Understanding UDS 0x0D Sub-function: Report Most Recent Test Failed DTC in 0x19 Service

Hello, automotive diagnostics enthusiasts! In this blog post, UDS Report Most Recent Test Failed DTC (0x0D). I’ll introduce you to a crucial concept in the UDS (Unified Diagnos

tic Services) protocol specifically, the 0x0D sub-function of service 0x19. This sub-function, known as Report Most Recent Test Failed DTC, allows you to retrieve the latest Diagnostic Trouble Code that has failed since the last memory clear. Understanding this feature is essential for identifying recent vehicle issues quickly and accurately. Whether you’re a diagnostics engineer, ECU developer, or technician, mastering this sub-function will help streamline fault analysis and repair workflows. In this post, we’ll explore what the 0x0D sub-function does, how it works, when to use it, and what the response structure looks like. By the end, you’ll have a clear grasp of how to implement and interpret this powerful diagnostic tool. Let’s dive into the world of UDS diagnostics!

Introduction to Report Most Recent Test Failed DTC (0x0D) in 0x19 Service of UDS Protocol

Welcome to this deep dive into the UDS protocol! In today’s post, we’ll focus on a specific sub-function of the 0x19 service 0x0D: Report Most Recent Test Failed DTC. This function is crucial for retrieving the latest DTC that has failed since the last time diagnostic data was cleared. It plays an important role in real-time troubleshooting by helping technicians and developers quickly identify recent faults in the system. Whether you’re developing diagnostic software or working on ECU testing, understanding how this sub-function operates can significantly improve your workflow. We’ll explain how the request is structured, what kind of response to expect, and how the data can be used effectively. Let’s begin exploring how this sub-function enhances fault analysis in vehicle diagnostics.

What is Report Most Recent Test Failed DTC (0x0D) in 0x19 Service of UDS Protocol?

In the Unified Diagnostic Services (UDS) protocol, service 0x19 (ReadDTCInformation) is used to access and retrieve Diagnostic Trouble Codes (DTCs) from a vehicle’s Electronic Control Unit (ECU). One of its useful sub-functions is 0x0D, also known as Report Most Recent Test Failed DTC.

Purpose of Sub-function 0x0D

The 0x0D sub-function allows a diagnostic client (like a scan tool or diagnostic software) to retrieve the most recently failed DTC that has occurred since the last time the DTC memory was cleared using the ClearDiagnosticInformation service (0x14). This helps identify the latest fault that has been registered by the ECU, which is very helpful in time-sensitive diagnostics or debugging.

Why do we need Report Most Recent Test Failed DTC (0x0D) in 0x19 Service of UDS Protocol?

The sub-function 0x0D – Report Most Recent Test Failed DTC plays a crucial role in modern vehicle diagnostics by enabling the retrieval of the latest fault that occurred in an Electronic Control Unit (ECU). Here’s why it’s important:

1. Quick Fault Identification

The 0x0D sub-function in the UDS protocol is designed to help diagnostic tools quickly retrieve the most recent failed Diagnostic Trouble Code (DTC). This allows technicians to focus directly on the newest fault logged in the ECU, eliminating the need to go through a long list of historical DTCs. By narrowing the search to only the most recent failure, the process becomes more efficient, enabling a faster response to the current issue without sifting through older errors. This immediate focus is particularly helpful in critical diagnostic scenarios where time is of the essence, such as in production lines or real-time troubleshooting.

2. Supports Efficient Troubleshooting

When an ECU stores multiple DTCs, it can become overwhelming for a technician to manually sift through them to find the most relevant failure. The 0x0D sub-function simplifies this by immediately providing the most recent test failure, allowing the technician to quickly identify the root cause of the issue. This process saves significant time by avoiding the need to manually search through a large list of errors, helping technicians pinpoint and address the most recent fault efficiently. By focusing on the latest failure, troubleshooting becomes more targeted and effective, leading to faster fixes and less time spent diagnosing.

3. Useful After Repairs or Reset

After performing a repair or resetting the ECU, it’s crucial to confirm whether the system has returned to normal or if a new problem has emerged. The 0x0D sub-function is invaluable in this scenario, as it enables the diagnostic client to retrieve the most recently failed DTC that may indicate a persistent issue. By doing so, the technician can quickly assess if the repair was successful or if a new fault has appeared. This process eliminates the guesswork and provides immediate insight into the vehicle’s health post-repair or reset, ensuring more accurate results and faster resolution of any new faults that may have occurred.

4. Critical in Automated Testing

In automated testing environments, such as those used in production lines or high-volume test benches, the 0x0D sub-function plays an essential role in streamlining diagnostics. These systems are designed to quickly process large numbers of ECUs, and retrieving only the most recent failed DTC makes the process far more efficient. Rather than processing a list of all past errors, which could be time-consuming, the system can immediately identify the most recent fault, allowing for faster decision-making and reducing the time spent on each unit. This helps maintain high throughput while ensuring the quality and functionality of each unit tested.

5. Memory Optimization

One of the advantages of using the 0x0D sub-function is that it helps optimize both memory usage and communication bandwidth. Instead of retrieving a potentially large list of all logged DTCs, this function only returns the most recent failed code. This significantly reduces the amount of data that needs to be transferred between the ECU and the diagnostic tool. In environments where bandwidth may be limited or when a quick response is required, this approach ensures that diagnostic processes are efficient, allowing faster and more reliable fault detection with minimal data overhead.

6. Minimizes Human Error

When dealing with multiple DTCs, there is always the risk that a technician may overlook the most relevant issue, especially when the fault list is long. The 0x0D sub-function minimizes this risk by ensuring that only the most recent failure is returned, reducing the possibility of human error. Technicians are less likely to miss an important fault, as they can focus on the latest DTC without the distraction of older, potentially irrelevant errors. This approach improves the accuracy and reliability of diagnostics, as it ensures that technicians are always working with the most up-to-date information available.

7. Enhances System Monitoring and Maintenance

The 0x0D sub-function is not just useful for immediate diagnostics; it also plays an important role in ongoing system monitoring and maintenance. By providing access to the most recent test failure, it allows technicians to keep track of recurring or newly developed issues within the ECU over time. This enables proactive maintenance, as any patterns or trends in the most recent faults can be quickly identified. Regular use of this sub-function can help improve long-term system reliability by addressing issues before they become critical failures, ensuring that the vehicle or system remains in optimal working condition.

Understanding Sub-Function 0x0D: Report Most Recent Test Failed DTC

The 0x0D sub-function (reportMostRecentTestFailedDTC) enables the diagnostic client to request the most recent DTC that failed a test. This provides insight into the latest issue detected by the ECU, helping service technicians prioritize current or recurring faults.

In response, the ECU sends:

• The DTCStatusAvailabilityMask.
• The most recently failed DTC that has been registered since the last diagnostic memory clear.
• The associated status byte for that DTC.

Just like with reportFirstTestFailedDTC, if there are no failed DTCs since the last memory clear, the server omits DTC and status information from the response. And if only one DTC has failed, that same DTC will be returned in both the first and most recent DTC queries. It’s crucial to understand that the most recent failed DTC is tracked independently of any DTC aging process. However, once a ClearDiagnosticInformation request is successfully processed, the record of the most recent failed DTC is cleared.

Syntax of Report Most Recent Test Failed DTC (SBFID-0x0D) of SID-0x19

Request Message Definition – Sub-function = Report Most Recent Test Failed DTC

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type =                             Report Most Recent Test Failed DTC ]	0x0D

Syntax of 0x19 SID Positive Response Message

Response Message Definition – Sub-function = Report Most Recent Test Failed DTC

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
# 2	Report Type = [                               Report Most Recent Test Failed DTC ]	0x0D
#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 OfDTC#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
C1: This parameter is only present if DTC information is available to be reported. C2: This parameter is only present if reportType = reportSupportedDTCs, reportDTCByStatusMask, reportMirrorMemoryDTCByStatusMask, reportEmissionsOBDDTCByStatusMask, reportDTCWithPermanentStatus and more than one DTC information is available to be reported.

SBFID (0x0D) 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).

Formats Supported:

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

Syntax of 0x19 SID Negative Response Message

Response Message Definition – Sub-Function = Report Most Recent Test Failed DTC

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 Most Recent Test Failed DTC (0x0D) in 0x19 Service of UDS Protocol

Here are the Examples of Report Most Recent Test Failed DTC (0x0D) in 0x19 Service of UDS Protocol:

// 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 0D
Positive Response: Server --> Client
15 59 0D FF 12 34 56 26 F1 90 06 CC D0 11 19 A4
// Example for Negative Response for SID-0x19
Request: Client --> Server
03 19 0D Negative Response: Server --> Client
03 7F 19 13

Understanding UDS Commands for SID 0x19 with Sub-function 0x0D (Report Most Recent Test Failed DTC)

The 0x19 service in UDS is known as ReadDTCInformation, and it allows a diagnostic client to request Diagnostic Trouble Codes (DTCs) from an ECU. One of the sub-functions of this service is 0x0D, which is used to retrieve the most recent test failed DTC.

Let’s break down both the positive and negative response examples over a CAN network.

1. Positive Response Example

Request from Client to Server:

02 19 0D

Explanation of the Code:

• 02: Indicates the total number of bytes in the request message (excluding the PCI byte, if segmented).
• 19: Service Identifier (SID) for ReadDTCInformation.
• 0D: Sub-function for ReportMostRecentTestFailedDTC.

This means the diagnostic client is asking the server (ECU) to return the most recent test failed DTC.

Positive Response from Server to Client:

15 59 0D FF 12 34 56 26 F1 90 06 CC D0 11 19 A4

Explanation of the Code:

• 15: PCI – First Frame indicating 15 bytes of total data (will continue if needed).
• 59: Positive Response Code (0x19 + 0x40).
• 0D: Echo of the sub-function requested.
• FF: DTC record number or internal index.
• 12 34 56: DTC code – example DTC 0x123456.
• 26: Extended data record number.
• F1 90 06 CC D0 11 19 A4: Extended data content (depends on OEM definition).

The ECU responded with the extended data related to DTC 0x123456. The record number is 26, and the remaining bytes contain diagnostic snapshot data collected when the fault occurred (e.g., sensor readings, temperature, etc.).

2. Negative Response Example

Request from Client to Server:

03 19 0D

Explanation of the Code:

• 03: Indicates the number of bytes in the message.
• 19: Service Identifier for ReadDTCInformation.
• 0D: Sub-function ReportMostRecentTestFailedDTC.

This is the same request format as above, sent by the diagnostic client.

Negative Response from Server to Client:

03 7F 19 13

Explanation of the Code:

• 03: Number of bytes in the response.
• 7F: This is the standard prefix for a negative response.
• 19: Refers to the service that caused the negative response (SID 0x19).
• 13: NRC (Negative Response Code) = 0x13, which stands for “InvalidFormat” or “IncorrectMessageLength or InvalidFormat”.

This indicates that the server rejected the request possibly due to incorrect message length, improper formatting, or a missing required parameter.

This example demonstrates how a diagnostic client can use the UDS 0x19 service with the 0x0D sub-function to retrieve the most recent test failed DTC over CAN. Understanding both positive and negative responses is essential for debugging and designing robust diagnostic tools in automotive applications. Correctly formatting the request and interpreting the response helps ensure accurate vehicle diagnostics and maintenance.