1 0x11功能描述

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

2 0x11应用场景

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

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

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

通常来说，ECU在收到一条诊断指令之后，要先进行相应的处理，执行某些诊断操作，完毕后在发送肯定响应。
但是ECU复位是个特例，因为它的诊断操作是复位，这时候这个ECU就会重新开始运行，此时ECU也不会及的前面发送过的诊断指令，所以复位后ECU没有办法再去发送诊断响应，所以要先发送肯定响应，再执行复位。
注意：从发送完肯定响应到执行复位的这段时间内，ECU是否还可以响应其他诊断操作，标准中没有规定。但是在此期间ECU不接受任何发送请求，也不发送任何响应消息。

3 0x11服务请求

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

3.1 请求格式

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

各参数解释如下：

3.2 重启类型

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

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

上述复位类型的具体含义解释：

4 0x11请求和响应

4.1 正响应格式

以实现HardReset为例

11诊断服务的正响应格式实例：

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

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

4.2 负响应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"