Case study: Hits and misses in an actual IIoT implementation
Figure 1: MacLean-Fogg Component Solutions makes fastener components and engineered plastics.
(Source: MacLean-Fogg)
The Industrial Internet of Things (IIoT) takes time. Unlike a light switch, the IIoT has no toggle button to turn it on and off. Each company has its own needs and requirements to optimize a business model or perhaps even create a new one. Some companies build IIoT systems and strategies and then leverage the success of those implementations to go further. Such is the case at MacLean-Fogg, an Illinois-based manufacturer founded in 1925.
“Through 2014, we had controls engineers and automated processes,” explains Chris Misztur, software architect and IIoT evangelist at MacLean-Fogg Component Solutions, which makes fastener components and engineered plastics (Figure 1). It’s one of two organizations within the company—the other developing power systems. The company has evaluated and implemented various IIoT technologies that have made a major difference in its decision-making.
At MacLean-Fogg, an ongoing enterprise-resource-planning (ERP) implementation across 40 divisions drove the need for better business practices and insights into the shop floor, explains Scott Masker, business systems engineer at MacLean-Fogg. Using the company’s 5C approach—connect, collect, combine, compute and convey—to the IIoT, MacLean-Fogg decided between cloud IIoT services and open-source middleware.
“We do lean training in-house for all of our 3,000-plus employees,” explains Misztur. “In 2015, IT got involved in IIoT because a lot of legacy hardware needed to be replaced. As I was doing lean-professional-training homework, I couldn’t find any of the data. And, when I could, it was just noise and didn’t make sense. So we started giving operations more and more data to look at (Figure 2). And finally in 2016 business units started to see the advantages of the data.”
Figure 2: As operations started seeing more and more data, finally in 2016 business units started to see the advantages of the data.
(Source: MacLean-Fogg)
MacLean-Fogg and its ERP-implementation team captured the current state and transitioned to the JD Edwards system, while removing non-value-added activities from processes along the way. “The paradigm shift from ‘we have been doing it like this for years’ to ‘there is always a better way’ has been best exemplified throughout the ERP project,” explains Misztur. “Any improvement starts with baselining current performance and setting procedural standards. The standards have been set by the people closest to the work and a predictable process is half the battle. Scale-performance and tolerance are examples of high-level dashboards we have created from shop-floor events mixed with business, system and network data. These information sets have allowed multiple roles within the organization to arrive at decisions with higher confidence.”
The IIoT team is able to optimize data-gathering techniques and identify network infrastructure bottlenecks. The IT director can identify capital expenditures based on geographical factory location. The business analyst can review end-user testing accuracy and the transactional-data-integrity overview. Engineering and quality control gain insight into equipment capability and process deviations.
“Overall, the interdepartmental communication within the business has increased in quantity and quality,” says Misztur. “Real-time information that cuts across multiple business contexts makes it much easier to start a conversation and attack one problem at a time.”
Continuous improvement
Figure 3: Standardization of ERP across all factories allowed MacLean-Fogg to finally see the horizon with a wide-angle lens.
(Source: MacLean-Fogg)
MacLean-Fogg, like other organizations employing continuous-improvement kaizen strategies, would often hold week-long meetings, but then nothing would get done. Misztur and Masker saw the opportunity for IIoT to change that.
“At the company level, we set objectives,” said Misztur. “First, we had to eliminate noise. Symptoms are not problems. We had to capture the data closest to the process, remove human intervention from data collection and be sure to capture only the data that was needed—no more and no less.”
Five factors have played into the birth of MacLean-Fogg’s IIoT initiative. “The first one is the ongoing lean activities, where clean and accurate data is key to problem-solving,” explains Misztur. “Second, standardization of ERP across all factories allowed us to finally see the horizon with a wide-angle lens (Figure 3). The disparate business processes and legacy technologies really hindered any kind of long-term planning and ubiquitous adoption. Third, the emergence of low-cost hobbyist electronics has opened up innovation and communication between IT and engineering. Proving an idea no longer requires a full-size panel, while some responsibility has shifted from the controls engineer to a well-rounded IT professional. Fourth, IT has never made the company any money. We must do what we can to contribute to the value of our products. Lastly, with all the IoT hype going around for the past couple of years, we thought it was great timing to seize the opportunity ourselves. In truth, the philosophies behind lean manufacturing and innovation, IIoT included, all speak to the reorganization capabilities of a company that must be flexible enough to withstand high-speed change.”
MacLean-Fogg decided not to go with an off-the-shelf IIoT platform. “The data center contains ERP, integration and messaging, so the analysis is separate,” explains Misztur. “There was a concern for latency and security. We had to build strong vendor relationships, and we had to support existing data-collection initiatives.”
The solution was to push standardization across the organization and develop employee partnerships through the 5C approach. “By connecting, collecting, combining, computing and conveying data, we turn it into information, which then becomes knowledge,” says Misztur.
Data, data everywhere
Figure 4: MacLean-Fogg needed data from machines and we knew that OPC-UA was the bridge between industrial and enterprise systems.
(Source: MacLean-Fogg)
On the data side, MacLean-Fogg employs solutions from a multitude of vendor partners, including Rockwell Automation EtherNet/IP, Beckhoff’s TwinCAT, Telnet, the ESP8266 Wi-Fi module, Raspberry Pi, and the KepServerEX connectivity platform. “To convert that data to information, we developed our own Kepware Proxy middleware to connect to Oracle, JD Edwards, Microsoft BizTalk, Ignition and NiceLabel,” explains Misztur. “On the knowledge end, we use Splunk.”
With so many potential technologies to implement, the process of discovery and investigation can be a chicken-and-egg process. “The question is akin to ‘How do you get Google to return the correct answer?’" notes Misztur. “Well, ask the right question.” If you do, the cyclical process then involves research, communication, trial and error and more research.
“We went into the project with very limited requirements, knowledge and a wide-open scope,” explains Misztur. “We needed data from machines and we knew that OPC-UA was the bridge between industrial and enterprise systems (Figure 4). We began our research on both fronts: functional and technical. Seeking internal opportunities for improvement was first on our list. Once we had a list of use cases, we were then able to narrow down the scope but stick to very generic terminology that left a lot to interpretation.”
MacLean-Fogg then looked at the communication side and evaluated multiple protocols of how to best bridge the shop floor to IT. “We settled on MQTT and HTTP protocols and built a proof-of-concept bridge into Kepware’s OPC-UA.
Figure 5: Once MacLean-Fogg had a couple pieces of equipment on-line, it realized that, by bridging the plant floor and IT, it was merging the operational/business datasets with the machine datasets into a single stream of information.
(Source: MacLean-Fogg)
MacLean-Fogg then communicated with Kepware’s R&D department, which has been working on the functionality and made it available for review. “The functionality was exactly what we have been looking for and gave us a huge leap forward,” says Misztur. “Once we had a couple pieces of equipment on-line, we quickly realized that, by bridging the two worlds together, what we were actually doing is merging the operational/business datasets with the machine datasets into a single stream of information (Figure 5).”
The next step was to contextualize the information so it made sense to different roles within the organization. “We looked into different bodies of research and knowledge, such as the European Commission, Fraunhofer Society, Industrial Internet Consortium, Digital Manufacturing and Design Innovation Institute, IEEE IoT, OPC Foundation and Open Connectivity Foundation,” says Misztur. “The needle in the haystack was the book, 'Enabling Things to Talk.'" The book is a result of efforts surrounding the IoT-Architecture project (IoT-A), which is the European Commission’s flagship project in the European Union’s Seventh Framework Program for Research and Development with respect to establishing an architecture for the Internet of Things.
“It is a very academic read, and, while now on the fourth pass of the book, I am still finding new material and constructing interpretations that could lead to application and implementation,” admits Misztur. “The premise, however, is that every physical object can have multiple digital representations, just like your car is represented digitally by the VIN, license plate or bank loan. The combination of all three passive representations might be of value to the repo man, while only the license plate might be of value to law enforcement. The story continues with more evaluation of enterprise products that might ever-so-slightly fit with the physical-digital paradigm. Eventually we built a proof of concept that actually stuck for the past year and dubbed it Kepware Proxy, acting as a shim between machines and enterprise.”
ALSO READ: 5 insider tips to access the IIoT
Hits and misses
With so many diverse implementations, MacLean-Fogg has seen many hits and overcome a few misses.
“We wanted to integrate our scale integration system into the enterprise system,” says Masker. “We started with RF-Smart’s workflow software for scanning work orders, operations and scales and then going through the Kepware Proxy server. Part-weight tolerances are being checked. There’s notification of out-of-sample weights, as well as validation of weights. We can even check on the availability of analytical tools for engineering to maintain part weights.”
Some of the first-year big hits were in sorting/packaging, torque testing and fact-finding, while a counting application missed and needed adjustment.
For sorting and packaging, MacLean-Fogg started with RF-Smart software, which then sends the data to the Kepware proxy and stores it in the database. “As the boxes come down the line, a sensor throws information to the proxy server,” explains Masker. “There’s centralized data collection for the entire department. Everything’s automatic, and operation is autonomous. The box triggers the label printing, but the user has the ability to intervene, if needed. It also gave us SCADA data, so we could build a dashboard to tell us what’s running, what’s not running and when things will ship.”
There’s also remote machine status, not to mention performance indicators. “The dashboard is a monitoring tool for the entire department,” says Masker. “The dashboard was the first time the manufacturing group came to us and requested something. Now that the business has seen the value in it, it’s starting to gain steam.”
Torque testing was another big hit. “It literally took about a day to mock out the screen and get a prototype,” explains Masker. “And we sold it to our boss in 5 minutes. We were able to spend the money for the Ignition software, rather than spend weeks and weeks writing code. It took less than a week to go from prototype to deployment, and the tags were easily brought in from the PLC.”
Splunk data analytics also were implemented to enable fact-finding and monitoring of IIoT performance.
While the technology implementations may not have changed MacLean-Fogg’s business model directly, it is starting to see more movement toward a new mindset of what is possible, rather than settling for what is available. “For instance,” explains Misztur, “a small group started meeting on the possibility of eliminating weight-counting product and pulled us into the meetings to determine if some of their ideas were obtainable. This is much different then calling IT in to ask them to come up with the idea.”
Mike Bacidore is the editor in chief for Control Design magazine. He is an award-winning columnist, earning a Gold Regional Award and a Silver National Award from the American Society of Business Publication Editors. Email him at [email protected].
