深入解析：ISO22901-1标准下的ODX诊断数据库
一
背景与挑战
在全球汽车行业日益发展的背景下，行业内对车辆诊断技术的要求也在不断提升。目前，ODX诊断数据库已被各大整车厂广泛采用，并在ECU的整个生命周期中扮演着至关重要的角色。它不仅可使诊断过程标准化，还确保了不同车型、不同环节之间数据交流的一致性和可靠性，从而成为推动车辆诊断技术进步的重要因素。
然而，构建ODX数据库存在一定的技术门槛，整车级别的大量数据输入工作也非常具有挑战性，而使用传统的手动编辑工具不仅耗时费力，还容易出错和遗漏。对工程师而言，这无疑是一项艰巨的任务。
二
ODX介绍
| 概述：
ODX（Open diagnostic data exchange）是由ASAM制定的标准诊断数据结构，自2002年开始制定，并于2008年正式释放了ISO 22901-1（ODX）标准。ODX标准的核心目的是，确保在系统供应商、汽车制造商、服务经销商及各种诊断工具之间，能够通过一致的数据格式来传输ECU诊断和编程信息。
ISO 22901-1协议标准描述了ECU诊断和编程数据的数据模型定义，包含描述车辆和ECU的所有诊断数据的数据模型，如诊断故障码、数据参数、输入/输出参数、ECU配置（变体编码）数据和通信参数，以及统一建模语言（UML）中的相关车辆接口描述，同时包括数据交换格式即扩展标记语言（XML）模式结构的实施。
（图1 Usage of ODX data in the ECU life cycle，图源来自：ISO22901-1 P3）
ODX格式的诊断数据将使MVCI（Modular Vehicle Communication Interface）设备能够与ECU进行通信，并解释包含在外部测试设备与ECU之间交换的信息中所包含的诊断数据。对于符合ODX标准的外部测试设备，无需进行额外软件编程，即可将诊断数据转换成技术人员可读的数据。
| 文件结构：
ODX文件结构可分为如下几个层级，以2.2.0版本为例：
*.odx-c Communication Parameter Specification
*.odx-cs Communication Parameter Subset
*.odx-d Diagnostic Layer Containers
*.odx-e ECU Configuration
*.odx-fd Function Dictionary
*.odx-v VehicleInfo Specs
*.odx-f Flashs
*.odx-m Multiple ECU Job Specification
| 下图展示了诊断层级-d数据结构的一个简单例子：
（图2 Diagnostic layers overview example，图源来自：ISO22901-1 P31）
■ Communication Parameter Specification “-C层”：
一个通信参数规范包含一个或多个协议栈（ProtStack），这些协议栈引用了通信参数子集（COMPRAM-SUBSET）中定义的一组通信参数。
■ Communication Parameter Subset “-CS层”：
• 通信参数及其值在通信参数子集中定义，例如网络层定时参数、应用层定时参数、波特率等。
• 每个子集可为不同的层（如应用层、传输层、物理层）定义通信参数。
■ Diagnostic Layer Containers “-D层”：
• 描述诊断仪与ECU之间的通信过程，包括通信服务的请求、响应格式及所用到的参数类型。
• 一个诊断层容器可包含一个或多个诊断层（DIAG-LAYER）。
• 每个诊断层（DIAG-LAYER）由五个子组组成，代表ASAM数据库模型的分层排列：
Shared Data（*. -SD）共享数据：包含通用诊断对象，如单位，经常被其他层重复使用；
Protocols（*. -PR）协议：描述通用协议（请求/响应），如包含ISO14229-1（UDS标准）；
Functional Groups（*. -FG）功能组：描述具有相同类似功能的ECU服务，通过功能寻址同时访问ECU；
ECU Base Variants（*. -BV）ECU基本变量：包含一个ECU平台的服务，通常有硬件零件号等；
ECU Variants（*. -EV）ECU变量：包含从基本变量衍生出来的变量，通常对应具体的供应商。
■ ECU Configuration “-E层”：
包含了ECU配置信息，包括根据特定的车辆环境、地点、使能/关闭可选功能等，主要应用于ECU生产、售后阶段。
■ Function Dictionary “-FD层”：
描述了面向特定功能的诊断信息。
■ VehicleInfo Specs “-V层”：
定义车辆拓扑结构，通道。
■ Flashs “-F层”：
刷写所需的数据描述，如内存布局、闪存片段的逻辑结构以及必须用于闪存数据的诊断服务或工作的信息。
■ Multiple ECU Job Specification “-M层”：
多ECU诊断Job的定义，可访问多个逻辑链路。
三
解决方案
基于多年的诊断开发经验，风丘科技自主研发的VisualODX诊断设计工具，支持一键转换Excel诊断问卷为ODX/PDX/CDD/DEXT/ATXML文件，功能强大，可大大减少了人力投入，同时操作便捷，从而加快了开发进度。
（图3 VisualODX软件界面）
（图4 VisualODX产品家族）
| 功能介绍：
1. Template：导入标准的ODX模板文件，完成ODX架构搭建。
（图5 Base-Template模板导入）
2. Link File：导入诊断问卷（Excel），生成*.odx-d、*.odx-e、*.odx-f文件，生成完整的诊断数据库；可为控制器添加多个EV，且EV数目不受限制。
（图6 Project-Link File导入表格）
3. Check：配置文件完整性检查与数据更新，错误可一键定位。
（图7 Project-Check检查功能）
4.Convert：支持导出ODX/PDX/CDD/DEXT/ATXML文件。
（图8 Project-Convert导出）
| 优势：
• 遵循ASAM标准的ODX模板、Excel模板结合双重检查，有效保证生成数据完整性、准确性；
• 标准版Excel填写模板，方便用户快速实现整车Excel问卷调查表创建；
• 创新性的项目配置界面，便于进行项目工程管理；
• 一键转换按钮，自动生成ODX/PDX/CDD/DEXT/ATXML文件；
• 支持导入单个或多个ECU的Excel表格，Excel表格数量无限制；
• 支持导出单个控制器或所有控制器的ODX/PDX/CDD/DEXT/ATXML文件；
• 转换效率高，满足大量数据的转换需求；
• 支持用户定制化Excel诊断问卷调查表。
四
总结
诊断数据库在整车生命周期中的重要作用不容忽视。通过使用VisualODX诊断设计工具，不仅可大大节约建库时间，还能有效提升工作效率，确保数据库在ECU链路的各个阶段的高质量管理和维护。
往期回顾