Skip to main content

​
Why Controls Are First-Class Work Items

In simpler tools, mitigations are free-text fields on a risk record. This creates a fundamental problem: the same physical design measure (say, a watchdog timer) might be documented three different times across an SFMEA, a DFMEA, and a security threat assessment — with no way to know they refer to the same control, no shared status, and no common traceability to a requirement or test case. The Aerospace Safety Solution models riskControl as a dedicated work item type. A single control can be linked from multiple risk records across different analysis frameworks. Its implementationStatus field tracks progress from planned through verified in one place, visible everywhere it is referenced.
A single riskControl item can appear in an SFMEA, a DFMEA, a PSSA, and a security threat assessment simultaneously. Changes to its status or linked requirements propagate to every view that references it.

​
Classification: Two Complementary Axes

Controls are classified along two axes that work together rather than replacing each other. The controlType field assigns a single category using an engineering lens:
  • Design — inherent safety built into the architecture (e.g., redundancy, fail-safe states)
  • Protective — devices or measures added to detect or limit harm (e.g., circuit breakers, monitors)
  • Information — procedures, warnings, and training that inform operators
The riskControlType field applies the ISO 14971 hierarchy and supports multi-select, meaning a single control can serve multiple reduction strategies simultaneously:
  • inherent-safety-design
  • protective-measure
  • information-for-safety
The ISO 14971 hierarchy is deliberately ordered: inherent safety design is preferred over protective measures, which are preferred over information-based controls. A control classified as inherent-safety-design alone signals stronger risk reduction than one relying on operator training. diagram

​
The Mitigation Chain

The value of first-class controls becomes clear when you trace the full mitigation chain that the Aerospace Safety Solution maintains: 
Failure Mode / Hazard / Security Threat
        ↓  mitigates (link role)
    riskControl
        ↓  back-links
    Safety Requirement (sysReq / desReq)
        ↓  verifies
    Test Case
This chain is surfaced directly in FMEA risksheets. The Mitigations column group in both System FMEA and Design FMEA shows the linked riskControl items alongside their implementationStatus, the requirements they link to, and the test cases verifying those requirements — all derived through Velocity traversal of the live traceability graph. The same chain applies in PSSA, Hazard Tracking (MIL-STD-882E), and security threat assessment — each framework surfaces controls through the same mitigates link role, ensuring consistent traceability regardless of analysis type.

​
RPN Before and After Controls

For FMEA analyses, the Aerospace Safety Solution calculates Risk Priority Number (RPN) twice:
  • commonRpn — pre-mitigation: Severity × Occurrence × Detection
  • commonRpnNew — post-mitigation: recalculated after controls are applied
Color-coded thresholds make residual risk immediately visible: Low (≤10, green), Medium (11–30, yellow), High (>30, red). The difference between commonRpn and commonRpnNew provides the quantitative evidence of control effectiveness — the same evidence captured in the Risk Control Effectiveness report. For MIL-STD-882E Hazard Tracking, an equivalent pattern applies through the Hazard Risk Index (HRI): initial assessment uses the MIL-STD-882E Table II matrix, and residual risk is separately tracked after safety controls are applied.

​
The Risk Control Plan as a Cross-Cutting View

While individual analysis documents (SFMEA, DFMEA, PSSA) show controls in context, the Risk Control Plan risksheet provides a project-wide view. It is the only analysis template where riskControl items appear as the primary row entity rather than as supporting tasks. The Risk Control Plan shows three columns: Title, riskControlType classification, and Linked Risk Records (the failure modes each control mitigates). This flat, project-wide list answers a compliance question that per-document views cannot: have all identified risks been assigned at least one control?
Controls are not owned by a single analysis document. A riskControl created while working on an SFMEA can — and should — be reused across DFMEA, PSSA, and security threat analyses when the same physical measure addresses risks in multiple contexts. The Risk Control Plan is the definitive inventory.

​
Implementation Status Tracking

Each riskControl carries an implementationStatus field with four states that track progress from intention to evidence. This status is visible wherever the control appears — in FMEA mitigations columns, in the Risk Control Plan, and in PSSA safety requirement views — giving the full project team a consistent picture of which mitigations are verified and which remain open.
The exact labels and transition rules for implementationStatus states should be confirmed in the live Polarion project configuration, as workflow details may vary between deployments.

​
Relationship to Other Concepts

The control hierarchy sits at the intersection of several other architectural concepts. Controls are allocated to failure modes (see Failure Condition and Failure Mode Hierarchy) and linked to safety requirements that carry DAL classifications (see Design Assurance Level (DAL) Classification). The traceability chain that runs through controls is the same chain described in V-Model Traceability Chain — controls are the bridge between the risk analysis domain and the requirements/verification domain.
Code: modules/RiskTemplates/RiskControlPlanTemplate/attachments/risksheet.json (0.64) · .polarion/tracker/fields/designRequirement-subType-enum.xml, environmentalCategory-enum.xml, fta-gateType-enum.xml, cca-analysisType-enum.xml, controlType-enum.xml, riskControlType-enum.xml, verificationMethod-enum.xml, testLevel-enum.xml (0.61) · .polarion/tracker/fields/testCase-custom-fields.xml, desReq-custom-fields.xml, processStep-custom-fields.xml, characteristic-custom-fields.xml, systemElement-custom-fields.xml, commonCauseEvent-custom-fields.xml, riskControl-custom-fields.xml, task-custom-fields.xml, custom-fields.xml (0.61) · modules/RiskTemplates/DFMEATemplate/attachments/risksheet.json (0.57) · modules/RiskTemplates/PSSATemplate/attachments/risksheet.json (0.56) · datasets/sol-aero-ui-walkthrough/summary.md, navigation.md, dashboards/home-dashboard.md, dashboards/role-dashboards.md, dashboards/standards-compliance.md, risksheet-views/risksheet-views.md, work-item-types/data-model.md (0.53) · modules/RiskTemplates/HazardTrackingTemplate/attachments/risksheet.json (0.50) · .polarion/tracker/fields/workitem-type-enum.xml (0.50) · modules/Risks/COMPLIANCE-001/module.xml, modules/Risks/MIL-STD-882E-HTS-001/module.xml, modules/Risks/SEC-THREAT-001/module.xml, modules/Risks/SFMEA-SUB-001/module.xml, modules/Risks/SFMEA-SUB-002/module.xml, modules/Risks/SFMEA-SUB-003/module.xml (0.50) · modules/RiskTemplates/FTATemplate/attachments/risksheet.json (0.50)