超详细版UDS 31服务时序分析及错误码解读

深入理解UDS 31服务：从时序控制到错误码实战解析

在汽车电子开发的日常中，诊断不再是售后维修的专属工具，而是贯穿于ECU设计、产线测试、OTA升级乃至整车运维的核心能力。而在众多UDS（Unified Diagnostic Services）服务中，0x31服务——“Routine Control”（例程控制），因其能够主动触发ECU内部特定功能逻辑，成为连接外部指令与底层固件行为的关键桥梁。

它不像0x10（会话控制）那样只是“切换模式”，也不像0x22（读数据）仅是“获取状态”。它是唯一能让诊断设备“启动一个动作”的服务之一。比如：让ECU开始执行Flash擦除准备、激活高压自检、运行EEPROM老化测试，甚至为刷写进入安全就绪状态。

但正因为它的“主动性”，一旦调用失败，排查起来往往比其他服务更复杂。你有没有遇到过这样的场景？

“明明报文发对了，为什么返回NRC 0x22？”
“启动了例程，结果却查不到，是不是ECU没执行？”
“偶尔成功、偶尔失败，像是总线问题？”

本文不讲泛泛而谈的概念，而是带你深入CAN总线波形背后的真实交互过程，拆解UDS 31服务的每一个关键节点，解读那些让人头疼的否定响应码（NRC），并结合实际工程案例，告诉你——问题到底出在哪，又该怎么解决。

什么是UDS 31服务？不只是“远程函数调用”

虽然我们常把Routine Control类比为“远程调用一个函数”，但它远比这复杂。根据ISO 14229-1标准定义，Service ID = 0x31的服务允许诊断仪请求目标ECU执行三项操作：

每个“例程”由一个16位的Routine Identifier（RID）唯一标识，范围从0x0000到0xFFFF。这些ID不是随便定的，而是由OEM或供应商在诊断数据库（如ODX/CDD）中明确定义的。例如：

• F001：Flash Erase Preparation
• E002：EEPROM Write Cycle Test
• S005：Security Access Challenge Generation

通信格式非常简洁：

[0x31] [Sub-function] [RID High] [RID Low]

例如，要启动RID为0xF001的例程，发送：

31 01 F0 01

ECU若接受请求，返回正响应：

71 01 F0 01

注意：SID从0x31变成了0x71，这是UDS协议规定的正响应偏移（+0x40）。

但这只是开始。真正的挑战在于：这个“启动”之后发生了什么？

真实世界的通信时序：别被“瞬间响应”骗了

很多开发者误以为，只要收到71 01就代表例程已经执行完毕。错！正响应只表示“命令已被接收并调度”，不代表任务已完成。

让我们看一个典型的Start Routine流程，在CAN总线上是如何展开的：

T0: Tester → ECU 31 01 F0 01 // 请求启动 F001 T1: ECU → Tester 71 01 F0 01 // 收到，已安排 T2~Tn: ... // ECU后台执行耗时操作（可能几百ms） Tn+1: ECU 或 Tester → ... // 可选：周期性上报结果 or 主动查询 Tester → ECU 31 03 F0 01 // 查询结果 ECU → Tester 71 03 F0 01 00 // 结果：0x00 表示成功

关键点如下：

1. T0 → T1 是即时的（通常 < 50ms），属于协议栈层面的合法性校验和任务入队；
2. T1 → 实际完成 是异步的，取决于例程本身的复杂度；
3. 结果必须通过 0x03 显式查询，除非ECU支持周期性发送（Rare）；
4. 中间可能存在资源竞争或超时风险。

这就引出了一个核心设计理念：31服务本质上是一个“三段式”操作——启动 → 等待 → 查询。任何省略“等待”的脚本，都极有可能读到无效或旧的结果。

子功能之间的协作关系

不同子功能的行为差异极大，使用不当会导致逻辑混乱：

特别提醒：不要重复调用 Start Routine。如果一个例程已经在运行，再次发送31 01很可能触发NRC 0x24（Request Sequence Error）。正确的做法是先尝试Stop，或直接查询状态。

嵌入式端如何实现？AUTOSAR风格代码揭秘

下面是一段基于AUTOSAR架构的典型处理逻辑，展示ECU端如何安全地处理31服务请求。

#include "Dcm.h" typedef struct { uint16_t activeId; boolean isRunning; uint8_t result; // 0x00=success, 0xFF=fail uint32_t startTime; } RoutineCtrlBlock; static RoutineCtrlBlock g_routineCtrl = {0}; // 外部接口：由DCM模块调用 Std_ReturnType Dcm_RoutineControl( const uint8* reqData, uint8 reqLen, uint8* respData, uint8* respLen) { if (reqLen < 3) { Dcm_SendNrc(DCM_NRC_INCORRECT_MESSAGE_LENGTH_OR_INVALID_FORMAT); return E_NOT_OK; } uint8 subFunc = reqData[0]; uint16 rid = (reqData[1] << 8) | reqData[2]; switch (subFunc) { case 0x01: // Start Routine if (!CanRoutineStart(rid)) { // 条件检查失败：会话不对、权限不足、已有例程在跑 Dcm_SendNrc(GetLastRejectReason()); return E_NOT_OK; } StartRoutineInternal(rid); // 构造正响应 respData[0] = 0x71; respData[1] = 0x01; respData[2] = reqData[1]; respData[3] = reqData[2]; *respLen = 4; return E_OK; case 0x03: // Request Results if (g_routineCtrl.activeId == rid && !g_routineCtrl.isRunning) { respData[0] = 0x71; respData[1] = 0x03; respData[2] = reqData[1]; respData[3] = reqData[2]; respData[4] = g_routineCtrl.result; *respLen = 5; return E_OK; } else { Dcm_SendNrc(DCM_NRC_REQUEST_OUT_OF_RANGE); // 或 NRC_GENERALREJECT return E_NOT_OK; } default: Dcm_SendNrc(DCM_NRC_SUB_FUNCTION_NOT_SUPPORTED); return E_NOT_OK; } }

再配合一个后台任务来执行具体逻辑：

void RoutineExecutionTask(void) { if (!g_routineCtrl.isRunning) return; switch (g_routineCtrl.activeId) { case ROUTINE_ID_FLASH_PREPARE: if (PrepareFlashForProgramming() == E_OK) { g_routineCtrl.result = 0x00; } else { g_routineCtrl.result = 0xFF; } g_routineCtrl.isRunning = FALSE; break; case ROUTINE_ID_EEPROM_TEST: RunEEPROMStressTest(); g_routineCtrl.result = GetTestResult() ? 0x00 : 0xFF; g_routineCtrl.isRunning = FALSE; break; default: g_routineCtrl.result = 0xFF; g_routineCtrl.isRunning = FALSE; break; } }

这段代码体现了几个重要原则：

• 非阻塞设计：Dcm_RoutineControl快速返回，不执行耗时操作；
• 状态机管理：全局结构体维护当前例程状态；
• 前置条件校验：CanRoutineStart()检查会话、安全等级、互斥状态；
• 结果缓存机制：执行完成后保留结果一段时间（建议5~10秒）；
• 错误隔离：异常不影响主通信流程。

最常见的否定响应码（NRC）到底意味着什么？

当你看到一条7F 31 XX的CAN报文，就意味着出错了。以下是高频NRC及其真实含义与应对策略：

⚠️ 特别注意：当收到NRC 0x78（pending）时，不要立刻重试！应暂停发送后续命令，等待ECU发出正响应或超时（建议≥2s），否则容易导致诊断锁死或总线拥塞。

实战案例：为什么我的31 01 F001总是失败？

故障现象

某车型在自动化测试中频繁出现：

Request: 31 01 F0 01 Response: 7F 31 22

即NRC 0x22 —— CONDITIONS_NOT_CORRECT

排查过程

1. 抓包分析：确认报文格式完全正确，无CRC错误、无丢帧；
2. 检查会话状态：发现测试脚本未显式切换会话，当前处于Default Session (0x01)；
3. 查阅规格书：明确标注F001例程仅可在Extended Session (0x03)下调用；

4. 添加前置指令：
   10 03 // 切换至扩展会话 20 // 发送流控帧保持连接（可选） [wait 100ms] 31 01 F0 01 // 再次尝试

5. 结果：成功返回71 01 F0 01，后续查询结果也为0x00。

根本原因

这不是协议错误，也不是ECU bug，而是诊断流程设计缺陷：忽略了会话依赖性。

改进建议

在所有涉及31服务的脚本中，强制加入以下前置判断：

def enter_extended_session(): send_request("10 03") expect_response("50 03") # 10->50, +0x40 sleep(0.1) def safe_start_routine(rid): enter_extended_session() unlock_security_if_needed() # 如需0x27解锁 send_request(f"31 01 {rid}") if get_nrc() == 0x22: log_error("Session mismatch!") retry_with_session_switch()

高级设计建议：让你的31服务更健壮

1. 统一RID命名规范

建议采用语义化编码规则，提升可读性与团队协作效率：
-Fxxx：Flash相关（F001=擦除准备）
-Exxx：EEPROM操作
-Sxxx：安全机制
-Hxxx：高压系统检测

2. 定义执行时间SLA

对于超过500ms的例程，应在文档中标注预期耗时，避免Tester误判超时。例如：

RID: F001, Description: Flash Prep, Expected Duration: 800ms ± 100ms

3. 设置结果有效期

建议将结果保留5~10秒，之后自动清零。防止Tester误读上一次的残留数据。

4. 实现互斥锁机制

同一时间只允许一个例程运行，避免资源冲突。可用状态标志 + 超时保护实现：

if (g_routineCtrl.isRunning) { if (GetElapsedTime(g_routineCtrl.startTime) > MAX_ROUTINE_DURATION) { ForceStopCurrentRoutine(); // 防止卡死 } else { return E_REJECT; // 返回 NRC 0x24 } }

5. 增强日志与追溯能力

通过Dem模块记录每次调用：
- 调用时间
- 调用者（Tester地址）
- RID
- 执行结果
- 异常NRC

便于后期数据分析与问题复现。

它在整车诊断架构中的位置

在现代EEA（电子电气架构）中，31服务通常位于如下路径中：

[诊断仪] ←CAN→ [中央网关GW] ←CAN/FlexRay→ [目标ECU] ↑ [UDS协议栈] ↑ ↑ [DCM模块] [XCP/DoIP适配层] ↑ ↑ [应用层Routine Handler] ↑ [BswM / SwcM 调度器]

其中：
-DCM模块：负责接收原始帧、解析SID、路由到对应服务；
-Security Module：与0x27联动，确保敏感例程需先解锁；
-Dem模块：记录执行失败事件，生成临时DTC；
-Rte层：实现SWC间的数据交互，支持复杂例程编排。

OTA升级前的经典应用：刷写准备链路

在一个完整的FOTA流程中，31服务往往是第一道“安全门”：

1. 10 03—— 进入Extended Session
2. 27 05/27 06—— 安全访问解锁
3. 31 01 F0 01—— 启动Flash准备例程
4. （等待800ms）
5. 31 03 F0 01—— 查询结果 →71 03 F0 01 00✅
6. 开始34请求下载、36传输数据……

这一系列操作确保：只有在电源稳定、温度正常、无活动故障的前提下，才允许进入编程模式，极大提升了刷写的可靠性。

写在最后：掌握31服务，就是掌握诊断主动权

UDS 31服务看似简单，实则暗藏玄机。它不仅是协议的一部分，更是ECU内部逻辑与外部诊断需求之间的契约。

当你下次再遇到“启动不了例程”的问题时，不妨问自己几个问题：

• 我当前处于哪个会话？
• 是否完成了安全访问？
• RID写对了吗？
• 上一个例程结束了吗？
• 是否给了足够的执行时间？

很多时候，答案就藏在这些细节里。

随着SOA和DoIP的普及，未来的诊断将不再局限于CAN总线上的字节流，但“请求-执行-反馈”这一核心模式不会改变。今天你对31服务的理解深度，决定了明天你在智能汽车时代的话语权。

如果你正在开发诊断脚本、构建自动化测试平台，或是负责OTA升级方案设计，那么请务必把这篇文章收藏下来。因为它不仅帮你解决问题，更能让你看懂ECU在想什么。