Working in systems integration often means putting on many hats. Sometimes you can just fulfill your normal duties of designing, building, and commissioning a controls/automation system.

But then other times you find yourself thrown into the mix as the sales estimator—asked to come up with a budgetary number for a project—or you’re deemed the “IT” person for a project.

Being designated the “IT” person can be a difficult road to navigate. Often you’re not truly an admin on any given network, but you’re asked to perform the duties of an admin.

Systems need complex data handling, and the amount of traffic that control devices produce can put quite a strain on any OT (operational technology) network, due to their polling nature. I’ve personally worked on plant networks that for good reasons did not have the costly IT infrastructure in place to mitigate this overload of polled data. So I’ve had to throttle scans and read/writes to SCADA systems.

Couple the overload of control data with all the business traffic that is generated from day-to-day operations, and there’s a real potential to lose critical business and production data.

So I was interested to read Benson Hougland’s recent article on automation.com, Next-Gen Industrial Communications as a Tool to Solve Networking Problems.

Benson points out the challenges with traditional industrial networking systems, like difficult implementation (especially with geographically widespread sites), the need to coordinate several technical groups, and the added load for the company’s network infrastructure.

Smart sensors, intelligent devices, and control systems can give you a wealth of information, but they have to be interconnected to access it. Standing in the way of interconnection—as any system integrator can tell you—are the limited networking and proprietary protocols historically used in industrial automation systems.

As Benson says, “Operations technology (OT) personnel have traditionally engineered their own control and connection solutions for the PLC and sensor devices they used, since the means and methods were often unique to these systems.”

Engineers have struggled with integration, especially as companies buy newer packaged equipment and automation systems, often leaving islands of automation that can’t interact with each other.

Changing times

But the situation is different now. Today, commercial off-the-shelf (COTS) Ethernet and wireless networking, based on consumer-driven technologies, is fast, reliable, and economical. And newer protocols—specifically a publish-subscribe protocol like MQTT—can make a huge difference.

IBM developed MQTT in 1999 as a lightweight delivery system for industrial production data over then-costly cellular networks. Since its development, MQTT has proven useful as a reliable, secure delivery system for all levels of data. It was deployed and used early on, but it started gaining a strong foothold when the concepts of M2M and IoT became popular. Now MQTT is accepted as a more mainstream method.

Typical firewalls reject incoming communication but allow outgoing communication, and that’s how MQTT works. The remote device initiates an outbound conversation to achieve the communication link, maintaining security while avoiding IT complications.

Fast enough

For slowly changing data sources, such as a level in a large tank, oversampling makes no sense. Polling just adds network traffic without giving useful information. For industrial applications, “fast enough” is often the best goal.

Publish-subscribe systems use a central server called a broker. Associated clients can publish data to the broker and subscribe to data handled by the broker. Pub-sub systems minimize network usage because clients publish data only when it changes (report by exception) and receive data only when it changes.

The outbound connection model provides a simple way to ensure that only configured devices initiate communications, without having to involve IT personnel. Existing network infrastructure and firewalls remain in place, administered by IT, while OT equipment maintains access to the onsite or cloud-located broker.

So a pub-sub method like MQTT puts OT in control again, with a reliable solution that doesn’t require a lot of IT involvement. And this approach is modular and scalable, because smart devices can easily be added.

Be a hero

So how do you get there? Take a look at Opto 22’s groov EPIC edge programmable industrial controller.

There’s a lot to see, from the integrated high-resolution touchscreen, to the ease of installation and wiring, to the 45+ years of industrial experience that went into the design of the guaranteed-for-life I/O.

But there’s also the dual network interfaces, the way the processor acts like a hub, and the system’s software for IIoT applications—including MQTT/Sparkplug. Using this type of controller in your automation system gives you an easy and scalable way to take advantage of next-generation communications.

Here’s how to be a hero as a systems integrator: move all of your “noisy” PLC devices to a network isolated to one of the dual network interfaces on the groov EPIC processor. Then publish tag data via MQTT/Sparkplug to a broker, using the other network interface card, where your SCADA/MES/ERP systems can subscribe to it.

All of this without costly networking equipment that most likely wouldn’t be rated for the plant floor environment anyway. All of this using secure outbound connections for data.

This method will also give you a good DMZ between IT and OT. The separation allows both sides to feel secure that their data is safe and protected.

• Read Benson’s article for more on next generation tools.
• Learn more about groov EPIC.

What’s your experience with connecting industrial and IT systems? What data do you want to get, and what keeps it isolated? I’ll be interested in your comments.