Edge or cloud? In industry, that’s the wrong question

In industrial digitalisation projects, the same question keeps coming up: edge or cloud?

As if we had to choose between two mutually exclusive worldviews. On one side, on-site processing; on the other, the cloud. One is fast and independent, the other scalable and centrally manageable.

In reality, a well-functioning industrial system almost always uses both. Not because of technology trends, but according to where a given piece of data or a decision can be handled most safely, most quickly and most economically.

What does the edge actually mean?

The edge is not necessarily a special server next to the production line. It can include any computing and decision-making capability that operates close to where the data is generated.

It can be:

• an intelligent sensor;
• a PLC;
• an industrial IoT gateway;
• a local computer;
• an on-site server;
• a data-processing service running in a container.

The job of the edge is not simply to “send less data to the cloud”. It can handle locally those functions where low latency, independence from the network, data protection or operational safety matter.

What must not be left to a remote connection

If a decision has to be made within milliseconds or seconds, the network round trip can be risky. The same applies when the process has to keep working without an internet connection.

Typically kept local:

• direct machine and process control;
• functional safety functions;
• immediate protective intervention;
• pre-processing of data with a high sampling rate;
• data buffering;
• essential local operator functions;
• adaptation of communication protocols.

For example, if a vibration sensor produces several thousand samples per second, it is not necessarily worth sending every raw value to a central system continuously. Local processing can calculate characteristic features, detect threshold crossings and forward only the relevant summary or the sample window around an event.

Where central or cloud processing is stronger

A central environment pays off where data from several sites, long periods or multiple business systems has to be brought together.

This is the right place for, among other things:

• comparison between sites;
• historical analysis;
• fleet-level device monitoring;
• corporate reporting;
• central access management;
• model training;
• maintenance and business processes;
• version and configuration management.

The advantage of the cloud is not merely that “the server is somewhere else”. It can provide flexible capacity, central accessibility, uniform operation and joint processing of data from multiple sources.

Five real decision criteria

The division of tasks between edge and cloud should be defined according to at least five criteria.

1. Latency

How quickly must the system respond? A machine-protection intervention and a monthly energy report obviously do not belong in the same category.

2. Connection reliability

What happens if the WAN or mobile connection drops? The local process must keep running safely, and data must be buffered where necessary and synchronised later.

3. Data volume

Are we transmitting raw data series or already processed features? Bandwidth, storage cost and the purpose of the analysis together determine the right answer.

4. Security and data handling

Which data may leave the site? In which direction are connections permitted? Where do authentication, encryption and logging take place?

5. Lifecycle and operation

Who updates the local component? How can the configuration of a hundred sites be managed? How can a faulty version be rolled back? An edge device must not become a forgotten black box.

Offline operation is not an exception but a design state

In an industrial solution, a network outage should be designed not as an extraordinary accident but as a system state handled in advance.

The following must be defined:

• how much data can be stored locally;
• in what order data is backfilled;
• how duplicates are handled;
• what happens in case of conflicting commands;
• which functions remain available;
• when the system raises an alert, and to whom.

OrigSmart’s gateway and platform approach addresses this continuity. Field connectivity, local logic, message forwarding, central data processing and business processes are not separate projects but parts of a single system designed end to end.

In a bidirectional system, the boundary matters even more

Simple telemetry only sends data upwards. A true operational platform, however, can also act back on physical operation: it changes a setpoint, controls an inverter, schedules consumption, acknowledges an alarm or starts a local process.

In such cases, a clear distinction must be made between:

• a recommendation and an executable command;
• central optimisation and local safety limits;
• user permissions and device-side authorisation;
• normal operation and the safe fallback mode.

The central system may indicate that reducing a load would be economically beneficial. Local control, however, must prevent any intervention that would violate a technological or safety limit.

Sources

• European Commission – Europe’s Internet of Things policy
• NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security
• OrigSmart – Web-based business operating system