Skip to main content

​
Why a Structured Data Model Matters

In traditional safety engineering, teams often manage requirements in Word, FMEA in Excel, and test cases in specialized tools. These silos create several problems:
  • Traceability gaps: Manual linking between documents becomes outdated as projects evolve
  • Duplicate data entry: The same information (like a system element or failure mode) appears in multiple spreadsheets
  • Inconsistent terminology: Different teams use different names for the same concept
  • Compliance risk: Auditors struggle to verify complete traceability chains
TestAuto2 solves these problems with a unified data model where every artifact — from hazards to requirements to test cases — is a typed work item with defined relationships. Think of it like a relational database: instead of storing customer requirements in one Excel file and system requirements in another, both are work item types in the same model, linked by a formal “refines” relationship.
Traditional safety projects are document-centric: requirements live in specs, FMEA lives in spreadsheets. TestAuto2 is entity-centric: requirements, hazards, failure modes, and test cases are all nodes in a graph, connected by typed relationships. Documents (LiveDocs, Risksheets, PowerSheets) are just different views onto this graph.

​
The Data Model Architecture

The TestAuto2 data model has three layers: diagram
  1. Entity Layer: 20+ work item types representing requirements, system architecture, risks, and tests
  2. Relationship Layer: Typed links (RTM domain model) defining how entities connect
  3. View Layer: Risksheets, PowerSheets, and dashboards that query and display the underlying graph

​
Entity Types: The Building Blocks

TestAuto2 defines 20 specialized work item types organized into six functional domains:

​
Requirements Hierarchy

  • Customer Requirement: Stakeholder needs and regulatory mandates (top of V-model)
  • System Requirement: System-level functional requirements derived from customer needs
  • Subsystem Requirement: Component-scoped requirements refining system requirements
  • Design Requirement: Implementation-level specifications (hardware or software)

​
System Architecture

  • System Element: Physical or logical product components (System → Subsystem → Component hierarchy)
  • Function: Operational capabilities or behaviors of system elements
  • Characteristic: Measurable properties with target values and tolerances

​
Risk and Safety Analysis

  • Hazard: Potential sources of harm in operational scenarios (ISO 26262)
  • Harm: Consequences of hazards to persons or property
  • Safety Goal: Top-level safety requirements derived from HARA
  • Failure Mode: Ways a function or element can fail (DFMEA)
  • Process Failure Mode: Ways a manufacturing process can fail (PFMEA)
  • Risk Record: Generic risk item for ISO 14971 or other frameworks
  • Risk Control: Mitigation actions to reduce failure likelihood or severity

​
Verification and Validation

  • Test Case: Generic test specification
  • Verification Test Case: Tests that verify requirements are correctly implemented
  • Validation Test Case: Tests that validate customer needs are met

​
Process Engineering

  • Process Step: Manufacturing or assembly operation
  • Control Plan Item: Inspection or measurement controls for characteristics
Each work item type has custom fields specific to its role. For example, Failure Mode has severity/occurrence/detection ratings and Action Priority calculations, while Test Case has test steps and expected results. Using typed entities ensures data integrity and enables specialized Risksheet/PowerSheet views.

​
Relationship Types: How Entities Connect

The RTM (Requirements Traceability Matrix) domain model defines how entities relate. Key relationship types:
Link RoleFrom → ToMeaningExample
refinesLower requirement → Higher requirement”Breaks down into more detail”System Req refines Customer Req
implementsSystem Element → Requirement”Realizes the functionality”ECU implements System Req
allocatedToFunction → System Element”Assigned to component”Braking function allocatedTo Brake ECU
verifiesTest Case → Requirement”Confirms correct implementation”Test Case verifies Design Req
validatesValidation Test → Customer Req”Confirms customer need is met”Validation Test validates Customer Req
hasHazardOperational Situation → Hazard”Can lead to hazard”Night driving hasHazard Obstacle misdetection
assessesFailure Mode → Characteristic”Analyzes risk for characteristic”FM assesses Sensor accuracy
mitigatesRisk Control → Failure Mode”Reduces risk from failure”Design change mitigates FM
parentWork Item → Work Item”Hierarchical decomposition”Subsystem parent System
Don’t confuse traceability links (refines, implements, verifies) with document hierarchy (parent/child in LiveDocs). A System Requirement can refine a Customer Requirement even if they’re in different documents. The links represent semantic relationships, not physical containment.

​
How Data Flows Through the Model

Here’s a concrete example showing how a single customer need flows through the entire model: 
[Customer Requirement]
  "Vehicle shall avoid collisions with pedestrians"
         │ refines
         ▼
[System Requirement]
  "AEB system shall detect pedestrians at 50m range"
         │ implements                    │ verifies
         ▼                               ▼
[System Element]                   [Verification Test Case]
  Camera Module                     "Pedestrian detection at 50m"
         │ allocatedTo
         ▼
[Function]
  Pedestrian Detection
         │ assesses
         ▼
[Failure Mode] ────────mitigates────► [Risk Control]
  False negative        "Dual sensor fusion"
  (S=10, O=6, D=4)     (reduces O to 2)
         │ analyzedIn
         ▼
[Risksheet: Component DFMEA]
  Displays S/O/D ratings, calculates Action Priority,
  shows pre/post mitigation risk reduction
This single customer need touches eight different work item types and seven relationship types. The beauty: all of this is captured once in the data model, then displayed in multiple views (RTM PowerSheet, FMEA Risksheet, Coverage Dashboard) without duplication.

​
Document Types and Their Role

While the data model is entity-centric, Polarion still organizes work items into documents (LiveDocs). TestAuto2 uses document types to categorize modules:
  • customerSpecification: Customer requirements documents
  • systemRequirementsSpecification: System-level requirements
  • designRequirementsSpecification: Design requirements
  • testsSpecification: Test case documents
  • functionsSpecification: Functional architecture
  • characteristicsSpecification: Product characteristics
  • riskSpecification: HARA, FMEA, HAZID documents (with Risksheet attachments)
  • powersheet: Traceability matrix views (driven by RTM model)
Document types enable filtering (e.g., “show all design requirements documents”) and workflow transitions (e.g., “approve this FMEA specification”).
A System Requirement in document A can link to a Design Requirement in document B. Documents provide organization and access control, but traceability crosses document boundaries.

​
Custom Fields: Extending the Model

Each work item type has custom fields specific to its purpose. For example: Failure Mode custom fields:
  • fmSeverity (1-10), fmOccurrence (0-10), fmDetection (0-10): AIAG-VDA FMEA ratings
  • fmSevNew, fmOccNew, fmDetNew: Post-mitigation ratings
  • fmActionPriority, fmAPNew: Action Priority (H/M/L) calculated from S/O/D
  • nextPreventiveAction: Recommended risk reduction measure
System Requirement custom fields:
  • classification: SC (Safety Critical) or CC (Conformance Critical)
  • iso26262Part: Which part of ISO 26262 the requirement addresses
Test Case custom fields:
  • testSteps: Step-by-step test procedure
  • expectedResults: Pass/fail criteria
This field customization enables specialized Risksheet configurations (like FMEA formulas) and PowerSheet renderers (like SC/CC badges).

​
How This Enables Key Features

The unified data model unlocks powerful capabilities:
  1. Automatic traceability coverage: Dashboards query link relationships to calculate ”% of requirements verified by tests” without manual updates
  2. Multi-level FMEA: System/Subsystem/Component FMEAs share the same Failure Mode type but filter by linked System Element hierarchy
  3. Cross-product references: PowerSheets expand from Requirements through System Elements to Failure Modes to Risk Controls in a single view
  4. Standards compliance metrics: Safety Readiness Scorecard counts work items by type, checks link completeness, and maps to ISO 26262 parts
  5. Impact analysis: Changing a System Element shows all linked Functions, Failure Modes, and Risk Controls affected

​
Common Misconceptions

“Work items are just rows in a spreadsheet.”
No — work items are persistent entities with IDs, revision history, and workflow states. Risksheets and PowerSheets are views that query and display them, but the underlying data lives in Polarion’s repository. “Traceability links are manually maintained.”
Partially true — users create links (via Risksheet context menus or PowerSheet multi-select pickers), but once established, coverage metrics and traceability reports update automatically. No copy-paste needed. “Each FMEA document is independent.”
No — all Failure Modes share the same work item type. The multi-level FMEA hierarchy comes from linking Failure Modes to different System Elements (System/Subsystem/Component) and filtering Risksheet views accordingly.

​
Next Steps

Now that you understand the data model structure, explore how it’s applied: For hands-on practice, try: