基于K总线的汽车静态测试仪高效调试

王明非，鲁统利，王天军

（1.上海交通大学 汽车工程研究院，上海 200240；2.上海通用汽车有限公司，上海 201201）

汽车静态测试是利用测试仪通过OBDII接口与汽车电子控制单元（Electronic Control Unit，ECU）的诊断系统进行交互式通讯，从而获取汽车各个控制单元的状态数据和故障信息。在此过程中，测试仪可以控制汽车各部件的工作和设定其运行状态。此外，测试仪还具有元件测试、读取数据流、匹配标定、代码升级等功能。汽车静态测试[1]是对实车进行离线测试，是对汽车动态测试[2]的简化。目前其测试仪程序的调试工作也都是在实车上进行的。

KWP2000诊断协议是由国际标准化组织下的车载电气电子设备分委员会制定的，是目前相对比较完善，被广泛应用的一种诊断协议[1]。

现在世界上各大汽车制造商，在总装线终端检测时都要使用测试仪对汽车进行静态测试和动态测试。而测试仪程序的调试工作却是在实车上进行。这种调试方法存在以下几个缺陷：（1）汽车运行达到期望状态所用时间长。（2）故障码设置不方便，甚至有时为了获得故障码，需在实车上设置实际的物理故障。（3）需要大量的车辆和人员的参与。在生产实际中以上几个缺陷使汽车测试仪的测试程序调试过程十分繁琐且成本高。

为解决生产实际中测试仪调试存在的这些问题，基于上述背景，本文通过对KWP2000通信协议和汽车静态测试通信数据的研究，融合汽车诊断技术和计算机仿真技术，开发了一套汽车静态测试仪程序调试系统（以下简称“调试系统”），率先实现了测试仪与汽车K总线通信数据模拟，使测试程序调试的效率大大提高，具有较高的实用价值和实际意义。

1 原理分析

1.1 调试系统功能

在调试过程中，测试系统向调试系统发送请求消息，调试系统根据请求消息（输入）解析出响应消息（输出）反馈给测试系统，并按照请求消息对数据库中的数据进行动态修改；调试系统使用者在软件界面上操作，对调试系统发送控制消息，调试系统根据使用者的控制输入改变程序数据库中的数据，实现对驾驶员操作和故障码生成的模拟。调试系统原理图如图1所示。

1.2 KWP2000分析

KWP2000根据开放系统互连（Open Systems Interconnection，OSI）的7层基本参考模型，从整体结构上将通信系统分为3层：（1）应用层（第7层，由ISO14230-3描述）。（2）数据链路层（第2层，由ISO14230-2描述）。（3）物理层（第1层，由ISO14230-1描述）。

以某采用KWP2000通信的车型为研究对象，该车通信协议规定的报文结构格式见表1[3]。可以按照协议规定解析请求消息并给出符合报文结构规定的响应消息。

表1 KWP2000报文结构

1.3 调试原理

在分析KWP2000规定的数据结构的基础上，利用英特佩斯电子控制系统公司的NeoVI FIRE通信硬件[4]和PC机（含USB接口）组成通信调试系统，可实现KWP2000协议通信的物理层和数据链路层。在应用层上设计软件系统实现逻辑判断和运算功能，就能实现汽车ECU的测试通信模拟。其中，整个系统开发的工作重点是软件系统设计，即建立软件模型与逻辑实现。软件设计的重点是在逻辑上实现按照协议解析请求消息和控制消息，即解析模块设计。

依据NeoVI FIRE的数据结构和应用函数[4]设计了：（1）通信接口模块，实现了搭载报文消息的结构体数组的收发。（2）解析模块流程的第1、2、5、6步，实现报文消息与结构体数组格式转换收发。

按照该车型的KWP2000协议规定[3]和调试系统功能分析设计了：（1）解析模块流程的3、4步，实现请求和控制消息解析与响应。（2）数据库模块，模拟汽车ECU数据。（3）系统主体，调用各模块功能以实现主功能。

按照调试过程中的具体操作需要，设计了设置、显示等模块。

2 硬件组成设计

采用NeoVI FIRE通信硬件[4]做二次开发，搭建调试系统物理通信线路。硬件系统组成和连接如图2所示。

3 软件设计与开发

3.1 软件系统结构设计

整个软件系统的开发采用VC++/ MFC平台。软件系统功能由模块化设计实现——对话框模块、接口模块、解析模块、数据库以及系统主体；对话框模块分设置、显示、控制分模块。设置模块具有设置数据库的功能；接口模块实现NeoVI FIRE结构体数组的收发功能；控制模块可从用户界面接收控制指令并通过系统主体传递给解析模块，实现数据库数据修改；解析模块从结构体数组中识别出请求消息，解析请求消息和控制命令，给出符合NeoVI FIRE结构体数组格式的响应消息，并按照请求消息、控制消息修改数据库数据；显示模块可以实现通信数据的实时显示和动画模拟。其中对话框模块、接口模块和解析模块通过动态连接库编程实现；系统主体调用各模块动态连接库的导出函数调用该模块的功能；由于ECU数据占用PC机空间很小，采用程序运行时的内存即可实现数据库功能。调试系统软件结构和数据流示意图如图3所示。

3.2 接口模块设计

使用NeoVI FIRE通信硬件提供给用户的应用函数可调用通信硬件的功能，实现通信接口的打开、关闭和搭载报文的结构体的接收、发送。接口模块流程图如图4所示。

3.3 解析模块设计

解析模块的功能是根据协议解析请求命令和控制命令，通过运算得出响应消息，再将响应消息封装在结构体数组中发送给系统主体，并修改数据库数据。这些过程模拟了汽车ECU数据的调用和改变，从而实现对实车K总线通信数据的模拟。

请求命令解析过程如图5所示，解析模块从系统读取结构体数组，并从中解析出请求消息的头和数据（第1、2步）。然后根据请求消息的数据运算出响应消息的数据，根据请求消息的头和响应消息数据运算出响应消息的头（第3、4步）。最后设置封装响应消息的结构体数组并发送给系统主体。

其中第3步，根据请求消息中的ECU、 SID(Service Identification，服务号)以及其它数据信息解析出响应消息数据的过程，是实现汽车诊断通信数据模拟的关键。根据SID的不同（汽车静态测试中常用的SID共计17种），调试系统对请求消息的响应动作大致可分为4大类。

（1)直接一次响应。按照协议要求和测试仪的测试通过期望值，对以下服务号：SID=10（开启诊断会话）/ 11（ECU重设）/ 2C（动态定义本地标识符）/ 31（本地标识符开启程序）/ 3E（测试仪参与）/ 81（开启通信）/ 82（结束通信），调试系统只需给测试仪发送1条正响应消息。按照协议规定，测试仪收到这条响应消息就会认为本次请求测试通过。例如，某请求消息中SID=81，表示测试仪请求开启与汽车ECU的通信，这时调试系统只需在响应消息中给出正响应标识符C1，测试仪就会认为其与汽车ECU的通信已经开启，下一步就可以发出其它服务的请求。

（2）数据库一次响应。以下服务号：SID=13（读诊断故障码）/ 18（根据状态读诊断故障码）/ 19（根据状态读诊断故障码状态）/ 1A（读ECU身份）/ 21（根据本地标识符读状态）/ 22（根据公共标识符读状态）/ 27（安全进入），是测试仪在请求获得汽车ECU数据。测试仪发出这个请求后不仅期望得到正响应标识符，还需要得到期望的数据，这类数据包括ECU身份（汽车VIN号）、故障码、汽车各单元状态（如发动机转速、油温、元件电压，自动变速器挡位、安全气囊状态等），安全进入种子数据等等。对包含这些服务号的请求，调试系统要对其做出正响应并在数据库中检索测试仪需要的数据，然后将正响应标识符和检索到的数据组合成响应消息并发给测试仪。测试仪收到这样的响应消息后，会认为是汽车ECU发送了这些数据，根据这些数据获知并分析汽车各单元的状态或故障信息。如果有异常状态或故障码，测试仪界面就显示测试失败。数据库数值的格式和数值精度要靠系统使用者人工设定。例如，某请求消息中SID=21，要求读取PID=01（某车发动机全部状态数据）的状态（见数据库设计），则调试系统将数据库中的相应数据打包成响应消息，反馈给测试仪。测试仪收到这些数据就会进行判断所读取的元件状态是否满足测试要求，若满足测试要求则可进行接下来的测试项目。又如SID=18，测试仪期望读取ECU的故障码，则调试系统将数据库中设置的故障码发给测试仪，测试仪收到故障码后，会在界面上显示故障，并在最终的测试报告中记录这个故障。

（3）直接一次响应+数据库操作。符合这种情形的服务是SID=14（清除诊断信息）/ 3B（根据本地标识符写数据）。测试仪不仅能从汽车ECU读数据，还可以向ECU写数据，比如汽车VIN码（17位数字或字母，相当于汽车“身份证号”，俗称车辆17位码，每辆车的VIN码是唯一的）。如果通过请求得到的VIN号是“错误”的（与测试仪测试程序中设定VIN号不一致），则会为汽车ECU写一个的“正确”的VIN号（测试仪设定值）。在模拟测试中，调试系统要能模拟错误的VIN码被测试仪改正的过程。第1步，调试系统储存在数据库中的VIN码是错误的；第2步，测试仪发出请求得到错误的VIN号，并识别了错误 ；第3步，测试仪会发送SID=3B的请求，给ECU写一个正确的VIN号；第4步，调试系统根据测试仪的请求消息将“正确”的VIN码写入数据库中的相应位置；第5步，测试仪再次发出读取VIN号的请求；第6步，调试系统将写“正确”了的VIN号发给测试仪。到此，测试仪判断汽车VIN码正确，从而可以进入接下来的测试内容。

（4)数据库一次响应+数据库操作。对于SID=30（根据本地标识符输入输出流控制），系统要解析请求消息，根据数据库数据给出响应；并根据请求消息的内容和预先设定的数据库向导数据修改数据库目标数据。例如，某车测试中请求消息为84 11 F1 30 24 07 96 77，调试系统对其进行解析可知ECU为11（发动机），SID=30（流控制）控制项目为24（怠速控制），控制方式为07（短期调整），控制数值为96（按协议换算后为1 500 r/min），校验码77正确，则下一步就根据数据库中的向导数据IOControlTarget_24 07 96=PID_01将发动机的转速数值（表2中PID_01等号后面的值第29、30字节）改为1 500 r/min [把0B B8（表示750 r/min[3])改为1 770（表示1 500 r/min[3]）]；并从数据库中找到该请求消息的正响应消息84 F1 11 70 24 07 96 B7发给测试系统，表示发动机转速已经调整至测试仪要求的1 500 r/min ；随后测试仪再次发出请求消息读取发动机ECU的状态数据；调试系统再次给出发动机状态数据响应，测试仪就会读到发动机转速为17 70（1 500 r/min[3]），则该项测试通过，可进入下一项测试。

除了对请求输入进行解析之外，调试系统还可以通过解析控制输入对数据库中的所有数据进行设定和修改。这样就可以实现对各个单元的身份数据、状态数据、故障码等数据内容进行人为设置，验证测试程序读状态数据和故障码的功能，即测试程序调试。控制命令解析过程如图6所示。

3.4 数据库设计

数据库的功能可利用Windows的应用程序初始化功能和PC机内存实现。利用Windows应用程序初始化功能需编写ini格式文件，并在软件程序中使用Windows 应用函数（API）对ini文件进行读写操作。

ini文件是windows的系统配置文件，统管Windows的各项配置，这里可以利用其为调试系统程序的内存数据初始化，实现虚拟数据库的作用。Windows应用程序初始化文件（ini文件）由节、键、值组成，其数据格式如下[5]：

对象车型某ECU的ini格式模拟内存数据见表2。

在仿真开始时，将ECU数据按照ini文件的格式初始化到程序内存中。调试过程中，系统读到请求消息，解析请求消息的ECU、SID等信息，根据解析到的关键字检索数据库（内存数据）中的键，然后读取对应的值，根据读到的值生成响应消息。

4 实际应用结果与分析

4.1 调试系统应用

通过功能测试和可靠性测试后，调试系统应用于上海通用汽车整车制造总装终检线的汽车静态测试程序调试中。图7为调试系统实物图；图8为调试系统软件界面图。

4.2 应用结果与分析

状态数据模拟方面，调试系统的ECU状态数据可以通过人工快速设定，达到并精确地稳定在测试要求的理想值，如发动机转速无误差地稳定在750 r/min 、1 500 r/min 等数值上。利用这一点可以快速精确地标定和验证测试仪程序的参数。图7和图9为调试系统通过某次测试时的实物图和测试仪界面。图7显示发动机转速可人为精确达到并稳定在1 500 r/min 。图10为在另一次模拟测试中发动机转速精确地达到并稳定在2 000 r/min 。

故障码设置方面，调试系统可以轻易设置在实车上不易设置的各种故障。利用这一点可以检验测试仪能否及时、正确地读取并识别故障。图10为测试仪读到用调试系统人为设置的故障码时，显示故障信息的界面。

从实际应用结果可以看出：（1）调试系统可快速地模拟设置汽车各种状态数据（实车达到期望状态时间长）。（2）调试系统可全面设置汽车静态测试中各种故障码（有些故障在实车上难以设置）。（3）调试系统使测试程序调试减少对实车环境的依赖。

5 结论

针对生产中K总线汽车静态测试程序采用实车调试存在的缺陷，提出了一种模拟实车总线通信的测试仪高效调试方法，并开发了汽车静态测试仪调试系统。调试系统与实车相比，状态数据设置快速、精确，故障码设置快速、全面，并且减少对实车和场地的依赖。这种模拟通信的调试方法比实车调试速度快、功能强、成本低，弥补了后者的不足，大大提高了汽车静态测试程序调试的效率。

在实践中，该调试系统已广泛应用于上海通用汽车整车制造终检线静态测试程序的调试，在最新几款车型中该系统均得到高度利用，节省了大量人力、物力、时间成本，大大提高了测试程序的调试效率和可靠性。

该调试系统为日后下一代汽车测试系统和诊断系统的开发提供了方便。该调试方法是基于K总线汽车静态测试进行的研究，其成果为其它总线和协议的测试仪调试提供了参考。进一步探索，由于汽车动态测试的车载ECU诊断通信模式与汽车静态测试基本相同，同时转鼓试验台工控机的串口通信也可以采用类似方法进行模拟，因此本文的工作为将来实现汽车动态测试系统（测试仪+汽车+转鼓）的测试仪高效调试打下了重要基础。

[1]吕奕晔.汽车诊断协议KWP2000的实现与应用[D].哈尔滨：哈尔滨工业大学，2007.Lü Yiye. The Implementation and Application of Vehicle Diagnostic Protocol 2000 [D]. Harbin： Harbin Institute of Technology，2007. (in Chinese)

[2]孙永佳，张睿.汽车动态测试—DVT [J].沈阳航空工业学院学报，2004，21(2)： 34-36.Sun Yongjia，Zhang Rui. Vehicle Dynamic Test— the DVT[J]. Journal of Shenyang Institute of Aeronautical Engineering，2004，21(2)： 34-36. (in Chinese)

[3]Keyword Protocol 2000 Implementation of Diagnostic Services Recommended Practice[S]. [S.l.]：United Automotive Electronic Systems Co. Ltd，2007.

[5]Intrepid Control Systems. Intrepidcs API Documentation[EB/OL]. http：//intrepidcs.com/support/ICS Documentation/neo VI DLL/neo Frame Main. htm，2008-11-11.

[6]宋坤，刘锐宁，李伟明.MFC程序开发参考大全[M].北京：人民邮电出版社，2007.Song Kun，Liu Ruining，Li Weiming. MFC Application Development Reference Books [M]. Beijing：The People's Posts and Telecommunications Press，2007. (in Chinese)