67

OPC UA forOPC
Extending Field
UALevel Communication
to the field: –
A Theory
OPC of Field
UA for Operations
eXchange (FX)
Version 1 // November 2020
Version 2 // November 2021

Technical Paper
Technical
2

Executive Summary

Digitalization of products and systems opens the op- On a technical level, this approach requires stan-
portunity to deliver new and enhanced software so- dardization to take place on multiple levels: seman-
lutions and enables new digital services and busi- tics, information modeling, communication proto-
ness models. The implementation of concepts is cols, data link layer and physical layer – all embraced
made more difficult because of the heterogeneity of by a common cyber-security framework. An impor-
communication protocols at the field level. Although tant aspect is the convergence of information tech-
most of today’s fieldbus systems and Real-Time Eth- nology (IT) and operational technology (OT) allowing
ernet protocols are standardized by IEC in the a common network infrastructure to be shared by IT
61784/61158 series, automation devices supporting and OT traffic while guaranteeing different levels of
different protocols are not interoperable with each quality of service (QoS) demanded by diverse IT and
other and often cannot coexist in a common network OT applications. Technologies of particular impor-
infrastructure. In addition, device information is tance are the Ethernet Advanced Physical Layer
structured using different information models, which (APL) and Ethernet Time-Sensitive Networking
makes data analysis a labor-intensive and time-con- (TSN). APL facilitates seamless Ethernet connectivity
suming task that is also vulnerable to errors, espe- down to the field level, including long cable lengths
cially in multi-vendor and multi-protocol environ- and explosion protection via intrinsic safety with
ments. power and communication over two wires. TSN en-
However, the trend of moving to seamless interoper- ables deterministic communication on standard Eth-
ability accelerated by the dawn of the Industry 4.0 ernet, allowing IT and OT protocols to coexist in a
and Industrial Internet of Things (IIoT) era requires common network infrastructure.
industrial system integration to become vendor-inde- The OPC Foundation’s Field Level Communications
pendent and to support end-to-end interoperability Initiative was established in November 2018 to spec-
from sensor to cloud, including field level devices for ify extensions to the OPC UA framework in
all relevant industrial automation use-cases, includ- order to standardize the semantics and behaviors of
ing real-time, motion, and functional safety. controllers and field devices from different manufac-
Standardized communication from sensor to cloud turers. The main use cases covered by the Initiative
will support the digital transformation across all in- are controller-to-controller, controller-to-device, and
dustries, including factory automation and process device-to-device including support for IIoT connec-
automation. End users, machine/skid builders and tivity for both controllers and devices (controller-to-
system integrators will benefit from easier system in- compute and device-to-compute). The technical
tegration and cross-vendor interoperability. Seam- work is being performed in OPC Foundation multi-
less access to production data and process condi- vendor working groups that define the technical con-
tions will facilitate availability and optimization of cepts and specify the different mechanisms to
production processes. achieve these goals. The specifications to extend
OPC UA for field-level communications are named
OPC UA FX (Field eXchange), abbreviated UAFX.
 3

Contents

4 INTRODUCTION 25 SAFETY COMMUNICATION

4 Background 26 Safety for field-level communications
5 Field Level Communications Initiative 27 SafetyProvider
6 Target audience 27 SafetyConsumer
6 Document walkthrough
28 SECURITY
8 TECHNICAL SYSTEM DESCRIPTION 28 Security for UAFX connections
8 System Architecture
10 Interaction Model 29 TRANSPORT
10 Controller-to-Compute 29 Communications Profiles
10 Controller-to-Controller 29 Profile A
10 Controller-to-Device 29 Profile B
11 Device-to-Device 30 Transport and Network Access Facets
11 Device-to-Compute 30 Transport Facets
11 Compute-to-Compute 30 Direct Network Access Facet
11 Communications Patterns 30 TSN Network Access Facet
12 Unidirectional 30 TSN Bridge Facet
12 Bidirectional 31 Interoperability Matrix
12 Communication Configuration
32 ETHERNET – ADVANCED PHYSICAL LAYER
14 AUTOMATION COMPONENT MODEL
14 Automation Component / 34 REAL-TIME COMMUNICATION MODEL
Functional Model and Asset Model 34 QoS concept
15 From Functional Entity to the Communication 34 TSN QoS mechanisms
Relationship 35 Types of UAFX traffic and their QoS requirements
16 The Role of the Connection Manager 35 TSN Domains and examples for communication
17 Connection state machine relations
37 Network Management
18 OFFLINE ENGINEERING WORKFLOW
AND MODEL 38 SUMMARY AND OUTLOOK
18 Introduction
19 Descriptor Definition 39 ACRONYMS
20 Product Descriptor
21 Configuration Descriptor 40 CONTACT
22 Workflow examples
22 System with a Line Controller and
3 subordinate controllers without TSN
23 System with a Line Controller and
3 subordinate controllers with TSN
4

Introduction

Background connected via today’s near ubiquitous IP-based net-

The goal of digitalization is to foster the integration of works. While Ethernet provides the ability for things
IT technologies with OT products, systems, solutions to ‘reach’ each other, they still need a common way
and services across their complete value chains, to communicate. Standardized data connectivity
which stretches from design and production to main- and interoperability addresses this need.
tenance. Once implemented, digitalization of prod- In simple terms, with standardized data connectivity
ucts and systems opens the opportunity to deliver at its core, the Industrial IoT (IIoT) can be looked at
new and enhanced software solutions and enables from two perspectives: horizontal and vertical data
new digital services and business models. connectivity. An example of horizontal communica-
The Internet of Things (IoT) brings together a broad tions is: Controller-to-Controller (C2C) data connec-
range of technologies to those OT products, sys- tivity between shop floor systems. An example of
tems and solutions that have traditionally not been vertical communications is device-to-cloud data

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

Pump

Oil Refinery

Controller Saw Controller Press DCS Mobile Robot

Field
device
Field
device
Field
device
Field
device
Field
device
Field
device
Field
device
Field
device
Field
device Initiative for Field
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

Figure 1: OPC UA use cases and scope of OPC Foundation’s Field Level Communications Initiative
 5

transfer. In both cases, the OPC Unified Architecture Field Level Communications Initiative
(OPC UA) standard from the OPC Foundation pro- At the SPS IPC Drives Fair 2018 in Nuremberg,
vides a secure, reliable, and robust foundation to fa- Germany, the OPC Foundation officially launched
cilitate standards-based data connectivity and in- the Field Level Communications Initiative. This Initia-
teroperability. For years, many companies and tive aims at extending OPC UA to field level to
partner organizations have openly worked together achieve an open, unified, standards-based IIoT com-
under the umbrella of the OPC Foundation to make munication solution between sensors, actuators,
this a reality and will keep doing so as it continues to controllers and cloud addressing all requirements of
expand its collaboration activities. factory automation and process automation (see
A key aspect of improving horizontal and vertical data Figure 1). Consequently, the OPC Foundation’s vi-
connectivity is network convergence supporting a sion of becoming the worldwide industrial interoper-
common network for IT- and OT-related communica- ability standard is advanced by extending OPC UA to
tion. Ethernet Time-Sensitive Networking (TSN) ac- the field level. Vendor independent end-to-end in-
cording to IEEE 802.1 supports communication with teroperability between field level devices is provided
bounded latency and jitter. In addition, various data for all relevant industrial automation use cases, in-
streams, and traffic types can be transmitted over a cluding real-time, functional safety and motion, all
common network infrastructure, while at the same requiring secured information exchange.
time guaranteeing the various bandwidth, latency,
jitter and reliability requirements of the different ap-
plications. Therefore, TSN plays a key role in sup-
porting the convergence of IT and OT. The Ethernet
Advanced Physical Layer (APL) is another key tech-
nology to drive network convergence as APL deliv-
ers seamless Ethernet connectivity to sensors and
actuators in process automation – including hazard-
ous areas.

The IT and OT worlds are converging. The Field Level Communications Initiative aims to
achieve the following four types of convergence:
1. UAFX application convergence where multiple UAFX automation devices from multiple vendors
share one network.
2. OT convergence where multiple systems and devices from multiple vendors using different
OT protocols share one network.
3. IT/OT convergence where multiple controllers, devices, applications, and systems from different
vendors using a combination of IT and OT protocols share one network.
4. IT/OT organizational convergence where the boundary between organizations blurs and
management of IT and OT groups operate to common strategies and processes.
6

Target audience Document walkthrough

The target audience for this technical paper are engi- To guide the reader through the document, an over-
neering managers, automation engineers, technical view about the structure and the content of each
product managers and technical sales representa- section is given:
tives who would like to get an overall understanding
of the technical approach and the basic concepts 1. The Technical System Description (pages 8 –
developed by the OPC Foundation’s Field Level 13) outlines the technical approach taken to ex-
Communications Initiative. tend the OPC UA framework for supporting ad-
ditional use cases in factory automation and
process automation. Details about the system
architecture, the software interactions and the
communication patterns are given, highlighting
the key Controller-to-Controller (C2C) use cases
and the target network architecture that are ad-
dressed in the first specification release.

2. The following section Automation Component

Model (pages 14 – 17) outlines the approach to
model Automation Components using an Asset
Model and a Functional Model with Functional
Entities. Details about UAFX connections, Con-
nection Configuration Data and the Connection
Manager are given, as they include the key con-
cepts for exchanging data between multiple Au-
tomation Components.

3. In the section Offline Engineering Workflow

and Model (pages 18 – 24) the workflow for a
control systems engineer is described to enable
the C2C use cases prior to on-site commission-
ing. Two descriptor concepts are explained: the
product descriptor for product-related data of an
Automation Component and the configuration
descriptor that contains a product-related part
and one or more configuration parts. Two exam-
ples demonstrate how the workflow looks like in a
scenario with one line controller and three subor-
dinate controllers with and without TSN, using
Configuration Descriptors which will form part of
Configuration Descriptor Packages.
 7

4. In the Safety and Security sections (pages 25 6. The last section Summary and Outlook (page
– 28) it is explained how data for functional safety 38) gives an overview of the key achievements
applications is exchanged between Functional and future work of the Field Level Communica-
Entities principle in combination with standard tions Initiative in order to support all relevant use
UAFX connections. SafetyProviders and Safety- cases and application scenarios in factory auto-
Consumers exchange safe data using OPC UA mation and process automation. Furthermore, it
Safety, a safety transmission protocol which fa- is explained what measures are taken to ensure
cilitates the use of OPC UA in safety-critical ap- an easy implementation of the technology as well
plications. This is followed by an explanation of as cross-vendor interoperability.
how UAFX connections are secured during con-
nection establishment and data exchange against
malicious attacks.

In the section Transport (pages 29 – 31) the

5. 
UAFX-supported communication profiles and
their structures with regard to the transport facets
and network access facets are described. Fur-
thermore, it is explained how interoperability is af-
fected when mixing devices supporting different
communication profiles. Afterwards the impor-
tance and the impact of the Ethernet Advanced
Physical Layer (APL) and Ethernet Time-Sensitive
Networking (TSN) are described in the context of
extending OPC UA to the field level.
8

Technical System Description

System Architecture The technical work within the Field Level Communi-
OPC UA is the data exchange standard for secure, cations Initiative includes the following topics:
reliable, manufacturer and platform-independent in-
dustrial communication. It is based on specifications ➞ definition of a base model for Automation Compo-
that were developed in close cooperation between nents that are common to all UAFX-conformant
manufacturers, users, research institutes and con- controllers and devices
sortia, in order to enable secure and reliable informa- ➞ definition of system behaviors and sequences for
tion exchange in heterogeneous systems. Neverthe- common functionalities e.g. bootstrapping, con-
less, the additional mechanisms needed to satisfy nection establishment, etc.
the specific OT-related requirements – such as func- ➞ harmonization and standardization of application
tional safety, determinism, and redundancy – for profiles such as IO, motion control, functional
information exchange between devices and con- safety, system redundancy
trollers in manufacturing factories and process auto- ➞ standardization of OPC UA information models for
mation plants were lacking (see Figure 2). field-level devices in online and offline scenarios
e.g. device description, diagnostics, etc.

Vendor Specific Extensions

Companion Models

Motion Instruments I/O ...

Safety

Automation Component
OPC UA Core Specifications

Common OPC UA Models

OPC UA FX Additions

OPC UA Meta Model

Built-In Security

OPC UA OPC UA
Client/Server PubSub
Services & Protocols Models & Protocols

Use case specific Mappings to Protocols & Physical Layers

End Stations and Bridges, their management and the required

network services (Ethernet/TSN, SPE/APL, WLAN, or cellular (e.g. 5G))

Figure 2: Extending OPC UA for the field: OPC UA for Field eXchange (FX) System Architecture
 9

➞ integration of OPC UA companion models The technical work results in specifications that ex-
➞ support of Ethernet TSN for deterministic com- tend the OPC UA framework. These specifications
munication and IT/OT convergence are identified with OPC UA FX (Field eXchange).
➞ mapping of application profiles related to real-time
operations on Ethernet networks including TSN In the first OPC UA FX specification release (Ver-
➞ definition of facets, profiles and conformance sion  1), the focus is on the Controller-to-Controller
units that can be tested to guarantee interopera- (C2C) use case which includes exchanging both
bility across vendors standard and safety real-time data using OPC UA
➞ definition of certification procedures Client/Server and OPC UA PubSub in combination
with a peer-to-peer application relationship and ba-
sic diagnostics. The target network architecture is
shown in Figure 3.

Non-UAFX, Network
non UA App Monitoring
(e.g. Video and Mgmt
Monitoring) Application

Vendor 1 Vendor 2 Vendor 3 System HMI System MES / ERP

Controller Controller Controller Historian
Eng Tool Eng Tool Eng Tool

L3 Switch

Non-UAFX
TSN Device L2 Switch L2 Switch
(e.g. Camera)

Vendor 1 Vendor 2 Vendor 3 Vendor Vendor 1 Vendor 2 Vendor 3

Controller Controller Controller Controller Controller Controller Controller
TSN TSN TSN and TSN Non TSN Non TSN Non TSN
Non TSN

Network Mgmt Protocols

Cyclic Non TSN
Isochronous TSN
Non-UAFX
Standard OPC UA Services

Figure 3: Controller-to-Controller supported network architecture

10

Interaction Model ➞ Controller-to-Controller

In the interaction model shown in Figure 4, a con- Plant owners and system integrators are assembling
troller represents a function typically implemented in complex operations using machinery purchased
a Programmable Automation Controller (PAC), Pro- from different machine/skid builders. They may find
grammable Logic Controller (PLC) or Distributed that each is fitted with a controller from a different
Control System (DCS) controller. Today, automation vendor, resulting in a need for an easy way to set up
devices are typically connected to controllers and controller-to-controller communications across mul-
can be as simple as an inductive proximity switch or tiple vendors. This problem has not been solved in
as complex as a Coriolis Flow Meter or Servo Drive. industrial automation to date and the UAFX control-
Compute refers to standalone software applications ler-to-controller solution created by the Field Level
running on a variety of hardware platforms, from an Communication Initiative will be the first to deliver an
edge gateway to a blade server in the cloud. Control- interoperable real-time solution covering both stan-
lers and Devices have many attributes in common – dard and safety communications for all types of au-
the term “Automation Component” is used where tomation applications.
functions apply to both.
➞ Controller-to-Device
➞ Controller-to-Compute The traditional fieldbus approach of having a control-
Software running on Compute platforms is a major ler communicate with a subnet of I/O modules,
area of innovation today, whether it is management drives, servos, instruments, and other smart Auto-
information in dashboards, long term process opti- mation Components is well understood in the indus-
mization, predictive device-level diagnostics or digital trial automation community. Albeit it comes with
twins. These all require information to be extracted constraints on network architecture and topology
from controllers. OPC UA is dominant today, and al- when a converged IT/OT solution is deployed, or dif-
most every major controller supplier offers OPC UA
directly on its controller or device.

Compute
OPC UA
Object

Controller Device

Figure 4: Interaction Model for OPC UA including field level communications (UAFX)
 11

ferent Industrial Automation technologies share the ➞ Compute-to-Compute

network. The Field Level Communications Initiative These applications include gateways to IT systems,
will deliver controller-to-device communications that cloud-to-cloud connectivity, interoperable manufac-
meet or exceed the capabilities provided by the turing operations management, and many more. The
IEC 61784 profiles. Field Level Communications Initiative will use and
build on the services, information modeling, and in-
➞ Device-to-Device teroperability that have driven the success of OPC
In bringing together best practices for multiple shop- UA in compute-to-compute applications over the
floor technologies and by harmonizing the applica- last decade. While no need for further development
tion profiles used in end devices, applications such of capabilities to support compute-to-compute ap-
as load sharing of inflexible loads across multiple plications is expected within the Field Level Commu-
servo drives will become far easier to deploy in an nications Initiative, these applications will inherit and
interoperable manner. benefit from the increased harmonization delivered at
the field level.
➞ Device-to-Compute
Controllers often serve as a proxy for devices, add Communications Patterns
valuable context to the information provided by these An example of controller-to-controller communica-
devices, and in some cases control access to that tions is where a blending skid of one vendor is inte-
information. However, as devices become increas- grated into a homogenizer of another vendor, each
ingly complex with an ever-growing number of useful selecting controllers from different vendors with their
variables and internal and external measurements, own eco-system of devices (see Figure 5). Similar
the use of a controller as a proxy becomes increas- examples exist with machines and distributed auto-
ingly impractical. For example, routing thousands of mation systems.
variables from each device through a controller is no
longer scalable. OPC UA for field-level communica-
tions will define the necessary semantics and meta-
data to contextualize the information from devices for
use in diverse compute-based software applications
in an open architecture without the controller acting
as a bottleneck.

Vendor 1 Vendor 2
Homogenizer Blending skid

Figure 5: Controller-to-controller example

12

OPC UA FX supports two new enhanced approach- changed in both directions, but the controller
es that make use of OPC UA PubSub without pre- does not initiate any communication.
venting the currently available Client/Server mecha- ➞ Machine 2 controller initiates all communications,
nisms to exchange data between these machines: but its designer must ensure that it is both trans-
mitting and receiving information in a form usable
➞ Unidirectional by Machine 1’s application code.
The name unidirectional derives from the flow of ap-
plication data. Each machine’s designer creates a In this case, Machine 1’s behavior is very similar to that
configuration descriptor of output information avail- of an I/O module.
able and supported configurations (update rates,
security, etc.) in their controller for the other control- Communication Configuration
ler’s use. Other machine designers can then import Standardized configuration descriptors are used to
the descriptor to enable communications and to exchange communication configurations between
customize their code to correctly use the data made the engineering tools of the controllers. An engineer-
available by other controllers as inputs to their own ing tool and a controller together can automate the
machines. creation of all necessary information model entries,
automate the establishment of a connection to the
➞ Bidirectional other controller and automate fault handling. Some
This model extends the unidirectional model and flexibility may be needed in post-installation commu-
inherits all attributes of that model. nications configuration, especially in cases where
In this model, designer 1 fixes the data and format multiple identical machines or skids are delivered to
that their controller both transmits (outputs) and re- a single application (see Figure 6). The level of allow-
ceives (inputs). It is the responsibility of the other able configuration must be controlled by the machine
controller (and its designer) to initiate communica- designer and the actual configuration may be set us-
tions to designer 1’s controller and to provide/con- ing by any generic OPC UA Client. In this example,
sume information in the format demanded by de- two identical machines have been purchased from
signer 1. Vendor 1 and two identical machines from Vendor 2.
In the unidirectional model, responsibility is symmet- None of the machines change function or operation
rical with both the designer of Machine 1 and Ma- post-installation, but there is no planning in advance
chine 2 performing exactly the same functions in or- of which machine is connected to which, and poten-
der to establish communications in both directions tially, no pre-planning of the network identification of
between the two controllers. In the bidirectional each machine once installed. At the time of commis-
model, one party defines both inputs and outputs sioning, each machine (or more specifically, the con-
from their equipment and the other party establishes troller in each machine) must be given its network
a bidirectional connection – the two machine control- identity (e.g. hostname or IP address) and must have
lers perform different functions in the communication the target network identity of the controller in the
relationship: other vendor’s machine using a general- purpose
➞ Machine
 1 designer defines the data to be ex- OPC UA client.
 13

Vendor 1 Vendor 2
Machine Machine

Vendor 1 Vendor 2
Machine Machine

Figure 6: C2C Example with two identical lines (Case 1)

In the following example, two identical blending skids has two unique connections for ‘a’ Vendor 2 skid
are integrated into a homogenizer of Vendor 1 (see which function in the same way but carry different
Figure 7). As in the previous example, the network data. The two Vendor 2 skid controllers must be told
identity of each Vendor 2 skid controller must be ap- by both the network identity of the Vendor 1 control-
plied to the relevant connection in Vendor 1 control- ler, and the internal identity of the connection to
ler. However, further information must be given to which they must be associated.
both of the Vendor 2 skids, as Vendor 1 controller

Vendor 2
Blending skid

Vendor 1
Homogenizer

Vendor 2
Blending skid

Figure 7: C2C Example with two identical skids in the same line (Case 2)
14

Automation Component Model

Automation Component – The AC is composed of two major groupings, the

Functional Model and Asset Model asset model and the functional model. Asset infor-
UAFX systems must expose their information using a mation typically describes physical items, but it can
prescribed OPC UA Information Model. The model is also include items that are not physical, such as firm-
based on an Automation Component (AC), which is ware or licenses. The Asset Model is based on the
an entity that performs one or more functions that DI-Information Model (OPC 10000-100 – Part 100:
are part of automation devices (e.g. controllers, Device Information Model) but extends the use cases
drives, instruments, I/O devices) (see Figure 8). in scope of the Field Level Communications Initiative.
All ACs are modeled as one or more Assets, and/or The Functional Model describes a logical functional-
one or more Functional Entities. Additionally, an AC ity. The functional model consists of one or more
contains information describing the Network Inter- Functional Entities which encapsulate features,
faces and Network and Communications Services which can include input/output variables, communi-
the AC supports. cation, and device parameters, as well as communi-
The scale of an AC is up to the vendor. It could be as cation connections. A Functional Entity (FE) is ab-
small as an individual standalone I/O device or as stracted from the hardware, which allows porting of
large as a complex room-sized machine. applications to new hardware. Functional Entities

Automation Component

Asset Model Functional Model

Hard Assets Functional Entity

Functional Entity
8.5 Identifying Properties
pH Functional Entity
Identifying Properties
Identifying Properties
Input
Variables
Input
Analyzer pH sensor Chlorine sensor References
Variables
Input
Module Module Configuring Variables
Variables
Configuring
Variables
Configuring
Output Variables
Variables
Output
Analyzer pH sensor Chlorine sensor
Firmware Module Firmware Module Firmware Variables
Output
Soft Assets Variables

Time Sync ....

Streams .... Network Services

Bridge
Ethernet Interface Model
Port Port

Figure 8: UAFX Automation Component Model

 15

reference assets that they are associated with or UAFX connections are the logical constructs used to
execute on, and allow applications to confirm that exchange a defined set of process data and process
any hardware requirements that the applications data quality information. Inside a UAFX connection
have are met. For example, a two-axes drive may be one or more PubSub DataSetWriter and DataSe-
based on one asset including two Functional Enti- tReader are responsible for exchanging the data with
ties. the other Functional Entity.
For exchanging process data using PubSub, the fol-
From Functional Entity to the lowing connection types are supported:
Communication Relationships
A Functional Entity is an element of an AC that repre- 1. Unidirectional
sents a functional capability of the AC (see Figure 9).  2. Unidirectional with heartbeat
Examples of Functional Entities include application 3. Bidirectional
execution engine, motion axis control, a sensor, a
relay, I/O control, and variable frequency drive con-
trol. There can be multiple FEs in an AC.

Automation Component (AC) A Automation Component (AC) B

Functional Entity Functional Entity

Identifying properties Identifying properties

Diagnostics Diagnostics
Input Event Input Event
data data

Configuration Processing Configuration Processing

data data
UAFX connection
Output Diagnostics Output Diagnostics
data data data data

Figure 9: UAFX connections between Functional Entities

16

The Role of the Connection Manager The Connection Configuration Data consists of the
The Connection Manager (CM) is a service respon- following parameters:
sible for establishing connections between FEs. It ➞ Description of the endpoints to be connected
uses Connection Configuration Data such as partner – Local Address, consisting of the address of
communication address, update rate and QoS set- the OPC UA server located on the AC, and
tings, to set up communication with one or more the browse path to the Functional Entity to
communication partners (see Figure 10). connect
The CM is modeled as a distinct entity. This entity – Remote Address
resides typically in an AC which initiates the connec- ➞ Choice of unicast or multicast
tion establishment via an internal mechanism, but ➞ QoS option and their pparameters (including TSN)
may optionally be realized as an external entity. ➞ For process data
– PublishingInterval (for the data publisher)
– MessageReceiveTimeout
(for the data subscriber)
➞ For heartbeat
– PublishingInterval (for the heartbeat publisher)
– MessageReceiveTimeout
(for the heartbeat subscriber)
➞ Connection timeout (for the cleanup)
➞ Compatibility verification parameters

Integrated CM External CM

AC_1 X AC_3
Functional Functional
CM Entity CM Entity
Connection Connection
Establishment Establishment

Connection AC_2 connection Connection AC_4 connection

Establishment Functional Establishment Functional
Entity Entity

Figure 10: Integrated or External Connection Manager of Automation Components

 17

UAFX connection state machine machine, which only addresses the single state of a
The Connection Manager (CM) must establish a PubSub Connection, but not how to reach this sta-
UAFX connection on two endpoints in parallel. For tus.
each of the endpoints a separate connection state A UAFX connection is initially set-up using Client/
machine is needed (see Figure 11). Server mechanisms, where information to establish a
For joint operation of the two endpoints, it is pro- bidirectional PubSub Connection, such as compati-
posed that the CM executes the state machine for bility verification, ownership and parameterization, is
the two endpoints in parallel, meaning step by step exchanged. Thereafter the PubSub Connection is
on the one and the other endpoint. This will later prepared and operational.
ease the startup of the communication. The UAFX Connection State Machine for each UAFX
This UAFX Connection State Machine extends the connection is defined in the information model of a
OPC 10000-14, chapter 6.2.1 defined PubSub state Functional Entity.

UAFX Connection State

Initiated by Timer CleanupConnection () Initiated by CM

Configured
CleanupConnection ()
EstablishConnection ()

Initial
Not operational
Implicit

Ready

AutoCleanup
Timeout Implicit Enable

Preoperational
Internal Error
Reception of input data
Reception of
input data
Error Operational

Loss of input data

or internal error MessageReceive
Timeout Initiated by PubSub

Figure 11: UAFX Connection State Machine

18

Offline Engineering Workflow and Model

Introduction before making changes to the physical system and

Offline Engineering is an important element for the be assured the changes will perform up to the ex-
development, operation, and maintenance of an au- pectation of the user and improve the performance
tomation system. By allowing the user to be able to of the system.
understand the operation of the automation system This chapter describes the configuration workflow
before deploying the system in physical hardware, that consumes the AC description artifacts in the Of-
the user will know that the system will perform the fline Engineering phase.
control function reliably and correctly once the phys- The following diagram is an overview of the workflow
ical system is in place. The user will be able to simu- steps for Offline Engineering descriptor(s) usage.
late changes and updates to the automation system

Create Product Publish Product UAFX

Descriptor Descriptor Product component
Descriptor vendor
(PD)

Role
Change Control
Product Get Product Create
Selection Descriptor CTRL project Configura- engineer
tion (module)
Descriptor
(CD)
Apply Create CTRL Pub Create
constraints & create data sets CTRL database

Export Configuration
descriptor
Role PD
Change Control
Download to Finalize configura- Import configuration
CTRL tion with runtime descriptor into the engineer
information CTRL Engineering Tool (plant)
CD

Role
Change
Online Online
configuration Engineering
changes

CTRL: Controller e.g. PLC, DCS

Figure 12: Overview of the workflow steps for offline engineering descriptor(s) usage
 19

Descriptor Definition The documents of an AC Descriptor can be catego-

Generally, the Descriptor of an AC is a set of docu- rized as information model and attachment docu-
ments containing an OPC UA information model and ments. Information model documents define the In-
potentially other useful information for configuration formation Model of the AC, while the attachment
purposes. The information can be for one AC or a documents provide supplemental (and optional ven-
group of ACs (like a machine, machine module or dor specific) material for the engineering and deploy-
skid). The AC Descriptor is delivered in a packaged ment process.
container format (zip file package) supporting the
provisioning and sharing of information in offline en-
gineering. One or more digital signatures in the De-
scriptor provide integrity for the content.

Descriptor

Root Part_N Attachments (folder)

Document
- references the top
level parts Attachments Part_N
Information Model
of Automation
Component(s)

jpg

Part_2
Attachments Part_2

Information Model
of Automation
Component(s)

DWG PDF

Signatures Part_1

Attachments Part_1
- Signature Part_1
- Signature Part_2 Information Model
... of Automation
Component(s)
- Signature Part_N
- Overall Signature
Firmware

Figure 13: Generic Descriptor Package or Generic Descriptor

20

As shown in Figure 13, the content is separated into Product Descriptor

parts. Each part may be produced by a different en- A Product Descriptor is a specific AC Descriptor
gineer and is the result of a specific engineering step. containing product data of the AC (see Figure 14).
The part structure forms a hierarchy where an upper Usually, the Product Descriptor is provided by the
level (later) part depends on the lower level (earlier) AC vendor. Importing the Product Descriptor into an
parts and adds to or overwrites (if allowed) informa- engineering tool can be the first step in engineering
tion that was created in the previous part. of an AC. In most cases, the Product Descriptor is
The content of an information model Part consists of included in a later descriptor (e.g. Configuration De-
one or more AutomationML (AML) documents. AML scriptor, see Figure 15) as the first part.
is a vendor-neutral XML-based format for the stor- The Product Descriptor states the identification,
age and change of engineering information. structure, and capabilities of the AC assets. For a
Two examples of AC Descriptors are described next. field or I/O Device, the Descriptor may also contain
information about the Asset Component functional-
ity.

Descriptor

Root Product (Part_1) Attachments

Document - Automation Component
- references the top - Asset Structure
level parts

Signatures Attachments Part_1

- Signature AC_Vendor
- Overall Signature
Picture Drawing

Manual Firmware

Figure 14: The Product Descriptor

 21

Configuration Descriptor
The Configuration Descriptor shown in Figure 15 is a
descriptor with one product part (Part_1) and one or
more configuration parts (Part_2). The Configuration
Descriptor is created in the engineering process,
usually with the intention to share engineering infor-
mation of an AC with another engineering tool.
The configuration part of the Configuration Descrip-
tor defines the Functional Entities, the communica-
tion DataSets, the required Quality of Service (QoS)
and the data necessary for connection establish-
ment (like unicast or multicast addresses for OPC UA
PubSub). In addition, for a field or I/O device, the
configuration part may also contain parametrization
data.

Descriptor

Attachments

Root Configuration1 (Part_2) Attachments Part_2

document - Functional Entities
- DataSets for PubSub
- Connection Information
- Parametrization Machine
Manual

Signature Product (Part_1) Attachments Part_1

- Signature Engineer1 - Automation Component
- Signature AC_Vendor - Asset Structure
- Overall Signature
Picture Drawing

Manual Firmware

Figure 15: The Configuration Descriptor

22

Workflow examples
This section will show how the descriptors are used in ➞ LC CDP for C_1 to be imported into the engineer-
an offline engineering environment and how the de- ing tool of C_1
scriptors will represent one or more ACs. In the two ➞L  C CDP for C_2 to be imported into the engineer-
examples below, a Line Controller (LC) will set up and ing tool of C_2
provide the overall control to 3 subordinate controllers ➞L  C CDP for C_3 to be imported into the engineer-
(PLC/DCS) in an UAFX automation system. In the first ing tool of C_3
example, standard Ethernet communications without
TSN is used. The system in the second example sup- Each CDP contains the information necessary to
ports TSN communications. configure the communication relationships between
Below is the workflow for the use case including enu- LC and C_X (X=1, 2, 3) (see Figure 16). In addition to
meration for the workflow states (noted in square the configuration information the CDP contains an
brackets, e.g. [1]): index that helps to navigate through the stored infor-
mation and a digital signature from the author (in this
System with a Line Controller and case the development engineer of the system inte-
3 subordinate controllers without TSN grator).
In the offline engineering phase, the engineering tool When the CDP is imported [2] into the engineering
for the LC has been used to create [1] Configuration tool of one of the controllers, the control engineer
Descriptors or Configuration Descriptor Packages checks the validity of the signature and uses the
(CDP): CDP index to browse and find the publication infor-

CDP: Configuration Descriptor Package

1, 2, 3 1, 2, 3
1 2
LC_
Vendor CDP Vendor
Engineering Tool export export for import Engineering Tool
for Line Controller for Controller
Controller _3 _3

download download

3 3

Line PLC_LC
Controller PLC_LC
Controller
_3

1, 2, 3

C: Controller (e.g. PLC, DCS) LC: Line Controller

Figure 16: Example: A system with a Line Controller and 3 subordinate controllers without TSN
 23

mation. This enables the control engineer to set up Each CDP contains the information necessary to
the corresponding Subscription and Connection ob- configure the communication relationships between
jects in the controller. Once the control engineer has LC and C_X (X=1, 2, 3) (see Figure 17). In addition to
completed the C_X project and the hardware (PLC/ the configuration information, the CDP contains an
DCS) is connected, the configuration can be de- index that helps to navigate through the stored infor-
ployed [3] from the C_X engineering tool. mation and a digital signature from the author (in this
case the development engineer of the System Inte-
System with a Line Controller and grator).
3 subordinate controllers with TSN The CDP for each controller – in addition to the infor-
In the offline engineering phase, the engineering tool mation in the first example – includes the QoS capa-
for the LC has been used to create [1] Configuration bilities and requirements provided by the TSN mech-
Descriptors or Configuration Descriptor Packages anisms for each controller (C_1, C_2 and C_3). The
(CDP): QoS capability is part of the Product Descriptor of
the controller (contained also in the CDP), while the
➞ LC CDP for C_1 to be imported into the engineer- QoS requirements are part of the Configuration De-
ing tool of C_1 scriptor.
➞ LC CDP for C_2 to be imported into the engineer-
ing tool of C_2
➞ LC CDP for C_3 to be imported into the engineer-
ing tool of C_3

CDP: Configuration Descriptor Package

1, 2, 3 1, 2, 3
1 2
LC_
Vendor CDP Vendor
Engineering Tool export export for import Engineering Tool
for Line Controller for Controller
Controller _3 _3
QoS
caps&reqs 1, 2, 3

1 3 PLC_A
Line CDP
C_3 CDP
Control-
download ler download
CDP QoS QoS
6 5 caps&reqs caps&reqs
5 6

1, 2, 3
4
Line CDP with
LC QoS PLC_LC
Controller Offline CDP with PLC_LC
parame- CNC Controller Controller
ters _3 QoS _3
parame-
ters
1, 2, 3

C: Controller (e.g. PLC, DCS), caps&reqs: Capabilities & Requirements, LC: Line Controller

Figure 17: Example: A system with a line controller configuring 3 subordinate controllers
24

When the CDP is imported [2] into the engineering The output of the calculation is entered into QoS pa-
tool of one of the controllers, the control engineer rameters/TSN Stream Settings descriptors – one for
checks the validity of the signature and uses the each controller C_X. These descriptors are imported
CDP index to browse and find the publication infor- again [5] in the C_X and LC engineering tools.
mation. This enables the control engineer to set up Once the control engineers have completed the C_X
the corresponding Subscription and Connection ob- project and the hardware (PLC/DCS) is connected,
jects in the controller. the configuration can be deployed [6] from the C_X
The QoS capabilities and requirements of all control- engineering tool.
lers (LC, C_1, C_2 and C_3) are imported from the
CDPs into the offline Central Network Configuration
(CNC) [3] to calculate [4] the information needed for
the TSN configuration (e.g. QoS parameters/TSN
Stream Settings data).

Description for C_3 Engineer

(C_Standard
object representations)

FE LineInterface
CG Global
PP LineStatus

Vendor Specific Project File

(Objects are imported in a CG C_1 Interface
vendor specific manner)
PP C_3 CMD
LC
FE LineInterface Eng Tool
CG C_Status Example
CG Global System Integrator’s
Development PP C_X STS
PP LineStatus
Engineer

CG Global
PP LineStatus
Description for C_1 Engineer Description for C_2 Engineer
(C_Standard (C_Standard
object representations) object representations)
CG Global
PP LineStatus FE LineInterface FE LineInterface
CG Global CG Global
PP LineStatus PP LineStatus
CG Global
PP LineStatus
CG C_2 Interface CG C_1 Interface
PP C_1 CMD PP C_2 CMD

CG Global
PP LineStatus CG C_Status Example CG C_Status Example
PP C_X STS PP C_X STS

C: Controller (e.g. PLC, DCS)

Figure 18: Development Engineer of System Integrator setting up the Configuration Information
 25

Safety Communication

The specification OPC UA Safety (OPC 10000-15 - network layers. In case an error is detected, this in-
Part 15: Safety) describes the services and protocols formation is shared with the safety layer which can
for the exchange of safety-relevant data using OPC then act appropriately, e.g. by switching to a safe
UA mechanisms. It extends OPC UA to fulfill the re- state. OPC UA Safety is application-independent
quirements of functional safety as defined in the IEC and does not pose requirements on the structure
61508 and IEC 61784-3 series of standards. and length of the application data.
Implementing this part allows for detecting all types
of communication errors encountered in the lower

Automation Component A Automation Component B

UAFX connection 1

Safety OPC UA OPC UA Safety Safety

Provider Mapper Mapper Consumer Functional
Entity

Request SPDU
Response SPDU

Safety
Functional
Entity
Automation Component C

UAFX connection 2

Safety OPC UA OPC UA Safety Safety

Consumer Mapper Mapper Provider Functional
Entity

Request SPDU
Response SPDU

Figure 19: Safety connections between Automation Components

26

Safety for field-level communications The most basic type of safety communication is bi-
OPC UA Safety is using standard UAFX connections directional communication, where a safety applica-
and an additional safety transmission protocol on top tion on one AC (A) sends data to a safety application
of these connections. It is developed to extend the on another AC (B). The SafetyConsumer initiates the
standard data exchange between Functional Entities communication with the Request SPDU. The Safety-
via UAFX connections with safety data (see Figure Provider mirrors the received ID and counters, adds
19). the requested safety data and secures all data via a
This principle delimits the assessment effort to the checksum before responding with the Response
safe transmission functions, such that the underlying SPDU.
UAFX connections do not need any additional func- One AC can be SafetyConsumer and SafetyProvider
tional safety assessment. at the same time. The connection between Safety-
Safety Functional Entities may include standard and Provider and SafetyConsumer can be established
safe input and output variables. The safety applica- and terminated during runtime, allowing different
tion inside the functional entity has to be developed consumers to connect to the same SafetyProvider at
in a safe workflow as well. different times.
The Safety Application is connected directly with the
SafetyProvider / SafetyConsumer, which exchange
data by means of the safety protocol. The OPC UA
Mapper is used to interface the safety layer and the
underlying communication and supports the channel
between SafetyProvider and SafetyConsumer.
 27

SafetyProvider State Diagram

The SafetyProvider has a very simple state machine
to implement. It is simply waiting for a request and if
the request is received, the safety telegram is sent
out. All safety checks will be done on the SafetyCon-
sumer side.

SafetyConsumer State Diagram

The SafetyConsumer is initiating the safe data ex-
change, waits for the response, and checks for po-
tential communication errors (integrity, timeliness,
authenticity, according to IEC61784-3). Thereafter
the SafeData is provided to the Safety Application
inside the AC. If a communication error occurs, fail-
safe substitute values will be provided to the Safety
Application instead, and an error will be indicated.

Automation Component (AC) A Automation Component (AC) B

Safety Safety OPC UA Connection OPC UA Safety Safety
Application Provider Mapper Mapper Consumer Application

Wait for
Request

Initialize

Prepare
SPDU

Time-
out1 
Wait for
Wait for SPDU
Request t SPDU
Reques

Proceed
Safety Data Request
Respon
To avoid running into safety
1
se SPD
U
timeout, SPDUs may also
Error
be protected by end-to-end
Check
latency guarantee.
Provide
S-Data
Safety Data

Figure 20: SafetyProvider and Consumer State Machines

28

Security

Security for UAFX connections ure 21). In this phase the mutual authentication and
Every UAFX connection is authenticated and option- the symmetric key exchange for the connection es-
ally encrypted by standard OPC UA security mecha- tablishment is done. Thereafter the Connection Man-
nisms specified for the Client/Server and PubSub ager (CM) maintains the connection via this secure
communication. The connection establishment is session up to the operational state of the connec-
entered after a OPC UA Secure Session establish- tion.
ment is completed with the use of asymmetric cryp-
tography with certificates and private keys (see Fig-

Client‘s Identity Client Server Server’s Identity

A
RC ( I
)R RC
Root Root
Certificate Protected by Certificate
Verify asymmetric
IC server‘s cryptography IC
Issuer identity A Issuer
Certificate ( I
) R Certificate
A Verify
AC server‘s AC
identity
Client‘s Client‘s A Server’s Server’s
Private Key Application Mutual Application Private Key
Certificate authentication Certificate
Key exchange
Client‘s Trust List Symmetric protocol Symmetric Server Trust List
keymaterial keymaterial
RS for Client/Server for Client/Server RC
Agree on credentials
for pub/sub
IS credentials for credentials for IC
PubSub PubSub
config & Further config &
UAFX communication

Protected by
asymmetric
cryptography

Figure 21: Mutual authentication plus obtaining credentials for PubSub

 29

Transport

Communications Profiles Facet and the UDP UADP Transport Facet. Any two
The current system architecture of a field level com- Profile A components installed in an IP network are
munications device allows for two communications interoperable, provided IP routes can be established.
profiles to be used with PubSub communications, ACs implementing Profile A may optionally imple-
constructed from at least four communications fac- ment the TSN Network Access facet in order to en-
ets (see Figure 22). able operation in a TSN Domain (see Page 35 et
All OPC UA ACs implemented using the Field Level seq.).
Communications will be capable of supporting one Profile A and Profile B connections are not interoper-
or more of the communication profiles and any or all able due to incompatible UADP Transport Facets
of its optional facets. Each profile can be used on a and so an AC must implement both to support in-
per-connection basis. Thus, if a controller conforms teroperability in all cases.
to multiple profiles, a control system engineer can
make the optimum selection for each connection. ➞ Profile B
Profile B is optimized for the layer 2 networks typi-
➞ Profile A cally seen within a single skid, cell or machine; con-
Profile A is optimized for layer 3 networks typically nections using the Profile B deliver the most efficient
deployed across an entire plant made of many ma- network bandwidth usage and performance but
chines, skids, and cells. Connections using Profile A cannot operate through a layer 3 switch or router.
deliver the most flexible network architecture but
consume more network bandwidth and processing
resources than those using Profile B. Profile A re-
quires the use of both the Direct Network Access

Profile A Profile B

UDP Ethernet
UADP UADP
Transport Transport
Facet Facet

Direct TSN Direct TSN

Network Network Network Network
Access Facet Access Facet Access Facet Access Facet Required
If an AC supports the TSN
1

bridge facet and is Optional

implemented with an TSN Bridge TSN Bridge
Facet1 Facet1
embedded Ethernet bridge,
Dependent
then it shall implement the
TSN Bridge Facet.
Figure 22: Structure of communications profiles
30

Profile B requires support of the TSN Network Ac- ➞ TSN Network Access Facet
cess Facet, the Direct Network Access Facet, and The TSN Network Access Facet is a superset of the
the Ethernet UADP Transport Facet. Any two Profile Direct Network Access Facet and uses TSN Ether-
B components installed in the same TSN Domain are net point-to-point or multicast techniques using TSN
interoperable. streams. Any two end stations using this facet with
In order to support operation in non-TSN enabled TSN bridges along their path can guarantee zero
Ethernet networks, a Profile B connection also sup- congestion packet loss and bounded network la-
ports the Direct Network Access Facet. tency and jitter. Even in heavily loaded TSN networks,
high priority streams suffer no effects of this loading.
Transport and Network Access Facets
➞ Transport Facets ➞ TSN Bridge Facet
Ethernet UADP and UDP UADP transport facets are Network interfaces implementing a TSN bridge are
defined in the OPC UA Specifications Part 14 Pub- characterized by the TSN Bridge Facet. The Field
Sub (OPC 10000-14) and Part 7 Profiles (OPC Level Communications Initiative is committed to sup-
10000-7), and are used as-is. porting the IEC/IEEE 60802 TSN Profile for Industrial
Automation. It is expected that all Industrial Ethernet
➞ Direct Network Access Facet variants and IT devices operating in an industrial net-
Communications using non-TSN Ethernet point-to- work using TSN will align with this specification, al-
point or multicast techniques, using the PCP or lowing them to fairly share network resources.
DSCP prioritization mechanisms are defined in the TSN Domains require all bridges (either embedded in
Direct Network Access Facet. This means that a an AC or in an infrastructure switch) to comply with
connection using this facet is infrastructure agnostic, IEC/IEEE 60802. If an AC implements the TSN Net-
supporting managed and unmanaged switches in all work Asset Facet and it implements an embedded
their varieties including TSN switches. In heavily switch, then it must implement the TSN Bridge Facet
loaded networks, switch buffers may be filled and and that switch must be an IEC/IEEE 60802-compli-
packets dropped, or latency and jitter may be creat- ant bridge. The mechanisms to connect multiple
ed resulting in packets being delivered too late to be TSN Domains in a single network and to extend TSN
used by the control application. Domains through network routers have yet to be
standardized.

1 2 3 4 5 6 Router 7 8

Profile A Profile B Bridge TSN bridge

Figure 23: Topology to illustrate interoperability in a mixed Profile A/Profile B scenario

 31

Interoperability Matrix full profile, that may impact its ability to meet applica-
Figure 23 shows a potential configuration of UAFX tion requirements. For instance, if devices 2 and 6
ACs that illustrates all possible network profile in- are motion devices, interoperability does not imply
teroperability use cases (allowing for both required that the system will achieve the update rates, latency
and optional facet implementations). and jitter required to successfully control a specific
Table 1 shows which of the ACs are interoperable, application.
and indicates likely constraints of that interoperabili- If devices 1 and 7 have implemented support for
ty. both, Profile A and Profile B, device 1 would be in-
Interoperability only applies to the ability for two teroperable with all devices (see Figure 24) and
components to exchange process data. There are therefore its row would be as shown in Table 2.
other attributes, typically associated with a device’s

Device 1 Device 2 Device 3 Device 4 Device 5 Device 6 Device 7 Device 8

1
Different communication Device 1 Yes No 1
Yes 2
No1
Yes 3
No 4
No1

profiles Device 2 No1 Yes2 No1 Yes3 No4 No1

2
All devices between devices
Device 3 No1 Yes No1 No1 Yes5
implement an embedded
Device 4 No1 Yes3 No4 No1
IEC/IEEE 60802 compliant
bridge Device 5 No1 No1 Yes5
3
Does not use TSN QoS Device 6 No4 No1
4
Layer 2 communications
Device 7 No1
cannot traverse a router
5
UDP communications are Table 1: Interoperability matrix (Device 1 supporting Profile B)
routable

Device 1 Device 2 Device 3 Device 4 Device 5 Device 6 Device 7 Device 8

Device 1 Yes Yes Yes Yes Yes 3

Yes Yes

Table 2: Interoperability matrix (Devices 1 and 7 supporting both, Profile A and Profile B)

1 2 3 4 5 6 Router 7 8

Profile A Profile B Profile A + B Bridge TSN bridge

Figure 24: Topology to illustrate interoperability in a mixed Profile A/Profile B scenario

32

Ethernet – Advanced Physical Layer

The OPC UA framework is transport-agnostic and Ethernet-APL defines two general types of seg-
therefore can be used with different underlying pro- ments:
tocols (e.g. TCP, UDP, MQTT, ...) and physical lay-
ers. To bring OPC UA down to the field level in pro- ➞ The “Trunk” provides high power and signal lev-
cess industry applications, OPC UA is combined els for long cable lengths of up to 1000 m.
with the Ethernet Advanced Physical Layer (APL) ➞ The “Spur” carries lower power with optional in-
which will be addressed in a later specification ver- trinsic safety for lengths of up to 200 m (2-WISE).
sion in the context of the controller-to-device use
case. 2-WISE stands for 2-Wire Intrinsically Safe Ether-
net. This IEC technical specification, IEC TS 60079-
Ethernet – Advanced Physical Layer 1 47 (2-WISE), defines intrinsic safety protection for
Ethernet-APL is an enhanced physical layer for sin- all hazardous Zones and Divisions. For users, this
gle-pair Ethernet (SPE) based on 10BASE-T1L as includes simple steps for verification of intrinsic
shown in Figure 25. It communicates via a cable safety without calculations.
length of up to 1000 m at 10 MBit/s, full-duplex. It Ethernet-APL combines the best attributes of Eth-
is the logical extension for Ethernet and provides ernet communication with two-wire installation
the attributes required for reliable operation in the techniques. This makes Ethernet-APL easy to de-
field of a process plant. Ethernet-APL is a physical ploy as a standard for field applications, from pro-
layer that will be able to support OPC UA or any cess plants with hazardous areas up to Zone 0 / Di-
other higher-level protocol. vision 1 to hybrid plants, employing technologies
Ethernet-APL is designed to support various instal- from factory automation and process automation.
lation topologies, with optional redundancy or resil- Consequently, the use of Ethernet-APL as a physi-
iency concepts and trunk-and-spur. Ethernet-APL cal layer for OPC UA field devices is a key driver for
explicitly specifies point-to-point connections only successfully bringing OPC UA down to the field
with each connection between communications level in process automation applications.
partners constituting a “segment”. Thus, Ethernet-
APL switches isolate communications between
segments. This eliminates disturbances such as
cross talk and natively protects communications
from device faults on a different segment.
 33

Engineering Asset Management Controller

Cloud

Auxilliary APL Other

Power Power-
Switch Applica-
tions

APL APL APL

Field Field Field
Switch Switch Switch

Field Field Field Field Field Field Field

device device device device device device device

Figure 25: Example topology for long cable reach Facility Ethernet

Ethernet-APL with
Increased Safety

Ethernet-APL with
Intrinsic Safety

1
Extract from “ethernet-apl advanced physical layer. Ethernet to the field”
https://opcfoundation.org/wp-content/uploads/2020/06/Ethernet-APL_Ethernet-To-The-Field_EN.pdf
34

Real-Time Communication Model

Quality of Service (QoS) concept TSN provides standardized mechanisms to deliver

QoS refers to network control mechanisms that can guaranteed service by reserving specific resources
provide various priorities to different devices or data from the network for specific types of traffic. Such
flows, or guarantee a certain level of performance to network guarantees must be mapped to the network
a data flow in accordance with requests from the ap- application or middleware such as OPC UA PubSub.
plication program. QoS guarantees are important if Application QoS requirements of an OPC UA appli-
the network performance is critical, especially for re- cation should be configurable with no or only little
al-time control applications. dependencies to the underlying network technology.
Prior to the arrival of TSN, the most common ap- Hiding network details from the application makes it
proach to delivering QoS in industrial automation easier for the application builder to migrate OPC UA
networks was by providing differentiated services to applications from one network technology to another
different types of traffic. In this approach, some types or even to interconnect OPC UA applications over
of traffic are treated better than others by classifying different network technologies.
the traffic and using tools such as priority queuing,
enabling faster handling, higher average bandwidth, TSN QoS mechanisms
and lower average loss rate for the chosen types. The IEC/IEEE 60802 TSN Profile for Industrial Auto-
However, this only provides a statistical preference, mation defines a selection of QoS mechanisms
not a hard and fast guarantee. Different types of in- specified by the IEEE 802.1 TSN Task Group for use
dustrial Ethernet traffic (such as motion, I/O, and in converged industrial automation networks.
HMI) have different requirements for latency, packet Converged networks promise to enable operational
loss, and jitter. The service policy should differentiate technology (OT) which includes traditional field buses
services for these types of flows. such as PROFINET or EtherNet/IP, and traffic to op-
The Field Level Communications Initiative defines erate the plant e.g. HMI/SCADA/MES communica-
provisions for identifying important OPC UA traffic tion to PLCs, and information technology (IT) appli-
at the field level with both Layer 3 DSCP (Differenti- cations to share the same physical network
ated Services Code Point, defined in IETF RFC 2474, infrastructure without hampering operation of the
etc.) and Layer 2 CoS (Class of Service, defined in other. For many industrial control applications, this
IEEE 802.1Q) tags for use in non-TSN managed net- implies that certain bandwidth, latency, and deadline
works. requirements must be met, especially in situations
where there is contention for network resources.
 35

Types of UAFX traffic and their A system-wide implementation of these traffic types
QoS requirements allows for convergence of factory automation, pro-
To allow for the coexistence of different applications cess control, IT traffic and best-effort traffic on the
on the same network, the infrastructure components same network.
have to provide the means to transport different
types of traffic with appropriate QoS. The traffic TSN Domains and examples for
types defined by the Field Level Communications communication relations
Initiative allow for convergence of different types of Today, many network architectures for industrial au-
OT traffic (e.g. process control, factory automation, tomation systems follow a certain physical and logi-
and fast motion and I/O control) and IT traffic using cal separation into domains or zones. This separa-
the same infrastructure. tion is often the result of organizational or technical
The following traffic types are defined for UAFX requirements, e.g., interconnection of individual
systems: components or entire machines from different ven-
dors, each with their own validated communication
➞ Network Control network and configuration, or the implementation of
➞ Cyclic Control zones for security best practice, or to support net-
➞ Event-based Control work redundancy and to further enhance network
➞ Configuration and Diagnostics QoS guarantees. These requirements also may ne-
➞ User-defined and cessitate a logical separation when using TSN.
➞ Best Effort

TSN Domain

E
Intra-domain Intra-domain
Communication stream

Bridge

Bridge

E E E E

E: end station

Figure 26: Intra-domain communication

36

Moreover, separation into different TSN Domains is Figure 27 shows such inter-domain communication
intended to allow for the centralized and distributed for a C2C scenario traversing TSN Domains 1, 2,
TSN stream reservation approaches to operate side- and 3.
by-side. As an alternative for inter-domain stream reservations
TSN intra-domain and inter-domain communication and as a state-of-the-art approach to interconnecting
are distinguished. The selected stream reservation different domains, e.g., representing machines in to-
mechanism enables an industrial control application day’s systems, the exchange of process data be-
to reserve network resources for the selected TSN tween two domains (e.g., Domain 1 and Domain 2 in
QoS mechanisms within the given TSN Domain. This Figure 28) may also logically be decoupled from on-
allows leveraging TSN-provided bandwidth and tim- the-wire communication and corresponding TSN
ing guarantees in converged network scenarios, as stream reservation via application-level gateways.
shown in Figure 26. Intra-domain communication Table 3 lists examples of communication relationships
can be utilized to realize C2C, C2D, and D2D com- utilizing either intra- or inter-domain communication.
munication relations. Inter-domain communications with TSN represent
Inter-domain communication occurs in communica- future work in IEC, IEEE, and IETF and so will not be
tions scenarios for data exchanges of industrial con- addressed in early releases of OPC UA FX specifica-
trol applications across (multiple) domains. It can be tions. Where inter-domain communications are re-
utilized to realize C2C, C2D, and D2D communica- quired by an application, Profile A will ensure interop-
tion relations. erable communications between ACs.

TSN Domain 3

Bridge Bridge

TSN Domain 1 TSN Domain 2

E E

Bridge Bridge

Bridge Bridge

E E E E E E E E

E: end station Inter-domain Communication

Figure 27: Inter-domain communication

 37

Network Management
UAFX Network Management will be based on open will be utilized. The actual configuration parameters
standards. For distribution of a successful network will be modelled in IEEE-conformant data models.
configuration standardized management protocols

TSN Domain 3 Intra-domain stream

Bridge Bridge

E E

Gateway/ Gateway/
Router Router

TSN Domain 1 TSN Domain 2

E E
E

Intra-domain Intra-domain
stream stream
Bridge Bridge

Bridge Bridge

E E E E E E E E

E: end station Inter-domain Communication

Figure 28: Connection of Domains using application level gateways or DetNet routers

Communication relation Description / Example

C2D Intra-domain communication This is probably the most common relationship, when a controller communicates
with its peripheral (I/Os, drives, valves, …)
C2C Intra-domain communication Communication between multiple controllers in the same TSN Domain

D2D Intra-domain communication To improve reaction times the devices (I/Os, drives, …) sometimes need to estab-
lish direct communication
C2D Inter-domain communication controller synchronizes on encoder signal from a different TSN Domain

C2C Inter-domain communication Interconnection of machines/skids without dedicated gateways (without controller)

D2D Inter-domain communication synchronization between motions drives in different TSN Domains

Table 3: Examples of communication relationships

38

Summary and Outlook

This technical paper described how the Field Level In parallel to the creation of specifications, open
Communications Initiative extends the OPC UA source stack software and code samples are being
framework to facilitate cross-vendor interoperability generated so that an easy adoption of OPC UA for
between controllers by enabling the exchange of field level communications is facilitated. Furthermore,
data relevant for different use cases including the ex- test specifications and test tools are being devel-
change of real-time and safety-relevant data in a se- oped to provide high-grade cross-vendor interoper-
cure way. ability between Automation Components.
After the first OPC UA FX release with the focus on With the extensions specified by the Field Level
the controller-to-controller use case, the specifica- Communications Initiative, OPC UA in combination
tions will be extended to also support controller-to- with APL, TSN, and 5G offers a complete, open,
device (C2D) and device-to-device (D2D) use cases standardized, and interoperable solution that fulfils
including additional features and device-specific industrial communication requirements and at the
models, e.g. for motion, instrument, I/O, and safety same time provides semantic interoperability from
devices. field to cloud (see Figure 29).

External World

Management Level L4

Planning Level L3
Source: VDI (2013), MDPI (2019)

Supervisory Level L2

Control Level L1

Field Level L0
Smart Automation Device

Network segments IT-related

Figure 29: Semantic interoperability from field to cloud Function OT-related
 39

Acronyms

AC Automation Component OPC Open Platform Communication

APL Advanced Physical Layer OPC UA OPC Unified Architecture
C2C Controller-to-Controller OPCF OPC Foundation
C2D Controller-to-Device OT Operational Technology
CD Configuration Descriptor PAC Programmable Automation Control-
CM Connection Manager ler
CNC Central Network Configuration PD Product Descriptor
CR Communication Relationship PCP Priority Code Point
CUC Centralized User Configuration PLC Programmable Logic Controller
D2D Device-to-Device QoS Quality of Service
DCS Distributed Control System SCADA Supervisory Control and Data
DSCP Differentiated Services Code Point Acquisition
ERP Enterprise Resource Planning SPE Single-Pair Ethernet
FE Functional Entity TSN Time-sensitive Networking
IEC International Electrotechnical UADP Unified Architecture Datagram
Commission Packet
IEEE Institute of Electrical and UAFX Unified Architecture for
Electronics Engineers Field eXchange
IETF Internet Engineering Task Force UDP User Datagram Protocol
IIoT Industrial Internet of Things
IoT Internet of Things
IT Information Technology
L2 Layer 2
L3 Layer 3
MES Manufacturing Execution System
OE Offline Engineering
OPC FOUNDATION HEADQUARTERS
OPC Foundation
16101 N. 82nd Street, Suite 3B
Scottsdale, AZ 85260-1868 USA
Phone: 480 483-6644
[email protected]

OPC FOUNDATION EUROPE

[email protected]

OPC FOUNDATION CHINA

[email protected]

OPC FOUNDATION JAPAN

[email protected]

OPC FOUNDATION KOREA

[email protected]

OPC FOUNDATION ASEAN

[email protected]

OPC FOUNDATION INDIA

[email protected]

V2 www.opcfoundation.org