Purpose and Scope
This automated dashboard assesses risk control measures across four critical dimensions:
- Coverage by Control Type — Distribution across ISO 26262 control hierarchy (inherent safety, protective measures, informational)
- Verification Evidence — Test case linkage validating that controls are objectively verified before safety assessment
- Risk Reduction Effectiveness — Pre-mitigation vs post-mitigation risk metrics (Action Priority for DFMEA, RPN for PFMEA)
- Traceability Completeness — Risk controls linked to failure modes and supporting test cases
The report applies to both Design FMEA (failureMode) and Process FMEA (processFailureMode) workflows, providing unified safety assessment across design and manufacturing contexts.
Risk Control Type Classification
Risk controls are categorized according to ISO 26262 Part 4 and AIAG-VDA hierarchy:
| Control Type | Definition | ISO 26262 Hierarchy | Example |
|---|
inherent-safety-design | Eliminates hazards through architectural design choices | Preferred (Tier 1) | Fail-safe defaults, redundancy, fault tolerance |
protective-measure | Mitigates consequences through detection or protective mechanisms | Secondary (Tier 2) | Watchdog timers, plausibility checks, error detection |
information-for-safety | Relies on operator information, warnings, or procedures | Last resort (Tier 3) | Warning messages, training, operational procedures |
prevention | Prevents failure mode occurrence (FMEA context) | Design control | Root cause elimination, process improvement |
detection | Detects failure after occurrence but before harm (FMEA context) | Detection control | Inspection methods, statistical process control |
Verification Evidence Validation
All risk controls must have objective verification evidence (typically test case links) demonstrating that the control functions as specified and achieves claimed risk reduction. Controls without linked test cases represent verification gaps.
nxOrphanDetect macro to identify risk controls lacking test case linkage:
#set($riskControls = $utils.createQuery("type:riskControl").getWorkItems())
#set($orphanedControls = $utils.macro("nxOrphanDetect", $riskControls, ["verifies"], "outgoing"))
Verification Gaps: $orphanedControls.size() controls without test evidence
- Create verification test cases validating control effectiveness
- Link test cases to risk controls via
verifies link role
- Document test method, pass/fail criteria, and evidence artifacts
- Retest after design changes affecting control implementation
Verification Evidence Table
| Criterion | Requirement | Verification Method |
|---|
| Control Specification | Every risk control must have documented specification | Review control_description field in riskControl work item |
| Test Case Existence | At least one test case per control | Query: testCase with outgoing verifies link to riskControl |
| Test Coverage | Test case must cover control functionality under normal and fault conditions | Review test case description and expected results |
| Objective Evidence | Test execution logs, pass/fail reports, or simulation results | Link to test run or evidence artifact in Test space |
| Retest After Changes | Any design change affecting control requires re-verification | Track in control_version field and test execution records |
Risk Reduction Effectiveness Analysis
The report compares pre-mitigation vs post-mitigation risk assessments to demonstrate that risk controls achieve measurable risk reduction:
Design FMEA — Action Priority (AP) Methodology
Design FMEA uses categorical Action Priority (H/M/L) per AIAG-VDA 2019 standard based on Severity × Occurrence × Detection:
Action Priority Classification (AIAG-VDA 2019):
High (H): Requires immediate action; risk unacceptable without control
Medium (M): Requires evaluation; acceptable only with verified control
Low (L): Acceptable risk; control optional or informational
| Metric | Description | Source Field |
|---|
| Pre-mitigation AP | Initial risk rating before control implementation | premitigationAP enum field |
| Post-mitigation AP | Residual risk rating after control implementation | postmitigationAP enum field |
| AP Reduction | Count of failure modes where AP improves (H→M, H→L, M→L) | Computed from AP comparison |
| Unmitigated High AP | Count of failure modes still rated H after controls | postmitigationAP = 'H' |
#set($failureModes = $utils.createQuery("type:failureMode").getWorkItems())
#set($apBuckets = $utils.macro("nxAPBuckets", $failureModes, "postmitigationAP"))
Design FMEA Post-Mitigation Risk Distribution:
High (H): $apBuckets.high failure modes
Medium (M): $apBuckets.medium failure modes
Low (L): $apBuckets.low failure modes
Not Rated: $apBuckets.na failure modes
Process FMEA — Risk Priority Number (RPN) Methodology
Process FMEA uses numeric Risk Priority Number (RPN) calculated as Severity × Occurrence × Detection:
RPN = Severity (1-10) × Occurrence (1-10) × Detection (1-10)
Maximum RPN = 1000
| Risk Level | RPN Range | Action Required |
|---|
| Low | ≤ 40 | Acceptable as-is; routine monitoring |
| Medium | 41-100 | Monitor process; evaluate control effectiveness |
| High | > 100 | Unacceptable; requires corrective action and verification |
| Metric | Description | Source Field |
|---|
| Pre-mitigation RPN | Initial RPN before control implementation | pfmRPN numeric field |
| Post-mitigation RPN | Residual RPN after control implementation | pfmRPNPost numeric field |
| RPN Reduction | Percentage reduction: (pre - post) / pre × 100 | Computed delta |
| Unmitigated High RPN | Count of process failure modes with post-mitigation RPN > 100 | pfmRPNPost > 100 |
#set($processFailureModes = $utils.createQuery("type:processFailureMode").getWorkItems())
#set($rpnBuckets = $utils.macro("nxRpnBuckets", $processFailureModes, "pfmRPNPost", 40, 100))
Process FMEA Post-Mitigation Risk Distribution:
Low (RPN ≤ 40): $rpnBuckets.low failure modes
Medium (RPN 41-100): $rpnBuckets.medium failure modes
High (RPN > 100): $rpnBuckets.high failure modes
Traceability Completeness Check
Every risk control must be traceable to at least one failure mode (Design FMEA) or process failure mode (Process FMEA). Unlinked controls represent traceability gaps per ISO 26262 Part 4 requirements.
Orphaned Controls Detection
The report identifies risk controls without failure mode linkage:
#set($allRiskControls = $utils.createQuery("type:riskControl").getWorkItems())
#set($orphanedByFailureMode = $utils.macro(
"nxOrphanDetect",
$allRiskControls,
["failureMode", "processFailureMode"],
"outgoing"
))
Unlinked Risk Controls: $orphanedByFailureMode.count
| Gap Type | Root Cause | Resolution |
|---|
| No failure mode link | Control created before FMEA analysis | Link to discovered failure mode or retire |
| No test case link | Control exists but not yet verified | Create verification test case and link |
| No implementation link | Control specified but not designed | Link to design requirement or component |
| Obsolete control | Control no longer needed after design change | Mark as obsolete in control_status field |
Bidirectional Traceability Matrix
The report validates traceability in both directions:
| Direction | Link Role | From | To |
|---|
| Upstream | has_risk_control | Failure Mode | Risk Control |
| Upstream | mitigates | Risk Control | Hazard |
| Downstream | verified_by | Risk Control | Verification Test |
| Downstream | has_evidence | Verification Test | Test Evidence |
| Cross-link | implements | Risk Control | System Requirement |
Safety Assessment Conclusion
The report generates an automated safety readiness determination based on four criteria:
Assessment Criteria
| Criterion | PASS Condition | GAP Condition | FAIL Condition |
|---|
| Verification Evidence | 100% of risk controls have ≥1 linked test case | < 100% linked | Any control without verification |
| Failure Mode Traceability | 100% of risk controls linked to failure modes | < 100% linked | Any orphaned control |
| Residual Risk Acceptance | 0 failure modes with post-mitigation AP=H or RPN>100 | > 0 high residual | Unacceptable high residual risk |
| Post-Mitigation Completeness | 100% of controls have post-mitigation values assigned | < 100% complete | Any incomplete assessment |
Automated Status Badges
The report displays three-tier status indicators:
🔴 DANGER — Unacceptable Residual Risk
Condition: Post-mitigation AP=H for any failureMode
OR post-mitigation RPN>100 for any processFailureMode
Action: Implement additional controls or request ASIL reduction justification
⚠️ WARNING — Verification or Traceability Gaps
Condition: Missing test case links OR orphaned controls
OR incomplete post-mitigation ratings
Action: Create verification test cases, link controls to failure modes,
complete post-mitigation assessments
✅ PASS — Safety Readiness Confirmed
Condition: All four criteria met
Action: Risk Control Effectiveness assessment complete; proceed to next phase
Configuration Properties
Risk Control Work Item Fields
| Property | Type | Description | Example |
|---|
id | Enum | Unique risk control identifier | RC-001 |
title | String | Control name and brief description | Watchdog Timer Monitoring |
control_type | Enum (multi-value) | Classification per ISO 26262 hierarchy | inherent-safety-design, protective-measure |
control_description | Text | Detailed specification of control mechanism and implementation | ”Implement hardware watchdog timer with < 100ms timeout…” |
mitigatesFailureModes | Link | Links to failureMode or processFailureMode items via “mitigates” role | links to failureMode-042 |
verification_method | Enum | Type of verification evidence | Review, Analysis, Simulation, Testing |
test_case_links | Link | Links to testCase via “verifies” role | links to test-TC-015 |
premitigationRisk | Enum | Pre-mitigation risk level (AP or RPN range) | High |
postmitigationRisk | Enum | Post-mitigation risk level after control | Medium |
control_status | Enum | Lifecycle status of control | Active, Planned, Obsolete, On-Hold |
control_version | String | Control design version number for change tracking | 2.1 |
effectiveness_evidence | Link | Links to verification or test execution artifacts | links to Test-Run-2025-02 |
| Related Report | Link | Purpose |
|---|
| FMEA Reports | Navigate to detailed Design/Process FMEA | Review failure mode risk classifications and control linkages |
| FMEA Coverage Report | Verify Design Requirements coverage | Ensure SC/CC Design Reqs have corresponding failure modes and controls |
| System DFMEA Report | Drill into Design FMEA by system element | Analyze control effectiveness across system hierarchy |
| System PFMEA Report | Drill into Process FMEA by element | Analyze process control effectiveness |
| Control Plans Report | Link to manufacturing control implementation | Validate process controls during production |
| Requirements Traceability Report | Bidirectional traceability view | Verify design requirements → test case → risk control chain |
Visual: Risk Control Effectiveness Decision Flow
Implementation and Workflow
Risk Control Effectiveness assessment should occur after Design FMEA and Process FMEA analyses are substantially complete with controls identified, but before design freeze or production readiness review. This ensures timely identification and resolution of verification gaps.
- FMEA Analysis — Complete failure mode identification and risk assessment (AP or RPN)
- Control Definition — Define risk controls and link to failure modes
- Control Specification — Document control mechanism, acceptance criteria, and verification method
- Test Case Creation — Create verification test cases for each control
- Evidence Execution — Execute tests and link results to risk controls
- Report Review — Generate Risk Control Effectiveness Report and address gaps
- Approval — Safety assessment approved before design freeze or PPAP submission
The report updates automatically as controls, test cases, and risk ratings change, providing continuous visibility into safety readiness.
