最近大眾CEO的一些想法很激進，通過媒體透露，未來是和現在完全不一樣的，在邁向電動汽車的過程中，汽車電子和車內線束的變化可能真是翻天覆地（城門失火，殃及池魚）。

在德國沃爾夫斯堡大眾集團12日的總部年度媒體會上，大眾汽車CEO Herbert Diess表示，大眾的汽車電子系統正在從分布式向集中式處理方式轉換，計劃將ECU（車載控制單元）功能集成起來，最終實現系統模塊數量級的減少，核心架構從當前數十個甚至上百個控制單元減少到三到五個車載中央處理器。 以新高爾夫為例，需要用到200多個供應商提供的70個控制單元，如果減少到3到5個中央處理器，如果面向自動駕駛開發，原有的架構系統根本無法滿足要求。

Volkswagen plans to improve its software’s robustness by reducing its cars’ 70 electronic control units “to three or four central on-board computers”. Herbert Diess announced restructure its software operations achieved by “taking over suppliers that in the past have delivered software to us”Automotive 《VW Cutting ECUs From 70 to “3 or 4”》

Diss有關軟件方面的介紹有下面三頁：

這一頁，我們也可以思考下，為什么汽車里面代碼這么多？如果把70個ECU的底層代碼、應用層軟件進行統計，如果合并整合成為10個ECU，大量的通信消失了，大量的底層代碼可以被share了。

這一頁，是對比從之前的MQB平臺往MEB平臺的結構化的轉換。說白了之前的功能軟件的附加值對于車企來說比較低，而隨著VW.OS提出，使得軟件的事情隨著ICAS車內服務控制器的導入，讓供應商的工作回到了大眾的手里。

備注：這一頁是非常抽象的，在MEB的架構里面還有大量基于CANFD的從MQB演進過來的ECU，但是未來的MEB+呢，未來MEB架構推進到原有燃油車和插電的架構呢，這個變化就持續減少了

按照下面的說法，軟件化的過程是逐步進行的，合作、收購、招人，開發In-house的軟件能力和知識產權。

在這個里面，我們核心聚焦到大眾所探討的ICAS的軟件開發過程

從大的劃分來說，In-Car Application Server（ICAS）里面

是否包含原有安全的功能？有關電機的控制、電池的管理，還有底盤原有涉及安全的功能是否會拉進去

應用層的軟件，是否完全自己開發？

基于ICAS里面原有Autosar Classic的部分和Autosar Adaptive的部分，是否都是自己In-house來操刀？

從目前的基于Autosar經典平臺開發的汽車控制器來說，大量的軟件工作都是供應商完成的，它的特點也是很清楚的，是面向特定實時性功能（硬實時，MCU根據軟件任務來選、系統對RAM或Flash等資源具有較低的占用率），供應商會開發一個全的版本軟件，基于功能固化之后，動態變更跟不上車企的要求。如果大眾確定要把這塊也全面接盤的話，確實只有少數的供應商能夠存在自身長期發展的價值。

基于Adapative Autosar方面，一個是供應商沒法完全提供足夠的東西給大眾，相信做VW API里面也要涉及大量的工作。

備注：我估計這事也是分階段的，項目管理先上，最終這部分除了面向第三方軟件的應用，其他都是內部體系獨立開發。這里大眾和Vector的工作分工，還有后者對外能輸出的內容尚不得而知。

小結：大眾比福特提出的軟件定義汽車，因為有著MEB的投入，還有MEB的架構開發，VW OS的導入，我們能看到這些東西影響著我們。甚至我們對比通用的Global B的開發還有一系列對應的動作，這些都是對等的都是邁開步子去做出改變，切切實實讓我們看到了這個行業未來的變化。