Understanding “Report Emissions OBD-DTC by Status Mask (0x13)” in UDS Protocol 0x19 Service

Hello, automotive diagnostics enthusiasts! In this blog post, Report Emissions OBD-DTC by Status Mask (0x13) in UDS. I’ll introduce you to one of the key sub-functions in the U

DS protocol Report Emissions OBD-DTC by Status Mask (0x13), which is part of the 0x19 service. This function plays a vital role in retrieving emissions-related Diagnostic Trouble Codes (DTCs) based on specific status masks. It’s a powerful tool used in vehicle ECUs for emission compliance and diagnostics. We’ll explore what this sub-function does, how it works, and when it’s typically used in real-world scenarios. You’ll also learn about the structure of the request and response messages involved. By the end of this post, you’ll have a clear understanding of how to implement and interpret the 0x13 sub-function in UDS. Let’s dive into the world of diagnostics!

Introduction to “Report Emissions OBD-DTC by Status Mask (0x13)” in the UDS Protocol 0x19 Service

The Unified Diagnostic Services (UDS) protocol is a key component in modern automotive diagnostics, enabling standardized communication between diagnostic tools and vehicle ECUs. One important feature within this protocol is the 0x19 service, used for reading Diagnostic Trouble Codes (DTCs). Among its sub-functions, 0x13 – Report Emissions OBD-DTC by Status Mask plays a crucial role in retrieving emissions-related fault codes based on specific status conditions. This sub-function is particularly valuable for emission compliance, regulatory diagnostics, and targeted fault analysis. By using a status mask, it allows technicians to filter and retrieve only the relevant DTCs that meet certain criteria, improving the efficiency and accuracy of diagnostics. In this article, we will explore the purpose, request and response format, and practical application of the 0x13 sub-function within the UDS protocol’s 0x19 service.

What is “Report Emissions OBD-DTC by Status Mask (0x13)” in the UDS Protocol’s 0x19 Service?

In the Unified Diagnostic Services (UDS) protocol, the 0x19 Service is known as “Read DTC Information”. It allows external diagnostic tools to request various types of Diagnostic Trouble Code (DTC) information from an Electronic Control Unit (ECU). One of the sub-functions under this service is 0x13, which is used to report emissions-related OBD DTCs based on a specific status mask.

The “Report Emissions OBD-DTC by Status Mask (0x13)” function is designed specifically to retrieve only those DTCs that are related to vehicle emissions and that match certain status criteria. These criteria are defined using a status mask a byte or set of bytes that tells the ECU which DTCs to include in the response, depending on their current status (e.g., test failed, pending, confirmed, warning indicator ON, etc.).

This is particularly useful in On-Board Diagnostics (OBD) systems where emissions-related faults must be carefully monitored and reported to comply with environmental regulations such as OBD-II in the U.S. or EOBD in Europe. Using sub-function 0x13, a scan tool can request a list of emissions-related DTCs that are active or have specific statuses, improving diagnostic efficiency and ensuring that emission-related problems are prioritized.

Why do we need “Report Emissions OBD-DTC by Status Mask (0x13)” in the UDS Protocol’s 0x19 Service?

The “Report Emissions OBD-DTC by Status Mask (0x13)” sub-function is essential in modern automotive diagnostics for several reasons, especially when dealing with emissions-related trouble codes. Here’s why it’s needed:

1. Regulatory Compliance

Modern vehicles must comply with strict emission standards set by regulatory bodies such as OBD-II in the U.S. and EOBD in Europe. These standards mandate that emission-related issues be accurately monitored and reported. The 0x13 sub-function helps fulfill this requirement by allowing diagnostic tools to request only emissions-related DTCs. This ensures that vehicles meet legal emission limits and that faults affecting emissions are not overlooked. Without this function, it would be difficult to isolate and report only those DTCs relevant to environmental compliance.

2. Efficient Data Filtering

Vehicles often store multiple DTCs, not all of which are active or relevant at the time of diagnostics. The 0x13 function uses a status mask that allows technicians to filter DTCs based on specific conditions like whether the fault is pending, confirmed, or has triggered the warning indicator. This filtering mechanism avoids information overload and lets users focus on only the DTCs that matter right now. It leads to a faster and more efficient diagnosis process.

3. Focus on Emission-Impacting Faults

Not every fault in a vehicle affects emissions, but those that do are critical for ensuring environmental performance. The 0x13 sub-function is designed specifically to extract only the DTCs related to the emissions system. This targeted approach allows service technicians to prioritize repairs that have the greatest impact on pollution control. It ensures that emission-related issues are handled first, improving both vehicle health and environmental safety.

4. Improved Diagnostic Accuracy

Using the status mask, 0x13 returns only those DTCs that match specific operational conditions, such as “test failed this cycle” or “warning lamp is ON.” This eliminates outdated, irrelevant, or previously resolved fault codes from the results. As a result, technicians receive clean, real-time diagnostic data. This improves the accuracy of troubleshooting and prevents unnecessary part replacements or guesswork in the repair process.

5. Support for On-Board Inspection Readiness

Many countries require emission system checks during periodic vehicle inspections. The 0x13 sub-function supports these checks by offering a standard way to retrieve emissions-related DTCs based on their current status. This helps inspection tools or government testers verify that no emission-related faults are present before a vehicle is allowed to pass. It is a reliable way to confirm a vehicle’s readiness for road use, especially in regulated areas.

6. Faster Troubleshooting and Servicing

By showing only the DTCs that are currently active or meet specific fault conditions, 0x13 allows technicians to quickly identify and focus on real-time issues. This results in less time spent sorting through irrelevant or stored fault data. With a narrowed focus, the repair process becomes faster, helping technicians make quick decisions and reducing overall vehicle downtime. It also improves workshop efficiency and customer satisfaction.

7. Compatibility Across OEMs and Tools

The 0x13 sub-function is defined within the UDS protocol, which is a standardized diagnostic protocol used by many OEMs (Original Equipment Manufacturers). This ensures that diagnostic tools, regardless of brand, can consistently access emission-related DTCs in a uniform format. This interoperability makes it easier for workshops to handle vehicles from multiple manufacturers using a single toolset, improving workflow and reducing the need for proprietary systems.

“Report Emissions OBD-DTC by Status Mask (0x13)” in the UDS Protocol’s 0x19 Service

When a diagnostic client needs to retrieve only the emissions-related OBD DTCs that meet specific conditions, it can use the UDS sub-function “Report Emissions OBD-DTC by Status Mask (0x13)”. This sub-function enables the client to define a status mask and request the server to return only those DTCs that match the specified criteria such as “testFailed”, “confirmed”, or other applicable statuses. To perform this filtering, the server uses a bitwise AND operation between the status mask provided by the client and the current status of each emissions-related OBD DTC stored on the server. Only the DTCs for which this operation yields a non-zero result (i.e., (DTC_Status & Status_Mask) ≠ 0) are included in the response. This ensures that the response contains only the DTCs that satisfy the requested conditions, enhancing both relevance and diagnostic efficiency.

If the client includes status mask bits that the server does not support, the server will simply ignore those unsupported bits and process the request using the bits it recognizes. In cases where no DTCs match the filtering criteria, the server will respond with only the DTCStatusAvailabilityMask and omit any DTC or status information. Additionally, it’s important to note that the status of emissions-related OBD DTCs is cleared when the client sends a ClearDiagnosticInformation (0x14) request and it is processed successfully by the server.

Syntax of Report Emissions OBD-DTC by Status Mask (SBFID-0x13) of SID-0x19

Request Message Definition – Sub-Function = Report Emissions OBD-DTC by Status Mask

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type =                             Report Emissions OBD-DTC by Status Mask ]	0x13
#3	DTC Status Mask	0x00 – 0xFF

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

DTC Status Mask:

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.

Syntax of 0x19 SID Positive Response Message

Response Message Definition – Sub-function = Report Emissions OBD-DTC by Status Mask

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
#2	Report Type = [                               Report Emissions OBD-DTC by Status Mask	0x13
#3	DTC Status Availability Mask	0x00 – 0xFF
#4 #5 #6 #7 #8 #9 #10 #11 : #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 Of DTC#2                                                                      :                                                      DTC High Byte#m                                                      DTC Middle Byte#m                                                      DTC Low Byte#m                                                      status Of DTC#m	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
Sure, here’s a concise version: C1: Present if DTC information is available. C2: Present if report Type matches specific conditions and more than one DTC is available.

SBFID (0x13) 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_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 Emissions OBD-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 Emissions OBD-DTC by Status Mask (0x13)” in the UDS Protocol’s 0x19 Service

Here are the Examples of “Report Emissions OBD-DTC by Status Mask (0x13)” in the UDS Protocol’s 0x19 Service:

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

Read DTC Information, Sub-function = Report Emissions OBD-DTC by Status Mask, 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 Emissions OBD-DTC By Status Mask,                  Suppress Pos Rsp Msg Indication Bit = FALSE	0x13
#3	DTC Status Mask	0x80

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

Read DTC Information, Sub-function = Report Emissions OBD-DTC By Status Mask, 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 Emissions OBD-DTC By Status Mask	0x13
#3	DTC Status Availability Mask	0xFF
#4 #5 #6 #7	DTC And Status Record#1 [ DTC High Byte ] DTC And Status Record#1 [ DTC Middle Byte ] DTC And Status Record#1 [ DTC Low Byte ] DTC And Status Record#1 [ status Of DTC ]	0x00 0x05 0x00 0xAE
#8 #9 #10 #11	DTC And Status Record#2 [ DTC High Byte ] DTC And Status Record#2 [ DTC Middle Byte ] DTC And Status Record#2 [ DTC Low Byte ] DTC And Status Record#2 [ status Of DTC ]	0x02 0x2F 0x00 0xAC
#12 #13 #14 #15	DTC And Status Record#3 [ DTC High Byte ] DTC And Status Record#3 [ DTC Middle Byte ] DTC And Status Record#3 [ DTC Low Byte ] DTC And Status Record#3 [ status Of DTC ]	0x0A 0x09 0x00 0xAF

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

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 13
Positive Response: Server --> Client
15 59 13 FF 00 05 00 AE 02 2F 00 AC 0A 09 00 AF
// Example for Negative Response for SID-0x19
Request: Client --> Server
01 19 13
Negative Response: Server --> Client
03 7F 19 13

UDS Protocol Example: Using “Report Emissions OBD-DTC by Status Mask (0x13)” Over CAN (DoCAN)

In the Unified Diagnostic Services (UDS) protocol, diagnostics are performed by sending service requests from a client (tester) to a server (ECU). The communication is typically done over the CAN bus, following the DoCAN (Diagnostics over CAN) specification. Below, we explain how the 0x13 sub-function of 0x19 service is used to report emissions-related OBD DTCs based on a status mask.

✅ Example: Positive Response for Service ID 0x19 Sub-function 0x13

Request Frame (Client → Server):

02 19 13

Breakdown:

• 02 – Indicates that 2 bytes of data follow in the CAN frame.
• 19 – This is the Service ID for ReadDTCInformation.
• 13 – This is the sub-function for Report Emissions-Related OBD DTCs by Status Mask.

The client sends this to request all emissions-related DTCs that meet a predefined status mask (typically stored internally).

Positive Response Frame (Server → Client):

15 59 13 FF 00 05 00 AE 02 2F 00 AC 0A 09 00 AF

Breakdown:

• 15: Indicates total data length = 21 bytes.
• 59: Positive response SID (0x19 + 0x40 = 0x59).
• 13: Echoes the sub-function (0x13).
• The rest of the data contains multiple DTC records in the following pattern:

Sample DTC Record Format:

Each record typically includes:

• 3 Bytes DTC Code
• 1 Byte DTC Status
• (Optional additional info bytes depending on ECU design)

Example Parsing:

1. FF 00 05: DTC code 1
2. 00: Status byte for DTC 1
3. AE 02 2F: DTC code 2
4. 00: Status byte for DTC 2
5. AC 0A 09: DTC code 3
6. 00: Status byte for DTC 3
7. AF: Possibly the beginning of another DTC or extra information depending on format definition.

• DTC Status Byte indicates fault conditions like:
  • Bit 0: Test failed
  • Bit 1: Confirmed DTC
  • Bit 2: Pending DTC (this bit is typically 1 here)
  • Bit 7: Warning indicator requested

❌ Example: Negative Response for Service ID 0x19 Sub-function 0x13

Request Frame (Client → Server):

01 19 13

Breakdown:

• 01 – Indicates 1 byte of data follows.
• 19 – Service ID for ReadDTCInformation.
• 13 – Sub-function for reporting emissions-related DTCs by status mask.

In this request, the status mask may have been invalid, unsupported, or no matching DTCs were found.

Negative Response Frame (Server → Client):

03 7F 19 13

Breakdown:

• 03 – Indicates that 3 bytes follow in the CAN frame.
• 7F – This is a negative response identifier.
• 19 – The original Service ID that caused the error.
• 13 – The Negative Response Code (NRC) indicating the type of error.

Note: The meaning of the NRC 0x13 can vary. In UDS, common NRCs include:

• 0x11 – Service not supported
• 0x12 – Sub-function not supported
• 0x13 – Incorrect message length or invalid format

Here, 0x13 means the server rejected the request due to incorrect length or an improperly formatted message.

Using the 0x13 sub-function of UDS Service 0x19 allows diagnostic testers to retrieve emissions-related DTCs filtered by specific status conditions. The status mask provided by the client ensures only relevant DTCs are returned. If the request is valid and matching DTCs exist, the server responds positively; otherwise, a negative response is returned with a code explaining why the request failed.