1.2: Understanding ASPICE 4.0
Learning Objectives
After reading this section, you will be able to:
- Describe the history and evolution of ASPICE
- Identify all ASPICE 4.0 process groups and processes
- Explain the three components of ASPICE (PRM, PAM, Capability Levels)
- Understand the key changes in ASPICE 4.0
- Apply ASPICE concepts beyond automotive contexts
ASPICE History and Evolution
Origins
ASPICE (Automotive SPICE) traces its roots to the ISO/IEC 15504 standard (now ISO/IEC 33001-33099):
| Year | Milestone |
|---|---|
| 1991 | ISO/IEC 15504 project initiated (SPICE - Software Process Improvement and Capability dEtermination) |
| 1998 | ISO/IEC 15504 Technical Report published |
| 2005 | ASPICE 1.0 released by AUTOSIG (Automotive Special Interest Group — a consortium of automotive OEMs and suppliers formed to create an automotive-specific process standard) |
| 2010 | ASPICE 2.5 - stabilized version widely adopted |
| 2017 | ASPICE 3.1 - major restructuring |
| 2023 | ASPICE 4.0 - introduction of MLE, SEC groups |
| 2024 | ASPICE 4.0 - current version with refined processes |
Organizational Stewardship
ASPICE is maintained by VDA QMC (German Association of the Automotive Industry - Quality Management Center), Working Group 13. The intacs (International Assessor Certification Scheme — the body that certifies the humans who conduct official ASPICE assessments) manages assessor certification.
The Three Components of ASPICE
ASPICE consists of three interrelated components:
1. Process Reference Model (PRM)
The PRM defines what processes exist and their purposes. For each process:
- Purpose statement: What the process is meant to achieve
- Outcomes: Specific outcomes that indicate successful implementation
The PRM is technology-agnostic—it describes what to achieve, not how to achieve it.
2. Process Assessment Model (PAM)
The PAM provides how to assess whether processes achieve their purposes:
- Base Practices (BP): Specific activities that implement the process
- Work Products (WP): Tangible outputs with defined characteristics
- Assessment indicators: Evidence of process implementation
3. Capability Levels
The Capability Levels define how mature a process is:
- Level 0: Incomplete
- Level 1: Performed
- Level 2: Managed
- Level 3: Established
- Level 4: Predictable
- Level 5: Innovating
Each level has associated Process Attributes (PA) — measurable properties that indicate how well a capability level is achieved — and Generic Practices (GP) — the specific activities that demonstrate those attributes are in place.
ASPICE 4.0 Process Catalog
ASPICE 4.0 core PAM includes processes organized in 10 process groups:
| Group | Name | Processes | Notes |
|---|---|---|---|
| ACQ | Acquisition | 1 | |
| SPL | Supply | 1 | |
| SYS | System Engineering | 5 | |
| VAL | Validation | 1 | |
| SWE | Software Engineering | 6 | |
| MLE | Machine Learning Engineering | 4 | New in ASPICE 4.0 |
| HWE | Hardware Engineering | 1 | Core PAM: HWE.1 only |
| SUP | Supporting | 5 | SUP.1, SUP.8-11 (SUP.2-7 removed in 4.0) |
| MAN | Management | 3 | MAN.3, MAN.5, MAN.6 |
| PIM | Process Improvement | 1 | |
| REU | Reuse | 1 | |
| SEC | Cybersecurity Engineering | 3 | From CS-PAM supplement (ISO/SAE 21434 alignment) |
Note: SEC processes are defined in the ASPICE Cybersecurity Process Assessment Model (CS-PAM) supplement, not the core ASPICE 4.0 PAM. They are commonly included in automotive assessments for ISO/SAE 21434 compliance.
Acquisition (ACQ)
| Process | Name | Purpose |
|---|---|---|
| ACQ.4 | Supplier Monitoring | Monitor supplier performance |
Supply (SPL)
| Process | Name | Purpose |
|---|---|---|
| SPL.2 | Product Release | Control product release activities |
System Engineering (SYS)
| Process | Name | Purpose |
|---|---|---|
| SYS.1 | Requirements Elicitation | Gather and capture stakeholder requirements |
| SYS.2 | System Requirements Analysis | Transform stakeholder needs into system requirements |
| SYS.3 | System Architectural Design | Establish system architecture and element allocation |
| SYS.4 | System Integration and Integration Verification | Integrate system elements and verify consistency with architecture |
| SYS.5 | System Verification | Verify system against stakeholder requirements |
Software Engineering (SWE)
| Process | Name | Purpose |
|---|---|---|
| SWE.1 | Software Requirements Analysis | Establish software requirements from system requirements |
| SWE.2 | Software Architectural Design | Define software architecture and interface specifications |
| SWE.3 | Software Detailed Design and Unit Construction | Design and implement software units |
| SWE.4 | Software Unit Verification | Verify software units meet requirements and design |
| SWE.5 | Software Integration and Integration Verification | Integrate software units and verify consistency with architecture |
| SWE.6 | Software Qualification Test | Validate software against requirements |
Hardware Engineering (HWE)
Note: ASPICE 4.0 core PAM defines only HWE.1. Some organizations and supplements define additional HWE processes (HWE.2-5), but these are not part of the official ASPICE 4.0 PAM. For hardware-intensive projects, consider using domain-specific hardware lifecycle standards (e.g., IEC 61508-2 for industrial, ISO 26262-5 for automotive, DO-254 for aerospace).
| Process | Name | Purpose |
|---|---|---|
| HWE.1 | Hardware Requirements Analysis | Establish hardware requirements from system requirements |
Extended HWE Processes (not in core ASPICE 4.0 PAM, but commonly referenced):
- HWE.2: Hardware Design (design hardware elements)
- HWE.3: Hardware Integration and Verification (integrate and verify hardware elements)
- HWE.4: Hardware Qualification Test (verify hardware against requirements)
- HWE.5: Hardware-Software Integration (coordinate HW-SW integration)
Machine Learning Engineering (MLE) - New in ASPICE 4.0
| Process | Name | Purpose |
|---|---|---|
| MLE.1 | ML Requirements Analysis | Establish ML-specific requirements |
| MLE.2 | ML Architecture | Define ML model architecture |
| MLE.3 | ML Training and Learning | Train and validate ML models |
| MLE.4 | ML Model Testing | Verify ML model behavior and performance |
Cybersecurity Engineering (SEC) - From CS-PAM Supplement
Note: SEC processes are defined in the ASPICE Cybersecurity Process Assessment Model (CS-PAM) supplement, not the core ASPICE 4.0 PAM. The CS-PAM aligns ASPICE with ISO/SAE 21434 cybersecurity requirements and is commonly used in automotive assessments where cybersecurity compliance is required.
| Process | Name | Purpose |
|---|---|---|
| SEC.1 | Cybersecurity Requirements Engineering | Define and manage cybersecurity requirements aligned with threat analysis |
| SEC.2 | Cybersecurity Design and Implementation | Implement cybersecurity controls and security architecture |
| SEC.3 | Cybersecurity Verification and Validation | Verify cybersecurity implementation and validate against threat scenarios |
Supporting Processes (SUP)
| Process | Name | Purpose |
|---|---|---|
| SUP.1 | Quality Assurance | Ensure work products and processes comply with plans |
| SUP.8 | Configuration Management | Maintain integrity of work products |
| SUP.9 | Problem Resolution Management | Analyze and resolve problems |
| SUP.10 | Change Request Management | Manage changes to work products |
| SUP.11 | Machine Learning Data Management | Manage ML training data and ensure data quality |
Management Processes (MAN)
| Process | Name | Purpose |
|---|---|---|
| MAN.3 | Project Management | Plan, execute, and control project activities |
| MAN.5 | Risk Management | Identify, analyze, and manage project risks |
| MAN.6 | Measurement | Collect and analyze measurement data |
Validation (VAL)
| Process | Name | Purpose |
|---|---|---|
| VAL.1 | Validation | Provide evidence that product satisfies intended use |
Process Improvement (PIM)
| Process | Name | Purpose |
|---|---|---|
| PIM.3 | Process Improvement | Continuously improve organizational processes |
Reuse (REU)
| Process | Name | Purpose |
|---|---|---|
| REU.2 | Management of Products for Reuse | Manage reusable work products |
Capability Levels in Detail
Level 0: Incomplete
The process is not implemented or fails to achieve its purpose.
Indicators:
- Process not performed
- No work products produced
- Purpose not achieved
Level 1: Performed
The process achieves its purpose.
Process Attribute PA 1.1: Process Performance
- Outcomes are achieved
- Work products are produced
- Purpose is met
Level 2: Managed
The process is implemented in a managed fashion (planned, monitored, adjusted).
Process Attributes:
- PA 2.1: Performance Management (work products meet requirements, activities are planned)
- PA 2.2: Work Product Management (work products are identified, documented, controlled)
Level 3: Established
A defined process is used based on a standard process.
Process Attributes:
- PA 3.1: Process Definition (standard process is maintained)
- PA 3.2: Process Deployment (standard process is deployed effectively)
Level 4: Predictable
The process operates within defined limits to achieve outcomes.
Process Attributes:
- PA 4.1: Quantitative Analysis (quantitative objectives established)
- PA 4.2: Quantitative Control (quantitative management applied)
Level 5: Innovating
The process is continuously improved to respond to change.
Process Attributes:
- PA 5.1: Process Innovation (process changes identified)
- PA 5.2: Process Optimization (impact of changes evaluated)
Key Changes in ASPICE 4.0
Major Additions
- Machine Learning Engineering (MLE): Complete process group for ML development
- Cybersecurity Engineering (SEC): Aligned with ISO/SAE 21434
- Agile Integration: Explicit guidance for agile methods
- DevOps Alignment: CI/CD and continuous testing support
Structural Changes
- Simplified Base Practices: Fewer, more outcome-focused BPs
- Revised Work Products: Updated WP characteristics
- Generic Practice Refinements: Clearer GP definitions
- Process Relationships: Better-defined process interactions
Philosophy Shift
ASPICE 4.0 emphasizes:
- Outcomes over activities: Focus on results, not procedures
- Flexibility in implementation: Many ways to achieve outcomes
- Modern development practices: Agile, DevOps, AI-assisted development
- Cross-domain applicability: Beyond pure automotive
Common Assessment Scopes
HIS Scope (Automotive Standard)
The HIS (Hersteller Initiative Software — a German OEM consortium including BMW, Daimler, and Volkswagen) scope is the most widely used set of processes for automotive supplier assessments. When an automotive OEM says "we require an ASPICE assessment," they typically mean this scope:
Required Processes:
- SYS.2, SYS.3, SYS.4, SYS.5
- SWE.1, SWE.2, SWE.3, SWE.4, SWE.5, SWE.6
- SUP.1, SUP.8, SUP.9, SUP.10
- MAN.3
Optional Extensions:
- SYS.1 (Requirements Elicitation)
- HWE.1 (Hardware Requirements Analysis - additional HWE processes from supplements)
- SEC.1-SEC.3 (Cybersecurity - from CS-PAM supplement)
- MLE.1-MLE.4 (Machine Learning Engineering)
- MAN.5 (Risk Management)
- MAN.6 (Measurement)
Tailored Scopes
Organizations may define custom scopes based on:
- Project type (software-only, full system)
- Safety requirements (ASIL level)
- Customer requirements
- Organizational maturity
ASPICE Beyond Automotive
While ASPICE originated in automotive, its principles apply broadly:
Universal Principles
| ASPICE Principle | Universal Application |
|---|---|
| Process definition | Any development context |
| Capability improvement | Any organization seeking maturity |
| Traceability | Any regulated or complex product |
| Verification | Any quality-focused development |
| Configuration management | Any multi-artifact development |
Adaptation for Other Domains
| Domain | ASPICE Adaptation |
|---|---|
| Medical devices | Align with IEC 62304 software classes |
| Industrial | Align with IEC 61508 SIL levels |
| Aerospace | Complement with DO-178C objectives |
| Consumer IoT | Focus on security (SEC) processes |
Summary
ASPICE 4.0 provides a comprehensive framework for process assessment and improvement:
- Three components: PRM (what), PAM (how to assess), Capability Levels (how mature)
- Core PAM process groups (10): ACQ, SPL, SYS, VAL, SWE, MLE, HWE, SUP, MAN, PIM, REU
- Core processes (28): Covering complete product development lifecycle
- CS-PAM supplement (3): SEC.1-3 for cybersecurity (ISO/SAE 21434 alignment)
- Six capability levels: From Incomplete (0) to Innovating (5)
- Key 4.0 changes: MLE process group, CS-PAM supplement, agile integration, DevOps alignment
Process Count Breakdown (core ASPICE 4.0 PAM):
- Primary Lifecycle: SYS (5) + SWE (6) + HWE (1) + MLE (4) = 16 processes
- Support & Management: SUP (5) + MAN (3) = 8 processes
- Acquisition & Supply: ACQ (1) + SPL (1) = 2 processes
- Organizational: VAL (1) + PIM (1) + REU (1) = 3 processes
- Total Core: 29 processes
- CS-PAM Supplement: SEC (3) processes
The framework is technology-agnostic, outcome-focused, and applicable beyond automotive to any domain requiring disciplined development.
Key Takeaways
- ASPICE evolved from ISO/IEC 15504 (SPICE) for automotive-specific needs
- The framework consists of PRM, PAM, and Capability Levels
- ASPICE 4.0 core PAM has 29 processes across 10 groups, with CS-PAM supplement adding 3 SEC processes
- ASPICE 4.0 adds MLE process group (4 processes) for machine learning engineering
- SEC processes (3) come from CS-PAM supplement for ISO/SAE 21434 alignment
- HWE.1 is the only hardware process in core PAM; additional HWE processes exist in supplements
- Capability levels range from Incomplete (0) to Innovating (5)
- The principles apply universally, not just to automotive
References
- VDA QMC (2024). Automotive SPICE Process Reference Model 4.0
- VDA QMC (2024). Automotive SPICE Process Assessment Model 4.0
- ISO/IEC 33001:2015. Information technology - Process assessment
- intacs (2024). Assessor Certification Guidelines