Enhancing Industrial Digitalisation through an Adaptable Component for Bridging Semantic Interoperability Gaps

Abstract

Digital transformation has a great effect on industries but also in the perception of their products with high consequences on society as a whole, as driver for innovation. However, there are still many barriers to the adoption of digital technologies, especially in small and medium-sized enterprises (SMEs). In the present study we propose a new software component that facilitates the adoption of industrial reference architectures (RAs) based on the semantic interoperability concept. Among these RAs, FIWARE has become a key enabler for flexible and resource effective digitalisation of shop floor processes. The proposed software component aims to enable full interoperability between these more widely used technologies and industrial standards and protocols such as OPC UA. As a result, a flexible, open, and adaptable implementation assists the automatic translation of messages from different standards enabling semantic interoperability of shop floor processes. The component aims to enable industrial SMEs to bring current barriers to digitalisation towards a more human-centred, resilient, and sustainable industry and society.

1. Introduction

Driven by global challenges in recent years, the post-pandemic scenario, and the slowing and increasing uncertainty of the world economy, significant growth in digitalisation has had a major impact on all sectors of the economy, from industry to agriculture and cities, and daily citizen routines [1,2,3], with particularly more severe consequences for micro and small enterprises (SMEs) [4]. This digital transformation (DT) evolves with a number of new solutions and tools that offer a wide range of competitive advantages, including improving productivity and profitability and adapting to the emerging of new value chains and customer demands [5]. However, traditional manufacturing technologies, namely those subtractive and long-established manufacturing methods, quality assured and implemented in the commercial space usually as vendor solutions, lack the standards and processes to meet the challenges of this digitalisation [6] that come with the Industry 4.0 paradigm, in a more and more interconnected world [7]. Although larger companies became involved with the digitalisation revolution decades ago, SMEs do not have the same capabilities, and the necessary adaptations to adopt digital transformation could pose a major challenge [8]. When Europe is pushing all its economic sectors to accelerate the twin green and digital transitions toward a more sustainable and resilient society and economy, to be prepared for the next crisis [9], many SMEs are locked in their digitalisation needs and they cannot embrace the DT challenges, emphasising aspects such as environmental, social, or economic aspects. To enable forward-looking transformation to help frame how these SMEs can co-exist with emerging societal trends, it is necessary to enable the enabling conditions to transform, in an easy and affordable manner, their manufacturing models.

In the past decade, the approach to facilitate the adoption of DT has been led by research on reference architecture (RA) models that enables the adoption of emerging technologies and communication protocols around the Internet of Things (IoT) paradigm [10]. Different approaches addressed different aspects of the value chain, data sharing, or integration of applications, facilitating one of the big challenges of Industry 4.0: Interoperability. In fact, interoperability is one of major advantages of the Industry 4.0 paradigm. In a context in which Industry 4.0 includes a transformation of the manufacturing sector, integrating digital technologies like IoT, data sharing, and analytics, it is needed to ensure efficient communication among a variety of services, applications, and actors. Even though different definitions of interoperability have been given [11,12,13], it could be generically defined in an industrial environment as the ability of systems to understand and use the functionality of one another [14]. Interoperability in Industry 4.0 includes four levels: operational (organisational), systematic (applicable), technical, and semantic [15]. Semantic interoperability, that is, the ability to ensure information exchange between system architectures, is one of the main challenges not completely addressed by the RA [16]. One of those causes is that DT tends to be very specialised and restricted to particular domains [7,17]. The changing nature of the sectorial context and the particular conditions and requirements of each company enforce the emergence of open platforms easily extended with additional enablers and components to implement data-driven smart applications. This facilitates a variety of sectorial and company needs and requirements and addresses specific challenges on their digital transformation path. As a result, RAs have contributed to the elimination of existing barriers to the adoption of new technologies and platforms, facilitating the incorporation of small businesses in the DT and the social revolution that transforms and integrates the different perspectives for sustainability priorities and response [18].

However, SMEs, as significant contributors to the European economy [5,19], still require support to transform their business and successfully implement DT strategies. Heterogeneity in the systems deployed in different companies and factories requires general system connectors that simplify the interoperability requirements between factory software, data, and platform and other external system adapters [20]. Digital technologies such as the IoT have the potential to facilitate the adoption of the DT paradigm due to easy access to massive data and the transformation into useful knowledge for effective decision making. In fact, IoT technology and the standards surrounding it have the potential to enable data storage, analysis, and transformation of data created in the company and use external sources, as they have the advantage of allowing for the integration of smart things in an affordable way and the exploitation of information resources and services on the cloud [21]. Nevertheless, to our knowledge, the suitability of existing RAs on this aspect has not been investigated. The lack of a reference process for digital transformation that supports the identification, specification, and implementation of IoT solutions compatible with current custom protocols (i.e., OPC UA, MQTT, XML, etc.) hampers the adoption of the strategy-driven approaches of SMEs. Under these conditions, it is very difficult to integrate new digitalised processes that improve the workability, sustainability, and efficiency of industrial SMEs. These difficulties come from their intrinsic heterogeneity and nuances when consider their specific needs and the different support required in overcoming the barriers of potential digital transformation [22]. Therefore, there is a clear need to bridge these problems and propose a novel approach to find and understand how the RA could be customised to support the automatic translation of one generic data model, used in a variety of IoT devices, into another from specific smart factories’ processes. One of the most extended open RA supporting generic data is FIWARE which offers an open framework dedicated to enhancing data interoperability and integration. By utilising open standards and common data models, it facilitates service composition and ensures the secure and efficient utilisation of shared data resources. Although there are contributions to integrated industrial standards using generic interfaces such as RESTful, they have limitations that make them not suitable to easily include proprietary software configurations, common or agnostic interfaces to decentralise system components, and the lack of experimental analysis to validate the proposed solutions [23,24]. The main purpose of this research is to develop a software component to provide a solution to interface different applications and devices deployed in a shop floor to share data in a common data space enabling the interoperability required to advance towards the digitalisation of industrial shops with clear benefits to daily working activities for many employees. Through a software component called FIWARE Interoperability Layer (FIL), integrated into an open platform, such as FIWARE, we facilitate a secure object model that offers an abstract description of every type of devices, independently of their description or communication protocol. In the context of a company’s Digital Transformation (DT) process, this component will ease the transition by applying standardised frameworks and enabling the integration of new interoperability components based on the FIWARE platform. Thus, these software components are connected to each other, facilitating interoperability between different data models and frameworks. The objective behind our work is to design, implement, and validate an open-source, API-agnostic, cross-standards component to address semantic interoperability and enable seamless aggregated data exchange across heterogeneous shop floor ecosystems using the capabilities of the FIWARE platform.

The proposed component aimed at unlocking industrial standard network capabilities, such as OPC UA, to address semantic interoperability on the usage of web standards, facilitating the integration of commonly usage development strategies such as web applications and cloud services into an industrial vendor-based environment. Our contributions with this article are oriented to present a comprehensive analysis of the current IoT platform FIWARE components and compare them with our proposed component, developing an extensive testbed to emulate large scale data updates originating from PLCs in a shop floor. The performance of the existing components is then analysed though a real configuration that includes multiple data configurations. The goal of the evaluation is twofold: (1) to validate the operations of the FIL component and (2) to investigate further the performance trade-offs, scalability, and requirements of solutions based on this component.

To this end, this document is structured as follows: Section 2 provides an overview of the related work, delving into the background of OPC UA and FIWARE for a comprehensive understanding of the proposed model. Section 3 outlines the proposed model and its specific implementation within FIWARE. Section 4 details the experimental setup and analysis, demonstrating FIL’s operational efficiency. Section 5 discusses the implications of our findings, suggesting future research directions. Finally, Section 6 concludes the document, summarizing key findings and their significance for IoT interoperability, particularly highlighting FIL’s benefits within the FIWARE community and broader IoT implementations.

2. Background and Related Work

This section presents current state-of-the-art and common practices related to semantic interoperability for industrial digitalisation. The section describes the main aspects of the different semantic interoperability approaches, and how RAs, in particular, FIWARE, have addressed the current challenges.

2.1. Semantic Interoperability

Semantic interoperability constitutes a critical element in industrial digitalisation, notably within the scope of SMEs in the manufacturing sector [25]. It empowers diverse systems and applications to effectively share, exchange, and interpret data, a capability that becomes increasingly indispensable as industrial enterprises integrate a range of emerging technologies [11,26]. The concept of interoperability refers to the innate ability of various systems to communicate effectively, enabling the efficient exchange and utilisation of shared information [12]. This feature holds significant importance in the contemporary technological landscape, particularly in facilitating seamless collaboration among a complex and expanding network of interconnected technologies [11,27].

However, semantic interoperability extends this foundational concept by ensuring not only effective exchange but also the accurate interpretation of data between the systems involved [28]. This advanced capability gains prominence for industrial companies looking to maximize the advantages of their digitalisation efforts. It ensures a coherent technological ecosystem capable of operating on shared semantic principles [29].

In the context of industrial digitalisation, achieving a high degree of semantic interoperability is vital to ensure effective communication and coordination among a wide array of technologies and digital systems [28]. Thus, such enterprises are better equipped to optimize their operational processes, make data-driven decisions, and offer increased customisation and efficiency [30].

2.2. Challenges and Opportunities in Semantic Interoperability in Industrial Digitalisation

Despite the compelling advantages of semantic interoperability and FIWARE in the realm of industrial digitalisation, implementing these advanced frameworks is not without challenges. Key issues include, but are not limited to, the complexity of managing various data formats, ensuring data security and privacy, and the adaptability of existing systems to new open standards [31].

However, these challenges also present opportunities for innovation and refinement. For example, the complexities in data management could catalyse the development of more robust data normalisation and translation algorithms [32]. Data security concerns could lead to advancements in secure data transmission techniques, potentially using blockchain or other cryptographic solutions [33]. Furthermore, the momentum towards standardisation via FIWARE offers a beacon for industry leaders to cohesively shape universal protocols, paving the way for more fluid and secure system interactions [34]. In actuality, preliminary triumphs are on record where entities have adeptly dismantled traditional data enclosures, realising impressive operational optimisations through the judicious use of semantic interoperability coupled with FIWARE’s capabilities.

In summary, the challenges inherent to implementing semantic interoperability and FIWARE in industrial digitalisation not only highlight areas for technological improvement but also pave the way for collaborative, industry-wide solutions that could further accelerate the digital transformation pathway.

2.3. Open Platform Communications Unified Architecture (OPC UA)

OPC UA stands as a pivotal communication framework within the realm of industrial automation and control systems [35]. At its core, OPC UA delineates a structured messaging model that facilitates the secure and reliable exchange of information amongst various devices and systems [36]. This is underpinned by the ethos of service-oriented architecture (SOA), which allows OPC UA to encapsulate a myriad of communication interactions within well-defined service calls [37].

The model’s standardised format is a testament to its promise of ensuring interoperability across diverse implementations. Additionally, the advanced security measures woven into its fabric underscore its commitment to maintaining secure and authenticated communications. The versatility of OPC UA is further showcased by its ability to support a range of communication protocols, such as TCP/IP and HTTPS, enabling it to effortlessly embed within heterogeneous environments. Its inherent adaptability ensures that OPC UA remains responsive and can evolve in tandem with the shifting needs of the industry [38].

Nevertheless, while the strengths underscore the efficacy of OPC UA, it is also essential to spotlight some inherent challenges. The extensible and feature-rich nature of OPC UA can, at times, render it complex, especially for those at the outset of their journey with this framework. Implementations on resource-constrained devices might also face challenges due to the memory and processing demands associated with OPC UA. Furthermore, the depth and richness that OPC UA brings to the table also introduce a learning curve, which stakeholders need to navigate to extract maximum value [39].

All in all, OPC UA, with its expansive adoption within the automation industry, is unequivocally one of the frontrunners in the domain of industrial communication standards [35]. However, a nuanced understanding of its capabilities and challenges is pivotal for its efficacious implementation [40].

2.4. FIWARE as a Reference Architecture for a Smart Industry

FIWARE is an open, generic, and extensible platform primarily focused on supporting the development of smart environment applications. FIWARE facilitates access to a rich set of universal and easy-to-use Web Services, which enable the storage and management of data from different sources and devices. Currently, it is considered a highly used DT RA in multiple sectors and domains [41,42]. With this extensive usage of RA to facilitate interoperability between systems, reduce integration costs and risks, and facilitate the adoption of standards and best practises, FIWARE has become a common middleware implementation due to its open source capabilities and wide support from research activities [43]. This extensive research support facilitated FIWARE’s incorporation of components, namely Generic Enablers, which open up the development of new smart applications, solving the issues of heterogeneous environments, overcoming different protocol approaches, or improving the capacities of the stored information. The objective of this work is to provide users of FIWARE generic enablers with the possibility of closing the gap between Linked Data vocabularies and functional APIs of IoT systems in the manufacturing industry domain. Currently, FIWARE, contrary to other platforms, in addition to offering a set of tools and services to facilitate the development of smart solutions, also provides a set of standards for context data management through its context broker, namely the Orion Context Broker [44]. In a FIWARE architectural deployment, all communication between applications and IoT devices is performed by the Context Broker, which means that this GE performs the communication between the producers of information and their consumers.

The Orion LD Context Broker offers advanced capabilities for data ingestion, storage, query processing, and real-time event handling [45]. In our research, we leveraged the Orion LD Context Broker to efficiently store and manage the FIWARE Alert entities generated by the FIWARE Interoperability Layer (FIL) component. This allowed us to seamlessly integrate and process contextual data obtained from OPC UA sources. However, data format generates an issue for real industrial environments. Data in FIWARE is represented in the FIWARE NGSI format. There are two leading versions of this format: NGSI v2 and NGSI-LD. However, the main implementation of Context Broker that supports this NGSI-LD (i.e., Orion-LD Context Broker, developed as a part of the FIWARE platform) is in the alpha development stage. It raises concerns for its smooth adoption in real factories. The Orion LD Context Broker’s support for standard APIs and its seamless integration with other FIWARE components further enhanced the interoperability and data management capabilities of our solution. By leveraging the Orion LD Context Broker, we were able to harness the power of FIWARE’s data-driven approach and unlock new possibilities for advanced IoT applications.

The functionality offered by Context Broker can be exploited due to operations compressed within exposed NGSI-LD APIs. As a notable open-source platform, FIWARE facilitates the delineation of interfaces utilising the OpenAPI Specification (OAS). This not only aids in the creation of web applications that implement the REST interface but also enhances communication between consumers and remote services, eliminating the necessity to access source code, refer to documentation, or conduct network traffic scrutiny. Some projects such as Connected Factories have tested some interoperability issues using current FIWARE Connector implementations, specifically lack of connectivity of shop floor sites which were deploying the components in local instances not connected to the internet. This requires an additional implementation to overcome the impossibility of deploying a data space based on standards [46].

Figure 1 shows how FIWARE as RA can easily integrate as reference middleware to support the communication between CPS, external systems, and the components that act as actuators on the shop floor.

2.5. Existing Similar Solutions: An Overview of Current Approaches to Address Semantic Interoperability Fragmentation and Their Limitations

Currently, there are many efforts in research trying to address the different requirements of Industry 4.0 in such a complex and heterogeneous domain as industry, and we have selected those solutions that could be potential direct competitors of the FIL proposed software.

Table 1. Summary of current research solutions. The table summarises those software solutions that address similar challenges and/or approaches followed by our proposal of interoperability bridge.

Approach Category	Approach	Solution Overview
Based on OPC-UA	OPCUA-IPE	This approach leverages the OPC UA standard to address interoperability, focusing mainly on syntactic issues [48].
	REST-based OPC UA middleware	This approach combines OPC UA with a REST-based middleware, aiming for flexibility in data integration across platforms [49].
	Semantic Validation rules	High-level approach to represent and (semi-)automatically extracting formal rules from unstructured standard documents [50].
Based on the IEEE 1451 Standard	IEEE 1451 Standard Transformation	This solution relies on the IEEE 1451 standard to achieve semantic interoperability, offering a specific service to facilitate external communication via JSON-LD structures [51].
	Model-Driven Digital Thread	This solution extends the IEEE standard using RESTful APIs [52].
Based on Semantic interoperability principles	eWoT	The approach provides a SPARQL query-based mechanism to transparently discover and access IoT devices that publish heterogeneous data [53].
	OPC UA Standard over TSN	Specialized middleware in general layered architecture [54].
	F4I IDAS OPC UA Agent	The main focus of this component is on the communication from field devices implementing an OPC UA server to FIWARE, allowing communication with the FIWARE Orion Context Broker [55]. Currently is the de facto standard for implementing FIWARE-based solutions in industrial settings.

summarises the approaches of our main competitors, while

Table 2. Summary of current research solutions. The table summarises the limitations of the identified competitors across three main domains: integration ease, data management efficiency, and implementation cost. Our component in the last row aims at overcoming these limitations.

Features/Components	Integration Ease	Data Management Efficiency	Implementation Cost
F4I IDAS OPC UA Agent	Requires technical expertise	Efficient, but may struggle with high volume data streams	High due to potentially greater developer time involved
OPCUA-IPE	Specialised skills needed to implement solution	Not achieved in the tests	High operational costs (proprietary licences required)
REST-based OPC UA middleware	Ac-doc server deployment required	Minimal latency	Operational expenses for specialised middleware
Semantic Validation rules	Intense manual effort needed	Multimodal extraction not allowed	Specialised development is required
IEEE 1451 Standard Transformation	Requires technical expertise	Struggle with high volume of data streams	Specialised nature of this approach can incur additional costs in system customisation and maintenance
Model-Driven Digital Thread	High programming and integration effort	Limited data format supported	Potentially higher due to reduced flexibility and scalability
eWoT	URI pattern definition is not allowed	OPC-UA is not specifically supported	Potentially higher due to reduced flexibility and scalability
OPC UA Standard over TSN	The solution is hardcoded	Not scalable, struggle with high volume data streams	High programming cost
FIL	User-friendly, designed for SMEs	High-speed processing minimal latency	Cost-effective, leverages open-source tech

analyses their primary limitations based on a literature review in three specific domains: ease of integration, data management efficiency, and implementation cost. These domains are essential requirements for our proposed solution.

Following Table 1, Table 2 delves into the interoperability challenges addressed by each approach, outlining their specific limitations. It further illustrates how the FIL component surpasses these constraints, offering a more robust solution to interoperability issues within the context of Industry 4.0.

Within the context of Industry 4.0, a critical challenge is the fragmentation of semantic interoperability. Addressing this, our research introduces the FIL component, designed to bridge these gaps. FIL is rooted in principles that are integral to system engineering and software development, offering a novel approach in comparison to existing methodologies. These principles not only address current interoperability challenges but also align with broader technological concepts, ensuring FIL’s relevance and applicability in diverse industrial scenarios.

Although existing solutions make meaningful contributions to specific facets of interoperability, they often incur high implementation and operational costs. FIL fills this gap by offering a comprehensive, flexible, and cost-effective solution that is well suited for the diverse and evolving requirements of industry digitalisation. Building upon this overview of current approaches, it is imperative to conduct a direct comparison between FIL and an established component in this domain, the F4I IDAS OPC UA Agent from FIWARE.

3. Proposed FIL Component for the Smart Factory Environment

This section outlines the comprehensive development process of the FIL component, designed for aggregating data from diverse sources using prevalent industrial standards, including OPC UA, and a variety of IoT sensors. Serving as middleware, the FIL component facilitates data integration within the FIWARE framework, thereby enhancing the development of web services and cloud platforms for the efficient collection, storage, and utilization of aggregated data. The materials and methodologies employed in developing the FIL component are detailed subsequently.

The FIL component is designed around a three-tier architecture, enhancing interoperability in IoT environments. Initially, the Node ID Registry Server configures and registers PLC nodes as FIL input variables. Subsequently, the Context Consumer module enriches data with semantic context and evaluates existing entities to prevent duplication. Finally, the FIWARE Entity Converter creates standardized FIWARE Entity definitions. This layered approach, illustrated in Figure 2, integrates physical OPC UA devices on the production floor with the FIWARE Context Broker through containerized solutions, optimizing data flow from the shop floor to the digital realm with efficiency and scalability.

Leading into the detailed functionality of the FIL component, the NodeID registry server plays a critical role. This module is designed to capture OPC UA input from third-party servers, specifically PLCs. It adheres to the PLC data model and exposes sensor and actuator data within their respective networks. OPC UA captures information using nodes as the basic element that communicates using the OPC UA protocol [17]. An OPC UA node can be a device, a process variable, a control structure, an application, etc. The OPC UA nodes are used for communication between different automation systems and for real-time data exchange. The structure of the OPC UA nodes is based on a hierarchical tree in which each node can have several children and a single parent. Each node has a unique identifier and a set of attributes and properties that describe its state and behaviour, according to the specification available in [56]. The main functionality of the NodeID registry server is to preserve the semantic value present in the different definitions of this specification, configure the nodes from the third-party servers, and add them to the FIL input variables. To this end, it configures PLC nodes and adds them to FIL’s input variables, preserving the original PLC semantic values. Once the nodes have been configured on the server or their existence verified, they need to be added to the environment variables of the Docker-deployed component. For configuring the OPC UA Client module inside the FIL component, the environment variables OPC_UA_SERVER and NODE_ID1 are set with specific details:

OPC_UA_SERVER=opc.tcp://[Server IP]:[OPC-UA Port],

(1)

for connecting to the OPC UA server, and:

NODE_ID1=ns=[NamespaceIndex];[IdentifierType]=[NodeIdIdentifier]

(2)

to specify the node. This setup ensures seamless identification and access to the information each node contains, streamlining the integration process within the FIL component.

After configuring all the nodes, the Context Consumer module is ready to read their contained information and proceed with defining the semantic context. This module takes the configured nodes and reads their metadata to start the generation process of the FIWARE Entities, thereby enabling interaction with the FIWARE Context Broker. Metadata in an OPC UA node are defined in the node description information, which includes properties such as the node identifier, data type, description, and other relevant attributes. These metadata are used to describe and manage the information associated with a node and allow OPC UA clients and servers to exchange data efficiently and reliably.

Table 3. OPC UA Variable Node to FIWARE Entity Attribute Mapping.

Variable Node Class Attributes	FIWARE Entity Class Attributes
Node ID	id
Display Name	name
Description	description
Value	value:value
Data Type	value:type

summarises the mapping process performed by this module. The obtained FIWARE Entities are published in a Context Broker deployed in the local network.

The design follows a modular architecture, where each module has a well-defined role in the process of capturing, translating, and exposing the data in a standardised format. This addresses different kinds of interoperability:

• Syntactic Interoperability: Achieved through the mapping of OPC-UA to the FIWARE data model;
• Semantic Interoperability: Achieved through the use of FIWARE Entities defined following the NGSI-LD definition, providing a comprehensive metadata structure that enables direct message exchange based on a unified HTTP-based interface.

Although the system may appear to be process-orientated, the use of an object model is crucial. The object model captures the hierarchical relationships between different entities in the OPC UA layer, thereby facilitating a seamless translation into the FIWARE data model.

4. FIL Component Quantitative Analysis: Experimental Testbed Design

To evaluate the performance of the proposed FIL component, we have built a software-based experimental testbed based on a simulated IoT deployment.

4.1. Evaluation Methodology

With its intended goal of serving as tool for facilitating semantic interoperability in an Industry 4.0 scenario, the FIL component will need to be able to handle efficiently the different traffic generated by the infrastructure, devices, and components deployed in a generic industrial shop floor. In a deployment such as the one depicted in Figure 3, the FIL component receives data updates sent by PLCs along the production line. The PLCs handle various data, including sensor readings, temperature, pressure, and timing responses. These updates may include multiple configurations changing in real time, implying a significant growth in the amount of data updates that have to be handled by the component.

To assess FIL’s performance in managing substantial updates from OPC UA servers and its comparison with the F4I OPC UA Agent, we constructed a comprehensive testbed capable of simulating PLC data loads. In the proposed scenario, we simulated a production line requiring data sharing from a set of PLCs to automate response and control mechanisms. These data, essential for other components depicted as Component 1 and Component 2 in Figure 3, involve some PLCs connected through common middleware, in our case, FIWARE, and others externally consuming data via standard HTTP/HTTPS protocols. Figure 3 sums up the architecture of the scenario deployed to test the FIL component. The same structure but with the F4I OPC UA Agent was implemented to perform a comparative analysis of the solutions.

The following design objectives were considered for the testbed:

• Performance observability, that is the ability to accurately capture, analyse, and present information about the performance of the proposed component. In a real shop floor, PLCs interact with the deployed components and it is necessary to balance the need for performance data against the cost of obtaining these data. As productivity and efficiency are core KPIs in industrial processes [57], we have used the Prometheus monitoring system [58] and cAdvisor [59] to collect extensive performance metrics;
• Variable and massive load generation to generate the heterogeneity and overload situation that could happen in a real shop floor scenario with multiple PLCs working in multiple working stations. Apache JMeter [60] was used to generate large rates of new active nodes.

4.2. Testing Environment Design and Configuration

In the experimental testbed design, we employed Docker to create isolated environments for both FIL and the F4I OPC UA Agent, ensuring comparable testing conditions. The monitoring tools cAdvisor and Prometheus were configured for real-time metrics collection, tracking resource usage, latency, and throughput. While cAdvisor provides insights in real time of the software tested, Prometheus allows one to set up a historical vision of each container performance, for example, to test the memory usage over time. Grafana provided the visualization platform for the data collected by cAdvisor and Prometheus, enabling us to analyse and compare the performance of FIL and F4I OPC UA Agent across various simulated IoT scenarios. The evaluation metrics focused on scalability, efficiency, and interoperability, critical factors for assessing semantic interoperability solutions in Industry 4.0 settings.

We used two Virtual Machines (VMs) to perform the experiments. We have used the application versions that come from FIWARE documentation recommendations or the latest available application version. In VM #1, we deployed the modules that enable the performance analysis OPC-UA Servers, and in VM #2, we deployed the applications under test: the interoperability solution, FIWARE, and MongoDB. We configured both VMs as the standard Amazon AWS t2.medium instance configuration (2vCPU-4 GB of RAM). The Node.js OPC UA client serves as an implementation of an OPC UA client within the Node.js runtime environment. OPC UA, a widely adopted communication standard in industrial automation and control, facilitates seamless interoperability between various devices and systems. Leveraging the power of the Node.js ecosystem, the Node.js OPC UA client leverages the JavaScript or TypeScript programming languages, taking advantage of its asynchronous and event-driven nature. This client enables real-time access to data, subscriptions to events, and execution of operations on OPC UA servers. By leveraging the extensive library ecosystem and modular architecture of Node.js, the client enables developers to build robust industrial applications, including real-time monitoring and control systems, asset management solutions, and data acquisition systems. In industrial environments, the Node.js OPC UA client provides a reliable and efficient means to establish connections and facilitate seamless communication with OPC UA servers, ensuring optimised integration and interoperability.

In the other server, a FIWARE-based platform has been deployed to facilitate the automatic management of component 1 and component 2 simulating different actions on a shop floor, i.e., to facilitate the automatic management of a robot using the automation control enablers.

4.3. Generating Load of IoT Protocols

In our testing battery, we simulate three different OPC-UA servers that send messages captured from a variety of sensors connected to them. The number of sensors and the sensors’ message periodicity vary during the experiment randomly. These synthetic messages are identified by a NodeId generated as a sequential identificatory number, a message type that identifies the type of sensor information (temperature, pressure, status, level, etc.), the datatype of that information, and the value.

Table 4. Examples of OPC UA nodes.

Server	Node ID	Display Name	Data Type	Value
A	ns=2;i=1001	Temperature	Float	25.6
A	ns=2;i=1002	Pressure	Float	101.2
B	ns=3;i=2001	Status	Boolean	True
B	ns=3;i=2002	Level	Int32	75
C	ns=4;i=3001	Speed	UInt16	500

shows several examples of OPC UA nodes, each with different characteristics and attributes in the context of industrial automation and data exchange.

Table 4 comprises essential fields such as Server, Node ID, Display Name, Data Type, and Value, which together provide a detailed description of the OPC UA infrastructure that will be used for the FIL and its competitor during the experiment performance.

Under the heading “Server”, various servers are identified, indicated by alphabetical labels, signifying the source or origin of the respective nodes. On the other hand, the “Node ID” column incorporates globally unique identifiers that ensure unambiguous identification and differentiation between the different nodes. These identifiers, represented in the format ns=i, serve as indispensable references to locate and access specific nodes within the OPC UA network.

The “Display Name” column encapsulates human-readable descriptions assigned to each node, allowing intuitive recognition and understanding of its functionalities. The delineation of the data type associated with each node is defined in the “Data type” column, which covers a range of primitive types. column, which covers a range of primitive and complex types such as Float, Boolean, Int32, and UInt16. Finally, the “Value” column captures the current value or state of each node, representing the real-time information being monitored or controlled.

4.4. Test Plan

To assess the component’s performance with OPC UA server update rates, we considered throughput to the MongoDB database (linked to the Context Broker), resource usage (CPU, active memory, and data transmitted), and entity query latency across both components. JMeter simulates state changes of sensors connected to the PLCs, creating asynchronous uptake over 180 s to ensure steady-state measurements via Grafana and Prometheus. The aim was to examine scaling effects on FIWARE platform PLC instances using FIL or the F4I OPC UA Agent, crucial for identifying system bottlenecks, efficiency, and deployment costs. Throughout the test, 600 scenarios were simulated, requiring each component to apply its functionality, ultimately resulting in an entity published on the Context Broker.

4.5. Performance Comparison: FIL vs. F4I OPC UA Agent

In this section, we analyse the FIL component and the F4I OPC UA Agent that allow the OPC UA server to connect to the FIWARE Context Broker and send data updates to the deployed backend component.

To ensure the correctness and completeness of the translation performed by the Context Consumer and the FIWARE Entity Converter, the messages produced by the OPC UA server were compared with the messages subscribed into the Context Broker and the ones stored into MongoDB. The completeness was manually validated by comparing the number in entities of all messages and verifying that it was the same in all inputs and outputs. Correctness was verified by manually comparing the content of all the outputs and verifying that they are the same entities in all of them. No major differences were found in the translations, and a value of correct translation close to 100% of the messages was found.

In our analysis with Prometheus and Grafana, FIL showed exceptional performance compared to the F4I OPC UA Agent, especially in resource utilization and speed. Specifically, FIL’s CPU usage peaked at only 1.75%, averaging around 0.5%, whereas the F4I OPC UA Agent averaged 2.5% (Figure 4 and Figure 5).

The memory usage is higher in F4I OPC UA Agent caused by Orion which updates the attribute stored into MongoDB any time an attribute is updated, increasing the processing demand of the database. The memory consumption for FIL averaged at 75.3 MiB, significantly less than the F4I OPC UA Agent’s 218 MiB (Figure 6 and Figure 7). The CPU usage in the F4I OPC UA Agent grows fast. While the CPU usage in the FIL component seems to grow linearly with the load in the MongoDB, in the F4I Agent this growth is faster than linear and it is maintained over time.

Data transmission rates for FIL peaked at 250 B/s, generally staying below 50 B/s, in stark contrast to the F4I OPC UA Agent’s nearly constant rate of 600 B/s (Figure 8 and Figure 9). These findings, supported by subsequent graphs, highlight FIL’s efficiency and its potential to provide cost-effective solutions for Industry 4.0 interoperability.

Finally, we have inspected the number of lost messages. All messages were delivered by the IoT agent, and minimum of them were lost when higher workload rates were sent in the case of the FIL component. The delay was higher in the F4I OPC UA Agent when translating into a FIWARE Entity, as shown in the partial description of the results in

Table 5. Comparative Performance Outcomes of FIL and F4I OPC UA Agent Under Varied Workloads.

Solution	Workload	Delivered Messages (Average)	Delay (Average Time (s))
FIL	Low	100%	0.10
F4I OPC UA Agent	Low	100%	0.13
FIL	Medium	99.02 ± 0.27%	0.32
F4I OPC UA Agent	Medium	98.99 ± 1.12%	0.58
FIL	High	98.32 ± 1.06%	1.27
F4I OPC UA Agent	High	93.55 ± 2.58%	1.59

.

The analysis reveals that while both FIL and the F4I OPC UA Agent exhibit high message delivery rates, FIL demonstrates a slight advantage, particularly under high workload conditions. This performance edge becomes more pronounced with increased delay times for the F4I OPC UA Agent during FIWARE Entity translation. This comparison underscores FIL’s robustness and efficiency, showcasing its potential to enhance the FIWARE platform’s interoperability and real-time data handling capabilities.

5. Discussion

Over the past decades, companies and industry organisations have increasingly adopted RAs to facilitate digitalisation transitions and interoperability between their systems. An RA can be essentially defined as an architectural definition of a collection of systems in a given domain, providing the knowledge about how to develop and evolve software in this domain. However, the heterogeneity of industrial needs, the variety of use cases and scenarios, and the different technical requirements require great flexibility and high connectivity features. Despite the good performance of current FIWARE components to address interoperability with IoT devices, the proposed FIL component demonstrates in the performance experiments some advantages in integration, data management efficiency, and deployment cost.

First, FIL distinguishes itself with its user-friendly design for integration with various IoT platforms and industrial systems, which is particularly advantageous for SMEs. In contrast to the F4I IDAS OPC UA Agent that requires more technical knowledge for effective integration, posing potential challenges in complex industrial environments, FIL only requires a first configuration based on web standard technologies that dynamically update over time. In addition, experiments demonstrated FIL’s capability in managing high-speed data processing which ensures real-time data handling with minimal latency, a crucial requirement in dynamic industrial settings. On the other hand, while F4I IDAS OPC UA Agent is efficient in data management, it might struggle with very high-volume data streams in real-time scenarios. Finally, FIL’s development strategy emphasizes cost-effectiveness, with both FIL and the F4I IDAS OPC UA Agent being open-source solutions that inherently reduce software acquisition costs. The distinguishing factor lies in FIL’s streamlined configuration process, which significantly cuts down on the time developers spend setting up the system. This efficiency translates to lower labour costs, positioning FIL as a particularly economical choice for SMEs aiming to deploy semantic interoperability solutions efficiently.

Through its seamless integration capabilities, real-time data management efficiency, and commitment to affordability, FIL sets itself apart. A side-by-side analysis with the F4I IDAS OPC UA Agent, as detailed in the accompanying table, showcases FIL’s superior performance in integration ease, data processing, and cost savings. These qualities demonstrate FIL’s precise alignment with SME needs within Industry 4.0, marking it as a versatile and economically viable choice for overcoming semantic interoperability hurdles.

This is a novel approach that addresses these three aspects, providing an interoperability solution for cyber-physical systems. In this way, the FIL component makes FIWARE compatible with OpenAPI and OPC UA facilitating the integration of any type of virtual or real component (i.e., sensors and applications in the cloud) embedded in complex frameworks (i.e., Industry 4.0) into RA with reduced effort, cost, and required skills. In this way, it is possible to take advantage of the greater power of NGSI-LD by allowing us to describe semantic contexts. Although the layered architecture may initially suggest higher implementation costs, the use of Docker containers for deployment adds flexibility and reduces the overall cost. Furthermore, by integrating existing standards such as OPC-UA and FIWARE, we eliminate the need to develop new interfaces from scratch, leading to a more cost-effective solution.

This component has the ability to serve as a communication bridge between FIWARE and standards such as OPC UA or OpenAPI. However, to translate into different vocabularies, adaptive algorithms should be developed to allow translating one data model into another, or translation fields should be manually defined for the mapping. Further work will be oriented towards testing and validating the solution in real shop floor scenarios and increasing the number of supported standards.

6. Conclusions

In concluding, this study showcases FIL’s significant role in enhancing IoT interoperability within Industry 4.0. Beyond its comparative advantage over the F4I OPC UA Agent, FIL embodies a pivotal development in the seamless integration of IoT devices and platforms. Its implementation within the FIWARE ecosystem demonstrates a forward leap in creating adaptable, efficient, and scalable IoT solutions. In light of the results reported and the previous analysis, several conclusions can be reached: (1) as the FIL solution could provide a faster integration of standard protocols such as OPC-UA into the FIWARE standard, once the translation template is ready, translation into FIWARE Entity descriptions are automatic and without major delays;(2) FIL provides an API-agnostic, language-independent solution that allows the integration of new IoT devices without the need of code modification; (3) the inclusion of new OPC-UA entities only requires registration, no new coding; (4) in extremely demanding situations, or those services that require a very high accuracy, the FIL solution needs to be faster. This comparative analysis focuses on critical aspects such as integration ease, data management efficiency, and implementation costs, providing a clearer understanding of how FIL positions itself in the landscape of semantic interoperability solutions in Industry 4.0. This research not only highlights FIL’s operational efficiencies but also its broader implications for digital transformation across industries, promoting a more interconnected and innovative future.