智能座舱的影分身术：Hypervisor（二）

本文分析了汽车电子需要的Hypervisor、Hypervisor方案的技术反思、Hypervisor技术使用的必要性以及Hypervisor对SoC的选择的影响。

接着智能座舱的影分身术：Hypervisor（一）的概念讲解，我们说明一下实际Hypervisor的进一步思考。

一、汽车电子需要什么样的Hypervisor

1. 安全要求

• 虚拟机系统设计需要达到ASIL B的安全等级。
• 硬件的系统隔离和安全系统。
• 安全模式启动

服务质量保证的高优先级任务性能水平。

2. 功能要求

• 多操作系统支持（Linux、Android、RTOS，QNX）
• 具备多屏互动的高效解决方案
• 图形图像加速的能力
• 系统快速启动与优化
• 启动画面显示显示
• 软件硬件分离

3. 接口标准

• 故障监视与诊断处理
• 优先级和调度策略
• 共享内存与进程间通信
• 半虚拟化设备的标准接口
• 透传的IO优化策略

二、Hypervisor方案的技术反思

我们对比一下各个Hypervisor厂商的宣传的技术的优势。

如果不考虑成本优势的话，在分布式电子电气架构下，Hypervisor厂商所宣传的虚拟化优势，都不是优势而是问题。

Hyperviosr技术在冗余算力调用，故障恢复方向有所成就，但是按汽车功能安全要求来说，原有的产品也是满足这些需求的。

三、一定要用Hypervisor技术吗

Hypervisor能省钱，灵活性上有所增强，是不是座舱一定要用Hypervisor技术？

回答：不一定。

拿Tesla Model3作一个例子，这个例子并不极端，在多个屏幕的状态下依然有效（由于不了解细节，我们这里的方案都是假想）。

智能座舱应用假设包含仪表、IVI、ADAS，显示输出一个屏幕。

在同样的成本条件下，我们有多处可行的解决方案：

• 方案1：Linux虚拟机方案，运行多个虚拟化系统，由仪表管理GPU，统一输出到屏幕。
• 方案2：单Linux方案，运行一个系统，保证ASIL B级别，单一输出。
• 方案3：轻量级虚拟化，考虑方案2可能存在的问题，可以在操作系统层进行虚拟化，采用容器技术虚拟化，保证仪表、自动驾驶的资源优先保证。

针对低功耗需求、启动需求、电源管理需求单独考虑。

为什么依然推荐使用Hypervisor技术？

回答：

• 软件硬分离带来的好处理。
• 与世界的进程保持同步。

虽然某些情况下，不使用虚拟化技术我们一样能解决问题，为什么还推荐使用Hypervisor技术？

回答：

1. Hypervisor带来的性能、资源的开销很小。
2. Hypervisor对错误处理、故障处理带来的冗余。
3. Hypervisor对硬件的隔离，有利用硬件的更新迭代。
4. Hypervisor是行业发展的整体选择，独立开辟、维护一条技术协议栈终将落后，除非你象Tesla一样有创造力，有控制力，有克制力。

举个历史故事：

自动驾驶发展史上，人们最初希望通过对道路的改造，比如铺设磁铁，来完成车辆自动驾驶。

探索很多年之后，所有的尝试都失败了。直到深度学习的发展重新为人类指明了自动驾驶的发展方向。

如果当初有人选择了深度学习的方向，自动驾驶**更快的到来吗？

几乎不**，因为个体选择的进步要等待时代。同样，今天如果选择5G作为实现自动驾驶的核心，那也**完蛋。

座舱还是选择Hypervisor好，以后麻烦少。

四、Hypervisor对SoC的选择有什么影响

SoC的选择与Hypervisor的选择是互相影响的，因为不是所有的SoC对所有的虚拟机都作过优化。

由于Hypervisor方案涉及到CPU、GPU的虚拟化，半虚拟化解决方案涉及到对上层OS的修改，完全虚拟化涉及到各个CPU的资源分配调用。汽车领域使用虚拟化技术依然需要SoC厂商与Hypervisor厂商共同的支持来进行优化。

• QNX支持IMX8系统、高通820A系列、SA6155/8155、瑞萨RCar系列；
• Global Hypervisor支持TI J6、瑞萨RCar系列、Intel Apollo系统；
• MTK、Autochips等公司都是基于Xen来完善与支持虚拟化技术。

当我们选择了SoC，或者选择了Hypervisor方案的时候，我们对另一部件的选择，甚至对上层OS采用QNX还是Linux其实也一样做出了选择。

作者：updatedb；公众号：强哥的面包屑  /  MyCrumbs。

本文由 @updatedb 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议