See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/283882805

OPC UA server aggregation - The foundation for an internet of portals

Article · January 2015

DOI: 10.1109/ETFA.2014.7005354

CITATIONS READS

15 2,822

5 authors, including:

Daniel Grossmann Suprateek Banerjee

Technische Hochschule Ingolstadt Technische Hochschule Ingolstadt
18 PUBLICATIONS   27 CITATIONS    10 PUBLICATIONS   44 CITATIONS   

SEE PROFILE SEE PROFILE

Dirk Schulz Roland Braun

Justus-Liebig-Universität Gießen ABB
17 PUBLICATIONS   47 CITATIONS    8 PUBLICATIONS   18 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Aggregation of Information Models View project

Electrical Integration of Drives View project

All content following this page was uploaded by Suprateek Banerjee on 21 January 2017.

The user has requested enhancement of the downloaded file.

 OPC UA Server Aggregation – The Foundation for an Internet of Portals

Prof. Dr.-Ing Daniel Großmann, Prof. Dr.-Ing. Dr. Dirk Schulz, Dipl.-Inform. (FH) Roland
Markus Bregulla, M.Sc. Suprateek Banerjee Braun
TH Ingolstadt ABB Corporate Research Center Germany
Esplanade 10 Wallstadter Str. 59
D-85049 Ingolstadt 68526 Ladenburg
Daniel.grossmann@thi.de Dirk.schulz@de.abb.com

Abstract technologies follow the same approach (e.g. Field

Device Tool (FDT), Analyzer Device Integration (ADI)).
Devices in industrial automation systems are All these approaches define a central integration
becoming more and more intelligent. Consequently, platform (Figure 1).
functions such as server services are migrating into the
device level. To solve the resulting connection mesh, this Consumer Consumer
paper entails the concept of aggregation of servers (Client) (Client)
connected to devices in an industrial automation
Consumer Consumer Consumer
scenario. The first section discusses the basic (Client) (Client) (Client)
requirements for aggregation and proposes an
architecture for server aggregation as a solution. The
following section describes the building blocks of the Central Integration
architecture. Finally, the paper presents a prototype Platform (Server)
based on this architecture model as a proof of concept
implementation of the concept introduced in this paper.
The last section discusses the results of the prototyping
phase including the possible improvements of the same. Dev. Dev. Dev. GW Subsyst.

Dev. Dev. Dev. Dev. Dev. Dev.

1. Introduction
In today’s industrial automation systems, vertical
integration plays an important role since information
needs to be exchanged throughout the various layers of
the automation pyramid. Device integration technologies
for example, make the information of field devices
available to higher levels of an automation system.
1.1. State of the art
Current state of the art integration technologies such
as Field Device Integration (FDI) define client server
architectures where a server centrally represents the data
and functions of the devices of the automation system
[1]. FDI uses OPC Unified Architecture (UA) as
information modeling and middleware technology [2].
The FDI server represents the topology of the field
networks and devices. It is connected to the devices via
(industrial) communication protocols (e.g. Profibus,
Profinet, HART and Foundation Fieldbus). Once the
server receives a request from a client, it gathers the data
necessary to serve the request from the device. After
applying the appropriate computations, the server passes
the response back to the requestor. Other integration
Figure 1. Centralized integration platform.
1.2. Integration platforms
Integration platforms represent one component or a
set of components of an automation system in the form
of an information model. An information model typically
consists of objects that have relations to other objects
(structure information). Objects are instances of a
specific type. This type information is also available
within the information model. Objects carry data that can
be read or written (instance data) and functions that can
be called (behavior).In conclusion, an information model
provides
• type information,
• structure information (objects and relations),
• instance data (data of objects) and
• behavior of objects
1.3. Trend towards distribution
Devices and subsystems are becoming more and more
powerful regarding CPU power, memory and
communication bandwidth. This trend towards increased
intelligence in devices enables devices to fulfil tasks on centralized integration platform. This reduces the above
their own that are currently provided externally in the mentioned complexity of connections (Figure 3). At the
centralized integration platform. As a result devices and same time, the aggregation component can act as a
subsystems will act as integration platforms on their own security supervisor that can manage the connections
in future, directly providing functionality and data. from a security perspective.
Already today, devices with embedded OPC UA server
functionality exist which also form the basis of ‘Internet Consumer Consumer
of Things’ [7]. One of the benefits of such a (Client) (Client)
development is that such devices and subsystems can be
Consumer Consumer Consumer
directly accessed already at a stage where the overall (Client) (Client) (Client)
automation system has not been engineered or
commissioned. The current trends of Cyber Physical
Systems and Industry 4.0 further drive the collaborative Aggregation Server
work of highly distributed system components. The
resulting situation (Figure 2) would be a system with
(fully) meshed connections between providers of
functions and data (servers) and consumers (clients).
Dev. Dev. Dev. GW Subsyst.

Consumer Consumer
(Client) (Client) Dev. Dev. Dev. Dev. Dev. Dev.

Consumer Consumer Consumer

(Client) (Client) (Client)
Figure 3. Aggregation server.

2. System architecture

This section describes the overall system architecture

from an aggregation standpoint (Figure 4) along with the
general aggregation requirements. The components
Dev. Dev. Dev. GW Subsyst. involved are described below.

Dev. Dev. Dev. Dev. Dev. Dev.

Figure 2. Resulting connection mesh.

1.4. The resulting connection mesh

While the trend towards devices and subsystems with
their own integration platforms has its advantages, there
are also drawbacks: During the lifecycle of the
automation system, different tools need to access the
devices and subsystems as clients (e.g. to configure
them). With a centralized integration platform, this
access is provided, managed and supervised centrally. In
a scenario where multiple decentralized integration
platforms exist, the connection of the clients need to be
set up manually multiple times. To make matters worse,
Figure 4. Overall aggregation architecture.
clients typically work on a set of devices, which means
that such clients would need to “know” multiple
decentralized integration platforms. In addition, each of 2.1. Aggregated server
these client server connections needs to be managed and Aggregated servers represent the entities of the
supervised from a security perspective. Strictly enforcing automation system. These are the underlying servers
security rules for each connection would cause an which may either represent a single component (e.g. a
enormous engineering effort. field device) or a subsystem that consists of a set of
As a result, an architecture is necessary in which an components, parts of the automation system or the entire
aggregation component provides the “illusion” of a automation system.
2.2. Aggregation server
The aggregation server is the core of the aggregation
architecture. It connects to underlying servers via OPC
UA services and aggregates their type, instance and
structure information. The aggregation server is
described in detail in section 3.
2.3. Aggregation configurator
The aggregation configurator is a tool that configures
the aggregation server. It creates information about the
aggregated servers that the aggregation server should
aggregate. The aggregation configurator can be used
during engineering or during commissioning/run time. If
used during engineering, the aggregation configurator
creates configuration information (section 2.4) that is
stored in a persistent fashion (e.g. file, database etc.). If
used during commissioning/run time, that means when
the aggregation server and the aggregated servers are
available and running, the aggregation configurator
directly accesses the aggregation server via a defined
OPC UA information model to configure the servers that
are to be aggregated.
2.4. Configuration
The configuration contains information about the
servers that need to be aggregated (e.g. urls etc.). The
aggregation server reads this information to know which
servers to aggregate.
2.5. Type mapping rules
The type mapping rules provide information that is
necessary to identify semantically identical types in
different underlying servers. Since such types may have
different NodeIds and different browse names (which are
used to uniquely identify a particular node in an address
space)[4][5], the aggregation server needs additional
information for identification (e.g. properties that need to
match). In case of FDI, a device type is identified via the
properties Manufacturer, Model and Device Revision
[6]. This means that in the prototype developed for this
paper, each of the type nodes were further browsed for
the above mentioned properties and the values of these
properties were compared to that of the already added
type nodes in the Type Manager (section 3.4). If the
values corresponding to all the properties do match, the
two types were considered to be identical.
2.6. Instance mapping rules
The instance mapping rules provide information
about the handling of objects/instances. Also information
(e.g. a list) about fixed objects is contained in the
instance mapping rules so that the aggregation server is
able to identify objects that are available multiple times
in different underlying servers and that need to be
merged into a single object in the aggregation server.
Such fixed objects typically have a definite NodeId,
defined as per the specification of the integration
technology (e.g. FDI) and also the OPC UA standard
itself. The instance mapping rules can either be
configured locally in the aggregation server or it can be
read dynamically from the aggregated server. This paper
proposes the necessary extensions to the aggregated
server’s information model (section 4.2).
3. Aggregation server architecture
3.1. Aggregation node manager
The aggregation node manager is the central singleton
that manages the nodes in the address space of the
aggregation server. A node manager can only cater to
requests targeted towards the nodes belonging to its own
namespaces. Therefore the aggregation node manager
updates its own namespaces to contain the new
namespaces present in the underlying server (after
connecting to it) in order to handle the incoming client
requests (read, write, subscribe etc.).The aggregation
node manager manages the flow of information to and
from the below mentioned components of the
aggregation server.
3.2. OPC UA client
The OPC UA client provides functionality to connect
to aggregated servers and to access nodes in the address
space of the aggregated server. The aggregation node
manager creates one OPC UA client per underlying
server and then browses each underlying server with the
help of the respective clients.
The node manager forwards all requests (read, write,
subscribe etc.) to and from the underlying node in the
aggregated server via the respective OPC UA client
connected to that particular server. The NodeIds that are
part of the request need to be resolved to the respective
NodeIds in the aggregated server(s).
3.3. Node factory
Depending upon the matching criteria (type/instance
matching rules), the node manager determines whether
or not each browsed node in the underlying server is to
be aggregated. A proxy node is created for each
aggregated node from the underlying server and
subsequent mapping information is maintained within
the aggregation node manager which maps each proxy
node to its original aggregated node in the underlying
server. The node factory creates these proxy nodes.
When a node with a fixed node id is being aggregated
for the first time, the node factory provides the same
unique identifier to the proxy node as that mentioned in
the fixed node id list (section 2.6). The corresponding
references between the proxy nodes are also maintained
just as they are maintained in the underlying servers, so
that the structure information of the underlying address
space is preserved. In case of a duplicate node
(overlapping structures or identical type nodes) only the
mapping information is updated and no new proxy node
is created.
3.4. Type manager
The Node manager contains the type manager which
caters to the consolidation of type nodes from the
underlying aggregating server in accordance with the
type matching rules.
3.5. OPC UA server
The OPC UA server provides the interface of the
aggregation server to external OPC UA clients. Besides
providing access to aggregated servers via the
aggregated proxy nodes, the OPC UA server provides
the aggregation specific information (section 4.1). This
contains functions to manage aggregation as well as
information about servers that are already aggregated
and servers that are available for aggregation
dynamically via the discovery manager.
3.6. Discovery manager
The Discovery Manager scans for available OPC UA
servers that can be aggregated. The available OPC UA
servers are represented in the aggregation server’s
specific information model (section 4.1). OPC UA
clients can advise the aggregation server to aggregate
such OPC UA servers during runtime. This aggregation
is also done with the help of the aggregation node
manager.
3.7. Security manager
The security manager manages additional access
control for specific underlying servers or nodes present
in specific underlying servers. In a scenario where the
aggregation server is being used to aggregate the
information models of different integration platforms, it
is necessary to limit access to certain client applications.
These security restrictions and access control
information is handled by the security manager and only
those requests which remain impervious to the security
restrictions are allowed to pass through to the underlying
servers.
4. Information model extensions
This paper defines two extensions to information
models. Section 4.1 extends the information model of the
aggregation server. It mainly provides means to manage
aggregation. Section 4.2 defines an optional extension to
the information model of servers that are aggregated.
The extensions mainly aim at providing type and
instance mapping rules directly from within the
aggregated server for fully automated aggregation. If the
optional extensions are not implemented, type and
instance mapping may need to be implemented using the
aggregation configurator (section 4.3).
4.1. Aggregation server
The information model definitions are as follows:
The OpcUaServerType represents an OPC UA server.
Therefore it references a variable ServerUrl that holds
the url of this OPC UA server (fig.Figure 5). The
AggregatedServerType inherits from the
OpcUaServerType and references a ServerType object.
The ServerType is defined by the OPC UA Specification
and contains detailed information of the server including
diagnostic status. The AvailableServerSetType contains
references to OpcUaServers that are available for
aggregation. This list may either be populated via
engineered configuration information or via OPC UA
discovery. The AggregatedServerSetType contains
references to AggregatedServers. These Aggregated-
Servers are represented including the aggregated Server
object (ServerType). This allows clients to also monitor
the status of aggregated servers within the aggregated
information model. The AggregatedServerSetType
provides a Method AggregateServer. This method takes
the NodeId of an OpcUaServer object in the
AvailableServerSet. The aggregation server then
aggregates this server so that it also is listed in the
AggregatedServerSet and disappears from the
AvailableServerSet. The ResidesIn reference type
inherits from the NonHierarchicalReferenceType. It
describes the original location of the object in an
aggregated server.
Figure 5. Aggregation Server Information
Model.
4.2. Aggregated server
The information model definitions are as follows:
The TypeMappingRuleSetType references Type-
MappingRules (Figure 6). The TypeMappingRuleType
represents the rules to map types. These rules may come
from a standard (e.g. rules to map DeviceTypes in FDI).
The InstanceMappingRuleSetType references Instance-
MappingRules. The InstanceMappingRuleType
represents the rules to map instances. These rules may
come from a standard (e.g. rules to map the
DeviceTopology node in FDI). The
TypeManagementServiceType provides standardized
services to manage the types of an OPC UA Server.
Therefore it provides two methods.
ExportTypeDefinition and ImportTypeDefinition. The
ExportTypeDefinition method serializes all necessary
information to establish this type in another server. The
method takes the NodeId of a Type node and then
creates the type information for export. In case of FDI
this is the FDI Package. The return value of this service
is a NodeId that can then be used to read the exported
type information. The ImportTypeDefinition method
takes serialized type information and establishes the
corresponding type in the type system of the OPC UA
server. In case of FDI, this means that a FDI Package
would be provided via this method thus creating the
corresponding DeviceType. The proposal of the creation
of new type definitions pertains only to the subsystems
that represent a range of types of lower-level devices
themselves, it is not of importance at the device level per
se. The Aggregation-SupportType references the
TypeMappingRuleSet, the InstanceMappingRuleSet and
the Type-ManagementServices.
Figure 6. Aggregated Server Information Model.
5. Prototype
A prototype was developed as a proof of concept
implementation of the proposed architecture. The
prototype is still work-in-progress and is in its
preliminary stage, however it does successfully
showcase the basic idea outlined in this paper. The
aggregation server prototype developed was used to
aggregate three FDI Servers along with sample OPC UA
servers provided in the OPC UA software development
kit (fig.Figure 7). After the aggregation, the resulting
address space structure of the aggregation server was
observed with the help of the UA Expert OPC UA
Client. The UA Expert client was used to test the
functionalities of the aggregation server. The original
underlying aggregated servers were also observed
alongside the aggregation servers to make sure that the
address spaces were merged appropriately. Read, write,
subscribe and unsubscribe requests were tested against
the aggregation server. Finally, an FDI client application
was connected to the aggregation server, to observe
whether the FDI client can work with the aggregated
information model of the three underlying FDI servers
without errors. Since the aggregation server provided the
perfect illusion of a central integration platform, the FDI
client was able to perform its tasks (e.g. read/write data,
subscribe, call methods). The prototype successfully
demonstrated the described features such as resolving
semantically identical types in different information
models or mapping of instances.
Figure 7. Aggregation Prototype.
5.1. Implementation
1) There are two ways of aggregating servers into
the aggregation server. The first method is to include the
server uris into a locally saved ServerUris.xml file.
When the aggregation server is first started, it always
reads this file to aggregate the servers, the Uris of which
have been listed in this file. This maps to the
configuration that is explained in section 2.4 above. The
second method is to aggregate a server with OPC UA
discovery. The aggregation server contains a node
Available Servers in its address space which contains
nodes corresponding to the discovered OPC UA servers
in the same system (by default). This Available Servers
node also contains a Discover Now method which when
called, prompts for an IP address or machine name as
argument. Upon providing a valid IP address or name
and the method called, the Available Servers node is
refreshed with new nodes corresponding to the OPC UA
servers running in the target machine with the provided
IP address. All of the discovered server nodes within the
Available Servers node contain a method node
Aggregate Server, which when called prompts a check
box with the name Remember Me. If this method is
called, the corresponding information model of the
underlying server will be aggregated into that of the
aggregation server. If the check box is checked the
server uri will be added to the locally saved
ServerUris.xml file if it is already not present in the
 same. The aggregation server need not be stopped in
order to aggregate servers using the discovery method.
That is, aggregation is possible dynamically.
2) Read: When the Aggregation Server receives a
read request for one of its nodes, the aggregation node
manager refers its mapping dictionaries and forwards the
read request to the actual node in the underlying server
(resolved with the help of the mapping dictionaries)via
the corresponding OPC UA client session object for that
aggregated server. The response thus obtained from the
aggregated server is forwarded to the external OPC UA
client which had made the initial read request.
3) Write: The procedure is similar to the read
request and in this case the original node in the
aggregated server is written to.
4) Subscribe/unsubscribe: This also follows a
similar methodology as above and the original node in
the underlying server is subscribed/unsubscribed to, via
the corresponding OPC UA client present within the
aggregation server. When the value of a monitored item
in the aggregated server changes, the OPC UA client in
the aggregated server is notified. Upon receiving the
notification the aggregation node manager updates the
value of the corresponding proxy node, with the help of
the bi-directional mapping dictionaries. This value
change in the proxy node of the aggregation server in
turn triggers a data change notification in the external
OPC UA client subscribed to this particular proxy node.
5) In case of the FDI servers, the type comparison
was done with respect to the value attributes
Manufacturer, DeviceRevision and Model of each of the
underlying type nodes (section 2.5). If this algorithm
returns true, this means that both are the essentially same
type and need not be integrated, and an entry is made in
the mapping dictionaries.
6) In order to test mapping of instances, an
instance mapping rule node was added to the aggregated
server. A NodeIdValues node contains the information
(identifiers and namespaces) about the nodes with fixed
NodeIds in a specific xml file format. The aggregation
node manager then refers to this information (by saving
it offline) each time it has to assign a new node id to a
new proxy node.
5.2. Results
The prototype of the aggregation server can aggregate
all types of OPC UA servers. It is not restricted to any
particular integration platform. It was successfully tested
with 3 different FDI Servers as well as OPC UA sample
servers. All servers were successfully integrated into a
single information model. Runtime dynamic aggregation
was also possible with the help of OPC UA discovery.
Read requests displayed the attribute values from the
underlying server. Write requests could write the values
to the node in the aggregated server. Subscribe and
unsubscribe requests were also handled appropriately
View publication stats
and live values of the aggregated server node could be
observed by subscribing to the proxy node in the
aggregating server. When the FDI Client was connected
to the aggregation server, three different information
models corresponding to the three underlying FDI
servers could be rendered and visualized in the client
without any changes necessary. The additional sample
servers that were also integrated along with the FDI
servers did not affect the functioning of the FDI client.
All of these tests were also made using UA Expert OPC
UA client providing similar results.
6. Outlook
Collaboration of distributed intelligent units is one of
the foundations of Industry 4.0 [7]. Meshed
communication, often referred to as Internet of Things, is
the result. While communication is vital for Industry 4.0
the authors are confident, that meshed communication
may not be necessary in all cases, apart from the high
complexity and security questions that come with
meshed communication. Therefore, the authors propose
an Internet of Platforms in which aggregation platforms
talk to each other. Each aggregation platform
encapsulates a set of devices, subsystems or entire
systems making the resulting connections easier to
oversee and to handle from a security point of view.
With features such as discovery and dynamic
aggregation, the ecosystem of connected aggregation
platforms can change over time, adopting new system
structures. The mentioned concept of aggregation of
OPC UA servers is a first step into this direction.
References
[1] IEC 62769-1 CDV: Field Device Integration (FDI),
Technical Specification - Part 1: Overview. IEC, 2013.
[2] IEC 62541-1: OPC UA Specification – Part 1: Concepts.
IEC, 2010.
[3] Imtiaz, J.; Jasperneite, J.: Scalability of OPC-UA down
to the chip level enables “Internet of Things”, 11th IEEE
International Conference on ”, Industrial Informatics
(INDIN), pp.500-505, July 2013. Bochum.
[4] IEC 62541-3: OPC UA Specification – Part 3: Address
Space Model. IEC, 2010.
[5] IEC 62541-5: OPC UA Specification – Part 5:
Information Model. IEC, 2011.
[6] IEC 62769-5 CDV: Field Device Integration (FDI),
Technical Specification - Part 5: FDI Information Model.
IEC, 2013.
[3] Promotorengruppe Kommunikation der Forschungsunion
Wirtschaft – Wissenschaft (Hrsg.): Umsetzungs-
empfehlungen für das Zukunftsprojekt Industrie 4.0.
April 2013