Management der funktionalen Sicherheit

In immer mehr Anwendungen und Branchen zieht die funktionale Sicherheit ein. Der Grund hierfür ist die steigende Komplexität, die mit sog. elektrischen, elektronischen und vor allem programmierbaren Systemen einhergeht. Wenn potentiell auch Gefahren für Gesundheit und Leben bestehen, legen Behörden und auch Standards Wert auf die Anwendung von Best Practices.
Aber auch im Bereich der funktionalen Sicherheit darf abgewogen werden. Dahinter steht der ganz richtige Gedanke, dass ein permanentes Einfordern jedweder maximal denkbarer Forschungstiefe ebenfalls gefährlich ist.

Die Konsequenz wären dann nämlich kaum mehr weiterentwickelte Sicherheitssysteme. Nicht nur unreif entwickelte Systeme sind gefährlich – gar nicht mehr entwickelte Systeme bzw. fehlende Sicherheitssysteme sind im Vergleich zu den sonst durchaus denkbaren und wirksamen Systemen eben auch eine Art von Gefährdung.

Darum ermöglichen es die entsprechenden Standards anhand verschiedene Gefährdungsklassen (Klassen, Sicherheitsintegritätslevels, Performance Levels, ASILs etc.) die zu ergreifenden Maßnahmen abzustufen. Erst in den hohen Gefährdungsklassen wird dann das Maximum bewährter Maßnahmen gefordert. In kleineren Gefährdungsklassen darf erwogen werden, bestimmte Bestätigungen schon nachgewiesener Kausalitäten anzupassen.

Ohnehin spielen Abwägungen eine große Rolle: auch hier zeigen ISO 26262 oder IEC 61508 viel gesunden Menschenverstand. Zwar gibt es Vorstellungen von Prozessen und Projektabläufen. Trotzdem gibt es über das sog. Tailoring die Möglichkeit diese Vorgaben an die konkrete Umgebung anzupassen. Im Fokus steht also nicht der Götzendienst sinnlos erstellter Dokumente, unter dem manchen QM-System leidet. Der Spielraum für ein Produkt wirklich sinnlose Vorgabe-Anteile zu streichen, ist explizit eingeräumt.
Der Geist dieser Standards ist tatsächlich nicht der, dass nur ein verhindertes Produkt auch eine sicheres ist. Ganz im Gegenteil: trotz der zunächst komplex erscheinenden Vorgaben, ist durchweg erkennbar, dass die Autoren hier bemüht waren, die Entwicklung auch dieser sensiblen Systeme zu ermöglichen und nicht zu erdrosseln.

Tatsächlich wird an den vielen Stellen kaum mehr verlangt, als für die Erreichung guter Produktmerkmale ohnehin nötig wäre. Natürlich kann man es aber bei einer Spiele-App hinnehmen, dass sie ggf. einmal abstürzt und der Nutzer gar einen Punktestand verliert. Beim Zünden eines Airbags sollte das ungleich weniger der Fall sein, wenn die Situation einen Airbag erfordert. Darum ist es bei der Spiele-App eben nur eine Kosten-Nutzen-Abwägung, wenn man etwa die qualitätssichernden Code-Reviews einspart. Trotzdem ist beispielsweise diese Maßnahme in beiden Fällen eine sehr geeignete zur Sicherung von Code- und Produktqualität. Im Airbag-Fall wäre für ein Software-Modul die Streichung der Methode aus Kostengründen aber einleuchtender Weise recht problematisch.

Wenn Sie Unterstützung beim Verstehen der großen Werkzeugkisten zur funktionalen Sicherheit brauchen, nehmen Sie doch einfach Kontakt mit uns auf.

  • Durchführung von Workshops zur funktionalen Sicherheit
  • Beratung zum Tailoring
  • Beratung zu den Methoden und deren Anwendung, z.B.
    • FMEA
    • FTA (Fehlerbaumanalyse)
    • Code Reviews
    • Test-Automation
    • Usability-Test
  • Unterstützung bei der Erstellung zahlreicher der sog. Work Products, z.B.
    • Safety Case
    • Impact Analysis
    • Requirements
    • Gefahren- und Risikoanalyse (HARA)
    • Risikomanagement
    • Funktionales Sicherheitskonzept
    • Technisches Sicherheitskonzept
    • Verifizierungsplan