12 month warranty Request a Quote Technical Support
Sign In

Edge Computing vs Cloud-Only Analytics for IIoT: When the Machine Must Decide Before the Ping Returns

Aug 22, 2026
KY Automation
Selection Guide
Contents [hide]

    A vibration sensor on a 3,500-ton stamping press detects a bearing defect signature at 10:03:14. If the data travels to a cloud analytics platform 200 milliseconds away, the alarm arrives at 10:03:14.4 — but the press completes its stroke in 180 milliseconds. By the time the cloud says stop, the die has already hit the workpiece with a compromised bearing, producing a bad part and accelerating the bearing failure. This is the fundamental case for edge computing in industrial IoT: when the decision latency budget is shorter than the round-trip time to the cloud, analytics must run at the edge. This article maps when to process at the edge, when to use the cloud, and when — most commonly — to use both in a tiered architecture.

    What Edge Computing Means in an Industrial Context

    Edge computing in IIoT is not a specific device category — it is a deployment location. An edge compute node is any processing resource physically located at or near the machine, typically in the same cabinet or on the same LAN segment, running analytics that operates on data before it leaves the facility. It can be an industrial controller that also runs analytics — like the Opto 22 GRV-EPIC-PR1, which executes IEC 61131-3 control logic alongside Node-RED flows and MQTT publishing on a real-time Linux kernel — or a dedicated edge appliance like the i-Edge-boxxed Box PC that runs Ignition EDGE for data collection and visualization at the machine level. For high-availability applications, the Emerson PACSystems RX3i CPL410 combines redundant control with edge computing capability, running analytics on the same platform that executes the control program.

    The Latency Decision Boundary: Four Tiers

    • Sub-10 ms: Edge only. Machine protection, closed-loop vibration compensation, safety interlock override. The data never leaves the controller.
    • 10–100 ms: Edge for response, cloud for history. Process tuning adjustments, quality hold/release decisions. The edge acts; the cloud records and learns.
    • 100 ms–1 second: Edge optional, cloud viable. OEE dashboards, energy alerts, predictive maintenance notifications on a well-engineered LAN/WAN.
    • Above 1 second: Cloud preferred. Multi-site benchmarking, supply-chain triggers, long-term trend analysis. The latency budget accommodates cloud processing queues.

    Bandwidth Economics: The Cost of Sending Everything Up

    A single three-axis vibration sensor streaming 10 kHz FFT spectra generates roughly 8 GB of data per day. At cellular data rates, transmitting this to the cloud costs more in monthly connectivity than the sensor cost. Edge processing compresses this data at the source: the edge node computes the FFT, extracts bearing defect frequencies and RMS trend values, and transmits only the reduced feature set to the cloud. The raw waveform stays in a local ring buffer, retrieved only when an anomaly investigation requires it. This local-preprocessing, cloud-aggregation model — data reduction at the edge — is the economically viable architecture for high-sample-rate condition monitoring at scale. Browse PLC controllers and PAC platforms for edge-capable control hardware.

    When Cloud-Only Makes More Sense

    Cloud-only analytics remain the right choice when data is naturally aggregated across sites and decision latency is measured in hours or days. A corporate energy manager comparing specific energy consumption across 12 plants does not need millisecond data — they need hourly aggregates with site-level normalization. Running this in the cloud avoids deploying analytics infrastructure at each site. Similarly, machine learning model training — which requires large historical datasets from multiple machines to achieve statistical significance — is inherently a cloud or data-center workload. The trained model then deploys to the edge for inference. This edge-for-inference, cloud-for-training split is the dominant pattern in industrial AI deployments today.

    Edge computing does not replace the cloud — it filters the firehose of machine data down to the stream that is actually worth transmitting, storing, and analyzing centrally. The question is not edge or cloud, but what processing belongs at each tier.
    Contents