深度解析汽車電子車輛控制功能的五域模型

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

?

一、為什么可以域控

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

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

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

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

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

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

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

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

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

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

處理器能力攀升

以動(dòng)力域?yàn)橹骶€來(lái)舉例，動(dòng)力域的控制系統(tǒng)其邏輯復(fù)雜度在傳統(tǒng)汽車電子中屬于比較高了，目前都是32位浮點(diǎn)處理器。此外車上其它應(yīng)用還存在著不少8位、16位的單片機(jī)芯片。

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

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

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

而英飛凌最新出的MPU TC4Dx達(dá)到了8kDMIPS量級(jí)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

車輛控制功能的五域模型

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

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

車輛控制的時(shí)間尺度

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

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

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

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

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

100ms量級(jí)：對(duì)實(shí)時(shí)性低一點(diǎn)的嵌入式控制系統(tǒng)可以放在此時(shí)間步長(zhǎng)下工作，例如BCM中的座椅、天窗、燈光等，以及空調(diào)和熱管理系統(tǒng)等。另外，ADAS中的感知規(guī)劃目前也會(huì)工作在這個(gè)時(shí)間尺度下，但這某種程度上也是不得已而為之，因?yàn)榧幢阍诟咚懔oC上，要完整處理完一套感知融合算法，也需要這么長(zhǎng)的時(shí)間。

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

Minutes/Hours量級(jí)：在傳統(tǒng)汽車電子系統(tǒng)中用這個(gè)步長(zhǎng)進(jìn)行運(yùn)算的場(chǎng)景就不多了，在這個(gè)時(shí)間尺度下，信息開(kāi)始逐步依賴于車云之間的遠(yuǎn)程通訊鏈路來(lái)獲取信息。

基于時(shí)間尺度的功能集中

重新審視上面的圖，有以下幾點(diǎn)想法：

1.?在時(shí)間尺度上落在兩根紅線中間部分的功能，即控制步長(zhǎng)在5ms~100s的功能，都可以域控集中化。這部分軟件可以從原有的控制器中拿出來(lái)，重新放進(jìn)一個(gè)集中的域控制器或者車載中央計(jì)算平臺(tái)中。

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

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

重點(diǎn)談一下第1點(diǎn)：

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

但這里想說(shuō)的是，包括一般認(rèn)為需要強(qiáng)實(shí)時(shí)性和安全性保證的動(dòng)力域和底盤(pán)域的大部分功能，同樣可以如此。對(duì)動(dòng)力和底盤(pán)域控制功能域控，最擔(dān)心的風(fēng)險(xiǎn)是實(shí)時(shí)性可能不夠，無(wú)法及時(shí)完成控制閉環(huán)，尤其當(dāng)功能與安全相關(guān)時(shí)尤其顯得不可靠。

實(shí)時(shí)控制的拆解分析

我們這樣來(lái)考慮這個(gè)問(wèn)題，假設(shè)某個(gè)動(dòng)力域或底盤(pán)域里的控制閉環(huán)以5ms為步長(zhǎng)，且不依賴于外部的通訊例如CAN（即不會(huì)因?yàn)橥ㄓ嶆溌芬腩~外的延遲）。在5ms內(nèi)，它需要完成A-獲取傳感器信息；B-邏輯處理運(yùn)算；C-驅(qū)動(dòng)被控對(duì)象三個(gè)步驟，如上圖左。

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

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

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

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

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

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

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

加起來(lái)，上述過(guò)程一共用了4ms，而且留了余量，實(shí)際情況會(huì)比這個(gè)更短。

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

此外，電子控制邏輯中本身也具備相當(dāng)多的進(jìn)一步寬容時(shí)間限制的可能性。

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

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

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

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

車云一體視角

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

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

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

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

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

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

三、未來(lái)可能的路

應(yīng)用進(jìn)程化

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

逐步過(guò)渡向集中

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

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

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

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

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

虛擬化

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

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

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

未來(lái)可能的方向：

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

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

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

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

?

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

參考

[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

編輯：黃飛