UDS服务基础篇之31

UDS服务基础篇之31服务

前言

正如前文《UDS基础之2F服务》所说的2F服务与今天本文要将的31服务存在着有些相似之处，因此需要针对31服务本身进行较为细致的剖析，在此小T抛出如下几个基本问题供大家思考：

• 你知道31服务是干什么的吗？
• 31服务是怎样的请求与诊断格式？
• 31服务在使用的过程中需要注意哪些问题？

这篇，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：

---

正文

服务功能

功能描述

根据ISO14119-1标准中所述，诊断服务31服务主要用于实现针对某类测试场景，非正常工况下的程序活动以及其他擦除内存等连续性操作步骤的集合。

在某些情况下2F服务的基本功能也是能够通过31服务来实现，可以理解2F实现的功能31服务均可以实现，不过如果能够用2F实现的功能来用31服务，未免有些大材小用，因此31服务则是用于更为复杂的输入输出控制场景，而2F服务则可用于较为简单常见的输入输出控制场景。

下列文中使用到的Client可直接理解为上位机Tester，Server可直接理解为接受Tester诊断请求的ECU。

应用场景

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

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

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

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

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

31服务控制基本原理：

如下图1所示，针对31服务的通信控制过程会经过如下几个AUTOSAR BSW模块进行处理，然后完成最终的Routine控制，具体步骤如下：

• Client 发送诊断指令给到Server，Server接收到指令后通过确认Routine Type来决定调用不同的回调函数；
• 在每个回调函数中便可以实现客户自定义的控制场景，具体场景就是要根据客户需求来自定义来实现的。

图1 31服务控制流程图

服务请求

服务请求是Client发送给到Server的诊断服务指令。

请求格式

按照ISO14229-1标准所述，如下图2所示为31服务诊断请求格式，即上述31服务控制原理中诊断服务请求格式：

图2 31诊断服务请求格式

上述参数routineControlOptionRecord是可选项，在项目中可自定义，如传递相关的一些控制参数等。除此之外，就是SID，SubFunction，routineIdentifier这三个参数则必选，下图3中各参数解释如下：

图3 31诊断服务请求格式说明

请求实例

开启Routine(01)

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

图4 31服务开启Routine请求实例

停止Routine(02)

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

图5 31服务停止Routine请求实例

获取Routine结果(03)

以获取Routine结果为例，31服务诊断获取Routine结果请求实例如下图5所示：

图6 31服务获取Routine结果请求实例

服务响应

服务响应是针对Client对Server诊断请求的响应。

正响应格式

如下图7所示，为31诊断服务的正响应格式：

图7 31诊断服务正响应格式

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

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

正响应实例

开启Routine(01)

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

图8 31 01正响应示例

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

停止Routine(02)

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

图9 31 02正响应示例

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

获取Routine结果(03)

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

图10 31 03正响应示例

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

负响应NRC支持

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

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

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

图11 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优先级展示如下图12所示：

图12 31服务NRC优先级

更多AUTOSAR精彩基础与实战内容，敬请关注公号：ADAS与ECU之吾见。
结合小T的基础内容，可以深度学习下小T的实战系列，如此便可以轻松掌握AUTOSAR：
AUTOSAR实战指南