基于ISO 15765 协议的汽车控制器刷写系统的设计

唐恒飞，王效金

（1.201620 上海市 上海工程技术大学 机械与汽车工程学院；2.200120 上海市 上海银基信息安全技术股份有限公司）

0 引言

无人驾驶技术、车联网技术和新能源电动汽车的热潮席卷整个汽车行业，不仅导致装载在汽车上的控制器数量增加，也使得控制器的控制策略和功能复杂度提高，而传统的软件升级方式已无法满足。因此，国内外很多的学者和企业都在研究汽车控制器刷写。文献[1]提出了一种基于ISO 15765协议和BootLoadr的汽车ECU升级方案，详细介绍了汽车ECU 的BootLoader 刷写软件的实现原理；文献[2]利用CANoe，基于ISO 15765协议设计了ECU 刷写上位机软件；文献[3]基于ISO 15765 协议和XC2000 单片机，设计了汽车诊断系统软件。以上的文献都介绍了刷写软件的设计，本文则偏向于上位机刷写软件设计流程以及研究上下位机之间的信息交互，经过上下位机联调测试，体现设计软件的准确性和可靠性。

1 ISO 15765 协议

ISO 15765 协议是一种基于CAN 总线的诊断协议。其中ISO 15765-1 应用于物理层和数据链路层，ISO 15765-2 对网络层进行说明，ISO 15765-3 则是规定到应用层的具体服务，本文的设计研究主要是ISO 15765-2 和ISO 15765-3。

1.1 ISO 15765-3

ISO 15765-3 规定了诊断服务的具体命令，不同的服务命令都有自己独特的标识符。表1 是ISO 15765 协议用于刷写的命令[4]。

表1 ISO 15765-3 协议服务命令Tab.1 ISO 15765-3 protocol service command

（续表）

1.2 IS0 15765-2

ISO 15765-2是对汽车诊断中网络层的说明。它规定网络层在接收到应用层发过来的消息流后，根据定义中的分包、位填充和时间控制等步骤对消息流进行控制传输[5]。流控制传输依据数据长度是否超过8 个字节分为单帧传输和多帧传输两种类型，多帧传输又包含首帧、连续帧以及流控制帧，表2 是帧类型。如表2 所示前3 个字节进行判别。单帧相对简单，遵循一问一答机制，单帧中SF_DL 代表单帧传输中数据字节数，而多帧就比较复杂。多帧数据在传输时，上位机软件首先给控制器发送一个首帧数据，首帧数据中包含控制器即将接收数据字节的大小（FF_DL）。当控制器接收到该命令消息，给上位机回复一个流控制帧。流控制帧主要有3 个参数，流控制帧状态（FS）、连续帧连续发送的最大数目（BS）以及两个连续帧之间的时间间隔（ST_min）。FS有0，1，2 三个值，分别代标着继续发送、停止发送和数据溢出。通常在收到流控制帧时，该位常常是0。BS 有一定范围（0～255），当两个连续帧之间的间隔时间超出ST_min 时，ECU 端就会给上位机端回复一个发送错误的消息帧。最后是不断传输连续帧。连续帧中的SN 代表着连续帧的连续号，每增加一个连续帧，SN 就加1，直到增加到15 时，SN 重新置0[6]。

表2 帧类型Tab.2 Frame types

2 刷新系统的组成以及原理

整个刷新系统由3 部分组成，上位机刷写软件、汽车诊断仪以及车载电控单元，系统组成如图1 所示。上位机软件通过USB 线与汽车诊断仪进行连接，人工操作界面，将刷写文件通过串口发送给汽车诊断仪，汽车诊断仪通过自身硬件串口读取数据流，将数据流分解，重组，形成符合CAN 总线传输的数据，再通过ISO 15765 协议将刷写程序传输给车载电控单元。

图1 系统组成Fig.1 System composition

3 刷写系统设计

3.1 刷写流程

基于ISO 15765 协议的ECU 在线刷新，是按照ISO15765 协议规定的相关服务命令进行软件程序刷新。整个软件程序刷写可以分为3 个阶段，预编程阶段、主编程阶段和后编程阶段[7-8]。

3.1.1 预编程阶段

预编程阶段是在进行主编程前的CAN 网络准备。流程如图2 所示

图2 预编程阶段Fig.2 Pre-programming stage

首先连通上下位机。通电之后，车载电控单元进入诊断默认会话模式。上位机发送0x81 请求与控制器进行通信，当控制器给上位机回复一个包含0xC1 的命令时代表通信成功。控制器就会不停地往上位机发送诊断记录信息，上位机发送0x28 命令，请求停止诊断记录发送，这样可以让CAN 总线不处于忙碌状态，在进行刷写时，能够大大减少刷写时间。车载电控单元的程序被更新时，需要电控单元的会话处于刷写模式下，因此发送0x10 85 命令请求进入刷写模式。对控制器的Flash 区进行擦除和数据写入，是一个级别较高的操作，需要通过密钥才能进入。向控制器发送0x27 07 请求命令，控制器收到请求，给汽车诊断仪回复一个0x67 07 AA BB CC DD 的消息帧，AA BB CC DD 代表4 个seekey，汽车诊断仪对这4 个seedkey 进行算法计算得到4 个掩码，再发送0x27 08 EE FF GG HH 给ECU，ECU 拿到这4 个掩码与自己的动态数据库进行匹配，匹配成功则会回复一个包含0x67 08 的消息帧，代表允许对控制器Flash 区进行操作。

3.1.2 主编程阶段

主编程阶段主要分为Flash 区的擦除和数据写入。整个主编程阶段的流程图如图3 所示。

图3 主编程阶段Fig.3 Main programming stage

对Flash 区进行擦除的命令是0x31，请求擦除的起始地址和擦除的空间大小。本文是从0x8008 0000 这个地址开始每个区块进行擦写。命令0x33 02请求询问擦除区域是否被完整擦除，确定擦除成功之后，上位机向ECU 请求下载文件的地址和最大数据长度，发送0x34 命令，利用0x36 命令，上位机软件开始将刷写程序传输给ECU。往往传输的数据量比较大，需要不停地重复0x36 命令，当传输完成之后，遵循0x37 命令，请求退出传输状态，整个主编程阶段结束。

3.1.3 后编程阶段

后编程阶段主要是校验写入的程序是否完整来判断整个刷写操作是否成功。后编程阶段的流程如图4 所示。当控制器退出数据传输状态，上位机就立刻发送0x31 01 命令，请求检查刷写程序的完整性，收到0x71 01 命令就代表了此次车载电控单元程序刷写成功。上位机发送0x11 命令请求，重新启动ECU。

图4 后编程阶段Fig.4 Post programming stage

3.2 下位机介绍

下位机是由实验室基于恩智浦公司的imx6ull芯片进行开发的汽车诊断仪，主要包含微处理器模块，高速CAN 通信模块，低速CAN 通信模块以及RS232 模块等[9]。在此基础上，利用codeWarrior 编写CAN 通信模块以及ISO15765 协议栈，用于处理与车载电控单元间的数据交互。

3.3 上位机软件设计

上位机软件是基于微软.Net 平台的C#语言设计的人机交互界面，C#语言是一种面向对象的编辑语言，是从C 和C++派生的一种简单、现代、面向对象和类型安全的编程语言，并且能够与.Net 框架完美结合。上位机软件有4 个部分：Winform 界面、通信逻辑层、数据库以及服务器。

3.3.1 Winform 界面与数据库设计

Winform 界面主要有3 个界面，登录界面、控制器选择界面以及刷写界面。用到一些简单的控件，如label，button，textbox 等。通过触发button 控件的Click()事件从而在界面上显示相关的信息以及进行刷写操作。数据库的设计是建议一张刷写文件的表格，关键字段有ECU_Name，ECU_SoftWareNumber，.A2L 和.Hex 文件名等。在读取控制的软件版本号，依靠这些关键字段的查找、匹配成功之后从服务器后台下载刷写文件。

3.3.2 通讯逻辑层设计

本设计的刷写软件属于自动化刷写，在选择好刷写文件后，点击一键刷写，流程如图5 所示。

图5 逻辑层流程图Fig.5 Logic layer flow chart

上位机软件抓取到的数据流都是通过串口进行发送和读取的，因此在逻辑层中设计了发送函数SendMeaasge()和读取函数ReceiveMessage()。客户端软件打开之后，通过ECUInit()函数和私有协议与汽车诊断仪连接成功。在选择控制类型时，触发button 控件的Click 事件，利用发送函数向串口发送包含0x81，0x1A 的命令用于连接控制器和读取控制器版本信息，将读取到的数据流进行解析，并带入数据库中去匹配，从而再从后台下载刷写文件。刷写文件直接存储到该debug 文件夹下，当点击刷写文件时，可以直接打开文件所在的位置。开始刷写是软件操作过程中最复杂的过程。本次刷写用到的刷写文件格式是.hex 文件。.hex 文件就是通过Freescal CodeWarrior 软件编译而成的一种刷写文件。.hex 文件可以通过文本进行打开，打开后的文件内容是一行行记录。这一行行记录都是以冒号开头，内容是16 进制码。表3 是.hex 文件格式。.hex 文件传输进ECU前，需要遵循ISO 15765 协议对.hex 文件进行解析，提取记录数据长度、数据起始地址以及数据内容，提取完毕之后再转换成CAN 报文格式将这些数据传输到ECU 中。在C#中，通过对文件流的读取，利用substring()函数将所需的数据地址、数据内容等参数截取下来，存放到临时的字符串数组中，以便在数据传输时能够在线发送。

表3 .hex 文件格式Tab.3 .hex file format

4 软件测试

为了验证刷写软件设计的正确性和适用性，进行了上下位机联调。图6 是上位机WinForm界面，图7 显示的是上位机刷写界面和通过CANList-2 抓取到的部分CAN 报文信息。

图6 上位机WinForm 界面Fig.6 Upper computer WinForm interface

图7 CAN 报文展示Fig.7 CAN message display

从报文中可以看出，首先进入刷写模式下（0x10 85），接着进入安全校验（0x27 07/08），然后擦除对应的flash 区（0x31 02），通过0x33命令请求是否擦写完毕。擦写完毕之后，将需要写入的数据传输给控制器（0x36）,传输结束之后将会退出传输状态（0x37），为了检验刷写的数据是否完整，即发送请求进行校验（0x31 01），再通过0x33 命令请求是否校验成功。校验成功之后，代表刷写数据完整，最后将控制器进行硬件重启（0x11 01 ）,刷写功能就完成了。从这些监测到的报文也就能够证明刷写的正确性和适用性。

5 结语

在此次研究中，本文利用C#语言编写了上位机刷写软件，遵循V 型软件开发流程，为从事汽车控制器刷写的研究者提供一种上位机刷写方法，而且基于ISO 15765 协议和CAN 通讯机制对上下位机之间的信息交互做了详细的介绍，也为刚接触汽车控制刷写的工作者有一个快速和全面的了解。但是本文的设计也存在着不足，刷写的速度不是很快，需要以后去解决。