Understanding UDS Service 0x19: Report DTC Extended Data by Record Number (0x16 Subfunction)

Hello, fellow automotive diagnostics enthusiasts! In this blog post, Report DTC Ext Data Record By Record Number (0x16) in UDS. I’m excited to walk you through a powerful featu

re of the UDS (Unified Diagnostic Services) protocol Service 0x19 with Subfunction 0x16. This service allows you to report DTC extended data by record number, which is crucial for in-depth fault analysis in vehicle ECUs. Whether you’re developing diagnostic tools or working on HIL test systems, understanding this service can greatly improve how you extract and interpret diagnostic data. We’ll break down the structure, use cases, and request/response formats of this UDS service. I’ll also highlight practical examples to help you implement it in real-world automotive applications. By the end of this post, you’ll be confident in using 0x19-0x16 to streamline your diagnostics workflows. Let’s dive in!

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

If you’re working with vehicle diagnostics, you’ve likely encountered UDS (Unified Diagnostic Services). One particularly useful feature within this protocol is Service 0x19, which deals with reading DTC (Diagnostic Trouble Code) information. Among its subfunctions, 0x16 stands out as it allows retrieval of extended data associated with a DTC, identified by a specific record number. This extended data can provide valuable context for troubleshooting and root cause analysis. In this post, we’ll walk through the purpose, structure, and usage of this subfunction in detail. Whether you’re developing diagnostic tools or validating ECUs, mastering this service is a must. Let’s unpack how it works and where it fits into your diagnostics workflow.

What is Report DTC Extended Data by Record Number (0x16) in UDS Protocol 0x19 Service?

UDS (Unified Diagnostic Services) is a communication protocol defined in ISO 14229, widely used in automotive electronics for diagnosing and managing ECUs (Electronic Control Units). It allows reading DTCs (Diagnostic Trouble Codes), controlling outputs, updating software, and more.

One important UDS service is Service 0x19 – “Read DTC Information”, which provides various subfunctions to read and handle DTC-related data.

Why do we need Report DTC Extended Data by Record Number (0x16) in UDS Protocol 0x19 Service?

In automotive diagnostics, simply knowing that a fault (DTC) occurred is often not enough. To properly understand, analyze, and resolve faults, we often need additional context this is where extended data comes in. Subfunction 0x16 of UDS Service 0x19 helps us access this crucial data in a structured, targeted way.

1. Provides Deeper Context for DTCs

A DTC just tells you that something went wrong, but not how, when, or under what conditions. Extended data might include:

• Engine temperature
• Battery voltage
• Mileage when the fault occurred
• Number of fault occurrences
• Snapshot of sensor values at the time of error

This helps engineers reproduce and understand the root cause of the fault.

2. Access Specific Data via Record Numbers

Each DTC can have multiple sets of extended data, stored as different record numbers. For example:

• Record #1 → Temperature & voltage
• Record #2 → RPM & throttle position
• Record #3 → Event counters

With subfunction 0x16, the tester can select a specific record, making data retrieval efficient and precise especially useful in memory-constrained ECUs.

3. Crucial for HIL Testing and Validation

In Hardware-in-the-Loop (HIL) testing, testers inject faults and verify that:

• The ECU logs the fault correctly.
• The associated extended data (e.g., input signals at the time) is recorded and retrievable.

Subfunction 0x16 lets testers query specific data records, which is key for automated validation scripts and test case traceability.

4. Supports Diagnostic Tool Development

Professional diagnostic tools (like those from Bosch, AVL, Vector, or OEMs) use 0x16 to:

• Provide detailed diagnostic reports.
• Present user-friendly fault history with timestamps and operating conditions.
• Offer recommendations based on data trends.

Without subfunction 0x16, these tools would have limited visibility into fault details.

5. Helps in After-Sales and Field Support

In service centers or fleet diagnostics:

• Extended data helps technicians identify intermittent or environmental issues.
• It reduces unnecessary part replacements by pinpointing root causes (e.g., low voltage rather than faulty hardware).

6. OEM Compliance and Regulations

Some OEMs or regulatory standards (e.g., OBD, ISO standards) require:

• Logging and reporting of specific freeze-frame/extended data.
• Accessibility of this data via standard diagnostic protocols like UDS.

Using 0x16 ensures the ECU complies with these requirements.

7. Enables Data-Driven Maintenance and Predictive Diagnostics

With access to extended data over time (e.g., sensor trends or operating hours when DTCs occur), OEMs and fleet operators can:

• Identify patterns in component failures
• Implement predictive maintenance strategies to prevent breakdowns
• Improve warranty analysis and cost optimization

Subfunction 0x16 helps retrieve the exact historical context needed for these analytics.

8. Facilitates Consistent ECU Behavior Across Vehicle Platforms

Many OEMs develop shared diagnostic strategies across multiple ECUs and vehicle models. Subfunction 0x16 provides a standardized way to retrieve detailed diagnostic data, ensuring:

• Consistent reporting format across ECUs
• Easier integration into diagnostic workflows
• Better interoperability with backend systems and cloud-based diagnostic platforms

This reduces development effort and improves maintainability across the vehicle’s lifecycle.

Report DTC Extended Data by Record Number (0x16) in UDS Protocol 0x19 Service

To retrieve extended diagnostic information, a client (typically a diagnostic tester) can issue a request using Service 0x19 with Subfunction 0x16, known as Report DTC Extended Data by Record Number. This request targets a specific DTC Extended Data Record Number, which is predefined by the client.

When the server (usually the ECU) receives this request, it scans through all supported Diagnostic Trouble Codes (DTCs) and identifies those that contain extended data records matching the specified record number. In this context, the record number applies universally it must match across all DTCs being queried, not just one.

If valid, the server responds with a list of DTCs that include:

• The DTC code
• Its status
• And the corresponding extended data associated with the requested record number

The structure and meaning of this extended data are entirely defined by the vehicle manufacturer. Much like UDS data identifiers (DIDs), each record number corresponds to a specific data layout and content, which must be documented and agreed upon within the OEM’s diagnostic specification.

However, if the record number requested by the client is invalid or not supported, the server will issue a negative response indicating that the request cannot be fulfilled.

Additionally, the handling of extended data deletion for example, when a ClearDiagnosticInformation service (Service 0x14) is triggered is governed by manufacturer-defined rules. OEMs are also responsible for defining how the ECU manages memory overflow situations, particularly when there’s no longer space to store new DTCs or their associated extended data.

Syntax of Report DTC Extended Data by Record Number (SBFID-0x16) of SID-0x19

Request Message Definition – Sub-Function = Report DTC Extended Data by Record 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 Record Number ]	0x16
#3	DTC Ext Data Record Number	0x00 – 0xEF

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

In the UDS protocol, the DTCExtDataRecordNumber is a 1-byte identifier used to specify exactly which DTC Extended Data Record the client wants to retrieve. This parameter plays a key role in both the reportDTCExtDataRecordByDTCNumber and reportDTCExtDataRecordByRecordNumber subfunctions under Service 0x19.

For OBD-compliant ECUs (i.e., emissions-related systems), a few specific values are either reserved or have standardized meanings. Here’s a breakdown of how this record number is interpreted:

Reserved and Defined Ranges for DTCExtDataRecordNumber

• 0x00 → Reserved by ISO/SAE for potential future use in On-Board Diagnostics (OBD).
• 0x01 – 0x8F → Used to request vehicle manufacturer-specific extended data records. These are typically custom-defined by the OEM and may vary from one vehicle platform to another.
• 0x90 – 0xEF → Reserved for accessing legislated OBD extended data. These data records are defined by emissions regulations and are common across compliant systems.
• 0xF0 – 0xFD → Reserved by ISO/SAE for future enhancements, specifically for reporting grouped data records in a single response.
• 0xFE → Instructs the ECU to return all legislated OBD extended data records in one message, assuming the ECU supports such combined reporting.
• 0xFF → Requests the ECU to provide all available DTC extended data records, including both OEM-specific and legislated OBD records, in a single response.

This structured approach to record numbering enables diagnostic tools to precisely target specific data, whether for manufacturer-specific analysis or regulatory compliance checks. Understanding these ranges ensures compatibility across tools, ECUs, and vehicle platforms while allowing for future extensibility of the protocol.

Syntax of 0x19 SID Positive Response Message

Response Message Definition – Sub-Function = Report DTC Extended Data by Record Number

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
#2	report Type =                  Report DTC Ext Data Record By Record Number	0x16
#3	DTC Ext Data Record Number	0x00 – 0xEF
#4 #5 #6 #7	DTC And Status Record[]#1 =                                                     [ DTC High Byte                                                       DTC Middle Byte                                                       DTC Low Byte                                                       Status Of DTC ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
#8 : #8+(p-1)	DTC Ext Data Record[]#1= [                                            extendedData#1 byte#1                                                            :                                            extendedData#1 byte#p ]	0x00 – 0xFF : 0x00 – 0xFF
:	:	:
#t #t+1 #t+2 #t+3	DTC And Status Record[]#x =                                                     [ DTC High Byte                                                       DTC Middle Byte                                                       DTC Low Byte                                                       Status Of DTC ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
#t+4 : #t+4+(p-1)	DTC Ext Data Record[]#x =   [                                          extendedData#x byte#1                                                              :                                               extendedData#x byte#p ]	0x00 – 0xFF : 0x00 – 0xFF
C1: The DTCAndStatusRecord and the DTCExtDataRecord parameters are only present if at least one DTCExtDataRecord is available to be reported. C2: The DTCAndStatusRecord and the DTCExtDataRecord parameters are only present if more than one DTCExtDataRecord is available to be reported. NOTE: It is up to the implementer to specify that a response will not exceed a length that it is possible by the used diagnostic communication.

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

DTCExtDataRecordNumber

Refers either to the echoed value provided by the client in a reportDTCExtDataRecordByDTCNumber or reportDTCExtDataRecordByRecordNumber request, or to the actual identifier of a stored DTC Extended Data record within the ECU.

DTCExtDataRecord

A DTCExtDataRecord is a server-defined data block that holds additional diagnostic information related to a specific DTC. This extended data may include various parameters or status details that were captured by the ECU at the time the fault was detected.

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

Below are the Examples of Report DTC Extended Data by Record Number (0x16) in UDS Protocol 0x19 Service:

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

Read DTC Information, Sub-function = Report DTC Ext Data Record By Record Number, 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 DTC Ext Data Record By Record Number,                  Suppress Pos Rsp Msg Indication Bit = FALSE	0x16
#3	DTC Ext Data Record Number	0x05

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

Read DTC Information, Sub-function = Report DTC Ext Data Record By Record Number, 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 DTC Ext Data Record By Record Number	0x16
#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 ] DTC And Status Record [ status Of DTC ]	0x12 0x34 0x56 0x24
#7	DTC Ext Data Record Number	0x05
#8	DTC Ext Data Record [ byte#1 ]	0x17
#9	DTC And Status Record [ DTC High Byte ]	0x23
#10	DTC And Status Record [ DTC Middle Byte ]	0x45
#11	DTC And Status Record [ DTC Low Byte ]	0x61
#12	DTC And Status Record [ Status Of DTC ]	0x24
#13	DTC Ext Data Record Number	0x05
#14	DTC Ext Data Record [ byte#1 ]	0x79

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

Read DTC Information, Sub-function = Report DTC Ext Data Record By Record Number, 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 16
Positive Response: Server --> Client
14 59 16 12 34 56 24 05 17 23 45 61 24 05 79
// Example for Negative Response for SID-0x19
Request: Client --> Server
03 19 16
Negative Response: Server --> Client
03 7F 19 13

UDS Protocol Example: Using “Report DTC Extended Data by Record Number” (0x16) Over CAN

In the Unified Diagnostic Services (UDS) protocol, Service ID 0x19 is used for accessing diagnostic trouble codes (DTCs) and their related information. One of its subfunctions, 0x16 (Report DTC Extended Data by Record Number), allows a diagnostic tester (client) to request specific extended data records stored on the ECU (server) for known DTCs.

Let’s walk through a real-world example of how this is implemented on the CAN bus using DoCAN (Diagnostics over CAN).

✅ Example 1: Positive Response for SID 0x19

Request Frame (Client → Server)

02 19 16

• 02 → Number of bytes to follow (2 bytes of actual data)
• 19 → Service ID (0x19: Read DTC Information)
• 16 → Subfunction (0x16: Report DTC Extended Data by Record Number)

The client is requesting the ECU to return extended data records that match a predefined record number.

Positive Response Frame (Server → Client)

14 59 16 12 34 56 24 05 17 23 45 61 24 05 79

• 14 → Total number of bytes in the response (14 bytes)
• 59 → Positive response ID for service 0x19 (0x40 + 0x19 = 0x59)
• 16 → Echoed subfunction (Report DTC Ext Data by Record Number)
• 12 34 56 → Example DTC (3-byte Diagnostic Trouble Code)
• 24 05 → DTC status information
• 17 23 45 61 24 05 79 → DTC Extended Data Record for that DTC, defined by the OEM

What’s happening?

• The server has matched the request and returned the extended data for DTC 0x123456.
• The extended data bytes contain parameter values recorded when the fault occurred this might include sensor readings, counters, or timestamp info depending on OEM configuration.

❌ Example 2: Negative Response for SID 0x19

Request Frame (Client → Server)

03 19 16

• 03 → Number of bytes to follow (3 bytes)
• 19 → Service ID (Read DTC Information)
• 16 → Subfunction (Report DTC Extended Data by Record Number)

Let’s assume here the client included an invalid or unsupported DTCExtDataRecordNumber.

Negative Response Frame (Server → Client)

03 7F 19 13

• 03 → Number of bytes in the response
• 7F → Negative response indicator
• 19 → Echoed service ID (original requested SID)
• 13 → Negative Response Code (NRC 0x13: Invalid Format)

What’s happening?

• The server is rejecting the request due to a malformed or unsupported DTCExtDataRecordNumber or request length.
• This helps the client understand the error and correct its message.

Summary from the Example:

Component	Purpose
0x19	UDS Service ID for DTC information
0x16	Subfunction to retrieve extended data by record
0x59	Positive response ID (0x40 + 0x19)
0x7F	Negative response indicator
0x13	Negative Response Code for Invalid Format

This communication pattern is essential for developers and testers who:

• Verify DTC logging and behavior in ECUs
• Use HIL test benches or automated diagnostic tools
• Develop diagnostic testers and need to interact with ECUs via UDS over CAN