What Is ASPICE? A Plain-Language Guide for Hardware and Embedded Teams

If you’ve entered the European automotive supply chain — or are trying to — you’ve almost certainly encountered ASPICE as a supplier qualification requirement. The acronym appears in statements of work, gets mentioned in kick-off meetings, and occasionally causes panic when an OEM announces an assessment date. Yet for engineers outside the core Tier 1 ecosystem, particularly those coming from aerospace, industrial, or North American automotive backgrounds, the framework remains strangely opaque.

This guide defines what ASPICE actually is, explains its structure in terms that make sense to practicing engineers, and covers what assessments look like from the inside. It also addresses how ASPICE intersects with ISO 26262, what Tier 1 suppliers actually demand of their Tier 2 and Tier 3 suppliers, and why requirements management is consistently the sharpest lens assessors use when evaluating a team’s real capability.

What ASPICE Is — and What It Is Not

Automotive SPICE (ASPICE) is a process assessment framework derived from the international standard ISO/IEC 33020, adapted specifically for the automotive domain by the AUTOSAR consortium and governed by the Automotive SIG. The current version is ASPICE 4.0, released in 2023.

The critical framing: ASPICE is not a product standard. It does not specify what your embedded software must do, what safety integrity level your hardware must achieve, or what architecture you must use. It is entirely about how you perform engineering work — whether your processes are defined, whether you execute them consistently, whether you measure them, and whether you improve them over time.

Assessors are not reviewing your product. They are reviewing your process discipline as evidence of whether your product development can be trusted to produce reliable outputs repeatedly and across programs.

This distinction matters enormously for how teams prepare.

The Process Reference Model: What Gets Assessed

ASPICE organizes engineering work into process areas grouped by domain. The most commonly assessed process areas for embedded and hardware teams are:

System Engineering (SYS)

  • SYS.1: Requirements Elicitation
  • SYS.2: System Requirements Analysis
  • SYS.3: System Architectural Design
  • SYS.4: System Integration and Integration Test
  • SYS.5: System Qualification Test

Software Engineering (SWE)

  • SWE.1: Software Requirements Analysis
  • SWE.2: Software Architectural Design
  • SWE.3: Software Detailed Design and Unit Construction
  • SWE.4: Software Unit Verification
  • SWE.5: Software Integration and Integration Test
  • SWE.6: Software Qualification Test

Supporting Processes (SUP)

  • SUP.8: Configuration Management
  • SUP.9: Problem Resolution Management
  • SUP.10: Change Request Management

Management Processes (MAN)

  • MAN.3: Project Management
  • MAN.5: Risk Management
  • MAN.6: Measurement

For a typical Tier 2 embedded software supplier being assessed by a Tier 1 customer, the SWE group plus SYS.1 and SYS.2 represent the primary scrutiny zone. Hardware-focused suppliers add SYS.3 through SYS.5 to that list.

Each process area has defined Base Practices (what you must do) and Work Products (what evidence must exist). Both are evaluated.

Capability Levels: The Actual Scoring System

ASPICE uses a 0–5 capability scale derived from the ISO/IEC 33020 measurement framework:

  • Level 0 — Incomplete: The process is not implemented or fails to achieve its purpose.
  • Level 1 — Performed: The process achieves its purpose, but with no particular discipline around how.
  • Level 2 — Managed: The process is planned, monitored, and adjusted. Work products are controlled.
  • Level 3 — Established: The process is based on a defined, tailored organizational standard. Process knowledge is transferable across projects.
  • Level 4 — Predictable: The process is quantitatively controlled. Variation is understood and managed statistically.
  • Level 5 — Innovating: Continuous improvement is driven by quantitative targets aligned to business goals.

In practice, Level 2 is the minimum acceptable rating for most Tier 1 qualification programs. Many OEM-driven programs targeting safety-critical systems now require Level 3 across SWE and SYS process areas. Levels 4 and 5 remain rare in production programs and are generally relevant only to OEM internal processes or research programs.

The jump from Level 1 to Level 2 is where most teams get stuck. Level 1 means your engineers are doing the right technical work — they understand requirements analysis, they write architecture documents. Level 2 means the work is planned in advance, executed against a plan, monitored for conformance, and the work products are configuration-managed. The difference is not technical skill. It is process discipline and evidence.

What Assessments Actually Look Like

ASPICE assessments are conducted by qualified assessors — either OEM-internal or contracted — using the standard interview-plus-evidence model.

A typical assessment for a mid-sized Tier 2 supplier runs two to four days on-site (or increasingly remote-hybrid). The structure follows this pattern:

Day 1: Opening meeting, process coverage mapping, identification of reference projects. Assessors select one or two active projects as the evidence base — they want to see real work, not demonstration artifacts.

Days 2–3: Process interviews. Assessors speak with engineers, leads, and managers directly involved in the reference projects. They ask how work gets done, then ask to see the evidence. The gap between what engineers describe and what the work products actually show is precisely what assessors are trained to find.

Day 4: Rating consolidation, findings discussion, closing presentation. Findings are organized by process area and capability level, with specific gaps called out as either weaknesses (addressable but present) or process attributes not satisfied (scored as a failed capability level for that attribute).

The closing presentation is not an argument. Assessors present findings; suppliers respond with planned improvement actions. The scores stand.

ASPICE and ISO 26262: Complementary, Not Redundant

A common source of confusion for teams new to the European automotive domain: ASPICE and ISO 26262 look superficially similar — both involve process rigor, work products, and external scrutiny. Engineers sometimes ask whether achieving one means they’ve addressed the other.

They do not overlap in that way.

ISO 26262 is a functional safety standard. It defines specific safety lifecycle activities, required analyses (FMEA, FTA, HARA), integrity levels (ASIL A through D), and what work must be done at each ASIL level to achieve a safety case for a specific product. It is outcome-oriented: a compliant safety case must exist for the specific item being developed.

ASPICE is a process capability framework. It defines how consistently you execute engineering processes — any engineering processes — and whether those processes are planned, disciplined, and based on organizational standards. It is practice-oriented: can you demonstrate repeatable, managed engineering work?

The practical intersection: ISO 26262 requires certain processes (requirements management, V&V, configuration management). ASPICE independently evaluates whether those processes are actually executed with discipline. A team can have ISO 26262-compliant work products that were assembled reactively and chaotically — ASPICE would reveal that at Level 1 or below in the process management attributes. Conversely, a team can have excellent ASPICE Level 3 scores in SWE but not yet have addressed ASIL decomposition or safety analysis — ISO 26262 compliance would still be absent.

For Tier 2 suppliers, the operational reality is this: ASPICE Level 2 across the primary SWE/SYS process areas is often a prerequisite for being permitted to develop ASIL-relevant components at all. OEMs and Tier 1s treat ASPICE scores as a proxy for whether a supplier’s development process can be trusted to produce evidence that supports the Tier 1’s own ISO 26262 safety case.

What Tier 1 Suppliers Actually Demand of Tier 2s

The requirements Tier 1 suppliers impose on their Tier 2 supply chain have tightened measurably over the 2023–2026 period, driven by OEM pressure following several high-profile ADAS component quality escapes and the expansion of ASPICE 4.0.

The pattern now common in supplier quality agreements:

  • Entry requirement: ASPICE Level 2 across SWE.1–SWE.6 and SYS.1–SYS.2 before production nomination
  • Ongoing requirement: Assessment every 18–24 months during active program; evidence of improvement actions tracked
  • Escalation requirement: Level 3 for SWE.1 (Software Requirements Analysis) and SYS.2 (System Requirements Analysis) for ASIL C/D-relevant development
  • Traceability evidence: Bidirectional coverage from customer requirements through system requirements, software requirements, architecture, design, test cases, and test results — reviewable on demand, not generated for the assessment

That last point is where the most friction occurs. Tier 1 program managers have begun requesting traceability artifacts mid-program, not just at assessment time. Suppliers who maintain traceability as a living practice handle these requests without disruption. Suppliers who treat it as an assessment-preparation activity spend days or weeks reconstructing coverage manually — and the reconstructed artifacts rarely hold up under scrutiny.

Requirements Management as the Sharpest Assessor Lens

Ask any experienced ASPICE assessor which process area most reliably reveals a team’s real capability level, and the answer is almost always requirements: SYS.2 and SWE.1.

The reason is structural. Requirements management is upstream of everything. If requirements are informal, ambiguous, or untraceable, every downstream work product — architecture, design, test cases — inherits that informality. Assessors use requirements artifacts as a leading indicator of overall process maturity.

What assessors look for in SWE.1 and SYS.2:

  • Are requirements uniquely identified and version-controlled?
  • Is each requirement verifiable — stated in a form that can be objectively tested?
  • Is bidirectional traceability maintained between system requirements and software requirements?
  • Are requirement changes managed through a defined change process, with impact analysis documented?
  • Are requirement review records available, with specific criteria and dispositions recorded?

Teams that maintain requirements in shared documents — Word files, Confluence pages, spreadsheet-based RTMs — almost universally score Level 1 on process management attributes in these areas. The work product exists; the management discipline does not.

How Modern Tools Support ASPICE Performance

The tooling dimension of ASPICE preparation has shifted in the last two years. Traditional requirements management platforms — IBM DOORS, DOORS Next, Jama Connect, Polarion, Codebeamer — were built around document or requirement databases with traceability link management. They can support ASPICE-compliant processes when implemented and governed correctly. The challenge is that correct implementation requires significant configuration effort, and maintaining discipline across a team requires training and enforcement that many Tier 2 suppliers lack the process infrastructure to sustain.

A newer approach to this problem is represented by platforms like Flow Engineering (flowengineering.com), which structures requirements and traceability as a graph-native model rather than as a linked document database. The practical difference for ASPICE preparation: traceability is not an artifact you create — it is the structure through which you record all engineering decisions. Coverage gaps are visible continuously, not discovered during pre-assessment reviews.

For teams building bidirectional traceability from customer requirements through system requirements, software requirements, architecture elements, and test cases, Flow Engineering’s graph model maps directly to the traceability evidence ASPICE assessors request in SYS.2, SWE.1, and SWE.6. The structure isn’t imposed on top of an existing document process; it is the process.

Flow Engineering is intentionally focused on requirements, traceability, and connected systems models. Teams that need heavy FMEA workflow management, classical gate-based document approval chains, or deep ERP integration should evaluate whether they need supplemental tools alongside it. That focus is a deliberate design choice, not a gap — it means the core function is executed without the compromise that comes from bolting requirements management onto a configuration management or PLM platform.

Practical Starting Points for Teams New to ASPICE

If you are preparing for a first ASPICE assessment, or closing gaps after a previous one, the highest-leverage actions in roughly the order to take them:

1. Select a reference project now. Assessors will assess real work. Identify an active program that represents your typical development process and ensure its artifacts are current and accessible.

2. Map your existing work products to ASPICE base practices. For each SWE and SYS process area in scope, identify what evidence you have and where the gaps are. Do this before the assessor does.

3. Establish bidirectional traceability on your reference project. This is the single activity most likely to improve scores across SYS.2, SWE.1, and SWE.6 simultaneously. If you’re doing this manually, use a structured template. If you’re investing in tooling, choose something that makes traceability the native structure rather than an added-on report.

4. Document your process, not just your products. Level 2 requires evidence that work was planned and monitored. Sprint plans, review meeting records, configuration management logs — these are process evidence. Ensure they exist and are retrievable.

5. Define your change management process and use it. Unmanaged requirement changes are one of the most common findings in SWE.1 and SUP.10. A simple, consistently followed process beats a sophisticated one that’s ignored.

6. Treat assessor preparation as gap closure, not artifact generation. Artifacts manufactured specifically for an assessment are identifiable and do not survive probing interviews. The preparation that works is the preparation that makes your actual engineering process more disciplined.

Honest Assessment

ASPICE is genuinely rigorous, and the compliance burden it places on Tier 2 suppliers is real. For a fifty-person embedded team being asked to achieve Level 2 across twelve process areas while managing active program deliverables, the overhead is significant.

That said, the discipline ASPICE demands — planned work, managed artifacts, bidirectional traceability, defined change processes — is not bureaucratic theater. Teams that operate this way produce fewer integration failures, handle requirement changes with less rework, and generate the kind of traceable evidence that supports root cause analysis when defects escape. The compliance process and the engineering quality process are, when implemented well, the same process.

The suppliers who struggle with ASPICE are not typically the ones who lack technical competence. They are the ones who have normalized informal, documentation-light development practices and are now being asked to reconstruct the evidence for work that was never tracked systematically. Starting from that position, under assessment pressure, is genuinely hard.

Starting from that position before the assessment pressure arrives is a different problem — one with a tractable solution.