Report DTC Ext Data Record By DTC Number (0x06): 0x19 SID in UDS

Leave a Comment / Protocols / By piembsystech

" rel="noreferrer noopener">UDS. I’ll introduce you to a vital feature of the UDS protocol Report DTC Extended Data Record by DTC Number (0x06), part of Service 0x19. This sub-function allows you to retrieve extended diagnostic data related to specific Diagnostic Trouble Codes (DTCs). These extended records often include additional sensor values, operating conditions, or historical information stored by the ECU. Such data is incredibly valuable for understanding the root cause of faults and analyzing system behavior more deeply. I’ll walk you through how this service works, the request and response formats, and how to interpret the results. By the end of this post, you’ll be confident in using 0x06 for advanced diagnostic tasks. Let’s get started!

Introduction to Report DTC Extended Data Record by DTC Number (0x06): 0x19 Service in UDS Protocol

In the world of automotive diagnostics, accessing detailed fault information is crucial for efficient troubleshooting. The UDS protocol’s 0x19 service, specifically sub-function 0x06, allows technicians to retrieve extended data records linked to specific Diagnostic Trouble Codes (DTCs). This data can include sensor states, system values, or operational parameters captured at the time of the fault. Such insights help in understanding not just what went wrong, but why and under what conditions the fault occurred. In this post, we’ll explore how the Report DTC Extended Data Record by DTC Number (0x06) works, how to structure requests, and how to interpret responses. By the end, you’ll see how this service enhances diagnostic accuracy and root cause analysis.

What is ‘Report DTC Extended Data Record by DTC Number (0x06)’ in 0x19 Service of the UDS Protocol?

The ‘Report DTC Extended Data Record by DTC Number (0x06)’ is a sub-function of the 0x19 service in the UDS (Unified Diagnostic Services) protocol. It is used to request extended diagnostic data related to a specific Diagnostic Trouble Code (DTC) stored in the vehicle’s ECU. Unlike basic DTC information, this extended data provides additional context such as sensor readings, engine conditions, or system status at the time the fault occurred. This service helps technicians and diagnostic tools perform a deeper analysis of the fault, making troubleshooting more accurate and efficient.

Why do we need ‘Report DTC Extended Data Record by DTC Number (0x06)’ in 0x19 Service of the UDS Protocol?

Here are the reasons why we need ‘Report DTC Extended Data Record by DTC Number (0x06)’ in 0x19 Service of the UDS Protocol:

1. Detailed Insight into Fault Conditions

The Report DTC Extended Data Record by DTC Number (0x06) offers more than just the fault code it provides a comprehensive picture of the vehicle’s state at the time of the fault. This includes crucial sensor data, operating conditions, and other parameters that were active when the problem was triggered. For example, if a sensor failure causes an issue, extended data could include readings from related sensors or system components. This information helps technicians understand how external factors or multiple systems contributed to the issue, making it easier to identify the underlying cause.

2. Enhanced Diagnostic Accuracy

Extended data allows technicians to conduct more precise diagnostics. Instead of relying solely on generic fault codes, which may not provide enough context, they can now analyze detailed readings. This detailed information helps avoid misdiagnosis by confirming whether the fault is a one-time event or a recurring problem. By gaining more insights into the vehicle’s behavior when the fault occurred, they can pinpoint the exact root cause, saving time and improving repair accuracy. This is particularly useful when dealing with intermittent or complex issues that don’t always appear during routine diagnostics.

3. Faster Troubleshooting and Reduced Diagnostic Time

With access to extended data, technicians don’t have to rely on guesswork or perform extensive trial-and-error procedures. The detailed records allow them to immediately focus on the key components or systems involved in the fault. This results in faster diagnosis and reduced downtime for the vehicle. By cutting down on unnecessary checks and pinpointing the problem quickly, workshops can serve more vehicles per day, improving productivity and customer satisfaction.

4. Improved Vehicle Reliability and Safety

The detailed diagnostics provided by the extended data plays a crucial role in ensuring vehicle safety and reliability. When technicians can accurately identify the cause of an issue, they can implement more effective solutions. This is particularly important for safety-critical systems such as airbags, brakes, and engine management systems. By thoroughly investigating and addressing faults based on extended data, mechanics can help prevent future breakdowns or safety hazards, leading to more reliable vehicles on the road.

5. Facilitates Intermittent Fault Detection

One of the most significant advantages of extended data is its ability to detect intermittent faults that may not be visible during a standard diagnostic scan. These types of faults often occur sporadically, making them harder to identify using traditional methods. By recording a wide range of data points during fault events, extended data provides a detailed history that can help identify the cause of sporadic issues. This ability to capture “occasional” faults ensures that vehicles are thoroughly checked for problems that may not appear during regular tests.

6. Supports Advanced Diagnostics for Complex Systems

Modern vehicles are equipped with a wide range of complex systems, such as hybrid powertrains, advanced driver-assistance systems (ADAS), and multiple sensors. For these systems, a simple DTC is often not enough. The extended data gives insight into multiple parameters within these advanced systems, enabling a thorough diagnosis. This is particularly important for newer vehicles, where diagnosing issues in complex systems requires a holistic view of the vehicle’s performance, not just a single fault code.

7. Better Maintenance and Preventive Measures

Having access to extended DTC data allows vehicle owners, fleet managers, and service centers to be proactive with their maintenance practices. By analyzing the stored data, they can detect trends or patterns that might indicate a potential failure in the future, even before it occurs. This enables preventive actions such as replacing parts or performing system updates before a minor issue escalates into a major failure. Proactive maintenance can not only extend the life of vehicle components but also help avoid costly repairs and unplanned breakdowns that could disrupt operations.

Report DTC Ext Data Record By DTC Number (0x06)

A client can request DTCExtendedData for a specific DTCMaskRecord and DTCExtendedData record number using the reportDTCExtDataRecordByDTCNumber sub-function. The server searches for a match with the provided DTCMaskRecord and returns the DTCExtendedData record specified by the DTCExtDataRecordNumber.

Key Points:

• DTCExtDataRecordNumber and DTCMaskRecord are separate.
• If the record number is 0xFE or 0xFF, the server returns all DTCExtendedData records for the DTC in one response.
• The server responds with a single DTCExtendedData record if the record number is neither 0xFE nor 0xFF.
• The format of the DTCExtendedData record is defined by the manufacturer and may include multiple data types.

Invalid parameters result in a negative response, while valid parameters with no data return only the DTCAndStatusRecord. Data is cleared upon a successful ClearDiagnosticInformation request. Manufacturers must specify rules for data deletion in cases of memory overflow.

Syntax of Report DTC Ext Data Record By DTC Number (SBFID-0x06) of SID-0x19

Request Message Definition – Sub-Function = Report DTC Ext Data Record By DTC Number

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type =               report DTC Ext Data Record By DTC Number ]	0x06
#3 #4 #5	DTC Mask Record[] = [                                        DTC High Byte                                        DTC Middle Byte                                        DTC Low Byte ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
#6	DTC Ext Data Record Number	0x00 – 0xFF

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

DTCMaskRecord [DTCHighByte, DTCMiddleByte, DTCLowByte]

DTCMaskRecord is a 3-byte value representing a unique diagnostic trouble code (DTC) using DTCHighByte, DTCMiddleByte, and DTCLowByte. The DTC can be decoded in various ways:

• ISO 15031-6: Identified by DTCFormatIdentifier = SAE_J2012-DA_DTCFormat_00
• ISO 14229: Identified by DTCFormatIdentifier = ISO_14229-1_DTCFormat (manufacturer-defined)
• SAE J1939-73: Identified by DTCFormatIdentifier = SAE_J1939-73_DTCFormat
• ISO 11992-4: Identified by DTCFormatIdentifier = ISO_11992-4_DTCFormat
• ISO 27145-2: Identified by DTCFormatIdentifier = SAE_J2012-DA_WWH-OBD_DTCFormat

DTCExtDataRecordNumber

DTCExtDataRecordNumber is a 1-byte value indicating the specific DTCExtendedData record requested for a DTCMaskRecord via the reportDTCExtDataRecordByDTCNumber or reportDTCExtDataRecordByRecordNumber sub-function. For emissions-related servers (OBD-compliant ECUs), 0x00 is reserved for future OBD use.

• The DTCExtDataRecordNumber ranges are reserved as follows:
  • 0x00: Reserved by ISO/SAE.
  • 0x01 – 0x8F: Requests manufacturer-specific DTCExtendedData records.
  • 0x90 – 0xEF: Requests legislated OBD DTCExtendedData records.
  • 0xF0 – 0xFD: Reserved by ISO/SAE for future group reporting.
  • 0xFE: Requests all legislated OBD DTCExtendedData records in a single response.
  • 0xFF: Requests all stored DTCExtendedData records in a single response.

Extended Data Record

There are so many Extended data records can be added by the OEM or any suppliers. But still there are some data records that should be the mandatory as per the ISO standards, such as:

• Time
• Occurence counter
• Fault detection counter
• Highest fault detection counter

Syntax of 0x19 SID Positive Response Message

Response Message Definition – Sub-Function = Report DTC Ext Data Record By DTC Number

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
#2	Report Type = [                             report DTC Ext Data Record By DTC Number]	0x06
#3 #4 #5 #6	DTC And Status Record[] = [                                                                                           DTC High Byte                                                       DTC Middle Byte                                                       DTC Low Byte                                                       Status Of DTC ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
#7	DTC Ext Data Record Number#1	0x00 – 0xFD
#8 : #18+(p-1)	DTC Ext Data Record[]#1 = [        extended Data#1 byte#1                           : extendedData#1 byte#p ]	0x00 – 0xFF : 0x00 – 0xFF
:	:	:
#t	DTC Ext Data Record Number#x	0x00 – 0xFD
#t+1 : #t+1+(q-1)	DTC Ext Data Record[]#x = [                                                    extended Data#x byte#1                                                                          :                                                    extended Data#x byte#q ]	0x00 – 0xFF : 0x00 – 0xFF
 Here’s a concise version in English: C1: DTC Ext Data Record Number and the extended Data in the DTC Ext Data Record parameter are included if there’s at least one DTC Ext Data Record available for reporting. C2: DTC Ext Data Record Number and the extended Data in the DTC Ext Data Record parameter are included only when all records are requested (DTC Ext Data Record Number set to 0xFE or 0xFF), and more than one record is available for reporting.

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

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

DTCExtDataRecordNumber: This parameter is either the echo of the DTCExtDataRecordNumber specified by the client in the reportDTCExtDataRecordByDTCNumber or reportDTCExtDataRecordByRecordNumber request, or the actual DTCExtDataRecordNumber of a stored DTCExtendedData record.

DTCExtDataRecord: The DTCExtDataRecord is a server-specific block of information that may include extended status details related to a DTC. It contains DTC parameter values identified at the time of the request.

Syntax of 0x19 SID Negative Response Message

Response Message Definition – Sub-Function = Report DTC Ext Data Record By DTC Number

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 DTC Extended Data Record by DTC Number (0x06)’ in 0x19 Service of the UDS Protocol

Following are the Examples of ‘Report DTC Extended Data Record by DTC Number (0x06)’ in 0x19 Service of the UDS Protocol:

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

ReadDTCInformation, sub-function = reportDTCExtDataRecordByDTCNumber, 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 = reportDTCExtDataRecordByDTCNumber,                  Suppress Pos Rsp Msg Indication Bit = FALSE	0x06
#3 #4 #5	DTCMaskRecord [ DTCHighByte ] DTCMaskRecord [ DTCMiddleByte ] DTCMaskRecord [ DTCLowByte ]	0x12 0x34 0x56
#6	DTCExtDataRecordNumber	0xFF

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

ReadDTCInformation, sub-function = reportDTCExtDataRecordByDTCNumber, 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 = reportDTCExtDataRecordByDTCNumber	0x06
#3 #4 #5 #6	DTC And Status Record [ DTC High Byte ] DTC And Status Record [ DTC Middle Byte ] DTC And Status Record [ DTC Low Byte ] DTCAndStatusRecord [ Status of DTC ]	0x12 0x34 0x56 0x24
#7	DTCExtDataRecordNumber	0x05
#8	DTCExtDataRecord [ byte#1 ]	0x17
#9	DTCExtDataRecordNumber	0x10
#10	DTCExtDataRecord [ byte#1 ]	0x79

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

ReadDTCInformation, sub-function = reportDTCExtDataRecordByDTCNumber, 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 06
Positive Response: Server --> Client
10 59 06 12 34 56 24 05 17 10 79
// Example for Negative Response for SID-0x19
Request: Client --> Server
01 19 06
Negative Response: Server --> Client
03 7F 19 13

Understanding UDS Commands for ‘Report DTC Extended Data Record by DTC Number (0x06)’ with CAN Communication

In UDS (Unified Diagnostic Services) protocol, service 0x19 (Read DTC Information) with sub-function 0x06 (Report DTC Extended Data Record by DTC Number) is used to retrieve extended data related to a specific Diagnostic Trouble Code (DTC). Let’s break down the provided examples step-by-step:

1. Positive Response Example

Request:

Client → Server
02 19 06

• 02: Number of additional bytes following (Length field).
• 19: Service Identifier (SID) for Read DTC Information.
• 06: Sub-function for Report DTC Extended Data Record by DTC Number.

The client sends a request asking for the extended data related to a specific DTC.

Positive Response:

Server → Client
10 59 06 12 34 56 24 05 17 10 79

• 10 – Total number of bytes in the message (First Frame indicator if multi-frame; but in this context, assume 1-frame).
• 59 – Positive response SID (0x19 + 0x40).
• 06 – Echoed sub-function.
• 12 34 56 – DTC for which extended data is being reported.
• 24 – DTC status byte (bitfield representing current DTC state).
• 05 – Record number or identifier for the extended data.
• 17 10 79 – Actual extended data (interpretation depends on OEM documentation; could represent time, temp, counter values, etc.)

These values provide richer detail compared to the basic DTC response, making them invaluable in advanced diagnostics.

2. Negative Response Example

Request:

Client → Server
01 19 06

• 01: Number of additional bytes.
• 19: Service Identifier (SID) for Read DTC Information.
• 06: Sub-function code for Report DTC Extended Data Record by DTC Number.

Here, the client sends another request but possibly with incomplete, invalid, or inappropriate parameters.

Negative Response:

Server → Client
03 7F 19 13

• 03: Number of additional bytes.
• 7F: Negative Response SID.
• 19: Original requested service (indicating the request was for 0x19).
• 13: Negative Response Code (NRC).
  • 0x13 means “Incorrect Message Length or Invalid Format”.

This negative response tells the client that the message sent was not properly formatted or had the wrong length.

Key Takeaways:

• A positive response (0x59) means the ECU accepted the request and provided the requested extended DTC data.
• A negative response (0x7F) indicates an error, such as message formatting issues or invalid parameters.

These command exchanges are essential for diagnostic tools to retrieve detailed error data from a vehicle’s Electronic Control Unit (ECU) during servicing and troubleshooting.