導讀：近年來，汽車電子電控部分域控化已然從個別前瞻項目變成所有主機廠努力踐行的方向。為什么現(xiàn)在可以提域控乃至中央計算平臺的概念？什么樣的功能可以域控？未來有哪些可能的路要走？本文將結(jié)合個人多年在汽車行業(yè)的開發(fā)經(jīng)歷，試圖對電子電氣域控的演進過程進行深度梳理。

?

一、為什么可以域控

汽車電子電控，無論什么類型，究其本質(zhì)都可以表達一個簡單的控制系統(tǒng)模型：“傳感獲取輸入 =>?處理計算 =>?驅(qū)動執(zhí)行器輸出”。

在以往汽車電子的MCU嵌入式環(huán)境中，輸入、處理計算和輸出是一體的，同一塊ECU板子既做信號采集，又做邏輯運算，最后再驅(qū)動執(zhí)行，如此形成閉環(huán)。

大多數(shù)情況下，ECU與被驅(qū)動的零件在物理上就被包在同一個殼體里，供貨時的零件狀態(tài)既包括了例如齒輪結(jié)構(gòu)這些機電結(jié)構(gòu)部分，也包括了芯片和PCB這些承載著軟件算法的部分，軟硬件二者一體同型，不可分割。

而裝到車上后，整車廠負責的是整個系統(tǒng)接口集成和功能打通，彼此之間的接口配合關(guān)系在開發(fā)過程中就已經(jīng)相對固化（例如CAN信號矩陣）。此狀態(tài)下，各ECU以管好自己的零件為主要任務(wù)目的，彼此是否能在整車層面靈活協(xié)同在功能上玩出花樣來，倒在其次。或者說即便有此心，實踐起來的變更難度也很大。整車的電子電氣框架，在項目開發(fā)到中期基本就處于焊死的狀態(tài)，任何變更都可能勞師動眾。

上述是傳統(tǒng)狀態(tài)，車作為一個復雜的大工業(yè)品，首要的是精密配合長期穩(wěn)定工作，在理念上就沒有把能靈活變更放在首要考慮上，包括電子電控部分。

域控的概念，或者再進一步中央計算平臺的概念，實質(zhì)上都是在做一件事，就是把前述的三個過程切割開，把其中邏輯處理計算的部分分離開并集中。

要做到能夠把邏輯分離并且集中，需要以下幾個前提條件：

1.?核心處理芯片升級，由MCU/MPU/SoC，計算能力大幅提升；

2.車載以太網(wǎng)應(yīng)用支持了高速實時和大數(shù)據(jù)量的信息傳輸能力；

3.大數(shù)據(jù)量的傳輸能力，進一步支撐了面向服務(wù)的中間件軟件架構(gòu)。

處理器能力攀升

以動力域為主線來舉例，動力域的控制系統(tǒng)其邏輯復雜度在傳統(tǒng)汽車電子中屬于比較高了，目前都是32位浮點處理器。此外車上其它應(yīng)用還存在著不少8位、16位的單片機芯片。

大概七八年前，做動力系統(tǒng)的MCU常用型號，以英飛凌的TC178x、NXP的MPC574x為例，都在200MHz以下，性能大約在1.x~2.xDMIPS/MHz水平，因此可以估計算力~400DMIPS。大量動力域和底盤域的控制器已經(jīng)可以基于這個檔位算力實施，例如EMS、VCU、BMS、EPS、ESP等，都有應(yīng)用上述MCU型號的實例。

以英飛凌為例，后來逐步升級到TC2xx。按照1.7~2.4DMIPS/MHz，200MHz，三核計算，大約算力達到了~1200DMIPS量級。數(shù)倍于此前的狀態(tài)。

近幾年又升級到TC3xx，例如TC39x已經(jīng)達到了4kDMIPS量級，又翻了數(shù)倍。

而英飛凌最新出的MPU TC4Dx達到了8kDMIPS量級。

此外，目前行業(yè)內(nèi)應(yīng)用廣泛的MPU S32G，處理器部分有4xA53+3xM7，分別按照2.3DMIPS/MHz @ 1GHz和2.14DMIPS/MHz @ 400MHz計算，其總處理算力達到了11k+DMIPS。

目前行業(yè)內(nèi)應(yīng)用廣泛的TDA4VM，處理器部分包括了2xA72和6xR5F，分別按照7.3DMIPS/MHz @ 2GHz和2.45DMIPS/MHz @ 1GHz計算，其總處理算力達到了40k+DMIPS。

再進一步到SoC，以Qualcomm為例，其后的SA85xx系列算力直奔100~200kDMIPS而去。

從MCU到SoC，CPU算力的跨度足足達到了200倍之多。

當然，MPU和SoC處理的內(nèi)容也不僅僅是嵌入式系統(tǒng)中純粹的邏輯系統(tǒng)，還包括運行復雜操作系統(tǒng)如Linux，以及配合其它協(xié)處理系統(tǒng)DSP、GPU、NPU等共同完成復雜的圖像感知和數(shù)據(jù)計算密集型算法的處理，單純?nèi)ケ人懔CU有點不公平。但總的來說，只是想表達一個觀點，就是隨著處理器能力的增強，過去的多個控制單元從算力上完全有機會放進同一個芯片中運行；換個角度，用新一代的MCU去處理傳統(tǒng)的汽車電子控制系統(tǒng)場景，即便刨除控制策略本身復雜度提升的因素，可能依然會浪費很多計算處理資源。

車載以太網(wǎng)的應(yīng)用

車載以太網(wǎng)是能實現(xiàn)域控分離的另一個重要的因素。車載應(yīng)用中，能夠?qū)崟r的交換數(shù)據(jù)是幾乎一切控制功能的基本要求。提到實時性，首先會想到AVB/TSN協(xié)議族。但這里我們先不談AVB/TSN，先算一筆基本賬。

以500kbps的CAN網(wǎng)絡(luò)為例，傳遞一幀8字節(jié)的報文需要大約216us（理論值，實際值會略高250~300us），理論傳輸效率 27us/Byte。類似地，按照百兆以太網(wǎng)100Mbps帶寬，一幀報文~1500Bytes大約需要花費120us傳輸（理論值，實際取決于網(wǎng)絡(luò)狀態(tài)和幀間延時等），理論傳輸效率為0.08us/Byte。二者相比，一來一回相差了足足200倍。

正是這200倍的裕量，進一步為AVB/TSN等協(xié)議族提供了足夠施展的空間。

面向服務(wù)的通訊中間件設(shè)計

正是CAN到以太網(wǎng)這種基于物理通訊手段的量級提升，使得信息的傳遞具備更靈活的可能性。面向服務(wù)只是一種工程思考方式，嚴格來說并不是汽車里的新物種。傳統(tǒng)的診斷服務(wù)協(xié)議UDS就是一種面向服務(wù)的思維，但即使用多幀，實時傳輸?shù)臄?shù)據(jù)量也僅限于數(shù)十個字節(jié)（不考慮刷寫的大包多幀）。但是基于以太網(wǎng)帶來的通訊效率的量級提升，使得通訊中間件有了新的可能性。

靈活和效率是一對相互制衡的屬性，采用面向服務(wù)的架構(gòu)具備靈活易插拔的能力，但同時會產(chǎn)生額外的協(xié)議開銷（Overhead），例如包括服務(wù)發(fā)現(xiàn)、握手、QoS信息的額外傳遞，本質(zhì)上是信息熵的編碼效率降低。

面向服務(wù)化后，可能會出現(xiàn)同樣的信號被打包在不同服務(wù)報文里多次發(fā)送，或同樣的報文被不同消費者多次消費，相比例如基于CAN信號的傳輸都屬于冗余。好在物理通訊效率的提升為信息的冗余提供了足夠?qū)掗煹目臻g。當進一步升級到千兆以太網(wǎng)，傳統(tǒng)汽車通信網(wǎng)絡(luò)里的有效負載信息量需要占用的帶寬幾乎可以忽略，反而是冗余和協(xié)議開銷占據(jù)了主要部分。

正因信息服務(wù)化提供了靈活的服務(wù)配置，以及節(jié)點熱插拔、功能動態(tài)配置等能力，使得整車內(nèi)不同控制節(jié)點間功能的協(xié)同和組合變成可能，進而開發(fā)出多種多樣的整車功能，并且隨著時間變化易于調(diào)整和升級。

二、什么樣的功能可以域控

車輛控制功能的五域模型

按車輛的功能劃分域，考慮可以把域內(nèi)的功能集中在一起。例如，底盤域、動力域、車身域，以及隨著近年來汽車智能化而逐步成型的座艙域、智駕域。上述五域模型是目前比較通用的域控架構(gòu)概念。

那么接下來，在往域控邁進以至進一步向中央計算平臺邁進的過程中，是不是所有的功能都可以被上移到高性能芯片中，答案似乎也不盡然。換言之哪些功能是可以被挪進去，哪些不能，需要進行考量。

車輛控制的時間尺度

用一張圖來整理思路，沿橫軸方向是時間尺度，上面羅列出了一些汽車電子控制器所處于的位置。

首先，從大的思路上，我認為應(yīng)該建立全時間尺度的概念。車輛作為一個系統(tǒng)，具備各種各樣不同時間尺度的功能要素，跨度很大。其中，就每個時間尺度上分別舉例說明：

100us量級：屬于超快速計算的場景。例如發(fā)動機管理系統(tǒng)中的噴油點火正時，必須嚴格根據(jù)曲軸齒的位置判斷，在6000rpm高速旋轉(zhuǎn)時，齒齒間的時間不過100us量級；再如電機矢量控制，高轉(zhuǎn)速可達到15000rpm，此時留給每次旋變位置解碼和矢量控制的計算窗口只有50~100us量級。這種情況受物理因素限制，做不到系統(tǒng)無法被有效控制。

1ms量級：快速計算場景。這在嵌入式系統(tǒng)中也算比較快的計算步長了。典型的場景，例如底盤電子中ESC的電磁閥控制，變速箱系統(tǒng)中的電磁閥控制，發(fā)動機管理系統(tǒng)中的節(jié)氣門控制，基本也都是受被控對象的物理特性要求，必須以快速響應(yīng)才能獲得好的控制效果。

10ms量級：大量控制系統(tǒng)會工作在這個時間尺度下，典型的例如VCU、BMS、BCM等等。另外包括EMS、MCU、ESP等控制器中的邏輯控制部分，也會放在這個時間步長下工作。

100ms量級：對實時性低一點的嵌入式控制系統(tǒng)可以放在此時間步長下工作，例如BCM中的座椅、天窗、燈光等，以及空調(diào)和熱管理系統(tǒng)等。另外，ADAS中的感知規(guī)劃目前也會工作在這個時間尺度下，但這某種程度上也是不得已而為之，因為即便在高算力SoC上，要完整處理完一套感知融合算法，也需要這么長的時間。

1s/10s量級：對于傳統(tǒng)汽車電子系統(tǒng)，這個時間偏慢了。仍有一些功能可以在這個步長下運行，例如BMS中計算健康狀態(tài)或一些滯回特性，或者混動系統(tǒng)中計算一些能量平衡狀態(tài)等，都是變化較緩慢的行為，并不需要用很快的頻率去計算更新狀態(tài)。

Minutes/Hours量級：在傳統(tǒng)汽車電子系統(tǒng)中用這個步長進行運算的場景就不多了，在這個時間尺度下，信息開始逐步依賴于車云之間的遠程通訊鏈路來獲取信息。

基于時間尺度的功能集中

重新審視上面的圖，有以下幾點想法：

1.?在時間尺度上落在兩根紅線中間部分的功能，即控制步長在5ms~100s的功能，都可以域控集中化。這部分軟件可以從原有的控制器中拿出來，重新放進一個集中的域控制器或者車載中央計算平臺中。

2.?而與被控對象驅(qū)動密切相關(guān)，需要快速運算的，則仍與被控對象的物理硬件綁定；此外，某些傳感器信號對長距離傳輸?shù)脑肼暶舾?，也不能遠離物理硬件。

3.?當計算時間尺度增加需要緩存記錄較長時間的數(shù)據(jù)才能計算出有效信息，而對實時性要求不高的，則可以考慮挪到云端去執(zhí)行。

重點談一下第1點：

車身域和座艙娛樂域相關(guān)的功能，因為對實時性和安全性相對敏感性低一些，把它們域控化似乎已經(jīng)比較能夠被接受。

但這里想說的是，包括一般認為需要強實時性和安全性保證的動力域和底盤域的大部分功能，同樣可以如此。對動力和底盤域控制功能域控，最擔心的風險是實時性可能不夠，無法及時完成控制閉環(huán)，尤其當功能與安全相關(guān)時尤其顯得不可靠。

實時控制的拆解分析

我們這樣來考慮這個問題，假設(shè)某個動力域或底盤域里的控制閉環(huán)以5ms為步長，且不依賴于外部的通訊例如CAN（即不會因為通訊鏈路引入額外的延遲）。在5ms內(nèi)，它需要完成A-獲取傳感器信息；B-邏輯處理運算；C-驅(qū)動被控對象三個步驟，如上圖左。

然后，當把控制功能上移之后，其核心邏輯處理運算功能轉(zhuǎn)移到了域控或中央控制器中。相應(yīng)地，增加了B1和B2兩項通信開銷。即變成了A-獲取傳感器信息；B0-邊緣處理；B1-發(fā)送信息；B-邏輯處理運算；B2-接收信息；C-驅(qū)動被控對象五個步驟，如上圖右。

不僅僅多了B1和B2兩個通信步驟，以及相應(yīng)網(wǎng)絡(luò)擁塞產(chǎn)生的延時風險，另一方面由于域控制器上可能跑的是Linux這種復雜操作系統(tǒng)，步驟B的任務(wù)調(diào)度也可能產(chǎn)生延時。實事求是地說這些可能性都存在，但我們繼續(xù)求證量化分析一下。

1.?以太網(wǎng)通信過程B1/B2：對于結(jié)構(gòu)簡單Hop數(shù)不超過3的車載以太網(wǎng)，在TSN加持下可以做到延遲最差數(shù)百us量級。加上本身的發(fā)送時間120us，一來一回總共可以估算為1ms。

2.?邏輯計算任務(wù)B：

（1）任務(wù)調(diào)度：對于加了PREEMPT_RT實時性補丁的Real-Time Linux來說，通常延遲在100us量級，最差情況可以控制在1ms量級。

（2）計算時間：原本MCU的5ms不可能用滿，算4ms，在高性能處理器加持下可以減半估為2ms。

3.?負責收發(fā)代理的區(qū)域/邊緣的簡化處理器B0，不再承擔邏輯計算任務(wù)，可以設(shè)為1ms運行。

加起來，上述過程一共用了4ms，而且留了余量，實際情況會比這個更短。

必須說明的是，實際場景中會有中斷響應(yīng)、調(diào)度、阻塞、資源鎖、優(yōu)先級等等實際問題要妥善解決，以上采用第一性的簡化模型進行討論。

此外，電子控制邏輯中本身也具備相當多的進一步寬容時間限制的可能性。

退一步講，任務(wù)本身對偶爾的時間延時也具備容忍能力，5ms為基準上下抖動幾個ms也是原本的設(shè)計就要考慮的因素，再說做故障診斷時也需要多個周期確認。

再退一步講，大部分控制器需要的步長可能在10ms乃至100ms都能夠接受，在這種時間裕度下，將更加輕松。

再再退一步講，如果是多個控制器形成的控制閉環(huán)，原本除了本身的計算步長也還要額外加上例如CAN收發(fā)的通訊延時，這又提供了時間裕度。

因此，對于車上的大多數(shù)控制功能來說，搬移到一個集中的域控/中央運算環(huán)境中，是完全可行的。

車云一體視角

從上面時間尺度的分析還有另一點需要特別指出，就是對其中單個的控制系統(tǒng)而言，它的時間尺度也可以具備很大的跨度，這一點是在無線通信和云端數(shù)據(jù)存儲處理技術(shù)成熟并且成本足夠低的情況下，在汽車上面催生的智能網(wǎng)聯(lián)新需求。

傳統(tǒng)汽車上基本沒有連接的概念，每個控制器是自己處理自己系統(tǒng)的事情?？梢哉f鐵盒一關(guān)，不知今夕是何年，亦不知世界為何。只要上電，就在自己的封閉系統(tǒng)里傳感-邏輯-執(zhí)行，如此往復數(shù)十年。

在傳統(tǒng)嵌入式系統(tǒng)里，運算資源和存儲資源都非常有限，幾乎不可能做長時間尺度的事情（這可能需要緩存很多的中間數(shù)據(jù)處理）；另外，也看不到其它的同款車型的平均狀態(tài)，所以即使本車的某些特征已經(jīng)明顯出現(xiàn)離群的異常，在本車也沒有任何手段可以辨別。但這種需求是并非不存在，只是在傳統(tǒng)嵌入式系統(tǒng)中沒有條件實現(xiàn)，就被接受為常態(tài)了。

隨著無線通信技術(shù)的進步和云端數(shù)據(jù)存儲處理技術(shù)進步，汽車智能網(wǎng)聯(lián)化已經(jīng)來到近前。在這種情況下，換一個視角，車輛的很多控制系統(tǒng)都可以拓展到云端，只有將車端和云端合在一起，才構(gòu)成一個真正完整的控制系統(tǒng)，能夠覆蓋到這個系統(tǒng)中不同時間尺度的控制需求。

需要說明的是，這種視角跟目前一些車企建立一個云端平臺，其中進行一些數(shù)據(jù)存儲、統(tǒng)計和可視化不是一個概念（如下圖左）。這里更強調(diào)的是從單個控制系統(tǒng)的角度，把本地的控制單元與云端的控制邏輯視同成一個系統(tǒng)，前者分別負責實時控制和數(shù)據(jù)處理，后者則負責慢時間尺度但時間空間大數(shù)據(jù)量處理的任務(wù)（如下圖右）。

對車云一體需求特別強烈的系統(tǒng)，包括電池管理系統(tǒng)BMS（電池狀態(tài)辨識）、座艙系統(tǒng)（駕駛員習慣風格辨識）、動力系統(tǒng)（駕駛風格，混動能量平衡等）。

三、未來可能的路

應(yīng)用進程化

在集中化的狀態(tài)下，基于復雜操作系統(tǒng)來運行，不管是宏內(nèi)核（例如Linux）還是微內(nèi)核（例如QNX），原有嵌入式環(huán)境中的邏輯控制程序，可以變化為一個或多個進程來，依靠操作系統(tǒng)的實時性調(diào)度來運行。如前所述，這種設(shè)計對大部分控制場景是有可行性的。

逐步過渡向集中

從實際行業(yè)趨勢上來說，可能會由座艙娛樂、車身類的功能，逐漸過渡到底盤、動力類的功能。這是由其性質(zhì)決定，畢竟對于高風險同時又性能要求高的應(yīng)用，工程師會基于風險厭惡的本能先從容易的部分著手。

但自動駕駛域可能有點特殊，作為一個跟動力和底盤線控密切配合且安全相關(guān)的系統(tǒng)，理想情況它的整體計算邏輯流能像VCU一樣10ms更新一次（跟著系統(tǒng)中最快的IMU頻率跑）最好。但這個速度不是不為也，而是不能也，目前的算力滿足不了這個要求（這也是輝羲要解決的目標）。感知、融合、定位、規(guī)劃等算法模塊都可能是“數(shù)據(jù)密集”+“計算密集”的狀態(tài)，計算強度的要求相對傳統(tǒng)邏輯控制為主的算法飆升，10ms算不完。實際的計算流由攝像頭的幀率觸發(fā)，30FPS就是33ms算一幀，而要完成一個從感知到控制的完整閉環(huán)，整個鏈路要達到100ms以上。所以自動駕駛除規(guī)控外的主體部分，從誕生之日起就沒在MCU上跑過，雖然從實時性需求角度它更可比擬一個MCU上的應(yīng)用。

此外，還有很多歷史的包袱，例如ESP等底盤件，它的軟件成熟不僅僅依靠工程師的專業(yè)know-how和開發(fā)能力，更依賴于專業(yè)試驗環(huán)境、大量產(chǎn)品驗證甚至事故教訓才逐步打磨出來。除非能整體移植，否則似乎很難具備量產(chǎn)級的質(zhì)量說服力。

所以總體上，飯是一口口的吃，由局部到整體逐漸納入更多的車輛控制功能，逐步由局部的域控走向整體的車載中央計算單元。而更宏觀地把車云一體納入來看，在車上的“車載中央計算單元”，在整體上也可以定位成“邊緣計算服務(wù)器”，而云端的超強算力和數(shù)據(jù)存儲能力則成為“計算中心”。

車+云二位一體的狀態(tài)，覆蓋到從實時性到長周期各種時間尺度的特征，構(gòu)成完整的控制系統(tǒng)。

虛擬化

破局之道可能在于虛擬化能力的不斷提升。按目前的認知把虛擬化分幾個段位，純軟件的虛擬化 >> 硬件支持的CPU虛擬化 >> GPU/NPU/...的虛擬化 >> 硬件支持下的多容器虛擬化。

一個控制功能要起作用，會用到多方面的資源，包括CPU、RAM、IO、Ethernet/CAN等通訊、SD/eMMC/UFS存儲，以及可能更復雜一點的NPU、GPU、Display、PCIe、MIPI-CSI、ISP等等資源。

虛擬化程度提升的過程，實際上就是根據(jù)不同的場景要求，實現(xiàn)不同層級的資源共享與隔離的過程?？梢钥紤]到的是，從Baremetal開始，到Hypervisor，再到操作系統(tǒng)的內(nèi)核、cgroup、進程、線程、協(xié)程，結(jié)合硬件的虛擬化支持，每一層具備不同能力的資源分配和隔離以及相應(yīng)的性能開銷，從而適合不同的場景。

未來可能的方向：

首先，是具有高性能計算能力的芯片。

其次，不同層級的車載軟件基礎(chǔ)架構(gòu)發(fā)展成熟。

然后，根據(jù)整車控制功能的性質(zhì)（例如實時性和隔離性的要求），就可以部署在相應(yīng)的層級。

這時候汽車可能真的變成了既是一個大工業(yè)品，也是一個消費電子終端的形態(tài)?，F(xiàn)在在手機平板上能實現(xiàn)的功能，加上汽車自身特性延伸開的功能，都會集中在這個產(chǎn)品上。

?

本文尚有很多細節(jié)未及展開討論，而更多在談?wù)摰氖墙K局理想形態(tài)。在今天域控技術(shù)進步日新月異的背景下，無數(shù)工程師對各種具體工程難題的逐個解決，才是推動行業(yè)進步最堅實的動力。

參考

[1] George K. Adam, "Real-Time Performance and Response Latency Measurements of Linux Kernels on Single-Board Computers"

[2] Michael M. Madden, "Challenges Using Linux as a Real-Time Operating System"

[3] Federico Reghenzani, Giuseppe Massari, and William Fornaciari, "The Real-Time Linux Kernel: A Survey on PREEMPT_RT"

[4] Pekka Varis, Thomas Leyrer, "Time-sensitive networking ?for industrial automation"

[5]?https://www.curtisswrightds.com/sites/default/files/2021-10/Latency-Understanding-Delays-in-Embedded-Networks-white-paper.pdf

編輯：黃飛