來源：喬美昀 , 韋天文/上汽通用五菱汽車股份有限公司隨著現(xiàn)代汽氣車上集成的ECU越來越多，整車網(wǎng)絡(luò)戒來越復(fù)雜。診斷通信作為車載網(wǎng)絡(luò)中的一個重要功能，開發(fā)周期和難度也不斷增加。為了提高軟件的復(fù)用率和可移植性，縮短開發(fā)周期，全球汽車制造商、零部件供應(yīng)商、半導(dǎo)體供應(yīng)商及工具供應(yīng)商共同制定了 AUTOSAR標(biāo)準(zhǔn)。AUTOSAR標(biāo)準(zhǔn)的核心是剝離 ECU 軟件開發(fā)對硬件的依賴，為此它將軟件分為應(yīng)用層軟件組件（SW Component）、基礎(chǔ)軟件包（Basic Software）和運(yùn)行時環(huán)境（RTE），AUTOSAR標(biāo)準(zhǔn)如圖1所示。本文在深入研究 AUTOSAR標(biāo)準(zhǔn)的設(shè)計思想和軟件體系后，參照AUTOSAR 標(biāo)準(zhǔn)街推薦的診斷通信架構(gòu)，開發(fā)了一個基于CAN 總線的、具有通用性和可移植性的診斷通信協(xié)議棧。1. 診斷通信協(xié)議?？傮w架構(gòu)為了實(shí)現(xiàn)網(wǎng)絡(luò)通信系統(tǒng)開發(fā)的標(biāo)準(zhǔn)化，國際標(biāo)準(zhǔn)組織（ISO）制定了 OSI模型。這個模型把網(wǎng)絡(luò)通信分為7個工作層，分別是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層和應(yīng)用層。ISO在后來制定的診斷通信協(xié)議中，如 ISO15765、ISO14229、ISO15031，也按照 OS模型對診斷通信進(jìn)行了分層，并用具體的診斷通信協(xié)議對每層做了詳細(xì)的規(guī)定。隨著診斷通信協(xié)議的不斷完善，已經(jīng)形成一套完整的診斷通信架構(gòu)（見表 1）。根據(jù)應(yīng)用范圍的不同，診斷通信分為2種∶ 一種是與排放無關(guān)的診斷，叫增強(qiáng)型診斷，即UDS診斷;一種是與排放相關(guān)的診斷，叫OBD診斷。傳統(tǒng)的診斷通信協(xié)議棧的開發(fā)，基本都是按照診斷協(xié)議中OST模型來建立整體架構(gòu)的。但診斷通信的OST模型并沒有在具體功能的開發(fā)上提供參考，這就導(dǎo)致不同的汽車制造商按照各自的軟件開發(fā)標(biāo)準(zhǔn)開發(fā)出各自專用的診斷通信軟件，其中有的診斷通信軟件在診斷應(yīng)用層直接操作硬件，這些都造成汽車診斷通信軟件缺乏通用性和可移植性。1.2 AUTOSAR 標(biāo)準(zhǔn)的診斷通信協(xié)議棧架構(gòu)AUTOSAR 標(biāo)準(zhǔn)基于傳統(tǒng)的OSI模型，為診斷通信軟件的開發(fā)提供了一套完整的解決方案。協(xié)議棧的硬件平臺根據(jù)選用的芯片、連接的方式及具體的布局而異，但根本原理都是一致的，CAN控制器是硬件的核心，通過不同的CAN收發(fā)器接到不同的CAN總線上。基礎(chǔ)軟件的微控制器抽象層主要解決硬件的底層驅(qū)動問題，對應(yīng)在診斷通信協(xié)議棧中是CAN驅(qū)動層。當(dāng)將診斷通信協(xié)議棧移植到其他硬件平臺上，只需對 CAN 驅(qū)動做相應(yīng)的更改，上層軟件則可以完全復(fù)用。ECU抽象層，也叫硬件抽象層，主要解決上層軟件和硬件驅(qū)動之間的接口問題，對應(yīng)在診斷通信協(xié)議棧中是CAN接口層。CAN接口層抽象了CAN控制器的位置和ECU的硬件布局，提供了一種平等訪問總線通道的機(jī)制而無需考慮這些控制器的物理位置。服務(wù)層用于給應(yīng)用程序提供可用的服務(wù)，在診斷通信協(xié)議棧里通過3個層次實(shí)現(xiàn)∶CAN傳輸層、Pdu路由層和 DCM 層。CAN 傳輸層主要解決多幀傳輸?shù)膯栴}，完成數(shù)據(jù)的打包和重組。Pdu 路由層是考慮到車載網(wǎng)絡(luò)中有多種通信方式共存，實(shí)現(xiàn)不同通信數(shù)據(jù)的中轉(zhuǎn)，可以對上層屏蔽通信方式的細(xì)節(jié)。DCM是服務(wù)層，也是整個診斷通信協(xié)議棧的核心。DCM 處理診斷儀發(fā)送來的服務(wù)請求消息，然后執(zhí)行相應(yīng)的操作，最后返回響應(yīng)消息給診斷儀，整個過程涉及診斷會話的管理、診斷服務(wù)的調(diào)度及診斷服務(wù)的執(zhí)行。本文采用 freescale 高性能芯片 MC9S12XEQ512 的開發(fā)板作為診斷通信協(xié)議棧開發(fā)和測試的硬件平臺，該芯片內(nèi)部集成5個支持 CAN 20B 標(biāo)準(zhǔn)的 CAN控制器，與之配套的 CAN 收發(fā)器采用 82C250 芯片。本文開發(fā)的診斷通信協(xié)議棧，選擇實(shí)現(xiàn)UDS診斷服務(wù)， OBD服務(wù)會在以后進(jìn)行擴(kuò)展。整個協(xié)議棧的開發(fā)采用由下往上的方式，DCM以下的模塊作為基本CAN通信軟件一起開發(fā)，DCM作為診斷應(yīng)用層單獨(dú)開發(fā)。首先制定代碼文件結(jié)構(gòu)，然后分別進(jìn)行基本CAN通信軟件的數(shù)據(jù)傳輸、通信模式控制和時間管理功能的開發(fā)，最后進(jìn)行 DCM層診斷服務(wù)處理功能的開發(fā)。2.1 診斷通信協(xié)議棧的文件結(jié)構(gòu)AUTOSAR 的模塊化思想很大程度上體現(xiàn)在代碼文件結(jié)構(gòu)的規(guī)范上。在AUTOSAR 標(biāo)準(zhǔn)里，診斷通信是作為一個完整的汽車電控系統(tǒng)的子系統(tǒng)進(jìn)行開發(fā)的。診斷通信協(xié)議棧中的子模塊不僅會調(diào)用各自的頭文件，也會調(diào)用 ECU 級別的頭文件，所以在保證代碼的系統(tǒng)性的同時，也導(dǎo)致代碼結(jié)構(gòu)較為龐大復(fù)雜。本文旨在單獨(dú)實(shí)現(xiàn)診斷通信的功能，因此對代碼結(jié)構(gòu)做了一定的簡化，整個診斷通信協(xié)議棧的代碼文件結(jié)構(gòu)如圖2所示。其中，Can_GeneralTypesh定義了通用 CAN協(xié)議棧底層模塊的數(shù)據(jù)類型。ComStack_Typesh定義了與在線通信模塊 Com 相關(guān)的數(shù)據(jù)類型，主要是數(shù)據(jù)協(xié)議單元。Std_Typesh定義了 Autosar標(biāo)準(zhǔn)專有的數(shù)據(jù)類型，如版本信息和一些狀態(tài)模式的宏定義。每個子模塊都有若干c 文件，主要定義僅限于本模塊使用的數(shù)據(jù)類型、常量和函數(shù)。每個用子模塊名稱命名的頭文件xxxh定義本模塊中被外部引用的數(shù)據(jù)類型、變量和服務(wù)。xxx_Cfgh 定義了模塊在預(yù)編譯階段用于配置的數(shù)據(jù)。xxx_Cbkh 和用 2 個模塊名稱命名的xxx1_xxx2h 聲明了某模塊被低層模塊調(diào)用的回調(diào)函數(shù)。xxx_Typesh 定義模塊專用數(shù)據(jù)類型。2.2 數(shù)據(jù)傳輸功能的開發(fā)數(shù)據(jù)傳輸功能是基本通信軟件的核心功能。本文為所有模塊開發(fā)了數(shù)據(jù)傳輸接口，用于數(shù)據(jù)的收發(fā)、處理和格式轉(zhuǎn)換。 整個診斷通信協(xié)議棧的數(shù)據(jù)傳輸過程如下; 當(dāng)總線上有數(shù)據(jù)發(fā)送過來時，首先經(jīng)過 CAN 控制器硬件過濾，即進(jìn)行標(biāo)識只符的匹配過濾。如果通過過濾，CAN驅(qū)動將通過中斷或輪詢間的方式觸發(fā) read （） 操作取出 CAN 控制器硬件接收緩沖區(qū)的數(shù)據(jù)，然后調(diào)用 Canlf RxIndication （）將數(shù)據(jù)傳遞至 CAN接口層，CAN 接口通過查詢標(biāo)識符列表對數(shù)據(jù)進(jìn)行軟件過濾后，再調(diào)用上層的 xxx _Rxlndication （）進(jìn)一步處理和傳遞數(shù)據(jù)，最后通過 Dcm __RxIndication （）將數(shù)據(jù)傳遞到 DCM層。當(dāng)發(fā)送數(shù)據(jù)時，高層模塊通過依次調(diào)用低層模塊的 xxx _Transmit（）將數(shù)據(jù)往底層傳遞，最后通過 Can_Write（）將數(shù)據(jù)寫入 CAN控制器的發(fā)送緩沖區(qū)，數(shù)據(jù)再根據(jù)傳送緩沖優(yōu)先級依次發(fā)送到總線上，低層模塊成功發(fā)送數(shù)據(jù)后通過返回 xxx TxConfirmation（）告知上層模塊。 在 AUTOSAR 標(biāo)準(zhǔn)中，CAN通信協(xié)議棧的硬件可以包含多個 CAN控制器，但統(tǒng)一由同一個CAN驅(qū)動管理。CAN驅(qū)動是協(xié)議棧里面唯一可以直接訪問和操作硬件的模塊，它通過分配給每個CAN 控制器的 ID 獲得對它們的訪問。本文只采用了一個 CAN控制器，用于實(shí)現(xiàn)ECU 和診斷系統(tǒng)在單一網(wǎng)絡(luò)中的通信。CAN驅(qū)動和上層模塊的信息交互都要經(jīng)過 CAN 接口層來傳遞。CAN 接口 層和驅(qū)動層之間的數(shù)據(jù)傳輸遵照 ISO11898-1 協(xié)議，對應(yīng)于 OSI模型中的數(shù)據(jù)鏈路層，主要解決數(shù)據(jù)幀格式，實(shí)現(xiàn)標(biāo)準(zhǔn)幀和擴(kuò)展幀的收發(fā)，數(shù)據(jù)單元格式為 L-PDU。單幀傳輸時，CAN接口層直接和 PduR 層進(jìn)行信息交互。AUTOSAR 為 PduR 與其他模塊之間的數(shù)據(jù)交換定義了一個交互層，PduR 通過查詢 I-PDU 標(biāo)識符列表對數(shù)據(jù)進(jìn)行路由選擇，數(shù)據(jù)格式為I-PDU。多幀傳輸時，CAN接口層和 PduR 層之間需要 CAN傳輸層來進(jìn)行數(shù)據(jù)的打包和拆包。CAN傳輸層和 PduR 層之間仍遵照交互層。CAN 接口層和 CAN傳輸層之間的數(shù)據(jù)傳輸遵照 ISO15765-2，對應(yīng)于OSI模型中的網(wǎng)絡(luò)層，主要完成尋址和多幀傳輸?shù)目刂?，?shù)據(jù)格式為 N-PDU。圖3以開發(fā)過程中的多幀傳輸為例，展示了各數(shù)據(jù)單元的格式和映射關(guān)系。當(dāng)工作條件發(fā)生改變時，如 ECU 上電和斷電，各模塊的狀態(tài)或模式會自動進(jìn)行轉(zhuǎn)換。當(dāng)通信需求改變時，需要主動切換模式，為此本文開發(fā)了—系列接口函數(shù)，主要用于切換通信波特率、CAN控制器狀態(tài)、PDU通道模式。UDS的一些診斷服務(wù)如 link control要求可以切換通信波特率，以滿足與不同診斷儀的通信。在 CAN 驅(qū)動層開發(fā)了 Can_SetBaudrate（）設(shè)置波特率，入口參數(shù)是目標(biāo)波特率的ID，波特率ID的選用參照 ISO14229-1。CAN控制器有4種狀態(tài)∶ UNINIT，此時 CAN控制器未初化;STOPPED，此時 CAN控制器初始化，但不參與總線; STARTED，此時CAN控制器可以正常工作;SLEEP，此時 CAN控制器休眠以降低能耗，但可以被事件喚醒。CAN控制器狀態(tài)在不同的通信條件下進(jìn)行切換，統(tǒng)一由 CAN 接口層管理，經(jīng)由驅(qū)動層實(shí)現(xiàn)。本文為此分別開發(fā)2個函數(shù)，接口層的 Canlf SetControllerMode（）和驅(qū)動層 Can_ SetControllerMode（）。軟件通過 Canif SetController- Mode（）發(fā)出狀態(tài)切換請求，然后調(diào)用Can SetControll- erMode（）操作 CAN 控制器的模式控制寄存器，CAN驅(qū)動層的控制器狀態(tài)可以立即切換，CAN 接口層的控制器狀態(tài)需等到驅(qū)動層返回E_OK后才切換。為了可以根據(jù)需求改變通信信道的收發(fā)模式，本文在CAN接口層開發(fā)了功能函數(shù) Canlf_SetPduMode （）用于實(shí)現(xiàn)L-PDU 信道4個狀態(tài)的切換∶ CANIF OFFLINE，此時不進(jìn)行通信; CANIF PASSIVE，此時只接收不發(fā)送數(shù)據(jù); CANIF_ACTIVE，此時只發(fā)送不接收數(shù)據(jù);CANIF_ON- LINE，此時進(jìn)行正常的數(shù)據(jù)收發(fā)。狀態(tài)機(jī)如圖4所示。
此外，在CAN傳輸層還通過CanTp_Shutdown（）實(shí)現(xiàn)CanTp_ On 到 CanTp_Off 的狀態(tài)切換，從而關(guān)閉多幀數(shù)據(jù)傳輸功能。
2.4 時間管理功能的開發(fā)
在 CAN接口層與 CAN傳輸層進(jìn)行多幀傳輸時，為了防止因總線負(fù)載過高或等待時間過長導(dǎo)致診斷通信失去聯(lián)系，本文遵照 ISO156765-2 中對網(wǎng)絡(luò)層定時的規(guī)定，開發(fā)了 CAN傳輸層函數(shù) CanTp_MainFunciton（）對通信的時間參數(shù)進(jìn)行控制，主要參數(shù)有 N As、N_Bs、NAr、N_Br、 N_Cr和 STM-min。
其中，STM-min決定連續(xù)幀的發(fā)送間隔，由接收方通過流控幀發(fā)給發(fā)送方，其他的時間參數(shù)都有各自的定時器，如果發(fā)生超時，定時器溢出，報告錯誤。假設(shè)與 ECU 進(jìn)行診斷通信的診斷儀的內(nèi)部協(xié)議棧也是基于 AUTOSAR 架構(gòu)進(jìn)行開發(fā)的。
2.5 診斷服務(wù)處理功能的開發(fā)
UDS診斷服務(wù)總共分為六大類∶ Diagnostic and com- munication management、Data transmission、Stored data transmission、InputOutput control、Remote acti- vation of routine、Upload and download。ISO14229—1對每個診斷服務(wù)作了詳細(xì)的規(guī)定，包括服務(wù)請求消息的服務(wù)標(biāo)識符、子功能和數(shù)據(jù)參數(shù)，服務(wù)響應(yīng)消息的服務(wù)標(biāo)識符和否定響應(yīng)碼。
DCM 模塊對一個診斷服務(wù)的處理，首先需要及時對服務(wù)請求消息進(jìn)行接收，其次需要對服務(wù)請求消息進(jìn)行驗(yàn)證，最后執(zhí)行有效診斷服務(wù)請求的操作。本文對應(yīng)以上要求，為 DCM模塊分別開發(fā)了3個子模塊∶ DSL、DSD、DSP。
DSL 直接與 PduR 進(jìn)行數(shù)據(jù)交換，完成服務(wù)請求消息的接收和服務(wù)響應(yīng)消息的發(fā)送。當(dāng)接收到 DiagnosticSession-Control（10 hex） 服務(wù)時，DSL 根據(jù)請求切換診斷會話模式，并返回診斷會話的定時參數(shù)，如發(fā)送服務(wù)請求消息的一方收到服務(wù)響應(yīng)消息的時間間隔 P2CAN Client，用于設(shè)定當(dāng)前會話模式下應(yīng)用層的超時機(jī)制。當(dāng)接收到 SecurityAc- cess （27 hex） 服務(wù)時，DSL返回種子，然后再收到對方發(fā)來的密鑰并驗(yàn)證，決定是否開放安全權(quán)限。診斷儀為了保持連接，會周期性生地發(fā)來TesterPresent 服務(wù)，DSL 接收后將復(fù)位 session timeout timer 以維持當(dāng)前會話模式，此后不再將該服務(wù)發(fā)給 DSD 做進(jìn)一步處理。
DSD 模塊首先負(fù)責(zé)驗(yàn)證服務(wù)請求消息的有效性。包括檢查服務(wù)標(biāo)識符是否在支持的服務(wù)列表里，檢查當(dāng)前會話模式、安全權(quán)限和ECU狀態(tài)是否支持該服務(wù)，檢查服務(wù)子功能和參數(shù)格式是否正確。如果發(fā)現(xiàn)消息無效，則返回對應(yīng)的否定響應(yīng)碼。如果請求消息通過有效性驗(yàn)證，DSD將通過診斷服務(wù)列表索引到 DSP 模塊對該診斷請求的執(zhí)行函數(shù)。
DSP 模塊負(fù)責(zé)執(zhí)行服務(wù)請求的操作，此時需要 DSP 模塊和診斷通信軟件之外的模塊進(jìn)行交互。當(dāng)服務(wù)請求消息請求的是讀取或清除故障信息，DSP 需要訪問 DEM模塊; 當(dāng)請求數(shù)據(jù)上傳下載或讀取數(shù)據(jù)流時，DSP需要訪問memory stack。當(dāng)請求輸入輸出控制時，DSP需要通過 DCM_Send/ ReceiveSignal （）接入RTE來獲得對 SW組件的訪問。
3. 診斷通信協(xié)議棧的測試
3.1 故障診斷測試平臺
本文借助于自主搭建的故障診斷測試平臺對開發(fā)的診斷通信協(xié)議棧進(jìn)行功能和協(xié)議的驗(yàn)證。診斷設(shè)備采用自主開發(fā)的PC式故障診斷系統(tǒng)，該系統(tǒng)運(yùn)行在個人電腦上，然后通過自主開發(fā)的 VCl（車輛通信接口）接入車載診斷網(wǎng)絡(luò)中，從而和掛載在同一網(wǎng)絡(luò)中的ECU進(jìn)行診斷通信，此時開發(fā)的診斷通信協(xié)議棧已經(jīng)燒入 ECU中。測試平臺如圖5所示。
3.2 ECU刷新測試
本文參考 ISO15765-3 提供的非易失性內(nèi)存再編程消息流程的例子，制訂丁了一套ECU 刷新過程測試方案，用于測試協(xié)議棧的基本通信和診斷服務(wù)處理功能。在診斷通信網(wǎng)絡(luò)中，診斷儀稱作客戶端，ECU稱作服務(wù)器。采用標(biāo)準(zhǔn)的 11 位 OBD CAN id，參考ISO15765-4，配置客戶端的物理請求 CAN ID為770，服務(wù)器的物理響應(yīng) CAN ID為 778，請求消息的 CAN 幀的無效數(shù)據(jù)填充 55hex，響應(yīng)消息的填充 AA hex（如圖6所示）。
采用 PC 故障診斷系統(tǒng)的數(shù)據(jù)監(jiān)聽功能進(jìn)行測試。在進(jìn)行診斷通信之前，PC故障診斷系統(tǒng)首先要對VCL進(jìn)行配置，包括設(shè)定通信波特率為500kb/s，通過復(fù)位完成配置。
整個 ECU 刷新測試流程如下; 診斷會話控制- 切換到編程會話模式（0x10 02）;安全訪問 -獲得種子（0x27 01）、發(fā)送密鑰（Ox27 02）;例程控制 -清除內(nèi)存 （Ox31 01FF 00）;請求下載 （0x34）;傳輸數(shù)據(jù)（0x36）;請求退出傳輸（Ox37）;例程控制一檢查編程依賴性 （Ox31 01 FF 01）;E-CU復(fù)位-硬件復(fù)位（Ox11 01）。考慮本文測試采用手動方式發(fā)送服務(wù)請求，難以做到周期性發(fā)送診斷儀在線服務(wù)，為此屏蔽了 ECU 的斷儀在線請青求超時錯誤功能。依次發(fā)送以上診斷服務(wù)，每發(fā)送一個診斷r請青求消息，立即收到ECUJ返向來的響應(yīng)消息，每條消息有 8個數(shù)據(jù)字節(jié)，首字節(jié)為有效數(shù)據(jù)個數(shù)，然后分別為響應(yīng)服務(wù)標(biāo)只符、子功能和數(shù)據(jù)參數(shù)。
通過以上測試表明，開發(fā)的診斷通信協(xié)議棧具有基本的通信功能并且可以正確響應(yīng)診斷請求，整個過程符合協(xié)議要求。
