ASPICE: Process Maturity

TL;DR

ASPICE (Automotive SPICE) measures how you build software, not what the software does. It’s a process assessment framework. Capability Levels 0–5 rate process maturity from “chaotic” to “optimizing.” OEMs require ASPICE Level 2 or 3 from Tier-1 suppliers because they can’t audit every line of your QNX gateway code. They audit whether your requirements traceability, change management, and verification process would catch bugs before they ship. ASPICE does not replace ISO 26262 or ISO 21434. It ensures your process can consistently deliver safe, secure products.

Your code might be brilliant. ASPICE asks: “Can you prove you knew what you were supposed to build, that you built it, that you tested it, and that you can reproduce the whole trail two years later during a recall?” Welcome to automotive process engineering, the paperwork that makes safety and security cases possible.

Process, Not Product

This distinction confuses every new engineer:

	Product Assessment	Process Assessment (ASPICE)
Question	Does this software work correctly?	Did the team follow a repeatable process to build it?
Examples	Unit tests, HIL testing, pen tests	Requirements management, configuration management, review records
Standards	ISO 26262 V&V, ISO 21434 verification	ASPICE SWE, SUP, MAN process areas
Outcome	Pass/fail on functionality	Capability Level rating

A team can ship working code with ASPICE Level 0 (hero-driven, tribal knowledge) until the hero leaves, the OEM audits, or a recall demands traceability you don’t have. ASPICE exists because OEMs outsource 80% of software and need confidence in supplier engineering discipline.

ASPICE asks a simple question: are suppliers producing in controlled environments? Product is what; process is how.

Mental Model

ASPICE is a restaurant health inspection, not a food critic review. The inspector doesn’t primarily taste your soup — they check hand-washing logs, fridge temperatures, supplier receipts, and recipe documentation. A delicious soup from a dirty kitchen fails. A mediocre soup from a spotless, traceable kitchen might pass. OEMs want proof your kitchen won’t poison the supply chain.

Capability Levels 0–5

ASPICE rates each process area (e.g., Software Requirements Analysis) on a scale:

Level	Name	What It Means	Automotive Reality
0	Incomplete	Process doesn’t exist or fails to achieve purpose	Startup mode, hero debugging, “works on my bench”
1	Performed	You do the work, but inconsistently	Team ships features; documentation is afterthought
2	Managed	Process is planned, monitored, and adjusted	Minimum bar for most OEM contracts (defined roles, tracked tasks, managed configs)
3	Established	Standard process used across projects; assets reused	Target for Tier-1 suppliers (templates, training, org-wide consistency)
4	Predictable	Process is quantitatively controlled	Metrics-driven: defect density, review coverage, escape rate
5	Innovating	Continuous process improvement from data	Rare in automotive; aspirational for mature orgs

Most OEM RFQs (Request for Quotation) demand ASPICE SWE Level 2 or 3 from Tier-1 ECU and domain controller suppliers. Level 1 is “we tried.” Level 2 is “we have a plan and evidence.” Level 3 is “every project does it the same way.”

Level 2 (Managed) is the minimum OEM mandate. Level 3 (Established) is where other teams start copying your templates.

Key Process Areas (V-Model Mapping)

ASPICE organizes software development into process areas that mirror the V-model lifecycle:

flowchart TB
    subgraph Left["Specification (Left Leg)"]
        SYS1["SYS.2 System Requirements"]
        SYS3["SYS.3 System Architecture"]
        SWE1["SWE.1 Software Requirements"]
        SWE2["SWE.2 Software Architecture"]
        SWE3["SWE.3 Detailed Design"]
    end

    subgraph Bottom["Implementation"]
        SWE4["SWE.4 Software Unit Implementation"]
    end

    subgraph Right["Verification (Right Leg)"]
        SWE5["SWE.5 Software Unit Verification"]
        SWE6["SWE.6 Software Integration Verification"]
        SWE4V["Integration & Qualification"]
        SYS4["SYS.4/SYS.5 System Integration & Qualification"]
    end

    SYS1 --> SYS3 --> SWE1 --> SWE2 --> SWE3 --> SWE4
    SWE4 --> SWE5 --> SWE6 --> SWE4V --> SYS4

Supporting processes cut across everything:

Process Area	Code	What Auditors Check
Software Requirements Analysis	SWE.1	Every requirement has ID, source, priority, testability
Software Architectural Design	SWE.2	Architecture doc maps to requirements; interfaces defined
Software Detailed Design	SWE.3	Module-level design before coding
Software Unit Verification	SWE.5	Unit tests trace to requirements; coverage reports
Software Integration Verification	SWE.6	Integration test specs, results, defect tracking
Configuration Management	SUP.8	Version control, baselines, change records
Change Request Management	SUP.10	Every change has ticket, impact analysis, approval
Quality Assurance	SUP.1	Independent QA checks process adherence
Problem Resolution Management	SUP.9	Defect lifecycle: report → root cause → fix → verify

For your daily work on QNX/AAOS integration, SWE.1–SWE.6 and SUP.8/SUP.10 are what you’ll feel most: requirements in DOORS/Polarion, Git branches tied to tickets, test reports in CI.

Common Gotcha

ASPICE Level 3 does not mean your software is bug-free. It means your organization has a defined, repeatable process with evidence. You can be ASPICE Level 3 and still ship a recall, but you’ll trace the defect to a missed requirement, a skipped test, or a change without impact analysis. Level 0 teams can’t even answer “what version was in that car?”

How Audits Work

An ASPICE assessment is typically a 3–5 day on-site or remote audit by a certified lead assessor, often coordinated with the OEM.

Phase	Activity	Your Experience
Pre-assessment	Supplier self-evaluation against process areas	Fill out capability questionnaire, gather sample artifacts
Assessment planning	Scope definition (which project, which process areas)	“SA8295P cockpit gateway, SWE.1–SWE.6, SUP.8, SUP.10”
Interviews	Assessor talks to PM, architects, developers, QA, config mgr	“Show me how this requirement became this test case”
Evidence review	Traceability matrices, review minutes, test reports, CM records	Assessor picks random requirement IDs and follows the chain
Rating	Each process area scored: N (Not achieved), P (Partially), L (Largely), F (Fully)	Aggregated to Capability Level per process area
Report	Strengths, weaknesses, improvement actions	OEM uses this in supplier scorecards

Assessors use the “magic trick”: pick requirement REQ-GW-0142 at random. Can you show: origin (system req) → architecture decision → design doc → code commit → unit test → integration test → review sign-off → baseline tag? If any link is missing, SWE.1 or SUP.8 gets downgraded.

Auditors trace the chain from ticket to requirement to architecture to code to test evidence.

ASPICE vs. ISO 26262 Process Overlap

ISO 26262 Part 2 (management) and Part 6 (product development at software level) define safety-specific process requirements. ASPICE’s SWE process areas overlap significantly. Many OEMs accept ASPICE evidence as partial fulfillment of ISO 26262 process requirements, mapped via a compliance matrix. You don’t maintain two completely separate systems; you maintain one traceability chain that satisfies both, with safety-specific additions (FMEA links, safety case references, ASIL tags on requirements).

Why OEMs Require ASPICE From Tier-1 Suppliers

OEMs like VW, BMW, GM, Stellantis, and Hyundai don’t have enough engineers to review every supplier’s source code. Instead:

1. Scale. A single OEM program has 50+ Tier-1 suppliers. Process assessment scales; code review doesn’t.
2. Recall cost. A traceability gap during a field issue costs weeks. ASPICE evidence shortens root cause time.
3. Regulatory pressure. UNECE WP.29 (R155/R156) cybersecurity and software update regulations align with documented processes ASPICE supports.
4. Supplier comparison. Objective scorecard: Supplier A (SWE Level 3) vs. Supplier B (SWE Level 1) for the same RFQ.
5. Liability allocation. Contractual evidence that the supplier followed agreed process, important when accidents lead to litigation.

For you as a software engineer: ASPICE is why you can’t just push to main. You need a ticket, a review, a linked requirement, a test result, and a release note, even for a one-line VHAL property fix. Module 9.1 (ISO 26262) defines what safety evidence you need. Module 9.2 (ISO 21434) defines cybersecurity case artifacts. ASPICE is the conveyor belt that ensures those artifacts exist for every change. Module 8’s flash procedures depend on SUP.8 configuration management — you can’t flash what you can’t baseline. Your CI pipeline’s test gates are SWE.5/SWE.6 in action.

Bottom line

1. ASPICE = process maturity, not product correctness.
2. Levels 0–5. OEMs typically require Level 2–3 from Tier-1 suppliers.
3. SWE.1–SWE.6 map to the V-model; SUP.8/SUP.10 govern config and change control.
4. Audits trace random requirements through design, code, test, and release.
5. Complements ISO 26262/21434. Safety and security need disciplined process to scale.

Where You'll See This

Process pain you’ll encounter, and why it exists:

Your Grumble	ASPICE Process Behind It
“Why do I need a JIRA ticket for a one-line fix?”	SUP.10 Change Request Management
“Why can’t I merge without two reviewers?”	SWE.4/SWE.5 peer review evidence
“Why does QA need my test coverage report?”	SWE.5 Unit Verification metrics
“Why is the release tagged v2.3.1-rc4 not latest?”	SUP.8 Configuration Management baselines
“Why does the OEM want a traceability matrix?”	SWE.1 bidirectional requirements trace

Before an audit, teams run “assessor drills”: pick 5 random requirements and trace them end-to-end in under 30 minutes. If you can’t, fix the process gap before the auditor finds it. Keep your commit messages referencing ticket IDs. Future you (or the recall team) will thank you.

Check Your Understanding

1. What does ASPICE primarily assess?

A. Whether the vehicle's brake software executes correctly on a HIL rigB. The maturity and repeatability of software development processesC. The ASIL level of each ECU functionD. Cellular modem RF performance

2. What Capability Level is typically the minimum requirement in OEM contracts for Tier-1 suppliers?

A. Level 0 — IncompleteB. Level 1 — PerformedC. Level 2 — Managed (often Level 3 — Established)D. Level 5 — Innovating

3. During an ASPICE audit, an assessor randomly selects requirement REQ-GW-0142. What are they testing?

A. Whether the gateway compiles without warningsB. End-to-end traceability from requirement through design, code, test, and release evidenceC. The developer's typing speedD. Whether AAOS is the hypervisor host