李亞運,孫耀杰

(河北工業(yè)大學 電子信息工程學院，天津 300401)

基于IS015765的電動汽車診斷系統(tǒng)設(shè)計

李亞運,孫耀杰

(河北工業(yè)大學 電子信息工程學院，天津 300401)

為了更加便捷地對電動汽車進行程序更新和故障診斷，開發(fā)了符合ISO15765的底層刷寫協(xié)議棧；參考BOSCH ECU在線刷寫流程擬定XC2000刷寫流程，包括初始化、密鑰認證、Flash分區(qū)擦除、Flash分區(qū)寫入等過程；開發(fā)XC2000 Flash驅(qū)動，實現(xiàn)Flash按地址進行塊擦除和寫入，開發(fā)Bootloader，實現(xiàn)硬件資源初始化以及ISO15765協(xié)議棧的裝載；開發(fā)了符合ISO15765的底層故障診斷協(xié)議棧，實現(xiàn)故障碼讀取、故障碼清除、數(shù)據(jù)流讀取、執(zhí)行器測試等故障診斷功能；開發(fā)了電動汽車診斷上位機系統(tǒng)，并通過硬件在環(huán)仿真測試平臺進行測試；測試結(jié)果表明，設(shè)計的電動汽車診斷系統(tǒng)利用CAN總線能夠?qū)崿F(xiàn)ECU在線刷寫及故障診斷功能。

ISO15765協(xié)議；電動汽車；刷寫；故障診斷

0 引言

因為無污染，低噪聲，高節(jié)能等優(yōu)點，電動汽車取代傳統(tǒng)汽車已經(jīng)成為一種重要的發(fā)展趨勢。整車控制器(英文縮寫VCU)是電動汽車控制系統(tǒng)的核心，有“電動汽車大腦”之稱。目前，VCU大多使用CAN總線通信方式，CAN總線是一種串行多主站控制器局域網(wǎng)總線，也是一種有效支持分布式控制或?qū)崟r控制的通信網(wǎng)絡，由于其采用了許多新技術(shù)及獨特的設(shè)計，與一般通信總線相比，CAN總線的數(shù)據(jù)通信具有可靠性高、實時性和靈活性強等優(yōu)點[1]。因此，本文設(shè)計的診斷系統(tǒng)通過CAN總線對電動汽車進行VCU程序更新和故障診斷。這種程序更新和故障診斷方式無需拆卸VCU，但要求符合ISO15765故障診斷標準。ISO15765是一種基于CAN總線的診斷系統(tǒng)通信標準，它符合現(xiàn)代汽車網(wǎng)絡總線系統(tǒng)的發(fā)展趨勢，已被許多汽車廠商采納, 并將成為未來汽車行業(yè)的通用診斷標準[2]。

1 系統(tǒng)設(shè)計原理

1.1 ISO15765體系結(jié)構(gòu)[3]

雖然ISO 15765協(xié)議主要應用于車載CAN診斷系統(tǒng)，但是ISO15765協(xié)議也能夠做為其他CAN通信系統(tǒng)的網(wǎng)絡層協(xié)議。這是因為，ISO15765協(xié)議基于ISO/IEC 7498 和ISO/IEC 10731指定的開發(fā)互聯(lián)參考(OSI)模型。OSI模型將通信系統(tǒng)分為7層，從上到下分別為應用層、表示層、會話層、傳輸層、網(wǎng)絡層、數(shù)據(jù)鏈路層和物理層，其中一部分應用到ISO 15765協(xié)議。

如圖1所示，將ISO15765協(xié)議映射到OSI模型，ISO15765定義的服務被分割成三部分：IS0 15765-3定義的診斷服務對應著應用層，ISO15765-2定義的網(wǎng)絡層服務對應

圖1 ISO15765體系結(jié)構(gòu)

著網(wǎng)絡層，ISO11898-1定義的CAN通信服務對應著數(shù)據(jù)鏈路層和物理層。不僅應用層服務要遵守ISO 14229-1和ISO 15031-5這些國際診斷標準，ISO15765-3協(xié)議也要與國家標準或汽車制造商自定義的標準兼容。網(wǎng)絡層服務可以獨立于物理層實現(xiàn)，并且只為通用車載診斷(OBD)指定物理層，對于其他應用領(lǐng)域，ISO 15765協(xié)議可以應用在任何CAN物理層。

1.2 Infineon XC2000系列單片機簡介

英飛凌XC2000系列MCU是英飛凌推出的具有32位處理器性能的16位MCU。XC2000家族又分為3個系列：XC2200、XC2300、和XC2700。這3個系列分別針對汽車電子中的3個應用部分：XC2200主要針對車身網(wǎng)關(guān)的應用；XC2300主要針對汽車安全性能的應用；XC2700則主要針對傳動系統(tǒng)的應用。XC2000系列內(nèi)部FLASH和SRAM最大為82 KB，主頻最高為80 MHz。其命名規(guī)則如圖2，例如SAK-XC2267-96F80L82AC：汽車級，片內(nèi)FLASH為768 KB，CPU主頻為80 MHz，片內(nèi)SRAM為82 kB。

圖2 命名規(guī)則

2 系統(tǒng)設(shè)計方案

2.1 刷寫協(xié)議棧軟件結(jié)構(gòu)

2.1.1 CanLoader

CanLoader部分的代碼的功能：(1)用于從PC中通過CAN總線接收需要刷寫的數(shù)據(jù)。(2)加載XC2000單片機的驅(qū)動，擦除驅(qū)動和刷寫驅(qū)動。(3)初始化單片機。

如圖3所示，其中xc_2000_flasher.c和xc_2000_flasher.h兩個文件為flash驅(qū)動，XC2765_CAN_LOADER.c和XC2765_CAN_LOADER.h為15765協(xié)議部分。在刷寫ECU過程中所有的代碼都在CanLoader中執(zhí)行。該工程編譯完成后生成hex文件，該hex文件需要保存在上位機軟件Debug目錄下，文件名為XC2765_CAN_LOADER.hex，在刷寫過程中上位機讀取文件內(nèi)容并加載到固定內(nèi)存區(qū)域。

2.1.2 Boot

Boot部分的代碼主要功能：(1)單片機啟動時，判斷當前單片機中的數(shù)據(jù)是否完整，如果不完整說明上次刷寫沒有成功，進入Boot后續(xù)代碼，等待用戶進行刷寫操作。如果刷寫成功，則跳轉(zhuǎn)到固定地址0xc10000(這個地址是用戶應用程序的起始地址)。注意用戶的應用程序在編譯時，必須要進行地址設(shè)置，使得編譯后的hex文件的首地址固定在0xc10000。(2)接收CAN數(shù)據(jù)，將CanLoader代碼加載到固定的內(nèi)存地址Boot這部分代碼在編譯后，必須要進行地址設(shè)置，使得編譯后的hex文件的首地址固定在0xc00000。便于從用戶應用程序跳轉(zhuǎn)回Boot代碼。

2.1.3 用戶應用程序

如圖3所示，用戶應用程序代碼為cprotocol.c以及cprotocol.h。這部分代碼的主要功能：(1)接收到特定的can消息和數(shù)據(jù)后，從用戶應用程序跳轉(zhuǎn)到Boot代碼部分以便于從boot中加載loader代碼。(2)按照15765協(xié)議進行數(shù)據(jù)流讀取和故障碼讀取和故障碼清除的功能。值得注意的是，用戶的應用程序在編譯時，必須要進行地址設(shè)置，使得編譯后的hex文件的首地址固定在0xc10000。

圖3 工程文件列表

2.2 系統(tǒng)刷寫協(xié)議棧工作流程

系統(tǒng)刷寫程序的工作流程如圖4所示，在開始使用系統(tǒng)刷寫功能之前，需要先將Boot工程編譯好的hex文件刷寫至xc2000單片機中。

圖4 刷寫工作流程圖

單片機啟動后，首先進入Boot代碼部分。判斷單片機中的數(shù)據(jù)是否完整(如果不完整說明上次刷寫失敗)，如果數(shù)據(jù)完整則跳轉(zhuǎn)到用戶程序，從用戶程序開始執(zhí)行代碼，如果數(shù)據(jù)不完整則保持在Boot中，等待用戶進行單片機刷寫。

開始單片機刷寫后，上位機從CANLoader中讀取數(shù)據(jù)，通過can發(fā)送數(shù)據(jù)給單片機。單片機把CanLoader加載到內(nèi)存中，并跳轉(zhuǎn)到CANLoader代碼部分。至此代碼從CanLoader開始執(zhí)行，按照15756協(xié)議刷寫單片機。

2.3 故障診斷協(xié)議?？蚣芘c機制

如圖5所示，Client代表故障診斷上位機系統(tǒng)，Servier代表電動汽車整車控制器，上位機系統(tǒng)通過MFC編程得到以PC為運行平臺，整車控制器以英飛凌XC2000系列微控制器為核心。上位機系統(tǒng)發(fā)送給整車控制器的報文稱之為請求，整車控制器發(fā)送給上位機系統(tǒng)的報文稱之為回復，所有的通信都必須由上位機系統(tǒng)發(fā)起， 即先有請求后有回復。

圖5 故障診斷框架與機制

2.4 系統(tǒng)應用的診斷服務[4-5]

診斷系統(tǒng)的主要功能是提供診斷服務，而實施這些診斷服務則必須要遵循ISO15765-3協(xié)議第9部分:Diagnostic services implementation 制定的規(guī)則。該部分不僅定義了ISO14229-1定義的診斷服務是如何適用于CAN的，并且定義了每一個診斷服務可用的子功能及數(shù)據(jù)參數(shù)。

刷寫協(xié)議棧開發(fā)應用到的診斷服務列表如表1所示，故障診斷協(xié)議棧開發(fā)應用到的診斷服務列表如表2所示。

表1 刷寫協(xié)議棧應用服務列表

表2 故障診斷協(xié)議棧應用服務列表

2.5 密鑰認證

為了避免未經(jīng)授權(quán)的訪問，EDC支持多層次的種子密鑰的安全訪問，由于診斷模式分為不同的訪問級別，所以開始一個診斷會話之前會強制實施SecurityAccess服務。函數(shù)seedToKeyLevel1為系統(tǒng)應用的SecurityAccess服務的算法：輸入?yún)?shù)為一個uint16的數(shù)據(jù)形態(tài)，表示兩個字節(jié)的無符號整數(shù)，返回值為一個uint32的數(shù)據(jù)形態(tài)，表示四個字節(jié)的無符號整數(shù)。采用的mask為uint32 mask_table[16]，共十六個4字節(jié)的無符號數(shù)，宣告四個變量，準備把密鑰的四個字節(jié)分別進行不同類型的運算。根據(jù)接收到的seed，決定此次參與運算的mask數(shù)值，將seed 作位元擴展，以4字節(jié)的長度參與之后的運算。若seed為0，則密鑰直接設(shè)置0，否則就分別對密碼的四組byte 做不同的運算，最后將密鑰的四組byte組合起來得到key。

uint32 seedToKeyLevel1(uint16 input_seed)

{

uint32 mask_table[16]={****};

uint32 key = 0;

uint16 mask_index = input_seed % 16;

uint32 mask_chosen =

mask_table[mask_index];

uint32 seed = input_seed;

seed = seed & 0x0000FFFF;

if(seed == 0) { return 0; }

else{key_byte1 =(seed >>((mask_index / 2) + 1)) +(mask_chosen >> 3);

key_byte2 =((mask_chosen >> ((seed % 10) +10)) * (mask_index + 1)) ^ seed;

key_byte3=(0x000FFFFF&key_byte1)* ((0x00000FFF) & key_byte1);

key_byte4 = (key_byte2 ^ key_byte3) >> 5; }

key = (key_byte1 << 24) + (key_byte2 << 16) + (key_byte3 << 8) + key_byte4; return key;

}

3 測試結(jié)果及分析

電動汽車診斷上位機系統(tǒng)和整車控制器在硬件在環(huán)仿真測試平臺上進行聯(lián)合測試，取得了令人滿意的結(jié)果：(1)ECU在線刷寫模塊管理刷寫過程中的所有協(xié)議指令交互，刷寫過程準確無誤。發(fā)生刷寫失敗時會有相應消息提示，ECU重新上電后可重復進行刷寫。(2)ECU故障診斷模塊能夠完成當前故障碼、支持的故障碼、標識符數(shù)據(jù)的讀取和中文顯示以及數(shù)據(jù)流中各傳感器、執(zhí)行器數(shù)據(jù)的讀取和中文顯示。此外，執(zhí)行器能夠完成激活測試，且結(jié)果良好。(3)軟件系統(tǒng)可實現(xiàn)用戶和用戶密碼的增刪查改，同時本機所有刷寫和診斷操作均記錄至本地數(shù)據(jù)庫，以備查詢。

4 結(jié)束語

本文通過研究分析ISO15765診斷協(xié)議和CAN總線技術(shù)及其協(xié)議規(guī)范，開發(fā)了符合ISO15765的底層刷寫協(xié)議棧，利用CAN總線實現(xiàn)基于XC2000的ECU在線刷寫，刷寫速度可自定義；開發(fā)了符合ISO15765的底層故障診斷協(xié)議棧，實現(xiàn)故障診斷功能。此外，開發(fā)的上位機系統(tǒng)具有ECU在線刷寫、故障診斷以及數(shù)據(jù)管理功能。經(jīng)過硬件在環(huán)仿真測試平臺驗證，本文設(shè)計的電動汽車診斷系統(tǒng)能夠達到技術(shù)目標，結(jié)果理想。

[1] 龍志強, 李曉龍, 竇峰山, 等. CAN總線技術(shù)與應用系統(tǒng)設(shè)計[M].北京：機械工業(yè)出版社, 2013.

[2] 李 銳, 王晶瑩, 姚 燕, 等. 基于ISO15765的車載CAN 網(wǎng)絡診斷設(shè)計[J].計算機工程， 2012,38(4):35-36.

[3] ISO 15765-1:2004-Road vehicles-Diagnostics on Controller Area Networks(CAN)-Part1:General information.

[4] ISO 14229-1:2006-Road vehicles-Unified Diagnostic Services (UDS)-Part 1:Specification and requirements.

[5] ISO 15765-3:2004-Road vehicles-Diagnostic on Controller Area Network (CAN)-Part 3: Implementation of Unified Diagnostic Services (UDS on CAN).

Design of Electric Vehicle Diagnosis System Based on ISO15765

Li Yayun, Sun Yaojie

(School of Electronics and Information Engineering, Hebei University of Technology, Tianjin 300401,China)

In order to carry out the program update and fault diagnosis of electric vehicle more conveniently, an underlying programming protocol stack in line with ISO15765 standards is developed. Referring to the BOSCH ECU online programming progress, the XC2000 programming process is proposed,which include initialization, key authentication, Flash partion erasing, Flash partion writing, etc. The XC2000 Flash driver has been developed to implement Flash block erasing and writing by address, and Bootloader has been developed to implement hardware resource initialization and loading IS015765 protocol stack. An underlying fault diagnosis protocol stack in line with ISO15765 standards is developed to implement reading DTC, clearing DTC, reading data flow, actuator test etc. An electric vehicle diagnosis host computer system is developed, which is tested by the Hardware-in-the-loop Test Bench. And the results show that the electric vehicle diagnosis system based on CAN bus have both ECU online programming and fault diagnosis functions.

ISO 15765 protocol; electric vehicle; programming; fault diagnosis

2016-07-22；

2016-08-24。

李亞運(1991-)，男，河北滄州人，碩士研究生，主要從事電子信息技術(shù)與工程方向的研究。

孫耀杰(1960-)，男，天津人，教授，碩士研究生導師，主要從事電子信息及計算機控制方向的研究。

1671-4598(2017)01-0024-03

10.16526/j.cnki.11-4762/tp.2017.01.007

TP391.5

A