一个读取 ECU 数据请求的 ODX 之旅

ODX的结构是复杂的，基本的背景介绍可参考此篇文章：

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

本文以一个读取 ECU Data ID 的请求为例，探寻解析 ODX 文件的过程，帮助读者更好的理解 ODX 结构。

这个基本请求的原始报文如下。（p.s.若读者不能理解如下报文的含义，则需先了解 UDS 诊断协议）

TX：22 F1 00
RX：62 F1 00 B1 B2 B3 B4 B5 B6 B7 B8 B9 B0 B1 B2 B3 B4 B5 B6

诊断设备的在解析 ODX 的过程中，入口往往是 odx-v。在官方标准中，odx-v 用于定义 VEHICLE-INFORMATION-SPEC ，即车辆信息参数。

在 odx-v 中，我们能够找到<LOGICAL-LINK>节点。每一个 LOGICAL-LINK 即一个 ECU，当然一辆车会有多个 ECU。

在这里有两个 REF，PROTOCOL-REF 和 BASE-VARIANT-REF。在 ISO-22901 中，有以下5个概念较为重要：

Protocol，如ISO-15765
Functional-Group，通过功能寻址来控制的诊断内容，如对门系统进行控制。
ECU-Shared-Data，用于提供诊断 Lib，如全局定义的 PID
Base-Variant (BV)，用于定义不同类别的 ECU，如 BCM 和 DCM
Ecu-Variant (EV)，各 ECU 类别下的不同 Variant 或配置，如 BCM-v1，BCM-v2，DCM-v1。

关于这些定义的概念，在 ODX 协议中有一张图非常有助于理解。

实际上，这 5 个概念中的 4 个（除了 ECU-Shared-Data ）存在着继承关系。如下图，EV 继承 BV 继承 Functional 继承 Protocol。

而在 ODX 文件系统中，这 5 个概念的信息都在 odx-d 中。

回到 odx-v ，我们知道 BCM 有两个 ref，分别为 PROTOCOL-REF 和 BASE-VARIANT-REF。

ROTOCOL-REF 就是索引到 PROTOCOL 层。找到对应的 ID，我们可以看到该 ECU 关于以太网诊断的协议内容都定义在这里，它实际上索引了 odx-cs 文件。

有了通讯协议，就可以执行实际的诊断指令了。在发出诊断指令之前，我们首先需要知道网关（对于 DoIP）和 ECU 的地址，这就需要跳转到 BV 文件了。

有了具体的 ECU 地址，我们就可以发起具体的诊断服务了。大名鼎鼎的 DIAG-SERVICE 便要登场了。

ISO-22901 的官方文档里说到，DIAG-SERVICE 是理解 DiagLayerContainer 即 odx-d 很好的开始。 DIAG-SERVICE 和 UDS 的诊断服务是强关联的，熟悉诊断的有关人士很容易理解其概念。

DIAG-SERVICE 可以在任意的 odx-d 文件中，这意味着 Protocol、Functional Group、ECU Shared Data、BV、EV中都可能会有 DIAG-SERVICE，因此 DIAG-SERVICE 会被层层继承（除非这个 Service 被定义在 NOT-INHERITED-DIAG-COMM 里）。

如下图，我们来具体看一个 DIAG-SERVICE，这个 DIAG-SERVICE 在 Protocol 层。它下面定义了 REQUEST-REF 和 POS-RESPONSE-REFS，分别对应着请求和正响应。

根据 REQUEST-REF，我们可以找到请求的具体诊断报文。ODX 中的 Byte 都是以十进制数字存储的，比如下面的 PARAM SID 值为 34，实际就是服务 0x22。而 DID 的值是 61696，对应的 Byte 就是 0xF100。将 SID 于 DID 组合，就得到了诊断请求报文 22 F1 00。

根据 POS-RESPONSE-REFS，这个请求对应的正响应也能够找到。在下图中，PARAM SIDPR就是回复报文的第一个字节，十进制 98 就是字节 0x62 (0x22 的正响应)。而后面的 DID 可根据 xsi:type=”MATCHING-REQUEST-PARAM” 知道其与请求的 DID 一致，也就是 0xF100。