前言

在AUTOSAR中，Ecu的喚醒流程并不能簡單的看作是對各個外設模塊的供電動作。Autosar給了軟件開發(fā)人員很大的自由度去設計目標項目Ecu的喚醒動作，而自由度越大的代價就是開發(fā)人員需要很好的設計Ecu的喚醒時序，提供Ecu喚醒過程的魯棒性。

喚醒源的狀態(tài)

在EcuM中規(guī)定了喚醒源的4中狀態(tài)：NONE、PENDING、VALIDATED、EXPIRED。四種狀態(tài)關系的切換關系如下所示：

當Ecu上電時，喚醒源的初始狀態(tài)是NONE，當喚醒源狀態(tài)切換到NONE時，需要通知到BswM模塊，上圖也可以看出，喚醒源的每次狀態(tài)切換都需要通知到BswM模塊，通知接口：BswM_EcuM_CurrentWakeup。

EcuM是如何知道有喚醒事件呢？EcuM如果想知道有喚醒Ecu的事件，最好的方式就是給底層提供一個接口或者注冊一個回調(diào)，Autosar里規(guī)定了標準接口：EcuM_SetWakeupEvent。當有喚醒事件發(fā)生時，底層的硬件模塊（例如：Transceiver、Sensor）最先識別到，之后通過該接口上報給EcuM。

EcuM主函數(shù)會輪詢檢測底層上報的喚醒事件，如果想進一步的分析喚醒事件是不是有效的總線喚醒源（網(wǎng)絡管理報文），需要Ecu有正常的收發(fā)報文能力，想要收發(fā)報文，Transceiver和Controller兩個模塊均需要啟動。一般來講，Transceiver會在程序初始化時進入正常的工作模式，而Controller進入正常的工作模式是EcuM調(diào)用EcuM_StartWakeupSources的結(jié)果，而該接口的內(nèi)部功能的實現(xiàn)由開發(fā)者自行把控，autosar并未做硬性的要求。

啟動Transceiver和Controller，建立了報文的正常收發(fā)能力，Ecu即可進一步的將報文上報上層模塊，如：CanIf，即此時Ecu可以拿到總線的RawData，不管是不是網(wǎng)絡管理報文，Ecu都可以做進一步的功能實現(xiàn)，如收到診斷報文喚醒網(wǎng)絡等。

一般來說，會在EcuM模塊配置兩個時間參數(shù)，CheckWakeup和ValidateWakeup時間，如果CheckWakeup時間走完走完沒有判斷到有效的喚醒源，則調(diào)用EcuM_StopWakeupSources關閉喚醒源，這里多數(shù)關閉controller，進而Ecu失去通信能力。

ValidateWakeup時間參數(shù)配置與否決定了是否使用喚醒事件的驗證功能，如果配置該參數(shù)，且驗證喚醒事件有效后則通知ComM使能通信，調(diào)用ComM接口：ComM_EcuM_WakeupIndication。如果該參數(shù)沒有配置，則EcuM不在繞圈，直接通知BswM喚醒事件有效，通知ComM開啟通信。個人理解：該參數(shù)配置較合理。

第一：可以驗證喚醒事件的有效性，避免因總線抖動等干擾造成的非預期Ecu喚醒；

第二：如果使用的Transceiver沒有Pn功能，Ecu會因總線的擾動而不斷的喚醒，假設總線有應用報文沒有網(wǎng)絡管理報文，ValidateWakeup時間給0，Ecu將會不斷的走上下電流程，如果下電選擇OFF流程(實際項目中很多開發(fā)人員沒有開啟Reset流程的Operation,即直接冷啟動，這不符合autosar規(guī)范，也不安全)，將會帶來未知問題（如果Ecu內(nèi)核有一定時間內(nèi)喚醒次數(shù)限制，超過閾值則可能上鎖保護），設置該參數(shù)可以有效的延遲Ecu喚醒頻率。


審核編輯：劉清