Architektur und Risikomanagement

Transkript

1 Architektur und Risikomanagement Zwei wie Pech und Schwefel Ihre Ansprechpartner: Goran Madzar Tel.: Thomas Kammerer Tel.:

2 Agenda Unser Beispiel AED Systemabgrenzung, Anwendungsszenarien Vorhersehbarer Missbrauch Systemkontext und Systemschnittstellen Beschreibende Sicherheit Schutzmaßnahmen Inhärent sicheres Design Gefährdungssituationen & Systemschnittstellen Umgebungsbedingungen Fehlerbaumanalyse & FMEA Systematik durch Systemmodelle Zusammenfassung Fahrplan zum sicheren Medizinprodukt 2

3 Automatischer Externer Defibrillator (AED) Kammerflimmern führt unbehandelt innerhalb kürzester Zeit zum Tod. AED leitet Helfer durch Reanimation AED analysiert selbständig EKG und trifft Entscheidung Anwender betätigt Schocktaste, damit Patient Defibrillationsimpuls erhält Unser Beispiel 3

4 Was macht eigentlich unser System und was macht es nicht? Die Systemabgrenzung durchführen!

5 Anwendungsfälle Gerät reparieren SW-Update durchführen Einsatzlogging Telemetrie Daten klauen Gerät unerlauberweise manipulieren Rettungsmittel instandsetzen / reparieren Einsatz dokumentieren Einsatzdaten auswerten Verbrauchsmaterial auffüllen Patientenzustand kontrollieren und überwachen Monitoring Techniker Trainings-Modus Üben Anwender Therapie AED-Modus Nicht vorschriftsgemäße Lagerung Funktionskontrolle durchführen Rettungsmittel lagern Funktion der Rettungsmittel kontrollieren Rettungsmittel reinigen Patienten transportieren Zum Rettungseinsatz fahren Transport in RTW Wiederverwendung von Einwegelektroden Funktionskontrolle nicht durchführen Selbsttest Status kontrollieren Reinigung des Gerätes Transport im Hubschrauber Legende Nutzungsszenarien Anwendung Defibrillator Misuse Case Was macht unser System was macht unser System nicht? 5

6 Wie sehen der Systemkontext und die Systemschnittstellen aus? Das System im Systemkontext darstellen Systemschnittstellen identifizieren!

7 Systemkontext Systemgrenze «device» Defibrillator Display Elektroden- Anschluss Alarm/Status LED Defi-Elektroden Elektroden-Stecker Klebeelektroden Schocktaste Patient Anwender Lautsprecher Label Gehäuse Umgebung «executione... Umgebung Tablet Service PC Funkschnittstelle Service Schnittstelle DC Eingang Netzteil AC-Stecker «executione... Netzversorgung Techniker Schrauben entnehmbarer Akku Akku Systemkontext und Systemschnittstellen 7

8 Hinweis zu Umgebungsbedingungen Umgebungsbedingungen sind mehr als Temperatur, Feuchte und Druck! Zu beachten sind auch: Verschmutzung Wasser Keime Mechanischer Schock und Vibration Magnetfelder Personen Fremdsysteme Untergrund EMV/ESD Strahlung Substanzen Luftreinheit Stromversorgung Umgebungsbedingungen sind vielfältig 8

9 Hinweis auf ISO Im Anhang finden wir Hinweise auf Umweltbedingungen 9

10 Instabilität des Systemkontexts Ändert sich das Nutzerverhalten? Ausbildung, Risikobewusstsein, Missbrauch, Reinigung? Ändern sich Zubehörteile? Stecker, Schläuche, Missbrauch Ändern sich Umweltbedingungen? Temperatur, Luftfeuchte, Lärm, Ändern sich Betriebsmittel? Betriebssystem, IT-Umgebung, Stromversorgung? Ist unser System auch dann noch sicher? Änderungen im Systemkontext können zu Gefährdungssituationen führen! 10

11 Instabilität des Systemkontexts Earthquake and Tsunami damage-dai Ichi Power Plant, Japan, Digital Globe, CC-Licence 11

12 Warum sind die Schnittstellen und Systemkontext so wichtig für das Risikomanagement? Weil sie die Stellen sind, wo Gefährdungen zu Gefährdungssituationen werden!

13 Kontext und Schnittstellen betrachten aus Redmill, Rajan: Human Factors in Safety-Critical Systems. Oxford Gefährdungssituationen finden wir an Systemschnittstellen und im Sytemkontext! 13

14 Das System an den Schnittstellen analysieren Elektrodenanschluss: Wie stellen wir sicher, dass nur Schock abgegeben wird, wenn die Schocktaste gedrückt wird?

15 Blockdiagramm Schockabgabe einkanalig Zerlegung des Systems in Blockdiagramm einkanalige Ausführung 15

16 Fehlerbaum für Schockabgabe Hazardous Situation (Gefährdungssituation) Unkontrollierte Schockabgabe Forderung: Erstfehlersicherheit! P F.MC1 OR Fehler in Micro Controller Fehler in HV-Endstufe Events (Ereignisse) OR P F.HV SW-Fehler HW-Ausfall Schnittstellenanalyse mit Fehlerbaum 16

17 Blockdiagramm Schockabgabe zweikanalig «device» Defibrillator SB1 Mikrocontroller 1 (GUI) Enable Enable HV-Endstufe Serielles IF Schocktaste Anwender Schock-Taste SB-Signal Serielles IF Elektroden- Anschluss Therapie Defi-Elektroden Elektroden-Stecker Klebeelektroden Patient SB2 Mikrocontroller 2 (Therapie) Control Control Check EnableStatus Zerlegung des Systems in Blockdiagramm Redundanz mit Entriegelung 17

18 Dynamisches Verhalten Anwender Schocktaste drücken() Schocktaste Mikrocontroller 1 (GUI) Mikrocontroller 2 (Therapie) HV-Endstufe Patient Schocktasten-Signal() Schocktasten-Signal() Freigabe der Endstufe() Schock-Befehl() Prüfen auf Plausibilität() Ansteuerung der Endstufe() Therapie() Dynamisches Verhalten modellieren Redundanz der Signalpfade 18

19 Fehlerbaum für Schockabgabe Hazardous Situation (Gefährdungssituation) Unkontrollierte Schockabgabe P F.MC = P F.MC1 P F.MC2 OR Events (Ereignisse) AND P F.MC1 Fehler in MC 1 OR P F.MC2 Fehler in HV-Endstufe Fehler in MC 2 OR P F.HV Common Cause Fehler betrachten! SW-Fehler HW-Ausfall SW-Fehler HW-Ausfall Schnittstellenanalyse mit Fehlerbaum - zweikanalig 19

20 Schockabgabe Architektur «device» Defibrillator SB1 Mikrocontroller 1 (GUI) Enable Enable HV-Endstufe Serielles IF Schocktaste Anwender Schock-Taste SB-Signal Serielles IF Elektroden- Anschluss Therapie Defi-Elektroden Elektroden-Stecker Klebeelektroden Patient SB2 Mikrocontroller 2 (Therapie) Control Control Check EnableStatus Mikrocontroller 1 (GUI) Mikrocontroller 2 (Therapie) HV-Endstufe Anwender Schocktaste Patient Schocktaste drücken() Schocktasten-Signal() Schocktasten-Signal() Freigabe der Endstufe() Schock-Befehl() Prüfen auf Plausibilität() Ansteuerung der Endstufe() Therapie() Risikokontrollmaßnahme Designmaßnahme: Redundanter Signalpfad, Entriegelung 20

21 Das System an den Schnittstellen analysieren Elektrodenanschluss: Elektroden können mehrfach verwendet werden!

23 Wiederverwendung von Einweg-Elektroden Beispiel: Risikominderung durch Information 23

24 Das System an den Schnittstellen analysieren Gehäuse: Unerlaubte Öffnung des Gehäuses

26 Schutzmaßnahme Schrauben können zu Missbrauch führen Integrität des Gerätes gefährdet Gefahr für den, der das Gerät öffnet Siegelplombe Schraube Risikomindernde Maßnahme durch Schutzmaßnahme 26

27 Appell für Architektur-Diagramme Systemgrenze «device» Defibrillator Display Elektroden- Anschluss Alarm/Status LED Defi-Elektroden Elektroden-Stecker Klebeelektroden «device» Defibrillator Anwender Schocktaste Schocktaste drücken() Mikrocontroller 1 (GUI) Mikrocontroller 2 (Therapie) HV-Endstufe Patient Anwender Tabelet Techniker Service PC Schocktaste Lautsprecher Label Umgebung Gehäuse Funkschnittstelle DC Eingang Service Schnittstelle entnehmbarer Akku Schrauben Netzteil AC-Stecker Akku Patient «executione... Umgebung «executione... Netzversorgung Anwender Schocktaste Schock-Taste Mikrocontroller 1 HV-Endstufe (GUI) SB1 Enable Enable Serielles IF SB-Signal Serielles IF Mikrocontroller 2 (Therapie) SB2 Control Control Check EnableStatus Elektroden- Anschluss Therapie Defi-Elektroden Elektroden-Stecker Klebeelektroden Patient Schocktasten-Signal() Schocktasten-Signal() Freigabe der Endstufe() Schock-Befehl() Prüfen auf Plausibilität() Ansteuerung der Endstufe() Therapie() Initial Stromlos [Stromversorgung vorhanden] [Stromausfall] [Stromausfall] Aus [Stromausfall] [Ausschaltsignal && SW-Update nicht aktiv] [Ausschaltsignal] [Einschaltsignal] An Gerät hochfahren [Ausfall EmPC] [Hochfahren beendet] Software Update Betrieb [SW Update] [Ausfall EmPC] Ausfall EmPC [Gerätefehler] Geräteausfall Modelle sagen mehr als 1000 Worte Architektur Diagramme helfen strukturiert vorzugehen Architektur Diagramme sind essenziell für Risikomanagement Aus Architektur-Modellen kann Dokumentation generiert werden. Traceability zu Architektur möglich Architektur Modelle Architektur Diagramme 27

28 Rückverfolgbarkeit Use Cases / Misuse Cases Anforderungen System Architektur Risikomanagement Dokumentation und Rückverfolgbarkeit 28

29 Systemkontext entwickeln 1. Nutzer und Nutzungsszenarien a) Nutzer identifizieren, b) Nutzerprofile erstellen, c) Nutzerkontext analysieren d) Aufgabenanalyse durchführen e) Nutzungsszenarien entwickeln und beschreiben 2. System abgrenzen a) Systemanwendungsfälle festlegen b) Systemschnittstellen identifizieren c) Systemfunktionen ableiten und analysieren 4. Systemkontext darstellen a) Systemkontextdiagramm verwenden b) Systemschnittstellen einzeichnen und benennen c) Systemschnittstellen beschreiben d) Umweltbedingungen nicht vergessen! 3. Vorhersehbarer Missbrauch a) Szenarien für vorhersehbaren Missbrauch betrachten und analysieren b) Miss-Use-Szenarien beschreiben Nutzerszenarien Systemabgrenzung vorhersehbarer Missbrauch - Systemkontext 29

30 Gefährdungssituationen ermitteln 1. Im Systemkontext a) Klinische Gefährdungen identifizieren b) Nutzungsszenarien bezüglich Gefährdungssituationen analysieren c) Gefährdungssituationen und sicherheitsrelevante Szenarien beschreiben 2. An Systemschnittstellen a) Schnittstellenanalyse bezüglich Gefährdungen und Gefährdungssituationen durchführen b) Mit Fehlerbaum visualisieren c) Risiken auf Systemebene bewerten 4. Entwurfstaktiken anwenden a) Risikomindernde Maßnahmen entwerfen b) Effekt der Maßnahme verifizieren und auf Systemebene betrachten c) Common Cause Fehler betrachten! d) Risiken auf Systemebene neu bewerten 3. Subsystemebene a) System risikobasiert in Subsysteme aufteilen b) Subsystemschnittstellen und Systemschnittstellen verbinden c) Fehlerbaumanalyse für Ursachen durchführen (Design, Produktion, Komponentenausfall) d) Für Komponenten FMEAs durchführen, um Ursachen zu identifizieren Architektur und Risikomanagement 30

31 hank ou! större - a multipurpose PowerPoint template