汽车ECU的虚拟化技术(四) -- 对MCU虚拟化实现难点的思考

lihu35

目录

1.OEM面临的难点

2.Hypervisor的难点思考

2.1 VMs部署到物理内核上的实现方式

2.2 VM调度机制

2.3 虚拟化中的中断处理

2.4 虚拟ECU的通信

3.小结

---

1.OEM面临的难点

为什么汽车ECU在逐渐倡导虚拟化，主要原因是整车电子电气架构从分布式往集中式演进，OEM希望将以前多个ECU的功能聚合到一个ECU中；并且近几年国际大厂推出的MCU性能越来越强大，从硬件层面有了实现虚拟化的基础。不过光有硬件还不行，软件也得跟上；因此，除了在功能层面上面的软件实现，现又新增了对虚拟化的软件实现需求。在此之前，OEM在整合多个供应商软件时候，都是以单个大功能（如BMS）独享整个MCU资源为前提；现在突然要将这些软件功能放到一个ECU，共享MCU的资源，同时还要保证功能的隔离和资源不会冲突，想想头都大了。我们以最粗暴的方式来形容这个过程，以前做集成的时候，会把Bootloader和App两个hex文件合成一个完整hex，然后刷进ECU里，现在就是要把这些不同功能的hex文件合并成一个大的hex文件，刷进高性能的MCU里，如下图：

假设MCU里面只有三个核，但是有5个不同类别的应用需要集成；为实现功能隔离、资源共享，借鉴座舱系统SOC的Hypervisor思想，如果能在MCU应用一二，也就可以实现上述要求，如下图：

因此个人认为，Hypervisor软件是实现电子电气架构演进的关键路径。据调研，目前市面上对于CP AUTOSAR下的虚拟化解决方案有Vector的veHypervisor、ETAS的RTA-HVR、EB的Embedded Hypervisor，不过应该都还达不到量产阶段。

---

2.Hypervisor的难点思考

据目前的资料整理，当前基于MCU的Hypervisor均属于Type-1，即Hypervisor直接运行在MCU裸板上。Type-1和Type2区别如下：

在Type-1 hypervisor下可以布局的方案如下图：

一般来说，Hypervisor是需要运行在最高异常等级下，例如R52内核MCU就需要hypervisor在EL2等级运行，英飞凌TC1.8更直接，直接就提供了名为hypervisor的运行模式。

那么这就引出了第一个问题：VMs部署到物理内核上的实现方式？2.1 VMs部署到物理内核上的实现方式

我们还是以上图为例，假设Power Control这个虚拟ECU（下文称VM）在最初设计时就需要两个内核来处理通信任务和高实时性任务，这就会和BCM VM或者Gateway VM至少共享一个物理内核，因此在布局上就可以如下图所示：

那么部署成功后，每个VM占用物理内核的调度应该是怎么样的呢？2.2 VM调度机制

根据英飞凌官网介绍，目前主要有两类的调度机制：固定优先级和时间切片；如下图：

固定优先级：高优先级可以抢占低优先级的VM

时间片调度：每个VM在固定的时间槽内占用物理内核

从实现角度来说，使用固定的时间片看起来比较容易实现。假设有4个VM，占用一个物理内核的时间片分别为100us、200us、300us和400us；这样刚好就能简单组成一个完整的调度周期为1ms。调度没有问题了，那如果这期间产生了中断，又该如何处理？2.3 虚拟化中的中断处理

由于中断产生其实是要对应实际功能的，因此在芯片设计时就应考虑虚拟化下的中断是可以分配到某VM，这样我们就可以识别当前产生的中断是哪一个VM需要。此外，还要考虑在其他VM运行期间的中断处理，举个例子，假设VM2正在运行，此时来了一个属于VM1的中断，这时候要不要处理？一般来讲，中断产生后应由hypervisor分发到不同VM，所以这个在设计hypervisor软件是需要考虑中断的抢占性。如下

上图中，VM1的ISR就可以抢占VM3的内核占用时间，但不能抢占VM2的内核占用时间。 2.4 虚拟ECU的通信

在之前分布式架构，ECU之间的通信多为CAN\CANFD，是有实际的物理线束的。现在好了，这些ECU整合到一个MCU里，他们之间的通信该如何是好？我们最容易想到的就是采用共享内存和Mailbox的方式，毕竟核间通信就是如此设计，但是虚拟化的特征就是VM始终认为自己独占MCU资源，因此对于共享内存的划分就很随意；如何保证共享内存不冲突，且读写权限，这是Hypervisor需要考虑的事情。此外，同一个VM里的不同内核通信，又该如何处理呢？个人认为可以尝试沿用AUTOSAR里的IOC机制，但限于多核经验有限，这里就不献丑了。

---

3.小结

上面是个人对hypervisor这一层级的软件思考，鉴于之前没有QNX Hypervisor的经验，暂时能想到的就是这些。接下来还是得好好捋一遍QNX hypervisor，看看有什么可以继续吸收的。其实，上面只是从应用功能上进行了梳理，但是还有更重要的两个方向没有考虑到，那就是Safety和Security。举个例子，在分布式架构下，每个ECU拆分下来的ASIL等级是不相同的，如下图：

那么如果把不同ASIL等级的ECU集成到一个ECU里，这个功能安全该如何分析？ 在设计Hypervisor软件时，是否也需要对软件进行功能安全认证？如果要做认证，那就只能以SEooC的方式进行软件设计，而这样的软件会用到量产上吗？除此之外，针对Security的设计应该如何考虑。据了解，目前量产的MCU基本都是内置HSM，但是只有一个密码加速引擎，这在多VM下势必会产生竞争。如何保证各VM都能够使用到HSM，一个方法是增加HSM加速引擎实例，另一个方式可以在HSM侧增加多个Host的配置，先保存来自VM的请求，根据固定优先级算法进行处理，这就必须考虑HSM引擎的数据处理能力了。以前还在想汽车MCU的虚拟化应该还很远，殊不知就在自己磨磨蹭蹭的时候需求都已经提过来了。同志们，得再加把劲儿啊。

---

往期回顾：

1.汽车标定精选
汽车标定技术--标定概念详解
汽车标定技术--Bypass的前世今生
万字长文：汽车标定技术--XCP概述

2.AUTOSAR精选
AUTOSAR CryptoStack--CSM Job夹带了哪些私货
AUTOSAR 诊断栈分析(一)
AUTOSAR OS概述（一）

3.汽车网络安全精选
汽车信息安全--MCU启动常用密码算法
汽车网络安全方案需求分析
汽车信息安全--常见车规MCU安全启动方案
车载信息安全场景概述

4.汽车功能安全精选

5.汽车虚拟化精选

    汽车ECU虚拟化技术初探(一)

    汽车ECU虚拟化技术(二)--U2A虚拟化功能

6.杂七杂八

    Flash模拟EEPROM原理浅析

    征途漫漫:汽车MCU的国产替代往事

    车规MCU应用场景及国产替代进展