Have you heard enough about the Industrial Internet of Things (IIoT)? Have you had enough of the marketing to fill you up for a year?
Get ready for some more. In fall of 2015, in Toronto, where I kind of live, there was an OPC-UA North American seminar tour. I wanted to attend, so I could see some of the people that have been involved with this technology from its roots, just like I have.
While it was not to be, they were kind enough to send me the seminar details to peruse. It’s funny how I received an email from C-Labs, a presenter at the seminar, just a few days before putting fingers to keyboard. So, what’s the buzz? Tell me what’s a-happening. I was bombarded with guidance and information that made my head spin.
I remember having visions of self-registering and self-aware devices 15 years ago. IEC 61499 was around, highly distributed control (HDC) came to the table, but nothing came of anything. Enter OPC Unified Architecture (OPC-UA) and IIoT. I will tell you the function and the idea of multi-device awareness isn’t new; this implementation is, and I believe it will be very successful.
OPC-UA is a multi-lingual communication framework to allow for communication to various devices. To have an OPC interface or available server means any application that can “talk” OPC talks OPC and does not have to deal with the bottom-layer protocols, which we used to have to do in the past.
IIoT, IoT, and Industry 4.0 are gaining a ton of traction in the press and from various surprising sources. Appliance manufacturers are tying into the buzz. Why is that important?
Most IoT data points normally are configured and monitored with an app. Typically, you have to download the app to your phone or tablet, and it runs on Android or IOS. Rarely do these apps run on Windows or BlackBerry. One of the reasons BlackBerry went to the PRIV phone and Android was the availability of all the apps that can run on Android.
The benefits of having access to these devices with an app is ease of use, instant availability and not needing to know much about the end device—the fridge for instance.
OPC-UA wants to become that app for IIoT. The biggest and coolest premise is the integration of an OPC server embedded in devices itself. Connectivity protocol such as Ethernet/IP and Modbus/TCP is already there, so why not a communication server, as well?
The heart of the IIoT Revolution is machine-to-machine (M2M) communications. This machine-to-machine connection is at the heart of IIoT, according to Tom Burke, president of OPC Foundation. And the draw of OPC is the vendor independence of getting the data out of the end device. With the advent of inexpensive cellular communication devices, it is now possible to have remote RTUs active on the network of choice. A coffee machine can become a node on a network. “Why?” is a question for another time, but it can.
So, enter the complexity of the network and all of the devices that are on it and the need and capability of interfacing with and gathering of data in a read/write scenario.
How many apps would you need? Well, I think that what OPC-UA is going to do is simplify all of this for us in one fell swoop.
The reason I wanted to get to the seminar in the first place was to see what the dialog would be about the cloud and why it matters. The other reason of interest is the topic of embedded OPC-UA and why it matters. The answers come from the new generation of devices themselves. Smarter devices are coming on-line that can be both consumers and producers of data. Consider a steam valve and some sensors such as pressure and temperature.
It has been noted over the years that remote I/O and network-based I/O would save money and make troubleshooting and monitoring much easier since the I/O would be close to the application.
Imagine if the sensors and the valve spoke to each other. And they would be talking OPC-UA. Valve position would be consumed by both the sensors, and the sensor data would be consumed by the valve. What they would do with it is vendor-based, and user-configured, but the availability of connectivity and interface spells “wow.”
With an OPC-UA central communication core, almost all things are enabled. I have to say that has been available for some time, but in a very different suit. Devices would have to talk Profibus or ASI-bus in order for this to happen, but the proliferation of bus types has created a segmented marketplace. OPC-UA will change that drastically.
“The aggregation of information on many layers adds additional metadata, and therefore it is of critical importance to use a single standard.” indicates Burke.
I read that to be: Everything everywhere needs to be OPC-UA aware. The database that is resident in the cloud can consume data from the steam valve just as easily as it can gather data streams from a SCADA logging program. Whether it would or could be really easy remains to be seen but the inference of what Burke talks to is very inviting.
Kenton Petit of C-Labs suggests that 82% of businesses will be connected to the IoT, which means that devices of varying form factors will be accessing the Internet and corporate networks trading off information at will.
C-Labs is a cloud service provider that provides a method of aggregating data into the cloud and pushing it out to mobile and/or BYOD devices. Its main focus is IoT as such, but it’s not ignoring the IIoT. C-Labs plans on developing an OPC-UA implementation to be used as a plug-in to its C-DEngine product scope. Notice though it’s not implementing an Ethernet/IP or Modbus/TCP protocol. This speaks volumes as to the market breadth available to a company like C-Labs, and others I’m sure will follow this lead.
What OPC-UA doesn’t do is “the cloud,” which is why other products and services will need to be employed to utilize the benefits of Microsoft’s Azure, for instance. Microsoft’s Rohit Bhargava, CTO, WW Manufacturing and Resources, has publicly stated that his company will fully support OPC-UA. C-Labs has created its own engine to benefit OPC users and devices.
SAP is using and supporting OPC for data transfer and data exchange. Oracle and HP have been part of the heavyweight commercial support that the OPC Foundation has garnered. Industrial support is widespread and well-known, including Rockwell Automation, Siemens and PLCopen with their OPC communication function blocks.
So the table is set for the OPC-UA led transformation of data flow in the industrial space. One more thing to examine: Embedded OPC.
Embedded OPC is what is resident at the device level, regardless of the functionality of the device. It could be a washing machine, thermostat, paper machine drive or a field-mounted limit switch. The range of applications in the field is endless. Some may argue that HTML5 is all you need, or in fact maybe Java, both of which are platform-independent. Honeywell’s Limitless wireless limit switch series uses commercial off-the-shelf wireless technology. However, you need proprietary software to access the device status.
This is where Embedded OPC changes the game. Any OPC client can have access to this limit switch if it had an OPC server embedded into it. The wireless part of the switch is the commercial off-the-shelf stuff, and in its marketing material the need for a separate interface is downplayed, in my opinion.
Typically interfacing with field-mounted devices used a browser-based interface. This is for manual browsing, if you will. OPC-UA will change the paradigm by allowing for automatic data transfer by having the server embedded into the device.
Using an off-the-shelf solution is not revolutionary, but from an application point of view using a standardized automation protocol is revolutionary. The abilities of the control systems can be greatly widened to include anything you want or need.
You could also consider Embedded OPC as software as a service (SaaS), as well. The ability to be a data producer from such a simple device simply breaks all the rules. One of the benefits of OPC is the ability to browse for servers on the connected network. While OPC devices may not be self-registering right now, they still provide a way to be polled and be recognized.
This in turn leads to the discovery of what information can be gleaned from the object model in the device itself. The usage of this data may not be autonomous, as human interaction may be needed to access the SaaS part of the metadata. But I can envision an HMI/SCADA system polling the network and displaying available status without operator involvement.
Another required feature is the ability to subscribe to information from a device. It’s a kind of “let me know when this happens.” This really minimizes unwanted traffic from the network.
OPC-UA provides nine different service levels, which we really don’t have to concern ourselves with as users of the technology. To have this availability in a single networked device will change the plant floor and the top floor in a big way—information everywhere, which was first envisioned many years ago with the advent of Ethernet.
Now it is coming to an automation project near you. You will be exposed to many new technologies and services. Almost 50% of the OPC Foundation membership is in Europe, which suggests that the evocation of OPC-UA may truly be new to us in North America.
We will rely on the OPC Foundation and its members to guide our industry through the new data jungle. Guide us well.
