What happens between the sensor and the business system?

When an industrial digitalisation project is presented, two things usually stand out: the physical device that measures, and the screen on which the result appears. From the outside, the path between them often looks like a single arrow.

Yet that arrow is where a large part of the work happens.

A raw sensor signal does not automatically become reliable business information. Along the way, you have to deal with the electrical signal, the protocol, the timestamp, the device identity, the unit of measurement, network outages, data quality, access rights, storage, context – and, finally, the question of which process the data should trigger.

The measurement point: where the physical world becomes data

The data path begins at a sensor, meter or controller. This may be an electrical power meter, a temperature sensor, a vibration sensor, a water meter, an inverter, a PLC, a pulse transmitter or custom electronics.

Several fundamental questions are already decided here:

• what we are actually measuring;
• with what accuracy and resolution;
• how often samples need to be taken;
• in what physical and electromagnetic environment the device operates;
• which communication interface is available;
• whether data may be lost if the connection is temporarily down.

A power measurement every two seconds and a temperature reading every five minutes do not call for the same data handling. And the high-frequency sample stream needed for vibration analysis can mean an entirely different load and level of local processing than a daily water meter reading.

Field communication: reality is rarely a REST API

In office IT, an IP network and a documented API are taken for granted. In the field, by contrast, RS-485, Modbus RTU, Modbus TCP, pulse signals, digital or analogue I/O, vendor-specific protocols and decades-old installed equipment are common.

Here it is not enough to know that it is “Modbus”. Among other things, you need to know:

• the unit ID;
• the register addressing;
• the data type, and the byte and word order;
• the scaling factor;
• the polling frequency;
• the physical layout of the bus and its termination resistor;
• how communication errors are handled.

A misinterpreted 32-bit floating-point value can easily turn into a physically impossible reading. If the system forwards it without validation, the error propagates along the entire data chain.

The gateway: translator, buffer and local decision point

The gateway connects the field world with the IT world. Its tasks may include translating between protocols and normalising, timestamping, buffering, encrypting and forwarding data.

An industrial gateway, however, must also allow for the fact that the network is not always available. Simply discarding data in that situation is not a good solution. Local storage, queuing and later synchronisation may be required.

Certain decisions also have to be made locally. If exceeding a limit requires an immediate shutdown or alarm, it makes no sense to wait for the round trip to the cloud and back. That is why, in many cases, the gateway is an edge computing device as well.

Message brokering: events instead of data

MQTT and other message brokering solutions make it possible for the data source and the processing system not to be tied together by a direct, rigid connection. The gateway publishes, and authorised systems subscribe to the topics they need.

This can make the system more flexible, but the design questions do not go away:

• how the topic structure is built;
• how the device and the site can be identified;
• what QoS level (delivery guarantee) is needed;
• whether duplicate messages are acceptable;
• how authentication and authorisation are handled;
• what guarantees the origin and integrity of the message.

A good message is more than just a number. It contains – or makes it unambiguously determinable – where it came from, when, with what quality and with what meaning.

Processing and normalisation

Incoming data often has to be cleaned and interpreted. This may include:

• scaling the raw value;
• unit conversion;
• detecting incorrect or missing values;
• handling duplicates;
• assigning device and location data;
• limit and state logic;
• calculating derived indicators.

A value of 23871 means nothing on its own. It could be an instantaneous power of 23,871 W, 2,387.1 kW with a scaling factor of 0.1, a cumulative energy counter reading or an error code. Data only becomes interpretable together with the right metadata and operational context.

Storage: not all data belongs in the same database

The master data of devices, customers, sites and contracts is different in nature from measurement rows arriving every second. That is why an industrial platform often uses several kinds of data storage.

A relational (transactional) database is strong at managing relationships, permissions and business objects. Time-series or column-oriented storage is suited to fast analysis of large volumes of measurement data. A document store, in turn, provides a home for reports, images and related files.

A good system is not one that forces the same database onto everything, but one that builds a unified business model on top of the different storage tasks.

Business context: what gives data its value

A measured value becomes enterprise information when it is linked to something:

• a piece of equipment;
• a room or site;
• a customer;
• a cost centre;
• a contract;
• a production operation;
• a maintenance history.

One of the core principles of the OrigSmart platform is that data from the physical and business worlds meets in a shared environment. A measured value can therefore become not only a chart, but also an alarm, a task, a work order, a billing item or information for management decisions.

Sources

• NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security
• OASIS MQTT Version 5.0
• Modbus Organization – Technical Resources
• OrigSmart – Web-based business operating system