鲁达
没错，OBD是当前切入“车联网”的一个捷径。但是，这个大多数人都找不到的16针接口，终究只是一个过渡手段。
在今年的北京车展上，奇瑞首发了Inhand CloudDrive智能行车方案，成为第一家推出OBD智能硬件的汽车制造商。相比第三方开发者，奇瑞的脚步晚了很多，但作为汽车领域的“正规军”，它的涉入让OBD硬件这个领域出现了新的沸点。
OBD智能硬件迎来新的沸点
OBD本来的目的有两个，一是为维修人员提供检测接口，二是用来测定排放标准。无论是维修，还是环保，OBD在功能上都是将车辆的ECU参数输出到外接设备。于是，以Automatic、ClickDrive、Dash为代表很多硬件，瞅准了OBD这个入口，借助智能手机的数据流量和数据运算能力，打出了智能、经济、环保用车等多张牌。
国内的试水者也有不少，比如智信通、Golo、摩铠等。不过，这些硬件在原理和功能上都大同小异，同质化非常严重。除了名字不一样，这些硬件在造型上也没有太多新的花样，缺乏优秀的工业设计（包括硬件和App）。
这些OBD硬件大致可以分为两类：一类是只发放给个人用户的，帮助他们自助诊断车况、更安全、经济地驾驶等；另一类是发放给经销商，再由经销商转发给车主，可以在两者之间搭建一个信息沟通渠道，比如当车辆出现隐患时，有实时监控数据的经销商就会及时通知车主。
相对来说，后者在适用性上更加普及一些，也更适合涉及安全问题的场景。而前者，相信大多数车主不会经常去查看自己车辆的发动机参数，他们更关注的是行驶轨迹、里程等与油耗相关的数据。
主机厂与第三方开发者：谁有资格为OBD硬件代言？
奇瑞这次推出的 Inhand CloudDrive，则属于前一类。与那些通用的第三方硬件相比，奇瑞的产品只适用于奇瑞车型，并且不会开放给其他品牌。北京车展期间，我在奇瑞展台试用了Inhand CloudDrive的App，但并没有见到实体的OBD硬件。
据了解，奇瑞Inhand CloudDrive是由上海博泰参与开发的。其中，博泰网络承接了App的开发，而博泰电子则承接了OBD硬件的生产。整体上，奇瑞搭建了框架，博泰负责提供平台与云服务。
这一产品的出现，让目前正火热的OBD智能硬件领域新增了一个沸点。同时也带出了一个问题：这种OBD智能硬件，是该由奇瑞这样的主机厂生产，还是应该改由Automatic这样的第三方开发者推出？
其实，两者也有优势劣势。首先，对于最早发现这个“捷径”的第三方开发者来说，他们面临的最大问题有两个：一是如何破解特定车型的PIN码；二是如何分销。其中，PIN码的破解直接关系到开发者能否读取到某款车型的OBD私有协议。如果失败，那么一些重要的ECU参数，如刹车片的情况等就无法抓取出来。
问题在于，主机厂设定的PIN码，每年都会改变。这就要求第三方开发者创建一个解码库，在读取某辆车时，先通过其VIN码判定车型的具体型号与年代，然后调取相应的解码器来读取。不然，第三方开发者的OBD硬件就只能读取开放的OBD公有协议。
而由整车厂商自己推出的OBD硬件，则预先设置好了自家车型的OBD私有协议，无需破解工作。
但问题还是存在。整车厂商的思维速度往往跟不上互联网发展的节奏。在用户体验和工业设计上，虽然不能完全否决汽车公司的水平，但第三方开发者作为从互联网这一端思考问题的一群人，他们在产品理念上的进步性观点，还是值得汽车厂商借鉴的。比如，奇瑞的Inhand CloudDrive，在功能设计上明显能看出十分机械化的思维逻辑，一味的追求大而全（集诊断、呼叫中心与社交于一体），却忽略了用户真正的痛点在哪里。
从这个角度说，汽车厂商与第三方开发者之间的关系，今后应该是协同的，而不是完全的对立。
不要过分抬高OBD硬件，它只是一个过渡
本文开头提了一个观点，即基于OBD的“车联网”只是一个过渡。那未来的形态是怎样的？毫无疑问，答案在云端。
想想OBD诞生的初衷，如果汽车的CAN总线可以由一个联网的高度集成的芯片控制，那么车辆ECU的信息就可以直接传输到云服务器，而无需从OBD接口导出。更进一步，当CAN总线被以太网替代，汽车变成实质意义上的移动终端，所有的ECU信息就可以直接发送至云端。这个时候，还需要费力地在OBD接口上外接一个硬件吗？
所以，未来的车辆诊断模式，将是云诊断。车辆实时联网，出现任何安全问题，都会像民航客机上的ACARS系统那样，实时向总机发回数据报告。至于车辆的行驶轨迹、里程，以及油料等情况，不但能实时查看，还可以结合大数据进行综合对比、预测与分析。
当前看来，OBD是“车联网”的一个捷径，而OBD智能硬件也将迎来一次爆发期。随着汽车厂商的介入，这个领域又一次开始沸腾。
不过，在我看来奇瑞的Inhand CloudDrive并未做出新意。给人的感觉，就像是一个大企业典型的跟风之作。估计，这个产品对于奇瑞来说，科技象征意义要远大于实用价值。