UDS服务基础篇之11

前言

首次，请教大家关于诊断服务11的几个问题：

• 11服务有何作用，为什么要有11服务呢？
• 11服务在使用过程中有哪些注意事项呢？
• 11服务诊断请求与诊断响应如何交互？

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

---

正文

服务功能

功能描述

根据ISO14119-1标准中所述，诊断服务11主要用于Client向Server(ECU)请求重启行为。该重启行为将会导致Server复位回归到特定的初始状态，具体是什么初始状态取决于Client的请求行为。

应用场景

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

• ECU被刷写新的软件后，此时需通过11诊断服务重启该ECU使其回复到初始状态，保证一个十分干净的运行环境；
• 在产线下线标定的过程中，对于KL30供电的ECU存在一些仅在下电存储的数据，此时需要通过11诊断服务使ECU走下电流程进而完成相应数据的保存；
• 为满足特定功能的需要，输入相关标定参数给到ECU后，只有通过发送诊断服务11才能使得标定参数生效的场景；
• 对于KL30供电的ECU节点，可以使用诊断服务11使ECU快速进入休眠的场景；

上述这些应用场景较为常见，除此以外，当然还有很多面向ECU内部测试的应用场合，这里就不一一列举。

注意事项：

根据ISO14229-1标准所述，当Client向Server发送11诊断服务请求时，Server可在重置行为完成之后或者开始重启行为之前给到Client

诊断响应，但14229-1强烈推荐的一种做法是：”当Server接受到来自Client的11诊断服务请求时，Server应当先给出诊断响应然后开始重启行为“。

至于为什么如此，我想到一个场景：如果功能寻址请求11诊断服务时(未抑制正响应)，在复位未完成之前，一般都会先回复NRC78让Client进行等待，那么对于Client需要根据不同的ECU节点的回复做超时监控，这无疑增加了Client负担，对于Client而言，最为简单的方法就发送完请求，各ECU节点回复正响应，然后各自完成复位操作即可。

服务请求

服务请求是Client发送给到Server的诊断服务指令。其中Client可以理解为Tester，Server可以理解为ECU节点。

请求格式

按照ISO14229-1标准所述，如下图1所示：

图1 11诊断服务请求格式

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

图2 11请求格式说明

重启类型

由上图2所提到复位类型，复位类型作为subfunction参数来传递给到Server发生相应的重启行为，具体由以下几种类型：

• HardReset：硬复位；
• keyOffOnReset：点火开关复位；
• SoftReset: 软复位；
• enableRapidPowerShutDown：使能快速休眠流程；
• disableRapidPowerShutDown：抑制快速休眠流程；
• vehicleManufacturerSpecific：供整车制造商使用的自定义复位类型；
• systemSupplierSpecific：供系统供应商使用的自定义复位类型；

如下图3中所示为上述复位类型的具体含义解释：

图3 11诊断服务复位类型

请求实例

以实现HardReset为例，如下图4所示：

图4 11 01诊断请求示例

由上可知，在不考虑特殊场景的前提下，只需发送"11 01"诊断请求便可以让Server发生硬复位行为。

suppressPosRspMsgIndicationBit: 为subfunction的Bit 7位。

• 如果该Bit位为1，则表示抑制正响应，Server不需要给到Client正响应；
• 如果该Bit位为0，则表示不抑制正响应，Server应该给予Client正响应；

在第2个Byte中特该Bit位为1别提到抑制正响应为False，则表示不抑制正响应，Server正常回复就是。

服务响应

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

正响应格式

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

图5 11诊断服务正响应格式

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

• Response ID：该参数固定为SID+0x40 = 0x51；
• SubFunction：该参数具体为对应的复位类型，如01，02，03，04，05等；
• powerDownTime：该参数仅针对subfunction==0x4时才会回复该参数，其他情况下，Server仅会回复前两个字节(response SID + SubFunction)，其取值范围只能为0x00-0xFE，0xFF则为无效值；

正响应实例

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

图6 11 01正响应示例

其中resetType即为针对诊断请求实例的ResetType保持一致即可。

负响应NRC支持

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

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

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

• 例如当尝试请求复位时且当前车速条件不满足，此时Client发送诊断指令"11 01"请求Server发生复位行为，Server将会回复“7F 11 22”来告诉请求者当前进入编程会话的条件不满足，请再次检查进入编程会话的条件。
• 当发送报文长度或者格式不对时，则Server会回复"7F 11 13"；
• 当诊断请求的resetType不在Server支持的范围内时，则Server会回复”7F 11 12“；
• 当Server在发生复位前处于security lock状态，那么此时Server则会回复"7F 11 33"

---

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

公众号后台回复关键字“加群”，便可免费加入AUTOSAR技术交流群，共同探讨CP，AP，SOA，信息与功能安全等前言热点话题！