Industrial measurement data is often used for much longer than the measuring instrument itself. A pressure sensor may have been replaced after five years, the PLC may have been modernized in the meantime, and the original edge gateway may no longer exist. However, the measurement values from that period may still be stored in a historian, SQL database or cloud platform and used for trend analysis, energy reports, quality records or condition monitoring.
This is where a problem arises that is easily overlooked during the initial commissioning of an IIoT application: A numerical value alone does not fully describe a physical measurement.
If, for example, a database contains the value 6.42, it must still be possible years later to determine clearly which physical quantity it represented, which unit was used and which scaling was valid at the time of measurement. For a pressure value, it makes a significant difference whether 6.42 bar, 6.42 kPa or 6.42 Pa is meant. The situation becomes even more critical when an analog or digital raw value is stored instead of an already scaled pressure value.
A typical case occurs when a pressure transmitter is replaced. Originally, a 4…20 mA sensor represents a measuring range of 0…10 bar. Later, a sensor with a range of 0…16 bar is installed at the same measuring point. The PLC channel remains the same, the data point name remains the same and the MQTT topic may also remain unchanged. However, the mathematical meaning of the input signal has changed.
If historical raw data is later evaluated using the currently configured 0…16 bar scaling, incorrect process values are produced. The data may look technically correct, may be sorted correctly in time and may even have the status “Good” – yet its physical meaning is wrong.
The key point is: Unit and scaling are part of the metrological meaning of a data point. If this meaning changes, it must remain traceable from which point in time which configuration was valid. Historical measurement values must never be silently reinterpreted using a later scaling.
Table of Contents
1. Why a measurement value is more than just a number
2. Distinguishing raw signal, scaling and engineering value
3. Correctly handling bar, Pa and display units
4. Why changed scaling affects historical data
5. What exactly should be versioned?
6. Versions require a clearly defined validity period
7. Why the measurement time determines the correct scaling
8. Correctly describing units and ranges with OPC UA
9. Keeping scaling and units unambiguous with MQTT
10. Using the edge gateway as the central scaling point
11. Store-and-forward without subsequent scaling errors
12. Store raw values or already scaled values?
13. Do not mix scaling and calibration correction
14. Why a Good status does not detect scaling errors
15. Documenting sensor replacement and range changes correctly
16. Safeguarding existing measurement data retrospectively
17. Systematically identifying typical data errors
18. Practical architecture for permanently usable measurement data
19. IIoT solutions from ICS Schneider
21. Frequently asked questions about units and scaling in measurement data
1. Why a measurement value is more than just a number
From a metrological perspective, a measurement value consists of a numerical value and a unit. In an automated data chain, however, additional information is required that can be just as important for later interpretation.
A pressure value, for example, must be clearly identifiable as a pressure quantity. It must also be known whether it is represented in Pa, kPa, MPa or bar. If the value is only generated by scaling an electrical signal, it must also remain traceable which measuring range formed the basis of that signal.
In practice, there are therefore several levels between the physical process and the value shown on a dashboard.
| Level | Example | Meaning |
|---|---|---|
| Physical measured quantity | Process pressure | The actual quantity to be measured |
| Sensor or input signal | 4…20 mA | Electrical transmission of the measurement information |
| Scaling | 4…20 mA corresponds to 0…10 bar | Relationship between signal and physical quantity |
| Engineering value | 6.42 bar | Measurement value already converted into a physical unit |
| Display or calculation unit | 642 kPa or 642,000 Pa | Alternative representation of the same physical quantity |
These levels should be kept conceptually separate. Problems arise particularly when a change at one level is unknowingly treated as a change at another.
Changing from bar to Pa, for example, does not change the sensor or its measuring range. It is simply a unit conversion of the same physical quantity. Replacing a 0…10 bar sensor with a 0…16 bar sensor, on the other hand, actually changes the scaling between sensor signal and process pressure.
This distinction forms the basis of a measurement data model that remains reliable over the long term.
2. Distinguishing raw signal, scaling and engineering value
With a conventional analog pressure transmitter, the measurement chain may start with the process and continue through a 4…20 mA output to a PLC. The analog input digitizes the current, the controller or edge gateway scales the value, and only then is the pressure value created that is stored in a historian or transmitted via MQTT.
As long as this entire chain remains unchanged, the relationship is clear. Problems usually arise only after a later modification.
Assume that 12 mA represents exactly the midpoint of a 0…10 bar measuring range. The calculated pressure is therefore 5 bar. If the same 4…20 mA input is later used for a 0…16 bar sensor, 12 mA now corresponds to 8 bar.
The input current of 12 mA is completely correct in both cases. Only the scaling determines whether the result is 5 or 8 bar.
For a linear measuring chain, this relationship can generally be described by an assignment between the lower and upper raw values and the lower and upper engineering values. For data storage, the exact formula is less important than ensuring that its parameters remain clearly traceable over time.
3. Correctly handling bar, Pa and display units
For pressure, the pascal is the coherent SI unit. The bar, which is widely used in industrial measurement technology, is another unit of the same physical quantity.
The conversion is exact:
1 bar = 100,000 Pa
Accordingly, 6.42 bar is exactly 642,000 Pa or 642 kPa.
A correct unit conversion therefore always changes the numerical value and the unit together. A value of 6.42 bar must not become “6.42 Pa” simply by replacing the unit label.
For IIoT projects, it can be useful to define a project-wide calculation unit. Central analytics could, for example, process pressure values in Pa, while maintenance technicians and operators continue to see bar in the dashboard.
Such an architecture is not mandatory, however. It is equally valid to store engineering values directly in bar. The decisive factor is not which unit is selected, but that it is clearly documented and interpreted consistently by all systems involved.
A simple change in display from bar to Pa therefore does not automatically require a new sensor scaling. If, however, the unit in which values are permanently stored or defined across an interface changes, this change must remain clearly traceable for historical data.
4. Why changed scaling affects historical data
Scaling describes the mathematical relationship between an input value and the required physical quantity.
With 4…20 mA signals, this relationship is particularly easy to illustrate. The current range often remains unchanged even though the connected sensor has a completely different measuring range.
This is exactly where a typical error occurs in historian and cloud systems. If the scaling of a data point is simply overwritten, the system subsequently knows only the current configuration.
Historical raw values, however, still have the meaning that was valid at the time they were measured.
A raw value recorded while a 0…10 bar sensor was installed must therefore still be interpreted using that 0…10 bar scaling years later. The later installation of a 0…16 bar sensor must not change the meaning of the old data record.
This is the actual purpose of a scaling version: It prevents the physical interpretation of already stored data from shifting retrospectively as a result of changes to the current system configuration.
5. What exactly should be versioned?
Not every change at a measuring point is the same type of change. For clear data management, it should therefore be distinguished whether the measuring range, unit, calibration correction or only the physical device has changed.
| Change | What should remain traceable? | Effect on historical values |
|---|---|---|
| 0…10 bar sensor replaced by 0…16 bar sensor | New scaling and new validity start | Continue evaluating old raw values using the old scaling |
| Display changed from bar to Pa | Unit convention used or interface version | Physical measurement remains identical |
| Sensor replaced by an identical model | Device identity and replacement time | Scaling can remain unchanged |
| Calibration correction changed | New correction version | Scaling does not necessarily have to change |
| Tank linearization changed | New linearization or strapping version | Historical conversion must match the characteristic valid at the time |
In a specific software implementation, this information does not necessarily have to be represented as five different database objects. The technical implementation may be more compact.
The decisive factor is simply that a later evaluation can clearly answer the question: Which configuration applied to this measurement value at this point in time?
6. Versions require a clearly defined validity period
A version number alone does not solve the problem. It must also be known when a version became valid.
For example, a measuring point may use a 0…10 bar scaling until June 30 and a new 0…16 bar scaling from July 1. The historical data record must be clearly separable at this point in time.
In a database, this can technically be implemented using a validity start and, optionally, a validity end, a configuration history or immutable change events.
For the technical meaning, the specific database technology is secondary. What matters is that the previous version is not lost when a new version is activated.
This approach provides another advantage: A sensor replacement does not necessarily require a new measuring-point ID. The logical process point can continue to be called PT101 while its technical configuration changes in a historically traceable manner.
This keeps the time series continuous from a process perspective without losing technical traceability.
7. Why the measurement time determines the correct scaling
Versioning only works reliably when the measurement value has a clearly defined time reference.
This becomes particularly clear during a communication interruption. Assume that an edge gateway stores values locally because the connection to the higher-level historian has failed. During this offline period, the sensor configuration is changed at 10:00.
A value generated at 09:59:58 still belongs to the old scaling. This remains true even if it is not transmitted to the cloud until 10:15 after the connection has been restored.
If the scaling were selected solely on the basis of the reception time, this value would incorrectly be assigned to the new configuration.
For historical interpretation, the original measurement or acquisition time should therefore be used wherever possible. If a genuine sensor timestamp is unavailable, it must at least be clearly defined whether the PLC or gateway time represents the relevant acquisition time.
The later transmission or storage time must not silently take its place.
8. Correctly describing units and ranges with OPC UA
OPC UA provides standardized mechanisms for describing the unit of analog process values in a machine-readable way. This means that a client does not have to infer the unit from a variable name such as “Pressure_bar”.
An engineering range can also be specified. This allows, for example, the normal value range and the unit of an analog data point to be represented in a structured manner.
This is particularly useful when devices and systems from different manufacturers are integrated into a common IIoT or SCADA system.
Another important feature of OPC UA is the ability to indicate changed semantics of a data point. If, for example, the engineering unit or engineering range changes, a client can recognize that the meaning of the data point has changed.
However, these mechanisms do not automatically solve historical versioning. A client can recognize that the current configuration has changed. If a measurement value from the previous year is to be evaluated later using the unit or scaling that was valid at that time, the plant or historian architecture must continue to make this previous configuration available.
OPC UA therefore provides important building blocks for clean semantics, but it does not replace a configuration archive.
9. Keeping scaling and units unambiguous with MQTT
MQTT is intentionally flexible. The protocol transports messages between publishers and subscribers, but it does not prescribe how an industrial measurement value must be structured within the payload.
This flexibility is one of the reasons why MQTT can be used so broadly in IIoT applications. At the same time, it means that the project itself must define the technical meaning of a measurement value clearly.
For a pressure measuring point, it should therefore be clearly defined which unit is transmitted, whether the data is already an engineering value or still a raw value, and how a change in scaling is identified.
Placing the unit exclusively in the topic name is often inflexible. A stable data point representing process pressure can remain unchanged regardless of whether the value is later provided in bar, kPa or Pa.
Likewise, a complete new MQTT topic hierarchy is not necessarily required for every scaling change. In many architectures, it is more appropriate to use a stable semantic measuring-point ID while managing and versioning the technical configuration separately.
Current metadata can, for example, be provided separately. However, for a reliable history it must also remain traceable which earlier metadata configuration was valid at which point in time.
10. Using the edge gateway as the central scaling point
Brownfield installations often contain very different data sources. One sensor provides 4…20 mA, another a Modbus register value, while a third already transmits a digital pressure value including its unit.
An edge gateway is well suited to bringing these different sources into a consistent data model.
Scaling can then be performed in a controlled manner at one defined point. At the same time, unit, measuring-point ID, timestamp and quality status can be standardized before the data is transferred to SCADA, historian or cloud systems.
However, clear responsibility is essential. If the PLC already converts a 4…20 mA value into bar, the edge gateway should not perform a second independent scaling. Otherwise, there are several locations at which the same physical meaning must be configured.
The fewer independent scaling points a measurement chain contains, the easier it is to maintain and validate.
The central architectural question is therefore not simply “Where can we scale?”, but rather “Which system is technically responsible for this scaling?”
11. Store-and-forward without subsequent scaling errors
Local buffering is particularly important for industrial IIoT applications. A temporary failure of the WAN connection, broker or cloud must not automatically result in data loss.
Versioned scaling creates an additional requirement.
If an already scaled engineering value is generated at the edge and stored together with its original timestamp, its meaning at that time is initially preserved. If the scaling changes later, the buffered value is not affected.
If, on the other hand, only raw values are buffered and are scaled later in a higher-level system, it must be possible to determine unambiguously which scaling was valid for every historical raw value at the measurement time.
Both approaches can be technically correct. The problematic case is a hybrid solution in which raw values are stored but the currently active scaling is automatically applied during later processing.
Especially with store-and-forward, the configuration assignment must therefore be just as robust as the actual data buffer.
12. Store raw values or already scaled values?
For many applications, permanently storing only the engineering value is sufficient. A historian for process pressure can, for example, record values directly in bar or Pa. This simplifies evaluation, reporting and visualization considerably.
However, additionally storing the raw value provides advantages where high requirements for traceability or subsequent correction exist.
If it is discovered years later that a PLC scaling was incorrectly configured between two maintenance dates, an available raw-data series may allow a correct recalculation.
Without the raw data, only the already incorrectly scaled engineering value remains.
Nevertheless, it would not be appropriate to recommend complete raw-data archiving for every installation. Storage requirements, data rates, measurement criticality and documentation requirements differ considerably.
For critical measuring points, storing both raw value and engineering value can be useful. For simple trend data, a correctly scaled and clearly versioned engineering value is often sufficient.
In both cases, once stored, original data should not be silently replaced by values recalculated later. If a historical data series is corrected, it should remain clear which values were originally stored and which were subsequently derived.
13. Do not mix scaling and calibration correction
A particularly important distinction must be made between scaling and calibration correction.
Scaling initially describes the nominal transfer relationship. A transmitter with 4…20 mA and a range of 0…10 bar defines which electrical quantity corresponds to which pressure.
Calibration, on the other hand, determines how much the specific measuring instrument deviates from a reference value. If the measuring system supports this, correction values can be derived from this deviation.
A sensor can therefore continue to have a nominal measuring range of 0…10 bar while only the applied correction changes after a new calibration.
If both were combined in one undocumented conversion formula, it would later be difficult to determine whether the sensor range, plant configuration or only the calibration correction had changed.
For demanding measurement data applications, these pieces of information should therefore remain logically separate.
14. Why a Good status does not detect scaling errors
A quality status typically describes whether a measurement value is usable from the perspective of the data source or communication system.
A sensor can operate correctly, the fieldbus can communicate without errors and the measurement value can still be physically misinterpreted.
This occurs, for example, if a 0…10 bar sensor is connected but the PLC is accidentally configured for 0…16 bar.
The analog input sees a valid current. There is no cable break and no communication error. The quality status can therefore correctly be “Good”.
Nevertheless, the calculated pressure is wrong.
Data quality therefore consists of more than communication status and sensor condition. Configuration management, scaling verification and documented changes are also part of it.
15. Documenting sensor replacement and range changes correctly
Maintenance is one of the most important reasons for version changes.
If a defective 0…10 bar sensor is replaced with an identical sensor having the same measuring range, the basic scaling may remain unchanged. Nevertheless, it should be traceable from which point in time a different physical device was installed at the measuring point.
If, on the other hand, a 0…16 bar sensor is installed, the scaling changes as well. In this case, both the device replacement and the new mathematical relationship must be documented.
The measuring-point ID itself therefore does not need to change continuously. From the process perspective, “Pressure downstream of pump P101”, for example, remains the same measured quantity.
Technically, however, this logical data point can have several configuration states over its lifetime.
This separation between stable plant identity and versioned device or measurement configuration considerably simplifies both maintenance and later data analysis.
16. Safeguarding existing measurement data retrospectively
Many companies already have years of historical measurement data in which unit and scaling were not stored consistently.
Retrospective cleanup is possible, but it should be carried out conservatively.
Maintenance records, PLC programs, sensor lists, calibration certificates and project revisions should first be evaluated. These often allow periods to be identified for which a particular configuration can be documented with confidence.
Transition periods are problematic, for example when it is known that a sensor was replaced in July but the exact date can no longer be determined.
In such a case, an apparently precise version change should not be invented.
Transparent identification of the affected data period as uncertain is technically much cleaner than retrospective scaling without reliable evidence.
This distinction is particularly important for AI, reporting and predictive-maintenance projects. A large data set is not automatically a good data set.
17. Systematically identifying typical data errors
| Observation | Possible cause | Recommended check |
|---|---|---|
| Measurement value changes abruptly exactly after maintenance or sensor replacement | Measuring range or scaling changed | Compare maintenance records and configuration history |
| Values differ by a factor of 100,000 | bar and Pa confused | Check unit and conversion throughout the complete data chain |
| Raw signal is plausible, engineering value is not | Incorrect scaling | Check relationship between input signal and measuring range |
| Historical values change after reconfiguration | Old data is being reinterpreted using the current scaling | Check version and validity logic in the historian |
| Unit label changes but numerical value remains unchanged | Only the label was changed instead of performing a real unit conversion | Check numerical transformation |
| Only older values are incorrect after an offline period | Incorrect configuration used during store-and-forward processing | Compare measurement time, data buffer and scaling version |
| Measurement status is Good but the value is physically implausible | Configuration error rather than communication error | Check scaling, measuring range and device configuration |
18. Practical architecture for permanently usable measurement data
A robust IIoT data architecture does not necessarily have to be complex. The decisive factor is a clear separation between stable measuring-point identity and changing technical configuration.
The physical process point receives a permanent identity. This can, for example, be represented through the plant structure, machine and measuring-point designation.
A technical configuration is maintained alongside it, describing the sensor, measuring range, unit, scaling and, where applicable, calibration correction. Every relevant change receives a clearly defined validity start.
The measurement value itself has an acquisition time and can therefore be assigned to the configuration that was valid at that point in time.
Scaling can be performed at the edge and an already clearly interpreted engineering value can then be transmitted to the historian or cloud. Alternatively, raw values can be transmitted if the higher-level architecture reliably preserves the historical assignment of scaling states.
In practice, it matters less whether this information is stored in an SQL table, asset model, OPC UA information model or another configuration database.
What matters is technical traceability:
Which sensor generated the value, which scaling applied, which unit is the value expressed in, and at what point in time was this configuration valid?
If a system can reliably answer these four questions even years later, an essential part of long-term data quality has already been achieved.
19. IIoT solutions from ICS Schneider
ICS Schneider Messtechnik supports the integration of industrial measuring devices from the field level through to higher-level IT and OT systems. An overview can be found under IIoT Solutions.
A typical architecture connects sensors and transmitters via existing field interfaces to a PLC or edge gateway. There, measurement data can be aggregated, scaled, assigned a defined time reference and then transferred via MQTT, OPC UA or HTTPS, for example, to SCADA, historian or cloud systems.
Particularly in cross-manufacturer integration, the data model is an essential part of the technical solution. Different register mappings, units and scaling relationships must be mapped to consistent semantics without losing the original source of the measurement data.
For pressure applications, further solutions are available under IIoT Pressure Monitoring.
The relationship between measurement value, unit, plant structure and quality status is also covered in the technical article “Planning MQTT Topics for Measurement Data: Correctly Representing Units, Plant Structure and Quality Status”.
For the time reference of the data, the article “Timestamps for IIoT Measurement Data: Sensor, PLC or Gateway?” is also relevant.
If data must be stored locally during a communication failure, the technical article “Sizing Edge Buffer Storage: Calculating Offline Duration, Data Rate and Storage Reserve” provides additional technical guidance.
20. Conclusion
Industrial measurement data remains usable over the long term only if its physical meaning is preserved.
A numerical value and timestamp are not sufficient for this purpose, particularly for raw data. It must also be possible to trace how the physical engineering value was produced from the original sensor signal.
A change from 0…10 to 0…16 bar changes the scaling. A change from bar to Pa, on the other hand, changes the unit or representation of the same physical quantity. A new calibration correction does not necessarily change either the unit or nominal measuring range.
These different types of changes should therefore not be combined into one undocumented configuration.
Temporal validity is particularly important. A historical measurement value must be interpreted using the configuration that was valid when it was acquired – not the configuration currently active at the measuring point.
This is why timestamps and configuration history belong together.
With OPC UA, units and engineering ranges can be described in machine-readable form and changes in semantics can be indicated. With MQTT, the corresponding data model must be defined on a project-specific basis. In both cases, long-term historical storage of previous configuration states remains a task for the specific plant and data architecture.
The same principle applies to edge and store-and-forward systems. Either the measurement value is stored as an engineering value using the scaling valid at the time, or the raw value must be retained together with the information required to determine the correct historical scaling later.
A technically robust data chain can therefore be reduced to one simple principle:
Measurement value, unit, scaling and time reference must never become separated over the lifetime of a measuring point.
Taking these relationships into account when designing the IIoT architecture not only prevents classic factor errors between bar and Pa. It also creates a significantly better foundation for historians, MES, reporting, condition monitoring and future data analysis.
21. Frequently asked questions about units and scaling in measurement data
Why must scaling be versioned?
Because the relationship between a raw signal and the physical measured quantity can change over time. Historical raw values must still be evaluated later using the scaling that was valid when they were acquired.
When do I need a new scaling version?
A new version is required whenever the mathematical relationship between the input signal and the engineering value changes. Typical examples include a different sensor measuring range or a changed linearization.
Does changing from bar to Pa require a new sensor scaling?
Not automatically. bar and Pa are different units of the same physical quantity. If the underlying measurement remains unchanged and only the display is converted, the sensor scaling does not change. If, however, the unit of the stored or transmitted data is changed, this change must be clearly documented for the interface and for historical interpretation.
How many pascals are in one bar?
One bar is exactly 100,000 Pa. Accordingly, 6.42 bar is equal to 642,000 Pa or 642 kPa.
What is the difference between scaling and unit conversion?
Scaling assigns a physical measured quantity to a raw or input signal, for example 4…20 mA to 0…10 bar. Unit conversion then converts the same physical value, for example from bar to Pa.
What is the difference between scaling and calibration correction?
Scaling describes the nominal relationship between the signal and the measuring range. A calibration correction, on the other hand, accounts for an individually determined deviation of the specific measuring instrument. Both pieces of information can change independently.
Does every sensor replacement require a new scaling?
Not necessarily. If a sensor is replaced by an identical device with the same output signal and measuring range, the scaling can remain unchanged. The device replacement itself should nevertheless be documented.
What happens when a 0…10 bar sensor is replaced by a 0…16 bar sensor?
The relationship between the input signal and pressure changes. A new scaling is therefore required for values recorded from the replacement time onward. Historical data before that time must continue to be interpreted using the previous measuring range.
Should I store raw values or already scaled values?
Both can be useful. Engineering values can be used directly and simplify analysis. Raw values improve traceability and may allow later recalculation. Which option is appropriate depends on criticality, data volume and traceability requirements.
Can a Good quality status still contain an incorrect measurement value?
Yes. The sensor and communication may be functioning correctly while an incorrect scaling is configured. The value can then be transmitted as technically valid even though its physical interpretation is wrong.
What role does the timestamp play?
The relevant measurement or acquisition time makes it possible to determine which configuration belonged to a specific value. This is particularly important when data is buffered and transmitted only later.
Why must the current scaling not simply be used during store-and-forward?
Because a buffered measurement value may have been generated before a later configuration change. Its interpretation must be based on the scaling valid at the original measurement time.
What does OPC UA provide for units?
OPC UA provides standardized information for engineering units and value ranges. This allows clients to determine the unit of an analog measurement value in a machine-readable way. Changes in semantics can also be indicated.
Does OPC UA automatically store previous units and scaling configurations?
No. OPC UA provides mechanisms for describing current semantics. Long-term historical storage of previous configurations must be implemented by the respective server, historian or plant architecture.
How does MQTT handle units and scaling?
MQTT defines message transport but does not prescribe a mandatory industrial measurement-data format. The project itself must therefore define the unit in which values are transmitted and how scaling and configuration versions are clearly assigned.
Should the unit be part of the MQTT topic name?
This is technically possible, but it can make later unit changes unnecessarily difficult. It is often more robust to use a stable measuring-point ID and treat the unit as clearly associated data or metadata.
What should be documented after a sensor replacement?
At minimum, the replacement time, identity of the new sensor, its measuring range and, where applicable, the new scaling or calibration information should remain traceable.
How should I handle historical data whose scaling is no longer known?
Scaling should only be assigned retrospectively if it can be reconstructed from reliable documentation such as PLC revisions, maintenance records or device configurations. If the assignment is not unambiguous, the affected period should be marked as uncertain.
What information does ICS Schneider require for an IIoT data model?
Useful information includes the measuring-point list, physical measured quantities, sensor and measuring ranges, output signals or register mappings, engineering units used, PLC and edge systems, sampling rates, timestamp source, requirements for data quality and buffering, and the planned target systems such as SCADA, historian, MQTT broker or cloud platform.