Proactive Approach to Production Control Utilizing Heterogeneous Shop-Level Production Data

Abstract

This paper presents an approach for integrating data between a production system and its digital twin, focusing on achieving proactivity in production control. Recognizing the unique nature of each production system, this research highlights that a universal, plug-and-play solution is only partially feasible, primarily through general guidelines. The study successfully applied and automated proposed data acquisition methods, resulting in a functional, simulation-based digital twin that adheres to the latest ISO standards. The developed solution incorporates multiple data acquisition strategies, including files containing comma-separated values, a permanent connection to the production control system database, open platform communications unified architecture, and external command files for scenario alteration. The main motivation behind the presented implementation is its application on the shop-floors of small and medium enterprises, where it could provide useful tools for keeping up with the ever-rising competition in the manufacturing sector. This integrated approach allows for affordable and accurate system representation within the proactive simulation concept. The methodology was empirically validated across two distinct production systems: a lab-scale food and beverage line focusing on product tracking, and a sub-assembly line with automated guided vehicle optimization. Despite system variability, the core data acquisition methods demonstrated remarkable adaptability.

1. Introduction

The existing body of research has established the undisputable advantage of Digital Twins (DTws) for facilitating organizational efficiency in manufacturing [1,2,3]. The necessity to advance further in terms of analytics, real-time monitoring, and optimization has been growing alongside the identified need for a more efficient approach to manufacturing in the context of simulations [4].

Simulation and modeling has become a key instrument for improving industrial processes [5,6,7] and has remained one of the pillars of most modern enterprises. Simulation and modeling lies at the heart of innovation and agility and consistently yields positive results for respective use cases.

The most widely used approach to simulating manufacturing production lines are discrete event simulations (DES); however, depending on the system features, modelers also opt for continuous [8,9,10,11] or agent-based simulation. The best solution to realistically capture the system flow is a hybrid multi-layer simulation of a given cyber–physical production line. Hybrid simulations offer the most adaptive and high-fidelity simulations that unify the control flow and physical processes and can serve as a base for DTw implementation.

DTw technology improves on simulation technology with its core being real-time data integration and subsequent data-driven analytics for decision support. DTws help track and manage asset data flow and enable for reconfiguration at a keystroke [12,13,14,15]. DTws serve to represent a physical object or a system, virtually, with real-time data and are particularly useful for ease-of-use by utilizing simulation. Simulations enable visualization of relationships among subsystems, inner components of systems, and their ability to interact with their environments.

The benefits of DTw technology depend on specific uses and implementation. It can simulate production processes, optimize urban planning, monitor operations and continuously assess system variables. Studies have proven that DTws’ application in enterprise resource planning (ERP) and manufacturing execution systems (MES) aids in decision-making and reduces response latency levels [16]. The combination of DTws with simulation achieves real-time control and optimization [17] of workflows [18], enabling for a closed-loop manufacturing system if integrated with artificial intelligence (AI) or machine learning (ML) This facilitates sizeable improvements in various aspects of industry use cases, such as error mitigation with real-time predictive maintenance [19] and safety monitoring of safety-critical infrastructures [20].

The aim of this study is to apply the Industry 4.0 concepts of cyber–physical systems (CPS) with real-time monitoring, data-driven control, and adaptive planning to demonstrate innovative approaches toward DTw creation for smart manufacturing systems where data sources are not only more unified than DTw solutions have been until this day but also to do so in a manner that complies with industry standards.

Analysis of common challenges and drawbacks faced in established implementations or presented case studies can be summarized as follows [21,22,23,24]:

• Limited scope of data types—Research focuses on specific data types and does not fully address the complexities of handling heterogeneous data.
• Focus on specific vendors—While the OPC UA architecture is aimed at vendor neutrality, implementations are still tied to specific vendors of PLCs or OPC UA software development kits [25].
• Economic viability—Implementations often lack cost–benefit analysis of data acquisition and integration solutions.
• Security simplification—The cyber-security vulnerability of presented applications is often outside of the primary scope of research.

In an attempt to solve some of these drawbacks, we have opted into proposing an approach which can help alleviate decision-making pressure from management workers responsible for production planning. Our approach revolves around incorporating multiple data acquisition methods, which are readily available in systems commonly found in small and medium enterprises (SMEs) and are often left underutilized. This is mainly due to the lack of trained workers or shop-floor-level expertise in data governance. While our proposed methodology still requires a higher degree of knowledge about the utilized systems, the all-in-one-place reference point of a complex solution can still be beneficial to the general base of knowledge. Keeping the full solution within a local network addresses the security aspect of the data acquisition process itself; however, the threat of outside breaches is still a possibility. This was only partially addressed by transferring minimal amounts of data, while its context is hard-coded into individual entities.

2. Data Management as a Prerequisite for Success

Industries and smart manufacturing organizations generate large amounts of data. After their acquisition and proper use, data allow for efficiency in organizational workflows as an asset creating value, central to innovation, development, and growth.

As defined by the standard, observable manufacturing elements (OMEs) are items within the manufacturing environment associated with production, materials, equipment use and other articles of the industrial processes. This suggests that companies must invest and focus on data management and an appropriate data strategy given the urge to make profit and gain insights from the values. However, data within organizations lack centered panoplies of their streams which has been an ongoing issue resulting in heterogeneity of secondary data sources, which is detrimental to the design process. It is at this phase of the model development process where operation comes to a halt due to the lack of an integrated unified center of data concerning the modeled entity, which hinders the process of information exchange between device communication entities [26] and OMEs in previous DTw adoption case studies [27,28,29].

Data is either available, acquirable or unavailable, which from that point onwards is a tall order to manage. The limiting conditions of unavailable data have been addressed by approaches of manual model development and by analyzing production logs. However, modern data-driven methods utilize advanced analytical techniques of statistical analysis and machine learning (ML) as they are suitable for complexity and dynamics representation [30,31].

In the creation of DTws, reliable data of the observable manufacturing domain are fundamental to enabling accurate system representation by OMEs’ states, and the data ought not only to be available but also synchronized with the DTw in the device communication domain. The data stream, i.e., the communication update period, must also be continuous and seamlessly integrated with the DTw system. Therefore, it is beneficial to assume a proactive stance toward data management. Although studies have previously been conducted to aid in the development of DTws [4,32], a more straightforward approach for requirements and methodologies for proper implementation has been finally supplied by the ISO/IEC 30173 standard [33].

In order to avoid the possible emergence of inconsistencies, as observed in textual sources of multiple case studies and our empirical knowledge, we have investigated the applicability of the standard for our solution. The common framework proposed by the ISO/IEC 30173 standard has from then onwards helped in providing the following:

• A basis for understanding the concept and composition of a DTw through definitions of digital twin-related concepts;
• An overview of the life cycle of a DTw in relation to the target entity it represents;
• A basis for the development of standards, specifications and uses of DTws.

The standard draws together a comprehensive definition of DTw concepts with terminology that can be applied in multiple domains. All relevant parts of the ISO 23247 standard, “Automation systems and integration—Digital twin framework for manufacturing”, were considered. The series defines a framework to support the creation of DTws of OMEs, including personnel, equipment, materials, manufacturing processes, facilities, environment, products, and supporting documents. The individual parts considered include

• ISO 23247-1 [34]: An overview and general principles for developing DTws in manufacturing, including concepts and definitions, as well as requirements for designing a DTw.
• ISO 23247-2 [26]: A reference architecture for implementing DTws in manufacturing. It includes a reference model with domains and entities. There are four domains, each with a logical group of tasks and functions performed by functional entities. The four domains include OME, data collection and device control, DTw, and user domains. Functional entities may include data acquisition, simulation, synchronization, etc.
• ISO 23247-3 [35]: A description of the basic informational attributes for a typical OME. The digital representation of OMEs may include both static and dynamic information. It is recommended to use existing standards to represent OME, based on use case requirements.
• ISO 23247-4 [36]: A description of the technical requirements for information exchange between individual elements (entities) within the defined reference architecture.

According to the standard, to ensure that our solution complies with digital twin entity requisites, it was necessary to assess our data collection sub-entity. For this purpose, we had to consider the data management of existing systems up until the time of DTw creation. To support the study, if necessary, data were aggregated so that they could be mapped onto the entity for seamless information exchange. Accessing the data entailed choosing the acquisition method and the rate of transfer. This played an important role in expediting the attempt for a proactive approach to task scheduling and production process simulation [37]. The act of transferring production data between the production control system (PCS) and the simulation platform can be facilitated in multiple ways, utilizing communication protocols on different technological levels, depending on the data subset transfer method.

3. Methodology

The four approaches discussed in this paper are aimed at the transference of selected production data between the PCS and the simulator. Each approach is proposed with the aim of achieving proactivity and prevention in production control as opposed to reactive issue management.

In our case studies, the first system is a lab-scale food and beverage production line with both discrete and continuous elements. As the system is in laboratory conditions, it is amenable enough to serve educational purposes and also as a testbed for further academic research and development. The other system is a sub-assembly line in an assembly shop in the automotive industry.

For funneling the necessary production data into the simulator, the data transference had to be done in a custom-made manner. Using industry standards, such as files containing comma-separated values (CSV), an open platform communications unified architecture (OPC UA) as well as a direct connection to the PCS database were a part of our proposed solution. In conjunction with the aforementioned data transference options was a simulator-specific command file, utilized as a tool for simulating different scenarios in rapid succession.

Figure 1 illustrates the architectural schema for data exchange among the systems detailed in this study. Continuous data flow is maintained between the PrS, the MES located on the PCS, and the database system throughout all phases of the production process. A system supervisor or operator can, upon request, initiate specific data streams linked to the data management interfaces and the simulation platform. This action triggers the generation and redirection of required data files to the simulator. The simulation process commences immediately upon validating all required input data files.

3.1. CSV for Production Orders

Production simulations necessitate the input of large amounts of data, which must adhere to predefined structure to ensure proper functionality. Some of the examples of this kind of data are production orders (PO), machine tasks or logistics schedule. Utilizing CSV files is a common approach to interconnect PCS and a simulator in general. Developing a DTw for a production system (PrS), regardless of whether concurrently with the PrS or for an existing one, defining a communication protocol is paramount. This protocol is used to establish explicit rules for generating and interpreting CSV file handling during the process. Unifying CSV file read and write rules for both the PCS and the simulator allows for better data interpretation and allocation within the respective entities.

When attempting to achieve seamless data file generation within the PCS and consequently integrating the generated data files with the simulator, multiple prerequisites for both entities need to be fulfilled.

3.1.1. Viewing and Modification of Incoming Production Orders

After performing the initial system analysis on the studied PrS, the first identified requirement was to integrate with a control platform, enabling a PrS operator to actively adjust the ongoing production. It could be done through, e.g., a Human–Machine Interface (HMI) panel or direct access to various interfaces of the manufacturing execution system (MES). In our studied use cases, the operator had access to data related to the production orders (PO), particularly to the incoming request execution priority. The operator was then able to adjust the priority of PO based on the current state of the PrS. The importance of fulfilling this requirement emerged from the fact that the control activity was performed at the start and at the end of the data integration and production process simulation.

To achieve full control over PO modification at the start of the data integration process, a custom multi-functional application tailored to the studied PrS, codenamed Order Management Interface (OMI), was proposed and implemented. The application shared a functionality similar to the overarching MES system while also allowing us to quickly generate multiple production scenarios for process analysis. To achieve this functionality, the OMI has been equipped with multiple control elements, which allow it to generate CSV files and ECFs based on the state of these elements, e.g., setting a different priority for bottle filling from 0%–>50%–>100% to 50%–>0%–>100% or changing a filling priority from solid filling to liquid filling to be executed first, which changes the output file composition and creates a new scenario for the simulator. Similarly, the OMI operator can opt into simulating a partial breakdown using elements related to this functionality. This occurrence creates a potential scenario in the simulator, where the production system can only produce one type of products, while the broken-down subsystems related to the specified resource are undergoing maintenance. It served the purpose of an offline research alternative, while the MES still fulfilled the functionality of directly controlling the production process in the physical system.

The following figure (Figure 2) contains a simplified showcase of the data file structures created by the OMI at the start of the simulation process. Individual modules of the simulation model then parse the CSV files. Concurrently, the command file provides scenario-specific parameters. This process is described in a later chapter.

3.1.2. Providing a Coding Environment or a Platform to Run User-Defined Scripts

Another important prerequisite for seamless data integration is the existence of an integrated development environment (IDE) within the PCS, or at the very least an option to run custom user-defined scripts. This functionality also removes dependency on third-party interfaces, which means that localized databases are not exposed to external influence and only the items important to the production simulation process are being accessed. Considering the data integration process between the PCS and the simulation platform, the benefit of being able to write and modify the user scripts plays a significant role. This prerequisite originates from the fact that production process and PO data are stored directly within the database of the PCS system. The user is then able to access and extract the data using various system variables or attributes, which mitigates the time pressure being put on the data acquisition process. Data extracted by this method is used for two different data file types, which are then forwarded into the simulator; first the CSV PO file, then the command file.

3.1.3. Ability to Load Data from External Files

By utilizing specialized algorithms for altering the shop-floor production schedule, with stochastic factors present, it is possible to create different scenarios and replications without the loss of initial data. The main benefits to this approach identified thus far directly correlate to the possibility of running an offline simulation without the need for active connections to the PCS or any other data sources.

To achieve this functionality, it is important to implement a software module for a PCS which allows the operator to create various scenarios for the ongoing production process. Alternatively, building a custom-built interface or a series of interfaces with different functionalities is also an option, as these can be iterated and expanded upon, allowing for further production process customization. The only requirement for this approach is the ability to load the customized scenarios or production schedules back into the PCS, which implies that the involved systems must be fully integrated for data to be exchangeable between the subsystems. To prove the concept, as mentioned in previous chapters, we have developed a fully customizable GUI for the PCS at our disposal, which allowed us to proactively run multiple simulations with different scenarios using the DTw of our monitored PrS. The GUI was a MATLAB R2023b application, equipped with the functionality to load the specialized data files from the PCS, allowing the user, or a production operator, to make suitable adjustments to the shop-floor schedule before initiating the simulation. The endpoint of the data-altering process is followed by generating the data files containing the modified schedule for the simulator. In addition, the simulation process is initiated directly from the GUI using the command files.

As presented in the conceptual model in Figure 3, after a successful simulation run, the data transfer back into the MES was narrowed down to a single data file containing the PO data. It was then a much simpler process, as our MES was equipped with a functionality which allowed it to identify the creation of new files with the specified parameters. Upon identifying a successful reading of the incoming data file, the extraction algorithm was initiated. The extraction algorithm was a custom script implemented to purposefully apply the simulated changes to the upcoming production schedule. A scenario where the simulation process can be deemed as unsuccessful (the “no” branch on the MES and Production system level in Figure 3) is a possible occurrence. This state is related to the prolonged or delayed acquisition of simulated data from the simulator (the simulator or the PCS was temporarily disconnected from the local network) or the inability to read the simulated data inside the MES (an error occurred during the simulation, preventing the generation of an output file in accordance with the pre-specified protocol). In this scenario, a relevant error message is displayed, presenting details about the cause of the error to the operator. Figure 4 displays an example of how the raw data collected from the MES is interpreted within the simulator after reading the CSV files. The interpretation adheres to the rules set up for the first case study presented further in this paper.

3.2. CSV for Supervisory Data

To date, many SME category enterprises still operate on manual data transfer [38], most commonly using spreadsheets as a tool of choice for collecting and storing production data. Although the process lacks automation, it is still possible to point out some clear benefits to this approach, such as detailed data analysis or data reusability for future validation processes. However, to integrate the PCS with the simulator for a proactive approach to production control requires a certain level of automation. A similar approach can also be applied to data without a predefined structure, e.g., data located in PLC data blocks, where the format and contents vary depending on the workstation [39]. An ability to access the remote data located within the PLC data block is not considered a common functionality of PCSs, as this data can be easily exploited. In this instance, however, it is possible to implement custom scripts with the purpose of accessing this type of data, which can then be used to further calibrate the simulation models. Alternatively, it is possible to use an OPC server to access and gather specific production data, while having the ability to store the data in spreadsheets, if necessary. By utilizing this approach to gather and transfer data, it is possible to gain a real-time digital image of the current production state. It is also manageable to get insights into its very near future by snapshotting the real-time data and sending it directly into the simulator with the in-app tools of the simulator.

3.3. Direct Database Connection

As per all the data acquisition methods described in this paper, utilizing a local database connected to the PCS alongside a simulation-based DTw is an approach used for accessing, acquiring and displaying supervisory data to the operator. It can be considered an alternative approach to data transfer, where intermediary data storage is not available or required [40]. One of the benefits of a simulation-based DTw is the option to display the data located in databases directly within the simulation environment, providing useful information for decision-making in production control. Our simulator of choice had a functionality that allowed DTws to be directly connected to the database and offered a range of elements to display or manipulate the data by custom algorithmic coding practices.

The volume of data being accessed and transferred between the PCS and the simulator is highly dependent on the type and volume of data being stored in the PCS itself. It is also important to note that not all of the data stored in the PCS is required or applicable for use in the simulation using the DTw. Therefore, data selection and preliminary data formatting algorithms should be implemented before the full integration of a DTw with the PCS database. A good practice is to create highly specific views or tables inside the database, which are then directly read by the DTw. This reduces the risk of potentially exposing the full scale of vulnerable data to a possible malicious interception, as the simulation process can be performed remotely. Furthermore, interpretation of said data within the DTw, its alteration and re-formatting for the purpose of sending the data back to the PCS, is a part of the requirement for implementing the backwards communication of the DTw with the PCS, thus having the communication process fully automated.

Unlike other methods described in this paper, which utilize data file transfer to ensure their targeted functionality, when initializing a simulation process within the DTw utilizing the PCS database, an active connection to the PCS is required throughout the full duration of the simulation. This is due to the DTw being directly dependent on the current data located within the database for the purpose of displaying the product data to the operator or the system supervisor. Based on this type of connection, utilizing a database does not require any additional data files as the functional elements within the simulator handle the production data autonomously. A common scenario for utilizing this type of approach is when attempting to transfer production batch data, logistical unit data or recent historical data from individual production entities into the simulator, e.g., machines, storage units, transport vehicles, etc. This data is then used to reconfigure the simulation model where necessary, to adjust it to the current state of production.

3.4. Utilizing the Transport Layer Communication

A key focus is accessing raw production data from shop-level Programmable Logic Controllers (PLCs) and the communication protocols facilitating this data transfer to a control PC. For the purpose of this paper, we have considered communication protocols, which would allow us to gather the following data from the PrS in order to achieve our simulation goals:

• Timestamped events: Recording the precise moment of occurrence for process-defining events within the production system, e.g., product entering a machine, start/end of an operation, etc. This is crucial for analyzing the sequence of occurring events, potential identification of production disruptions, and quality control [41].
• Product movement tracking: Monitoring the flow of products as they progress through the production line. This data can involve tracking individual items, batches, or pallets, and is essential for inventory management, identifying potential bottlenecks throughout the PrS and, lastly, process optimization.
• Cycle time measurement: Determining the duration required for individual workstations or processes to complete their tasks. This specific type of data is highly valued during the process of creating a DTw for already existing and developed systems, as not all the data is available to the end user or documented in the PrS technical documentation [42].

This production data can be accessed in its raw state directly from the shop-floor PLCs. It provides a detailed and unfiltered view of the production process, minimizing data loss and maximizing accuracy.

To facilitate the production data transfer from the PrS to the control PC and further to the simulation platform, we have considered the use of the following three communication protocols. The main criteria for choosing a suitable data transfer protocol were reliability and efficiency.

• User Datagram Protocol (UDP)—a connectionless protocol that prioritizes speed over reliability. When using this method, data is transferred in packets without establishing a dedicated connection or ensuring its delivery to the designated receiver. While offering low latency, the potential for packet loss devalues the choice of this protocol for the resulting solution. Due to the requirements of a DTw fully integrated with the production system, any potential loss of transferred network packets is a significant drawback, as it can compromise the simulation accuracy and cause failed simulation runs, therefore possibly negatively affect subsequent decision-making.
• Transmission Control Protocol (TCP)—a connection-oriented protocol that prioritizes reliability and data integrity. In order to ensure that the packets are delivered in the correct order and retransmit any lost packets, it establishes a connection between the sender and receiver prior to the data transmission process. As data integrity is a crucial part of a successful simulation when using a DTw, the reliability of this communication protocol makes it more suitable for acquiring production data from the PrS, mainly due to the overhead actions associated with the connection establishment and error checking capabilities.
• Open Platform Communications Unified Architecture—the OPC UA protocol is a platform-independent, service-oriented architecture for industrial communication [43,44]. It provides a comprehensive framework for data exchange, encompassing not only raw data but also metadata, security, and information modeling. Among the three communication protocols considered, OPC UA operates with the highest volume of data. This does not necessarily pose a problem, since modern network infrastructures can easily handle the required volume without noticeably affecting the speed of the data acquisition process.

Figure 5 represents a topological layout of our established PLC network with a connection to the simulation platform through an OPC UA interface.

The data acquired through the OPC UA server is formatted into a JSON format which is then further adjusted for use in the simulation through our custom data integration interfaces. In the case depicted in Figure 6, the main attributes utilized within the simulator are the names of elements (element identification) and volume levels for individual tanks (initial value at the start of simulation). The remaining attributes extracted from the production system serve as control attributes for data integrity and trigger alarms, in case of data inconsistency occurrence. An example of data acquired from two PLCs in the system and their respective interpretation into an external command file is illustrated in the following figure.

A similar study by Coito, et al. (2022) [45] has shown that this protocol can be utilized to capture and transfer data related to machine availability and work states while keeping the data binary in nature and adjusting the interpretation where deemed necessary.

3.5. External Command Files

An alternative approach to production problem solving and production control using simulation tools and practices is by utilizing external command files (ECF). This approach exploits the functionalities of the chosen simulation platform to perform systematic modifications on existing models for the duration of a single simulation run, thus leaving the base model unchanged outside of the ongoing experiment.

The main prerequisite for utilizing this approach is to establish a default PrS state, which can be recreated within the simulator and used as a starting point able to be further altered through ECFs. Furthermore, it is possible to create a fully functional simulation model using ECFs exclusively, although this approach is not recommended by the developers of our simulator. This highly specific use case lacks proper visual representation of the model, i.e., it becomes unsuitable for the purpose of showcasing the ongoing processes [46].

By taking advantage of the ability to run the simulation through ECFs, it is possible to run multiple simulations in quick succession, while also being able to generate data or log files for further system analysis. For simulators which allow this type of simulation control, it is possible to create multiple ECFs specifically tailored to the requirements of the problem at hand. Furthermore, having sufficient familiarity with the simulated physical system and its digital model allows for the creation of ECFs which alter the functionality of selected workstations, functional entities, or even the entirety of the simulated process. Considering all the options and applications listed above, it is important to note that the exact size, structure, or usage of ECFs directly correlates to the specific needs of the problem at hand. This also holds true for other simulation platforms, though the syntax may differ for every individual software being used for this task.

In order to fully utilize the strengths of using ECFs for production process simulation, we opted into implementing various custom scripts for the system platform of the production control system (PCS), which would then automatically create these files. However, this puts a requirement on PCS choice, or any software directly connected to the PCS interface, to allow for the creation of such files. Furthermore, it is necessary to understand the syntax required for defining these CFs, and the syntax within the PCS scripting interface, as well as finding a way to combine these to get the desired output.

This approach comes with several benefits over standard methods used for data transfer between systems (e.g., through direct database connection). The most notable difference is in the way the PCS data is handled. By creating an ECF inside the PCS, the production data is accessed directly through internal variables and attributes, which store the sensor data from the PrS. This means that the raw data stays within the MES and only the data required by the simulator is being stored and transferred as a part of the ECFs. Due to the structure of these files, the risk of important data loss or potential harmful interceptions from outside sources is reduced.

4. Pilot Solution

After exploring available data acquisition options related to the proactively oriented DTws, we have concluded that a complex simulation task cannot be confined to a single source of production data. The ability to exploit multiple data acquisition methods simultaneously is necessary for carrying out accurate simulations. The most important result of our analysis was comprehending the appropriate applications of data acquisition methods for specific types of production data. For example, while production orders in the form of CSV data are only needed during the initiation process of a simulation task, a permanent connection to the PCS database has proven to be mandatory to identify and potentially react to any ongoing changes inside the PrS during the simulation process. Furthermore, it seems that capturing the real-time images of the production system through raw data located in the PLCs is imperative for a correct setup of the initial DTw state. Lastly, having an option to alter the existing model through ECFs for the specific scenario, whenever necessary and without directly modifying the base model, has proven to drastically affect how frequently we were able to simulate different production outcomes. However, when combining all the data acquisition methods described in this paper, even though the majority are sufficiently functional in an offline mode, the necessity of a permanent connection to the PrS database makes the implementation of our pilot solution in an environment which allows this type of connection a fundamental requirement. This presents additional hardware- as well as software-related challenges. The main challenge being the necessity for data acquisition process supervision by a skilled operator with real-time access to all related systems and the ability to perform adjustments in a timely manner. The biggest challenge related to shop-floor hardware was its age and wear. A similar occurrence can be identified in current-age SMEs, where hardware updates are not performed regularly due to the high costs of an ever-evolving industrial market and associated technology [47]. On the other hand, an overarching technological challenge related to software is the safety and reliability of used methods when exposed to external influence. A temporary solution to this problem was to keep the proposed approach in the laboratory environment for the duration of this research, although, it is important to note, that safety of vulnerable data is of the utmost importance when implementing any new technology into an ongoing production process [48]. To help alleviate time constraints, various alarms and control points have been set up throughout the entire data acquisition process monitoring failed or corrupt data file creation.

Table 1. Application of proposed methods for the first use case.

Transfer Method	Production Orders	Supervisory Data	PLC-Level Data	Detailed Process Data for Simulation
CSV	(+)	(*)		(*)
Database	(*)	(+)
UDP/TCP/OPC		(*)	(+)	(*)
ECF				(+)

(+)—chosen method for the proof of concept. (*)—method only partially viable for the specified type of data.

displays the proposed data transfer method allocation for every data type required for successful production process simulation.

Our proposed methodology was empirically validated across two distinct production systems, each presenting unique operational characteristics. The initial system under investigation focused on the granular tracking and movement of individual products throughout its operational flow. In contrast, the second system’s primary objective was the optimization and dynamic adjustment of workload distribution among automated guided vehicles (AGVs) and human operators.

The inherent variability in data provision within the MES across these two systems necessitated minor adaptations in data acquisition protocols. Despite these system-specific adjustments, the fundamental methodology for data acquisition remained consistent. This methodological uniformity across diverse operational contexts suggests a high degree of generalizability for our analytical framework.

4.1. Use Case #1: Agro-Food and Beverages Training Model

For the first model, the extraction of topological data was performed using two different approaches. Initial system parameters, such as the connections between production machinery, their spatial coordinates or the sequence of performed operations, were directly integrated into the simulation environment without requiring extensive pre-processing. However, the more intricate aspects of the fluid system, including tank levels and flow rates, along with precise positional data related to individual products within the PrS, necessitated a more detailed extraction process. This involved generating CSV files containing comprehensive product-specific data and utilizing ECFs to capture the real-time operational states of the machinery within the PrS. The final implementation of the simulation model, including an indication of individual data type utilization, is represented in Figure 7.

The section of our simulation model dedicated to PO data integrates raw input from the MES. This data is then separated into singular values, which are subsequently allocated to individual products as they enter the PrS, or, in our case, the simulation model. Production level data, which provides a real-time snapshot of the PrS at the precise moment a simulation request is initiated, represents a critical component of each specific production scenario analyzed. This data was seamlessly integrated into the simulation model via the transport communication layer of the shop-floor PLCs.

The database interface within our model facilitates a real-time comparison between the current state of the simulated scenario and the anticipated outcomes. This interface presents comprehensive information to the operator, including details regarding the types and volumes of both planned and completed products.

Finally, the analytical and monitoring functionalities embedded within our model enable expeditious generation of reports and data files. These files can be subjected to further in-depth analysis after the simulation process is concluded. It is important to note that this analytical data is generated internally by the simulator itself and is not extracted from the physical PrS, serving instead as a direct reflection of the ongoing simulation’s performance.

Exploration of possibilities for data utilization and identification of the scope of data, which can be seamlessly integrated directly into the simulation model without the necessity of data pre-processing algorithms, could be considered as the main takeaway from this implementation. Within the context of a production system which consists of discrete (individual products) and continuous (filling material) elements, it is important to distinguish between the static and dynamic parts of the production process. The processing machines, transport stations or robotic manipulators could be considered static, as the likelihood of changes in the shop-floor topology during an ongoing production is minimal. On the other hand, movement of individual products or the flow of resources used during the production process is not pre-defined, as these are dependent on the production plan at the moment of the production snapshot in the PCS. Static elements fall into the data category, which is often modeled in the simulator, and serves as a base structure for the movement of aforementioned dynamic elements. Furthermore, as mentioned by Bambura (2020) [49] in their research, the importance of storing and accessing relevant process data related to products or machine states in some form of database is important for near-real-time simulation of a production system. Furthermore, a study by Wang et al. (2023) [50] provided an in-depth analysis and discussed the importance of action adjustments and work reassignment for system components in relation to predictive maintenance.

As the data required for simulation is being collected locally, it is possible to establish an architecture in which the delay between the simulation request and the process of carrying out the production simulation is seemingly non-existent. This type of architecture supports the idea of the proactive approach to simulation, where identification of potentially unexpected production outcomes could occur.

4.2. Use Case #2: Sub-Assembly Line of a Just-in-Time Production Process

Building upon the methodological framework described in this paper, a similar approach was then used with a functionally and topologically dissimilar PrS. The variability between not only the tested systems but also any PrS in general excludes the possibility of universal applicability for our proposed approach. While not being able to create a plug-and-play solution, the data acquisition process itself demonstrated remarkable adaptability, requiring only minor adjustments when transitioning to the new PrS. Due to the differences between the two investigated systems, a new DTw as well as new data processing interfaces had to be created.

The simulation model for this case study, even though simpler in terms of representation, fulfilled a unique requirement for abstraction and design of background calculations. Notably, this system was a sub-assembly line within a larger production environment, focused on a Just-In-Time (JIT) production strategy. The time-sensitive nature of JIT processes amplified the impact of any adjustments or interventions, regardless of their scope. Due to this fact, exploration and simulation using different scenarios, facilitated through adjustments to various attributes using ECFs, were limited to a notable extent; however, the enabled utility for rapid experimentation and validation still positively contributed to the overall agility of the DTw. Data utilization in our second system is showcased in Figure 8.

A key simplifying factor when creating a model for the second production system was the absence of fluid dynamics. Unlike the first PrS, this implementation allowed for a higher degree of abstraction in certain sections of the DTw, which further lowered the computational requirements for background processes without compromising its accuracy, while achieving the primary goal of the DTw: proactivity in production simulation.

A significant advancement in the data acquisition strategy for this system involved the direct utilization of an OPC UA server for real-time tracking of automated guided vehicles (AGVs). This approach exploited the inherent functionality of the AGVs’ internal control systems and/or their associated fleet managers, which were designed to continuously publish their positional data [51]. This continuous stream of positional data (e.g., coordinates, velocity, status) was then leveraged by the manufacturing execution system (MES). The MES acted as an OPC UA client, subscribing to and collecting this dynamic data from the AGV’s OPC UA server. This enabled the MES to generate snapshots of the current system status, which were then transmitted to the simulator [52], providing the DTw with up-to-date data on AGVs.

A similar approach was used by Zheng et al. (2019) [53], where they employed an OPC UA technology to gather data related to mechanical arms located within their respective manufacturing system.

The two presented iterations of our proposed methods adhere to the majority of recommendations and standards discussed in the ISO 23247 standard. Figure 9 showcases areas which our solution managed to incorporate (marked green). The remaining functional entities (FEs) are subject to future implementation.

5. Conclusions

This paper presented a unique method for facilitating data integration between a production system and its DTw. When compared to the existing case studies and research reports, we proposed a unique data type allocation for individual acquisition methods, while also incorporating a broader range of systems. While the proposed approach was specifically tailored to the presented use cases, several aspects offer reusable general guidelines for other systems, as demonstrated through testing on two distinct systems. Guidelines that can be deduced from our research can mainly be viewed as reference points for data allocation when attempting to build a DTw for an existing PrS. Our research indicates that a truly universal method applicable to all production systems is only partially achievable, primarily in the form of general guidelines, which can be derived from our procedures. This limitation stems from the inherent distinctive character of each production system, varying from topological configurations to data storage methodologies, therefore demanding custom-made solutions.

We have successfully applied and automated the proposed data acquisition methods, which lead to a fully functional simulation-based DTw with a focus on achieving proactivity in production control and adherence to the latest ISO standards.

The implementation, however, faced a few challenges and limitations, mainly related to old and outdated hardware throughout the production systems. Many of these challenges had to be overcome through the implementation of various software adaptations, which resulted in making the proposed methods a bit more system-specific than generally applicable. This was, however, a sub-optimal solution to the underlying problems, but, due to the high financial requirements of updating the old hardware, it was evaluated as a more suitable solution for the purpose of carrying out the necessary research.

Future research will focus on the optimization and thorough performance testing of these methods and algorithms.