MIL, SIL, PIL, HIL for firmware people

Aug 4, 2026

Someone hands you a process document with four boxes and expects you to know what they mean. MIL, SIL, PIL, HIL. Nobody explains them, because in the room they came from, everybody already knows.

I write firmware. Registers, interrupts, a UART. I do not have a plant model and I am never going to have one. Every page I found explaining MIL SIL PIL HIL was written for someone who does.

So here is the translation.

Where MIL SIL PIL HIL comes from

The vocabulary is not automotive testing in general. It is model-based control design.

You start with a physical thing you want to control — an engine, a motor, a brake. You write a math model of it, called the plant. Then you write the controller as another model, usually in Simulink, and simulate the two against each other in a closed loop. When the controller model behaves, you generate C from it and ship that.

Every rung is a step in that pipeline: the same loop, one more piece swapped from model to real. That is what "in the loop" means. Not "under test" — in the control loop, with a simulated plant on the other side. Continental's writeup lays out the chain that way: physical model, implementation model, C compiled for the host, C compiled for the target.¹

The ladder hangs off the V-model, the shape automotive settled on decades ago and baked into its standards.² These four are rungs on the way back up the right side.

None of that is stupid. It is a good process for the job it was built for. The job just is not yours.

The four rungs, defined properly

MIL — model in the loop. The controller model runs against the plant model inside the modeling environment. No generated code exists yet. You are testing whether the algorithm is right: thresholds, state transitions, gains.³

SIL — software in the loop. The generated (or hand-written) production code, compiled for and executed on your development computer, against the same simulated plant.⁴ Host compiler, host architecture. You are now running the artifact that ships, so codegen bugs, overflow, type casts and fixed-point errors show up.³

PIL — processor in the loop. The code is cross-compiled with the target compiler and runs on the target processor — "or an equivalent instruction set simulator," in MathWorks' own words.⁴ The plant is still simulated on the host, stimulus shuttled to the target each sample interval. This rung catches faults caused by the target compiler or the processor architecture.¹

HIL — hardware in the loop. The real ECU runs the real binary, wired to a real-time simulator faking everything around it: sensor signals, CAN and LIN traffic, power.⁵ Controller real, world simulated. That is why it catches timing, drivers, peripherals and buses that nothing above it can.³

Direction of travel: at MIL everything is a model. At HIL, only the world is.

The SIL confusion that wastes everyone's afternoon

An embedded developer hears "software in the loop" and pictures the firmware binary running inside a simulator. Real ELF, virtual chip. Reasonable — that is what the words say in English.

That is not what SIL means. In model-based design, SIL is the control algorithm compiled for the host and linked against a plant model. No target instruction set anywhere near it. The thing the embedded developer was picturing is PIL.

So two people say "we do SIL in CI" and mean different things. One means host unit tests against a math model. The other means the shipping firmware image booting on a virtual chip. Those catch nearly disjoint bugs, and the conversation goes nowhere until someone notices.

If someone says...	The MBD meaning	What a firmware dev pictured	Actual rung
"We run SIL"	Generated C on the host vs. plant model	The real ELF on a simulated chip	PIL
"It passed software-in-the-loop"	Host-compiled numerical equivalence	Firmware booted and printed the right thing	PIL
"We need HIL for this"	Real ECU, simulated vehicle	Any test involving a real board	HIL
"MIL signed off"	Algorithm behaves against the plant	(nothing — no equivalent exists)	MIL

When a firmware person says "simulation," they usually mean PIL.

Does each rung earn its place in a firmware project?

The honest column, which vendor pages skip because every rung is somebody's product.

Rung	What runs	Runs on	Simulated	Catches	Cannot catch	Earns its place in firmware?
MIL	Controller model	Modeling tool (Simulink)	Plant and everything else	Algorithm logic, thresholds, missing transitions	Anything about code, compiler or chip	Only with model-based design. Otherwise there is no model to run
SIL	Generated or handwritten C	Host CPU, host compiler	Plant	Codegen bugs, overflow, casts, fixed-point error	Target timing, memory layout, interrupts, peripherals	Yes, as host unit tests. You have this and call it `cargo test`
PIL	Target binary	Target CPU or instruction set simulator	Plant, and usually the board around the CPU	Target compiler bugs, architecture-specific math, stack depth, execution time, boot and peripheral logic	Analog behavior, electrical faults, real bus timing, anything off-chip	Yes. Most under-used rung in embedded
HIL	Target binary	Real ECU, real silicon	The vehicle around it	Timing, drivers, electrical, bus, watchdog, the ugly stuff	Nothing you can afford to run a thousand times a day	Yes, as the last mile — not the default loop

Read the last column.

If you do not do model-based design, MIL does not apply to you at all. There is no plant model, so there is no rung. Skipping it is not a coverage gap, it is a category mismatch. SIL collapses into host unit tests, which every firmware team already does some version of. And HIL is the last mile — essential, scarce, and the wrong place to put your default feedback loop.

Which leaves PIL.

PIL is where firmware simulation lives

Every automotive page I read treats PIL as a formality. AskUI calls it a stage that "sits between SIL and HIL in some workflows" and notes not all teams use it.³ OPAL-RT's SIL-versus-HIL guide does not mention it at all.⁵ PatSnap gives it two sentences.⁶

That is a hangover from where the vocabulary came from. In model-based design, PIL exists to prove the target compiler and FPU do not change your numbers before you go book the bench. A checkbox on the way to HIL.

Look at what PIL mechanically is, though: your real firmware binary, cross-compiled with your real toolchain, executing on the target instruction set. Not a checkbox. For a firmware team that is the whole product.

And MathWorks explicitly allows the target to be an instruction set simulator rather than silicon.⁴ So the sanctioned PIL setup includes the thing embedded people have been building for years under a different name: a virtual board. That is where a hosted target simulator like Chiplab sits on this ladder — a PIL rig with no eval board to book.

The consequence is throughput. BTC Embedded, who sell PIL tooling, already argue for running PIL in CI as an always-on quality gate.⁷ That is not the ceiling. With an instruction set simulator there is no board to allocate, no flashing step and no queue, so the rung runs on every commit.

Most firmware CI never gets there. It compiles, links, and stops — which is where firmware CI usually ends. PIL is the rung that fixes that, and the one the ladder undersells. Where exactly to draw the line between virtual target and bench I worked out separately, in what belongs in CI versus on a HIL rig.

What the standard asks for

Careful here. This is where posts start inventing clause numbers.

The ZVEI best-practice guideline for safety-related automotive software restates the ISO 26262-6 software unit verification methods, and one is "back-to-back comparison test between model and code, if applicable" — applicable, it says, when a model of the software unit exists.⁸ That conditional does real work. The whole MIL-versus-SIL ritual is scoped to teams who have a model in the first place.

MathWorks positions SIL and PIL as verification activities you can run against ISO 26262-6 and friends via a certification kit.⁴ BTC frames PIL as the way to test "as close to the target as possible" without jumping straight to HIL.⁷ Both are vendor framings, not quotes from the standard, and I am flagging them as such.

Which ASIL requires which rung, I am not going to tell you. I do not have the text in front of me, and most confident answers online are copied from each other.

What is the real difference between SIL and PIL?

The compiler and the instruction set.

SIL compiles your code with the host compiler and runs it on the host CPU. PIL cross-compiles with the target compiler and runs the object code on the target processor, or on an equivalent instruction set simulator.⁴ Same source, two machines. SIL proves the logic survived code generation. PIL proves it survives your toolchain and your chip.

One place sources genuinely disagree: whether PIL requires physical silicon. MathWorks and the Continental paper both explicitly permit an instruction set simulator as the PIL target.⁴ ¹ BTC's definition assumes an evaluation board wired to a host PC.⁷ If you are writing a process document, pick one and say which. If you are reading someone else's, ask.

So what do you call the thing you actually do

If you run firmware on a virtual chip in CI, the automotive word for that is PIL, and saying so will save you an argument with a process engineer.

But you do not owe the ladder your vocabulary. It describes a pipeline that turns block diagrams into C, and you are not running that pipeline. You have a binary, a chip, and one question: does this boot and do the right thing on the part I ship?

Two rungs answer that. The other two describe a job you do not have.