Report Supported DTCs (Service 0x19, Sub-function 0x0A) in UDS Protocol Explained

Hello, fellow automotive enthusiasts! In this blog post, I’ll introduce you to UDS Report Supported DTCs (0x0A) – an important concept in the UDS (Unified Diagnostic Serv

ices) protocol: the Report Supported DTCs using Service 0x19 and Sub-function 0x0A. This service plays a crucial role in diagnostics by helping tools identify which DTCs (Diagnostic Trouble Codes) are supported by a control unit. Understanding this concept is essential for effective troubleshooting and communication between diagnostic testers and ECUs. In this post, I’ll explain what Report Supported DTCs are, how they work, and why they are important in automotive diagnostics. By the end, you’ll have a clear understanding of how to use this service to enhance your UDS communication skills. Let’s dive in!

Introduction to Report Supported DTCs (Service 0x19, Sub-function 0x0A) in UDS Protocol

Welcome to this blog post on an important topic in automotive diagnostics! Today, we’ll explore the Report Supported DTCs feature using Service 0x19 and Sub-function 0x0A in the UDS protocol. This service allows diagnostic tools to request a complete list of trouble codes that a vehicle’s ECU can report. It plays a key role in identifying potential issues quickly and accurately. In this post, we’ll break down how this service works, what the communication flow looks like, and why it’s essential for effective diagnostics. Whether you’re a beginner or looking to deepen your understanding, this guide will help you master this UDS feature. Let’s dive right in!

What is Report Supported DTCs (Service 0x19, Sub-function 0x0A) in UDS Protocol?

In automotive diagnostics, Report Supported DTCs serves as a crucial sub-function under the Read DTC Information service, identified by Service ID (SID) 0x19 and Sub-function 0x0A. It falls under the UDS (Unified Diagnostic Services) standard defined in ISO 14229. This service enables a diagnostic tester (such as a diagnostic tool, service tester, or scan tool) to request a complete list of all Diagnostic Trouble Codes (DTCs) that an ECU (Electronic Control Unit) is programmed to monitor and report, regardless of their current status (active, stored, or historical).

In simple words, it doesn’t matter if a fault currently exists or not – this service lists every DTC that the ECU supports or is capable of detecting.

How It Works?

• Service Identifier (SID): 0x19 (Read DTC Information)
• Sub-function: 0x0A (Report Supported DTCs)

The diagnostic tester sends a diagnostic message to the ECU consisting of:

• SID (0x19)
• Sub-function (0x0A)

No additional parameters are required for this basic request.

Upon receiving this request, the ECU responds with:

• A positive response (0x59 instead of 0x19) along with
• A list of all DTC codes that it supports.

Each DTC is typically a 3-byte (24-bit) value and can include:

• The DTC identifier
• Optional status availability masks

The format of the response follows the UDS specification, ensuring interoperability across different testers and ECUs.

Communication Flow

Step	Action
1	Tester sends a diagnostic request: [0x19, 0x0A]
2	ECU processes the request internally.
3	ECU sends a positive response: [0x59, 0x0A, List of Supported DTCs]
4	Tester interprets and displays or logs the list of supported DTCs.

Notes:

• If the ECU cannot process the request, it may send a Negative Response like 0x7F 0x19 0x11 (Service Not Supported) or others based on the error encountered.
• The DTCs are often grouped by function, system, or category (such as powertrain, body, chassis, etc.).

Purpose of Report Supported DTCs (0x0A)

The Report Supported DTCs service plays a vital role in automotive diagnostics and ECU development. Its key purposes include:

1. Identifying Supported Faults: This service tells the diagnostic tester exactly which faults the ECU is capable of recognizing and reporting. It helps technicians and engineers understand the scope of diagnostic monitoring built into the ECU.
2. Building Diagnostic Applications: Diagnostic software tools can dynamically gather the list of supported DTCs from the ECU. Based on this list, they can tailor their user interfaces, troubleshooting guides, and analysis routines to match the capabilities of the specific vehicle system.
3. Validation of ECU Configuration: Engineers and validation teams use this service to confirm that an ECU is correctly configured with all necessary DTCs. It ensures that no critical faults are missing and that the ECU complies with design or regulatory requirements.
4. System Testing and Verification: During the development and testing phases, the Report Supported DTCs service helps verify the integration of the DTC database. It ensures that all required faults are properly linked to the ECU software logic and are ready for activation during operation.
5. Supporting Aftermarket Diagnostics: Independent service centers and third-party scan tool manufacturers rely on this service to develop tools that can diagnose a wide range of vehicles. By querying supported DTCs directly, they can ensure broad compatibility without needing proprietary OEM information.
6. Facilitating Preventive Maintenance: By knowing all the possible faults an ECU can report, fleet managers and vehicle owners can design better preventive maintenance schedules. This minimizes unexpected breakdowns by preparing for the most common or critical fault conditions.
7. Enhancing Communication Standardization: Using this standardized UDS service ensures that communication between diagnostic testers and ECUs remains consistent across different car models and brands. It promotes interoperability, making automotive diagnostics more universal and streamlined.
8. Reducing Manual Effort in Development: Instead of manually maintaining DTC lists in external documents, the tester can dynamically fetch the current list directly from the ECU. This reduces errors, saves time, and ensures that development, testing, and service teams always work with up-to-date data.

Report Supported DTCs (Service 0x19, Sub-function 0x0A) is a simple but powerful service that allows the diagnostic tester to obtain a full list of potential fault codes from an ECU. This functionality is essential for diagnostics, repairs, testing, and validation across the automotive industry. Understanding how it works strengthens your ability to design, troubleshoot, and maintain automotive electronic systems effectively.

Why do we need Report Supported DTCs (Service 0x19, Sub-function 0x0A) in UDS Protocol?

The Report Supported DTCs service (identified as Service 0x19, Sub-function 0x0A) in the UDS (Unified Diagnostic Services) protocol is crucial for automotive diagnostics and ECU (Electronic Control Unit) management. Here are the reasons why we need Report Supported DTCs (Service 0x19, Sub-function 0x0A) in UDS Protocol:

1. Comprehensive Fault Detection

The Report Supported DTCs service allows diagnostic testers to get a complete list of all possible Diagnostic Trouble Codes (DTCs) that an ECU can detect. This list includes both active and stored fault codes. With this information, technicians can identify the potential faults that the ECU is capable of reporting, allowing them to perform more effective diagnostics. Without this service, testers would have to rely on external documents, risking incomplete diagnostics. It ensures that all faults that the ECU can detect are accounted for, providing a complete view of the vehicle’s health.

2. Enhanced Diagnostic Tool Development

Diagnostic software tools rely heavily on Report Supported DTCs to design and improve their diagnostic capabilities. By querying the ECU for the supported DTCs, diagnostic tools can adapt to the specific vehicle model they are diagnosing. This customization ensures that the diagnostic tool doesn’t attempt to retrieve unsupported codes, saving time and reducing the chance of errors. It also allows developers to create universal diagnostic tools that work across different vehicle brands and models by accommodating a wide range of fault codes.

3. Accurate Vehicle Maintenance

Knowing which faults the ECU is capable of detecting is critical for vehicle maintenance. With this knowledge, service centers can prioritize repairs based on the supported DTCs, focusing on the most critical issues that could cause failure. It also helps in designing preventive maintenance schedules, ensuring vehicles receive timely checks for faults that are most likely to occur. Furthermore, understanding the full scope of supported DTCs helps in reducing the chances of missing potentially dangerous or critical issues that could affect vehicle performance.

4. Improved ECU Configuration Validation

During ECU development and manufacturing, the Report Supported DTCs service is used to validate the configuration of the ECU. Engineers and service technicians rely on this service to confirm that the ECU is configured with the correct set of diagnostic capabilities. This ensures that the ECU supports all necessary fault codes and is functioning as intended. It also helps verify that the ECU complies with industry regulations or manufacturer specifications, avoiding the risk of misconfigurations or missing diagnostic functionality.

5. Standardization Across the Industry

In the automotive industry, multiple manufacturers use different diagnostic protocols, but Report Supported DTCs ensures a consistent communication standard between ECUs and diagnostic testers. The UDS protocol provides a standardized method for querying supported fault codes, making it easier for service centers, aftermarket diagnostic tools, and independent repair shops to communicate with vehicles from different brands. Standardization simplifies the diagnostic process, reducing the learning curve for technicians and ensuring that diagnostic tools work seamlessly across different vehicle systems.

6. Time and Cost Efficiency

The Report Supported DTCs service increases efficiency by allowing diagnostic testers to automatically retrieve a list of supported DTCs, eliminating the need for manual documentation or guesswork. This saves valuable time in the diagnostic process, as technicians no longer need to search for or maintain extensive DTC lists. Additionally, it reduces costs by minimizing diagnostic errors and improving the overall accuracy of the diagnostic process. This efficiency is crucial for service centers that handle multiple vehicles daily, allowing them to quickly diagnose and repair issues.

7. Simplifying ECU Testing and Integration

For engineers and manufacturers, Report Supported DTCs plays an essential role in testing and verifying ECU functionality. During the development phase, engineers must ensure that the ECU integrates correctly with the appropriate fault codes. This service allows testing of whether the ECU can accurately report the faults it is designed to detect. It also helps verify that the DTC database within the ECU is correct and comprehensive, ensuring that the ECU performs as expected during actual vehicle operation.

8. Enabling Effective Aftermarket Support

The Report Supported DTCs service is vital for the aftermarket industry, where third-party diagnostic tools and service centers often need to diagnose vehicles from different manufacturers. By querying the ECU for supported DTCs, aftermarket tools can ensure compatibility with various vehicle systems. This enables independent repair shops to offer reliable diagnostics without requiring proprietary information from OEMs. It also helps reduce the need for expensive specialized diagnostic tools for each brand, making the aftermarket service more accessible.

9. Supporting Regulatory Compliance

Regulatory bodies often require that vehicles pass specific diagnostic checks to ensure safety and emissions standards are met. By using the Report Supported DTCs service, diagnostic tools can confirm that a vehicle’s ECU supports the necessary fault codes related to emissions and safety systems. This service helps ensure that vehicles meet compliance standards before they are sold or put into use. It is also crucial for post-production testing to verify that vehicles are compliant with local or regional regulations regarding vehicle diagnostics and fault reporting.

10. Future-Proofing Diagnostic Systems

With the evolution of automotive technology, especially with electric vehicles, autonomous systems, and advanced driver assistance systems (ADAS), the number and complexity of DTCs will continue to grow. The Report Supported DTCs service allows diagnostic tools to dynamically adjust and keep up with these advancements. As new fault codes are added to ECUs, diagnostic systems can remain up-to-date by querying for the latest supported DTCs, ensuring that the tools can handle newer vehicle technologies efficiently and accurately.

Report Supported DTC (0x0A)

A client can request the status of all DTCs supported by the server using the reportSupportedDTCs sub-function. The server responds with a DTCStatusAvailabilityMask, indicating the supported DTC status bits for masking. The response also includes a listOfDTCAndStatusRecord, which provides the DTC number and status for each diagnostic trouble code supported by the server.

Syntax of Report Supported DTC (SBFID-0x0A) of SID-0x19

Request Message Definition – Sub-Function = Report Supported DTC

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type =                                          report Supported DTC]	0x0A

SBFID (0x0A) Request Message Data-Parameter of SID (0x19)

reportType: This parameter reflects bits 6 – 0 of the sub-function parameter from the client’s request message.

Syntax of 0x19 SID Positive Response Message

Response Message Definition – Sub-Function = Report Supported DTCs

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
#2	Report Type = [                               report Supported DTCs	0x0A
#3	DTC Status Availability Mask	0x00 – 0xFF
#4 #5 #6 #7 #8 #9 #10 #11 : #n-3 #n-2 #n-1 #n	DTC And Status Record[] = [                                                 DTC High Byte#1                                                 DTC Middle Byte#1                                                 DTC Low Byte#1                                                      status Of DTC#1                                                 DTC High Byte#2                                                 DTC Middle Byte#2                                                      DTC Low Byte#2                                                      status Of DTC#2                                                                      :                                                      DTC High Byte#m                                                      DTC Middle Byte#m                                                      DTC Low Byte#m                                                      status Of DTC#m	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
Sure, here’s a concise version: C1: Present if DTC information is available. C2: Present if report Type matches specific conditions and more than one DTC is available.

SBFID (0x0A) Response Message Data-Parameter of SID (0x19)

reportType: This parameter reflects bits 6 – 0 of the sub-function parameter from the client’s request message.

DTCStatusAvailabilityMask: A byte where the bits are defined the same as the statusOfDTC, representing the status bits supported by the server. Bits not supported by the server will be set to ‘0’. Each supported bit (indicated by a value of ‘1’) will be implemented for every DTC supported by the server.

DTCAndStatusRecord: This parameter record includes one or more groupings of DTCHighByte, DTCMiddleByte, DTCLowByte, and statusOfDTC, based on the following formats:

Supported DTC Formats:

• ISO_14229-1_DTCFormat
• SAE_J2012-DA_DTCFormat_00
• SAE_J1939-73_DTCFormat
• SAE_J2012-DA_DTCFormat_04
• ISO_11992-4_DTCFormat

• DTCHighByte, DTCMiddleByte, DTCLowByte: Together represent a unique identification number for a specific diagnostic trouble code.
  • DTCHighByte and DTCMiddleByte: Represent the circuit/system being diagnosed.
  • DTCLowByte: Indicates the type of fault (e.g., sensor open circuit, sensor shorted to ground). Definitions found in ISO 15031-6 [12].

Formats Supported:

• SAE_J2012-DA_DTCFormat_00
• ISO_14229-1_DTCFormat
• SAE_J1939-73_DTCFormat
• ISO11992-4DTCFormat
• SAE_J2012-DA_DTCFormat_04

Syntax of 0x19 SID Negative Response Message

Response Message Definition – Sub-Function = Report Supported DTCs

Data byte	Parameter Name	Byte Value
#1	Read DTC Information –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x19
#3	Negative Response Code [ byte#1 ]	NRC

Example of Report Supported DTCs (Service 0x19, Sub-function 0x0A) in UDS Protocol

Here are the Examples of Report Supported DTCs (Service 0x19, Sub-function 0x0A) in UDS Protocol:

Example of Request Message Frame Format of SBFID-0x0A for SID-0x19

ReadDTCInformation, sub-function = reportSupportedDTCs, request message flow

Message direction	Client → Server
Message Type	Request
Data Byte	Description (all values are in hexadecimal)	Byte Value
#1	Read DTC Information Request SID	0x19
#2	Sub-Function = report Supported DTCs,                  Suppress Pos Rsp Msg Indication Bit = FALSE	0x0A

Example of Positive Response Message Frame Format of SBFID-0x0A for SID-0x19

ReadDTCInformation, sub-function = read Supported DTCs, positive response

Message direction	Server → Client
Message Type	Response
Data Byte	Description (all values are in hexadecimal)	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
#2	Report Type = Read Supported DTCs	0x0A
#3	DTCStatusAvailabilityMask	0x7F
#3 #4 #5 #6	DTC And Status Record#1 [ DTC High Byte ] DTC And Status Record#1 [ DTC Middle Byte ] DTC And Status Record#1 [ DTC Low Byte ] DTC And Status Record#1 [Status of DTC]	0x12 0x34 0x56 0x24
#7 #8 #9 #10	DTC And Status Record#2 [ DTC High Byte ] DTC And Status Record#2 [ DTC Middle Byte ] DTC And Status Record#2 [ DTC Low Byte ] DTC And Status Record#2 [Status of DTC]	0x23 0x45 0x05 0x00
#11 #12 #13 #14	DTC And Status Record #3 [ DTC High Byte ] DTC And Status Record#3 [ DTC Middle Byte ] DTC And Status Record#3 [ DTC Low Byte ] DTC And Status Record#3 [Status of DTC]	0xAB 0xCD 0x01 0x2F

Example of Negative Response Message Frame Format of SBFID-0x0A for SID-0x19

ReadDTCInformation, sub-function = read Supported DTCs, negative response

Message direction	Server → Client
Message Type	Response
Data Byte	Description (all values are in hexadecimal)	Byte Value
#1	Read DTC Information –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x19
#3	Negative Response Code [ byte#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-0x19
Request: Client --> Server
02 19 0A
Positive Response: Server --> Client
15 59 0A 7F 12 34 56 24 23 45 05 00 AB CD 01 2F
// Example for Negative Response for SID-0x19
Request: Client --> Server
03 19 0A
Negative Response: Server --> Client
03 7F 19 13

Understanding UDS Commands Over CAN Data Field

The UDS (Unified Diagnostic Services) protocol is widely used in automotive diagnostic systems for communication between diagnostic testers (clients) and Electronic Control Units (ECUs) in vehicles. It uses different service identifiers (SIDs) to perform various diagnostic functions, and the CAN protocol is used to transmit these services.

Let’s break down the example you provided for Service 0x19 (Report Supported DTCs), with Sub-function 0x0A (Report Supported DTCs) over CAN, using both positive and negative responses.

1. Positive Response for SID-0x19 (Service 0x19, Sub-function 0x0A)

Request from Client to Server:

02 19 0A

Here’s what each byte represents:

• 02: This is the Length byte, indicating that the message length is 2 bytes after the first byte.
• 19: This is the Service Identifier (SID) for the “Report Supported DTCs” service. SID-0x19 is used to request the list of DTCs that the ECU can report.
• 0A: This is the Sub-function that specifically asks for “Report Supported DTCs”.

Interpretation:

The client (diagnostic tool) is sending a request to the server (the ECU) asking for a report of all the supported DTCs (Diagnostic Trouble Codes). The sub-function 0x0A specifies that the client is requesting a report of supported DTCs, not the currently active ones.

Response from Server to Client:

15 59 0A 7F 12 34 56 24 23 45 05 00 AB CD 01 2F

Here’s what each byte represents in the response:

• 15: Total length of the response (21 bytes in decimal).
• 59: Positive response to service 0x19 (0x19 + 0x40 = 0x59).
• 0A: Echo of the requested sub-function.
• 7F 12 34: Most recent failed DTC (this is a 3-byte DTC code).
• 56 24: DTC Status Byte & additional data (depends on implementation).
• The rest (23 45 05 00 AB CD 01 2F) can include:
  • Snapshot data.
  • Extended data records.
  • DTC failure counter.
  • Environmental conditions.

This data structure is often OEM-specific, so the interpretation of the remaining bytes depends on the vehicle manufacturer’s documentation.

Interpretation:

The server (ECU) is successfully responding to the client’s request. The ECU indicates that it has received the query and is ready to provide the supported DTCs in the following data frames (not shown in the example, but would follow this frame). The positive response confirms that the ECU has successfully processed the request.

2. Negative Response for SID-0x19 (Service 0x19, Sub-function 0x0A)

Request from Client to Server:

03 19 0A

Here’s what each byte represents:

• 03: This is the Length byte, indicating that the message length is 3 bytes following this byte.
• 19: The Service Identifier (SID) for “Report Supported DTCs.”
• 0A: The Sub-function that specifies that the request is for supported DTCs.

Interpretation:

The client (diagnostic tool) is sending a request for supported DTCs, just like in the positive response case. However, in this case, it’s indicating a negative scenario where the client might have sent an incorrect or incomplete request, or there could be an issue on the ECU’s side.

Response from Server to Client:

03 7F 19 13

Here’s what each byte represents in the negative response:

• 03: The Length byte indicates that there are 3 bytes following this byte.
• 7F: This is the Negative Response SID. The 7F value indicates that the server (ECU) is sending a negative response.
• 19: This is the Service Identifier to which the negative response corresponds, which is the “Report Supported DTCs” service (0x19).
• 13: This is the Negative Response Code, indicating the specific error or issue. In this case, 13 represents a General Reject error, meaning that the request could not be processed due to an invalid request or other issue.

Interpretation:

The server (ECU) is responding with a negative response indicating that the request was not valid or could not be processed. The error code 13 is a general rejection, which could occur if the client sends an unsupported service, if the ECU is in an incorrect state to process the request, or if the parameters in the request are incorrect.

Key Takeaways:

• Positive Response: A successful communication where the ECU responds to the diagnostic tester’s request by confirming that it can provide the list of supported DTCs.
• Negative Response: A communication failure or invalid request, where the ECU rejects the request and provides an error code to indicate the issue.

Understanding these UDS commands and their associated responses is critical for automotive technicians, as they ensure proper communication between diagnostic tools and ECUs, enabling effective troubleshooting and diagnostics.