Skip to main content
Unlike simple “linkage” (where any artifact can link to any other), TestAuto2’s traceability model enforces structured relationships that mirror ISO 26262’s V-Model methodology, ensuring complete bidirectional coverage from customer needs down to test evidence.

​
What Traceability Means in Automotive Safety

In traditional software development, traceability might be optional or informal. In automotive functional safety, traceability is a mandatory compliance requirement specified in ISO 26262-8 (Supporting Processes) and enforced by standards auditors. Every safety-relevant requirement must demonstrate:
  1. Upstream traceability — What customer need or hazard justifies this requirement’s existence?
  2. Downstream traceability — How is this requirement implemented in design artifacts?
  3. Verification traceability — Which test cases prove this requirement is satisfied?
  4. Risk traceability — Which failure modes threaten this requirement, and which controls mitigate those risks?
Traceability is not just about creating links. It’s about creating the right kinds of links between the right kinds of artifacts at the right lifecycle stages. A requirement linked to a random test case provides no value if that test doesn’t actually verify the requirement’s acceptance criteria.

​
The Three Layers of Traceability

TestAuto2’s traceability model consists of three interacting layers: diagram

​
Layer 1: Work Item Type Network

The foundation defines what can link to what. TestAuto2 establishes 20+ work item types organized into domains:
DomainWork Item TypesPurpose
Requirements HierarchyCustomer Requirement, System Requirement, Subsystem Requirement, Design RequirementV-Model decomposition cascade
System ArchitectureSystem Element, Function, CharacteristicStructural and functional breakdown
Risk AnalysisHazard, Harm, Failure Mode, Process Failure Mode, Risk Record, Risk ControlISO 26262 HARA + AIAG-VDA FMEA
Verification/ValidationTest Case, Verification Test Case, Validation Test CaseV&V evidence
Process ControlProcess Step, Control Plan ItemIATF 16949 APQP workflow
Each type declares which link roles it accepts. For example, a System Requirement can have:
  • Outgoing links: refines → Customer Requirement
  • Incoming links: refines ← Design Requirement, verifies ← Test Case, assesses ← Failure Mode
Link roles define why two items are connected. TestAuto2 uses semantic relationship types:
Link RoleMeaningExample
refinesDecomposes / elaboratesSystem Req -> Customer Req
verifiesProves compliance through testingTest Case -> Requirement
validatesConfirms user need satisfactionValidation Test -> Customer Req
mitigatesReduces riskRisk Control -> Failure Mode
assessesAnalyzes potential failureFailure Mode -> Characteristic
failureModesIdentifies risk scenariosSafety Goal -> Hazard
Bidirectional Semantics: Most roles have inverse meanings. When Test Case TC-45 verifies System Requirement SR-12, Polarion automatically creates the reverse link: SR-12 is verifiedBy TC-45. This ensures traceability queries work in both directions without manual duplication.
Generic “related to” links are useless for compliance. An auditor needs to see that requirement SR-23 is verified by TC-101, not just “linked”. Typed relationships enable automated gap analysis: “Show me all System Requirements with no verifying test cases.”

​
Layer 3: Expansion Paths

PowerSheet configurations define how to traverse multi-hop traceability chains. An expansion path specifies a sequence of link roles to follow when building a traceability matrix. Example from the Whole RTM PowerSheet: This expansion path generates the complete V-Model trace: Customer → System → Design → Test in a single PowerSheet view, with automatic gap detection at every level.

​
How Traceability Flows Through the V-Model

The V-Model methodology organizes traceability into two flows:

​
Downward Flow: Requirements Decomposition

Requirements refine from abstract customer needs into implementable specifications: Each refinement step adds technical detail while maintaining semantic consistency with parent requirements. The refines link role captures this parent-child relationship.

​
Upward Flow: Verification and Validation

Test cases prove that implementation satisfies requirements, working up the V from design to customer:
Verification asks: “Did we build it right?” (Test against design specifications)
Validation asks: “Did we build the right thing?” (Test against customer needs)
Both use different link roles (verifies vs. validates) to maintain semantic clarity.
See Verification vs Validation for detailed explanation of this distinction.

​
Cross-Domain Traceability: Linking Risk to Requirements

Beyond the V-Model’s vertical traceability, automotive safety demands horizontal traceability connecting risk analysis to requirements: 
    Hazard                 Failure Mode              Risk Control
"Unintended braking"  →  "Radar false positive"  →  "Multi-sensor fusion algorithm"
       │                          │                          │
       │ failureModes             │ assesses                 │ mitigates
       ↓                          ↓                          ↓
  Safety Goal            Characteristic            Design Requirement
"Minimize false          "Radar detection          "Camera + radar fusion:
 activations"             confidence threshold"     activate only if both agree"
This cross-domain traceability ensures:
  1. Every hazard leads to safety goals
  2. Every failure mode links to characteristics that can fail
  3. Every risk control traces to design requirements that implement the control
The RTM Domain Model defines these cross-domain relationships using entity types and expansion rules that PowerSheets and Risksheets query.

​
Traceability Gap Analysis

TestAuto2 automatically detects traceability gaps using Lucene queries embedded in dashboard widgets. Coverage metrics answer questions like:
  • “Which System Requirements have no verifying test cases?”
    Query: type:sysReq AND NOT backlinkedWorkItems:verifies=TA*
    Result: 5 of 31 System Requirements lack verification (83% coverage)
  • “Which Design Requirements don’t refine any System Requirement?”
    Query: type:desReq AND NOT linkedWorkItems:refines=TA*
    Result: 0 of 15 Design Requirements are orphaned (100% coverage)
  • “Which SC/CC Characteristics have no Failure Mode analysis?”
    Multi-hop query: Find characteristics with classification:(sc OR cc), check for back-linked Failure Modes via assesses role
    Result: 11 of 14 SC/CC characteristics covered (78% coverage)
These gap queries drive the coverage bars on space dashboards and feed into the Safety Readiness Scorecard.

​
Cardinality Constraints

Not all relationships allow multiple links. TestAuto2’s RTM model defines cardinality rules:
RelationshipCardinalityMeaning
Design Requirement → System Requirement (refines)1 to 1..*Each design requirement must refine at least one system requirement
System Requirement → Test Case (verifiedBy)0..* to 0..*Requirements can have multiple test cases; tests can verify multiple requirements
Failure Mode → Characteristic (assesses)1..* to 1Each failure mode must assess exactly one characteristic (the thing that fails)
Risk Control → Failure Mode (mitigates)1..* to 1..*Controls can mitigate multiple failure modes; failure modes can have multiple controls
Cardinality constraints are enforced through:
  • Risksheet column configuration (single-select pickers vs. multi-select pickers)
  • PowerSheet entity factory settings (mandatory vs. optional link fields)
  • Velocity macro validation in dashboard reports
See Constraints and Validation for complete constraint definitions.

​
Practical Applications

Understanding the traceability model unlocks practical workflows: For detailed link role definitions and expansion path syntax, see the RTM Model Configuration reference section.

​
Why This Model Matters

A robust traceability model is the difference between a collection of documents and an auditable safety case. TestAuto2’s structured approach ensures:
  1. Completeness — Every requirement has upstream justification and downstream implementation
  2. Consistency — Semantic link roles prevent meaningless connections
  3. Auditability — Gap queries prove compliance before external audits
  4. Maintainability — Changes propagate through impact analysis using traceability paths
Without this model, automotive functional safety projects drown in spreadsheet cross-references, manual link maintenance, and audit findings. With it, traceability becomes a living system that evolves with the product.