文章目录

 

---

前言

车载诊断现阶段应用的诊断数据库大体分为三种：

CDD（Vector私有格式）；

ODX全球通用诊断数据库格式；

DEXT（基于AUTOSAR友好交互的诊断数据库.ARXML格式）。

CDD与ODX本身文件载体是XML，类似根目录形式，工程师日常在用文本打开（e.g. Notepad++），通过搜索也是可以找到对应的诊断描述内容，只是可读性特别差而已。

因此本文基于ISO22901（自身在外企做过此协议收费培训讲师），详细分析下ODX数据库的具体格式框架，辅助认识该数据库。

---

一、ODX数据库自身架构是什么？

在UML建模后，对诊断的层级结构进行形象描述。当MCD-3D Server对于诊断数据库ODX的调用逻辑取决于ODX数据库架构。

本文基于ISO 22901协议中对ODX架构进行分享。

在ODX层级结构中，内容（值）继承是诊断层之间关系的核心。如下图：

通过上图，清晰说明了继承的层架结构和方向。关于ODX内部层级：

PROTOCOL

FUNCTIONAL-GROUP

BASE-VARIANT

ECU-VARIANT

ECU-SHARED-DATA

每一个层级只能继承一组 特定的其他类型诊断层，一个诊断层不能继承同一个类型的诊断层。在图中，层级较高的诊断层属性更“General”，层级较低的诊断层属性更“Special”：

 注：只有如下类的对象可以进行值传递（继承）：

⎯ DIAG-COMM (its specializations),

⎯ DIAG-VARIABLE,

⎯ GLOBAL-NEG-RESPONSE,

⎯ DOP-BASE (its specializations),

⎯ TABLE,

⎯ FUNCT-CLASS,

⎯ VARIABLE-GROUP,

⎯ ADDITIONAL-AUDIENCE,

⎯ STATE-CHART,

⎯ UNIT-GROUP;

 注：

1、只有具有HANDLE属性的类的对象才能进行值传递，具有HANDLE属性对象聚合了其他也具有HANDLE属性的对象，则完整的聚合将被继承，即始终是聚合最外层对象（具有HANDLE属性）是值传递的主题。

2、值继承是为DIAG-LAYER的不同实例之间的对象定义的，因此只有在DIAG-LAYER中定义的类才可以继承。这些类的对象在选定的DIAG-LAYER的D-server API上可查询，查询结果将是该层可见的对象列表。

3、同一类的所有对象在每一个DIAG-LAYER中都应该有一个唯一的SHORT-NAME，即使这些对象不是在这个DIAG-LAYER中定义而是继承的。并且对于SHORT-NAME，当从更“General”层继承的对象可以被更“Special”层所覆盖，从而保证每一个Class的SHORT-NAME的唯一性。对于整个ODX数据库，只有覆盖对象可见（Tester可以通过SHORT-NAME进行诊断内容识别并调用）。

BASE-VARIANT对象通过聚合PROTOCOL-REF对象来创建到PROTOCOL对象的值继承关系。该对象又通过使用《odxlink》引用PROTOCOL对象。

继承层次详情可参考下图：

 BASE-VARIANT 对象通过聚合 PROTOCOL-REF 对象来建立到 PROTOCOL 对象的值继承关系，该对象又通过使用 <<odxlink>> 引用 PROTOCOL 对象。

一对 DIAG-LAYER 对象之间可能存在本节中描述的值继承关系。 禁止同一对对象同时存在两种关系。

二、ODX数据库架构具体组成部分和含义

如图显示的模型部分定义了所有诊断层的共同特征，基类DIAG-LAYER聚合了以下组件：

A：Collection of REQUEST objects

Request是每个诊断服务的组成部分，它由诊断仪发送到一个ECU或者一组ECU（以物理寻址 & 功能寻址进行区分）以获取所需要的诊断数据或配置ECU的属性。

Request的UML表示描述了这种请求消息的结构，它定义报文内容的一个或多个请求参数（PARAM）组成，ECU解析请求报文，并基于请求给与响应：

B：Collection of response objects (POS-RESPONSE, NEG-RESPONSE, GLOBAL-NEG-RESPONSE)

Response是ECU诊断服务的一部分。它由ECU反馈测试人员的请求报文，如下图描述此类响应格式：

ODX中定义了三种类型的响应：肯定响应、否定响应和全局否定响应。通常ECU会发送肯定响应报文（POS-RESPONSE）。如果ECU内发生了异常情况，则回复否定响应。

否定响应可能被定义为特定于服务或诊断层实例。

1. 在第一种情况下，应通过 NEG-RESPONSE-REF 引用来自服务的 NEG-RESPONSE 来定义否定响应。
2. 在第二种情况下，应定义全局否定响应（GLOBAL-NEG-RESPONSE）。 如果实际服务引用的否定响应不匹配，则该响应应由 D -server自动使用。

C：Document information using the ADMIN-DATA and COMPANY-DATA objects

对于ODX（诊断层或诊断服务），具有很长的声明周期。不可避免受到来自不同公司的不同人员可能进行的许多更改。因此引入该类对象，通过其更改历史记录与ODX对象绑定存储。

与此同时，该内容也包含关负责更改的人员的一些信息。 这样问题和反馈就可以发送给正确的接收者。 这种数据称为“管理数据”。 每个流程合作伙伴还可以将自己公司特定的管理数据添加到 ODX 对象，例如 使用内容管理系统或数据库处理 ODX 对象所需的修订信息。UML模型如下 ：

D：Collection of FUNCT-CLASS objects:

FUNCT-CLASS 对象在 DIAG-LAYER 中定义，用于对属于 DIAG-LAYER 的 DIAG-COMM 对象进行分类。 创建的类别的语义是用户自己定义，在协议中并未专门定义。

E：Collection of DOP-BASE and TABLE objects:

尽管元素 DIAG-DATA-DICTIONARY-SPEC 是可选的，但大多数 DIAG-LAYER 实例都会包含它，因为它作为解码诊断消息所需的数据元素的主要容器 .

F：Collection of DIAG-COMM objects and/or DIAG-COMM references:

通过DIAG-COMM对象或其引用的集合——通过模型中的DIAG-COMM-OPROXY捆绑。DIAG-COMM类是DIAG-SERVICE和SINGLE-ECU-JOB的抽象体，该内容会在D-service体现。

G: Collection of ADDITIONAL-AUDIENCEs

ADDITIONAL-AUDIENCE 是一个单独的用户列表，可以启用或禁用这些用户以读取相应的诊断元素。 诊断元素可以包含启用或禁用对 ADDITIONAL-AUDIENCE 的引用。如下是UML对additional audience的描述：

H: Collection of STATE-CHARTs

该内容是对车载诊断范畴里两个状态机进行管控：

1) 第一个是描述由执行 DIAG-COMM 导致的可能状态转换。

2) 第二个是描述执行 DIAG-COMM 的先决条件。

如下通过UML描述了Session/Security和STATE-CHART：

I: Collection of LIBRARYs

LIBRARY用于指定不直接执行但由 PROG-CODE 具体定义的可执行代码替代执行。e.g.包含 Java 的 PROG-CODE 元素可能引用描述附加 JAR 文件的 LIBRARY 元素，该文件由Java 代码中的 import 语句包含。 LIBRARYs 附加到 DIAG-LAYERs 以允许多个引用而没有冗余。

 

J: Collection of SUB-COMPONENTs：

如下图表述通过UML形象说明了SUB-COMPONENT的定义。子组件在诊断层定义，被认为是 ECU 内部或外部的功能单元，涵盖物理上（例如 LIN 从节点）或逻辑上的某些附加诊断相关功能。

如上分析，希望有所帮助！

---

总结

本文详细介绍了ODX数据库的结构框架,帮助工程师了解ODX数据库文件格式！