電子發燒友App
導讀：近年來，汽車電子電控部分域控化已然從個別前瞻項目變成所有主機廠努力踐行的方向。為什么現在可以提域控乃至中央計算平臺的概念？什么樣的功能可以域控？未來有哪些可能的路要走？本文將結合個人多年在汽車行業的開發經歷，試圖對電子電氣域控的演進過程進行深度梳理。
?
一、為什么可以域控
汽車電子電控，無論什么類型，究其本質都可以表達一個簡單的控制系統模型：“傳感獲取輸入 =>?處理計算 =>?驅動執行器輸出”。
在以往汽車電子的MCU嵌入式環境中，輸入、處理計算和輸出是一體的，同一塊ECU板子既做信號采集，又做邏輯運算，最后再驅動執行，如此形成閉環。
大多數情況下，ECU與被驅動的零件在物理上就被包在同一個殼體里，供貨時的零件狀態既包括了例如齒輪結構這些機電結構部分，也包括了芯片和PCB這些承載著軟件算法的部分，軟硬件二者一體同型，不可分割。
而裝到車上后，整車廠負責的是整個系統接口集成和功能打通，彼此之間的接口配合關系在開發過程中就已經相對固化（例如CAN信號矩陣）。此狀態下，各ECU以管好自己的零件為主要任務目的，彼此是否能在整車層面靈活協同在功能上玩出花樣來，倒在其次。或者說即便有此心，實踐起來的變更難度也很大。整車的電子電氣框架，在項目開發到中期基本就處于焊死的狀態，任何變更都可能勞師動眾。
上述是傳統狀態，車作為一個復雜的大工業品，首要的是精密配合長期穩定工作，在理念上就沒有把能靈活變更放在首要考慮上，包括電子電控部分。
域控的概念，或者再進一步中央計算平臺的概念，實質上都是在做一件事，就是把前述的三個過程切割開，把其中邏輯處理計算的部分分離開并集中。
要做到能夠把邏輯分離并且集中，需要以下幾個前提條件：
1.?核心處理芯片升級，由MCU/MPU/SoC，計算能力大幅提升；
2.車載以太網應用支持了高速實時和大數據量的信息傳輸能力；
3.大數據量的傳輸能力，進一步支撐了面向服務的中間件軟件架構。
處理器能力攀升
以動力域為主線來舉例，動力域的控制系統其邏輯復雜度在傳統汽車電子中屬于比較高了，目前都是32位浮點處理器。此外車上其它應用還存在著不少8位、16位的單片機芯片。
大概七八年前，做動力系統的MCU常用型號，以英飛凌的TC178x、NXP的MPC574x為例，都在200MHz以下，性能大約在1.x~2.xDMIPS/MHz水平，因此可以估計算力~400DMIPS。大量動力域和底盤域的控制器已經可以基于這個檔位算力實施，例如EMS、VCU、BMS、EPS、ESP等，都有應用上述MCU型號的實例。
以英飛凌為例，后來逐步升級到TC2xx。按照1.7~2.4DMIPS/MHz，200MHz，三核計算，大約算力達到了~1200DMIPS量級。數倍于此前的狀態。
近幾年又升級到TC3xx，例如TC39x已經達到了4kDMIPS量級，又翻了數倍。
而英飛凌最新出的MPU TC4Dx達到了8kDMIPS量級。
此外，目前行業內應用廣泛的MPU S32G，處理器部分有4xA53+3xM7，分別按照2.3DMIPS/MHz @ 1GHz和2.14DMIPS/MHz @ 400MHz計算，其總處理算力達到了11k+DMIPS。
目前行業內應用廣泛的TDA4VM，處理器部分包括了2xA72和6xR5F，分別按照7.3DMIPS/MHz @ 2GHz和2.45DMIPS/MHz @ 1GHz計算，其總處理算力達到了40k+DMIPS。
再進一步到SoC，以Qualcomm為例，其后的SA85xx系列算力直奔100~200kDMIPS而去。
從MCU到SoC，CPU算力的跨度足足達到了200倍之多。
當然，MPU和SoC處理的內容也不僅僅是嵌入式系統中純粹的邏輯系統，還包括運行復雜操作系統如Linux，以及配合其它協處理系統DSP、GPU、NPU等共同完成復雜的圖像感知和數據計算密集型算法的處理，單純去比算力對MCU有點不公平。但總的來說，只是想表達一個觀點，就是隨著處理器能力的增強，過去的多個控制單元從算力上完全有機會放進同一個芯片中運行；換個角度，用新一代的MCU去處理傳統的汽車電子控制系統場景，即便刨除控制策略本身復雜度提升的因素，可能依然會浪費很多計算處理資源。
車載以太網的應用
車載以太網是能實現域控分離的另一個重要的因素。車載應用中，能夠實時的交換數據是幾乎一切控制功能的基本要求。提到實時性，首先會想到AVB/TSN協議族。但這里我們先不談AVB/TSN，先算一筆基本賬。
以500kbps的CAN網絡為例，傳遞一幀8字節的報文需要大約216us（理論值，實際值會略高250~300us），理論傳輸效率 27us/Byte。類似地，按照百兆以太網100Mbps帶寬，一幀報文~1500Bytes大約需要花費120us傳輸（理論值，實際取決于網絡狀態和幀間延時等），理論傳輸效率為0.08us/Byte。二者相比，一來一回相差了足足200倍。
正是這200倍的裕量，進一步為AVB/TSN等協議族提供了足夠施展的空間。
面向服務的通訊中間件設計
正是CAN到以太網這種基于物理通訊手段的量級提升，使得信息的傳遞具備更靈活的可能性。面向服務只是一種工程思考方式，嚴格來說并不是汽車里的新物種。傳統的診斷服務協議UDS就是一種面向服務的思維，但即使用多幀，實時傳輸的數據量也僅限于數十個字節（不考慮刷寫的大包多幀）。但是基于以太網帶來的通訊效率的量級提升，使得通訊中間件有了新的可能性。
靈活和效率是一對相互制衡的屬性，采用面向服務的架構具備靈活易插拔的能力，但同時會產生額外的協議開銷（Overhead），例如包括服務發現、握手、QoS信息的額外傳遞，本質上是信息熵的編碼效率降低。
面向服務化后，可能會出現同樣的信號被打包在不同服務報文里多次發送，或同樣的報文被不同消費者多次消費，相比例如基于CAN信號的傳輸都屬于冗余。好在物理通訊效率的提升為信息的冗余提供了足夠寬闊的空間。當進一步升級到千兆以太網，傳統汽車通信網絡里的有效負載信息量需要占用的帶寬幾乎可以忽略，反而是冗余和協議開銷占據了主要部分。
正因信息服務化提供了靈活的服務配置，以及節點熱插拔、功能動態配置等能力，使得整車內不同控制節點間功能的協同和組合變成可能，進而開發出多種多樣的整車功能，并且隨著時間變化易于調整和升級。
二、什么樣的功能可以域控
車輛控制功能的五域模型
按車輛的功能劃分域，考慮可以把域內的功能集中在一起。例如，底盤域、動力域、車身域，以及隨著近年來汽車智能化而逐步成型的座艙域、智駕域。上述五域模型是目前比較通用的域控架構概念。
那么接下來，在往域控邁進以至進一步向中央計算平臺邁進的過程中，是不是所有的功能都可以被上移到高性能芯片中，答案似乎也不盡然。換言之哪些功能是可以被挪進去，哪些不能，需要進行考量。
車輛控制的時間尺度
用一張圖來整理思路，沿橫軸方向是時間尺度，上面羅列出了一些汽車電子控制器所處于的位置。
首先，從大的思路上，我認為應該建立全時間尺度的概念。車輛作為一個系統，具備各種各樣不同時間尺度的功能要素，跨度很大。其中，就每個時間尺度上分別舉例說明：
100us量級：屬于超快速計算的場景。例如發動機管理系統中的噴油點火正時，必須嚴格根據曲軸齒的位置判斷，在6000rpm高速旋轉時，齒齒間的時間不過100us量級；再如電機矢量控制，高轉速可達到15000rpm，此時留給每次旋變位置解碼和矢量控制的計算窗口只有50~100us量級。這種情況受物理因素限制，做不到系統無法被有效控制。
1ms量級：快速計算場景。這在嵌入式系統中也算比較快的計算步長了。典型的場景，例如底盤電子中ESC的電磁閥控制，變速箱系統中的電磁閥控制，發動機管理系統中的節氣門控制，基本也都是受被控對象的物理特性要求，必須以快速響應才能獲得好的控制效果。
10ms量級：大量控制系統會工作在這個時間尺度下，典型的例如VCU、BMS、BCM等等。另外包括EMS、MCU、ESP等控制器中的邏輯控制部分，也會放在這個時間步長下工作。
100ms量級：對實時性低一點的嵌入式控制系統可以放在此時間步長下工作，例如BCM中的座椅、天窗、燈光等，以及空調和熱管理系統等。另外，ADAS中的感知規劃目前也會工作在這個時間尺度下，但這某種程度上也是不得已而為之，因為即便在高算力SoC上，要完整處理完一套感知融合算法，也需要這么長的時間。
1s/10s量級：對于傳統汽車電子系統，這個時間偏慢了。仍有一些功能可以在這個步長下運行，例如BMS中計算健康狀態或一些滯回特性，或者混動系統中計算一些能量平衡狀態等，都是變化較緩慢的行為，并不需要用很快的頻率去計算更新狀態。
Minutes/Hours量級：在傳統汽車電子系統中用這個步長進行運算的場景就不多了，在這個時間尺度下，信息開始逐步依賴于車云之間的遠程通訊鏈路來獲取信息。
基于時間尺度的功能集中
重新審視上面的圖，有以下幾點想法：
1.?在時間尺度上落在兩根紅線中間部分的功能，即控制步長在5ms~100s的功能，都可以域控集中化。這部分軟件可以從原有的控制器中拿出來，重新放進一個集中的域控制器或者車載中央計算平臺中。
2.?而與被控對象驅動密切相關，需要快速運算的，則仍與被控對象的物理硬件綁定；此外，某些傳感器信號對長距離傳輸的噪聲敏感，也不能遠離物理硬件。
3.?當計算時間尺度增加需要緩存記錄較長時間的數據才能計算出有效信息，而對實時性要求不高的，則可以考慮挪到云端去執行。
重點談一下第1點：
車身域和座艙娛樂域相關的功能，因為對實時性和安全性相對敏感性低一些，把它們域控化似乎已經比較能夠被接受。
但這里想說的是，包括一般認為需要強實時性和安全性保證的動力域和底盤域的大部分功能，同樣可以如此。對動力和底盤域控制功能域控，最擔心的風險是實時性可能不夠，無法及時完成控制閉環，尤其當功能與安全相關時尤其顯得不可靠。
實時控制的拆解分析
我們這樣來考慮這個問題，假設某個動力域或底盤域里的控制閉環以5ms為步長，且不依賴于外部的通訊例如CAN（即不會因為通訊鏈路引入額外的延遲）。在5ms內，它需要完成A-獲取傳感器信息；B-邏輯處理運算；C-驅動被控對象三個步驟，如上圖左。
然后，當把控制功能上移之后，其核心邏輯處理運算功能轉移到了域控或中央控制器中。相應地，增加了B1和B2兩項通信開銷。即變成了A-獲取傳感器信息；B0-邊緣處理；B1-發送信息；B-邏輯處理運算；B2-接收信息；C-驅動被控對象五個步驟，如上圖右。
不僅僅多了B1和B2兩個通信步驟，以及相應網絡擁塞產生的延時風險，另一方面由于域控制器上可能跑的是Linux這種復雜操作系統，步驟B的任務調度也可能產生延時。實事求是地說這些可能性都存在，但我們繼續求證量化分析一下。
1.?以太網通信過程B1/B2：對于結構簡單Hop數不超過3的車載以太網，在TSN加持下可以做到延遲最差數百us量級。加上本身的發送時間120us，一來一回總共可以估算為1ms。
2.?邏輯計算任務B：
（1）任務調度：對于加了PREEMPT_RT實時性補丁的Real-Time Linux來說，通常延遲在100us量級，最差情況可以控制在1ms量級。
（2）計算時間：原本MCU的5ms不可能用滿，算4ms，在高性能處理器加持下可以減半估為2ms。
3.?負責收發代理的區域/邊緣的簡化處理器B0，不再承擔邏輯計算任務，可以設為1ms運行。
加起來，上述過程一共用了4ms，而且留了余量，實際情況會比這個更短。
必須說明的是，實際場景中會有中斷響應、調度、阻塞、資源鎖、優先級等等實際問題要妥善解決，以上采用第一性的簡化模型進行討論。
此外，電子控制邏輯中本身也具備相當多的進一步寬容時間限制的可能性。
退一步講，任務本身對偶爾的時間延時也具備容忍能力，5ms為基準上下抖動幾個ms也是原本的設計就要考慮的因素，再說做故障診斷時也需要多個周期確認。
再退一步講，大部分控制器需要的步長可能在10ms乃至100ms都能夠接受，在這種時間裕度下，將更加輕松。
再再退一步講，如果是多個控制器形成的控制閉環，原本除了本身的計算步長也還要額外加上例如CAN收發的通訊延時，這又提供了時間裕度。
因此，對于車上的大多數控制功能來說，搬移到一個集中的域控/中央運算環境中，是完全可行的。
車云一體視角
從上面時間尺度的分析還有另一點需要特別指出，就是對其中單個的控制系統而言，它的時間尺度也可以具備很大的跨度，這一點是在無線通信和云端數據存儲處理技術成熟并且成本足夠低的情況下，在汽車上面催生的智能網聯新需求。
傳統汽車上基本沒有連接的概念，每個控制器是自己處理自己系統的事情。可以說鐵盒一關，不知今夕是何年，亦不知世界為何。只要上電，就在自己的封閉系統里傳感-邏輯-執行，如此往復數十年。
在傳統嵌入式系統里，運算資源和存儲資源都非常有限，幾乎不可能做長時間尺度的事情（這可能需要緩存很多的中間數據處理）；另外，也看不到其它的同款車型的平均狀態，所以即使本車的某些特征已經明顯出現離群的異常，在本車也沒有任何手段可以辨別。但這種需求是并非不存在，只是在傳統嵌入式系統中沒有條件實現，就被接受為常態了。
隨著無線通信技術的進步和云端數據存儲處理技術進步，汽車智能網聯化已經來到近前。在這種情況下，換一個視角，車輛的很多控制系統都可以拓展到云端，只有將車端和云端合在一起，才構成一個真正完整的控制系統，能夠覆蓋到這個系統中不同時間尺度的控制需求。
需要說明的是，這種視角跟目前一些車企建立一個云端平臺，其中進行一些數據存儲、統計和可視化不是一個概念（如下圖左）。這里更強調的是從單個控制系統的角度，把本地的控制單元與云端的控制邏輯視同成一個系統，前者分別負責實時控制和數據處理，后者則負責慢時間尺度但時間空間大數據量處理的任務（如下圖右）。
對車云一體需求特別強烈的系統，包括電池管理系統BMS（電池狀態辨識）、座艙系統（駕駛員習慣風格辨識）、動力系統（駕駛風格，混動能量平衡等）。
三、未來可能的路
應用進程化
在集中化的狀態下，基于復雜操作系統來運行，不管是宏內核（例如Linux）還是微內核（例如QNX），原有嵌入式環境中的邏輯控制程序，可以變化為一個或多個進程來，依靠操作系統的實時性調度來運行。如前所述，這種設計對大部分控制場景是有可行性的。
逐步過渡向集中
從實際行業趨勢上來說，可能會由座艙娛樂、車身類的功能，逐漸過渡到底盤、動力類的功能。這是由其性質決定，畢竟對于高風險同時又性能要求高的應用，工程師會基于風險厭惡的本能先從容易的部分著手。
但自動駕駛域可能有點特殊，作為一個跟動力和底盤線控密切配合且安全相關的系統，理想情況它的整體計算邏輯流能像VCU一樣10ms更新一次（跟著系統中最快的IMU頻率跑）最好。但這個速度不是不為也，而是不能也，目前的算力滿足不了這個要求（這也是輝羲要解決的目標）。感知、融合、定位、規劃等算法模塊都可能是“數據密集”+“計算密集”的狀態，計算強度的要求相對傳統邏輯控制為主的算法飆升，10ms算不完。實際的計算流由攝像頭的幀率觸發，30FPS就是33ms算一幀，而要完成一個從感知到控制的完整閉環，整個鏈路要達到100ms以上。所以自動駕駛除規控外的主體部分，從誕生之日起就沒在MCU上跑過，雖然從實時性需求角度它更可比擬一個MCU上的應用。
此外，還有很多歷史的包袱，例如ESP等底盤件，它的軟件成熟不僅僅依靠工程師的專業know-how和開發能力，更依賴于專業試驗環境、大量產品驗證甚至事故教訓才逐步打磨出來。除非能整體移植，否則似乎很難具備量產級的質量說服力。
所以總體上，飯是一口口的吃，由局部到整體逐漸納入更多的車輛控制功能，逐步由局部的域控走向整體的車載中央計算單元。而更宏觀地把車云一體納入來看，在車上的“車載中央計算單元”，在整體上也可以定位成“邊緣計算服務器”，而云端的超強算力和數據存儲能力則成為“計算中心”。
車+云二位一體的狀態，覆蓋到從實時性到長周期各種時間尺度的特征，構成完整的控制系統。
虛擬化
破局之道可能在于虛擬化能力的不斷提升。按目前的認知把虛擬化分幾個段位，純軟件的虛擬化 >> 硬件支持的CPU虛擬化 >> GPU/NPU/...的虛擬化 >> 硬件支持下的多容器虛擬化。
一個控制功能要起作用，會用到多方面的資源，包括CPU、RAM、IO、Ethernet/CAN等通訊、SD/eMMC/UFS存儲，以及可能更復雜一點的NPU、GPU、Display、PCIe、MIPI-CSI、ISP等等資源。
虛擬化程度提升的過程，實際上就是根據不同的場景要求，實現不同層級的資源共享與隔離的過程。可以考慮到的是，從Baremetal開始，到Hypervisor，再到操作系統的內核、cgroup、進程、線程、協程，結合硬件的虛擬化支持，每一層具備不同能力的資源分配和隔離以及相應的性能開銷，從而適合不同的場景。
未來可能的方向：
首先，是具有高性能計算能力的芯片。
其次，不同層級的車載軟件基礎架構發展成熟。
然后，根據整車控制功能的性質（例如實時性和隔離性的要求），就可以部署在相應的層級。
這時候汽車可能真的變成了既是一個大工業品，也是一個消費電子終端的形態。現在在手機平板上能實現的功能，加上汽車自身特性延伸開的功能，都會集中在這個產品上。
?
本文尚有很多細節未及展開討論，而更多在談論的是終局理想形態。在今天域控技術進步日新月異的背景下，無數工程師對各種具體工程難題的逐個解決，才是推動行業進步最堅實的動力。
參考
[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
編輯：黃飛
工商網監
評論