Edge computing on the factory floor: putting computation where the machine is

Three honest reasons to compute locally

The first is response time: if a result must influence the current cycle, the round trip to a remote service is too slow and too variable to rely on. The second is volume: high-rate vibration, image or waveform data is far cheaper to reduce at source than to transport in full. The third is independence: production should not stop because a link is down, so anything the equipment needs in order to keep running belongs locally. Requirements that do not fall into one of those categories — reporting, aggregation, cross-site comparison, model training — are usually better served centrally, where hardware is maintained by people who do that for a living.

Industrial hardware exists for reasons you will discover otherwise

An office-grade computer in a cabinet fails in specific, tedious ways: fans clog with dust, spinning storage dies from vibration, the machine will not restart after an unexpected power loss, and it runs hot enough in summer to throttle. Fanless enclosures, solid-state storage rated for write endurance, wide temperature tolerance, DIN mounting and proper immunity to electrical disturbance cost more and remove a category of intermittent problem. Also settle the boring physical questions: where it lives, how it is powered, whether it is on a protected supply, how it is cooled, and who has the key to the cabinet when it needs a hard restart at night.

You have just deployed software into a place with no support model

Edge devices multiply quickly and each one runs an operating system, an application and a configuration that will drift. Without deliberate management you accumulate machines nobody can list, patch or rebuild, which is both an availability problem and a security exposure. Decide up front how software is deployed and updated, how a failed unit is rebuilt from a known image, how configuration is held somewhere other than on the device itself, and when updates may be applied given that these machines sit on a production line. The plant IT team may reasonably decline to own equipment they cannot reach and cannot reboot.

Keep local computation out of the control path

Most edge deployments should observe and advise, not act. Once a general-purpose computer is permitted to send commands into machine control, its patch state, storage health and software quality become production safety concerns, and its behaviour under fault becomes something the risk assessment must consider. Where closed-loop action is genuinely the point — adaptive process control or camera-guided motion — treat the edge unit as part of the control system with the same change control, testing and access restrictions, and make sure the machine has a defined, safe behaviour when the unit does not answer.

Buffering is what makes the record trustworthy

A network drop should degrade the view, not create a hole. Local storage that holds data while a link is unavailable and forwards it afterwards is a small feature with a large effect on whether anyone trusts a historical dataset, since gaps that coincide with disturbances are exactly the periods worth studying. Decide how much can be held, what happens when the buffer fills, and whether forwarded data preserves its original timestamps rather than acquiring the moment it was received. Getting timestamps wrong at this layer produces analyses that appear to show effects preceding their causes.

Frequently asked questions

How do we decide what to process locally and what to send onward?

Ask what the result is for. If it changes something within the current cycle, it must be computed locally. If it is a high-rate signal you only need summarised, reduce it at source and forward the summary while keeping raw data locally for a short window in case an investigation needs it. If it informs a decision made hours or days later, send it onward. The mistake is transporting everything by default and discovering the network and storage cost afterwards.

Who should own plant-floor computers, engineering or IT?

Neither alone works well. Engineering understands the process consequence of a restart and controls physical access; IT understands patching, backup, identity and network security. The workable arrangement names a joint responsibility with explicit rules: engineering decides when a device may be taken out of service, IT defines the build standard and update process, and both agree the network boundary. What fails is an ownership vacuum, where devices installed by a project team are quietly maintained by nobody.

Does edge computing replace the need for a central data platform?

No, they answer different questions. Local computation handles immediacy and independence; a central platform handles comparison across time, lines and sites, and is where long retention and heavier analysis belong. A sensible architecture reduces data at the machine, forwards what has lasting value, and keeps enough raw detail locally to support an investigation. Treating the edge as a substitute for central storage tends to leave the plant with data trapped on devices nobody can query.