Achtung : Skript gibt den mündlichen Vortrag nur teilweise wieder !!!
                        

1. Einführung

Bislang wurden im Bereich von Realzeitsystemen nur Tasks unterschieden, die aufgrund von Stimulusereignissen auf Ressourcen zugreifen und Responseereignisse erzeugen (vgl. Bild).

Figure: Basic Layout of Realtime Systems

In dieser Vorlesung soll verdeutlicht werden, dass Realzeitsysteme im Einsatz eine komplexere innere Architektur aufweisen und wie diese im Zusammenhang mit der Eigenschaft der Zuverlässigkeit (engl.: Reliability) steht.

START

2. Fault Tolerant Units (FTUs)

Für die weiteren Überlegungen ist es notwendig eine mögliche Komplexitätshierarchie innerhalb von Realzeitsystemen anzunehmen. Wir folgen hier  dem Buch von [Kopetz 1997:Chapt.4].

Kopetz nimmt an, dass ein Realzeitsystem aus einem Cluster von Fault Toleran Units (FTUs) besteht. Eine FTU wiederum kann aus mehreren Nodes bestehen, die als Smallest Replacable Units (SRUs) gelten, also als kleinste ersetzbare Einheiten. Wenn ein Node in einer FTU ausfällt, dann könnte dieser sofort von einer anderen Node ersetzt werden. Ein Node wiederum besteht aus Tasks, die als kleinste funktionale Einheiten einer Node angesehen werden.

Auch wenn ein Task als kleinste funktionelle Einheit in einer Node gilt, so kann man hier doch noch eine wichtige Unterscheidung machen, nämlich die zwischen 'einfachen' und 'komplexen' Tasks.

Ein einfacher ('simple') Task ('S-Task') ist ein Prozess, der --wird er einmal gestartet-- auf keinen anderen Task mehr warten muss; ein einfacher Task verfügt über  alle Ressourcen, die er zur Erfüllung seiner Aufgabe benötigt. So gesehen ist er 'autonom'.

Demgegenüber zeichnet sich ein komplexer ('complex') Task ('C-Task') dadurch aus, dass er mindestens an einer Stelle die Ergebnisse eines anderen Tasks benötigt, d.h. er muss warten ('wait'-statement), bis der andere Task ihm diese Ergebnisse liefert.

Nennt man die Zeit, die ein Task a benötigt, um seine Aktion auszuführen,

(mit x := Input Daten von a, z := Kontrollsignal für a, s := interne Zustände von a), dann ist diese Zeit im Falle eines einfachen S-Tasks wohldefiniert, im Falle eines komplexen C-Tasks muss dies nicht der Fall sein. Wie später deutlich wird, kann das Auftreten von C-Tasks zu NP-harten Problemen führen.

Von der Eigenschaft der Synchronisation zu unterscheiden ist die Eigenschaft der Präemption. Präemption liegt vor, wenn ein Task --auch ein S-Task!-- aufgrund eines Interrupts unterbrochen werden muss.

START

3. Verknüpfte Systeme

Um die nachfolgend benötigten Begriffe einführen zu können, muss an dieser Stelle der Systembegriff aus der vorausgehenden Vorlesung  erweitert werden. Wir unterscheiden nun zwischen atomaren Systemen (ASYS) und Systemen, die komplex sein können (complex systems) (CSYS). Komplexe Systeme entstehen dadurch, dass man gegebene Systeme  sequentiell oder parallel schaltet oder beliebige Kombinationen von sequentiellen und parallelen Verbindungen bildet (vgl. nächstes Bild).

Bild: Bild eines Komplexen Systems

Auf formaler Ebene benötigt man für diese Darstellung den Begriff des komplexen Systems. Um diesen definieren zu können, benötigt man die Operationen AND  und OR bezogen auf Systeme. Dies bedeutet, man muss von einer Menge von Systemen SYS ausgehen, die innerhalb einer Umgebung E (environment) als Objekte (O) auftreten können.

Bezogen auf die Menge SYS der Systeme innerhalb der Umgebung E müssen jetzt die Operationen AND und OR definiert werden.

Bei Systemen, die durch die Operation AND() verknüpft werden, ist der Output von A der Input von B.

Bei Systemen, die durch die Operation OR() verknüpft werden, ist der Output des Gesamtsystems entweder der Output  von A oder  von B oder von beiden.

Mithilfe der Operationen AND() und OR() kann man jetzt nach Einführung der Menge der atomaren Systeme  induktiv die Menge der komplexen Systeme definieren.

Ausgehend von der Basismenge der atomaren Systeme ASYS kann man jetzt induktiv eine komplexe Obermenge SYS definieren:

START

4. WCAO := Worst Case Administrative Overhead

Zuvor wurde herausgestellt, wie vorteilhaft ereignisgetriebene Systeme gegenüber zeitgetriebenen Systeme sein können, wenn es darum geht, schnell und flexibel auf unerwartete Ereignisse zu reagieren. Allerdings darf nicht übersehen werden, dass die Unterbrechung eines laufenden Task a gefolgt von dem Umschalten ('switching') auf einen neuen Task b auch minimale Zeit benötigt, und zwar administrative Zeit, die zusätzlich ('overhead') zur normalen Task-Ausführungszeit entsteht. Im Englischen spricht man daher hier auch vom 'administrative overhead' (AO). Selbst wenn man heute schon in der Hardware diese Verwaltungsprozesse dadurch beschleunigt, dass man keine speziellen Register mehr benutzt, sondern nur noch Speicherbereiche, zwischen denen man hin- und herschaltet, benötigt man auch in diesem Fall minimale Verwaltungsprozesse, die das Wiederauffinden der verschiedenen Speicherbereiche sicherstellen.

Seien

die Ausführungszeiten, die die Tasks a und b 'für sich genommen' benötigen. Sei

die Umschaltzeit (switch-time) von a nach b. Dann ist einerseits klar, dass jede präemptive Unterbrechung zwei zusätzliche Verwaltungszeiten einführt.  Im Falle vieler 'blinder' Interrupts könnte dies den administrativen Overhead extrem erhöhen. Man kann ausrechnen, in welcher Konstellation der worst-case administrative overhead (WCAO) das Gesamtverhalten des Systems soweit stören würde, dass es die Realzeitanforderungen sprengen würde. Das Problem ist nur, dass die Ursachen für solche Umschaltvorgänge letztlich in Ereignissen gründen, deren Auftreten nicht vom System kontrolliert werden können (man denke an die grossflächigen Zusammenbrüche der Energieversorgung in USA, Schweden und Italien in 2003).

START

5. WCET := Worst Case Execution Time

Von dem Worst Case Administrative Overhead (WCAO) ist die Worst Case Execution Time (WCET) zu unterscheiden. Während die WCAO von Ereiniskonstellationen abhängt, die vom System nicht vorhergesehen werden können, handelt es sich bei der WCET um Zeiten, die unter Voraussetzung der bekannten Eigenschaften des Systems berechnet werden können. Zur Berechnung von WCET müssen allerdings alle Eigenschaften erfasst werden .

Die nachfolgenden Überlegungen haben dann gezeigt, dass eine Bestimmung des Zeitbedarfs nicht auf einer Ebene alleine, sondern nur unter Berückichtigung aller Ebenen vorgenommen werden kann.

Das nachfolgende Diagramm bringt dies nochmals zusammenfassend zum Ausdruck:

Ausgangspunkt ist die Grösse WCET := worst case execution time. Wenn es eine Grösse gibt, die präzise und verlässlich bestimmt werden muss, dann diese. Der  Einlösung dieser Forderung stehen aber  immense Schwierigkeiten entgegen.

Ausgangspunkt bildet die Software auf der höchsten Ebene der Kodierung; möglicherweise sogar die Ebene der formalen Modellbildung. Nennen wir dies den A-Level für abstrakten Level. Dies ist die Ebene, auf der die logische Funktion der Software definiert ist. Dies ist ebenfalls die Ebene, auf der der Auftraggeber mit dem/der IngenieurIn kommuniziert. Die Aufgabe besteht hier darin, diese formale Darstellung der Software in eine solche formale Präsentation zu übersetzen, die es zweifelsfrei erlaubt, jedem Abschnitt des Softwarequelltextes eindeutig einen Zeitbedarf zuzuweisen. Eine von mehreren Möglichkeiten, dies zu tun, ist die Konvertierung des Quelltextes in Struktogramme. Da sich alle Algorithmen grundsätzlich vollständig in Struktogramme konvertieren lassen, ist garantiert, dass bei dieser Konvertierung nichts verlorengeht.

Im nächsten Schritt muss nun eine Zuordnung hergestellt werden zwischen Abschnitten des Quelltextes auf dem A-Level und dem Objekkode, der vom Compiler erzeugt wird. Nennen wir diese Ebene den O-Level. Ohne diese Zuordnung ist nicht klar, welcher Ressourcenbedarf dem Quelltext auf der hohen Ebene entspricht, also

Ist diese Abbildung gelungen, dann muss man nun eine Zuordnung herstellen zwischen den Elementen des Objektkodes und den Operationen der Mikroarchitektur; nennen wir diese den M-LEVEL, also:

Ist auch diese Zuordnung gelungen, dann lässt sich der Zeitbedarf eines Programms klar angeben. Wichtig dabei ist, dass nicht alle Verarbeitungs-Pfade betrachtet werden müssen, sondern nur die kritischen Pfade ('critical paths'); dies sind jene, die die WCET gefährden könnten.

An dieser Stelle angekommen muss man feststellen, dass die Quantifizierung des M-LEVELS wahrscheinlich das grösste Problem darstellt; denn die modernen Prozessoren und Mikrokontroller sind fast ausnahmslos RISC-Prozessoren, die ausgefeilte Caching- und Pipelining-Verfahren beinhalten. Ein solches Verhalten ist indeterministisch! Es bleibt eine offene Frage, wieweit man in extrem zuverlässigen Kontexten solche CPUs überhaupt einsetzen kann; der Trend geht momentan allerdings dahin, fast ausschliesslich solche hochleistungsfähigen, aber inhärent indeterministisch, Prozessoren zu bauen.

Kann man schon alleine durch diese Analyse der Anforderungen der unterschiedlichen Realisierungsebenen erahnen, welche Herausforderungen Realzeitsysteme für den/die IngenieurIn bereithalten, so wird dies noch zusätzlich erschwert durch die Tatsache, dass die Annahme von S-Tasks ohne Präemption praktisch kaum vorkommt; selbst bei der vereinfachenden Annahme, dass nur S-Tasks auftreten, muss man doch meistens Präemption annehmen. Damit kommt aber nicht nur die Grösse WCAO ins Spiel, sondern auch der Faktor externer Ursachen, die vom System selbst nicht kontrolliert werden kömnen. Nimmt man weiterhin an --was 'normal' ist--, dass C-Tasks vorkommen, dann tritt zusätzlich das Synchronisationsproblem auf, das in der Berechnung berücksichtigt werden muss.

Angesichts dieser Komlexität überrascht es nicht, wenn [KOPETZ 1997:90] zur Frage der WCET-Bestimmung abschliessend schreibt:

START

6. Zuverlässigkeit (Reliability)

(Die Ausführungen zur Zuverlässigkeit orientieren sich am Kap.7 des sehr guten Buches von [STOREY 1998]; für mehr Details und weitere Informationen sei auf dieses Buch verwiesen).

Der Begriff der Zuverlässigkeit (Reliability) führt strenggenommen über die Thematik von Realzeitsystemen hinaus. Dies ist eher ein Thema für das Fach Sicherheitskritische Systeme (Safety Critical Systems). Dennoch ist dieser Begriff so eng mit Realzeitsystemen verknüpft, dass hier einige grundsätzlichen Begriffe eingeführt werden sollen.  Der Zusammenhang ist dadurch gegeben, dass  Realzeitsysteme  bestimmte Zeitvorgaben (Deadlines) einhalten müssen und diese Einhaltung garantiert werden muss. Da nun  Realzeitsysteme letztlich  konkrete technische Systeme sind, gilt, dass auch  sie --über den Aspekt des Zeitmanagements hinaus--  im Bereich Hardware und Software Fehlfunktionen aufweisen können, die zu einer Beeinträchtigung der  Zuverlässigkeit führen können. Diese hardwarebedingten Beeinträchtigungen sollen im Folgenden kurz beschrieben werden. Zuvor jedoch muss geklärt werden, wie es möglich ist, über die Zuverlässigkeit (Reliability) eines technischen Systems so zu sprechen, dass dies nicht einfach 'willkürlich' ist. Wie muss eine Aussage über die Zuverlässigkeit eines technischen Systems beschaffen sein, dass Sie im Rahmen eines Rechtsstreits Bestand haben kann?

Anhand des folgenden Schaubildes sei dies kurz erläutert.

Figure: Measurement of Reliability

Aussagen über die Zuverlässigkeit können nur dann akzeptiert werden, wenn sie auf einem transparenten und wiederholbaren Messvorgang beruhen (siehe hierzu auch Standardisierte Beobachtung). Dies setzt voraus, dass die Ereignisse, die als Fehler klassifiziert werden, entsprechend definiert sein müssen. Für solch eine Klassifikation benötigt man eine Norm, einen Standard, anhand dessen entscheidbar ist, was als Fehler gelten soll. Im Falle konkreter technischer Systeme kann dies nur das offfizielle Anforderungsdokument sein (auch Pflichtenheft genannt, Requirements Document). Nur und insoweit in einem Anforderungsheft (verpflichtend für Auftraggeber wie Auftragnehmer) nachvollziehbar beschrieben ist, welches die gesollten Verhaltensweisen des System sein sollen, kann man relativ zu dem beschrieben SOLL mögliche Abweichungen von diesem Soll im späteren Betrieb identifizieren. Diese entscheidbaren Abweichungen stellen ein Fehlverhalten dar, für das der Auftragnehmer haftet. Dies bedeutet, jedes beobachtbare Verhalten eines  technischen Systems, das von dem vertraglich vereinbarten SOLL-Verhalten abweicht, zählt als Fehler. Ein so definierter Fehler kann dann als neues Referenzobjekt (RO) für das Messen von Fehlern benutzt werden. Der Fehlerbegriff ist einer direkten Messung zugänglich.  Gewöhnlich wird aber der Begriff des Fehlers in Verbindung mit Zeit benutzt und man definiert klein Lambda als lambda = Fehler/Zeit. Die Fehlerhäufigkeit lambda (auch als 'Fehlerrate' bezeichnet) ist einer indirekten Messung zugänglich.  Die unterschiedlichen Werte von lambda lassen sich vergleichen nd es gelten die Ordnungsrelationen '<' und '='. Damit kann man mit den Werten von lambda eine Ordinalskala bilden und unterschiedliche Systeme bzgl. ihrer  Fehlerrate vergleichen.

Nehmen wir im folgenden an, dass ein System aus verschiedenen Komponenten (components) besteht, die entweder hintereinander oder parallel geschaltet sein können und die alle zum Gesamtverhalten des Systems beitragen. Nehmen wir ferner an, dass die möglichen Fehler (failures) nicht systematischer, sondern nur zufälliger (random) Natur sind

START

6.1 Fehlerrate Lambda eines Systems

Ein konkretes System S besteht gewöhnlich aus Hardware oder Hardware und Software. Dabei besitzt jedes System ganz spezifische Eigenschaften die ein ganz spezifisches Fehlerverhalten bedingen. Besteht das System aus Standardkomponenten, die nach Standardverfahren zusammengebaut werden, dann kann man aufgrund von empirischen Daten zu solchen System das Verhalten des Systems bezüglich der Fehlerrate parametrisieren. Ein Vorrreiter war in diesen Dingen das amerikanische Verteidigungsministerium (Department of Defense (DoD)), das aufgrund der immensen Komplexität der militärischen Systeme schon sehr früh gezwungen war, die Herstellungs- und Testverfahren von militärischen Systemen zu standardisieren. In diesem Zusammenhang wurden über die Jahre umfangreiche Daten gesammelt, die im Dokument MIL-HDBK-217 zusammengetragen worden sind (man beachte die Updates!).

Eine allgemeine Definition der Fehlerrate Lambda ist die folgende:

Angenommen, ein System s1 hat 5 Fehler in 10^6 Stunden, dann würde gelten

Lambda(S1) = 5/1*10^6 h = 0.000005

Im Standard MIL-HDBK-217 werden zahlreiche Bauteile 'normiert'. So wird z.B. die Fehlerrate Lambda für Halbleiter Speicherbausteine angegeben mit der Formel:

START

6.2 MTTF (Mean Time To Failure)

Hat man Lambda gegeben, dann kann man eine Reihe weiterer Begriffe definieren. Z.B. wird die Grösse MTTF wie folgt definiert:

MTTF = 1/Lambda

Bsp: Ein Webserver, der 1x pro Woche ausfällt hätte also die Werte:

(1 Woche = 24h * 7 = 168h)

Lambda = 1/168 = 0.0059524

MTTF = 1/lambda = 168h

START

6.3 MTTR ('Mean Time to Repair')

Wartbarkeit hat damit zu tun, wieviel Zeit man benötigt, um das Auftreten eines Fehlers im System zu entdecken, ihn zu lokalisieren, ihn zu beheben und das System wieder in den korrekten betriebsfähigen Zustand zu versetzen. Ein hier vielfach benutzter Begriff ist der Begriff Mittlere Zeit zur Wiederherstellung ('Mean Time to Repair', MTTR). Setzt man eine konstante Reparaturrate my an (Reparaturen pro Stunde), dann kann man --analog zu MTTF-- vereinbaren: MTTR = 1/my.

START

6.4 MTBF ('Mean Time Between Failure')

MTBF = MTTF + MTTR

START

6.5 Availability/ Unavailability

Verfügbarkeit beschreibt die Zeit, in der ein Dienst verfügbar ist (MTTF) im Verhältnis zur Zeit in der er wegen Reparatur nicht verfügbar ist (MTTR) und verfügbar ist (MTTF), also MTTR+MTTF. Im Falle konstanter Fehler- und Reparaturraten gilt dann:

A = MTTF/(MTTF+MTTR)

Unavailability = 1 - Availability

Das nachfolgende Schaubild fasst einige der Begriffe nochmals zusammen:

START

6.6 Zuverlässigkeit R(t); Unzuverlässigkeit Q(t)

Auf der Basis von Lambda kann man nun aber auch den Begriff der Zuverlässigkeit (Reliability) definieren als die Wahrscheinlichkeit, mit der ein bestimmtes System in einem bestimmten Zeitintervall (t₀,t) korrekt funktionieren wird.

Es gilt die Formel:

(Für die Formeln in dieser Vorlesung benutze ich das Opensource-Werkzeug scilab); hier die benutzen Formeln im scilab-Format.

Entsprechend kann man die Unzuverlässigkeit definieren als:

Um  mit scilab rechnen zu können, kann man scilab auch direkt aus dem Verzeichnis aus aufrufen und als Argument eine Formeldatei übergeben, z.B. die Datei 'reliability.sci':

gerd@linux:~/public_html/fh/I-RT05/VL/VL2> scilab -f reliability.sci

Es öffnet sich dann ein scilab-Fenster, in dem man über die Kommandozeile nun die aktivierten Formeln benutzen kann. Angenommen, ein System hat eine Fehlerrate Lambda von 0.001 pro Stunde, dann ergibt sich der Wert MTTF zu 1000 Stunden. Setzt man diese Werte in die Formel ein, so bekommt man:

-->reliability(1000,0.001)
ans = 0.3678794

Das bedeutet, die Wahrscheinlichkeit, dass das System bis zum Zeitpunkt t = 1000, also der vollen MTTF-Zeit von 1000 Std, das System korrekt funktioniert, liegt nur bei ca. 37 %! Oder, wegen

Q(t) = 1 - R(t) = 1 - 0.3678794 = 0.6317525

Die Wahrscheinlichkeit, dass das System in den 1000 Std. einen Fehler haben wird, liegt bei ca. 63%. Man könnte dies auch direkt berechnen mit:

-->unreliability(1000,0.001)
ans = 0.6321206

Dabei ist zu bedenken, dass aufgrund des exponentiellen Charakters der Funktion die Zuverlässigkeit mit wachsender Betriebszeit abnimmt Mit scilab kann man dies wie folgt berechnen:

-->t=[1:1:10], for k=1:1:10, t(k)=reliability(k*100,0.001), end

...

-->plot2d(t)

(siehe Schaubild):

Man kann den Blickpunkt auch verändern und fragen, wie sich die Fehlerrate Lambda verändert, wenn man die Zuverlässigkeit konstant hält. Wegen y=a^x und x =log_a(y) bekommt man:

Für einen Wert von R(1000) = 0.99 ergibt sich folgender Wert für lambda:

-->lambda1(0.99,1000)
ans = 0.0000101

Um den Wert von lamda für einen Wert von R(t) = 0.999  für den Zeitraum von t = 0 * 100 bis t = 10 * 100 zu errechnen, muss man folgendes eingeben:

-->t=[1:1:10], for k=1:1:10, t(k)=lambda1(0.999,k*100), end

-->xbasc() /* Löscht das vorausgehende Grafikfenster */

-->plot2d(t)

Figure: Abnahme der Fehlerrate Lambda bei Fortschreiten der Zeit und konstanter Zuverlässigkeit

Man erkennt hier direkt, dass man für die Einhaltung eines bestimmten Zuverlässigkewitswertes über einen längeren Zeitraum  eine immer  niedrigere Fehlerrate garantieren muss.

Handelt es sich bei dem zu prüfenden System um ein komplexes System, so setzt sich das Verhalten aus dem Verhalten der Teilsysteme zusammen. Entsprechend muss man das Gesamtverhalten durch Berechnung der Verhalten der Teilsysteme berechnen.

START

6.7 Zuverlässigkeit bei sequentiellen Systemen

Besteht das komplexe System aus einer Sequenz von k-vielen atomaren Systemen, dann addiert sich die Fehlerrate Lambda von jedem Teilsystem:

Für die Zuverlässigkeit gilt in diesem Fall:

START

6.8 Zuverlässigkeit bei parallelen Systemen

Besteht das komplexe System aus einer Parallelschaltung von k-vielen atomaren Systemen, dann kann man die Zuverlässigkeit über die Unzuverlässigkeit annähern:

Wegen R(t) = 1 - Q(t) gilt dann:

START

6.9 Zuverlässigkeit bei kombinierten Systeme

In der Praxis treten natürlich Systeme auf, die sowohl sequentielle Kombinationen von Systemen umfassen wie auch parallele, dies zusätzlich gemischt.

In einem solchen Fall muss man so vorgehen, dass man von innen nach aussen reine Sequenzen bzw. Parallelschaltungen berechnet und diese Schaltungen dann weiterhin wie ein einziges System behandelt. Auf diese Weise wird die komplexe Verknüpfung nach und nach immer mehr vereinfacht.

In dem vorausgehenden Beispielsystem A bestand A aus einer Parallelschaltung von zwei sequentiellen Schaltungen: OR( AND(1,2), AND(3,4)). In diesem Beispiel würden zunächst die beiden sequentiellen Schaltungen jede für sich ausgerechnet, so dass man z.B. die Werte bekäme OR(0.955, 0.914). Dann würde man die parallele Schaltung berechnen, also:

START

6.10 Zusammenfassung: eine anhaltend schwierige Situation

Die hier vorgestellten Begriffe und Methoden bilden nur einen Ausschnitt aus einem ganzen Spektrum. Zur Vertiefung sei nochmals verwiesen auf das Buch von [STOREY 1998]

Grundsätzlich ist festzuhalten, dass zwar der Bedarf an zuverlässigen Systemen beständig steigt, eine alle Fehler berücksichtigende und erfassende Methodik aber bis heute nicht in Sicht ist. Dies betrifft sowohl die Fehlervermeidung während der Erstellung des Systems, die Fehlervoraussage wie auch das Testen von zuverlässigen Systemen.

START

7. Klassifikation von Realzeit-Systemen

Für die Klassifikation von Realzeit-Systemen stehen zahlreiche Kategorien zur Verfügung. Einige seien hier aufgelistet:

1. Fail-safe/Fail-operational: In einem System, das 'fail-safe' ist, kann das System mit hoher Wahrscheinlichkeit einen Fehler erkennen und dann einen sicheren Zustand ansteuern. In Situationen, in denen keine sicheren Zustände verfügbar sind, ist das System 'fail-operational'.




2. Guaranteed-Response/ Best-Effort: eine garantierte Antwort ('guaranteed-response') liegt vor, wenn ein System so umfassend analysiert worden ist, dass es in allen voraussagbaren Belastungssituationen eine definierte Antwort zu geben vermag. Ist eine umfassende Analyse nicht verfügbar, dann kann es nur 'beste Versuche' ('best effort') geben, eine Antwort bereitzustellen; dies kann mangelhaft sein.




3. Resource-Adequate/ Resource Inadequate: in einem ressourcenadäquaten System stehen in allen Belastungsfällen genügend Ressourcen zur Verfügung. In vielen Systemen wird aber aus Wirtschaftlichkeitsüberlegungen mit limitierten Ressourcen gearbeitet, die aufgrund von Wahrscheinlichkeitsüberlegungen dynamisch verwaltet werden. Bei schlechten Einschätzungen sind damit Störfälle wahrscheinlich.




4. Event-triggered/ Time-triggered: in ereignisgetriebenen ('event triggered') Systemen reagiert ein System ausschliesslich auf das Auftreten bestimmter Ereignisse, die durch sogenannte Unterbrechungen ('interrupts') 'bekannt' werden. Das System muss dann dynamisch auf diese Unterbrechungen reagieren. Im Unterschied dazu orientieren sich zeitgetriebene ('time triggered') Systeme ausschliesslich an einem Systemtakt ('system clock'), der fest mit bestimmten Aktionen verknüpft ist. In verteilten Systemen stellt dabei die Synchronisation der verschiedenen Systemtakte eine wichtige Aufgabe dar (siehe oben)..




5. Hard Real-Time/ Soft Real-Time: der zentrale Unterschied zwischen Hard Realtime Systemen und Soft Realtime Systemen kann wohl am besten am Verhältnis zur Umwelt festgemacht werden. Ein hartes Realzeit-System muss absolut synchron bleiben mit den Ereignissen in seiner Umgebung, wohingegen ein weiches Realzeit-System seine Antwortzeiten unter Belastung bis zu einem gewissen Grad gegenüber der Umgebung verlangsamen kann (z.B. dauern die Reaktionszeiten eines Servers im Netz dann einfach länger) ohne dabei Schaden anzurichten. Die Zeitanforderungen von harten Realzeit-Systemen liegen auch oft in kleineren Zeiteinheiten (Milisekunden und weniger) als bei weichen Realzeitsystemen (Sekunden). Damit harte Realzeit-Systeme ihre Leistungen zuverlässig erbringen können, müssen sämtliche Belastungssituationen, auch die eher seltenen, vollständig analysiert sein, so dass eine garantierte Antwort gewährleistet wird. Bei weichen Systemen reicht in der Regel eine durchschnittliche Antwortzeit. Ferner verlangen harte Realzeit-Systeme eine sehr zuverlässige autonome Fehlererkennung und Fehlerbehandlung innerhalb klar definierter zeitlicher Grenzen. Für harte Realzeit-Systeme ist es ferner wichtig, dass ihre zeitlichen Daten innerhalb sehr enger Grenzen absolut zuverlässig sind; die impliziert, dass es sich um kleine Datensätze handelt. Demgegenüber operieren viele weiche Realzeit-Systeme mit grossen Datensätzen, deren Integrität über lange Zeiträume zu gewährleisten ist. Roll-Back-Strategien weicher Realzeit-Systeme sind wegen der sehr engen zeitlichen Schranken für harte Realzeitsysteme in der Regel nicht anwendbar.

START

8. Berechnungsbeispiele zur Zuverlässigkeit

8.1 Serielle Schaltung: Q(t) gesamt

Gegeben sei eine serielle Schaltung mit K-vielen Komponenten, für die eine Zuverlässigkeit von R_c(t) = 0.999 für alle Komponenten gelten soll. Jede Komponenten wird als völlig unabhängig von den anderen angenommen.

Gefragt wird nach der Zuverlässigkeit R(t) der gesamten Schaltung bzw. nach der Unzuverlässigkeit Q(t) der gesamten Schaltung, für K = 100. Es gilt:

Am Beispiel der Unzuverlässigkeit kann man sehen, wie dramatisch die Unzuverlässigkeit ansteigt selbst dann, wenn die einzelnen Komponenten sehr zuverlässig sind. Bei 100 Komponeten steigt die Unzuverlässigkeit um den Faktor 950 !

START

8.2 Serielle Schaltung: Komponenten

Man hat eine serielle Schaltung mit K = 100 Komponenten und man will wissen, wie gross die individuellen Zuverlässigkeit R_c(t) sein muss, damit die Zuverlässigkeit R(t) des Gesamtsystems mindestens so gross ist wie R_SOLL(t)

Man erkennt, dass die Genauigkeit der einzelnen Komponenten erheblich grösser sein muss als die Genauigkeit des gesamten seriellen Systems.

Dieser Zusammenhang wird noch deutlicher, wenn man die Frage umformuliert. Man gibt einen SOLL-Wert R(t) mit z.B.0.9047921 für das Gesamtsystem vor und einen IST-Wert R_c(t) für die einzelnen Komponenten, z.B. 0.999. Dann fragt man nach der notwendigen Anzahl K von Komponenten, um den Gesamtwert zu erreichen.

Man benötigt also höchstens 100 Komponenten.

START

8.3 Parallele Schaltung: Q(t) gesamt

Gegeben sei eine parallele Schaltung mit K Komponenten. Es sei wiederum angenommen, dass die Zuverlässigkeit einer einzelnen Komponenten R_c(t) = 0.999 sei. Gefragt ist nach der Zuverlässigkeit R(t) des Gesamtsystems.

Man sieht, ein paralleles System ist schon mit 3 Komponenten ertrem zuverlässig!

START

8.4 Parallele Schaltung: Komponenten

Auch im Falle der Parallelschaltungen kann man natürlich die Frage so stellen, dass man wissen will, mit wievielen Komponenten K man bei einer gegebenen Komponentenzuverlässigkeit von R_c(t) = IST eine bestimmte Gesamtzuverlässigkeit R_SOLL(t) erreicht wird.

Es sei angenommen, dass die Zuverlässigkeit R_c(t) der einzelnen Komponenten schlechter sei als die Zuverlässigkeit R_SOLL(t) des Gesamtsystems, die mit 0.999 angenommen wird. Dann ergibt sich z.B. für einen Wert von R_c(t) = 0.70:

Mit einem ganzzahligen Wert von K = 6 erreicht das Gesamtsystem die Zuverlässigkeit von 0.999. Im Vergleich zum seriellen System sieht man, dass die Zuverlässigkeit von parallelen Schaltung auch bei geringerer Qualität der einzelnen Komponenten erheblich grösser ist als bei seriellen Systemen.

START

9. Testfragen

1. Wie verhalten sich die Begriffe 'cluster', 'ftu', 'node' und 'task' zueinander?




2. Was unterscheidet einen S-Task von einem C-Task?




3. Was bedeutet es, wenn ein System 'präemptiv' ist?




4. Wenn Taskunterbrechung eintritt, welche Auswirkungen hat dies auf die Ressource Zeit?




5. Was verstehen Sie unter WCAO?




6. Was verstehen Sie unter WCET?




7. Warum spielen Abbildungsprozesse im Rahmen der Berechnung von WCET eine wichtige Rolle? Worin bestehen diese Abbildungsprozesse?




8. Nennen Sie Faktoren, die die Ermittlung von WCET erschweren bzw. beim heutigen Wissensstand letztlich unmöglich machen?





9. Beschreiben sie, was ein atomares System ist?




10. Worin unterscheidet sich ein komplexes System von einem atomaren System?




11. Wie ist die Fehlerrate Lambda definiert?




12. Machen Sie einen Vorschlag, wie man die Fehlerrate Lambda für ein konkretes System ermittelt?




13. Was bedeuten die Kürzel MTTR, MTTF, MTBF?




14. Was versteht man unter der Availability bzw. Unavailability von Systemen?




15. Wie wird die Zuverlässigkeit (Reliability) eines Systems definiert?




16. Wie wird die Unzuverlässigkeit (Un-Reliability) eines Systems definiert?




17. Wie interpretieren Sie den Sachverhalt, dass ein System bei einer MTTF = 1000h einen Wert für die reliability von reliability(1000,0,0.001) = 0.3678794 besitzt?




18. Warum kann die Zuverlässigkeit eines Systems bei anwachsender Betriebszeit abnehmen?




19. Wie berechnen Sie die Zuverlässigkeit eines komplexen Systems, das sequentiell aufgebaut ist? Geben Sie ein konkretes Beispiel.




20. Wie berechnen Sie die Zuverlässigkeit eines komplexen Systems, das parallel aufgebaut ist? Geben Sie ein konkretes Beispiel.




21. Wie berechnen Sie die Zuverlässigkeit eines komplexen Systems, das sequentiell und parallel aufgebaut ist? Geben Sie ein konkretes Beispiel.




22. Beschreiben Sie die wichtigen Eigenschaften von fünf wichtigen Klassifikationen von Realzeitsystemen.




23. Geben Sie 7 Beispiele von Realzeitsystemen aus ihrer alltäglichen Umgebung an und geben sie Erfahrungswerte an für MTTF, MTTR und f+r die Zuverlässigkeit dieser Systeme.




24. Geben Sie 3 Beispiele von Realzeitsystemen aus ihrer alltäglichen Umgebung, deren Zuverlässigkeit ihrer Einschätzung nach vergleichsweise am höchsten liegen und 3 Beispiele von Realzeitsystemen, deren Zuverlässigkeit vergleichsweise am niedrigsten liegen.

START