AUTOSAR CAN診斷實現(xiàn)

　　雖然AUTOSAR目前不支援上述服務(wù)，但并未限制開發(fā)者對其進行擴展。

　　2) 軟體架構(gòu)

　　AUTOAR架構(gòu)中和診斷相關(guān)的模組如圖2所示。

　　FIM模組的作用是根據(jù)DEM(Diagnostic Event Manager)報告的事件狀態(tài)使能或禁止軟體構(gòu)件內(nèi)部的功能實體。PDU Router(協(xié)議數(shù)據(jù)單元路由器)模組僅負責(zé)轉(zhuǎn)發(fā)DCM(Diagnostic Communication Manager)和CAN TP(CAN Transport Layer)之間的I_PDU(交互層協(xié)議數(shù)據(jù)單元)，不會對數(shù)據(jù)進行任何修改。CAN Interface模組、CAN Driver模組和CAN Transceiver模組負責(zé)L_PDU(數(shù)據(jù)鏈路層協(xié)議數(shù)據(jù)單元)的傳輸。

　　DEM、DCM和CAN TP是AUTOSAR架構(gòu)中和診斷相關(guān)的核心模組。

　　3) DCM

　　DCM模組遵循ISO 14229-1、ISO 15031-5、ISO 15765-4和SAE J1979標(biāo)剩能直接處理0x10、0x27和0x3E服務(wù)。收到AUTOSAR支援的OBD服務(wù)或其他UDS服務(wù)時，靠叫DEM、軟體構(gòu)件或者其他BSW模組提供的介面進行響應(yīng)。

　　AUTOSAR建議用叁個功能模組組成DCM，分別是DSL(Diagnostic Session Layer)、DSD(Diagnostic Service Dispatcher)和DSP(Diagnostic Service Processing)。其中DSL負責(zé)處理PDU Router傳來的診斷請求，管理會話層和應(yīng)用層定時參數(shù)，處理會話狀態(tài)的切換等。DSD負責(zé)將DSL傳來的診斷請求轉(zhuǎn)發(fā)給DSP，同時將DSP傳來的診斷響應(yīng)報文傳給DSL。DSP負責(zé)分析接收到的診斷請求報文，檢查其報文格式以及其請求的子功能。只有在診斷請求報文的服務(wù)標(biāo)識符、子功能、報文格式等條件都滿足的情況下，DSP才會處理收到的請求報文，并將處理結(jié)果整理成診斷響應(yīng)報文發(fā)給PDU Router。

　　4) DEM

　　DCM模組遵循的標(biāo)視DCM相同，負責(zé)直接處理與DTC相關(guān)的服務(wù)，如UDS中的0x19服務(wù)(響應(yīng)報文由DCM發(fā)送出去)。當(dāng)軟體構(gòu)件中的Monitor Function檢測到故障或BSW模組檢測到故障時，將通知DEM模組處理和儲存‘診斷事件’(由Event ID進行標(biāo)識)。如果故障確診，唿叫NVRAM Manager(非揮發(fā)性記憶體管理器)提供的介面將其存取到非揮發(fā)性記憶體中，同時通知應(yīng)用層進行故障指示。DEM的狀態(tài)圖如圖3所示：

　　圖3 DEM狀態(tài)圖

　　5) CAN TP模組

　　遵循ISO 15765-2標(biāo)?。负扎愪Z媳ㄎ牡難爸貳⒉鳶與打包，以及網(wǎng)路層定時參數(shù)的管理。所以，該模組向下傳輸?shù)氖荖_PDU(網(wǎng)路層協(xié)議數(shù)據(jù)單元)。

　　結(jié)論

　　第一、由于嚴格分層，除了CAN Driver和CAN Transceiver模組要依賴于硬體，AUTOSAR與診斷相關(guān)的模組幾乎完全獨立于硬體。按照此架構(gòu)開發(fā)完成的診斷程式碼能夠擺脫硬體的束縛，具有最大程度的再使用性。

　　第二、AUTOSAR目前不支援SAE J1939。

　　第叁、暫時不能直接將AUTOSAR軟體架構(gòu)用于Bootloder程式的開發(fā)。

　　綜上所述，AUTOSAR標(biāo)嗜躍紗τ詵⒄購?fù)完善藉F危但隨著目前汽車ECU軟體開發(fā)矛盾的加劇，開發(fā)難度不斷增大，開發(fā)L期卻不斷縮短，AUTOSAR將成為必然趨勢。