EINFÜHRUNG | PATTERNS 
Architekturmuster in sicherheitsgerichteten Systemen 
Mustergültig 
Daniel Mölle 
Von Automotive bi...
EINFÜHRUNG | PATTERNS 
Während eine derartige Aussage schon greifbarer ist, liefert 
sie aber immer noch kein standardisie...
setzt: Sie findet auf dem Prozessor statt, auf dem auch die zu 
überwachenden Funktionen laufen, was eine in Umfang und 
Z...
Betrachtungen zur Überwachung 
•ˇEnge Überwachung setzt Kenntnisse über Interna der zu überwa-chenden 
Komponente voraus (...
Nächste SlideShare
Wird geladen in …5
×

Architekturmuster in sicherheitsgerichteten Systemen (iX Magazin 2/2014)

631 Aufrufe

Veröffentlicht am

Von Automotive bis Avionik, von Industrieautomatisierung bis Medizintechnik: In vielen Branchen hat man es mit sicherheitsgerichteten Systemen zu tun. Weil diese zunehmend mehr Software enthalten und ein Ende dieses Trends nicht abzusehen ist, wird ein systematischer Architekturentwurf für diese Software immer wichtiger.
In diesem Kontext können Architekturmuster helfen.
Autor: Daniel Mölle

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
631
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
5
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Architekturmuster in sicherheitsgerichteten Systemen (iX Magazin 2/2014)

  1. 1. EINFÜHRUNG | PATTERNS Architekturmuster in sicherheitsgerichteten Systemen Mustergültig Daniel Mölle Von Automotive bis Avionik, von Industrieautoma-tisierung bis Medizintechnik: In vielen Branchen hat man es mit sicherheitsgerichteten Syste-men zu tun. Weil diese zunehmend mehr Software enthalten und ein Ende dieses Trends nicht abzusehen ist, wird ein systematischer Architekturentwurf für diese Software immer wichti-ger. In diesem Kontext können Architekturmuster helfen. Noch vor 20 Jahren hätte die Frage, welche Muster in einer bestimmten Software eingesetzt werden sollten, zu hilf-losen Blicken geführt: Der Begriff war schlichtweg nicht geläufig. 1994 erschien allerdings mit „Design Patterns – Ele-ments of Reusable Object-Oriented Software“ˇ[1] eines der bis heute meistbeachteten Bücher der Softwaretechnik. Hierbei steht Pattern – allgemein gesprochen – für ein bewährtes Stan-dardrezept zur Lösung bestimmter Aufgaben, die sich im Rah-men der Softwareentwicklung immer wieder stellen. Der Erfolg des oben genannten Buches und somit auch der Siegeszug des Musterbegriffs basieren auf der gebündelten Praxis erfahrung, die hinter den darin behandelten Entwurfs-mustern steckt. In diesem Sinne stehen Muster für eine weitere Professionalisierung der Softwaretechnik: Der systematische Einsatz fundierter Standardrezepte in den passenden Standard-situationen stellt das Gegenteil von intuitiv-individuellem „cowboy coding“ dar. Die positive Belegung des Musterbegriffs führte dazu, dass er sich im Laufe der Zeit weiter verbreitete. So existieren mittler-weile dutzende Fachbücher zu den Themen Design und Architek-tur, in deren Titel das Wort „patterns“ bemüht wird – zu Recht, solange es auch hier um bewährte Rezepte geht. Ihre Schwer-punkte erstrecken sich über die verschiedensten Teildisziplinen der Softwaretechnik, etwa von Enterprise-Themen wie SOA oder Cloud bis hin zu Embedded-Themen wie fehlertolerante Soft-ware oder Echtzeitsysteme. Darüber hinaus erscheinen Jahr für Jahr Artikel und Konferenzbeiträge, die sich mit Patterns ausei-nandersetzen – oder mit Anti-Patterns, also mit häufig zu beob-achtenden Vorgehensweisen, die zum Scheitern verurteilt sind. Nebenbei bemerkt hat der oben ausgeführte Erfolg auch eine Kehrseite: Weil der Musterbegriff mit Konnotationen wie Pro-fessionalisierung und großer Praxiserfahrung besetzt ist, also etwas besonders Gehaltvolles suggeriert, wird er inzwischen inflationär gebraucht – und zum Teil dafür eingesetzt, Inhalte mit nur durchschnittlicher Qualität verkaufen zu können. Im Allgemeinen bezeichnet man ein abgegrenztes System – et-wa ein elektronisches Gerät inklusive seiner Softwareanteile – als sicherheitsgerichtet, wenn es darauf ausgelegt ist, alle vorherr-schenden Sicherheitsbedürfnisse zu befriedigen. Diese Bedürfnis-se wiederum erwachsen aus den potenziellen Bedrohungen, die mit dem Einsatz des Systems einhergehen, beispielsweise Bedro-hungen durch den Ausfall elektronischer Bauteile oder durch Pro-grammierfehler in der Software. Um die erforderliche Sicherheit zu erreichen, sind für jede derartige Bedrohung Maßnahmen zu definieren und umzusetzen, die das aus der Bedrohung resultie-rende Risiko auf ein akzeptables Restrisiko absenken. Normen und Anforderungen Diese Forderung nach Risikominimierung ist zwar leicht nach-zuvollziehen, in ihrer allgemeinen Form allerdings auch viel zu abstrakt für eine praktische Anwendung. Allein schon deshalb, weil überhaupt nicht definiert wird, wann genau ein Restrisiko akzeptabel ist und wie diese Eigenschaft nachgewiesen werden soll. Deshalb existieren für jede betroffene Domäne spezifische Konkretisierungen – etwa Medizinprodukte, auf die der Artikel noch öfter zurückgreift. So findet sich eine erste solche Konkre-tisierung in der Medizinprodukterichtlinie: Sie besagt, dass „etwaige Risiken verglichen mit der nützlichen Wirkung für den Patienten vertretbar und mit einem hohen Maß des Schutzes von Gesundheit und Sicherheit vereinbar sein müssen“ˇ[2]. iX Developer !/!"#$ – Embedded Software %% © Copyright by Heise Zeitschriften Verlag
  2. 2. EINFÜHRUNG | PATTERNS Während eine derartige Aussage schon greifbarer ist, liefert sie aber immer noch kein standardisiertes Handwerkzeug für das systematische Erkennen und Einstufen von Risiken (Risi-koanalyse) oder gar für die Ableitung geeigneter Sicherheits-maßnahmen (Risikobeherrschung). An dieser Stelle kommen die einschlägigen Normen ins Spiel, die bei der Entwicklung sicherheitsgerichteter Systeme in mindestens dreierlei Weise extrem hilfreich sind: • Erstens vereinheitlichen die Normen zentrale Begriffe und Verfahren. Beispielsweise liefert die ISO 14971 klare Anfor-derungen an den Risikomanagementprozess und die damit verbundene Dokumentation, während die IECˇ62304 normier-te Sicherheitsklassen definiert und unmissverständliche For-derungen an den Softwareentwicklungsprozess stellt. • Zweitens enthalten die Normen Hinweise, also Aussagen in-formativen Charakters, etwa bezüglich möglicher Methoden zum Erfüllen bestimmter Aufgaben. Als Beispiel möge hier wieder die ISOˇ14971 dienen, in deren Anhang konkrete Ver-fahren wie die FMEA (failure mode and effects analysis), die FTA (fault tree analysis) oder die PHA (preliminary hazard analysis) zur Risikoanalyse benannt werden. • Drittens sind die Normen, die in einer Domäne gelten, auch immer mit einer gewissen Arbeitskultur verbunden, die bei der Entwicklung sicherheitsgerichteter Systeme zusätzliche Orientierung bietet. Das ist beispielsweise der Fall, wenn sich eine Norm auf den „Stand der Technik“ bezieht: Was der Stand der Technik ist, wird weitgehend nicht in den Normen definiert, sondern unterliegt einer zeitgenössischen Interpre-tation. Diese lässt sich in der Diskussion mit Experten, im Kontext von Medizinprodukten beispielsweise mit den be-nannten Stellen, klären. Kurzum: Normen sollten nicht als Gängelung oder Einengung missverstanden werden. Vielmehr sind sie ein zentraler Schritt auf dem Weg von der abstrakten Forderung nach Sicherheit zur Ableitung konkreter Risikomaßnahmen. Sie ermöglichen eine systematische und zielgerichtete Entwicklung sicherheitsgerich-teter Systeme. Architekturmuster für sicherheitsgerichtete Systeme Ein fundamentaler Unterschied zwischen Entwurfs-ˇ[1] und Architekturmustern besteht darin, dass sich erstere immer auf das softwaretechnische Design für einen vergleichsweise be-grenzten Aspekt einer Software konzentrieren, während letz-tere immer das gesamte System betreffen. Dabei kann der Sys-tembegriff nicht nur die vollständige Software, sondern auch das Gesamtsystem aus Mechanik, Elektronik und Software umfassen. Ein besonders häufig anzutreffendes Architekturmuster mit dieser Form von Systemsicht ist Redundanzˇ[3][4]. In ihrer ein-fachsten Form lässt sich Redundanz dadurch erreichen, dass mehrere Instanzen derselben Funktionseinheit parallel betrieben werden, sodass die verbleibenden Instanzen den Ausfall einer Instanz kompensieren können. Typische Anwendungsfälle für Redundanz sind allerdings Systeme, bei denen Verfügbarkeit – und nicht Sicherheit – im Mittelpunkt steht. Das liegt schlicht-weg daran, dass sich viele Fehlerquellen durch Redundanz nicht lösen lassen: Wenn ein System beispielsweise auf zwei identi-schen Microcontrollern mit identischer Firmware basiert, dann schlagen alle systematischen Fehler immer auf beide Kanäle durch. Klassische Beispiele für derartige Fehler sind Hardware-oder Software-Bugs. Anders gesagt: Die Stärke der Redundanz liegt im Auffangen stochastischer Fehler wie Hardwareausfällen oder Speicherfehlern („Bitkipper“). Die Schwäche der redundanten Auslegung kann man aller-dings leicht auflösen, indem man den Schritt von der Redun-danz zur Diversität vollzieht. Eine solche Diversität lässt sich, um das obige Beispiel aufzugreifen, durch drei wesentliche Maßnahmen erreichen: Erstens müssen zwei verschiedene Mi-crocontroller – idealerweise von zwei verschiedenen Herstel-lern – zum Einsatz kommen, um eine möglichst hohe Wahr-scheinlichkeit dafür zu erreichen, dass ein Hardware-Bug nur eine der beiden Seiten betrifft. Zweitens sind aus gleichen Er-wägungen, was mögliche Compiler-Fehler betrifft, zwei ver-schiedene Toolchains zu verwenden. Drittens müssen systema-tische Fehler in der Software dadurch entschärft werden, dass keine kritische Funktion auf beiden Seiten des Systems von derselben Person implementiert wird. Überwachende Patterns Im Dunstkreis von Redundanz und Diversität – also im Zusam-menhang mit Systemen, die gewissermaßen über mehrere Ka-näle verfügen – ist auch ein Architekturmuster zu erwähnen, das in der Fachliteratur eher unterrepräsentiert ist: Aktuator/Monitor. Die grundsätzliche Idee des Musters besteht darin, auf einem Kanal die eigentlichen Funktionen und auf einem zweiten Kanal ihre möglichst enge Überwachung umzusetzen. Wenn Aktuator und Monitor nach den Prinzipen der diversitären Entwicklung implementiert werden, sind sie besonders für sicherheitsgerich-tete Systeme interessant, die – was beispielsweise für viele Me-dizinprodukte gilt – erstfehlersicherˇ[5] sein müssen: Ein Fehler im Aktuator würde durch den Monitor erkannt; ein Fehler im Monitor würde den Aktuator nicht betreffen. Ein weiteres Architekturmuster mit dem Schwerpunkt Moni-toring ist die Programmlaufüberwachung, eine konkrete Ausprä-gung des etwas abstrakteren Ansatzes „System Monitor“ˇ[3]. Die grundsätzliche Idee hinter einer Programmlaufüberwachung besteht darin, kontinuierlich zu kontrollieren, ob sicherheitskri-tische Funktionen der Software wie vorgesehen ausgeführt wer-den. Dieses Monitoring eignet sich besonders für Echtzeitsys-teme, in denen bestimmte Funktionen innerhalb eines gewissen Zeitraums zur Ausführung kommen müssen – sei es periodisch (zum Beispiel alle 50ˇMillisekunden) oder als Reaktion auf be-stimmte Ereignisse (zum Beispiel innerhalb von 100ˇMillisekun-den nach einem Tastendruck). Im Gegensatz zu Aktuator/Monitor, das eher im Kontext zweikanaliger Systemen eine Rolle spielt, wird eine Programm-laufüberwachung in den meisten Fällen „prozessorlokal“ einge- Sicherheitsbedürfnis/ Risikominimierung domänenspezi!sche Gesetze z."B. Medizinprodukte-richtlinie/- gesetz anzuwendende Normen z."B. ISO #$%&', #%()#; EN *+$,%, *+$**, *,*,# konkrete Maßnahmen projektspezi!sche Maßnahmen Ableitungspfad für Safety: Durch schrittweises Konkretisieren lassen sich aus einem abstrakten Sicherheitsbedürfnis spezifi-sche Maßnahmen zur Risikobeherrschung ableitenˇ(Abb.ˇ1). %$ iX Developer !/!"#$ – Embedded Software © Copyright by Heise Zeitschriften Verlag
  3. 3. setzt: Sie findet auf dem Prozessor statt, auf dem auch die zu überwachenden Funktionen laufen, was eine in Umfang und Zeitverhalten engere Kontrolle gestattet. Alternativ lässt sich dieser Ansatz aber auch über die Prozessorgrenzen hinaus be-treiben. Beispielsweise kann er bei einem zweikanaligen System so ausgelegt werden, dass die Programmlaufüberwachung des einen Kanals auch sicherstellt, dass die Programmlaufüberwa-chung des anderen noch aktiv ist. Ein für sicherheitsgerichtete Systeme besonders interessantes und deshalb auch häufig anzutreffendes Konzept sind in die Soft-ware eingebaute (Selbst-)Tests. Gemeint sind hiermit Eigenprü-fungen des Systems, die zu wohldefinierten Punkten während der Laufzeit durchgeführt werden – im Gegensatz zu einer Pro-grammlaufüberwachung, die ja kontinuierlich den Ablauf einer Software betrachtet. Für gewöhnlich unterscheidet man hier zwei Sorten von Tests: Auf der einen Seite steht der „Power-On Self Test“ (POST), also Eigenprüfungen, die beim Einschalten des Systems auszuführen sind. Es ist üblich, dass diese auch peri-odisch zu wiederholen sind, wenn das System länger eingeschal-tet ist. Auf der anderen Seite stehen in den normalen Programm-lauf integrierte Prüfungen („Built-in Tests“), beispielsweise von Vor- und Nachbedingungen einzelner Funktionen bei jedem Be-treten und Verlassen derselben. Patterns zur Fehlerbehandlung Bei der genaueren Betrachtung der Einschalttests wird offenbart, dass die Literatur sie nicht unbedingt als Architekturmuster auf-führt. Zu beachten ist aber, dass die Existenz von Einschalttests fundamentalen Einfluss auf die Architektur eines Systems haben kann. Im Allgemeinen gilt nämlich: Sicherheitsfunktionen sind erst durch den Einschalttest zu prüfen, bevor sich das System auf sie verlassen darf. In der Konsequenz muss die Architektur dafür sorgen, dass die kritischen Funktionen des Geräts uner-reichbar sind, bis der Einschalttest erfolgreich absolviert wur-de !– beispielsweise durch eine ausdrückliche Unterscheidung entsprechender Systemzustände. Ansätze wie Aktuator/Monitor oder Programmlaufüberwa-chung legen den Schwerpunkt auf das Erkennen von Fehlern. Das wirft die Folgefrage auf, was beim Erkennen eines Fehlers überhaupt passieren soll. Erfreulicherweise gibt es auch zum Thema Fehlerbehandlung zahlreiche Architekturmuster. Ein pro-minentes Beispiel hierfür sind die „Units of Mitigation“ˇ[3]. In ihrem Fokus steht der Umstand, dass Fehler innerhalb einer Komponente nicht zwangsweise dazu führen sollten, dass das Gesamtsystem in den sicheren Zustand herunterzufahren ist. Es gibt nämlich viele Fehler, die sich nicht nur komponentenlokal erkennen, sondern auch komponentenlokal auflösen lassen. Ein typisches Beispiel hierfür ist die Unterscheidung zwi-schen kritischen Gerätefehlern, die den sicheren Betrieb des Ge-samtsystems gefährden, und transienten Fehlern in unkritischen Komfortfunktionen, von denen sich das System durch geeignete Maßnahmen zur Laufzeit erholen kann. So existieren etwa Me-dizinprodukte, die zwar Betriebsdaten an ein PDMS (patient data management system) melden, bei denen aber ein Fehler in der Kommunikation mit dem PDMS überhaupt keine Beeinträchti-gung ihrer eigentlichen Hauptfunktion bedeutet. Derartige Fehler sollten also innerhalb der Kommunikationskomponenten abge-fangen werden und nicht auf das Gesamtsystem durchschlagen. Allgemeiner gesprochen besteht die Aufgabe darin, schon beim Entwurf einer Architektur – genauer gesagt beim Schneiden einer komponentenbasierten Architekturˇ[4] – geeignete Units of Mi-tigation herauszuarbeiten. Funktionseinheit # Variante # Instanz # Funktionseinheit # Variante # Instanz + Redundanz: Mehrere identische Kopien erhöhen die Verfügbarkeit; stochastische Fehler werden entschär-. Für systematische Fehler allerdings verbleibt aufgrund der Identität ein „single point of failure“. Funktionseinheit # Variante # Instanz # Funktionseinheit # Variante + Instanz # Diversität: Der „single point of failure“ wird aufgelöst, indem verschiedene Lösungswege zum Einsatz kommen. Dieses Vorgehen kann sich auf viele unterschiedliche Arten manifestieren. Funktionseinheit # Variante # Instanz # Überwachungseinheit # Variante # Instanz # Aktuator/Monitor: Statt identischer Funktion realisieren die beiden Kanäle in diesem Beispiel ein Paar aus Funktionen und Überwachung. Ein diversitäres Vorgehen emp!ehlt sich hier aus den o."g. Gründen besonders. Visualisierung des entscheidenden Unterschieds zwischen Redundanz und Diversität. Aktuator/Monitor wird außerdem erläutert, um zu verdeutlichen, dass Diversität nicht auf gleichberechtigte Rollen beschränkt istˇ(Abb.ˇ2). Etwas anders sieht es beim Architekturmuster „Escalation“ˇ[3] aus. Hierbei wird dem System die Möglichkeit eingeräumt, die Verantwortung zur Behandlung eines lokal erkannten Fehlers, der sich leider nicht lokal auflösen ließ, einer übergeordneten Ebene zuzuweisen. Es handelt sich hierbei also nicht etwa um ein Entwurfsmuster, das lediglich das Design der betroffenen Softwarekomponente betrifft, sondern um eine Architekturfrage mit umfassender Systemsicht: Die Architektur muss komponen-tenübergreifende Eskalationspfade definieren. Benutzer involvierende Muster Die oben zitierte Systemsicht bei der Betrachtung von Architek-turmustern geht sogar so weit, dass einige dieser Muster nicht nur das Komplettsystem aus Mechanik, Elektronik und Software in den Mittelpunkt rücken, sondern tatsächlich auch den Benut-zer mit einbeziehen. Zum Abschluss sei diese Tatsache an zwei Architekturmustern aus der Welt der fehlertoleranten Syste-me ˇ[3] verdeutlicht. Das Muster „Minimize Human Intervention“ resultiert aus der Erkenntnis, dass es neben Hardware- und Softwarefehlern vor al-lem die Bedienfehler sind, die beim Einsatz sicherheitsgerichteter Systeme zu Gefährdungen führen (ein Umstand, der sich auch in der zunehmenden Betrachtung von Fragen der Gebrauchstaug-lichkeit widerspiegelt). Der Lösungsansatz besteht darin, die Anwender in größtmöglichem Umfang von fehlerträchtigen Auf-gaben zu befreien – vor allem dann, wenn die Software diese Aufgaben viel besser selbst übernehmen kann. Ein für dieses Paradigma besonders relevantes Gebiet ist das der Fehlerbehand-lung: Wenn der Benutzer in einer Fehlersituation dazu gezwungen wird, unter dem durch die damit einhergehende Alarmierung ver-ursachten Stress eine sicherheitskritische Prozedur zur Fehlerbe-hebung durchzuführen, so besteht hier offenbar ein erhebliches Risiko für Konzentrationsfehler und Fehlentscheidungen. Das zweite Beispiel trägt den Namen „Maximize Human Par-ticipation“. Auf den ersten Blick mag es kurios erscheinen, dass zwei Paradigmen existieren, die ihrer Benennung nach das exak-te Gegenteil des anderen fordern. Dieser scheinbare Konflikt löst sich aber auf, sobald man erfährt, dass es in diesem zweiten Architekturmuster ausdrücklich um Menschen geht, die als Ex-iX Developer !/!"#$ – Embedded Software %& © Copyright by Heise Zeitschriften Verlag
  4. 4. Betrachtungen zur Überwachung •ˇEnge Überwachung setzt Kenntnisse über Interna der zu überwa-chenden Komponente voraus (im Widerspruch zu „encapsulation“). •ˇZentral organisierte Programmlaufüberwachungen oder Selbsttests führen dazu, dass Wissen über verschiedene Funktionen des Systems an einer Stelle konzentriert wird (im Widerspruch zu „separation of concerns“ beziehungsweise „high cohesion“). In ähnlicher Weise erhöhen zusätz-liche Überwachungen vielleicht die Sicherheit, verringern potenziell aber auch die Verfügbarkeit des Systems – etwa durch überemp-findliche Überwachungen, die häu-fig falschen Alarm melden. Wer zusätzliche Überwachungen ein-bauen möchte, ohne die Verfügbar-keit zu senken, muss mit erhöhten Kosten rechnen. Diese Gesetzmä-ßigkeit ist letztlich analog zum be-rühmten „iron triangle“ der Projekt-leitung. niedrige Kosten starke Überwachung hohe Verfügbarkeit Trade-off-Dreieck zwischen Kosteneffizienz, Sicherheit (qua Überwachung) und Verfügbarkeitˇ(Abb.ˇ4). überhaupt ein sicherer Zustand definieren lässt, ein fundamentaler Unterschied: Es ist vergleichsweise einfach, ein Röntgengerät in einen Nothalt zu versetzen, was sich für ein in der Luft befindli-ches Großraumflugzeug hingegen als schwierig erweist. Nichtsdestoweniger ist der sprichwörtliche Blick über den Tellerrand immer ein lohnenswertes Unterfangen. Wenn doku-mentiert ist, warum sich ein Architekturmuster in einer fremden Domäne etabliert hat, lässt sich leicht ableiten, ob dieses Muster auch für das eigene Fachgebiet interessant wäre. Die Frage der Eignung ist aber selbst innerhalb einer Domäne nicht zu unterschätzen. Inwiefern ein Architekturmuster nämlich seine Vorzüge ausspielen kann – und welche Nachteile es mit sich bringt –, hängt immer auch von den ganz konkreten Rah-menbedingungen ab. Folglich ist vor der Anwendung eines sol-chen Musters stets kritisch zu prüfen, ob sein Einsatz im jeweils vorliegenden Einzelfall zu empfehlen ist. (ane) Literatur [1]ˇErich Gamma et al.; Design Patterns – Elements of Reusable Object-Oriented Software; Addison-Wesley 1994 [2]ˇChristian Johner et al.; Basiswissen Medizinische Software; dpunkt.verlag 2011 [3]ˇRobert S. Hanmer; Patterns for Fault Tolerant Software; Wiley 2007 [4]ˇBruce Powel Douglass; Real-Time Design Patterns; Addison-Wesley 2009 [5]ˇChristian Johner; Erstfehlersicherheit bei Software (www.johner-institut.de/wissen/2011/iec-62304- medizinische-software/erstfehlersicherheit-bei-software) [6]ˇDavid A. Mindell; Digital Apollo; The MIT Press 2011 Dr. Daniel Mölle arbeitet als Softwarearchitekt bei der Zühlke Engineering GmbH. Alle Links: www.ix.de/ix!"!"#$$ x EINFÜHRUNG | PATTERNS Wie bei vielen spannenden architektonischen Fragestellungen verbirgt sich auch hinter dem Einsatz von Überwachungsmaßnahmen immer ein Trade-off. Tatsächlich läuft Überwachung nämlich einigen gemein-hin erstrebenswerten Eigenschaften einer Software entgegen: •ˇDie Überwachung von Komponenten durch andere Komponenten ver-stärkt die Kopplung im System (im Widerspruch zu „loose coupling“). Selbsttest Aktuator # Aktuator + Aktuator $ Monitor # Monitor + Monitor $ Programmlauf-überwachung überwacht Die Kosten von Überwachungsmaßnahmen: Starke Kopplung, Bruch der Kapselung und Zentralisierungˇ(Abb.ˇ3). perten einzustufen sind. In diesem Fall nämlich ist davon aus-zugehen, dass der Nutzen eines Eingriffs durch Experten die da-mit verbundenen Risiken überwiegt. Die Technikgeschichte kennt zahlreiche Anekdoten für Ab-wägungen zwischen den beiden oben genannten Paradigmen. So bestand einer der wesentlichen Streitpunkte innerhalb des Apollo-Programms der NASA in der Frage, wie viel Kontrolle die Astronauten über das Raumfahrzeug haben solltenˇ[6]. 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, bestan-den 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 Bordcom-puter 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, bei-spielsweise beim Ausfall der Bordcomputer durch Überlast („Alarm 1202“) im Rahmen der Mondlandung von Apolloˇ11. Fazit Dem Siegeszug des Pattern-Begriffs ist es zu verdanken, dass sich heute unter anderem auch auf ein großes Repertoire an Ar-chitekturmustern zurückgreifen lässt – also auf bewährte Stan-dardrezepte für Aufgaben, die sich beim Architekturentwurf fortwährend stellen. Die Fachliteratur zu diesem Themenkom-plex umspannt inzwischen viele verschiedene Schwerpunkte, von denen einige besonders im Zusammenhang mit sicherheits-gerichteten Systemen interessant sind. Es gibt allerdings auch Architekturmuster, die in sicherheitskritischen Anwendungen nichts verloren haben. Ferner bleibt festzuhalten, dass die Popularität einzelner Ar-chitekturmuster von Domäne zu Domäne schwankt. Vergleicht man etwa die beiden Domänen Medizintechnik und Avionik, zeigt sich schon bei der Frage, ob sich für das jeweils gegebene System %' iX Developer !/!"#$ – Embedded Software © Copyright by Heise Zeitschriften Verlag

×