The word ‘simulation’ can be misleading. This is neither about recreating an entire battle nor about pretending that a military system already exists. In the field of drones and cyber, simulation can fulfil a more straightforward and useful function: serving as a test bed for the chain linking the sensor to the decision. A simple mission is re-enacted; a known disruption is introduced into the data or communications; and then we measure what the operator sees, understands and decides. The aim is not to promise a new, complex system. It is to describe a system that can be assembled from available building blocks, then supplemented, where necessary, by hardware testing or controlled flight trials.
The war in Ukraine has highlighted the widespread use of drones: it is estimated that around 10,000 drones are deployed every day by both sides1. As early as 2021, the French Senate emphasised that these systems had become indispensable and were set to play an increasingly significant role in war zones2. But the issue is not merely a question of the number of platforms. Each drone adds a sensor, a communication link, software, metadata and an interface. It therefore increases both the capacity for observation and the number of points at which a situation can be distorted before reaching the commander.
The relevant question is therefore not: can we simulate drone warfare? Such an ambition would be too broad and would quickly produce a spectacular but unconvincing demonstration. The realistic question is more precise: how can we test, in a repeatable manner, the robustness of a sensor- transmission-interface-decision chain when plausible information becomes inaccurate, delayed or contradictory?
Not simulating war: testing the sensor-transmission-interface decision chain
A drone is not merely a airframe, an engine, a payload and a radio link. In an intelligence or support mission, it forms part of a cyber-physical chain that combines sensors, computing, communications and action in the physical world3. The truly useful state is not that of the drone taken in isolation, but that of the system as a whole: sensor position, time of measurement, link quality, on-board processing, fusion with other sources, display on screen and validation procedure.
This chain can degrade without any outright failure. A GNSS position may drift gradually; an image may remain authentic whilst being associated with incorrect coordinates; a data frame may be replayed with a plausible timestamp; several tracks may appear to corroborate one another when they actually originate from the same source. Research into spoofing shows precisely that tampering is not limited to jamming: it can mimic or displace the expected signal4. In this case, the system continues to function. The danger lies in its credibility.
To test this vulnerability, it is not necessary to replicate the intrusion technique used by an attacker. The test bed need only replicate the observable effect at the point where it enters the chain. A positional drift can be introduced into the telemetry; a time offset can be added to a data stream; packet loss or duplication can be imposed on the link; a contradiction can be created between two sources. This distinction is essential. It prevents the study from becoming a cyber-attack programme and allows us to focus on what is directly relevant to operational use: the way in which the chain reacts.
False information only produces a military effect when it becomes an accepted representation and then a decision.
Each test must therefore be based on a known fact on the ground. A short mission is sufficient: reconnoitering a route, following a few tracks, confirming or ruling out the presence of an object, and then reporting an assessment. The evaluator knows where the tracks actually are and at what point the given in were altered. The operator, however, knows neither the nature nor the timing of the disruption. A specific pattern can then be observed: does the operator detect the anomaly, report it, seek an independent source, stand by their decision or correct it?
The scope must be deliberately limited. The aim is neither to predict a future operation, nor to represent an entire theatre of operations, nor to conclude that a vulnerability observed in a test bed exists in exactly the same form during actual operations. The system serves to isolate a mechanism and compare responses. Its value lies in this very simplicity: the same mission can be replayed with just a single variable altered.
A minimal system based on existing components
An initial test bench does not require the development of a proprietary simulator. Common autopilot ecosystems already feature software-in-the-loop modes, in which the flight software runs on a computer without an aircraft, as well as, depending on the configuration, hardware-in-the-loop modes using a real controller. They also allow a ground station to be connected and several virtual vehicles to be operated5. The specific task therefore involves less creating the flight itself and more setting up the interactions, introducing defined disturbances and recording the responses.
The basic setup can fit into a single room: one workstation runs the virtual vehicles and the scenario; a second displays the control station used by the operator; a module on the network modifies certain data streams; and a recorder stores telemetry, logs, screen displays and decisions. Existing network emulation tools allow for the controlled introduction of delay, packet loss, duplication or corruption6. A detailed test plan specifies, for each test, the nominal mission, the disturbance, the time of its occurrence and the termination condition.
Level 1 – software only. This is the preferred level to start with. A few virtual vehicles carry out a simple mission. The disturbance is injected into the telemetry, metadata or network. No radio effects are required, no airspace is occupied and the scenario can be repeated immediately. This level allows verification that the injection is under control, that the logs are usable and that the indicators adequately address the question being asked.
Second level – hardware in the loop. A real flight controller, or even a component of the link, is added to the test bench to verify that the observed behaviours do not depend solely on a software abstraction. This level is only meaningful once the protocol has stabilised. It should not be presented as an initial requirement: its feasibility depends on the hardware selected, its interfaces and the level of access available.
Third level – limited flight test. One or two drones can then take over the mission within a controlled area. The simplest disruptions are still generated within the data chain or at the ground station; sensitive radio or GNSS transmissions are not required to validate the overall logic. The flight test primarily verifies the effects that the software simulator fails to accurately represent: piloting constraints, actual link quality, workload, weather, interruptions and coordination between operators.
This step-by-step approach avoids three common pitfalls: starting with a large swarm, developing a detailed 3D scene, or adding artificial intelligence before the test criteria have been defined. None of these elements is essential for the initial results. The core requirements are much simpler: real-world conditions, an observable data stream, a controlled disruption, an expected decision, and a comprehensive log of what occurred.
Test matrix achievable at the first level
| Test | Controlled injection | Operational question | Primary measurement |
| Position drift | A gradual shift in a coordinate in the telemetry. | Does the operator detect that a credible track is moving abnormally? | Detection time and position error at the time of the decision. |
| Historical data | Delay or replay of an image and its timestamp. | Is the age of the data identified before validation? | Age of validated data and number of actions based on an outdated status. |
| Poor connection | Delays, packet loss or duplicates. | Does the procedure remain stable when the data stream becomes intermittent? | Mission continuity, errors and time taken to return to a usable data stream. |
| Conflicting sources | Two sensors provide incompatible positions or identifications. | Is an independent source sought, or does the initial reading take precedence? | Cross-check rate, decision time and possible correction. |
| Duplicate track | Duplication of an identifier or a track in the fusion entry. | Does a false consensus artificially inflate confidence? | False validation rate and declared confidence level. |
Each test is carried out under at least three conditions: nominal operation, disruption without countermeasures, and disruption with a specific correction. This correction may be technical – explicit display of the data’s age, contradiction alert, separation of sources – or procedural – double validation, request for cross-checking, temporary suspension of the action. The aim is not to multiply the number of scenarios, but to determine whether an identifiable change actually improves the decision.
Limited results, but directly actionable
The simulation does not produce a universal truth about drone warfare. It provides localised results, specific to a mission, an interface, an organisation and a type of disruption. This is precisely what makes them usable. One can compare two versions of a display, two validation rules or two team compositions without changing the rest of the scenario.
The indicators must remain few in number and linked to operational use: time taken to detect an anomaly, proportion of erroneous validations, recovery time, discrepancy between stated confidence and actual reliability, number of contradictions effectively cross-checked, final decision and justification given. Situational awareness involves perceiving, understanding and projecting the evolution of a dynamic environment7. The aim is therefore not to assess the theoretical quality of the sensor, but to determine at what point the available information ceases to support a representation that is sufficiently accurate to enable action.
Three deliverables are realistic. The first is a reproducible protocol: mission files, disturbance parameters, expected logs and evaluation rules. The second is a mapping of the observed vulnerabilities: where the error enters, how it propagates, which decision it alters and the condition under which it can be corrected. The third is a set of rules for action limited to the configuration under test: displaying the age of the data, distinguishing between truly independent sources, requiring cross-checking when discrepancies exceed a certain threshold, or suspending validation when the displayed confidence is based on a single source.
What the system must not promise is equally important. It does not certify a drone’s cybersecurity. It does not demonstrate that an adversary actually possesses the necessary access to cause the disruption. It does not replace code analysis, electromagnetic testing or evaluation flights. Finally, it does not automatically transform an observation into general doctrine. The thresholds obtained apply only to the equipment, interface, mission and operators tested.
On the other hand, it creates a common language between the user, the engineer, the cyber specialist and the trainer. All can review the same incident, verify the same timeline and discuss the same decision. An anomaly that previously remained abstract becomes an observable sequence: altered data, a missing or ignored alert, a modified display, a decision made, a belated or successful correction. The test bed then enables a decision to be made as to what needs to be modified first: the workflow, the interface, the procedure or the training.
Here, the simulation derives its military value not from spectacle, but from repeatability. The Realist project is not a complete virtual battlefield, and even less so a promise of a digital twin of war. It is an instrumented chain – deliberately short – which allows the same mission to be replayed under disruptive conditions and measures what changes. We start with readily available software; we add hardware only when a specific question warrants it; we move on to flight testing to verify what the simulator cannot replicate.
It is therefore not a question of pretending that war is taking place. It is a question of verifying, before it happens, how a decision-making chain reacts when plausible information ceases to be true.
The Opinion piece is available below
- Lefief, J.-P. (2026). ‘How Ukraine managed, at least for a time, to assert its control over digital data from the battlefield’. Le Monde, 15 May 2026. ↩︎
- Perrin, C. et al. (2021). Preparing for the ‘drone war’: a strategic challenge. Information Report No. 711 (2020–2021), Senate. ↩︎
- Monostori, L. (2014). ‘Cyber-physical Production Systems: Roots, Expectations and R&D Challenges’. Procedia CIRP, 17, pp. 9–13. DOI: 10.1016/j.procir.2014.03.115. ↩︎
- Van Der Merwe, J. R., Zubizarreta, X., Lukčin, I., Rügamer, A. and Felber, W. (2018). ‘Classification of spoofing attack types’. 2018 European Navigation Conference, pp. 91–99. ↩︎
- PX4 Autopilot, ‘Simulation’, PX4 Guide; ArduPilot Project, ‘SITL Simulator (Software in the Loop)’, official documentation, accessed in August 2026. These environments support software simulation and, depending on the configuration, hardware-in-the-loop simulation and multi-vehicle simulation. ↩︎
- Linux man-pages project, tc-netem(8). The netem module enables the emulation of, amongst other things, packet delay, loss, duplication and corruption. ↩︎
- Endsley, M. R. (1995). ‘Toward a Theory of Situation Awareness in Dynamic Systems’. Human Factors, 37(1), pp. 32–64. DOI: 10.1518/001872095779049543. ↩︎
