从ODX（Open diagnostic Data eXchange）谈车联网应用绕不开的底层网络“基建”

前言：“车联网应用代表着资本的下一个风口，也是汽车电子技术竞争的重要角斗场。但与其谈些美妙的应用设想，不妨构想下让为这些应用成为现实的“基建工程”，即真正地让车和外部通信连接的网络系统。”

高级辅助驾驶、智能驾驶乃至无人驾驶等应用层的概念推陈出现，让汽车行业成为当下诸多新技术的角斗场。工信部在2017年年初提出“智能网联汽车”产业标准体系的征求意见稿。摘录官方定义，智能网联汽车是指搭载先进的车载传感器、控制器、执行器等装置，并融合现代通信与网络技术，实现车与人、车、路、云端等智能信息交换和共享，具备复杂环境感知、智能决策、协同控制等功能，可实现”安全、高效、舒适、节能“，并最终可实现替代人来操作的新一代汽车。

Fig.1 车和多网（人、车、路、云端）连接示意图（图片转自这里）
谈到智能网联汽车，首先需要的便是理清楚车联网和移动互联网的区别，事实上当下很多挂着车联网的应用其实只是一种“泛化”的移动互联网，如很多公司试图通过OBD（车载在线诊断）场景作为车联网切入点，如腾讯路宝（VCI盒子<–蓝牙或wifi–>手机APP）、还有通过地图导航的强应用需求场景切入的，如阿里智驾盒子，以为LBS服务场景提供入口。

Fig.2 当下主流的车联网“浅层应用”场景（图片转自这里）
相比于移动互联网提供的数据异地存储带来的“浅层应用”，OEM厂商要的车联网是把车和网络（互联网、交通路网、地图等）打通，要的是车身数据全部完整的上网，不仅可以收集车身数据还要可以根据汽车的传感器数据实现双向控制汽车的执行器。一言以蔽之，车联网的网络拓扑更强调的是收集数据后，外部数据处理端可以对车身提供新的控制逻辑输入，只有新的控制逻辑输入才是“深层应用”（如ADAS，主被动安全控制系统等），而非当下的行车记录仪、驾驶行为记录仪、燃油液位提示APP等车身部分数据异地存储的“泛化”移动互联网。戏谑点的说法可以是，国内目前热炒的车联网概念是走娱乐化路线（充其量车载多媒体娱乐系统），而国外同行们走的路线就更偏向技术干货了（eg. 戴姆勒的自动驾驶卡车，奥迪的自动出库入库Connect系统，Volvo行进中邻域车辆通信）。总结来说，国内当下的车联网技术无非是在OBD接口上加装一套信息收集系统，经过浅层的逻辑处理，通过手机或是中控屏予以显示的路线，而不切入CAN总线，不切入车辆内部通信内网和控制逻辑闭环的车联网都是伪概念。

Fig.3 Audi Connect

应用层设想虽美，但那也是需要建立在掌握车身全方位数据的基础上，可是单纯想靠OBD这一被阉割的数据接口+VCI蓝牙盒子+手机移动端的后装套路显然显得内功不够。相比于以OBD接口切入走移动汽车互联网的处理方式，OEM更多地叫这汽车联网服务，MCD（测量、标定和诊断）全场景的引入才是真正的车联网。车联网应用要想走向技术路线，作为物理层以及传输层的”管道基建“成为无法绕过去的技术难点。

考虑到国产汽车行业的现状，企业间数据编写方式不一（人为筑起的低级壁垒just make some non-generality protocols ）、企业内部数据复用程度低(R&D、制造、售后各角色手中数据虽为一物，但格式千奇百怪），并且由于国内车辆传感器数量较少的现状，使得服务功能空间有限，导致很多企业在短期内采用的数据管理方式极为静态，直肠子遍历是常态，但依旧可以有效地应付过去。可面对未来将要爆发的功能场景带来数据维度爆炸，传统的静态数据管理方式显然不可能经受住考验。（国内外的商用车传感器数量甚至差一个数量级，其实某种程度上，国内工业其它领域也是如此，如果说”智能化+网联化”是未来发展方向，实现工业数字化才是当下关键，故国内工业嵌入式开发应该会迎来机遇）

国内车企都意识到硬件上国内车辆内部网络过于简单、控制策略上缺乏核心的控制技术、工业软件自主化程度低又是国内工业领域的通病。按照未来无可避免的硬件架构复杂化（自主品牌要和国际品牌竞争，各种传感器、控制器都会上），国内车联网发展的路线基本有一下几条：1.前装市场主导，以车企为主导，和上下游供应商紧密配合，走定制化的软硬件紧密结合的路线；2.后装市场主导，以诊断厂商、想入场的互联网公司为主导，如腾讯路宝。显然大家都想走第一条路，把控制权掌握在自己手中，但是受限于国内厂商自身的软硬件整合能力现状，你懂得，心有余而力不足；而走第二条路，后装市场主导，信息链过长，同时车企话语权需要和其他角色分享，故障诊断服务市场长期受制于诊断仪厂商（软硬件由第三方诊断仪厂商整合），又让车企根本不想再走这条说不清理不清的合作路线。

那怎么办呢？显然不能不做，那有第三条路吗？把目光放远一点，看看汽车行业的鼻祖欧美市场的发展路线，很多情况下答案就自然出现了。毕竟师夷长技以制夷，以汽车领域最有话语权的德国为首在21世纪初便提出了ODX(open data diagnostic exchange)数据管理的统一方式，成为国内目前业界主流的下一代数据编写方式。ODX+MCD-server+MVCI的模块化设计框架让功能清晰分层，软硬件功能分离。对于核心的数据控制权通过车企自主编写适合自身产品的针对XML配置文件来实现，ODX编写协议和主流软件乃至解析软件虽然都是欧美大佬老早就占据了，但是好歹这种方式可以让车企把最为关键的数据控制权掌握在自己手中，server软件和MVCI硬件可采用第三方产品，自主组合。多害相较取其轻，可能是当下国内车联网发展不得不面对的现状。

ODX采用IT行业常见的多层抽象迭代的方式对繁杂但重复度高的车用数据进行分层，解决了数据复用度低的现状，并且数据更改维护复杂度都得到极大改善，减轻车企的数据维护压力。但是欧美大佬显然不会拱手相赠这么棒棒的设计理念，ODX毕竟是用在汽车这一敏感的对象上，加解密、权限认证、功能敏感性分级、故障应急等等诸多措施都需要在数据编辑端便进行干预，并且ODX数据分层抽象层次较深，数据结构的粒度差异极大，想想你就知道这里面的软件逻辑复杂度绝非一般的难度，更不说如何将车辆内部通信网络的安全性设计组合进来。尴尬的现状是国内懂车的车企少有能开发这种难度级别的软件能力，懂软件的公司又不懂车，而这两角色都想在车联网中占有主导地位，结果……虽然整个看下来，“模块化设计，软硬件分离”原则可以保留核心的数据控制权在车企手中，让国内车企可以在后期的车联网应用中拥有较为主导的地位，但是按照欧美大佬设计的技术套路走下去，光是攒这一套完整的工具链就已经是把该交的学费，也是一次性给交上去了，或许只多不少。下一篇文章来谈谈ODX数据解析的一些技术方案吧。