What is HIL, and how is it different from SITL?

The short version

HIL stands for Hardware In The Loop. The real firmware runs on the real flight controller — the same board you would bolt into the aircraft, running the same binary you flashed. It is not a PC build. The simulator, running on your computer, feeds that board synthetic sensor data down a wire, and reads back the motor outputs it produces.

The board does not know anything is unusual. It believes it has a gyro, an accelerometer, a barometer and a GPS, and it believes they are telling it that it is airborne. It runs its loop, its filters and its state machine accordingly, and it drives its motor outputs at whatever the physics model says it should.

SITL, by contrast, has no flight-controller hardware in it at all. The firmware is compiled for your PC and runs as an ordinary process. The loop closes over a socket on localhost.

Both are "the real firmware in a simulated world." The difference is whether the silicon is real too.

The difference in one picture

Picture the two loops side by side.

In SITL, the loop lives entirely inside your computer. The simulator computes a state, hands it to a firmware process over a UDP or TCP socket, the process runs its PID loop and hands back four motor commands, and the simulator integrates the physics forward. Everything is software talking to software. Nothing has to happen at any particular wall-clock moment — if you want, you can even run the whole thing faster or slower than real time.

In HIL, the loop leaves your computer and comes back. The simulator computes the same state, but instead of writing it into a socket it serialises it down a serial or USB link into a physical flight controller. That board — an STM32 with real drivers, real DMA channels, a real scheduler and a real clock — ingests the injected sensor readings as if they had come from its own IMU, does its work under its actual CPU budget, and puts its motor outputs back onto the wire. The simulator reads them and steps the physics.

The wire is the whole story. It brings in everything that is true about the hardware, and it also brings in the constraint that the loop must now keep up with real time, because the board is running in real time whether your PC is ready or not.

What HIL catches that SITL cannot

SITL tests logic. HIL tests logic as it actually executes on the thing you fly. That difference is not academic.

That last row is the one people underrate. Your SITL binary is not the binary you flash. It is the same source compiled by a different compiler for a different architecture, with hardware-specific code paths stubbed or #undef'd out. It is an excellent model of the firmware's logic and a poor model of the firmware's executable. HIL closes exactly that gap: the artefact under test is the artefact you will trust.

The other genuine win is that HIL lets you fly the simulation with your real transmitter, through your real receiver, into your real board — so the RC link, the mode switches, the failsafe wiring and your muscle memory are all being exercised together.

What SITL catches that HIL does not

SITL wins on everything that makes a test cheap to repeat, and repetition is most of what testing is.

• It needs no hardware. No board, no wire, no bench. Anybody can run it.
• It is trivially reproducible. Same seed, same inputs, same result — no thermal drift, no USB flakiness, no board that is currently in the aircraft.
• It runs in CI. You can gate a firmware change on a hundred simulated flights that nobody had to supervise. You cannot easily put a rack of flight controllers in a build pipeline.
• It is not bound to real time. Run a twenty-minute mission in thirty seconds, or slow the loop to a crawl to watch a single failsafe branch unfold.
• It runs in parallel. Fifty simultaneous instances sweeping a PID grid is a laptop's afternoon.
• It is the right tool for logic. The control loop, the arming checks, the failsafe branches, the mission state machine, the GPS Rescue path. These are software questions, and software questions belong in a software loop.

And it is honest to say the obvious: HIL is fiddlier. You need a physical board, a physical link, and firmware that actually supports a sensor-injection protocol — and support for that varies considerably between Betaflight, iNAV and ArduPilot, and between versions. SITL setups are already awkward enough for most pilots; a HIL rig raises that bar again.

When each is worth the trouble

Reach for SITL when the question is what does the aircraft do? Tuning, mode behaviour, failsafe behaviour, mission logic, learning a new firmware, deliberately driving a control loop into instability to see what it looks like in the trace. This is nearly every question a pilot has.

Reach for HIL when the question is what does this board do? You suspect a timing problem. Your loop rate is not holding at the configured value and you want to see it fail. You have enabled six features and want to know what your CPU load actually is. A driver or a peripheral is misbehaving in a way no PC build can reproduce. Or — the best reason — you are about to trust a specific firmware build with an expensive airframe, and you want the last rung of a staged test procedure to be with the exact binary and the exact hardware.

The honest verdict

Start with SITL. That is where roughly 90% of the value is for a pilot, because roughly 90% of what goes wrong on a multirotor is a control-loop or a configuration problem, and both are pure software. It costs you nothing, it repeats forever, and it will teach you the failure modes before they cost you an airframe.

Go to HIL when you have a hardware-specific or timing-specific suspicion that SITL structurally cannot answer, or when you are doing the final validation of a build you are about to fly for real. It is a sharper instrument aimed at a narrower target.

They are complementary, not competing, and the framing of "which is better" is wrong. SITL asks is the logic right? HIL asks does this board execute that logic correctly? Both are worth asking, in that order.

And neither one replaces a real flight. What both replace is a great many crashed real flights, which is a rather better deal than it sounds.