=Paper=
{{Paper
|id=Vol-3214/WS3Paper6
|storemode=property
|title=Collaboration in the Framework of the HUB4.0MNUVAL DIH for Innovation in Embedded OPC-UA IoT Systems
|pdfUrl=https://ceur-ws.org/Vol-3214/WS3Paper6.pdf
|volume=Vol-3214
|authors=Alberto Delgado,Francisco Blanes,José Simó
|dblpUrl=https://dblp.org/rec/conf/iesa/DelgadoBS22
}}
==Collaboration in the Framework of the HUB4.0MNUVAL DIH for Innovation in Embedded OPC-UA IoT Systems==
https://ceur-ws.org/Vol-3214/WS3Paper6.pdf
Collaboration in the Framework of the HUB4.0MNUVAL DIH for
Innovation in Embedded OPC-UA IoT Systems
Alberto Delgado 1, Francisco Blanes 1 and José Simó 1
1
Instituto Universitario de Automática e Informática Industrial, Universitat Politècnica de València, Camino
de Vera S/N, Valencia, 46022, Spain
Abstract
In the literature on DIH, there is a consensus around the services normally provided by a
competence center. All of them identified in the EC EDIH call, are not normally dealt with as
independent points, because they are part of a complex process where the Small and Medium
Enterprises (SME) and the competence center collaborate to produce an innovation. This
paper presents the solution adopted as a synergy of two entities, one industrial, the
engineering company Dismuntel S.A. and one academic, the Institute of Automation and
Industrial Informatics, as an improvement in interoperability and future projection of
developments for the connectivity of devices normally based on very specific protocols. The
solution includes using a communication bridge (ESP32) to implement an Open Platform
Communications Unified Architecture (OPC-UA) communication protocol by designing a
client/server program based on this distribution, improving data accessibility. This solution is
the result of close relations in the HUB4.0MANUVAL (DIH participant in SMART4ALL
project) ecosystem between SMEs and competence centers.
Keywords 1
Communication protocols, Internet of Things, OPC-UA, embedded systems.
1. Introduction
Dismuntel S.A. is a company in the engineering sector, in the field of electronics, an expert in
remote management and energy efficiency. Within this framework, it usually implements specific
project developments with very clearly defined communication protocols.
In a quest to add a greater future projection to the developments, this company promotes synergy
with the Institute of Automation and Industrial Informatics. Considering the current industry trends, it
is possible to understand the current trends influenced by the emergence of low-cost, low-power
hardware modules. With these new microcontrollers, System on a Chip (SoC), the developed
solutions will offer greater competitiveness and versatility within the market, thus expanding its scope
and projection.
The evolution of electronics towards smaller and smaller equipment, with more powerful features
and improvements in connectivity, gives new meaning to interoperability between devices, expanding
the possibilities of the Internet of Things (IoT) systems and environments. The interoperability and
interconnection of devices favor the flow of data and information between equipment that normally
does not have common communication protocols. In this paper, an attempt is made to solve this
problem by implementing the OPC-UA communication protocol in a hardware device used as a
bridge (Figure 1).
More specifically, it will address the solutions implemented to provide greater interoperability to a
generator set with its own data switchboard that has only one data output via the CAN communication
protocol [1].
Proceedings of the Workshop of I-ESA’22, March 23–24, 2022, Valencia, Spain
EMAIL: aldelro@ai2.upv.es (A. Delgado); pblanes@ai2.upv.es (F. Blanes); jsimo@disca.upv.es (J. Simó)
ORCID: 0000-0001-7314-5743 (A. Delgado); 0000-0002-9234-5377 (F. Blanes); 0000-0003-4677-7627 (J. Simó)
© 2022 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Wor
Pr
ks
hop
oceedi
ngs
ht
I
tp:
//
ceur
-
SSN1613-
ws
.or
0073
g
CEUR Workshop Proceedings (CEUR-WS.org)
Figure 1: Scheme of interoperability structure between equipment.
The interconnection bridge chosen was a low-cost, low-power microcontroller with high versatility
in terms of wireless connectivity, ESP32 manufactured by Espressif Systems [2]. In the specific case
of this work, the final-stage solution implemented (bridge-end client) based on the OPC-UA
communication protocol will be explained, offering the data to any client based on this type of
protocol.
2. Methods and protocols
The major advances in the fourth industrial revolution (i4.0) favor the development of new
possibilities for cooperation, particularly at the technical level. Communication between devices and
systems is essential to facilitate data exchange and transfer between equipment. Improvements in
communication in this type of environment do not require proximity between the devices to be
interconnected, which broadens the range of solutions to be implemented. However, this would not be
possible if there were no communication mechanisms with guaranteed security and interoperability
that would allow i4.0 active devices to operate beyond the physical limits of a plant.
Under these characteristics, OPC-UA appears as a fundamental pillar of the communication
standards within the i4.0 framework. This communication protocol, mainly used in automation fields,
is built on a client/server structure based on TCP/IP. Each OPC-UA client accesses the OPC-UA
server data through point-to-point communication with this one-to-one communication mechanism.
The OPC-UA client sends a request to the OPC-UA server and receives a response. The
communication between the two ends provides a secure, reliable, and encrypted data exchange
without data loss even in situations with unreliable net-work qualities. It is also vendor-independent
and open to any platform. This feature, together with its operation based on a simple Ethernet
network, makes this protocol an accessible and easy-to-implement option for any device.
About the development of this project, the final stage of communication establishes two extremes,
the hardware bridge as receiver of the data sent by the Gen-set and in charge of translating this data to
communication nomenclature of the OPC-UA protocol and acting as the OPC-UA server, and on the
other hand an OPC-UA end client in charge of monitoring and controlling the operation of the
Genset.
For the implementation of this protocol in the chosen hardware bridge, ESP32, open distribution of
this protocol, written in C99, open62541 [3], has been used, more specifically, an adaptation of this
implementation developed to be fully dedicated to this microcontroller. This library is available on
GitHub where it is periodically reviewed and updated about the updates incorporated in the general
implementation (open62541) [4].
3. Implementation
3.1. Hardware configuration
Before starting with the software implementation and design, it is necessary to define and
configure the hardware parameters of the bridge. As previously mentioned, the hardware chosen is an
ESP32 microcontroller (Figure 2), more specifically the ESP32-Wroover, with an 8MB flash memory
to which an Ethernet module will be attached to provide much greater reliability in terms of
connectivity. Also, the board has a CAN driver to establish the communication between the Generator
and the bridge.
Figure 2: Hardware assembly for the implementation of the solution.
Considering the OPC-UA protocol implementation that will be used for the program design and
that it is not specifically designed to be executed in this type of microcontrollers, it will be necessary
to enable the external RAM memory option, equipped in the 4MB Wroover version of this SoC.
3.1.1. Software development
Focused on the needs that the company would cover with this development, we began to the
establish parameters and methodology of the software solution.
First of all, is the consideration of all data and its organizational structure. As discussed in section
1, the data comes from an electrical generator. A total of 439 variables of different types of data
grouped in 7 different blocks need to be processed. Based on these characteristics, two different
clustering tests were performed:
A. Generation of one object for each group (7 in total) with array sub-nodes of variable length
according to type and amount of data
This first data grouping structure allows it to correspond as much as possible to the original
structure established by the genset, but the fact that the arrays are not complete (size of 255) prevents
the memory management from being fully optimal since the empty memory gaps accumulate and the
memory release is not as efficient as it should be, resulting in small losses that in the long term could
col-lapse the SoC memory. This structure is easier to understand looking at the schema shown in
Figure 3:
Figure 3: The first option for the data structure scheme in the OPC-UA Server.
B. Generation of a single object with one sub-node for each group (7 in total), with arrays of
maximum length (255)
Of the 7 sub-nodes defined within the single object, six of them have the same characteristics,
UInt32 type array with a size of 255 positions, in order not to leave memory spaces without variable
allocation.
The last sub-node will be defined as a Boolean array with a size of 255 positions, since this block
will have read/write permissions, thus allowing the direct control of the electric generator variables.
This data structure can be seen more graphically below in Figure 4.
Figure 4: The second option is for the data structure scheme in the OPC-UA Server.
The advantages of this type of structural organization of the data in the OPC-UA server allow a
remarkable improvement in the memory management of the SoC, as it has been possible to verify
with memory load tests which will be explained in section 4.
4. Results
The development of two different code solutions for data grouping has made it possible to study
which of the two solutions is optimum in terms of performance and memory consumption to be
implemented as the final solution in a microcontroller in which memory management is key for
correct operation over time. For this purpose, several functional tests have been performed in which
information about the memory status of the microcontroller has been extracted.
To test both developments, an OPC-UA client (UA Expert [5]) has been used to make random data
requests to the server, as well as to modify parameters in the write sub-node for the modification of
the Genset control parameters. For both tests, the same operating conditions were considered.
The first distribution of data. Seven different objects with sub-nodes of variable length.
In Figure 5, we can observe the available RAM versus the program cycles, directly related to the
running time of the application. At the beginning of the test, there is a sharp drop in the available
memory, which then smooths out until 20 hours of operation, at which point there is a recovery and
subsequent smooth drop again. This recovery cycle will be repeated approximately every 20 hours of
operation ensuring certain stability in the running of the application.
Figure 5: Graph with the representation of available RAM of the SoC for the first option of data
structuring.
The second distribution of data. Just one object with seven different sub-nodes of regular length
(255).
In the second test performed, the graph represents the same data as in the first test (Figure 6). From
the beginning, a stabilization in the available RAM memory line can be observed, which remains
constant during the entire test. There are some irregularities and decreases in memory every 5000
program cycles or so, but there is also an immediate recovery of this memory.
Figure 6: Graph with the representation of available RAM of the SoC for the second option of data
structuring.
After studying these load test results and looking for a higher scalability of the solution, the second
configuration of the data structure is chosen. With this configuration, the solution is validated in real
conditions. As can be seen in Figure 7, the control module of the generator set in charge of generating
all the data (print-ed circuits at the top of the image) is extracted. At the bottom of the image is the
assembly of the communication bridge with the ESP32, with the Ethernet module for its connection to
the network and a controller module for receiving the, CAN frames from the generator control
module.
Figure 7: Image of the model used for testing in a real environment.
The bridge assembly itself will act as an OPC-UA Server and, using a computer with the indicated
software to make the OPC-UA client requests, it will be possible to monitor the data and control some
of them. With this assembly, it is possible to perform a battery of tests to check the correct global
operation during a longer period as well as tests to check the correct operation of the disconnection
protocols and their corresponding reconnections.
5. Discussion
The cooperation between centers of different natures such as a business entity and an academic
organization in the search for a solution to the problem of connectivity between different equipment
has generated a beneficial synergy for both parties.
On the one hand, the academic organization has been able to access a real problem existing
nowadays in the plants, such as the diversity in the communication protocols and the problems in
facilitating the data flow that this generates.
On the other hand, the business entity has benefited from obtaining a versatile solution with many
more capabilities in the future-focused on the universality of communications, which will allow this
solution to be scaled in the future and adapted to the different needs that arise in real industrial
environments.
6. Acknowledgements
SMART4ALL [6] has received funding from the European Union’s Horizon 2020 research and
innovation program under Grant Agreement No 872614. We thank the reviewers for their detailed and
insightful feedback to improve this document.
7. References
[1] CAN communication Protocol, 2022. URL: https://www.ti.com/lit/an/sloa101b/sloa101b.pdf
[2] ESP32 Wi-Fi & Bluetooth MCU I Espressif Systems, 2022. URL:
https://www.espressif.com/en/products/socs/esp32.
[3] Open62541: an open source implementation of OPC UA, 2022. URL: https://open62541.org/.
[4] S. Profanter, OPC UA on a ESP32 Microcontroller, 2021. URL:
https://github.com/Pro/open62541-esp32.
[5] UaExpert, UA Reference Client’ - Unified Automation, 2022. URL: https://www.unified-
automation.com/products/development-tools/uaexpert.html.
[6] SMART4ALL, Home, 2022. URL: https://smart4all-project.eu/.