Industrial Computing & IIoT — Engineering Decision Guide

Put compute at the edge when the decision is time-critical (closed-loop control, machine safety, sub-second anomaly response), when bandwidth to send raw high-rate data is impractical, or when the line must keep running if the internet drops. Use the cloud for fleet-wide analytics, long-term storage, model training, and cross-site dashboards. In practice most plants land on hybrid: filter and act at the edge, send summarized/exception data up. Decide per data stream, not per plant.

The tradeoff is latency, bandwidth, and availability versus scale and cost. Edge wins on response time and resilience because the data never leaves the floor to be acted on, and it slashes the bandwidth and cloud-ingest cost of streaming raw high-frequency signals. Cloud wins on elastic storage and compute for training models across many machines and sites. High-rate vibration or vision data is the canonical "process at the edge, ship the summary" case; slow trend data can go straight to the cloud.

Streaming everything to the cloud runs up ingest/egress bills and adds a round-trip latency and an internet dependency that a control or safety function cannot tolerate. Over-investing in edge hardware for data that is not time-critical wastes capital and adds fleet devices to patch and secure. Match the placement to the data stream's latency and volume, not to a vendor's default architecture.

Standardize on OPC UA when you need a rich, self-describing information model and interoperable machine-to-machine data across mixed-vendor equipment — it carries structured, typed data with built-in security. Use MQTT (typically with a Sparkplug B payload) for lightweight, scalable telemetry from many devices up to a broker/cloud over unreliable or bandwidth-limited links. They are complementary, and OPC UA now offers a pub/sub mode over MQTT that blends both. Below that, the fieldbus/industrial-Ethernet layer (Modbus, PROFINET, EtherNet/IP, EtherCAT) stays where it is for deterministic device I/O.

OPC UA and MQTT solve different problems. OPC UA models what the data means (a semantic, typed address space) and is built for interoperability and security across vendors — ideal machine-to-machine and machine-to-MES. MQTT is a minimal publish/subscribe transport built for many-to-one telemetry at scale over flaky networks; Sparkplug B adds the state and payload definition MQTT itself lacks. Picking one as a religion is the mistake — the modern pattern is OPC UA for structured interop and MQTT for scalable edge-to-cloud telemetry, not either/or.

Using raw MQTT without a payload standard (Sparkplug) leaves every integration bespoke and brittle. Forcing OPC UA through constrained, high-latency links where a lightweight telemetry transport belongs adds overhead. And bridging protocols without a gateway that enforces security re-opens the OT attack surface — see the network-security entry below.

Segment the plant network into zones (assets grouped by security need) connected only through controlled conduits, per IEC 62443 — the consensus OT-security standard. Assign each zone a target Security Level (SL 1–4) from a risk assessment and protect its conduits accordingly. Use the Purdue reference model as the layering guide and put a DMZ between IT (enterprise) and OT (control) so no enterprise host talks directly to controllers. Reference IEC 62443-3-3 for system requirements and 62443-4-2 for component requirements.

OT devices — PLCs, drives, sensors — were designed for reliability and long life, not authentication, and many cannot be patched on IT timelines. You cannot harden each device to IT standards, so IEC 62443 instead contains risk by segmentation: break the network into zones, allow traffic between them only through conduits you monitor and control, and size each zone's defenses to its assessed risk (SL). This is what stops a compromise in one area — or on the IT side — from propagating across the whole plant.

A flat, unsegmented OT network lets one infected device or one crossover from IT reach every controller. Skipping the IT/OT DMZ is the single most common architecture gap. Note that regulatory pressure is rising (e.g. the EU Cyber Resilience Act), so treating OT security as optional is an increasingly expensive bet.

An IT-side ransomware or malware infection spreads onto the plant floor and halts production, because enterprise and control networks share the same flat address space with no boundary. Once one host is compromised, controllers and HMIs are directly reachable.

No segmentation between IT and OT; no DMZ; unmanaged remote-access paths (vendor laptops, jump boxes) straight into the control zone; legacy devices with default credentials and no monitoring; and connecting brownfield equipment to the network faster than it can be secured.

1) Segment into IEC 62443 zones with a firewalled IT/OT DMZ — no enterprise host talks to a controller directly. 2) Inventory and monitor OT assets; you cannot protect what you cannot see. 3) Control and log all remote access; kill standing vendor connections. 4) Change default credentials and disable unused services on every reachable device. 5) Set per-zone security levels from a risk assessment and enforce them at the conduits.

A promising IIoT or predictive-maintenance pilot works on one line, then stalls — it never rolls out to the fleet, the dashboards go stale, and the ROI never materializes.

Starting from the technology instead of a specific, measurable problem; no plan for connecting heterogeneous brownfield assets; data with no owner, model, or governance; and a pilot architecture (bespoke integrations, no standard payload) that cannot be replicated at scale.

1) Anchor the project to one measurable outcome (downtime, scrap, energy) with a baseline. 2) Standardize the data layer early — a consistent protocol and payload model (e.g. OPC UA / MQTT-Sparkplug) so line two is a copy, not a rebuild. 3) Give data an owner and a contextualization model, not just a historian dump. 4) Design the pilot for replication from day one. 5) Prove ROI on one asset class, then template it across the fleet.