智能座艙的影分身術: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技術?
回答:
- Hypervisor帶來的性能、資源的開銷很小。
- Hypervisor對錯誤處理、故障處理帶來的冗余。
- Hypervisor對硬件的隔離,有利用硬件的更新迭代。
- 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協議
作者做過hypervisor座艙與單獨控制器的具體成本對比嗎?例如研發費用及單件成本。