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

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

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有關(guān)軟件方面的介紹有下面三頁：

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

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

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

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

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

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

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

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

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

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

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

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

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