诊断数据库ODX—数据库框架（基于ISO22901详解）
文章目录
- 前言
- 一、ODX数据库自身架构是什么？
- 二、ODX数据库架构具体组成部分和含义
- 总结
前言
车载诊断现阶段应用的诊断数据库大体分为三种：
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 对象的值继承关系，该对象又通过使用 <
一对 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内发生了异常情况，则回复否定响应。
否定响应可能被定义为特定于服务或诊断层实例。
- 在第一种情况下，应通过 NEG-RESPONSE-REF 引用来自服务的 NEG-RESPONSE 来定义否定响应。
- 在第二种情况下，应定义全局否定响应（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数据库文件格式！