Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Architekturmuster in sicherheitsgerichteten systemen med conf2013

452

Published on

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 …

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
452
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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“).
  • Transcript

    • 1. Architekturmuster in sicherheitsgerichteten Systemen Folie 1 16. Oktober 2013 Daniel Mölle © Zühlke 2013
    • 2. Der Musterbegriff Architekturmuster in sicherheitsgerichteten Systemen Folie 2 16. Oktober 2013 Daniel Mölle © Zühlke 2013
    • 3. Sicherheitsgerichtete Systeme Architekturmuster in sicherheitsgerichteten Systemen Folie 4 16. Oktober 2013 Daniel Mölle © Zühlke 2013
    • 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. Architekturmuster Architekturmuster in sicherheitsgerichteten Systemen Folie 6 16. Oktober 2013 Daniel Mölle © Zühlke 2013
    • 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. Zum Aufwärmen: (#1) Redundanz Quelle: Wikimedia Commons Architekturmuster in sicherheitsgerichteten Systemen | Daniel Mölle 16. Oktober 2013 Folie 8 © Zühlke 2013
    • 8. Nächster Schritt: (#2) Diversität
    • 9. Und jetzt asymmetrisch: (#3) Aktuator/Monitor
    • 10. Apropos Monitoring: (#4) Programmlaufüberwachung
    • 11. Apropos Monitoring: (#5) Selbsttest
    • 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. 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. Von der Erkennung zur Behandlung: (#6) Units of Mitigation
    • 15. Und wenn es doch nicht lokal geht: (#7) Escalation
    • 16. Ausweitung des Systembegriffs Software Elektronik Mechanik Anwender Architekturmuster in sicherheitsgerichteten Systemen | Daniel Mölle 16. Oktober 2013 Folie 17 © Zühlke 2013
    • 17. Bedienfehler vermeiden: (#8) Minimize Human Intervention
    • 18. Auf zum Widerspruch? (#9) Maximize Human Participation
    • 19. Quelle: Wikimedia Commons
    • 20. Architekturmuster: Fazit
    • 21. Über den Tellerrand… Architekturmuster in sicherheitsgerichteten Systemen | Daniel Mölle 16. Oktober 2013 Folie 22 © Zühlke 2013
    • 22. Fragen? Daniel Mölle

    ×