1.OBD国内现有实现方案分析
OBD-Ⅱ在线诊断系统的一个最大的特点就是统一了数据传输协议和诊断模式。但OBD-Ⅱ标准中并不止规定了一种通信协议，而是统一了应用最广泛的几种协议。分别为：CAN、ISO 9141、KWP2000、SAEJ 1850（PWM）、SAEJ 1850（VPW）。
房车改装图片依据是否自己开发这几种协议的底层，可把现有系统分为自开发协议版、应用现有协议转换芯片版。
1.1.自开发协议版
所谓自开发协议版，就是开发人员通过通用单片机（ARM9、PIC单片机等）去实现OBD这五种协议，主要工作为读懂这几种协议的读写时序，并在单片机上实现。
国内采用这种开发方式的主要有山寨版的OBD车载检测仪（100元左右的）和专业做汽车电脑故障诊断仪的公司，像金德、元征、爱夫卡等。不过他们采用这种方式的原因则大不相同：
山寨版的OBD车载检测仪用廉价的通用单片机去实现OBD的协议，从而省下昂贵的协议转换芯片费用，同时把数据的输出格式做成与现有的协议转换芯片一致的格式，让消费者可以直接用免费的通用的检测软件。
下图显示一个拆开的山寨版OBD汽车检测仪：
而专业做汽车故障诊断的公司，则会把这个借口做的巨烦无比，因为他们要考虑到各个汽车厂商在OBD-Ⅱ标准接口上的厂商自定义的几个针脚，
而汽车厂商通常都会超出OBD-Ⅱ协议，定义自有协议和读解码方式；他们一般会购买各个汽车厂商的这些资料，从而做更复杂的诸如诊断等上层开发。
下图为爱夫卡某款汽车故障诊断仪的OBD接口电路：
1.2.应用现有协议转换芯片版
应用现有的协议转换芯片，就是将汽车总线各种协议的数据通过现有的芯片转换为串口格式的数据进行发送和接收，开发过程可以免受众多
协议读写时序的折磨，从而转注于汽车故障码的解释及故障检测专家系统的研发。
协议转换芯片的工作框图如下所示：
国内外做的比较好的协议转换芯片主要有ELM327、TL718、XT78。
ELM327是加拿大elmelectronics公长安新豹
司开发的协议转换芯片，也是市场上出
现得最早的协议转换芯片，它有很完善
的电脑端软件与之对应；国内山寨版的
OBD车载检测仪都是以它为蓝本的，可
以见到外观上标有ELM327，可拆开里面
并没有这个芯片。
左图为用ELM327芯片的OBD车载
检测仪，它采用的串口与电脑通信，并
风云2汽车论坛没有内置蓝牙芯片。
TL718则是海口鑫工电子有限公司开发的
山寨汽车
另外一款协议转换芯片，其部分指令与
ELM327兼容，并增加了部分功能以及好一些
协议，比如说它可以通过自带的串口直接升kn空滤
级固件；增加了KW1281等协议，能更好的
兼容各个品牌各个型号的汽车；同时还增加
了多条AT指令，可对OBD协议进行扩展使用，
使TL718附合大部分厂商专用的OBD诊断。
左图为采用TL718芯片的车载OBD检测
仪，它采用USB或串口与电脑通信，同样没
有内置蓝牙芯片。
2.本平台拟采用方案
从以上分析，我们可以了解到：
专业做汽车故障诊断的公司的那种方案旨在诊断一部汽车的所有故障信息，而我们的开发平台不会过多涉及OBD2协议以外的内容。
其余三种方案的核心思想都来自ELM327，即将OBD的各种协议转成一种通用的协议（比如串口）与上位机通信，区别只在于是自己转换这个协议还是用现成的协议转换芯片、用ELM327还是用TL718。
与上位机的通信方面，我们的平台需要与手机通信，所以必定选择蓝牙无疑，由于蓝牙所用频率比较高，PCB自己布线要求较高，拟采用现成的蓝牙转串口模块，这种模块可以直接把蓝牙转成串口，而且成本也不高，这点与山寨版的OBD汽车故障诊断仪相似。
汽车维修保养连锁店至于软件方面，可以依据章节1中的分类把所需开发的软件分为两类，OBD通讯协议转换以及上位机（电脑、手机）应用软件。如果采用章节1.1 自开发协议的方式，则上述的两种软件都要开发；若采用章节1.2 应用现有协议转换芯片的方式，则只需开发上位机应用软件，这无疑是一个大大地减少工作量的好方法，不过其代价是需要支付昂贵的协议转换芯片成本。对于上位机软件，常用的DiagRa、VGA-COM、ScanTool、ScanMaster 等，其中VGA-COM 支持一些特殊的开发功能，可以读取某些车型的远远多于OBD2要求的丰富的参数，可以完全替代价格不菲的专业诊断仪。后面两种为共享软件，特别地，ScanTool不仅仅是一个标准的OBD2软件，还可以在网上下载到其源码，方便进行二次开发。
3.汽车总里程数读取解决方案之初步设想
平台对汽车总里程数这一数据有着强烈的需求，而此数据在标准OBD协议中并无涉及，通过查询相关
资料，在此对此数据的读取解决方案作如下初步设想：
1）、OBD-Ⅱ的标准ISO15031-4中标定了两个与距离有关的参数：OBD-Ⅱ诊断模式一：动态数据获取下：
PID 21: Distance travelled while MIL is activated(故障灯亮后已行驶距离)
PID 31: Distance travelled since DTCs cleared(故障码清除后已行驶距离)
如果能合理得利用好这两个里程数据，再加上第一次安装OBD 诊断系统时候设置的已行驶里程，估计可以准确地得到汽车总里程这一参数。
这种方案需要在每台OBD设备第一次安装到汽车上时，设置当时汽车已行驶里程，更大的难点的是需要在协议转换芯片上编写算法计算当前汽车已行驶里程数，并保存在ROM上，以防止掉电丢失数据。
2）、监听OBD-Ⅱ总线，对比、分析数据，获取OBD-Ⅱ协议内厂商自定义的已行驶里程数据
具体过程是通过截获通用诊断仪（eg：元征的X431或VAG-COM，CarSoft之类的诊断软件）和车辆通讯的全部数据信息，并与通用诊断仪上显示的数据相比较，从而得到专用指令的数据结构，并用调试软件直接测试该功能而快速验证。
这种方案的基础是通用诊断仪能查到车辆的已行驶总里程数；其关键是数据的对比分析过程，通常采用变更车辆的运行状态，出数据的变化规律，不过此方法只能出一部分的数据规律，其中有没有已行驶总里程数还是个未知数，专业的方法是根据监听到的指令自己仿真ECU工作，进行各种测试，这样可以得到诊断仪的全部功能数据，不过仿真ECU工作也不是一件简单的事情。
3）、购买厂商的协议
这不仅仅包括厂商OBD协议的扩展，还包括汽车仪表系统等，用这种方案的话肯定是100%可以得到汽车已行驶的总里程数，不过缺点也是非常明显的：各个厂商的协议都价格不菲，而协议中我们用到的数据并不多，这个投入似乎并不值得。
4）、添加一些传感器从而得到已行驶里程数
还没到有合适的传感器。或者GPS可以考虑！
By Drawind
2011.4.28