我的汽车进步之路-ISO 15765

ISO 15765（DoCAN/CAN-TP）协议深度解析

ISO 15765 全称道路车辆 --- CAN 总线诊断通信（Diagnostic communication over Controller Area Network, DoCAN） ，行业内常称其为 CAN-TP（CAN 传输协议） ，是车载诊断领域的核心基础协议之一。它对应 OSI 模型的网络层（第 3 层）+ 传输层（第 4 层），底层基于 ISO 11898 定义的 CAN/CAN FD 数据链路层，上层承载 UDS（ISO 14229）、OBD 等诊断应用层服务，核心解决「CAN 单帧载荷有限，无法传输长诊断报文」的问题。

一、协议整体架构与组成

ISO 15765 系列标准分为 4 个部分，核心逻辑全部集中在第 2 部分：

ISO 15765-1：总则 定义通用术语、缩略语、协议整体框架，是整个系列的基础说明文档。
ISO 15765-2：传输协议与网络层服务（核心） 协议的核心本体，定义了 CAN 总线上长数据的分段、重组、流控机制，也就是常说的 CAN-TP 协议。既支持经典 CAN（8 字节载荷），也兼容 CAN FD（最大 64 字节载荷）ISO。
ISO 15765-3：UDS on CAN 实现（已废止） 旧版标准中定义了统一诊断服务（UDS）在 CAN 总线上的实现规范，目前已被 ISO 14229-3（UDS 第 3 部分：CAN 总线会话层与诊断服务映射） 完全替代，不再属于 15765 体系ISO。
ISO 15765-4：排放相关系统要求 针对 OBD-II、WWH-OBD 等法规强制的排放诊断，规定了排放相关 ECU 的诊断通信强制规范，包括 CAN ID 分配、物理层参数、传输协议约束等，是满足排放法规的必选标准。

二、核心机制：ISO 15765-2 网络层详解

这部分是协议的灵魂，所有长诊断报文（如读大量故障码、ECU 刷写数据）的可靠传输都依赖这套机制。

2.1 核心功能

短数据直接封装为单帧传输，长数据自动分段拆分，接收端按序重组；
通过流控帧协调收发双方的传输节奏，匹配接收端缓冲区能力，避免数据溢出；
经典 CAN 下支持最大 4095 字节的单条报文（12 位长度字段），满足绝大多数诊断场景需求。

2.2 四种帧类型（N_PDU）

网络层协议数据单元（N_PDU）分为 4 种，通过帧首的协议控制信息（N_PCI） 区分。N_PCI 位于数据段的第一个字节，高 4 位为帧类型标识。

帧类型	简称	PCI 高 4 位	核心作用	经典 CAN 载荷结构
单帧（Single Frame）	SF	0000（0x0）	传输短数据，一帧完成交互	第 1 字节：低 4 位为数据长度第 2~8 字节：有效数据（最多 7 字节）
首帧（First Frame）	FF	0001（0x1）	多帧传输第一帧，声明总数据长度	第 1 字节：低 4 位为总长度高 4 位第 2 字节：总长度低 8 位（共 12 位）第 3~8 字节：有效数据（6 字节）
流控帧（Flow Control）	FC	0011（0x3）	接收方回复，控制发送节奏	第 1 字节：低 4 位为流控状态 (FS)第 2 字节：块大小 (BS)第 3 字节：最小帧间隔 (STmin)第 4~8 字节：保留
连续帧（Consecutive Frame）	CF	0010（0x2）	多帧传输的后续数据帧	第 1 字节：低 4 位为帧序列号 (0~F 循环)第 2~8 字节：有效数据（7 字节）

流控帧的三种状态（FS）

0x0（CTS, Continue to Send）：允许发送，发送方可按约定参数继续发送连续帧
0x1（WAIT）：接收方忙，发送方暂停发送，等待下一个流控帧
0x2（OVFLW, Overflow）：接收方缓冲区溢出，无法接收，直接终止本次传输

2.3 寻址模式

ISO 15765-2 定义了两套寻址维度：通信目标类型 （物理 / 功能寻址）和 地址编码格式（正常 / 扩展 / 混合 / 正常固定寻址）。

按通信目标分类

物理寻址（Physical Addressing） 点对点一对一通信，用于诊断仪与单个 ECU 的专属通信，比如读取特定 ECU 的故障码、参数配置等。
功能寻址（Functional Addressing） 一对多广播通信，一条报文总线上所有符合条件的 ECU 都会接收并响应，最典型的是 OBD 广播 ID 0x7DF，所有排放相关 ECU 都会响应。

按地址编码格式分类

正常寻址（Normal Addressing） 地址信息完全隐含在 11 位 CAN ID 中，数据段内不携带地址字段。乘用车行业有通用约定：
- 功能寻址请求 ID：0x7DF
- 物理寻址请求 ID：0x7E0 ~ 0x7EF
- 响应 ID = 请求 ID + 8，例如 0x7E0 → 0x7E8 这也是 ISO 15765-4 的强制要求，是乘用车诊断 CAN 最常用的寻址方式。
正常固定寻址（Normal Fixed Addressing） 基于 29 位 CAN ID 的标准化地址编码，典型格式为 0x18DA + 目标地址(TA) + 源地址(SA)，地址信息直接编码在 CAN ID 中，常见于商用车、重卡等遵循 J1939 体系的场景。
扩展寻址（Extended Addressing） 在 CAN 数据段的最开头（N_PCI 之前）增加 1 字节目标地址（TA），相当于把地址放在数据载荷里。可以配合 11 位或 29 位 CAN ID 使用，用于 ECU 数量多、地址空间不足的场景。
混合寻址（Mixed Addressing） 同时使用 CAN ID 寻址 + 数据段中的地址扩展字节（N_AE），包含源地址、目标地址、地址扩展三级地址，主要用于跨网段远程诊断等复杂场景。

2.4 时序参数与超时机制

协议定义了 6 个核心时序参数，所有车载 ECU 都必须满足对应的超时约束，是诊断通信可靠性的基础。

参数	全称	含义	典型超时阈值
N_As	发送方仲裁延时	网络层将帧交给数据链路层 → 帧成功发到总线的最大延时	1000 ms
N_Ar	接收方仲裁延时	数据链路层收到帧 → 帧交给网络层的最大处理延时	1000 ms
N_Bs	发送方缓冲延时	发出首帧 → 收到流控帧的最大等待时间	1000 ms
N_Br	接收方缓冲延时	收到首帧 → 发出流控帧的最大处理时间	1000 ms
N_Cs	发送方连续帧间隔	两个连续帧之间的发送间隔（由 STmin 约束最小值）	-
N_Cr	接收方连续帧超时	两个连续帧之间的最大接收间隔，超时则终止传输	1000 ms

额外约束：N_WFTmax --- 接收方最多可连续发送 FC.WAIT 帧的数量，超过该值发送方直接终止传输，避免无限等待。

2.5 网络层服务原语

网络层向上层（会话层 / 应用层）提供标准化的服务接口，通过服务原语交互：

N_USData.request：上层发起数据传输请求，传入目标地址、数据内容
N_USData.confirm：网络层向上层反馈传输结果（成功 / 失败及错误原因）
N_USData.indication：网络层接收完整报文后，向上层提交数据
N_USData_FF.indication：收到首帧时提前通知上层，便于上层提前分配接收缓冲区
N_ChangeParameter.request/confirm：动态修改协议参数（如超时时间、STmin、BS 等）

三、与 UDS（ISO 14229）的关系

二者是分层协作的关系，经常被混淆，核心差异如下：

维度	ISO 14229（UDS 统一诊断服务）	ISO 15765（DoCAN）
OSI 层级	应用层（第 7 层）+ 会话层（第 5 层）	网络层（第 3 层）+ 传输层（第 4 层）
核心功能	定义诊断服务逻辑：读故障码、安全访问、ECU 刷写、数据读写等	定义 CAN 总线上的传输规则：数据分段、流控、重组
总线依赖性	总线无关，可运行在 CAN、LIN、FlexRay、以太网（DoIP）等多种总线	仅适用于 CAN/CAN FD 总线
安全机制	内置安全访问、身份认证机制	无内置安全能力，仅负责数据可靠传输

简单来说：UDS 管「传什么」，ISO 15765 管「在 CAN 上怎么传」 。车载 UDS 诊断的完整协议栈为： 应用层（ISO 14229-1 UDS服务） → 会话层（ISO 14229-3 CAN映射） → 网络/传输层（ISO 15765-2 CAN-TP） → 数据链路层（ISO 11898 CAN）

四、工程应用关键要点

CAN FD 兼容：2016 版及之后的 ISO 15765-2 完整支持 CAN FD，单帧最大载荷提升至 64 字节，大幅减少多帧传输场景，ECU 刷写等大数据场景速率提升最明显。
流控参数工程配置 ：
- BS（块大小）= 0 表示不分块，发送方可以一次性发完所有连续帧，无需等待后续流控帧，是车载 ECU 的主流配置；
- STmin（最小帧间隔）：常见配置为 0x14（20ms）、0x0A（10ms），配置为 0 表示无间隔全速发送。
多会话并行：协议支持不同地址的传输会话交错进行，网络层通过地址信息区分不同会话，互不干扰。
错误处理：序列号不连续、流控溢出、任意超时触发，都会直接终止本次传输，并向上层报告错误，由应用层决定是否重传。