## 3 Proposed FIL Component for the Smart Factory Environment
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:  
\[\text{OPC\_UA\_SERVER=opc.tcp://[Server IP]:[OPC-UA Port],} \tag{1}\]  
for connecting to the OPC UA server, and:  
\[\text{NODE\_ID1=ns=[NamespaceIndex];[IdentifierType]=[NodeIdIdentifier]} \tag{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  
Figure 2: FIL architecture; inside the orange dashed box are the high-level modules of the FIL component. 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:  
1. Syntactic Interoperability: Achieved through the mapping of OPC-UA to the FIWARE data model;
2. 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.