Introduction
Edge computing is one of the most discussed concepts in industrial automation today — and one of the most misunderstood. I regularly encounter two types of misapplication in practice: engineers adding edge compute to every system as a default architecture choice, and engineers dismissing edge computing as unnecessary complexity when it would have solved their core problem.
Neither approach is correct. Edge computing is a tool. Like all tools, its value depends entirely on whether it is the right tool for the specific job. In this article, I provide a practical engineering framework for making that decision — based on system requirements, not trends.
What Is Edge Computing in Industrial Automation?
Before discussing when to use it, it is important to be precise about what edge computing actually means in an industrial context.
Edge computing means processing data at or near the source of that data — on the factory floor, inside the machine, or at the network edge of the facility — rather than sending all data to a centralized cloud or data center for processing.
In industrial automation, the edge layer sits between the machine control layer (PLCs, drives, sensors) and the cloud or enterprise IT layer. Edge devices are typically industrial PCs, embedded Linux systems, gateway devices, or AI-accelerated compute modules positioned physically near the machines they serve.
The key characteristic of edge computing is locality: data is processed where it is generated, and only relevant results — alarms, aggregated metrics, model outputs — are sent upstream. This has direct engineering implications for latency, bandwidth, reliability, and security.
When Edge Computing Is Necessary
There are four conditions where edge computing is not just beneficial but necessary for a correctly functioning industrial automation system.
Condition 1: Real-Time Response Is Required
If your system requires decisions or responses in under 10 milliseconds, cloud computing is not architecturally viable. The round-trip latency to a cloud server — even on a well-performing enterprise connection — is typically 20–100ms, with variance depending on network load and routing. For real-time control loops, safety systems, or anomaly responses that must act within milliseconds, the decision logic must run locally on the edge.
Examples: vibration-triggered emergency stop, real-time quality rejection on a production line, vision-guided robot guidance with sub-10ms response requirements.
Condition 2: Internet Connectivity Is Unreliable or Unavailable
Many industrial facilities have poor or intermittent internet connectivity — remote mining operations, offshore platforms, distributed agricultural facilities, older factory buildings with inadequate IT infrastructure. In these environments, any system that depends on cloud connectivity for normal operation is operationally unreliable.
Edge computing allows the system to operate fully autonomously when connectivity is lost. Relevant data is buffered locally and synchronized to the cloud when connectivity is restored — but production does not stop because the internet is down.
Condition 3: High-Frequency Sensor Data Must Be Processed Locally
High-speed sensors — vibration accelerometers sampling at 10kHz, machine vision cameras capturing at 60fps, current sensors sampling at 1kHz — generate data volumes that are impractical to transmit to the cloud continuously. A single vibration sensor at 10kHz generates approximately 1.2 GB of raw data per day. Multiply that across a facility with hundreds of machines and the bandwidth requirement becomes prohibitive.
Edge processing solves this by doing the heavy computation locally — running FFT analysis on vibration data, extracting features from camera frames, computing RMS and peak values from current signals — and sending only the extracted results (typically 1000x smaller in volume) upstream. This makes high-frequency monitoring economically and technically feasible at scale.
Condition 4: Safety-Critical Systems Require Local Intelligence
Any system where a delayed or missed response creates a safety risk must have its safety logic running locally. This is non-negotiable both from an engineering standpoint and from a regulatory standpoint (IEC 62061, ISO 13849 do not permit cloud-dependent safety functions). Edge compute enables local AI-based safety features — vision-based presence detection, force anomaly detection — that would be impossible to implement with cloud latency.
When NOT to Use Edge Computing
Equally important is understanding when edge computing adds unnecessary cost and complexity without delivering proportionate value.
When Only Historical Analytics Are Needed: If your requirement is simply to collect operational data, store it, and analyze trends over days, weeks, or months, you do not need edge computing. Standard industrial gateways can aggregate and transmit this data to cloud platforms effectively without local processing. Adding an edge compute layer in this scenario adds cost (hardware, software, maintenance) with no functional benefit.
When Cloud Latency Is Acceptable: For applications where a 1–5 second response time is adequate — non-real-time alerts, dashboard updates, shift reports, non-urgent configuration changes — cloud processing is simpler, cheaper, and easier to maintain. Use cloud for what cloud does well. Reserve edge for what cloud cannot do.
When the System Is Small-Scale and Simple: A single machine or small system with straightforward monitoring requirements does not justify the infrastructure investment of edge computing. A direct cloud connection from the machine gateway is usually sufficient, more cost-effective, and easier to support.
When Data Volume Is Low: If your sensors generate modest data volumes that are well within connectivity constraints, there is no technical reason to process locally. The benefit of edge — bandwidth reduction — does not apply.
Edge vs PLC vs Cloud — Understanding the Architectural Role of Each Layer
A common source of confusion is conflating edge computing with PLC control or cloud analytics. These are three distinct layers with distinct responsibilities, and understanding the boundary between them is essential for correct architecture design.
The PLC layer handles hard real-time machine control — scan cycles in the 1–10ms range, direct I/O, motion control, and safety interlocks. PLCs are deterministic, isolated, and purpose-built for machine control. They are not designed for data analytics, AI inference, or network communication beyond their defined protocol interfaces.
The edge layer handles intelligence and preprocessing — running above the PLC but physically local to the machine. Edge devices process data from PLCs and sensors, run AI models, perform protocol translation, aggregate data for upstream transmission, and execute local decisions that require more compute than a PLC can provide but faster response than cloud can deliver. Edge devices are not real-time controllers — they support and extend the control layer without replacing it.
The cloud layer handles analytics and optimization at scale — processing historical data from many machines, training AI models, providing fleet-level dashboards, enabling remote access, and managing system configuration. Cloud operates on timescales of minutes to months. It makes no real-time control decisions.
Getting these boundaries wrong — trying to run real-time control on edge, or trying to implement safety logic in the cloud — is one of the most common and dangerous architecture mistakes in IIoT system design.
Industrial Use Case — Three-Layer Architecture in Practice
Consider a high-speed packaging line in a food production facility. The system architecture breaks down across the three layers as follows:
PLC layer: Siemens S7-1500 controls conveyor speeds, filling valve timing, sealing press force and dwell time, and label application actuation. Scan cycle: 4ms. All motion and safety logic executes here. No cloud dependency at this layer.
Edge layer: An industrial PC running Linux processes vibration data from accelerometers on the filling heads at 5kHz. A trained ML model (ONNX format, deployed via Docker container) runs continuous FFT analysis and detects the signature of filling nozzle wear before it causes product quality defects. When detected, the edge device raises a maintenance flag through the SCADA system. Response time: under 100ms. No cloud round-trip required.
Cloud layer: Azure IoT Hub receives aggregated OEE metrics, maintenance flags, and quality data from the edge every 5 minutes. A Power BI dashboard provides shift supervisors and plant managers with real-time production performance. Predictive maintenance models retrain weekly on accumulated data. Model updates are pushed back to edge devices automatically.
This architecture delivers real-time local intelligence (edge), operational transparency (cloud), and deterministic machine control (PLC) — each layer doing what it does best, with clean interfaces between them.
Selecting Edge Hardware for Industrial Environments
When edge computing is appropriate, hardware selection must consider the industrial environment. Consumer-grade hardware fails in industrial settings due to temperature extremes, vibration, EMI, and dust exposure.
For general-purpose edge compute in industrial environments, DIN-rail mounted industrial PCs (from vendors including Siemens, Beckhoff, Advantech, Kontron) are the standard choice. They offer wide temperature range operation, EMC certification, IEC 61000 compliance, and industrial M12 or D-Sub connectivity.
For AI-accelerated edge applications (vision inspection, predictive maintenance ML inference), NVIDIA Jetson AGX Orin or Intel NUC-based industrial platforms provide the required GPU/NPU compute in ruggedized form factors.
For lightweight protocol translation and data aggregation without heavy compute requirements, purpose-built IIoT gateways (from vendors including Moxa, Ewon, Secomea) are cost-effective and purpose-designed for industrial use.
Conclusion
Edge computing is a critical architectural layer in modern industrial automation — but its value is context-dependent. It is necessary when real-time local intelligence is required, when connectivity is unreliable, when high-frequency data must be processed locally, or when safety constraints demand local decision-making. It adds unnecessary complexity when these conditions are absent.
The correct approach to edge computing in industrial automation is requirements-driven, not trend-driven. Start with the system requirements — latency, connectivity, data volume, safety criticality — and let those requirements determine the architecture. When edge is the right answer, implement it properly. When it is not, do not add it just because everyone else is talking about it.