What’s Really New About IIoT?

Factory equipment has been creating data for decades, but today there are dozens of terms to describe it, like these: smart manufacturing, Industry 4.0, Industrial Internet of Things (IIoT), digital factory, digitalization, operational IT, manufacturing analytics, descriptive analytics, predictive analytics, operational analytics and connected factory.

All of these terms describe three steps that drive toward a common goal:

1. Capturing manufacturing data.
2. Translating that data into actionable information.
3. Using that actionable information to improve operations.

What’s changed dramatically over the past few years is the way data is acquired, the volume of data, and the way it’s used to improve operations.

Speaking specifically about IIoT and Industry 4.0, I often hear feedback like: “Well, that’s just the same stuff we’ve been doing for decades.” And though that’s mostly a valid statement—after all, the end goal of running an efficient organization hasn’t changed—how we are doing it has changed significantly.

A micro-history of factory automation

I’ve been doing factory information system integration and projects for about 20 years. To frame the change, let’s look quickly at where we’ve been.

Factory automation started with relay logic, with ladders and rungs. Electricians had to individually rewire the relays to change their operational characteristics. The development of the programmable logic controller (PLC) was a big breakthrough, replacing hard-wired relays and timers.

From there, we went to proprietary I/O networks, and then to industrial Ethernet. Each of these advancements created a better way to capture data, but didn’t directly address the need to translate it into actionable information and improve operations.

Why is IIoT better?

The big difference between IIoT and everything that came before is how it facilitates better access to and use of factory data. In a nutshell, IIoT decouples the “things” on the plant floor from the “applications” that make information actionable. Whereas in the past your sensors, devices and alerting systems had to be directly tied to each unique application, they’re now attached to a common infrastructure that can be accessed by any authorized system.

With IIoT, factory data is acquired and connected to a common and shared infrastructure. Your applications, analytics engines and devices can access this infrastructure to use and manipulate this information. The old point-to-point data model is replaced by a broadcast-subscribe model.

There are immediate benefits from this approach. One of the most important is how it reduces the risk of adding functionality to your factory applications.

New applications don’t put existing applications at risk

So what does that really look like? Let’s say that today you have an error-proofing application that’s tied to a pick light and button. Every time an operator takes a part, s/he presses the button, and that tells the error-proofing application that the right part has been added.

But let’s say tomorrow you decide you want to have that button do something else, like put in a restock request whenever the operator presses the button for at least 2 seconds. Without IIoT, you’d have to get the “pick light application” rewritten to include that new functionality.

And that rewrite process can be a nightmare—because who knows how long it will take and who knows if it will work the first time? As you continue to add functionality over time, you end up with this giant, unwieldy application that only a few people in your company know how to code, so it’s not nimble or flexible or any of the things you need it to be.

IIoT liberates your data

With IIoT, all the information from your devices is linked to your information infrastructure rather than one specific application, so your error-proofing application can run uninterrupted while your restock application gets set up.

When you want to add another application, your error-proofing and restock applications can continue to hum along without interruption. All your inputs—like short press, long press, double press, light on, light flash, light color—get defined as inputs that can be used however you want them to be used. They’re not hard coded into an inflexible application.

IIoT has other benefits as well:

• Freeing your data from your applications not only reduces the risk of changes, it also keeps you from being held hostage to your programmers. When only a few people understand your giant multi-application system, those programmers become more critical to your operation than they should be.
• Data sampling can become unnecessary, since you’ll be able to capture and analyze all of your data. This is especially valuable when a fault occurs infrequently and it’s hard to get enough data for a representative sample. And it’s a great advantage when you have a lot of data and want your manufacturing analytics to interpret all of it.
• Perhaps most importantly, the broadcast-subscribe-analyze-learn loop is particularly effective for management reporting and analysis systems, such as overall equipment effectiveness (OEE) and factory information systems (FIS). IIoT allows users to receive information more quickly, act upon it, receive feedback and adjust accordingly.

Where’s the right place to start?

I recommend you start everywhere you can free your data from your locked-down applications. Even if you might not need all that data now, data is cheap and it will give you enormous flexibility. It’s the first step in future-proofing your manufacturing information.

Then, as with any other area of your business, take a look at where your reality isn’t living up to your requirements. Where’s your pain? If it’s in throughput, take a look at how your data can be used in an OEE/FIS application to give you better insights into bottlenecks, starved stations and machine downtime. If you’re adding value to faulty products or running into product recalls, consider where you can implement IIoT for traceability. If you’ve got unacceptably high rates of scrap, take a look at IIoT options for error proofing.

Another way to look at it is in terms of your highest-cost operations. What data are they generating, and who could benefit from a broadcast-subscribe model? Where is your data structure or your programming staff keeping you from reducing those high costs?