ASPICE.
Prozessreife, bewertet.
Automotive SPICE (ASPICE) ist das Prozessmodell des VDA zur Bewertung der Prozessreife in der Automotive-Softwareentwicklung. Das ASPICE-Modell misst über Capability Level 0–5 entlang des V-Modells, wie diszipliniert und reproduzierbar entwickelt wird — nicht das Produkt, sondern den Prozess. OEMs fordern von Zulieferern meist ASPICE Level 2 oder 3. ASPICE 4.0 (2023) strafft das Modell und integriert Machine Learning und Cybersecurity. Viele Nachweise entstehen automatisch aus einer guten CI/CD-Pipeline.
Ist ASPICE bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Was sind die ASPICE Level (Capability Level 0–5)?
ASPICE bewertet jeden Prozess über sechs Capability Level (0–5): Incomplete, Performed, Managed, Established, Predictable und Optimizing. OEMs fordern von Zulieferern meist ASPICE Level 2 oder 3 — höhere Level sind in der Praxis selten verlangt.
Der Anlass ist fast immer derselbe: Ein OEM schreibt Level 2 in den Lastenheft-Anhang, und das Projektteam fragt sich, wie weit der eigene Alltag davon entfernt ist. Damit sind Sie in guter Gesellschaft — kaum ein Zulieferer startet mit einer gelebten Level-2-Praxis, die meisten bauen sie unter Projektdruck auf.
ASPICE Level 2 oder Level 3 — was verlangt der OEM?
ASPICE Level 2 (Managed) bedeutet, dass ein Prozess im konkreten Projekt geplant, überwacht und mit gemanagten Arbeitsprodukten gesteuert wird — über die Prozessattribute Performance Management (PA 2.1) und Work Product Management (PA 2.2). ASPICE Level 3 (Established) verlangt zusätzlich einen organisationsweit definierten Standardprozess, der auf jedes Projekt angepasst und gelebt wird. In der Praxis fordern OEMs meist Level 2 für die meisten Prozesse und Level 3 für einzelne Schlüsselprozesse (etwa SWE.1–SWE.6). Der Sprung von 1 auf 2 ist Projektdisziplin — der von 2 auf 3 eine Organisationsleistung.
Wie hängt ASPICE mit dem V-Modell zusammen?
Das ASPICE V-Modell ordnet die Entwicklung in zwei Äste: Links stehen die spezifizierenden Schritte (System- und Software-Anforderungen, Architektur, Detaildesign), rechts die korrespondierenden Verifikations- und Integrationsschritte. Jede Anforderung links hat ein Gegenstück rechts — verbunden durch bidirektionale Traceability, die ASPICE als Kernanforderung prüft.
- System-Anforderungen (SYS.2)
- Systemarchitektur (SYS.3)
- Software-Anforderungen (SWE.1)
- Software-Architektur (SWE.2)
- Detaildesign & Unit-Konstruktion (SWE.3)
- Unit-Verifikation (SWE.4)
- Software-Integrationstest (SWE.5)
- Software-Qualifizierungstest (SWE.6)
- Systemintegrationstest (SYS.4)
- System-Qualifizierungstest (SYS.5)
Was ist SWE.5 in ASPICE?
SWE.5 ist der Prozess der Software-Integration und ihrer Verifikation: Komponenten werden schrittweise zusammengeführt und gegen die Software-Architektur (SWE.2) getestet. In ASPICE 3.1 heißt der Prozess „Software Integration and Integration Test“, in ASPICE 4.0 „Software Component Verification and Integration Verification“. Im Assessment fällt SWE.5 häufig durch fehlende Rückverfolgbarkeit auf — Integrationstests, die sich keinem Architekturelement zuordnen lassen, zählen als Schwäche. Wie sich genau diese Integrations- und Testnachweise automatisiert erzeugen lassen, zeigt der Anwendungsfall CI/CD für Automotive & Embedded.
In Assessments scheitert es selten am Testen selbst, sondern am Nachweis: Die Tests sind gelaufen, aber drei Monate später kann niemand mehr belegen, welche Anforderung welcher Test abdeckt — handgepflegte Traceability-Matrizen in Excel veralten schneller, als sie nachgetragen werden. Teams, die den Nachweis einmal in die Pipeline verlagert haben, erleben den Unterschied im nächsten Assessment unmittelbar: Was früher eine Woche Vorbereitung kostete, ist ein Link auf den Pipeline-Run. Genau diese Traceability- und Testnachweise entlang des V-Modells lassen sich aus einer CI/CD-Pipeline heraus erzeugen — mehr dazu im Anwendungsfall CI/CD für Automotive & Embedded sowie in unseren DevSecOps- und Compliance-Leistungen. Wie die Pipeline-Architektur dahinter für Steuergeräte und andere cyber-physische Systeme grundsätzlich aufgebaut ist, beschreibt der Leitfaden zu Industrial DevOps.
Was ändert sich mit ASPICE 4.0?
ASPICE 4.0 (2023) konsolidiert das Prozessmodell: Mehrere Prozesse aus Version 3.1 entfallen oder werden zusammengelegt, die Prozessgruppen sind neu strukturiert und es kommen eigene Prozesse für Machine Learning Engineering hinzu. Die Bewertung stützt sich auf überarbeitete Performance-Indikatoren. V-Modell und Capability Level 0–5 bleiben erhalten.
Die Kern-Neuerungen im Überblick
- Konsolidiertes ProzessmodellMehrere Prozesse aus ASPICE 3.1 wurden zusammengelegt oder entfernt — das Modell ist schlanker und überschneidungsärmer.
- Neue Prozessgruppen-StrukturDie Prozessgruppen wurden neu geordnet, um Engineering, Management und Supporting-Prozesse klarer zu trennen.
- Machine-Learning-Prozesse (MLE)Eigene Prozesse für Machine Learning Engineering tragen datengetriebenen Funktionen und KI-Komponenten Rechnung.
- Klarere Performance-IndikatorenDie Bewertungssystematik nutzt überarbeitete Performance-Indikatoren statt der bisherigen Base- und Generic-Practices-Logik.
- Stärkere Security-IntegrationCybersecurity-Aspekte (u. a. ISO/SAE 21434) sind enger im Prozessmodell verankert.
Die straffere Struktur verschiebt den Aufwand vom Dokumentieren zum Nachweisen: Wer Traceability, Reviews und Tests bereits aus der Pipeline heraus belegt, bildet die neuen Performance-Indikatoren weitgehend automatisch ab. Im Assessment zählt am Ende nicht, was dokumentiert wurde, sondern was sich auf Nachfrage belegen lässt — wenn der Assessor die Traceability einer beliebigen Anforderung sehen will, entscheidet sich in diesem Moment, ob Wochen der Nachdokumentation folgen oder ein Klick genügt. Genau hier unterstützen unsere DevSecOps- und Compliance-Leistungen beim Übergang von 3.1 auf 4.0 — und wo die Pipeline dauerhaft nachweisfähig bleiben muss, ohne dass ein eigenes Team sie pflegt, übernehmen wir den Betrieb als Managed CI/CD per SLA. Wenn Sie vorab wissen wollen, wie weit Ihre Pipeline heute von belastbaren Nachweisen entfernt ist: Ein 30-Minuten-Erstgespräch ist kostenlos und verpflichtet zu nichts.
Was ist ASPICE (Automotive SPICE)?
Automotive SPICE (ASPICE) ist ein Prozessreferenz- und Bewertungsmodell für die Entwicklung von Automotive-Software und -Systemen. Es wird vom VDA gepflegt und basiert auf ISO/IEC 330xx. ASPICE bewertet, wie diszipliniert und reproduzierbar ein Entwicklungsprozess abläuft — nicht das Produkt selbst, sondern die Prozessreife.
Was bedeuten die ASPICE Capability Level?
ASPICE kennt sechs Capability Level (0–5): Incomplete, Performed, Managed, Established, Predictable und Optimizing. OEMs fordern von Zulieferern typischerweise Capability Level 2 oder 3 für die relevanten Prozesse. Höher ist selten verlangt. Jeder Level baut auf den darunterliegenden auf.
Was ist ASPICE Level 2?
ASPICE Capability Level 2 („Managed") ist erreicht, wenn ein Prozess nicht nur durchgeführt (Level 1), sondern auch geplant, überwacht und mit gemanagten Arbeitsprodukten gesteuert wird — konkret über die Prozessattribute Performance Management (PA 2.1) und Work Product Management (PA 2.2). Er beschreibt einen im jeweiligen Projekt beherrschten Prozess und ist der übliche Mindest-Zielzustand, den OEMs von Zulieferern fordern. Level 3 verlangt darüber hinaus einen organisationsweit definierten Standardprozess.
Was ist neu in ASPICE 4.0?
ASPICE 4.0 (2023) strafft das Prozessmodell, integriert Themen wie Machine Learning und Cybersecurity stärker und vereinfacht die Bewertungsdimensionen. Der grundlegende Ansatz — Prozessreife über Capability Level entlang des V-Modells — bleibt erhalten. Bestehende Assessments sollten auf die neue Struktur abgebildet werden.
Was ist der Unterschied zwischen ASPICE 4.0 und 3.1?
ASPICE 4.0 konsolidiert das Modell gegenüber 3.1: Einzelne Prozesse wurden zusammengelegt oder entfernt, die Prozessgruppen neu strukturiert und eigene Prozesse für Machine Learning Engineering (MLE) ergänzt. Die Bewertungssystematik wurde auf klarere Performance-Indikatoren umgestellt. Der V-Modell-Kern und die Capability Level 0–5 bleiben erhalten, sodass bestehende 3.1-Assessments auf die neue Struktur abgebildet werden können.
Wie hängen ASPICE und das V-Modell zusammen?
ASPICE strukturiert die Entwicklung entlang eines V-Modells: System- und Software-Anforderungen, Architektur und Design auf der linken Seite, die korrespondierenden Verifikations- und Integrationsschritte auf der rechten. Bidirektionale Traceability zwischen diesen Stufen ist eine Kernanforderung — und genau hier setzt Pipeline-Automatisierung an.
Welches V-Modell wird in der Automotive-Entwicklung verwendet?
Die Automotive-Entwicklung folgt dem V-Modell in der Ausprägung von Automotive SPICE: links die spezifizierenden Prozesse SYS.2 bis SWE.3 (Anforderungen, Architektur, Detaildesign), rechts die korrespondierenden Verifikationsprozesse SWE.4 bis SYS.5 (Unit-Verifikation bis System-Qualifizierungstest). Jede Spezifikationsstufe hat ein Test-Gegenstück auf gleicher Höhe; bidirektionale Traceability zwischen beiden Ästen wird im Assessment geprüft.
Was ist SWE.5 in ASPICE?
SWE.5 ist der Prozess der Software-Integration und ihrer Verifikation: Software-Komponenten werden schrittweise zum Gesamtsystem integriert und gegen die Software-Architektur getestet. In ASPICE 3.1 heißt er „Software Integration and Integration Test", in ASPICE 4.0 „Software Component Verification and Integration Verification". SWE.5 liegt auf der rechten Seite des V-Modells und ist das Gegenstück zur Software-Architektur (SWE.2) — Integrationstests müssen auf die Architekturelemente rückverfolgbar sein.
Was ist der Unterschied zwischen ASPICE und ISO 26262?
ASPICE bewertet die Prozessreife (wie diszipliniert entwickelt wird), ISO 26262 adressiert die funktionale Sicherheit (was ein System sicher macht). Beide werden in Automotive-Projekten parallel gefordert: ASPICE liefert die Prozessdisziplin, ISO 26262 die sicherheitsspezifischen Anforderungen und ASIL-Einstufung.
Lässt sich ASPICE-Konformität durch CI/CD unterstützen?
Ja. Viele ASPICE-Erwartungen — versionierte Arbeitsprodukte, bidirektionale Traceability, reproduzierbare Builds, dokumentierte Reviews und Tests — entstehen als Nebenprodukt einer gut gebauten CI/CD-Pipeline mit Git als Single Source of Truth. Das reduziert manuellen Assessment-Aufwand erheblich.
Wie geht es bei Ihnen mit ASPICE weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
ASIL-Level A bis D nach ISO 26262 erklärt
ASIL A, B, C und D, die Einstufung über S/E/C und automatisierte Nachweise.
DevSecOps für die Industrie & IEC 62443
Security in jeder Pipeline-Stufe für regulierte Branchen.
TIA Portal mit Git versionieren
Mergefähige Quelltexte als Basis für Traceability.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance