ID.3這款大眾MEB平臺的車還沒上市，就遭到德國媒體爆料有諸多的軟件問題，而大眾官方也沒有出來闢謠。最近大眾在英國發布了一些預告片，主要渲染這車的虛擬座艙、HUD和智能燈光控制，今天我們結合它的架構來探討一下這些智能化軟件組合的得失。我特別不喜歡某位仁兄寫的有關唱衰它的文章，MEB這個平臺雖然從三電系統上來看我們都能跟得上，但是在電子電氣架構方面，很多的時候我們真的只能集中資源去嘗試和摸索。
大眾軟件智能化水平
1） HUD視頻：
這條視頻折射出的是大眾的HUD特性，顯示的信息很多，把大量有關ADAS交互的信息配合著內部的燈光一起，作為和車主的交互。
2） 座艙的顯示：
以中控屏為核心（雖然ID.3上這塊屏不是很大），是大眾VW.OS的核心，它承載著整個車主和車輛的交互，同時也是和後臺進行交互的關鍵。
目前已經可以找到一些車載應用服務器ICAS3的結構照片以及它的功能定義，這個LG Electronics提供了一些基礎的軟件功能，大部分大眾自主開發的OS和交互軟件都是以此為基礎來做的。從目前來看，這有點類似第一代iPhone軟件系統的OS，還需要對很多地方進行完善。
我個人理解它的問題包括——
大眾把大量的車載計算平臺的交互，以SOA面向服務的形式開發，原來大量的Use Case、Feature轉化為Requirement，甚至做成功能邏輯都不難，但是具體到軟件架構中的服務和服務接口，再轉化成通信設計（以太網的參數和底層的CAN FD）在域控制器和傳統ECU之間進行執行的時候，由於之前沒有做過，就很難估計其複雜度。
圖1 ICAS3的核心
備註：在德國媒體的爆料中，這套軟件系統“道路測試每天都會上報新的問題，有數百名司機同時駕駛車輛進行路試，平均每天上報300個Bug”。有大約10000名工程技術人員在參加技術攻堅。而ID.3的硬件生產並沒有受到影響，都是缺乏可用的軟件系統。參加這一項目的人都認為。原定的夏季發佈這款車的計劃並不可行，可能會延期3~12個月，但大老闆依然堅持要按原計劃發佈。某種意義上，大眾在跨越一道鴻溝，之前大量的開發經驗，特別是在ICAS1-ICAS3這三個核心的計算平臺之間的軟件交互，大部分Tie1舊有的經驗用不上，從車企到支持的軟件供應商都要一點點“打怪”，慢慢積累經驗。
圖2 從信號到服務，我們要刷新認知
ICAS1和ICAS2的問題
大眾試圖在MEB平臺把車輛和人的距離拉近，不僅僅是依靠原有的PEPS這類的檢測，而是可以通過用戶的手機=>後臺=>車，交互的內容是車輛裡面大部分的服務，所以雖然ICAS1是一個車身+網關兼容的計算平臺，但是裡面的功能也非常多。
1） 從求全的角度考慮，以目前大眾把ICAS1中設計的網關/車輛管理功能，涵蓋高壓電源管理、低電壓能量管理、歷史數據記錄、疲勞識別、駕駛配置文件、剩餘有效里程、實時監控等等，在權限、訪問和個性化、在線個性化等等（包括車內燈光、空調和車外燈光），大眾在軟件服務定義的角度已經做得非常細緻，但是實際在實現過程中，這套基於E2E的架構需要耗費很多的時間和精力，特別是ICAS1也有獨立的網絡連接功能。這些把傳統車輛的功能以服務的形式和ICAS3進行交互，很大一部分是我們之前也沒有經歷過的。
圖3 End to End架構E3
2） 有zFAS在前，在ICAS2中比之前更少的定義，說明這套ADAS其實是輕車熟路的，更多的還是在一個算力更強的平臺裡面實現L1和L2的各項功能，集成各種軟件，我覺得這部分不會是MEB的瓶頸。
圖4 zFAS的框圖
小結：
我覺得我們現在不應該嘲笑大眾“弱雞”，目前我們就單個的車載計算平臺的開發，也都是一點點嘗試，等到我們把這些控制器組合起來，需要實現那麼多的新Use Case，而所有的新客戶都適應這些新的功能作為標配的時候，就輪到我們弱雞了。
我覺得這也是當下車企在軟件領域成立獨立的子公司並開始進行摸爬滾打的關鍵階段。有時候看這些架構、軟件和基於計算平臺的發展，為自己將來幹什麼深深憂慮，不過總是要跟著學習和進步才能跟上時代步伐。不過我確定的是對於系統工程師來說，還是可以找到自己的位置，雖然很多傳統開發ECU的汽車軟件工程師，想要轉換到基於車載計算平臺的軟件開發有點困難。
作者簡介：朱玉龍，資深電動汽車三電系統和汽車電子工程師，著有《汽車電子硬件設計》。
圖｜朱玉龍 網絡及相關截圖
