UDS_RoutineControl(0x31)服务

一、服务功能：

UDS 服务 Service 0x31 RoutineControl 是用于对主机厂定义的一些特定程序的控制操作（启动程序、停止程序、请求运行结果）的服务。它可以让诊断仪对服务器（如ECU）中的某些例程进行控制，例如擦除内存、检查编程依赖性、执行OBD测试等。

与2F服务相比，2F的基本功能都可以通过31服务来实现，不过用2F来实现的功能来用31服务，未免有点大材小用，因此31服务则是用于更复杂的输入输出控制场景，而2F服务则可用于较为简单常见的输入输出控制场景。

二、应用场景：

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

①：比如用于某sensor特定工况下的操作集合，如进行摄像头或者雷达内参标定流程；

②：在整车制造过程中较为常见的便是某Sensor的外参标定工位，在该工位中需要用到31服务开启标定例程，标定流程结束后也能够31服务获取标定例程的最终结果；

③：如雷达使用过程中的非正常工况下的发波波形配置调整可以通过31服务来实现；

④：在进行UDS刷写过程中可以通过31服务来触发内存的擦除操作等；

注意事项：

31服务针对同一控制场景一般可分为开始，停止，获取结果三个过程，这三个过程并不是同时存在，是否需要同时存在完全可以客户自定义；

31服务针对每一个控制场景均可以一个Routine ID来进行唯一的区别，因此不同的控制场景应采用唯一的Routine ID来进行区别；

通过AUTOSAR工具链配置的31 Routine回调函数命名时，函数名除了说明其基本功能以外，也需要将对应的Routine ID体现在函数名称中，这样便于搜索排查问题，是一种不错的代码实践；

对于31服务涉及的回调函数，一般不建议走RTE，主要是从代码可维护角度而言，更加简洁明了，实现效率高，走RTE接口还需增加额外的工作量，没有必要且容易出错。

三、服务请求：

请求格式：

Request SID：Rouutine Control的服务ID 固定为0x31；

SubFunction：

01：开启Routine;

02:停止Routine；

03：获取Routine;

其他预留

routineIdentifier（2byte）：即RID;

routineControlOptionRecord：根据客户需求可以自定义；

四、服务响应：

正响应格式：

Response ID：该参数固定为0x71；

Subfunction：该参数为上述诊断请求格式中Routine Type保持一致；

routineIdentifier：该参数与诊断服务请求中的routineIdentifier中保持一致；

routineInfo：一般可以理解为客户自定义，作为可选项；

routineStatusRecord：同上；

五、支持的NRC：

13：发送报文长度或者格式不对。

22：例如当尝试请求复位时且当前车速条件不满足，此时Client发送诊断指请求时，会回复22。

24：当某个routine还没有Start时便请求结果或者中止Routine时，会回复24。

31：当routineIdentifier或者可选的routineControlOptionRecord中均超出规定的范围时。

33：当该routineIdenfier设置了安全访问等级时，如果未解锁便执行该31服务。

72：当31服务用于擦除NVM时，在此过程中如果出现失败。