Automotive SPICE (ASPICE)
Automotive SPICE (ASPICE) ist das Prozess-Assessment-Modell der Automobilindustrie zur Bewertung der Reife von Entwicklungsprozessen für software-basierte Systeme. Assessments stufen Prozesse auf Capability Levels 0 bis 5 ein — viele OEMs fordern von Zulieferern Level 2 oder 3. ASPICE ist die branchenspezifische Ausprägung der genormten Assessment-Familie ISO/IEC 330xx und wird unter dem Dach des VDA QMC gepflegt.
Wie funktioniert ein ASPICE-Assessment?
ASPICE hat zwei Dimensionen. Die Prozessdimension definiert Prozessgebiete mit Zielen und Basispraktiken — etwa SYS.2 (Anforderungsanalyse auf Systemebene) oder SWE.4 (Software Unit Verification). Die Reifegraddimension bewertet, wie gut ein Prozess beherrscht wird:
| Level | Bezeichnung | Bedeutung |
|---|---|---|
| CL 0 | Incomplete | Prozess fehlt oder verfehlt sein Ergebnis |
| CL 1 | Performed | Prozess erreicht sein Ergebnis |
| CL 2 | Managed | Prozess wird geplant, überwacht, Arbeitsprodukte werden verwaltet |
| CL 3 | Established | Prozess folgt einem organisationsweiten Standardprozess |
| CL 4 | Predictable | Prozess wird quantitativ gesteuert |
| CL 5 | Innovating | Prozess wird kontinuierlich und systematisch verbessert |
In Zuliefererprojekten sind Level 2 und 3 die praktisch relevanten Zielmarken; Level 4 und 5 spielen in Assessments kaum eine Rolle.
Die Prozessgebiete: orientiert am V-Modell
Die Engineering-Prozesse folgen der Logik des V-Modells: Auf der linken Seite werden Anforderungen und Architektur auf System- und Softwareebene verfeinert (SYS.1–SYS.3, SWE.1–SWE.3), auf der rechten Seite in umgekehrter Reihenfolge verifiziert (SWE.4–SWE.6, SYS.4–SYS.5). Dazu kommen unterstützende Prozesse wie Qualitätssicherung, Konfigurationsmanagement und Change Request Management sowie Managementprozesse wie das Projektmanagement.
Was ändert sich mit ASPICE 4.0?
Die 2023 veröffentlichte Version 4.0 erweitert das Modell über die Software hinaus: Eigene Prozessgebiete für Hardware Engineering (HWE) und Machine Learning Engineering (MLE) tragen der Realität softwaredefinierter Fahrzeuge Rechnung. Zugleich erhöht ASPICE 4.0 die formalen Anforderungen an die Traceability in der Automotive-Entwicklung — Nachweisketten müssen konsistent über alle Ebenen des V-Modells geführt werden.
ASPICE und Traceability
Bidirektionale Traceability ist in ASPICE eine Basispraktik, die sich durch nahezu alle Engineering-Prozessgebiete zieht: Jede Systemanforderung muss sich zu Softwareanforderungen, Architekturelementen, Implementierung und Testfällen verfolgen lassen — und von dort wieder zurück. Damit fordert ASPICE dieselbe Nachweisstruktur, die auch Safety-Normen wie die ISO 26262 verlangen: Wer Prozessreife nachweisen will, kommt an digitaler Traceability nicht vorbei.
ASPICE in der Praxis: Das Assessment beginnt in der Toolchain
Die größte Hürde in Assessments ist selten das Prozessverständnis, sondern die Nachweisführung: Anforderungen liegen in DOORS oder Polarion, Architektur in MBSE-Werkzeugen, Code und Tests in GitLab — und der Assessor will die Kette dazwischen sehen. Wo diese Nachweise von Hand zusammengesucht werden, bindet die Assessment-Vorbereitung Engineering-Teams über Wochen. Mit durchgängiger, werkzeugübergreifender Requirements Traceability lässt sich derselbe Nachweis in Stunden statt Wochen erbringen — und die Trace-Daten stiften zwischen den Assessments echten Engineering-Nutzen, etwa für Impact-Analysen bei Änderungen.


