AUTOSAR是由全球汽車OEM和供貨商共同推出的一種汽車電子嵌入式軟件分層架構。該分層架構由微控制器抽象層、ECU抽象層、服務層、執行時環境(RTE)和應用層組成，前三層被統稱爲基礎軟件(BSW)。html
AUTOSAR各層軟件的通訊經過三類接口實現，分別是標準接口、AUTOSAR接口和標準AUTOSAR接口。其中，標準接口用於BSW各個模塊之間的通訊，已用C語言定義，如void Adc_Init(const Adc_ConfigType* ConfigPtr)。AUTOSAR接口用於軟件構件(SW-C)之間的通訊或者軟件構件和ECU固件(IO硬件抽象、複雜設備驅動)之間的通訊，這類接口命名以「Rte_」爲前綴。標準AUTOSAR接口用於軟件構件存取AUTOSAR服務。依賴這種分層架構和接口定義，AUTOSR顯著提升了汽車電子嵌入式軟件的可重用性——層級越高者，可重用性越強。值得注意的是：編程
* 微控制器抽象層層級最低，隨微控制器的更換而更換；網絡
* RTE雖然層級僅低於應用層，但因爲它負責着應用層和BSW之間的橋樑做用，和硬件的耦合性最高，不具備可重用性；架構
* 應用層(除傳感器、執行器相關的軟件構件外)徹底獨立於硬件，具備絕對的可重用性。spa
圖1：AUTOSAR分層架構。3d
汽車診斷簡介htm
目前，整車廠和供貨商採用在線診斷與脫機診斷相結合的診斷方法。在線診斷經過ECU內部軟硬件實現自診斷。在汽車執行過程當中，自診斷系統實時監控電子控制系統各組成部分的工做狀態，於是檢測電子控制系統中的故障。自診斷系統一方面將檢測出的故障經過必定的方式(好比警報指示燈)向駕駛員發出警告，另外一方面將故障程序代碼及相關數據存入ECU內存。脫機診斷經過外部診斷設備讀取相應的診斷信息，實現診斷做業。實現脫機診斷的關鍵在於如何實現診斷設備和ECU之間的通訊機制和診斷服務，即診斷協議。blog
目前，診斷協議標準主要分爲ISO和SAE兩種體系。美國使用SAE標準體系，包括中國在內的多數國家使用ISO標準體系。在乘用車領域，OEM正從自定義診斷協議逐漸轉向ISO標準。在商用車領域，OEM沿用SAE診斷，歐洲OEM在此基礎上增長了ISO診斷。表1列出了部分ISO和SAE標準對照。接口
AUTOSAR CAN診斷實現事件
1) 診斷服務
目前，AUTOSAR V3.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（現已支持）。
圖2：AUTOSAR CAN診斷相關模塊。
雖然AUTOSAR目前不支持上述服務，但並未限制開發者對其進行擴展。
2) 軟件架構
AUTOAR架構中和診斷相關的模塊如圖2所示。
FIM模塊的做用是根據DEM(Diagnostic Event Manager)報告的事件狀態使能或禁止軟件構件內部的功能實體。PDU Router(協議數據單元路由器)模塊僅負責轉發DCM(Diagnostic Communication Manager)和CAN TP(CAN Transport Layer)之間的I_PDU(交互層協議數據單元)，不會對數據進行任何修改。CAN Interface模塊、CAN Driver模塊和CAN Transceiver模塊負責L_PDU(數據鏈路層協議數據單元)的傳輸。
DEM、DCM和CAN TP是AUTOSAR架構中和診斷相關的核心模塊。
3) DCM
DCM模塊遵循ISO 14229-一、ISO 15031-五、ISO 15765-4和SAE J1979標準，能直接處理0x十、0x27和0x3E服務。收到AUTOSAR支持的OBD服務或其餘UDS服務時，靠叫DEM、軟件構件或者其餘BSW模塊提供的接口進行響應。
AUTOSAR建議用三個功能模塊組成DCM，分別是DSL(Diagnostic Session Layer)、DSD(Diagnostic Service Dispatcher)和DSP(Diagnostic Service Processing)。其中DSL負責處理PDU Router傳來的診斷請求，管理會話層和應用層定時參數，處理會話狀態的切換等。DSD負責將DSL傳來的診斷請求轉發給DSP，同時將DSP傳來的診斷響應報文傳給DSL。DSP負責分析接收到的診斷請求報文，檢查其報文格式以及其請求的子功能。只有在診斷請求報文的服務標識符、子功能、報文格式等條件都知足的狀況下，DSP纔會處理收到的請求報文，並將處理結果整理成診斷響應報文發給PDU Router。
4) DEM
DEM模塊遵循的標準與DCM相同，負責直接處理與DTC相關的服務，如UDS中的0x19服務(響應報文由DCM發送出去)。當軟件構件中的Monitor Function檢測到故障或BSW模塊檢測到故障時，將通知DEM模塊處理和儲存「診斷事件」(由Event ID進行標識)。若是故障確診，呼叫NVRAM Manager(非易失性內存管理器)提供的接口將其存取到非易失性內存中，同時通知應用層進行故障指示。DEM的狀態圖如圖3所示：
圖3：DEM狀態圖。
5) CAN TP模塊
遵循ISO 15765-2標準。負責診斷報文的尋址、拆包與打包，以及網絡層定時參數的管理。因此，該模塊向下傳輸的是N_PDU(網絡層協議數據單元)。
☆本文小結
第1、因爲嚴格分層，除了CAN Driver和CAN Transceiver模塊要依賴於硬件，AUTOSAR與診斷相關的模塊幾乎徹底獨立於硬件。按照此架構開發完成的診斷程序碼可以擺脫硬件的束縛，具備最大程度的可重用性。
第2、AUTOSAR目前不支持SAE J1939。
第3、暫時不能直接將AUTOSAR軟件架構用於Bootloder程序的開發。
綜上所述，AUTOSAR標準仍舊處於發展和完善階段，但隨着目前汽車ECU軟件開發矛盾的加重，開發難度不斷增大，開發週期卻不斷縮短，AUTOSAR將成爲必然趨勢。
AUTOSAR在CAN上的處理與咱們傳統的使用仍是有比較大的差別，過去咱們寫CAN的代碼，也就是寫了CAN基本的Tx和Rx驅動，收到原始8個bytes的數據後，進行什麼處理或者在哪一層處理都由本身隨意來定，有的甚至8bytes數直接在APP層用建模進行解析處理，這種狀況也很多見，也沒有不對。而AUTOSAR出於解耦，隔離及統一接口的因素考慮，將CAN作了多個層次的處理，再也不只是一個底層驅動+應用層（或增長一箇中間層）。
下面是AUTOSAR常見的介紹：
紅框部分是和通信相關的內容，包含LIN，CAN，Eth等，咱們重點介紹CAN。和汽車領域中你們熟知的和CAN相關最重要的三部分就是診斷，標定及COM。
咱們結合兩張圖中來看AUTOSAR中的分層和數據走向：
第一張圖中能夠看出根據不一樣的層次，CAN在不一樣的層次的數據包分爲了
* 數據鏈路層：L-PDU
* 網絡層（一般用的是TP層）：N-PDU
* 交互層：I-PDU
能夠看到CAN Driver和CAN Interface部分COM，XCP，UDS仍然是共用的，再往上就有不一樣的分支：
* UDS須要經過TP層，再進入PDUR進行分配進入DCM
* XCP相對獨立直接由CAN interface進入後獨立處理，不通過PDUR
* COM則從CAN Interface進入PDUR而後分配至COM
是否已經被各類PDU弄蒙圈了，下面是PDU和PDUR的官方解釋，一塊兒來理解一下：
PDU是「協議數據單元」的縮寫。PDU包含SDU和PCI。在傳輸端，PDU從上層傳遞到下層，下層將PDU解釋爲SDU。
1.提供不一樣抽象通訊控制器與上層之間的pdu路由
2.路由器的規模是特定於ECU的(若是隻有一個通訊控制器存在，則沒有大小)
3.實時提供TP路由。在緩衝完整的TP數據以前，會啓動TP數據的傳輸
簡單的說，PDU中包含地址信息（當前層和目標層的地址信息）和數據信息，PDUR經過地址信息分配到不一樣的目標地。下圖是PDU的組成，能夠加深理解
PDU包含PCI和SDU，PCI包含源地址和目標地址信息，SDU是數據信息。
在咱們關注的CAN傳輸中最關鍵的信息I-PDU，I-PDU並非某一層單獨全部的信息，也不是CAN單獨全部的內容，能夠在前一個圖中看出I-PDU是進出PDUR的信息。而I-PDU是包含地址信息和數據信息的。
最後拿你們最關注的COM來講明各層的數據走向，以收取報文來舉例：由CAN Driver收取報文生成L-PDU,然後進入CAN Interface進行抽象隔離處理，生成I-PDU，進入PDUR進行分配，根據地址信息（PCI）將進入COM模塊的I-PDU傳入COM，COM對I-PDU的數據信息SDU進行解析，生成signals，signals經過RTE傳輸給APP層，發送則正好相反