autosar中bsw架構組成_autosar診斷功能實作、資料流的方向

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

AUTOSAR各層軟體的通信通過三類接口實作，分别是标準接口、AUTOSAR接口和标準AUTOSAR接口。其中，标準接口用于BSW各個子產品之間的通信，已用C語言定義，如void Adc_Init(const Adc_ConfigType* ConfigPtr)。AUTOSAR接口用于軟體構件(SW-C)之間的通信或者軟體構件和ECU固件(IO硬體抽象、複雜裝置驅動)之間的通信，這類接口命名以“Rte_”為字首。标準AUTOSAR接口用于軟體構件存取AUTOSAR服務。依賴這種分層架構和接口定義，AUTOSR顯著提高了汽車電子嵌入式軟體的可重用性——層級越高者，可重用性越強。值得注意的是：

* 微控制器抽象層層級最低，随微控制器的更換而更換；

* RTE雖然層級僅低于應用層，但由于它負責着應用層和BSW之間的橋梁作用，和硬體的耦合性最高，不具有可重用性；

* 應用層(除傳感器、執行器相關的軟體構件外)完全獨立于硬體，具有絕對的可重用性。

圖1：AUTOSAR分層架構。

汽車診斷簡介

目前，整車廠和供貨商采用線上診斷與脫機診斷相結合的診斷方法。線上診斷通過ECU内部軟硬體實作自診斷。在汽車執行過程中，自診斷系統實時監控電子控制系統各組成部分的工作狀态，因而檢測電子控制系統中的故障。自診斷系統一方面将檢測出的故障通過一定的方式(比如警報訓示燈)向駕駛員發出警告，另一方面将故障程式代碼及相關資料存入ECU記憶體。脫機診斷通過外部診斷裝置讀取相應的診斷資訊，實作診斷作業。實作脫機診斷的關鍵在于如何實作診斷裝置和ECU之間的通信機制和診斷服務，即診斷協定。

目前，診斷協定标準主要分為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-1、ISO 15031-5、ISO 15765-4和SAE J1979标準，能直接處理0x10、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

DCM子產品遵循的标準與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(網絡層協定資料單元)。

本文小結

第一、由于嚴格分層，除了CAN Driver和CAN Transceiver子產品要依賴于硬體，AUTOSAR與診斷相關的子產品幾乎完全獨立于硬體。按照此架構開發完成的診斷程式碼能夠擺脫硬體的束縛，具有最大程度的可重用性。

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

第三、暫時不能直接将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中包含位址資訊(目前層和目标層的位址資訊)和資料資訊，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層，發送則正好相反

原文：https://www.cnblogs.com/still-smile/p/12143564.html