前言

上一篇中講只有Transceiver、Controller處于正常工作模式以后才能有效的收發(fā)報文，進而才能識別報文的類型（NM Message、XCPMessage、Diagnostic Message、APPMessage）。但識別出這些報文需要一個前提：ECU上電同時整個主程序運行起來，且需要一定的時間去識別報文類型。

項目中，喚醒事件（也稱喚醒源）有效性驗證為什么要設置一段時間？ECU上電，整個主程序如何運行起來？

本篇就上述問題進行分析。

喚醒事件有效性驗證時間分析

在實際的網絡管理項目中，大家可能會遇到這樣的需求：收到有效喚醒事件（如：網絡管理報文），網絡激活，報文正常收發(fā)；如果收到的報文是非網絡管理報文，ECU需要保持一定時間后休眠（如：ECU保持5s，即5s內ECU處于供電狀態(tài)）。注意后者網絡仍然在BSM（BusSleepMode），只能此時間內接收報文，不能發(fā)送報文。如果ECU在該時間內收到有效喚醒事件（多數是網絡管理報文，也可能是有效的Power ON信號報文），網絡將激活，進而進行正常的報文收發(fā)。

注意：ECU喚醒是網絡喚醒的前提條件，ECU喚醒并不一定網絡喚醒，如果網絡激活（進入NormalMode）則ECU一定喚醒（RUN模式）。

為什么要ECU保持一段時間呢?這里說一下個人理解，ECU自身并不知道喚醒事件是不是有效，ECU只要被供電就從啟動文件指定的位置開始執(zhí)行程序。如果要識別該喚醒事件是不是有效需要上層模塊（EcuM）識別，而EcuM從開始驗證到確認該事件的有效性需要調用底層模塊確認（如：Controller或者Transceiver），這需要時間，且EcuM的驗證和確認一般是異步執(zhí)行，這也需要時間。上述時間其實并不長，項目不同執(zhí)行的時間不等（每個項目初始化模塊數量和讀NVM時間不同），但多數在幾十毫秒內執(zhí)行完，但又為什么會要求1s或者5s或者更長呢？個人理解：ECU被喚醒，整個冷啟動（可以理解為與電壓相關的啟動）花費了“較長”的時間，廢了這么大勁立馬Shutdown有點“過分”，如果ECU下電又被干擾起來還需要重頭再來（各個模塊、外設初始化、讀NVM等），既然這樣還不如等待一段時間確定沒有有效喚醒事件以后，ECU再走Shutdown流程，進而避免ECU頻繁的喚醒->休眠->喚醒，注意是ECU，不是網絡被喚醒->休眠->喚醒，網絡只有有效喚醒源才能激活。

ECU上電，程序運行過程分析

ECU如果要正常的運行程序，則需要供電，之后程序開始執(zhí)行：啟動文件->BootLoader->Application，進入“main”函數，也就是我們熟知的用戶代碼程序。用戶代碼程序包含ASWC的runnable以及各個模塊的mainhandler（如：CanTrcv_30_Tja1145_MainFunction），這些程序在OS的調度下周期性或者事件觸發(fā)執(zhí)行，這也是上層模塊可以收到消息和處理消息的基礎。

這里主要分析EcuM管理的上電到程序運行過程。AUTOSAR中，EcuM分為Flexible和Fixed兩種類型，因為Fixed并不支持多核且不靈活，本文主要討論Flexible類型的EcuM。

如上圖(1)所示，CInitCode一般是應用程序的main函數，即EcuM_Init在應用程序的main函數被調用，EcuM將控制ECU的啟動流程，EcuM調用StartOS，讓Os完成Task的激活。

EcuM_Init并不能完成MCU所有的初始化動作，在StartPreOS Sequence階段主要完成DET模塊（最先完成初始化，以便其它模塊可以上報開發(fā)錯誤）以及一些硬件外設的初始化，如MCU、Port、Internal Watchdog等（主要根據項目需求設置要初始化的外設模塊）。

如上圖，EcuM_StartupTwo將完成SchM（Os），BSW模塊的初始化，其中各個模塊的初始化（Can_Init、CanIf_Init等）在BswM中完成。程序所需的所有外設、模塊初始化之后，啟動Scheduler 定時，即周期性的執(zhí)行BSW/SWCs任務，至此Application程序得以運行。



審核編輯：劉清