隨著現(xiàn)代汽氣車上集成的ECU越來(lái)越多，整車網(wǎng)絡(luò)戒來(lái)越復(fù)雜。診斷通信作為車載網(wǎng)絡(luò)中的一個(gè)重要功能，開發(fā)周期和難度也不斷增加。為了提高軟件的復(fù)用率和可移植性，縮短開發(fā)周期，全球汽車制造商、零部件供應(yīng)商、半導(dǎo)體供應(yīng)商及工具供應(yīng)商共同制定了 AUTOSAR標(biāo)準(zhǔn)。AUTOSAR標(biāo)準(zhǔn)的核心是剝離 ECU 軟件開發(fā)對(duì)硬件的依賴，為此它將軟件分為應(yīng)用層軟件組件（SW Component）、基礎(chǔ)軟件包（Basic Software）和運(yùn)行時(shí)環(huán)境（RTE），AUTOSAR標(biāo)準(zhǔn)如圖1所示。

本文在深入研究 AUTOSAR標(biāo)準(zhǔn)的設(shè)計(jì)思想和軟件體系后，參照AUTOSAR 標(biāo)準(zhǔn)街推薦的診斷通信架構(gòu)，開發(fā)了一個(gè)基于CAN 總線的、具有通用性和可移植性的診斷通信協(xié)議棧。

1. 診斷通信協(xié)議?？傮w架構(gòu)

1.1 診斷通信協(xié)議中的OSI模型

為了實(shí)現(xiàn)網(wǎng)絡(luò)通信系統(tǒng)開發(fā)的標(biāo)準(zhǔn)化，國(guó)際標(biāo)準(zhǔn)組織（ISO）制定了 OSI模型。這個(gè)模型把網(wǎng)絡(luò)通信分為7個(gè)工作層，分別是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話層、表示層和應(yīng)用層。

ISO在后來(lái)制定的診斷通信協(xié)議中，如 ISO15765、ISO14229、ISO15031，也按照 OS模型對(duì)診斷通信進(jìn)行了分層，并用具體的診斷通信協(xié)議對(duì)每層做了詳細(xì)的規(guī)定。隨著診斷通信協(xié)議的不斷完善，已經(jīng)形成一套完整的診斷通信架構(gòu)（見(jiàn)表 1）。

根據(jù)應(yīng)用范圍的不同，診斷通信分為2種∶ 一種是與排放無(wú)關(guān)的診斷，叫增強(qiáng)型診斷，即UDS診斷;一種是與排放相關(guān)的診斷，叫OBD診斷。

傳統(tǒng)的診斷通信協(xié)議棧的開發(fā)，基本都是按照診斷協(xié)議中OST模型來(lái)建立整體架構(gòu)的。但診斷通信的OST模型并沒(méi)有在具體功能的開發(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é)議棧的硬件平臺(tái)根據(jù)選用的芯片、連接的方式及具體的布局而異，但根本原理都是一致的，CAN控制器是硬件的核心，通過(guò)不同的CAN收發(fā)器接到不同的CAN總線上。





基礎(chǔ)軟件的微控制器抽象層主要解決硬件的底層驅(qū)動(dòng)問(wèn)題，對(duì)應(yīng)在診斷通信協(xié)議棧中是CAN驅(qū)動(dòng)層。當(dāng)將診斷通信協(xié)議棧移植到其他硬件平臺(tái)上，只需對(duì) CAN 驅(qū)動(dòng)做相應(yīng)的更改，上層軟件則可以完全復(fù)用。

ECU抽象層，也叫硬件抽象層，主要解決上層軟件和硬件驅(qū)動(dòng)之間的接口問(wèn)題，對(duì)應(yīng)在診斷通信協(xié)議棧中是CAN接口層。CAN接口層抽象了CAN控制器的位置和ECU的硬件布局，提供了一種平等訪問(wèn)總線通道的機(jī)制而無(wú)需考慮這些控制器的物理位置。

服務(wù)層用于給應(yīng)用程序提供可用的服務(wù)，在診斷通信協(xié)議棧里通過(guò)3個(gè)層次實(shí)現(xiàn)∶CAN傳輸層、Pdu路由層和 DCM 層。CAN 傳輸層主要解決多幀傳輸?shù)膯?wèn)題，完成數(shù)據(jù)的打包和重組。Pdu 路由層是考慮到車載網(wǎng)絡(luò)中有多種通信方式共存，實(shí)現(xiàn)不同通信數(shù)據(jù)的中轉(zhuǎn)，可以對(duì)上層屏蔽通信方式的細(xì)節(jié)。

DCM是服務(wù)層，也是整個(gè)診斷通信協(xié)議棧的核心。DCM 處理診斷儀發(fā)送來(lái)的服務(wù)請(qǐng)求消息，然后執(zhí)行相應(yīng)的操作，最后返回響應(yīng)消息給診斷儀，整個(gè)過(guò)程涉及診斷會(huì)話的管理、診斷服務(wù)的調(diào)度及診斷服務(wù)的執(zhí)行。

2. 診斷通信協(xié)議棧的開發(fā)

本文采用 freescale 高性能芯片 MC9S12XEQ512 的開發(fā)板作為診斷通信協(xié)議棧開發(fā)和測(cè)試的硬件平臺(tái)，該芯片內(nèi)部集成5個(gè)支持 CAN 20B 標(biāo)準(zhǔn)的 CAN控制器，與之配套的 CAN 收發(fā)器采用 82C250 芯片。

本文開發(fā)的診斷通信協(xié)議棧，選擇實(shí)現(xiàn)UDS診斷服務(wù)， OBD服務(wù)會(huì)在以后進(jìn)行擴(kuò)展。整個(gè)協(xié)議棧的開發(fā)采用由下往上的方式，DCM以下的模塊作為基本CAN通信軟件一起開發(fā)，DCM作為診斷應(yīng)用層單獨(dú)開發(fā)。首先制定代碼文件結(jié)構(gòu)，然后分別進(jìn)行基本CAN通信軟件的數(shù)據(jù)傳輸、通信模式控制和時(shí)間管理功能的開發(fā)，最后進(jìn)行 DCM層診斷服務(wù)處理功能的開發(fā)。

2.1 診斷通信協(xié)議棧的文件結(jié)構(gòu)

AUTOSAR 的模塊化思想很大程度上體現(xiàn)在代碼文件結(jié)構(gòu)的規(guī)范上。在AUTOSAR 標(biāo)準(zhǔn)里，診斷通信是作為一個(gè)完整的汽車電控系統(tǒng)的子系統(tǒng)進(jìn)行開發(fā)的。診斷通信協(xié)議棧中的子模塊不僅會(huì)調(diào)用各自的頭文件，也會(huì)調(diào)用 ECU 級(jí)別的頭文件，所以在保證代碼的系統(tǒng)性的同時(shí)，也導(dǎo)致代碼結(jié)構(gòu)較為龐大復(fù)雜。本文旨在單獨(dú)實(shí)現(xiàn)診斷通信的功能，因此對(duì)代碼結(jié)構(gòu)做了一定的簡(jiǎn)化，整個(gè)診斷通信協(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)模式的宏定義。每個(gè)子模塊都有若干c 文件，主要定義僅限于本模塊使用的數(shù)據(jù)類型、常量和函數(shù)。每個(gè)用子模塊名稱命名的頭文件xxxh定義本模塊中被外部引用的數(shù)據(jù)類型、變量和服務(wù)。xxx_Cfgh 定義了模塊在預(yù)編譯階段用于配置的數(shù)據(jù)。xxx_Cbkh 和用 2 個(gè)模塊名稱命名的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)換。

2.2.1 數(shù)據(jù)傳輸過(guò)程

整個(gè)診斷通信協(xié)議棧的數(shù)據(jù)傳輸過(guò)程如下; 當(dāng)總線上有數(shù)據(jù)發(fā)送過(guò)來(lái)時(shí)，首先經(jīng)過(guò) CAN 控制器硬件過(guò)濾，即進(jìn)行標(biāo)識(shí)只符的匹配過(guò)濾。如果通過(guò)過(guò)濾，CAN驅(qū)動(dòng)將通過(guò)中斷或輪詢間的方式觸發(fā) read （） 操作取出 CAN 控制器硬件接收緩沖區(qū)的數(shù)據(jù)，然后調(diào)用 Canlf RxIndication （）將數(shù)據(jù)傳遞至 CAN接口層，CAN 接口通過(guò)查詢標(biāo)識(shí)符列表對(duì)數(shù)據(jù)進(jìn)行軟件過(guò)濾后，再調(diào)用上層的 xxx _Rxlndication （）進(jìn)一步處理和傳遞數(shù)據(jù)，最后通過(guò) Dcm __RxIndication （）將數(shù)據(jù)傳遞到 DCM層。當(dāng)發(fā)送數(shù)據(jù)時(shí)，高層模塊通過(guò)依次調(diào)用低層模塊的 xxx _Transmit（）將數(shù)據(jù)往底層傳遞，最后通過(guò) Can_Write（）將數(shù)據(jù)寫入 CAN控制器的發(fā)送緩沖區(qū)，數(shù)據(jù)再根據(jù)傳送緩沖優(yōu)先級(jí)依次發(fā)送到總線上，低層模塊成功發(fā)送數(shù)據(jù)后通過(guò)返回 xxx Tx/confirm/iation（）告知上層模塊。

2.2.2 數(shù)據(jù)傳輸格式

在 AUTOSAR 標(biāo)準(zhǔn)中，CAN通信協(xié)議棧的硬件可以包含多個(gè) CAN控制器，但統(tǒng)一由同一個(gè)CAN驅(qū)動(dòng)管理。CAN驅(qū)動(dòng)是協(xié)議棧里面唯一可以直接訪問(wèn)和操作硬件的模塊，它通過(guò)分配給每個(gè)CAN 控制器的 ID 獲得對(duì)它們的訪問(wèn)。本文只采用了一個(gè) CAN控制器，用于實(shí)現(xiàn)ECU 和診斷系統(tǒng)在單一網(wǎng)絡(luò)中的通信。

CAN驅(qū)動(dòng)和上層模塊的信息交互都要經(jīng)過(guò) CAN 接口層來(lái)傳遞。CAN 接口 層和驅(qū)動(dòng)層之間的數(shù)據(jù)傳輸遵照 ISO11898-1 協(xié)議，對(duì)應(yīng)于 OSI模型中的數(shù)據(jù)鏈路層，主要解決數(shù)據(jù)幀格式，實(shí)現(xiàn)標(biāo)準(zhǔn)幀和擴(kuò)展幀的收發(fā)，數(shù)據(jù)單元格式為 L-PDU。

單幀傳輸時(shí)，CAN接口層直接和 PduR 層進(jìn)行信息交互。AUTOSAR 為 PduR 與其他模塊之間的數(shù)據(jù)交換定義了一個(gè)交互層，PduR 通過(guò)查詢 I-PDU 標(biāo)識(shí)符列表對(duì)數(shù)據(jù)進(jìn)行路由選擇，數(shù)據(jù)格式為I-PDU。

多幀傳輸時(shí)，CAN接口層和 PduR 層之間需要 CAN傳輸層來(lái)進(jìn)行數(shù)據(jù)的打包和拆包。CAN傳輸層和 PduR 層之間仍遵照交互層。CAN 接口層和 CAN傳輸層之間的數(shù)據(jù)傳輸遵照 ISO15765-2，對(duì)應(yīng)于OSI模型中的網(wǎng)絡(luò)層，主要完成尋址和多幀傳輸?shù)目刂疲瑪?shù)據(jù)格式為 N-PDU。

圖3以開發(fā)過(guò)程中的多幀傳輸為例，展示了各數(shù)據(jù)單元的格式和映射關(guān)系。



2.3 通信模式控制功能的開發(fā)

當(dāng)工作條件發(fā)生改變時(shí)，如 ECU 上電和斷電，各模塊的狀態(tài)或模式會(huì)自動(dòng)進(jìn)行轉(zhuǎn)換。當(dāng)通信需求改變時(shí)，需要主動(dòng)切換模式，為此本文開發(fā)了—系列接口函數(shù)，主要用于切換通信波特率、CAN控制器狀態(tài)、PDU通道模式。

UDS的一些診斷服務(wù)如 link control要求可以切換通信波特率，以滿足與不同診斷儀的通信。在 CAN 驅(qū)動(dòng)層開發(fā)了 Can_SetBaudrate（）設(shè)置波特率，入口參數(shù)是目標(biāo)波特率的ID，波特率ID的選用參照 ISO14229-1。

CAN控制器有4種狀態(tài)∶ UNINIT，此時(shí) CAN控制器未初化;STOPPED，此時(shí) CAN控制器初始化，但不參與總線; STARTED，此時(shí)CAN控制器可以正常工作;SLEEP，此時(shí) CAN控制器休眠以降低能耗，但可以被事件喚醒。CAN控制器狀態(tài)在不同的通信條件下進(jìn)行切換，統(tǒng)一由 CAN 接口層管理，經(jīng)由驅(qū)動(dòng)層實(shí)現(xiàn)。

本文為此分別開發(fā)2個(gè)函數(shù)，接口層的 Canlf SetControllerMode（）和驅(qū)動(dòng)層 Can_ SetControllerMode（）。軟件通過(guò) Canif SetController- Mode（）發(fā)出狀態(tài)切換請(qǐng)求，然后調(diào)用Can SetControll- erMode（）操作 CAN 控制器的模式控制寄存器，CAN驅(qū)動(dòng)層的控制器狀態(tài)可以立即切換，CAN 接口層的控制器狀態(tài)需等到驅(qū)動(dòng)層返回E_OK后才切換。

為了可以根據(jù)需求改變通信信道的收發(fā)模式，本文在CAN接口層開發(fā)了功能函數(shù) Canlf_SetPduMode （）用于實(shí)現(xiàn)L-PDU 信道4個(gè)狀態(tài)的切換∶ CANIF OFFLINE，此時(shí)不進(jìn)行通信; CANIF PASSIVE，此時(shí)只接收不發(fā)送數(shù)據(jù); CANIF_ACTIVE，此時(shí)只發(fā)送不接收數(shù)據(jù);CANIF_ON- LINE，此時(shí)進(jìn)行正常的數(shù)據(jù)收發(fā)。狀態(tài)機(jī)如圖4所示。



此外，在CAN傳輸層還通過(guò)CanTp_Shutdown（）實(shí)現(xiàn)CanTp_ On 到 CanTp_Off 的狀態(tài)切換，從而關(guān)閉多幀數(shù)據(jù)傳輸功能。

2.4 時(shí)間管理功能的開發(fā)

在 CAN接口層與 CAN傳輸層進(jìn)行多幀傳輸時(shí)，為了防止因總線負(fù)載過(guò)高或等待時(shí)間過(guò)長(zhǎng)導(dǎo)致診斷通信失去聯(lián)系，本文遵照 ISO156765-2 中對(duì)網(wǎng)絡(luò)層定時(shí)的規(guī)定，開發(fā)了 CAN傳輸層函數(shù) CanTp_MainFunciton（）對(duì)通信的時(shí)間參數(shù)進(jìn)行控制，主要參數(shù)有 N As、N_Bs、NAr、N_Br、 N_Cr和 STM-min。

其中，STM-min決定連續(xù)幀的發(fā)送間隔，由接收方通過(guò)流控幀發(fā)給發(fā)送方，其他的時(shí)間參數(shù)都有各自的定時(shí)器，如果發(fā)生超時(shí)，定時(shí)器溢出，報(bào)告錯(cuò)誤。假設(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對(duì)每個(gè)診斷服務(wù)作了詳細(xì)的規(guī)定，包括服務(wù)請(qǐng)求消息的服務(wù)標(biāo)識(shí)符、子功能和數(shù)據(jù)參數(shù)，服務(wù)響應(yīng)消息的服務(wù)標(biāo)識(shí)符和否定響應(yīng)碼。

DCM 模塊對(duì)一個(gè)診斷服務(wù)的處理，首先需要及時(shí)對(duì)服務(wù)請(qǐng)求消息進(jìn)行接收，其次需要對(duì)服務(wù)請(qǐng)求消息進(jìn)行驗(yàn)證，最后執(zhí)行有效診斷服務(wù)請(qǐng)求的操作。本文對(duì)應(yīng)以上要求，為 DCM模塊分別開發(fā)了3個(gè)子模塊∶ DSL、DSD、DSP。

DSL 直接與 PduR 進(jìn)行數(shù)據(jù)交換，完成服務(wù)請(qǐng)求消息的接收和服務(wù)響應(yīng)消息的發(fā)送。當(dāng)接收到 DiagnosticSession-Control（10 hex） 服務(wù)時(shí)，DSL 根據(jù)請(qǐng)求切換診斷會(huì)話模式，并返回診斷會(huì)話的定時(shí)參數(shù)，如發(fā)送服務(wù)請(qǐng)求消息的一方收到服務(wù)響應(yīng)消息的時(shí)間間隔 P2CAN Client，用于設(shè)定當(dāng)前會(huì)話模式下應(yīng)用層的超時(shí)機(jī)制。當(dāng)接收到 SecurityAc- cess （27 hex） 服務(wù)時(shí)，DSL返回種子，然后再收到對(duì)方發(fā)來(lái)的密鑰并驗(yàn)證，決定是否開放安全權(quán)限。診斷儀為了保持連接，會(huì)周期性生地發(fā)來(lái)TesterPresent 服務(wù)，DSL 接收后將復(fù)位 session timeout timer 以維持當(dāng)前會(huì)話模式，此后不再將該服務(wù)發(fā)給 DSD 做進(jìn)一步處理。

DSD 模塊首先負(fù)責(zé)驗(yàn)證服務(wù)請(qǐng)求消息的有效性。包括檢查服務(wù)標(biāo)識(shí)符是否在支持的服務(wù)列表里，檢查當(dāng)前會(huì)話模式、安全權(quán)限和ECU狀態(tài)是否支持該服務(wù)，檢查服務(wù)子功能和參數(shù)格式是否正確。如果發(fā)現(xiàn)消息無(wú)效，則返回對(duì)應(yīng)的否定響應(yīng)碼。如果請(qǐng)求消息通過(guò)有效性驗(yàn)證，DSD將通過(guò)診斷服務(wù)列表索引到 DSP 模塊對(duì)該診斷請(qǐng)求的執(zhí)行函數(shù)。

DSP 模塊負(fù)責(zé)執(zhí)行服務(wù)請(qǐng)求的操作，此時(shí)需要 DSP 模塊和診斷通信軟件之外的模塊進(jìn)行交互。當(dāng)服務(wù)請(qǐng)求消息請(qǐng)求的是讀取或清除故障信息，DSP 需要訪問(wèn) DEM模塊; 當(dāng)請(qǐng)求數(shù)據(jù)上傳下載或讀取數(shù)據(jù)流時(shí)，DSP需要訪問(wèn)memory stack。當(dāng)請(qǐng)求輸入輸出控制時(shí)，DSP需要通過(guò) DCM_Send/ ReceiveSignal （）接入RTE來(lái)獲得對(duì) SW組件的訪問(wèn)。

3. 診斷通信協(xié)議棧的測(cè)試

3.1 故障診斷測(cè)試平臺(tái)

本文借助于自主搭建的故障診斷測(cè)試平臺(tái)對(duì)開發(fā)的診斷通信協(xié)議棧進(jìn)行功能和協(xié)議的驗(yàn)證。診斷設(shè)備采用自主開發(fā)的PC式故障診斷系統(tǒng)，該系統(tǒng)運(yùn)行在個(gè)人電腦上，然后通過(guò)自主開發(fā)的 VCl（車輛通信接口）接入車載診斷網(wǎng)絡(luò)中，從而和掛載在同一網(wǎng)絡(luò)中的ECU進(jìn)行診斷通信，此時(shí)開發(fā)的診斷通信協(xié)議棧已經(jīng)燒入 ECU中。測(cè)試平臺(tái)如圖5所示。



3.2 ECU刷新測(cè)試

本文參考 ISO15765-3 提供的非易失性內(nèi)存再編程消息流程的例子，制訂丁了一套ECU 刷新過(guò)程測(cè)試方案，用于測(cè)試協(xié)議棧的基本通信和診斷服務(wù)處理功能。在診斷通信網(wǎng)絡(luò)中，診斷儀稱作客戶端，ECU稱作服務(wù)器。采用標(biāo)準(zhǔn)的 11 位 OBD CAN id，參考ISO15765-4，配置客戶端的物理請(qǐng)求 CAN ID為770，服務(wù)器的物理響應(yīng) CAN ID為 778，請(qǐng)求消息的 CAN 幀的無(wú)效數(shù)據(jù)填充 55hex，響應(yīng)消息的填充 AA hex（如圖6所示）。


采用 PC 故障診斷系統(tǒng)的數(shù)據(jù)監(jiān)聽功能進(jìn)行測(cè)試。在進(jìn)行診斷通信之前，PC故障診斷系統(tǒng)首先要對(duì)VCL進(jìn)行配置，包括設(shè)定通信波特率為500kb/s，通過(guò)復(fù)位完成配置。

整個(gè) ECU 刷新測(cè)試流程如下; 診斷會(huì)話控制- 切換到編程會(huì)話模式（0x10 02）;安全訪問(wèn) -獲得種子（0x27 01）、發(fā)送密鑰（Ox27 02）;例程控制 -清除內(nèi)存 （Ox31 01FF 00）;請(qǐng)求下載 （0x34）;傳輸數(shù)據(jù)（0x36）;請(qǐng)求退出傳輸（Ox37）;例程控制一檢查編程依賴性 （Ox31 01 FF 01）;E-CU復(fù)位-硬件復(fù)位（Ox11 01）?？紤]本文測(cè)試采用手動(dòng)方式發(fā)送服務(wù)請(qǐng)求，難以做到周期性發(fā)送診斷儀在線服務(wù)，為此屏蔽了 ECU 的斷儀在線請(qǐng)青求超時(shí)錯(cuò)誤功能。依次發(fā)送以上診斷服務(wù)，每發(fā)送一個(gè)診斷r請(qǐng)青求消息，立即收到ECUJ返向來(lái)的響應(yīng)消息，每條消息有 8個(gè)數(shù)據(jù)字節(jié)，首字節(jié)為有效數(shù)據(jù)個(gè)數(shù)，然后分別為響應(yīng)服務(wù)標(biāo)只符、子功能和數(shù)據(jù)參數(shù)。

通過(guò)以上測(cè)試表明，開發(fā)的診斷通信協(xié)議棧具有基本的通信功能并且可以正確響應(yīng)診斷請(qǐng)求，整個(gè)過(guò)程符合協(xié)議要求。