基于ISO15765协议的车载电控单元应用程序刷新系统设计
2012-09-04李济泰
李济泰 杨 毅
(广州汽车集团股份有限公司)
1 前言
车载电控单元在汽车上的应用越来越多,功能也越来越复杂,因此,对车载电控单元应用程序的更新也越来越频繁。在现有车载电控单元应用程序更新方法中,大部分采用芯片厂商提供的程序烧写器进行更新,更新时需要拆卸车载电控单元,这对主机厂来说几乎是不可能的。考虑到目前车载电控单元大部分使用CAN通信,因此采用一种接入车载OBD接口,并通过CAN总线对车载电控单元的应用程序进行更新的刷新系统。这种刷新方式虽然要求电控单元应符合ISO15765定义的刷新规则,但无需拆卸电控单元,也无需考虑电控单元使用的芯片类型,尤其适用于主机厂。
2 车载电控单元应用程序刷新系统原理
基于ISO15765协议的车载电控单元应用程序刷新系统(下称刷新系统)原理如图1所示。该刷新系统由上位机和下位机组成。上位机用作人机界面,一方面执行操作人员的指令,另一方面显示刷新过程中必要的信息;下位机用作与车载电控单元通信的接口,一方面从上位机接收指令和数据,另一方面与车载电控单元进行通信,完成应用程序的刷新。上、下位机之间的通信采用RS232串口,上层通信协议自定义。下位机与车载电控单元的通信采用CAN总线,上层通信协议采用ISO15765协议。
车载电控单元若要能够刷新应用程序,必须包含应用程序和引导程序2个可执行的软件包。在ECU正常运行时,应用程序运行;在ECU进行程序刷新或应用程序失效时,则引导程序运行。应用程序和引导程序需要占据不同的FLASH空间,其中应用程序占据的空间可刷新,而引导程序占据的空间受保护不能刷新,这样可避免引导程序被误擦除而不能进行应用程序刷新的情况。RAM用来存储引导程序或应用程序运行时的临时变量,可被应用程序和引导程序共用。
3 刷新系统设计
3.1 上、下位机上层通信协议制定
上位机发送给下位机的报文称之为请求,下位机发送给上位机的报文称之为回复,所有的通信都必须由上位机发起,即先有请求后有回复。帧的长度最大为20个字节,如果报文过长则分成多个帧发送。在请求帧与回复帧之间的间隔及多帧传输中,上一个回复帧与下一个请求帧之间的间隔最长为500 ms,一旦超时则通信中断。
请求帧的定义如表1所列。帧类型包括单帧、首帧、末尾帧和连续帧。单帧表示其内容已经包含了整个报文的内容;首帧表示多帧传输中的第1帧;末尾帧表示多帧传输的最后一帧;连续帧则表示多帧传输中的中间帧。数据长度是指服务标识符和参数的总长度,该长度最大为17个字节,加上同步头、帧类型和数据长度这3个字节,整个帧的最大长度为20个字节。服务标识符表示该请求的功能,参数与服务标识符相对应。上位机传输应用程序给下位机时,服务标识符使用0x36,参数为应用程序具体数据。对于请求下位机刷新车载电控单元的应用程序,服务标识符使用0x31,参数包括命令类型、当前时间和目标ECU地址。命令类型包括开始刷新命令和在刷新过程中请求刷新进度的命令;当前时间用以保证刷新的可追溯性;目标ECU地址可指定当前要刷新的车载电控单元。
表1 请求帧定义
肯定回复的定义如表2所列。帧类型为请求帧类型取反;服务标识符为请求服务标识符取反;参数为执行请求的结果。
否定回复的定义如表3所列。服务标识符为请求服务标识符取反;否定码表示否定回复的原因。
表2 肯定回复定义
表3 否定回复定义
3.2 ISO15765协议的使用
下位机与车载ECU之间的通信遵循ISO15765协议,其中网络层的通信遵循ISO15765-2,应用层的通信遵循ISO15765-3。
ISO15765-2中定义了单帧传输和多帧传输[1]2种通信方式。在下位机与ECU的通信过程中,如果传输的有效数据少于8个,则采用单帧传输;如果传输的有效数据多于或等于8个,则采用多帧传输,依次使用到首帧、流控制帧和连续帧。
ISO15765-3中定义了刷新程序的流程及相关的诊断服务[2]。下位机刷新车载ECU时采用该流程,如图2所示。
首先,请求整个网络的节点进入扩展模式,然后关闭所有节点的故障设置以避免其它节点存储关于被刷新节点的故障,再禁止整个网络的非诊断的通信以节约刷新所用时间。
目前洋山港已建一、二、三期集装箱码头,岸线总长5 640 m,其中一期工程共布置5个5万~10万吨级泊位,二期工程布置4个7万~10万吨级泊位,三期工程布置7个7万~15万吨级泊位。经加固升级改造,洋山港二、三期码头现可靠泊20万吨级集装箱船舶。[1]
其次,请求被刷新节点进入刷新模式,由应用程序运行状态转换到引导程序运行状态,然后擦除原应用程序所占据的存储器空间,再请求传输程序传输数据到存储空间,并在数据传输完成后检查数据的一致性。
最后,请求整个网络的节点进入默认模式,使得被刷新节点重启,由引导程序运行状态转换到新应用程序运行状态,并使之前关闭的故障设置和非诊断通信重新开启,整个网络进入正常运行状态。
3.3 上位机软件设计
该上位机软件的开发平台为National Instrument提供的图形化虚拟仪器集成开发环境Lab-VIEW 8.5,它具备友好的编程环境及提供了许多实用的控件,给软件开发带来了极大的方便[3]。
该上位机功能分为2部分。一部分为传输应用程序文件给下位机,并显示传输进度;另一部分为请求下位机刷新车载电控单元的应用程序,并显示刷新进度。
传输应用程序文件的软件流程如图3所示。首先,初始化刷新人员所选择的串口,然后将刷新人员选取的应用程序文件的前16个字节读取出来,加上同步头、帧类型、数据长度和服务标识符形成请求帧通过串口发送出去。发送后从串口读取下位机的回复,收到肯定回复则计算出传输进度并显示,回复超时或否定回复则显示相应的报错信息并退出。如果文件没有发送完毕,则每次循环发送16个字节的数据,直到文件全部发送完毕为止。最后进行CRC校验,检测传输过程中是否出现了误传。
请求下位机刷新车载电控单元的应用程序软件流程如图4所示。首先,根据获取的系统时间、刷新人员所选择的ECU地址生成开始刷新的请求帧,并通过串口发送出去。发送后从串口读取下位机的回复,收到肯定回复则将回复中的进度信息提取出来并显示,回复超时或否定回复则显示相应的报错信息并退出。如果刷新没有100%完成,则循环发送刷新进度的请求,从下位机的回复中获得实时刷新进度并显示,直到刷新成功完成为止。
3.4 下位机硬件设计
微处理器模块的主要组成部分为Freescale公司生产的MC9S12XE100。该处理器是一款低成本、低功耗的16位单片机,它包含有64 K字节的RAM、1M字节的FLASH、8个串行通信接口、3个串行外围接口、2个16通道、12 bit的A/D转换器、1个8通道的脉宽调节模块和5个兼容CAN2.0A、B的CAN模块[4],可满足与上位机和车载电控单元之间的通信。
高速CAN通信模块的主要组成部分为NXP公司生产的TJA1040。该CAN收发器完全兼容ISO11898协议,支持最高1 Mbaud的通信速率,具有非常低的电磁辐射和非常高的抗电磁骚扰能力[5]。
低速CAN通信模块的主要组成部分为NXP公司生产的TJA1054。该低速容错CAN收发器支持最高125 Kbaud的通信速率。与TJA1040相似,该收发器同样具有非常低的电磁辐射和非常高的抗电磁骚扰能力[6]。
RS232通信模块的主要组成部分为DALLAS SEMICONDUCTOR公司生产的低功耗收发器DS276,该收发器完全兼容RS232信号[7]。
3.5 下位机软件设计
该下位机软件的开发平台为Freescale提供的一个面向S12(X)系列MCU的集成开发环境Code-Warrior 5.0,它不仅具有很友好的调试环境,而且提供了代码烧写工具,配合USBMULTILINK调试/编程器,给软件开发带来方便[8]。
该下位机功能可分为2部分。一部分为接收上位机传过来的应用程序文件;另一部分为刷新车载电控单元的应用程序,并上传刷新进度。
接收应用程序文件的软件流程如图6所示。首先,初始化单片机并循环监测串口是否收到上位机请求。一旦收到应用程序传输请求,则在请求中提取出16个字节的应用程序数据并存储。存储成功后向串口发送肯定回复;如存储未成功,则发送否定回复并退出。肯定回复后,根据请求的帧类型是否为末尾帧来判断文件传输是否完毕。如未完毕,则继续循环从串口中读取请求,并提取应用程序数据存储,直到文件传输完毕为止。在此过程中,如果出现无效请求或超时,则报错退出。文件接收完毕后,判断CRC校验是否正确。如果正确,置应用程序有效位,结束此次文件传输;如果错误,则表示此次传输失败,退出。
刷新应用程序的软件流程如图7所示。首先,循环监测串口是否收到上位机请求。一旦收到应用程序刷新请求,则在CAN上发送进入扩展模式的诊断请求,与ECU建立诊断通信。如果ECU肯定回复,则在串口回复上位机开始刷新成功;如果ECU否定回复,则在串口上回复CAN通信失败并退出。回复上位机开始刷新成功后,下位机按照ISO15765-3定义的刷新流程,通过CAN对ECU进行程序刷新,包括关闭故障设置、禁止非诊断通信、进入刷新模式、擦除ECU FLASH里的应用程序代码空间、请求传输新的应用程序数据和传输程序数据。在传输程序数据的过程中,循环接收上位机周期性发送过来的询问软件刷新进度的请求,并根据传输数据的进度进行实时回复,便于上位机更新进度条信息。程序数据传输完毕后,继续进行ISO15765-3定义的传输数据检查和进入默认模式。此2步顺利完成后,则应用程序的刷新完成。
4 试验结果
该刷新系统经过实车测试完全能够成功刷新符合ISO15765协议的车载电控单元,上位机刷新界面如图8所示。
具体操作流程如下:首先在设置中选择串口号、待刷新ECU的名称和待更新的应用程序二进制文件,并在命令下拉菜单中选择传输应用程序的命令,然后点击开始;这时,应用程序由上位机传向下位机,进度条实时显示传输的进度;应用程序传输完毕后,在命令下拉菜单中选择刷新应用程序的命令,并点击开始;此时下位机更新ECU的应用程序,进度条实时显示程序更新的进度,直到更新完毕。如果在上述过程中出现错误,则显示有错误的文字信息。
5 结束语
设计了基于ISO15765协议的车载电控单元应用程序的刷新系统,并采用了上、下位机的方式,其中上位机用作人机界面,下位机用作上位机和车载电控单元之间的通信接口。经测试,该系统可成功刷新符合ISO15765协议的车载电控单元的应用程序。目前,正在研究将上、下位机的通信由RS232通信改为USB通信,这样可加快刷新速度。另外,该系统作为一个CAN通信节点,在汽车电子的其它领域也有广泛的应用前景。
1 ISO15765-2.Road vehicles—Diagnostics on Controller Area Networks(CAN)—Part 2:Network layer services.International Organization for Standardization,2004.
2 ISO15765-3.Road vehicles—Diagnostics on Controller Area Networks(CAN)—Part 3:Implementation of unified diagnostic services (UDS on CAN).International Organization for Standardization,2004.
3 杨乐平,李海涛,等.LabVIEW高级程序设计.北京:清华大学出版社,2003.
4 Freescale Semiconductor.MC9S12XEP100 Reference Manual Covers MC9S12XE Family.Rev.1.222010.
5 Philips Semiconductors.TJA1040 High speed CAN transceiver data sheet.2003.
6 NXP Semiconductors.TJA1054 Fault-tolerant CAN transceiver data sheet.2010.
7 DALLAS SEMICONDUCTOR.DS276 Low Power Transceiver Chip.1999.
8 邵贝贝,宫辉,等.嵌入式系统中的双核技术.北京:北京航空航天大学出版社,2008.