Industrial Edge Computing. Where to put compute when the cloud isn't enough.
For ten years, "move it to the cloud" was the answer to every industrial-data question. For the last three, the answer has gotten more nuanced — because some computation cannot move to the cloud, some doesn't make economic sense to move, and some shouldn't move for security reasons. The new architecture has a name: industrial edge computing. Here's a practical version of what it is, where it lives, and how to think about the cloud-vs-edge decision in 2026.
The 30-second version
Industrial edge computing means putting purposeful compute at or near the equipment generating the data, rather than streaming everything to a central data center or cloud and processing it there. The compute can live on the device (PLC, RTU), on a gateway in the cabinet, on a server in the control room, or at the "near edge" — a regional data center serving a cluster of sites.
The driver is rarely about cost — it's about physics, security, and resiliencein that order:
- Physics: a 100 Hz vibration analysis can't ride a 30-second satellite link. Decisions that need to happen in milliseconds happen near the process.
- Security: some data shouldn't leave the customer's network at all. Edge processing keeps sensitive content local while exporting only safe derivatives.
- Resilience: the cloud goes down. The plant doesn't get to. Edge computing degrades to local autonomy when the wire to the cloud disappears.
The compute tiers — where things actually run
"Edge" by itself is too vague. In industrial settings there are four practical compute tiers, each with its own role:
A well-designed industrial system uses all five. The mistake operators make is putting things in the wrong tier — running cloud analytics for a millisecond decision (won't work), or running site dashboards on a public cloud (works, but a comms outage means blind operators).
The cloud-vs-edge decision framework
Six questions that determine whether something belongs at the edge or the cloud:
| Question | Edge if… | Cloud if… |
|---|---|---|
| Latency | Sub-second decision needed | Minutes or hours acceptable |
| Bandwidth | Raw data volume too large to ship economically | Already aggregated / sampled / compressed |
| Data sensitivity | Contains operational secrets or regulated data | Already aggregated to a safe-to-share derivative |
| Resilience requirement | Must keep working when the WAN is down | Cloud outage is acceptable |
| Workload characteristics | Steady-state always-on, fits a small box | Bursty, needs elastic compute, ML training, fleet-wide aggregation |
| Operational maturity | Team can maintain physical infrastructure at sites | Team prefers managed services over hardware ownership |
The right answer is almost always "both." Edge for resilience, latency, sensitive-data filtering. Cloud for fleet analytics, ML training, executive dashboards. The architecture question is which tier does what — not where to put everything.
The hardware landscape
The "industrial edge" hardware market has consolidated around a few patterns:
Hardened gateways (Tier 1)
- Stratus ztC Edge — fault-tolerant pair, hot-standby. Premium pricing, high reliability. Common in continuous-process plants.
- Schneider EcoStruxure IPC / M580 — Schneider's hardened compute + PLC combo. Strong if you're a Schneider shop.
- Bedrock OSA — secure-by-design industrial control + edge compute. SCADA + cybersecurity primitives in one box.
- Siemens IPC / Industrial Edge — Siemens's portfolio. Containerized workloads, AI inference. Strong in process industries.
- MultiTech Conduit / Cradlepoint NetCloud — cellular-first edge gateways. Popular in distributed-asset industries.
AI-capable site edge (Tier 2)
- NVIDIA Jetson Orin / IGX Orin — the de facto AI edge platform. Aevus uses Jetson clusters for inference workloads at the site edge.
- AWS Snowball Edge / Outposts — managed AWS hardware at the site. Pricier, but you get AWS APIs locally.
- Dell PowerEdge XR — ruggedized servers for industrial environments. Common where the customer wants standard server-class hardware in an industrial form.
Hyperconverged + virtualization (Tier 2/3)
For larger sites, VMware vSAN, Nutanix, or Proxmox running a cluster that hosts SCADA VMs, historian, dashboards, and edge analytics on shared hardware. Easier to manage than dozens of dedicated boxes.
What actually runs at the edge
The workloads that fit naturally at each tier:
Tier 0 (controller): control loops + safety
PID loops, safety interlocks, sequential function chart logic, alarm raising. Real-time, deterministic. Doesn't migrate elsewhere.
Tier 1 (cabinet gateway): cleansing, translation, edge anomalies
Modbus → OPC UA translation, value-quality validation, deadband compression, simple anomaly detection (stuck values, out-of-range, sensor disconnect). Local alerts when the cloud is unreachable.
Tier 2 (site server): full SCADA + local AI inference
The HMI the operator looks at, the historian, site-level analytics, vision-based anomaly detection on local cameras, predictive-failure inference for site-local assets. Aevus's site edge runs here for sites that need full operation during cloud outages.
Tier 3 (near edge): cross-site correlation
Operator dashboards aggregating multiple sites, regional asset management, training data pipelines for ML, regulatory reporting buffers.
Tier 4 (cloud): fleet-wide intelligence + ML
Model training, fleet-wide pattern detection, comparative benchmarking, executive dashboards, integration with corporate systems (ERP, CMMS, finance). The aggregated view of all sites — the place that knows your pipeline operations are 7% worse than industry average and which sites are dragging the number.
Edge security — the harder problem
Edge devices sit in the field. They're physically accessible. They have local network connections. They run software that needs updating. They are, structurally, the most exposed parts of an industrial system. Five practices that matter:
1. Hardware root of trust
TPM 2.0 or equivalent embedded secure element. Stores device identity, decrypts firmware-encryption keys, attests boot integrity. Without this, "secure boot" is just a checkbox.
2. Secure boot + signed firmware
Every stage of boot validates the next stage's signature against keys in the hardware root. An attacker who flashes malicious firmware to disk can't make it boot.
3. Containerized workloads with isolation
Edge workloads (analytics, protocol translation, ML inference) run as containers with mandatory access controls. Compromise of one workload doesn't pivot to others. AWS Greengrass, Azure IoT Edge, Eclipse Kura all support this; Bedrock OSA bakes it in.
4. Remote-attestation reporting
Each edge node reports its current firmware hash, container hashes, and config state to a central trust engine. Drift from expected state triggers investigation. Critical for federal compliance.
5. Physical-tamper detection
Case-open switches, accelerometers (detects movement), GPS for fixed assets. Tamper triggers cryptographic erase of secrets. Required for some regulated environments.
The connectivity patterns
How edge and cloud talk depends on what you're trying to do:
Continuous stream (most common, simplest)
Edge publishes telemetry to cloud at the cloud's preferred cadence. Cloud loss = data loss unless edge buffers. Patterns: MQTT/Sparkplug B with QoS-1 + local buffer, OPC UA Pub/Sub, AWS Kinesis Streams.
Store-and-forward (for intermittent links)
Edge stores everything locally, syncs when the link is available. Loss is bounded by local storage capacity, not link reliability. Critical for satellite-backed and cellular-fringe sites. Most modern edge platforms have this; older deployments often don't.
Filter and forward
Edge runs analytics locally, only forwards interesting events. Massively reduces bandwidth at the cost of fidelity. Common when raw data volume is too large to economically ship — vibration sensors, image processing, RF spectrum monitoring.
Bidirectional (control)
Cloud sends commands back to edge for orchestration (push new model version, update config, etc.). Rare for actual process control; common for system-management traffic. Aevus deliberately doesn't run this pattern — our cloud has no path to write to customer edge devices.
How Aevus uses edge
Aevus's reference architecture spans Tiers 2-4. Specifically:
- Tier 2 (site edge): a small Aevus edge collector (containerized, runs on Jetson Orin or x86 customer hardware) ingests the local historian / OPC UA server / Modbus polls. Runs local data-cleansing and value-quality scoring. Maintains local buffer for store-and-forward when the cloud link is degraded.
- Tier 3 / 4 (regional + cloud): Aevus's central intelligence platform consumes the filtered, compressed telemetry from each customer's edge collectors. Runs ML for predictive failure, cross-site correlation, fleet-wide pattern detection. This is where the actual product runs.
Critical to the architecture: traffic is one-way (edge → cloud) by design.The Aevus cloud has no path to write back to the customer's edge, and the edge collector has no path to write back to the customer's PLCs / RTUs. The boundary is enforced at the AWS Organization level via the IL-9000 service-control policy — not by application code that could be modified.
For evaluators: this is the property that makes Aevus deployable on critical infrastructure without the AI write-prevention question being a multi-month architecture review. The boundary is structural. Read the IL-9000 brief →
That's industrial edge.
If your team is deciding what to put at the edge vs the cloud — or evaluating an operational-intelligence platform that respects that boundary — Aevus is built around the right answer.
Related Articles
The 5 compute tiers and the cloud-vs-edge decision framework.
Where AI earns its keep in the control room.
NIST 800-207 principles applied inside the OT boundary.
Ready to see how this applies to your operation? Start a pilot conversation — no commitment, no field changes.