AUTO SARCAN診斷實(shí)現
加入技術(shù)交流群
2)軟體架構
AUTOAR架構中和診斷相關(guān)的模組如圖2所示。
FIM模組的作用是根據DEM(DiagnosticEventManager)報告的事件狀態(tài)使能或禁止軟體構件內部的功能實(shí)體。PDURouter(協(xié)議數據單元路由器)模組僅負責轉發(fā)DCM(DiagnosticCommunicationManager)和CANTP(CANTransportLayer)之間的I_PDU(交互層協(xié)議數據單元)，不會(huì )對數據進(jìn)行任何修改。CANInterface模組、CANDriver模組和CANTransceiver模組負責L_PDU(數據鏈路層協(xié)議數據單元)的傳輸。
DEM、DCM和CANTP是AUTOSAR架構中和診斷相關(guān)的核心模組。
3)DCM
DCM模組遵循ISO14229-1、ISO15031-5、ISO15765-4和SAEJ1979標準，能直接處理0x10、0x27和0x3E服務(wù)。收到AUTOSAR支援的OBD服務(wù)或其他UDS服務(wù)時(shí)，靠叫DEM、軟體構件或者其他BSW模組提供的介面進(jìn)行響應。
AUTOSAR建議用叁個(gè)功能模組組成DCM，分別是DSL(DiagnosticSessionLayer)、DSD(DiagnosticServiceDispatcher)和DSP(DiagnosticServiceProcessing)。其中DSL負責處理PDURouter傳來(lái)的診斷請求，管理會(huì )話(huà)層和應用層定時(shí)參數，處理會(huì )話(huà)狀態(tài)的切換等。DSD負責將DSL傳來(lái)的診斷請求轉發(fā)給DSP，同時(shí)將DSP傳來(lái)的診斷響應報文傳給DSL。DSP負責分析接收到的診斷請求報文，檢查其報文格式以及其請求的子功能。只有在診斷請求報文的服務(wù)標識符、子功能、報文格式等條件都滿(mǎn)足的情況下，DSP才會(huì )處理收到的請求報文，并將處理結果整理成診斷響應報文發(fā)給PDURouter。
4)DEM
DCM模組遵循的標準與DCM相同，負責直接處理與DTC相關(guān)的服務(wù)，如UDS中的0x19服務(wù)(響應報文由DCM發(fā)送出去)。當軟體構件中的MonitorFunction檢測到故障或BSW模組檢測到故障時(shí)，將通知DEM模組處理和儲存‘診斷事件’(由EventID進(jìn)行標識)。如果故障確診，唿叫NVRAMManager(非揮發(fā)性記憶體管理器)提供的介面將其存取到非揮發(fā)性記憶體中，同時(shí)通知應用層進(jìn)行故障指示。DEM的狀態(tài)圖如圖3所示：
圖3DEM狀態(tài)圖
5)CANTP模組
遵循ISO15765-2標準。負責診斷報文的尋址、拆包與打包，以及網(wǎng)路層定時(shí)參數的管理。所以，該模組向下傳輸的是N_PDU(網(wǎng)路層協(xié)議數據單元)。
第一、由于嚴格分層，除了CANDriver和CANTransceiver模組要依賴(lài)于硬體，AUTOSAR與診斷相關(guān)的模組幾乎完全獨立于硬體。按照此架構開(kāi)發(fā)完成的診斷程式碼能夠擺脫硬體的束縛，具有最大程度的再使用性。
第二、AUTOSAR目前不支援SAEJ1939。
第叁、暫時(shí)不能直接將AUTOSAR軟體架構用于Bootloder程式的開(kāi)發(fā)。
綜上所述，AUTOSAR標準仍舊處于發(fā)展和完善階段，但隨著(zhù)目前汽車(chē)ECU軟體開(kāi)發(fā)矛盾的加劇，開(kāi)發(fā)難度不斷增大，開(kāi)發(fā)週期卻不斷縮短，AUTOSAR將成為必然趨勢。
評論