兼容Linux操作系統(tǒng)的域控制器生命周期管理

摘? 要：文章從未來汽車控制器發(fā)展的需求角度闡述了生命周期管理的重要性，分析了傳統(tǒng)控制器生命周期方案的局限性，明確了MCU+GPU系統(tǒng)架構(gòu)下對域控制器生命周期管理的要求，提出了一種可以兼容Linux操作系統(tǒng)的域控制器生命周期管理方案，同時分析了在異常狀態(tài)下的生命周期響應(yīng)策略并設(shè)計了該生命周期管理方案的軟件架構(gòu)，最后給出了在這種方案設(shè)計下實際軟件運行的性能。

關(guān)鍵詞：域控制器;生命周期管理;穩(wěn)定性;魯棒性

中圖分類號：U463.6;TP393? ? ? ? ? ? ? ? 文獻(xiàn)標(biāo)識碼：A文章編號：2096-4706（2021）15-0054-06

Abstract： This paper explains the importance of life cycle management from the perspective of the development of future automotive controllers， analyzes the limitations of traditional controller life cycle management solutions， clarifies the requirements for domain controller life cycle management under the MCU+GPU system architecture， and proposes a domain controller life cycle management solution compatible with Linux operating system. At the same time， it analyzes the faults reaction strategy and designs the software architecture of life cycle management. Finally， the performance of actual software running under this design is given.

Keywords： domain controller; life cycle management; stability; robustness

0? 引? 言

未來的汽車將逐步向智能化、網(wǎng)聯(lián)化、中央集成化發(fā)展，高算力的車載控制器是汽車發(fā)展的必然趨勢。傳統(tǒng)車載控制器由于選用MCU作為主控芯片無法滿足高算力的要求。搭載Linux操作系統(tǒng)的GPU芯片雖然算力強大，可處理圖像識別、深度學(xué)習(xí)等復(fù)雜運算，但安全性和穩(wěn)定性難以達(dá)到車規(guī)級要求。所以當(dāng)下車載域控制器都采用MCU+GPU的系統(tǒng)架構(gòu)。GPU上運行圖像、深度學(xué)習(xí)和決策算法，MCU上運行通信管理、電源管理、診斷管理等高實時性，高安全性的功能策略。MCU和GPU之間通過高帶寬的SPI或以太網(wǎng)實現(xiàn)數(shù)據(jù)傳輸。

隨著MCU+GPU系統(tǒng)架構(gòu)的出現(xiàn)，域控制器如何在一次上電到休眠的生命周期中同時管理MCU和GPU，并保證其運行的穩(wěn)定性和魯棒性顯得迫在眉睫。本文首先將闡述傳統(tǒng)控制器的生命周期管理以及局限性;其次會提出兼容Linux操作系統(tǒng)的域控制器的生命周期管理方案;再次會進(jìn)一步分析故障下的生命周期管理;從次會設(shè)計該生命周期管理方案的軟件架構(gòu)及實現(xiàn)方案;最后進(jìn)行總結(jié)和展望。

1? 傳統(tǒng)汽車控制器的生命周期管理

在傳統(tǒng)車載控制器諸如ECU、VCU中僅有一個MCU芯片。所以傳統(tǒng)控制器的生命周期管理僅考慮了單MCU架構(gòu)下的流程狀態(tài)。圖1所示為當(dāng)前博世VCU8.0的生命周期管理方案。

這種生命周期管理主要用于區(qū)分MCU固定調(diào)度機制下的初始化流程，正常定周期調(diào)度流程以及下電反初始化流程。其中ini狀態(tài)用于初始化流程的操作以及NVM存儲數(shù)據(jù)的讀取;Wait狀態(tài)用于初始化結(jié)束后等待KL15喚醒信號的等待狀態(tài);PreDrive狀態(tài)為收到Kl15喚醒信號后的準(zhǔn)備狀態(tài);Drive狀態(tài)為全功能運行狀態(tài);PostDrive為KL15下電后的準(zhǔn)備下電狀態(tài);PrepareShutDown用于執(zhí)行反初始化流程和NVM數(shù)據(jù)的存儲。ShutDown為等待斷電狀態(tài)。

該生命周期管理有以下三點問題：（1）MCU上電后狀態(tài)過于冗余。當(dāng)今比較先進(jìn)的電子電器架構(gòu)，KL15的信號逐漸弱化。例如特斯拉Model3上已無啟動開關(guān)。所以定周期調(diào)度中僅需Wait狀態(tài)即可。（2）控制器級的故障在該生命周期管理中不會體現(xiàn)，所有軟硬件故障均釋放給上層邏輯處理。該生命周期管理僅負(fù)責(zé)上電和下電的切換。（3）只能支持MCU定周期的調(diào)度，無法同時支持MCU+GPU，無法支持Linux或QNX操作系統(tǒng)。

所以未來域控制器的生命周期管理需要支持多主控芯片的系統(tǒng)架構(gòu)（MCU+GPU），能夠識別硬件不同的工作狀態(tài)，支持硬件級的故障響應(yīng)并需要同時兼容定周期OS調(diào)度和Linux/QNX操作系統(tǒng)。

2? 兼容Linux操作系統(tǒng)的域控制器生命周期管理方案

在MCU+GPU的系統(tǒng)架構(gòu)中，MCU和GPU各司其職。MCU作為電管管理、網(wǎng)絡(luò)管理、通訊管理的主控芯片會優(yōu)先運行，GPU上搭載Linux操作系統(tǒng)負(fù)責(zé)復(fù)雜算法運算和攝像頭驅(qū)動功能，需要在MCU運行后啟動。所以域控制器的生命周期管理由兩個子生命周期構(gòu)成：MCU生命周期和GPU生命周期。MCU生命周期可以參考博世VCU8.0的設(shè)計，并要求盡早開始通信和啟動GPU。GPU的生命周期參考Linux啟動流程設(shè)計Bootup、Startup、Fullrun和GPUShutdown四個流程狀態(tài)。由于兩個子生命周期流程相互影響，且需要兩者間實現(xiàn)握手，通信等交互功能，故整個控制器的生命周期狀態(tài)的管理及跳轉(zhuǎn)顯得錯綜復(fù)雜。圖2為本文提出的生命周期管理的方案設(shè)計。

其中Poweroff定義為整個域控制器休眠狀態(tài)，MCU和GPU均不工作。

Ini狀態(tài)定義為單MCU工作狀態(tài)。在Ini狀態(tài)下域控制器已可以正常通信，并能處理電源管理、通信管理、診斷功能的策略邏輯。故此時定義在該生命狀態(tài)下的上層應(yīng)用可作網(wǎng)絡(luò)路由或執(zhí)行器控制功能。圖像以及決策相關(guān)的算法由于GPU尚未工作，不可以觸發(fā)。在從Poweroff跳轉(zhuǎn)到Ini狀態(tài)過程中需要經(jīng)歷MCU的電源上電管理流程。CAN 通信和以太網(wǎng)通信在MCU啟動后即可開始。

在生命周期進(jìn)入ini狀態(tài)后，MCU會主動請求GPU上電喚醒并啟動GPU上電流程。此時GPU的boot啟動，進(jìn)入Bootup狀態(tài)。Bootup狀態(tài)定義為GPU內(nèi)的Boot開始運行，但Linuxkernel尚未啟動。Boot啟動成功后，需要GPU通知MCU，進(jìn)而跳轉(zhuǎn)Startup狀態(tài)。由于在Boot啟動過程中，MCU和GPU芯片間尚未建立通信，故系統(tǒng)設(shè)計上要求增加一路GPIO在MCU和GPU之間。當(dāng)GPUBoot啟動成功，需要GPU上拉通知MCU。該GPIO要求高有效，并設(shè)計下拉電阻，實現(xiàn)GPU斷電時MCU也收到無效信號。在Bootup狀態(tài)中如停留時間過長MCU仍未收到Boot啟動成功信號，認(rèn)為啟動超時，生命周期將會直接跳轉(zhuǎn)到GPU Shutdown狀態(tài)。從域控制器被喚醒到進(jìn)入Bootup狀態(tài)要求時間盡量短，本方案可做到100 ms左右，后文將做進(jìn)一步闡述。

在生命周期進(jìn)入GPUStartup狀態(tài)后，Linux操作系統(tǒng)kernel開始運行，此時GPU上的SPI通信，以太網(wǎng)通信開始啟動，Linux上部分APP開始初始化。啟動完成后，GPU和MCU之間開始建立握手機制（SPI、以太網(wǎng)或IPC）。MCU收到成功握手信號后觸發(fā)生命周期狀態(tài)即跳轉(zhuǎn)到Fullrun。如長時間未建立握手或握手失敗，生命周期將會直接跳轉(zhuǎn)到GPUshutdown狀態(tài)。Startup和Bootup狀態(tài)均為過程性狀態(tài)，圖像以及決策相關(guān)的算法由于APP尚未工作，不可以觸發(fā)。狀態(tài)設(shè)計上將GPU啟動流程拆分為Bootup和Startup兩個狀態(tài)主要考慮到：（1）方便啟動異常原因的記錄，區(qū)分是Boot原因還是kernel原因?qū)е聠邮?，方便工程師調(diào)試和測試;（2）在Boot失敗后能快速下電修復(fù)避免過長時間的等待，提高用戶滿意度。根據(jù)實驗室數(shù)據(jù)，在搭載linux的征程2處理器GPU上，Bootup狀態(tài)可以做到停留1 s內(nèi)，Startup狀態(tài)會停留5 s左右。

在生命周期的Fullrun狀態(tài)定義為MCU和GPU芯片均已正常運行且無硬件及操作系統(tǒng)級故障。此時MCU上功能策略和GPU上所有算法均可滿負(fù)荷運行。該狀態(tài)停留時間無特定要求。在出現(xiàn)GPU或MCU故障，以及需要域控制器休眠時才會退出該狀態(tài)，進(jìn)入GPUShutdown狀態(tài)。

GPUShutdown狀態(tài)為GPU的下電過程狀態(tài)。進(jìn)入該狀態(tài)后，GPU上的APP執(zhí)行反初始化操作，并做GPU端的NVM數(shù)據(jù)存儲，為下次啟動做準(zhǔn)備。之后Boot上做準(zhǔn)備下電處理，完成后通過拉低上文提到的GPIO通知MCU。MCU執(zhí)行GPU的下電流程邏輯。當(dāng)MCU完成GPU端的所有下電流程，并收到GPIO被拉低的通知后，生命周期跳轉(zhuǎn)到Ini狀態(tài)，單MCU工作。有兩點值得注意：（1）在該狀態(tài)下如MCU長時間未收到GPIO低的通知，認(rèn)為準(zhǔn)備下電超時，MCU將強制執(zhí)行GPU下電流程。（2）如由于GPU異常故障或啟動不成功導(dǎo)致的下電，生命周期進(jìn)入Ini后會繼續(xù)請求GPU啟動，嘗試通過GPUreset實現(xiàn)故障修復(fù)。連續(xù)5次失敗后進(jìn)入Ini將不再繼續(xù)請求GPU啟動。

EcuShutdown狀態(tài)為MCU的下電過程。該狀態(tài)由Ini跳轉(zhuǎn)而來，故此時GPU已完成下電。進(jìn)入該狀態(tài)的條件有：（1）正常控制器下電休眠;（2）上層軟件請求的reset;（3）MCU端異常故障導(dǎo)致的reset。三者滿足一個即可進(jìn)入EcuShutdown。在該狀態(tài)中MCU執(zhí)行Ecu下電邏輯和NVM存儲操作，與傳統(tǒng)車載控制器下電狀態(tài)一致。

這種生命周期管理設(shè)計，主控邏輯由MCU負(fù)責(zé)，但需要MCU和GPU保持通信交互，保證兩芯片狀態(tài)和策略的一致性。在異常狀態(tài)下該方案也支持MCU端的單獨運行，所以可以根據(jù)不同的軟件應(yīng)用場景靈活地選擇GPU+MCU同時運行，MCU單獨運行兩種芯片級的工作狀態(tài)。該方案同時支持故障下的各種響應(yīng)。

3? 故障情況下的響應(yīng)

生命周期管理對不同故障的響應(yīng)會直接反映出控制器的穩(wěn)定性和魯棒性。本文將基于TC234+征程2GPU的系統(tǒng)架構(gòu)，較詳細(xì)地分析電源故障、通信故障以及溫度故障下的生命周期響應(yīng)策略，以滿足穩(wěn)定性和魯棒性的要求。硬件架構(gòu)圖如圖3所示。

3.1? 控制器電源監(jiān)控故障

控制器電源監(jiān)控的主要故障有：對控制器供電12伏電壓的過壓欠壓;對MCU芯片供電5伏的過壓欠壓;對GPU芯片供電5伏的過壓欠壓。

當(dāng)出現(xiàn)對控制器供電12伏的過壓欠壓時，會導(dǎo)致整個控制器電路的失控和不可信。所以在12伏過壓或欠壓時，認(rèn)為是MCU嚴(yán)重故障，生命周期管理將從Fullrun->GPU Shutdown->Ini ->Ecu Shutdown ->Poweroff。并且要求下電結(jié)束后不能對MCU和GPU供電，故在從Poweroff跳轉(zhuǎn)Ini過程中如發(fā)現(xiàn)12伏過壓或欠壓，觸發(fā)硬件復(fù)位。同時需要在硬件設(shè)計中對12伏的電壓有檢測，如出現(xiàn)過壓或欠壓電源芯片不能對MCU供電。

當(dāng)出現(xiàn)對MCU芯片供電的欠壓和過壓時，會導(dǎo)致MCU上程序運行不可信，同時GPU端的供電也可能出現(xiàn)不可信。所以在MCU端5伏供電過壓或欠壓時，認(rèn)為是MCU嚴(yán)重故障，生命周期管理將從Fullrun->GPU Shutdown->Ini ->Ecu Shutdown ->Poweroff。與12伏供電故障不同的是，MCU端5伏出現(xiàn)故障后，下電完成后需要支持再次喚醒MCU到Ini狀態(tài)，并監(jiān)控MCU側(cè)5伏電壓。如電壓在reset后恢復(fù)正常，則再次正常上電至Fullrun狀態(tài);如reset后5伏供電仍不正常，再次重啟控制器。連續(xù)3次重啟失敗后，在當(dāng)次生命周期中，不再啟動MCU。

當(dāng)對GPU 供電5 伏出現(xiàn)過壓或欠壓時，僅GPU端程序運行不可信。所以僅認(rèn)為是GPU嚴(yán)重故障，生命周期將從Fullrun->GPU Shutdown->Ini，并保持監(jiān)測GPU供電電壓，當(dāng)對GPU供電正常后由Ini->Bootup ->Startup –>Fullrun。

3.2? MCU與GPU間通信故障

MCU和GPU間通信有以下兩種：上電下電GPIO端子通信，SPI/以太網(wǎng)信號交互通信。通信故障所覆蓋的異常狀態(tài)不僅包括MCU和GPU間狹義的通信功能故障，同時也覆蓋Linuxkernel crash、GPUboot失控、MCU周期調(diào)度崩潰等操作系統(tǒng)級的異常狀態(tài)。

上電下電GPIO端子通信在上文已提到，主要用于GPUboot失控，或GPU異常斷電時通知MCU的一種機制。同時也是GPU正常關(guān)機后的一種通知機制。所以在GPIO被拉低后，生命周期管理將從Fullrun->GPU Shutdown->Ini。之后將會連續(xù)嘗試3次再次啟動GPU，若不成功，將保持在Ini狀態(tài)中。

SPI/以太網(wǎng)信號交互通信在生命周期管理中主要用于MCU和Linuxkernel間的相互監(jiān)控。在首次上電時會有初始化握手校驗，如握手不成功，認(rèn)為域控制器啟動失敗，生命周期將會從Fullrun->GPU Shutdown->Ini，并會嘗試再次請求啟動GPU，連續(xù)5次失敗后將會保持在Ini狀態(tài)中。握手成功后，MCU和GPU會定周期監(jiān)控通信的穩(wěn)定性。當(dāng)MCU側(cè)檢測到通信丟失，會強制對GPU斷電并跳轉(zhuǎn)至Ini;當(dāng)GPU側(cè)檢測到通信丟失，會執(zhí)行GPU側(cè)的下電操作，并通過GPIO通知MCU，生命周期會跳轉(zhuǎn)至Ini。同樣的，進(jìn)入Ini狀態(tài)后MCU會嘗試再次請求啟動GPU，連續(xù)5次失敗后將會保持在Ini狀態(tài)中。

3.3? 溫度監(jiān)控

根據(jù)圖3硬件架構(gòu)，我們會監(jiān)控控制器PCB板溫度和征程2芯片內(nèi)部溫度。

查閱征程2芯片手冊，芯片內(nèi)溫度分為兩個等級：大于125 ℃，芯片要求關(guān)機重啟;大于105 ℃小于125 ℃，要求芯片降頻處理，以減少功耗。所以在生命周期管理中，需要linux上系統(tǒng)軟件實時讀取芯片內(nèi)溫度寄存器，當(dāng)超過125 ℃，linux執(zhí)行關(guān)機流程，并通知MCU，狀態(tài)機從Fullrun->GPU Shutdown->Ini。當(dāng)芯片溫度超過105 ℃，小于125 ℃，生命周期狀態(tài)不變，降頻處理由Linux上軟件負(fù)責(zé)，復(fù)雜算法可根據(jù)開發(fā)者需求停止運行。

PCB溫度由MCU監(jiān)控。實際溫度故障的閾值需要根據(jù)控制器熱仿真結(jié)果進(jìn)行判斷。我們根據(jù)圖3所示架構(gòu)圖做熱仿真。設(shè)定熱交換系數(shù)為10 W/m2K，初始壓力為101 325 Pa，環(huán)境溫度為85 ℃，MCU功率為0.492 W，征程2芯片功率為4.656 W。熱仿真結(jié)果如表1所示。

我們集中關(guān)注MCUTC234和GPU征程2的仿真結(jié)果。發(fā)現(xiàn)GPU上溫度，在環(huán)境溫度為85 ℃時最高溫度已達(dá)到124 ℃，并且此時MCU 控制器內(nèi)環(huán)境溫度最高也達(dá)到了124 ℃。考慮到GPU極限溫度125 ℃，MCU極限溫度150 ℃，需要在此時做GPU下電處理。此時根據(jù)仿真結(jié)果，PCB板溫達(dá)到115 ℃。所以在MCU監(jiān)控板溫達(dá)到115 ℃時，生命周期管理需要從Fullrun->GPU Shutdown->Ini。當(dāng)在Ini狀態(tài)下監(jiān)控到PCB板溫低于110 ℃時，才會再次啟動GPU。

本文只分析了控制器芯片級別的電壓故障、通信故障和溫度故障的響應(yīng)策略。實際軟件應(yīng)用中還有諸如攝像頭故障、顯示器故障、雷達(dá)故障等其他類型故障。由于這些故障和外部選用模組、雷達(dá)強相關(guān)，本文不做闡述。但本文提出的生命周期管理方案中已留有故障響應(yīng)和軟件請求的對應(yīng)接口，故可根據(jù)實際需求做對應(yīng)的配置。

4? 生命周期管理的軟件架構(gòu)實現(xiàn)

生命周期管理的主要邏輯在MCU中實現(xiàn)，所以MCU會作為主節(jié)點部署主體邏輯，GPU會作為從節(jié)點部署GPU端的生命周期管理。整個域控制器的靜態(tài)軟件架構(gòu)如圖4所示。

圖中左側(cè)為MCU上軟件架構(gòu)。MCU上整體部署Autosar軟件架構(gòu)，生命周期管理模塊（上方標(biāo)紅）在其中作為復(fù)雜驅(qū)動，可通過RTE與上層APP交互，實現(xiàn)與通信信號和診斷結(jié)果的交互，從而實現(xiàn)上層應(yīng)用軟件控制生命周期跳轉(zhuǎn)以及上電下電的需求。生命周期管理模塊下層為電源管理模塊（下方標(biāo)紅），負(fù)責(zé)整個控制器的上下電。在生命周期進(jìn)入特定狀態(tài)，（如GPUShutdown 或EcuShutdown）時，調(diào)用電源管理模塊接口，實現(xiàn)上下電。該軟件架構(gòu)中Autosar其他服務(wù)與生命周期管理并行運行，可實現(xiàn)生命周期管理進(jìn)入Ini狀態(tài)即可正常運行通信和診斷功能。

圖中右側(cè)為GPU端Linux操作系統(tǒng)的部署。生命周期管理（左側(cè)標(biāo)紅）在其中為APP，當(dāng)Kernel啟動成功后運行，主要負(fù)責(zé)監(jiān)控Fullrun狀態(tài)下的各種異常狀態(tài)。如需要執(zhí)行狀態(tài)機的跳轉(zhuǎn)，通過Gateway模塊通知MCU，并同時通知Linux中電源模塊（右側(cè)標(biāo)紅）實現(xiàn)GPU外設(shè)的下電處理。

這種軟件架構(gòu)在實驗室中已完成部署和測試，可實現(xiàn)110 ms內(nèi)首個CAN報文的發(fā)出，110 ms內(nèi)開始啟動GPU，如圖5、圖6所示。從開始喚醒到Linux開始正常運行，進(jìn)入Fullrun時間在7 s內(nèi)（喚醒幀在96.215 s 發(fā)出，首幀報文在96.319 s 發(fā)出，間隔104 ms）。

5? 結(jié)? 論

域控制器的生命周期管理是MCU+GPU系統(tǒng)架構(gòu)的重要技術(shù)之一。本文提出了一種兼容GPULinux操作系統(tǒng)的生命周期管理的解決方案，并細(xì)化了這種解決方案下的故障響應(yīng)和軟件架構(gòu)部署，最終給出了在實驗室環(huán)境下的啟動時間。這種解決方案適用于所有MCU+單一GPU的系統(tǒng)架構(gòu)，并能滿足量產(chǎn)項目對穩(wěn)定性和魯棒性的要求。但該方案暫不支持多GPU芯片的系統(tǒng)架構(gòu)。后續(xù)將對多GPU的系統(tǒng)架構(gòu)繼續(xù)分析討論，使生命周期管理能兼容多GPU的系統(tǒng)設(shè)計。

參考文獻(xiàn)：

[1] AUTOSAR. Specification of ECU State Manager [EB/OL].（2021-02-08）.https：//www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SWS_ECUStateManager.pdf.

[2] AUTOSAR. Specification of Operating System. [EB/OL].（2021-02-08）.https：//www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SWS_OS.pdf.

[3] 劉佳熙，丁鋒.面向未來汽車電子電氣架構(gòu)的域控制器平臺 [J].中國集成電路，2019，28（9）：82-87.

[4] ZHOU X，WANG K，ZHU L，et al. Development of Vehicle Domain Controller Based on Ethernet. [J/OL].Journal of Physics：Conference Series 2020，（1802）：（2020-04-14）.https：//iopscience.iop.org/article/10.1088/1742-6596/1802/2/022065.

[5] 劉佳熙，施思明，徐振敏，等.面向服務(wù)架構(gòu)汽車軟件開發(fā)方法和實踐 [J].中國集成電路，2021，30（Z1）：82-88.

作者簡介：柳灝（1989—），男，漢族，江蘇南京人，資深工程師，碩士研究生，研究方向：新能源電動汽車、汽車智能駕駛。

3542500338261