玩转车联网2--汽车内部通讯和车联网整体架构

上一篇博文提到了汽车内部的通讯方式，但是我们的程序是如何与OBD之间进行通讯的呢？

这里就涉及到两个问题：通讯方式和通讯协议。先上一张OBD安装在蒙迪欧致胜上的效果图：

1. 通讯方式

对于大多数的OBD硬件来说，多采用蓝牙、WIFI、串口等几种方式。

下面看看几种模式在实际使用场景中，对于普通消费者的优缺点：

	优点	缺点
蓝牙	可与智能手机连接，不占用智能手机网络信道	因为大部分用户的蓝牙功能是关闭的，用户可能会上车后可能忘记打开蓝牙
WIFI	可与智能手机连接，用户一般情况下会打开手机WIFI功能	由于智能手机连接OBD后，相当于构成个车内局域网，因此占用手机网络信道，不能上外网
串口	非常稳定，适合作为检测设备	不可与智能手机连接

　　根据利弊分析，作为消费级的产品，采用串口作为通讯方式肯定是不行的。蓝牙和WIFI相比较，蓝牙模块的成本更低，更加稳定，因此优先选择蓝牙模块。我相信这也是为什么大多数的可穿戴设备选择蓝牙的原因。当然，在软件设计上，可以将蓝牙和WIFI虚拟成一个ICommunication接口，方便程序的扩展。本文不作重点讲述，以后会在Android蓝牙自动重连章节着重展开。

2. 市面上的OBD

　　上文中对于OBD的通讯方式有了简要介绍，再进行通讯协议之前，我们先说说市面上的OBD吧。

市面上有众多OBD产品，最常用的是Elm327（便宜，淘宝上40几块，蓝牙的），当然还有EST527, XTool,国外还有好多，从几十到上千不等。为什么会有价格差别？

1.产品质量，所谓一分价钱一分货

2.软件支持，其他厂商的可以配合他们自己的硬件实现特有的软件服务，例如将OBD同保险和汽车维修服务挂钩。

3.硬件支持，其他厂商会增加GPS/GPRS/3G等模块，不需要智能手机，可以通过OBD硬件直接将数据传到后台。

但是我想做的是一个相对通用的开发者平台，尽量支持市面上的OBD硬件。一个厂商或者一个开发者的能力是有限的，降低开发门槛，提供最基础的SDK服务，发挥广大人民的想象力，开发出更多更实用的应用。

那么是否有这种可能性呢？答案是可能的。因为大部分的硬件厂商都是在Elm327上进行扩展，我们只要把Elm327吃透，支持一种新的设备也是很迅速的事情。

3. 通讯协议

回归正题，那么OBD的通讯协议时怎样的呢，这里只做简单介绍。

3.1 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下真正能读取的数据远远不止下面这些，暂且说几个最常用的吧。

油耗系:读取动力系数据（瞬时油耗、当前油量）

引擎类（速度、发动机转速）

温度系(水温等数据）

故障码类（故障码个数，故障码详细，清除故障码等）。

3.2. OBD数据协议格式

这里是基础的基础，我们以CAN总线的OBD数据格式为例，其中ELM327也是采用这种数据格式。

ID表示CAN总线的ID；

PCI表示协议控制的信息数；

7 data bytes非常关键，表示Mode+PID，例如，如果是车速，那么这里就应该是01(Mode1) + 0D(车速)

Checksum:校验码

3.3. 最简单的OBD消息交互---获取水温

以获取水温为例：

发送：>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车机界面原型图，鼓励自己.

posted on 2013-12-12 23:27 enjoyeclipse 阅读(8311) 评论(4) 编辑收藏举报

刷新页面返回顶部

enjoyeclipse

玩转车联网3---通讯方式和通讯协议

玩转车联网1---初识OBD和行车助手