Iso 26262 Safety Expert

ISO 26262 consists of 12 parts covering the complete safety lifecycle:

• Part 1: Vocabulary
• Part 2: Management of functional safety
• Part 3: Concept phase (HARA, Safety Goals, Functional Safety Concept)
• Part 4: Product development at the system level (Technical Safety Concept, System Design)
• Part 5: Product development at the hardware level
• Part 6: Product development at the software level
• Part 7: Production and operation
• Part 8: Supporting processes
• Part 9: ASIL-oriented and safety-oriented analyses (DFA, FMEA, FMEDA)
• Part 10: Guidelines
• Part 11: Application of ISO 26262 to semiconductors
• Part 12: Application of ISO 26262 to motorcycles

2. ASIL (Automotive Safety Integrity Level)

ASIL represents the risk classification based on:

• S (Severity): S0 (no injuries) to S3 (life-threatening/fatal injuries)
• E (Exposure): E0 to E4 (probability of operational situation)
• C (Controllability): C0 to C3 (ability to avoid harm through driver control)

ASIL Determination Table:

ASIL Levels (increasing rigor):

• QM: Quality Management only (no ISO 26262 safety requirements)
• ASIL A: Lowest safety integrity level
• ASIL B: Medium-low safety integrity level
• ASIL C: Medium-high safety integrity level
• ASIL D: Highest safety integrity level

3. Key Safety Lifecycle Phases

Phase 1: Concept Phase (ISO 26262-3)

1. Item Definition: Define system boundaries, interfaces, and dependencies
2. HARA (Hazard Analysis and Risk Assessment):
   • Identify hazards (malfunction of the item)
   • Define hazardous events (hazard + operational situation)
   • Assess risk (S, E, C) for each hazardous event
   • Determine ASIL
3. Safety Goals: Derive top-level safety requirements from HARA
4. Functional Safety Concept: Define high-level safety mechanisms

Phase 2: System Level (ISO 26262-4)

1. Technical Safety Concept: Refine functional safety concept with technical details
2. Functional Safety Requirements (FSR): Detailed system-level requirements
3. System Design: Architecture, interfaces, and allocation to HW/SW
4. Safety Analysis: FMEA, DFA (Dependent Failure Analysis)
5. Verification: Ensure requirements are correctly implemented

Phase 3: Hardware Level (ISO 26262-5)

1. Hardware Safety Requirements: Derived from FSRs
2. Hardware Design: Circuit design, component selection
3. Hardware Safety Analysis: Hardware FMEA, FMEDA, DFA
4. Safety Metrics Evaluation: SPFM, LFM, PMHF
5. Hardware Testing: Component and integration testing

Phase 4: Software Level (ISO 26262-6)

1. Software Safety Requirements: Derived from FSRs
2. Software Architectural Design: Module structure, interfaces
3. Software Unit Design and Implementation: Coding with appropriate methods
4. Software Testing: Unit, integration, and safety requirements testing
5. Software Safety Analysis: Software FMEA, DFA

Phase 5: Verification and Validation (ISO 26262-4, 5, 6)

1. Verification: Reviews, analyses, testing at each level
2. Validation: Ensure system meets safety goals in target environment
3. Functional Safety Assessment: Independent evaluation

4. Safety Metrics (ISO 26262-5 Clause 8 & 9)

SPFM (Single-Point Fault Metric)

Measures effectiveness of safety mechanisms for single-point faults:

Formula: SPFM = (ΣλS,SPF + ΣλS,RF) / (ΣλS,SPF + ΣλS,RF + ΣλSPF + ΣλRF)

Targets:

• ASIL B: ≥ 90%
• ASIL C: ≥ 97%
• ASIL D: ≥ 99%

LFM (Latent Fault Metric)

Measures effectiveness of safety mechanisms for latent multi-point faults:

Formula: LFM = ΣλS,MPF,latent / (ΣλS,MPF,latent + ΣλMPF,latent)

Targets:

• ASIL B: ≥ 60%
• ASIL C: ≥ 80%
• ASIL D: ≥ 90%

PMHF (Probabilistic Metric for Random Hardware Failures)

Violation of safety goal due to random hardware failures:

Targets:

• ASIL B: ≤ 100 FIT (Failures In Time, per 10⁹ hours)
• ASIL C: ≤ 100 FIT
• ASIL D: ≤ 10 FIT

5. Fault Tolerance Time Interval (FTTI)

FTTI: Time span from fault occurrence to potentially hazardous event EOTI (Emergency Operation Tolerance Interval): Time for emergency operation

Typical Values:

• ASIL D (critical safety functions): 10-100ms
• ASIL B/C (moderate safety functions): 100-1000ms

FTTI must be determined based on:

• Hazard severity and dynamics
• Driver reaction time
• Physical system response time

6. Safety Mechanisms

Categories:

1. Detection: Identify faults (plausibility checks, range checks, CRC, alive counters)
2. Control: Prevent faults from causing failures (redundancy, diversity, voting)
3. Mitigation: Reduce consequences (graceful degradation, safe state transitions)

Examples:

• Dual sensors with cross-check (detection + control)
• Watchdog timers (detection)
• Lock-step CPUs (detection + control)
• Fail-safe shutdown paths (mitigation)
• CAN message monitoring (detection)

7. Safety Concept Strategies

3-Layer Defense Strategy (Recommended Approach)

Layer 1: Fault Prevention (Robust Design)

• Design for fault avoidance
• Derating components
• EMC protection
• Thermal management

Layer 2: Fault Detection & Reaction (Diagnostics)

• Real-time monitoring
• Comprehensive diagnostics
• Fast fault detection (within FTTI)
• Error handling logic

Layer 3: Safe State Transition (Controlled Degradation)

• Multiple safe states (DM1, DM2, etc.)
• Graceful degradation
• Driver warning
• Fail-operational or fail-safe design

8. Safety Argument Structure

A complete safety argument must demonstrate:

1. Completeness: All hazards identified and addressed
2. Sufficiency: Safety measures are adequate for ASIL level
3. Effectiveness: Evidence shows measures work as intended
4. Independence: Verification is independent of development
5. Traceability: Clear links from hazards → safety goals → FSRs → design → verification → evidence

Typical Argument Pattern:

Safety Goal X shall be achieved
├─ Safety Measure 1 prevents/detects/mitigates hazard
│  ├─ Design implements measure correctly [Evidence: Design Spec]
│  ├─ Implementation verified [Evidence: Code Review, Unit Test]
│  ├─ Integration tested [Evidence: Integration Test Report]
│  └─ Effectiveness validated [Evidence: Vehicle Test, Analysis]
├─ Safety Measure 2 provides redundancy
│  └─ [Similar evidence structure]
└─ Safety Metrics achieved [Evidence: FMEDA, PMHF Calculation]

9. Verification Methods (ISO 26262-4 Table 6)

(++ = highly recommended, + = recommended, o = optional)

10. Common Degradation Modes (Safe States)

Example Degradation Mode Definitions:

Workflow Guidance

Task 1: Conducting HARA

Step-by-Step Process:

1. Prepare Item Definition

   • Define system boundaries, functions, interfaces
   • Identify operational modes and environmental conditions

2. Identify Hazards

   • For each function, ask: "What malfunctions are possible?"
   • Examples: loss of function, unintended function, excessive function, delayed function
   • Use systematic approach (brainstorming, past experience, checklists)

3. Define Operational Situations

   • Different driving scenarios: highway, urban, parking, etc.
   • Vehicle states: speed ranges, weather conditions
   • Driver actions and expectations

4. Create Hazardous Events

   • Combine: Hazard + Operational Situation = Hazardous Event
   • Example: "Sudden loss of steering assist while cornering at high speed"

5. Assess Risk (S, E, C)

   • S: Based on potential injuries (S0-S3)
   • E: Based on frequency of operational situation (E0-E4)
   • C: Based on driver's ability to control (C0-C3)

6. Determine ASIL

   • Use ASIL determination table
   • Select highest ASIL if multiple scenarios exist

7. Derive Safety Goals

   • One safety goal per hazard (may address multiple ASILs)
   • Format: "[Function] shall be prevented" or "[Condition] shall be maintained"
   • Example: "Unintended steering shall be prevented"

Output: HARA table with Hazards, Hazardous Events, S/E/C ratings, ASIL, and Safety Goals

Reference: See resources/HARA_TEMPLATE.md for detailed template

Task 2: Developing Functional Safety Requirements (FSR)

Step-by-Step Process:

1. Start with Safety Goals

   • Each safety goal needs FSRs to achieve it

2. Define FSR Categories

   • Failure Handling (FH): Detect and respond to faults
   • Data Protection (DP): Ensure signal integrity
   • Safety Constraints (SC): Design constraints (SPFM, LFM, PMHF)

3. Specify FSR Details

   • ID: Unique identifier (e.g., FSR_FH_001)
   • Description: What shall be done
   • ASIL: Inherited from safety goal
   • FTTI: Fault tolerance time
   • Allocation: HW, SW, or System
   • Safe State: Which degradation mode (DM1, DM2, etc.)
   • Acceptance Criteria: Measurable success criteria

4. Ensure Completeness

   • Cover all failure modes (sensors, actuators, communication, controller, logic)
   • Include both systematic and random faults
   • Address all phases of operation (startup, running, shutdown)

5. Link to Safety Goals

   • Create traceability matrix: FSR → Safety Goal → Hazard

Output: FSR table with all requirements specified

Task 3: Building Safety Arguments

Step-by-Step Process:

1. Structure the Argument

   • Top level: Safety Goal is achieved
   • Second level: Safety Measures that contribute to goal
   • Third level: Evidence that measures are effective

2. For Each Safety Measure:

   • Describe the measure (what it does, how it's implemented)
   • Explain effectiveness (why it prevents/detects/mitigates the hazard)
   • Provide verification results (evidence from work products)
   • Reference ISO 26262 compliance (which clauses, tables, methods)

3. Use 3-Layer Defense Pattern

   • Layer 1 (Prevention): Robust design, derating, EMC
   • Layer 2 (Detection): Diagnostics, monitoring, plausibility checks
   • Layer 3 (Reaction): Safe state transition, degradation

4. Provide Evidence Trail

   • Requirements specification [Work Product ID]
   • Design specification [Work Product ID]
   • Implementation verification [Work Product ID]
   • Safety analysis (FMEA/FMEDA/DFA) [Work Product ID]
   • Testing results [Work Product ID]
   • Validation results [Work Product ID]

5. Address Gaps Proactively

   • If evidence is missing, acknowledge and plan to provide
   • If residual risks exist, explain mitigation or acceptance rationale

Output: Safety argument document with complete traceability

Reference: See resources/SAFETY_ARGUMENT_TEMPLATE.md for detailed template

Task 4: Calculating Safety Metrics

SPFM Calculation Process:

1. Collect hardware FMEDA data (failure rates by component)
2. Classify each failure mode:
   • Safe faults (λS): Do not violate safety goal
   • Single-point faults (λSPF): Directly violate safety goal, no detection
   • Residual faults (λRF): Single-point faults not covered by safety mechanism
   • Detected single-point faults (λS,SPF): Detected by safety mechanism
   • Latent faults (λMPF,latent): Multi-point faults not detected in time
3. Apply SPFM formula
4. Verify against ASIL target

PMHF Calculation Process:

1. Identify fault combinations that lead to safety goal violation
2. Calculate failure rates for each path
3. Consider detection coverage and FTTI
4. Sum all contributions
5. Verify against ASIL target (10 or 100 FIT)

Reference: See resources/METRICS_CALCULATION_GUIDE.md for examples

Task 5: Preparing for Confirmation Review

Checklist:

1. Completeness Check

   • All work products exist and are reviewed
   • Traceability established (HARA → SG → FSR → Design → Test → Evidence)
   • All ASILs appropriately managed

2. Requirements Check

   • Item definition complete
   • HARA covers all operational scenarios
   • Safety goals correctly derived
   • FSRs complete and allocated

3. Design Check

   • Technical safety concept defined
   • Safety mechanisms implemented
   • Hardware and software designs comply with ASIL methods

4. Analysis Check

   • FMEA/FMEDA performed
   • DFA performed (independence verified)
   • Safety metrics calculated and meet targets
   • Residual risks assessed

5. Verification Check

   • All requirements verified (reviews, testing, analysis)
   • Verification methods appropriate for ASIL level
   • Test coverage adequate

6. Validation Check

   • System validated in target environment
   • Safety goals confirmed achieved
   • Acceptance criteria met

7. Documentation Check

   • Safety plan complete
   • Safety case documented
   • Configuration management in place
   • Change management applied

Reference: See resources/CONFIRMATION_REVIEW_CHECKLIST.md for detailed checklist

Best Practices

1. Start with Clear Item Definition

• Define boundaries clearly
• Document all interfaces and dependencies
• Consider system-of-systems interactions

2. Be Systematic in HARA

• Use structured hazard identification methods
• Consider all operational scenarios
• Document rationale for S, E, C ratings

3. Design for Safety from the Start

• Don't add safety as an afterthought
• Use proven design patterns (redundancy, diversity, monitoring)
• Plan for safe states and degradation

4. Maintain Traceability

• Use requirements management tools
• Create traceability matrices
• Keep documentation synchronized with design

5. Verify Early and Often

• Review requirements before design
• Analyze design before implementation
• Test at every level (unit, integration, system, vehicle)

6. Document Rationale

• Explain design decisions
• Justify ASIL ratings
• Document assumptions and constraints

7. Plan for Independence

• Ensure verification is independent of development
• Use independent safety assessors
• Maintain objectivity in reviews

8. Manage Changes Rigorously

• Impact analysis for all changes
• Regression analysis
• Update safety arguments and evidence

Example: EPS (Electric Power Steering) System

This Skill can reference the existing EPS safety documents in your project:

• Safety Concept: /Safety concept.md
• Safety Arguments: /safety_goal_arguments.md
• HARA Results: Safety Goals SG1-SG5 with ASIL B, D ratings
• Degradation Modes: DM1-DM6 defined

Key Safety Goals for EPS:

1. SG1: Sudden loss of assist shall be prevented (ASIL B)
2. SG2: Unintended steering shall be prevented (ASIL D)
3. SG3: Unintended wheel motion shall be prevented (ASIL B)
4. SG4: Lock steering shall be prevented (ASIL D)
5. SG5: Loss of ADAS function shall be prevented (QM)

Reference the project files when working on EPS-specific tasks.

Additional Resources

For more detailed guidance on specific topics, see:

• resources/HARA_TEMPLATE.md - Step-by-step HARA template
• resources/SAFETY_ARGUMENT_TEMPLATE.md - Safety argument structure and examples
• resources/FSR_TEMPLATE.md - FSR specification template
• resources/VERIFICATION_CHECKLIST.md - Comprehensive verification checklist
• resources/ISO_26262_QUICK_REFERENCE.md - Quick reference for ISO 26262 clauses and tables

When NOT to Use This Skill

• For non-automotive safety standards (use IEC 61508 or other relevant standards)
• For cybersecurity (use ISO/SAE 21434 instead)
• For SOTIF (Safety of the Intended Functionality) - use ISO/PAS 21448
• For general quality management (use IATF 16949)

Summary

This Skill provides expert-level guidance on ISO 26262 functional safety for automotive systems. Use it whenever you need to:

• Navigate the safety lifecycle
• Apply ISO 26262 methods and techniques
• Create safety documentation
• Build convincing safety arguments
• Ensure compliance with the standard

Always maintain a systematic, traceable, and evidence-based approach to functional safety.