Skip to main content

​
Overview

Risk Control (riskControl) is a work item type used to track all mitigation actions across FMEA, FHA, and hazard analysis documents. Each risk control:
  • Links to one or more failure modes, failure conditions, or hazards via the mitigates relationship
  • Has a classification (Design, Protective, or Information) indicating its risk reduction strategy
  • Tracks implementation status through the lifecycle
  • May reference associated requirements and verification test cases
Risk controls appear as primary items in the Risk Control Plan risksheet and as task rows in DFMEA/SFMEA mitigations columns.

​
Custom Fields

Field NameTypeDefaultDescription
riskControlTypeMulti-select Enum(none)ISO 14971 risk control hierarchy. Multi-select allows a single control to serve multiple strategies. Values: inherent-safety-design (design out the hazard), protective-measure (add protection), information-for-safety (procedural/labeling). Preferred order: design > protective > information.
implementationStatusEnum(see application)Lifecycle state of the control. Typical values: Not Started, In Progress, Implemented, Verified. Tracks whether the control has been designed, built, and validated.
The complete set of implementationStatus enum values and any additional custom fields should be verified in your Aerospace Safety Solution instance via Tracker → Custom Fields → riskControl.

​
Risk Control Plan Risksheet

The Risk Control Plan is a specialized risksheet where risk controls are the primary work items (not mitigation tasks within another analysis).

​
Structure

AspectDetails
Risk TyperiskControl (primary item type)
ColumnsTitle, Type (riskControlType), Linked Risk Records (failure modes via mitigates role)
HierarchySingle level — no multi-level nesting
PurposeCentralized inventory of all mitigation measures across the project
Linked RecordsDisplays failure modes, hazards, or failure conditions linked via mitigates relationship

​
Example Risk Control Entry

  • Title: Redundant Sensor Architecture
  • riskControlType: inherent-safety-design
  • implementationStatus: Implemented
  • Mitigates: FM-1: Sensor Loss (SFMEA) → HI-5: Loss of Attitude Data (FHA)

​
Risk Control References Across Risksheets

Risk controls appear in multiple analysis contexts:

​
DFMEA Mitigation Columns

In Design FMEA (DFMEA), the Mitigations column group shows:
ColumnContent
RC IDUnique identifier of the linked risk control
TitleRisk control name
StatusImplementation status (Not Started, In Progress, Implemented, Verified)
RequirementsDesign requirements linked to this control (traversed via work item back-links)
VerificationTest cases verifying the control (traversed through linked requirements)
Example flow: Risk Control → back-linked to desReq → back-linked to testCase

​
SFMEA Mitigation Tasks

System FMEA similarly includes mitigation task rows linked to failure modes, showing the same risk control properties and verification chain.

​
FHA/PSSA Safety Requirements

In Functional Hazard Assessment (FHA) and Preliminary System Safety Assessment (PSSA), safety requirements allocate from failure conditions. Risk controls support these allocated requirements by providing concrete mitigation implementation.

​
Relationships and Traceability

diagram Key Link Roles:
Link RoleDirectionMeaning
mitigatesRisk Control → Failure Mode/Condition/HazardThis control reduces the risk of that failure
allocatesToSafety Requirement → Failure ConditionRequirement derived from FHA failure condition
(implicit)Risk Control → Design RequirementControl implementation is specified in design req
verifiedByDesign Requirement → Test CaseTest validates that design requirement is met

​
Implementation Workflow

​
1. Risk Identification

During SFMEA/DFMEA analysis, failure modes and their severity/occurrence/detection are identified. High RPN values trigger the need for risk controls.

​
2. Control Design

A risk control is created and classified:
  • Inherent-Safety-Design (preferred): Modify design to eliminate the failure mode entirely
  • Protective-Measure: Add redundancy, monitoring, or fail-safe mechanisms
  • Information-for-Safety: Provide warnings, operational procedures, or labeling

​
3. Allocation to Requirements

The risk control is allocated to one or more design requirements that implement the mitigation strategy.

​
4. Verification

Test cases are linked to the design requirements, ensuring the control is validated.

​
5. Implementation Tracking

The implementationStatus field tracks progress: Not Started → In Progress → Implemented → Verified.

​
Usage in Aerospace Standards

​
ARP 4761 (Safety Assessment)

Risk controls mitigate failure conditions identified in FHA. Each failure condition’s allocated safety requirement should reference the risk control that prevents the condition.

​
ARP 4754A (System Development Assurance)

Risk controls implemented as design requirements inherit the DAL (Design Assurance Level) from the failure condition. All associated activities (design, verification, documentation) must meet the DAL.

​
DO-178C / DO-254 (Software & Hardware Assurance)

Risk controls appear in compliance matrices. Each control’s verification method (test, analysis, inspection, demonstration, review) and test level (unit, integration, system, acceptance) must satisfy the DAL.

​
MIL-STD-882E (Hazard Analysis)

Risk controls are the primary mitigation measures tracked in the Hazard Tracking risksheet. Residual risk (post-mitigation) is assessed after controls are implemented.

​
Multi-Select Risk Control Type

Because riskControlType is multi-select, a single risk control can serve multiple risk reduction strategies: 
Example: Sensor Redundancy Control
  riskControlType: [inherent-safety-design, protective-measure]
    - inherent: Redundant sensor architecture eliminates single-point failure
    - protective: Voting logic detects and masks sensor disagreement
List the primary risk control strategy first, followed by secondary strategies. Prefer inherent safety design whenever possible per ISO 14971.

​
Verification in Application

The following should be confirmed in your Aerospace Safety Solution instance:
  • Available implementationStatus enum values
  • Linked work item types and back-link traversal (requirements and test cases)
  • Risk control plan risksheet column configuration
  • Multi-select behavior of riskControlType (verify multiple values can be assigned simultaneously)
  • Any custom fields beyond riskControlType and implementationStatus

​
See Also

Code: modules/RiskTemplates/RiskControlPlanTemplate/attachments/risksheet.json (0.67) · modules/RiskTemplates/DFMEATemplate/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.63) · .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.63) · .polarion/tracker/fields/workitem-type-enum.xml (0.60) · 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.55) · .polarion/pages/spaces/_default/Data Model/page.xml (0.55) · modules/RiskTemplates/PSSATemplate/attachments/risksheet.json (0.55) · .polarion/tracker/fields/riskRecord-custom-fields.xml (0.54) · modules/RiskTemplates/HazardTrackingTemplate/attachments/risksheet.json (0.51)