漫谈UDS协议之Service 86

今天是2022年8月28日，周日，魔都天气多云转晴。温度已经从40°逐渐降低，慢慢有了秋天的感觉。一场秋雨一场寒，十场秋雨入冬天，反正不热就好！
老规矩，分享一段喜欢的文字，避免成为高知识低文化的人：
“
当你决定要准备好了再开始做一件事，之后，你会发现好像永远也不能万事俱备，永远有可以为自己开脱的理由，现实也永远不会完全按照你预设的理想状态运行，做与不做，什么时候去做，是我们能决定的，而做好做坏则需要听天由命。从动了念头的那一刻就开始行动起来，并且做好了接受事与愿违的准备，何尝不是一种勇气。
”
Done is better than perfect!
Return to today's topic.
UDS(ISO 14229)作为用于车载诊断应用层诊断协议，规范中定义了26个诊断服务：
  

根据以前文章所写内容，有想法把所有诊断服务都补全。本文主要分享下UDS Service 86.
Service 86（ResponseOnEvent）功能是请求Server端（ECU）启动或停止在指定事件上传输响应。

该服务整体逻辑如下：
首先诊断仪向ECU发送诊断请求，其中设置一个事件逻辑，之后再向ECU（Server端）发送指令控制该事件的逻辑启动，指令中包含着EventWindowTime参数（即事件有效持续时间）。当事件逻辑启动时，如果发生了指定事件，ECU就会返回一个响应报文。
通过子服务配置的事件由如下两种变化引起参数记录：
-> onChangeOfDataIdentifier
-> onComparisonOfValues

因此Server端（ECU）需要提前配置好如下参数：
-> ResponseOnEventSchedulerRate：定期调度程序的调用率，用于比较 DataIdentifier (DID) 的值或检测 DTC 状态变化；
-> MaxNumChangeOfDataIdentfierEvents：配置了参数MaxNumChangeOfDataIdentfierEvents可以同时发生的最大事件数；
-> MaxNumComparisionOfValueEvents：配置了子服务onComparisonOfValues可以同时发生的最大事件数；
-> MaxSupportedDIDLength：每个DID允许的最大可测量数据字节数（用于比较或数据更改）。
它是车辆制造商指定的，通过先进先出 (FIFO) 处理多个 DataIdentifier 更改事件，或者如果事件逻辑暂时停止，同时处理事件报告。
多个DataIdentifier 更改事件通过先进先出 (FIFO) 处理，或者如果事件逻辑暂时停止，同时处理事件报告，这种报告的策略由OEM定义。
注：强烈建议使用大小为最大为4字节的MaxSupportedDIDLength值（例如，避免定义读取常量“校准”标签的事件逻辑）。

该服务提供了在Server端发生指定事件的情况下自动执行诊断服务的可行性。Client端指定事件（包括可选事件参数）以及事件发生时要执行的服务（包括服务参数）。如下简要描述Client和Server端之间行为流程：

需要注意的是，上图假定事件窗口定时器配置为在Server端（ECU）断电之前超时，因此最终的ResponseOnEvent肯定响应报文显示在事件定时窗口的末尾。Server端应在接收时评估ResponseOnEvent请求报文的子功能和数据内容。这里包括如下子功能和参数：
-> eventType；
-> eventWindowTime；
-> eventTypeRecord。
如果ResponseOnEvent请求报文中数据无效，则发送否定响应以及否定响应码NRC 31。



ServiceToRespondRecord不是此评估的一部分。当指定事件发生时，将评估ServiceToRespondToRecord参数，这里会触发ServiceToRespondToRecord中包含的服务执行。当事件发生时，应执行ServiceToRespondToRecord（诊断服务请求报文）。在条件不正确的情况下。应该发送带有适当否定响应码的否定响应报文。应按其发生顺序发出多个事件的信号。
如下是实施细节措施描述：
-> ResponseOnEvent服务可以在任何会话中设置和激活，其中包括DefaultSession。TesterPresent服务不一定需要保持ResponseOnEvent服务处于激活状态。
-> 如果在诊断服务正在进行发生指定的事件，这意味着要么正在接收请求报文， 要么正在执行请求，或者正在进行响应报文（其中包括否定响应正在处理以及对应的NRC 78）被传送（如果SuppressPosRspMsgIndicationBit = False），那么包含在ServiceToResponseToRecord中请求执行将被推迟直到完成正在进行的诊断服务动作。
-> 如果多个事件发生而另一个事件正在进行，多个事件的处理应为VehecleManufactureSpecific。

-> 当事件逻辑得到满足并且事件在事件时间窗口内生成时，Server端应执行ServiceToResponseToRecord中包含的服务。
-> 一旦ResponseOnEvent服务由ResponseOnEvent请求中“启动”启动，Server端就会响应已建立事件逻辑的Client端，并启动ROE事件到事件窗口时间到期。
-> 移动到任何非默认会话的DiagnosticSessionControl请求应停止ResponseOnEvent服务，而不管是否激活与当前会话或同一非默认会话不同的非默认会话模式中。在返回到默认会话模式之前在默认会话模式中处于活动状态的所有ResponseOnEvent服务应重新激活。
-> 读ResponseOnEvent服务可以与不同的需求（不同的EventTypes，ServiceToRepondToRecords等）同时运行以启动和停止诊断服务。启动和停止子功能应始终控制所有初始化的ResponseOnEvent服务。
该服务请求格式：

响应格式：

其中子服务功能定义：
   
其中响应报文参数定义：
如上分享，希望有所帮助！日进一步，功不唐捐！
愿你我相信时间的力量，
做一个长期主义者！