systems engineering//verification//X-in-the-loop testing//software-in-the-loop

Software-in-the-loop testing runs the compiled production code of a controller on an ordinary computer, against simulated plant, sensors and clock, so the real software can be exercised without any hardware; it is used to catch regressions and logic errors early and in bulk, running thousands of scenarios in parallel on servers every night, and it is how open drone autopilots such as PX4 and ArduPilot are developed day to day, with a simulator like Gazebo providing the physics. The code is the code that will fly; only its surroundings are simulated.

Software-in-the-loop testing runs the compiled production code of a controller on an ordinary computer, against simulated plant, sensors and clock, so the real software can be exercised without any hardware; it is used to catch regressions and logic errors early and in bulk, running thousands of scenarios in parallel on servers every night, and it is how open drone autopilots such as PX4 and ArduPilot are developed day to day, with a simulator like Gazebo providing the physics. The code is the code that will fly; only its surroundings are simulated.

The simulated clock is what makes it powerful. Because the simulation controls time, it can run faster than real time, pause, replay a scenario exactly, and run many copies at once, so a change to the altitude controller can be tested overnight across hundreds of wind profiles, payloads and failure cases. That repeatability is what lets it carry the regression battery of continuous integration for control software.

SIL tests the code's logic and its numerical behaviour at full scale and almost no marginal cost, which makes it the widest layer of the test pyramid. What it cannot test is anything the PC hides: real execution time on the target processor, interrupt timing, bus behaviour and the electronics, which are left to processor-in-the-loop and hardware-in-the-loop.

Its realism is the simulator's. Sensor noise, latency, vibration and aerodynamic effects are present only as modelled, so a controller tuned purely in SIL can be over-confident; comparing SIL runs against real flight logs is how the sim-to-real gap is kept measured.

It closes the loop that log replay leaves open, so a new controller is judged here and a new estimator usually there first.

It is the cheapest stage for fault injection, since a simulated sensor or motor can be broken in any way, at any moment, at no cost.

The name collides with safety integrity level, also SIL, in functional safety; context decides which is meant.