深入理解 UDS 31 服务：诊断例程控制的实战解析

在现代汽车电子系统中，ECU 的功能日益复杂，诊断不再是简单的“读故障码”操作，而是贯穿整车生命周期的关键能力。OTA 升级、产线刷写、安全访问、远程标定……这些高阶场景背后，都离不开一个强大而灵活的机制——UDS 31 服务（Routine Control）。

它不像 10 会话控制或 27 安全访问那样频繁出现，但一旦涉及底层硬件操作或定制化流程，它就是那个“真正干活的人”。今天，我们就抛开术语堆砌，从工程实践角度，彻底讲清楚UDS 31 服务的数据传输格式、工作原理与真实开发中的关键细节。

为什么需要 Routine？常规读写搞不定的事

你有没有遇到过这种情况：

• 要刷新 ECU 程序，得先擦除一大块 Flash；
• 想做传感器出厂校准，需要执行一段特定激励序列；
• 安全模块要求生成动态种子，还得配合加密算法运行；

这些都不是“读个 DTC”或者“写个参数”能解决的问题。它们本质上是一段运行在 ECU 内部的专用程序逻辑，我们称之为“诊断例程”。

而 UDS 31 服务，就是用来启动、停止和查询这类例程状态的标准接口。它是 ISO 14229 协议里为数不多允许“执行动作”的服务之一，也是实现高级诊断功能的核心支柱。

📌 简单说：
-22服务是“问你要不要苹果” → 读数据
-31服务是“让你去果园摘苹果” → 执行任务

数据帧长什么样？一文看懂通信结构

UDS 31 服务基于标准 CAN 报文传输，通常使用 ISO-TP 分段处理长消息。它的基本请求/响应格式非常清晰：

[SID] [SubFunction] [RID_H] [RID_L] [Input Data...]

请求报文（Tester → ECU）

响应报文（ECU → Tester）

[Response SID] [SubFunction] [RID_H] [RID_L] [Output Data...]

其中：
-响应 SID = 请求 SID + 0x40→ 所以31变成71
- 输出数据长度由具体例程决定，建议首字节表示后续有效数据长度（Length-Prefixed）

比如你想启动一个 Flash 擦除任务：

Tx: 31 01 F1 01 00 80 // 启动 RID=F101，参数：偏移地址 0x80000 Rx: 71 01 F1 01 // 成功启动，无返回数据

再比如查询结果：

Tx: 31 03 F1 01 Rx: 71 03 F1 01 01 00 // 返回 1 字节状态，值为 0x00（成功）

看到没？结构极其简洁，但背后的实现却大有讲究。

核心三板斧：三种子功能详解

31 服务的灵魂在于它的三个子功能，每个都有明确语义，不能乱用。

实战要点提醒：

• 启动后别卡住：某些操作（如整片 Flash 擦除）可能耗时数秒。如果你在Start时就让 ECU 阻塞等待完成，会导致整个诊断链路超时（P2Server timeout）。正确做法是：快速返回71 01 ...表示已受理，后台异步执行。
• 停止要有意义：不是所有例程都能“优雅终止”。比如 Flash 已经开始擦除，中途停不下来。此时应拒绝Stop请求，并返回否定响应NRC=0x22 (ConditionsNotCorrect)。
• 结果查询要稳定：即使例程已完成，0x03至少应在下一次重启前可查。否则售后工具无法确认历史操作是否成功。

RID 怎么分？别拍脑袋，要有规划！

Routine Identifier是 16 位无符号整数（0x0000 ~ 0xFFFF），其中0x0000被保留用于否定响应，实际可用范围从0x0001开始。

但你怎么分配这些 ID？随便给吗？

当然不行！一个成熟的团队一定会制定RID 编码规范，便于跨项目复用和工具识别。

推荐编码策略（按功能域划分）

这样做的好处显而易见：
- 新人接手代码一看就知道F1xx是干啥的；
- ODX 文件可以批量导入，诊断仪自动识别功能；
- 减少不同 ECU 之间的 RID 冲突风险。

输入输出数据怎么设计？别让协议变成黑盒

很多初学者只关注启停命令，却忽略了Input/Output Data 的结构定义，结果导致后期维护困难、工具兼容性差。

输入数据（Input Data）

这是你传给例程的“指令包”，比如：

• 起始地址、长度（用于 Flash 操作）
• 校准模式标志位
• 密钥类型选择

📌强烈建议采用 TLV 或固定结构体方式组织数据，并在 ARXML/DBC 中明确定义。

例如：Flash 擦除参数结构体

typedef struct { uint32_t startAddr; // 地址（虽然只有2字节可用，也可扩展） uint16_t length; // 长度（扇区数） } FlashEraseConfig;

然后在Start函数中解析：

uint8_t FlashErase_Start(const uint8_t* inData, uint8_t* outData) { uint32_t addr = ((uint32_t)inData[0] << 16) | ((uint32_t)inData[1] << 8) | inData[2]; uint8_t sectors = inData[3]; if (!IsValidAddress(addr, sectors)) { return 0xFF; // 错误码 } EraseInBackground(addr, sectors); // 异步启动 return 0x00; // 成功接收 }

输出数据（Result Data）

这是例程执行后的“成绩单”，常见形式包括：

• 执行状态（0x00 成功，0x01 失败，0x02 超时等）
• 实际耗时（毫秒）
• 校验和比对结果
• 自动生成的随机数（如种子）

输出数据第一字节通常作为长度前缀，方便上位机解析：

// 示例：返回 3 字节数据，内容为 [状态, 时间高, 时间低] outData[0] = 3; outData[1] = status; outData[2] = (time >> 8) & 0xFF; outData[3] = time & 0xFF; *outLen = 4;

如何编写 ECU 端处理逻辑？一张表搞定调度

下面是一个贴近真实项目的 C 语言实现框架，采用静态注册表方式管理所有例程，适合中小规模系统。

#include "Dcm.h" // 例程状态枚举 typedef enum { ROUTINE_IDLE, ROUTINE_RUNNING, ROUTINE_COMPLETED, ROUTINE_FAILED } RoutineStateType; // 函数指针类型定义 typedef uint8_t (*StartFuncType)(const uint8_t*, uint8_t*); typedef uint8_t (*StopFuncType)(void); typedef uint8_t (*ResultFuncType)(uint8_t*); // 例程控制块 typedef struct { uint16_t routineId; RoutineStateType state; StartFuncType start; StopFuncType stop; ResultFuncType result; } RoutineControlBlock; // 外部声明各例程处理函数 extern uint8_t FlashErase_Start(const uint8_t*, uint8_t*); extern uint8_t FlashErase_Stop(void); extern uint8_t FlashErase_Result(uint8_t*); // 注册表（实际项目可通过配置工具生成） const RoutineControlBlock RoutineTable[] = { {0xF101, ROUTINE_IDLE, FlashErase_Start, FlashErase_Stop, FlashErase_Result}, {0xF301, ROUTINE_IDLE, SeedGen_Start, NULL, SeedGen_Result }, // 更多例程... }; #define ROUTINE_COUNT (sizeof(RoutineTable)/sizeof(RoutineTable[0])) Std_ReturnType Dcm_RoutineControl( uint8_t subFunc, uint16_t rid, const uint8_t* inData, uint8_t* outData, uint8_t* outLen ) { for (int i = 0; i < ROUTINE_COUNT; i++) { if (RoutineTable[i].routineId != rid) continue; switch(subFunc) { case 0x01: // Start if (RoutineTable[i].state != ROUTINE_IDLE) { return DCM_E_CONDITIONS_NOT_CORRECT; // 正在运行 } if (RoutineTable[i].start) { outData[0] = RoutineTable[i].start(inData, &outData[1]); *outLen = outData[0] + 1; RoutineTable[i].state = ROUTINE_RUNNING; return E_OK; } break; case 0x02: // Stop if (RoutineTable[i].state == ROUTINE_RUNNING) { if (RoutineTable[i].stop) RoutineTable[i].stop(); RoutineTable[i].state = ROUTINE_IDLE; return E_OK; } return DCM_E_REQUEST_OUT_OF_RANGE; case 0x03: // Query Result if (RoutineTable[i].state == ROUTINE_IDLE) { return DCM_E_REQUEST_SEQUENCE_ERROR; // 尚未启动 } if (RoutineTable[i].result) { outData[0] = RoutineTable[i].result(&outData[1]); *outLen = outData[0] + 1; return E_OK; } break; default: return DCM_E_SUB_FUNCTION_NOT_SUPPORTED; } } return DCM_E_ROUTINE_NOT_SUPPORTED; // RID 不存在 }

关键设计思想：

• 集中注册，统一调度：新增例程只需往表里加一行，主逻辑不动；
• 状态机驱动：防止非法状态迁移（如重复启动）；
• 函数指针解耦：核心调度层不依赖具体业务逻辑；
• 错误码标准化：返回 AUTOSAR 规范的否定响应码，利于工具识别。

常见坑点与调试秘籍

别以为写了代码就万事大吉。以下是在真实项目中踩过的坑，记住了能少熬两个通宵。

❌ 坑点1：长操作阻塞导致链路超时

现象：发送31 01 F101后，Tester 收不到响应，最终报 “Timeout”。

原因：你在Start函数里直接调用了HAL_FLASH_Erase(...)并等待完成，耗时超过 P2Server 定时器（通常是 50ms~2s）。

✅解决方案：
- 启动后立即返回；
- 使用定时器或任务轮询检测完成状态；
- 在Result查询中反馈最终结果。

❌ 坑点2：多个 Tester 并发控制引发资源冲突

现象：两个诊断仪同时尝试擦除 Flash，导致数据损坏。

✅解决方案：
- 使用互斥锁保护共享资源（如 Flash 控制器）；
- 在Start前检查是否有其他例程正在运行；
- 必要时返回NRC=0x31 (RequestOutOfRange)或0x24 (RequestSequenceError)。

❌ 坑点3：输入参数没校验，越界访问炸了

现象：传了个非法地址0xFFFFFFFF，ECU 直接 HardFault。

✅解决方案：
- 所有输入必须做边界检查；
- 对关键操作增加 CRC 校验；
- 敏感例程必须处于扩展会话 + 安全解锁状态。

最佳实践清单：写出靠谱的 31 服务

结语：掌握 31 服务，才真正掌控诊断主动权

UDS 31 服务看似低调，实则是连接诊断需求与底层执行的桥梁。它不像 22/2E 那样简单直观，也不像 34/36/37 刷写流程那样庞大复杂，但它赋予了诊断系统“动起来”的能力。

无论是 OTA 升级中的分区擦除，还是产线测试中的自动化流程，亦或是远程触发自检程序，背后都是 31 服务在默默支撑。

当你不再只是“调用 API”，而是真正理解了它的数据格式、状态流转和工程约束，你就已经迈入了专业诊断工程师的行列。

如果你在项目中实现了某个有趣的诊断例程（比如“一键复位所有传感器”），欢迎在评论区分享你的 RID 和设计思路！我们一起把车“玩”明白。