Key Takeaway
- Automotive testing runs as a ladder: model in the loop, then software in the loop, then processor in the loop, then hardware in the loop. Each rung is slower and more expensive than the one below.
- Push every defect down the ladder. A fault found in SIL costs a fraction of the same fault found on a HIL rig.
- ISO 26262 does not only ask whether you tested. It asks whether you can trace each test back to a requirement and forward to a result.
- Fault injection is the part teams skip. Normal path testing tells you the feature works, not what happens when a sensor lies.
- Rig time is the scarce resource. Schedule it like a machine tool, not like a meeting room.
Overview
01
What automotive embedded software testing has to prove
Most software testing asks whether the product does what it should. Automotive testing asks a second question that costs far more to answer.
Automotive embedded software testing has to show what happens when things go wrong: a sensor drifts, a bus message arrives late, a task misses its deadline. Those are the cases the safety argument rests on.
That is why automotive embedded testing is organised as a ladder of environments rather than as a single test phase. Each rung catches a different class of fault, and moving up costs more per hour.
For the wider engineering picture see our guide on embedded software for industrial systems.
Ladder
02
Four environments, in the order to use them
The rule is simple. Find each defect at the cheapest rung that can find it.
| Environment | What it runs | What it catches |
|---|---|---|
| Model in the loop | The control model against a plant model, no code yet | Logic and control errors, before anyone writes a line |
| Software in the loop | Generated or hand written code on a host machine | Code that does not match the model, and most functional defects |
| Processor in the loop | The compiled code on the target processor or an instruction set simulator | Compiler and target specific behaviour, arithmetic and overflow faults |
| Hardware in the loop | The real ECU wired to simulated sensors and actuators | Timing, bus behaviour, electrical faults, everything the earlier rungs cannot see |
Hardware in the loop is the most convincing and the most expensive, which is why it comes last rather than first. A team that runs everything on a HIL rig is paying rig rates for defects a host machine could have caught.
Traceability
03
What ISO 26262 actually asks for
Teams new to this expect a list of required tests. What the standard is more interested in is whether the evidence hangs together.
Traceability runs in both directions. Each requirement points to the tests that verify it, and each test result points back to the requirement it serves. A test suite with no link to requirements is work you cannot use in the safety argument.
The other expectation is that the depth of testing follows the risk. A function with a higher integrity level carries heavier verification, and the reasoning for that level has to be written down rather than assumed.
Where the architecture is AUTOSAR, the operating system layer needs its own attention. Missed deadlines, blocked tasks and priority inversion are failure modes that ordinary functional testing does not surface.
Agree the traceability tooling before the first test is written. Retrofitting links between requirements, tests and results across an existing suite is slow, dull and almost always underestimated.
Practice
04
Six things that separate a working test setup
These are the differences between a suite that protects a release and a suite that produces reports.
Fault injection, not just happy paths
Stuck sensors, out of range values, dropped bus frames and delayed messages. This is where the safety argument is actually tested.
Rig time treated as scarce
Schedule hardware in the loop like a machine tool, with a queue and an owner. Rigs sitting idle overnight are the cheapest capacity most programmes never use.
Embedded automation testing in CI
The SIL and PIL rungs belong in the pipeline, running on every build. If they only run when someone remembers, they are documentation rather than testing.
Coverage that means something
Structural coverage at the level your integrity classification requires, reported per build. Coverage as a single site wide percentage tells you nothing about the function that matters.
Records tied to builds
Every result linked to the exact image and the exact test version that produced it. An auditor asks which build, and a report without that answer is not evidence.
Somebody who can say no
A test lead with the authority to hold a release and explain why in one page. Without it the suite reports and the schedule decides.
Outsourcing
05
What an outside team can take on
Choosing an embedded software testing firm for automotive work is mostly about which rungs of the ladder you hand over.
- Start with the SIL suite. Automated testing embedded systems work on a host machine is the easiest piece to hand over and the fastest to show value.
- Add the pipeline job. Ownership has to include running it, not just writing tests that somebody else wires in.
- Then the PIL layer. Target specific behaviour, still without competing for rig time.
- Share the rig last. Decide whether hardware sits with you and is reached remotely, or whether a duplicate rig goes to the team.
- Keep the safety argument in house. Evidence can be produced anywhere. Signing off the argument is not a task to send away.
For the general offshore version of this, see our guide to offshore test automation.
Working With Us
06
How Dev Station supports automotive test programmes
We build and maintain test suites for embedded products, take on the pipeline job with them, and work to the coding and traceability rules your programme requires.
Where a customer runs a HIL setup already, we work into it rather than proposing a replacement. Where the rig does not exist, we build it alongside the suite so the two grow together.
Our engineers work from Vietnam with overlap into UK GMT and US Eastern and Pacific hours, and we invoice in GBP or USD. Send us your requirement list and your current suite and we will tell you which rung each test belongs on.
FAQ
07
Frequently asked questions
What programmes ask when planning verification.
What is the difference between SIL and HIL testing?
Software in the loop runs the code on a host machine against simulated inputs. Hardware in the loop runs the real controller wired to simulated sensors and actuators, which catches timing and electrical behaviour that a host cannot reproduce.
Why run model in the loop at all?
Because it catches control logic errors before any code exists, which is the cheapest point in the programme to fix them.
Does ISO 26262 require specific tools?
It requires confidence in the tools you use, which is why tool qualification exists. The practical effect is that switching test tooling late in a programme is expensive.
Can embedded testing automotive domain work be automated?
The lower rungs largely can, and should run on every build. Hardware in the loop can be automated too, and it stays constrained by how many rigs you have rather than by how much you script.
Want an AI assistant to summarize or cite this guide?
Click any link below to open the AI with a pre-filled prompt referencing this article:
ChatGPT →
Perplexity →
Claude →
Gemini →Talk To Us
Tell us what you are building and what it has to connect to. An engineer answers, and you get a straight view of what the work would take.
Get In Touch →
