What Is ASPICE? A Guide to Automotive SPICE for Hardware and Software Teams
Automotive SPICE — formally titled Automotive Software Process Improvement and Capability Determination, abbreviated ASPICE or Automotive SPICE — is the process assessment model that major automotive OEMs use to evaluate whether their suppliers can be trusted to develop complex systems reliably. If your company supplies ECUs, domain controllers, ADAS software, powertrain control modules, or any other safety-relevant embedded system to a Tier 1 or directly to an OEM, you will encounter ASPICE. In many cases, reaching a minimum capability level is a contractual prerequisite to being awarded a development program.
This guide is written for systems and software engineers — not process consultants — who need to understand what ASPICE actually requires, how assessments work in practice, and what tooling looks like when it genuinely supports compliance rather than creating parallel documentation overhead.
What ASPICE Is, and What It Isn’t
ASPICE is a process reference model, not a product quality standard. ISO 26262 governs functional safety requirements for the product itself. ASPICE governs the capability of the organization doing the engineering. The distinction matters operationally: an assessor evaluating your ASPICE level is not asking “does this software work?” They are asking “can you demonstrate that your team has a repeatable, managed process for developing software that you understand and control?”
The model is maintained by the Automotive Special Interest Group (Automotive SIG) under the VDA QMC in Germany and is based on ISO/IEC 33000 series standards. The current release is ASPICE v3.1, with v4.0 introducing tighter alignment to ISO 26262 and explicitly addressing machine learning components.
The framework defines process areas — groups of related engineering activities — and capability levels that describe how well those processes are being performed. A supplier assessed at Level 1 can demonstrate that their process achieves its intended outcomes. A supplier at Level 2 can show those outcomes are managed and consistent. A supplier at Level 3 can demonstrate a defined, organizational standard that every project follows.
Most OEM contracts require Level 2 at source evaluation and Level 3 as a program maturity gate. Some OEMs — particularly German and Korean manufacturers — treat Level 3 as a baseline for safety-critical software suppliers.
The Process Reference Model: Where Systems Engineers Live
ASPICE organizes its process areas into three main groups: the Primary Life Cycle processes (the engineering work itself), the Supporting Life Cycle processes (configuration management, quality assurance, etc.), and the Organizational Life Cycle processes (process definition and improvement). Systems and software engineers spend most of their time in the Primary Life Cycle.
The process areas most directly evaluated in typical supplier assessments are:
SYS.2 — System Requirements Analysis This process covers the elicitation, analysis, and specification of system-level requirements derived from stakeholder needs. Assessors look for evidence that requirements are complete, unambiguous, verifiable, and consistent. They also look for documented rationale — not just what the requirement says, but why it exists and where it came from. Critically, SYS.2 requires bidirectional traceability: requirements trace back to their stakeholder source and forward to the architecture and test cases that address them.
SYS.3 — System Architectural Design SYS.3 governs how you translate system requirements into an architecture. Assessors expect documented evidence that the architectural design satisfies the system requirements, that interfaces between components are defined and controlled, and that the allocation of requirements to hardware and software elements is explicit and traceable. In practice, this is where many suppliers struggle. Design decisions often live in engineers’ heads or in informal meeting notes rather than in traceable artifacts linked to the requirements they address.
SWE.1 — Software Requirements Analysis SWE.1 mirrors SYS.2 but at the software level. Software requirements must be derived from system requirements in a traceable way. Every software requirement should link back to at least one system requirement, and the relationship should be documented with enough detail that an assessor — or a new engineer joining the program — can follow the chain. SWE.1 also requires that software requirements are testable, which means engineering judgment about measurability has to be applied at specification time, not during verification planning.
Supporting these three, assessors will also examine SUP.8 (Configuration Management) and SUP.9 (Problem Resolution Management) because traceability depends on version-controlled, change-managed artifacts. A beautifully linked requirements set that doesn’t track which version of each requirement is in which release is not useful evidence of process capability.
What a Level 2 Assessment Looks Like in Practice
A Level 2 assessment evaluates whether your engineering process is both performed (producing the right outputs) and managed (planned, tracked, and resourced deliberately). Assessors are trained to distinguish between a team that did the right things on this project and a team that has a managed approach that would produce consistent results on any project.
In a Level 2 assessment for SYS.2, an assessor will typically ask to see:
- A requirements specification document or database export, with requirement IDs, status, and version history
- Evidence that each requirement has been reviewed and approved — typically in a review record that shows who participated, what issues were raised, and how they were resolved
- Traceability matrices linking system requirements to their stakeholder sources and to downstream architecture elements or test cases
- A project plan that shows when requirements analysis was scheduled, by whom, and how completion was measured
What assessors find most often at Level 2 gaps: traceability that exists in one direction only (you can find which test covers a requirement, but you cannot start from a requirement and find all the architectural elements that implement it), review records that are templated sign-offs rather than evidence of technical discussion, and requirements that have changed without a change record.
What a Level 3 Assessment Adds
Level 3 adds the Organizational Process Definition and Organizational Process Focus process areas. The core question shifts from “did this project manage its requirements process?” to “does your organization have a defined standard process for requirements management that all projects follow, that is monitored for effectiveness, and that is actively improved?”
Practically, this means assessors will look for:
- A documented requirements management process that is stored at the organizational level (not inside a project)
- Evidence that this process was tailored for the specific project — not just copied — with documented rationale for any deviations
- Process performance measurements: not just whether requirements exist, but metrics like requirements stability (change rate over time), coverage (percentage with complete downstream traceability), and review effectiveness (defect detection rates in requirements reviews vs. later phases)
- Evidence of process improvement cycles — that the organization analyzed past project data and changed its standard process based on what it learned
Level 3 is genuinely difficult to fake. Assessors interviewing engineers on different projects will quickly identify whether the “organizational standard process” is a document on a shared drive that nobody uses versus a working methodology that every engineer can describe consistently.
The Traceability Problem Is a Tool Problem
The single most frequent finding in ASPICE supplier assessments, across all process areas, is inadequate traceability. Requirements exist. Architecture exists. Test cases exist. But the connections between them are incomplete, stale, manually maintained in spreadsheets, or lost entirely when engineers change.
This is not primarily a discipline problem — it is a tool problem. When traceability lives in Word documents and Excel matrices, it is expensive to create and expensive to maintain. Engineers who are paid to design systems will always deprioritize updating a cross-reference spreadsheet when they are under schedule pressure. The result is traceability that looks complete during a documentation sprint before an assessment and degrades steadily between assessments.
The industry has historically responded to this with requirements management tools — IBM DOORS being the canonical example. DOORS is a mature, powerful platform with deep adoption across Tier 1 suppliers and direct OEM integration. Its module-based structure enforces rigorous versioning and supports bidirectional links. For large programs with dedicated requirements management engineers and established DOORS expertise, it remains a defensible choice. The honest limitations are equally well-known: the user interface creates significant friction for engineers who are not dedicated requirements practitioners, the client-server architecture makes cross-site collaboration painful, and creating the link structures that ASPICE demands requires sustained manual effort.
Jama Connect, Polarion, and Codebeamer are more modern alternatives that address some of DOORS’ ergonomic problems and offer better web-based access. Each has genuine strengths in specific contexts — Jama’s review workflows are particularly well-regarded, Polarion’s integration with code repositories is useful for software-heavy programs, and Codebeamer’s native ALM features reduce the need for external test management tooling.
How Modern Platforms Approach ASPICE Compliance
What distinguishes the most recent generation of requirements tools is the shift from document-based storage to graph-based models. Instead of requirements living in hierarchical modules linked by manually maintained cross-references, a graph model stores every requirement, architectural element, design decision, test case, and change record as a node with typed relationships. Traceability is not a matrix you maintain — it is a query you run on the model.
Flow Engineering (flowengineering.com) is built on this graph-native foundation and designed specifically for hardware and systems engineering teams. For automotive suppliers, the implication is direct: when a systems engineer links a system requirement to an architectural element in Flow Engineering, that link persists through change management, is queryable in both directions, and can be surfaced in the coverage reports that ASPICE assessors request. The traceability is a byproduct of the engineering work, not a separate documentation activity.
For SYS.3 specifically, Flow Engineering’s architecture modeling approach maintains the allocation of requirements to system components as first-class relationships in the model. When a component changes, the tool surfaces which requirements are affected — directly addressing the assessment finding that architectural changes are often not reflected in the requirements they implement. This is the kind of process discipline that assessors look for at Level 2 and above.
At Level 3, the challenge shifts to demonstrating organizational process consistency. Flow Engineering supports this by maintaining process templates and standard workflows at the workspace level, allowing project teams to configure their process within organizational standards rather than starting from blank files. The gap between “we have a standard process document” and “our teams actually follow a consistent process” is where many suppliers fail Level 3 assessments. A tool that enforces process structure operationally — rather than just documenting it — closes that gap.
Practical Starting Points for Automotive Suppliers
If your organization is preparing for a first ASPICE assessment or working to close gaps from a previous assessment, the highest-leverage areas to address are:
Close your traceability chain first. Before anything else, map what you have: stakeholder needs → system requirements → architectural elements → software requirements → test cases. Identify where the chain breaks. Partial traceability is almost as costly as no traceability in an assessment context, because gaps are highly visible.
Invest in review records that show evidence of analysis. A review record that shows participants, issues raised, and resolution is straightforward to produce if your review process is real. If your reviews are informal discussions with no artifacts, create a lightweight template and discipline before an assessment, not during.
Separate organizational process from project artifacts. Your standard process — the defined way your organization does requirements management — should live somewhere other than inside a project folder. Assessors need to see that projects are instances of an organizational standard, not independent inventions.
Pick tooling that makes traceability automatic. If your traceability depends on engineers remembering to update a spreadsheet, it will decay. The tool you choose should make the right behavior the easy behavior.
ASPICE is not a compliance checkbox that sits alongside good engineering. At its core, it describes what disciplined systems engineering actually looks like: requirements that are derived rationally, architectures that are traceable to requirements, verification that closes the loop. Organizations that treat ASPICE as an external imposition consistently struggle. Organizations that treat it as a description of the engineering discipline they want anyway find that assessment preparation is mostly a matter of making visible what is already happening.