Was ist ein (Sicherheits-)Konzept?

Ausgangslage: Der unbestimmte Zweck des Sicherheitskonzepts

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 und zugehörige Artefakte, die Band 4 für das Technische Sicherheitskonzept fortführt.

ISO 26262 führt hingegen nicht aus, wozu ein Sicherheitskonzept fachlich 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.

Zirkuläres Problem: Sicherheitskonzepte nach ISO 26262 setzen ihre eigenen Ergebnisse voraus

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: Von Sicherheitszielen und -anforderungen über Notationen wie SysML und UML bis hin zu Sicherheitsanalysen und Tests. 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. In der Konzeptentwicklung nach ISO 26262 entsteht 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.

Konsequenz: Abgleiten ins Detailed Design und zu hohe Komplexität

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 hier auf dem Zusammenspiel; weniger auf der technischen Umsetzung im Detailed Design.

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 veranlasst uns zu vorschnellem Detailed Design und damit zur Unterwanderung der Norm der selbst.

Definition: Was ein Sicherheitskonzept ist

Oft wird Konzept salopp als „erste Niederschrift“ aufgefasst. Doch es steckt mehr drin. Im Systems Engineering versteht man unter einem Konzept die Abbildung relevanten Systemverhaltens auf Struktur:[2][3]

$$f: \text{Verhalten} \rightarrow \text{Struktur}$$

Übertragen auf Sicherheitskonzepte:

$$f: \text{(Fehl-)Verhalten} \rightarrow \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.

Beispiel: (Fehl-)Verhalten und Struktur im ePowertrain

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 soll verändert werden
• (Fehl-)Verhalten: Beschleunigen und Energie wandeln; daraus resultierend: Verlustleistung und Gefährdungen
• Struktur: E-Maschine, Inverter, Antriebstrangmechanik, Systemschnittstellen
• Verbindungen: Abbildung von Verhalten auf Struktur

Deutlich wird, wie Gefährdungen im ePowertrains entstehen. Der emergente Charakter von Systemsafety wird sichtbar: Gefährdungen ergeben sich aus dem Zusammenwirken von Verhalten und Struktur; nicht aus isolierten Komponenten oder Fehlermoden.

Für das Fortschreiben der Entwicklung werden die Elemente in Bild 3 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 und technische Sicherheitsanforderungen und detaillierteren Architekturdarstellungen.

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.

Anhang 1 – OPM Safetykonzept ePowertrain

Anhang 2 – Venn-Abbildung

Das Venn-Diagramm kann mit LaTeX kompiliert werden:

% LaTeX / TikZ
\documentclass[tikz,border=5pt]{standalone}
\usepackage{tikz}
\usepackage{amsfonts}   % oder: amssymb
\usetikzlibrary{calc,arrows.meta}

\begin{document}
\begin{tikzpicture}[
  font=\Huge,
  every node/.style={inner sep=0pt},
  arr/.style={-Latex, line width=0.9pt}
]

% Mengen V und S
\node[font=\Huge] at (-2.5,2.8) {$\mathbb{V}$};
\draw[rounded corners=29pt, line width=1pt]
  (-4.,-2.5) rectangle (-2,2.5);

\node[font=\Huge] at (3.4,2.8) {$\mathbb{S}$};
\draw[rounded corners=45pt, line width=1pt]
  (1,-2.5) rectangle (4.1,2.5);

% Knoten Menge V
\node (v1) at (-3.2, 1.6) {$v_1$};
\node (v2) at (-2.7, 0.0) {$v_2$};
\node (v3) at (-3.2,-1.6) {$v_3$};

% Knoten Menge S
\node (s1) at ( 2.4, 1.6) {$s_1$};
\node (s2) at ( 3.3, 0.7) {$s_2$};
\node (s3) at ( 2.1,-0.2) {$s_3$};
\node (s4) at ( 3.5,-0.8) {$s_4$};
\node (s5) at ( 2.7,-1.9) {$s_5$};

% Abbildungspfeile V → S
\draw[arr] (v1.east) -- (s1.west);
\draw[arr] (v2.east) -- (s2.west);
\draw[arr] (v2.east) -- (s5.west);
\draw[arr] (v3.east) -- (s3.west);

\end{tikzpicture}
\end{document}

Endnoten

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.