Khorina · 6月7日

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

目录

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里,如下图:

image.png

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

image.png

因此个人认为,Hypervisor软件是实现电子电气架构演进的关键路径。

据调研,目前市面上对于CP AUTOSAR下的虚拟化解决方案有Vector的veHypervisor、ETAS的RTA-HVR、EB的Embedded Hypervisor,不过应该都还达不到量产阶段。

2.Hypervisor的难点思考

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

image.png

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

image.png

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

image.png

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

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

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

image.png

那么部署成功后,每个VM占用物理内核的调度应该是怎么样的呢?

2.2 VM调度机制

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

image.png

从实现角度来说,使用固定的时间片看起来比较容易实现。

假设有4个VM,占用一个物理内核的时间片分别为100us、200us、300us和400us;这样刚好就能简单组成一个完整的调度周期为1ms。

调度没有问题了,那如果这期间产生了中断,又该如何处理?

2.3 虚拟化中的中断处理

由于中断产生其实是要对应实际功能的,因此在芯片设计时就应考虑虚拟化下的中断是可以分配到某VM,这样我们就可以识别当前产生的中断是哪一个VM需要。

此外,还要考虑在其他VM运行期间的中断处理,举个例子,假设VM2正在运行,此时来了一个属于VM1的中断,这时候要不要处理?

一般来讲,中断产生后应由hypervisor分发到不同VM,所以这个在设计hypervisor软件是需要考虑中断的抢占性。如下

image.png

上图中,VM1的ISR就可以抢占VM3的内核占用时间,但不能抢占VM2的内核占用时间。 

2.4 虚拟ECU的通信

在之前分布式架构,ECU之间的通信多为CAN\CANFD,是有实际的物理线束的。

现在好了,这些ECU整合到一个MCU里,他们之间的通信该如何是好?

我们最容易想到的就是采用共享内存和Mailbox的方式,毕竟核间通信就是如此设计,但是虚拟化的特征就是VM始终认为自己独占MCU资源,因此对于共享内存的划分就很随意;如何保证共享内存不冲突,且读写权限,这是Hypervisor需要考虑的事情。

此外,同一个VM里的不同内核通信,又该如何处理呢?

个人认为可以尝试沿用AUTOSAR里的IOC机制,但限于多核经验有限,这里就不献丑了。

image.png

3.小结

上面是个人对hypervisor这一层级的软件思考,鉴于之前没有QNX Hypervisor的经验,暂时能想到的就是这些。

接下来还是得好好捋一遍QNX hypervisor,看看有什么可以继续吸收的。

其实,上面只是从应用功能上进行了梳理,但是还有更重要的两个方向没有考虑到,那就是Safety和Security。

举个例子,在分布式架构下,每个ECU拆分下来的ASIL等级是不相同的,如下图:

image.png

那么如果把不同ASIL等级的ECU集成到一个ECU里,这个功能安全该如何分析? 在设计Hypervisor软件时,是否也需要对软件进行功能安全认证?如果要做认证,那就只能以SEooC的方式进行软件设计,而这样的软件会用到量产上吗?

除此之外,针对Security的设计应该如何考虑。

据了解,目前量产的MCU基本都是内置HSM,但是只有一个密码加速引擎,这在多VM下势必会产生竞争。如何保证各VM都能够使用到HSM,一个方法是增加HSM加速引擎实例,另一个方式可以在HSM侧增加多个Host的配置,先保存来自VM的请求,根据固定优先级算法进行处理,这就必须考虑HSM引擎的数据处理能力了。

以前还在想汽车MCU的虚拟化应该还很远,殊不知就在自己磨磨蹭蹭的时候需求都已经提过来了。

同志们,得再加把劲儿啊。

作者:快乐的肌肉
文章来源:汽车MCU软件设计

推荐阅读

更多物联网安全,PSA等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信(id:aijishu20)加入PSA技术交流群,请备注研究方向。
推荐阅读
关注数
4558
内容数
136
Arm发布的PSA旨在为物联网安全提供一套全面的安全指导方针,使从芯片制造商到设备开发商等价值链中的每位成员都能成功实现安全运行。
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息