Suppose we read the following raw value from one of the Modbus registers of an industrial electrical power meter:

register: 40001
value:    23871

Are we done with industrial digitalisation?

We have barely started.

23871 is nothing more than a string of digits. Before any decision can be based on it, we need to know what it means, where it came from, when it was valid, how reliable it is, what it belongs to, what it should be compared with to count as abnormal, and what should happen if there really is a problem.

Let’s follow the data along its entire path.

1. Reading the register correctly

The Modbus documentation has to tell us:

  • the function code used;
  • the actual register address;
  • the data type;
  • whether the value is signed or unsigned;
  • the byte and word order;
  • the scaling factor;
  • the unit of measurement;
  • the validity and error flags.

Even the notation 40001 can be misleading. Some documentation uses human-friendly numbering, some uses zero-based protocol addresses. A single address offset can mean that instead of power we are reading a neighbouring register.

Suppose the documentation says the value is an unsigned 16-bit integer with a scaling of 1 W. Then:

23871 → 23,871 W → 23.871 kW

Now it has a physical meaning. But it still has no business context.

2. Device identity and timestamp

The data must be assigned to a specific meter and measuring point. The IP address or the Modbus unit ID is not enough, because these can change or be repeated across several sites.

A stable device and measuring-point identifier is needed, together with a reliable timestamp. The system must also distinguish:

  • when the measurement was taken;
  • when the gateway read it;
  • when it arrived in the central system.

After a network outage, previously buffered data may arrive later. If only the arrival time is stored, the historical picture shifts and the rules may evaluate it incorrectly.

3. Data quality and validity

Not every number that is read is a real measurement. It may be the last known value after a communication error, an overflow, a state during device start-up or a documented error code.

A quality flag can therefore be attached to the data:

quality: good | uncertain | bad
source: live | buffered | estimated

A business rule cannot treat a verified live measurement and an estimated, uncertain value in the same way. This is particularly important in a billing or control process.

4. Normalised message

The gateway converts the field value into a uniform data model. For example:

{
  "site_id": "site-etyek-01",
  "asset_id": "compressor-03",
  "measurement": "active_power",
  "value": 23.871,
  "unit": "kW",
  "measured_at": "2026-09-14T06:32:10Z",
  "quality": "good"
}

From this point on, central processing no longer needs to know the manufacturer-specific register map of every meter. Field-level differences are handled by the gateway and the device profile, while the platform works with uniform concepts.

5. Secure transmission and buffering

The message reaches the processing system over a controlled connection. When designing the communication, authentication, encryption, authorisation, the topic or endpoint structure, redelivery and error handling all have to be defined.

If the connection drops, the gateway can store the data locally and forward it later with the original measurement time. The central system has to handle messages that arrive late and possibly more than once.

This is not a spectacular feature. But without it the chart has gaps, the settlement can be disputed and the model learns from faulty data.

6. Storage and business context

The 23.871 kW measurement goes into a time-series store. In parallel, the platform’s master data tells us about compressor-03:

  • which site it is located at;
  • which production line it belongs to;
  • which cost centre it is charged to;
  • who is responsible for operating it;
  • what its rated power is;
  • when it was last serviced;
  • which contract or project it is affected by.

This is the point at which the measuring point becomes part of how the company operates.

7. Interpreting the number

Suppose the compressor is currently idling. According to historical data, a power of 12–15 kW is normal in this state. So 23.871 kW is interesting not because it is a large number in itself, but because it is a significant deviation for that operating state.

The rule or anomaly detection model can take into account:

  • the operating state;
  • the baseline of the previous period;
  • the outside temperature;
  • the pressure value;
  • the duration of the deviation;
  • the sensor’s quality flag.

For example, an event is only created if idle power stays above 20 kW for at least 20 minutes. That way a momentary spike does not trigger an unnecessary alarm.

8. From event to task

The system creates the event:

Type:        high idle energy consumption
Asset:       compressor no. 3
Priority:    medium
Owner:       site maintenance
Deadline:    24 hours
Evidence:    trend, operating state, related measurements

A work order can be generated automatically from the event. On site, the technician sees the asset’s data, its history and the curve that supports the alert. During the inspection they record that, because of a valve that was not closing properly, the system was running unnecessarily even when unloaded.

9. Intervention and verification

Once the valve has been repaired, the system does not simply close the task. It compares the new idle consumption with the previous state.

Suppose the value drops back to 13.5 kW. The difference is about 10.4 kW whenever the machine is idling.

With 120 such operating hours per month, the estimated saving is:

10.4 kW × 120 h = 1,248 kWh/month

Using the current internal or purchase cost of energy, a financial impact can be derived from this. The system therefore documents not only that “we repaired the valve”, but also what energy and cost result the intervention delivered.

10. Management decision

A single case does not necessarily make a strategy. But if the same platform handles similar events across several sites and assets, management can get answers to questions such as:

  • which type of equipment causes the most losses;
  • where instrumented condition monitoring pays back fastest;
  • which site responds fastest;
  • how much verified saving the interventions have delivered;
  • which assets are worth refurbishing or replacing;
  • which pilot is worth rolling out across the company.

The manager no longer sees register 40001. They see what a measurable technical problem has cost, how it was handled, how long it took to close and what the result was.

This is what IT–OT integration really means

OrigSmart’s complete technology environment ties exactly this path together. Where needed, we start from the measurement and field communication layer. The gateway interprets and forwards the data. The platform links it to the asset, the location, the person responsible and the business process. The event becomes an actionable measure, and the measure becomes a verifiable result.

This is much more than a Modbus driver, a database or a dashboard. They are all necessary components, but on their own they do not add up to a working operational system.

OrigSmart creates value by taking a single raw number from the physical world through interpretation, responsibility and intervention all the way to a management decision.

Let’s discuss your project

Sources