Safety lässt sich nicht hineinprüfen – die Schlagseite von ISO 26262 und ASPICE

• Safety & Risiko
• Engineering

Nico Litschke • 09.11.2025 • 7 min

Um zu verstehen, warum die Standards eine Schlagseite haben, betrachten wir das Grundprinzip technischer Entwicklung. 

Ein Entwickler soll ein Problem lösen. Die gewünschten Eigenschaften der Lösung übersetzt er in Anforderungen. Anschließend legt er Merkmale von Bauteilen fest oder codiert. Danach prüft er, ob die IST-Eigenschaften den SOLL-Eigenschaften entsprechen. Die Merkmale kann er direkt gestalten; die Eigenschaften entstehen aus ihrem Zusammenspiel. So bewegt er sich ständig zwischen Synthese und Analyse, wie Bild 1 schematisch zeigt:

Das Safetykonzept legt fest, unter welchen Belastungen und Bedingungen das System über die Lebensdauer fehlerfrei funktionieren soll und wie es im Fehlerfall ausfällt. Es grenzt damit den Lösungsraum ein, fügt sich aber nahtlos in diese Logik.

Für größere Systeme mit mehreren Fachdomänen wird diese Logik kaskadiert. Nach dem Verfahren des „General Problem Solvers[1] werden die obersten Eigenschaften in Unter-/Untereigenschaften zerlegt, bis Merkmale festgelegt werden können. Die so ausgelegten Bauteile oder Code werden rekursiv zum System integriert und die IST-Eigenschaften gegen die SOLL-Eigenschaften laut Anforderungen geprüft. So entfaltet sich das V-Modell. 

Für unsere Betrachtung genügen jedoch Synthese und Analyse.

Bild 2 erweitert Synthese und Analyse um konkrete methodische Ansätze und Kriterien, wie sie etwa in der ISO 26262 festgelegt sind:

Die Schlagseite der Standards ist unverkennbar: Sie legen fest, womit verifiziert, validiert und bestätigt (engl. „confirmation“) wird. So gibt ASPICE Prozessgebiete, Base und Generic Practices sowie Prüfmaßstäbe vor, um etablierte Prozesse zu bewerten. Alles rechts in Bild 2. Ebenso ISO 26262: Sie lässt offen, welches Design tatsächlich sicher ist. Stattdessen liefert sie Methoden und Kriterien, um die Systemeigenschaft Safety eines bestehenden Designs zu prüfen.

Die Synthese (links im Bild 2) fehlt in Safetynormen und Compliancestandards.

Damit stehen sie nicht allein. In Cybersecurity (ISO/SAE 21434), S(W)EBOK[2] [3], NASA System Engineering Handbook[4], PMBOK[5] oder ISO 9001[6] finden wir stets das gleiche Bild: Es geht um Überwachen, Bewerten, Nachweisen, Prüfen, Argumentieren – nicht um Gestalten, Schaffen oder Verstehen. 

Diese Schlagseite schafft Probleme. Um nicht missverstanden zu werden: Die Aktivitäten der rechten Seite sind unbestritten notwendig. Doch sie reichen allein nicht, um erfolgreiche Produkte oder sichere Systeme zu entwickeln. Gleiches gilt für andere Systemeigenschaften wie Performance oder Verfügbarkeit. 

Wie wir gesehen haben, lassen sich nur Merkmale gestalten, aus deren Zusammenspiel Systemeigenschaften entstehen. Wer zum ersten Mal eine Norm wie ISO 26262 umsetzt, merkt schnell: Mit „ein bisschen Prozessarbeit“ ist es bei Safety nicht getan. Safety muss im System selbst durch Merkmale angelegt sein.[17] Beispiele sind:

• Funktionsüberwachung
• Hardwareüberwachung
• Latentfehlerdiagnosen
• Redundante und unabhängige Signalpfade, Sensoren, Aktoren, µC, Speicherbereiche, und Mechanismen, die Grenzüberschreitungen zur Laufzeit stoppen
• Entprellung, Degradationen und Abschaltpfade
• Diversitäre Bauteile und Code
• Andere Technologien, etwa Pyrofuse oder Kühlung

Nicht zu vergessen: Safety steht zudem im ständigen Zielkonflikt mit Performance, Verfügbarkeit und Stückkosten. Alles Themen, die auf der linken Seite in Bild 2 gelöst werden müssen. ISO 26262 hilft dabei kaum; eine der wenigen positiven Ausnahmen ist Band 5, Anhang D.

In den letzten Jahren hatte ich Gelegenheit, mit erfahrenen Ingenieuren aus verschiedenen Branchen zu arbeiten. So unterschiedlich ihre Fachgebiete auch waren, eines verband sie alle: Sie entwarfen zuerst ein tragfähiges Design (links in Bild 2), das die geforderten Eigenschaften erfüllte – und zogen erst danach die Standards heran, um den Nachweis zu argumentieren (rechts). Eigentlich selbstverständlich: Man kann nur prüfen, was existiert.

Heute ist das oft umgekehrt. Projekte, die erstmals Safety erreichen sollen, beginnen mit dem Prüfverfahren. Kein Wunder: in der Norm steht wenig anderes. Das führt zu Methodismus.[7]

Methodismus ist der unhinterfragte Einsatz von Methoden, ohne dass deren fachliche Bedingungen erfüllt sind.[8]

Das erzeugt unwirksames Management. Erst kürzlich erhielt ich einen Projektplan mit dem singulären Arbeitspaket Technische Sicherheitskonzept (TSC). Völlig substanzlos. Ein TSC besteht aus Dutzenden, teils Hunderten Sicherheitsfunktionen und -restriktionen, an denen viele Fachdomänen mitwirken. Dafür braucht es mindestens eine TSC Breakdown Structure oder ein Komponentendiagramm. TSC mag für eine Norm korrekt abstrahiert sein und reicht für die Checkfrage im Gate Review; für die Umsetzung ist es aber nicht plan- und steuerbar.

Typische Auswüchse des Methodismus:

•  künstlich erzeugte Systemanforderungen, obwohl ausschließlich Software entwickelt wird.
  Copy-Paste-Umformulieren. Abstraktionsleistung: Null.
• zwanghaftes Dokumentieren von Designalternativen, obwohl der OEM die wichtigen Entscheidungen meist schon in der RFQ-Phase gefällt hat.
  Bürokratie ohne Mehrwert.
• Unittest, die direkt aus Code generiert werden. 100 % MC/DC Coverage, 100 % effizient,
  100 % nutzlos – weil nichts verifiziert wird; bestenfalls Regression.
• Scheinredundanzen, die erst nach dem ADC den Signalpfad aufspalten.
  Gleiche Common Causes: Sensor, ADC und Signalstrecke dazwischen.
• Back-to-Backtests, obwohl nur handgeschriebener Code existiert.
  Eine „highly recommended“ Methode erzwungen.
• System-FMEA, die Merkmale, Fehlermoden und Robustheit prüft.
  Scheinsicherheit: Safety ist eine Eigenschaft, kein Merkmal. Robust heißt nicht automatisch sicher.[9]

Die Schlagseite der Norm fördert diesen Methodismus, hausgemachte Bürokratie. Verstärkt wird sie durch eine Unsitte unserer Zunft: Methoden werden verschrieben, ohne ihre Bedingungen anzugeben. Das ist, als würde man Medikamente ohne Beipackzettel zu Risiken und Nebenwirkungen verteilen.

Unter Investoren ist es ein bekanntes Phänomen: Bonistrukturen steuern operative Entscheidungen. Schlechte Anreize führen zu Fehlsteuerung und lassen sich als Prädiktor späterer Ergebnisse lesen.[10]

Ein Beispiel: In einem Projekt gab es zu viele Bugs. Das Projektmanagement von OEM und Tier 1 forderte den „Bug Burndown“ (rechts in Bild 2), entlastete das Program Increment aber nicht von neuen Funktionen. Der Burndown kam – gemessen an geschlossenen Tickets. Gelöste Bugs (links in Bild 2) dagegen kaum. In der nächsten Testkampagne waren rund 90 % der Tickets wieder offen. Die einen waren entrüstet, die anderen genervt. Ähnliche Erfahrungen beschreibt Gunther Dueck anschaulich in „Schwarmdumm“.[11]

Automotive OEMs und damit auch Tier 1 nutzen ASPICE inzwischen als hartes Auswahlkriterium für Lieferanten. Einen stärkeren Anreiz zur ASPICE-Anwendung gibt es kaum. Was also ist der Prädiktor? ASPICE prüft Prozessreife (rechts in Bild 2). Wenig überraschend werden Entwickler plötzlich aus Projekten abgezogen, weil anderswo ein ASPICE-Audit ansteht. Die Doku muss auf Vordermann gebracht werden. Um ISO 26262 ist es nicht viel besser bestellt. Im Safety Assessment wird nicht geprüft, ob das Design tatsächlich „unzumutbar hohe Gefährdungen abwendet“ (links in Bild 2), sondern ob die eingesetzten Methoden plausibel waren. Ob ein System sicher ist, muss der Hersteller selbst beurteilen.

In beiden Fällen stellt sich die Gretchenfrage: Werden die Assessments antizipiert und dadurch vorauseilend[12] Güte und Sorgfalt erhöht? Laut der Organisationsforschung ist die Antwort ein klares Nein. Untersuchungen zu ISO 9001[6] oder PMBOK[5] zeigen: Das Getane wird nachträglich so dargestellt, als seien die Standards eingehalten worden; tatsächlich passten Aktivitäten und Standards kaum zusammen.[13] [14] Was man sagt, was man tut, und was man tatsächlich tut, sind oft verschiedene Dinge.[15] Und die Engineering-Forschung? Totalausfall. Sie wiederholt artig die Behauptungen von Gurus.[16]

Eigentlich müssten ISO 26262 und ASPICE auf der Titelseite eine Warnung tragen:

„Gefahr! Die Anwendung dieser Standards ist notwendig, aber nicht hinreichend für die Gefährdungs- und Risikovermeidung technischer Systeme!“

Das ist das Dilemma: Die Schlagseite hin zum Prüfen und Bewerten bündelt Zeit, Geld und Aufmerksamkeit im Prozesscontrolling. Doch Controlling kann nur feststellen, ob ein IST vom SOLL abweicht. Meistens werden dafür nichtfachliche Kennzahlen wie Aufwand oder Kosten herangezogen. Es kann weder fachliche Probleme lösen noch benennen. Genau dort aber entsteht Wertschöpfung.

Wir sollten nicht der Versuchung erliegen, den Anwendern die Schuld zu geben. „Man muss die Standards nur richtig anwenden!“, ist eine beliebte Floskel. So einfach ist es nicht. Bei Safetykonzepten müssen wir vorhersehbare Zweckentfremdungen antizipieren. Warum sind Standards von diesem Anspruch befreit?

Wenn so viele Unternehmen mit vergleichbaren Schwierigkeiten bei der Anwendung kämpfen, liegt die Ursache vielleicht nicht beim Anwender, sondern in den Standards selbst. Die aufgezeigte Schlagseite anzunehmen und gezielt zu korrigieren, wäre ein erster Schritt, um das Schiff wieder aufzurichten.

— Ihr, Nico Litschke

1. ↑ Simon, H. A. (1973). The Structure of Ill Structured Problems. Artificial Intelligence, 4(3–4), 181–201. https://doi.org/10.1016/0004-3702(73)90011-8
2. ↑ SWEBOK. (2025). Guide to the Software Engineering Body of Knowledge (Version 4.0a) (H. Washizaki, Ed.). IEEE Computer Society Press. https://doi.org/10.3403/30314312
3. ↑ SEBoK. (2024). The Guide to the Systems Engineering Body of Knowledge (Version 2.12). Stevens Institute of Technology Systems Engineering Research Center, the International Council on Systems Engineering, and the Institute of Electrical and Electronics Engineers Systems Council. Im Internet: www.sebokwiki.org
4. ↑ NASA. (2016). NASA Systems Engineering Handbook (2nd ed., p. 298). Washington: CreateSpace Independent Publishing Platform.
5. ↑ PMBOK. (2004). A Guide to the Project Management Body of Knowledge (Version 3). Newtown Square, PA: Project Management Institute.
6. ↑ ISO 9001. (2015). Qualitätsmanagementsysteme – Anforderungen (ISO 9001:2015-09).
7. ↑ Clausewitz, C. v. (2014). Vom Kriege (6. vollständige Ausgabe). Hamburg: Nikol.
8. ↑ Dörner, D. (2002). Die Logik des Mißlingens: Strategisches Denken in komplexen Situationen (15. Aufl.). Reinbek bei Hamburg: Rowohlt.
9. ↑ Leveson, N. G. (2011). Engineering a Safer World: Systems Thinking Applied to Safety (p. 534). Cambridge, London: MIT Press.
10. ↑ Clark, D. (2018). Das Tao des Charlie Munger (C. T. Munger & E. Neumüller, Hrsg.). Kulmbach: Börsenbuchverlag.
11. ↑ Dueck, G. (2015). Schwarmdumm: So blöd sind wir nur gemeinsam. Frankfurt/New York: Campus.
12. ↑ Coenenberg, A., Fischer, T. M., & Günther, T. (2009). Kostenrechnung und Kostenanalyse (7., überarb. und erw. Aufl.). Stuttgart: Schäffer-Poeschel.
13. ↑ Kühl, S. (2011). Organisationen: Eine sehr kurze Einführung (1. Aufl.). Wiesbaden: Springer VS.
14. ↑ Kühl, S. (2016). Projekte führen: Eine kurze organisationstheoretisch informierte Handreichung. Wiesbaden: Springer VS. https://doi.org/10.1007/978-3-658-13427-3
15. ↑ Argyris, C. (2000). Teaching Smart People How to Learn. In Strategic Learning in a Knowledge Economy (pp. 279–295). Elsevier. https://doi.org/10.1016/b978-0-7506-7223-8.50015-0
16. ↑ Ralph, P. (2018). The two paradigms of software development research. Science of Computer Programming, 156, 68–89. https://doi.org/10.1016/j.scico.2018.01.002
17. ↑ Battershell, A. L. (1999). The DOD C-17 Versus the Boeing 777: A Comparison of Acquisition and Development. CreateSpace Independent Publishing Platform.