Architekturmuster in
sicherheitsgerichteten
Systemen

Folie 1
16. Oktober 2013

Daniel Mölle
© Zühlke 2013
Der Musterbegriff

Architekturmuster in
sicherheitsgerichteten
Systemen
Folie 2
16. Oktober 2013

Daniel Mölle
© Zühlke 20...
Sicherheitsgerichtete
Systeme

Architekturmuster in
sicherheitsgerichteten
Systemen
Folie 4
16. Oktober 2013

Daniel Mölle...
Sicherheitsbedürfnis/
Risikominimierung

Domänenspezifische
Gesetze

Z.B.:
Medizinprodukte
-richtlinie/-gesetz

Anzuwenden...
Architekturmuster

Architekturmuster in
sicherheitsgerichteten
Systemen
Folie 6
16. Oktober 2013

Daniel Mölle
© Zühlke 20...
Wichtige Begriffe

Fehler

Fehlertypen

Fault:
Fehlerzustand

stochastisch

Failure:
Fehlerwirkung

systematisch

Der Bug ...
Zum Aufwärmen:
(#1) Redundanz

Quelle: Wikimedia Commons
Architekturmuster in sicherheitsgerichteten Systemen | Daniel Möl...
Nächster Schritt:
(#2) Diversität
Und jetzt asymmetrisch:
(#3) Aktuator/Monitor
Apropos Monitoring:
(#4) Programmlaufüberwachung
Apropos Monitoring:
(#5) Selbsttest
Trade-Offs (1/2)

Aktuator A

Monitor A
Selbsttest

Aktuator B

Monitor B
Programmlaufüberwachung

Aktuator C
Architekturm...
Trade-Offs 2/2

Geringe Kosten

Hohe Verfügbarkeit
Architekturmuster in sicherheitsgerichteten Systemen | Daniel Mölle

Ho...
Von der Erkennung zur Behandlung:
(#6) Units of Mitigation
Und wenn es doch nicht lokal geht:
(#7) Escalation
Ausweitung des Systembegriffs

Software

Elektronik

Mechanik

Anwender
Architekturmuster in sicherheitsgerichteten System...
Bedienfehler vermeiden:
(#8) Minimize Human Intervention
Auf zum Widerspruch?
(#9) Maximize Human Participation
Quelle: Wikimedia Commons
Architekturmuster: Fazit
Über den Tellerrand…

Architekturmuster in sicherheitsgerichteten Systemen | Daniel Mölle

16. Oktober 2013

Folie 22

© Z...
Fragen?
Daniel Mölle
Architekturmuster in sicherheitsgerichteten systemen med conf2013
Nächste SlideShare
Wird geladen in …5
×

Architekturmuster in sicherheitsgerichteten systemen med conf2013

764 Aufrufe

Veröffentlicht am

Abstract: Wenn Informatiker von patterns sprechen, dann meinen sie meist abstrakte Strukturen, die sich in vielen konkreten Fällen sinnvoll anwenden lassen. Derartige Muster haben sich mittlerweile auf vielen Ebenen herausgebildet: Es gibt die berühmtem design patterns, Echtzeit-Entwurfsmuster, patterns für fehlertolerante Systeme, Architekturmuster, problem frames und vieles mehr. Der Vortrag beginnt mit einem Einblick in die Geschichte und die Bedeutung dieser Muster. Im Hauptteil werden konkrete Architekturmuster vorgestellt, vor allem aber in Bezug auf zwei für die MedConf wichtige Fragen bewertet: Wie eignen sie sich für den Einsatz in Projekten mit klarem Safety-Fokus, und wie verhalten sich jeweils Kosten und Nutzen zueinander?
Zielgruppe: Der Vortrag umfasst sowohl eine systematische technische Einführung als auch eine technisch-kommerzielle Bewertung mit Erfahrungsberichten aus der Praxis. Er richtet sich natürlich an Architekten und Entwickler, istaber auch für Projektleiter und Entscheider geeignet, die den Einfluss fundamentaler Designentscheidungen auf Projekte bewerten können möchten.
Was lernen die Zuhörer in dem Vortrag: Die systematische Einführung sollte ein klares Verständnis dafür erzeugen, was genau Architekturmuster sind, wie sie entstehen und wo sie eingesetzt werden können. Der Hauptteil des Vortrags geht dann weit über das Zitieren ausgewählter Muster hinaus - das Augenmerk liegt vielmehr auf Erfahrungen in der Anwendung und kritischen Gedanken, die zukünftige Entscheidungen erleichtern mögen.

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
764
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
204
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Muster: Vor 20 Jahren ein unüblicher Begriff. Dann kam 1994 „Design Patterns“ der GoF heraus – mit softwaretechnischen Standardrezepten, die aus der gesammelten Praxiserfahrung der Autoren destilliert waren. Seitdem stehen „Muster“ in der Branche für eine Professionalisierung der Software-Technik, bei der die systematische Anwendung bewährter Rezepte im Vordergrund steht - das Gegenteil von intuitiv-individuellem „cowboycoding“. Die positive Besetzung des Musterbegriffs resultierte später in vielen entsprechend benannten Büchern, Artikeln und Konferenzbeiträgen… sowie in Trittbrettfahrern, bei denen das Wort „(anti-)patterns“ suggerieren soll, dass hier etwas besonders Gehaltvolles vorläge.
  • 1. Ganz allgemein sprechen wir von einem sicherheitsgerichtetenSystem, wenn es auf die Erfüllung von Sicherheitsbedürfnissen ausgelegt ist. Diese erwachsen natürlich aus potentiellen Bedrohungen und verlangen eine Risikominimierung.2. Je nach Domäne spiegelt sich dieses Sicherheitsbedürfnis in den gesetzlichen Bestimmungen wider, für die Medizintechnik z.B. in MDD und MPG. Allerdings sind diese Bestimmungen oft sehr abstrakt.3. Eine Konkretisierung erfahren die Gesetze durch die entsprechenden Normen. Diese vereinheitlichen Begriffe und Verfahren, liefern hilfreiche Hinweise z.B. zu geeigneten Verfahren und sind ferner mit einer gewissen Arbeitskultur verbunden (z.B. bezüglich der Interpretation von „Stand der Technik“), was zusätzliche Orientierung bietet.4. Projektspezifische Maßnahmen bilden das konkrete Ende der Ableitungskette.
  • Aufgemerkt: Architekturmuster sind etwas anderes als Entwurfsmuster (Architektur versus Design eben). Es geht um das gesamte Softwaresystem – oder sogar mehr -, nicht um programming in thesmall.
  • “Single fault conditions”: Clause 13 of Third Edition IEC 60601-1.Johner:Generell kann Erstfehlersicherheit definitionsgemäß [60601-1] auf zwei Arten erreicht werden.(1) Man trifft eine Maßnahme, die das Risiko sicher (“mit einer vernachlässigbaren Wahrscheinlichkeit eines Versagens”) vermindert. Ein typisches Beispiel ist ein ausfallsicherer Watchdog, der den Fehler einer Komponente (Erstfehler) erkennt und das Gerät in einen sicheren Zustand bringt.(2) Man hat eine Maßnahme getroffen, welche Risiken nicht sicher minimiert, diese erste Maßnahme aber durch eine zweite Maßnahme ergänzt wird [sic]. Die Wahrscheinlichkeit, dass diese zweite Maßnahme ausfällt, muss vernachlässigbar sein.„Software, die prinzipiell zu unvertretbaren Risiken führen kann, lässt sich nicht durch eine wie auch immer geartete Maßnahmen innerhalb der gleichen Software erstfehlersicher gestalten.“ (Christian Johner)Hier ein kleiner Überblick:Rüstzeug zur Analyse von Architekturmustern in Bezug auf ihre Eignung in SGS.ISTQB orIEEE 610.12-90 / Software Engineering Body of Knowledge:- Mistake: A human action that produces an incorrect result.- Error: Often synonymous for mistake. Occasionally also: A difference...between a computed result and the correct result- Fault: An incorrect step, process, or data definition in a computer program- Failure: The [incorrect] result of a faultStochastische Fehler sind z.B. Bitkipper, Ausfall technischer Bauteile usw.Zur Fangfrage: Alle SW-Bugs sind systematisch – auch wenn sie nur sporadisch auftreten, etwa weil die Vorbedingungen nur sporadisch erreicht werden.
  • Wir betrachten hier den einfachsten Fall: Zwei identische „Kanäle“. Natürlich gibt es etwas allgemeiner auch die m-aus-n-Redundanz (z.B. zwei aus vier Triebwerken).Unterscheidung: Stochastische versus systematische Fehler. Redundanz hilft natürlich nur bei ersteren.Beispiele: Zwei identische Mikrocontroller, zwei identische Firmware-Binaries (entstanden aus demselben Quelltext und mit derselben Toolchain)… analysiere Bitkipper versus Software-Bug.
  • Im Vergleich zu Redundanz: Verschiedene Personen setzen verschiedene Lösungswege um, aber die äußere Funktion ist dieselbe.Achtung: Kein automatischer Ausschluss des singlepointoffailure (z.B. arbeiten beide auf Grundlage derselben Spezifikation).
  • Kontinuierliche Überwachung: Werden wichtige Funktionen wie erwartet ausgeführt (periodisch/bedingt)?
  • Test wichtiger Funktionen, Sensoren o.ä. – meist zu klar definierten Zeitpunkten, beispielsweise beim Einschalten des Gerätes.
  • Analog zum „irontriangle“ der Projektleitung: Scope, Budget, Zeit (bei gleicher Qualität).Spannender Punkt: Verfügbarkeit ist in der Medizintechnik nicht von zentraler Bedeutung (da Personalruf ausreicht). Ausnahme: Infusionssysteme (FDA). Ganz anders sieht es in anderen Bereichen aus, z.B. Avionik.
  • Fehler innerhalb eines begrenzten Bereichs (z.B. Komponente) auflösen.Beispiel: Abschalten von Randfunktionalität (z.B. PDMS bei Kommunikationsfehler).Alltagsbeispiel: Start-Stop-Automatik im Privatfahrzeug.
  • Wenn eine lokale Auflösung doch nicht möglich ist: Sukzessive eskalieren an übergeordnete „Behandlungscontainer“ (in Organisationen sehr üblich).
  • Unterschiedliche Architekturmuster haben unterschiedlichen Scope: Softwaresystem, Gesamtgerät, Gerät mit Anwender, Gerät mit Anwender und Arbeitsumgebung…Redundanz/Diversität/zweikanalige Überwachung findet sich vor allem in SW+EL.Diversität bei Mechanik ist eher unüblich (MRT mit zwei Röhren??).Was aber passiert, wenn wir den Anwender in unsere Betrachtungen aufnehmen?
  • Ein erheblicher Anteil der im Feld auffallenden Fehler sind tatsächlich Bedienfehler.Gerade bei schlecht geschultem Personal ist es von daher sinnvoll, Eingriffe zu reduzieren.Analogie: Entwurf sicherer Betriebssystem (ohne Rückfragen der Art „Soll cpqrtsvc.exe auf Port 8099 von 219.17.33.195 zugreifen dürfen (j/n)?“).
  • Der scheinbare Konflikt löst sich auf, sobald man erfährt, dass es in diesem Architekturmuster ausdrücklich um Menschen geht, die als Experten einzustufen sind.In diesem Fall nämlich ist davon auszugehen, dass der Nutzen eines Eingriffs durch Experten die damit verbundenen Risiken überwiegt.
  • Die Apollo-Anekdote:Die meisten Ingenieure, allen voran Wernher von Braun, hielten eine praktisch vollständige Kontrolle durch die Bordcomputer für den einzig gangbaren Weg.Die meisten Astronauten hingegen, unter anderem der erfahrene Testpilot Neil Armstrong, bestanden darauf, vor allem in kritischen Situationen jederzeit in die diversen Flugmanöver eingreifen zu können.Am Ende bewährte sich eine gesunde Mixtur aus beiden Ansätzen:Die Bordcomputer stellten sich als unverzichtbar heraus, was die komplexe Navigation und die Beherrschung der oft völlig unintuitiven Flugmechanik betraf.Die Astronauten hingegen konnten durch beherztes Eingreifen mehrere Katastrophen abwenden, beispielsweise beim Ausfall der Bordcomputer durch Überlast ("Alarm 1202") im Rahmen der Mondlandung von Apollo 11.
  • - Dem Siegeszug des Pattern-Begriffs ist es zu verdanken, dass wir heuteauch auf ein großes Repertoire an Architekturmustern zurückgreifen können.- Es gibt natürlich auch Architekturmuster, die in sicherheitskritischen Anwendungen nichts verloren haben.
  • - Ferner bleibt festzuhalten, dass die Popularität einzelner Architekturmuster von Domäne zu Domäne schwankt. Dieser Umstand ergibt sich aus den grundsätzlich verschiedenen Ausgangsbedingungen. (Beispiel:fail-safe state in Medizintechnik versus Avionik)- Dennoch lohnt sich ein Blick über den Tellerrand.- Die Eignung eines Musters muss natürlich im jeweiligen Einzelfall geprüft werden („itdepends“).
  • Architekturmuster in sicherheitsgerichteten systemen med conf2013

    1. 1. Architekturmuster in sicherheitsgerichteten Systemen Folie 1 16. Oktober 2013 Daniel Mölle © Zühlke 2013
    2. 2. Der Musterbegriff Architekturmuster in sicherheitsgerichteten Systemen Folie 2 16. Oktober 2013 Daniel Mölle © Zühlke 2013
    3. 3. Sicherheitsgerichtete Systeme Architekturmuster in sicherheitsgerichteten Systemen Folie 4 16. Oktober 2013 Daniel Mölle © Zühlke 2013
    4. 4. Sicherheitsbedürfnis/ Risikominimierung Domänenspezifische Gesetze Z.B.: Medizinprodukte -richtlinie/-gesetz Anzuwendende Normen Z.B.: ISO 13485, 14971; EN 62304, 62366, 60601 Konkrete Maßnahmen Projektspezifische Maßnahmen
    5. 5. Architekturmuster Architekturmuster in sicherheitsgerichteten Systemen Folie 6 16. Oktober 2013 Daniel Mölle © Zühlke 2013
    6. 6. Wichtige Begriffe Fehler Fehlertypen Fault: Fehlerzustand stochastisch Failure: Fehlerwirkung systematisch Der Bug tritt nur sporadisch auf… Architekturmuster in sicherheitsgerichteten Systemen | Daniel Mölle 16. Oktober 2013 Folie 7 © Zühlke 2013
    7. 7. Zum Aufwärmen: (#1) Redundanz Quelle: Wikimedia Commons Architekturmuster in sicherheitsgerichteten Systemen | Daniel Mölle 16. Oktober 2013 Folie 8 © Zühlke 2013
    8. 8. Nächster Schritt: (#2) Diversität
    9. 9. Und jetzt asymmetrisch: (#3) Aktuator/Monitor
    10. 10. Apropos Monitoring: (#4) Programmlaufüberwachung
    11. 11. Apropos Monitoring: (#5) Selbsttest
    12. 12. Trade-Offs (1/2) Aktuator A Monitor A Selbsttest Aktuator B Monitor B Programmlaufüberwachung Aktuator C Architekturmuster in sicherheitsgerichteten Systemen | Daniel Mölle Monitor C 16. Oktober 2013 Folie 13 © Zühlke 2013
    13. 13. Trade-Offs 2/2 Geringe Kosten Hohe Verfügbarkeit Architekturmuster in sicherheitsgerichteten Systemen | Daniel Mölle Hohe Sicherheit 16. Oktober 2013 Folie 14 © Zühlke 2013
    14. 14. Von der Erkennung zur Behandlung: (#6) Units of Mitigation
    15. 15. Und wenn es doch nicht lokal geht: (#7) Escalation
    16. 16. Ausweitung des Systembegriffs Software Elektronik Mechanik Anwender Architekturmuster in sicherheitsgerichteten Systemen | Daniel Mölle 16. Oktober 2013 Folie 17 © Zühlke 2013
    17. 17. Bedienfehler vermeiden: (#8) Minimize Human Intervention
    18. 18. Auf zum Widerspruch? (#9) Maximize Human Participation
    19. 19. Quelle: Wikimedia Commons
    20. 20. Architekturmuster: Fazit
    21. 21. Über den Tellerrand… Architekturmuster in sicherheitsgerichteten Systemen | Daniel Mölle 16. Oktober 2013 Folie 22 © Zühlke 2013
    22. 22. Fragen? Daniel Mölle

    ×