基于IS015765的电动汽车诊断系统设计

李亚运,孙耀杰

(河北工业大学 电子信息工程学院，天津 300401)

基于IS015765的电动汽车诊断系统设计

李亚运,孙耀杰

(河北工业大学 电子信息工程学院，天津 300401)

为了更加便捷地对电动汽车进行程序更新和故障诊断，开发了符合ISO15765的底层刷写协议栈；参考BOSCH ECU在线刷写流程拟定XC2000刷写流程，包括初始化、密钥认证、Flash分区擦除、Flash分区写入等过程；开发XC2000 Flash驱动，实现Flash按地址进行块擦除和写入，开发Bootloader，实现硬件资源初始化以及ISO15765协议栈的装载；开发了符合ISO15765的底层故障诊断协议栈，实现故障码读取、故障码清除、数据流读取、执行器测试等故障诊断功能；开发了电动汽车诊断上位机系统，并通过硬件在环仿真测试平台进行测试；测试结果表明，设计的电动汽车诊断系统利用CAN总线能够实现ECU在线刷写及故障诊断功能。

ISO15765协议；电动汽车；刷写；故障诊断

0 引言

因为无污染，低噪声，高节能等优点，电动汽车取代传统汽车已经成为一种重要的发展趋势。整车控制器(英文缩写VCU)是电动汽车控制系统的核心，有“电动汽车大脑”之称。目前，VCU大多使用CAN总线通信方式，CAN总线是一种串行多主站控制器局域网总线，也是一种有效支持分布式控制或实时控制的通信网络，由于其采用了许多新技术及独特的设计，与一般通信总线相比，CAN总线的数据通信具有可靠性高、实时性和灵活性强等优点[1]。因此，本文设计的诊断系统通过CAN总线对电动汽车进行VCU程序更新和故障诊断。这种程序更新和故障诊断方式无需拆卸VCU，但要求符合ISO15765故障诊断标准。ISO15765是一种基于CAN总线的诊断系统通信标准，它符合现代汽车网络总线系统的发展趋势，已被许多汽车厂商采纳, 并将成为未来汽车行业的通用诊断标准[2]。

1 系统设计原理

1.1 ISO15765体系结构[3]

虽然ISO 15765协议主要应用于车载CAN诊断系统，但是ISO15765协议也能够做为其他CAN通信系统的网络层协议。这是因为，ISO15765协议基于ISO/IEC 7498 和ISO/IEC 10731指定的开发互联参考(OSI)模型。OSI模型将通信系统分为7层，从上到下分别为应用层、表示层、会话层、传输层、网络层、数据链路层和物理层，其中一部分应用到ISO 15765协议。

如图1所示，将ISO15765协议映射到OSI模型，ISO15765定义的服务被分割成三部分：IS0 15765-3定义的诊断服务对应着应用层，ISO15765-2定义的网络层服务对应

图1 ISO15765体系结构

着网络层，ISO11898-1定义的CAN通信服务对应着数据链路层和物理层。不仅应用层服务要遵守ISO 14229-1和ISO 15031-5这些国际诊断标准，ISO15765-3协议也要与国家标准或汽车制造商自定义的标准兼容。网络层服务可以独立于物理层实现，并且只为通用车载诊断(OBD)指定物理层，对于其他应用领域，ISO 15765协议可以应用在任何CAN物理层。

1.2 Infineon XC2000系列单片机简介

英飞凌XC2000系列MCU是英飞凌推出的具有32位处理器性能的16位MCU。XC2000家族又分为3个系列：XC2200、XC2300、和XC2700。这3个系列分别针对汽车电子中的3个应用部分：XC2200主要针对车身网关的应用；XC2300主要针对汽车安全性能的应用；XC2700则主要针对传动系统的应用。XC2000系列内部FLASH和SRAM最大为82 KB，主频最高为80 MHz。其命名规则如图2，例如SAK-XC2267-96F80L82AC：汽车级，片内FLASH为768 KB，CPU主频为80 MHz，片内SRAM为82 kB。

图2 命名规则

2 系统设计方案

2.1 刷写协议栈软件结构

2.1.1 CanLoader

CanLoader部分的代码的功能：(1)用于从PC中通过CAN总线接收需要刷写的数据。(2)加载XC2000单片机的驱动，擦除驱动和刷写驱动。(3)初始化单片机。

如图3所示，其中xc_2000_flasher.c和xc_2000_flasher.h两个文件为flash驱动，XC2765_CAN_LOADER.c和XC2765_CAN_LOADER.h为15765协议部分。在刷写ECU过程中所有的代码都在CanLoader中执行。该工程编译完成后生成hex文件，该hex文件需要保存在上位机软件Debug目录下，文件名为XC2765_CAN_LOADER.hex，在刷写过程中上位机读取文件内容并加载到固定内存区域。

2.1.2 Boot

Boot部分的代码主要功能：(1)单片机启动时，判断当前单片机中的数据是否完整，如果不完整说明上次刷写没有成功，进入Boot后续代码，等待用户进行刷写操作。如果刷写成功，则跳转到固定地址0xc10000(这个地址是用户应用程序的起始地址)。注意用户的应用程序在编译时，必须要进行地址设置，使得编译后的hex文件的首地址固定在0xc10000。(2)接收CAN数据，将CanLoader代码加载到固定的内存地址Boot这部分代码在编译后，必须要进行地址设置，使得编译后的hex文件的首地址固定在0xc00000。便于从用户应用程序跳转回Boot代码。

2.1.3 用户应用程序

如图3所示，用户应用程序代码为cprotocol.c以及cprotocol.h。这部分代码的主要功能：(1)接收到特定的can消息和数据后，从用户应用程序跳转到Boot代码部分以便于从boot中加载loader代码。(2)按照15765协议进行数据流读取和故障码读取和故障码清除的功能。值得注意的是，用户的应用程序在编译时，必须要进行地址设置，使得编译后的hex文件的首地址固定在0xc10000。

图3 工程文件列表

2.2 系统刷写协议栈工作流程

系统刷写程序的工作流程如图4所示，在开始使用系统刷写功能之前，需要先将Boot工程编译好的hex文件刷写至xc2000单片机中。

图4 刷写工作流程图

单片机启动后，首先进入Boot代码部分。判断单片机中的数据是否完整(如果不完整说明上次刷写失败)，如果数据完整则跳转到用户程序，从用户程序开始执行代码，如果数据不完整则保持在Boot中，等待用户进行单片机刷写。

开始单片机刷写后，上位机从CANLoader中读取数据，通过can发送数据给单片机。单片机把CanLoader加载到内存中，并跳转到CANLoader代码部分。至此代码从CanLoader开始执行，按照15756协议刷写单片机。

2.3 故障诊断协议栈框架与机制

如图5所示，Client代表故障诊断上位机系统，Servier代表电动汽车整车控制器，上位机系统通过MFC编程得到以PC为运行平台，整车控制器以英飞凌XC2000系列微控制器为核心。上位机系统发送给整车控制器的报文称之为请求，整车控制器发送给上位机系统的报文称之为回复，所有的通信都必须由上位机系统发起， 即先有请求后有回复。

图5 故障诊断框架与机制

2.4 系统应用的诊断服务[4-5]

诊断系统的主要功能是提供诊断服务，而实施这些诊断服务则必须要遵循ISO15765-3协议第9部分:Diagnostic services implementation 制定的规则。该部分不仅定义了ISO14229-1定义的诊断服务是如何适用于CAN的，并且定义了每一个诊断服务可用的子功能及数据参数。

刷写协议栈开发应用到的诊断服务列表如表1所示，故障诊断协议栈开发应用到的诊断服务列表如表2所示。

表1 刷写协议栈应用服务列表

表2 故障诊断协议栈应用服务列表

2.5 密钥认证

为了避免未经授权的访问，EDC支持多层次的种子密钥的安全访问，由于诊断模式分为不同的访问级别，所以开始一个诊断会话之前会强制实施SecurityAccess服务。函数seedToKeyLevel1为系统应用的SecurityAccess服务的算法：输入参数为一个uint16的数据形态，表示两个字节的无符号整数，返回值为一个uint32的数据形态，表示四个字节的无符号整数。采用的mask为uint32 mask_table[16]，共十六个4字节的无符号数，宣告四个变量，准备把密钥的四个字节分别进行不同类型的运算。根据接收到的seed，决定此次参与运算的mask数值，将seed 作位元扩展，以4字节的长度参与之后的运算。若seed为0，则密钥直接设置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 测试结果及分析

电动汽车诊断上位机系统和整车控制器在硬件在环仿真测试平台上进行联合测试，取得了令人满意的结果：(1)ECU在线刷写模块管理刷写过程中的所有协议指令交互，刷写过程准确无误。发生刷写失败时会有相应消息提示，ECU重新上电后可重复进行刷写。(2)ECU故障诊断模块能够完成当前故障码、支持的故障码、标识符数据的读取和中文显示以及数据流中各传感器、执行器数据的读取和中文显示。此外，执行器能够完成激活测试，且结果良好。(3)软件系统可实现用户和用户密码的增删查改，同时本机所有刷写和诊断操作均记录至本地数据库，以备查询。

4 结束语

本文通过研究分析ISO15765诊断协议和CAN总线技术及其协议规范，开发了符合ISO15765的底层刷写协议栈，利用CAN总线实现基于XC2000的ECU在线刷写，刷写速度可自定义；开发了符合ISO15765的底层故障诊断协议栈，实现故障诊断功能。此外，开发的上位机系统具有ECU在线刷写、故障诊断以及数据管理功能。经过硬件在环仿真测试平台验证，本文设计的电动汽车诊断系统能够达到技术目标，结果理想。

[1] 龙志强, 李晓龙, 窦峰山, 等. CAN总线技术与应用系统设计[M].北京：机械工业出版社, 2013.

[2] 李 锐, 王晶莹, 姚 燕, 等. 基于ISO15765的车载CAN 网络诊断设计[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-)，男，河北沧州人，硕士研究生，主要从事电子信息技术与工程方向的研究。

孙耀杰(1960-)，男，天津人，教授，硕士研究生导师，主要从事电子信息及计算机控制方向的研究。

1671-4598(2017)01-0024-03

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

TP391.5

A