【车载开发系列】UDS诊断---控制DTC设置（$0x85）

【车载开发系列】UDS诊断—控制DTC设置（$0x85）

)

一.概念定义

1. 0x85(ControlDTCSetting)控制DTC设置
2. DTC控制服务的主要作用是控制DTC的状态更新。
3. 本服务允许上位机请求一个或一组服务器启用/停禁用DTC检测；
4. 软件实现中；当应用模块检测到故障后，如果读DTC控制状态为OFF，将不会进行DTC状态掩码操作。

常见汽车故障

• 常见的车载故障如下(包含不限于)

1. ECU内部故障（如ECU供电电压过高，ECU供电电压过低
   网络通信异常（如总线bus off，节点丢失）
2. 输入输出电路异常(传感器短路/开路，执行器异常，温度传感器数值过高)

二.子功能

DTC控制服务的子功能叫DTCSettingType，只有两个选项，其余的都是保留值或可自定义的值，下表列出了常用的两个子功能和描述。
DTCSettingType参数定义：

Hex (bit6-0)	描述	Description
0x01	ON	ECU应根据正常运行条件恢复诊断故障码设置
0x02	OFF	ECU应停止诊断故障码设置

三.报文格式

1）报文请求

1. DTC控制服务的请求报文格式非常简单，一般只会用到SID和子功能DTCSettingType两个字节
2. 在ISO当中后面还有DTCSettingControlOptionRecord参数，但这个参数并不十分常用。
   

2）肯定响应

1. 当服务端（ECU）接收到85服务后，如果控制信息是off，则服务端应该立即停止DTC的状态更新。即从此刻起，DTC的状态信息保持不变，无论是发生了新的故障，还是已有的故障有了新的状态，服务端的DTC数量、状态信息都不会更新。如果控制信息是on，那么如果先前是off，就立即恢复到正常的状态，如果先前是on，保持状态不变。
2. 无论是on还是off，服务端在正确处理请求之后都要给出肯定响应，如果无法正确处理，需要给出否定响应并明确响应失败的NRC。
   

3）否定响应

有关NRC和报文示例比较简单，建议直接参照ISO14229的标准。

四.应用举例

0x85通常和0x28服务结合使用，使用0x28服务停止某个或某些ECU的通信报文后，会导致其它接收这些ECU通信报文的ECU丢失通信故障码，因此通常需要先发送0x85服务来停止DTC记录，再发送0x28服务。

Client发送
0x85 0x02 (ControlDTCSetting request for Subfunction 0x02,DTC off)
ECU响应
0xC5 0x02 (Positive response starting with 0x85+ 0x40 = 0xC5)
Client发送：
0x85 0x03 (ControlDTCSetting request for Subfunction 0x03, invalid subfunction)
ECU响应：
0x7F 0x85 0x12 (Negative response starting with 0x7F, NRC is 0x12)

五.前提条件

1. ECU故障码的设置功能应在接收到控制模式为 2（关闭）的ControlDTCSetting请求报文或成功发送肯定响应后停止故障检测。
2. ECU故障码的设置功能应在接收到控制模式为 1（开启）的ControlDTCSetting请求报文或成功发送肯定响应后使能故障检测
3. 以下的情况下，ECU中故障码的设置功能应重新开启
   1. 执行ECU复位服务11
   2. 诊断会话模式从非默认诊断会话变为默认诊断会话的时候
4. ReadDTCInformation 服务（19h 02h），
   ReadDtcInformation 服务（19h 0Ah）
   ClearDiagnosticInformation 服务(14h)应不受服务0x85的影响。
5. 注意本服务是要求在非默认会话下支持的服务，所以如果是默认会话下是无法执行请求的，只能回复否定响应NRC7F。