01三個視頻折射的東西

1）HUD 視頻：這個視頻折射的是大眾的 HUD 的特性，顯示的信息很多，把大量有關 ADAS 交互的信息配合著內部的燈光一起作為和車主的交互

2） 座艙的顯示：以中控屏為核心（雖然這個屏不是很大），是大眾 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 從信號到服務，我們要刷新認知

02 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 的汽車軟件工程師，想要轉換到基于車載計算平臺的軟件開發有點困難。

編輯：hfy