喬美昀 韋天文

【摘 要】在研究了AUTOSAR標準的設計思想和診斷通信OSI模型后，開發(fā)了基于AUTOSAR架構的汽車診斷通信協(xié)議棧。整個協(xié)議棧的開發(fā)采用由下往上的分層模塊化結構，以實現(xiàn)具體的數(shù)據(jù)傳輸、通信模式控制、時間管理和診斷服務處理功能為核心，這種開發(fā)方式具有開發(fā)周期短、軟件復用度高、可移植性好的優(yōu)點。借助自主搭建的故障診斷測試平臺對協(xié)議棧進行測試，通過ECU刷新的例子，分析了總線上的刷新報文及通信機制，結果表明協(xié)議?？梢赃M行診斷通信并且通信過程符合診斷協(xié)議。

【關鍵詞】AUTOSAR；診斷通信協(xié)議棧；模塊化；診斷協(xié)議

【中圖分類號】U472.9 【文獻標識碼】A 【文章編號】1674-0688（2018）07-0036-05

0 引言

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

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

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

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

為了實現(xiàn)網(wǎng)絡通信系統(tǒng)開發(fā)的標準化，國際標準組織（ISO）制定了OSI模型。這個模型把網(wǎng)絡通信分為7個工作層，分別是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層、會話層、表示層和應用層。ISO在后來制定的診斷通信協(xié)議中，如ISO15765、ISO14229、ISO15031，也按照OSI模型對診斷通信進行了分層，并用具體的診斷通信協(xié)議對每層做了詳細的規(guī)定。隨著診斷通信協(xié)議的不斷完善，已經(jīng)形成一套完整的診斷通信架構（見表1）。根據(jù)應用范圍的不同，診斷通信分為2種：一種是與排放無關的診斷，叫增強型診斷，即UDS診斷；一種是與排放相關的診斷，叫OBD診斷。

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

1.2 AUTOSAR標準的診斷通信協(xié)議棧架構

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

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

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

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

服務層用于給應用程序提供可用的服務，在診斷通信協(xié)議棧里通過3個層次實現(xiàn)：CAN傳輸層、Pdu路由層和DCM層。CAN傳輸層主要解決多幀傳輸?shù)膯栴}，完成數(shù)據(jù)的打包和重組。Pdu路由層是考慮到車載網(wǎng)絡中有多種通信方式共存，實現(xiàn)不同通信數(shù)據(jù)的中轉，可以對上層屏蔽通信方式的細節(jié)。DCM是服務層，也是整個診斷通信協(xié)議棧的核心。DCM處理診斷儀發(fā)送來的服務請求消息，然后執(zhí)行相應的操作，最后返回響應消息給診斷儀，整個過程涉及診斷會話的管理、診斷服務的調度及診斷服務的執(zhí)行。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CAN控制器有4種狀態(tài)：UNINIT，此時CAN控制器未初始化；STOPPED，此時CAN控制器初始化，但不參與總線；STARTED，此時CAN控制器可以正常工作；SLEEP，此時CAN控制器休眠以降低能耗，但可以被事件喚醒。CAN控制器狀態(tài)在不同的通信條件下進行切換，統(tǒng)一由CAN接口層管理，經(jīng)由驅動層實現(xiàn)。本文為此分別開發(fā)了2個函數(shù)，接口層的CanIf_SetControllerMode（）和驅動層Can_

SetControllerMode（）。軟件通過CanIf_SetController-

Mode（ ）發(fā)出狀態(tài)切換請求，然后調用Can_SetControll-

erMode（ ）操作CAN控制器的模式控制寄存器，CAN驅動層的控制器狀態(tài)可以立即切換，CAN接口層的控制器狀態(tài)需等到驅動層返回E_OK后才切換。

為了可以根據(jù)需求改變通信信道的收發(fā)模式，本文在CAN接口層開發(fā)了功能函數(shù)CanIf_SetPduMode（）用于實現(xiàn)L-PDU信道4個狀態(tài)的切換：CANIF_OFFLINE，此時不進行通信；CANIF_PASSIVE，此時只接收不發(fā)送數(shù)據(jù)；CANIF_ACTIVE，此時只發(fā)送不接收數(shù)據(jù)；CANIF_ONLINE，此時進行正常的數(shù)據(jù)收發(fā)。狀態(tài)機如圖4所示。此外，在CAN傳輸層還通過CanTp_Shutdown（ ）實現(xiàn)CanTp_

On到CanTp_Off的狀態(tài)切換，從而關閉多幀數(shù)據(jù)傳輸功能。

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

在CAN接口層與CAN傳輸層進行多幀傳輸時，為了防止因總線負載過高或等待時間過長導致診斷通信失去聯(lián)系，本文遵照ISO156765-2中對網(wǎng)絡層定時的規(guī)定，開發(fā)了CAN傳輸層函數(shù)CanTp_MainFunciton（）對通信的時間參數(shù)進行控制，主要參數(shù)有N_As、N_Bs、N_Ar、N_Br、N_Cr和STM-min。其中，STM-min決定連續(xù)幀的發(fā)送間隔，由接收方通過流控幀發(fā)給發(fā)送方，其他的時間參數(shù)都有各自的定時器，如果發(fā)生超時，定時器溢出，報告錯誤。假設與ECU進行診斷通信的診斷儀的內部協(xié)議棧也是基于AUTOSAR架構進行開發(fā)的。

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

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

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

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

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

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

ReceiveSignal（）接入RTE來獲得對SW組件的訪問。

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

3.1 故障診斷測試平臺

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

3.2 ECU刷新測試

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

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

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

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

4 結語

本文在研究AUTOSAR標準的設計思想和軟件體系后，開發(fā)了一個基于AUTOSAR架構的診斷通信協(xié)議棧，該協(xié)議棧的垂直結構為從下往上的分層模塊，水平結構為數(shù)據(jù)傳輸、通信模式控制、時間管理和診斷服務處理四大功能。該分層式協(xié)議棧的各模塊可以單獨進行開發(fā)和調試，提高了協(xié)議棧的開發(fā)效率和復用度。通過對硬件抽象層的修改，可以將該診斷通信協(xié)議?？焖倏煽康貞玫狡渌布脚_，具有很高的可移植性和通用性。

參 考 文 獻

[1]周濤，ISO 15765協(xié)議的研究實現(xiàn)[D].合肥：合肥工業(yè)大學，2011.

[2]楊會，魯統(tǒng)利，王天軍.基于GMLAN的汽車診斷通信仿真[J].汽車工程，2010，32（10）：902-904，913.

[3]劉麗麗，徐皚冬，宋巖，等.車輛通用故障診斷協(xié)議的研究與開發(fā)[J].計算機工程，2012，38（16）：9-13.

[4]過錫雋.汽車電控系統(tǒng)J1939協(xié)議和診斷通信模塊的開發(fā)[D].杭州：浙江大學，2006.

[5]張培鋒.參照AUTOSAR的汽油發(fā)動機ECU軟件設計[D].杭州：浙江大學，2010.

[6]郭晞文.參照AUTOSAR標準的汽車電子通信與應用[D].杭州：浙江大學，2008.

[7]胡琦.參照AUTOSAR的汽車故障診斷系統(tǒng)的設計與實現(xiàn)[D].杭州：浙江大學，2011.

[8]鄒志斌.車載軟件中通信機制的研究與實現(xiàn)[D].成都：電子科技大學，2010.

[9]周毅.汽車診斷通信管理軟件的研究與實現(xiàn)[D].成都：電子科技大學，2010.

[10]AUTOSAR GBR，AUTOSAR Specification of Diag-nostic Event Manager V3.1.0，R3.1[S].

[11]ISO 11898—1，Road vehicles-Controller area network（CAN）-Data link layer and physical signaling[S].

[12]ISO/WD15765—2，Road Vehicles-Diagnostic Syst-ems-Diagnostics on CAN-Network Layer Services[S].

[13]ISO/WD15765—3，Road Vehicles-Diagnostic Syst-ems-Diagnostics on CAN-Application Layer Services[S].

[14]ISO/WD15765—4，Road Vehicles-Diagnostic Syst-ems-Diagnostics on CAN-Requirements for Emis-sion Related Systems[S].

[15]ISO 14229—1，Road Vehicles-Unified DiagnosticServices（UDS）-Specification and Requirements[S].

[16]ISO 15031—5，Road Vehicles -Communication bet-ween Vehicle and External Equipmentfor Emissions-related Diagnostics-Emissions-related Diagnostic Services[S].

[17]AUTOSAR GBR，AUTOSAR Specification of CANDriver V4.2.0，R4.1[S].

[18]AUTOSAR GBR，AUTOSAR Specification of CANTransport Layer V5.1.0，R4.1[S].

[19]AUTOSAR GBR，AUTOSAR Specification of CANPdu Router V4.1.0，R4.1[S].

[20]AUTOSAR GBR，AUTOSAR Specification of Diagn-ostic Communication Manager V5.1.0，R4.1[S].

[21]W·齊默爾曼，R·施密特加爾.汽車總線系統(tǒng)[M]. 鄧萍，譯.北京：機械工業(yè)出版社，2009：262-272.

[22]李向燕，唐柳湘，李允.基于autosar的LIN實現(xiàn)[J].企業(yè)科技與發(fā)展，2012（4）：208-211.

[23]顏伏伍，王攀.基于車載總線的PC式汽車故障診斷系統(tǒng)[J].武漢理工大學學報：信息與管理工程版，2011，33（5）：758-762.

[責任編輯：鐘聲賢]