Link roles define how work items reference each other in TestAuto2 — Automotive Safety Solution. They establish the traceability pathways required by ISO 26262 and support the V-model verification and validation workflow.
Overview
Link roles are directional relationships between work items. Each link role has:
- A source work item type (the entity making the reference)
- A target work item type (the entity being referenced)
- A direction (forward link and optional reverse/backlink)
- Cardinality rules (one-to-one, one-to-many, many-to-many)
- Constraints (optional validation rules)
The RTM domain model defines all available link roles. PowerSheet and Risksheet configurations use these roles to traverse and display related work items in denormalized grid views.
Link roles form the backbone of ISO 26262 Part 8 Clause 6 traceability evidence. Every link role in this reference maps directly to compliance requirements: requirements refinement, verification/validation coverage, and risk control effectiveness.
Standard Link Roles (Forward Direction)
The table below shows primary link roles defined in the RTM model. Each role supports forward and reverse traversal via PowerSheet/Risksheet RTM queries.
| Role Name | Source Type | Target Type | Cardinality | Purpose | Compliance |
|---|
refines | Requirement | Requirement | One-to-many | Hierarchical requirement decomposition across V-model levels (system → subsystem → component) | ISO 26262-4 §6, §8 |
verifies | TestCase | Requirement | Many-to-many | Verification test cases linked to design/system requirements (left-side V) | ISO 26262-4 §6, §8 |
validates | ValidationTestCase | CustomerRequirement | Many-to-many | Validation test cases demonstrating customer requirements met (right-side V) | ISO 26262-4 §8 |
assesses | FailureMode | Characteristic | One-to-many | Failure modes that affect design characteristics (FMEA hazard analysis) | ISO 26262-5 §7 |
mitigates | RiskControl | FailureMode | Many-to-many | Risk control measures reducing post-mitigation severity/occurrence | ISO 26262-4 §8, §9 |
monitors | ControlPlanItem | Characteristic | Many-to-many | Control plan items measuring characteristic values during production | IATF 16949 §5.2 |
traces | Function | SystemElement | Many-to-one | Functions allocated to system elements (system architecture decomposition) | ISO 26262-4 §7 |
implements | DesignRequirement | Characteristic | One-to-many | Design requirements specifying characteristic requirements (form, fit, function) | ISO 26262-5 §6 |
analyzes | Function | FailureMode | One-to-many | FMEA failure modes caused by functional failures | ISO 26262-5 §7 |
Requirements Refinement Chain
The refinement hierarchy traces requirement decomposition from customer needs through system, subsystem, and design levels:
Each refines link documents how a higher-level requirement is decomposed into more specific requirements at the next level. Reverse links (accessed via backlinks in PowerSheet) show which requirements a given requirement refines.
| Property | Details |
|---|
| Bidirectional | Yes — both forward and reverse links available |
| Multiplicity | One parent can refine into many children; one child typically refines one parent |
| Validation | Cyclic link detection — system prevents cycles (A→B→C→A) |
| Usage | RTM PowerSheets, traceability reports, coverage metrics |
Verification and Validation Links
ISO 26262 Part 4 §8 distinguishes verification (building the system correctly) from validation (building the right system):
Verification: verifies Link Role
Source: TestCase (verification test)
Target: SystemRequirement or DesignRequirement
Semantics: "This test case verifies that this requirement is met"
Direction: Backward from test perspective
Cardinality: Many TestCases can verify one Requirement (multiple test approaches)
- System verification: TestCase → SystemRequirement
- Design verification: TestCase → DesignRequirement
- Coverage metric: count TestCases with
verifies backlinks per Requirement
PowerSheet: System Verification Sheet, Design Verification Sheet
Validation: validates Link Role
Source: ValidationTestCase (acceptance/user test)
Target: CustomerRequirement
Semantics: "This validation test demonstrates the customer requirement is satisfied"
Direction: Backward from test perspective
Cardinality: Many ValidationTestCases per CustomerRequirement (various validation scenarios)
- User acceptance testing: ValidationTestCase → CustomerRequirement
- Coverage metric: count ValidationTestCases with
validates backlinks per CustomerRequirement
PowerSheet: User Need Validation Sheet
Verification tests (verifies) check that requirements were implemented correctly. Validation tests (validates) check that the implemented system satisfies user needs. ISO 26262 requires both for ASIL B and above.
Risk Control Mitigation Links
FMEA risk controls link to failure modes they mitigate. The RTM model captures pre- and post-mitigation ratings through this traceability:
| Link Role | Source | Target | Semantics |
|---|
mitigates | RiskControl | FailureMode | This control measure reduces the failure mode’s post-mitigation severity, occurrence, or detection rating |
- Multi-level FMEA workflow: For each FailureMode, design RiskControls and link via
mitigates
- Risk Control Plan Risksheet displays FailureModes with their linked RiskControls
- Post-mitigation rating: RiskControl defines new occurrence/detection, but FailureMode retains full pre/post history
- Effectiveness metric: compare pre-mitigation Action Priority to post-mitigation AP
Properties captured:
- Pre-mitigation AP (on FailureMode): severity × occurrence × detection / 10
- Post-mitigation AP (on RiskControl or FailureMode): reduced occurrence/detection after control implementation
- Gap tracking: High post-mitigation AP triggers further risk controls
Function and Characteristic Links
Design decomposition connects functions to system elements and characteristics:
traces Link (Function to System Element)
| Property | Value |
|---|
| Source | Function |
| Target | SystemElement |
| Semantics | Function is allocated to this system element for implementation |
| Cardinality | One Function can be allocated to multiple system elements (distributed function); one element implements multiple functions |
| Usage | System Structure Navigator, subsystem-level design specs |
implements Link (Design Requirement to Characteristic)
| Property | Value |
|---|
| Source | DesignRequirement |
| Target | Characteristic |
| Semantics | This design requirement is realized by specifying this characteristic’s target value and tolerance |
| Cardinality | One DesignRequirement implements one or more Characteristics (e.g., power consumption spec → multiple voltage/current characteristics) |
| Usage | Design Verification Sheet, characteristics traceability |
assesses Link (Failure Mode to Characteristic)
| Property | Value |
|---|
| Source | FailureMode |
| Target | Characteristic |
| Semantics | This failure mode represents a potential deviation from this characteristic’s target or tolerance |
| Cardinality | Many FailureModes can assess one Characteristic (e.g., voltage characteristic → overvoltage, undervoltage, oscillation failure modes) |
| Usage | Characteristics Sheet (PowerSheet), FMEA-to-design traceability |
Expansion Paths in PowerSheet/Risksheet
RTM expansion syntax allows multi-hop traversal of link roles. PowerSheet column configurations use this to denormalize related work items:
# Example: Design Verification Sheet traverses verifies backlinks
Source: DesignRequirement
Expansion: verifyingTestCases.testCase
Semantics: Follow the verifies link role in reverse to find all TestCases that verify this requirement
| Pattern | Expansion Syntax | Reading Direction | Purpose |
|---|
| Requirement → linked tests | verifyingTestCases.testCase | Reverse (backlink) | Show tests verifying a requirement |
| Requirement → child reqs | refiningRequirements.requirement | Forward | Show decomposed child requirements |
| Failure Mode → risk controls | mitigatingRiskControls.riskControl | Reverse | Show controls addressing a failure mode |
| Characteristic → failure modes | assessingFailureModes.failureMode | Reverse | Show failures affecting a characteristic |
| Function → system elements | tracingSystemElements.systemElement | Reverse | Show elements implementing a function |
- One-to-many: Multiple related items appear as grouped rows or nested columns
- Many-to-one: Multiple source items link to same target; PowerSheet denormalizes with repeated target values
- Many-to-many: Full Cartesian expansion — all source-target combinations displayed
Two-level expansions (e.g., Characteristic → FailureMode → RiskControl) create Cartesian products. If one characteristic has 5 failure modes and each failure mode has 3 controls, the expansion generates 15 rows. Large PowerSheets may require filtering or view-based queries.
Link Role Constraints and Validation
The RTM model defines optional constraints on link roles:
| Constraint Type | Example | Effect |
|---|
| Cardinality violation | Linking two Parent Requirements (should only refine to children) | Validation error during link creation |
| Cyclic link | A → B → C → A | Prevention rule; system detects and blocks |
| Type mismatch | Attempting to link TestCase to Hazard (requires FailureMode) | Type constraint checked; link rejected |
| Document scope | Linking across incompatible document types (e.g., Requirements doc to Risks doc) | May be restricted by entityFactory constraints |
- Link creation time — user attempts to link two work items
- RTM query execution — PowerSheet queries verify link roles exist
- Expansion traversal — PowerSheet expansion verifies target type matches expected entity type
Backlinks and Link Coverage Metrics
Many link roles support backlink queries — reverse traversal to find all source items linking to a target:
# Example backlink query: find all TestCases verifying this SystemRequirement
SELECT testCase WHERE verifies.target = <current-item>
| Metric | Calculation | Link Role |
|---|
| Verification Coverage | count(SystemRequirement backlinks from TestCase via verifies) / total SystemRequirements | verifies |
| Validation Coverage | count(CustomerRequirement backlinks from ValidationTestCase via validates) / total CustomerRequirements | validates |
| Risk Control Coverage | count(FailureMode backlinks from RiskControl via mitigates) / total FailureModes | mitigates |
| Traceability Completeness | count(items with any outgoing or incoming link) / total items in level | All roles |
Link Role Usage by Document Type
Different document types emphasize different link roles:
| Document | Primary Link Roles | Purpose |
|---|
| HARA | (none — hazards don’t link to requirements yet) | Hazard identification; safety goals derived from hazards |
| System FMEA | assesses (FailureMode → Function), parent/child | Function-level failure analysis |
| Design FMEA | assesses (FailureMode → Characteristic), mitigates | Characteristic-level failures and risk controls |
| Design Verification Spec | verifies (TestCase → DesignRequirement) | Design-level test coverage |
| Control Plan | monitors (ControlPlanItem → Characteristic) | Production control of critical characteristics |
| Process FMEA | assesses (FailureMode → ProcessStep) | Process-step-level failure analysis |
Link Role Configuration
Link roles are defined in .polarion/nextedy/models/*.yaml RTM model files. Each definition specifies:
LinkRole:
name: "verifies"
sourceType: "TestCase"
targetType: "SystemRequirement"
reverseRoleName: "verifyingTestCases"
cardinality: "many-to-many"
constraints:
- cyclicDetection: true
- typeValidation: true
| Property | Purpose | Example |
|---|
name | Forward link role identifier (used in linking UI) | verifies |
reverseRoleName | Backward link role name (used in RTM expansion queries) | verifyingTestCases |
sourceType | Work item type that creates the link | TestCase |
targetType | Work item type being referenced | SystemRequirement |
cardinality | Multiplicity constraints | many-to-many |
Cross-Reference: Link Roles in RTM Model
For the complete RTM domain model including all entity types, see Entity Types.
For how link roles are traversed in PowerSheet column definitions, see Expansion Paths.
For validation rules applied to links, see Constraints and Validation.
Last updated: February 2026
Related pages: Entity Types · Expansion Paths · Constraints and Validation 
