Because it embraces so many technologies, the nature of the Industrial Internet of Things (IIoT) is determined by the needs of the users in each application and industry, according to G. Brooks-Zak, co-founder and technical lead at Outlier Automation, a system integrator in Fresno, Calif., and member of the Control System Integrators Association (CSIA).
“In food and beverage, IIoT is used for continuous batch processes, but in the packaging field, it’s used in more discrete applications. This changes what it includes and how it’s applied,” says Brooks-Zak. “We previously had production processes, internal communications, and data storage for process and machine statistics, but then we started connecting all this equipment and delivering data to different areas, including IT-based layers for analysis. The question is what best practices can IIoT enable, what value can it bring to controls and IT, and how can it be useful to people’s jobs?”
“There are also different maturity levels that we try to figure out with our clients. Even though some new Industry 4.0 and artificial intelligence (AI) tools are available, users must first be able to collect their basic production data, and use IIoT to relay and access it where their businesses want it. This means controls engineers are learning more IT skills and adapting them for plants that need to maintain cybersecurity and safety. We often work with both the automation side (OT) and business side applications (IT), but many IT departments don’t know their OT counterparts, and vice versa. The procedures and best practices on both sides often aren’t aligned, which is why IT and OT need to converge and close these gaps. The classic example is that IT wants to install software patches automatically, but OT needs them to be applied on a delayed schedule that doesn’t interfere with operations or cause safety issues.”
Building batteries better
For example, Outlier recently worked in the research area of a large battery-production facility, which operated 20 pieces of equipment that it’s studying for use in the company’s batch processes. The initial problem was that all these devices came from different suppliers, have different PLCs, and weren’t networked and couldn’t talk to each other. The researchers were writing down batch data by hand and were having a hard time catching mistakes or knowing which batches were run.
“We needed to know what data this equipment had that might be available to our client’s team, but the engineering staff didn’t know the right language for talking to their IT team, and connecting to its virtual local area network (VLAN) to reach that information,” explains Brooks-Zak. “The rest of the facility had a common, standard network, but the equipment in the research area wasn’t connected to it, so we added Ethernet communication gateways and Inductive Automation’s Ignition SCADA software to collect and visualize the data. This let us establish communications via standard Industrial protocols like Ethernet/IP and Modbus TCP and the OPC UA framework where those standard protocols couldn’t be used. It allowed the production data to be stored in a standard format for users like engineers and operators to see context-based trends and start to make decisions on the data.”
In some cases, Outlier encountered devices like a heater with a basic, nonstandard controller, where data might be trapped, so it added Moxa’s Ethernet gateway. This allowed it to convert the heater’s Modbus RTU serial data to OPC UA, and approach and connect other devices on a case-by-case basis. The research area’s equipment was a mix of new and used equipment. This application was similar to overcoming the difficulties of implementing IIoT in any brownfield facility. “Some devices in the research areas had old SLC 500 PLCs, but Red Lion’s HMI reads serial data, and could also get it to the OPC UA server. Other devices had CompactLogix PLCs that could be read directly by Ignition and reported to the SCADA system, while some Siemens PLCs could engage directly with the OPC UA server, even though many of those items weren’t connected before.”
Base streamlining on best practices
Until recently, rescuing stranded information or developing previously nonexistent controller data would likely require costly PLC modernizations or add-ons, and/or migrating between networks and converting data, which could be equally expensive. Brooks-Zak again recommends installing a parallel gateway like Moxa’s or a similar communications interface, which can read and convert serial data running on Modbus RTU or Data Highway Plus (DH+), and convert it to a form that OPC UA, MQTT or another IIoT protocol can use to deliver it to Ignition or another SCADA systems.
However, even though today’s IIoT networking components and software can remove many former hurdles and streamline communications, Brooks-Zak adds that users must still design their network based on best practices and their own unique requirements.
“We need to know how frequently they require data, polling and updates. Is it once an hour, once a day, or a mix? We need to know where’s it’s located, is it accessible, and do they want trends or a continuous equivalent of the machine running? Much of this depends on how often their process changes, and what’s most useful for their process,” adds Brooks-Zak. “Many users like to see pressure, temperature and motor torque every 30 seconds, put it all in a big, time-series data table that everyone can access, and observe changes when a device starts or an ingredient is added, and check for changes over longer periods of time with a custom ERP, MES or quality app. This can help users validate that they’re making the right decisions based on research. It also takes far less time than going to each device or operations person and asking what’s happening?”
