digital twins<\/a>. With the Asset Administration Shell (AAS) [6], IDTA has defined a uniform digital access layer for various asset information. IDTA 02008-1-1 [7] defines a dedicated Submodel for time series data. Based on the Reference Architecture Model Industry 4.0 (RAMI 4.0) [8], Drath et al. [9] recommend OPC UA as the appropriate technology for implementing runtime-relevant information including AAS sensor values.<\/p>\n\n\n\nOPC UA provides interoperability with the IT world and, with its integrated data model, is capable of modeling and mapping a wide range of information. However, OPC UA is a complex communication stack, too. To standardize the integration of dedicated technologies, the OPC UA Foundation defined a set of mapping companion standards. For example, the IO-Link mapping [10] is a companion standard that specifies the OPC UA namespace definitions for the IO-Link Device Descriptors. However, OPC UA standards only define the mapping and modeling, but do not fully enable implementation.<\/p>\n\n\n\n
To successfully set up and operate a digital sensor twin, it is not enough to design the relevant interfaces. One must also close the technological gap between the communication protocols and the buses on both shop floor and IT level. Ifm is known to be a pioneer in the field of IO-Link as well as a leading sensor provider [11]. In addition to sensors, Ifm offers its own IO-Link gateways [12] that convert IO-Link data into PROFIBUS, EtherCAT, or IP-based communication via MQTT.<\/p>\n\n\n\n
A direct translation into OPC UA is not yet available. The Baumer Group, another major supplier of sensors, sells similar gateways and provides support for OPC UA in some cases [13]. However, the gateways usually only support one sensor technology, in this case IO Link.<\/p>\n\n\n\n
There are also a number of companies that focus solely on the development and sale of gateways and do not develop their own sensors. One example of this is Wachendorff Prozesstechnik GmbH & Co KG, who offer a wide range of different protocol converters [14]. However, unlike STAG, an individual gateway is required for each combination of technologies. Offering various 1-to-1 protocol adapters, HMS has a similar product portfolio [15]. However, this also means that different devices are required for different protocols.<\/p>\n\n\n\n
Furthermore, some OPC UA SDK providers, such as Softing or Matrikon, sell their own OPC UA gateways, which are intended to simplify the integration of existing systems into the OPC UA world. These technologies have the common feature of supporting the exchange of data between the shop floor and the IT world. On the downside, they are also both limited to only one communication protocol.<\/p>\n\n\n\n
Another approach to data interoperability and integration is put forward by companies who act as brokers of digital integration solutions. For example, some companies create their own digital marketplace for Docker-based applications supported by specific industrial computers. Yet other systems allow machine manufacturers to easily embed various machine data and control points into the IT landscape.<\/p>\n\n\n\n
Although different commercial solutions exist that support the integration of individual technologies and sensors into IT-systems, research on the generalization and process simplification to obtain plug-and-produce (PnP) vision is still ongoing [16]. OpenPNP [17], for example, integrates different OPC UA data sources at run time. In contrast, Endeley et al. [18] focus on accessing legacy sensors that have no IP-based interface.<\/p>\n\n\n\n
The authors were able to validate their approach by mapping the serial communication with an SPS and other I2C based sensors into the OPC UA data model. However, a general support of different sensors and technologies used on the shop floor is missing. In [19], Pena et al. present a configurable Modbus – OPC UA gateway that maps Modbus variables to OPC UA variables based on user specifications. However, the approach is limited to Modbus only.<\/p>\n\n\n\n
System architecture<\/h2>\n\n\n\n The STAG system architecture is designed around modularity and expandability. The architecture can be subdivided into three main parts: core modules, technology adapter, and data consumer implementations. All components are managed by the System Runner<\/em>, as shown in Figure 1<\/strong>. Our aim is to introduce a conceptual distinction between accessing data points on the shop floor, providing interfaces and data to the IT department, and mapping functionalities between them. Thus, the STAG architecture enables operators to simultaneously employ different operation and information technologies without the need to modify any of the existing system configurations.<\/p>\n\n\n\nFigure 1: STAG system overview.<\/em><\/figcaption><\/figure>\n\n\n\nThe core modules<\/strong> contain the Information Model<\/em> definitions and provide interfaces for technology adapter and data consumer implementations. These modules ensure that the modeled elements, created by the technology adapters, are built correctly, and that no duplicate entities exist within the model. This is done by the Technology Adapter Interface<\/em> and the Technology Manager<\/em>, which registers the modeled entities in the Model Manager<\/em>.<\/p>\n\n\n\nThese entities are then stored in the Information Repository<\/em>. Once a change within the Information Repository<\/em> occurs, the Model Manager<\/em> sends out notifications to all data consumers via an internal event mechanism that either a new entity has been added or an existing one has been removed. The Data Consumer Adapter Interface<\/em> accesses the modeled entities in a uniform manner without knowing the specific technology adapter behind it.<\/p>\n\n\n\nTechnology adapters<\/strong> are instrumental in creating entities within the Information Model <\/em>and handling all technology-specific tasks needed to access the data. Every adapter must implement the Technology Adapter Interface<\/em>, which provides a standardized way of creating Device <\/em>abstractions within the Information Model <\/em>via the Builder pattern [20]. It also provides a mechanism for adding and removing Device<\/em> abstractions from the internal Information Repository.<\/em><\/p>\n\n\n\nData consumers<\/strong> manage the connection to IT solutions, respectively providing server endpoints as well as making the data sourced from the Information Model Device<\/em> abstractions accessible. Data consumers are responsible for performing the appropriate data mappings and allowing users to interact with the modeled entities. Every consumer must implement the Data Consumer Adapter Interface<\/em>, which contains the aforementioned event mechanism to notify the implementations, when a new Device <\/em>abstraction has been created, or an existing one has been removed by any of the technology adapters.<\/p>\n\n\n\nAll modules areorchestrated by the System Runner<\/em>. It starts and stops the registered technology and data consumer adapter plugins via their respective interfaces, connects them to the core, as well as configures their shared logging functionality. Any exceptions, thrown by the plugins, are evaluated and handled appropriately to guarantee that the entire system functions smoothly. Any plugin that encounters an unrecoverable error is stopped and removed from the system by the System Runner<\/em>. This ensures that the Information Repository<\/em> remains consistent, while unavailable devices are automatically removed. The System Runner<\/em> then attempts to restart the plugin and reestablish previous connections.<\/p>\n\n\n\nSTAG information model<\/h2>\n\n\n\n The basis of the STAG project is the internal data abstraction, called the Information Model<\/em>. It defines the fundamental elements that describe an entity\u2019s logical structure, the types of input\/output data points as well as their values. By entity, we mean sensors or machinery. Figure\u00a02<\/strong> introduces the basic elements of the STAG Information Model,<\/em> illustrated as a UML class diagram. We designed the model according to the composition over inheritance design principle [21], which allows us to decouple the modeled entities structure from its features.\u00a0<\/p>\n\n\n\nFigure 2: STAG Information Model class diagram.<\/em><\/figcaption><\/figure>\n\n\n\nEach modeled entity (e.g. a sensor or a machine) is represented as a Device<\/em> class. It acts as a container for all the other classes, modeling the relevant attributes and functionalities in terms of DeviceElement <\/em>instances. Both the Device<\/em> and the DeviceElement<\/em> classes inherit from the NamedElement <\/em>class, which contains general information like name, unique identifier, and description of said element. The three classes (Device<\/em>, DeviceElement<\/em>, and NamedElement<\/em>) are the only classes that use the inheritance principal to reuse code.<\/p>\n\n\n\nAll other classes were modeled following the composition over inheritance paradigm as mentioned above. DeviceElement class<\/em> is a container that can have one of the following classes: a DeviceElementGroup<\/em>, a Metric<\/em>, a WritableMetric<\/em>, an ObservableMetric<\/em> or a Function. <\/em>Each of these classes model a specific functionality.<\/p>\n\n\n\nDeviceElementGroup <\/em>class is used to logically group other DeviceElement<\/em> instances. It always contains at least one DeviceElement<\/em> instance inside. Since DeviceElementGroup <\/em>contains only DeviceElement instances,<\/em> which themselves reference a DeviceElementGroup<\/em>, we can create nested groups of elements within a group. This modeling approach allows users to group elements in a more granular way.<\/p>\n\n\n\nThe Metric<\/em> class serves to model a single, readable entity attribute of a specific type (e.g. a temperature value that is represented as a floating point) and is further expanded by two other classes: WritableMetric <\/em>and ObservableMetric. <\/em>The base functionality of Metric <\/em>is available to both of them via composition. Thus, WritableMetric <\/em>and ObservableMetric <\/em>can still be used to read entity attributes.The WritableMetric <\/em>class allows users to modify a single readable entity attribute with new values (e.g. a user-defined label, represented as a human-readable string). ObservableMetric <\/em>class is designed as a data source for the Observer pattern [20] and informs all attached listeners when the attribute receives a new value.<\/p>\n\n\n\nFunction <\/em>class is used to model entity attributes that can use input values to perform an action and optionally return a result once the operation is completed. The Function<\/em> class can also be used similarly to the WritableMetric<\/em>, since it allows users to modify the attributes of the modeled entity. However, WritableMetric <\/em>instances only allow the modification of a single value by another single value of the same data type, whereas Function<\/em> instances can use multiple values as inputs to execute any desired operation.<\/p>\n\n\n\nDevice, DeviceElement <\/em>and DeviceElementGroup <\/em>classes are used to represent the structure, which does not change for the entire lifetime of the modeled entity. Therefore, the three classes model static information. In contrast,the classes Metric, WritableMetric, ObservableMetric, <\/em>and Function <\/em>are used to represent attributes and functionalities with dynamic information. Hence, the values represented by the metrics change regularly during the lifetime of a modeled entity or can be modified during run time. To modify the static information of existing entities, a new entity with the same ID must be created and registered as an updated value. The Model Manager<\/em> will then remove the old entity from the model and register the new one via the event mechanism.<\/p>\n\n\n\nImplementation and use cases<\/h2>\n\n\n\n The STAG System has been in development since 2018 as a follow-up development of an evaluation kit based on Lightweight Machine to Machine (LwM2M) and OPC UA technologies for non-disruptive Ad-Hoc smart sensor systems (NIKI 4.0 project). In subsequent projects, AMELI 4.0 and ParsiFAL 4.0, we further refined the LwM2M and OPC UA technology implementations for specific use cases as well as gathered requirements for the system as a whole. Finally, we laid the groundwork architecture for the STAGSystem and refactored existing LwM2M and OPC UA implementations to fit the modular approach.<\/p>\n\n\n\n
The first application and evaluation of the STAG System started as part of a project that extends and integrates vehicle test facilities as digital twins into a cloud-based virtual test platform. With STAG, we not only realized the communication interfaces and the data mappings into OPC UA, but also demonstrated the system\u2019s extendibility.We implemented a specialized technology adapter for the vehicle test stand that uses Simple Object Access Protocol (SOAP) [22] interface for communication.<\/p>\n\n\n\n
Due to the way STAG is designed, the only extension needed was an adapter for the SOAP technology, as the mapping for the existing OPC UA interface did not require any changes. As a second application example, we implemented a general-purpose Modbus technology adapter that was used to obtain sensor information from a hydrogen generator. Both technology adapters can run in parallel. The data that both adapters provide is transferred to a cloud-based virtual test bed over STAG\u2019s OPC UA interface.<\/p>\n\n\n\n
To highlight and demonstrate the features of STAG, we developed a showcase that integrates different industrial sensors. As shown in Figure 3<\/strong>, we used a TCC501 temperature transmitter, an IO-Link based sensor from ifm, a BA EE660 low air velocity sensor from E+E Elektronik and a S-Light-01 ambient light sensor from Seed Studio. Both the air velocity and ambient light sensors were configured for Modbus communication via the RS-485 interface. These sensors are then connected to our software via Ethernet and the ifm AL1304 IO-Link Master for the IO-Link sensor and a twisted pair cable for the Modbus sensors. To visualize the sensor information, we are using UA Expert OPC UA Client from Unified Automation.<\/p>\n\n\n\nFigure 3: STAG demonstrator deployment diagram.<\/em><\/figcaption><\/figure>\n\n\n\nThe demonstrator presents an IO-Link Technology Adapter working alongside the Modbus Technology Adapter to deliver data via the OPC UA interface. The IO-Link Technology Adapter uses the IODD (IO-Link Device Descriptor) files to create Information Model Device<\/em> instances and the IoT Core interface [23] from ifm to obtain the process data and provide it as Metric<\/em> and Function<\/em> instances. The Modbus Technology Adapter uses our custom, JSON (JavaScript Object Notation) [24] based descriptors to define the registers and their decoders to create Device<\/em> instances. All of the technological complexities of each adapter are hidden away to present easy-to-understand OPC UA Nodes (Fig. 4<\/strong>).<\/p>\n\n\n\nThe different use cases demonstrate the significant effort reduction for integrating new sensors that can be reached by STAG in comparison to a manual and individual implementation approach. In the case of Modbus and SOAP, only a sensor-specific configuration files with a few lines of code need to be specified. These configuration files map addresses, IDs, and URLs to data variables of the STAG internal data model.<\/p>\n\n\n\n
In contrast, a manual implementation requires the implementation of technology and sensor-specific code ranging from communication adapter over data parser up to the implementation of an OPC UA server or an MQTT data provider. Even with using libraries, the implementation will require several hundred lines of code. In the case of IO-Link, the implementation effort is even lower. The IODDs should be accessible for STAG and the communication with the IO-Master needs to be configured. Newly connected sensors are discovered automatically and directly accessible through the OPC UA interface.\u00a0<\/p>\n\n\n\nFigure 4: Data Visualization in UA Expert.<\/em><\/figcaption><\/figure>\n\n\n\nMaking shop floor data more accessible<\/h2>\n\n\n\n With STAG, we developed and implemented an extendable and modular gateway technology that bridges the gap between sensors on the shop floor and the IT system using software solutions that analyze and process the data. Dedicated Technology Adapters offer multiple communication technologies on the shop floor and map data into the internal STAG Information Model. Subsequently, various Data Consumers can be deployed to map data into IT protocols including OPC UA and MQTT. As a result, STAG makes shop floor data accessible for IT systems. We developed STAGas part of different research projects and demonstrated STAG in several use cases highlighting the significant reduction of implementation effort.<\/p>\n
![\"Figure](\"https:\/\/industry-science.com\/wp-content\/uploads\/2025\/06\/Rathfelder_I4S-25-3_Bild-1-1024x429.jpeg\")
![\"Figure](\"https:\/\/industry-science.com\/wp-content\/uploads\/2025\/06\/Rathfelder_I4S-25-3_Bild-2-1024x735.jpg\")
![\"Figure](\"https:\/\/industry-science.com\/wp-content\/uploads\/2025\/06\/Rathfelder_I4S-25-3_Bild-3-1024x356.jpg\")
![\"Figure](\"https:\/\/industry-science.com\/wp-content\/uploads\/2025\/06\/Rathfelder_I4S-25-3_Bild-4-1024x823.jpg\")