A Novel Method for Simulation Model Generation of Production Systems Using PLC Sensor and Actuator State Monitoring

Abstract

This article proposes and validates a novel methodology for automated simulation model generation of production systems based on monitoring sensors and actuator states controlled by Programmable Logic Controllers during regular operations. Although conventional Discrete Event Simulation is essential for material flow analysis and digital experimentation in Industry 4.0, it remains a resource-intensive and time-consuming endeavor—especially for small and medium-sized enterprises. The approach introduced in this research eliminates the need for prior system knowledge, physical inspection, or modification of existing control logic, thereby reducing human involvement and streamlining the model development process. The results confirm that essential structural and operational parameters—such as process routing, operation durations, and resource allocation logic—can be accurately inferred from runtime data. The proposed approach addresses the challenge of simulation model obsolescence caused by evolving automation and shifting production requirements. It offers a practical and scalable solution for maintaining up-to-date digital representations of manufacturing systems and provides a foundation for further extensions into Digital Shadow and Digital Twin applications.

1. Introduction

The advent of Industry 4.0 has significantly reshaped industrial manufacturing by integrating physical systems with advanced digital technologies. This fourth industrial revolution is characterized by the deployment of Cyber–Physical Systems (CPSs), the Internet of Things (IoT), Artificial Intelligence (AI), cloud computing, and big data analytics, which collectively facilitate the development of intelligent, interconnected, and highly automated production environments. These technologies are designed to enhance system flexibility, operational efficiency, and resilience. A fundamental component of this technological landscape is the Digital Twin (DT), defined as a dynamic virtual representation of physical assets, processes, or systems that is continuously synchronized with real-time data [1,2,3,4]. DTs have become integral to modern manufacturing operations, enabling predictive maintenance, process optimization, and informed, real-time decision-making. As noted by Thürer et al. [5], DT architectures are evolving from centralized, static representations to decentralized systems that incorporate local data processing and Programmable Logic Controllers (PLCs), thereby offering improved scalability and adaptability in complex manufacturing networks. Discrete Event Simulation (DES) remains a core methodological approach in the modeling, analysis, and optimization of manufacturing and logistics systems. Despite its proven utility, the traditional implementation of DES typically necessitates detailed process mapping and expert knowledge for model development and calibration. This process is often time-consuming, resource-intensive, and heavily reliant on manual intervention. Even with the widespread use of industrial sensors and Supervisory Control and Data Acquisition (SCADA) systems, the conversion of operational data into valid simulation models poses a considerable challenge. Automating this process is particularly pertinent within the domains of smart manufacturing and DT applications, where the ability to rapidly generate and adapt models in response to real-time data is crucial [5,6].

In light of these developments, there is a growing demand for manufacturing systems that are not only flexible but also capable of autonomous and real-time decision-making. DTs and DES have emerged as pivotal tools in supporting both strategic planning and operational control. Nevertheless, the inherent limitations of DES—namely, the extensive effort required for model creation, validation, and maintenance—remain a critical bottleneck, often impeding broader adoption and scalability. This research addresses these limitations by examining the feasibility of generating simulation models automatically, relying exclusively on data acquired during normal operation, without the need for prior system-specific knowledge, manual modeling, or process surveys. The objective is to reduce reliance on domain expertise, streamline the model development process, and support both real-time and long-term applications through efficient, scalable, and accurate simulation frameworks.

2. Literature Review

The inefficiencies are particularly pronounced when simulation models are developed for singular, non-recurring planning purposes—often called “throw-away” or “stand-alone” models. As noted by Ryan and Heavey [7,8], the typical development process adheres to the so-called “40–20–40 rule”, wherein approximately 40% of the effort is allocated to data collection and preparation, 20% to model construction, and the remaining 40% to simulation experiments. This distribution underscores the disproportionate emphasis on data handling within conventional simulation practices. Due to the significant proportion of time and resources dedicated to data acquisition, numerous studies have sought to streamline this phase through automation to expedite model creation and enhance the overall feasibility of simulation-based approaches. A central aspect of this automation is the capacity to extract relevant data and control logic directly from existing industrial control and information systems, particularly those integrated into contemporary automated manufacturing environments.

2.1. Challenges of Process Simulations

Several studies have converged on DES model creation, revealing substantial advancements while simultaneously identifying persistent challenges. Elnadi and Abdallah [9] provide a meta-perspective, noting that although technology is often the focus of Industry 4.0, organizational and managerial readiness are equally vital. Simulation-based tools must align with these broader enablers and account for the complexity of transformation processes. A key research gap is the lack of frameworks that incorporate organizational factors into simulation-based decision support systems. In their agenda-setting literature review, Vieira et al. [10] emphasize that automated model generation, data exchange automation, and visualization are the most critical features needed for DES to fulfill its role in Industry 4.0. While simulation tools are well-established, they note that the lack of integration with live production data and the inability to self-update restrict their relevance in dynamic environments. Reinhardt et al. [11] provide a broad survey of automatic simulation model generation (ASMG) in discrete manufacturing, emphasizing that manual synchronization between real systems and simulation models is inefficient and error-prone. They classify ASMG methods by data source (e.g., Computer-Aided Design—CAD; Manufacturing Execution System—MES, PLC) and retrieval techniques (e.g., machine vision, sensor data), but highlight a critical gap: existing models often suffer from incomplete data and poor adaptability, limiting their utility in dynamic environments. Extending this, Friederich et al. [12] identify data requirements as a foundational challenge for generating dynamic models via process mining. They argue that while existing process mining approaches can capture components of a manufacturing system, they often fail to represent multi-perspective models that integrate material flows, machine behaviors, and degradation states. Kattenstroth et al. [13] further reinforce this by outlining the implementation challenges of DES-based Digital Factory Twins (DFTs). Their systematic literature review identifies that model adaptability and usability across lifecycle stages are not sufficiently addressed in current methods. Particularly, small and medium-sized enterprises (SMEs) face barriers related to resource intensity and expertise requirements. Kim et al. [14] address the usability gap by proposing a user-level customized modeling environment that supports different modeling paradigms (icon-based, parameter-based, and code-based) tailored to users’ expertise. Their framework allows non-experts to participate in model development, thereby promoting broader adoption of simulation technologies. However, the absence of seamless integration with real-time data remains a limitation. Gajsek et al. [15] take a novel approach by combining Industry 4.0 maturity models with DES to guide companies through digital transformation. Their methodology enables simulation-based evaluation of maturity scenarios, but the lack of automation in modeling and scenario generation poses a bottleneck for wide-scale implementation.

2.2. Automated Model Generation Approaches

Section 2 synthesizes findings across multiple recent studies, focusing on automated simulation model generation, especially from PLC and event data. Lugaresi and Matta [16] identified the core stages of simulation model generation—data collection, process topology discovery, parameter estimation, control policy extraction, model conversion, and validation—and proposed a structured framework to automate this pipeline. Their approach employed process mining to infer system logic and emphasized the necessity of “model tuning” to counteract over-detailed, low-utility representations, often referred to as the “spaghetti model” problem, integrating heuristics and score-based filtering mechanisms grounded in manufacturing system properties. Based on their previous work, Lugaresi and Matta [17] introduced a refined method for the automated discovery and generation of DTs for manufacturing systems, incorporating both structural and parametric information from event logs. A central contribution of this work is the ability to adjust the granularity of the generated model, ensuring relevance and usability for various decision-making contexts. The authors demonstrated that many existing approaches either rely heavily on expert-defined templates or fail to generalize across different manufacturing scenarios. Their proposed method bridges this gap by enabling the automatic inference of both system topology and control logic, while supporting modular adaptation to specific use cases through model tuning mechanisms. Furthermore, one of their most recent articles on the subject (Lugaresi and Matta [18]) addresses a critical limitation in earlier process mining approaches—namely, their reliance on “flat” event logs with single-object identifiers. In complex production systems, especially those involving assembly operations, multiple interacting material flows and changing identifiers make traditional techniques ineffective. To overcome this, the authors adopt an Object-Centric Process Mining (OCPM) paradigm, which enables the discovery of relationships across diverse object types and supports modeling non-linear, converging flows typical in assembly systems. The novelty of their contribution lies in formalizing a graph model generation approach that incorporates blocking conditions, which are typically omitted in simplified representations. Popovics et al. [8,19] proposed a comprehensive approach to automating DES model generation and validation by leveraging control-level and execution-level data. Their 2012 study demonstrated that PLC code and MES data can be used to extract system topology, control logic, and parameters, enabling automated model creation. Through grammar-based code analysis and statistical evaluation of historical data, they generated simulation models that closely mirrored real system behavior in short-term forecasting scenarios. Extending this work, their 2016 paper introduced a generic data structure based on the ISA-95 standard to support simulation tool independence and enable automated model validation. The proposed EasySim framework facilitated modular model development and objective validation using Key Performance Indicators (KPIs). By comparing simulated and historical data under deterministic and stochastic conditions, they demonstrated that automated models could replicate real system behavior with high fidelity while emphasizing the importance of continuous model updates for long-term accuracy. Castiglione [20] introduces an event-centric process mining approach based on Event Relationship Graphs (ERGs), which enables fast and accurate modeling of complex manufacturing systems with multi-product flows, re-entrant structures, and stochastic rework. By utilizing event logs and known sensor placements, the method minimizes modeling time and supports real-time updates of digital models, making it well-suited for rapidly changing production environments. Zhu et al. [21] propose a state reconstruction-based model generation technique that overcomes the limitations of previous process mining methods. Their approach reconstructs system states from event logs, capturing the dynamic behavior of production lines more precisely. This method enables accurate parameter estimation, particularly in the presence of state-dependent behaviors like blocking or capacity constraints and supports mild assumptions about data quality. Schlecht et al. [22] provide a comprehensive review of model generation strategies in Industry 4.0, emphasizing data acquisition and integration challenges. Their analysis identifies persistent issues such as high manual effort, tool dependency, and lack of standardization, especially for small and medium-sized enterprises. The study underscores the need for adaptable frameworks that can bridge the gap between physical systems and simulation environments in a resource-efficient manner. Carl May et al. [23] developed a flexible ASMG framework using process mining and machine learning techniques. The framework constructs Colored Petri Nets (CPNs) from event data and infers routing, control rules, and timing parameters with high fidelity. This approach is particularly effective in complex job shop environments and supports model updates aligned with system changes, validating its performance through key KPIs like throughput and utilization. Focusing on third-party logistics, Steinbacher et al. [24] present an ontology-driven ASMG system tailored for tender processes. By transforming spreadsheet-based planning data into material flow simulations, their approach allows logistics service providers to evaluate alternative layouts and resource configurations with minimal manual effort. This significantly supports rapid decision-making during competitive tendering scenarios. Lastly, Mousavi and Siervo [25] emphasize the integration of real-time SCADA data with simulation models to automatically compute KPIs like Overall Equipment Effectiveness (OEE) and Overall Line Effectiveness (OLE). Their middleware solution supports both real-time monitoring and predictive control, enabling dynamic performance assessment and proactive management in live production systems. The reviewed literature provides a cohesive view (

Table 1. Summarized key contributions.

Authors	Approach	Input Source	Output	Key Contribution
Popovics et al. [8]	PLC and MES Data Extraction	PLC codes, MES logs	DES model (conveyor system)	Extracts logic and structure from control systems.
Popovics et al. [19]	ISA-95 Framework	Structured data	Validated DES model	Tool-independent validation with KPIs.
Mousavi & Siervo [25]	SCADA-to-KPI Translation	Real-time SCADA data	Real-time simulation-linked KPIs	Supports predictive and management-level monitoring.
Lugaresi & Matta [17]	Process Mining + Tuning	Event logs	Adaptive DES model	Allows model granularity control.
Schlecht et al. [22]	Literature Review	Survey/test cases	Strategy taxonomy	Guidelines for method selection in SMEs.
Zhu et al. [21]	State Reconstruction	Event logs	Graph-based model	Tracks dynamic system states precisely.
Carl May et al. [23]	Process Mining + Machine Learning + Petri Nets	Event-based data	Validated simulation	Infers routing and timing with KPI alignment.
Castiglione [20]	Event-Centric Mining	Sensor event logs	Petri Net model	Models complex systems in seconds.
Steinbacher et al. [24]	Ontology-Driven Modeling	Planning spreadsheets	Third-party logistic (TPL) simulation	Low-effort modeling for logistics planning.
Behrendt et al. [26]	Data Mining + Machine Learning	Lot tracking data, machine states	Validated simulation	ASMG with machine learning-based equipment emulation.

) of recent efforts to automate this process using various data-driven methods.

3. Methodology

Conventional simulation modeling typically relies on a predefined system specification, encompassing the model’s requirements, the expected level of granularity, and its operational boundaries. Achieving this necessitates a comprehensive understanding of the underlying processes, decision-making logic, and the scope and type of data involved. The transmission, acquisition, and interpretation of such information often demand considerable human involvement, making the quality of the resulting model partially dependent on human-related factors. In this study, the problem is approached with the objective of minimizing human involvement, and the proposed methodology is validated through empirical investigation.

The objective of the experimental study is to examine the feasibility of automatically generating a simulation model of a production process, utilizing data acquired during regular operations. This approach aims to eliminate the need for comprehensive prior knowledge of the production system, on-site assessments, or modifications to the PLC code governing the production line. The underlying hypothesis is evaluated through a systematic analysis of various methodological approaches, concurrently addressing the following research questions (RQs):

• What is the minimum level of information required about the production system to enable automated model generation?
• Based on the generated model, what aspects of the system under investigation can be identified, and does the level of detail influence the model’s effectiveness?
• Is there a relationship between the complexity of the production system and the level of detail of the simulation model generated from the available data?
• From the perspective of automated model construction, does the simultaneous production of multiple product types have any impact?
• Can the entire system be understood by running and collecting data for each product type individually?
• In the context of automated model generation, does it matter whether different product types follow distinct production paths?
• Does the automatically generated model provide a sufficient basis for preparing a detailed offline simulation model, support the modeling process, and reduce the time required for its development?
• Is the automatically generated offline model suitable for the preparation of online Digital Shadow (DS) or DT models, thereby contributing to a reduction in development time?
• As a result of automated model generation, should the focus be on evaluating the model’s performance or verifying the generation process’s realism and accuracy?

3.1. Test Environment

The experimental environment was developed using multiple software platforms (Figure 1). Given the intention to evaluate the proposed method across production lines with varying layouts, the physical aspects of manufacturing are digitally represented using Factory I/O version 2.5.7. This environment contains only the physical component set, deliberately excluding predefined control logic to ensure maximum configurational flexibility. For similar purposes, there are several software types available on the market (Enterprise Dynamics 10.6, Process Simulate 2408, Visual Components 4.6, FlexSim 2025, Anylogic 8.9.0), but the authors have experience in the chosen software for this purpose. Control programming is carried out in Siemens TIA Portal version 17 Update 8, employing a 1518-4 PN/DP-type PLC. To simulate the manufacturing process, Siemens S7-PLCSIM Advanced version 4.0 SP1 is utilized to emulate the PLC within the digital factory environment provided by Factory I/O. Data collection and automated simulation model generation are conducted within a DES platform, specifically Siemens Tecnomatix Plant Simulation.

Communication between the different software systems is established using the Open Platform Communications Unified Architecture (OPC UA) protocol, which is considered the standard for Industry 4.0 also. Server–client architecture is implemented between individual test environment components. The OPC UA server employs a custom information model developed (Figure 2) using Siemens SiOME version 2.7.2.

The following tasks must be performed when preparing the test environment:

• Specifying the task to be performed on the production system.
• Parameterization of the production system: defining the individual components of the production system, identifying the sensors and actuators necessary for the operation processes.
• Production line design in Factory I/O.
• PLC code writing in TIA Portal.
• PLCSIM Advanced setup.
• OPC UA information model preparation and setup communication between software.
• Prepare the data acquisition in Plant Simulation.

The online process simulation and data collection are executed with the coordinated operation of all the software tools involved:

• Plant Simulation execution: Collect all production data from the OPC UA server during operation.
• PLCSIM Advanced execution: Simulate the system in Factory I/O using TIA Portal PLC code.

Subsequently, data filtering and automated model construction are performed offline using the data acquired in the DES. The effectiveness of the data filtering process is highly dependent on the consistency and precision of the underlying terminological framework.

3.2. Terminology Framework

In general, nomenclature refers to a structured system for defining the terms, names, and concepts used within a specific scientific or technical domain. Within industrial environments, implementing a unique data identification system is a common and necessary practice to ensure the traceability and support of operational processes. In the present context, such a system is indispensable for successful implementation, as data must be consistently defined according to a predetermined nomenclature to enable effective communication between software platforms. This nomenclature functions as a terminological framework, facilitating unambiguous communication and accurate interpretation of process-related information among technical stakeholders. The nomenclature primarily applies to variables associated with the physical system—namely input/output (I/O) elements—and its structure is designed to align with physical constraints and system capabilities. The proposed naming convention follows a standardized template as outlined below:

$$vv-x-yy-z-name$$

• vv: denotes the resource identifier, typically assigned incrementally according to the process sequence; its value ranges from 01 to 99.
• x: indicates the variable type, representing either input (i) or output (o).
• yy: refers to the sequence number of the variable within the given resource and type; this number usually reflects the order of operations and ranges from 01 to 99.
• z: designates the data type of the variable: boolean (b) or different types (d).
• name: a descriptive label that characterizes the role or purpose of the variable; its value may vary depending on the application, e.g., sensor, drive, process, etc.

Examples of variable names defined using this nomenclature include 01-i-01-b-sensor, 04-o-01-b-process, etc.

4. First Experiment

The production line examined in the first experimental scenario consists of a linear conveyor system (Figure 3) composed of five independently driven sections (01–05), of which two sections are associated with a processing station (02, 04). During the process, the products move in one direction and each product stops at each operation where machining takes place. Sections that do not contain a processing unit are 4 m in length and are equipped with presence sensors at both the entry and exit points. Sections incorporating a processing station are 2 m long and contain a single presence sensor positioned at the center. The sensors are normally closed, thereby continuously transmitting a logical high (true) signal under standard conditions. The conveyor belts operate at a uniform speed of 0.45 m/s. The transported product dimensions are 75 × 62.5 cm², and the processing time at each station is fixed at 3 s.

Throughout the process, the conveyor sections are controlled independently. When an entry sensor detects the arrival of a product, the corresponding drive is activated; when the exit sensor detects the product’s departure, the drive is deactivated. At processing stations, the drive is also stopped during the execution of the operation to ensure process stability. The product loading interval at the initial section of the conveyor is set to 45 s. This timing ensures single-piece flow during data collection, guaranteeing that only one product is present on the production line at any given time.

On the production line, 8 input and 7 output signals were defined in accordance with the established terminological framework (

Table 2. Input/output data of the production line (Exp. 1).

Resource	Input	Output
01	01_i_01_b_sensor 01_i_02_b_sensor	01_o_01_b_drive
02	02_i_01_b_sensor	02_o_01_b_drive 02_o_02_b_process
03	03_i_01_b_sensor 03_i_02_b_sensor	03_o_01_b_drive
04	04_i_01_b_sensor	04_o_01_b_drive 04_o_02_b_process
05	05_i_01_b_sensor 05_i_02_b_sensor	05_o_01_b_drive

). In all cases, the inputs are sensors, and the outputs are drives and processes.

4.1. Conventional Simulation Model

The primary objective of conventional modeling is to generate reference results supporting the validation of experimental findings. In this study, the modeling was conducted using Plant Simulation, an event-driven simulation tool operating within an object-oriented environment. Based on the configuration of the production line described earlier, a process simulation model was developed through conventional modeling methods (Figure 4). The modeling process involved the representation and logical interconnection of known production line components, such as conveyors and workstations. The purpose of the simulation is to analyze the performance characteristics of the production system. To achieve this, the necessary data for the parameterization of individual components were defined:

• Layout.
• Number of workstations.
• Processing times.
• Length and speed of conveyor belts.
• Product types.
• Loading sequence and intervals.
• Duration of the test period.

The results of the conventional simulation modeling indicate that, under the specified test conditions, the production line produces 40 units within a 30 min interval, and the average utilization rate of the workstations is approximately 7%. These outcomes serve as a baseline for evaluating and comparing the results and methodology of the automatically generated simulation model.

4.2. Data Collection

During the production process simulation, there is an online connection between Factory I/O, TIA Portal and PLCSIM Advanced (Figure 5). In the first experiment, process simulation was conducted within the online test environment at real-time speed (1×) for a duration of 30 min.

The communication protocol was configured during the simulation with a sampling and publishing interval of 10 milliseconds each. As data collecting was performed within Plant Simulation, these timing parameters directly influenced the resolution of the recorded signals. The outcome of the data collection process was a dataset comprising 1313 rows, each representing a signal change. The dataset includes the variable name (as defined by the terminological framework), its associated value, and the timestamp corresponding to the state change measured from the simulation start time.

4.3. Data Analysis (1: Methodology)

The objective of data filtering is to extract a sufficient volume of high-quality information suitable for automatic simulation model generation of the production line. The first step involved establishing a filtering methodology aligned with both the terminological framework and the experiment’s goals. The filtering process was carried out offline within the Plant Simulation environment. This experiment aimed to investigate whether it is possible to approximate the configuration and operational behaviors of the production system based solely on output signal data and their transitions and whether the performance of the resulting model approaches that of the physical system. Consequently, the specific goal of data filtering was to estimate both the number of distinct resources and their average operation times. The data filtering procedure consisted of the following steps:

• Filtering by Variable Type: Based on the terminological framework, variables classified as outputs (o) were isolated. The objective was to determine the total number of output signals. It should be noted that the number of outputs does not necessarily correspond to the number of physical resources, as a single resource may be associated with multiple outputs. The filtering process identified 7 outputs: 5 corresponding to conveyor drives and 2 to operational stations. Two of the resources (vv = 02 and vv = 04) were found to have two outputs each.
• Computation of Average Operation Times: For each output, signal transitions (true/false) were grouped by their respective timestamps. The time intervals between transitions were calculated, aggregated, and averaged to determine the mean operating time for each of the 7 outputs based on historical data (Figure 6). All available data points were included in the averaging process; no outliers were excluded.
• Simulation Time Determination: The difference between the earliest and latest timestamps in the dataset was computed. This value (29 min and 50.9169 s) was used as the input parameter for the runtime of the automatically generated simulation model.
• Estimation of Production Volume: The frequency of a specific value of the first variable in the raw dataset (regardless of its type) was calculated to estimate the number of products processed during the simulation. This analysis yielded a production count of 38 units for the evaluated period.

4.4. Automatic Model Generation

During model preparation, the simulation-specific objects “Source” and “Drain” were added to the model. These elements do not correspond to any physical component of the system under investigation but are structural elements required for simulation. As part of the model generation process, the outputs of the physical system were mapped and configured as individual “Station” objects, with operation times derived from the data filtering results. Additionally, parameter values within the “EventController” were modified based on the same data. The interconnection of model components was also performed automatically. The model generation process was limited to the resources involved in the production process and the associated simulation parameter, no additional constraints were applied. This led to the development of an automatic modeling framework capable of importing raw signal data and autonomously generating simulation models for linear production lines. The input parameters used during automatic model generation were as follows:

• Number and designation of outputs.
• Operation times associated with each output.
• Total simulation runtime.

Following model generation, the simulation was executed using the defined parameters. The results revealed that these inputs were insufficient for accurately replicating the behavior of the physical production system. Specifically, 131 products were produced during the simulation period, a significant deviation from the theoretically expected output of 38 units previously identified through data filtering. This discrepancy is attributed to the lack of control over the product input interval, resulting in a push-based flow in which products enter the system continuously and without regulation. To address this issue, the data filtering methodology was extended to include the estimation of product arrival frequency based on existing signal data. In this extended filtering step, the first occurrence of a “true” value in the output signal column of the dataset was identified under the assumption that each intervention signal corresponds to the presence of a product. By averaging the time differences between consecutive such events, the estimated product arrival interval was determined to be 46.1074 s. This value was subsequently incorporated into the revised model as an input parameter, automatically applied to define the interval of the “Source” object.

The updated simulation results were compared against both the physical system parameters and the outputs of the conventional simulation model. In the revised model (Figure 7), the number of products produced was 38, matching the value obtained through the earlier data filtering process and closely aligning with the conventional model result of 40 units. Nevertheless, it is important to emphasize that the effectiveness of the proposed methodology cannot be evaluated solely based on production volume.

4.5. Validation

Validation is required to assess the actual effectiveness of the generated model. In the absence of real production data, the conventional simulation model serves as the baseline for comparison. The primary objective is to evaluate the performance of the automatically generated model against that of the conventional model. The boundary conditions for this comparison include the product loading interval and the total simulation duration, which is set to one production shift (8 h). Validation (

Table 3. Conventional model results (Exp. 1).

Product Interval	No. of Items	Workplace 1	Workplace 2
0 s	9587	99.96%	99.90%
10 s	2876	29.99%	29.98%
20 s	1438	15.00%	14.99%
30 s	959	10.00%	10.00%
45 s	640	6.67%	6.67%
60 s	480	5.00%	5.00%

and

Table 4. Generated model results (Exp. 1).

Product Interval	No. of Items	Workplace 1	Workplace 2
0 s	2163	22.80%	22.82%
10 s	2163	22.80%	22.82%
20 s	1438	15.16%	15.18%
30 s	959	10.10%	10.11%
45 s	639	6.74%	6.75%
60 s	480	5.05%	5.06%

) was carried out across multiple variations of the loading interval.

When interpreting the results, it is essential to consider that the methodology underlying the automatically generated model treats each output as a distinct “Station”, which differs from the conventional “Conveyor + Station” structure used in conventional modeling. Despite this conceptual difference, the results indicate that from the third variation (from a 20 s loading interval), both the utilization of active workstations and the number of products produced begin to converge between the two models. This convergence is primarily attributed to the absence of length orientation in the automatically generated model. In the case of length-dependent system elements (e.g., distance, speed), substituting event triggering based on operation time can serve as an acceptable simplification—provided that the product loading interval exceeds the cycle time required for a product to traverse a segment. When this condition is met, the deviation between Key Performance Indicators of the two models remains below 1%, suggesting the generated model can be considered valid for such scenarios. The findings demonstrate that the data filtering methodology produces a sufficiently accurate approximation of system behavior, enabling performance analysis of the production line under varying load conditions. However, more detailed parameterization still requires user input. Overall, the proposed methodology proves effective in generating automatic simulation models for linear production lines based solely on output data. Its ability to represent length-oriented elements, however, is limited. Nonetheless, the approach offers significant potential to reduce the time required for model development. An additional insight for enhancing the efficiency of the data filtering process is that, prior to filtering, the starting and ending variables of the evaluation interval—and their respective values—should be defined in accordance with the terminological framework. This step is essential for delineating the process’s physical start and end points under investigation, particularly in cases where data collection does not begin at system startup or on an empty production line.

5. Second Experiment

The production line investigated in the second experiment is a multi-path conveyor system (Figure 8) composed of four (01–04) independently driven sections, and there are also designated operational locations in some sections (02, 03). The system handles three distinct product types, each following a unique routing path and utilizing different operation locations, resulting in varying throughput times. Product loading at the conveyor entry is random with respect to type and occurs at a frequency dependent on the time required for the preceding product to traverse the system. During data collection, only one product is present on the line at any given time.

Sections that do not contain (01, 04) at an operation station are 4 m in length and are equipped with presence sensors at both their entry and exit points. The first non-operational section (01) also includes a color sensor and an associated routing and ejection mechanism. The sections with operation (02, 03) locations are 6 m long, arranged in parallel, and are equipped with presence sensors at both ends. The conveyor speed is uniformly set at 0.6 m/s, and product dimensions are 37.5 × 37.5 cm². Throughout the production process, each conveyor section operates independently. When a sensor detects a product, the drive mechanism is activated; when no product is present, the drive halts. Additionally, conveyor movement is paused at each operation station for the duration of the respective processing activity. One of the operation sections (02) contains a single workstation (WS3), while the other (03) includes two workstations (WS1, WS2), each associated with an individual presence sensor (

Table 5. Product–workstation matrix (Exp. 2).

Product/Workstation	WS 1	WS 2	WS 3
Type 1	-	30 s	-
Type 2	10 s	30 s	-
Type 3	-	-	60 s

). The section (02) with one operation processes (WS3) a single product type (Type 3). In contrast, the section (03) with two operations handles two different product types—one (Type 2) processed at both stations (WS1, WS2) and the other (Type 1) at only one (WS2). Sensors are open by default and generate a signal upon detecting a product.

Based on the terminological framework, 13 input and 8 output signals were identified and defined for the production line (

Table 6. Input/output data of the production line (Exp. 2).

Resource	Input	Output
01	01_i_01_b_sensor 01_i_02_d_sensor 01_i_03_b_sensor 01_i_04_b_sensor	01_o_01_b_drive 01_o_02_b_process
02	02_i_01_b_sensor 02_i_02_b_sensor 02_i_03_b_sensor 02_i_04_b_sensor	02_o_01_b_drive 02_o_02_b_process 02_o_03_b_process
03	03_i_01_b_sensor 03_i_02_b_sensor 03_i_03_b_sensor	03_o_01_b_drive 03_o_02_b_process
04	04_i_01_b_sensor 04_i_02_b_sensor	04_o_01_b_drive

). In all cases, the inputs are sensors, and the outputs are drives and processes.

5.1. Conventional Simulation Model

A conventional simulation model was also developed as part of the second experiment to establish a reference for validating the automatically generated model. Based on the defined structure of the production line, a process simulation model was created using conventional modeling techniques (Figure 9). This involved mapping the known production processes and system components. The objective of the simulation was to evaluate production line performance, and to achieve this, the necessary input parameters for sub-component configurations were as follows:

• Layout.
• Number of workstations.
• Processing times.
• Length and speed of conveyor belts.
• Product types.
• Loading sequence and interval.
• Control logic.
• Duration of the test period.

The conventional simulation of the production line yielded 25 completed products over a 30 min test period. Average workstation utilization was approximately 6%, 35%, and 13%, respectively. These relatively low values are attributed to the product loading interval; however, modifying this parameter allows for further analysis of system performance. This simulation model serves as a robust benchmark for evaluating the performance and structure of the automatically generated model.

5.2. Data Collection

During the production process simulation, there is an online connection between Factory I/O, TIA Portal and PLCSIM Advanced (Figure 10). In the second experiment, process simulation was executed in an online test environment at a real-time speed (1×) for a duration of 30 min.

The communication protocol’s sampling and publishing intervals were both configured to 10 milliseconds. Online data collection was conducted using Plant Simulation. This process resulted in a dataset containing 786 entries, each corresponding to a signal change. Every entry recorded the variable name (in accordance with the terminological framework), the associated value, and the timestamp marking the state transition.

5.3. Data Analysis (2: Methodology)

In the second experiment, one of the objectives of data filtering is to apply the methodology developed during the first experiment to a non-linear production line and evaluate its effectiveness. The primary goal, however, is to develop a methodology for identifying multi-path and multi-product systems, which would enable more accurate detection and representation of length-oriented components. Specifically, the experiment seeks to answer the following: Can product types and routing paths be identified through product tracking and resource mapping? Furthermore, can the challenges related to length orientation be mitigated using this approach? In essence, is it possible to generate an approximate representation of the production line’s equipment and processes such that the resulting model’s performance approximates that of the physical system?

By applying the initial methodology (Figure 11) to the dataset generated from the online simulation of the second experiment, eight outputs were identified based on naming conventions: four correspond to conveyor drives and four to operational tasks. Using the same method, the total simulation duration was determined to be 30:37.003 s, while the product loading interval was calculated as 1:11.204984 s.

In multi-path systems, the original methodology proves insufficient for generating a viable model, as the extracted data do not provide enough detail to ensure model fidelity. Complex systems require additional data to enable the inference of machine layout and product type classification. Product type identification is typically integrated into the system in practical multi-path, multi-product semi- or fully automated production environments. The data filtering sequence developed here is based on this conception.

• To trace individual product processes, a product identifier (ID.x) is generated, associated with the initial symbol and its corresponding value previously used for identification. Each time this signal and the same value re-appears, the identifier is incremented by one. Between any two such events, the most recent ID value is recorded for all signal transitions on the line, effectively grouping changes into product-specific segments, hereafter referred to as ID groups. A prerequisite for this method is that only one product is present in the system at a time during data acquisition. To verify the correct segmentation of ID groups, it is ensured that the product identification signal (01_i_02_d_sensor) changes from 0 (no product detected) to a non-zero value only once per ID group. This condition was confirmed through validation.
• In the next step, each ID group is analyzed to determine the number of resources it utilizes, based on the terminological framework. This allows for inference of the production line’s potential layout by analyzing product routing paths. After identifying the resources per ID group, a consistency check compares the starting and ending resources. If starting resources differ across frames, it indicates multiple system inputs; if the end points differ, it implies various outputs. In this case, the results showed one input and one output. Further analysis of the routing directions identified two distinct paths: sequences 01–02–04 and 01–03–04. Since the initial and final resources are identical in both cases, it can be inferred that resources 02 and 03 operate in parallel.
• In addition to routing, identifying product types is equally important. Product type classification is based on the cycle times of the ID groups. A new product type is defined when the cycle time differs by more than 10% from existing categories. As a result (Figure 12), three distinct product types were identified, two of which follow the same path. The 10% threshold was chosen empirically, having proven effective without requiring further ratio testing.
• The subsequent step involves calculating the average resource lead times per product type based on ID groups (Figure 13). The relative distribution of product types is also derived from the ID groups: among 25 products, 44% were identified as Type_1, 20% as Type_2, and 36% as Type_3. The data confirms that product distribution is random rather than sequential. These outcomes provide the minimum necessary dataset for automatically generating a simulation model of the production line, incorporating both process variability and system layout complexity.

5.4. Automatic Model Generation

As in the first experiment, the “Source” and “Drain” objects were incorporated into the model during the preparation phase. In the model generation process, the physical system resources were represented as individual “Station” objects, with operation times specified per product type based on the results of data filtering. Additionally, parameter modifications were made in the “EventController”, where the simulation runtime was set, and in the “Source”, where the product arrival frequency was defined. Object connections were also generated automatically. The model generation process was limited to the resources and simulation parameters relevant to the system under investigation; no additional constraints were applied. The automatic model generation relied on data filtering outputs as input parameters, which included the following:

• Number and identification of resources.
• Configuration of resource layout (series or parallel).
• Operation times of each resource, differentiated by product type.
• Loading rules for each product type.
• Product loading frequency.
• Resource usage per product (routing).
• Total simulation runtime.

Following model generation, the simulation was executed (Figure 14), yielding a total of 25 completed products. This result aligns with both the filtered dataset and the output of the conventional model. However, the validity and efficiency of the method cannot be assessed solely on the basis of output quantity.

5.5. Validation

A validation procedure was conducted to assess the effectiveness of the automatically generated model. As with the first experiment, the conventional model served as the benchmark for comparison. The purpose was to evaluate the performance of the generated model under varying production loads in relation to the conventional model. In all scenarios, the simulation period corresponded to one production shift (8 h), with system load evaluated based on loading intervals and product variation.

When interpreting results, it is important to note that in the conventional model (

Table 7. Conventional model results (Exp. 2).

Product Mix	P. Interval	No. of Items	Workplace 1	Workplace 2	Workplace 3
	0 s	1370	16.56%	96.35%	92.78%
33% Type_1	30 s	958	11.08%	67.29%	65.17%
33% Type_2	45 s	639	7.19%	45.83%	41.57%
33% Type_3	60 s	479	5.49%	35.42%	29.13%
	90 s	320	3.40%	23.65%	19.37%
	0 s	958	33.53%	99.92%	-
100% Type_1	30 s	958	33.33%	99.92%	-
0% Type_2	45 s	639	22.22%	66.64%	-
0% Type_3	60 s	479	16.67%	50.00%	-
	90 s	320	11.11%	33.33%	-
	0 s	959	-	99.95%	-
0% Type_1	30 s	959	-	99.95%	-
100% Type_2	45 s	639	-	66.67%	-
0% Type_3	60 s	480	-	50.00%	-
	90 s	320	-	33.33%	-
	0 s	479	-	-	99.96%
0% Type_1	30 s	479	-	-	99.96%
0% Type_2	45 s	479	-	-	99.96%
100% Type_3	60 s	479	-	-	99.96%
	90 s	320	-	-	66.67%

), the performance of each workstation can be individually assessed. In contrast, the results of the generated model (

Table 8. Generated model results (Exp. 2).

Product Mix	Product Interval	No. of Items	Resource 02	Resource 03
	0 s	704	81.06%	60.72%
33% Type_1	30 s	704	81.06%	60.72%
33% Type_2	45 s	638	73.89%	54.30%
33% Type_3	60 s	478	54.61%	41.69%
	90 s	320	36.03%	28.48%
	0 s	637	99.97%	-
100% Type_1	30 s	637	99.97%	-
0% Type_2	45 s	637	99.97%	-
0% Type_3	60 s	479	75.27%	-
	90 s	320	50.18%	-
	0 s	530	99.97%	-
0% Type_1	30 s	530	99.97%	-
100% Type_2	45 s	530	99.97%	-
0% Type_3	60 s	479	90.46%	-
	90 s	320	60.31%	-
	0 s	385	-	99.97%
0% Type_1	30 s	385	-	99.97%
0% Type_2	45 s	385	-	99.97%
100% Type_3	60 s	385	-	99.97%
	90 s	319	-	82.86%

) are reported per resource, as defined by the data filtering methodology. For instance, Resource 02 encompasses the combined performance of Workplace 1, Workplace 2, and their associated conveyor section, while Resource 03 corresponds to the combined performance of Workplace 3 and its respective conveyor. Therefore, the interpretation of the results must consider this context.

The outcomes indicate that valid product count results were not achieved in every scenario across the tested combinations of product mix and loading intervals. This is primarily attributed to the absence of length orientation, consistent with observations from the first experiment. As the loading interval increases, the results of the two models converge. However, discrepancies in workstation and resource utilization remain significant. Consequently, the model can only be considered conditionally valid. When the loading interval approximates the time required for a product to traverse the production line, the model becomes suitable for estimating or planning product throughput. However, it remains unsuitable for a detailed evaluation of workstation performance. The proposed methodology is capable of extracting key structural and operational features—such as layout configuration (serial, parallel), product routing, and product classification—from data collected on non-linear, multi-path production lines. While it effectively reduces manual modeling effort, its application is more appropriate for high-level analysis rather than detailed performance evaluation of individual workstations.

6. Discussion

Experiments were conducted using two distinct data filtering methodologies to enable data-driven simulation model generation for production lines, and their results were systematically evaluated. In the first methodology, it was demonstrated that by identifying outputs—understood as sub-units of the production system where specific, direct (e.g., processing) or indirect (e.g., material handling) activities are performed on the product and filtering their relevant parameters—the essential data required for the modeling of linear production lines can be obtained. In contrast, the second methodology is based on filtering resources determined through product identification. These resources refer to sub-units where grouped (non-unique) operations—both direct and indirect—take place. This approach makes it possible to extract structural and functional information from multi-path (non-linear) systems, including the decomposition into linear segments, the identification of product routing, and the classification of product types. However, a key finding is that the second methodology alone is insufficient for generating the minimum dataset required for accurate simulation modeling. This is due to the aggregation of distinct outputs into generalized resources, which distorts the representation of production line performance. Nevertheless, this approach is well-suited for identifying flow directions and product variants, wherein each direction can be broken down into linear segments. A detailed analysis of these segments can then be conducted using the first methodology. The successful application of both methods depends on two key prerequisites: the development of a robust and consistent terminological framework, and the assurance of one-piece flow during online data collection. Based on the above, a hybrid methodology is proposed for data-driven ASMG. This combined approach integrates the strengths of both methods and consists of the following main steps:

• Development of a terminological framework.
• Online data acquisition with guaranteed one-piece flow.
• Application of the multi-path (non-linear) methodology to decompose the system into linear units.

  (a)

  Product identification and grouping of signals belonging to individual products (ID groups).

  (b)

  Classification of product types based on ID group cycle times.

  (c)

  Determination of product routes and identification of associated resources.

  (d)

  Layout identification (serial or parallel) based on route variations among ID groups.

  (e)

  Assignment of unique routing paths to each product type.

  (f)

  Decomposition of product flow into linear segments.

• Application of the linear method: identification of outputs and parameters per unit.

  (a)

  Identification of outputs within each linear unit.

  (b)

  Determination of output operation times for each product type.

• Structured aggregation of production data for model generation.
• Generation of the simulation model.

This methodology enables the automatic construction of a production line simulation model directly from operational data. The resulting model can represent the system’s actual performance and can be used for further “what-if” simulation scenarios in support of experimental analysis or operational planning. The approach reduces the need for in-depth system knowledge during the initial modeling phase and significantly shortens the development timeline. It is particularly valuable for remote or data-sensitive facilities, where direct access to processes may be limited. Furthermore, this method contributes to digital transformation by promoting the reuse of digitally collected data in modeling activities. It is important to note that Step 6, which pertains to model generation, may be executed either automatically or manually. The crucial factor is that the data derived in Step 5 must be of sufficient quality to allow accurate reconstruction of the system, regardless of the modeling approach.

In complex industrial environments, sensor data collected for simulation model generation is often subject to various sources of noise and anomalies, sensor drift, hardware faults, and asynchronous system behaviors. These disturbances can significantly affect the integrity of the extracted parameters and the reliability of the created simulation models. To effectively manage outliers, erroneous entries, or incomplete datasets, the proposed process must undergo refinement and validation using real-world industrial data. As such data is not currently available, addressing this aspect is identified as a prospective area for future research, potentially through collaborative efforts between academic institutions and industrial partners.

An additional observation from the data collection process relates to defining the variable data type (z). The current classification does not account for sensor default states (i.e., whether a sensor is normally open or closed), which is essential information for effective data filtering. Therefore, it is recommended that the terminological framework be extended to include this attribute, enhancing its utility for data-driven analysis.

Based on extensive computer modeling and related mathematical–statistical analyses, the research carried out results in the following answers to the questions formulated in Section 3 (RQs #1–#9). The minimum information requirements necessary for the effective application of the proposed methodology have been identified (Research Question 1, i.e., RQ #1). A correlation was found between system complexity and the level of detail in the ASMG, particularly with respect to the number of resources and operation locations, where the granularity of the model significantly influences the achievable simulation results (RQs #2, and #3). From the perspective of ASMG, product types are not critical, any sequence or combination can be used if the data is collected under single-piece flow conditions. Under these conditions, the production system’s structural layout and directional flow can be effectively reconstructed (RQs #4, #5, and #6). The generated ASMG provides a sufficient basis for further model parameterization and is suitable for the development of DS and DT models, offering a significant reduction in model development time (RQs #7 and #8). When evaluating outcomes, model efficiency and the accurate measurement of performance indicators are more relevant than achieving full machine-level fidelity or structural congruence with the physical system (RQ #9).

7. Conclusions

The primary objective established at the outset of this research—to determine whether it is feasible to construct a data-driven simulation model based solely on data collected during operation, without comprehensive knowledge of the manufacturing system, without prior surveying, and without intervention—has been demonstrably achieved. A novel methodology was developed for data-driven automated simulation model generation, the core concept of which lies in system-level decomposition into linear segments and the identification of operation locations. The two principal components of the methodology were independently validated through comparison with simulation models developed using conventional modeling techniques. The methodology is platform-neutral and can be used with PLCs from other manufacturers in addition to the Siemens PLC used in the experiments; the key is to produce properly structured data.

A potential avenue for improving the methodology lies in extending its applicability to datasets not limited to single-piece flow, allowing it to function effectively even when collected from continuous (“live”) production environments. Further experimentation may also focus on implementing the methodology’s individual steps through AI-based tools, where objectives may include improving efficiency, reducing processing time, and enabling the comparison of different toolsets. This approach supports a broader digital transformation initiative by facilitating the reuse of operational data in simulation modeling, offering particular benefits in scenarios involving remote operations or data-sensitive environments where direct access to systems may be restricted or undesirable. Future research will/would aim to address the following:

• Advanced statistical modeling of PLC and sensor data [27,28,29]: develop correlation analyses and pattern recognition techniques to refine automated simulation models, building on proven effective material property optimization methodologies, considering traditional statistical and fuzzy-based calculation methodologies.
• Experimental validation through controlled laboratory testing [30]: implement hybrid physical–digital testing protocols to validate simulation accuracy under varying production conditions, adapting approaches successfully used in railway track settlement studies.
• Model refinement using real-world feedback systems [31,32]: establish vibration-based calibration methods for Digital Twins, inspired by special engineering structure—i.e., rail damper—optimization techniques, to achieve precise alignment between virtual models and actual production line performance.
• Microstructural analysis [33]: incorporate material durability insights from thermite welding research to develop advanced algorithms for predicting equipment degradation in industrial settings.
• Energy optimization through data-driven workflows [34]: adapt regenerative energy strategies from railway systems to manufacturing processes, using real-time operational data to minimize waste and improve efficiency.
• Cross-disciplinary knowledge integration: combine statistical rigor, experimental validation, and industry-specific insights to develop self-optimizing simulation systems that reduce reliance on expert intervention while enhancing operational responsiveness.