Table of contents
- Introduction to Read Data By Identifier (0x22) Service
- Properties of ReadDataByIdentifier (0x22) Service in UDS Protocol
- Frame Format of Read Data By Identifier (0x22) Service in UDS Protocol
- Supported NRC of Read Data By Identifier (0x22) Service in UDS Protocol
- How Does Read Data By Identifier (0x22) Service works in UDS Protocol?
- Advantages of Read Data By Identifier (0x22) Service in UDS Protocol
Introduction to Read Data By Identifier (0x22) Service
The RDBI stands for Read Data By Identifier. The Read Data by Identifier (0x22) service in UDS Protocol is a service that is used to read a single or multiple DID’s from the ECU or server. This 0x22 service is coming under the Data Transmission services of the UDS protocol. It helps the Tester, Diagnostic Engineer, Developer, Service Engineer, Traffic Police, RTO Office, etc. to get the basic data details of any vehicle.
Generally, this 0x22 service is being used in the service center to read any data or information required by them to repair the vehicle.
Every Data is storing in the Flash or permanent memory in the microcontroller of the ECU. But generally the enginners are not allowed to get or understand like a developer to make the work complex. So the SAE made a standard names or a range of numerical values for each data and defined it in the ISO 14229 standard. This ranges from 0x0000 to 0xFFFF.
For Example, the DID number is 0xF190 is for VIN Data Identifier. It stores the 17 bytes of VIN inside the Vehicle ECU memory. So when you want this unique VIN number, you can use this DID to request the original VIN number from the vehicle.
The Read Data by Identifier (0x22) service in UDS protocol is a basic service and is widely used for diagnostic and testing purposes in the automotive industry. It provides a simple and efficient way to retrieve specific data from the vehicle’s ECU, which can be useful for troubleshooting and identifying issues with the vehicle’s systems.
In the Unified Diagnostic Services (UDS) protocol, the Read Data by Identifier (0x22) service is a service that allows a diagnostic tester (e.g., a diagnostic tool) to request one or more values of a particular data identifier from a vehicle’s Electronic Control Unit (ECU).
Data Identifier in UDS Protocol
The Data Identifier is typically a unique identifier assigned to a specific piece of data (e.g., a sensor reading or system status) that is stored in the ECU. The diagnostic tester sends a request to the ECU with the data identifier that it wants to read, and the ECU responds with the value of the requested data.
Need of ReadDataByIdentifier (0x22) Service in UDS Protocol
The UDS protocol is having lot of Services used for diagnostic purpose. The ReadDataByIdentifier (0x22) is one of the most important service in UDS protocol. But this a general and important service that is used in most of the time and places. If you think any kind of data you want to read like, vehicle speed, enginee speed, VIN number or any data like this, then we can use this service to read it from the vehicle or from a particular ECU.
Properties of ReadDataByIdentifier (0x22) Service in UDS Protocol
- ReadDataByIdentifier (RDBI) is a Service Identifier (SID) in UDS Protocol ISO 14229.
- Its Service Identifier (SID) is 0x22 defined in UDS protocol.
- It does not have any Sub-function.
- It sends a 2 byte DID in request frame like Sub-function to get to real data of this DID.
- Every DID of UDS Protocol is a 2-byte numerical value ranges from 0x0000 to 0xFFFF. But there values can be 1 byte to any ranges as per the requirement.
- For Example: 0xF190 is a 2 byte DID Number for Vehicle Identification Number (VIN), but its value is 17 characters (e.g; 4Y1SL65848Z411439).
- Some DIDs are ISO standard, some DIDs are OEM Reserved, some DIDs are Supplier defined. All are can be found from this link: List of All DID.
Frame Format of Read Data By Identifier (0x22) Service in UDS Protocol
Like other service, Read Data by Identifier (0x22) Service is also request frame, Positive response frame, and negative response frame formats available. Lets discuss about each frame formats with details by taking example of any DID.
Request Frame Format of Read Data By Identifier (0x22) Service in UDS Protocol
The Read Data By Identifier (0x22) Service is used to request the DID number to the server or ECU or whole vehicle to get the original data or information assigned to that DID number. The syntax or range of this service for how to request is defined in this below table.
| Data Byte | Parameter Name | Byte Value | Mnemonic |
|---|---|---|---|
| #1 | ReadDataByIdentifier Request SID | 0x22 | RDBI |
| #2 #3 | DataIdentifier[]#1 = [ byte#1 (MSB) byte#2 ] | 0x00 – 0xFF 0x00 – 0xFF | DID_H DID_L |
| . | . | . | . |
| #n-1 #n | DataIdentifier[]#1 = [ byte#1 (MSB) byte#2 ] | 0x00 – 0xFF 0x00 – 0xFF | DID_H DID_L |
Example of Request Frame Format of Read Data By Identifier (0x22) Service
The below example is used a Data Identifier (DID) is 0xF180. This DID is used to know the current active session of the ECU. Means either it is in Default session, Programming session or Extended Diagnostic etc. Lets discuss about it by taking the example of DoCAN frame format.
| PCI_H | RDBI | DID_H | DID_L | NULL | NULL | NULL | NULL |
|---|---|---|---|---|---|---|---|
| 0x03 | 0x22 | 0xF1 | 0x86 | XX | XX | XX | XX |
If the server received this request, then it will validate and sends the response as per the request. It might be positive response or Negative response.
- PCI_H (0x03): This is a 1 byte Protocol Control Information Header as per the CAN-TP standard. It is divided into 2 digit or 4 LSB & 4 MSB.
- 4 MSB: This PCI digit is called as Frame type and its value is ‘0’,that means it is a single frame.
- 4 LSB: This PCI digit is called Data Length (DLC) and its value is ‘3’, that means it has next 3 bytes of UDS diagnostic data.
- RDBI: The Read Data By Identifier is the 2nd byte of the CAN data field and 1st byte of the DoCAN or diagnostic byte. Its service Identifier is 0x22.
- DID_H n DID_L (0xF186): This is a combination of last 2 byte of the diagnostic Data Identifier. Its DID number is 0xF186. It is a DID defined in the ISO 14229 standard document.
Positive Response Frame Format of Read Data By Identifier (0x22) Service in UDS Protocol
If the server is successfully validated this request received from the client, then it will execute the request as per the DID number sent by the client, then it will send the Positive response to the client with the data of that DID. Lets check the standard syntax frame format of the Read Data By Identifier (0x22) Service defined below.
| Data Byte | Parameter Name | Byte Value | Mnemonic |
|---|---|---|---|
| #1 | ReadDataByIdentifier Request SID | 0x62 | RDBIPR |
| #2 #3 | DataIdentifier[]#1 = [ byte#1 (MSB) byte#2 ] | 0x00 – 0xFF 0x00 – 0xFF | DID_HB DID_LB |
| 4 : (k-1)+4 | DataIdentifier[]#1 = [ data#1 (MSB) : data#k ] | 0x00 – 0xFF : 0x00 – 0xFF | DREC_DATA_1 : DREC_DATA_m |
| : | : | : | : |
| n-(o-1)-2 n-(o-1)-1 | DataIdentifier[]#m = [ byte#1 (MSB) byte#2 ] | 0x00 – 0xFF 0x00 – 0xFF | DID_HB DID_LB |
| n-(o-1) : n | dataRecord[]#m = [ data#1 : data#o ] | 0x00 – 0xFF : 0x00 – 0xFF | DREC_DATA_1 : DREC_DATA_m |
Example of Positive Response Frame Format of Read Data By Identifier (0x22) Service
If the ECU is already received this request with the DID number 0xF186, it will read the real data or informed stored in the memory address of this DID. Then it will send it to the server as a positive response if it is able to get the data successfully without any error. Since the DID is a “Active Diagnostic Session Data Identifier”, it stores a 1 byte data for the session ID as per the Diagnostic session control sub-function ID. Suppose lets say now the current session of the ECU is programming session or the ECU is in programming mode, then it will send you the data value with “2”. Lets see it in the example script below.
| PCI_H | RDBIPR | DID_HB | DID_LB | DREC_DATA_1 | NULL | NULL | NULL |
|---|---|---|---|---|---|---|---|
| 0x04 | 0x62 | 0xF1 | 0x86 | 0x02 | xx | xx | xx |
- PCI_H (0x07): This is a 1 byte Protocol Control Information as per the CAN-TP standard. It is divided into 2 digit or 4 LSB & 4 MSB.
- 4 MSB: This PCI digit is called as Frame type and its value is ‘0’,that means it is a single frame.
- 4 LSB: This PCI digit is called Data Length (DLC) and its value is ‘7’, that means it has next 7 bytes of UDS diagnostic data.
- RDBIPR: The Read Data By Identifier Positive Response is the 2nd byte of the CAN data field and 1st byte of the DoCAN or diagnostic byte. Its service Identifierwill be (Request ID (0x22)+ 0x40) 0x62.
- DID_H n DID_L (0xF186): This is a combination of next 2 byte of the diagnostic Data Identifier. Its DID number is 0xF186. It is a DID defined in the ISO 14229 standard document for getting the Active Diagnostic Session Data Identifier information. That means next will be the data for this DID.
- DREC_DATA_1 (0x02): This Data Record 1 is a 1 byte data that defines the current active diagnostic session. As per the data value is 0x02 means the current session is the programming session.
Negative Response Frame Format of Read Data By Identifier (0x22) Service in UDS Protocol
If the request received by the server from the client is not a valid request or due to any problem in the server side, the server will send the Negative response. Lets discuss about this frame by taking 1 example below for the wrong data format or message length.
// Suppose the request frame is wrong like below by adding 1 extra byte of junk data by mistake
//Client Sending request to server
02 22 F1 86 F2If you look at the above wrong request sent by the client to server. The F1 & 86 is the last 2 bytes of DID is 0xF186. But there is 1 extra byte is 0xF2, which is a wrong format as per this Read Data By Identifier (0x22) Service in UDS Protocol defined in the ISO 14229 standard. So, the server will valiadte as wrong message format and sending a negative response as per the below message table.
| PCI_H | RDBINR | RDBI | NRC | NULL | NULL | NULL | NULL |
|---|---|---|---|---|---|---|---|
| 0x03 | 0x7F | 0x22 | 0x13 | XX | XX | XX | XX |
- PCI_H (0x03): 1st byte of the CAN data field is the Protocol Contro Information Header.
- 4 MSB (0): 1st 4 MSB is the Frame type. Since it is ‘0‘, this is a single frame and the next 4 bit will be the DLC of this frame.
- 4 LSB (3): last 4 LSB is the Length of this frame. It means the next 3 byte is the original data.
- RDBINR (0x7F): The Read Data By Idenitfier Negative Response is a 1 byte service Identifier defined in the ISO standard. This SID is fixed in all over the protocol and its value is 0x7F. if the Service ID is 0x7F means it is a negative response frame. So the next byte will be the Requested SID.
- RDBI (0x22): This is the 3rd byte of CAN data field and 2nd byte of RDBINR. Its value is 0x22 means Read Data By Identifier (0x22) Service in UDS Protocol.
- NRC (0x13): This a 4th byte of CAN data field and 3rd byte of RDBINR. Since it is a Negative response,its 4th byte will be NRC sent by the server as per the Read Data By Identifier (0x22) Service in UDS Protocol. So, since its value is 0x13, means “Incorrect Message Length Or Invalid Format“. To understand more about it, you can go to the NRC table defined below.
Supported NRC of Read Data By Identifier (0x22) Service in UDS Protocol
Like other services, Read Data By Identifier (0x22) Service in UDS Protocol is having 5 different Negative Response Codes as per the ISO 14229 standard. Please check the below table for more details of each UDS NRC of Read Data By Identifier (0x22) Service of all thr supported NRC. In belwo table we have explained the supported nrc in RDBI service of UDS protocol.
| NRC code | NRC Name | NRC Description |
|---|---|---|
| 0x13 | Incorrect Message Length Or Invalid Format | If the length of the request message is invalid or the client requests too many pieces of information at once, they will receive an NRC message to indicate that their request was unsuccessful. |
| 0x14 | Response Too Long | This NRC shall be sent if the total length of the response message exceeds the limit of the underlying transport protocol (e.g., when multiple DIDs are requested in a single request). |
| 0x22 | Conditions Not Correct | If the server cannot perform a requested action due to certain operating conditions not being met, an NRC message will be sent to indicate the action cannot be performed. |
| 0x31 | Request Out Of Range | This NRC shall be sent if: – None of the requested dataIdentifier values are supported by the device. – None of the requested dataIdentifiers are supported in the current session. – Requested dynamicDefinedDataIdentifier has not been assigned yet. |
| 0x33 | Security Access Denied | If the server is not in an unlocked state and at least one of the requested data identifiers is secured, an NRC message will be sent to indicate that the requested action cannot be performed. |
How Does Read Data By Identifier (0x22) Service works in UDS Protocol?
Clients can use the ReadDataByIdentifier service to retrieve data record values from the server based on one or more dataIdentifiers. Within the client request message, there are one or more two-byte dataIdentifier values that serve to identify the server-maintained data record. The structure and meaning of the dataRecord is specific to the vehicle manufacturer or system supplier, and it may consist of analog input/output signals, digital input/output signals, internal data, and system status information, provided that the server supports them.
As per the agreement between the vehicle manufacturer and system supplier, the server might impose a restriction on the number of dataIdentifiers that can be requested simultaneously.
Once a ReadDataByIdentifier request is received, the server will retrieve the data elements of the records identified by the dataIdentifier parameter, and then transmit their values in a single positive response through the associated dataRecord parameter. The request message may contain repeated instances of the same dataIdentifier. The server will treat each instance as a distinct parameter and respond with data for each as frequently as requested.
In the above image, the client is sending a ReadDataByIdentifier request to the server with the DID number 0xF186. This DID value is defining that the client want to know the current diagnostic session of the ECU. So once the server is receiving, it validated and since it is a correct message, the server is sending a positive response with the 1 byte current diagnostic session value. Since the value is 0x02, hence the current diagnostic session is Programming session.
Advantages of Read Data By Identifier (0x22) Service in UDS Protocol
The Read Data by Identifier (0x22) Service in UDS Protocol has several advantages:
- Efficient Data Retrieval: This service allows the client to request specific data from the server, which can help optimize data retrieval and reduce the amount of unnecessary data sent over the network.
- Reduced Network Traffic: Since the client can request only the specific data it needs, this can reduce the amount of network traffic and help optimize network performance.
- Standardized Protocol: The UDS protocol is a standardized protocol used in the automotive industry, which can help ensure interoperability and consistency across different systems and components.
- Supports Diagnostics and Troubleshooting: The Read Data by Identifier service can be used for diagnostics and troubleshooting, allowing technicians to quickly and efficiently access specific data and diagnose problems.
Disadvantages of Read Data By Identifier (0x22) Service in UDS Protocol
The Read Data by Identifier (0x22) Service in UDS Protocol also has some potential disadvantages:
- Limited to Supported Data: This service can only retrieve data that is supported by the server, and if the requested data is not supported, the server will send an error message to the client.
- Security Concerns: Since this service can be used to retrieve sensitive data, such as vehicle diagnostic information, there may be security concerns if the data is not properly protected.
- Requires Knowledge of Data Identifiers: The client must know the specific data identifiers in order to use this service, which may require additional knowledge or training.
- Limited to Single Data Retrieval: This service only allows for retrieval of a single piece of data at a time, which may not be efficient for applications that require retrieval of multiple pieces of data.
Future Development & Enhancement of Read Data By Identifier (0x22) Service in UDS Protocol
The future development and enhancement of the Read Data by Identifier (0x22) Service in UDS Protocol could involve several improvements or modifications, such as:
- Increased Data Support: The service could be expanded to support additional types of data and data identifiers, allowing clients to request more specific or complex information from the server.
- Security Upgrades: To address potential security concerns, the service could be enhanced with additional security measures, such as stronger authentication or encryption protocols.
- Batch Data Retrieval: The service could be modified to allow for batch data retrieval, which would enable clients to retrieve multiple pieces of data in a single request and improve overall efficiency.
- Integration with Other Services: The Read Data by Identifier service could be integrated with other UDS services, such as the Write Data by Identifier service or the Input Output Control by Identifier service, to enable more advanced functionality and capabilities.
- Improved Error Handling: The service could be improved with better error handling and reporting, providing clients with more detailed and informative error messages to help diagnose and resolve issues more effectively.
- Performance Optimization: The service could be optimized for performance, potentially through the use of more efficient data retrieval algorithms or improved network communication protocols.
- Compliance with New Standards: The service could be modified to comply with new industry standards or protocols as they emerge, ensuring ongoing compatibility and interoperability with other systems and components.
