# Collaborative-Iterative Digital Twin Benchmarking

Dimitri Renard, Dylan Baptiste, R Saddem, D Annebicque, Bernard Riera

► To cite this version:

Dimitri Renard, Dylan Baptiste, R Saddem, D Annebicque, Bernard Riera. Collaborative-Iterative Digital Twin Benchmarking. 19ème colloque national "Recherche et enseignement agiles pour une industrie soutenable", May 2025, Vogüé, France. hal-05230179

HAL Id: hal-05230179

https://hal.science/hal-05230179v1

Submitted on 29 Aug 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

<figure><img src="image_3.png" /></figure>

# Collaborative-Iterative Digital Twin Benchmarking

D. Renard<sup>a,b,*</sup>, D. Baptiste<sup>a,c</sup>, R. Saddem<sup>a</sup>, D. Annebicque<sup>a,B</sup>, Riera<sup>a</sup>

## 1. INTRODUCTION

A significant amount of research is being conducted on production systems to identify new methods and practices that optimize various factors of production. Model-based benchmarks exist within different community like discrete event systems (DES) community, as evidenced by existing literature [1], [2], [3]. However, these benchmarks are challenging to use for data generation and are visually distant from reality. A proposal for a benchmark focused on diagnosis had been initiated using the ITS PLC software [4], but this benchmark is now obsolete due to the unavailability of the simulation software. Therefore, it is relevant to propose a benchmark for an automated production system simulation and its control within the DES community. A preliminary, less detailed version of this benchmark was presented at a national conference in poster form [5]. The command-line interface makes it feasible to replicate the benchmark in most industrial settings where the production line is already operational. To demonstrate the first service, this benchmark is embellished with a dataset generated from this benchmark containing various sensor and actuator values, normal operating scenarios, and faulty behavior scenarios. Faulty behavior refers to the consequence of a fault affecting a sensor or an actuator. The long-term objective of this benchmark is to serve as a research basis for the digital twin (DT), which aims to aggregate individual services designed specifically for each system. To establish a standard for its use and evolution, it would be beneficial to develop a common research platform that can be duplicated across laboratories. This will enable development and reflection on the subject, making it accessible to anyone through a downloadable link. As a result, this benchmark will be available to everyone and can be used in the context of their own research.

The purpose of this article is not to provide a scientific approach, but a proposal for a common benchmark where

the various DT services can be assembled to iteratively try to create a common DT with service interactions.

The paper's structure is as follows: In Section 2, we will provide an overview of the current state-of-the-art in DT technology, highlighting its various components. Section 3 will delve into the concept of benchmarking and its multiple facets, examining its significance in evaluating DT performance. Finally, in this paper, we will conclude with a discussion on the implications of our findings and provide a summary of our conclusions.

## 2. STATE-OF-THE-ART DIGITAL TWIN

### 2.1. The Foundations of the Digital Twin Concept

The foundations of the concept of DT are present in the following definition, that of Grieves [6] "*The Digital Twin concept model [...] contains three main parts: a) physical products in Real Space, b) virtual products in Virtual Space, and c) the connections of data and information that ties the virtual and real products together.*". DT is an extension of capabilities that more accurately mirrors the real world in a virtual world to increase its possibilities. The 5-dimensional model of the DT is given by Tao and al. in 2018 [7], [8] "[*...A] complete DT [Digital Twin] should include five parts: physical part, virtual part, connection, data, and service.*". It takes up the real, virtual, and communication part of Grieve's definition [6] but breaks down the DT a little more with the notions of data and service. The increasing interest in industrial applications has led to a significant surge in the volume of publications on this topic, resulting in an exponential growth in the number of research papers and articles being produced [9]. Summaries on the DT are therefore essential to clarify this complex notion which is rapidly evolving [10], [11], [12], [13], [14], [15], [16], [17], [18]. The manufacturing world, which is very involved in the development of the DT, has resulted in a standard, ISO 23247 [19] defining the DT as

<footnote><sup>a</sup> Université de Reims Champagne-Ardenne, Reims</footnote>

<footnote><sup>b</sup> Prosys, Valenciennes</footnote>

<footnote><sup>c</sup> Seckiot, Paris</footnote>

<footnote>* e-mail: prenom.nom@univ-reims.fr</footnote>
"<manufacturing> fit for purpose digital representation of an observable manufacturing element with synchronization between the element and its digital representation". This definition is focused on the manufacturing sector, but it is a first step towards a more generalization and adoption of the concept of DT.

## 2.2. Digital Twin Framework

The definitions of DT help us to understand the philosophy of technology. However, they do not provide an understanding of the architecture that is required to implement it. The ISO 23247 standard defines a framework for DT in the manufacturing industry and in particular architecture. This architecture is broken down into four parts: Data collection & Device control, Core, User, and Cross-System.

We propose our vision of the DT to illustrate in another way the different bricks of the standardized architecture of the DT in Figure 1. The physical part of the framework represents the physical system and its environment. Virtual models of the virtual part describe the system using mathematical formulations, allowing them to reproduce the real behaviors of the system. Data collected by the data dimension - which includes real-world perceptions, historical records, and internal data - are used by services

to adjust the system in real-time, inform operators about its current state, and optimize its performance to maximize its efficiency. DT is limited to the perception of sensors (which can be humans) as well as their memory. This integration is achieved through a solid connection between the virtual part, the data dimension, and the services, requiring an adapted strategy for integrating the framework with the infrastructure's constraints.

This framework offers a clear understanding of the differences and complexity it introduces. The synergy between multiple services, adapted models, communication, and evolution throughout the lifecycle is crucial to enhancing system intelligence.

Nevertheless, addressing the complexities of service interactions, human integration, and data storage intelligence remains a major research priority for DT development.

A benchmark is essential to address technological challenges and propose methods for deploying Digital Twins (DTs) using our tools and methods developed in the community. The goal of this benchmark is not comparison but rather integration, impact measurement, and validation of these services on a system, ensuring their effectiveness together.

<figure><img src="image_4.png" /><figcaption>Figure 1: Digital Twin Framework</figcaption></figure>

# 3. DIGITAL TWIN BENCHMARK

In this section, we present the benchmark which consists of four parts:

- Description of these possibilities of use as a DT

- Description of the box sorting system: This part includes information about the box sorting system (Figure 2).

- Order Program: This part contains the control program used to control the box sorting system.

The program was developed in the Unity Pro environment and Tia Portal environment.

- Dataset for services description: This part provides a detailed description of a dataset that can be used in the benchmark. The dataset files are included in the download link.

To download the full benchmark, including the Factory IO scene, the Unity Pro / EcoStruxure Control Expert / Tia Portal control program, and the dataset files: [Link](link)
## 3.1. A benchmark for Digital Twin?

The system is created with Factory IO, a software that allows you to build your factory by assembling subsystems available in a library of components, and interfacing it with hardware or software Programmable Logic Controllers (PLCs) [20], [21]. Factory IO is easy to use and provides a simulator tailored to address research problematics with multiple drivers (Modbus TCP, S7 Protocol, OPC-UA...). Factory IO provides the possibility of injecting faults into both sensor and actuator devices. Its component library allows for the creation of a similar line to test the generalization of the DT services proposed. With a free 30-day trial, you can test our DT services without any costs on this benchmark.

A Digital Twin (DT) is characterized by the construction of a virtual environment that enables optimization and understanding of a real system. To achieve this, the proposed benchmark must be based on a real system. However, to propose an identical real system for the entire community, the real system considered in this benchmark will be simulated (Figure 2).

We have a real system simulated based on a model, which can then be used either in its original form or modified for digital twin services. A single instance of the model is real, but an infinite number of simulations can be instantiated by digital twin services.

<figure><img src="image_5.png" /><figcaption>Figure 2 - Box sorting system.</figcaption></figure>

Our proposal involves a dataset used in machine learning to train a diagnosis service (Figure 3). The Digital Twin (DT) can be extended with new services such as diagnosis and identification, new data sets can be created, or methodological approaches for designing control interfaces tailored to DT's specific challenges can be proposed.

<figure><img src="image_6.png" /><figcaption>Figure 3 - A benchmark for Digital Twin</figcaption></figure>

## 3.2. Description of the Box Sorting System

The purpose of the box sorting system (Figure 4) is to transport boxes from the inlet (feed) conveyor to the outbound conveyor by sorting them according to their height. The system has 15 sensors (C0 to C14) of the All or Nothing (AON) type to determine the size of the boxes (small or large) as well as the entry or exit of the boxes on the different conveyors (feed, intermediate and discharge) or on the turntable. A 16th "sensor" is present (C15), which allows you to know the status of the Factory IO simulation (see Table 2 and Figure 4).

<figure><img src="image_7.png" /><figcaption>Figure 4 - Overview of the box sorting system sensors.</figcaption></figure>

The system also has 7 actuators (A0 to A6) of the AON type to activate the different conveyors and the turntable (see Table 1 and Figure 6). A gantry on the inlet conveyor is composed of two sensors C1 and C2 at different heights (Figure 5). If the C2 sensor detects a rising edge, it means that the box is high enough and will be sent to the left by the turntable. If only the C1 sensor detects a rising edge, then the box will be sent to the right. The turntable consists of a motor allowing its rotation at 90 degrees, controlled by the A4 actuator. The C4 and C5 sensors indicate its orientation (0 degree for C4 and 90 degrees for C5). The C6 sensor indicates whether a box is loaded onto the turntable. The A2 and A3 actuators allow the gearbox to be moved forward and backward respectively on the turntable when it is in its initial position. When the turntable is rotated 90 degrees, A2 moves the box to the left and A3 moves the box to the right. All other actuators (A0, A1, A5, A6) are used to operate the conveyors. Each conveyor has a sensor at the beginning and the end of its journey.

<figure><img src="image_8.png" /><figcaption>Figure 5 : Sorting gantry</figcaption></figure>
<table><caption>Table 1 - The actuators of the box sorting system</caption><thead><tr><td>Actuators</td><td>Description</td></tr></thead><tbody><tr><td>A0</td><td>Infeed Conveyor</td></tr><tr><td>A1</td><td>Inlet Conveyor</td></tr><tr><td>A2</td><td>Turntable Rollers (Loading)</td></tr><tr><td>A3</td><td>Turntable rollers (Unloading)</td></tr><tr><td>A4</td><td>Turntable rotation</td></tr><tr><td>A5</td><td>Left-hand exit conveyor</td></tr><tr><td>A6</td><td>Right-hand exit conveyor</td></tr></tbody></table>

<table><caption>Table 2: The sensors of the box sorting system.</caption><thead><tr><td>Sensor</td><td>Description</td></tr></thead><tbody><tr><td>C0</td><td>Feed Conveyor End Sensor</td></tr><tr><td>C1</td><td>Low Light Curtain Sensor (Small Boxes)</td></tr><tr><td>C2</td><td>High Light Curtain Sensor (Large Boxes)</td></tr><tr><td>C3</td><td>End of Inlet Conveyor</td></tr><tr><td>C4</td><td>Turntable in the Loading position</td></tr><tr><td>C5</td><td>Turntable in Unloading position (90°)</td></tr><tr><td>C6</td><td>The presence of boxes on the turntable</td></tr><tr><td>C7</td><td>Sensor at the beginning of the right-hand output conveyor</td></tr><tr><td>C8</td><td>The sensor at the beginning of the left-hand output conveyor</td></tr><tr><td>C9</td><td>The sensor at the end of the right-hand exit conveyor</td></tr><tr><td>C10</td><td>The sensor at the end of the left-hand output conveyor</td></tr><tr><td>C11</td><td>Start button</td></tr><tr><td>C12</td><td>Reset button</td></tr><tr><td>C13</td><td>Stop Button</td></tr><tr><td>C14</td><td>Emergency Stop Button</td></tr><tr><td>C15</td><td>Simulation Factory IO Status Sensor</td></tr></tbody></table>

<figure><img src="image_9.png" /><figcaption>Figure 6 - Overview of the box sorting system actuators.</figcaption></figure>

### 3.3. Explanation of control program

As part of this benchmark, the system control program is also provided. This complies with the specifications already presented. The purpose of the box sorting system is to transport them from the inlet conveyor (A1) to the outbound conveyors (A5 and A6) sorting them according to their height. Small boxes should go to the left conveyor (A5) and large boxes to the right conveyor (A6).

As far as walking modes are concerned, these have been deliberately reduced. Pressing the Start button starts the cycle. Pressing the Stop push button must cause all boxes to be evacuated before the installation is shut down.

It should be noted that it is necessary to manage a FIFO stack to determine whether the box should go to the left or right conveyor because to determine the size of the box, the sensors are located at the beginning of the inlet conveyor (A1).

The entire control specification (operating mode, normal operation, and FIFO battery) was made of GRAFCET (IEC 60848) for several reasons:

- The GRAFCET language is known to all automation engineers and is suitable for implementation in a PLC, using IEC 61131 standard languages (SFC, LD, ST among others).

- It is easy to convert one or more GRAFCET into logical equations. The controller's program is then made up of logic equations that will be executed sequentially at each PLC cycle.

- Logical equations can be written very easily in ST, C, or Python, and conversion from one language to another is easy.

The specification therefore consists of 3 GRAFCET (Figure 7). It should be noted that the FIFO stack is voluntarily managed by a GRAFCET to allow an implementation only in logical equations, without using PLC-specific functions.

<figure><img src="image_10.png" /></figure>
<figure><img src="image_11.png" /><figcaption>Figure 7 - GRAFCET Controller Specification</figcaption></figure>

In the first GRAFCET (initial step 1), the operating mode is managed as well as the 2 output conveyors (A5 and A6). It should be noted that this GRAFCET also partly manages the counters for conveyors A1, A5, and A6 to know the number of boxes on the conveyors. Additionally, the P2 observer is noteworthy as it ensures a minimum distance between two boxes on conveyors A0 and A1.

The second GRAFCET (initial step 6) manages conveyors A0 and A1, as well as the turntable and its rollers (A4, A2 and A3).

The third and final GRAFCET (initial step 20) manages the FIFO stack. Once the pallet has completely passed through the C0 sensor, the presence of the C2 sensor can be used to determine if it is a large box. It should be noted that this GRAFCET can manage a stack of 6 pallets on conveyor 1. Steps 21 to 26 allow the knowledge of the position of the small boxes on conveyor 1. Similarly, steps 31 to 36 allow the knowledge of the position of the large boxes on conveyor 1.

The PLC program, written in ST, is also provided with the benchmark. The edge functions (up and down) have been reprogrammed to use only logical AND, OR, and NO operators and IF tests. The PLC program is structured as follows:

1. Calculation of transition functions

2. Calculation of step variables

3. Calculation of outputs

4. Updating variables for the next cycle's edge calculation

### 3.4. Overview of the saved dataset provided

We bring an application in the form of a dataset to the benchmark. The proposed dataset is a historization of system failure simulations. This dataset is intended to be used to create services for the DT of the system. It has now been used for diagnosis and identification purposes [22], [23]. The identification service uses the model directly, while for the diagnostic service, the model has been completed. However, the benchmark remains the same.

In the form of CSV (Comma Separated Values) files, this dataset can be downloaded from the CReSTIC website. Each file is a sequence of components' values and GRAFCET steps as shown in Figure 7. The names of the columns are self-explanatory. The sensor and actuator columns are named in the Table 2 and Table 1. The steps of GRAFCET are named by X+Step Number. The other columns allow you to know the failures in progress. Columns F1_X and F0_X, where X is the component name, are Boolean variables indicating a failure on component X. When F1_X = 1, it indicates that component X is faulty and is stuck to 1. Similarly, when F0_X = 1, it indicates that component X is faulty and is stuck to 0. If F1_X = 0 and F0_X = 0, then component X is not faulty. Also, we can translate F1 as forced to 1 and F0 as forced to 0. Finally, the last column: "Time", represents the time elapsed since the start of the recording, with millisecond accuracy. We have simulated bonding failures at 1 or at 0 for one component at a time. We consider that only one failure can occur at a time (single fault) in the system and that the failure is permanent (non-intermittent). A JSON (JavaScript Object Notation) file is also made available providing details of the recording sequence for each CSV file. This file contains the following information:

- "name": the name of the corresponding CSV file,

- "Behavior": the behavior of the system during the recording session may be set to "normal" if no fault has been injected or "faulty" otherwise,

- "bonding": the type of fault injected, for stuck to 1 "1" and for stuck to 0 "0",

- "Component" means the component on which the fault was injected,

- "blocking": a boolean indicating whether the system is set to a blocking state because of the fault injection,

- "critical": a boolean indicating whether the system is put into a critical state because of the injection of the fault, mainly by a tamping of the conveyors,

- "injection": A boolean indicating whether the fault was injected at the beginning of the simulation or after a few nominal cycles.

It is important to note that due to the technique of recording this data online, some value changes that appear to occur simultaneously are technically not at the PLC level. However, we guarantee that no sensor and actuator events are missing from the recordings. On the other hand, some events related to GRAFCET states are absent due to state transitions that are faster than the collection frequency.

## 4. DISCUSSION AND CONCLUSION

We propose a benchmark of an automated production system open access to have a common research framework. Initially, it will allow individual testing of its approaches. You may or may not use the dataset to implement your services on the system.

This benchmark serves as a sandbox for testing, sharing, and blending approaches within the digital twin
service ecosystem. It allows participants to propose
services that align with their methodologies on a common
platform. The ecosystem of stakeholders working with
this benchmark fosters the exchange of ideas, enabling
comparison, complementarity, and potentially the
creation of a more complex benchmark.

However, its goal is to solve the problems of DT. What
data is essential to collect from the order, how do the
services interact with each other, and what
characteristics should my command have? All these
questions around a scalable, and standardized DT will be
at the heart of the technology's issues. The system and the
control are therefore provided with an initial data history
as a basis that can evolve with the iterations of the
benchmark. How far can we collectively push the
intelligence of this system with the tools we are
developing in our respective labs? This is the question of
the purpose of this benchmark.

DATA AVAILABILITY

The benchmark is available via the link:
https://urlz.fr/ocAe (1.1Mb)

ACKNOWLEDGMENTS

This research and development work is partly carried
out within the framework of an industrial-academic
collaboration (CIFRE agreement) between PROSYST and
the CReSTIC (laboratory of the University of Reims
Champagne Ardennes), funded by PROSYST and the
National Association for Research and Technology.

REFERENCES

[1] A. Giua, 'A benchmark for diagnosis', presented at the WODES'08, 2007.

[2] M. Ghazel and B. Liu, 'A customizable railway benchmark to deal with fault diagnosis issues in DES', in *2016 13th International Workshop on Discrete Event Systems (WODES)*, Xi'an, China: IEEE, May 2016, pp. 177-182. doi: 10.1109/WODES.2016.7497845.

[3] A. Boussif and M. Ghazel, 'Diagnosticabilité des Systèmes à Évènements Discrets: Une Nouvelle Variante de l'Approche Diagnostiqueur', presented at the MSR 2017, Marseille, France, 2017, p. 15p.

[4] A. Philippot, 'Survey on diagnosis of a pick and place benchmark: Special session on diagnosis of Discrete Event Systems: Application on a benchmark', in *2011 3rd International Workshop on Dependable Control of Discrete Systems*, Saarbrucken, Germany: IEEE, Jun. 2011, pp. 25-28. doi: 10.1109/DCDS.2011.5970313.

[5] D. Renard, R. Saddem, D. Annebicque, and B. Riera, 'Poster : Benchmark d'un Système Automatisé de Production de type SED', presented at the Modélisation des Systèmes Réactifs, Toulouse, 2023.

[6] M. Grieves, 'Digital Twin: Manufacturing Excellence through Virtual Factory Replication'. Accessed: Feb. 22, 2024. [Online]. Available: https://www.researchgate.net/publication/275211047_Digital_Twin_Manufacturing_Excellence

[7] F. Tao, J. Cheng, Q. Qi, M. Zhang, H. Zhang, and F. Sui, 'Digital twin-driven product design, manufacturing and service with big data', *Int J Adv Manuf Technol*, vol. 94, no. 9-12, pp. 3563-3576, Feb. 2018, doi: 10.1007/s00170-017-0233-1.

[8] F. Tao, B. Xiao, Q. Qi, J. Cheng, and P. Ji, 'Digital twin modeling', *Journal of Manufacturing Systems*, vol. 64, pp. 372-389, Jul. 2022, doi: 10.1016/j.jmsy.2022.06.015.

[9] X. Liu et al., 'A systematic review of digital twin about physical entities, virtual models, twin data, and applications', *Advanced Engineering Informatics*, vol. 55, p. 101876, Jan. 2023, doi: 10.1016/j.aei.2023.101876.

[10] M. R. Enders and N. Hoßbach, 'Dimensions of Digital Twin Applications - A Literature Review', presented at the Twenty-fifth Americas Conference on Information Systems, Cancun, Mexico: Association for Information Systems, 2019. [Online]. Available: https://aisel.aisnet.org/amcis2019/org_transformation_is/org_transformation_is/20

[11] D. Jones, C. Snider, A. Nassehi, J. Yon, and B. Hicks, 'Characterising the Digital Twin: A systematic literature review', *CIRP Journal of Manufacturing Science and Technology*, vol. 29, pp. 36-52, May 2020, doi: 10.1016/j.cirpj.2020.02.002.

[12] I. Errandonea, S. Beltrán, and S. Arrizabalaga, 'Digital Twin for maintenance: A literature review', *Computers in Industry*, vol. 123, p. 103316, Dec. 2020, doi: 10.1016/j.compind.2020.103316.

[13] K. Y. H. Lim, P. Zheng, and C.-H. Chen, 'A state-of-the-art survey of Digital Twin: techniques, engineering product lifecycle management and business innovation perspectives', *J Intell Manuf*, vol. 31, no. 6, pp. 1313-1337, Aug. 2020, doi: 10.1007/s10845-019-01512-w.

[14] T. Y. Melesse, V. D. Pasquale, and S. Riemma, 'Digital Twin Models in Industrial Operations: A Systematic Literature Review', *Procedia Manufacturing*, vol. 42, pp. 267-272, 2020, doi: 10.1016/j.promfg.2020.02.084.

[15] C. Semeraro, M. Lezoche, H. Panetto, and M. Dassisti, 'Pattern-based Digital Twin for Optimizing Manufacturing Systems: A Real Industrial-Case Application', *IFAC-PapersOnLine*, vol. 54, no. 1, pp. 307-312, 2021, doi: 10.1016/j.ifacol.2021.08.157.

[16] E. VanDerHorn and S. Mahadevan, 'Digital Twin: Generalization, characterization and implementation', *Decision Support Systems*, vol. 145, p. 113524, Jun. 2021, doi: 10.1016/j.dss.2021.113524.

[17] Á. García, A. Bregon, and M. A. Martínez-Prieto, 'Towards a connected Digital Twin Learning Ecosystem in manufacturing: Enablers and challenges', *Computers & Industrial Engineering*, vol. 171, p. 108463, Sep. 2022, doi: 10.1016/j.cie.2022.108463.

[18] A. Sharma, E. Kosasih, J. Zhang, A. Brintrup, and A. Calinescu, 'Digital Twins: State of the art theory and practice, challenges, and open research questions', *Journal of Industrial Information Integration*, vol. 30, p. 100383, Nov. 2022, doi: 10.1016/j.jii.2022.100383.

[19] International Organization for Standardization, *ISO 23247-1:2021, Automation systems and integration — Digital twin framework for manufacturing — Part 1: Overview and general principles*, Geneva, Switzerland., 2021. Accessed: Feb. 27, 2023. [Online]. Available:

https://www.iso.org/obp/ui/#iso:std:iso:23247:-1:ed-1:v1:en
R. J. Mora-Salinas and H. G. G. Hernandez, 'Virtual labs: 5 ways to connect with Factory IO for mechatronics engineering courses', in *2022 IEEE Global Engineering Education Conference (EDUCON)*, Tunis, Tunisia: IEEE, Mar. 2022, pp. 485-490. doi: 10.1109/EDUCON52537.2022.9766615.

[21] B. Riera and B. Vigário, 'HOME I/O and FACTORY I/O: a virtual house and a virtual plant for control education', presented at the IFAC World Congress, Toulouse, France, 2017, pp. 9144-9149. doi: 10.1016/j.ifacol.2017.08.1719.

[22] A. Parant, D. Baptiste, R. Saddem, and A. Philippot, 'Data-based PLC Identification for IEC 61499 Implementation', in *13th International Workshop on Service-Oriented, Holonic and Multi-Agent Manufacturing Systems for Industry of the Future*, ANNECY, France, Sep. 2023. Accessed: Oct. 25, 2023. [Online]. Available: https://hal.science/hal-04225366

[23] R. Saddem, D. Baptiste, and A. P. W. Teingua, 'Autoencoder-based method for online fault detection in discrete-event class Production Systems', *IFAC-PapersOnLine*, vol. 58, no. 1, pp. 228-233, 2024, doi: 10.1016/j.ifacol.2024.07.039.