Lokesh Chennuru What the references say
Three documents, none of them vendor marketing, frame this decision soberly.
ISA-95 / IEC 62264 gives the level model: sensing and control at levels 0–2, site operations systems — historians, MES, maintenance — at level 3, enterprise systems at level 4. Its lasting value is vocabulary: every proposed data consumer can be placed on a level, and every integration question becomes “which levels does this connect, in which direction?”
IEC 62443 supplies the security architecture: partition the plant into zones of equipment with common security requirements, and treat every communication path between zones as a conduit that must be defined, justified, and protected. The cloud is simply the outermost zone — nothing about it is forbidden, everything about it must be deliberate.
NIST SP 800-82 Rev. 3 turns that into operating guidance for OT: minimise exposure of control systems, broker data outward through demilitarised layers rather than opening inbound paths, and assume that availability — not confidentiality — is the asset being protected.
None of these documents says “edge good, cloud bad.” All three say: know your boundary, and make crossing it a designed act.
What it means on the plant floor
The practical question is never “edge or cloud” for the plant as a whole — it is “where does each function live?” A working split for heavy industry:
| Function | Where it lives | Why |
|---|---|---|
| Control loops, interlocks, safety functions | Edge, always | Sub-second timing, availability first, no external dependency tolerable |
| High-rate condition signals (vibration waveforms, fast electrical data) | Acquired and processed at the edge; features and context forwarded | Raw waveforms are heavy and mostly redundant; the decision needs the feature, the state, and the timestamp |
| Site operating views, downtime and historian context | Site level (ISA-95 level 3) | Operators and maintenance act here; it must work when the WAN does not |
| Fleet comparison, long-horizon trends, model training, cross-site benchmarks | Cloud | Elastic storage and computation genuinely pay for themselves here — this is what the cloud is for |
| Enterprise integration, remote expert access | Cloud or DMZ-brokered, read-only outward by default | The conduit is the product: defined, monitored, one-directional unless proven otherwise |
The recurring failure pattern is not choosing the wrong tier — it is skipping the middle: streaming raw signals to a cloud platform before edge context (operating state, asset hierarchy, units, timestamps) is preserved, then discovering the data cannot support the decisions it was collected for.
The three decisions this should change
- Write down what never leaves the cell. Control, safety, and anything with sub-second action requirements stays at the edge as a matter of policy, not per-project debate. Putting this one paragraph in the architecture standard ends a hundred future meetings.
- Make cloud earn its tier with a named workload. “Cross-site bearing-fleet comparison,” “12-month energy trend,” “model training on labelled stoppages” are cloud justifications. “We might want the data later” is storage cost plus attack surface. If the workload cannot be named, the data waits at level 3.
- Assign one owner per conduit. Every zone crossing gets a named owner who can answer: what crosses, in which direction, read or write, monitored how, and shut off by whom. The IEC 62443 conduit concept fails in practice exactly when this name is missing.
Where it stops being useful
- A matrix is not a site security review. Zone and conduit design must reflect the actual network, vendors, remote-access contracts, and legacy equipment — generic tables, this one included, only structure the conversation.
- Latency and cost claims are site-specific. Any document quoting universal round-trip times or cloud-vs-edge cost ratios without your traffic profile is selling something. Measure on your own links; model with your own volumes.
- Validated and regulated environments add constraints. Where GxP or safety certification applies, system boundaries follow validation status as much as architecture logic — the matrix above is the starting point, not the approval.
Sources
- ISA-95 / IEC 62264: Enterprise-control system integration International Society of Automation / IEC
- IEC 62443 series: Security for industrial automation and control systems International Electrotechnical Commission
- NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security National Institute of Standards and Technology
Frequently asked
Should industrial data go to the cloud or stay at the edge?
Both, by function. Control, safety, and sub-second decisions stay at the edge unconditionally. High-rate raw signals are processed near the machine, with features and context forwarded. Cloud earns its place for cross-site comparison, long-horizon trends, model training, and elastic storage — after edge context is preserved and the security boundary is explicit.
What is the ISA-95 model in simple terms?
A level model for where industrial functions live: level 0-1 is sensing and basic control, level 2 is supervisory control, level 3 is site operations (historians, MES), and level 4 is enterprise systems. It gives teams a shared vocabulary for deciding which level a new data consumer belongs to — and which levels it must never reach back into.
Does IEC 62443 prohibit cloud connections from the plant?
No. It requires the connection to be deliberate: the plant is partitioned into zones, every zone-to-zone communication path is a defined conduit with security requirements, and exposure is minimised. A read-only, outbound-brokered path from a DMZ is a legitimate conduit; an analytics service with write access into the control network is a design failure.