📚 课程目录第2章诊断协议概述

诊断协议概述：UDS（ISO 14229）的起源、发展、与OBD-II/ISO 15765-2的关系

在车载网络诊断的工程实践中，UDS（Unified Diagnostic Services，统一诊断服务）是当前全球OEM和零部件供应商应用最广泛的应用层诊断协议。它定义了一套标准化的服务标识符（SID，Service Identifier），用于在诊断仪（Tester）与电子控制单元（ECU）之间进行读取数据、写入参数、清除故障码、执行例程等操作。要真正理解UDS，不能只停留在服务ID的记忆层面，而必须厘清它的“来路”——即它如何从早期的ISO 14230（KWP2000）演进而来，又为何在CAN总线上选择ISO 15765-2（CAN-TP）作为传输层承载，以及它与法规强制要求的OBD-II之间究竟是“替代”还是“互补”的关系。本章将从协议谱系、分层架构和工程应用三个维度展开剖析。

2.1 UDS的起源：从KWP2000到统一诊断服务的演进

UDS并非凭空诞生，它的前身是欧洲汽车工业广泛使用的KWP2000（Keyword Protocol 2000，ISO 14230）。KWP2000最初设计用于K线（ISO 9141）和早期的CAN总线，其核心思想是通过“关键字”协商波特率和协议参数。然而，随着车载电子系统复杂度急剧上升，KWP2000暴露出几个关键痛点：一是服务定义不够统一，各OEM经常自定义扩展服务，导致诊断仪兼容性差；二是对多帧传输的支持不够高效，尤其在传输大数据块（如Bootloader刷写）时，KWP2000的流控机制显得笨重；三是它没有很好地与现代车载网络的分层架构解耦，导致底层传输介质更换时，应用层需要大量修改。

2006年，ISO组织正式发布了ISO 14229-1，即UDS。UDS的设计目标非常明确：提供一套与底层传输介质无关的、统一的应用层诊断服务。它不再关心数据是通过CAN、LIN、FlexRay还是以太网传输，而是专注于定义“诊断服务”本身——比如请求ECU的软件版本号（0x22服务）、写入VIN码（0x2E服务）、读取故障码（0x19服务）等。这种“应用层与传输层解耦”的设计思想，使得UDS可以轻松适配不同的总线类型，也为后续的DoIP（Diagnostic over IP，基于以太网的诊断）铺平了道路。

  核心原理：UDS的“统一”体现在两个层面。第一，服务ID（SID）的语义统一，例如0x10（诊断会话控制）、0x22（按标识符读取数据）、0x2E（按标识符写入数据）在所有OEM的ECU中含义一致。第二，服务执行流程统一，每个服务都遵循“请求-响应-待处理（Pending）”的标准时序，即使ECU正在执行耗时操作（如擦除Flash），也必须通过0x7F（否定响应）配合NRC 0x78（响应待处理）来维持通信链路，避免诊断仪误判超时。

2.2 UDS与ISO 15765-2（CAN-TP）的协同关系

在实际的CAN总线诊断应用中，UDS应用层数据并不能直接塞进一个CAN帧里。经典CAN数据帧最多承载8字节数据，而一条UDS请求（如写入Bootloader的32KB数据块）往往远超8字节。因此，ISO 15765-2（通常称为CAN-TP，Transport Protocol）承担了“分段传输”的职责。CAN-TP定义了四种帧类型：单帧（SF）、首帧（FF）、连续帧（CF）和流控帧（FC）。当UDS报文长度小于等于7字节时，直接使用单帧发送；当长度超过7字节时，发送方先发出首帧（包含总长度信息），接收方回复流控帧（告知发送方“我可以接收多少字节”），随后发送方以连续帧的形式分批发送剩余数据。

这种分层协作关系在工程中至关重要。诊断仪工程师在配置CANalyzer或PCAN工具时，必须同时配置两个关键参数：应用层协议选择ISO 14229，传输层协议选择ISO 15765-2。如果只配置了UDS而忽略了CAN-TP，那么当诊断仪发送一个超过8字节的请求时，CAN驱动会直接报错“帧溢出”。反之，如果只配置了CAN-TP而没有UDS，则收到的数据只是一堆没有语义的字节流，无法解析出具体的服务ID和参数。

对比维度	ISO 14229 (UDS)	ISO 15765-2 (CAN-TP)
协议层级	应用层（第7层）	传输层（第4层，适配CAN）
核心职责	定义服务ID、子功能、数据参数、时序要求	定义单帧/多帧分段、流控机制、段长度管理
典型报文	0x22 F1 90（读取VIN）	首帧：0x10 0x0C 0x22 0xF1 0x90...
最大传输单元	理论无限制（由传输层决定）	经典CAN：4095字节；CAN FD：可更大
错误处理	否定响应码（NRC）	帧超时、流控错误、序列号错误

实战经验：在ECU刷写（Bootloader）场景中，UDS的0x34（请求下载）和0x36（传输数据）服务配合CAN-TP的多帧传输，是典型的“应用层+传输层”协作案例。刷写时，诊断仪先发送0x34请求下载，ECU回复一个“最大数据块长度”（通常为4KB），随后诊断仪将固件拆分为多个4KB块，每块再通过CAN-TP拆分为若干连续帧发送。如果CAN-TP的流控帧参数（BlockSize和STmin）配置不当，会导致ECU接收缓冲区溢出或总线带宽浪费。

2.3 UDS与OBD-II（ISO 15031）的定位差异

很多初学者容易混淆UDS和OBD-II，甚至认为它们是同一回事。实际上，两者在法规背景、服务定义和应用场景上有本质区别。OBD-II（On-Board Diagnostics II）是法规强制要求的排放诊断标准，其核心目的是监控车辆排放相关系统（如氧传感器、三元催化器、燃油系统）的工作状态，并在排放超标时点亮仪表盘上的MIL灯（Malfunction Indicator Lamp）。OBD-II的服务ID定义在ISO 15031-5中，例如模式0x01（请求当前数据）、0x03（请求故障码）、0x07（请求待定故障码）。这些服务是“只读”的，且PID（参数ID）是固定的，比如PID 0x0C表示发动机转速，PID 0x0D表示车速。

UDS则完全不同。它是OEM自定义诊断的“万能工具箱”，不仅支持读取数据，还支持写入配置、执行例程、控制ECU进入特定模式（如扩展诊断会话、编程会话）。UDS的服务ID范围从0x10到0x3E，其中0x10（诊断会话控制）、0x11（ECU复位）、0x22（读取数据）、0x2E（写入数据）、0x27（安全访问）、0x19（读取故障码）、0x14（清除故障码）是最常用的七个服务。OBD-II的故障码格式是5位标准码（如P0301表示1缸失火），而UDS的故障码格式更灵活，通常包含DTC（诊断故障码）和状态掩码（如当前存在、历史存在、待定等）。

风险提示：在售后诊断仪开发中，必须明确区分“法规诊断”和“增强诊断”两个通道。法规诊断（OBD-II）通常通过CAN ID 0x7DF（广播请求）和0x7E8-0x7EF（ECU响应）进行，而UDS增强诊断通常使用OEM自定义的CAN ID（如物理请求0x7E0，功能请求0x7DF）。如果诊断仪错误地将UDS的0x22服务发送到OBD-II的0x7DF地址上，ECU可能不会响应，因为OBD-II模式只识别ISO 15031定义的服务ID。反之，如果OBD-II的0x01服务被发送到UDS的物理请求地址，ECU同样会返回否定响应（NRC 0x11，服务不支持）。

2.4 案例拆解：一个真实的UDS会话建立与数据读取流程

为了将上述概念串联起来，我们拆解一个典型的工程场景：使用UDS读取某ECU的VIN码（车辆识别码）。该ECU挂在CAN总线上，诊断仪通过CANalyzer连接。

第一步：物理层与数据链路层准备。确认CAN总线波特率为500kbps，终端电阻120Ω正常。诊断仪发送一个CAN帧，ID为0x7E0（物理请求），DLC=8，数据为02 10 03 00 00 00 00 00。其中02表示后续有效字节数为2，10是UDS服务ID（诊断会话控制），03是子功能（扩展诊断会话）。注意，这里虽然只有3个有效字节，但CAN帧必须填满8字节，不足部分补0x00。

第二步：传输层封装。由于该请求只有3字节有效数据，小于7字节，因此CAN-TP直接使用单帧（SF）格式。单帧的第一个字节高4位为0x0（表示单帧），低4位为有效长度3，即0x03。所以实际CAN数据为03 10 03 00 00 00 00 00。诊断仪工具会自动完成这个封装，但工程师必须理解其原理。

第三步：ECU响应与安全访问。ECU收到请求后，回复06 50 03 00 32 01 F4。解析：06表示有效长度6，50是0x10服务的肯定响应（SID+0x40），03是回显的子功能，00 32 01 F4是ECU返回的会话参数（如P2超时时间、P2*超时时间）。此时，如果VIN码存储在受保护的内存区域，ECU会要求先进行安全访问（0x27服务）。诊断仪发送02 27 01 00 00 00 00 00请求种子，ECU返回种子04 67 01 1A 2B 3C 00 00，诊断仪根据种子计算密钥并发送04 27 02 4D 5E 6F 00 00，ECU验证通过后返回02 67 02 00 00 00 00 00。

第四步：读取VIN码。安全访问通过后，诊断仪发送03 22 F1 90 00 00 00 00，其中22是读取数据服务，F1 90是VIN码的DID（数据标识符）。ECU回复14 62 F1 90 4C 53 56 38，其中14表示有效长度20，62是0x22的肯定响应，F1 90回显DID，后续17字节是ASCII编码的VIN码（如“LSV8...”）。由于响应长度超过7字节，CAN-TP自动切换为多帧传输：首帧10 14 62 F1 90 4C 53 56，流控帧30 00 00 00 00 00 00 00，连续帧21 38 2E 2E 2E 00 00 00等。

  案例复盘：这个流程展示了UDS与CAN-TP的完整协作。关键经验有三点：第一，安全访问的种子/密钥算法是OEM自定义的，诊断仪必须实现对应的算法（通常是一个CRC或XOR变换）；第二，VIN码的DID（0xF190）是ISO 14229-1附录中推荐的标准DID，但部分OEM会使用自定义DID，因此诊断仪必须维护一个DID映射表；第三，多帧传输时，连续帧的序列号从0x21开始递增，如果接收方发现序列号不连续，会发送否定响应或直接丢弃报文。

2.5 常见误区与总结复盘

在培训中，学员经常对UDS、OBD-II和CAN-TP的关系产生混淆。以下三个误区最具代表性：

误区一：认为UDS可以替代OBD-II。实际上，OBD-II是法规底线，所有在售车辆必须满足；UDS是OEM的增值功能，两者共存于同一ECU中，通过不同的CAN ID和服务ID进行区分。
误区二：忽略CAN-TP的存在。很多初学者在CANalyzer中直接发送UDS报文，发现ECU无响应，原因就是没有启用CAN-TP通道，导致超过8字节的报文被截断。
误区三：混淆物理寻址和功能寻址。UDS支持物理请求（点对点，如0x7E0）和功能请求（广播，如0x7DF）。功能请求通常用于同时唤醒多个ECU（如0x10 03），但ECU的响应会冲突，因此功能请求一般只用于不需要响应的服务（如0x28 通信控制）。