Report WWH-OBD DTC By Mask Record (0x42): 0x19 Service in UDS Protocol

UDS 0x19 Service: Understanding Report WWH-OBD DTC By Mask Record (0x42) for Emissions Compliance and Diagnostics

Hello, fellow automotive tech enthusiasts! In this blog post, Report WWH-OBD DTC By Mask Record (0x42) in UDS. I’ll walk you through one of the critical and lesser-known diagno

stic features in the UDS protocol – the Report WWH-OBD DTC By Mask Record (0x42) sub-function of Service 0x19. This service plays a key role in emission-related diagnostics and compliance, especially under the Worldwide Harmonized OBD (WWH-OBD) regulations. Whether you’re building a diagnostic tool, working on ECU software, or just exploring UDS deeper, understanding this sub-function is vital. I’ll explain what this service is, when and why it’s used, and how the client-server communication works. We’ll also go through the request/response formats with practical insights. By the end of this article, you’ll have a strong grasp of how 0x42 supports robust diagnostic reporting in modern vehicles. Let’s get started!

Introduction to UDS 0x19 Service: Report WWH-OBD DTC By Mask Record (0x42)

Welcome to this deep dive into the world of automotive diagnostics! In this post, we’ll explore a specialized sub-function of the Unified Diagnostic Services (UDS) protocol – Report WWH-OBD DTC By Mask Record (0x42), which is part of Service 0x19. This function plays a key role in retrieving diagnostic trouble codes (DTCs) specifically related to emission control systems, as required by Worldwide Harmonized On-Board Diagnostics (WWH-OBD) standards. Understanding how 0x42 works is essential for developers working on ECU diagnostics, emissions compliance, and modern vehicle health monitoring. We’ll walk through its purpose, message structure, and usage scenarios. Whether you’re a beginner or a seasoned automotive engineer, this guide will help clarify how this UDS service contributes to safer, greener vehicles. Let’s get started with the fundamentals!

What is Report WWH-OBD DTC By Mask Record (0x42): 0x19 Service in UDS Protocol?

Unified Diagnostic Services (UDS) is a communication protocol defined in ISO 14229, widely used in automotive systems for diagnostics and vehicle testing. It allows diagnostic testers (e.g., scan tools or ECUs) to communicate with on-board systems to retrieve data, read/clear DTCs, perform tests, or reprogram ECUs.

Service 0x19 (ReadDTCInformation) is used to retrieve Diagnostic Trouble Codes (DTCs) from the ECU. This service has many sub-functions to cover various DTC reporting needs, including:

• 0x01: ReportNumberOfDTCByStatusMask
• 0x02: ReportDTCByStatusMask
• 0x06: ReportDTCWithPermanentStatus
• 0x0A: ReportSupportedDTC
• and importantly for our case:
• 0x42: ReportWWHOBDDTCByMaskRecord

What Is WWH-OBD?

WWH-OBD (Worldwide Harmonized On-Board Diagnostics) is an emissions-related diagnostic standard defined in ISO 27145. It builds on UDS and ensures that vehicles sold globally follow unified diagnostics for emission compliance. It focuses on standardized reporting, uniform code structures, and clear diagnostics for regulators and service technicians.

Sub-function 0x42: Report WWH-OBD DTC By Mask Record

This is a specific sub-function of UDS Service 0x19, defined to work in WWH-OBD mode.

It allows the diagnostic tester to request WWH-OBD-compliant Diagnostic Trouble Codes from the ECU based on a filter (status mask record).

Key Takeaways:

• It filters and returns only WWH-OBD relevant DTCs.
• It complies with emissions diagnostics regulations.
• It ensures that only required DTCs (e.g., those causing MIL-on conditions) are reported.
• ReportWWHOBDDTCByMaskRecord (0x42) is a sub-function of UDS Service 0x19.
• It is used in WWH-OBD diagnostics to report DTCs related to emissions.
• Filters DTCs based on status masks to return only relevant codes.
• Helps meet regulatory requirements and enhances diagnostic precision.

Why do we need Report WWH-OBD DTC By Mask Record (0x42): 0x19 Service in UDS Protocol?

The Report WWH-OBD DTC By Mask Record (0x42) is a specialized sub-function of UDS Service 0x19 (ReadDTCInformation). It was introduced to meet the strict diagnostic and reporting requirements of WWH-OBD (Worldwide Harmonized On-Board Diagnostics), a global standard for emissions-related diagnostics.

Here’s why this sub-function is needed:

1. WWH-OBD Compliance (ISO 27145)

Report WWH-OBD DTC By Mask Record (0x42) is designed to meet the diagnostic needs of WWH-OBD, a global standard for emissions-related diagnostics under ISO 27145. This standard is required in regions such as Europe, Japan, and India for vehicles under regulations like Euro 6 and Bharat Stage VI. The 0x42 service ensures that diagnostic tools can retrieve only emission-relevant trouble codes. Without this, emission certification would be inefficient and inconsistent. It plays a key role in harmonizing global OBD systems.

2. Selective DTC Reporting Using Status Masks

Unlike generic DTC requests, 0x42 allows filtering DTCs based on their status bits – for example, test failed this cycle, test failed since last clear, or MIL requested. This helps the tester to focus only on active or relevant DTCs instead of retrieving an entire list. The “mask record” acts like a filter, improving diagnostic efficiency. This functionality is especially useful in emission inspection workflows. It reduces processing time and prevents unnecessary data from being reported.

3. Efficient Emission Testing & Certification

During emission testing or vehicle certification, only emission-relevant faults are required to be reported. Sub-function 0x42 allows direct access to these codes, helping certification authorities retrieve exactly what is needed without manual filtering. This is critical for fast and accurate compliance checks. It streamlines the inspection process for manufacturers and government testing stations. As a result, emission testing becomes faster and more automated.

4. Supports Global Diagnostic Harmonization

One of the goals of WWH-OBD is to ensure diagnostic uniformity across vehicle manufacturers and regions. By using 0x42, diagnostic tools and testers get a standardized format and structure for DTCs. This reduces the need for OEM-specific customization and tool adaptation. Engineers and testers can use the same implementation logic globally. It promotes plug-and-play diagnostics and improves compatibility across vehicles and scan tools.

5. Data Integrity & Legal Validation

In regulated environments, it’s important to ensure that only emission-related DTCs are disclosed during inspections or audits. Using 0x42 restricts the response to relevant DTCs only, preserving data privacy and legal compliance. This prevents accidental exposure of unrelated system DTCs, which may be OEM-specific or proprietary. It provides a legally accepted way to collect data for emissions validation. This improves trust in vehicle data reporting.

6. Real-World Use in OBD Scanners

Many advanced scan tools and emission test devices rely on 0x42 to extract necessary information from the vehicle. These tools often run automated checks using predefined status mask filters. The sub-function 0x42 allows them to retrieve only what’s required for their specific testing purpose. This also ensures compatibility with international regulations. In practice, it enables fast and accurate diagnostics with minimal manual input.

7. Improves Diagnostic Efficiency and Reduces Network Load

Using the Report WWH-OBD DTC By Mask Record (0x42) service helps optimize communication between the diagnostic tester and the vehicle’s ECU. Instead of retrieving all DTCs, which can be numerous and include irrelevant codes, the tester requests only filtered, relevant emission-related DTCs. This reduces data transfer volume and processing time, making diagnostics faster and more responsive. It also minimizes network congestion on the vehicle’s diagnostic bus, which is important in complex modern vehicles with multiple ECUs communicating simultaneously. Overall, this improves the reliability and speed of emission diagnostics.

Syntax of Report WWH-OBD DTC By Mask Record (SBFID-0x42) of SID-0x19

Request message Definition – Sub-function = Report WWH-OBD DTC By Mask Record

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type =                             Report WWH-OBD DTC By Mask Record]	0x42
#3	Functional Group Identifier	0x00 – 0xFF
#4 #5	DTCSeverityMaskRecord[] = [ DTCStatusMask DTCSeverityMask ]	0x00 – 0xFF 0x00 – 0xFF

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

Functional Group Identifier:

The FunctionalGroupIdentifier was introduced to help differentiate commands sent by diagnostic tools across various functional system groups within a vehicle’s complex electrical architecture, which often includes multiple ECUs. In cases where a single ECU manages software for both the emissions system and other vehicle systems subject to inspection during an Inspection/Maintenance (I/M) test, it becomes crucial to report only the Diagnostic Trouble Codes (DTCs) related to the specific functional group requested. This ensures that the I/M test results remain accurate and are not affected by DTCs from unrelated system groups. Ultimately, this prevents a test failure caused by faults outside the scope of the targeted functional area.

DTC Severity Mask Record:

The DTCSeverityMaskRecord is a two-byte data structure that combines both the DTCSeverityMask and the DTCStatusMask. This record allows diagnostic tools to simultaneously filter Diagnostic Trouble Codes (DTCs) based on their severity levels as well as their current status. By using this combined mask, testers can perform more targeted queries to retrieve only the DTCs that meet specific severity and status criteria, enhancing the precision and efficiency of vehicle diagnostics.

Syntax of 0x19 SID Positive Response Message

Response Message Definition – Sub-Function = Report WWH-OBD DTC By Mask Record

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
#2	Report Type = [                             report DTC Snapshot Identification ]	0x42
#3	FunctionalGroupIdentifier	0x00 – 0xFF
#4	DTCStatusAvailabilityMask	0x00 – 0xFF
#5	DTCSeverityAvailabilityMask	0x00 – 0xFF
#6	DTCFormatIdentifier = [ SAE_J2012-DA_DTCFormat_04 SAE_J1939-73_DTCFormat]	0x04 0x02
#7 #8 #9 #10 #11 : #n-4 #n-3 #n-2 #n-1 #n	DTCAndSeverityRecord[] = [ DTCSeverity#1 DTCHighByte#1 (MSB) DTCMiddleByte#1 DTCLowByte#1 statusOfDTC#1 : DTCSeverity#m DTCHighByte#m (MSB) DTCMiddleByte#m DTCLowByte#m statusOfDTC#m ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
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 (0x42) Response Message Data-Parameter of SID (0x19)

Functional Group Identifier:

The FunctionalGroupIdentifier is a single-byte value that specifies the particular functional system group associated with one or more Diagnostic Trouble Codes (DTCs). Examples of these groups include systems such as Brakes, Emissions, Occupant Restraints, Tire Inflation, and Forward/External Lighting. This identifier helps in categorizing and isolating DTCs based on the vehicle system they relate to, enabling more focused and efficient diagnostics.

DTC Status Availability Mask:

The DTCStatusAvailabilityMask is a single byte where each bit corresponds to a specific status flag defined in the statusOfDTC. This mask indicates which status bits are supported by the diagnostic server. Bits that are not supported must be set to ‘0’, while supported bits are marked with a ‘1’. Importantly, every supported status bit must be implemented consistently for all Diagnostic Trouble Codes (DTCs) that the server handles, ensuring uniform status reporting.

DTC Severity Availability Mask:

The DTCSeverityAvailabilityMask is a single byte where each bit corresponds to a specific severity level defined in the DTCSeverity. This mask indicates which severity bits the diagnostic server supports. Any bits that are not supported by the server must be set to ‘0’, ensuring clarity about the severity information available for Diagnostic Trouble Codes (DTCs).

DTC Format Identifier:

This 1-byte parameter defines the format of the DTC reported by the server:

• SAE_J2012-DA_DTCFormat_00: Identifies the DTC format as defined in the ISO 15031-6 [12] specification.
• ISO_14229-1_DTCFormat: Identifies the DTC format as defined by the DTCAndStatusRecord parameter in this table.
• SAE_J1939-73_DTCFormat: Identifies the DTC format as defined in SAE J1939-73 [19].
• ISO_11992-4_DTCFormat: Identifies the DTC format as defined in the ISO 11992-4 [5] specification.
• SAE_J2012-DA_DTCFormat_04: Identifies the DTC format as defined in the ISO 27145-2 [16] specification.

The definition of the byte values in the DTCFormatIdentifier can be found in section D.4 of this specification. Each server supports only one DTCFormatIdentifier.

DTCCount: This 2-byte parameter includes the DTCCountHighByte and DTCCountLowByte, which are sent in response to a reportNumberOfDTCByStatusMask or reportNumberOfMirrorMemoryDTC request. The DTCCount represents the number of DTCs that match the DTCStatusMask specified in the client’s request.

DTC And Severity Record:

The DTCAndSeverityRecord is a comprehensive data structure that groups together various diagnostic parameters, including DTCSeverity, DTCFunctionalUnit, and the components of the Diagnostic Trouble Code itself—namely DTCHighByte, DTCMiddleByte, and DTCLowByte. Depending on the format used, such as SAE_J2012-DA_DTCFormat_00, ISO_14229-1_DTCFormat, SAE_J1939-73_DTCFormat, ISO11992-4DTCFormat, or SAE_J2012-DA_DTCFormat_04, the record may also include the statusOfDTC or other specific identifiers.

The DTCSeverity indicates how critical the fault is to vehicle operation or system function, often guiding recommended driver actions. The DTCFunctionalUnit is a one-byte identifier that points to the basic vehicle or system function reporting the DTC. These identifiers are implementation-specific and should be defined in the applicable standard.

The combination of DTCHighByte, DTCMiddleByte, and DTCLowByte forms a unique code identifying a specific diagnostic trouble. The high and middle bytes typically denote the circuit or system under diagnosis, while the low byte specifies the fault type (for example, sensor open circuit, short to ground, or algorithm failure). These definitions are outlined in the ISO 15031-6 specification.

For the SAE_J1939-73_DTCFormat, the record includes DTCSeverity, DTCFunctionalUnit, along with SPN (Suspect Parameter Number), FMI (Failure Mode Identifier), and OC (Occurrence Counter). These elements are defined in the SAE J1939 standard and provide additional detail for fault identification and tracking.

Syntax of 0x19 SID Negative Response Message

Response Message Definition – Sub-Function = Report WWH-OBD DTC By Mask Record

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 WWH-OBD DTC By Mask Record (0x42): 0x19 Service in UDS Protocol

Following are the Examples of Report WWH-OBD DTC By Mask Record (0x42): 0x19 Service in UDS Protocol explained in detail:

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

Read DTC Information Request, Sub-function = Report Number Of DTC By Status Mask

Message direction	Client → Server
Message Type	Request
Data Byte	Description (all values are in hexadecimal)	Byte Value
#1	Read DTC Information Request SID	0x59
#2	Report Type = Report WWH-OBD DTC By Mask Record suppressPosRspMsgIndicationBit = FALSE	0x42
#3	FunctionalGroupIdentifier (FunctionalGroupIdentifier=emissions=0x33)	0x33
#4	DTCSeverityMaskRecord[] = [ DTCStatusMask ]	0x08
#5	DTCSeverityMaskRecord[] = [ DTCSeverityMask ]	0xFF

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

Read DTC Information Response, Sub-function = Report WWH-OBD DTC By Status Mask

Message direction	Server #1 → 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 WWH-OBD DTC By Mask Record	0x42
#3	FunctionalGroupIdentifier (FunctionalGroupIdentifier=emissions=0x33)	0x33
#4	DTCStatusAvailabilityMask	0xFF
#5	DTCSeverityAvailabilityMask	0xFF
#6	DTCFormatIdentifier = [SAE_J2012-DA_DTCFormat_04]	0x04
#7 #8 #9 #10 #11	DTCAndSeverityRecord[ DTCSeverity#1 ] DTCAndSeverityRecord[ DTCHighByte#1 ] DTCAndSeverityRecord[ DTCMiddleByte#1 ] DTCAndSeverityRecord[ DTCLowByte#1 ] DTCAndSeverityRecord[ statusOfDTC#1 ]	0x20 0x25 0x22 0x1F 0x2F

Message direction	Server #2 → 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 WWH-OBD DTC By Mask Record	0x42
#3	FunctionalGroupIdentifier (FunctionalGroupIdentifier=emissions=0x33)	0x33
#4	DTCStatusAvailabilityMask	0xFF
#5	DTCSeverityAvailabilityMask	0xFF
#6	DTCFormatIdentifier = [SAE_J2012-DA_DTCFormat_04]	0x04
#7 #8 #9 #10 #11	DTCAndSeverityRecord[ DTCSeverity#1 ] DTCAndSeverityRecord[ DTCHighByte#1 ] DTCAndSeverityRecord[ DTCMiddleByte#1 ] DTCAndSeverityRecord[ DTCLowByte#1 ] DTCAndSeverityRecord[ statusOfDTC#1 ]	0x20 0x02 0x35 0x12 0x2E

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

ReadDTCInformation, sub-function = Report WWH-OBD DTC By Status Mask, 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 42
Positive Response: Server --> Client
14 59 42 12 34 56 24 05 17 23 45 61 24 05 79
// Example for Negative Response for SID-0x19
Request: Client --> Server
03 19 42
Negative Response: Server --> Client
03 7F 19 13

UDS Service 0x19 over CAN (DoCAN) – Example Breakdown

The Unified Diagnostic Services (UDS) protocol allows diagnostic testers to communicate with an ECU using standard service identifiers (SIDs). Service 0x19 is used for reading Diagnostic Trouble Codes (DTCs). Below is a practical example showing how this service works over CAN (Controller Area Network) using the DoCAN protocol layer.

✅ Example 1: Positive Response for Service 0x19 (Sub-function 0x42)

This scenario shows a successful request and response where the tester queries DTCs using sub-function 0x42 – typically Report WWH-OBD DTC By Mask Record.

Request (Client → Server)

02 19 42

• 02 → Number of data bytes (excluding the PCI byte, used in ISO-TP)
• 19 → Service ID (SID) for ReadDTCInformation
• 42 → Sub-function: ReportWWHOBDDTCByMaskRecord

Positive Response (Server → Client)

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

• 14 → Total number of bytes in the payload
• 59 → Positive Response SID (0x40 + original SID 0x19)
• 42 → Echoed sub-function ID (confirms it’s a response to 0x42)
• 12 34 56 → DTC code 1 (High, Mid, Low bytes)
• 24 → Status of DTC 1 (StatusByte as per UDS spec)
• 05 17 → Additional info (e.g., occurrence counter, timestamp – format varies by implementation)
• 23 45 61 24 05 79 → More DTC records in similar format

Note: Actual interpretation of the trailing bytes depends on the ECU’s DTC format (ISO 15031-6 or OEM-specific format).

❌ Example 2: Negative Response for Service 0x19 (Sub-function 0x42)

This scenario shows a failed request where the server cannot process the request due to an issue such as unsupported sub-function, incorrect format, or invalid conditions.

Request (Client → Server)

03 19 42

• 03 → Number of data bytes
• 19 → SID: ReadDTCInformation
• 42 → Sub-function: ReportWWHOBDDTCByMaskRecord

Negative Response (Server → Client)

03 7F 19 13

• 03 → Number of bytes in the response
• 7F → Negative Response Indicator
• 19 → Original SID that caused the error
• 13 → NRC (Negative Response Code) = 0x13 (InvalidFormat)

The server is rejecting the request due to an invalid format. Possible causes include incorrect message length, unsupported parameters, or improper masking values.

Key Points:

• UDS over CAN uses service IDs and sub-functions to perform diagnostics like DTC reading.
• A positive response always has the format 0x40 + SID.
• A negative response starts with 0x7F and includes the original SID and a negative response code (NRC).
• These structured responses help ensure standardized, reliable communication between diagnostic testers and ECUs.