知薦 | AUTOSAR基礎篇之EcuM

駕駛哥

2021年7月28日 10:22

瀏覽：3501 收藏：1

來源 | ADAS與ECU之吾見【焉知智車年會合作媒體】

前言

當你看到ECU從啟動狀態至正常運行狀態，再從正常運行狀態至休眠或關閉的過程時，你是否曾想過以下一些問題呢？

ECU是怎么啟動或關閉的呢？
ECU啟動方式有沒有一般規律呢？
按照AUTOSAR標準，ECU啟動過程又可分為哪幾個階段呢？
。。。。。。

今天，我們來一起探討并回答這些問題。為了便于大家理解，以下是本文的主題大綱：

熬夜肝文系列之技術干貨，閱讀稍長，但應有盡有，一文搞懂EcuM爽文，認真看完，也必定讓你有所收獲！

正文

EcuM模塊總體介紹

主要功能

EcuM模塊作為AUTOSAR中的標準模塊，全稱為（ECU State Management）。故名思義，指的就是ECU 的狀態管理，不過需特別強調的是ECU上下電流程的狀態管理，具體可以簡單概括為以下五個方面的內容：

Startup 初始化流程狀態管理；
ECU運行狀態管理；
ShutDown流程狀態管理；
Sleep流程狀態管理
Wakeup Source管理；

總狀態機（Flexible 與 Fixed）

在具體介紹上述5個狀態管理過程之前，我們有必要對ECU啟動過程有個總體的感性認識，以便于對后續各個階段的之間的關系有個較為清晰的了解。如下圖1所示，描述了一般情況下ECU的啟動流程。

在上述的ECU啟動過程中，可以看出ECU的一般啟動過程涉及到Boot，C_Init, EcuM，OS等模塊，在這些模塊的共同接力下保證BSW及RTE成功初始化，進而使得整個SW-C處于正常running的過程。

ECU啟動時，首先通過中斷向量表運行引導程序（俗稱BootLoader），Bootloader在滿足一定條件下跳轉至APP程序中的C_Init處并指向Main函數。

在Main函數中首先完成堆棧空間的初始化，然后調用EcuM_Init函數進入到后續的StartPreOS，StartOS階段。

在開啟OS的初始化函數中調用EcuM_StartupTwo進行第二啟動階段的初始化，最后就是進入StartPostOS階段，如完成BswM模塊的初始化，進而將控制權轉交給BswM模塊。

由于接力賽中首棒很關鍵，因此本文將重點關注EcuM模塊的啟動與關閉過程，按照AUTOSAR定義，EcuM可分為兩種模式：Flexible與Fixed模式。

Flexible 總狀態機，如下圖2-1所示：

在上圖中，Startup階段按照開始OS節點作為分水嶺，可分為StartPreOS與StartPostOS兩個階段。經歷過Startup階段之后，則會進入到UP階段。

在UP階段則是正常運行狀態，當條件滿足時，可以根據CPU是否進入到低功耗狀態還是OFF狀態，相應進入到Sleep階段與ShutDown階段，當然如果是Reset，那么也是先進入到Shutdown階段，最后跳轉至Startup階段。

若進入到Sleep階段之后，也存在著兩種CPU低功耗模式：Poll與Halt模式，后者比前者更節約電能且無需運行代碼，具體采用哪個則可根據當初的系統設計而定。

在該階段不會關閉OS，OS始終低功耗的running狀態，同時也會不斷的對喚醒源進行監控，若喚醒源滿足，則會直接跳轉至RUN階段。

若進入到Shutdown階段，會經歷兩個階段：OffPreOS與OffPostOS階段，前者則是為Shutdown OS之前所做的準備，后者則是關閉OS之后，選擇對應的函數執行關閉ECU還是重啟ECU的操作。

Fixed 總狀態機,如下圖2-2所示：

在上圖2-2中，較為清晰的描述了EcuM Fixed模式下五種狀態Startup，Shutdown，RUN，Sleep，Wakeup的狀態組成以及狀態切換的過程，其中OFF，Sleep，RUN是穩態，而Startup跟Wakeup則是暫態。

在Startup階段，同樣按照Flexible 模式中開啟OS為界限，分為Startup I與Startup II兩個階段；

當喚醒事件能夠控制CPU供電時，則需要進入Wakeup階段驗證Wakeup Event是否有效，相反如果不帶電源控制，則直接進入RUN階段。

若進入到RUN階段，可分為兩個階段：RUN II與RUN III兩個階段。其中RUN II指的是正常運行階段，RUN III則是SW-C為即將進入到ShutDown所需要做的前提準備。

若進入到ShutDown階段，首先會進入到PreShutDown階段，然后按照Shutdown的目標不同，可以分為reset，OFF，Sleep三條路徑。

如果Target為Sleep，則進入到Go Sleep階段，若在該階段檢測到喚醒事件，那么直接跳轉至Wakeup Validation階段。

如果Target為OFF或Reset，則需經歷Go OFF I與Go OFF II兩個階段，reset則會重新跳轉至Startup階段，而OFF則是直接關閉ECU。

若進入到Wakeup階段，則需要進行四個階段的喚醒源驗證，主要分為Wakeup I，Wakeup Validation，Wakeup Reaction，Wakeup II階段；

若進入到Sleep階段，則可以分為兩種Sleep模式：Sleep I 與Sleep II，一般兩者選其一。其中Sleep I階段（Halt），此階段不運行代碼，等待喚醒事件，然后跳轉至Wakeup階段；

其中Sleep II階段則為Polling階段，這個階段則會低功耗運行代碼，并且等待喚醒事件，如果存在，則進入到Wakeup階段。

Fixed與Flexible模式區別與聯系，從上述EcuM Fixed Mode與Flexible Mode的描述，便可知兩者存在著很多的相似點，同時也存在著彼此之間的差異，因此小T我將兩者的區別與聯系展現如下表1所示：

表1 EcuM Fixed與Flexible模式區別與聯系

由上分析可知，EcuM Flexible可以兼容Fixed模式，是傳統ECU的啟動過程的擴展，也可理解Flexible是Fixed模式的更高一層抽象，Fixed則可以稱作Flexible模式的一種表現形式。

同時Fixed模式明確了各個階段的狀態及狀態切換過程，而Flexible則更為靈活，可以實現多核啟動，局部快速啟動等特性，為了更好的了解Flexible模式的啟動思想，本文將以重點介紹Fixed模式下各狀態機的狀態機及切換過程，舉一反三。

按照EcuM的主體功能，對應的將從以下五個過程來展開講解EcuM Fixed Mode下的各狀態機狀態及狀態切換過程。

Startup Sequence : 完成啟動過程的初始化；
Run Sequence ：正常運行及退出運行狀態階段
ShutDown Sequence：shutdown 或Reset ECU的階段；
Sleep Sequence：ECU休眠階段;
Wakeup Sequence: ECU 驗證喚醒源階段；

Startup Sequence

STARTUP階段的目的就是初始化基礎軟件模塊，主要可分為兩個階段：啟動OS之前的初始化以及啟動OS之后的初始化，如下圖3所示，為Startup Sequence的頂層設計。

STARTUP I

如上圖3所示，通過調用EcuM_Init函數則進入到STARTUP I階段，在該階段主要會調用下列兩個Callout函數完成OS啟動前的初始化工作；

EcuM_AL_DriverInitZero：完成無需OS支持的底層硬件驅動的初始化或者其他低水平的初始化（無需postconfig），將這部分驅動的初始化稱為Init Block 0；
EcuM_AL_DriverInitOne：完成無需OS支持的底層硬件驅動的初始化或者其他低水平的初始化，將這部分驅動的初始化稱為Init Block 1;

STARTUP II

在STARTUP II階段則是在start os函數中調用EcuM_AL_DriverInitTwo ，隨后開啟RTE，最后調用函數EcuM_AL_DriverInitThree最后初始化那些需要NVM數據的BSW模塊。

EcuM_AL_DriverInitTwo ：需要OS支持但是無需使用NVM的BSW模塊初始化，并將此部分驅動的初始化稱為Init Block II；
EcuM_AL_DriverInitThree：需要OS支持同時也需要使用NVM的BSW模塊初始化，并將此部分驅動的初始化稱為Init Block III；

特別需要注意的是，STARTUP 1主要用于為start OS而作的驅動函數初始化，啟動時間應當盡可能短，而START UP II盡可能完成所有所需模塊的初始化。

且中斷一般不允許在startup I階段使用，如果需要使用，也只能使用Category I，不能使用Category II。

為了加深大家對Startup兩個階段的驅動模塊初始化的認識與理解，特此將其總結如下表2所示：

表2 StartUp階段驅動初始化列表

RUN Sequence

RUN階段可以劃分為以下兩個階段，一個是RUN II，表示正常工作狀態，另一個是RUN III，表示為進入到ShutDown所作的前提準備，頂層設計如下圖4所示：

RUN II

在RUN I階段則表明已完成了所有BSW模塊（包括OS及RTE）的初始化，開始運行SW-C程序。在該階段，將主要完成以下幾種操作：

通過調用函數ComM_CommunicationAllowed來使得相應的通信通道允許通信；
在該階段，EcuM將允許保持一個最小的運行事件EcuMRunMinimumDuration，以便讓SW-C有機會向EcuM模塊請求RUN Request；
在該階段也需要進行休眠總線的喚醒源驗證工作；
除非沒有通信請求，否則ComM不會釋放RUN Request，也就不會退出RUN II階段；

RUN III

當最后一個Run Request被釋放之后，EcuM就會進入到RUN III階段（即Post RUN 階段）。在PostRUN主要完成以下幾種操作：

在RUN III階段，如果Sw-C請求PostRun，那么就會停留在該狀態，SW-C可以運行其相應的代碼如存儲重要的數據等，直至釋放PostRun Request；
若在該階段存在RUN Request，那么就會立刻跳回到RUN II階段；
若既不存在RUN Request，也不存在PostRun Reqest，那么就會直接進入到ShutDown階段中的PreShutdown階段；

ShutDown Sequence

在ShutDown階段，主要根據ShutDown Target不同而進入不同的狀態機處理流程。如下圖5所示，總體上體現了根據Target不同而做出的不同狀態機處理。

圖5 ShutDown Sequence頂層設計

從上圖可知，不管ShutDown Target是什么，都會經歷PreShutdown階段，進入到該階段，主要完成以下操作：

De_Init所有的SW-C，同時保證通信協議棧處于關閉狀態。
清除所有的Wakeup Event；
關閉Dem模塊；
根據不同的ShutDown目標進入不同的狀態（Sleep或者OFF或者Reset）；

ShutDown Target

在ShutDown階段，ShutDown Target非常重要，因為其決定了ShutDown階段應當走何種路線。ShutDown Target可分為以下三種：

OFF：CPU掉電；
RESET：這屬于一個暫態，CPU Reset；
Sleep：CPU處于低功耗狀態，未掉電；

默認的ShutDown Target可以通過配置得到，當然SW-C可以直接調用函數接口 EcuM_SelectShutdownTarget來覆蓋掉默認的ShutDown Target。

Go Sleep

當ShutDown Target為Sleep時，那么就會進入到Go Sleep階段，在該階段主要完成以下操作：

調用NvM_WriteAll函數完成寫操作，同時開啟NVM寫超時計數器；
調用函數EcuM_EnableWakeupSources使能Wake up事件接收；
在該階段，OS并沒有關閉，處于正常Running狀態；
若此階段存在Pending Wakeup Event，則直接調用函數NvM_CancelWriteAll取消寫操作，然后直接跳轉Wakeup階段的Wakup Validation子狀態；
當Nvm_WriteAll成功執行完或者寫超時，則直接進入到Sleep階段；

Go OFF I

當ShutDown目標為OFF或者RESET時，則首先進入到該狀態。在該階段，主要完成以下幾種操作：

僅設置LIN的通信狀態為FALSE；
完成ComM，BswM的Deinit操作；
調用NvM_WriteAll函數完成寫操作，并開啟寫超時計數器；
等待NvM寫成功或者NvM寫超時，調用函數ShutdownOS關閉OS；
在ShutDown OS的過程中通過shutdown hook函數調用EcuM_ShutDown來進入OFF II階段；

Go OFF II

當ShutDown Target為OFF或者RESET時，經過OFF I階段就會最終調用EcuM_ShutDown進入到該階段，在該階段，主要完成以下幾種操作：

如果ShutDown Target是OFF，則調用Callout函數EcuM_AL_SwitchOff來直接斷掉CPU供電；
如果ShutDown Target是RESET，則調用Callout函數EcuM_AL_Reset進而調用MCAL標準函數Mcu_PerformReset來重啟CPU；