Philipp
Fabian
Preliminary Hazard Analysis
(Vorläufige Gefährdungsanalyse):
- Wird als High-Level-Analyse zu Beginn einer Entwicklungsphase durchgeführt
- Meist während der Anforderungsanalyse und des Entwurfsprozesses
- Eine grobe Beschreibung des Systems muss vorhanden sein
- Induktives Analyseverfahren (also vom Speziellen zum Allgemeinen)
- Es sollen Gefährdungen, Gefährdungssituationen und Ereignisse identifiziert werden
- Häufig wird von einer Aktivität oder einer Komponente ausgegangen und die sich daraus entstehenden Gefährdungen identifiziert
- Die Art und Weise der Dokumentation (Tabelle, Skizze, …) ist nicht definiert
- Manche Firmen erstellen eine grobe Klassifizierung in Schweregrade (Minor, Moderate, Major), wenn diesem Zeitpunkt eine Risikobewertungsmatrix vorliegt
- Nicht formalisiert (Brainstorming, Erfahrungen, Expertenmeinung, …)
- Es werden häufig Erfahrungen von Vorgängern oder ähnlichen Systemen verwendet
Da die vorläufige Gefährdungsanalyse typischerweise zu Beginn des Prozesses durchgeführt wird, bevor andere Analysetechniken durchgeführt wurden, hat diese Methode zwei wesentliche Einschränkungen:
- Es sind zusätzliche Folgeanalysen erforderlich. Da die PHA früh in der Entwicklung durchgeführt wird liegen auch nur vorläufige Systembeschreibungen und Architekturen vor. Es sind in der Regel zusätzliche Analysen erforderlich, um die vom PHA-Team identifizierten Gefährdungen und Gefährdungssituationen besser zu verstehen und zu bewerten.
- Die Qualität der Ergebnisse hängt stark vom Wissen des Teams ab. Zum Zeitpunkt einer PHA gibt es nur wenige oder gar keine ausgereiften Systemspezifikationen und wenig oder gar keine detaillierten Designinformationen. Daher stützt sich die Risikobewertung stark auf das Wissen der Spezialisten. Wenn diese Experten nicht an der Risikobewertung teilnehmen oder wenn es sich bei dem System um eine neue Technologie mit wenig oder gar keiner frühen Betriebsgeschichte handelt, werden die Ergebnisse der PHA die Unsicherheit des Teams in vielen Ihrer Bewertungen und Annahmen widerspiegeln.
Quellen:
- ISO 14971, Anhang G2
- IEC/ISO 31010
Fault Tree Analysis
(Fehlerbaumanalyse):
- Top-Down-Verfahren
- Zentrale Frage: “Welche Ursachen können zu einem bestimmter Schaden führen?”
- Was muss passieren? In welchem Zusammenhang?
- Geht von einem Schaden zur möglichen Ursache
- Es sollen Gefährdungen und Ereignisse identifiziert werden
- Benötigt Wissen über die System-Architektur
- Kombinationen von Ursachen bestimmen, die zu bestimmten unerwünschten Events führen
- Es werden Ereignisse mittels boolescher Operatoren (und/oder) verknüpft
- Dadurch können Zusammenhänge bzw. Ereignisketten dargestellt werden
- Es kann an dem Punkt aufgehört werden, wenn das Element beherrscht werden kann
- Üblicherweise als Baum dargestellt (wie schon aus dem Namen zu erahnen ist)
- Im regulieren Umfeld auch tabellarische Darstellung möglich
- Kann auch als mitgeltende Unterlage zur FMEA verwendet werden
- Im Gegensatz zur FMEA (monokausal) zeigt die FTA, dass ein Schaden mehrere Ursachen haben kann. Oder wie verschiedene Ursachen zusammenspielen müssen um zu einem Schaden zu führen.
- Pro Gefährdung einen Baum erstellen
Die FTA sucht zu gegebenen Wirkungen unbekannte Ursachen.
Quellen:
Failure Mode and Effect Analysis
(Fehlermöglichkeits- und Einflussanalyse):
- Bottom-Up-Verfahren
- Zentrale Frage: “Wie breiten sich Fehler aus und führen zu einem Schaden?”
- Induktives Verfahren, beginnend mit einzelnen Komponenten mit der ersten Fehler-/Auslöserursache
- Es sollen (unbekannte) Auswirkungen und Gefährdungen identifiziert werden, die von bekannten Ursachen verursacht werden
- Benötigt Wissen über das Gesamtsystem/Architektur
- Es sollte von den untersten Komponenten in der (Software)Architektur ausgegangen werden
- Es können auch Fremdkomponenten betrachtet werden (SOUP, Betriebssystem, Laufzeitumgebung, …)
- Auswirkungen untersuchen, die das Versagen einzelner Komponenten auf ein Gesamtsystem haben
- Kann als ein mögliches Verfahren verwendet werden um die Software-Sicherheits-Klasse zu argumentieren
- Üblicherweise als tabellarische Darstellung
- Risikoprioritätsziffer (RPZ) sehr problematisch und für die Anwendung mit der ISO 14971 nicht empfohlen
- RPZ widerspricht der Norm. Anhang D nennt diesen Fall explizit (“Dies bedeutet nicht, dass die beiden Faktoren multipliziert werden, um zu einem Risikowert zu gelangen.”)
- Anstatt der RPZ mit der Risikobewertungsmatrix arbeiten
Beispiel einer FMEA Tabelle für ein Endoskop (Tabelle kann vertikal und horizontal verschoben werden):
| Komponente / Funktion | (Erst)Fehler | Auswirkung auf das Subsystem | Auswirkung auf das Gesamtsystem | Möglicher Schaden | Erwartete Häufigkeit | Risiko |
|---|---|---|---|---|---|---|
| Bildrotation | Rechnet mit falschen Koordinaten | Liefert falschen Rotationswinkel | Gerät wird falsch positioniert | Schnittwunden | Schnittwunden | Akzeptabel (aus der Risikobewertungsmatrix) |
| Authentifizierung | Standardpasswörter während der Entwicklung nicht entfernt | Vertraulichkeit nicht gewährleistet | Vertraulichkeit nicht gewährleistet | innere Blutungen | Unwahrscheinlich | Nicht akzeptabel (aus der Risikobewertungsmatrix) |
| Authentifizierung | Fehler in der verwendeten Feldkomponente (oder falsch verwendet) | Verfügbarkeit nicht gewährleistet | Anwender kann Gerät nicht verwenden | Schmerzen | Selten | Nicht Akzeptabel (aus der Risikobewertungsmatrix) |
Die FMEA sucht zu einer angenommenen Ursache unbekannte Wirkungen.
Quellen:
- ISO 14971, Anhang G4
- IEC 60812
- https://www.johner-institut.de/blog/iso-14971-risikomanagement/fmea-bei-medizinprodukten/
Hazard and Operability
(Gefährdung und Beherrschbarkeit):
- Ähnlich einer FMEA
- Auf Deutsch: PAAG (Prognose, Auffinden der Ursache, Abschätzen der Auswirkungen, Gegenmaßnahmen)
- Ursprünglich für chemische industrielle Herstellungsverfahren
- Feststellen von Abweichungen bei der normalen Anwendung
- Es sollen Gefährdungen festgestellt werden
- Die Anforderungen und die Systemarchitektur muss bekannt sein
- Der Fokus liegt auf dem System und seinen Teilen
- Ist daher nicht geeignet zum Risiken durch mangelnde Gebrauchstauglichkeit zu identifizieren
- Kann zur Identifizierung wesentlicher Leistungsmerkmale verwendet werden
Definition wesentliches Leistungsmerkmal:
- Ein Leistungsmerkmal ist dann ein wesentliches Leistungsmerkmal, wenn es bei Fehlen oder Verschlechterung zu einem unvertretbaren Risiko führen kann. (nach IEC 60601-1)
Die Ereigniskette wird in beide Richtungen analysiert (Ursache und Folgen)
- FMEA: Von der Ursache zu den Folgen (“bottom up”)
- FTA: Von den Folgen zur Ursache (“top down”)
Damit ist die HAZOP ist kein alternatives, sondern ein zusätzliches Verfahren, was die vollständige Dokumentation des Systems voraussetzt.
Quellen:
- ISO 14971, Anhang G6
- IEC 61882
- https://www.johner-institut.de/blog/iso-14971-risikomanagement/hazop-iec-61882/
Zusammenfassung dieser Episode
- Es wurden nur Verfahren zur Risikoanalyse vorgestellt
- Gefährdungen identifizieren
- Gefährdungssituationen und vorhersehbaren Ereignisabläufe identifizieren
- Das Risikomanagement umfasst jedoch noch viel mehr
- Risikomanagement Prozess
- Zweckbestimmung
- Risikobewertungsmatrix
- Risikobewertung
- Risikominimierung
- Bewertung der Akzeptanz der Gesamtrisiken
- Risikomanagementbericht
- Nachgelagerte Phase
- CAPAs, Interne Audits, Kundenfeedback, nicht konformes Material, …
Schreibe einen Kommentar