|
因为CDD格式是一家德国公司（Vector）私有的一种数据库格式，在它的整个工具链（需求——功能实现——后期测试整个汽车电子V模型全流程）可以实现流通，保证整个流程数据的有效性和一致性。 但是对于整个行业的人，考量的是不会将所有鸡蛋全部放在一个篮子里，也不会让一家独大，达到垄断地位。因此关于诊断数据库国际上又有另外一种格式——ODX。
ISO开放式诊断数据交互——ODXODX—Open Diagnostic data eXchange（ISO 22901-1对该数据格式有着详细的定义）：起源是从2002年开始，ASAM组织的ODX工作组开始制定描述诊断数据的标准。关于ODX格式，发起者除了能够实现软件读取诊断信息外，还期望跨越工具边界，实现开放式的诊断数据库格式。在经历多个ASAM内部版本后，ODX标准第一版（ASAM ODX 2.0.0）于2004年发布。此后经过不断的完善， ISO组织于2008年收录ASAM ODX 2.2.0版本，正式发布ISO ODX标准——ISO 22901。当前汽车行业中常用的是ODX 2.0.1和ODX 2.2.0。ODX 2.0.1版本包含：
但对UDS的支持不够完善，缺少功能寻址、肯定响应抑制位、会话安全级状态机等内容。ODX 2.2.0不仅补充了缺失的内容，同时增加了ECU配置、车辆功能信息库等内容，更好地支持当前车辆的诊断现状。两个版本互不兼容，用户在使用ODX文件时需要确定使用的版本（所以用户在选择使用ODX数据库时需要明确使用的是那个版本）。
ODX2.2.0包含7层子模块：ODX-D和ODX-C描述诊断数据和服务，但ODX文件不仅可以描述单个ECU的诊断需求/数据，也可以描述整车所有ECU的诊断需求/数据；在ODX-D和ODX-C基础上，增加整车接口（ODX-V），可将整车数据打包成一个PDX工程；以上三个子模块也是诊断仪调用ODX文件实现诊断通信的基础模块。除诊断通信之外，在生产售后等阶段的诊断仪还需要具备ECU配置、刷写、车辆功能检测等功能。ODX-E描述ECU配置信息，方便下限工具快速抓取车辆产线下线所需要的所有的数据内容，而不用像以往，需要下线工程师根据下线配置表，每个车型（高中低不同配置）对应的配制内容后，在手动选取配制数据烧录到整车；ODX-F描述刷写数据，该数据（ODX-F）可以想象成一个容器，其内具体刷写数据还是Hex、S19、Bin等文件格式，只是在ODX-F这个容器中多了其他一些手段，比如增加Checksum、Signature等，保证刷写数据的完整性和有效性检验，增加了一道手段，保证ECU刷写的正确性；
ODX-FD描述面向功能的诊断信息库，从而满足生产售后的诊断应用需求。ODX是开放式的诊断数据交互格式，用户可以依据ISO相关标准开发参数化诊断仪，调用ODX文件实现诊断功能。同时，ODX对于整车级诊断通信的支持以及对生产售后的诊断应用的支持会更友好，所以ODX文件更多地被应用于OEM的工程、生产、售后等阶段的各种诊断仪中。反思其实关于CDD、ODX格式，其物理存在形式都是XML格式，只是行业先发者根据自己公司技术积累，基于不同协议按照不同的人机交互界面，形成了不同的数据库（用户看到的就是交互界面）。其实质就是诊断数据内容就摆在那里（XML根目录形式），就看哪家公司形成最好的人机交互界面让用户使用。 同样，先出发者（欧洲西方国家），凭借此，建立整个工具链圈（也相当于生态）。对于我国用户，只是使用者，并且使用后还离不开（他们卖的还死贵，总感觉在交智商税，这种情形不但是汽车行业，医药、工业控制软件皆如此）。形成的生态，构造了很高的技术护城河，让后来者只是使用者。不是说这样不好，业务嘛，术有专攻精于某一处，但是国家之间，没有永恒的朋友，只有永恒的利益，因此还是要有Plan B。 自己也一直在想，怎么摆脱这个困局，在读的您有啥好想法吗？
愿你我相信时间的力量， 做一个长期主义者！ ----------------------------------- 作者简介 | 穿拖鞋的汉子 汽车电子工程师 |
|
|
