Einleitung: Zwischen Norm und Wirklichkeit
Die ISO 26262 ist in der Automobilentwicklung gesetzt. Sie definiert Prozesse, Rollen, Methoden und Dokumente für sicherheitsrelevante Systeme – mit dem Ziel, funktionale Risiken zu erkennen und systematisch zu minimieren. Doch so wichtig die Norm ist: Ihre Umsetzung in der Praxis stellt viele Unternehmen vor Herausforderungen.
Denn funktionale Sicherheit ist keine reine Checkliste. Sie erfordert ein tiefes Verständnis für Technik, Organisation und Verantwortung. Und sie funktioniert nur dann, wenn Theorie und Wirklichkeit miteinander in Einklang gebracht werden.
In diesem Beitrag teilen wir zentrale Erkenntnisse aus realen Projekten: typische Fehlerquellen, bewährte Vorgehensweisen und konkrete Verbesserungspotenziale.
1. Unklare Anforderungen als Risikoquelle
Eines der größten Probleme beginnt bereits in der Konzeptphase: Sicherheitsanforderungen werden entweder zu allgemein formuliert oder viel zu spät in den Prozess eingebracht.
Was wir beobachtet haben:
- Sicherheitsziele werden nicht frühzeitig mit System- und Projektzielen abgestimmt.
- Gefahren- und Risikoanalysen (HARA) erfolgen isoliert von der Gesamtarchitektur.
- Die Traceability von Sicherheitsanforderungen wird erst im Nachhinein versucht – mit hohem manuellen Aufwand.
Was hilft:
- Frühzeitige Abstimmung aller beteiligten Disziplinen.
- Iterative Sicherheitsanalysen, parallel zur Systementwicklung.
- Klare Dokumentationswerkzeuge und Toolchains, die Nachvollziehbarkeit von Anfang an sicherstellen.
2. Sicherheitsanalysen im Projektverlauf vernachlässigt
Viele Projekte starten mit sauberer Dokumentation – verlieren sie aber im Projektalltag aus dem Blick.
Typische Stolpersteine:
- Änderungen an Architektur oder Komponenten werden nicht mehr sicherheitsseitig bewertet.
- Neue Fehlerbilder durch spätere Integration oder Lieferantenänderungen bleiben unberücksichtigt.
- Die Sicherheitsziele geraten im Projektverlauf in den Hintergrund.
Was sich bewährt hat:
- Ein systematischer Änderungsprozess mit explizitem Safety-Impact-Check.
- Kontinuierliche Aktualisierung von Sicherheitsanalysen.
- Ein Safety Engineer mit klarer Rolle im Projekt – und entsprechender Entscheidungskompetenz.
3. Rollen und Verantwortung: Theorie vs. Praxis
Die Norm definiert Rollen – doch in der Projektpraxis verschwimmen Zuständigkeiten oft.
Erkannte Probleme:
- Safety und Projektleitung verfolgen unterschiedliche Ziele ohne Abstimmung.
- Safety-Entscheidungen werden informell getroffen und nicht dokumentiert.
- Die Rolle des “Independently Assessed Safety Engineer” ist nominell vergeben, aber nicht operativ eingebunden.
Konkrete Verbesserung:
- Klare Rollendefinitionen im Projektauftrag.
- Feste Abstimmungspunkte zwischen Safety, Entwicklung und Qualität.
- Etablierung von Eskalationswegen bei sicherheitsrelevanten Zielkonflikten.
4. Sicherheitskultur als Erfolgsfaktor
Technik, Methoden und Prozesse sind wichtig – aber ohne gelebte Sicherheitskultur bleiben sie wirkungslos.
Woran das scheitert:
- Sicherheit wird als “notwendige Dokumentationsarbeit” betrachtet.
- Kritische Fragen oder Hinweise bleiben unausgesprochen, um Zeitpläne nicht zu gefährden.
- Sicherheitsziele gelten als Aufgabe des Safety Engineers, nicht als gemeinsames Projektziel.
Was sich bewährt hat:
- Regelmäßige Projekt-Reviews mit offenem Umgang mit Fehlern.
- Anerkennung sicherheitsrelevanter Hinweise als fachlicher Beitrag.
- Safety-Training für alle Projektrollen.
5. Werkzeuge und Methoden sinnvoll nutzen
Viele Organisationen verfügen über Tools zur Sicherheitsanalyse und Dokumentation – nutzen sie aber ineffizient oder isoliert.
Beobachtete Defizite:
- Werkzeuge zur Requirements-Analyse werden nicht mit denen zur Architekturentwicklung gekoppelt.
- Sicherheitsnachweise erfolgen getrennt von funktionaler Verifikation.
- Tool-Ausgaben werden manuell nachbearbeitet, was zu Fehlern führt.
Empfehlung:
- Integrierte Toolchains mit zentralem Sicherheitsdatenmodell.
- Automatisierte Prüfmechanismen für Traceability, Reifegrad und Konsistenz.
- Werkzeugintegration in die CI/CD-Prozesse.
Fazit: Sicherheit ist mehr als Normerfüllung
Funktionale Sicherheit kann nicht allein durch Formalitäten sichergestellt werden. Sie lebt vom Zusammenspiel aus Klarheit, Struktur, Verantwortung und gelebter Sicherheitskultur.
Unsere Erkenntnis aus vielen Projekten:
- Wer Sicherheit als integralen Bestandteil des Projekts versteht, reduziert Risiken, spart Ressourcen und erhöht die Qualität.
- Wer funktionale Sicherheit dagegen als reines Dokumentationsthema behandelt, riskiert Sicherheitslücken, Mehraufwand und Verzögerungen.
Adinger unterstützt Unternehmen dabei, Sicherheit praxistauglich zu machen – durch Beratung, Review, Training und Prozessbegleitung.
