
發(fā)布
注冊(cè)
/
登錄ECUM的案例
知薦 | AUTOSAR基礎(chǔ)篇之EcuM
表3 EcuM模塊常用函數(shù)列
汽車(chē)軟件RTOS-之AUTOSAR OS多核控制簡(jiǎn)介
Startup階段:
初始化MCU,每個(gè)核完成EcuM_Init() (AUTOSAR定義功能),且每個(gè)核完成StartOS。
2. 運(yùn)行階段:
從啟動(dòng)模式切換到操作系統(tǒng)運(yùn)行模式,完成OS:Startuphook,并開(kāi)始操作系統(tǒng)的運(yùn)行,e.g. 10ms, 100ms等周期性任務(wù)開(kāi)始運(yùn)行。
3. Shutdown階段:
從OS運(yùn)行模式切換到下電模式。下電關(guān)閉程序由BswM和EcuM協(xié)調(diào)。所有核上的EcuM都表明它們已經(jīng)準(zhǔn)備好了關(guān)閉,EcuM在主內(nèi)核上調(diào)用shutdownallcore(),完成整個(gè)ECU的下電。
在AUTOSAR OS中具體的分配策略有如下幾種:
1)ChainTask鏈任務(wù)機(jī)制
什么是ChainTask機(jī)制,AUTOSAR規(guī)范中又是如何定義的呢?一個(gè)鏈任務(wù)由幾個(gè)任務(wù)組成,每個(gè)鏈任務(wù)OS-Mechanism相互激活。所以不同的任務(wù)可以按照定義的順序在不同的核上執(zhí)行。
例如下圖所示。左邊是單核芯片core X,右邊是雙核芯片core Y和core Z。
原來(lái)任務(wù)Task A是單獨(dú)在單核芯片core X上運(yùn)行, Task A => proc1(); proc2(); proc3(); proc4()。當(dāng)把Task A拆分為兩個(gè)任務(wù)Task A’和Task A’’ 并且分別在2個(gè)單獨(dú)的核core Y和core Z上運(yùn)行時(shí),鏈任務(wù)ChainTask機(jī)制確保,流程順序是與任務(wù)A一樣,在不同的內(nèi)核中運(yùn)行。
跨核task又是如何開(kāi)銷(xiāo)ChainTask呢?例如下圖所示。
展開(kāi) AUTOSAR基礎(chǔ)篇之OS(下)
AUTOSAR多核OS啟動(dòng)與關(guān)閉
在AUTOSAR軟件基本架構(gòu)下,無(wú)論是單核操作系統(tǒng)還是多核操作系統(tǒng),都與EcuM模塊和BswM模塊息息相關(guān)。因?yàn)檫@兩類(lèi)模塊決定了OS啟動(dòng),初始化,運(yùn)行,關(guān)閉等狀態(tài)及其過(guò)程。
從之前文章
AUTOSAR基礎(chǔ)篇之EcuM
我們可以知道ECU工作過(guò)程可分為啟動(dòng)(STARTUP), 運(yùn)行(UP), 睡眠(SLEEP)以及關(guān)閉(SHUTDOWN)四種狀態(tài)。
ECU在上電前處于SHUTDOWN階段,上電后便進(jìn)入STARTUP階段,主要包括StartPreOS與StartPostOS兩個(gè)子階段。
在StartPreOS子階段主要完成一些OS啟動(dòng)之前的一些準(zhǔn)備工作,如初始化MCU,IO,WatchDog等模塊;
在StartPostOS子階段則是啟動(dòng)OS之后的階段,該階段主要執(zhí)行初始化BSW的調(diào)度器以及初始化BswM模塊兩個(gè)動(dòng)作,如下圖4所示。
圖4 ECU啟動(dòng)流程
由于ECU詳細(xì)的啟動(dòng)過(guò)程在
?AUTOSAR基礎(chǔ)篇之EcuM?
文章中已有大量篇幅介紹,本文就不再贅述,只是作為一個(gè)引子,大家如果有興趣,可以閱讀了解一下。
多核OS啟動(dòng)過(guò)程
當(dāng)然無(wú)論是否存在OS,多核的啟動(dòng)過(guò)程相比單核與硬件關(guān)系則更為密切。
通常情況下,硬件會(huì)首先啟動(dòng)一個(gè)核作為主核(Master Core),而從核(Slave Core)則由軟件啟動(dòng),這種啟動(dòng)方式被稱(chēng)為主從模式。AUTOSAR規(guī)范定義了多核啟動(dòng)方式應(yīng)該為主從模式。
展開(kāi) 一文輕松理解AUTOSAR之Watchdog協(xié)議棧(上)
Watchdog使用實(shí)踐心得
通過(guò)EcuM模塊來(lái)完成看門(mén)狗初始化之后,剛開(kāi)始設(shè)置的看門(mén)狗Counter初始值盡可能能夠Cover住Watchdog Driver初始化至Watchdog Manager初始化的時(shí)間,否則容易造成狗超時(shí)。
在OS shutdown之前Watchdog Manager去初始化,在去初始化過(guò)程中需要設(shè)置成較大的Timeout值,以確保能夠覆蓋住Watchdog Manager去初始化至系統(tǒng)power down或者再次reset的過(guò)程。
如果ECU支持休眠模式,如果在ECU休眠情況下看門(mén)狗仍保持在活躍狀態(tài),那么就需要在EcuM模塊中來(lái)完成看門(mén)狗的喂狗操作。
在系統(tǒng)初始化以及休眠兩個(gè)階段應(yīng)重點(diǎn)考慮看門(mén)狗是否會(huì)存在超時(shí)的可能,如果底層硬件都無(wú)法來(lái)得及喂狗,將會(huì)對(duì)系統(tǒng)造成重大影響。
展開(kāi) 
AUTOSAR基礎(chǔ)篇之BswM
Mode Indication則總是來(lái)源于BSW模塊,比如CANSM,EcuM,WdgM等。
在圖中也可以看到定義了模式請(qǐng)求的一些規(guī)則條件,如只有Normal_Mode為T(mén)RUE且IFC1_Bus_Off為False時(shí),條件成立為T(mén)RUE,其他情況則為False。
由此可見(jiàn),模式仲裁過(guò)程中的規(guī)則條件也就是真值表達(dá)式,而真值表達(dá)式的結(jié)果就是模式仲裁之后的結(jié)果,并作為下一環(huán)節(jié)模式控制過(guò)程的輸入。
圖1 模式仲裁過(guò)程
上述過(guò)程中提到的Mode Indication 與 Mode Request都是以同等的地位在BswM中接收仲裁,且這兩種類(lèi)型都可以在AUTOSAR標(biāo)準(zhǔn)配置項(xiàng)BswMModeRequestSource得以體現(xiàn)。
同時(shí)BswM模塊會(huì)通過(guò)調(diào)用其他BSW模塊如EcuM,COM,ComM,
SM,PduR的標(biāo)準(zhǔn)接口來(lái)獲取每個(gè)模塊的當(dāng)前狀態(tài)作為模式仲裁的輸入。
但需要注意的是如果在調(diào)用這些標(biāo)準(zhǔn)接口之后返回的結(jié)果為錯(cuò)誤(E_NOT_OK),那么BswM模塊可以設(shè)置DTC來(lái)告知上層這一錯(cuò)誤或者取消當(dāng)前正在執(zhí)行的Action List。
模式控制過(guò)程
模式控制指的是基于上述上述模式仲裁的結(jié)果(TRUE or FALSE)執(zhí)行相應(yīng)的行為序列。
這些行為序列通常稱(chēng)為“Action List”,且這些Action List都是有序的,也就意味著可根據(jù)項(xiàng)目需要自由配置各類(lèi)Action的執(zhí)行順序。
圖2 模式控制過(guò)程
如上圖2所示, 每一個(gè)Action List可以對(duì)應(yīng)1個(gè)或者多個(gè)行為,AUTOSAR支持實(shí)現(xiàn)不同行為的自由組合與復(fù)用。
展開(kāi) AUTOSAR 架構(gòu)下看門(mén)狗的理解
WdgIf模塊,WdgM通過(guò)WdgIf接口更改WdgDriver的驅(qū)動(dòng)模式,同時(shí)通知看門(mén)狗觸發(fā)條件
EcuM模塊,管理WdgM的Initializing 和DeInitializing狀態(tài),在Sleep模式下出發(fā)硬件看門(mén)狗
Mcu模塊,在WdgM監(jiān)控程序失敗之后,可以通過(guò)Mcu的接口Mcu_PerformReset立即重新ECU單元
Det模塊,診斷開(kāi)發(fā)中的錯(cuò)誤
Dem模塊,WdgM 在偵測(cè)到錯(cuò)誤之后,可以通過(guò)Dem模塊觸發(fā)Event
SchM模塊,WdgM 調(diào)用SchM模塊接口WdgM_GlobalSuspendInterrupts進(jìn)入臨界區(qū),WdgM_GlobalRestoreInterrupts退出臨界區(qū)
Rte模塊,Rte通過(guò)WdgM_CheckpointReached()接口,監(jiān)控SWC是否按照設(shè)計(jì)運(yùn)行
BswM模塊,WdgM在監(jiān)控Spuervised Entity失敗后,可以通過(guò)BswM模塊重啟被監(jiān)控程序
OS模塊,周期性調(diào)度Task通過(guò)WdgM_MainFunction()調(diào)用WdgM_UpdateTickCount()接口為WdgM提供時(shí)間戳
具體框圖如下:
02
模塊配置
1、Wdg
Wdg Driver提供三種喂狗模式給WdgM管理,WdgM可以通過(guò)Wdg_SetMode接口設(shè)置看門(mén)狗運(yùn)行模式
WdgSettingFast 快速喂狗
WdgSettingOff 關(guān)閉看門(mén)狗
WdgSettingSlow 慢速喂狗
Wdg External Trigger Counter :外部定時(shí)器,定時(shí)調(diào)用Cbk函數(shù),
展開(kāi) AUTOSAR基礎(chǔ)篇之OS(上)
通常會(huì)將一些基礎(chǔ)軟件的模式管理主函數(shù)映射到
Not Trusted OS Application
中的任務(wù),如
EcuM_Mainfunction,BswM_Mainfunction, Can_Mainfunction_Mode()
等周期性狀態(tài)查詢(xún)函數(shù),當(dāng)然前提這些軟件模塊的安全級(jí)別為QM。
接下來(lái),將針對(duì)這5大基本對(duì)象分別展開(kāi)講述各個(gè)對(duì)象的基本特點(diǎn)與用途,以便大家在對(duì)OS配置的過(guò)程中有一個(gè)更為清晰的認(rèn)識(shí)。
Task
基本任務(wù)與擴(kuò)展任務(wù)
AUTOSAR OS中存在兩種任務(wù):基本任務(wù)(Basic Task)和擴(kuò)展任務(wù)(Extended Task)。基本任務(wù)則存在以下三種狀態(tài):
運(yùn)行狀態(tài)(Running):
處于運(yùn)行狀態(tài)的任務(wù)可能被高優(yōu)先級(jí)任務(wù)或者中斷搶占從而進(jìn)入就緒狀態(tài),且同一Core中任何時(shí)刻只會(huì)存在一個(gè)任務(wù)處于運(yùn)行狀態(tài),任務(wù)運(yùn)行結(jié)束后則將自己掛起進(jìn)入阻塞狀態(tài);
就緒狀態(tài)(Ready):
處于就緒狀態(tài)的任務(wù)由調(diào)度器決定是否啟動(dòng)進(jìn)入運(yùn)行狀態(tài),且該狀態(tài)時(shí)任務(wù)切換至運(yùn)行狀態(tài)的前提;
阻塞狀態(tài)(Suspend):
處于阻塞狀態(tài)的任務(wù)是被動(dòng)的,可以由API函數(shù)或Alarm激活進(jìn)入就緒狀態(tài);
擴(kuò)展任務(wù)與之相比,則多了一個(gè)等待狀態(tài)(Waiting),解釋如下:
等待狀態(tài)(Waiting):
當(dāng)任務(wù)的運(yùn)行需要等待某一或某些事件被置位時(shí),任務(wù)進(jìn)入就緒狀態(tài)。
基本任務(wù)的代碼示例如下:
#include “OS.h”
TASK(BasicTask)
{
...
展開(kāi)