随着汽车电子技术的不断发展，电子控制单元（ECU）在现代汽车中得到了广泛的应用。电子控制单元在提高汽车动力性、经济性、舒适性和安全性的同时，也使得车辆中的电子电气系统越来越复杂，这也促使汽车诊断技术有了更大的发展。在整车生命周期中，为了便于交换诊断数据，提高研发、测试、生产及售后的效率，降低诊断数据管理成本，一种开源的标准化诊断数据格式——ODX得到了越来越多的应用。本文介绍了ODX的基本体系结构，其与车辆通信模型接口（MVCI）的关系，并分析了现在ODX的主要应用及未来发展方向。

一、 ODX概述

ODX(Open Diagnostic Data Exchange)是一种开放式的诊断数据格式，用于车辆全生命周期中诊断数据的交互。ODX最初由ASAM (自动化及测量系统标准协会)提出并形成标准MCD-2D，在2008年以ODX 2.2.0为基础形成了ISO标准——ISO 22901-1。

在ODX提出之前，由于应用场景、开发工具的不同，诊断开发不同阶段使用的数据格式均不相同。例如，在研发阶段，诊断需求通常采用.doc或.rtf格式描述;在测试验证阶段，以业界常用的Vector CANoe.DiVa工具为例，诊断需求采用.cdd的格式描述;同样，生产、ECU代码实现及售后阶段，诊断需求的描述格式也不相同。然而，诊断开发流程中的各个阶段又相互依存，密不可分。如果诊断需求描述格式不断转换，将难以保证数据的一致性，既增大了需求管理的复杂度，又使各阶段工作衔接困难，增加综合成本。如果在整个诊断开发流程中均使用ODX作为诊断数据格式，由于其开源及标准化属性，上述问题都得以解决。使用ODX作为诊断数据格式的整个数据交互过程如图1所示：

图1 ODX数据交互过程

目前最新版本的ODX为2.2.0，整个ODX数据模型分为七层：ODX-D、ODX-C、ODX-V、ODX-E、ODX-FD、ODX-F、ODX-M，如图2所示：

图2 ODX数据模型

ODX-D部分主要描述了诊断仪与ECU之间的通信过程，包括诊断服务的请求、响应格式及所用到的参数类型等。除此之外，ODX-D部分还使用Single-ECU-job (java)的形式描述了一些特殊的诊断应用，例如安全访问算法的实现。ODX-C部分描述了诊断仪与ECU之间的通信参数，例如网络层定时参数、应用层定时参数、波特率等。ODX-V描述了车辆的信息，例如OEM(原始设备制造商)信息、车型信息、车辆拓扑等。ODX-F部分主要对上传下载的数据进行描述，应用于在线刷新程序。ODX-E部分描述了车辆的配置信息，包括根据特定的车辆环境，地点，使能/关闭可选功能，设定特征曲线等，主要应用于ECU生产、售后阶段。ODX-FD部分描述了面向功能的诊断信息。ODX-M部分描述了多个ECU共同实现的某些诊断功能信息。ODX-D与ODX-C是ODX数据模型的基础，是诊断数据的描述必不可少的两个部分。对于OEM来讲，ODX-V也是不可或缺的。

ODX为开发人员、供应商、售后生产人员之间的诊断数据交互提供了便利，简化了彼此之间的工作流程，降低了OEM对诊断数据维护、管理的成本。除此之外，ODX-D中各诊断层的值继承的应用，使诊断数据得以复用。在多个ECU项目中，通过比较或添加来减少数据量，避免不同ECU的数据拷贝时出错。同时，也可以通过值的本地覆盖来更新数据，有很强的灵活性。ODX中权限属性及强制继承属性的应用保证了诊断数据的安全性和完整性。

二、 ODX与MVCI

MVCI(Multiple Vehicle Connect Interface)为车辆通信接口模型，描述了车辆外接设备(例如售后诊断仪、下线设备、测试设备)与ECU之间的通信接口，如图3所示。

图3 车辆通信接口模型

其中应用层实现诊断的上层功能，例如售后诊断仪中读取故障功能、下线设备中钥匙匹配功能、测试设备中的测试用例等。接口实时系统负责与ODX进行交互，将应用层的功能转换成诊断请求，或者将收到的诊断响应解析为应用数据传给应用层。VCI是ECU与车辆外接设备之前的硬件接口，实现不同信号载体之间数据的传递。应用层与实时系统之间的接口称为D-Server API，实时系统与VCI之间的接口称为D-PDU API，这两个接口均由ISO标准化定义，分别为ISO 22900-1、ISO 22900-2。

由图3可知，对于OEM来说，如果使用ODX作为诊断数据格式，无论车辆外接设备应用于售后诊断、下线检测还是测试验证，只需要开发一套通用的接口实时系统，并提供标准的接口，即可根据不同的应用需求开发出不同的工具。节约了工具开发的成本，也避免了各个环节中诊断工具的管理成本。另外，这也将便于以后应用的扩展及通信硬件设备的更新。

接下来以读取发动机转速值为例介绍MVCI处理ODX数据的过程。

图4 MVCI处理ODX数据

1) 应用层将读取发动机转速值的应用命令通过D-Server API传递给接口实时系统;

2) 接口实时系统将读取数据这一应用命令通过ODX映射到诊断服务中(例如通过标识符读数据($22));

3) 接口实时系统将发动机转速这一命令通过ODX映射到诊断服务的参数中(例如 $0101);

4) 接口实时系统将应用指令组成完整的诊断请求 $22 $01 $01;

5) 接口实时系统通过D-PDU API接口将请求传递给VCI，VCI将这一诊断请求转换成通信信号(例如CAN信号)发给ECU;

6) VCI将接收到的通信信号通过D-PDU API传递给接口实时系统，例如$62 $01 $01 $5D $C0;

7) 接口实时系统将响应中数据通过ODX进行解析，例如发动机转速为$5D $C0;

8) 接口实时系统通过ODX中的参数数据类型将响应中的总线值转换成物理值，例如 ($5DC0*0.125=3000)

9) 接口实时系统通过ODX创建响应对象，包括参数物理值、单位等，例如3000 rpm;

10) 接口实时系统通过调用D-Server API将这一结果传递给应用层并展示给用户。

整个通信过程中的时间参数也是接口实时系统通过ODX获取，并以此来保证通信的正确性及准确性。

三、 ODX应用现状

ASAM 组织的核心成员均为欧美主要的OEM及工具制造商，包括通用、奥迪、宝马、代姆勒、大众、Vector等。因此ODX在欧美的应用较为广泛。

宝马公司之前的诊断数据为特有的BEST2格式，但从长远考虑，宝马公司决定从研发阶段开始标准化诊断数据格式。但这将会带来很多问题，例如售后、测试、生产用到的诊断数据均需要重新建立，使用到的工具、软件都需要重新开发，整个诊断流程中涉及到的人员需要对其进行培训。这将花费很长的时间及费用，并会对现有的生产体系造成影响。为了降低诊断数据格式切换带来的影响，宝马公司与ESG公司合作开发了ODX-BEST2-Converter这一工具，如图5所示。它能将研发阶段的ODX格式诊断数据转化成生产售后使用的BEST2格式。但这一工具仅用在诊断数据格式切换的过渡时期，宝马公司已经制定了详细的数据格式切换计划，如图6所示，逐步将全部诊断流程中使用的诊断数据统一为ODX格式。

图5 ODX-BEST2-Converter软件架构

图6 ODX数据格式切换计划

奥迪公司在2007年建立了新的总装、测试中心A14，奥迪A4、A6将在这里生产。在生产初期，奥迪公司就引入ODX数据来进行ECU诊断的测试及ECU在线程序刷写。除进行诊断测试外，其它的测试，例如标定、四轮定位、动态测试等都在此测试中心进行，且这些测试均使用了ECOS测试系统。由于不同车型的测试需求及顺序不同，ECOS测试系统需要根据不同的车型数据来判断在测试过程中是否需要通过ODX数据来进行诊断测试及在线刷写。如果需要，将使用另一支持ODX的设备进行测试。为了优化测试流程，并避免将ODX格式转换成ECOS支持格式带来的风险，奥迪公司与Siemens公司共同开发了SIDIS Data Manager工具，并将此集成到了ECOS测试系统中，如图7所示，保证了测试过程的完整性及准确性，同时也提高了整个测试效率。

图7 集成了处理ODX数据软件的ECOS测试系统

通用公司在2006年提出要建立一个更为先进的测试实验室，但是通用公司发现非标准的协议及自定义的接口使得测试环境的搭建以及工具的管理变得复杂。为了解决这一问题，通用公司选择了ODX作为所有诊断数据的标准格式，并标准化了通用公司测试应用与工具供应商之间的软件接口。使得通用公司的注意力更集中于测试的过程及方法而不是工具的开发及数据完整性上，同时也节约了开发成本。

大众旗下的兰博基尼公司希望有一套从设计、生产、售后的诊断工具链。最终选择了ASAM MCD以及OBD相关的ISO标准。同时与RA Consulting合作开发了以处理ODX为核心，不同应用的DiagRA MCD-development 、LaRA EOL-production、LaRA AS-after-sales工具链。选择标准的诊断数据格式降低了工具的开发成本并有很好的扩展性。

在ODX的应用过程中，OEM会提出一些特殊的需求，相对应的工具开发商将开发相应的工具。例如为了满足代姆勒公司在释放ODX数据给供应商时希望对数据进行过滤，只将和供应商相关的数据进行释放的需求，MBtech公司为其开发了ODX数据导出的工具，这一工具可以保证导出的ODX数据的正确性，并能将ODX中与供应商无关的数据进行过滤。再比如在ODX数据往往是以PDX(将所有ODX文件打成包并加上目录)形式进行传递，但PDX中的文件经常会有更新、提取或增加。ESG公司开发的PDXLib工具可以轻松的将ODX文件打包成PDX或添加到已有的PDX中并更新目录，还可以提取PDX中任意文件、检测PDX文件的正确性。这一工具统一了PDX中文件的命名及结构，方便了数据交换过程、减少了数据集成的时间并避免由于人为因素造成的数据错误。

ODX在中国目前应用还比较少，国内的OEM只有上海汽车为ASAM的成员。但是随着国内OEM自主研发能力的不断提高，车型的不断丰富，ODX也越来越受到重视。目前一汽技术中心、潍柴动力、恒润科技等公司均对ODX技术有一定研究，并将其逐步应用到诊断开发流程中。

四、 ODX发展趋势

ODX技术在国外尤其是欧美的OEM中应用已经较为成熟，但随着ODX的深入应用，不同的需求还会不断涌现，这也将促使标准的不断完善和新工具的诞生。例如ASAM在2011年发布的ODX Authoring Guidelines，为建立ODX文件时的命名(比如文件名称、ODX-Link、DOP)、SDG的描述、服务的描述(SEMANTIC、Service-Id、否定响应码)、DTC的描述、数据交互过程给出了统一的建议及相关示例，进一步推进了ODX在OEM和供应商之间交互诊断数据的应用。标准化组织、OEM、工具供应商共同努力将是ODX应用与发展的主要推动力。

随着国内OEM诊断技术的不断积累，诊断开发流程的不断完善，为了减少诊断数据及工具管理的成本，ODX也将逐步得到更为广泛的应用。国内OEM将逐渐统一诊断数据格式，并与工具供应商合作开发适用于自身的诊断工具链。

ODX作为一种开源的数据格式，其安全性将是OEM及供应商共同面临的一个问题，因此基于这种开源的数据格式，数据的加密、保护也会有相应的发展。

五、 总结

作为用于交换诊断数据的一种标准化的格式，基于XML语言的ODX标准在制定时考虑了诊断开发全过程中数据的可交换性，标准化了数据格式。这使得ODX标准及相关的工具和测试方法在诊断开发流程中具有广阔的应用前景。