This site uses cookies in order to improve your user experience and to provide content tailored specifically to your interests. Detailed information on the use of cookies on this website is provided in our Privacy Policy. You can also manage your preferences there.

By using this website, you consent to the use of cookies.

Learn more
OK

A Common Language for the Industrial Internet of Things

Ever since the Tower of Babylon, we’ve known that a common language is crucial for complex tasks. The same applies to the Industrial Internet of Things (IIoT). Only with a common language and data model, will companies be able to benefit from these new structures. But is OPC Unified Architecture (OPC UA) the appropriate answer? Read what Stefan Hoppe, President of the OPC Foundation, says about the design process for widely-accepted companion specifications and what role his organization plays in this.

Companion specifications offer a specific language for dedicated domains.

Many people recognize OPC UA as the foundation of the upcoming Industrial Internet of Things. So, why do we need companion specifications?

Stefan Hoppe Stefan Hoppe

The idea behind companion specifications is that of defining a language. This means OPC UA is not only about products, it’s about making it possible to standardize data, interfaces and behavior. Writing a companion spec for a specific domain means that even competing companies in that specific domain work together, synchronize their efforts and agree on one standard information model; a set of standardized data and interfaces for a specific industry. For instance, robotics vendors would work together and say “this is our interface for obtaining telemetry data from a robot or even interacting with a robot.” However, it could also be an Auto-ID device. Various companies offer different automatic identification (Auto-ID) devices with 1D or 2D barcode scanning, i.e. RFID technology using the same set of data. In the end, companion specifications reduce the effort of integrating all these devices for horizontal and vertical communication in your IT environment.

Stefan Hoppe, President OPC Foundation

OPC Foundation supports the working groups, but couldn’t you leave the topic to the vendors and just deliver the framework for them? What exactly is the present role of OPC Foundation in this game?

Stefan Hoppe Stefan Hoppe

Supporting different initiatives is exactly what we want to do.Companion specifications can be written by anybody, no matter where they are located. We just provide documentation and tools to write them in the best possible way. Many associations and collaboration partners have formed a joint working group with the OPC Foundation. As a result, they can use the OPC UA Foundation logo for their products. However, I assume there are many other applications around the world that we – the OPC Foundation – are not aware of. That’s why the next step is to harmonize with other groups. We will align our efforts and offer expert assistance to accelerate the ramp-up phase overall.

Let me summarize: The OPC UA foundation provides guidance to the working groups while making sure that the actual companion specifications keep in track with the big picture and don’t just follow a single interest.

Stefan Hoppe Stefan Hoppe

Yes, exactly. We’ve gained a lot of experience since the beginning and learned from that. We share this experience with our partners by talking about what didn’t go so well, what we changed, so we keep getting better. And that is exactly why we bring all the joint working groups together. They need to be connected.

Harmonizing standards across domains remains one of our challenges for the future. Many machine types have applicable standards that are also required by other machines. Every machine needs a firmware update or power management interface. So why don’t we harmonize across domains? We need to enable a reasonable amount of compatibility between companion specifications wherever possible.

Personally, I believe this to be the real challenge of the OPC Foundation. It’s a framework. It will grow with protocols and more functionality in controller-to-controller communication, and become safer. To me, that’s a logical evolution, but the real challenge is that we are becoming the world library for industrial descriptions, and this calls for organization.

OPC UA has also established itself as a protocol for cloud connectivity. Many companies have accepted OPC UA as the protocol for the cloud. This will also require a common data model, which covers more or less everything on the shop floor. What is the timeline to get this entire model to the implementation stage?

Stefan Hoppe Stefan Hoppe

As it is domain specific, you can’t say the world will be ready for this common data model at an exact time in the future. There are already companion specifications in use by industry, as mentioned above. The Auto-ID group started up a couple of years ago, and after two years they had all the work done. Now you can obtain OPC UA-compliant RFID devices from stock, from Siemens as well as from other vendors. Integrating them into your existing IT environment is extremely easy, connection to SAP or Microsoft Azure takes only 10-15 minutes. In other areas, it could occur that group members disagree on features and models – after all humans don’t always have the same opinion. They need more time to understand the benefits of interoperability. Thus, all in all, I can’t give you a firm estimate on when we will finally finish building the library of all descriptions in the industrial world.

Industrial communication requires a lot of human talk with various stakeholders.

On the other hand, customers are telling us – as a vendor – that they want to start now with cloud connectivity and with the implementation of Industry 4.0. Should they wait until the OPC Foundation has finished and finalized a common data model? What is your advice for such customers?

Stefan Hoppe Stefan Hoppe

(laughs) The open and honest answer is maybe OPC UA will never be finished, because it is a framework which keeps expanding; that’s a benefit. You don’t have to add these extensions to your existing machines. The first OPC UA-enabled devices were available on the market in 2007 and even today you can still connect to them with modern clients. Perhaps those devices do not have Pub/Sub or MQTT support, but they still have the original client/server-based OPC TCP communication and robust security. That’s great!

OPC UA is an open framework, which is extended by real industrial requirements, like controller-to-controller communication, OPC UA Motion or OPC UA Safety. Two years ago, we started a group “Safety over OPC UA” to address safety issues in connection with OPC UA. More and more capabilities have been added, so that OPC may never be finished and finalized. So, what is my recommendation? Everyone should start immediately! You can try an open source implementation of OPC UA available for download on GitHub. If you want to start with your product, I highly recommend approaching a toolkit vendor and buying a toolkit for the programming language you want. Start innovating your products today…

…and benefit from the common ground that already exists!

Stefan Hoppe Stefan Hoppe

Absolutely!

With SioME, companion specifications can be deployed to Simatic S7 PLCs by just a few mouse clicks. More on the web:  https://sie.ag/2QA1ZNh