Read DTC Information Service (0x19) – UDS Protocol

Need Of 0x19 Service In UDS Protocol

The read DTC information service in UDS protocol to read the DTC’s from a vehicle or from a particular ECU or node. One of the major of the UDS protocol is fault diagnostics. Whenever any fault occurs in the vehicle, a diagnostic trouble code (DTC) corresponding to the fault is stored in the ECU fault code memory (FCM). The diagnostic service engineer can retrieve these DTCs by using the Read DTC Information (0x19) service.

The Fault Diagnostics service allows the client to read both the emissions related or non-emission related DTC information. The client can define a status mask based on which the DTC information will be displayed.

Except for DTC, to do more diagnostic which will help the diagnostic engineer to solve the problem, snapshot data also stored in the NVM. The DTC Snapshot data gives additional information about the engine’s parameters during the occurrence of the fault.

Read DTC Information Applications

This Read DTC Information service is the heart of UDS protocol. Mostly, this service is being used by developers, testers, system engineers, service engineers, etc.

Read DTC Information DTC Properties

The main purpose of the Read DTC Information service is to read the DTC and its related data from the server. The Diagnostic Trouble codes are defined in two ways. One is defined by the ISO standard and the other is by the OEM. To know more about it, please follow our ISO 15031 Tutorial. At last, all the DTC numbers are predefined inside the ECU Flash Fault or error memory.

But when this DTC should set, when it should clear, or when it should mature so that we can say that yes it is a proper fault. It is nothing like you should say that if any short circuit happened that is a fault and the DTC should log. There are a lot of test scenarios defined by the Server or vehicle manufacturer or system supplier specific conditions, that define, whether a system being diagnosed is functioning properly within normal, acceptable operating ranges or not. That means there are no failures exist and the diagnosed system is correct.

So to ensure that the fault is 100% happening by running the particular test programs written for that test or DTC. There are multiple test criteria’s that can ensure a definite fault are defined below. So let us go to discuss that and then we will go one by one Read DTC Information 0x19 service sub-functions.

Fault Enable Criteria:

Every ECU is having inbuilt fault test programs that return the test results. It might be ‘PASS’ or ‘FAIL’ as per test results. there will be a lot of test programs implemented for each fault. But it is nothing like all the test programs will be running after ECU gets powered or the main program starts running.

So there multiple specific criteria on which that particular test program should run to check for a diagnostic fault. This will help in the reduction of Microcontroller program execution overloading. It also helps to detect a particular fault at that time only when it is really required as per the system requirement.

We can say that the Server or vehicle manufacturer or system supplier specific criteria used to control when the server actually performs a particular internal diagnostic. If the fault is enabled, then we can read the DTC by using the Read DTC Information 0x19 service.

Test Pass Criteria:

Now we are concluded that when the test programs will be running for a particular fault. We are sure that the test program will run. But we should know when that fault should pass or fail. That means what are the conditions under which we can say that fault is happening and we need to fix this issue, then only that DTC should log, otherwise it should not log. That means the fault is happening but it is not confirmed. If you want to read the unconfirmed DTC, yes you can read by using the Read DTC Information 0x19 service with 0x04 status byte.

Let me explain you with a best example. suppose your vehicle is not starting. you are checking something like battery. suppose by mistake you shorted the battery terminals by using your screw driver or anything. Later you removed it.

So do you think that it is a fault and you need to fix it? No right because it happened unwantedly. But when the real short will happen inside the vehicle and it is not recovering from that, then only you need to log the DTC.

So for each DTC, there will be diagnostic test programs. Each test will be having its own specific test pass conditions. These criteria defined by the Server or vehicle manufacturer or system supplier. So it defines whether a system being diagnosed is functioning properly within normal, acceptable operating ranges or not.

Test Failure Criteria:

I hope you understood from the above description that the test conditions for a particular diagnostic test. Then like the pass conditions, there will be multiple conditions for which the test program should take a decision that it is failing. The Server or vehicle manufacturer or system supplier specific failure conditions that define, whether a system being diagnosed has failed the test or not.

Confirmed Fault Failure Criteria:

Now the question is again what is confirmed fault? Yes, I have already explained it right. Fault can happen and it might not be confirmed fault. But it might not occur concurrently. Since it is happening in between the different conditions, we should check and fix it before it logged which might be cost more money. So to handle all these, we have a DTC status byte where it stores for each test condition.

Each test is having its own conditions to confirm a fault. This is also called matured DTC. so there are different operation cycles after which a definite fault will mature. So that this DTC will store all the dependency data like status byte, snapshot record, Extended data record, etc. into the permanent memory of the microcontroller. It can be used in the later future whenever you want or in the service center.

Fault Occurrence Counter:

In every ECU, there will be test programs that will run periodically as per system requirements. But to make a confirmed fault, it will be having a number of operation cycles. Each operation cycle will be having a fault counter. This fault counter will count one when a fault occurs for a number of instances. So that by which a given DTC test reported a unique occurrence of a test failure. The Read DTC Information 0x19 service can be used to read this counter value.

Fault Aging Counter

The aging counter defines the age of a fault or DTC. Let me explain to you how age helping in DTC. How a human is having some age and after this age, we are all dying. In the case of machine or Automotive ECU also, they have an age for each DTC defined by the system engineers. So every ECU or server is having an array of aging counter that stores the age value of each fault or DTC. Each ECU or server is having a process. By using this process, the server can count the age of a DTC and store it in an aging counter. It can also increase or decrease by using the Count-In step and Count-Out step method. You can also read the counter value using the Read DTC Information service.

DTC Aging

The aging in DTC is a process by which a certain ECU evaluates the past results of each internal diagnostic to determine if a confirmed DTC can be cleared from Non-Volatile Memory (NVM). That means after how many numbers of failure-free cycles, a DCT can be cleared. So the Read DTC Information service can read only the DTC that is not cleared.

Read DTC Information Service Sub-Functions List

This article only describes how the Read DTC information or 0x19 service identifier works. But to learn or understand deeply about each sub-functions, you need to check the below links. Each link defines a particular sub-functions from basic to deep with frame format.

I hope you are understanding the time is taking to think, research, arrange documents, and write. So it might take some time, but don’t worry I will update you. You will get it here with all the links one by one when I will complete each sub-functions.