MEB新一代的汽車電子架構展望

接前文如何看待電動汽車電子架構的發展？，本文主要包括以下的內容：

• 服務為導向的軟體架構
• 網路通信
• 功能分配
• 開發模式
• 控制器硬體

1）服務為導向的軟體架構

為了面對個性化的需求，功能軟體開發需要更敏捷，而基於此Service oriented Architecture (SOA)是完成這項任務的關鍵，它能夠建立動態的實時網路通信關係，把車內各個IP節點根據功能要求進行應用層服務的數據建立交互。

圖 SOA 架構與服務分布

在AUTOSAR中基於TCP/UDP之上定義了SOME/IP通信模塊能夠支持SOA架構通信的需要，當然在AUTOSAR標準中SOME/IP也是逐步部署的。

可參考http://some-ip.com 對SOME/IP的roadmap的介紹

• AUTOSAR 4.0 – basic support for SOME/IP messages already existing.
• AUTOSAR 4.1 – support for SOME/IP-SD and Publish/Subscribe was added.
• AUTOSAR 4.2 –the transformer was added for serialization as well as other optimizations.
• AUTOSAR 4.3 – fixing some transformer bugs, adding support for large UDP messages with SOME/IP-TP as well as SOME/IP-SD optimizations.

在自動駕駛領域內，尤其是在高階自動駕駛場景中，數據交互量要求巨大，未來基於SOME/IP構建大數據傳輸還有待驗證，至少從Audi zFAS上看到並未採用SOME/IP作為其中間件，在確定性網路內需要動態組網應用場景還比較少，但是考慮未來功能升級需求，還是需要研究實現大規模數據傳輸的組網協議。

2）網路通信 車內網路指的是IVN （In Vehicle Network）

V2X/V2V需要與國家，地區通信基礎設施規劃同步，且DSRC非國內主流，暫時沒有太多關注

國內的5G部署速度會很快，所以考慮V2X的場景還是結合中國自身情況

對於MEB這樣的真正的網路開發需要包含更多的實際設計要求：

• 100BaseT1與1000BaseT1的標準化使得乙太網已作為主幹網路的首選，而且整車需要增加冗餘設計；
• 基於AVB/TSN乙太網通信規範將成為網路核心底層協議；
• 確定性網路數據調度設計，保證控制系統時延要求；

CAN到現在還是車輛內部主要網路通信技術的主要原因就是能夠滿足控制功能的時間延遲，信號優先順序搶佔等要求；在現有整車電子架構框架下的網路信號路由需求也可以由通信核心的網關實現，當然在一些中高檔車上已經有MOST/FlexRay子網，Ethernet主要應用於DoIP與AVB。

備註：FlexRay這個東西能堅持多久，滲透多大範圍不樂觀。

不久的將來TSN能夠把傳統乙太網改造成與CAN類似的具有優先順序搶佔功能網路匯流排技術，同時基於控制功能信號流需求，實現硬體級的網路調度設計。硬體層面參考如下圖所示,軟體層面AUTOSAR也在逐步發布，但是核心的信號基於時間觸發的調度設計需要由軟體協議棧確保Worst Case場景下的時延滿足功能（應用）軟體需求，在現有乙太網案例中都有TTTech的身影，後續從OEM核心利益出發這塊的設計包括軟體開發應該會由自己來掌握。

更多TSN標準的信息可以訪問以下網站：https://1.ieee802.org/tsn/

以下這張是NXP乙太網網關晶元選項表，可以看到大的車企對晶元供應商的要求有哪些。當然業界還有一家在車載乙太網加速布局, 可以看到TSN基本協議在MAC/PHY中已經部分實現。

圖 NXP乙太網晶元 摘自 http://www.nxp.com

圖 Maverll乙太網晶元 摘自 http://www.marvell.com

在某些材料上，未來在某些應用中規劃10G帶寬傳輸。按照現在的車載乙太網標準時間表，很難在2020年實現車規級的規範發布，而且底層的線束需要從UTP/STP切換成光纖，另外隨著帶寬提高對於主晶元的緩存/內存讀寫能力要求將大大提高，看到Intel Go平台已經把PCIe匯流排也加入進來，汽車電子發展真的是太快了！！！

圖 Intel自動駕駛平台系統結構圖(包含主要匯流排技術）

3）功能分配

域控制器因為有強大的硬體計算能力與豐富的軟體介面支持，使得更多核心功能模塊集中於域控制器內，系統功能集成度大大提高，這樣對於功能的感知與執行的硬體要求降低，加之數據交互的介面標準化/網路化，會讓這些零部件變成標準零件，從而降低這部分零部件開發/製造成本。簡而言之，外圍零件只關注本身基本功能，而中央（域）控制器關注系統級功能實現。

圖 大眾MEB ICAS軟體功能規劃策略 摘自 Vector Congress 2016

由於大眾一向是分散式系統模塊化的倡導者，以後哪些ECU合併，演算法合併還有哪些功能簡化降級，在接下來的信息發布過程中非常值得關注

4）開發模式

上層應用程序可能來自不同的供應商，那麼軟體開發流程以及後期的集成測試驗證也會帶來更大的挑戰，傳統的供應商與OEM的合作模式已經發生變化，Tier1不再是大包大攬，OEM以及第三方軟體供應商會更多參與進來，如果硬體開發由另外的合作方負責，那麼後續的軟體/系統集成將是一個非常複雜的工作。作為最終的負責方，OEM在系統開發中會擔當越來越重要的角色，未來的成功將來自於全產業鏈的核心技術整合

軟體的開發計劃與硬體的開發計劃相互獨立，軟體將會是全生命周期內迭代持續，且軟體可能橫跨更多不同硬體設備。而以往的開發都是以零件SOP節點作為軟體開發計劃的參考時間，同時硬體方案是同步確定的。

未來隱藏在這個電動平台下面的軟體整合工作，值得期待。

5）控制器硬體

傳統主控制器主要還是基於32位Tricore,PowerPC以及850等架構的微處理器, 而對於海量計算,高速數據傳輸,傳統架構體系已經無法滿足上述應用需求,這也是為什麼新架構內核晶元在積極進入汽車電子行業,

可以看看這兩家最新的車載晶元都從已有的晶元平台往ARM上轉移

https://www.nxp.com/products/automotive-products:MC_50802?tid=sbmenu#MCUMPU

https://www2.renesas.cn/zh-cn/products/automotive-lsis/r-car.html

對於Machine Learning, Deep Learning等技術在自動駕駛的場景的應用, 需要提供額外的軟硬體支持.這也是為什麼AI晶元,GPU等非汽車行業的計算硬體在汽車行業內受到重視.未來對於域控制器內部的硬體必定要根據功能安全等級劃分為Performance,Safety等不同類型的功能,根據不同類型的功能分配進入不同功能安全支持的晶元內.從現有控制器硬體架構看多顆/多核晶元以及冗餘架構是域控制器設計主流設計， 雖然MEB還沒有提供官方硬體控制器信息,但是借鑒Audi zFAS自動駕駛控制器ZFAS,未來域控制器只會在此基礎上增加更多高性能，可靠性的設計。

結束語

數字生活在國內已經由"互聯網+"，"共享經濟"的風口下比歐美髮到國家領先了許多，但是汽車行業也正乘著這股熱潮藉由各種題材來展現美好的前景。圍繞個人的數字化應用入口已經由幾家互聯網巨頭所把控，新的公司想成為其中一極越發困難。而在個人數字生活中由一件硬體與兩個賬號是至關重要的，手機+微信/支付寶。國內大部分人的數字生活有這3樣東西構建，剩下的服務或者工具都可以在3樣東西下授權與操控。所以不知道MEB來到國內如何定位自己的數字生活中的角色。

對於手機行業，下面是2007年與2017年全球銷量前5排行榜，在智能化以及中國品牌崛起的10年間原來4位領跑者已經退出了。那麼汽車行業的洗牌是否也在這股電動化，智能化風潮中已經到來？

2007年全球銷量2017年全球銷量諾基亞三星 摩托羅拉蘋果三星華為索愛OPPOLG小米