大眾“MEB平台”與“軟體驅動的企業”： - 汽車

寫在前面：

這篇文章是對岸一位汽車電子工程師"冷酷的冬瓜"寫的文章的其中一篇，不想
看對岸用語的、不想看對岸人寫的文章的，自己左轉離開。

這篇文章主要是整理了VW 下一代的重要電動車平台 - MEB 到底跟以往有何不
同，跟之前的MQB 等各種燃油車平台不只是硬體上電池排放位置上的差別，更
重要的是汽車的軟體架構的不同。

另外若是覺得他有寫錯或是有疑問的地方，按我以前的經驗直接留言他是會回
覆的。


==============================以下正文==============================
來源：
https://www.weibo.com/ttarticle/p/show?id=2309404455994921975927


大眾“MEB平台”與“軟件驅動的企業”：緩慢拉開的巨幕？

╭────────────────────────────────╮
│大眾“MEB平台”到底要做一個什麼事情以及“軟件驅動的企業”背後到 │
│底意味著什麼呢？ │
╰────────────────────────────────╯


提起大眾汽車，近年來的新聞報導不可謂不多，我們先來看下大眾官方的說法：
╭────────────────────────────────╮
│...大眾集團在11月17日公佈了其調整後的長期和短期計劃...經過調整 │
│的短期計劃顯示，大眾集團在2024年之前將會在電動出行、混動車型等領│
│域投資600億歐元。而其長期計劃則要求該集團在2029年前推出75款電動 │
│汽車和60款混動車型。 │
╰────────────────────────────────╯
╭────────────────────────────────╮
│大眾計劃在2029年之前售出2600萬輛純電動汽車，以及600萬輛混動汽車 │
│。其中，這2600萬輛純電動汽車中有2000萬輛將基於大眾MEB平台打造， │
│剩下的600萬輛將基於高性能平台PPE打造。 │
╰────────────────────────────────╯


針對其轉型電動化之舉，媒體也各有說法；有說“大象轉身”的、有疑問“勝
算有幾成的”、有認為“轉型之路任重道遠”的...不一而足；但是我們今天呢，
主要是想站在一個汽車電子工程師的角度、根據網絡公開的信息以及手頭的部
分資料、談談對大眾的“MEB平台”以及Diess所說的“軟件驅動的企業”的理
解。

其中，關於MEB平台（M odularer E -Antriebs- B aukasten/Modular
Electrification Toolkit，模塊化電氣化工具套件[1]），我前不久有整理一
篇“ 關於大眾MEB，你不得不知道的10件事！ ”，是官方的一手信息，大家可
以參考。

此外，我還想做下舖墊的是大眾此類決策的內在驅動力。



大眾掌舵人、CEO赫伯特·迪斯（Herbert Diess）：

https://i.imgur.com/rb0Agai.jpg
圖1.車載軟件的變化

╭─────────────────────────────────╮
│當前：每輛車100 million行代碼，例如：導航系統大約在20 million行代 │
│ 碼。 │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│未來：整車代碼量有望超過200~300 million行、L5自動駕駛車輛代碼量將 │
│ 達到1 billion行[2] │
╰─────────────────────────────────╯

https://i.imgur.com/i96hi8V.jpg
圖2.汽車將成為最複雜的聯網設備
╭─────────────────────────────────╮
│當前：功能分散、整車需要大約70個ECU、沒有自己的代碼 │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│未來：3~5個高性能的計算單元+安全相關的ECU、開發大眾自己的軟件（包 │
│ 括基礎軟件：操作系統以及其他的應用軟件） │
╰─────────────────────────────────╯

迪斯還在後續的一個採訪中具體談到：
╭─────────────────────────────────╮
│為什麼要“接管過去為我們提供軟件的供應商”？ │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│當前的車輛軟件代碼量是智能手機的10倍，一輛具備自動駕駛能力的車輛甚│
│至會是1000倍，各類ECU之間的通信交互太過複雜...在將來，軟件將占到創│
│新的90%、並且在未來的汽車中扮演重要的角色。它在汽車價值中所佔的比 │
│例越來越大。 │
╰─────────────────────────────────╯

而在談到大眾的vw.os部門時，迪斯則直接表示，
╭─────────────────────────────────╮
│大眾未來的商業模式將更像一家手機公司。 │
╰─────────────────────────────────╯



大眾汽車品牌董事會成員、vw os操刀者克里斯蒂安·森格(Christian Senger)：

https://i.imgur.com/7k3IJSp.jpg
圖3.遵循IT行業並在集團層面進行平台部署

https://i.imgur.com/WJy0NK3.jpg
圖4.敏捷型組織架構/5個產品集群和4個橫向功能構成的Car.SW Org


此外，森格在今年9月份的媒體採訪時也進一步提到，
╭─────────────────────────────────╮
│...未來1,100 多萬台車要基於同一個電子架構，也就是說將來對某一款產 │
│品推出新功能就可以為所有產品所用。 │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│未來我們將把車輛搭載集團內部開發軟件的佔比提升到60%...會減少供應商│
│數量...內部軟ﾥ騥}發部門有1 萬人團隊。 │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│將來的一個軟件架構上能支持至少1500 萬輛車，這在整個汽車行業內都將 │
│創造一個最優的成本結構...時機成熟時，把這些軟件開放給集團外的其他 │
│品牌使用會是個合乎邏輯的決定。 │
╰─────────────────────────────────╯


提煉下迪斯和森格的內容，軟件、成本、整車架構平台、IT，或許能對其內在
驅動有個大概的了解。

...


好了，下面讓我們進入正文部分，嘗試下抽絲剝繭的過程。

一、MEB平台整車電氣&軟件架構

https://i.imgur.com/Awk2qGV.jpg
圖5.一種實現可更新性和可升級性的新方法

╭─────────────────────────────────╮
│應用軟件和I/O功能解耦的、功能中心化的架構： │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│減少整個系統的複雜性和應用之間的依賴性； │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│高效、快速地開髮用戶功能； │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│提供一些用戶功能所需的基本服務； │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│採用面向服務的通信。 │
╰─────────────────────────────────╯

先解釋下：

“I/O功能”可以簡單理解為硬件Input/Output，即Local ECU；
“面向服務”的通信即車載以太網。

https://i.imgur.com/vguyMHS.jpg
圖6.基礎概念/功能集成化

╭─────────────────────────────────╮
│車輛功能集中在幾個強大的ECU中，即ICAS（In-Car Application-Server）│
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│傳感器與執行器通過強大的網絡，比如車載以太網、CAN-FD，連接到ICAS；│
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│在ICAS中使用虛擬化技術整合許多不同的功能。 │
╰─────────────────────────────────╯


那麼這兩張圖說了個什麼事情呢？我認為主要有三點，

1、分層架構的思想，包括對整車ECU的重新分類、ICAS內部的軟件架構
（ICAS下一小節說）；
2、功能的集中化；
3、虛擬化技術。

可能有人要說，還有“更先進的總線技術（CAN-FD/Ethernet）呢”？資瓷當然
是資瓷的，但是現階段作為主幹網絡投入產出比低（傳感器raw data之類的剛
需除外）。


看完這兩幅圖，有沒有一種似曾相識的感覺呢？

我們曾經在今年10月份翻譯過一篇文章未來的汽車架構以及IT的發展趨勢影響
（我太喜歡這篇文章了...）——事實上這篇文章[3]由寶馬工程師於2017年4月
在IEEE Software發表，考慮到MEB平台先期研發啟動於2015年——歐洲人的想
法還是蠻同步的，當然也少不了VECTOR“穿針引線”的功勞。

https://i.imgur.com/24ZNLmo.jpg
圖7.BMW為下一代車型創建了一個分層的E/E架構

強大的集成平台實現了汽車領域的無縫分層的E/E架構

可以看出寶馬相比大眾進行了更細的劃分，雖然沒看到大眾對Sensor/Actuator
Level以及Computer Level的詳細描述，可以參考下寶馬的，分別對應Class 4
和Class 1：

╭─────────────────────────────────╮
│中央計算平台（class 1 - 圖7的頂層）承擔主要的軟件功能，這部分主要 │
│由內部進行開發。這些平台能夠提供較高的性能並且能夠滿足最高級別的安│
│全需求。 │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│集成控制器（class 2）銜接中央計算平台和商品控制器（class 3） - 例 │
│如，實時性需求高的功能要求能夠直接訪問傳感器或者執行器。 │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│對於簡單的、OEM無特定需求的功能，由商品控制器和傳感器或者執行器（ │
│class 4）直接實現是可接受的。理想情況下，這些控制器和傳感器或者執 │
│行器是基於共同的OEM開發或者Tire 1的零部件。 │
╰─────────────────────────────────╯

PS：“商品控制器”（commodity ECU）這個詞有點內味了、是不是很有感覺~


那麼這麼做有什麼好處呢？我們這裡列舉幾條，有官方說法、有個人理解。

1、與分佈式功能相比，集中式實現的複雜性更低；
2、傳感器/執行器ECU之間沒有功能依賴；
3、傳感器/執行器和高級車輛功能的分離增加了添加新功能的靈活性(功能更新)；
4、統一的開發方式（ICAS）取代本地（分佈式的、數量巨大的ECU）開發方式；
5、集中化及虛擬化降低網絡和軟件的複雜性；
6、虛擬化則通過共享硬件資源節約成本。

詳細的MEB平台架構拓撲（概念）我們下次找機會再詳細探討。



二、MEB平台ICAS架構

首先我們同步下認識，ICAS（In-Car Application-Server，車載應用服務）我
個人更傾向於認為它是一個虛擬的概念，它的硬件載體即迪斯口中所說的“3~5
個高性能計算單元（High Performance Computer）”，這個高性能計算單元根
據車型可配置，但是搭載相同的ICAS的軟件架構，即“通用軟件框架”。

https://i.imgur.com/ZtIsiem.png
圖9.數字化的關鍵：面向服務的架構（SOA）

╭─────────────────────────────────╮
│使用服務發現和發布/訂閱的動態綁定； │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│數據表示主要基於REST（表述性狀態傳遞）-->統一接口、無狀態、關注點 │
│分離... │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│接口的前後兼容性。 │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│通過提高可更新、可升級、可複用和可移植的特性，能夠輕鬆地通過即插即│
│用的方式部署新功能。 │
╰─────────────────────────────────╯

https://i.imgur.com/BIbGEtz.png
圖10.基於AP（Adaptive Autosar，Adaptive Platform）的通用軟件框架

╭─────────────────────────────────╮
│一個通用的軟件框架能夠帶來： │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│用戶功能/基礎服務能夠獨立於ICAS和操作系統並行開發； │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│統一的方法論以及數據交換格式； │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│統一的更新以及通信協議。 │
╰─────────────────────────────────╯

https://i.imgur.com/dcY5aS2.jpg
圖11.MEB平台ICAS架構

ICAS：In-Car Application-Server，車載應用服務
...

我給大家提煉下關鍵詞：面向服務的架構（SOA）、CP（Classic AUTOSAR）、
AP（Adaptive AUTOSAR）、通用軟件框架...

我們先來看下ICAS的三層：通信服務層、基礎服務層、應用服務層。沒錯，我
又要祭出寶馬下一代的E/E規劃了。

https://i.imgur.com/T5NKzzs.jpg
圖12.BMW在下一代E/E架構中引入的中央通信服務以及SOA的解決方案

為了方便大家理解，我做了一個對比表格：
https://i.imgur.com/IsBUQ2q.png


下面我們再來依次看下，

1、面向服務的架構（Service Oriented Architecture，SOA）

直接貼上之前整理的材料吧，主要參考了偉哥的"汽車上為什麼非要用SOA？"。
https://i.imgur.com/CrjMJjU.jpg
https://i.imgur.com/ZjFZv1v.jpg
https://i.imgur.com/0HyKT8M.png

2、Classic AUTOSAR/Adaptive AUTOSAR

...做軟件工程師時有翻譯過AUTOSAR的標準（但是理解不深笑cry），現在想
想、距離上一次敲代碼7年過去了...市場急需一個強有力的推手啊。

...

那麼，大眾“MEB平台”到底要做一個什麼事情以及“軟件驅動的企業”背後到
底意味著什麼呢？答案也就逐漸明朗：一個全新的、足夠先進（可升級性、可
擴展性、可複用性以及可移植性）的汽車電氣架構，基於CP/AP的通用軟件框架、
採用SOA的軟件設計方法論並開發完整的軟件開發工具鏈；按照集中式的原則重
新進行功能分配、逐步接管供應商軟件並開發大眾自己的軟件——包括操作系
統及其他應用軟件；出於成本考量在合適時機向競爭對手兜售該軟件套件。

我的眼前彷彿浮現了一個龐然大物、趴在桌子上伸出了觸角，吆喝著周圍的玩
家跟進。

...

與此同時，就在我們整理這篇文章的期間，關於大眾MEB也接收到了各種不同的
聲音：

一種是“大眾大肆宣揚電氣化改革就是個幌子、一切都是為了股價”；

一種是“大眾內部阻力重重、軟件人才匱乏、轉型之路任重道遠”；


當然，當然看到媒體報導說大眾正在解決大量軟件問題時、第一時間查證了德
國Manager Magazin的源報導並進行了翻譯Manager Magazin：大眾汽車正在努
力解決ID.3的大量軟件問題 ...老實講如果此次手動升級之後就能夠OTA，那進
度還是可以的。謹慎樂觀。

...

誠然，龐然如大眾緩慢推開了電動化轉型的巨幕，而對於傳統車企來說，
“軟件定義汽車”的征程，一切都才剛剛開始。

最後，特斯拉牛逼！


[1]Wikipedia.Volkswagen Group MEB platform.Wikipedia,2019.11.13
[2]Volkswagen .Volkswagen.com.
[3]MTraub.Future Automotive Architecture and the Impact of IT Trends.
IEEE Software,2017,34 (3) :4

--
https://i.imgur.com/xHFddLR.jpg

--