基于智能手机的汽车故障诊断系统研究与开发

基于智能手机的汽车故障诊断系统研究与开发
胡杰;盛祥政;李洪飞;曾恺;颜伏伍
【摘要】研究了一种利用OBD系统基于智能手机平台的汽车故障诊断系统,该系统由手机诊断程序和VCI系统组成.手机诊断程序通过遵循SAE J2534标准的VCI 系统与车内电子控制单元进行通信,获取汽车故障代码及汽车内部实时状态数据.由智能手机对诊断数据进行处理和管理,并整合诊断辅助功能.通过实际测试验证了整个系统性能.%ln this paper, an automotive troubleshooting system based on smart phone using OBD System is studied, the system is made up of mobile diagnostics application and VCI (Vehicle Communication Interface) system. Mobile diagnostics apph'calion communicates with the on-board electronic control unit by VCI system which follows the SAE-J2534 standard, and gets vehicle DTC (Diagnostic Trouble Codes) and vehicle internal real time data. Smartphone processes and manages the diagnostic data, and also integrates auxiliary function of fault diagnosis. System performance is validated by practical test.
【期刊名称】《汽车技术》
【年(卷),期】2011(000)009
【总页数】7页(P4-10)
【关键词】车辆故障;诊断;车载诊断系统;智能手机
【作者】胡杰;盛祥政;李洪飞;曾恺;颜伏伍
【作者单位】武汉理工大学现代汽车零部件技术湖北省重点实验室;武汉理工大学现代汽车零部件技术湖北省重点实验室;武汉理工大学现代汽车零部件技术湖北省重点实验室;武汉理工大学现代汽车零部件技术湖北省重点实验室;武汉理工大学
现代汽车零部件技术湖北省重点实验室
【正文语种】中文
【中图分类】U472
1 前言
目前手持式诊断仪器一般基于linux或Windows ce等嵌入式操作系统，其硬件
需要专门设计，开发难度及成本都较高[1，2]；一般使用C或C++语言编写诊断
软件，与当前流行的C#语言相比，开发效率较低。

针对上述问题，本文提出了基于智能手机的汽车故障诊断系统，即利用智能手机现有的硬件平台和软件开发环境，简化了汽车故障诊断系统的开发过程，降低了成本，同时能满足各种诊断应用需要。

2 手机诊断系统概述
手机诊断系统由手机诊断软件和VCI（Vehicle Communication Interface）系统两部分组成，系统结构示意图如图1所示。

智能手机通过VCI与车载网络建立通信链接，实现基于OBD的故障诊断。

其中，VCI系统基于SAE J2534标准设计，是手机诊断软件和车载网络通信的桥梁。

SAE J2534由美国SAE协会制定，是用于车辆ECU编程刷新的软硬件标准。

通过SAE J2534设备不仅可以实现PC对ECU进行重新编程，也可以实现PC和ECU
的数据通信[3]。

在本故障诊断系统中，将SAE J2534标准运用到手机平台上，设计了基于SAE J2534标准的VCI系统。

图1 手机诊断系统结构示意
手机诊断软件通过调用SAE J2534 API与车载网络通信实现具体的诊断应用，并且提供友好的人机交互界面、诊断数据管理等功能。

整个系统主要实现以下几点功能：
a. 本地OBD诊断。

实现读故障码、读冻结帧、读数据流和动作测试等OBD规定的故障诊断功能。

b. 集成故障码查询。

通过手机外部存储卡存储多个厂商故障帮助信息，提供故障码详细解释及相应解决措施。

c. 对每次故障诊断生成故障诊断报告。

报告中包含车辆图片、车辆唯一标识（VIN）等详细信息，并可通过网络将故障诊断报告上传到厂商的故障诊断中心。

d. 诊断数据PC管理。

以特定格式保存诊断数据，利用PC数据管理系统对诊断数据进行分析。

3 VCI系统研究
该VCI系统是一个不完全标准的SAE J2534设备。

根据SAE J2534要求，SAE J2534设备需支持 ISO 9141、ISO 14230-4 （KWP2000）、SAE J1850（PWM）、 SAE J1850 （VPW）、CAN、ISO 15765-4（CAN）、SAE J2610（SCI）[3]等诊断协议。

限于开发条件，本系统只针对 ISO 9141、ISO 14230-4（KWP2000）和ISO 15765-4（CAN）这3种通信协议进行了研究，所以本VCI 系统的软硬件设计主要围绕这3种诊断协议进行。

3.1 VCI硬件研究
VCI硬件由主控模块、CAN和K线硬件接口、蓝牙模块、USB模块、指示灯及电源模块组成，硬件结构如图2所示。

主控模块是整个硬件系统的核心部分，采用飞思卡尔公司的16位单片机
MC9SDG128，该单片机具有丰富的通信接口、2个SCI串口、2个CAN接口，其中一个串口通过K线硬件接口芯片与车载K线网络连接；另一个串口与蓝牙模
块及USB模块连接；CAN接口通过专用CAN收发器与车载网络CAN总线连接。

图2 VCI硬件结构
蓝牙模块是VCI与手机通信的核心部分。

目前手机对外设的通信方式主要有USB、蓝牙和WiFi。

很多手机之间USB硬件接口不兼容，而且开发USB通信的技术难
度较高［4］。

WiFi通信基于网络通信协议，开发难度大而且硬件成本高［5］。

蓝牙是一种支持短距离通信（一般10 m内）的无线电技术，具有功耗低、体积小和成本低的优点[6]。

目前智能手机上几乎都配置有蓝牙模块，而且蓝牙驱动成熟，很适合作为手机和VCI的通信方式。

VCI采用的蓝牙模块为半成品蓝牙模块，该模块采用 CSR （Cambridge Silicon Radio）公司的BlueCore4-External蓝牙芯片，最高支持3Mbps的
数据速率。

在硬件上，单片机通过SCI引脚与蓝牙模块建立物理连接，基于RFCOMM协议与蓝牙模块进行通信。

RFCOMM是蓝牙协议栈中对串口进行仿真的协议，它完成了对RS232串口的模拟。

在手机和VCI两个不同设备的应用之间形成一条完整的通信路径[7]。

对于手
机端，只需利用系统提供的蓝牙驱动，将蓝牙模块作为串口设备以串口通信方式和VCI通信。

图3为蓝牙串口通信示意图。

图3 蓝牙串口通信示意
3.2 VCI软件研究
VCI软件与SAE J2534 API函数库紧密相连，两者共同完成SAE J2534标准中的数据处理、链路控制及流程控制。

SAE J2534标准主要规定了J2534设备应当遵
循的通信接口规范，并没有详细规定接口内部的处理机制。

由于手机平台的特殊性及蓝牙通信的延时特性［8］决定实时和定时的数据处理和链路控制应由VCI完成，大量的数据运算由API函数库完成，同时应尽量减少
API函数库和VCI频繁的通信，两者任务有如下区分：
a. VCI完成的任务有链路定时控制、循环命令发送、发送数据控制、接收数据及
过滤控制、CAN流控制等。

b. API函数库中完成的任务有函数参数解析、数据校验及添加校验、数据接收缓存、VCI设置控制、产生错误信息等功能。

VCI的软件框架如图4所示。

图4 VCI软件框架图
VCI软件不干涉发送和接收数据，但会过滤接收数据报文，以防止车载网络中大量无关的数据进入API接收缓存阻塞系统。

3.3 SAE J2534 API的设计
SAE J2534 API函数库是实现手机诊断程序和VCI通信的通信接口，采用Visual
C++来编写，并最终编译成DLL供手机诊断程序调用。

SAE J2534 API在系统中
的功能如图5所示。

图5 SAE J2534 API功能示意
因为使用蓝牙技术作为手机和VCI的通信媒介，其数据传输性能将受到蓝牙传输
效率的影响。

研究表明，蓝牙技术与有线串口相比存在较长的传输延时［9］。

为保证VCI系统有较高效的通信效率，需制定合理的通信策略。

研究显示，在理想
条件下，传输50字节数据，PC对PC的蓝牙串口传输数据延时在10 ms左右[9]。

由于不同厂商蓝牙模块及手机蓝牙驱动的影响，手机和VCI通过蓝牙串口传输的
延时跟PC之间的蓝牙串口传输延时不太相同。

为此，测试了正常情况下手机和VCI通过蓝牙串口传输数据的传输延时。

测试以下述方式进行：发送50字节到单片机，单片机接收完所有数据后立即回馈相同数据到手机，这个过程连续不间断循环进行；然后通过示波器监测单片机上的串口接收和发送引脚，可以得到图6。

其中send为蓝牙模块TX引脚上的信号曲线，feedback为蓝牙模块RX上的信号曲线。

图6 蓝牙传输延时波形图
由图6可见，每次测试周期有一段较长的空闲时间，该空闲时间就是由蓝牙传输延时导致。

相关的循环周期分布如图7所示。

由图7可见，整个循环周期在155 ms左右，除去数据在串口物理层的传输时间t=2×50/3840=26 ms，即蓝牙通信延时时间为155-26=129 ms。

155 ms代表手机和VCI一个完整通信来回的最短时间。

如此高的延时会导致手机与VCI的通信效率下降，并最终影响系统的诊断性能。

所以在设计API时需尽可能避免在实时性要求较高的情况下与VCI进行双向通信操作。

在设计PassThruReadMsgs函数时，将数据接收缓存建立在DLL中，当VCI接收到合法数据时，VCI立即自动将数据上传到DLL的数据接收缓存中。

手机诊断程序则直接访问DLL缓存从而避免了与VCI数据接收缓存的双向通信。

PassThruStart-PeriodicMsg中的周期性命令也应该放在VCI中自动执行，DLL 只需控制队列的初始化、开始、结束等操作。

图7 蓝牙延时测试循环周期
4 通信机制研究
4.1 通信机制原理分析
KWP2000诊断协议采用问答式通信过程，即请求一次诊断指令，ECU返回一次数据，而且协议规定了通讯过程中的时序，如图8所示。

各计时参数定义如表1所示。

图8 数据请求及反馈时序表1 计时参数定义
SAE J2534 API根据ISO 14230规定设定了相关默认值，并将其应用到VCI软件中，应用层只需考虑P2和P3。

不同诊断应用的通信过程不一样。

如读故障码通信过程，向ECU发送一个读故障
码的请求报文，ECU反馈带有故障码信息的报文，一个通信回合就可以完成读故
障功能。

其他如读冻结帧、清故障码、读ECU信息也是如此，此类诊断应用对通
信效率要求不高。

数据流本质上也是请求一次，ECU反馈一次，如果连续请求就
可以获得连续的数据流报文，通过解析这些报文可以获得连续的汽车内部状态数据。

数据流读取频率越高，由数据流提取出来的数据就越能真实反应发动机内部的运行状况，所以不管是作为故障诊断或发动机运行状况分析还是汽车运行状态数据采集，快速的数据流读取至关重要。

决定数据流读取速度的关键点是蓝牙传输延时及诊断系统的通信机制P1、P2、P3、P4。

根据通信过程的不同可将请求指令分为数据流请求和非数据流请求两种。

非
数据流请求对数据实时性要求不高，不需要特别处理，而数据流请求则严格按照一定的通信定时要求进行。

系统通信机制如图9所示。

图9 系统通信机制
系统以动态定义帧方式读取数据流。

将请求命令封装为周期发送命令发送到VCI
周期发送队列里，以一定间隔时间T1自动向ECU发送。

VCI接收到ECU的反馈
数据后自动发送到SAE J2534 DLL接收数据缓存中，手机诊断程序则不断读取DLL的数据接收缓存来获得数据流反馈数据。

由此，整个系统的通信以周期T1进行而避免了与VCI双向通信延时的影响。

制约数据读取速度的参数只剩下P1、P2、P3、P4及数据在物理层的传输速度。

其中T1min可通过公式（1）估算：
式中，Ts为发送数据在物理层的传输时间；Tr为反馈数据在物理层的传输时间。

对于K线，可通过公式（2）和公式（3）保守计算Ts和 Tr。

式中，Ns为发送数据的长度；t为单字节数据在物理总线上的传输时间；Np为选
取的数据流数目。

T2min应该小于等于T1min，即一个发送循环的总时间。

由此可见整个诊断系统
以T1min为周期循环读取数据流。

4.2 实际验证
KWP2000的定时要求如表2所列[11]。

表2 定时参数设置 ms名称最小值最大值下限默认默认上限P1 0 0 20
20 P2 0 25 50 取决于总线速度P3 0 55 5000 ∞（S FF）P4 0 5 20 20
以K线为例进行验证，K线的最大波特率为10400[10]，一个字节加上开始和结
束位共有10位，一个字节在物理层的传输时间可通过公式（4）计算：
以UAES某款ECM （Engine Control Module，发动机控制模块）为测试对象，该ECU使用K线通信协议，并设定P2=25，P3=55，P4=5。

测试中随机选取3
个数据流PID，通过示波器监测K线，其波形如图10所示。

图10 K线数据流读取波形图
其中请求命令为“82 11 F1 21 F0 95”，可以计算出T1min=146 ms，这与图9的数据相吻合。

通过试验可以看到图8所示的通信机制达到了良好效果，可有效
避免蓝牙通信延时造成的不利影响。

5 手机诊断程序设计
手机诊断软件是整个系统的核心部分，不仅要实现具体的诊断应用还要提供良好的交互界面。

因所有诊断应用都由手机诊断软件完成，为此必须有稳健的软件架构、良好的数据结构及高效的通信机制。

基于window mobile 6.0平台采用C#语言
来编写手机诊断程序，软件的整体架构如图11所示。

图11 手机诊断程序框架
5.1 通信模块设计
通信模块主要完成对VCI链路控制、数据封装及拆包和数据发送与接收。

在发送时，对数据报文进行协议封装，然后调用SAE J2534 API发送到VCI。

在接收数
据时，调用SAE J2534 API接收ECU反馈数据，并对ECU反馈数据进行拆包处理，最后将数据发送到诊断应用模块。

5.2 诊断应用模块设计
诊断应用模块主要实现KWP2000规定的应用层功能，如故障码读取及清除、冻
结帧读取、数据流读取、ECU动作测试、模块信息读取等。

诊断应用模块通过发
送请求指令从ECU获得反馈报文，并根据具体模块对报文的定义将数据报文解析
为相关诊断信息，如故障码数目、故障码代号等信息。

除此之外，诊断应用模块还整合了故障诊断过程中可能需要的如下附加功能。

a. 故障码查询。

由数据管理模块管理手机存储卡上的故障码数据库，通过诊断帮
助模块查询故障码的详细信息，获取故障码排除措施。

b. 数据流曲线显示。

通过手机显示屏实时显示数据流变化曲线，使用户可以直观
看到汽车内部大量运行状态的变化趋势如发动机转速、节气门开度、发动机水温、点火提前角等。

c. 诊断数据管理。

对诊断过程中产生的诊断数据进行管理。

数据主要包括故障码、冻结帧、数据流信息和模块标识信息，并将数据以特定格式保存在手机存储卡内。

d. 生成诊断报告。

诊断报告是对本次诊断详细描述，包括时间、地点、人物、车型、模块和诊断过程中产生的诊断数据（如故障码、数据流数据、故障处理方法以及处理结果）等。

诊断报告大部分内容由系统自动生成，操作人员只需补充少部分内容。

如果有额外需要，手机诊断程序还可以调用手机摄像头拍摄高清晰图片或录制语音、视频等多媒体信息。

一旦诊断报告生成，可以马上将诊断报告上传至远程诊断中心，由远程诊断中心对诊断报告进行管理，建立汽车故障信息数据库。

5.3 数据管理模块设计
本系统主要采用XML技术作为数据存储方式，将故障码、模块信息以XML格式
进行存储。

XML格式可以方便的进行跨平台、跨语言、跨网络的数据交换，有利
于系统数据的更新及整个系统的升级。

而诊断数据则以CSV格式存放，方便PC
进行处理和分析。

故障码详细解释则以Htm方式保存，无论是PC平台还是手机
平台都可以通过浏览器进行加载及显示。

数据管理模块则对这些数据进行管理和调用。

5.4 手机诊断软件界面
图12为手机诊断软件部分使用界面，图13为PC端数据管理软件界面。

图12 手机诊断软件系统界面
图13 PC端数据管理软件界面
6 系统测试及分析
以某款车型为测试对象，通过手机诊断系统连接车辆诊断接口，通过与车辆ECM
模块的通信，实时获取并监测车辆运行时的部分参数，监测参数包括节气门位置信号、进气歧管压力信号、点火提前角信号、发动机转速信号。

图14～图16所示
为部分道路测试试验结果，包括怠速、加速、减速及匀速等工况。

图14 进气温度电压和节气门位置电压信号
图15 车速与发动机转速信号
图16 进气歧管绝对压力与1缸点火提前角信号
当发动机处于怠速时，发动机转速维持在750 r/min左右，进气歧管压力为
0.028 MPa左右，说明发动机怠速工作稳定；加速后进气歧管压力急剧变低，对
点火提前角有很大影响，使得点火提前角变为负值。

通过分析试验结果可知，该手机诊断系统数据读取频率较高，能够实时、准确反映发动机或车辆的实际工作状况，能够为汽车维修和新车型开发测试提供有利工具和重要支撑。

参考文献
【相关文献】
1 赵静.手持式仪器μClinux操作系统的研究与实践：[学位论文.南京：南京师范大学，2005.
2 郑盛.汽修系统的嵌入式平台研究：[学位论文].大连：大连海事大学，2006.
3 SAE.J2534-1 “Surface Vehicle Recommanded Practice”.SAE，2004.
4 胡晓军，张爱成.USB接口开发技术.西安：西安电子科技大学出版社，2005.
5 ISO/EC 8802-II:1999 （E）.“Wireless LAN Medium Access Control （MAC） and Physical Layer（PHY）Specifications”．1999．
6 钱志鸿，杨帆，周求湛．蓝牙技术原理、开发与应用．北京：北京航空航天大学出版社，2006．
7 马晋兴，陈启军．蓝牙协议栈中RFCOMM协议层的分析与实现．上海：计算机工程，2004，08-042．
8 Rozeha A.Rashid and Rohaiza Yusoff．“Bluetooth Performance Analysis in Personal Area Network （PAN）”.PUTRAJAYA：2006 International RF and Microwave Conference Proceedings,2006．
9 M．J．Moron，R．Luque，E．Casilari，A．D az-Estrella．Minimum delay bound in Bluetooth transmissions with serial port profile．ELECTRONICS LETTERS 28th August 2008 Vol．44 No．18．
10 ISO/WD14230-1，“Road vehicles diagnostic system keyword protocol 2000 phy sical layer”．1997．
11 ISO/WD14230-2，“Road vehicles diagnostic system keyword protocol 2000 data Link”．1997．。