前言
Dem是AUTOSAR中配置項最多,實現功能最為復雜的模塊之一,主要負責記錄故障診斷以及其關聯數據,是實現診斷功能至關重要的模塊,本文將以最簡單的方式將Dem的功能聊具體,聊透徹。為了方便大家學習,以下是本文的大綱。
1.診斷故障基礎
當人患了疾病,便需要醫(yī)治,醫(yī)生根據各種檢驗結果找出病因,并得出診治策略。當汽車出現故障時,DTC故障碼就等同于“檢驗結果”,汽車工程師通過該標識碼便可以查表的方式獲得該故障信息,如故障觸發(fā)條件、故障解除條件、系統(tǒng)功能表現等,得出解決該故障的策略。 DTC(DiagnosticTrouble Code)顧名思義診斷故障碼,一種用來記錄當ECU發(fā)生或者檢測到某種故障時呈現給大家的標識碼。
1.1 DTC的組成
DTC故障碼是一個4個字節(jié)的標識符,由以下兩部分組成:DTC Catogory與Failure Type,其中DTC Catogory 又可以根據Powertrain、Body、Chasis、N etwork四大子系統(tǒng)來進一步定義其范圍,簡稱PBCU四大子系統(tǒng),如下表所示:
1.2 DTC的意義
故障碼有以下兩點意義:
1)產線下線檢測:一輛車的零部件的開發(fā),系統(tǒng)集成,整車組裝,其中涉及的流程之長,零部件數量之多,可以說是相當復雜。為了產線生產的車能正常下線,安全上路,就需要確保在車輛下線前,各零部件本身以及零部件相互配合是沒有問題的。因此在產線電檢流程中,會讀取整車故障碼,通過故障碼說明車輛是否正常。
2)車輛維修:當車輛出故障時,維修工程師是如何快速定位到故障零部件呢?車輛是由上萬個零部件組成,如果依賴于維修工程根據經驗慢慢排查,效率會極其低下。因此,維修工程師會使用診斷儀讀取整車故障碼,并將故障碼與故障現象對照,快速得出維修策略。
1.3 DTC故障類型
以非排放相關的ECU為例,可以將DTC故障類型分為以下幾個部分:
硬件故障:如RAM、Flash、CPU時鐘等硬件本身失效的問題
軟件故障:如配置字故障,標定故障或客戶定義的軟件功能性故障
外部環(huán)境故障:電壓過高或者欠壓、環(huán)境溫度過高或過低等
通訊相關故障:如報文丟失、信號無效,Checksum/Rolling 障等
1.4DTC狀態(tài)位介紹
每個DTC都有一個字節(jié)用來表示該故障的狀態(tài),這個字節(jié)中每個bit的含義如下:
status Of DTC: bit field name | Bit | Bit state | Description |
testFailed | 0 | 0 | DTC is not failed at the time of the request |
testFailedThisOperationCycle | 1 | 0 | DTC failed during the current operation cycle |
pendingDTC | 2 | 0 |
DTC was not failed on the current or previous operation cycle |
confirmedDTC | 3 | 0 | DTC is not confirmed at the time of the request |
testNotCompletedSinceLastClear | 4 | 0 | DTC test was completed since the last code clear |
testFailedSinceLastClear | 5 | 0 | DTC test never failed since last code clear |
testNotCompletedThisOperationCycle | 6 | 0 | DTC test completed this operation cycle |
warningIndicatorRequested | 7 | 0 | Server is not requesting warningIndicator to beactive |
具體解釋如下: Bit0:請求時刻測試結果為失??; Bit1:在當前點火循環(huán)至少失敗過1次;
Bit2:在當前或者上一個點火循環(huán)測試結果不為失??;
Bit3:請求時刻DTC被確認,一般確認是在一個點火周期內發(fā)生錯誤1次;
Bit4:自上次清除DTC之后測試結果已完成,即測試結果為PASS或者FAIL結果;
Bit5:自上次清除DTC后測試結果都不是FAIL;
Bit6:在當前點火周期內測試結果已完成,即為PASS或FAIL狀態(tài);
Bit7:ECU沒有得到點亮警示燈請求
1.5凍結幀與擴展數據
從上文可知,DTC中8bit位可以描述DTC狀態(tài),但8個bit位能夠承載的信息是有限的,僅能說明故障是當前故障還是歷史故障。故障發(fā)生時的車速,溫度,油量,電量等關鍵信息怎么記錄呢?
UDS中規(guī)定了凍結幀可以用來記錄故障發(fā)生時的詳細情況,擴展數據可以提供故障碼相關的擴展信息,包括老化計數器。
類型 | 組成 | 內容 |
凍結幀 | 由一系列DID組成,用戶可以自定義DID內容 | 描述車速,溫度,油量,等信息 |
擴展信息 | 由一系列DID組成,DID內容由BSW規(guī)定 | 描述故障碼的額外信息,比如老化周期數量。 |
2.DEM詳解
2.1 DEM主要功能
Dem全稱Diagnostic Event Manager,負責診斷故障事件的處理,存儲診斷故障事件以及故障事件相關聯的數據(故障發(fā)生時溫度,車速等)。簡而言之,Dem發(fā)揮了AUTOSAR架構中故障”中央處理器作用”,用戶軟件模塊只需要將故障上報給DEM,所有故障信息的處理都由DEM執(zhí)行:
1.故障確認前:用戶模塊上報故障的Debounce防抖處理,確保對應故障不為誤報故障。
2. 故障確認時:故障事件確認時的故障數據存儲至NVM,保證故障能長期保存。
3. 故障確認后:故障的老化,替代,實現故障修復后,故障能被清除的功能。例如,儀表上的發(fā)動機故障燈,在發(fā)動機修好后一段時間后就會熄滅。
2.2 DEM與其他模塊關系
1)DEM在AUTOSAR架構位置
Dem位于AUTOSAR架構系統(tǒng)服務層,系統(tǒng)服務層提供了以下服務:
1.操作系統(tǒng)調度與監(jiān)控服務、
3.存儲服務
4.診斷服務(UDS通信服務以及故障服務)
5.ECU狀態(tài)管理服務
從下面架構圖可以看出,Dcm與Dem作為“診斷雙雄”,完整提供了所有的診斷服務。區(qū)別在于,Dcm主修“UDS診斷通信服務”,對下與通信協(xié)議棧聯系,與外部診斷儀交互提供診斷通信服務(10,22等服務);Dem主修故障診斷服務,與上層SWC,BSW模塊交互,接收故障上報,與NVM交互使用存儲功能。
???
AUTOSAR架構圖
???
2)Dem與其他模塊依賴關系
???
Dem與其他模塊關系鏈路圖
???
NVM: Nvm能夠提供存儲服務給Dem使用,即提供診斷故障存儲所需的NVM BLOCK。需要注意的是,Nvm給Dem提供了兩類存儲服務接口,Nvm_WriteBlock()供DEM實時存儲診斷故障,NvM_SetRamBlockStatus()供Dem下電存儲診斷故障,上述存儲模式可以在DTC配置屬性中體現。
DCM:從上圖中可以看出,DCM在接收到診斷儀的19服務(get Dtc),14服務(Clear Dtc)時,需要實時通過Dem獲取DTC數據以及對DTC進行清除操作。
ECUM:對Dem模塊執(zhí)行初始化以及ShutDown操作。
SWC(Monitor):監(jiān)控診斷故障事件Event,通過使用Dem_SetEventStatus()函數,將Event狀態(tài)上報給Dem。使用Dem_SetOperationCycleState()對操作循環(huán)狀態(tài)進行控制。
2.3 DEM核心Event
在介紹DEM的具體功能前,先引入概念“Diagnosticevent”,“Diagnostic event”也是DEM模塊中最重要的元素。對于AUTOSAR軟件架構,DTC只是展示給診斷儀使用者,而Event才是DTC狀態(tài)實際操控者,同時Event也是診斷NVM數據存儲實際控制者。
各位讀者肯定會有如下問題:
為什么要引入 “Diagnostic event”呢?
“Diagnostic event”來源?
“Diagnostic event”有哪些特性呢?
“Diagnostic event”怎么控制DTC?
“Diagnostic event”怎么控制診斷數據存儲?
接下來將會給大家一一解答上述問題。
1)Event與DTC的聯系與區(qū)別
區(qū)別:
1.描述層級:DTC是系統(tǒng)層面對于故障的描述,而Event是軟件層面對故障監(jiān)控的最小單元。
例子:某個電機故障會由電壓過高造成,但軟件是無法直接識別該故障,軟件只能監(jiān)控是否產生了電壓過高的時間Event,從而計算出是否產生DTC.
2.鏈接關系:多個event可以mapping 同一個DTC;而同一個event不能mapping 多個DTC;
3.可見度:DTC可以直接可見,但Event需通過進一步手段才能看到,有時僅對ECU供應商可見;
聯系:
1.DTC代表某類event集中表現,而event則是某個DTC的具體實例;
2.event的優(yōu)先級決定了DTC的優(yōu)先級;
3.event之間的依賴關系決定了DTC的依賴關系;
2)“Diagnostic event的上報方式
上文提到了SWC監(jiān)控故障Event的狀態(tài),并可以通過Dem_SetEventStatus(EventId,EventStatus)向DEM上報Event狀態(tài)。那么對于SWC,應該怎樣上報Event狀態(tài)呢?周期調用Dem_SetEventStatus上報即為周期循環(huán)上報;當Event狀態(tài)變化時,調用Dem_SetEventStatus上報為觸發(fā)上報。兩種上報方式各有優(yōu)缺點,如下圖所示,切不可一刀切。
一般來說,對于小型控制器,需要上報Event數量不多,可以選擇周期循環(huán)上報。
對于域控制器,需要上報的Event數量龐大,為了保證負載率穩(wěn)定,應該選擇觸發(fā)上報。
3)“Diagnostic event”有哪些特性呢?
1.Event Kind
Event Kind根據故障事件上報方式可分為:BSW Event與SWC Event。
Event Kind | 來源 | 上報方式 | 函數名 |
BSW Event | BSW模塊 | 標準C接口 | Dem_ReportErrorStatus |
SWC Event | SWC模塊 | RTE接口 | SetEventStatus(RTE) |
2.Event priority
對于診斷,能夠存儲的故障事件以及對應凍結幀等相關數據的數量是恒定的,需要軟件開發(fā)工程師提前配置。當內部存儲的故障事件已經滿了,Event優(yōu)先級可以解決新的故障事件如何存儲的問題。
一般來說,診斷優(yōu)先級的設定由診斷系統(tǒng)工程師從整車功能出發(fā),根據診斷故障的重要性,安全性,嚴重性綜合評估。比如汽車的動力故障遠比空調故障嚴重,所以動力相關故障優(yōu)先級一般會大于空調相關故障。
診斷事件優(yōu)先級有下面幾個重要特點:
1)診斷事件優(yōu)先級數值越小,優(yōu)先級越高,數值為1優(yōu)先級最大。
2)Event優(yōu)先級僅在診斷事件已經存滿情況下發(fā)揮作用,其余情況根據FIFO原則存儲。
3.Event occurrence
Event occurrence顧名思義就是故障事件上報計數器,故障上報次數越多,Event occurrence值越大,標志著該故障越“老”?!靶隆薄稀收?a target="_blank">標簽在后續(xù)新的故障事件如何存儲的仲裁機制上也會發(fā)揮重要作用,這部分內容在后面的內容會詳細說明。
Event occurrence存在以下特點,如下所示:
1.每一個event memory entry都有對應的Event occurrence。
2.Event occurrence最大值為255。
3.Event occurrence的計數方式有如下兩種配置選擇:
配置屬性 | 計數方式 |
DEM_PROCESS_OCCCTR_TF | Bit0(TestFail)由0跳變至1,Event occurrence +1 |
DEM_PROCESS_OCCCTR_CDTC | Bit0(TestFail)由0跳變至1和Bit3由0跳變至1,Event occurrence +1 |
2.4 EventMemory存儲內容
上文對Event,凍結幀,擴展數據等作了詳細描述,那么,這些數據在DEM中是怎么存儲的呢?DEM提供了Event Memory概念,將Event,凍結幀,擴展數據全部歸納起來做了統(tǒng)一管理。廢話不多說,開始探索Event Memory吧。
EventMemory分類:
類型 | 含義 |
DemPrimaryMemory | 存儲EventId,故障狀態(tài),凍結幀,擴展數據 |
DemMirrorMemory | |
Permanent Event Memory | 用于存儲OBD相關的DTC |
Event Memory的組成架構如下圖所示:
Event Memory組成架構圖
S1:Dem模塊必須支持PrimaryMemory,Mirror和Permanent memory可根據用戶需要具體選擇,一般用不上。
S2: Primary Memory是一個大小為DemMaxNumberEventEntryPrimary用于存儲故障數據的非易失性存儲空間。也就是PrimaryMemory由DemMaxNumberEventEntryPrimary個EventMemory Entry組成。
本質上,DemMaxNumberEventEntryPrimary設置為多少,NVM就會提供多少個NVMBlock用于存儲Primary Memory,就只能存儲多少個Event信息。
S3:每個Event Memory Entry存儲的內容有:EventId,Occurance Counter,凍結幀,擴展數據,老化周期等。
2.5 EventMemory management
當SWC或者BSW上報Event后,會經過哪些處理最終變成Flash中的Event Memory呢?
從下圖中可以看出,Event上報后需要經過下列處理: Event使能條件檢測
Event控制DTC Bit位更新 Event Memory Retention
Event Memory management流程圖
1)Event使能條件檢測
Event使能條件就相當于Dem中的一個閘門,只有在條件合適的情況下Event才能真正進入Dem的處理流程中。
Event使能條件流程圖
從圖中可以看出,Event上報至最終能到第二階段Event控制DTC bit位跳變,需要經歷很多流程,接下來對上述流程進行詳解。
S1:首先,需要判斷當前是否開啟了操作循環(huán),操作循環(huán)一般指的是點火循環(huán),一個操作循環(huán)可以認為是DTC檢測的一個周期。如果操作循環(huán)開啟了,則開始下列的Enable Condition判斷,否則直接退出整個Event Memorymanagement流程。
S2::EnableCondition判斷指的是Event上報增加的一個附加條件判斷,Dem通過對應的接口給SWC使用,SWC實現附件條件處理。一般可以用來處理一些電壓,車輛模式等限制條件。如果Enable Condition條件滿足,則進行85服務判斷;如果Enable Condition條件不滿足,則直接退出Event Memorymanagement流程。
S3: 若現在使用了85服務抑制DTC使能,則直接退出整個Event Memory management流程。若沒有執(zhí)行85服務,開始Event Debounce流程。
S4:經過Debounce后,如果最終Event結果為Pass或者Fail,則開始下一階段Event控制DTC跳變;否則直接跳出退出整個Event Memory management流程。
Event Debounce “Debounce”顧名思義,指對于Event的防抖處理,防止Event誤報導致DTC誤報。 SWC通過Dem_SetEventStatus(EventId,EventStatus)上報Passed/Failed/PrePassed/Prefailed四種狀態(tài)。 1)當SWC上報Passed和Failed狀態(tài)時,Dem不需要進行Debounce處理。 2)當SWC上報Prefailed和Prepassed狀態(tài)時,Dem需要進行Debounce處理。
本質上,Dem提供的Debounce為通過特定機制,處理PrePassed/Prefailed至Passed/Failed狀態(tài)變化。
Dem提供了兩種Debounce機制,即“Base Time”和“Base Counter”。
1.基于計數器的Debounce策略
基于Counter的Debounce策略的幾個重要參數如下表格:
參數 | 含義 |
FDC(Fault Detection Counter) | 錯誤計數器,值范圍為-128-127 |
DemDebounceCounterFailedThreshold | 使Event診斷事件狀態(tài)最終為Failed的Debounce Counter閾值 |
DemDebounceCounterPassedThreshold | 使Event診斷事件狀態(tài)最終為Passed的Debounce Counter閾值 |
DemDebounceCounterIncrementStepSize | 當SWC上報Prefailed,錯誤計數器增加量 |
DemDebounceCounterDecrementStepSize | 當SWC上報Prepassed,錯誤計數器增加量 |
基于Couneter的Debounce機制
如上圖所示,在基于Counter的Deboucne機制中,Dem會提供一個計數器(FDC)用于記錄判斷的結果,當SWC上報給Dem的Event狀態(tài)為Prefialed,計數器會按照步長增加,當達到設定的限值時,故障狀態(tài)變成Failed。當上報狀態(tài)為PrePassed時,計數器按照步長減少,當達到設定的限值時,故障狀態(tài)變成Passed。
2.基于時間的Debounce策略
基于時間的Debounce策略的幾個重要參數如下表格:
參數 | 含義 |
DebounceTimeBasedTaskTime | 基本的檢測周期 |
DemDebounceTimeFailedThreshold | 定義故障狀態(tài)從PreFailed跳轉至Failed需要多少個DebounceTimeBasedTaskTime周期 |
DemDebounceTimePassedThreshold | 定義故障狀態(tài)從PrePassed跳轉至Passed需要多少個DebounceTimeBasedTaskTime周期 |
基于時間的Debounce機制
在這種策略下,當SWC開始上報Event狀態(tài)后,Dem模塊會提供一個計時器用于記錄判斷的結果,計時器的增長方向由Event狀態(tài)決定。當計時器累積到一定閾值后,故障狀態(tài)變?yōu)镻assed或者Failed。
3)Event 控制DTC狀態(tài)更新
當Event經過一系列處理,最終能夠對DTC狀態(tài)進行更新,DTC 8個bit更新邏輯如下:
DTC Bit0 更新邏輯
Bit位更新 | 條件 |
0 -> 1 | 經Debounce后最終上報狀態(tài)為Failed |
1 -> 0 |
經Debounce后最終上報狀態(tài)為Passed OR 使用14服務清除DTC OR 復位事件狀態(tài) |
DTC Bit0 更新邏輯圖
DTC Bit1更新邏輯
Bit位更新 | 條件 |
0 -> 1 | 經Debounce后最終上報狀態(tài)為Failed |
1 -> 0 |
操作循環(huán)更新 OR 使用14服務清除DTC |
DTC Bit1 更新邏輯圖
DTC Bit2更新邏輯
Bit位更新 | 條件 |
0 -> 1 | 經Debounce后最終上報狀態(tài)為Failed |
1 -> 0 |
(操作循環(huán)更新 AND TestFailedThisOperationCycle == 0) OR 使用14服務清除DTC OR TestNotCompeleteThisOperationCycle == 0 |
DTC Bit2 更新邏輯圖
DTC Bit3更新狀態(tài)
Bit位更新 | 條件 |
0 -> 1 |
經Debounce后最終上報狀態(tài)為Failed AND Fialure Counter > = 故障確認閾值 |
1 -> 0 |
達到老化條件 OR 使用14服務清除DTC OR 故障溢出被替換 |
DTC Bit3 更新邏輯圖
DTC Bit4更新邏輯
Bit位更新 | 條件 |
0 -> 1 | 經Debounce后最終上報狀態(tài)為Failed |
1 -> 0 | 使用14服務清除DTC |
DTC Bit4 更新邏輯圖
DTC Bit5更新邏輯
Bit位更新 | 條件 |
0 -> 1 | 經Debounce后最終上報狀態(tài)為Failed |
1 -> 0 | 使用14服務清除DTC |
DTCBit5 更新邏輯圖
DTC Bit6更新邏輯
Bit位更新 | 條件 |
0 -> 1 | 經Debounce后最終上報狀態(tài)為Failed |
1 -> 0 |
使用14服務清除DTC OR 操作循環(huán)更新 |
DTCBit6更新邏輯圖
DTC Bit7更新邏輯
Bit位更新 | 條件 |
0 -> 1 |
經Debounce后最終上報狀態(tài)為Failed AND 點燈條件滿足 |
1 -> 0 |
使用14服務清除DTC OR 點燈條件不滿足 |
DTCBit7更新邏輯
4)Retention條件檢測
當DTC狀態(tài)完成更新后,Dem將開始進行Retention條件檢測。Dem給用戶提供多種策略用以判斷是否需要分配Event Memory Entry。分配策略由配置DemEventMemoryEntryStorageTrigger決定,具體如下面表格所示:
DemEventMemoryEntryStorageTrigger | 分配條件 |
DEM_TRIGGER_ON_TEST_FAILED | DTC bit0 由0跳變成1 |
DEM_TRIGGER_ON_CONFIRMED | DTC bit3 由0跳變成1 |
DEM_TRIGGER_ON_PENDING | DTC bit2 由0跳變成1 |
DEM_TRIGGER_ON_FDC_THRESHOLD |
DTC bit0 由0跳變成1 OR DTC bit1由0跳變成1 OR DTC bit2由0跳變成1 OR DTC bit3由0跳變成1 |
5)Event Memory Retention處理
Event上報經過了使能條件檢測,Event控制DTC Bit位狀態(tài)更新,Retention條件檢測重重難關,最終被允許進入Event Memory,Dem會怎樣將Event(DTCs),DTC狀態(tài),快照,擴展數據存入Event Memory中呢?
基本思路如下:
Event Memory Retention處理機制
S1:在Event Mmeory所有Event Mmeory Entry中搜索,檢查該Event及相關數據是否已經存入Event Memory中,如果已經存在,則進入Event MemoryEntry Storage。如果不存在,則在Event Memory中尋找空間用于存儲Event內容,如果Event Memory中空間已滿,則需要使用Replacement機制。
S2:當進入Event memory Storage,Occurance Counter需要加1,判斷是否需要更新凍結幀,擴展數據。 EventDisplacement處理 Event Memory存儲了數量為DemMaxNumberEventEntryPrimary的Event MemoryEntry,當Event Memory Entry已滿,需要進行Replacement,即根據一定的策略決定新增的Event如何存儲。Dem模塊提供了一套完善的機制用于Replacement,該機制有三個核心原則:
1.Event Priority(數字越小存儲優(yōu)先級越高)
2.Event Active或者Event Passive狀態(tài)(Active優(yōu)先級高于Passive優(yōu)先級)
3.Event Occurance Counter(最近發(fā)生的存儲優(yōu)先級高于之前發(fā)生的)
被替換的Event對應DTC中Bit2,Bit3 ,Bit5會被設置為0.
下圖展示了整套Event Displacement機制,體現了三個核心原則在替換機制中的作用。
Event Displacement機制
總結
DEM是以DTC為核心的AUTOSAR基礎軟件模塊,實現了對DTC的監(jiān)控上報,存儲等功能,如果需要對AUTOSAR診斷進行進一步學習,還需要對DCM,Doip,Cantp等模塊進行系統(tǒng)性學習。
-
數據
+關注
關注
8文章
7002瀏覽量
88940 -
配置
+關注
關注
1文章
188瀏覽量
18375 -
DEM
+關注
關注
0文章
23瀏覽量
15304
原文標題:一文讀懂AUTOSAR系列 – DEM功能詳解
文章出處:【微信號:汽車電子嵌入式,微信公眾號:汽車電子嵌入式】歡迎添加關注!文章轉載請注明出處。
發(fā)布評論請先 登錄
相關推薦
評論