STAG — Bridging Data from Shop Floor to IT World

Modern production facilities are dealing with enormous amounts of process data related to production lines, including data from sensors, machines, and logistic systems. To advance digitization, data needs to be tracked, analyzed, and visualized using various IT systems for different reasons. However, many data sources do not provide a simple, common interface to access the data.

Especially when digitizing a production facility, data often originates from machines and sensor systems that use different communication protocols [1]. Thus, the integration of shop floor data sources with larger IT solutions, including ERP or MES solutions, tends to be difficult and tedious. Often data sources need to be integrated, controlled, and maintained individually, in each IT solution.

With the aim of easing the digitization and closing the gap between shopfloor and IT systems, our work focuses on the following research questions:

• How to automatically map and translate between different protocols and data models on the shop floor?
• How to generalize the protocol mapping to become extendable to multiple standards?
• How to implement this mapping in a modular and adaptable system architecture?

The modular and extensible STAG software solution addresses the challenges outlined above. It bridges the gap between the data sourcing technologies at the shop floor (e.g. Modbus [2], IO-Link [3]) and the data models of mostly IP-based protocols used in the IT world, including Open Platform Communications Unified Architecture (OPC UA) [4] or MQTT [5]. The core of STAG is a modular architecture based on an internal information model that acts as an intermediate mapping model between different technologies.

State of the art

There have been many approaches that address the data modeling and interoperability on the shop floor level with IT systems. The Industrial Digital Twin Association (IDTA), for one, focuses on defining and developing standards for digital twins. 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.

OPC 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.

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.

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.

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.

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.

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.

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.

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.

System architecture

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, as shown in Figure 1. 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.

The core modules contain the Information Model 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 and the Technology Manager, which registers the modeled entities in the Model Manager.

These entities are then stored in the Information Repository. Once a change within the Information Repository occurs, the Model Manager 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 accesses the modeled entities in a uniform manner without knowing the specific technology adapter behind it.

Technology adapters are instrumental in creating entities within the Information Model and handling all technology-specific tasks needed to access the data. Every adapter must implement the Technology Adapter Interface, which provides a standardized way of creating Device abstractions within the Information Model via the Builder pattern [20]. It also provides a mechanism for adding and removing Device abstractions from the internal Information Repository.

Data consumers manage the connection to IT solutions, respectively providing server endpoints as well as making the data sourced from the Information Model Device 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, which contains the aforementioned event mechanism to notify the implementations, when a new Device abstraction has been created, or an existing one has been removed by any of the technology adapters.

All modules areorchestrated by the System Runner. 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. This ensures that the Information Repository remains consistent, while unavailable devices are automatically removed. The System Runner then attempts to restart the plugin and reestablish previous connections.

STAG information model

The basis of the STAG project is the internal data abstraction, called the Information Model. It defines the fundamental elements that describe an entity’s logical structure, the types of input/output data points as well as their values. By entity, we mean sensors or machinery. Figure 2 introduces the basic elements of the STAG Information Model, 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. 

Each modeled entity (e.g. a sensor or a machine) is represented as a Device class. It acts as a container for all the other classes, modeling the relevant attributes and functionalities in terms of DeviceElement instances. Both the Device and the DeviceElement classes inherit from the NamedElement class, which contains general information like name, unique identifier, and description of said element. The three classes (Device, DeviceElement, and NamedElement) are the only classes that use the inheritance principal to reuse code.

All other classes were modeled following the composition over inheritance paradigm as mentioned above. DeviceElement class is a container that can have one of the following classes: a DeviceElementGroup, a Metric, a WritableMetric, an ObservableMetric or a Function. Each of these classes model a specific functionality.

DeviceElementGroup class is used to logically group other DeviceElement instances. It always contains at least one DeviceElement instance inside. Since DeviceElementGroup contains only DeviceElement instances, which themselves reference a DeviceElementGroup, we can create nested groups of elements within a group. This modeling approach allows users to group elements in a more granular way.

The Metric 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 and ObservableMetric. The base functionality of Metric is available to both of them via composition. Thus, WritableMetric and ObservableMetric can still be used to read entity attributes.The WritableMetric 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 class is designed as a data source for the Observer pattern [20] and informs all attached listeners when the attribute receives a new value.

Function 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 class can also be used similarly to the WritableMetric, since it allows users to modify the attributes of the modeled entity. However, WritableMetric instances only allow the modification of a single value by another single value of the same data type, whereas Function instances can use multiple values as inputs to execute any desired operation.

Device, DeviceElement and DeviceElementGroup 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, and Function 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 will then remove the old entity from the model and register the new one via the event mechanism.

Implementation and use cases

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.

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’s extendibility.We implemented a specialized technology adapter for the vehicle test stand that uses Simple Object Access Protocol (SOAP) [22] interface for communication.

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’s OPC UA interface.

To highlight and demonstrate the features of STAG, we developed a showcase that integrates different industrial sensors. As shown in Figure 3, 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.

The 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 instances and the IoT Core interface [23] from ifm to obtain the process data and provide it as Metric and Function 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 instances. All of the technological complexities of each adapter are hidden away to present easy-to-understand OPC UA Nodes (Fig. 4).

The 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.

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. 

Making shop floor data more accessible

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.

You might also be interested in

Learning Factories for the Future of Manufacturing in Brazil Advancing manufacturing through technology and skills development

Manufacturing firms in developing countries face challenges in closing productivity gaps while adopting Industry 4.0 technologies. Learning factories are one helpful approach to countering these challenges. One such example is the learning factory Fábrica do Futuroin São Paulo, Brazil, which has engaged students, supported competence development, and collaborated with industry in applied research, functioning as a hub for advanced manufacturing initiatives.

Serious Gaming and the Energy Transition Collaborative knowledge generation and interactive understanding of complex interrelationships Janine Gondolf , Gert Mehlmann, Jörn Hartung, Bernd Schweinshaut, Anne Bauer

Conveying the complexity and multifaceted nature of the energy transition to a broad audience is a challenge. This article demonstrates how interactive serious games on a multitouch table can help make connections tangible and comprehensible. The games and the table were used in various conversational contexts. These are presented here in three case vignettes based on participant observation of the different applications, as well as situated and shared reflection. The vignettes demonstrate how interaction can trigger epistemic processes, enable shifts in perspective, and foster collective thinking, all of which are necessary for shaping the future of society as a whole.

Industry 4.0 Science | Volume 42 | 2026 | Edition 2 | Pages 62-69

Experiencing Digital Twins in Production and Logistics The fischertechnik® Learning Factory 4.0 as a development platform for possible expansion stages Deike Gliem , Sigrid Wenzel , Jan Schickram, Tareq Albeesh

The fischertechnik® Learning Factory 4.0 has proven to be a suitable experimental environment for testing digital twins. Depending on the targeted maturity stage, the functions of a digital twin range from status monitoring and forecasting to the operational control of production and logistics systems. To systematically classify these functions, this article presents a maturity model that serves as a framework for the development of a digital twin. Building on this, selected use cases are implemented in a test and development environment based on a system architecture with multi-layered logic structure. These initial implementations serve to highlight application purposes, relevant methods, and typical challenges and potentials in the transfer to real factory environments.

Industry 4.0 Science | Volume 42 | Edition 2 | Pages 30-37 | DOI 10.30844/I4SE.26.2.30

Collaborative Robots in Production Environments Employee qualification and acceptance for human-machine interaction Tobias Wienzek, Mathias Cuypers

The introduction of new technologies poses a major challenge, especially for small and medium-sized enterprises (SMEs). At the same time, SMEs must rise to this challenge in order to keep pace technologically and economically. Employee acceptance is an important factor in ensuring that both the introduction and the long-term use of a technology are successful. At the same time, the introduction process also has a central influence on acceptance in the long term. This article uses the implementation of collaborative robotics as an example for examining such an introduction process, identifying the key factors that influence employee acceptance and the important role played by advanced employee training. It serves to highlight how the introduction process and employee training are seamlessly interlinked.

Industry 4.0 Science | Volume 42 | 2026 | Edition 2 | Pages 14-21 | DOI 10.30844/I4SE.26.2.14

XAI for Predicting and Nudging Worker Decision-Making Feasibility and perceived ethical issues Jan-Phillip Herrmann , Catharina Baier, Sven Tackenberg , Verena Nitsch

Explainable artificial intelligence (XAI)-based nudging, while ethically complex, may offer a favorable alternative to rigid, algorithmically generated schedules that simultaneously respects worker autonomy and improves overall scheduling performance on the shop floor. This paper presents a controlled laboratory study demonstrating the successful nudging of 28 industrial engineering students in a job shop simulation. The study shows that the observed concordance between students’ sequencing decisions and a predefined target sequence increases by 9% through nudging. This is done by using XAI to analyze students’ preferences and adjusting task deadlines and priorities in the simulation. The paper discusses the ethical issues of nudging, including potential manipulation, illusory autonomy, and reducing people to numbers. To mitigate these issues, it offers recommendations for implementing the XAI-based nudging approach in practice and highlights its strengths relative to rigid, ...

Industry 4.0 Science | Volume 42 | 2026 | Edition 1 | Pages 70-78

Applied AI for Human-Centric Assembly Workplace Design An ethics-informed approach Tadele Belay Tuli , Michael Jonek , Sascha Niethammer, Henning Vogler, Martin Manns

Artificial intelligence (AI) can enhance smart assembly by predicting human motion and adapting workplace design. Using probabilistic models such as Gaussian Mixture Models (GMMs), AI systems anticipate operator actions to improve coordination with robots. However, these predictive systems raise ethical concerns related to safety, fairness, and privacy under the EU AI Act, which classifies them as high-risk. This paper presents a conceptual method integrating probabilistic motion modeling with ethical evaluation via Z-Inspection®. An industrial case study using the Smart Work Assistant (SWA) demonstrates how multimodal sensing (motion, gaze) and interpretable models enable anticipatory assistance. The approach moves from ethics evaluation to ethics-informed work design, yielding transferable principles and a configurable assessment matrix that supports compliance-by-design in collaborative assembly.

Industry 4.0 Science | Volume 42 | 2026 | Edition 1 | Pages 60-68 | DOI 10.30844/I4SE.26.1.58