1 0x31功能描述

client端使用RoutineControl服务执行定义的步骤序列并获取任何相关结果。该服务具有很大的灵活性，典型的用法包括擦除内存，复位或学习自适应数据，运行自检，覆盖正常服务器控制策略以及控制服务器值随时间变化等功能。预定义的序列（例如：关闭的敞篷车顶）等等。通常，当用于控制输出时，此服务用于更复杂的类型控制，而inputOutputControlByIdentifier用于相对简单（例如：静态）的输出控制。

2 0x31应用场景

一般而言，对于31诊断服务，主要应用场景为以下场合：

• 比如用于某sensor特定工况下的操作集合，如进行摄像头或者雷达内参标定流程；
• 在整车制造过程中较为常见的便是某Sensor的外参标定工位，在该工位中需要用到31服务开启标定例程，标定流程结束后也能够31服务获取标定例程的最终结果；
• 如雷达使用过程中的非正常工况下的发波波形配置调整可以通过31服务来实现；
• 在进行UDS刷写过程中可以通过31服务来触发内存的擦除操作等；

上述这些应用场景较为常见，这里就不一一列举。

除了在哪些应用场景下使用，在此还需要针对31服务提出如下几点注意事项：

• 31服务针对同一控制场景一般可分为开始，停止，获取结果三个过程，这三个过程并不是同时存在，是否需要同时存在完全可以客户自定义；
• 31服务针对每一个控制场景均可以一个Routine ID来进行唯一的区别，因此不同的控制场景应采用唯一的Routine ID来进行区别；
• 通过AUTOSAR工具链配置的31 Routine回调函数命名时，函数名除了说明其基本功能以外，也需要将对应的Routine ID体现在函数名称中，这样便于搜索排查问题，是一种不错的代码实践；
• 对于31服务涉及的回调函数，一般不建议走RTE，主要是从代码可维护角度而言，更加简洁明了，实现效率高，走RTE接口还需增加额外的工作量，没有必要且容易出错。

3 0x31服务请求和响应

3.1 请求格式

按照ISO14229-1标准所述，如下图所示为31服务诊断请求格式：
上述参数routineControlOptionRecord是可选项，在项目中可自定义，如传递相关的一些控制参数等。除此之外，就是SID，SubFunction，routineIdentifier这三个参数则必选，各参数解释如下：

• request SID： 31为service ID，表示RoutineControl的服务ID
• SubFunction = [Routine Type]
  01：开启Routine
  02：停止Routine
  03：获取Routine,其他值预留
• routineIdentifier(2 Byte)：该两个字节范围为0x0000-0xFFFF
• routineControlOptionRecord(n Byte) ：根据客户需求自定义

3.2 正响应格式

31诊断服务的正响应格式：
从上图中可以看出，31诊断服务的正响应由以下二个部分组成：

• Response ID：该参数固定为SID+0x40 = 0x71；
• SubFunction：该参数为上述诊断请求格式中Routine Type保持一致;
• routineIdentifier: 该参数与诊断服务请求中的routineIdentifier中保持一致；
• routineInfo：一般可以理解为客户自定义，作为可选项；
• routineStatusRecord: 同上；

3.3 请求与正响应示例

开启Routine(01)

以开启Routine为例，假设Routine ID为0201，该Routine则用于进行短时间的输入输出控制， 31服务诊断请求开启Routine实例如下图所示：
正响应：

其中，0x01就是跟诊断请求中31 01中的RoutineType保持一致即可，同时routineStatusRecord则是根据客户需求进行自定义回复。

停止Routine(02)
以停止Routine为例，31服务诊断停止Routine请求实例如下图所示：

如下图所示，为上述31 02 02 01请求示例所对应的正响应：

其中，0x02就是跟诊断请求中31 02中的RoutineType保持一致即可，同时routineStatusRecord则是根据客户需求进行自定义回复。

获取Routine结果(03)

以获取Routine结果为例，31服务诊断获取Routine结果请求实例如下图所示：
如下图所示，为上述31 03 02 01请求示例所对应的正响应：

其中，0x03就是跟诊断请求中31 03中的RoutineType保持一致即可，同时routineStatusRecord则是根据客户需求进行自定义回复。

3.4 负响应NRC支持

绝大多数情况下，Server针对Client的请求都会给到正响应，比如发生重启前需确保整车处于安全状态，如引擎熄火，车速不能超过3km/h等，或者为了防止不按照诊断请求格式进行请求，那么Server需要通过某种方式来告诉Client执行不成功的原因在哪里以便于调查问题直至得到正响应。

因此ISO14229-1针对所有的诊断服务提供了一种统一的诊断负响应的诊断格式：7F +SID + NRC。

其中NRC全称为Negetive Responce Code，每个NRC具有唯一的含义来代表当前诊断请求错误的原因所在。当然每个诊断服务支持的NRC不尽相同，具体支持的NRC需要参考ISO14229-1标准文档，对于31服务而言支持的NRC如下图：

• 当诊断请求的subfuntion不在Server支持的范围内时，则Server会回复”7F 31 12“；
• 当发送报文长度或者格式不对时，则Server会回复"7F 31 13"；
• 例如当尝试请求复位时且当前车速条件不满足，此时Client发送诊断指请求时，Server将会回复“7F 31 22”来告诉请求者当前进入编程会话的条件不满足，请再次检查进入编程会话的条件；
• 当某个routine还没有Start时便请求结果或者中止Routine时，那么Server会回复"7F 31 24";
• 当routineIdentifier或者可选的routineControlOptionRecord中均超出规定的范围时，则Server会回复“7F 31 31”；
• 当该routineIdenfier设置了安全访问等级时，如果未解锁便执行该31服务，则Server会回复"7F 31 33";当31服务用于擦除NVM时，在此过程中如果出现失败那么Server便会回复"7F 31 72"

上述NRC也存在对应的优先级，因此小T将对应的31服务NRC优先级展示如下图所示：

按从上到下的顺序，每一步的检查内容列举如下：

Minimum length check：这里最小长度检查包括了SID,SubFunction,RID，最少是4个字节；

第一个NRC31：这里检查在当前诊断会话模式，是否支持请求的RID，这里的RID即routineIdentifier；

NRC34：如果服务支持安全传输，这里检查安全传输的验证结果是否通过；

NRC33：如果DID支持安全校验，这里检查安全校验服务是否已经验证通过；

NRC12：这里校验请求里的子功能是否支持；

Total length check：总长度检查，即包括SID,SubFunction,RID,routineControlOptionRecord的总长度，routineControlOptionRecord的长度依据RID而定；

第二个NRC31：当检查逻辑执行到这里的时候，主要检查的是routineControlOptionRecord参数是否在RID定义的有效范围内；

NRC22：NRC22有两个，第一个检查的是请求的服务和子功能的执行条件是否满足，第二个检查的是请求数据的执行条件是否满足；

NRC24：31服务的子功能是有顺序的，即停止例程的请求必须是在开始例程的后面请求才可以，请求例程的执行结果也必须在开始例程之后才被允许，否则回复此NRC。

如果上面的检查内容都检查通过了，则回复肯定响应。