Safety-Prozesse mit Automotive SPICE abstimmen

Warum Safety und ASPICE zusammengedacht werden müssen

In der Entwicklung sicherheitskritischer Systeme im Automotive-Bereich ist es nicht mehr ausreichend, ISO 26262 und Automotive SPICE (ASPICE) als zwei getrennte Welten zu betrachten. Viele Unternehmen stehen vor der Herausforderung, funktionale Sicherheit mit Entwicklungsreifegraden in Einklang zu bringen. Die Integration spart nicht nur Zeit und Kosten, sondern verbessert auch die Nachvollziehbarkeit, Qualität und Auditierbarkeit.

Beide Normen werden zunehmend gemeinsam gefordert – sei es von OEMs, Zulieferern oder in internationalen Entwicklungskooperationen. Der Druck steigt, die Anforderungen effizient zu erfüllen, ohne doppelte Arbeit zu leisten. Dabei helfen Synergien, ein einheitliches Verständnis und vor allem ein klares Vorgehensmodell.

Unterschiedliche Zielsetzungen – gleiche Verantwortung

ISO 26262 stellt Anforderungen für die funktionale Sicherheit, ASPICE für die Prozessqualität der Software- und Systementwicklung. Beide Normen fokussieren auf unterschiedliche Aspekte, verfolgen jedoch ein gemeinsames Ziel: den sicheren Betrieb von Systemen im Fahrzeug. Die Schwierigkeit besteht darin, diese Perspektiven strukturell, methodisch und operativ zu vereinen.

ISO 26262 fokussiert auf Gefährdungsanalyse (HARA), Sicherheitsanforderungen und Sicherheitsnachweise.

ASPICE hingegen prüft die Prozessreife – also ob Aktivitäten systematisch, wiederholbar und nachvollziehbar ablaufen.

Gemeinsamkeiten und Synergien nutzen

  • Traceability: Beide Normen fordern lückenlose Rückverfolgbarkeit. Eine konsistente Dokumentation ermöglicht die parallele Nutzung beider Nachweisführungen.
  • Validierung und Verifikation: Safety fordert sicherheitsgerichtete Tests, ASPICE fokussiert auf generische Testabdeckung. Durch Integration lassen sich Tests effizient zusammenlegen.
  • Konfigurationsmanagement: Beide Standards fordern versionierte, nachvollziehbare Entwicklungsergebnisse. Ein einheitlicher Prozess erleichtert Audits und reduziert Redundanz.
  • Dokumentationspflichten: Safety verlangt Sicherheitsnachweise, ASPICE strukturierte Prozessnachweise. Mit übergreifenden Templates können diese effizient bedient werden.
  • Qualitätsbewusstsein: Beide Normen setzen auf ein hohes Maß an Dokumentation, Disziplin und Nachvollziehbarkeit.

Tiefere Einblicke: Wo liegen die Fallstricke?

Ein häufiger Fehler ist, dass Safety und ASPICE in getrennten Silos organisiert werden. Das führt zu doppelten Aufwänden, widersprüchlicher Dokumentation und ineffizienten Prozessen. Auch die Toolintegration wird häufig vernachlässigt: Zwei Systeme für Requirements, zwei für Tests – das erhöht nicht nur die Komplexität, sondern birgt auch Fehlerpotenzial.

Ein Beispiel aus der Praxis: In einem Tier-1-Zuliefererprojekt wurde das Safety-Team isoliert vom ASPICE-Team organisiert. In der Folge waren die Sicherheitsanforderungen nicht mit den Systemanforderungen abgestimmt. Beim OEM-Audit fiel dies auf – mit erheblichen Nachbesserungskosten.

Konkrete Vorgehensmodelle für die Integration

  1. Prozesslandkarte zusammenführen: Beginnen Sie mit einer Meta-Analyse beider Normen. Welche Prozesse sind gleichartig? Welche ergänzen sich? Daraus lässt sich eine gemeinsame Prozessarchitektur ableiten.
  2. Work Products konsolidieren: Dokumente wie Requirement-Spezifikationen, Testspezifikationen oder Konfigurationslisten lassen sich modular gestalten und normübergreifend verwenden. Tipp: Verwenden Sie eine Matrix zur Zuordnung der Anforderungen beider Normen zu einzelnen Dokumenten.
  3. Rollen und Verantwortlichkeiten harmonisieren: Es braucht keine doppelte Besetzung – aber klare Zuordnung. Ein „Safety Process Engineer“ kann auch ASPICE-Themen verantworten, sofern die Qualifikation stimmt.
  4. Kombinierte Audit-Vorbereitung: Statt separate Audits zu planen, sollte ein kombiniertes Auditkonzept erstellt werden. Viele Inhalte überschneiden sich ohnehin. Ein gemeinsamer Auditplan spart Aufwand und stärkt die interne Koordination.
  5. Toollandschaft vereinheitlichen: Ideal ist eine zentrale ALM-Plattform (Application Lifecycle Management), die Anforderungen, Risiken, Tests, Nachweise und Reviews in einem System verwaltet. Beispiele: IBM Jazz, Polarion, Codebeamer.
  6. Pilotprojekte durchführen: Bevor das Konzept auf alle Projekte ausgerollt wird, empfiehlt sich ein Pilotprojekt. Dort lassen sich Lessons Learned ableiten und das Vorgehen optimieren.

Erweiterte Normenanalyse: Unterschiede und Gemeinsamkeiten

KategorieISO 26262ASPICE
ZielsetzungFunktionale SicherheitProzessreife und Entwicklungseffizienz
GeltungsbereichSicherheitsrelevante Systeme im FahrzeugAlle Software-/Systementwicklungsprozesse
Typische ArtefakteSicherheitskonzept, SicherheitsnachweiseProzessdefinitionen, Reifegradnachweise
RisikoanalyseHARA, ASILRisikoanalysen nicht primär enthalten
ProzessmodellV-Modell mit Sicherheitsbezuggenerisches V-Modell mit Bewertungskriterien
Rolle der Testaktivitätensicherheitsgerichtet, szenarienbasiertumfassend, systematisch

Fallstudie: Integration in einem deutschen OEM-Projekt

Ein deutscher OEM hatte über Jahre getrennte Teams für ASPICE und Safety aufgebaut. Im Rahmen eines neuen E/E-Projekts entschloss man sich zur Integration. Die Lessons Learned aus dem Projekt:

  • Mehr Klarheit in der Prozesslandschaft: Frühzeitige Abstimmung der Prozessverantwortlichen führte zu klaren Schnittstellen.
  • Reduzierter Auditaufwand: Ein kombiniertes Audit durch TISAX/ASPICE/Safety war schneller und günstiger als drei Einzeltermine.
  • Weniger Schulungsaufwand: Mitarbeiterschulungen konnten kombiniert erfolgen – mit Fokus auf Gemeinsamkeiten.
  • Weniger Toolwechsel: Durch Umstellung auf eine einheitliche ALM-Plattform konnten Redundanzen abgebaut werden.

Handlungsempfehlungen für Unternehmen

  • Beginnen Sie mit einer Gap-Analyse: Welche Safety-Anforderungen sind schon ASPICE-konform abgedeckt – und umgekehrt?
  • Benennen Sie Schnittstellenverantwortliche zwischen beiden Welten.
  • Erstellen Sie eine Prozesslandkarte, die Safety- und ASPICE-Perspektive integriert.
  • Schulen Sie Ihre Teams normübergreifend – nicht getrennt.
  • Betrachten Sie Tool- und Datenintegration als Schlüssel zum Erfolg.

Fazit

Die Integration von Safety-Prozessen mit ASPICE ist keine Kür, sondern Pflicht für moderne Entwicklungsorganisationen. Wer sie strategisch plant, spart langfristig Kosten, verbessert Qualität und ist bei Audits souveräner aufgestellt. Entscheidend ist ein durchdachter, methodischer und auf Standards abgestimmter Ansatz – und der Wille, Silos zu durchbrechen. Mit der richtigen Strategie entsteht aus zwei komplexen Anforderungen ein durchgängiger, schlanker und sicherer Entwicklungsprozess.

Newsletter Anmeldung

Name
Datenschutz