【UDS】ISO14229之0x31服务

---

->返回总目录<-

前言

简称： “RoutineControl”，例程控制
功能： 该服务执行指定的步骤操作并获取相关结果，相比0x2F服务，具有较大的灵活性，可用于较为复杂类型的控制。一般应用包括清除内存（多数用在更新ECU软件），重置或学习自适应数据，运行自检，方向盘角度零点标定等。

---

一、理论描述

程序控制类型的定义如下表：

01： 若响应消息是肯定或否定，表示请求已经执行或即将执行，则需在完成01请求消息和完成首个响应消息之间的某段时间内启动例程。
02： 若响应消息是肯定或否定，表示停止例程的请求已经执行或即将执行，则需在完成02请求消息和完成首个响应消息之后停止例程。
03： 使用该子功能请求例程的结果（如退出状态），该结果是ECU执行例程所产生的结果。（不太常用~~）

二、使用步骤

1.请求

这里博主就只说Sub-Function 为 01的情况，目前项目中也只用到该服务，02也简单就不说了。

例如： 诊断服务更新或刷写ECU程序之前，需要请求该服务项，检查是否满足刷写程序的条件。
某整车厂针对0x31服务的需求如下，（注：M表示强制要求，U表示可选）
Sub-Function： 01 (M)，02 (U)，03 (U)
RoutineIdentifier： 0x0203，软件刷写条件预检查
满足刷写的条件： 车速 < 5km/h，车辆处于非充电状态(新能源车型)，车辆处于驻车状态。

请求报文： 31 01 02 03

在请求该服务前，我们先制造一个不满足刷写条件的条件，如车速。该报文是我们ECU接收到的报文。

车速 6km/h > 条件5km/h，即不满足刷写条件，请求报文如下图：

红框：我们请求的报文
Service ID：31
Sub-Function：01
RoutineIdentifier：02 03
RoutineControlOptionRecord：无，可选项。

2.响应

1）正响应

Routine StatusRecord： 即请求之后的状态，如：00表示刷写条件满足，01表示刷写条件不满足。

参见CANoe图中的蓝框

2）否定响应
支持的否定响应如下，一般工作上根据整车厂给的诊断输入文档来选择要支持的NRC码。

博主平日项目中支持NRC如下：

NRC12： Sub-Function不支持（请求数据 31 FF 02 03。而你请求的子功能FF根本找不到啊，规范里也没有该子服务，ECU收到你这条报文，无法识别subfunc，因此回复该NRC）

NRC13： 请求报文数据长度有误（正确请求数据31 01 02 03 有4个字节。而你请求的是31 01 02只有3个字节，ECU收到你这条报文，无法理解，因此回复该NRC）

NRC22： 请求条件不满足
（一般整车厂会告诉你NRC22的满足条件，例如：车速>3km/h，电源过欠压时候，请求服务，ECU便回复该NRC）

NRC31： 请求超出范围（不按套路出牌，发送 31 01 66 66，RoutineIdentifier有66 66?）

NRC33： 安全访问拒绝（在请求31服务之前，必须先解锁，否则ECU回复NRC33）

总结

0x31服务在实际运用中要比0x2F复杂些，但那又怎样，通过本章讲解是否对该服务熟悉那么一勾勾呢？
下一章 DTC控制 0x85服务见！

->返回总目录<-