Noch vor 20 Jahren hätte die Frage, welche Muster in einerbestimmten 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 bisheute meistbeachteten Bücher der Softwaretechnik. Hierbeisteht 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 derSiegeszug des Musterbegriffs basieren auf der gebündeltenPraxis erfahrung, die hinter den darin behandelten Entwurfs-mustern steckt. In diesem Sinne stehen Muster für eine weitereProfessionalisierung der Softwaretechnik: Der systematischeEinsatz 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 ersich 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 Teildisziplinender Softwaretechnik, etwa von Enterprise-Themen wie SOA oderCloud bis hin zu Embedded-Themen wie fehlertolerante Soft-ware oder Echtzeitsysteme. Darüber hinaus erscheinen Jahr fürJahr 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 eineKehrseite: Weil der Musterbegriff mit Konnotationen wie Pro-

fessionalisierung und großer Praxiserfahrung besetzt ist, alsoetwas besonders Gehaltvolles suggeriert, wird er inzwischeninflationär gebraucht – und zum Teil dafür eingesetzt, Inhaltemit nur durchschnittlicher Qualität verkaufen zu können.

Im Allgemeinen bezeichnet man ein abgegrenztes System – et-wa ein elektronisches Gerät inklusive seiner Softwareanteile – alssicherheitsgerichtet, wenn es darauf ausgelegt ist, alle vorherr-schenden Sicherheitsbedürfnisse zu befriedigen. Diese Bedürfnis-se wiederum erwachsen aus den potenziellen Bedrohungen, diemit dem Einsatz des Systems einhergehen, beispielsweise Bedro-hungen durch den Ausfall elektronischer Bauteile oder durch Pro-grammierfehler in der Software. Um die erforderliche Sicherheitzu erreichen, sind für jede derartige Bedrohung Maßnahmen zudefinieren 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 zuabstrakt für eine praktische Anwendung. Allein schon deshalb,weil überhaupt nicht definiert wird, wann genau ein Restrisikoakzeptabel ist und wie diese Eigenschaft nachgewiesen werdensoll. Deshalb existieren für jede betroffene Domäne spezifischeKonkretisierungen – etwa Medizinprodukte, auf die der Artikelnoch ö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 denPatienten vertretbar und mit einem hohen Maß des Schutzes vonGesundheit und Sicherheit vereinbar sein müssen“ˇ[2].

iX Developer !/!"#$ – Embedded Software %%

EINFÜHRUNG | PATTERNS

Architekturmuster in sicherheitsgerichteten Systemen

MustergültigDaniel Mölle

Von Automotive bis Avionik, von Industrieautoma-tisierung bis Medizintechnik: In vielen Branchenhat man es mit sicherheitsgerichteten Syste-men zu tun. Weil diese zunehmend mehrSoftware enthalten und ein Ende diesesTrends nicht abzusehen ist, wird einsystematischer Architekturentwurffür diese Software immer wichti-ger. In diesem Kontext könnenArchitekturmuster helfen.

xx.1414.033-036 03.02.14 10:16 Seite 33

© Copyright by Heise Zeitschriften Verlag

%$ iX Developer !/!"#$ – Embedded Software

EINFÜHRUNG | PATTERNS

Während eine derartige Aussage schon greifbarer ist, liefertsie aber immer noch kein standardisiertes Handwerkzeug fürdas systematische Erkennen und Einstufen von Risiken (Risi-koanalyse) oder gar für die Ableitung geeigneter Sicherheits-maßnahmen (Risikobeherrschung). An dieser Stelle kommendie einschlägigen Normen ins Spiel, die bei der Entwicklungsicherheitsgerichteter Systeme in mindestens dreierlei Weiseextrem hilfreich sind:• Erstens vereinheitlichen die Normen zentrale Begriffe und

Verfahren. Beispielsweise liefert die ISO 14971 klare Anfor-derungen an den Risikomanagementprozess und die damitverbundene 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 Methodenzum Erfüllen bestimmter Aufgaben. Als Beispiel möge hierwieder die ISOˇ14971 dienen, in deren Anhang konkrete Ver-fahren wie die FMEA (failure mode and effects analysis), dieFTA (fault tree analysis) oder die PHA (preliminary hazardanalysis) zur Risikoanalyse benannt werden.

• Drittens sind die Normen, die in einer Domäne gelten, auchimmer mit einer gewissen Arbeitskultur verbunden, die beider Entwicklung sicherheitsgerichteter Systeme zusätzlicheOrientierung bietet. Das ist beispielsweise der Fall, wenn sicheine Norm auf den „Stand der Technik“ bezieht: Was derStand der Technik ist, wird weitgehend nicht in den Normendefiniert, sondern unterliegt einer zeitgenössischen Interpre-tation. Diese lässt sich in der Diskussion mit Experten, imKontext von Medizinprodukten beispielsweise mit den be-nannten Stellen, klären.

Kurzum: Normen sollten nicht als Gängelung oder Einengungmissverstanden werden. Vielmehr sind sie ein zentraler Schrittauf dem Weg von der abstrakten Forderung nach Sicherheit zurAbleitung konkreter Risikomaßnahmen. Sie ermöglichen einesystematische und zielgerichtete Entwicklung sicherheitsgerich-teter Systeme.

Architekturmuster für sicherheitsgerichtete SystemeEin fundamentaler Unterschied zwischen Entwurfs-ˇ[1] undArchitekturmustern besteht darin, dass sich erstere immer aufdas 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 Softwareumfassen.

Ein besonders häufig anzutreffendes Architekturmuster mitdieser Form von Systemsicht ist Redundanzˇ[3][4]. In ihrer ein-fachsten Form lässt sich Redundanz dadurch erreichen, dassmehrere Instanzen derselben Funktionseinheit parallel betriebenwerden, sodass die verbleibenden Instanzen den Ausfall einerInstanz kompensieren können. Typische Anwendungsfälle fürRedundanz sind allerdings Systeme, bei denen Verfügbarkeit –und nicht Sicherheit – im Mittelpunkt steht. Das liegt schlicht-weg daran, dass sich viele Fehlerquellen durch Redundanz nichtlösen lassen: Wenn ein System beispielsweise auf zwei identi-schen Microcontrollern mit identischer Firmware basiert, dannschlagen alle systematischen Fehler immer auf beide Kanäledurch. Klassische Beispiele für derartige Fehler sind Hardware-oder Software-Bugs. Anders gesagt: Die Stärke der Redundanzliegt im Auffangen stochastischer Fehler wie Hardwareausfällenoder 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 wesentlicheMaß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 nureine 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, dasskeine kritische Funktion auf beiden Seiten des Systems vonderselben 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, dasin der Fachliteratur eher unterrepräsentiert ist: Aktuator/Monitor.Die grundsätzliche Idee des Musters besteht darin, auf einemKanal die eigentlichen Funktionen und auf einem zweiten Kanalihre möglichst enge Überwachung umzusetzen. Wenn Aktuatorund Monitor nach den Prinzipen der diversitären Entwicklungimplementiert 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 Fehlerim Aktuator würde durch den Monitor erkannt; ein Fehler imMonitor 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überwachungbesteht 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 gewissenZeitraums 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 Kontextzweikanaliger Systemen eine Rolle spielt, wird eine Programm-laufüberwachung in den meisten Fällen „prozessorlokal“ einge-

Sicherheitsbedürfnis/Risikominimierung

domänenspezi!scheGesetze

z."B. Medizinprodukte-richtlinie/-gesetz

anzuwendendeNormen

z."B. ISO #$%&', #%()#;EN *+$,%, *+$**, *,*,#

konkreteMaßnahmen

projektspezi!scheMaßnahmen

Ableitungspfad für Safety: Durch schrittweises Konkretisierenlassen sich aus einem abstrakten Sicherheitsbedürfnis spezifi-sche Maßnahmen zur Risikobeherrschung ableitenˇ(Abb.ˇ1).

xx.1414.033-036 03.02.14 10:16 Seite 34

© Copyright by Heise Zeitschriften Verlag

setzt: Sie findet auf dem Prozessor statt, auf dem auch die zuüberwachenden Funktionen laufen, was eine in Umfang undZeitverhalten engere Kontrolle gestattet. Alternativ lässt sichdieser Ansatz aber auch über die Prozessorgrenzen hinaus be-treiben. Beispielsweise kann er bei einem zweikanaligen Systemso ausgelegt werden, dass die Programmlaufüberwachung deseinen Kanals auch sicherstellt, dass die Programmlaufüberwa-chung des anderen noch aktiv ist.

Ein für sicherheitsgerichtete Systeme besonders interessantesund 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 einerSoftware betrachtet. Für gewöhnlich unterscheidet man hier zweiSorten von Tests: Auf der einen Seite steht der „Power-On SelfTest“ (POST), also Eigenprüfungen, die beim Einschalten desSystems 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 vonVor- 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 Einschalttestsfundamentalen Einfluss auf die Architektur eines Systems habenkann. Im Allgemeinen gilt nämlich: Sicherheitsfunktionen sinderst durch den Einschalttest zu prüfen, bevor sich das Systemauf sie verlassen darf. In der Konsequenz muss die Architekturdafür sorgen, dass die kritischen Funktionen des Geräts uner-reichbar sind, bis der Einschalttest erfolgreich absolviert wur-de!– beispielsweise durch eine ausdrückliche Unterscheidungentsprechender 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 zumThema Fehlerbehandlung zahlreiche Architekturmuster. Ein pro-minentes Beispiel hierfür sind die „Units of Mitigation“ˇ[3]. Inihrem Fokus steht der Umstand, dass Fehler innerhalb einerKomponente nicht zwangsweise dazu führen sollten, dass dasGesamtsystem in den sicheren Zustand herunterzufahren ist. Esgibt nämlich viele Fehler, die sich nicht nur komponentenlokalerkennen, 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 unkritischenKomfortfunktionen, von denen sich das System durch geeigneteMaßnahmen zur Laufzeit erholen kann. So existieren etwa Me-dizinprodukte, die zwar Betriebsdaten an ein PDMS (patient datamanagement system) melden, bei denen aber ein Fehler in derKommunikation mit dem PDMS überhaupt keine Beeinträchti-gung ihrer eigentlichen Hauptfunktion bedeutet. Derartige Fehlersollten also innerhalb der Kommunikationskomponenten abge-fangen werden und nicht auf das Gesamtsystem durchschlagen.Allgemeiner gesprochen besteht die Aufgabe darin, schon beimEntwurf einer Architektur – genauer gesagt beim Schneiden einerkomponentenbasierten Architekturˇ[4] – geeignete Units of Mi-tigation herauszuarbeiten.

Etwas anders sieht es beim Architekturmuster „Escalation“ˇ[3]aus. Hierbei wird dem System die Möglichkeit eingeräumt, dieVerantwortung zur Behandlung eines lokal erkannten Fehlers,der sich leider nicht lokal auflösen ließ, einer übergeordnetenEbene zuzuweisen. Es handelt sich hierbei also nicht etwa umein Entwurfsmuster, das lediglich das Design der betroffenenSoftwarekomponente betrifft, sondern um eine Architekturfragemit 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 nichtnur das Komplettsystem aus Mechanik, Elektronik und Softwarein den Mittelpunkt rücken, sondern tatsächlich auch den Benut-zer mit einbeziehen. Zum Abschluss sei diese Tatsache an zweiArchitekturmustern aus der Welt der fehlertoleranten Syste-meˇ[3] verdeutlicht.

Das Muster „Minimize Human Intervention“ resultiert aus derErkenntnis, dass es neben Hardware- und Softwarefehlern vor al-lem die Bedienfehler sind, die beim Einsatz sicherheitsgerichteterSysteme zu Gefährdungen führen (ein Umstand, der sich auch inder 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 dieseAufgaben 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 gezwungenwird, unter dem durch die damit einhergehende Alarmierung ver-ursachten Stress eine sicherheitskritische Prozedur zur Fehlerbe-hebung durchzuführen, so besteht hier offenbar ein erheblichesRisiko für Konzentrationsfehler und Fehlentscheidungen.

Das zweite Beispiel trägt den Namen „Maximize Human Par-ticipation“. Auf den ersten Blick mag es kurios erscheinen, dasszwei Paradigmen existieren, die ihrer Benennung nach das exak-te Gegenteil des anderen fordern. Dieser scheinbare Konfliktlöst sich aber auf, sobald man erfährt, dass es in diesem zweitenArchitekturmuster ausdrücklich um Menschen geht, die als Ex-

iX Developer !/!"#$ – Embedded Software %&

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 zwischenRedundanz und Diversität. Aktuator/Monitor wird außerdemerläutert, um zu verdeutlichen, dass Diversität nicht aufgleichberechtigte Rollen beschränkt istˇ(Abb.ˇ2).

xx.1414.033-036 03.02.14 10:16 Seite 35

© Copyright by Heise Zeitschriften Verlag

Alle Links: www.ix.de/ix!"!"#$$ x

EINFÜHRUNG | PATTERNS

iX Developer !/!"#$ – Embedded Software%'

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 desApollo-Programms der NASA in der Frage, wie viel Kontrolledie Astronauten über das Raumfahrzeug haben solltenˇ[6]. Diemeisten Ingenieure, allen voran Wernher von Braun, hielten einepraktisch vollständige Kontrolle durch die Bordcomputer fürden einzig gangbaren Weg. Die meisten Astronauten hingegen,unter anderem der erfahrene Testpilot Neil Armstrong, bestan-den darauf, vor allem in kritischen Situationen jederzeit in diediversen Flugmanöver eingreifen zu können. Am Ende bewährtesich eine gesunde Mixtur aus beiden Ansätzen: Die Bordcom-puter stellten sich als unverzichtbar heraus, was die komplexeNavigation und die Beherrschung der oft völlig unintuitivenFlugmechanik betraf. Die Astronauten hingegen konnten durchbeherztes 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, dasssich 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 Architekturentwurffortwä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 auchArchitekturmuster, die in sicherheitskritischen Anwendungennichts verloren haben.

Ferner bleibt festzuhalten, dass die Popularität einzelner Ar-chitekturmuster von Domäne zu Domäne schwankt. Vergleichtman etwa die beiden Domänen Medizintechnik und Avionik, zeigtsich schon bei der Frage, ob sich für das jeweils gegebene System

überhaupt ein sicherer Zustand definieren lässt, ein fundamentalerUnterschied: Es ist vergleichsweise einfach, ein Röntgengerät ineinen 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 denTellerrand immer ein lohnenswertes Unterfangen. Wenn doku-mentiert ist, warum sich ein Architekturmuster in einer fremdenDomäne etabliert hat, lässt sich leicht ableiten, ob dieses Musterauch für das eigene Fachgebiet interessant wäre.

Die Frage der Eignung ist aber selbst innerhalb einer Domänenicht zu unterschätzen. Inwiefern ein Architekturmuster nämlichseine Vorzüge ausspielen kann – und welche Nachteile es mitsich 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 jeweilsvorliegenden 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.

Betrachtungen zur ÜberwachungWie bei vielen spannenden architektonischen Fragestellungen verbirgtsich auch hinter dem Einsatz von Überwachungsmaßnahmen immerein 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“).

•ˇEnge Überwachung setzt Kenntnisse über Interna der zu überwa-chenden Komponente voraus (im Widerspruch zu „encapsulation“).

•ˇZentral organisierte Programmlaufüberwachungen oder Selbsttestsführen dazu, dass Wissen über verschiedene Funktionen des Systemsan einer Stelle konzentriert wird (im Widerspruch zu „separation ofconcerns“ beziehungsweise „high cohesion“).

In ähnlicher Weise erhöhen zusätz-liche Überwachungen vielleicht dieSicherheit, verringern potenziellaber auch die Verfügbarkeit desSystems – etwa durch überemp-findliche Überwachungen, die häu-fig falschen Alarm melden. Werzusätzliche Überwachungen ein-bauen möchte, ohne die Verfügbar-keit zu senken, muss mit erhöhtenKosten rechnen. Diese Gesetzmä-ßigkeit ist letztlich analog zum be-rühmten „iron triangle“ der Projekt-leitung.

SelbsttestAktuator #

Aktuator +

Aktuator $

Monitor #

Monitor +

Monitor $Programmlauf-überwachung

überwacht

Die Kosten von Überwachungsmaßnahmen: Starke Kopplung,Bruch der Kapselung und Zentralisierungˇ(Abb.ˇ3).

niedrige Kosten

starke Überwachung

hoheVerfügbarkeit

Trade-off-Dreieck zwischenKosteneffizienz, Sicherheit(qua Überwachung) und Verfügbarkeitˇ(Abb.ˇ4).

xx.1414.033-036 03.02.14 10:16 Seite 36

© Copyright by Heise Zeitschriften Verlag