UDS Protocol 0x19 Service: Report DTC Stored Data By Record Number (0x05) Explained

Hello, fellow automotive diagnostics enthusiasts! In this blog post, Report DTC Stored Data by Record Number 0x05

"noreferrer noopener">UDS. I’ll introduce you to one of the essential features of the UDS protocol Service 0x19, Sub-function 0x05, known as Report DTC Stored Data by Record Number. This sub-function is used to retrieve specific stored data records linked to Diagnostic Trouble Codes (DTCs). These records can contain vital information like system parameters, sensor readings, or event data stored by the ECU. Understanding this service is key to analyzing vehicle faults more accurately and effectively. In this post, I’ll explain how this sub-function works, what its structure looks like, and how to interpret its responses. By the end, you’ll have a clear understanding of how to use 0x05 to extract meaningful diagnostic information. Let’s get started!

Introduction to Report DTC Stored Data By Record Number (0x05): 0x19 Service in UDS Protocol

In the realm of automotive diagnostics, the UDS (Unified Diagnostic Services) protocol plays a key role in providing accurate and detailed information about vehicle systems. One of the essential services within UDS is Service 0x19, specifically Sub-function 0x05, which is used to Report DTC Stored Data by Record Number. This service allows diagnostic tools to retrieve specific data records related to stored Diagnostic Trouble Codes (DTCs). These records provide valuable insights into the state of vehicle systems and can help technicians pinpoint faults. In this article, we will dive into how 0x05 works within Service 0x19, explore its request and response structure, and understand its significance in modern vehicle diagnostics. Let’s get started!

What is ‘Report DTC Stored Data By Record Number (0x05)’ in 0x19 Service of the UDS Protocol?

‘Report DTC Stored Data By Record Number (0x05)’ is a sub-function of Service 0x19 in the UDS (Unified Diagnostic Services) protocol. This service allows diagnostic testers to retrieve specific stored data records related to a Diagnostic Trouble Code (DTC) from the vehicle’s ECU. The data retrieved can include crucial details such as sensor values, system states, or environmental conditions when the fault was logged. By using sub-function 0x05, technicians can extract a detailed snapshot of the vehicle’s condition at the time of the fault, making it easier to diagnose and fix problems. This function is an essential tool for deep diagnostics and ensuring the proper functioning of automotive systems.

Why do we need ‘Report DTC Stored Data By Record Number (0x05)’ in 0x19 Service of the UDS Protocol?

Here’s a clear and concise explanation for why ‘Report DTC Stored Data by Record Number (0x05)’ is needed in 0x19 Service of the UDS Protocol:

1. Contextual Information for Accurate Diagnostics

‘Report DTC Stored Data by Record Number (0x05)’ provides valuable context around the circumstances under which a Diagnostic Trouble Code (DTC) was logged. This includes critical information such as sensor values, system parameters, or environmental conditions at the time of the fault. By having this contextual data, technicians can better understand the cause of the problem, making it easier to identify the underlying issue and its severity. Without this data, diagnostics would rely solely on the fault code, which may not always provide enough insight into the problem’s origin.

2. Improves Troubleshooting Efficiency

This sub-function of Service 0x19 significantly improves the efficiency of troubleshooting. Instead of manually analyzing multiple vehicle parameters or conducting tests to gather data, technicians can retrieve all relevant information in a single request. This allows for a more focused approach to repairs, minimizing the time spent on unnecessary diagnostic steps. The ability to access stored data for each fault helps speed up the diagnosis and repair process, reducing downtime for the vehicle and increasing productivity in service centers.

3. Enables In-Depth Vehicle Analysis

The stored data retrieved through 0x05 offers a deeper look into the vehicle’s condition at the time a fault occurred. This can include variables like engine temperature, vehicle speed, or pressure readings. With this detailed data, technicians can pinpoint specific issues that might have otherwise been overlooked, enabling a more thorough analysis. In-depth analysis also helps prevent recurring problems by identifying patterns or conditions that lead to faults, ultimately contributing to better long-term vehicle maintenance.

4. Enhances Fault Isolation

Having access to the exact data tied to each DTC record allows for better fault isolation. The recorded snapshot enables technicians to verify the precise system states and conditions at the time of fault activation. With this information, it’s easier to rule out unrelated issues and narrow down the exact source of the problem. This enhanced fault isolation means that technicians can make more accurate repairs, avoiding unnecessary part replacements and reducing the risk of overlooking other potential issues in the system.

5. Facilitates Better Vehicle Performance Monitoring

By utilizing Report DTC Stored Data by Record Number (0x05), service centers can continuously monitor vehicle performance and keep track of stored diagnostic data. This function not only aids in identifying immediate issues but also helps in tracking recurring faults over time. Monitoring these records allows technicians to detect patterns in vehicle performance and anticipate potential issues before they escalate, leading to proactive maintenance strategies and better vehicle reliability.

6. Supports Comprehensive Diagnostic Reports

The stored data from 0x05 is often part of a larger diagnostic report, which can be shared with vehicle owners or manufacturers. This provides a complete picture of a vehicle’s health, outlining the specific faults, conditions, and possible causes. Comprehensive diagnostic reports enable vehicle owners to understand the exact issues with their cars and make informed decisions regarding repairs. It also helps service providers maintain accurate records of the work performed, which can be valuable for future service interactions or warranty claims.

7. Enhances Compliance and Standardization

The ‘Report DTC Stored Data by Record Number (0x05)’ feature also plays a critical role in ensuring compliance with industry standards and protocols. Many automotive manufacturers and regulatory bodies require detailed diagnostic data to be stored and retrievable for quality control and safety checks. By using this service, vehicles can adhere to standardized diagnostic procedures, which help ensure that repairs are performed according to the required specifications. This enhances the overall integrity of the diagnostic process and guarantees that vehicles meet regulatory standards for safety and emissions.

Report DTC Stored Data By Record Number (0x05)

A client can retrieve DTCStoredData by requesting the service with the sub-function reportDTCStoredDataByRecordNumber, specifying a DTCStoredDataRecordNumber. The server searches its records for the provided number.

Key Points:

• DTCStoredDataRecordNumber and DTCSnapshotRecordNumber are separate.
• The server may store data from the first or most recent failure occurrence, as defined by the manufacturer.
• The DTCStoredData record includes a dataIdentifier and multiple data parameters (e.g., B+, RPM, timestamp) for reconstructing vehicle conditions.

If DTCStoredDataRecordNumber is set to 0xFF, the server returns all records for the specified DTC in a single response. For each record, the DTCAndStatusRecord is repeated.

If the record number is invalid or unsupported, the server responds negatively. If valid but without associated data, the server responds positively with only the DTCStoredDataRecordNumber.

DTCStoredData is cleared upon a successful ClearDiagnosticInformation request. Manufacturers must specify rules for data deletion in case of memory overflow.

Syntax of Report DTC Stored Data By Record Number (SBFID-0x05) of SID-0x19

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

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type =                        report DTC Stored Data By Record Number]	0x05
#3	DTC Stored Data Record Number	0x00 – 0xFF

reportType: This parameter reflects bits 6 – 0 of the sub-function parameter from the client’s request message.

DTCStoredDataRecordNumber

DTCStoredDataRecordNumber is a 1-byte value indicating the specific DTCStoredDataRecord requested via the reportDTCStoredDataByRecordNumber sub-function. 0x00 is reserved for legislated purposes. Values 0x01 to 0xFE are for manufacturer-specific use, and 0xFF requests all stored DTCStoredData records at once.

Syntax of 0x19 SID Positive Response Message

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

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
#2	Report Type = [                             report DTC Stored Data By Record Number ]	0x05
#3	DTC Stored Data Record Number#1	0x00 – 0xFF
#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	DTC Stored Data Record Number Of Identifiers#1	0x00 – 0xFF
#9 #10 #11 : #11+(p-1)	DTC Stored Data Record[]#1 = [                                                    data Identifier#1 byte#1 (MSB)                                                    data Identifier#1 byte#2 (LSB)                                                    DTC stored Data#1 byte#1                                                                                   :                                                         DTC stored Data#1 byte#p	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF
: #r-(m-1)-2 #r-(m-1)-1 #r-(m-1) : #r	:  Data Identifier#w byte#1 (MSB) Data Identifier#w byte#2 (LSB) DTC stored Data#w byte#1  : DTC stored Data#w byte#m ]	: 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF
:	:	:
#t	DTC Stored Data Record Number#x	0x00 – 0xFF
#t+1 #t+2 #t+3 #t+4	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+5	DTC Stored Data Record Number Of Identifiers#x	0x00 – 0xFF
#t+6 #t+7 #t+8	DTC Stored Data Record[]#x = [                                data Identifier#1 byte#1 (MSB)                                data Identifier#1 byte#2 (LSB)                                DTC stored Data#1 byte#1	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
: #t+8+(p-1) : #n-(u-1)-2 #n-(u-1)-1 #n-(u-1) : #n	: DTC stored Data#1 byte#p :  Data Identifier#w byte#1 (MSB) Data Identifier#w byte#2 (LSB) DTC stored Data#w byte#1 : DTC stored Data#w byte#u ]	: 0x00 – 0xFF : 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF
 Here’s a concise version: C1: DTC And Status Record and the first data Identifier/DTC Stored Data pair are included if at least one DTC Stored Data record is available. C2/C4: Multiple data Identifier/DTC Stored Data pairs can be present in a single DTC Stored Data Record, especially when a single data Identifier references a part of data or a block of data. C3: DTC Stored Data Record Number, DTC And Status Record, and the first data Identifier/DTC Stored Data pair are included only when all records are requested to be reported (DTC Stored Data Record Number set to 0xFF), and more than one record is available.

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

DTCStoredDataRecord: The DTCStoredDataRecord contains a freeze frame of data values recorded at the time of the system malfunction.

DTCStoredDataRecordNumber: This parameter is either the echo of the DTCStoredDataRecordNumber specified by the client in the reportDTCStoredDataByRecordNumber request or the actual DTCStoredDataRecordNumber of a stored DTCStoredDataRecord.

DTCStoredDataRecordNumberOfIdentifiers: This single-byte parameter indicates the number of dataIdentifiers in the immediately following DTCStoredDataRecord.

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_01
• SAE_J1939-73_DTCFormat_02
• ISO11992-4DTCFormat_03
• SAE_J2012-DA_DTCFormat_04

Syntax of 0x19 SID Negative Response Message

Response Message Definition – Sub-Function = Report DTC Stored 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 Stored Data By Record Number (0x05)’ in 0x19 Service of the UDS Protocol

Here are the Examples of ‘Report DTC Stored Data By Record Number (0x05)’ in 0x19 Service of the UDS Protocol:

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

ReadDTCInformation, sub-function = reportDTCStoredDataByRecordNumber, 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 = reportDTCStoredDataByRecordNumber,                  Suppress Pos Rsp Msg Indication Bit = FALSE	0x05
#3	DTC Stored Data Record Number	0x02

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

ReadDTCInformation, sub-function = reportDTCStoredDataByRecordNumber, 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 = reportDTCStoredDataByRecordNumber	0x05
#3	DTC Stored Data Record Number	0x02
#4 #5 #6 #7	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
#8	DTC Stored Data Record Number of Identifiers	0x01
#9 #10	dataIdentifier [ byte#1 ] (MSB) dataIdentifier [ byte#2 ] (LSB)	0x47 0x11
#11 #12 #13 #14 #15	DTC Stored Data Record [ data#1 ] = ECT DTC Stored Data Record [ data#2 ] = TP DTC Stored Data Record [ data#3 ] = RPM DTC Stored Data Record [ data#4 ] = RPM DTC Stored Data Record [ data#5 ] = MAP	0xA6 0x66 0x07 0x50 0x20

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

ReadDTCInformation, sub-function = reportDTCStoredDataByRecordNumber, 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 05
Positive Response: Server --> Client
15 59 05 02 12 34 56 24 01 47 11 A6 66 07 50 20
// Example for Negative Response for SID-0x19
Request: Client --> Server
01 19 05
Negative Response: Server --> Client
03 7F 19 13

Understanding UDS Protocol Commands over CAN (DoCAN) – Example for 0x19 Service (Sub-function 0x05)

The Unified Diagnostic Services (UDS) protocol uses specific command formats to allow a diagnostic tool (client) to communicate with an ECU (server). These commands are transmitted over the CAN (Controller Area Network) using DoCAN (Diagnostics over CAN). Below is a simple breakdown of how this communication works using Service 0x19 with Sub-function 0x05 – Report DTC Stored Data by Record Number.

✅ Positive Response Example:

Request: Client --> Server  
02 19 05

Positive Response: Server --> Client  
15 59 05 02 12 34 56 24 01 47 11 A6 66 07 50 20

Explanation of the Code:

• 02: This is the PCI (Protocol Control Information) byte. It means 2 bytes of actual data follow (i.e., 0x19 and 0x05).
• 19: The Service Identifier (SID). Here, 0x19 indicates the ReadDTCInformation service.
• 05: This is the Sub-function, meaning Report DTC Stored Data by Record Number.

Server’s Positive Response:

• 15 – Total length of the response message.
• 59 – Positive response SID (0x40 + 0x19 = 0x59).
• 05 – Echoed sub-function.
• 02 – Snapshot record number.
• 12 34 56 – DTC associated with this snapshot.
• 24 – Status availability or format identifier.
• 01 47 11 A6 66 07 50 20 – Snapshot data (freeze-frame values like engine RPM, coolant temperature, vehicle speed, etc.)

This data gives insight into the operating conditions at the time the fault was recorded.

❌ Negative Response Example:

Request: Client --> Server  
01 19 05

Negative Response: Server --> Client  
03 7F 19 13

Explanation of the Code:

• 01: PCI byte – 1 byte of actual data follows (0x19).
• 19: SID – ReadDTCInformation.
• 05: Sub-function – Report DTC Stored Data by Record Number.

Server’s Negative Response:

• 03: PCI byte – 3 bytes of data follow.
• 7F: Standard identifier for negative response.
• 19: Echoes the original service (0x19) that caused the error.
• 13: Negative Response Code (NRC) – here, 0x13 means Invalid Format. It indicates the request was not in the expected format or missing required parameters.

Final Thoughts:

These message structures are part of how ECUs and diagnostic tools “talk” to each other using UDS over CAN. Positive responses provide requested data, while negative responses help diagnose why a command failed. Understanding these formats is essential for diagnostics engineers, testers, and anyone working in automotive embedded systems.