UDS Protocol 0x86 Service: How Response On Event Works in Automotive Diagnostics

Hello, fellow automotive tech enthusiasts! In this blog post, we’re diving into UDS Protocol Response On Event (0x86) Service – one of the most dynamic services in the UD

S (Unified Diagnostic Services) protocol Service 0x86: Response On Event. This service plays a crucial role in real-time diagnostics by allowing ECUs to send responses based on specific event triggers. It’s a powerful tool used in advanced vehicle communication systems for monitoring and responding to predefined conditions. Whether you’re a beginner or brushing up your diagnostics knowledge, this post will guide you step by step. We’ll explore what this service does, how it works, and where it’s applied. By the end, you’ll understand how Response On Event enhances the efficiency of UDS-based diagnostics. Let’s begin our deep dive into Service 0x86!

Introduction to Response On Event (0x86) Service in UDS Protocol

Welcome to another deep dive into the world of automotive diagnostics! In this post, we’ll explore the Response On Event (Service 0x86) in the UDS (Unified Diagnostic Services) protocol. This service allows an ECU to automatically send a response when a predefined event occurs, making it essential for real-time system monitoring. It’s commonly used in scenarios where immediate notification of critical changes is required. We’ll walk through how this service works, its key sub-functions, and where it fits in modern vehicle systems. Whether you’re a student, developer, or automotive engineer, this guide is for you. Let’s get started with understanding how Response On Event adds intelligence to diagnostics communication!

What is Response On Event (0x86) Service in UDS Protocol?

The Response On Event (0x86) service in the UDS protocol allows an ECU to automatically send a response when a specific event or condition occurs, without needing a request from the diagnostic tool. This service is reactive, meaning the ECU responds to predefined events, such as sensor malfunctions or threshold breaches. It helps in real-time monitoring and quick diagnostics, enabling faster identification of issues like engine faults. Commonly used in advanced vehicle diagnostics, this service ensures that critical system changes are promptly reported for safety and performance.

Why do we need Response On Event (0x86) Service in UDS Protocol?

Here are the reasons why we need Response On Event (0x86) Service in UDS Protocol:

1. Immediate Response to Critical Events

The Response On Event (0x86) service allows the ECU to send an automatic response when a predefined event occurs, such as a fault detection or a threshold breach. This immediate response is essential for real-time monitoring, allowing diagnostic tools to detect and address issues without delay. For example, if a critical sensor malfunctions, the ECU will automatically notify the diagnostic tool, ensuring that no time is wasted in identifying potential safety risks or performance issues. This helps maintain the overall reliability and safety of the vehicle.

2. Reduces the Need for Constant Polling

Without the 0x86 service, diagnostic tools would need to constantly poll the ECU to check for any changes in system status. This approach would be inefficient and could lead to slower response times, especially in complex systems. By allowing the ECU to send responses only when necessary, the service optimizes communication, reducing unnecessary traffic and ensuring that diagnostics are more focused and timely. This leads to more efficient use of resources and faster detection of system anomalies.

3. Enhances Fault Detection and Troubleshooting

The Response On Event service is vital for quick fault detection and troubleshooting. When a vehicle component reaches a certain threshold or malfunctions, the ECU can immediately respond to the diagnostic tool, providing real-time data about the issue. This reduces diagnostic time and helps technicians pinpoint problems faster, ensuring that necessary repairs can be made promptly. It enhances the effectiveness of maintenance processes by improving the speed and accuracy of fault identification.

4. Supports Proactive Vehicle Maintenance

By enabling the ECU to automatically notify diagnostic tools of specific events, the 0x86 service supports proactive vehicle maintenance. For instance, it can notify technicians about minor issues before they develop into major problems. This early warning system is crucial for maintaining vehicle performance and preventing breakdowns. It allows service providers to address issues before they escalate, reducing repair costs and improving the vehicle’s overall lifespan.

5. Improves System Monitoring and Safety

The Response On Event (0x86) service enhances overall system monitoring and vehicle safety. It ensures that important system changes, such as error conditions or safety breaches, are detected and addressed immediately. This is particularly important in critical systems like engine management, braking, and safety sensors, where delays in response could lead to significant safety risks. With real-time event-based notifications, the service helps keep vehicles safer and ensures they meet required standards for reliability and performance.

6. Facilitates Real-Time Diagnostics

The 0x86 service enables real-time diagnostics by allowing the ECU to respond to events as soon as they occur. This means that diagnostic tools can receive immediate feedback about the vehicle’s status, allowing technicians to address issues swiftly. For example, if a fault occurs during vehicle operation, the diagnostic tool can immediately capture and log the error, preventing any delays in resolving the issue. This feature is particularly valuable in automotive systems where timing is critical.

7. Streamlines Communication Between ECUs

In modern vehicles, multiple ECUs communicate with each other to ensure optimal performance. The Response On Event (0x86) service helps streamline this communication by triggering automatic responses across ECUs when specific events take place. This ensures that all parts of the vehicle’s system are informed of critical changes in a timely manner. By reducing manual intervention and continuous polling, it fosters a smoother and more efficient communication process between ECUs, contributing to better vehicle performance.

8. Enhances Compliance with Diagnostic Standards

The 0x86 service ensures that vehicles comply with industry-standard diagnostic protocols, such as the UDS protocol, which is widely adopted for automotive diagnostics. By using event-based responses, it aligns with best practices in modern vehicle diagnostics, ensuring vehicles meet required regulatory and performance standards. This is especially important for manufacturers who need to ensure that their vehicles can be easily diagnosed and maintained, providing better serviceability and compliance with automotive regulations.

Syntax of 0x86 SID Request Message Frame Format

Data byte	Parameter Name	Byte Value
#1	Response On Event Request SID	0x86
#2	sub-function = [ event Type ]	0x00 – 0xFF
#3	Event Window Time	0x00 – 0xFF
#4 : #(m-1)+4	Event Type Record[] = [                           event Type Parameter 1                                                  :                           event Type Parameter m ]	0x00 – 0xFF : 0x00 – 0xFF
#n-(r-1)-1 #n-(r-1) : #n	Service To Respond To Record[] = [                                                                serviced                                   service Parameter 1                                                         :                                   service Parameter r ]	0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF
C1: This parameter is present if the event Type necessitates additional parameters to be specified for the event response. C2: It is mandatory to be present if the sub-function parameter is not equal to report Activated Events, stop Response On Event, start Response On Event, or Clear Response On Event. C3: This parameter is present if the service request of the service to respond to requires additional service parameters.

Request Message Data-Parameter

eventWindowTime

The parameter eventWindowTime can be used to define a time window for which the event logic in the server shall be active. In case the parameter value of eventWindowTime is 0x02 the response time is infinite. In case of an infinite event window and storageState equal to doNotStoreEvent it is strongly recommended to close the event window by a certain signal (e.g. power off).

A finite event window in combination with storageState equal to storeEvent shall not be used.

NOTE: This parameter is not applicable to be evaluated by the server in case the eventType is equal to a ROE control sub-function.

eventTypeRecord

This parameter record includes additional parameters for the specified eventType.

serviceToRespondToRecord

This parameter record includes the service ID and service parameters for the service to be executed on the server whenever the specified event, as defined in the eventTypeRecord, occurs.

Syntax of 0x86 SID Positive Response Message

Data byte	Parameter Name	Byte Value
#1	Response On Event +Ve Response SID	0xC6
#2	Event Type	0x00 – 0x7F
#3	Number Of Identified Events	0x00 – 0xFF
#4	Event Window Time	0x00 – 0xFF
#5 : #(m-1)+5	Event Type Record[] = [                             event Type Parameter 1                                                     :                             event Type Parameter 1	0x00 – 0xFF : 0x00 – 0xFF
#n-(r-1)-1 #n-(r-1) : #n	Service To Respond To Record[] = [                                                                serviced                                   service Parameter 1                                                       :                                   service Parameter r ]	0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF
C1: Present if the event Type requires additional parameters to be specified for the event to respond to. C2: Present if the service request of the service to respond to requires additional service parameters.

Response Message Data-Parameter

eventType

This parameter echoes bits 6 through 0 of the sub-function parameter from the request message.

eventTypeOfActiveEvent

This parameter echoes the sub-function parameter from the request message used to set up the active event. The applicable values are those specified for the eventType sub-function parameter.

numberOfActivatedEvents

This parameter indicates the number of active events when the client requests a report of active events. This number reflects the events reported in the response message.

numberOfIdentifiedEvents

This parameter indicates the number of identified events during an active event window and is only applicable to the response message sent at the end of the event window (in the case of a finite event window). The initial response to the request message will contain a zero (0) in this parameter.

Syntax of 0x86 SID Negative Response Message

Data byte	Parameter Name	Byte Value
#1	Response On Event –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x86
#3	Negative Response Code [ byte#1 ]	NRC

Sub-Function ID of (0x86) SID in UDS Protocol

Bits 5 – 0 Value	Name	Description	Type of ROE sub-function
0x00	Stop Response On Event	This value is utilized to halt the server from sending responses during an event. The event logic remains intact but can be resumed by utilizing the `startResponseOnEvent`      sub-function parameter. The length of the `eventTypeRecord` is 0 bytes.	control
0x01	On DTC Status Change	This value indicates a new Diagnostic Trouble Code (DTC) matching the specified mask. The length of eventTypeRecord is 1 byte. Implementation hint: The server counts DTCs meeting the client-defined mask periodically. If the count changes, it triggers the event for service execution. The event Type requires specifying the DTC Status Mask in the request message.	setup
0x02	On Timer Interrupt	This value signifies a timer interrupt event, but the timer and its values are not included in the Response On Event service. Additional details need to be specified in the request message (eventTypeRecord). The length of event Type Record is 1 byte.	setup
0x03	On Change Of Data Identifier	This value denotes an event as a new internal data record identified by a data Identifier. The data values are specific to the vehicle manufacturer. Additional details need to be specified in the request message (eventTypeRecord). The length of eventTypeRecord is 2 bytes.	setup
0x04	Report Activated Events	This value indicates that all currently active events activated in the server with the Response On Event service will be reported in the positive response. The length of eventTypeRecord is 0 bytes.	control
0x05	Start Response On Event	This value is used to instruct the server to activate the event logic, including the event window timer, and start sending responses when the event occurs. The length of eventTypeRecord is 0 bytes.	control
0x06	Clear Response On Event	This value is utilized to clear the event logic that has been configured in the server, consequently halting the server from sending responses when the event occurs. The length of eventTypeRecord is 0 bytes.	control
0x07	On Comparison Of Values	This sub-function defines a data value event by specifying a change in a data value within a record identified by a data Identifier. Users can trigger events by comparing a measurement value to a predefined value using a specified operator. The event occurs when the comparison is positive. The event Type Record length is 10 bytes.	setup
0x08 – 0x1F	ISOSAE Reserved	This range of values is set aside by this document for future definition.	–
0x20 – 0x2F	Vehicle Manufacturer Specific	This range of values is set aside for vehicle manufacturer-specific use.	setup
0x30 – 0x3E	System Supplier Specific	This range of values is designated for system supplier-specific use.	setup
0x3F	ISOSAE Reserved	This value is set aside by this document for future definition.	–

Supported Negative Response Codes (NRCs) of 0x86 SID in UDS Protocol

NRC	Parameter Name	Description
0x12	Sub-Function Not Supported	This NRC (Negative Response Code) shall be sent if the sub-function parameter is not supported.
0x13	Incorrect Message Length Or Invalid Format	This NRC (Negative Response Code) shall be sent if the length of the request message is incorrect.
0x22	Conditions Not Correct	This code is used when the server is engaged in critical normal mode activity and is therefore unable to execute the requested functionality.
0x31	Request Out Of Range	The server shall utilize this response code in the following scenarios: • If it detects an error in the eventTypeRecord parameter. • If the specified event Window Time is invalid. • If the requested DID is not supported. • If a combination of a finite event window and storage State equal to store Event is requested.

Example of Response On Event (0x86) Service in UDS Protocol

Here are the Examples of Response On Event (0x86) Service in UDS Protocol:

Example #1 – ResponseOnEvent (finite event window)

Example of Request Message Flow:

Message Direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	ResponseOnEvent Request SID	0x86
#2	eventTypeRecord [ eventType ] = onDTCStatusChange, storageState = doNotStoreEvent suppressPosRspMsgIndicationBit = FALSE	0x01
#3	eventWindowTime = 80 seconds	0x08
#4	eventTypeRecord [ eventTypeParameter ] = testFailed status	0x01
#5 #6 #7	serviceToRespondToRecord [ serviceId ] = ReadDTCInformation serviceToRespondToRecord [ sub-function ] = reportNumberOfDTCByStatusMask serviceToRespondToRecord [ DTCStatusMask ] = testFailed status	0x19 0x01 0x01

Example of Positive Response Message Flow:

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	ResponseOnEvent Response +Ve Response SID	0xC6
#2	eventType = onDTCStatusChange	0x01
#3	numberOfIdentifiedEvents = 0	0x00
#4	eventWindowTime = 80 seconds	0x08
#5	eventTypeRecord [ eventTypeParameter ] = testFailed status	0x01
#6 #7 #8	serviceToRespondToRecord [ serviceId ] = ReadDTCInformation serviceToRespondToRecord [ sub-function ] = reportNumberOfDTCByStatusMask serviceToRespondToRecord [ DTCStatusMask ] = testFailed status	0x19 0x01 0x01

Example of Negative Response Message Flow:

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Periodic Data Identifier#2 [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x86
#3	Negative Response Code [ data#1 ]	NRC

// Below example shows how to use the UDS commands over the CAN data field as per the DoCAN
// Example for Positive Response for SID-0x86
Request: Client --> Server
02 86 04
Positive Response: Server --> Client
02 C6 04
// Example for Negative Response for SID-0x86
Request: Client --> Server
01 86 04
Negative Response: Server --> Client
03 7F 86 13

UDS Service 0x86: Response On Event – CAN Communication Explained

When using UDS over CAN (DoCAN), commands are exchanged between the client (tester) and server (ECU) using the CAN data field. Let’s break down how a request and response look for Service 0x86 (Response On Event), with both positive and negative responses explained.

✅ Example: Positive Response for Service ID 0x86

Request from Client to Server:

CAN Data: 02 86 04

• 02: Number of data bytes after this one (here, 2 bytes → 86 and 04)
• 86: Service ID (SID) for Response On Event
• 04: Sub-function (example: StartResponseOnDTCStatusChange)

This request tells the ECU to start monitoring and send a response when a certain event (like a DTC status change) occurs.

Positive Response from Server to Client:

CAN Data: 02 C6 04

• 02: Number of data bytes after this one (here, 2 bytes → C6 and 04)
• C6: Positive Response Code (SID + 0x40 → 0x86 + 0x40 = 0xC6)
• 04: Echoes the sub-function (confirmation of 04)

Meaning: The ECU accepted the request and has successfully activated the Response On Event function.

❌ Example: Negative Response for Service ID 0x86

Request from Client to Server:

CAN Data: 01 86 04

• 01: Indicates 1 byte of actual data (only SID)
• 86: Service ID (SID) for Response On Event
• 04: Sub-function requested

Let’s assume something goes wrong (e.g., sub-function not supported in current session).

Negative Response from Server to Client:

CAN Data: 03 7F 86 13

• 03: Total bytes after this (7F, 86, 13)
• 7F: Negative Response SID (standard indicator for NACK)
• 86: Echoes the original Service ID that caused the error
• 13: NRC (Negative Response Code) – 0x13 means “InvalidFormat”

Meaning: The ECU could not process the request due to an invalid format or unsupported sub-function in the current state.

Summary Table:

Message Type	CAN Data	Explanation
Request	02 86 04	Ask ECU to start Response On Event (sub-func 04)
Positive Response	02 C6 04	ECU accepted the request
Request (bad)	01 86 04	Improper/invalid request
Negative Response	03 7F 86 13	ECU sends error: Invalid format (NRC 0x13)

Advantages of Response On Event (0x86) Service in UDS Protocol

These are the Advantages of Response On Event (0x86) Service in UDS Protocol:

1. Real-Time Fault Notification: This service allows the ECU to instantly send diagnostic messages when a specific event, like a DTC status change, occurs. It eliminates the need for repeated polling, enabling faster detection of issues. Real-time updates help technicians take immediate action, reducing vehicle downtime. This improves overall diagnostic responsiveness and supports dynamic system monitoring.
2. Reduces Network Load: Instead of constantly sending requests to check for faults, diagnostic tools receive updates only when necessary. This event-driven approach minimizes unnecessary CAN traffic. It ensures the network remains available for other critical communications and avoids overloading the bus. As a result, system performance and communication efficiency are significantly improved.
3. Faster Troubleshooting: The ECU proactively sends relevant data as soon as a fault is detected. This quick transmission saves time by removing the need to manually query for issues. Technicians can identify, analyze, and resolve problems more efficiently. It streamlines the diagnostic process and leads to faster service turnaround, benefiting both users and workshops.
4. Proactive Maintenance Support: Response On Event enables early detection of potential issues before they become critical. It allows technicians to schedule maintenance at the right time, avoiding emergency repairs. This predictive maintenance approach extends the vehicle’s life and improves reliability. It also reduces costs associated with unexpected breakdowns and major component failures.
5. Supports Advanced Diagnostics: Modern vehicles require intelligent diagnostic systems, and this service supports that need by enabling smart event-based data handling. It reduces irrelevant data flow and highlights only the important status changes. This helps in developing efficient, automated tools that respond only to actual issues. It’s a foundation for building next-gen diagnostics.
6. Enhanced Safety and Reliability: Safety-critical systems like brakes or airbags can be monitored continuously, and immediate alerts can be issued when a fault occurs. Quick response times are essential to ensure corrective action is taken promptly. This enhances both vehicle safety and reliability, as technicians are kept informed in real time. It plays a crucial role in safety compliance.
7. Standards Compliance: The 0x86 service adheres to ISO 14229 (UDS) standards, ensuring compatibility with various OEMs and third-party diagnostic tools. Following industry standards guarantees uniform behavior across vehicle systems. It simplifies development, testing, and integration of diagnostics. Moreover, it supports future-proofing by aligning with global automotive protocols.
8. Better Resource Management: Since the ECU does not have to constantly process polling requests, it frees up processing power and memory. This makes the system more efficient and reduces the load on hardware resources. For embedded systems or low-power ECUs, this is especially important. It contributes to stable and optimized system operation.
9. Improves Testing Efficiency: During development and validation, engineers can track and log real-time event notifications without manually checking for changes. This makes testing faster and more accurate. It also ensures that transient or short-duration faults are captured and documented. The result is improved product validation and reduced time to market.
10. Ideal for Remote Diagnostics: In connected vehicles or telematics systems, Response On Event allows ECUs to report faults remotely only when needed. This reduces unnecessary data transmission, saving bandwidth and cost. It’s particularly useful in fleet management or over-the-air (OTA) services. It supports scalable, real-time remote diagnostics across vehicle platforms.

Disadvantages of Response On Event (0x86) Service in UDS Protocol

These are the Disadvantages of Response On Event (0x86) Service in UDS Protocol:

1. Complex Implementation: Implementing the 0x86 service in the ECU software requires additional logic to track event triggers and send responses accordingly. This increases development time and effort, especially for systems that already use standard polling diagnostics. More rigorous testing and validation are also needed to ensure correct behavior.
2. Increased Memory Usage: Since the ECU must maintain a list of subscribed events and their conditions, it consumes additional RAM and storage. This can be problematic for resource-constrained microcontrollers. Developers must optimize memory usage while still ensuring accurate event detection and response.
3. Risk of Message Flooding: If multiple events are triggered in quick succession or if thresholds are too sensitive, the ECU may flood the CAN bus with messages. This can cause bus congestion and lead to communication delays. Proper configuration is essential to avoid such overload scenarios.
4. Requires Precise Event Configuration: Defining the right conditions for event triggers can be tricky. Misconfigured events may either trigger too often or not at all, leading to inaccurate or missing diagnostic data. This can confuse technicians and complicate fault diagnosis instead of simplifying it.
5. Compatibility Limitations: Not all third-party diagnostic tools or older ECUs support the 0x86 service. This creates interoperability issues when working with mixed hardware or legacy systems. In such cases, fallback to polling-based diagnostics may still be necessary, reducing the benefit of event-based communication.
6. Debugging Can Be Difficult: Because responses are only sent when specific conditions occur, it can be hard to reproduce and debug event-triggered issues. If a condition is missed or misinterpreted, it might delay fault detection and repair. Technicians may also need advanced tools to monitor event activity in real time.
7. Security Concerns: As this service allows automatic responses from the ECU, it might expose the system to spoofing or DoS (Denial of Service) attacks if not properly secured. Malicious nodes on the CAN bus could exploit the event mechanism to flood or manipulate communication.
8. Extra Diagnostic Tool Support Needed: Tools must be designed to subscribe to and interpret 0x86 event responses correctly. Basic scan tools that don’t support this service won’t receive any updates, leading to incomplete diagnostics. This limits the use of the feature to advanced or OEM-specific tools.
9. Potential for Missed Events: If the ECU resets or the communication is interrupted during an event, the client may miss critical fault notifications. Without a backup mechanism, important diagnostic data could be lost. Robust error-handling and backup strategies are required to maintain reliability.
10. Increases System Complexity: Managing event subscriptions, multiple clients, trigger conditions, and timely responses adds complexity to the overall UDS stack. More code means more chances for bugs and longer testing cycles. It also increases the learning curve for engineers new to UDS protocol services.

Future Development and Enhancement of Response On Event (0x86) Service in UDS Protocol

Here are the Future Development and Enhancement of Response On Event (0x86) Service in UDS Protocol:

1. Integration with AI-based Diagnostics: Future diagnostic systems may integrate AI algorithms that use event-based data from the 0x86 service to predict component failures. This would allow smarter, context-aware maintenance strategies. Such enhancements could shift diagnostics from reactive to predictive, improving vehicle reliability and safety.
2. Enhanced Security Features: With rising cybersecurity concerns, future versions of the UDS protocol could include encrypted or authenticated Response On Event messages. This would prevent malicious exploitation or spoofing on the CAN bus. Secure communication would also enable safer remote diagnostics.
3. Cloud-Connected Event Logging: Events triggered by the 0x86 service can be logged to cloud platforms in real time for large-scale fleet monitoring. This can help manufacturers analyze fault trends across thousands of vehicles. Such cloud diagnostics would enable remote software updates and preventive maintenance.
4. Cross-ECU Coordination: Future implementations could enable ECUs to collaborate and share event triggers across systems. For example, an ABS fault could notify both the powertrain and telematics ECUs. Coordinated event handling would lead to more robust and holistic diagnostics.
5. Support for More Event Types: Currently limited to specific types like DTC status change, future enhancements could include temperature spikes, voltage drops, or sensor deviations as triggers. This broadens diagnostic coverage and enables more detailed health monitoring of ECUs and components.
6. Dynamic Subscription Management: Future diagnostic tools may gain the ability to update or change event subscriptions during runtime. This means subscriptions can be adjusted based on driving conditions or test modes, offering more flexibility. It would allow tools to adapt to different scenarios on the fly.
7. Improved Support in OBD Tools: As the 0x86 service gains popularity, more OBD-II and advanced diagnostic tools will support it by default. Enhanced tool support would make event-based diagnostics more accessible to technicians in garages and workshops. It ensures broader adoption across the automotive service industry.
8. Inclusion in Over-the-Air Diagnostics: As OTA updates become common, 0x86 service could be used to report faults immediately after an update. This helps in real-time validation of firmware integrity and performance. It ensures that any new issues are detected and fixed promptly.
9. Visual Dashboards for Event Monitoring: Future diagnostic environments may offer real-time dashboards that visualize event responses graphically. This would help engineers and technicians monitor event flow, DTC triggers, and ECU behavior at a glance. It simplifies data interpretation and accelerates debugging.
10. Alignment with EV and ADAS Systems: Electric Vehicles (EVs) and Advanced Driver-Assistance Systems (ADAS) require precise, real-time fault reporting. Enhanced 0x86 service can be tailored to meet the diagnostic needs of these complex systems. It ensures safe operation and simplifies compliance with regulatory requirements.