智能汽车驾驶演进:虚拟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)。
![](https://pic1.zhimg.com/80/v2-1150a8d09eafdb9e012e522164f1737f_1440w.png)
▲AUTOSAR软件架构
在20年的长久发展之下,AUTOSAR架构已趋于成熟,汽车嵌入式系统软硬件的耦合度大大降低,截至目前,AOTOSAR已被广泛应用于ECU软件开发和汽车电子设计,如汽车底盘控制系统开发、底层通信软件设计、整车电子电气架构设计、汽车电子诊断系统开发及电机控制系统设计等领域,为满足用户日益增长的智能驾驶需求提供了新解决方案。
02.虚拟ECU种类及优劣分析
根据AUTOSAR框架的不同层次,虚拟ECU可以分为以下四个大类:
![](https://pic1.zhimg.com/80/v2-54bb7e7d951d0f786253dcb5c2026fc8_1440w.png)
▲虚拟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将在未来的汽车电子系统开发中发挥越来越重要的作用,推动汽车行业迈向更智能、更安全的未来。