Derived from the ISO/IEC 15504 SPICE framework, Automotive SPICE, known as ASPICE, provides a structured process assessment framework to assess how well engineering and management processes are defined, executed, and controlled across the automotive supply chain.
Traceability, therefore, has a key role to play in the ASPICE process. Over the years, multiple publications and guidelines have described traceability as “one of the most important concepts in ASPICE”. They point out that “the changes made to the work products must be recordable, verifiable, and traceable – so does the flow between the requirements, implementation, and test cases”. When traceability is incomplete, assessments fail or end up at a lower capability level than expected.
In this article, we explore ASPICE and its different aspects and why traceability is fundamental to the framework. We also clarify how assessors interpret traceability when evaluating process outcomes.
SPICE or Software Process Improvement and Capability DEtermination is a framework created by ISO and IEC to assess and improve software development processes. Automotive SPICE adapts this framework to the automotive field. ASPICE is now a maturity model used to assess the development processes for electronic and software-based systems.
APSICE combines:
| ℹ️ Please note that ASPICE is not a tool or a development method. It is a model used for OEMs, suppliers, and assessors to evaluate how effectively engineering processes are defined, executed, and controlled. |
The term “process” refers to a structured set of activities that must be achieved to deliver work products. In ASPICE, each process specifies a purpose, expected outcomes, and the evidence needed to demonstrate that these outcomes have been achieved. Processes are organized by domains. For example, SYS.x covers System Engineering: SYS.1 refers to Requirements Elicitation, SYS.2 for System Requirements Analysis, etc. Lower numbers correspond to early lifecycle activities, while higher ones correspond to downstream activities such as architectural design, integration, and qualification (See Fig 1).
ASPICE focuses on outcomes and evidence. It does not mandate any specific tools, programming languages, or development of lifecycle models.
Fig. 1 – ASPICE System Engineering Process Structure.
ASPICE defines six capability (or maturity) levels for each process. These levels evaluate how far a process is implemented, managed, and improved.
Fig. 2 – The Maturity Levels of ASPICE
Modern vehicles rely on software for many critical functions. An issue in an ECU can trigger costly recalls, expose gaps in regulatory compliance, and affect brand reputation. These risks increase as systems become more complex and as more suppliers contribute to the overall vehicle architecture.
ASPICE helps address these risks by providing OEMs and suppliers with a common framework for evaluating process quality and maturity. ASPICE also contributes to reducing systematic defects by defining structured processes, all supported by traceability to ensure these activities remain consistent and complete.
Some OEMs and Tier-1 suppliers also rely on ASPICE capability levels as part of their supplier selection process. Level 2 is often considered the minimum expectation, and some automobile manufacturers expect their suppliers to achieve Level 3.
|
For engineering teams, this also brings many concrete benefits:
|
In the context of Automotive SPICE, traceability can be defined as the existence of meaningful references or links between work products (requirements, design elements, code, test artifacts, change requests, etc.).
In concrete terms, this means that engineering teams must be able to demonstrate the path from a stakeholder's request to the system requirements, software requirements, design elements, implementation, and the corresponding tests.
They must also keep these links up to date as the project evolves, so the traceability remains accurate even after changes.
ASPICE assessors look for objective evidence that process outcomes are achieved. And traceability is one of the primary ways to demonstrate this. It provides evidence that requirements are implemented and verified.
Weak or incomplete traceability leads to lower capability ratings, for instance, Level 1 instead of Level 2. Most often, this is due to the following factors:
Traceability also strengthens several ASPICE processes at once: from requirements and design to testing, change management, and configuration control.
Automotive SPICE relies on the V-Model, a model demanding that system requirements be decomposed into software requirements (See Fig.1 & 3). This mechanism facilitates the creation of traceable links with implementation tasks and ensures that all the requirements are well addressed during the development phase.
For the recall, the left side covers stakeholders, system, and software requirements, and the corresponding architecture and design. The right side covers integration, verification, and validation activities.
Fig. 3 – The V-Model
Within that structure:
|
ASPICE does not request to trace “everything to everything”. Instead, it expects a level of traceability that genuinely supports completeness checks, impact analysis, and audits. It becomes a strong assessment when the right balance is struck and when we focus on the most relevant links and keep them up to date. And to do this, the use of tools that integrate traceability directly into daily work is highly recommended. |
ASPICE assessments are not satisfied by well-written process documentation alone. Assessors look for concrete evidence that engineering decisions are consistent, justified, and verifiable over time.
Traceability is the mechanism that makes this demonstrable. Well-implemented traceability allows assessors to follow the engineering logic of a project, including:
What matters is not the number of traceability links, but whether those links enable completeness checks, reliable impact analysis, and confidence in the validity of the resulting evidence.
When traceability becomes an integral part of the engineering work, rather than evidence gathered for an audit, it changes how teams operate. Inconsistencies surface earlier, trade-offs are made with better context, and assessment discussions focus on engineering rationale instead of missing or reconstructed evidence.
ASPICE does not mandate traceability as a standalone process, but it is implicitly required across many processes. Traceability is one of the primary ways assessors verify that process outcomes are actually achieved.
No. ASPICE is tool-agnostic. It evaluates outcomes and evidence, not tooling choices. However, assessors expect traceability to be consistent, up to date, and maintainable, which is often difficult to achieve with manual approaches alone.
No. While traceability is reviewed during assessments, it reflects day-to-day engineering discipline. Weak traceability often reveals deeper issues such as unclear requirement ownership, inconsistent design decisions, or poor change impact analysis.
ASPICE does not expect “everything to be traced to everything.” It expects traceability at a level that supports completeness checks, impact analysis, and verification. Excessive or poorly justified links can be as problematic as missing ones.
Our solutions help engineering teams implement ASPICE-compliant traceability without disrupting existing and legacy toolchains. By linking requirements, models, tests, and change artifacts across tools, we make traceability consistent and verifiable over time.
Your teams can produce reliable assessment evidence directly from live engineering information, rather than reconstructing traceability links before an audit. The result is traceability that supports both daily engineering tasks and ASPICE assessment with confidence.
➡️ Do you have questions about implementing traceability links that stay valid and reliable throughout your entire project? We'd love to discuss your context.