Engineering · Verification & Validation
MIL, SIL, and HIL Testing for ECU Programmes
Test benches, Test Automation, and execution evidence aligned to ISO 26262 and ISO/SAE 21434. HIL and SIL Testing is the XiL test-services offering within our Verification & Validation practice — delivered on your benches or ours, for single ECUs through vehicle platforms with 100+ ECUs.
What do HIL and SIL Testing Services cover?
HIL and SIL Testing Services build and operate the closed-loop environments that verify automotive software before it reaches a vehicle: MIL runs the controller model against a plant model, SIL runs production code on the host in Continuous Integration, and HIL runs the real ECU against a real-time plant simulation with fault injection. Agnile specifies and commissions the environments, develops test cases from requirements, automates regression, and delivers execution evidence traceable to ISO 26262 and ISO/SAE 21434 obligations.
Scope
What the Engagement Covers
Programmes come to us at every stage: some need a first SIL environment stood up, some need an idle HIL bench commissioned, and some need an existing suite extended, automated, or simply executed at a pace the internal team cannot sustain. The scope below flexes to all three.
SIL Environments and Continuous Integration Execution
We build closed-loop SIL environments around your production code — plant models, interface stubs, and test harnesses — and wire the suite into your Continuous Integration pipeline so regression runs on every commit. Scaling, saturation, and module-interaction defects surface in minutes on a build server instead of hours on a bench.
HIL Bench Specification and Commissioning
We capture bench requirements from your ECU’s real interfaces — I/O count, CAN, CAN FD, LIN, and Automotive Ethernet channels, load simulation, and fault-insertion needs — write a platform-neutral specification, then integrate plant models and rest-bus simulation, run acceptance tests, and hand the bench over with operator documentation. We commission new benches and revive inherited ones.
Test-Case Development from Requirements
Every test case starts from an identified system or software requirement and keeps that link through execution. We derive cases using equivalence classes, boundary values, and fault-model analysis, so coverage is arguable rather than asserted. For how test-case design fits the wider integration ladder, read our complete guide to System Integration Testing — MIL, SIL, and HIL explained end to end.
Regression Suites and Test Automation Frameworks
Bench hours are scarce; unautomated suites decay. We build the Test Automation layer — sequencing, parameterisation, result capture, and reporting — that lets one engineer run overnight what a team once ran in a week, and we structure suites so a requirement change breaks one test asset, not forty.
Fault Injection and Robustness Testing
The bench earns its cost where the vehicle cannot go: shorts, open circuits, undervoltage and overvoltage, corrupted and delayed bus traffic, implausible sensor values. We design and execute fault-injection campaigns that verify degraded-mode behaviour and safety mechanisms — repeatably, and without endangering a prototype or a driver.
Cybersecurity Test Execution on the Bench
The same bench that verifies function verifies defence. We execute Fuzz Testing on CAN and diagnostic interfaces, exercise Secure Onboard Communication failure modes — failed MAC verification, freshness desynchronisation, replayed frames — and verify secure diagnostics behaviour, turning security requirements into repeatable regression tests. For the offensive discipline behind these cases, see our Automotive Penetration Testing services.
The XiL ladder
MIL vs SIL vs HIL at a Glance
These are stages of one strategy, not alternatives. Each stage replaces one piece of simulation with one piece of reality — and every defect class belongs at the cheapest stage that can catch it.
| Stage | What Runs | What It Verifies | When It Fits |
|---|---|---|---|
| MIL — Model-in-the-Loop | The controller model closed-loop against a plant model in desktop simulation — no production code yet | Control logic and algorithm behaviour against functional requirements; the reference for later back-to-back comparison | Function development, before production code exists |
| SIL — Software-in-the-Loop | Production source code compiled for the host PC, running in the same closed loop | Model-to-code equivalence, fixed-point scaling, saturation and overflow behaviour, software module interactions | Per-commit regression in Continuous Integration, from first code drop onwards |
| HIL — Hardware-in-the-Loop | The real ECU — or an ECU network — with real electrical interfaces, against a real-time plant and rest-bus simulation | Hardware-software integration, bus communication, diagnostics, network management, end-to-end timing, behaviour under injected electrical faults | Integration and release testing once ECU samples exist; fault injection and cybersecurity test execution |
Rigor
ASIL-Driven Test Rigor
ISO 26262 does not ask whether you tested — it asks whether the methods matched the ASIL. Requirements-based testing and interface testing apply at every level; fault injection testing, resource usage evaluation, and back-to-back comparison between model and code strengthen from recommended to highly recommended as integrity rises toward ASIL D. We plan each suite against those method tables, so the test campaign is defensible in a safety audit, not just green on a dashboard.
The result is a rigor argument per test level: which methods ran where, at what coverage, with which results — evidence that slots into the Safety Case. New to the standard? Start with our ISO 26262 primer.
Deliverables
What You Keep After the Engagement
Everything is built to outlast us — in your toolchain, under your version control, runnable by your engineers.
- Test Specifications. Test cases with preconditions, stimuli, expected results, and pass/fail criteria — derived from requirements, reviewed with your engineers, and versioned alongside them.
- Automation code. Test sequences, harnesses, plant-model interfaces, and framework configuration — maintainable source, not recorded macros.
- Traceability matrices. Requirement to test case to latest execution result, maintained in your requirements-management toolchain, with coverage gaps visible per release.
- Execution reports. Results per run and per release with deviation analysis — packaged as evidence for safety and cybersecurity cases, ready for assessor review.
Engagement models
Three Ways to Engage
Test-Package Delivery
A fixed-scope package: test cases developed for a defined set of requirements, executed on your bench or ours, delivered with results, traceability, and deviation analysis. Clear acceptance criteria, scoped per programme.
Bench and Suite Build-Out
We specify and commission the HIL bench or SIL environment, build the Test Automation framework and first regression suite on it, then hand over a running system with documentation and operator training.
Test Automation Teams
Agnile test engineers embedded onsite or offshore — operating benches, extending suites, and carrying regression across releases as a durable part of your programme, in your toolchain and your meetings.
FAQ
HIL and SIL Testing Questions
Scope Your HIL and SIL Testing Engagement
A 60-minute scoping call: bring your requirements set, your bench inventory, or the regression suite that no longer keeps up with releases. We respond to qualified enquiries within one business day.