UDS Service 0x19 – How to Report User Defined Memory DTCs by Status Mask (0x17)

Hello, fellow automotive diagnostics enthusiasts! In this blog post, Report User DefMemory DTC By Status Mask (0x17) in UDS. I’ll walk you through an essential and powerful fea

ture in the UDS (Unified Diagnostic Services) protocol: Service 0x19 – Report DTC by Status Mask (0x17). This service allows testers and developers to retrieve Diagnostic Trouble Codes (DTCs) from user-defined memory areas based on specific status masks. It plays a critical role in ECU diagnostics, especially when custom or proprietary DTC handling is implemented. Understanding how to properly use Service 0x19 with sub-function 0x17 can greatly enhance your diagnostic coverage and testing accuracy. We’ll explore its purpose, message structure, use cases, and how to implement it effectively. Whether you’re working on HIL testing or ECU development, this guide will sharpen your skills. Let’s dive into the details of this powerful UDS feature!

Introduction to Reporting User Defined Memory DTCs by Status Mask (0x17) in UDS Protocol Service 0x19

Welcome to this deep dive into UDS Protocol Service 0x19, specifically focusing on the sub-function Status Mask (0x17) for reporting User Defined Memory DTCs. In the world of automotive diagnostics, retrieving Diagnostic Trouble Codes (DTCs) accurately is crucial for validating ECU behavior and ensuring compliance with diagnostic standards. The UDS (Unified Diagnostic Services) protocol offers powerful services, and Service 0x19 is key when it comes to reading stored, pending, or confirmed DTCs. Sub-function 0x17 allows developers to filter DTCs based on specific status bits, making diagnostics more targeted and efficient. This feature is especially valuable when dealing with custom DTC storage in non-volatile memory areas. In this post, we’ll explore the structure, usage, and real-world applications of this service. By the end, you’ll have a clear understanding of how to implement and validate UDS Service 0x19 with sub-function 0x17.

What is ‘Report User Defined Memory DTC by Status Mask (0x17)’ in UDS Protocol Service 0x19?

In the UDS protocol (Unified Diagnostic Services, defined in ISO 14229), Service 0x19 Read DTC Information is used by diagnostic tools (e.g., testers, HIL systems) to query Diagnostic Trouble Codes (DTCs) stored in a vehicle’s ECU. This service supports multiple sub-functions to retrieve various types of DTC data.

Sub-function 0x17 is one of those specialized functions in Service 0x19. Its official name is:

“Report User Defined Memory DTC by Status Mask”

This function is designed to allow diagnostic testers to query DTCs stored in user-defined or proprietary memory sections of the ECU not the standard DTC storage area.

Why is this important?

In many advanced or custom automotive systems, engineers may store additional or proprietary diagnostic codes in separate memory blocks. These might include:

• OEM-specific fault tracking
• Safety-critical backup diagnostics
• Redundant or extended diagnostics in AUTOSAR-based systems

How It Works?

Here’s a breakdown of how this service call works:

Field	Description
Service ID (SID)	0x19 — Read DTC Information
Sub-function	0x17 — Report User Defined Memory DTC by Status Mask
Status Mask	A bitmask used to filter which DTCs should be returned based on their current status (e.g., test failed, confirmed, pending, etc.)

Status Mask:

The Status Mask is an 8-bit field where each bit represents a specific DTC status, as per ISO 14229-1. Common bits include:

• Bit 0: Test Failed
• Bit 1: Test Failed This Operation Cycle
• Bit 2: Pending
• Bit 3: Confirmed
• Bit 7: Warning Indicator Requested (MIL, etc.)

You pass this bitmask to retrieve only the DTCs matching those statuses.

Why do we need ‘Report User Defined Memory DTC by Status Mask (0x17)’ in UDS Protocol Service 0x19?

Here is why we need ‘Report User Defined Memory DTC by Status Mask (0x17)’ in UDS Protocol Service 0x19:

1. Support for Custom or Proprietary Diagnostics

Not all DTCs are standard OBD-II trouble codes. Many OEMs or Tier-1 suppliers define custom or internal DTCs for:

• Development-phase debugging
• Software-level internal faults
• Hardware testing (e.g., memory checks, power stages, etc.)

These DTCs are typically stored in user-defined memory blocks, separate from the OBD-compliant area. Sub-function 0x17 allows access to these non-standard DTCs.

2. Separation of OBD and OEM Diagnostics

In an ECU, DTCs can be logically separated into:

• Standard OBD memory (for emissions, required by regulations)
• User-defined memory (for internal OEM diagnostics)

Using sub-function 0x17 allows the tester to query only the user-defined memory without interfering with the standard DTC memory.

3. Efficient Filtering Using Status Masks

Just like other DTC queries in UDS, sub-function 0x17 supports status mask filtering. This allows testers to:

• Retrieve only active or confirmed faults
• Ignore irrelevant or cleared DTCs
• Focus on specific test conditions (e.g., test failed this cycle)

This makes automated diagnostics, logging, and test automation more efficient.

4. Important for HIL, SIL, and V&V Testing

In Hardware-in-the-Loop (HIL) or Software-in-the-Loop (SIL) testing:

• Engineers simulate ECU faults to validate diagnostic responses.
• User-defined DTCs are often used to represent simulated or injected faults.
• Service 0x19 with sub-function 0x17 allows the test system to read back these custom DTCs and verify expected behavior.

5. Extensibility Without Breaking Standards

The UDS protocol is designed to be flexible. Sub-function 0x17 provides a way for OEMs to:

• Add advanced diagnostics
• Implement additional health monitoring
• Maintain separation from standard OBD-II compliance

…without violating the ISO 14229 standard or confusing generic diagnostic tools.

6. Multi-Domain ECU Support (e.g., ADAS, Infotainment, Powertrain)

Modern ECUs often serve multiple functions or domains, each with its own diagnostic logic. For example:

• A powertrain ECU may handle both combustion and hybrid logic.
• An ADAS ECU may combine radar, camera, and sensor fusion diagnostics.

Using sub-function 0x17, OEMs can partition DTCs by domain, storing some in user-defined memory and retrieving them independently for debugging or OTA diagnostics.

7. Improved Cybersecurity Isolation

Some ECUs implement diagnostic isolation for security purposes limiting access to certain DTCs unless specific conditions are met (e.g., security access granted).
Sub-function 0x17 can be configured to:

• Restrict access to sensitive or critical DTCs
• Only expose user-defined memory after security unlock or tester authentication
  This helps enforce secure diagnostic communication, especially in safety-critical systems.

8. Post-Production and Field Debugging

In post-production, service, or in-field debugging scenarios:

• Engineers often need more detailed fault information than what’s exposed via standard DTCs.
• Sub-function 0x17 allows technicians or OEM engineers to access additional diagnostic depth for intermittent, rare, or internal issues.

This helps with faster root cause analysis during warranty claims, customer complaints, or field returns.

‘Report User Defined Memory DTC by Status Mask (0x17)’ in UDS Protocol Service 0x19

When a diagnostic client wants to retrieve specific Diagnostic Trouble Codes (DTCs) from a user-defined memory block, it can do so by sending a Service 0x19 request with sub-function 0x17 (reportUserDefMemoryDTCByStatusMask). This sub-function enables targeted DTC retrieval based on a status mask defined by the client. For example, the client might want to fetch all DTCs that are marked as “testFailed”, “confirmed”, or other relevant status types. To achieve this, the client includes a status mask in the request, indicating which status bits to filter for.

On the server (ECU) side, the DTC evaluation is performed by applying a bitwise AND between the client’s status mask and the actual status byte of each DTC stored in the specified memory region. If the result of this bitwise operation is non-zero ((DTCStatus & ClientMask) != 0), the DTC qualifies to be included in the response.

The server also returns the DTCStatusAvailabilityMask, indicating which status bits it supports. If the client’s mask includes unsupported bits, the server simply ignores those and processes the request based only on the bits it recognizes. If none of the DTCs in the user-defined memory match the requested mask criteria, the server’s response will contain only the DTCStatusAvailabilityMask no actual DTC entries will follow.

It’s also important to note that, unlike standard DTC clearing behavior, the status information for these user-defined DTCs is not reset through a standard ClearDiagnosticInformation (0x14) request. Instead, clearing is handled via a manufacturer-specific routine, allowing OEMs to retain more control over custom diagnostic data.

Syntax of Report User Defined Memory DTC by Status Mask (SBFID-0x17) of SID-0x19

Request Message Definition – Sub-function = Report User Defined Memory DTC By Status Mask

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type = Report User Defined Memory DTC By Status Mask ]	0x17
#3	DTC Status Mask	0x00 – 0xFF
#4	Memory Selection	0x00 – 0xFF

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

DTCStatusMask: The DTCStatusMask contains eight bits defining DTC statuses. In the request message, it allows the client to request DTC information for DTCs whose status matches the mask. A match occurs if any bit in the DTC’s status is ‘1’ and the corresponding bit in the DTCStatusMask is also ‘1’. Unsupported bits in the mask are ignored by the server.

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 By Status Mask

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
#2	Report Type = [                               Report User Defined Memory DTC By Status Mask ]	0x17
#3	Memory Selection	00 – FF
#4	DTC Status Availability Mask	00 – FF
#5 #6 #7 #8 #9 #10 #11 #12 : #n-3 #n-2 #n-1 #n	DTC And Status Record[] = [                                           DTC High Byte#1                                                 DTC Middle Byte#1                                                 DTC Low Byte#1                                                      status Of DTC#1                                                 DTC High Byte#2                                                 DTC Middle Byte#2                                                   DTC Low Byte#2                                                      status OfDTC#2                                                                   :                                                      DTC High Byte#m                                                      DTC Middle Byte#m                                                  DTC Low Byte#m                                                      status Of DTC#m	00 – FF 00 – FF 00 – FF 00 – FF 00 – FF 00 – FF 00 – FF 00 – FF : 00 – FF 00 – FF 00 – FF 00 – FF
C1: This parameter is only present if DTC information is available to be reported. C2: This parameter is only present if more than one DTC information is available to be reported.

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

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

Syntax of 0x19 SID Negative Response Message

Response Message Definition – Sub-Function = Report User Defined Memory DTC By Status Mask

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 by Status Mask (0x17)’ in UDS Protocol Service 0x19

Here are the Examples of ‘Report User Defined Memory DTC by Status Mask (0x17)’ in UDS Protocol Service 0x19:

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

Understanding UDS Service 0x19 (Sub-function 0x17) Over CAN – Request and Response Examples

In the Unified Diagnostic Services (UDS) protocol over CAN (commonly known as DoCAN, as per ISO 15765-3), Service ID 0x19 is used to read DTC (Diagnostic Trouble Code) information from an ECU. One of its important sub-functions is 0x17, which allows the retrieval of user-defined memory DTCs based on a status mask.

Let’s break down a practical example of how this communication happens between a diagnostic client (tester) and a server (ECU) over the CAN network.

✅ Example 1: Positive Response for UDS Service 0x19, Sub-function 0x17

Request (Client → Server)

02 19 17

• 02: Number of additional bytes (excluding this length byte)
• 19: Service ID for ReadDTCInformation
• 17: Sub-function for Report User Defined Memory DTC by Status Mask

This request tells the ECU to return all DTCs from the user-defined memory that match the status mask defined internally (this example omits the status mask byte for simplicity).

Positive Response (Server → Client)

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

Let’s decode this:

• 14: Total number of bytes to follow (optional depending on protocol stack)
• 59: Positive Response SID (0x19 + 0x40 = 0x59)
• 17: Echoed sub-function
• The rest of the data:
  • 12 34 56: DTC #1
  • 24: Status byte for DTC #1
  • 05 17: Additional data (e.g., fault occurrence counter, aging counter)
  • 23 45 61: DTC #2
  • 24: Status byte for DTC #2
  • 05 79: Additional info for DTC #2

Each DTC entry includes the 3-byte DTC code, a 1-byte status, and optionally more bytes depending on ECU configuration.

❌ Example 2: Negative Response for UDS Service 0x19, Sub-function 0x17

Request (Client → Server)

03 19 17

• 03: Total data length
• 19: Service ID
• 17: Sub-function

Negative Response (Server → Client)

03 7F 19 13

• 03: Number of bytes
• 7F: Indicates a negative response
• 19: The original Service ID (ReadDTCInformation)
• 13: NRC (Negative Response Code) – 0x13 = Incorrect Message Length or Invalid Format

This means the ECU rejected the request due to an improperly formatted message most likely, the status mask byte was missing or the data length did not match the expected format.

Key Takeaways for UDS over CAN (DoCAN)

Element	Description
0x19	Read DTC Information Service
0x17	Sub-function to report DTCs from user-defined memory using a status mask
0x59	Positive response (0x19 + 0x40)
0x7F	Indicates a negative response
0x13	Error code: Incorrect message length or format

This exchange is fundamental in automotive diagnostics, HIL testing, and custom ECU development, especially when OEM-specific memory areas or proprietary DTCs are involved.