(ODX). 1: 引言 该部分 ISO 22901 协议用于定义传递 ECU 诊断数据格式�以及系统供应商、汽车制造 商和服务经销商以及不同的诊断工具开发商之间的程序数据 在今天的汽车工业中�存在一个对汽车 ECU 诊断数据流信息非正式的描述任何使用 该 ECU 诊断数据流文档去开发诊断测试设备的�都需要这些工具将这些文档转化为一种易 于读的格式如果诊断数据流信息以开放诊断数据交换�ODX�格式提供并且这些工具支持 ODX 格式的话�这些工夫就不必要了 该部分 ISO 22901 协议包括了 ECU 诊断及编程数据的数据模型的定义�并且使用统一 建模语言�ULM�对相关的汽车接口的描述在附件 C 源文件中�它也包含配置脚本语言 (XML)的实施 1 范围 该部分的ISO22901协议描述了使用新的工业标准诊断格式制作用于设备生产厂家诊断工具的诊断数据流信息�以便简化汽车后市场汽车服务行业开放数据交换�ODX�模型 诊断数据兼容模块化的车辆通讯接口(mvci)�ISO 22900-2 及 ISO 22900-3 中说明.�的软件 要求ODX 模型诊断数据会启用一个 mvci 设备与车辆电子控制单元进行通讯�并且解码外 部诊断设备与 ECU 之间的信息交互的诊断数据。
由于 ODX 依照外部测试设备�对于开发人 员来说�不必要编程将诊断数据转化为技术员可读的信息 ODX 规范包含描述车辆及 ECU 全部诊断数据的数据模型� 例如� 故障代码� 数据参数� 识别代码�输入/输出参数�ECU 设置�多种代码�数据及通信格式 ODX 以统一建模语言 �ULM� 图表形式描述� 并且数据交换格式使用配置脚本语言(XML) ODX 模型诊断数据描述: ——ECU 诊断通讯的协议规范� ——给予多种协议�数据链路层和 ECU 软件的通讯参数� ——ECU 编程数据�Flash� � ——相关车辆接口描述(接插件�引出线)� ——网络中 ECU 的诊断能力的功能描述 ——ECU 设置数据�多种代码� 图 1 显示了在 ECU 的生命周期中 ODX 的使用 该部分的 ISO22901 协议保证了任何汽车制造商的诊断数据�独立于测试硬件�及由任 何测试设备生产厂家提供的协议软件 3 缩略语 API 设备编程接口 ASAM 自动化及测试系统的标准化协会 ASCII 美国标准字符信息转换码 DOP 数据对象属性 ECU 电子控制单元 GMT 格林威治标准时间 MCD 测量�校准和诊断 ODX 开放诊断数据交换 OEM 原始设备制造商 PDU 协议数据单元 PDX 打包的 ODX UML 统一建模语言 UTC 协调世界时 VMM 车辆信息矩阵 W3C 万维网联盟 XML 配置脚本语言 4 ODX 使用案例 4.1 概述 图 1 显示了在 ECU 的生命周期中 ODX 的使用。
工程行业�制造行业及服务行业指定通 信协议及在 ECU 中执行的数据这些信息以 XML 的标准格式�通过合适的 ODX 制作工具 组织成文件从 ODX 文件中�有可能生成 ECU 软件此外�对于同一个 ODX 文件过去常 常建立诊断工程工具�以确认 ECU 通信的正确�及功能验证和符合性测试一旦满足目标 质量�ODX 文件可能发行到诊断数据库诊断的信息现在对生产�服务�OEM 特许经营商 以及在后市场服务中�通过内部网及因特网发布都是可行的 图 1 在 ECU 的生命周期中 ODX 的使用 4.2 使用案例 1�ODX 进程链 图 2 显示了 ODX 数据如何在一个进程链中使用的例子�包含如下 3 个阶段� 阶段 A� 在汽车制造商与系统供应商之间的开发过程中� 包括诊断的 ODX 的数据交互� 这用于支持 ECU 和开发工具的使用 阶段 B� 在汽车制造商开发过程中� 工程技术部门发布 ODX 数据到诊断数据库 生产、 服务部门使用 ODX 数据做为基准�建立命令行测试设备、服务应用开发工具及生成服务文 件 阶段 C�开发过程支持服务代理权诊断及编程工具服务部以 ODX 数据模型为依据� 开发服务工具应用软件。
诊断及编程软件可给所有服务经销商使用 ODX 数据是所有交互的诊断及编程数据的基础 图 2 ODX 进程链的例子 4.3 使用案例 2�多种汽车平台的 ECU 诊断开发 汽车制造商将电子系统使用到多个新的汽车平台在电子系统跨越不同汽车平台时�只需做小小的改变在多种汽车平台使用相同的 ECU 减少了多余的开发工作电子系统大 多数设计�正常的工作及诊断数据可以重用在各式车辆 大汽车制造商倾向于有多项工程开发中心诊断数据交换可以基于 ODX 数据格式以减 少在不同开发现场诊断数据的校对建立一个 ODX 兼容工具链将避免在不同开发现场将诊 断数据重定义为多种格式 图 3 显示了在两个开发现场�多种汽车平台 ECU 诊断开发的例子 图 3 多种汽车平台 ECU 诊断开发的例子 4.4 使用案例 3�特许经营店及后市场服务代理商诊断工具支持 图 4 显示了汽车制造商可能使用的脚本�用于支持服务代理商�特许经营店�及后市 场ODX 文件可能被转换成一个 ODX 运行时格式用于下载到服务代理商的诊断系统中 重要——ODX 运行时格式在不同诊断及编程设备中可能不同 在这种情况下� 一个 ODX 运行时转换器可能常常是支持将数据转换到服务代理商特定的测试设备中。
图 4 支持汽车代理商诊断工具的例子 4.5 兼容 VCI 模型的 D-server 架构 图 5 显示了 D-server 接口及 ODX 在诊断系统中的位置D-server 可以使用它内部特定 的运行时数据格式这些数据可以通过使用特定的格式转换器从 ODX 转换而来 图 5——模块 VCI 兼容的 D-server 架构 4.6 ODX 使用的好处 4.6.1 ECU 系统供应商 对于系统供应商有如下几个好处� ——自动配置 ECU 诊断数据流 ��� MULTIPLE-ECU-JOB; ��� CONFIG-ITEM, CONFIG-RECORD and DATA-RECORD of ECU-CONFIG; ��� BASE-FUNCTION-NODE of FUNCTION-DICTIONARY; ��� SESSION-DESC of ECU-MEM-CONNECTOR; ��� DATABLOCK of ECU-MEM; ��� TABLE-ROW. 在 ODX 中预先定义了 5 个组�因此 5 个值也指定了� a) IS-SUPPLIER; b) IS-DEVELOPMENT; c) IS-MANUFACTURING; d) IS-AFTERSALES; e) IS-AFTERMARKET. 每一个值都可设置为”true”或者”false”。
默认情况下�某一元素潜在的附带一个听众� 对每个组都可用�无论这个听众元素是空的还是不存在 为了扩展使能/禁能组清单� DIAG-LAYER 的子元素 ADDITIONAL-AUDIENCE 可被使 用ADDITION-AUDIENCE 是用户一个独立的清单�可被使能或禁能读相应的诊断元素 相对 ADDITIONAL-AUDIENCEs�一个诊断元素应包含要么使能要么禁能 图 16——层常规的 UML 表示——额外的听众显示 UML 详细的组件 图 16——层常规的 UML 表示——额外的听众 例子 ADDITONAL-AUDIENCES: IS_SUPPLIER IS-SUPPLIER “ENABLED-AUDIENCE-REF”有这个意思�例如 DIAG0COMM 只对参考的 ADDITIONAL-AUDIENCEs.可用 “DISABLED-AUDIENCE-REF”意思是该元素不对 ADDITIONAL-AUDIENCEs 可用� 只对其他列出的 ADDITIONAL-AUDIENCEs 可用 除了参考的 ADDITIONAL-AUDIENCEs�预定义 AUDIENCEs 应当被工具评估。
见图 17——DIAG-COMM 和 ADDITONAL-AUDIENCE 的 UML 表示�用于详细的 UML 图 17——DIAG-COMM 和 ADDITONAL-AUDIENCE 的 UML 表示 例子 ADDITIONAL-AUDIENCES: MANUFACTURER_C Manufacturer_C SUPPLIER_G SUPPLIER_G MANUFACTURER_S Manufacturer_S SUPPLIER_B SUPPLIER_B SERVICE_1 SERVICE_2 结果如下� — Service_1对 于MANUFACTURER_C使 能 � 但 对 于 其 它 定 义 的 ADDITIONALAUDIENCE.禁能 — Service_2 对 SUPPLIER_B 禁能� 但对于其它定义的 ADDITIONALAUDIENCE.使能 . 7.1.2.3 管理信息 7.1.2.3.1 总览 一些 ODX 组件�比如诊断层或服务�有很长的生命周期它们接受很多变化�可能由不同 公司�不同的人运行该组件的变动应当跟随该组件存储一些关于谁负责这些变动信息 应当可使用�以便问题和反馈能投递到正确的接收方。
该类型的数据称为“管理数据” 每一个处理人员能增加他自己公司指定的管理数据到一个 ODX 组件中例如在一个内容管 理系统或数据库中�修改那些需要处理 ODX 组件的信息 见图 18——管理数据的 UML 表示用于详细的组件信息 图 18——管理数据的 UML 表示 7.1.2.3.2 在 ODX 数据模型中的位置 ODX 为管理数据提供两个组件类�ADMIN-DATA 和 COMPANY-DATA ADMIN-DATA 组件包括管理数据指定 ODX 组件属于谁创建或修改 ODX 组件关于公司的信 息存储在 COMPANY-DATA 组件中应当为每一个加入过程合作创建和修改 ODX 组件的公司 的 COMPANY-DATA 组件独立开来见图 19——UML 建模信息的管理信息 图 19——管理信息 ADMIN-DATA 组件与一部分 ODX 组件相关联这些 ODX 组件在工程链中应当作为整体 进程处理�例如�修改�交换� 每一个 COMPANY-DATA 组件提供公司与其参与该项工程链的雇佣者的信息所有公司 指定的管理数据都直接或间接参考 COMPANY-DATA 组件。
通过这些参考�一个工程链合作 者能滤出他自己公司指定的管理数据 COMPANY-DATA 放置在 ODX 组件中例如�DIAG-LAYER-CONTAINER�用在数据交换单 元�可能转移到其它工程链合作者中 一个 ODX 容器类型在第九单元描述�打包的 ODX 数据也可包含 ADMIN-DATA 和 COMPANY-DATA ODX 容器类型中管理数据描述文件的修改情况�它用在数据交换过程 7.1.2.3.3 ADMIN-DATA 结构 ADMIN-DATA 包含两个部分�DOC-REVISIONS 和 COMPANY-DOC-INFOS 如果需要的话�整个 ODX 组件文本数据的 LANGUAGE 包括 ADMIN-DATA 可以说明例如� 为了支持与国际过程合作者合作是一个四个字母代码�例如�为德国�LANGUAGE 可设 置为“de-DE”或者“de-CH”为德国�瑞士等 每一个 DOC-REVISION 组件描述 ADMIN-DATA 属于的那个组件的修改 DOC-REVISION 组件应 当包含 DATE 的修改 创建这。