Industrial IoT is generating genuine value at industrial sites across Australia: condition monitoring on conveyor idlers that predicts failures before they cause downtime, vibration monitoring on rotating equipment that replaces time-based maintenance with condition-based maintenance, energy sub-metering that provides granular visibility of energy consumption by process area. The technology works.
The challenge is integration. Getting sensor data from a new IIoT device into an existing PLC and SCADA system, reliably, securely, and without disrupting the production control system, requires engineering thought that goes beyond simply connecting the device to the network.
The fundamental integration problem
Industrial IoT devices speak a different language from PLCs. A modern IIoT sensor typically uses MQTT or OPC-UA to publish data to a broker or server over an Ethernet/IP network. A Rockwell ControlLogix PLC communicates with field devices over DeviceNet, ControlNet, or Ethernet/IP using Rockwell’s own protocol stack. Bridging these worlds requires an integration layer.
The most common integration architectures are:
- OPC-UA to PLC: the IIoT device or its local gateway publishes data as an OPC-UA server. A Kepware KepServerEX OPC server aggregates this data and presents it to the SCADA system via OPC-DA or OPC-UA. The SCADA system reads the data and can write values back to PLC tags. There is no direct PLC integration; the data lives in the SCADA layer.
- MQTT broker with protocol gateway: the IIoT device publishes to an MQTT broker. A protocol gateway (such as a Red Lion device, or a Node-RED instance) subscribes to the broker, processes the data, and writes values to PLC input registers via Ethernet/IP or Modbus TCP. The data then lives in the PLC and is visible to SCADA via the normal PLC/SCADA communications path.
- Direct PLC integration via custom driver: some IIoT devices support direct communication to specific PLC platforms via custom function blocks or Add-On Instructions. This is the most tightly integrated approach but is platform-specific and requires PLC program modification.
OPC-UA: what it is and why it matters
OPC Unified Architecture (OPC-UA) is the current generation of the OPC interoperability standard. Unlike its predecessors (OPC Classic, which relied on Microsoft COM/DCOM), OPC-UA is platform-independent, encrypted, and designed for both machine-to-machine and vertical integration from field device to enterprise system.
OPC-UA’s security model is a significant step forward from OPC Classic. Communications are encrypted by default using TLS, and both client and server can authenticate each other using certificates. For OT environments where data confidentiality and integrity matter, this is an important distinction.
Kepware’s KepServerEX is the most widely used OPC server in Queensland industrial operations. It supports hundreds of device drivers, acts as both an OPC-DA and OPC-UA server, and integrates with SCADA systems from every major vendor. Most Citect and FactoryTalk installations in the Queensland mining and sugar sectors are communicating with at least one Kepware instance.
MQTT: the IIoT messaging standard
MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol designed for constrained devices and unreliable networks. An IIoT sensor publishes data to a topic on an MQTT broker; any subscriber to that topic receives the data. The broker handles routing and queuing.
MQTT brokers are simple to deploy. Mosquitto is a widely used open-source broker that can run on a small industrial PC or VM. Commercial brokers such as HiveMQ and EMQX offer additional features for production deployments.
The limitation of MQTT in a PLC integration context is that PLCs do not natively speak MQTT. Bridging from MQTT to PLC registers requires either a protocol gateway or an intermediary processing layer such as Node-RED.
Node-RED as an integration tool
Node-RED is an open-source flow-based development tool designed for connecting IoT devices, APIs, and online services. In an IIoT integration context, Node-RED can subscribe to MQTT topics, process and transform the data, and write values to PLC registers via Ethernet/IP or Modbus TCP.
Node-RED runs on any platform that supports Node.js. It has been deployed on industrial PCs, Raspberry Pi devices, and Linux VMs. Its visual flow editor makes it accessible to engineers who are not software developers, while its JavaScript-based function nodes allow complex processing logic when needed.
Node-RED in a production OT environment needs the same discipline applied to any OT software: version control, backup, change management, and monitoring. A Node-RED flow that is not documented or backed up is a reliability risk.
Security considerations
The most important security consideration in IIoT integration is network segmentation. IIoT devices should not be placed directly on the OT control network. They should be placed in a separate network zone, with a controlled conduit to the systems that need to consume their data.
The typical architecture:
- IIoT devices on a dedicated sensor network or DMZ-equivalent zone
- The integration layer (Kepware, Node-RED, or protocol gateway) in a zone with controlled access to both the sensor network and the OT network
- Firewall rules that permit only the specific protocols and destinations needed, with no broad permit rules
- OT SCADA reading data from the integration layer via OPC or direct PLC tags, not directly from IIoT devices
This architecture ensures that a compromised IIoT device cannot directly reach the OT control network. The integration layer is the controlled conduit, and the firewall rules at each boundary define what is permitted.
About the author
Dennis Murphy RPEQ developed IIoT integration frameworks for 2Censor (asset wear sensors) and Vayeron (Smart-Idler conveyor sensors) in 2020, and has designed AEMO real-time power price integration systems for Queensland sugar mills. Contact: [email protected]