UDS Protocol: Understanding 0x0B Report First Test Failed DTC in 0x19 Service with Examples

Hello, fellow automotive diagnostics enthusiasts! In this blog post, UDS 0x0B Report First Test Failed DTC. I’m excited to walk you through one of the essential sub-functions o

f the UDS protocol – the 0x0B Report First Test Failed DTC under the 0x19 service. This feature plays a crucial role in identifying the first diagnostic trouble code (DTC) that failed during a test cycle, making it invaluable for early fault detection. Understanding how this sub-function works helps technicians and developers accurately trace issues in ECU systems. In this post, we’ll explore what the 0x0B sub-function does, how it responds, when it clears, and how it differs from other sub-functions like 0x0D. We’ll also look at the structure of the request and response messages. By the end, you’ll have a clear understanding of how to implement and interpret 0x0B effectively in your UDS-based systems. Let’s dive into diagnostics!

Introduction to Report First Test Failed DTC (0x0B) in UDS Protocol 0x19 Service

Hello, automotive diagnostics learners! In this post, we’ll explore the Report First Test Failed DTC feature, identified by sub-function 0x0B under the UDS 0x19 service. This function allows a diagnostic tester to retrieve the first DTC that failed during system tests since the last memory clear. It’s an essential tool for technicians to identify the root cause of a fault early in the diagnostic process. Understanding how and when this DTC is reported helps in making accurate repairs and avoiding repeat issues. We’ll look at how the request and response are structured, what happens if no DTCs are found, and when this data gets cleared. By the end, you’ll be confident in using sub-function 0x0B effectively in UDS-based diagnostics. Let’s begin!

What is Report First Test Failed DTC (0x0B) in UDS Protocol 0x19 Service?

The Report First Test Failed DTC is a sub-function with identifier 0x0B under the 0x19 (ReadDTCInformation) service in the UDS (Unified Diagnostic Services) protocol. This sub-function allows a diagnostic tester (client) to request the first DTC (Diagnostic Trouble Code) that failed a diagnostic test after the last memory clear on the ECU (Electronic Control Unit).

When a fault condition occurs during system operation, the ECU logs a DTC. Among those, the one that first failed is stored separately and can be retrieved using this 0x0B sub-function. This helps technicians and engineers identify the earliest fault that triggered an issue which is often the root cause of a chain of errors.

Here’s how it works:

• The client sends a request with sub-function 0x0B.
• The server responds with a DTCStatusAvailabilityMask, followed by the first failed DTC and its status byte.
• If no DTCs have failed since the last ClearDiagnosticInformation (0x14) request, the server returns only the DTCStatusAvailabilityMask without any DTCs.
• If only one DTC has failed, that same code is returned for both 0x0B (first) and 0x0D (most recent) sub-functions.

Importantly, the information returned by 0x0B is not affected by DTC aging and is cleared only when the memory is cleared using the 0x14 service.

Why do we need Report First Test Failed DTC (0x0B) in UDS Protocol 0x19 Service?

The Report First Test Failed DTC (0x0B) sub-function in the UDS 0x19 service plays a crucial role in efficient and accurate diagnostics. Here’s why it’s needed:

1. Identifying the Root Cause First

The 0x0B Report First Test Failed DTC helps identify the first failure that occurred during a diagnostic cycle. Often, this first failure is the primary cause of subsequent issues, which may trigger a chain of faults in the system. By targeting this first failure, technicians can directly address the underlying problem, avoiding the misdiagnosis of secondary faults that may arise later in the process. This process ensures a more accurate and effective repair, focusing on resolving the root cause rather than chasing multiple symptoms that may be results of the initial issue. By using 0x0B, technicians can improve their troubleshooting process and increase repair efficiency.

2. Efficient Troubleshooting

When multiple DTCs are triggered during a diagnostic test, identifying the true source of the issue can become difficult. The 0x0B sub-function streamlines this by providing the first failed DTC, which is often the most critical one to address. Focusing on the first failure reduces the time spent chasing secondary or less impactful faults, allowing for a more targeted repair process. This saves technicians time and effort, preventing the need for redundant repairs or unnecessary component replacements. It ultimately leads to quicker diagnoses and repairs, reducing the time vehicles spend in the workshop and minimizing overall downtime.

3. Minimizes Guesswork

Without the 0x0B sub-function, diagnosing a fault could involve guesswork, especially when multiple DTCs appear simultaneously. Technicians would have to address the symptoms without knowing exactly which fault triggered the chain of events. The first failed DTC provided by the 0x0B function removes this uncertainty by offering an accurate starting point for diagnosis. This allows technicians to focus on the root cause and avoid unnecessary repairs that might not address the real issue. By eliminating guesswork, 0x0B enhances diagnostic accuracy, ensuring that the technician can resolve the actual problem quickly and efficiently.

4. Supports Reliable Fault Tracking

The 0x0B sub-function is especially valuable when dealing with intermittent faults that may not consistently appear during normal diagnostics. These kinds of faults are often challenging to track, as they may not trigger during typical testing cycles. The first failed DTC provides a reliable record of the fault that occurred first, helping technicians identify recurring issues even if they are not easily reproducible. This is particularly beneficial for troubleshooting faults that may only appear under specific conditions or after certain driving patterns. By reliably tracking when a fault first occurred, 0x0B ensures that even elusive issues can be accurately diagnosed and addressed.

5. Post-Clear Validation

After a ClearDiagnosticInformation (0x14) request is made, all stored fault information is cleared from the system, and the vehicle or ECU is essentially reset. In such cases, the 0x0B sub-function can be used to check if the same fault reappears after the reset. This allows technicians to verify whether the original issue persists and is not resolved by merely clearing the fault memory. If the same DTC appears again as the first failure after the reset, it indicates that the fault is persistent and requires further attention. The post-clear validation process using 0x0B helps ensure that the system is not masking or overlooking persistent faults, giving a clearer picture of the vehicle’s health.

6. Improves Data Logging & Reporting

The 0x0B sub-function allows manufacturers, repair shops, and fleet managers to log the first failed DTC for future reference, providing valuable data for maintenance analysis and trend monitoring. Over time, this data can be used to identify recurring failures, assess the performance of vehicle components, and improve the overall reliability of the system. The information can also be valuable for warranty analysis, helping to determine if certain issues are covered under warranty or if there are patterns that need addressing. Data logging using 0x0B improves long-term maintenance strategies by giving technicians and engineers more comprehensive insights into the failure history, enabling better planning and more informed decision-making for future repairs.

7. Enhances Diagnostic Tool Functionality

The 0x0B Report First Test Failed DTC enhances the overall capability of diagnostic tools by enabling them to provide more precise and actionable information. Diagnostic tools that support this sub-function are able to offer more detailed insights into the vehicle’s health, allowing technicians to focus their attention on the most critical failures first. This not only improves the efficiency of the diagnostic process but also enhances the reliability of the tools themselves. By offering the ability to track and report the first failed DTC, diagnostic tools become more powerful and effective in identifying and addressing issues quickly, which ultimately benefits vehicle performance and the service experience. This added functionality ensures that the diagnostic process is both comprehensive and user-friendly.

Report First Test Failed DTC (Sub-function: 0x0B)

The reportFirstTestFailedDTC sub-function (0x0B) allows a diagnostic client to request the very first Diagnostic Trouble Code (DTC) that failed since the last time the ECU’s memory was cleared. When this request is made, the server responds with a DTCStatusAvailabilityMask byte, followed by the DTC number and its associated status.

However, if there are no failed DTCs stored since the last diagnostic reset, the response will include only the DTCStatusAvailabilityMask byte no DTC or status information will follow. In cases where only one DTC has failed after the last memory clear, this single DTC will be returned for both the first and the most recent test failed DTC queries.

It’s important to note that the recording of the first failed DTC is not affected by the aging process of confirmed DTCs. Furthermore, this first-failure record is cleared only when a ClearDiagnosticInformation request is successfully received and processed by the server.

Syntax of Report First Test Failed DTC (SBFID-0x0B) of SID-0x19

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

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

Syntax of 0x19 SID Positive Response Message

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

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
# 2	Report Type = [                               Report First Test Failed DTC ]	0x0B
#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 (0x0B) 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_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 First 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 First Test Failed DTC (0x0B) in UDS Protocol 0x19 Service

Here are the Examples of Report First Test Failed DTC (0x0B) in UDS Protocol 0x19 Service:

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

Read DTC Information, Sub-Function = Report First Test Failed DTC, Request Message Flow Example

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 First Test Failed DTC,                  Suppress Pos Rsp Msg Indication Bit = FALSE	0x0B

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

Read DTC Information, Sub-Function = Report First Test Failed DTC, Positive Response Example

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 = Report First Test Failed DTC	0x0B
#3	DTC Status Availability Mask	0xFF
#4 #5 #6 #7	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 0x26

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

Read DTC Information, Sub-function = Report First Test Failed DTC, Negative Response Example

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 0B
Positive Response: Server --> Client
07 59 0B FF 12 34 56 26
// Example for Negative Response for SID-0x19
Request: Client --> Server
03 19 0B
Negative Response: Server --> Client
03 7F 19 13

Understanding UDS Command Flow for Report First Test Failed DTC (0x0B) in 0x19 Service

In UDS (Unified Diagnostic Services) over CAN (also called DoCAN), communication between a diagnostic client (tester tool) and a server (ECU) follows a structured format. Here’s a breakdown of how the Report First Test Failed DTC (0x0B) is used under the ReadDTCInformation service (0x19).

Let’s go through both positive and negative response examples.

1. Positive Response Example for SID 0x19, Sub-function 0x0B

Request (Client to Server):

02 19 0B

Explanation of the Code:

• 02 → Number of following bytes (2 bytes: 0x19 and 0x0B).
• 19 → Service ID for ReadDTCInformation.
• 0B → Sub-function for ReportFirstTestFailedDTC.

This request asks the ECU (server) to return the first test failed DTC that occurred since the last DTC clear.

Positive Response (Server to Client):

07 59 0B FF 12 34 56 26

Explanation of the Code:

• 07 → Total number of bytes following this one.
• 59 → Positive response for service 0x19 (i.e., 0x40 + 0x19 = 0x59).
• 0B → Echoes the requested sub-function (ReportFirstTestFailedDTC).
• FF → DTC Status Availability Mask (tells which status bits are available).
• 12 34 56 → The first failed DTC code (in this example, DTC = 0x123456).
• 26 → DTC status byte (shows current status of the DTC like test failed, confirmed, etc.).

This means the ECU has found a valid DTC (0x123456) that first failed, and it’s responding with all relevant information.

2. Negative Response Example for SID 0x19, Sub-function 0x0B

Request (Client to Server):

03 19 0B

Explanation of the Code:

• 03 → Number of following bytes (3 bytes: 0x19, 0x0B).
• 19 → ReadDTCInformation service ID.
• 0B → Sub-function: ReportFirstTestFailedDTC.

Negative Response (Server to Client):

03 7F 19 13

Explanation of the Code:

• 03 → Number of following bytes.
• 7F → Indicates a negative response.
• 19 → Original requested service ID (ReadDTCInformation).
• 13 → Negative Response Code (NRC) = 0x13, which means: “Request Out of Range” – This typically means:
  • The sub-function is not supported by the ECU,
  • No failed DTC exists,
  • Or the DTC data has been cleared and no new failures have occurred since.

Summary from the Example:

Field	Description
0x19	UDS Service ID for ReadDTCInformation
0x0B	Sub-function to Report First Test Failed DTC
0x59	Positive response code (0x40 + 0x19)
0x7F	Negative response indicator
0x13	NRC: Request Out of Range (common when no DTC is present)
FF	DTC Status Availability Mask
12 34 56	Example DTC code returned
26	Status byte of the returned DTC