What Is ASPICE (Automotive SPICE)? A Primer for Hardware Engineering Teams
Automotive SPICE (ASPICE) has moved from a niche OEM preference to a standard contractual requirement for Tier 1 and Tier 2 suppliers across Europe, Asia, and increasingly North America. If your team develops embedded controllers, sensor systems, power electronics, or any safety-relevant hardware with software content, your customer is likely already measuring you against it—or will be within the next product cycle.
This article explains what ASPICE actually is, what the capability levels mean in practice, which process areas matter most for systems and requirements engineering, and why demonstrating compliance has become operationally expensive for teams still managing requirements in documents.
What ASPICE Is—and What It Isn’t
ASPICE stands for Automotive Software Process Improvement and Capability dEtermination. The framework is owned by the Automotive Special Interest Group (Automotive SIG) and derives from ISO/IEC 33000, the international standard family for process assessment.
The critical distinction: ASPICE is a process assessment framework, not a product certification. Passing an ASPICE assessment does not mean your product is safe or correct. It means your organization demonstrates disciplined, repeatable processes for engineering, managing, and verifying that product. OEMs use ASPICE scores as a proxy for supplier risk—a Capability Level 1 supplier is an execution risk; a Capability Level 3 supplier is a manageable partner.
ASPICE defines a two-dimensional model:
Process dimension: A set of process areas organized into engineering, supporting, and management categories. Each process area defines specific outcomes and base practices that must be demonstrated.
Capability dimension: Six levels (0–5) that describe how systematically and manageably a process is performed. The level is not self-declared—it is assessed by a qualified assessor through document review, interviews, and artifact inspection.
In practice, most automotive supply contracts specify a target capability level, and that target is almost universally CL2 or CL3.
The Capability Levels, Defined Plainly
Level 0 — Incomplete: The process is not performed or fails to achieve its purpose. No meaningful evidence exists.
Level 1 — Performed: The process achieves its intended outcomes but without consistent management. Work products exist but may not be formally controlled. Many supplier organizations operate at this level without realizing it.
Level 2 — Managed: The process is planned, monitored, and adjusted. Work products are version-controlled. Resources are tracked. This is the minimum bar most Tier 1 OEM contracts now specify for new platform development.
Level 3 — Established: The process is defined, documented, and deployed consistently across projects using a standard organizational process. Tailoring is controlled. This level is required for suppliers working on safety-critical systems or seeking preferred supplier status with major OEMs.
Levels 4 and 5 address quantitative management and continuous optimization. These are rare in practice outside of top-tier Tier 1 suppliers and OEM internal processes, and they’re beyond the scope of what most engineering teams need to target.
The jump from CL1 to CL2 is largely about documentation discipline and change management. The jump from CL2 to CL3 requires organizational process definition—not just individual project rigor.
The Process Areas That Matter Most for Systems Engineering Teams
ASPICE organizes process areas into an “Engineering” group, a “Supporting” group, and a “Management” group. For hardware and embedded systems teams, three engineering process areas generate the most assessment findings and compliance burden.
SYS.2 — System Requirements Analysis
SYS.2 covers how stakeholder requirements are transformed into system-level requirements. ASPICE assessors look for:
- A consistent mechanism for eliciting and capturing stakeholder needs
- Transformation of those needs into verifiable, unambiguous system requirements
- Bidirectional traceability between stakeholder requirements and system requirements
- Evidence that system requirements have been analyzed for consistency, completeness, and feasibility
- Change management: when a stakeholder requirement changes, the impact on derived system requirements is tracked and communicated
The failure mode here is almost always the same: teams have requirements, but they exist in disconnected documents or spreadsheets with no enforced relationship between stakeholder needs and derived system specs. An assessor asks “show me the impact if this stakeholder requirement changes” and the honest answer is “we’d have to manually search across five documents.”
SWE.1 — Software Requirements Analysis
SWE.1 mirrors SYS.2 but at the software level. System requirements that have software content must be further decomposed into software requirements. The traceability obligation extends downward: each software requirement must trace to a system requirement, and each system requirement that allocates software behavior must trace to software requirements that satisfy it.
The practical challenge at SWE.1 is allocation. In hardware/software co-development, the boundary between what the hardware specification handles and what the software requirement handles is often negotiated during design, not fixed at the start. ASPICE doesn’t prohibit that negotiation—it requires that the negotiation be documented and traceable.
SWE.2 — Software Architectural Design
SWE.2 requires that software requirements are refined into an architectural design, and that every software requirement is demonstrably allocated to a software component. The traceability chain extends: stakeholder need → system requirement → software requirement → architectural component. And it must be traversable in both directions.
This is where the term “bidirectional traceability” becomes concrete for most engineers. It’s not enough to show that a component implements requirements. You must also be able to show, for any given requirement, which component implements it and how it will be verified. Assessors will explicitly walk this chain during interviews.
Why Tier 1 and Tier 2 Compliance Requirements Are Intensifying
Three forces are driving increased ASPICE enforcement across the supply chain.
OEM liability redistribution. As vehicles become software-defined, OEMs are managing functional safety (ISO 26262) and cybersecurity (ISO/SAE 21434) obligations that cascade directly into supplier contracts. ASPICE capability is increasingly used as a contractual proxy for a supplier’s ability to manage safety-relevant work products with the rigor those standards require.
Tier 1 pass-through requirements. Tier 1 suppliers who have achieved CL3 on their own processes are now requiring the same from their Tier 2 component suppliers. A Tier 1 cannot maintain their ASPICE compliance posture if their critical sub-suppliers are operating at CL1 with undisciplined change management.
Audit frequency increasing. Several large German and Japanese OEMs now require annual ASPICE assessments for suppliers working on next-generation platform architectures, rather than the historical per-program approach. This means compliance is no longer something you demonstrate once at program launch—it has to be a continuous operational state.
For hardware teams specifically, the increased scrutiny on SYS.2 is notable. Requirements and systems engineering processes that were historically evaluated lightly (because the focus was on SWE.1/SWE.2 software process) are now receiving full assessor attention, particularly on mixed hardware/software systems like ADAS sensors, battery management systems, and domain controllers.
How Modern Requirements Platforms Support ASPICE Compliance
The manual approach to ASPICE evidence—maintaining a requirements traceability matrix (RTM) in Excel, linking documents with hyperlinks, maintaining a change log in a shared folder—fails at CL2 and becomes untenable at CL3. The RTM goes stale, links break, change impacts are missed, and the audit preparation sprint in the weeks before an assessment consumes engineer-weeks of effort that produces evidence of what the process should have been, not what it was.
ASPICE assessors are experienced enough to recognize retrospective documentation, and the CL2 attribute PA 2.2 specifically requires work products to be “identified, defined, and controlled” throughout the process—not reconstructed before the audit.
Modern requirements platforms address this structurally by making traceability continuous rather than periodic.
Graph-Based Traceability vs. Document-Based Linking
ASPICE’s traceability requirements map naturally to a graph: requirements are nodes, and the relationships between stakeholder needs, system requirements, software requirements, design elements, and test cases are typed edges. When a requirement changes, the graph makes impact propagation computable—you can immediately see which downstream artifacts are affected.
Document-based tools force traceability to be represented as text references or matrix entries. These are inherently brittle—they don’t enforce relationship types, they don’t propagate change alerts, and they can’t generate a coverage report without manual audit.
Flow Engineering is built on this graph model. Requirements, subsystems, interfaces, and verification items are all nodes in a connected model, and relationships between them are first-class objects with type and direction. When a system requirement changes, the platform surfaces which downstream software requirements, design elements, and test cases have an unresolved impact—which is exactly the change impact analysis artifact an ASPICE assessor asks for at SYS.2 and SWE.1.
Bidirectionality as a Query, Not a Document
One of the most time-consuming aspects of ASPICE preparation under document-based workflows is constructing bidirectional traceability views. You need to show, from a test case, that you can trace back to the requirement it verifies, and from that requirement, to the stakeholder need it satisfies. You also need to show coverage—that every requirement has a test case, and every test case traces to a requirement.
Flow Engineering generates these views on demand as live queries against the current model state. A bidirectional traceability report is not a document you maintain—it is a read-out of the graph at a point in time, and it is always current. This matters for continuous compliance: the traceability evidence available on assessment day reflects your actual process, not a reconstruction of it.
Change Management With Audit Trail
CL2’s PA 2.2 attribute requires configuration management of work products. CL3 requires that changes to the standard process are controlled. Both require an audit trail: who changed what, when, and why.
Modern platforms maintain this automatically. Flow Engineering records every change to requirements, relationships, and model structure with user identity and timestamp. Change rationale can be attached at the point of change rather than entered retroactively into a separate change log. This is the difference between evidence that is generated as a natural byproduct of working in the tool and evidence that is assembled manually before an audit.
Flow Engineering is designed for hardware and systems engineering teams specifically, which means the process model it supports aligns with how systems engineers actually work—allocating requirements to subsystems, managing interfaces between hardware and software, tracking requirement status through design phases. Teams working primarily on pure software development or document-intensive regulatory submissions may find purpose-built ASPICE compliance tools or established platforms like Jama Connect or IBM DOORS Next better suited to their workflow. Flow Engineering’s focus is on model-connected, graph-based systems engineering rather than regulatory document management.
Practical Starting Points for Teams Preparing for ASPICE Assessment
If your organization is preparing for its first formal ASPICE assessment, or working to move from CL1 to CL2, the highest-leverage changes are almost never about buying new tools first.
Establish requirement types and relationships explicitly. Before an assessment, define in writing what a “stakeholder requirement” is, what a “system requirement” is, and what types of relationships you recognize between them. This is the foundation of SYS.2 evidence.
Make traceability continuous, not periodic. The RTM that gets updated before an audit is not evidence of CL2 management. Traceability needs to be a live artifact, maintained as requirements are created and modified.
Document change impact, not just change history. Version history tells assessors that you controlled your work products. Change impact analysis tells them that you managed the process. These are different artifacts.
Align your tool to your process, not vice versa. If you adopt a requirements platform specifically for ASPICE, configure it to reflect your defined process (tailored from the ASPICE process reference model) rather than the platform’s default workflow. Assessors are evaluating whether you perform your defined process—if your defined process doesn’t match what the tool enforces, the evidence is inconsistent.
ASPICE compliance is achievable for most hardware engineering teams without organizational transformation. What it requires is that requirements and traceability are treated as engineering artifacts—not administrative overhead—from the start of a program, not as retrospective documentation assembled for an audit.