中心議題：

• 汽車診斷簡介
• AUTOSARCAN診斷實現

AUTOSAR是由全球汽車OEM和供應商共同推出的一種汽車電子嵌入式軟體分層架構。該分層架構由微控製器抽象層、ECU抽象層、服務層、執行時環境(RTE)和應用層組成，前叁層被統稱為基礎軟體(BSW)。

AUTOSAR各層軟體的通訊透過叁類介麵實現
，分別是標準介麵、AUTOSAR介麵和標準AUTOSAR介麵。其中，標準介麵用於BSW各個模組之間的通訊，已用C語言定義，如voidAdc_Init(constAdc_ConfigType*ConfigPtr)。AUTOSAR介麵用於軟體構件(SW-C)之間的通訊或者軟體構件和ECU韌體(IO硬體抽象
、複雜設備驅動)之間的通訊，這類介麵命名以‘Rte_’為前綴。標準AUTOSAR介麵用於軟體構件存取AUTOSAR服務。依賴這種分層架構和介麵定義
，AUTOSR顯著提高了汽車電子嵌入式軟體的再使用性──層級越高者，再使用性越強。值得注意的是：

*微控製器抽象層層級最低，隨微控製器的更換而更換;
*RTE雖然層級僅低於應用層，但由於它負責著應用層和BSW之間的橋樑作用，和硬體的耦合性最高

，不具有再使用性;
*應用層(除感測器、執行器相關的軟體構件外)完全獨立於硬體
，具有絕對的再使用性。


圖1AUTOSAR分層架構

汽車診斷簡介

目前，整車廠和供應商採用在線診斷與離線診斷相結合的診斷方法。在線診斷透過ECU內(nei)部(bu)軟(ruan)硬(ying)體(ti)實(shi)現(xian)自(zi)診(zhen)斷(duan)。在(zai)汽(qi)車(che)執(zhi)行(xing)過(guo)程(cheng)中(zhong)

，自(zi)診(zhen)斷(duan)係(xi)統(tong)即(ji)時(shi)監(jian)控(kong)電(dian)子(zi)控(kong)製(zhi)係(xi)統(tong)各(ge)組(zu)成(cheng)部(bu)份(fen)的(de)工(gong)作(zuo)狀(zhuang)態(tai)，因(yin)而(er)檢(jian)測(ce)電(dian)子(zi)控(kong)製(zhi)係(xi)統(tong)中(zhong)的(de)故(gu)障(zhang)。自(zi)診(zhen)斷(duan)係(xi)統(tong)一(yi)方(fang)麵(mian)將(jiang)檢(jian)測(ce)出(chu)的(de)故(gu)障(zhang)透(tou)過(guo)一(yi)定(ding)的(de)方(fang)式(shi)(比如警報指示燈)向駕駛員發出警告，另一方麵將故障程式碼及相關數據存入ECU記憶體。離線診斷透過外部診斷設備讀取相應的診斷資訊，實現診斷作業。實現離線診斷的關鍵在於如何實現診斷設備和ECU之間的通訊機製和診斷服務
，即診斷協議。

目前，診斷協議標準主要分為ISO和SAE兩種體係。美國使用SAE標準體係
，包括中國在內的多數國家使用ISO標準體係。在乘用車領域，OEM正從自定義診斷協議逐漸轉向ISO標準。在商用車領域，OEM沿用SAE診斷，歐洲OEM在此基礎上增加了ISO診斷。表1列出了部份ISO和SAE標準對照。

AUTOSARCAN診斷實現

1)診斷服務

目前，AUTOSARV3.1診斷部份支援9個OBD服務(如表2所示)

，14個UDS服務(如表3所示)。

依據表2和表3可知，AUTOSAR不支援OBD中的0x05服務(請求氧感測器監測結果)
，塬因在於基於CAN線的0x05服務在0x06中實現。不支援UDS中的0x28(通訊控製)
、0x34(程式下載)、0x35(程式上傳)、0x36(數據傳輸)和0x37(請求傳輸煺出)服務，且0x10服務不支援編程會話和擴展會話這兩種子功能。這些服務主要用於ECU重新編程，因此AUTOSAR不支援Bootloader。

圖2AUTOSARCAN診斷相關模組[page]

雖然AUTOSAR目前不支援上述服務，但並未限製開發者對其進行擴展。

2)軟體架構

AUTOAR架構中和診斷相關的模組如圖2所示。

FIM模組的作用是根據DEM(DiagnosticEventManager)報告的事件狀態使能或禁止軟體構件內部的功能實體。PDURouter(協議數據單元路由器)模組僅負責轉發DCM(DiagnosticCommunicationManager)和CANTP(CANTransportLayer)之間的I_PDU(交互層協議數據單元)，不會對數據進行任何修改。CANInterface模組、CANDriver模組和CANTransceiver模組負責L_PDU(數據鏈路層協議數據單元)的傳輸。

DEM、DCM和CANTP是AUTOSAR架構中和診斷相關的核心模組。

3)DCM

DCM模組遵循ISO14229-1

、ISO15031-5
、ISO15765-4和SAEJ1979標準，能直接處理0x10、0x27和0x3E服務。收到AUTOSAR支援的OBD服務或其他UDS服務時
，靠叫DEM、軟體構件或者其他BSW模組提供的介麵進行響應。

AUTOSAR建議用叁個功能模組組成DCM，分別是DSL(DiagnosticSessionLayer)、DSD(DiagnosticServiceDispatcher)和DSP(DiagnosticServiceProcessing)。其中DSL負責處理PDURouter傳來的診斷請求
，管理會話層和應用層定時參數，處理會話狀態的切換等。DSD負責將DSL傳來的診斷請求轉發給DSP
，同時將DSP傳來的診斷響應報文傳給DSL。DSP負責分析接收到的診斷請求報文
，檢查其報文格式以及其請求的子功能。隻有在診斷請求報文的服務標識符
、子功能、報文格式等條件都滿足的情況下，DSP才會處理收到的請求報文，並將處理結果整理成診斷響應報文發給PDURouter。

4)DEM

DCM模組遵循的標準與DCM相同，負責直接處理與DTC相關的服務
，如UDS中的0x19服務(響應報文由DCM發送出去)。當軟體構件中的MonitorFunction檢測到故障或BSW模組檢測到故障時
，將通知DEM模組處理和儲存‘診斷事件’(由EventID進行標識)。如果故障確診，呼叫NVRAMManager(非揮發性記憶體管理器)提供的介麵將其存取到非揮發性記憶體中
，同時通知應用層進行故障指示。DEM的狀態圖如圖3所示：
 

 圖3DEM狀態圖

5)CANTP模組

遵循ISO15765-2標準。負責診斷報文的尋址
、拆包與打包
，以及網路層定時參數的管理。所以，該模組向下傳輸的是N_PDU(網路層協議數據單元)。

第一
、由於嚴格分層，除了CANDriver和CANTransceiver模組要依賴於硬體，AUTOSAR與診斷相關的模組幾乎完全獨立於硬體。按照此架構開發完成的診斷程式碼能夠擺脫硬體的束縛，具有最大程度的再使用性。

第二、AUTOSAR目前不支援SAEJ1939。

第叁
、暫時不能直接將AUTOSAR軟體架構用於Bootloder程式的開發。

綜上所述
，AUTOSAR標準仍舊處於發展和完善階段
，但隨著目前汽車ECU軟體開發矛盾的加劇

，開發難度不斷增大，開發週期卻不斷縮短


，AUTOSAR將成為必然趨勢。