TestAuto2 — Automotive Safety Solution uses risk control type classification to guide engineers toward optimal mitigation strategies, ensure compliance with ISO 26262 and AIAG-VDA FMEA standards, and track the effectiveness of risk reduction measures across the V-Model lifecycle.
Why Risk Control Types Matter
Risk control types serve three critical purposes in safety-critical development:
-
Safety Hierarchy Enforcement: ISO 26262 requires organizations to prioritize inherent safety (designing out hazards) over protective measures (detecting and mitigating hazards) over informational controls (warnings). Explicit classification ensures teams follow this hierarchy.
-
Risk Rating Impact: In FMEA workflows, Prevention controls reduce Occurrence ratings while Detection controls reduce Detection ratings. Misclassifying a control type leads to incorrect Action Priority calculations.
-
Verification Strategy: Different control types require different verification approaches. Design controls need design verification tests, protective measures need fault injection testing, and detection controls need diagnostic coverage analysis.
Not all risk controls provide the same level of safety assurance. A warning label (Information control) does not provide the same risk reduction as a fail-safe redundant architecture (Design control). ISO 26262 explicitly requires justification when relying on lower-tier controls for high-ASIL hazards.
ISO 26262 Safety Control Hierarchy
ISO 26262 Part 3 defines a three-tier hierarchy for hazard control measures, prioritized by effectiveness and reliability:
Inherent Safety by Design
Inherent Safety controls eliminate the hazard source through architectural choices. This is the gold standard because it doesn’t rely on active detection, correct timing, or human intervention.
Examples in AEB System:
- Dual independent sensor channels (eliminates single-point-of-failure for obstacle detection)
- Fail-operational power architecture (ensures AEB remains active during electrical faults)
- Non-volatile storage of safety-critical calibration (prevents loss on power cycle)
Why it’s preferred: If the hazard cannot physically occur due to the design, no detection, diagnosis, or human action is needed. This is the most reliable form of risk control.
Protective Measures
Protective Measures detect hazardous conditions and activate countermeasures to prevent harm. These controls assume the hazard can occur but mitigate its consequences before it reaches the driver or other road users.
Examples in AEB System:
- Sensor data plausibility check (detects corrupted radar data and switches to camera-only mode)
- Watchdog timer for ECU processing subsystem (detects stuck firmware and triggers safe reset)
- CAN bus timeout monitoring (detects lost communication and transitions to degraded mode)
Why it’s second-tier: Protective measures rely on correct implementation of detection logic, sufficient diagnostic coverage, and timely response. They are effective but introduce complexity and potential failure modes in the safety mechanism itself.
Information for Safety controls provide warnings, alerts, training, or procedures that enable operators (drivers, technicians, assemblers) to avoid hazards through awareness and correct behavior.
Examples in AEB System:
- Dashboard warning when AEB is degraded or disabled
- Maintenance manual procedure for sensor alignment verification
- Training for assembly workers on connector insertion force requirements
Why it’s lowest-tier: Information controls assume the operator receives the information, understands it, and takes correct action in time. Human factors research shows high variability in response, making this the least reliable control type. ISO 26262 requires strong justification when using Information controls for ASIL C or D hazards.
FMEA Risk Control Categories: Prevention vs Detection
AIAG-VDA FMEA methodology uses a different control type taxonomy focused on when the control acts in the failure mode lifecycle:
| Control Type | Definition | Effect on FMEA Ratings | Example in AEB System |
|---|
| Prevention | Prevents the failure mode or root cause from occurring | Reduces Occurrence rating | Design rule: “All ECU power pins must have reverse polarity protection diodes” |
| Detection | Detects the failure mode after it occurs but before it causes harm | Reduces Detection rating | End-of-line functional test that verifies radar detection range meets specification |
Prevention Controls
Prevention controls address the root cause of failure modes. They reduce the likelihood that the failure will happen in the first place.
Design FMEA Prevention Examples:
- Component derating (selecting capacitors with 2× voltage margin reduces likelihood of overvoltage failure)
- Error-correcting code (ECC) in RAM (prevents single-bit errors from corrupting data)
- Conformal coating on PCB (prevents solder joint corrosion in harsh environments)
Process FMEA Prevention Examples:
- Poka-yoke connector design (asymmetric connector prevents insertion in wrong orientation)
- Automated torque wrenches (prevent undertightening or overtightening of fasteners)
- Vision system for component presence verification (prevents missing parts)
Key Insight: Prevention controls justify lower Occurrence ratings in FMEA analysis. If you claim Occurrence = 3 (remote likelihood), you must cite specific prevention controls that make frequent occurrence implausible.
Detection Controls
Detection controls identify defects or failures after they occur but ideally before they reach the customer or cause harm.
Design FMEA Detection Examples:
- Built-in self-test (BIST) circuits that detect RAM failures at power-up
- CAN bus error frames that signal corrupted messages
- Diagnostic Trouble Code (DTC) logging for out-of-range sensor readings
Process FMEA Detection Examples:
- X-ray inspection for solder joint quality
- Electrical test for continuity and resistance of assembled harnesses
- Leak test for sealed housing assemblies
Key Insight: Detection controls justify lower Detection ratings (remember: in FMEA, Detection 1 = almost certain to detect, Detection 10 = cannot detect). Strong detection controls move high-severity failure modes out of High Action Priority even if Occurrence remains elevated.
Optimal FMEA design includes both Prevention (reduce likelihood) and Detection (catch failures before harm). Relying solely on detection leaves the failure mode occurring frequently but caught by inspection—expensive and inefficient. Relying solely on prevention without detection means latent defects escape to the field unnoticed.
How TestAuto2 Classifies Risk Controls
TestAuto2 uses the riskControlType enumeration field on Risk Control work items to categorize each mitigation measure. This field appears in:
- Risksheet configurations for HAZID, DFMEA, PFMEA, and Risk Control Plan documents
- PowerSheet configurations showing traceability from requirements to controls
- Risk Control Effectiveness Report dashboard that groups controls by type and validates coverage
The enumeration supports five values to accommodate both ISO 26262 and FMEA methodologies:
ISO 26262 Safety Hierarchy
| Classification | Tier |
|---|
inherent-safety-design | Tier 1 |
protective-measure | Tier 2 |
information-for-safety | Tier 3 |
| Classification | Effect |
|---|
| Prevention | Reduces Occurrence rating |
| Detection | Reduces Detection rating |
When to Use Each Classification
| Classification | Use When | FMEA Impact | ISO 26262 Tier |
|---|
inherent-safety-design | The control eliminates the hazard source through architecture or design choices | May reduce Occurrence to 1-2 if failure mode becomes physically impossible | Tier 1 (highest) |
protective-measure | The control detects hazardous conditions and activates countermeasures (safe states, fault handling) | Typically reduces Severity (if degraded mode is less severe) or Occurrence (if mechanism prevents propagation) | Tier 2 |
information-for-safety | The control provides warnings, procedures, or training requiring human action | No direct FMEA impact unless user action prevents failure mode occurrence | Tier 3 (lowest) |
Prevention | The control prevents the failure mode root cause in design or manufacturing process | Justifies lower Occurrence rating in FMEA | N/A (FMEA-specific) |
Detection | The control detects defects during manufacturing, testing, or runtime diagnostics | Justifies lower Detection rating in FMEA | N/A (FMEA-specific) |
Some controls serve multiple roles. For example, a watchdog timer is a protective-measure (ISO 26262 Tier 2) and a Detection control (FMEA context) because it detects stuck firmware. When in doubt, prioritize the ISO 26262 hierarchy classification for safety goals and use Prevention/Detection for FMEA-specific analysis.
Risk Control Type and Verification Evidence
Different control types require different verification strategies to prove effectiveness:
| Control Type | Required Verification Evidence | Example Test Approach |
|---|
| Design (Inherent Safety) | Design Verification Test Case proving the hazard cannot occur | Fault injection test demonstrating failover to redundant sensor |
| Protective Measure | Fault injection test proving detection and safe state transition within timing constraints | Inject CAN bus timeout, verify transition to safe mode within 100ms |
| Information for Safety | Human factors validation proving warning is perceivable and actionable | Usability test with representative drivers in simulated failure scenario |
| Prevention | Design review confirming implementation + process verification (if manufacturing control) | Design review of ECC implementation + RAM self-test validation |
| Detection | Validation test proving control detects intended failure modes with measured coverage | X-ray inspection capability study showing 99.5% defect detection rate |
Control Type in FMEA Action Priority Calculation
In Design FMEA workflows using AIAG-VDA Action Priority methodology, control types influence which ratings can change between pre-mitigation and post-mitigation assessment:
- Prevention controls justify lowering the Occurrence rating
- Detection controls justify lowering the Detection rating
- Severity ratings NEVER change between initial and residual risk (severity is inherent to the effect of failure)
A common FMEA mistake is claiming that adding protective measures reduces Severity. Severity is determined by the worst-case consequence of the failure mode, which doesn’t change. If a stuck throttle can cause loss of vehicle control (Severity 9), adding a watchdog doesn’t make the consequence less severe—it reduces the Occurrence (makes it less likely) or improves Detection (catches it in testing).
Failure Mode: Radar sensor signal corruption
Initial Assessment:
- Severity: 8 (delayed braking, potential collision)
- Occurrence: 6 (occasional)
- Detection: 7 (low likelihood of detection before release)
- Action Priority: H (High)
Prevention Control Added: Triple-modular redundancy with voting (Design control)
Post-Mitigation Assessment:
- Severity: 8 (unchanged—effect is still delayed braking)
- Occurrence: 3 (remote—requires all three channels to fail)
- Detection: 7 (unchanged—still relying on system test)
- Action Priority: M (Medium)
Detection Control Added: Automated sensor plausibility check in test (Detection control)
Final Assessment:
- Severity: 8 (unchanged)
- Occurrence: 3 (unchanged from Prevention control)
- Detection: 3 (high likelihood—plausibility failures caught in every test)
- Action Priority: L (Low)
See Also
Understanding Risk Control Concepts:
Practical Application:
Reference:
