UDS 0x19 Service: Report Number of DTC by Severity Mask (0x07) Explained with Examples

Hello, automotive diagnostics enthusiasts! In this blog post, Report Number of DTC By Severity Mask Record (0x07) in

el="noreferrer noopener">UDS. I’ll introduce you to one of the key sub-functions of the UDS protocol: Report Number of DTC by Severity Mask (0x07) under service 0x19. This powerful diagnostic feature allows you to query how many Diagnostic Trouble Codes (DTCs) are active based on their severity levels. It plays a vital role in prioritizing faults and improving system reliability. In this article, I’ll walk you through what this sub-function does, how it’s structured, and how it’s used in real-world ECUs. We’ll also cover request/response formats and examples to help you understand it clearly. By the end of this post, you’ll have a solid grasp of this UDS function and its practical applications. Let’s dive into the world of diagnostic services!

Introduction to ‘Report Number of DTC by Severity Mask’ (0x07): 0x19 Service in UDS Protocol

Welcome to this deep dive into the UDS (Unified Diagnostic Services) protocol! In this post, we’ll explore the sub-function 0x07 – Report Number of DTC by Severity Mask, which is part of the 0x19 (ReadDTCInformation) service. This sub-function is essential for filtering and counting Diagnostic Trouble Codes (DTCs) based on their severity levels. It helps diagnostic tools and ECUs prioritize faults that are more critical to vehicle safety or emissions. We’ll break down how the request and response messages are structured, how the severity mask is used, and what each field means. With real-world examples and use cases, you’ll gain a solid understanding of this UDS service. Whether you’re a beginner or a professional, this guide will make this topic easier to grasp. Let’s get started!

What is ‘Report Number of DTC by Severity Mask’ (0x07) in UDS 0x19 Diagnostic Service?

In the Unified Diagnostic Services (UDS) protocol, the 0x19 service is called ReadDTCInformation. This service is responsible for retrieving Diagnostic Trouble Code (DTC) information from a vehicle’s Electronic Control Unit (ECU). One of the sub-functions of this service is 0x07, known as “Report Number of DTC by Severity Mask”.

This specific sub-function allows a diagnostic tester (like a scan tool) to query the number of stored DTCs based on their severity levels. Instead of retrieving full DTC details, this sub-function provides a count of how many DTCs meet specific severity conditions. This helps in prioritizing critical faults quickly, such as those affecting emissions, safety, or vehicle performance.

Severity Mask Concept:

The Severity Mask is a 1-byte value where each bit represents a different severity level. The tester sets the mask bits to 1 for the severities it wants to count.

Bit Position	Severity Level
0	Emission-related DTCs stored
1	Emission-related DTCs pending
2	Critical malfunction (e.g., safety-related)
3	Non-critical malfunction
4–7	Reserved or OEM-defined

For example, if you set the mask to 0x05 (binary 00000101), the ECU will count DTCs that are either emission-related (stored) or critical.

Why do we need ‘Report Number of DTC by Severity Mask’ (0x07) in UDS 0x19 Diagnostic Service?

The automotive diagnostic process involves not just detecting faults but also prioritizing them based on how critical they are to vehicle performance, safety, and environmental compliance. That’s where sub-function 0x07 – Report Number of DTC by Severity Mask – comes into play. It allows diagnostic tools to efficiently count the number of Diagnostic Trouble Codes (DTCs) that meet specific severity levels without retrieving the full DTC details.

Here are the key reasons why this sub-function is essential:

1. Fault Prioritization

Not every Diagnostic Trouble Code (DTC) is equally important. Some may indicate minor sensor glitches, while others could be critical safety or emission-related issues. The ‘Report Number of DTC by Severity Mask’ (0x07) helps separate the serious faults from the less important ones by returning a count of DTCs that match a specific severity level. This enables technicians and diagnostic tools to focus only on the most critical faults first. Prioritizing these codes leads to faster repairs and reduces the risk of overlooking dangerous issues. It enhances the overall reliability and safety of the vehicle.

2. Data Efficiency

In a typical diagnostic session, retrieving all stored DTCs and analyzing them for severity can be data-heavy, especially on limited-bandwidth networks like CAN. The 0x07 sub-function improves efficiency by sending just a count of the relevant DTCs instead of the full fault data. This reduces unnecessary traffic on the network and allows faster communication between the diagnostic tester and the ECU. It’s especially useful in embedded systems where communication time and bandwidth are constrained. Overall, it leads to a more responsive and optimized diagnostic process.

3. Pre-Screening Before Full Diagnostic Readout

Before performing a complete fault memory readout, diagnostic tools can use the 0x07 function to check if any critical DTCs are stored. If the returned count is zero, a full readout may not be necessary, saving time and system resources. This pre-screening method is efficient during periodic vehicle inspections or automated health checks. It also helps in large systems with many control units, where accessing each ECU’s full DTC list can be time-consuming. Thus, it adds intelligence and speed to the diagnostic workflow.

4. Regulatory Compliance

Emission regulations often require that vehicles report any emission-related DTCs for environmental monitoring. Using 0x07, the tester can request a count of only those DTCs that are marked as emission-relevant based on the severity mask. This function allows quick validation without needing to extract every fault code. It supports faster and more automated compliance checks, especially during inspection and maintenance (I/M) tests. Automotive manufacturers and test centers rely on this for ensuring vehicles meet emission standards at all times.

5. Support for Remote Diagnostics and Telematics

In connected vehicles or remote diagnostics systems, sending all DTCs over cellular networks may not be practical due to data costs and bandwidth limits. Sub-function 0x07 allows these systems to transmit just a summary the number of high-severity faults saving both time and data. It’s ideal for use in fleet telematics, remote monitoring apps, or emergency alert systems. This function supports proactive fault detection even when full diagnostic data is not feasible to send. As a result, it helps enable smarter remote maintenance strategies.

6. Efficient Fleet Management

Fleet operators manage dozens or hundreds of vehicles, and diagnosing each one manually is not scalable. The 0x07 function can be used to monitor the number of severe DTCs in each vehicle quickly and automatically. This enables them to prioritize maintenance schedules, arrange repairs, and prevent unplanned breakdowns. It also reduces downtime and increases vehicle availability. Over time, this leads to improved fleet performance, lower maintenance costs, and higher customer satisfaction. It’s a vital tool in modern fleet health monitoring.

7. Enhanced User Experience

Modern ECUs and dashboards are designed to keep the driver informed but not overwhelmed. Instead of showing all stored DTCs, the system may internally use 0x07 to decide whether to display a warning light based on the severity of the issues. This ensures that only truly important alerts are shown, improving driver awareness without causing unnecessary concern. It creates a smarter alert system that filters out non-critical issues. This not only enhances safety but also improves the driving experience by reducing false alarms.

Report Number of DTC By Severity Mask Record (0x07): 0x19 SID in UDS Protocol

When a client wants to know the count of Diagnostic Trouble Codes (DTCs) that match a specific severity status mask, they can send a request to the server with the sub-function set to reportNumberOfDTCBySeverityMaskRecord. In response, the server will evaluate all the supported DTCs and perform a bit-wise logical AND operation between the client’s specified mask and the actual DTC data. This operation checks both the status of the DTC and the severity of the DTC, ensuring that only those codes that match both criteria are counted.

The operation follows this formula:

(((statusOfDTC & DTCStatusMask) != 0) && ((severity & DTCSeverityMask) != 0)) == TRUE

For every DTC that meets this condition, the server will increment a counter. It’s important to note that if the client includes mask bits that the server does not support, the server will ignore those bits and only apply the supported ones during the evaluation.

After reviewing all supported DTCs, the server sends back a response to the client containing the DTCStatusAvailabilityMask and a two-byte count representing the number of DTCs that met the specified criteria. If no DTCs match the client’s request, the server will return a count of 0.

This count reflects the number of DTCs matching the severity and status mask at the exact moment the request is made. However, it is important to understand that this count does not correspond to the full list of DTCs that would be retrieved through other methods, like the reportDTCByStatusMask sub-function, which is performed at a different point in time.

Syntax of Report Number of DTC By Severity Mask Record (SBFID-0x07) of SID-0x19

This parameter indicates that the server will send the client the count of DTCs that match the severity mask record defined by the client.

Request Message definition – Sub-function = Report Number of DTC By Severity Mask Record

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type =                             Report Number Of DTC By Severity Mask Record ]	0x07
#3 #4	DTCSeverityMaskRecord[] = [ DTCSeverityMask DTCStatusMask ]	0x00 – 0xFF 0x00 – 0xFF

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

DTCFormatIdentifier: 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.

Syntax of 0x19 SID Positive Response Message

Response Message definition – Sub-function = Report Number of DTC By Severity Mask Record

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
#2	report Type =                 Report Number of DTC By Severity Mask Record	0x07
#3	DTC Status Availability Mask	0x00 – 0xFF
#4	DTC Format Identifier = [                                             SAE_J2012-DA_DTCFormat_00 ISO_14229-1_DTCFormat SAE_J1939-73_DTCFormat                                            ISO_14229-1_DTCFormat SAE_J2012-DA_DTCFormat_04 ]	0x00 0x01 0x02 0x03 0x04
#5 #6	DTC Count[] = [                               DTC Count High Byte                               DTC Count Low Byte ]	0x00 – 0xFF 0x00 – 0xFF

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

DTCAndSeverityRecord

This parameter record includes fields like DTCSeverity, DTCFunctionalUnit, DTCHighByte, DTCMiddleByte, DTCLowByte, and statusOfDTC, depending on the DTC format used (e.g., ISO 14229-1, SAE J2012-DA, or SAE J1939-73). DTCSeverity indicates how critical a fault is and helps in deciding what action or warning to show the driver. DTCFunctionalUnit identifies the system or component reporting the fault and is defined by the vehicle manufacturer.

The combination of DTCHighByte, DTCMiddleByte, and DTCLowByte uniquely identifies a DTC. The first two bytes show the affected system, and the last byte defines the fault type. In SAE J1939-73 format, this record may also include SPN, FMI, and OC, which provide detailed fault information as per SAE J1939 standards.

DTCRecord

This parameter record consists of one or more sets of DTCHighByte, DTCMiddleByte, and DTCLowByte. The interpretation of each DTC record depends on the DTCFormatIdentifier value.

Syntax of 0x19 SID Negative Response Message

Response Message definition – Sub-function = Report Number of DTC By Severity 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 Number of DTC by Severity Mask’ (0x07) in UDS 0x19 Diagnostic Service

Here are the Examples of ‘Report Number of DTC by Severity Mask’ (0x07) in UDS 0x19 Diagnostic Service:

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

Read DTC Information, Sub-function = Report Number of DTC By Severity Mask Record, 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 Number Of DTC By Severity Mask Record,                  Suppress Pos Rsp Msg Indication Bit = FALSE	0x07
#3	DTC Severity Mask Record (DTCSeverityMask)	0xC0
#4	DTC Severity Mask Record (DTCStatusMask)	0x01

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

Read DTC Information, Sub-function = Report Number of DTC By Severity Mask Record, 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 Number of DTC By Severity Mask Record	0x07
#3	DTC Status Availability Mask	0x09
#4	DTC Format Identifier = ISO_14229-1_DTC Format	0x01
#5	DTC Count [ DTC Count High Byte ]	0x00
#6	DTC Count [ DTC Count Low Byte ]	0x01

Example of Negative Response Message Frame Format of SBFID-0x07 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 07
Positive Response: Server --> Client
06 59 07 09 01 00 01
// Example for Negative Response for SID-0x19
Request: Client --> Server
03 19 07
Negative Response: Server --> Client
03 7F 19 13

Example: UDS Commands for Report Number of DTC by Severity Mask (0x07) – Service 0x19

The following example demonstrates how the UDS (Unified Diagnostic Services) command for the 0x19 service is used to report the number of DTCs (Diagnostic Trouble Codes) that match a specific severity mask. These messages are sent and received via the CAN protocol, typically over the CAN data field.

✅ 1. Positive Response Example for SID 0x19, Sub-function 0x07

Request (Client → Server):

02 19 07

• 02: Indicates the length of the message (2 bytes following this).
• 19: Service Identifier (SID) for “Read DTC Information”.
• 07: Sub-function code for ReportNumberOfDTCBySeverityMaskRecord.

Response (Server → Client):

06 59 07 09 01 00 01

Breakdown:

• 06: Length of original request echoed back.
• 59: Positive response to Service 0x19 (i.e., 0x19 + 0x40 = 0x59).
• 07: Same sub-function echoed.
• 09: DTCStatusAvailabilityMask – tells which status bits are supported by the server.
• 01 00: The 2-byte count of DTCs matching the severity mask (in this case, 0x0100 = 256 DTCs).
• 01: May indicate additional info (e.g., padding or format-specific data depending on implementation).

This positive response confirms that the server successfully processed the request and found 256 matching DTCs.

❌ 2. Negative Response Example for SID 0x19, Sub-function 0x07

Request (Client → Server):

03 19 07

• 03: Indicates the length of the message.
• 19: Service Identifier for Read DTC Information.
• 07: Sub-function code.

Response (Server → Client):

03 7F 19 13

Breakdown:

• 03: Message length.
• 7F: Standard Negative Response Code indicator.
• 19: Indicates the request failed for service 0x19.
• 13: NRC (Negative Response Code) = 0x13, which means “Invalid Format”.

This negative response tells the client that the request format was incorrect or not supported by the server at that time.

These examples help diagnose the correct operation of the UDS service 0x19 with sub-function 0x07. They are useful for validating communication between ECUs and diagnostic tools during vehicle troubleshooting or diagnostics development.