Was ist ein (Sicherheits-)Konzept?

• Safety & Risiko
• Engineering

Nico Litschke • 16.12.2025 • 5 min

Sicherheitskonzepte sind zentrale Bestandteile der ISO 26262. Die Norm beschreibt detailliert, mit welchen Artefakten und Methoden Sicherheitskonzepte zu erstellen, zu analysieren und zu testen sind. Unklar bleibt jedoch, was ein Sicherheitskonzept ist, was es leisten soll, und was nicht. In der Praxis driften viele Sicherheitskonzepte frühzeitig ins Detailed Design ab. Sie verfehlen damit ihren eigentlichen Zweck: Safety ist eine Systemeigenschaft. Sicherheitskonzepte sollen zeigen, wie Schutzmaßnahmen zusammenwirken, um unzumutbar hohe Risiken durch Fehlverhalten oder variierende Umweltbedingungen zu begrenzen. Der Beitrag greift die klassische Konzeptdefinition des Systems Engineering auf. Übertragen auf Safety bedeutet das: Ein Sicherheitskonzept bildet sicherheitsrelevantes (Fehl-)Verhalten auf die Systemstruktur ab. Diese begriffliche Schärfung legt die Basis für eine verständliche und schlanke Konzeptdokumentation, ohne vorschnell ins Detailed Design abzudriften.

Diese Überschrift überrascht. ISO 26262 sieht explizit ein Funktionales und ein Technisches Sicherheitskonzept vor.[1] Der Begriff „concept“ wird in ISO 26262 und ihren Schwesternormen SOTIF (ISO/PAS 21448) und KI Safety (ISO/PAS 8800) insgesamt 391-mal genannt. Wie kann dann der Zweck des Sicherheitskonzepts unbestimmt sein?

Die normativen Vorgaben beziehen sich nahezu ausschließlich auf Vorgehen und Methodik. So beschreibt Band 3 „Concept Development“ in rund 40 Seiten Prosa, Grafiken und Tabellen die Methodik, die Band 4 für das Technische Sicherheitskonzept fortführt.

ISO 26262 führt hingegen nicht aus, wozu ein Sicherheitskonzept dient, was es leisten soll, wie es sich inhaltlich vom Detailed Design abgrenzt und warum diese Abgrenzung relevant ist.

Diese Leerstelle bleibt nicht folgenlos. Mangels klarer inhaltlicher Leitplanken werden Sicherheitskonzepte in der Praxis häufig überfrachtet – nach dem Motto: Mehr Detail erhöht die Sicherheit. Doch genau das Gegenteil ist hier der Fall. 

Wie auch andere Engineeringansätze beruht ISO 26262 auf dem bewährten Prinzip „Teile und Herrsche“: Sollvorgaben werden vom Einfachen zum Detail weiter zerlegt, geordnet und konkretisiert. Dieses Prinzip setzen die Methoden der Konzeptentwicklung um: von Sicherheitszielen und -anforderungen über Notationen wie SysML und UML bis hin zu Sicherheitsanalysen. Grundsätzlich ist genau das auch gewollt: Die Freiheitsgrade der Systemteile sollen durch Restriktionen top-down beschränkt werden, um einen sicheren Systembetrieb zu gewährleisten.

„Grundsätzlich“ heißt jedoch: Es gibt Ausnahmen. Zerlegen, Ordnen und Konkretisieren setzt stets Sollvorgaben voraus. Damit ergibt sich in der Konzeptentwicklung nach ISO 26262 ein Zirkelschluss: Sie setzt Ergebnisse voraus, die sie selbst erst erzeugt. So erfordert bereits eine Gefährdungsanalyse die Kenntnis, welches (Fehl-)Verhalten in welcher Systemumwelt auftreten kann. Teile dieser Betrachtung wurden später unter anderem mit der Schwesternorm SOTIF (ISO/PAS 21448) explizit adressiert. Sie fokussiert auf Gefährdungen, die bei fehlerfreiem System aufgrund variierender Umweltbedingungen auftreten können.

Dieses zirkuläre Problem lässt sich wiederum auf die fehlende Zweckbestimmung von Sicherheitskonzepten zurückführen: Mangels Klarheit, was ein Konzept leisten soll, werden wichtige Randbedingungen und Annahmen übersehen.

Die fehlende Zweckbestimmung von Sicherheitskonzepten wirkt unmittelbar in die Praxis hinein. Ohne klare Leitplanken ersetzt Detailtiefe die Systembeschreibung. Sicherheitskonzepte gleiten oft früh ins Detailed Design ab: Die Behandlung von Bitkippern, Fehlermoden einzelner Bauteile, Timeouts oder Checksummen wird ausführlich ausbuchstabiert, anstatt die systemischen Abhängigkeiten sowie, Neben- und Fernwirkungen alternativer Designentscheidungen zu betrachten. Das ist zunächst nachvollziehbar: Wer kleinste Fehler im Griff hat, glaubt leicht, das System sei sicher.

So ist es jedoch nicht. Fehlerfreie Bauteile garantieren keine Systemsicherheit. Safety ist eine Systemeigenschaft. Sicherheitskonzepte müssen daher aufzeigen, wie unzumutbar hohes Risiko durch Gefährdungen mittels des Zusammenspiels von Schutzvorkehrungen begrenzt wird. Der Schwerpunkt liegt dabei auf diesem Zusammenspiel; weniger darauf, wie es im Detailed Design technisch umgesetzt wird.

Zudem fordert ISO 26262 wiederholt ein hierarchisches Design mit Modularisierung, Kapselung, Einfachheit und reduzierter Komplexität. Ausschweifende Sicherheitskonzepte mit detaillierten Vorgaben stehen diesen Prinzipien direkt entgegen. Die unklare Zweckbestimmung unterläuft damit die Anforderungen der Norm selbst.

Im Systems Engineering versteht man unter einem Konzept die Abbildung relevanten Systemverhaltens auf Struktur:[2][3]

\(f:\ \text{Verhalten}\to\text{Struktur}\)

Übertragen auf Sicherheitskonzepte:

\(f:\ \text{(Fehl-)Verhalten}\to\text{Systemstruktur}\)

Die Besonderheit dieser Auffassung gegenüber Methoden des Zerlegens, Ordnens und Konkretisierens liegt darin, dass (Fehl-)Verhalten und Systemstruktur untrennbar miteinander verknüpft sind. Sie werden nicht über getrennte Sichten oder Artefakte behandelt, wie etwa in SysML/UML, sondern als Einheit verstanden.

Damit ist zugleich die Grundlage für eine systematische Gefährdungsanalyse gelegt: Das (Fehl-)Verhalten unter variierenden Umweltbedingungen kann mit der bekannten Methodik der ISO 26262 bewertet werden. In nachgelagerten Schritten lässt sich diese Abbildung konsistent in Sicherheitsziele sowie funktionale und technische Sicherheitsanforderungen überführen, ohne frühzeitig in Fragen des Detailed Designs einzusteigen. 

Auf diese Weise geht auch die Item Definition in die Systemarchitektur ein. Beide beschreiben unterschiedliche Abstraktionsebenen desselben Systems, die im Verlauf der Konzeptarbeit schrittweise präzisiert werden.

Der Vorteil dieses Konzeptverständnisses lässt sich an einem vereinfachten Sicherheitskonzept eines ePowertrains auf L0-Abstraktionsebene verdeutlichen:

Das Bild zeigt das Sicherheitskonzept (L0) und integriert dabei Zweck, Verhalten mit Gefährdungen und Struktur des ePowertrains:

• Zweck: Der Standort von Fahrer, Insassen und Gepäck wird verändert
• (Fehl-)Verhalten: Beschleunigen, Rekuperieren, Entladen, Verlustleistung
• Struktur: E-Maschine, Inverter, Antriebstrangmechanik, Systemschnittstellen
• Verbindungen: Abbildung von Verhalten auf Struktur 

Deutlich wird, wie Gefährdungen aus gewünschtem Systemverhalten und den Strukturen des ePowertrains entstehen. Damit wird der emergente Charakter von Systemsafety sichtbar: Gefährdungen ergeben sich aus dem Zusammenwirken von Verhalten und Struktur und nicht aus isolierten Komponenten oder Fehlermoden.

Die im Bild enthaltenen Elemente werden mit Anforderungen spezifiziert. Somit entsteht eine knappe und präzise Konzeptdarstellung. In der weiteren Entwicklung bildet sie die Basis für das Zerlegen, Ordnen und Konkretisieren des ePowertrains in Sicherheitsziele, funktionale Sicherheitsanforderungen und detailliertere Konzeptdarstellungen.

Eine Besonderheit des Bildes ist die Notation „Object-Process-Methodology“ gemäß ISO 19450:2024. Sie eignet sich besonders für die Konzeptentwicklung und wird im nächsten Beitrag näher vorgestellt.

— Ihr, Nico Litschke

1. ↑ International Organization for Standardization. (2018). ISO 26262:2018 Road vehicles – Functional safety (2nd ed.). Geneva: ISO.
2. ↑ National Aeronautics and Space Administration. (2016). NASA systems engineering handbook (2nd ed., p. 298). Washington, DC: CreateSpace Independent Publishing Platform.
3. ↑ International Council on Systems Engineering. (2015). INCOSE systems engineering handbook: A guide for system life cycle processes and activities (4th ed., p. 304). Hoboken, NJ: Wiley.