SCADA vs IoT -
Understanding Industrial IoT
and SCADA Platforms (2026)

Back to Blog

What Is the Difference Between SCADA and IoT?

SCADA (Supervisory Control and Data Acquisition)

SCADA is a complete operational technology (OT) system with a 40+ year history in industrial automation. It defines the full workflow for industrial process supervision: data acquisition from field devices, real-time operator dashboards (HMI), alarm management with notification routing, historian database for long-term data storage, and in many configurations, supervisory control commands sent back to field devices (setpoint changes, valve commands, start/stop signals). SCADA has defined roles and defined outputs. An operator using a SCADA system sees live process data, acts on alarms, and accesses historical records - the same workflow whether running a water treatment plant in 1990 or a cloud-monitored oil field in 2026.

IoT (Internet of Things)

IoT is a broader technology category describing internet-connected devices that collect and transmit data. Consumer IoT covers familiar products: smart thermostats, wearables, connected appliances, voice assistants. Industrial IoT (IIoT) covers internet-connected industrial sensors, actuators, PLCs, and gateways. The key distinction is that IoT and IIoT describe the connectivity layer - the technology that gets data from devices to the internet. IoT does not inherently include dashboards, alarm management, historian databases, or operator interfaces. A connected pressure transmitter is an IIoT device. The system that receives its data, displays it to an operator, and pages them when the pressure goes out of range is SCADA.

IIoT (Industrial Internet of Things)

IIoT is the application of IoT connectivity principles to industrial environments. IIoT sensors and gateways transmit process data using lightweight, internet-native protocols - MQTT, CoAP, HTTPS - over cellular LTE, ethernet, or Wi-Fi to cloud platforms. IIoT is the technology layer that enables modern cloud SCADA systems to collect field data without proprietary communication networks. An IIoT gateway at a wellhead speaks Modbus to the local PLC and MQTT to the cloud - bridging the 40-year-old industrial protocol to the modern internet infrastructure.

How They Overlap

Modern cloud SCADA platforms are IIoT platforms with industrial-specific application layers added. The IIoT layer handles connectivity: sensors, gateways, MQTT messaging, cellular networks, cloud data ingestion. The SCADA layer handles operations: alarm management, operator dashboards, historian data, regulatory compliance reporting, PLC connectivity. The term IIoT-SCADA platform accurately describes systems that integrate both layers - which is what every serious modern industrial monitoring platform does. The distinction between "IoT platform" and "SCADA system" has become meaningful primarily when evaluating whether a platform provides complete operational functionality or just data connectivity.

How SCADA and IoT Work Together

The complete IIoT-SCADA architecture flows from physical measurement to operator action through a series of well-defined layers:

1. Field sensor measures a physical parameter. A pressure transmitter on a wellhead measures tubing pressure. A thermocouple reads pipe temperature. A flow meter measures instantaneous gas rate. These instruments produce signals - 4-20mA analog, pulse output, or digital - proportional to the measured parameter.
2. Sensor outputs a signal. The pressure transmitter outputs a 4-20mA current signal ranging from 4mA (zero pressure) to 20mA (full-scale pressure) across the wired loop back to the control panel. This analog signal is the raw measurement.
3. RTU or PLC reads the signal. The Remote Terminal Unit or PLC at the site has analog input cards that read the 4-20mA signal and convert it to a digital engineering value - for example, 12mA on a 0–3000 PSI transmitter becomes 1500 PSI stored in Modbus holding register 40001.
4. IIoT gateway reads data from the RTU/PLC via Modbus TCP. The cellular gateway at the site polls the RTU's Modbus registers on a configurable interval - every 30 or 60 seconds for most remote monitoring applications. It reads the current values of all configured tags: tubing pressure, casing pressure, temperature, flow rate, equipment status bits.
5. Gateway publishes data using MQTT over cellular LTE to cloud broker. The gateway packages the current tag values into an MQTT message and publishes it to a topic on the cloud MQTT broker (AWS IoT Core, HiveMQ, or similar). The cellular LTE connection carries this message over the internet to the cloud - the same network path used by any smartphone application.
6. Cloud SCADA platform subscribes to MQTT topics and writes to time-series database. The Merobix cloud platform subscribes to all site MQTT topics. As messages arrive, it parses the tag values, applies engineering unit scaling, writes each data point to a purpose-built time-series historian with a timestamp, and updates the live dashboard data for that site.
7. SCADA platform evaluates alarm rules. After each data write, the platform compares each tag value against its configured alarm thresholds. If tubing pressure drops below the low alarm setpoint - indicating a potential well shut-in - the platform generates an alarm record and routes notifications: SMS to the on-call operator, email to the supervisor, and a push notification to the mobile app.
8. Operator opens browser dashboard. The operator receives an SMS notification with a direct link. They open the Merobix web interface in any browser - on their phone, laptop, or office desktop - and see real-time pressure data, the alarm event, and a historical trend showing the last 24 hours of wellhead pressure. From this context they can assess the likely cause and decide whether to dispatch a technician or investigate further remotely.

This is the architecture Merobix uses in production deployments today. The IIoT layer - gateway, MQTT, cellular - handles connectivity. The SCADA layer - historian, alarm management, dashboard, notifications - makes the data operationally useful.

Key Protocols in IIoT-SCADA Systems

MQTT

MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe messaging protocol designed specifically for constrained devices and unreliable network connections - exactly the characteristics of cellular-connected field devices in remote industrial locations. A gateway "publishes" data to a named topic on an MQTT broker; the cloud platform "subscribes" to that topic and receives every published message. MQTT supports three Quality of Service (QoS) levels that guarantee message delivery even when cellular connections briefly drop: QoS 0 (at most once), QoS 1 (at least once), and QoS 2 (exactly once). MQTT brokers - Mosquitto (open source), HiveMQ, AWS IoT Core, Azure IoT Hub - aggregate messages from thousands of field devices simultaneously. Virtually all modern IIoT gateways support MQTT natively. For remote oil and gas monitoring over LTE cellular, MQTT is a widely used protocol for field-to-cloud data transport.

OPC-UA (OPC Unified Architecture)

OPC-UA is the industrial standard for interoperable data exchange between controllers, HMIs, historians, and SCADA systems - developed by the OPC Foundation and widely adopted across all major PLC and automation vendors. Unlike the older OPC DA standard that required Windows DCOM, OPC-UA is platform-independent and has built-in security (certificate-based authentication, encrypted transport). OPC-UA supports both client-server communication (a SCADA client reads data directly from a PLC OPC-UA server) and publish-subscribe (OPC-UA PubSub, which maps cleanly onto MQTT infrastructure). Siemens S7-1200 and S7-1500 PLCs have native OPC-UA servers. Allen-Bradley PLCs support OPC-UA through additional software. When connecting to modern PLCs in manufacturing or processing facilities, OPC-UA is frequently the preferred protocol for SCADA connectivity.

Modbus (TCP and RTU)

Modbus is the 40-year-old industrial protocol that still connects a large share of the field devices in oil and gas operations to SCADA systems. Despite its age, Modbus remains ubiquitous because of its simplicity, universality, and the enormous installed base of Modbus-capable devices - PLCs, RTUs, flow computers, variable frequency drives, analyzers, and hundreds of other field instruments. Modbus RTU runs on RS-485 serial links; Modbus TCP runs on ethernet. Every field gateway and every serious SCADA platform must support both variants. In the Permian Basin and throughout the oil patch, Modbus RTU is the standard communication protocol between wellhead RTUs and cellular gateways - a protocol decision made in the 1980s that is still the right choice for simple, reliable field communication in 2026.

EtherNet/IP

EtherNet/IP is Rockwell Automation's industrial Ethernet protocol, based on the Common Industrial Protocol (CIP). It is the required communication protocol for Allen-Bradley ControlLogix and CompactLogix PLCs, which are widely used across North American industrial automation. A SCADA or IIoT platform connecting to Allen-Bradley PLCs at compressor stations, pump stations, or processing facilities must support EtherNet/IP to read process data natively from the PLC without an additional Modbus gateway. Merobix supports EtherNet/IP for direct Allen-Bradley PLC connectivity.

How Merobix Supports All Protocols

Merobix field gateways support Modbus RTU, Modbus TCP, EtherNet/IP, OPC-UA, and MQTT natively. This means any field device - from a 1990s RTU running Modbus RTU on RS-485 to a modern Siemens S7-1500 with an OPC-UA server - can connect to the Merobix cloud platform without protocol converters, middleware, or custom integration work. The same gateway hardware and cloud platform serve a legacy Permian Basin RTU installation and a new compressor station with Allen-Bradley ControlLogix without any additional hardware. See our services page for PLC connectivity support options.

IIoT-SCADA Platform Comparison

Choosing between purpose-built IIoT-SCADA platforms and DIY cloud IoT approaches is one of the most consequential decisions in an industrial monitoring deployment. The comparison below illustrates the key differences:

Capability	Merobix	DIY cloud IoT + custom build	General-purpose cloud IoT service	On-premise SCADA + MQTT
Setup time	1 week	3–6 months	3–6 months	Weeks to months
Industrial alarm management	Included	Custom build required	Custom build required	Included (on-premise server)
Historian included	Yes - cloud time-series database	Custom build required	Partial (add-on time-series service)	Yes (requires server)
PLC connectivity	Modbus, EtherNet/IP, OPC-UA	Custom gateway code	Custom gateway code	All protocols (on-premise)
Operator dashboard	Included	Custom build required	Third-party BI tool / custom	Included (on-premise HMI)
Platform cost	Custom quote - all-inclusive	Cloud services + development cost	Cloud services + development cost	Per-server license + modules
Oil & gas specialization	Primary market	General cloud	General cloud	General industrial

The central argument for purpose-built IIoT-SCADA over general-purpose cloud IoT platforms is straightforward: general cloud IoT services provide excellent data ingestion and storage infrastructure, but they do not include dashboards, alarm logic, industrial historian formatting, compliance reporting, PLC connectivity drivers, or operator interfaces. Building those capabilities on top of a general-purpose cloud IoT service requires months of custom software development - creating a de facto SCADA system from scratch using cloud primitives. The ongoing maintenance burden of that custom codebase falls entirely on the industrial operator's internal team. Purpose-built IIoT-SCADA platforms like Merobix provide all of those capabilities out of the box, maintained and updated by the vendor as part of the subscription. For most industrial operators, especially in oil and gas where IT resources are limited, the build-vs-buy decision clearly favors purpose-built platforms.

Benefits of a Unified IIoT-SCADA Platform

Single platform for all data. In a unified IIoT-SCADA platform, there is no middleware or integration layer between the IoT connectivity layer (gateway, MQTT) and the SCADA visualization layer (dashboard, alarms, historian). Data flows directly from field device to operator display with no intermediate data transformation, translation service, or API call chain. When a pressure transmitter reads 1500 PSI, that value appears on the dashboard within seconds - not after traversing a custom integration pipeline that could introduce latency, data loss, or errors.

No middleware complexity. DIY approaches that combine separate IoT data brokers with SCADA software require ongoing integration maintenance. API changes at the IoT platform level break SCADA data ingestion. Schema changes in the historian require updates to the ingestion pipeline. Security patches at one layer may introduce compatibility issues with another. A unified platform eliminates all of this integration complexity - one vendor, one architecture, one support relationship.

Faster deployment. A unified IIoT-SCADA platform configures connectivity and visualization together during a single onboarding process. The vendor configures gateway communication protocols, tag definitions, alarm setpoints, and dashboard layout as a single workflow. Merobix deployments go from contract execution to live data on a browser on a scoped timeline. Custom IoT + SCADA build projects routinely take 3–6 months before an operator sees any live data.

Lower ongoing cost. One vendor, one subscription, one support contact, one contract renewal. Compare this to a DIY approach that might involve a general-purpose cloud IoT service, a separate visualization tool, a custom historian integration, and a contracted development team to maintain the integration - each with its own cost, contract, and support relationship.

IIoT-SCADA for Oil and Gas

The oil and gas industry presents the prototypical IIoT-SCADA use case: geographically dispersed assets at remote locations, limited local IT infrastructure, cellular as the only viable communication medium, legacy Modbus field devices that must continue to function, and safety requirements that demand reliable alarm delivery and data integrity.

Wellhead monitoring. Wellhead pressure transmitters and temperature sensors output 4-20mA signals to a Teltonika RUT956 cellular gateway configured for direct analog input - or to an existing RTU via Modbus RTU. The gateway transmits data via MQTT over LTE to the Merobix cloud. Operators see real-time wellhead pressure and receive SMS alarms within 60 seconds of an abnormal condition. See our complete wellhead monitoring system guide for hardware specifications.

Compressor stations. Allen-Bradley CompactLogix or ControlLogix PLCs at compressor stations expose process data (suction pressure, discharge pressure, temperature, unit run/stop, fault codes) via EtherNet/IP. The Merobix gateway reads PLC tags directly over EtherNet/IP, transmits to the cloud, and generates SMS alarms on compressor trips or out-of-range conditions. Field supervisors diagnose faults from any browser before dispatching a technician.

Pipeline flow computers. Electronic flow computers at measurement points communicate via Modbus TCP over ethernet or Modbus RTU over RS-485. The Merobix gateway polls flow computer registers for differential pressure, static pressure, temperature, and calculated flow volumes. Accumulated volumes and instantaneous rates appear in the cloud historian, supporting both operational monitoring and regulatory reporting.

The Merobix IIoT-SCADA stack deploys across all three of these asset types in a single unified platform - deployed on a scoped timeline without custom software development. For additional oil and gas applications, see our guides on pipeline SCADA monitoring and natural gas SCADA monitoring.

Frequently Asked Questions