The Framework Behind Every Supplier Qualification Conversation

When a Tier 1 supplier enters contract negotiations with an OEM for an electronic control unit, a powertrain module, or an ADAS perception system, one document category appears on the due diligence checklist almost without exception: the ASPICE assessment report. Before a single line of production code is written, the OEM wants to know whether the supplier’s engineering processes are mature enough to be trusted with the program.

Automotive SPICE — formally Automotive Software Process Improvement and Capability dEtermination, abbreviated ASPICE — is the process assessment framework that answers that question. It was developed under the auspices of the Automotive SIG within the SPICE User Group, originally derived from ISO/IEC 15504, and has since been aligned with ISO/IEC 33000. Version 4.0, released in 2023, extended coverage explicitly to systems engineering processes and reflects the increasing complexity of modern vehicle electronics.

Understanding ASPICE is not optional for automotive software and systems engineers. It shapes how programs are structured, how reviews are conducted, and — critically — what evidence your team must produce at every stage of development.

Capability Levels: The 0–5 Scale

ASPICE measures process capability at six levels. The levels are cumulative: achieving Level 2 requires satisfying all Level 1 criteria, and so on.

Level 0 — Incomplete. The process is not implemented or fails to achieve its purpose. No consistent outputs exist.

Level 1 — Performed. The process achieves its intended purpose. Work products are produced, but there is no systematic management of how the work gets done. Many supplier development teams operate here without realizing it.

Level 2 — Managed. The process is planned, monitored, and adjusted. Work products are appropriately controlled and meet defined requirements. This is the minimum threshold most OEMs require before nominating a supplier for a new program.

Level 3 — Established. The process is implemented using a defined, tailored process drawn from organizational standards. Teams follow documented procedures rather than improvising per-project. OEMs developing next-generation safety-critical systems often require Level 3 for critical process areas.

Level 4 — Predictable. The process operates within defined limits. Quantitative management is in place; process performance is measured and controlled statistically.

Level 5 — Innovating. The process is continuously improved to meet current and projected business goals. Defect causes are analyzed and eliminated systematically.

In practice, the automotive industry concentrates on Levels 1 through 3. Level 4 and Level 5 are rare outside the most mature suppliers, and OEM contracts rarely specify them. The real competitive threshold is the distance between Level 1 and Level 3 — the difference between a team that produces results and a team that produces results reliably and repeatably.

The Key Process Groups: SYS, SWE, MAN, SUP

ASPICE organizes its process reference model into primary life cycle processes and supporting processes. Four groups dominate supplier assessments.

SYS — System Engineering Processes

The SYS group covers the engineering work at the system level, from understanding what stakeholders need through validating that the delivered system meets those needs.

  • SYS.1 — Requirements Elicitation: Gathering, documenting, and agreeing on stakeholder requirements. This process asks: do you have a systematic method for capturing what customers and end users actually need?
  • SYS.2 — System Requirements Analysis: Transforming stakeholder requirements into a complete, consistent, and verifiable set of system requirements. Bidirectional traceability between stakeholder requirements and system requirements is a core output.
  • SYS.3 — System Architectural Design: Defining the system architecture, allocating system requirements to hardware and software elements, and producing interface definitions. Traceability from system requirements to architectural elements is mandatory evidence.
  • SYS.4 — System Integration and Integration Testing: Planning and executing integration of system components and verifying interfaces.
  • SYS.5 — System Qualification Testing: Verifying the complete system against system requirements under representative conditions.

SWE — Software Engineering Processes

The SWE group mirrors the SYS group at the software level.

  • SWE.1 — Software Requirements Analysis: Derives software requirements from system requirements allocated to the software element.
  • SWE.2 — Software Architectural Design: Defines software architecture and allocates software requirements to components.
  • SWE.3 — Software Detailed Design and Unit Construction: Detailed design and coding.
  • SWE.4 — Software Unit Verification: Static analysis, code reviews, unit testing.
  • SWE.5 — Software Integration and Integration Testing: Integration of software components.
  • SWE.6 — Software Qualification Testing: Verification of the software element against software requirements.

MAN — Management Processes

  • MAN.3 — Project Management: Planning, monitoring, and controlling projects.
  • MAN.5 — Risk Management: Identifying, analyzing, and treating project and technical risks.
  • MAN.6 — Measurement: Defining and collecting measures to support management decisions.

SUP — Supporting Processes

  • SUP.1 — Quality Assurance: Ensuring processes and work products conform to plans and standards.
  • SUP.8 — Configuration Management: Controlling changes to work products and maintaining integrity.
  • SUP.9 — Problem Resolution Management: Recording, analyzing, and resolving defects and problems.
  • SUP.10 — Change Request Management: Managing changes to baselined work products.

An ASPICE assessment evaluates each of these process areas independently. A supplier might achieve Level 3 in SWE.1 but only Level 1 in SUP.8 — and that gap has contractual consequences.

How OEMs Use ASPICE Assessments

OEMs use ASPICE in three distinct ways across the supplier lifecycle.

Supplier qualification. Before awarding a contract, OEMs require a baseline assessment — either self-assessed or conducted by a licensed ASPICE assessor. The assessment report documents current capability levels across the relevant process areas. Gaps become contractual remediation items before program start.

Program monitoring. During development, OEMs conduct surveillance assessments at major milestones. A supplier that entered the program at Level 2 is expected to demonstrate progress toward Level 3 by specific gates. Regression — dropping from Level 2 to Level 1 under program pressure — triggers escalation.

Tier 2 pass-through requirements. Tier 1 suppliers increasingly flow ASPICE requirements down to their Tier 2 suppliers. If your electronics subcontractor cannot demonstrate Level 2 in SWE processes, you carry the liability. This has created an entire ecosystem of ASPICE consulting and tooling at the Tier 2 level.

The most important practical implication: ASPICE assessors do not accept verbal assurances. They examine work products. They read requirements documents, trace links between artifacts, review change histories, and interview engineers. The evidence must exist and must be navigable.

ASPICE and ISO 26262: Complementary Frameworks

A persistent source of confusion in automotive supplier organizations is the relationship between ASPICE and ISO 26262. They are frequently discussed in the same breath, sometimes treated as redundant, and occasionally pitted against each other in resource arguments. None of these framings is accurate.

ISO 26262 is a functional safety standard. It specifies what safety-relevant technical requirements must be met for automotive electrical and electronic systems — hazard analysis and risk assessment, safety goals, functional safety requirements, technical safety requirements, hardware and software safety requirements, and verification objectives at each level. ISO 26262 is prescriptive about content and outcomes.

ASPICE is a process capability framework. It evaluates how an organization performs its engineering processes — whether requirements are systematically analyzed, whether architecture decisions are traceable to requirements, whether changes are controlled. ASPICE is prescriptive about process discipline, not technical content.

The relationship is additive. A supplier developing an ASIL D braking controller needs both: ISO 26262 to define what the safety case must contain, and ASPICE to demonstrate that the processes which produced that safety case are capable and repeatable. A team can produce technically correct ISO 26262 work products through heroic individual effort — and still fail ASPICE because the process was not managed, documented, or repeatable. Conversely, a highly capable ASPICE Level 3 team can still fail ISO 26262 if their safety analysis is methodologically incorrect.

OEM contracts increasingly specify both, with separate assessment events. Safety managers own ISO 26262 compliance. Quality managers own ASPICE compliance. In well-run suppliers, these teams collaborate because their artifacts overlap — particularly in requirements traceability and change management.

Requirements Management Is the Spine of SYS.2 and SYS.3

When ASPICE assessors sit down with a supplier team to evaluate SYS.2 and SYS.3, they are essentially conducting a requirements management audit. The two process areas together ask a single overarching question: can you show me, right now, how your system requirements connect to what the customer asked for, and how your architecture connects to those requirements?

In SYS.2, assessors look for specific evidence:

  • Stakeholder requirements are transformed into system requirements that are complete, consistent, and verifiable. Not just written down — verifiable. Each requirement must be testable.
  • System requirements are attributed. Who approved this requirement? What version? Under what change control?
  • Bidirectional traceability exists between stakeholder requirements and system requirements. The assessor will pick a stakeholder requirement and ask to see the system requirements that implement it. Then they will pick a system requirement and ask to see the stakeholder requirement that motivated it. Orphaned requirements — system requirements with no stakeholder origin — are a finding.
  • Impacts of requirement changes are analyzed. When a customer changes a stakeholder requirement, can you identify every system requirement affected? Can you show that analysis was performed before the change was accepted?

In SYS.3, the scrutiny extends downward into architecture:

  • System requirements are allocated to architectural elements (hardware, software, mechanical). Every requirement lands somewhere. Unallocated requirements are a Level 1 finding.
  • Interface definitions are derived from requirements and documented. Assessors check that interface control documents connect to the requirements that motivated them.
  • Traceability from system requirements to architectural elements is bidirectional and maintained under change.

The practical implication is that requirements management is not a documentation activity that happens once before development begins. It is a continuous, change-tracked, bidirectionally linked record of technical decisions. Teams that manage requirements in word processing documents or spreadsheets almost always fail SYS.2 and SYS.3 at Level 2 because they cannot demonstrate that traceability is maintained under change — only that it existed at a point in time.

How Modern Tools Help Suppliers Meet the Traceability Standard

The gap between what ASPICE assessors require and what document-based tools can reliably produce is one of the most expensive recurring problems in automotive supplier engineering. A team that stores requirements in DOORS Classic exports them to Word for review, manages changes through email, and reconstructs traceability in a spreadsheet before each assessment is doing three to four times the work of a team with an integrated requirements management environment — and still producing weaker evidence.

Graph-based requirements tools change the structural relationship between engineering work and assessment evidence. When requirements, architectural elements, tests, and change records are nodes in a connected graph rather than rows in separate documents, traceability is not something you generate for the assessor — it is the natural output of how the team works.

Flow Engineering is built on this model. The platform represents requirements, system functions, architectural allocations, and verification links as graph nodes with typed relationships, which means a SYS.2 traceability matrix is not a report generated from the tool — it is a view of the live model. When a stakeholder requirement changes, the graph immediately surfaces which system requirements are affected, which architectural elements those requirements are allocated to, and which tests verify them. That impact chain is the evidence SYS.3 assessors want to see: not a claim that impact analysis was performed, but a structured record of what the analysis found.

For ASPICE assessments specifically, this matters at two levels. First, the evidence is always current. There is no “pre-assessment sprint” to reconstruct traceability that decayed during development. Second, the evidence is navigable. An assessor can follow a link from stakeholder requirement to system requirement to architectural element to test case without asking an engineer to pull up five separate documents. That navigability is itself a demonstration of process discipline.

Flow Engineering’s focus is on systems and requirements engineering rather than full project lifecycle management, which means teams that need ASPICE coverage across MAN and SUP process areas will integrate it with complementary tools for project scheduling, configuration management, and defect tracking. That is a deliberate scope decision — depth in the engineering model rather than breadth across all project functions.

Where to Start

For automotive suppliers entering their first ASPICE assessment cycle, or rebuilding after a poor assessment result, the practical sequence is:

  1. Assess your current state honestly against SYS.2 and SYS.3 first. These two process areas generate the most findings at Tier 1 suppliers and have the longest remediation timelines. If your requirements traceability is not bidirectional and change-controlled today, it will not be by the time your assessor arrives next quarter.

  2. Separate ASPICE requirements from ISO 26262 requirements in your planning. They share artifacts but have different owners, different timelines, and different audit events. Conflating them creates coordination problems that slow both.

  3. Choose tooling that produces navigable evidence natively. A tool that forces you to export traceability to a spreadsheet for review is a tool that creates evidence fragility. The assessor’s question — “show me the impact of this change” — should have a live answer, not a static one.

  4. Treat Tier 2 pass-through seriously. If your subcontractors are not ASPICE-capable, you own that gap in your assessment. Audit your supply chain with the same criteria your OEM applies to you.

ASPICE is not a compliance exercise that ends when the assessment report is filed. The suppliers that use ASPICE capability levels as an internal engineering benchmark — rather than an OEM-imposed obligation — tend to have shorter development cycles, fewer late-stage integration failures, and better change management histories. The process discipline ASPICE measures is worth having independently of who is checking.