IIoT & SCADA

Connecting IIoT Sensors to SCADA: A Practical Integration Plan

Connecting an industrial sensor is only the first step in an Industrial Internet of Things (IIoT) project. The harder task is making its reading meaningful to the people and systems that use it. A temperature appearing on a dashboard is not enough if its equipment identity, units or freshness are unclear. A useful integration plan follows the measurement from the field device through the gateway to the supervisory control and data acquisition (SCADA) system.

1. Define the operating question and system boundary

Begin with a specific question: which pump is running unusually hot, where is energy use changing, or which tank reading needs investigation? Name the person who will review the information and describe the action available to them. This keeps the project focused on an operating need rather than collecting every accessible register.

Draw a simple inventory of sensors, controllers, gateways, networks and destination systems. Record who owns each component, its approved interface and its maintenance window. Distinguish monitoring data from commands. Adding visibility should not quietly create a new route for changing equipment settings.

2. Map meaning, not just protocol addresses

A protocol bridge can move data between interfaces without resolving what that data means. Create a tag dictionary covering equipment identity, source address, units, scaling, valid range, update interval and destination name. Confirm these details with the equipment documentation and the responsible engineer.

Carry quality and timing information alongside the reading. The OPC Foundation’s DataValue specification distinguishes the value, status and timestamps. That distinction matters when a sensor fails or a connection stalls: the last numeric value should not silently look like a fresh, valid measurement.

Test awkward cases explicitly, including negative readings, counter resets, missing values and unexpected scaling. Decide how the receiving system will display each condition.

3. Start read-only and protect the OT boundary

For an initial monitoring integration, request only the approved read access needed for selected tags. Read-only access reduces the permitted actions, but polling can still burden older equipment. Agree query rates and watch controller and network health during commissioning.

Operational technology (OT) has safety, reliability and availability constraints that differ from ordinary office IT. NIST’s OT security guidance provides a framework for considering those constraints and network segmentation. Review allowed communication paths, gateway placement, service accounts and remote access with the site’s OT owner.

If writes are later required, treat them as a separate engineering change. Specify who can issue a command, which values are permitted, how interlocks remain effective and how the outcome is confirmed. Retain existing safety responsibilities and obtain the appropriate site approval.

4. Make communication failures visible

Choose a transport policy that matches the measurement. A delayed energy total may remain useful for reporting; a delayed level reading may be unsuitable for an immediate operating decision. Define freshness limits and show when a reading has crossed them.

Where MQTT is used, its delivery settings are only part of the design. The OASIS MQTT specification distinguishes delivery qualities, including at-least-once delivery that can produce duplicates. Plan message identity, source timestamps and duplicate handling where needed. Broker delivery alone does not establish that a downstream application accepted a valid reading.

Also decide what the gateway retains during an outage, what happens when storage fills and how recovered history is distinguished from live data.

5. Use a concrete commissioning checklist

  • Compare selected source readings with the values shown in SCADA, including units and scaling.
  • Confirm timestamps, clock synchronisation and the visible treatment of stale or bad-quality data.
  • Simulate an approved sensor or network interruption and check the recovery behaviour.
  • Verify that the monitoring account cannot perform unauthorised writes.
  • Observe polling load under representative operating conditions.
  • Document configuration versions, ownership, rollback steps and escalation contacts.

Run these checks in an agreed test environment or maintenance window. Record evidence and unresolved exceptions rather than relying on a successful demonstration alone.

6. Hand over a maintainable integration

Common pitfalls include undocumented scaling, one shared privileged account, aggressive polling and a dashboard that hides communication gaps. Another is commissioning without deciding who will maintain the tag dictionary after equipment changes.

A realistic first outcome is a small set of trustworthy measurements with a tested path into existing operations. Predictive analytics can be considered once that foundation is understood. Skymics provides industrial connectivity, telemetry and SCADA integration. Discuss your equipment and monitoring requirement to scope a suitable first step.