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

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

1. 診斷通信協議?？傮w架構

1.1 診斷通信協議中的OSI模型

為了實現網絡通信系統(tǒng)開發(fā)的標準化，國際標準組織（ISO）制定了 OSI模型。這個模型把網絡通信分為7個工作層，分別是物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層。

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

根據應用范圍的不同，診斷通信分為2種∶ 一種是與排放無關的診斷，叫增強型診斷，即UDS診斷;一種是與排放相關的診斷，叫OBD診斷。

傳統(tǒng)的診斷通信協議棧的開發(fā)，基本都是按照診斷協議中OST模型來建立整體架構的。但診斷通信的OST模型并沒有在具體功能的開發(fā)上提供參考，這就導致不同的汽車制造商按照各自的軟件開發(fā)標準開發(fā)出各自專用的診斷通信軟件，其中有的診斷通信軟件在診斷應用層直接操作硬件，這些都造成汽車診斷通信軟件缺乏通用性和可移植性。

1.2 AUTOSAR 標準的診斷通信協議棧架構

AUTOSAR 標準基于傳統(tǒng)的OSI模型，為診斷通信軟件的開發(fā)提供了一套完整的解決方案。

協議棧的硬件平臺根據選用的芯片、連接的方式及具體的布局而異，但根本原理都是一致的，CAN控制器是硬件的核心，通過不同的CAN收發(fā)器接到不同的CAN總線上。





基礎軟件的微控制器抽象層主要解決硬件的底層驅動問題，對應在診斷通信協議棧中是CAN驅動層。當將診斷通信協議棧移植到其他硬件平臺上，只需對 CAN 驅動做相應的更改，上層軟件則可以完全復用。

ECU抽象層，也叫硬件抽象層，主要解決上層軟件和硬件驅動之間的接口問題，對應在診斷通信協議棧中是CAN接口層。CAN接口層抽象了CAN控制器的位置和ECU的硬件布局，提供了一種平等訪問總線通道的機制而無需考慮這些控制器的物理位置。

服務層用于給應用程序提供可用的服務，在診斷通信協議棧里通過3個層次實現∶CAN傳輸層、Pdu路由層和 DCM 層。CAN 傳輸層主要解決多幀傳輸的問題，完成數據的打包和重組。Pdu 路由層是考慮到車載網絡中有多種通信方式共存，實現不同通信數據的中轉，可以對上層屏蔽通信方式的細節(jié)。

DCM是服務層，也是整個診斷通信協議棧的核心。DCM 處理診斷儀發(fā)送來的服務請求消息，然后執(zhí)行相應的操作，最后返回響應消息給診斷儀，整個過程涉及診斷會話的管理、診斷服務的調度及診斷服務的執(zhí)行。

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

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

本文開發(fā)的診斷通信協議棧，選擇實現UDS診斷服務， OBD服務會在以后進行擴展。整個協議棧的開發(fā)采用由下往上的方式，DCM以下的模塊作為基本CAN通信軟件一起開發(fā)，DCM作為診斷應用層單獨開發(fā)。首先制定代碼文件結構，然后分別進行基本CAN通信軟件的數據傳輸、通信模式控制和時間管理功能的開發(fā)，最后進行 DCM層診斷服務處理功能的開發(fā)。

2.1 診斷通信協議棧的文件結構

AUTOSAR 的模塊化思想很大程度上體現在代碼文件結構的規(guī)范上。在AUTOSAR 標準里，診斷通信是作為一個完整的汽車電控系統(tǒng)的子系統(tǒng)進行開發(fā)的。診斷通信協議棧中的子模塊不僅會調用各自的頭文件，也會調用 ECU 級別的頭文件，所以在保證代碼的系統(tǒng)性的同時，也導致代碼結構較為龐大復雜。本文旨在單獨實現診斷通信的功能，因此對代碼結構做了一定的簡化，整個診斷通信協議棧的代碼文件結構如圖2所示。



其中，Can_GeneralTypesh定義了通用 CAN協議棧底層模塊的數據類型。ComStack_Typesh定義了與在線通信模塊 Com 相關的數據類型，主要是數據協議單元。Std_Typesh定義了 Autosar標準專有的數據類型，如版本信息和一些狀態(tài)模式的宏定義。每個子模塊都有若干c 文件，主要定義僅限于本模塊使用的數據類型、常量和函數。每個用子模塊名稱命名的頭文件xxxh定義本模塊中被外部引用的數據類型、變量和服務。xxx_Cfgh 定義了模塊在預編譯階段用于配置的數據。xxx_Cbkh 和用 2 個模塊名稱命名的xxx1_xxx2h 聲明了某模塊被低層模塊調用的回調函數。xxx_Typesh 定義模塊專用數據類型。

2.2 數據傳輸功能的開發(fā)

數據傳輸功能是基本通信軟件的核心功能。本文為所有模塊開發(fā)了數據傳輸接口，用于數據的收發(fā)、處理和格式轉換。

2.2.1 數據傳輸過程

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

2.2.2 數據傳輸格式

在 AUTOSAR 標準中，CAN通信協議棧的硬件可以包含多個 CAN控制器，但統(tǒng)一由同一個CAN驅動管理。CAN驅動是協議棧里面唯一可以直接訪問和操作硬件的模塊，它通過分配給每個CAN 控制器的 ID 獲得對它們的訪問。本文只采用了一個 CAN控制器，用于實現ECU 和診斷系統(tǒng)在單一網絡中的通信。

CAN驅動和上層模塊的信息交互都要經過 CAN 接口層來傳遞。CAN 接口 層和驅動層之間的數據傳輸遵照 ISO11898-1 協議，對應于 OSI模型中的數據鏈路層，主要解決數據幀格式，實現標準幀和擴展幀的收發(fā)，數據單元格式為 L-PDU。

單幀傳輸時，CAN接口層直接和 PduR 層進行信息交互。AUTOSAR 為 PduR 與其他模塊之間的數據交換定義了一個交互層，PduR 通過查詢 I-PDU 標識符列表對數據進行路由選擇，數據格式為I-PDU。

多幀傳輸時，CAN接口層和 PduR 層之間需要 CAN傳輸層來進行數據的打包和拆包。CAN傳輸層和 PduR 層之間仍遵照交互層。CAN 接口層和 CAN傳輸層之間的數據傳輸遵照 ISO15765-2，對應于OSI模型中的網絡層，主要完成尋址和多幀傳輸的控制，數據格式為 N-PDU。

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



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

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

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

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

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

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



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

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

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

其中，STM-min決定連續(xù)幀的發(fā)送間隔，由接收方通過流控幀發(fā)給發(fā)送方，其他的時間參數都有各自的定時器，如果發(fā)生超時，定時器溢出，報告錯誤。假設與 ECU 進行診斷通信的診斷儀的內部協議棧也是基于 AUTOSAR 架構進行開發(fā)的。

2.5 診斷服務處理功能的開發(fā)

UDS診斷服務總共分為六大類∶ Diagnostic and com- munication management、Data transmission、Stored data transmission、InputOutput control、Remote acti- vation of routine、Upload and download。ISO14229—1對每個診斷服務作了詳細的規(guī)定，包括服務請求消息的服務標識符、子功能和數據參數，服務響應消息的服務標識符和否定響應碼。

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

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

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

DSP 模塊負責執(zhí)行服務請求的操作，此時需要 DSP 模塊和診斷通信軟件之外的模塊進行交互。當服務請求消息請求的是讀取或清除故障信息，DSP 需要訪問 DEM模塊; 當請求數據上傳下載或讀取數據流時，DSP需要訪問memory stack。當請求輸入輸出控制時，DSP需要通過 DCM_Send/ ReceiveSignal （）接入RTE來獲得對 SW組件的訪問。

3. 診斷通信協議棧的測試

3.1 故障診斷測試平臺

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



3.2 ECU刷新測試

本文參考 ISO15765-3 提供的非易失性內存再編程消息流程的例子，制訂丁了一套ECU 刷新過程測試方案，用于測試協議棧的基本通信和診斷服務處理功能。在診斷通信網絡中，診斷儀稱作客戶端，ECU稱作服務器。采用標準的 11 位 OBD CAN id，參考ISO15765-4，配置客戶端的物理請求 CAN ID為770，服務器的物理響應 CAN ID為 778，請求消息的 CAN 幀的無效數據填充 55hex，響應消息的填充 AA hex（如圖6所示）。


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

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

通過以上測試表明，開發(fā)的診斷通信協議棧具有基本的通信功能并且可以正確響應診斷請求，整個過程符合協議要求。