基于CANoe的汽车诊断工具开发及应用

龚存昊，段金亮，初洪超（安徽江淮汽车股份有限公司，安徽 合肥　230601）



基于CANoe的汽车诊断工具开发及应用

龚存昊，段金亮，初洪超
（安徽江淮汽车股份有限公司，安徽 合肥230601）

摘要：近年来随着汽车行业的迅速发展，各系统电控单元在汽车上的应用日益广泛，汽车整体性能得到了显著的提升，进而导致传统的汽车诊断方式已经无法满足其功能要求。本文以CAN总线诊断协议为基础，设计一种基于CANoe开发环境工具制作的汽车诊断测试工具。该工具不但可以对CAN总线上的ECU模块进行诊断测试，同时也为测试人员能够快速准确地确认ECU模块的故障原因提供了一种新的途径，对汽车行业具有良好的应用前景和非常现实的意义。

关键词：CANoe；ECU；诊断协议；测试

随着人们对汽车动力性、舒适性等要求的不断提高，信息技术和网络技术在汽车行业中得到了迅速的发展。越来越多的电控单元、功能不同的传感器和对应的执行机构在汽车中得到了广泛应用，汽车产品完成了由传统的机械产品上升到一个具有多种功能的移动多媒体平台的过程［1］。

在汽车电子技术不断发展的同时，汽车总线技术作为一种计算机网络技术和工业现场总线控制技术的结合，成为现代汽车发展过程中的主要技术成果之一。它的出现不仅使传统线束得到了精简，电控单元的功能得到了细化，而且使得汽车可以搭载越来越多的ECU模块，如TCU、BCM、EMS、ESC等，使得整车网络的功能日益复杂化。与此同时，在汽车正常的使用过程中，其车况随着行驶距离的增加而不断地发生变化，其可靠性、动力性、安全性也会不断地下降，故障率显著提升，对车辆的安全行驶造成了很大的隐患，甚至会直接导致事故的发生［2］。因此，对于测试人员而言，能通过既定的诊断协议完成汽车诊断服务功能测试，与此同时能及时和准确地诊断出汽车存在的当前故障，并对其发生的原因进行合理地排查，成为现代汽车诊断技术的一项重要内容。

1　CAN总线诊断协议

1.1汽车在线诊断发展概述

车辆诊断测试系统的研究和开发最早起于20世纪70年代，在研发设计汽车诊断测试工具的过程中，研究人员逐渐认识到汽车诊断工具的重要性。在1985年美国加州为第1代的OBD-I（On-Board Diagnostics）立法并在3年后正式开始实施，该诊断系统主要面向于零部件包括氧传感器、废气再循环阀、供油系统和发动机控制系统，但是缺乏统一的故障码和通信协议标准。随后在1989年加州环保局为第2代的OBD-II（On-Board Diagnostics）立法，增加了对系统的诊断要求，如催化器失效、灭火、蒸汽泄漏等，并且建立了标准化的故障码和通信协议标准。从2001年1月1月起，在欧洲等发达地区销售的汽油发动机汽车都必须装备在线监测发动机排放的在线诊断系统，并在2004年起，所有生产的柴油发动机汽车亦必须装备OBD系统［3-5］。

1.2汽车诊断协议

在乘用车早期的发展过程中，汽车诊断主要通过K线进行实现，国际标准化组织先后颁布了基于K线的ISO 9141和ISO 14230诊断协议。ISO 9141主要定义了整车物理层、数据链路层和应用层，其中ISO 9141-2定义了OBD（车载诊断）。ISO 14230则定义了协议的总体框架，不同的供应商可以根据自己的需要对协议本身进行完善修订，设置具体的服务内容和故障代码。测试人员只有获得供应商所制定的具体协议内容后，才能从诊断设备中获得准确的诊断信息，参照表1。

表1　基于K线各个层的诊断协议

随着汽车总线技术的日益发展，CAN总线技术已经在不同的主机厂中得到了广泛的应用，成为目前汽车最常用的总线技术之一。为了降低诊断系统的成本，解决CAN总线和诊断系统能相互融合等问题，国际标准化组织在21世纪初先后颁布了基于CAN总线的ISO 15765和ISO 14229-1通信诊断协议。对比K线的通信诊断协议，ISO 15765和ISO 14229-1协议整合并兼容了大部分主流的汽车厂商所定义的诊断标准规范，包括测试、检查、诊断、通信管理等功能，参照表2。

表2　基于CAN总线各个层的诊断协议

ISO 14229-1协议在应用层中各个功能单元诊断服务主要包括：诊断和通信管理功能单元、数据传输功能单元、传输存储的数据功能单元、输入输出控制功能单元和远程激活例程功能单元。在此过程中，参照图1所示，该协议要求客户 （Tester）和服务器（ECU）必须有统一的编址且每一个客户 （Tester）和服务器 （ECU）的地址需是唯一的。

图1　ISO 14229-1应用层远程诊断服务

在图2中，客户端 （Client）首先需向服务器应用层 （Server）发出诊断请求指令，当服务器应用层（Server）收到该请求指令后，会根据具体的情况向客户端 （Client）发出相应的肯定或者否定响应，此时客户端 （Client）需要对回复的结果进行对应的确认接收工作，从而完成一套完整的确认服务工作。这些服务说明并没有指定具体的应用程序接口，而只是一些独立于具体实施的主要服务项。

图2　ISO 14229-1应用层诊断确认服务

ISO15765协议最初是依据于ISO/IEC7498和ISO/ IEC 10731协议的开放互联系统基本参考模型所提出和设立的，并再映射到CAN总线通信系统。其中ISO 15765-2协议主要定义了CAN总线车载诊断系统网络层的要求，网络层的内部操作为实现对等实体间的通信提供了分组、重组和数据传输流控制方法，其主要任务是传递一帧或者大于一帧的数据信息。当数据内容超过一帧时，会根据协议将其内容划分成多个部分，再将每一个部分通过一个CAN总线标准帧的形式进行发送，通过对多包数据的打包、解包、同步、定时、流控制等操作，保证数据能够可靠地从客户端（Server）传递给客户 （Client）。

在图3中，网络层发送方A需要将多帧数据传输给接收方B，由于其发送方所传输的数据长度大于一帧，无法使用单帧数据传输方式，所以首先需要将其发送的数据内容解包成首帧 （FirstFrame）和多帧连续帧（ConsecutiveFrame）。当网络层发送方A成功发送出首帧后，此时接收方B需要回复相应的流控制帧（FlowControl），当发送方A确认接收到流控制帧后，会根据其内容发送对应的连续帧。若此时还未将数据内容全部发送完，则需要重复流控制帧和连续帧的动作，直至发送方将所有的数据内容全部发送完毕。

基于CAN总线网络层诊断的ISO 15765-2协议和早期乘用车基于K线诊断的ISO 14230协议相比，具有更快的信号传输速度和更大的数据传输长度，并且CAN总线具有完善的通信错误诊断处理机制和总线仲裁机制，这对于底层通信错误及仲裁处理具有重要的意义。

图3　ISO 15765-2网络层多帧数据传输方式

2　诊断工具开发

本文所设计开发的CAN总线诊断工具是基于德国Vector公司研发的总线开发环境工具CANoe，该软件主要用于汽车总线的开发设计。CANoe前期针对于CAN总线通信网络进行建模、仿真、测试和开发，后来扩展加入了LIN、Flexray、Most等网络。此外，其具备测试和诊断功能集，可以用来简化或自动进行测试。使用该功能，可以进行一系列的连续测试和诊断通信，并自动生成测试报告。

2.1诊断工具总体设计

本文研究的对象是某款搭载四路CAN总线的车型，首先运行CANoe软件，在Simulation Setup界面中添加信号数据库 （.DBC文件）和环境变量数据库 （. DBC文件），将整车各路CAN总线所搭载的ECU模块与数据库中的信息相链接，并设置网络数据传输的速率，从而建立一个完整模拟的网络系统测试模型。如图4所示。

图4CAN总线测试模型

图5　CAN总线诊断开发工具控制显示面板

其次利用Panel Editor界面建立和制作一个图形化的状态显示和控制面板，用户可以通过该人机对话的控制和状态显示面板，实时显示或者更改环境变量中的值。在图5中，通过每一个显示或者控制单元与之前添加的环境变量数据库中的环境变量或者信号相匹配，作为其显示或者控制对象。

最后在诊断工具开发过程中，编写相应的显示面板控制程序。考虑到CAPL语言是一种类似于C语言的CAN总线编程语言且与CANoe完美兼容，因此利用CAPL语言可以对各个ECU模块的诊断策略进行编程和控制，以实现各个ECU模块之间的通信和控制功能。CAPL语言由全局变量、自定义函数和事件过程组合而成，并且可以在CAPL浏览器 （CAPL Brower）中进行程序的编辑、调试工作。CAPL控制程序如图6所示。

图6 诊断工具CAPL语言

2.2诊断测试与结果分析

通过USB接口线、串口线将车辆的OBD接口和CANcaseXL总线接口卡相连接，启动CANoe测试环境，运行CAN总线测试工具进行在线诊断测试。通过CANoe中的Trace界面便可以实时跟踪总线上ECU模块的报文信息。

根据CAN总线诊断协议ISO14229-1和ISO15765-2，参见图7所示，在ECU模块诊断测试的开始，需要在诊断界面中选择被测ECU模块的名称并设置其相应的会话模式。在获得会话模式请求的肯定响应之后，就可以根据ISO14229-1协议中不同的SID（Service Identifier）和DID（Data Identifier）进行CAN总线应用层诊断测试。

图7ECU模块诊断会话控制

在图8中，利用诊断测试工具读取TCU当前的故障信息，根据ISO1575-2协议，由于当前故障信息较多且无法通过单帧将其全部列出时，则需要测试人员通过该诊断工具的流控制帧策略对故障信息进行控制，使TCU将当前故障信息通过首帧和连续帧的方式将其全部传输给测试人员。测试人员可根据每个主机厂定义的OBDII故障代码表对读取到的故障信息进行编译，进而分析当前ECU模块发生故障的具体原因。

在ECU模块诊断测试过程中，由于供应商和主机厂之间的协议，ECU模块的写入和某些读取功能需要在安全访问通过后方可进行。ECU模块安全访问请求必须要在扩展模式 （Extended Session）下进行。测试人员首先需要向ECU模块请求种子 （Seed），再根据ECU模块发送的种子 （Seed）解析并发送出相应的钥匙 （Key），若此钥匙 （Key）正确，则ECU模块解锁，安全访问通过。在图9中，依据上述的安全访问步骤，可以对TCU单元解锁，使测试人员可以对其进行安全访问。

图8ECU模型当前故障信息

图9　ECU模块安全访问功能

3　总结

本文详细介绍了CAN总线诊断协议，并依据该协议设计和建立了一种针对于CAN总线的诊断测试开发工具，且通过具体的实车环境对该诊断工具的功能性和合理性进行了验证。利用该诊断工具，可以使测试人员能够更加直观方便地对CAN总线上的ECU模块进行诊断测试和读取故障信息，对汽车电气测试有着非常现实的意义。

参考文献：

［1］贺永玲.基于CAN总线的电动汽车故障诊断系统研究［D］.广东：广东工业大学.2009.

［2］周涛.基于ISO15765协议的研究与实现 ［D］.合肥：合肥工业大学.2011.

［3］麦克斯.汽车第二代车载诊断系统详解［M］.北京：北京机械工业出版社，2007.

［4］丁志华，罗峰，孙泽昌.基于CANoe的汽车故障诊断系统研制［J］.汽车工程，2007，29（5）：449-452.

［5］张宏，詹德凯，林长加.基于CAN总线的汽车故障诊断系统研究与设计［J］.汽车工程，2008，10（30）：934-937.

（编辑杨景）

中图分类号：U463.6

文献标识码：A

文章编号：1003－8639（2016）05－0059－04

收稿日期：2016-02-20

作者简介：龚存昊 （1990-），男，硕士，电器设计工程师。

CAN Bus Diagnostic Tool Development and Application Based On CANoe

GONG Cun-hao，DUAN Jin-liang，CHU Hong-chao
（Anhui Jianghuai Automobile Co.，Ltd.，Hefei 230601，China）

Abstract：With the rapid development of the automobile industry，the application of ECU module and the performance of the vehicle is increasing.But problems also follows as the traditional vehicle diagnosis method cannot fetch with the function requirement.This paper designs a diagnostic test tool based on CANoe，in accordance with the CAN-bus diagnostic protocol.The tool can not only conduct diagnostic test on ECU module of CAN，but also provide the new way for testers to find ECU module fault reasons quickly.It has a good application prospect and realistic significance for the automotive industry.

Key words：CANoe；ECU；diagnostic protocol；test