| Role | Responsibility | ISO 26262 Reference |
|---|---|---|
| Safety Manager | Overall safety lifecycle management; safety plan owner; assessment coordination | Part 2 Clause 5 |
| System Safety Engineer | HARA, safety goals, FSC, TSRs; system-level safety analyses | Part 3, Part 4 |
| Hardware Safety Engineer | FMEA, FTA, DFA for hardware; SPFM/LFM/PMHF calculation | Part 5, Part 9 |
| Software Safety Engineer | SSRs, software safety analysis, review of architecture and code | Part 6, Part 9 |
| Functional Safety Assessor | Independent assessment of safety case; not part of development team | Part 2 Clause 6 |
| Safety Culture Champion | Promotes safety mindset; escalates safety concerns; training | Part 2 Clause 5 |
Safety Roles and Responsibilities
Independence Requirements by ASIL
| Activity | QM | ASIL-A | ASIL-B | ASIL-C | ASIL-D |
|---|---|---|---|---|---|
| Design review | — | I1 | I1 | I1 | I2 |
| Safety analysis (FMEA/FTA) | — | — | I1 | I1 | I2 |
| Software unit testing | — | — | I1 | I1 | I2 |
| Software integration testing | — | — | — | I1 | I2 |
| Functional safety assessment | — | — | — | I2 | I3 |
| HW-SW integration test | — | — | — | I1 | I2 |
Independence Levels
I1: Different person (not the developer)
I2: Different team / organisational unit
I3: Different company (external assessor)
Safety Plan Structure
Markdownsafety_plan_outline.md
# Safety Plan — [Project Name] v1.0
## 1. Scope and Purpose
- Item under development: [e.g., Electronic Power Steering ECU]
- ASIL level(s): [e.g., ASIL-D for steering torque path]
- ISO 26262 edition: 2018 (second edition)
- Applicable parts: 2, 3, 4, 5, 6, 8, 9
## 2. Safety Manager and Contacts
- Safety Manager: [Name, Role]
- Functional Safety Assessor (external): [Company, contact]
## 3. Work Products and Schedule
| Work Product | Responsible | Due Date | Review By |
|---------------------------|--------------|------------|-----------------|
| Item Definition | Sys Eng | 2024-Q1 | Safety Manager |
| HARA Report | Safety Eng | 2024-Q1 | External (I2) |
| Safety Goals | Safety Eng | 2024-Q1 | Safety Manager |
| TSRs | Sys Eng | 2024-Q2 | Safety Eng (I1) |
| HW FMEA | HW Eng | 2024-Q3 | HW Safety (I1) |
| SW Safety Requirements | SW Safety | 2024-Q2 | Safety Eng (I1) |
| Unit Test Reports | SW Dev | 2024-Q4 | SW Safety (I1) |
| Safety Case | Safety Mgr | 2025-Q1 | External (I3) |
## 4. Confirmation Measures
- Design reviews: per Part 2 Clause 6.4.6
- Functional safety audits: per Part 2 Clause 6.4.8
- Functional safety assessment: per Part 2 Clause 6.4.9
## 5. Tools and Tool Qualification
- [List all tools; identify TI class; plan qualification evidence]
## 6. Configuration Management
- Version control: [Git + Polarion or DOORS for requirements]
- Baseline strategy: [define baseline points]
## 7. Safety Culture and Training
- Safety training: [mandatory for all engineers on project]
- Escalation path: [Safety concern → Safety Manager → Programme Director]Safety Culture: Practical Behaviours
| Behaviour | Anti-Pattern | Best Practice |
|---|---|---|
| Raising safety concerns | 'We can't raise that — it will delay the project' | Stop-and-fix culture; any team member can raise a safety concern without repercussion |
| Requirements traceability | 'The requirement is obvious; we don't need to document it' | Every safety requirement has a unique ID, rationale, and bidirectional trace |
| Change management | 'It's a small change; we don't need a safety impact assessment' | Every change to safety-relevant elements requires a safety impact assessment |
| Testing attitude | 'We tested enough; the rest is edge cases' | Systematic coverage targets (MC/DC) driven by ASIL; gaps must be justified |
| Document quality | 'We'll write the safety case at the end' | Concurrent documentation; safety case assembled throughout development |
Summary
ISO 26262 places significant emphasis on organisational safety culture because systematic failures — the dominant failure mode in modern complex software — are fundamentally caused by human and process errors. The independence requirements ensure that the person reviewing a design is not the same person who created it, preventing confirmation bias. ASIL-D requires I3 independence for the functional safety assessment: an external company with no involvement in the development must assess the safety case. This is not optional — it is a certification requirement that determines whether the vehicle can be type-approved in many markets.
🔬 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.