Overview
Risk Control entities document how risks will be reduced or eliminated. Each control has a type (inherent design, protective measure, or informational), links to the risks it addresses, and tracking of effectiveness through pre- and post-mitigation impact. Risk Controls support both ISO 26262 HARA workflows (safety-critical controls) and AIAG-VDA FMEA workflows (design and process controls).
Core Properties
| Name | Type | Default | Description |
|---|
ID | String | Auto | Unique work item identifier (e.g., RC-0042). Auto-assigned by Polarion based on project prefix. |
title | String | — | Control name or description (e.g., “Add watchdog timer for ECU timeout detection”). Should clearly identify what the control does. |
description | String | Empty | Detailed explanation of how the control mitigates the risk, including technical implementation details, architecture changes, or procedural steps. |
status | Enum | Open | Workflow state of the risk control: Open, In Development, Implemented, Validated, Closed. Reflects progress through implementation lifecycle. |
assignee | Link | — | User/team responsible for implementing the control. Typically a design engineer or safety engineer depending on control type. |
dueDate | Date | — | Target completion date for implementing the risk control. Used in project scheduling and milestone tracking. |
priority | Enum | Medium | Control urgency level: Low, Medium, High, Critical. High-ASIL controls or prevention measures typically prioritized higher. |
Classification Properties
| Name | Type | Default | Description |
|---|
riskControlType | Enum | — | Categorizes the control strategy according to ISO 26262 hierarchy: inherent-safety-design, protective-measure, information-for-safety, prevention, or detection. See Risk Control Types for detailed definitions. |
controlType | Enum | — | Dual-purpose classification for FMEA contexts: design (design-level mitigation), protective (runtime detection/mitigation), or information (operator warnings/procedures). |
rationale | String | — | Engineering justification for choosing this control strategy. Example: “Redundant sensor reading chosen over single-point detection due to ASIL D requirement for object detection.” |
controlType is a legacy field supporting FMEA workflows. riskControlType is the modern ISO 26262-aligned enumeration. TestAuto2 uses both for compatibility; prefer riskControlType in new workflows.
Effectiveness and Mitigation Properties
| Name | Type | Default | Description |
|---|
effectiveness | Enum | — | Expected risk reduction: high (ASIL-critical, designed-in redundancy), medium (protective mechanisms, good diagnostic coverage), low (informational, warnings). |
estimatedReductionPercent | Integer (0-100) | — | Quantified estimate of risk reduction this control provides (e.g., 85% reduction in failure mode occurrence). Used in post-mitigation rating calculations. |
preImplementationRisk | Enum | — | Risk level before control implementation: High, Medium, Low, or numeric equivalent. Populated from linked Failure Mode or Hazard pre-mitigation rating. |
postImplementationRisk | Enum | — | Residual risk after control implementation. Must be acceptable per project safety requirements and standards (typically Medium or lower for ASIL B+). |
Relationship Properties
| Name | Type | Default | Description |
|---|
mitigates | Link (→) | — | Links to Failure Mode or Hazard or Harm work items this control addresses. Supports traceability from risk to mitigation. Multiple links allowed. |
mitigatedBy | Link (←) | — | Reverse link: populated when Failure Modes, Hazards, or Harms reference this control. Enables bidirectional traceability in RTM. |
relatedControls | Link | — | Links to other Risk Control work items that work in concert (e.g., primary redundant sensor + secondary watchdog timer). Useful for documenting control strategy decomposition. |
verifiedBy | Link | — | Links to Verification Test Case or Validation Test Case work items that prove the control is effective. Supports V&V traceability. |
implementedIn | Link | — | Links to Design Requirement or System Element implementing the control. Traces control to architectural decisions. |
Implementation Tracking Properties
| Name | Type | Default | Description |
|---|
implementationMethod | String | — | How the control will be implemented: e.g., “Hardware redundancy (dual sensors)”, “Firmware watchdog routine”, “Operator training and checklist”, “Design rule enforcement”. |
implementationOwner | Link | — | Individual or team responsible for execution. May differ from assignee (who is accountable). |
targetImplementationDate | Date | — | Expected completion of control implementation in design or manufacturing. |
actualImplementationDate | Date | — | Date control was actually implemented and integrated. Recorded post-implementation for historical tracking. |
implementationNotes | String | — | Technical notes, change requests, or decisions made during implementation that differ from planned approach. |
Validation and Evidence Properties
| Name | Type | Default | Description |
|---|
validationMethod | String | — | How control effectiveness will be validated: e.g., “Component-level FMEA failure mode injection test”, “System-level sensor fusion redundancy check”, “SOTIF scenario simulation”, “Control plan verification with audit”. |
validationStatus | Enum | Not Started | Progress through validation: Not Started, In Progress, Complete, Accepted. Drives Safety Readiness Scorecard completion. |
validationEvidenceLink | Link | — | Reference to external evidence document, test report, or data file proving control effectiveness. Links to wiki pages or external URLs. |
diagnosticCoverage | Integer (0-100) | — | For protective measures: percentage of failure modes in the element that this control can diagnose. Used in ISO 26262 diagnostic coverage calculations. |
Risk Assessment Context
| Name | Type | Default | Description |
|---|
targetAsil | Enum | — | ASIL level this control must support: QM (Quality Management), A, B, C, or D. Guides validation rigor and control robustness requirements per ISO 26262-5/6. |
safetyGoalReference | Link | — | Links to Safety Goal this control contributes to achieving. Provides ISO 26262 safety integrity chain traceability. |
standards | Multi-select | — | Applicable standards this control addresses: ISO 26262, ISO 14971, AIAG-VDA FMEA, IATF 16949, ISO 21448 SOTIF. Documents which methodology framework governs the control. |
Example: Watchdog Timer Control for ECU Timeout
{
"ID": "RC-0042",
"title": "Implement watchdog timer for ECU software timeout detection",
"description": "Add independent watchdog timer in Safety Co-Processor that monitors ECU main processor heartbeat. If heartbeat missing for >100ms, triggers safe shutdown sequence (brake signal off, AEB disabled). Meets ASIL B requirement for runtime fault detection.",
"status": "In Development",
"assignee": "Sarah Chen (Safety Co-Processor Design)",
"priority": "High",
"riskControlType": "protective-measure",
"effectiveness": "high",
"estimatedReductionPercent": 92,
"preImplementationRisk": "High",
"postImplementationRisk": "Medium",
"mitigates": ["FM-0156"],
"verifiedBy": ["VTC-0089"],
"implementedIn": ["SREQ-0024"],
"implementationMethod": "Firmware watchdog routine in Safety Co-Processor with <100ms response time",
"targetImplementationDate": "2026-04-15",
"validationMethod": "Component-level FMEA failure injection test: ECU heartbeat suppressed, watchdog response verified",
"validationStatus": "Not Started",
"targetAsil": "B",
"safetyGoalReference": ["SG-03"],
"standards": ["ISO 26262", "AIAG-VDA FMEA"]
}
Hierarchy and Relationships in Risksheet Views
Risk Controls appear in multiple risksheet configurations, each emphasizing different traceability angles:
HARA Risksheet
Risk Controls linked from Safety Goals in the HARA workflow, showing how each safety goal (derived from hazards) will be controlled:
DFMEA/SFMEA Risksheet
Risk Controls linked from Failure Modes showing mitigation strategy:
- Failure Mode FM-0156: ECU software hangs — no AEB activation
- Pre-mitigation RPN: 720 (S=9, O=8, D=10)
- mitigated by:
- Post-mitigation RPN: 72 (S=9, O=4, D=2) — 90% reduction
Control Plan Risksheet
Risk Controls organized by Process Steps and linked to Characteristics showing manufacturing controls:
- Process Step PS-08: Sensor Unit Assembly
- Control RC-0180: 100% vision inspection of solder joints
- Type: Detection control
- Prevents: Failure Mode FM-0089 (Cold solder joint)
Risk Controls should not be created until the corresponding risk (Failure Mode, Hazard, Harm) has been analyzed and rated. Pre-emptive control definition without clear risk linkage creates maintenance burden and compliance gaps.
Standards Compliance Integration
ISO 26262 (Functional Safety)
Risk Controls in HARA workflows must achieve target ASIL through hierarchical control strategy (inherent safety > protective measure > information). Pre- and post-mitigation assessment demonstrates ASIL requirement fulfillment.
AIAG-VDA FMEA
Risk Controls in FMEA workflows categorized as Prevention (reduces Occurrence) or Detection (reduces Detection rating). Action Priority calculation updated post-control to show residual risk acceptability.
IATF 16949 / APQP
Manufacturing-level controls (Process FMEA) linked to Control Plan Items and Characteristics. SC (Special Characteristic) and CC (Critical Characteristic) designations drive control rigor and documentation requirements.
Configuration in PowerSheet and Risksheet
Risk Controls are rendered in traceability sheets via relationship columns:
- Whole RTM Sheet: “Mitigating Controls” column showing risk controls linked to failure modes
- Risk Control Plan Sheet: Three-level hierarchy (Process Step → Characteristic → Control Method) with control type, effectiveness, and validation status
- Safety Goal Traceability: “Achieving Controls” column linking each safety goal to its risk controls
See Also
