现代汽车更安全、更舒适、更智能的代价是车载 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 软件架构

*基础软件层的相关内容可以查看小迪历史文章：《汽车 ECU 软件开发之应用层软件与底层软件》（点击跳转）

在 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 将在未来的汽车电子系统开发中发挥越来越重要的作用，推动汽车行业迈向更智能、更安全的未来。

原文链接：https://mp.weixin.qq.com/s/Zz0_9O1UA6K1QXsGjVNGQg