UDS 0x19 Service: Report User Defined Memory DTC Snapshot Record by DTC Number (0x18 Sub-function)

Hello, fellow automotive diagnostics enthusiasts! Report User Defined Memory DTC Snapshot Record By DTC Number (0x18) in UDS. In this blog post, I will walk you through a critical sub

-function of the UDS (Unified Diagnostic Services) protocol: 0x18 under Service 0x19. This sub-function, known as Report User Defined Memory DTC Snapshot Record by DTC Number, plays a key role in accessing detailed diagnostic snapshot data from ECUs. Understanding this service is essential for anyone involved in advanced vehicle diagnostics, ECU development, or testing. I’ll explain what this sub-function does, how it fits into the UDS framework, and when to use it. We’ll also look at request/response message structures and practical use cases. By the end of this article, you’ll gain valuable insights into implementing or analyzing this UDS feature effectively. Let’s dive into the details!

Introduction to UDS 0x19 Service: Report User Defined Memory DTC Snapshot Record by DTC Number (0x18 Sub-function)

The Unified Diagnostic Services (UDS) protocol is a key standard used in automotive diagnostics. Among its many services, Service 0x19 is designed to handle Diagnostic Trouble Code (DTC) information. In this post, we focus on the 0x18 sub-function, which reports user-defined memory DTC snapshot records by DTC number. This function is crucial for accessing ECU-captured data linked to specific fault codes. Understanding how to use this service helps in root-cause analysis and advanced diagnostic reporting. We’ll explore the purpose, structure, and message format of this sub-function in detail. By the end, you’ll know how to implement and interpret this service effectively in UDS-based systems.

What Is the ‘Report User Defined Memory DTC Snapshot Record by DTC Number’ (0x18 Sub-function) in UDS 0x19 Service?

In the Unified Diagnostic Services (UDS) protocol, defined in the ISO 14229 standard, Service 0x19 is used to access information related to Diagnostic Trouble Codes (DTCs). These codes are essential for identifying and diagnosing faults in Electronic Control Units (ECUs) of vehicles.

Among the various sub-functions of Service 0x19, the 0x18 sub-function is titled:

Report User Defined Memory DTC Snapshot Record by DTC Number (0x18 Sub-function)

This sub-function allows a diagnostic tester (client) to request snapshot records stored in user-defined memory areas for a specific DTC. These snapshot records contain additional context or sensor data captured by the ECU at the time the DTC was set, providing engineers or service technicians with valuable information for debugging and fault analysis.

Purpose of Sub-function 0x18

While regular snapshot records are stored in standard memory, some OEMs define custom memory locations for storing enhanced or proprietary snapshot data. The 0x18 sub-function is used to retrieve that user-defined data, which is typically used in internal development, testing, or advanced service tools.

Request Format (Client to Server):

The basic structure of the request message includes:

Byte(s)	Field Description
0	Service ID = 0x19
1	Sub-function = 0x18
2–4	DTC Number (3 bytes, e.g., 0x01 0x23 0x45)
5	Memory Selection (e.g., memory ID or index)

Example Request: 19 18 01 23 45 01
(Asks for user-defined snapshot for DTC 0x012345 from memory index 0x01)

Positive Response Format (Server to Client):

Byte(s)	Field Description
0	Positive Response SID = 0x59
1	Sub-function echoed = 0x18
2–4	DTC Number
5	Memory selection echoed
6–n	Snapshot record data from user-defined memory

The exact format and length of the snapshot data are OEM-specific and must be interpreted according to the supplier’s documentation or implementation.

Negative Response:

If the requested data is not available or the DTC is invalid or not supported in user-defined memory, the ECU may return a negative response, such as:

• 0x13 – Invalid Format
• 0x31 – Request Out of Range
• 0x72 – General Programming Failure (if memory is inaccessible)

Why do we need ‘Report User Defined Memory DTC Snapshot Record by DTC Number’ (0x18 Sub-function) in UDS 0x19 Service?

The 0x18 sub-function in UDS Service 0x19 Report User Defined Memory DTC Snapshot Record by DTC Number is necessary for enabling advanced, customized diagnostic capabilities that go beyond the standard snapshot reporting. Here’s why it’s needed:

1. Enhanced Diagnostic Insight

Standard DTC snapshot records (via sub-functions like 0x04 or 0x06) typically provide limited data, such as vehicle speed or engine RPM at the time of the fault. However, some OEMs and Tier-1 suppliers need more detailed or specialized context, such as:

• Custom sensor readings
• Internal ECU variable states
• Communication bus statuses (CAN/LIN signal values)
• Proprietary control system data

Using 0x18, this extended snapshot data can be stored and retrieved from user-defined memory.

2. OEM-Specific Customization

Not all vehicle manufacturers have the same diagnostic requirements. The 0x18 sub-function allows them to define their own memory regions and data layouts for DTC snapshots. This gives them flexibility to:

• Store unique diagnostic values
• Tailor debugging tools to specific control strategies
• Maintain compatibility with internal development tools

3. Advanced Testing and Debugging

During ECU development or vehicle testing, engineers often need more than just a DTC code. They want to know what the ECU “saw” internally when a fault occurred. With 0x18, they can:

• Log rich diagnostic data
• Analyze real-time internal conditions
• Reproduce or simulate faults using historical ECU data

4. Support for Post-Production Tools

In post-production service environments (e.g., dealerships), advanced service tools can use this sub-function to access OEM-specific memory areas, enabling:

• Deeper fault investigation
• Faster root cause analysis
• Reduced repair time

5. Segregation of Data for Security or Performance

Sometimes, snapshot records in user-defined memory are separated from normal memory to:

• Protect sensitive or proprietary data
• Reduce processing load on critical memory
• Organize snapshot storage efficiently

6. Supports Conditional Logging for Specific Faults

With user-defined memory, the ECU can be programmed to log snapshot data conditionally, only for critical or rare faults that require deeper investigation. This helps conserve memory and allows for focused analysis of:

• Intermittent issues
• Safety-critical events
• Calibration-specific behavior

The 0x18 sub-function enables retrieval of these selectively logged records by DTC number, making diagnostics more targeted and efficient.

7. Enables Structured Memory Management and Modular Design

Modern ECUs often follow a modular software architecture, with different modules responsible for specific subsystems (e.g., powertrain, body, communication). Each module can log snapshot records in separate user-defined memory blocks.
The 0x18 sub-function facilitates structured access to these blocks by allowing retrieval based on DTC number and memory identifier, ensuring modularity and maintainability of the diagnostic system.

‘Report User Defined Memory DTC Snapshot Record by DTC Number’ (0x18 Sub-function) in UDS 0x19 Service

In modern automotive diagnostic systems, it’s often necessary to capture detailed contextual data when a Diagnostic Trouble Code (DTC) is set. The UDS protocol (ISO 14229) addresses this through several sub-functions, and one of the most flexible and OEM-customizable options is sub-function 0x18 of Service 0x19. This service is known as “Report User Defined Memory DTC Snapshot Record by DTC Number.”

This sub-function enables a diagnostic client (such as a scan tool or ECU testing interface) to retrieve specific snapshot records associated with a user-defined DTC mask and stored in dedicated memory regions. To do this, the client sends a request specifying:

• The DTC number (high, middle, and low bytes),
• A snapshot record number, and
• A user-defined memory identifier.

The ECU (server) will then scan its internal DTC list for a match with the provided DTC mask. If the parameters are valid and a snapshot exists, the server responds with the corresponding DTC status and one or more snapshot records from the defined memory space.

Note: The DTCSnapshotRecordNumber is distinct from the DTCStoredDataRecordNumber each has its own address space and use case.

How It Works?

• The snapshot record number tells the server which occurrence of the fault to retrieve (e.g., first or most recent).
• If the record number is not equal to 0xFF, only a single snapshot record will be returned in the response.
• If the client sets the record number to 0xFF, the ECU will return all available snapshot records for the specified DTC and memory location.
• Each snapshot includes a dataIdentifier followed by associated data bytes, allowing multiple snapshot types to be stored for the same DTC.
• The number of dataIdentifiers present is also included, making it easier for the diagnostic tool to parse the response correctly.

These snapshots might include critical context such as battery voltage (B+), engine RPM, timestamps, and other internal ECU variables useful for fault analysis.

Behavior, Constraints, and Edge Cases:

• If the DTC or snapshot parameters are invalid or unsupported, the ECU sends a negative response.
• If the parameters are valid but no snapshot data is available (i.e., the fault never occurred), the ECU responds positively but includes only the DTC number and its current status no snapshot data.
• The format and structure of user-defined snapshot memory is entirely OEM-dependent, allowing flexibility for proprietary implementations.
• Snapshots may be cleared by manufacturer-defined triggers, such as a routine control request or a reset operation.
• In the event of memory overflow, it’s the manufacturer’s responsibility to define a strategy for handling the loss or overwriting of snapshot records.

Practical Use Case:

For developers, testers, and advanced diagnostic tool designers, this sub-function is incredibly powerful. It enables precise access to tailored diagnostic data, supporting robust debugging during ECU development or post-production analysis.

By leveraging user-defined memory and structured snapshot records, OEMs can achieve a more intelligent, traceable, and modular diagnostic environment critical for managing the growing complexity of modern automotive electronics.

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

Request Message Definition – Sub-function = Report User Defined Memory DTC Snapshot 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 Snapshot Record By DTC Number]	0x18
#3 #4 #5	DTCMaskRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
#6	DTC Status Mask	0x00 – 0xFF
#7	Memory Selection	0x00 – 0xFF

SBFID (0x18) 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 Status Mask:

The DTCStatusMask is a single byte containing eight (8) status bits that represent different DTC conditions.

In a request message, this mask allows the client to filter and request DTCs whose status matches the mask. A DTC’s status is considered a match if any of its status bits set to ‘1’ also correspond to a ‘1’ bit in the DTCStatusMask. In other words, when the DTC’s actual status is bitwise ANDed with the DTCStatusMask, a non-zero result indicates a match.

If the client includes bits in the mask that the server does not support, the server will ignore those bits and only evaluate the supported ones when processing the DTC information.

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 Snapshot 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 Snapshot Record By DTC Number	0x18
#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	DTC Snapshot Record Number#1	0x00 – 0xFF
#9	DTC Snapshot Record Number Of Identifiers#1	0x00 – 0xFF
#10 #11 #12 : # 12+(p-1) : #r-(m-1)-2 #r-(m-1)-1 #r-(m-1) : #r	DTCSnapshotRecord[]#1 = [ dataIdentifier#1 byte#1 (MSB) dataIdentifier#1 byte#2 (LSB) snapshotData#1 byte#1 : snapshotData#1 byte#p : dataIdentifier#w byte#1 (MSB) dataIdentifier#w byte#2 (LSB) snapshotData#w byte#1 : snapshotData#w byte#m ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF : 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF
:	:	:
#t	DTC Snapshot Record Number#x	0x00 – 0xFF
#t+1	DTC Snapshot Record Number Of Identifiers#x	0x00 – 0xFF
#t+2 #t+3 #t+5  : #t+5+(p-1)  : #n-(u-1)-2 #n-(u-1)-1 #n-(u-1)  : #n	DTCSnapshotRecord[]#x = [ dataIdentifier#1 byte#1 (MSB) dataIdentifier#1 byte#2 (LSB) snapshotData#1 byte#1 : snapshotData#1 byte#p : dataIdentifier#w byte#1 (MSB) dataIdentifier#w byte#2 (LSB) snapshotData#w byte#1 : snapshotData#w byte#u	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF  : 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF  : 0x00 – 0xFF
C1: The DTCSnapshotRecordNumber and the first dataIdentifier/snapshotData combination in the DTCSnapshotRecord parameter is only present if at least one DTCSnapshot record is available to be reported. C2/C4 There are multiple dataIdentifier/snapshotData combinations allowed to be present in a single DTCSnapshotRecord. This can e.g. be the case for the situation where a single dataIdentifier only references an integral part of data. When the dataIdentifier references a block of data then a single dataIdentifier/snapshotData combination can be used. C3: The DTCSnapshotRecordNumber and the first dataIdentifier/snapshotData combination in the DTCSnapshotRecord parameter is only present if all records are requested to be reported (DTCSnapshotRecordNumber set to 0xFF in the request) and more than one record is available to be reported.

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

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

DTCSnapshotRecordNumber: This parameter is either an echo of the DTCSnapshotRecordNumber specified by the client in the reportDTCSnapshotRecordByDTCNumber request, or it represents the actual DTCSnapshotRecordNumber of a stored DTC snapshot record.

DTCSnapshotRecordNumberOfIdentifiers: This single-byte parameter indicates the number of data identifiers present in the immediately following DTC Snapshot Record. A value of 0x00 signifies that the number of data identifiers is undefined typically used when the snapshot record contains more than 255 data identifiers.

DTCSnapshotRecord: The DTCSnapshotRecord captures a snapshot of data values recorded at the moment the system malfunction occurred.

Syntax of 0x19 SID Negative Response Message

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

Here are the Examples of ‘Report User Defined Memory DTC Snapshot Record by DTC Number’ (0x18 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 18
Positive Response: Server --> Client
14 59 18 12 34 56 24 05 17 23 45 61 24 05 79
// Example for Negative Response for SID-0x19
Request: Client --> Server
03 19 18
Negative Response: Server --> Client
03 7F 19 13

UDS over CAN (DoCAN) – Example: Service ID 0x19 (ReadDTCInformation)

The UDS protocol (ISO 14229) is widely used for vehicle diagnostics. When transmitted over CAN (ISO 15765-4), it’s referred to as DoCAN. Here’s a simple explanation of how UDS messages are structured and interpreted when reading DTC (Diagnostic Trouble Code) information.

✅ Positive Response Example – SID 0x19

Request from Client to Server:

02 19 18

• 02 – PCI byte (Protocol Control Information), indicating 2 bytes of actual data.
• 19 – Service ID for ReadDTCInformation.
• 18 – Sub-function (in this case, 0x18 corresponds to “Report DTC Snapshot Record by DTC Number”).

Response from Server to Client:

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

• 14 – PCI byte indicating 14 bytes of data follow (this can vary based on content).
• 59 – Positive response SID, which is 0x40 added to the request SID (0x19 + 0x40 = 0x59).
• 18 – Echoed sub-function (0x18).
• 12 34 56 – DTC Number (3 bytes).
• The remaining bytes contain snapshot record data, including time stamps, sensor values, etc. Each OEM may define this content differently.

❌ Negative Response Example – SID 0x19

Request from Client to Server:

03 19 18

• 03 – PCI byte indicating 3 bytes of data.
• 19 – Requested Service ID.
• 18 – Sub-function.

Response from Server to Client:

03 7F 19 13

• 03 – PCI byte for 3 bytes of data.
• 7F – Indicates a Negative Response.
• 19 – Echo of the requested SID.
• 13 – Negative Response Code (NRC). 0x13 means “Incorrect Message Length or Invalid Format”.

Summary of Key UDS Elements

Byte	Meaning
19	SID for ReadDTCInformation
18	Sub-function: ReportSnapshotByDTC
59	Positive response (0x19 + 0x40)
7F	Indicates negative response
13	NRC: Invalid message length

Tips for Implementation

• Always validate the message length and format before processing.
• Use the NRC to debug communication issues efficiently.
• Snapshot data is typically customized per OEM – understand your target ECU’s specifications.