基于诊断协议的车身ECU 在线升级系统的设计

蒋建春，连依萍，郑太雄，陈洪霞

(重庆邮电大学汽车电子与嵌入式系统研究所，重庆 400065)

0 引言

在汽车电子产品生产和售后阶段，常需要更新电子控制单元(electronic control unit，ECU)中的代码，将系统拆下来取出ECU，再通过专用烧写器将新代码写入。此方法不但麻烦而且也容易损坏电路板。所以要求开发一套具备固件更新升级功能的系统。在国外，汽车电子起步早，开发人员已经通过专有网络:控制器局域网(controller area network，CAN)，本地互连网络(local interconnect network，LIN)，FlexRay，基本形成了网络化的汽车电子系统的调试、维护、升级、诊断系统，在国内，汽车电子起步相对较晚，技术水平较低。国内网络研发技术薄弱，车载网络技术基本上还处于试验和样机阶段，所以目前还未见适用于汽车领域的网络化升级系统。只有文献［1］中提出通过LIN网络实现ECU网络升级系统，但使用的是自定义协议，可扩展性不强。CAN网络由于其非破坏性的网络仲裁机制、较高的通讯速率和灵活可靠的通讯方式，在车载网络领域广受青睐。ISO15765协议是基于CAN总线的车载诊断协议标准，该协议规定了命令格式，但并没有规定服务内容，这就使得在ISO15765协议框架下，用户可以根据自己的需要和要求设计相关服务［2］，增加了开发的灵活性，近年来在欧洲汽车领域得到广泛应用。本文基于ISO15765诊断数据通信协议给出在线升级系统的设计方法，该方法将升级功能嵌入到ECU的在线诊断功能中，实现升级、诊断系统的一体化、网络化，具有一定的现实意义。

1 在线升级技术原理

常用的在线升级方法主要有在系统编程(in system programming，ISP)和在应用编程(in application programming，IAP)。这2种方法都是通过固化在ECU中的一段bootloader代码和一系列的机制(硬件/软件上)实现不拆硬件设备便可以改变flash存储器中数据的方法［3］。在正常运行时，不执行bootloader代码，当检测到有下载要求时便和上位机通信，下载数据到存储区。ISP和IAP技术的主要区别是:①ISP方法需要通过硬件电路触发升级系统(例如，通过上电后检查某个特定引脚电平等)，所以使用ISP技术要求有硬件支持而且操作人员必须到操作现场。IAP方法设计为可在运行应用代码过程中执行代码升级，升级系统通过软件触发(上位机发送的升级命令)实现，增加了灵活性;②ISP方法的bootloader和应用代码是相互独立，在没有触发升级系统时不被运行，存放位置没有严格限制。而在IAP方法中，系统上电后首先运行bootloader，检查升级标志位，在没有升级命令后跳入到应用代码，所以bootloader占用了flash的低端地址，但一般ECU的低端flash用于存放中断向量表，被bootloader占用后，中断将无法响应，所以采用IAP方法必须对flash低端的中断向量表进行处理。所以，IAP方法的实现相对复杂。

2 在线升级系统的整体架构

汽车车身控制系统的控制对象比较多而且分布于整个车体，系统应用的ECU节点安装位置分散。目前都采用分布式控制方式，通过CAN总线将各个控制节点组成网络［4］。基于CAN总线的在线升级系统结构如图1所示。

图1 车身网络系统结构框图Fig.1 Body network system structure diagram

图1中，各个ECU节点通过CAN接口接入CAN总线，PC主机通过 USB－CAN转接卡连接到CAN总线上。该升级系统采用IAP方法实现，不需要添加硬件，只在原来的车身网络系统中添加升级功能软件。即在ECU上固化一段用于实现升级功能的 bootloader，个人计算机(personal computer，PC)机上安装用于下载应用代码的文件下载工具。整个升级系统便是利用下载工具通过CAN总线和bootloader实现应用代码的更新。在该系统中，上位机的下载工具主要是提供用户操作界面，并解析目标文件，最后根据ISO15765通信协议组织命令报文实现和ECU节点通讯，将应用代码打包发送给ECU。下位机bootloader主要是响应相应的命令报文，接收应用代码并将其写入指定的存储器空间中，引导升级的整个过程。

3 基于诊断协议的在线升级系统设计

3.1 在线升级bootloader设计

为了在无需添加硬件条件下实现在线升级功能，本文根据IAP设计要求必须将ECU的存储器分为2个部分:①应用代码区。这部分用于存储相关的协议栈、操作系统、控制算法等;②bootloader区。主要存放ECU初始化启动代码、传输协议、CAN驱动、flash驱动、引导装载等，通过这段代码控制对应用代码更新。考虑到ECU中断向量表都是存放在flash低端起始地址，由于bootloader代码占用了这段存储空间，所以为了能够正确响应中断，本文设计在应用代码区开辟一段空间，在原来中断向量表处通过软件跳转到对应的应用代码段中的中断向量表实现了中断向量的重新映射。图2是一个包含bootloader的ECU flash存储结构。

图2 含bootloader的存储结构Fig.2 Storage structure containing bootloader

Bootloader 代码和首次应用代码通过编译器一起写入存储器中。以后再更新应用代码可以通过CAN总线进行下载。ECU节点运行状态切换如图3所示。

图3 ECU在线升级状态切换图Fig.3 ECU online update state－transition diagrams

具有升级功能的 ECU上电之后，首先进入bootloader区，执行ECU初始化启动代码，进行基本的配置，初始化CAN节点。由于在进行flash擦写操作时，不宜读取指令，所以这里将flash驱动函数拷贝到随机存取存储器(random access memory，RAM)中，最后清除升级标志位，直接进入应用代码区。在执行应用代码中的某个时刻接收到升级命令进入编程会话状态后，设置升级标志位，然后转入bootloader的引导装载部分。在引导装载的控制下，对操作人员身份确认通过后，按照传输协议接收数据，调用flash驱动函数更新应用代码区代码。升级完成后清除升级标志位，系统重启。

3.2 ISO15765诊断协议简介

ISO 15765协议是欧洲汽车领域广泛采用的车载诊断协议KWP2000在CAN总线上的实现。数据链路层采用了ISO 11898—1协议;应用层采用了ISO 15765—3协议;网络层则采用ISO 15765—2协议，规定了网络层协议数据单元与底层CAN数据帧、上层KWP 2000服务之间的映射关系，并且为长报文的多包数据传输过程提供了同步控制、顺序控制、流控制和错误恢复功能。该协议规定了命令格式，但并没有规定服务内容，用户可以根据自己的需要和要求设计相关服务。在线升级系统中用到服务见表1所示。

表1 诊断服务信息表Tab.1 Diagnosis service information list

在故障诊断协议中通信控制服务报文作用是控制ECU是否接收或者发送消息报文(即控制ECU是否和服务器通信)，控制故障码(diagnostic trouble codes，DTCs)设置服务报文是用于ECU停止或恢复和服务器中的故障诊断码设置，诊断会话控制服务报文用于使能不同的诊断服务。在线升级系统中通过这3项服务报文使ECU停止当前除升级功能外的一切工作，准备进入升级状态。在故障诊断协议中，安全访问报文和写数据标识服务报文是提供一种访问ECU中数据或者诊断服务限制方法。在线升级系统中这2项服务报文用于验证在线升级操作人员的身份。故障诊断协议中例程控制服务报文用于使ECU启动、停止一段例程或者是请求某段例程执行结果。在线升级系统中该服务报文用于启动flash的擦除和数据写入操作。故障诊断协议中请求下载服务报文用于请求服务器和ECU之间数据传送，请求传输退出服务报文用于终止服务器和ECU之间的数据传输。在线升级系统中，这2项服务报文用于升级代码的传输。每条报文的具体报文格式及其详细说明见14229规范参考文献［5］和文献［6］。

对安全访问种子和密钥服务，诊断协议没有规定具体算法。在该升级系统中，采用置换密码的方法，种子和密钥都是16位的16进制数(0～F)，密钥为种子循环后移5位［5］。例如:

ECU在接收到安全访问报文后，从某个固定应用代码存储区中读取2个字节作为种子(每次下载的应用代码不同，该存储区内容也不同，所以种子也是不同)发给上位机，ECU和操作人员都按照种子计算出密钥，操作人员将密钥发送给ECU，ECU核对操作人员的密钥，如果正确则等待下一步操作，否则退出升级系统，返回应用代码。

3.3 在线升级流程设计

基于ISO15765诊断协议的在线升级系统升级过程包括3个阶段:预编程阶段、编程阶段和编程结束。整个在线升级的时序如图4所示。

图4 在线升级时序图Fig.4 Online update timing diagram

预编程阶段主要是为下载程序的编程阶段做准备工作。首先上位机要发送一个单帧的诊断会话控制报文(服务号为10 hex)使ECU进入扩展诊断会话模式。然后通过发送一个单帧的DTCs设置控制报文(服务号为85 hex)停止所有的DTCs诊断服务，防止由于正处于升级状态而不能正常通信产生误报诊断信息。最后通过发通信控制报文(服务号为28 hex)停止正常的应用层报文，因为在升级过程中应用代码已被擦除无法正确响应这些报文。

编程阶段正式开始进行编程，首先上位机要发送一个单帧的诊断会话控制报文(服务号为10 hex)使ECU进入编程会话模式。进入编程会话模式后通过发送一个单帧的安全访问报文(服务号为27 hex)请求种子，根据ECU给出的种子计算出密钥key后再通过安全访问报文传送给ECU。通过安全验证后发送一个单帧的例程控制报文，启动ECU内部的flash擦除例程，将应用代码区清空。在存储区擦除成功之后，发送请求数据下载报文(服务号为34 hex)，把将要下载的数据的长度，数据存放的起始地址传送给ECU。然后将应用代码数据打包通过传输数据报文(服务号为36 hex)依次发送给ECU。数据传输结束后，发送一个单帧的请求传输退出报文(服务号为37 hex)通知ECU数据传输完成。在接收到ECU对该帧响应后发送一个单帧的启动例程报文(服务号为31 hex)启动应用程序校验例程对应用代码进行校验。

编程结束阶段是在下载完所有的应用程序并且校验正确无误后，发送单帧的ECU复位报文(服务号为11 hex)使ECU重启。

4 基于诊断协议的在线升级系统实现

基于ISO15765诊断协议升级系统的设计方案已应用于XC167CI和STM8单片机应用代码升级中，并且取得良好的效果。图5是该方案设计的升级系统用于下载XC167CI应用代码的上位机截图。

该上位机软件包括CAN的相关配置区、预编程区、文件下载区和信息区等几个部分。参数配置区主要是CAN波特率等参数设置;预编程区主要是ECU型号选择，安全访问验证;文件下载区主要是擦除命令启动、目标代码扫描、启动文件下载命令;信息区用于显示各种操作信息或者状态信息如:进入升级状态、升级结束等。

5 结论

基于ISO15765诊断协议的车载ECU在线网络升级，无需增加任何硬件资源便实现通过网络更新ECU应用代码。引入操作者身份验证功能，可以防止非法操作人员操作，提高安全性，方便车身ECU代码的升级和维护工作。遵循ISO15765诊断协议，将在线升级功能兼容于诊断系统中，具有较高的移植性、可靠性、提高通用性和兼容性，有利于形成网络化的汽车电子系统的调试、维护、升级、诊断系统，对于汽车电子的发展有一定意义，推动国内的汽车电子行业与国际水平接轨。

图5 下载XC167CI应用代码Fig.5 Download XC167CIapplication code

［1］张本宏，韩江洪.总线式车身控制系统在应用编程的研究与实现［J］.汽车工程，2009，31(11):1086－1090.

ZHANG Ben－hong，HAN Jiang－hong.Research and Implementation of IAP for Bus－based Auto－body Control System［J］.Automotive Engineering，2009，31(11):1086－1090.

［2］张丽，方成.基于ISO15765的柴油机故障诊断接口开发［J］.车用发动机，2009，(4):16－19.

ZHANG Li，FANGCheng.The Developmentof FaultDiagnosis Interface for Diesel Based on ISO15765［J］.VEHICLE ENGINE，2009，(4):16－19.

［3］杭勇，王伏.电控系统下线管理与故障诊断功能开发［J］.汽车工程，2009，31(2):184－188.

HANG Yong，WANG Fu.The Development of End Line and Fault Diagnosis Functions for Electronic Control System［J］.Automotive Engineering，2009，31(2):184－188.

［4］盛宏伟.计算机网络密码技术［J］.重庆邮电大学学报:自然科学版，1992，4(1):53－55.

SHENG Hong－wei.The Password Technology of Computer Network［J］.Journal of Chongqing University of Posts and Telecommunications:Natural Science Edition，1992，4(1):53－55.

［5］International Standard Organization.ISO/DIS 14229－1.2 Road vehicles— Unified diagnostic services(UDS)—Part1:Specification and requirements［EB/OL］.(2005－03－12)［2010－12－20］.http://www.iso.org.

［6］International Standard Organization.ISO15765－3 Road vehicles— Diagnostics on Controller Area Networks(CAN)—Part 3:Implementation of unified diagnostic services(UDS on CAN)［EB/OL］.(2005－03－12)［2010－12－20］.http://www.iso.org.

(编辑:刘 勇)