Industrial Automation Meets IT: Key Technologies Making an Impact

• Get practical explanations of key IT technologies, such as MQTT, containers and DevOps specifically from an operations technology perspective to help OT professionals understand concepts that are increasingly important to industrial operatons.
• See real-world implementation examples of these technologies in industrial settings.
• Insights on how industrial organizations are adapting to and benefiting from the integration of IT and OT.

The convergence of information technology (IT) and operations technology (OT) has become a well-worn topic over the past decade. And while many operations technology professionals remain focused on the core industrial technologies they've traditionally worked with, the business realities of having a connected enterprise have led IT professionals to learn more about operations technologies and, likewise, required operations professionals to learn more about and more frequently work with IT technologies.

To better understand the real-world impacts of this shift, Automation World connected with Kevin McClusky (KM), Inductive Automation's chief technology architect for a recent episode of the Automation World Gets Your Questions Answered podcast, to help our audience get a better grasp on the IT technologies they should be most aware from an OT perspective. 

McClusky is a great connection to learn about this from because this is the space Inductive Automation has always existed in with its Ignition platform. This platform is designed to work with standard IT technologies such as SQL and Python, and operations technologies like OPC UA to develop applications for SCADA and HMIs as well as connect data and applications from the plant floor to the front office and with supply chain partners.

AW: MQTT is a messaging technology originally designed for industry in 1999 for a project at Phillips 66. But then it gained wide acceptance after high-profile applications with Facebook Messenger and Instagram. From an OT perspective, what should our audience understand about MQTT and its use in industry?

KM: To keep it relatively simple, think of MQTT (message queueing telemetry transport) as having two different layers. One would be a simple MQTT communication capability. That is, if you see a device, app or platform that says we support MQTT, it's going to support simple MQTT communications. Then there are the data formats on top of MQTT that allow systems to have some sort of a contract language between them.

Essentially, MQTT itself is the communication layer and then, on top of that, you have data formats. 

I think the most important thing to understand about MQTT is that it’s a great communication protocol for sending standard, simplified data between one system and another. But if you want to have a format for that data being communicated, then you need to have an agreed-upon contract between the different software packages being used. The most common one right now is Sparkplug — it guarantees that those data points being transmitted are going to have timestamps associated with them and they're going to have a quality that's associated with them. For example, if the originating system has engineering units, you're going to be able to see the speeds or the psi. It's going to have some sort of measure in there that will give you a guarantee of knowing when something's connected or disconnected if you're using the Sparkplug format.

AW: Can you give us some examples of how you're seeing MQTT used most often in industry?

KM: The earliest adopters of MQTT were mainly using it to communicate data from a plant or other location to a central location, which could be the cloud, a central data center or a corporate office. 

This concept of the virtual machine basically evolved to the point where the goal was to have all the applications running in the virtual machine — without having to copy all of the operating system too — into a small container that could run on another operating system. That's where the idea of containers came from. They’re basically a contained application that is intended to run lightweight on a platform that will run containers.

What makes containers so attractive is that you can potentially run containers on edge devices instead of needing to have server farms to run virtual machines.

AW: What are containers most often used for in industrial applications?

KM: You can get edge devices that are small industrial PCs that support containers. And a growing number of PLCs and PACs support containers as well. So, if a device says it supports containers, you can take applications that are delivered in containers and run them on those systems.

With Ignition, for example, we have a release where, instead of using an installer to place it in the operating system, you can just spin up the container on any device that supports containers and run it from there. 

Essentially, containers are another way to run applications in a way that is self-contained from a security standpoint. Containers open up the possibility of running significant applications at the edge of the network where you might previously have needed a virtual machine, which requires additional hardware.

AW: DevOps is another topic like containerization that's been well known in IT circles for years and is now gaining interest in the operations space. So, what is DevOps from an OT perspective?

KM: To understand DevOps, think about when you're developing an application that’s going to be used on the plant floor or out in the field. Either way, you're going to go through a development cycle followed by deployment, which involves assessing the operations needed to get it packaged up in a way that it's going to be able to run well.

Consider the traditional SCADA approach of development and deployment where you open an application designer and make the changes you want to see. Once the changes are made, you hit the save button, publish it to production and then you’d be done with it. But that immediately makes changes to your production system without first testing it. If something breaks you would just fix it right away.

The process with DevOps is very different because it’s more careful. In DevOps, following the design and development stage, there’s a test cycle where people from different parts of operations, such as quality, will come in and test the software first and get any issues addressed before going through to deployment.

There are a variety of tools available for DevOps that have been used in the IT space for a long time and are now available to be used on the OT space as well. Git is one of the most popular ones.

AW: To clarify, DevOps is not just related to creating apps to, say, check temperature and vibration on a troublesome machine. This is something that can be used for SCADA or other types of production operations systems. Is that correct?

KM: Yes, absolutely. And I'd say, at this point, it’s not that most of our customers are using DevOps now, but our most advanced customers are all using DevOps in some way on the SCADA side for industrial data visualization, enterprise visualization and sometimes for HMI applications as well.

• 4 Automation Trends Impacting Manufacturing 
• Inside the IT/OT Platform Decision at Entegris 
• Scaling IIoT Across Operations and into the Enterprise