ISO 26262 Organizational Process

Framework for Engineering Service

Providers
A Comprehensive Implementation Guide for Safety-Critical Automotive Systems
Development

Executive Summary
This document defines the complete organizational and operational framework for
implementing ISO 26262 functional safety processes within an automotive engineering
services provider organization. This is not theoretical guidance—these are the concrete
processes, responsibilities, quality gates, and verification mechanisms that will be used
operationally to deliver safety-critical systems to OEM clients with uncompromising rigor.
The framework is structured around four core operational pillars:
1. Organizational Management & Safety Culture - Governance, competence, and the
safety-first decision-making culture
2. Safety Lifecycle Process Management - End-to-end safety activities from concept
through decommissioning
3. Technical Safety Engineering - HARA, safety concepts, requirements allocation,
and safety case development
4. Supporting Processes & Quality Assurance - Configuration management, change
control, tool qualification, and compliance verification

This document reflects 25+ years of automotive functional safety expertise and is designed
for immediate operational implementation.

Part 1: Organizational Management & Safety Culture

1.1 Functional Safety Management System (FSMS)
1.1.1 Safety Policy & Commitment
The organization shall establish and maintain a documented Functional Safety
Management System (FSMS) that:
Policy Statement:

Declares commitment to achieving acceptable residual risk in all safety-related

systems delivered to OEM clients
Commits to compliance with ISO 26262:2018 (Ed. 2) across all applicable parts and
ASILs (A through D)
Establishes safety as non-negotiable—competitive pressures, schedules, and cost
constraints shall never override safety decisions
 Applies uniformly to all projects regardless of client, timeline, or perceived
complexity
Integrates functional safety across all organizational functions (engineering, project
management, quality, procurement)
Documented Evidence:

Executive-level safety commitment signed by company leadership

Communication of safety policy to all employees upon hire and annually
Board-level oversight with quarterly safety metrics review
Safety performance included in leadership KPIs

1.1.2 Functional Safety Manager & Organizational Structure

Functional Safety Manager Role:
Reports directly to company leadership (CTO, VP Engineering, or equivalent)
Has authority to override project timelines, budgets, and decisions on safety grounds
Maintains independence from project delivery pressures
Responsible for:
Approval of all Safety Plans and Safety Cases
Confirmation measures review and sign-off
Audit coordination and non-conformance resolution
Competence assessment and training program oversight
ASIL D project oversight and decision gates
Organizational Structure Imperative:

Functional Safety function is SEPARATE from project delivery organization

Functional Safety team reports to leadership, not to program managers or delivery
teams
Creates healthy tension: delivery teams push for efficiency, Safety team ensures rigor
This separation is not overhead—it is foundational to avoiding systematic risk
Minimum Organizational Requirements by Company Size:

Company Size Functional Safety Team Composition

Small (1-50 1 Functional Safety Manager; may share with
engineers) quality function
Medium (51-200 1 FSM + 1-2 Safety Engineers; dedicated team for
engineers) ASIL C/D
Large (200+ 1 FSM (director level) + lead safety engineers per
engineers) domain + quality integration
1.1.3 Competence Management
Functional Safety Competence Framework:
All personnel performing safety-related activities must demonstrate competence in:
Knowledge Competencies:

ISO 26262 (all applicable parts) - demonstrated via formal assessment

ASIL principles and their implications
Hazard analysis methodologies (HARA, FMEA, FTA, HazOp)
Safety case development and argumentation
Confirmation measures and their rationale
Applicable automotive standards (IATF 16949, ASPICE, 26262-8 tool qualification)
Domain-specific knowledge (E/E architecture, hardware reliability, embedded
software)
Experience Competencies:
Minimum 3 years in automotive functional safety (or equivalent domain-specific
safety experience)
Demonstrated successful delivery of at least one ASIL B project
For ASIL C/D lead roles: minimum 5+ years with 2+ ASIL C/D projects
Functional Safety Manager: minimum 10+ years with proven organizational impact

Competence Assessment Process:

1. Initial Assessment: Written examination covering ISO 26262 fundamentals (80%
pass required)
2. Project Assignment: Mentoring on first project; sign-off by FSM after 6 months
3. Continuous Development: Annual competence review; identified gaps trigger
training
4. Role-Specific Certification: For ASIL D leads, external certification (TÜV, Dekra, or
equivalent) recommended
5. Knowledge Maintenance: Minimum 16 hours/year of functional safety training
(conferences, workshops, internal seminars)
Competence Register:

Maintained by HR with Functional Safety Manager input

Updated upon each role change, training completion, or project assignment
Reviewed during non-conformance incidents to identify training needs
No safety-critical role assignment without documented competence

1.2 Safety Culture & Decision-Making Framework

1.2.1 Safety-First Decision Framework
The organization shall establish explicit criteria for situations where safety conflicts with
schedule, cost, or technical convenience:
Decision Hierarchy (Non-Negotiable):
 1. Safety Acceptance Criteria - Does this meet ISO 26262 requirements AND achieves
acceptable residual risk?
If NO → Decision is STOPPED until criteria met
No executive override, no customer pressure can override this gate
2. Technical Feasibility - Can this be implemented given resource constraints?
If NO → Scope/requirements adjusted; schedule/budget adjusted to match (not
the reverse)
3. Schedule & Cost - Planned within available budget and timeline
Adjusted based on safety and technical requirements, never the driver
Operational Example:
A client pushes to eliminate a redundancy because "other suppliers don't use it." The safety
analysis shows this redundancy is necessary to achieve the required ASIL.

Decision: Redundancy is RETAINED

Communication: Written explanation of ASIL requirement and residual risk without
it
Alternative: Client informed they can reduce ASIL (and accept higher residual risk) if
they absorb contractual liability
Outcome: Clear trail showing safety decision was made on facts, not pressure

1.2.2 Safety Culture Mechanisms

Monthly Safety Forums:
All personnel involved in safety-related activities participate
Topics: near-misses, tool issues, process improvements, lessons learned, risk
discussions
Outcome: One safety improvement action per month implemented organization-
wide
Safety Escalation Process:

Any engineer can escalate safety concerns directly to Functional Safety Manager
(bypass normal chain of command)
Anonymous reporting option available
No retaliation policy explicitly documented and reinforced
All escalations logged and tracked to closure
Safety Incident & Non-Conformance Tracking:
Root cause analysis for all safety-related defects
Systemic improvements to process (not just fixing individual issues)
Transparent reporting to all teams (what happened, why, what changed)

Part 2: Safety Lifecycle Process Management

2.1 Project Initialization & Safety Planning
2.1.1 Contract Review & Safety Requirements Definition
Upon contract award or project start:

1. Safety Requirements Extraction from client documents:

Client's safety goals and requirements
Applicable standards (ISO 26262, ISO 13849, SOTIF, cybersecurity)
Target ASIL(s) for delivered functions
OEM-specific mandatory processes or constraints
Functional safety budget (time/resources allocated)
Confirmation measure expectations
2. Feasibility Assessment (completed within first 2 weeks):
Can target ASIL be achieved with available resources?
Are client assumptions about complexity realistic?
Does proposed schedule allow adequate verification/validation?
Are tool and methodology constraints compatible with ASIL?
Decision Gate: Proceed only if feasibility confirmed; otherwise escalate
3. Safety Plan Development (ISO 26262-2, Section 7):
Item Definition: Clear scope of what constitutes the safety-critical system
ASIL Assignment: Documented ASIL(s) for each safety goal
Safety Lifecycle: Phases, activities, and responsible parties
Organization: Who does what, reporting structure
Resources: Budget, schedule, tools, personnel competence
Confirmation Strategy: Which confirmation measures will be used
Interface Agreements: With OEM, subsystem suppliers, integration partners
Change Management: How changes affecting safety are evaluated
Tool Qualification: What tools will be used and their qualification status
Safety Plan Sign-Off:
Approved by Functional Safety Manager BEFORE project execution begins
Acknowledged by Project Manager and Lead Engineers
Provided to client (transparency on our approach)
Baseline for tracking project safety compliance

2.1.2 Interface Agreements & Supplier Management

Safety-Critical Interfaces: Define clear responsibilities and information flow for:

OEM Integration Interfaces:

Item Definition: What is in scope, what is out (boundary conditions)
System assumptions: What assumptions about other systems we depend on?
Functional Safety Concept: Which safety functions are provided by whom?
Integration testing: Who provides what test vectors and fault injection scenarios?
Evidence handoff: What artifacts does OEM require for confirmation?
Subsystem Supplier Interfaces:

ASIL decomposition: What ASILs are required from suppliers?

Requirements traceability: Supplier requirements derived from our needs
Evidence standards: What verification/validation evidence suppliers must provide
 Failure modes: Supplier responsible for documenting how their failures affect our
system
Key Principle: No assumptions about external systems left implicit. Every assumption
documented and validated.

2.2 Concept Phase (ISO 26262-3)

2.2.1 Item Definition
Purpose: Establish the boundary and scope of the safety-critical system.
Output Document: Item Definition Report
Contents:

Functional Description: What does the system do? What functions are safety-
critical?
System Boundaries: Hardware and software included/excluded
Operational Environment: Vehicle platform, sensors, actuators, external systems
Lifecycle Assumptions: Expected operational life, maintenance intervals,
diagnostic capabilities
Interfaces: Electrical, mechanical, information interfaces to other systems
Safety Functions: Which specific vehicle-level safety functions are allocated to this
item?
Quality Gates:
Technical review: Engineering lead confirms functional description is accurate
Safety review: Functional Safety Manager confirms boundaries are clear and
assumptions documented
Client confirmation: OEM signs off that Item Definition matches contract scope

2.2.2 Hazard Analysis and Risk Assessment (HARA)

Methodology: Structured, systematic identification of hazards and assignment of ASIL.

HARA Process:
Step 1: Hazard Identification
Use systematic methods: architectural review, FMEA starting point, fault trees, design
review
Question: What malfunctions of this item could lead to hazardous events?
Generate candidate hazards (not yet filtered)

Step 2: Hazard Analysis - Severity Assessment

Severity (S): What is the worst-case injury/outcome if this malfunction occurs?
S3 (Severe): Serious injury or fatality
S2 (Moderate): Moderate injury with permanent effects
S1 (Light): Minor injury or no injury
S0 (No injury): Not a hazard
Step 3: Exposure Assessment
 Exposure (E): How frequently/likely is this malfunction to occur in real vehicle
operation?
E4 (Very High): Frequent occurrence
E3 (High): Reasonably expected
E2 (Medium): Possible but infrequent
E1 (Low): Rare occurrence
E0 (Impossible): Not feasible in vehicle operation
Step 4: Controllability Assessment

Controllability (C): If malfunction occurs, can driver mitigate or control

consequences?
C3 (Not Controllable): Driver cannot control or detect situation
C2 (Difficult to Control): Driver might recognize but mitigation is difficult
C1 (Controllable): Driver can detect and control situation
C0 (Always Controllable): Inherently safe due to vehicle design
Step 5: ASIL Determination
Use ISO 26262 ASIL determination table (severity × exposure × controllability)
ASIL D: S3 + E3/E4 + C2/C3 (highest criticality)
ASIL C: Various combinations of medium-high values
ASIL B: Lower combinations
ASIL A: Minimal criticality
QM: No ASIL assigned (quality management only)

Step 6: Safety Goals Definition

For each hazard with ASIL ≥ B: Define a safety goal that prevents/mitigates the
hazard
Safety goal inherits ASIL of the hazard
Safety goal is high-level: "System shall detect brake pressure loss within 100ms"
HARA Documentation Requirements:
 Se Ex Con
A
Haz Scenari ve po trol Ratio
SI Safety Goal
ard o rit su labi nale
L
y re lity
[Analy
Loss Vehicle System shall
sis
of [conditi AS detect within
justify
[Fun on], S3 E3 C3 IL [time] AND
ing
ction [fault D command
scores
] occurs] safe state
]
[Nex
t
... ... ... ... ... ... ...
haza
rd]

HARA Validation:
Technical review: Are hazards realistic and complete?
Safety review: Are ASIL assignments justified? Are assumptions about controllability
sound?
Completeness check: Did we consider multi-fault scenarios? Dependent failures?
Client review: OEM confirms HARA matches their vehicle-level analysis

Critical Principle: HARA is not an exercise to complete—it is your safety foundation.

Conservative assignments (higher ASIL when uncertain) are preferred to optimistic ones.

2.2.3 Functional Safety Concept

Purpose: Define at a high level how safety goals will be achieved.
Functional Safety Concept Document:
Component 1: Safety Functions

Describe each safety function: what it does, trigger conditions, response

Example: "Brake Pressure Loss Detection: When brake pressure drops below 80 kPa,
system signals driver via brake warning lamp within 50ms"
Component 2: Safety Mechanisms
For each safety goal, identify mechanisms that prevent/mitigate the hazard
Mechanisms can be:
Redundancy (hardware or software)
Diagnostic monitoring (detecting faults and commanding safe state)
Architectural features (isolation, safe defaults)
Procedural controls (maintenance, inspection)

Component 3: ASIL Allocation

 Assign ASILs to safety functions and mechanisms
Can decompose ASIL: ASIL D goal might use ASIL C redundant channels
Document assumptions about system interactions
Component 4: Safe State Definition

Explicitly define what constitutes a safe state for this system

Must remain safe until driver can take evasive action
Example: "Safe state = brake warning illuminated, brake force request set to zero,
system disabled"
Component 5: Failure Detection & Response
For each credible failure mode: is it detected? How quickly? What is the response?
Combines with hardware/software design to achieve required ASIL

Quality Gates:
Technical review: Do proposed safety mechanisms realistically achieve goals?
Safety review: Are ASIL allocations justified? Are decompositions valid?
Feasibility check: Can this be implemented and verified within project constraints?

2.3 Product Development Phase (ISO 26262-4, 5, 6)

2.3.1 System-Level Development
System Architecture Design:

Input: Functional Safety Concept (high-level safety requirements)

Output: Technical Safety Concept + System Architecture
Process:

1. Technical Safety Concept Development

Translate safety functions into technical requirements: "Brake pressure loss
detection" → "Brake pressure sensor input < 80 kPa sampled at 10ms intervals
for 3 consecutive samples triggers warning lamp"
Specify timing requirements, accuracy requirements, failure modes to be
handled
Define interfaces between safety functions and non-safety functions
Document assumptions about external systems (CAN bus is available, sensor
provides valid signals, etc.)
2. System Architecture Design
Hardware architecture: Processors, memory, sensors, actuators,
communication buses
Software architecture: Functional components, their interfaces, data flow
Fault detection and handling: Which faults are detected? By what mechanism?
Response?
Timing and synchronization: How are safety-critical timing deadlines met?
Safety mechanisms: Redundancy, cross-checks, safe defaults
Safety Analysis at System Level:
Conduct System-Level FMEA (Failure Mode Effects Analysis):
For each component/interface: what faults can occur?
What is the system-level consequence of each fault?
Is the fault detected? By what mechanism?
Is the detection adequate for the ASIL?

Example System FMEA Entry:

Det
Com Effect Detection ecti A
Failure Mitigatio
pone on Mechani on SI
Mode n
nt Safety sm Tim L
e
Loss Pressure Trigger
Brake
of vs. A brake
Press Stuck low <
brake vehicle SI warning,
ure (reports 0 100
signal decelerat L disable
Senso kPa) ms
detect ion cross- D adaptive
r
ion check brake
Message Watchdog Declare
Loss
loss timeout A sensor
of
CAN (brake (no 200 SI fail, use
pressu
Bus pressure message ms L limp-
re
data not for C home
signal
received) 200ms) mode

Integration Planning:
Identify integration test scenarios that will verify:
Each safety function operates as designed
Faults are detected within required time
Safe state is achieved and maintained
No unintended interactions between functions

System-Level Verification Plan:

Define verification methods: analysis, review, simulation, hardware testing
Specify pass/fail criteria for each requirement
Link to integration test scenarios
2.3.2 Hardware Development (ISO 26262-5)
Hardware Safety Analysis (FMEDA):
FMEDA = Failure Modes, Effects, and Diagnostics Analysis
For each electronic component (microcontroller, sensor, FPGA, discrete transistor):

1. Identify Failure Modes:

Single-bit flip in memory
Stuck-at-1 or stuck-at-0 logic signal
Open or short circuit
Thermal runaway
Voltage regulation failure
Clock signal loss
2. Calculate Failure Rates:
Use industry data (Siemens SN 29500, IEC TR 62380) or manufacturer
datasheets
Account for operating temperature, stress levels
Derate based on safety margin (typically 20-50% derating)
Example: Microcontroller rated at 10,000 FITS (failures in 10^9 hours) at 70°C;
design operates at 50°C, apply derating factor 0.7 → effective FITS = 7,000
3. Classify Failures:
Safe: Failure cannot cause safety goal violation (e.g., sensor reports 0 when
open-circuit; detected by diagnostic)
Latent: Failure is not detected; could combine with other fault to cause hazard
Detected: Failure is detected and safe state commanded
Undetected Dangerous: Failure is not detected and could cause safety goal
violation
4. Diagnostic Coverage Assessment:
What percentage of failures is detected by onboard diagnostics?
Coverage = (Detected + Safe) / Total failures
Higher ASIL requires higher diagnostic coverage
ASIL D typically requires ≥ 90-99% DC
5. FMEDA Table Example:
 Fail Clas
Detection D ASIL
Compo Failure ure sific
Mechanis C Achieve
nent Mode Rat atio
m % d
e n
Single-bit ASIL D
Microc ECC (error-
flip in 500 Late 95 (with
ontroll correcting
data FITS nt % redunda
er code)
memory ncy)
Cross-
Brake
check vs.
Pressur Stuck 100 Dete 98
vehicle ASIL D
e high FITS cted %
deceleratio
Sensor
n
Watchdog
CAN 10
Output 50 Dete timer
Transc 0 ASIL C
stuck low FITS cted (message
eiver %
not sent)

Hardware Architecture Decisions (for ASIL C/D):

Redundancy: Dual-channel (monitoring + main), triple-modular, or others
Diagnostic coverage: Health monitoring, parity checks, CRC verification, cross-
validation
Component selection: Proven devices with automotive qualification, avoiding
new/unproven parts
Derating: Conservative margins on voltage, current, temperature to reduce failure
probability
Thermal management: Ensure components don't exceed temperature ratings under
worst-case conditions

Hardware Verification Methods:

1. Design Review: Peer review of schematics, PCB layout, thermal design
2. FMEDA Review: Technical review of failure analysis completeness and fault tree
adequacy
3. Environmental Testing: HALT (Highly Accelerated Life Testing) to identify weak
points
4. Production Validation: HASS (Highly Accelerated Stress Screening) on sample
production units
5. Functional Testing: Verification that safety functions operate across temperature,
voltage, aging conditions
2.3.3 Software Development (ISO 26262-6)
Software Safety Requirements Specification (SRS):
Input: Technical Safety Concept + System Architecture (software components)
Output: Detailed, traceable software safety requirements

SRS Structure:
1. Safety-Related Requirements
Functional: "System shall calculate brake pressure every 10ms"
Failure handling: "If brake pressure sensor reports invalid value, set pressure
to zero and trigger diagnostic"
Timing: "Brake warning lamp shall command within 50ms of pressure loss
detection"
Resource constraints: "System shall not use more than 80% of available
memory"
2. Traceability (Requirement ← Safety Goal ← Hazard)
Every safety requirement traces back to a safety goal
Every safety goal traces to a hazard in the HARA
Ensures completeness: no floating requirements; no unimplemented safety
goals
3. Requirement Format (MoSCoW + ASIL):
REQ-FS-001 [ASIL D]: System shall detect loss of brake pressure and
command brake warning lamp illumination within 100ms of pressure
falling below 80 kPa (sensor reading stable for 3 consecutive samples
at 10ms intervals).
Rationale: Hazard "Loss of brake pressure signal" (HARA-H05)
allocated to this system. Safety goal is to detect and warn driver.
Timing allows driver response time before brake fade becomes dangerous.
4. Acceptance Criteria (How will we know this is correct?)
Measurable, testable criteria
Not: "System shall be robust" (vague)
Yes: "System shall not exceed 100ms from sensor reading < 80 kPa to lamp on,
across 0°C to 80°C operating range and across ±10% supply voltage variation"
Software Architecture Design:

1. High-Level Design (HLD):

Software components and their responsibilities
Inter-component interfaces and data flow
Resource allocation (memory, CPU time)
Safe state initialization and recovery
2. Detailed Design (LLD):
Algorithm descriptions
State machines and their transitions
Error handling and exception paths
Memory layout and initialization sequences
3. Safety-Critical Design Features:
Fail-safe defaults: On startup, enter safe state; remain safe on any fault
 Redundancy: Critical calculations performed independently; results
compared
Watchdog timers: Detect if main task hangs or loops infinitely
Sanity checks: Cross-validate sensor readings against physical expectations
Diagnostic monitoring: Continuous self-test of safety functions
Software Implementation (Coding):

Coding Standards (Mandatory for ASIL B+):

MISRA C:2012 (or later) for C code
AUTOSAR Secure Onboard Communication (SecOC) if CAN-based
No dynamic memory allocation, recursion, or function pointers (ASIL D)
All inputs validated before use
No undefined behavior
Code Review Process:

1. Author completes code

2. Independent reviewer (different engineer) reviews against:
Design specification conformance
Coding standards compliance
Safety analysis coverage (is this hazard scenario handled?)
3. Defects logged and corrected
4. Re-review before approval
Software Verification (Unit & Module Level):
1. Unit Testing:
Test each function/module in isolation
Test cases cover:
Normal operation (expected inputs)
Boundary conditions (min, max values)
Error cases (invalid inputs, fault injection)
Code coverage target: ≥ 90% (ASIL C) or ≥ 95% (ASIL D)
2. Integration Testing:
Test interaction between software modules
Test timing constraints (are calculations done within deadline?)
Test fault injection (single-bit flips in memory, CAN message loss)
Verify safe state behavior
3. Software Verification Report:
Summary of test environment (compiler, tools, target hardware)
Test results (pass/fail for each requirement)
Code coverage data
Defect analysis (any critical defects found and fixed)
2.4 System Integration & Validation (ISO 26262-4)
2.4.1 Integration Testing Strategy
Objective: Verify that hardware and software work together to achieve safety goals.

Integration Test Plan:

1. Module Integration:
Bring up individual software modules on target hardware
Verify sensors/actuators respond to commands
Verify CAN communication
2. Subsystem Integration:
Integrate multiple functional modules
Test inter-module communication and timing
Verify diagnostic functions detect simulated faults
3. System Integration:
Full system operational on vehicle-representative hardware (or vehicle itself)
End-to-end functional testing: trigger hazard scenario, verify safety response
Thermal, vibration, EMI testing under vehicle operational conditions
Integration Test Cases:

Each test case includes:

Test ID: e.g., ITEST-FSC-01
Objective: What safety requirement is being verified?
Preconditions: System state before test
Test Steps: Actions taken (fault injected, sensor values changed, etc.)
Expected Result: What should happen (alarm, safe state, detection time, etc.)
Acceptance Criteria: Pass/fail based on quantitative measurements
Traceability: Links to safety requirements, hazards, safety goals
Example Integration Test:

ITEST-FSC-003: Brake Pressure Sensor Loss Detection & Warning

Objective: Verify system detects brake pressure sensor open circuit and
illuminates brake warning within ASIL D timing requirement.
Preconditions:

System powered and operating nominally

Vehicle at idle, brake pressure nominal (600 kPa)
Test Steps:
1. Disconnect brake pressure sensor (simulate open circuit)
2. Monitor system response

Expected Result:
Brake warning lamp illuminates within 100ms
No false sensor reading is used for control (verified via CAN logging)
System remains stable and doesn't command unintended brake action
Acceptance Criteria:
PASS if warning illuminates at [time measured in ms] within 100ms window
FAIL if warning illuminates > 100ms or does not illuminate
FAIL if any unintended brake action observed

Test Execution Date: ___ Pass: ___ Fail: ___

Test Log Reference: [link to data file]
Verification Engineer: ___ Date: ___

2.4.2 Validation Testing (Real Vehicle)

Objective: Demonstrate system meets safety goals in actual vehicle environment.
Validation Test Scenarios:
For ASIL C/D systems, include:

1. Normal operation: Verify system operates correctly under expected conditions

(temperature, supply voltage, sensor noise)
2. Degraded operation: System continues to operate with reduced performance (one
sensor failed, fuel low, etc.)
3. Safe shutdown: System gracefully shuts down when unrecoverable faults detected
4. Environmental extremes: Operation at thermal extremes (-40°C to +85°C), voltage
transients, EMI
5. Realistic hazard scenarios: Brake pressure loss, sensor faults, electrical faults—
system detects and responds within timing
Validation Evidence Collected:
Test logs (timestamp, sensor values, system responses)
Video recording (real-time system behavior, warning indicators)
Data analysis (statistical summary of response times, fault detection success rates)
Non-conformances identified and root-caused

Part 3: Technical Safety Engineering - Safety Case &

Confirmation
3.1 Safety Case Development
3.1.1 Safety Case Concept & Structure
What is a Safety Case?
A Safety Case is a documented, systematic argument supported by evidence that the system
achieves acceptable residual risk (meets safety goals with ASIL D confidence). It is your
proof to the OEM (and potentially regulators) that the system is safe.
Safety Case is NOT:

A marketing document
A compliance checklist
A risk register with risk items "closed"
 A collection of test reports
Safety Case IS:

A structured argument: "We made these safety decisions because we analyzed these
hazards and applied these methods"
Evidence-based: "We verified these safety requirements using [tests, analysis,
review]"
Traceable: Every claim in the argument ties back to evidence
Confidence-building: Independent reviewers can follow the logic and agree the
system is safe

3.1.2 Safety Case Argument Structure (Goal Structuring Notation - GSN)

ISO 26262 does not mandate a specific format, but Goal Structuring Notation (GSN)
provides a clear, visual framework.
Components of GSN:
1. Goal (Goal node): Top-level claim (e.g., "System is acceptably safe for brake pressure
monitoring")
2. Strategies (Strategy nodes): High-level approach to arguing safety
3. Sub-goals (Sub-goal nodes): Decomposition of the main goal
4. Evidence (Artifact/Evidence nodes): Data, test results, analysis reports
5. Context (Context nodes): Assumptions, definitions, scope

Example Safety Case Argument (Simplified):

GOAL: Brake Pressure Monitoring System is acceptably safe (ASIL D)
├─ STRATEGY: Argue via systematic development per ISO 26262

├─ SUBGOAL-1: Hazards are identified and ASIL appropriately assigned

│ ├─ Evidence: HARA report (shows loss of brake pressure signal, ASIL D assigned)
│ └─ Evidence: Client confirmation of HARA

├─ SUBGOAL-2: Safety goals are implemented in system design

│ ├─ SUBGOAL-2.1: Brake pressure loss is detected within required time
│ │ ├─ Evidence: Technical Safety Concept (detection method: cross-check sensor vs. decel)
│ │ ├─ Evidence: Hardware FMEDA (shows diagnostic coverage 98%)
│ │ ├─ Evidence: Integration test ITEST-FSC-003 (detection time < 100ms verified)
│ │ └─ Evidence: Validation test in real vehicle (10 test iterations, all pass)
││
│ └─ SUBGOAL-2.2: Driver is warned appropriately
│ ├─ Evidence: SWR-FS-001 (brake warning command within 100ms)
│ ├─ Evidence: Software design review (warning logic implementation)
│ ├─ Evidence: Unit tests (warning function tested with fault injection)
│ └─ Evidence: Integration test (warning illumination timing verified)

├─ SUBGOAL-3: Process used for development meets ISO 26262 requirements

│ ├─ Evidence: Safety Plan (approved by FSM, shows ISO 26262 compliance)
│ ├─ Evidence: Design reviews (peer review checklists, sign-offs)
│ ├─ Evidence: Competence records (all engineers have required certification)
│ └─ Evidence: Tool qualification (tools used meet ASIL requirements)
└─ SUBGOAL-4: Residual risk is acceptable
└─ Evidence: FMEA analysis shows no undetected failures lead to hazard
└─ Evidence: All safety goals achieved; no gaps identified

Safety Case Documentation: Compile all evidence references into a single document with
clear traceability. OEM and auditors can "walk the argument" from top-level claim through
sub-claims to evidence.

3.2 Confirmation Measures (ISO 26262-2, Section 10)

What are Confirmation Measures?
Confirmation measures are independent verification activities that demonstrate:

1. The system was developed using proper ISO 26262 processes

2. Safety requirements are implemented correctly
3. Residual risk is acceptable
4. No major safety gaps were missed
Confirmation Measures Required by ASIL:

AS Final Safety
Required Audits Confirmation Review
IL Assessment
Organization
A None (optional) Optional
responsibility
I0 (basic Organization
B Before production
independence) responsibility
I2 (project-level I2 independent
C Before production
independence) review
I3 (organizational During development + I3 external
D
independence) Before production organization

Independence Levels (I0 to I3):

I0: Person not directly involved in creation (e.g., QA team from same dept)
I2: Person independent from creation team but same organization
I3: External organization (TÜV, Dekra, Exida, or equivalent recognized body)

3.2.1 Confirmation Review Process

Confirmation Review = Independent evaluation that evidence supports safety case
Confirmation Review Conduct:
1. Review Planning (4-6 weeks before production):
Identify independent reviewer (I2 or I3 depending on ASIL)
Define scope: which components/functions will be reviewed?
 Provide reviewer with: Safety Plan, Safety Case, all supporting evidence
Establish review schedule and communication protocol
2. Evidence Review:
Does HARA identify all major hazards?
Are ASIL assignments justified?
Are safety goals implemented in design?
Is verification evidence adequate (tests, analysis)?
Are all requirements traced and verified?
Are risks identified during development resolved?
3. Gap Identification:
Missing evidence (e.g., test result not documented)
Weak arguments (e.g., safety goal claimed met, but evidence unclear)
Process deviations (e.g., code review not properly documented)
Technical concerns (e.g., failure mode identified in FMEA but not addressed in
design)
4. Clarification & Closure:
Organization addresses identified gaps
Provide missing evidence or revise design/process
Reviewer validates that gaps are closed
Sign-off: "This system appears to be developed per ISO 26262 and safety goals
are met"
Confirmation Review Output:

Confirmation Review Report detailing:

Scope of review
Review method and depth
Findings (areas of strength, areas of concern)
Resolutions to findings
Confirmation statement (system meets safety requirements)

Part 4: Supporting Processes & Quality Assurance

4.1 Configuration Management
Purpose: Ensure all work products are traceable, versioned, and reproducible.

4.1.1 Configuration Items (CIs) and Baselines

Safety-Critical Configuration Items (must be under strict control):

1. Documentation CIs:
Safety Plan
HARA Report
Functional Safety Concept
Technical Safety Concept
System/Hardware/Software Architecture Design
Safety Requirements Specifications
Safety Analysis Reports (FMEA, FMEDA, FTA)
Test Plans and Test Cases
Test Reports and Verification Evidence
Safety Case
 2. Hardware CIs:
Schematics (component-level detail)
PCB layout files
Component Bill of Materials (BOM)
Hardware verification/validation test procedures
3. Software CIs:
Source code (with design, safety requirement traceability)
Compiler configuration and version
Build scripts and build environment documentation
Software integration/build output (executable)
Unit test code and results
Deployment/installation procedures

4.1.2 Baseline Control

Three Formal Baselines:
1. Functional Baseline:
After HARA and Functional Safety Concept approved
Establishes safety requirements that must be met
Any change requires HARA re-assessment
2. Allocated Baseline:
After system/hardware/software architecture and requirements allocated
Establishes design that implements safety goals
Any change to design requires safety impact analysis
3. Product Baseline:
After verification and validation complete, before production
Final, tested, confirmed version
Any production change goes through formal change control

Baseline Control Process:

1. All CIs assigned unique version numbers (e.g., v1.0, v1.1, v2.0)
2. Only approved CIs are "released" into a baseline
3. Every CI includes release date, approver, and traceability ID
4. Historical versions retained for audit traceability (can trace back any decision)
Example Document Control Header:

SAFETY PLAN - Brake Pressure Monitor System

Document ID: BR-PLAN-001
Version: 2.3
Release Date: 2024-12-08
Approver: [FSM Signature]
Scope: System-level safety planning for ASIL D brake pressure loss detection
Change History:
v2.0 → v2.3: Updated resource schedule, added supplier communication protocol
(Reviewer initials) (Date)
v1.5 → v2.0: Incorporated HARA baseline updates, refined confirmation strategy
(Reviewer initials) (Date)
4.2 Change Management
Purpose: Evaluate safety impact of any change; prevent unintended safety degradation.

4.2.1 Change Request & Impact Assessment

Any change to safety-critical work products requires formal evaluation:
Change Evaluation Process:
1. Submitter completes Change Request Form:
What is changing? (component, requirement, test procedure, etc.)
Why? (bug fix, requirement clarification, performance improvement, etc.)
What is the scope of change? (affected systems, functional impact)
Requested timeline (when is this needed?)
2. Safety Impact Assessment (conducted by Functional Safety Engineer):
Could this change affect any safety goal?
Does this require re-analysis (HARA, FMEA, architecture)?
Do existing tests still verify the change? Do new tests needed?
Is ASIL still achievable with this change?
Decision: Approve (safe), Approve with conditions (additional testing), Reject
(safety risk)
3. Change Control Board (CCB) Review:
For major changes: project manager, architect, functional safety engineer, QA
review
Consensus decision: proceed or reject
If approved, assign responsibility and timeline
4. Implementation & Verification:
Change implemented and tested per impact assessment requirements
Verification results documented
Updated CI re-baselined

Example Change Control Scenario:

CHANGE REQUEST CR-1247:
Title: Increase brake pressure threshold from 80 kPa to 90 kPa
Rationale: New vehicle platform has slightly different brake system behavior;
testing shows false alarms at 80 kPa threshold.

Safety Impact Assessment:

Affects: HARA-H05 (Loss of brake pressure), ASIL D
Affects: Safety goal "Detect brake pressure loss within 100ms"
Question: Does 90 kPa threshold still detect real brake pressure loss?
Answer: Yes, real loss occurs below 50 kPa; 90 kPa is conservative margin
Question: Do existing tests verify this threshold?
Answer: Integration tests use 80 kPa; need to re-run with 90 kPa and
verify detection time still < 100ms
Decision: APPROVED with condition that integration tests ITEST-FSC-003
and ITEST-FSC-005 are re-run and pass.

Implementation:
 Software requirement SWR-FS-001 updated: threshold = 90 kPa (v1.2)
Code updated, unit tests re-run
Integration tests ITEST-FSC-003, ITEST-FSC-005 re-run: PASS
Safety Case section 2.1 updated to reflect new threshold
Change closed: 2024-12-08

4.3 Tool Qualification (ISO 26262-8)

Purpose: Ensure tools used in development do not introduce undetectable errors.

4.3.1 Tool Classification & Qualification Requirements

ISO 26262 Tool Classes:
Class 1: Tool does not directly generate safety-critical code/design
Examples: Document editors, project management tools, email
Qualification: None required

Class 2: Tool generates code/design but errors would be detected by other verification
Examples: Code generators where output is reviewed; compilers where generated
code is tested
Qualification: Tool Operational Qualification (TOQ) sufficient
Class 3: Tool generates safety-critical code/design; errors NOT detected downstream

Examples: Optimizing compiler (generated code not fully testable); code generator
with no review
Qualification: Tool Validation Plan (TVP) + Tool Operational Qualification (TOQ)
required

4.3.2 Tool Qualification Methods

Method 1: Tool Qualification by Evaluation of Development Process (TCR-1)
Applicable if tool vendor has rigorous development process documentation
Review vendor's process: design standards, testing, change control, documentation
Evidence: Tool development plan, design documentation, test results, change logs
Less expensive but requires trust in vendor
Method 2: Tool Validation (TCR-2)

Execute test cases covering all safety-relevant tool functions

Tests demonstrate tool correctly handles:
Normal inputs (generates correct code/output)
Boundary conditions (max file size, max memory, unusual input formats)
Error cases (invalid input, intentional faults)
Evidence: Test plan, test cases, test execution log, results
Method 3: Vendor Provided Qualification Evidence (TCR-3)
Tool vendor provides qualification package (analysis, tests, certification)
Suitable for commercial off-the-shelf (COTS) tools with strong automotive pedigree
Reduces cost; requires OEM acceptance
4.3.3 Tool Qualification Documentation
Tool Qualification Report (for each Class 2/3 tool):

ASI Clas
Ve
L sific Qualificatio
Tool rsi Status Expiry
Use atio n Method
on
d n
TOQ
GCC (compiler Ongoing
(GNU C 9.3 ASI Class verified QUALI (vendor
Compile .0 LC 2 through FIED support
r) system ed)
testing)
TOQ
Embedd
(generated
ed Expires
6.2 ASI Class code QUALI
Studio 2025-12-
0 LD 2 reviewed; FIED
(SEGGE 31
projects
R)
tested)
NOT
CANalyz SAFET
16. ASI Class
er None Y- N/A
0 LB 1
(Vector) CRITIC
AL
TVP
Lint (PC- (validation Expires
2.4 ASI Class QUALI
Lint tests for lint 2026-06-
.04 LC 3 FIED
Plus) rule 30
detection)

4.4 Documentation Management & Traceability

4.4.1 Traceability Matrix
Traceability Chain: Hazard → Safety Goal → Safety Requirement → Design Component →
Test Case
Traceability Matrix (simplified example):
 Verif
Ha Se Safe
Design Test icati
zar ve AS Safety ty
Componen Cas on
d rit IL Goal Req
t e Statu
ID y ID
s
Pressure
HA Detect sensor ITE
AS SWR
RA- brake input ST-
S3 IL -FS- PASS
H0 pressure handler; FSC-
D 001
5 loss threshold 003
logic
Command
HA CAN ITE
AS brake SWR
RA- message ST-
S3 IL warning -FS- PASS
H0 send FSC-
D within 002
5 routine 003
100ms
HA Cross-check ITE
AS Prevent SWR
RA- logic ST-
S3 IL false -FS- PASS
H0 (pressure FSC-
D alarm 003
5 vs. accel) 005

Traceability Value:
Completeness check: Are all hazards addressed? All safety goals implemented?
Impact analysis: Change in requirement → automatically see all tests affected
Audit trail: "Why was this test written?" → Trace back to hazard

4.4.2 Documentation Retention & Archival

Retention Policy:

All safety-critical documents retained for:

Duration of product in production: + 10 years minimum
Rationale: Supports warranty claims, recall investigations, post-incident analysis
Documents to Archive:

Safety Plan, HARA, Safety Concept

All analysis reports (FMEA, FMEDA, FTA)
Design specifications and architectural drawings
Source code (all versions)
Test plans and test results
Change control logs
Configuration management records
 Confirmation review report
Any non-conformance and corrective action records
Archive Format:

Digital format (PDF, XML) with audit trail (who accessed, when, for what purpose)
Backup media (multiple locations)
Encrypted for security; access controlled

Part 5: Quality Assurance & Process Auditing

5.1 Internal Audit Program
Purpose: Verify that all projects are following documented safety processes.

5.1.1 Audit Scope & Frequency

Annual Internal Audit Schedule:

1. Process Audit (Quarterly):

Audit one project phase per quarter (concept, development, validation,
production)
Verify documented process is being followed
Check: Safety Plan is approved; HARA is complete; design reviews are
conducted; tests are documented
Scope: 1-2 projects per quarter (rotating through active projects)
2. Technical Audit (Semi-Annual):
Deep-dive technical review of safety analysis and architecture decisions
Verify: HARA hazards are realistic; ASIL assignments justified; design
addresses all safety goals
Scope: 1 ASIL C or D project per audit cycle
3. Organizational Audit (Annual):
Review: Competence management, tool qualification, configuration
management, safety culture
Verify: Training records up-to-date; tools remain qualified; safety escalation
policy understood
Scope: Entire organization

5.1.2 Audit Checklist (Process Audit Example)

Project: [Name], Phase: [Concept/Development/Validation]
 Ye N Observati Requirem
Audit Item
s o on ent
Safety Plan approved before ISO 26262-
☐ ☐ [Date/Ref]
phase start? 2
Functional Safety Manager Organizati
☐ ☐ [Signature]
sign-off obtained? onal policy
HARA (Concept) or Safety ISO 26262-
☐ ☐ [Doc Ref]
Analysis (Dev) documented? 3, -4
Design reviews conducted [Review
☐ ☐ ISO 26262
with documented findings? minutes]
Quality
All reviewed defects tracked
☐ ☐ [Defect log] manageme
and closed?
nt
Verification testing per test ISO 26262-
☐ ☐ [Test log]
plan? 4, 5, 6
Configuration management
[CM ISO 26262-
applied (versioning, ☐ ☐
records] 8
baselines)?
Change
Change requests processed
☐ ☐ [CR log] manageme
through CCB?
nt
Traceability matrix updated [Traceabili Document
☐ ☐
and current? ty data] ation
Tool qualification current for [Tool list + ISO 26262-
☐ ☐
tools used? qual status] 8

Audit Results:
No. of Findings: ___ (Observations, Minor non-conformances, Major non-
conformances)
Audit Conclusion: ☐ Compliant ☐ Minor issues (low risk) ☐ Major issues (stop work,
remediate)
Required Actions: [List by priority]
Follow-up Audit Date: [Scheduled]
Auditor: [Name, Signature, Competence] Date: ___
5.2 Non-Conformance Management
Purpose: Track, analyze, and correct safety-related deviations.

5.2.1 Non-Conformance Classification

Minor Non-Conformance:
Process deviation with low safety risk impact
Example: Design review conducted but minutes not documented
Action: Document retrospectively or conduct brief repeat review
Major Non-Conformance:

Process deviation with potential safety impact

Example: Safety requirement not traced to test; gap in verification evidence
Action: Halt work until issue resolved; conduct impact assessment; test gap closed
Critical Non-Conformance:
Uncontrolled defect or safety risk identified in delivered product
Example: Hazard in FMEA not addressed in design; failure mode not detected
Action: Immediate escalation to leadership; root cause analysis; corrective action;
customer notification

5.2.2 Non-Conformance Process

Upon Identification:

1. Documentation:
Record what the non-conformance is (specific deviation from
standard/process)
Where found (project, phase, artifact)
Risk assessment: Could this affect safety? Which safety goals?
2. Root Cause Analysis:
Why did the process deviation occur?
Not just: "Engineer forgot," but deeper: "No audit reminder scheduled; person
new; no checklist at gate"
Identify systemic issues (not just individual mistakes)
3. Corrective Action:
For this project: What remediation is needed? (Re-test, re-analyze, design
change)
For organization: What process change prevents recurrence?
Example: "Implement gate checklist; add calendar reminder for design
reviews; brief team on requirements"
4. Closure & Verification:
Corrective action implemented and verified effective
Record: Date closed, evidence of correction, follow-up plan if needed
Non-Conformance Tracking Report (Monthly):
 Da Cla D
te ssi Correc ue
Ph Root Sta
ID Fo Issue fic tive D
ase Cause tus
un ati Action at
d on e
New
Create
Test enginee
test Clo
NC De case for r; no 12
12/ case sed
-20 vel SWR- test /1
01/ Ma templa 12/
24- op FS-004 case 5/
20 jor te; 10/
12- me not templat 20
24 email 202
01 nt docume e 24
to 4
nted provide
team
d
Failure Re-
HARA
NC mode assess 12
12/ not In
-20 identifi Cri HARA; /0
03/ HA update Pro
24- ed in tica update 8/
20 RA d after gre
12- FMEA l if 20
24 design ss
02 not in neede 24
review
HARA d

Part 6: Production, Operation & Decommissioning

6.1 Production Phase (ISO 26262-7)
6.1.1 Production Process Safety Planning
Before production release:
1. Production Safety Plan:
Which production process steps could introduce faults?
Examples: Component soldering could create cold joints; firmware flashing
could corrupt memory
For each risk: inspection/test method to detect
2. Production Verification Methods:
In-circuit testing (ICT): Electrical continuity, component placement
verification
Functional testing: Each unit powered; safety functions tested (brake warning
triggered, sensor reads correctly)
Burn-in testing: Units operated under stress to detect early-life failures
HASS (Highly Accelerated Stress Screening): Thermal cycling, vibration to
screen out weak components
3. Production Quality Control:
 Sampling plan: Inspection percentage (100% for critical safety functions, or
AQL sampling)
Traceability: Each unit can be traced back to component lots, software
version, test date
Non-conformance handling: Any failed test triggers investigation; corrective
action documented

6.1.2 Configuration Control in Production

Software Build Management:
Each production software load is uniquely identified (version number)
Compiler version, linker settings, compiler optimization flags documented
Build reproducible (any engineer can rebuild from source and get identical
executable)
Traceability from production vehicle to exact software version used

Hardware Component Management:

Component BOM (Bill of Materials) specifies part number and revision
Changes to components (even minor revisions) go through change control
Qualified suppliers list maintained; only approved suppliers used
Incoming component inspection verifies part number, revision, date code

6.2 Operation, Service & Decommissioning

6.2.1 Operational Safety Considerations
Vehicle-In-Service Monitoring:

Diagnostic data collected from vehicles in field (warranty claims, recall campaigns)
Safety-related failures investigated: Was there a fault tree path we missed? Did
system respond safely?
Lessons fed back into next product generation
Software Updates & Patches:
Any safety-critical software change treated as new product development (testing,
verification, confirmation)
Cannot simply upload "patch" without full verification
Clear communication to customers about nature of update

6.2.2 Decommissioning
End-of-Life Planning:

When product reaches end-of-service: How is system safely disabled?

Data securely erased (safety-critical information not retrievable)
Documentation archived for warranty claims or incident investigation
Residual hazards (electrical, mechanical) managed during removal
Part 7: Metrics & Performance Management
7.1 Safety Metrics & KPIs
Organization-Level KPIs (reviewed quarterly by leadership):

Metric Target Rationale

% of projects with approved No project starts
Safety Plan before 100% without safety
development roadmap
% of safety-critical
Completeness
requirements with 100%
verification
traceability to test
% of design reviews with Accountability and
100%
documented sign-offs audit trail
Major non-conformances per Indicates process
<2
50 projects maturity
ASIL D projects achieving
Demonstrates
confirmation measures on 100%
delivery discipline
schedule
Engineer compliance with
Competence
annual functional safety 100%
maintenance
training
60 days
Time from non-conformance Responsiveness to
(minor), 30
identification to closure issues
days (major)

Project-Level Metrics (tracked monthly):

 Acceptabl
Metric Use
e Range
Test pass rate for safety Early indicator of
> 95%
requirements design quality
Quality of peer
Code review defect detection rate > 80%
review process
Peer review cycle time (days
5-7 days Process efficiency
from submission to approval)
Verification gaps
Traceability matrix completeness 100%
identified early
Integration test execution vs. plan 90-100% Schedule health

Part 8: Risk Management & Escalation Framework

8.1 Safety Risk Escalation
Safety risks identified during development must be escalated and managed
transparently.

Risk Categories:
1. Technical Risk:
Design cannot meet ASIL target with current approach
Example: Diagnostic coverage calculated at 87% (target 90%); need design
change
Escalation: Functional Safety Manager → Project Manager → Client
Resolution: Design alternative or reduce ASIL assignment and accept
customer liability
2. Schedule Risk:
Insufficient time for verification/validation to meet ASIL
Example: 2 weeks remaining; ASIL D validation requires 3 weeks minimum
Escalation: Project Manager → Functional Safety Manager → Client → Client
acceptance of compressed schedule + risk
Resolution: Add resources, extend schedule, or reduce ASIL
3. Resource Risk:
Key engineer unavailable; no backup with required competence
Escalation: HR → Functional Safety Manager → Project Manager
Resolution: Hire/train replacement; bring in consultant; pause project
4. Tool Risk:
Critical tool (compiler, design tool) fails or becomes unsupported
Escalation: Functional Safety Manager → IT → Supplier
Resolution: Qualify alternative tool; use older version with workarounds
8.2 Decision Gates & Go/No-Go Criteria
Phase-End Gates (where go/no-go decision made):
Gate 1: Concept Phase Exit (Go into development)
[ ] HARA completed and ASIL assigned to all hazards
[ ] Safety goals defined; no gaps identified
[ ] Functional Safety Concept reviewed and approved by FSM
[ ] Client confirmed agreement on ASIL and approach
[ ] Safety Plan finalized with resources, tools, schedule
Decision: Proceed to Product Development OR Iterate (if gaps found)

Gate 2: Design Review (Go into coding/hardware manufacturing)

[ ] System/hardware/software architecture designed and reviewed
[ ] All safety requirements allocated to architecture components
[ ] FMEA/FMEDA completed; all major failure modes addressed in design
[ ] Preliminary Hazard Analysis (PHA) shows no new hazards
[ ] Integration test plan prepared and reviewed
Decision: Proceed to implementation OR Design iteration (if significant gaps)
Gate 3: Verification Complete (Go into validation)

[ ] All safety requirements unit/module tested and passed

[ ] Code coverage targets met (>90% ASIL C, >95% ASIL D)
[ ] Integration tests executed; no critical failures
[ ] Peer code reviews 100% complete; no high-severity defects
[ ] Safety analysis updated with integration test results
Decision: Proceed to validation OR Rework (if test failures)
Gate 4: Validation Complete (Go into production)
[ ] System operates per safety requirements in real-world scenarios
[ ] All safety functions trigger correctly within timing windows
[ ] Failure injection tests show safe responses
[ ] Environmental testing (thermal, EMI) passes
[ ] Confirmation review completed; no major gaps
[ ] Safety Case approved; all evidence collected
Decision: Release to production OR Remediate identified issues

Part 9: Training & Competence Development Program

9.1 Functional Safety Training Curriculum
Role-Based Training Path:

All Engineers (Mandatory):

1. ISO 26262 Fundamentals (16 hours)
Overview of 10 parts
ASIL concept and implications
How it affects their role
System/Hardware/Software Engineers (By Domain):
1. System-Level Safety (12 hours)
Hazard analysis and ASIL assignment
Safety concept development
System architecture from safety perspective
2. Hardware Safety (8 hours)
FMEDA methodology
Diagnostic coverage principles
Component derating
Redundancy architectures
3. Software Safety (8 hours)
Software safety requirements specification
Design for safety (fault tolerance, safe state)
MISRA C coding standards
Software verification methods

Project Leads & Managers:

1. ISO 26262 Project Management (12 hours)
Safety planning and scheduling
Risk management
Change control
Confirmation measures planning
Functional Safety Engineers & FSM:

1. Advanced HARA (16 hours)

HARA facilitation
ASIL decomposition
Multi-domain hazard analysis
2. Safety Case Development (12 hours)
Argument structuring
Evidence collection
Confirmation review preparation
3. Tool Qualification (8 hours)
TCR approaches
Test validation methodology
Vendor evaluation

9.2 Annual Competence Maintenance

Minimum 16 hours per year (refresher + advanced topics)
Industry conferences (ISO 26262 update, new techniques)
Internal seminars (lessons learned, case studies)
New role assignment requires role-specific certification
Competence record maintained by HR, reviewed by FSM annually
Part 10: Integration with Client (OEM) Requirements
10.1 Communication & Transparency
Regular Client Communication:
1. Kickoff Meeting (Week 1):
Safety plan presentation
ASIL confirmation
Verification approach
Confirmation measures planning
Schedule and resource plan
2. Monthly Status Updates:
Safety activities progress (% complete for each phase)
Any safety-related issues identified and resolution
Test results summary
Upcoming milestones
3. Gate Reviews (Phase-end):
Present analysis outputs (HARA, architecture, test results)
Confirm approvals before proceeding to next phase
Address client concerns on evidence sufficiency
4. Confirmation Review Coordination:
Client informed of independent reviewer identity and credentials
Client provided opportunity to observe/participate in review
Results communicated transparently; findings discussed openly

10.2 Contractual Safety Responsibilities

Contract Obligations Must Include:

1. What We Deliver:
Specific safety-critical functions and their ASILs
Confirmation measures (who performs, timeline)
Documentation (Safety Case, analysis reports, test evidence)
Intellectual property and data ownership
2. What Client Is Responsible For:
Providing System-Level HARA input (context for our Item)
Confirming assumptions about external systems
Providing integration test vectors / fault injection scenarios
Accepting our confirmation review recommendations
3. Liability & Risk Allocation:
We are responsible for ISO 26262 compliance in our scope
Client is responsible for system-level integration and validation
Clear statement: If client modifies our design without re-verification, we
disclaim responsibility
Summary & Implementation Roadmap
Organizational Maturity Progression
Phase 1 (Months 1-3): Foundation
Establish Functional Safety Manager role
Define and communicate Safety Policy
Document Safety Plan template
Begin competence assessment
Phase 2 (Months 3-6): Processes

Deploy HARA process and templates

Establish design review process
Implement configuration management
Launch internal audit program (pilot)
Phase 3 (Months 6-12): Integration
Integrate tool qualification program
Launch change management process
Conduct first internal audits on active projects
Deploy non-conformance tracking

Phase 4 (Months 12-18): Maturity

Achieve first external confirmation review (ASIL C/D project)
Refine processes based on lessons learned
Establish metrics and KPI tracking
Conduct organizational competence assessment

Closing Statement
This process framework is not a compliance checkbox exercise. Each element—from the
Functional Safety Manager's independence, to HARA discipline, to integration testing rigor,
to confirmation measures—exists because automotive failures can cause death.
Your role as an engineering services provider is to be the experts the OEM trusts to navigate
this complexity. You are not there to do the minimum to pass audit. You are there to deliver
systems that are demonstrably safe, with evidence that any skilled engineer can evaluate
and agree with.

Implement this framework with absolute commitment. Push back on schedules that don't
allow verification. Escalate safety concerns early. Train your team relentlessly. Audit
yourselves harder than any external auditor would.
The companies that succeed in automotive functional safety are those where every
engineer—from the junior software developer to the senior architect to the company
leadership—understands that safety is non-negotiable. That's the culture you must build.
References
[1] ISO 26262:2018. Road vehicles — Functional safety — Parts 1-12. International
Organization for Standardization.
[2] ISO 26262-2:2018. Management of functional safety.

[3] ISO 26262-3:2018. Concept phase.

[4] ISO 26262-4:2018. Product development at the system level.
[5] ISO 26262-5:2018. Product development at the hardware level.

[6] ISO 26262-6:2018. Product development at the software level.

[7] ISO 26262-8:2018. Supporting processes.
[8] Automotive SPICE 3.1. Process Assessment and Improvement Model.
[Link]

[9] MISRA C:2012. Guidelines for the Use of C Language in Critical Systems.
[Link]
[10] IEC 61508:2010. Functional safety of electrical/electronic/programmable electronic
safety-related systems.
[11] IEEE 1012:2016. Standard for Software Verification and Validation.

[12] INCOSE. Systems Engineering Handbook. Version 4.0. International Council on Systems
Engineering.