Methoden der künstlichen Intelligenz bei Entwurf und Analyse fehlertoleranter Rechensysteme

deposit_hagen

Publikationsserver der Universitätsbibliothek

Mathematik und

Informatik

Informatik-Berichte 77 – 02/1988

Methoden der künstlichen Intelligenz bei

Entwurf und Analyse fehlertoleranter

Rechensysteme

I

DANKSAGUNG

Jedes Expertensystem braucht "seinen" Experten.

Er liefert das nötige Wissen, auf dem das System dann aufbaut.

Für diese Diplomarbeit hat sich dankenswerterweise Herr Prof.Dr.W.Schneeweiss zur Verfügung gestellt.

In vielen Tagen der Diskussion haben wir gemeinsam das Wissen gesammelt und strukturiert, das nun die Grundlage des Systems 'FAULT-EXPERT' darstellt.

Für die aufgewandte Zeit und Mühe, ebenso wie für die freundliche Unterstützung, möchte ich mich bei Herrn Prof.Dr.W.Schneeweiss besonders herzlich bedanken.

Wuppertal, im November 1987 Michael Schulte

INHALTSVERZEICHNIS

Seite

Danksagung • • • • • • • • •

e...

^I

Inhaltsverzeichnis

...

^II

Hinweise • • • . • • • • • • • • • • . • • . • • • • • • • • . • • • • • . • • . • • • • • • • • • • • • • • • . . IV

1 • Ein 1 e i tun g • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 1

2. Ablauf der Entwicklung Prototyping ···••••••••••••••••••· ²

3. Grobstruktur von 'FAULT-EXPERT'

...

⁴

3 .1 Begriffsbaum • • • • • • • • . • • . • • . . • • • • • • • • • • • • • • • • • • • • • • • • • • • 4 3.1.1 Zum fertigen Begriffsbaum•••••••••••••••••••••••••• 5 3.1.2 Zum Entstehen des Begriffsbaumes ••••••••••••••••••• 13

3.2 Merkmale eines Rechensystems 15

3.2.1 Strukturierte Darstellung von Rechensystemen••••••• 15 3.2.2 Leistungs- und Kostenmerkmale ·••·•••••••••••••••••• 16 3.3 Ausgestaltung des Inferenzmechanismus

3.4 Daten zu den Vorschlägen von 'FAULT-EXPERT' 3.4.1 Allgemeiner Ablauf eines Vorschlages

18 20 20 3.4.2 Zum Entstehen der Vorschlagsdaten · • • · • · · · · • • · • • • · • · 20 3.5 Speicherprobleme

...

'FAULT-EXPERT' 3.6 Gesamtstruktur von

3.7 Sitzungsablauf

...

22 24 26

III

4. Feinstruktur von 'FAULT-EXPERT'

...

4.1 Zusammenstellung der Daten, Regeln und Vorschläge

4.1.1 Alle Übergangsregeln

...

4.1.2 Alle Vorschlagsdaten

...

4.1.3 Default-Werte

...

31 31 31 37 41 4.2 Programmiermethodik•••••••••••••••••••••••••••••••••••• 42 4.3 Benutzerdaten Datenbank

...

4.4 Kommentiertes Programmlisting von 4.4.1 Listing des Hauptprogrammes

'FAULT-EXPERT'

4.4.2 Listing des Kommentar- und Textfiles 'TEXT.DAT'

43 45 45 68

S. Test und Beurte i 1 ung • • • • . . • • . . . • • • . . • • . . . • . . . • . • . . . • . . 83

6. Erweiterungs- und Verbesserungsmöglichkeiten 85

7. Bewertung, auch gegenüber anderen Expertensystemen•••••·•• 86

8. Literaturverzeichnis

...

⁸⁸

HINWEISE

Im folgenden sollen noch einige Hinweise zur Behandlung von Zitaten, Eigennamen usw. gegeben werden.

- Literaturverweise werden an den Stellen der Diplomarbeit angegeben, an denen die Literatur Einfluß auf Gestaltung oder Text der vorlie- genden Arbeit hatte.

Bei konkreten Zitaten sind diese zusätzlich durch"

zeichnet.

- Eigennamen zeichnet.

(z.B. aus dem Programmtext) sind durch '

"gekenn-

' gekenn-

- Werden Eigennamen nach ihrer Einführung immer wieder verwendet, so werden sie später auch ohne ' ' geschrieben, wie zum Beispiel der Name des behandelten Expertensystems 'FAULT-EXPERT'.

-1-

1. EINLEITUNG

Das Gebiet 'Fehlertolerierende Rechensysteme' besitzt eine erhebliche Breite.

Die Fragestellungen reichen vom Personaleinsatz über Hardware-Maßnahmen (z.B. Verdoppelung) bis zu Software-Maßnahmen.

Daher gibt es nur wenige Fachleute, die den gesamten Wissensbereich abdecken können.

Aus dieser Situation heraus entstand die Idee, ein wissensbasiertes System zu erstellen, das den Entwickler eines Rechensystems bei der Durchführung von Fehlertoleranz-Maßnahmen berät und ihm insbesondere erst alle Möglichkeiten aufzeigt.

Genauer gesagt, das Expertensystem soll der punktuellen Verbesserung der Fehlertoleranz bestehender Systeme dienen und dabei den Faktor Preis berücksichtigen.

Ziel ist es nicht, ein nach kommerziellen Gesichtspunkten fertiges System zu entwickeln; Ziel ist es vielmehr, das Wissensgebiet 'Fehler- tolerierende Rechensysteme' im Hinblick auf die Realisierung eines Expertensystems zu untersuchen, alle wichtigen Entwurfsentscheidungen aufzuzeigen und die wesentlichen Teile in PROLOG zu implementieren.

Auf eine perfekte Ausgestaltung der Benutzerschnittstelle wird dabei kein großes Gewicht gelegt.

Aus obigen Zielsetzungen und der relativen Ungewißheit über die Mög- lichkeiten das Wissensgebiet zu strukturieren, ergab sich zwangsläufig der Wunsch nach mög¹ichst großer Flexibilität bei der Entwicklung.

Damit schieden die meisten gängigen Werkzeuge aus (vgl. [5] S.97).

Weiter war aus Gründen der Rechnerverfügbarkeit die Entwicklung auf einem PC wünschenswert.

Somit fiel die Entscheidung auf 'TURBO-PROLOG' der Firma 'BORLAND', das auf einem aufgerüsteten (512 KB) TA PC 50-1 verwendet wurde.

Vorteile von TURBO-PROLOG sind: (siehe u.a. [7]) - Compiliertes Prolog und somit hohe Geschwindigkeit - Gute Entwicklungsumgebung.

Nachteile gegenüber dem 'Clocksin-Mellish' Prolog-Standard sind:

- Keine neuen Regeln/Prädikate während Programmablauf erzeugbar.

- Fehlen der Konstrukte 'call', 'functor' und '=•• •

- Die dynamisch erzeugbaren Datenbank-Objekte ('assert','retract') sind kein vollwertiger Ersatz dafür.

2. ABLAUF DER ENTWICKLUNG - PROTOTYPING

Im Unterschied zum klassischen Software-Life-Cycle werden bei der Entwicklung von Expertensystemen einige Stufen mehrmals durchlaufen

([4) S.40).

Hieraus entstand der Begriff des "Prototyping" ([4] S.49 bzw. [6] S.19).

Er besagt, daß möglichst irüh eine lauffähige Ver-ion des Systems fertig sein sollte, die später erweitert und verbessert wird.

Dieser Art der Software-Entwicklung kommt gerade PROLOG sehr entgegen.

In PROLOG können Regeln eingefügt oder gestrichen werden, ohne die Grundstruktur des Systems zu verändern.

Aus diesen überlegungen heraus entstand ein Ablaufplan zur Entwicklung von 'FAULT-EXPERT', der weitgehend einhalten werden konnte und im

folgenden wiedergegeben sein soll:

a.) Problemanalyse

->

bis Ende Mai 1987 - Zielerstellung;

- Vorbereitungen;

- Wahl von TURBO-PROLOG.

b.) Konzeption

->

Juni bis August 1987 - Strukturierung des Wissensgebietes;

- Wissen unformal erarbeiten;

- Grundlegende Entwurfsentscheidungen.

c.) Formalisierung

->

Juli bis September 1987 - Anpassen des Wissens an PROLOG;

- Detaillierter Entwurf.

d.} Implementierung

->

Juli bis September 1987 - Programmieren in TURBO-PROLOG.

e.) Test und Bewertung

->

Juli bis Oktober 1987 - Testläufe erarbeiten und durchführen;

- Vergleich mit existierenden Expertensystemen.

An den sich überschneidenden Zeitangaben ist deutlich abzulesen, daß immer wieder in vorherige Phasen zurückgesprungen wurde (Prototyping).

Zu einem Zeitpunkt, an dem noch lange nicht alle Regeln und Fakten erarbeitet waren, existierte trotzdem schon ein lauffähiges System.

Diese Prototypen wurden dann im Laufe der Zeit verbessert beziehungsweise erweitert.

- ,__

_.,

An dieser Stelle soll darauf hingewiesen werden, daß Ende Juni die Zielvorstellungen an das Produkt 'FAULT-EXPERT' leicht geändert werden mußten.

Zunächst war es vorgesehen gewesen, das in PASCAL erstellte Programm- paket 'Syrepa·ss• (Autoren : W.Schneeweiss / M~Schulte; siehe Informatik Bericht Nr. 62 der FernUni.) zu nutzen, um eine exakte Berechnung der System-MTTF, Unverfügbarkeit usw. zu erhalten.

Diese Absicht gründete sich auf die Werbeaussage, es sei möglich Objektmodule anderer Programmiersprachen (auch PASCAL) unter TURBO- PROLOG zu binden.

Tatsächlich stellte sich aber heraus, daß dieses mit dem zur Verfügung stehenden TURBO-PASCAL des selben Herstellers gerade nicht durchführbar ist.

In einem kleinen Hinweis am Ende des TURBO-PROLOG Handbuches wird darauf recht "verschämt" hingewiesen ((18]).

An die Stelle exakter Systemwerte mußte daher eine grobe numerische Abschätzung treten. Siehe dazu Abschnitt 3.2.2 1

Bevor nun 'FAULT-EXPERT' im einzelnen zu diskutieren ist, wird das fertige Produkt stichpunktartig vorgestellt.

'FAULT-EXPERT'

- berät bei der Entwicklung fehlertolerierender Rechensysteme;

- ist eine intelligente Checkliste, die Methoden und Konzepte zur Verbesserung der Fehlertoleranz vorschlägt;

- erlaubt es, die Auswirkungen der vorgeschlagenen Maßnahmen abzu- schätzen;

arbeitet im Dialog mit dem Benutzer, ohne die Verwendung einer speziellen Kommandosprache;

- stellt ein Lexikon von Fachbegriffen zur Verfügung.

3. GROBSTRUKTUR VON 'FAULT-EXPERT'

Bei der nun folgenden Diskussion des Expertensystems 'FAULT-EXPERT' ist bewußt darauf verzichtet wo~den, zu sehr ins Detail zu gehen.

Insbesondere spezielle Aspekte der Programmierung (z.B. das Setzen eines 'Cut' an einer bestimmten Stelle) werden nicht bis ins Detail diskutiert, da das einen normalen Umfang dieser Arbeit sprengen würde.

Hier sei der interessierte Leser auf das ausgiebig kommentierte Programmlisting in Abschnitt 4.4 sowie auf seine eigenen PROLOG- Kenntnisse verwiesen.

Vielmehr liegt das Augenmerk darauf, die wesentlichen Aspekte und Besonderheiten des Expertensystems 'FAULT-EXPERT' herauszuarbeiten.

3.1 BEGRIFFSBAUM

Wie schon in der Einleitung erwähnt, ist das Wissensgebiet Fehler- tolerierende Rechensysteme äußerst komplex, unstrukturiert und schwer abgrenzbar.

Ein weiteres Problem entsteht dadurch, daß hier auch numerische Aspekte eine wichtige Rolle spielen; im Gegensatz zu vielen gängigen Experten- systemen, wie zum Beispiel 'MYCIN', bei denen Symbolverarbeitung eindeu- tig überwiegt und die Fakten meist von ähnlicher Qualität sind.

Bei der Frage, wie ein derartiges Wissensgebiet strukturiert darzu- stellen ist, kommt man mit formalen Verfahren schnell an die Grenze des Möglichen ([8) S.42).

Von den grundlegenden Möglichkeiten der Wissensrepräsentation ([5) S.41) scheiden einige wegen zu geringer Flexibilität direkt aus; so zum Bei- spiel Objekt-Attribut-Wert-Tripel oder Frames .•

Die Entscheidung fiel daher auf eine Abart der flexiblen Darstellung in einem semantischen Netz, und zwar auf einen verwickelten Baum ([12)).

In einem verwickelten Baum können zwei verschiedene Väter denselben Sohn haben.

Die Darstellung des Gebietes Fehlertolerierende Rechensysteme wird im sogenannten 'Begriffsbaum' dabei wie folgt vorgenommen:

- Die Knoten sind Begriffe, die Maßnahmen zur Verbesserung der Fehler- toleranz darstellen.

- Die Kanten sind von der Art "ist Oberbegriff von" und drücken daher eine hierarchische Beziehung aus.

Die Regeln zu den Kanten geben an, unter welchen Bedingungen eine Kante durchlaufen werden darf.

-5-

Diese Struktur kann man sehr gut an der Baumwurzel erkennen (s. unten).

Der Oberbegriff ist "Verbesserung der Fehlertoleranz"i

Dieser wird in fünf Unterbegriffe wie "Coderedundanz", "Wartung" usw.

unterteilt, die man auch weiter verfeinern kann.

An den Blättern des Baumes ist somit der höchste Detaillierungsgrad der Begriffe erreicht.

Sie stellen konkrete Handlungsempfehlungen an den Benutzer dar.

Es scheint, daß auf eine derartige Weise auch sehr "sperrige" Wissens- gebiete gut darstellbar sind.

3.1.1 ZUM FERTIGEN BEGRIFFSBAUM

Der fertige Begriffsbaum, wie er nach ausgiebigen Diskussionen und

vielfachen Änderungen entstand, ist auf den folgenden Seiten zu finden.

Dazu noch einige Hinweise:

-Die Flußrichtung auf allen Kanten ist von oben nach unten bzw.

waagerecht.

Auf die Angabe von Pfeilrichtungen wird daher verzichtet.

-Die unterstrichenen Begriffe werden auf einem späteren Blatt weiter verfeinert.

-Erläuterungen zu den Begriffen sind dem Programmtext (File text.dat) in At~chnitt 4.4.2 (Prädikat 'kommentar') zu entnehmen.

1

^Code-

Qua.l i tät

1

^redundanz

J

be=.sere stc:1b i 1 ere Ba.utei l e Mecha.ni k

Verbesserung Fehlertoleranz

Zeit- redLmdanz

bessere f:::limati- sierung

1

^{redundanz Modul-}

J l

^Wartung

^J

bessere Ab·:Sch i r-·- ffiLlng

F'arity-

Code

Fehler- erkennung

Berger- Code

Code- redundanz

Zyklische Codes

Fehler- korrektur

Hamming- Code

BCH-Codes

tliversitäre Zeit-

redundanz

-~-Versionen f='rc.;gra.m-

komplette Wieder- holung

Rec:overy- Bloc:k-

-7-

Zeit- redundanz

1

nicht

~iversitäre Zeitred.

Mehrfach- kop i. r~n

Lm1eru11g

J 1

,1erf ahren

1 1 J

partielle Wieder- hol Ltng

Rcillb-~ck- Verfahren

1-von-2

gleiche Komponen- ten

kalte Reserve

Modul- redundanz

2-von-3

~iversitäre Komponen- ten

heiße Reserve

andere Struktur

(m-von-nl

**) Nicht alle Kombinationsmb9lickeiten werden tatsächlich genutzt.

Personal- einsatz

Dauernde Anwesen- heit

Hersteller Personal

Reparatur- strategien

Notbereit- schaft

Eigenes Personal

-9-

Wartung

Fehler- diagnose

Rekonfi- guration

Bevorra- tung

Notab- schaltung

Ersatz- teile

Transport

Reparatur später

nach Priori- täten

bei Fehler

Reparatur- strategien

Reparatur sofort

1 nach FIFO

Prophy- laktisch

periodi- sche F•rüfLlng

Fremd- diagnose

fremde F'rüfpro- gramme

-11-

Fehler- diagnose

Sy·stem- sel bst- diagnose

Test-- 1;ir21phen

Diagnose bei

Fehler

Selbst- diagnose

eigene F'rüfpr·o- gr·amme

für

einzelne Einheit

F·r i.'i.f-

~;;chc1l tungen

BaLlstei n- ersatz.

Mono- pr·oz essor- system

Reorganisa- tion der Rechenproz.

Rekonfi- guration

Mehr- prozessor- system

gutes Ersatznetz

Last- umver- teilung

Notbetrieb

Mindest- konf i gu.- rat i c:m

Den auf den vorherigen Seiten vorgestellten Begriffsbaum findet man im Programmtext (Abschnitt 4.4.1) bei dem Prädikat 'ueb-ergang' wieder.

Dieses Prädikat im PROLOG-Programm definiert, wann von einem Knoten zu einem anderen übergegangen werden kann und entspricht daher den Kanten des Begriffsbaumes.

-1 3-

3.1.2. ZUM ENTSTEHEN DES BEGRIFFSBAUMES

Natürlich ist es verfehlt zu glauben, daß der vorgestellte Begriffsbaum sofort in dieser Form aus den Diskussionen hervorgegangen ist.

Daher werden nun einige der Probleme aufgezeigt, die während der Strukturierung des Gebietes 'Fehlertolerierende Rechensysteme' ent- standen sind.

Prinzipiell wurde der Baum Top-Down entworfen.

Die Diskussion begann daher mit der Fragestellung, welche grundsätz- lichen Methoden zur Verbesserung der Fehlertoleranz existieren.

Dabei schienen 7 Untergebiete in Frage zu kommen:

- Fehlerdiagnose

- Rekonfiguration/Topologie - Bessere Qualität

- Coderedundanz - Modulredundanz - Zeitredundanz - Wartung.

Später stellte sich dann heraus, daß die Begriffe 'Fehlerdiagnose' und 'Rekonfiguration/Topologie' doch als Unterbegriffe der 'Wartung' zu sehen sind.

Der Begriff 'Wartung' wird also als sehr umfassend interpretiert, nicht nur, wenn menschliche Eingriffe erfolgen.

An dieser Stelle erkennt man eines der Hauptprobleme, das sich bei den Diskussionen herausstellte, nämlich die Frage, inwieweit Hierarchie- beziehungen zwischen den einzelnen Begriffen bestehen.

Immer wieder gab es tiberschneidungen zwischen verschiedenen Begriffen, so zum Beispiel beim Prinzip 'Baustein-Ersatz' im Rahmen der Rekonfigu- ration und dem Prinzip 'bessere Bauteile' als Unterbegriff von 'bessere Qualität'.

Trotzdem müssen beide Begriffe getrennt betrachtet werden.

Zum einen handelt es sich um einen zwangsweisen Austausch des Bauteils, also nicht unbedingt eine Verbesserung.

Zum anderen wird ein intaktes Bauteil freiwillig durch ein Exemplar besserer Qualität ersetzt.

An anderer Stelle führten solche Uberschneidungen auch dazu, daß ver- schiedene Knoten zu einem Knoten zusammenfielen, also Äste des Baumes verschwanden.

So entstand zum Beispiel das Blatt 'Lastumverteilung', welches auch den Begriff des 'Re-Routing' umfaßt.

Ein weiteres, wichtiges Problem lag in der Unterscheidung zwischen hierarchischen und prozeduralen Aspekten.

Wie schon in 3.1 erläutert, sollten die Kanten des Baumes eine hierar- chische Beziehung von der Art Ober/Unterbegriff darstellen.

Diese hierarchische Beziehung impliziert dann indirekt einen Ablauf, da der Benutzer bei der Beratung vom Allgemeinen zum Speziellen geführt werden soll.

Tatsächlich führte diese Unterscheidung zwischen der hierarchischen Struktur und der impliziten Ablauf-Struktur mehrfach dazu, daß fälsch- licherweise Knoten nach rein prozeduralen Gesichtspunkten in den Baum aufgenommen wurden.

So war zunächst vorgesehen, als Sohn des Knoten 'Modulredundanz' einen Knoten 'welches Modul?' vor die weiteren Verzweigungen zu setzen.

Dieser Knoten sollte den Sachverhalt darstellen, daß der Benutzer nach der Wahl von 'Modulredundanz' entscheiden muß, welches Modul er verviel- fachen will.

Wie sich später herausstellte, ist das aber nach Hierarchiegesichts- punkten kein selbständiger Knoten, sondern vielmehr eine Station im Beratungsablauf aus Benutzersicht.

Trotz der beschriebenen Probleme bei der Wissenserarbeitung, ging es aber im allgemeinen recht zügig voran.

Im folgenden seien einige typische Fragestellungen vorgestellt, wie sie während der Konzeptionsphase an den Experten Prof.Dr.Schnee- weiss zu richten waren:

- Gibt es weitere Unterbegriffe zum Knoten •••••• ?

- Von welchen Faktoren hängt die Entscheidung zwischen den beiden Knoten •••••• und •••••• ab?

- Welche konkreten Auswirkungen hat die Durchführung dieser Maßnahme?

- Sind damit alle prinzipiellen Möglichkeiten aufgezählt?

- Unter welchen Bedingungen kommt dieser Ast des Baumes überhaupt nicht in Frage?

Gehärt der Begriff ••••• nicht doch in einen anderen Teil des Baumes?

usw •••.•

Nach der Erarbeitung des Begriffsbaumes, konnten die Kanten des Baumes mit übergangsregeln belegt werden.

Das Ergebnis ist in Abschnitt 4.1.1 zu finden.

Darauf mußten die konkreten Auswirkungen der vorzuschlagenden Maßnahmen spezifiziert werden.

Dazu siehe Abschnitt 3.4 und 4.1.2 •

-15-

3.2 MERRMALE EINES RECHENSYSTEMS

Jedes Rechensystem läßt sich durch eine Reihe von Merkmalen hinsicht- lich Topologiestruktur, Leistung usw. kennzeichnen.

Der dazu entwickelte Ratalog der Merkmale soll nun im folgenden dar- gestellt werden.

Zunächst wird die Topologiestruktur betrachtet.

3.2.1 STRUKTURIERTE DARSTELLUNG VON RECHENSYSTEMEN

FAULT-EXPERT soll bei der Entwicklung jedes Rechensystems beraten können.

Daher mußte eine allgemeine Form der Darstellung gewählt werden, die es erlaubt, Großrechner ebenso wie PC's zu behandeln.

Es läge nahe, den Benutzer die Topologiestruktur seines Rechensystems zeichnen zu lassen und diese dann zu analysieren.

Dazu wären aber komplexe Algorithmen zur Strukturerkennung, Zusammen- hanganalyse usw. nötig gewesen, was aufgrund des zeitlichen Rahmens einer Diplomarbeit nicht mehr möglich war.

Aus diesem Grund wurde die folgende Form der Darstellung gewählt.

Jedes Rechensystem läßt sich mit 3 Grundstrukturen modellieren:

- Funktionseinheiten (aktive Einheiten), in denen Daten verarbeitet werden (z.B. ein Prozessor).

- Speichereinheiten, in denen Daten gespeichert werden (z.B. RAM, Platte).

Datenkanäle, in denen Daten übertragen werden (z.B. ein Bus).

Zur Modellierung eines räumlich getrennten Rechnernetzes könnte man Beispiel wählen:

Funktionseinheiten= Einzelrechner, Speichereinheiten

Datenkanäle

= Speicher der Einzelrechner,

= Datenfernübertragungsleitungen Zur Modellierung eines PC dagegen:

Funktionseinheiten= Rechenwerk, Leitwerk usw., Speichereinheiten = RAM, Floppy usw.,

Datenkanäle = E/A-Leitungen usw ••

usw ••

Am Beginn einer neuen Sitzung wird der Benutzer nach Zahl und Eigen- schaften der 3 Grundstrukturen gefragt.

Auf dieser Basis arbeitet dann FAULT-EXPERT.

zum

3.2.2 LEISTUNGS- UND KOSTENMERKMALE

Nachdem das betrachtete Rechensystem mit den drei Grundstrukturen charakterisiert ist, lassen sich eine Reihe konkreter Merkmale er- mitteln.

Dies sind

pro Funktionseinheit: - Maximale Rechenleistung

- Aktuelle Durchschnittsleistung - MTTF in Stunden

- MTTR in Stunden - UnverfUgbarkeit pro Speichereinheit: - Größe in MegaByte

- MTTF in Stunden - MTTR in Stunden - Unverfügbarkeit

pro Datenkanal: - Maximale übertragungsleistung - Aktuelle Durchschnittsleistung - MTTF in Stunden

- MTTR in Stunden - Unverfügbarkeit

- Leitungslänge in Metern

Dabei braucht man den Benutzer nach der Unverfügbarkeit nicht mehr zu fragen, da sie sich aus MTTF und MTTR berechnen läßt.

Als Merkmale des gesamten Rechensystems kommen in Betracht:

- Anschaffungskosten

- maximale Anschaffungskosten - Unterhaltskosten

- maximale Unterhaltskosten - gewünschte System-MTTF - aktuelle System-MTTF - gewünschte System-MTTR - aktuelle System-MTTR

- aktuelle System-UnverfUgbarkeit - Mindest-Gesamtrechenleistung - aktuelle Gesamtrechenleistung - aktuelle öbertragungsleistung

Zunächst war als Zielvorstellung auch die gewünschte K-Fehler-Toleranz vorgesehen.

Darauf mußte man dann aber doch verzichten, da die notwendigen kombi- natorischen Tests ohne eine explizite Systemtopologie nicht möglich sind.

-17-

Wie schon in Abschnitt 2 erwähnt, sollten die Systemunverfügbarkeit, MTTF und MTTR zunächst mittels 'SYREPA'86' exakt berechnet werden.

Da dieses nicht möglich ist, werden die Werte mittels der folgenden Formeln abgeschätzt:

Us - ! Ui mit Us = System-Unverfügbarkeit, Ui = Unverf. der Komponenten

mit As= System-Fehlerrate, Ai = Fehlerrate der Komponenten Sytem-MTTF = 1/ As

System-MTTR - System-MTTF w Us

Obige Berechnung erfolgt im Programm (Abschnitt 4.4.1) unter dem

Prädikat 'aktuelle_zuverl_situation', wobei die zusätzlichen Faktoren zu System-MTTF und -MTTR zu beachten sind.

Diese spiegeln die Veränderung von System-MTTF und -MTTR durch Fehler- toleranzmaßnahmen wieder.

Dem aufmerksamen Leser wird bei Studium des Programmlistings in 4.4 nicht entgehen, daß Auswirkungen bezüglich MTTF usw. auf einzelne Komponenten des Rechensystems direkt berechnet werden.

Die Fehlerwerte der einzelnen Einheit sind also direkt angepaßt (Prädikat 'neudatenl').

Dagegen werden Auswirkungen auf das Gesamtsystem erst in einem Faktor, z.B. MTTF-Faktor, gespeichert (Prädikat 'neudaten2' ).

Dies scheint auf den ersten Blick unnötig zu sein, ist aber notwendig.

Der Grund dafür liegt in der Art, wie Gesamtwerte - hier die System-

MTTF - berechnet werden, nämlich aus der Vereinigung aller Einzelelemente (Prädikat 'aktuelle_zuverl_situation').

Würde man nun die System-MTTF aufgrund einer Maßnahme direkt verändern und darauf eine einzelne Komponente verbessern, so müßte die System-MTTF neu berechnet werden und die globale Veränderung wäre verloren.

Auch die System-Rechen- bzw. übertragungsleistung wird näherungsweise durch Addition der Subsysteme berechnet.

Dies erfolgt unter dem Prädikat 'aktuelle_leistung' (s. Abschnitt 4.4.1).

3.3 AUSGESTALTUNG DES INFERENZMECHANISMUS

Durch den Einsatz von PROLOG liegt es nahe, einen Inferenzmechanismus nicht explizit zu deklarieren (z.B. ein Resolutionsverfahren), sondern sich der logischen Inferenz ((5) S.1O3) von PROLOG zu bedienen.

Das Motto : "Let PROLOG da ~he werk" ((18)) läßt sich natürlich nur bedingt aufrechterhalten, denn dieser deklarative Programmierstil reicht an vielen Stellen nicht aus, um den gewünschten Ablauf zu realisieren.

Daher müssen auch prozedurale Aspekte berücksichtigt werden, so zum Beispiel beim Setzen des 'Cut' zur Manipulation des Backtracking.

Um den Inferenzmechanismus von FAULT-EXPERT möglichst elegant zu realisieren, wurde eine Mischung aus Rekursion und Backtracking gewählt.

Die Rekursion sorgt für den Aufruf eines Unterbaumes (möglicherweise Blattes); Backtracking sorgt dafür, daß alle Knoten des Begriffsbaumes besucht werden, sofern dies aufgrund von Regeln erlaubt wird.

Dieser Mechanismus ist im Kern durch das Prädikat 'behandle' realisiert.

Beachten Sie bitte die Konstruktion des Prädikats im Programmtext unter Abschnitt 4.4.1 •

Ein Knoten des Baumes wird wie folgt behandelt:

a: Suche eine 'uebergang'-Regel die einen Sohn des Knoten definiert.

Falls diese Regel fehlschlägt sorgt Backtracking dafür, daß eine andere Regel ausprobiert wird.

Falls kein Sohn gefunden werden kann (z.B. Blatt), führt das zu einem Rücksprung in die nächsthöhere Rekursionsebene (= Vater) und wird als Fehlschlagen ·der Ubergangsregel auf höherer Ebene betrachtet, also führt wieder zu Backtracking.

b: Drucke einen Kommentar zum Sohn-Knoten; falls der Sohn Blatt ist, mache einen Verbesserungsvorschlag.

c: Rufe 'behandle' rekursiv für den Sohn-Knoten auf.

Gestartet wird also mit 'behandle(fehlertoleranz)', das heißt behandle die Wurzel des Baumes.

Backtracking und Rekursion sorgen im folgenden dafür, daß dem Benutzer alle Hinweise/Vorschläge gegeben werden, die für ihn von Bedeutung sind.

In der Terminologie des Knowledge Engineering besteht der Inferenz- mechanismus von FAULT-EXPERT also aus:

Logischer Inferenz mit Backward Chaining, Depth-First-Search,

Monotoner Inferenz (als wahr erkannte Fakten bleiben wahr).

-19-

Um den oben informell dargestellten Sachverhalt noch etwas klarer zu machen, sei nun beispielhaft der Ablauf dargestellt, wenn FAULT-EXPERT den Knoten 'diversitäre Zeitredundanz' (s. Abschnitt 3.1.1) erreicht hat.

Dazu wird angenommen, daß aufgrund der Struktur des behandelten Rechen- systems nur die 'N-Versionen-Programmierung' in Frage kommt; außerdem daß der Knoten 'nicht diversitäre Zeitredundanz' noch nicht behandelt wurde:

behandle(div_zeitred)

uebergang(div_zeitred,n_versionen_prgm)

/*Es wird versucht, den Knoten 'N-Versionen-Programmmierung' zu erreichen.*/

komment(n_versionen_prgm)

/*Drucken einer Erläuterung.*/

vorschlag(n_versionen_prgm)

/*Es wird geprüft, ob der Knoten ein Verbesserungsvorschlag, daher ein Blatt ist ! Dies ist hier der Fall. Der Vorschlag wird bear- beitet !*/

behandle(n_versionen_prgm)

/*Rekursiver Aufruf von 'behandle'.*/

uebergang(n_versionen_prgm,???????)

/*Es kann kein Sohn gefunden werden, da der Knoten ein Blatt ist.

Daraus folgt der Rücksprung aus der Rekursion.*/

uebergang(div_zeitred,recovery_block_verfahren)

/*Aufgrund des Backtracking wird ein anderer Sohn von 'diversitäre Zeitredundanz' gesucht. Diese Regel schlägt aber gemäß Annahme fehl.

=> Backtracking => keine weiteren Söhne vorhanden=> Rekursion- rücksprung.*/

uebergang(komplette_wiederholung,nicht_div_zeitred)

/*Aufgrund des Backtracking wird nun der Knoten 'nicht diversitäre Zeitredundanz' untersucht.*/

usw.

Im Zusammenhang mit der Erläuterung des Inferenzmechanismus muß auch noch darauf hingewiesen werden, daß beim Dialog mit dem Benutzer die Entscheidung auf eine gezielte Frageweise fiel.

Fragen an den Benutzer werden also erst dann gestellt, wenn die Ant- worten tatsächlich benötigt werden.

Demgegenüber könnten auch alle Fragen in einem Block gestellt werden, zum Beispiel am Anfang des Beratung.

Die Vorteile der gewählten Lösung liegen aber, wie leicht einsichtig ist, in der höheren Akzeptanz der Fragen durch den Benutzer ((11) S.14).

3.4 DATEN ZU DEN VORSCHLÄGEN VON 'FAULT-EXPERT'

Konkrete Vorschläge zur Verbesserung der Fehlertoleranz, also Blätter des Begriffsbaumes,·werden um das Prädikat 'vorschlag' herum bearbeitet

(s. 4.4.1).

3.4.1 ALLGEMEINER ABLAUF EINES VORSCHLAGES

Der grobe Ablauf eines Vorschlages zur Verbesserung der Fehlertoleranz sieht wie folgt aus:

a: Kurze Erläuterung des Vorschlages.

b: Entscheidung, ob Vorschlag durchgeführt werden soll.

c: Zusätzliche Kosten ermitteln.

d: Test, ob Kosten im vorgegebenen Rahmen liegen.

e: Kosten um zusätzliche Kosten erhöhen.

f: Anpassen der Fehlertoleranz- und Leistungskennwerte

g: Maßnahme in Liste der durchgeführten Maßnahmen eintragen.

Die konkreten Daten zu den einzelnen Maßnahmen hinsichtlich Kosten, Leistung und Fehlertoleranz (s. 4.1.2) sind dabei natürlich nur grobe Richtwerte, wie sie in den diversen Diskussionen erarbeitet wurden.

3.4.2 ZUM ENTSTEHEN DER VORSCHLAGSDATEN

Noch schwieriger als die in Abschnitt 3.1.2 beschriebene Entwicklung des Begriffsbaumes war es, zu den grundsätzlichen Vorschlägen die Aus- wirkungen in konkreten Zahlen anzugeben.

So mußten zu jeder Maßnahme angegeben werden:

- Zusätzlich entstehende Anschaffungskosten.

- Zusätzlich entstehende Unterhaltskosten.

- Auswirkungen auf die (Sub-) System-MTTF.

- Auswirkungen auf die (Sub-) System-MTTR.

- Auswirkungen auf die (Sub-) System-Leistung.

-?1-

Man bekommt eine Ahnung vom ganzen Ausmaß der Unsicherheit, wenn man den Knoten 'Hersteller-Personal' (s. 3.1.1) betrachtet und die

vergleichsweise einfache Frage stellt, wieviel dieses Fachpersonal denn nun pro Monat kostet.

Gänzlich im Ungewissen bewegt man sich aber, wann man nun einen Faktor angeben muß, um den sich die System-MTTF durch Einsatz von Personal des Herstellers verbessert !

Aus diesen tiberlegungen wird klar, daß es sich bei den konkreten Aus- wirkungen trotz aller Sorgfalt nur um grobe Richtwerte handeln kann.

Trotzdem stellt FAULT-EXPERT mit diesen Richtwerten einen erheblichen Fortschritt dar, da der Rechensystementwickler sonst auf seine eigenen Schätzungen angewiesen wäre.

Wie man sieht, existiert hier also der typische Fall, in dem Experten- wissen benötigt wird.

FAULT-EXPERT stellt dies zur Verfügung.

Der Vollständigkeit halber muß darauf hingewiesen werden, daß die Aus- wirkungen nicht alle angegeben werden können.

Teilweise ist es notwendig, den Benutzer noch nach bestimmten Sachver- halten zu befragen.

So zum Beispiel, wenn die Kosten filr ein Ersatzteil angegeben werden sollen.

Für genauere Informationen steht die Tabelle in Abschnitt 4.1.2 zur Verfügung.

3.5 SPEICHERPROBLEME

Im Laufe der Verfeinerung beziehungsweise Erweiterung der verschiedenen Prototypen, kam es schon recht frühzeitig zu Problemen mit dem vor- handenen Speicherplatz.

Trotz der Erweiterung des PC auf 512 KB RAM ließ sich das Programm nicht mehr compilieren.

TURBO-PROLOG belegt über 220 KB, der Source-Code beträgt über 70 KB und die compilierte Fassung hätte dann über 120 KB benötigt, was aufgrund zusätzlicher Belegungen zur Laufzeit nicht mehr möglich war.

Zwar sieht TURBO-PROLOG die Möglichkeit getrennter Compilierung vor, beim Linken beider Teile traten aber immer wieder System-Fehler auf, die TURBO-PROLOG zum "Absturz" brachten (s. dazu auch [7] S.90).

Es scheint mir nicht sinnvoll an dieser Stelle näher auf die möglichen Gründe einzugehen.

Tatsache ist nur, daß TURBO-PROLOG offensichtllich auch in Version 1.1 noch nicht völlig ausgereift ist.

Somit blieb nur die Möglichkeit, Daten auf ein separates File auszu- lagern und bei Bedarf zu lesen.

Dies führt natürlich zu einer Verlangsamung des Dialogs mit FAULT-EXPERT, was aber bei einem derartigen Experimentalsystem nicht übermäßig bedeu- tend ist.

Zur Auslagerung boten sich alle Kommentare, Erläuterungen und Fragetexte an, die vom Expertensystem im Dialog ausgedruckt werden.

Insbesondere das Lexikon der Fehlertoleranz-Fachbegriffe, ist auf dem externen File zu finden.

Die ausgelagerten Daten sind im File 'text.dat' zu finden (s. 4.4.2).

Sollte eine größere Konfiguration zur Verfügung stehen, können die aus- gelagerten Daten einfach wieder in das Hauptprogramm eingefügt werden.

Dazu müssen dann nur noch die File-Befehle unter den Prädikaten 'komment', 'kuerzel' und 'begriff' gestrichen, sowie die Prädikate 'kommentar', 'wart' und 'kurz' neu deklariert werden (s. 4.4.1).

Die beschriebenen Speicherprobleme hatten aber leider auch Auswirkungen auf die Programmierung.

So konnte in vielen Fällen die übersichtlichere, dafür aber speicher- intensivere Lösung nicht gewählt werden.

Ein Beispiel sind dafür die Prädikate 'neudatenl' und 'neudaten2'

(s. 4.4.1).

Beide hätten natürlich zu einem gemeinsamen Prädikat mit 6 Parametern zusammengezogen werden können, da sie ähnliche Aufgaben erfüllen.

Dies hätte aber zur Folge gehabt, daß bei jedem Aufruf des gemeinsamen Prädikates 'neudaten' 6 Parameter anzugeben wären.

Im Schnitt die Hälfte dieser Parameter sind dann aber nur Dummy-Werte, die gar nicht gebraucht werden.

-23-

Aus ähnlichem Grund konnte auch die in Abschnitt 4.1.2 entwickelte, übersichtliche Tabelle aller Vorschlagsdaten so nicht implementiert werden, da in ihr viele Wiederholungen (ähnliche/gleiche Zeilen) vor- kommen.

Diese Wiederholungen mußten aber zugunsten einer Verringerung des Source-Codes ausgenutzt werden.

Es ist natürlich sehr bedauerlich, daß den Prinzipien der Lesbarkeit und übersichtlichkeit aus den genannten Gründen nicht die Aufmerksam- keit zukommen konnte, die ihrer Bedeutung entspräche.

Trotzdem ist FAULT-EXPERT in den gesteckten Grenzen so strukturiert und übersichtlich wie möglich programmiert ([1]).

Zusammen mit den Kommentaren im Programmtext (s. 4.4.1) sollte der der Aufbau des PROLOG-Programmes gut nachzuvollziehen sein.

3.6 GESAMTSTRUKTUR VON 'FAULT-EXPERT'

Nachdem die wichtigsten Elemente von FAULT-EXPERT allgemein erläutert wurden, kann man nun die Gesamtstruktur des Expertensystems betrachten.

Dabei sind vier prinzipielle Strukturen zu unterscheiden:

Die Steuerung des Expertensystems, insbesondere auch das Benutzer- menü.

Die Regelbasis, wie sie im wesentlichen durch das Prädikat 'uebergang' realisiert ist.

Die konkreten Verbesserungsvorschläge samt ihrer Auswirkungen, die um das Prädikat 'vorschlag' gruppiert sind.

Externe Daten.

Zum einen das File der Texte und Kommentare 'text.dat', zum ande- ren die dynamisch erstellte Datenbank der Daten des untersuchten Rechensystems.

Diese Aufteilung ist natürlich eine Vereinfachung der tatsächlichen Situation.

So gibt es durchaus Prädikate im PROLOG-Programm, die nicht eindeutig einer der vier Strukturen zuzuordnen sind.

Trotzdem gibt diese Vierteilung den globalen Aufbau von FAULT-EXPERT korrekt wieder.

Auf der folgenden Seite ist die Aufruf- und Datenfluß-Struktur in einem Diagramm dargestellt.

-25-

Auf t··uf Datenfluß

Steuerung Benutzermenü

\J

übergangsregeln

1

^~ <Begriffsgraph)

4 1

\/ ^{\ /}

File Datenbank

Kommentare System-

Te:-:te daten

\ /

1, 1 / \

1

^~ \/orschläge

+ -

-

Auswirkungen

^-

3.7 SITZUNGSABLAUF

Nun soll der allgemeine Ablauf einer Sitzung mit FAULT-EXPERT dargestellt werden:

a: Die Dateien 'fexpert.exe', 'fexpert.map' und 'text.dat' müssen auf einem Speichermedium vorhanden sein.

b: Start von FAULT-EXPERT unter MS-DOS durch Aufruf von 'fexpert'.

c: Auf dem Bildschirm erscheinen die beiden Fenster 'Info' und 'Dialog' sowie eine Begrüßung.

d: Danach muß das zu untersuchende Rechensystem, wie in Abschnitt 3.2 erläutert, charakterisiert werden.

Ist der Benutzer sich über erfragte Daten (z.B. Speicher-MTTF) selber nicht im klaren, so kann er durch einfaches Drücken der 'Return'-Taste vordefinierte Default-Werte abrufen (s. 4.1.3).

e: Darauf werden die Wünsche des Benutzers hinsichtlich Fehlertoleranz und Leistung abgefragt.

f: Statt der vollständigen Charakterisierung eines neuen Rechensystems können auch die alten Daten eines schon vorher bearbeiteten Rechen- systems geladen werden.

g: Nach Eingabe der Daten beginnt der eigentliche Dialog, in dem der Benutzer zu allen für ihn in Frage kommenden Fehlertoleranzmaßnahmen geführt wird.

h: Der Benutzer kann den Ablauf durch ein separates Menüfenster beein- flussen, aus dem er eine Funktion auswählen kann.

Zur Wahl stehen:

- 'Weitermachen'

(Im normalen Ablauf weiter fortfahren.) - 'Rücksprung'

(Kommen die behandelten Maßnahmen für den Benutzer von vornherein nicht in Frage, oder will er sie nicht weiter verfolgen, kann mit

'Rücksprung' der gerade behandelte Ast des Baumes vorzeitig ver- lassen und zum Nächsten übergegangen werden.)

- 'Kostensituation'

(Anzeigen der aktuellen Kosten im 'Info'-Fenster.) - 'Fehlersituation'

(Anzeigen der aktuellen Fehlertoleranzwerte im 'Info'-Fenster.)

-27-

- 'Systemleistung'

(Anzeigen der aktuellen Leistungskennwerte im 'Info-Fenster'.) - 'Maßn~h~en'

(Auflisten aller bisher durchgeführten Maßnahmen.) - 'Lexikon'

(Aufruf der Lexikon-Datenbank.

Mit ihr kann sich der Benutzer Fachbegriffe der Fehlertoleranz erläutern lassen.)

i: Am Ende der Sitzung werden automatisch alle durchgeführten Maßnahmen aufgelistet.

Außerdem wird darauf hingewiesen, wenn die gewünschten Fehlertole- ranzwerte trotz der Verbesserungen noch nicht erreicht werden konntsn.

über die Dauer einer Sitzung läßt sich pauschal keine Aussage machen.

Sie hängt sehr stark von Art und Größe des untersuchten Rechensystems, sowie von den Kenntnissen des Benutzers ab.

Die meisten Beratungen werden sich allerdings in der Größenordnung von etwa 30 Minuten abspielen.

Auf den folgenden drei Seiten sind typische Momentaufnahmen einer Sitzung mit FAULT-EXPERT dargestellt.

r-

^INFCI

~ - - - D I A L . D G - - - ~ Im folgenden werden die Systemeigenschaften erfragt.

Dabei wird ihr Rechensystem mit 3 Strukturen modelliert:

Funktionseinheiten <z.B. Prozessoren), Speicher (auch Peripherie) und Koppelelemente <Kommunikationseinheiten).

Wieviel Funktionseinheiten gibt e s ? 1

Bitte geben Sie nun die Daten der 1. Fktseinheit ein:

Maximale Leistung in MIPS? 2.3

Derzeitige Durchschnittsleistung in MIPS?

Es wurde ein Default-Wert von 0.1 MIPS angenommen.

MTTF in Stunden ⁰ 1.4 MTTR in Stunden ⁰

Es wurde ein Default-Wert von 1 Stunde angenommen.

Wieviel Speicher gibt e s ?

(Default möglich)

N O>

1

. - - - I N F O - - - ~

############# Momentane Kostensituation##############

Anschaffungskosten:

Unterhaltskosten

2000.00 Maximum:

100.00 Maximum:

4000.00 200.00

, - - - D I A L O G - - - - Zeitredundanz erlaubt eine Verbesserung der Fehlertoleranz.

Sie bezieht sich im wesentlichen auf Software und bedeutet zusätzliche Zeit für eine oder mehrere Wiederholungen.

Sind die Prozesse relativ lang?

<>

1 Std.) (j oder n) n

Weiter-machen Rücksprung Kostensituation Fehlersituation Systemleistung Maßnahmen

Lexikon

Handelt es sich bei den erwarteten Fehlern um E n t w u r f s f e h l e r ~ - - - ~ ( j oder n) j

Der fehlerhafte Vorgang sollte jeweils komplett wiederholt werden.

Die Zeitredundanz soll diversitär realisiert werden.

I'.)

'-0 1

also die mittlere fehlerfreie Zeit.

~ - - - D I A L O G - - - - Wieviel DM macht das aus~ 500

Wieviel DM macht das aus? 6

**********

Liste der schon beschlossenen Maßnahmen 1. Funktionseinheit verbessert durch

diversitäre 2-von-3 Redundanz mit heißer Reserve 1. Speicher verbessert durch

nicht-diversitäre 1-von-2 Redundanz mit kalter Reserve

Auch Wartung ist ein wichtiger Aspekt bei der Verbesserung der Fehlertoleranz von Rechensystemen.

Der Begriff wird hier sehr umfassend interpretiert, nicht nur in Bezug auf menschliche Wartung von außen.

Weitermachen Rücksprung Kostensituation Fehlersituation Systemleistung Maßnahmen

Lexikon

'-->I

0 1

- 31-

4. FEINSTRUKTUR VON 'FAULT_EXPERT'

In den nun folgenden Unterpunkten wird das Expertensystem FAULT-EXPERT auch im Detail erläutert.

Kern dieses Abschnitts ist dann das kommentierte Programmlisting unter Punkt 4.4 •

4.1 ZUSAMMENSTELLUNG DER DATEN, REGELN UND VORSCHLÄGE

4.1.1 ALLE üBERGANGSREGELN

Zunächst sollen die übergangsregeln, also die Basis von FAULT-EXPERT, umgangssprachlich dargestellt werden.

Dies erlaubt es auch dem in Prolog weniger versierten Leser, die übergangsregeln zu untersuchen.

Die sich anschließende Liste wurde aus den Ergebnissen der Diskussionen mit Prof.Dr. Schneeweiss, sowie teilweise aus dem Studium von

(14),(15],(16] und (17] erarbeitet.

Die Fassung dieser Liste in PROLOG, ist unter dem Prädikat 'uebergang' im Programmlisting zu finden.

Um Eindeutigkeit zu gewährleisten, wurde eine halbformale Art der Darstellung gewählt.

Und zwar bezeichnet '->' den übergang Uber eine Kante des Begriffs- baumes.

Außerdem sind 'UND', 'ODER', ' ( ' , ' ) ' , 'IMMER' sowie 'WENN' jeweils logisch zu interpretieren.

(Die folgenden umgangssprachlichen Begriffe wie 'maximal' oder 'zu groß', sind in FAULT-EXPERT zum Teil mit konkreten Daten/Werten verknüpft]

Fehlertoleranz-> bessere Qualität WENN

Spielraum für Anschaffungskosten genügend groß.

bessere Qualität-> bessere Bauteile WENN

Funktionseinheiten nahe maximaler Leistung sind Funktionseinheiten geringe MTTF haben

Datenkanäle nahe maximaler Leistung sind

Datenkanäle geringe MTTF bei kurzer Länge haben Funktionseinheiten unterdurchschnittliche Leistung Datenkanäle unterdurchschnittliche Leistung haben.

ODER ODER ODER ODER haben ODER

bessere Qualität-> stabilere Mechanik IMMER.

bessere Qualität-> bessere Klimatisierung IMMER.

bessere Qualität-> bessere Abschirmung IMMER.

Fehlertoleranz-> Coderedundanz WENN

(Spielraum für Unterhaltskosten genügend groß UND

Speichereinheiten relativ groß sind ODER (Spielraum für Unterhaltskosten genügend groß UND

Speicher-MTTF gering ODER

(Spielraum für Unterhaltskosten genügend groß UND Datenkanäle geringe MTTF bei großer Länge haben ).

Coderedundanz-> Fehlererkennung WENN

es sich um Peripheriespeicher handelt ODER Erkennung dem Benutzer ausreicht.

Coderedundanz-> Fehlerkorrektur WENN (es sich um Datenkanäle handelt UND

Erkennung nicht ausreicht ) ODER

(es sich nicht um Peripheriespeicher handelt UND

Erkennung nicht ausreicht ).

Fehlererkennung-> Parity-Code WENN 1-Bit-Fehler erkannt werden sollen.

Fehlererkennung-> Berger-Code WENN

unidirektionale Fehler erkannt werden sollen.

Fehlererkennung-> Zyklische Codes WENN es sich um Datenkanäle handelt UND

diese dem Datenverkehr zwischen Peripherie und Zentraleinheit dienen UND Bündelfehler erkannt werden sollen.

Fehlerkorrektur-> Hamming-Code WENN

noch keine BCH-Codes angewandt wurden UND 1-Bit-Fehler korrigiert werden sollen.

Fehlerkorrektur-> BCH-Codes es sich um Datenkanäle handelt

WENN UND

noch kein Hamming-Code angewandt wurde UND Mehr-Bit-Fehler korrigiert werden sollen.

Fehlertoleranz-> Zeitredundanz WENN

Funktionseinheiten mit großen Leistungsreserven existieren.

Zeitredundanz-> komplette Wiederholung WENN

(es sich nicht um relativ lange Prozesse handelt UND

es sich bei den erwarteten Fehlern um Entwurfsfehler handelt) es sich um relativ kurze Prozesse handelt.

ODER

-33-

Zeitredundanz-> partielle Wiederholung WENN es sich um relativ lange Prozesse handelt

(es sich nicht um relativ kurze Prozesse handelt hauptsächlich sporadische Fehler erwartet werden

ODER UND

)

.

komplette Wiederholung-> diversitäre Zeitredundanz WENN es sich bei den erwarteten Fehlern um Entwurfsfehler handelt Spielraum für Anschaffungskosten genügend groß.

komplette Wiederholung-> nicht diversitäre Zeitredundanz WENN ODER

noch keine Maßnahme diversitärer Zeitred. durchgeführt wurde UND es sich nicht um Entwurfsfehler handelt.

nicht diversitäre Zeitredundanz-> Mehrfachkopien IMMER.

WENN wird UND diversitäre Zeitredundanz-> N-Versionen Programmierung

(die Mindest-Gesamtrechenleistung nicht unterschritten die Geschwindigkeit des Rechensystems nicht besonders (die Mindest-Gesamtrechenleistung nicht unterschritten

genaue Ergebniskontrolle nötig ist

wichtig ist) ODER wird UND

diversitäre Zeitredundanz-> Recovery-Block-Verfahren N-Versionen Programmierung noch nicht angewandt wurde die Mindest-Gesamtrechenleistung nicht unterschritten genaue Ergebniskontrolle nicht nötig ist.

partielle Wiederholung-> Rollback WENN

WENN UND

wird UND

die Mindest-Gesamtrechenleistung nicht unterschritten wird.

Fehlertoleranz-> Modulredundanz WENN

(Spielraum für Anschaffungskosten genügend groß UND Spielraum für Unte~haltskosten genügend groß UND keine starke Systemvernetzung vorliegt UND

Speichereinheiten relativ klein sind

(Spielraum für Anschaffungskosten genügend groß UND Spielraum für Unterhaltskosten genügend groß UND keine starke Systemvernetzung vorliegt UND

Funktionseinheiten geringe MTTF haben

ODER

)

.

)

.

Modulredundanz-> 1-von-2 mit gleichen Komponenten in kalter Reserve es sich im wesentlichen um Peripherie-Funktionseinheiten handelt es sich im wesentlichen um Peripherie-Speicher handelt.

Modulredundanz-> 1-von-2 mit gleichen Komponenten in heißer Reserve auf die behandelten Module noch keine Modulredundanz angewandt wurde Maskierung der Fehler nicht nötig ist UND

nicht mit Common-Mode Fehlern gerechnet werden muß UND die Fehlerfolgekosten nicht sehr hoch sind UND

es sich bei den erwarteten Fehlern nicht um Entwurfsfehler handelt.

WENN ODER

WENN UND

Modulredundanz-> 1-von-2 mit diversitären Komponenten in heißer Res.

auf die behandelten Module noch keine Modulredundanz angewandt wurde Maskierung der Fehler nicht nötig ist UND

keine sehr große Fehlerwahrscheinlichkeit vorliegt.

Modulredundanz-> 2-von-3 mit gleichen Komponenten in heißer Reserve auf die behandelten Module noch keine Modulredundanz angewandt wurde Maskierung der Fehler nötig ist UND

nicht mit Common-Mode Fehlern gerechnet werden muß UND die Fehlerfolgekosten nicht sehr hoch sind UND

es sich bei den erwarteten Fehlern nicht um Eritwurfsfehler handelt.

Modulredundanz-> 2-von-3 mit diversitären Komponenten in heißer Res.

auf die behandelten Module noch keine Modulredundanz angewandt wurde Maskierung der Fehler nötig ist UND

keine sehr große Fehlerwahrscheinlichkeit vorliegt.

Modulredundanz-> andere Struktur WENN

auf die behandelten Module noch keine Modulredundanz angewandt wurde eine sehr große Fehlerwahrscheinlichkeit vorliegt.

Fehlertoleranz-> Wartung WENN

Spielraum für Unterhaltskosten genügend groß.

Wartung-> Notabschaltung WENN

gefährliche Prozesse vom Rechensystem gesteuert werden.

Wartung-> Ersatzteile IMMER.

Ersatzteile-> Bevorratung IMMER.

Ersatzteile-> Transport IMMER.

Wartung-> Personaleinsatz WENN

das Rechensystem zu groß ist, um es zu verschicken.

Personaleinsatz-> dauernd anwesendes Hersteller-Personal es sich um ein wichtiges Rechensystem handelt UND

eigenes Personal zur Wartung nicht ausreicht.

Personaleinsatz-> dauernd anwesendes eigenes Personal es sich um ein wichtiges Rechensystem handelt UND eigenes Personal zur Wartung ausreicht.

Personaleinsatz-> Hersteller-Personal in Notbereitschaft es sich nicht um ein wichtiges Rechensystem handelt UND eigenes Personal zur Wartung nicht ausreicht.

Personaleinsatz -> eigenes Personal in Notbereitschaft es sich nicht um ein wichtiges Rechensystem handelt UND eigenes Personal zur Wartung ausreicht.

WENN UND

WENN UND

WENN UND

UND

-35-

Wartung-> Reparaturstrategien IMMER.

Reparaturstrategien-> Prophylaktische Reparatur WENN die Lebensdauer der Systemkomponenten wenig streut.

Reparaturstrategien-> Reparatur bei Fehler WENN

die Lebensdauer der Systemkomponenten nicht wenig streut.

Reparatur bei Fehler-> Reparatur später nach Prioritäten WENN

Das Gesamtsystem genügend Redundanz zur geforderten Leistung besitzt UND Einige Bauteile des Rechensystems besonders wichtig sind.

Reparatur bei Fehler-> Reparatur später nach FIFO WENN

Das Gesamtsystem genügend Redundanz zur geforderten Leistung besitzt UND Keine Bauteile des Rechensystems besonders wichtig sind.

Reparatur bei Fehler-> Reparatur sofort nach Prioritäten WENN

Dem Gesamtsystem genügend Redundanz zur geforderten Leistung fehlt UND Einige Bauteile des Rechensystems besonders wichtig sind.

Reparatur bei Fehler-> Reparatur sofort nach FIFO WENN

Dem Gesamtsystem genügend Redundanz zur geforderten Leistung fehlt UND Keine Bauteile des Rechensystems besonders wichtig sind.

Wartung-> Fehlerdiagnose IMMER.

Fehlerdiagnose-> Periodische Prüfung WENN

gefährliche Prozesse vom Rechensystem gesteuert werden.

Fehlerdiagnose-> Diagnose bei Fehler WENN

keine gefährlichen Prozesse vom Rechensystem gesteuert werden.

Periodische Prüfung-> Fremddiagnose WENN

es sich um ein Mehrprozessor-System handelt UND das Kommunikationsnetz nicht stark belastet ist.

Periodische Prüfung-> Selbstdiagnose IMMER.

Diagnose bei Fehler-> Fremddiagnose WENN

es sich um ein Mehrprozessor-System handelt UND das Kommunikationsnetz nicht stark belastet ist.

Diagnose bei Fehler-> Selbstdiagnose IMMER.

Selbstdiagnose-> Systemselbstdiagnose WENN es sich um ein Mehrprozessor-System handelt UND das Kommunikationsnetz nicht stark belastet ist.

Selbstdiagnose-> für einzelne Einheit IMMER.

Systemselbstdiagnose-> Testgraphen IMMER.

Fremddiagnose-> fremde Prüfprogramme WENN

die Mindest-Gesamtrechenleistung nicht unterschritten wird UND Funktionseinheiten mit großen Leistungsreserven existieren.

für einzelne Einheit-> eigene Prüfprogramme WENN

die Mindest-Gesamtrechenleistung nicht unterschritten wird UND Funktionseinheiten mit großen Leistungsreserven existieren UND eine flexiblere, dafür aber langsamere Diagnose gewünscht wird.

für einzelne Einheit-> Prüfschaltungen WENN

die Mindest-Gesamtrechenleistung nicht unterschritten wird UND noch keine Prüfprogramme angewandt wurden.

Wartung-> Rekonfiguration IMMER.

Rekonfiguration -> Monoprozessorsystem IMMER.

Rekonfiguration -> Mehrprozessorsystem WENN es sich um ein Mehrprozessor-System handelt.

Monoprozessorsystem -> Baustein-Ersatz WENN

die auszutauschenden Teile nicht besonders teuer sind UND keine extreme System-MTTF oder MTTR vorliegt.

Monoprozessorsystem -> Reorganisation der Rechenprozesse WENN die auszutauschenden Teile besonders teuer sind ODER

eine extreme System-MTTF oder MTTR vorliegt.

Mehrprozessorsystem-> gutes Ersatznetz WENN

Spielraum für Anschaffungskosten genügend groß UND es sich nicht um ein wichtiges Rechensystem handelt UND eine starke Systemvernetzung vorliegt.

Mehrprozessorsystem-> Notbetiieb WENN Spielraum für Anschaffungskosten sehr klein es sich um ein wichtiges Rechensystem handelt keine starke Systemvernetzung vorliegt.

Notbetrieb-> Mindestkonfiguration IMMER.

gutes Ersatznetz-> Lastumverteilung IMMER.

ODER ODER

Im Zusammenhang mit den öbergangsregeln muß noch erwähnt werden, daß darauf verzichtet wurde, Konfidenzfaktoren ([SJ S.57 f.) zur Darstellung ungewisser Regeln zu verwenden.

Dies liegt daran, daß die Wahrheitswerte der Regel-Prämissen dem Benutzer oder FAULT-EXPERT bekannt sind.

Wo dies nicht der Fall ist, nimmt FAULT-EXPERT Default-Werte an (z.B.

im Prädikat 'alle_elemente') und stellt somit wieder Sicherheit her.

-37-

4.1.2 ALLE VORSCHLAGSDATEN

Die Kosten beziehungsweise Auswirkungen jedes Verbesserungsvorschlages von FAULT-EXPERT finden sich im Programmtext (Abschnitt 4.4) unter den Prädikaten 'Vorschlagl' und 'neue_daten'.

Im Anschluß sollen diese Daten, in einer Tabelle gesammelt, angegeben werden.

Steht an einer Stelle der Tabelle keine Angabe, dann sind diese Daten nicht bekannt und werden vom Benutzer während der Beratung erfragt.

Aus Platzgründen sind im Kopf der Tabelle nur Abkürzungen angegeben.

Diese bedeuten:

'Vorschlag' = Kürzel des Verbesserungsvorschlages.

'Bezug'

'Komm'

'A-Kos'

'A-Fak'

'U-Kos'

'U-Fak'

'MTTF-F'

'MTTR-F'

'Lstg-F'

= Gibt an auf welche Teile des Rechensystems sich der Vorschlag bezieht. Dabei stehen zur Auswahl:

fkt - Funktionseinheiten, speich - Speicher,

kanal - Datenkanäle, system - Gesamtsystem.

= Die Kommentar-Spalte legt fest, welchen Kommentar der Benutzer zu den zusätzlichen Kosten der vorgeschlagenen Maßnahme erhält.

Den dazugehörigen Text kann man im Text-File 'text.dat' unter dem Symbol finden, das in der Tabelle angegeben ist.

(z.B. k8 in Tabelle--> kommentar(k8," •••••• ") in File 'text.dat', siehe Abschnitt 4.4 .)

= Zusätzliche Anschaffungskosten durch den Vorschlag, wie sie im Kommentar spezifiziert sind (in DM).

= Faktor, mit dem 'AKos' zu multiplizieren ist, um die

tatsächlichen zusätzlichen Anschaffungskosten zu erhalten

(<>

1 zum Beispiel beim 2-von-3-Prinzip).

= Zusätzliche Unterhaltskosten durch den Vorschlag, wie sie im Kommentar spezifiziert sind (in DM).

= Faktor, mit dem 'UKos' zu multiplizieren ist, um die tatsächlichen zusätzlichen Unterhaltskosten zu erhalten

(<>

1 zum Beispiel beim 2-von-3-Prinzip).

= Faktor, mit dem die MTTF des behandelten Teils (Bezug) zu multiplizieren ist.

= Faktor, mit dem die MTTR des behandelten Teils (Bezug) zu multiplizieren ist.

= Faktor, mit dem die System-Rechenleistung zu multiplizieren ist.

Wird in einer Kostenspalte eine Prozentangabe gemacht (z.B. S%), so bezieht sich diese immer auf die Anschaffungskosten des Gesamtsystems zu Beginn der Beratung.

Vorschlag Bezug Komm A-Kos A-Fak U-Kos U-Fak MTTF-F MTTR-F Lstg-F

=========================================================================

Parity-Code kanal kl 0 1 0 1 1 0.28 1

Parity-Code speich k2 1 0 1 1 0.28 1

Zyklische Codes kanal k3 0 1 0 1 1 0. 19 1

Berger-Code kanal k4 1 0 1 1 0.1 1

Berger-Code speich k5 1 0 1 1 0. 1 1

Hamming-Code kanal k6 0 1 0 1 5 1 1

Hamming-Code speich k7 1 0 1 5 1 1

BCH-Codes kanal k8 10% 1 0 1 20 1 1

stabilere system k9 1 0 1 1 0.5 1

Mechanik

bessere Bauteile fkt k9 1 0 1 1

bessere Bauteile kanal k9 1 0 1 1

bessere

Klimatisierung system k9 1 10 1 1 1

bessere

Abschirmung system k9 1 0 1 1.5 1 1

1-von-2 mit fkt klO 1 0 1 10 0.01 1

gleichen Kamp.

in kalter Res.

1-von-2 mit speich k 1 ') 1 0 1 10 0.01 1

gleichen Kamp.

in kalter Res.

1-von-2 mit fkt kl 1 1 1 10 0.5 1

gleichen Komp.

in heißer Res.

1-von-2 mit speich kll 1 1 10 0.5 1

gleichen Kamp.

in heißer Res.

1-von-2 mit fkt k 11 1 1 20 0.5 1

diversit. Kamp.

in heißer Res.

1-von-2 mit speich kll 1 1 20

o.s

1

diversit. Kamp.

in heißer Res.

-39-

Vorschlag Bezug Komm A-Kos A-Fak U-Kos U-Fak MTTF-F MTTR-F Lstg-F

================================--======-========-=======-===============

2-von-3 mit fkt kll 2 2 8 o.s 1

gleichen Kamp.

in heißer Res.

2-von-3 mit speich kll 2 2 8 o.s 1

gleichen Kamp.

in heißer Res.

2-von-3 mit fkt k11 2 2 16 o.s 1

diversit. Kamp.

in heißer Res.

2-von-3 mit speich kl 1 2 2 16 o.s 1·

diversit. Kamp.

in heißer Res.

Andere Struktur fkt k11 3 3 40 0.2s 1

(m-von-n)

Andere Struktur speich k11 3 3 40 0.2s 1

(m-von-n)

Mehrfachkopien fkt k6 0 1 0 1 1 0.1 1

Recovery-Block- fkt k12 2 0 1 2 1 0.9

Verfahren

N-Versionen- fkt k12 2 0 1 10 1 0.3

Prgm.

Rollback fkt k6 0 1 0 1 s 1 0.7

Notabschaltung system k6 0 1 0 1 1 1 1

Bevorratung system k13 0 1 5% 1 1 0.2 1

Transport system k13 0 1 5% 1 1 0.2 1

Hersteller-Pers. system k14 0 1 5000 1 1 0.2 1 dauernd anwesend

Hersteller-Pers. system k14 0 1 200 1 1 o.s 1 notbereitschaft

Eigenes Pers. system k14 0 1 3000 1 1 0.33 1 dauernd anwesend

Eigenes Pe!:"s. system k6 0 1 0 1 1 1 1 notbereitschaft

Vorschlag Bezug Komm 1'-Kos 1'-Fak U-Kos U-Fak MTTF-F MTTR-F Lstg-F

==============================-~--==--=---======--==--===--=========-====

Prophylaktische system k6 0 1 0 1 5 1 1

Reparatur

Spätere Rep. system k15 0 1 0.5 0.77 1. 15 1 nach Prioritäten

Spätere Rep. system k15 0 1 0.5 0.77 1.5 1 nach FIFO

Sofortige Rep. system k6 0 1 0 1 1 0.77 1 nach Prioritäten

Sofortige Rep. system k6 0 1 0 1 1 1 1

nach FIFO

Fremde Prüfprgm. system k16 5% 1 0 1 2 0.5 0.95 Eigene PrUfprgm. system k16 5% 1 0 1 2 0.5 0.95 Prüfschaltungen system k16 5% 1 0 1 2 0.5 0.95

Testgraphen system k16 5% 1 0 1 1 1 1

Baustein-Ersatz system k17 0 1 1 1 1 1

Reorganisation system k10 5% 1 0 1 5 1 1

der Rechenproz.

Mindestkonfi- system k6 0 1 0 1 1 1

guration

Lastumverteilung system k16 5% 1 0 1 5 1 1

-41-

4.1.3 DEFAULT-WERTE

In den vorherigen Abschnitten wurde schon verschiedentlich erwähnt, daß der Benutzer die Möglichkeit hat, bei der Eingabe vordefinierte Default- werte zu verwenden.

Diese werden nun aufgezählt:

Für Funktionseinheiten:

- Maximale Rechenleistung= 1 MIPS

- Aktuelle Durchschnittsleistung= 0.1 MIPS - MTTF = 4000 Stunden

- MTTR = 1 Stunde

Für Speichereinheiten:

- Größe= 1 MegaByte - MTTF = 1000 Stunden - MTTR = 0.S Stunden

Für Datenkanäle:

- Maximale übertragungsleistung = 1 MegaBit pro Sek.

- Aktuelle übertragungsleistung = 0.2 MegaBit pro Sek.

- MTTF = 100 Stunden - MTTR = 1 Stunde

- Leitungslänge = 10 Meter

Im Programmtext in Abschnitt 4.4.1 sind diese Default-Werte beim Prädikat 'alle_elemente' zu finden.