目录
1.概述
2.虚拟化软件的难点
2.1 虚拟化中的中断处理
2.2 虚拟ECU的通信
3.小结
1.概述
在上面文章里汽车ECU的虚拟化技术(四) -- 对MCU虚拟化实现难点的思考-CSDN博客,解了OEM面临新的电子电气架构下的集成难点,引入了hypervisor以及VM调度机制,接下来我们将继续讲VM之间的通信、中断处理、在safety和security上面的思考。
2.虚拟化软件的难点
2.1 虚拟化中的中断处理
由于中断产生其实是要对应实际功能的,因此在芯片设计时就应考虑虚拟化下的中断是可以分配到某VM里的;这样我们就可以识别当前产生的中断是哪一个VM需要。
此外,还要考虑在其他VM运行期间的中断处理,举个例子,假设VM2正在运行,此时来了一个属于VM1的中断,这时候要不要处理?
一般来讲,中断产生后应由hypervisor分发到不同VM,所以这个在设计hypervisor软件是需要考虑中断的抢占性。如下
上图中,VM1的ISR就可以抢占VM3的内核占用时间,但不能抢占VM2的内核占用时间。
2.2 虚拟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的虚拟化应该还很远,殊不知就在自己磨磨蹭蹭的时候需求都已经提过来了。同志们,得再加把劲儿啊。