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

本文探讨了OEM在电子电气架构演进中遇到的集成难题,如何通过Hypervisor实现不同功能的软件在MCU上的共享与隔离,以及VM部署和调度机制,特别是基于Type-1Hypervisor的实现方式和可能的调度策略。
摘要由CSDN通过智能技术生成

目录

1.OEM面临的难点

2.Hypervisor的难点思考

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

2.2 VM调度机制

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。

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

3.小结

本文主要讲解了OEM面临新的电子电气架构下的集成难点,引入了hypervisor以及VM调度机制,下一篇我们将继续讲VM之间的通信、中断处理、在safety和security上面的思考

评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

CyberSecurity_zhang

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值