Stefan Hoppe, President of the OPC Foundation, takes a look back in an interview and explains the challenges of tomorrow.

Mr. Hoppe, when and under what starting conditions was OPC launched?

Stefan Hoppe: The history of the OPC Foundation is well documented: in 1995, a task force was formed by the companies Fisher-Rosemount, Rockwell Software, Opto 22, Intellution and Intuitive Technology as a kind of precursor to the OPC Foundation. A basic specification was created within just one year. This standard, called OLE for Process Control, was based on the Microsoft COM/DCOM technology in widespread use at the time and functioned like a device driver. This made it possible to enable PLC controllers to deliver live data, alarms and historical data to SCADA and MES systems. A simplified specification v1.0 followed in 1996 - at the same time the OPC Foundation was officially founded in April 1996, with Siemens as the only European company.
In 2003, the OPC Foundation then began to separate services and data, and OPC Unified Architecture (OPC UA) was given a service-oriented architecture. The technology was developed to ensure a seamless, secure and reliable exchange of information from the sensor to IT, independent of operating systems. The OPC UA specification v1.0 was published on July 26, 2006, and to facilitate global adaptation, OPC UA was published as a full IEC standard under the number IEC 62541. Today, in 2023, we have arrived at OPC UA version 1.05. This means that OPC UA has been available on the market for 17 years without a break in compatibility.

In your opinion, what are the biggest hurdles to overcome now and in the future?

The biggest hurdle is convincing users of the performance and practicability of OPC UA. It is still the case that many users still assume that you first select a data protocol and then provide the necessary data in the second step. Later, as a third step, the security aspects may be considered. In today's world, however, this is no longer expedient and results in a great deal of effort. OPC UA offers many functions like a Swiss army knife: Data is modeled first and protocols, including security, are already available and only need to be configured. However, the individual tools of the pocket knife are very diverse and you don't always have to use the largest knife with all the features - a smaller knife will often do! In technical terms: OPC UA can be designed with scalable features - for example, as a digital twin in the cloud, it doesn't have to implement TCP, UDP or TSN, but perhaps only MQTT and REST. On the other hand, I don't expect field devices to necessarily offer OPC UA directly via REST interfaces.

"We shouldn't just keep throwing new technologies into the field, but rather add missing features to existing technologies!"

One challenge is certainly that although the list of available features is publicly well documented, it is now so large that many people lose track of it and believe they have to invent things that have long been available as OPC UA features. One example is File Transfer, which has been defined in OPC UA since 2009: OPC UA makes it possible to search directories, create new files, edit files, insert or remove content and delete files. OPC UA can therefore read or transfer online - i.e. live data - and offline data, for example AML configuration data. There is no more data - is there?

It is well known that IT and automation providers are finding it somewhat difficult to implement the digitalization of the factory together. What are your biggest fears when it comes to the IT/OT conflict?

Unfortunately, IT and OT don't really talk to each other, but mostly about each other. In addition, the human syndrome 'Not invented here' is the biggest problem. Broken down to OPC, many people once had a picture of OPC UA in 2008 and misjudged it as a 'more modern OPC Classic protocol' - but this no longer does justice to today's OPC UA. OPC UA is now much more and consists of three cores. First: OPC UA is a powerful modeling language - for the description and behavior of almost everything: devices, but also services and processes. Secondly, various protocols for the OT and IT world are already integrated and, as already mentioned, point three, security, is also included - and the great thing is that everything can be expanded.

With these three cores, OPC UA was created from the outset for the convergence of IT and OT - which is why, for example, modeling language scales into the OT world to describe a robot and its behavior and interaction as well as the description of services or a digital twin or data spaces in the IT world in the cloud.
The good thing about this is that the information standardized by domain experts can be easily referenced in the cloud and does not have to be mapped into other less powerful meta-modelling languages.

Wishes and visions

Where does it currently stand in concrete terms?

I recently had many discussions with representatives and architects of the AAS administration shell at the Automation Congress in Baden-Baden and asked them what the new use case to be solved is that could not be solved with the combination of OPC UA and AML. OPC UA is then quickly pigeonholed as "OPC UA only provides live operational data - AAS collects data over the life cycle". However, this answer provides no information about which feature is actually missing in the combination of OPC UA and AML. And if a feature is missing, why not get involved within the existing organizations and introduce such a new feature?

"The interest from the IT world is incredibly high and OPC UA with its REST and OPC UA over MQTT interfaces will therefore become much more established in the IT world."

If a feature is missing, you shouldn't take this as an opportunity to build your own, completely new system that is incompatible with a proven existing system! This only creates confusion in the market: what do I build with the established system and what do I build with the new system? The result would be that small and medium-sized companies are simply overwhelmed and stop any integration of standards, thus preventing the adaptation and convergence of IT and OT. Somewhat heretically: A legitimate reason to build such a new system is perhaps to raise research funds - but does this really deliver pragmatic innovations?

What would you like to see from the IT industry in terms of reducing conflict between OT and IT?

Simply asking the IT industry to 'listen' is not enough: The conflict between IT and OT takes place within all large user groups as well as among suppliers. There is no mutual understanding: The IT world has little understanding of what boundary conditions a deterministic fieldbus needs, why OT wants to separate the networks and why a REST interface or an AAS makes no sense at the lowest OT level on the sensor and controller. The same applies vice versa for pure OT concepts that do not scale into the IT world. Everyone assumes that their own concept will also scale into the other world and be adapted there.
OPC UA was designed from the outset by people with an affinity for IT and OT to bring IT/OT together and is therefore a successful lighthouse project driven by industry for industry: Innovation driven without any taxpayers' money - but for 17 years without any compatibility break.

What can the OT sector do to better protect its interests?

The same applies as for the previous question: the OT world should not think that all IT concepts are not suitable for the OT world anyway. Listen impartially to how and where virtualization and docker concepts fit well and where they don't. And please don't try to push OT solutions into the IT world either. That doesn't work either. My appeal: please talk to each other, think in terms of use cases and find solutions together! Please don't first find a solution and then look for the problem!

What vision continues to drive you personally?

OPC UA has changed in perception from a pure last mile standard for PLC controllers to a standard that now covers over 105 industries with information models and, with OPC UA over MQTT, stands as a link between the OT and IT world.
But I believe that OPC UA can open completely different doors! The best example: The REST extension as an OPC UA interface was publicly presented by the Open62541 stack in a research project in 2016. At the request of the industry, we are currently expanding this REST interface with the aim of providing easy access to the information standardized within OPC UA.
Interest from the IT world is incredibly high and OPC UA with its REST and OPC UA over MQTT interfaces will therefore become much more established in the IT world in the future. The first open source frameworks for digital twins and metaverse are already available based on OPC UA,
offered by consortia such as the Digital Twin Consortium. In short: OPC UA has the potential to establish itself very strongly in the IT world. This outlook simply has to be motivating!