Why the V-Model Matters for Automotive Safety
ISO 26262 mandates traceability at every phase of the safety lifecycle. The V-Model isn’t just a helpful diagram—it’s a compliance requirement. Part 8 of ISO 26262 explicitly requires bidirectional traceability from customer requirements through system design, implementation, and back through verification and validation. Without a structured decomposition-verification framework, proving compliance becomes impossible.
The V-Model solves three fundamental problems in safety-critical development:
-
Requirements Cascade: Customer needs don’t directly translate to implementation details. The V-Model enforces progressive refinement from abstract customer requirements → concrete system requirements → detailed design specifications.
-
Test Coverage: Without systematic verification planning, teams miss critical test scenarios. The V-Model ensures each requirement level has corresponding verification activities.
-
Traceability Enforcement: Regulatory audits demand proof that every customer requirement is implemented and tested. The V-Model structure makes traceability explicit rather than implicit.
Think of the V-Model as a two-way highway system. The left side is the “Requirements Highway” moving from abstract (top) to concrete (bottom). The right side is the “Verification Highway” moving from concrete tests (bottom) back to abstract validation (top). The horizontal crossbars are bridges connecting corresponding levels—every requirement must have a bridge to its verification.
The V-Model Structure in TestAuto2
TestAuto2 implements the V-Model through work item types, link roles, and PowerSheet configurations. Here’s how the abstract V-Model maps to Polarion entities:
Left Side: Requirements Decomposition
The left descending path represents progressive refinement:
-
Customer Requirements (customerRequirement): High-level stakeholder needs and regulatory mandates. “The AEB system shall prevent collisions in urban scenarios.”
-
System Requirements (sysReq): Functional and performance specifications derived from customer needs. “The AEB system shall detect stationary obstacles at distances up to 80m.”
-
Subsystem Requirements (subsysReq): Component-level requirements partitioned by architectural subsystem. “The radar module shall provide range measurements with ±2m accuracy.”
-
Design Requirements (desReq): Implementation-specific technical requirements. “The radar DSP shall execute FFT processing within 5ms latency.”
Each level uses the refines link role to establish parent-child relationships. A design requirement “refines” a system requirement, which “refines” a customer requirement. This creates a traceable chain from abstract intent to concrete implementation.
Right Side: Verification and Validation
The right ascending path represents testing activities:
-
Design Verification (verificationTestCase): Component-level testing proving design requirements are met. “Verify radar FFT latency under maximum target load.”
-
Subsystem Verification: Integration testing proving subsystem requirements are satisfied.
-
System Verification (verificationTestCase): System-level functional testing proving system requirements are met. “Verify obstacle detection at 80m distance.”
-
Customer Validation (validationTestCase): End-to-end scenario testing proving customer requirements are satisfied. “Validate AEB collision avoidance in ISO 26262 urban test scenarios.”
Test cases use the verifies link role pointing to requirements. A design verification test “verifies” a design requirement. The system automatically tracks coverage: for example, 83% of system requirements have linked verification test cases (26/31).
The Bottom: Implementation Domain
The bottom of the V represents actual implementation artifacts:
- System Elements: Physical or logical components (ECU, Sensor Housing, CAN Transceivers)
- Functions: Operational capabilities (Obstacle Detection, Collision Risk Assessment)
- Characteristics: Measurable properties (Operating Voltage, Detection Range, Response Time)
- Failure Modes: FMEA analysis of how functions/characteristics can fail
This implementation domain feeds into FMEA workflows, where failure modes link to risk controls that mitigate safety risks.
How the V-Model Enforces Traceability
TestAuto2’s RTM Domain Model defines expansion paths that walk the V-Model structure. PowerSheet configurations leverage these paths to generate traceability matrices.
Example: Whole RTM Sheet
The Whole RTM PowerSheet expands from Customer Requirements → System Requirements → Design Requirements → Test Cases in a single denormalized view. This creates a multi-level traceability matrix where each customer requirement row expands to show all derived system requirements, their design requirements, and linked test cases.
The PowerSheet configuration defines:
entities:
- type: CustomerRequirement
query: document = $document
expand:
- name: systemRequirements
cardinality: many
expand:
- name: designRequirements
cardinality: many
expand:
- name: testCases
cardinality: many
Many teams treat the V-Model as a conceptual diagram shown in presentations. In TestAuto2, the V-Model is enforced through data model constraints. The RTM model’s entity types, link roles, and cardinality rules make it impossible to create work items that violate V-Model structure. For example, you cannot create a design requirement without linking it (via “refines”) to a parent system requirement.
V-Model Phases and ISO 26262 Parts Mapping
The V-Model aligns directly with ISO 26262’s safety lifecycle phases:
| V-Model Level | ISO 26262 Part | Work Item Types | Document Types |
|---|
| Customer Requirements | Part 3: Concept Phase | customerRequirement, hazard, safetyGoal | customerSpecification, riskSpecification |
| System Requirements | Part 4: System Level | sysReq, systemElement, function | systemRequirementsSpecification, functionsSpecification |
| Design Requirements | Part 5 (Hardware) / Part 6 (Software) | desReq, characteristic | designRequirementsSpecification, characteristicsSpecification |
| Implementation | Part 5/6 Implementation | (external code repositories) | — |
| Design Verification | Part 5/6 Verification | verificationTestCase | testsSpecification |
| System Verification | Part 4 Verification | verificationTestCase | testsSpecification |
| Customer Validation | Part 4 Validation | validationTestCase | testsSpecification |
- 87.1% requirements completion (31 system requirements)
- 100% traceability (all requirements linked)
- 83.9% verification (26/31 system requirements have test cases)
- 100% FMEA coverage (all failure modes analyzed)
Bilateral Traceability: Proving Completeness
ISO 26262 Part 8 Clause 6 requires bidirectional traceability—not just forward links from requirements to tests, but backward links proving every test traces to a requirement and every requirement traces to a customer need.
TestAuto2 enforces this through backlinked link roles:
refines has a reverse role refinedBy: Design Requirement → refines → System Requirement | System Requirement → refinedBy → Design Requirementverifies has a reverse role verifiedBy: Test Case → verifies → Requirement | Requirement → verifiedBy → Test Case
Dashboard coverage bars use Lucene queries to identify gaps:
Forward Coverage Example:
Covered: type:sysReq AND backlinkedWorkItems:verifies=TA*
Gap: type:sysReq AND NOT backlinkedWorkItems:verifies=TA*
Covered: type:verificationTestCase AND linkedWorkItems:verifies=TA*
Gap: type:verificationTestCase AND NOT linkedWorkItems:verifies=TA*
Practical Application: From Concept to Validation
Let’s walk through a single requirement flowing through the V-Model:
Customer Requirement (Top-Left):
“The AEB system shall prevent collisions with stationary obstacles in urban driving scenarios.”
System Requirement (Decomposition):
“The AEB system shall detect stationary obstacles at distances up to 80m in urban conditions.”
(Linked via refines to customer requirement)
Design Requirement (Further Decomposition):
“The radar module DSP shall execute FFT-based range estimation with 5ms maximum latency.”
(Linked via refines to system requirement)
Design Verification (Bottom-Right, Ascending):
Test Case: “Verify radar DSP FFT latency under maximum target load scenarios.”
(Linked via verifies to design requirement)
System Verification (Ascending):
Test Case: “Verify obstacle detection range ≥80m using calibrated stationary targets.”
(Linked via verifies to system requirement)
Customer Validation (Top-Right):
Validation Test Case: “Validate AEB collision avoidance in ISO 26262-3 urban scenarios (Annex B).”
(Linked via validates to customer requirement)
This complete traceability chain is visualized in the Requirements Traceability Report, where each customer requirement expands to show the full downstream cascade and upstream validation evidence.
How to Use the V-Model in Daily Work
Understanding the V-Model helps you navigate TestAuto2 more effectively:
-
Writing Requirements: Always link new requirements to their parent using the
refines link role. Use Refine Requirements Across Levels for step-by-step guidance.
-
Planning Verification: For every requirement, create a corresponding test case and link it using the
verifies role. See Create Verification Test Cases.
-
Checking Coverage: Use the Requirements Space Dashboard to identify traceability gaps—requirements without linked tests or customer requirements without validation evidence.
-
FMEA Analysis: Failure modes at the bottom of the V feed back into risk controls, which trace upward to requirements they mitigate. Learn more in FMEA Workflow.
-
Standards Compliance: The Standards Compliance Overview shows per-standard readiness computed from V-Model traceability completeness.
The V-Model isn’t just theory—it’s the structural framework TestAuto2 enforces through data model constraints, PowerSheet configurations, and dashboard coverage metrics. Every link you create, every test case you write, and every requirement you refine fits into this bilateral traceability highway connecting customer intent to verified implementation.
Next Steps:
