Lots of talk can make it difficult to find the central truth about a topic and understand the best path forward. This was never truer than it is about the Industrial Internet of Things (IIoT) and all the capabilities and benefits it can give to control and automation applications. It often seems like IIoT can do absolutely everything, which means many users get overwhelmed and don't do anything with it. This is where a little practical guidance can help.
"Many people are excited about IIoT's potential and possibilities for solving problems in the process industries and elsewhere in manufacturing, but they don't know where to start," says Benson Hougland, vice president of marketing and product strategy at Opto 22, which designs and manufactures industrial automation and IIoT systems, such as its groov EPIC edge-programmable industrial controller.
Hougland believes the right way to look at IIoT is simply as a way to solve persistent industrial automation problems, and suggests that users start their digital transformation in the field. "Process control still faces many of its age-old performance and optimization problems, as well as new ones like dealing with information technology (IT) and cybersecurity. We believe the best way to solve them is at the edge," says Hougland. "Whether we're talking about instruments, 4-20 mA signals, or pump and motor statuses, this is the point where the physical and digital worlds meet, and where industrial data originates. Of course, PLCs, PACs and similar devices have been on the edge for a long time, but they're typically purpose-built for specific processes. As a result, they weren't always as good at releasing their data, or sharing it as easily and securely as IIoT requires."
First, flatten the architecture
"Usually, when IIoT is implemented in the field, it involves stitching together controls, PCs, HMIs, OPC, firewalls, gateways and servers, and now reaching up to cloud services to accomplish a given task," explains Hougland. "Getting all these pieces to work together is challenging because each component reaches across multiple technical domains—each with its own operating costs (Figure 1). Plus, users also have to manage security vulnerabilities between each system or device to reduce or eliminate attack vectors. With this kind of architecture, it’s difficult to do IIoT, especially in brownfield applications with lots of existing equipment and heavy reliance on IT departments .
"Consider the smartphone in your pocket though. Nowadays, there's less need for multiple devices to do things like navigation, taking photos, or measuring distances because mobile devices are really powerful computers that can do all those things, whatever a user needs, with different apps. Likewise in process control, we can eliminate the need for multiple traditional technologies when we apply the ideas of mobile computing."
Hougland adds it’s not necessary to rip out legacy PLCs and I/O systems to get started with IIoT because industrial systems combining Ethernet gateways and edge-programmable controllers can connect and communicate with them, unleash and share their data, all while adding secure barriers.
“One thing's for sure—like the smartphone example—if the new approach isn’t as good or better than the old way, no one will adopt it,” adds Hougland. “The same holds true for process controls. This new approach must be simpler, safer, cheaper, easier to maintain, and more secure to be considered for industrial operations.”
Uncoupling for flexibility, security
In traditional control systems and networks, each sensor, analyzer, flowmeter, PLC, instrument or other device communicates directly with—and is tightly coupled to—other specific pieces of software on the operations level, such as proprietary drivers, HMIs or historians. As these connections increase, architectures become complex and brittle, inhibiting the connectivity and scalability required for IIoT applications. Complexity also introduces security concerns because each connection may require monitoring different ports, and each application may follow different security practices, increasing potential attack vectors. All of this places a burden on IT groups to understand and maintain infrastructure related to unfamiliar operations technology (OT) systems.
"OPC-UA and other fieldbuses or Ethernet protocols can help broker these links. However, there are still many individual, point-to-point connections, and they all have to be managed, including many network ports that are often left unsecured. Many users try to shift this responsibility to the IT department, but they often refuse because they don’t know how to deal with OT devices and fieldbus networks," says Hougland. "The MQTT publish-subscribe messaging protocol removes many of the former, inflexible connections by decoupling devices from software. With MQTT, devices like PLCs can publish their data to a central server, called a broker, and other interested users and devices can subscribe to that data. This means there's just one network port to manage at the broker, and data can flow wherever it’s needed." (Figure 2)
Decoupling software and devices from each other with MQTT can make entire process applications easier to maintain with:
- Flexible architectures that allow any client to access process data it needs without changing the infrastructure;
- More efficient communications due to minimal overhead required by publish-subscribe;
- Better performance by transmitting data only when changes occur, rather than cyclically;
- Improved security due to only one open port on the broker server, meaning only one place to manage and maintain user and data access; and
- Simpler tag management and global discoverability, and devices as the single source of truth for published data.
This architecture makes IIoT benefits possible. For instance, once sensor, instrument, I/O, controls and other equipment and software data have been decoupled, it’s possible to share that data between machines to bring that data into maintenance databases, inventory and financial systems, or send it up to cloud-based analytics platforms (Figure 3). "Controls can still be connected to their local PLCs or RTUs, but MQTT can push (publish) that controls data to a central server, and allow other applications (subscribers) to pull data into other parts of the organization, simply and securely," adds Hougland.
Just as devices and software in an individual application can be decoupled and simplify communications with MQTT, Hougland explains that oil pads or wellheads, machines, production lines, or even functions spread among separate facilities can be linked and coordinated in the same way using publish-subscribe network architectures.
First, suppliers and managers of OEM equipment like to know how their products are performing onsite, so they can evaluate, support and apply updates. However, this traditionally meant asking a client's IT department to open a network port or allow a tunnel through their firewall, which creates security issues. Instead, an edge-programmable controller inside the firewall can be used to manage OEM equipment by pushing data to a secure MQTT broker outside the firewall, where data consumers like the supplier can subscribe to it. MQTT connections are always outbound, so they don’t require firewall changes, and subscriber connections can be secured with authentication and encryption.
Second, users that need to acquire multi-facility data used to build complex, private poll/response networks from their corporate headquarters to each site, such as plants, tank farms and warehouses, and usually hired Cisco, AT&T and other suppliers to implement them. Now, they can use edge devices at each facility to push process values to a central, MQTT server over public TCP/IP networks, secured with TLS/SSL encryption and trusted third-party certification.
Third, users seeking to collect in-plant MES and OEE data from multiple production lines might wrestle with navigating different firewalls, virtual local area networks (VLANs) or other segmented network configurations. They can use edge devices to bridge these networks, and deliver their information to a central, on-premise MQTT server for the user and other subscribers to consume.
Fourth, operators required to connect SCADA with wellhead systems also used to build custom poll/response networks from each well’s RTUs or PLCs to their SCADA control room. They typically employed proprietary radio networks using significant bandwidth to talk to thousands of sites with poll/response protocols. Instead, using MQTT-capable edge gateways and devices, they can send efficient report-by-exception data payloads with state awareness to a central MQTT broker and utilize SCADA networks more efficiently, securely and reliably.
"Edge computing lets users keep legacy equipment and brownfield applications in place, while adding the computing and networking capabilities they need to integrate them into the IIoT," says Hougland. "Eventually, edge-programmable industrial control devices will ultimately replace older PLCs and RTUs as more of them become capable of executing real-time control logic and I/O functions, in addition to providing secure connectivity.”