Hands-On: Integrated Safety Plan - Standards & Compliance

Safety Plan Content (ISO 26262 Part 2)

Pythonsafety_plan_generator.py

#!/usr/bin/env python3
# Safety Plan skeleton generator for ISO 26262 project
import json

safety_plan = {
    "project": "Electronic Power Steering ECU — SW Safety Plan",
    "version": "1.3",
    "asil": "ASIL C",
    "scope": {
        "item": "EPS SW Component v3.2",
        "ecu": "EPS ECU (MCU: Infineon AURIX TC397)",
        "asil_level": "ASIL C (decomposed to ASIL A(C) + ASIL B(C))",
    },
    "lifecycle_phases": [
        {"phase": "HARA",             "start": "2025-10-01", "end": "2025-11-15", "status": "Complete"},
        {"phase": "Safety Concept",   "start": "2025-11-16", "end": "2025-12-15", "status": "Complete"},
        {"phase": "SW Requirements",  "start": "2025-12-16", "end": "2026-02-01", "status": "In Progress"},
        {"phase": "SW Architecture",  "start": "2026-01-15", "end": "2026-03-01", "status": "In Progress"},
        {"phase": "Implementation",   "start": "2026-03-01", "end": "2026-06-01", "status": "Planned"},
        {"phase": "Unit Testing",     "start": "2026-05-01", "end": "2026-07-01", "status": "Planned"},
        {"phase": "Integration Test", "start": "2026-07-01", "end": "2026-08-01", "status": "Planned"},
        {"phase": "FSA",              "start": "2026-08-01", "end": "2026-09-01", "status": "Planned"},
    ],
    "roles": {
        "Safety Manager":    "Dr. A. Weber — Independence Level I2",
        "Safety Analyst":    "B. Schmidt — responsible for FMEA, FTA",
        "Independent Assessor": "C. Müller (TÜV SÜD) — Independence Level I3",
        "SW Architect":      "D. Park",
        "Test Engineer":     "E. Tanaka",
    },
    "confirmation_measures": [
        "Confirmation Reviews at each phase gate (Safety Manager + Assessor)",
        "FSA at completion of all work products",
        "Safety Case sign-off before SOP gate",
    ]
}

print(json.dumps(safety_plan, indent=2))

HARA Workshop Exercise: EPS

Hazard	S	E	C	ASIL	Safety Goal
Unintended torque > 3 Nm at > 30 km/h highway	3	3	2	C	EPS shall not apply unintended torque > 3 Nm for > 500 ms during normal driving
Unintended torque > 3 Nm in parking manoeuvre	2	3	1	A	EPS unintended torque < 10 Nm at < 10 km/h (driver can correct)
Loss of steering assist at highway speed	3	3	1	B	EPS degradation shall be gradual; manual steering always achievable within 2 s
Torque assist oscillation > 0.5 Hz	2	3	2	B	EPS shall not generate steering oscillation > 0.2 Nm at > 1 Hz

💡 Safety Goal Wording

A Safety Goal must be: (1) function-observable and measurable — 'no unintended torque > 3 Nm' is measurable; 'safe operation' is not; (2) not solution-specific — 'no fault in the motor driver' is a solution, not a goal; (3) ASIL-rated — the ASIL from HARA attaches to the goal. Poor safety goal wording is the most common HARA finding in FSAs. Write goals in terms of vehicle behaviour observable from outside the ECU.

Safety Plan Management and Gate Reviews

Pythonsafety_issue_tracker.py

#!/usr/bin/env python3
# Safety issue tracker with ASIL impact classification
# Simulates JIRA safety issue workflow

safety_issues = [
    {
        "id": "SI-001",
        "title": "MC/DC coverage for Torque_Limiter module only 87% (target 100%)",
        "asil_impact": "ASIL C",
        "blocking_gate": "SIL Gate",
        "status": "Open",
        "safety_manager_approval_required": True,
        "owner": "Test Engineer",
        "due": "2026-06-30"
    },
    {
        "id": "SI-002",
        "title": "FFI analysis missing for DMA channel 3 (writes to ASIL B partition)",
        "asil_impact": "ASIL B",
        "blocking_gate": "Architecture Review",
        "status": "In Progress",
        "safety_manager_approval_required": True,
        "owner": "SW Architect",
        "due": "2026-03-15"
    },
]

print("Open Safety Issues (Safety Manager approval required):")
for issue in safety_issues:
    if issue["status"] != "Closed":
        print(f"  [{issue['id']}] {issue['title']}")
        print(f"    ASIL: {issue['asil_impact']} | Gate: {issue['blocking_gate']}")
        print(f"    Status: {issue['status']} | Due: {issue['due']}")
        print()

Safety Case Structure using GSN

Goal Structuring Notation (GSN) — Safety Case Sketch

  G1: EPS Item achieves functional safety per ISO 26262 ASIL C
  │
  ├── S1: Argue over complete ISO 26262 lifecycle evidence
  │
  ├── G2: HARA complete; Safety Goals allocated to system
  │   └── Evidence: HARA Report v3.2 [HARA-001]
  │
  ├── G3: Safety Requirements specified and traceable
  │   └── Evidence: SW Safety Requirements Spec v2.1 [SRS-001]
  │
  ├── G4: Implementation meets ASIL C coding requirements
  │   ├── Evidence: MISRA C Report — 0 mandatory violations [SA-001]
  │   ├── Evidence: Code Review Records (100% reviewed) [CR-001..CR-047]
  │   └── Evidence: MC/DC Coverage 100% for safety-critical modules [TC-001]
  │
  ├── G5: Testing demonstrates safety requirements are met
  │   ├── Evidence: Unit Test Report (all tests passed) [UT-001]
  │   ├── Evidence: Integration Test Report [IT-001]
  │   └── Evidence: Safety Validation Report [VAL-001]
  │
  └── G6: Independent assessment confirms compliance
      └── Evidence: FSA Report — 0 open Major findings [FSA-001]

Summary

The Safety Plan is the binding commitment document for all safety activities on a project — it defines what will be done, who will do it, when, and what evidence will result. The HARA workshop is the highest-leverage safety engineering activity: poorly written safety goals (unmeasurable, solution-specific) cause cascading rework in requirements, design, and testing. The Safety Case using GSN makes the compliance argument explicit and auditable — every claim must link to evidence, and every open evidence item is a gap that blocks SOP.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.