📚 CAN总线技术系列 · 持续更新中

本系列从差分电气层一路打到 Linux SocketCAN,把"两根线"背后的电气/协议/控制器/驱动/实战全拧成一根线。

👉 想系统追更，戳这里查看完整专栏：
【CAN 技术系列】
👉 其他技术系列专栏，欢迎关注、交流、共同成长：
【SPI 技术系列】 【I2C 技术系列】 【串口技术系列】【RISC-V 架构系列】【Linux内核系列】 【操作系统设计思想系列】 【 Android 系统全景专栏】

本篇定位:CAN 只规定到数据链路层(ID+8字节),怎么用这 8 字节传语义?靠高层协议。本篇讲四大主流高层协议:CANopen(工业自动化,CiA 301)、J1939(商用车,29bit ID 编码)、UDS(汽车诊断,ISO 14229)、ISO-TP(大报文分包,ISO 15765)。读完你理解 CAN 8 字节怎么承载复杂通信,以及 AEGIX 汽车诊断要用 UDS。

CAN 只有 ID+8 字节,高层协议赋予语义
SPI/I2C 是裸字节,语义全靠应用自己定。CAN 也是裸 ID+8 字节,但汽车/工业场景复杂(诊断/大报文/参数组),靠高层协议统一语义。CANopen 定义对象字典,J1939 用 29bit ID 编码参数组,UDS 定义诊断服务,ISO-TP 把 8 字节拼成大报文。汽车芯片,UDS 诊断和 ISO-TP 是必会。这是 L2 协议层收官篇,理解高层协议才算懂 CAN 应用。

一、为什么需要高层协议

1.1 CAN 的局限

CAN 数据链路层只提供:

• ID(11/29bit)+ 8 字节数据(经典)/ 64 字节(FD)
• 无地址(只有 ID)、无大报文、无服务定义

1.2 高层协议补什么

1.3 四大主流高层协议

二、CANopen(CiA 301)

2.1 CANopen 架构

应用层(用户应用) ↑ CANopen 应用层(CiA 301:对象字典/SDO/PDO/心跳) ↑ CAN 数据链路层(ID + 8B) ↑ CAN 物理层(ISO 11898)

2.2 对象字典(Object Dictionary, OD)

CANopen 核心——对象字典,类似寄存器表:

• 每个对象有索引(16bit)+ 子索引(8bit)
• 读写对象 = 读写设备参数

2.3 PDO(Process Data Object,过程数据)

• 实时数据(周期性,高优先级)
• 无需应答,广播或点对点
• 传输类型:周期/事件触发/同步
• ID 范围:0x181~0x57F

TPDO(发送 PDO):节点状态 → 总线 RPDO(接收 PDO):总线 → 节点控制

2.4 SDO(Service Data Object,服务数据)

• 配置数据(非实时,低优先级)
• 读写对象字典,需应答
• 可传 > 8 字节(分段传输)
• ID 范围:0x581~0x67F

SDO 下载(写):Client → Server,写对象字典 SDO 上传(读):Client ← Server,读对象字典

2.5 心跳(Heartbeat)

• 节点周期发心跳(0x700+)
• 其他节点监控,超时 = 节点失联
• 替代 Node Guarding(轮询,少用)

2.6 NMT(Network Management)

• 0x000:NMT 主站控制
• 命令:进入操作/停止/预操作/复位
• 节点状态:初始化/预操作/操作/停止

三、SAE J1939

3.1 J1939 概述

• 商用车(卡车/客车/工程机械)标准
• 基于 CAN 2.0B(29bit ID)
• 用 29bit ID 编码:优先级 + 参数组 + 源/目地址

3.2 29bit ID 编码

29bit ID 结构: ┌──────┬─────┬───────┬──────────────┬──────────────┬──────────┐ │优先级│ 保留│数据页 │ PDU 格式(PF) │ PDU 特定(PS)│ 源地址 │ │ 3bit │ 1bit│ 1bit │ 8bit │ 8bit │ 8bit │ └──────┴─────┴───────┴──────────────┴──────────────┴──────────┘ bit28-26 bit25 bit24 bit23-16 bit15-8 bit7-0

3.3 参数组(PGN)

• PGN = 保留 + 数据页 + PF(+ PS if PDU1)
• 标识一组参数(如发动机转速/水温)
• 常见 PGN:

3.4 PDU1 vs PDU2

• PDU1(PF < 240):PS 是目标地址(点对点)
• PDU2(PF ≥ 240):PS 是参数组扩展(广播)

3.5 传输协议(BAM/RTS)

• PGN 数据 > 8 字节,用传输协议分包
• BAM(Broadcast Announce Message):广播多包
• RTS/CTS(Request/Clear to Send):点对点流控

四、UDS(ISO 14229)

4.1 UDS 概述

• Unified Diagnostic Services,统一诊断服务
• 汽车诊断标准(ISO 14229)
• 基于 CAN + ISO-TP 传输
• 客户端(诊断仪)→ 服务端(ECU)

4.2 诊断 ID

• 请求:0x7E0~0x7E7(诊断仪 → ECU)
• 响应:0x7E8~0x7EF(ECU → 诊断仪)
• 广播:0x7DF(所有 ECU)

4.3 常用服务

4.4 会话控制(0x10)

• 默认会话(0x01):基础诊断
• 编程会话(0x02):刷写 ECU
• 扩展会话(0x03):高级诊断

请求:10 03(进扩展会话) 响应:50 03 00 32 01 F4(成功,参数)

4.5 读数据(0x22)

• 按 DID(Data Identifier)读数据
• DID 是 16bit 标识符

请求:22 F1 90(读 VIN,DID=0xF190) 响应:62 F1 90 <17字节VIN>

4.6 写数据(0x2E)

• 按 DID 写数据
• 需先安全解锁(0x27)

请求:2E F1 90 <17字节VIN>(写 VIN) 响应:6E F1 90(成功)

4.7 安全访问(0x27)

• 防未授权修改
• 流程:请求种子 → 算密钥 → 发密钥

1. 请求:27 01(请求种子) 响应:67 01 <种子> 2. 算:密钥 = f(种子) 3. 请求:27 02 <密钥>(发密钥) 响应:67 02(解锁成功)

4.8 刷写流程(0x34/0x36/0x37)

1. 10 02(进编程会话) 2. 27(安全解锁) 3. 31 01 FF 00(擦除) 4. 34(请求下载:地址+长度) 5. 36(传输数据:分包发) 6. 37(退出传输) 7. 11 01(复位)

4.9 否定响应(NRC)

• 响应 7F + SID + NRC(否定响应码)

五、ISO-TP(ISO 15765)

5.1 ISO-TP 概述

• ISO Transport Protocol,CAN 传输层
• 把 > 8 字节的报文拆成多个 CAN 帧传输
• UDS/J1939 大报文都基于 ISO-TP

5.2 帧类型

5.3 单帧(Single Frame)

• 数据 ≤ 7 字节
• 一帧搞定

单帧:0x0N + N字节(PCI首字节=0x0N,N=数据长度) 例:发 3 字节 [01 02 03] 帧:03 01 02 03(首字节0x03=3字节数据)

5.4 多帧(首帧 + 流控 + 续帧)

数据 > 7 字节,分多帧:

发送 12 字节数据: 1. 首帧(FF):1x xx + 6字节(首字节0x1,后11bit=总长度) 帧:10 0C D1 D2 D3 D4 D5 D6(0x100C=12字节,D1~D6前6字节) 2. 流控制(FC):接收方发 帧:30 00 0A(30=FC,00=继续发,0A=帧间隔10ms) 3. 续帧(CF):发送方发 帧:21 D7 D8 D9 DA DB DC DD(21=CF序号1,D7~DD后6字节) 帧:22 DE DF 00 00 00 00 00(22=CF序号2,DE DF最后2字节)

5.5 流控制(FC)

接收方控制发送方节奏:

• FS(Flow Status):0=继续/1=等待/2=溢出
• BS(Block Size):每发 BS 帧等一次 FC(0=只一次 FC)
• STmin(最小间隔):帧间最小间隔(ms)

FC:30 FS BS STmin 30 00 00 0A → 继续(FS=0),BS=0(只一次FC),STmin=10ms

5.6 分包流程图

发送方 接收方 │ 首帧 FF(总长度+前6B) │ │ ─────────────────────────→ │ │ │ │ 流控制 FC(FS/BS/STmin) │ │ ←───────────────────────── │ │ │ │ 续帧 CF1(序号1,7B) │ │ ─────────────────────────→ │ │ 续帧 CF2(序号2,7B) │ │ ─────────────────────────→ │ │ ...(按BS/STmin节奏) │ │ 续帧 CFn(最后,补0) │ │ ─────────────────────────→ │ │ │ │ 重组完成 │

5.7 ISO-TP 状态机

typedefenum{TP_IDLE,// 空闲TP_SEND_FF,// 发首帧TP_WAIT_FC,// 等流控制TP_SEND_CF,// 发续帧TP_RECV_FF,// 收到首帧TP_SEND_FC,// 发流控制TP_RECV_CF,// 收续帧TP_DONE// 完成}tp_state_t;

5.8 超时

• 等流控制超时(发送方等 FC):通常 1000ms
• 等续帧超时(接收方等 CF):通常 1000ms
• 超时 → 丢弃,重新开始

六、CAN FD 与高层协议适配

6.1 CAN FD 大帧优势

• 数据段 64 字节
• 单帧可传 64 字节(经典 ≤ 7 字节)

6.2 ISO-TP FD 适配

• 单帧扩到 64 字节(很多报文不用分包)
• 多帧时每续帧 64 字节(分包数大减)
• 传输大报文快很多

经典 ISO-TP 传 100 字节:1 FF + 14 CF(7B/帧) FD ISO-TP 传 100 字节:1 FF + 2 CF(64B/帧)

6.3 CANopen FD

• CiA 302(CANopen FD)
• SDO 大块传输(64B/帧)
• 对象字典扩展

6.4 J1939 FD

• J1939-22(FD 传输)
• 参数组数据段 64B
• 兼容经典 J1939 仲裁段

6.5 UDS + CAN FD

• UDS 服务不变,传输层用 ISO-TP FD
• 刷写快(64B/帧,刷写时间大减)
• 诊断仪要支持 CAN FD

七、关键问题 Q&A

Q1:CANopen 的 PDO 和 SDO 有什么区别?

A:

• PDO:过程数据,实时,周期/事件触发,无需应答,高优先级(ID 0x181~0x57F)。传实时控制数据(位置/速度)。
• SDO:服务数据,非实时,读写对象字典,需应答,低优先级(ID 0x581~0x67F)。传配置数据(参数/标定)。

Q2:J1939 怎么用 29bit ID 编码?

A:29bit 分 6 段:优先级(3bit)+ 保留(1)+ 数据页(1)+ PF(8)+ PS(8)+ 源地址(8)。PF < 240 是 PDU1(PS=目标地址,点对点),PF ≥ 240 是 PDU2(PS=参数组扩展,广播)。PGN = 保留+数据页+PF(+PS)。例:发动机转速 PGN 61444,优先级 3。

Q3:UDS 刷写 ECU 完整流程?

A:

1. 10 02(进编程会话)
2. 27(安全解锁:请求种子→算密钥→发密钥)
3. 31 01(擦除 Flash)
4. 34(请求下载:地址+长度)
5. 36(传输数据:分包发,ISO-TP 多帧)
6. 37(退出传输)
7. 11 01(复位 ECU)
8. 验证(10 03 进扩展会话,22 读版本)

Q4:ISO-TP 单帧和多帧怎么分?

A:

• 单帧(SF):数据 ≤ 7 字节,一帧搞定(PCI 首字节 0x0N,N=长度)
• 多帧:数据 > 7 字节,首帧 FF(0x1,总长度+前6B)→ 接收方发流控 FC(0x3,FS/BS/STmin)→ 发送方发续帧 CF(0x2,序号+7B)→ 重组

Q5:ISO-TP 流控制(FC)什么作用?

A:接收方控制发送方节奏,防淹没。FC 三字段:FS(0继续/1等待/2溢出)+BS(每发 BS 帧等一次 FC,0=只一次)+STmin(帧间最小间隔)。例:30 00 0A → 继续,只一次 FC,间隔 10ms。

Q6:CAN FD 对高层协议有什么影响?

A:数据段 64 字节,单帧传更多。ISO-TP 单帧扩到 64B(很多报文不分包),多帧续帧 64B(分包数大减)。UDS 刷写快很多(64B/帧)。CANopen FD(CiA 302)/J1939-22 都是 FD 适配版。仲裁段仍 1M 兼容经典。

八、实战案例

案例 1:CANopen 节点心跳丢失告警

现象:CANopen 从站失联,主站报心跳超时。

分析:从站崩溃/掉线,停止发心跳(0x700+),主站超时检测到。

解决:查从站电源/复位;主站心跳超时进安全状态(停止相关控制)。

案例 2:J1939 发动机转速解析错

现象:读 J1939 报文,发动机转速值不对。

分析:PGN 61444(EEC1),转速是 2 字节,分辨率 0.125 rpm/bit,偏移 0。解析没按比例换算。

解决:按 SPN 定义换算:转速 = raw × 0.125 rpm。注意字节序(MSB 先)。

案例 3:UDS 读 VIN 失败

现象:发 22 F1 90(读 VIN),响应 7F 22 33(安全拒绝)。

分析:VIN 写需要安全解锁(0x27),读 VIN 在默认会话也可能限制。

解决:先进扩展会话(10 03),安全解锁(27),再读 VIN(22 F1 90)。

案例 4:UDS 刷写中途断

现象:ECU 刷写,36 传输数据中途失败。

分析:ISO-TP 续帧超时(接收方等 CF 超时),或 CAN 总线错(错误帧)。

解决:查 CAN 错误(逻辑分析仪),检查刷写流程(34 下载请求的地址/长度对),重刷。

案例 5:ISO-TP 多帧接收方不回 FC

现象:发首帧 FF,接收方不发流控制 FC,超时失败。

分析:接收方没实现 ISO-TP,或 FC 的 ID 配错,或接收方忙(没处理)。

解决:确认接收方实现 ISO-TP,检查 FC 的 CAN ID(请求/响应对应),接收方提高处理优先级。

案例 6:CAN FD 刷写比经典快多少?

现象:CAN FD 刷写 1MB Flash 用 30s,经典 CAN 用 4min。

分析:FD 单帧 64B vs 经典 7B,分包数 1/9,传输快约 9 倍。

解决:CAN FD 刷写是优势,诊断仪和 ECU 都要支持 FD。

案例 7:J1939 多包报文 BAM 传输

现象:J1939 参数组数据 20 字节,收到 BAM(广播多包)。

分析:PGN 59904 请求 → 响应方发 BAM(0x18ECFF)声明多包 → 分包发数据包(0x18EBFF)→ 接收方重组。

解决:实现 J1939 传输协议(BAM),按序号重组,超时丢弃。

案例 8:CANopen SDO 下载写参数

现象:SDO 下载写对象字典 0x2000=0x1234,响应成功但参数没变。

分析:SDO 下载请求格式错(子索引/数据长度),或对象只读。

解决:确认对象可写(OD 定义),SDO 帧格式对(指令+索引+子索引+数据),读回验证。

九、本篇小结与速查

核心要点

• CAN 只有 ID+8B,高层协议赋予语义
• CANopen(CiA 301):对象字典 + PDO(实时)+ SDO(配置)+ 心跳
• J1939:29bit ID 编码(优先级+PGN+源/目地址),商用车
• UDS(ISO 14229):诊断服务(0x10会话/0x22读/0x2E写/0x27解锁/0x34/36/37刷写)
• ISO-TP(ISO 15765):8B → 大报文分包(SF单帧/FF首帧/CF续帧/FC流控)
• UDS 刷写流程:会话→解锁→擦除→下载→传输→退出→复位
• J1939 PDU1(PF<240,点对点)/PDU2(PF≥240,广播)
• ISO-TP 流控:FS(继续/等待/溢出)+ BS(块大小)+ STmin(间隔)
• CAN FD 适配:单帧 64B,刷写快 9 倍,CANopen FD/J1939-22
• 否定响应 NRC:7F + SID + NRC(0x33安全拒绝/0x31超范围/0x78忙)

CANopen 速查

J1939 ID 速查

UDS 服务速查

ISO-TP 帧速查

汽车诊断要点

• UDS 诊断服务必实现(0x10/0x22/0x2E/0x27/0x11)
• ISO-TP 传输层(单帧/多帧/流控/超时)
• 安全访问(0x27)防未授权
• 刷写流程(0x34/0x36/0x37)+ 校验
• CAN FD 刷写优化(64B/帧)
• 否定响应码完整(NRC)
• 诊断 ID 分配(0x7E0~0x7EF)

延伸阅读

• [[04-CAN帧格式]] —— 8 字节数据段承载高层协议
• [[05-CAN仲裁与优先级]] —— 高层协议 ID 分配
• [[08-CAN控制器寄存器与IP架构]] —— 高层协议驱动实现
• [[12-CAN设备驱动实战]] —— UDS/ISO-TP 实战
• [[14-CAN排查手册与速查表]] —— 高层协议速查
• [[07-SPI高级模式-QSPI-Octal-XIP]] —— 对比 SPI 高级模式
• [[07-I2C协议扩展-SMBus-PMBus]] —— 对比 I2C 协议扩展

参考资料

• CiA 301(CANopen 应用层)
• SAE J1939-21(数据链路层)/-71(应用层)
• ISO 14229(UDS)
• ISO 15765-2(ISO-TP)
• CiA 302(CANopen FD)

[[00-CAN技术系列总目录]] · 上一篇:[[06-CAN错误处理与错误帧]] ·下一篇:[[08-CAN控制器寄存器与IP架构]]

✨ 感谢你的阅读 ✨

技术之路漫漫，分享是为了更好地交流。
如果本文的内容对你有启发，希望能得到你的支持：

👍 点赞|⭐ 收藏|👀 关注

如果你在调试过程中遇到了其他问题，
欢迎在评论区 💬留言，我们一起探讨。

关注我，一起交流底层开发的那些事儿！🚀