The Industrial Interoperabolity Standard

OPC UA Users and Experts –

Conveying Knowledge and Experience
Fourth Edition
November 2021
Second Edition | January 2021

The OPC Foundation publishes a series of interviews with experts, market leaders and think tanks
in communication, automation and industrial IT to highlight the benefits and the potential of the
OPC UA technology for end users, system integrators, operators in the world of industrial IoT.

Independent from Sensor to Cloud

IoT
International
4.0
Industrie

Protocol agnostic

M2M
Reliable

Industrie4.0

Extendable Secure
Cross-domain
Scalable Field Level Communications
Contents

5 CHAPTER 1: 18 CHAPTER 4:
THE STATUS AND FUTURE OF OPC UA SUPPORTING FIELD EXCHANGE (FX)
OPC UA IN CHINA INCLUDING TSN AND APL
Albert Zhang provides an update on the current The Field Level Communications (FLC) Initiative of the
status of the OPC Foundation‘s activities in various OPC Foundation has completed the initial Release
regions around China, highlights the adoption of the Candidate for OPC UA-based Field Exchange (UAFX)
OPC UA specification as a Chinese national for the use case “controller-to-controller”.
standard, and shares the status and preparations This important milestone establishes OPC UA as the
for the „Made in China 2025“ activities. standardized industrial interoperability solution at the
field level, taking advantage of key technologies.
8 CHAPTER 2:
EQUINOR OPC UA USE CASE 22 CHAPTER 5:
Steffan Sørenes of Equinor shares Equinor’s OPC FUNCTIONAL SAFETY
UA use case, explaining how they implemented and Interview with Max Walter from Siemens, in his role as
scaled-up OPC UA, the benefits Equinor is the chairperson of the OPC UA Safety working group.
achieving, the open-source information model Max provides a quick introduction into functional
library they’ve shared with the world, and Equinor’s safety, how OPC UA deals with safety, discuss
roadmap going forward. example use cases, talk about key features, prerequi-
sites, certification, and how OPC UA Safety will
14 CHAPTER 3: become the one and only safety protocol.
OPC UA FX (FIELD EXCHANGE)
SPECIFICATION EXTENSIONS 26 CHAPTER 6:
interview with Clark Case of Rockwell Automation GETTING OPC UA PRODUCTS CERTIFIED
and Georg Beeler from Siemens sharing the current Interview with Alexander Allmendinger from the OPC
status and future road map of the OPC UA FX Foundation, outlining the process of getting OPC UA
Specification, an initiative of the Field Level products certified. Further explanation of the certifica-
Communications (FLC) initiative including tion process, the preparation, how to reach compli-
achievements, the creative process, the parties ance, the testing itself, what is being tested, how to
involved, and the background and features of the get started, and the tools available to support
UAFX Standard. developers and end users.

OPC Foundation Podcasts

are available on different
distribution channels like … Spotify iTunes Google your computer

For any further questions please send an email to office@opcfoundation.org and let’s stay in touch.
 www.opcfoundation.org

Condition Monitoring
Efficiency/Process Optimization
Predictive Maintenance

CLOUD
IIoT Digitalization
OPC UA Semantics
Security
FOR CLOUD 5G
OPC UA over MQTT

FIELD
APL SPE Safety TSN Motion

ONE HARMONIZED SOLUTION

FOR PROCESS & FACTORY
SCALING FROM FIELD TO CLOUD

© metamorworks – shutterstock.com © klagyivik / stock.adobe.com

OPC UA Factory Automation
FOR FIELD Process Automation

e
First live demo on th
SPS 23 – 25.11.2021
40
OPC Booth Hall 5 – 1
OPC Foundation
Public Press Conference
➞ Nov 23rd, 2021 – 16:45h – 17:45h CET
➞ Onside: SPS show, Nuremberg,
NCC Ost, Room Istanbul
➞ Remote access available

nd remotely
Register here to atte nt-detail/sps-2021/
o un d at io n. o rg /e ve
https://opcf

„Please join our pr ess conference!“

ndation
cutive Director OPC Fou
nt and Exe
Agenda Stefan Hoppe, Preside

➞ OPC Foundation: News world

Stefan Hoppe, President & Executive Director, OPC Foundation

➞ OPC for Field

Peter Lutz, Director Field Level Communications Initiative, OPC Foundation
• FLC: Status of work
• Demonstrator: C2C including 20 companies
• Demonstrator: OPC UA Safety

➞ OPC UA for Cloud

Erich Barnstedt, Chief Architect Standards & Consortia, Azure IoT, Microsoft
John Dyck, CEO, CESMII
Sven Goldstein, Product Manager TwinCAT, Beckhoff Automation
• The challenge – the solution
• OPC UA over MQTT – One solution scaling from field to cloud
• Demonstrator: OPC UA over MQTT from Beckhoff & Siemens controller to Microsoft Azure
• UA for Cloud Library – Internet-hosted database containing OPC UA information models
• Cloud Federation – Enabling data-driven services in industrial environments

➞ Collaborations
Stefan Hoppe, President & Executive Director, OPC Foundation
Andreas Faath, Managing Director, Machine Information Interoperability, VDMA
• Overview collaboration & news
• UA for Machinery – the world production language

➞ Summary
CHAPTER 1

THE STATUS AND FUTURE OF

OPC UA IN CHINA
IN THIS SECTION: Albert Zhang provides an update on the current ALBERT ZHANG,
General Manager of the OPC Foundation China
status of the OPC Foundation’s activities in various regions around albert.zhang@opcfoundation.org
China, highlights the adoption of the OPC UA specification as a Chi-
nese national standard, and shares the status and preparations for the
“Made in China 2025” activities.

OPC UA status and influence in China demand under the premise of time and cost savings in engineering
Before 2015, not many people or companies in China knew about and operations. There are also subway projects, such as the recently
OPC UA. When people think of OPC, most of them still understand it completed Kunming Line 4, and the upcoming Zhuzhou Metro and
as the Classic OPC DA. Since 2016, with the popularization of Indus- the Shaoxing Line 1, all of which use OPC UA. Through the integra-
trie 4.0 concept of Industrial IoT, the promotions and activities of the tion of their own OPC UA interface along with off-the-shelf 3rd party
OPC Foundation, and most importantly, the acceptance of OPC UA OPC UA products, the Beijing Urban Construction Group (BUCG) has
as a Chinese National Standard, the popularity and attention on OPC realized the management, control, monitoring, operation, and mainte-
UA has increased by leaps and bounds. Thus, many companies, re- nance of communication and power systems, while reserving expan-
search institutions, and industry associations in China are becoming sion space for upgrading the centralized cloud deployment in the fu-
increasingly interested in OPC UA as the interoperability standard that ture. Based on what we know today, OPC UA will be used in at least
will enable all industrial communications from sensors to the cloud. 13 subway projects in the future.

Starting in 2020, as more and more factories upgraded and the im- OPC UA and Chinese National Standard
pacts of COVID-19 were evident, the end users began requiring sup- In 2016, OPC UA officially became the Chinese national standard
pliers to not only provide equipment with OPC UA interfaces and so- GB/T 33863 (OPC Unified Architecture). Since then, many national
lutions, including OPC UA, but also to ensure the OPC UA products projects led by the Chinese government began to require the use of
are certified by the OPC Foundation. This led more and more Chinese OPC UA. For example, ITEI’s national demonstration project in Beijing
companies to start developing OPC UA interfaces to support their Economic-Technological Development Area, the “Intelligent Manufac-
software and hardware, such as Machine Tools, Robots, and MES. turing Comprehensive Test Platform”, uses OPC UA to connect and
interoperate controllers, equipment and software in three production
At present, OPC UA is increasingly deployed in many advanced fac- lines from several different manufacturers, thus realizing the integra-
tories and demo projects, such as “The World Factory” by Foxconn, tion of factory management & control.
production lines of Geely (Automobile Manufacturing) and CSSC
(Shipbuilding), “Intelligent Building project”by Wanda (Property Devel-
oper) , Alibaba Cainiao (Logistics) etc. Many excellent cases have also
emerged in the fields of Food & Beverage processing and Machining
processing. By using OPC UA, they have realized small batch and
diversified flexible manufacturing. The application of OPC UA informa-
tion models, enables them to quickly adapt to changes in market Intelligent Manufacturing Comprehensive Test Platform
CHAPTER 1

In 2020, the Chinese national standard GB / T 38869 (OPC UA based This year (2021), two industry information model standards based on
interconnected network architecture in digital plant) was released. OPC UA have been released - GB/T 40209 (General Modelling Prin-
ciple for Integration Based on Information Model about Manufacturing
Equipment) and GB/T 39483 (Rubber and Plastics Injection Moulding
Machine-Interface). GB/T 40209 is a basic standard and applicable to
the modeling of manufacturing equipment integration information mo-
del by manufacturers, integrators and other users. The information
models of equipment / units / systems like CNC machine tools, indus-
trial robots, injection molding equipment, instruments and meters,
logistics storage, production units or lines, and digital workshops can
be modeled uniformly according to the rules specified in this stan-
dard. GB/T 39483 is highly consistent with OPC 40083. China‘s in-
jection moulding machine industry led by Haitian Plastics Machinery
developing Plastic & Rubber Machinery with OPC UA information mo-
del is starting to begin.

In addition, the new Chinese national standards related to OPC UA,

such as Machine Tools, Robots, and Machine Vision are on-going.
The OPC UA information model is very important to many industries.
We are looking forward to more and more Chinese national standards
for the OPC UA information model in the future. Our job is to ensure
they are consistent with OPC standards, such as address space,
data dictionary, etc., so that devices from different countries can
quickly work together and plug and play in the future.

OPC UA and China Industrial Internet / Made in China 2025

“Made in China 2025” was designed and approved by Premier Li
GB/T 33863.1-2017 Keqiang and officially proposed in 2015 the plan for the first decade
of China‘s manufacturing power strategy. Later, it was gradually mo-
dified and refined and became „Internet +“ and „Strong Foundation
Project“. Currently the goal is to realize China‘s Industrial Internet.
Under the guidance of the Ministry of Industry and Information Tech-
nology (MIIT), two affiliated institutes - China Academy of Information
and Communications Technology (CAICT) and China Academy of In-
dustrial Internet (CAII+) – are responsible for implementation methods
and related standards. The two institutes agreed that information mo-
deling is the top priority of the Industrial Internet. The OPC UA infor-
mation model will play a vital role in the implementation of China‘s
Industrial Internet. Therefore, they have initiated cooperation with the
OPC Foundation. Among them, the „3IM Partnership“ program initia-
ted by CAICT and AII (Alliance of Industrial Internet) has invited the
OPC Foundation and its members to participate, and also include
China Mobile, China Telecom, Aerospace Intelligence, Hollysys, Haier
and many other major Chinese listed companies.

Whether we are talking about “Made in China 2025” or China Industri-

al Internet, their development will be closely related and based on the
OPC UA information model. Therefore, the main task of OPC China is
to help more Chinese companies realize the value of the OPC UA in-
formation model and participate in the OPC UA information model
standard working group to jointly develop a neutral information model
standard that meets not only the demands from China, but globally.
GB/T 38869-2020
CHAPTER 1

The strong emphasis on OPC UA from leading industrial

companies in China
The rapid development of OPC UA is inseparable from the support of ABOUT THE INTERVIEW PARTNER –
many companies and partners, and this is also true in China. The in- ALBERT ZHANG:
teroperability, modeling, and security of OPC UA have been recog-
nized and supported by many advanced Chinese companies. For Albert worked in the Chinese government for 6 years and was
example, Huawei has deeply participated in the FLC initiative of the responsible for the design and establishment of industrial
OPC Foundation and has contributed funds, knowledge and experts parks. In 2015 to become the general manager of OPC Foun-
to the future integration of OPC UA over TSN and 5G. Another well- dation China. Industrial Development Consultant of CODESYS
known Chinese technology company, Inovance, a comprehensive China, and Technical Consultant of WellSell Group, ZGC Ad-
product and solution provider focusing on industrial automation and vanced Manufacturing Industry Alliance & China Industrial In-
new energy, will fully support OPC UA in a large number of products terconnection Standard Technology Alliance Deputy Secretary.
covering more than a dozen industries. Both Huawei and Inovance
are Class A Members of the OPC Foundation. In addition, many in-
dustry leaders also expressed a high level of interest and recognition
for the development of OPC UA, such as China Mobile, one of the ABOUT THE OPC CHINA TEAM
global top 500 companies, CATL, which has the world’s largest pow-
er battery usage, and Delta, a well-known Taiwan company. The OPC China team consists of part-time volunteers who
make up the OPC China Steering Committee (CSC), which
provides guidance and support to the full-time workers, Albert
Zhang and Holly Lou, who are responsible for marketing, pro-
motions, operations, and membership services in China. In the
20 years since the establishment of OPC China, the team has
helped more and more companies understand the value and
embrace the use OPC UA in China. Thanks to the attention
and support of the OPC Foundation and OPC President Stefan
Hoppe, as well as the CSC which is composed of experts from
Siemens, NI, and other well-known companies, Chinese com-
panies, the Chinese government, and end users are embracing
OPC UA and we look forward to many OPC success stories
coming out of China.
CHAPTER 2

OPC EXPERTS INTERVIEWS:

EQUINOR OPC UA USE CASE
IN THIS SECTION: This interview is with Steffan Sørenes of Equinor.
He is the leading advisor for Plant IT Architecture and Integration. He STEFFAN SØRENES,
Leading Advisor Plant IT Architecture & Integration
will share Equinor’s OPC UA use case, explain how they implemented
steffso@equinor.com
and scaled-up OPC UA, the benefits Equinor is achieving, the open-
source information model library they’ve shared with the world, and
Equinor’s roadmap going forward.

CLARK: Thank you, Steffan, for sharing your time and exper- When I tell people about this, I normally use an analogy related to the
tise with our readers. Please introduce yourself and describe headlights that we have in all our cars: our cars have headlights with
your role at Equinor. two modes to help us light the road in front of us when it’s dark out-
SØRENES: Today, we are called Equinor but in the past our name side. These modes are low-beam and high-beam.
was Statoil. We are a 50-year-old Norwegian company, originally fo- The low-beam mode provides enough light, so to speak, to help us
cused on oil and gas, but these days, we are transforming into be- see only what’s right in front of us, while high-beam mode helps us
coming a broader energy company. We are moving into offshore see even further down the road – you can be more forward looking.
wind, operating several wind-power plants and we are also expand- This is a good explanation of the OT and IT architecture because the
ing into carbon capture and storage, hydrogen, value chains, solar, industrial automation and control systems more closely emulate the
et cetera. low-beam mode – the real-time domain. Personnel who use these
We are not only doing business in Norway anymore; we are doing systems need to control and operate the facility in a safe and efficient
business in over 30 countries, with around 21,000 employees. manner; they need to make important and critical decisions, here and
I have been with the company for 10 years now and my current role now; they can’t sit and spend time in training or using machine learn-
is as a leading advisor on Industrial IT. So, I spend most of my time in ing models to predict what might happen four months from now.
the avenues built between Operations Technology and Information The control-room operators cannot have that focus. Instead, subject
Technology integration, where the plant-floor meets the IT world. I matter experts who reside in the back office or at our onshore opera-
have been working on these types of interfaces directly and indi- tions centers, they are the ones that can help our facilities with this.
rectly over these ten years, through various roles and projects, and They are the high-beam mode. They use the data from the facility
this is where OPC comes into the picture. OPC is something that we and really, really help operations become more forward looking by
have actually been using for decades and now we are scaling up using the collected data.
more and more with OPC UA. So, OPC UA, from my perspective, is a framework that basically con-
nects this low-beam and high-beam world in a better way. This en-
CLARK: So where does OPC UA come into the picture, and why? sures that the engineers and subject matter experts, in the back office
SØRENES: We see that OPC UA is very applicable – almost all over the or at our onshore operations center, not only get access to data but
place – ranging from field sensors to the cloud; but, from my perspective, that they are also given access to the context – the description of the
OPC UA is a key enabler and a key framework to connect and better data – so they cannot only read data but also understand the data and
integrate data coming from the industrial automation and control system. to act upon it. This is where OPC UA really comes into the picture.
We utilize this within the enterprise systems, business processes, and
various applications and analytics from the domain of the IT platform.
CHAPTER 2

CLARK: You’ve been using OPC UA for some years now in ma-
jor oil and gas fields. Where and when did this journey start?
SØRENES: Yes, as I mentioned, when it comes to OPC, we have ABOUT THE INTERVIEW PARTNER –
been a member of the OPC Foundation for 11 years now. We have STEFFAN SØRENES:
been using OPC UA for over 10 years, although we have used OPC
Classic for decades. Steffan is passionate about making industrial plant data from
Prior to 2014, our approach to OPC UA was that we “preferred” OPC the physical world available and transform it into usable infor-
UA. So, in our company requirements, we said that we preferred mation through data capture, contextualization and distribution
suppliers to deliver data via OPC UA; but we also said that it’s com- with the purpose to support analytics, business processes and
pletely fine to deliver data some other way. decision-makers with long-term plant optimization.
We began a new oil and gas project around 2013 called Johan Sver- Steffan holds a Bachelor’s Degree in Computer Science and a
drup, one of the largest oil and gas field developments in Norway, Master’s in Risk Management, specializing in offshore safety.
which started production in 2019. He has been providing Equinor with IT analysis and architec-
At the commencement of this project, we decided that, OK, now it’s ture and integration advice for over ten years.
time to really get serious with OPC UA and start to really understand
OPC; to understand the potential that is there and to see what we
can do to properly use it.
So, on this project, we went from saying that “OPC UA is preferred”
to saying that “OPC UA is what we shall use” … period!
This was quite a big project back then, now a big operating facility,
today. It’s a field consisting of a drilling platform, a riser platform, and
one process platform. We are building yet another process platform
and living quarters. The whole field is getting its power from a station
onshore and, at its peak production, this field alone will produce 30%
of Norway’s total production. This was the project where the OPC UA
journey within Equinor really took off.
So, on this project, we asked that we only acquire from suppliers
who could deliver software that would deliver real-time data over
OPC UA. We also utilized the information modeling features and ca-
pabilities within OPC UA to model and describe the facilities, the
equipment, and operational data so that the IT world – the high-
beam world – would not only get access to raw data, but that they
could have access to the context of the data in order to understand
and use it.
So, today, we make around 200,000 OPC UA variables available to
the IT platform in near-real-time.
[Editor’s Note: The number of OPC UA variables collected from the
Johan Sverdrup facility has increased to over 1 million since the time
of this original interview]

CLARK: So, with the help of these 200,000 variables, in a

structured way, in an OPC UA information model, you kind of
make a digital twin of your plant such that, at whatever level
I’m viewing within the OPC UA tree structure, I can get an un-
derstanding of what exactly that variable is and its meaning?
SØRENES: Yes, it’s basically a model of the facility where you can
start by viewing the top node in the OPC UA address space but then
you can drill down to a single piece of equipment, expand that equip-
ment, and easily subscribe to live data – operational data – originat-
ing from the plant floor. This is something you can do now in the IT
world by using OPC UA. We are not providing only raw sensor data
without any context, but we have provided the sensor data in context
so that the operational people can understand and use it by utilizing
the capabilities of modeling within OPC UA.
CHAPTER 2

CLARK: What can other companies learn from you when it CLARK: Along the way, did you meet any bumps in the road?
comes to implementing and scaling up the usage of OPC UA? What surprised you the most?
SØRENES: What I think other companies can learn from us is that, SØRENES: Yeah, we met bumps on the road – there will always be
first of all, the decision to utilize OPC UA on this project was actually some bumps on the road.
not a big companywide, top-down strategy; this was driven, I would When we started to talk about OPC UA, what I heard from a lot of
say, from the bottom up – driven by personal engagement champi- people around us, especially since OPC UA was not new at that time
ons and advanced learners. My experience is that you often need – I think the first version of OPC UA specification was released in
such champions to lead the way before it becomes operational 2006 or something like that – what I heard people say is, “Oh, OPC
throughout the entire company. UA, we have heard about it for many years but we have not seen
One of the first learnings we did was to get expert help because, anything yet.”
back in 2014, the fact was that we didn’t know anything about OPC I felt that it was a kind of a chicken and egg situation. Since Equinor
UA. It was very new to us, so we quickly saw that we needed to get is an end user, when we talked to suppliers out there, we felt that we
help and we needed to educate ourselves – we needed to invest in should kind of wait on the market and all the suppliers and compa-
learning. We partnered up with some of the most knowledgeable and nies will come up with OPC UA products on their own; but when we
experienced people and companies in Norway on OPC UA. We talked to some suppliers, they, instead, were waiting for a push from
worked together with them, spending one year studying and diving us as an operator, as an end user. So, we kind of inadvertently waited
deep, deep, deep into OPC UA in order to understand it. We saw the on each other.
overall concepts but especially learned how the information model- The take away for me is that sometimes we, as an operator and an
ing concept can actually solve some significant challenges we had end user, need to set the direction and take the lead by saying, “now,
when it came to lack of context and a lack of interoperability between we’re doing this!” and then things start to happen.
systems, and so forth. Another bump along the way is that, when you do projects like this, the
Another lesson we discovered was that we cannot do this alone. So, whole project development and construction has an investment cost;
back in 2014, yes, this was new to Equinor but it was also new to all then when you put the facility into operation, it becomes an opera-
the suppliers and we are 100% dependent on the suppliers and the tional cost. But, when we are going to do something new, such as
markets to understand this technology as well as deliver good prod- using OPC UA, but not all suppliers support it at that time, then they
ucts that we can utilize. So, that is a main lesson that one company have to develop OPC UA. We, and our suppliers, need to do some
cannot do this alone; we need to work on this together, we need to investment, which means that the investment cost is increasing.
help each other, we need to collaborate. If you only look at things from the investment cost perspective, it
Yet another lesson that I learned, and you may have heard this means higher cost, which is not good; but the perspective we need
phrase, that when it comes to digitalization, “Think big; Start small; to observe is the total cost of ownership. Since we did so when im-
Scale fast.” But in this Johan Sverdrup project, we were actually plementing OPC UA, we believe that, in the long term, the cost will
thinking big but we also started big… and scaled fast. be reduced due to more flexibility, more interoperability, and system
We started big in terms of actually implementing OPC UA in one of standardization.
the biggest oil and gas field developments of all time in Norway. We The third challenge, I would say, is that OPC UA is very, very flexible,
made a bet on OPC UA – on a flagship project – not only in the Nor- it’s powerful, and it’s comprehensive. You have many features and
wegian industry, but the entire global oil and gas industry. We made options that can be utilized. We experienced this when we said to
this bet on OPC UA and it paid off! suppliers that, “you shall deliver data over OPC UA.” That’s a very
We proved that OPC UA works on such a major project. Today, it’s generic requirement and, as luck would have it, you can deliver data
operational – we are using OPC right here and now. When we oper- over OPC UA in many, many different ways using different functional-
ate this field, and when we do so on such a big project, we remove ity but, also, on the modeling side of things. So, each supplier can
any doubts within Equinor, and across the industry, as to whether basically structure the address space and the information model in
OPC will work or not. vastly different ways and, yet, still deliver on the requirement that,
When you succeed with OPC UA in such a flagship project, that yes, they have used OPC UA.
quickly becomes the blueprint for the next projects and this inspires We have learned that, as an industry, we need to agree on which
people. So, what started out with one to three champions and ad- models and which OPC UA features we need for which use cases;
vanced learners leading the way, quickly became 30 champions and because it’s not realistic that every company, in every OPC server, is
advanced learners leading the way. required to support every part and every feature in OPC UA. That is
not realistic.
CHAPTER 2

CLARK: You suggested that, within your industry, you would Overall, the main benefit for us is, of course, interoperability. That is
need to agree on features and use cases and on specific mod- the key word here; to get an architecture and a flow where similar
els. That has been happening in many industrial sectors like, types of data are described, defined, and represented in a standard-
let’s say robotics, as an example, and many types of machine ized manner, independent of the system or system supplier. That
equipment manufacturers. Has that kind of industry talk hap- means that we can achieve more plug-and-play and spend less hu-
pened within your industry; perhaps taking the model, which man engineering time doing manual translations, mappings, trans-
you developed, as a kind of a de facto industry standard? formations of the data, et cetera, et cetera.
SØRENES: Now, when it comes to standardization of information
models within OPC UA, I think that many positive things have hap- CLARK: So, you mentioned the benefits of an open standard, an
pened over the last few years, especially when it comes to develop- open architecture. I saw your presentation during the ARC In-
ment and all the initiatives that are happening around the world. We dustry Forum in 2021 where you mentioned that you have an
are following closely what the VDMA is doing; we are following close- open source OPC UA information model library. Can you elabo-
ly what NAMUR is doing with their NAMUR Open Architecture. Equi- rate more on what that is and why you opened it up for the world?
nor is a member of NAMUR and we are also a member of the Open SØRENES: What we offered as open-source software is the infor-
Process Automation Forum, which also relies heavily on OPC UA. mation model library that we built for the Johan Sverdrup project.
So, yes, many things are happening and it’s a huge untapped poten- The library is actually an extension of the ISA S95 Companion Spec-
tial; but I also know that it takes time to go from agreeing on a model ification with OPC UA. So, it’s basically a library of equipment that
and a specification before we see it in a product we can buy. Hope- you typically find in an oil and gas facility, including the operational
fully more and more products will come with these models, standard- data model. The library is actually based on ten years of experience
ized, out of the box. That is what we hope and believe will happen. of making data available to our operations group, to plant integrity
people, and so on. So, over the last ten years, we have built on our
CLARK: I’m sure it’s going to happen and, you know, with your experience, knowing what types of data these people and teams
huge initiative, others are likely to join your effort. What are need. And, as such, we have modeled this experience into the OPC
the benefits to Equinor, as an end user and operator, when us- UA library, which today, I think consists of around 50 different object
ing OPC UA? types – types of equipment – and almost 1000 attributes.
SØRENES: To illustrate the benefits, I’ll use an example from the This library is something we have made openly available for the entire
Johan Sverdrup project. world and, within Equinor, “Open” and “Collaborative” are two out of
When it comes to the model that we developed, we actually created our four company values. We truly believe that having openness is
the OPC UA modeling – the types – in a software tool from vendor A. the key to achieving adoption across the industry. In order to make a
Then we instantiated the models – created the instances – in a tool real impact, we need open standards, open ecosystems, open-
from vendor B. And, finally, we broached the model and read the source code, and we need to make it simple for people and compa-
data and subscribed to live data from OPC UA Clients from vendors nies to get started. Lower the investment risk, lower the investment
C, D, and E. So, we used different products from different vendors to cost; make it as simple as possible; and OPC UA is open, which is
create this plug-and-play environment – no hassles, no integration, the key to ensuring, even driving, adoption.
and no manual translation or conversion. This is the future that we Now, if OPC UA was a closed standard, we would be very skeptical of
are seeking; this plug-and-play flexibility is one of the biggest benefits OPC UA. So, the fact that OPC UA is open, it is a key benefit and a key
that we see in the overall architecture… easier to plug-and-play a enabler for adoption. Within Equinor, we are committed to a very firm
wider array of products, easier to replace. open-source strategy; we have a requirement that, when we develop
We also become more competitive because, without standardized software, that software shall be open-sourced. Some might argue that
interfaces, we’ll never be competitive if we’re stuck with vendor lock- we shouldn’t make our code open to the world. However, if people
in. Instead, we need to compete on business value; that is a benefit want to look at our strategy and our repositories, they can! All you have
for everybody in the industry, I think. to do is go to opensource.equinor.com to view our commitment and
Another benefit that I’m starting to see today, but that I also expect our strategy – even look up the Equinor organization on github.com.
to see improve in the future, is lower costs. The oil and gas industry So why did we open source this OPC UA information model? Well, for
is not so special because many of the machines and equipment we me, OPC UA is not only a connectivity framework but I look at OPC UA
have on an oil and gas platform are similar to other industries using or the OPC Foundation as a community consisting of people and
pumps, heat exchangers, valves, control systems, turbines, com- companies that share, in my opinion, the same beliefs, the same pas-
pressors, and so on. The good thing about that is that OPC UA is sion for standardization, for plug-and-play, interoperability, exchange
industry-independent by design; it is not locked to oil and gas or of information, all in a seamless manner. That is the kind of passion
locked to manufacturing or anything like that. So that means that the that people share together by using OPC UA. We, as an end user, re-
same supplier can deliver the same OPC UA server, the same type of ceive benefits from this community; therefore, we would like to share
model, across industries, and I believe that we can lower the cost something in return, which, I believe, is a win-win for everybody.
over the long term.
CHAPTER 2

CLARK: You’ve put a lot of energy into this effort, clearly, with
great results. What is your road map going forward with re-
gards to using OPC UA at Equinor?
SØRENES: We are focusing on a standardized OPC information
model. It’s great to see all these companion specifications that com-
panies and people are now working on across all industries. There’s
a huge untapped potential there; broader usage, scaling up of these
models; that’s an important part of the way forward.
Additionally, we are focusing on making sure that we get closer inte-
gration between the plant floor and the applications and services in
the cloud, especially when it comes to OPC UA information models.
For example, if you have an OPC UA server at the plant floor, it’s quite
easy to stream real-time time-series data, the telemetry data, to the
cloud. But, in many cases, you also leave the model or the context
behind. So, when we stream this live, time-series data, we also need
to find a way to make the information model – the context – also
available to the cloud, not just the simple time-series data.
To be fair, we acknowledge that OPC UA isn’t the answer for every-
thing; but there are other exchange formats that exist for different use
cases. I sense that there is huge potential in closing the loop be-
tween engineering and operations by combining OPC UA and the
Automation Markup Language (AML).
We are also following Platform Industrie 4.0 in Germany, quite close-
ly, and have a dialogue with many people and companies there. So,
to be clear, this is the Asset Administration Shell, which is maturing in
Germany. We see huge potential and many benefits in this concept,
which is based on OPC UA, AutomationML, and REST APIs in order
to make the semantics available to different mechanisms.

CLARK: Thank you, Steffan, for a fantastic interview. Do you

have any more key takeaways or final messages to share with
our readers?
SØRENES: Yes. So, to summarize our experience and our learning,
I would say that one of the most important things is to find a spark, a
passion for interoperability, for standardization, for plug-and-play, for
collaboration across companies, but also across industries. That is
simply what OPC UA is all about; if you have that passion, and if you
truly believe in it, then you will find a lot of joy in OPC UA.
The second takeaway is to invest in learning. So, let the champions
and advanced learners within your company lead the way, ask for
help, reach out to other companies and people to learn from them
and share experiences. I would encourage readers to share your
story and your experiences, both good and bad experiences when
using OPC UA; because, if we share, then we can improve and do
things even better while working together.
And the last thing that I believe we all need is to have stamina be-
cause, through adoption and through semantic interoperability, using
standardized OPC UA models will take time. It’s not a quick win; we
need stamina; we need to approach this with a long-term perspective
and a long-term mindset but also, at the same time, do things step by
step. We can do things here and now; it’s already providing value.
So, personally, I’m looking forward to continuing utilizing and getting
business-value out of OPC UA.
 www.opcfoundation.org

SPS 23 – 25.11.2021
40
OPC Booth Hall 5 – 1
67
1

OPC
OPC UA
UA for Field Level
for Field Level Communication
Communication––
A
A Theory of Operations
Theory of Operations
Version 1 // November 2020
Version 1 // November 2020

Factory
Technical Paper
Technical

BLE
NEW – NOW AVAILA
OCHURE
OPC UA FOR FLC BR
Automation
OPC_FLC_Technical_Paper_C2C_lay16.indd 1 29.10.20 11:06

rg/FLC
www.opcfoundation.o

© metamorworks – shutterstock.com
First Live Demo: November 2021
OPC UA for Field eXchange
A Sole OPC UA Solution for Factory and Process Automation

Process
Automation

© metamorworks – shutterstock.com
CHAPTER 3

CLARK CASE, GEORG BIEHLER,

Platform Leader – Communications Editor OPC UA FX Specification
clcase@ra.rockwell.com georg.biehler@siemens.com

OPC EXPERTS INTERVIEWS:

OPC UA FX SPECIFICATION EXTENSIONS
IN THIS SECTION: This interview is with Clark Case of Rockwell Automation and Georg Biehler from Sie-
mens. In this article, they will share the current status and future roadmap of the OPC UA FX Specification,
an initiative of the OPC UA Field Level Communications (FLC) initiative. They will cover the achievements,
the creative process, parties involved, the background and features of the OPC UA FX Standard.

CLARK: Thanks for taking part in this interview, gentlemen. CLARK: We already mentioned that we are talking about the
Let’s start from the beginning. Can you both introduce your- OPC UA FX specification, can one of you explain it in more
selves to our readers and provide a little background as to detail and highlight the latest achievements you’ve made as
how you’re contributing to the initiative? an initiative?
CASE: My name is Clark Case and I’m with Rockwell Automation. I’ve CASE: I’ll give an overview and then Georg can talk a little bit more
worked with Rockwell in various roles over the past 20 years or so and about the specifics.
in recent years, have been focusing on various topics related to com- So, the first version of the OPC UA FX specification focuses on con-
munication between devices and between devices and software. troller-to-controller communication for real-time control communica-
So, when the opportunity came up to be involved in the OPC UA FX tions. As such, we’re trying to enable a controller from Siemens and
effort or, as it previously was known, the OPC UA FLC effort, I thought a controller from Rockwell and a controller from Phoenix Contact
it was a very exciting opportunity and was happy to take part in it. and a controller from B&R to all communicate with each other in real-
BIEHLER: My name is Georg Biehler and I’ve been with Siemens for time for the purposes of synchronizing operation, for doing com-
about 35 years now. I’ve been participating in standardization in the mand and control activities – the kinds of use cases that are com-
area of industrial communication for about 20 years and, similar to monly encountered when a manufacturing facility is trying to integrate
Clark, when I heard about the OPC UA FLC initiative and the OPC machines from different machine builders or from other different pro-
UA FX specification, I was glad to be part of the team. It’s a really viders. We’re trying to make that challenge much more easily achiev-
interesting opportunity. able than it has been in the past.
CHAPTER 3

BIEHLER: So, to achieve this, we wrote the OPC UA FX Specifica- within the framework of the OPC Foundation in order to develop
tion. FX stands for Field eXchange, which is the title of our specifica- these specifications, we put into place an OPC UA Working Group
tion series. FLC stands for Field Level Communications initiative, so and began our work.
it’s the name for the working group, while FX is the name of our We’ve organized our overall group into a number of different sub-
specification. teams focused on different, specific areas. We have a team focused
In our first release, the core context of our specification has concen- on the overall architecture of the system. We have a team focused on
trated on controller-to-controller communication. Part of the specifi- information modeling. We have a team that is focused on the mech-
cation is concentrating on the information model of an automation anisms for establishing, monitoring, and managing communications
component. This is used to harmonize the information models that between devices. We also have a team focused on the specification
we today, typically find in different companion specifications. So, if around the offline engineering deliverables. And we have teams fo-
you have a controller where you are looking for information for assets cused on specification for networking aspects, for safety, for profiling
or functions, the specification has this now in a specific place, with a the features defined in the specification, and for prototyping and test
navigation path to the harmonized information. It’s exactly the same specification.
regardless if you have a Rockwell controller, an ABB controller, a B&R BIEHLER: Actually, at the moment, and this is just a rough count,
controller, a Siemens controller, or from some other automation we have 320 members from 65 companies.
company. CASE: And it’s quite an impressive roster of companies. Basically, all
And secondly, also expanding on what Clark said, regarding control- of the automation companies with perhaps one or two notable ex-
ler-to-controller communication, “communication” means “data ex- ceptions; but we also have representatives from Intel and Microsoft I
change”. We have specified real-time data exchange, including TSN, believe, and some other companies that aren’t directly involved in
or Time Sensitive Networking, and easy management of these con- industrial automation but who are interested in perhaps providing
nections between different automation components. enabling products or services for this space.
Last, but not least, we have specified offline descriptors, so we are
able to engineer these machines in either offline or online modes in a CLARK: Let’s talk about the technologies behind OPC UA FX
very nice and easy way. because there’s a lot of OPC UA technologies used in the
CASE: Let me expand on that, just a little bit. There’s a couple of specification. How are they being utilized and how does ev-
reasons why this work that Georg just described is very important. erything work together?
One aspect is the common way of discovering what one controller CASE: There are a number of technologies underlying the OPC UA
knows about the data it is capable of publishing as well as the data FX specifications. We are utilizing the functionality provided by OPC
it expects to be able to consume. Without the OPC UA FX specifica- UA as much as possible. If there is a capability offered by OPC UA,
tion in place, that process is different for each and every vendor’s we’re going to utilize that capability, instead of inventing something
controller, and it becomes a nightmare for the system integrator or new. So, we are using OPC UA Client/Server communication capa-
for the end user to figure out exactly what data a given controller is bility. We are using OPC UA pub-sub communication capability. We
expecting and what data it is able to provide. are utilizing OPC UA security model; however, there are some areas
The second critical aspect is the manner in which the data is actu- that OPC UA doesn’t cover, so we’re also having discussions around
ally exchanged. Instead of having a different vendor-specific protocol how we apply TSN technologies to the OPC UA FX specifications,
for each and every vendor’s controller, it becomes the same protocol. which Georg mentioned a bit ago.
Without the OPCA UA FX specification in place to enable different BIEHLER: We haven’t yet mentioned offline descriptors, so allow me
vendor’s controllers to communicate with each other, it would be to speak to that topic. We’re using the Open Process Container spec-
necessary to put in place a number of different gateways, bridges, or ification, but that’s not OPC, even though it uses the same letters, it
translation devices – all of which require time and money to purchase also uses AutomationML for the contents of the offline descriptor.
and configure and, furthermore, slowdown communications when For TSN, we actually do not want to build our own TSN on the side,
such intermediate hardware or software is implemented. So, OPC but we are enjoying contact with an IEC/IEEE 60802 working group,
UA FX is going to make a huge difference in the deployment of inte- who is driving the TSN profile for industrial automation to ensure in-
grated machines between different vendors. teroperability between several protocols utilizing TSN in an automa-
tion network.
CLARK: How was the FX idea created and what is on the Regarding Client/Server and Pub-Sub, we’re using the base security
horizon for OPC UA FX? servers, which are provided by OPC UA, so we are actually extend-
CASE: Well before the standards effort got underway in January of ing OPC UA and we are an integral part of the OPC UA base speci-
2019, there were a lot of discussions among representatives from all fication. We are not considered to be something on the side, doing
of the different major automation vendors; discussing the different our own stuff but instead, we are built on top of OPC UA and extend-
vendors goals and how they would want to interact. That, of course, ing our standards.
took some time but all the different vendors seemed to understand
the value of this effort and that it would provide benefit to all the ven-
dors and, ultimately, all of the different end users. Once that agree-
ment was in place, and they had agreed that they wanted to work
CHAPTER 3

CLARK: I think it’s important to emphasize that the OPC UA data, which can then be exchanged. Input data could be given by
FLC initiative isn’t doing something on their own but is, in- someone to a functional entity, whereas output data could be pro-
stead, building on top of OPC UA and trying to help the indus- vided by a functional entity to someone else.
try in this way. In addition, you have configuration data, where you could, for ex-
I think you’ve already mentioned harmonization but can you ample, adjust your measurement value. Examples could include,
explain in more detail what harmonization means and how speed, in miles per hour, in kilometers per hour, in rotations per sec-
the information model and automation component are being ond, or whatever.
harmonized. The “asset” is actually the thing the automation component is built off.
BIEHLER: If you, today, look at some components of an OPC UA For example, when considering a modular IO device, we are speaking
Server, what you have on hand is a Client/Server protocol where you about its modules, its connectors to the outside world, its clamps,
can access information, which is structured in objects, which are put and all that stuff; but in addition, its licenses, certificates, firmware.
into a navigation tree so you can follow references. As you navigate
through such a tree, the problem that we see today is that, as you CLARK: Let’s discuss connections and how they help to ex-
look at the elements throughout the tree, you don’t really know what change data.
they are intended for. To figure this out, you have to read some spec- BIEHLER: The first methodology is OPC UA Pub-Sub. We build on
ification. Unfortunately, you can structure your components in what- top of publish-subscribe the notion of a connection. We can use that
ever way you want. connection to transport data in a few ways. First of all, we can move
OPC UA FX is fixing this by actually making a standard navigation data in only one direction; next, we could have an arrangement to get
tree. So, on top, you see something called FX Root and below that a heartbeat; and lastly, we can have bidirectional data flowing on a
you have an automation component, which has several functional connection.
entities, which model the functional world of an automation compo- Pub-Sub can also be used across four different transports. The first
nent. It also has a tree of assets, which models the physical world, transport is pure Layer-2 Ethernet based, the second is UDP, and
which also includes software licenses and so on. then cloud protocols like MQTT and AMQP are supported.
By having such a standard navigation tree, you always know where Pub-Sub can also be used with different quality of service applica-
to find your input data – that data to which a controller subscribes – tions, which allows you to utilize deadline or latency, supported by
or the output data is always found at the same location. So, you time sensitive networking, or TSN.
don’t have to know a lot about your automation component; you can
just use it because the information is always structured in the same CLARK: So, how are those connections established?
way for anybody using that component. That is the harmonization of BIEHLER: There is the notion of an entity holding configuration data
the information model. for connections, which is called the connection manager. The con-
nection manager could be integrated into one of the automation
CLARK: Let’s clarify again how the architecture is designed. components, but it could also be located on some external server
Can it be used for both factory and process automation? like a shop floor manager, for example, connecting two machines or
CASE: Absolutely! perhaps on a plant server or something like that. The connection
Our goal is to be able to address process automation, factory auto- manager gets in contact with the two automation components that
mation, as well as hybrid situations. As Georg mentioned, the OPC are to be connected.
UA FX specification is addressing how automation components, in
those systems, exchange data. It does not specify anything about CLARK: Can you shortly summarize how data is being ex-
how devices are internally programmed. This frees-up the machine changed?
builder, the device vendor, or the system integrator to implement au- BIEHLER: Actually, data can be exchanged with a lot of different
tomation logic for whatever they have in their automation compo- quality of services. One example is the isochronous mode, which
nent, in the best way that they can. If they conform to the standard means that the end stations, the network, and the applications are
for exchanging data with other automation components, they’ll then synchronized to each other. Then you have a very precise operation
be OPC UA FX conformant and they’ll be able to exchange data with between two automation components.
other automation components, independent of the specific applica- CASE: And not every application is going to require the use of this
tion type. technology.
So, we are working to make sure that we can support applications
CLARK: Perhaps our readers might benefit from an explana- that both require the TSN technology and those that don’t.
tion of the terms, “functional entities” and “assets”.
BIEHLER: A “functional entity” models the automation function of an
automation component or a part of the automation function of an
automation component. For example, if you have a temperature sen-
sor, a functional entity could be providing the value from a tempera-
ture sensor. So, a functional entity, generally, receives input data
from somewhere else and, as an internal function, produces output
CHAPTER 3

CLARK: I’m sure that creating the specification required a lot

of prototyping and testing. Can you give us a little insight on
that? ABOUT ABOUT THE INTERVIEW PARTNER –
BIEHLER: Actually, we formed a prototyping group inside one of the CLARK CASE:
working groups that Clark mentioned before. Companies who are
interested in the prototyping work are joining together, bringing pro- Clark is the former chairperson of the Architecture (Core) Work-
totypes to exchange with each other, sharing progress and even ing Group of the FLC Technical Working Group. Clark is a Plat-
fragments of code with the goal to have several independently built form Leader for communications at Rockwell Automation,
prototypes based on our specification. where he has worked for over 20 years. In his time at Rockwell,
By sharing outcomes with each other, we prove that the specification he has worked in roles ranging field engineer and software de-
is correct – because writing a specification is a bit different than im- veloper to requirements analyst and technology manager.
plementing it – so, by implementing prototypes, you may be able to
detect flaws in the specification.
The outcome is to prove that our specification is implementable and
that several different implementations are able to interact or be in- ABOUT ABOUT THE INTERVIEW PARTNER –
teroperable with each other. GEORG BIEHLER:

CLARK: What are the next goals for the initiative and for the Georg is the editor of the OPC UA FX specification. Georg is a
specification? Senior Key Expert for industrial communication at Siemens,
CASE: Well, currently we are wrapping up work on Release Candi- where he has worked for almost 35 years. In his time at Sie-
date 1, which contains the basics for establishing connections be- mens, he has worked as software developer, team leader and
tween controllers and exchanging data. system architect. Since 25 years he is involved in standardiza-
Next up will be Release Candidate 2, which will add in TSN capabili- tion for industrial communication, amongst others he was edi-
ties, security capabilities, and support for exchanging data with SIL 3 tor of IEC 61158-5-10 (PROFINET IO services).
Safety. That will complete the scope for our controller-to-controller
release.
Release Candidate 2 should form the basis for what will be released
as version one. Once we have completed release 1, covering control-
ler-to-controller communications, we will then turn our attention to
controller-to-device communications, defining how controllers com-
municate with devices such as drives, temperature transmitters, pres-
sure transmitters, IO devices – pretty much any field-level device.
That will be a very interesting activity because, then, we’ll actually be
able to deploy systems that are fully based on OPC UA FX commu-
nications.
CHAPTER 4

OPC UA SUPPORTING FIELD

EXCHANGE (FX) INCLUDING PETER LUTZ,
Field Level Communications Director,
TSN AND APL – OPC Foundation
peter.lutz@opcfoundation.org
AN INTERMEDIATE GOAL HAS
BEEN ACHIEVED!

Two years after the launch in November 2018, the Field Level as Ethernet Time-Sensitive Networking (TSN) and the Ether-
Communications (FLC) Initiative of the OPC Foundation has net Advanced Physical Layer (APL).
completed the initial Release Candidate for OPC UA-based The FLC Initiative has also published a 40-page technical pa-
Field Exchange (UAFX) for the use case “controller-to-con- per in which the technical approach and the basic concepts
troller”. This marked an important milestone in establishing for expanding OPC UA to the field level for the various require-
OPC UA as a standardized industrial interoperability solution ments and use cases in factory and process automation are
at the field level, taking advantage of key technologies, such explained.

The member companies of the Steering Committee of the OPC Foundation’s Field Level Communications (FLC) initiative
CHAPTER 4

At SPS 2018, in Nuremberg, Germany the FLC initiative was founded

under the umbrella of the OPC Foundation. A total of 27 companies,
including the largest automation manufacturers in the world, have ABOUT THE INTERVIEW PARTNER –
joined the initiative’s Steering Committee, supporting it financially as PETER LUTZ:
well as with man-power and technical know-how (Fig. 1). The com-
mon goal is to expand the scope of OPC UA down to the field level Peter Lutz is director field level communications of the OPC
and to establish OPC UA as a uniform and consistent communica- Foundation. He has more than 25 years of experience in open
tion standard in factory and process automation (Fig. 2). In the tech- control systems, industrial automation, and real-time commu-
nical working groups, which are open to all members of the OPC nications. He has been engaged in several national and inter-
Foundation, a total of over 300 experts from more than 60 compa- national standardization committees, including IEC SC65C
nies are currently working to develop appropriate concepts and (digital communication), IEC SC22G (adjustable speed electric
specifications. drive systems), and IEC/IEEE 60802 WG (TSN Profile for indus-
trial automation). Since April 2019, he has been managing the
Work on the first version of the specification has made good pro- OPC Foundation’s FLC initiative with the goal of establishing
gress in the past year - despite Covid-19 and the associated restric- OPC UA as a globally accepted standard for field level com-
tions. The basic concepts for the use case controller-to-controller munications in the factory and process industries.
(C2C) have largely been developed and have been incorporated into
the first draft specifications. A first Release Candidate was comple-
ted in November of 2020. On this basis, prototypes have now been
implemented in order to validate the draft specifications. At the same
time, a Working Group is developing test specifications which are
then converted into corresponding test cases for the OPC UA Com-
pliance Test Tool (UACTT).

Cloud
Satellite
Industrial
Interoperability:
From Sensor
Relay
into Cloud ERP Broker
MES
SCADA

Pump

Oil Refinery

Controller Saw Controller Press DCS Mobile Robot

Initiative for Field

Field Field Field Field Field Field Field Field Field
device device device device device device device device device

Level Communications
Fieldbus APL APL
Field Field Field Field Field Field
Switch Switch device device device device

Field Field Field Field Field

device device device device device

OPC UA as an integrated communication solution down to the field level

In a second version of the specification, the already developed con-

cepts are extended for the use cases controller-to-device (C2D) and
device-to-device (D2D), with which OPC UA can then be used as a
uniform and consistent communication solution across all automati-
on levels (Figure 3). This opens up completely new possibilities, es-
pecially with regard to the different Industry 4.0 application scenarios
and IT/OT convergence.
 CHAPTER 4

The initial release candidate of the FLC Initiative, completed in Novem-

ber 2020, consists of four specification parts (OPC UA Parts 80-83)
and focuses on C2C communication (controller-to-controller) for the
Compute
OPC UA
exchange of process and configuration data by means of peer-to peer-
Object
connections and a basic diagnosis:

• Part 80 (OPC 10000-80) includes an introduction and

provides an overview of the basic concepts for expanding
C2C Controller Device D2D OPC UA for communication with and at the field level.
• Part 81 (OPC 10000-81) specifies the basic information
C2D model for controllers and field devices (automation
Use cases for OPC UA with the extensions for the field level components) and the communication concepts to meet
(controller-to-controller C2C, controller-to-device C2D and device-to-device D2D). the various use cases and requirements of factory and
process automation.
• Part 82 (OPC 10000-82) describes network services such
OPC UA at the field level – the system architecture as topology detection and time synchronization.
The extensions specified by the FLC Initiative are based on the OPC • Part 83 (OPC 10000-83) describes the data structures for
UA Framework (IEC 62541), which enables a secure and reliable, ma- the exchange of information required for offline engineering
nufacturer and platform-independent information exchange (Figure 4). using descriptors and descriptor packages.
Controllers and field devices support both, the connection-oriented
client/server communication model and the publish/subscribe extensi- Work on the safety solution for OPC UA (OPC UA Safety) is also very
ons, which are indispensable for communication at the field level due advanced. A first OPC UA Safety specification, which is based on
to the corresponding requirements for flexibility, efficiency and deter- client/server mechanisms which arose from a Joint Working Group
minism. The security mechanisms specified in OPC UA are also used, with Profibus & Profinet International (PI), was already adopted in No-
which, among other things, support authentication, signing and enc- vember 2019 (Part 15, OPC 10000-15). Revisions to the OPC UA
ryption of the data to be transported and can be used for both client/ Safety specification describe extensions for OPC UA publish/subscri-
server and publish/subscribe communication relationships. be and the parameterization of safety participants. The special thing
about the safety concept for OPC UA is, among other things, that
safe participants can be dynamically integrated into the communica-
Vendor Specific Extensions tion, with a unique identification, even while a machine or system is in
operation.
Companion Models
Progress can also be reported with regard to motion. A working group
has been developing an OPC UA-based motion solution since mid-
Motion Safety Instruments I/O ... 2020. OPC UA Motion comprises the specification of motion control
functions for various types of motion devices such as controllers,
OPC UA Core Specifications

standard drives, frequency converters and servo drives. The FLC

Automation Component Steering Committee has agreed to base the work on the CIP Motion
and Sercos specifications and to adapt them to the OPC UA informa-
Common OPC UA Models
tion modeling and system architecture, taking into account the rele-
vant Industry 4.0 use cases. The fact that, as with safety, existing
concepts and specifications are being used, the specification work
OPC UA Meta Model
can be significantly accelerated.

Built-In Security
The combination with TSN, APL and 5G
The OPC UA Framework is fundamentally transport-agnostic and can
OPC UA OPC UA therefore be flexibly used with various underlying communication pro-
Client/Server PubSub
Services & Protocols Models & Protocols tocols and transmission physics. Ethernet Time-Sensitive Networking
(Ethernet TSN) and the Ethernet Advanced Physical Layer (Ethernet
APL) are considered by the OPC Foundation as important elements of
Use case specific Mappings to Protocols & Physical Layers the strategy to expand OPC UA to all use cases and requirements in
(including APL and TSN integration)
factory and process automation and the vision to create a completely
scalable, industrial interoperability solution.
OPC UA based system architecture with extensions for the field level.
 CHAPTER 4

The combination with TSN The combination with 5G

By using Ethernet TSN, deterministic data transmission via OPC UA Data exchange via OPC UA is not limited to wired or wireless Ethernet
is facilitated, which is particularly indispensable for demanding auto- communication. Support for the 5G mobile communications standard
mation applications. In addition, TSN allows different applications and is also on the OPC Foundation‘s development horizon. The mapping
protocols to be operated using standard sized hardware and a com- to 5G will be seamlessly integrated into the existing OPC UA architec-
mon network infrastructure. This enables convergent industrial auto- ture, so that all protocol and profile extensions of the FLC initiative can
mation networks to be implemented in which various IT and OT pro- be used, not only via Ethernet and Ethernet TSN, but also via 5G in
tocols can coexist. A Working Group of the FLC Initiative is currently the future.
working out which TSN sub-standards shall be mandatory for OPC
UA-based end devices and infrastructure components in order to Summary
meet the specified requirements for performance, flexibility and ease- The OPC UA (IEC 62541) framework, with extensions for the field le-
of-use. The OPC Foundation has given a clear commitment to the vel, specified by the FLC Initiative, in combination with underlying
TSN-IA (Industrial Automation) profile, which is being developed by communication standards such as APL, TSN, and, in the future, 5G,
the IEC/IEEE 60802 working group. For this reason, the OPC Found- offers a complete, open, standardized and interoperable solution. It
ation has entered into liaison agreements with the standardization not only fulfills the requirements of industrial communication, but, at
bodies IEC SC65C and IEEE 802.1. the same time, enables consistency and semantic interoperability
from the field level to the cloud and vice versa (Fig. 5). With this ap-
The combination with APL proach - in combination with the various companion specifications -
Ethernet APL describes a physical layer for Ethernet that was spe- information is made available with a standardized semantics directly
cially developed for the requirements of the process industry. Ether- at the data source.
net APL enables data transmission at high speeds over long distan- Use cases to consider: A flow meter offers directly standardized „OPC
ces, the supply of energy and data via a common, twisted 2-wire UA flow measuring data“ the moment the APL cable is plugged in.
cable, and protective measures for safe use in hazardous areas. This And analogously, servo drives directly process standardized „OPC
makes Ethernet APL the enabling technology for the use of OPC UA UA drive setpoints” and provide standardized “OPC UA actual drive
and other Ethernet-based protocols in the process industry. Due to values” as soon as they are integrated into a machine network with
the special importance of this technology, the OPC Foundation joined Ethernet TSN.
the Advanced Physical Layer (APL) project group in June 2020 to
develop and promote APL together with other non-profit organiza-
tions and various industrial partners.

Further information:
www.opcfoundation.org/flc
External World
Downloads:
FLC Initiative Technical Paper:
Management Level L4
https://opcfoundation.org/wp-content/
L3
uploads/2020/11/OPCF-FLC-Technical-
Planning Level
Paper-C2C.pdf
Source: VDI (2013), MDPI (2019)

Supervisory Level L2
APL White Paper:
Control Level L1 https://opcfoundation.org/wp-content/
uploads/2020/06/Ethernet-APL_Ethernet-
Field Level L0
Smart Automation Device To-The-Field_EN.pdf

Network segments IT-related FLC webinar presentations / recordings:

Function OT-related www.opcfoundation.org/flc
Semantic interoperability with OPC UA from the sensor to the cloud
CHAPTER 5

OPC EXPERTS INTERVIEWS:

FUNCTIONAL SAFETY
IN THIS SECTION: Learn from an interview with Max Walter from
Siemens, in his role as the chairperson of the OPC UA Safety working MAX WALTER,
Chairman OPC UA Safety Joint Working Group
group. Max will give us a quick introduction into functional safety, how
max.walter@siemens.com
OPC UA deals with safety, discuss example use cases, talk about key
features, prerequisites, certification, and how OPC UA Safety will be-
come the one and only safety protocol.

CLARK: Max, please introduce yourself to our readers and tell cifically addresses risks stemming from incorrectly functioning
us about your involvement with OPC technology and the OPC equipment.
Foundation. For example, if there’s a risk that a motor might start while a person
WALTER: I’m located in Nuremberg, Germany working for Siemens is in close proximity to a machine, this is deemed to be an issue of
as an expert in functional safety, specifically in the area of functional functional safety. For such risks, plants will install light curtains,
safety for communication, including PROFIsafe and OPC UA Safety. emergency stop buttons, or other protective measures. These com-
I’m involved in standards development, working for IEC, where we ponents must communicate with each other and it’s critically impor-
define the prerequisites of functional safety communication. I’m also tant that the communication either works correctly or that the com-
the chairman of the OPC UA Safety Working Group and the PRO- ponents are able to detect that a communication error has occurred.
FIsafe Technical Working Group. If a communication fault is detected, the components are configured
Siemens is a founding member of the OPC Foundation and is very to transition into a safe state. This is the typical way of handling prob-
active in advancing OPC UA technology. We actively contribute by lems in a safety function; there is always a safe state into which com-
providing experts and managers, in fact, the Vice President of the ponents can switch.
OPC Foundation is from Siemens. The difference between functional safety and security is that, in func-
Siemens supports OPC UA because we see it as a very important tional safety, we deal with hardware or software errors but not with
technology today, and into the future. It’s very important that control- human adversaries. We do not take into account that somebody is
lers can collaborate and communicate with each other using OPC attacking a system, trying to provoke an accident. Something like
UA technology. this would be considered part of security and, in practice, safety al-
ways needs a secure environment. You cannot operate a safety-crit-
CLARK: Max, today we are discussing functional safety. For ical system if it is in an insecure environment. To that end, I would say
those readers that are not familiar with this topic, please give security is a prerequisite for safety, but security alone is not sufficient.
us a quick introduction. What is the difference between safety This is why it is necessary to have safety communication throughout
communication and non-safety communication? And what is a plant.
the difference between safety and security?
WALTER: Functional safety comes into play if there is a risk that
people could be injured or, perhaps, other accidents could happen,
like a potentially dangerous impact to the environment. In many in-
dustrial plants, it’s common to find components which are specifi-
cally implemented as part of a safety function. Functional safety spe-
CHAPTER 5

CLARK: How does OPC UA deal with Safety?

WALTER: In the OPC UA Standard, there is a reserved Part (or
Specification) number “15” which deals with functional safety. It’s a
specification which was jointly created by PROFIbus, PROFInet In-
ternational, and the OPC Foundation. It’s based on well-established
PROFIsafe technology. The goal is to have a specification, which
contains a protocol, describing how controllers can communicate
with each other in a vendor neutral and functionally safe way. For
example, users can connect different vendor’s PLC’s and exchange
safety critical data; like the state of an emergency stop button or the
state of a light curtain. This is how we facilitate machine-to-machine
communication in a safety-critical way.

Safety Application Safety Application

Safety Application
Application PDU
layer
Companion Companion
Specification: Protocol Data Unit Specification: To be safety-
Machine/Process- Machine/Process- certified
specific interface specific interface according to:
IEC 61784-3
IEC 61508
…

RequestSPDU
SafetyProvider SafetyConsumer
OPC UA
Safety
ResponseSPDU

OPC UA — Mapper OPC UA — Mapper

Non-safety
related part
OPC UA OPC UA of the
e.g. OPC Call
OPC UA implementation
PubSub PubSub
layer or or
Call-Service of the Method
Client/Server Service Set Client/Server

OPC UA Part 15: Safety is re-using standard OPC-technology to provide functional safe communication. All possible communication errors such as
loss, data corruption, incorrect addressing, and unacceptable delay are detected. Only error-free data is delivered to the safety application program.

CLARK: Which kinds of components can communicate via

OPC UA Safety?
WALTER: For machine-to-machine communication, a machine is
typically represented by a controller – a PLC, a DCS, or an industrial
PC – and it is important that these components are safety compo-
nents. There’s sometimes the misconception that if you implement a
safety protocol on a standard component it becomes a safety com-
ponent. Unfortunately, that is not true. The component, itself, must be
implemented in a safety-critical way. The mandate of our specification
centered around controller-to-controller communication, and just re-
cently, the Field Level Communication (FLC) initiative decided to use
OPC UA Safety as part of their work. This means that we are now
extending the specification to field-level devices such as safe IO mod-
ules, laser scanners, electric drives with safety functions, and so on.
CHAPTER 5

Unidirectional communication
Controller A Controller B
RequestSPDU
Safety Safety
SafetyProvider SafetyConsumer
Application Application
ResponseSPDU

Bidirectional communication
Controller A Controller B
RequestSPDU
SafetyProvider1 SafetyConsumer1
Safety ResponseSPDU Safety
Application RequestSPDU Application
SafetyConsumer2 SafetyProvider2
ResponseSPDU

Multicast
RequestSPDU Controller B1
Controller A
SafetyProvider1 SafetyConsumer1 Safety Appl.
ResponseSPDU
RequestSPDU Controller B2
Safety
SafetyProvider2 SafetyConsumer2 Safety Appl.
Application
… ResponseSPDU …
RequestSPDU Controller B3
SafetyProvider3 SafetyConsumer3 Safety Appl.
ResponseSPDU
The basic building blocks of OPC Safety are the SafetyProvider and the SafetyConsumer. Together, they establish a unidirectional communication link.
By instantiating multiple pairs of SafetyProviders and SafetyConsumers, bi-directional communication, multicast, and even more complex communication
topologies (line, ring, star, tree, …) can be realized.

CLARK: Can you please give us some use-case examples in CLARK: Was OPC UA Safety built from scratch, or was it de-
which safe controller-to-controller communication is needed? rived from existing fieldbus safety protocols?
WALTER: A typical example, which I’ve already mentioned, is an WALTER: Yes, of course, we wisely used what was already estab-
emergency stop button. If you have two machines next to each oth- lished. OPC UA Safety is built on the existing PROFIsafe protocol.
er, there’s a general rule that everything that is in view, from the prox- We already have some well-established mechanisms – cyclic redun-
imity of the button, should stop. In other words, in the event that dancy checks, monitoring number, SIL monitor – which we re-used
something bad is happening, you don’t want to be searching for the in OPC UA safety. Of course, there are also some novel features, one
correct button; you simply press the emergency stop button that is being the dynamic behavior that I just mentioned. So, it’s not a word-
close by and things should stop. for-word clone of the PROFIsafe specification, but rather, it’s an ad-
In another example, if you have a modular machine comprised of vanced version of it.
different modules plugged together, if you press an emergency stop
button at one module, all of the other modules should also stop. CLARK: What are the key features of OPC UA Safety?
One more example – if you open a safety door or a safety latch and WALTER: OPC UA Safety uses the standard OPC UA communica-
the machine is then supposed to run at a reduced speed, if multiple tion as a, so called, “black channel”. This sits on top of standard
machines are connected to this one, then of course, all the associ- communications. It can either use OPC UA client/server or OPC UA
ated machines should run at a similarly reduced speed. pub/sub, making it suitable for both real-time and non-real-time ap-
Looking a bit more into the future, I think it will become very impor- plications.
tant that automated guided vehicles and autonomous mobile robots The basic building block of OPC UA Safety is a unidirectional com-
are able to connect to machines and work together in one safety munication link, but if choosing to instantiate multiple links, you can
function for many obvious reasons. communicate bidirectionally or even create multicast connections. If
the architecture is comprised of more than two controllers, we can
build arbitrary bus, tree, or star network topologies.
The communication payload allows up to 1500 bytes of data per
telegram. These packets can be arbitrarily structured to include
whatever basic data types you choose as part of an OPC UA infor-
mation model.
CHAPTER 5

CLARK: Does OPC UA Safety have any existing prerequisites CLARK: Does OPC UA Safety have certification?
like error rate, transmission rate, or limits on the number of WALTER: Yes. This is a very important aspect. OPC UA Safety will
network components? be tested by a certification authority. We are working closely with
WALTER: What is important is that the communication endpoints TUV, up to Safety Integrity Level (SIL) 3 and the accompanying test
must be safety devices developed according to safety standards like specification will be TUV-Certified. Therefore, when implementing an
the IEC 61508. What is in between is the, so called, “black channel” OPC UA Safety device, the certification process will be described in
principle, where there are no requirements from a safety point of view; the test specification.
the transmission rates are not limited, the number of network ele- The OPC Foundation and PROFIbus/PROFInet International are
ments such as routers or switches are not limited. It works over any working together to establish a certification process for OPC UA
arbitrary local or even wide area networks including wireless. Yes, it’s Safety products. We are doing everything we can to make the imple-
possible to build a safety function over a wireless connection. mentation of OPC UA Safety devices as simple as possible; this in-
If you use a channel which is too unreliable, then the safety function will cludes developer training.
detect this and go into a safe state. From an availability point of view, Finally, there will be a test tool provided, and the OPC Foundation will
it’s important to ensure that the communication channel has high reli- provide a communication stack implementation, which can be inte-
ability and that it fulfills the real-time requirements of the application. grated into the device development process. If you choose to use
the stack and the test tool, then you have already done many of the
steps required for safety certification of your product.

Safety Application Program Interface (SAPI)

CLARK: What is the timeline for OPC UA Safety?
WALTER: The first release has already been published and the work-
Safety NonSafety
Data Data ing group has begun work on the next release, which will include
pub/sub (since the first release only included client/server). The test
Control Status specification and the test tools are currently under development.
… … They are targeted to be included with the second release.

CLARK: In closing, do you have any final thoughts that you

Safety would like to share with our readers?
Parameter SafetyProvider
Interface (SPI)
WALTER: If anyone wishes to cooperate in the area of OPC UA
Safety, they are most welcome. To anyone who may be interested in
reviewing and providing remarks on subsequent releases, we appre-
ciate your comments. Lastly, there is an open invitation for anyone
wishing to join the working group; we would be happy to hear from
RequestSPDU ResponseSPDU
your readers.

OPC UA – Mapper

The SafetyProvider accepts application data via the safety application interface (SAPI).
Upon receiving a RequestSPDU from the OPC UA Mapper, it returns a
ResponseSPDU containing the application data protected by an error detecting code.
CHAPTER 6

GETTING OPC UA
PRODUCTS CERTIFIED
IN THIS SECTION: Learn from an nterview with Alexander Allmendinger
from the OPC Foundation, where he outlines the process of getting ALEXANDER ALLMENDINGER,
Test Lab Manager
OPC UA products certified. He’ll explain the certification process, the
OPC Foundation European Certification Lab
preparation, how to reach compliance, the testing itself, what is being alexander.allmendinger@opcfoundation.org

tested, how to get started, and the tools available to support develop-
ers and end usesr.

CLARK: Alexander, please introduce yourself to our readers the test scripts, but I’m also heading the European certification test
and tell us about your role at the OPC Foundation. lab, which is kind of the headquarters for the certification program.
ALLMENDINGER: I’m located in the South of Germany, close to As such, I’m also educating the other test labs on the certification
Stuttgart, to be more precise, and my first contact with OPC UA was tools, the certification program, and all the implemented changes
actually before the initial specification had been released. I had the op- that are being made to the technology and certification.
portunity to do some testing of the initial versions of the OPC UA
stacks. So, I’ve been doing testing of OPC UA right from the beginning. CLARK: In a previous interview I had with Paul Hunkar, we
In the OPC Foundation, I am involved in a lot of different activities. For learned that the highest objective of OPC certification is to
example, I participate in the UA Working Group, the Security Working enhance the quality of the product. To achieve this, I assume
Group, as well as the Harmonization Working Group all with the aim you are testing compliance to the specification, but what else
to ensure that the certification labs are handling the latest updates, is being tested to achieve this goal?
so that we can assure that we use the latest versions for certification. ALLMENDINGER: So, in general, we are testing five different cate-
gories, the most obvious being the compliance test; however, we are
CLARK: So, you have been “Mr. OPC Tester” right from the not only testing all of the mandated features but also any optional
beginning. features that are being included in a product. Furthermore, we’re not
ALLMENDINGER: Well, kind of. It hasn’t been an official role. Back just doing test cases to pass, but also tests to fail.
then, the work I was doing was more internal to our company and For example, we will send chunk messages to a Server, or inject
less on the broader OPC scope. similar behavior into responses to Clients to ensure that they are be-
having compliant in all cases.
CLARK: But now you have the official hat on; so, please de- The second aspect is interoperability, and that is obviously the most
scribe what you do these days. important thing for an open standard like OPC UA. What we are do-
ALLMENDINGER: I’m working on the Compliance Test Tool, or CTT ing here is testing the communication with products of other vendors
development, though, most of all, I’m organizing all the different de- from certain markets. And while we are doing that, we ensure that we
velopment steps. I’ve personally performed quite a lot of develop- are not just using a different vendor product but also different SDK’s
ment on the CTT framework, including binary code and scripting for [software development kits] – different programming languages.
CHAPTER 6

More precisely, we ensure the interoperability for the UA services for CLARK: So, you said that not all of the features supported by
data types, security policies, user tokens, mimicking things that you the SDK are automatically included within the product; that
would see in a production environment. means that the test cases you are choosing for that specific
The third category is robustness. Now we are really digging into test- product will be related to only the features the vendor choos-
ing for communication breakdowns. es to identify, correct?
For example, assuring that a problem remains self-contained. Let’s ALLMENDINGER: Exactly!
say you have an external sensor and we deliberately create intermit- So, basically, with the feature set in mind that your product supports,
tent communications to that external sensor; we would expect the you go to the profile reporting tool or you provide a list of profiles or
product to still respond to UA requests. We also test to confirm that facets to us, which we then associate with corresponding confor-
correct status codes are being supplied to a Client so that the Client mance units. With those conformance units, your product is as-
– or the end user –is aware of what is happening. signed all the test cases that are valid for your stated profile.
These are the three core categories that we look at in order to help
enhance the quality of each product; however, we do have some CLARK: So now that I have a list of everything my product
more extensive tests. supports and the associated test cases, depending on my
For example, we look at product’s efficiency, wherein we put the product, this could be a very long list of test cases. Is there a
product under real load, then retest using the same three aspects tool available that helps me execute those tests?
that we just covered – combining compliance testing with interoper- ALLMENDINGER: Luckily, yes.
ability and robustness. As I already mentioned, I’m one of the developers for that tool; it is
We do this by connecting the device under test with a minimum of the CTT or Compliance Test Tool. To be more precise, it’s actually
five other products. We begin by ensuring that communication is called the UACTT, but the UA is often omitted.
stable and works fine; then we inject intermittent communication to The Compliance Test Tool is like the certification program itself; it’s not
not only the OPC UA peers but also to underlying data sources. only available to paying members of the OPC Foundation, but also to
While doing this over a span of 72 hours, we measure the CPU us- non-paying members. The Compliance Test Tool can do a lot of auto-
age, RAM threads, and handles. By doing this, we ensure that the mated testing for OPC UA Servers, but it also helps with Client certi-
products are really capable of doing long term runs in production fication preparation because Client testing is not that easy. The UA
environments. specification requires Clients to support certain application-logic.
And then, last but not least, we evaluate product usability, which is For example, it isn’t possible to automate a test to see if a bad status
basically all about having a positive end user experience. So, we take code, received from the communication partner, is being indicated to
a look at product documentation, help files, and how intuitive it is to the end user; therefore, we need to take manual steps here. So, the
use the product – the idea being that we hope to ensure that a certi- CTT, when in client-mode, helps you to inject bad status codes in
fied product is very easy for end users to operate. order to force some bad things to happen, resulting in valid Client
To illustrate, if we notice that certificate handling – a very complex behavior.
task – is not described well in the product documentation, we will
point that out to the vendor and suggest enhancement tips and CLARK: So, does the CTT cover OPC UA security features?
ideas so that product documentation can be improved. ALLMENDINGER: Of course.
So, like I said, in total, we concentrate on five areas: compliance, The security aspects in OPC UA are quite important and, as such,
interoperability, robustness, efficiency, and usability in order to en- they are an important part of certification and testing. The CTT takes
sure very high-quality products. care of all the different aspects of the security features, like certificate
validation steps, which are an important thing when it comes to com-
CLARK: So, where and how do interested parties get started; plex CA [Certificate Authority] structures that are being used in pro-
what is the first thing I, as an interested party, would need to duction environments; but also, when it comes to user token han-
do to get a product certified? dling, having secure connections, handshakes, and everything
ALLMENDINGER: Well, the very first thing you need to do is to associated with them.
identify all the features that are being supported by your product. An The compliance test tool is continuously enhanced to have all the
important thing to remember here is that a product does not auto- new security mechanisms integrated fairly fast; however, having said
matically include all the features that are being supported by the par- that, especially when it comes to security, sometimes there are man-
ticular SDK the vendor chooses for their development. Even though ual test cases. Once again, it depends on whether application-logic
an SDK can do a lot for you, it cannot do everything. Some features is required and especially when it comes to the fact that you want to
do require manual integration and, therefore, the very first thing is to enable and disable security policies that are the baseline for secure
identify the real features that your product supports. communication in OPC UA. This may become necessary if a particu-
We provide the vendor with a profile reporting tool, which basically lists lar algorithm has been cracked. You may then have a use case for
all the different features that are described in OPC UA, in order to help manual steps, therefore, there are always manual test cases when
the vendor identify each of the included features within their product. performing security compliance testing.
CHAPTER 6

CLARK: So, this tool can validate product compliance, but CLARK: What happens during the actual testing – how is the
how about interoperability – is that being tested as well? testing executed?
ALLMENDINGER: Well, the nature of that kind of testing is to check ALLMENDINGER: We like to do our testing as efficiently as possi-
the interoperability between different applications. The CTT is only ble, so we try to prepare the whole environment before testing com-
one application; therefore, it is quite obvious that it cannot perform mences; we do the installation; we perform test tool commissioning;
interoperability testing with only one active application. Thankfully, we prepare the environment; all of this is taken care of prior to the
this need was identified by the OPC Foundation a long time ago. As actual testing date.
a solution, they host an event called Interoperability Workshop or IOP We typically start the testing on either a Monday or a Tuesday, and
Workshop, which invites interested vendors to gather in one room to what we do on the first day is product commissioning. We ask the
test and validate the interoperability between their applications. I vendor to guide us through the product; to guide us through how to
highly recommend that each provider attend these IOP workshops to use the application; to teach us how to find everything we need to test.
ensure the interoperability of a product. This is usually not that difficult for us, especially if we’ve already seen
four comparable applications from different vendors, the fifth is likely
CLARK: Assuming I’ve done everything you’ve mentioned so very similar – it just uses different icons.
far, what is the next step? How do I get the actual process of Now, having said that, what is most important for us is that, through-
certification testing started? out the entire test period, we have a developer or an expert from the
ALLMENDINGER: So, on the OPC Foundation website, the whole vendor available. The reason for this is that, if we have questions or
process is documented. There, you will find a certification section find issues, we have an expert with whom we can discuss how to
and that is where you can always look for more information on the perform a particular setup or a certain scenario in order to get it
next steps. working. This helps us work as efficiently as possible.
Now, in order to get the process started, there is something called
the application request form, which is located in the “How to Certify” CLARK: What happens if an issue is discovered during testing?
section. The request form covers a lot of questions about your prod- ALLMENDINGER: So, if an issue is found, we are prepared for such
uct; which features are being supported, which SDK did you use for events. Actually, it isn’t that uncommon but what we do in such cas-
your development, which version we are talking about, what operat- es is that we report any issues at either the end of a testing category
ing system, and so on. By providing all this information to the lab that or, more typically, at the end of a testing day. We provide detailed
will execute the testing for you, they can come up with an official feedback – not simply that you failed test case number 24 in a certain
estimate as to how long it will take to certify your product. So, after conformance unit but, rather, we explain what went wrong and what
we take a look at the completed form, we may say that it will require may or may not be the issue here. Then we start an iterative ap-
seven days of testing to get the product to a certifiable state; how- proach, because we can continue the testing with the other unaf-
ever, if the product is well prepared, we don’t find any issues, and it fected areas.
is very intuitive to use, perhaps we may only need four days of test- So, let’s say you have an issue in a write-call; that doesn’t prohibit us
ing. In that case, it is only four days of testing which the company from testing the read-call or data change notifications or security as-
needs to pay – it’s not always necessary to pay the whole lump sum. pects. We will still continue testing other aspects until you have a fix
for the earlier issue that we reported. Once you’ve provided us with
CLARK: To get my product certified, does someone need to the update, we will apply it to the product; we will verify that you
be at the lab in person? didn’t just tweak something but that you actually fixed the issue; then
ALLMENDINGER: Actually, we can do a fully virtual certification; we will do some spot checks on potentially affected features.
that is absolutely possible, in fact, it is the most common case. We Once we get to the point where there are zero failed test cases, we
provide you with an access point, which most likely will be a virtual have a certified product.
machine in a designated network where you can verify your applica-
tion as well as access all the reference products that we’re going to
use for testing. With this arrangement, we basically virtualize every-
thing, so we don’t need to have an in person visit.
CHAPTER 6

CLARK: Good. This then means that they get an official docu-
ment which will contain the name of the product tested, the
date it was tested, and then that gives them the right to use ABOUT THE INTERVIEW PARTNER –
the Certified OPC UA product logo, is that right? ALEXANDER ALLMENDINGER:
ALLMENDINGER: Absolutely!
In fact, at the end of testing they get a few documents. The first one Alexander Allmendinger is heading the OPC Foundation Euro-
is a testing summary – this is the document that I highly recommend pean Certification Test Lab since 2016. In this role he actively
every end user request when evaluating certified products. This sum- participates in shaping the certification program of the OPC
mary provides all the details of what has been tested and under what Foundation. He also works in the training and auditing team for
environment. certification test labs as well as being a member of the Compli-
The second document is a detailed test record – we’re talking about ance Steering Committee. To complete the scope of testing
a few hundred pages, which I agree is not necessarily the thing that the OPC Foundation also appointed him to coordinate the In-
you want to take a look at as an end user. teroperability (IOP) Workshops of the OPC Foundation as IOP
Next, they get a report pertaining to the efficiency test, including Workshop Coordinator.
some graphs. And last, but not least, they receive the Certified for
Compliance logo and the Compliance Certificate.

CLARK: OK, final question; are there any final thoughts that
you would like to share with our readers?
ALLMENDINGER: There is a big push coming from each of the dif-
ferent joint working groups with respect to their companion specifi-
cations. A lot of companion specifications are aiming for a way to
ensure that products, those built to the standards of the companion
specifications, can be tested so that not only the vendor themselves
can verify whether they have done everything right, but also provide
an opportunity to end users allowing them to test a product once
they’ve commissioned it.
We have already integrated testing scripts into the CTT for multiple
companion groups, including MDIS, which is from the oil and gas
industry; PLC-Open representing PLCs; and a first draft for PA-DIM
testing. We have further developments under way for automated
testing capabilities for IO-Link and machine tools as well as other
groups from VDMA.
OPC FOUNDATION HEADQUARTERS
OPC Foundation
16101 N. 82nd Street, Suite 3B
Scottsdale, AZ 85260-1868 USA
Phone: 480 483-6644
office@opcfoundation.org

OPC FOUNDATION EUROPE

opceurope@opcfoundation.org

OPC FOUNDATION CHINA

opcchina@opcfoundation.org

OPC FOUNDATION JAPAN

opcjapan@opcfoundation.org

OPC FOUNDATION KOREA

opckorea@opcfoundation.org

OPC FOUNDATION ASEAN

asean@opcfoundation.org

OPC FOUNDATION INDIA

opcindia@opcfoundation.org

www.opcfoundation.org