兼容Linux操作系統的域控制器生命周期管理

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

關鍵詞：域控制器;生命周期管理;穩定性;魯棒性

中圖分類號：U463.6;TP393? ? ? ? ? ? ? ? 文獻標識碼：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? 引? 言

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

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

1? 傳統汽車控制器的生命周期管理

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

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

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

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

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

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

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

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

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

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

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

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

EcuShutdown狀態為MCU的下電過程。該狀態由Ini跳轉而來，故此時GPU已完成下電。進入該狀態的條件有：（1）正?？刂破飨码娦菝?（2）上層軟件請求的reset;（3）MCU端異常故障導致的reset。三者滿足一個即可進入EcuShutdown。在該狀態中MCU執行Ecu下電邏輯和NVM存儲操作，與傳統車載控制器下電狀態一致。

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

3? 故障情況下的響應

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

3.1? 控制器電源監控故障

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

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

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

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

3.2? MCU與GPU間通信故障

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

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

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

3.3? 溫度監控

根據圖3硬件架構，我們會監控控制器PCB板溫度和征程2芯片內部溫度。

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

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

我們集中關注MCUTC234和GPU征程2的仿真結果。發現GPU上溫度，在環境溫度為85 ℃時最高溫度已達到124 ℃，并且此時MCU 控制器內環境溫度最高也達到了124 ℃?？紤]到GPU極限溫度125 ℃，MCU極限溫度150 ℃，需要在此時做GPU下電處理。此時根據仿真結果，PCB板溫達到115 ℃。所以在MCU監控板溫達到115 ℃時，生命周期管理需要從Fullrun->GPU Shutdown->Ini。當在Ini狀態下監控到PCB板溫低于110 ℃時，才會再次啟動GPU。

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

4? 生命周期管理的軟件架構實現

生命周期管理的主要邏輯在MCU中實現，所以MCU會作為主節點部署主體邏輯，GPU會作為從節點部署GPU端的生命周期管理。整個域控制器的靜態軟件架構如圖4所示。

圖中左側為MCU上軟件架構。MCU上整體部署Autosar軟件架構，生命周期管理模塊（上方標紅）在其中作為復雜驅動，可通過RTE與上層APP交互，實現與通信信號和診斷結果的交互，從而實現上層應用軟件控制生命周期跳轉以及上電下電的需求。生命周期管理模塊下層為電源管理模塊（下方標紅），負責整個控制器的上下電。在生命周期進入特定狀態，（如GPUShutdown 或EcuShutdown）時，調用電源管理模塊接口，實現上下電。該軟件架構中Autosar其他服務與生命周期管理并行運行，可實現生命周期管理進入Ini狀態即可正常運行通信和診斷功能。

圖中右側為GPU端Linux操作系統的部署。生命周期管理（左側標紅）在其中為APP，當Kernel啟動成功后運行，主要負責監控Fullrun狀態下的各種異常狀態。如需要執行狀態機的跳轉，通過Gateway模塊通知MCU，并同時通知Linux中電源模塊（右側標紅）實現GPU外設的下電處理。

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

5? 結? 論

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

參考文獻：

[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] 劉佳熙，丁鋒.面向未來汽車電子電氣架構的域控制器平臺 [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] 劉佳熙，施思明，徐振敏，等.面向服務架構汽車軟件開發方法和實踐 [J].中國集成電路，2021，30（Z1）：82-88.

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

3542500338261