阅读下文前，建议对OBD有初步了解，可阅读下面两篇：
上一篇博文提到了汽车内部的通讯方式，但是我们的程序是如何与OBD之间进行通讯的呢？
这里就涉及到两个问题：通讯方式和通讯协议。先上一张OBD安装在蒙迪欧致胜上的效果图：
对于大多数的OBD硬件来说，多采用蓝牙、WIFI、串口等几种方式。
下面看看几种模式在实际使用场景中，对于普通消费者的优缺点：
优点 缺点 蓝牙 可与智能手机连接，不占用智能手机网络信道 因为大部分用户的蓝牙功能是关闭的，用户可能会上车后可能忘记打开蓝牙 WIFI 可与智能手机连接，用户一般情况下会打开手机WIFI功能 由于智能手机连接OBD后，相当于构成个车内局域网，因此占用手机网络信道，不能上外网 串口 非常稳定， 适合作为检测设备 不可与智能手机连接
根据利弊分析，作为消费级的产品，采用串口作为通讯方式肯定是不行的。蓝牙和WIFI相比较，蓝牙模块的成本更低，更加稳定，因此优先选择蓝牙模块。我相信这也是为什么大多数的可穿戴设备选择蓝牙的原因。当然，在软件设计上，可以将蓝牙和WIFI虚拟成一个ICommunication接口，方便程序的扩展。本文不作重点讲述，以后会在Android蓝牙自动重连章节着重展开。
上文中对于OBD的通讯方式有了简要介绍，再进行通讯协议之前，我们先说说市面上的OBD吧。
市面上有众多OBD产品，最常用的是Elm327（便宜，淘宝上40几块，蓝牙的），当然还有EST527, XTool,国外还有好多，从几十到上千不等。为什么会有价格差别？
1.产品质量，所谓一分价钱一分货
2.软件支持，其他厂商的可以配合他们自己的硬件实现特有的软件服务，例如将OBD同保险和汽车维修服务挂钩。
3.硬件支持，其他厂商会增加GPS/GPRS/3G等模块，不需要智能手机，可以通过OBD硬件直接将数据传到后台。
但是我想做的是一个相对通用的开发者平台，尽量支持市面上的OBD硬件。一个厂商或者一个开发者的能力是有限的，降低开发门槛，提供最基础的SDK服务，发挥广大人民的想象力，开发出更多更实用的应用。
那么是否有这种可能性呢？答案是可能的。因为大部分的硬件厂商都是在Elm327上进行扩展，我们只要把Elm327吃透，支持一种新的设备也是很迅速的事情。
回归正题，那么OBD的通讯协议时怎样的呢，这里只做简单介绍。
OBD主要有下面九种服务，每一种服务都可以延伸很多东西，我们先着重关注服务1（Mode1)。
Mode 1: 请求动力系当前数据（发动机转速、速度、水温、油耗等数据）
Mode 2: 请求冻结祯数据
Mode 3: 请求排放相关的动力系诊断故障码
Mode 4: 清除/复位排放相关的诊断信息
Mode 5: 请求氧传感器监测测试结果
Mode 6: 请求非连续监测系统OBD测试结果
Mode 7: 请求连续监测系统OBD测试结果
Mode 8: 请求控制车载系统，测试或者部件（中国市场开发的OBD系统不支持该模式）
Mode 9: 读车辆和标定识别号
即使Mode1下真正能读取的数据远远不止下面这些，暂且说几个最常用的吧。
油耗系:读取动力系数据（瞬时油耗、当前油量）
引擎类（速度、发动机转速）
温度系(水温等数据）
故障码类（故障码个数，故障码详细，清除故障码等）。
这里是基础的基础，我们以CAN总线的OBD数据格式为例，其中ELM327也是采用这种数据格式。
ID表示CAN总线的ID；
PCI表示协议控制的信息数；
7 data bytes非常关键，表示Mode+PID，例如，如果是车速，那么这里就应该是01(Mode1) + 0D(车速)
Checksum:校验码
以获取水温为例：
发送：>01 05 (Mode1:01 动力系, PID:05 水温)
返回：41 05 7B
下面是返回的解释：
41=40+01,具体40是什么有点忘了,表示是从01 <Mode1返回的，05表示是PID05
7B转换成10进制为7*16 + 11 = 123 (华氏温度),
即123-40 = 83摄氏度。
哎哎，终于写完了，比较讨厌写这种纯技术类的文章，好累。
最后发一张正在开发的Android车机界面原型图，鼓励自己.
相关文章
