汽车虚拟ECU和MCU硬件虚拟化，傻傻分不清楚

本文主要是介绍汽车虚拟ECU和MCU硬件虚拟化，傻傻分不清楚，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1.概述

2.汽车虚拟ECU

3.汽车MCU虚拟化功能

4.小结

1.概述

近几年，随着智能网联汽车普及，车型的更新迭代速度进一步提升，功能开发工程师希望在能够在硬件成型前验证软件功能，意味着汽车控制器的功能开发也在不断左移。

为此业内出现了对ECU进行虚拟化以加速开发的呼声，在22年瑞萨联合ETAS就提出了基于Zone ECU的虚拟化解决方案。

随着这种方案的出现，对高端MCU也出现了要求支持虚拟化功能。

那么什么是虚拟ECU，什么是汽车MCU虚拟化，我来一一梳理一下。

2.汽车虚拟ECU

我们知道，一个完整的汽车ECU是包括软件和硬件。

做过模型开发的朋友应该都有过MIL和SIL的经验，忽略掉ECU硬件，直接在x86平台的PC机上验证软件功能，这就是虚拟ECU最初的形态。

由于这种只是运行在PC主机上的仿真软件，无法对软件的实时性、效率、性能做出有效评估(simulink仿真的步长让人窒息)；慢慢提出了一种将ECU硬件也进行虚拟化的需求，这就需要对MCU内核、外设资源以及ECU外围电路进行详细建模以达到与实际ECU硬件相近甚至完全一致的效果。

基于此，个人理解的虚拟ECU就主要分成两大类：

基于PC编译器编译生成的ECU软件，该软件运行在PC主机，没有ECU硬件支持，因此该虚拟ECU(vECU)只能验证部分功能，较少能够做全功能验证，常见工具如ASCET、Simulink等；

Simulink提供的汽车ABS仿真建模

基于目标MCU编译器(例如Tricore系列、RH850系列)编译生成的ECU软件 + ECU硬件的板级建模，该vECU就与真实ECU相近，该vECU同样可以运行在PC。常见编译器如GreenHill、Tasking、HighTec；常见硬件建模如新思提出的Silver虚拟ECU仿真平台，实现了把开发任务从路测和台架转移到PC，大大提高效率。

新思提出的Silver方案，不受硬件资源限制，可对ECU软件的不同层级在PC测试

在收集这块资料时，翻到了新思对vECU的具体定义，非常详细。这里分享给大家：

从上图可以看到，vECU的等级是从Leve0-Level4；

Level 0：针对算法模型，常见的就是Matlab/Simulink、ETAS Ascet，这个就与之前定义的基于PC编译器的虚拟ECU类似；
Level 1-3：随着算法的成熟，软件开发人员希望能够在一个真实的ECU环境下进行验证，但是此时硬件如果还没有成熟(如果软硬件并行开发)，新思就提供了很完整的解决方案；它基于Classic AUTOSAR提出了BSW各层级的软件仿真代码，包括RTE、I\O、MCAL甚至说中间件等，那软件开发人员就可以基于此将应用代码集成并在PC主机编译进行仿真测试；
Level 4：到达这一层级，软件开发人员就更过分了，他想要上量产代码了，但是硬件还在定版，这时候就如果能基于目标内核编译出完整的hex文件，然后在仿真平台测试，如上图Level 4b中的深绿色方框；迭代测试后就可以结合实际硬件ECU量产了。

具体产物在不同阶段如下：

从这个角度来看，随着vECU的提出，在硬件建模、算法建模方向的人员需求是逐年提升的；传统OEM或者Tire1的开发模式会有颠覆性的改变，冗余的ASPICE、V model可能会被挑战，因为上述提到的vECU可以更容易实现CI/CD。

这是我对虚拟化ECU的理解。

3.汽车MCU虚拟化功能

那么现在S32Z、U2A、TC4xx提出的MCU虚拟化跟虚拟ECU有什么关系呢？

个人认为，上述MCU提出的虚拟化是指硬件虚拟化，这是为中央域电子电气架构做准备的功能。通过一颗芯片能够实现多个汽车ECU功能。我们以S32Z公开培训资料为例：

在当前多域控的整车电子电气架构里，域控其实还要下挂很多子节点，如上图：动力控制ECU、BMS等等，用硬件资源定义汽车架构。

随着功能的融合和架构的眼睛，有没有可能使用一颗芯片零成本移植以前独立ECU的所有功能(pin2pin)？显然参考以前座舱域SoC的开发方法，使用hypervisor为仪表和中控提供服务，MCU也可以实现，如下：

将上述提到的PDC、INV、BMS、EMS等功能全部集中到一颗MCU，从而实现了当前越来越流行的软件定义汽车。例如，S32Z支持4个物理内核，但是现在有6个大型功能需要集成，在功能软件不做大修改情况下，使用Hypervisor虚拟出6个CPU运行不同功能，保证这些应用软件运行时就像自己独占这颗MCU资源。如下图：