喬美昀 韋天文

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

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

【中圖分類號】U472.9 【文獻(xiàn)標(biāo)識碼】A 【文章編號】1674-0688（2018）07-0036-05

0 引言

隨著現(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）和運行時環(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)

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

為了實現(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，也按照OSI模型對診斷通信進(jìn)行了分層，并用具體的診斷通信協(xié)議對每層做了詳細(xì)的規(guī)定。隨著診斷通信協(xié)議的不斷完善，已經(jīng)形成一套完整的診斷通信架構(gòu)（見表1）。根據(jù)應(yīng)用范圍的不同，診斷通信分為2種：一種是與排放無關(guān)的診斷，叫增強型診斷，即UDS診斷；一種是與排放相關(guān)的診斷，叫OBD診斷。

傳統(tǒng)的診斷通信協(xié)議棧的開發(fā)，基本都是按照診斷協(xié)議中OSI模型來建立整體架構(gòu)的。但診斷通信的OSI模型并沒有在具體功能的開發(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的硬件布局，提供了一種平等訪問總線通道的機制而無需考慮這些控制器的物理位置。

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

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

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

本文開發(fā)的診斷通信協(xié)議棧，選擇實現(xiàn)UDS診斷服務(wù)，OBD服務(wù)會在以后進(jìn)行擴展。整個協(xié)議棧的開發(fā)采用由下往上的方式，DCM以下的模塊作為基本CAN通信軟件一起開發(fā)，DCM作為診斷應(yīng)用層單獨開發(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ù)雜。本文旨在單獨實現(xiàn)診斷通信的功能，因此對代碼結(jié)構(gòu)做了一定的簡化，整個診斷通信協(xié)議棧的代碼文件結(jié)構(gòu)如圖2所示。

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

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

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

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

整個診斷通信協(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)用CanIf_RxIndication（）將數(shù)據(jù)傳遞至CAN接口層，CAN接口通過查詢標(biāo)識符列表對數(shù)據(jù)進(jìn)行軟件過濾后，再調(diào)用上層的xxx _RxIndication（）進(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（）告知上層模塊。

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

在AUTOSAR標(biāo)準(zhǔn)中，CAN通信協(xié)議棧的硬件可以包含多個CAN控制器，但統(tǒng)一由同一個CAN驅(qū)動管理。CAN驅(qū)動是協(xié)議棧里面唯一可以直接訪問和操作硬件的模塊，它通過分配給每個CAN控制器的ID獲得對它們的訪問。本文只采用了一個CAN控制器，用于實現(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ù)幀格式，實現(xiàn)標(biāo)準(zhǔn)幀和擴展幀的收發(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)系。

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

當(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ū)動層實現(xiàn)。本文為此分別開發(fā)了2個函數(shù)，接口層的CanIf_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ù)CanIf_SetPduMode（）用于實現(xiàn)L-PDU信道4個狀態(tài)的切換：CANIF_OFFLINE，此時不進(jìn)行通信；CANIF_PASSIVE，此時只接收不發(fā)送數(shù)據(jù)；CANIF_ACTIVE，此時只發(fā)送不接收數(shù)據(jù)；CANIF_ONLINE，此時進(jìn)行正常的數(shù)據(jù)收發(fā)。狀態(tài)機如圖4所示。此外，在CAN傳輸層還通過CanTp_Shutdown（ ）實現(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、N_Ar、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 communication management、Data transmission、Stored data transmission、InputOutput control、Remote activation 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)行驗證，最后執(zhí)行有效診斷服務(wù)請求的操作。本文對應(yīng)以上要求，為DCM模塊分別開發(fā)了3個子模塊：DSL、DSD、DSP。

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

DSD模塊首先負(fù)責(zé)驗證服務(wù)請求消息的有效性。包括檢查服務(wù)標(biāo)識符是否在支持的服務(wù)列表里，檢查當(dāng)前會話模式、安全權(quán)限和ECU狀態(tài)是否支持該服務(wù)，檢查服務(wù)子功能和參數(shù)格式是否正確。如果發(fā)現(xiàn)消息無效，則返回對應(yīng)的否定響應(yīng)碼。如果請求消息通過有效性驗證，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é)議的驗證。診斷設(shè)備采用自主開發(fā)的PC式故障診斷系統(tǒng)，該系統(tǒng)運行在個人電腦上，然后通過自主開發(fā)的VCI（車輛通信接口）接入車載診斷網(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)首先要對VCI進(jìn)行配置，包括設(shè)定通信波特率為500 kb/s，通過復(fù)位完成配置。

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

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

4 結(jié)語

本文在研究AUTOSAR標(biāo)準(zhǔn)的設(shè)計思想和軟件體系后，開發(fā)了一個基于AUTOSAR架構(gòu)的診斷通信協(xié)議棧，該協(xié)議棧的垂直結(jié)構(gòu)為從下往上的分層模塊，水平結(jié)構(gòu)為數(shù)據(jù)傳輸、通信模式控制、時間管理和診斷服務(wù)處理四大功能。該分層式協(xié)議棧的各模塊可以單獨進(jìn)行開發(fā)和調(diào)試，提高了協(xié)議棧的開發(fā)效率和復(fù)用度。通過對硬件抽象層的修改，可以將該診斷通信協(xié)議棧快速可靠地應(yīng)用到其他硬件平臺，具有很高的可移植性和通用性。

參 考 文 獻(xiàn)

[1]周濤，ISO 15765協(xié)議的研究實現(xiàn)[D].合肥：合肥工業(yè)大學(xué)，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].杭州：浙江大學(xué)，2006.

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

[6]郭晞文.參照AUTOSAR標(biāo)準(zhǔn)的汽車電子通信與應(yīng)用[D].杭州：浙江大學(xué)，2008.

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

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

[9]周毅.汽車診斷通信管理軟件的研究與實現(xiàn)[D].成都：電子科技大學(xué)，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].武漢理工大學(xué)學(xué)報：信息與管理工程版，2011，33（5）：758-762.

[責(zé)任編輯：鐘聲賢]