一文讲透UDS、OBD与CDD：从协议规范到工程落地的完整剖析

一、引言

在汽车电子技术迅猛发展的今天，车载诊断系统已成为现代车辆不可或缺的核心组成部分。它犹如车辆的“健康管家”，实时监测各系统的运行状态，一旦发现异常便及时发出警示，为车辆的维护保养和故障排查提供关键依据。在车载诊断领域，UDS（统一诊断服务）与OBD（车载诊断系统）是两大核心协议，而CDD（CANdela诊断描述）文件则是连接诊断协议与工程实践的桥梁。本文将系统讲解这三者的技术内涵、协议架构及其在汽车电子开发中的应用。

二、UDS诊断协议详解 2.1 UDS概述

UDS（Unified Diagnostic Services，统一诊断服务）是汽车电子ECU环境下的一种诊断通信协议，对应的国际标准为ISO 14229。UDS定义了一系列的服务和子服务，用于在诊断设备（客户端）和车辆ECU（服务器）之间进行通信，以执行读取/清除故障码、配置ECU参数、请求和设置数据等各种诊断任务。

“统一”（Unified）一词意味着它是一个国际化的、非公司特定的标准，区别于早期各厂商私有的诊断协议。

2.2 UDS协议体系结构

截至2020年，UDS诊断由以下8个部分组成：

部分编号

名称

ISO 14229-1

规范和要求

核心应用层规范

ISO 14229-2

会话层服务

会话层协议定义

ISO 14229-3

UDSonCAN

CAN总线上的UDS实现

ISO 14229-4

UDSonFR

FlexRay总线上的UDS实现

ISO 14229-5

UDSonIP

Internet协议上的UDS实现（DoIP）

ISO 14229-6

UDSonK-Line

K线上的UDS实现

ISO 14229-7

UDSonLIN

LIN总线上的UDS实现

ISO 14229-8

UDSonCXPI

CXPI总线上的UDS实现

ISO 14229-1描述的是与诊断服务相关的需求，并未涉及具体通信机制，因此UDS可以在不同的汽车总线上实现。当UDS运行于CAN总线上时，在网络层和传输层遵循ISO 15765-2（ISO-TP）标准。ISO-TP专门为CAN上的诊断通信定义了传输协议，解决了应用层数据长度（最大4095字节）与经典CAN总线数据长度（8字节）不匹配的问题。

2.3 UDS通信机制

UDS是一种请求/响应（Request/Response）式的定向交互协议。诊断方（Tester）发送服务请求，ECU返回肯定响应或否定响应。

请求格式：请求数据的第一字节为SID（Service Identifier，服务标识符）。

肯定响应格式：（SID + 0x40）+ 数据。例如，请求0x10服务，肯定响应的第一字节为0x50。

否定响应格式：0x7F + SID + NRC。例如，请求0x10服务，否定响应第一字节为固定的0x7F，第二字节为0x10，第三字节为NRC（否定响应码）。NRC码是快速判断故障原因的重要依据。

根据是否具有子功能（Subfunction），UDS服务请求和响应分为两类。子功能是对主服务的进一步细分，例如0x10服务（诊断会话控制）常用的子功能包括：01默认会话、02编程会话、03扩展会话。

2.4 寻址方式

UDS诊断支持两种寻址方式：

• 物理寻址（Physically Addressed）：指定发送特定诊断请求，等待指定ECU给予响应，用于一对一通信。

• 功能寻址（Functionally Addressed）：广播诊断请求，同时等待总线上所有ECU给予响应，用于一对多通信。

UDS诊断包括6大类、26种服务，每种服务都有独立的SID。以下列举部分核心服务：

SID

服务名称

功能描述

0x10

DiagnosticSessionControl

诊断会话控制，切换ECU工作会话

0x11

ECUReset

ECU复位

0x14

ClearDiagnosticInformation

清除诊断信息（故障码）

0x19

ReadDTCInformation

读取故障码信息

0x22

ReadDataByIdentifier

通过DID读取数据

0x27

SecurityAccess

安全访问（解锁/锁定）

0x2E

WriteDataByIdentifier

通过DID写入数据

0x3E

TesterPresent

保持当前会话激活状态

其中，0x10诊断会话控制服务用于激活控制器的不同会话模式。ECU上电后初始状态为默认会话（Default Session），该状态下支持的诊断服务有限；如需更多服务，需通过0x10服务切换到编程会话或扩展会话。

0x3E服务（TesterPresent）用于确保诊断服务或之前激活的通信保持激活状态，通过周期性发送请求帧防止自动跳回默认会话。

0x27安全访问服务用于身份验证，客户端需证明身份后才能访问受安全限制的数据和诊断服务。

0x19读取DTC服务是UDS中的核心服务，故障码分为四大类：P（Powertrain，动力系统）、C（Chassis，底盘）、B（Body，车身）、U（Network，网络通信系统），每个DTC信息占用4个字节。

三、OBD诊断协议详解 3.1 OBD概述

OBD（On-Board Diagnostic，车载诊断系统）是汽车排放和驱动性相关故障的标准化诊断规范。OBD的起源与环保法规紧密相连——上世纪80年代，美国加州空气资源委员会（CARB）强制要求1988年起在加州销售的车辆必须装备车载诊断系统，以实时监控车辆排放相关部件的工作状态。随后该法规推广至全美，形成了OBD-II标准。

3.2 OBD的诊断范畴与功能

OBD的核心聚焦于排放，其诊断范畴严格限定在与车辆排放性能直接相关的系统与部件上，涵盖发动机动力总成、排放后处理系统、燃油蒸发控制系统等。

OBD主要提供以下基础诊断服务：

• 读取故障码（DTC）：当系统检测到排放相关故障时生成标准化故障代码

• 清除故障码：故障排除后清除ECU中的故障码

• 获取实时数据：读取与排放相关的实时运行参数（发动机转速、车速、氧传感器信号等）

• 检查系统就绪状态：检查各排放相关系统的自检完成情况

OBD-II定义了9种诊断服务模式（Mode 09），每种模式对应特定的诊断功能：

模式

名称

功能

$01

Request Current Powertrain Diagnostic Data

请求当前动力总成诊断数据

$02

Request Powertrain Freeze Frame Data

请求冻结帧数据

$03

Request Emission-Related DTCs

请求与排放相关的故障码

$04

Clear/Reset Emission-Related DTCs

清除排放相关故障码

$05

Request Oxygen Sensor Monitoring Test Results

请求氧传感器监测结果

$06

Request On-Board Monitoring Test Results

请求车载监测测试结果

$07

Request DTCs during Current or Last Driving Cycle

请求当前/上次驾驶循环的DTC

$08

Request Control of On-Board System

请求车载系统控制

$09

Request Vehicle Information

请求车辆信息

3.4 OBD通信协议栈

OBD通信基于七层OSI模型构建：

• 物理层：早期采用基于ISO 9141的K线通信，如今广泛采用高速CAN总线（ISO 11898）

• 数据链路层：负责数据帧封装、差错检测与流量控制

• 网络层：处理网络寻址与路由选择

• 应用层：遵循ISO 15031-5标准，定义OBD诊断服务

UDS与OBD在多个维度上存在显著差异：

对比维度

OBD

UDS

关注焦点

车辆实时排放

全面的诊断服务

适用范围

面向排放系统ECU

面向整车所有ECU

法规驱动

环保法规（CARB/EPA）

行业标准化需求

典型车辆

传统燃油车必须满足

燃油车、混动车、纯电动车均适用

服务代码范围

小于0x10

从0x10开始

OBD是关注车辆实时排放的理念形成的行业规范，电动车不需要满足OBD标准（因为没有尾气排放）。而UDS是诊断服务的统一化规范，既可用于燃油车中的ECU，也可用于混动和纯电动车中的ECU。

4.2 协同共存

UDS和OBD虽然存在差异，但都依赖于相同的网络层和会话层协议，因此可以在同一ECU中共存。一般传统燃油车或混动车中，与排放相关的ECU既要支持OBD也要支持UDS。

在技术实现层面，UDS上的OBD（OBD over UDS）已成为重要趋势——ISO 14229-3中规定了统一诊断服务，SAE J1979-2中规定了基于UDS的OBD诊断服务标准。这意味着OBD服务可以承载在UDS协议框架之上，实现两种诊断体系的融合。

4.3 应用层与传输层的关系

UDS本质上是一个应用层协议（ISO 14229-1），它可以在不同的物理总线上实现，包括CAN（UDSonCAN）、Ethernet（DoIP）等。OBD同样可以在UDS协议之上运行。两者在应用层和服务定义上各有侧重，但在传输层可以共享相同的协议栈（如ISO-TP）。

五、CDD诊断描述文件详解 5.1 CDD概述

CDD（CANdela Diagnostic Descriptions，CANdela诊断描述）文件是诊断数据的数据库，与用于CAN消息和信号描述的DBC文件地位相当。CDD文件基于ASAM MCD-2D标准格式，提供了车辆诊断通信所需的详细描述，包括诊断服务、参数、PDU格式等。

CDD文件在Vector公司的CANdelaStudio工具中创建，可以在CANoe/CANalyzer中用于诊断服务和参数的符号访问和解释。通过导入CDD文件，CANoe可以自动解析和识别ECU支持的UDS诊断服务及相关数据格式，从而提供更高效和自动化的测试过程。

5.2 CDDT与CDD的关系

在理解CDD之前，需要首先了解CDDT（CANdela Document Template）的概念：

• CDDT（模板文件）：由OEM提供的模板文件，定义了诊断服务的框架结构和基本规则。它是基于整车级的需求规范生成的，对应宏观概念。CDDT会定义整车所有控制器用到的UDS诊断服务。

• CDD（数据库文件）：供应商基于CDDT模板为特定ECU创建的具体诊断数据库。CDD是微观的、针对单个ECU的，量化了CDDT中定义的接口参数（如具体的诊断ID、DID值等）。

对比维度

CDDT

CDD

性质

模板（Template）

实例（Document）

层级

整车级

单ECU级

定义内容

服务框架、结构规则

具体参数值（ID、DID、DTC等）

提供方

OEM

供应商

可编辑性

仅Admin版本可编辑

可基于模板编辑

CDDT与CDD的关系可以用一个形象的比喻：CDDT是“桌子”，CDD是“站在桌子上摘到的桃子”——没有CDDT这个基础平台，就无法生成规范的CDD文件。

5.3 CDD文件结构

CDD文件包含了ECU诊断规格的完整描述，主要包括以下内容：

1. 通信参数：协议类型（CAN、CAN FD、DoIP等）、诊断ID（请求ID/响应ID）、定时参数（STmin、Block Size、CS、BS等）

2. 诊断服务：支持的UDS服务列表及其参数（请求格式、肯定响应格式、否定响应格式）

3. DID（Data Identifier）：数据标识符及其关联的数据类型定义

4. DTC（Diagnostic Trouble Code）：故障码表及其状态定义

5. 会话与安全：诊断会话定义、安全访问等级配置

6. 快照数据：故障发生时的环境数据记录定义

在汽车电子经典的V模型开发流程中，CDD文件处于核心枢纽位置：

1. 需求阶段：OEM提出诊断需求规范

2. CDD编辑阶段：供应商使用CANdelaStudio工具，基于CDDT模板编辑生成CDD数据库

3. 代码实现阶段：

• Non-AUTOSAR体系：将CDD加载到配置工具，生成CANdesc协议栈

• AUTOSAR体系：将CDD加载到达芬奇工具，配置生成MICROSAR协议栈

测试验证阶段：

• 手动测试：将CDD加载到CANoe、CANape等工具进行手动诊断测试

• 自动化测试：将CDD加载到CANoe.Diva工具，自动生成诊断测试用例并运行

在实际的UDS诊断测试中，CDD文件的使用带来了显著的效率提升：

• 有CDD文件：测试工具可以自动解析和识别ECU支持的诊断服务及数据格式，实现高效、自动化的测试

• 无CDD文件：需要手动配置每个诊断服务的SID、参数ID、数据格式，依赖脚本编写和手动调用

CDD文件确保ECU在全生命周期（研发、量产、售后）中使用一致的诊断数据，保证了诊断数据的同源性和一致性。

5.6 CDD与ODX的关系

ODX（Open Diagnostic Data Exchange）是由ASAM主导制定的国际标准（ASAM MCD-2D），旨在统一车载诊断数据的描述语言和交换格式。CDD是Vector公司的专有格式，而ODX是跨厂商的开放标准。在实际工程中，CDD文件可以转换为ODX格式，实现诊断数据在不同工具链之间的交换与共享。

六、总结

UDS（ISO 14229）作为统一诊断服务协议，定义了完整的诊断服务体系和通信规范，是当前汽车电子诊断领域最核心的应用层协议。OBD作为车载诊断系统，专注于排放相关的诊断需求，是环保法规驱动的行业规范。两者在应用场景、服务范围和功能定位上各有侧重，但在现代汽车中协同共存、相互补充。

CDD诊断描述文件作为连接诊断协议与工程实践的桥梁，将抽象的协议规范转化为具体、可执行的诊断数据库。通过CDDT模板→CDD实例的工程化流程，CDD文件确保了从OEM需求到供应商实现、从代码开发到测试验证的全链路诊断数据一致性，是UDS/OBD诊断工程化落地不可或缺的关键组件。