OPC UA Hardware Offloading Engine as dedicated
peripheral IP Core
Chris Paul Iatrou
Technical University of Dresden
Chair for Process Control Systems Engineering
Email: Chris_Paul.Iatrou@tu-dresden.de
Abstract—OPC UA is a promising candidate for achieving
a vertical semantic integration of field devices in the next
generation of industrial automation topologies. Microprocessing
platforms embedded in sensors and actor do however not provide
the memory and computing resources required to integrate
OPC UA communication stacks. To enable the usage of OPC UA
on limited platforms, this article introduces a dedicated, highly
scalable hardware server stack, synthesizable on 75.800 μm2
using 28 nm CMOS technology as well as FPGAs, that can
process OPC UA as a peripheral component.
I. I NTRODUCTION
OPC Unified Architecture (OPC UA ) is an industrial com-
munications protocol with object oriented information meta-
modeling capabilities. Aside from accessing data values, the
relationships between instances and types convey semantic
information pertaining to server and data. [1], [2] These
attributes make OPC UA a prime candidate as an information
carrier for IoT and next generation industrial communications.
[3] Due to the protocols object oriented design, it does
however not scale well to computing platforms with limited
memory and computing resources. This limitation particularly
impacts field devices such as sensors and actors, which are
vital information carriers in any automation process.[4] At-
tempts to implement software stacks on common and industrial
microcomputing platforms result either in OPC UA servers
with severely limited capabilities [5] or non-specification con-
formant behavior[6]. Even in these cases the implementation
of OPC UA servers still demands powerful System-on-a-Chip
based products with external memory components.[7]
To enable actors and sensors to become part of a dynamic,
heterogeneous networked ecosystem both in industrial and
commercial applications, the authors designed an OPC UA
server implemented as a hardware IP capable of offloading
OPC UA communications in an autonomous, on-chip periph-
eral component. The design enables highly parallel processing
of OPC UA communications independently of the chips ap-
plication bound main processor. This peripheral component
allows energy efficient, widely employed microcomputing
platforms to make use of OPC UA as an information carrier
without requiring significant redesign or changes to proven,
optimized or time critical software.
978-1-5090-2339-4/16/$31.00 
c 2016 European Union
Leon Urbas
Technical University of Dresden
Chair for Process Control Systems Engineering
Leon.Urbas@tu-dresden.de
II. A RCHITECTURAL OVERVIEW
The OPC UA hardware server can be divided into three
key components (fig. 1a): A hierarchic set of coders, a
coder interconnecting bus fabric and a data access component
handling information stored in the namespace. The hierarchic
structure is derived from the OPC UA-Binary protocol, divided
into the transport layer, a security- & sequencing layer and a
services layer. Transport layer coders exchange data streams
with OSI1-4 component. The design includes connection-
dedicated TCP/IP offloading engines, making package pro-
cessing deterministic without implying real-time capability on
the side of the underlying Ethernet fabric. Each coder is able
to process one specific OPC UA data stream format, e.g. that
of a read service request. The number and type of coders
present in each layer is variable at design time. Coders between
hierarchies are interconnected using a bidirectional, packet
based, connection oriented bus fabric. Additionally, coders of
the service layer are able to communicate with the namespace
engine, requesting information about attributes or relations of
nodes stored in the binary namespace image. The namespace
engine also provides for method call interrupts, value updating
and subscriptions.
A. Service Coder Units
The OPC UA-Binary encoding is a serialized representation
individual data fields. The encoding rules for 37 base types
are explicitly specified by OPC UA and more complex types
are derived by creating structures of said types. [8] As a rule,
when decoding a serialized, binary data stream the type of the
structure contained must be known before hand, as the data
stream does not provide stream information or synchroniza-
tion markers. Standard processing cores operating with fixed
word widths additionally require multiple instruction to align
operands for calculations or manipulation for reading these 8
bit data streams.[9]
This issue was addressed by creating highly specialized
coder units based on a newly developed OPC UA stream pro-
cessor core. The core natively parses all OPC UA base types as
part of its instruction set. It also provides hardware memory
management for a configurable amount of internal memory.
All registers of the core treat data as streams composed of
8bit words. The OPC UA stream processor core allows to
programatically define the processing of messages without the
 (a) Architectural design overview
Figure 1: Design overviews of the peripheral IP with exemplary coder distribution and a service processor
requirement to align, index or otherwise manage the transfer
and storage of base data types. Stream processors operate in
a request-response scheme, in which the core enters a low
power idle state until a message arrives. The data stream is
then parsed and responded to by to stream processor according
to its program, after which the processors returns into the idle
state. Each cycle clears the internal memory, registers, flags
and program counters.
Service coders (Fig. 1b) are composed of a stream processor
core, a bus terminal, a namespace engine linkup, a limited set
of peripherals persistent registers and a timer. Every OPC UA
service coder uses this same hardware arrangement and only
differs in the program used to process data streams. Each coder
also has a unique bus address and broadcast key set during
synthesis.
Large memory components are only required in coders that
assemble fragmented messages, which is only the case for the
TCP/IP Offloading Engine and the OPC UA-Sequencing layer
that assembles message chunks. The memories are constructed
as FIFO buffers and are made accessible to subsequent codes,
to which the contents are forwarded on demand as a data
stream. New data can easily be written back into the buffers
by subsequent coders, so that local memory is not required in
coders of the service layer.
Every service coder can process exactly one stream at
any time. Coupled with the forwardable memory architecture,
deterministic program execution by the stream processor cores
and the non-blocking packet switching bus fabric, this design
principle results in the worst case processing time for any
message being solely dependent on the length of the message
itself. This property enables fulfilling hard real-time require-
ments, as both the maximum message length and the clock
rate of the system are known at design time.
(b) Internal structure of a service coder
B. Coder interconnect fabric
Communication between coders is facilitated by a non
blocking, connection oriented network-on-chip bus fabric
(NoC). A terminal handles the access to this bus on the
coder side, making communications appear like FIFO con-
tents. Physical access to the bus is controlled by a round-
robin-scheduler, providing equally distributed bus access. This
allows for deterministic worst case behavior, which is essential
for guaranteeing hard real-time capabilities. The bus scheduler
can also function as router towards other schedulers. The
addressing scheme allows for 256 bus participants, which
can be located on a single bus or distributed over multiple
bridged buses. The MTU is 256 Bytes, transferred as 32 bit
words. The packet based transactions permit different coders to
process data in parallel, allowing for continuous operations and
minimizing hot-waiting of stream processors that are halted
due to the lack of data in their terminal.
A single coder in the hierarchy can only decode his re-
spective part of the datastream; i.e, the security coder is
able to sequence the chunks of a message and remove the
relevant headers, but he needs to forward the contained service
request to the appropriate service coder. The discovery of an
appropriate subsequent coder is handled by the bus system
using a key broadcast mechanism. The key corresponds to
the decoding requirements of the message, which for service
decoders is the service NodeId, while the transport coder uses
the SecureChannelId. Coders that can process the message au-
tomatically reply to the broadcast query and the first free coder
is chosen to process the message. Adding new services during
design time only entails connecting new service coders to the
bus system, automatically allowing its dynamic discovery at
runtime.
C. Binary namespace encoding purpose shared memory, accessible to all service coders, pro-
One of the key strengths of OPC UA is its information vides an inter-process communication mechanism. The shared
modeling capabilities. Type definitions, instances and methods memory is currently used to store and verify session IDs across
are abstracted as nodes in a graph and interconnected using all service coders.
typed references.[1] Runtime representation of this data re- The application processor has access to the namespace en-
quires large amount of memory. Data models in small devices gine using memory mapped interface registers. These registers
such as actors and sensors are largely static and composed of allow interacting with the OPC UA peripheral IP and enable
preinitialized objects and variables.[10] Only a small subset of the application to write to or read data from the namespace.
this information are changed at runtime. It was hence opted to For the application processor, updating OPC UA values is
store the information model on an static memory component reduced a periodic write operation to a special function register
(such as EEPROM or Flash) and mask any runtime changes in its address space.
to the data using a small associative cache. The default XML
OPC UA namespace representation proves too complex to
parse on-demand, while the OPC UA binary encoding imposes
severe limitation: The serial decoding requirement forces the
reading process to either parse the entire image up to the
information it wants to access, or index certain memory
locations.
As a solution, a specialized binary encoding for OPC UA
was developed that reduces persistent memory requirements
to 116 kB for namespace 0 1 . Next to reducing memory
requirements, the image format was designed to ease parsing
the contents of the linear 8 bit memory. Nodes are arranged
in ascending order of their numeric ID and CRC synchroniza-
tion markers in the stream permit locating nodes positions,
allowing for O(log(n)) search complexity[11] for arbitrary
nodes. Relative data offsets of node attributes (references, type
payload, compressed string data) are inserted to enable quick
navigation to the desired attributes. Search operations for refer- Figure 2: Internal architecture of the namespace engine.
ences are obsoleted by using a 24 bit direct addressing scheme,
effectively reducing search complexity for referenced nodes
to O(1). Frequently referenced nodes, such as referenceTypes, A bus system similar to the NoC is used to communicate
are addressed indirectly using 6 bit fields. The binary encoding with service coders. Only the round robin bus scheduler but not
is automatically generated by a python namespace compiler the overlying packet switching protocol is used. Service coders
using XML descriptions of the namespace. request access to the namespace engine using their instruction
set, thereby accessing the bus. The namespace engines bus
D. Namespace engine scheduler then allocates a fixed time slice for each coder
Service coders access the contents of the namespace by interaction. If the time slice elapses before the service coder
using an extension of their instruction set to interact with concludes its transactions, the state of the transaction is stored
the namespace engine, whose core component is an interface in a stack and later restored when the coder is re-granted access
for parsing the binary image. Its contents are assumed to be to the namespace engine, effectively preventing any coder from
static, variable contents being preallocated by the namespace blocking the namespace access.
compiler. On write operations, the information is stored in III. VALIDATION AND H ARDWARE C HARACTERISTICS
a separate memory, which masks the data stored at that
The design composed of a TCP/IP offloading engine, a
address of the static image. The data retrieval logic builds
transport coder, a security coder and service coders covering
on an address associative cache, thereby providing for a fixed
GetEndpoints, Read and Open-/CloseSecureSession services
amount of maskable memory. A feistel network based hash
underwent successful synthesis studies for FPGAs and the
table provides fast identification of masked memory areas.
GlobalFoundries 28nm SLP CMOS technology. The design,
A prefetch cache is used to accelerate read access to the
excluding the namespace engine, was extensively simulated at
comparatively slow serial memory (predictive read).
125 Mhz.
The namespace engine also provides subscription tracking
Simulated network traffic included a full TCP/IP con-
by monitoring bus operations and automatically storing the
nection handling, OPC UA transport layer connection han-
information necessary to generate publish responses. A general
dling (HEL/ACK/CLO), managing the secure session (Open-
1 1.6 MB of equivalent XML description or 196 kB for OPC UA binary /CloseSecureSession), reading server endpoints (GetEnd-
encoding points) and reading the server-status node (Read). The com-
plete testbench was concluded in 245 μs, a single read trans-
action taking 25.52 μs2 . The server responses where verified
to be equivalent to software implementations. Several error
scenarios where run for all implemented services as well as
the TCP/IP engine, which were all successfully recognized and
handled by their respective coders.
Synthesis studies for FPGAs and the GF28nm SLP CMOS
technology confirm the high efficiency and low footprint of the
OPC UA hardware peripheral IP. Synthesis targeting GF28nm
SLP CMOS resulted in a footprint of 75.800 μm2 at 125 Mhz3
On a Xilinx FPGAs the maximum clock rate was 70 Mhz45 ,
while the Altera Cyclone V reaches 60 Mhz 6 .
Energy consumption and footprint scale linear to the num-
ber and types of services coders of the server (profiles).
Dynamic coder identification over the bus system enables
the addition or removal of services to the network on chip
fabric at design time. Since no other modifications to the
hardware are necessary, the process of configuring profiles and
service parallelism could be automatically generated using IP
Core generators that determine the appropriate service coder
configuration depending on the use case. Further means to
tune the stacks Characteristics includes adjustments of cache
sizes, stack- and in-processor buffer depths and the maximum
number of chunks/shared FIFO sizes.
IV. C URRENT WORKS
Current works focus on implementing and improving the
namespace engine, in particular in regard to supporting model
changes that insert or delete segments of memory from the
static binary image. The NoC protocol is being revised to allow
message prioritization, effectively enabling quality-of-service
support. The large number of configurable components such
as memory sizes or the number of service coders is examined
to determine the appropriate service multiplicity and memory
configuration in dependance of several use cases. Since all
service coders are identical from a hardware standpoint, one
concept being closer examined is implementing floating ser-
vice coders by assigning the appropriate program just in time
as a message requires processing, which would allow for a
load dependent, adaptive coder availability. The bus protocol
is being redesigned to include message priorization so that
messages of certain client gain priority when searching or
assigning message coders.
V. C ONCLUSION
The works presented in the paper demonstrate the feasi-
bility and benefits of using an OPC UA Hardware Server.
By employing a hierarchic coder structure derived from the
OPC UA binary protocol structure allows the fully paral-
lel and autonomous processing of individual messages. The
independence of the processing coders, fixed size, shared
2 Firstbit reception to last bit transmission on ethernet PHY
3 Areas for slow-corner models at 85o C.
4 Virtex 6 XC6VLX75T: 36% logic use, 57% memory use
5 Artix7 XCA100T-CSG324: 20% logic use, 19% memory use
6 CycloneV 5CGFXC7D7F31C8: 15% logic use, 7% memory use
FIFO buffers and a non blocking, round robin controlled bus
fabric provides deterministic and predictable processing times,
making the protocol usable in real-time critical applications
without mandating additional protocols. The design provides
a high degree of configurability in regard to its functionality,
energy consumption and footprint. Access to large information
models is made possible by recoding the information to fit on
a serial, non-volatile memory component, with written data
being masked in a small memory area during access. The sum
of these efforts makes OPC UA accessible to even the simplest
microcomputing platforms in actors and sensors, enabling their
vertical integration into information networks. If scaled, the
design also provides mean for implementing high throughput,
autonomous aggregating servers and other use cases.
R EFERENCES
[1] M. Damm, W. Mahnke, and S.-H. Leitner, OPC Unified Architecture.
Springer, 4 2009.
[2] L. Zheng and H. Nakagawa, “Opc (ole for process control) specification
and its developments,” in SICE 2002. Proceedings of the 41st SICE
Annual Conference, vol. 2, p. 917–920 vol.2, 8 2002.
[3] S. H. Jeanne Schweder, “Platform industrie 4.0 proposes reference
architecture model for industrie 4.0: Opc-ua confirmed as one and only
standard in category "communication layer",” 04 2015.
[4] P. Reboredo and M. Keinert, “Integration of discrete manufacturing
field devices data and services based on OPC UA,” in Industrial
Electronics Society, IECON 2013-39th Annual Conference of the IEEE,
p. 4476–4481, IEEE, 2013.
[5] J. Imtiaz and J. Jasperneite, “Scalability of opc-ua down to the chip
level enablesinternet of things,” in Industrial Informatics (INDIN), 2013
11th IEEE International Conference on, 7 2013.
[6] G. Shrestha, J. Imtiaz, and J. Jasperneite, “An optimized opc ua transport
profile to bringing bluetooth low energy device into ip networks,” in
Emerging Technologies Factory Automation (ETFA), 2013 IEEE 18th
Conference on, p. 1–5, 9 2013.
[7] MatrikonOPC, OPC-UA Device Server Hardware Development Kit
(HDK). MatrikonOPC, 6 2013.
[8] V. VDK, OPC-UA Specification Part 6, vol. 6 of OPC-UA Specification.
OPC Foundation, 11 2008.
[9] J. Gummaraju and M. Rosenblum, “Stream Programming on General-
Purpose Processors,” in MICRO 38: Proceedings of the 38th annual
ACM/IEEE international symposium on Microarchitecture, (Barcelona,
Spain), 11 2005.
[10] C. Legat, C. Seitz, and B. Vogel-Heuser, “Unified sensor data provision-
ing with semantic technologies,” in Emerging Technologies & Factory
Automation (ETFA), 2011 IEEE 16th Conference on, p. 1–8, IEEE, 2011.
[11] K. Weicker and N. Weicker, Algorithmen und Datenstrukturen. Springer-
Verlag, 2013.