Purpose and Scope
The Data Model Diagram documents:
- Entity Types: All work item types (hazard, requirement, design element, test case, failure mode, risk control, etc.) with their properties and roles
- Relationships: Link roles defining how entities reference each other (refines, verifies, validates, mitigates, assesses, allocates, etc.)
- Hierarchies: Multi-level decomposition paths (system → subsystem → component; customer requirement → system requirement → design requirement)
- Expansion Paths: RTM relationships used by PowerSheet configurations to denormalize related entities into grids
- Standards Mapping: Which work item types implement which ISO 26262, AIAG-VDA, or IATF 16949 requirements
This report is essential for:
- Configuration managers designing new link roles or work item types
- Safety engineers tracing requirements through the V-model
- Test engineers validating verification/validation traceability
- Project architects understanding solution scope and customization points
Work Item Type Hierarchy
TestAuto2 implements a hierarchical work item type structure organized by safety lifecycle phase:
| V-Model Phase | Work Item Types |
|---|
| User Needs | User Need, Stakeholder Requirement |
| System Design | System Requirement, Safety Goal, System Function |
| Subsystem Design | Subsystem Requirement, Subsystem Function, Design Element |
| Component Design | Component, Characteristic, Special Characteristic |
| Risk Analysis | Hazard, Failure Mode, Risk Control, Control Plan |
| Implementation | Process Step, Use Step, Manufacturing Process |
| Verification | Test Case, Test Result, Verification Evidence |
| Validation | Validation Activity, Validation Evidence |
Entity Type Reference
| Entity Type | Work Item ID Pattern | Purpose | ISO 26262 Phase | Custom Fields |
|---|
| CustomerRequirement | CR-* | User-facing system needs | Part 3 (Concept) | trackingStatus, category |
| SystemRequirement | SR-* | System-level functional/safety requirements | Part 4 (System Design) | safetyRelevant, classification (SC/CC) |
| DesignRequirement | DR-* | Component/subsystem design specifications | Part 5 (Hardware) | asil, classification (SC/CC) |
| UserNeed | UN-* | Stakeholder needs traced to validation | Part 3 | validationType, stakeholder |
| UseStep | US-* | Operational scenario steps for validation testing | Part 3 | operationalPhase, scenarioContext |
| Hazard | HAZ-* | Potential harmful events in operational context | Part 3 (HARA) | severity, exposure, controllability, asil |
| Harm | HAR-* | Consequences of hazard occurrence | Part 3 | severityLevel, harmedParty |
| SafetyGoal | SG-* | Mitigation objective for hazards | Part 3 | asil, functionalSafetyRequirement |
| SystemElement | SE-* | Hierarchical system decomposition (system/subsystem/component) | Part 4 | hierarchyLevel, functionAllocation |
| Function | FN-* | System function allocated to element | Part 4 | safetyRelevant, operationalMode |
| Characteristic | CHAR-* | Design characteristic (dimension, tolerance, material) | Part 5 (IATF) | specialCharacteristic (SC/CC) |
| FailureMode | FM-* | Design FMEA failure mode (what could go wrong) | Part 5 | severity, occurrence, detection, actionPriority (H/M/L) |
| ProcessFailureMode | PFM-* | Process FMEA failure mode (manufacturing risk) | AIAG-VDA | rpn, rpmPost, controlType |
| RiskRecord | RR-* | Captured risk with mitigation strategy | Part 4 | riskLevel (H/M/L), probability |
| RiskControl | RC-* | Risk mitigation measure (design change, test, inspection) | Part 4-6 | controlType (inherent/protective/info), verificationMethod |
| VerificationTestCase | VTC-* | Test verifying design requirement against test case | Part 6 | testLevel (unit/integration/system), verificationMethod |
| ValidationTestCase | VLTC-* | Test validating system meets user need | Part 3 | validationType, stakeholder |
| ProcessStep | PS-* | Manufacturing process step traced to control plan | IATF 16949 | processArea, equipmentRequired |
| ControlPlanItem | CPI-* | Inspection/control method for process step | IATF 16949 | controlMethod, sampleFrequency, measurementMethod |
Primary Link Roles
The following link roles define traceability relationships between entity types:
| Link Role | Source → Target | Cardinality | Purpose | Notes |
|---|
| refines | CR → SR, SR → DR, DR → Characteristic | 1:N | Hierarchical decomposition through requirement levels | Bidirectional |
| verifies | VerificationTestCase → DesignRequirement, SystemRequirement | N:N | Test cases validating design/system requirements | Backward link from test |
| validates | ValidationTestCase → UserNeed | N:N | Validation tests justifying user needs | Backward link from test |
| assesses | FailureMode → Characteristic | N:N | Failure modes analyzing design characteristics | FMEA traceability |
| mitigates | RiskControl → FailureMode | N:N | Risk controls addressing failure modes | Pre-/post-mitigation tracking |
| monitors | RiskControl → ProcessFailureMode | N:N | Process controls addressing process failure modes | PFMEA links |
| causes | FailureMode → Harm (implicit) | N:N | Failure consequence linking | FMEA analysis chain |
| addresses | SafetyGoal → Hazard | 1:N | Safety goal mitigating hazard | HARA analysis |
| allocates | Function → SystemElement | N:N | Functions assigned to system elements | System architecture |
| supports | DesignRequirement → SystemRequirement | N:N | Design requirements satisfying system requirements | RTM decomposition |
| implements | SystemElement → SafetyGoal | N:N | Element implementing safety goal | ASIL allocation |
| controls | ControlPlanItem → Characteristic | N:N | Control plan inspecting characteristics | IATF traceability |
| measures | ControlPlanItem → ProcessFailureMode | N:N | Control detecting process failure mode | Prevention/detection |
| traces | ProcessStep → ProcessFailureMode | N:N | Process step potential failure context | PFMEA environment |
| justifies | Function → UserNeed | N:N | Function satisfying user need | Operational mapping |
Most links are bidirectional: forward (refines, verifies, assesses) and backward (back-linked via workitem.backlinkedWorkItems()). Use backward links in Velocity templates when querying “what tests verify this requirement?” rather than “what does this requirement verify?”
RTM Expansion Paths
PowerSheet RTM configurations use the following expansion paths to denormalize work item relationships into grid views:
| PowerSheet | Expansion Chain | Purpose |
|---|
| Whole RTM | CustomerRequirement → (refines) → SystemRequirement → (refines) → DesignRequirement | End-to-end traceability through requirement hierarchy |
| Component RTM | SystemElement → (allocates) → Function → (supports) → DesignRequirement | Design element decomposition and requirement allocation |
| Design Characteristics | SystemElement → (composed of) → Characteristic → (back-links: assessedBy) → FailureMode | Design element characteristics and FMEA coverage |
| System Verification | SystemRequirement → (back-verifies) → VerificationTestCase | Verification test matrix for system requirements |
| User Need Validation | UserNeed → (back-validates) → ValidationTestCase | Validation test traceability |
| Process Steps | ProcessStep → (traces) → ProcessFailureMode | PFMEA process context mapping |
| Control Plan | ControlPlanItem → (controls) → Characteristic → (back-refines) → DesignRequirement | Control plan to design requirement trace |
Custom Field Dependencies
Changing custom field values affects downstream calculations in Risksheet formulas, FMEA severity/occurrence/detection formulas, and dashboard metrics. Always validate dependent fields when modifying configurations.
HARA Analysis Fields
| Hazard | | | | |
|---|
| ├── severity: S0 | S1 | S2 | S3 (severity enum) | |
| ├── exposure: E0 | E1 | E2 | E3 | E4 (exposure enum) |
| ├── controllability: C0 | C1 | C2 | C3 (controllability enum) | |
| └── asil: QM | A | B | C | D (calculated via severity × exposure × controllability matrix) |
| SafetyGoal | | | | |
| └── asil: QM | A | B | C | D (required to match or inherit from originating hazard) |
FMEA Analysis Fields
| Field | Type | Description |
|---|
| Severity (S) | Enum (1-10) | Impact rating of failure effect |
| Occurrence (O) | Enum (1-10) | Likelihood of failure cause |
| Detection (D) | Enum (1-10) | Ability to detect before reaching customer |
| RPN | Calculated | Risk Priority Number (S x O x D) |
| Action Priority | Enum | High / Medium / Low based on AP matrix |
| Current Prevention Controls | Text | Existing prevention measures |
| Current Detection Controls | Text | Existing detection methods |
Characteristic Fields
| Field | Type | Description |
|---|
| Characteristic ID | String | Unique identifier |
| Name | String | Characteristic description |
| Classification | Enum | SC (Special) / CC (Critical) / Standard |
| Specification Limits | Text | Upper/lower tolerance bounds |
| Measurement Method | Text | How the characteristic is measured |
| Control Method | Enum | SPC / Inspection / Go-NoGo / Functional Test |
Data Flow Diagram
Coverage Calculation Queries
The Data Model Diagram report implements the following automated coverage queries using Lucene syntax:
Requirement Traceability
# Unlinked customer requirements
type:customerReq AND NOT linkedWorkItems:refines=TA*
# System requirements without design requirement refinement
type:sysReq AND NOT linkedWorkItems:refines=TA*
# Design requirements not verified by test cases
type:desReq AND NOT backlinkedWorkItems:verifies=TA*
FMEA Coverage
# Failure modes without Action Priority
type:failureMode AND (severity:null OR occurrence:null OR detection:null)
# High-priority items remaining post-mitigation
type:failureMode AND actionPriorityPost:H
# Unmitigated high-risk failure modes
type:failureMode AND actionPriority:H AND NOT linkedWorkItems:mitigates=TA*
Verification Traceability
# Test cases without linked requirements
type:verificationTestCase AND NOT linkedWorkItems:verifies=TA*
# Design requirements without verification evidence
type:desReq AND NOT backlinkedWorkItems:verifies=TA*
Integration with Other Reports
| Related Report | Integration Point |
|---|
| Requirements Traceability Report | References same link roles; validates chain coverage |
| System DFMEA Report | Displays failure modes and action priority calculations based on custom fields |
| Risk Control Effectiveness Report | Uses work item type relationships to validate traceability completeness |
| System Structure Navigator | Navigates system element hierarchy defined in data model |
| FMEA Coverage Report | Counts failure modes by type and status |
Viewing the Data Model Diagram
To view the interactive Data Model Diagram report:
- Navigate to the Documentation space
- Open the Data Model Reference page
- Click the Data Model Diagram widget
- Use the Expand button to show all entity types and relationships
- Click an entity type card to see its custom fields and validation rules
- Hover over relationship arrows to see link cardinality and bidirectional capabilities
The data model can be extended by adding new work item types or link roles in .polarion/documents/ configuration. Changes require re-running coverage calculations and may affect dependent dashboard reports. Consult the Modify RTM Model guide before making structural changes. Related Pages
