Compare responsibilities rather than system names
Asking whether IoT or SCADA is better can miss the actual requirement. One may connect data across workflows while another supports existing process supervision. Define whether you need new data, presentation, analysis or commands, and what must continue if the new system stops.
An existing SCADA installation can receive camera observations without changing control circuits. A site without a central platform may begin with history and a small dashboard. Both approaches need a source of truth, access permissions and ownership; cloud or local deployment is not automatically suitable.
Read-only observation has very different consequences from writing machine commands. Successful transport does not establish safe control. Initial trials should specify read-only scope and inspectable separation from production control.
Scroll the diagram horizontally to inspect all details.
1. Definitions and responsibilities
SCADA means Supervisory Control and Data Acquisition. It collects data, presents status, alarms and supervisory commands; lower-level control often resides in PLCs or controllers. Do not characterize every SCADA path as hard real-time because network and design conditions differ.
Industrial IoT connects devices and information for monitoring, analysis and cross-system use. It can operate on premises, at the edge or in the cloud without public internet. The name alone establishes neither a shared SLA nor a common security level.
2. Compare verifiable requirements
- Function: distinguish status, history, analysis and commands; timing and permissions differ.
- Time: measure deadlines, latency, jitter and freshness on actual paths rather than assigning figures from a system label.
- Data: verify tags, quality, timestamps, units and historian meanings.
- Maintenance: identify responsibility for patches, backups, licenses, certificates and recovery throughout the lifecycle.
- Cost: include equipment, engineering, licensing, networking and downtime; no universal per-point price fits every site.
- Security: on-premises deployment and air gaps are not automatic protection; inspect access paths and actual maintenance.
3. SCADA, PLCs and SIS are different
SIS and safety functions need risk analysis, a safety lifecycle and applicable standards. SCADA or AI does not confer SIL automatically. Ordinary gauge reading supports observation, not replacement of independent protective signals.
Control projects require responsible engineers to define interlocks, permissions, fallback and authorization. Do not connect AI outputs to valve operation or machine shutdown simply because a protocol can carry them.
4. An illustrative coexistence architecture
A risk-separated starting point reads images at the edge, sends values and quality to separate storage and lets an authorized SCADA or dashboard consume them. Existing control remains independent, without pilot write-back.
Define the historical source of truth, duplicate-tag handling and missing-data behavior. Delayed observations must not appear on an HMI as newly measured values merely because connectivity has recovered.
5. Before expanding the system
- Inventory equipment, protocols, versions and access limits.
- Diagram monitoring, supervisory control and safety functions with explicit boundaries.
- Agree on a data contract and test read-only before considering write-back.
- Simulate connectivity loss, reordered data, certificate expiry and restart.
- Define operation during unreadable observations and responsibility for every stage.
- Agree on acceptance and rollback before modifying production operation.
Assess the architecture throughout its lifecycle
Costs include surveys, mapping, licensing, certificates, backups and downtime during changes, not only devices or platforms. A lower initial price may create greater maintenance burden. Compare equivalent scope and lifecycle periods.
Users need distinct missing, stale and unreadable states. Recovery can deliver many historical messages together; check original-time storage and ensure the HMI does not present them as fresh.
Before expansion, review evidence and maintainability: who changes settings, checks permissions and approves release? Safety responsibilities need their own assessment, not inferred certification from the chosen network or software.