基于Android和车载OBD的车辆参数实时采集系统

谢江浩，彭忆强*，黄志东，黄得铭，任洪涛

(1．西华大学汽车与交通学院，四川 成都 610039；2．成都易泰客汽车技术有限公司，四川 内江 641000)



基于Android和车载OBD的车辆参数实时采集系统

谢江浩1， 彭忆强1*，黄志东2，黄得铭2，任洪涛1

(1．西华大学汽车与交通学院，四川 成都 610039；2．成都易泰客汽车技术有限公司，四川 内江 641000)

摘要：为实现对车载OBD数据的采集与显示，设计一个以16位MC9S12XEP100作为主控制器，以Android手机为移动终端的数据采集显示系统。在主控制器中，以KWP2000作服务层，以TP2.0作传输层，按OSEK通信标准实现双向传输通道的动态分配，采用CAN总线技术实现与OBD的数据传输；同时，主控制器通过蓝牙设备与Android手机的APP连接，实现车辆运行数据的在手机上的显示。通过在试验样车上进行测试，表明该系统工作稳定、可靠，可为车联网的实施提供参考。

关键词：TP2.0；OBD ； KWP2000 ； APP；Android系统

汽车的OBD(on board diagnostics)不仅具有监控车辆尾气排放的功能，而且通过OBD还能获取发动机控制单元(ECU)、变速箱控制单元(TCU)等各个控制单元的内部参数，实现车辆故障检测、诊断的功能[1]。针对OBD系统与车辆各个控制单元之间的数据交换，欧洲和美国都制定了相关的协议标准。其中：在欧洲广泛使用的是基于TP2.0传输层与KWP2000应用层的车载诊断服务协议[2]；在美国和我国，大部分采用基于ISO15765-2传输层协议[3]。

本文将研究对象定位于德系乘用车，因此在工作过程中，采用TP2.0作为传输层协议。基于对该协议OBD数据流的分析，设计了主控制器采集OBD数据、移动终端(如android手机APP)作为人机界面、移动终端与主控制器采用蓝牙模块通信协议，实时显示车速、发动机转速、油耗等车辆运行参数的采集系统，为后期车联网采集不同车辆的参数信息，以及智能交通系统中车辆的自动化管理奠定了基础。

1系统整体设计框架

本文研发的车辆参数采集系统以Fresscale 16位MC9S12XEP100作为主控制器，其整体设计方案框架如图1所示。

图1　系统整体设计方案框架

系统中采用的微处理器(MC9S12XEP100)最高总线时钟频率可以达到40 M，内部64KB RAM，1 M片内Flash，可以满足实际应用的需要。

现在的智能手机都具有蓝牙通信功能[4]，以Android手机蓝牙APP作为人机界面，能够实时、方便地显示车辆运行参数，以及车辆故障代码。

该方案的工作过程如下：Android手机蓝牙APP搜索主控制器的蓝牙模块，并进行配对；配对成功后，向其发送请求连接命令；主控制器接收命令后，发出响应信号，两者握手成功。Android手机蓝牙APP再向主控制器发送请求数据命令；主控制器接收命令后，分析请求数据类型，通过CAN向OBD接口发送数据请求；主控制器接收到数据后，通过蓝牙模块发送给Android手机蓝牙APP。

请求数据完成后，手机蓝牙APP向主控制器发送断开连接命令，主控制器接收后，发出响应信号，并断开连接。

为实现该系统，下面将分别对诊断协议中传输层TP2.0与应用层KWP2000实现方式，以及主控制器与Android手机APP的通信过程进行详细阐述。

2TP2.0协议解析

TP2.0传输层协议可实现标准帧的CAN模块之间大量数据的传输，以及采用OSEK通信标准(V1.0)的双向传输通道动态分配协议。该协议对于连接中标识符的动态分配，以及响应超时后数据传输自动断开都具有非常重要的作用。在数据交换过程中，所有汽车控制单元的数据请求与接收都包括有唯一地址的动态标识符。同时，该协议具有数据传输双向通道、数据传输中断请求以及错误帧的更正等特征。

另外，在控制器数据传输的过程中：如果其传输通道只有1个，则属于静态通道；如果其传输通道有多个，则其在数据传输之前，必须进行通道的分配，则属于动态通道[5]。本文所采用的数据传输方式为动态通道方式。

2.1动态通道信息结构

动态通道主要用于2个ECU之间大量数据块的传输。为了实现数据的传输，主ECU向从ECU发送请求建立通道的报文；从ECU接收到报文后，必须在规定时间内给予肯定或否定的响应，否则，超时后将会自动断开连接。

建立通道的报文结构见表1。表中，RX-ID是一个11位的CAN ID，其中低八位放在RX-ID-Low中，高三位放在RX-ID-High中[6]。各字节与位域的定义说明见表2。

表1　建立通道中的报文结构

表2　建立通道中各个字节与位域的定义说明

从ECU接收到请求报文后，可能会出现响应超时以及给出否定响应的事件，下一节将介绍对该事件的处理方式。

2.2CAN报文错误处理

在TP2.0协议中，除了对报文接收与发送具有严格时间要求外，还对规定时间内未接收到响应、重新发送请求的次数也有规定。当发送与接收超时或发送次数超过最大次数后，都会作相应的错误处理。对超时或超次后的处理说明见表3。

表3　CAN报文错误处理

2.3CAN报文建立通道与连接过程分析

上面对建立通道过程中各个字节的含义进行了说明，但在实际操作过程中，对于CAN报文通道建立与连接过程中，各个字节数据需要组合在一起构成特定的命令[7]；因此，对建立通道与连接完整的通信应答模式还需进行进一步说明。下面以某款大众车型的OBD接口实测数据为例，对该过程进行分析，通道连接过程所对应的数据流如图2所示。

在图2所示的建立通道与连接过程中：发送通道请求CAN报文中的0X200为主ECU的ID号；0X01 为目标地址，也就是从ECU的ID号低8位；0XC0为建立通道请求；第5个字节0X00与第6个字节0X03分别给出了从ECU的ID低8位与高8位；第7个字节0X01表示读取KWP2000协议数据。接收通道响应CAN报文中的0X201为从ECU的ID号；0X00 为目标地址，也就是主ECU的ID号低8位；0XD0为接收通道响应；第3个字节0X00与第4个字节0X03分别给出了从ECU的ID低8位与高8位；第5个字节0X40与第6个字节0X07分别给出了主ECU的ID低8位与高8位；第7个字节0X01表示读取KWP2000协议数据。在建立通道与连接后，就可以进行数据的双向传输。

图2　建立通道与连接过程

2.4传输层协议数据单元(TPDU)报文分析

通道建立后，对于主从控制器之间的连接与数据传送，分别有不同的报文格式。表4到表7对TPDU报文格式进行了详细说明。其中：表4、表5对TPCI1字节各位域进行了说明，以及对在请求数据与应答的过程中，该字节不同数字所表示的不同含义进行了详细描述；表6说明了TPDU报文格式，以及各字节的含义；表7对TPCI2字节(在建立连接与连接响应过程中存在)各位域所表示的含义进行了说明[8]。

表4　TPCI1 结构说明

表5　TPCI1 具体数值含义说明

表6　TPDU报文格式

注：T1为控制器接收连续数据最大时间；T3为连续发送给控制器各个数据的最大间隔时间；T2为T4默认为0XFF。

表7　TPCI2 定义说明

注：BS为在不需要应答情况下最多可以连续发送数据帧的个数，该值范围是0

3基于TP2.0的KWP2000协议分析

3.1KWP2000信息帧分析

基于TP2.0的KWP2000应用层协议目前应用于大众集团的大多数车型上。在本次所试验测试的车上，是基于TP2.0协议实现的。其CAN的传输速率为500K，属于高速CAN。下面通过ECU数据流对数据传输过程进行分析。表8给出了KWP2000信息帧的结构定义。

表8　KWP2000信息帧结构定义

注：Len为数据长度(包含SID与后面的Data Bytes)。

由于一帧CAN报文最多只能包含8个字节，当KWP2000信息帧内容大于8个字节时，将分成多帧CAN报文进行发送[9]。其对应关系如图3所示。

KWP2000信息帧：

Byte0Byte1Byte2Byte4Byte5Byte6Byte7Byte8Byte907SIDD1D2D3D4D5D6

CAN报文第1帧：

IDByte1Byte2Byte3Byte4Byte5Byte6Byte7Byte8TPCI107SIDD1D2D3D4

CAN报文第2帧：

IDByte1Byte2Byte3TCPI1D5D6

图3KWP2000信息帧与CAN报文对应关系

在图3所示的KWP2000信息帧与CAN报文对应关系中，KWP2000信息帧的数据长度为9个字节，应该分为多个CAN报文发送，其中，第1帧第1个字节包括TPCI1信息，第2个和第3个字节为后面数据长度，SID为请求服务ID，后面4个字节为数据。由于数据未接收完，后面第2帧将继续接收数据，其中包括TCPI1与未接收完数据。

3.2通道数据流分析与计算

上面进行了TP2.0传输层以及KWP2000应用层的解析[9]，下面通过实例对测试车辆的OBD数据流进行分析。图4描述了建立通道与连接的请求与响应过程，以及数据的请求命令、响应命令、数据传输过程中各个通道数据的不同含义。

图4　应用层数据的传输过程

在图4所示的数据传输过程中，0X21为读取局部标识符服务，0X01与0X02分别为通道号，响应0X61为肯定响应，其肯定响应都满足请求服务命令加上0X40。响应中0XB1代表准备好下一包数据，0X2表示不需应答，后面跟随多包数据，0X1A表示后面数据长度。除去肯定响应的0X61与0X01，后面数据每3个为一组，用X、Y、Z表示[11]，其中X代表不同车辆参数的标识符。通过查表9，可以得到对应的计算公式以及对应的车辆运行参数。

表9　数据流运算公式与对应车辆运行参数

通过图4得到的车辆数据，查表9运算公式可以得出发送机转速为1 120 r/min，冷却液温度为97 ℃。

4主控制器与手机APP的通信协议

4.1通信协议要求

主控制器与手机APP间的数据交互主要是读取指定数据流和当前存在的故障码，需要满足如下要求：

1)采用主从交互模式，由主机发送请求，从机响应，在此应用中，手机APP作为主机，主控制器作为从机；

2)所有的交互命令都应在已经建立连接情况下进行；

3)请求命令和响应的交互时间应在设定时间范围内，即手机APP发送请求命令后，在设定时间范围内没有收到响应，应重新发送请求命令；

4)请求命令次数不超过5次，如果超过次数，应重新进行连接请求；

5)请求数据的命令个数由手机APP根据实际需求决定，请求故障码命令的个数由车辆当前存在的故障数决定，在请求故障码命令之前应先请求获取故障个数；

6)手机APP每次请求数据应是某一通道所对应的某一数据，如请求多个数据应发送多条请求命令；

7)由手机APP断开通信连接。

4.2通信协议命令格式

在该通信协议中，其命令包含约定值首帧0XAA与尾帧0X55、数据长度、命令标识符以及CRC校验位等，部分命令格式说明如表10所示。

表10　通信协议命令格式

4.3APP上位机显示

基于上述分析，本文作者实现了通过读取运行车辆OBD数据，采集车辆运行参数，并在手机上实时显示的功能。所实现的手机APP运行效果如图5所示。

图5　手机APP数据显示

在图5中显示的车辆运行数据，是通过手机APP发送请求命令，主控制器接收命令后，发出响应信号，两者握手成功。手机APP向主控制器发送请求数据命令；主控制器接收命令后，分析请求数据类型，通过CAN总线向OBD接口发送数据请求；主控制器接收到数据后，通过蓝牙模块发送给手机APP显示。由图4请求数据与表9计算结果可知，图5显示数据是正确的。这也验证了本设计方案的可行性。

5结论

本文的工作是以一款德系乘用车为试验车而进行的。在本文涉及的关于传输层协议TP2.0与应用层协议KWP2000协议中，首先对TP2.0协议通道建立过程、数据传输过程、错误处理进行了描述，然后对应用层协议KWP2000协议服务标识符的请求以及各个车辆运行参数、计算公式进行了说明，最后还对手机APP与主控制器通信协议的制定与命令格式进行了说明。通过以上OBD数据分析，实现了手机APP实时显示车速、发动机转速和油耗等车辆运行参数，对下一步车联网开发奠定了基础。

参考文献

[1]孙龙, 李孟良, 徐达，等.OBD技术的应用及其发展[J]. 汽车工程师, 2011(10):54.

[2]彭忆强, 黎薇.车载网络通讯协议软件自动诊断测试系统[J].中国测试技术, 2008, 34(2):24.

[3]李锐,王晶莹,姚燕,等. 基于ISO15765的车载CAN网络诊断设计[J]. 计算机工程,2012(4):35.

[4]OBD II Scan Tool：ANSI/SAE J1978-1998[S]. 1998.

[5]道路车辆诊断系统关键词协议2000第2部分:数据链路层：ISO 14230-2-1999[S].

[6]KWP2000 auf TP2.0[EB/OL]. [2015-01-05]. http://www.samtec.de/hauptmenu/unternehmen/eintrag.

[7]KeyWord-Protokoll 2000[EB/OL].[2015-01-05]. http://en.wikipedia.org/wiki/Keyword_Protocol_2000.

[8]周昊.基于CAN的TP协议及其应用[C]// 2007年中国汽车工程学会年会论文集.天津：[s.n], 2007:1015-1018.

[9]道路车辆诊断系统关键词协议2000 第3部分:应用层:ISO 14230-3-1999[S].

[10]史久根, 张培仁, 陈真勇. CAN现场总线系统设计技术[M]. 北京：国防工业出版社,2004:167-169.

[11]刘国权, 张伯英, 宋卫峰. KWP2000协议分析及开发测试[J]. 汽车技术, 2006(5): 7.

(编校：夏书林)

Real-time Data Acquisition System for Automobile Based on OBD and Andriod Application

XIE Jianghao1, PENG Yiqiang1*, HUANG Zhidong2,HUANG Deming2, REN Hongtao1

(1.SchoolofAutomobile&Transportation,XihuaUniversity,Chengdu610039China；2.ChengduI-techAutomotiveTechnologyCo.，Ltd,Neijiang641000China)

Abstract:To collect and display vehicle OBD data , a system schema is designed with MC9S12XEP100 microprocessor for data acquisition from OBD, and the Android application used as a mobile terminal for data display. For communication with OBD, the KWP2000 is used as service layer, TP2.0 as transport layer. The bi-directional communication channels are allocated dynamically according to the OSEK communication standard. CAN bus is used to transmit data between the controller and the OBD. With Bluetooth devices, the microprocessor is connected to Android APP to implement the data display. The testing results shown that the designed system is stable and reliable, and it can be as a foundation for the implementation of vehicle networking.

Keywords:TP2.0； OBD； KWP2000；APP；Android system

doi:10.3969/j.issn.1673-159X.2016.02.012

中图分类号：TN919.2；TP206.1

文献标志码：A

文章编号：1673-159X(2016)02-0061-6

*通信作者：彭忆强(1963—)，男，教授，博士，主要研究方向为汽车电子控制。E-mail:yqpeng@mail.xhu.edu.cn

基金项目：四川省科技支撑项目(2013GZ0129)；四川省高校科技创新团队项目(KYTD201003)。

收稿日期：2015-01-20

·新能源汽车与低碳运输·