Improving Industrial Interoperability and Scalability Through OPC-UA

and Smart Object-Based Architectures

Guilherme Coelho

, Liliana Ant

1 a

, Beatriz Coutinho

1 b

, Gil Gonc¸alves

1 c

Ant

onio Augusto

and Miguel Moura

SYSTEC ARISE, Faculdade de Engenharia, Universidade do Porto, Rua Dr. Roberto Frias, 4200-465 Porto, Portugal

Idepa - Ind

ustria de Passamanarias, Lda, Portugal

Keywords:

OPC-UA, Industry 4.0, Smart Object, Data Model.

Abstract:

This paper presents the development and implementation of a remote monitoring and control system for indus-

trial machines, aligned with the principles of Industry 4.0. The proposed solution builds under the Advanced4i

work package of the PRODUTECH R3 initiative, addressing key limitations in industrial digitalization scala-

bility, responsiveness, and usability. A redesigned architecture is introduced, build upon a previous data model

and architecture by Neto et al., featuring advanced communication protocols, a refactored LabVIEW-based in-

terface, and a middleware layer to enhance data ﬂow and synchronization. A structured data model and an

optimized graphical user interface further enable real-time monitoring and remote conﬁguration. The system

was validated in a real-world deployment at IDEPA, a real manufacturing company a leader in the labels,

tapes, and textile accessories markets , integrating over 30 sensors, and subsequently scaled to support up to

85 sensors with minimal data loss and high responsiveness under operational stress. The results demonstrate

capability of maintaining monitoring performance and scalability, offering a practical roadmap for the deploy-

ment of interoperable and modular Industry 4.0 solutions in manufacturing environments.

1 INTRODUCTION

Industry 4.0 has transformed manufacturing through

digitalization, real-time data exchange, and intelli-

gent automation. A core requirement of this shift is

the ability to remotely monitor and control machin-

ery to optimize processes, reduce costs, and improve

efﬁciency. However, many current solutions strug-

gle with scalability and usability in complex, hetero-

geneous environments (Pisching et al., 2018; Boyes

et al., 2018; Danys et al., 2022).

To address these challenges, the Reference Ar-

chitecture Model for Industry 4.0 (RAMI 4.0) pro-

vides a structured framework for designing and de-

ploying Industry 4.0 systems. By combining product

lifecycles, hierarchy levels, data types, and technol-

ogy layers into a multidimensional Service-Oriented

Architecture(SOA), RAMI 4.0 enables consistent

modeling and analysis of smart manufacturing sys-

tems (Pisching et al., 2018; Morgan et al., 2021).

https://orcid.org/0000-0002-2903-0989

https://orcid.org/0009-0000-9769-6726

https://orcid.org/0000-0001-7757-7308

Furthermore, the inclusion of the Asset Adminis-

tration Shell (AAS) within the RAMI 4.0 framework

signiﬁcantly enhances its practical relevance. The

AAS serves as the ”digital twin” of physical assets,

enabling standardized data management and interop-

erability across diverse industrial platforms (Pisching

et al., 2018).

This paper presents a scalable and modular sys-

tem architecture aligned with RAMI 4.0 principles,

designed to enhance remote monitoring, conﬁgurabil-

ity, and real-time diagnostics in industrial automation.

The proposed solution emphasizes fault isolation, dy-

namic reconﬁguration, and integration with existing

OPC Uniﬁed Architecture (OPC UA) infrastructures,

addressing key limitations of current monitoring sys-

tems. Furthermore, it contrasts the proposed design

with the architecture previously implemented in (Neto

et al., 2019), highlighting key differences such as the

introduction of a middleware layer and modiﬁcations

to the LabView environment.

Coelho, G., Antão, L., Coutinho, B., Gonçalves, G., Augusto, A. and Moura, M.

Improving Industrial Interoperability and Scalability Through OPC-UA and Smart Object-Based Architectures.

DOI: 10.5220/0013802900003982

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 22nd International Conference on Informatics in Control, Automation and Robotics (ICINCO 2025) - Volume 2, pages 457-468

ISBN: 978-989-758-770-2; ISSN: 2184-2809

457

1.1 Advanced 4I PRODUTECH-R3

Project

This work was carried out within the framework of an

existing work package known as Advanced4i, which

is a part of a larger project called PRODUTECH R3

– Recovery-Resilience-Reindustrialization, a Mobi-

lizing Agenda of Production Technologies for Rein-

dustrialization. Advance4i aims to strengthen the na-

tional industry’s ability to compete in an increasingly

demanding market in terms of sustainability while re-

ducing energy and operating costs. Given the Euro-

pean Union’s sustainability targets, it is necessary to

integrate solutions based on IoT (Internet of Things),

predictive maintenance, and energy efﬁciency tech-

nologies. Energy efﬁciency, which is often neglected

in poorly digitized industrial environments, suffers

from a lack of visibility of the associated costs. Ad-

vance4i aims to reverse this reality by providing trans-

parency on energy consumption at different levels,

from production lines to speciﬁc equipment and pro-

cesses. Speciﬁcally, this paper will focus on adapting

the basis of the digitalization architecture deﬁned.

1.2 Smart Box

This work builds upon a foundational Industry 4.0

aligned project focused on digitalizing factory oper-

ations to improve monitoring, control, and efﬁciency.

The initial implementation at IDEPA a leading man-

ufacturer of labels, tapes, and textile accessories in-

volved the integration of approximately 30 sensors.

While successful, the current LabVIEW based solu-

tion faces challenges related to scalability, reliability

under load, and user accessibility. These limitations,

including data loss and system instability, highlight

the need for a more robust and user-friendly architec-

ture. This Section reviews the existing implementa-

tion, identiﬁes its shortcomings, and outlines poten-

tial improvements.

The Smart Box and its related components, shown

in Fig. 1, integrates an OPC-UA server, a LabVIEW

application, and a Backofﬁce system, deployed on a

CompactRIO 9040 industrial computer. This archi-

tecture aimed to enable real-time data exchange and

control within a factory environment through Smart

Object Self Descriptor (SOSD) based conﬁguration.

1.3 Smart Object

The Smart Object, also referred to as the Smart Ob-

ject Self Descriptor (SOSD), is a comprehensive data

model designed to encapsulate the complete set of

system-level information relevant to a given industrial

component. As a digital abstraction, the SOSD em-

bodies the essential characteristics of the Component

4.0 Paradigm, a foundational concept within the Ref-

erence Architectural Model for Industry 4.0 (RAMI

4.0) framework. This alignment ensures robust com-

pliance with key principles of Industry 4.0, particu-

larly those related to interoperability, modularity, and

decentralized control (Neto et al., 2020).

The Smart Object model is not merely a static de-

scriptor, but an active, semantically rich representa-

tion of both the internal conﬁguration of a compo-

nent and its dynamic relationships with other entities

within the system. By explicitly modeling structural,

functional, and behavioral aspects, the SOSD enables

seamless integration into Industry 4.0-compliant en-

vironments.

In the context of this work, the SOSD serves as the

foundational construct for the proposed data model.

It facilitates a uniﬁed description of system compo-

nents, allowing for enhanced system-level orchestra-

tion and intelligent decision-making. The adoption of

this model is instrumental in achieving higher degrees

of automation, resilience, and scalability in industrial

production systems.

2 RELATED WORK

To address the identiﬁed problems, research was con-

ducted to evaluate existing industrial solutions and ex-

plore potential technologies that could complement or

replace the current system. The investigation began

with an analysis of the Industry 4.0 paradigm to un-

derstand its relevance and requirements. This was fol-

lowed by a study of alternative communication proto-

cols and a deeper examination of the advantages and

limitations of the OPC-UA protocol that is currently

under use.

The digital transformation of industrial sectors has

been an increasingly prominent topic of academic and

industrial discussion. Several works have explored

the intersection between industrialization and digital-

ization, highlighting the pervasive impact of emerging

technologies across different sectors.

In particular, the work in (Neto et al., 2019) em-

ploys the same data Modeling approach as this study,

this being the Smart Object Self Descriptor (SOSD).

Their research validates the relevance and applicabil-

ity of the chosen methods in analyzing digital trans-

formation trends. The reuse of these approaches,

along with their consistent ﬁndings, demonstrates that

this topic has already received considerable attention

in the literature.

Moreover, other studies such as (Neto et al., 2020)

ICINCO 2025 - 22nd International Conference on Informatics in Control, Automation and Robotics

458

Figure 1: Smart Box and related components.

provide a broader perspective on the digitalization and

industrialization of various industries. These works

focus on the structural and operational shifts driven by

digital technologies, particularly in traditionally non-

digital sectors.

For instance, one paper speciﬁcally addresses the

food industry and its ongoing industrial transforma-

tion (Demartini et al., 2018). It highlights how digital

technologies are not conﬁned to sectors such as tex-

tiles but are also being rapidly adopted in the food

sector. The paper also analyzes the number of publi-

cations over time, underscoring the growing academic

interest and the emergence of this topic in diverse sec-

tors of industry.

Another relevant contribution is the study focused

on industrialization within the broader economic sec-

tor (Zhang and Li, 2023). Similar to the aforemen-

tioned works, it discusses the rising imperative for

digitalization across all industrial domains. This work

reinforces the notion that digital transformation is not

an isolated phenomenon, but rather a global necessity

affecting all branches of the industrial economy.

A particularly comprehensive study is offered in

(Bauer et al., 2018), which evaluates over 385 In-

dustry 4.0 use cases across German industrial sec-

tors. This large-scale review categorizes applications

based on their technological maturity—namely, infor-

mation, interaction, and intelligence—and sheds light

on real-world deployment of digital solutions in do-

mains such as production, logistics, engineering, and

services. The ﬁndings show that while the majority

of applications are still in the “information” phase

(data availability and transparency), there is a sig-

niﬁcant trend toward integrating interaction-level and

intelligence-level systems that support real-time re-

sponsiveness and autonomous decision-making. The

study also emphasizes human-centric approaches, un-

derlining the importance of Human-Technology Inter-

action and the evolving role of workers in digitalized

environments. These insights are crucial in framing

digital transformation not only as a technical upgrade

but also as a sociotechnical evolution that involves

new models of cooperation, substitution, and collab-

oration between humans and machines.

Together, these studies provide a comprehensive

overview of ongoing efforts to understand and support

digital transformation in industrial contexts. They

collectively emphasize the strategic importance of in-

tegrating digital technologies to enhance productiv-

ity, efﬁciency, and innovation across various indus-

trial sectors.

Improving Industrial Interoperability and Scalability Through OPC-UA and Smart Object-Based Architectures

459

Figure 2: Proposed System architecture.

3 IMPLEMENTATION

In the proposed solution all the modules of the sys-

tem were subject to change, retaining core functional-

ity while improving system robustness and scalability.

The updated design is shown in Figure 2.

A major architectural improvement is the middle-

ware layer, which decouples system components and

mitigates previous instability issues. This facilitates

modularity, scalability, and easier maintenance. Con-

sequently, a custom middleware was implemented to

ensure efﬁcient synchronization and information ﬂow,

maintaining system coherence and reliability. The

middleware’s design and functional beneﬁts are de-

tailed in the following sections.

A reﬁned control and data acquisition system was

developed for the IDEPA factory ﬂoor using a Com-

pactRIO 9040, serving as a local industrial controller

interfacing directly with factory-ﬂoor machines and

sensors. This unit enables real-time monitoring and

control, hosts the LabVIEW-based logic, and inte-

grates an OPC-UA server that exposes sensor data

in accordance with the Industry 4.0 (I4.0) component

model for standardized communication.

3.1 Data Model

The SOSD model facilitates the transformation of

physical assets such as machines, sensors, and actu-

ators into digital entities that are accessible via the

OPC-UA network. As a digital representation of

Component 4.0, SOSD enables the modeling of com-

plex industrial environments by providing a ﬂexible

and standardized framework to deﬁne attributes, be-

haviors, and interrelationships among various manu-

facturing components (Neto et al., 2020)(Torres et al.,

2022).

The SOSD Architecture can be seen in the follow-

ing Figure 3, where we can see all the components

and relationships that compose the model.

The device Set shown in the Figure 3 is composed

by equipments and Sensors, which represent 2 differ-

ent types of data. The Equipments have a descrip-

tion and a collection of Sensors equipments. The Sen-

sor type of data represents a digitalization of the fac-

tory ﬂoor Sensor, with all its variables and subscribed

equipment. This data model is written in modeled Ex-

tensible Markup Language (XML).

ICINCO 2025 - 22nd International Conference on Informatics in Control, Automation and Robotics

460

Figure 3: SOSD Architecture.

3.2 OPC-UA Server

The OPC-UA server exposes factory data through a

structured Smart Object Self Descriptor (SOSD) rep-

resented in XML format. This serves as the basis for

dynamically generating data pipelines and mapping

them to a dedicated namespace. The exposed data

is also accessible through standard tools such as the

Prosys OPC-UA Viewer, facilitating monitoring and

validation of system behavior.

Building upon the existing OPC-UA server infras-

tructure, several enhancements were introduced to ex-

tend its functionality and improve operational robust-

ness. The pipeline creation process was systemati-

cally restructured to streamline operations, reducing

initialization latency and improving overall startup ef-

ﬁciency. Additionally, a graceful shutdown mecha-

nism was implemented to enable autonomous and re-

liable termination of the server process without re-

quiring manual intervention, thereby supporting bet-

ter integration in automated environments.

To further enhance system interoperability, a ﬁle-

based handshake protocol was introduced to synchro-

nize the OPC-UA server with the LabVIEW interface

during startup. This coordination mechanism effec-

tively mitigates race conditions and ensures temporal

alignment between components

3.3 Data Acquisition Program

The LabVIEW program operates as the core data ac-

quisition and preprocessing service within the system

architecture. It interfaces with the Modbus communi-

cation bus to retrieve real-time sensor and equipment

data, processes the acquired values, and subsequently

transmits them through the data pipelines provisioned

by the OPC-UA server. During initialization, the Lab-

VIEW application parses the SOSD XML ﬁle to iden-

tify and conﬁgure the relevant Modbus registers and

associated IP addresses. This ﬁle is transformed into

a structured representation of devices, enabling sys-

tematic access to the underlying industrial assets.

To enhance the system’s modularity, scalability,

and performance, several architectural improvements

were introduced to the LabVIEW implementation.

The XML parsing logic was refactored to decouple

equipment and sensor deﬁnitions into two distinct

data structures. This abstraction promotes cleaner

code organization and facilitates future extensibility.

To ensure reliable coordination with the OPC-UA

server, a ﬁle-based synchronization protocol was im-

plemented. This mechanism enforces a startup depen-

dency, ensuring that LabVIEW initiates communica-

tion only after the OPC-UA server is fully operational,

thereby eliminating race conditions.

The most signiﬁcant advancement lies in the re-

design of the data acquisition loop to support parallel

execution. Each equipment unit is managed within its

own dedicated thread, and sensor polling is handled

independently, allowing for concurrent Modbus in-

teractions. This multithreaded approach signiﬁcantly

improves the system’s responsiveness and fault toler-

ance—ensuring that communication failures with in-

dividual sensors do not propagate through the acqui-

sition cycle. While the transition to parallelism in-

troduces higher CPU load, it also opens opportunities

for hardware-speciﬁc optimizations to balance perfor-

mance and resource utilization.

3.4 Middleware Component

A dedicated middleware was developed to coordinate

LabVIEW and the OPC-UA server. Beyond manag-

ing synchronization, it validates Modbus conﬁgura-

tions and logs channel availability. These diagnos-

tics are exposed to the Backofﬁce interface, provid-

ing operators with real-time feedback on sensor sta-

tus. The middleware also handles server lifecycle

management, including shutdown commands, ensur-

ing that system components remain decoupled and in-

dependently manageable.

3.5 Industrial Backofﬁce

Finally, an integral component of the system archi-

tecture is the Backofﬁce, a locally hosted web ap-

plication that provides a graphical interface for real-

time system interaction and oversight. Designed as

a lightweight yet extensible control layer, the Back-

ofﬁce facilitates secure, remote access to the SOSD

Improving Industrial Interoperability and Scalability Through OPC-UA and Smart Object-Based Architectures

461

XML conﬁguration ﬁle through a browser-based in-

terface. Authorized personnel can inspect, modify,

and manage system conﬁgurations without interrupt-

ing ongoing data acquisition, enabling continuous

system operation and reducing maintenance down-

time.

To extend its utility and align with the overall

goals of system modularity and observability, the

Backofﬁce interface underwent a series of enhance-

ments. The graphical user interface (GUI) was aug-

mented to support full visibility into system compo-

nents, including detailed information on Modbus con-

ﬁgurations, sensor to equipment mappings, and OPC-

UA pipeline statuses. This extended view provides

maintainers with granular insights necessary for sys-

tem diagnostics and performance tuning.

Built on a modern web stack, the updated Back-

ofﬁce allows interactive manipulation of the XML-

based SOSD model. Equipment and sensor entities

can be added, removed, or edited through the inter-

face without requiring direct modiﬁcation of the Lab-

VIEW application or server-side code. These updates

are retained persistently and applied during the next

system restart, during which the OPC-UA server re-

registers all updated elements based on the revised

conﬁguration. Furthermore, in-place XML editing,

element reordering, and backup creation capabilities

have been added to improve usability and conﬁgura-

tion traceability.

To support runtime transparency, middleware-

generated diagnostics—such as sensor connectiv-

ity status, polling errors, and synchronization re-

ports—are now integrated into the Backofﬁce dash-

board. This provides operators with real-time feed-

back on system health and aids in rapid identiﬁcation

of faults.

These advancements reﬂect a broader effort to el-

evate the system’s architectural maturity. Improve-

ments to the Backofﬁce were developed in conjunc-

tion with enhancements to other subsystems, includ-

ing the modularization of the LabVIEW interface, re-

structuring of the XML schema, increased OPC-UA

reliability, and the introduction of a middleware layer

to orchestrate inter-component synchronization. Col-

lectively, these improvements foster greater scalabil-

ity, resilience, and user-centric control within the In-

dustry 4.0-compliant system.

4 TESTING AND RESULTS

This section presents the evaluation outcomes of the

proposed industrial monitoring system, with empha-

sis on scalability, stability, efﬁciency, and practi-

cal deployment, particularly in environments like the

IDEPA factory ﬂoor.

To assess the scalability and effectiveness of the

proposed architecture, a comprehensive test suite was

designed to replicate a range of industrial scenarios

typical of the IDEPA factory ﬂoor. Each test was ex-

ecuted on both the previous and proposed system ar-

chitectures to allow direct performance comparison.

Five representative operational scenarios were de-

ﬁned to emulate varying levels of system complexity:

• Low Complexity: 2 equipments with 2 sensors

each.

• Medium Complexity (Baseline): 3 equipments

with 5 sensors each.

• High Complexity: 3 equipments with 10 sensors

each.

• Stress Test: Maximum load using 6 equipments

with 10 sensors and high acquisition frequency.

• Centralized Deployment: All sensors connected

to a single equipment, compared against the dis-

tributed conﬁguration.

Each scenario was run under multiple sampling

rates (2s, 1s, 0.5s) to measure responsiveness and re-

liability under dynamic conditions.

Tests were conducted using a CompactRIO 9040

with NI Linux Real-Time OS, replicating the de-

ployed environment at IDEPA. Sensors aggregate into

logical equipments, sending data via an Ethernet

switch to the Smart Box. Varying key system param-

eters helped simulate realistic operating conditions:

• Equipments: 2 to 6

• Sensors/Equipment: 2 to 10

• Acquisition Rate: 2s to 0.5s

The summary of all test conﬁgurations is shown

in Table 1.

Table 1: Summary of Test Cases and Conﬁguration Param-

eters.

Test ID Complexity Level Equip. Sensors Rate (s)

1 Medium 3 5 2

1.1 Medium - centralized 3 5 2

2 Medium 3 5 1

3 Medium 3 5 0.5

4 Low 2 2 2

4.1 Low - centralized 2 2 2

5 Low 2 2 1

6 Low 2 2 0.5

7 High 3 10 2

7.1 High - centralized 3 10 2

8 High 3 10 1

9 High 3 10 0.5

10 Extreme 6 10 2

ICINCO 2025 - 22nd International Conference on Informatics in Control, Automation and Robotics

462

To objectively assess system performance and en-

sure comparability between the two architectures, a

set of quantitative metrics was deﬁned:

• OPC UA Server Setup Time: Time to initialize

and expose the full server namespace, measured

via server stdout timestamps.

• CPU Utilization: Average and peak processor

load during runtime, indicating computational ef-

ﬁciency.

• RAM Usage: Memory footprint during opera-

tion, collected via a Python script for later anal-

ysis.

• System Stability: Frequency of runtime errors,

data loss, or crashes, assessed from test logs.

• Jitter: Variability between sensor acquisition and

OPC UA node updates, measured and analyzed by

data collection done with Python.

4.1 Baseline Evaluation: Tests 1–3

To establish a reliable foundation for subsequent eval-

uations, a baseline test was executed. This comprises

three distinct tests using a setup consisting of three

equipment units, each with ﬁve sensors, for a total of

ﬁfteen sensor data streams. Each test scenario eval-

uated both the sequential and the proposed (multi-

threaded) data acquisition architectures under increas-

ing levels of data acquisition frequency. These tests

were designed to provide insight into system behav-

ior in terms of CPU and RAM utilization, data ac-

quisition latency (measured as jitter), and operational

responsiveness (startup time).

All test scenarios were run for a duration of ap-

proximately 10 minutes, during which relevant per-

formance data was captured for comparative analysis.

Test 1: Low-Frequency Acquisition (2 Seconds)

Test 1 evaluated system performance at a 2-second ac-

quisition interval, representing a low-stress baseline.

Table 2 summarizes CPU, RAM, and jitter metrics for

both architectures.

Table 2: Comparison of Test 1: 2s Acquisition Interval.

Metric Sequential New

CPU Usage Max (%) 99.00 100.00

CPU Usage Avg (%) 8.90 8.16

RAM Usage Avg (%) 33.64 36.20

Jitter Avg. (s) 0.1845 0.0759

The new architecture matches the sequential sys-

tem’s CPU and RAM usage despite its multithreaded

design, while achieving signiﬁcantly lower jitter, in-

dicating improved timing consistency. Figures 4 and

5 illustrate resource usage over time, highlighting re-

duced initialization overhead and smoother operation

in the new solution.

Figure 4: CPU and RAM Usage Over Time — Sequential

Architecture (Test 1).

Figure 5: CPU and RAM Usage Over Time — New Archi-

tecture (Test 1).

Conclusions:

• Both architectures show similar resource usage.

• The new architecture signiﬁcantly reduces jitter.

• System responsiveness improves with the new de-

sign.

Test 2: Medium-Frequency Acquisition (1

Second)

At a 1-second interval, both systems exhibited slightly

increased CPU and RAM usage (Table 3), with the

new architecture maintaining lower jitter.

Table 3: Performance Metrics for Test 2: 1s Acquisition

Interval.

Metric Sequential New

CPU Usage Avg (%) 10.76 9.94

RAM Usage Avg (%) 37.48 37.80

Jitter Avg. (s) 0.1663 0.0505

Resource usage trends are consistent with Test 1.

The new architecture sustains better timing precision,

Improving Industrial Interoperability and Scalability Through OPC-UA and Smart Object-Based Architectures

463

with over 50% jitter reduction. The behavior similar-

ity is evident in Figures 6 and 7.

Figure 6: CPU and RAM Usage Over Time — sequential

Architecture (Test 2).

Figure 7: CPU and RAM Usage Over Time — New Archi-

tecture (Test 2).

Test 3: High-Frequency Acquisition (0.5 Seconds)

At 0.5 seconds per sample, CPU usage nearly doubled

(averaging 16.04% sequential, 14.75% new), with

RAM usage stable. The new architecture maintained

superior jitter performance, demonstrating scalability

under high load (full results omitted for brevity).

Summary for Tests 1–3:

• The new architecture consistently reduces jitter,

enhancing timing accuracy.

• Multithreading did not increase resource con-

sumption signiﬁcantly.

• Faster initialization and responsiveness favor the

new design.

4.2 Evaluation of Low Complexity

Scenarios: Tests 4–6

This subsection presents the results and analysis of

Tests 4, 5, and 6, which evaluate system behavior

under low-complexity conﬁgurations involving two

pieces of equipment, two sensors, and increasing data

acquisition frequencies. The tests were conducted, as

mentioned before, on a CompactRIO (cRIO) device.

Both the sequential and the newly proposed architec-

tures were assessed for comparison.

Performance Results for Test 4

Table 4: Comparison of Test 4: 2 Equipment, 2 Sensors, 2s

Acquisition Interval.

Metric

Sequential

Solution

Proposed

Solution

CPU Usage Max (%) 98.50 99.00

CPU Usage Avg (%) 12.74 10.48

CPU Usage Min (%) 1.50 2.00

RAM Usage Max (%) 32.30 32.90

RAM Usage Avg (%) 30.59 29.87

RAM Usage Min (%) 18.80 17.80

Jitter Equipment 1 (s) 0.2021 0.1892

Jitter Equipment 2 (s) 0.1530 0.1476

The results indicate that both architectures deliver

similar jitter performance, with the proposed solution

slightly outperforming the sequential system, as per

the baseline scenarios. This improvement is likely

due to the parallelization employed in the new ar-

chitecture, contrasting with the serialized approach of

the sequential implementation. RAM usage remains

comparable, and small differences are attributed to

background system processes and runtime variability.

Results for Tests 5 and 6

These tests conﬁrm that both solutions scale effec-

tively with increased data acquisition frequencies in

low-complexity scenarios. CPU usage increases pro-

portionally, as expected, while RAM usage remains

stable across both implementations. The jitter re-

mains within acceptable limits, with the proposed ar-

chitecture again achieving slightly better performance

due to its parallel execution model.

Conclusions About Tests 4-6

Two primary conclusions can be drawn from these

tests:

• Both the sequential and proposed architectures

demonstrate similar performance in terms of av-

erage CPU and RAM usage, with consistent peak

activity.

• The proposed architecture offers a signiﬁcant re-

duction in startup time for data acquisition, ap-

proximately 45 seconds faster, achieving im-

proved responsiveness without compromising re-

source efﬁciency.

These results validate the capability of both sys-

tems to handle low-complexity data acquisition sce-

ICINCO 2025 - 22nd International Conference on Informatics in Control, Automation and Robotics

464

narios effectively. However, the proposed architec-

ture presents clear advantages in startup latency and

jitter optimization, thereby laying the groundwork for

superior scalability in more complex environments.

Test 7: Baseline High Complexity Conﬁguration

In this test, both the previous and proposed architec-

tures were evaluated under the same conﬁguration.

The proposed architecture demonstrated reliable per-

formance, successfully collecting and displaying data

from all 30 sensors with minimal network latency. In

contrast, the sequential solution encountered signiﬁ-

cant limitations. Due to the absence of a handshake

mechanism between the OPC-UA server and the Lab-

VIEW interface, the system lacked the ability to op-

timize server setup. This resulted in system failure

during initialization, a previously mentioned limita-

tion where the solution could not handle more than

20 sensors.

Resource usage data for the proposed solution dur-

ing Test 7 is summarized below:

Table 5: Performance Metrics for Test 7.

Metric Value

CPU Usage Max (%) 100.00

CPU Usage Avg (%) 12.79

CPU Usage Min (%) 0.00

RAM Usage Max (%) 45.30

RAM Usage Avg (%) 42.87

RAM Usage Min (%) 20.70

Jitter analysis was also performed, with average

jitter values recorded as follows:

• Equipment 1: 0.071164 seconds

• Equipment 2: 0.094439 seconds

• Equipment 3: 0.082088 seconds

These results show that, although the resource

consumption was higher than in prior tests, the sys-

tem operated within acceptable thresholds. Jitter re-

mained stable, suggesting the network was not over-

loaded despite the increased sensor count.

Tests 8 and 9: Increased Acquisition Frequency

Tests 8 and 9 involved gradually increasing the data

acquisition frequency. At a 1-second interval, the

system remained stable and efﬁcient, showing only

marginal increases in CPU, RAM usage, and decrease

in jitter. However, when the acquisition frequency

was increased to 0.5 seconds, the system encountered

a critical issue after approximately 7 minutes. Data

loss occurred due to Modbus server disconnections,

triggered by the excessive number of requests. The

LabVIEW logs conﬁrmed that the Modbus program

could not handle the volume of concurrent threads,

which points to a potential bottleneck in the Lab-

VIEW Modbus layer rather than the overall system

architecture.

Conclusions About Test 7-9

After the conclusion of these tests the following con-

clusions were made:

• The previous solution is fundamentally limited to

handling up to 20 sensors.

• The proposed solution scales effectively to 30 sen-

sors with minor trade-offs in RAM and CPU us-

age.

• At acquisition frequencies below 1 second, the

Modbus Labview implementation becomes a lim-

iting factor, requiring optimization.

4.3 Stress Testing: Test 10

Test 10 was designed to push the architecture to its op-

erational limits. The test utilized a conﬁguration ﬁle

specifying 60 sensors across 6 different equipment

modules, with a 2-second acquisition rate, doubling

the complexity of the previously mentioned tests.

Testbed Conﬁguration and Results in the

Raspberry Pi 5

Since the IDEPA factory ﬂoor didn’t have 60 sensors

sending data to the Modbus Bus, the system was em-

ulated using three Raspberry Pi 4 units and one Rasp-

berry Pi 5. These devices hosted the Modbus servers

and clients, and a custom XML conﬁguration was de-

ployed. The ﬁrst deployment was carried out on a

Raspberry Pi 5, a more modern computing platform

than the CompactRIO, albeit not optimized for indus-

trial control. Despite this, the solution worked ﬂaw-

lessly, with no interruption in data collection. CPU

and RAM usage were comparable to the CompactRIO

in absolute terms, but slightly lower in percentage due

to the more capable hardware. Attempts to scale be-

yond 60 sensors failed due to thread allocation limi-

tations, which was expected based on earlier architec-

tural analysis.

Test Results on CompactRIO

The second phase of Test 10 involved re-deploying

the architecture to the CompactRIO testbed present

in FEUP. This environment closely simulates the ac-

tual IDEPA factory ﬂoor. The results on the compact

Improving Industrial Interoperability and Scalability Through OPC-UA and Smart Object-Based Architectures

465

Rio were more successful, the system was capable of

capturing 85 sensors without any issues, in contrast

with the previously mentioned 60 on the Raspberry

Pi 5. This is the case because the CompactRio is built

for industrial setups and data processing, which the

Raspberry is not. Attempts to move to the 86th sensor

proved unsuccessful.

Conclusion About Test 10

The stress test conﬁrmed the resilience and adaptabil-

ity of the proposed architecture. The main conclu-

sions are:

• The new system can manage 60 sensors across

multiple devices under moderate acquisition fre-

quency.

• It can operate reliably on both industrial-grade

and consumer-grade hardware.

• Thread allocation and Modbus handling are the

primary bottlenecks for further scalability, espe-

cially under high-frequency conditions.

4.4 Conclusion on Tests 1.1, 4.1 and 7.1

The results obtained from Test 4.1 conﬁrmed the ex-

pected behavior: the system, conﬁgured with 4 sen-

sors and a single equipment unit, performed equiv-

alently to its distributed architecture counterpart. A

similar outcome was observed in Test 7.1, further

validating the solution’s consistency across different

conﬁgurations.

These results reinforce the conclusion that the pro-

posed architecture is both scalable and robust. It

demonstrates that the system can reliably perform its

intended functions without requiring changes to the

existing factory layout, thus supporting seamless de-

ployment in varied industrial setups.

5 CRITICAL ANALYSIS

This section presents and interprets the key ﬁndings

obtained through the comprehensive testing and eval-

uation of the proposed monitoring system. The results

are analyzed from an industrial deployment perspec-

tive, with a particular focus on scalability, operational

stability, system efﬁciency, and user experience. Em-

phasis is placed on the system’s practical readiness

for deployment in real-world manufacturing environ-

ments, such as the IDEPA factory ﬂoor.

5.1 Performance Evaluation

Testing conﬁrmed that the proposed system offers sig-

niﬁcant enhancements over the baseline implementa-

tion, particularly in terms of scalability, fault isola-

tion, and user operability, key requirements for mod-

ern industrial control systems.

A core architectural change was the transition

from a sequential to a multithreaded design. Contrary

to initial expectations, the multithreaded implementa-

tion did not incur excessive computational overhead.

The sequential system, operating sequentially, polled

sensors linearly, resulting in a single point of fail-

ure—where one unresponsive sensor could stall the

entire acquisition process. The newly implemented

parallel architecture isolates such failures, ensuring

uninterrupted data ﬂow from remaining sensors, thus

improving system reliability and robustness.

Tests, as detailed in the previous section, were

conducted under varying loads, acquisition rates,

and sensor conﬁgurations using the CompactRIO

9040 hardware—the same controller deployed on the

IDEPA factory ﬂoor. These scenarios simulated con-

ditions commonly found in medium-sized industrial

environments. Performance metrics revealed that

both the sequential and new architectures exhibited

comparable CPU and memory footprints under most

operating conditions. However, the new architecture

signiﬁcantly reduced acquisition jitter, thereby en-

hancing temporal precision and consistency of data

streams.

These results indicate that the proposed solution is

well-suited for deployment across industrial sites sim-

ilar in scope to IDEPA, especially where distributed

equipment layouts and real-time reliability are criti-

cal.

5.2 Scalability and Limitations

The system demonstrated reliable scalability in con-

trolled test environments, consistently supporting up

to 85 sensors during stress tests. This capability ex-

ceeds the sensor handling capacity of the previous so-

lution and positions the architecture for broader in-

dustrial applicability.

However, limitations emerged when scaling be-

yond this threshold. During system initialization with

over 85 sensors conﬁgured via the XML interface,

startup failures were observed. These issues were

traced to the excessive number of threads created,

which exceeded system resource limits. This behav-

ior highlights a practical ceiling on vertical scalability

when using the current threading model.

Additionally, during high-frequency acquisition

ICINCO 2025 - 22nd International Conference on Informatics in Control, Automation and Robotics

466

scenarios (0.5-second intervals) with 30 sensors,

data loss occurred after sustained operation (approx-

imately seven minutes). This suggests a throughput

ceiling beyond which the system cannot guarantee

consistent data integrity, signaling the need for further

optimization in high-load environments.

5.3 System Evaluation: Strengths and

Weaknesses

The proposed system architecture exhibits several no-

table strengths. One of its key advantages lies in its

fault isolation capabilities. By employing a multi-

threaded design, the system ensures that individual

sensor failures are contained within their respective

execution threads, thereby preventing fault propaga-

tion and maintaining operational continuity—an es-

sential requirement in real-time industrial monitoring

environments.

Another signiﬁcant strength is the robust ini-

tialization mechanism achieved through a dedicated

handshake protocol between LabVIEW and the OPC

UA server. This protocol guarantees an orderly and

deterministic startup process, minimizing the likeli-

hood of boot-time errors and enhancing system relia-

bility.

Furthermore, the integration of a centralized con-

ﬁguration management solution via the Backofﬁce

module contributes to streamlined deployment and

maintenance. Conﬁguration data stored in XML for-

mat enables consistent system setup across multiple

factory installations, supporting scalability and ease

of maintenance.

The system also supports real-time monitoring by

interfacing with the OPC UA Prosys client. This inte-

gration provides immediate visualization and live sta-

tus updates, which are vital for plant-ﬂoor diagnos-

tics, control, and decision-making processes.

Despite these advantages, the system also presents

certain limitations. The reliance on legacy hardware

and software components introduces concerns regard-

ing long-term maintainability and may pose chal-

lenges to future upgrades or performance optimiza-

tion. Additionally, while the multithreaded architec-

ture improves fault tolerance, it also increases com-

putational overhead. This added processing load, al-

though acceptable under current operating conditions,

may limit the system’s deployability on resource-

constrained hardware platforms.

Overall, the system demonstrates a balanced de-

sign that favors reliability, conﬁgurability, and real-

time monitoring, albeit with trade-offs in terms of

hardware compatibility and computational efﬁciency.

6 CONCLUSIONS AND FUTURE

WORK

This work demonstrates the value of reengineering

legacy industrial systems to meet the demands of In-

dustry 4.0. By modernizing middleware, communi-

cation layers, and user interfaces, the proposed solu-

tion improves scalability, robustness, and operational

transparency. The integration of key principles dis-

cussed in this paper is critical for realizing Industry

4.0 objectives, enabling improved operational visi-

bility, reduced downtime, and data-driven decision-

making.

The system modernized at IDEPA enhances scal-

ability, usability, and synchronization through sev-

eral key improvements. Notably, the introduction

of a middleware layer resolves startup race condi-

tions and improves component synchronization. In

parallel, a modular Modbus acquisition approach en-

ables parallel polling and fault tolerance. While

OPC-UA remains the core protocol for standardized

data modeling, its limitations under high sensor loads

led to the exploration of a complementary Message

Queuing Telemetry Transport (MQTT) based archi-

tecture. Although full MQTT integration was beyond

the project’s scope, its advantages in decoupled, scal-

able messaging were validated and recognized for fu-

ture use.

The redesigned GUI signiﬁcantly enhances user

interaction by improving error messaging, operational

transparency, and control intuitiveness, thereby em-

powering operators during maintenance and diagnos-

tics.

The system’s modular design ensures long-term

adaptability and positions it for future integration with

open standards and modern protocols. This platform

contributes directly to IDEPA’s digital transformation

goals and offers a scalable reference model for sim-

ilar industrial deployments. Continued evolution in

this direction aligns with the RAMI 4.0 architecture

and the broader Industry 4.0 vision.

Future work will focus on modernizing the sys-

tem architecture to enhance performance, ﬂexibility,

and maintainability. A key objective is the migra-

tion from the current CompactRIO 9040 platform to

a contemporary industrial controller that offers su-

perior processing capabilities and broader hardware

openness. In parallel, the communication infrastruc-

ture will be restructured around the MQTT protocol

to facilitate improved scalability and reduce the over-

all architectural complexity. Furthermore, the exist-

ing LabVIEW-based data acquisition layer is intended

to be replaced with an open-source framework—such

as Python, Java, or C++ to eliminate licensing depen-

Improving Industrial Interoperability and Scalability Through OPC-UA and Smart Object-Based Architectures

467

dencies and increase development agility. Finally, the

software stack will undergo signiﬁcant refactoring to

eliminate legacy XML-based logic, thereby stream-

lining data management and better supporting con-

tainerized deployment approaches aligned with mod-

ern development practices.

ACKNOWLEDGMENT

This work has been supported by the European Union

under the Next Generation EU, through a grant of

the Portuguese Republic’s Recovery and Resilience

Plan (RRP) Partnership Agreement, within the scope

of the project PRODUTECH R3 – “Agenda Mo-

bilizadora da Fileira das Tecnologias de Produc¸

para a Reindustrializac¸

ao”, Total project investment:

166.988.013,71 Euros; Total Grant: 97.111.730,27

Euros. The authors acknowledge Fundac¸

ao para a

encia e a Tecnologia (FCT) for its ﬁnancial sup-

port via the project UIDB/50022/2020 (LAETA Base

Funding)

REFERENCES

Bauer, W., Schlund, S., Hornung, T., and Schuler, S. (2018).

Digitalization of industrial value chains-a review and

evaluation of existing use cases of industry 4.0 in

germany logforum digitalization of industrial value

chains-a review and evaluation of existing use cases

of industry 4.0 in germany. LogForum, 14:331–340.

Boyes, H., Hallaq, B., Cunningham, J., and Watson, T.

(2018). The industrial internet of things (iiot): An

analysis framework. Computers in Industry, 101:1–

12.

Danys, L., Zolotova, I., Romero, D., Papcun, P., Kajati, E.,

Jaros, R., Koudelka, P., Koziorek, J., and Martinek,

R. (2022). Visible light communication and localiza-

tion: A study on tracking solutions for industry 4.0

and the operator 4.0. Journal of Manufacturing Sys-

tems, 64:535–545.

Demartini, M., Pinna, C., Tonelli, F., Terzi, S., Sansone,

C., and Testa, C. (2018). Food industry digitalization:

from challenges and trends to opportunities and solu-

tions. volume 51, pages 1371–1378. Elsevier B.V.

Morgan, J., Halton, M., Qiao, Y., and Breslin, J. G. (2021).

Industry 4.0 smart reconﬁgurable manufacturing ma-

chines.

Neto, L., Gonc¸alves, G., Torres, P., and Dion

ısio, R. (2020).

On the development of a component model for the re-

alization of industry 4.0. In 2020 IEEE Conference on

Industrial Cyberphysical Systems (ICPS), volume 1,

pages 481–486.

Neto, L., Torres, P., Dionisio, R., Malh

ao, S., and

Gonc¸alves, G. (2019). An industry 4.0 self descrip-

tion information model for software components con-

tained in the administration shell.

Pisching, M. A., Pessoa, M. A., Junqueira, F., dos San-

tos Filho, D. J., and Miyagi, P. E. (2018). An architec-

ture based on rami 4.0 to discover equipment to pro-

cess operations required by products. Computers and

Industrial Engineering, 125:574–591.

Torres, P., Dion

ısio, R., Malh

ao, S., Neto, L., and

Gonc¸alves, G. (2022). Machinery retroﬁting for in-

dustry 4.0. Lecture Notes in Mechanical Engineering,

pages 213–220.

Zhang, T. and Li, N. (2023). Measuring digital economy:

From the perspective of digital industrialization and

industry digitalization. In Procedia Computer Sci-

ence, volume 221, pages 1006–1012. Elsevier B.V.

ICINCO 2025 - 22nd International Conference on Informatics in Control, Automation and Robotics

468