Most functional safety training follows one pattern. A few days in a room, a certificate, and then the project. Six months later the hazard analysis is due, the engineer who took the course opens a blank template, and what comes back is the shape of the method and none of the judgement. Nothing went wrong with the course. It was asked to do something no course can do.
Why one shot does not hold
ISO 26262 runs to twelve parts. Nobody applies all of them at once, and nobody applies most of them soon after learning them. Hazard analysis comes at the start of a project. Hardware metrics come a year later. The functional safety assessment comes at the end. Whatever a training week covers is used in slices, each slice months apart, and the slices that are not used in time fade.
The alternative is not a longer course. It is a shorter distance between learning a method and doing it, repeated until the method stops being a checklist and becomes a way of thinking. Learn a topic. Apply it to a real item, or one close enough to hurt. Get evaluated, so the gaps are visible instead of assumed. Then come back to it when the next project asks for it again. The competence an assessor looks for is built this way, one cycle at a time.
It never stands alone
The second reason is that ISO 26262 is not self-contained. Each step borrows knowledge from a domain the standard does not teach. A hazard analysis is only as good as the engineer's understanding of the vehicle, its dynamics and how a driver reacts. A functional safety concept needs E/E architecture judgement. Hardware metrics need reliability data and practice with FMEDA arithmetic. Part 6 assumes the reader can design, code and verify software. The supplier interface is a contract as much as a DIA. Tool confidence needs the toolchain in detail.
Then there is what the standard leaves out on purpose. A sensor that works to specification and still misses a pedestrian is a SOTIF question, ISO 21448. A forged bus message is a cybersecurity question, ISO/SAE 21434. Both change the safety argument, and both are met by the same team, on the same item, usually in the same year.
No single person holds all of this on day one, and no team holds it evenly. The hardware lead knows FMEDA and has never run a hazard analysis. The new hire has read Part 3 and never watched a fault tree yield its cut sets. That unevenness is normal. What is not acceptable is not knowing where the gaps are.
Learn, practice, evaluate, repeat
The loop is simple to describe and hard to run by hand. Learning is reading and watching, and it is the cheapest part. Practice means doing the method on something concrete: a fault tree that has to yield its minimal cut sets, an FMEDA whose single-point fault metric has to reach the target, a hazard analysis on an item the engineer actually works on. Evaluation means an exam that comes back with the topics missed, not a certificate that says attended. Repeat means a refresher before the knowledge is needed again, not after the audit finds it missing.
Run by hand, the loop breaks at the third step. Managers know who attended what. They rarely know who can still do it.
What this looks like for a team
ISO 26262 Academy for Teams exists to keep that loop running without a manager chasing it. Seats belong to the company and move from one engineer to the next. A manager assigns concept pages and processes by role, so a hardware engineer and a software engineer are not sent through the same tour. Practice happens in the simulators, on the team's own numbers, and in the work product templates. Exams close each cycle and report per topic, so the whole team's weak spot shows up as one line rather than as an audit finding. Refreshers recur on the cadence the company sets.
The by-product is the evidence. Every cycle leaves a record: training completed, exam attempted, score, date, integrity signals. Read across the team, that is a competence matrix that is already filled in when the assessor asks for it, and it stays current because the loop keeps turning.
Not one shot
ISO 26262 is not learned in one shot, and it was never going to be. It is learned the way the rest of engineering is learned: by doing it, checking it, and doing it again on the next project. The difference for a team is whether that loop is left to chance or run on purpose.
See what a Teams workspace contains at iso26262.academy/teams.
Abbreviations & Key Definitions
- DIA - Development Interface Agreement, the ISO 26262 Part 8 agreement between customer and supplier.
- E/E - Electrical and Electronic, including programmable electronics.
- FMEDA - Failure Modes, Effects and Diagnostic Analysis, the basis of the Part 5 hardware metrics.
- ISO 21448 - Safety of the Intended Functionality (SOTIF).
- ISO/SAE 21434 - Road vehicle cybersecurity engineering.
- TCL - Tool Confidence Level, ISO 26262 Part 8.
Comments
Loading comments