一、引言
在汽车电子技术迅猛发展的今天，车载诊断系统已成为现代车辆不可或缺的核心组成部分。它犹如车辆的“健康管家”，实时监测各系统的运行状态，一旦发现异常便及时发出警示，为车辆的维护保养和故障排查提供关键依据。在车载诊断领域，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诊断规格的完整描述，主要包括以下内容：
通信参数：协议类型（CAN、CAN FD、DoIP等）、诊断ID（请求ID/响应ID）、定时参数（STmin、Block Size、CS、BS等）
诊断服务：支持的UDS服务列表及其参数（请求格式、肯定响应格式、否定响应格式）
DID（Data Identifier）：数据标识符及其关联的数据类型定义
DTC（Diagnostic Trouble Code）：故障码表及其状态定义
会话与安全：诊断会话定义、安全访问等级配置
快照数据：故障发生时的环境数据记录定义
在汽车电子经典的V模型开发流程中，CDD文件处于核心枢纽位置：
需求阶段：OEM提出诊断需求规范
CDD编辑阶段：供应商使用CANdelaStudio工具，基于CDDT模板编辑生成CDD数据库
代码实现阶段：
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诊断工程化落地不可或缺的关键组件。
热门跟贴