Home

Formale Fehlermodellierung fuer verteilte reaktive

1. C Abbildung 5 5 Kombination von Modifikations und Treiberkomponente Beispiel 5 5 Ein klassisches Beispiel f r den sinnvollen Einsatz von Treibern stellen verlust behaftete Kommunikationskan le dar Ein idealisierter bertragungskanal Channel sei absolut fehler und verlustfrei Er sei parametrisierbar reagiere also auf gewisse Steuersignale mit un terschiedlichen Qualit tsmerkmalen wie Datenrate oder Verz gerungszeiten Eine realistische Implementierung des Kanals kann jedoch dem Verlust von Nachrichten ausge setzt sein Dies k nnen wir modellieren durch Hinzuf gen einer virtuellen Komponente Loss die den sporadischen Verlust von Nachrichten spezifiziert Es gen gt diese Komponente auf einer Seite des Kanals zu erg nzen da es beobachtungs quivalent ist ob eine Nachricht sofort verloren wird oder erst Channel passiert und dann verloren geht _ os me o Sender Loss Channel Receiver gt lt 9 lt gt ee Abbildung 5 6 Fehlerhafter bertragungskanal mit Treibern Zum Ausgleich dieses Fehlers erg nzen wir entsprechend Abbildung B 6 das System um die zwei Treiberkomponenten Sender und Receiver die mit Hilfe eines Protokolls sicherstellen dass trotz auftretender Nachrichtenverluste alle Nachrichten durch entsprechende Wiederholungen bertragen werden Es gibt eine Vielzahl von Protokollen beschrieben beispiel
2. m gt Modul 1 L Modul 2 Voter gt e Modul 3 Abbildung 2 6 Triple Modular Redundancy gleiche Replikation von Komponenten ist als Ma nahme gegen ber Hardwarefehlern sinnvoll aber nicht gegen ber Softwarefehlern die immer Designfehler sind Hardwarefehler sind in den meisten F llen physikalische Fehler die tempor r und eher sporadisch auftreten Das Auftreten dieser Fehler in verschiedenen aber bauglei chen Komponenten kann statistisch unabh ngig sein wenn sie nur von physikalischen Zuf lligkeiten abh ngen und nicht etwa beispielsweise durch die gleichen Umgebungs einfl sse beeintr chtigt werden Die Auftreten von Fehlern in der Hardware wird durch Alterungs und Verschleisserscheinungen beeinflu t Spielen diese Effekte eine Rolle ist es sinnvoll eine identische Ersatzkomponente bereitzustellen die bei Ausfall der ei gentlichen Komponente deren Aufgabe bernimmt Auch permanenten Fehlern in der Hardware kann durch Replikation begegnet werden wenn diese ihren Ursprung in De fiziten im Herstellungsproze haben Einen Fehler den eine Komponente hat wird mit einer meist hohen oft bekannten Wahrscheinlichkeit eine andere Komponente nicht haben Bekannte Techniken zur Hardwarefehler Toleranz mit Replikation sind Triple Modular Redundancy und Standby Spares die wir im folgenden kurz skizzieren Triple Modular Redundancy Gegeben sei eine Komponente mit einer beliebigen Ein Ausgabefunkt
3. Sind die Systeme durch Black Box Spezifikationen und spezifiziert so liegt eine Verhaltensverfeinerung vor wenn 9 gt 6 68 KAPITEL 3 FORMALES SYSTEMMODELL Lo 5 ze 9 R Ra b i rd So j YF o Abbildung 3 9 Schnittstellenverfeinerung Ein typischer Schritt in der Entwicklung eines Systems ist die Reduktion von Nichtde terminismus und Unterspezifikation Dies kann durch eine Verhaltensverfeinerung for malisiert werden Ist das verfeinerte System aus Unterkomponenten zusammengesetzt nennt man diesen Schritt auch strukturelle Verfeinerung 3 9 2 Schnittstellenverfeinerung Die Schnittstellenverfeinerung erlaubt es die Ver nderung der Schnittstelle eines Sys tems als Verfeinerungsschritt zu formalisieren So k nnen Anzahl und Typ der Nach richtenkan le und die Repr sentation von Nachrichten ver ndert werden Prominentes Beispiel ist die Verfeinerung von Nachrichten die abstrakt durch nat rliche Zahlen implementierungsnah jedoch durch Bitsequenzen dargestellt werden Die Schnittstellenverfeinerung wird in Abbildung 3 9 veranschaulicht Die Nachrichten des abstrakten Systems S werden verm ge der Abstraktions bzw Repr sentationsre lationen R und Ra mit Nachrichten des konkreten Systems 53 in Beziehung gesetzt Eine Verfeinerung liegt vor wenn jedes Verhalten von S2 nach einer bersetzung mit R und Ra auch ein Verhalten von Sj
4. Eine resultierende Modifikation des Gesamtsystems l t sich auch informell interpre tieren Die Eigenschaft von S wird verst rkt um die Konjunktion der zus tzlichen Ei genschaften die von den modifizierten Komponenten erf llt werden m ssen und die durch die Komposition nicht ung ltig gemacht werden Durch neue als r formulier te Verhaltensm glichkeiten hat S zus tzliche Freiheiten in seinem Verhalten Es darf einerseits neue Verhaltensm glichkeiten einer Teilkomponenten kombinieren mit dem unver nderten Verhalten der jeweils anderen Teilkomponente andererseits darf es auch die neuen Verhaltensm glichkeiten beider Teilkomponenten kombiniert ausn tzen Gilt die Annahme der Unabh ngigkeit der Modifikationen wie wir sie bereits in Ab schnitt 5 1 kennengelernt haben also amp gt 67 und F l und zeigt S1 S2 genau das Verhalten von S gilt also auch 2 so k nnen im Beweis die Implikationen ersetzt werden zu Gleichheiten und die Aussage der Pro position MI verst rkt werden zu BAM 8 AM Q P24 M Auch f r Transitionssysteme k nnen wir eine Modifikation eines Systems S finden die zu Modifikation von Teilkomponenten pa t Da wir aber keinen Verfeinerungsbe griff zwischen Transitionssystemen definiert haben wie in Abschnitt 3 9 begr ndet definieren wir die Aussage ber die Gleichheit von modifizierten zusammengesetzten Systemen Proposition 4 8 Fortpflanzung von Modifikatio
5. Auch Zustand 5 ist ein Fehlzustand der aber noch unsichtbar bleibt Erst im Zustand 6 tritt ein Versagen auf da durch die zweite Anfrage R der interne Fehler offensichtlich wird Das System ZahlerAM reagiert mit einer 2 w hrend das fehlerfreie System eine 3 ausgegeben h tte Im Falle einer Black Box Spezifikation sieht dieser Fall g nzlich anders aus Da wir uns auf ein ungezeitetes Systemmodell beschr nkt haben kann der Z hler nur sehr grob spezifiziert werden durch eo r N j lt k sej lt j k A maz n Ik c k n lt i Auf jede Anfrage wird also reagiert die ausgegebenen Zahlen wachsen monoton und es k nnen nie mehr Daten gez hlt werden als auf i verf gbar sind Es ist ohne explizite Modellierung der Zeit nicht erkennbar in welcher Reihenfolge die zu z hlenden Daten und Anfragen vom System empfangen wurden So ist es m glich dass ein Datum dann ein R wieder ein Datum das zweite R und schlie lich das dritte Datum empfangen wurden Die Ausgabe 1 2 w re also eine korrekte und spezifizierte Reaktion des Systems Insgesamt sind im ungezeiteten Modell auf die Eingabe i d da d3 und r R R folgende Reaktionen m glich c 0 0 0 1 0 2 0 3 1 1 1 2 1 3 2 2 2 3 3 3 Der Verlust eines Datums macht sich im Verhalten dieses Beispiels nur dadurch bemerkbar dass die Zahl 3 nicht mehr ausgegeben werden kann Die Modifikation wird also durch eine Einschr nkung mittels x ausge
6. Die Verwendung formaler Methoden zielt blicherweise ab auf den Nachweis der Ab wesenheit von Fehlern in Systemen Da ein formales Modell im allgemeinen aber eine Abstraktion des realen Systems darstellt die daher potentielle beispielsweise implemen tierungsbedingte Fehler nicht repr sentieren kann beinhaltet Fehlerfreiheit im formalen Modell eine idealisierende Annahme Diese Idealisierung ist f r fr he Entwicklungspha sen zul ssig in denen die eigentliche intendierte Kernfunktionalit t des Systems im Vordergrund der Untersuchungen steht Im Rahmen einer weiteren Systementwicklung sollte es aber m glich sein Fehler als unerw nschten aber dennoch unvermeidbaren Teil eines Systems explizit aufzunehmen und zu behandeln In dieser Arbeit wird hierf r eine formale Unterst tzung pr sentiert Die formale Methodik Focus wird dazu um Begriffe und Notationen erweitert mit de nen verschiedenste Klassen von Fehlern eines verteilten reaktiven Systems sowohl in abstrakter eigenschaftsorientierter Black Box Sicht als auch im Kontext von Transiti onssystemen als sogenannte Modifikationen explizit dargestellt werden k nnen Auf der Grundlage einer formalen Darstellung wird es m glich pr zise und nachweisbare Aus sagen ber Fehlertoleranz eines Systems und die Auswirkungen von Fehlern zu machen Zur Unterst tzung einer Systementwicklung wird die schrittweise auch nachtr gliche Einf hrung von Techniken zur Fehlererkennung zur Generie
7. x type o1 x type om Diese Sicht auf Systeme wird Black Box Sicht genannt da nur das nach au en sichtbare Kommunikationsverhalten beschrieben wird ohne Bezug auf Interna des Systems wie lokale Variable Zust nde oder interne Operationen Wir geben das Verhalten von Merge im folgenden Beispiel durch eine Relation an Beispiel 3 2 Das Verhalten von Merge sei zun chst informell beschrieben Die Nachrichten die auf i und iz empfangen werden sollen auf o wieder ausgegeben werden Die Reihenfolge der Daten soll dabei nicht ver ndert werden Wenn also eine Nachricht d vor einer Nachricht d auf Kanal i empfangen wird dann soll auch auf o wieder dj vor d gesendet werden f r j 1 2 Die Art und Weise der Zusammenmischung von Nachrichten aus verschiedenen Kan len bleibt dabei beliebig d h ohne Vorgabe von Reihenfolgen oder Priorit ten Dieses Verhalten von Merge dessen informelle Beschreibung trotz seiner Einfachheit bereits re lativ aufwendig ist wird formal spezifiziert durch eine Relation die wir auch mit dem Bezeichner Merge identifizieren Merge C DY x DY x Dy U D2 Sie ist beispielhaft angedeutet in Abbildung B2 und durch folgende explizite aber nur partielle Angabe Dabei seien d di Elemente aus D und da d Nachrichten aus Da Merge 0 0 di d d2 d2 di d d di di d2 d d2 di d2 dz d 0 d2 d3 d2
8. Aber auch im laufenden Betrieb k nnen noch Fehler festgestellt werden Typischerweise wird ein System dann durch die Entwickler durch Erstellung einer neuen Version oder das Ausliefern von Patches nachgebessert Wir ordnen diese T tigkeit auch noch der Entwicklungszeit zu Laufzeit Die genannten T tigkeiten w hrend der Entwicklungszeit zielen alle auf ein fehlerfreies System ab Beim Umgang mit Fehlern w hrend der Laufzeit eines Systems akzeptiert man aber das Eingest ndnis dass Fehler in einem System enthalten sein k nnen seien es Softwarefehler die sich durch Defizite in der Entwicklung ergeben haben Hardwa refehler die durch Probleme in der Herstellung durch Verschlei bzw Alterung oder andere physikalische Einfl sse verursacht werden oder andere unber cksichtigte u ere 2 1 FEHLER 23 Einfl sse wie beispielsweise Umgebungsfehler oder Viren Ein Umgang mit derartigen Fehler zur Laufzeit muss durch das System selbst erfolgen Wir k nnen diesbez glich folgende Systemaktivit ten unterscheiden e Fehlerentdeckung Das System soll in der Lage sein einen Fehler im Sinne von Fehlzustand oder Versagen zu entdecken um darauf reagieren zu k nnen Eine Fehlerursache hingegen kann ein System normalerweise nicht selbst feststellen W ren daf r Mechanismen vorhanden h tte man sie bereits vor Inbetriebnah me des Systems verwenden k nnen um den Fehler zu beheben Das System soll w hrend seiner Laufzeit aber die Wir
9. Dh Foleo A Go o A if fail Als entsprechende Modifikation des Transitionssystems passen wir F so an dass bei Ausfall des Systems die Fehlermeldung sofort erzeugt wird p d Name Pre Input Output Post Top true f fail stop true Die Modifikationen M true bzw M E F beschreiben damit das fail stop failure Modell f r jedes System mit f O 5 1 3 Omission failure Mit omission failure bezeichnet man Verluste in der Ausgabe eines Systems Wir be schreiben dieses Fehlermodell bezogen auf einen Ausgabekanal o O des Systems S Die Verluste treten vollkommen nichtdeterministisch auf d h alle Varianten zwischen den Extremen Verlust aller Nachrichten einerseits und berhaupt keinem Verlust an dererseits sind m glich Das Normalverhalten bleibt dabei also ebenso m glich so dass wir Modifikationen mit g true bzw E w hlen F r die neuen Paare i 0 im Fehlerverhalten soll gelten dass der Strom o eine beliebige Zahl von Nachrichten nicht mehr enth lt Reichert man o wieder an zu o so stellt o ein Normalverhalten dar Formal definieren wir dieses Fehlermodell durch Bp 30 0 0 EXTEND type o A D o o 124 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN Die Relation EXTEND M enth lt alle Strompaare x y vom Typ M in denen y durch eine Anreicherung von x um Nachrichten aus M entstehen kann yeM y EXTEND M dE MAz ye M Nz E M A a
10. Soll die Modifikation der Ausgaben auch von der Eingabe abh ngen so ist nicht in jedem Fall ausreichend Information an den Ausgabekan len verf gbar Variante schafft hier Abhilfe da die Modifikationskomponente auch Kenntnis ber die Eingabe erh lt Im Prinzip ist diese Variante bereits m chtig genug um Modifikationen hin zu einem beliebigem Verhalten zu modellieren M k nnte die Ausgaben von ignorieren und ein beliebiges w hlbares Verhalten erbringen W nschenswert ist aber vielmehr die Funktionalit t von zu nutzen und in M wirklich nur die eigentliche Abweichung vom Normalverhalten zu modellieren Die in Abbildung 4 3 d dargestellte Variante bietet hier noch mehr Ausdrucksm ch tigkeit da sowohl die Ein als auch Ausgabekan le modifiziert werden k nnen Die Modifikation kann unter Ausnutzung aller Informationen definiert werden die in einer Black Box Sicht verf gbar sind d h mit Kenntnis der gesamten bisherigen Ein und Ausgabegeschichten der Komponente S Die vier erw hnten Varianten von Modifikationskomponenten werden wir nun formal definieren 4 2 MODIFIKATION DES VERHALTENS 91 Definition 4 6 Modifikationskomponenten Sei S ein System mit der Schnittstelle I O Eine Komponente mit der Schnittstelle X Y hei t Modifikationskomponente zu S wenn eine der folgenden Bedingungen erf llt ist i X29 KRY Sd Die Eingabe von M ist kompatibel zur Eingabe von I ndert also nicht die Schnittstelle nur die Na
11. die auf den endlich vielen Variablen des Systems bereinstimmen aber anderen Variablen beliebige andere Werte zuweisen Die 50 KAPITEL 3 FORMALES SYSTEMMODELL relevanten Variablen eines Systems bezeichnen wir mit V IUOUA Beschreibung konkreter Transitionssysteme Wie schon bei den Black Box Spe zifikationen kann die meist unendliche Menge T nicht explizit durch Auflistung an gegeben werden Sie wird meist durch eine Menge von Pr dikaten r angegeben die jeweils ganze Teilmengen von T beschreiben Ein Pr dikat 7 enth lt freie Variablen aus V UV Die Variablen aus V beschreiben die Werte der Variablen in einem Zustand a die gestrichenen Variablen aus V die Werte im Nachfolgezustand 9 Einem Pr dikat T wird also die Menge von Transitionen a p a p 5 T zugeordnet und einer Menge von Pr dikaten r wird erwartungsgem die Vereini gung der zugeh rigen Transitionsmengen zugeordnet Wir werden im folgenden auch ein Pr dikat 7 als Transition bezeichnen obwohl dies eigentlich einer Menge von Tran sitionen entspricht Wir k nnen nun definieren wann eine Transition in einem Systemzustand schaltbereit ist Definition 3 6 Schaltbereitschaft Sei ein Transitionssystem I O A T T gegeben e Eine Einzel Transition B y aus T hei t schaltbereit in einem Zustand a wenn sich 3 von a nur in der Zuweisung von Werten an Variable unterscheidet die im System nicht auftreten wenn also gilt aX B e
12. die diesen Wert ndern ist dies im Ausf hrungs modell einer Programmiersprache automatisch sichergestellt Solange der Wert einer Variable nicht explizit ver ndert wird bleibt er gleich Wir haben uns in dieser grundlagenorientierten Arbeit auf die Bereitstellung von allge meinen Prinzipien und die Darstellung von elementaren Zusammenh ngen fokussiert F r die Umsetzung unserer Ans tze in die praktische Verwendung in einer Systement wicklung sind noch weitere berlegungen anzustellen Im Vordergrund steht hierbei die Bereitstellung eines Werkzeugs das einen Entwickler in der Anwendung der Methodik unterst tzt Ein derartiges Werkzeug sollte es m glich machen Systeme zu beschreiben Modifikationen darauf anzuwenden und deren Auswirkungen zu untersuchen So sollte es idealerweise erm glichen aus einem Katalog von Fehlermodellen eine Fehlerklasse zu w hlen diese einem System zuzuordnen gegebenenfalls Fehlererkennungs und Kor rekturmechanismen vorzuschlagen und sogar Beweise anzupassen Eine Realisierung dieses idealisierten Werkzeugs erfordert aber noch die L sung einiger Probleme die wir im n chsten Kapitel zusammenfassen Vielversprechend sind Ans tze die beispielswei se Zust nde identifizieren f r die die Reaktivit t nicht sichergestellt ist oder die die offenen Beweisverpflichtungen in einem modifizierten Beweisdiagramm ermitteln 156 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN Kapitel 6 Zusammenfassung und Ausb
13. f hren F a B ak init A BE TA init Das resultierende System S I O AU init init true T E UF hat demnach das gleiche Verhalten wie S die Modifikation E F stellt in diesem konkreten Fall also eine neutrale Modifikation dar aber mit einer vereinfachten minimalen Initialbedingung Soll das System nun in seinen Startzust nden modifiziert werden so ist dies mit reinen Modifikationen entsprechend Definition MIB m glich F r eine praktische Beschreibung von Modifikationen ist selbstverst ndlich eine Be schreibungstechnik f r Modifikationen von A und Y w nschenswert die auf die be schriebenen schematischen Umsetzungen verzichtet Da in dieser Arbeit aber prinzipi elle berlegungen im Vordergrund stehen wollen wir hier darauf aber verzichten Beispiel 4 5 Wir modellieren zun chst die Entscheidung von welchem Kanal die modifizierte Komponente MergeAM ausschlie lich liest durch Verwendung einer neuen Variable c choice die unabh ngig vom Startwert nichtdeterministisch auf einen der Werte 1 oder 2 gesetzt wird der dann nicht mehr ver ndert wird Die entsprechenden zu erg nzenden Transitionen 73 und T4 beschreiben wir tabellarisch F Name Pre Input Output Post p T3 c 1Ac 2 c 1 T4 c 1NX1c 2 e 2 4 2 MODIFIKATION DES VERHALTENS 89 Da die Variable c noch nicht in A enthalten war k nnen die Transitionen 7 und 72 in T den Wert von c beliebig modifizieren Dies schlie en wir auf
14. ge der Fehlzust nde ERROR S M enth lt alle Zust nde a die in einem Ablauf des modifizierten Systems erreicht werden k nnen aber nur unter Verwendung von Fehler transitionen aus F ERROR S M a 3 e3kEeNe amp k a A a gt Jl lt ke 1 1 1 EF Die Menge E von Transitionen die im modifizierten System nicht mehr ausgef hrt wer den k nnen reduziert im allgemeinen die Menge der erreichbaren Zust nde und damit auch die Zahl der Fehlzust nde Eine alternative Definition in 9 verzichtet auf die Forderung der Erreichbarkeit und unterscheidet daher nicht zwischen Zust nden die durch die Modifikation unerreichbar werden und Zust nden die bereits ohne Modifika tion unerreichbar waren F r die hier gew hlte Definition sprechen zwei Argumente e Der vorgestellte Formalismus dieser Arbeit zielt darauf ab mit Fehlern explizit umgehen zu k nnen indem die Fehler ihre Auswirkungen und Gegenma nahmen modelliert werden Wie in Abbildung EI skizziert soll damit eine klare Grenze gezogen werden zwischen einerseits den Fehlern mit denen man rechnet umgehen m chte und andererseits den Fehlern f r die man eine Behandlung nicht vorsieht Obige Definition unterst tzt diese klare Trennung e In Abschnitt b 3 werden Kriterien angegeben die ein Pr dikat zur Erkennung von Fehlern zu erf llen hat Durch die Aufnahme unerreichbarer Fehler in die Menge der Fehlerzust nde m ten auch diese unn tigerweis
15. korrektur verwendet werden und werden im entsprechenden Ab schnitt 5 3 wieder aufgegriffen 4 4 Fehlertoleranz Fehlertoleranz l t sich auf verschiedene Weisen interpretieren Meist wird sie als die Eigenschaft eines Systems betrachtet auf auftretende Fehlern auf eine noch akzeptable Weise zu reagieren Eine pr zise Fehlertoleranzaussage macht diese Aussage explizit In einer alternativen Interpretation des Begriffes l t sich Fehlertoleranz als die F higkeit eines Systems verstehen die Wirkung von auftretenden Fehlern einzud mmen Wir werden beide Interpretationen im folgenden diskutieren 4 4 1 Fehlertoleranz als korrespondierende Modifikation Betrachtet man Fehlertoleranz als die Eigenschaft eines Systems auf das Auftreten von Fehlern auf eine akzeptable Weise zu reagieren m ssen die folgenden zwei Fragen beantwortet werden um diese Aussage explizit zu machen e Welche Fehler werden toleriert Ein System kann im allgemeinen nicht beliebige Fehler tolerieren sondern nur eine bestimmte Fehlerklasse In der Literatur finden sich teilweise standardisierte Fehlermodelle auf die sich Aussagen zur Fehlertoleranz beschr nken beispiels weise in 60 Eine gr ere Zahl wird aufgef hrt in 23 darunter die Fehlerklassen ommision timing response crash failures und mehr Pr zisere Aussagen ber Feh lertoleranz lassen sich machen wenn die Fehlerklassen individuell f r gew nschte Aussagen der Fehlertoleranz formuliert we
16. wie sich Modifikationen von Systemkomponenten auf das Gesamtsystem auswirken Diese Auswirkung lie sich wiederum als Modifikation des Gesamtsystems ausdr cken Es wurden sowohl die Komponenten als auch das System das sie bilden im gleichen Formalismus beschrieben also jeweils durch Black Box Spezifikationen oder durch Tran sitionssysteme In diesem Abschnitt behandeln wir den Zusammenhang von Modifikationen eines Sys tems das zweimal mit Hilfe verschiedener Techniken beschrieben wird also sowohl durch Black Box Eigenschaften als auch durch Transitionssysteme Wir nennen Modi fikationen der beiden Sichten korrespondierend wenn ihre Wirkungen sich entsprechen Man kann den Bedarf nach dem Begriff der korrespondierenden Modifikationen auf verschiedene Arten motivieren e Im Laufe eines Entwicklungsprozesses kann sich eine nderung der Anforderungen an ein System ergeben beispielsweise durch eine ver nderte Umgebung durch das Auftauchen neuer Kundenw nsche oder durch eine Korrektur die eine fehlerhafte Spezifikation n tig macht Hat man aber bereits eine abstrakte Implementierung des Systems in Form eines Transitionssystems so mu dieses an die neuen Forde rungen angepasst werden e Auch umgekehrt k nnen sich Modifikationen ergeben Werden beispielsweise Feh ler in einer Implementierung beobachtet so lassen sich diese in vielen konkreten F llen leicht durch zus tzliche Transitionen nachmodellieren Spontane nderun gen vo
17. 1 Mit jedem Empfang eines Datums verringert sich die Kapazit t des Puffers um 1 mit jeder Anfrage und dadurch ausgel ster Ausgabe eines Datums erh ht sich die Kapazit t wieder um 1 Die Differenz der empfangenen Daten und der empfangenen Anfragen darf also niemals h her als N liegen nur dann w rde der Puffer seine Kapazit tsgrenze ber schreiten Es muss also gelten D i R i lt N Diese Forderung ist allerdings noch zu schwach denn sie macht nur eine Aussage iiber die gesamte m glicherweise unendliche Kommunikationsgeschichte Die Forderung mu aber 3 5 BLACK BOX SPEZIFIKATIONEN 47 w hrend des gesamten Ablaufes also auch in allen Zwischen zust nden gelten Dies wird ausgedr ckt indem die G ltigkeit der obigen Bedingung f r alle Pr fixe von i gefordert wird Vil Cie DOi R Oi lt N 2 Zu vermeiden ist der Fall dass der Puffer eine Anfrage in einer Situation erh lt in der berhaupt keine Daten im Puffer enthalten sind Dies passiert wenn mehr Anfragen als Daten empfangen werden wenn also obige Differenz negativ wird Um dies auszuschlie en gehen wir davon aus dass dieser Fall nie also f r keinen Pr fix von i eintritt und fordern entsprechend Vi Cie DOi R Oi gt 0 Die Konjunktion dieser beiden Forderungen ergibt unsere Umgebungsannahme Unter dieser Annahme ist nun das Verhalten des Puffers als Pr dikat G zu formulieren Der Inhalt der Ausgabe auf dem Kanal o wird in
18. Abweichungen dieser Attribute beschreiben In den folgenden Kapiteln wer den wir diese Sichtweise pr zisieren indem wir formale Definitionen dieser drei Begriffe erarbeiten Wir betrachten Systeme die aus Komponenten zusammengesetzt sein k nnen Zur Mo dellierung von Fehlern wollen wir auf eine Teilkomponente des Systems fokussieren um darin enthaltene lokale Fehler zu modellieren und ihre Wechselwirkungen sowohl mit dem restlichen System als auch mit der Umgebung explizit darzustellen und zu untersuchen Dies f hrt zu einer Sicht auf Systeme wie sie in Abbildung P I dargestellt ist Dargestellt ist darin ein System das in eine Teilkomponente 5 und ein Restsystem 9 untergliedert ist Die Systemumgebung wird durch E repr sentiert Die Teilkomponente S wird im Vergleich zum Restsystem S hervorgehoben und damit in das Zentrum der 18 KAPITEL 2 DER FEHLERBEGRIFF E e co ee 5 gt g w Abbildung 2 1 Zusammengesetztes System mit Umgebung Betrachtungen ger ckt Die Komponente S interagiert sowohl mit dem Restsystem als auch direkt mit der Umgebung w hrend nat rlich auch S mit E interagiert Durch die Wahl der Grenze zwischen und kann jeder beliebige Teil eines Systems fokussiert werden S kann das Gesamtsystem umfassen mehrere zusammengefa te Teil komponenten oder auch nur eine Einzelkomponente Im Rahmen einer Fehlermodellie rung k nnen damit Fehler eines
19. Ap lt 4 e In dem durch o repr sentierten Zustand ist das Ziel Y erreicht d h o gt Y 3 8 VERIFIKATION VON EIGENSCHAFTEN 65 y N gt o gt k k lt Hi 75 Abbildung 3 8 Fortschrittsdiagramm f r Merge Befindet sich das System in einem Zustand in dem gilt so befindet es sich auch in einem durch o charakterisierten Zustand Da immer eine Transition schaltbe reit ist wird aufgrund der Fairness jeder Zustand auch wieder verlassen Beim Wechsel in einen anderen Knoten wird dabei der Wert der Bewertungsfunktion reduziert Da der Wert nicht beliebig klein werden kann muss schlie lich im weiteren Systemablauf der Knoten o erreicht werden der das Zustandspr dikat Y erf llt K nnen also alle gefor derten Eigenschaften eines Fortschrittsdiagramms nachgewiesen werden repr sentiert es einen Nachweis f r die Aussage SI y Diese Form der Fortschrittsdiagramme stellt eine Verallgemeinerung der Diagramme in I0 dar da Zyklen im Graph hier zugelassen werden Eine Einbettung wird mit der trivialen Bewertung 6 i erreicht Beispiel 3 12 Wir wollen mit einem Diagramm beweisen dass Merge IF 0 k k lt ut i2 o gt k gilt d h die Ausgabe wird verl ngert solange sie nicht genauso lang ist wie die Eingabestr me an beiden Eingabekan len Es werden also tats chlich alle Eingaben wieder ausgegeben Das einfache Beweisdiagramm mit nur zwei Knoten und o findet sich in Ab
20. Das neue Diagramm enth lt 16 Beweisverpflichtungen 3 Knoten mit jeweils 5 Transitio nen und die G ltigkeit des Initialzustandes Von diesen wurden 10 bereits im alten Diagramm gezeigt lediglich 6 neue Beweisverpflichtungen entstehen durch die beiden neuen Transitionen Selbstverst ndlich ist der Grad der Wiederverwendung nicht in allen F llen hoch Bei starken Modifikationen die mit vielen neuen Transitionen viele neue Knoten erzeugen entstehen auch viele neue Beweisverpflichtungen Dennoch ist es auch in diesem Fall lohnens und erstrebenswert auf einem bereits existierenden Beweis aufzubauen auch wenn dieser unter Umst nden nur noch einen Spezialfall des Gesamtbeweises abdeckt 5 7 2 Fortschrittsdiagramme Mit einem Fortschrittsdiagramm entsprechend Kapitel B 8 2 kann eine Eigenschaft der Form gt WV nachgewiesen werden Wird die Transitionsmenge des Systems ver ndert so erf llt das System im allgemeinen diese Eigenschaft nicht mehr Wir werden im folgenden untersuchen in welchen F llen die G ltigkeit erhalten bleibt oder wie die 5 7 WIEDERVERWENDUNG VON BEWEISEN 149 Eigenschaft an das ver nderte System angepasst werden kann Dabei unterscheiden wir wieder zwischen dem Entfernen und Erg nzen von Transitionen Entfernen von Transitionen Eine mit einem Fortschrittsdiagramm verbundene Be weisverpflichtung fordert dass von jedem Knoten des Diagramms au er vom Zielknoten o mindestens eine ausgehende Transition schal
21. Eine Transition smenge T ist schaltbereit in einem Zustand a wenn es einen Nachfolgezustand gibt der von aus mit T erreichbar ist SBea B Er Dies wird abgek rzt durch a En r Wir veranschaulichen die Formalisierung von Transitionssystemen anhand des folgenden Beispiels Beispiel 3 5 Merge als Zustandstransitionssystem Wir spezifizieren wieder das System Merge das wir in BeispielBB schon kennengelernt haben Die Ein und Ausgabekan le des Transitionsystems Merge I O A T T sind offensichtlich I i i2 O o 3 6 ZUSTANDSTRANSITIONSSYSTEME 51 Da wir uns keine Daten merken miissen und unsere Reaktion auch nicht von der Vorgeschichte abh ngt brauchen wir weder Daten noch Kontrollzust nde und definieren ein minimales A durch Hinzuf gen der Variablen f r den gelesenen und ungelesenen Teil der Eingabestr me A i ag ay is Die Startzust nde beschreiben wir durch das Pr dikat Yerv a AR N0 Das System Merge startet also ohne initiale Ausgabe und natiirlich ohne bereits konsumierte Eingaben Es soll nun in der Lage sein Daten von beiden Kan len auf den Ausgabekanal zu kopieren F r den Kanal 7 definieren wir dazu ein Pr dikat 7 durch af n 3de fti d is if d A o 07 d A ig 18 A Oi Ayle Die erste Zeile stellt sicher dass eine Nachricht d auf dem Eingabekanal 7 vorliegt Entspre chend der zweiten und dritten Zeile wird diese Nachricht
22. Invariante beweisen Als Beispiel f r eine Fortschrittseigenschaft geben wir folgende Behauptung an Wird in einem Ablauf ein Zustand erreicht in dem die L nge des Ausgabestromes k rzer ist als die Summe der L ngen der Eingabestr me so wird im weiteren Ablauf die Ausgabe noch weiter verl ngert 62 KAPITEL 3 FORMALES SYSTEMMODELL Merge l 0 k k lt i i gt o gt k Auch diese Aussage werden wir im folgenden mit Hilfe von Verifikationsdiagrammen beweisen Da in komponierten Systemen die Teilkomponenten nur ber asynchrone und damit nicht blockierenden Nachrichtenaustausch kommunizieren und interagieren sonst je doch entkoppelt bleiben weist unser Systemmodell Kompositionalit t auf d h die Ei genschaften eines Systems bleiben im Kontext eines weiteren Systems erhalten Es gilt also f r j 1 2 S I inv Sj Y S Q S2 IF inv S1 Q S2 lF BOW 3 8 2 Verifikationsdiagramme Ein formaler Beweis einer Eigenschaft eines Transitionssystems stellt sich klassischer weise als eine lineare Folge von Aussagen dar die ausgehend von Axiomen oder Tau tologien unter Verwendung von Beweisregeln ber Zwischenresultate hinweg die zu be weisende Aussage herleiten Eine derartige Darstellung folgt nicht der Intuition der operativen Funktionsweise die man mit einem Transitionssystem verbindet Ein Ve rifikationsdiagramm ist geeignet einen Beweis zu veranschaulichen Es stellt an sich keinen Beweis dar aber impli
23. Komplexit t bei der Systementwicklung bei da sie ein System auf seine f r die intendierte Funktionalit t relevanten Aspekte reduziert For male Methoden betrachten diese Klasse von Fehlern meist nicht sondern gehen implizit davon aus dass diese Fehler auf implementierungsnaher Ebene abgefangen und behan delt werden also au erhalb des formalen Rahmens Damit wird die Anwendbarkeit der formalen Methoden auf einen Teil der Systementwicklung beschr nkt Ein Ziel der Arbeiten auf dem Gebiet der formalen Methoden ist es aber die erm glichte Pr zision nicht nur auf Ausschnitte eines Systems zu begrenzen sondern eine durchg n gige Verwendung zu erm glichen beispielsweise durch einen automatisierten bergang von Spezifikationen zu implementierungsnahen Systembeschreibungen bis zur Gene rierung von Code Dies erfordert den Umgang mit den letztendlich unvermeidbaren Fehlern auch innerhalb der abstrakten Formalismen Die durch die Abstraktion indu zierte idealisierte Annahme von Fehlerfreiheit soll bewu t und auf systematische Weise aufgegeben werden k nnen Fehler k nnen damit formal erfa t werden Eine weitere Motivation zur Integration von Fehlern ist eine w nschenswerte Unter st tzung der Entwicklung sogenannter fehlertoleranter Systeme In diesen spielen Fehler eine prominente Rolle da Aussagen ber das Systemverhalten diese explizit referenzie ren Fehlertoleranz ist eine Eigenschaft die gerade bei sehr hohen Sicherheits und
24. Komposition der restlichen Komponenten beinhal tet Wir wollen nun ermitteln welche Modifikation des Gesamtverhaltens sich aus einer Modifikation von 5 ergibt Wir k nnen f r die Darstellungsform der Black Box Spezifikationen als auch der Transi tionssysteme Charakterisierungen der Auswirkungen definieren Dazu gehen wir jeweils von einem zusammengesetzten System aus und definieren aus den Modifikationen der Einzelkomponenten die quivalente Modifikation des Gesamtsystems Proposition 4 7 Fortpflanzung von Modifikationen bei Black Box Spezifikationen Sei ein System S durch die Black Box Spezifikation gegeben das durch ein komponier tes System aus zwei Komponenten S und Sa verfeinert wird Das Verhalten der beiden Komponenten wird jeweils durch eine Black Box Spezifikation und a beschrieben d h P P amp P oder auch APR gt P Wird das Verhalten der Komponenten durch Modifikationen M 1 PL und Ma 823 92 ver ndert so entspricht dies der Modifikation M p p des Gesamt systems mit r L APZ Dr P A OF v 8 A OL V PL A P23 Es gilt dann also PAM P1AM1 8 P24 M 108 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Dies kann leicht bewiesen werden wie folgende Deduktion zeigt 81AM A 24M2 A PL v OL A 2 A 2 V 6 8 APh A Bp A 4 V 8 A OL A 62 V BEN Ba A 8 V Du A DR gt 1 APL A by A P3 V 8 A 64 V Dh A 2 V Ph A 4 gt A z r
25. Kontext verwendet wird und dass es seine Funktionalit t tats chlich nur unter diesen Bedingungen erbringen kann oder wenn es m glich ist bei Kenntnis der Umgebungsannahmen eine bez glich geeigneter Kriterien g nstigere Implementierung zu w hlen Eine Annahme bez glich der Umgebung eines Systems ist eine Aussage ber seine Eingabestr me semantisch im einfachsten Fal also eine Teilmenge von type i1 x x type tn Im allgemeinen Fall ist es n tig diese Menge auch in Abh ngigkeit von den Ausgaben des Systems selbst zu definieren wie es in Kapitel B 5 motiviert wurde Wir beschr nken uns hier auf den einfachen Fall 114 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Diese Menge enth lt alle Eingabestr me die die Umgebung an das System senden darf Die Teilmenge der zugelassenen Eingabestr me kann wieder entsprechend den Be schreibungstechniken aus den Kapiteln B 5 undB 6 auf zwei Arten beschrieben werden e Eine Black Box Spezifikation der Umgebungsannahme wird durch eine Formel A il in beschrieben die die Namen der Eingabestr me und m glicherwei se auch der Ausgabestr me als freie Variable enth lt Diese Annahme kann un abh ngig von der Beschreibungstechnik f r das System selbst formuliert werden insbesondere also auch f r Transitionssysteme Wurde das System im Format ei ner A G Spezifikation definiert so ist die Annahme A darin bereits blicherweise definiert e Die Menge der ge
26. Nachweis sichergestellt werden Im Rahmen einer Systementwicklung kann es allerdings ausreichend sein dies erst indirekt durch die Entwicklung einer Im plementierung zu tun Beispiel 3 3 Das System Merge kann sehr leicht in der Black Box Sicht spezifiziert werden Betrachtet man im Ausgabestrom o die Nachrichten die vom Eingabekanal 7 kommen k nnen so sind dies genau die Nachrichten die auf i tats chlich empfangen wurden und sie erscheinen in unver nderter Reihenfolge Extrahiert man also aus o den Strom der Nachrichten vom Typ Dj so ist dieser identisch mit i1 Die analoge Forderung f r iz ergibt die vollst ndige Black Box Spezifikation Wir benennen das Pr dikat entsprechend dem Namen des Systems Merge D o i A Do ia Die Stromtupel aus Beispiel BP erfiillen alle die hier genannte Spezifikation Eine spezielle Form von Black Box Spezifikationen stellen die sogenannten Assumpti on Guarantee oder auch Rely Guarantee oder Assumption Commitment Spezifikatio nen dar die die Funktionalit t eines Systems in Abh ngigkeit von Eigenschaften der Umgebung definieren Einfache Assumption Guarantee Spezifikationen Eine einfache A G Spezifikation besteht aus zwei Pr dikaten A und G Das Pr dikat A weist als freie Variable nur Kan le aus auf und beschreibt welche Eingabestr me von der Umgebung an das System geschickt werden d rfen Darin ist also die Annahme an die Umgebung formuliert deren G ltigkeit vo
27. Nutzen der definierten Begriffe und des vorgeschlagenen methodischen Um gangs sollte durch Fallbeispiele nachgewiesen werden Die angestrebte Erweiterung formaler Methoden stellt einen weiteren Schritt hin zu einer durchg ngigen Verwendung formaler Methoden dar die nicht nur Fehlervermei dung sondern den expliziten bewu ten und pr zisen Umgang mit Fehlern erm glicht 1 5 berblick In KapitelP Jcharakterisieren und diskutieren wir den Begriff des Fehlers auf Grundlage relevanter Literatur Wir differenzieren Fehler in Fehlerursachen Fehlerzust nde und Versagen geben eine Klassifikation der Begriffe an und beschreiben Techniken zum Um gang mit Fehlern Das Thema der Fehlertoleranz wird ausf hrlicher behandelt indem sowohl bekannte formale Ans tze vorgestellt werden als auch etablierte Techniken die in fehlertoleranten Systemen zum Einsatz kommen Um die Fehlerbegriffe formal definieren zu k nnen ist eine mathematische Grundlage notwendig Dazu pr sentieren wir in Kapitel B ein Systemmodell das zur Modellierung verteilter reaktiver Systeme geeignet ist Ein System wird darin als eine Menge intera gierender Komponenten dargestellt die ber Kommunikationskan le asynchron Nach richten austauschen Die Kommunikationsgeschichte wird durch Nachrichtenstr me 8 KAPITEL 1 EINF HRUNG Systemverhalten durch Relationen von Nachrichtenstr men dargestellt Es werden zwei Beschreibungstechniken f r Systeme pr sentiert die sich
28. Sicht auf Systeme steht uns mit den Transitionssys temen eine ablauforientierte Sicht zur Verfiigung Auch fiir diese Sichtweise wollen wir nun Modifikationen einfiihren 4 2 3 Modifikationen von Transitionssystemen Ein Transitionssystem kann auf zwei natiirliche Arten modifiziert werden und zwar durch das Hinzufiigen von Transitionen einerseits und durch das Entfernen von Transi tionen andererseits Die Modifikation des Zustandsraumes spielt eine nur untergeordnete Rolle wie wir im folgenden noch diskutieren werden Wir definieren die Modifikation eines Transitionssystems daher durch die Angabe entsprechender Transitionsmengen wie folgt Definition 4 5 Modifikation von Transitionssystemen Sei S I O A Y T ein Transitionssystem und seien E und F Mengen von Tran sitionen E F C VALx VAL wobei F die Forderung d aus Definition BP erf llt Die Modifikation M E F entfernt die Menge E der Transitionen aus der Transitionsmenge T und f gt die Tran sitionen aus F hinzu SAM 1 0 A Y T E UF Die Forderung an F beschr nkt uns in der Modifikation von Transitionssystemen So sollen auch modifizierte Systeme die Eigenschaft behalten das Lesen von Nachrichten nicht mehr r ckg ngig machen zu k nnen nur bereits gesendete Nachrichten zu lesen 4 2 MODIFIKATION DES VERHALTENS 87 und einmal geschriebene Ausgaben nicht mehr l schen zu k nnen Die Beweisprinzipien aus Abschnitt B 8 lerfordern diese Eigenschaf
29. Typ des Kanals f bleibt dabei noch unspezi fiziert 4 1 MODIFIKATION DER SCHNITTSTELLE 79 Eine Erweiterung der syntaktischen Schnittstelle soll unabh ngig von einer Verhal tens nderung geschehen Da sich die Typen der Kan le ver ndert haben muss auch die verhaltensbeschreibende Relation angepa t werden aber in einer Weise die das Verhalten nicht wesentlich ver ndert Wir m ssen nun also definieren welche an die neue Schnittstelle angepa te Relation wir als das im wesentlichen gleiche Verhalten interpretieren Ausgehend von der existierenden auf die unmodifizierte Schnittstelle bezogene Relation soll die angepa te Verhaltensrelation folgende Eigenschaften aufwei sen e Die Eingabe ber neue Kan le soll ignoriert werden also keinen Einflu auf das an den alten Ausgabekan len sichtbare Ausgabeverhalten haben Das Verhalten darf nur abh ngen von den Eingaben auf den urspr nglichen bereits vorhandenen Kan len e Neue Nachrichten auf bereits vorhandenen Kan len werden ignoriert e Auf neuen Ausgabekan len d rfen beliebige Nachrichten des passenden Typs gesendet werden Diese d rfen zwar auch von den Eingaben an neuen Kan len abh ngen m ssen es aber nicht e Auf typerweiterten Ausgabekan len werden nur Nachrichten vom urspr nglichen Typ gesendet Ein derartiges in seiner Schnittstelle erweitertes und im Verhalten angepa tes System kann damit in der gleichen Umgebung eingesetzt werden wie
30. Umgebung dies nicht mit ihren bereits gesendeten Nachrichten tun kann F r alle Transitionen d rfen die Belegungen der i und o also nur l nger werden wie in der zweiten Zeile in d formali siert Schlie lich d rfen die Transitionen des Systems nicht das Verhalten der Umgebung einschr nken gefordert in e Ein Berechnungsschritt darf nicht verbunden sein mit einer spezifischen Verl ngerung der Eingabe sondern muss beliebige Verl ngerungen zulassen Entsprechende Transitionen m ssen also in T mit enthalten sein F r alle Eingabestr me gilt jederzeit 7 E i wie durch Induktion leicht zu zeigen ist Initial gilt mit 7 die Aussage trivial und f r jeden Schritt mit a 8 T gilt aufgrund von d sofort B i E a i C i Wir k nnen daher den ungelesenen Teil eines Eingabestromes definieren als i durch die Forderung i i it Die Umgebungstransitionen lassen alle kontrollierten Variablen eines Systems unver n dert k nnen jedoch die Eingabestr me beliebig verl ngern Damit kann ein System f r jeden Eingabekanal jeden beliebigen Eingabestrom erzeugen Damit wird sichergestellt dass in der Menge der Abl ufe vgl DefinitionBI7 wirklich f r alle Eingaben Reaktionen definiert werden Ein Zustand eines Transitionssystems besteht aus einer Belegung a VAL die den Va riablen aus JZU OU A Werte zuweist Die Darstellung eines Zustandes ist nicht eindeutig da es beliebig viele andere Belegungen gibt
31. Verst rkung einer Aussage erm glichen Der Einfachheit halber haben wir die Fortschrittseigenschaft mehr als n tig abgeschw cht und haben nur gezeigt dass die Ausgabe verl ngert wird wenn k lt min t1 12 ist Hat sich das System verm ge der Wahl eines c aber f r einen Kanal entschieden so muss k nur k rzer als der entsprechende Eingabestrom sein 5 8 ZUSAMMENFASSUNG UND DISKUSSION 153 Allerdings kann die Beweisanpassung im allgemeinen nicht automatisch erfolgen Be reits die Erstellung eines Diagramms f r das unmodifizierte System erfordert ein Ver st ndnis seiner Funktionsweise so dass auch die Anpassung Einsicht und Kreativit t erfordert Die Anpassung eines Systems und der Beweisdiagramme ist eine komplexe Aufgabe Fehlertransitionen k nnen teilweise durch weitere hinzuzuf gende Modifika tionen wieder unsch dlich gemacht werden Diese haben aber auf die beiden Diagramm arten unterschiedliche Auswirkungen So k nnen beispielsweise durch neue Transitionen Fortschrittseigenschaften einfach wieder g ltig gemacht werden wobei aber wiederum Invarianten ihre G ltigkeit verlieren k nnen Das F hren von Beweisen mit Hilfe von Diagrammen ist in einem Entwicklungsproze besonders dann hilfreich und gewinnbringend einzusetzen wenn es durch ein Werkzeug unterst tzt wird In T3 wird dies vorbereitet Ein Werkzeug sollte es erm glichen Beweisdiagramme zu erstellen die implizierten Beweisverpflichtungen zu generiere
32. Z 5Juntersuchen Die Transitio nen T bzw T werden dort so eingeschr nkt dass sie nur f r c 1 oder f r c 2 schaltbereit sind Im Knoten ist dazu keine Information verf gbar so dass die erforderliche Schaltbe reitschaft in diesem Knoten nicht nachgewiesen werden kann Wir spalten diesen Knoten auf in drei Knoten die disjunkten F llen entsprechen Das zugeh rige Diagramm ist in Abbildung 5 10 dargestellt und hat die identische Aussage wie das Diagramm in B 8 Dabei beschreibt wieder das Pr dikat 9 0 k k lt i iz2 Zudem sind bereits die berg nge der neuen Transitionen von 73 und 74 eingetragen Diese legen den Wert von c auf 1 oder 2 fest und sind auch nur genau dann schaltbereit wenn c noch keinen dieser Werte hat Wir modifizieren nun die Transitionen zu r und 75 Durch die st rkeren Vorbedingungen k nnen einige Kanten gel scht werden da rj nur im linken oberen Knoten und 73 nur im rechten Knoten schaltbereit ist Dennoch ist damit kein g ltiges Diagramm erreicht da die Schaltbereitschaft von 7 und 73 nicht nachgewiesen werden kann Wir setzen hier lediglich voraus dass die Anzahl der bisherigen Ausgaben unterhalb der Anzahl der Eingaben an beiden Eingabekan len liegt Daraus kann jedoch nicht geschlossen werden dass an einem der beiden Kan le noch Nachrichten vorhanden sind Die behauptete Aussage ist f r das modifizierte System auch tats chlich nicht 152 KAPITEL 5 METHODISCHER UMGANG MIT FE
33. anhand von Beispielen veranschau licht Zur Formalisierung von Fehlern haben wir in Kapitel 4 die sogenannten Modi fikationen M eingef hrt Mit einer Modifikation wird der Unterschied zwischen einem System S und einer modifizierten Version SAM des Systems beschrieben Mit als einer Beschreibung des Soll Systems und SAM als Ist System ist die Mo difikation M eine formale Charakterisierung eines Fehlers der eine Abweichung eines Soll vom Ist darstellt Damit eignen sich Modifikationen hervorragend zur Formalisierung von Fehlern Zur Darstellung konkreter Modifikationen haben wir drei verschiedene Beschrei bungstechniken vorgestellt Die Modifikationen von Black Box Spezifikationen Abschnitt E2 2 die Modifikationen von Transitionssystemen Abschnitt 2 3 6 1 BEITRAG DIESER ARBEIT 159 und Modifikationskomponenten Abschnitt 2 4 Damit k nnen Fehler auf ver schiedenen Abstraktionsniveaus beschrieben werden Im Gegensatz zu fehlermodellierenden Techniken aus anderen formalen Ans tzen k nnen unsere Modifikationen sowohl Verst rkungen von Eigenschaften als auch Abschw chungen bzw die Entfernung als auch das Erg nzen von Transitionen beschreiben Sie sind damit in ihrer Ausdruckskraft sehr allgemein und k nnen nicht nur f r Fehler sondern auch zur Formalisierung intendierter nderungen wie f r Updates oder Patches von Systemen verwendet werden Den Modifikationsbegriff verwenden wir in Kapitel 3 als Grundlage zur f
34. beispielsweise in 89 43 66 werden zwei m gliche kausale Zusam menh nge zwischen den drei Fehlerbegriffen angesprochen e Eine Fehlerursache bewirkt einen Fehlerzustand e Ein Fehlerzustand f hrt zu einem Versagen In beiden F llen sind die Konsequenzen m glich aber nicht zwingend Eine Fehlerur sache kann muss aber nicht zu einem Fehlerzustand f hren Beispielsweise mu ein bug in einem Programm nicht zu einem falschen Wert f hren wenn der fehlerhafte Programmteil nicht ausgef hrt wird oder in einem konkreten Ablauf keine Folgen zeigt Auch ein Fehlerzustand mu nicht zu einem sichtbaren Ausfall f hren wenn wie oben schon erw hnt ein falscher Wert nie gelesen wird oder vor dem Lesen durch einen kor rekten Wert berschrieben wird Techniken der Fehlermaskierung und Fehlertoleranz dienen genau dazu diesen Kausalit tszusammenhang zu durchbrechen Die Zusammenh nge der Kausalit ten der drei eingef hrten Begriffe sollen an einem Beispiel erl utert werden Gehen wir aus von einem System das entsprechend einem Design also einem Bauplan aus Komponenten zusammengesetzt ist Im Design sei ein Fehler enthalten der eine mangelhafte Interaktion zweier Komponenten bewirkt In einem Ablauf f hrt dies zu einer inkonsistenten Belegung von Variablen dieser beiden Komponenten Es liegt also ein Fehlzustand des Systems vor Es kann sein dass dieser Fehlzustand nur erkennbar ist wenn der Gesamtzustand betrachtet wird aus
35. ckt die wir im Verlauf der Arbeit noch oft verwenden werden Notationelle Konvention Wir gehen f r eine vereinfachte Notation f r Charakte risierungen von Verhaltensrelationen von nur einem Eingabekanal und einem Ausgabe kanal aus und identifizieren den Bezeichner f r einen Kanal mit dem Strom der auf ihm bertragen wird 44 KAPITEL 3 FORMALES SYSTEMMODELL Wir w hlen also f r die Notation f r die Str me auf dem Eingabekanal die Bezeichnung i und f r Str me auf dem Ausgabekanal o Damit vereinfacht sich beispielsweise der Ausdruck Vz type t1 n type in zu einem kurzen Vie Die Forderung der Linkstotalit t m te ausf hrlich notiert werden als Vz type i1 2n type in Iy type 01 Ym type Om ee le ER Wie im Beispiel bereits angedeutet enth lt eine verhaltensbeschreibende Relation im allgemeinen unendlich viele Tupel wobei bereits ein einzelnes Tupel unendlich lange Str me enthalten kann Daher kann eine konkrete Relation nicht durch explizite Auf listung angegeben werden was aber auch im Fall von endlichen Relationen keine an gemessene Technik w re In den n chsten Abschnitten werden wir Formeln Abschnitt B 5 und Diagramme Abschnitt B 6 als geeignetere Beschreibungstechniken angeben 3 5 Black Box Spezifikationen Wie wir im vorherigen Abschnitt gesehen haben l t sich das Verhalten eines Systems abstrakt als eine Relation b
36. damit die Eigenschaften des Ein Ausgabeverhaltens unmittelbar beschreibt Ein Transitionssys tem gibt dagegen ein Verhalten operationell an und enth lt keine unmittelbaren Aussa gen ber die Eigenschaften des Systemverhaltens An der Transitionsmenge der m gli chen Einzelschritte ist das Verhalten das daraus entstehen k nnte unter Umst nden schwer erkennbar Dennoch ist man an der Verifikation von Eigenschaften der Abl ufe von Transitionssystemen interessiert da sich damit ein Zusammenhang zwischen den beiden Beschreibungstechniken herstellen l t Wir werden im folgenden mit den Invarianten und den Fortschrittseigenschaften zwei Klassen von Eigenschaften der Transitionssysteme vorstellen die mit den bekannten Sicherheitseigenschaften beziehungsweise Lebendigkeitseigenschaften diese werden vor gestellt in I ein Literatur berblick findet sich in 40 eng verwandt sind Daraufhin werden wir die Technik der Verifikationsdiagramme pr sentieren die sich eignet forma le Beweise auf abstraktem Niveau intuitiv darzustellen Eine ausf hrliche Behandlung dieser Themen findet sich in 10 3 3 8 1 Eigenschaften von Transitionssystemen Die Eigenschaft P eines Transitionssystems beschreiben wir durch ein Pr dikat P Weist ein System S ein Pr dikat P auf so notieren wir dies als SIF P Wir sind hier nicht an statischen Eigenschaften eines Systems interessiert wie beispiels weise die Zahl der Transitionen den Grad von Nichtde
37. das gar keine Ausgaben mehr erzeugt Ist der Totalausfall erkennbar kann dies mit fail stop failure bezeichnet werden Ist der Ausfall nicht unmittelbar erkennbar sondern sind eigene Mechanismen au erhalb der ausgefallenen Komponente n tig wie beispielsweise Timer so spricht man von fail silent oder crash Versagen Ist nach einem Totalausfall ein Neustart m glich so kann im Falle eines pause crash failure das System in dem Zustand seine Aktivit t fortsetzen in dem das Versa gen auftrat oder einem Zustand kurz vor diesem Startet das System ganz neu im Grundzustand also mit v lligem Informationsverlust nennt man dies amne sia crash failure F hren die Auswirkungen eines Versagens zu einer Inkonsistenz von Daten im System wird ein Fehler corrupting genannt Die gravierendste 2 1 FEHLER 17 Klasse der sogenannten byzantine failures beschreibt ein chaotisches Versagen bei dem beliebiges Verhalten m glich wird also keinerlei Information ber das Systemverhalten mehr verf gbar ist Auswirkungen Die Auswirkungen von Versagen k nnen wie Fehler bewertet werden nach ihrem Schweregrad und beispielsweise in harmlos oder unkritisch kritisch und katastrophal eingestuft werden In komponierten Systemen ist es interessant die Auswirkungen des Versagens von Komponenten auf das Gesamtverhalten zu untersuchen Dazu muss es m glich sein aus dem Verhalten von Komponenten und der Kenntnis des Systemdesigns das Verhalten des Gesamtsyste
38. das urspr ngliche Sys tem ohne ein neues Verhalten zu erzeugen Die genannten Anforderungen sind in der folgenden Definition reflektiert Definition 4 2 Verhaltensgleichheit bei ver nderter Schnittstelle Sei durch die Relation R das Verhalten eines Systems mit der Schnittstelle I O spe zifiziert d h R C typeli x x type in x type 01 x type om Sei ferner T eine erweiterte Schnittstelle mit k neuen Eingabe und l neuen Aus gabekan len Die Relation R vom Typ C type h x x type in x type ingi x x typelin r x type 01 x x type m x type m 1 x x type Om 1 hei t die verhaltensgleiche Relation zu R und ist definiert durch OBERE ER ERLERNT eR def type 41 O2 Hg type in D amp n Yl Ym ER 80 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN In der Definition wurden entgegen der Konvention die Kanalnamen und die Nachrichten str me nicht mit den gleichen Variablen bezeichnet da dies zu verwirrenden Ausdr cken wie type i i gef hrt h tte Stattdessen wurden die neuen freien Variablen x und y zur Repr sentation der Ein und Ausgabestr me verwendet Wir veranschaulichen die Definition an einem Beispiel Beispiel 4 2 Verhaltensgleichheit von Merge Betrachten wir erneut die Komponente Merge mit der ver nderten Schnittstelle Das konkrete Verhalten d high di di ia d2 dh high 6 d do di di db f
39. dem hier vorgestellten Systemmodell abst tzen Eine detailliertere Beschreibung von Focus findet sich in BI 9 Weitere Literatur aus dem Projektumfeld zusammen mit Anwendungen von Focus ist in 25 aufgef hrt Die Beweiskonzepte und regeln sind ausf hrlich in TO 12 vorgestellt und 0 TI enth lt eine Beschreibung der Verwendung von Verifikationsdiagrammen in Kontext von FOCUS 3 1 berblick Ein System ist im Sinne von FOCUS eine von der Umgebung abgegrenzte Einheit die durch eine Definition ihrer Schnittstelle zur Umgebung und ihres Verhaltens vollst ndig charakterisiert werden kann Die Schnittstelle besteht aus einer Menge von Kanalnamen Ein Kanal ist eine Kommu nikationsverbindung ber die Nachrichten unidirektional also in eine Richtung flie en 37 38 KAPITEL 3 FORMALES SYSTEMMODELL k nnen Einem Kanal ist ein Typ zugeordnet als eine Menge von Nachrichten die auf diesem Kanal gesendet und empfangen werden k nnen Das Verhalten wird durch eine Relation zwischen Eingabe und Ausgabe dargestellt Ein und Ausgaben werden durch Nachrichtenstr me beschrieben die den Kan len zugeord net werden Ein Strom ist eine m glicherweise unendliche Sequenz von Nachrichten die die gesamte Kommunikationsgeschichte der Lebenszeit eines Systems beschreibt Ein System ist typischerweise wieder aus Komponenten zusammengesetzt Diese Kom ponenten sind wiederum eigenst ndige Systeme mit Schnittstelle und Verhalten
40. den Eingaben an das System und den Ausgaben mit denen das System auf erstere reagiert Um ein konkretes Verhalten anzugeben m ssen wir also f r jede m gliche Eingabe definieren mit welcher Ausgabe das System darauf reagieren wird Im allgemeinen h ngt diese Reaktion nicht nur von einer einzelnen Nachricht in der Eingabe zu einem bestimmten Zeitpunkt ab sondern auch von der gesamten Vorge schichte also den zuvor bereits empfangenen und verarbeiteten Nachrichten So h ngt beispielsweise die Reaktion eines Lesebefehls an einen Speicher davon ab welche Daten vorher in den Speicher geschrieben wurden Eine derartige Information wird blicher weise in einem Zustand des Systems gespeichert Da wir Zust nde eines Systems aber vorerst nicht modellieren wollen setzen wir komplette Eingabegeschichten mit Aus gabegeschichten in Beziehung Die Pr fixe der Kommunikationsgeschichten lassen sich als abstrakte Repr sentationen von Zust nden interpretieren Formal k nnen wir die Beziehung von Ein und Ausgabegeschichten ausdr cken durch eine Relation R die ganze Eingabestr me und Ausgabestr me zueinander in Beziehung 42 KAPITEL 3 FORMALES SYSTEMMODELL di di di Merge d d di ds 2 9 93 Abbildung 3 2 Verhalten von Merge Beispiel setzt Mit n Eingabekan len i1 in und m Ausgabekan len 01 Om eines Systems ergibt sich R formal als eine Relation vom Typ R C type i x type in
41. der Anwendung der Modifikationen M und Ma keine Auswirkung auf das Resultat hat und identisch ist mit dem System das durch die Kombination beider modifiziert wurde BAM AMa A Mi M2 AM2 AM Dies wird einfach gezeigt unter Ausnutzung der Annahmen die die quivalenzen Ph A 3 Ph und 6 APh amp OF implizieren AM AM2 A B V B A 33 V O4 P A PL A 87 Vv OL A 64 v OF A Bh A V BF V 04 Oa b Bh 04 A M M2 A M2 M ba O 83 04 h A 04 104 V 0 V Of 1 02 A OL v 6 A BL v bl A V 04 A Oh V Of PAM2 AM Die Forderung der Unabh ngigkeit 64 gt 6 und umgekehrt besagt durch Ausschlu des Falles A dass durch Abschw chung der Spezifikation durch eine der beiden Modifikationen ein neu gestattetes Verhalten nicht im Widerspruch zur Eigen schaft stehen darf die durch die jeweils andere Modifikation eingefordert wird Eine 4 5 EIGENSCHAFTEN VON MODIFIKATIONEN 105 neutrale Modifikation true false ist immer unabh ngig von einer beliebigen anderen Modifikation da false gt p und p gt true immer gelten Modifikationen von Transitionssystemen lassen sich kombinieren indem wir die Tran sitionen die mittels zweier Kombinationen hinzugef gt bzw entfernt werden auf einmal hinzuf gen bzw entfernen Wir verwenden wieder den Operator der damit berladen wird Definition 4 1
42. der Sicht der einzelnen Komponenten ist der Fehlerzustand unter Umst nden nicht erkennbar Im weiteren Ablauf des Systems k nnen die inkonsistenten Werte schlie lich zu Ausgaben des Systems f hren die es korrekterweise nicht h tte zeigen d rfen In diesem Beispiel hat der Designfehler zu einem Fehlzustand gef hrt der ein Versagen nach sich zog 2 1 2 Klassifikationen Die im vorigen Abschnitt beschriebenen Fehlerbegriffe sind sehr allgemein und ihre konkreten Auspr gungen in konkreten Systemen k nnen sehr verschiedenartige Eigen 14 KAPITEL 2 DER FEHLERBEGRIFF schaften aufweisen Wir werden in diesem Abschnitt die Fehlerursachen und Versagen klassifizieren um so das Spektrum dieser Begriffe aufzuzeigen und eine Strukturie rungsm glichkeit anzubieten Eine derartige Klassifizierung kann helfen einen vorliegenden Fehler und seine Eigen schaften genauer zu beschreiben und bestimmten Fehlerklassen geeignete Umgangsm g lichkeiten zuzuordnen Klassifikation von Fehlerursachen Eine Fehlerursache im Sinne von fault ist wie bereits beschrieben der Unterschied eines Systems von einer als korrekt definierten Fassung Dieser Unterschied kann ver schiedenste Charakteristika aufweisen von denen wir hier einige angeben wollen Ist eine Fehlerursache in einem System bekannt so sollte man in der Lage sein diese gem der folgenden Kriterien einordnen zu k nnen Die angegebene Klassifizierung fa t die Kriterien zusammen wie si
43. durch diese Transition konsumiert also in if aufgenommen und auch auf o ausgeben Die n chsten Zeilen stellen sicher dass keine Nachrichten von ia konsumiert werden die Umgebung aber im gleichen Schritt beliebige Nachrichten an Merge schicken darf Das Lesen einer Nachricht von i2 wird durch T2 analog definiert Transition 7 ist genau dann schaltbereit wenn eine Nachricht auf i vorliegt In den n chsten beiden Abschnitten werden wir kompaktere graphische und tabella rische Beschreibungstechniken f r Transitionen angeben bei denen auf die explizite Aufnahme von Aussagen ber unver nderte Werte oder die Handlungsfreiheit der Um gebung verzichtet werden kann Die Attraktivit t von Transitionsystemen liegt in ihrer abstrakten Formalisierung von Systemen bei gleichzeitiger Darstellung von operationellem Verhalten Um einem Sys tem ein Verhalten zuordnen zu k nnen definieren wir die Abl ufe eines Systems Definition 3 7 Ablauf Sei ein Transitionssystem S I O A Y T gegeben Ein Ablauf ist eine unendliche Sequenz von Zust nden des Systems f a B Y mit folgenden Eigenschaften e Das System startet in einem Initialzustand also EIET 52 KAPITEL 3 FORMALES SYSTEMMODELL e Die berg nge zwischen zwei in einem Ablauf aufeinanderfolgenden Zust nden sind zul ssige Transitionen VjeNe amp j amp G 1 e TUT e Sind in Zust nden mehrere Transitionen schaltbereit so geschieht ihre Auswah
44. ein Modul die geforderte Funktionalit t Versagt dieses Modul wird dies durch eine Fehler kennungskomponente an den Umschalter signalisiert der dann nicht mehr die Ausgaben des defekten ersten Moduls sondern des zweiten Moduls an die Umgebung weiterleitet Varianten und Verallgemeinerungen finden sich wieder in 66 Im Gegensatz zu Hardwarefehlern sind Softwarefehler in jedem Fall permanente Feh ler die im Design eines System lokalisiert sind Repliziert man Software so repliziert man auch unweigerlich die darin enthaltenen Fehler Techniken wir Triple Modular Redundancy oder Standby Spares sind bei Softwarefehlern demzufolge nicht sinnvoll einsetzbar Es gibt aber hnliche Techniken die auf Diversifikation von Software beru hen und von denen wir hier Recovery Blocks und N Versionen Programmierung kurz beschreiben Sie basieren auf der Grundidee verschiedene Versionen von Software zu verwenden Beide Techniken und ihr Vergleich sind ausf hrlich in 44 58 diskutiert Recovery Blocks Das Konzept der Recovery Blocks basiert auf verschiedenen Ver sionen von Software und einem sogenannten Akzeptanztest Dieser Test muss in der Lage sein die Ausgabe einer Komponente auf ihre Korrektheit oder Plausibilit t zu berpr fen Wird das Ergebnis eines Ablaufs f r ung ltig erkl rt so wird es verworfen das System in einen Startzustand zur ckgesetzt also ein recovery durchgef hrt und eine alternative Version gestartet Dieser Vorgang l
45. ein System in einer Art und Weise zu modifizieren dass es auch in einer fehlerhaften Umgebung noch weitgehend sinn voll d h auf definierbare Weise reagiert Wir wollen also die Robustheit eines Systems erh hen Wir werden im folgenden diskutieren wie Entwicklungsschritte zur Erh hung der Ro bustheit formal in unserem Systemmodell dargestellt werden k nnen Dazu unterschei den wir wie in Kapitel amp 6 nach expliziten und impliziten Umgebungsannahmen 5 6 1 Explizite Umgebungsannahmen Sind die Annahmen an eine Systemumgebung explizit formuliert so k nnen sie durch ein Pr dikat A mit freien Variablen aus dargestellt werden Das Verhalten der Komponente selbst wird im Rahmen von A G Spezifikationen dann durch ein Pr dikat G repr sentiert Fehler in der Umgebung f hren in diesem Kontext zu Eingabestr men die die An nahme A nicht erf llen Typischerweise interessiert man sich nicht f r alle denkbaren Fehler die sich durch eine Negation von A charakterisieren lie en sondern nur f r eine gewisse Teilmenge dieser f r die die Systemrobustheit erh ht werden soll Wir k nnen diese gew hlte Teilmenge der externen Fehler mit Hilfe einer Abschw chung A der Umgebungsannahme formulieren f r die also A gt A gilt Das Verhalten des Systems wollen wir nun ver ndern zu G so dass es auch bei Ein gaben die zwar A aber nicht mehr A erf llen ein definiertes Verhalten zeigt Wel ches konkrete Verhalten ein Ent
46. ein System zu einem fehlerhaften macht Ein Fehler muss nicht unbedingt einfach zu lokalisieren sein wie zum Beispiel ein Tipp fehler ein falsches Datum oder ein verfehlter Prozeduraufruf in einem Programmcode Ein Entwurfsfehler inkompatible Schnittstellen oder inkonsistente Eigenschaften eines Systems k nnen zu einer informellen Bewertung wie Das System hat einen Fehler f hren ohne dass man auf den Fehler unmittelbar zeigen kann 2 Der Begriff der Modifikation wurde unter anderem dadurch motiviert derartige Abwei chungen zu repr sentieren Wir definieren Fehler daher direkt als Modifikationen Definition 4 7 Fehler Ein Fehler eines fehlerbehafteten Systems SAM bez glich einer als korrekt definierten Spezifikation S wird beschrieben durch die Modifikation M Diese Definition charakterisiert den Fehler eines Systems SAM also f r ein System das den Fehler bereits explizit in seiner Beschreibung enth lt F r ein fehlerbehaftetes System S das relativ zu einer Spezifikation S einen Fehler aufweist muss dieser Fehler erst gefunden werden Der Fehler in ist dann das nicht notwendigerweise eindeutige M f r das S SAM gilt Die Beschreibungstechnik spielt in Definition MIZ keine Rolle Fehler k nnen also insbesondere mit Black Box Spezifikationen Transitionssystemen und Modifikations komponenten beschrieben werden Es sei bemerkt dass wir nicht unterscheiden zwi schen einem und mehrer
47. einer Nachricht nicht vor dem Senden einer Nachricht geschieht Da wir verteilte Systeme modellieren wollen in denen die Nachrichten bermitt lung unterbrochen oder verz gert sein kann und da wir keine Annahmen ber die bertragungszeiten machen wollen ist die Wahl des asynchronen Modells angemessen Focus bietet alle Varianten von Systemmodellen an Im gezeiteten Modell wird Zeit durch spezielle Nachrichten modelliert die den Fortschritt der Zeit repr sentieren Im taktsynchronen Modell wird auf allen Kan len jeweils gleichzeitig genau eine Nach richt gelesen und geschrieben Ist eine Komponente nicht bereit eine Nachricht zu lesen so mu die Nachricht explizit gepuffert werden In PI werden die alternativen Modelle die Focus bietet vorgestellt Im n chsten Kapitel werden wir das Systemmodell so erweitern dass damit die Fehler eines Systems modelliert werden k nnen 74 KAPITEL 3 FORMALES SYSTEMMODELL Kapitel 4 Formale Modellierung von Fehlern Nachdem im vorangegangenen Kapitel das Systemmodell vorgestellt wurde wollen wir dieses nun um neue Begriffe erweitern die es uns erm glichen mit Fehlern von Syste men explizit umzugehen Selbstverst ndlich sind auch Fehler nur ein Teil von Systemen und ihrem Verhalten und k nnten aufgrund der Allgemeinheit und Ausdruckskraft des Systemmodells auch ohne die folgenden Begriffe modelliert werden Allerdings verhel fen vorbereitete Begriffsbildungen zu einem besser
48. gbar w re Andererseits darf das Pr dikat nicht zu stark sein um nicht zu viele weitere Knoten zu generieren Es sollte eine geeignete Abstraktion des Ausnahmezustandes beschrei ben Wird beispielsweise eine Variable x die immer nicht negativ sein sollte durch einen Fehler dekrementiert obwohl sie schon den Wert 0 hat so kann es g nstiger sein diesen Fall als x lt 0 zu beschreiben und nicht etwas als x 1 Bei einer weiteren Dekrementierung durch die Fehlertransition bleibt dieser Zustand erhalten und es wer den nicht weitere generiert mit x 2 x 3 und so weiter Die geeignete Wahl der Pr dikate kann nur mit Kreativit t Intuition und einem Verst ndnis der Funkti onsweise des Systems geschehen wie dies schon f r die Erstellung des urspr nglichen Beweisdiagramms n tig war Werden mit einer Modifikation sowohl Transitionen erg nzt als auch entfernt empfiehlt es sich bei der Anpassung eines Beweisdiagramms in folgender Reihenfolge vorzugehen 1 Zun chst werden m glichst viele Kanten und Knoten aus dem Diagramm entfernt 5 7 WIEDERVERWENDUNG VON BEWEISEN 147 7 o 10 io s 0 el 9 c 1 c Abbildung 5 8 Modifiziertes Invariantendiagramm fiir Merge Die Pr dikate in den verbleibenden Knoten werden maximal verst rkt 2 Erst dann werden die neuen Transitionen zusammen mit den notwendigen neuen Knoten hinzugef gt Auf diese Weise wird eine unn tig
49. hohe Anzahl von Knoten Kanten und Beweisver pflichtungen vermieden Im folgenden Beispiel veranschaulichen wir die Auswirkung von Modifikationen auf ein Beweisdiagramm Beispiel 5 8 Anpassung des Invariantendiagramms von Merge In Beispiel BITTJhaben wir mit Hilfe des Invariantendiagramms in Abbildung B 7 gezeigt dass Fo HE Hi eine Invariante des Systems Merge aus Beispiel BJ6 ist Wir wollen dieses Beweisdiagramm nun an die in Beispiel MiB definierte Modifikation M FE U E2 F anpassen Die Entfernung der Transitionen aus E U Ey f hrt zu einer Verst rkung der Vor und Nach bedingungen von r und 72 Wir nennen die ver nderten Transitionen ry und 7 die wir in Beispiel bereits definiert haben als Name Pre Input Output Post T c 1 i a ola d c Ty c 2 i a ola d c Das BeweisdiagrammB 7 bleibt mit diesen Transitionen g ltig Wir k nnen die Pr dikate aber nun verst rken Die Transition r stellt sicher dass nach ihrer Ausf hrung c 1 gilt Da der linke mittlere Knoten nur mit Hilfe dieser Transition erreicht werden kann k nnen wir diese Eigenschaft dem Pr dikat erg nzen Analog kann c 2 dem rechten mittleren Knoten hinzugef gt werden Mit c 1 im linken Knoten ist es offensichtlich dass Transition 73 in diesem Zustand nicht mehr schaltbereit ist da c 2 in der Vorbedingung enthalten ist Diese Kante kann also entfernt werden Entsprechend wird die Kante vom rechten Knoten zum unteren Knoten gel scht
50. ist Definition 3 15 Schnittstellenverfeinerung Seien zwei Systeme S und Sy mit den Schnittstellen I O bzw T O gegeben und zwei Stromrelationen R und Ra mit den Schnittstellen I I und O O Das System S ist eine Schnittstellenverfeinerung von S bez glich R Ra notiert durch 91 on S2 wenn gilt Vi o o i 0 Een gt Ji 0 i 7 E Ry X 4 0 Sy A 0 0 Ro Die Schnittstellenverfeinerung ist eine Verallgemeinerung der Verhaltensverfeinerung Mit R und Ra als Identit tsrelation fallen die beiden Verfeinerungsbegriffe zusam men Die beiden Abstraktions bzw Repr sentationsrelationen k nnen wie gew hnli che Systeme mit den bereits vorgestellten Beschreibungstechniken spezifiziert werden 3 10 ENTWICKLUNGSPROZESS 69 In 5 rA BI sind Varianten obiger Definitionen angegeben und Kriterien die die Kompositionalit t sicherstellen sowie F lle von Verfeinerungen ausschlie en die aus praktischer Sicht nicht sinnvoll sind Auf eine Darstellung der noch allgemeineren bedingten Verfeinerung verzichten wir da sie in dieser Arbeit keine Rolle spielen wird Mit ihr ist es m glich zus tzliche Be dingungen an die Eingaben des Systems zu formulieren unter denen eine Verfeinerung vorliegt Eine detaillierte Diskussion findet sich wieder in PT 3 9 3 Kompositionalitat Eine wichtige Eigenschaft der Verfeinerungsbegriffe im Rahmen einer methodischen Systementw
51. noch andere Transitionen schaltbereit k nnen auch die se gew hlt werden Nur bei permanenten Fehlern wird r aufgrund der Fairness im Ausf hrungsmodell irgendwann einmal ausgef hrt Bei transienten Fehlern also nur vor bergehender G ltigkeit des fehlererkennenden Zustandspr dikates Y kann es pas sieren dass eine Fehlernachricht nie gesendet wird Ferner ist es m glich dass eine Fehlermeldung mehrfach ausgegeben wird Wir wollen nun zwei verfeinerte Modellie rungen f r sofortiges Senden und f r einmaliges Senden einer Fehlermeldung angeben Unmittelbare Fehlermeldung Eine Fehlermeldung wird sofort ausgegeben wenn wir die Schaltbereitschaft anderer Transitionen bei erkanntem Fehler aufheben Dies geschieht durch Entfernen von E a p a Y Damit beschreibt M rf E U E die Modifikation die ein System bei erkanntem Fehler sofort eine Fehlermeldung ausgeben l t Einmalige Fehlermeldung Soll eine Fehlermeldung nur einmal gesendet werden so darf r nur dann schaltbereit sein wenn der Fehler noch nicht gemeldet wurde Dazu w hlen wir eine neue boolesche Variable sent die mit false initialisiert wird und verm ge Ey a a sent B sent a 3 a U A bY A B sent von keiner anderen Transition ver ndert wird Nur wenn ein Fehlerzustand nicht mehr vorliegt was am bergang von W zu false erkennbar ist soll der Wert von sent wieder auf den Initialwert gesetzt werden Mit TF als Name Pre Input Outpu
52. nur einmal geschickt wird Damit die Fehlermeldung unmittelbar erfolgt verst rken wir auf schematische Weise entspre chend E die Vorbedingungen der Transitionen Insgesamt wird der Puffer der die Fehler er kennt und darauf sofort mit einer Fehlermeldung sowie einer einfachen Fehlerkorrektur reagiert folgenderma en spezifiziert Name Pre Input Output Post Ti 4 lt N A q z i d d qyr d Az z 1 T2 q4 gt 0A q z iR o ft q q rtq Nz z 1 T3 q gt 0A q z q rtq nz z Tf q 2 _ o fail gd qh2z In einer Realisierung des Puffers wird die Fehlertransition 73 nat rlich nicht realisiert sie re pr sentiert nur das ungewollte jedoch als unvermeidbar eingesch tzte Fehlerverhalten 5 5 Fehlerkorrektur Die fr hzeitige Ber cksichtigung und Modellierung von Fehlern bereits w hrend der Entwicklungszeit erm glicht es Ma nahmen und Techniken zur Fehlerkorrektur in ein System zu integrieren die w hrend der Laufzeit des Systems die Auswirkungen der Feh ler verbergen oder zumindest eind mmen Wir geben hier zwei Techniken an die sich zur Fehlerkorrektur im Rahmen unseres Systemmodells eignen Die Erg nzung einer korrigierenden Transitionsmenge und die Verwendung von korrigierenden Treiberkom ponenten 5 5 FEHLERKORREKTUR 133 AW i er m a b c Abbildung 5 4 Varianten korrigierender Transitionen 5 5 1 Erg nzung von korrigierenden Transitionen Ist ein Fehler erkannt
53. physikalische oder effizienz bedingte Notwendigkeiten sein und ebenso ein Mittel die Komplexit t eines Systems durch eine Aufteilung in berschaubarere Teile handhabbar zu machen Beispielsweise muss ein internationales Buchungssystem auf viele physikalische Standorte verteilt sein und wird sinnvollerweise in logische Anwendungsmodule strukturiert Die verteilten reaktiven Systeme stellen also eine Systemklasse dar die in der Praxis eine relevante Rolle spielt Die Entwicklung dieser Systeme stellt durch ihre inh rente Komplexit t eine gro e Herausforderung dar so dass eine formale Unterst tzung not wendig oder zumindest lohnenswert ist Das in Kapitel B vorgestellte Systemmodell ist f r diese Klasse hervorragend geeignet Fehler Fehler spielen in sehr vielf ltiger Weise eine Rolle im Umfeld informationstech nischer Systeme Sie k nnen in Erwartungen Spezifikationen Programmen Teilkompo nenten lokal oder verteilt in Hard oder Software oder auch in Abl ufen auftreten Sie sind unter Umst nden nicht exakt lokalisierbar und nicht quantifizierbar Sie k nnen einen statischen oder dynamischen Charakter haben Mit Fehlern kann auf verschiedens te Weise umgegangen werden So k nnen sie vermieden ignoriert erkannt behandelt gesucht entfernt gemeldet und toleriert werden Die vielf ltigen Interpretationen des Fehlerbegriffes haben jedoch eine Gemeinsamkeit Ein Fehler ist immer nur relativ zu einer definierten Korrektheit
54. sehr einfach modellierbar W hrend F die Transitionen enth lt die den R cksprung beschreiben wird durch E das Sys tem daran gehindert bei einem entdeckten Fehler unbeeinflu t seine normale Aktivit t fortzusetzen F a 8 aE VABEYT E a 8 aE Y Das System SAM mit M E F spezifiziert damit ein System das sich von S darin unterscheidet dass es bei entdecktem durch Y beschriebenem Fehler neu startet 5 5 FEHLERKORREKTUR 135 Erg nzen einer Ausnahmebehandlung AbbildungB Ac illustriert den allgemein sten Fall einer Fehlerbehandlung Nach der Entdeckung eines Fehlers wird eine Fehler behandlung gestartet die als eigenes Transitionssystem spezifiziert ist Ist die Fehler behandlung abgeschlossen erfolgt ein R cksprung in das urspr ngliche System Diese Reaktion entspricht einer Ausnahmebehandlung wie man sie aus Programmiersprachen als exceptions kennt Wir beschreiben eine Ausnahmebehandlung mit Hilfe einer Transitionsmenge C und zwei Zustandspr dikaten Entry und Exit Das Pr dikat Entry beschreibt die zu er f llende Startbedingung der Ausnahmebehandlung und umfa t eine Auszeichnung des Kontrollzustandes in dem das System gestartet wird wie auch die Initialisierung von lokalen Variablen Exit charakterisiert die Zust nde von denen aus der R cksprung in das Normalsystem erfolgen darf Wir zeichnen eine bislang noch nicht im System verwendete Variable xp aus mit der es m glich ist die Normaltransition
55. sentiert Zur besseren Unterscheidung haben wir hier neue Namen f r die Komponen ten und ihre Modifikationen eingef hrt Damit sind M und M korrespondierende Modifikationen bez glich Merge und Merge 4 6 Fehler in der Systemumgebung Mit dieser Arbeit wollen wir wie bereits in Kapitel motiviert Methoden daf r anbie ten wie Systeme schrittweise entwickelt werden k nnen ausgehend von einer Idealisie rung des Systems bis zu einer realen Implementierung also auch unter Ber cksichtigung 4 6 FEHLER IN DER SYSTEMUMGEBUNG 113 m glicher zu erwartender Fehler Mit den in diesem Kapitel bisher vorgestellten Begrif fen k nnen wir Modifikationen an der Schnittstelle und dem Verhalten von Systemen durchf hren Unber cksichtigt blieb dabei bislang die Umgebung der Systeme Fehler k nnen auch in der Systemumgebung auftreten Zu viele oder zu wenige zu schnelle oder zu langsame bzw inkonsistente Eingaben sind Beispiele die es einem System unm glich machen k nnen seine Funktionalit t zu erbringen Derartige F lle lassen sich nicht durch eine Modifikation der Schnittstelle oder des Systemverhaltens darstellen Aufgrund der Linkstotalit t der Verhaltensrelationen scheint ein Begriff des externen Fehlers nicht sinnvoll zu sein F r jede Eingabe an ein System muss eine Ausgabe definiert sein Die Umgebung kann also keine irgendwie gearteten falschen Nachrichten str me an ein System schicken Bei Black Box Sp
56. tze ist es also m glich Fehler in den Anforderungen an ein System zu formulieren Dies scheint aber unvermeidbar da man f r eine formale Untersuchung mit der damit erwarteten Pr zision eine fixierte Grundlage haben muss so wie jeder Kalk l von akzeptierten Axiomen und Schlussregeln ausgehen muss Da alle genannten Ans tze Fehler durch Transitionen beschreiben die dem System hin zugef gt werden bleibt das urspr ngliche fehlerfreie Verhalten immer als eine Verhal tensvariante m glich Die Fehlertransitionen erweitern die M glichkeiten durch Erg nz ung nichtdeterministisch ausw hlbarer Alternativen aber sie schr nken das Verhalten nie ein Diese Ans tze eignen sich also eher zur Modellierung tempor rer physikalischer Fehler die w hrend der Laufzeit auftreten und weniger f r permanente Softwarefehler bei denen beispielsweise eine Rechnung in jedem Ablauf falsch durchgef hrt wird Die vorgestellten Modelle sind geschlossene Systeme und unterscheiden nicht zwischen einem Innen und einem Au en eines Systems Demzufolge ist es auch nicht m glich zwischen internen und externen Fehlern eines Systems zu unterscheiden entsprechend der Lokalisierung von Fehlern aus Abschnitt 2 1 2 Ferner werden die Zusammenh nge von Fehlern in Komponenten und ihre Auswirkungen auf das Gesamtsystem nicht oder nur oberfl chlich untersucht Alle formalen Modelle dienen vorwiegend einer grundlegenden Modellierung von Feh lern und Fehlertoleranz i
57. ver ndert so ndern sich auch seine Eigenschaften Eine wesentli che Voraussetzung f r den Umgang mit Modifikationen von bestehenden verifizierten Systemen ist also eine Vorgehensweise mit der auch die entsprechenden Beweise an gepasst werden k nnen Dazu haben wir Techniken vorgestellt wie durch Diagramme repr sentierte Beweise an Modifikationen von Transitionssystemen und entsprechenden Modifikationen ihrer Eigenschaften angepasst werden k nnen Mit den Ergebnissen aus 4 5 2 k nnen damit Zusammenh nge von Modifikationen im gesamten Entwicklungs baum entsprechend Abbildung B II hergestellt werden Die in diesem Kapitel vorgestellten methodischen Hinweise sind gr tenteils abstrakt formuliert um m glichst unabh ngig von konkreten Beschreibungstechniken die eigent lichen zugrundeliegenden Anforderungen auszudr cken Beispielsweise sind die Krite rien eines fehlererkennenden Pr dikates ber Ausf hrungen und die darin enthaltenen Zust nde formuliert Es ist w nschenswert auch f r ein konkretes System das beispiels weise durch Programmcode beschrieben ist angepa te Beschreibungstechniken zu fin den und die in diesem Kapitel definierten Kriterien entsprechend umzusetzen Manche Modifikationen lassen sich in konkreten Programmiersprachen sogar trivial umsetzen W hrend beispielsweise nach Einf hrung einer neuen Variable unter Umst nden alle 5 8 ZUSAMMENFASSUNG UND DISKUSSION 155 Transitionen entfernt werden m ssen
58. verwendet werden DO d z Da wir Eigenschaften mit Hilfe von Formeln definieren wollen bedarf es entsprechender Begriffe die wie blich charakterisiert werden Definition 3 2 Variable Belegungen Formeln Die Menge VAR bezeichnet die Menge aller Variablen Jeder Variable v VAR ist ein Typ zugewiesen Ein Typ ist eine Menge von Werten die eine Variable annehmen kann Eine Belegung a weist jeder Variablen v einen Wert a v ihres Typs zu Die Menge aller Belegungen wird durch VAL bezeichnet Zwei Belegungen stimmen auf einer Variablenmenge V berein wenn sie allen Varia blen aus V jeweils den gleichen Wert zuweisen a p Yve V e a v b v Zu zwei Belegungen bezeichnet Agree a 3 f r agreement die maximale Menge von Variablen auf denen die Belegungen a und D bereinstimmen Agree a 3 C VAR mit a Agree 3 B AM yV C VAR ea v B gt V Agree a 3 Eine Formel ist ein wohlgeformter Ausdruck der sich mit einer Belegung a zur Interpretation der freien Variablen zu einem booleschen Wahrheitswert aus true false 40 KAPITEL 3 FORMALES SYSTEMMODELL auswerten l t Wird unter amp zu true ausgewertet notieren wir dies als ake F r eine Variablenmenge V bezeichnet V die zu V disjunkte Variablenmenge die alle Variable aus V mit einem Strich versieht also Vi v veEV Dabei stellen v und v verschiedene Variablen dar F r eine Belegung a kann eine Bel
59. wir dann die bersetzung Fehlerursache verwenden wenn der Unterschied zu den bei den anderen Bedeutungen betont werden soll ansonsten vereinfacht Fehler Wir beschreiben die drei Begriffe und ihre Zusammenh nge zun chst nur informell wie sie in oben genannter Literatur dargestellt werden und geben eine Klassifizierung an die die verschiedenen Aspekte der Begriffe beleuchtet Wir werden dann in Abschnitt B T 3lauf der Basis eines einfachen aber allgemeinen Systemmodells die Fehlerbegriffe konkreter als Abweichungen eines Jst von einem Soll bez glich verschiedener Aspekte eines Systems charakterisieren und systematisch darstellen Eine entsprechende formale Definition dieser Begriffe werden wir schlie lich in Kapitel 1 3 vorstellen Failure Ein System Versagen engl failure liegt vor wenn das Verhalten eines Systems nicht das Verhalten ist das in der Spezifikation des Systems gefordert wird Ein Versagen kann demnach nur w hrend des Betriebes eines Systems auftreten oder beim Versuch seiner Inbetriebnahme und auch nur dann festgestellt werden Die potentielle An bzw Abwesenheit von Versagen macht letztendlich die Korrektheit eines Systems aus Kann man die Abwesenheit von Ausf llen in allen Systemabl ufen garantieren so sind das System und all seine Komponenten vollst ndig korrekt oder auftretende lokale Fehler beliebiger Auspr gung k nnen auf maskierende Weise toleriert werden Der Begriff des Versagens eignet sich
60. wir dazu die Kombi nationen von Modifikationen 4 4 2 Fehlertoleranz als D mpfung quantitativ Wird ein System dem Einflu von Fehlern ausgesetzt so hat dies im allgemeinen Aus wirkungen auf das Systemverhalten Bei einem System das Fehler nicht tolerieren kann werden sich die Fehler auf sch dliche Weise auf das Verhalten auswirken Ist das System dagegen fehlertolerant werden die Auswirkungen abgeschw cht und im Idealfall sogar vollkommen maskiert 4 4 FEHLERTOLERANZ 101 Die Fehler denen ein System S ausgesetzt sein kann k nnen sowohl innerhalb des Sys tems in einer Teilkomponente als auch au erhalb in der Systemumgebung lokalisiert sein Wir gehen im folgenden von einem zusammengesetzten System S S1 S2 aus und betrachten einen Fehler in S1 Dabei kann S sowohl die Teilkomponente von S als auch die Umgebung von Sa repr sentieren Mit unserem Formalismus k nnen wir diesen Fehler durch eine Modifikation Mj explizit angeben Die durch diesen Fehler bewirkte Abweichung des Systemverhaltens kann durch eine Modifikation M von S formalisiert werden In Abschnitt 5 2 werden wir Techniken kennen lernen mit denen M aus M ermittelt werden kann Es gilt dann SAM S1AM 8 5 Der Grad der Fehlertoleranz l t sich quantifizieren wenn ein Ma f r den Schweregrad von Modifikationen definiert werden kann Sei d eine Funktion die einer Modifikation eine entsprechende Ma zahl zuordnet Das System kann dann als fe
61. zwei Varianten vor die sich an der Beschreibung der Umgebungsan nahme orientieren e Ist eine Umgebungsannahme durch eine Black Box Spezifikation A beschrieben so steht uns mit den Modifikationen bereits ein Formalismus bereit mit dem Abschw chungen beschrieben werden k nnen Beschr nken wir uns also auf eine Modifikation M true so kann damit ein Umgebungsfehler spezifiziert werden Ist die Annahme an die Umgebung durch eine Umgebungskomponente A definiert so k nnen wir diese durch eine Modifikation f r Transitionssysteme M4 F spezifizieren die der Umgebung damit zus tzliche Freiheiten in ihrem Verhalten zugesteht Im allgemeinen Fall h tte diese Formel die Form A i1 in 01 3 Om 4 6 FEHLER IN DER SYSTEMUMGEBUNG 115 Wir haben uns in beiden F llen beschr nkt auf eine reine Abschw chung des Systemver haltens lassen also weder eine Verst rkung noch das Entfernen von Transitionen in A ber ein nichtleeres E zu Wir interessieren uns im Rahmen unseres idealen Entwick lungsprozesses f r die Verbesserung von Systemen was im Kontext von Umgebungs fehlern eine Erh hung der Robustheit bedeutet Ein System soll also trotz auftretender Umgebungsfehler sinnvolles Verhalten aufweisen Im Kapitel 6 werden wir die Anpas sung von Systemen an Umgebungsfehler diskutieren Selbstverst ndlich kann es m glich sein auch die Annahmen an das Umgebungsverhal ten verst rken zu wollen Werden im Rahmen e
62. 2 Kombination von Modifikationen von Transitionssystemen Die Kombination zweier Modifikationen M und Ma eines Transitionssystems wird definiert durch d E1 Fi E2 Fo af 1 U Eo F1 U F3 Eine Unabh ngigkeit von Modifikationen liegt dann vor wenn vermieden wird dass eine Modifikation Transitionen erg nzt die von der anderen entfernt werden Es gilt dann die folgende Eigenschaft Proposition 4 6 Unabh ngigkeit von Modifikationen von Transitionssystemen Der Operator f r Modifikationen von Transitionssystemen ist assoziativ und kommu tativ wie sich unmittelbar aus der Assoziativit t und Kommutativit t der Mengenver einigung U ergibt Unter der Voraussetzung EnR 8 1 ENF O f r Modifikationen M E1 Fi und Ma Eo F2 gilt SAM AMa SA M M2 SAM2 AM Die Voraussetzung stellt sicher dass Fy N Ey Fy Ey so dass mit T als Transitionsmenge von S die Behauptung bewiesen wird durch TAM AM2 T E UH T Fi Fo U Fi Fh U F2 T Z1 U E2 U F1 U Fo TA M Ma TA M 2 M T 2 U F U F2 U Fi T E2 Z1 U F2 Z1 U Fa T 2 U F2 Z1 U Fi TAM2 A M Eo U Fo C C Wir illustrieren die Notwendigkeit der Unabh ngigkeitsforderung an folgendem Beispiel 106 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Beispiel 4 9 Kombination von Modifikationen von Transitionssystemen Wir betrachten die Kompone
63. 6 2 Tabellarische Darstellung Werden Systeme sehr gro und besitzen sie sehr viele Kontrollzust nde kann die gra phische Darstellung in Diagrammen sehr untibersichtlich werden In solchen Fallen kann eine tabellarische Darstellung besser geeignet sein Die Transitionen werden nach dem gleichen Muster wie bei der graphischen Darstellung der Transitionssysteme notiert Kontrollzust nde m ssen aber explizit aufgenommen werden als eine Datenvariable zum Beispiel die als Werte die Namen der Kon trollzust nde annehmen kann Ihre berg nge m ssen explizit angegeben werden Die tabellarische Darstellung wird auf analoge Weise in die formale Darstellung bersetzt wie dies bereits bei der graphischen Darstellung m glich ist Es sind auch Mischformen beider Darstellungen gebr uchlich Dabei werden in der graphischen Darstellung die Transitionen nur mit ihrem Namen beschriftet und die vier Bestandteile in einer Tabelle angegeben Damit kann die Lesbarkeit gro er Diagramme erh ht werden bei Erhalt einer intuitiven Darstellung des Kontrollflusses Beispiel 3 7 Wir stellen die Transitionen von Merge als Tabelle auf offensichtliche Weise folgendermassen dar Name Pre Input Output Post 71 i d old T2 ig d old In Kapitel 4 werden wir weitere Beispiele der Verwendung von Tabellen zur Beschrei bung von Fehlern prasentieren 3 7 KOMPOSITION 55 3 7 Komposition Komplexere Systeme werden typischerweise aus
64. 8 34 gezeigt Die Knoten stellen wir durch Ovale dar die mit dem Namen von Kontrollzust nden beschriftet werden Der oder die Startknoten werden mit einem schwarzen Kreis mar kiert Die Beschriftung der Transitionskanten besteht aus vier Bestandteilen und hat die Form Pre Inputs gt Outputs Post Das Eingabemuster Inputs besteht aus einer Liste von Ausdr cken der Gestalt i d mit 7 I und d als transitionslokaler Variable oder Konstante vom Typ type i Eine Transition kann nur schalten wenn die aktuellen Eingaben zu diesem Eingabemuster passen also auf den entsprechenden Eingabekan len tats chlich Nachrichten vorliegen und diese entweder identisch sind mit der Konstante oder die f r eine sp tere Bezug nahme der transitionslokalen Variablen zugewiesen werden Eine weitere Bedingung an die Schaltbereitschaft ist die G ltigkeit des Pr dikates Pre welches Datenvariablen und auch die transitionslokalen Variablen in free Pre enthalten darf In Pre k nnen also weitere Vorbedingungen formuliert werden Wird eine Transition ausgef hrt so produziert sie Ausgaben entsprechend der Liste Outputs von Ausdr cken der Form olexp mit o als Name eines Ausgabekanals o O und exp als Ausdruck fiir den Wert der auf diesem Kanal gesendet wird In Post wird die Nachbedingung formuliert die ty pischerweise den Datenvariablen neue Werte zuweist und die daher die Variablen des Systems auch in gestrichener Form enthalten darf Po
65. Abh ngigkeit von i ausgedr ckt Da gem der informellen Spezifikation die Daten auf o genau die empfangenen Daten von i sind wobei auch die Reihenfolge der Daten erhalten bleibt fordern wir of DOi Diese Sicherheitseigenschaft l t es zu dass ein System berhaupt keine Ausgaben macht Wenn es aber Ausgaben macht dann sind es die richtigen Wir ben tigen zus tzlich noch eine Leben digkeitsaussage die fordert dass Ausgaben tats chlich gemacht werden Dies k nnen wir ber die L nge des Stromes o formulieren F r jede Anfrage wird genau ein Datum auf o ausgegeben 0 Ri Beide Aussagen k nnen wir nun zusammenfassen zur A G Spezifikation A G des Puffers mit A X vi Cie0 lt DOi R O i lt N G oC D i 1 0 RBi Das Format von A G Spezifikationen schr nkt das Verhalten nur ein f r den Fall dass die Annahme A erf llt ist Gilt die Annahme f r einen Eingabestrom i nicht so ist auch das resul tierende Verhalten des Puffers nicht spezifiziert In Abschnitt B 6 werden wir den Puffer weiter entwickeln so dass auch diese F lle ber cksichtigt werden und der Puffer dann ein definiertes und sinnvolles Verhalten zeigt Allgemeine Assumption Guarantee Spezifikationen Im allgemeinen sind die einfachen A G Spezifikationen nicht ausdrucksstark genug Es ist m glich dass eine Bedingung an die Umgebung nicht mit einem Pr dikat definiert werden kann das nur auf die Eingabekan le Bezug nimmt
66. Box Charakterisierung von Versagen Ist ein System S und seine Modifikation durch eine Black Box Spezifikation und M 5 r beschrieben so gilt FAILURES S M i 0 r An Die Abschw chung z hat demzufolge keinen Einflu auf die Menge der Versagen eines Systems Da p nur zus tzliche Eigenschaften beschreibt die das modifizierte System zu erf llen hat k nnen dadurch nat rlich keine Abweichungen vom normalen System verhalten bewirkt werden Nur p gibt dem System neue Freiheiten die zu sichtbaren Abweichungen f hren k nnen In vielen formalen Ans tzen zur Fehlermodellierung wird daher auf die Modellierung von Eigenschaftsverst rkungen daher auch verzichtet Unser Begriff der Modifikationen ist somit allgemeiner Auf eine Unterscheidung der Begriffe Ausfall und Versagen wie sie auch in Kapitel B angesprochen wird haben wir verzichtet da dies in unserem Kontext nicht sinnvoll erscheint Das Ziel der Arbeit ist es die Beschreibung von Systemen und ihren Modifika tionen zu erm glichen Ob der Ausfall physikalischer Natur ist oder nicht spielt hierbei keine prinzipielle Rolle solange wir in der Lage sind die Auswirkungen zu modellieren Beispiel 4 7 Um den Unterschied zwischen einem Fehlzustand und einem Versagen veran schaulichen zu k nnen definieren wir einen Z hler der einen internen Zustand besitzt Der Z hler habe zwei Eingabekan le Auf i empf ngt er zu z hlende Daten vom Typ D U
67. DELL Temporal Logic of Actions UNITY oder Proze algebren Wir haben uns f r Focus entschieden da es folgende Vorteile in sich vereint die in dieser Kombination alternative Systemmodelle nicht aufweisen e Focus bietet ein einheitliches semantisches Grundmodell auf das die verschie densten Sichten eines Systems fundiert werden k nnen Von monolithischen ab strakten eigenschaftsorientierten Black Box Spezifikationen bis hin zu ablaufori entierten implementierungsnahen Beschreibungen von Netzwerken interagieren der Komponenten k nnen Systeme auf allen Abstraktionsstufen spezifiziert wer den Alle Beschreibungen k nnen mit Hilfe der Fundierung auf das Strommodell zueinander in Beziehung gesetzt werden Dies erm glicht eine durchg ngige Sys tementwicklung ohne Wechsel des semantischen Modells e Der Schnittstellenbegriff erm glicht eine deutliche Trennung zwischen dem Sys tem und seiner Umgebung und zwischen den verschiedenen Komponenten eines zusammengesetzten Systems Die Interaktion zwischen den Systemteilen ist so klar definiert unerw nschte Seiteneffekte sind bereits durch Anforderungen des Systemmodells ausgeschlossen e Eine Konsequenz des Schnittstellenbegriffs liegt in der Kompositionalit t des Mo dells Damit ist eine modulare Systementwicklung m glich Die Komponenten ei nes Systems k nnen demzufolge weitgehend unabh ngig voneinander entwickelt werden da dies automatisch einer Weiterentwicklung des Gesamtsyste
68. Da der untere Knoten nun nicht mehr erreichbar ist wird auch er entfernt Es verbleibt das in Abbildung B 8 dargestellte Beweisdiagramm Wir m ssen nun die Auswirkung der neuen Transitionen aus F ber cksichtigen Dazu erg nzen wir zu jedem Knoten die beiden Transitionen 148 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN j imma cee ji CE Ep c 1 os Abbildung 5 9 Vollst ndig modifiziertes Invariantendiagramm fiir Merge Name Pre Input Output Post T3 cAlAc 2 c 1 T4 cl c 2 c 2 und pr fen in welche Knoten deren Ausf hrung f hrt Da beide nur auf den Wert von c Einflu haben das im Pr dikat des oberen Knoten nicht auftritt erhalten diese Transitionen offensicht lich die G ltigkeit des Pr dikates und k nnen als Schleife eingetragen werden In den beiden unteren Knoten sind 73 und 74 nicht schaltbereit und m ssen daher auch nicht erg nzt werden Als Ergebnis erhalten wir das Beweisdiagramm in Abbildung 5 9 Da keine neuen Knoten hin zugef gt werden mu ten beweist das angepa te Diagramm noch immer die Invariante Da ein Knoten entfernt wurde geht das ihm zugeordnete Pr dikat nicht mehr in die Disjunktion ein so dass mit dem Diagramm sogar MergeAM IH 0 i io A Hie 0V R 0 gezeigt wird Das Beispiel verdeutlicht wie das Beweisdiagramm des modifizierten Systems einen nicht unerheblichen Teil des urspr nglichen Beweisdiagramms wiederverwendet
69. Die Kommunikation zwischen den Komponenten findet ausschlie lich ber den Austausch von Nachrichten ber die Kan le statt F r Systeme ihre Schnittstellen ihr Verhalten und ihre Komposition sind Beschrei bungstechniken anzubieten mit denen konkrete Instanzen beschrieben werden k nnen Wir geben hierf r verschiedene Techniken an Wir werden in der gesamten Arbeit die Begriffe Systeme und Komponenten synonym verwenden da es zwischen beiden Begriffen keinen prinzipiellen Unterschied gibt Ein System kann als Komponente Teil eines umfassenden Systems sein und eine Kompo nente ist selbst wieder ein System Die Wahl der Bezeichnung f r ein System bzw f r eine Komponente h ngt nur vom Kontext der Verwendung ab und dient bei komponier ten Systemen zur besseren sprachlichen Unterscheidung zwischen dem Gesamtsystem und seinen Komponenten Wir beginnen den formalen Teil dieses Kapitel mit einer Einf hrung in ben tigte ma thematische Grundlagen 3 2 Mathematische Grundlagen Die Grundlage zur Darstellung von Kommunikation zwischen Systemen bilden die Str me die als Sequenz von Nachrichten die Kommunikationsgeschichte auf einem Ka nal darstellen k nnen Wir definieren sie zusammen mit den zugeh rigen Operatoren Definition 3 1 Str me und ihre Operatoren Sei M eine beliebige nichtleere Menge Ein Strom ber M ist eine endliche oder un endliche Sequenz von Elementen aus M Die Menge der endlichen bzw unendlichen Str me be
70. Do auf r kann er Anfragen R empfangen die ihn auffordern auf dem Ausgabekanal c die bisherige Anzahl von gez hlten Daten auszugeben Formal haben wir also die Schnittstelle I i r O c mit type i D U Da type r R type c N und definieren Z hler I O i r n n 0 T mit n N und T definiert durch Name Pre Input Output Post Ti r R aln n n T2 i d n n 1 Wir definieren eine Modifikation M die spontan Daten vom Eingabekanal verliert also Daten unter Umst nden nicht mitz hlt M 2 F mit df Name Pre Input Output Post F LK T3 i d n n Betrachten wir folgenden exemplarischen Ablauf so erkennen wir dass Zustand 4 durch die fehlerhafte Transition T3 erreicht wurde Es wurde ein Datum von o gelesen aber n nicht erh ht 110 9 2 1 di 3 1 di R 1 4 1 di d2 R 1 5 2 d d2 d3 R 1 6 2 d d2 d3 R R 1 2 4 3 FORMALISIERUNG DER FEHLERBEGRIFFE 97 Dieser Zustand ist ein Fehlzustand da es keinen Ablauf ohne Verwendung von 73 gibt der diesen Zustand erreicht Im unmodifizierten System Z hler ist n i eine Invariante Dennoch beschreibt Zustand 4 kein Versagen des Systems d h der Fehler ist noch nicht sichtbar geworden da es einen fehlerfreien Ablauf gibt der nach aussen identisch aussieht Zustand 4 unterscheidet sich von Zustand 4 durch den korrekten Wert f r n aber n ist als lokale Variable vor der Umgebung verborgen
71. ERHALTEN 41 i Merge e 0 tz Abbildung 3 1 Schnittstelle von Merge Beispiel 3 1 Wir betrachten in diesem und auch dem n chsten Kapitel ein einfaches System namens Merge an dem sich die Konzepte dieser Arbeit gut veranschaulichen lassen Das System soll hnlich einem Multiplexer die Nachrichten die es ber zwei Kan le empf ngt auf seinem Ausgabekanal wieder ausgeben Das System hat also zwei Eingabekan le 7 und 22 Uber den Kanal i k nnen Nachrichten eines Typs Dj ber ig Nachrichten vom Typ Da empfangen werden Die beiden Nachrichtenmengen seien nicht weiter spezifiziert F r sie sei lediglich angenommen dass sie disjunkt sind also D N D gilt Auf dem Ausgabekanal o k nnen alle empfangenen Nachrichten wieder ausgegeben werden wodurch sich der Typ von o als die Vereinigung aller Nachrichten von D und Da ergibt Formal definieren wir also I i i2 O 0 type D type t2 Do type o D U D In dem hier verwendeten Systemmodell ist die Schnittstelle eines Systems bzw einer Komponente statisch bleibt also nach der Implementierung unver ndert Systeme mit Komponenten deren Schnittstellen sich zur Laufzeit ndern werden in der vorlie genden Arbeit nicht betrachtet Das derart verallgemeinerte mobile dynamische FOCUS wird in 29 30 B2 beschrieben 3 4 Systemverhalten Das Verhalten eines Systems wird charakterisiert durch die Beziehung zwischen
72. Fehlertoleranz Sei ein Transitionssystem S gegeben das die Eigenschaft habe d h es gelte SE Wir nennen das System S fehlertolerant bez glich der Fehler MS und der Toleranz M wenn gilt SAMS aM Ist M die neutrale Modifikation so liegt eine maskierende Fehlertoleranz vor Die auftretenden Fehler in S erhalten dann die Black Box Eigenschaften des Systems F r eine sehr differenzierte Aussage ber die Fehlertoleranz eines Systems kann unter Umst nden der Nachweis mehrerer dieser Eigenschaften notwendig sein Ein System kann bez glich einer Abweichung M die Fehler M tolerieren bez glich einer Ab weichung M die Fehler M und so weiter In den meisten F llen wird man sich aber auf ein einziges maximales Fehlermodell konzentrieren und f r diese Fehlerf lle die Auswirkungen ermitteln Wir werden in Definition T3 lin Abschnitt Z5 3Jeine hnliche Aussage wie in Definition 10 wiederfinden Die Aussage der Fehlertoleranz stellt eine spezielle Interpretation der korrespondierenden Modifikationen dar Mit den Beschreibungstechniken f r Systeme und ihre Modifikationen zusammen mit den Beweistechniken k nnen wir Fehlertoleranz ausdr cken und verifizieren ohne neue Notationen oder Begriffe einf hren zu m ssen Auf einen Unterschied zu anderen Ans tzen zur Fehlermodellierung in der Literatur insbesondere die Arbeiten von Joseph Liu 48 47 und Janowski 86 B5 ist hier hinzuweisen da er g
73. Formale Fehlermodellierung f r verteilte reaktive Systeme Max Breitling Lehrstuhl f r Software amp Systems Engineering Institut f r Informatik Technische Universit t M nchen Institut f r Informatik der Technischen Universit t M nchen Lehrstuhl f r Software amp Systems Engineering Formale Fehlermodellierung f r verteilte reaktive Systeme Max Dieter Breitling Vollst ndiger Abdruck der von der Fakult t f r Informatik der Technischen Uni versit t M nchen zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften Dr rer nat genehmigten Dissertation Vorsitzender Univ Prof Dr Christoph Zenger Pr fer der Dissertation 1 Univ Prof Dr Manfred Broy 2 Univ Prof Dr Eike Jessen Die Dissertation wurde am 14 03 2001 bei der Technischen Universit t M nchen eingereicht und durch die Fakult t f r Informatik am 18 06 2001 angenommen Zusammenfassung An die Entwicklung heutiger informationstechnischer Systeme werden aufgrund ihrer hohen Komplexit t strenger Rahmenbedingungen und vielf ltiger geforderter Qua lit tsmerkmale hohe Anforderungen gestellt Insbesondere f r Systeme oder System teile deren M ngel zu erheblichen Sch den f hren k nnten ist die Entwicklung mit Hilfe formaler Methoden ein Ansatz diesen Anforderungen zu begegnen Formale Me thoden erm glichen eine hohe Pr zision in Spezifikationen und die akkurate Verifikation kritischer Systemeigenschaften
74. HLERN 2 A T3 A T4 2 A c 1IX cFlA gt c 2A k lt i c 2 k lt i2 7 1 o gt k Abbildung 5 11 Modifiziertes Fortschrittsdiagramm f r Merge g ltig Wir k nnen sie aber abschw cherf und behaupten nur noch Ho knk lt rnk lt an m o gt k Mit 2 definiert als 0 k A k lt i A k lt k nnen wir die Knotenbeschriftungen verst rken und erhalten das Diagramm in Abbildung 5 11 Als Ausschnitt der darin enthaltenen Beweisverpflichtungen zeigen wir exemplarisch die Schalt bereitschaft von rj Dazu m ssen wir die Eigenschaften aus dem linken oberen Knoten im Diagramm sowie die Invariante verwenden die wir in Beispiel BB hergeleitet haben die nach einer weiteren aber im Beweisdiagramm in Abbildung B Jleicht erkennbaren Verst rkung als o ip i A Hi 0ONc 2 v HR 0Ac 1 formuliert werden kann Wir leiten aus c 1 daraus Ho if i9 i ab so dass wir mit fo k lt 4 Hip Hirt auf it gt 0 schlie en k nnen Damit ist r schaltbereit Beweisdiagramme stellen also nicht nur eine geeignete Methode dar Beweise zu re pr sentieren sondern erm glichen es durch ihre graphische und damit intuitive Dar stellung auch die Ver nderungen von Eigenschaften bei modifizierten Transitionssys temen zu ermitteln Es l t sich gut verfolgen welche neue Transitionen aus dem Dia gramm herausf hren bzw welche entfernten Transitionen die
75. LERN Wir nennen eine Schnittstelle I O eine Erweiterung einer Schnittstelle J O wenn neue Kan le erg nzt werden oder der Typ existierender Kan le erweitert wird Definition 4 1 Erweiterung der Schnittstelle Die Schnittstelle hei t Erweiterung der Schnittstelle I O wenn gilt Vi I e type i C type i Vo E Oe type o C type 6 Die erweiterten Kan le werden zur Unterscheidung von den urspr nglichen Kan len mit markiert um die Typerweiterung zwischen den alten und den neuen Kan len ausdr cken zu k nnen Die Kanalmenge I bzw enth lt also alle Kanalnamen von I bzw O die darin aber markiert sind und m glicherweise noch weitere neue Kanal namen Beispiel 4 1 Schnittstellenerweiterung von Merge Die Schnittstelle der Komponente Merge ist I f ig O 0 mit type i1 DATA type i2 DATA type o DATA U DATA Nehmen wir an wir wollen den Typ der Eingabekan le um ein weiteres Datum high DATA U DATAg erg nzen das anzeigt dass das folgende Datum durch eine sp ter zu erg nzende ent sprechende Modifikation des Verhaltens mit h herer Priorit t eingemischt werden soll Ferner wollen wir die Komponente um einen neuen Ausgabekanal erweitern auf dem Fehlermeldungen gesendet werden k nnen Die neue Schnittstelle i1 a gt mit type 1 DATA U high type t2 DATA U high type DATA ist eine Erweiterung gem obiger Definition Der
76. MAST 2000 Algebraic Methodology And Software Technology number 1816 in Lecture Notes in Computer Science pages 11 25 Springer 2000 165 166 13 20 21 22 23 24 LITERATURVERZEICHNIS BREITLING MAX und JAN PHILIPPS Verification Diagrams for Dataflow Proper ties Technischer Bericht TUM I0005 Institut f r Informatik Technische Univer sit t M nchen 2000 BROWNE I A Z MANNA and H B SIPMA Generalized temporal verification diagrams In Foundations of Software Technology amp Theoretical Computer Science number 1026 in Lecture Notes in Computer Science pages 484 498 1995 Broy MANFRED Interaction refinement the easy way In BRoy M editor Program Design Calculi Springer NATO ASI Series Series F Computer and System Sciences Vol 118 1993 Broy MANFRED A Functional Rephrasing of the Assumption Commitment Spe cification Style Technischer Bericht TUM I9417 Institut f r Informatik Techni sche Universit t M nchen 1994 Broy MANFRED Compositional refinement of interactive systems Journal of the ACM 44 5 September 1997 Broy MANFRED The Specification of System Components by State Transition Diagrams Technischer Bericht TUM I9729 Institut f r Informatik Technische Universitat Miinchen 1997 Broy MANFRED FRANK DEDERICHS CLAUS DENDORFER MAX FUCHS THO MAS F GRITZNER und RAINER WEBER The Design of Distributed Systems An Introduction to FOCUS Technisc
77. Nach den Zwischenformen 3a und 3b charakterisiert Spalte 4 die schw chste Form der D mpfung von Fehlereinfl ssen die genaugenommen keine wirkliche D mpfung mehr darstellt Fehler f hren wieder zu sichtbaren Fehlern des Gesamtsystems chaotisches Verhalten der Teilkomponente bewirkt chaotisches Ge samtverhalten Die Tabelle ist vollst ndig in dem Sinne dass andere Kombinationen nicht mehr sinnvoll als Fehlertoleranz verstanden werden k nnen So darf das Gesamtverhalten keine Fehler aufweisen wenn die betrachtete Teilkomponente korrekt ist die erste Zeile darf also nur die Eintr ge Normal enthalten Das Gesamtverhalten darf nicht ins Chaos verfallen wenn die Komponente vorhergesehene Fehler zeigt also kann Chaos nicht in der zweiten Zeile erscheinen Ein System das auf vorhergesehene Fehler mit sichtbaren Fehlern reagiert auf unvorhergesehene Fehler aber mit Normalverhalten reagiert stellt einen unplausiblen Sonderfall dar den wir nicht in unsere Untersuchungen aufnehmen Wir k nnen die verschiedenen Arten von Fehlertoleranz durch eine Ordnung gt verglei chen die wir durch ee ee definieren Eine gr ere Fehlertoleranz eines Systems besagt informell dass gr ere Fehler eine geringere Auswirkungen haben Die angegebene Klassifikation eignet sich also bei gegebenen Modifikationen Systeme bez glich ihrer F higkeit zur Fehlerd mpfung zu bewerten Die qualitative Bewertung der Fehlerd mpfung eines S
78. Prozesskalk ls CCS mit dem es erm glicht wird fehlerbehaftete Prozesse zu spezifizieren und Eigenschaften abzuleiten Er defi niert eine Ordnung ber Fehlermodelle die die Sch dlichkeit von Fehlern vergleichen l t In seinem Modell gilt Monotonie in folgendem Sinne Toleriert ein System ein gewisse Menge von Fehlern so toleriert es auch jede Teilmenge davon Diese Eigen schaft steht in unmittelbarem Zusammenhang mit dem unvorhersehbaren Auftreten von Fehlern Janowski diskutiert erw nschte Eigenschaften seines Ansatzes der eine schrittweise Entwicklung fehlertoleranter Systeme erm glicht Dazu geh ren eine Un abh ngigkeit der Entwicklung von Systemkomponenten und die schrittweise Integration von Mechanismen gegen wachsende Fehlerklassen ohne dabei bereits integrierte Tech niken unwirksam oder sogar inkorrekt zu machen Wir w hlen hier nicht die Notation aus dem Originalpapier sondern eine vereinfachte Version die die enthaltene Idee aber angemessen ausdr ckt Die Autoren w hlen in ihren diversen Arbeiten verschiedene Notationen 2 2 FEHLERTOLERANZ 27 Abbildung 2 5 Normal und Fehlerzust nde Arora Kulkarni Im Ansatz von Arora und Kulkarni A B ZT A BE 42 wird Fehler toleranz allgemeiner ausgedr ckt da nicht nur maskierende Fehlertoleranz betrachtet wird sondern auch Abschw chungen von verhaltensbeschreibenden Aussagen Ein Zustandspr dikat S ist abgeschlossen f r eine Transitionsmenge wenn alle Tran siti
79. RD SCHATZ Herausgeber Formale Beschrei bungstechniken f r verteilte Systeme FBT99 GI ITG Fachgesprach M nchen 1999 STOLEN KETIL Assumption Commitment Rules for Data flow Networks with an Emphasis on Completeness Technischer Bericht TUM I9516 Institut f r In formatik Technische Universit t M nchen 1995 ST LEN KETIL FRANK DEDERICHS und RAINER WEBER Assump tion Commitment Rules for Networks of Asynchronously Communicating Agents Technischer Bericht TUM I9303 Institut f r Informatik Technische Universit t M nchen 1993 STOREY NEIL Safety critical Computer Systems Addison Wesley 1996 TANENBAUM ANDREW S Computer Networks Prentice Hall 1989 Web Seite der Virtual Library Formal Methods http archive comlab ox ac uk formal methods VYTOPIL JAN editor Formal Techniques in Real time and Fault Tolerant Sys tems Kluwer Academic Publishers 1993 WING JEANNETTE M Teaching mathematics to software engineers Technical Report CMU CS 95 118R Carnegie Mellon University 1995 170 LITERATURVERZEICHNIS Abbildungsverzeichnis METER ee beet WERNER 18 2 2 Vereinfachtes Systemmodelll 2 2222 on nn 19 ed yee been ek ieee ee ae 20 ne bared ayes a 21 Bg ere ar Se Sn Pe 27 Len ede ae oe ee re 31 Stay ata wate ee hoe ay Rh ae 32 tigre u a es Se ee Se ee 33 Lieu tate eee ee eee shennan s 34 ee e ee ree ere 41 3 2 Verhalten von Merge Beispiel oo aaa a a 42 a ee ae E 46 EEE RE 54 a ee
80. Spezifikation des Puffers entspricht Beim Entwurf des Transitionssystems ist diese Annahme implizit mit eingeflossen Die Menge a enth lt die in Definition AMA beschriebene Menge von Belegungen Sind Fangzust nde versehentlich zum Beispiel durch einen Entwurfsfehler in einem System enthalten so kann eine explizite Formulierung der darin enthalten Umgebungs annahme helfen diesen Entwurfsfehler aufzudecken Es lie e sich erkennen dass die Umgebungsannahme nicht intendiert und nicht realistisch ist da sie der Umgebung zuviele Eingaben an das System verbietet Fangzust nde k nnen auch bewu t in ein System aufgenommen werden da ein Sys tem in bestimmten Zust nden tats chlich stehen bleiben soll Der hier vorgestellte Ansatz der impliziten Umgebungsannahmen scheint dann nicht anwendbar zu sein denn es w rde von der Umgebung gefordert werden nur Eingaben zu senden die nicht zu diesen Zust nden f hren Dieses Problem wird vermieden indem zu den gewollten Haltezust nden Transitionen erg nzt werden die alle Nachrichten von allen Kan len konsumieren k nnen ohne dabei eine Reaktion durch Ausgaben sichtbar zu machen Be folgt man dies als Entwurfsdisziplin lassen sich die verbleibenden wahren impliziten Umgebungsannahmen wieder sinnvoll definieren Die Menge aller Eingaben die die Annahme A S verletzen stellen Fehler der Umge bung dar wenn diese dennoch an das System geschickt werden Eine sinnvolle We
81. Systems Ausdrucksm glich keiten der Fehlerbegriffe bietet 2 1 4 Umgang mit Fehlern Nach der Kl rung der grundlegenden Begriffe wollen wir nun den Umgang mit Fehlern diskutieren Es ist heutzutage weitgehend akzeptiert dass Fehler in komplexen Syste men nicht zu vermeiden sind oder nur mit einem erheblichem Aufwand der nicht mehr in einer rechtfertigbaren Relation zu potentiellen Sch den steht die durch tats chlich auftretende Fehler verursacht werden w rden Fehler sind ein Teil des Verhaltens der zwar unerw nscht aber dennoch unvermeidbar ist und daher in einer Systementwick lung ber cksichtigt werden mu 22 KAPITEL 2 DER FEHLERBEGRIFF Im Umgang mit Fehlern k nnen wir zwischen zwei Phasen im Lebenszyklus eines Sys tems unterscheiden der Entwicklungszeit und der Zeit w hrend des Betriebes eines Systems seiner Laufzeit Entwicklungszeit Der offensichtlich ideale Umgang mit Fehlern ist der Ansatz jegliche Fehler zu ver meiden d h nur absolut fehlerfreie System zu erstellen und zu betreiben Inbesondere f r Softwaresysteme ist dieser Ansatz lohnenswert da Software nicht altert keine Ver schleisserscheinungen zeigt und auf nahezu perfekte Weise replizierbar ist Ist also ein fehlerfreies Software System einmal geschaffen bleibt es fehlerfrei Die Disziplin des Software und Requirement Engineerings erarbeitet Modelle Vor gehensweisen und Techniken die dieses Ziel verfolgen Anforderungen an ein System m sse
82. Systems auf verschiedenen Ebenen von lokalen bis zu systemglobalen Fehlern untersucht werden Der Unterschied zwischen E und S besteht im wesentlichen darin dass E die Sys temumgebung beinhaltet auf die ein Entwickler im allgemeinen keinen Einflu hat w hrend 5 ein Teil des zu konstruierenden Systems ist das im Entwicklungproze noch entsprechend gestaltet werden kann Aus der Sicht der Komponente S stellen sowohl 9 als auch E externe Systemteile dar die sich prinzipiell nicht mehr voneinander unterscheiden Sind wir also an der Fehlermodellierung bez glich interessiert k nnen wir das Systemmodell noch etwas vereinfachen Wir fassen E und zusammen zu einer Umgebung U des Systems S wie in AbbildungB 2 dargestellt Die Interaktion zwischen 5 und E stellt in diesem Modell nur noch eine interne Aktivit t von U dail Unser einfaches Systemmodell identifiziert also ein System S eine Umgebung U und eine Schnittstelle zwischen diesen Wir k nnen an diesem Modell nun verschiedene At tributklassen charakterisieren Durch die Schnittstelle und die klare Abgrenzung von internen und externen Merkmalen k nnen wir zwei Sichten auf ein System unterscheiden In der Black Box Sicht auf ein System h lt man seine Interna vollst ndig verborgen nur seine Schnittstelle und Au enwirkung werden betrachtet In der Glass Box Sicht werden zus tzlich die internen Aspekte eines Systems dargestellt beispielsweise seine interne Stru
83. T2 N T 3 8 VERIFIKATION VON EIGENSCHAFTEN 59 Das komponierte System besitzt alle Variablen der Teilsysteme als lokale Variable Gem Voraussetzung gibt es hier keine Konflikte Das System startet in einem Zustand der die Initialbedingungen beider Komponenten erfiillt Die Schnittmengenbildung im Ausdruck fiir die Transitionsmenge T stellt sicher dass jedes Belegungspaar a 6 gleichzeitig eine Transition der einen Komponente und eine Umgebungstransition der jeweils anderen Komponente darstellt Die Zusicherung dass eine Transition immer die Umgebungstransition von jeweils einer Komponente ist stellt sicher dass sich darin die lokalen Variablen nicht spontan ndern k nnen Die Transition einer Teilkomponente hat aufgrund der vorausgesetzten Disjunktheit der kontrollierten Variablen au er einer Verl ngerung der Eingabestr me keine Wirkung auf die jeweils andere Komponente also gibt es f r sie immer eine passende Umgebungstransition Falls beide Transitionssysteme die Eigenschaften aus Definition BBlerf llen erf llt auch das komponierte System wieder diese Eigenschaften gezeigt in T0 ist also wieder ein wohlgeformtes Transitionssystem 3 8 Verifikation von Eigenschaften Mit den bisher dargestellten Techniken sind wir in der Lage Systeme sowohl durch Black Box Spezifikationen als auch durch Transitionssysteme darzustellen Black Box Spezifikationen charakterisieren ein Systemverhalten durch eine Formel die
84. Teilkomponenten zusammengesetzt die nach M glichkeit unabh ngig entwickelt werden k nnen In diesem Abschnitt wollen wir beschreiben wie Komponenten zusammengesetzt werden k nnen Dazu definieren wir zun chst unter welchen Voraussetzungen Komponenten zusammengesetzt werden d rfen und welche Schnittstelle sich f r ein zusammengesetztes System ergibt Wir geben dann sowohl f r Black Box Spezifikationen als auch f r Transitionssysteme an wie das Verhalten des Gesamtsystems aus dem Verhalten der Komponenten abgeleitet wird Eine f r die Komposition vorteilhafte Eigenschaft unseres Systemmodells ist es dass Systeme bzw Komponenten nur ber ihre Ein und Ausgabekan le mit ihrer Umge bung interagieren und keine weiteren Seiteneffekte eine Rolle spielen Ein komponiertes System entsteht daher auf einfache Weise aus den Einzelkomponenten durch die Ver schaltung der Kan le Eine Verschaltung muss angeben welche Komponenten welche Ausgaben einer anderen Komponente als Eingabe erh lt Da alle Komponenten auf Kan le zugreifen die mit konkreten Namen referenziert wer den ergibt sich eine sehr einfache Technik zur Beschreibung der Komposition Kan le mit gleichem Namen werden identifiziert Ein Konflikt kann nur auftreten wenn zwei zu komponierende Systeme gemeinsame Ausgabekan le haben da dann beide auf dem gleichen Kanal Nachrichten senden w rden Diesen Fall schlie en wir mit Hilfe der folgenden Definition aus Definition 3 8 Ko
85. Tran sitionen nicht in das System aufgenommen die f r eine volle Reaktivit t notwen dig sind e Bei dem Entwurf des Systems wurden implizite Annahmen an die Umgebung gemacht die Eingaben ausschlie en die zu einem Fangzustand f hren w rden So k nnen beispielsweise Kontrollzust nde in ein Transitionssystem aufgenom men werden in dem nicht von einem bestimmten Kanal gelesen werden kann da der Entwickler annimmt dass in einem solchen Systemzustand immer andere Nachrichten auf anderen Kan len vorliegen werden die eine Weiterverarbeitung und damit das Lesen der zun chst nicht konsumierbaren Nachricht in reaktiver Weise m glich machen Diese Annahme wurde unter Umst nden nicht explizit dokumentiert ist aber sozusagen versteckt im System enthalten Wir gehen im folgenden vom letztgenannten Grund aus und interpretieren m gliche 116 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN OO Abbildung 4 7 Transitionssystem des Puffers Fangzust nde als implizite Umgebungsannahme Diese fordert von den von der Um gebung produzierten Eingaben dass sie vollst ndig gelesen werden k nnen also das System nicht in einen Fangzustand geraten lassen Definition 4 14 Implizite Umgebungsannahme Die implizite Umgebungsannahme A eines Transitionssystems S wird definiert als die Menge aller Eingabestr me die vollst ndig gelesen werden k nnen f r die das System also in keinem Ablauf in einen Fangzustand ger t Die Menge wird ausg
86. Umst nden vom Rech ner selbst erkannt und an einen Benutzer weitergegeben wird und eine klare Ursache daf r gefunden werden kann ist ein Fehler in einer Spezifikation vielleicht nur schwer zu erkennen und zu lokalisieren seine Ursachen k nnen in M ngeln eines Entwicklungspro zesses liegen und die Folgen k nnen sowohl wieder Fehler im Benutzerhandbuch sein als auch unerwartetes vielleicht sogar unsicheres oder unzuverl ssiges Systemverhalten Die Vielfalt von Bedeutungen mit denen Fehler in Verbindung gebracht wird legt es nahe diesen Begriff hier durch eine genauere Differenzierung zu diskutieren Die obigen Beispiele zeigen eine Gemeinsamkeit die alle Arten von Fehlern aufweisen Ein Fehler beinhaltet immer eine Abweichung eines Ist von einem Soll Fehler lassen sich also nur relativ definieren zu einem Begriff von Korrektheit der Fehlerfreiheit bedeu tet Diese Korrektheit ist oft mittels einer Spezifikation postuliert Dennoch k nnen in einer realen Spezifikation nat rlich Fehler enthalten sein wenn die eigentlichen wahren Anforderungen an ein System nicht korrekt wiedergegeben werden konnten Die Diskre panz zwischen einem Ist und einem Soll kann auch durch ein inkorrektes Soll ausgel st sein wie das Beispiel des vermeintlich falschen Kontoauszuges zeigt Beispiel 2 1 Um die Schwierigkeiten der Qualifizierung Quantifizierung und Lokalisierung von Fehlern zu verdeutlichen wollen wir ein einfaches Beispiel angeben Ge
87. University of Texas at Austin 1992 ARORA ANISH and MOHAMED GOUDA Closure and convergence A foundation of fault tolerant computing IEEE Transactions on Software Engineering 1993 ARORA ANISH and SANDEEP KULKARNI Component based design of multitoler ance IKEE Transactions on Software Engineering 1998 ARORA ANISH and SANDEEP KULKARNI Detectors and correctors A theory of fault tolerance components IEEE Transactions on Software Engineering 1999 Web Seite des Werkzeuges AUTOFOCUS http autofocus in tum de BISHOP PETER Software fault tolerance by design diversity In 49 1995 pages 211 229 BREITLING Max Modellierung und Beschreibung von Soll Ist Abweichungen In 63 1999 Seiten 35 44 BREITLING Max Modeling faults of distributed reactive systems In JOSEPH MATHAI editor FTRTFT 2000 Formal Techniques in Real Time and Fault Tolerant Systems number 1926 in Lecture Notes in Computer Science pages 58 69 Springer 2000 BREITLING MAX und JAN PHILIPPS Black Box Views of State Machines Tech nischer Bericht TUM I9916 Technische Universit t M nchen Dezember 1999 BREITLING MAX und JAN PHILIPPS Diagrams for Dataflow In GRABOWSKI JENS und STEFAN HEYMER Herausgeber FBT 2000 Formale Beschreibungs techniken f r verteilte Systeme 10 GI ITG Fachgespr ch Seiten 101 110 Shaker Verlag Juni 2000 BREITLING MAX and JAN PHILIPPS Step by step to histories In Rus TEODOR editor A
88. W ein gro er Teil des urspr nglichen Beweisdiagramms wiederverwendet Die Abschw chung erfolgt dabei durch eine Verst rkung von oder eine Abschw chung von WV Erg nzung von Transitionen Auch neue Transitionen k nnen dazu f hren dass ein Fortschrittsdiagramm nicht mehr g ltig ist Es ist m glich dass sie in neue Zust nde f hren die vom bestehenden Diagramm nicht erfa t sind und von denen unter Um st nden der Zielknoten nicht mehr erreichbar ist Wir gehen wieder von einem bestehenden Diagramm aus das einen Nachweis f r gt WU repr sentiert Wird das System erweitert um eine Transition 7 muss f r jeden Knoten untersucht werden wohin diese Transition von ihm aus f hrt Wir unterscheiden wieder drei F lle die wir schon von den Invariantendiagrammen kennen e Die Transition 7 ist im Knoten nicht schaltbereit also A T gt false Die G ltig keit des Diagramms bleibt erhalten e Die Transition f hrt in einen anderen existierenden Knoten bei gleichzeitiger Reduzierung der Bewertung es gilt also Pj Aj UAT gt PAA lt u In diesem Fall bleibt weiterhin sichergestellt dass das System auch nach Ausf h rung der neuen Transition noch den Zustand o erreichen wird Falls die Transition schaltbereit ist jedoch kein Knoten im Diagramm vorhanden ist der die notwendigen Bedingungen erf llt so ist ein neuer Knoten 1 mit einer Bewertung 6 41 zu erg nzen Wie schon bei neuen Knoten in Invariant
89. Wie beweist man die Korrektheit der modifizierten Eigenschaft Selbstverst ndlich l t sich die Aussage SAM PAM mit den gleichen Me thoden beweisen wie wir sie in Abschnitt 3 8 dargestellt haben Allerdings kann der Aufwand relativ hoch sein den Beweis vollkommen neu zu f hren W nschens werter ist es den bereits existierenden Beweis f r S ausn tzen zu k nnen um den darin bereits investierten Aufwand nicht zu verlieren Wir wollen also nach M glichkeit bei Modifikationen von Systemen auch ihre Beweise entspre chend modifizieren Da wir Beweise durch Diagramme repr sentieren k nnen wir eine Beweismodifikation durch eine Anpassung der Beweisdiagramme darstellen Wir werden dies im Abschnitt 5 7 diskutieren Korrespondierende Modifikationen k nnen zur Formulierung von Fehlertoleranzaussa gen verwendet werden Wie in Kapitel 2 2 beschrieben sind f r eine pr zise Aussage die Fehler und die tolerierbaren Auswirkungen explizit zu beschreiben Mit M als Feh lermodell einer Implementierung und M zum Formulieren ver nderter Eigenschaften stehen geeignete Ausdrucksm glichkeiten bereit Beispiel 4 11 Korrespondierende Modifikationen Wir haben in BeispielBB die Komponente Merge als Transitionssystem definiert und in Bei spiel BB seine Black Box Eigenschaften Merge Die Modifikation nur noch von einem der beiden Kan le zu lesen wurde in beiden Formalismen in Beispiel AH M und Beispiel AB M5 pr
90. Zu verl ssigkeitsforderungen an Systeme wichtig ist f r die sich die Verwendung formaler Methoden also empfiehlt Der Mangel klarer Begriffe im Umfeld der Fehler und einer Systematik im Umgang mit ihnen wird auch von anderen Autoren identifiziert Felix C G rtner h lt die h ufig verwendeten Begriffe wie fault error und failure f r unscharf definiert 28 These terms are admitttedly vague and here again formalization can help clarification Seite 4 Flaviu Cristian fordert in 23 eine einheitliche Begriffsbildung fiir die Fehlermodellie rung 6 KAPITEL 1 EINF HRUNG One has to stay in control of not only the standard system activities when all components are well but also of the complex situations which can occur when some components fail The difficulty of this task can be exacerbated by the lack of clear structuring concepts and the use of a confusing terminology Presently it is quite common to see different people use different names for the same concept or use the same term for different concepts For example what one person calls a failure a second person calls a fault and a third person might call it an error Jeanette Wing beschreibt in 70 die folgenden Forderungen von Software Ingenieuren hinsichtlich der Ausdrucksm glichkeiten in Spezifikationen When I have asked the question Why specify formally of a software engineer here are the kinds of responses I have heard e to specify what happe
91. Zu seiner Formulierung k nnen auch Information ber die Ausgaben des Systems notwendig werden Dies kann bei Systemen auftreten bei denen die Umgebung Bedingungen erf llen muss die von ei ner nichtdeterministischen Wahl der Ausgaben des Systems abh ngen Dann muss auch die Formulierung der Umgebungsannahme Bezug auf die Ausgaben nehmen k nnen Ei ne Annahme A hat dann also alle Kanalnamen J U O als freie Variable Da wir allgemeine A G Spezifikationen in dieser Arbeit nicht ben tigen werden wir uns auf einfache A G Spezifikationen beschr nken und verweisen auf die ausf hrliche Behandlung dieses Spezifikationstypus in 16 BT 64 63 48 KAPITEL 3 FORMALES SYSTEMMODELL 3 6 Zustandstransitionssysteme W hrend Black Box Spezifikationen das Verhalten von Systemen durch die Relation von vollst ndigen Kommunikationsgeschichten der Ein und Ausgabe beschreiben wird mit Zustands Transitionssystemen angegeben wie das Verhalten schrittweise erzeugt wird Ein Schritt besteht aus dem bergang von einem Zustand des Systems zu einem Nachfolgezustand wobei Nachrichten von den Eingabekan len gelesen und auf den Aus gabekan len geschrieben werden k nnen Zustandstransitionssysteme sind durch das schrittweise Erbringen ihrer Ausgaben als Reaktion auf jeweils aktuelle Eingaben unter Ber cksichtigung eines Systemzustan des sehr nahe an konkreten Systemimplementierungen W hrend wir die Verwendung von Black Box Spezifikationen als eigensc
92. abekanal beliebigen Typs erg nzt Will man ein System um neue Leistungsmerkmale erweitern so muss dazu im allgemei nen die Schnittstelle erweitert werden damit die neuen Merkmale auch nutzbar werden Beispiele sind Signale zum R cksetzen oder Neustarten eines Systems oder Fehlermeldungen anderer Komponenten auf die ein System zu reagieren hat e Der Typ eines bestehenden Eingabekanals wird erweitert so dass ber ihn neue Nachrichten empfangen werden k nnen Diese Form der Schnittstellenerweiterung motiviert sich erneut durch den Wunsch nach einer erweiterbaren Funktionalit t mit zu erg nzenden neuen Nachrichten auf einem existierenden Kanal Auch eine Verallgemeinerung einer Systemfunktionalit t kann eine Erweiterung des Kanal typs bedingen Soll beispielsweise eine Komponente nicht nur nat rliche sondern ganze Zahlen verarbeiten entspricht dies neuen Nachrichten auf einem bereits existierenden Kanal e Die Schnittstelle wird um einen neuen Ausgabekanal erg nzt Sollen beispielswei se zus tzliche im System vorhandene Informationen oder errechnete Ergebnisse ausgegeben oder auch Fehlermeldungen nach au en sichtbar gemacht werden ist die Einf hrung neuer Ausgabekan le n tig e Der Typ eines Ausgabekanals wird erweitert Wiederum k nnen neue Nachrichten die ausgeben werden sollen nicht nur auf einem dedizierten Kanal sondern auch auf bereits existenten Kan len verschickt werden 78 KAPITEL 4 FORMALE MODELLIERUNG VON FEH
93. ahl erweist sich dennoch g nstiger wie am Beispiel BBlerkennbar wird W rde man zun chst die Transitionen erg nzen die c auf 1 bzw 2 setzen so d rften diese danach nicht mehr entfernt werden Die Formulierung von EF w re aufwendiger 120 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Mit Hilfe der formalisierten Modifikationen waren wir in der Lage die sonst nur infor mell charakterisierten Begriffen f r fault error und failure mit einer formalen Definition zu pr zisieren Im n chsten Kapitel werden wir diese Begriffe nutzen k nnen um bei spielsweise die Korrektheit von fehlererkennenden Mechanismen auszudr cken Auch den Begriff der Fehlertoleranz k nnen wir mit Hilfe der Modifikationen pr zise definieren Fehlertoleranz wird meist als die F higkeit eines Systems verstanden un ter dem Einflu von Fehlern dennoch eine akzeptable Leistung zu erbringen Durch Modifikationen k nnen wir sowohl die Fehler als auch die Ver nderung im Verhalten explizit ausdr cken In einer anderen Sichtweise von Fehlertoleranz wird sie als die Abschw chung von Fehlereinfl ssen interpretiert Auftretende Fehler in einer Teilkom ponente oder der Systemumgebung werden zumindest teilweise toleriert und zeigen nur noch eine abgeschw chte Wirkung auf das Gesamtverhalten Wir haben diese Sichtwei se skizziert und eine Vereinfachung aufgezeigt die auf quantitative Bewertungen der Schwere von Fehlern verzichten kann In weiteren Untersuchungen wur
94. alle Nachrichten von o die in der Menge D liegen und zwar auch in der gleichen Reihenfolge Das Verhalten des zusammengesetzten Systems Multiplex ergibt sich damit direkt zu der Kon junktion aus Merge und Split Multipla D amp o A w DOo A o D amp o A o Do Aus dieser Verhaltensbeschreibung folgt i1 01 A ig 02 Dies beschreibt damit ein Verhalten wie man es von einem Multiplexer erwartet 3 7 2 Komposition von Zustandsmaschinen Zwei Zustandsmaschinen k nnen zu einer Zustandsmaschine komponiert werden die genau die Transitionen ausfiihren kann die auch die beiden Komponenten durchfiihren k nnten Das zusammengesetzte System kombiniert dazu eine Transition der einen Teil maschine mit einer Umgebungstransition der anderen Maschine und fiihrt sie gemein sam aus Damit keine Konflikte durch Uberlappungen von internen Variablen entstehen m ssen neben der Kompatibilit t der Schnittstellen weitere Forderungen gestellt wer den Definition 3 11 Komposition von Zustandsmaschinen Es seien zwei kompatible Zustandsmaschinen gegeben mit S I O1 A1 Y T und S2 h O2 Aa Ya Ta f r die durch eventuelle Umbenennung sichergestellt sei dass 01 U A1 A O2 U A2 BA A nk amp AAnh amp Das Verhalten des komponierten Systems S Q Sa ist definiert durch die Zustandsma schine S I O A Y T mit I und O definiert wie in Definition J und A A U Aa Y T XATa T FO T U
95. alle ausgehenden Nachrichten die aus lesenden Zugriffen auf diese Speicherzelle resultieren konsequent modifiziert werden bis in diese Speicherzelle schlie lich neu geschrieben wird Diese Modifikation ist durch eine entsprechende zus tzliche Transition deutlich einfacher zu repr sentieren Beispiel 4 6 Die Modifikation von Merge zu einer Komponente die nur einen Eingabekanal bertr gt l t sich auf verschiedene Weisen modellieren von denen wir hier zwei skizzieren 92 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN e Eine vorgeschaltete Modifikationskomponente M vom Typ entsprechend Abbildung 4 3 a kopiert nur einen der beiden Eingabestr me und blockiert den jeweils anderen Als Schnittstelle f r M w hlen wir i 23 u i2 womit Bedingung 1 erf llt ist mittels der Bijektion f i gt i i ig Das Verhalten von M beschreiben wir mit Hilfe einer Black Box Spezifikation durch Y i 4 Ath V i Aiz i Das modifizierte System hat die Schnittstelle 3 o und zeigt das durch Kon junktion beschriebene Verhalten VAD amp o iAD amp So ia woraus sich durch Expansion und Ersetzung Di o i A Do v Di o A DxSo 15 ableiten l t Nach einer Vereinfachung ergibt sich bis auf Kanalumbenennung genau die in Beispiel AM erwartete Eigenschaft al gl o 4 Vo e Der Verlust der Daten eines ganzen Eingabekanals kann auch durch eine nachgeschal tete Modifikationskomponente en
96. araus keine Eigenschaften mehr ableiten lassen Es beschreibt damit das schlimmste aller denkbaren Fehlermodelle Die Beliebigkeit des Verhalten ist etwas eingeschr nkt da in einem realen System nat rlich nicht alle Paare i 0 bzw alle Transitionen aus F wirklich auftreten k nnen So muss beispielsweise die Kausalit t und die Monotonie auf den Kan len entsprechend Abschnitt 8 4 erhalten bleiben Auch durch einen Fehler kann ein System nicht an In formationen gelangen die noch nicht verf gbar sind Alle Fehler die in der Realit t auftreten k nnen werden aber mit diesem Fehlermodell erfa t Mit unseren Beschreibungstechniken sind wir in der Lage f r verschiedenartige Feh lermodelle eine Formalisierung anzugeben Diese Modelle k nnen in Untersuchungen verwendet werden in denen das Verhalten von Systemen unter dem Einflu von Fehlern analysiert wird und es werden Fehlertoleranzaussagen m glich gemacht Als Beispiel 5 2 FORMULIERUNG VON FEHLERANNAHMEN 125 sei das Alternating Bit Protokoll erw hnt Dieses Protokoll erm glicht eine bertra gung von Daten ber Kan le die omission failures aufweisen versagt aber falls auf den Kan len ein crash failure auftritt Ein formaler Beweis dieser Aussage kann auf die hier vorformulierten Fehlermodelle zur ckgreifen 5 2 Formulierung von Fehlerannahmen Wie wir gesehen haben k nnen wir die Fehler eines Systems durch Modifikationen dar stellen Die Ausdruckskraft der M
97. ariante also erhalten Das angegebene Beweisdiagramm ist nicht das einzige Diagramm das die Invariante zeigt Wir haben hier nicht das einfachste Diagramm gew hlt um die Anwendung der Verifikationsdia gramme besser veranschaulichen zu k nnen 64 KAPITEL 3 FORMALES SYSTEMMODELL o 4 4 4 as 0 vv Ne A e 5 5 0 i 0 IN A Fo HY Fi Abbildung 3 7 Invariantendiagramm fiir Merge Fortschrittsdiagramme Der Nachweis der Eigenschaft W fiir alle Abl ufe eines Systems kann mit einem Fortschrittsdiagramm erfolgen das die folgenden Eigenschaften erf llt Die Knoten wer den zus tzlich mit einer Bewertung 6 versehen die einem Systemzustand einen Wert aus einer wohlfundierten Ordnung W lt zuordnet also a gt W e Das Pr dikat impliziert mindestens eines der Pr dikate im Diagramm also gt oV V e Jeder Knoten hat mindestens eine ausgehende Kante Von den ausge henden Kanten 7 T eines Knotens ist mindestens eine Transition schalt bereit j gt En 7 ViN En 7i e F r jeden Knoten mit j l n und jede Transition r T gilt genau einer der beiden folgenden F lle Vom Knoten geht keine mit T beschriftete Kante aus und es gilt Pj Ad UuAT gt PA lt u Vom Knoten geht eine Kante zu einem Knoten F r alle derartigen Knoten gilt DRG UT gt P
98. as fehlerbehaftete System abgeleitet werden kann In Abschnitt B 8 2 haben wir gesehen wie Beweise f r Invarianten und Fortschritts eigenschaften mit Hilfe von Diagrammen repr sentiert werden k nnen Wir gehen im folgenden von einem Transitionssystem S aus zusammen mit einem g ltigen Beweis diagramm f r eine Eigenschaft Sowohl f r Invarianten als auch Fortschrittsdia gramme beschreiben wir nun ob und wie diese an eine Ver nderung der Transitionen angepasst werden k nnen 144 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN 5 7 1 Invariantendiagramme Wir unterscheiden zwischen den Auswirkungen die das Entfernen und das Hinzuf gen von Transitionen auf ein Invariantendiagramm haben Entfernen von Transitionen In einem Invariantendiagramm ist mit jedem Knoten und jeder davon ausgehenden Transition eine Beweisverpflichtung verbunden Damit ist es offensichtlich dass durch die Entfernung von Transitionen die Zahl der Beweisver pflichtungen reduziert wird Liegt ein g ltiges Beweisdiagramm f r ein System S vor so stellt dies automatisch auch ein g ltiges Diagramm f r das System SA E amp dar Es kann m glich sein dass f r das ver nderte System mit weniger Transitionen eine st rkere Invariante gezeigt werden kann als die vom urspr nglichen Diagramm bewie sene Aussage S IF inv o V V Folgende Ver nderungen am Beweisdiagramm sind zul ssig ohne seine G ltigkeit f r das System SA E zu gef hrden e E
99. ationen exakt zu definieren und formal zu berpr fen ob die Fehlererkennung eines Systems in Bezug auf diesen Fehler ad quat ist Als weiteren typischen Schritt in der Entwicklung eines fehlerbehafteten Systems haben wir sowohl die Einf hrung von Varianten von Fehlermeldungen angegeben als auch eine schematische Erweiterung um eine allgemeine Fehlerbehandlung Dabei haben wir den Stopp eines Systems zur Sicherstellung eines fail safe Verhaltens und den Neustart eines Systems als Spezialf lle modelliert Alle eingef hrten nderungen eines Systems konnten wieder als Modifikationen eines Transitionssystems oder als Modifikationskom ponenten dargestellt werden so dass sich der bereits eingef hrte Formalismus erneut als ausreichend m chtig erweist Um ein System auch in einer Umgebung verwendbar zu machen in der zu definieren de Fehler auftreten kann dieses auf systematische Weise robuster gemacht werden Es weist in einer gutartigen Umgebung das urspr nglich spezifizierte Verhalten auf zeigt aber auch bei auftretenden Fehlern sinnvolle Reaktionen die in Abh ngigkeit vom je weiligen Anwendungskontext zu definieren sind Wir haben formale Kriterien f r eine Systemmodifikation vorgestellt die eine derartige Erh hung der Robustheit sicherstel len In einer formalen Systementwicklung im Rahmen unseres Modells kann man Black Box Eigenschaften eines Transitionssystems verifizieren Wird ein Transitionssystem durch eine Modifikation
100. auf einen erkannten Fehler ist die Meldung des er kannten Fehlers nach aussen an die Systemumgebung Dazu kann ein bestehender oder ein neuer dedizierter Kanal f verwendet werden Unter Verwendung der in Kapitel LI vorgestellten Technik k nnen wir zun chst einen Kanal erg nzen oder den Typ eines bestehenden Kanals verhaltensneutral erweitern Ein Fehler werde entsprechend Abschnitt 5 3 durch ein Zustandspr dikat Y erkannt Das Senden einer Fehlermeldung 5 4 EINF HRUNG VON FEHLERMELDUNGEN 131 fail auf dem Kanal f kann dann durch eine neue Transition der Form Name Pre Input Output Post TF vv fifail post modelliert werden Die Nachbedingung post fordert typischerweise dass der lokale Da tenzustand bei Versenden der Fehlermeldung unver ndert bleibt Allerdings kann hier auch eine Fehlerkorrektur initiiert werden wie wir im folgenden Beispiel und im n chs ten Abschnitt sehen werden Diese neue Transition ndert das Verhalten des Systems nicht solange kein Fehler auftritt Damit die Fehlermeldung nur genau dann geschickt wird wenn ein Fehler vorliegt d rfen bereits existierende Transitionen die Nachricht fail nicht versenden Wir stellen dies sicher durch das Entfernen aller Transitionen die dies tun Dabei sollen alle anderen Nachrichten auf f noch immer gesendet werden k nnen E a p b f af fail Die Transition tf muss bei dieser Modellierung aber nicht sofort ausgef hrt werden wenn ein Fehler vorliegt Sind
101. be von zwei in Abbildung EL 2Ib illustrierten Angaben explizit dargestellt werden Der dunkel schattierte Teil E ist der Teil des Verhaltens den durch die Modifikation verliert Der durch F repr sentierte grau schattierte Teil stellt die neuen Anteile des Verhaltens dar Diese Idee die Ver nde rung durch Angabe von neuen und zu entfernenden Teilen explizit zu machen wird sich in den folgenden Formalisierungen von Modifikationen widerspiegeln 4 2 MODIFIKATION DES VERHALTENS 83 Abbildung 4 2 Verhaltensmodifikation Im folgenden geben wir an wie konkrete Verhaltensmodifikationen in den in Kapitel Bl vorgestellten Beschreibungstechniken notiert werden k nnen Wir behandeln die re lationale Sicht die Black Box Ebene die Sicht der Transitionssysteme und sogenannte Modifikationskomponenten Die Zusammenh nge von Modifikationen die mittels ver schiedener Techniken und damit auf verschiedenen Abstraktionsebenen angegeben wer den sind in Abschnitt 4 5 3 beschrieben Wir greifen f r die Beispiele dieses Abschnitts wieder die Komponente Merge aus Kapi tel Blauf die zwei Eingabestr me zusammenmischt Wir werden mit den im folgenden dargestellten Beschreibungstechniken immer die gleiche Modifikation beschreiben die eine Abweichung vom eigentlich intendierten Systemverhalten darstellt Das System soll einen der beiden Kan le ignorieren und daher nur die empfangenen Nachrichten des andere
102. beschrieben werden Die Bl tter unseres Ent wicklungsbaumes enthalten daher Zustandstransitionssysteme von denen mit den Me thoden aus Abschnitt B 8 gezeigt wird dass sie tats chlich die geforderten Eigenschaften aufweisen Es sind noch weitere Verfeinerungen auf der Ebene der Transitionssysteme denkbar Die praktische Anwendbarkeit ist jedoch beschr nkt so dass wir diese hier nicht n her beschreiben sondern auf 56 verweisen Auch auf den bergang von Transitionssyste men zu Implementierungen in konkreten Programmiersprachen der wie im Werkzeug AurtoFocus 6 weitgehend automatisiert erfolgen kann wird hier nicht weiter einge gangen Das Ziel dieser Arbeit ist es die m glichen Fehler eines Systems zu modellieren und sinnvoll mit ihnen umgehen zu k nnen Dazu sollen auch in einer bereits durchgef hrten Systementwicklung nachtr glich noch Fehler ber cksichtigt werden Dies erfordert eine Anpassung des Systementwicklungsbaumes Wird ein Knoten des Baumes modifiziert so m ssen auch die damit verbundenen Knoten entsprechend modifiziert werden so dass wieder ein korrekter Systementwicklungsbaum vorliegt In den Abschnitten 1 5 1 und 4 5 2 sowie in weiten Teilen von Kapitel 5 wird diese Thematik behandelt 3 11 Zusammenfassung Neben dem hier vorgestellten Systemmodell von FOCUS gibt es weitere Systemmodelle die geeignet sind verteilte reaktive Systeme zu modellieren wie beispielsweise TLA 72 KAPITEL 3 FORMALES SYSTEMMO
103. bezogen das vom Normalverhalten ab weicht Allerdings wird dabei nicht jedes abweichende Verhalten ber cksichtigt sondern eine Unterscheidung gemacht zwischen Abweichungen mit deren Auftreten man um gehen m chte und den restlichen Abweichungen die man entweder f r unm glich oder f r unwahrscheinlich genug h lt um sie in Betracht ziehen zu m ssen Auch andere for 75 76 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Normal Fehler verhalten verhalten elites Abbildung 4 1 Verhaltensklassen male Ans tze zur Fehlermodellierung klassifizieren Verhalten in diese drei Typen 59 Mit dem Formalismus den wir in dieser Arbeit pr sentieren ist es m glich eine schar fe Trennung zwischen diesen drei Klassen zu ziehen Wir k nnen damit Abweichungen vom Normalverhalten die formal zu untersuchen und f r die etwaige Gegenma nahmen zu erg nzen sind exakt spezifizieren In den folgenden beiden Abschnitten beschreiben wir was Modifikationen von Syste men sind und wie sie formal repr sentiert werden unterschieden nach Modifikatio nen der Schnittstelle eines Systems Abschnitt LT und Modifikationen des Verhaltens Abschnitt 4 2 Wir nutzen in Abschnitt 4 3 und 4 4 die formalen Fundierungen zur Definition von sonst meist nur informell beschreibbaren Begriffen aus dem Umfeld der Fehler und Fehlertoleranz In Abschnitt E5 Juntersuchen wir formale Eigenschaften von Modifikationen wie ihre Kombination und ihr
104. bildungB 3 Als Bewertung k nnen wir die Konstanten 6 1 und 69 0 w hlen Fast alle Beweisverpflichtun gen sind offensichtlich nur die Schaltbereitschaft einer der beiden Transitionen in Zustand muss nachgewiesen werden Dazu m ssen wir die in Beispiel BI gezeigte Invariante 0 i i verwenden und k nnen folgern dass Hi H Ho k lt Hi Hi Hi Hit 8 Hi im Knoten g ltig ist woraus sich i i gt 0 ergibt Damit wissen wir dass auf einem der beiden Kan le noch ungelesene Nachrichten vorhanden sind woraus wir En 71 V En 72 schlie en k nnen Das System Merge wird also noch Ausgaben produzieren Wir k nnen auch hierarchische Diagramme zulassen in denen Knoten einander umfas sen k nnen Dies kann dann n tzlich sein und zur bersichtlichkeit beitragen wenn die Knoten gemeinsame Konjunktionsglieder haben die somit nur noch einmal notiert wer den m ssen Hierarchische Diagramme k nnen in flache Diagramme bersetzt werden die die gleiche M chtigkeit aufweisen Wir verzichten daher auf eine genauere Darstel lung und verweisen auf I3 66 KAPITEL 3 FORMALES SYSTEMMODELL Aus einem Diagramm k nnten mit Hilfe geeigneter Werkzeuge die darin enthaltenen Be weisverpflichtungen generiert werden und sogar automatisch oder interaktiv bewiesen werden In 13 wird dieser Ansatz vorgestellt In Kapitel 5 7 werden wir die Beweisdiagramme wieder aufgreifen und diskutiere
105. ch zu verifizieren Es ist also lohnenswert in dieser Rich tung weiterf hrende Untersuchungen durchzuf hren und den Testbegriff auch im formalen Umfeld zu etablieren Um die pragmatische Verwendbarkeit der Ans tze dieser Arbeit in einer realen System entwicklung noch st rker voranzutreiben sind unter anderem die folgenden Arbeitfelder sinnvoll e In Kapitel 5 haben wir typische Schritte formal charakterisiert die im Umfeld einer Entwicklung eines fehlerbehafteten Systems auftreten Die Darstellung ist in gro en Teilen allerdings noch sehr semantiknah So werden beispielsweise Men gen von Transitionen mit Hilfe von Belegungen definiert die wiederum durch Zustandspr dikate beschrieben sind Die Charakterisierung eines korrekten Feh lererkennungspr dikates st tzt sich sogar auf Systemausf hrungen ab F r die praktische Verwendung in einer Systementwicklung sollten diese forma len Definitionen nach M glichkeit aber verborgen und stattdessen auf der Ebene der Beschreibungstechniken ausgedr ckt werden Beispielsweise ist die Ausnah mebehandlung aus Definition BI im Kontext einer konkreten Programmierspra che durch Prozeduren und entsprechende Aufrufe realisierbar unter Umst nden sogar unter Ausnutzung von in einer Sprache bereits implementierten exception Mechanismen Die in dieser Arbeit vorgestellten Techniken stellen damit eine allgemeine und prinzipielle Grundlage zum Umgang mit Fehlern dar die f r die Anwendung in eine
106. chiedenen Kriterien bewertet wer den Fehler k nnen in Kategorien eingeordnet werden wie beispielsweise unkri tisch kritisch und katastrophal Unkritische Fehler betrachtet man als so harm los dass sie nur Auswirkungen haben die keiner intensiven Beachtung bed rfen Kritische Fehler dagegen beeintr chtigen die Systemleistung so erheblich dass Gegenma nahmen zu ergreifen sind Die schlimmste Klasse sind katastrophale Fehler Diese sind absolut untolerierbar und mit allen Mitteln zu vermeiden Weitere M glichkeiten zur Bewertung der Schwere von Fehlern bestehen in der Ermittlung der Kosten die zur Deckung der durch einen Fehler verursachten Sch den notwendig w ren oder werden Man kann das Ma der Tolerierbarkeit von Fehlern angeben indem das erreichbare Niveau der Fehlertoleranz besprochen in 16 KAPITEL 2 DER FEHLERBEGRIFF Abschnitt B 2 bei Vorliegen der Fehler angegeben wird Fehler k nnen auch nach dem Aufwand bewertet werden der f r ihre Behebung notwendig ist Die angegeben Charakteristika kommen nicht in allen Kombinationen vor Es gibt bei spielsweise keine absichtlichen physikalischen Fehler da eine Absicht nur einem Men schen zugesprochen werden kann Es gibt ebensowenig tempor re Softwarefehler die w hrend der Laufzeit des Systems auftreten Meist treten die Kriterien in wiederkeh renden Gruppierungen auf Beispiele sind e Softwarefehler die von Menschen begangen wurden zur Entwicklungszeit auftre ten p
107. d3 di d de d2 d di d1 di da di d2 dt d di da d di de F r die Eingabe d di auf i und da auf ig gibt es beispielsweise drei m gliche Reaktionen im Sinne der informellen Beschreibung da die Nachricht da vor zwischen oder nach den beiden Nachrichten von wieder auf o ausgegeben werden kann 3 4 SYSTEMVERHALTEN 43 Selbstverst ndlich ist es im allgemeinen nicht m glich alle potentiellen Verhalten explizit aufzu listen da die Relation unendlich viele Elemente enth lt und sogar einzelne Elemente unendlich lange Str me enthalten k nnen Die Relation muss durch geeignete Beschreibungstechniken angegeben werden Mit Relationen k nnen Paarungen von Ein und Ausgaben ausgedr ckt werden die einem nicht mehr sinnvollen also kausalem und realisierbarem Verhalten entsprechen Ein Verhalten ist realisierbar wenn es eine Strategie gibt die Eingaben an ein System schrittweise liest und aus diesen die Ausgaben produziert Dabei darf die Reaktion nicht von Nachrichten abh ngen die zu einem aktuellen Verarbeitungszeitpunkt noch gar nicht verf gbar sind Dies widerspr che der Kausalit t und k me der F higkeit des Systems gleich in die Zukunft sehen zu k nnen In PI wird die Realisierbarkeit genauer im Rahmen eines gezeiteten Systemmodells diskutiert und begr ndet dass die Realisierbarkeit im wesentlichen nur durch die Verletzung der Linkstotalit t und der Kausalit t
108. darf nur auf maximal zwei der drei Kan le oc1 oc2 und oc3 die Nachricht true geschickt werden Dies l t sich durch eine Spezifikation der virtuellen Komponente V ausdr cken Diese hat die Schnittstelle oc 0c2 0c3 mit type oc true Die Erlaubnis zum Versagen wird durch die Nachricht true dargestellt ansonsten wird keine Nachricht verschickt Das Verhalten l t sich sowohl durch eine Black Box Beschreibung durch ocy V ocg V 0c3 oder auch als einfaches Transitionssystem spezifizieren in Abbildung B 2 graphisch dar gestellt Die Transitionen sind definiert durch Name Pre Input Output Post a a a a aid Ti oc true T2 oca true T3 oc3 true T12 oc true oca true T13 oc true ocz true T23 oca true ocz true Da wir das ungezeitete Modell als Grundlage haben besteht kein unmittelbarer zeitlicher Zu sammenhang zwischen der Entscheidung von V welche Transition ausgef hrt wird und welche Komponenten damit ausfallen d rfen und dem tats chlichen Ausfall Wird eine Nachricht true von V auf einen Kanal oc geschrieben wird sie von einer der drei Transitionen Tstop zu einem sp teren aber sonst beliebigen Punkt in der Systemausf hrung gelesen Aufgrund der Fairness in den Ausf hrungen ist sicher gestellt dass eine vorhandene Nachrichten irgendwann gelesen wird also ein Ausfall tats chlich stattfinden wird Die Transition r be
109. dem informationstechnischen Umfeld und beschreiben darin weitgehend akzeptierte in der Literatur h ufiger wiederkehrende Darstellungen des Begriffes 2 1 FEHLER 11 2 1 1 Fehlerbegriffe der Literatur In der Literatur findet sich eine ganze Reihe von Begriffen aus dem Umfeld der Feh ler W hrend man in deutschen Texten beispielsweise die Begriffe Fehler Versagen Ausfall St rung und Fehlfunktion findet liest man in englischsprachiger Literatur von faults errors failures malfunctions und mistakes Zwischen dieses Begriffen lassen sich nicht unmittelbar Entsprechungen finden da sie sich in ihren intendierten Bedeutun gen teilweise berschneiden So werden die Begriffe faults und errors meist jeweils beide mit Fehler bersetzt w hrend failure im Deutschen differenziert wird in Ausfall und Versagen Wir werden die unterschiedlichen Begriffe im folgenden herausarbeiten und orientieren uns dabei an den im wesentlichen bereinstimmenden Charakterisierungen aus B9 A3 44 Wir konzentrieren uns auf drei allgemeine zentrale Begriffe die im Englischen als fault error und failure bezeichnet werden Die verbleibenden Begrifflichkeiten wie malfunc tion mistake St rung und Ausfall werden wir als spezielle Auspr gungen dieser drei Begriffe interpretieren Wir werden im Deutschen entsprechend der in 43 vorgeschlagenen Ubersetzung fail ure durch Versagen und error durch Fehlerzustand ausdr cken F r fault werden
110. demnach gut als Ma zur Bewertung eines Systems bzgl seiner Fehleranf lligkeit Hat man keinerlei Information ber die innere Struktur sieht man das System also in einer Black Box Sicht so ist der Begriff des Versagens der einzige der sinnvoll angewendet werden kann In der deutschen Sprache wird failure genauer differenziert in Versagen und Ausfall Ein Ausfall ist ein Versagen das mit einer physikalischen und permanenten Ver nde 12 KAPITEL 2 DER FEHLERBEGRIFF rung einhergeht Ein durchgebrannter Baustein in einer elektronischen Schaltung ist ein Beispiel f r einen Ausfall Eine malfunction bersetzbar mit Fehlfunktion verstehen wir als eine inkorrekte Auf tragsausf hrung Auch bei einer auftretenden Fehlfunktion liegt also eine sichtbare Ab weichung vom erw nschten Verhalten vor Damit k nnen wir eine Fehlfunktion als spe zielle Form des Versagens bezeichnen W hrend man ein Versagen meist als endg ltig und fatal betrachtet so dass eine Reparatur oder der Ersatz des Systems erforderlich wird interpretiert man eine Fehlfunktion eher als eine kurzfristige harmlosere und to lerierbare Abweichung vom spezifizierten Verhalten Wir verzichten im Rahmen dieser Arbeit auf eine derartige Bewertung der Schwere eines Versagens und differenzieren daher nicht weiter zwischen failure und malfunction Error Den Begriff des Fehlerzustands oder auch Fehlzustandes engl error l t sich nur bei zustandsbehafteten Systemen defini
111. den 4 2 4 Modifikationskomponenten Modifikationskomponenten vorgestellt in 8 erlauben es uns ein zu modifizierendes System unangetastet zu lassen und die Ver nderung in seinem Verhalten durch die Komposition mit einer weiteren Komponente zu beschreiben Die Modifikationskompo nente wird zwischen die Umgebung und die eigentliche Komponente geschaltet und kann die ein und ausgehenden Nachrichten ver ndern l schen oder sogar neue Nach richten erzeugen Sowohl die Modifikationskomponente als auch die zu modifizierende Komponente k nnen dabei unabh ngig voneinander in beliebig w hlbaren Formalismen beschrieben werden Verschiedene Varianten die sich in Ausdrucksm chtigkeit und Komplexit t unterschei den sind in Abbildung 4 3 graphisch dargestellt Mit Hilfe einer vorgeschalteten Mo difikationskomponente entsprechend Abbildung 4 3 a k nnen eingehende Nachrichten 90 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN e e S e e S l o a b S e e S c a Abbildung 4 3 Varianten von Modifikationskomponenten manipuliert werden Der Verlust von Eingabenachrichten ist beispielsweise auf diese Weise modellierbar Eine Modifikation der Ausgabe ist mit der in Abbildung 4 3 b dargestellten Variante m glich Der Verlust oder die Verf lschung von Ausgaben kann damit gut modelliert werden
112. den formale Eigenschaften der Modifikationen behan delt die in einem Entwicklungsproze fehlerbehafteter Systeme eingesetzt werden k n nen Wie in Kapitel B 10 beschrieben resultiert ein idealisierter Entwicklungsproze in einem Entwicklungsbaum mit einer abstrakten Spezifikation als Wurzel einer ite rierten Verzweigung in Spezifikationen von Teilkomponenten und schlie lich einem bergang zu Transitionssystemen als Bl ttern Werden an einer Stelle in diesem Baum Modifikationen durchgef hrt ist man an einer Anpassung des Baumes interessiert so dass ein modifizierter aber wieder korrekter Entwicklungsbaum vorliegt Mit den Ab schnitten ber die Fehlerfortpflanzung sind die formalen Grundlagen f r die Modifika tionen innerhalb eines Beschreibungsformalismus bereits dargestellt F r die Anpassung des bergangs von Transitionssystemen zu Black Box Eigenschaften wird im n chsten Kapitel eine methodische Unterst tzung angeboten Schliesslich haben wir die Thematik der externen Fehler behandelt Aufgrund des Schnittstellenbegriffs unseres Systemmodells k nnen wir klar zwischen internen und ex ternen Fehlern trennen Wir haben sowohl explizite als auch implizite Fehlerannahmen diskutiert mit den externe Fehler definiert werden k nnen Den Umgang mit externen Fehlern werden wir in Abschnitt 5 6 behandeln Kapitel 5 Methodischer Umgang mit Fehlern In den vorangegangenen Kapiteln wurden die formalen Grundlagen vorgestellt m
113. des Systems vervielf ltigt Funktionale Redundanz impliziert die Integration zus tzlicher Komponenten die gezielt f r die Fehlertoleranz in das System aufgenommen werden Diese Form kommt in allen fehlertoleranten Systemen vor da immer Systemteile zur Fehlererkennung zum R cksetzen oder Vorausrechnen zur Fehlerkompensation oder zum Melden von Fehlern notwendig sind Informations redundanz beinhaltet die Speicherung redundanter Daten im System beispielsweise als Pr fsummen Zeitliche Redundanz liegt vor wenn zus tzliche Zeit in einem Systemab lauf aufgewendet wird beispielsweise durch wiederholte Abl ufe Man spricht von sta tischer Redundanz wenn die redundanten Bestandteile im fehlerfreien Normalbetrieb bereits einen Beitrag zur Systemleistung erbringen Tun sie dies nur im Ausnahmefall nennt man dies dynamische Redundanz Die Wahl einer Technik zum Erreichen von Fehlertoleranz h ngt von den Charakteristi ka der zu tolerierenden Fehler ab Es besteht hier ein wesentlicher Unterschied zwischen der sogenannten Softwarefehler Toleranz und der Hardwarefehler Tolerand Die bau Die englischen Begriffe software fault tolerance und hardware fault tolerance lassen sich auch inter pretieren durch Software Fehlertoleranz bzw Hardware Fehlertoleranz Diese bezeichnen eine Fehlerto leranz die mit Software bzw Hardware erreicht wird Wir meinen hier aber die Toleranz von Software 2 2 FEHLERTOLERANZ 31
114. die Beschreibung interner Teilkomponenten mit ihren Interaktionen Da wir im Rahmen dieser Arbeit auf die Untersuchung sogenannter dynamischer und mobiler Systeme ver zichten sind all diese Merkmale den statischen zuzuordnen Die Abl ufe eines Systems stellen einen dynamischen Aspekt dar Ein Ablauf eines Systems besteht aus einer Folge von Kontroll und Daten Zust nden Wir ordnen die Zust nde und ihre berg nge also den dynamischen Merkmalen der Glass Box Sicht zu Die beschriebenen Aspekte eines Systems sind nicht unabh ngig voneinander sondern m ssen auf vielf ltige Weise zusammenpassen Abstraktionen der Zustandsfolgen aus den Abl ufen eines Systems werden als sein Black Box Verhalten sichtbar das Umge bungsverhalten hat durch Systemeingaben unmittelbaren Einflu auf die Abl ufe das Systemdesign legt die m glichen Zustandswechsel fest und das Systemverhalten inklu sive seiner Interaktionen mit der Umgebung muss mit der Schnittstelle vertr glich sein um einige Beispiele der Bez ge zu nennen Es ist die Aufgabe eines Entwicklers eine derartige Konsistenz innerhalb der verschiedenen Merkmale und Sichten auf ein System zu erreichen In vielen F llen liegen die Bestandteile der Black Box Sicht als Spezifikation vor Die in ternen statischen Bestandteile des Systems werden dann entsprechend konstruiert und die Abl ufe ergeben sich daraus meist aufgrund einer zugrundeliegenden Laufzeitumge bung Im Idealfall ist am Ende eine
115. die Wahl des Bezeichners E Definition 4 3 Modifikation von Relationen Sei R eine Relation ber der Schnittstelle I O und seien auch E und F Relationen vom gleichen Typ also R E F C type t x x type in x type o1 x type Om Die durch M E F definierte Modifikation modifiziert das System gem RAM R E UF Die Ausdruckskraft dieser Modifikationen ist hinreichend allgemein wie leicht einzuse hen ist Eine Relation R kann zu einer beliebigen Relation R modifiziert werden mittels der Modifikation M R R Eine neutrale Modifikation die keine nderungen be wirkt f r die die Bezeichnung Modifikation also nicht mehr wirklich zutrifft wird durch 2 2 dargestellt Die Modifikation mit F als der All Relation wandelt jedes System R um in ein System mit beliebigem also chaotischem Verhalten Wir fordern in der Definition weder dass die Stromtupel aus E wirklich in R enthalten sind noch dass die Str me in F nicht bereits in R liegen Es bleibt also formal ge stattet nicht vorhandene Stromtupel zu entfernen und bereits enthaltene Stromtupel erneut in die Menge R aufzunehmen Damit werden unn tige Einschr nkungen bei der Formulierung von Modifikationen in konkreten Beschreibungstechniken vermieden Wir lassen hier auch zu dass Str me durch E entfernt und durch F wieder erg nzt werden In Abschnitt 45 1 werden wir allerdings die Disjunktheit der Mengen E und F zwi schen verschieden
116. die Zahl von Anwendungen steigt wachsen auch die Fehlerwahrscheinlichkeiten Auch ein unwahrscheinlicher Fehler wird bei mil lionenfacher Verwendungen von Ger ten irgendwann doch auftreten 2 KAPITEL 1 EINF HRUNG Die gestellten Kriterien an die Qualit t betreffen im allgemeinen eine ganze Reihe von Aspekten die je nach Anwendungsgebiet unterschiedlich gewichtet sein k nnen So sollen Systeme Verl lichkeit aufweisen also die von ihnen erwartete Leistung auf zu verl ssige Weise erbringen Ein System soll sicher im Sinne von safe sein so dass keinerlei Gef hrdung von ihm ausgeht und es nicht m glicherweise Menschenleben be droht oder Sch den anderer Art verursachen kann Es soll auch sicher im Sinne von secure sein also keine Informationen preisgeben an Personen die nicht berechtigt sind diese zu erhalten Ein System soll korrekt sein also genau das tun was von ihm erwartet wird Ausf hrlichere Diskussionen verschiedener Qualit tsaspekte finden sich beispiels weise in 58 45 43 Es ergibt sich noch eine Reihe weiterer Fragen wie beispielsweise die Erwartungen an ein System definiert werden wie die Zuverl ssigkeit ermittelt und bewertet wird wie eine ad quate Spezifikation erstellt wird die selbst wieder als korrekt bezeichnet werden kann und viele mehr Diesen Fragestellungen wird in der Disziplin des Requirements Engineering nachgegangen Wir gehen im Rahmen dieser Arbeit von dem vereinfachten Ansatz aus das
117. dnis interpretiert werden den Softwareentwicklungsproze nicht ausreichend gut zu beherrschen so dass ein Entwicklungsteam darauf aus Imagegr nden bevorzugt verzichtet Techniken der Fehlertoleranz werden daher vorwiegend in Systemen zum Einsatz kom men an die h chste Qualit tsanforderungen gestellt werden Dabei sollte Fehlertoleranz ein zus tzliches Mittel zur Erreichung dieses Zieles sein aber andere Techniken der Feh lervermeidung keinesfalls ersetzen 2 3 ZUSAMMENFASSUNG 35 2 3 Zusammenfassung Im Umgang mit Fehlern lassen sich sehr unterschiedliche Interpretationen der diffe renzierten Fehlerbegriffe finden Wir haben die drei wesentliche Begriffe Fehlerursa che Fehlerzustand und Versagen identifiziert und diese informell charakterisiert und klassifiziert Ein pr ziser und formaler Umgang mit Fehlern erfordert also ein genaues Verst ndnis der m glichen Varianten und geeignete Beschreibungstechniken um mit konkreten Fehlern in konkreten Systemen zielf hrend umgehen zu k nnen Sowohl Fehler als auch Fehlertoleranz sind relative Begriffe Fehler lassen sich nur relativ zu einer definierten Korrektheit bestimmen Ein einzelner Fehler kann nur als Abwei chung von einem intendierten erw nschten System Zustand oder Verhalten sinnvoll angegeben werden Wir haben eine systematische Darstellung der Fehlerbegriffe vor gestellt die diese in Abh ngigkeit einer Soll Ist Abweichung verschiedener Merkmale eines Systems charakter
118. dr ckt und es liegt in unserem Modell kein Versagen im Sinne von Definition AP vor Die auf dem Transitionssystem basierende Spezifikation erlaubt also eine deutlich differenziertere Untersuchung In modifizierten Transitionssystemen lassen sich neben der Menge der normalen Zust n de die auch im unmodifizierten System erreicht werden k nnen der Menge der Fehl zust nde und der Menge der Versagenszust nde noch weitere Klassen von Zust nden auszeichnen e Zust nde die zu Fangzust nden geworden sind da die von ihnen ausgehenden Transitionen durch E entfernt wurden Das System w re in solchen Zust nden nicht mehr reaktiv und w rde seine Aktivit t beenden K nnen diese Zust nde durch einen dem System neu erg nzten Mechanismus erkannt werden so kann man auch eine entsprechende Reaktion in das System integrieren wie wir in Kapitel D diskutieren 98 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN e Zust nde die aufgrund entfernter Transitionen nicht mehr erreichbar sind K n nen Lebendigkeitseigenschaften mit dem Erreichen bestimmter Zust nde verkn pft werden so kann man untersuchen ob eine Modifikation die Erreichbarkeit der Knoten und damit eine Systemeigenschaft gef hrdet Wir werden in Abschnitt B 7 2 zeigen wie man die Auswirkungen von entfernten Transitionen im Rahmen von Beweisdiagrammen ermittelt Die in diesem Abschnitt definierten Begriffe k nnen zur Definition von Techniken zur Fehlererkennung und
119. dustriellen An wendung h ngt in starkem Ma e von der Unterst tzung durch ein Werkzeug ab Ein derartiges Werkzeug sollte einen Entwicklungsproze durchg ngig un terst tzen indem es beispielsweise die Nutzung verschiedenster Beschreibungs techniken anbietet Konsistenz berpr fungen durchf hren kann Verfeinerungs schritte unterst tzt und auch bei der Beweisf hrung durch die Erzeugung und idealerweise sogar Verifikation von Beweisverpflichtungen entscheidende Hilfen anbietet Mit AUTOFocus 6 liegt bereits ein Werkzeug f r unser Systemmo dell vor allerdings noch ohne die Integration der Fehlermodellierung Dieses Werkzeug ist im Sinne dieser Arbeit durch die Unterst tzung des explizi ten Umgangs mit Modifikationen als eigenst ndiges Konzept so zu erweitern dass damit zus tzlich die Modellierung von Fehlern auf den verschiedensten Abstrak tionsebenen und die Integration von Techniken zur Fehlerbehandlung m glich gemacht wird Mit der vorliegenden Arbeit sind die Grundlagen f r eine formale Fehlermodellierung f r verteilte reaktive Systeme zur Verf gung gestellt worden F r einen pragmatischen und unmittelbaren Einsatz der Techniken empfehlen sich die weiterf hrenden Arbeiten die in diesem Abschnitt aufgef hrt wurden Literaturverzeichnis ALPERN BOWEN and FRED B SCHNEIDER Defining Liveness Information Processing Letters 21 181 185 1985 ARORA ANISH A foundation of fault tolerant computing PhD thesis
120. e ber cksichtigt werden Nicht jeder Zustand a der ber fehlerhafte Transitionen erreicht werden kann ist un bedingt ein Fehlzustand Ist n mlich auch ein anderer Ablauf m glich der zu demsel ben Zustand a f hrt ohne dabei Fehlertransitionen zu verwenden so ist nicht in der Menge ERROR S M enthalten Abbildung 4 veranschaulicht einen derartigen Fall Es werden zwei Abl ufe mit gemeinsamen Zust nden dargestellt Runde Knoten repr sentieren Zust nde die keine Fehlzust nde sind quadratische Knoten sind Feh lerzust nde die fett gezeichneten Pfeile repr sentieren Transitionen aus F Der mit x markierte Knoten ist kein Fehlzustand da dieser auch ber einen fehlerfreien Ablauf erreichbar ist W ren alle Nachfolgerknoten von Fehlzust nden auch wieder Fehlzust nde w ren Me chanismen zur Fehlerkorrektur nicht sinnvoll definierbar 4 3 FORMALISIERUNG DER FEHLERBEGRIFFE 95 oO oe Abbildung 4 4 Fehlerzust nde in einem Ablauf 4 3 3 Versagen Ein Versagen engl failure wird blicherweise als eine von aussen sichtbare Abwei chung des Verhaltens vom spezifizierten Verhalten bezeichnet Wir stellen diesen Begriff wieder im Rahmen der Black Box Spezifikationen und Transitionssysteme dar Bei Black Box Sichten definieren wir Versagen auf naheliegende Weise als die Menge der Verhalten die im modifizierten System auftreten k nnen im spezifizierten Verhalten aber nicht Eine derartige Abweichung vom spezifizierte
121. e lich jeweils zwei etablierte Techniken f r Hardware und Softwa refehler darstellen Eine Voraussetzung f r Fehlertoleranz ist die Fehlererkennung Fehler k nnen mit Hilfe von Replikation erkannt werden wenn eine Komponente identisch oder variiert repli ziert wird und die Ergebnisse der verschiedenen Versionen verglichen werden Sind die Ergebnisse nicht identisch oder ist ihre Abweichung au erhalb tolerierbarer Werte so ist dies ein Indiz f r ein aufgetretenes Versagen Replikation ist zwar m chtig kann aber er hebliche Ressourcen erfordern und daher zu kostenintensiv sein Versagen k nnen auch durch Umkehrungstests aufgedeckt werden Von der Ausgabe eines Systems wird auf die Eingaben zur ckgeschlossen und die Plausibilit t berpr ft Eine Probe ist hierf r ein g ngiges Beispiel Sie ist geeignet wenn die Umkehrung sehr viel leichter zu berech nen ist als die zu berechnende Funktion So l t sich beispielsweise die Berechnung des Quadrats viel effizienter durchf hren als die Berechnung der Quadratwurzeln Konsis tenztests sind eine weitere Technik zur Fehlererkennung So kann die Konsistenz von Datenstrukturen berpr ft werden oder es werden Quittungen bei Daten bertragun gen eingefordert Beispielsweise k nnten Sensorenfehler durch zu abrupte nderungen der gelieferten Daten erkannt werden Weitere M glichkeiten zur Fehlererkennung sind zeitliche berpr fungen die mit Timern realisiert werden oder Codierungstests di
122. e Auswirkung ber verschiedene Abstrak tionsstufen hinweg Fehler k nnen nicht nur innerhalb eines Systems auftreten sondern ebenso in der Umgebung eines Systems Dieses Thema behandeln wir in Abschnitt 4 6 Wir schlie en in amp 7 mit einer Diskussion Im darauffolgenden Kapitel 5 werden wir die Verwendungsm glichkeiten des dargestell ten erweiterten Formalismus eingehender diskutieren 4 1 Modifikation der Schnittstelle Wie in Kapitel B beschrieben definiert man ein System durch zwei wesentliche Teile seine Schnittstelle und sein Verhalten Wir wollen beide Teile unabh ngig voneinander modifizieren k nnen also die Schnittstelle ver ndern und dabei das Verhalten weitge hend unver ndert lassen und dann das Verhalten modifizieren ohne dabei gleichzeitige nderungen in der Systemschnittstelle ber cksichtigen zu m ssen Diese Trennung er leichtert einerseits die formale Fehlermodellierung und entspricht auch dem Wunsch bei einer Systementwicklung unterschiedliche Aspekte weitgehend getrennt zu halten und damit die Komplexit t einzelner Entwicklungsschritte im Rahmen zu halten Im Laufe einer Systementwicklung ist es m glich dass nicht von vornherein absehbar ist welche Kan le mit welchen Typen zwischen dem System und seiner Umgebung bzw zwischen den Komponenten eines Systems notwendig sind So kann in einer abstrakten idealisierten Spezifikation in der Fehlerf lle noch g nzlich unber cksichtigt sind keine M glichk
123. e mit Hilfe von Pr fsummen korrupte Datens tze erkennen Nach der Erkennung eines Fehlers folgt idealerweise seine Behebung Folgende drei Prinzipien k nnen dabei zur Anwendung kommen R ckw rts Fehlerbehebung Bei einem auftretenden Fehler wird zu einem rechtzei tig gespeicherten korrekten R cksetzpunkt zur ckgesprungen Die Speicherung muss also regelm ig erfolgen so dass ausreichend fr h und m glichst zeitnah vor dem m glichen Auftreten von Fehlern ein R cksetzpunkt gespeichert wird Der gespeicherte Zustand muss selbst vor Fehlern gesch tzt sein Ein Vorteil der R ckw rts Fehlerbehebung ist die allgemeine Anwendbarkeit da diese Technik weitgehend systematisch auf viele Systeme angewendet werden kann unabh ngig von ihrer spezifischen Funktionalit t Nachteile sind der relativ hohe Aufwand und Verluste in der Performanz der Systeme W hrend bei selten gesicherten 30 KAPITEL 2 DER FEHLERBEGRIFF R cksetzpunkten unter Umst nden weit zur ckgesetzt und damit lange Abl ufe erneut durchgef hrt werden m ssen f hrt h ufiges Sichern von R cksetzpunkten zu einer nicht unerheblichen dauerhaften Verlangsamung des Systems auch oh ne auftretende Fehler Nicht geeignet ist diese Technik jedoch bei permanenten Fehlern bei denen ein erneutes Durchf hren keine Verbesserung erbringt und bei Systemen die viel Interaktion mit ihrer Umgebung aufweisen die sich nicht oder nur schwer zur cksetzen l t Vorw rts Fehlerbe
124. e mit hohen Qualit tsanforderungen unterst tzt Systeme und ihre potentiellen Fehler werden damit auf systematische Weise modellierbar analysierbar und behandelbar Im einzelnen erfordert dieses Ziel die L sung der folgenden Teilaufgaben e Zun chst soll der Fehlerbegriff im Rahmen eines formalen Systemmodells unter sucht und m glichst in bereinstimmung mit etablierten informellen Charakte risierungen des Begriffs formal definiert werden Die Eigenschaften des Fehlerbegriffes sind zu untersuchen und zu differenzieren Fragen nach der Auswirkung von Fehlern in Komponenten auf das Verhalten des Gesamtsystems nach der Wirkung von Kombinationen und berlagerungen von auftretenden Fehlern und nach den Zusammenh ngen von internen und externen Fehlern sollen unter Ausnutzung eines formalen Kalk ls beantwortbar werden Um mit konkreten Fehlern in einem konkreten System umgehen zu k nnen m ssen angemessene Beschreibungstechniken f r Fehler angegeben werden die es erlau ben auf verschiedenen Abstraktionsebenen die durch Fehler bedingten Abwei chungen von Ist und Soll zu formulieren e Fehler in einem System erfordern die Integration von Techniken die mit diesen auf sinnvolle Weise umgehen Dazu sind methodische Anleitungen zu erarbeiten wie ein idealisiertes fehlerfreies System schrittweise zu einem fehlerbehafteten System entwickelt werden kann in dem Fehlern durch Fehlererkennung behebung und toleranz begegnet wird e Der
125. e neue Transition tats chlich von s ausgeht und nur dann schaltbereit ist wenn keine der ursprtinglichen Transitionen schalten kann Damit bleibt das Verhalten bei fehlerfreien Eingaben unver ndert wie wir es auch bei Black Box A G Spezifikationen verlangt haben Die Nachbedingung und der nachfolgende Kontrollzustand der neuen Transition k nnen beliebig definiert werden und sollten eine sinnvolle Fehlerbehandlung bewirken Durch iteriertes Erg nzen von Transitionen kann ein System schlie lich beliebig robust gegen ber externen Fehlern gemacht werden 5 7 WIEDERVERWENDUNG VON BEWEISEN 143 Beispiel 5 7 Unterlauf des Puffers Transitionssystem In Beispiel AT2 haben wir den Puffer als Transitionssystem spezifiziert und die darin enthaltene implizite Umgebungsannahme abgeleitet Wir wollen nun erneut wie in Beispiel Bf leine Reak tion auf einen Unterlauf spezifizieren Dazu zeichnen wir den Zustand aus der einen Unterlauf charakterisiert und ein Fangzustand des Systems ist D trap g fiit R A 4 0 Es liegt in diesem Zustand eine Anfrage vor es sind aber keine Daten in q gespeichert Wir defi nieren f r diese Situation wieder eine Reaktion um die Robustheit gegen ber einem derartigen Umgebungsfehler zu erh hen Mit Hilfe der neuen Transition Name Pre Input Output Post Tuf 9 0 R q q wird die nicht sinnvoll beantwortbare Anfrage einfach ignoriert Die Vorbedingung dieser Tran sition ist disjunkt zu den Vorbedingungen de
126. e sich in der Literatur finden beispielsweise in 43 44 62 66 Lokalisierung Ein Fehler kann bez glich eines Systems intern oder extern auftreten falls der verwendete Systembegriff eine klare Grenze zwischen einem Innen und einem Au en eines Systems zul t Ein Fehler kann lokal sein also einen relativ kleinen berschaubaren Bereich in beispielsweise einer Spezifikation oder einem Programm betreffen oder er kann verteilt in einem System auftreten so zum Beispiel in einem Programm als eine Inkonsistenz in der Reihenfolge von bergabeparametern zwischen der Definition und der Aufrufstelle einer Funktion Ein Fehler kann in einer Spezifikation in einem Systemdesign in der Implemen tierung dem Programmtext oder auch in den Umgebungsannahmen liegen Ein Fehler kann in einer einzelnen verwendeten Komponente des Systems lokali siert sein oder in der Architektur des Systems die fehlerfreie Komponenten auf ung nstige Weise zusammensetzt Fehler k nnen in der Hardware liegen oder sie k nnen in der Software eines Sys tems enthalten sein Hardware und Softwarefehler haben recht unterschiedlich Eigenschaften die wir in B 2Jansprechen werden Verursacher F r den Verursacher eines Fehlers gibt es zwei M glichkeiten Der Feh ler kann durch einen Menschen verursacht worden sein oder durch die physika lische Umwelt Einfl sse durch elektromagnetische oder radioaktive Strahlungen auf Daten bertragungseinrichtungen Hitze mit
127. e von q die Kapazit tsgrenze von N noch nicht erreicht hat Die Transition T2 reagiert auf den Empfang einer Anfrage R durch die Ausgabe des ersten Elementes in q und 3 Der Ausdruck 00 beschreibt den fiktiven Zustand den ein System nach einem unendlichen Ablauf erreicht Er wird definiert in Definition BIZ 4 6 FEHLER IN DER SYSTEMUMGEBUNG 117 dem Entfernen dieses Elements aus q aber nur wenn wirklich Daten in q gespeichert sind Diese Vorbedingung stellt sicher dass der Ausdruck ft q definiert ist Aus diesem Transitionssystem wollen wir nun die darin enthaltene implizite Umgebungsannah me ableiten Wir wollen dazu die Eingabestr me betrachten bei denen das System nicht in einen blockierenden Zustand ger t Hierf r charakterisieren wir zun chst die Umkehrung also die Eingabestr me bei denen das System h ngenbleibt F r unseren Puffer sind diese F lle relativ leicht zu charakterisieren da es nur einen Eingabestrom und einen Kontrollzustand gibt Wir unterscheiden dazu nach der n chsten zu lesenden Nachricht m vom Eingabestrom f r die also gilt i m Ci Entsprechend der Typinformation ber den Kanal i sind zwei F lle m glich e Die n chste zu lesende Nachricht ist ein Element d vom Typ D Diese muss von Transition T gelesen werden die aber nur schaltbereit ist wenn q lt N Der Puffer blockiert also wenn gilt 0 Adei dLirn qg gt N e Als n chste Nachricht muss die Nachricht R kons
128. edr ckt durch Belegungen die unter anderem den Eingabekan len i I Str me zuweisen AS fa veelS eViele odi 00 i na 00 Wir illustrieren diesen Ansatz in dem wir den Puffer aus Beispiel BJ als Transitions system spezifizieren und daraus eine implizite Umgebungsannahme ableiten Beispiel 4 12 Ableitung einer Umgebungsannahme Der Puffer kann als Transitionssystem S I O A T T folgenderma en definiert werden Die Variablenmenge A wird definiert zu 7 q Der gelesene Teil von wird damit standardm ig erg nzt Die Variable q vom Typ type q D verwenden wir als eigentlichen Puffer in dem die Daten gespeichert werden Die Konstante N muss nicht in A aufgenommen werden da wir sie als globale Gr e voraussetzen Da wir keine Kontrollzust nde ben tigen ist daf r auch keine Variable n tig Die Initialbedingung definieren wir zu Ss r q AP A0 Dies besagt dass der Puffer initial leer ist und der Puffer weder Eingaben gelesen noch Nach richten gesendet hat Wir ben tigen zwei Transitionen 7 und 72 in T jeweils f r eine Nachricht vom Typ D und f r eine Anfrage R Das sehr einfache STD ist in Abbildung A 7 dargestellt Die beiden Transitionen spezifizieren wir tabellarisch Name Pre Input Output Post Ti q lt N id qd q da T2 4 gt 0 WR olft g qg rtq Die Transition r liest ein Datum d vom Eingabekanal und h ngt dieses an q an aber nur wenn die L ng
129. ee E 56 eee er en ee eee a Re Er 57 en nee Rie bee eae as 64 ohne abe ead een Babe 65 piweG eee ee ee 68 EIERN 70 3 11 Idealisierter Entwicklungsproze l 2 22 2 cm mn 71 Sgt EE ae er E eng 76 pee Shy ee ee ate ee ee dee 83 oh oe oa TETEE EEEE 90 pe Pees abe aaa eee ap as 95 ee eae eee a 107 171 172 ABBILDUNGSVERZEICHNIS 4 6 _Korrespondierende Modifikationen 22 22 nn m mn 111 4 7 __Transitionssystem des Puffersl 2 2 2 Hm m nn 116 se tay eta re a TEE 126 eaten eb ee 127 eee ee eee 129 Pepa hans 133 ee entre 138 am ES 138 ee 146 ee 147
130. eginnen zu m ssen Die nderungen werden an allen Knoten auf verschiedenen Abstraktionsstufen als Modifikationen repr sentiert Die Verwendbarkeit des Formalismus wird nachgewiesen indem er in Abschnitt BI exemplarisch in typischen Anwendungsmustern dargestellt wird wie sie bei der Entwicklung eines Systems mit potentiellen Fehlern auftreten Mit Hilfe von Orakelstr men und virtuellen Komponenten aus Abschnitt 5 2 wird es erm glicht Fehlerannahmen zu formulieren die mehrere Komponenten betref fen Diese Annahmen treten somit explizit und gut dokumentiert als gew hnliche Teile des Systems auf Sie m ssen nicht wie in anderen Formalismen oft notwen dig au erhalb des formalen Rahmens erfa t werden In den Kapiteln 5 3 E J und 5 5 werden Techniken pr sentiert mit denen Fehler erkannt gemeldet und behandelt werden k nnen Es wurden Kriterien vorgestellt die formalisieren wann eine Fehlererkennung relativ zu einem gegebenen Fehler modell korrekt ist Wir haben Modifikationen erarbeitet die angewandt auf ein System dazu f hren dass auf einen erkannten Fehler mit einer Fehlermeldung reagiert wird Als Verallgemeinerung haben wir eine Modifikation angegeben die eine frei definierbare Reaktion auf einen erkannten Fehler in ein System einf gt 6 2 WEITERF HRENDE THEMENGEBIETE 161 Als konkrete Beispiele haben wir den Stopp oder Neustart als Fehlerreaktion eines Systems vorgestellt e Oft sind mit einem System Um
131. egung a definiert werden Diese weist einer Variablen v denselben Wert zu der von Q an v zugewiesen wird also VveVeav av Um einer Formel die sowohl einfache als auch gestrichene Variablen enth lt einen Wahrheitswert zuzuweisen verwenden wir eine Belegung a und eine gestrichene Bele gung B Die Aussage a BK gilt wenn wahr wird wobei die einfachen Variablen mittels a die gestrichenen Va riablen mittels 3 ausgewertet werden Die Menge der freien Variablen in wird bezeichnet als free Mit x free beschreibt y x die Formel in der aber alle Vorkommen von z durch y ersetzt sind 3 3 Systemschnittstelle Die Schnittstelle eines Systems beschreibt seine Ein und Ausgabekan le Sie wird de finiert durch zwei Mengen die jeweils die Namen der Kan le angeben F r die Kan le m ssen zugeh rige Typen definiert sein Definition 3 3 Schnittstelle Die Schnittstelle eines Systems wird durch ein Paar I O bestehend aus einer end lichen Menge I der Eingabekan le sowie einer endlichen Menge O der Ausgabekan le beschrieben mit IU O C VAR Allen Kan len ce IU O werden durch die Funktion type Typen zugeordnet die die Menge der m glichen Nachrichten enthalten die ber einen Kanal gesendet und empfangen werden k nnen Die Mengen J und O werden typischerweise graphisch repr sentiert wie dies in Abbil dung B 1 f r das folgende Beispiel dargestellt ist 3 4 SYSTEMV
132. eise hat ein System nicht die gew nschten Eigenschaften von Fehlertole ranz da es m glicherweise noch ohne Ber cksichtigung potentieller Fehler entwickelt wurde Nach der Identifikation der zu erwartenden Fehler und ihrer Formalisierung durch Modifikationen ist das System im weiteren Verlauf des Entwicklungsprozesses um entsprechende Mechanismen der Fehlertoleranz zu erweitern Entsprechende Ent wicklungsschritte werden in Kapitel 5 vorgestellt 4 5 Eigenschaften von Modifikationen Wir werden in diesem Abschnitt weitere Konzepte und Eigenschaften definieren die auf Basis des vorgestellen Modifikationsbegriffes m glich geworden sind Dazu zeigen wir wie mehrere Modifikationen zu einer Modifikation kombiniert werden k nnen und unter suchen ihre Wirkung ber verschiedene Beschreibungsebenen hinaus Wir diskutieren die Zusammenh nge von Modifikationen bez glich verschiedener Beschreibungstechni ken unter dem Stichwort der korrespondierenden Modifikationen 4 5 1 Kombination von Modifikationen Im Laufe eines Entwicklungsprozesses ist es m glich dass ein System mehreren Modi fikationen ausgesetzt wird Es ist auf dem Weg zu einem realistischen System in einer ebenso realistischen also unter Umst nden fehlerbehafteten Umgebung nicht immer von Anfang an in vollem Umfang bekannt wie ein System angepasst werden muss Es sind stattdessen mehrere Iterationen m glich Eine Komponente wird ver ndert was die Modifikation einer anderen Kom
133. eit vorgesehen sein um Fehlermeldungen zu bertragen oder um Reaktionen auf Fehlermeldungen beispielsweise einen Neustartbefehl auszugeben Eine Modifikati 4 1 MODIFIKATION DER SCHNITTSTELLE 77 on der Schnittstelle muss also im Rahmen eines Entwicklungsprozesses m glich gemacht werden In diesem Abschnitt stellen wir dazu die formalen Grundlagen bereit Wir betrachten nur Modifikationen der Schnittstelle zur Entwicklungszeit des Systems also im Rahmen einer Systementwicklung Ver nderungen der Schnittstelle zur Laufzeit des Systems wie dies in mobilen und dynamischen Systemen 32 B0 29 geschieht sind nicht Gegenstand unserer Untersuchungen Wir gehen im folgenden wie in Abschnitt B 3 von einem System mit der Schnitt stelle I O aus wobei Leise O 01 Om Das Verhalten von S sei durch eine Relation R gegeben Wir unterscheiden in den n chsten beiden Abschnitten die Erweiterung der Schnittstelle von der Einschr nkung der Schnittstelle W hrend wir eine Erweiterung als Entwicklungsschritt formal un terst tzen werden wir die Einschr nkung unter Angabe von Gr nden nicht zulassen 4 1 1 Erweiterung der Schnittstelle Eine Erweiterung der Schnittstelle eines Systems kann sich in vier Varianten auspr gen Diese im folgenden kurz beschriebenen vier Varianten lassen sich durch Beispiele moti vieren die ihre Relevanz in konkreten Entwicklungsszenarien zeigen e Die Schnittstelle wird um einen neuen Eing
134. elder identifizieren Wir haben sie weitgehend im Einklang mit der in der Fachliteratur aufzufindenden Terminologie zun chst informell charakterisiert Ein berblick ber die relevanten Ans tze und den Stand der Technik zur forma len Fehlermodellierung macht Defizite in diesem Gebiet deutlich Oben genannte Fehlerbegriffe sind nicht oder nur unzul nglich formal definiert und die Ans tze sind in ihrer Ausdruckskraft eingeschr nkt Sie bieten wenig methodische Un terst tzung eines Entwicklungsprozesses und keine pragmatischen Beschreibungs techniken zur Spezifikation fehlerbehafteter Systeme Damit motiviert sich der allgemeinere und umfassendere formale Ansatz der mit dieser Arbeit verfolgt wurde Als Grundlage f r einen pr zisen und formalen Umgang mit Fehlern haben wir die Methodik Focus ausgew hlt Sie bietet alle Voraussetzungen die zur Ent wicklung der wichtigen Systemklasse der verteilten reaktiven Systeme notwendig sind Die verschiedenen Beschreibungstechniken die kompositionale Semantik die m chtigen Verfeinerungsbegriffe die vorhandenen Beweistechniken und ein bereits verf gbares Werkzeug machen FOCUS zu einem guten Ausgangspunkt um es zu sammen mit den hier pr sentierten Erweiterungen auch in der Praxis einzusetzen Um diese Arbeit auch Lesern ohne Vorkenntnisse ber die Methodik Focus zug nglich zu machen haben wir in Kapitel Blalle Aspekte von Focus die f r diese Arbeit relevant sind kurz vorgestellt und
135. emverhalten nicht durch die Fehler beeinflu t es liegt also maskierende ansonsten nicht maskierende Fehlertoleranz vor Kann ein System von beliebigen Zust nden aus wieder in Normalzust nde zur ckfinden 28 KAPITEL 2 DER FEHLERBEGRIFF nennt man dies global stabilisierendes System ansonsten nur lokal stabilisierend Ein global stabilisierendes System ist ein selbst stabilisierendes System vergleiche Abschnitt RIJ In ihren Arbeiten nutzen die Autoren ihren Ansatz um sogenannte Detektoren und Korrektoren als notwendige Bestandteile fehlertoleranter System charakterisieren zu k nnen W hrend Detektoren das Auftreten von Fehlern aufdecken f hren Korrekto ren nach der Fehlererkennung das System wieder in einen fehlerfreien Zustand zur ck Detektoren sind die minimale Voraussetzung f r Fehlertoleranz mit der fail stop Ver halten erreicht werden kann Dabei wird beim Auftreten von Fehlern ein System an gehalten Mit Korrektoren k nnen stabilisierende Systeme konstruiert werden Sind beide Bestandteile f r ein Fehlermodell verf gbar kann maskierende Fehlertoleranz er reicht werden In 42 besch ftigen sich die Autoren mit dem automatischen Erg nzen von Mechanismen der Fehlertoleranz f r fail stop maskierender und nicht maskierender Fehlertoleranz mit Untersuchungen der Komplexit t dieser Algorithmen Bewertung der Ans tze Alle Autoren gehen von Systemspezifikationen aus die als korrekt definiert werden In keinem der Ans
136. en diagrammen muss bei seiner Formulierung ein angemessener Kompromi zwischen einer spezifischen starken und einer allgemeinen aber daf r schwachen Aussage gew hlt werden Jeder neue Knoten muss wieder alle Eigenschaften erf llen die in einem Fort schrittsdiagramm von den Knoten gefordert werden Insbesondere m ssen also alle Transitionen wieder in bestehende Knoten f hren und immer muss mindes tens eine ausgehende Transition schaltbereit sein Alternativ ist es auch m glich die Fortschrittseigenschaft abzuschw chen zu Y V 1 Das Erg nzen eines neuen Knotens kann noch weitere neue Knoten erfordern 5 7 WIEDERVERWENDUNG VON BEWEISEN 151 PA T3 1 TA an pe cin A c 2 en T2 Ti T2 T1 71 T2 o gt k Abbildung 5 10 Erweitertes Fortschrittsdiagramm f r Merge Das Erweitern der Transitionsmenge eines Systems korrespondiert mit einer Erweite rung des Fortschrittsdiagramms Das urspr ngliche Beweisdiagramm kann damit als Teildiagramm vollst ndig wiederverwendet werden solange die Fortschrittseigenschaft unver ndert erhalten bleibt Beispiel 5 9 Anpassung des Fortschrittsdiagramms von Merge Die Komponente Merge gibt alle Nachrichten die ihr ber die beiden Eingabekan le zugesen det werden auch wieder aus Diese Fortschrittseigenschaft wurde mit Hilfe des Diagramms in Abbildung BJ gezeigt Wir wollen nun die Auswirkungen der Modifikation aus Beispiel
137. en Fehlerzustand genau dann wenn in diesem Zu stand W gilt also a Error Buffer 2 73 lt aY 130 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN Korrektheit folgt daraus unmittelbar Lebendigkeit zeigt sich mit der Wahl j k so dass das erste Disjunktionsglied erf llt ist Mit k 1 ergibt sich sofort die Disjunktion der Stabilit tsaussage Den Beweis von kann man auf das Invariantendiagramm in AbbildungB 3labst tzen Daran ist einerseits erkennbar dass nach der Ausf hrung der Fehlertransition 73 das Pr dikat erf llt ist und dass dieses andererseits auch nur durch Ausf hrung von 73 wahr wird Es liegt uns hier wiederum ein Beispiel vor das die Erweiterung von Beweisdiagrammen bei nachtr glich modellierten Fehlern illustriert F r den fehlerfreien Fall ohne die Ausf hrung der Transition 73 zeigt das Diagramm die Aussage Buffer IF inv z q In anderen Ans tzen wie zum Beispiel in 47 48 wird Fehlererkennung vereinfacht indem alle Fehlertransitionen in F eine boolesche Variable f von false auf true set zen m ssen Wurde eine Fehlertransition ausgef hrt ist dies unmittelbar am Wert von f erkennbar Gegen diesen Ansatz sprechen einige Argumente Zum einen ist es im allgemeinen praktisch nicht m glich auftretende Fehlertransitionen sofort durch das System selbst erkennen zu lassen Beispielsweise ist der Verlust von Daten auf einem bertragungskanal nicht ohne spezielle Mechanism
138. en Fall Modifiziert beispielswei se M die Eingabekan le aber Ma die Ausgabekan le so ist M nur durch die Variante darstellbar die beide Kanaltypen modifiziert 4 5 2 Fortpflanzung von Modifikationen Wird ein System modifiziert so hat dies selbstverst ndlich auch Auswirkungen auf die Umgebung des Systems Zeigt das System neues Verhalten so wird die Umgebung mit neuem Verhalten darauf reagieren zeigt das System im Gegenteil ein bestimmtes Ver halten nicht mehr wird auch die Umgebung ein entsprechend anderes meist reduziertes Verhalten aufweisen Da wir nderungen im Verhalten von Systemen durch Modifikationen ausdr cken k n nen sind wir in der Lage die Auswirkungen der Modifikation eines Systemteils erneut als Modifikation des Gesamtsystems auszudr cken Wir gehen im folgenden entspre chend Abbildung 4 5 von einem zusammengesetzten System aus das aus zwei Kom ponenten S und S2 besteht d h S 518 5 Aufgrund der Eigenschaften unseres Systemmodells sind wir durch die Abst tzung der folgenden Definition auf nur zwei Komponenten keineswegs in der Anwendbarkeit ein geschr nkt da sich beliebig viele Komponenten immer durch eine Komponente aus dr cken lassen die aus ihnen zusammengesetzt wird So kann S4 tats chlich nur eine 4 5 EIGENSCHAFTEN VON MODIFIKATIONEN 107 I 5 ce L S S Abbildung 4 5 Zusammengesetztes System Komponente sein w hrend S2 die
139. en Fehlern in einem System da Fehler unter Umst nden nicht eindeutig lokalisiert und damit auch nicht sinnvoll quantifiziert werden k nnen 4 3 2 Fehlzustand Weist ein System einen Fehler auf so kann dieser in einem Ablauf eines betroffenen Systems eine Wirkung haben und zwar sowohl auf interne Zust nde als auch auf das nach aussen sichtbare Verhalten Nach aussen sichtbares Fehlverhalten werden wir noch unter dem Begriff Versagen diskutieren Die Sichtbarkeit ist in unserem Systemmodell durch die Festlegung der Schnittstelle jedes Systems gegeben Die in J O enthaltenen Kan le sind sichtbar w hrend andere Bestandteile systemintern und f r die Umgebung unsichtbar bleiben Die Beschreibungstechnik der Black Box Sichtweise wie auch die Modifikationskompo nenten nehmen keinerlei Bezug zu Interna von Systemen Daher k nnen mit ihnen keine internen Zust nde eines Systems und somit auch keine Fehlzust nde charakterisiert wer den Mit dem Formalismus der Transitionssysteme steht uns aber eine weitere Sicht auf 94 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Systeme zur Verf gung mit dem Zust nde und damit auch Fehlzust nde angemessen dargestellt werden k nnen Wir definieren Fehlzust nde als die Zust nde in einem Sys temablauf die nur unter Verwendung von Fehlertransitionen aus F mit M E F erreicht werden k nnen Definition 4 8 Fehlzustand Sei ein Transitionssystem S und eine Modifikation M E F gegeben Die Men
140. en Modifikationen fordern um die Kombination von Modifikationen zu erleichtern Beispiel 4 3 Da das modifizierte System MergeA M nur noch die Nachrichten eines der bei den Eingabekan le ausgeben soll m ssen wir alle Str me entfernen in denen auf o Nachrichten von Kanal i und i2 vorkommen Das modifizierte System zeigt kein neues Verhalten so dass keine neuen Stromtupel erg nzt werden m ssen Wir definieren die Modifikation also zu M E wobei E alle Tupel enth lt deren Ausgabestr me sowohl Daten mit dem Index 1 als auch mit dem Index 2 enthalten E di di di da dj dy di d2 di di dy J d2 dy dy 3 d2 d1 di di di J d2 d3 dy d di d2 J da d3 dy dz d di d di dy 4 2 MODIFIKATION DES VERHALTENS 85 Das Beispiel macht erneut deutlich dass die explizite Angabe von Relationen durch Auflistung nicht geeignet ist um konkrete Systeme und ihre Modifikationen zu definie ren Wir geben im folgenden geeignetere Beschreibungtechniken an 4 2 2 Modifikationen von Black Box Spezifikationen Eine Black Box Spezifikation kann im wesentlichen auf zwei Arten modifiziert werden Die durch beschriebene Eigenschaft kann durch Hinzunahme weiterer Eigenschaften verst rkt werden und sie kann durch Anbieten von alternativen Eigenschaften abge schw cht werden Die Verst rkung kann durch eine Konjunktion
141. en Verst ndnis und k nnen einen bewu teren Umgang mit Fehlern und ihren spezifischen Eigenschaften erm glichen Fehler k nnen nur relativ zu einer als korrekt und damit fehlerfrei akzeptierten Fassung eines Systems definiert werden Liegt ein korrektes System S und seine fehlerbehaftete Version vor ist der Fehler als der Unterschied zwischen diesen beiden Fassungen beschrieben wenn auch nur sehr implizit Der Fehler selbst w re so noch nicht direkt formal greifbar Der Unterschied kann alle Merkmale eines Systems betreffen wobei Un terschiede im Verhalten im Vordergrund stehen Wir werden noch genauer differenzieren zwischen Unterschieden statischer Systemanteile Unterschiede in der Schnittstelle und Unterschiede im Verhalten eines Systems Wir interpretieren Fehler eines Systems explizit als die Modifikation die aus der fehler freien Version die fehlerbehaftete macht Eine derartige Modifikation erlaubt es damit von einer idealisierten Sicht auf ein System zu einer realistischen und damit implemen tierungsn heren Sicht bergehen zu k nnen Die formale Definition von Fehlern eines Systems erlaubt eine Unterscheidung von Sys temverhalten in drei disjunkte Klassen die in Abbildung I dargestellt sind In der Mehrzahl typischer formaler Ans tze wird nur das intendierte Verhalten eines Systems untersucht und spezifiziert Bei der Ber cksichtigung von Fehlern wird zus tzliches Sys temverhalten in die formale Behandlung mit ein
142. en des Systems w hrend der Ausnahmebehandlung zu deaktivieren Eine Ausnahmebehandlung wird mit einem Transitionssystem verkn pft indem zwei Pr dikate W und definiert werden Dabei beschreibt Y einen Fehler oder Ausnah mezustand in dem die Ausnahmebehandlung gestartet werden soll w hrend die Zust nde des Systems charakterisiert in die nach der Ausf hrung der Ausnahmebe handlung zur ckgesprungen wird Formal k nnen wir dies folgenderma en definieren Definition 5 1 Ausnahmebehandlung in Transitionssystemen Seien ein Transitionssystem S I O A T T mit xp A und type xp true false sowie zwei Pr dikate W und gegeben Eine Ausnahmebehandlung wird durch eine Transitionsmenge C und die zwei Zustands pr dikate Entry und Exit definiert Dabei gelte v a 8 E C a zp A p E zp Die Erweiterung von S um die Ausnahmebehandlung die bei G ltigkeit von Y gestar tet wird und die nach Ausf hrung in einen Zustand zur ckspringt f r den gilt ist definiert durch SA E F mit F CU a B PsEmwnra FV i E Entry AVB e Agree a 3 C Agree a 3 U a 8 BEaAaspAak ExitNBE AV 3 o Agree a 3 C Agree a P E a 8 of ap U a 8 ako Dabei sei xp in diesem System mit false initialisiert 136 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN Diese Definition bedarf einer Erl uterung Die Variable xp wird beim Eintritt in die Aus nahmebeha
143. en erkennbar Zum anderen k nnen Fehlertransitionen ausgef hrt werden ohne dass dies unbedingt zu einem Fehlerzu stand f hrt So kann in bestimmten Situationen die Wirkung einer Fehlertransition von einer normalen Transition nicht zu unterscheiden sein wenn beispielsweise der Wert von Variablen ver ndert wird die ohnehin ohne weiteren Lesezugriff neu berschrieben werden Dennoch kann es n tzlich sein eine fehleranzeigende Variable f einzuf hren die bei der Verifikation genutzt werden kann um beispielsweise die Korrektheit eines Fehler erkennungspr dikates zu beweisen Sie geh rt aber nicht zu den Variablen auf die das System selbst zugreifen kann darf also nicht Teil von W sein Eine pragmatische Realisierung von fehlererkennenden Pr dikaten im Rahmen konkre ter Programmiersprachen wird in 55 diskutiert Darin wird gezeigt wie die G ltigkeit von Invarianten und Vor und Nachbedingungen von Prozeduraufrufen mit program miertechnischen Mitteln berwacht wird und wie auf Verletzungen geforderter Eigen schaften mit Hilfe von Exceptions reagiert werden kann Definiert man ein fehlererken nendes Zustandspr dikat Y bereits auf der abstrakten Ebene des Transitionssysteme kann es sowohl formal auf Korrektheit Stabilit t und Lebendigkeit untersucht werden als auch mit den programmiersprachlichen Techniken konkret in einer Implementierung verwendet werden 5 4 Einf hrung von Fehlermeldungen Eine einfache m gliche Reaktion
144. en springt das System in den Fangzustand von dem aus keine Transitionen mehr m glich sind so dass insbesondere keine Ein und Ausgaben mehr stattfinden Damit bleiben automatisch alle Sicherheitseigenschaften des Systems erhalten Der Sprung in den Fangzustand muss von allen erreichbaren Zust nden des Systems m glich sein In einer graphischen Repr sentation eines Systems stellt sich wie in Ab bildung 5 4Ja der Fangzustand als ein neuer Knoten f dar Zu diesem f hren von allen anderen Knoten des Systems jeweils eine Transition w hrend von ihm keine Transition mehr ausgeht F r kleinere Systeme ist diese Darstellung sehr intuitiv F r gro e kom plexe Systeme mit zahlreichen Kontrollzust nden ist diese Darstellung allerdings nicht 134 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN gut geeignet da viele neue Kanten erg nzt werden m ssen Wir k nnen den Sprung in einen Fangzustand auch sehr kompakt als Modifikation M ausdr cken Wir ben tigen dazu eine neue boolesche Variable trap die initial den Wert false besitzt f r die also gelten soll Y trap Wird ein Fehler durch ein Pr dikat erkannt soll vollkommen unabh ngig vom Zustand des Systems in den Fangzustand gesprungen werden Dies wird erreicht durch eine Modifikation mit Name Pre Input Output Post F Ttrap U trap Der Sprung in den Fangzustand soll sofort erfolgen wenn der Fehler entdeckt wurde Daher sind jene Transitionen zu entfernen die es erlaub
145. en wiirden dass das System weiterarbeitet obwohl der Fehler bereits entdeckt wurde Da auch im Fangzustand das Pr dikat W wahr bleibt ist sichergestellt dass keine Transitionen von ihm ausgehen Es ist also ausreichend die folgenden Transitionen zu entfernen E a 8 a U Damit beschreibt der Ausdruck SA E F f r jedes System S mit dem Fehlerpr dikat Y das System das bei Auftreten eines an Y erkennbaren Fehlers seine Aktivit t einstellt Die sogenannten fail safe Systeme lassen sich mit dieser Technik modellieren Im Unterschied zu Fehlermodellen wie crash failure und fail stop failure die den Halt des Systems bereits mit enthalten wird hier bewu t der Sprung in den Fangzustand als Reaktion auf einen beliebigen durch Y charakterisierbaren Fehler gew hlt Neustart des Systems In Abbildung B 4b wird der Neustart eines Systems bei einem auftretenden Fehler dargestellt Wird ein Fehler durch Y erkannt wird in einen Startzustand s gesprungen Soll diese Fehlerbehandlung graphisch repr sentiert werden gelten die gleichen Vor und Nachteile wie beim Sprung in den Fangzustand W hrend die graphische Darstel lung bei kleineren Systemen sehr intuitiv ist wird sie bei komplexen Systemen schnell un bersichtlich Da es mehrere Knoten geben kann die Startzust nde darstellen ist es hier sogar n tig von jedem Knoten des Systems eine Transition zu jedem Startknoten zu erg nzen Ein Neustart ist durch eine Modifikation erneut
146. ene L sung So k nnen Fehler in Einzelkomponenten nicht immer auf lokaler Ebene maskiert werden sondern setzen sich in ihrer Wirkung in andere Komponenten und schlie lich im Gesamtsystem durch Sie m ssen dann auch im Rahmen einer abstrak ten systemglobalen Sicht ber cksichtigt werden und entsprechend bei einer formalen Beschreibung der Systeme mit erfa t werden Die Aufnahme und Ber cksichtigung von Fehlern stellt damit einen wichtigen Schritt dar von einer idealisierten fehlerfreien Welt hin zu einer realen Welt mit potentiellen Fehlern Auch dieser Schritt muss im Rahmen einer formalen Systementwicklung mit unterst tzt werden 157 158 KAPITEL 6 ZUSAMMENFASSUNG UND AUSBLICK Mit den in dieser Arbeit pr sentierten Modellierungs und Entwicklungstechniken lie gen alle wesentlichen Grundlagen hierf r vor Der Fehlerbegriff und die damit zusam menh ngenden Konzepte aus seinem thematischen Umfeld wurden formal fundiert und zusammen mit methodischen Hinweisen in die Methodik FOCUS eingebettet Wir geben hier einen berblick ber die wichtigsten Beitr ge dieser Arbeit mit ihren jeweiligen Konsequenzen Um sinnvolle und ad quate Fehlerbegriffe zu definieren haben wir in KapitelP die in der Literatur auffindbaren Interpretationen dieses Begriffes diskutiert und ver schiedene Klassifikationen dargestellt Es lie en sich die Begriffe der Fehlerursa che des Fehlerzustandes und des Versagens als die drei wesentlichen Begriffsf
147. er Komponente quantitativ auszudr cken wobei aber die Kausalit t dennoch sichergestellt bleibt Wir be schr nken uns damit auf eine abstrakte Darstellung von Systemen indem wir alle 3 11 ZUSAMMENFASSUNG 73 Varianten von Verhalten zusammenfassen die sich nur in ihrem konkreten Ablauf in der Zeit unterscheiden Wir wollen uns in dieser Arbeit mit der Modellierung von Fehlern besch ftigen Auftretende Fehler k nnen im allgemeinen neben einer Ver nderung des Verhal tens auch eine Ver nderung in der Zeit bewirken Diese Aspekte sind in einer vollst ndigen Behandlung von Fehlern selbstverst ndlich zu ber cksichtigen im plizieren aber eine zus tzliche Komplexit t in der Behandlung F r die Erarbei tung der grundlegenden Techniken im Umgang mit Fehlern im Rahmen dieser Arbeit wollen wir uns hier aber auf das ungezeitete Systemmodell beschr nken um die Modellierung von Fehlern zun chst relativ einfach darstellen zu k nnen Daher fokussieren wir in dieser Arbeit zun chst auf die Auswirkungen von Fehlern ohne Ber cksichtigung zeitlicher Aspekte und regen eine weiterf hrende Untersu chung in Kapitel J an e Im asynchronen Modell erfolgt die Kommunikation zwischen zwei Komponenten so unabh ngig wie m glich Das Senden einer Nachricht ist zu jedem Zeitpunkt m glich und vom Empfangen der Nachricht entkoppelt Es gibt keine Garantien wann und ob die Nachricht vom Empf nger gelesen wird Sichergestellt ist nur dass der Empfang
148. er Str men betrachten Typischerweise beschreibt man eine Relation durch eine Formel die die Elemente charakterisiert die in der Relation enthalten sind Diese Beschreibungstechnik verwenden wir auch f r unsere Verhaltens spezifikationen Eine Black Box Spezifikation beschreibt das Verhalten eines Systems durch ein Pr dikat Wir gehen von einem System aus f r das die Schnittstelle bereits definiert sei In dem Pr dikat d rfen die Bezeichner f r die Kan le des Systems als freie Variable vorkommen Das Pr dikat charakterisiert dann diejenigen Tupel von Ein und Ausgabestr men f r die das Pr dikat wahr wird wenn man die Kanalbezeichner durch die Str me ersetzt die auf ihnen empfangen bzw gesendet werden Definition 3 4 Black Box Spezifikation Eine Black Box Spezifikation eines Systems mit der Schnittstelle I O besteht aus einem Pr dikat das Variablen aus TU O als freie Variablen hat d h free C IUO Das Pr dikat beschreibt die Menge aller Ein und Ausgabestr me die dieses Pr dikat erf llen KB E m 6 3 5 BLACK BOX SPEZIFIKATIONEN 45 Es ist m glich ein Pr dikat zu definieren das nicht konsistent nicht linkstotal oder auch nicht kausal ist Das Pr dikat beschreibt in einem solchen Fall kein realisierba res Verhalten und es gibt kein konkretes implementiertes System dessen Ein und Ausgabestr me das Pr dikat erf llen k nnten Die Konsistenz und Kausalit t muss bei Bedarf durch
149. er der Baum aufgebaut wird Die Wurzel des Entwicklungsbaumes enth lt eine abstrakte Black Box Spezifikation die das Verhalten des gesamten Systems be schreibt Diese Spezifikation wird typischerweise pr zisiert durch die Hinzunahme wei terer Anforderungen und das F llen von Entwurfsentscheidungen zu einer Spezifikation Eine strukturelle Verfeinerung hat als Ergebnis eine Reihe von Unterspezifikationen 1 Dazu geh rt eine in der Abbildung nicht dargestellte Verschaltung die die Kan le zwischen den Komponenten und damit die m glichen Interaktionen beschreibt Die Komponenten selbst k nnen wieder weiter in ihrem Verhalten ihrer Schnittstelle oder ihrer Struktur verfeinert werden Da die Komposition und der Nachweis einer Verfeinerung auf der Ebene der Black Box Spezifikationen relativ leicht durch einfache Konjunktionen und Implikationen auszu 3 11 ZUSAMMENFASSUNG 71 Verhaltens Schnittstellen verfeinerung Black Box Spezifikationen p Strukturelle Verfeinerung s vex by Eigenschaftsnachweise Transitionssysteme er Si los oS vice Sa Abbildung 3 11 Idealisierter Entwicklungsproze dr cken ist empfiehlt es sich die Systembeschreibungen m glichst lange auf diesem Abstraktionsniveau zu halten Letztendlich sollten die Komponenten aber implemen tierungsn her durch Transitionssysteme
150. erade in Bezug auf Fehlertoleranz eine Rolle spielt Janowski argumentiert dass man sich bei Aussagen ber Fehlertoleranz nicht auf das Auftreten von Fehlern verlassen darf Fehler k nnen auftreten m ssen es aber nicht Er fordert den Nachweis dass ein fehlertolerantes System die Toleranzspezifikation nicht nur bei Auftreten von Fehlern erf llt sondern auch dann wenn Fehler nicht oder nur teilweise auftreten In den Arbeiten der genannten Autoren werden Fehler in einem System nur durch zus tzliche Transitionen modelliert das Entfernen von Transitionen wird nicht zugelassen Zus tzliche Transitionen spiegeln tats chlich einen tempor ren 100 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Charakter von Fehlern besser wider Die Fehlertransitionen k nnen zwar jederzeit aus gef hrt werden wenn sie schaltbereit sind sie m ssen aber nicht schalten Das System kann also immer noch ein fehlerfreies Verhalten zeigen und der Nachweis der Fehlerto leranz umfa t wie gefordert auch immer alle Abl ufe in denen Fehler nicht auftreten Modifiziert man ein System nur durch Hinzuf gen von neuen Transitionen also durch eine Modifikation E F mit E so ist auch mit unserer Definition von Fehlerto leranz sichergestellt dass das Auftreten von Fehlern in allen Abl ufen nicht postuliert wird Der Ansatz dieser Arbeit stimmt also in diesem Fall mit den Techniken der ge nannten Ans tze berein Es ist uns jedoch zus tzlich m glich du
151. eren Ein Fehlerzustand wird meist verstanden als ein Zustand des Systems der vom eigentlich erw nschten Systemzustand abweicht Ein falscher Wert einer Variable falsche Daten in einem Datenbankeintrag oder ein falscher Kontrollzustand sind Beispiele f r Fehlzust nde Ein Fehlzustand kann mu aber nicht zu einem Systemversagen f hren Wird ein falscher Wert an Stelle eines korrekten ausgegeben oder ergibt sich durch einen anderen Kontrollzustand ein nach au en sichtbares ver ndertes Verhalten so liegt tats chlich ein Versagen vor Wird jedoch ein falscher Wert durch einen korrekten Wert ber schrieben bevor ersterer Wirkung zeigen konnte kann der vor bergehend vorliegende Fehlerzustand nicht zu einem Versagen f hren Fault Als Fehlerursache engl fault bezeichnet man den Grund der aus einem System ein fehlerhaftes macht Die Fehlerursache ist der eigentliche Unterschied zwischen einem fehlerhaften System und seiner korrekten Fassung Dieser Defekt kann auf allen Ebenen in beliebigen Bestandteilen des Systems liegen Es k nnen Unzul nglichkeiten in der Hardware oder Software oder und im Design eines Systems sein in der Beschreibung der Anforderungen in der Spezifikation in der Implementierung in den Umgebungsan nahmen und allen anderen Aspekten eines Systems Die Klassifikation im n chsten Ab schnitt zeigt die vielf ltigen Auspr gungen in denen Fehlerursachen auftreten k nnen Die Differenzierung zwischen Fehlerzusta
152. erge definiert die nur noch von einem Kanal liest und den anderen ignoriert Wir ermitteln nun welche Auswirkung die Anderung von Merge auf das zusammengesetzte System Multipler hat bei unmodifizierter Komponente Split Die Modifikationen der Komponenten lauten also M Merge false o iuVo i2 M sput true false Die noch weiter zu vereinfachende zusammengesetzte Modifikation M M merge M spuit ergibt sich nach Definition AM zu M false A true false V Di o 01 A Do 02 A 0 i V o i2 V false Wir m ssen nun nicht die Modifikationen der Einzelkomponenten einzeln anwenden sondern k nnen diese kombinierte Modifikation unmittelbar auf die Eigenschaft des Gesamtsystems anwenden und erhalten PAM F false v Di o 01 A Do 02 A 0 i V 0 i2 Aus dem ersten Fall o i der darin enthaltenen Disjunktion k nnen wir D o o ableiten und daraus sowohl 0 Di o o als auch D8 o o2 unter Ausnutzen der Disjunktheit von D und D Mit einem hnlichen Argument f r den zweiten Fall k nnen wir schlie lich f r Multiplex mit dem modifizierten Merge die zu erwartende Eigenschaft herleiten dass nur auf genau einem der beiden Ausgabekan le Nachrichten ausgegeben werden o i A 02 V 02 ig A 01 110 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN 4 5 3 Korrespondierende Modifikationen Im vorherigen Abschnitt ber die Fortpflanzung von Modifikationen wurde behandelt
153. ermanent im System enthalten sind und versehentlich eingef gt wurden und e Fehler in der Daten bertragung die einen physikalischen Ursprung haben zur Laufzeit und nur tempor r auftreten und auch nicht absichtlich verursacht wur den Klassifikation von Versagen F r das Versagen failure von Systemen oder Komponenten finden sich Klassifizie rungen in 23 27 43 62 die hier zusammengefa t dargestellt werden Ein Versagen ist eine von au en beobachtbare Abweichung des Verhaltens von der Erwartung Wir unterscheiden nach der Art wie das Verhalten abweicht klassifizieren nach den Aus wirkungen und der Einheitlichkeit der Beobachtbarkeit Art Man kann unterscheiden zwischen wert und zeitbezogenen Versagen von Syste men Bei wertebezogenen Ausf llen werden Leistungen zwar zum richtigen Zeit punkt erbracht aber die Ergebnisse sind nicht korrekt Ein Beispiel daf r ist ein value failure bei dem ein falscher Wert als Resultat geliefert wird Zeitbezogenes Versagen liegt vor wenn zeitliche Bedingungen nicht eingehalten werden Man kann hier au erdem die beiden F lle des early und late timing unterscheiden Die Klasse der omission oder response failures l t sich nicht eindeutig als wert oder zeitbezogenes Versagen bezeichnen da das Ausbleiben eines Ergebnisses so wohl als falscher Wert als auch als ein extrem versp tetes Ergebnis interpretiert werden kann Ein Totalversagen beschreibt den v lligen Ausfall eines Systems
154. esem System also sichergestellt dass die L nge des Ausgabe stroms schlie lich die L nge erreichen wird blicherweise h ngt von den Eingaben ab hat also Elemente aus I als freie Variablen Zum Nachweis dieser Aussage eignet sich folgende Regel die die Existenz einer zielf h renden Transition fordert die schaltbereit ist und die Ausgabe tats chlich verl ngert Aufgrund der Fairness in unserem Systemmodell wird diese Transition also tats chlich einmal ausgef hrt und damit die Ausgabe wie gefordert verl ngert Der Beweis der Regel findet sich wieder in TO F r eine Transition 7 T o k k lt L gt En T und o k nk lt lAT gt H 0 gt k Sl 0 k k lt l 0 gt k In den Anwendungsbeispielen in 0 IT 72 T3 haben sich Aussagen zur Invarianz und zur Ausgabeverl ngerung als ausreichend erwiesen um die interessanten Eigenschaf ten eines Transitionssystems auszudr cken W hrend mit Invarianten die Korrektheit der ausgegebenen Nachrichten formalisiert wird gibt die Aussage ber die Ausgaben verl ngerung an dass ausreichend viele Ausgaben gemacht werden Beispiel 3 10 Eigenschaften von Merge Wir greifen wieder das System Merge auf Als Invariante formulieren wir die Aussage dass in jedem Zustand in jedem Ablauf des Systems genau so viele Daten ausgegeben sind wie auf den beiden Eingabekan len bislang konsumiert wurden Merge IF inv 0 i Im n chsten Abschnitt werden wir die G ltigkeit dieser
155. ezifikationen wird die Linkstotalit t oft durch die Verwendung des Assumption Guarantee Formates erreicht bei Transi tionssystemen ist die Linkstotalit t automatisch sichergestellt Auch die Komposition mit Modifikationskomponenten erh lt die Linkstotalit t Dennoch kann ein Teil der Ausgaben unerw nscht sein obwohl er in der verhaltensbe schreibenden Relation vorkommt Existieren n mlich Umgebungsannahmen die genau die Eingaben ausschlie en die zu den unerw nschten Ausgaben f hren wird das Sys tem diese Ausgaben nie zeigen Wird eine Komponente beispielsweise in einem Kontext verwendet der bestimmte Eingaben f r das System nie produzieren wird darf die Re aktion dieser Komponente auf diese Eingaben sogar beliebig sein ihre Spezifikation wird damit nicht gef hrdet wenn sie nur Aussagen macht ber die Reaktion auf eine Teilmenge der erlaubten Eingaben Diese Umgebungsannahmen sind damit die wesentliche Voraussetzung um ber Feh ler der Systemumgebung sprechen zu k nnen Die Systemumgebung kann nur Fehler machen wenn gewisse Anforderungen an sie gestellt werden Diese Forderungen an die Umgebung k nnen explizit oder implizit definiert sein Wir behandeln im folgenden beide F lle 4 6 1 Explizite Umgebungsannahmen Eine Umgebungsannahme nennen wir explizit wenn sie beim Entwurf des Systems vom Entwickler identifiziert und dokumentiert wird Dies geschieht wenn erkennbar ist dass das System nur in einem entsprechenden
156. f r Systembeschreibungen auf verschiedenen Abstraktionsebenen eignen Der bergang zwischen den Ebenen basiert auf einer Verifikationtechnik deren Beweise mit Beweisdiagrammen visualisiert werden k nnen Schliesslich beschreiben wir das Konzept der Verfeinerung und einen ideali sierten Entwicklungsproze Dieses Systemmodell sieht die explizite Modellierung von Fehlern noch nicht vor In Kapitel N erweitern wir das Systemmodell um sogenannte Modifikationen M Mit diesen ist es m glich eine Ver nderung sowohl von Schnittstellen als auch von System verhalten zu beschreiben darstellbar mit Hilfe beider Beschreibungstechniken F r ein System S beschreibt SAM das ver nderte System Damit steht ein geeigneter Forma lismus bereit mit dem Fehler als Abweichung eines Ist von einem Soll und verwandte Begriffe formal definiert werden Dar ber hinaus werden in diesem Kapitel Kombinatio nen von Modifikationen und ihre Eigenschaften untersucht und die Modellierung von externen Fehlern dargestellt Um Nutzen aus einer formalen Methodik ziehen zu k nnen ist neben einer Sprache zur Darstellung von Systemen und ihren m glichen Fehlern auch ein zweckm iger zielge richteter Umgang erforderlich In Kapitel BJwerden methodische Hinweise zum Umgang mit Fehlern gegeben Wir erl utern wie pr zise Fehlermodelle auch von zusammen gesetzten Systemen formuliert und mit welchen Techniken Fehler im Rahmen unseres Fehlermodells erkannt gemeldet und kor
157. fikationen gew hlt so dass das ver nderte System die ver nder ten Eigenschaften aufweist so ist man an einer passenden Ver nderung des Be weisdiagrammes interessiert Wir haben in Kapitel 5 7 sowohl f r Invarianten als auch f r Fortschrittsdia gramme Techniken erarbeitet mit Hilfe derer die Diagramme bei Modifikationen der Eigenschaften oder Systeme entsprechend angepa t werden k nnen Ein nicht unerheblicher Anteil der Diagramme bleibt dabei unangetastet so dass die zu geh rigen Beweisverpflichtungen bernommen und nicht neu nachgewiesen wer den m ssen Eine Systementwicklung l t sich im wesentlichen als ein Baum darstellen mit einer abstrakten Systemspezifikation als Wurzel verfeinerten Teilkomponenten als Zwischenknoten und einer implementierungsnahen Beschreibung der Kompo nenten als Bl tter Im Laufe eines Entwicklungsprozesses kann es sich nun erge ben dass ein Knoten im Baum modifiziert werden muss Dies kann beispielsweise durch vorherzusehende Fehler oder ver nderte Anforderungen notwendig werden Mit den Techniken die uns mit dieser Arbeit vorliegen ist es m glich ausgehend vom modifizierten Knoten den Baum schrittweise in alle erforderlichen Richtungen nachtr glich anzupassen bis wieder ein korrekter Entwicklungsbaum vorliegt Damit k nnen Fehler oder andere Ver nderungen in einem System auch nach tr glich in einer Systementwicklung ber cksichtigt werden ohne die Entwicklung dabei vollkommen neu b
158. fordert sei ein Pro gramm das f r nat rliche Zahlen n gt 2 die Fakult t berechnet Das Soll ist damit informell definiert Betrachten wir nun das folgende funktionale Programm ausgedr ckt in ML B2 fun fac n int if n 1 then 2 else n fac n 1 Dieses Programm berechnet nicht das geforderte Ergebnis Man spricht intuitiv von einem Fehler im Programm ohne sich dabei unbedingt der verschiedenen m glichen Bedeutungen des Begriffes bewu t zu sein Aber wo liegt der Fehler Der Fehler l t sich nicht eindeutig lokalisieren denn es gibt zwei M glichkeiten zur Korrektur Das Resultat im Terminierungsfall lie e sich durch 1 ersetzen denn 1 1 aber auch die 1 im Konditional der if Anweisung k nnte durch eine 2 ersetzt werden da 2 2 und die Berechnung f r n 1 in der Spezifikation ausgeschlossen wurde Das Problem der Lokalisierung wird noch deutlicher in folgender L sung der Aufgabe fun fac n int if n lt 1 then 1 else fac n 1 fac n 2 Dieses Programm berechnet eine vollst ndige andere Funktion Damit l t sich nicht einmal auf sinnvolle Weise sagen wieviele Fehler dieses Programm enth lt Es gibt eine unmittelbare Ana logie zur nat rlichen Sprache Ist die Aussage eines Satzes nicht korrekt ist dies im allgemeinen nicht auf ein einzelnes Zeichen oder Wort in diesem Satz zur ckzuf hren In den folgenden Abschnitten besch ftigen wir uns vornehmlich mit Fehlerbegriffen aus
159. gebungsannahmen verbunden die die Systemum gebung zu erf llen hat damit das System korrekt funktioniert M chte man das System so weiterentwickeln dass es sich auch in einer Umgebung sinnvoll verh lt die nicht mehr alle Annahmen erf llt muss man seine Robustheit erh hen F r einen entsprechenden Entwicklungsschritt haben wir in Kapitel 5 6 Techniken und Korrektheitskriterien f r verschiedene Arten von Beschreibungstechniken be reitgestellt Damit kann ein System auf formal unterst tzte Weise um Reaktionen auf externe Fehler erweitert werden e Alle vorgestellten Techniken und Konzepte dieser Arbeit wurden durch eine Viel zahl von Beispielen veranschaulicht Damit werden f r den Leser die Definitionen und ihre Verwendung illustriert und alle Resultate verdeutlicht Die Methodik Focus ist als Resultat der vorliegenden Arbeit um einen expliziten Feh lerbegriff mit zugeh rigen Entwicklungstechniken erweitert worden mit dem Systeme und ihre Fehler auf systematische und integrierte Weise modelliert analysiert und be handelt werden k nnen Die in Kapitel L4 genannten Ziele wurden also erreicht Allerdings sind f r die Techniken und Konzepte bislang im wesentlichen gerade die grundlegenden Fundamente gelegt worden die einen gewinnbringenden Einsatz in einer praktischen Systementwicklung zun chst vorbereiten F r einen unmittelbaren Einsatz in einer praktischen Systementwicklung sind weitere Schritte empfehlenswert die wir zusa
160. gef hrdet werden kann Um die Realisierbarkeit von Systemen in unserem Systemmodell sicherzustellen fordern wir von den Relationen die folgenden zwei Eigenschaften Linkstotalit t Ein System zeigt f r jedes Verhalten der Umgebung also f r jede Eingabe eine Reaktion Die verhaltensbeschreibende Relation muss also f r jede m gliche Eingabe ein passendes Element besitzen formal Vied3oe i o eR Monotonie Ein System darf eine einmal ausgesandte Nachricht nicht mehr zur ck nehmen d h verl ngert man eine Eingabe i zu 1 so verl ngert sich auch die Ausgabe oder bleibt unver ndert Vi i 0 0 io ERACE Ai o O ERS gt o0oCo In unserem ungezeiteten Modell stellt dies auch die Kausalit t sicher Haben zwei Eingaben einen gemeinsamen Pr fix 7 so haben auch ihre Ausgaben einen gemein samen Pr fix o f r den auch i o R gilt Dies impliziert dass die Reaktion auf einen Teil der Eingaben wirklich nur durch diesen Teil und nicht durch erst noch zu empfangene Nachrichten bestimmt wird In der Praxis ist ein Nachweis dieser Eigenschaften oft nicht erforderlich da durch die Beschreibungstechniken ihre Erf llung automatisch sichergestellt ist So stellen bei spielsweise die in Abschnitt B 6 beschriebenen Transitionssysteme durch ihre schrittwei se Verl ngerung der Ausgaben die Monotonie sicher Um die Lesbarkeit zu erh hen haben wir die beiden obigen Forderungen in einer ver einfachten Notation ausgedr
161. haftsorientierte Spezifikationstechnik bezeich nen k nnen lassen sich Transitionssysteme als abstrakte Implementierungen begreifen Transitionssysteme f r unser Systemmodell wurden in hnlicher Form in 10 pr sen tiert Die Transitionen werden hier allerdings nicht durch Formeln sondern spezifischer durch Paare von Belegungen definiert Wir motivieren die folgenden Forderungen die an ein Transitionssystem gestellt werden im Anschlu an die Definition Definition 3 5 Transitionssystem Ein Zustandstransitionssystem S wird definiert durch das Tupel S 1 0 4 T T das die folgenden Bedingungen erf llt Die Mengen I und O enthalten die Namen der Ein und Ausgabekan le und definieren damit die Schnittstelle des Systems Die Menge A definiert die zus tzlichen lokalen Variablen des Systems Es gelte a i lienca Die Menge der Startzust nde wird durch die Formel Y charakterisiert free Y C IU OUA Das System hat in einem Zustand zu starten in dem Y erf llt ist Es gelte f r alle i I b EeTAtel s ar c aETABMasBET Die Menge T C VALx VAL enth lt die Menge der Transitionen Sie hat f r alle i I folgende Bedingungen zu erf llen BET gt ai CBI A BA Cai A aoE o A ail Bi d e Be Trasicyin y gt ay eT 3 6 ZUSTANDSTRANSITIONSSYSTEME 49 Die Menge der Umgebungstransitionen T eines Systems wird definiert durch T a B a 4B AYicIoaiC pi Wir w
162. hebung Tritt ein Fehler auf wird mit dieser Technik versucht einen bereits entstandenen Schaden zu ermitteln und diesen zu beheben indem das System in einen Zustand versetzt wird den es ohne die aufgetretenen Fehler h tte erreichen m ssen M glicherweise kann nur eine abgeschw chte Form der Fehlerbehebung erreicht werden bei der nur ein Zielzustand angenommen wird der vom Ideal auf noch akzeptable Weise abweicht So k nnen beispielsweise bei einem berlasteten System zur bertragung von Daten Nachrichtenpakete ver worfen werden Diese Technik ist deutlich effizienter als die r ckw rts gerichtete aber nur in Abh ngigkeit von der konkreten Anwendung und sehr spezifisch ein setzbar Fehlerkompensation Bei der Fehlerkompensation werden Auswirkungen von Fehlern mit Hilfe ausreichender Redundanz sofort vermieden Beispiele sind fehlerkorri gierende Codes zur Daten bertragung und auch RAID 5 Systeme Diese Systeme halten ausreichend zus tzliche Information verf gbar um Fehler nach Lokalisie rung eines entstandenen Schadens sofort zu beheben Die Fehlerkompensation l t sich als Mischform der Vorw rts und R ckw rtsfehlerbehebung interpretieren Alle Techniken zur Fehlertoleranz ben tigen Redundanz in einem System Redundanz wird etabliert durch die Bestandteile eines Systems die bei Fehlerfreiheit des Systems gar nicht notwendig w ren Redundanz kann in vielen Formen auftreten Bei strukturel ler Redundanz werden Komponenten
163. her Bericht SFB 342 2 2 92 A Technische Universitat Miinchen 1993 Broy MANFRED und OTTO SPANIOL Herausgeber Informatik und Kommuni kationstechnik VDI Lexikon Springer 1999 BROY MANFRED and KETIL ST LEN Specification and Development of Interac tive Systems FOCUS on Streams Interfaces and Refinement Monographs in Computer Science Springer April 2001 CRISTIAN FLAVIU A rigorous approach to fault tolerant computing IEEE Trans Software Engineering 1985 CRISTIAN FLAVIU Understanding fault tolerant distributed systems Communi cation of ACM 34 2 56 78 December 1991 DOUGLASS BRUCE POWEL Doing Hard Time Developing Real Time Systems with UML Objects Frameworks and Patterns The Addison Wesley object tech nology series Addison Wesley 1999 Web Seite von FOCUS http www4 in tum de proj focus Web Seite von Formal Methods Europe http www fmeurope org GARTNER FELIX C Specifications for Fault Tolerance A Comedy of Failures Technischer Bericht TUD BS 1998 03 Technische Universitat Darmstadt Oktober 1998 LITERATURVERZEICHNIS 167 28 G RTNER FELIX C Fundamentals of fault tolerant distributed computing in asynchronous environments ACM Computing Surveys 31 1 1 26 1999 29 Grosu RADU and KETIL STOLEN A model for mobile point to point data flow networks without channel sharing In WIRSING MARTIN and MAURICE NIVAT editors AMAST 1996 Algebraic Methodology And Software Technolog
164. hiedene Auspr gungen von Fehlerd mpfung definieren Seien dazu wieder eine Modifikation M einer Teilkomponente bzw der Umgebung und eine Modifikation M des Gesamtsystems gegeben Diese implizieren eine Unterteilung des Verhaltens der fehlerhaften Teilkomponente bzw der Umgebung und des Gesamtsystems in die drei genannten Klassen 102 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Wir k nnen nun jeweils untersuchen in welche Klasse das Systemverhalten f r jede der drei Verhaltensklassen des fehlerhaften Teilsystems einzuordnen ist Es gibt dabei die in der folgenden Tabelle dargestellten M glichkeiten a 2 3a 3b 4 Normal Normal Normal Normal Normal Normal Fehler Normal Normal Fehler Normal Fehler Chaos Normal Fehler Fehler Chaos Chaos In der Spalte ganz links sind die Verhaltensm glichkeiten des fehlerverursachenden Teilsystems aufgef hrt in den anderen Spalten verschiedenen M glichkeiten von Ver haltensklassen des Gesamtsystems In Spalte 1 sind die Reaktionen eines maximal fehlertoleranten Systems dargestellt Sogar wenn vollkommen unvorhergesehenes Ver halten in der Teilkomponente auftritt bleibt das Gesamtverhalten normal Spalte 2 beschreibt eine etwas schw chere Form der Fehlerd mpfung Unvorhergesehene Fehler spiegeln sich nun in einem Fehlverhalten des Systems wider w hrend die vorhergesehe nen und damit erwarteten Fehler aber noch keine Beeintr chtigung des Gesamtverhal tens nach sich ziehen
165. hlertolerant be zeichnet werden wenn d M lt d M Der korrekte Teil S2 des Systems ist also in der Lage die Auswirkungen des Fehlers innerhalb von S einzud mmen Diese Charakterisierung von Fehlertoleranz basiert somit auf einer geeigneten Definition einer Bewertungsfunktion d von Modifikationen Diese Funktion ist eng verbunden mit einer Metrik die den Unterschied von Systemen quantifiziert und ber einen Ahnlich keitsbegriff zwischen Systemverhalten zu definieren ist Der Unterschied zwischen zwei Systemen wird der Bewertung d der Modifikation entsprechen die S1 in das System Sa umwandelt Es ist zu vermuten dass der Schweregrad d einer Modifikation in Abh ngig keit vom System zu definieren ist auf das sie angewendet wird Sinnvolle Definitionen der genannten Begriffe verbleiben als offenes Problem Wir beschr nken uns im folgenden auf eine qualitative Bewertung von Fehlerd mpfung Mit dieser wird es m glich die Fehlertoleranz von Systemen einer von f nf definierten Klassen zuzuordnen 4 4 3 Fehlertoleranz als D mpfung qualitativ Mit Hilfe unseres Formalismus sind wir in der Lage das Systemverhalten in die drei Klassen Normal Fehler und Chaos zu unterteilen vgl Abbildung I Das Normal verhalten wird durch eine Beschreibung von S charakterisiert und das Fehlerverhalten durch SAM beschrieben w hrend alle restlichen Verhalten als Chaos bezeichnet wer den k nnen Mit diesen drei Klassen k nnen wir versc
166. hrend der Fertigstellung dieser Ar beit f r mich aufbrachten F r die Durchsicht einer Vorversion der Arbeit und ihre konstruktiven Vorschl ge m chte ich Prof Manfred Broy Prof Eike Jessen Katharina Spies Konstanze Tau ber und Ingolf Kr ger meinen herzlichsten Dank ausdr cken Die Arbeit wurde finanziell durch die Deutsche Forschungsgemeinschaft DFG im Rah men des Sonderforschungsbereichs 342 unterst tzt Inhaltsverzeichnis 1 Einf hrung ee SOT Tee eee ree ea be eee Beene seas oe oes as ee ee ee ea Formales Systemmodel 3 eisai Sot be ae ec ne oe oes sik So in ee te en ee a oat a Ae oe en Boe eb E ei ee a 3 7 1 _ Komposition von Black Box Spezifikatione E ew E er EE E eee 3 8 1 Eigenschaften von Transitionssystemen EEE REES RER NID OW RF amp 11 13 17 21 24 25 29 35 ii INHALTSVERZEICHNIS 3 9 1 Verhaltensverfeinerung 2m a a nn 3 9 3 _Kompositionalit t ne ane ah veh ee re Die Bh ee eee le a 4 1 2 Einschr nkung der Schnittstelle a a ee es ee ee ae Lead be ee ee bee ee eee BEN ee ee ent 4 4 1 _Fehlertoleranz als korrespondierende Modifikation 4 4 2 Fehlertoleranz als D mpfung quantitativ 4 4 3 Fehlertoleranz als D mpfung qualitativ ie ae ee ne 4 5 1 Kombination von Modifikatione re ee 4 6 1 __Explizite Umgebungsannahmen 4 6 2 Implizite Umgebunssannahme 4 7 Zusammenfassung und Diskuss
167. icher Weise m glichst viele Variablenwerte unver ndert Die Erg nzung einer beliebig w hlbaren Ausnahmebehandlung ist die allgemeinste Form des Umgangs mit Fehlern Damit sind alle denkbaren Reaktionen modellierbar unter anderem auch Techniken des Backward und Forward Recovery beschrieben beispiels weise in 44 mit denen versucht wird trotz auftretender Fehler m glichst wenig vom Normalablauf eines Systems abzuweichen Als einfachere Beispiele definieren wir den Sprung in einen Fangzustand und den Neustart eines Systems im formalen Rahmen der Ausnahmebehandlungen Beispiel 5 4 Wir k nnen den Sprung in einen Fangzustand folgenderma en als Ausnahme behandlung definieren c a Entry true Exit 2 false Durch die Variable zp ist sichergestellt dass keine Transitionen des Systems schaltbereit sind Sie bernimmt die Rolle von trap Da es keinen Riicksprung gibt ist beliebig definierbar Auch der Neustart des Systems kann leicht definiert werden Wir ben tigen in C erneut kei ne Transitionen da wir die Ausnahmebehandlung sofort wieder verlassen wollen Das System springt mittels Y als in einen Startzustand von S zur ck Wir haben also d C Yo Entry Z true Exit a true af Y 5 5 FEHLERKORREKTUR 137 In allen vorgestellten Formalisierungen wird bei einem erkannten Fehler sofort die Feh lerbehandlung gestartet Es kann jedoch in konkreten Anwendungsf llen sinnvoller sein die normale Ausf hrung e
168. ickeln das trotz enthaltener und auftretender Fehler ein akzeptables Verhalten zeigt Wir widmen diesem Thema den folgenden Abschnitt Einen Sonderfall im Umgang mit Fehlern stellen die sogenannten selbststabilisierenden Systeme 61 dar Diese zustandsbasierten Systeme streben von nahezu jedem belie bigen Zustand immer zu Zust nden die als korrekt definiert sind und kommen unter Umst nden ohne explizite Fehlerentdeckung und lokalisierung aus Die Fehlerbehebung ist damit ein integraler Bestandteil der Funktionsweise eines derartigen Systems Diese Systeme basieren auf speziellen Eigenschaften des zugrundeliegenden Algorithmus und sind in der Praxis nach 28 nur sehr selten anzutreffen Die Techniken die die Fehlertoleranz eines Systems erm glichen werden nat rlich auch schon w hrend der Entwicklungszeit integriert so dass in gewisser Weise der Umgang mit Fehlern nicht nur w hrend der Laufzeit erfolgt sondern vorbereitend bereits zur 24 KAPITEL 2 DER FEHLERBEGRIFF Entwicklungszeit Dennoch besteht hier ein qualitativer Unterschied Nur der auto matisierte Umgang mit Fehlern zur Laufzeit kann eventuell unvermeidbaren Fehlern begegnen die erst zur Laufzeit auftreten oder w hrend der Entwicklungszeit bersehen wurden Die entsprechenden Techniken unterscheiden sich erheblich von Entwicklungs techniken zur Vermeidung von Fehlern 2 2 Fehlertoleranz Als Fehlertoleranz wird zum Beispiel in B0 die Eigenschaft eines Syste
169. icklung ist ihre Kompositionalit t Verfeinert man eine Komponente eines zusammengesetzten Systems so ergibt sich eine Verfeinerung des Gesamtsystems Dies ist f r die Bew ltigung der Komplexit t in einem Entwicklungsproze wesentlich Die Verfeinerung der einzelnen Komponenten kann damit unabh ngig voneinander gesche hen Die Kompositionalit t wird mit folgender Regel ausgedr ckt SS S2 gt 5 S1 8 S2 Si S3 Im Falle der Schnittstellenverfeinerung ist die Verfeinerung nicht g nzlich unabh ngig da die Ver nderung von Kan len und ihren Nachrichtentypen jeweils eine schreibende und eine lesende Komponente betrifft Durch die explizite Formalisierung dieser nde rungen mit Hilfe der Abstraktions und Repr sentationsrelationen R ist der Zusammen hang aber formal dokumentiert und entsprechende Beweisverpflichtungen ergeben sich aus der folgenden Regel die in Abbildung B T0 illustriert ist RiARx RoAR 5 R x Ro y s 5 RrARK RoARL gt ReARy RLARx gt 2 S18 52 Si amp S Die Relationen R m ssen gewisse Voraussetzungen erf llen um die Kompositionalit t zu gew hrleisten wie in 17 BI begr ndet Diese sind hinreichend durch die Umkehr barkeit oder Linkseindeutigkeit von R sichergestellt wenn also x y R A 2 y R gt r r gilt 3 10 Entwicklungsproze Wie bereits in Abschnitt B 9 erw hnt ist es nicht m glich ein komplexes System in einem Schritt zu entwickeln Eine f
170. ie auf Zust nden und Transitionen basieren und die nun kurz charakterisieren Ein System befindet sich zu jedem Zeitpunkt in einem Zustand Ein Zustand besteht im wesentlich aus einer Belegung aller Variablen des Systems mit konkreten Werten Der bergang zwischen zwei Folgezust nden wird durch eine Transition beschrieben die als bewachte Zuweisung ausgedr ckt werden kann Ein Ablauf eines Systems ist eine endliche oder unendliche Folge von Zust nden in der zwei aufeinanderfolgende Zust nde einer legalen Transition des Systems entsprechen Wir stellen in Kapitel B 6 ein Modell f r Transitionssysteme vor und verzichten hier daher auf eine detailliertere Darstellung Fehler werden in oben genannten Modellen als explizit angegebene Mengen zus tzli cher Transitionen dargestellt wie bereits 1985 in 22 vorgeschlagen Auf eine Aussage ber die Ver nderung der Systemeigenschaften verzichten einige formale Ans tze da sie Fehlertoleranz nur als maskierende verstehen Liu Joseph Liu und Joseph stellen in ihren Arbeiten 46 47 48 Fehlertoleranz nur in der speziellen Form der maskierenden Fehlertoleranz dar Sie bezeichnen mit P das Nor 26 KAPITEL 2 DER FEHLERBEGRIFF malsystem und mit F P das durch eine definierte Fehlermenge beeinflu te System Das entstehende System wird fehlertolerant gegen ber einer Spezifikation genannt wenn das System alle Eigenschaften von erf llt also gilt FUP gt 8 Sie lassen im Falle ei
171. ierender Mo difikationen F hrt man nderungen an einem Transitionssystem durch so 6 2 WEITERF HRENDE THEMENGEBIETE 163 m chte man die damit verbundenen nderungen der Systemeigenschaften ableiten Selbst wenn eine allgemeine und in allen F llen anwendbare Tech nik kaum zu finden sein wird ist eine Einschr nkung auf Teilklassen von Systemen vielversprechend So ist etwa vorstellbar aus bestimmten Klas sen von Modifikationen an Transitionssystemen entsprechende Modifikatio nen an den Systemeigenschaften konstruktiv ermitteln zu k nnen Beispiele sind die Fehlerklassen aus Abschnitt 5 1 mit denen sich ihnen entsprechen de nderungen an den Systemeigenschaften assoziieren lassen Entsprechend lohnenswert ist die Entwicklung von Kriterien und Hinweisen ob und wie Be weisdiagramme m glichst konstruktiv an die Modifikationen von Systemen angepa t werden k nnen e In engem Zusammenhang mit dem Fehlerbegriff steht das Themengebiet des Tes tens Ein Systemtest hat das Ziel Fehler in einem System aufzudecken Mit dem in dieser Arbeit erarbeiteten formalen Fehlerbegriff wird auch eine formale Cha rakterisierung von Tests m glich Damit ist man beispielsweise in der Lage aus definierten Fehlern eines Systems einen zugeh rigen Test zu konstruieren der diese Fehler aufdecken wird Mit Hilfe einer geeigneten Erweiterung unseres For malismus wird man so in die Lage versetzt die Korrektheit eines Tests explizit zu formulieren und au
172. iert werden k nnen e Ein Transitionssystem kann gem dem in Abschnitt B 6 beschriebenen System modell beliebige Variablen aus der Menge der Variablen VAR verwenden Die Variablenmenge A dient dazu die in einem System vorkommenden Variablen zu dokumentieren und damit die Kompositionalit t leichter definieren zu k nnen Es ist damit durch reine Inspektion von J O und A m glich zu erkennen welche Variablen gelesen und welche geschrieben werden d rfen Solange sichergestellt ist dass bei der Komposition nicht etwa auf die interne Variablen einer anderen Komponente zugegriffen wird d rfen ohne weiteres neue Variablen in A erg nzt werden Da es beliebig viele frische Variablen gibt k nnen Konflikte leicht ver mieden werden Allerdings ist zu beachten dass eine neue erg nzte Variable in den existierenden Transitionen bislang nicht vorkommt und daher von dieser in beliebiger Weise bei jedem Systemschritt ver ndert werden kann Dies kann bei Bedarf mit Hilfe einer Modifikation durch Entfernen von Transitionen leicht behoben werden Wird eine neue Variable v VAR in A aufgenommen so werden durch eine Modifikation M E F mit E 2 a p a v B v Ver nderungen von v ausgeschlossen die erst durch explizite Aufnahme durch entsprechende Transitionen via F wieder eingef hrt werden k nnen Dieser Ansatz wird im Beispiel 5 veranschaulicht 88 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Die Entfernung von Va
173. ilure Fehler Sicht i AE fault Fehlerursache Fehlerzustand Glass Box fault error Sicht Abbildung 2 4 Fehlerbegriffe f r Soll Ist Abweichungen werden oft erst im Systemablauf in Form von ausgel sten Fehlerzust nden oder Sys temversagen erkannt Abweichungen eines vorliegenden Ist Systemzustandes von einem erwarteten Soll Zu stand k nnen wieder in bereinstimmung mit den etablierten Begriffen als Fehlerzu stand bezeichnet werden Die in Abbildung P A dargestellte Tabelle gibt uns einen berblick welchem Fehlerbe griff eine vorliegende Abweichung eines Ist von einem Soll zuzuordnen ist In Abh ngig keit des Merkmals das eine vorliegende Diskrepanz aufweist kann der zugeordnete Fehlerbegriff ermittelt werden Wir werden alle Aspekte eines Systems in den forma len Definitionen in Kapitel B unmittelbar wiederfinden Die Systemschnittstelle wird in Abschnitt B 3 definiert das Verhalten eines Systems in Abschnitt B 4 Das Umgebungs verhalten wird in Abschnitt 3 5 behandelt Internes Systemdesign wird in Kapitel B 6 mit Transitionssystemen dargestellt die die entsprechenden Systemabl ufe als dynami schen Anteil definieren Eine wichtige Frage dabei ist wie konkrete Systeme und ihre Fehler zu beschreiben sind Wir werden dazu geeignete Beschreibungstechniken anbie ten Zur Darstellung der Soll Ist Abweichungen f hren wir in Kapitel 4 den Begriff der Modifikationen ein der f r alle relevanten Merkmale eines
174. in Computer Science pages 82 93 Springer 2000 LAPRIE JEAN CLAUDE Dependability Basic Concepts and Terminology vol ume 5 of Dependable Computing and Fault Tolerant Systems Springer 1992 LEE PETE and TOM ANDERSON Fault Tolerance Principles and Practice Springer second revised edition 1990 LEVESON NANCY Safeware System Safety and Computers Addison Wesley 1995 Liu ZHIMING Fault Tolerant Programming by Transformations PhD thesis University of Warwick July 1991 Liu ZHIMING and MATHAI JOSEPH A formal framework for fault tolerant pro grams In IMA Conference on Mathematics of Dependable Systems Oxford Uni verity Press 1993 Liu ZHIMING and MATHAI JOSEPH Specification and verification of recovery in asynchronous communicating systems In 69 1995 pages 137 166 Lyu MICHAEL R editor Software Fault Tolerance John Wiley amp Sons 1995 MANNA ZOHAR and AMIR PNUELI Temporal verification diagrams In Inter national Symposium on Theoretical Aspects of Computer Software number 789 in Lecture Notes in Computer Science pages 726 765 1994 MANTEL HEIKO und FELIX C GARTNER A case study in the mechanical ve rification of fault tolerance Technischer Bericht TUD BS 1999 08 Institut f r Informatik Technische Universit t Darmstadt November 1999 PAULSON LAWRENCE C ML for the Working Programmer Cambridge Univer sity Press 1996 Web Seite des Projektes QUEST http www4 in tum de
175. ine mit r beschriftete Kante die von einem Knoten zu einem Knoten f hrt kann aus dem Diagramm entfernt werden wenn die Transition T im modifizierten System nicht mehr enthalten ist wenn also gilt YVa ea Hina b Hr gt aB ET E Wird der Knoten j eines Diagramms durch das Entfernen von Kanten unerreich bar so kann und muss er aus dem Diagramm gel scht werden Das Diagramm beweist dann die st rkere Aussage S IF inv Po V V _ V 841V V e Eine Transition r kann durch E sowohl in seinen Vor als auch Nachbedingungen so verst rkt werden dass nicht nur AT gt F gezeigt werden kann sondern die verst rkte Aussage PATS AX mit geeignetem x Die Gesamtaussage des Diagramms verst rkt sich dann zu S IF inv o V V PAX V V On Ein Beispiel f r eine verst rkte Vorbedingung haben wir in Abschnitt 5 5 ken nengelernt Eine Menge von Transitionen wurde derart eingeschr nkt dass die 5 7 WIEDERVERWENDUNG VON BEWEISEN 145 darin enthaltenen Transitionen nur noch schalten d rfen wenn eine Variable xp den Wert false hat Dieses Wissen darf dann zum Ableiten eines x verwendet wer den In Beispiel BR werden wir sehen wie entfernte Transitionen als verst rkte Nachbedingungen formuliert werden k nnen Kann das einem Knoten zugeordnete Pr dikat verst rkt werden ist es zudem m glich auch die Pr dikate der Nachfolgeknoten entsprechend zu verst rken da von A W mehr Aussagen abgeleitet werden
176. inen Eingabestrom i die Bedingung Vil Cie R Oi lt D8i so tritt kein Unterlauf auf da stets ausreichend viele Daten vorhanden sind Es gilt dann also underflow i 0 Damit ist die urspr ngliche Spezifikation erf llt wenn A gilt Wir haben also A gt G G und somit eine Verfeinerung des Systems spezifiziert die eine erh hte Robustheit aufweist 5 6 ERH HUNG DER SYSTEMROBUSTHEIT 141 5 6 2 Implizite Umgebungsannahmen Ein Charakteristikum reaktiver Systeme ist es jederzeit auf Eingaben zu reagieren In Abschnitt 4 6 2 leiten wir basierend auf dieser Annahme aus einem Transitions system eine implizite Anforderung an die Umgebung ab Die Pr fixe von Eingaben d rfen nicht in Zust nde f hren von denen aus die Eingaben nicht mehr vollst ndig gelesen werden k nnen Das Erh hen der Robustheit eines Transitionssystems besteht folglich aus dem Erg nzen von Transitionen die die Zahl der Fangzust nde reduzieren und damit die Reaktivit t des Systems verbessern F r ein System S I O A T T definieren wir dazu eine Menge von Transitionen F so dass jede Transition a 3 F von einem Fangzustand von S ausgeht Es gibt also in T keine Transition die im Zustand a schaltbereit ist formal mit V TU OU A beschrieben durch Vieai A Va yea a gt 4 7 ZT Einen Zustand nennen wir nicht Fangzustand wenn nur aufgrund mangelnder Nach richten auf den Eingabekan len keine Transit
177. iner Modifikation die Anforderungen an ein System verst rkt kann es notwendig sein auch die Umgebungsannahmen entspre chend zu verst rken ohne die ein System die verlangte neu aufgenommene Forderung nicht zu erf llen vermag Die Umgebung kann dargestellt sein durch weitere Kompo nenten die dann wiederum geeignet modifiziert werden m ssen In diesem Abschnitt fokussieren wir aber auf Umgebungsfehler interpretiert als eine potentielle M glichkeit der Umgebung vom erwarteten Verhalten abzuweichen Hierf r ist die Beschr nkung auf abschw chende Modifikationen ausreichend 4 6 2 Implizite Umgebungsannahmen Ist ein System durch ein Transitionssystem spezifiziert so kann eine Umgebungsannah me explizit definiert sein wie in Abschnitt 6 1 Aber auch ohne direkte Formulierung kann eine implizite Umgebungsannahme in den Entwurf des Transitionssystems einge flossen sein Wir zielen in dieser Arbeit in erster Linie auf die Modellierung reaktiver Systeme ab Ein System ist nur dann reaktiv wenn es jederzeit bereit ist weitere Nachrichten auf den Eingaben zu empfangen und darauf zu reagieren Ger t das System in einen sogenann ten Fangzustand in dem zwar noch unverarbeitete Nachrichten vorliegen aber keine Transition mehr schaltbereit ist ist die Reaktivit t des Systems nicht mehr gew hrleis tet F r auftretende Fangzust nde kann es zwei Gr nde geben e Der Entwurf des Transitionssystems ist fehlerhaft und es wurden geeignete
178. ines Systems noch etwas weiterzuf hren da gewisse Teilauf gaben noch vollendet werden sollen und m ssen bevor die Fehlerbehandlung gestartet wird Dies ist durch eine geeignete Anpassung des Pr dikates Y modellierbar Die Fehlerbehandlungen haben die Eigenschaft dass sie keinen Einflu auf das System verhalten haben solange keine Fehler auftreten Dies ist offensichtlich da Modifikatio nen nur dann eine Wirkung zeigen k nnen wenn gilt oder galt F r eine durch M beschriebene Ausnahmebehandlung und ein System S in dem W eine Invariante ist gilt also S SAM Selbstverst ndlich muss diese Eigenschaft nicht immer gelten So kann beispielsweise ein System erweitert werden um Transitionen die regelm ig relevante Teile des Sys temzustandes abspeichern um im Fehlerfalle auf einen korrekten Zustand zur ckgreifen zu k nnen und ihn wiederherzustellen Die Strategie des Backward Recovery verwen det diese Technik Die Bereitstellung der notwendigen Redundanz hat Einflu auf das Normalverhalten des Systems und macht es typischerweise ein wenig langsamer Auch diese Techniken k nnen durch die Erg nzung von Transitionen modelliert werden Wir haben uns hier auf die Darstellung einiger einfacher Beispiele beschr nkt 5 5 2 Treiberkomponenten Es ist w nschenswert die Auswirkungen von Fehlern nach M glichkeit lokal zu hal ten um eine Ausbreitung ber weitere Teile eines Systems zu vermeiden Dies kann durch sogenannte T
179. inger 1994 36 JANOWSKI Tomasz On bisimulation fault monotonicity and provable fault tolerance In AMAST 97 International Conference on Algebraic Methodology and Software Technology number 1349 in Lecture Notes in Computer Science Springer 1997 37 JANOWSKI TOMASZ Semantic and logic for provable fault tolerance Slides for tutorial Formal Methods Europe Graz Austria 1997 38 JANOWSKI TOMASZ and YUN XIAOCHUN Concurrency faults and atomic trans actions Incremental design for fault tolerance Technical Report 138 The United Nations University UNU International Institute for Software Technology IST August 1998 39 JOHNSON BARRY W Design and Analysis of Fault Tolerant Digital Computing Addison Wesley 1989 168 40 41 43 44 45 46 47 LITERATURVERZEICHNIS KINDLER EKKART Sicherheits und Lebendigkeitseigenschaften Ein Litera tur berblick Technischer Bericht TUM I9339 Technische Universit t M nchen Dezember 1993 SFB Bericht Nr 342 2 93 B KULKARNI SANDEEP and ANISH ARORA Compositional design of multitolerant repetitive byzantine agreement In Proceedings ofthe 18th International Conference on the Foundations of Software Technology and Theoretical Computer Science 1997 KULKARNI SANDEEP and ANISH ARORA Automating the addition of fault tolerance In JOSEPH MATHAI editor Formal Techniques in Real Time and Fault Tolerant Systems number 1926 in Lecture Notes
180. inzipielle etablierte Techniken der Fehlertoleranz 2 1 Fehler Der Begriff des Fehlers ist sehr unterschiedlich interpretierbar Wir wollen anhand ver schiedener Beispiele den sehr unterschiedlichen Charakter verschiedener Arten von Feh lern illustrieren In den meisten F llen wird dabei der Begriff des Fehlers verwendet Bei der Nutzung eines Diskettenlaufwerks kann ein Rechner einen Lesefehler melden Eine Systemspezifikation kann einen Fehler aufweisen der in einem Review Proze auf gedeckt wird Es k nnen falsche Informationen in einem Benutzerhandbuch enthalten sein die Benutzer zu einer falschen Bedienung oder zu falschen Erwartungen gegen ber eines Systems f hren Die Ausf hrung eines Programmes kann unerwartet nicht ter minieren Das Layout eines mit einem Textverarbeitungsprogramms erstellten Doku mentes kann im Ausdruck anders aussehen als erwartet Der Kontostand auf einem Kontoauszug kann berraschend niedrig sein so dass er als fehlerhaft empfunden wird Ein Steuersystem kann versagen so dass sogar Menschenleben gef hrdet werden bei spielsweise durch unerwartet ausgel ste oder nicht oder zu sp t ausgel ste Airbags Diese Beispiele zeigen wie unterschiedlich die Ursachen die Auswirkungen die Art und Weise der Feststellung die Wahrnehmung die Lokalisierung und Quantifizierung von sogenannten Fehlern sein k nnen 10 KAPITEL 2 DER FEHLERBEGRIFF W hrend ein Fehler beim Lesen eines Diskettenlaufwerks unter
181. io 5 _ Methodischer Umgang mit Fehler 5 1 Beispiele f r Fehlermodelle ee ee ac bn oe er tote an cg oe ah Gone BR Re Seo oh hoe te eee loi fds Hist ee et Ne oe eh Te ed 5 5 1 _ Erg nzung von korrigierenden Transitionenl pe ee ee ee 5 6 _ Erh hung der Systemrobustheitl 0 2 2 2 nn 5 6 1 Explizite Umgebungsannahmen INHALTSVERZEICHNIS 5 6 2 _Implizite Umgebungsannahme 5 7 _ Wiederverwendung von Beweise 5 7 1 __Invariantendiagramme 5 7 2 __Fortschrittsdiasrammd 5 8 Zusammenfassung und Diskussio 6 _ Zusammenfassung und Ausblick 6 1 Beitrag dieser Arbeit 6 2 Weiterf hrende Themengebiete Literaturverzeichni A bbildungsverzeichni ii 141 143 144 148 153 157 157 161 165 171 iv INHALTSVERZEICHNIS Kapitel 1 Einf hrung Nach der folgenden Einleitung die die Herausforderungen der heutigen Informatik il lustriert erl utert dieses Kapitel in Abschnitt L 2 Jdas Umfeld der Arbeit und pr zisiert damit ihren Titel Im Anschlu an die Motivation in Abschnitt 03 formulieren wir in Abschnitt L4 die Ziele der Arbeit und geben einen kurzen berblick ber die Inhalte der folgenden Kapitel 1 1 Einleitung Durch die rasche Entwicklung der Leistung informationstechnischer Systeme und ihre damit verbundene rasante Ausbre
182. ion f X Y gibt so dass VeeX e type c type f c 3 7 KOMPOSITION 57 t e e 0 Merge e Split i2 gt e 02 Abbildung 3 6 Multiplexer Sie hei en zus tzlich eindeutig vereinbar wenn es genau eine solche Bijektion gibt Die Bijektion f nennen wir Umbenennung Wir werden diese Definition in Kapitel 4 2 4 verwenden Im folgenden Beispiel ist eine Umbenennung nicht notwendig da die Komponenten von vornherein passende Kanal namen aufweisen Beispiel 3 8 Spezifikation eines Multiplexers Wir definieren zun chst eine weitere Komponente Split die wir mit Merge komponieren wollen Diese Komponente empf ngt den Datenstrom den Merge erzeugt und trennt die Daten wieder in zwei Datenstr me auf Split besitzt also o als Eingabekanal Wir definieren die Ausgabe kan le zu 01 02 mit den Typen type o Dj Damit ist Split also offensichtlich kompatibel zu Merge Das komponierte System ist in Abbildung B 6 dargestellt Als Eingabeschnittstelle des Systems Multiplex 2 Merge Split ergeben sich i2 als Eingabekan le und 01 02 0 als Ausgabekan le In den folgenden beiden Abschnitten definieren wir fiir unsere beiden Beschreibungs techniken wie sich das Verhalten eines komponierten Systems aus dem Verhalten der Einzelkomponenten ergibt Im Rahmen eines Entwicklungsprozesses ist es empfehlenswert die Komposition auf der Ebene der Black Box Spezifikatio
183. ion schaltbereit ist Da die Umgebungs transitionen 7 immer schaltbereit sind werden im weiteren Systemablauf noch weitere Eingaben produziert Liegen aber Eingaben an allen Kan len an und ist keine Transition aus T schaltbereit so ndert sich dies auch nicht mehr durch ausgef hrte Umgebungs transitionen aus T Sinnvollerweise sollten die neuen Transitionen von erreichbaren Zust nden ausgehen Es sollte also einen Ablauf geben in dem der Zustand a auftritt 3gE S eIke kla Ist ein Zustand nicht erreichbar kann er auch kein Fangzustand sein Das Erg nzen einer Transition an einen unerreichbaren Zustand ndert das Systemverhalten und damit auch die Robustheit nicht Modifizieren wir ein System S zu SA amp F so wird damit seine Robustheit erh ht da das System weniger Fangzust nde aufweist Nat rlich k nnen auch in einem robuste ren System noch immer Fangzust nde existieren es k nnen sogar neue Fangzust nde hinzukommen die zuvor unerreichbar waren aber durch F erreichbar werden Diese werden jedoch in einem Ablauf erst sp ter erreicht so dass dennoch sinnvollerweise von einem robusteren System gesprochen werden kann In welche Zust nde die mit F neu erg nzten Transitionen f hren bleibt dem Entwickler berlassen und ist von der konkreten Anwendung abh ngig So k nnen beispielsweise unerwartete Nachrichten die sonst zu einem blockiertem System gef hrt h tten einfach verworfen werden oder es kann eine ande
184. ionalit t bei der man von potentiellem Versagen ausgehen muss Um eine h here Robustheit zu erreichen wird diese Komponente verdreifacht und alle drei Module mit den gleichen Eingabedaten versorgt Eine neue Komponente der Voter liest die Ausgaben der drei Module und ermittelt durch Mehrheitsbildung ein Ergebnis das an die Umgebung ausgegeben wird Abbildung 6 Das Versagen von nur einer Komponente kann nach au en maskiert werden Versagen mehrere Komponenten kann der Fehler noch erkannt werden Versagen allerdings mehrere Module auf die gleiche Weise wird die entstehende Ergebnismehrheit nach au en weitergegeben Ein pr zise Aussage ber Fehlertoleranz entsprechend Abschnitt 2 2 muss all diese F lle ber cksichtigen also f r verschiedene F lle die jeweiligen Auswirkungen beschreiben bzw Hardwarefehlern Designfehler in der Hardware spielen hier eine Sonderrolle und sind aufgrund ihrer Charakteristik eher den Softwarefehlern zuzuordnen 32 KAPITEL 2 DER FEHLERBEGRIFF Fault Detect A Modul 1 Switch gt Modul 2 Abbildung 2 7 Reservekomponenten Es gibt Verallgemeinerungen dieser Technik zum Beispiel durch die Verwendungen von mehr als drei Modulen oder auch eine Replizierung des Voters 66 Standby Spares Eine weitere h ufig verwendete Technik ist die Verwendung von Reservekomponenten wie in Abbildung 2 7 dargestellt Im Normalbetrieb erbringt
185. ir im folgenden noch erl utern werden Ausgehend von diesem neuen Knoten muss dann f r alle Transitionen aus TUF erneut untersucht werden in welche Knoten sie jeweils f hren Dabei k nnen noch weitere neue Knoten entstehen In Abbildung B 7list eine Illustration eines erweiterten Verifikationsdiagramms darge stellt Die Disjunktion der Pr dikate der m neuen schattiert dargestellten Knoten stellt die Abschw chung p der Invariante dar Es gilt also nur noch 146 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN bo pE Abbildung 5 7 Erweiterung eines Beweisdiagramms S IF inv Po V V n V Pn V V nym lt m Op Das neue Beweisdiagramm umfa t und verallgemeinert damit das urspr ngliche Be weisdiagramm so dass damit vom bereits geleisteten Entwicklungsaufwand auch bei nachtr glicher Erg nzung von Fehler Transitionen m glichst wenig verloren wird Die Wahl des Pr dikates f r einen neuen einzuf genden Knoten ist dabei aber entschei dend f r die Komplexit t des neu entstehenden angepa ten Diagramms Das Pr dikat des neuen Knotens soll einerseits stark genug sein um gen gend Wissen ber das System zu enthalten und damit sinnvolle Ableitungen m glich zu machen Das triviale Pr di kat true w re ein unbrauchbarer Extremfall der einen R cksprung in ein bestehendes Pr dikat nahezu unm glich macht da keine Information ber den Systemzustand mehr verf
186. isiert Es existieren formale Ans tze mit denen Fehler und Fehlertoleranz prinzipiell definiert werden k nnen Diese bleiben in ihrer Ausdruckskraft aber eingeschr nkt und ihre prak tische Anwendbarkeit konnte noch nicht nachgewiesen werden Erweiterungen formaler Ans tze um pragmatische Beschreibungstechniken und methodische Hilfestellungen zur Entwicklung von Systemen unter Einbeziehung der Fehlerproblematik werden sich also gewinnbringend einsetzen lassen Es haben sich einige Techniken etabliert die sich zur Entwicklung fehlertoleranter Sys teme eignen wobei diese vorwiegend auf Hardwarefehler abzielen In der Beherrschung von Softwarefehlern sind Defizite erkennbar was seinen Grund nicht zuletzt in der hohen Komplexit t von Software hat die durch die Integration und Modellierung von potentiellen Fehlern und ihren zugeh rigen Gegenma nahmen noch weiter stark w chst W nschenswert ist eine systematische Methodik zum Umgang mit Fehlern die idealer weise das Normalverhalten von der Fehlerbehandlung trennt Mit dieser Arbeit werden wir hierf r einen wesentlichen Beitrag leisten Wir werden Techniken bereitstellen mit denen Systeme und ihre Fehler formal und explizit model liert werden k nnen und werden eine methodische Unterst tzung f r den integrierten Umgang mit Fehlern im Rahmen einer formalen Systementwicklung erarbeiten In den drei folgenden Kapiteln werden wir ein formales Modell einf hren und erweitern um Techniken z
187. ist ein erlaubtes Verhalten da durch u di di di i2 d2 d3 o d de di di d2 ein Verhalten der Merge Komponente mit unver nderter Schnittstelle beschrieben ist Auf dem neuen Ausgabekanal f d rfen beliebige Nachrichten gesendet werden Das Ignorieren neuer Nachrichtentypen in den Eingaben sowie beliebiger Ausgaben ber neue Ausgabestr me ist in diesem Beispiel also unmittelbar erkennbar H tten wir auch einen neuen Eingabekanal erg nzt so h tten auch auf diesem beliebige Nachrichtenstr me empfangen werden k nnen Es bleibt zu kl ren ob die so definierte Erweiterung der Schnittstelle die in Abschnitt 3 4 geforderten Eigenschaften der Verhaltensrelation nach Realisierbarkeit erh lt Die Linkstotalit t bleibt offensichtlich erhalten wie leicht gezeigt werden kann Proposition 4 1 Erhalt der Linkstotalit t Seien amp Xn r Fingabestr me und sei R eine Verhaltensspezifikation also linksto tal Die Str me type t1 O21 type in Say stellen typkorrekte Eingaben an ein durch R beschriebenes System dar so dass aufgrund der Linkstotalit t von R passende Str me Y1 Yn existieren die eine m gliche Ausgabe des Systems repr sentieren Erg nzt man diese um beliebig w hlbare Yn4i Yn 1 so hat man zu einer beliebigen Einga be eine Ausgabe gefunden die bez glich R pa t Die Kausalit t bleibt auch erhalten wenn man die Aussage auf die Ausgabekan le be sch
188. it de nen verteilte reaktive Systeme und Modifikationen sowohl der Schnittstellen als auch des Verhaltens dieser Systeme dargestellt werden k nnen Damit steht uns zun chst nur eine Sprache zur Verf gung mit der Fehler und fehlerbehaftete Systeme ausgedr ckt werden k nnen Um diese Sprache aber auch gewinnbringend zur Entwicklung fehlerto leranter Systeme einsetzbar zu machen werden wir in diesem Kapitel ihre Verwendung darstellen Dieses Kapitel erl utert dazu wie man beispielsweise die Fehlererkennung zu gegebenen Fehlern in ein System integriert wie man ein System derart erweitert dass es Fehlermeldungen erzeugen kann und mit welchen Techniken fehlerkorrigierende Mechanismen erg nzt werden k nnen Dazu geben wir zun chst Beispiele f r die Formalisierung typischer Fehlermodelle an Sollen die Zusammenh nge von Fehlern in verschiedenen Komponenten ausgedr ckt werden k nnen sogenannte virtuelle Komponenten und Orakel verwendet werden die wir in Abschnitt 5 2 beschreiben Die Fehlererkennung kann durch Pr dikate realisiert werden deren Eigenschaften wir in Abschnitt 5 3 charakterisieren Das Einf hren von Fehlermeldungen beschreiben wir in Abschnitt 5 4 In Abschnitt 5 5 geben wir zwei Techniken an wie Mechanismen zur Fehlerkorrektur nachtr glich in ein System in tegriert werden sowohl basierend auf Transitionssystemen als auch auf Modifikati onskomponenten Daraufhin diskutieren wir die M glichkeiten ein bestehendes S
189. iter entwicklung des Systems besteht wie bereits im vorausgehenden Abschnitt erl utert in der Erh hung der Robustheit Dies wollen und k nnen wir meist nicht f r alle denkbaren externen Fehler tun sondern nur f r eine Teilmenge f r die eine passende Reaktion zu definieren ist Wir differenzieren also auch hier wieder zwischen der Menge der ber ck sichtigten Fehler die erwartet beschrieben und behandelt werden und der Menge der nicht ber cksichtigten Fehler Von letzteren nehmen wir an dass sie nie auftreten und ignorieren damit den Fall falls dies dennoch passieren sollte Die Teilmenge der Fehler die zu ber cksichtigen sind muss durch eine geeignete Be schreibungstechnik definiert werden k nnen Dies ist auf der Basis eines Transitionssys tems S I O A T T m glich indem wir mit einer Formel ap mit freien Variablen aus IU O U A eine Teilmenge von Zust nden des Systems beschreiben Diese Menge charakterisiert die Eingaben die zu diesen Zust nden f hren durch LeadsTo trap a IE KS o It o t H Dinay Aa et Werden Transitionen dem System hinzugef gt so dass alle Zust nde f r die Otay gilt keine Fangzust nde mehr sind so entspricht dies einer Abschw chung der Umge bungsannahme des Systems Das modifizierte System bleibt dann in einer Umgebung reaktiv die Eingaben aus A S U LeadsTo tray erzeugt In Abschnitt 5 6 werden wir 4 7 ZUSAMMENFASSUNG UND DISKUSSION 119 die ents
190. itung in immer mehr Anwendungsbereiche sind die Qualit tsanforderungen an diese Systeme enorm gewachsen Rechner spielen eine zen trale Rolle bei der Steuerung der vielf ltigsten Systeme wie Flugzeuge Autos Raketen Haushaltsger te Telefone Waffensysteme Fernseher und andere Unterhaltungsger te Atomkraftwerke Kinderspielzeuge die Strom Gas und Wasserversorgung alle Arten von Telekommunikation sie bew ltigen den f r die Mehrzahl der finanziellen Trans aktionen notwendigen Informationsflu und sind in B ros mittlerweile unverzichtbar Sogar die Entwicklung neuer Systeme ist nur noch mit bereits bestehenden Systemen m glich Durch st ndige technische Neuerungen w chst die Zahl der M glichkeiten und damit der Anwendungsgebiete von IT Systemen stetig Ihre Verwendung reicht immer tiefer in alle Anwendungsbereiche hinein was die Komplexit t der Systeme weiter erh ht Al le Systeme und Dienste werden idealerweise miteinander gekoppelt und was technisch m glich ist soll m glichst schnell auch realisiert werden Der Markterfolg neuer Pro dukte und Dienstleistungen h ngt oft von der Geschwindigkeit ab in der sie verf gbar gemacht werden Mit zunehmender Verwendung und Vernetzung der IT Systeme in allen Bereichen des Lebens w chst die Abh ngigkeit von ihrer Verf gbarkeit Zuverl ssigkeit Sicherheit und Korrektheit stark an Ein auftretendes Versagen kann in immer komplexer werdenden Systemen fatale Folgen haben Da auch
191. jahrzehntelange Erfahrungen verf gen noch immer in ihren Anf ngen Die in den sp ten Sechziger Jahren formulierte Software Krise brachte die Disziplin des Software Engineerings hervor die zum Ziel hat wissenschaftlich fun dierte Methoden und Techniken bereitzustellen mit denen den genannten Problemen begegnet werden kann Diese Arbeit leistet den Beitrag die vielf ltigen Methoden des Software Engineerings um den speziellen Aspekt der Fehlermodellierung und behandlung zu erg nzen und damit die Palette der Techniken zur Erstellung hochqualitativer Systeme zu erweitern Dazu wird der Umgang mit Fehlern in verteilten reaktiven Systemen im Rahmen einer formalen Methodik aus systematische Weise erm glicht Wir werden dazu im folgenden das Umfeld und die Ziele der Arbeit genauer motivieren und darstellen 1 2 UMFELD 3 1 2 Umfeld Das thematische Umfeld der Arbeit ergibt sich unmittelbar aus den Stichworten des Titels Wir wollen unsere Ans tze auf eine formal fundierte Grundlage stellen und im folgenden daher die wesentlichen Kennzeichen formaler Methoden kurz charakterisie ren Wir konzentrieren uns im wesentlich auf die Systemklasse der verteilten reaktiven Systeme und wollen diese Wahl begr nden Dem Begriff des Fehlers und der Thematik der Fehlermodellierung ist mit Kapitel Blein eigenes Kapitel gewidmet Formale Methoden Der Begriff der formalen Methoden umfa t eine Palette von Me thoden und Hilfsmitteln die eine Systementwickl
192. k nnen Erg nzung von Transitionen Das Erg nzen von Transitionen aus einer Menge F erh lt im allgemeinen die G ltigkeit eines Diagramms nicht und kann eine Ab schw chung der Invariante nach sich ziehen Eine systematische Anpassung des Be weisdiagramms erfordert eine Untersuchung des Diagramms f r jeden Knoten und jeder neuen Transition 7 F Dabei ist zu berpr fen wohin diese Transition f hrt Folgende drei F lle sind m glich e Ist die Transition nicht schaltbereit gilt also AT false so erfordert die Transition in diesem Knoten keine nderung im Diagramm Diese Situation tritt typischerweise ein wenn die Schaltbereitschaft von einem Kontroll zustand abh ngt Hat 7 die Aussage o s als Teil ihrer Vorbedingung so muss T nicht in Zusammenhang mit Knoten untersucht werden deren Pr dikat o s impliziert e Ist eine Transition schaltbereit so ist zu pr fen ob es einen Knoten i gibt dessen Pr dikat vom System nach Ausf hrung der Transition erf llt wird also PAT gt P Eine entsprechende Kante muss dann im Diagramm erg nzt werden um die G ltigkeit des Beweisdiagramms sicherzustellen e Gibt es keinen Knoten der den Zustand nach Ausf hrung der neuen Transition beschreibt muss das Diagramm um einen neuen Knoten erweitert werden Dieser ist mit einem Pr dikat p41 zu beschriften f r das j AT gt Phy gilt Dabei liegt die Schwierigkeit in der geschickten Wahl von 1 wie w
193. kation die Ausf hrungsmodelle und die Mo dellierung von Zeit festlegt Die praktische Verwendbarkeit formaler Methoden ist noch immer Gegenstand von Diskussionen Auch wenn ihr Nutzen nicht immer eindeutig nachgewiesen werden kann werden sie in zunehmenden Ma e erfolgreich eingesetzt vor allem in sicherheitskriti schen Anwendungsbereichen Durch die in Abschnitt L I Jgenannten wachsenden Anfor derungen an die Systeme und durch st ndige Fortschritte auf dem Gebiet der formalen Methoden wird ihre Bedeutung und Einsetzbarkeit weiter zunehmen In 26 fin den sich sowohl viele Beispiele als auch Literaturhinweise und Erfahrungsberichte f r verschiedenste formale Methoden und ihre Anwendungen Der Ansatz dieser Arbeit zur Fehlermodellierung basiert auf der formalen Methodik Focus deren relevante Aspekte wir im Detail in Kapitel B vorstellen werden Verteilte reaktive Systeme Die Systemklasse der reaktiven Systeme zeichnet sich wir ihr Name schon sagt durch eine best ndige Reaktivit t aus und unterscheidet sich damit von sogenannten transformationellen Systemen Die transformationellen Systeme 4 KAPITEL 1 EINF HRUNG werden zusammen mit einer Eingabe gestartet berechnen ein Ergebnis und terminieren Ein Neustart mit einer weiteren Eingabe ist im allgemeinen m glich aber unabh ngig vom vorherigen Lauf ein errechnetes Resultat h ngt nur von der Eingabe ab die von Anfang an vollst ndig zu Verf gung steht Transformationelle Sy
194. kation angibt Leider ist dies im allgemeinen nicht m glich da man sonst auch in der Lage w re aus einem beliebigen Transitionssystem S automatisch auf seine Eigenschaften zu schlie en Man w rde ein beliebiges System mit einfachen Eigenschaften w hlen und es zum gew nschten System S modifizieren Ein konstruktives Verfahren w rde die Modifikation M liefern und AM w rde die gesuchten Eigenschaften repr sentieren Es ist zu vermuten dass eine korrespondierende Modifikation nur von einem Ent wickler des Systems gefunden werden kann der ein Verst ndnis f r die Funkti onsweise des Systems hat und die Auswirkungen von Modifikationen absch tzen 112 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN kann Eine Black Box Spezifikation stellt auch immer eine Abstraktion dar und umfa t in den meisten F llen nicht wirklich alle Eigenschaften die ein Transi tionssystem aufweist sondern beschr nkt sich auf Eigenschaften die im Sinne der Anwendung interessant sind Auf die gleiche Weise wie zueinander passende Spezifikationen und Transitionssysteme durch Verst ndnis Kreativit t und In tuition gefunden werden m ssen m ssen auch korrespondierende Modifikationen gefunden werden W rden sich korrespondierende Modifikationen konstruktiv finden lassen w re die Korrektheit der Korrespondenz automatisch gegeben Da wir sie aber selbst finden m ssen muss noch ihre Korrektheit gezeigt werden Als Frage resultiert daraus e
195. ktur und die Art und Weise wie es sein Verhalten erbringt Die Aspekte der Black Box Sicht sind hierbei mit enthalten um den Zusammenhang zwischen den Interna und ihrer externen sichtbaren Wirkung herzustellen Die Black Box Sicht stellt eine abstraktere Sichtweise dar da sie im Gegensatz zur Glass Box Sicht Details verbirgt In jeder dieser beiden Sichten lassen sich die Systemmerkmale in statische und dyna Den Operator zur Komposition werden wir in Abschnitt B 7 formal definieren 2 1 FEHLER 19 gt o d ee U E S Abbildung 2 2 Vereinfachtes Systemmodell mische Aspekte untergliedern Damit erhalten wir die in Abbildung 2 3 tabellarisch dargestellten Attribute eines Systems Die Black Box Sicht umfa t die Schnittstelle und das von au en sichtbare Verhalten des Systems Die Schnittstelle bleibt in einem Systemablauf unver ndert und ist da her ein statischer Aspekt Das Verhalten ist ein dynamischer Systemaspekt wobei wir unterscheiden zwischen dem Verhalten des Systems selbst und den Voraussetzungen an das Verhalten der Umgebung In vielen F llen kann ein System seine Leistung nur dann erbringen wenn die Umgebung gewisse Voraussetzungen erf llt Diese werden meist in einer Umgebungsannahme formuliert Der statische Anteil der Glass Box Sicht enth lt den internen Aufbau eines Systems Dazu geh ren beispielsweise sein Design sein Code und soweit vorhanden auch
196. kung einer Fehlerursache entdecken k nnen Dazu werden wir einige Techniken in Abschnitt 2 2 2 vorstellen Fehlerlokalisierung Zwischen dem Auftreten eines Fehlers und seiner Entdeckung k nnen sich die Folgen des Fehlers bereits ber das System ausgebreitet haben Techniken der Fehlerlokalisierung sollten in der Lage sein diejenigen Systemteile identifizieren zu k nnen die betroffen sind oder betroffen sein k nnten Nur so ist es m glich die Auswirkungen zu beheben und eine Ausbreitung von vornherein zu verhindern oder zumindest einzuschr nken Die Fehlerlokalisierung kann im Idealfall auch ermitteln welche Fehlerursache vorliegt Fehlermeldung Wird ein Fehler entdeckt so ist die Meldung an andere Systemteile oder an die Umgebung des Systems zum Beispiel seinen Benutzer die minimale Reaktion die vom System auf alle F lle geleistet werden muss Eine Fehlermel dung kann mit einer Deaktivierung des Systems oder eines Teiles verbunden sein wenn andere Reaktionen zur Fehlerbehebung nicht m glich sind e Fehlerbehebung Im Idealfall kann ein System einen Fehler zustand und seine Auswirkungen nach seiner Erkennung korrigieren Dies kann mit einer tempor ren Ver nderung des Systemverhaltens verbunden sein im optimalen Fall aber sogar nach au en nicht sichtbar werden Wir werden auf einige technische M glichkeiten in Abschnitt 2 2 2 eingehen Mit den genannten Mechanismen wird es m glich ein fehlertolerantes System zu ent w
197. l schwach fair d h jede Transition 6 ist unendlich oft nicht schaltbereit oder wird unendlich oft f r einen Schritt verwendet esse Welser i E Die Menge aller Abl ufe eines Transitionssystems S nennen wir S Die dritte Eigenschaft der schwachen Fairness erm glicht es uns Fortschrittsaussagen formal nachweisen zu k nnen wie wir in Abschnitt B 8 2 sehen werden Ein System kann blockieren wenn es in einem Zustand keine schaltbereiten Transi tionen mehr gibt Da die Umgebungstransitionen in T aber immer schaltbereit sind gibt es f r jedes System immer unendliche Abl ufe auch wenn sich nach einem blockie renden Zustand die Werte der kontrollierten Variablen unter Umst nden nicht mehr ndern Schritte in denen alle Werte unver ndert bleiben Stotterschritte sind jeder zeit m glich da a in der Menge 7 mit enthalten ist Um einem Transitionssystem ein Black Box Verhalten zuordnen zu k nnen betrachten wir die Werte der gelesenen Eingabestr me und der produzierten Ausgabestr me am fiktiven Ende einer Ausf hrung Da Ausf hrungen unendlich sind ist dies nat rlich nicht direkt m glich Da aber sowohl die Ein als auch Ausgabestr me schrittweise verl ngert werden und somit eine Kette bilden gibt es f r v JU O eine kleinste obere Schranke und wir k nnen diese als letzten Wert im Ablauf definieren c0 v LEk v k N Als Black Box Verhalte
198. lementiert Sie repr sentiert nur auf explizite Weise die globale Fehlerannahme die damit in Beweisen verwendet werden kann Beispiel 5 1 Als Beispiel w hlen wir das Triple Modular Redundancy System aus Abbil dung 5 1 Eine Komponente sei dreifach repliziert als S1 S2 und S3 denen das crash failure Fehlermodell zugewiesen sei Der Voter ist durch Vergleich der Ausgaben der drei Komponenten in der Lage den Ausfall einer Komponente an einer fehlenden Nachricht zu erkennen F r das hier gew hlte Fehlermodell kann das Gesamtsystem seine Leistung noch erbringen wenn mazi mal zwei der drei Komponenten ausfallen Diese Aussage wollen wir formal nachweisbar machen Dazu f hren wir die vorgeschlagenen beiden Schritte durch e Das Auftreten des Ausfalls wird kausal verkn pft mit einem entsprechenden Signal im Orakelstrom oc mit i 1 2 3 der entsprechend Abschnitt IJerg nzt wird Das Feh lermodell aus Abschnitt S LI wird weiter angepasst durch eine Ver nderung der Tran sition Tstop Diese Transition darf nur noch schalten wenn sie auf oc den Wert true empf ngt 126 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN V ymn i m a S Io 11 it tot oR a oe 1 So 1 l ji l i i ie S3 IBS a Ses seSeS Abbildung 5 1 TMR System mit virtueller Komponente F df Name Pre Input Output Post an S oc true stop true e Es
199. lick In diesem abschlie enden Kapitel fassen wir die Ergebnisse und Beitr ge der vorliegen den Arbeit zusammen und identifizieren die neu aufgeworfenen Problemstellungen mit den daraus resultierenden weiterf hrenden Aufgaben und Herausforderungen 6 1 Beitrag dieser Arbeit Der Kernbeitrag dieser Arbeit liegt in der Integration des Fehlerbegriffs in die formale Methodik Focus Damit wird eine engere Verbindung geschaffen zwischen der formalen Welt in der idealisierend von der Abwesenheit jeglicher Fehler ausgegangen wird und einer realen Welt in der vielf ltige Arten von Fehlern oft unvermeidbar sind und da mit auch im Entwicklungsproze f r komplexe verteilte Softwaresysteme nicht ignoriert werden k nnen und d rfen Formale Methoden werden oft gerade deshalb eingesetzt um Fehlerfreiheit in einer Sys tementwicklung zu erreichen Durch die mit ihrer Verwendung verbundene hohe Pr zi sion in der Formulierung von Systemspezifikationen und einer formal nachweisbaren Korrektheit von Entwicklungsschritten werden Fehler im Entwicklungsproze weitge hend ausgeschlossen Jedes konkret realisierte System st tzt sich aber ab auf eine nicht notwendigerweise fehlerfreie zugrundeliegende Basis wie beispielsweise das Betriebssys tem die Hardware oder die Systemumgebung Diese Fehler d rfen nicht vernachl ssigt werden Eine Verschiebung des Umgangs mit Fehlern in sp te Phasen einer Systementwicklung ist nicht in jedem Fall eine angemes s
200. lso die Annahme A verletzen A G Spezifikationen sind gut geeignet die Linkstotalit t von Black Box Spezifikationen zu erreichen indem nicht zugelassene Eingaben durch die Annahme ausgeschlossen wer den k nnen Sie eignen sich auch die Anforderungen an eine Umgebung auszudr cken in denen Komponenten in der Lage sind ihre Leistung zu erbringen Es k nnen damit auch Bedingungen f r die Komposition von Komponenten pr zise definiert werden Beispiel 3 4 A G Spezifikation eines Puffers Als Beispiel spezifizieren wir einen einfachen Puffer der Daten aus einer nicht n her spezifizier ten Menge D zwischenspeichert und auf Anfrage in der gleichen Reihenfolge wieder ausgibt Seine Kapazit t sei auf N Datenelemente beschr nkt Es gibt zwei F lle die wir durch eine geeignete Umgebungsannahme A ausschlie en wollen Der Puffer empf ngt Anfragen obwohl er keine Daten gespeichert hat oder der Puffer empf ngt Daten obwohl bereits N Elemente gespeichert sind Zun chst definieren wir die Schnittstelle Sowohl Daten als auch Anfragen dargestellt durch die Nachricht R sollen beide auf einem Kanal i empfangen werden w hrend die Ausgaben auf dem Kanal o wieder ausgegeben werden Damit ergibt sich I i type t DU R O o type o D und eine Darstellung der Schnittstelle entsprechend Abbildung BJ Die Annahme A soll die Bedingung beschreiben die der Eingabestrom zu erf llen hat Es ergeben sich folgende beiden Forderungen
201. ltierenden Schnittstellen und das Verhalten von S T amp U und T U identisch Sind die Komponenten jedoch nicht paar weise kompatibel kann dennoch nach einer geeigneten Umbenennung der Kan le eine Komposition m glich sein Eine Umbenennung kann aus verschiedenen Gr nden notwendig werden Bei der Spe zifikation eines Systems k nnen die Kanalnamen willk rlich gew hlt werden M chte man Systeme komponieren bei deren Entwurf nicht auf eine geeignete Namensgebung geachtet wurde so k nnen die System unn tigerweise nicht kompatibel sein wenn die Ausgabekan le den gleichen Namen tragen Die Kanalnamen k nnen vollkommen auch disjunkt sein so dass die Komposition nur eine parallele und vollkommen interaktions freie Komposition der Systeme ergibt Eine Umbenennung erfordert die Zuordnung von alten auf neue Kanalnamen Jedem alten Kanalnamen wird genau ein neuer Kanalname zugeordnet Eine Umbenennung k nnen wir also definieren durch eine bijektive Funktion zwischen Kanalnamen Bei einer Komposition k nnen nur Kan le identifiziert werden die den gleichen Nachrich tentyp aufweisen Daher mu die Umbenennung den Typ der Kan le erhalten K nnen Kanalnamen aus zwei Mengen typerhaltend umbenannt werden nennen wir die Mengen der Kanalnamen vereinbar Definition 3 9 Vereinbarkeit von Schnittstellen Umbenennung Seien zwei Mengen X und Y von Kanalnamen gegeben Sie hei en vereinbar im Zei chen X Y wenn es eine Bijekt
202. m bezeichnet trotz intern oder extern auftretender Fehler noch immer ein gew nschtes oder zumin dest davon nur geringf gig abweichendes Verhalten aufzuweisen Eine Aussage ber die Fehlertoleranz eines Systems muss also zwei Teilaussagen umfassen e Die Menge der tolerierten Fehler muss angegeben werden Im allgemeinen k nnen nicht beliebige Fehler zum Beispiel Fehler mit extrem fataler Wirkung toleriert werden sondern nur eine zu definierende Klasse von Fehlern von denen man an nimmt dass das System ihnen ausgesetzt sein kann Diese Menge von Fehlern wird h ufig auch als Fehlermodell bezeichnet ber Fehler die nicht in dieser Klasse sind wird keine Fehlertoleranz Aussage gemacht So wird f r manche Fehler bei spielsweise angenommen dass ihr Auftreten zu unwahrscheinlich ist als dass sie ber cksichtigt werden m ssen e Die zul ssige Abweichung vom fehlerfreien Verhalten ist zu definieren Nur im idealen Fall bleiben die Auswirkungen von Fehlern nach au en unsichtbar Im allgemeinen gibt es eine Ver nderung beispielsweise in der Performanz eines Sys tems in seinem zeitlichen Verhalten oder auch in einer tolerierbaren Abweichung von berechneten Werten vom eigentlich korrekten Resultat Diese in der Literatur oft als graceful degradation sanfte Leistungsminderung bezeichnete Abweichung ist f r eine klare Aussage zur Fehlertoleranz explizit zu machen F r ein System k nnen auch mehrere gestaffelte Aussagen zur Fehle
203. men der Eingabekan le und M kann vor S geschaltet werden Abbildung 2X OAY2O Die Modifikationskomponente kann direkt hinter S geschaltet werden und ihre Ausgabe ndert die Schnittstelle nicht bis auf Umbenennung der Kan le Abbil dung 3 X IUO AY 0 Die Eingabe der Komponente M wird sowohl mit der Eingabe als auch mit der Ausgabe von S verbunden w hrend die Ausgabe von M zur Ausgabe von S kom patibel bleibt Abbildung 4 3IT O0 e X I UO AY IUO0O AI sIn s0 Die Modifikationskomponente empf ngt sowohl Eingaben von der Umgebung ber I als auch die Ausgaben von S ber O Sie kann Ausgaben machen ber O an die Umgebung und ber I an S Abbildung 4 3 d Die Modifikation wird definiert durch die Komposition mit der entsprechenden Modifi kationskomponente Das modifizierte System wird also ausgedr ckt durch S amp M Es ergibt sich in allen vier F llen dass das komponierte System S 8 M kompatibel zu S ist also verm ge einer Umbenennung der Kan le in jedem Kontext an Stelle von S eingesetzt werden kann Durch die Beschr nkung auf eine Modifikation des Black Box Verhaltens sind Modifi kationskomponenten nicht immer gut geeignet zur Repr sentation von Fehlern So l t sich beispielsweise eine spontane interne Ver nderung im Datenanteil einer Kompo nente nur kompliziert darstellen Soll eine Ver nderung des Inhalts einer Speicherzelle durch eine Modifikationskomponente modelliert werden so m ssten
204. mit das Verhalten des Puffers in einem derartigen Fall nicht mehr unspezifiziert ist definieren wir eine naheliegende Reaktion Im Falle eines Unterlaufs soll die entsprechende Anfrage ignoriert werden Diese nderung dr cken wir nun formal aus Da wir die Annahme fallen lassen dass in jedem Pr fix die Zahl der Anfragen nicht gr er als die Zahl der Daten ist schw chen wir die Annahme A ab und fordern von der Umgebung nur noch AZ Vil Cie DOi R i lt N Wir passen die Spezifikation des Systems an zu amp oc DOi A 0 R i underflow i Die ausgegebenen Daten sind noch immer genau jene Daten die auch empfangen werden aller dings wird nicht mehr f r jede Anfrage eine Ausgabe gemacht Die L nge der Ausgabe wird um die Anzahl der auftretenden Unterl ufe reduziert Die Funktion underflow wird definiert durch Abst tzung auf die Hilfsfunktion uf mit underflow i uf i 0 Die Funktion uf ermittelt f r einen Eingabestrom die Zahl der Unterl ufe die er ausl sen wird Dazu z hlt sie im zweiten Argument die im Puffer gespeicherten Daten Diese Zahl erh ht sich demzufolge beim Empfang eines Datums und reduziert sich bei Ausgabe eines Datums Sind keine Daten mehr vorhanden wird aber eine Anfrage empfangen liegt ein Unterlauf vor Die Funktion uf k nnen wir also rekursiv definieren durch uf 0 uf d i n uf i n 1 uf R oin uf i n 1 firn gt 0 uf R 37 0 1 uf i 0 Gilt f r e
205. mit den neuen Eigenschaften beschrieben werden die wir als r bezeichnen Die neuen Eigenschaften sind selbst wieder eine Black Box Spezifikation bei unver nderter Systemschnittstelle Die Abschw chung wird entsprechend durch eine Disjunktion mit einer Formel p angegeben Wir definieren Definition 4 4 Modifikation von Black Box Spezifikationen Seien Pg und p Black Box Spezifikationen zur Schnittstelle I O Die Wirkung der durch M r r definierten Modifikation auf die Black Box Spezifikation ist definiert durch BA Op dp PAPE VF Die neutrale Modifikation wird offensichtlich durch das Paar true false beschrieben da A true V false Die Modifikationen von zu einem beliebigem Y kann ausgedr ckt werden durch die Modifikation M WV oder durch ein M g Y mit g gt P begr ndet durch die Tautologie V A v W Die Modifikation zu chaotischem Verhalten l t sich mit der Modifikation g true mit beliebigem z beschreiben Die Formel p definiert eine Menge von Stromtupeln die diese Formel erf llen Diese werden aber nicht aus dem Verhalten des modifizierten Systems entfernt wie dies bei der Modifikation von Relationen geschieht Eine unmittelbarere Analogie w re gegeben h tte man die Modifikation mit einer Negation durch A p V p definiert Wir haben Definition 4 Jaber so gew hlt dass sich in p gut die zus tzlichen Eigenschaften des ver nde
206. mmen mit offenen Fragestellungen im n chsten und abschlie enden Abschnitt die ser Arbeit zusammenstellen 6 2 Weiterf hrende Themengebiete Wir identifizieren und beschreiben nun die neu aufgeworfenen Aufgabenfelder die sich zur Fortf hrung dieser Arbeit anbieten Wir k nnen dabei zwischen zwei Ausrichtungen unterscheiden Einerseits bieten sich einige theoretische und grundlagenorientiere Erwei terungen an die das Anwendungsfeld der formalen Fehlermodellierung noch weiter ver gr ern Andererseits ergeben sich Aufgabenstellungen die auf eine Verbesserung der praktischen Verwendbarkeit der vorgestellten Ans tze abzielen Wir skizzieren zun chst die eher theoretischen Themengebiete e Wir haben in dieser Arbeit Systeme auf der Basis des asynchronen und ungezei teten Modells dargestellt Dies bietet eine abstrakte Sicht auf Systeme die aber insbesondere die zeitlichen Aspekte in Systemabl ufen nicht reflektiert Zeit kann im Zusammenhang mit potentiellen Fehlern aber durchaus eine relevante Rolle spielen da Fehler beispielsweise durch Nachrichten erzeugt werden die zu sp t oder zu fr h bertragen werden Fehler k nnen die Performanz von Systemen beeinflussen wenn durch die Ausf hrung einer Fehlerbehandlung die normalen Aktivit ten unterbrochen werden m ssen 162 KAPITEL 6 ZUSAMMENFASSUNG UND AUSBLICK Die bereits erarbeiteten Techniken zur Fehlermodellierung und behandlung sind also auf ein m chtigeres Systemmodell z
207. mponenten Damit erm glichen sie die Formalisierung von Fehlern auf verschiedenen Abstraktionsstufen Auch die sogenannte Schnittstellenverfeinerung die uns im Systemmodell von FOCUS zur Verf gung steht erlaubt die Modifikation von Schnittstellen Eine abstrakte Darstel lung einer Kommunikationsgeschichte kann durch Repr sentations und Abstraktions pr dikate zu einer konkreteren Darstellung in Beziehung gesetzt werden Diese Art der Modifikation ist aber einerseits zu m chtig da mit ihr auch eine Verhaltensver nde rung modelliert werden kann Unser Ziel war eine Trennung der Modifikation von Ver halten und Schnittstelle um die Komplexit t eines Einzelschrittes berschaubar zu halten Andererseits sind Schnittstellenverfeinerungen durch ihre Forderungen an die Repr sentations und Abstraktionspr dikate zu eingeschr nkt um alle Modifikationen beschreiben zu k nnen Modifikationen sind im allgemeinen keine Verfeinerungen son dern erlauben eine wirkliche Ver nderung eines Systems Bei der Definition der Verhaltensmodifikationen wird entsprechend Abbildung 4 2 in den drei Formalismen der Relationen Eigenschaften und Transitionen ein Teil des Ver haltens entfernt und ein anderer Teil hinzugef gt Durch die Klammerung ist eine Reihenfolge dieser Operationen definiert Das Entfernen wird zuerst durchgef hrt das Hinzuf gen danach Diese Reihenfolge ist keinesfalls zwingend und h tte auch anders gew hlt werden k nnen Unsere W
208. mposition Zwei Komponenten S und T mit den Schnittstellen Is Os und Ir Or hei en kom patibel wenn sie keine gemeinsamen Ausgabekan le haben also Os N Or Das aus S und T zusammengesetzte System wird bezeichnet durch SOT und besitzt als Schnittstelle d Iser 2 IsUIr OsU Or d Oset af Os U Or In AbbildungB 5 ist die entstehende Schnittstelle veranschaulicht Die Eingabeschnitt stelle des Gesamtsystems besteht also aus den Eingabekan len der beiden Komponenten ohne diejenigen Kan le die von den Ausgaben der jeweils anderen Komponente schon mit Nachrichten versorgt werden Diese Kan le bleiben aber in der Ausgabe sichtbar so dass sich die Ausgabeschnittstelle als Vereinigung aller Ausgabekan le ergibt Interne Kan le entstehen somit nicht Wir haben diese Wahl getroffen da sie eine Vereinfachung 56 KAPITEL 3 FORMALES SYSTEMMODELL Is Ir U Or gt gt Og Ir S Os N Ir Ig N Ir OrN Is T Ir Is U Os m Or Is Abbildung 3 5 Komposition von Komponenten fiir die Verifikation mit sich bringt indem auf alle Informationen offen zugegriffen wer den kann Die Komposition ist nur fiir zwei Komponenten definiert Durch iterative Anwendung k nnen aber beliebig viele Komponenten zu einem System verbunden werden Die Rei henfolge der Komposition spielt dabei keine Rolle denn sind die Komponenten paar weise kompatibel so sind die resu
209. ms ermitteln zu k nnen Beobachtung Die Beobachtung eines Ausfalls kann f r verschiedene Beobachter kon sistent oder inkonsistent sein Nicht immer nehmen alle Beobachter einen Ausfall auf die gleiche Weise wahr So kann ein Versagen f r einen Systembenutzer erheb liche Einschr nkungen darstellen w hrend es f r einen anderen Benutzer vollkom men unbemerkt bleibt da nur Funktionalit ten betroffen sind die von ihm nicht in Anspruch genommen werden Aber auch bei Verwendung des gleichen Funktio nalit t k nnen durch unterschiedliche Granularit ten der Zeitwahrnehmung von Benutzern Versagen unterschiedlich wahrgenommen werden Versagen mit kon sistenter Beobachtbarkeit stellen im allgemeinen ein kleineres Problem dar wenn Versagen im Rahmen einer automatisierten Fehlerbehandlung erkannt werden sollen 2 1 3 Fehler als Soll Ist Abweichung Die bisher angegebenen Klassifizierungen stellen das breite Spektrum an Interpretati onsm glichkeiten f r den Fehlerbegriff dar wie sie in der Literatur gefunden werden k nnen Wir wollen in diesem Abschnitt verschiedene Fehlerbegriffe durch Abweichun gen eines Ist von einem Soll in Bezug auf verschiedene Aspekte eines Systems charak terisieren Wir beschreiben dazu zun chst ein einfaches Systemmodell und erl utern daran die Attribute eines Systems die uns im Rahmen dieser Arbeit interessieren Die bereits beschriebenen Begriffe Fehlerursache Fehlerzustand und Versagen k nnen wir dann als
210. ms gleich kommt Die Eigenschaften eines Systems sind im wesentlichen unabh ngig von seiner Umgebung und bleiben in jedem Kontext erhalten Dies unterst tzt einen Entwickler in der Handhabung komplexer Systeme F r eine praktische Einsetzbarkeit einer formalen Methodik ist eine Werkzeugun terst tzung absolut unerl lich Mit AUTOFOCUS und seiner Weiterentwicklung im Rahmen des Projektes QUEST 53 steht bereits ein Werkzeug zur Verf gung mit dem sich reale Systementwicklungen durchf hren lassen F r die Modellierung von Fehlern stellt dieses Systemmodell daher eine geeignete Grund lage dar um Fehler auf verschiedenen Abstraktionsebenen repr sentieren zu k nnen Das Modell erm glicht es aus der Kenntnis des Komponentenverhaltens auf das Verhalten des Gesamtsystems zu schlie en nach 57 relevant beim analytischen Umgang mit Fehlern Es ist weiterhin m glich zwischen internen und externen Fehlern zu unter scheiden und die Ausbreitung von Fehlern ber verschiedene Komponenten hinweg zu untersuchen Diese Themen werden in den folgenden beiden Kapiteln behandelt Im Rahmen von FOCUS gibt es alternative Modellierungstechniken die sowohl Zeit als auch Synchronit t betreffen Wir haben uns aus den im folgenden angegebenen Gr nden f r das ungezeitete und asynchrone Systemmodell entschieden e Im sogenannten ungezeiteten Modell wird Zeit nicht modelliert Es ist damit nicht m glich das zeitliche Verhalten eines Systems oder ein
211. mus verf gbar aber eine Implementierung unseres Puffers entsprechend seiner Spezifikation ist nicht in der Lage sich beispielsweise an alle ausgegebenen Nachrichten in o zu erinnern Wir entwickeln den Puffer daher weiter und f hren eine neue mit 0 initialisierte Variable z als Z hler ein Die beiden Transitionen 7 und 72 werden verfeinert indem sie die Variable z nicht mehr beliebig ver ndern d rfen sondern in ihr die L nge von q speichern Die Fehlertransition 73 l t z aber unver ndert Name Pre Input Output Post n 9 lt N DM degrek azr zr i ie oe aa ae a n gt 0 G rtqav z Das System kann nun auf die Variable z zugreifen so dass wir folgende Definition von W w hlen k nnen v amp q z Da wir mit den Beweistechniken aus B 8 2 zeigen k nnen dass z i 0 eine Invariante unseres fehlerbehafteten Puffers darstellt ist W eine angemessene Charakterisierung des Daten verlusts d h mit der Variablen z und den Verfeinerungen der Transitionen wurde das System auf geeignete Weise erg nzt um einen Zustand q i 0 vom System erkennbar zu machen Die Variable z stellt Redundanz entsprechend B 2 2 dar die die Fehlererkennung durch das System selbst erm glicht Wir m ssen nun noch die Korrektheit Lebendigkeit und Stabilit t von W nachweisen In un serem Fall gilt eine st rkere Aussage die diese drei Eigenschaften impliziert denn der Puffer befindet sich in einem durch 73 verursacht
212. n Beispiel BII haben wir bewiesen dass 0 i i eine Invariante von Merge ist Da auch 7 C i und damit i lt i f r alle Eingabestr me i eine Invariante in jedem System ist k nnen wir Merge inv 0 lt i folgern Dieses Pr dikat ist gem den Kriterien aus IO admissible so dass wir unter Anwen dung obiger Regel Merge gt 0 lt i i2 ableiten Unter Verwendung der Regel f r Fortschritteigenschaften k nnen wir aus dem Resultat in Beispiel BIT2 folgern dass Merge gt 0 gt i a Kombiniert man beide Resultate erhalten wir mit Merge gt 0 1 i2 die erwartete Black Box Eigenschaft von Merge 3 9 VERFEINERUNGEN 67 3 9 Verfeinerungen Die Entwicklung eines komplexen Systems kann nicht in einem einzigen Schritt erfolgen Eine Systementwicklung muss mehrere Phasen durchlaufen die sich von der Erfassung von Systemanforderungen bis zu einer konkreten Implementierung und Integration von Systemkomponenten erstrecken Dabei wird ein System typischerweise zun chst rela tiv abstrakt beschrieben um eine grobe Strukturierung des Systems zu erm glichen Im weiteren Entwicklungsproze werden durch Entwurfsentscheidungen mehr und mehr Details erg nzt die alle Aspekte eines Systems betreffen k nnen Beispiele f r Entwurfs entscheidungen sind die Wahl einer Systemarchitektur die Wahl eines Datenmodells und die Wahl einer Systemplattform Derartige Entscheidung habe
213. n wie sie bei der Modifikation von Systemen entsprechend angepa t werden k nnen mit dem Ziel m glichst wenig von dem bereits geleisteten Beweisaufwand zu verlieren 3 8 3 Black Box Eigenschaften von Transitionssystemen Die Eigenschaften von Zustandsmaschinen aus Abschnitt 8 8 1 die mit den Diagrammen aus Abschnitt B 8 2 bewiesen werden k nnen machen Aussagen ber die Zust nde des Transitionssystems Eine Black Box Eigenschaft dagegen spricht nur ber die nach au en sichtbaren Ein und Ausgabestr me Der bergang zwischen beiden Sichten kann mit zwei Regeln hergestellt werden die in 0 hergeleitet und ausf hrlicher diskutiert werden Sie lauten SIF inv er Slk o kAk lt l Ye 0 gt k gt s gt S gt 0 gt wobei und auch nur Variable aus J U O enthalten d rfen Das Pr dikat adm f r admissible stellt sicher dass die Eigenschaft auch f r unendliche Str me g ltig ist wenn sie f r alle endlichen Approximationen erf llt ist Eine Invariante gilt dann auch f r die unendlichen Ein Ausgabestr me die im Grenzwert erreicht werden Die Fortschrittseigenschaft f hrt zu einer iterierten Verl ngerung einer Ausgabe solange der Wert noch nicht erreicht ist Im Falle eines unendlichen Ablaufs wird dieser Grenzwert letztendlich erreicht oder sogar bertroffen Beispiel 3 13 Black Box Eigenschaften von Merge Wir verwenden die beiden Regeln um eine Black Box Eigenschaft von Merge herzuleiten I
214. n Daten oder der Verlust und die Verf lschung von Daten bei der bert ragung sind auf diese Weise gut darstellbar Man ist in einem solchen Fall daran interessiert wie sich die Black Box Eigenschaften des so modifizierten Systems ver ndern also ob zum Beispiel sicherheitskritische Eigenschaften verletzt werden Die Idee der korrespondierenden Modifikationen wird in Abbildung Z 6 dargestellt Ein Transitionssystem S habe eine Eigenschaft Beide Beschreibungen des Systems wer den passend modifiziert so dass das modifizierte System die modifizierte Eigenschaft hat Wir definieren dies formal Definition 4 13 Korrespondierende Modifikationen Ein Transitionssystem S habe eine Eigenschaft also S Ferner sei MS eine Modifikation von S und M eine Modifikation von Die beiden Modifikationen MS und M hei en korrespondierende Modifikationen zu S und wenn gilt SAMS aM Diese Definition von korrespondierenden Modifikationen ist relativ zu konkreten S und Dies ist begr ndet durch die Beobachtung dass korrespondierende Modifikationen 4 5 EIGENSCHAFTEN VON MODIFIKATIONEN 111 S Modifikation SAME H SAM Abbildung 4 6 Korrespondierende Modifikationen im allgemeinen nicht auf beliebige Systeme anwendbar sind Ein offensichtlicher Grund ist dass die Modifikationen von Transitionssystemen konkreten Bezug auf die Namen von Variablen nehmen Zwei Transitionssysteme die sich n
215. n Einflu aufeinan der und m ssen daher sehr sorgf ltig gew hlt werden Die verschiedenen in einem Entwicklungsproze entstehenden Systemversionen sollen nat rlich nicht unabh ngig voneinander sein sondern sind idealerweise durch soge nannte Verfeinerungen verbunden Liegt eine Verfeinerung zwischen zwei Varianten eines Systems vor so beschreibt die verfeinerte Variante im wesentlichen das gleiche System wie die abstrakte Sicht darf aber zus tzliche Eigenschaften und Konkretisie rungen aufweisen Es ist also formal zu definieren wann ein System eine Verfeinerung oder Implementierung eines anderes Systems darstellt Wir wollen dazu in diesem Abschnitt den Verfeinerungsbegriff im Rahmen unseres Systemmodells vorstellen Dazu beschreiben wir kurz die beiden Verfeinerungsrelatio nen der Verhaltens und der Schnittstellenverfeinerung Eine deutlich ausf hrlichere Einf hrung in diese Konzepte findet sich in BJ 3 9 1 Verhaltensverfeinerung Die Verhaltensverfeinerung erlaubt es ein abstraktes System mit einem konkreten Sys tem in Beziehung zu setzen das die gleiche Schnittstelle hat aber zus tzliche Forde rungen an das Verhalten aufweisen kann Definition 3 14 Verhaltensverfeinerung Seien zwei Systeme mit gleicher Schnittstelle durch die Relationen Ry und Ra be schrieben System Ra ist eine Verhaltens Verfeinerung von R notiert durch Ri Ra wenn jedes Verhalten von Ra auch ein Verhalten von R ist R C Ry
216. n Kanals auf dem Ausgabekanal wieder ausgeben Die Auswahl des ignorierten Kanals soll dabei nichtdeterministisch erfolgen 4 2 1 Modifikationen von Relationen Das Verhalten wird semantisch als eine Relation zwischen Ein und Ausgabestr men repr sentiert also durch die Menge aller Stromtupel die in dieser Relation stehen Diese Menge kann nur auf zweierlei Arten modifiziert werden Einerseits durch die Hinzunahme weiterer Stromtupel die zus tzliche Freiheiten im Verhalten des Systems bedeuten andererseits durch das Entfernen von Stromtupeln Da die Linkstotalit t nicht gef hrdet werden darf muss nat rlich f r jede m gliche Eingabe noch immer ein Stromtupel in der Relation erhalten bleiben Diejenigen Stromtupel die ein modifiziertes System zus tzlich enth lt fassen wir in einer Menge F zusammen Die Menge der Stromtupel die das modifizierte System nicht mehr enth lt nennen wir E Die Wahl des Bezeichners F orientiert sich am Begriff des Fehlers oder auch an fault und failure Transiente Fehler in einem System sind meist unerw nschte Auspr gungen des 84 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Verhaltens die ein System zus tzlich aufweisen kann also ein erweiterter Nichtdeter minismus der genau durch die Menge F beschrieben wird Das Entfernen von Teilen des Verhaltens geht mit einer h heren Priorisierung des verbleibenden Verhaltens ein her was einem Exception Mechanismus hnelt Dies wird illustriert durch
217. n Programmierung Diese Technik ist eng verwandt mit der Triple Mo dular Redundancy Die verschiedenen Versionen werden parallel ausgef hrt und das Ergebnis durch einen Voter verglichen wie in Abbildung 2 9 dargestellt Ein geeigneter Voter muss nicht f r alle Arten von Software existieren Es k nnen f r eine Berechnung durchaus mehrere Resultate korrekt sein so dass es durch reine Mehrheitsbildung nicht m glich ist korrekte von falschen Ergebnissen zu unterscheiden Unter Umst nden k nnen Toleranzen definiert werden mit denen hnliche Resultate als bereinstimmung interpretiert werden Die Abarbeitung der verschiedenen Versionen muss effizient und nebenl ufig erfol gen k nnen Bei sequentieller Ausf hrung m te die Summe aller Laufzeiten aufge wendet werden bei paralleler Abarbeitung ergibt sich noch das Maximum der Lauf zeiten der Einzelkomponenten Die Komponenten m ssen dar ber hinaus vollkommen eigenst ndig ablaufen k nnen ohne eine ver ndernde Wirkung auf ihre Umgebung zu haben Damit m ssen sie eine noch st rkere Eigenschaft erf llen als f r die R cksetz barkeit notwendig ist 34 KAPITEL 2 DER FEHLERBEGRIFF m gt Version 1 Version 2 Voter gt _ gt Version 3 Abbildung 2 9 N Versionen Programmierung Das Problem beider Ans tze ist die Bereitstellung einer echten vielf ltigen Diversi fikation zwischen den Versionen Man ve
218. n Verhalten ist unmittelbar f r die Umgebung sichtbar da sie in der Black Box Sicht formuliert wird F r die Transitionssysteme ist ein Ablauf der nicht dem spezifizierten System ent spricht nicht unbedingt als Versagen zu bezeichnen da eine Abweichung auch lediglich intern auftreten kann und damit nur einen Fehlzustand darstellt Wir definieren das Versagen eines Systems daher auf folgende Weise Ein Versagen tritt in einem Zustand auf wenn alle Zust nde die von au en betrachtet identisch mit ihm sind Fehlzust nde sind Dies bedeutet dass bei einem Versagen das nach aussen sichtbare Verhalten eines Transitionssystems nur aufgrund fehlerhafter Transitionen zustande kommen konnte Definition 4 9 Versagen 1 Seien eine Black Box Spezifikation S und eine Modifikation M gegeben Die Men ge aller Verhalten die ein Systemversagen aufweisen wird definiert durch FAILURES S M i 0 i 0 SAM A i 0 S 2 F r ein Transitionssystem S und eine zugeh rige Modifikation M wird die Menge der Zust nde die ein Systemversagen beschreiben definiert durch FAILURES S M a Y8 o 872 a gt 6 ERROR S M Das Versagen von Systemen l t sich im Rahmen der Black Box Sicht weiter vereinfa chen Aufgrund der Tautologie PAPr Vr AA amp rana k nnen wir die Menge der Versagen auch folgernderma en charakterisieren 96 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Proposition 4 4 Black
219. n eines Transitionssystems definieren wir alle Stromtupel die im Grenzwert einer Systemausf hrung auf den Kan len gelesen bzw produziert wurderft IS Fam 2n Y1 Ym FE S Vj 1 n 00 ij ay A ee a Eine ausf hrliche Diskussion dieser Definitionen findet sich in IQ F r die Verhaltensre lation eines wohldefinierten Transitionssystems ist sichergestellt dass sie linkstotal und monoton ist Die Monotonie folgt unmittelbar aus der Forderung d aus Definition BB Da die Umgebungstransition immer schaltbereit ist kann auf den Eingabekan len jeder beliebige Eingabestrom erzeugt werden W hlt man eine geeignete Darstellungsform f r Transitionssysteme so k nnen darin nur wohldefinierte Systeme dargestellt werden Zwei derartige Darstellungsformen werden wir nun pr sentieren Wir m ssen hier unterscheiden zwischen den Kanalnamen i bzw oj und den Str men x bzw y die auf den Kan len transportiert werden 3 6 ZUSTANDSTRANSITIONSSYSTEME 53 3 6 1 Graphische Darstellung Ein Transitionssystem hat eine einfache Funktionsweise Es befindet sich in einem Zu stand und geht ausgel st durch Eingaben in einen Nachfolgezustand ber wobei es Ausgaben produzieren und lokalen Variablen neue Werte zuweisen kann W hlt man Kontrollzust nde als Knoten und die Transitionen als Kanten so lassen sich Transiti onssysteme sehr intuitiv als gerichtete Graphen darstellen wie beispielsweise in 1
220. n hier ver einfachend von nur einem Ein und Ausgabekanal aus Ein Strompaar i 0 repr sen tiert ein zul ssiges Verhalten des fehlerhaften Systems mit potentiellem crash failure Fehlermodell wenn die Verl ngerung o von o ein Normalverhalten darstellt Op AoleoLo A amp 0 o Im Formalismus der Transitionssysteme modellieren wir dieses Fehlermodell durch die Hinzunahme einer neuen in A noch nicht enthaltenen booleschen Variable die wir mit stop bezeichnen Die Hinzunahme kann entsprechend Kapitel 2 3 zun chst verhaltens neutral erfolgen Der Wahrheitswert der Variable gibt an ob das System schon seinen Stoppzustand erreicht hat In einem solchen Fall darf keine der Transitionen T schaltbereit sein Daher sind alle Transitionen aus dem System zu entfernen die von einem Zustand a ausgehen in dem a stop true gilt Dies wird durch folgende Definition von E aus der Modifikation M E F erreicht ve a B a stop true U a B a stop B stop Wie in Abschnitt amp 2 3 beschrieben entfernen wir standardm ig mit diesem E zus tz lich alle Transitionen die den Wert der neuen Variablen ndern k nnten Nun erg nzen wir mit Hilfe von F eine stets schaltbereite Transition Tso die jederzeit in der Lage ist den Wert von stop auf true zu setzen und damit das System zu blockieren p a Name Pre Input Output Post Tstop true stop true Da keine Transition im System enthalten ist die
221. n korrekt erfa t werden k nnen pr zise Spezifikationen formuliert ein geeigne tes Systemdesign erstellt Module implementiert und integriert werden Dies hat unter Einhaltung von Einschr nkungen verschiedener Ressourcen wie finanzieller Mittel Ar beitskraft und Zeit zu geschehen Ein Hilfsmittel sind formale Methoden die nicht nur eine pr zise Sprache zur Formulierung von Systemen und ihrer Eigenschaften bieten sondern auch einen Kalk l zur Verifikation von Eigenschaften Eine Systementwicklung wird typischerweise durch Werkzeuge unterst tzt die zum Beispiel Konsistenzen und Vollst ndigkeiten zwischen verschiedenen Dokumenten berpr fen Code aus Spezifika tionen und Prototypen generieren und Gruppenarbeit unterst tzen Trotz gewisser Fortschritte dieser Disziplin in den letzten Jahren kann aufgrund der ho hen und weiter wachsenden Komplexit t der Systeme selten vollkommene Fehlerfreiheit erreicht werden Ein Entwicklungsproze umfa t in der Regel daher auch Reviews von Beschreibungs und Spezifikationsdokumenten mit denen versucht wird Fehler in ei nem System seinen Anforderungen und seiner Implementierung aufzudecken um diese anschlie end zu beheben Systeme und ihre Komponenten werden bevor sie in ihrer ei gentlichen Umgebung zum Einsatz kommen auch immer durch verschiedenartige Tests gepr ft um somit nach enthaltenen Fehlern zu suchen Versagt ein Testlauf werden die verantwortlichen Fehler lokalisiert und entfernt
222. n und diese nach M glichkeit sogar zu beweisen Die in diesem Ansatz vorgeschlagenen Anpassungen von Beweisdiagrammen k nnten gut durch ein Werkzeug unterst tzt werden das die Auswirkungen einer Modifika tion ermittelt und bereits gezeigte und neue entstehende Beweisziele verwaltet Die Beweisverpflichtungen sind in den meisten F llen zwar einfach k nnen aber in gro er Zahl auftreten Ohne Werkzeugunterst tzung besteht die Gefahr dass hier einzelne Be weisverpflichtungen bersehen werden oder aufgrund vermeintlicher hnlichkeiten und Symmetrien inkorrekte Analogieschl sse gezogen werden Auch in BI wird der Ansatz diskutiert Beweise an ver nderte Systeme anzupassen um damit Fehlertoleranz nachzuweisen Anhand eines Beispiels wird demonstriert wie gro e Teile eines urspr nglichen Beweises f r den Beweis des ver nderten fehlerbehafteten Systems wiederverwendet werden k nnen Die Autoren beschr nken sich allerdings auf reine Sicherheitsaussagen und auf ein relativ einfaches Fehlermodell Auch sie bewerten die Anpassung von Beweisen als ein interessantes und offenes Forschungsgebiet Einen weiteren Ansatz zur Wiederverwendung von Beweisen beschreibt 54 5 8 Zusammenfassung und Diskussion Die Einf hrung formaler Begriffe zur Beschreibung von Modifikationen von Systemen mit einer Untersuchung ihrer Eigenschaften ist als Selbstzweck nicht ausreichend Sie m ssen dar berhinaus in einem Entwicklungsproze sinnvoll eingesetzt
223. n zustandsbasierten Systemen Ihre Tauglichkeit wird wie in formalen Methoden h ufig nur durch kleine eher akademische Beispiele veranschau licht so dass Schwierigkeiten in einer konkreten Anwendung nicht untersch tzt werden d rfen Es ist daher zu vermuten dass die Techniken in der dargebotenen Form in realen Anwendungen noch nicht brauchbar eingesetzt werden k nnen G rtner greift in 28 diesen Ansatz auf und differenziert weiter nach Sicherheits und Lebendig keitseigenschaften der Systeme 2 2 FEHLERTOLERANZ 29 Wir werden in Kapitel 4 versuchen diesen Defiziten zu begegnen Wir werden dazu auch das Entfernen von Transitionen zulassen und Fehler auch auf der Ebene der Systemei genschaften beschreiben Das Systemmodell wird eine Unterscheidung von internen und externen Fehlern zulassen und die Zusammenh nge zwischen Komponenten und Sys temfehlern werden untersucht 2 2 2 Techniken der Fehlertoleranz Formale Modelle wie wir sie im vorherigen Abschnitt vorgestellt haben bieten eine pr zise Sprache mit der Fehlertoleranz und ihre Eigenschaften formuliert und unter sucht werden k nnen Mit dieser Sprache k nnen Techniken die sich in fehlertoleranten Systemen finden ausgedr ckt und untersucht werden In diesem Abschnitt wollen wir die Prinzipien fehlertoleranter Techniken beschreiben Dazu werden wir M glichkeiten zur Fehlererkennung Prinzipien der Behebung und eine Klassifikation von Redundanz skizzieren und schli
224. nd und Fehlerursache wird deutlicher wenn man den Unterschied bei deren Behebung betrachtet Ein bekannter und lokalisierter Fehlerzustand l t sich zur Laufzeit korrigieren indem die falschen Werte durch kor rekte ersetzt werden Die Fehlerursache ist aber im allgemeinen viel schwieriger zu ent fernen da beispielsweise das Design eines Systems oder sein Programmcode korrigiert werden m ssen Eine wichtige Klasse von Fehlerursachen sind die externen Fehler Da wir die Umgebung eines Systems als nicht kontrollierbar verstehen liegt die Fehlerursache hierbei in den 2 1 FEHLER 13 nicht ad quat erfa ten Annahmen an die Umgebung in der das System eingesetzt wird Das Verhalten der Umgebung kann in einem solchen Fall zu Fehlerzust nden und zum Versagen des Systems f hren Wird ein solches Versagen durch einen Menschen ausgel st der immer zur Systemumgebung geh rt so bezeichnet man diesen externen Fehler als Fehlhandlung engl mistake Auch den Begriff der St rung wollen wir den Fehlerursachen zuordnen Nach 20 ver steht man unter einer St rung sowohl technisch bedingte Ist Soll Abweichungen von Systemkomponenten als auch Umgebungseinfl sse die wir bereits als externe Fehler charakterisiert haben Der Begriff der St rung wird vorwiegend verwendet um den tempor ren Charakter einer Fehlerursache zu beschreiben Dabei unterscheidet er nicht zwischen internen und externen Fehlerursachen Zusammenh nge In der Literatur
225. ndlung auf true gesetzt beim Verlassen wieder auf false ansonsten ndert sie ihren Wert nicht Die Transitionen des Systems S sind wegen E w hrend der aktiven Ausnahmebehandlung also nicht schaltbereit und nur die Transitionen aus C k nnen schalten Das Pr dikat WV eignet sich nur bedingt um Transitionen von T w hrend einer Ausnahmebehandlung zu vermeiden Das Ziel der Abarbeitung wird es oft sein einen Fehlerzustand zu korrigieren und damit V ung ltig zu machen Transitionen aus T k nnten also zu fr h wieder schaltbereit werden Daher ist eine neue Variable xp notwendig Beim Start der Ausnahmebehandlung wird eine Transition ausgef hrt die in einen Zu stand 3 f hrt f r den das Pr dikat Entry gilt der aber ansonsten dem Ausgangszustand a m glichst hnlich ist hnlichkeit wird hierbei verstanden als eine maximale Uber einstimmung in der Belegung aller Variablen Typischerweise wird das Pr dikat Entry den Kontrollzustand o auf einen neuen Wert setzen und gegebenenfalls Variablen in itialisieren aber sonst keine Aussagen ber die Variablen des Systems machen Mit obiger Definition bleiben diese Variablen bei Ausf hrung dieser Transition tats chlich unver ndert wie man es auch bei einer operationellen Sicht erwarten w rde Die expli ziten Zuweisungen werden erf llt w hrend alle brigen Variablen unangetastet bleiben Beim R cksprung aus einem Zustand in dem Erit gilt in einen Zustand in dem gilt bleiben in gle
226. ne derartige Metrik erm glicht eine Quantifizierung des Schweregrades von Fehlern Mit einer derartigen Metrik kann der qualitative Begriff zu Fehlertoleranz definiert werden der als D mpfung verstanden wird Ein System ist feh lertolerant wenn die Wirkung die ein Fehler einer Systemkomponente auf ein System zeigt einen geringeren Schweregrad hat als der Schweregrad des verursachenden Fehlers In engem Zusammenhang mit einer Metrik ber Fehlern steht ein Begriff der die hnlichkeit von Verhalten ausdr ckt Zwei Verhalten sind hnlich wenn der als Modifikation ausgedr ckte Unterschied angemessen klein ist Eigenschaften wie graceful degradation k nnen damit explizit und pr zise dargestellt werden Es ist w nschenswert Aussagen ber Systeme aus den Aussagen ber ihre Komponenten abzuleiten In Abschnitt amp 5 2 haben wir bereits einige hierf r relevante Zusammenh nge dargestellt Es ist lohnenswert weitere Beweis regeln zu finden um komplexere derartige Ableitungen m glich zu machen So ist es beispielsweise interessant aus beobachteten Fehlern des Gesamt systems auf die potentiellen Fehlerursachen innerhalb der Komponenten des Systems R ckschl sse ziehen zu k nnen Zus tzliche Beweisregeln werden es erm glichen mit Modifikationen sozusagen rechnen zu k nnen Ein weiteres interessantes Ziel f r weiterf hrende Untersuchungen sind Kri terien und Hinweise zum konstruktiven Ermitteln korrespond
227. nen bei Transitionssystemen Seien zwei kompatible Transitionssysteme S und Sa gegeben und sei ihre Komposition S Q S2 definiert wie in Abschnitt 3 7 insbesondere sei die Transitionsmenge T des komponierten System also gegeben durch T T x T U T x T Seien weiterhin M E1 F1 und Ma E2 Fa Modifikationen der beiden Teilsys teme Die Modifikation M E F definiert durch E E amp T5 U E2 amp Tf 4 5 EIGENSCHAFTEN VON MODIFIKATIONEN 109 beschreibt damit die entsprechende Modifikation des zusammengesetzten Systems so dass also gilt S Q S2 A E F Sy A F4 F Q S24A E2 F Zum Nachweis dieser Aussage expandiert man die entsprechenden Definitionen zu T pa T U Tz x T Ei Pa Ty U E2 amp T U Fy gt T U Fa Da Tf T1 1 U F1 bs Ts U T2 E2 U F2 amp T und zeigt dies unter Verwendung der folgenden Gleichheiten f r die Operatoren op VU X Z op Y x Z X op Y sZ Der vorgestellte Formalismus kann verwendet werden um die Auswirkungen zu berech nen die die Fehler in den Komponenten eines Systems haben Wir illustrieren dies mit folgendem Beispiel Beispiel 4 10 Fehlerfortpflanzung In Abschnitt B7 wurden die Komponenten Merge und Split zu einem System Multiplex kom poniert von dem wir bereits die Eigenschaft d D o i A Do iz D o 0 A DXHo 02 nachgewiesen haben In Beispiel AM haben wir eine Modifikation von M
228. nen durchzufiihren Wir werden dies in Abschnitt 8 10 diskutieren In manchen F llen lassen sich allerdings fiir Systeme nur komplizierte und unhandliche explizite Black Box Spezifikationen finden oder es gehen durch die damit verbundene Abstraktion Informationen verloren die eine Verifikation erschweren k nnen F r derartige Situationen ist ein Formalismus zur Komposition von Zustands maschinen hilfreich In Kapitel 4 5 2 werden wir auf der Basis der hier vorgestellten Komposition die Aus wirkungen ableiten die Fehler in Komponenten auf die Gesamtsysteme haben die sie konstituieren 3 7 1 Komposition von Black Box Spezifikationen Die Black Box Spezifikation eines komponierten Systems deren Komponenten selbst durch Black Box Spezifikationen beschrieben sind ist sehr einfach definiert als Kon junktion 58 KAPITEL 3 FORMALES SYSTEMMODELL Definition 3 10 Black Box Komposition Seien S und T Black Box Spezifikationen zweier kompatibler Komponenten S und T Das Verhalten von T ist beschrieben durch BUNTE Ein Stromtupel von Ein und Ausgabestr men beschreibt ein m gliches Verhalten eines komponierten Systems wenn diese Stromtupel auch einem m glichen Verhalten der Einzelkomponenten entsprechen Beispiel 3 9 Black Box Spezifikation des Multiplexers Die Komponente Split k nnen wir durch folgende Black Box Spezifikation definieren Split g o D amp o A o Do F r j 1 2 erscheinen auf dem Kanal o
229. ner nicht giiltigen Fehlertoleranz zu dass ein System durch Inte gration weiterer Mechanismen fehlertolerant gemacht wird Die Integration wird durch einen Operator R ausgedriickt und das verbesserte weiterentwickelte System durch R P Die Fehlertoleranzaussage lautet dann F R P gt S Janowski Auch Janowski hat in seinen Arbeiten 85 36 37 B8 Transitionssysteme als Systemmodell gew hlt Er konzentriert sich ebenfalls auf maskierende Fehlertoleranz und dr ckt sie mit Hilfe einer Bisimulation aus die die zus tzlichen Fehlertransitionen ber cksichtigt Ein Proze Q ist eine fehlertolerante Implementierung eines fehlerfrei en Spezifikationsprozesses P wenn e jeder Schritt von P durch einen fehlerfreien Schritt von Q beobachtungs quivalent simuliert werden kann und e jeder m glicherweise durch Fehler beeinflu te Schritt von Q durch einen na t rlich fehlerfreien Schritt von P simuliert werden kann Wichtig ist hierbei dass ein Schritt von P durch Q simuliert werden kann ohne dass dabei Fehlertransitionen verwendet werden k nnen Janowski vertritt die These dass man sich auf das Auftreten von Fehlern nicht verlassen kann Fehler passieren seiner Ansicht nach also nichtdeterministisch unkontrollierbar und unvorhersehbar Er kann demzufolge mit seinem Ansatz permanente Fehler wie beispielsweise Ausf lle von Kom ponenten und Designfehler in der Software nicht untersuchen Janowski bietet eine erweiterte Version des
230. nkung bedeutet informell dass gewisse Eingaben nicht mehr auftre ten auch wenn f r sie eine Reaktion definiert w re F r die noch immer m glichen verbleibenden Eingaben bleibt die Ausgabe nat rlicherweise definiert und unver ndert 82 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Diese Probleme legen die in dieser Arbeit befolgte Konsequenz nahe auf eine Ein schr nkung der Schnittstelle zu verzichten Im Gegensatz zur Erweiterung der Schnitt stelle die durchaus f r eine Anpassung eines Systems an ver nderte Neben und Um gebungsbedingungen n tig ist kann auch ohne eine formale Unterst tzung der Ein schr nkung von Systemschnittstellen eine Komponente mit allen Freiheiten beliebig weiterentwickelt werden Bestimmte Kan le existieren in diesem Fall weiterhin treten also in Form von Platzhaltern in den Tupeln auf auch wenn sie nicht mehr in die Funktionalit t eingehen also ihre Variablen nicht mehr in den Formeln f r Verhaltens beschreibungen oder den Eingabemustern von Transitionssystemen erscheinen Die Beschr nkung der Eingabe an ein System entspricht einer st rkeren Bedingung die die Systemumgebung erf llt Unter st rkeren Umgebungsbedingungen weist ein System im allgemeinen auch st rkere Eigenschaften auf f r die es im Rahmen der Verifikation m glich sein muss dass diese formal gezeigt werden k nnen Dies ist aber auch ohne eine formale Schnittstellenbeschr nkung m glich Durch die Formulierung einer Um gebung
231. ns if an error occurs e to specify the right thing happens if an error occurs e to make sure this error never occurs Seite 3 Ian Sommerville fordert in 62 die m glichen Versagen explizit in Spezifikationen auf zunehmen um damit mit diesen umgehen zu k nnen When writing a reliability specification the specifier should identify different types of failure and consider whether these should be treated differently in the specification Seite 357 Lee und Anderson fordern eine Beschreibungstechnik in der das normale Verhalten vom Sonder bzw Fehlerverhalten getrennt gehalten wird 44 it is highly desirable that a framework is adopted in which the normal activity of the system is clearly distinguished from its abnormal i e fault tolerance activity Seite 245 Die Defizite die sich sowohl durch die unklaren Begriffe im Umfeld von Fehlern ergeben als auch durch den unsystematischen Umgang mit Fehlern im Rahmen formaler Me thoden sind also klar erkennbar Diese Arbeit hat sich zum Ziel gesetzt diese Defizite zu reduzieren 1 4 Ziel Das Ziel der Arbeit das durch die beschriebenen Defizite motiviert wurde wird nun explizit und zusammenfassend formuliert Die formale Methodik FOCUS wird erweitert um Begriffe und Vorgehens weisen die einen expliziten Umgang mit verschiedenartigsten Fehlern ih ren Eigenschaften und Auswirkungen im Rahmen einer Systementwicklung 1 5 BERBLICK 7 f r verteilte reaktive System
232. nte Merge aus Beispiel die durch M so ver ndert wurde dass sie nur noch von einem Kanal liest Die Modifikation M soll den Verlust einzelner Nachrichten auf den Eingabekan len modellieren Dies wird spezifiziert durch F mit Name Pre Input Output Post F T5 4 d Zu ze T6 i d Von der Kombination M M erwarten wir dass sie zu einer Komponente f hrt die nur noch von einem Kanal liest aber auf diesem auch Nachrichten verlieren kann Es liegt aber keine Unabh ngigkeit der Modifikationen vor da durch M mittels E alle Transi tionen entfernt werden die c ver ndern die neuen Transitionen in F enthalten aber die Variable c nicht und k nnen sie daher auf beliebige Werte setzen Die Eigenschaften aus Proposition JG gelten hier in der Tat nicht W hrend MergeAM AM das erwartete Verhalten beschreibt kann sich MergeA M A M nach dem Verlust eines einzelnen Datums f r einen neuen Kanal c entscheiden W hlen wir c c als Nachbedingung von 75 und 76 k nnen wir einen Konflikt zwischen M und M vermeiden Die Modifikationskomponente die sich durch die Kombination zweier Modifikationskom ponenten ergibt ist naheliegend Sie wird durch die normale Komponentenkomposition unseres Systemmodells dargestellt also durch M M Ma Das Ergebnis ist oft von einem allgemeineren Typ als der Typ der einzelnen Modifikationskomponenten und f hrt meist zu dem in Abbildung 4 3 d dargestellt
233. ntr chtigt wird Spielt das zeitliche Verhalten keine Rolle kann man also die folgende Fehlertoleranz Aussage treffen Das System ist bez glich omission failures der bertragungskan le maskierend fehlertolerant Im allgemeinen m chte man aber sehr pr zise Aussagen ber die Auswirkungen von Feh lern auf ein System machen Dazu ist es notwendig sowohl die Systeme ihre Fehler als auch die Abweichungen vom Normalverhalten unter Einflu der Fehler zu beschreiben Mit formalen Techniken kann dabei die h chste Pr zision erreicht werden Im n chsten Abschnitt geben wir einen kurzen berblick ber existierende formale Ans tze die den Begriff der Fehlertoleranz definieren Der in den folgenden Kapiteln B und vorgestellte Formalismus wird diese Ans tze verallgemeinern und erg nzen 2 2 1 Formale Ans tze Wir werden in diesem Abschnitt formale Ans tze und Definitionen zur Fehlertoleranz vorstellen Wir diskutieren dazu die Ans tze von Zhiming Liu und Mathai Joseph 47 Anish Arora und Sandeep Kulkarni 5 sowie Thomsz Janowski 36 die auch von Felix Gartner in 28 als die wesentlichen bekannten Arbeiten identifiziert werden Um Fehler und Fehlertoleranz formal ausdr cken zu k nnen mu zun chst definiert werden was ein System und sein Verhalten ist Die genannten formalen Ans tze die wir im folgenden kurz vorstellen werden verwenden alle eine hnliche Fehlermodellierung auf Grundlage verwandter Systemmodelle d
234. odifikationen ist allerdings beschr nkt wenn spezielle verfeinerte Fehlermodelle spezifiziert werden sollen die Zusammenh nge von auftreten den Fehlern in verschiedenen Komponenten eines zusammengesetzten Systems beschrei ben Dies kann mit dem Beispiel eines Triple Modular Redundancy Systems beschrieben in Kapitel 2 2 2 veranschaulicht werden Maskierende Fehlertoleranz kann im allgemeinen nur sichergestellt sein wenn maximal eine der drei replizierten Komponenten versagt F r einen formalen Nachweis der Fehlertoleranz muss diese Voraussetzung explizit re pr sentiert werden Dazu schlagen wir folgendes Verfahren vor e Das Versagen der drei replizierten Komponenten wird gekoppelt an einen Ora kelstrom den die Komponenten zus tzlich als Eingabe erhalten Dieser Strom typischerweise vom Typ true false gibt an ob eine Komponente versagen darf e Die Voraussetzungen die an das Auftreten der Versagen gestellt werden k nnen durch ein Pr dikat ber den Orakelstrom ausgedr ckt werden oder durch eine virtuelle Komponente die den Orakelstrom erzeugt In Abbildung B I haben wir eine virtuelle Komponente V und die gestrichelt darge stellten Kan le f r die Orakelstr me f r ein Triple Modular Redundancy System vi sualisiert Signalisiert die Komponente V immer nur maximal einer Komponente die Erlaubnis zum Versagen kann f r das Gesamtsystem maskierende Fehlertoleranz nachgewiesen werden Die Komponente V wird nicht imp
235. ollen die in der Definition auftretenden Einschr nkungen erl utern Die Men ge A definiert die zus tzlichen Variablen die vom System kontrolliert werden k nnen Typischerweise enth lt sie eine Variable f r einen Kontrollzustand und Variablen zum Speichern von Daten Gem a wird f r jeden Eingabestrom i eine Variable i auf genommen Diese beschreibt den Teil der Eingabe der bereits vom Eingabestrom i konsumiert wurde also einen endlichen Pr fix von i Bei Start des Systems wurden noch keine Eingaben konsumiert gefordert in b Die ersten beiden Glieder der Kon junktion in d stellen weitere Forderungen sicher Da das Lesen von Nachrichten nicht r ckg ngig gemacht werden kann kann bei jedem Schritt also f r jede Transition der konsumierte Teil nur l nger werden und es k nnen nur Nachrichten gelesen werden die tats chlich auf dem Kanal liegen Wir fordern nicht dass jedes System mit leeren Ausgabekan len starten muss so dass spontane initiale Ausgaben spezifiziert werden k nnen Da die Eingabe an ein System von diesem nicht kontrolliert werden kann darf auch die Initialbedingung die Belegung der Eingabekan le nicht einschr nken Bedingung c stellt sicher dass beliebige Eingaben m glich sind und nur Anforderungen an die kontrollierten Variablen in O U A gestellt werden Wir lassen weiterhin nur Systeme zu deren Transitionen sicherstellen dass Ausgaben des Systems nicht zur ckgenommen werden und dass auch die
236. onen von einem Zustand s S wieder in einen Zustand in 5 f hren Ein Zustand spr dikat beschreibt also eine Invariante Betrachtet man nun zus tzliche als Fehler bewertete Transitionen so k nnen neue Zust nde erreichbar werden die durch ein Zu standspr dikat T charakterisiert werden Mit diesem Pr dikat kann eine Aussage ber Fehlertoleranz gemacht werden denn es beschreibt die Abweichung des Systemverhal tens unter dem Einflu von Fehlern Die Autoren formulieren folgende drei Bedingungen die in Abbildung 2 5 veranschaulicht werden e T umfa t die Normalzust nde S das hei t es gilt in jedem Zustand in dem auch S gilt also S gt T e T ist abgeschlossen unter Normal und Fehlertransitionen Das Pr dikat T um fa t also alle Zust nde die bei auftretenden Fehlern erreicht werden k nnen Das Pr dikat T kann als die durch die Fehler induzierte Erweiterung von verstanden werden und wird auch als Fehlerspanne bezeichnet e Die Normaltransitionen t f hren schlie lich wieder zur ck zu Zust nden f r die S gilt Werden Fehlertransitionen f nicht mehr ausgef hrt stabilisiert sich das System also wieder und kehrt zur ck zum erwarteten Verhalten Sind diese Bedingungen erf llt wird ein System fehlertolerant genannt bez glich der definierten Fehlermenge und der Fehlerspanne T Zwei Spezialf lle dieser Bedingungen f hren direkt zu einer einfachen Klassifizierung von Fehlertoleranz Gilt S F so wird das Syst
237. orma len Definition der Begriffe Fehler Fehlerzustand und Versagen Damit ist die in der Literatur sonst immer nur informell gehaltene Terminologie um pr zise Cha rakterisierungen erg nzt Diese Definitionen erm glichen es die Korrektheit ver schiedener Mechanismen nachzuweisen die f r den Umgang mit Fehlern relevant sind Modifikationen erlauben eine formale Definition von Fehlertoleranz Weist ein Sys tem unter dem Einflu von Fehlern eine noch akzeptable Ver nderung in seinem Verhalten auf so nennen wir es fehlertolerant Mit den in dieser Arbeit vorge stellten Ausdrucksmitteln ist es m glich sowohl die Fehler als auch die nderung im Verhalten pr zise zu formulieren Abschnitt 41 Damit sind explizite und exakte Fehlertoleranzaussagen m glich und sogar verifizierbar Eine alternative Interpretation versteht Fehlertoleranz als die F higkeit eines Sys tems die Auswirkungen von Fehlern die in einem Teilsystem oder der Umgebung auftreten nur in m glichst abgeschw chter Form auf das Gesamtsystem Einflu nehmen zu lassen Dazu haben wir in Abschnitt 24 3 eine qualitative Klassifi kation angegeben mit der Systeme bez glich dieser F higkeit bewertet werden k nnen Das zugrundeliegende Systemmodell bietet durch seinen klaren Schnittstellenbe griff eine Abgrenzung eines Systems von seiner Umgebung Damit ist es uns im Gegensatz zu anderen Ans tzen im Bereich der Fehlermodellierung m glich auch externe Fehler eines S
238. ormale Methode mu es erm glichen ein System auf verschiedenen Abstraktionsebenen darstellen zu k nnen und den bergang zwischen 70 KAPITEL 3 FORMALES SYSTEMMODELL p B g7 b 5 7 eo ao Q Q Q Q Ry Rg Rx Ry RL Ro gb 3 pbs A Le cm 9 N 0 EE Abbildung 3 10 Schnittstellenverfeinerung eines komponierten Systems verschiedenen Ebenen formal zu unterstiitzen Dabei sollte das Spektrum der Darstel lungsm glichkeiten von abstrakten Systemanforderungen bis hin zu einer konkreten Implementierung reichen Als Vorgehensweise kennen wir zwei idealisierte Richtungen Eine Top Down Entwick lung f hrt ausgehend von einer abstrakten Spezifikation schrittweise zu einer lauff hi gen Implementierung w hrend eine Bottom Up Entwicklung von der Entwicklung von Einzelkomponenten ausgeht die zielf hrend zu einem Gesamtsystem zusammengesetzt werden In der Realit t wird man meist eine Mischform w hlen in der man sowohl von abstrakten Anforderungen als auch von bereits implementierten und wiederzuverwen denden Einzelkomponenten ausgehen wird Das Ergebnis einer idealisierten Systementwicklung l t sich vereinfacht als ein Ent wicklungsbaum darstellen wie er in Abbildung BIT illustriert ist Der Unterschied zwischen einem Top Down und Bottom Up Verfahren liegt dann nur in der Reihenfol ge in welch
239. ponente nach sich zieht was wiederum eine Ver nderung der ersten Komponente m glich macht und so weiter Wir wollen hier nun formal ausdr cken wie mehrere Modifikationen zu einer Modifika tion zusammengefa t werden k nnen sowohl im Formalismus der Black Box Spezifi kation als auch im Rahmen von Transitionssystemen Wird die Black Box Eigenschaft einer Komponente zweimal modifiziert also je zweimal verst rkt und abgeschw cht so entspricht dies einer Modifikation durch die Konjunktion der Verst rkungen aber einer Disjunktion der Abschw chungen 104 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Definition 4 11 Kombination von Black Box Modifikationen Die Kombination zweier Black Box Modifikationen M und Ma wird mit Hilfe des Operators definiert durch df Di DF OF Of Oy A OF Op V DR Sind die beiden Modifikationen unabh ngig voneinander k nnen sie in beliebiger Rei henfolge und sogar gemeinsam als kombinierte Modifikation auf ein System angewendet werden wobei sich immer das gleiche Resultat ergibt Dies formulieren wir folgender ma en Proposition 4 5 Unabh ngigkeit von Black Box Modifikationen Der Operator f r Black Box Spezifikationen ist assoziativ und kommutativ Dies er gibt sich unmittelbar aus der Assoziativit t und Kommutativit t von A und V Unter der Voraussetzung der Unabh ngigkeit gt A 6456 gilt fiir M P4 P4 und Ma 7 dass die Reihenfolge
240. prechenden Systemmodifikationen beschreiben und mit dem Puffer als Beispiel illustrieren Alle in unserem Systemmodell spezifizierten Systeme weisen eine Umgebungsannah me auf die bislang nicht angesprochen wurde Wir nehmen von allen Nachrichten a die ber einen Kanal c empfangen werden an dass sie zum richtigen Nachrichtentyp geh ren also a type c Soll modelliert werden dass ein System unerwartete Nach richten empf ngt so ist dies durch eine Kombination bisher dargestellter Techniken m glich Zun chst wird durch eine Schnittstellenmodifikation der Kanal c um die neuen Nachrichten zu c erg nzt und die Umgebungsannahme um Vt e c t type c erweitert Der Fehler der Umgebung ist dann durch eine Abschw chung der Umgebungsannahme modellierbar 4 7 Zusammenfassung und Diskussion Wir haben in diesem Kapitel das Konzept der Modifikationen eingef hrt Mit diesen k nnen beliebige Ver nderungen sowohl der Schnittstelle als auch des Verhaltens eines Systems dargestellt werden Mit Modifikationen kann prinzipiell jedes System in jedes andere verwandelt werden In der Praxis wird man aber eher an relativ kleinen nde rungen interessiert sein mit denen Fehler als Abweichungen eines Ist von einem Soll repr sentiert werden Die Modifikationen wurden im Rahmen von vier Beschreibungs techniken eingef hrt Als Modifikationen der Relationen der Black Box Eigenschaf ten und der Transitionssysteme und schlie lich als Modifikationsko
241. proj quest REIF WOLFGANG and KURT STENZEL Reuse of proofs in software verification In SHYAMASUNDAR R editor Foundation of Software Technology and Theoretical Computer Science number 761 in Lecture Notes in Computer Science Bombay India 1993 Springer LITERATURVERZEICHNIS 169 55 56 57 58 59 60 61 62 63 66 67 68 69 70 RENZEL KLAUS Error Detection In BUSCHMANN FRANK und DIRK RIEHLE Herausgeber European Pattern Languages of Programming Conference Irsee 1997 Siemens Technischer Bericht 120 SW1 FB RUMPE BERNHARD Formale Methodik des Entwurfs verteilter objektorientierter Systeme Doktorarbeit Technische Univerit t M nchen 1997 RUSHBY JOHN Critical system properties Survey and taxonomy Reliability Engineering and System Safety 43 2 189 219 1994 Rust HEINRICH Zuverl ssigkeit und Verantwortung die Ausfallsicherheit von Programmen Vieweg 1994 SCHEPERS HENK Terminology and paradigms for fault tolerance In VYTOPIL JAN editor Formal Techniques in Real Time and Fault Tolerant Systems pages 3 31 Kluwer Academic Publishers 1993 SCHNEIDER FRED B Implementing fault tolerant services using the state ma chine approach A tutorial ACM Computing Surveys 1990 SCHNEIDER MARCO Self stabilization ACM Computing Surveys 1993 SOMMERVILLE IAN Software Engineering Addison Wesley Fifth edition 1995 SPIES KATHARINA und BERNHA
242. r nkt die nicht neu erg nzt wurden wie die folgende Proposition zeigt Auf den neuen Kan len sind beliebige Ausgaben m glich also auch nicht monotones Verhalten Da ein neuer Kanal blicherweise zweckgebunden eingef hrt wird wird das Verhalten in weiteren Entwicklungsschritten durch eine Verhaltensmodifikation pr ziser spezi fiziert und damit auch kausal Wir haben daher in Definition MB auf eine explizite Sicherstellung der Kausalit t verzichtet 4 1 MODIFIKATION DER SCHNITTSTELLE 81 Proposition 4 2 Partieller Erhalt der Kausalit t Gelte x E x f r alle j 1 n k und 21 lt s Tn Intl ntk Yis Ym Yms mt ER 1 l al 1 aah 1 1 1 T En is ee oO Use ie ag ER Aufgrund der Definition verhaltensgleicher Relationen gilt also type i Oz sey type in Dun Yly Ym ER type i Ori type in OL Y Ym E R Da gilt dass x E x gt M r E MOr folgt daraus mit der Kausalit t von R direkt Vj E 1 m e yj E y Die Beziehung zwischen den durch R und R beschriebenen Systemen stellt eine Schnitt stellenverfeinerung im Sinne von Abschnitt B 9 2 dar Die Umsetzungsrelationen Ry bzw Ro ergeben sich unmittelbar aus Definition HP Sie sind entsprechend Abschnitt B I 3lumkehrbar so dass die in diesem Abschnitt pr sentierte Erweiterung der Schnitt stelle kompositional erfolgen kann 4 1 2 Einschr nkung der Schnittstelle Die Schnittstelle eines S
243. r M wird bezeichnet als M bzw M Die Menge aller Str me ber M wird definiert als M M UM F r amp 1 2 n M bezeichnet der Ausdruck 2 22 p einen endlichen Strom der L nge n mit x als erstem und x als letztem Element Der Sonderfall bezeichnet den leeren Strom 2 bezeichnet die L nge des Stroms x Ist x unendlich so gilt 1 x Das erste Element eines nicht leeren Stromes x wird mit ft x first bezeichnet ein Strom x ohne sein erstes Element mit rt x rest Das letzte Element eines Stromes wird definiert als It x last 3 2 MATHEMATISCHE GRUNDLAGEN 39 Falls t lt 2 so bezeichnet x t die t te Nachricht in Strom x xz y bezeichnet die Konkatenation der Str me x und y Ist x ein unendlicher Strom so glt ny r Der Strom x ist ein Pr fix Anfangsstrom von y notiert als x E y wenn x zu y verl ngert werden kann TEY def JzeM s nz y x ist ein echter Pr fix also x C y wenn y wirklich l nger ist als x also wenn z Mit Hilfe des Filter Operators definiert man mit D x den Strom der aus x entsteht wenn man alle Nachrichten aus x entfernt die nicht in D liegen Er kann definiert werden durch folgende induktive Definition DX 0 d DOr falls de D DOzT falls d g D In 9 BT finden sich weitere ausf hrlich beschriebene Definitionen und Operatoren zu Str men Wir haben uns hier auf die Darstellung der Operatoren beschr nkt die in dieser Arbeit
244. r bereits vorhandenen Transitionen so dass das Verhalten im Normalfall unver ndert bleibt Die im Rahmen der Erh hung von Robustheit erg nzten neuen Transitionen ver ndern die Reaktion des Systems auf Eingaben f r die das System urspr nglich blockiert hat Durch die Modifikation ist das Systemverhalten ver ndert worden und entsprechend auch seine Black Box Eigenschaften Damit ist ein eventuell bereits gef hrter Beweis der die Eigenschaften eines Systems zeigt nicht mehr g ltig Wir diskutieren im fol genden Abschnitt wie Beweise an Modifikationen von Systemen und Eigenschaften angepasst werden k nnen 5 7 Wiederverwendung von Beweisen Mit den Beweistechniken aus Kapitel 8 8 k nnen wir nachweisen dass ein Transitions system S gewisse Eigenschaften hat Werden im Verlauf eines Entwicklungsprozesses potentielle aber unvermeidbare Fehler eines Systems identifiziert so k nnen diese mit den in dieser Arbeit pr sentierten Techniken als korrespondierende Modifikationen der Eigenschaften bzw des Transitionssystems dargestellt werden Ein bereits gef hrter Beweis f r das urspr ngliche und fehlerfreie System macht f r das modifizierte fehler behaftete System keine Aussage mehr Ohne eine Anpassung des Beweises w re damit der Aufwand der bereits f r die Erstellung des Beweises investiert wurde verloren Wir wollen in diesem Abschnitt diskutieren wie aus dem Beweis f r das fehlerfreie System ein Beweis f r d
245. r konkreten Systementwicklungsumgebung aber noch zu instantiieren sind Hier k nnen also noch einige sinnvolle Weiterentwicklungen erfolgen 164 KAPITEL 6 ZUSAMMENFASSUNG UND AUSBLICK e Eine durchg ngige und effiziente Entwicklung eines komplexen Systems erfordert ein systematisches Vorgehen das durch sogenannte Vorgehensmodelle unterst tzt wird Wir haben mit der vorliegenden Arbeit die M glichkeiten formaler Metho diken erweitert da auch Fehler und ihre Auswirkungen in verschiedenen Phasen einer Systementwicklung reflektiert werden k nnen Die in Kapitel behandelten Themen liefern erste systematische Hinweise wie mit verschiedenen typischen fehlerbezogenen Aufgaben in einer Systementwicklung umgegangen werden kann Allerdings liegt damit noch kein umfassendes Vorgehensmodell vor sondern nur einige seiner Bausteine deren Kombination zu konkreten den Gesamtentwick lungsproze umfassenden Handlungsanweisungen noch zu leisten ist Es verbleibt damit weiterhin als lohnende Aufgabe bestehende Vorgehensmodelle zu analysie ren mit Hilfe von FOCUS auf eine formale Grundlage zu stellen und schlie lich um Aspekte der Fehlermodellierung im Sinne dieser Arbeit zu erweitern Auch die Bereitstellung von design patterns stellt einen vielversprechenden An satzpunkt dar den Umgang mit Fehlern in einer Systementwicklung zu unterst t zen In 24 finden sich dazu erste Ans tze e Die Akzeptanz einer formalen Methodik in der praktischen in
246. r vermutlich w hrend der Entwicklungszeit durch Fahrl ssigkeit verur sacht und ist dauerhaft im System vorhanden Die Schwere dieser Fehlerursache kann nur im Einzelfall beurteilt werden Ein Systemversagen k nnen wir in bereinstimmung mit den bereits vorgestellten Be griffen als eine sichtbare Soll Ist Abweichung im Systemverhalten definieren Erfiillt die Umgebung nicht die Erwartungen die an sie in der Umgebungsannahme gestellt wurden bezeichnen wir dies als einen externen Fehler Es liegt also eine Abwei chung zwischen der in der Systembeschreibung enthaltenen Umgebungsannahme und dem konkret beobachteten Umgebungsverhalten vor Die Abweichung kann sowohl in einer fehlerhaften Erfassung der Umgebungsannahmen als auch im wirklichen Versa gen der Umgebung liegen Wir betrachten Diskrepanzen zwischen einem Ist und einem Soll ohne dabei unmittelbar Verantwortungen zuzuweisen Eine derartige Abweichung bezeichnen wir im Einklang mit den Begriffen der Literatur wieder als Fehlerursache Sehr h ufig sind Fehlerursachen in einer Soll Ist Abweichung im System selbst zu fin den Fehler im Design oder im Code eines Systems sind typische Beispiele Aufgrund ihres statischen Charakters sind diese Fehlerursachen permanent und gelangen zur Ent wicklungszeit in das System sind aber unter Umst nden nur schwer zu lokalisieren und 2 1 FEHLER 21 statisch dynamisch asia Externer Inkompatibilit t Versagen Black Box fault fa
247. rausgesetzt wird Mit dem Pr dikat G wird die Verhaltensrelation des Systems auf die gleiche Weise definiert wie f r einfache Black Box Spezifikationen Als Semantik einer einfachen A G Spezifikation definieren wir also unter Verwendung der vereinfachten Notation entsprechend Seite 43 alle Stromtupel die G erf llen wenn die Umgebung nur Eingabestr me sendet die A erf llen 4 Gi 0 AG gt Gli 0 Erf llt eine Umgebung die Annahme A nicht ist das Verhalten des Systems unspezifi ziert also beliebig Normalerweise erbringt ein System seine Leistung schrittweise indem es schrittweise Nachrichten einliest auf diese mit Ausgaben reagiert weiter Eingaben liest wieder entsprechende Ausgaben macht und so fort Solange die Umgebung sich an A h lt muss sich auch das System an G halten Obige Definition scheint es zuzulassen dass sich ein System von Anfang an beliebig verh lt auch wenn eine Abweichung von der Annahme erst bei einer sp teren Nachricht im Eingabestrom 7 auftritt F r dieses i 46 KAPITEL 3 FORMALES SYSTEMMODELL Puffer ne Abbildung 3 3 Schnittstelle von Buffer w re A nicht erf llt und die Implikation f r ein beliebiges o aber schon Durch die geforderte Monotonie ist jedoch sichergestellt dass f r einen korrekten Pr fix von i auch eine korrekte Ausgabe produziert wird die wiederum ein Pr fix von o ist Bevor einem System beliebiges Verhalten erlaubt ist muss die Umgebung a
248. rch eine Modifikation das Entfernen von Tran sitionen durchzuf hren Dies kommt der Modellierung von permanenten Fehlern n her da dem System manche Verhaltensm glichkeiten von Anfang an genommen werden Damit sind wir auch in der Lage Fehlertoleranz auszudr cken unter der Annahme dass Fehler sicher auftreten Unser Ansatz stellt damit einen allgemeineren Formalismus bereit der bekannte An s tze umfa t Wir erm glichen damit einen allgemeineren Begriff von Fehlertoleranz der Aussagen ber ver nderte Eigenschaften von ver nderten Systemen macht Durch die Wahl einer geeigneten Modifikation kann jede gew nschte Aussage formuliert werden Beispiel 4 8 F r die Systeme Merge und Merge aus den Beispielen AH und ABl gilt Merge AM5 H Merge AM da sie das gleiche Verhalten beschreiben Wir modifizieren Merge AM durch das Hinzuf gen von zwei weiteren Transitionen mittels M3 F wobei Name Pre Input Output Post F t c 2 ua c c T6 c 1 i a c c Diese Transition lesen und verwerfen Daten nur von jeweils dem Eingabekanal iiber den die modifizierte Black Box Spezifikation keine Aussage macht Das System Merge AM ist also gegen ber dem Fehler M3 und der Eigenschaft Merge AM maskierend fehlertolerant da gilt Merge AM AM8 H Merge AM Im Beispiel wird deutlich dass man auch an Modifikationen von bereits modifizierten Systemen interessiert ist Im folgenden Abschnitt 5 1 behandeln
249. rden k nnen wie dies beispielsweise in den Arbeiten B6 A7 durchgef hrt wurde Fehler werden darin durch eine beliebig definierbare Menge zus tzlicher Transitionen modelliert Welches Verhalten des Systems wird noch als tolerierbar akzeptiert Im allgemeinen ver ndern Fehler das Systemverhalten so dass ein fehlerbehafte tes System in der Regel nicht mehr alle Forderungen einer Spezifikation erf llt Eine pr zise Aussage zur Fehlertoleranz muss definieren inwieweit sich ein Sys temverhalten ndern darf um dennoch als akzeptabel zu gelten In der Literatur finden sich dazu Begriffe wie beispielsweise Toleranzspezifikation 5 und graceful degradation sanfte Leistungsminderung B1 4 4 FEHLERTOLERANZ 99 Die in einem System vorhandenen Fehler k nnen wir als Modifikationen darstellen und ebenso die Verletzung von Umgebungsannahmen durch eine Abschw chung der sie be schreibenden Aussage formulieren Damit werden die Fehler die toleriert werden sollen ausgezeichnet Das tolerierbare Verhalten das ein System trotz Fehler aufweisen soll k nnen wir relativ zum Normalverhalten ebenfalls durch eine Modifikation beschreiben Damit sind wir mit unserem Systemmodell also in der Lage pr zise Antworten auf die beiden obigen Fragen geben zu k nnen Dies erm glicht es uns eine Aussage ber Fehlertoleranz eines Systems formal zu beschreiben und wenn sie von einem System erf llt wird auch zu verifizieren Definition 4 10
250. re Fehlerbehandlung erg nzt werden wie wir es schon im Abschnitt 5 5 vorgestellt haben Im allgemeinen wird man ein System nicht gegen ber allen nur denkbaren Umgebungs fehlern robust machen k nnen sondern lediglich f r eine Teilmenge von diesen Diese l t sich wie in Abschnitt 6 2 beschrieben durch ein Pr dikat irap angeben Ist jeder 142 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN durch irap beschriebene Zustand durch die Erh hung der Robustheit kein Fangzustand mehr gilt also a H Pray gt AGPe a P ETUF so bleibt das System SA F auch in einer Umgebung reaktiv in der Eingabestr me erzeugt werden die eine Teilmenge der abgeschw chten Umgebungsannahme A S U LeadsTo trap bilden In einer realen praktischen Systementwicklung will man die Verbesserung der Robust heit eines Systems nicht auf semantischer Ebene sondern in der Beschreibungstechnik durchf hren in der das System spezifiziert ist Besonders gut lassen sich Fangzust nde in der graphischen Repr sentation von Transitionssystemen erkennen Jeder durch einen Knoten dargestellte Kontrollzustand s hat eine n elementige Menge von abgehenden Transitionen 7 die jeweils mit einer Vorbedingung mit i l n assozi iert sind Diese Vorbedingungen enthalten sowohl Aussagen ber den lokalen Daten zustand als auch ber die aktuellen lesebereiten Nachrichten auf den Eingabekan len also free C IU A Das System ist in einem Kontrollzu
251. reiberkomponenten geschehen die zwischen einer durch Fehler be eintr chtigten Komponente und ihrer Umgebung geschaltet werden Je nach Art und Schwere des Fehlers sind verschiedene Arten von Treibern notwendig Die Treiber ha ben dieselbe Gestalt wie die Modifikationskomponenten und werden daher auch wie in Abbildung M3 dargestellt Je nach Typ des Fehlers kann es gen gen dass Treiber ausschlie lich die Ausgaben kontrollieren und korrigieren wobei sie unter Umst nden Kenntnis ber die Eingaben besitzen m ssen Im allgemeinsten Fall muss ein Treiber sowohl auf Ein als auch auf Ausgabekan le Einflu nehmen Alle Varianten aus Abbil dung 4 3 sind also auch f r Treiber relevant W hrend die Modifikationskomponenten in Kapitel zur Modellierung von Fehlern ver wendet wurden k nnen sie ebenso der Darstellung von Treibern dienen Der wesentli che Unterschied besteht darin dass die Modifikationskomponenten nicht implementiert werden sondern nur verwendet werden um die Abweichungen des Verhaltens zu mo dellieren Treiberkomponenten werden dagegen tats chlich realisiert Werden wie in Abbildung 5 5 dargestellt Fehler einer Komponente durch eine Modifikationskompo nente M modelliert die durch eine Treiberkomponente C korrigiert werden k nnen so heben sich die Wirkungen von C und M gegenseitig auf und es gilt idealerweise nach geeigneter Umbenennung von Kan len SU C CR MRS 138 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN
252. rekte Weise dem Diagramm hinzugef gt werden und damit unter anderem sicherstellen dass das Pr dikat des Nachfolgeknotens gilt und durch ihre Ausf hrung die Bewertung 6 monoton verkleinert wird e Durch eine Verst rkung von zu A x werden zus tzliche Annahmen an den Systemzustand im Knoten j gemacht Es kann m glich sein mit dieser Verst r kung die geforderte Schaltbereitschaft von einer der verbleibenden Transitionen zu zeigen Dies hat Auswirkungen auf weitere Beweisverpflichtungen die dann zus tzlich noch gezeigt werden m ssen Alle an Knoten j eingehenden Transitionen m ssen zus tzlich die G ltigkeit von x implizieren Dies kann wiederum eine Verst rkung der Pr dikate ihrer Ausgangsknoten erfordern In Abschnitt 5 71 haben wir die Verst rkung von Pr dikaten in Zusammenhang mit der Entfernung von Transi tionen bereits beschrieben Da hier zus tzlich noch die Initialbedingung P gt PoV V BAX V Vr 150 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN gelten muss ist unter Umst nden sogar zu verst rken e Es kann m glich sein dass die Modifikation das System soweit ver ndert dass es im Zustand h ngenbleibt und von dort keine Transition mehr in Richtung o f hrt In einem solchen Fall muss die Fortschrittsaussage abgeschw cht werden zu Or VV In allen drei F llen wird durch eine Anpassung des Beweisdiagramms und m glicher weise durch eine Abschw chung der Fortschrittsaussage gt
253. riablen aus A kann selbstverst ndlich zu Problemen f hren wenn die zu entfernende Variable in den Transitionen verwendet wird eine Sys temspezifikation w re dann nicht mehr konsistent Wir lassen die Entfernung von Variablen aus A daher nicht zu Soll ein System auf eine Art und Weise modi fiziert werden die eine Variable berfl ssig macht so kann durch entsprechende Modifikationen der Transitionen diese Variable einfach nicht mehr benutzt also auf irgendeine Art lesend oder schreibend referenziert werden Die Initialbedingung Y zeichnet eine Menge von Startzust nden aus die die se Bedingung erf llen Eine Modifikation der Initialbedingung lie e sich wieder um durch eine Kombination von Verst rkung und Abschw chung beschreiben verbunden mit einer Verkleinerung bzw Vergr erung der entsprechenden Zu standsmenge Zur Vereinfachung des Formalismus wollen wir dies aber wie folgt reduzieren auf eine Modifikation der Transitionsmengen Zun chst wandeln wir dazu ein System S um ohne sein Verhalten dabei zu ndern Wir f hren wie bereits beschrieben eine frische boolesche Variable init ein die von keiner existierenden Transition ver ndert werden darf Dazu sei E entspre chend definiert als die Menge die alle Transitionen enth lt die init ver ndern Den neuen Startzustand charakterisieren wir als init true Wir f gen nun neue Transitionen hinzu die vom neuen Startzustand zu den bisherigen Startzust nden
254. rigiert werden k nnen Es wird angegeben wie die Robustheit von Systemen gegen ber externen Fehlern erh ht und wie aus Beweisen zu fehlerfreien Systemen Beweise f r fehlerbehaftete Systeme abgeleitet werden k nnen In allen Kapiteln verdeutlichen wir alle wesentlichen Konzepte mit Hilfe vieler Beispiele Dabei konzentrieren wir uns auf die durchg ngige Verwendung zweier einfacher Systeme Merge und Buffer die trotz ihrer Einfachheit eine ausreichende Komplexit t aufweisen um die jeweils relevanten Aspekte demonstrieren zu k nnen Schliesslich werden in Kapitel 6 die Beitr ge dieser Arbeit zusammengefa t und ver bleibende sowie neu aufgeworfene offene Probleme identifiziert Kapitel 2 Der Fehlerbegriff Als Grundlage f r einen formalen pr zisen Umgang mit Fehlern wollen wir den facet tenreiche Begriff des Fehlers mit seinen verschiedenen Bedeutungen zun chst informell diskutieren Wir fassen in diesem Kapitel verschiedene Begriffe zusammen die sich dazu in der Literatur aus dem Bereich der Informationstechnik finden lassen Dazu beschreiben wir die Differenzierung von Fehlern in Fehlerursache Fehlerzustand und Versagen mit ihren Zusammenh ngen und geben Klassifizierungen dieser Begriffe an Nach Angabe verschiedener M glichkeiten im Umgang mit Fehlern fokussieren wir auf die Fehlertoleranz welche wir zun chst informell beschreiben und darauf entspre chende formale Ans tze diskutieren Schlie lich pr sentieren wir pr
255. rsucht dies beispielsweise durch die Verwen dung verschiedener Programmierteams Programmiersprachen und Tools zu erreichen Dadurch entstehen hohe Qualit tsanforderungen an eine Spezifikation des Systems Sie muss einerseits sehr pr zise sein damit Versionen entstehen die nach M glichkeit alle korrekt sind und deren Ergebnisse durch den korrekten Akzeptanztest angenommen oder die durch einen Voter auch wirklich sinnvoll verglichen werden k nnen Anderer seits soll sie m glichst allgemein und frei von bereits getroffenen Entwurfsentscheidun gen sein um noch verschiedenartige Implementierungen zuzulassen Eine Diskussion ber Techniken und Probleme der Software Diversifikation mit einem guten berblick ber verschiedene Experimente und ihre Resultate findet sich in 7 Systeme mit Softwarefehler Toleranz scheinen nicht sehr h ufig entwickelt zu werden und es finden sich kaum Erfahrungsberichte Storey gibt in 66 einige wenige Verwei se Die Integration genannter Fehlertoleranztechniken zusammen mit der Erstellung mehrerer Versionen resultieren in einem deutlich h heren Entwicklungsaufwand Die ser Aufwand k nnte stattdessen auch in Techniken zur Fehlervermeidung investiert werden was insbesondere f r Softwarefehler interessant ist Ein einmal korrektes Soft waresystem bleibt f r immer korrekt von nderungen der Anforderungen oder der Umgebung abgesehen Die Verwendung von fehlertoleranten Mitteln k nnte auch als Eingest n
256. rtbarkeit Korrektheit Lebendigkeit und Stabilit t aufweisen e Das Pr dikat UV kann durch das System selbst ausgewertet werden Es darf also nicht Variablen enthalten die der Formalismus zwar zur Verwendung in Beweisen bereitstellt auf die das System selbst aber nicht zugreifen kann Dazu geh ren beispielsweise die Variablen i f r alle i I f r noch nicht gelesene Eingaben oder Variable oc f r Orakel aber auch bereits gelesene Eingaben 7 und sogar vom System bereits gesendete Ausgaben o Die entsprechenden Informationen stehen dem System nur dann zur Verf gung wenn sie vom System explizit in lokalen Variablen gespeichert werden e Das Pr dikat ist korrekt Das Pr dikat wird also nur dann wahr wenn tats chlich ein Fehler vorliegt In unserem Formalismus k nnen wir dies formulieren als a Y gt a ERROR S M Das Pr dikat ist lebendig in dem Sinne dass ein Fehler auch tats chlich erkannt wird wenn er dauerhaft vorliegt Wir fordern also nicht dass ein Fehler sofort erkannt wird was sich in einer quivalenz anstelle der Implikation in der Kor rektheitsforderung widerspiegeln w rde Wir fordern nur die abgeschw chte Form amp k ERROR S M gt Ij gt k e j H V V j ERROR S M Ist ein Fehler durch W erkannt bleibt Y stabil also solange wahr bis dieser Fehler nicht mehr vorliegt Ek H T gt k 1 EVV k 1 g ERROR S M Als Beispiel greifen wir auf den Puffer zur ck
257. rten Systems erfassen lassen Dies unterst tzt eher die praktische Verwen dung von Modifikationen wenn die Systemeigenschaften verst rkt werden sollen Die Modifikation von Black Box Spezifikationen ist vertr glich mit der Verfeinerung wie leicht einzusehen ist Proposition 4 3 Es gilt N Pa p AM PaA M 86 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN Aus 2 A p V Dr folgt unter der Voraussetzung 2 sofort 1 A p V Dr Wir beschreiben die Modifikation aus Beispiel MIB erneut im Rahmen von Black Box Spezifikationen Dabei wird deutlich dass zwei semantisch quivalente Modifikatio nen in verschiedenen Beschreibungstechniken sehr unterschiedlich formuliert werden k nnen Beispiel 4 4 Die Komponente Merge soll nur noch Nachrichten von 7 oder iz auf o ausgeben Die Disjunktion dieser beiden F lle scheint eine zus tzliche Eigenschaft als Verst rkung der Black Box Sicht mittels z darzustellen Konjugiert man aber o 71 V o ia zur Black Box Spezifikation Dio i A D amp o ia so impliziert dies dass einer der Eingabestr me il oder ia leer sein m te was der Linkstotalit t widerspricht Um diesen Konflikt zu vermeiden w hlen wir die radikale L sung durch Verwerfen der urspr nglichen Spezifikation mit z false und spezifizieren das neue Verhalten verm ge p Unsere gesuchte Modifikation l t sich also definieren als M false o i Vo i Neben der eigenschaftsorientierten
258. rtoleranz g ltig sein F r verschiedene Mengen von Fehlern weicht das Verhalten auf unterschiedliche Weise ab So k nnen beispielsweise f r harmlose Fehler keine Auswirkungen sichtbar werden w hrend f r gravierendere Fehler nur noch sicherheitskritische Eigenschaften erf llt bleiben Die st rkste Form von Fehlertoleranz ist die sogenannte maskierende Fehlertoleranz Sie stellt sicher dass bez glich einer definierten Menge von Fehlern das Verhalten un ver ndert bleibt die Fehler also keine Wirkung zeigen k nnen Die in der Klassifizierung von Versagen aufgef hrten Beispiele k nnen f r explizite Aus sagen ber Fehlertoleranz verwendet werden So k nnen Komponenten eines Systems bestimmte Klassen von Versagen als Fehlermodelle zugeordnet werden und damit ei ne Aussage ber die Menge der zu tolerierenden Fehler gemacht werden Andererseits kann die Abweichung vom erwarteten Verhalten des Gesamtsystems durch diese Klassen beschrieben werden 2 2 FEHLERTOLERANZ 25 Beispiel 2 2 Sei ein einfaches System gegeben das der Nachrichten bermittlung dient bestehend aus einem Sender einem Empf nger und zwei bertragungskan len Sender und Empf nger bermitteln Daten mit Hilfe der beiden Kan le entsprechend dem Sliding Window Protokoll beschrieben beispielsweise in 67 Das Protokoll ist in der Lage den sporadischen Verlust von Nachrichten auf den Kan len zu tolerieren so dass nur die Geschwindigkeit der bertragung beei
259. rung von Fehlermeldungen und zur Fehlerkorrektur in ein bestehendes System auf systematische Weise erm glicht Die Praktikabilit t dieser Techniken wird durch begleitende Beispiele illustriert Damit wird ein weiterer Schritt hin zu einer durchg ngigen und praktischen Verwend barkeit formaler Methoden geleistet Danksagung Meine Arbeit ist nur mit der vielf ltigen Unterst tzung meiner Kollegen Freunde und Familie m glich geworden Daf r m chte ich mich an dieser Stelle ganz herzlich bedan ken Insbesondere m chte ich mich bei Prof Manfred Broy bedanken f r seine fachliche wie organisatorische Betreuung und Unterst tzung w hrend aller Entstehungsphasen dieser Arbeit F r die bernahme des Zweitgutachtens und seine Hinweise zum Fehlerbegriff bin ich Prof Eike Jessen sehr dankbar Gro en Dank schulde ich Jan Philipps Unsere gemeinsame intensive Projektarbeit hat nicht nur zu einer guten Fundierung meiner Arbeit gef hrt sondern hat mir auch sehr viel Spa gemacht Ingolf Kr ger danke ich f r seine vielf ltige konstruktive Un terst tzung unter anderem durch zahlreiche fachliche Diskussionen und Anregungen Katharina Spies und Bernhard Sch tz geb hrt mein Dank f r ihre motivierenden Hilfe stellungen und Ratschl ge insbesondere in den fr hen und konzeptionellen Phasen der Arbeit Nicht zuletzt bin ich sehr dankbar f r die viele Geduld Nachsicht und Aufmunterung die Konstanze meine Freunde und meine Familie w
260. s Entwicklungsprozesses eine konsistente Definition aller Aspekte erreicht und sogar formal bewiesen Wir definieren diese Sicht als die Soll Beschreibung eines Systems Die verschiedenen Arten von Fehlern k nnen wir nun anhand dieser Darstellung gut 20 KAPITEL 2 DER FEHLERBEGRIFF statisch dynamisch Schnittstelle System on Black Box verhalten 8 8 Sicht verhalten Systemstruktur Abl ufe als Class Bor Code Folge von Sicht Design Systemzust nden Abbildung 2 3 Merkmale eines Systems illustrieren Weichen Merkmale eines vorliegenden st Systems von einem geforderten Soll System ab so liegen Fehler vor Mit Hilfe von Abbildung 2 4 stellen wir die Fehler begriffe nun einheitlich im Rahmen unserer Systemsicht vor Jeder Soll Ist Abweichung der f nf Merkmalsklassen k nnen wir entsprechende Fehlerbegriffe zuordnen Unterscheidet sich eine st Schnittstelle von einer intendierten Schnittstelle eines Soll Systems so f hrt dies zu einer Inkompatibilit t zwischen dem System und seiner Um gebung Beispielsweise kann es dann passieren dass von dem System Nachrichten emp fangen werden die in der Schnittstellenspezifikation nicht enthalten waren und beim Systementwurf daher nicht ber cksichtigt wurden Das System kann daher auf diese Nachrichten nicht reagieren Im Sinne der Klassifizierung aus Abschnitt 2 1 2 ist eine derartige Fehlerursache verteilt als Inkonsistenz im Gesamtsystem vorhanden ist durch den Entwickle
261. s Versagen oder Fehlerzustand auftreten Das Versagen eines Systems kann von au en erkannt werden wenn ein beobachtetes Ist Verhalten von einem spezifizierten Soll Verhalten abweicht Die Erkennung findet dabei also in einem anderen System oder in einer anderen Komponente eines Systems statt Die Erwartung an die m glicherweise versagende Komponente kann in der erkennen den Komponente als eine Umgebungsannahme formuliert werden Ein Fehler wird also nicht unbedingt als solcher erkannt da im allgemeinem bei einer nicht erf llten Um gebungsannahme das Verhalten nicht spezifiziert ist Eine Fehlererkennung mit einer zugeh rigen Fehlerbehandlung kann in ein System integriert werden indem die Fehler erkennung mit einer zus tzlichen sinnvollen Reaktion verbunden wird In Abschnitt 5 6 wird dies diskutiert Ein Fehlerzustand tritt innerhalb eines Systems und zur Laufzeit auf Ein System das zur Erkennung eines Fehlerzustandes in der Lage ist muss also die Abweichung des aktu ellen Systemzustandes von einem erw nschten Systemzustand selbst erkennen k nnen Wir wollen nun eine m gliche Modellierung einer Fehlererkennung im Rahmen unseres Systemmodells vorstellen 128 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN Dazu definieren wir ein Zustands Pr dikat W mit free V C IU OU A das das Vorliegen eines Fehlerzustandes a ERROR S M in einem System S mit dem Feh lermodell M anzeigt Das Pr dikat muss die vier Eigenschaften der Auswe
262. s bereits eine Spezifikation vorliegt die alle relevanten Qualit tsaspekte umfa t die wir von einem System fordern Erf llt ein System also seine Spezifikation m ssen keine weiteren Kriterien berpr ft werden Doch auch unter der Voraussetzung dass alle Anforderungen an ein System im Rah men einer Spezifikation bereits definiert sind ist es eine gro e Herausforderung eine entsprechende Implementierung zu entwickeln Dies ist im wesentlichen in der hohen Komplexit t der Systeme begr ndet Sie bestehen aus einem diffizilen ausbalancierten Zusammenspiel vieler Komponenten in Hard und Software die untereinander und mit anderen Systemen interagieren Es werden meist bestehende Altsysteme oder Systemtei le integriert deren Funktionsweise unter Umst nden nur teilweise dokumentiert ist Sys teme k nnen so gro und komplex werden dass niemand sie mehr zugleich vollst ndig und im Detail verstehen kann Bei der Durchf hrung realer Projekte kommt hinzu dass sich w hrend der Entwicklung Ziele Spezifikationen die Systemumgebung und zugrun deliegende Hardware oder Betriebssysteme ndern und nur knappe Ressourcen von Zeit und Geld zur Verf gung stehen Die Informatik hat in den letzten Jahren beispielsweise durch Beschreibungstechniken Vorgehensmodelle dom nenspezifische Systemarchitekturen oder Entwicklungswerk zeuge bereits einige Fortschritte gemacht befindet sich aber im Vergleich zu anderen Ingenieurdisziplinen die ber
263. s im n chsten Abschnitt vorgestellt wird In 0 ist eine Reihe weiterer Beweisregeln zum Nachweis von Invarianten angegeben Invarianten sind leicht erf llbar von einem System das keinerlei Aktivit t zeigt bei spielsweise von einem trivialen System ohne Transitionen oder einem blockierten Sys tem Daher fordert man blicherweise eine gewisse minimale Aktivit t Wir formulieren diese mit Hilfe sogenannter Fortschrittseigenschaften die sich wieder auf Zustandspr di kate abst tzen Definition 3 13 Fortschrittseigenschaften Ein Zustand zieht in einem System S einen Zustand Y nach sich notiert als SIF y 3 8 VERIFIKATION VON EIGENSCHAFTEN 61 wenn in all seinen Abl ufen nach Erreichen eines Zustandes in dem gilt auch sofort W gilt oder im weiteren Ablauf ein Zustand folgt in dem W gilt VEE S eYk o EKE gt Il k o t l H Y In 10 finden sich wieder einige Beweisregeln zum Nachweis einer Fortschrittseigen schaft Im Rahmen unseres Systemmodells ist man h ufig an der folgenden speziellen Form interessiert die eine Verl ngerung der Ausgabe ausdr ckt die ein System leisten soll Fo kk lt lm o gt k Dabei beschreibt einen ganzzahligen Ausdruck mit freien Variablen aus U O Erf llt ein System diese Eigenschaft und hat in einem Zustand die L nge des Ausgabestromes den Wert noch nicht erreicht so wird der Ausgabestrom im weiteren Systemablauf noch verl ngert Es ist in di
264. sannahme entsprechend Abschnitt B 5 l t sich zus tzliches Wissen formulieren und in der Verifikation nutzen 4 2 Modifikation des Verhaltens Wir behandeln nun in diesem Abschnitt die Modifikation des Systemverhaltens Wir bezeichnen eine Verhaltensmodifikation mit M die im folgenden in den verschiedenen Beschreibungstechniken jeweils formal definiert wird Eine Modifikation M kann auf ein System S angewendet werden und beschreibt den Unterschied zwischen dem ur spr nglichen System und seiner ver nderten Variante Das Resultat ist das modifizierte System und wird notiert als SAM zu lesen als S modifiziert durch M Eine Modifikation M ver ndert ein System S auf zwei Weisen Es entfernt einerseits gewisse Anteile des Systems und f gt andererseits andere im allgemeinen neue Teile dem System hinzu Diese Ver nderungen k nnen die verschiedensten Aspekte eines Systems betreffen wie Eigenschaften interne Transitionen oder das Black Box Verhalten Wir illustrieren mit Abbildung 4 2Ja die Auswirkung einer Modifikation die das Ver halten eines Systems S modifiziert Die Gesamtfl che stelle die Menge aller m glichen Verhalten dar Darin wird das Verhalten eines Systems S durch eine Teilmenge repr sen tiert Das Verhalten des modifizierten Systems SAM stellt nun eine andere Teilfl che dar die nur noch einen Teil des Verhaltens von umfa t daf r aber neue Fl chenteile dazugewinnt Der Unterschied kann durch die Anga
265. schreibt den Fall dass keine der drei Komponenten einen Fehler aufweist Mit dieser Formalisierung des Gesamtsystems wird also die Annahme ausgedr ckt dass maximal zwei der drei Komponenten ausfallen Die behauptete maskierende Fehlertoleranz des Systems kann damit nachgewiesen werden 5 3 FEHLERERKENNUNG 127 T 71 72 73 712 713 723 gt Abbildung 5 2 Transitionssystem der virtuellen Komponente Orakelstr me sind weiterhin daf r geeignet Annahmen ber H ufigkeiten von auftre tenden Fehlern zu machen Kann beispielsweise ein Verfahren die Fehlertoleranz eines Systems nur sicherstellen wenn ein Fehler nicht n mal unmittelbar hintereinander auf tritt so kann dies durch ein Pr dikat ber einen Orakelstrom oc durch Ike Vje o lt j lt n 1 gt oc k j true ausgedr ckt und dann in einem Beweis als Voraussetzung verwendet werden 5 3 Fehlererkennung Ein wichtiger Schritt bei der Behandlung von Fehlern ist ihre Erkennung Wir k nnen unterscheiden zwischen den in Kapitel 2 1 1 drei diskutierten Fehlerbegriffen Eine Fehlerursache als der eigentliche Defekt eines Systems kann als solcher nicht vom System erkannt werden da eine Fehlerursache beispielsweise im Entwicklungsproze in fehlerhaften oder unvollst ndigen Anforderungen oder einer ungeeigneten Architektur ihren Ursprung haben kann Das System selbst kann diese Defekte nicht direkt erkennen sondern kann nur deren Wirkung wahrnehmen die al
266. so soll auf diesen angemessen und sinnvoll reagiert werden Die Ausgabe einer Fehlermeldung wie wir sie im vorigen Abschnitt diskutiert haben stellt bereits ein Beispiel einer einfachen Reaktion dar Wir wollen hier nun allgemeiner beschreiben wie Systeme um Reaktionen erg nzt werden k nnen Es ist typischerweise nicht ausreichend lediglich neue Transitionen hinzuzuf gen um eine gew nschte Reaktion auf Fehler ausdr cken zu k nnen Es kann n tig sein neue lo kale Variablen zu erg nzen oder die Wertemenge den Typ von vorhandenen Variablen zu erweitern Insbesondere ist es damit m glich neue Kontrollzust nde aufzunehmen Mit den Techniken aus Abschnitt I sind wir in der Lage die ben tigten neuen Va riablen oder erweiterten Typen verhaltensneutral zu erg nzen Wir gehen daher im folgenden davon aus dass alle Variablen mit entsprechenden Wertebereichen bereits vorhanden sind Wir spezifizieren exemplarisch drei Varianten von Reaktionen auf einen entdeckten Fehler die in Abbildung 5 4 dargestellt sind Der Sprung in einen Fangzustand der Neustart des Systems und der Start einer frei w hlbaren Fehlerbehandlung die eine Verallgemeinerung der ersten beiden Reaktionen darstellt Sprung in einen Fangzustand In Abbildung a ist der Sprung in einen Fang zustand f illustriert Wird ein Fehler durch ein Pr dikat Y erkannt d rfen Normal transitionen nicht mehr gew hlt werden da ihre Vorbedingung um W verst rkt wird Stattdess
267. st Die geforderte Implikation gilt trivialerweise da A 7 dann den Wahrheits wert false hat Vom Knoten gehen mit 7 beschriftete Kanten zu den Knoten und es gilt OATS V VE e Die Umgebungstransitionen erhalten jedes Pr dikat es gilt also f r alle r T j AT gt OF Frf llt ein Diagramm alle diese Eigenschaften so repr sentiert es einen Beweis fiir die Aussage S IF inv o V V Die Disjunktion gilt aufgrund der ersten Forderung initial und bleibt wegen der anderen Forderungen f r jede Transition erhalten Ein Beweis findet sich in 10 Wir illustrieren die Invariantendiagramme mit Hilfe des folgenden Beispiels Beispiel 3 11 Wir beweisen mit Hilfe des Verifikationsdiagrammes in Abbildung B 7 dass 0 ty Fg eine Invariante von Merge ist In allen vier Knoten gilt die geforderte Gleichung so dass die Behauptung eine Konsequenz der Disjunktion der vier Zustandspr dikate ist Initial sind keine Eingaben gelesen und noch keine Ausgaben ausgegeben so dass Y das Pr dikat im Startknoten impliziert Von den 12 Beweisverpflichtungen resultierend aus 4 Knoten mal 3 Transitionen inklusive der Umgebungstransition greifen wir exemplarisch eine heraus o Hi AHB ONT gt fol pif Hi Dies gilt offensichtlich da aus der Definition von 72 folgt dass Jde it i Aig i d Ao 0 7 a Auf beiden Seiten der Gleichung der Invarianten erh ht sich der Wert um 1 Damit bleibt die Inv
268. st muss erf llbar sein wenn eine Transition schaltbereit ist Bei einfachen Zuweisungen neuer Werte an Datenvariable ist dies sichergestellt Aus einem Transitionsdiagramm zusammen mit der Definition der Datenvariablen mit ihrer Initialisierung und der Definition der Schnittstelle ergibt sich eindeutig die formale Darstellung des zugeh rigen Transitionssystems Die systematische bersetzung wird in 13 beschrieben Beispiel 3 6 Merge als graphisches Transitionsdiagramm Wir spezifizieren das System Merge durch ein Zustands bergangsdiagramm in Abbildung BA 54 KAPITEL 3 FORMALES SYSTEMMODELL true amp d gt old true true i2 d gt o d true Abbildung 3 4 Zustands berg nge von Merge Wir ben tigen in diesem Fall keine Datenvariablen so dass wir auch keine Initialisierung angeben m ssen Diese wird blicherwiese in einem Diagramm in kommentar hnlicher Form angef gt Die Variable d ist in beiden Transitionen eine lokale Transitionsvariable Das Ergebnis einer systematischen bersetzung der Transitionen f hrt genau zu der Formalisierung wie wir sie bereits in Beispiel BB gesehen haben Auf eine Formalisierung des Kontrollzustandes haben wir verzichtet da es nur einen Zustand gibt Beide Transitionen w ren sonst um o s in Pre und o s in Post erg nzt worden Eine ausf hrliche Behandlungen von Zustandstransitionssystemen die auch hierar chisch sein k nnen findet sich in 18 B3 3
269. stand s und einer Variablen belegung a blockiert wenn es keine ausgehenden Transitionen gibt also n 0 gilt oder wenn n gt 0 und keine der ausgehenden Transitionen schaltbereit ist d h wenn mit o als Parameter f r den aktuellen Kontrollzustand gilt a Eee had V V Um nachzuweisen ob ein Kontrollzustand s ein Fangzustand sein kann muss man diese Aussage aber nicht f r alle Belegungen berpr fen Meist l t sich ein Kontrollzustand mit gewissen Eigenschaften Y verkn pfen die immer gelten wenn sich das System im Kontrollzustand s befindet In diesem Fall stellt 0 s W eine Invariante des Systems dar Ein Knoten beschreibt damit nicht nur dann einen Fangzustand wenn die Disjunktion der Vorbedingungen nicht true ergibt sondern auch dann wenn diese Disjunktion unter der Voraussetzung W nicht identisch zu true ist Die Bedingung Y gt n i V V ist also eine hinreichende Bedingung daf r dass s ein Fangzustand ist Da unter Um st nden aber W nicht die st rkste Aussage ist die im Zustand s gilt ist diese Aussage keine notwendige Bedingung f r einen Fangzustand Die Disjunktion kann f r eine Be legung a erf llbar sein obwohl diese Belegung im Zustand s in keinem Systemablauf erreichbar ist Die Robustheit des Systems kann bei einem vorliegenden Fangzustand s erh ht werden durch eine Transition mit der Vorbedingung 1 f r die gilt n41 oS oA a Oy Vv V Damit ist sichergestellt dass di
270. statteten Eingabestr me kann auch beschrieben werden durch eine fiktive Zustandsmaschine A die genau diese Menge von Str men erzeugen kann Sie kann im einfachen Fall keine Eingaben besitzen und die Ausgaben spon tan erzeugen oder die Ausgaben des Systems als Eingabe erhalten um R ck schl sse ber den Zustand des Systems ziehen zu k nnen Zum Ableiten von Eigenschaften des Systems unter dieser Annahme betrachtet man die Komposition des System mit der abstrakten Umgebungsmaschine Der Begriff des Umgebungsfehlers l t sich relativ zur Umgebungsannahme leicht de finieren Ein Fehler im Verhalten der Umgebung tritt auf wenn die Umgebung Nach richtenstr me an das System schickt die nicht die Annahme erf llen Diese Menge von Str men die die Annahme nicht erf llen k nnen wir unterteilen in zwei Teilmengen einerseits die Fehler die wir f r plausibel halten und f r deren Behandlung wir Ma nahmen im System ergreifen werden und andererseits die Fehler der Umgebung bei denen wir davon ausgehen dass sie nicht eintreten werden und die wir auch nicht weiter ber cksichtigen wollen Um eine Trennung dieser beiden Menge explizit zu machen wollen wir die Umgebungsannahmen derart abschw chen dass der letztere Teil noch immer ausgeschlossen bleibt aber das Auftreten spezifizierter Fehler m glich wird Es stellt sich somit die Frage wie eine konkrete Abschw chung f r ein konkretes System beschrieben werden kann Wir schlagen hier
271. stem kann man charak terisieren als Funktionen die eine Ein auf eine Ausgabe abbilden So geh ren klassische sequentielle Programme ohne Interaktion mit ihrer Umgebung in diese Klasse Ein reaktives System arbeitet dagegen eher kontinuierlich Es empf ngt stetig die Nach richten die von der Umgebung in m glicherweise willk rlicher Folge und H ufung gesen det werden und darauf reagiert im allgemeinen mit Ausgaben Das System terminiert nicht sondern bleibt reaktiv Abl ufe sind also potenziell unendlich Die Reaktion ei nes Systems kann dabei von aktuellen Eingaben und der Vorgeschichte also vorherigen Eingaben und Entscheidungen des Systems abh ngen Sie sind demzufolge allgemeiner und deutlich komplexer als transformationelle Systeme Reaktive Systeme stellen eine gro e und wichtige Systemklasse dar die oft auch in sicherheitskritischen Bereichen ihre Anwendung findet mit den damit verbundenen hohen Anforderungen an Korrektheit und best ndige Verf gbarkeit Beispiele sind Be triebssysteme Systeme zur Nachrichten bermittlung wie Basisstationen von Mobilfunk systemen oder Netzknotenrechner sowie eingebettete Systeme zur Steuerung von Fahr zeugen K chenger ten oder industriellen Herstellungsprozessen Ein verteiltes System besteht nicht aus einer einzigen Einheit sondern aus mehreren Komponenten die miteinander interagieren und so gemeinsam eine Gesamtleistung erbringen Gr nde f r die Verteilung eines Systems k nnen
272. stop wieder auf false setzen kann bleibt ein einmal angehaltenes System immer gestoppt Durch eine st rkere Vorbedingung Pre von Tstop kann der Ausfall des Systems von anderen Systemparametern abh ngig gemacht werden 5 1 BEISPIELE F R FEHLERMODELLE 123 Eine Ver nderung der Initialbedingung Y ist nicht n tig der initiale Wert von stop ist also frei w hlbar Damit ist es m glich dass das durch SAM definierte System gleich von Anbeginn seiner Ausf hrung versagt 5 1 2 Fail stop failure Wie beim crash failure Modell bleibt bei diesem Fehlermodell das System spontan ste hen Im Unterschied zu crash failure sendet es aber noch ein Signal an seine Umgebung welches das Versagen leicht und unmittelbar erkennbar macht Aufgrund der hnlichkeit der beiden Modelle unterscheiden sich auch die Formalisie rungen nur minimal Wir gehen von einem existierenden Kanal f aus auf dem Fehler meldungen fail ausgegeben werden k nnen also fail type f Unter Umst nden ist dieser Kanal entsprechend Abschnitt LT TJmit Hilfe einer verhaltensneutralen Schnitt stellenmodifikation zu erg nzen Wir k nnen die Modifikation true r der Black Box Spezifikation so anpassen dass bei einem auftretenden Versagen des Systems auch wirklich eine Fehlermeldung auf f ausgegeben wird Der Strom o muss in diesem Fall ein echter Pr fix von o sein da die Fehlermeldung nur genau dann ausgegeben werden soll wenn der Fehler wirklich aufgetreten ist
273. sweise in 67 die verschiedene Arten von Fehlern wie die Generierung von Nachrichten oder die Vertauschung ihrer Reihenfolge tolerieren k nnen Mit Hilfe von Orakelstr men aus Abschnitt B 2 sind wir in der Lage auszudr cken dass nicht alle Nachrichten verloren gehen dies w rde die bertragung schlie lich unterbrechen Kann man in unserem Fall Channel gt Sender Loss Channel Receiver nachweisen so ist ein gew hltes Protokoll f r ein vorausgesetztes Fehlermodell angemessen Im Extremfall kann der Treiber die volle geforderte Funktionalit t von S bernehmen und die fehlerhaften Ausgaben von M S dabei ignorieren Ein Beispiel stellen die in Kapitel 2 2 2 beschriebenen Reservekomponenten dar die in unserem Systemmodell formal mit dem Konzept der Treiberkomponenten eingef hrt werden k nnen 5 6 ERH HUNG DER SYSTEMROBUSTHEIT 139 5 6 Erh hung der Systemrobustheit In Kapitel 6 wurden Fehler diskutiert die nicht im System selbst sondern in der Umgebung eines Systems auftreten Das betroffene System erh lt dann Eingaben von denen angenommen wurde dass sie nie empfangen werden Das Verhalten des Systems kann in einem solchen Fall nicht spezifiziert sein so dass es sich auf unvorhersehbare Weise verhalten kann oder beispielsweise seine Aktivit t schlicht beendet Im Laufe eines Entwicklungsprozesses in dem Fehler unter Umst nden erst nachtr g lich modelliert werden muss es m glich sein
274. systematische Weise aus indem wir alle Transitionen entfernen die den Wert von c ver ndern und definieren E 2 a B a c B o Nun sind noch die eigentlichen Transitionen so einzuschr nken dass tats chlich nur von dem Kanal gelesen wird der durch c angezeigt wird So soll die Transition r nur schaltbereit sein wenn c 1 gilt Diese Verst rkung der Vorbedingung spiegelt sich formal wider in der Ent fernung aller Transitionen die diese Vorbedingung nicht erf llen Also erreichen wir durch die Entfernung der Transitionen Name Pre Input Output Post B 7 c 1 i a ola Th c 2 i a ola den gew nschten Effekt Unsere gesuchte Modifikation lautet also M Ey U Eo F Die Negativformulierungen der entfernten Transitionen sind nicht sehr intuitiv Errechnet man die resultierende Transitionsmenge des Systems MergeAM so erhalt man Name Pre Input Output Post Ti c 1 i a ola e e TA c 2 i a ola d c T3 c 11c 2 c 1 TA c 1Ac 2 c 2 Die Modifikationen die wir bislang vorgestellt haben nehmen unmittelbar Bezug auf die Beschreibungstechnik in der die Systeme spezifiziert werden Die relationalen Be schreibungen werden durch eine Modifikation der Relationen ver ndert Black Box Ei genschaften durch eine Ver nderung der Eigenschaften und Transitionssysteme durch eine Manipulation der Transitionen Eine Alternative stellt die Komposition mit Modi fikationskomponenten dar die wir im folgenden vorstellen wer
275. t Post TF Y Ansent f fail sent true 132 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN beschreibt die Modifikation M 7 EU E2 ein System in dem eine Fehlermeldung nur einmal gesendet werden kann Beide Modifikationen lassen sich kombinieren Ein durch M r EU Ey U Ey modifiziertes System gibt eine Fehlermeldung sofort aus bleibt dann aber in einem Fangzustand stehen da es keine Transitionen mehr gibt die bei g ltigem Y schaltbereit sind Durch Hinzuf gen von weiteren korrigierend eingreifenden Transitionen kann ein System wieder aus dem Fehlerzustand herausgef hrt werden Wir diskutieren dies im n chsten Abschnitt Beispiel 5 3 Fehlermeldung bei Datenverlust des Puffers Der Verlust von Daten im Puffer wird in Beispiel bP durch das Pr dikat Y g z erkannt Um die Fehlermeldung auf dem Ausgabekanal o ausgeben zu k nnen erweitern wir seinen Typ um das Element fail also type o DU fail Wir erg nzen standardm ig die Transition Name Pre Input Output Post Tf q z olfail post Damit diese Fehlermeldung nur einmal pro verlorenem Datum gesendet wird modifizieren wir Ty derart dass wieder ein konsistenter Zustand hergestellt wird also W nicht mehr gilt Dazu w hlen wir die Nachbedingung post so dass q unver ndert bleibt und z mittels 2 q angepasst wird Im Einzelfall kann also auf die Verwendung einer neuen Variable sent verzichtet werden und dennoch sichergestellt sein dass eine Fehlermeldung
276. t sich so lange wiederholen bis alle Versionen verwendet wurden In Abbildung B 8 ist der Ablauf f r drei Versionen dargestellt Die Pfeile beschreiben hier den Kontroll nicht den Datenflu Folgende Voraussetzungen ergeben sich f r die Anwendung von Recovery Blocks Es muss einen geeigneten Akzeptanztest geben der aufgrund des ihm gelieferten Ergebnis ses bei Kenntnis der Eingabedaten effizient berpr fen kann ob ein Ergebnis korrekt 2 2 FEHLERTOLERANZ 33 Akzeptanztest I ok Version If ae fail aati RAR L ok Version 2 ae fail I I ok Version 3 iaa fail Abbildung 2 8 Recovery Blocks oder zumindest akzeptabel ist Bei komplexen Aufgaben kann ein solcher Test nicht existieren oder nur in Form einer aufwendigen Neu oder Parallelberechnung des Er gebnisses Ferner muss es m glich sein das System in seinen Startzustand zur ckzu versetzen wenn ein Ergebnis nicht akzeptabel ist Bei intensiven Interaktionen mit der Umgebung kann dies eventuell nicht realisiert werden Bei zeitkritischen Anwendungen m ssen Zeitschranken auch dann noch eingehalten werden wenn erst sp t das hei t im Extremfall im zuletzt gestarteten Modul ein korrektes Ergebnis gefunden wird Es ist m glich die Komplexit t der erst sp ter verwendeten Module zu reduzieren und auf Teile der Funktionalit t zu verzichten Dies stellt eine Form von graceful degradation BJ dar N Versione
277. tbereit ist Es ist dann sichergestellt dass eine derartige Transition auch ausgef hrt wird Aufgrund der monoton abnehmen den Bewertungsfunktion n hert sich das System mit jedem Schritt dem Zielzustand o der schlie lich die Eigenschaft impliziert Durch die Entfernung von Transitionen ist es nun m glich dass eine relevante zielf h rende Transition aus dem System entfernt wurde und das System in seinem Ablauf nicht mehr im Sinne des Fortschrittsdiagramms vorankommt Dies wird daran erkennbar dass die Eigenschaft B En V V En f r einen Knoten mit den ausgehenden Transitionen 7 7 nicht mehr gilt Bleibt diese Figenschaft f r alle Knoten erhalten so bleibt auch das Fortschrittsdia gramm und damit die Aussage gt W g ltig Solange es einen Pfad zum Zielknoten o gibt k nnen Kanten gel scht und unerreichbare Knoten entfernt werden ohne die Fortschrittsaussage ung ltig zu machen Ist dies aber nicht der Fall und will man das Beweisdiagramm nicht vollst ndig ver werfen sondern zumindest teilweise beibehalten so sind folgende Ma nahmen m glich e Es werden wiederum Transitionen erg nzt so dass obige Eigenschaft erneut gilt Dieser Fall tritt typischerweise ein wenn man bestehende Transitionen durch hnliche Transitionen ersetzt die eine andere Wirkung zeigen k nnen dabei aber die reine Fortschrittseigenschaft nicht beeintr chtigen Die neuen Transitionen m ssen selbstverst ndlich auf kor
278. ten Wir werden in dieser Arbeit von nun an voraussetzen dass alle Transitionen in diesem Sinne wohlgeformt sind Pr ziser formuliert lautet die Transitionsmenge eines modifizierten Systems T E U F wobei F C F den Anteil von F beschreibt der die notwendigen Bedingungen erf llt Die f r alle Systeme S neutrale Modifikation kann durch dargestellt werden da mit ihr weder Transitionen erg nzt noch entfernt werden Selbstverst ndlich stellt eine Modifikation E F eine neutrale Modifikation dar wenn T N E und FC T gilt da in diesem Fall nur Transitionen entfernt werden die gar nicht enthalten sind bzw nur Transitionen erg nzt werden die bereits in der Transitionsmenge liegen Wir schlie en derartige F lle nicht von vornherein aus Durch Verwendung eines E mit T C E wird die Transitionsmenge eines Systems auf ein beliebig w hlbares F gesetzt da damit alle Transitionen in T entfernt werden und genau F verbleibt Erneut l t sich die Vervollst ndigung zu einem System mit chaotischem Verhalten durch Hinzunehmen aller Transitionen mittels F VAL x VAL erreichen nat rlich beschr nkt auf die Transitionen die die Forderung d aus Defini tion BBlerf llen Ein Transitionssystem enth lt noch die Variablenmenge A und die Initialbedingung Y als weitere Bestandteile die sich modifizieren lie en nderungen dieser Anteile ha ben wir jedoch nicht in M aufgenommen da sie auf Modifikationen der Transitionen reduz
279. terminismus oder die Anzahl der 60 KAPITEL 3 FORMALES SYSTEMMODELL Kan le sondern an Aussagen ber den dynamischen Anteil also die Abl ufe eines Systems Wir beschr nken uns auf Eigenschaften die sich durch Invarianten und durch Fort schrittsaussagen ausdr cken lassen Dazu werden Zustandspr dikate verwendet um Aussagen ber die Menge der Ausf hrungen von Systemen zu machen Sei S im folgen den gegeben durch S I 0 A Y T Definition 3 12 Invarianten Ein Zustandspr dikat eines Transitionssystems S hei t Invariante von S notiert als SIF inv wenn in allen Abl ufen in allen erreichbaren Zust nden wahr ist VEEKS eVkEeEKEG Die Giiltigkeit einer Invariante wird typischerweise gezeigt indem man nachweist dass die Invariante im Initialzustand g ltig ist und bei jeder m glichen Transition erhalten bleibt wie dies in der folgenden Beweisregel formalisiert ist Y p A rTr gt f f rale reT PATE f rale Te T S F inv Nicht jede Invariante l t sich auf diese Weise zeigen da eine Invariante zu schwach sein kann und damit unerreichbare Zust nde umfa t f r die die Beweisregel unn ti ge Beweisverpflichtungen erzeugt Die Invariante ist in einem solchen Fall geeignet zu verst rken Die st rkste Invariante eines Systems charakterisiert exakt die erreichbaren Zust nde eines Systems Dieses Beweisprinzip wird auch in einem Beweisdiagramm f r Invarianten verwendet da
280. tsprechend ae p O modelliert werden Wir w hlen die Komponente M mit der Schnittstelle 0 0 Das Verhalten kann wieder leicht als Black Box Spezifikation durch 0 Di o v o Dx amp o angegeben werden Selbstverst ndlich ist es auch m glich das Verhalten von M in an deren Beschreibungstechniken anzugeben Exemplarisch spezifizieren wir das Verhalten durch ein Transitionssystem S 0 0 0 c c 1 V c 2 T mit einem tabellarisch definierten T Name Pre Input Output Post T c 1NxdeD od old e c T m c 1AdED old _ c c TQ c 2AdED old d c T2 c 21ndeDs ord o d e c 4 3 Formalisierung der Fehlerbegriffe In der Literatur werden die Begriffe Fehler engl fault Fehlzustand engl error und Ausfall bzw Versagen engl failure meist nur informell beschrieben Sogar in Stan dardwerken wie beispielsweise 43 44 66 wird auf eine pr zise Definition verzichtet da eine formale Grundlage nicht zur Verf gung steht Mit dem in 4 2 vorgestellten Begriff der Modifikationen k nnen wir nun geeignete formale Definitionen f r Fehler Fehlerzustand und Versagen vorzuschlagen 4 3 FORMALISIERUNG DER FEHLERBEGRIFFE 93 4 3 1 Fehler Wie in KapitelB T bereits diskutiert bezeichnet man einen Fehler blicherweise als den eigentlichen urspr nglichen Grund f r die Abweichung eines konkreten fehlerbehafte ten Systems von seiner korrekten intendierten Fassung Ein Fehler ist also genau der Defekt der
281. u verallgemeinern Dazu geh ren neben den getakteten zeitbehafteten und synchronen Modellen auch Erweiterungen in Richtung mobiler und dynamischer Systeme Die damit verbundenen weiteren Freiheitsgrade im Verhalten von Systemen bergen ein weiteres Fehlerpotential das zu modellieren und zu untersuchen ist Mit der formalen Einf hrung des Begriffs der Modifikationen wurden Fehler expli zit als eigene formale Gr e definiert die mit Hilfe verschiedener Beschreibungs techniken und auf unterschiedlichen Abstraktionsstufen dargestellt werden kann Wir haben bereits einige Eigenschaften dieses Begriffs untersucht und Operatoren f r Modifikationen definiert Eine weiterf hrende Untersuchung und die Defini tion zus tzlicher Operatoren ist sinnvoll da die Ausdruckskraft und damit der Nutzen des Formalismus weiter erh ht werden kann Wir geben einige potentielle und anspruchsvolle aber lohnenswerte Weiterentwicklungen an Eine Ordnungsrelation zwischen Modifikationen kann den Vergleich von Feh lern erm glichen und damit ausdr cken wann ein Fehler schlimmer ist als ein anderer Damit werden erw nschte Monotonieaussagen m glich To leriert ein System einen Fehler so toleriert es auch jede schw chere Form dieses Fehlers Als allgemeinerer Ansatz bietet es sich an eine Metrik f r Modifikationen zu definieren Eine Metrik f r Fehler ordnet zwei Fehlermodellen eine Ma zahl zu die den Unterschied zwischen diesen bewertet Ei
282. umiert werden Die zust ndige Transition T2 kann dies nur durchf hren wenn die Vorbedingung q gt 0 erf llt ist Ein blockierender Zustand ist also beschrieben durch A R CIA G lt 0 Ein Eingabestrom i kann nur dann vollst ndig gelesen werden wenn die beiden obigen F lle nie eintreten wenn also Vie e i Ana erf llt ist Wir leiten daraus nun eine Anforderung an den Eingabestrom ab Durch Expansion der Negation ergibt sich Vi de w A d CisH a lt N A io R Cis q gt 0 Wir miissen nun eine Invariante des Puffers verwenden die den Zusammenhang zwischen der Lange des Puffers und dem Eingabestrom beschreibt Sie kann mit den Techniken aus Abschnitt B 3 2 leicht bewiesen werden 4 D i F R Or Damit ergibt sich durch Ersetzung i gt DOi H ROL lt N A i gt DOi R Oi gt 0 und daraus unter Ausnutzung der Eigenschaften der Operators ve de dEi gt D i d HROU c i R Cis DO i R HRSG R 1 gt 0 vide i d d lt N N 118 KAPITEL 4 FORMALE MODELLIERUNG VON FEHLERN woraus wir trivialerweise schlie en k nnen auf vie de i d Cis D8 i d HRO o d SNA i R Ci gt D i R H R OU gt R gt 0 Damit ist f r jeden Pr fix i ob er nun mit einer Nachricht d oder R endet gezeigt dass d VVi Lie0 lt DO8i H i lt N was genau der Umgebungsannahme der Black Box
283. und definieren f r ihn ein Fehlermodell zusammen mit einem Fehlererkennungspr dikat Beispiel 5 2 Erkennung von Datenverlust im Puffer In Beispiel AZ haben wir eine Spezifikation des Puffers definiert in der die Daten in einer Variablen q gespeichert werden Wir wollen nun den potentiellen Datenverlust von Daten aus q modellieren und ein Pr dikat Y definieren das diesen Fehler aufdeckt Der Datenverlust wird durch die Erg nzung einer Transition 73 dargestellt die das erste Datum in q entfernt Name Pre Input Output Post T3 q gt 0 _ q rt q Da diese Transition immer schaltbereit ist wenn Daten in q vorhanden sind und da jedes Datum vor einer potentiellen Ausgabe einmal ganz vorne in q steht kann jedes Datum verlo ren gehen Durch eine Verst rkung der Vorbedingung k nnte man den Verlust auf bestimmte 5 3 FEHLERERKENNUNG 129 T3 z 1 z lt Fa Q 71 72 71 72 73 Abbildung 5 3 Invariantendiagramm f r Buffer Daten einschr nken oder auch durch Orakelstr me Einschr nkungen ber die H ufigkeit von Datenverlust ausdr cken Ohne aufgetretenen Datenverlust sind in q genau i o Nachrichten enthalten also genau die Differenz zwischen der Zahl der bereits empfangenen Daten und der schon wieder ausgegebenen Daten Ein Verlust ist also daran erkennbar dass 4 FH 0 Weder 7 noch o sind allerdings Gr en auf die das System zugreifen darf Sie sind zwar in unserem Formalis
284. ung auf Basis mathematischer Grund lagen auf eine pr zise und verifizierbare Weise unterst tzt Im Idealfall stellen die formalen Methoden dazu Notationen und eine Sprache bereit mit der es m glich wird Spezifikationen mit einer klar definierten Semantik zu formulieren Im Gegensatz zu informellen Spezifikationen wird es damit eher m glich die Forderun gen nach Eindeutigkeit und Konsistenz zu erf llen Eigenschaften einer Spezifikation oder eines Systems und durch sie implizierte Konsequenzen k nnen unter Verwendung eines logischen Kalk ls formal bewiesen werden Entwicklungsschritte die von Spezi fikationen als abstrakten Systembeschreibungen hin zu einer ausf hrbaren Implemen tierung f hren werden durch geeignete Verfeinerungsbegriffe unterst tzt Werkzeuge stellen dazu die notwendige Infrastruktur zur Bearbeitung von Systembeschreibungen und eine m glichst automatisierte Durchf hrung von Beweisen bereit Als Beispiele f r formale Ans tze lassen sich nennen die Methoden RAISE Unity VDM Z TLA die B Methode algebraische Ans tze wie CASL Focus mit dem Werk zeug AUTOFOCUS und Petri Netze Diese Beispiele bieten vielmals nur Teilaspekte formaler Methoden und stellen oft nur eine Sprache zur Spezifikation bereit ohne entsprechende Konzepte zur Verfeinerung und ohne Werkzeuge Sie unterscheiden sich teilweise wesentlich in ihrem zugrundeliegenden Systemmodell das unter anderem die prinzipiellen Paradigma f r die Kommuni
285. ur Beschreibung von Abweichungen Wir werden schlie lich Techniken vorstellen die in einer Systementwicklung sinnvoll zum Umgang mit Fehlern verwendet werden k nnen 36 KAPITEL 2 DER FEHLERBEGRIFF Kapitel 3 Formales Systemmodell Dieses Kapitel beschreibt das Systemmodell der Methodik Focus das wir als Grund lage f r diese Arbeit gew hlt haben Ein Systemmodell bietet eine allgemeine und ab strakte Charakterisierung der Klasse der Systeme die uns interessieren und sich zur Modellierung verteilter reaktiver Systeme eignen Es definiert den Systembegriff die Modellierung von Verhalten Kommunikation Komposition und verschiedene Verfein erungs und Beweiskonzepte Nach einem berblick ber das Systemmodell und einer Darstellung formaler Grundla gen definieren wir die semantische Sicht auf Schnittstellen Abschnitt B 3 und auf das Verhalten von Systemen Abschnitt 8 4 Zur Beschreibung konkreter Systeme f hren wir die sogenannten Black Box Spezifikationen und Zustandstransitionssysteme in den AbschnittenB 5JundB 6lein Die Komposition von Systemen wird inB 7ldefiniert gefolgt von Techniken und Begriffen zur Verifikation und Verfeinerung Schlie lich skizzieren wir einen idealisierten Entwicklungsbegriff und enden mit einem Ausblick auf alternati ve Systemmodelle Wir werden zur Illustration der Konzepte eine einfache Komponente Merge als durchg ngiges Beispiel verwenden In Kapitel 4 werden wir die Fehlermodel lierung auf
286. ur in der Wahl der Namen f r interne Variablen unterscheiden haben nat rlich die gleichen Eigenschaften w rden aber verschiedene Formulierungen von Modifikationen ben tigen Dieses Problem lie e sich noch beheben durch entsprechende Formalismen die gegen ber Variablennamen indifferent sind die aber die praktische Handhabung erschweren w rden Dennoch kann beispielsweise das Hinzuf gen der Transition Name Pre Input Output Post T ye d in Systemen mit gleicher Schnittstelle aber v llig anderer Funktionalit t vollkommen unterschiedliche Auswirkungen haben Stellt dies in der Komponente Merge den unbe merkt bleibenden Verlust eines Datums dar k nnte dies in einer anderen Komponente den Verlust einer Quittierung darstellen die zum Beispiel das R cksetzen der Kompo nente bewirkt um nur ein willk rliches Beispiel zu nennen Wir beziehen korrespondie rende Modifikationen daher im allgemeinen sinnvollerweise auf konkrete Systeme Es ist eine komplexe Aufgabe in konkreten Anwendungsf llen korrespondierende Mo difikationen zu finden Hat man also bereits einen Beweis f r S gefunden und modifiziert man eine der beiden Systembeschreibungen so ergeben sich zwei Fragestel lungen e Wie lautet die zu einer vorgegeben Modifikation passende korrespondierende Mo difikation Ideal w re ein konstruktives Verfahren das zu gegebenen Systembeschreibungen und einer Modifikation die entsprechende korrespondierende Modifi
287. verbundenen Ausdehnungen von Hardwarekomponenten oder Feuchtigkeitseinfl sse auf elektrische Kontakte sind typische Beispiele f r physikalische Einfl sse die auf ein System einwirken k nnen und sowohl im Betrieb als auch bei der Herstellung eines Systems Fehler bewir ken Fehler durch Menschen k nnen sowohl w hrend der Entstehungszeit durch einen Entwickler in ein System gelangen als auch w hrend der Laufzeit eines Systems durch einen Benutzer der durch fehlerhafte Bedienung die Korrektheit eines Systemverhaltens gef hrden kann 2 1 FEHLER 15 Es l t sich argumentieren dass eigentlich alle Arten von Fehlern den Menschen als Verursacher haben denn auch physikalische Fehler sind nur ein Zeichen daf r dass der Mensch die Technik nicht ausreichend beherrscht und er nicht in der Lage ist physikalische Fehlerquellen durch entsprechende Gegenma nahmen aus zuschlie en Aber dennoch hat die Unterscheidung ihre Rechtfertigung Sie k nnen von einem Entwickler bewu t in Kauf genommen werden da Ma nahmen zu ihrer vollst ndigen Vermeidung zu aufwendig w ren wie beispielsweise Abschirmungen von Kommunikationskan len oder h here Qualit tsanforderungen in einem Her stellungsproze von Hardwarekomponenten Stattdessen kann auf Mechanismen zur Tolerierung der physikalischen Fehler ausgewichen werden Zeitpunkt des Auftretens Ein Fehler kann zur Zeitpunkt der Entwicklung in ein System gelangen oder w hrend seines Betriebes zur Lauf
288. werden k nnen In diesem Kapitel haben wir gezeigt wie typische Entwicklungsschritte f r Systeme in denen Fehler eine Rolle spielen in unserem Formalismus durchgef hrt werden k nnen Wir haben dazu einige typische Fehlerklassen formuliert von denen Systeme betroffen sein k nnen Damit konnte die allgemeine Ausdruckskraft der Modifikationen gut unter mauert werden F r den praktischen Einsatz ist ein Katalog von Fehlerklassen denkbar der sinnvollerweise in Kombination mit den jeweils entsprechenden Gegenma nahmen zur Verf gung gestellt wird Fehlerannahmen in einem System k nnen nicht lokal sein wenn die Zusammenh nge und H ufigkeiten des Auftretens von Fehlern mehrere Komponenten betreffen Wir 154 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN haben gezeigt wie sich diese Zusammenh nge mit bereits existierenden Beschreibungs mitteln unseres Formalismus geeignet beschreiben lassen Es k nnen virtuelle Kompo nenten verwendet werden die nicht implementiert werden aber eine komponenten ber greifende Annahme ber Fehler beschreiben und in einer formalen Untersuchung in der gleichen Weise wie reale Komponenten behandelt werden k nnen Wir haben gezeigt dass die Fehlererkennung mit Hilfe von Zustandspr dikaten forma lisiert werden kann und haben Kriterien angegeben die ein fehlererkennendes Pr dikat relativ zu einem definierten Fehler zu erf llen hat Wir sind damit also in der Lage einen Fehler mit Hilfe von Modifik
289. wickler hier w hlt ist unmittelbar von der Anwen dung abh ngig Das neue Verhalten G muss aber die Forderung erf llen dass es sich nicht vom urspr nglichen Verhalten unterscheidet wenn die Eingaben die Annahme A erf llen Gilt also A und G so muss auch G erf llt sein W hrend das Verhalten bei auftretenden externen Fehlern im urspr nglichen System A G unspezifiziert und damit beliebig ist reagiert das System A G auf wohlde finierte Weise Damit ist im System A G der Nichtdeterminismus reduziert und dieser Entwicklungsschritt stellt eine Verhaltensverfeinerung im Sinne von Abschnitt 3 9 1 dar Folgende einfach beweisbare Regel fa t diese Aussage zusammen A gt A A gt G gt G A G A G 140 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN Bei Black Box Spezifikationen mit expliziten Umgebungsannahmen l t sich die Sys temrobustheit also einfach durch eine Verst rkung des verhaltensbeschreibenden Pr dikates darstellen das zus tzlich eine Aussage ber das Systemverhalten im Fehlerfalle macht Beispiel 5 6 Unterlauf des Puffers A G Spezifikation Wir erh hen die Robustheit des Puffers der in BeispielBJim Format einer A G Spezifikation definiert wurde Dazu wollen wir Eingabestr me zulassen in denen Anfragen an den Puffer geschickt werden ohne dass vorher ausreichend viele Daten gesendet wurden In einem solchen Fall tritt also ein sogenannter Unterlauf des Puffers auf Da
290. y number 1101 in Lecture Notes in Computer Science Springer 1996 30 GrosU RADU KETIL STOLEN und MANFRED Broy A Denotational Model for Mobile Point to Point Data flow Networks with Channel Sharing Technischer Bericht TUM I9724 Technische Universit t M nchen 1997 31 HERLIHY MAURICE and JEANNETTE WING Specifying graceful degradation in distributed systems IEEE Transactions on Parallel and Distributed Systems 2 1 1991 32 HINKEL URSULA und KATHARINA SPIES Spezifikationsmethodik f r mobile dy namische FOCUS Netze In WOLISZ A I SCHIEFERDECKER und A RENNOCH Herausgeber Formale Beschreibungstechniken f r verteilte Systeme GI ITG Fachgespr ch 1997 GMD Verlag St Augustin 1997 33 HUBER FRANZ BERNHARD SCH TZ ALEX SCHMIDT and KATHARINA SPIES Autofocus a tool for distributed systems specification In Proceedings FTRTFT 96 Formal Techniques in Real Time and Fault Tolerant Systems number 1135 in Lecture Notes in Computer Science 1996 34 HUBER FRANZ BERNHARD SCHATZ und KATHARINA SPIES AutoFocus Ein Werkzeugkonzept zur Beschreibung verteilter Systeme In HERZOG ULRICH Herausgeber Formale Beschreibungstechniken fiir verteilte Systeme Universitat Erlangen Niirnberg 1996 35 JANOWKSI TOMASZ Fault tolerant bisimulations and process transformations In FTRTFT 94 Formal Techniques in Real Time and Fault Tolerant Systems number 863 in Lecture Notes in Computer Science Spr
291. ys tem nachtr glich robuster gegen ber Fehlern in der Systemumgebung zu machen In Abschnitt 5 7 wird schlie lich aufgezeigt wie Beweise die f r ein fehlerfreies System gef hrt wurden an die fehlerbehaftete Version angepasst werden k nnen 5 1 Beispiele f r Fehlermodelle Der Umgang mit Fehlern erfordert eine explizite Formulierung der Fehlerklassen mit deren Auftreten man rechnet Zur Illustration der Ausdrucksm chtigkeit unserer Be schreibungstechniken geben wir in diesem Abschnitt die Formalisierung einiger Beispiele 121 122 KAPITEL 5 METHODISCHER UMGANG MIT FEHLERN an die in der Literatur als typische Fehlerklassen identifiziert werden 23 27 Wir modellieren die folgenden Fehlerklassen sowohl im Formalismus der Black Box Spe zifikationen als auch mit Transitionssystemen Sei dazu eine Spezifikation bzw ein Transitionssystem S mit S I O A T T gegeben an das wir bis auf die Annahme der Existenz von Ausgabekan len keine weiteren Anforderungen stellen Die folgenden als Modifikationen dargestellten Fehlermodelle k nnen also in Verbindung mit beliebi gen Systemen verwendet werden 5 1 1 Crash failure Bei diesem Fehlermodell kann ein System spontan jegliche Aktivit ten einstellen und somit keine Nachrichten mehr auf seinen Ausgabekan len ausgeben Im Rahmen der Black Box Spezifikationen stellen wir dies durch eine Modifikation M true r dar wobei r partielle Ausgabestr me erg nzt Wir gehe
292. ystems als solche zu charakterisieren und zu beschreiben Sowohl f r Black Box Spezifikationen als auch f r Transitionssysteme haben wir in Kapitel 6 gezeigt wie externe Fehler angegeben werden k nnen Dar ber hinaus haben wir gezeigt dass in einem Transitionssystem oft implizite Umge bungsannahmen enthalten sind die formal abgeleitet werden k nnen Wir haben dies an einem Beispiel demonstriert In Kapitel 45 haben wir Eigenschaften der Modifikationen ermittelt und pr sen tiert die in einer Systementwicklung gewinnbringend genutzt werden k nnen So haben wir die Kombination von Modifikationen definiert mit der die erneu te Modifikation von bereits modifizierten Systemen kompakt ausgedr ckt werden kann Mit Hilfe der Modifikationsfortpflanzung k nnen in einem zusammengesetz ten System aus der Modifikation einer Teilkomponente die Auswirkungen auf das Verhalten des Gesamtsystems konstruktiv ermittelt werden 160 KAPITEL 6 ZUSAMMENFASSUNG UND AUSBLICK Diese Eigenschaften wurden f r Modifikationen in den beiden Beschreibungstech niken der Black Box Spezifikationen und der Transitionssysteme pr sentiert Mit der Technik der Verifikationsdiagramme k nnen Beweise von Black Box Ei genschaften von Transitionssystemen repr sentiert werden Werden die Eigen schaften oder das Transitionssystem durch Modifikationen ver ndert wird ein bestehendes Verifikationsdiagramm im allgemeinen ung ltig Werden aber korre spondierende Modi
293. ystems ist relativ zur Definition der Modifikationen So ist durch die Wahl von M beliebig definierbar ob ein fehler induziertes Gesamtverhalten als vorhersehbarer Fehler oder als chaotisches Verhalten betrachtet wird W hlt man beispielsweise als Modifikation die Erg nzung zu beliebi gem Verhalten so kann der Fall Chaos nicht mehr auftreten und jeder Fehler wird als 4 5 EIGENSCHAFTEN VON MODIFIKATIONEN 103 vorhergesehen qualifiziert es liegt also mindestens eine D mpfung entsprechend 3a vor W hlt man eine neutrale Modifikation zur Definition der Fehler des Gesamtsys tems wird jegliche Abweichung vom Normalverhalten als Chaos bewertet die Klasse Fehler tritt nicht mehr auf Es kommen dann zur Bewertung der D mpfung nur noch die beiden Klassen 1 und 3b in Frage und eine Bewertung von Systemen bez glich ihrer Fehlerd mpfung kann nur noch sehr grob ausfallen Die Wahl der Modifikationen mit der verbundenen Einteilung des Verhaltens in die genannten drei Klassen hat also sorgf ltig zu erfolgen um eine sinnvolle Bewertung zu erm glichen Die Charakterisierung von Fehlertoleranz entsprechend Definition MMO aus Abschnitt 4 1 als korrespondierende Modifikationen entspricht den Varianten 3a und 4 der Fehlerd mpfung Die Abwesenheit von Fehlern bewirkt Normalverhalten auftretende Fehler bewirken Fehlverhalten des Gesamtsystems und ber die Auswirkungen unvor hergesehener Fehler wird keine Aussage gemacht Typischerw
294. ystems k nnen wir einschr nken indem wir Kan le entfernen oder den Typ von Kan len reduzieren Dies kann aber zu Problemen f hren wenn dies wie im Fall der Schnittstellenerweiterung auf eine Art und Weise geschehen soll die das Verhalten unver ndert l t Ein problematischer Fall ist die Beschr nkung von Ausgabekan len Hat ein unmodifi ziertes System auf eine bestimmte Eingabe mit einer oder mehreren Ausgabenachrich ten reagiert die n n durch die Modifikation der Schnittstelle nicht mehr m glich sein k nnen ist die Linkstotalit t der Verhaltensrelation gef hrdet Ist das System determi nistisch so l t sich in diesem Fall keine allgemein definierbare sinnvolle Reaktion des Systems mehr finden Doch auch das Entfernen von Eingabekan len kann zu Komplikationen f hren f r die sich keine sinnvolle allgemeine verhaltensneutrale Anpassung der Verhaltensrelation finden l t War der Fortschritt einer Systemaktivit t beispielsweise von einem stetigen Empfang von Nachrichten ber einen bestimmten Kanal abh ngig und wird dieser Kanal entfernt so bleibt die Frage offen wie das Verhalten nun angepa t werden soll Soll die Aktivit t von diesem Kanal unabh ngig gemacht werden oder soll das System keinerlei Ausgaben mehr machen Die Typeinschr nkung auf den Eingabekan len stellt dagegen ein unwesentlicheres Pro blem dar da die verhaltensbeschreibende Relation vollkommen unver ndert bleiben kann Die Einschr
295. z y EXTEND M gt d 72 2 d y EXTEND M F r Transitionssysteme modellieren wir dieses Fehlermodell durch eine Erg nzung neuer Transitionen verm ge der Modifikation M F mit F df a 2 ye a y ET A Bene g Vie y Wir f gen also diejenigen Transitionen hinzu die den bestehenden in T sehr hnlich sind und sich nur darin unterscheiden dass sie den Ausgabestrom auf dem Kanal o unver ndert lassen Man erg nzt also zu jeder Transition die eine Ausgabe auf o macht eine weitere Transition die sich ebenso verh lt aber die Ausgabe auf o nicht macht Obige Formalisierung macht diese Intuition nicht unmittelbar deutlich Hat man ein konkretes System beispielsweise tabellarisch beschrieben lassen sich die zus tzlichen Transitionen anschaulicher beschreiben F r jede Transition die in der tabellarischen Darstellung in der Spalte Output einen Ausdruck der Form olexpr hat erg nzen wir dieselbe Transition aber ohne diese Ausgabeanweisung 5 1 4 Byzantine failure Bei diesem Fehlermodell verh lt sich das betroffene System auf v llig unvorhersehbare Weise Da damit jedes Verhalten m glich wird bezeichnen man dies auch als chaotisches Verhalten Es ist sehr leicht zu formalisieren durch die Modifikationen M true true bzw M F wobei F die Gesamtheit aller Transitionen enth lt F amp VALx VAL Bei diesem Fehlermodell liegt keinerlei Regelm igkeit im Verhalten vor so dass sich d
296. zeit Fehler in der Logik eines Systems Softwarefehler oder Defizite in einer Systemarchitektur entstehen w hrend der Entwicklung eines Systems Bedienfehler oder Fehler physikalischer Natur sind dagegen Fehler die erst zur Laufzeit in einem System auftreten k nnen Dauer Bez glich der Dauer eines Fehler unterscheidet man permanente Fehler und tempor re Fehler Ein Fehler hei t permanent wenn er vom Zeitpunkt seines ersten Auftretens an dauerhaft und ununterbrochen im System verbleibt Insbe sondere sind dauerhafte Fehler die sogar gleich von Anfang an in einem System enthalten sind permanent Tempor re Fehler sind nur zeitweilig in einen System enthalten Man nennt sie transient wenn sie nur einmal f r einen endlichen Zeit raum auftreten und intermittierend wenn sie wiederholt auftreten aber dennoch nicht permanent sind Grund Man kann zwei Gr nde f r vorhandene Fehler unterscheiden Ein Fehler kann zuf llig in einem System vorhanden sein oder dort absichtlich aufgenommen wer den Ein zuf lliger Fehler kann sowohl durch Unkenntnis Fahrl ssigkeit als auch Unverm gen des Entwicklers entstehen der aus diesen Gr nden entgegen seiner Bem hungen ein fehlerbehaftetes System schafft Ein absichtlicher Fehler kann beispielsweise f r Testzwecke aufgenommen werden oder aber auch in krimineller oder b swilliger Absicht um einen Schaden zu erzeugen oder Daten aussp hen zu k nnen Schwere Die Schwere eines Fehlers kann nach vers
297. ziert eine Menge von einzelnen Beweisverpflichtungen K nnen diese nachgewiesen werden so ist ein Diagramm g ltig und repr sentiert eine Gesamtaussage Verifikationsdiagramme wurden in 14 50 eingef hrt und in I f r unser Systemmodell spezialisiert Wir unterscheiden Diagramme zum Nachweis von Invarianten und Diagramme zum Nachweis von Fortschrittseigenschaften Beide haben aber die folgenden Charakteristika gemeinsam Ein Verifikationsdiagramm zu einem Transitionssystem S I O A T T besteht aus einem gerichteten zusammenh ngenden Graphen mit einer endlichen Menge von Knoten die mit Pr dikaten o beschriftet sind Die Pr dikate sind Zustand spr dikate des Transitionssystems also mit free C IU OU A Die Kanten des Diagramms sind mit Mengen von Transitionen beschriftet Invariantendiagramme Ein Diagramm zum Nachweis einer Invariante erf llt zus tzlich zu den eben genannten die folgenden Eigenschaften e Bei Start des Systems S ist mindestens eines der Pr dikate erf llt Die erf ll ten Pr dikate werden mit einem schwarzen Punkt links in einem Knoten als Startzust nde markiert Y ov Vn 3 8 VERIFIKATION VON EIGENSCHAFTEN 63 e F r jeden Knoten und jede Transition r T gilt genau einer der beiden folgenden F lle Vom Knoten geht keine mit T beschriftete Kante aus und es gilt AT gt p Dieser Fall liegt auch dann vor wenn 7 im Knoten nicht schaltbereit i
298. zu verstehen ist also zu identifizieren mit einer Abweichung eines vorliegenden Ist von einem erw nschten Soll Eine intensivere Diskussion Charakterisierung und Klassifizierung des Begriffes ist als Grundlage dieser Arbeit lohnenswert und ist in Kapitel B zu finden 1 3 MOTIVATION 5 1 3 Motivation Der Begriff des Fehlers spielt in einer Systementwicklung die mit Hilfe verbreiteter formaler Hilfsmittel durchgef hrt wird kaum eine Rolle Es mag sogar widerspr chlich erscheinen hier einen Zusammenhang zu sehen Formale Methoden werden ja gerade verwendet um korrekte also fehlerfreie Systeme zu entwickeln Diese Sicht ist aber nur zutreffend wenn man Fehler im Sinne von Fehlern im Entwicklungsproze versteht wie beispielsweise nicht aufgedeckte Inkonsistenzen in Spezifikationen oder inkorrekte Verfeinerungsschritte Die Verwendung formaler Methoden dient hier tats chlich der Fehlervermeidung Eine andere Klasse von Fehlern sind aber Fehler die in einer abstrakten Spezifikati on nicht auftreten in einer realen Implementierung aber durchaus Eine Abstraktion ist in der Regel mit idealisierenden Annahmen verbunden die beispielsweise Laufzeit fehler nicht ber cksichtigen die durch M ngel in der Hardware oder in verwendeten Komponenten ausgel st werden und zum Versagen des Systems f hren k nnen Diese Abstraktion von beispielsweise physikalischen Defiziten ist selbstverst ndlich erw nscht denn sie tr gt zur Reduktion der

Formale Fehlermodellierung fuer verteilte reaktive

Contents

Download Pdf Manuals

Related Search

Related Contents