By the 5Tech engineering team · Published June 2021 · Written for solution architects and OT/IT integration leads. This is an educational engineering guide; market figures are cited and qualified, latency ranges are labelled order-of-magnitude, and the architecture shown is an illustrative reference, not a specific installation.
If you are architecting Industrial IoT (IIoT), the decision that actually matters is not edge or cloud — it is where each individual decision is allowed to live: on the device, on an on-prem edge node, or in the cloud. That placement is a constraint-driven choice — latency, bandwidth, availability, and data governance — not a fashion. And the part that sinks projects is rarely the compute. It is the OT/IT boundary: the trust, timing, and ownership seam where the deterministic plant floor meets elastic IT.
It was never cloud versus edge
For a decade the reflex was to backhaul everything and analyze it centrally. On a modern line that reflex breaks in two places at once: the data pouring off cameras, PLCs, and IIoT sensors has outgrown what a plant can economically ship, and a subset of decisions carry constraints a WAN round trip cannot meet.
So the useful question is not whether to process at the edge. It is which tier a given workload belongs in, and why. Every workload has a natural home defined by four constraints — how tight its latency budget is, how much data it produces, what it must do when the network drops, and where its data is legally and commercially allowed to sit.
Compute placement is a constraint-satisfaction problem. Pick the highest tier that still meets latency, bandwidth, availability, and governance — and no higher.
Three tiers, not two
"Edge" is not one place. In practice IIoT architectures span three tiers, and mature deployments layer them rather than choosing one.
Device / field edge
Sensors, PLCs, RTUs, and embedded or on-sensor inference. Sub-millisecond-to-millisecond, deterministic, and the authoritative owner of raw process data. This is where control loops and safety functions live.
On-prem edge → cloud
A plant edge server or micro-cluster for local analytics, historian, and store-and-forward buffering; above it, the cloud for training, fleet management, and aggregation. Neither sits in the real-time or safety path.
A useful fourth option sits between plant and cloud: the telco / regional edge, standardized by ETSI as Multi-access Edge Computing (MEC), which hosts applications inside the operator network (ETSI ISG MEC). It matters for multi-site or mobile assets; for a single plant it is usually a distraction. The table below is a placement heuristic — the latency figures are order-of-magnitude and depend entirely on model, payload, and network, not benchmarks.
| Dimension | Device / field edge | On-prem edge | Cloud |
|---|
| Typical response (order-of-magnitude) | sub-ms – ms | ms – seconds | tens–hundreds ms + WAN |
| Bandwidth off-site | minimal (results only) | aggregated / filtered | full stream (costly) |
| Survives WAN outage | Yes — autonomous | Yes — buffers & runs | No |
| Data governance | data never leaves asset | stays on-site / on-prem | leaves the plant |
| Best-fit workload | control, safety, hard real-time | vision, historian, supervisory analytics | training, cross-plant, long-term |
Work backward from constraints and the placement is usually obvious. The mistake is forcing every workload into one favourite tier — pushing safety logic to the cloud, or hoarding raw video on a device that cannot store a shift's worth of it.
The OT/IT boundary is the hard part
Drawing three tiers is easy. The engineering is in the seam between them — where operational technology (OT), which is deterministic, long-lived, and safety-bound, meets information technology (IT), which is elastic, frequently patched, and built to "move fast." Those cultures have opposite defaults, and the boundary is where they are reconciled.
NIST's OT-security guidance is explicit that acceptable delay and jitter are application-specific, that real-time requirements must be defined, not assumed, that safety and availability come before confidentiality, and that ordinary IT security measures can themselves disrupt OT timing or safety (NIST SP 800-82r3). The standard way to structure the boundary is to segment the plant into zones (assets sharing a security level) connected only through controlled conduits, per ISA/IEC 62443, with an OT/IT DMZ so enterprise systems never talk directly to controllers.
Reference architecture. The device/field tier owns raw data and runs deterministic control; the on-prem edge buffers, analyzes, and bridges to IT; the cloud trains and aggregates but is never in the real-time or safety path. An OT/IT DMZ enforces the trust boundary via IEC 62443 zones and conduits. Telemetry flows up and signed models flow down across a WAN backhaul that may drop — while the device and on-prem edge tiers keep operating through the outage, disciplined by a shared PTP time base. (Illustrative reference architecture, not a specific installation.)
Data ownership, time sync, and buffering
Three details decide whether the boundary holds under stress. None of them is glamorous, and all three are where audits and outages find you.
Data ownership. Decide, per data class, which tier is the system of record. The field tier owns raw process data; the historian owns the retained series; the cloud owns aggregates and models. Ambiguity here produces two "truths" that quietly diverge. A vendor-neutral information model helps enforce it: OPC UA (OPC Unified Architecture, standardized internationally as IEC 62541) gives a platform-independent way to model and expose tags across heterogeneous equipment, so ownership and semantics travel with the data instead of living in tribal knowledge.
Time synchronization. The moment data crosses tiers, unsynchronized clocks make it unanalyzable — you cannot correlate a vibration spike with a control event if their timestamps disagree by tens of milliseconds. Distribute a shared time base with IEEE 1588 Precision Time Protocol (PTP), which targets sub-microsecond accuracy and underpins the 802.1AS profile used by Time-Sensitive Networking (TSN). Network Time Protocol (NTP) is fine for logs; it is not for correlating fast physical events.
Buffering. "Runs during a WAN outage" is a design commitment, not a hope. The on-prem edge needs an explicit store-and-forward buffer — commonly MQTT or a local log/queue — sized for the longest realistic outage, with backpressure, deduplication, and ordered replay on reconnect so nothing is silently lost or double-counted. Size it from a stated worst-case (how many hours dark, at what data rate), not from a good day.
The on-prem edge tier in practice: a ruggedized plant edge node aggregating field data, buffering through link outages, and bridging the OT/IT boundary.
Security zones — the tier you add is attack surface you add
Every node you place on the floor is another asset to authenticate, patch, and monitor. A defensible edge deployment layers controls rather than trusting one: a hardware root of trust (TPM or secure element) with secure boot and signed images; segmentation into IEC 62443 zones with the OT/IT DMZ as the only conduit; least-privilege, per-service identities with a real certificate lifecycle and key rotation; controlled and logged remote-vendor access; a software bill of materials with vulnerability management; and audit logging that reaches a SOC with OT expertise. Crucially, plan for recovery from a failed or interrupted update at an offline site — the update path is itself an attack and outage surface. Treat the whole thing as a dedicated OT security and change-control risk assessment; NIST is explicit that bolting on IT controls without OT context can disrupt the very timing and safety they are meant to protect.
Make the placement a number
Because each lower tier adds capital and standing operational cost, the decision to push a workload down should be a calculation, not a preference:
Annual value of moving a workload to the edge = latency/uptime gains + bandwidth & cloud-egress saved + data-residency value − ( edge hardware + OT/IT integration + time-sync & network upgrades + security & segmentation + fleet operations + lifecycle management )
Then price in the cost of being wrong. A safety-relevant function must be judged by what happens when the network, node, or model fails — not by its happy-path latency. That is why placement and criticality are linked: a control loop or safety function belongs at the deterministic device tier with validated fallback to a known-safe state; the cloud is legitimate for monitoring, decision support, and training, but never as the authority in a real-time or safety loop. Speed alone is not safety.
Operational lifecycle — the cost that outlives the pilot
Placement is decided once; the fleet is operated for years, and that is where budgets actually go. Design for it from day one:
- Provisioning & identity — treat nodes as immutable, cattle-not-pets: image-based, enrolled with a hardware identity, reproducible from infrastructure-as-code.
- Updates — signed over-the-air images, staged with canaries and automatic rollback, scheduled into maintenance windows; never a rolling update on the real-time path.
- Model drift — where models run at the edge, monitor input and output distributions, validate against a golden dataset in shadow mode before promotion, and keep sign-off with a process engineer.
- Observability — collect metrics, logs, and traces locally and forward when bandwidth allows, so a disconnected site is still diagnosable afterward.
- End-of-life — industrial hardware outlives its software support; plan certificate expiry, security-patch cadence, and hardware replacement before the equipment is unsupported and unpatchable.
Open frameworks reduce some of this toil: EdgeX Foundry, a vendor-neutral, Apache-2.0 edge platform under the Linux Foundation's LF Edge, gives a common device-connectivity and management layer instead of a bespoke one per site. It lowers the integration and maintenance burden; it does not remove the governance, security, and lifecycle obligations above.
What to remember
- Compute placement is a constraint problem: choose the highest tier that still meets latency, bandwidth, availability, and governance.
- Think in three tiers — device, on-prem edge, cloud — and layer them; don't force every workload into one.
- The OT/IT boundary is the real engineering: DMZ, IEC 62443 zones and conduits, and NIST SP 800-82r3's safety-first, timing-defined priorities.
- Nail data ownership (OPC UA), time sync (IEEE 1588 PTP), and store-and-forward buffering, or the boundary fails under stress.
- Every lower tier is added attack surface and lifecycle cost — justify it with a number, and keep safety loops off the cloud.
Where to start
Skip the platform debate. Take one workload and answer four questions in writing — its latency budget, its data rate, what must survive a WAN outage, and where its data may legally sit — and let those decide its tier. Then prove the boundary the boring way: pull the WAN cable and confirm the field and edge tiers keep running, timestamps stay aligned, and the buffer replays cleanly on reconnect. One workload placed on evidence will teach you more than any reference diagram.
If you want a second pair of hands on that boundary, book a free engineering consultation with 5Tech — we design and integrate industrial edge and IoT systems across the OT/IT seam. On the horizon, the tiers are converging on real-time networks (TSN and OPC UA over TSN) and on standardized regional edge via ETSI MEC; expect adoption to look very different in a greenfield plant than in one running decades-old equipment, and budget the migration accordingly.
References & further reading
- NIST SP 800-82r3 — Guide to Operational Technology (OT) Security: application-specific timing, real-time requirements defined not assumed, safety-first priority order, and how IT measures can disrupt OT.
- ISA/IEC 62443 series: zones and conduits, the segmentation model behind the OT/IT DMZ.
- OPC Foundation — OPC UA (IEC 62541): platform-independent industrial interoperability and information modeling.
- IEEE 1588 — Precision Time Protocol (PTP): sub-microsecond time synchronization; basis of the 802.1AS TSN profile.
- ETSI ISG MEC — Multi-access Edge Computing: reference architecture (GS MEC 003) for the telco/regional edge tier.
- LF Edge — EdgeX Foundry: vendor-neutral, Apache-2.0 open-source edge/IoT framework.
- IDC — Worldwide Edge Spending Guide, and Grand View Research — Edge Computing Market: market size and growth (differing methodologies).
- Gartner — What Edge Computing Means for I&O Leaders: the 2018 "75% by 2025" data-location forecast (target year now passed; directional).
The reference architecture diagram is an illustrative 5Tech schematic, not a specific installation.
Send 5Tech one workflow, inspection task, sensor problem, robotics challenge, or prototype idea. We will review it and suggest a practical next step. Start My Free First Phase — a free first review of one idea. If it is not practical, we will tell you.