从零构建基于CAN总线的UDS 31服务通信：实战全解析
你有没有遇到过这样的场景？在产线刷写ECU固件时，设备提示“Flash未就绪”；或者调试ADAS模块自检流程时，反复发送私有命令却无法触发内部逻辑。问题的根源往往不是硬件故障，而是缺少一套标准化、可追溯、跨平台兼容的诊断接口。
这时候，统一诊断服务（Unified Diagnostic Services, UDS）的价值就凸显出来了。而其中的UDS 31服务 —— “请求例程控制”（Routine Control），正是解决这类“执行特定内部操作”需求的关键工具。
本文不讲空泛理论，带你从零开始手把手实现一个完整的基于CAN总线的UDS 31服务通信链路。我们将深入协议细节、拆解传输机制、剖析代码逻辑，并结合真实开发中的“坑点”与应对策略，让你不仅能看懂标准，更能落地写出稳定可靠的诊断代码。
为什么是UDS 31服务？
先来回答一个根本问题：我们已经有CAN通信了，为什么还要搞这么复杂的UDS协议？
答案很简单：为了秩序和互操作性。
想象一下，如果每个ECU厂商都用自己定义的CAN ID和数据格式来启动Flash擦除、执行传感器校准，那上位机软件就得为每种ECU写一套驱动——这显然不可持续。
而UDS作为ISO 14229定义的标准协议，就像车载诊断世界的“普通话”。只要大家都遵守这套规则，就能实现：
- 不同供应商ECU之间的无缝对接
- 通用诊断仪（如CANoe、PCAN-Diag）即插即用
- 自动化测试脚本跨项目复用
在这套标准中，服务ID0x31的作用是：让诊断设备可以远程调用ECU内部封装好的功能模块——这些模块被称为“例程”（Routines）。
它能做什么？
典型应用场景包括：
| 场景 | 动作 |
|---|---|
| OTA升级前准备 | 启动Flash擦除预处理例程 |
| 生产线标定激活 | 执行EEPROM数据加载例程 |
| 故障排查辅助 | 触发某个传感器自检并获取结果 |
| 安全访问解锁 | 运行Seed-Key生成辅助例程 |
你会发现，这些都不是常规数据读写，而是需要主动触发某种行为的操作。这正是31服务的核心定位：对ECU内部状态机的一次“遥控按键”。
协议结构详解：请求与响应如何组织？
要实现31服务，首先要搞清楚它的报文长什么样。
请求帧结构（Tester → ECU）
当诊断仪想让ECU做点什么，它会发送这样一个请求：
[SID][Sub-function][Routine ID High][Routine ID Low][Optional Parameters] 31 01 00 01 ...- SID = 0x31：服务标识符，告诉ECU“我要调用例程控制”
- Sub-function：子功能码，决定具体动作类型
- Routine ID：16位无符号整数，唯一标识一个例程
- 可选参数：某些例程可能需要输入参数（如超时时间、目标地址等）
⚠️ 注意：整个请求通过ISO-TP协议封装后走CAN总线传输，物理层通常是11位标准帧或29位扩展帧。
常见子功能码一览
| 子功能值 | 名称 | 说明 |
|---|---|---|
0x01 | Start Routine | 启动指定例程 |
0x02 | Stop Routine | 停止正在运行的例程 |
0x03 | Request Routine Results | 查询例程执行结果 |
举个例子：
// 想启动ID为0x0001的Flash擦除准备例程 uint8_t request[] = {0x31, 0x01, 0x00, 0x01};这条指令通过CAN发送出去后，ECU就要按规矩办事了。
正响应格式（ECU → Tester）
如果一切顺利，ECU返回正响应：
[PSID][Sub-func][RID_H][RID_L][Result Data...] 71 01 00 01 ...- PSID = 0x71：Positive Response SID = 0x31 + 0x40
- 其余字段回显原始请求内容，便于匹配
- 可携带额外返回数据（例如状态码、执行耗时等）
例如成功启动后的响应：
{0x71, 0x01, 0x00, 0x01} // 无附加数据或带结果的状态查询响应：
{0x71, 0x03, 0x00, 0x01, 0x00} // 最后一字节表示成功负响应处理：错误也要说得清楚
不是每次调用都能成功。当条件不满足时，ECU必须返回负响应，告知Tester失败原因。
格式如下：
[0x7F][SID][NRC]0x7F：负响应服务IDSID：原请求的服务ID（这里是0x31）NRC：负响应码（Negative Response Code）
常见NRC码对照表：
| NRC | 含义 | 典型场景 |
|---|---|---|
0x12 | Sub-function not supported | 发送了不支持的子功能 |
0x22 | Conditions not correct | 当前会话模式不对、安全未解锁 |
0x31 | Request out of range | Routine ID不存在 |
0x33 | Security access denied | 未通过安全认证 |
比如你在普通会话下尝试执行敏感操作，ECU应回：
{0x7F, 0x31, 0x22}✅关键设计原则：永远不要静默忽略非法请求！必须返回明确的NRC，否则Tester将陷入“超时重试→再超时”的死循环。
多帧传输怎么搞？ISO-TP是幕后功臣
现在有个现实问题：CAN单帧最多传8字节数据，但UDS请求/响应可能更长（比如带多个参数的结果查询）。怎么办？
答案就是ISO 15765-2 定义的 ISO-TP 协议—— 它运行在CAN之上，负责把大块数据拆成小包发送，并在接收端重新组装。
四种PDU类型协同工作
| 类型 | 缩写 | 作用 |
|---|---|---|
| 单帧 | SF | 数据 ≤ 7字节，一帧搞定 |
| 首帧 | FF | 第一帧，声明总长度 |
| 连续帧 | CF | 后续数据帧，编号递增 |
| 流控帧 | FC | 接收方控制发送节奏 |
实际通信示例（多帧请求）
假设你要发送一个10字节的请求：
首帧 (FF)
CAN数据域：[0x10][0x0A][D0][D1][D2][D3][D4][D5]
-0x10表示首帧，低4位0x0A=10，表示总长度10字节
- 紧跟6字节有效载荷连续帧 (CF)
第二帧：[0x21][D6][D7][D8][D9]...（其余补0）
-0x21中的1是序列号SN，每帧+1（0~F循环）流控帧 (FC)
接收方回复：[0x30][BS][STmin]
- BS=Block Size，一次允许发多少CF
- STmin=最小间隔时间（ms），防总线拥堵
📌 小贴士：对于典型的31服务请求（仅4~5字节），通常走单帧模式即可，无需复杂分段。但在返回大量结果数据时（如日志导出），就必须启用多帧机制。
核心代码实现：ECU端如何处理31服务？
下面是一个贴近真实项目的C语言框架，专为嵌入式环境优化，已剥离OS依赖，可直接移植到STM32、RH850等平台。
#include <stdint.h> #include "can_iso_tp.h" // 假设已有ISO-TP栈 #include "uds.h" // --- Routine ID 定义 --- #define ROUTINE_ID_ERASE_PREPARE 0x0001 #define ROUTINE_ID_SENSOR_TEST 0x0002 // --- 子功能码 --- #define SUBFUNC_START 0x01 #define SUBFUNC_STOP 0x02 #define SUBFUNC_RESULT 0x03 // --- 负响应码 --- #define NRC_OK 0x00 #define NRC_SUB_NOT_SUPPORTED 0x12 #define NRC_INCORRECT_MESSAGE_LEN 0x13 #define NRC_OUT_OF_RANGE 0x31 #define NRC_SECURITY_DENIED 0x33 #define NRC_CONDITIONS_INCORRECT 0x22 // --- 外部函数（由应用层实现）--- extern uint8_t Routine_ErasePrepare_Start(void); extern void Routine_ErasePrepare_Stop(void); extern uint8_t Routine_ErasePrepare_GetResult(uint8_t *out_data); /** * @brief 处理UDS 31服务主入口 * @param req 数据指针（不含PCI头） * @param len 数据长度 */ void Uds_HandleRoutineControl(const uint8_t *req, uint32_t len) { // 基础长度检查 if (len < 4) { Send_NegativeResponse(0x31, NRC_INCORRECT_MESSAGE_LEN); return; } uint8_t subfunc = req[1]; uint16_t rid = (req[2] << 8) | req[3]; // 必须处于扩展会话才能执行敏感操作 if (!Is_CurrentSession(DIAG_SESSION_EXTENDED)) { Send_NegativeResponse(0x31, NRC_CONDITIONS_INCORRECT); return; } switch (rid) { case ROUTINE_ID_ERASE_PREPARE: Handle_ErasePrepare(subfunc, req, len); break; case ROUTINE_ID_SENSOR_TEST: Handle_SensorTest(subfunc, req, len); break; default: Send_NegativeResponse(0x31, NRC_OUT_OF_RANGE); break; } }分例程处理：以Flash擦除为例
static void Handle_ErasePrepare(uint8_t subfunc, const uint8_t *req, uint32_t len) { uint8_t resp[8] = {0}; uint8_t rlen = 0; switch (subfunc) { case SUBFUNC_START: // 敏感操作需安全解锁 if (!Is_SecurityLevel_Unlocked(LEVEL_03)) { Send_NegativeResponse(0x31, NRC_SECURITY_DENIED); break; } if (Routine_ErasePrepare_Start() == 0) { resp[0] = 0x71; // PSID resp[1] = subfunc; resp[2] = req[2]; // RID H resp[3] = req[3]; // RID L ISO_TP_Send(resp, 4); // 发送正响应 } else { Send_NegativeResponse(0x31, NRC_CONDITIONS_INCORRECT); } break; case SUBFUNC_STOP: Routine_ErasePrepare_Stop(); resp[0] = 0x71; resp[1] = subfunc; resp[2] = req[2]; resp[3] = req[3]; ISO_TP_Send(resp, 4); break; case SUBFUNC_RESULT: { uint8_t result; if (Routine_ErasePrepare_GetResult(&result) == 0) { resp[0] = 0x71; resp[1] = subfunc; resp[2] = req[2]; resp[3] = req[3]; resp[4] = result; ISO_TP_Send(resp, 5); } else { Send_NegativeResponse(0x31, NRC_CONDITIONS_INCORRECT); } } break; default: Send_NegativeResponse(0x31, NRC_SUB_NOT_SUPPORTED); break; } }💡 提示：这里的
ISO_TP_Send()是你使用的ISO-TP库提供的API，自动处理单帧/多帧切换。
实战调试技巧：那些文档不会告诉你的事
纸上得来终觉浅。真正开发中，你会遇到一堆“理论上应该可行，实际上就是不通”的问题。
以下是几个高频踩坑点及解决方案：
❌ 问题1：Tester总是收到超时，没有任何响应
排查方向：
- ✅ 是否正确绑定了CAN RX中断？
- ✅ ISO-TP是否及时发送了Flow Control帧？（尤其在接收多帧时）
- ✅ CAN波特率设置是否一致？（常见错误：Tester设500k，ECU跑250k）
🔍 抓包建议：用PCAN-Explorer或CANalyzer观察是否有
0x7F 0x31 xx帧发出。如果没有，说明ECU连请求都没进协议栈。
❌ 问题2：返回NRC 0x22，但明明已经进了扩展会话
真相往往是：你确实发了10 03进入扩展会话，但ECU内部没有持久化记录当前会话状态！
修复方法：
static uint8_t current_session = DIAG_SESSION_DEFAULT; void Uds_HandleDiagnosticSessionControl(uint8_t target) { if (target == 0x03) { current_session = DIAG_SESSION_EXTENDED; // 返回正响应... } } uint8_t Is_CurrentSession(uint8_t sess) { return current_session == sess; }别忘了清零安全状态！退出会话时应自动降级安全等级。
❌ 问题3：安全访问通过了，还是被拒绝执行
注意权限粒度：不同例程可能要求不同的安全级别。
例如：
- Level 1（Key1）：允许读取日志
- Level 3（Key3）：才允许启动Flash操作
确保你在调用Is_SecurityLevel_Unlocked()时传的是正确的level。
❌ 问题4：多帧传输偶尔失败，数据错乱
最大元凶：STmin 设置太小！
如果你在FC帧中设置STmin=0，意味着“尽快发”，但如果接收方处理慢（比如正在跑电机控制任务），就会丢帧。
✅推荐配置：
Send_FlowControl_Frame(BS: 0, STmin: 10); // BS=0表示无限发，STmin≥10ms既保证效率，又留出CPU处理时间。
架构设计建议：不只是跑通，更要健壮
当你准备把这个功能集成进正式项目时，请考虑以下工程化要点：
1. 资源占用评估
| 组件 | RAM占用估算 |
|---|---|
| ISO-TP缓冲区（最大64K） | ~64 KB |
| UDS任务栈 | ~2KB |
| Routine状态管理 | <1KB |
📌 对于RAM小于64KB的MCU（如S12Z），应限制最大传输长度（如≤2048字节），或采用分块处理策略。
2. 实时性保障
- 将UDS任务优先级设为高优先级（仅次于Safety任务）
- 使用DMA+中断方式收发CAN，避免轮询阻塞
- 在RTOS中为ISO-TP分配独立任务/队列
3. 日志与可观测性
哪怕没有调试接口，也建议加入轻量级追踪手段：
#define UDS_LOG_EVENT(e) do { GPIO_TOGGLE(DEBUG_PIN); } while(0) // 在关键路径插入 UDS_LOG_EVENT(ENTER_31_HANDLER); UDS_LOG_EVENT(SEND_POSITIVE_RESPONSE);配合示波器抓GPIO波形，就能看到协议执行节奏，极大提升现场排错效率。
4. 文档化你的诊断接口
建立一份《UDS服务表》，像这样：
| Service | Routine ID | Name | Sub-func | Session | Security Level | Notes |
|---|---|---|---|---|---|---|
| 0x31 | 0x0001 | Erase Prepare | 01,02,03 | Extended | Level 3 | 用于OTA前准备 |
| 0x31 | 0x0002 | Sensor Selftest | 01,03 | Default | None | 返回0=pass, 1=fail |
这份表格将成为后续自动化测试、产线脚本编写的重要依据。
写在最后：掌握31服务，打开诊断系统的大门
看到这里，你应该已经具备了独立实现UDS 31服务的能力。但这不仅仅是一个功能点的打通，更是你迈入专业车载诊断领域的第一步。
你会发现，一旦建立起标准化的诊断通道，很多原本繁琐的工作都会变得自动化：
- 产线烧写前自动执行“初始化检查”
- OTA升级流程中嵌入“健康度预判”
- 整车下线测试一键触发所有ECU自检
- 远程诊断中动态启用调试日志输出
而这一切，都可以通过一条简单的31 01 xx xxCAN报文来启动。
随着智能汽车对软件迭代速度的要求越来越高，标准化诊断能力不再是“加分项”，而是ECU开发的基础设施。无论是做动力域、车身域还是智驾系统，理解并熟练运用UDS这类核心协议，已经成为每一位汽车电子工程师的必备技能。
如果你正在开发一个新ECU，不妨现在就动手加一个最简单的31服务——比如让LED闪烁5次。当你第一次从CAN卡看到那个绿色的71 01 xx xx响应时，你就真正掌握了“遥控ECU”的钥匙。
如果你在实现过程中遇到了其他挑战，欢迎在评论区分享讨论。
