A capability level says the process that produced your software is under control. It says nothing about whether the product that came out of it is safe. Those are two different verdicts, awarded by two different evaluations, and neither substitutes for the other.
That is the whole of the ASPICE and ISO 26262 relationship, and most of the trouble teams have with it comes from expecting one framework to do the other's job.
Two questions over one set of artifacts
Automotive SPICE is a process assessment model, maintained by the VDA QMC. It asks whether your engineering is under control and repeatable, and answers on a scale: each process in scope is rated, and a capability level follows. Version 3.1 still runs in many programs; version 4.0, released in 2023, is current.
ISO 26262 is a safety standard. It asks whether the risk of harm from a malfunction of an electrical or electronic system has been reduced to an acceptable level, and it answers with an argument: safety goals, the measures taken to meet them, and evidence that they hold. Its rigour is not uniform, it scales with the ASIL assigned to each safety goal.
The practical consequence: an organisation assessed at capability level 3 can still ship a product whose safety argument does not hold, and a positive functional safety assessment awards no capability level at all. Presenting one as evidence of the other is a good way to be corrected in public.
Three zones in one process landscape
Lay the two frameworks over each other and three zones appear. Knowing which zone a piece of work sits in tells you whether you are writing it once, or writing it at all.
The shared middle is the engineering V, and the shared base is configuration, change, problem resolution, quality assurance and project management. Both evaluators walk them, reading the same documents. Everything there is written once.
The safety-only top is the concept phase. Hazard analysis and risk assessment, the safety goals that come out of it, and the functional safety concept sit above the top of the V, and no ASPICE process produces any of them. It is a whole storey of the building that a capability assessment will never ask about, and the storey the rest of the safety argument rests on.
What safety adds to a shared artifact
In the shared middle, safety does not replace the artifact. It adds attributes to it, and raises the bar for what counts as done.
Take an electric power steering system. A well-formed system requirement is uniquely identified, verifiable, traced up to its source and down to the tests that check it, reviewed and under configuration control. That is good requirements engineering, and it is what a capability assessor looks for.
Safety asks what good structure alone does not answer. Which safety goal is this helping to meet, what ASIL does it inherit, what happens when the torque sensor fails, within what time, and into what safe state. A requirement can be impeccably managed and never have been asked whether the system it describes can produce unintended steering torque at speed.
One note on level. A safety goal states how the item must behave: prevent unintended steering intervention the driver cannot control. It names no component and no mechanism. The torque threshold, the reaction time and the sensor belong to the safety requirements refined underneath it.
Where the effort differs
| Area | What a capability assessment looks for | What ISO 26262 adds |
|---|---|---|
| Concept | Customer needs captured and agreed | The whole phase: hazard analysis and risk assessment, safety goals, the functional safety concept |
| System | Requirements, architecture and integration, traced and consistent | Safety requirements and mechanisms, allocated to elements |
| Software | Requirements, design, implementation, unit verification | Method and rigour selected by ASIL |
| Verification | Requirements-based testing at each level, coverage of the requirements | Fault injection and safety mechanism testing, tied back to a safety goal |
| Support and management | Configuration, change, problem resolution, quality assurance, planning | A safety plan, and a safety-impact question on every change |
The trap: two documentation sets
The expensive mistake is not a missing safety activity. It is running two programs: a safety team writing safety requirements in one tool while a process team maintains the software requirements specification in another, each with its own traceability and review cycle. The two sets drift from the first change. Then an assessor finds a safety requirement with no matching software requirement, an auditor finds a trace whose ends no longer agree, and the same engineer answers the same question twice in two vocabularies.
The alternative is one requirements database with a safety-relevant flag and an ASIL on every node, filtered into a safety view rather than copied into one. Which artifacts can genuinely merge, and which safety documents have to stay separate, is the part worth getting right before you restructure anything.
Where to go next
Keep the two questions apart, build one artifact set with safety attributes on it, and treat the concept phase as work no amount of process capability will produce for you.
On the platform, the ASPICE and ISO 26262 integration concept works through the mapping process by process, the capability rating rule, the supporting-process pairings that most often cost teams findings, and a worked requirement traced down and back up an integrated V. Hazard Analysis and Risk Assessment covers the concept phase this article only points at, and Confirmation Measures covers the reviews, audit and assessment behind the safety verdict.
Abbreviations & Key Definitions
- ASIL - Automotive Safety Integrity Level, the risk classification ISO 26262 assigns to a safety goal, from A to D, which sets how rigorous the work to meet it must be.
- ASPICE - Automotive SPICE, the model used to rate the capability of automotive systems and software development processes.
- Capability level - The result of an ASPICE assessment for one process, on a scale from 0 to 5.
- Confirmation measures - The ISO 26262 checks on a safety project: confirmation reviews, a functional safety audit, and a functional safety assessment, each at an independence that rises with the ASIL.
- EPS - Electric Power Steering, a steering system in which an electric motor provides the assist torque.
- Fault injection - Testing in which faults are introduced deliberately to check that a safety mechanism detects them and the system reaches its safe state.
- HARA - Hazard Analysis and Risk Assessment, the activity that identifies hazardous events and assigns an ASIL to each resulting safety goal.
- Safe state - An operating mode entered when a fault is detected, in which the safety goal is not violated.
- Safety goal - A top-level safety requirement derived from the hazard analysis, stated without technical solution detail.
- VDA QMC - The quality management centre of the German automotive industry association, which maintains Automotive SPICE.
Photograph: car factory assembly line, Gliwice, by Marek Slusarczyk (Tupungato), CC BY 3.0, via Wikimedia Commons.
This article was corrected and edited with Claude.
Comments
Loading comments