The PAM 3.1 Structure

Automotive SPICE PAM 3.1 organizes process requirements into four process categories:

Engineering processes (ENG) cover the technical work of developing a system: system requirements analysis (SYS.2), system architectural design (SYS.3), software requirements analysis (SWE.1), software architectural design (SWE.2), software detailed design and unit construction (SWE.3), software unit verification (SWE.4), software integration and integration testing (SWE.5), and software qualification testing (SWE.6).

Support processes (SUP) cover the infrastructure that enables engineering: documentation (SUP.1), configuration management (SUP.8), problem resolution (SUP.9), change request management (SUP.10), and quality assurance (SUP.1 and SUP.2 in some versions).

Management processes (MAN) cover project planning and control: project management (MAN.3), risk management (MAN.5), and measurement (MAN.6).

Acquisition and supply processes cover the relationship between OEM and supplier, including acquisition (ACQ) and supply (SPL) processes.

For a Tier-1 software supplier, the primary assessment focus is the engineering processes SWE.1 through SWE.6 and the key support processes (SUP.8 for configuration management, SUP.9 for problem resolution).

Capability Levels Explained

ASPICE measures each process against six Capability Levels (CL), from CL0 (Incomplete) to CL5 (Optimizing). Most OEM contracts require a minimum of CL2 for all assessed processes, with some safety-critical processes required at CL3.

The capability levels assess the process against two dimensions:

Process performance (CL1): The process is performed — it achieves its purpose. For SWE.1, this means software requirements are elicited, analyzed, and documented. The assessor verifies that the work products exist and are appropriate.

Performance management (CL2): The process is managed — it is planned, monitored, and adjusted to meet objectives. For SWE.1 at CL2, this means there is a plan for how software requirements will be developed, actual progress is tracked against that plan, resources are appropriately allocated, and the work products meet defined quality criteria.

Process definition (CL3): The process follows a defined organizational standard process, rather than being improvised project by project.

Process measurement (CL4): Process performance is measured and used to improve the process.

Process innovation (CL5): Continuous process improvement is systematic and quantitatively managed.

The practical implication: achieving CL2 requires demonstrating that your engineering processes are planned and managed — not just that you are producing work products. Assessors look for evidence of planning documents, status tracking, review records, and configuration management for each process area.

What ASPICE Assessors Actually Look for

Assessors evaluate two types of evidence: work products (documents and artifacts that demonstrate the process outputs) and practice indicators (evidence of how the work was done).

For SWE.1 (Software Requirements Analysis), the primary work product is the software requirements specification. Assessors look for:

  • Traceability: Every software requirement must be traceable to a system-level input (system requirements, customer requirements, or safety goals). Untraceable requirements are a finding.
  • Verifiability: Every software requirement must have acceptance criteria that allow it to be tested or inspected. "The system shall behave correctly" fails this criterion.
  • Completeness: Requirements must cover all applicable interfaces, all operational modes (including error modes), and all relevant safety-relevant behaviors.
  • Consistency: Requirements shall not contradict each other.

For SWE.3 (Software Detailed Design and Unit Construction), assessors look for evidence that code was written to match a design, that the design satisfies the requirements, and that coding standards (typically MISRA C for automotive safety software) were applied and deviations were documented.

The ASPICE-ISO 26262 Integration

The ASPICE and ISO 26262 process requirements overlap significantly, but they are not identical. Understanding the overlap prevents double documentation.

In a program that manages both standards with shared work products, the software requirements specification satisfies both SWE.1 and ISO 26262-6 simultaneously. The assessors evaluate the same document against different criteria. In a program with separate documents for each standard, engineers produce two documents that must be kept consistent — which they never are.

Common ASPICE Assessment Failures

Traceability gaps. Software requirements that cannot be traced to system requirements, or code that cannot be traced to design. Traceability is a CL1 requirement for the engineering processes — failing traceability is a CL1 gap, which means the process is assessed as Incomplete regardless of how sophisticated everything else is.

Requirements that are not verifiable. "The system shall process sensor data efficiently" cannot be tested. Requirements must specify measurable acceptance criteria. This is a common finding in SWE.1 assessments.

Configuration management that is documentation only. Version control exists, but engineers routinely work from uncontrolled copies, commit directly to mainline branches, and create deliverable releases from local builds rather than controlled sources. Assessors ask to see recent commit logs, branch management policies, and build records — not the CM plan document.

No evidence of process management. Engineering work was done, but there are no planning records, status tracking records, or resource allocation evidence. The work products exist, but there is no evidence that they were produced by a managed process. This is the gap between CL1 and CL2.

ASPICE in ISO WIZ

ISO WIZ includes an ASPICE process tracking module that maps PAM 3.1 process areas to the engineering work products being developed for ISO 26262, SOTIF, and ISO 21434.

The fundamental design principle is that safety and cybersecurity work products serve as ASPICE evidence — not that ASPICE evidence is produced separately. The ISO 26262 software requirements specification IS the SWE.1 work product. The SOTIF algorithm performance requirements ARE SWE.1 requirements with ASPICE attributes. The configuration management records that ISO 26262-8 requires ARE the SUP.8 evidence.

This eliminates the compliance waste of producing parallel documentation. ASPICE assessors see engineering work products — not a compliance overlay. ISO 26262 assessors see the same work products evaluated against safety criteria.