UDS（统一诊断服务）与CAN总线的分层架构专业解读

引言

在汽车电子领域，车辆诊断协议的演进经历了从OBD（车载诊断系统）到UDS（统一诊断服务）的漫长过程。最早的诊断系统主要服务于排放监测，随着电子控制单元数量激增，车辆的诊断需求早已超越了最初的设计范畴。UDS作为ISO 14229标准定义的一套通用诊断服务，其核心目标是为所有现代车载ECU提供一套统一的诊断通信规范。

UDS本身独立于底层物理总线，可以运行于CAN、FlexRay、以太网或LIN等多种网络介质之上。其中基于CAN的实现（UDSonCAN）是最为普遍的应用形态。CAN总线负责数据的物理传输和链路控制，UDS则定义了诊断数据的格式、含义和处理逻辑——二者在OSI七层模型中分工明确，各司其职。

本文将从OSI模型出发，系统讲解CAN与UDS的分层架构、协议栈组成以及二者之间的协同工作机制。

一、OSI七层模型与车载诊断的对应关系

OSI（开放系统互连）模型将网络通信划分为七个层次，每一层承担特定的功能，并为上下层提供标准化的服务接口。

在UDSonCAN的体系中，CAN标准与UDS标准分别覆盖了OSI模型的不同层级：

OSI层级

对应标准

职责说明

应用层（Layer 7）

ISO 14229-1

UDS服务定义：请求/响应格式、SID、子功能、NRC

表示层（Layer 6）

—（UDS直接承载于应用层）

通常与ISO 27145-2关联，用于基于CAN的车辆诊断

会话层（Layer 5）

ISO 14229-2

诊断会话管理、服务原语接口（请求/指示/确认）

传输层（Layer 4）

ISO 15765-2（CAN网络/传输层）

多帧分割与重组（SF/FF/CF/FC）、流控制、定时管理

网络层（Layer 3）

—（CAN无独立网络层）

寻址信息（N_SA、N_TA）嵌入在CAN ID或N_AI中

数据链路层（Layer 2）

ISO 11898-1

CAN协议帧格式、仲裁、错误检测、位填充

物理层（Layer 1）

ISO 11898-2

差分信号传输、位时序、总线拓扑、波特率

表格的数据来源于UDS阅读文档的OSI分层架构整理，该文档完整描述了UDS在各层中的对应标准。

以下逐一展开各层的详细功能及其在UDSonCAN中的具体实现。

二、物理层（Layer 1）与数据链路层（Layer 2）：CAN协议的核心 2.1 物理层（ISO 11898-2）

CAN总线的物理层由ISO 11898-2标准定义，核心内容是采用双绞差分信号传输，每条总线由两条线组成：CAN_H和CAN_L。差分信号的逻辑规则为：CAN_H > CAN_L时代表显性位（逻辑0），CAN_H ≤ CAN_L时代表隐性位（逻辑1）。

这种差分设计具有出色的抗电磁干扰能力，尤其适合汽车环境中电动机、逆变器等强干扰源并存的工作场景。高速CAN的典型通信速率为125 kbps至1 Mbps，总线最大长度在1 Mbps速率下为40米，足以覆盖绝大多数乘用车的车身网络长度。

CAN收发器负责将CAN控制器的逻辑电平信号转换为总线差分信号，两者功能分工明确——控制器处理协议逻辑，收发器完成物理信号转换。

2.2 数据链路层（ISO 11898-1）

数据链路层的功能主要由CAN控制器实现，涵盖以下几个关键方面：

（1）CAN帧结构

CAN定义了四种报文类型：数据帧、远程帧、错误帧和过载帧。在UDS诊断通信中，最常用的是数据帧，其结构包含以下字段：

• 帧起始（SOF）：标志一个帧的开始

• 仲裁场：包含11位标准ID（CAN 2.0A）或29位扩展ID（CAN 2.0B）以及用于仲裁的RTR位

• 控制场：包含IDE位（区分标准帧/扩展帧）和4位DLC（数据长度码，0-8字节）

• 数据场：最多8字节的有效载荷

• 校验场：15位CRC用于错误检测

• 应答场：接收节点确认正确接收的时隙

• 帧结束（EOF）：标志帧的结束

（2）逐位仲裁机制

CAN总线采用载波侦听多路访问/冲突避免的访问控制机制。当多个节点同时发送时，总线通过逐位比较ID优先级来完成无损仲裁——ID值越小（显性位越多），优先级越高。这意味着，在UDSonCAN中，诊断报文的CAN ID值需要合理分配，以确保关键诊断请求能够优先获得总线访问权。

（3）错误处理机制

ISO 11898-1定义了一套完整的错误检测和错误计数体系。每个CAN控制器内置发送错误计数器（TEC）和接收错误计数器（REC），当错误计数达到特定阈值（96、128、256）时，节点会依次进入"错误主动"、"错误被动"和"总线关闭"状态。CAN收发器则是实现物理信号转换的组件，负责将控制器的逻辑电平转换为总线差分信号，两者功能分工明确——控制器处理协议逻辑，收发器完成物理信号转换。

三、传输层与网络层（Layer 3/4）：ISO 15765-2的核心使命 3.1 为什么要引入传输层？

经典CAN协议的数据场最大为8字节。然而，诊断应用中的数据包常常远超这一限制——例如VIN码为17字节，软件刷写数据可达数MB。传输层的核心使命就是解决这种长度矛盾：将应用层的大数据包拆分成多个8字节的CAN帧进行传输，在接收端再重组还原。这一机制使得UDS的诊断能力不再受限于底层总线的帧长度。

ISO 15765-2定义了完整的网络层协议，主要功能包括：将诊断服务数据转换为CAN数据帧、最多支持4095字节的多帧数据传输、错误处理与时间管理、以及发送/接收完成状态报告。

3.2 网络层协议数据单元（N_PDU）

网络层的数据结构被称为N_PDU（Network Protocol Data Unit），它由三部分构成：

• N_AI：网络地址信息（隐含源地址N_SA、目标地址N_TA和寻址类型）

• N_PCI：协议控制信息（标识帧类型和长度信息）

• N_Data：网络层数据（承载上层应用数据）

网络层定义了四种N_PDU类型，通过N_PCI进行区分：

N_PCI类型

高4位值

单帧（SF）

0x0

数据长度 ≤ 7字节

首帧（FF）

0x1

多帧传输的第一帧，包含总长度（12位）

连续帧（CF）

0x2

多帧传输的后续帧，包含顺序编号SN（4位）

流控制帧（FC）

0x3

接收方对发送方的流量控制指令

基于ISO 15765-2的定义，N_PDU有四种类型，用于建立对等实体间的通信，网络层通过协议控制信息（N_PCI，Protocol Control Information）区分这四种类型，每一个N_PDU都只有一个N_PCI。

3.3 单帧传输（SF）

当诊断数据的有效字节数不超过7字节时，网络层采用单帧传输。N_PCI占用1个字节：高4位为0（标识SF），低4位为SF_DL（有效数据长度）。

示例：诊断请求10 02共2字节，单帧的N_PCI为0x02，完整帧格式为02 10 02，其中02表示单帧有2个有效字节。

3.4 多帧传输机制

多帧传输采用"首帧—流控—连续帧"的三段式交互流程。网络层根据需要将诊断数据拆分为一个首帧和多个连续帧——首帧包括分段数据的总长度信息以及若干初始数据；每个连续帧的第一个字节包含拆分的顺序编号，后面的七个字节存放诊断数据，接收端在接收到连续帧后根据数据帧的编号重组服务数据。

流控制帧（FC）是关键的控制机制，它由三个字节构成：

• FS（流状态）：0=继续发送，1=等待，2=溢出

• BS（块大小）：允许发送的连续帧数量（0表示无限制）

• STmin（最小间隔时间）：连续帧之间的最小时间间隔

流控制机制的主要作用是使发送端动态适应接收端网络层的处理能力。

四、会话层（Layer 5）：ISO 14229-2的核心接口

会话层的标准化是UDS区别于其他诊断协议的关键特征之一。ISO 14229-2规定了一组通用的服务原语接口，位于OSI第5层（会话层）与第4层（传输层）之间。这些原语通过服务请求、指示和确认机制，使得ISO 14229-1定义的UDS服务能够与任意底层通信协议（CAN、FlexRay、以太网、K-Line）无缝对接，有效确保了协议栈各层之间的解耦。

ISO 14229-2定义了四种核心原语：

• Request：上层向下层请求执行某项服务

• Indication：下层向上层指示收到了某项服务请求

• Response：下层向上层返回服务执行结果

• Confirm：上层向下层确认收到响应

ISO 14229-2:2013标准规定了一个通用的服务原语接口，位于OSI传输层与会话层之间，通过服务请求/确认/指示原语实现UDS与各种以"DoXYZ / CoXYZ"命名的通信协议的无缝集成。当前版本ISO 14229-2:2021延续了相同的设计理念。

ISO 14229-2的接口抽象能力允许UDS协议栈横跨CAN、LIN、FlexRay、以太网等多种物理介质。在AUTOSAR架构中，这些原语通常由PduR模块实现，负责DCM（UDS应用层）与CanTp（CAN传输层）之间的消息传递。

五、应用层（Layer 7）：UDS诊断服务的核心 5.1 UDS在AUTOSAR中的三层实现架构

在应用层与传输层之间的交互中，诊断服务数据的请求与响应严格按照ISO 14229-1规定的格式封装，AUTOSAR标准将UDS的软件实现进一步拆分为三个子层：DSL（诊断会话层）、DSD（诊断服务分发层）和DSP（诊断服务处理层）。

DSL（诊断会话层）：管理诊断通信的状态机，包括默认会话与编程会话的切换跟踪。在上位机诊断请求的边界之外，ECU在S3Server超时后会自动回退到默认会话。DSL还严格控制P2与P2时间参数，并管理安全访问等级（配合27服务跟踪Lock/Unlock状态）。P2_Server的定义是：ECU收到请求后必须在此时间内给出响应；P2_Server则在ECU发出NRC 0x78后允许其获得更多处理时间。

DSD（诊断服务分发层）：负责对接收到的诊断请求进行有效性校验，包括检查SID是否为当前架构支持、是否被允许在当前会话和安全等级下执行，以及验证诊断报文的有效数据长度。

DSP（诊断服务处理层）：执行具体业务逻辑，如切换诊断会话、读写DID（数据标识符）、获取DTC（故障诊断码）信息、例程控制等。

5.2 诊断请求与响应格式

ISO 14229-1定义了诊断报文的编码规范。诊断请求由SID（Service Identifier，1字节）、可选的Sub-function（1字节）和随后的数据参数构成。

消息类型

格式规则

示例

肯定响应

`SID

0x40` + [Subfunction] + 参数

否定响应

0x7F + SID + NRC

10 02 → 7F 10 12

肯定响应的SID = 请求SID + 0x40，这一规则的语义是"请求服务ID的bit6被置1"。否定响应由3字节组成：第一个字节为0x7F，第二个字节为原始的请求SID，第三个字节为NRC（Negative Response Code），用于指示ECU无法处理该请求的具体原因。

若服务不支持子功能，请求格式为SID+具体数据，肯定响应格式为(SID+0x40)+具体数据。例如，22服务（ReadDataByIdentifier）就没有子功能，诊断仪直接以22 DID_H DID_L格式请求，ECU以62 + DID + 数据内容回复。

5.3 核心UDS服务概览

服务ID

服务名称

功能说明

0x10

诊断会话控制

切换默认/编程/扩展诊断会话

0x11

ECU复位

请求ECU执行特定类型的复位

0x22

读取数据标识符

从ECU读取特定DID的参数值

0x27

安全访问

通过种子-密钥机制解锁敏感诊断服务

0x2E

写入数据标识符

向ECU写入特定DID的参数值

0x19

读取DTC信息

读取ECU存储的故障码及其状态

0x14

清除诊断信息

清除ECU中的故障码记录

0x31

例程控制

启动/停止ECU内部的特定测试例程

0x34/0x36/0x37

刷写服务

软件下载与升级

在AUTOSAR的DCM规范中，0x10服务用于切换诊断会话；22/2E用于读写标定参数或传感器数据；19用于从DEM获取当前故障码信息；14请求DEM清除故障内存；31启动/停止/查询ECU内部特殊例程；34/36/37是在Bootloader刷写流程中用于请求下载数据、传输数据切片和退出传输的核心服务。

六、诊断时间参数体系

为了保证诊断通信的可靠性，UDS定义了一套严格的时间参数体系：

参数

角色

定义

P2_Server

ECU

收到请求后到发送第一帧响应（肯定或否定）的最大允许时间

P2*_Server

ECU

发出NRC 0x78后到发送最终响应的附加时间

S3_Server

ECU

无请求活动状态下保持当前会话的非活动超时时间，超时后自动回退到默认会话

P2_Client

诊断仪

发送请求后等待第一帧响应的超时时间

P2*_Client

诊断仪

接收到NRC 0x78后继续等待最终响应的超时时间

P2_Server指ECU收到请求消息后发送第一帧响应（肯定或否定）的时间；P2*_Server指ECU发出响应挂起（NRC 0x78）后被允许发送最终响应的附加时间。在AUTOSAR DSL实现中，若ECU无法在P2时间内完成处理（例如正在写入Flash），DSL必须向诊断仪发送0x7F 0x78（Response Pending），并启动P2*定时器争取更多处理时间。

七、CAN诊断寻址机制

UDSonCAN定义了两种寻址模式，通过CAN ID的分配来实现：

• 物理寻址（点对点）：诊断请求报文中的CAN ID指向唯一的ECU。每个ECU分配一对CAN ID——一个用于接收Tester的请求，一个用于发送响应。例如，若物理寻址基地址为0x700，Tester节点地址为0x01，则该ECU的物理寻址请求ID为0x701，ECU响应ID为0x709。物理寻址在ECU所支持的服务中都可以访问。

• 功能寻址（广播式，一对多）：诊断请求发送到一组ECU，所有支持该功能寻址的ECU同时接收并处理。功能寻址CAN ID在标准帧格式中通常为0x7DF。功能寻址一般支持的服务包括10、11、28、3E、85、22、14、19等，而27服务（安全访问）及需要写/修改敏感数据的服务通常禁止使用功能寻址。

物理寻址是一个诊断仪对一个ECU的一对一通信；功能寻址是诊断仪向一组ECU的一对多广播。两种寻址方式在NRC响应规则上也有所不同：功能寻址对于某些否定响应码（如11、12、31、7E、7F）不产生响应，而物理寻址对所有的NRC都需要响应。

在实际AUTOSAR配置中，这两种方式通常预先配置在DCM模块的DcmDsl子模块中，物理寻址专门用于读/写特定ECU的数据、编程下载或故障码等一对一操作；功能寻址常用于同时唤醒/休眠整个网络、广播清除所有DTC或同步复位等需同时作用于多个ECU的场景。

八、应用视角的典型交互示例

以下通过一个实际场景，完整展示诊断请求从诊断仪发出到ECU响应的全过程：

假设车辆下线检测（EOL）环节中，诊断仪需要读取某ECU的软件版本号。硬件环境为：ECU的物理寻址请求CAN ID=0x701，响应CAN ID=0x709，诊断会话为默认会话（0x10服务子功能=0x01）。

步骤一：诊断仪构建请求并发送

诊断仪在应用层构造UDS诊断请求：SID=0x22（ReadDataByIdentifier），DID=0xF190（软件版本号对应的数据标识符）。请求数据22 F1 90共3字节，小于7字节，适配单帧传输。传输层添加N_PCI=0x03（高4位0+低4位3），得到完整CAN数据场03 22 F1 90。CAN报文在数据链路层封装后被发送到CAN总线上，CAN ID=0x701。

步骤二：ECU接收并处理

ECU数据链路层在CAN ID=0x701上收到CAN帧，剥离CAN ID后的数据场03 22 F1 90递交给传输层。传输层解析N_PCI=0x03（SF_DL=3），确认这是一个单帧、有效数据长度为3字节，提取诊断请求22 F1 90，通过PDU路由器递交给应用层的DCM模块。DCM中的DSD层校验SID 0x22和DID 0xF190有效性，DSP层调用SW-C接口读取Flash中存储的软件版本号（假设为"V1.2.3"，编码为01 02 033字节）。

步骤三：ECU构建并发出响应

DSP层构造UDS肯定响应：SID=0x62（22+0x40），加上DID 0xF190和数据01 02 03，响应数据62 F1 90 01 02 03共6字节，再次适配单帧。传输层添加N_PCI=0x06，完整数据场06 62 F1 90 01 02 03；数据链路层在CAN ID=0x709上发送。诊断仪接收后解析出肯定响应中的软件版本号01 02 03，解码为"V1.2.3"。

九、UDS与CAN的协同机制总结

CAN标准与UDS在OSI模型中的分工可以概括为：**CAN定义"如何传输"，UDS定义"传输什么"**：

• CAN承担底层通信（物理层与数据链路层）：负责总线访问仲裁、帧的错误检测与重传、物理信号的收发

• UDS涵盖会话层与应用层：负责会话状态的维持与切换、诊断服务的解析与执行、肯定/否定响应的生成与处理

中间的ISO 15765-2传输层则扮演了关键的桥梁角色。它一方面从ISO 14229-2会话层接收诊断服务数据，通过分段、流控制和重组等机制适配CAN的8字节帧长度限制；另一方面处理来自CAN数据链路层的诊断响应数据并重组为上层的UDS消息。

各层协议数据单元的封装关系如下：

• 应用层定义了A_PDU（UDS诊断消息）

• 传输层将A_PDU映射为N_PDU（单帧/多帧分组）

• 数据链路层将N_PDU封装为L_PDU（CAN帧）

完整的UDS通讯报文由CAN ID、N_PCI、SID和DATA四个核心要素构成——N_PCI由传输层CANTp模块实现，将应用层消息拆分为多个8字节CAN帧以兼容CAN的数据长度约束；SID根据ISO 14229预定义的表来标识当前诊断请求的类型。

正是ISO 14229-2抽象出的标准化服务原语接口，确保了这种多层封装与解封装在任何底层传输协议下都保持一致的交互方式，使UDS协议栈具有良好的跨平台和跨网络扩展性。理解这一分层架构，有助于在实际诊断开发中更准确地定位问题——从CAN ID冲突到网络层多帧重组超时，再到应用层NRC的否定响应原因解析，每一层的排查视角各有侧重，而有效的诊断通信恰恰依赖于各层的无偏差协同。

参考文献

[1] ISO 11898-1:2015, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling [6†L8-L10]

[2] ISO 11898-2:2016, Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access unit [18†L5-L7]

[3] ISO 14229-1:2020, Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer [14†L8-L18]

[4] ISO 14229-2:2021, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services [4†L11-L17]

[5] ISO 15765-2:2016, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2: Transport protocol and network layer services [10†L5-L18]

[6] ISO 15765-3:2004, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 3: Implementation of unified diagnostic services (UDS on CAN) [19†L3-L4]

[7] AUTOSAR Specification of Diagnostic Communication Manager (DCM) [12†L6-L26]