Edge computing in automation, minus the marketing

Edge computing is the least precisely used term in industrial automation, which is a competitive field. Stripped of the marketing it means one thing: running software on hardware near the machine rather than somewhere central.

The interesting question is not what it means, it is what belongs there.

The three tiers, honestly

The controller. Deterministic real time control. Anything that must happen every scan, or that stops the machine when it is wrong. Nothing that can wait belongs here, and nothing here should depend on anything above it.

The edge. Protocol conversion, buffering, aggregation, local analytics, inference, and providing a local interface when the network is down.

Central. Historian, reporting, cross site comparison, model training, anything needing data from more than one place.

The test for whether something belongs at the edge is a single question: what happens when the link to central goes down for two hours? If the answer is that the machine stops, the thing is in the wrong tier.

What genuinely belongs at the edge

Protocol conversion. A twenty year old machine speaking Modbus RTU, and a plant that speaks MQTT. Something has to translate, and it has to be near the machine.

Store and forward. Buffering data through a network outage, with original timestamps preserved. Cannot be done centrally by definition.

Vision and high rate signals. A camera producing images or an accelerometer at 20 kHz generates more data than anybody wants to send anywhere. Process locally, send the result.

Inference where latency rules. A reject decision within a hundred milliseconds cannot involve a round trip to a cloud region.

A local interface. An operator screen that still works when the plant network is down.

What does not belong there

Control. Repeatedly, because it keeps being proposed. An edge device runs a general purpose operating system with no timing guarantee and a patch cycle. It is not a controller, and putting an interlock in one is a decision that will be discussed at an inquiry.

Anything the PLC already does well. Counting parts, timing a sequence, scaling an analogue input. Moving these to an edge device adds a dependency and a failure mode for no gain.

Model training. Data goes central for that. Inference comes back.

The cost that is always underestimated

Every edge device is a computer.

It has an operating system that needs patching. Certificates that expire. A configuration that needs backing up. A disk that fills. A failure mode that requires somebody to know how to rebuild it.

Twenty machines with an edge device each is a fleet, and a fleet needs management: remote deployment, health monitoring, a rollback path, an inventory of what is running what version.

Deployments fail here far more often than they fail technically. The proof of concept works; the twentieth device is running an image nobody remembers building.

Security

An edge device sits between the plant network and something outside it, which is the definition of the position an attacker wants.

• Outbound connections only, initiated from the edge.
• Read only from the controller wherever the application allows.
• Certificate based authentication, with a renewal process that exists before the first certificate expires.
• A patching plan agreed with whoever owns the machine, because a device that cannot be patched during production is a device that is never patched.

Where to start

One machine, one gateway, one genuine question you cannot currently answer. Prove the value, then work out the fleet management before the second one, not after the tenth.