Safety Integrity Level (SIL): Essentiell für die funktionale Sicherheit
Ob Autos, Flugzeuge oder Züge: überall, wo ein Fehler große Kosten oder Menschenleben kosten kann, gibt es Sicherheitsanforderungsstufen, oder Safety Integrity Level auf Englisch. Jeder Systems Engineer sollte zumindest die Grundlagen von SIL kennen. Darum geht es im Folgenden.
IEC 61508
Die Norm IEC 61508 ist eine der wichtigsten Normen im Systems Engineering und definiert den Begriff „Safety Integrity Level“. Die Norm ist die Grundlage für eine ganze Anzahl von Standards für spezifische Awendungsbereiche der funktionalen Sicherheit (FuSi). Eine der bekannteren, aufgrund des einprägsamen Namens, ist die ISO 26262 aus der Fahrzeugentwicklung. Das folgende Bild gibt eine Übersicht:
Safety Integrity Level (SIL)
In einer sicherheitskritischen Entwicklung wird nun jeder relevanten Funktion oder Anforderung ein Sicherheitsintegritätslevel zugewiesen. Dieses Level zu erreichen ist das Ziel. Die ISO 61508 arbeitet mit vier numerischen Levels (SIL 1-4), wobei Level 4 das höchste ist. Nicht sicherheitskritischen Funktionen wird das fünfte Level QM zugewiesen.
Nicht alle spezifischen Standards bleiben bei diesen Bezeichnungen. Die Eisenbahnindustrie zum Beispiel benutzt die Level A-D (EN 5012x). Die Automobilindustrie hingegen bleibt zwar bei den Levels 1-4, nennt diese jedoch ASIL (ISO 26262, Automotive Safety Integrity Level).
Dazu gibt es unterschiedliche Bewertungskriterien. Zum Beispiel können wir mit Ausfallwahrscheinlichkeiten arbeiten. Zum Beispiel muss bei SIL4 und kontinuierlichem Betrieb die Wahrscheinlichkeit eines Ausfalls mit katastrophalen Folgen kleiner als 10−8 pro Stunde sein. (Fußnote: Welcher FuSi-Experte wird mich jetzt korrigieren, weil ich irgendetwas doch falsch formuliert habe?).
Akzeptables Risiko
In manchen Anwendungsbereichen akzeptieren wir ein Risiko eher als in anderen. Gerade bei der Entwicklung medizinischer Geräte (ISO 14971) sind wir oft bereit, Risiken einzugehen. Denn hier ist die Alternative (Krankheit und deren Folgen) oft schlimmer. Daher wird hier typischerweise mit einer Risikoakzeptanzmatrize gearbeitet.
Diese Matrix zeigt sehr schön, dass Risikoanalyse mehrdimensional ist: Im medizinischen Bereich können wir Risiken nicht ausschließen. Aber kleinere Risiken sind akzeptabel. Für größere Risiken müssen entsprechende Gegenmaßnahmen ergriffen werden (Mitigations).
Wir kennen solche Wahrscheinlichkeiten auch aus den Beipackzetteln in Medikamenten.
Dekomposition vom Safety Integrity Level
Eine der großen Herausforderungen im Systems Engineering ist die Dekomposition von Systembeschreibungen und der richtige Umgang mit SIL-Levels. Auch hier gibt es unterschiedlich aufwändige Techniken, welche aber die industriespezifischen Standards teilweise vorschreiben. Ein recht bekannter ist die Fehlerbaumanalyse, bei der die Ausfallwahrscheinlichkeiten einzelner Komponenten logisch miteinander verknüpft werden, um die übergeordnete Ausfallwahrscheinlichkeit zu bestimmen. Die Technik stammt aus der Nuklearindustrie, wird aber auch in der Luftfahrt und Eisenbahnindustrie eingesetzt.
Im Automobilumfeld, wo viel mit natürlichsprachigen Spezifikationen gearbeitet wird, wird auch mit Regeln gearbeitet, die ASIL-Level der verschiedenen Ebenen in Relation zueinander setzen. So kann eine Anforderung, die als ASIL 4 klassifiziert wird, nicht Anforderungen mit einem niedrigeren Level heruntergebrochen werden. Doch das ist eine vereinfachte Darstellung. Jörg Schacht hat einen extrem guten Blogeintrag zu diesem Thema geschrieben.
Die Mathematik der Dekomposition laut ISO 26262:
Jörg Schacht
ASIL A(D) ≠ ASIL D
Systematische Probleme
Wie so oft im Systems Engineering müssen wir gerade bei der funktionalen Sicherheit den Faktor Mensch unbedingt berücksichtigen. Auch darauf gehen die Standards ein. Zum Beispiel ist es wichtig, dass bei bestimmten Reviews Autor und Reviewer nicht die selbe Person sind.
Und auch mit Konflikten und Machthierarchien müssen wir umgehen können. Wie auch schon beim Testen hat das Management manchmal die schlechte Angewohnheit, bei Verzögerungen an den stellen zu kürzen, wo nichts „Anfassbares“ bei herauskommt. Ich habe auch schon Anekdoten gehört, wo der Manager versuchte den Ingenieur davon zu „überzeugen“, dass eine Funktion im Steuergerät ja doch eher fürs Infotainment sei und daher als „ASIL QM“ klassifiziert werden sollte und nicht „ASIL C“…
Fazit
Jeder Systems Engineer wird früher oder später mit dem Thema Safety Integrity Level, bzw. SIL, in Berührung kommen. Das Thema wird auch immer wichtiger, da immer mehr komplexe Geräte in unseren Lebensraum eindringen (Stichwort IoT).
Ich habe einen hohen Respekt vor erfahrenen FuSi-Experten. Dieser kurze Artikel kann nicht einmal ansatzweise in das Thema einführen. Aber gerade deshalb ist es wichtig, dass wir zumindest die Grundlagen kennen, damit die funktionale Sicherheit nicht zu kurz kommt und wir den FuSi-Experten den Freiraum geben, den sie für ihre Arbeit benötigen.
