Go最全智能汽车驾驶演进：虚拟ECU种类与优劣分析，字节跳动8年老Golang面试官经验谈-CSDN博客

本文链接：https://blog.csdn.net/2401_84904661/article/details/138763345

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

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

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

汽车开放系统架构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软件开发和汽车电子设计，如汽车底盘控制系统开发、底层通信软件设计、整车电子电气架构设计、汽车电子诊断系统开发及电机控制系统设计等领域，为满足用户日益增长的智能驾驶需求提供了新解决方案。

根据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的仿真实现很有可能无法完全复现所有底层硬件的功能，在一些复杂功能上会有所受限，无法满足所有应用场景的需求，尤其是在一些复杂的硬件功能和特性方面。