Automotive MIL vs. SIL vs. HIL: How Engineers Test a Car Before the Car Exists

One of the strangest things about modern automotive engineering is that engineers can begin driving a car long before anyone has built it.

Not physically, of course.

Virtually.

They can brake it.

Accelerate it.

Put it on ice.

Fail a sensor.

Overheat the battery.

Confuse a camera.

Interrupt a network message.

Lock a wheel.

Lose voltage.

And send the vehicle into situations no test driver would particularly enjoy experiencing.

The actual car may still be months—or years—from production.

That is the world of MIL, SIL and HIL testing:

• MIL — Model-in-the-Loop
• SIL — Software-in-the-Loop
• HIL — Hardware-in-the-Loop

These techniques let automotive engineers gradually replace simulated pieces of a vehicle with real software and hardware.

The idea is simple:

Find the problem before the problem becomes expensive.

And then:

Introduce reality gradually.

Why Test a Car That Does Not Exist Yet?

Automotive development has always had a timing problem.

Engineers need to test vehicle systems.

But many of those systems need to be developed before a complete vehicle exists.

Consider a new electric vehicle.

Teams may simultaneously be developing:

• Battery-management software
• Electric-motor controls
• Braking systems
• Steering
• Stability control
• Thermal management
• ADAS
• Infotainment
• Vehicle networks
• Charging systems

Nobody can simply say:

We will wait until the first finished car arrives and see whether all of this works together.

By then, discovering fundamental problems could be enormously expensive.

Modern automotive development therefore tries to move testing earlier—sometimes so early that neither the production software nor the production controller hardware exists yet.

MathWorks describes MIL, SIL, PIL and HIL as progressive verification and validation techniques for embedded systems, with different portions of the controller and physical plant becoming real as development advances.

That progression lets engineers build confidence before the complete physical product exists.

Start With a Car Made of Mathematics

Suppose engineers are developing electronic stability control.

The final system may need to understand:

• Vehicle speed
• Steering angle
• Wheel speeds
• Vehicle yaw
• Braking force
• Tire behavior
• Road friction

Eventually, sensors will collect real information from a real car.

But early in development, engineers can model those things mathematically.

They can create a virtual representation of the vehicle and another model representing the control strategy.

Now the engineers can simulate a driver turning sharply on a slippery road.

The vehicle model begins to lose stability.

The control model sees the simulated sensor information.

It calculates a response.

It applies simulated braking.

The virtual vehicle responds.

No steel has been stamped.

No prototype has been crashed.

No one has even gotten wet standing beside a test track.

Yet engineers are already learning how the vehicle might behave.

That is Model-in-the-Loop testing.

MIL: The Engineer Tests the Idea

During MIL testing, both the controller and the physical system can exist as models.

MathWorks describes MIL as an early development technique in which engineers verify control algorithms using high-level simulation models before actual software or hardware is required.

This gives engineers enormous freedom.

They can change:

• Vehicle mass
• Tire characteristics
• Motor output
• Battery behavior
• Road friction
• Sensor inputs
• Control logic

and run the experiment again.

That makes MIL particularly valuable for answering a fundamental question:

Does our engineering concept actually work?

Imagine developing regenerative braking for an EV.

The control model needs to decide how much deceleration should come from the electric motor and how much should come from the friction brakes.

Engineers can experiment with those decisions before the final brake controller exists.

What happens when the battery is full and cannot accept much regenerative energy?

What happens on a slippery surface?

What happens during emergency braking?

What happens at extremely low temperatures?

The engineers can begin answering those questions in MIL.

A Virtual Car Can Be Deliberately Abused

This is one of simulation’s great luxuries.

Engineers can be mean to the virtual vehicle.

Very mean.

Suppose you want to know what happens when a wheel-speed sensor suddenly reports nonsense.

Do it.

What if a steering-angle sensor freezes?

Try it.

What if battery temperature rises unexpectedly while the vehicle is climbing a steep grade?

Simulate it.

What if road friction suddenly changes from dry pavement to ice?

Click.

Nobody needs to arrange a hazardous physical test every time someone thinks of another unpleasant scenario.

And if the simulated vehicle ends up upside down in a virtual ditch?

Reset.

That freedom encourages engineers to explore the strange edge cases that often reveal weaknesses in a system.

But Eventually the Model Has to Become Software

A control model can behave perfectly and still produce problems when engineers turn the design into executable software.

The algorithm may be correct.

The implementation may not be.

So the next question becomes:

Does the actual software behave like the model we approved?

That is where Software-in-the-Loop enters the process.

SIL: Now Test the Code

In SIL testing, engineers run actual executable controller software while much of the surrounding vehicle remains simulated.

MathWorks describes SIL simulation as compiling generated code and running it on the development computer so engineers can compare software behavior with the original model.

The car can still be virtual.

But one important part is no longer merely a mathematical control model.

It is software.

So our virtual braking example becomes:

Real brake-control software + simulated brakes + simulated tires + simulated road + simulated vehicle.

That moves testing closer to what will eventually happen in the actual car.

Why SIL Has Become So Important

Modern vehicles contain enormous amounts of software.

Software also changes far more frequently than physical automotive hardware.

A mechanical component may require tooling, prototypes and physical validation before it changes.

A software developer can alter code this morning.

That makes physical testing a bottleneck.

If every software build required access to a real ECU and a physical test bench, development could slow dramatically.

SIL provides another option.

Software tests can potentially run on ordinary computing infrastructure, including highly automated virtual environments. ETAS, for example, describes cloud-based SIL testing environments for deeply embedded automotive software.

That changes the scale of testing.

Instead of asking:

Do we have a test bench available?

teams can increasingly ask:

How many virtual tests can we run?

The Virtual Garage Can Run All Night

This is where SIL starts looking like modern software development.

A developer changes code.

The system builds it.

Automated tests run.

Different scenarios execute.

Failures are recorded.

The next software version goes through the same process.

That is particularly important for software-defined vehicles, where automotive software development increasingly incorporates continuous integration and continuous testing.

Virtual tests do not need a coffee break.

They do not need a test driver.

They do not need someone to reserve a proving ground.

And many can potentially run in parallel.

That means engineers can perform broad regression testing every time software changes.

The virtual vehicle becomes something like a continuously available engineering test fleet.

So Why Do We Still Need Hardware?

Because software eventually runs on something physical.

The production ECU has:

• A real processor
• Real memory
• Real communications interfaces
• Real electrical inputs and outputs
• Real execution timing
• Real resource constraints

Code that behaves beautifully on an engineering workstation may behave differently once loaded onto automotive hardware.

Timing becomes particularly important.

A braking controller cannot eventually conclude:

Yes, I have determined that braking would have been appropriate three seconds ago.

It must respond when the physical system needs the response.

That is where HIL becomes important.

HIL: Give the Software Its Real Computer

During Hardware-in-the-Loop testing, the actual electronic control hardware becomes part of the test.

dSPACE defines HIL testing as testing real ECUs inside a realistic simulated environment.

Now imagine an actual production-intent brake controller sitting on a laboratory bench.

Its software is running.

Its communications connections are active.

Its electrical interfaces are connected.

As far as the ECU is concerned, it may be installed in a vehicle.

But there is no vehicle.

The HIL simulator impersonates it.

The ECU Thinks It Is Driving

This is the delightful trick at the center of HIL.

Suppose the ECU expects information from four wheel-speed sensors.

The simulator sends those signals.

The ECU expects steering-angle information.

The simulator provides it.

It expects braking inputs.

Those arrive too.

The controller calculates what the brakes should do and sends output commands.

The HIL system reads those outputs.

Its virtual vehicle responds.

Then it sends the updated vehicle state back to the real ECU.

Around and around the loop goes.

Real controller.

Real software.

Fake car.

But the fake car has to behave convincingly enough that the real controller does not care.

HIL Has to Keep Up With Reality

A desktop simulation can sometimes run faster or slower than real time.

HIL generally does not have that freedom.

If the ECU expects something to happen every few milliseconds, the simulated vehicle has to respond accordingly.

The physical controller is running on real clock time.

So the simulation has to keep pace.

That requirement makes HIL systems considerably more sophisticated than simply running a vehicle model on a laptop.

MathWorks describes HIL as connecting controller hardware to a real-time simulated plant, while dSPACE emphasizes realistic, reproducible interaction between real ECUs and the virtual system.

Now Engineers Can Create Failures on Demand

HIL becomes particularly powerful when engineers start injecting faults.

Imagine testing a battery-management controller.

The simulator can tell it:

Battery temperature is increasing.

One cell voltage is abnormal.

A sensor has failed.

Cooling performance has dropped.

A communications message has disappeared.

Voltage is unstable.

The engineer does not need to physically damage a battery pack to create these conditions.

The simulator generates the signals.

The real controller responds.

That makes dangerous and rare situations dramatically easier to repeat.

dSPACE specifically notes that HIL allows critical corner cases to be tested without creating safety problems for the device under test or its surroundings.

That is especially attractive when the alternative involves intentionally creating a dangerous situation in a prototype automobile.

The Test Can Be Exactly Awful Every Single Time

Physical tests contain variability.

Temperatures change.

Drivers react slightly differently.

Road conditions vary.

Components wear.

One of HIL’s great advantages is reproducibility.

If engineers want exactly the same fault to occur exactly 2.7 seconds into a maneuver, they can create that scenario.

Then run it again.

Change the software.

Run it again.

Change a calibration.

Run it again.

That makes HIL useful not only for finding problems but for proving that engineers actually fixed them.

This Is Why Engineers Do Not Want to Discover Everything on the Test Track

Real vehicle testing is indispensable.

But it is expensive.

It requires:

• Prototype vehicles
• Instrumentation
• Test engineers
• Drivers
• Tracks
• Facilities
• Time

Some tests also require special conditions.

Ice.

Snow.

Extreme heat.

Extreme cold.

Specific road surfaces.

And some scenarios are dangerous.

Virtual testing cannot replace all of that.

But it can help engineers arrive at physical vehicle testing with fewer unknowns.

The real prototype should ideally confirm engineering work—not become the first place anyone discovers that the software occasionally forgets how brakes work.

MIL, SIL and HIL Are Not Competitors

It can be tempting to view the progression as:

MIL is basic.

SIL is better.

HIL is best.

That is the wrong way to think about it.

Each environment is useful for different questions.

MIL may be faster for developing control concepts.

SIL may be better for running enormous numbers of software tests.

HIL may be necessary for checking real hardware interfaces and timing.

dSPACE explicitly describes SIL and HIL as complementary approaches and notes that shifting appropriate testing into SIL can free HIL resources for tests that actually require physical hardware.

The goal is not to reach HIL as quickly as possible.

The goal is to avoid using an expensive HIL bench to discover a problem that could have been caught earlier on a virtual machine.

Spend Reality Carefully

That gives us another useful way to understand automotive testing.

Reality is expensive.

A model is relatively easy to duplicate.

Software environments can be scaled.

Real ECUs cost money.

HIL benches cost more.

Prototype vehicles cost considerably more.

Full vehicle testing requires people, facilities and time.

So engineers progressively spend more reality only when it adds information they could not obtain economically at an earlier stage.

That is the real logic behind:

MIL → SIL → HIL → physical vehicle.

Not every automotive program follows a perfectly neat sequence, of course.

Development overlaps.

Teams work in parallel.

Hardware may arrive while models are still evolving.

Testing may move backward and forward between environments.

But the economic logic remains.

Use the least expensive environment capable of answering the engineering question.

A Battery Management System Is a Perfect Example

Consider an electric-vehicle battery management system, or BMS.

During MIL, engineers can develop and validate the control logic using simulated battery behavior.

During SIL, they can run the BMS software against virtual battery models.

During HIL, the real BMS controller can connect to a simulator generating battery voltage, current and temperature behavior.

dSPACE demonstrates this exact kind of SIL-to-HIL workflow for battery-management system testing.

Eventually the system is connected to a real battery pack.

But by then engineers may already have tested a vast range of behavior.

The battery pack is not where the investigation begins.

It is where increasingly mature engineering arrives.

ADAS Makes Virtual Testing Even More Important

Now consider automated driving or an advanced driver-assistance system.

The number of possible scenarios becomes enormous.

Different:

• Roads
• Vehicles
• Pedestrians
• Lighting conditions
• Speeds
• Weather
• Lane markings
• Traffic behavior

No physical test fleet could efficiently explore every possible combination.

Simulation environments let engineers create driving scenarios before testing them in physical vehicles.

dSPACE describes automated-driving workflows designed to transition from SIL to HIL using realistic simulation as the basis of virtual validation.

Again, virtual testing does not eliminate road testing.

It helps decide which problems should never make it as far as the road.

Steering Can Be Tested While the Road Exists Only in a Computer

Some HIL systems go beyond electrical ECUs.

dSPACE describes mechatronic test benches capable of testing real steering systems under simulated vehicle and road conditions.

Think about that for a moment.

A real steering system can physically move.

The forces can be real.

The controller can be real.

But the road the vehicle is supposedly traveling over may exist entirely inside a computer.

This is where the line between physical and virtual development becomes surprisingly fuzzy.

The car does not either exist or not exist.

Parts of it exist.

Other parts are mathematics.

And engineers keep moving that boundary.

Eventually the Car Appears

At some point, real prototypes arrive.

Then engineers begin integrating more physical systems.

Real sensors.

Real brakes.

Real battery packs.

Real steering.

Real tires.

Eventually the whole vehicle.

And there are additional testing concepts beyond our three acronyms.

You may encounter:

• PIL — Processor-in-the-Loop
• VIL — Vehicle-in-the-Loop

PIL introduces the target processor into testing, while VIL brings an actual vehicle into a test environment that may still contain simulated scenarios or surroundings. MathWorks distinguishes PIL from SIL by running object code on the target processor or equivalent instruction-set environment.

The progression can therefore become something like:

Model → Software → Processor → Hardware → Vehicle → Road

At every stage, another piece of reality arrives.

The First Car Is No Longer Really the First Car

This may be the most interesting consequence of all.

By the time engineers assemble a physical prototype, they may already have accumulated enormous amounts of experience with its virtual versions.

The braking system has already stopped the virtual car.

The battery software has already managed the virtual battery.

The ADAS software has already encountered virtual traffic.

The controller has already reacted to virtual failures.

The vehicle may be physically new.

But from the engineering team’s perspective, parts of it have been driven thousands—or potentially far more—times.

That fundamentally changes what a prototype is for.

Physical Testing Becomes More Valuable, Not Less

Simulation skeptics sometimes frame virtual testing and physical testing as competitors.

They should not be.

If virtual testing removes thousands of routine or easily reproducible failures before physical prototypes arrive, engineers can use expensive physical testing for the things simulation cannot yet answer confidently.

Real tire behavior.

Unexpected vibration.

Complex environmental interactions.

Human perception.

Manufacturing variation.

The strange noises something makes only on Tuesday when it is 17 degrees outside.

Reality always contains surprises.

The point of virtual development is not to pretend otherwise.

It is to arrive at reality better prepared.

Software-Defined Vehicles Raise the Stakes

This approach becomes even more important as automobiles become software-defined.

Software can change throughout development.

Multiple teams may update vehicle functions continuously.

An update to one system can have unintended effects elsewhere.

dSPACE has emphasized end-to-end SIL and HIL validation for electric, automated and software-defined vehicle development as automotive software complexity increases.

That makes repeated automated testing essential.

A manufacturer cannot reasonably rebuild a prototype fleet every time someone commits new code.

The virtual vehicle becomes a permanent part of development.

We May Eventually Have More Virtual Test Cars Than Real Ones

There is an amusing inversion here.

Historically, automotive testing meant building physical prototypes and putting miles on them.

Increasingly, an automotive program can create enormous numbers of virtual configurations.

Different software versions.

Different hardware definitions.

Different driving scenarios.

Different environmental conditions.

Different failures.

One physical test car occupies one place at one time.

A virtual vehicle can potentially be duplicated across computing resources and placed into many scenarios simultaneously.

So the future automotive test fleet may contain something peculiar:

A relatively small number of expensive physical cars surrounded by an enormous invisible fleet of virtual ones.

Find the Cheap Mistakes First

That is ultimately what MIL, SIL and HIL accomplish.

Use MIL to discover problems while they are still largely ideas.

Use SIL to discover problems while they are software.

Use HIL to discover problems when the real controller hardware enters the picture.

Then use the real vehicle for the questions that actually require a real vehicle.

There is no virtue in discovering a simple software defect at 70 mph on a proving ground if a computer could have found it six months earlier.

Automotive engineering is increasingly about deciding where a problem should be allowed to exist.

Ideally:

In the model.

Maybe in the software lab.

Occasionally on the HIL bench.

And almost never for the first time in the finished car.

That is how engineers test a car before the car exists.

And it may be one of the reasons increasingly complicated cars can exist at all.