【车载开发系列】UDS诊断—基于事件响应($0x86)
一.概念定义
- 基于事件响应(ResponseOnEvent)服务(0x86)顾名思义就是当ECU发生了某个事件或满足了某个条件的时候发送响应,这和以往我们介绍的一条请求一条响应的诊断通信方式有所不同。
- 该服务是请求服务器启动或停止传输对特定事件的响应。
- 由客户端规定事件发生时将要执行的事件(包括可选的事件参数)和服务(包括服务参数)
- 首先诊断仪要先向ECU发送请求,设置一个事件逻辑,之后再向ECU发送指令控制该事件逻辑的启动,指令中附带eventWindowTime参数,即事件有效持续时间。当事件逻辑启动时,如果发生了指定的事件,ECU就会返回一条响应。
- 该服务的原理类似于设计模式当中的命令模式,因为有满足了条件之后就执行回调的思想在里面。
二.注意事项
- 0x86服务可以在任何诊断会话下被执行,包括默认会话,并且不需要诊断工具在线(0x3E)服务来维持状态
- 当指定时间发生时,如果当前有其它诊断指令正在被处理并即将返回一个诊断响应(包括返回0x78的情况),那么86服务的响应应该被推迟发送,在当前诊断响应发送完毕后再发送。所以在这种情况下可能会导致86响应中的数据不是实时的最准确的数据。
三.报文格式
1)请求报文
- eventTypeRecord
此参数记录包含指定的eventType的其他参数。 - serviceToRespondToRecord
该参数记录包含每次在eventTypeRecord中定义的指定事件发生时要在服务器中执行的服务的服务参数(服务ID和服务参数)。 - 当指定事件发生时,将评估serviceToRespondToRecord参数,该事件将触发serviceToRespondToRecord中包含的服务的执行。在事件发生时,应执行serviceToRespondToRecord(诊断服务请求消息)。
- Subfunction服务器应在接收时评估ResponseOnEvent请求消息的子功能和数据内容。 这包括以下子功能和参数:eventType,eventWindowTime和eventTypeRecord。具体的见下表。
Hex | Name | Description | eventTypeRecord的长度 |
---|---|---|---|
0x00 | tstopResponseOnEvent | 停止服务器发送事件响应 | 0字节 |
0x01 | onDTCStatusChange | 检测到与为此事件指定的DTCStatusMask匹配的新DTC | 1字节 |
0x02 | onTimerInterrupt | 计时器中断 | 1个字节 |
0x03 | onChangeOfDataIdentifier | DataIdentifier标识的新内部数据 | 2个字节 |
0x04 | reportActivatedEvents | 报告已在服务器中使用ResponseOnEvent服务激活的所有事件 | 0字节 |
0x05 | startResponseOnEvent | 指示服务器激活已设置的事件逻辑并开始发送事件响应 | 0字节 |
0x06 | startResponseOnEvent | 指示服务器激活已设置的事件逻辑并开始发送事件响应 | 0字节 |
0x07 | onComparisonOfValues | DataIdentifier标识的特定记录中定义的数据值更改 | 10字节 |
0x08-0x1F | ISOSAEReserved | ISO 保留,暂未定义 | - |
0x20-0x2F | VehicleManufacturerSpecific | 整车厂定义 | - |
0x30-0x3E | SystemSupplierSpecific | 供应商定义 |
2)肯定响应
- everyWindowsTime这个参数一般都是定义为0x02。在这里只是用来回显用,和请求报文时使用同样的值。
- 对于参数eventTypeRecord与serviceToRespondToRecord则是指在诊断请求要求的情况下才会被记录发出。如果出现多个符合定义的事件发生,则会逐一进行记录。
Hex | Name | Description |
---|---|---|
0x00-0x01 | ISOSAEReserved | ISO保留 |
0x02 | infiniteTimeToResponse | 响应时间无限 |
0x03-0x7F | vehicleManufacturerSpecific | 车厂自行定义 |
0x80-0xFF | ISOSAEReserved | ISO保留 |
3)否定响应
常见的86服务的否定响应码如下