Purpose: Define the data model, traceability logic, and rationale behind the AIAG–VDA FMEA PowerSheet configuration in Polarion ALM.
1. Introduction
The AIAG–VDA FMEA Handbook establishes a harmonized methodology to analyze risk within design and process development.
To realize its full traceability potential inside Polarion ALM, each step of the FMEA must be expressed as structured data and directional relationships between work items.
Within Polarion ALM, this model is realized through Nextedy RISKSHEET, a Polarion-integrated application for functional safety and risk management.
Nextedy RISKSHEET provides the spreadsheet-style interface, work item types, and linking logic described below, allowing engineers to apply the AIAG–VDA approach natively within Polarion without coding or external templates.
This paper documents the complete Polarion configuration—from Structure Analysis (Step 2) to Optimization (Step 6)—and justifies each link, field, and column in accordance with the standard.
2. Overall Concept
Each Risk Record in Polarion represents a single FMEA line (i.e., one row of the FMEA form):
a combination of the Focus Element, its Function, Failure Mode, Cause, Effect, and associated controls and actions.
The model connects four main information domains:
| Domain | Represented by | Polarion Work Item Type | Purpose |
|---|---|---|---|
| Structure | System Elements & Characteristics | systemelement, characteristic | Hierarchical product structure |
| Function | Functional intent of each element | function | What the element does or shall do |
| Risk | Analysis records per failure | riskrecord | Captures failure modes, effects, causes, and ratings |
| Optimization | Actions and Verification loop | task, requirement, testcase | Defines mitigations and evidence of effectiveness |
2.1 Implementation in Nextedy RISKSHEET
Insert a short, visual, product-oriented explanation before the “Step Mapping” table:
The model described in this paper is implemented directly inside Nextedy RISKSHEET for Polarion.
- a configurable PowerSheet interface to display the FMEA structure (Steps 2–6),
- editable and read-only columns mapped to Polarion fields and link roles,
- automatic color-coded Action Priority formulas, and
- native links to Tasks, Requirements, and Test Cases as described in this paper.
This ensures full compliance with the AIAG–VDA FMEA workflow, while maintaining the flexibility of Polarion work item types and traceability.
3. AIAG–VDA Step Mapping to Polarion Data Model
| AIAG–VDA Step | Objective | Polarion Entity | Key Relationships |
|---|---|---|---|
| Step 2 – Structure Analysis | Define hierarchy of system elements and characteristics | System Element, Characteristic | System Element → contains → System Element ; System Element → has_feature → Characteristic |
| Step 3 – Function Analysis | Define functions and interdependencies | Function | System Element → defines → Function |
| Step 4 – Failure Analysis | Identify effects, modes, and causes | Risk Record | links to System Element, Function, Characteristic |
| Step 5 – Risk Analysis | Evaluate S/O/D and Action Priority (AP) | Risk Record fields (cf_ …) | Internal fields compute AP |
| Step 6 – Optimization | Define Actions and verify effectiveness | Task, Requirement, Test Case | Task → mitigates → Risk Record; Requirement → relates_to → Task; Test Case → relates_to → Requirement |
4. Column-by-Column Definition and Justification
🟣 STRUCTURE ANALYSIS (STEP 2)
| Column | Meaning | Editable? | Polarion Link / Field | Reason per AIAG–VDA |
|---|---|---|---|---|
| 1. Next Higher Level | Parent element containing the Focus Element | ❌ Read-only (via link role parent) | Shows hierarchical context of analysis (§6.2.1) | |
| 2. Focus Element | Element currently analyzed | ✅ (Risk Record → context → System Element) | Central anchor for the row; defines scope of failure analysis | |
| 3. Next Lower Level / Characteristic Type | Direct or indirect child element or feature affecting the Focus Element | ✅ (Risk Record → characteristic → System Element/Characteristic) | AIAG–VDA permits “dependent structures” — not only immediate children (§6.2.2); represents dependencies one or two levels below. |
🟢 FUNCTION ANALYSIS (STEP 3)
| Column | Meaning | Editable? | Link or Field | Rationale |
|---|---|---|---|---|
| 1. Next Higher Level Function and Requirement | Function(s) of parent element | ❌ Read-only (derived via parent’s defines) | Supports top-down traceability between levels (§6.3.1) | |
| 2. Focus Element Function and Requirement | Function performed by the Focus Element | ✅ (Risk Record → function → Function) | Core function evaluated for failure modes (§6.3.2) | |
| 3. Next Lower Level Function and Requirement or Characteristic | Function or requirement of linked lower element / characteristic | ❌ Read-only (derived from characteristic target’s backlinks) | Connects functional dependence to lower-level features (§6.3.3). Empty if target is Characteristic. |
🔴 FAILURE ANALYSIS (STEP 4)
| Column | Meaning | Editable? | Field | Justification |
|---|---|---|---|---|
| Failure Effect (FE) | Consequence to higher level or end user | ✅ | cf_failure_effect | AIAG–VDA Step 4 requires link to “next higher function” (§6.4.1). |
| Severity (S) | Rating of effect seriousness (1–10) | ✅ | cf_severity | Standard severity scale. |
| Failure Mode (FM) | How the Focus Element fails | ✅ | cf_failure_mode | Central to Risk Record definition (§6.4.2). |
| Failure Cause (FC) | Root cause at next lower level or feature | ✅ | cf_failure_cause | Enables bottom-up cause analysis (§6.4.3). |
🟡 RISK ANALYSIS (STEP 5)
| Column | Meaning | Editable? | Field | Reason per AIAG–VDA |
|---|---|---|---|---|
| Prevention Control (PC) | Existing measure to prevent cause | ✅ | cf_prevention_control | Prevention is assessed first (§6.5.2). |
| Occurrence (O) | Likelihood of cause occurring | ✅ | cf_occurrence | Rated 1–10 per handbook table. |
| Detection Control (DC) | Existing control to detect cause or failure mode | ✅ | cf_detection_control | Distinguishes between PC and DC (§6.5.3). |
| Detection (D) | Detection rating (1–10) | ✅ | cf_detection | Numeric assessment for DC effectiveness. |
| Action Priority (AP) | Calculated priority (Low/Middle/High) | ⚙️ Auto-computed via formula | Required output of AIAG–VDA Step 5 (AP replaces RPN). |
🔵 OPTIMIZATION (STEP 6)
| Column | Meaning | Editable? | Link Direction | AIAG–VDA Justification |
|---|---|---|---|---|
| Task ID / Title | Mitigation Action defined to reduce risk | ✅ | Task → Risk Record (mitigates) | Step 6 defines Actions that address causes and reduce risk (§6.6.1). Action owns the mitigation. |
| Action Type / Responsible / Dates / Status | Execution fields of the Action | ✅ | Task fields | Support planning and tracking of mitigation execution. |
| Requirements | Requirements resulting from completed Actions | ❌ | Requirement → Task (relates_to) | Step 6 demands “implementation and verification of actions” — the result becomes a new requirement (§6.6.2). |
| Req Verification | Verification evidence (Test Cases) confirming those Requirements | ❌ | Test Case → Requirement (relates_to) | Step 6 and 7 require proof of effectiveness (§6.6.3). Test Cases own the verification link. |
| New S/O/D & New AP | Re-evaluation after Action closure | ✅ (fields + formula) | — | Represents the “residual risk” per AIAG–VDA Table 6-8. |
5. Directionality and Ownership Rationale
| Relationship | Direction | Reason for Direction Choice |
|---|---|---|
| Task → Risk Record | Action mitigates risk | The Action is the active entity executing mitigation; Risk is the object of mitigation. |
| Requirement → Task | Requirement relates_to the Action that produced it | Requirement is the result of Action execution, not its sub-task. Keeps Requirement independent and reusable. |
| Test Case → Requirement | Test Case relates_to Requirement | Verification objects always point to the specification they verify. Consistent with ISO 15288 and AIAG–VDA verification principles. |
This directionality ensures correct data lineage:
Risk Record ←mitigated by– Task ←related from– Requirement ←related from– Test CaseIt expresses the lifecycle: Identify → Act → Define → Verify.
In Nextedy RISKSHEET, these relationships are automatically established by link-role configuration and displayed dynamically in the PowerSheet columns. Users can manage all AIAG–VDA linkages interactively without scripting or manual maintenance.
6. Compliance with AIAG–VDA Principles
| Principle | Implementation in Polarion |
|---|---|
| Top-Down Structure → Bottom-Up Failure | Parent/child links between System Elements and Functions mirror hierarchical decomposition (§6.2–6.3). |
| Linkage of Function and Failure | Each Risk Record connects Focus Element Function with its Failure Mode (§6.4). |
| Action Planning and Tracking | Step 6 columns map to Action responsibility, status, and timing (§6.6). |
| Verification of Effectiveness | Requirements and Test Cases close the loop of evidence (§6.7). |
| Residual Risk Evaluation | New S/O/D and AP fields support final assessment (§6.8). |
7. Benefits of This Representation
| Benefit | Description |
|---|---|
| Full Traceability | Every failure mode is connected upstream to its structure and function and downstream to its verified mitigation. |
| AIAG–VDA Compliance | All mandatory steps and relationships are covered in logical sequence. |
| Audit Readiness | Inspectors can trace from risk to verification evidence without manual cross-reference. |
| Reuse and Scalability | Functions, Requirements, and Tests are independent work items usable in other contexts. |
| Automation Potential | Computed Action Priority and visual color coding support automatic risk ranking and dashboards. |
8. Conclusion
This Polarion configuration implements the AIAG–VDA FMEA handbook’s complete logic chain inside a traceable, data-driven model.
The chosen link directions reflect the true ownership of actions, requirements, and evidence as prescribed by the standard:
Cause → Action → Requirement → Verification
The model ensures that every risk record is not only analyzed and rated but also supported by a closed loop of mitigation and proof of effectiveness, making it both methodologically sound and audit-ready.
9. Nextedy RISKSHEET and Polarion Integration
Nextedy RISKSHEET acts as the operational layer implementing this FMEA model within Polarion ALM.
- It provides preconfigured work item types and relationships for System Elements, Functions, Risk Records, Actions, Requirements, and Test Cases.
- All columns described above correspond directly to configurable RISKSHEET columns and link renderers.
- Users can modify field bindings, rating formulas, and color codings without code changes.
This architecture makes RISKSHEET the foundation for applying AIAG–VDA-compliant risk management in functional safety, cybersecurity, and process quality domains directly inside Polarion.
Appendix A – Simplified Diagram of Link Flow
System Element (parent)
└─ System Element (focus)
├─ Function
├─ Characteristic
└─ Risk Record
├─ Failure Effect / Mode / Cause
├─ Prevention & Detection Controls
├─ mitigated by → Task (Action)
│ ├─ relates_to ← Requirement (Resulting spec)
│ │ └─ relates_to ← Test Case (Verification)
└─ Updated S/O/D → New Action Priority✅ Final Statement:
This FMEA model represents a fully compliant AIAG–VDA implementation inside Polarion ALM.
It connects structure, function, failure, and optimization data into a single, traceable, and verifiable ecosystem, ensuring that every risk is analyzed, acted upon, and proven effective in line with international best practice.