标签：仿真 AUTOSAR 演进 优劣 MCAL 硬件 ECU 虚拟

现代汽车更安全、更舒适、更智能的代价是车载ECU（Electronic Control Unit）数量的迅速增长，与之相对应的是ECU上规模软件越来越大、软件开发成本在整车制造成本中的占比越来越高。车企可以从规则与方法两个角度入手来解决上述问题：

• 一手抓规则：汽车开放系统架构AUTOSAR；
• 一手抓方法：通过仿真建模技术搭建虚拟ECU，实现汽车的“数字孪生”。

本文将以此为基础，分析虚拟ECU在智能汽车驾驶演进过程中，基于AUTOSAR架构的多个种类以及个中优劣。

01.汽车开放系统架构AUTOSAR

AUTOSAR（AUTomotive Open System ARchitecture）源自2003年，是由全球知名汽车制造商、零部件供应商及其他电子、半导体和软件系统公司联合建立的汽车开放系统架构联盟，该联盟所推出的规范被称为AUTOSAR规范，通过对汽车基础软件进行标准化定义，提升汽车ECU的兼容性、复用性与可靠性。 AUTOSAR遵循的是一种自上而下的开发方式，即先进行系统设计，再分别进行开发实现，最终进行系统集成。主要做了以下三件事：

• 对应用软件与底层软件之间以及应用软件之间的接口进行标准化；
• 给出一个控制器软件参考架构；
• 规范分布式开发流程中的交换格式。

根据AUTOSAR GBR. AUTOSAR layer software architecture R4.4.0的资料显示，其整体框架呈分层式设计，以中间件RTE（Runtime Environment，RTE）为界，隔离上层的应用层（Application Layer，APPL）与下层的基础软件（Basic Software，BSW）。 ​▲AUTOSAR软件架构   在20年的长久发展之下，AUTOSAR架构已趋于成熟，汽车嵌入式系统软硬件的耦合度大大降低，截至目前，AOTOSAR已被广泛应用于ECU软件开发和汽车电子设计，如汽车底盘控制系统开发、底层通信软件设计、整车电子电气架构设计、汽车电子诊断系统开发及电机控制系统设计等领域，为满足用户日益增长的智能驾驶需求提供了新解决方案。

02.虚拟ECU种类及优劣分析

根据AUTOSAR框架的不同层次，虚拟ECU可以分为以下四个大类： ​▲虚拟ECU分类   第一类：仅包含ASW和RTE（RTE中可能会包含一个OS）

• 只仿真RTE环境，仅能测试ASW的基本功能，忽略了基础软件中的通信细节。
• 如果ASW的代码是AUTOSAR兼容的，则可以对ASW代码进行测试。

**此类虚拟ECU因为不涉及硬件，所以构造较为简单，但无法保证与真实ECU同样的执行行为。   第二类：包含ASW，RTE和虚拟的BSW。

• 此类虚拟ECU相比第一类更加真实，可以对ASW、RTE代码进行测试。
• 虚拟BSW的作用是将底层硬件的特性和复杂性进行抽象和封装，为上层应用软件提供简化的接口和功能，从而实现对底层硬件的虚拟化。

**无法测试真实硬件的一些实际执行行为。   第三类：上述基础上外加OS及一个虚拟的MCAL（Microcontroller Abstraction Layer）。

• 相比第二类更加真实，可以测试任务调度以及BSW的功能。
• 虚拟MCAL负责封装底层硬件的访问，通过软件模拟来完成硬件相关的功能，提供统一的接口给上层软件，使得软件开发人员可以更方便地编写应用程序，无需担心底层硬件的差异。

**值得注意的是，虚拟MCAL也会带来一些问题：

• 性能损失：由于虚拟MCAL是通过软件模拟来实现底层硬件功能虚拟化的，可能导致仿真性能相对较低于直接访问实际硬件，尤其是在对实时性要求较高的应用场景下——可能会出现延迟问题。
• 适配性问题：因其需要针对不同的底层硬件进行开发和适配来实现仿真，原有的虚拟MCAL大概率无法完全涵盖所有的底层硬件特性和功能，一旦涉及定制化开发就会导致成本上升。
• 复杂性和维护成本：虚拟MCAL的开发和维护可能需要投入大量的人力和资源。虽然虚拟MCAL可以提供抽象和统一的接口，但其底层实现与硬件相关，需要工程师对硬件规格有着深入理解以落实维护，开发和维护的复杂性和成本也会随之上升。
• 功能限制：由于虚拟MCAL的仿真实现很有可能无法完全复现所有底层硬件的功能，在一些复杂功能上会有所受限，无法满足所有应用场景的需求，尤其是在一些复杂的硬件功能和特性方面。
• 灵活性较差：此类虚拟ECU也无法直接运行真实ECU的二进制代码，对于复杂设备驱动（Complex Device Drivers，CDD）支持也较为欠缺。

  第四类（最佳）：与第三类相同，但MCAL为真实硬件MCAL。

• 实现了完全仿真，能够实现几乎相同的真实硬件行为。
• 可通过完全模拟ECU处理器、相关外设及总线等设施实现【真实ECU相同的二进制代码】的直接运行。
• 可在此基础上实现真实硬件无法达成的故障注入，以测试软件的安全性与可靠性。
• 灵活性较强，可以增加CDD的建模仿真。

**由于需要模拟硬件的技术细节，因此存在一定的建模工作量和建模周期；同时，为了确保具备一定的实时性，该类虚拟ECU的搭建往往具有较高的技术难度。

基于SkyEye的虚拟ECU解决方案

国产自主可控的天目全数字实时仿真软件SkyEye，作为基于可视化建模的硬件行为级仿真平台，支持搭建第四类虚拟ECU，可高度仿真真实控制器。除了第四类虚拟ECU原有的优势外，基于SkyEye的虚拟ECU解决方案还有着以下特点：

• 可以将开发任务从路测和台架转移到Windows/Linux PC上，以实现ECU软件的高效软件在环（SIL）开发。
• 系统本身同时也是一个强大的实验环境，可通过协同仿真总线平台工具与多种工具（包括通过标准化的FMI接口运行MATLAB/Simulink和其他多种工具）的仿真模型进行数据交互。
• 虚拟ECU的相关配置可以快速复制拓展，复制成本低、比真实硬件也容易得多。
• 每位工程师都能拥有个人开发环境，不会占用HIL台架或测试车辆之类的稀缺资源，避免因硬件资源紧张引起的研发周期过长问题，更多工程师能从中受益。

总体而言，基于SkyEye的虚拟ECU解决方案有着如下优势：

• 可以在早期开发阶段进行软件开发、集成和测试，加速整个开发过程，提高开发效率。
• 减少实际车辆测试的需求，降低测试成本和时间，同时减少由于实际车辆测试带来的风险和损失。
• 提供可视化的仿真结果，帮助开发人员更直观地理解控制系统的行为和性能。
• 可以在模拟环境下进行测试，提高测试的精度和可重复性，并减少测试中的人为误差。

虚拟ECU作为一种创新性的技术，对于ECU软件开发具有重要的现实意义。其不仅提高了汽车软件的开发效率与可重用性，为系统集成与验证带来了便利，还为软件开发和测试提供了更好的环境，对汽车ECU软件的安全性与隔离性起到了至关重要的保障作用。虚拟ECU将在未来的汽车电子系统开发中发挥越来越重要的作用，推动汽车行业迈向更智能、更安全的未来。  

标签：仿真,AUTOSAR,演进,优劣,MCAL,硬件,ECU,虚拟
From： https://www.cnblogs.com/digiproto/p/17606683.html