ASPICE 4.0 vs 3.1 — 何が変わり、どう移行するか

Why ASPICE 4.0

ASPICE 3.1 has served as the de facto standard for automotive software development process assessment since 2017. However, rapid changes in the automotive industry created gaps that 3.1 could no longer address.

First, 3.1 was software-centric. It lacked comprehensive coverage for hardware engineering and system-level integration. Modern vehicle E/E systems are tightly coupled mechatronic systems where software and hardware interact closely, yet the process model did not reflect this reality.

Second, AI/ML-based software entered automotive applications at scale. Autonomous driving, driver monitoring, and predictive maintenance all rely on machine learning, but no process guidelines existed for data-driven development within the V-Model framework.

Third, the rise of SDV (Software Defined Vehicles) made cybersecurity a critical concern. Standards like ISO 21434 and regulations like UN R155 emerged, and the industry demanded that ASPICE reflect these changes.

Against this backdrop, VDA QMC developed ASPICE 4.0 and officially released it in December 2023. The assessor transition period ended on March 31, 2025, and all official assessments are now conducted against the 4.0 standard.

Key Changes Comparison

The transition from 3.1 to 4.0 is not a minor update but a structural overhaul. If you understand ASPICE fundamentals, the following comparison illustrates the scope of change.

Scope: 3.1 focused on software engineering. 4.0 covers the entire mechatronic system — software, hardware, and machine learning.

Hardware Processes: 3.1 had no hardware-specific processes. 4.0 introduces HWE.1 (Requirements Analysis) through HWE.4 (Verification) — four dedicated hardware engineering processes.

Machine Learning Processes: 3.1 had no ML coverage. 4.0 defines MLE.1 (Data Management) through MLE.4 (Verification) for machine learning engineering.

Safety and Cybersecurity: 3.1 offered general guidelines. 4.0 significantly strengthens safety management and cybersecurity management requirements, explicitly aligning with ISO 26262 and ISO 21434.

Traceability: In 3.1, traceability and consistency were separate Base Practices. 4.0 integrates them, improving management efficiency.

Assessment Criteria: 3.1 was based on ISO 15504. 4.0 aligns with ISO/IEC 33002:2015, enhancing international standards compatibility.

Agile/DevOps: 3.1 had no explicit agile support. 4.0 officially accommodates agile and DevOps approaches, making integration with automotive CI/CD pipelines more natural.

Architecture Evaluation: 3.1 required separate alternative architecture evaluation as a BP. 4.0 changes this to selection justification, increasing practical flexibility.

New Process Areas — HW and ML

The most visible change in 4.0 is the introduction of hardware and machine learning processes.

Hardware Engineering (HWE) consists of four processes:

• HWE.1 — Hardware Requirements Analysis: Derives hardware requirements from system requirements.
• HWE.2 — Hardware Design: Defines hardware architecture including circuit design and PCB layout.
• HWE.3 — Hardware Implementation: Executes hardware fabrication and prototyping per design.
• HWE.4 — Hardware Verification: Verifies that hardware meets its requirements.

Machine Learning Engineering (MLE) also consists of four processes:

• MLE.1 — ML Data Management: Covers collection, preprocessing, labeling, and quality management of training data.
• MLE.2 — ML Model Development: Handles model architecture selection, training, and hyperparameter tuning.
• MLE.3 — ML Integration: Integrates ML models into the overall system.
• MLE.4 — ML Verification: Verifies model performance, accuracy, and robustness.

These processes cross-reference existing SWE (Software Engineering) and SYS (System Engineering) processes. For example, MLE.3 (Integration) relates to SWE.5 (Software Integration), and HWE.1 (Requirements) derives from SYS.2 (System Requirements).

Enhanced Safety and Cybersecurity Requirements

ASPICE 4.0 substantially strengthens management requirements for both safety and cybersecurity.

Safety management processes are now more closely aligned with the ISO 26262 functional safety standard. For safety-related software, traceability of safety requirements, safety analysis, and safety verification are more systematically required throughout the development lifecycle.

Cybersecurity management is strengthened through alignment with ISO/SAE 21434. Threat Analysis and Risk Assessment (TARA), security requirements derivation, and security verification must be integrated into the development process. This directly connects to UN R155 regulatory compliance.

While 3.1 treated safety and security as separate concerns, 4.0 is designed so that both are considered simultaneously throughout the development process — reflecting the reality that modern vehicles must ensure functional safety and cybersecurity in parallel.

Migration Roadmap

Transitioning from ASPICE 3.1 to 4.0 should be systematic. Here is a proven five-phase roadmap.

Phase 1: Current State Analysis (1-2 months)

Perform a gap analysis comparing your current 3.1-based processes against 4.0 requirements. Identify which processes already comply and which need new development. Pay special attention to whether HW processes (HWE) and ML processes (MLE) apply to your organization.

Phase 2: Training and Awareness (1-2 months)

Train the entire development team on ASPICE 4.0 changes. Secure executive support and build organizational consensus on the need for transition.

Phase 3: Process Update (2-3 months)

Update existing process descriptions, templates, and checklists to 4.0 criteria. If new process areas (HWE, MLE) apply, define new processes from scratch. Tool configurations should also be adjusted during this phase.

Phase 4: Pilot Project (3-4 months)

Select one project and fully apply the updated processes. Fix issues discovered during real-world application and document lessons learned.

Phase 5: Organization-Wide Rollout + External Assessment (2-3 months)

Expand pilot-validated processes across the organization and prepare for official assessment by a certified ASPICE assessor.

A realistic timeline is 6-12 months for new projects and 12-18 months when reverse-engineering existing projects. The actual duration depends on your organization's current maturity and the scope of 4.0 applicability (whether HW and ML processes are relevant).

ASPICE Transition with PopcornSAR

The ASPICE 4.0 transition involves not only process redefinition but also tool and automation updates. PopcornSAR's PARVIS efficiently supports this transition.

• PARVIS-Spec: Automates requirements analysis and ensures traceability across system, software, and hardware levels — addressing 4.0's strengthened traceability requirements.
• PARVIS-Coder: Automatically applies coding rules such as MISRA C, supporting the SWE.3 (Detailed Design and Implementation) process.
• PARVIS-Verify: Auto-generates test cases using AI, reducing verification effort (SWE.4-SWE.6) by 3-4x.

PopcornSAR also provides ASPICE 4.0 migration consulting and training services, supporting the entire journey from gap analysis to external assessment preparation.

Visit the PARVIS product page for details, or get in touch to discuss your transition needs.