Kopfbereich

Schnellnavigation

Hauptnavigation

Gefährdungs- und Risikoanalytik

Damit ein Produkt auf dem Markt in Verkehr gebracht werden kann, muss der Hersteller die dazu notwendigen rechtlichen Anforderungen erfüllen. Diese Anforderungen mögen im Detail, je nach Produktart, unterschiedlich sein, gemeinsam ist ihnen jedoch, dass der Hersteller mittels einer Gefährdungs- und Risikoanalyse nachweisen können muss, dass sein Produkt weder Mensch noch Umwelt nicht tolerierbaren Risiken aussetzt.

Um Produktanforderungen und -auslegung so zu definieren, dass ein tragbares Risikoniveau erreicht werden kann sollten Gefährdungs- und Risikoanalysen bereits in den ersten Phasen des Entwicklungsprozess durchgeführt werden. Insbesondere rücken diese Analysen bei sicherheitskritischen Systemen, in denen sicherheitsbezogenen Anforderungen naturgemäss eine wesentliche Rolle zukommt, in den Vordergrund.

Neben den klassischen Analysemethoden, wie FMEA oder FTA, die wir anwenden, forschen wir im Bereich der systemtheoretischen Modellierung und Analyse komplexer technologischer und sozio-technologischer Systeme.

Wir unterstützen Sie bei der Planung und Durchführung von Gefährdungs- und Risikoanalysen, direkt in konkreten Projekten oder durch zielgerichtete Schulungen.

Methodische Vielfalt

Die Risikoanalytik bedient sich diverser, teilweise seit langer Zeit etablierter Methoden, welche je nach Entwicklungsphase zur Anwendung kommen können.

In den frühen Phasen der Entwicklung können Gefährdungsanalysen bereits auf Konzeptbasis durchgeführt werden. Hier bietet sich zum Beispiel die Durchführung einer Vorläufigen Gefährdungsanalyse (Preliminary Hazard Analysis, PHA) an, um potentielle, vom System ausgehende Gefahren erkennen und bewerten zu können, und diese bereits durch Anpassung des Systementwurfs oder der Forderung zusätzlicher Schutzmassnahmen entschärfen zu können.

Gefährliches Systemverhalten kann natürlich durch unterschiedliche Ursachen ausgelöst werden, was wiederum dazu führt, dass unterschiedliche, diesen Ursachen angepasste Risikominderungsmassnahmen definiert werden können. Eine „top-down“ Dekomposition der Gefährdungen, je nach Ursache, kann zum Beispiel mittels einer Fehlerbaumanalyse (Fault Tree Analysis, FTA) durchgeführt werden. Auf diesem Weg können verfeinerte Risikominderungsmassnahmen spezifiziert werden.

Ist der Entwurf des Systems bereits detailliert bekannt, kann die Fehlermodus- und Einflussanalyse (Failure Mode and Effects Analysis, FMEA) angewendet werden. Ausgehend von den Fehlermodi einzelner Systemeinheiten wird „bottom-up“ untersucht, welchen Einfluss diese auf das Gesamtsystem haben. So kann zum Beispiel geprüft werden ob alle potentiell gefährlichen Komponentenfehler in einer elektronischen Schaltung ausreichend durch Risikominderungsmassnahmen abgedeckt sind.

Neben diesen klassischen Methoden gibt es ein breites Spektrum an weiteren Werkzeugen, zum Beispiel der ETA, HAZOP, HACCP, LOPA, sowie auch verschiedene Methodenvarianten wie zum Beispiel der FMECA oder FMEDA. Diese Methodenvielfalt führt unweigerlich zu vielen Fragen: Welche dieser Methoden kann in welchen Phasen eines Entwicklungsprozesses nutzbringend eingesetzt werden? Welche Methoden können nur für rein qualitative, welche aber auch für quantitative Analysen eingesetzt werden? Wie lassen sich Ergebnisse aus einer Methode zielführend durch andere Methoden verfeinern?

Systemtheoretische Modellierung und Analyse

Typischerweise werden Unfälle als Folge einer Verkettung von einzelnen Ereignissen gesehen, wobei das auslösende Ereignis auf Komponentenversagen oder menschliche Fehlhandlung zurückgeführt wird. Für viele elektro-mechanische Systeme ist eine solche Betrachtungsweise nach wie vor angebracht und etablierte Methoden wie FTA (Fault Tree Analysis, Fehlerbbaumanalyse), ETA (Event Tree Analysis, Ereignisbaumanalyse) sowie FMEA (Failure Mode and Effect Analysis, Fehlermöglichkeits- und -einflussanalyse) sind ideal geeignet, um potentiell ungewolltes Verhalten solcher Systeme zu analysieren und zu bewerten.

Systems-Theoretic Process Analysis (STPA)

Für die Analyse komplexer, dynamischer und oft sehr stark software-basierter Systeme, wie sie heute zur Steuerung von Anlagen eingesetzt werden, greifen die klassischen Analysemethoden jedoch zu kurz. Die Ursachen von Unfällen können nicht mehr ausschliesslich auf Komponentenversagen und eine Verkettung einzelner Fehler zurückgeführt werden, vielmehr muss die Interaktion zwischen korrekt funktionierenden Komponenten (im Sinne ihrer Spezifikation) und somit das emergente Verhalten eines Systems, dessen einzelne Bestandteile nicht versagen, als Gesamtheit zusätzlich analysiert werden.

Basierend auf dieser Erkenntnis wird von Prof. Nancy Leveson vom MIT (Massachusetts Institute of Technology) vorgeschlagen, den Aspekt der Sicherheit aus Sicht der System-Theorie zu betrachten. Zu diesem Zweck hat Prof. Leveson eine innovative Analyse-Methodik zur Gefährdungsanalyse, die Systems-Theoretic Process Analysis (STPA), aufgebaut.

STPA ist eine Gefährdungsanalysemethode welche Sicherheit als emergente Eigenschaft eines gesamtheitlich betrachteten sozio-technologischen Systems untersucht. Der Mensch kann mit seinen Handlungen ebenso in der Analyse betrachtet werden wie programmierbare Einheiten. Weiter ist STPA als Top-Down Methode ausgelegt, und eignet sich deshalb insbesondere für den entwicklungsbegleitenden Einsatz. Das Paradigma des Safety Guided Design wird somit greifbar.

STPA Hierarchische Kontrollstruktur

Beispiel einer hierarchischen STPA-Kontrollstruktur mit zwei Kontrollern sowie Kontrollaktionen (control actions) und Rückmeldungen (feedback channels). Diese funktionale Darstellung ist der Ausgangspunkt von STPA

Ausgangspunkt für die STPA Analyse ist die sogenannte hierarchische Kontrollstruktur, eine Darstellung des Systems aus funktionaler Sicht, in welcher der Kontroll- und Informationsfluss durch die Subsysteme explizit dargestellt wird.

In der hierarchischen Kontrollstruktur trägt jeder Kontroller, sei es ein Mensch oder ein Computersystem, die Verantwortung für die Umsetzung bestimmter Systemaufgaben und kann zu diesem Zweck, über Kontrollaktionen (Control Actions) Einfluss auf die hierarchisch unterstellten Ebenen nehmen. Die Entscheidungsgrundlage über die Ausgabe von Kontrollaktionen basiert auf dem Prozessmodell des Kontrollers. Dieses Prozessmodell enthält neben den kausalen Zusammenhängen zwischen System und Umwelt auch ein Abbild des aktuellen Systemzustands. Die Aufdatierung des Systemzustands geschieht über Rückmeldungen (Feedbacks) von untergeordneten Kontrollern oder dem gesteuerten Prozess selber. Handelt es sich beim Kontroller um ein Computersystem, kann das Prozessmodell zum Beispiel aus einem in Software umgesetzten Regel-Algorithmus bestehen. Handelt es sich hingegen beim Kontroller um einen Menschen, zum Beispiel um den Bediener eines technischen Systems, basiert sein Prozessmodell auf seiner Erfahrung im Umgang mit dem System und seiner Interpretation des Systemzustands.

STPA Analyseprozess

Die STPA-Analyse selber ist in zwei Teilschritte gegliedert:

STPA Step 1: Ziel des ersten Schritts ist es, potentiell gefährliche Kontrollaktionen (Unsafe Control Actions) zu identifizieren. Durch Anpassung des Systemdesigns lassen sich eventuell bereits solche Unsafe Control Actions eliminieren.

STPA Step 2: Im zweiten Schritt werden mögliche Ursachen und Szenarien, die zu den Unsafe Control Actions, respektive zu deren Folgen führen können, ermittelt. Hier können weitere Sicherheitsmassnahmen zur Risikominderung spezifiziert werden, oder bestehende Sicherheitssysteme auf mögliche Lücken hin untersucht werden.

Wir forschen aktiv an der weiteren Entwicklung und Konkretisierung dieser Methode im Kontext diverser Industriesektoren, mit dem Ziel deren Anwendbarkeit in einem industriellen Umfeld zu fördern.

Der STPA-Prozess (Links) umfasst zwei Teilschritte. Im zweiten Teilschritt (Step 2) werden anhand eines Kontrollkreislaufs (Rechts) mögliche Ursachen und Szenarien gesucht, die zu Unsafe Control Actions, respektive zu deren Folgen führen können.

Mehr zu STAMP, STPA und CAST

Projektbeispiele:

Weiterführende Informationen: