By Travis Cox, co-director of sales engineering at Inductive Automation
Businesses are struggling to realize the full potential of digital transformation.
Regardless of the terms you want to use—Industry 4.0, IIoT, etc.—every industrial company in the world is trying to come to grips with WHAT this revolution means to them and HOW to get started.
Companies can certainly see the promise of digital transformation—the ability to get their operational data into all these cloud IT apps and do all kinds of amazing analysis, business intelligence and machine learning.
But there is an elephant in the room: most organizations are trying to drive digital transformation from the top down. If you try to approach it in a way that doesn’t work for the guy on the plant floor, your digital transformation efforts are going to go nowhere.
The reality of digital transformation is this: it must be implemented from the bottom up, with OT on board first. However, the operational world is extremely complex, involving hundreds of different protocols, communication mediums and legacy device knowledge.
We’ve been doing SCADA the same way for 40 years. We’ve always started with operational data that we need to monitor and control with a SCADA application. On day one, we solve the problem and go home very happy, but soon the enterprise or IT staff will come along and say, “Hey, we could use some of that data in our application.” So, we write a custom data-extraction application, which can pull some of the OT data and pass it off to the business system.
Over time, more of these requests come along and we write data-extraction tools that pull the information for other data needs. Eventually the system becomes so complex and brittle that we don’t want to make any changes or add more polls for data. Finally, OT says “Stop!”
At that point, we’ve killed innovation and prevented future applications from accessing any data.
The journey starts with the operational infrastructure and creating a migration strategy that implements the digital transformation but also meets all of the OT requirements. It boils down to a single, crucial concept: an architecture change. We need to stop connecting devices to applications with protocols and, instead, connect devices to infrastructure. At the same time, we need to provide a superior OT solution that meets the needs of operators that is plug-and-play, reliable and scalable.
This new architecture uses MQTT, a lightweight publish/subscribe protocol that enables message-oriented middleware architectures. This is not a new concept in the IT space; Enterprise Service Bus (ESB) has long been used for integration of applications over a bus-like infrastructure. With MQTT, device data is published by exception to a MQTT server, either on the premises or in the cloud. Applications subscribe to the MQTT server to get data; there’s no need to connect to the end device itself.
MQTT provides several benefits:
- Open standard / interoperable (OASIS standard & Eclipse open standard (TAHU))
- Decouples devices from applications
- Reports by exception
- Requires little bandwidth
- TLS security
- Remote-originated connection (outbound only; no inbound firewall rules)
- Stateful awareness
- Single source of truth
- Auto-discovery of tags
- Plug-and-play functionality
Look to the edge
So the big question is, “How do we get there from the brownfield world?”
There are hundreds of different polling protocols that require mapping in terms of name, engineering units and other metadata. Currently, our SCADA systems are connected directly to these devices with mappings defined in SCADA. To get to a new architecture, the answer is found with edge computing and protocol conversion.
Let’s say you have 10 Modbus devices connected to SCADA. You can deploy a single edge gateway, hardware, or software solution with support of Modbus and MQTT to push the polling closer to the PLC. You can poll more information, potentially at faster rates, and publish the values as they change to a central MQTT server. You can change the SCADA to connect and subscribe to the MQTT server to get the data instead of connecting to the end devices.
This is an incredibly important step for future-proofing your SCADA system. As you acquire new sensors or upgrade equipment, SCADA will immediately get access to that data without having to know about the end device. Of course, this implies that your SCADA system must support MQTT. In some cases, it’s not feasible to change the current SCADA system without huge upgrades. While the upgrade is inevitable, you can either have the SCADA system publish all its data to a MQTT server or install an edge gateway connected to the same PLCs to publish the data, so it’s accessible by third-party business systems and applications. Installations of edge gateways or new equipment can easily plug into the new environment.
With this new method, you connect all of your OT and other data into infrastructure, securely and reliably. Then you plug in a SCADA/HMI system. OT is happy because they have a better, faster, more scalable and more reliable OT solution. IT is very happy because they have all the data in infrastructure, so other applications can just plug in as needed and subscribe to information.
Data is openly shared throughout the enterprise. Innovation thrives. Creative new ways to use information are encouraged. You’ve provided a better OT solution, solved from the ground up. Now it’s possible for IT and the business to start leveraging cloud platforms, analytics, machine learning, and more.
And—just like that—your business becomes the industry leader.