Don’t cry over spilled milk, beer, or anything else for that matter. Why? Because there’s no longer any need to put up with spillage and other forms of waste just because your installed base of equipment is too old. You can solve many of these problems by retrofitting your legacy equipment to give you the connectivity and visibility promised by the Industrial Internet of Things (IIoT) to reduce waste.
Just ask Joe Vogelbacher, CEO and co-founder of the Sugar Creek Brewing Co., a craft brewery in Charlotte, N.C. Retrofitting a bottling line there with IIoT technology has allowed operators to control foaming as beer moves from tank to tank. Even slight variations in pressure and temperature can generate foam, which translates into enough spillage to cost the brewery $30,000 a month in lost revenue.
Operators can now interact with the process in real time from anywhere in the brewery, thanks to help from Bosch Rexroth Corp.
“Together with Sugar Creek, we mapped the value stream and began to analyze specific pain points,” said Armando Gonzalez, Industry 4.0 business leader at Bosch Rexroth. “From there, we were able to determine the amount of waste and how that translated in terms of value.”
Bosch Rexroth engineers then helped the brewery’s staff understand how IIoT technology could help them achieve some quick success.
The retrofit team added not only IIoT sensors to the beer tanks, but also Rexroth’s IIoT Gateway to report fill levels and temperature. Once analyzed, these data points are available to operators on their laptops, tablets, or mobile phones. With information easily accessible and the ability to adjust setpoints remotely, Sugar Creek Brewing Co. saved $120,000 in 2019 alone.
Planning is crucial
Like any other technology, successful IIoT implementation requires a plan that makes good business sense. Developing such a plan helps avoid over-retrofitting, the most common mistake that users make, according to Manish Chawla, general manager for the industrial sector at IBM Corp. “The primary consideration should be clearly identifying what the ultimate goals and business benefits are for retrofitting a given piece of equipment,” he advises. “There needs to be a business purpose for every single sensor that someone wants to install.”
These purposes usually include some benefit for such things as cost, safety, quality, and throughput. “The most impactful place to start one would be to look at where your biggest problems are,” suggests Dave Eifert, senior business development manager for IIoT at Phoenix Contact USA. “Look at one of these aspects in a very granular way and imagine what it would take to eliminate that one problem.” If more data and information about the process will help you to understand and solve the problem, then it could be a good application for IIoT.
Automation experts warn beginners to be selective when deciding what data to collect. “The influx of too much data can create analysis paralysis,” explains Trevor Diehl, vice president of research and development at DelmiaWorks, a supplier of enterprise resource planning software. To avoid this problem, he suggests working with quality professionals to identify three to five signals to start with—and certainly no more than eight.
An oft-forgotten consideration in the planning process is the long-term maintenance of any added sensors. “Making sure that sensors are calibrated appropriately is a long-term difficulty that few people plan for,” observes Diehl. Besides experiencing some drift that occurs naturally over time, sensors also eventually fail in industrial settings because they are installed in hostile environments, such as on vibrating machinery, in electromagnetic fields, and near heat sources.
IIoT with existing controllers
Once the goals and benefits are established, the next step for planning is to weigh them against the value and cost of the technology available to achieve them. The good news is that adding IIoT devices usually does not require replacing the existing controller. One reason is that IIoT is no longer limited to adding discrete sensors decoupled from the traditional control hierarchy. It can now include distributing data already available through PLCs.
“The controls world has been rapidly assimilating more IIoT technology,” explains Diehl. He points to the ability of technology like Rockwell Automation’s FactoryTalk View to connect to an OPC server, which is a common IIoT aggregator of data from a PLC. “So, it’s very possible to get relevant IIoT information from your existing equipment once it’s hooked into the right aggregator.”
“Many older controllers have some way of communicating valuable data, even if it’s over older protocols such as serial or DeviceNet,” adds Daymon Thompson, U.S. software product manager at Beckhoff Automation. Consequently, IIoT and other digitalization technologies can usually read data from these legacy controllers and then transmit it via an IIoT communication standard like MQTT, HTTP, and REST. “However, doing this requires adding a device to the system as a communications gateway.”
These gateways work alongside existing PLCs to send selected data to an on-premises or cloud-based system for the application of analytics. Eifert at Phoenix Contact recommends starting by leaving the existing control system in place and applying edge gateways in parallel. “It’s usually best to start small and learn to avoid potential pitfalls before pursuing projects with higher risk-reward profiles,” he says.
Then, you can weigh the benefits of replacing the PLCs as it makes sense during subsequent upgrade cycles. To permit this option, Eifert suggests using IIoT technology that can be applied incrementally. An example is Phoenix Contact’s PLCnext, which can serve as both an edge gateway and a PLC. It can be applied incrementally alongside an existing PLC, communicating locally with the PLC via such protocols as Modbus TCP, EtherNet/IP, or even Modbus RTU. Its Linux-based operating system allows using open-source programming tools like Node-Red as a link to the IIoT world.
Thompson reports that most IIoT upgrades involving Beckhoff Automation’s PC-based controls have entailed updating software to add functionality and communications in the controller. “In cases with very old equipment, it is straightforward to add a small gateway device and use our Data Agent software to read data from the existing controller and then map it to IoT communications protocols,” he says.
Such hardware can typically do much more than that, though. “A local IoT gateway can also do some of the computing at the edge before sending any information to the enterprise level or to the cloud,” says Thompson. Processing information at the edge can reduce network traffic and minimize the data being sent to higher-level systems.
An application requiring high-speed data will mostly likely need on-premises or edge computing. “These datasets often also need to roll up into an overarching corporate or enterprise view to assess holistic impact,” notes Chawla at IBM. “So, you need a well-defined architecture that specifies where data needs to be processed.”
Here, a common mistake is to take a strictly linear approach of processing the data either on-premises or in the cloud. “This approach can limit the value you’re able to gain from the data,” says Chawla. To avoid such limitations, he urges users to consider an open, hybrid architecture because it offers the flexibility to process data on-premises for speed and agility, as well as to reap the benefits of access to the cloud.
A tale of two constraints
Two important constraints for planning an IIoT retrofit are whether the equipment is instrumented and designed to communicate externally. “An application consisting of multiple connected, instrumented systems using controllers capable of communicating with industrial protocols is going to be a lot more straightforward,” notes Josh Eastburn, director of technical marketing at Opto 22. “Basically, you just need some good gateways or a single edge controller to bridge those different automation networks, and then pipe that information to wherever you want it to go.”
He adds, however, that establishing connectivity has been more difficult for un-instrumented equipment not designed to communicate externally. The low-cost option was to add the necessary instrumentation, send the data to a datalogger, and manually transfer the collected data to a spreadsheet. A more expensive option was to invest in a continuous logger, RTU, or PLC—which was pricey for just one piece of equipment and didn’t scale well for multiple machines. A Raspberry Pi was cheaper, but it tended not to work well with industrial I/O signals and was often too fragile for industrial environments.
For simplicity and scalability, Eastburn suggests an edge-oriented approach, such as that used in a predictive-maintenance program developed for a CNC mill by Enginuity Inc., an engineering firm in Halifax, Nova Scotia. Because CNC machines are usually not designed to collect or publish all of the necessary information for overall equipment efficiency (OEE) tracking, Enginuity’s engineers added sensors for measuring vibration, temperature, and current. They then wired the signals into a groovRIO edge I/O module from Opto 22. Using the module’s embedded Node-Red IoT engine, they collected the signal data, created a real-time mobile dashboard, and pushed data to OSIsoft PI (analytics system) using REST calls.
When either the existing controller is closed or the machine is old enough to be controlled via relay logic, Thompson at Beckhoff Automation says an IoT coupler is another option for reading sensor and motor data directly. In such cases, consider extracting uptime and other OEE data. Beckhoff’s EK9160 IoT Coupler can write sensor or electrical-input data to higher-level systems in the cloud or on premises using OPC UA or MQTT.
On-machine IIoT
Although IIoT devices are often added at the I/O level, another important place for retrofitting is at the machine level, the same level as an HMI in the control hierarchy, according to Alexander Bergner, director, IIoT product management at TTTech Industrial Automation. This is where TTTec’s Nerve edge computing platform runs.
By operating just above the PLC, the platform is able to draw upon much more computing power than is typically available at the I/O level. And by operating below the SCADA level, the algorithms are still close enough to the operation itself that the data are received in real time and experience no loss of granularity. Consequently, Nerve can support predictive maintenance and other analytics at the edge.
Because the platform has a virtualization function, it can run new applications and services alongside existing infrastructure. In fact, this ability captured the attention of the engineering staff at Fill Gesellschaft, a builder of CNC machine tools based in Gurten, Austria. Nerve now hosts the company’s Cybernetics smart factory software.
Running on edge devices built into each of Fill’s machines, Nerve collects data from the machines and sends it to the Cybernetics applications without any loss of granularity. Fill then processes the data on its software at the edge before sending the information to the cloud.
Fill is also using global datasets to check wear on components across its entire fleet of machines and to offer the results to its customer base as a service. The builder expects as much as 12% of its revenue to come from such services in a few years.
