Building a digital twin of a micro-factory

How can we foresee the unforeseeable and prevent the impossible?

This is the open question to which I tried to bring some elements of an answer during a year spent at the Technische Hochschule Brandenburg laboratory in Germany, within the cybersecurity and steganography department.

Industrial systems have returned to the centre of our concerns over the past few years, in the face of the tense geopolitical context we are going through, and the recent cyberattacks on sensitive sites have only heightened the need to foresee, anticipate and assess the risks and consequences for the vulnerability and exposure of industrial control systems.

To prevent any risk in the industrial field, many current solutions aim at organising attack-response exercises. But all these exercises rely on an established model that must be faithful to reality, and cannot afford to be a mere imitation that only approximates the behaviour of a real system. When it comes to nuclear power plants, electrical facilities or even military installations, there can be no right to error, and this is where Cyber Ranges (virtual laboratories dedicated to cybersecurity) equipped with digital twins come in, true replicas of a facility that reflect its state and its behaviour in real time.

Having studied for almost six months, within a previous collaboration with ESAIP, the strengths and weaknesses of a proprietary Cyber Range solution^[1], I found it worthwhile to take the approach to its conclusion on a real physical facility by reproducing it entirely in virtual form. At the IoT laboratory of the Technische Hochschule Brandenburg in Germany, where this final-year project took place from April to September 2026, a full-scale industrial model developed by the company Fischer Technik was made available to me. I thus had a real playground to build the replica of a physical system as its computerised twin. Through this research project, I invite you to follow the twists and turns that accompany the creation of a “digital twin” of a physical industrial system.

In 2010, the Stuxnet attack raised the alarm about the risk of cyberattacks targeting industrial infrastructures, and since then the threat has kept moving from information systems towards the controllers, sensors and actuators that run factories, power grids and water treatment plants. In 2024, according to the Dragos report^[2], 1,693 ransomware attacks against industrial facilities were recorded, an 87 % increase in one year, and this is how a fine understanding of control chains, of their protocols and of their weaknesses has become an essential component of any industrial cybersecurity approach.

The project was integrated into the cybersecurity research group of the “computer science and media” department, headed by Professor Claus Vielhauer, whose work deals with information systems security, forensics and, more specifically, steganography and steganalysis, in other words the hiding of information in digital media and its detection. This work is part of a joint research programme of universities named ATTRIBUT, dedicated to the attribution of steganographic communications. The laboratory develops there methods for detecting and analysing covert channels. The question of the fidelity of the network flows of a replicated industrial system, the subject of this research project, found its place and its meaning there, since digital twins are true playgrounds for observing communications hidden within industrial protocols.

This final-year project followed on from a research project that I had started in September 2025 on Cyber Ranges and their use in the industrial field.

Within the laboratory of the TH-Brandenburg university in Germany, I had the opportunity to combine the physical and the virtual by having at my disposal a full-scale model of an industrial system driven by a programmable logic controller, or PLC. Together with the cyber research group, we came up with the idea of building a digital twin of the Fischer Technik factory, allowing the analysis of the communication flows of a virtual model in order to compare them with the data of the physical model present on site.

The interest of building such a virtual replica lies in the diversity of the communication protocols present on the physical solution. The factory relies on industrial communication protocols such as OPC-UA and MQTT.

In the background, the multiplicity of the physical solutions present, such as actuators tied to a Siemens S7-1500 programmable logic controller, the presence of a communication gateway using low-code communication interfaces such as Node-Red and MQTT, as well as a proprietary OT gateway (Fischer Technik TXT) aggregating MQTT, I2C and low-current PWM inputs, strengthened the motivations of the project by adding a real educational value about the universal character of the solution, which covers a large number of technologies used in existing industries.

Within the IoT laboratory of Brandenburg University of Applied Sciences, my final-year project followed on from the research work I had previously undertaken at ESAIP on the virtualisation of industrial peripherals. It drew upon the full range of competencies acquired over the past three years at my engineering school, and notably:

• Embedded systems programming, which in the present case centred chiefly on Siemens SCL, the solution being built around an S7-1500 programmable logic controller;
• Node-RED development for the network communication gateway;
• Programming of Raspberry Pi embedded platforms, carried out predominantly in Python;
• Reverse engineering, applied to the design of a substitute for the proprietary Fischer Technik TXT controller;
• Linux and distributed real-time operating systems, used to implement the sensor gateways feeding the digital twin, together with the simulated environmental sensors measuring temperature, gas concentration and humidity;
• C# development, employed to build a gateway simulating the physical behaviour of the factory through the entry points exposed by the Siemens controller.

Taken together, these competencies made it possible to construct the digital twin: a virtual replica of the physical plant. This objective, agreed with the research group, provided a reference framework against which communications originating from a synthetic environment could be analysed and compared with those produced by the physical one. It therefore required the virtual model to expose the same communication protocols — OPC UA and MQTT — and to exhibit the same behaviour under both nominal operating conditions and disturbances.

The principal challenges lay in gaining an exact understanding of the plant and its control system, both poorly documented by Fischer Technik, in order to identify the key characteristics governing the choice of replication model and the replication of the physical and network peripherals, so as to reproduce a data transmission chain as faithful as that of the real installation.

The main obstacles encountered were consequently the initial commissioning of a rig delivered in a faulty state, the reverse engineering of the proprietary modules, and the selection of an appropriate network capture protocol capable of yielding consistent and exploitable datasets. To these was added the replacement of a proprietary solution by an open-source one, a decision whose architectural implications bore directly on the quality of the resulting data.

The specification drafted in April, which called for an interface displaying the replicated plant in three dimensions, was thus scaled back to a more concise yet highly effective version based on a two-dimensional logical mimic diagram of the factory.

The research question fitting the stakes and objectives stated above was the following:

The provisional schedule, established during the week of 13 to 17 April, organised the project into nine groups of tasks associated with as many milestones: the functional and technical familiarisation with the factory, its commissioning and calibration, the comparative study of the frame capture possibilities, the capture and analysis of the field frames, the modification of the PLC programme for continuous operation, the design of a virtualisation architecture, the virtualisation itself, and finally the capture and exploitation of the data produced by the virtual model, this last part being carried out by my colleague Hirama Wohler within his own internship. Each milestone planned a deliverable, documentation, minutes or report, and the complete detail of the steps is given in appendix 8.

The core of this research project lies in the period shown in the diagram below, where the work carried out was the most intense because of the variable geometry of its success, which oscillated between achievement and failure.

According to the research of Ukwandu et al.^[3], completed by the formalisations of NIST^[4], four main approaches can be taken to design a Cyber Range.
Among these approaches, we find:

• Simulation, which consists in modelling the behaviour of the systems mathematically, representing 50 % of the solutions mainly studied. This approach is the safest and the least expensive, but it faces the difficulty of reproducing real-world infrastructures faithfully.
• Emulation, which corresponds to replicating the operations of a target system through a mirror system, representing 38 % of the solutions mainly studied. This approach offers a better level of fidelity and realism by simulating both the real infrastructure and its associated nominal behaviours, such as real-world network traffic and addressing.
• Overlay, which consists in using a whole existing network and infrastructure on which test and attack tools are superimposed, representing 8 % of the solutions mainly studied. This solution is the one with the most optimal levels of fidelity, but with a significant financial counterpart, since it implies having real physical equipment such as servers, OT systems, network and storage.
• The physical approach, which represents only 4 % of the solutions mainly studied, largely because of its extremely high costs.

As a formal definition, the digital twin is a virtual replica of a physical system reflecting its state and its behaviour in real time.

Originally, the digital twin was developed for predictive maintenance and process optimisation. Its application in the field of industrial security is booming, since it allows the creation of virtual copies of OT infrastructures with a view to conducting penetration tests, attack simulations and vulnerability analyses (pentest) without impacting the real production systems.
This concept thus allows a cost reduction in the research and development stages, but also an easier improvement of the quality and security of systems over a very short period of time.

If we must define its usefulness in cybersecurity in one sentence, the digital twin must meet the following rule:

The work of Tao et al., dating from 2019, surveyed the industrial applications of the concept, noting that the fidelity of a digital twin is characterised by measuring the quality of the synchronisation between the twin and its real model. This goes much further than a model judged on appearances, such as the graphical realism of a replica^[5].

It is precisely on this characteristic that I made it a point of honour to build a twin that does not merely satisfy expected behaviours like boxes to be ticked, but a twin that simulates its physical parts and interacts with them following a command from the PLC. This made it possible to highlight the defects that the real machine showed, but also other unsuspected ones that were hidden in the noise of the real world.

On the cybersecurity side, the work of Eckhart and Ekelhart dating from 2018 caught my attention because it referred to a precise, easily quantifiable approach based on specification-based state replication. The work invited running the real control programme on a replica whose state is aligned with its physical reference in order to detect the deviations and disturbances induced by an attack, by comparing the effects in the real world with those in the virtual world^[6]. This approach was expressed as a typology of uses: from intrusion detection to the validation of patches before their deployment in production. Their insistence on the value of a twin is fundamental, since it became the spearhead of the simulation developed: the cost of a twin lies in keeping it consistent with the installation it represents^[7].

Applying this methodology made it possible to reveal many errors in the programme designed by Fischer Technik, since it is by comparing the view of the real PLC and the fictitious one, going through each characteristic, that I was able to detect many programming faults that were silent in the real world.

Exploring the proposed methodology in more detail, the main criteria frequently used were the comparison between the real state and the replicated state (which goes without saying), the validation of any modification of the control programme before any loading into the real and virtual worlds, and the training of operators using systems that can be destroyed at will and whose state can be reset at any time.

Replicating an OT/IT chain is not limited to simulating a PLC: after replicating the heart, one must replicate the lungs of the system, such as the Node-RED gateway that interfaces the communications of each element of the factory, and the sensor station that sends the environmental data and the identification data of the processed workpieces. These two stations have a very specific architecture, that of a Raspberry Pi 4 running a Linux operating system and using an instruction set different from that of ordinary computers. Since the objective was to run their original software without modifying a single line, virtualising these elements required reproducing their physical architectures as well as their programmes.
One solution stood out: processor emulation. It makes it possible to “replicate” the behaviour of a precise architecture and of its associated instruction set. The instructions intended for a Raspberry Pi board under the ARM architecture are thus translated in real time into those of the host running the emulator. The tool used, a reference in its field, was QEMU, presented in 2005 and open-source^[8]. However, any translation comes at a cost, which in this case makes the emulated Raspberry Pi about ten times slower than its physical counterpart. This leads to longer programme start-ups and internal clock offsets, which was a secondary battle fought in the chapter of this research project devoted to time management.

In addition to the emulation, I had to replicate an inter-component dialogue, and more precisely that of the environmental sensor, the Bosch BME680, and that of the NFC reader, which in the real model used the I²C bus. Instead of creating a virtual component from scratch, which would have taken a considerable time, I preferred to use paravirtualisation, which allows an emulated machine and a host to communicate through a shared message queue. Through this channel, every frame is transmitted raw, and this allows a programme present on the host to answer requests as a sensor would in the real world. This approach is called virtio^[9] and, thanks to its extensive documentation, it was very easy to design the emulation of the sensors on a replica of an I²C bus^[10], since this approach provided for such a communication among its use cases. The replication of the sensors was thus based on the vhost-device project of the rust-vmm community^[11].
Each sensor, written in Python in our case, can thus communicate on a virtual I²C bus, which makes it possible to replicate its real behaviour faithfully. As the design of the twin progressed, a constant crept in among the sources of problems. Although it seems obvious to us, without a common reference it becomes a real nightmare, because many control and scheduling points depend on it. This constant is Time! The physical solution, like the virtual one, was spread over several organs, and it required a precise time reference common to each element. Lamport showed in 1978 that there was no common clock in so-called “distributed” systems and that, without this precious time reference, every order of events had to be reconstructed^[12].
We therefore needed a precise reference conditioning any coordination of events, as Kopetz points out^[13].
On our modern machines, connected to one another and sometimes thousands of kilometres apart, the question hardly arises, since a central atomic-clock server using the NTP (Network Time Protocol) protocol sets the pace. The Fischer Technik model depended on it^[14], which raised the problem of a transition to a closed virtualised environment where these central servers became inaccessible. The extent of the importance of time was measured when the PLC started refusing the commands coming from an NFC reader response whose timestamp was earlier than that of its command. Added to this was the simulated operation of the PLC through the proprietary Siemens solution, which only advances according to the co-simulation cycle modelling the physical behaviour, in our case the IoBridge written in C#. It was now necessary to add to the list of tasks a synchronisation of every internal clock of the elements of the factory, from the gateway to the PLC via the sensor station, which was no small matter.

This state of the art thus made it possible to draw a few hypotheses:

• One corresponding to functional fidelity, according to which a physical model of the organs of a system, not derived from a “raw” sequencing, is sufficient for a real PLC programme to run its complete cycle on it without any modification of its logic.
• One corresponding to protocol fidelity, according to which the emulation of the two Raspberry Pi boards coupled with their original software produces on the virtual network the same OPC UA and MQTT flows as those observed on the real network.
• One corresponding to temporal coherence, according to which a time synchronisation chain can keep the internal clocks of the virtual components aligned to the second, a condition required by the real-world programme.

The factory model on which the project was built is a demonstrator developed by the German brand Fischer Technik.
Its advantages are directly linked to the protocols and communication methods found in companies, such as OPC UA, widely used for industrial systems. The interest of using a scale model is its direct link between physics and automation, allowing various development teams specialised in one field to work on a concrete physical prototype.
In our case study, the model chosen by the research group was the Training Factory Industry 4.0 24V model equipped with the S7-1500 PLC.
This model offered us a wide range of industrial solutions and associated communication protocols.

Regarding its operating principle, here is a summary of the nominal machining cycle of a workpiece:

1. A red, blue or white workpiece carrying a unique RFID identifier is placed on a deposit zone (in comparison with the real world we would speak of raw material)
2. A pneumatic robotic arm moves this workpiece from the reception zone to the storage zone
3. A second robotic arm stores this workpiece – raw material – in a storage slot.
4. A customer / production manager orders the machining of a workpiece of a precise colour from the control interface of the factory.
5. A robot present in the storage bay brings the raw material to the machining zone
6. A pneumatic robotic arm takes the raw material and brings it to the machining station, made up of a multifunction oven and a milling machine
7. The various components of the finished product are transported by means of conveyors and pneumatic robotic arms
8. The finished product is then analysed and sorted towards its transport zone by means of conveyors
9. The finished product is moved to the transport zone by means of the pneumatic arm

The technical solution is made up of five main modules:

• The first is the brain of the system, represented by the Siemens S7-1500 programmable logic controller using physical I/Os coupled to the OPC UA protocol for the data acquisition and control chain.
• The second is an OPC UA – Node Red – MQTT communication gateway, provided by a Raspberry Pi 4 board running Linux; this communication gateway also acts as a Node Red web server displaying a graphical interface that controls the industrial process itself, such as the registration of new workpieces in the factory, the storage of the workpieces, the calibration of each module and the request for the manufacture of a particular workpiece. It communicates directly with the PLC and the TXT controller.
• The third is the Fischer Technik actuator and sensor solution, comprising 4 main modules:
• VGR – Vacuum Gripper Robot – the main robotic arm carrying the workpieces to be machined to each assembly and processing line
• HBW – High Bay Warehouse – the workpiece storage unit
• MPS / MPO – Multi Processing Station – Multi Processing Oven – a machining station combined with a multifunction oven
• SL / SLD (Sorting Line – Sorting Line / Sorting Line with color Detection) – the final sorting of the workpieces after machining.

Regarding the communication chain, the elements communicate with one another through a physical LAN and are interfaced through the MQTT – OPC/UA and NTP protocols. The presence of the NTP protocol is worth noting, because it provides a precise timestamping of the events of the sensor-actuator chain as well as a common time reference for orchestrating the tasks concerning the manufacture of the workpieces. This was a key point throughout the project, since, with a view to a virtualisation without Internet, the loss of an NTP connection caused the total malfunction of the system, notably with the timestamping of the NFC tags assigned to each workpiece.

This preliminary analysis pointed to a particularity of the solution developed by Fischer Technik: the use of several controllers linked to the direct control chain. Whereas our preliminary hypotheses only put the PLC in relation with the control elements, its dependence on the TXT controller, notably for reading the RFID tags, required adding a reverse-engineering step on its operating principle in order to design a virtual replication protocol.

This chapter reports on the central achievement of the project, the virtual replication of the factory in which the real PLC programme runs without its logic ever being modified.

Three principles governed all the choices:

The first aimed at obtaining a physical model and not a sequencer: the software bridge linking the virtual PLC to the simulated mechanics does not reproduce a sequence expected by the programme; on the contrary, it faithfully reproduces the behaviour in the field, so that a contactor released too early or a workpiece lost on the way produces exactly the result observed on the real machine.

The second aimed at an increased accuracy with respect to the source code involved: any disagreement between the designed model and the PLC was settled by reading the source code, never by adapting the simulation programme, which would have filled a virtual defect without ever knowing its true source.

The third established the principle of consistency and coherence before any refinement. Each modification reported in this chapter was based on a tangible element: a network capture, a log or an offline simulation of the exact logic of the programme, so that the physical behaviours observed have their equivalent in the world of the digital twin.

All these principles required reproducing the physical operation of the system, including its delays, its lost pulses and its clock hazards. It was thus necessary to go down to the data emitted by the sensors, by studying their raw values and then “back-calculating” their internal conversion formulas. The frames of the NFC reader are thus reproduced down to their transmission times, and the Raspberry Pi boards are not replaced by equivalent programmes but emulated from the real images of their SD cards, hosted on simulated hardware architectures so that their original software runs without the slightest modification.

The value of a twin lies in the small deviation of its behaviour from its physical model. This required having an almost perfect physical model as a reference. An unstable physical model would have amplified the defects, given the immutable abstraction layer introduced by virtualisation. Particular care was therefore taken over the characteristics of the physical solution before any replication. The position sensors present on each axis were studied thoroughly, from their purely physical and mechanical model to their control as declared in the source code of the PLC. Replicating erroneous data describing a physical movement would have been catastrophic, since it would have produced purely unusable analytical data.

This requirement of understanding and checking the consistency of the PLC code against its physical actions within the factory was pushed as far as the methods of transmitting the information about any workpiece, stored in “NFC tags”. The original programme only exposed their content in an interpreted form, which did not allow raw data to be captured. By connecting directly through the I2C interface of the sensor station, described in the previous chapter, I was able to read twelve real tags, eight in the raw state and four in the machined state, which made it possible to build the only reliable source of tags presented by the emulated reader, so that each workpiece of the twin carries the identifier and the history of a workpiece that really existed. The same was done for the images of the factory camera, which were captured at their source to be replayed within the virtual model.

Even the real system had to be extended to lend itself to the comparison. The original fischertechnik programme executes one order at a time and stops at the output tray until the workpiece is removed by an operator. Since building a reference data set required hours of traffic without human intervention and without interruption, I therefore extended the PLC programme to obtain a continuous operating mode.

This simple modification required an overhaul of the entire control chain of the solution. The behaviour of the Node-Red gateway had to be modified in accordance with this new operating mode.

The gateway correspondingly received an automatic-order tab which, on an operator's action, activated the continuous operating mode of the factory with the random management of workpieces of different characteristics. Thus modified, the real model was able to produce, over several 10-minute cycles (a choice made for storage-space reasons), the OPC UA and MQTT traffic needed to build a reference database.

The PLC is virtualised through the SIEMENS PLCSIM Advanced V5 software, in so-called synchronised mode, which gives the physical model, in the form of a bridge between the PLCSIM software and the NodeRed gateway, perfect control over the simulation time as well as over the actions carried out during this cycle time. The IoBridge, the physical model of the factory, was written in C# following the API published by Siemens. At each cycle time, it performs in order:

• the reading of the outputs of the PLC, allowing the physical model to know the current state of the PLC through its commands.
• the advance of the physical model, that is the movements of each unit, their states and those relating to the workpieces.
• the writing of the inputs, such as those corresponding to the infrared barriers that locate the absolute position of the workpieces at precise places
• the writing of the outputs (in parallel with that of the inputs) such as those corresponding to the motor commands of the robotic axes

The input/output addressing plan of the bridge reproduces with perfect fidelity (bit for bit) the allocation plan of the project defined by Fischer Technik; each signal is assigned to an input or an output bearing the exact name of the programme variable.

The physical model driven by the bridge comprises:

• seven axes with incremental encoders (whose position can be known in real time)
• three axes with limit switches (whose position is only known when the physical axis presses a limit switch, which gives a number of positions limited by the number of limit switches present on its path)
• pneumatic axes (for gripping and moving)
• light barriers signalling the presence of workpieces at a precise place in the factory
• two analogue colour sensors: one at the entrance of the manufacturing line and another at its exit
• workpiece conveyors that carry the workpieces from one point to another by means of belts.
• The correlation of the behaviour of certain sensors, such as the NFC workpiece information when the workpieces are present in a precise zone of the factory

The presence of a workpiece in a precise zone is thus determined by the conjunction of the states of these various elements coupled with the NFC sensor.

The two Raspberry Pi boards are emulated from the disk images taken from their physical models. On the real sensor station, the NFC service and the environmental data capture service read the data of their components through the I²C communication bus. This bus was replicated within virtual machine 3 in order to simulate the presence of the sensors and the data they produce on the I²C channel. This simulation is completed by a link with the physical model, the IoBridge, in order to simulate in due time the behaviour of the sensors according to the presence of a workpiece in a precise zone. The behaviour is simulated from the source code of their physical model, but also with the help of reference databases, as is the case for the workpiece identification information carried by the NFC service.

The emulated reader reproduces the protocol of the chip faithfully so that the virtual machine hosting the sensor station can talk to it. Three behaviours from the physical world are simulated in it:

• waiting for a workpiece when the communication field is empty
• the read fault when no card or several cards are placed on the reader
• reading / writing a tag. In our simulation, the bridge determines which tag is in the field and asks the sensor management programme to simulate the presence of the corresponding tag. The sensor gateway then talks to the simulated sensor to carry out one of the actions mentioned above.

A page of the dashboard, shown below, was created so that the operator has control over the sensor, in order to insert a precise tag, to read and write its content, with the possibility of injecting faults at will, such as the presence of two tags in the field or of an unknown or erased tag.

To the question of how to supervise the virtual model quickly, efficiently and simply, the answer was to implement a two-dimensional synoptic that reproduces the layout of the real factory with all its units. We thus find:

• The robotic arm
• the automated workpiece storage warehouse
• the multifunction workpiece processing unit
• the packaging unit

These units are animated through the simulation bridge, which takes each instruction in progress and sends it to the gateway via UDP so that it updates the synoptic interface. In addition to this logical view of the factory, control elements are provided to insert and remove workpieces in the model and to order a manufacture as in the real world. Moreover, for the sake of realism, sources of faults were added, such as the loss of a workpiece or the malfunction of a position sensor on a precise axis.

The commissioning of the twin was delayed by two months because of the many problems that accumulated during the preparation of the physical model of the factory, which came up against the imperative of obtaining a reference model free of major defects.

The first problem, which demanded so much effort from me, concerned the position encoders present on the motors of the VGR, SSC and HBW robotic axes. From the commissioning, we had noticed that the positions computed by the PLC were out of touch with reality at each movement, with deviations ranging from a few units to hundreds of units. This made any measurement or creation of a reference data set impossible.
Digging into the source code of the PLC, I came across a line that left me stunned, since it performed an exclusive “OR” (XOR) on the signal inputs coming from these encoders, which halved the position accuracy, since it meant that instead of reading the values coming from the two rotary encoders, the measurement relied on only one encoder signal… This also caused a loss of pulses between two programme cycles, generating a loss of the order of 400 increments on average on each axis travel.

This serious weakness explains the silence of Fischer Technik, which never publicly documented the position measurement of the axes of the factory. On the contrary, the brand merely deliberately capped the maximum speed reachable on each axis of the factory at 500 increments per second, the value up to which the imperfect measurement programme stayed in its comfort zone, whereas the motors and the encoders themselves could reach a speed of 1,000 increments per second.
To solve this problem, a new block counting the pulses coming from the two incremental encoders of each axis was written. Named FBINCDECv2, it no longer misses any pulse and even recognises the direction of rotation of the motor.

The FischerTechnik Industry 4.0 virtual factory is a real breeding ground of multiple peripherals, whose diversity of operation and architecture quickly caught up with a criterion that the industrial physical model imposed with the notion of “critical real time”. This notion refers to systems that tolerate no overrun of their timing constraints, at the risk of serious consequences induced by drifts from nominal behaviour. One speaks of “time-critical systems” for the control systems of nuclear power plants or those of the aeronautics field. In our case, the movements of the axes, which require increased precision, characterised this critical time, to which were added the conditions of sending and answering the messages circulating between the various components, where the strict timestamp was checked. The initial solution of Fischer Technik was to synchronise all the peripherals to a reliable clock source, such as that of the atomic clocks distributing their time reference through the NTP (Network Time Protocol) protocol. However, this “critical” choice turned out to be inappropriate, since it prevented any local operating mode put forward on paper. By making the peripherals dependent on a resource present on the Internet, it de facto contradicted the possibility of a closed-loop operation without any access to the outside. Moreover, no manual synchronisation mechanism had been implemented to catch up these time errors by turning a machine such as the Node-RED gateway into a temporary time source in the event of a failure of the availability and accessibility of the NTP servers.

The blockages are characterised by the way the PLC talks to the NFC tag reader. When a workpiece is near the reading field of the NFC sensor, the PLC sends a read request to the sensor station, adding the time at which it issued its request. The station then checks whether the difference between the time the command is received and the time it was issued fits the interval predefined in memory. If this interval is exceeded, the command is rejected. In our case the expiry time is set by default to 10 s. If the command is valid in time, the station sends back the response with a timestamp, and the PLC, for its part, checks whether the response was issued after its command; if so, the response is accepted, otherwise it sends the workpiece to the scrap bin. These rules are perfectly correct when the time source is “pure”, without imperfection or fluctuation. But in the world of the digital twin, for the reasons mentioned earlier about the clock imperfections caused by the emulation of a processor architecture, time fluctuates and the clocks go out of order. The main weak link of the chain is the virtual PLC, which only advances when the physical model allows it, in our case the C# bridge advancing millisecond by millisecond, which causes a cumulative delay as soon as its process starts on the simulation computer. Combined with the emulated Raspberry Pi boards, which become slower than their physical counterparts, time becomes a real nightmare.

The solution found to overcome this problem was to start from a precise time source and to synchronise the time of the other peripherals to it, as illustrated below, giving priority to the one that generates the most fluctuations. In our case it was imperative to reset the time of the PLC, which lost its reference at every cycle. It was therefore decided to set the time of the PLC from the clock of the computer hosting it, 50 times per second. The Node-RED gateway then follows this reference time to correct its clock as soon as the gap with the PLC time exceeds 1 s. Finally, the sensor gateway aligns itself with the time given to it by the Node-RED gateway through a message and self-corrects its clock when the gap exceeds half a second.

To assess the performance of the twin, the criteria established in the scientific research part were reused, namely whether they met the fundamental principle of consistency and legitimacy of a twin:

These criteria were proven on both levels: functional and network.

• On the functional level, the unchanged programme of the physical PLC succeeded in running under all the physical modes emulated on the virtual twin. The complete cycle of the manufacture of a workpiece was thus observed: from the reception, storage and warehousing steps to those of baking, milling, sorting and dispatch. The continuous mode was also verified: the expected behaviour was the retrieval of a workpiece by the VGR from the DSO finished-workpiece tray in order to recycle it as raw material in an endless cycle (defined by the time limits of the continuous mode). Finally, the reading, writing and erasing modes of the NFC tags took place as on the physical model, including the rejection of workpieces whose command timestamp exceeded the predefined tolerance. Thanks to the PLC mirror served through the Node-RED gateway, the positions recorded in the model and computed by the PLC only differed by a few increments on average, which is nothing compared with the initial Fischer Technik programme, which was close to 400 increments of error.
• On the network level, the machines of the twin correspond to their real addressing plan, use the same ports and the same MQTT topics. The 429 variables exposed by the PLC are the same as on the physical model, and the messages of the sensor gateway are the same. The simulated camera traffic is exactly the same, and the images are served and encoded in the correct base 64 format. The clocks, for their part, remain aligned to within a quarter of a second without any Internet connection.

What the twin reproduces of the real factory, and what it does not

• PLC programme – Final programme of the model – The same programme, unchanged – Identical
• Complete cycle of a workpiece – Reception, storage, oven, milling, sorting, dispatch – Identical, return to storage included – Reproduced
• Axis positions – Real encoders, corrected counting – Deviation below 5 pulses on the 7 axes – Reproduced
• NFC tags – Real tags of the workpieces – 12 real tags read on the model – Reproduced
• Addresses, ports, MQTT topics – Those of the model – Identical – Replicated
• PLC variables – 429 variables, read by polling – 429 variables, read by subscription – Replicated, different read mode
• Gap between the clocks – Time set through the Internet – Less than a quarter of a second, without Internet – Replicated
• Camera stream – 15 frames per second – About 2 frames per second – Not reproduced
• Wear and mechanical hazards – Present – Absent – Not reproduced

One limit remains: the virtual camera only provides about two frames per second instead of fifteen, which reduces the volume of the traffic without changing its nature. Subject to this reservation, the criterion is met: the twin reproduces the operation of the factory and replicates its network characteristics.

Once the new encoder service was installed and tested, the captures could extend over several days in order to build a reference database for the design of the digital twin. The captures were taken in 10-minute steps in continuous factory operation and recorded various events, from the storage of a workpiece in the raw-material state to its complete manufacture.

After assessing 10 network captures in nominal operation, 10 more were carried out with every possible type of failure: desynchronisation of the gateway, PLC and TXT clocks, loss of network connection of one of the elements in full factory operation, loss of a workpiece during manufacture… These samples formed a reference database of alterations that should have been compared with the altered one coming from the digital twin, but for lack of time, the comparison of the nominal captures could only be made between the physical model and its digital twin.

At the beginning of this research project we were questioning the feasibility of a digital twin; we are now convinced by the result. Measurements support it, as do an implementation protocol and, above all, so much expertise on the Fischer Technik solution, where every problem encountered did nothing but add a little more to our knowledge of the factory. We started from far away, with a factory that was malfunctioning, and after thorough diagnoses we managed to get it back on its feet. It now runs in continuous mode, and its sensor platform is no longer limited to a single controller whose secret belongs to Fischer Technik alone. Today the digital twin is functional, running the same programme as its physical counterpart and simulating the same network behaviour as a real model.

The three hypotheses were thus put to the test, and we can now rule on each of them. The first one, stating that a physical model of the machine's parts is enough to run the programme, is now confirmed by the proof of a complete cycle of the PLC programme without any artefact taking the place of one of its functions. The second one, according to which the emulated Raspberry Pi boards reproduce the same network frame contents in the OPC UA and MQTT flows, is confirmed as well: their software and their virtual architectures are intact. Finally the third one, bearing on the stability of the clocks, was the hardest to establish; it was only confirmed after a thorough correction of the time-setting chain of the devices.

This project nevertheless has a few limits that will have to be lifted, or even reworked, notably as regards the synthetic images produced by the virtual camera, the comparison of the altered traffic of the physical and virtual models, which remains to be done, and the improvement of the twin's physical model in order to simulate more advanced wear and mechanical hazards. What about a possible evaluation of attack vectors, or of attacks properly speaking, on the systems in order to study their behaviour? Such are the perspectives that we can outline at the end of this project.

1. BAGLIONE Pierre-Sacha (2025). ESAIP internship report: strengths and weaknesses of the Airbus CyberRange. ESAIP, Angers (France).
2. DRAGOS (2025). 2025 OT Cybersecurity Year in Review. Dragos Inc.
3. UKWANDU Elochukwu, et al. (2020). A Review of Cyber-Ranges and Test-Beds: Current and Future Trends. Sensors, vol. 20, n° 24, 7148.
4. NIST, The Cyber Range Project Team and the NICE Community (2023). The Cyber Range: A Guide. National Institute of Standards and Technology.
5. TAO Fei, ZHANG He, LIU Ang, NEE Andrew Y. C. (2019). Digital Twin in Industry: State-of-the-Art. IEEE Transactions on Industrial Informatics, vol. 15, n° 4, pp. 2405-2415.
6. ECKHART Matthias, EKELHART Andreas (2018). Towards a Specification-Based State Replication Approach for Digital Twins. Proceedings of the 2018 Workshop on Cyber-Physical Systems Security and PrivaCy (CPS-SPC '18), ACM, Toronto, pp. 36-47.
7. ECKHART Matthias, EKELHART Andreas (2019). Digital Twins for Cyber-Physical Systems Security: State of the Art and Outlook. In: Security and Quality in Cyber-Physical Systems Engineering, Springer, Cham, pp. 383-412.
8. BELLARD Fabrice (2005). QEMU, a Fast and Portable Dynamic Translator. Proceedings of the USENIX Annual Technical Conference, FREENIX Track, Anaheim, pp. 41-46.
9. RUSSELL Rusty (2008). virtio: Towards a De-Facto Standard for Virtual I/O Devices. ACM SIGOPS Operating Systems Review, vol. 42, n° 5, pp. 95-103.
10. OASIS (2022). Virtual I/O Device (VIRTIO) Version 1.2. OASIS Standard, Organization for the Advancement of Structured Information Standards.
11. RUST-VMM PROJECT (2024). vhost-device: vhost-user backend devices, including vhost-device-i2c. GitHub repository [online], available at <https://github.com/rust-vmm/vhost-device> [accessed 21 September 2026].
12. LAMPORT Leslie (1978). Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, vol. 21, n° 7, pp. 558-565.
13. KOPETZ Hermann (2011). Real-Time Systems: Design Principles for Distributed Embedded Applications. 2nd edition, Springer, New York.
14. MILLS David, MARTIN Jim, BURBANK Jack, KASCH William (2010). Network Time Protocol Version 4: Protocol and Algorithms Specification. RFC 5905, Internet Engineering Task Force.