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

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

中圖分類號(hào)：U463.6;TP393? ? ? ? ? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：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ā)展的必然趨勢(shì)。傳統(tǒng)車載控制器由于選用MCU作為主控芯片無法滿足高算力的要求。搭載Linux操作系統(tǒng)的GPU芯片雖然算力強(qiáng)大，可處理圖像識(shí)別、深度學(xué)習(xí)等復(fù)雜運(yùn)算，但安全性和穩(wěn)定性難以達(dá)到車規(guī)級(jí)要求。所以當(dāng)下車載域控制器都采用MCU+GPU的系統(tǒng)架構(gòu)。GPU上運(yùn)行圖像、深度學(xué)習(xí)和決策算法，MCU上運(yùn)行通信管理、電源管理、診斷管理等高實(shí)時(shí)性，高安全性的功能策略。MCU和GPU之間通過高帶寬的SPI或以太網(wǎng)實(shí)現(xiàn)數(shù)據(jù)傳輸。

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

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

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

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

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

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

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

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

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

Ini狀態(tài)定義為單MCU工作狀態(tài)。在Ini狀態(tài)下域控制器已可以正常通信，并能處理電源管理、通信管理、診斷功能的策略邏輯。故此時(shí)定義在該生命狀態(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啟動(dòng)后即可開始。

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

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

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

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

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

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

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

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

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

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

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

當(dāng)出現(xiàn)對(duì)MCU芯片供電的欠壓和過壓時(shí)，會(huì)導(dǎo)致MCU上程序運(yùn)行不可信，同時(shí)GPU端的供電也可能出現(xiàn)不可信。所以在MCU端5伏供電過壓或欠壓時(shí)，認(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)次生命周期中，不再啟動(dòng)MCU。

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

3.2? MCU與GPU間通信故障

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

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

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

3.3? 溫度監(jiān)控

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

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

PCB溫度由MCU監(jiān)控。實(shí)際溫度故障的閾值需要根據(jù)控制器熱仿真結(jié)果進(jìn)行判斷。我們根據(jù)圖3所示架構(gòu)圖做熱仿真。設(shè)定熱交換系數(shù)為10 W/m2K，初始?jí)毫?01 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 ℃時(shí)最高溫度已達(dá)到124 ℃，并且此時(shí)MCU 控制器內(nèi)環(huán)境溫度最高也達(dá)到了124 ℃。考慮到GPU極限溫度125 ℃，MCU極限溫度150 ℃，需要在此時(shí)做GPU下電處理。此時(shí)根據(jù)仿真結(jié)果，PCB板溫達(dá)到115 ℃。所以在MCU監(jiān)控板溫達(dá)到115 ℃時(shí)，生命周期管理需要從Fullrun->GPU Shutdown->Ini。當(dāng)在Ini狀態(tài)下監(jiān)控到PCB板溫低于110 ℃時(shí)，才會(huì)再次啟動(dòng)GPU。

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

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

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

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

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

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

5? 結(jié)? 論

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

參考文獻(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)的域控制器平臺(tái) [J].中國(guó)集成電路，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ā)方法和實(shí)踐 [J].中國(guó)集成電路，2021，30（Z1）：82-88.

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

3542500338261