This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2020.3043116, IEEE
Transactions on Instrumentation and Measurement
1

Assessment of Different OPC UA Implementations

for Industrial IoT-based Measurement Applications
Alberto Morato, Stefano Vitturi, Federico Tramarin and Angelo Cenedese

Abstract—The Industrial IoT (IIoT) paradigm represents an an even further level of interaction to integrate instrumentation
attractive opportunity for new generation measurement appli- data, sensors, communication and processing. Moreover, the
cations, which are increasingly based on efficient and reliable need of improving production capacity and optimizing the out-
communication systems to allow the extensive availability of
continuous data from instruments and/or sensors, thus enabling put process, and eventually exploiting predictive maintenance
real-time measurement analysis. Nevertheless, different communi- and machine learning approaches [5], requires an increased
cation systems and heterogeneous sensors and acquisition systems number of sensor devices and sensor swarms to be deployed.
may be found in an IIoT-enabled measurement application, This new IIoT–enabled DMS scenario is based on the
so that solutions need to be defined to tackle the issue of support of efficient and reliable communication systems, which
seamless, effective, and low-latency interoperability. A significant
and appropriate solution is the Open Platform Communications have to ensure widespread availability of data gathered from
(OPC) Unified Architecture (UA) protocol, thanks to its object– possibly heterogeneous measurement instruments and/or sen-
oriented structure that allows a complete contextualization of sors [6], [7]. Overall, the IIoT paradigm may represent the
the information. The intrinsic complexity of OPC UA, however, enabler for several enhanced measurement features: continu-
imposes a meaningful performance assessment to evaluate its ous and thorough measurements through low-power wireless
suitability in the aforementioned context. To this aim, this paper
presents the design of a general yet accurate and reproducible connections, measurement collection over considerably wide
measurement setup that will be exploited to assess the perfor- geographic areas, and real-time analysis of measurement data
mance of the main open source implementations of OPC UA. collected from the field [8].
The final goal of this work is to provide a characterization of the Unfortunately, in the highlighted IIoT scenario it is common
impact of this protocol stack in an IIoT-enabled Measurement that components and sensors devices come from different
System, in particular in terms of both the latency introduced in
the measurement process and the power consumption. producers and use different formats to represent measurement
data, and also it is very likely that they intrinsically operate
Index Terms—Industrial internet of things (IIoT), distributed over heterogeneous networks. Hence, the provision of ways
sensors, open platform communication unified architecture (OPC
UA), latency assessment, performance evaluation, distributed to enable communication and interoperability among such
measurement applications. devices is of paramount importance. A key solution toward
this goal is the Open Platform Communication (OPC) Uni-
fied Architecture (UA) [9]. OPC UA is a protocol defined
I. Introduction
by the IEC 62541 international standard [10] conceived to
In the last few years, the industrial world embraced the implement Machine–to–Machine (M2M) communication over
Industry 4.0 paradigm [1], which merges technologies with possibly different physical media, while ensuring high level
products, systems, and services, having its own intrinsic net- data protection against attacks and threats.
worked structures, to realize the Industrial Internet of Things OPC UA represents hence an appealing and advantageous
(IIoT) [2], [3]. IIoT is a network of networks that connects opportunity for the arising IIoT measurement paradigm. Par-
industrial equipment, controllers, sensors and actuators, i.e. ticularly, its object–oriented structure allows a complete con-
the “Things”, to provide diverse and advanced types of ser- textualization of the information. For instance, an OPC UA
vices in manufacturing systems, aiming at improving quality, object could be used to store the value of a measurement,
productivity, efficiency, reliability, safety, and security. the features of the instrument/sensor, the measurement units,
Traditionally, the foundation of manufacturing and process possible thresholds and so on. Such important characteristics
industries has been in the deployment of specific distributed allow for new generation of measurement instruments to deal
sensor systems, to the purpose of monitoring (and then con- with multiple and heterogeneous types of data.
trolling) the production process, thus leveraging the concept At the same time, the complexity of the OPC UA protocol
of Distributed Measurement Systems (DMS) [4]. With the in- may also reveal an obstacle to its introduction within measure-
creased pervasiveness of the IIoT paradigm, DMSs come even ment systems. Indeed, sensors and actuators, field equipment
more into focus, since the components of an IIoT system need and measurement instruments in the IIoT scenario are typically
realized exploiting devices with limited hardware resources
A. Morato is with the Dept. of Information Engineering, University of
Padova, Italy and with CMZ Sistemi Elettronici srl, Carbonera, Italy. and low computational capabilities (and low costs). As a
A. Cenedese is with the Dept. of Information Engineering, University of consequence, the implementation of OPC UA on such devices
Padova, Italy and with the CNR–IEIIT, National Research Council of Italy. might be problematic and, furthermore, the performance might
S. Vitturi is with the CNR–IEIIT, National Research Council of Italy.
F. Tramarin is with the Dept. of Engineering E. Ferrari, University of result compromised, in terms of increased latency and power
Modena and Reggio Emilia, Italy. consumption, hence impairing the quality and accuracy of

0018-9456 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: Newcastle University. Downloaded on December 28,2020 at 05:10:13 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2020.3043116, IEEE
Transactions on Instrumentation and Measurement
2

measurements. Three of them are open source, namely Open62541, FreeOPC

UA C++ and FreeOPC UA Python, whereas the fourth one is
a proprietary product, namely Prosys OPC Java. The work is
II. Related Work and Contribution
aimed at investigating the behavior of OPC UA for the different
The introduction of Industrial IoT technologies in the con- implementations focusing on i) CPU usage, ii) communication
text of distributed measurement systems has started to be times and iii) power consumption. In order to provide a
addressed some years ago. Paper [8] deals with the potential of meaningful and fair assessment, the protocol was implemented
IIoT for the instrumentation and measurement fields. Notably, on a widespread commercially available Raspberry Pi Model
the authors provide an accurate assessment that addresses ben- 3B+ board that, thanks to its features, represents a manageable
efits and challenges, including also some useful commercial and effective test–bed. The measurement set–up has been
aspects. In [11], [12] and [13] the authors address diverse designed to be of general usage and reproducible. Also, ex-
Low Power Wide Area Networks (LPWAN) to enable IIoT- periments have been mostly carried out using two widespread
based measurement and monitoring applications over large communication systems, namely Ethernet and Wi–Fi.
distances. Both papers [14] and [15] describe the use of Wi-Fi, In detail, the paper is organised as follows. Section III gives
another important network for IIoT, to implement measurement a brief description of the OPC UA protocol and outlines the
systems that involve remote cloud data storage and analysis. possible structure of distributed measurement systems that rely
Moving to OPC UA, in [16] the authors describe a method on OPC UA. Section IV introduces the experimental set–up
to achieve synchronization among electrical drives connected implemented for the measurements. Section V describes the
via EtherCAT (a widespread real–time Ethernet network) using tests carried out and discusses the obtained results. Finally,
the OPC UA protocol. Particularly, the paper deals with the Section VI concludes the paper and outlines some future
significant topic of obtaining a high accuracy synchronization directions of research.
over a geographically distributed system, that is of uttermost
importance in distributed measurement applications. In [17],
III. Brief Introduction to OPC UA
the authors refer to metrology assisted assembly systems, and
introduce the optical large–scale metrology instruments, such OPC UA is based on a client–server relationship, in which
as laser trackers and indoor GPS. Then they propose an object– the information is structured following an object–oriented
oriented model to formally describe such instruments and model, where objects are formally referred to as “nodes”. The
investigate the suitability of OPC UA, as well as that of OPC UA model defines the node objects in term of variables,
other protocols, to implement such a model. In [18] OPC methods and events. A Node is, hence, the fundamental entity
UA is used to implement a smart sensor system to monitor of OPC UA and represents a basic object which has only the
the behavior of numerical control devices in the Industry attributes necessary to define any kind of information item
4.0 context. Specifically, OPC UA objects are used to store (e.g. ID, name, etc.). The set of nodes made available by an
sensor information such as measurement, threshold, range, OPC UA server is referred to as the address space [22].
product data, etc. Another interesting OPC UA application is To access the information stored within the nodes, OPC UA
proposed in [19]. Here the authors present a system based provides for a number of service sets. The attribute service
on OPC UA to connect and integrate components typical of set, in particular, contains the read/write services that may
industrial automation as well as of distributed measurement be used by a client to access the attributes of a node. Thus, for
systems. Examples of applications are provided that include example, the attribute “value” of a node of type “variable” may
smart microgrids, industrial laboratories and energy systems in be read (respectively, written) by a client by suitably invoking
general. Paper [20] considers an IIoT environment and focuses the read (respectively, write) service.
on the transfer of plant data to a cloud when OPC UA–based With the subscription service set, a client may define a “sub-
gateways are used to gather data directly at the production scription” and assign to it some “monitored items”. Then, any
level. Notably, the authors implemented a measurement system attribute of any node in the address space may be associated to
that allowed to determine the impact of Quality of Service a monitored item. The change of one of such attributes triggers
parameters on the communication delays. a “notification” to the subscription. Based on a “publishing
The papers cited above represent interesting contributions. interval” set by the client, the subscription periodically sends
However, as far as OPC UA is concerned, they mostly describe to the client the list of notifications that occurred during the
meaningful applications that make use of such protocol, with- publishing interval. In this way, for example, a client may be
out investigating its actual potential and capabilities. Nor, they notified periodically with the list of changes of the attribute
consider protocol implementation aspects, which represent value, of a node of type variable, that occurred in the last
very important issues especially in the industrial scenario. publishing interval.
Moving from the above considerations, in this paper, which More recently, a further relationship to exchange infor-
substantially extends [21], we propose a more structural as- mation in the context of OPC UA has been added to the
sessment about the adoption of OPC UA in the context of standard, namely, the PubSub (Publisher – Subscriber) rela-
IIoT–based measurement systems. In this respect, we report tionship. It is complementary to the client–server one. With
and discuss the results of an experimental work on some this model, a publisher is responsible for creating “DataSets”
popular implementations of the OPC UA protocol stack, that may contain the attributes of variable or event nodes
Particularly, we considered four OPC UA implementations. (for example the value of a variable). DataSets are grouped

0018-9456 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: Newcastle University. Downloaded on December 28,2020 at 05:10:13 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2020.3043116, IEEE
Transactions on Instrumentation and Measurement
3

within “DataSetMessages“ that are sent continuously to a Raspberry Pi3 Raspberry Pi3
“Message Oriented Middleware” that, in turn, delivers them OPC
OPCUAUA Ethernet OPC
OPCUAUA
to subscribers. With such a model, it is possible to distribute Server
Server Switch Client
Client
data and events relevant to the publisher to a set of devices Ethernet Configuration
(subscribers) in a very efficient way.
Raspberry Pi3 Raspberry Pi3
In the context of IIoT-based measurement applications, the Access
OPC
OPCUA (( ( (( ( OPC
OPCUA
(( ( (( (
OPC UA protocol can be profitably exploited to allow seamless UA Point UA
Server
Server Client
Client
and secure interoperability among the heterogeneous sources WiFi Configuration WiFi
of measurement data, as well as among the heterogeneous
communication networks. Indeed, measurements can be stored Fig. 2. Experimental set–up.
by nodes that belong to one or more servers, so that they can
be seamlessly accessed by distributed clients using, for ex- mobility and larger installations. More importantly, although
ample, the aforementioned service sets. An illustrative sketch Wi-Fi networks are able to provide very high transmission rate
representing the described scenario is reported in Figure 1. and good reliability, the performance figures they provide are
As can be seen, measurements stored in different devices, and clearly different with respect to those of Ethernet networks,
structured within diverse OPC UA servers, can be remotely that may considered hence as a benchmark. An important as-
accessed by an OPC UA client which implements techniques pect that will be analyzed in this work is hence the comparison
of real–time analysis and visualization. between the two network supports in terms of latency to gather
measurement data, which is a crucial parameter for accurate
Measurement real-time Analysis distributed measurements.
and Visualization As can be seen, the same topology was used for the two
networks, with OPC UA client and server implemented on two
diverse Raspberry Pi boards. A Netgear WGR 614 Wireless-
OPC UA client G router was used to connect the two boards that was able to
seamlessly implement the packet routing for both the Ethernet
and Wi-Fi configurations.
Two different operating system versions have been used
Cloud, for the boards. The first one is represented by the default
Internet or Raspbian OS (Kernel version 4.14.79), whereas the second
Local Network one is its real-time version (Kernel version 4.14.74–rt44).
The latter one has been obtained from the default kernel
version with the introduction of the RT_PREEMPT patch set,
which enables a real–time behavior of the system allowing
non critical parts of the kernel to be preempted in favor of the
OPC UA Server OPC UA Server
execution of userspace applications. Furthermore, we exploited
a useful feature offered by the Linux operating system, to
Instrument ... Instrument isolate a group of CPU cores in which a process can be
or Sensor or Sensor run. Specifically, the isolcpus boot parameter in combination
with the taskset command, allows to isolate one or more
Fig. 1. Example of use of OPC UA in an IIoT-based Measurement System. cores from the kernel scheduling and to reserve them for the
execution of userspace applications without interference from
the OS. Furthermore, in order to minimize the external factors
IV. Experimental Set–up that may affect the accuracy of the measurements, the CPU
governor (i.e. a kernel–level component responsible of scaling
The experimental set–up has been redesigned, with respect the CPU frequency based on the workload) has been disabled
to [21], to be as much general as possible, with reproducibility during the experiments and the CPU frequency has been set
in mind in order to be easily reused in different scenarios. The to its maximum operable value of 1.4 GHz.
set–up has been used to assess the behavior of some different The implementations of OPC UA considered in the ex-
OPC UA protocol stacks, implemented on lightweight embed-
ded systems, that resemble those adopted by intelligent IoT TABLE I
sensors. Particularly, experiments have been carried out using OPC UA Implementations.
Raspberry Pi Model 3B+ boards, over two diverse communi-
cation systems, namely Ethernet and Wi-Fi, as schematically OPC UA Programming Commit
Type
shown in Fig. 2. Indeed, while both networks are meaningful Implementation Language Hash
in distributed measurement systems and IIoT scenarios, the Open62541 Open Src. C99 / C++98 9f0c73d
former is much more targeted to high performance, ultra FreeOPC UA C++ Open Src. C++11 da2b76f
low-latency and local measurement applications, whereas the FreeOPC UA Python Open Src. Python 83fb9ea
Prosys Java v4.3.0-1075 Proprietary Java —
latter represents its wireless counterpart, allowing for increased

0018-9456 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: Newcastle University. Downloaded on December 28,2020 at 05:10:13 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2020.3043116, IEEE
Transactions on Instrumentation and Measurement
4

periments are reported in Table I, along with the indication TABLE II

of the adopted programming language (PL). For the open Statistics of the CPU Usage.
source implementations (available through the popular Github
CPU Usage
platform) we also provide the commit hash of the sources at
the time the experiments were performed. In Kernel In User
Mean
Space Space
All the listed protocol stacks work natively on Raspberry
Pi boards, and consequently their setup procedures have not Open62541 17.2% 60.89% 39.11%
involved any further software adaptation. However, they are FreeOPC UA C++ 26.1% 50.63% 49.37%
FreeOPC UA Python 51.2% — —
conceptually different. In particular, as can be seen, two out Prosys Java 50.9% — —
of four stacks are implemented by means of compiled lan-
guages (C/C++), whereas the other ones are implemented in,
respectively, Python and java, which are high level interpreted Server
Client
languages. As a consequence the analysis of their behaviors
reveals necessary to provide useful insights for the applications Thread A: Thread B: Read
Acquisition request
that use them. In this direction, since the outcomes of the of a variable OPC UA
from the sensor Server Stack
experiments also depend on the adopted development envi-
OPC UA
ronment, the most relevant technical details are summarized Client Stack
below:
Common Response with
• Python version 3.5.3; memory variable object
area
• openJDK 1.8;
• glibc 2.23;
• gcc version 6.3.0;
Fig. 3. Test Task for OPC UA.
• gcc optimization option: -O3 -s.
Finally, it has to be pointed out that other valuable OPC latter one highlighted a rather higher utilization compared to
UA implementations are available (either free of charge or the other ones. However, this is not surprising since FreeOPC
commercial), that could have been considered in our work. UA Python and Prosys Java are based on interpreted languages,
For example Eclipse Milo, ASNeG OPC UA, OpenOpcUa, that are certainly less efficient. It is interesting to note that, for
High Performance OPC UA, to mention some. To this regard, the Open62541 implementation, the subdivision of the used
an interesting overview of such solutions is provided in [23]. resources of the CPU is slightly unbalanced towards the Kernel
However, the aim of our analysis is to investigate the behavior Space, while for FreeOPC UA C++ we have a subdivision
of OPC UA in the context of IIoT based measurement systems, almost at 50%. Unfortunately, values for FreeOPC UA Python
not to provide a comparison of different OPC UA imple- are not available, because the tool Perf, with which the
mentations. For this reason, we selected among the available analysis was performed, does not support measurements of
solutions those listed in Table II paying attention to their the stack of interpreted languages.
diversity, so that the proposed assessment can result adequately
comprehensive.
B. Read and Write Services
V. Measurement Results and Analysis The experiments we carried out to test the OPC UA read and
write services were based on a purposely developed test OPC
The objective of the measurements is to assess the behavior
UA task, with which an integer variable stored in the OPC
of the diverse different OPC UA implementations focusing
UA server is read by the OPC UA client. In a first session, we
on performance figures that are of interest for IIoT-based
focused on the open source implementations. In this task, the
measurement instruments and applications. Specifically, we
server implements two separate threads as shown in Figure 3.
addressed the CPU usage, the power consumption and the
Thread A simulates the acquisition of a new measurement (i.e.
task execution times. The latter indicator is of particular
a physical quantity) every second, by increasing an integer
significance in the application context of this paper, since it has
variable. Thread B is instead devised to manage the whole
reflects the overall latency with which measurement data can
OPC UA server. The measurement outcome, stored in an OPC
be collected at the client, and is hence a meaningful indicator
UA object, is saved in a memory area common to both threads
of the intrinsic capability of the system to sustain real-time
so that the server can access it. In the test task, the OPC UA
measurement analysis over networks [8].
client cyclically reads the value of the variable stored on the
server. This is accomplished by a read request issued by the
A. CPU Usage client, to which the server answers in agreement with the OPC
A first set of outcomes is resumed in Table II, which shows UA protocol rules.
the statistics about the CPU usage for the three considered The outcomes relevant to the CPU usage for the read and
implementations. write services are reported in Table III. The table refers to
As can be seen, Open62541 is the most efficient from context switches, CPU migrations and total number of CPU
the average resources utilization point of view, followed by cycles to complete the execution of 100.000 consecutive OPC
FreeOPC UA C++ and FreeOPC UA Python. Actually, the UA test tasks. These outcomes are common indices exploited

0018-9456 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: Newcastle University. Downloaded on December 28,2020 at 05:10:13 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2020.3043116, IEEE
Transactions on Instrumentation and Measurement
5

to determine the efficiency of a program, where high values TABLE IV

indicate poor optimization and therefore long execution times. Statistics of the Execution Time for the OPC UA Test Task –
Non–Isolated CPU.
The results are in good agreement with those shown in Subsec-
tion V.A. Also in this case, both the compiled implementations Execution Time 𝑇𝑠 [µs]
have comparable values, whereas both the Python and Java Generic OS RT OS
based ones show much higher values regarding in particular
Mean Std Mean Std
the number of CPU cycles.
Ethernet
Open62541 312.83 12.56 382.48 24.44
TABLE III FreeOPC UA C++ 377.30 4.54 467.59 15.01
CPU usage for the OPC UA test task. FreeOPC UA Python 736.79 7.44 778.43 20.63
Wi-Fi
context CPU CPU Open62541 2036.12 501.60 3765.62 924.52
switches migrations cycles FreeOPC UA C++ 2063.38 488.10 3869.62 907.36
FreeOPC UA Python 9274.24 750.59 12824.94 3901.25
Open62541 100 · 103 1 7.7 · 109
FreeOPC UA C++ 200 · 103 0 13 · 109
FreeOPC UA Python 283 · 103 29 533 · 109
Prosys Java — — 174 · 109 TABLE V
Statistics of the Execution Time for the OPC UA Test Task – Isolated
CPU.
To assess the performance of the read and write services,
we measured the task execution time, 𝑇𝑠 , defined as the time Execution Time 𝑇𝑠 [µs]
necessary to complete one instance of the OPC UA test task Generic OS RT OS
described in Figure 3. Specifically, 𝑇𝑠 represents the time Mean Std Mean Std
that elapses between the read request of the client, 𝑇𝑟 𝑒𝑞 , and Ethernet
the time at which it actually receives the OPC UA object Open62541 306.67 12.76 368.78 10.13
containing the variable, 𝑇𝑟 𝑒𝑠 . FreeOPC UA C++ 374.74 3.32 457.60 11.32
FreeOPC UA Python 711.27 6.52 735.84 9.69
𝑇𝑠 = 𝑇𝑟 𝑒𝑠 − 𝑇𝑟 𝑒𝑞 (1) Wi-Fi
Open62541 1950.29 460.55 3431.68 886.28
In the experiments, 𝑇𝑠 has been measured by a direct access FreeOPC UA C++ 2017.71 457.51 3656.67 902.52
FreeOPC UA Python 9031.62 713.10 12463.11 3807.16
to the content of the Cycle Counter Register (CCR), an
internal CPU register implemented within ARM processors,
which is a counter of the processor clock cycles. This design standard deviations is similar, with an exception relevant to
choice is significant to improve the accuracy relevant to the the Open62541 implementation. In this case, a slight increase
measurement of the task execution time, because accessing (from 12.56 to 12.76 µs) is observed when switching from
the CCR register requires only one CPU cycle [24], hence the non–isolated case to the isolated one. We believe this
introducing a negligible impact on the evaluation of the time aspect may be explained by the low average execution time
𝑇𝑠 . The OPC UA test task was run continuously, meaning that of the Open62541 implementation. Indeed, we have checked
a new instance of the task was started immediately after the that only the 30% of the CPU time was necessary to execute
conclusion of the former one. In the Ethernet configuration, the the Open62541 stack. Thus, both the task execution time and
selected transmission rate was 100 Mbit/s whereas, for the Wi- its variability, are mostly determined by the execution times
Fi one, we chose the IEEE 802.11g mode, with transmission of unbounded kernel threads (e.g. those concerned with the
rate dynamically selected by the multi–rate support feature TCP/IP protocol suite, the network drivers, etc.), as well as by
provided by such protocol1. For each experimental session, the network transmission times, that do not benefit from the
𝑁 = 100.000 measurements of the execution time have been CPU isolation.
collected and analyzed. Furthermore, all the components of The results shown in Table V are confirmed by the prob-
the experimental set–up were located sufficiently close to each ability density functions obtained experimentally (empirical
other to ensure, particularly for the Wi-Fi configuration, a probability density function, EPDF), reported for the Ethernet
high success probability in packet delivery. This has been configuration, respectively, in Fig. 4 (generic operating system)
subsequently confirmed by the traffic analysis we carried out, and in Fig. 5 (RT operating system). As can be seen, the CPU
that showed a very low number of packet retransmissions and isolation improves the EPDF shapes in most cases.
losses, with an average of about 3.6%. The tests carried out on the Wi-Fi configuration revealed
The statistics of the execution time for the OPC UA test similar trends, as shown in both Table IV and Table V and
task are reported in Table IV for the case of non – isolated in both Fig. 6 and Fig. 7. In particular, the benefits brought
CPU and, respectively, in Table V for the isolated one. by the CPU isolation are evident. As can be seen, both mean
At a first glance, the beneficial effect of introducing CPU and standard deviation are greater with respect to the Ethernet
isolation appears clear. Indeed, as shown in Table V, all mean case. This is due to the longer packet transmission times as
values decrease when such a feature is used. The behavior of well as to the possible retransmissions (interleaved by random
1Please note that the multi–rate support feature could not be disabled on backoff times) that could be necessary to successfully deliver
Raspberry Pi boards. a packet. Also, as discussed in [25], the task execution time is

0018-9456 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: Newcastle University. Downloaded on December 28,2020 at 05:10:13 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2020.3043116, IEEE
Transactions on Instrumentation and Measurement
6

·10−2 ·10−2
15
Empirical PDF

Empirical PDF
10 Without cpu isolation Without cpu isolation
With cpu isolation 10 With cpu isolation
5
5

0 0
280 300 320 340 360 380 340 360 380 400 420 440 460
𝑇𝑠 [µs] 𝑇𝑠 [µs]
(a) Open62541 (a) Open62541

·10−2 ·10−2
Empirical PDF

Empirical PDF
6
20
4
10
2
0 0
340 350 360 370 380 390 400 410 420 420 440 460 480 500 520 540 560
𝑇𝑠 [µs] 𝑇𝑠 [µs]
(b) FreeOPC UA C++ (b) FreeOPC UA C++

·10−2 ·10−2
10
Empirical PDF

Empirical PDF
6
5 4
2
0 0
700 710 720 730 740 750 760 770 780 790 720 740 760 780 800 820 840 860
𝑇𝑠 [µs] 𝑇𝑠 [µs]
(c) FreeOPC UA Python (c) FreeOPC UA Python

Fig. 4. Generic OS: EPDF of the execution time of the OPC UA test task Fig. 5. RT OS: EPDF of the execution time of the OPC UA test task for the
for the Ethernet configuration. Blue line: configuration without CPU isolation. Ethernet configuration. Blue line: configuration without CPU isolation. Red
Red line: configuration with CPU isolation enabled, where both server and line: configuration with CPU isolation enabled, and where both server and
client are forced to run on the isolated CPU. client are forced to run on the isolated CPU.

further negatively influenced by the Access Point which may the Linux real–time extension has negative effects on the
introduce additional, non negligible, delays and randomness. throughput of the communication interface. This is confirmed
The introduction of the RT operating system, in general, by the traffic analysis that showed, in the worst case, an
worsened the behavior of the OPC UA test task execution increment of 2.8 times of packet retransmissions.
time, as can be evinced from the statistics and the EPDF Focusing on the stack implementations, the obtained re-
reported above. Actually, the mean values are higher for all the sults show that both the compiled versions, Open62541 and
OPC UA implementations, with respect to the correspondent FreeOPC UA C++, are characterized by comparable average
cases in which the generic OS is used. The same happens values of the OPC UA test task execution time. Conversely, the
for the standard deviation, with the unique exception of the average 𝑇𝑠 is much higher (about doubled) for the FreeOPC
Open62541 implementation (in this case, the value decreases UA Python implementation, as it was expected since Python
from 12.76 to 10.13 µs when the RT OS is used). However, is an interpreted language. This aspect is exacerbated for
as already pointed out, these values, for the Open62541 the Wi-Fi configuration. As far as the standard deviation
implementation, are mostly influenced by the times necessary is concerned, with the Ethernet configuration, Open62541
to execute unbounded kernel threads. presents higher values than both FreeOPC UA C++ and
Although the worsening observed when the RT operating FreeOPC UA Python, especially as percentage of the mean,
system is used may seem surprising, it may be explained reflecting in a considerable jitter of the execution time. This
making some considerations about the introduction of the feature is evident for the generic operating system, whereas it
Linux real–time extension. Actually, as can be seen from Table appears more vague for the RT operating system, likely due
II, all the considered implementations of the OPC UA protocol to the additional randomness introduced by this latter one. A
stack make extensive use of the kernel functions, especially similar consideration can be made for the Wi-Fi configuration.
those concerning network connectivity. Nonetheless, the real- In this case, as can be seen, both the mean and standard
time patch makes some parts of the kernel preemptable, thus deviation are increased with respect to Ethernet. However, the
leaving up more space for executing instructions in the user standard deviation values become comparable, especially for
space. Thus, the stack execution could be interrupted more Open62541 and FreeOPC UA C++, likely as an effect of the
frequently, resulting in longer execution times and greater randomness in accessing the physical medium introduced by
jitter. Furthermore, as reported in [26], the application of Wi-Fi.

0018-9456 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: Newcastle University. Downloaded on December 28,2020 at 05:10:13 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2020.3043116, IEEE
Transactions on Instrumentation and Measurement
7

·10−2 ·10−2
10
Empirical PDF

Empirical PDF
Without cpu isolation 8 Without cpu isolation
With cpu isolation 6 With cpu isolation
5 4
2
0 0
1.6 1.7 1.8 1.9 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2 2.5 3 3.5 4 4.5 5
𝑇𝑠 [µs] ·103 𝑇𝑠 [µs] ·103
(a) Open62541 (a) Open62541

·10−2 ·10−2
10 10
Empirical PDF

Empirical PDF
5 5

0 0
1.7 1.8 1.9 2 2.1 2.2 2.3 2.4 2.5 2.6 2 2.5 3 3.5 4 4.5 5
𝑇𝑠 [µs] ·103 𝑇𝑠 [µs] ·103
(b) FreeOPC UA C++ (b) FreeOPC UA C++

·10−2 ·10−2
Empirical PDF

Empirical PDF
4
4
2 2
0 0
0.84 0.86 0.88 0.9 0.92 0.94 0.96 0.98 1 1.02 1.04 0.8 1 1.2 1.4 1.8 2
1.6
𝑇𝑠 [µs] ·104 𝑇𝑠 [µs] ·104
(c) FreeOPC UA Python
(c) FreeOPC UA Python

Fig. 6. Generic OS: EPDF of the execution time of the OPC UA test task for
Fig. 7. RT OS: EPDF of the execution time of the OPC UA test task for the
the Wi-Fi configuration. Blue line: configuration without CPU isolation. Red
Wi-Fi configuration. Blue line: configuration without CPU isolation. Red line:
line: configuration with CPU isolation enabled, where both server and client
configuration with CPU isolation enabled, and where both server and client
are forced to run on the isolated CPU.
are forced to run on the isolated CPU.

The final experiments of the read and write services

·10−2
were concerned with the Prosys Java implementation. In this
Empirical PDF

4 Without cpu isolation

case, due to space limitations we considered only the (most With cpu isolation
meaningful) case of generic OS over Ethernet. The EPDF of 2
the test task execution time is shown in Fig. 8, whereas the
statistics are reported in Table VI. As can be seen, both mean 0
and standard deviation are considerably higher with respect to 2,500 2,600 2,700 2,800 2,900 3,000
the open source implementations, confirming the trend already 𝑇𝑠 [µs]
observed when an interpreted language (Java in this case) is
used. Also, the EPDF shown in Fig. 8 puts in evidence the Fig. 8. EPDF of the execution time of the OPC UA test task for the Prosys
Java implementation on Ethernet with Generic OS.
high variability of 𝑇𝑠 , which is only partially mitigated by the
CPU isolation.
previous Subsection, we considered the case of generic OS
TABLE VI over Ethernet. Moreover, we focused on only one open source
Statistics of the Execution Time for the OPC UA Test Task for the implementation, namely Open62541, and on the Prosys Java
Prosys Java implementation on Ethernet with Generic OS. proprietary solution. Notably, Open62541 revealed the most
effective open source implementation among those addressed
Execution Time 𝑇𝑠 [µs]
in the previous subsection. Also, as discussed in [27] and [28],
Without Open62541 is well supported and suitable for applications in
CPU Isolation
CPU Isolation
the IIoT scenario.
Mean Std Mean Std
2793.19 348.50 2648.31 280.13 Subscription services are totally asynchronous and let the
server to notify changes in its nodes. With refer to Fig 3, we
associated a monitoring item to the sensor value simulated
by Thread A. In this way, the server checks the data source
C. Subscription Services with a period defined by the “Sampling Interval” and, when
In this session of experiments, we addressed the OPC the publishing interval elapses, it sends a “Publish Response”
UA subscription services. Similarly to the last test of the message containing the notification of data change. Then the

0018-9456 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: Newcastle University. Downloaded on December 28,2020 at 05:10:13 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2020.3043116, IEEE
Transactions on Instrumentation and Measurement
8

·10−2 ·10−2
2 3
Empirical PDF

Empirical PDF
Without cpu isolation Without cpu isolation
1.5 With cpu isolation 2 With cpu isolation
1
1
0.5
0 0
220 240 260 280 300 320 250 300 350 400 450 500 550
𝑇𝑠 [µs] 𝑇𝑠 [µs]

Fig. 9. EPDF of the delivery time for the subscription service – Open62541 Fig. 10. EPDF of the delivery time for the subscription service – Prosys Java
implementation over Ethernet with Generic OS. implementation over Ethernet with Generic OS..

client acquires the data and sends a “Publish Request” message since for such a proprietary implementation, it has not been
that acknowledges the received data. possible to modify the stack core to set the GPIO pins.
To assess the performance of the subscription service for the Thus, we resorted to analyze the time stamps of the messages
Open62541 implementation, we evaluated the delivery time, exchanged over the network, acquired with Wireshark. The
defined as the time employed by the client to acquire a data delivery time has been hence determined as the time interval
published by the server. The measurements have been carried between the generation of the publish response message and
out as follows. When the publish response message is ready the arrival of the acknowledgment generated by the client.
to be transmitted, the server sets one of the GPIO pins of the The EPDF of the delivery time is shown in Fig. 10, whereas
Raspberry Pi. Similarly, when the client receives the message the statistics are reported in Table VIII
at the application level, it sets one of its GPIO pins. The As can be seen, also in this case, the subscription service
interval elapsed between the generation of the two consecutive appears more efficient than the read one (although, as already
signal edges represents the delivery time. In this experiment, pointed out for the Open62541 implementation, an effective
6000 measurements have been collected and analyzed. comparison can not be made). Indeed, the mean time necessary
On the server, both the publishing interval and sampling to acquire a measurement data by the client is definitely lower
interval have been set to 100 ms, which is the minimum than that shown in Table VI for the read service. Also, the
selectable value on the default implementation of Open62541, beneficial effect of the CPU isolation is evident.
whereas the update interval of Thread A has been set to 30 ms.
The signal edges of the GPIO have been acquired by a logic TABLE VIII
analyzer with a sample rate of 24 MHz. Statistics of the delivery time for the subscription service Prosys
Java implementation over Ethernet with Generic OS.

TABLE VII Execution Time 𝑇𝑠 [µs]

Statistics of the delivery time for the subscription service
Open62541 implementation over Ethernet with Generic OS. Without
CPU Isolation
CPU Isolation
Delivery Time [µs] Mean Std Mean Std
434.33 47.57 401.53 24.84
Without
CPU Isolation
CPU Isolation
Mean Std Mean Std
267.77 24.55 255.68 22.59
D. PubSub Communication Profile
The EPDF of the delivery time is shown in Fig. 9, whereas In a final experimental session we addressed the OPC UA
its statistics are provided in Table VII. Although an effective PubSub communication model. Currently, PubSub is only
comparison with the results of the read and write services supported by Open62541 and, although it provides all the
reported in Subsection V-B can not be done (the adopted mea- main methods, it is an experimental version still under heavy
surement techniques had to be necessarily different), it may be development. Similarly to the subscription services carried out
observed that the delivery time has, on average, lower values for Open62541, the server has been configured to publish a
than the task execution time of the read service. This can message every 100 ms. These messages were sent to a message
be explained considering that, with the subscription services, oriented middleware via UDP multicast transmissions using
a single message transmission by the server is sufficient to the UADP encoding. As for Open62541, we measured the
make the measured data available to the client. Conversely, delivery time as the difference between the generation of the
the jitter increases with respect to the read service for the two consecutive signal edges on the GPIO pins. The EPDF of
Open62541 implementation. For the same considerations made the delivery time and its statistics are reported respectively in
in Subsection V-B, we believe this is most likely due to the Fig. 11 and Table IX. Contrary to expectations, with the use
execution of unbounded kernel threads that may heavily impact of PubSub, there is a remarkable worsening of performance
on the behavior of the delivery time. As a final observation, with respect to the subscription services. Indeed both mean
the CPU isolation is beneficial also in this case. and jitter values increase considerably. This is an unexpected
Moving to the Prosys Java implementation, an analogous result, since the PubSub communication model has been
procedure to evaluate the delivery time could not be used, conceived to minimize protocol overhead and hence to reduce

0018-9456 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: Newcastle University. Downloaded on December 28,2020 at 05:10:13 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2020.3043116, IEEE
Transactions on Instrumentation and Measurement
9

·10−2 The adsorbed current was measured using a Hall effect sensor
2
Empirical PDF Without cpu isolation whose sensitivity is 185 mV/A. Current measurements have
1.5 With cpu isolation
been acquired using an external digital acquisition system
1
equipped with a 12 bit ADC with an input range of [0 , 3.3] V
0.5
at a sampling rate of 1 kHz. Each time the OPC UA test task
0
300 350 400 450 500 550 is started, the Raspberry Pi rises a signal triggering a new
𝑇𝑠 [µs] acquisition of the current level, which is also timestamped for
further analysis.
Fig. 11. EPDF of the pubsub transmission time for the Open62541 imple-
mentation on Ethernet with Generic OS. +
Power
the transmission times between publishers and subscribers. 5V RaspberryPi
Supply
Thus, there are not logical explanations of these outcomes. Current Sensor −
We suppose the problem is due to the fact that the PubSub
implementation of Open62541 is still under development.
Trigger
External ADC
TABLE IX
Statistics of the delivery time for the pubsub communication profile
over Ethernet with Generic OS.
Fig. 12. Setup adopted for current measurements.
Delivery Time 𝑇𝑠 [µs]
Without TABLE X
CPU Isolation
CPU Isolation Statistics of the current consumption with CPU governor disabled
and enabled.
Mean Std Mean Std
384.77 43.93 376.28 43.69
Current [A] Session completion
time [ms]
Mean Std Idle
E. Power Consumption
Governor Enabled 0.4175 0.0587 0.3928 235924
One of the main issues concerned with, possibly mobile, Governor Disabled 0.4767 0.0760 0.4462 215259
battery powered devices is the autonomy. Indeed, such devices
have to ensure a good level of performance for a given amount The results of this new set of experiments are summarized in
of time. To meet these requirements, modern processors are Table X, which reports the statistics of the current consumption
capable of Dynamic Voltage and Frequency Scaling (DVFS) to for the two cases in which the governor was, respectively,
minimize their power consumption and, consequently, extend enabled and disabled. The table also shows the current con-
the battery lifetime [29]. In the Raspberry PI boards used in sumption in idle state (i.e. while the experimental session was
the experimental setup, the DVFS functionality is driven by not carried out), for comparison.
a default kernel governor, called ondemand, that dynamically As can be seen, enabling the governor leads to a slight
adjusts the CPU frequency in agreement with the workload decrease of the current consumption, for both average and
variation. Specifically, if the workload exceeds a predefined standard deviation values. However, the time necessary to
threshold for a certain amount of time, then the governor complete the experimental session increases, by almost 10%,
increases the CPU operating frequency to its maximum value. as a result of the continuous CPU frequency adjustments
Conversely, if the workload is below the threshold, the operat- caused by the workload variations. Thus, at a first glance, it
ing frequency is switched to the lowest feasible one [30]. Such might not be worth to maintain the governor enabled, since
an approach, clearly, represents an optimal trade-off between the benefits achieved in term of power savings may result
performance and power consumption in a generic processing nullified by the performance degradation. However, a decision
system. in this direction has to take into consideration other aspects,
We carried out an analysis of the DVFS impact on both such as the specific devices adopted and the performance
power consumption and performance for the experimental requirements.
setup considered so far. The first tests have been performed A further observation can be made with respect to the
using the Open62541 stack, on the Wi-Fi configuration, with current consumption in idle state. Table X clearly shows only
the generic operating system and without CPU isolation using a limited increase of the current consumption, when moving
read/write services. In detail, we measured the current con- from this state to that in which experiments were executed,
sumption on the client side, as well as the time necessary regardless of the governor status (enabled or disabled). This
to complete the experimental session described in Subsection may be explained considering that Open62541 uses very low
V.B, that comprised the execution of 𝑁 = 100.000 OPC UA CPU resources that, evidently, are not sufficient to imply a
test tasks. remarkable variation in current consumption, as confirmed by
The circuit implemented for current measurement is de- the results presented in Table II.
scribed in Figure 12. The Raspberry Pi was powered by a Finally, we carried out additional tests for the subscrip-
stabilized power supply, providing a 5 V continuous voltage. tion service set and PubSub communication profile. In both

0018-9456 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: Newcastle University. Downloaded on December 28,2020 at 05:10:13 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2020.3043116, IEEE
Transactions on Instrumentation and Measurement
10

cases, we used we measured the power consumption for the [9] D. Bruckner, M.-P. Stanica, R. Blair, S. Schriegel, S. Kehrer, M. See-
Open62541 implementation, over Ethernet, with the governor wald, and T. Sauter, “An Introduction to OPC UA TSN for Industrial
Communication Systems,” Proc. IEEE, vol. 107, no. 6, pp. 1121–1131,
disabled. The analysis, actually, has not revealed any signifi- Jun. 2019.
cant change with respect to the former measurements. [10] International Electrotechnical Commission, IEC 62541: OPC unified
architecture - Part 1: Overview and concepts. IEC, 2016.
[11] M. Rizzi, P. Ferrari, A. Flammini, and E. Sisinni, “Evaluation of the IoT
VI. Conclusion and Future works LoRaWAN Solution for Distributed Measurement Applications,” IEEE
In this paper we considered the case of IIoT measurement Trans. Instrum. Meas., vol. 66, no. 12, pp. 3340–3349, Dec. 2017.
[12] H. Lee and K. Ke, “monitoring of large-area iot sensors using a lora
applications and proposed the adoption of OPC UA protocol to wireless mesh network system: Design and evaluation,” IEEE Trans.
enable a seamless interoperability when heterogeneous sources Instrum. Meas., no. 9, pp. 2177–2187.
of measurement data coexist sharing information over the net- [13] R. Palisetty and K. C. Ray, “FPGA Prototype and Real Time Analysis of
Multiuser Variable Rate CI-GO-OFDMA,” IEEE Trans. Instrum. Meas.,
work. We focused on four widespread implementations of the vol. 67, no. 3, pp. 538–546, Mar. 2018.
protocol, to analyze their impact on a networked measurement [14] V. Bianchi, A. Boni, S. Fortunati, M. Giannetto, M. Careri, and I. De
system, mostly in terms of latency and power consumption. Munari, “A Wi-Fi Cloud-Based Portable Potentiostat for Electrochemical
Biosensors,” IEEE Trans. Instrum. Meas., vol. 69, no. 6, pp. 3232–3240,
A reproducible and effective measurement setup has been Jun. 2020.
designed that allowed to carry out a thorough assessment, thus [15] Y. Liao and H. Lai, “Investigation of a Wireless Real-Time pH Monitor-
providing a rather complete characterization of OPC UA for ing System Based on Ruthenium Dioxide Membrane pH Sensor,” IEEE
Trans. Instrum. Meas., vol. 69, no. 2, pp. 479–487, Feb. 2020.
network-based measurement instrumentation systems. [16] J. Cavalaglio Camargo Molano, A. Lahrache, R. Rubini, and M. Coc-
Meaningful results have been obtained, allowing also to pro- concelli, “A new method for motion synchronization among multiven-
vide some interesting implementation guidelines. For instance, dor’s programmable controllers,” Measurement, vol. 126, pp. 202 – 214,
Oct. 2018.
it has been verified that the use of a real-time operating system [17] B. Montavon, M. Peterek, and R. Schmitt, “Model–based interfacing
does not bring specific advantages whereas, in general, the best of large–scale metrology instruments,” Proc. SPIE 11059, Multimodal
performances are achieved with a generic operating system Sensing: Technologies and Applications, 110590C, Jun. 2019.
[18] S. Lee, C. Kim, and J. Lee, “Development of a Smart Sensor System
exploiting the CPU isolation for the measurement application. Using OPC UA,” in Proc. MoMM, 2017, pp. 220–225.
Furthermore, in compliance with modern IIoT-based appli- [19] I. González, A. J. Calderón, A. J. Barragán, and J. M. Andújar,
cations, we considered the case of battery powered wireless “Integration of Sensors, Controllers and Instruments Using a Novel OPC
Architecture,” Sensors, vol. 17, no. 7, Jul. 2017.
measurement systems, thus providing some valuable insights [20] P. Ferrari, A. Flammini, S. Rinaldi, E. Sisinni, D. Maffei, and M. Malara,
about the expected power consumption in some selected and “Impact of Quality of Service on Cloud Based Industrial IoT Applica-
relevant cases. Indeed, the measurement campaign highlighted tions with OPC UA,” Electronics, vol. 7, no. 7, p. 109, Jul. 2018.
[21] A. Morato, S. Vitturi, F. Tramarin, and A. Cenedese, “Assessment of
that the DVFS feature should be enabled, allowing for lower Different OPC UA Industrial IoT solutions for Distributed Measurement
power consumption without compromising the performance. Applications,” in Proc. I2MTC, Dubrovnik, Croatia, 2020, pp. 1–6.
The current work opens up to future analysis. For instance, [22] M. Damm, S.-H. Leitner, and W. Mahnke, OPC Unified Architecture.
Springer-Verlag Berlin Heidelberg, 2009.
power consumption depends also on intrinsic parameters of the [23] H. Haskamp, M. Meyer, R. Möllmann, F. Orth, and A. W. Colombo,
accumulator and on environmental conditions, hence requiring “Benchmarking of existing OPC UA implementations for Industrie 4.0-
a more extensive experimental campaign focused on mobile compliant digitalization solutions,” in 2017 IEEE 15th International
Conference on Industrial Informatics (INDIN), 2017, pp. 589–594.
battery powered measurement instruments. In addition, the [24] “Arm Architecture Reference Manual Armv8, for Armv8-A architecture
proposed experimental setup for latency analysis seems to be profile”. Accessed: 2020-10-05. [Online]. Available: https://developer.
overkill for small integrated smart sensors. Hence, we plan arm.com/documentation/ddi0487/fb/
[25] L. Seno, F. Tramarin, and S. Vitturi, “Performance of Industrial Com-
to test the framework on low power embedded devices, like munication Systems - Real Application Contexts,” IEEE Ind. Electron.
widespread microcontrollers with no operating systems. Mag, vol. 6, no. 2, pp. 27–37, Jun. 2012.
[26] “Raspberry Pi: The N-queens Problem (benchmark)
References Preempt-RT vs. Standard Kernel”. Accessed: 2020-
10-05. [Online]. Available: https://lemariva.com/blog/2018/04/
[1] Y. Lu, “Industry 4.0: A survey on technologies, applications and open raspberry-pi-the-n-queens-problem-performance-test
research issues,” J. Ind. Inf. Integr., vol. 6, pp. 1–10, Jun. 2017. [27] F. Palm, S. Gruener, J. Pfrommer, M. Graube, and L. Urbas, “Open
[2] E. Sisinni, A. Saifullah, S. Han, U. Jennehag, and M. Gidlund, “Indus- source as enabler for OPC UA in industrial automation,” in Proc. ETFA,
trial internet of things: Challenges, opportunities, and directions,” IEEE Luxembourg, Luxembourg, 2015, pp. 1–6.
Trans. Industr. Inform., vol. 14, no. 11, pp. 4724–4734, Nov. 2018. [28] J. Pfrommer, “Semantic interoperability at big-data scale with the
[3] S. Vitturi, C. Zunino, and T. Sauter, “Industrial Communication Systems open62541 OPC UA implementation,” in Proc. Workshop Interoper-
and Their Future Challenges: Next-Generation Ethernet, IIoT, and 5G,” ability and Open-Source Solutions for the Internet of Things, Stuttgart,
Proc. IEEE, vol. 107, no. 6, pp. 944–961, Jun. 2019. Germany, 2016, pp. 173–185.
[4] D. Grimaldi and M. Marinov, “Distributed measurement systems,” [29] J. Howard, S. Dighe, S. R. Vangal, G. Ruhl, N. Borkar, S. Jain,
Measurement, vol. 30, no. 4, pp. 279–287, Dec. 2001. V. Erraguntla, M. Konow, M. Riepen, M. Gries, G. Droege, T. Lund-
[5] I. H. Witten, E. Frank, and M. A. Hall, Data Mining: Practical Machine Larsen, S. Steibl, S. Borkar, V. K. De, and R. Van Der Wijngaart, “A 48-
Learning Tools and Techniques, 3rd ed. Boston: Morgan Kaufmann, Core IA-32 Processor in 45 nm CMOS Using On-Die Message-Passing
2011. and DVFS for Performance and Power Scaling,” IEEE J. of Solid-St.
[6] G. Y. Tian, “Design and implementation of distributed measurement Circ., vol. 46, no. 1, pp. 173–183, Jan. 2011.
systems using fieldbus-based intelligent sensors,” IEEE Trans. Instrum. [30] M. P. Karpowicz, “Energy-efficient CPU frequency control for the Linux
Meas., vol. 50, no. 5, pp. 1197–1202, Oct. 2001. system,” Concurr. Comput., vol. 28, no. 2, pp. 420–437, Feb. 2016.
[7] L. Skrzypczak, D. Grimaldi, and R. Rak, “Analysis of the different
wireless transmission technologies in distributed measurement systems,”
in Proc. IDAACS, Rende, Italy, 2009, pp. 673–678.
[8] B. Ooi and S. Shirmohammadi, “The potential of IoT for instrumentation
and measurement,” IEEE Instrum. Meas. Mag., vol. 23, no. 3, pp. 21–26,
May 2020.

0018-9456 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: Newcastle University. Downloaded on December 28,2020 at 05:10:13 UTC from IEEE Xplore. Restrictions apply.