ODX – 车辆开放式诊断数据交换协议

0.0 写在前面

ODX 其实已经问世很多年了，最早是在 2000 年由 ASAM 开始制定的。在 2008 年，一个新的 ODX 版本正式面世，它被定义在 ISO 22901-1:2008 标准中，也就是被业内熟知的名字：ODX 2.2.0。现阶段很多汽车行业的 OEM 和供应商已经开始逐步支持 ODX ，但 ODX 的灵活性也导致了各家产生自家的一些 ODX “方言”。在我国国内，从知网上搜索结果来看，早在 2010 年就有相关文献介绍 ODX。这十年间，ODX 的推进速度并不快。就像汽车行业很多方面一样，在传统车企推进 ODX 的应用好比“大象转身”，贸然 ODX 可能会导致一些意想不到的问题。

但是，ODX 解决了行业内数据交换的诸多痛点，它可以提高诊断质量，必定是未来车辆诊断行业主要数据交换方式。深入了解 ODX 是很有意义的。

笔者撰写本文的原因一是为了同行交流，二是为了自己学习。很多内容是来自 ISO22901-1 中。文中的一些观点可能并不成熟，若有异见欢迎提出。本文会在每周末更新。

若需转载本文，或有任何疑问，请联系邮箱：i@never84.com。

0.1 什么是 ODX？

ODX = Open Diagnostic Data Exchange，中文名：（车辆）开放式诊断数据交换协议。

制定者：ASAM (Association for Standardisation of Automation and Measuring Systems) 自动化及测量系统标准协会。

0.2 为什么 ODX?

ODX 出现之前，OEM 各部门之间或与供应商之间交换诊断数据通常是以微软的 OFFICE 格式或 PDF 格式。诊断数据没有一个统一的数据格式。这导致了一下几个痛点：

• 没有统一的数据格式，诊断数据不好管理；
• 阅读、查找有效诊断数据时，需要花时间成本去理解文档格式；
• 在车辆生命周期各阶段中的诊断程序开发者，需要手动将诊断数据维护到诊断程序之中，这既是一个耗时的工作，也会导致一些人为失误。

因此，在各阶段的诊断开发中，亟需一种统一的、可在各诊断平台之间重用的标准，来规范诊断数据的交换。

在这样的背景之下，ODX 应运而生。

0.3 谁在应用 ODX？

宝马、大众等 ASAM 核心成员已经在使用 ODX。越来越多的国内外 OEM 在转型 ODX 的过程中，如捷豹路虎、吉利、上汽等。国内的造车新势力如蔚来、小鹏都在使用 ODX。

供应商方面，Vector 和 Softing 都有完整的 ODX 解决方案。EOL / 售后诊断方案供应商 Bosch、DSA、Actia 都支持 ODX，

0.4 ODX 有什么内容？

ODX 数据模型中，包含以下六大类数据：

• ECU 诊断通讯用到的的协议
• ECU 软件中定义的各协议的数据链路层相关通讯参数
• ECU 的刷写相关数据
• 车辆接口描述（Connector 及相关引脚定义）
• 各 ECU 的具体诊断功能描述
• ECU 的配置参数（variant coding）

车辆诊断通讯中需要的所有信息在 ODX 数据模型都有所包含。

0.5 ODX 应用案例

阶段 A：在车辆开发过程中，整车 OEM 与 ECU 供应商通过交换 ODX 文件来开发 ECU 诊断功能和对应的调试工具。

阶段 B：在车辆的生产阶段，OEM 将 ODX 文件释放给 EOL 工程部门或供应厂商，用于生产中的 EOL 测试。

阶段 C：在车辆的售后阶段，OEM 将 ODX 文件释放给售后工程部门或供应厂商，用于售后服务中的诊断测试。

0.6 ODX 存储格式

ODX 文件都是以 XML 格式存储的。

ODX 的具体格式会在下文中详述。

0.7 如何制作 ODX？

使用 ODX Authoring 工具，通过 UML 类图建模，再映射成 ODX 文件。

0.8 ODX 相关协议介绍

ODX 标准也就是 ISO22901-1， 其实是 ASAM 推出车辆诊断一系列协议栈的一部分。

先介绍 ASAM 标准中的一个高频使用的缩写：

• MCD = Measurement, Calibration & Diagnostic

ASAM 车辆诊断协议栈中与 ODX 相关的有：

• ASAM MCD-2 D 即 ODX ASAM 链接
• ASAM MAC-3 D ASAM 链接

需要指出的是，ASAM 不是 ISO。ASAM 的标准被 ISO 吸纳为国际标准，但并不意味着 ASAM 标准就是 ISO 标准。ISO 与 ASAM 的关系在 此链接 可以发现。

在 ISO 标准中，ODX 是 MVCI (Modular Vehicle Communication Interface) 系列协议的一部分。MVCI 系列协议栈包括：

• ISO 22900-1:2008 Road vehicles — Modular vehicle communication interface (MVCI) — Part 1: Hardware design requirements
• ISO 22900-2:2017 Road vehicles — Modular vehicle communication interface (MVCI) — Part 2: Diagnostic protocol data unit (D-PDU API)
• ISO 22900-3:2012 Road vehicles — Modular vehicle communication interface (MVCI) — Part 3: Diagnostic server application programming interface (D-Server API)
• ISO 22901-1:2008 Road vehicles — Open diagnostic data exchange (ODX) — Part 1: Data model specification

综上所述，ISO 22901-1 与 ASAM MCD-2 D 是描述 ODX 协议的通行标准。

0.9 PDX

PDX 包是交换 ODX 文件的一个容器。所有的 ODX 文件都可以打包成一个 PDX 包。一个 PDX 包可以包含以下几种 ODX 文件。

• odx-c, odx-cs (for COMPARAM-SPEC, COMPARAM-SUBSET);
• odx-d (for DIAG-LAYER-CONTAINER);
• odx-e (for ECU-CONFIG);
• odx-f (for FLASH);
• odx-fd (for FUNCTION-DICTIONARY);
• odx-m (for MULTIPLE-ECU-JOB-SPEC);
• odx-v (for VEHICLE-INFORMATION-SPEC);
• odx (alternatively all the files containing ODX data can use the extension “odx” lesser restrictive).
• PDX 包中可以不仅包含 odx 数据，还可以包含文本、图片或者任意格式的其他文件。

1.0 UML (统一建模语言)

UML = Unified Modeling Language 统一建模语言

UML 在 ODX 中非常重要。它被用于定义 ODX 的数据模型。在 ISO_22901-1 中介绍了 UML，我在这边把相对重要的内容照猫画虎介绍一下。

类：在 UML 中类使用一个长方形来表示。长方形中自上而下有三个字段，最上面的字段定义类的名字，中间字段定义类的属性，下方字段定义类的方法。在ODX中不会使用类的方法，所以类的只会有上下两个字段。在 ODX 文件中，类名和属性名称都是大写的。

继承：类可以继承别的类的属性，并且可以在此基础上添加自己的属性。下图中的 SCHOOLKID 继承指 PERSON 类，并且增加了一个属性 “GRADE”。在 UML 中，使用【实线空三角箭头】代表继承关系。

Aggregation(聚合)：类和类之间还可能存在聚合关系。聚合关系可以理解为 “has a”。比如人和鞋子之间的关系。人拥有鞋子，但人消失后，鞋子不会跟着消失。聚合关系使用【空心菱形】表示。

Composition(组合)：组合关系和聚合关系很容易混淆。组合关系可以理解为“part of”，代表a类是b类“不可分割”的一部分。如人和脚的关系，脚是人的不可分割的一部分，如果人消失了，脚也就不存在了。组合关系使用【实心菱形】表示。

Association(关联)：关联关系相对于组合和聚合更弱。属于关联关系的两个类是有着同等权限的。受关联的双方是可以看到对方的属性的。如下图中，PERSON是SCHOOLKID是有关联的，PERSON 的 Role 是 SCHOOLKID 的妈妈，在这里可以用实线表示，并且标识出角色关系。关联关系是可以带箭头的，从而限定哪一方有接触到对方属性的权限。

Association Classes (关联类)：关联类是关联和类的结合，它可以用来描述关联带来的属性。如下如，Person 与 Employer 的关联是雇主关系，这个关系中有一个属性叫做 SALARY。SALARY 不是雇主 Person 的属性，也不是雇员 Employer 的属性。Salary 最好是 Employed 这个关系的属性。

Interfaces (接口)：接口能够让某一个类的属性能够被其它的类获取到。接口是一种特殊的方式，能够让一个类的某些方面属性被其他的类所依赖，而不是像继承一样依赖于这个类的所有属性。下图中包含着一个接口如何使用的例子。COMPANY 这个类有着两个接口： EMPLOYEE 和 COMPETITOR。一个被 COMPANY 雇佣的 EMPLOYER 看不到 COMPETITOR，COMPANY 的 COMPETITOR 也看不到这个 COMPANY 的 EMPLOYER。在 UML 中使用【虚线空三角箭头】 来表示接口。

Constraints (限制): UML 也可以定义限制。一个常用的限制就是两个聚合或关联之间的异或 (XOR) 关系。下图展示了 Constraints 的一个例子，一个人只能穿 BOOT 或者 SHOE，而不能同时穿两种鞋子。

1.1 UML 映射至 XML

<EXAMPLE>
    <PERSON ID="ID_64711" AGE="33" xsi:type="PERSON">
        <NAME>Jack O. Trades</NAME>
        <PROFESSION> All Duty Service Technician </PROFESSION>
        <COAT>Gucci</COAT>
        <FOOT SIZE="8"></FOOT>
        <FOOT SIZE ="9"></FOOT>
    </PERSON>
    <PERSON ID="ID_60815" AGE = "8" xsi:type="SCHOOLKID" GRADE="3">
        <NAME>Kevin</NAME>
        <FOOT SIZE="5"></FOOT>
        <FOOT SIZE="5"></FOOT>
        <FATHER-REF ID-REF="ID_64711"></FATHER-REF>
    </PERSON>
</EXAMPLE>

看懂了 UML 即其对应 XML 的映射关系，就能理解 ISO-22901-1 协议中的 UML 图了。

2.1 ODX 数据模型 – 通用成员

SHORT-NAME 定义一个 ODX 对象，最长可以有 128 个字符。一个 Short name 可以由字母，数字和下划线组成 （[a-zA-Z0-9_]+）。

LONG-NAME 定义 ODX 对象的简短功能描述，最长可以有 255 个字符。人机界面上显示的是 LONG-NAME 而不是 SHORT-NAME。

DESC 描述了 ODX 对象详细的功能信息。没有长度限制。这个 element 是可选的，并且支持 html 标记。

LONG-NAME 和 DESC 都支持一个可选的成员 TI (Text Identifier) 来支持多语言。TI 还可以支持链接到外部的文件。

ELEMENT-ID 是一个通用类型来代表在 ODX 数据模型中的上述成员。上述成员中还有一个通用的属性 HANDLE 。

ID 是一个用来链接 “odxlink” 的标识。在一个 ODX 项目中，ID 是唯一的。因此 ISO22901 推荐使用 UUID。

2.2 ODX 通用对象

SDG 是 Special Data Group 的缩写，顾名思义，特殊数据组。它用于定义在 ODX 标准数据模型中没有定义的数据类型。SI 是 Semantic Information 的缩写，它用于定义 SDG 中的信息，是 SDG 的成员。

<SDGS>
<SDG>
<SDG-CAPTION ID = "id123">
<SHORT-NAME>properties</SHORT-NAME>
<LONG-NAME>A table of key-value pairs</LONG-NAME>
</SDG-CAPTION>
<SD SI = "part-number">4711</SD>
<SD SI = "index">007</SD>
<SD SI = "SAP-number">1234567</SD>
</SDG>
</SDGS>