Dervo
If you supply software or engineering services to an automotive OEM or Tier 1, you will hear two names very early: ISO 26262 and Automotive SPICE (ASPICE). They are often mentioned together, but they answer different questions.
The short version
- ISO 26262 asks: is this product safe enough? It is the functional safety standard for electrical and electronic systems in road vehicles.
- ASPICE asks: are your development processes capable and under control? It is a model used to assess how a supplier develops systems and software.
A project can be assessed on both, and most customers expect both.
ISO 26262 in practice
ISO 26262 follows a V-model from the concept down to hardware and software, and back up through integration and validation.
- Hazard analysis and risk assessment. For each vehicle-level hazard, the team rates severity, exposure and controllability.
- ASIL. The result is an Automotive Safety Integrity Level from A (lowest) to D (highest), or QM where no special safety measures are needed.
- Safety goals and requirements. Each hazard gets a safety goal, broken down into technical safety requirements for hardware and software.
- Methods scale with ASIL. Higher ASILs need stricter methods, for example more demanding test coverage, more formal reviews and stronger independence of verification.
- Evidence. Work products show that each requirement was implemented and verified. Tools used in development may need to be qualified.
ASPICE in practice
ASPICE defines processes such as requirements analysis, architecture, construction, integration testing, qualification testing, project management, quality assurance, configuration management, problem resolution and change management.
- Each process is rated on a capability level from 0 to 5.
- Customers commonly ask suppliers for level 2, and sometimes level 3, for the processes in scope.
- Level 2 means the work is planned, monitored and controlled, and the work products are managed. Level 3 means the organisation has a defined standard process that projects tailor and follow.
- Version 4.0 of the model extends it to hardware engineering and machine-learning engineering.
Where the two overlap
The good news: the foundations are the same. If you get these right, both assessments become much easier.
- Traceability from requirements to design, code and tests, in both directions.
- Reviews with recorded results and follow-up of findings.
- Configuration management: knowing exactly which version of everything was tested and delivered.
- Change management: every change analysed for impact before it is made.
- Problem resolution: defects tracked to closure, with root causes understood.
Common gaps in small supplier teams
- Requirements kept in documents with no stable IDs, so traceability is impossible.
- Test results that cannot be tied to a specific software version.
- Reviews that happen but leave no record.
- Changes made directly in code without updating requirements and tests.
None of these needs expensive tools to fix. They need agreed ways of working, used consistently from the first week of the project.
