文章目录

 


前言

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

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数据库文件格式!

Logo

腾讯云面向开发者汇聚海量精品云计算使用和开发经验,营造开放的云计算技术生态圈。

更多推荐