DEM全稱“Diagnostic Event Management”,該模塊作為AUTOSAR架構中的BSW模塊之一,對于ECU軟件開發也是必需的軟件模塊,了解該模塊自身屬性以及與其他模塊的關系也顯得尤為重要。結合自身開發經驗,我將從以下六個方面對該模塊進行簡要介紹和幾點思考。
診斷故障管理模塊主要涉及到故障事件監控,故障信息上報、故障信息處理以及故障信息存儲等四個基本環節,它們之間的基本關系如下圖1所示:
圖1 故障上報流程圖
故障事件觸發
故障監控的基本單元是事件(event), 上報事件可以來自于BSW模塊,也可以來自SW-C模塊,事件的監控策略方式由各個上報故障事件的模塊自行決定,但故障事件定義需滿足圖2.1以下幾條基本原則:
圖2.1事件定義基本原則
如果未能按照上述基本原則去定義事件或者觸發方式,可能會出現故障事件重復上報、事件多報或者誤報等問題,甚至很難快速定位到問題所在,沒有真正起到事件監控應具備的基本特點:準確性、合理性、獨立性等。良好的故障事件定義將會為整個故障管理打下堅實的基礎,為故障分析提供一種強有力的手段。
2. 故障信息上報
經由BSW模塊或者SW-C模塊上報的故障事件,有多種上報方式,如通過RTE接口、DEM模塊標準接口來上報,一般是同屬于BSW的模塊直接調用RTE或者DEM標準接口均可,對于SW-C模塊則需要通過RTE來上報故障事件。其中,調用DEM標準接口時,也存在四種調用方式,如下圖2.2所示:
圖2.2故障上報五種方式 由圖中所示,上述5種上報方式的選擇,一般根據是否位于BSW模塊,是否需要上報相關環境數據、是否需要在診斷監控開啟之前監控等因素來決定。
3. 故障信息處理
當Dem模塊收到來自BSW或者SW-C模塊的故障事件及狀態會進行相應的處理,上報故障事件狀態可分為四種:PreFail、PrePass、Passed、Failed。其中前兩者需要經過TimeBased 或者CounterBased 的debouncing 策略來進一步判定故障是否成熟,而后二者則可以直接判別故障是否成熟。如下圖3所示:
圖3 故障信息處理流程圖
4. 故障信息存儲
經過上述診斷信息處理后,為了便于故障發生后能夠保留現場,因此需要將相關故障信息存儲至Flash或者EEPROM中,此文中先不過多討論故障信息如何在內存中存儲,若以何種方式存儲故障信息來區分,常規存儲故障信息方式一般有兩種,循環故障信息存儲與休眠時存儲;若以存儲區域劃分,可以分為內部故障信息存儲區(IFM)與客戶故障信息存儲區(CFM);通過分析優缺點、應用場合等維度來對故障信息存儲分析如下:
存儲方式 | 優缺點 | 應用對象 | 存儲區域 | 應用場合 |
循環存儲 | 能夠實時存儲故障信息,信息頻繁更新存儲,大量占用RAM | KL15 ECU | IFM | 詳細故障信息存儲,內部可見,客戶不可見。 |
休眠存儲 | 僅在ECU休眠時存儲,不會占用大量RAM,適用于大量故障信息的存儲。 | KL30 ECU | CFM | 常規故障信息存儲,內部及客戶均可見。 |
5.故障系統降級
當ECU系統檢測到任何故障時,按照功能安全的要求,系統將會作出相應的系統降級行為,以保證整車行車安全。按照AUTOSAR標準規范,圖4是從故障信息上報到系統降級的數據流程圖,故障上報給到DEM模塊,DEM模塊會先進行前期故障信息處理,后期將故障評估結果映射到FIM模塊,各模塊無論是BSW還是SW-C就會識別相應的FIM ID狀態來決定系統作出相應的反應。
圖4 系統故障降級數據流
6.故障監控存儲基本原則
在設計系統故障監控、故障信息預處理、故障存儲、故障降級等環節時,務必本著設計先行、故障依賴性明確、故障信息獲取全面、降級方式合理等原則來設計故障監控存儲系統,將能夠最大程度上來保證ECU系統的穩定性與魯棒性且大大提供故障分析效率并最終準確定位到問題所在。
審核編輯:劉清
-
FlaSh
+關注
關注
10文章
1638瀏覽量
148207 -
AUTOSAR
+關注
關注
10文章
363瀏覽量
21627 -
ecu
+關注
關注
14文章
890瀏覽量
54585 -
DEM
+關注
關注
0文章
23瀏覽量
15322 -
BSW
+關注
關注
0文章
15瀏覽量
3520
原文標題:AUTOSAR-DEM模塊幾點思考!
文章出處:【微信號:智能汽車電子與軟件,微信公眾號:智能汽車電子與軟件】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論