手把手教你配置诊断开发中的UDS 31服务

深入实战：如何高效配置与应用 UDS 31 服务，打通诊断开发的“主动脉”

在汽车电子开发的世界里，你有没有遇到过这样的场景？

产线上的 ECU 刷写失败率居高不下，测试人员反复插拔、手动触发流程；OTA 升级前需要关闭一堆功能，却缺乏统一入口；售后维修时想执行一次传感器标定，只能靠烧录特殊版本软件……这些问题背后，往往不是硬件出了问题，而是诊断能力没跟上。

而解决这些痛点的关键钥匙之一，就是——UDS 31 服务（Routine Control Service）。

它不像读 DTC 那样被动观察，也不像写数据那样简单赋值。它是“主动出击”的那一类诊断手段：让 ECU 执行一段预设逻辑，比如擦除 Flash、启动自检、进入编程模式。换句话说，31 服务是连接诊断指令和底层行为的桥梁。

今天我们就抛开教科书式的讲解，从一个真实开发者视角出发，手把手带你把UDS 31 服务用起来，无论你是跑在 AUTOSAR 上的大厂工程师，还是在裸机上“搬砖”的嵌入式老兵，都能找到属于你的实现路径。

---

为什么是 31 服务？因为它干的是“脏活累活”

我们先来回答一个问题：为什么非要用 31 服务？不能直接调函数吗？

当然可以——如果你只关心单台样车、临时调试的话。

但一旦进入量产阶段，事情就变了：

• 测试脚本要复用
• 工具链要标准化
• 安全权限要有管控
• 远程诊断要支持

这时候你会发现，没有标准接口的私有调用方式就像一盘散沙。不同项目各搞一套，新人接手头大如斗，测试团队天天催文档。

而UDS 31 服务正好解决了这个问题。它提供了一个标准化、可配置、带状态反馈、支持安全校验的功能执行通道。

举个例子你就明白了：

假设你要做 OTA 升级，第一步是让 ECU 进入 Bootloader 模式。
如果不用 31 服务，你可能得发一堆 2E 写数据 + 11 复位命令，顺序错一步就失败。
而用了 31 服务后，只需一条请求：

31 01 00 02→ 启动 ID 为0x0002的“进入 Bootloader”例程。

ECU 内部自动完成一系列检查、关闭任务、跳转准备等操作，整个过程对外透明且可控。

这才是现代诊断该有的样子：简洁、可靠、可追溯。

---

核心机制拆解：31 服务到底怎么工作的？

别被 ISO 14229 的术语吓到，其实31 服务的本质非常朴素：通过 ID 找到一段代码，并控制它的生命周期。

请求格式长什么样？

[0x31][Sub-function][RID_H][RID_L][Optional Input Data]

• 0x31：服务 ID
• Sub-function：
• 0x01：Start Routine
• 0x02：Stop Routine
• 0x03：Request Routine Results
• RID：Routine Identifier，两个字节，比如0x0001
• Input Data：可选输入参数，长度由具体例程定义

响应则是正响应71 + sub-function或负响应7F 31 [NRC]。

它是怎么跑起来的？

想象一下你在 ECU 里建了个“小程序商店”，每个程序有个唯一编号（RID），你可以远程安装（启动）、卸载（停止）、查看运行状态（查询结果）。这其实就是 31 服务的工作模型。

当诊断仪发送一个31 01 00 01请求时，ECU 做了这几件事：

1. 解析出 RID =0x0001，子功能 = Start
2. 查表看有没有注册这个 ID 的处理函数
3. 有则调用对应的Start回调函数
4. 函数返回成功，则回复71 01 00 01
5. 后续可通过31 03 00 01查询执行进度或结果

整个过程依赖于 ECU 内部的一个“调度器”机制，它可以是 AUTOSAR DCM 模块，也可以是你自己写的查表逻辑。

---

AUTOSAR 平台实战：一步步配出可用的 31 服务

如果你用的是 Vector、ETAS 等主流工具链，那恭喜你，大部分工作已经被框架接管了，你只需要做好“填空题”。

第一步：定义你的 Routine ID

打开 ARXML 文件，在<Dcm>模块下添加一个 Routine 配置：

<Routine> <SHORT-NAME>Routine_EraseFlash</SHORT-NAME> <ROUTINE-IDENTIFIER>0x0001</ROUTINE-IDENTIFIER> <START-ENABLED>true</START-ENABLED> <STOP-ENABLED>true</STOP-ENABLED> <RESULTS-ENABLED>true</RESULTS-ENABLED> </Routine>

就这么几行，告诉系统：“我要注册一个 ID 为0x0001的例程，支持启停和查结果。”

⚠️ 小贴士：不要随便用保留 ID！建议制定内部编码规范，例如：
-0x00xx：工厂专用
-0x01xx：售后维修
-0xFFxx：OEM 特殊用途

第二步：绑定回调函数

接下来要告诉系统：“这个 ID 对应哪段代码？”通常是在DcmDspRoutine.c中填写函数指针表：

const Dcm_DspRoutineType Dcm_DspRoutine[] = { { .DcmDspRoutineId = 0x0001, .DcmDspStartRoutineFnc = App_StartEraseFlash, .DcmDspStopRoutineFnc = App_StopEraseFlash, .DcmDspRequestResultsRoutineFnc = App_GetEraseStatus }, // 其他例程... };

这三个函数分别对应三种操作：

• Start：初始化任务、检查前置条件
• Stop：中断执行、释放资源
• Result：返回当前状态（成功/失败/进度）

第三步：写业务逻辑 —— 真正干活的地方

来看一个典型的 Flash 擦除例程实现：

Std_ReturnType App_StartEraseFlash(uint8 *dataIn, uint16 lengthIn, uint8 *dataOut, uint16 *lengthOut) { // 必须先进入解锁状态（Security Level 3） if (SecurityLevel != LEVEL_3) { return E_NOT_OK; } // 可以接收参数，比如指定扇区 if (lengthIn >= 2) { uint16 sector = (dataIn[0] << 8) | dataIn[1]; if (!IsValidSector(sector)) { return E_NOT_OK; } gTargetSector = sector; } EraseTaskInit(); // 启动异步擦除任务 gRoutineState = ROUTINE_RUNNING; return E_OK; } uint8 App_GetEraseStatus(uint8 *dataOut, uint16 *lengthOut) { dataOut[0] = gEraseProgress; // 返回进度百分比 *lengthOut = 1; return gRoutineResult; // 返回 PASS / FAIL / RUNNING }

🔍 关键点解析：
-安全等级校验是必须的，防止非法刷写；
- 使用全局变量跟踪状态，供轮询使用；
- 若操作耗时较长（>50ms），务必采用非阻塞设计，避免 CAN 报文超时。

第四步：编译下载 + CANoe 验证

把代码编译烧录进 MCU 后，就可以用 CANoe 验证了。

编写 CAPL 脚本发送请求：

message 0x711 req; on key 'F1' { // 发送：31 01 00 01 （启动 Flash 擦除） req.dlc = 4; req.byte(0) = 0x31; req.byte(1) = 0x01; req.byte(2) = 0x00; req.byte(3) = 0x01; output(req); } on message 0x711 { if (this.byte(0) == 0x71 && this.byte(1) == 0x01) { write("✅ 例程已成功启动！"); } else if (this.byte(0) == 0x7F && this.byte(1) == 0x31) { byte nrc = this.byte(2); write("❌ 负响应，NRC=%X", nrc); } }

按 F1 键就能看到响应结果。如果一切正常，你会收到71 01 00 01，表示例程已启动。

接着可以用另一个按键循环查询状态：

on key 'F2' { req.byte(0) = 0x31; req.byte(1) = 0x03; // Request Results req.byte(2) = 0x00; req.byte(3) = 0x01; output(req); }

监听返回的进度值，甚至可以在 Panel 上画个进度条，是不是瞬间专业感拉满？

---

非 AUTOSAR 环境也能玩：轻量级实现方案

不是所有项目都上了 AUTOSAR。很多工业控制、低成本 ECU 或早期原型还在用裸机或 FreeRTOS。

没关系，我们可以自己搭一套简易版 31 服务框架。

设计思路：查表 + 函数指针

核心就是一个结构体数组，类似中断向量表：

typedef struct { uint16 id; Std_ReturnType (*start)(uint8*, uint16, uint8*, uint16*); Std_ReturnType (*stop)(void); uint8 (*result)(uint8*, uint16*); } RoutineEntry; // 注册所有例程 const RoutineEntry routineTable[] = { {0x0001, FlashErase_Start, FlashErase_Stop, FlashErase_Result}, {0x0002, SensorCalib_Start, NULL, SensorCalib_Result}, {0xFFFF, NULL, NULL, NULL} // 结束标志 };

主循环中处理请求

void ProcessUDS31(const uint8 *req, uint8 len, uint8 *res, uint8 *resLen) { uint8 subFunc = req[1]; uint16 rid = (req[2] << 8) | req[3]; const RoutineEntry *rt = FindRoutine(rid); // 遍历查找 if (!rt) { SendNRC(0x31, 0x31); // Request Out Of Range return; } switch(subFunc) { case 0x01: // Start if (rt->start) { if (rt->start(&req[4], len-4, res+4, resLen) == E_OK) { res[0] = 0x71; res[1] = 0x01; res[2] = req[2]; res[3] = req[3]; *resLen += 4; } else { SendNRC(0x31, 0x24); // Request Sequence Error } } else { SendNRC(0x31, 0x22); // Conditions Not Correct } break; case 0x03: // Query Result if (rt->result) { uint8 r = rt->result(res+4, resLen); res[0] = 0x71; res[1] = 0x03; res[2] = req[2]; res[3] = req[3]; res[4] = r; *resLen = 5; } break; default: SendNRC(0x31, 0x12); // Sub-function not supported break; } }

这套方案占用内存极少，适合资源紧张的 MCU。只要保证函数是非阻塞的，完全可以稳定运行。

---

实战应用场景：这些坑我都替你踩过了

讲完技术细节，我们来看看31 服务真正能解决哪些实际问题。

场景一：产线下线检测（EOL Test）

以前的做法：工人手动按下按钮，观察灯亮不亮，记录数据。

现在怎么做？

• 定义多个 Routine ID：
• 0x0010：车窗升降测试
• 0x0011：门锁动作循环
• 0x0012：灯光通断扫描
• 测试台自动调用31 01 xx xx启动各项测试
• 通过31 03获取结果，失败则上报 MES 系统

效率提升不说，数据还能自动归档，便于追溯。

场景二：OTA 升级前准备

OTA 不是发个包就完事了。升级前要做一堆准备工作：

• 停止非关键任务
• 保存当前状态
• 关闭通信周期报文
• 开启 Bootloader 监听

把这些打包成一个例程0x0002，主机端只需一条命令即可完成全部准备动作，大大降低升级失败风险。

场景三：高压系统安全检测

新能源车上电前必须做绝缘电阻检测。这类涉及安全的操作尤其适合用 31 服务封装：

Std_ReturnType HV_Interlock_Test(...) { if (Voltage < MIN_VOLTAGE || Temp > MAX_TEMP) { return E_NOT_OK; // 条件不满足 } RunInsulationTest(); return g_test_result; }

结合 Security Access 控制访问权限，确保只有授权设备才能触发。

---

踩过的坑与避坑指南

别以为配置完就万事大吉，以下是我在项目中总结的真实教训：

❌ 坑点1：忘记加安全等级校验

曾经有个同事开放了 Flash 擦除例程但没做安全校验，结果测试时误触发，整片程序被清空，整车“变砖”。

✅秘籍：所有敏感操作必须绑定 Security Level，推荐使用 27 服务解锁后再允许调用。

❌ 坑点2：长时间操作导致 CAN 超时

某次标定例程执行时间长达 3 秒，期间没有响应任何请求，诊断仪判定为通信中断，直接报错退出。

✅秘籍：耗时操作必须异步化！启动后立即返回71 01，后续通过31 03轮询状态。

❌ 坑点3：未处理重复启动请求

用户连续点击“开始测试”两次，导致任务重入，RAM 数据混乱。

✅秘籍：在Start函数开头加状态锁：

if (gRoutineState == ROUTINE_RUNNING) { return E_NOT_OK; }

✅ 最佳实践清单

项目	推荐做法
命名规范	制定 RID 编码规则，团队统一
异常处理	每个例程加超时保护、看门狗喂狗
资源隔离	诊断任务独立优先级，不影响主控逻辑
文档同步	新增 RID 必须更新 CDD/ODX 文件
版本兼容	旧 RID 不删除，标记为 deprecated

---

写在最后：未来的诊断不止于“读写”

随着汽车 EE 架构向中央计算演进，传统的“读 DTC、写参数”已经不够用了。

未来的智能 ECU 需要更强的主动诊断能力：能自我检测、能远程干预、能动态调整行为。

而UDS 31 服务，正是通往这条路的第一步。

它不仅是一个协议服务，更是一种思维方式的转变——从“我能读什么”变成“我能做什么”。

当你能把 ECU 的每一个关键动作都封装成一个可调用的“服务”时，你会发现：

• 自动化测试不再是难题
• OTA 升级变得更安全
• 售后诊断效率翻倍
• 整车运维走向智能化

所以，别再把它当成冷冰冰的标准条款了。试着去用它、优化它、扩展它。也许下一次你写的那个0x0001，就会成为产线上每天被调用上千次的“黄金接口”。

如果你正在做诊断开发，不妨现在就打开工程，试着注册第一个 Routine ID。
动手那一刻，才算真正入门。

💬 互动时间：你在项目中用过哪些有趣的 31 服务场景？欢迎在评论区分享你的实战经验！