Functional safety is the discipline of making sure that when electronics fail — and they do — the vehicle ends up somewhere survivable rather than somewhere catastrophic. ISO 26262 is the framework the automotive industry uses to organise that work, and it governs far more than engineering technique.
Quick Overview
What you’ll learn:
- What functional safety means in a vehicle, and what it deliberately excludes
- How the risk classification works, and why it decides the rigour of everything downstream
- What changes in testing, documentation and review once a rigour level is assigned
- Why the supplier chain carries the requirement as directly as the manufacturer does
- Where functional safety stops being sufficient on its own, and what picks up from there
- What an assessment actually examines, and what makes organisations fail one
Who this article is for:
- Software and systems engineers moving into automotive or safety-critical work
- Quality, process and compliance staff preparing an organisation for assessment
- Managers deciding what a safety programme will cost and what it will constrain
Reading time: 17 minutes
Why Vehicle Electronics Needed a Standard of Their Own
Electronic control arrived in cars gradually and then all at once. Early systems handled ignition timing and entertainment; a modern vehicle distributes braking, steering assistance, energy management and driver assistance across a network of controllers that have to agree with each other continuously. Complexity of that kind changes the nature of the risk: the dangerous failures are no longer component failures anybody can see, but interactions nobody modelled.
The general framework for this class of problem already existed. IEC 61508 addresses safety-related electrical, electronic and programmable systems across industries, and functional safety in the automotive sense is its sector-specific adaptation — narrowed to road vehicles, their development timescales and their supply structure.
What makes an automotive adaptation necessary rather than merely convenient is the shape of the industry. Vehicle programmes involve a manufacturer integrating components from suppliers who themselves integrate from further suppliers, on a product that will be maintained for many years and operated by people with no training in it. A safety framework for that setting has to be as much about who owes what to whom as about engineering method, which is why ISO 26262 spends so much of its length on organisation, process and evidence rather than on circuits.
Regulation supplies the outer boundary. Regulation (EU) 2019/2144 makes specific safety systems a condition of type-approval for new vehicles in the European Union — driver assistance functions, event data recording and related requirements — which turns the presence of certain electronic systems into a legal matter rather than a commercial choice. Regulation (EU) 2019/2144 also sets out requirements applying to automated and fully automated vehicles, which is where the regulatory frame and the functional-safety frame meet most directly. The standard is voluntary; the presence of the systems it governs is not.
The Risk Classification at the Centre of It
Everything in a functional-safety programme flows from one judgement: how bad it would be if a given function failed in a given situation. That judgement is made through hazard analysis and risk assessment, and its output is an integrity level that then sets the rigour of every subsequent activity.
The assessment considers a hazardous event along three dimensions:
- Exposure — how often a vehicle is in the situation where this failure would matter
- Controllability — whether a driver, or another road user, could reasonably avoid harm if it happened
- Severity — how serious the harm would be if nobody avoided it
Combining these produces the automotive safety integrity level. The scale runs from a quality-management classification for functions with no safety relevance up through progressively stricter levels:
- ASIL D — the highest rigour, applied to functions whose failure is likely to be both unavoidable and severe, such as braking
- ASIL C — high rigour, typical of steering assistance and comparable functions
- ASIL B — moderate rigour, typical of adaptive cruise control and similar assistance features
- ASIL A — the lowest safety classification, covering functions with limited harm potential such as automatic lighting
- QM — quality management only, for functions with no safety relevance, such as audio
Two things about this deserve emphasis, because both are routinely misread. First, the level attaches to a function in a situation, not to a component in a catalogue. The same controller can carry different levels for different functions it performs. Second, the level is an input to process, not a grade of quality: a correctly implemented QM function is not worse engineering than an ASIL D one, it is engineering under a different obligation.
Once assigned, the level propagates. It determines which analysis methods are required, how independent the reviewers must be, what test coverage has to be demonstrated, and which architectural patterns are acceptable. Getting the classification wrong at the start is therefore the most expensive available mistake, because every downstream artefact inherits it.
What the Standard Actually Changes in Practice
Organisations approaching this for the first time usually expect a technical specification and find something closer to a management system. The changes it produces are mostly organisational.
Analysis moves earlier. Hazard analysis happens at concept stage, before architecture is fixed, because the classification constrains the architecture. Teams accustomed to deciding structure first and reviewing safety later find that sequence inverted, and the inversion is the point.
Interfaces acquire obligations. A safety requirement allocated to a supplier comes with an agreement about who verifies what, what evidence is handed over, and what happens when either side changes something. This is contractual work that engineering teams do not normally do, and it is where programmes most often discover they have no process.
Roles become explicit. Somebody is accountable for the safety case; somebody independent reviews it; the degree of that independence is determined by the integrity level rather than by preference. Organisations that distribute responsibility informally have to name it, and naming it surfaces disagreements that were previously invisible.
The benefit is real and worth stating without inflation: defects that would otherwise be found in integration or in the field get found in analysis and review, which is where they are cheapest. The cost is equally real — the analysis, the evidence and the independence all consume time before anything runs. A programme that treats compliance as documentation added at the end pays the cost and receives none of the benefit, which is the most common way this goes wrong.
Testing Under a Risk-Based Regime
Verification stops being a phase and becomes a property of the whole lifecycle. What changes concretely is that the required strength of evidence is set by the integrity level rather than by the team’s judgement of what seems sufficient.
The required independence of testing scales with the level. At the highest rigour, verification is performed by people who did not develop the item; at intermediate levels, by a different team or through review by another party; at the lowest, internal verification is acceptable. This is not a statement about trust. It is a recognition that the person who wrote something has already applied their model of it, and cannot easily test the assumption they did not know they made.
Structural coverage requirements likewise tighten with the level, and the standard is specific about which coverage measures are expected. What matters operationally is that coverage becomes an argued position rather than a number to be reached: uncovered code has to be justified, and justification is reviewed.
Traceability is what makes the rest usable. Each safety requirement must be linked to the design that realises it, the tests that verify it, and the results of those tests. Without that chain, a body of testing proves that a lot of testing happened and nothing about whether the safety requirements were met.
Model-based testing earns its place here for a structural reason. Where behaviour is specified as a model, test cases can be generated systematically against it and re-generated when the model changes, which addresses the practical problem that manual test suites decay silently as requirements move.
Automated Driving, and Where Functional Safety Stops Being Enough
Functional safety answers a specific question: what happens when something fails. It says comparatively little about a system that works exactly as designed and is still unsafe because the design did not anticipate the situation. Automated driving makes that gap the central problem.
Two related standards cover the adjacent ground, and their designations are worth knowing because they get conflated. ISO/PAS 21448 addresses the safety of the intended functionality — hazards arising from performance limitations of sensing and decision-making rather than from faults. ISO/SAE 21434 addresses automotive cybersecurity. A system built to a high integrity level under ISO 26262 can still misclassify an object it was never trained to recognise, and no fault has occurred.
SAE J3016 supplies the vocabulary for how much of the driving task a system is actually performing, and it matters here for a practical reason: the level of driving automation determines who is expected to intervene, which feeds directly into the controllability judgement in hazard analysis. SAE J3016 distinguishes systems that assist a driver from systems that perform the entire dynamic driving task, and treating those as interchangeable produces a classification that is wrong from the first step.
Machine learning strains the framework in a specific way. Safety argumentation assumes behaviour that can be specified and verified; a learned model is characterised statistically. The response has been to constrain what learned components are permitted to decide, to bound them with conventional monitors, and to argue safety at the system level rather than the component level.
Where a driving function involves machine learning, the organisation is usually also examining the Artificial Intelligence Act, whose obligations for high-risk systems — a risk-management system, data governance, technical documentation, record-keeping, human oversight, and accuracy, robustness and cybersecurity — read as a familiar list to anyone who has worked a safety lifecycle. The Artificial Intelligence Act is not a substitute for functional safety and does not attempt to be, but the artefacts overlap enough that duplicating the effort is a planning failure rather than a requirement.
The Supplier Chain Problem
A vehicle manufacturer integrates work it did not do. Functional safety therefore has to survive the boundary between organisations, and the mechanism it uses is an explicit agreement about who is responsible for which safety activities.
That agreement is more demanding than a normal specification because it has to cover assumptions. A supplier delivering a component to a given integrity level does so under stated conditions — about the environment, the inputs, the diagnostic coverage the integrator is expected to provide. If the integrator uses the component outside those conditions, the classification does not transfer, and the resulting gap is invisible in every document either party holds.
The practical consequences are familiar to anyone who has run a supplier programme. Assumptions have to be written down and confirmed, not inherited. Evidence has to be transferable, which means the supplier’s internal artefacts must be intelligible to somebody outside their process. And changes on either side have to trigger a re-examination, because a modification that is trivial locally can invalidate a safety argument two levels up.
Organisations that already run a structured programme for assessing external providers have most of the machinery for this; the additions are the assumption register and the safety-specific evidence exchange. The general discipline is set out in our guide to third-party risk management, and the automotive version is the same practice with a stricter evidence standard.
Competence as a Requirement Rather Than an Aspiration
The standard treats competence as something to be established and demonstrated rather than assumed. That has consequences for how an organisation staffs and records safety work.
Different roles need different things. An engineer implementing a safety mechanism needs the technique; a reviewer needs enough independence and depth to challenge it; a manager approving a safety case needs to understand what the case does and does not claim. Treating these as one training requirement produces a course that suits nobody.
Records matter because an assessor will ask. Being able to show that the people who performed safety-relevant activities had appropriate training and experience is part of the evidence, and reconstructing it afterwards is far harder than maintaining it.
Knowledge transfer is the underestimated part. Safety programmes accumulate reasoning that never reaches a document — why an assumption was drawn where it was, which alternative was rejected and on what grounds. When that reasoning lives only in one person, their departure removes the ability to defend decisions the organisation is still relying on.
Structured training is the efficient route into this, precisely because the material is procedural rather than intuitive. The ISO 26262 functional safety course covers the lifecycle, the classification and the evidence obligations in the order a programme actually needs them, which is faster than assembling the same understanding from the standard’s parts individually.
Evidence, Documentation and Traceability
Documentation in this context is not administrative overhead attached to engineering; it is the engineering output that anyone outside the team can examine. That distinction changes how it should be produced.
The chain runs from hazard analysis through safety goals, safety requirements, architecture, implementation, verification and validation results. Each link has to be navigable in both directions: from a requirement to the tests that verify it, and from a test result back to the hazard it ultimately addresses. Systems that support the first direction and not the second cannot answer an assessor’s most common question, which is why a particular thing was tested at all.
Version control is where this most often degrades. A safety case is a statement about a specific configuration. When components, tools and documents drift out of step, the case describes a system that was never built, and re-establishing correspondence retrospectively is expensive and unconvincing.
Retention obligations extend well past the end of development. An organisation may need to demonstrate the basis of a decision long after the people who made it have moved on, which argues for documentation written to be read by strangers rather than as an aide-memoire for the authors.
Different readers need different artefacts, and conflating them produces documents that serve none of them. Developers need specifications precise enough to implement. Assessors need argument and evidence. Management needs the residual risk position stated plainly. Producing one document intended to satisfy all three is a reliable way to satisfy none.
Security as a Safety Property
A vehicle with external interfaces has an attack surface, and a successful attack on a safety-relevant system produces a safety consequence. The separation between safety work and security work is therefore administrative rather than real.
The connection runs in both directions. Security failures can defeat safety mechanisms — a manipulated message on an internal bus can drive a correct implementation into an unsafe state. And safety mechanisms can be security-relevant, because a system that fails safe under attack is behaving as designed even while under attack.
Software update is where safety and security become least separable. A vehicle that accepts updates in the field has an authenticated, integrity-protected channel to safety-relevant software, and both the protection of that channel and the verification of what arrives through it are conditions of the safety argument continuing to hold after delivery.
Established software-security practice transfers directly. NIST’s Secure Software Development Framework (SSDF) sets out practices for preparing an organisation, protecting software, producing well-secured software and responding to vulnerabilities, and the Secure Software Development Framework maps onto a safety lifecycle without friction because both are process frameworks built around evidence.
The organisational lesson is that industrial systems and vehicles face structurally similar problems: long-lived equipment, safety consequences and networks that were not designed for hostile traffic. Our guide to IT, OT and ICS cybersecurity covers that territory in detail and is directly applicable here.
Software Process Inside a Safety Lifecycle
Software work under a functional-safety regime is recognisably normal software engineering with the discretionary parts removed.
Language use is constrained. Unrestricted C or C++ contains constructs whose behaviour is undefined, implementation-defined or simply easy to get wrong, and a safety argument cannot rest on them. The industry’s answer is a restricted subset, and the MISRA coding guidelines are the subset most suppliers adopt. Adopting the MISRA coding guidelines is not a formality: deviations have to be justified individually, which is the mechanism that keeps the subset meaningful.
Static analysis moves from optional to expected, and its findings become part of the evidence rather than a private developer aid. So do reviews, which acquire specified participants and recorded outcomes.
Agile practice is compatible with this, contrary to a persistent belief that it is not, but only if the safety artefacts are treated as part of the increment rather than as a phase deferred to the end. What is incompatible is deciding architecture iteratively while a safety argument depends on it being stable; the constraint falls on architecture, not on iteration.
Tool qualification is the requirement teams forget to budget for. A tool that could introduce or fail to detect an error in safety-relevant software has to be evaluated for that possibility, and the evaluation depends on how the tool is used rather than on the vendor’s claims.
Failure Analysis and the Safe State
The technical core of the work is a systematic account of how the system can fail and what it does when it does.
Analysis works from both directions and needs both. Working upward from component failure modes establishes what each failure would do to the system; working downward from a hazardous event establishes which combinations could produce it. Either alone leaves a class of problems invisible: bottom-up misses combinations, top-down misses failure modes nobody enumerated.
Random hardware failures are treated statistically, and the required probability targets tighten with the integrity level. Systematic failures — design errors, specification errors, process errors — are not treated statistically at all, because they are not random; they are addressed by process rigour, which is exactly what the integrity level determines.
Diagnostic coverage is what connects analysis to design. A failure the system can detect can be handled; a failure it cannot detect can only be prevented or tolerated architecturally. Deciding which failures need detection, and designing mechanisms that detect them within a useful time, is the central design activity.
The safe state is the destination. It is not always a shutdown — for a steering system, losing assistance is safer than losing control — and identifying the correct one for each function is a judgement about the vehicle, not about the component. Analysis has to remain live: field data reveals failure modes that analysis did not anticipate, and an analysis that is never revisited becomes a historical document.
Change After Start of Production
A vehicle that has been sold is still under the safety argument, and changes to it are governed accordingly.
Every proposed change goes through an impact analysis that asks what part of the safety argument it touches. The answer is frequently wider than expected, because safety arguments rest on assumptions that the person making the change may not know exist.
Regression is the practical burden. A change that affects a safety-relevant item requires re-verification proportionate to its integrity level, and organisations that have not automated their verification discover that the cost of a small change is dominated by the cost of proving it was small.
Field updates raise the stakes. When software can be changed after delivery, the safety argument has to cover the update mechanism, the verification performed before release, and the behaviour of a vehicle that is partially updated or interrupted mid-update. These are design requirements, not deployment details.
Communication closes the loop. Suppliers, service networks and — where behaviour changes — owners need to know what changed. A change that is technically sound and unannounced can still produce an unsafe outcome, because someone was relying on the previous behaviour.
Assessment, and What Assessors Actually Look For
Preparing for a functional-safety assessment is mostly a matter of having done the work in a form somebody else can follow.
Assessors look for correspondence between what the process says and what the records show. A defined process with no evidence of use is worse than a simpler process that is demonstrably followed, because it establishes that documentation and practice have diverged.
They follow chains. A common technique is to select a hazard and trace it forward to the tests that address it, or select a test result and trace it back to the requirement that motivated it. Programmes fail this not because the work was absent but because the links were maintained inconsistently.
They probe reasoning rather than checking boxes. The question is usually why a decision was made — why this classification, why this diagnostic coverage, why this assumption was acceptable — and the answer has to come from the people who made it. This is why competence records and internal audit results matter: they establish that the organisation was checking itself before anyone else did.
The preparation that pays is internal audit conducted honestly, followed by closing what it finds. Organisations that treat internal audit as rehearsal for a good impression arrive with a clean internal report and unresolved problems. The general mechanics of preparing for an external examination — evidence sampling, scope agreement, corrective action tracking — carry over from other domains, and our guide to preparing for security audits covers them in a form that translates.
What Is Changing Next
Three pressures are reshaping this area, and none of them is speculative.
Software that changes after sale now delivers a growing share of vehicle capability. That makes the safety argument a living artefact rather than a delivery milestone, and it pushes organisations toward the automation and traceability infrastructure that continuous re-verification requires.
Convergence of the safety, security and performance-limitation frameworks is the second. Functional safety, the safety of intended functionality and automotive cybersecurity were developed separately and are increasingly worked as one programme, because their evidence overlaps and their conclusions constrain each other.
Electrification is the third. It introduces energy-management and charging functions whose failure modes had no equivalent in a combustion vehicle, and which are safety-relevant in ways that are still being learned.
The stable conclusion underneath all three is unglamorous. Functional safety is not a certificate obtained once; it is an operating capability that has to be maintained for as long as the product exists. Organisations that build it as a capability find each subsequent programme cheaper. Organisations that build it as a project rebuild it every time.
Build Your Skills
Most of the difficulty in functional safety sits in the software part: what the standard requires of specification, coding, verification and tool use, and how to produce evidence that survives an assessment. The secure software development course for ISO 26262 works through exactly that material with practical exercises. Check the programme and sign up.
Frequently Asked Questions (FAQ)
What does an ASIL classification actually determine?
It determines the rigour required of everything downstream, not the quality of the outcome. The classification comes from hazard analysis — how often the situation arises, whether anyone could avoid harm, and how severe the harm would be — and it then fixes which analysis methods are required, how independent the reviewers must be, what verification evidence is needed and which architectural approaches are acceptable. It attaches to a function in a situation rather than to a component, which is why one controller can carry several classifications at once.
Does the standard apply to suppliers or only to vehicle manufacturers?
To both, and the supplier obligation is often the more demanding one in practice. Safety activities are divided between the parties by explicit agreement, and a component delivered to a given integrity level carries assumptions about how it will be used, what its inputs will be, and what diagnostics the integrator will provide. If those assumptions are not confirmed on the integrating side, the classification does not transfer, and neither party’s documents will show the gap.
Is compliance legally required?
The standard itself is voluntary; the situation around it is not. Regulation (EU) 2019/2144 makes specific safety systems a condition of type-approval for new vehicles in the European Union and sets requirements for automated vehicles, so the systems whose safety the standard governs are legally mandated even where the method of assuring them is not. Commercially the question is settled anyway: conformity is a routine requirement in supply agreements, particularly for higher integrity levels.
How does functional safety relate to cybersecurity and to automated driving?
They cover different failure sources and have to be worked together. Functional safety addresses what happens when something fails; ISO/PAS 21448 addresses hazards arising from performance limitations of a system that has not failed; ISO/SAE 21434 addresses deliberate attack. An automated driving function needs all three, because a correctly functioning, uncompromised system can still misjudge a situation it was not designed for, and that failure belongs to none of the other two.
Where do implementations usually go wrong first?
At the point where safety is treated as documentation rather than as a sequence of decisions. The classification is made late, after architecture is fixed; assumptions passed to suppliers are never confirmed; traceability is maintained in one direction only; and the evidence is assembled shortly before an assessment. Each of these is cheap to avoid at the start and expensive to repair afterwards, because every downstream artefact has already inherited the problem.