UDS服务基础篇之85

UDS服务基础篇之85服务

前言

正如前文《UDS基础之28服务》所说的28服务与85服务往往是搭配使用，因此讲完28服务之后，本文将对85服务做一个专题介绍。那么针对85服务，小T咨询下大家如下几个问题？

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

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

---

正文

功能描述

根据ISO14119-1标准中所述，诊断服务85服务主要用于开启或者停止DTC状态位的更新功能，这个功能在主机厂规定的诊断服务规范当中都会有实际的功能及作用。

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

应用场景

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

• 用于在诊断刷写的过程中关闭DTC记录，因为在刷写的过程中往往是针对某个ECU节点单独进行刷写，其他的对手件ECU节点始终处于正常工作状态，那么此时应当发送功能寻址给到各ECU节点使得其停止记录DTC，刷写完成之后在重新开启对手件DTC记录功能即可。
• 用于某些特殊不需要记录DTC的场景；

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

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

• 当通过85服务控制DTC不报出时，也就意味着当前DTC的状态将不会更新，DTC状态将保持现状；
• 一旦85服务控制DTC报出或者session超时回到默认会话或者软件复位等操作时，那么此时DTC状态将会继续保持更新；
• 当85服务控制DTC不报出时，此时执行14清除DTC服务时，DTC的状态将会正常被14服务处理，不会收到85服务的影响；
• 如果某event并没有Mapping DTC，那么85服务将不会对这个event做任何处理，因为85服务处理的基本对象是DTC；
• 如果某故障event发生会触发安全行为，此时如果执行85服务抑制DTC，同时触发14服务那么DTC状态将会被清除，相应的安全行为可能失效，因为对于安全关键系统，一般建议出现这种情况时，已触发的安全行为不应该被同步抑制；

DTC控制基本原理：

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

• Client 发送诊断指令给到Server，Server接收到指令后内部会置位某全局变量；

• 软件内部故障触发时，会首先检查如下两个条件是否满足才会进行event的处理；

  • enable condition是否满足；
  • DTC控制有无关闭(85服务)；

  只有当enable condition满足并且抑制DTC上报的开关为FALSE的情况下，上报的故障事件才能够得到进一步处理；

图1 85服务DTC控制原理图

服务请求

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

请求格式

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

图2 85诊断服务请求格式

一般来说参数DTCSettingControlOptionRecord几乎不使用，仅用到前面两个参数，一个是SID，另外一个是DTCSettingType。

下图3中各参数解释如下：

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

如下图4所示，为上述subfunction(DTCSettingType)中的各项取值的具体含义：

图4 85诊断服务subfunction取值说明

请求实例

关闭DTC监控(OFF)

以抑制DTC上报为例，85服务诊断请求实例如下图5所示：

图5 85服务抑制DTC上报请求实例

开启DTC监控(ON)

以开启DTC上报为例，85服务诊断请求实例如下图6所示：

图6 85服务使能DTC上报请求实例

服务响应

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

正响应格式

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

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

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

• Response ID：该参数固定为SID+0x40 = 0xC5；
• SubFunction：该参数为上述诊断请求格式中DTCSettingType;

正响应实例

关闭DTC监控(OFF)

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

图8 85 02正响应示例

其中，0x02就是跟诊断请求中的DTCSettingType保持一致即可。

开启DTC监控(ON)

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

图9 85 01正响应示例

负响应NRC支持

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

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

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

图10 85服务NRC支持

• 当诊断请求的subfuntion不在Server支持的范围内时，则Server会回复”7F 85 12“；
• 当发送报文长度或者格式不对时，则Server会回复"7F 85 13"；
• 例如当尝试请求复位时且当前车速条件不满足，此时Client发送诊断指请求时，Server将会回复“7F 85 22”来告诉请求者当前进入编程会话的条件不满足，请再次检查进入编程会话的条件。
• 当communicationType与nodeIdentificationNumber均超出规定的范围时，则Server会回复 “7F 85 31”；

复位时且当前车速条件不满足，此时Client发送诊断指请求时，Server将会回复“7F 85 22”来告诉请求者当前进入编程会话的条件不满足，请再次检查进入编程会话的条件。

• 当communicationType与nodeIdentificationNumber均超出规定的范围时，则Server会回复 “7F 85 31

更多精彩内容，敬请关注公众号“ADAS与ECU之吾见”！