一、服务功能:
该服务主要用于开启或停止DTC状态位的更新功能,而具体的实际功能和作用在主机厂规定的诊断服务规范当中都有提到。
DTC控制基本原理:
一般来说要满足两个条件:
①使能条件满足
②DTC控制有无关闭(85服务);
只有当使能条件满足且抑制DTC上报的开关为FALSE的情况下,上报的故障事件才能够进一步得到处理;
二、应用场景:
①在诊断刷写过程中,对某个ECU节点单独进行刷写,总线上其他的ECU节点还处于正常工作状态,一般会让各ECU节点停止记录DTC,刷写完成之后再重新开启DTC记录功能,此过程一般结合28服务一起使用。
②某些不需要进行记录DTC的场景。
在某些场景下的注意事项:
1、当通过85服务控制DTC不报出时,也就意味着当前DTC的状态将不会更新,DTC状态将保持现状。
2、一旦85服务控制DTC报出或者session超时回到默认会话或者软件复位等操作时,那么此时DTC状态将会继续保持更新;
3、当85服务控制DTC不报出时,此时执行14清除DTC服务时,DTC的状态将会正常被14服务处理,不会收到85服务的影响;
4、如果某event并没有Mapping DTC,那么85服务将不会对这个event做任何处理,因为85服务处理的基本对象是DTC;
5、如果某故障event发生会触发安全行为,此时如果执行85服务抑制DTC,同时触发14服务那么DTC状态将会被清除,相应的安全行为可能失效,因为对于安全关键系统,一般建议出现这种情况时,已触发的安全行为不应该被同步抑制;
三、服务请求:
请求格式:

★DTCSettingControlOptionRecord参数几乎不使用
ControlDTCSetting Request SID:固定为0x85
SubFunction:
| Subfunction | 说明 |
| 00 | ISO保留 |
| 01 | ON:表明DTC状态位正常更新 |
| 02 |
OFF:表明DTC状态位将被抑制 |
| 03-3F | ISO保留 |
| 40-5F | 主机厂使用 |
| 60-7E | 供应商使用 |
| 7F | ISO保留 |
四、服务响应:
正响应格式:

ControlDTCSetting Response SID:固定为0xC5
DTCSettingType:与请求保持一致
五、支持的NRC:
| NRC | Description | MNemonic |
| 12 | 子功能不支持 | SFNS |
| 13 | 发送报文长度或者格式不对 | IMLOIF |
| 22 | 当前请求条件不足 | CNC |
| 31 | 请求超出范围 如果检测到通信类型或节点识别号参数中有错误,则服务端应使用此响应码。 | ROOR |
本文介绍了汽车诊断中的DTC控制服务,包括服务功能、控制基本原理、应用场景,如诊断刷写中DTC的暂停与恢复,以及服务请求和响应格式。强调了85和14服务的区别,以及在不同场景下的注意事项。
1060

被折叠的 条评论
为什么被折叠?



