PQRST - Funktionale Sicherheit und SOTIF

 

PQRST Software-Lebenszyklus

Funktionale Sicherheit (Functional Safety) betrachtet mögliche Gefahren von Produkten, die durch Fehlfunktion ausgehen und dabei Menschen gefährden können. Dies ist in Situationen relevant, wo die Sicherheit von Funktionen von dem betrachteten Produkt abhängt. Das Produkt muss dabei entweder korrekt funktionieren oder im Fehlerfall gezielt einen sicheren Zustand einnehmen.

Der Begriff der funktionalen Sicherheit hat sich mittlerweile in einer Vielzahl von Feldern etabliert, seien es komplexe Industrieanlagen, Bahnsysteme oder im Automotive-Bereich. Die Anforderungen an die Sicherheitsintegrität (SI = Safety Integrity) werden typisch mit SIL 0 (minimale Anforderungen, auch Basisintegrität genannt) bis SIL 4 (maximale Anforderungen) benannt. Im Automotive-Bereich hat sich der ASI-Level (ASIL A...D) durchgesetzt.

Funktionale Sicherheit betrachtet zufällige und systematische Fehler. Zufällige Fehler werden hauptsächlich durch Hardware und deren Ausfallsraten bestimmt. Sie lassen sich quantitativ bewerten und durch gezielte Auswahl und zusätzliche Maßnahmen gut beherrschen.

Systematische Fehler entstehen hauptsächlich in Software und entstehen durch Unzulänglichkeiten von Menschen. Sie lassen sich nicht berechnen, sondern nur mit strikten Vorgangsmodellen und weiteren Maßnahmen wie Verifikationen pro Phase in den Griff bekommen. Mit der EN 50155:2017 wird beispielsweise für Schienenfahrzeuge auch bereits für Basisintegrität eine Minimaldokumentation des Software-Lebenszyklus nach EN 50657 verlangt.

SOTIF (Safety Of The Intended Functionality) ist ein vergleichsweise neuer Aspekt, der die Sichtweise der funktionalen Sicherheit ergänzt. SOTIF stellt sich dabei die Frage, wie sicher die eigentlichen Funktionen eines Produkts sind. Ein erklärendes Beispiel findet sich zB in der ISO/PAS 21448. Die Funktion, ein Kind auf einer Fahrbahn zu erkennen (und ein Bremsmanöver o.ä. einzuleiten) kann dadurch fälschlich ausgelöst werden, wenn auf der Fahrbahn derartige Zeichnungen vorhanden sind und dies zu einer Erkennung mit Folgeauswirkungen führen kann.

 

Der Software-Lebenszyklus selbst ist ein komplexer Kreislauf mit vielfältigen und unterschiedlichen Elementen. Da es für Hardware keine vergleichbaren ausführlichen Lebenszyklusmodell gibt, kann das Vorgehensmodell für Software auch für Hardware umgelegt und angewendet werden. Ergänzende Informationen zu Vorgehensmodelle dazu finden Sie auch unter Software-Engineering.

Jede Stufe hat dabei ihre Bedeutung für gute und richtige Endergebnisse. Ich unterstütze dabei hauptsächlich mit der Erstellung und dem Review von Lastenheften und Pflichtenheften, mit Requirements Engineering und Requirements Management (Erstelllung und Review von Anforderungen/Design-Dokumenten/Change Management/Testfällen) sowie dem Qualitäts- und Sicherheitsmanagement (Verifikation und Validierung) in sicherheitsrelevanten Systemen (Automotive, Eisenbahnindustrie u.dgl.).

 

Weiterführende Dokumente:

Software-Lebenszyklus

Lastenheft und Pflichtenheft
Qualitätskriterien für Lastenhefte
Scope Modelling
Use-Cases
Sequenz-Diagramme

Anforderungen in der Business Analyse

Projekthandbuch
Goto Qualitätsprozesse in Projekten Begriffs- und Abkürzungsverzeichnis

Goto Qualitätsprozesse in Projekten Qualitäsprozesse in Projekten