如何看待電動汽車電子架構的發展？

04-26

我覺得電動汽車帶來了重大的歷史機遇，很多地方都會帶來改變，這裡既有傳統動力總成轉向電動汽車獨特的東西，而隨著電動汽車本身發展對原有的電子架構產生了深刻的影響。而在這塊也正是我們對於底盤、動力總成和網聯，這幾個Domain重構，我們在通往這條路上該怎麼看待、怎麼選擇和怎麼執行和操作，都需要跨領域的探討。這次我和我的幾位少壯派好友，仔細做了一個探討，在採訪和匯總的基礎上，做了兩篇習作，請大家參考。本文的話題是「MEB新一代的汽車電子架構展望」，主要包括：

架構需求
架構準則
軟體架構

虛擬化
操作系統
Adaptive AUTOSAR
服務為導向的軟體架構
網路通信
功能分配
開發模式

控制器硬體

早一些的時間，我在整理有關大眾電氣化的發展，特別是有關MEB還有後續豪華車電動平台的信息，在整車平台，特別是電動汽車的布置、核心電池和驅動系統上做了很大動作的勾畫。

而我的友人也談及，在MEB的電子電器方面，德國人也做了很多的內容，一直以來VW對於電子部分公開的信息比較有限，通過幾份介紹資料以及以往對於一些技術發展的研究，可以一探MEB有關電子/軟體架構的動向，對於未來MEB的電子架構還是明顯感覺汽車電子的技術發展真的非常快，應用速度不斷加快。傳統整車企業的領導層都感受到了技術的發展對於自身開發的壓力，特別是受到以快打慢，講究體驗和迭代的IT，互聯網巨頭競爭的壓力。順應消費者的訴求，整個汽車行業也不得不快速與數字世界融合中，不管從研發，製造到服務都處於數字化的演變中。這個制高點，我們來看看德國大眾是怎麼做的。

以下這些是摘錄的部分大眾有關MEB新聞稿，從中可以看出，在戰略上大眾造車理念表達出來有了很大的延伸和變化。

Analog zur ?Apple ID「 ben?tige auch Volkswagen eine entsprechende pers?nliche ID, die er in seinen Folien ?Group ID Mobility「 nennt, ?damit unser Kunder an all unsere Produkte gebunden wird und sich immer wieder zurechtfindet – und das funktioniert schon recht gut.「 All das müsse ?natürlich über Fahrzeug-Generationen hinweg funktionieren「. Und das ist sehr wichtig: ?Wer das richtig macht, der bekommt die Kunden, denn sie sind froh, wenn sie datentechnisch vernünftig aufgehoben sind und die Funktionen bekommen, die sie auch haben m?chten.「

by Ralf Milke, Leiter E/E-Entwicklung Karosserieelektronik und Bordnetz bei der Volkswagen AG

摘自 http://www.all-electronics.de/keynotes-automobil-elektronik/3/

「The VW I.D. Buzz will use DRIVE IX technology to create 「Intelligent Co-Pilot」 applications, which will include convenience and assistance systems based on processing sensor data from both inside and outside of the car. The systems can be enhanced throughout the life of the vehicle via software updates, and can gain new capabilities as further developments are made in autonomous driving. 」

摘自 https://globenewswire.com/news-release/2018/01/08/1284707/0/en/Volkswagen-and-NVIDIA-to-Infuse-AI-into-Future-Vehicle-Lineup.html

MEB從用戶體驗出發設計整車功能（Feature)，試圖把數字化生活拓展到車上，使得車輛成為數字化生活的一部分，並且借鑒Apple模式來開發整車。Apple有自己的用戶體驗/UX設計，以及封閉成熟的iOS，性能領先的64位處理晶元。如果要對標Apple，需要從這些維度去構建MEB的技術優勢。

1. 架構需求

電子電器架構開發之初需要定義技術開發需求，大眾MEB電子電器架構的需求慢慢朝個人數字生活需求轉變，「MaaS」的理念應該會在這代MEB的電子架構平台上展現。從以下這張圖上可以看出MEB的功能需求定義已經更為拓寬。

圖大眾兩代架構平台對比摘自 Vector Congress 2016

Auto. Driving這個不用說，這兩年炒得火熱，基於它可以衍生出很多功能應用與消費場景；
Digitalization可以跟「ID」更緊密地聯繫起來。

這些需求下開發的技術功能會迭代以及更新並且新的功能會在消費者手中時發布，APP Store概念也會從手機/電視端往車輛發展。傳統OEM的「功能手機」時代應該會加速切換。

2. 架構準則

在Bosch發布的關於電子電器架構發展趨勢報告中，就把「域」控制器以及整車級」計算平台「的需求描繪出來，當下各大OEM也都在加緊部署」域「DCU。

圖 Bosch 電子電器架構趨勢報告

不管是」域「也好，」大腦「也好，核心是需要設計開發準則Criteria

哪些功能應該放在一起？
哪些需要獨立分布？
哪些需要頻繁升級更新？

這些開發準則可以相互借鑒，但各家有各家的實際情況，車型種類/產量/市場定位都不一樣。當然如果採用跟隨戰略通常做法，但是看下現今的手機市場，如果汽車市場未來的集中度越來越高，那麼各家OEM就得尋找差異化的競爭力，架構策略會有不同。

MEB走個人數字方向，那麼個性化的需求要求下，軟體差異性化，升級迭代, 軟體功能訂購是必須。現在很多車上都已經宣傳個人的信息帳號系統已經建立了，軟體也在更新換代，OTA已經實現。我想這只是部分功能（Infotainment為主）的帳號關聯，如上文提到的把車作為MaaS的話，需要關聯的功能還有許多。

3. 軟體架構

虛擬化

功能開發就不得不提功能安全與網路信息安全，這兩塊在歐洲OEM是與功能開發相同步的流程。為了讓不同Safety/Security級別的功能能夠合理有效的實現，需要對系統的底層硬體與軟體做技術升級。汽車電子的虛擬化也已經到來，hypervisor虛擬化能夠直接從硬體層面分割硬體資源保持片上多軟體系統獨立。

對多核處理晶元進行硬體資源隔離降低信息安全/功能安全的隱患

備註：最近爆出的intel/arm Spectre與Meltdown漏洞是對汽車晶元也有影響的，至今沒有看到有效修補方案，硬體層面的漏洞需要在內核設計中優化，不能短期完成

圖大眾Adaptive AUTOSAR框架摘自 Vector Congress 2016

從整體上未來各家OEM在整車主幹網上的主節點（域控制器）將會虛擬出多個封閉軟體系統。

傳統汽車基礎軟體供應商正在加快開發hypervisor適配域控制器內那些多核汽車微控制器
傳統消費電子類晶元巨頭INTEL/Nvidia也在加快進入汽車電子領域，他們除了提供晶元技術以外虛擬化解決方案也一起打包

隨著未來數據計算力要求越來越高，消費電子類巨頭搶佔汽車核心處理晶元的趨勢越發明顯，而傳統的汽車電子供應商的晶元則更多的在安全領域，終端執行，感知層面出現。為了適應數字生活，在娛樂域控制器引入互聯網的解決方案能夠有效解決車與外界的數據交互，同時也能有效解決信息安全。

操作系統

除了硬體虛擬化外，基礎軟體/操作系統也在進行改變。當今的汽車軟體操作系統，除了娛樂系統，

動力/底盤/車身系統大部分都採用實時操作OSEK/AUTOSAR OS，
VW在MEB上的域控制器已經切換成POSIX OS與Adaptive AUTOSAR，
當然classic AUTOSAR還會繼續存在，Safety相關的還需要依賴與Classic（safety） AUTOSAR。

很快就可以看到在一塊晶元上既能跑Linux，QNX又能跑傳統AUTOSAR OS的控制器

對於高性能計算能力系統需要POSIX OS, 支持如GPU的計算。同時需要集成滿足車載通訊要求的網路通信協議棧，UDPNM, DOIP, SOME/IP以及支持時間同步的802.1AS。而這些在當前的OS基礎軟體中沒有提供，需要陸續部署

對於POSIX OS本身，大家普遍青睞於Linux，開源可以帶來自由定製，但是開發之初未涉及到汽車控制領域，對於任務調度/搶佔機制還在優化過程中。雖然也有Tier1與OEM在使用QNX，但是一旦涉及到深度軟體定製開發，那麼QNX本身的開放程度將會決定未來可以應用範圍。

Adaptive AUTOSAR

Adaptive AUTOSAR也是必須底層軟體涉及的部分，雖然像Linux也有很多現成的驅動底層，對於汽車行業的控制軟體涉及車輛安全所以不得不提出自己本身的軟體要求，同時為了滿足統一的介面要求，才會對現有POSIX軟體生態體系提出Adaptive AUTOSAR。

從2017年開始Adaptive AUTOSAR釋放第一版規範，但是Adaptive AUTOSAR還處於開發模式階段，會每６個月更新版本，2018/10將釋放第一個完整版本，後續將會與Classic AUTOSAR R4.4.0同步。雖然要到18年10月才能凍結，且第三方軟體供應商會較標準滯後，但像VW這樣的業內巨頭，完全會提前獲得對應版本的軟體（Autosar的白金會員名單，這些OEM，Tier1是定義標準規範的主力）