I just read an article from Craig Resnick from ARC Advisory group titled "Add IIoT to Legacy Automation Assets to Reduce Unscheduled Downtime." In the article, Craig uses the terms "IIoT-enabled solutions," "IIoT connectivity," and "IIoT technology." What does this mean in practical terms? I have actually asked Craig for his input as he is looking across industry and may shed some more specific light on the subject, but I am going to add what I think it means and means for you.
First of all, let's talk about what IS the IIoT. There are lots of definitions out there and I did a bit of research just to see what people are saying. Let me see if I can sum things up with some bullet points:
The whole "Internet of Things" concept in and of itself infers interconnectivity between "things" - in the consumer world, this may be a fitness band to a cloud based application to track our personal goals.
How this connectivity applies to the Industrial world is that sensors and machines will talk to more things in the future - i.e. other machines, optimization systems, etc.
This connectivity should allow more of us to have more intelligence into what is happening in our industrial plants without specialized knowledge of how the information system in the plant is put together
We will likely have intelligent and low cost sensors that we all use to optimize machinery that may not ever be attached to a control system - i.e. optimize safety, energy use, productivity, etc.
New protocols like MQTT, OPC UA, and others will facilitate this connectivity (for more information, automation.com published a great article here)
As a result of all of this interconnectivity, more and more machine learning and artificial intelligence applications are coming to market for use in the industrial setting
New business models will likely come to pass as a result of all of this connectivity. Here is a different business model entered into by Miller Brown Milling through one of Industrial Insight's partners - SenseOps. (Start at the 5:10 mark of the video). Instead of selling a machine to a customer, they have a contract with their customer based on the type of and amount of material run through the system. Their CEO is very excited about the new technology and new business model
Security is going to be an even bigger issue than it is now - how will we keep hackers out of all of this web of interconnected machines?
The traditional architecture today consists of sensors tied to a control system, often tied to some kind of data collection system (hopefully). Many of these data collection systems are either traditional data historians or those transforming themselves into true data infrastructures. One hopes that from there that the data in these "historians" is available to everyone and all other applications, but this is often not the case. They are in a silo and one has to have specialized knowledge of how the data streams or "tags" are named in the system just to get to the data to see it. A flow measurement for a device may have a not so obvious tagname (unless you are a process engineer and know the Process and Instrumentation Diagrams well) like 29:FIT209.PV, instead of just being known as "#1 machine cooling water flow."
Systems like OSIsoft's PI Asset Framework are trying to help with this, but for whatever reason, adoption has been slow (resources, perceived value or hard to quantify value, or simply time to configure have all been impediments). However, this is definitely the correct approach, make the information stored in the data infrastructure meaningful and easy to find, which is PI AF's chief goal.
Today, the approach of getting some of the information that is housed in legacy control systems can be done (although some people are still using the fact that they have legacy control systems as a crutch). Nearly every data infrastructure platform supports OPC (OLE for Process Control), and there is almost always a way to get to even the most legacy of systems with OPC. There is also almost always a way to convert some of the old controls protocols (DH+, Profibus, Modbus Plus, etc.) to Ethernet, which then opens the door for the use of OPC.
However, I believe we are seeing and will see more sensors bypassing some of the traditional ways that we currently get the data from them into data infrastructures today, i.e. the control system. By the time one buys the sensor, potentially the I/O module for the control system, adds the wiring back to the DCS or PLC, potentially adds logic to the PLC or DCS, the cost may be prohibitive.
In my opinion, every company needs a data infrastructure to house all of the data and one that has the ability to link to other applications like:
Maintenance systems
Accounting/ERP Systems
Artificial Intelligence and Machine Learning systems
MES/MOM systems
Vendors and suppliers' systems
My belief is that we will see sensors connected directly to these traditional data historians, or more likely, those who represent true data infrastructures. This is already happening some today, but adoption will likely explode over the next 5-10 years.
I can see a future where a low cost sensor connects to a gateway over a wireless connection and starts publishing data into the data infrastructure almost immediately. I believe this future is closer than we think. This is where I believe Mr. Resnick's article is focused and where I see the earliest benefit to "IIoT-enabled" technology adoption.
This idea of machinery talking to other machinery I believe will take some thought and will be slower to come. The issue of getting machines from different vendors, different control systems, and of different vintages to speak the same "language" will be very challenging. Defining payback for the investment required to make this type of interaction happen will be crucial. Just because machines CAN talk to each other, will they "understand" how they need to react to other machinery's signals?
We have been making machines on the same control networks talk to each other for years, but often in discrete manufacturing environments, the coordination between OEM's providing machinery was always tricky and the customer themselves, or a controls systems integrator had to get the machinery "talking" to each other effectively. More times than not, someone other than the OEM had to define the rules on what happens if one machine in the system slows down, speeds up, or stops. This takes process knowledge and thoughtful consideration to all downstream equipment.
The idea in the IIoT community seems to be out there that machinery will be able to "talk" more autonomously across a variety of platforms with less human interaction.
This will be interesting to watch as there is a lot to consider.
So, what practical thoughts or ideas stand out to me and what can we do today? In Mr. Resnick's article, he believes that IIoT technology can help reduce unplanned downtime. I agree. I think there may be opportunities in your facilities where some well placed sensors can tell you more than what you know right now that can clue you when when the machine or process is likely to have a downtime event. Are you looking at wireless sensor technology? Are you thinking about the data that those sensors not even being piped through your control system? How can you get the data into your infrastructure the fastest and cheapest way possible?
How about sensors for monitoring equipment reliability? Equipment reliability is a MAJOR reason why systems have unplanned downtime! The owners of the DCS or PLC may not really care about this information, but the reliability engineer certainly will. How about energy optimization? Are there opportunities to get your WAGES (Water, Air, Gas, Electric, Steam) measurements into your data infrastructure more cost effectively? Often times, the process control systems don't necessarily "care" about this kind of information, but the people who pay the energy bills certainly do.
In this modern world, we have to think unconventionally about how we get data into our data infrastructure, and our legacy control systems might just be prohibiting us from getting the data we need to transform our organizations, but they shouldn't be.