前言

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

項(xiàng)目中，喚醒事件（也稱喚醒源）有效性驗(yàn)證為什么要設(shè)置一段時(shí)間？ECU上電，整個(gè)主程序如何運(yùn)行起來(lái)？

本篇就上述問(wèn)題進(jìn)行分析。

喚醒事件有效性驗(yàn)證時(shí)間分析

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

注意：ECU喚醒是網(wǎng)絡(luò)喚醒的前提條件，ECU喚醒并不一定網(wǎng)絡(luò)喚醒，如果網(wǎng)絡(luò)激活（進(jìn)入NormalMode）則ECU一定喚醒（RUN模式）。

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

ECU上電，程序運(yùn)行過(guò)程分析

ECU如果要正常的運(yùn)行程序，則需要供電，之后程序開(kāi)始執(zhí)行：?jiǎn)?dòng)文件->BootLoader->Application，進(jìn)入“main”函數(shù)，也就是我們熟知的用戶代碼程序。用戶代碼程序包含ASWC的runnable以及各個(gè)模塊的mainhandler（如：CanTrcv_30_Tja1145_MainFunction），這些程序在OS的調(diào)度下周期性或者事件觸發(fā)執(zhí)行，這也是上層模塊可以收到消息和處理消息的基礎(chǔ)。

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

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

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

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



審核編輯：劉清