What Is Automotive SPICE?
Automotive SPICE (Software Process Improvement and Capability dEtermination) is a process assessment framework tailored for automotive software development. It defines a set of processes and capability levels that describe how well an organization executes its development activities.
OEMs require ASPICE assessments from their Tier 1 software suppliers as a condition of business. Achieving ASPICE Level 2 is the baseline expectation for new programs at most major OEMs. ASPICE Level 3 is increasingly required for safety-critical ECU software.
The current version is PAM 3.1 (Process Assessment Model), released in 2017. It covers engineering processes (requirements, architecture, design, implementation, testing), supporting processes (configuration management, quality assurance, change management), and management processes (project management, risk management).
The Capability Level Model
ASPICE rates each process on a capability scale from 0 to 5:
| Level | Name | What It Means |
|---|---|---|
| 0 | Incomplete | Process not implemented or fails to achieve its outputs |
| 1 | Performed | Process achieves its purpose |
| 2 | Managed | Process is planned, monitored, and adjusted; work products are controlled |
| 3 | Established | Process is performed using a defined standard process; tailoring is documented |
| 4 | Predictable | Process operates within defined limits; quantitative management |
| 5 | Optimizing | Process is continuously improved |
Level 2 requires evidence that the process is planned, work products are managed (baseline, change control), and quality criteria are defined and monitored.
Level 3 additionally requires that a defined, organization-wide process exists — you're not just doing it ad hoc on this project, you have a standard process that's documented and followed consistently across projects.
Key ASPICE Processes for Safety Programs
SWE.1 — Software Requirements Analysis
Derives and analyzes software requirements from system requirements. Work products: software requirements specification, traceability to system requirements, consistency analysis.
SWE.2 — Software Architectural Design
Defines software architecture allocating requirements to software components. Work products: software architectural design document, traceability from requirements to architecture.
SWE.3 — Software Detailed Design and Unit Construction
Detailed design at unit level and implementation. Work products: detailed design, source code, unit test specification.
SWE.4 — Software Unit Verification
Verification of software units against the detailed design. Work products: unit test plan, test cases, test results, coverage metrics.
SWE.5 — Software Integration and Integration Test
Integration of software components and integration testing. Work products: integration test plan, integration test specification, test results.
SWE.6 — Software Qualification Test
Qualification testing of the software against software requirements. Work products: qualification test plan, test specification, test results, coverage against requirements.
SYS.2–SYS.5 — System Engineering
System requirements analysis, architectural design, integration, and qualification — the system-level counterparts to SWE.1–6.
How ASPICE Relates to ISO 26262
ISO 26262 defines what you need to produce (work products, verification activities, review records). ASPICE defines how well your process for producing those things is managed and controlled.
They complement each other:
- An ISO 26262 software safety requirement is a work product in SWE.1
- The ISO 26262 software architectural design is the SWE.2 output
- ISO 26262 software unit testing evidence (including MC/DC coverage for ASIL C/D) is part of SWE.4
- ISO 26262 traceability requirements — requirements to design to test — are exactly what ASPICE Level 2 measures for process management
In practice: if your ISO 26262 program is well-documented with proper traceability, controlled work products, and formal review records — you are already producing most of the evidence ASPICE Level 2 needs. The difference is that ASPICE also asks about the process planning, monitoring, and quality criteria around those activities.
Common ASPICE Audit Failures
1. Traceability gaps between levels
Requirements exist, architecture exists, but the links between them are incomplete or informal. ASPICE Level 2 requires documented bidirectional traceability. "We know which requirements drove which components" is not traceable.
2. Work products not under configuration control
Documents that were reviewed and approved but weren't baselined — so there's no way to tell what version was reviewed. Configuration management is a Level 2 generic practice requirement for every process.
3. No evidence of process monitoring
Level 2 requires that the process is monitored against a plan. If you have no review meeting minutes, no status tracking, no evidence that deviations from the plan were identified and corrected — you won't achieve Level 2 for that process.
4. Informal change management
Changes to requirements, architecture, or code that happened without a formal change request and impact analysis. "We just updated it" fails the Level 2 change management expectation.
5. Test coverage not reported against requirements
Having test results isn't enough. ASPICE requires that test coverage is reported against the requirements being tested — percentage of requirements verified, with traceability from test case to requirement.
ASPICE and ISO WIZ
ISO WIZ generates the work products that ASPICE assessors look for — requirements specifications, architectural design documents, traceability matrices, review records, test plans, and test results — as a natural output of the ISO 26262 and ISO 21434 workflows. Configuration management and change control are built in: every artifact is versioned, every change is logged with author and rationale, and every review is timestamped.
This means that an ASPICE Level 2 assessment for a program developed with ISO WIZ is largely a matter of pointing the assessor at the platform — not assembling evidence from disparate sources after the fact.
ISO 26262 · SOTIF · ISO 21434 · ASPICE — one platform
ISO WIZ harmonizes all four standards into a single workflow with shared traceability, cross-standard gap detection, and no spreadsheet maintenance.
Try ISO WIZ Free →