Read Scaling Data By Identifier (0x24) Service in UDS Protocol Explained with Examples

Hello, automotive diagnostics enthusiasts! In this blog post, I’ll introduce you to Read Scaling Data By Identifier (0x24) in

arget="_blank" rel="noreferrer noopener">UDS Protocol – one of the advanced and insightful services in the UDS protocol: Read Scaling Data By Identifier (0x24). This service enables diagnostic tools to retrieve scaling information that defines how to interpret raw data values from the ECU. It’s especially useful when dealing with measurement values that require conversion using formulas, factors, or units. Understanding this service is essential for accurate diagnostics, data visualization, and ECU development. In this article, I’ll explain what this service does, how it works, and walk you through its request and response formats. You’ll also see real-world examples to help clarify its usage. By the end, you’ll have a strong grasp of how to use service 0x24 effectively in UDS communication.

Introduction to Read Scaling Data By Identifier (0x24) Service in UDS Protocol

The Read Scaling Data By Identifier (0x24) service is a diagnostic function in the Unified Diagnostic Services (UDS) protocol that allows testers to read scaling information related to specific data identifiers (DIDs) from the Electronic Control Unit (ECU). This scaling data typically includes factors like offset, resolution, unit of measurement, and formulas needed to convert raw data into human-readable values. Service 0x24 is especially useful in scenarios where diagnostic tools or testing environments need to interpret real-time sensor data or internal parameters with accurate units and scaling. It plays a crucial role in diagnostics, calibration, and validation processes within the automotive industry. By enabling access to this additional layer of context, the service enhances the clarity and precision of ECU data interpretation, helping engineers and testers make more informed decisions during development and troubleshooting.

What is Read Scaling Data By Identifier (0x24) Service in UDS Protocol?

The Read Scaling Data By Identifier (0x24) service in the Unified Diagnostic Services (UDS) protocol is used to retrieve scaling information related to a specific Data Identifier (DID). Scaling data helps to interpret raw data by providing a scaling factor, offset, and unit of measurement. This service is essential when you need to convert the raw data provided by an ECU (Electronic Control Unit) into real-world values.

Purpose

The 0x24 service provides the tester with the necessary scaling information to interpret the raw values from a diagnostic session correctly. Without this information, the tester would only receive raw values, which are often meaningless unless translated using a scaling formula.

For example, a temperature sensor might return a raw value like 0x1234, but the actual temperature could be calculated by multiplying the raw value with a scaling factor and adding an offset.

Note:

There are no sub-function parameters used by this service.

Why do we need Read Scaling Data By Identifier (0x24) Service in UDS Protocol?

Here are the reasons why the Read Scaling Data By Identifier (0x24) service is needed in the UDS Protocol, explained in detail with key points:

1. Efficient Access to Scaling Information

The 0x24 service allows diagnostic tools to retrieve scaling information directly from the ECU. This includes the resolution, offset, and physical units for specific data identifiers. It eliminates the need for hardcoding this information into the tester, making the process dynamic. This is especially useful when dealing with multiple ECUs with varying data formats. It helps streamline diagnostics and reduces manual errors.

2. Accurate Interpretation of Raw Data

Raw sensor data returned by ECUs often needs conversion to meaningful physical values. Without knowing the scaling details, the diagnostic tool might interpret values incorrectly. The 0x24 service solves this by providing real-time access to scaling metadata. For example, a raw value might represent voltage or temperature, which requires scaling to understand accurately. This ensures that the data used for diagnostics or analysis is precise.

3. Compatibility with Multi-Vendor ECUs

Modern vehicles contain ECUs from various suppliers, each potentially using different scaling formats. With the 0x24 service, diagnostic tools can dynamically retrieve relevant scaling data without relying on predefined configurations. This improves compatibility and allows a single tool to work across various platforms. It also makes tool development and maintenance easier for OEMs and third-party vendors.

4. Enhanced Post-Flashing Verification

After reprogramming or updating an ECU, it is vital to verify that the correct scaling parameters are still being used. The 0x24 service enables testers to confirm that scaling definitions have not changed or been corrupted. This ensures that critical measurements, such as speed or fuel level, are still accurate after an update. It also helps in validating that the software version applied is functioning as intended.

5. Simplified Tool Development and Maintenance

Hardcoding scaling values into diagnostic tools can lead to issues when updates are required. Using 0x24, the scaling information is retrieved in real time from the ECU. This approach allows developers to create more flexible and reusable tools. It also reduces the cost and time associated with frequent updates to accommodate different ECU versions.

6. Better Support for Automated Testing

In manufacturing and service environments, automated test setups are widely used. The 0x24 service allows these systems to automatically fetch scaling and unit information for various parameters. This eliminates the need for manual lookup and configuration. As a result, the entire process becomes faster, more reliable, and less prone to human error.

7. Compliance with UDS Protocol and ISO Standards

The Read Scaling Data By Identifier service is part of the ISO 14229 UDS specification. By implementing it, vehicle manufacturers and tool developers ensure their systems are compliant with international standards. This improves interoperability between different ECUs and diagnostic tools. It also helps streamline global diagnostics across diverse automotive markets.

8. Dynamic Support for ECU Software Updates

Scaling values for data identifiers may change across ECU software versions. Instead of requiring tool updates every time a new software version is released, the 0x24 service allows scaling data to be fetched dynamically. This provides backward and forward compatibility. It also simplifies support and diagnostics for vehicles with evolving ECU architectures.

9. Improved Communication Between OEMs and Suppliers

OEMs and ECU suppliers often have to share complex spreadsheets or documentation to explain scaling parameters. The 0x24 service reduces the need for manual data sharing by embedding this information in the ECU itself. This promotes better synchronization and understanding during development, validation, and testing. It also reduces documentation errors and mismatches.

10. Prevention of Misdiagnosis and Safety Risks

Incorrect interpretation of data due to missing scaling info can lead to faulty diagnostics and even safety risks. For example, reading a tire pressure value without the correct unit could result in the wrong inflation pressure being applied. By using service 0x24, the correct interpretation is ensured, minimizing the chance of such critical mistakes. This improves both reliability and safety in vehicle diagnostics.

Syntax of 0x24 SID Request Message Frame Format

Message Direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier Request SID	0x24
#2 #3	Data Identifier[] = [                                  byte#1 (MSB)        byte#2 ]	0x00 – 0xFF 0x00 – 0xFF

Request Message Data-Parameter

DataIdentifier

This parameter identifies the server data record that the client is requesting.

Syntax of 0x24 SID Positive Response Message Frame Format

Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier +Ve Response SID	0x64
#2 #3	Data Identifier[] = [                                       byte#1 (MSB)               byte#2 (LSB) ]	0x00 – 0xFF 0x00 – 0xFF
#4	Scaling Byte#1	0x00 – 0xFF
#5 : #(p-1)+5	Scaling Byte Extension[]#1 = [           scaling Byte Extension Parameter#1                                    :         scaling Byte Extension Parameter#p ]	0x00 – 0xFF : 0x00 – 0xFF
:	:	:
#n-r	Scaling Byte#k	0x00 – 0xFF
#n-(r-1) : #n	Scaling Byte Extension[]#k = [            scaling Byte Extension Parameter#1                                             :            scaling Byte Extension Parameter#r ]	0x00 – 0xFF : 0x00 – 0xFF
C1: The presence of this parameter depends on the high nibble of the scaling Byte. It is mandatory to be present if the scaling Byte high nibble is encoded as formula, unit/format, or bit Mapped Reported With Out Mask. C2: The presence of this parameter depends on whether the encoding of the scaling information requires more than one byte.

Response Message Data-Parameter

dataIdentifier

This parameter echoes the data-parameter dataIdentifier from the request message.

scalingByte (#1 to #k)

This parameter is used in the ReadScalingDataByIdentifier positive response message to provide the requested scaling data record values to the client.

scalingByteExtension (#1 to #p / #1 to #r)

This parameter provides additional information for scalingBytes, with the high nibble encoded as either a formula, unit/format, or bitmappedReportedWithOutMask.

Syntax of 0x24 SID Negative Response Message Frame Format

Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x24
#3	Negative Response Code [ byte#1 ]	NRC

Common Negative Response Codes (NRCs) for Read Scaling Data By Identifier (0x24) Service

NRC	Parameter Name	Description
0x13	Incorrect Message Length Or Invalid Format	This Negative Response Code (NRC) shall be sent if the length of the request message is invalid.
0x22	Conditions Not Correct	This Negative Response Code (NRC) shall be sent if the operating conditions of the server do not meet the requirements to perform the required action.
0x31	Request Out Of Range	This Negative Response Code (NRC) shall be returned if: •The requested data Identifier value is not supported by the device, or •The requested data Identifier value is supported by the device, but no scaling information is available for the specified data Identifier.
0x33	Security Access Denied	This Negative Response Code (NRC) shall be sent if the data Identifier is secured and the server is not in an unlocked state.

Example of Read Scaling Data By Identifier (0x24) Service in UDS Protocol

Here’s a detailed example of how the Read Scaling Data By Identifier (0x24) service works in the UDS (Unified Diagnostic Services) protocol.

Example #1: Read Scaling Data By Identifier with Data Identifier 0xF190

Request Frame Format:

Message Direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier Request SID	0x24
#2 #3	Data Identifier [ byte#1 ] (MSB) Data Identifier [ byte#2 ] (LSB)	0xF1 0x90

Read Scaling Data By Identifier Positive Response Message Flow Example #1

Message Direction	Client → Server
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier +Ve Response SID	0x64
#2 #3	Data Identifier [ byte#1 ] (MSB) Data Identifier [ byte#2 ] (LSB)	0xF1 0x90
#4	Scaling Byte#1 {ASCII, 15 data bytes}	0x6F
#5	Scaling Byte#2 {ASCII, 2 data bytes}	0x62

Read Scaling Data By Identifier Negative Response Message Flow Example #1

Message Direction	Client → Server
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier –Ve Response SID	0x7F
#2	Requested SID [ byte#1 ]	0x24
#3	Negative Response Code [ byte#1 ]	NRC

Example #2: Read Scaling Data By Identifier with Data Identifier 0x0105 (Vehicle Speed)

Message Direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier Request SID	0x24
#2 #3	Data Identifier [ byte#1 ] (MSB) Data Identifier [ byte#2 ] (LSB)	0x01 0x05

Read Scaling Data By Identifier Positive Response Message Flow Example #2

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier +Ve Response SID	0x64
#2 #3	Data Identifier [ byte#1 ] (MSB) Data Identifier [ byte#2 ] (LSB)	0x01 0x05
#4	Scaling Byte#1 {unsigned numeric, 1 data bytes}	0x01
#5	Scaling Byte#2 {formula, 5 data bytes}	0x95
#6 #7 #8 #9 #10	Scaling Byte Extension#2 [ byte#1 ] {formula Identifier = C0 * x + C1} Scaling Byte Extension#2 [ byte#2 ] {C0 high byte} Scaling Byte Extension#2 [ byte#3 ] {C0 low byte} [ C0 = 75 * 10P-2P ] Scaling Byte Extension#2 [ byte#4 ] {C1 high byte} Scaling Byte Extension#2 [ byte#5 ] {C1 low byte} [ C1 = 30 * 10P0P ]	0x00 0xE0 0x4B 0x00 0x1E
#11	Scaling Byte#3 {unit / format, 1 data byte}	0xA1
#12	Scaling Byte Extension#3 [ byte#1 ] {unit ID, km/h}	0x30

Read Scaling Data By Identifier Negative Response Message Flow Example #2

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x24
#3	Negative Response Code [ byte#1 ]	NRC

Read Scaling Data By Identifier Request Message Flow Example #3

Message Direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier Request SID	0x24
#2 #3	Data Identifier [ byte#1 ] (MSB) Data Identifier [ byte#2 ] (LSB)	0x09 0x67

Read Scaling Data By Identifier Positive Response Message Flow Example #3

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier +Ve Response SID	0x64
#2 #3	Data Identifier [ byte#1 ] (MSB) Data Identifier [ byte#2 ] (LSB)	0x09 0x67
#4	Scaling Byte#1 {bit Mapped Reported With Out Mask, 2 data bytes}	0x22
#5 #6	Scaling Byte Extension#1 [ byte#1 ] {dataRecord#1 Validity Mask} Scaling Byte Extension#1 [ byte#2 ] {data Record#2 Validity Mask}	0x03 0x43

The above example assumes that the only supported bits, meaning those containing information, for this data Identifier in the server are as follows:

• Byte #1, bits 1 and 0
• Byte #2, bits 6, 1, and 0

Read Scaling Data By Identifier Negative Response Message Flow Example #3

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Read Scaling Data By Identifier –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x24
#3	Negative Response Code [ byte#1 ]	NRC

Example of Request Upload (0x24) SID Request and Positive Response Frame Format

Request Frame Format:

PCI Length	SID	Data by Identifier (DID)
0x03	0x24	0xF1	0x90

Positive Response Frame Format:

PCI Length	Response ID	Data by Identifier (DID)		Scaling Data
0x05	0x64	0xF1	0x90	0x6F	0x62

• In the above scaling Data, 0x6F 0x62 are scaling data information.
  • 0x6F – Indicates,
    • 6 – Represents that the value is an ASCII value
    • F – Represents the total number of bytes, in this case, 15 bytes of VIN
  • 0x62 – Indicates,
    • 6 – Represents that the value is an ASCII value
    • 2 – Represents the 2 leftover bytes of the VIN

Example of Request Upload (0x24) SID Request and Negative Response Frame Format

Request Frame Format:

PCI Length	SID	DID (Calibration Date)
0x06	0x24	0xF1	0x9B

Negative Response Frame Format:

PCI Length	Negative Response	SID	NRC
0x03	0x7F	0x24	13

Advantages of Read Scaling Data By Identifier (0x24) Service in UDS Protocol

These are the Advantages of Read Scaling Data By Identifier (0x24) Service in UDS Protocol:

1. Dynamic Data Interpretation: This service allows diagnostic tools to read scaling details such as offset, resolution, and unit directly from the ECU. This means raw data like sensor voltage or pressure can be converted to human-readable values dynamically. It removes the need to hardcode formulas in the diagnostic software. This ensures flexibility and accuracy across various ECUs.
2. Reduces Development Time: Since scaling information is fetched directly from the ECU, developers don’t need to manually define conversion formulas. This reduces the effort required to adapt diagnostic tools to new ECU versions. It also minimizes the chances of mismatches between the ECU data and tool interpretation. Overall, it speeds up diagnostic application development.
3. Improves Accuracy of Diagnostics: Incorrect interpretation of raw ECU data can lead to faulty conclusions. This service ensures the tool always has access to the correct scaling information. As a result, displayed values such as engine temperature or sensor readings are always accurate. This is vital for precise diagnostics and troubleshooting.
4. Supports Flash Programming Validation: After updating the ECU firmware, it’s important to confirm the data layout and scaling values are correct. This service allows tools to read updated scaling values and verify them against expected ones. This helps in validating successful software flashing. It ensures system behavior remains as intended post-update.
5. Enables Universal Diagnostic Tools: Instead of building a unique diagnostic interface for each ECU model, tools can retrieve the necessary scaling dynamically. This makes it possible to build universal or multi-brand diagnostic tools. It simplifies tool design and supports a broader range of vehicles. It also improves user convenience for multi-vehicle servicing.
6. Enhances Maintenance and Debugging: Technicians can read scaling information in real-time, helping them understand how the ECU interprets signals. This is especially useful when analyzing strange behaviors or when values seem out of range. The scaling context gives deeper insights into system performance. It ultimately leads to quicker and more accurate fault resolution.
7. Facilitates Remote Diagnostics: In connected or telematics-enabled vehicles, remote diagnostics is growing in importance. With this service, a remote diagnostic server can read scaling data without relying on local tools. This ensures correct interpretation of live data streams remotely. It enhances vehicle monitoring from cloud platforms.
8. Increases Reusability of Test Scripts: Test cases or scripts written to read data don’t need to be updated when scaling changes. Since the scaling info is fetched dynamically, the same script can run on different ECU versions. This saves time and reduces the need for maintaining multiple versions of the same test case. It brings consistency across test cycles.
9. Minimizes Documentation Dependency: With scaling retrieved directly from the ECU, there’s less need to refer to OEM-provided scaling tables or documents. This is a big advantage for third-party testers and developers who may not have full access to proprietary documentation. It ensures proper scaling even when official data is limited.
10. Ensures Future-Proof Diagnostics: As vehicles become more advanced, new data identifiers and parameters are continuously added. By using this service, diagnostic tools remain compatible with newer ECUs. They automatically adapt to future scaling definitions. This future-proofs the tools and reduces maintenance overhead.

Disadvantages of Read Scaling Data By Identifier (0x24) Service in UDS Protocol

These are the Disadvantages of Read Scaling Data By Identifier (0x24) Service in UDS Protocol:

1. Limited ECU Support: Not all Electronic Control Units (ECUs) support the 0x24 service. This means diagnostic tools that rely on this feature may not work across all vehicle models. As a result, technicians might need to use alternative services or OEM-specific tools, making standardization difficult in multi-brand diagnostics.
2. Security Restrictions: The service might be restricted based on the current security level or diagnostic session. For example, an ECU may require the tester to unlock certain features using SecurityAccess (0x27) before responding to a 0x24 request. This adds extra steps to the diagnostic process, slowing down operations and requiring prior knowledge of security seeds and keys.
3. Dependency on ECU Configuration: The accuracy of data retrieved depends entirely on how the ECU defines and stores scaling data. If the internal configuration is incorrect or outdated, the scaling values retrieved might be misleading. This can lead to errors in data interpretation and even cause incorrect parameter analysis during calibration or troubleshooting.
4. Increased Communication Overhead: This service increases the number of UDS messages exchanged between the tester and ECU. In systems where communication time and bandwidth are critical such as real-time applications this overhead can negatively affect performance. Too many simultaneous requests may even lead to buffer overflow or delayed responses.
5. Risk of Misuse or Misinterpretation: Diagnostic tools need to interpret the scaling data correctly based on format and encoding. Any misinterpretation can lead to incorrect data representation, like showing an incorrect sensor range. This becomes especially risky when the technician makes calibration or validation decisions based on faulty scaled data.
6. Compatibility Issues: Vehicle manufacturers may implement the service differently, or use proprietary extensions. This lack of standardization across OEMs causes compatibility issues when using generic tools. It also demands tool developers to implement brand-specific adaptations, increasing development time and costs.
7. Lack of Documentation: Often, OEMs do not provide public documentation about how the scaling data is structured. This makes it difficult for third-party tool developers or testers to understand or decode the values returned by the ECU. Without clear documentation, reverse engineering becomes the only option, which is time-consuming and error-prone.
8. Vulnerability to Firmware Bugs: Some ECUs may have bugs in the way they handle or respond to 0x24 requests. These bugs could lead to corrupted scaling data or unexpected ECU behavior. Diagnosing such issues becomes challenging without access to source code or firmware update logs, especially in complex vehicles with multiple ECUs.
9. Difficult to Test Manually: Manual testing of this service is not straightforward without a proper simulation setup. You need to know the Data Identifier (DID) mapping and the expected scaling table format. Without such preparation, it’s nearly impossible to validate the response manually, making automation a better but more complex choice.
10. Inconsistent Support Across Tools: Not all diagnostic tools especially lower-cost or open-source ones support service 0x24. This restricts technicians from accessing scaling data unless they invest in premium tools or OEM-authorized equipment. As a result, workshop operations may suffer due to tool limitations.

Future Development and Enhancement of Read Scaling Data By Identifier (0x24) Service in UDS Protocol

Here are the Future Development and Enhancement of Read Scaling Data By Identifier (0x24) Service in UDS Protocol:

1. Standardization Across OEMs: Future enhancements may focus on unifying the implementation of service 0x24 across different vehicle manufacturers. This would allow better interoperability of diagnostic tools and simplify development for third-party vendors, reducing the need for OEM-specific configurations or workarounds.
2. Improved Security Models: As cybersecurity becomes more critical, future versions of UDS may integrate more advanced authentication mechanisms for accessing scaling data. This ensures that only authorized diagnostic tools can read sensitive data, helping prevent unauthorized access or reverse engineering of calibration parameters.
3. Enhanced Data Structures: ECUs may begin supporting more structured or self-describing scaling data formats. This would allow diagnostic tools to automatically understand the structure and units of returned values without relying on external decoding tables, making the process more efficient and reliable.
4. Integration with AI Diagnostic Systems: The scaling data retrieved through 0x24 could be utilized more effectively by AI-powered diagnostics. Future systems may use this information to better interpret raw sensor data, detect anomalies, and provide predictive maintenance suggestions based on learned patterns.
5. Real-Time Scaling Information: Future developments may allow scaling data to be updated or verified in real-time based on ECU state. This means the scaling values could adjust dynamically depending on system mode (e.g., normal vs diagnostic mode), improving accuracy and reducing the chances of misinterpretation.
6. Better Tooling Support: Diagnostic tool manufacturers are likely to improve their support for 0x24 through enhanced GUIs, automated decoding, and better logging. This will simplify the workflow for engineers and technicians by abstracting the complexity behind the scenes and presenting data in a more user-friendly way.
7. Dynamic Scaling Configuration: Future ECUs might allow certain scaling parameters to be adjusted or configured dynamically by the tester, improving flexibility. This could be helpful in scenarios where the tester needs to adjust the interpretation scale temporarily without re-flashing the ECU.
8. Integration with Calibration Tools: Service 0x24 could see tighter integration with calibration and tuning environments like INCA or CANape. By directly accessing scaling data, these tools can provide accurate visualization and editing of parameters, streamlining the calibration process for engine control units.
9. Enhanced Error Reporting: Upcoming versions of the UDS protocol might enhance the error responses for 0x24 to provide more diagnostic feedback. This would help engineers quickly understand why a request failed such as due to incorrect identifier, access restriction, or corrupted data.
10. Backward Compatibility with Legacy ECUs: As service 0x24 evolves, ensuring backward compatibility will be a key focus. Diagnostic systems may implement smart fallback mechanisms to maintain support for older ECUs that use older scaling formats, preserving usability across different vehicle generations.