大家好，我是嵌入式老林，从事嵌入式软件开发多年，今天分享的内容是UDS中DTC控制服务0X85特殊用法的介绍，希望能对你有所帮助
一、0X85服务简介
0X85服务是用来控制DTC的，即DTC控制服务，主要是客户端用来停止或恢复服务端中DTC状态的更新。
当服务端收到85服务后：
1）控制信息是on：那么如果先前是off，就立即恢复到正常的状态，如果先前是on，保持状态不变。
2）控制信息是off：则服务端应该立即停止DTC的状态更新。即从此刻起，DTC的状态信息保持不变。无论是发生了新的故障，还是当前的故障有了新的状态，服务端的DTC数量、状态信息都不会更新。
举个例子，执行了$85 02，即使有节点丢失的故障，通过19服务的DTC状态码去读，也读不到节点丢失相关的故障，这就是85服务的作用。当然85服务不是把故障检测功能给关闭了，故障还是产生了的，只是DTC的状态位被禁止更新了，所以通过DTC状态位读不到故障码
注意：
a）DTC控制服务是要求在非默认会话下支持的服务，如果是默认会话下此服务无法执行请求的，回复否定应答，当前会话不支持，即NRC 0X7F。
b）如果没有发送诊断仪在线，会话超时从当前会话退出了，回到了默认会话下，则即使之前关闭了DTC的状态位更新，此时也会恢复DTC状态位更新
c）0x85服务并不影响通过ClearDTCInformation（14）服务请求清除故障信息
d）只能打开/关闭诊断故障代码状态位的更新，不能关闭故障监控，也不能禁止故障诊断软件策略
之前的文章也有介绍过0X85服务，此处不再过多介绍了，可看一下之前分享的文章：UDS统一诊断服务【七】DTC控制0X85服务
二、0X85服务的特殊用法
之前接触到的项目，0X85服务一般的用法就是，$85 01，$85 02 就这样去控制DTC，后面不会再接DTCSettingControlOptionRecord这个参数。实际ISO-14229中在描述0X85服务的格式时有介绍，但没给出对应的例子
这里也有介绍，大概意思就是：当控制DTC状态位的更新时，该参数记录是用户可选的，用于向服务器传输数据(例如，数据可以包含要打开或关闭的DTC列表)。
但在实际项目中还得按客户需求为准，我在实际接手的项目中就有规范要求在执行85服务的时候，得接DTCSettingControlOptionRecord，具体要求如下图所示：
当然了如果不是Autosar项目的话，可能得改UDS的协议栈，把这个参数加上，具体看你项目的协议栈是否比较全面。这里的项目是上了Autosar的，DTCSettingControlOptionRecord参数可通过配置去配的。配置很简单，就在DCM中把是否支持控制DTC设置的选项勾选上即可
改完后的实际效果：
三、问题
这个问题在之前的项目中都没接触过，所以本文记录一下，后面再接触到85服务的这种用法也就不陌生了。最后留几个问题，看看你们是否能答上来。
客户需求：85服务在默认会话下不支持，只在扩展会话下支持。子功能01和02都支持，且DTCSettingControlOptionRecord为 FF FF FF
下面的都是物理寻址
1）在默认会话下，执行85 01，服务端回复什么NRC？
2）在默认会话下，执行85 01 FF FF FF，服务端回复什么NRC？
3）先切换到扩展会话，然后执行85 01，服务端回复什么？
4）先切换到扩展会话，然后执行85 01 FF FF FF，服务端回复什么？
5）在默认会话下，执行85 81 FF FF FF，服务端回复什么？
6）先切换到扩展会话，然后执行85 81 FF FF FF，服务端回复什么？
上面的问题主要涉及到NRC的优先级，难度不大，细节还是蛮多的。还可以配合功能寻址和抑制正响应一起，这又有点不太一样了。有兴趣的可以回答一下上面的问题，可将答案私信发我，看看你回答是否正确
最后，如果觉得有帮助，希望你能一键三连(分享，点赞，在看)，你们的认可是我持续输出的动力，感激不尽。
谢谢分享