UDS 0x19 Service: Report User Defined Memory DTC Extended Data Record by DTC Number Explained

Hello, fellow automotive diagnostics enthusiasts! Report User Defined Memory DTC Extended Data Record By DTC Number (0x19) in UDS. In this blog post, we’ll explore a powerful f

eature of the UDS (Unified Diagnostic Services) protocol: Service 0x19, Sub-function 0x19 used to report user-defined memory DTC extended data by DTC number. This sub-function allows diagnostic tools to request detailed information about faults stored in the ECU, including extended diagnostic data. Understanding this feature is essential for engineers working on ECU development, testing, or vehicle diagnostics. We’ll break down how this service works, when to use it, and how request/response messages are structured over CAN. With practical examples and explanations, you’ll gain valuable insights into this advanced UDS functionality. By the end of this post, you’ll be able to analyze or implement this service effectively in your diagnostic projects. Let’s dive in!

Introduction to Report User Defined Memory DTC Extended Data Record by DTC Number (Sub-function 0x19) in UDS 0x19 Service

Hello, diagnostics professionals and automotive engineers! In this article, we’ll explore a vital diagnostic feature in the UDS protocol: Service 0x19, Sub-function 0x19, also known as Report User Defined Memory DTC Extended Data Record by DTC Number. This service allows a diagnostic tester to request detailed, user-defined extended data associated with a specific DTC (Diagnostic Trouble Code) stored in an ECU. It’s particularly useful in advanced fault analysis, where extended data can reveal conditions during or around the time of failure. We’ll explain how this sub-function works, how the request and response messages are structured, and typical use cases. Whether you’re working in ECU development, HIL testing, or vehicle diagnostics, mastering this service enhances your diagnostic capabilities. Let’s dive into the UDS 0x19 service and uncover what extended data can tell us!

What Is the “Report User Defined Memory DTC Extended Data Record by DTC Number” (Sub-function 0x19) in UDS 0x19 Service?

In the UDS protocol (Unified Diagnostic Services, ISO 14229), Service ID 0x19 is known as “ReadDTCInformation.” It provides various sub-functions to retrieve Diagnostic Trouble Code (DTC) related data from an ECU (Electronic Control Unit). One of these sub-functions is Sub-function 0x19, which is used to report user-defined memory DTC extended data records by DTC number.

Purpose of Sub-function 0x19

Sub-function 0x19 enables a diagnostic tool (client) to request extended diagnostic data associated with a specific DTC that is stored in a user-defined memory region of the ECU. This extended data can contain additional contextual information recorded during or around the time of a fault.

Where It’s Used?

• This sub-function is used in scenarios such as:
  • Advanced ECU diagnostics
  • Custom or OEM-specific memory partitioning
  • Detailed debugging of rare or complex faults
  • Validation and testing (e.g., HIL setups)

Unlike standard memory regions used for DTC storage, user-defined memory allows OEMs to customize how and where extended data is logged, stored, and retrieved.

Key Takeaways:

• Enables OEM-specific customization of DTC data reporting.
• Improves fault traceability with rich, contextual extended data.
• Supports advanced diagnostics in both field service tools and test benches.

When implementing this sub-function, always ensure the DTC number requested matches an entry that has user-defined extended data available. Otherwise, a negative response will be issued by the ECU.

Why do we need “Report User Defined Memory DTC Extended Data Record by DTC Number” (Sub-function 0x19) in UDS 0x19 Service?

The Report User Defined Memory DTC Extended Data Record by DTC Number (Sub-function 0x19 in UDS Service 0x19) exists to provide flexibility, customization, and advanced diagnostic insight into vehicle faults that go beyond standard DTC reporting. Here’s why this sub-function is important:

1. Access to Customized Diagnostic Data

Standard DTCs often contain limited predefined information (e.g., fault code, status, occurrence count). However, many OEMs want to store additional, application-specific data like:

• Sensor values during the fault
• Engine temperature or speed
• System voltages or communication state
  This extra information is stored in a user-defined memory area, and this sub-function retrieves it.

2. Advanced Fault Analysis

During debugging or warranty claim investigation, engineers need more than just the DTC. The extended data provides context that helps answer:

• What exactly was happening when the fault occurred?
• Was this fault associated with an overload, communication timeout, or sensor glitch?
  This makes root cause analysis much easier.

3. Support for OEM-Specific Requirements

Automakers often have unique requirements for diagnostics and memory layout. This sub-function allows them to:

• Define their own data format
• Log fault-related data in custom memory regions
• Use it during vehicle servicing, field diagnostics, or testing

4. Improved Testing & Validation

In HIL (Hardware-in-the-Loop) or SIL (Software-in-the-Loop) environments, having access to rich extended data helps:

• Validate fault injection logic
• Trace ECU behavior during simulated faults
• Log data for automated test reports

5. Separation from Standard Memory

Using user-defined memory allows the ECU to:

• Avoid conflicts with standard OBD or emission-critical memory
• Maintain separate zones for development, validation, or post-production data

6. Enhanced Service Tool Capabilities

Advanced diagnostic tools used in workshops or OEM service centers can leverage this sub-function to:

• Display detailed fault context to technicians
• Export extended data for reports or remote analysis
• Offer better support for brand-specific troubleshooting procedures

7. Post-Production and Fleet Monitoring

In fleet diagnostics or connected vehicle platforms, extended DTC data helps in:

• Monitoring real-world fault conditions
• Performing trend analysis across vehicles
• Supporting remote diagnostics with richer context from the field

8. Compliance with Proprietary Diagnostic Standards

While UDS is standardized (ISO 14229), many OEMs extend it with proprietary features. This sub-function allows:

• Implementation of company-specific fault tracing strategies
• Alignment with internal testing protocols or development tools
• Compliance with internal quality systems without breaking UDS compliance

“Report User Defined Memory DTC Extended Data Record by DTC Number” (Sub-function 0x19) in UDS 0x19 Service

In the world of UDS diagnostics, the sub-function 0x19 under Service 0x19 serves a critical role in retrieving extended diagnostic information tied to specific DTCs stored in user-defined memory regions. This functionality allows diagnostic clients to request custom diagnostic data records associated with a particular DTC, providing far more insight than standard DTC data.

To initiate this request, the client sends a diagnostic message that includes the DTCMaskRecord (which contains the full 3-byte DTC number), a UserDefMemoryIdentifier, and a DTCExtDataRecordNumber. The ECU (server) will search its internal DTC memory for a match based on the DTC number and the memory identifier provided.

If a valid match is found, the ECU returns a predefined DTCExtendedData record corresponding to the specified DTC and data record number. This extended data can include critical runtime values, environmental conditions, or custom metrics captured at the time the fault occurred. The format and content of the extended data are entirely defined by the vehicle manufacturer, offering flexibility to design application-specific diagnostics.

Handling Multiple Extended Data Records

A single DTC may have multiple types of extended data stored under different DTCExtDataRecordNumbers, enabling structured diagnostic reporting (e.g., one record for sensor snapshots, another for fault counters, etc.). Typically, the server sends one record per response. However, if the client sets the DTCExtDataRecordNumber to 0xFE or 0xFF, the ECU is instructed to return all available extended data records associated with the given DTC from the user-defined memory in a single response.

Negative Response Conditions

The ECU will respond with a negative response if:

• The specified DTCMaskRecord, DTCExtDataRecordNumber, or UserDefMemoryIdentifier is invalid or unsupported.
• The request refers to a valid record, but no extended data exists for it (e.g., due to memory overflow or data being deleted).

It is important to differentiate between these scenarios. In the first case, the server truly cannot process the request. In the second, the request is valid, but no data is currently available to return.

Behavior When No Extended Data Exists

If the DTC is valid but no associated extended data is found (for instance, the memory was cleared or data was overwritten), the server will send a positive response containing only the DTC and its status, effectively confirming the DTC’s presence without providing additional detail.

OEM Responsibility

It is up to the vehicle manufacturer to define:

• The structure and content of the extended data records
• The format of user-defined memory
• The policies for storing, retaining, or deleting DTC extended data from these memory areas

This design ensures that the implementation remains flexible and adaptable to different platforms, vehicle architectures, and diagnostic strategies.

This sub-function plays a pivotal role in deep diagnostics especially for OEMs and test engineers who require granular fault data during development, testing, or in-service diagnostics.

Real-World Example:

Suppose a DTC is triggered due to an over-voltage condition on a battery sensor. While the standard DTC tells you “over-voltage,” the extended data retrieved using Sub-function 0x19 could tell you:

• Battery voltage = 16.2V
• Alternator load = 95%
• Engine RPM = 3800
• Last CAN message delay = 200ms
  This detailed snapshot helps pinpoint the actual cause and speed up diagnosis.

We need Sub-function 0x19 in UDS 0x19 Service to unlock a deeper level of diagnostics, especially when dealing with complex ECUs, custom applications, or non-standard fault handling. It empowers OEMs, testers, and developers to access richer, more meaningful diagnostic data tailored to their specific needs.

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

Request Message Definition – Sub-function = Report User Defined Memory DTC Extended Data Record by DTC Number

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type = Report User Defined Memory DTC Extended Data Record By DTC Number ]	0x19
#3 #4 #5	DTCMaskRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
#6	DTC Extended Data Record Number	0x00 – 0xFF
#7	Memory Selection	0x00 – 0xFF

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

DTC Mask Record:

The DTCMaskRecord is a 3-byte value composed of three parts: DTCHighByte, DTCMiddleByte, and DTCLowByte. Together, these bytes uniquely identify a specific Diagnostic Trouble Code (DTC) supported by the diagnostic server.

This 3-byte DTC number can be interpreted using several different coding schemes, depending on the diagnostic standard or manufacturer preferences. The main formats include:

• ISO 15031-6 (SAE J2012-DA Format 00): The DTC is decoded following the ISO 15031-6 standard. This format is indicated by the identifier: DTCFormatIdentifier = SAE_J2012-DA_DTCFormat_00.
• ISO 14229-1 (UDS Standard): This standard does not define a specific decoding method, allowing vehicle manufacturers to implement their own custom decoding logic. This is identified by: DTCFormatIdentifier = ISO_14229-1_DTCFormat.
• SAE J1939-73: Used primarily in heavy-duty vehicles, this format follows the SAE J1939-73 specification and is identified by:
  DTCFormatIdentifier = SAE_J1939-73_DTCFormat.
• ISO 11992-4: Applied mainly in commercial vehicle networks, this format is based on ISO 11992-4 and identified by:
  DTCFormatIdentifier = ISO_11992-4_DTCFormat.
• ISO 27145-2 (WWH-OBD Format): This format complies with the ISO 27145-2 specification, commonly used in heavy-duty On-Board Diagnostics, and is identified by: DTCFormatIdentifier = SAE_J2012-DA_WWH-OBD_DTCFormat.

Each of these formats defines how the three bytes in the DTCMaskRecord are decoded to represent meaningful fault information. This flexibility allows OEMs to support a wide variety of vehicle architectures and diagnostic requirements while maintaining a consistent method to uniquely identify trouble codes.

DTC Extended Data Record Number:

The DTCExtDataRecordNumber is a 1-byte value defined by the client that specifies which particular DTCExtendedData record is being requested for a given DTCMaskRecord. This parameter is used in the UDS sub-functions:

• reportDTCExtDataRecordByDTCNumber
• reportDTCExtDataRecordByRecordNumber.

For emissions-related servers, such as OBD-compliant ECUs, the value 0x00 is reserved for future OBD use.

Reserved Ranges of DTCExtDataRecordNumber

The DTCExtDataRecordNumber values are divided into specific ranges, each with its own meaning:

• 0x00: Reserved by ISO/SAE for future use.
• 0x01 to 0x8F: Requests vehicle manufacturer-specific stored DTCExtendedData records.
• 0x90 to 0xEF: Requests legislated OBD stored DTCExtendedData records.
• 0xF0 to 0xFD: Reserved by ISO/SAE for future use, specifically for reporting groups of records in a single response.
• 0xFE: Requests the server to return all legislated OBD DTCExtendedData records in a single response message.
• 0xFF: Requests the server to return all stored DTCExtendedData records (both manufacturer-specific and OBD-related) in a single response message.

This structured range allows flexible querying of extended diagnostic data while maintaining compatibility with both manufacturer-specific and regulated OBD requirements.

Memory Selection: This parameter is used to identify and access the specific user-defined DTC memory from which the DTCs are to be retrieved.

Syntax of 0x19 SID Positive Response Message

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

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
#2	report Type = Report User Defined Memory DTC Extended Data Record by DTC Number	0x19
#3	Memory Selection	0x00 – 0xFF
#4 #5 #6 #7	DTC And Status Record[] = [ DTC High Byte DTC Middle Byte DTC Low Byte Status of DTC ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
#8	DTCExtDataRecordNumber#1	0x00 – 0xFE
9 : 9+(p-1)	DTCExtDataRecord[]#1 = [ extendedData#1 byte#1 : extendedData#1 byte#p ]	0x00 – 0xFF : 0x00 – 0xFF
:	:	:
t+1 : t+1+(q-1)	DTCExtDataRecord[]#x = [ extendedData#x byte#1 : extendedData#x byte#q ]	0x00 – 0xFF : 0x00 – 0xFF
C1: The DTCExtDataRecordNumber and the extendedData within the DTCExtDataRecord parameter are included only when at least one DTCExtendedData record is available for reporting. C2: The DTCExtDataRecordNumber and the extendedData in the DTCExtDataRecord parameter are present only if the client requests all records (by setting DTCExtDataRecordNumber to 0xFE or 0xFF) and more than one record is available to be reported.

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

MemorySelection: This parameter echoes the MemorySelection parameter received in 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).

Formats Supported:

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

DTCExtDataRecordNumber: This parameter represents either the echoed DTCExtDataRecordNumber sent by the client in the reportDTCExtDataRecordByDTCNumber or reportDTCExtDataRecordByRecordNumber request, or the actual DTCExtDataRecordNumber associated with a stored DTCExtendedData record.

DTCExtDataRecord: The DTCExtDataRecord is a server-specific data block that may include extended status details related to a Diagnostic Trouble Code (DTC). It contains DTC parameter values that are identified and retrieved at the time of the request.

Syntax of 0x19 SID Negative Response Message

Response Message Definition – Sub-Function = Report User Defined Memory DTC Extended 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 User Defined Memory DTC Extended Data Record by DTC Number’ (0x19 Sub-function) in UDS 0x19 Service

Below are the Examples of ‘Report User Defined Memory DTC Extended Data Record by DTC Number’ (0x19 Sub-function) in UDS 0x19 Service:

// 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 19
Positive Response: Server --> Client
14 59 19 12 34 56 24 05 17 23 45 61 24 05 79
// Example for Negative Response for SID-0x19
Request: Client --> Server
03 19 19
Negative Response: Server --> Client
03 7F 19 13

Understanding UDS Commands over CAN for Service 0x19 (SID 0x19) with DoCAN

In the Unified Diagnostic Services (UDS) protocol, communication between a diagnostic client (tester) and a server (ECU) is performed by exchanging messages over the CAN bus. Here, we look at examples of how the client requests data and how the server responds for Service ID (SID) 0x19, which is related to vehicle diagnostics and snapshot data retrieval.

Example 1: Positive Response for SID 0x19

Request (Client → Server):

02 19 19

• 02 — Length of the data field (2 bytes follow)
• 19 — Service Identifier (SID) for “Read DTC Information”
• 19 — Sub-function identifier requesting a specific operation within SID 0x19 (in this case, possibly Report User Defined Memory DTC Extended Data Record by DTC Number)

Response (Server → Client):

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

• 14 — Length of the response data (20 bytes follow)
• 59 — Positive response SID (SID + 0x40, i.e., 0x19 + 0x40 = 0x59) indicating a successful operation
• 19 — Echo of the sub-function requested
• The rest (12 34 56 24 05 17 23 45 61 24 05 79) represents the requested snapshot data or extended DTC information returned by the server.

This positive response confirms that the server successfully processed the request and is returning the requested diagnostic data.

Example 2: Negative Response for SID 0x19

Request (Client → Server):

03 19 19

• 03 — Length of the data field (3 bytes follow)
• 19 — SID for “Read DTC Information”
• 19 — Sub-function identifier (same as above)

Response (Server → Client):

03 7F 19 13

• 03 — Length of the response data (3 bytes follow)
• 7F — Negative response code indicator
• 19 — Echo of the requested SID that caused the error
• 13 — Negative Response Code (NRC), where 0x13 means “IncorrectMessageLengthOrInvalidFormat”

This negative response indicates that the request sent by the client was not processed successfully, likely due to incorrect message length or invalid format.

Key Takeaways:

• Service Identifier (SID) 0x19 is used for diagnostic trouble code (DTC) and snapshot data requests.
• Positive responses start with SID + 0x40 (here, 0x59) and include the requested data.
• Negative responses start with 0x7F followed by the original SID and a Negative Response Code explaining the failure reason.
• Proper message formatting (correct byte lengths, valid parameters) is essential to avoid negative responses.