FuSaCert · Functional safety learning
Getting started with ISO 26262 functional safety
Start with a function and ask what can become hazardous when it malfunctions, how that hazard should be prevented, and how the measures will be shown to work. This provides a more useful entry point than memorising every abbreviation.
The learning path is original FuSaCert guidance. Descriptions of the standard paraphrase ISO 26262:2018. Practice tasks are teaching activities, not a complete list of project obligations.
Step 1: map the safety lifecycle
Read the overview of the 12 parts and connect management, concept, systems, hardware, software, production and operation with supporting processes. ISO 26262 is broader than coding rules or a final test.
Create a relationship map: what does the concept phase provide, how are safety requirements allocated at system level, and what verification evidence comes from software and hardware? Understand the direction before studying individual clauses.
Step 2: connect HARA, ASIL and safety goals
The Part 3 concept phase covers item definition, hazard analysis and risk assessment (HARA), and the functional safety concept. Define the function, boundaries and operational situations before examining hazardous events caused by malfunctioning behaviour.
Classify risk using severity S, exposure E and controllability C, then determine the associated ASIL. Exposure concerns the operational situation, not the probability of a malfunction. ASIL is a risk classification, not a product quality score.
Practice output: a bounded item description, a complete hazardous event, reasons for S/E/C assumptions and a safety goal linked to the hazardous event.
Step 3: understand how requirements become concrete
A safety goal states what hazard needs to be prevented. Functional safety requirements describe the required safety behaviour. Technical and software safety requirements further refine implementation constraints. Rewriting the same sentence at each level is insufficient.
For each downstream requirement, check its upstream basis, allocation of responsibility and verification method. Clarify inputs and expected behaviour before writing tests for an ambiguous requirement.
Step 4: follow the Part 6 software chain
Study software safety requirements, architecture, unit design and implementation, unit verification, software integration and verification, and testing of embedded software. Pair development and verification activities instead of leaving testing until the end.
Practice output: select one software safety requirement and map the component receiving it, the units implementing it, the verification level and the evidence traced back to the original requirement.
Step 5: check understanding through questions
Concept check
What different questions do HARA, FMEA and software testing answer? Can you distinguish a fault, malfunctioning behaviour, a hazard and a hazardous event?
Scenario check
Would S/E/C reasoning change in a different operational situation? What supporting information would you need instead of copying the example rating?
Evidence check
If a reviewer asks why a safety requirement is satisfied, can you connect the requirement, design and verification results?
Common questions
- Should I start with Part 3 or Part 6?
- Build the Part 3 concept chain first, then focus on your engineering discipline. Software engineers can study Part 6 next while understanding its relationship with system requirements and supporting processes.
- Is this guide enough to perform a real HARA?
- It provides a learning sequence. Real HARA needs a complete item definition, operational situation information, engineering judgement and review. A teaching example cannot simply be copied into a project.
- Do I need to buy tools immediately?
- Paper or a spreadsheet can help organise concepts, assumptions and traceability at the beginning. Tools help execute and check a process; they do not replace judgement.
Sources and scope
- ISO 26262-3:2018 · ISO catalogue
Concept phase scope: item definition, HARA and the functional safety concept.
- ISO 26262-6:2018 · ISO catalogue
Scope of product development at the software level.