Engineering · Cross-Domain Verification & Validation
Agnile plans, executes, and argues verification for automotive, aerospace, and embedded software — the V&V strategy across test levels, requirements-based testing, structural coverage to MC/DC, regression, and the release evidence an assessor or certification authority reads. Building and running the MIL, SIL, PIL, and HIL rigs themselves is a separate service: MIL, SIL and HIL testing services.
Reviewed by Shreyansh, Founder & CTO ·
Verification and validation services show, with traceable evidence, that software meets its requirements (verification) and that the system fulfils its intended use (validation). Agnile Technologies defines the V&V strategy across unit, integration, system, and vehicle levels, derives requirements-based test cases, closes structural coverage — statement, branch, or MC/DC as the ASIL or DAL demands — automates regression, and assembles release evidence for ISO 26262, DO-178C, and Automotive SPICE assessments.
| Dimension | Verification & Validation (this page) | MIL, SIL and HIL Testing |
|---|---|---|
| The question it answers | What must be verified, at which level, and how is the argument closed? | Which environment runs the test, and is it fit for purpose? |
| Typical outputs | V&V plan, test specifications, coverage reports, traceability, release evidence | Rigs, plant models, rest-bus simulation, automation code, execution reports |
| Domains | Automotive, aerospace, embedded, and software programmes | Automotive ECUs and ECU networks |
System integration testing
System Integration Testing (SIT) is the verification activity that exercises a software or hardware system across its integrated components — module, subsystem, and external- interface levels — to confirm that the interactions between parts behave as specified. In automotive and safety-critical contexts, SIT happens after unit-level Software-in-the-Loop testing and before vehicle-level validation. It is the layer where integration defects — interface mismatches, timing issues, fault propagation, network message drops — surface before they reach production silicon. ISO 26262 Part 6 Clause 10 governs software integration and verification for automotive safety-critical software; DO-178C §6.4.3 covers requirements-based integration testing for airborne software; ASPICE SWE.5 is the process-assessment view of the same activity.
Map the system architecture into integrated components — modules, subsystems, interface contracts, message flows. Each boundary becomes a test target.
Decide the integration approach — bottom-up, top-down, big-bang, or incremental. For ASIL or DAL programmes this is documented in the Test Strategy aligned to ISO 26262 Part 6 / DO-178C §6.4 rigor targets.
Design test cases from the integrated software requirements — nominal interactions, abnormal interactions, fault injection, timing and sequencing, message-drop scenarios. Each test case traced back to a requirement.
Stub or simulate components not yet ready, instrument the integration layer for observability, and configure coverage tooling (VectorCAST, LDRA, GoogleTest, dSPACE, ETAS) to capture structural-coverage results.
Run the test cases on the integrated system. Capture pass/fail, structural-coverage data, timing measurements, and defect logs. In automotive this frequently runs on HIL benches with real ECU hardware and a simulated plant model.
Triage failures, categorise root cause (interface mismatch, timing issue, requirement defect, test defect), file and track to resolution, re-run after fix and regression.
Bundle test specifications, test cases, test results, structural-coverage analysis, and bi-directional traceability into release evidence. For ISO 26262 and DO-178C programmes this becomes part of the certification or Confirmation Review pack.
For the full walkthrough of the MIL, SIL and HIL stages that integration testing sits between, read System Integration Testing in automotive: MIL, SIL and HIL explained.
Verification coverage
Capability areas
Verification strategy, test planning, coverage objectives, toolchain selection, traceability planning, and release evidence structure.
Which requirements are verified at model, software, processor, hardware, or vehicle level — and how the results combine into one coverage argument across embedded software and control systems.
Test case design, automation, traceability to requirements, test execution, result analysis, defect logging, and regression support.
Structural coverage, MC/DC support where applicable, fault injection, robustness testing, validation reports, and release evidence packages.
Building the rigs, plant models, and bench automation those levels run on is delivered through our MIL, SIL, PIL and HIL testing services; safety-case integration of the evidence through functional safety engineering.
Process
Durations are typical. Steps 1 and 2 run once per programme; steps 3 to 6 repeat per release scope, and coverage closure is sized per software item.
Requirements, architecture, ASIL or DAL allocation, existing tests, tools, and coverage data reviewed; testability and ambiguity issues logged before any test is written.
Which requirement is verified at which level — MIL, SIL, PIL, HIL, or vehicle — with methods, coverage targets, independence, entry and exit criteria, and tool-confidence needs, written into a plan you can fund and an assessor can read.
Test cases derived with equivalence classes, boundary values, state transitions, and fault-based analysis, each traced to a requirement and reviewed with your engineers.
Tests implemented in your framework and run in Continuous Integration or on the bench; failures triaged to requirement, code, test, or environment defects and tracked to closure.
Statement, branch, or MC/DC measured as the ASIL or DAL demands; missing tests added where requirements justify them, uncoverable code justified in writing.
Test summary, coverage report, traceability matrix, open problem reports, and deviation rationale assembled per release candidate.
Deliverables
Each artefact is produced in your toolchain and mapped to the standard or assessment it serves, so release evidence is assembled as the work happens rather than reconstructed later.
| Deliverable | What It Contains | Evidence It Supports |
|---|---|---|
| V&V strategy and test plan | Test levels, methods, coverage targets, independence, entry and exit criteria, environments, and tools | ISO 26262 Part 8 Clause 9 verification planning; DO-178C Software Verification Plan; ASPICE verification strategy |
| Test specification | Test cases with preconditions, inputs, expected results, and pass criteria, derived by named methods | ISO 26262 Part 6 test-case derivation methods; DO-178C normal-range and robustness test cases |
| Bidirectional traceability matrix | Requirement to test case to result, maintained in your requirements-management toolchain | ASPICE traceability and consistency; DO-178C trace data; ISO 26262 verification evidence |
| Structural coverage report | Statement, branch, or MC/DC per unit, with written justification for uncovered code | ISO 26262 Part 6 structural coverage; DO-178C §6.4.4.2 structural coverage analysis |
| Regression results | Per-build pass/fail trends, flaky-test log, and links to problem reports | Change impact and release decisions; ASPICE regression strategy |
| Release evidence package | Test summary, coverage, traceability, open problem reports, and deviation rationale per release | Safety-case and certification inputs — ISO 26262 confirmation measures, Automotive SPICE assessments, DO-178C Software Accomplishment Summary inputs |
| Tool-confidence inputs | Tool use cases, potential tool errors, detection measures, and validation evidence | ISO 26262 Part 8 Clause 11 tool classification; DO-330 tool qualification inputs |
Engagement models
A V&V strategy and test architecture, a requirements-based test campaign with CI regression, or coverage closure to MC/DC on a software unit. We scope the actual work on the call.
Test strategy across MIL, SIL, PIL, HIL, and vehicle layers. We design what gets tested where, why, and how coverage will be argued. Outcome: a written test architecture aligned to your ASIL / DAL rigor target and ready to fund.
Engagement flow
Deliverables
Requirements-based test cases derived for a defined release scope, implemented in your framework, executed, and wired into CI regression — with results, deviations, and traceability your release review can rely on. Need the bench itself? HIL bench builds run through our HIL & SIL testing service.
Engagement flow
Deliverables
Targeted coverage closure on a software unit under DAL A or ASIL D rigor. We design missing test cases, justify uncoverable code, and bundle the structural-coverage analysis into the certification or Confirmation pack.
Engagement flow
Deliverables
Why Agnile
We test on the silicon already in your programme. PIL and HIL on AURIX, RH850, S32K, S32G — not host-only environments that hide target-specific bugs.
MC/DC closure on real safety-critical code. Every condition independently affecting the decision outcome — written-rationale uncoverable-code analysis bundled in.
Tool-agnostic — VectorCAST, LDRA, GoogleTest, Unity, dSPACE, ETAS. We integrate into your existing pipeline; we don't ask you to retool.
ASPICE Level 2+ test deliverables. Test specifications, cases, and results bidirectionally traceable to software requirements — ready for assessment.
Release evidence an assessor can read. Test summaries, coverage reports, traceability, and deviation rationale packaged per release — not reconstructed the week before an audit.
Standards depth
ISO 26262 Part 6 at ASIL D. DO-178C §6 at DAL A. ASPICE SWE.4–SWE.6 in steady state.
ISO 26262 Part 6
Software-level requirements for ASIL A–D
Requirements-based testing at software unit, integration, and embedded-software level (Clauses 9–11). Coverage recommendations scale with ASIL — statement coverage highly recommended at A and B, branch coverage at B to D, MC/DC at D.
DO-178C §6
Verification process for airborne software
DO-178C verification objectives — requirements-based test cases at HLR and LLR, structural coverage analysis with MC/DC at DAL A, robustness testing per §6.4.2.2.
MC/DC
Modified Condition / Decision Coverage
MC/DC test sets — every condition independently affects the decision outcome — for safety-critical decisions. Uncoverable code justified with written rationale.
ASPICE SWE.4–SWE.6
Software verification processes (Automotive SPICE, VDA QMC)
SWE.4 unit verification, SWE.5 integration test, and SWE.6 qualification test in ASPICE 3.1 — ASPICE 4.0 renames SWE.5 and SWE.6 to software component verification and integration verification, and software verification. Specifications, results, and bidirectional traceability maintained for assessment.
ISO 26262-8 Clause 11
Confidence in the use of software tools
Tool use cases, tool impact and error-detection analysis, and validation evidence as inputs to the tool confidence level your safety team sets — and to DO-330 tool qualification on airborne programmes.
VectorCAST / LDRA
Test + coverage tooling
VectorCAST or LDRA integrated into the build — auto-generate harness code, configure target adapters for AURIX / RH850 / S32K, drive coverage at Statement / Decision / MC/DC.
How we test — the V&V progression
Six stages, each with named methodology and an explicit deliverable. Earlier faults cost less — we push test maturity left in the V-model.
01
We define the test strategy across MIL, SIL, PIL, HIL, and vehicle layers — what gets tested where, why, and how coverage will be argued.
→ Test Strategy + Architecture
02
Algorithm-level tests against the Simulink / TargetLink / Stateflow model. Catches numeric and behavioural defects before code generation.
→ MIL test cases + reports
03
Generated or hand-written code tested in a host environment — GoogleTest, Unity, VectorCAST. Coverage tooling configured for Statement / Decision / MC/DC.
→ Unit + integration tests
04
Code executed on the target processor with stimuli mirroring the SIL test cases. Catches compiler / runtime / target-specific defects that host environments hide.
→ PIL test reports + delta
05
ECU under test on a dSPACE or ETAS bench with simulated plant model and real CAN/Ethernet stimuli. Closed-loop scenarios, fault injection, robustness testing.
→ HIL bench + scenarios
06
Field validation campaigns, edge-case scenarios, and final coverage closure. Independent verification at DAL A / ASIL D. Test report bundle ready for programme acceptance or audit.
→ Coverage closure pack
01 · ASPICE SWE.4–SWE.6
Deliverable
→ Test Strategy + Architecture
02 · Earliest verification
Deliverable
→ MIL test cases + reports
03 · Unit + integration
Deliverable
→ Unit + integration tests
04 · Target-specific behaviour
Deliverable
→ PIL test reports + delta
05 · System-level closed-loop
Deliverable
→ HIL bench + scenarios
06 · Final argument
Deliverable
→ Coverage closure pack
Case study
Anonymised by request. References available on qualified enquiry.
Anonymised engagement summary. Customer identity and programme details withheld under NDA. Metrics reflect internally documented delivery outcomes.
Indian powertrain programme · ASIL D ECU
Context
An Indian engineering team was preparing for vehicle-programme acceptance on a powertrain ECU classified ASIL D. Their existing structural coverage stood at 87% Branch coverage with no MC/DC argument — sufficient for ASIL B, not ASIL D. They had 6 weeks before submission and 12 kSLOC of safety-relevant code to close.
Approach
Agnile ran a coverage gap analysis, designed targeted MC/DC test cases against the existing requirements, justified uncoverable code with written rationale, and integrated the resulting suite into the team's VectorCAST harness. Coverage closure delivered in 5 weeks, evidence pack in week 6.
What we delivered
What the customer got
ASIL D · 12 kSLOC · MC/DC closed · 5 weeks
FAQ
Explore next
The test-environment service that runs these tests, the safety practice that consumes the evidence, and the guides behind the terms.
A 60-minute call: plan a V&V strategy, scope a requirements-based test campaign, or close MC/DC for a DAL A function. We respond to qualified enquiries within one business day.