AUTOSAR是由全球汽車OEM和供貨商共同推出的一種汽車電子嵌入式軟件分層架構(gòu)。該分層架構(gòu)由微控制器抽象層、ECU抽象層、服務(wù)層、執(zhí)行時(shí)環(huán)境(RTE)和應(yīng)用層組成，前三層被統(tǒng)稱為基礎(chǔ)軟件(BSW)。

　　AUTOSAR各層軟件的通信通過三類接口實(shí)現(xiàn)，分別是標(biāo)準(zhǔn)接口、AUTOSAR接口和標(biāo)準(zhǔn)AUTOSAR接口。其中，標(biāo)準(zhǔn)接口用于BSW各個(gè)模塊之間的通信，已用C語言定義，如void Adc_Init(const Adc_ConfigType* ConfigPtr)。AUTOSAR接口用于軟件構(gòu)件(SW-C)之間的通信或者軟件構(gòu)件和ECU固件(IO硬件抽象、復(fù)雜設(shè)備驅(qū)動(dòng))之間的通信，這類接口命名以“Rte_”為前綴。標(biāo)準(zhǔn)AUTOSAR接口用于軟件構(gòu)件存取AUTOSAR服務(wù)。依賴這種分層架構(gòu)和接口定義，AUTOSR顯著提高了汽車電子嵌入式軟件的可重用性——層級(jí)越高者，可重用性越強(qiáng)。值得注意的是：

　　* 微控制器抽象層層級(jí)最低，隨微控制器的更換而更換；

　　* RTE雖然層級(jí)僅低于應(yīng)用層，但由于它負(fù)責(zé)著應(yīng)用層和BSW之間的橋梁作用，和硬件的耦合性最高，不具有可重用性；

　　* 應(yīng)用層(除傳感器、執(zhí)行器相關(guān)的軟件構(gòu)件外)完全獨(dú)立于硬件，具有絕對(duì)的可重用性。

圖1：AUTOSAR分層架構(gòu)。

　　汽車診斷簡介

　　目前，整車廠和供貨商采用在線診斷與脫機(jī)診斷相結(jié)合的診斷方法。在線診斷通過ECU內(nèi)部軟硬件實(shí)現(xiàn)自診斷。在汽車執(zhí)行過程中，自診斷系統(tǒng)實(shí)時(shí)監(jiān)控電子控制系統(tǒng)各組成部分的工作狀態(tài)，因而檢測電子控制系統(tǒng)中的故障。自診斷系統(tǒng)一方面將檢測出的故障通過一定的方式(比如警報(bào)指示燈)向駕駛員發(fā)出警告，另一方面將故障程序代碼及相關(guān)數(shù)據(jù)存入ECU內(nèi)存。脫機(jī)診斷通過外部診斷設(shè)備讀取相應(yīng)的診斷信息，實(shí)現(xiàn)診斷作業(yè)。實(shí)現(xiàn)脫機(jī)診斷的關(guān)鍵在于如何實(shí)現(xiàn)診斷設(shè)備和ECU之間的通信機(jī)制和診斷服務(wù)，即診斷協(xié)議。

　　目前，診斷協(xié)議標(biāo)準(zhǔn)主要分為ISO和SAE兩種體系。美國使用SAE標(biāo)準(zhǔn)體系，包括中國在內(nèi)的多數(shù)國家使用ISO標(biāo)準(zhǔn)體系。在乘用車領(lǐng)域，OEM正從自定義診斷協(xié)議逐漸轉(zhuǎn)向ISO標(biāo)準(zhǔn)。在商用車領(lǐng)域，OEM沿用SAE診斷，歐洲OEM在此基礎(chǔ)上增加了ISO診斷。表1列出了部分ISO和SAE標(biāo)準(zhǔn)對(duì)照。

　　AUTOSAR CAN診斷實(shí)現(xiàn)

　　1) 診斷服務(wù)

　　目前，AUTOSAR V3.1診斷部分支持9個(gè)OBD服務(wù)(如表2所示)，14個(gè)UDS服務(wù)(如表3所示)。

　　依據(jù)表2和表3可知，AUTOSAR不支持OBD中的0x05服務(wù)(請(qǐng)求氧傳感器監(jiān)測結(jié)果)，原因在于基于CAN線的0x05服務(wù)在0x06中實(shí)現(xiàn)。不支持UDS中的0x28(通信控制)、0x34(程序下載)、0x35(程序上傳)、0x36(數(shù)據(jù)傳輸)和0x37(請(qǐng)求傳輸退出)服務(wù)，且0x10服務(wù)不支持編程會(huì)話和擴(kuò)展會(huì)話這兩種子功能。這些服務(wù)主要用于ECU重新編程，因此AUTOSAR不支持Bootloader（現(xiàn)已支持）。

圖2：AUTOSAR CAN診斷相關(guān)模塊。

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

　　2) 軟件架構(gòu)

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

　　FIM模塊的作用是根據(jù)DEM(Diagnostic Event Manager)報(bào)告的事件狀態(tài)使能或禁止軟件構(gòu)件內(nèi)部的功能實(shí)體。PDU Router(協(xié)議數(shù)據(jù)單元路由器)模塊僅負(fù)責(zé)轉(zhuǎn)發(fā)DCM(Diagnostic Communication Manager)和CAN TP(CAN Transport Layer)之間的I_PDU(交互層協(xié)議數(shù)據(jù)單元)，不會(huì)對(duì)數(shù)據(jù)進(jìn)行任何修改。CAN Interface模塊、CAN Driver模塊和CAN Transceiver模塊負(fù)責(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)準(zhǔn)，能直接處理0x10、0x27和0x3E服務(wù)。收到AUTOSAR支持的OBD服務(wù)或其他UDS服務(wù)時(shí)，靠叫DEM、軟件構(gòu)件或者其他BSW模塊提供的接口進(jìn)行響應(yīng)。

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

　　4) DEM

　　DEM模塊遵循的標(biāo)準(zhǔn)與DCM相同，負(fù)責(zé)直接處理與DTC相關(guān)的服務(wù)，如UDS中的0x19服務(wù)(響應(yīng)報(bào)文由DCM發(fā)送出去)。當(dāng)軟件構(gòu)件中的Monitor Function檢測到故障或BSW模塊檢測到故障時(shí)，將通知DEM模塊處理和儲(chǔ)存“診斷事件”(由Event ID進(jìn)行標(biāo)識(shí))。如果故障確診，呼叫NVRAM Manager(非易失性內(nèi)存管理器)提供的接口將其存取到非易失性內(nèi)存中，同時(shí)通知應(yīng)用層進(jìn)行故障指示。DEM的狀態(tài)圖如圖3所示：

圖3：DEM狀態(tài)圖。

　　5) CAN TP模塊

　　遵循ISO 15765-2標(biāo)準(zhǔn)。負(fù)責(zé)診斷報(bào)文的尋址、拆包與打包，以及網(wǎng)絡(luò)層定時(shí)參數(shù)的管理。所以，該模塊向下傳輸?shù)氖荖_PDU(網(wǎng)絡(luò)層協(xié)議數(shù)據(jù)單元)。

　　☆本文小結(jié)

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

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

　　第三、暫時(shí)不能直接將AUTOSAR軟件架構(gòu)用于Bootloder程序的開發(fā)。

　　綜上所述，AUTOSAR標(biāo)準(zhǔn)仍舊處于發(fā)展和完善階段，但隨著目前汽車ECU軟件開發(fā)矛盾的加劇，開發(fā)難度不斷增大，開發(fā)周期卻不斷縮短，AUTOSAR將成為必然趨勢。

AUTOSAR在CAN上的處理與我們傳統(tǒng)的使用還是有比較大的差異，過去我們寫CAN的代碼，也就是寫了CAN基本的Tx和Rx驅(qū)動(dòng)，收到原始8個(gè)bytes的數(shù)據(jù)后，進(jìn)行什么處理或者在哪一層處理都由自己隨意來定，有的甚至8bytes數(shù)直接在APP層用建模進(jìn)行解析處理，這種情況也不少見，也沒有不對(duì)。而AUTOSAR出于解耦，隔離及統(tǒng)一接口的因素考慮，將CAN做了多個(gè)層次的處理，不再只是一個(gè)底層驅(qū)動(dòng)+應(yīng)用層（或增加一個(gè)中間層）。

下面是AUTOSAR常見的介紹：

紅框部分是和通訊相關(guān)的內(nèi)容，包含LIN，CAN，Eth等，我們重點(diǎn)介紹CAN。和汽車領(lǐng)域中大家熟知的和CAN相關(guān)最重要的三部分就是診斷，標(biāo)定及COM。

我們結(jié)合兩張圖中來看AUTOSAR中的分層和數(shù)據(jù)走向：

第一張圖中可以看出根據(jù)不同的層次，CAN在不同的層次的數(shù)據(jù)包分為了

* 數(shù)據(jù)鏈路層：L-PDU

* 網(wǎng)絡(luò)層（通常用的是TP層）：N-PDU

* 交互層：I-PDU

可以看到CAN Driver和CAN Interface部分COM，XCP，UDS仍然是共用的，再往上就有不同的分支：

* UDS需要通過TP層，再進(jìn)入PDUR進(jìn)行分配進(jìn)入DCM

* XCP相對(duì)獨(dú)立直接由CAN interface進(jìn)入后獨(dú)立處理，不經(jīng)過PDUR

* COM則從CAN Interface進(jìn)入PDUR然后分配至COM

是否已經(jīng)被各種PDU弄蒙圈了，下面是PDU和PDUR的官方解釋，一起來理解一下：

PDU是“協(xié)議數(shù)據(jù)單元”的縮寫。PDU包含SDU和PCI。在傳輸端，PDU從上層傳遞到下層，下層將PDU解釋為SDU。

1.提供不同抽象通信控制器與上層之間的pdu路由

2.路由器的規(guī)模是特定于ECU的(如果只有一個(gè)通信控制器存在，則沒有大小)

3.實(shí)時(shí)提供TP路由。在緩沖完整的TP數(shù)據(jù)之前，會(huì)啟動(dòng)TP數(shù)據(jù)的傳輸

簡單的說，PDU中包含地址信息（當(dāng)前層和目標(biāo)層的地址信息）和數(shù)據(jù)信息，PDUR通過地址信息分配到不同的目標(biāo)地。下圖是PDU的組成，可以加深理解

PDU包含PCI和SDU，PCI包含源地址和目標(biāo)地址信息，SDU是數(shù)據(jù)信息。

在我們關(guān)注的CAN傳輸中最關(guān)鍵的信息I-PDU，I-PDU并不是某一層單獨(dú)所有的信息，也不是CAN單獨(dú)所有的內(nèi)容，可以在前一個(gè)圖中看出I-PDU是進(jìn)出PDUR的信息。而I-PDU是包含地址信息和數(shù)據(jù)信息的。

最后拿大家最關(guān)注的COM來說明各層的數(shù)據(jù)走向，以收取報(bào)文來舉例：由CAN Driver收取報(bào)文生成L-PDU,而后進(jìn)入CAN Interface進(jìn)行抽象隔離處理，生成I-PDU，進(jìn)入PDUR進(jìn)行分配，根據(jù)地址信息（PCI）將進(jìn)入COM模塊的I-PDU傳入COM，COM對(duì)I-PDU的數(shù)據(jù)信息SDU進(jìn)行解析，生成signals，signals通過RTE傳輸給APP層，發(fā)送則正好相反

總結(jié)

以上是生活随笔為你收集整理的AUTOSAR诊断功能实现、数据流的方向，以及PDUSDU的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。