UDS 0x19 Service: How to Report Severity Information of DTC (0x09 Sub-function)

Hello, automotive diagnostics enthusiasts! In this blog post, I’ll guide you through Report Severity Information of DTC (0x09) in UDS – one of the crucial sub-functions

of the UDS protocol: 0x09 – Report Severity Information of DTC under Service 0x19. This function helps retrieve detailed information about the severity of Diagnostic Trouble Codes (DTCs), which is essential for fault prioritization and maintenance strategies. Understanding how severity levels are reported enables better decision-making in vehicle diagnostics and repairs. We’ll explore how this sub-function works, what data it returns, and how to implement it effectively. Whether you’re an automotive engineer, tester, or learner, this article will provide practical insights. By the end, you’ll have a clear grasp of how to use 0x09 to its full potential. Let’s dive in!

Introduction to UDS 0x19 Service: Report Severity Information of DTC (0x09 Sub-function)

Hello, automotive diagnostics professionals and enthusiasts! In this blog post, we’ll explore one of the key sub-functions of the UDS protocol: 0x09 – Report Severity Information of DTC, which is part of Service 0x19 (ReadDTCInformation). This sub-function plays an essential role in determining how critical a specific Diagnostic Trouble Code (DTC) is for vehicle safety or emissions. By understanding and implementing this feature, diagnostic tools can prioritize faults more effectively and offer better insights for repair decisions. We’ll cover the purpose of this sub-function, its data structure, and how to request and interpret the response. Whether you’re developing a diagnostic tool or studying UDS, this article will provide practical knowledge. Let’s dive into the details of how severity levels are reported in modern vehicles!

What is ‘Report Severity Information of DTC’ (0x09) in UDS 0x19 Service?

In the UDS (Unified Diagnostic Services) protocol, Service 0x19 called ReadDTCInformation is used to retrieve information about Diagnostic Trouble Codes (DTCs) stored in a vehicle’s ECU (Electronic Control Unit). These codes indicate faults or malfunctions in the system.

Among several sub-functions under 0x19, the sub-function 0x09 is known as:

Report Severity Information of DTC

This specific sub-function is used to obtain additional information about the severity and status of a particular DTC. In other words, it helps to classify the importance of a fault whether it’s critical, non-critical, emissions-related, safety-related, etc.

Why do we need ‘Report Severity Information of DTC’ (0x09) in UDS 0x19 Service?

We need the ‘Report Severity Information of DTC’ (0x09) sub-function in the UDS 0x19 Service because it provides critical context about how serious a diagnostic trouble code (DTC) is, beyond just knowing that a fault occurred.

Here’s a detailed breakdown of why it’s needed:

1. Prioritize Repairs Based on Criticality

Not every Diagnostic Trouble Code (DTC) indicates a severe issue. Some faults may be minor and not require immediate action, while others could threaten vehicle safety or cause emissions failures. The 0x09 sub-function helps identify the severity of each DTC. This enables technicians to handle urgent problems first, ensuring that the most critical faults are addressed without delay. It helps prevent serious issues from being overlooked during vehicle servicing.

2. Improve Service Efficiency

By knowing the severity of each DTC, diagnostic tools and service personnel can streamline the repair process. Faults can be sorted automatically so that time isn’t wasted on minor problems when major ones exist. This structured approach boosts productivity and reduces turnaround time in service centers. It also improves customer satisfaction by resolving the most impactful problems quickly. Overall, it leads to smarter and faster diagnostics.

3. Support Regulatory Compliance

Vehicles must comply with various emission and safety regulations depending on the region. A DTC linked to emission or safety compliance must be addressed immediately to avoid penalties or legal issues. The severity information from sub-function 0x09 helps identify such DTCs automatically. This ensures that diagnostic systems can flag compliance-related issues. It plays a critical role in supporting legal and environmental obligations.

4. Enhance Automated Diagnostic Tools

Modern diagnostic tools use automation and intelligent algorithms to manage and interpret DTCs. Severity data gives these tools the ability to make informed decisions without manual input. For example, they can automatically trigger alerts or generate reports based on fault criticality. This leads to quicker and more accurate diagnostics. It also allows integration with fleet management systems and remote diagnostics.

5. Differentiate Between Similar DTCs

Sometimes multiple DTCs might seem related or result from the same issue. However, not all of them carry the same level of urgency or impact. The 0x09 sub-function helps diagnostic systems determine which fault should be prioritized. This avoids misdiagnosis or wasting time on less severe issues. As a result, repair strategies become more accurate and efficient.

6. Enable Predictive Maintenance

When severity information is logged over time, it helps in tracking the health of various components. If a particular component shows recurring critical severity, predictive maintenance can be scheduled before it fails. This minimizes unexpected breakdowns and improves vehicle uptime. The 0x09 data plays a valuable role in enabling such proactive servicing.

7. Inform Functional Unit Mapping

The 0x09 response may also include a Functional Unit byte, which tells you which system (e.g., chassis, powertrain, body) the DTC belongs to. Combined with severity data, this helps narrow down the source of the problem faster. It eliminates guesswork during diagnostics and allows technicians to focus on specific ECUs or vehicle subsystems. This reduces repair time and increases accuracy.

‘Report Severity Information of DTC’ (0x09) in UDS 0x19 Service

A client can request the Report Severity Information of DTC (0x09) sub-function by sending a service request that includes a specific DTCMaskRecord. This record contains the full Diagnostic Trouble Code (DTC) value comprising the high, middle, and low bytes. Upon receiving this request, the server scans its list of supported DTCs to find an exact match with the provided DTC. If a match is found, the server responds with both the severity level and the associated functional unit information for that particular DTC, enabling precise fault analysis.

Syntax of ‘Report Severity Information of DTC’ (SBFID-0x09) of SID-0x19

Request Message Definition – Sub-function = Report Severity Information of DTC

Syntax of Request Message Frame Format:

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type =                             Report Severity Information of DTC ]	0x09
#3 #4 #5	DTCMaskRecord[] = [ DTCHighByte DTCMiddleByte DTCLowByte ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF

Syntax of 0x19 SID Positive Response Message

Response Message Definition – Sub-function = Report Severity Information of DTC

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
# 2	Report Type = [                               Report Severity Information of DTC ]	0x09
#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 OfDTC#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
C1: In case of reportDTCBySeverityMaskRecord this parameter has to be present if at least one DTC matches the client defined DTC severity mask. In case of reportSeverityInformationOfDTC this parameter has to be present if the server supports the DTC specified in the request message. C2: This parameter record is only present if reportType = reportDTCBySeverityMaskRecord. It has to be present if more than one DTC matches the client defined DTC severity mask.

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

DTCAndSeverityRecord Explained in UDS 0x19 Service

The DTCAndSeverityRecord is a structured response format used in the UDS 0x19 service that provides detailed information about Diagnostic Trouble Codes (DTCs). This record consists of multiple data fields grouped together to convey critical diagnostic details, depending on the DTC format in use.

For standard formats such as SAE J2012-DA DTCFormat_00, ISO 14229-1 DTCFormat, SAE J1939-73 DTCFormat, ISO 11992-4, or SAE J2012-DA DTCFormat_04, the record typically includes:

• DTCSeverity: Indicates how serious or critical a particular DTC is with respect to the vehicle’s performance or safety. It helps prioritize faults and may guide drivers with recommended actions. Detailed severity definitions are provided in section D.3 of the specification.
• DTCFunctionalUnit: This is a 1-byte value representing the core system or function in the vehicle that reports the DTC (e.g., powertrain, braking, or emission systems). Its value and meaning are defined specifically by the vehicle manufacturer or supplier.
• DTCHighByte, DTCMiddleByte, and DTCLowByte: These three fields together uniquely identify a DTC. The high and middle bytes generally point to the subsystem or circuit being diagnosed, while the low byte indicates the specific nature of the issue such as a short circuit, sensor fault, or logic-based error. These values follow the DTC structure as outlined in ISO 15031-6.

In the case of the SAE J1939-73 format, the record may instead include:

• SPN (Suspect Parameter Number): Identifies the specific component or system parameter involved.
• FMI (Failure Mode Identifier): Describes the nature of the failure (e.g., voltage too high, data error).
• OC (Occurrence Counter): Tracks how many times the issue has occurred.

This flexible structure ensures that diagnostic tools receive all relevant data necessary for accurate fault identification, prioritization, and vehicle maintenance planning.

Syntax of 0x19 SID Negative Response Message

Response Message Definition – Sub-function = Report Severity Information of DTC

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 Severity Information of DTC’ (0x09) in UDS 0x19 Service

Here are the Examples of ‘Report Severity Information of DTC’ (0x09) in UDS 0x19 Service:

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

Read DTC Information, Sub-function = Report Severity Information of DTC,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 Severity Information of DTC,                  Suppress Pos Rsp Msg Indication Bit = FALSE	0x09
#3	DTC Mask Record [ DTC High Byte ]	0x08
#4	DTC Mask Record [ DTC Middle Byte ]	0x05
#5	DTC Mask Record [ DTC Low Byte ]	0x11

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

Read DTC Information, Sub-function = Report Severity Information of DTC, 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 Severity Information of DTC	0x09
#3	DTC Status Availability Mask	0x7F
#4	DTCSeverityRecord#1 [ DTCSeverity ]	0x40
#5	DTCSeverityRecord#1 [ DTCFunctionalUnit ]	0x10
#6	DTCSeverityRecord#1 [ DTCHighByte ]	0x08
#7	DTCSeverityRecord#1 [ DTCMiddleByte ]	0x05
#8	DTCSeverityRecord#1 [ DTCLowByte ]	0x11
#9	DTCSeverityRecord#1 [ StatusofDTC ]	0x2F

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

Read DTC Information, Sub-function = Report Severity Information of DTC, Negative 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 [ 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 09
Positive Response: Server --> Client
09 59 09 7F 40 10 08 05 11 2F
// Example for Negative Response for SID-0x19
Request: Client --> Server
01 19 09
Negative Response: Server --> Client
03 7F 19 13

Understanding UDS 0x19 (Report Severity Information of DTC) over CAN: Positive and Negative Response Example

When working with UDS (Unified Diagnostic Services) over CAN (Controller Area Network) known as DoCAN data is exchanged in the form of service identifiers (SIDs) and sub-functions, using specific CAN data formats.

Below is a step-by-step explanation of a client-server communication using Service 0x19 (Read DTC Information) with Sub-function 0x09 (Report Severity Information of DTC).

✅ Positive Response Example

Client Request:

Client → Server: 02 19 09

Breakdown:

• 02: Indicates the number of additional data bytes (2 bytes follow).
• 19: This is the Service ID (SID) for Read DTC Information.
• 09: This is the Sub-function ID for Report Severity Information of DTC.

Server Response:

Server → Client: 09 59 09 7F 40 10 08 05 11 2F

Breakdown:

• 09: Number of bytes in the response.
• 59: Positive response to 0x19 (0x19 + 0x40 = 0x59).
• 09: Echo of sub-function 0x09.
• 7F 40 10: First DTC that failed its test.
• 08 05 11: Possibly another DTC.
• 2F: Part of DTC or padding (depending on the OEM structure).

Each DTC is usually 3 bytes long, following the ISO 14229 standard or a custom format by the OEM. The presence of multiple DTCs might vary depending on the vehicle manufacturer.

This response is crucial for identifying the first anomaly that occurred during ECU operation—valuable for both debugging and aftersales diagnostics.

❌ Negative Response Example

Client Request:

Client → Server: 01 19 09

Breakdown:

• 01: Only 1 byte of data follows (sub-function).
• 19: Service ID (Read DTC Information).
• 09: Sub-function ID (Report Severity Information of DTC).

Server Response:

Server → Client: 03 7F 19 13

Breakdown:

• 03: Indicates that 3 data bytes follow.
• 7F: Standard identifier for negative response.
• 19: Echoes the service ID where the error occurred.
• 13: Negative Response Code (NRC) – here, 0x13 means “Invalid Format”.

This tells us that the server could not process the request due to an issue with how the request was formatted possibly the data length, missing parameters, or incorrect structure.

Summary from the Example:

Term	Meaning
SID (0x19)	Service ID for reading DTCs
Sub-function (0x09)	Requests severity and functional unit info
Positive Response (0x59)	Indicates the request was processed successfully
Negative Response (0x7F)	Indicates an error occurred
NRC 0x13	“Incorrect message length or format”