前言

汽车诊断功能开发覆盖如下内容：

• 需求定义（系统、框架、单元）；

• 软件实现（依据AUTOSAR架构）；

• 测试验证（单元测试、集成测试）。

诊断应用流程覆盖生产、OTA、售后等阶段。在整个开发应用流程中，不同阶段会采用不同的诊断设备，以满足开发、生产、云端、售后等不同的需求。不同的诊断设备支持的诊断数据库格式也不完全相同，但同时又需要保证不同的诊断设备获取的诊断数据一致。在当前汽车行业中，业界常用的诊断数据库格式为：

1.CDD；

2.ODX；

3.ARXML（当然也包含其他功能e.g.通信）。

每个数据库都有其不同于其它诊断数据库的主要应用场景。在不同的诊断应用场景，如果混用诊断数据库，会导致诊断信息的缺失，甚至引起诊断流程混乱，给流程相关者带来麻烦。

本文将介绍不同的诊断数据库文件的应用场景与区别，以及如何保证不同诊断数据库中诊断数据的一致性。

概述

在传统开发开发中，OEM使用软件不可读文件（PDFWord）描述企业级诊断规范，然后将这些文档提供给ECU供应商，而ECU供应商根据这些文档设计自己的ECU级诊断规范，通常使用Excel诊断需求调查表的形式与OEM交互。

整个流程涉及到不同的公司，不同的部门（部门墙），不同的工程师（教育背景、工作经验），解读这些文档描述的诊断信息。在这个过程中，理解可能会有出入，从而导致诊断流程中出现矛盾，再回到最初的诊断需求来明确实际含义，使得流程周期延长针对传统流程中的问题，解决方案是将这些机器不可读的数据描述文档转化为机器可读的诊断数据库，诊断开发和应用流程中的诊断设备直接读取诊断数据库中的诊断信息，以此为基础实现诊断相关工作，避免人为理解的误差，同时提高诊断需求获取的正确性以及诊断流程的实现效率。

注：

CDD、ODX以及arxml是汽车行业内常见的三种诊断数据库格式，虽然都是描述诊断相关信息的数据库，但不能互相替代，因为它们各有特点，需要相互补充才可以完全满足诊断开发和应用流程的所有需求。

Vector诊断数据库CDD

首先CDD是Vector（一家德国公司）私有的诊断数据库格式，用于描述ECU的诊断功能需求，例如ECU支持UDS协议描述的诊断功能，则需要支持其中定义的会话跳转、安全解锁、读写数据流、读取故障码等服务和参数。CDD来源于欧洲某OEM期望改变人为理解诊断需求的状态，可以使用软件直接读取诊断需求，因此CDD文件是最早实现软件读取诊断需求的文件格式，也是在汽车行业内被最多诊断用户掌握的诊断数据库格式。

其中CDDT用于描述OEM即整车级别的诊断需求。CDD文件的建立基于CDDT模板，一个CDD文件对应一个ECU的诊断需求，从而保证ECU的诊断数据满足整车级别的需求与数据，同时可以减少相同数据的重复定义，提高CDD数据库的定义效率（编辑效率）。

CDD在整个过程中的作用：

• 保证整个流程的数据一致性和有效性；

• 在功能实现阶段（代码生成），可以导入配置功能，自动生成协议栈；

• 用于V模型中右侧的单元测试、集成测试（数据输入源）。