论文部分内容阅读
摘 要：针对传统PC式汽车故障诊断系统的不足，本文提出了一种标准化的PC式汽车故障诊断系统，由标准诊断接口设备和诊断应用软件组成，硬件选用满足SAE J2534标准的MDI诊断工具，研究了MDI通信机制和SAE J2534标准内容，优化了系统数据读取速率，采用架构层次化、功能模块化的思路，开发了诊断应用软件。经实车测试及分析，系统可实现对整车电控系统的故障诊断、维修帮助、实时监控和在线刷新，具有良好的通用性和扩展性，对应用标准设备开发具有借鉴意义，为车辆诊断维修提供了有利工具。
关键词：车载诊断系统；汽车故障诊断；多功能诊断通信接口；SAE J2534
中图分类号：U472.9 文献标识码：A 文章编号：1005-2550（2015）03-0017-06
Abstract： For the deficiencies of traditional PC-based vehicle fault diagnostic system， this paper proposes a kind of standardized PC-based vehicle fault diagnostic system which by the standardized diagnostic interface device and diagnostic application software， selects the MDI diagnostic device which conformed to SAE J2534 standard， studies the communication mechanism of MDI and SAE J2534 standard content， optimizes the data read rate， develops the diagnostic application software using the ideas of hierarchical architecture and function modularization. Through vehicle testing and analysis， this system allows the fault diagnosis， maintenance help， real-time monitoring and online refresh for vehicle electronic control system， has a good versatility and scalability， has a reference for developing standardized diagnostic device and provides the favorable tools for Vehicle Diagnosis and Maintenance.
Key Words： On-Broad Diagnostic System； Vehicle Fault Detection； Multiple Diagnostic Interface； SAE J2534
前言
PC式汽车故障诊断系统因为在实时监控、集成处理、功能扩展、远程诊断等方面的优势，替代手持式诊断设备成为目前汽车诊断的主流选择[1]。
然而，不同厂商支持的诊断总线类型、诊断引脚定义和诊断通信协议不尽相同，为满足各大汽车厂商车辆内部日益增多的ECU（Electronic Control Unit）诊断任务的要求[2]。因此，笔者提出一种基于MDI（Multiple Diagnostic Interface）的PC式汽车故障诊断系统。
1 系统方案
系统由标准诊断接口设备（MDI诊断工具）和故障诊断软件两部分组成。系统的构架如图1所示。
标准诊断接口设备通过车辆的OBD（On-Broad Diagnosis）接口接入车载网络，其主要负责笔记本电脑和车辆之间不同数据帧的封装和信号的转换。
故障诊断软件安装在笔记本电脑上，通过USB线与标准诊断接口设备连接，其主要负责向车辆ECU发送请求指令，处理应答数据；同时笔记本电脑还可以通过互联网访问服务器数据库，完成数据的上传下载。
2 系统硬件
该系统采用笔记本电脑和标准诊断接口设备的硬件组合。标准诊断接口设备选用通用汽车公司的MDI诊断工具。
MDI诊断工具遵循SAE J2534标准，SAE J2534是用于车辆ECU编程刷新的软硬件标准。通过满足SAE J2534标准的接口设备不仅可以实现笔记本电脑和ECU的数据通信，也可以对ECU进行重新编程[3]。同时MDI支持多种主流的车载通信协议，包括KWP2000、CAN总线（ID为11位的标准帧）、CLASS2、UART等[4]。另外，MDI充分的兼容了ISO 22900-1、ISO 22900-2、ISO 22900-3的标准，实现了新兴MVCI（Modular Vehicle Communication Interface）软件构架，具有良好的扩展性。
3 系统通信机制研究
MDI是基于SAE J2534标准设计的诊断工具。其数据处理、链路控制和流程控制是由MDI下位机软件和SAE J2534规定的标准接口函数共同完成。表1所示为SAE J2534定义的标准接口函数[5]。
3.1通信过程建立
目前车辆上的电控模块绝大多数选用K线或CAN总线通信协议，因此汽车故障诊断系统主要针对K线和CAN总线通信协议进行开发，同时保留其他通信协议的接口，易于今后扩展。图2为调用标准接口函数实现通信过程的流程。 a. 与MDI建立连接：连接成功将返回设备ID。
b. 设置通信协议ID和相应波特率：其中K线的协议ID设置为0x04，波特率设置为10 400kbps； CAN总线的协议ID设置为0x06，波特率设置为 50 000kbps。设置成功将返回通道ID。
c. 过滤设置：对于K线，超过一定时间没有数据交互，则会自动断开通信。因此需要每3s循环发送测试在线指令“3E”，以保持K线通信在线，同时过滤掉ECU正反馈指令“7E”，避免上位机对反馈数据的频繁操作，节约资源；对于CAN总线，总线上传输着大量数据，通过CANID的过滤，筛选出需要的数据给上位机。
d. 通信初始化：对于K线的ECU，在开始通信之前还需要对其进行初始化。这里选择快速初始化方式，对应接口函数PassThruIoctl的参数loctlID为0x05。
e. 数据收发：在上述设置成功后，便可直接调用PassThruWriteMsgs和PassThruReadMsgs进行数据的收发。
f. 与MDI断开连接：在结束诊断后，需要断开指定协议的通信通道以及与MDI的连接，释放资源。
3.2 通信机制优化
基于KWP2000协议的诊断服务必须遵循一定的时序来进行，ISO 14230-2给出了诊断服务请求响应过程的时序图以及时序参数P1、P2、P3、P4的严格规定[6]。
P1、P2、P3、P4以及诊断系统的通信机制是影响数据读取实时性的主要因素。协议已经对P1、P2、P3、P4有着严格的规定，因此优化诊断系统的通信机制是提高读取数据实时性的唯一途径。
不同的诊断服务对通信过程的实时性要求也不同。对于读取故障码，清除故障码，读取冻结帧，动作测试和读取模块信息这些服务，完成诊断服务只需要一次请求应答，对实时性的要求不高；而对于读数据流服务，需要短时间内连续的请求应答。一次请求应答的时间越短，每次请求时间间隔越小，车辆和发动机运行中各种参数的变化情况反映的就越真实。数据流读取的实时性对于车辆故障诊断，车辆运行状态监控有着极为重要的影响。因此，根据不同服务对实时性的要求，需要制定了不同的通信机制。
本文将汽车故障诊断系统的通信过程分为两种情况来处理。对于实时性要求不高的非数据流服务请求，使用上位机的发送接收函数，一次请求应答即可，如图3所示；对于实时性要求较高的数据流服务请求，在两个方面优化了读数据流的实时性，如图4所示。
第一，在请求方式上，采用动态定义读数据流。传统的读数据流方式，每条数据流需要一次请求，当选择的数据流条目较多时，每次读取需要多次请求，数据响应将会滞后。而采用动态定义读数据流，将分配的动态ID和所选的数据流PID组合成一个动态定义请求指令（如2C、FE、00 05，其中2C为动态定义服务指令，FE为动态ID， 0005为PID），肯定响应后，便可用服务指令“AA01 所分配的动态ID”来读取数据流，这样将要读取的数据流动态组合在一起，当动态定义请求成功后，每次读取只需要一次请求即可。
第二，在通信过程上，采用循环发送请求。相比于每次都由上位机的发送函数来发送请求，采用MDI循环发送请求，将节省从上位机到MDI的传输时间。对于需要反复请求的数据流指令来说，每次请求应答需要的时间缩短，将明显提高了读取数据流的实时性。
通过在数据流服务通信过程采用了周期循环发送和动态定义相结合的方法，合理设置循环发送请求周期（T1）和循环接收数据周期（T2），对系统通信机制进行了优化。对某款采用K线通信协议的ECU进行了通信测试，使用示波器检测到K线读取数据流时的波形图。如图5所示，循环发送的周期约为150ms，发送数据流请求与得到反馈的时间间隔约为45ms，完全满足对读取数据流实时性的要求。
4 系统软件
诊断系统软件选用Visual Studio 2008平台，采用C#编写。使用Microsoft SQL Server数据库。
根据诊断系统硬件选型和需求分析，采用分层的设计思路，将软件架构从下到上分为四层：MDI驱动层，数据访问层，业务逻辑层，表示层。诊断软件构架如图6所示。
4.1 MDI驱动层
MDI驱动层主要负责标准接口函数的调用，将标准接口函数封装成18个功能函数，供数据访问层调用。驱动层实现了数据访问层和MDI接口函数的隔离。功能函数及描述如表2所示：
4.2 数据访问层
数据访问层主要负责对MDI数据的发送和接收、数据库的数据交互以及对服务器数据的上传和下载。数据访问层建立在MDI驱动层之上，通过使用MDI驱动层封装的函数，设计了7个函数接口，供业务逻辑层调用。主要包括：
4.3 业务逻辑层
业务逻辑层主要负责OBD指令生成，反馈数据解析和诊断数据管理。当用户通过操作接口给出诊断请求时，业务逻辑层会根据协议规定将请求封装成标准的OBD数据帧传递给数据访问层；当数据访问层接收到ECU的反馈数据时，业务逻辑层将从反馈数据中提取有效数据，根据协议规定解析成实际值，通过表示层显示给用户。
同时，业务逻辑层负责诊断系统功能的实现，主要包括常规故障诊断功能、维修诊断帮助功能、ECU在线刷新功能、软件附属功能四个部分。
常规故障诊断功能包括读故障码，清除故障码，读冻结帧，读数据流，动作测试等。通过数据访问层的发送接收函数完成和ECU的数据交互。
维修诊断帮助功能是通过数据访问层的MdbRead访问诊断数据库，从诊断数据库中查询相应的维修帮助手册内容并显示。
ECU在线刷新功能是通过数据访问层的WebUpload和WebDownload完成与服务器的数据上传下载，通过SendCommand完成对被刷新ECU数据的写入，在线刷新的流程如图7所示： 软件附属功能包括软件激活，用户认证，密码修改，软件升级，诊断报告生成等。
4.4 表示层
表示层主要负责数据的显示和用户操作接口的提供。如图8所示，用户界面主要包括状态显示区，主工作区和导航区三部分。状态显示区负责所选诊断功能、车型模块及MDI连接状态等状态的显示；主工作区负责用户操作和结果显示；导航区可以实现不同界面之间的切换和软件的退出。
5 系统测试及结果分析
以某车辆（其电控模块包括ECU，BCM， ABS，SDM，EPS，IPC等六个核心电控模块）为测试对象，MDI诊断工具通过车辆OBD接口连入车载网络，测试人员通过PC端的诊断软件进行故障诊断功能测试和模块刷新功能测试。
5.1 故障诊断功能测试
车辆故障灯常亮，读到故障码P0031，描述为上游氧传感器加热电路对地短路，初步判断为上游氧传感器故障，如图9所示；读取上游氧传感器电压数据流，发现电压值曲线不变，意味着上游氧传感器并未工作。根据软件的维修诊断帮助逐步排查，更换上游氧传感器后，重新读取上游氧传感器电压数据流，电压值在正常范围波动，恢复正常，如图10所示。清除故障码，故障灯熄灭，故障排除。
5.2 在线刷新功能测试
车辆的发动机控制模块标定数据需要更新时，使用软件的在线刷新功能，可在ECU不拆卸的情况，将更新的标定数据写入发动机控制模块。刷新功能测试界面如图11所示。整个刷新过程仅用时约15分钟，相比传统的更换电控模块和拆卸回厂更新，大大节约了时间和成本。
6 结论
基于MDI的汽车故障诊断系统硬件选用满足SAE J2534标准的诊断接口工具，兼容主流的车载网络通信协议，具有良好的通用性；软件采用架构层次化、功能模块化的开发思路，具有良好的扩展性；对系统通信机制进行了研究和优化，实现了基于通用诊断通信接口装置的PC式汽车故障诊断系统的开发，对应用标准设备开发具有一定借鉴意义。
通过测试分析可知，该汽车故障诊断系统的数据读取频率高，响应速度快，不仅能够满足诊断任务，还可以实时监控车辆及发动机的运行状况，此外还具备维修诊断帮助和电控模块在线刷新功能，为车辆的诊断维修提供了有利的工具。
参考文献
[1] 颜伏伍， 王攀， 胡杰， 等. 基于车载总线的PC式汽车故障诊断系统[J]. 武汉理工大学学报， 2011， 33（5）：758-762.
[2] 郭刚， 王励明， 卢明.基于MVCI、ODX的诊断标准研究[J]. 制造业自动化， 2010， 32（12）：15-16.
[3] 胡杰， 盛祥政， 李洪飞， 等. 基于智能手机的汽车故障诊断系统的研究与开发[J].汽车技术， 2011， 9：4-10.
[4] 蔡浩， 汽车故障诊断系统的设计与开发[M].上海：上海交通大学， 2009.
[5] SAE J2534-1， Surface Vehicle Recommended Practice[S]. 2004.
[6] ISO/WD14230-2， Road vehicles diagnostic system keyword protocol 2000 data Link[S].1997.
关键词：车载诊断系统；汽车故障诊断；多功能诊断通信接口；SAE J2534
中图分类号：U472.9 文献标识码：A 文章编号：1005-2550（2015）03-0017-06
Abstract： For the deficiencies of traditional PC-based vehicle fault diagnostic system， this paper proposes a kind of standardized PC-based vehicle fault diagnostic system which by the standardized diagnostic interface device and diagnostic application software， selects the MDI diagnostic device which conformed to SAE J2534 standard， studies the communication mechanism of MDI and SAE J2534 standard content， optimizes the data read rate， develops the diagnostic application software using the ideas of hierarchical architecture and function modularization. Through vehicle testing and analysis， this system allows the fault diagnosis， maintenance help， real-time monitoring and online refresh for vehicle electronic control system， has a good versatility and scalability， has a reference for developing standardized diagnostic device and provides the favorable tools for Vehicle Diagnosis and Maintenance.
Key Words： On-Broad Diagnostic System； Vehicle Fault Detection； Multiple Diagnostic Interface； SAE J2534
前言
PC式汽车故障诊断系统因为在实时监控、集成处理、功能扩展、远程诊断等方面的优势，替代手持式诊断设备成为目前汽车诊断的主流选择[1]。
然而，不同厂商支持的诊断总线类型、诊断引脚定义和诊断通信协议不尽相同，为满足各大汽车厂商车辆内部日益增多的ECU（Electronic Control Unit）诊断任务的要求[2]。因此，笔者提出一种基于MDI（Multiple Diagnostic Interface）的PC式汽车故障诊断系统。
1 系统方案
系统由标准诊断接口设备（MDI诊断工具）和故障诊断软件两部分组成。系统的构架如图1所示。
标准诊断接口设备通过车辆的OBD（On-Broad Diagnosis）接口接入车载网络，其主要负责笔记本电脑和车辆之间不同数据帧的封装和信号的转换。
故障诊断软件安装在笔记本电脑上，通过USB线与标准诊断接口设备连接，其主要负责向车辆ECU发送请求指令，处理应答数据；同时笔记本电脑还可以通过互联网访问服务器数据库，完成数据的上传下载。
2 系统硬件
该系统采用笔记本电脑和标准诊断接口设备的硬件组合。标准诊断接口设备选用通用汽车公司的MDI诊断工具。
MDI诊断工具遵循SAE J2534标准，SAE J2534是用于车辆ECU编程刷新的软硬件标准。通过满足SAE J2534标准的接口设备不仅可以实现笔记本电脑和ECU的数据通信，也可以对ECU进行重新编程[3]。同时MDI支持多种主流的车载通信协议，包括KWP2000、CAN总线（ID为11位的标准帧）、CLASS2、UART等[4]。另外，MDI充分的兼容了ISO 22900-1、ISO 22900-2、ISO 22900-3的标准，实现了新兴MVCI（Modular Vehicle Communication Interface）软件构架，具有良好的扩展性。
3 系统通信机制研究
MDI是基于SAE J2534标准设计的诊断工具。其数据处理、链路控制和流程控制是由MDI下位机软件和SAE J2534规定的标准接口函数共同完成。表1所示为SAE J2534定义的标准接口函数[5]。
3.1通信过程建立
目前车辆上的电控模块绝大多数选用K线或CAN总线通信协议，因此汽车故障诊断系统主要针对K线和CAN总线通信协议进行开发，同时保留其他通信协议的接口，易于今后扩展。图2为调用标准接口函数实现通信过程的流程。 a. 与MDI建立连接：连接成功将返回设备ID。
b. 设置通信协议ID和相应波特率：其中K线的协议ID设置为0x04，波特率设置为10 400kbps； CAN总线的协议ID设置为0x06，波特率设置为 50 000kbps。设置成功将返回通道ID。
c. 过滤设置：对于K线，超过一定时间没有数据交互，则会自动断开通信。因此需要每3s循环发送测试在线指令“3E”，以保持K线通信在线，同时过滤掉ECU正反馈指令“7E”，避免上位机对反馈数据的频繁操作，节约资源；对于CAN总线，总线上传输着大量数据，通过CANID的过滤，筛选出需要的数据给上位机。
d. 通信初始化：对于K线的ECU，在开始通信之前还需要对其进行初始化。这里选择快速初始化方式，对应接口函数PassThruIoctl的参数loctlID为0x05。
e. 数据收发：在上述设置成功后，便可直接调用PassThruWriteMsgs和PassThruReadMsgs进行数据的收发。
f. 与MDI断开连接：在结束诊断后，需要断开指定协议的通信通道以及与MDI的连接，释放资源。
3.2 通信机制优化
基于KWP2000协议的诊断服务必须遵循一定的时序来进行，ISO 14230-2给出了诊断服务请求响应过程的时序图以及时序参数P1、P2、P3、P4的严格规定[6]。
P1、P2、P3、P4以及诊断系统的通信机制是影响数据读取实时性的主要因素。协议已经对P1、P2、P3、P4有着严格的规定，因此优化诊断系统的通信机制是提高读取数据实时性的唯一途径。
不同的诊断服务对通信过程的实时性要求也不同。对于读取故障码，清除故障码，读取冻结帧，动作测试和读取模块信息这些服务，完成诊断服务只需要一次请求应答，对实时性的要求不高；而对于读数据流服务，需要短时间内连续的请求应答。一次请求应答的时间越短，每次请求时间间隔越小，车辆和发动机运行中各种参数的变化情况反映的就越真实。数据流读取的实时性对于车辆故障诊断，车辆运行状态监控有着极为重要的影响。因此，根据不同服务对实时性的要求，需要制定了不同的通信机制。
本文将汽车故障诊断系统的通信过程分为两种情况来处理。对于实时性要求不高的非数据流服务请求，使用上位机的发送接收函数，一次请求应答即可，如图3所示；对于实时性要求较高的数据流服务请求，在两个方面优化了读数据流的实时性，如图4所示。
第一，在请求方式上，采用动态定义读数据流。传统的读数据流方式，每条数据流需要一次请求，当选择的数据流条目较多时，每次读取需要多次请求，数据响应将会滞后。而采用动态定义读数据流，将分配的动态ID和所选的数据流PID组合成一个动态定义请求指令（如2C、FE、00 05，其中2C为动态定义服务指令，FE为动态ID， 0005为PID），肯定响应后，便可用服务指令“AA01 所分配的动态ID”来读取数据流，这样将要读取的数据流动态组合在一起，当动态定义请求成功后，每次读取只需要一次请求即可。
第二，在通信过程上，采用循环发送请求。相比于每次都由上位机的发送函数来发送请求，采用MDI循环发送请求，将节省从上位机到MDI的传输时间。对于需要反复请求的数据流指令来说，每次请求应答需要的时间缩短，将明显提高了读取数据流的实时性。
通过在数据流服务通信过程采用了周期循环发送和动态定义相结合的方法，合理设置循环发送请求周期（T1）和循环接收数据周期（T2），对系统通信机制进行了优化。对某款采用K线通信协议的ECU进行了通信测试，使用示波器检测到K线读取数据流时的波形图。如图5所示，循环发送的周期约为150ms，发送数据流请求与得到反馈的时间间隔约为45ms，完全满足对读取数据流实时性的要求。
4 系统软件
诊断系统软件选用Visual Studio 2008平台，采用C#编写。使用Microsoft SQL Server数据库。
根据诊断系统硬件选型和需求分析，采用分层的设计思路，将软件架构从下到上分为四层：MDI驱动层，数据访问层，业务逻辑层，表示层。诊断软件构架如图6所示。
4.1 MDI驱动层
MDI驱动层主要负责标准接口函数的调用，将标准接口函数封装成18个功能函数，供数据访问层调用。驱动层实现了数据访问层和MDI接口函数的隔离。功能函数及描述如表2所示：
4.2 数据访问层
数据访问层主要负责对MDI数据的发送和接收、数据库的数据交互以及对服务器数据的上传和下载。数据访问层建立在MDI驱动层之上，通过使用MDI驱动层封装的函数，设计了7个函数接口，供业务逻辑层调用。主要包括：
4.3 业务逻辑层
业务逻辑层主要负责OBD指令生成，反馈数据解析和诊断数据管理。当用户通过操作接口给出诊断请求时，业务逻辑层会根据协议规定将请求封装成标准的OBD数据帧传递给数据访问层；当数据访问层接收到ECU的反馈数据时，业务逻辑层将从反馈数据中提取有效数据，根据协议规定解析成实际值，通过表示层显示给用户。
同时，业务逻辑层负责诊断系统功能的实现，主要包括常规故障诊断功能、维修诊断帮助功能、ECU在线刷新功能、软件附属功能四个部分。
常规故障诊断功能包括读故障码，清除故障码，读冻结帧，读数据流，动作测试等。通过数据访问层的发送接收函数完成和ECU的数据交互。
维修诊断帮助功能是通过数据访问层的MdbRead访问诊断数据库，从诊断数据库中查询相应的维修帮助手册内容并显示。
ECU在线刷新功能是通过数据访问层的WebUpload和WebDownload完成与服务器的数据上传下载，通过SendCommand完成对被刷新ECU数据的写入，在线刷新的流程如图7所示： 软件附属功能包括软件激活，用户认证，密码修改，软件升级，诊断报告生成等。
4.4 表示层
表示层主要负责数据的显示和用户操作接口的提供。如图8所示，用户界面主要包括状态显示区，主工作区和导航区三部分。状态显示区负责所选诊断功能、车型模块及MDI连接状态等状态的显示；主工作区负责用户操作和结果显示；导航区可以实现不同界面之间的切换和软件的退出。
5 系统测试及结果分析
以某车辆（其电控模块包括ECU，BCM， ABS，SDM，EPS，IPC等六个核心电控模块）为测试对象，MDI诊断工具通过车辆OBD接口连入车载网络，测试人员通过PC端的诊断软件进行故障诊断功能测试和模块刷新功能测试。
5.1 故障诊断功能测试
车辆故障灯常亮，读到故障码P0031，描述为上游氧传感器加热电路对地短路，初步判断为上游氧传感器故障，如图9所示；读取上游氧传感器电压数据流，发现电压值曲线不变，意味着上游氧传感器并未工作。根据软件的维修诊断帮助逐步排查，更换上游氧传感器后，重新读取上游氧传感器电压数据流，电压值在正常范围波动，恢复正常，如图10所示。清除故障码，故障灯熄灭，故障排除。
5.2 在线刷新功能测试
车辆的发动机控制模块标定数据需要更新时，使用软件的在线刷新功能，可在ECU不拆卸的情况，将更新的标定数据写入发动机控制模块。刷新功能测试界面如图11所示。整个刷新过程仅用时约15分钟，相比传统的更换电控模块和拆卸回厂更新，大大节约了时间和成本。
6 结论
基于MDI的汽车故障诊断系统硬件选用满足SAE J2534标准的诊断接口工具，兼容主流的车载网络通信协议，具有良好的通用性；软件采用架构层次化、功能模块化的开发思路，具有良好的扩展性；对系统通信机制进行了研究和优化，实现了基于通用诊断通信接口装置的PC式汽车故障诊断系统的开发，对应用标准设备开发具有一定借鉴意义。
通过测试分析可知，该汽车故障诊断系统的数据读取频率高，响应速度快，不仅能够满足诊断任务，还可以实时监控车辆及发动机的运行状况，此外还具备维修诊断帮助和电控模块在线刷新功能，为车辆的诊断维修提供了有利的工具。
参考文献
[1] 颜伏伍， 王攀， 胡杰， 等. 基于车载总线的PC式汽车故障诊断系统[J]. 武汉理工大学学报， 2011， 33（5）：758-762.
[2] 郭刚， 王励明， 卢明.基于MVCI、ODX的诊断标准研究[J]. 制造业自动化， 2010， 32（12）：15-16.
[3] 胡杰， 盛祥政， 李洪飞， 等. 基于智能手机的汽车故障诊断系统的研究与开发[J].汽车技术， 2011， 9：4-10.
[4] 蔡浩， 汽车故障诊断系统的设计与开发[M].上海：上海交通大学， 2009.
[5] SAE J2534-1， Surface Vehicle Recommended Practice[S]. 2004.
[6] ISO/WD14230-2， Road vehicles diagnostic system keyword protocol 2000 data Link[S].1997.