Table of contents
- Introduction To Report DTC By Status Mask Sub-Function Of 0x19 Service
- Report DTC By Status Mask (0x02) Request Frame Format
- Example Of Report DTC By Status Mask (0x02) Request Frame Format
- Example Of Report DTC By Status Mask (0x02) Positive Response Frame Format
- Example Of Report DTC By Status Mask (0x02) Negative Response Frame Format
- Supported NRC for 0x19 Service In UDS Protocol
Introduction To Report DTC By Status Mask Sub-Function Of 0x19 Service
The Report DTC by Status Mask is a sub-function in the Rea
d DTC information (0x19) Service. It is used to retrieve the list of DTC with the client-defined status mask from the server. In this article, you need to understand the status mask very well, or else it will be very difficult for you to understand it. So I would like to request you that before going forward, if you have any doubt, please select the links I have given below and learn them and then come to this article for further study. This sub-function (0x02) Identifier of 0x19 service is used in most of the places for vehicle diagnostic. Because the most two important data that is DTC value and status is available in this sub-function. So anyone can retrieve that for any kind of common fault in an automotive vehicle. So I would like to suggest to everyone having this knowledge. If you are an Automotive Embedded Software developer, or tester, or client-side engineer for the new feature, then you need to know this. So why should wait? let us start our discussion on how to read DTC by status mask.Client Defined Status Mask In 0x19 Service
The client-defined status mask means the client will define a status byte. This status byte data will send to the server in the request message. To get this done, the server will perform a bit-wise logical “AND” operation. This will be in between the status mask byte sent by the client & the status mask byte available in ECU for all the DTC. Then the server will check and compare this status byte with all the DTC status byte available in ECU. If the DTC status bytes will be matching with the client sent status byte, the server or ECU will send all these DTC with their status byte.
Report DTC By Status Mask (0x02) Request Frame Format
I hope you understood the basic requirement with functionality how it is working. So now let us discuss the request frame details for how to send it. It will help you if you are implementing this sub-function or testing it in your project. Please check the below table for the frame format syntax of Report DTC By Status Mask (0x02).
Byte No. | Parameter Name | Byte Value |
---|---|---|
#1 | ReadDTCInformation Request SID | 0x19 |
#2 | ReportDTCByStatusMask | 0x02 |
#3 | DTCStatusMask | 0x00 – 0xFF |
There are 3 bytes in this request frame format, so it will be having single frame. So now let us discuss what are these 3 bytes.
ReadDTCInformation Request SID In Report DTC By Status Mask (0x02)
This is the first byte of Report DTC By Status Mask (0x02) Request Frame. So this is the Service Identifier 0x19 in UDS Protocol defined in ISO 14229 standard.
ReportDTCByStatusMask In Report DTC By Status Mask (0x02)
This parameter is the second byte of the 0x19 service. This byte is nothing but the Report DTC By Status Mask (0x02) sub-function. We are now discussing this sub-function. When you want to read all the DTC lists as per the client-defined status mask, then we will use this sub-function ID.
DTCStatusMask In Report DTC By Status Mask (0x02)
This is the third byte of the 0x19 service. This byte basically selected by the client or tester. The selection of this byte is depending on our requirement. Suppose a vehicle came for service to your service center. You are gonna service it. Then you can use this 0x02 sub-function to read all the DTC lists with the help of DTCStatusMask byte selection.
Example Of Report DTC By Status Mask (0x02) Request Frame Format
Suppose you are the diagnostic service engineer. You are gonna service a vehicle. you need to know what are DTC’s are there. So suppose you need to fix all the Confirmed DTC. That means you need to fix all the faults that are confirmed. If you are new to the DTC status byte, please go through our Fault Code Status Byte Tutorial.
Then you need to mask the third bit of the “DTCStatusMask” parameter in the request frame as shown below. So the third bit should be high (0 0 0 0 1 0 0 0), and in Hexadecimal it is 0x08. So the “DTCStatusMask” parameter value should be 0x08 as shown in the below request frame format.
RDTCI | RDTCBSM | DTCSM |
---|---|---|
19 | 02 | 08 |
- RDTCI (0x19): Read DTC Information Request Service Identifier of the UDS Protocol.
- RDTCBSM (0x02): Report DTC By Status Mask is the sub-function Identifier of 0x19 service.
- DTCSM (0x08): DTC Status Mask is the client request parameter to read the DTC’s whose status byte will be masked that was requested by the client “DTCStatusMask” parameter.
Example Of Report DTC By Status Mask (0x02) Positive Response Frame Format
Suppose, the request frame successfully completed the verification and validation by the server. Then it will process the service and send the positive response message with the requested data record. So let us take 4 DTC for our example to make you better understand. These are the DTC’s that are available with the below status bytes.
- 1st DTC (P0B79-11): The DTC is P0B79 with the fault code 0x11. So the DTC value will be 0x0B7911. Let us consider the status byte of DTC (0x0B791F) is 0x0F.
- 2nd DTC (P0A05-12): It is P0A05 having Fault code 0x12, so the DTC value is 0x0A0512. Let us consider the status byte of DTC (0x0B7912) is 0x1F.
- 3rd DTC (B0A5B-13): The DTC is B0A5B with fault code 0x13 with the DTC value is 0x0A5B13. Its status byte is 0xF1
- 4th DTC (P2522-14): DTC is 2522 with fault code 0x14 having DTC value is 0x252214. It is a status byte is having 0xF2.
So let us see how the response is sent by the server or ECU to the client in the below table. If you can look onto the above 4 DTC’s, the first and second DTC status byte 3rd bit nothing but the confirmed DTC bit is masked or you can say high. Since the client requested a DTC status mask is matching with these, both the DTC is sending by the server to the client in the response frame of Report DTC By Status Mask (0x02). Whereas in the case of the 3rd & 4th DTC, the 4th bit of the status byte is not masked, so they were not added in the response frame.
RDTCIPR | RDTCBSM | DTCSAM | DTC1HB | DTC1MB | DTC1LB | SODTC1 | DTC2HB | DTC2MB | DTC2LB | SODTC2 |
---|---|---|---|---|---|---|---|---|---|---|
59 | 02 | 7F | 0B | 79 | 1F | 0F | 0A | 05 | 12 | 1F |
I hope now you understood the positive response frame format with how the status byte is working. Now let us discuss about the each data bytes with details.
- RDTCIPR(0x59): Read DTC Information Positive Response Service Identifier.
- RDTCBSM(0x02): Report DTC By Status Mask sub-function identifier.
- DTCSAM(0x7F): DTC Status Availability Mask is nothing but the supported DTC status bytes for this ECU. To learn more about this parameter please select this link DTCStatusAvailabilityMask.
- [DTC1HB DTC1MB DTC1LB](0x0B791F): This is a 3 byte DTC-1 sent by the server to the client since its status byte matched with the client-defined “DTCStatusMask” (0x0F) sent in the request frame.
- SODTC1(0x0F): Status Of DTC (0x0B791F) value is 0x0F.
- [DTC2HB DTC2MB DTC2LB](0x0B7912): This DTC-2 is also having a status byte with the client-defined “DTCStatusMask” (0x1F) sent in the request frame format.
- SODTC2(0x1F): Status Of DTC (0x0B7912) value is 0x1F.
Example Of Report DTC By Status Mask (0x02) Negative Response Frame Format
If the client requests a message with any problem or does not follow any standard as per ISO 14229, the server will revert the negative response message with NRC.
NRSID | RFTSID | NRC |
---|---|---|
7F | 19 | 12 |
Supported NRC for 0x19 Service In UDS Protocol
NRC Value | NRC Parameter Name | NRC Description |
---|---|---|
0x12 | SubFunctionNotSupported | If the client requested sub-function is not supported in that ECU, the ECU will send 0x12 NRC |
0x13 | IncorrectMessageLengthOrInvalidFormat | The server will send this NRC if the message length is not correct as per the request frame format. |
0x31 | RequestOutOfRange | Server reverts with this NRC, if 1) The client specified a DTC Mask Record or DTC Severity Mask Record was not recognized by the server. 2) The client specified an invalid DTC Snapshot Record Number or DTC Extended Data Record Number |
My Dear Engineers, I would like to request you to give feedback suggestions below. So that we can motivate & write more with improvement with quality content for you. Our objective is to make every engineer innovative.
PiEmbSysTech
Discover more from PiEmbSysTech
Subscribe to get the latest posts sent to your email.