Verlässliche Echtzeitsysteme
|
|
- Lilli Babette Geiger
- vor 6 Jahren
- Abrufe
Transkript
1 Verlässliche Echtzeitsysteme Redundanz und Fehlertoleranz Peter Ulbrich Lehrstuhl für Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg Mai 2017 Verlässliche Echtzeitsysteme (SS 17) 1/38
2 Das Problem Wiederholung: Fehlerkette und Fehlerfortpflanzung Ungehemmte Fehlerfortpflanzung führt zum Systemversagen Unerkannte Datenfehler (engl. silent data corruption) (vgl. III/10) Bedingen beispielsweise fehlerhafte Stellwerte für Aktoren Ihre Folgen treten häufig räumlich und zeitlich unkorreliert auf Erkannte, unkorrigierbare Fehler (engl. detected unrecoverable errors) Führen zu einem unmittelbaren, erkennbaren Systemversagen Verlässliche Echtzeitsysteme (SS 17) 1 Übersicht 2/38
3 Das Problem Wiederholung: Fehlerkette und Fehlerfortpflanzung Ungehemmte Fehlerfortpflanzung führt zum Systemversagen Unerkannte Datenfehler (engl. silent data corruption) (vgl. III/10) Bedingen beispielsweise fehlerhafte Stellwerte für Aktoren Ihre Folgen treten häufig räumlich und zeitlich unkorreliert auf Erkannte, unkorrigierbare Fehler (engl. detected unrecoverable errors) Führen zu einem unmittelbaren, erkennbaren Systemversagen Vermeidung dieser Fehler ist erforderlich Problematik: Robuste Auslegung aller Komponenten ist häufig nicht möglich Diese müssten frei von konzeptionellen Fehler sein ( keinerlei Hardware- oder Softwaredefekte) Sie müsste widrigen äußeren Umständen trotzen Lösung: Ein System, welches Fehler tolerieren kann Einzelne Komponenten (HW/SW) können (dürfen) ausfallen Dies wird durch andere redundante Komponenten aufgefangen Die gewünschte Funktionalität an der Schnittstelle bleibt erhalten Der Anwender bekommt davon möglichst nichts mit ( Transparenz) Verlässliche Echtzeitsysteme (SS 17) 1 Übersicht 2/38
4 Übersicht Fehlertoleranz durch Redundanz Redundanz als Grundlage von Fehlertoleranz Welche Arten von Redundanz existieren? Welche Eigenschaften verknüpfen sich hiermit? Auf welcher Ebene wird Redundanz angewandt? Hardwarebasierte Replikation Was tun gegen unzuverlässige Komponenten? Klassische Lösung für die Auslegung fehlertoleranter Systeme Replikation auf Ebene des Knotens bzw. der Hardware Fokussierung auf Triple Modular Redundancy Softwarebasierte Replikation Process-Level Redundancy: Zuhilfenahme von Mehrkernprozessoren Replikation auf Ebene von Prozessen bzw. Software A Maskierung transienter Hardwarefehler durch redundante Ausführung Vermeidung von Gleichtaktfehlern durch Diversität Replizierte Entwicklung der einzelnen Redundanzen Verlässliche Echtzeitsysteme (SS 17) 1 Übersicht 3/38
5 Gliederung 1 Grundlagen Arten von Redundanz Einsatz von Redundanz 2 Strukturelle Redundanz Replikation Fehlerhypothese Voraussetzungen Nutzen Kritische Bruchstellen 3 Umsetzungsalternativen und Beispiele Hardwarebasierte Replikation Softwarebasierte Replikation 4 Diversität 2 Grundlagen 4/38
6 Ziele von Fehlertoleranz Fehlererkennung (engl. fault detection) Erkennen von Fehlern z. B. mithilfe von Prüfsummen Fehlerdiagnose (engl. fault diagnosis) Identifikation der fehlerhaften (redundanten) Einheit Fehlereindämmung (engl. fault containment) Was man mit dem Mehraufwand eigentlich bezweckt! Verhindern, dass sich ein Fehler über gewisse Grenzen ausbreitet Fehlermaskierung (engl. fault masking) Dynamische Korrektur von Fehlern z. B. durch Mehrheitsentscheid Wiederaufsetzen (engl. recovery) Wiederherstellen eines funktionsfähigen Zustands nach Fehlern Reparatur (engl. repair) bzw. Rekonfiguration (engl. reconfiguration) Fokus der Vorlesung: Fehlererkennung und Fehlermaskierung 2 Grundlagen 5/38
7 Arten von Redundanz Redundanz ist eine Grundvoraussetzung für Fehlertoleranz 2 Grundlagen 2.1 Arten von Redundanz 6/38
8 Arten von Redundanz Redundanz ist eine Grundvoraussetzung für Fehlertoleranz Strukturelle Redundanz (dieses Kapitel) A Bereitstellung mehrerer gleichartiger Komponenten Replikation (typisch) hardwarebasierte Fehlertoleranzlösungen Mehrfache Auslegung: Prozessoren, Speicher, Sensoren, Aktoren,... 2 Grundlagen 2.1 Arten von Redundanz 6/38
9 Arten von Redundanz Redundanz ist eine Grundvoraussetzung für Fehlertoleranz Strukturelle Redundanz (dieses Kapitel) A Bereitstellung mehrerer gleichartiger Komponenten Replikation (typisch) hardwarebasierte Fehlertoleranzlösungen Mehrfache Auslegung: Prozessoren, Speicher, Sensoren, Aktoren,... Funktionelle Redundanz A Bereitstellung mehrerer verschiedenartiger Komponenten Mehrfache Herleitung desselben Sachverhalt auf verschiedenen Wegen Ventilstellung Stellungsgeber bzw. Durchflussmengenmesser Funktionswächter (engl. watchdog) für bestimmte Parameter 2 Grundlagen 2.1 Arten von Redundanz 6/38
10 Arten von Redundanz Redundanz ist eine Grundvoraussetzung für Fehlertoleranz Strukturelle Redundanz (dieses Kapitel) A Bereitstellung mehrerer gleichartiger Komponenten Replikation (typisch) hardwarebasierte Fehlertoleranzlösungen Mehrfache Auslegung: Prozessoren, Speicher, Sensoren, Aktoren,... Funktionelle Redundanz A Bereitstellung mehrerer verschiedenartiger Komponenten Mehrfache Herleitung desselben Sachverhalt auf verschiedenen Wegen Ventilstellung Stellungsgeber bzw. Durchflussmengenmesser Funktionswächter (engl. watchdog) für bestimmte Parameter Informationsredundanz (vgl. Kapitel 5) A Einbringung zusätzlicher Informationen/Daten (nicht zwingend erforderlich) Speicherung von Brutto- und Nettobetrag Typischerweise in Form von Codierung (Prüfsummen, CRC,... ) 2 Grundlagen 2.1 Arten von Redundanz 6/38
11 Arten von Redundanz Redundanz ist eine Grundvoraussetzung für Fehlertoleranz Strukturelle Redundanz (dieses Kapitel) A Bereitstellung mehrerer gleichartiger Komponenten Replikation (typisch) hardwarebasierte Fehlertoleranzlösungen Mehrfache Auslegung: Prozessoren, Speicher, Sensoren, Aktoren,... Funktionelle Redundanz A Bereitstellung mehrerer verschiedenartiger Komponenten Mehrfache Herleitung desselben Sachverhalt auf verschiedenen Wegen Ventilstellung Stellungsgeber bzw. Durchflussmengenmesser Funktionswächter (engl. watchdog) für bestimmte Parameter Informationsredundanz (vgl. Kapitel 5) A Einbringung zusätzlicher Informationen/Daten (nicht zwingend erforderlich) Speicherung von Brutto- und Nettobetrag Typischerweise in Form von Codierung (Prüfsummen, CRC,... ) Zeitliche Redundanz A Bereitstellung von über den Normalbetrieb hinausgehender Zeit Z.B. Numerische Algorithmen, Schlupf in einem EZS,... 2 Grundlagen 2.1 Arten von Redundanz 6/38
12 Koordinierter Einsatz von Redundanz Anwendungstransparenz Elementgröße Implementierungsebene (Strukturelement) Voll- / Paravirtualisierung (Virtuelle Maschine) Partielle Virtualisierung (Prozessinkarnation) Anwendung (Algorithmus) Befehlssatz (Instruktion) Redundanzstrategie (Beispiel) Information Redundanztechnik Paritätsbits CRC Prüfsummen Codierung Struktur Redundanztechnik 2-fach Redundanz 3-fach Redundanz Replikation Redundanzart Funktion Redundanztechnik Funktionswächter Konkrete Realisierung (Beispiel) Zeit Redundanztechnik Schlupfzeit Numerische Algorithmen Erst der koordinierte Einsatz von Redundanz ermöglicht Fehlertoleranz In VEZS: Klassifizierung nach Fehlererkennung ( Literatur) Es existieren viele Implementierungsalternativen Implementierungsebene (vgl. Sichtbarkeit Folien III/7 ff) Art der Redundanz und Erkennungsstrategie Anwendungstransparenz 1 A Konkrete Redundanztechnik 1 Funktionelle und zeitliche Redundanz lassen sich in der Praxis nur fallspezifisch implementieren und stehen daher außerhalb des Veranstaltungskontextes. 2 Grundlagen 2.2 Einsatz von Redundanz 7/38
13 Fehlererkennung Grundlagen Relativtest Akzeptanztest x y z Maskierer x = y = z? v v Testvorschrift v wahr/falsch Zwei Testverfahren zur Fehlererkennung (vgl. [3, S.78 ff]) 2 Grundlagen 2.2 Einsatz von Redundanz 8/38
14 Fehlererkennung Grundlagen Relativtest Akzeptanztest x y z Maskierer x = y = z? v v Testvorschrift v wahr/falsch Zwei Testverfahren zur Fehlererkennung (vgl. [3, S.78 ff]) 1 Relativtest (engl. comparison test) (auch Vergleichstest) Ist-Ist-Vergleich auf Übereinstimmung anwendungsunabhängig Erfordert mehrere Vergleichsobjekte A Mehrheitsentscheider (engl. voter) (auch Maskierer) Ausschließlich bei struktureller Redundanz anwendbar 2 Grundlagen 2.2 Einsatz von Redundanz 8/38
15 Fehlererkennung Grundlagen Relativtest Akzeptanztest x y z Maskierer x = y = z? v v Testvorschrift v wahr/falsch Zwei Testverfahren zur Fehlererkennung (vgl. [3, S.78 ff]) 1 Relativtest (engl. comparison test) (auch Vergleichstest) Ist-Ist-Vergleich auf Übereinstimmung anwendungsunabhängig Erfordert mehrere Vergleichsobjekte A Mehrheitsentscheider (engl. voter) (auch Maskierer) Ausschließlich bei struktureller Redundanz anwendbar 2 Akzeptanztest (engl. acceptance test) (auch Absoluttest) Soll-Ist-Vergleich auf Konsistenzbedingung anwendungsabhängig Ein Testobjekt genügt Vollständigkeit der Testbedingung ist das Problem 2 Grundlagen 2.2 Einsatz von Redundanz 8/38
16 Gliederung 1 Grundlagen Arten von Redundanz Einsatz von Redundanz 2 Strukturelle Redundanz Replikation Fehlerhypothese Voraussetzungen Nutzen Kritische Bruchstellen 3 Umsetzungsalternativen und Beispiele Hardwarebasierte Replikation Softwarebasierte Replikation 4 Diversität 3 Strukturelle Redundanz 9/38
17 Replikation Replikation ist der koordinierte Einsatz struktureller Redundanz 3 Strukturelle Redundanz 3.1 Replikation 10/38
18 Replikation Replikation ist der koordinierte Einsatz struktureller Redundanz Aufbau eines Replikationsbereichs (engl. Sphere of Replication, SoR) [5] Sie maskiert transparent Fehler in einzelnen Replikaten Eingabe Replikat 1 Replikat 2 Ausgabe Replikat n 3 Strukturelle Redundanz 3.1 Replikation 10/38
19 Replikation Replikation ist der koordinierte Einsatz struktureller Redundanz Aufbau eines Replikationsbereichs (engl. Sphere of Replication, SoR) [5] Sie maskiert transparent Fehler in einzelnen Replikaten Replikat 1 Eingabe Replikation der Eingaben Replikat 2 Ausgabe Replikat n Eingaben werden repliziert und auf die Replikate verteilt 3 Strukturelle Redundanz 3.1 Replikation 10/38
20 Replikation Replikation ist der koordinierte Einsatz struktureller Redundanz Aufbau eines Replikationsbereichs (engl. Sphere of Replication, SoR) [5] Sie maskiert transparent Fehler in einzelnen Replikaten Replikat 1 Eingabe Replikation der Eingaben Replikat 2 Vergleich der Ausgaben Ausgabe Replikat n Eingaben werden repliziert und auf die Replikate verteilt In einem Ausgangsvergleich werden die Ausgaben abgestimmt 3 Strukturelle Redundanz 3.1 Replikation 10/38
21 Replikation Replikation ist der koordinierte Einsatz struktureller Redundanz Aufbau eines Replikationsbereichs (engl. Sphere of Replication, SoR) [5] Sie maskiert transparent Fehler in einzelnen Replikaten Replikat 1 Eingabe Replikation der Eingaben Replikat 2 Vergleich der Ausgaben Ausgabe Replikat n Eingaben werden repliziert und auf die Replikate verteilt In einem Ausgangsvergleich werden die Ausgaben abgestimmt Offene Fragestellungen: Wie viele Replikate benötigt man, um das zuverlässig tun zu können? Welche Voraussetzungen müssen für eine erfolgreiche Replikation gelten? 3 Strukturelle Redundanz 3.1 Replikation 10/38
22 Wie viele Replikate braucht man? Allgemeiner Fall mit unabhängigen Replikaten (Knoten) Zahl benötigter Replikate hängt von der Art des Fehlverhaltens ab [4] Annahme: von n Replikaten sind in folgender Weise f fehlerhaft 3 Strukturelle Redundanz 3.2 Fehlerhypothese 11/38
23 Wie viele Replikate braucht man? Allgemeiner Fall mit unabhängigen Replikaten (Knoten) Zahl benötigter Replikate hängt von der Art des Fehlverhaltens ab [4] Annahme: von n Replikaten sind in folgender Weise f fehlerhaft fail-silent Ein Replikat erzeugt korrekt oder gar keine Antworten Das Fehlerverhalten führt zum Stillstand A Einfachster Fehlermodus Der Ausfall wird von den anderen Replikaten als solcher erkannt 3 Strukturelle Redundanz 3.2 Fehlerhypothese 11/38
24 Wie viele Replikate braucht man? Allgemeiner Fall mit unabhängigen Replikaten (Knoten) Zahl benötigter Replikate hängt von der Art des Fehlverhaltens ab [4] Annahme: von n Replikaten sind in folgender Weise f fehlerhaft fail-silent Anzahl der Replikate n = f + 1 Ein Replikat erzeugt korrekt oder gar keine Antworten Das Fehlerverhalten führt zum Stillstand A Einfachster Fehlermodus Der Ausfall wird von den anderen Replikaten als solcher erkannt 3 Strukturelle Redundanz 3.2 Fehlerhypothese 11/38
25 Wie viele Replikate braucht man? Allgemeiner Fall mit unabhängigen Replikaten (Knoten) Zahl benötigter Replikate hängt von der Art des Fehlverhaltens ab [4] Annahme: von n Replikaten sind in folgender Weise f fehlerhaft fail-silent Anzahl der Replikate n = f + 1 Ein Replikat erzeugt korrekt oder gar keine Antworten Das Fehlerverhalten führt zum Stillstand A Einfachster Fehlermodus Der Ausfall wird von den anderen Replikaten als solcher erkannt fail-consistent Ein Replikat kann auch fehlerhafte Antworten erzeugen Alle anderen Replikate sehen konsistent dasselbe Fehlverhalten 3 Strukturelle Redundanz 3.2 Fehlerhypothese 11/38
26 Wie viele Replikate braucht man? Allgemeiner Fall mit unabhängigen Replikaten (Knoten) Zahl benötigter Replikate hängt von der Art des Fehlverhaltens ab [4] Annahme: von n Replikaten sind in folgender Weise f fehlerhaft fail-silent Anzahl der Replikate n = f + 1 Ein Replikat erzeugt korrekt oder gar keine Antworten Das Fehlerverhalten führt zum Stillstand A Einfachster Fehlermodus Der Ausfall wird von den anderen Replikaten als solcher erkannt fail-consistent Anzahl der Replikate n = 2f + 1 Ein Replikat kann auch fehlerhafte Antworten erzeugen Alle anderen Replikate sehen konsistent dasselbe Fehlverhalten 3 Strukturelle Redundanz 3.2 Fehlerhypothese 11/38
27 Wie viele Replikate braucht man? Allgemeiner Fall mit unabhängigen Replikaten (Knoten) Zahl benötigter Replikate hängt von der Art des Fehlverhaltens ab [4] Annahme: von n Replikaten sind in folgender Weise f fehlerhaft fail-silent Anzahl der Replikate n = f + 1 Ein Replikat erzeugt korrekt oder gar keine Antworten Das Fehlerverhalten führt zum Stillstand A Einfachster Fehlermodus Der Ausfall wird von den anderen Replikaten als solcher erkannt fail-consistent Anzahl der Replikate n = 2f + 1 Ein Replikat kann auch fehlerhafte Antworten erzeugen Alle anderen Replikate sehen konsistent dasselbe Fehlverhalten malicious bösartige, fehlerhafte Replikate erzeugen verschiedene Antworten Keine konsistente Sicht auf das Fehlverhalten Typischerweise verursacht durch Komm system (Nachrichtenausfall!) Synonym: byzantinische Fehler (engl. byzantine failures) 3 Strukturelle Redundanz 3.2 Fehlerhypothese 11/38
28 Wie viele Replikate braucht man? Allgemeiner Fall mit unabhängigen Replikaten (Knoten) Zahl benötigter Replikate hängt von der Art des Fehlverhaltens ab [4] Annahme: von n Replikaten sind in folgender Weise f fehlerhaft fail-silent Anzahl der Replikate n = f + 1 Ein Replikat erzeugt korrekt oder gar keine Antworten Das Fehlerverhalten führt zum Stillstand A Einfachster Fehlermodus Der Ausfall wird von den anderen Replikaten als solcher erkannt fail-consistent Anzahl der Replikate n = 2f + 1 Ein Replikat kann auch fehlerhafte Antworten erzeugen Alle anderen Replikate sehen konsistent dasselbe Fehlverhalten malicious Anzahl der Replikate n = 3f + 1 bösartige, fehlerhafte Replikate erzeugen verschiedene Antworten Keine konsistente Sicht auf das Fehlverhalten Typischerweise verursacht durch Komm system (Nachrichtenausfall!) Synonym: byzantinische Fehler (engl. byzantine failures) 3 Strukturelle Redundanz 3.2 Fehlerhypothese 11/38
29 Fehlerhypothese (engl. fault hypothesis) Annahmen über das Verhalten einzelner Replikate im Fehlerfall In der Praxis betrachtet man für Echtzeitsysteme Replikate, die: Einen Fehler tolerieren können Sich fail-silent oder zumindest fail-consistent verhalten Unabhängig voneinander ausfallen (vgl. Folie 13 f) Sich Replikdeterministisch verhalten (vgl. Folie 15 ff) 3 Strukturelle Redundanz 3.2 Fehlerhypothese 12/38
30 Fehlerhypothese (engl. fault hypothesis) Annahmen über das Verhalten einzelner Replikate im Fehlerfall In der Praxis betrachtet man für Echtzeitsysteme Replikate, die: Einen Fehler tolerieren können Sich fail-silent oder zumindest fail-consistent verhalten Unabhängig voneinander ausfallen (vgl. Folie 13 f) Sich Replikdeterministisch verhalten (vgl. Folie 15 ff) Byzantinische Fehlertoleranz wird üblicherweise nicht angestrebt Grund ist der enorme Aufwand, der damit verbunden ist 3f + 1 Replikate um f Fehler zu tolerieren Getrennte Kommunikationswege zwischen allen Replikaten Hoher Hardwareaufwand für Replikate und Verkablung A hohe Kosten, Gewicht, Energieverbrauch Erkennung fehlerhafter Replikate erfordert aufwendige Kommunikation f + 1 Kommununikationsrunden für 3f + 1 Replikate und f Fehler Je Runde schickt jedes Replikat eine Nachricht an alle anderen Replikate A Für Echtzeitsysteme ein nicht tolerierbarer zeitlicher Aufwand 3 Strukturelle Redundanz 3.2 Fehlerhypothese 12/38
31 Fehlerisolation Replikate müssen unabhängig voneinander ausfallen Gleichtaktfehler (engl. common mode failures) sind zu vermeiden Sie führen zum gleichzeitigen Ausfall mehrerer Replikate Eine Fehlermaskierung ist in diesem Fall nicht mehr möglich Quellen für Gleichtaktfehler Permanente Fehler in den Komponenten (vgl. Ariane 5 Kapitel II/16 ff) Übergreifen eines Fehlers auf andere Replikate (Fehlerausbreitung) 3 Strukturelle Redundanz 3.3 Voraussetzungen 13/38
32 Fehlerisolation Replikate müssen unabhängig voneinander ausfallen Gleichtaktfehler (engl. common mode failures) sind zu vermeiden Sie führen zum gleichzeitigen Ausfall mehrerer Replikate Eine Fehlermaskierung ist in diesem Fall nicht mehr möglich Quellen für Gleichtaktfehler Permanente Fehler in den Komponenten (vgl. Ariane 5 Kapitel II/16 ff) Übergreifen eines Fehlers auf andere Replikate (Fehlerausbreitung) Einzelne Replikate sind gegeneinander abzuschotten Räumliche Isolation des internen Zustands Dieser darf nicht durch andere Replikate korrumpiert werden Ein verfälschter Zeiger hat großes Schadenspotential Zeitliche Isolation anderer Aktivitätsträger Eine Monopolisierung der Ausführungseinheiten ist zu verhindern Ein Amok laufender Faden könnte in einer Schleife festhängen Selbiges gilt für alle gemeinsamen Betriebsmittel 3 Strukturelle Redundanz 3.3 Voraussetzungen 13/38
33 Lose Kopplung unterstützt Isolation Ziel sind lose gekoppelte Replikate Minimierung des Koordinations- und Kommunikationsaufwands Je weniger sich einzelne Replikate abstimmen müssen, umso besser A Fehlerausbreitung wird auf diese Weise effektiv vermieden 3 Strukturelle Redundanz 3.3 Voraussetzungen 14/38
34 Lose Kopplung unterstützt Isolation Ziel sind lose gekoppelte Replikate Minimierung des Koordinations- und Kommunikationsaufwands Je weniger sich einzelne Replikate abstimmen müssen, umso besser A Fehlerausbreitung wird auf diese Weise effektiv vermieden Unterstützung durch eine statische, zyklische Ablaufstruktur 1 Eingaben lesen Der Zustand des kontrollierten Objekts wird erfasst 2 Berechnungen durchführen Der neue Zustand wird aus dem alten Zustand und den Eingaben berechnet 3 Ausgaben schreiben Die Stellwerte werden an die Aktoren ausgegeben 3 Strukturelle Redundanz 3.3 Voraussetzungen 14/38
35 Lose Kopplung unterstützt Isolation Ziel sind lose gekoppelte Replikate Minimierung des Koordinations- und Kommunikationsaufwands Je weniger sich einzelne Replikate abstimmen müssen, umso besser A Fehlerausbreitung wird auf diese Weise effektiv vermieden Unterstützung durch eine statische, zyklische Ablaufstruktur 1 Eingaben lesen Der Zustand des kontrollierten Objekts wird erfasst 2 Berechnungen durchführen Der neue Zustand wird aus dem alten Zustand und den Eingaben berechnet 3 Ausgaben schreiben Die Stellwerte werden an die Aktoren ausgegeben Lediglich die Schritte 1 und 3 erfordern eine Abstimmung der Replikate Austausch von Nachrichten zwischen den Replikaten, um durch ein Einigungsprotokoll einen Konsens über die Eingaben/Ausgaben zu erzielen Die Berechnung wird von jedem Replikat in Eigenregie durchgeführt Ermöglicht einen unterbrechungsfreien Durchlauf (engl. run-to-completion) 3 Strukturelle Redundanz 3.3 Voraussetzungen 14/38
36 Replikdeterminismus Korrekt arbeitende Replikate müssen identische Ergebnisse liefern. Replikate sind replikdeterministisch (engl. replica determinate), wenn: Ihr von außen beobachtbarer Zustand identisch ist, und... Sie zum ungefähr gleichen Zeitnkt identische Ausgaben erzeugen Sie müssen innerhalb eines Zeitintervalls der Länge d erzeugt werden Im Bezug auf einen gemeinsamen Referenzzeitgeber 3 Strukturelle Redundanz 3.3 Voraussetzungen 15/38
37 Replikdeterminismus Korrekt arbeitende Replikate müssen identische Ergebnisse liefern. Replikate sind replikdeterministisch (engl. replica determinate), wenn: Ihr von außen beobachtbarer Zustand identisch ist, und... Sie zum ungefähr gleichen Zeitnkt identische Ausgaben erzeugen Sie müssen innerhalb eines Zeitintervalls der Länge d erzeugt werden Im Bezug auf einen gemeinsamen Referenzzeitgeber Warum ist Replikdeterminismus wichtig? Replikdeterminismus ist eine Grundvoraussetzung für aktive Redundanz! 3 Strukturelle Redundanz 3.3 Voraussetzungen 15/38
38 Replikdeterminismus Korrekt arbeitende Replikate müssen identische Ergebnisse liefern. Replikate sind replikdeterministisch (engl. replica determinate), wenn: Ihr von außen beobachtbarer Zustand identisch ist, und... Sie zum ungefähr gleichen Zeitnkt identische Ausgaben erzeugen Sie müssen innerhalb eines Zeitintervalls der Länge d erzeugt werden Im Bezug auf einen gemeinsamen Referenzzeitgeber Warum ist Replikdeterminismus wichtig? Replikdeterminismus ist eine Grundvoraussetzung für aktive Redundanz! Korrekte Replikate könnten sonst unterschiedliche Ergebnisse liefern Ein Mehrheitsentscheid ist in diesem Fall nicht mehr möglich In den Replikaten kann der interne Zustand divergieren Unterschiedliche Ergebnisse sind die logische Folge Ein im Hintergrund laufendes Replikat kann im Fehlerfall nicht übernehmen Außerdem wird die Testbarkeit verbessert Schließlich kann man präzise Aussagen treffen, wann welche Ergebnisse von den einzelnen Replikaten geliefert werden müssten 3 Strukturelle Redundanz 3.3 Voraussetzungen 15/38
39 Phänomene, die Replikdeterminismus verhindern Abweichende Eingaben bei verschiedenen Replikaten Digitalisierungsfehler, z. B. bei der Analog-Digital-Wandlung Temperatur- oder Drucksensoren liefern zunächst eine Spannung Diese Spannungen werden in einen diskreten Zahlenwert überführt Abbildungen kontinuierlicher auf diskrete Werte sind fehlerbehaftet Dies betrifft auch die Diskretisierung der physikalischen Zeit A unterschiedliche Reihenfolge beobachteter Ereignisse 3 Strukturelle Redundanz 3.3 Voraussetzungen 16/38
40 Phänomene, die Replikdeterminismus verhindern Abweichende Eingaben bei verschiedenen Replikaten Digitalisierungsfehler, z. B. bei der Analog-Digital-Wandlung Temperatur- oder Drucksensoren liefern zunächst eine Spannung Diese Spannungen werden in einen diskreten Zahlenwert überführt Abbildungen kontinuierlicher auf diskrete Werte sind fehlerbehaftet Dies betrifft auch die Diskretisierung der physikalischen Zeit A unterschiedliche Reihenfolge beobachteter Ereignisse Unterschiedlicher zeitlicher Fortschritt der einzelnen Replikate Oszillatoren verschiedener Replikate sind nie exakt gleich A Vor allem der Zugriff auf die lokale Uhr ist problematisch u. U. werden lokale Auszeiten (engl. time-outs) deshalb gerissen 3 Strukturelle Redundanz 3.3 Voraussetzungen 16/38
41 Phänomene, die Replikdeterminismus verhindern Abweichende Eingaben bei verschiedenen Replikaten Digitalisierungsfehler, z. B. bei der Analog-Digital-Wandlung Temperatur- oder Drucksensoren liefern zunächst eine Spannung Diese Spannungen werden in einen diskreten Zahlenwert überführt Abbildungen kontinuierlicher auf diskrete Werte sind fehlerbehaftet Dies betrifft auch die Diskretisierung der physikalischen Zeit A unterschiedliche Reihenfolge beobachteter Ereignisse Unterschiedlicher zeitlicher Fortschritt der einzelnen Replikate Oszillatoren verschiedener Replikate sind nie exakt gleich A Vor allem der Zugriff auf die lokale Uhr ist problematisch u. U. werden lokale Auszeiten (engl. time-outs) deshalb gerissen Präemptive Ablaufplanung ereignisgesteuerter Arbeitsaufträge Diese bearbeiten u. U. unterschiedliche interne Zustände Die evtl. aus Wettlaufsituation (engl. data races) erwachsen sind 3 Strukturelle Redundanz 3.3 Voraussetzungen 16/38
42 Phänomene, die Replikdeterminismus verhindern Abweichende Eingaben bei verschiedenen Replikaten Digitalisierungsfehler, z. B. bei der Analog-Digital-Wandlung Temperatur- oder Drucksensoren liefern zunächst eine Spannung Diese Spannungen werden in einen diskreten Zahlenwert überführt Abbildungen kontinuierlicher auf diskrete Werte sind fehlerbehaftet Dies betrifft auch die Diskretisierung der physikalischen Zeit A unterschiedliche Reihenfolge beobachteter Ereignisse Unterschiedlicher zeitlicher Fortschritt der einzelnen Replikate Oszillatoren verschiedener Replikate sind nie exakt gleich A Vor allem der Zugriff auf die lokale Uhr ist problematisch u. U. werden lokale Auszeiten (engl. time-outs) deshalb gerissen Präemptive Ablaufplanung ereignisgesteuerter Arbeitsaufträge Diese bearbeiten u. U. unterschiedliche interne Zustände Die evtl. aus Wettlaufsituation (engl. data races) erwachsen sind Nicht-deterministische Konstrukte der Programmiersprache z. B. die SELECT-Anweisung der Programmiersprache Ada 3 Strukturelle Redundanz 3.3 Voraussetzungen 16/38
43 Wie stellt man Replikdeterminismus sicher? Globale diskrete Zeitbasis Ermöglicht eine globale zeitliche Ordnung relevanter Ereignisse Ohne dass sich die Replikate hierfür explizit einigen müssen Es dürfen keine lokale Auszeiten verwendet werden Betrifft die Anwendung, Kommunikations- und Betriebssystem 3 Strukturelle Redundanz 3.3 Voraussetzungen 17/38
44 Wie stellt man Replikdeterminismus sicher? Globale diskrete Zeitbasis Ermöglicht eine globale zeitliche Ordnung relevanter Ereignisse Ohne dass sich die Replikate hierfür explizit einigen müssen Es dürfen keine lokale Auszeiten verwendet werden Betrifft die Anwendung, Kommunikations- und Betriebssystem Einigung über die Eingabewerte Die Replikate führen hierzu ein Einigungsprotokoll durch Konsistente Sicht bzgl. Wert und Zeitnkt der Eingabe A Grundlage für die globale zeitliche Ordnung aller Ereignisse 3 Strukturelle Redundanz 3.3 Voraussetzungen 17/38
45 Wie stellt man Replikdeterminismus sicher? Globale diskrete Zeitbasis Ermöglicht eine globale zeitliche Ordnung relevanter Ereignisse Ohne dass sich die Replikate hierfür explizit einigen müssen Es dürfen keine lokale Auszeiten verwendet werden Betrifft die Anwendung, Kommunikations- und Betriebssystem Einigung über die Eingabewerte Die Replikate führen hierzu ein Einigungsprotokoll durch Konsistente Sicht bzgl. Wert und Zeitnkt der Eingabe A Grundlage für die globale zeitliche Ordnung aller Ereignisse Statische Kontrollstruktur Kontrollentscheidungen sind unabhängig von Eingabedaten Ermöglicht außerdem eine statische Analyse dieser Entscheidungen Programmunterbrechungen sind mit größter Vorsicht einzusetzen 3 Strukturelle Redundanz 3.3 Voraussetzungen 17/38
46 Wie stellt man Replikdeterminismus sicher? Globale diskrete Zeitbasis Ermöglicht eine globale zeitliche Ordnung relevanter Ereignisse Ohne dass sich die Replikate hierfür explizit einigen müssen Es dürfen keine lokale Auszeiten verwendet werden Betrifft die Anwendung, Kommunikations- und Betriebssystem Einigung über die Eingabewerte Die Replikate führen hierzu ein Einigungsprotokoll durch Konsistente Sicht bzgl. Wert und Zeitnkt der Eingabe A Grundlage für die globale zeitliche Ordnung aller Ereignisse Statische Kontrollstruktur Kontrollentscheidungen sind unabhängig von Eingabedaten Ermöglicht außerdem eine statische Analyse dieser Entscheidungen Programmunterbrechungen sind mit größter Vorsicht einzusetzen Deterministische Algorithmen Keine randomisierten Verfahren, nur stabile Sortierverfahren,... 3 Strukturelle Redundanz 3.3 Voraussetzungen 17/38
47 Replikation der Eingänge Stellvertreter Replikation Akzeptanzmaskierer v 1 x = 5 v 1 x = 4,1 Akzeptanztest x C v C v = 3,9 v v 2 y = 5 Replikator v 3 v 2 y = 3,9 Akzeptanztest y C z C Maskierer v C v C z = 5 v 3 z = 3,7 Akzeptanztest Deterministische, seiteneffektfreie Eingänge Mehrfaches Auslesen (Replikation) des Wertes möglich A Zustandswerte, welche im Betrachtungszeitraum ihre Gültigkeit bewahren Indeterministische Eingänge Mehrfaches Auslesen führt zu unterschiedlichen Werten Einsatz eines Stellvertreters Liest den Wert einmal und dupliziert diesen Keine Redundanz! Alternative: Akzeptanzmaskierer Kombination aus Akzeptanz- und Relativtest Anwendungsspezifische Übereinstimmungsbedingung 3 Strukturelle Redundanz 3.3 Voraussetzungen 18/38
48 Zuverlässigkeitsgewinn durch Replikation Hilft viel grundsätzlich viel? Erhöht sich durch Replikation in jedem Fall die Zuverlässigkeit? Anders formuliert: R tmr > R r? R tmr Zuverlässigkeit des TMR-Verbunds, R r des einzelnen Replikats 3 Strukturelle Redundanz 3.4 Nutzen 19/38
49 Zuverlässigkeitsgewinn durch Replikation Hilft viel grundsätzlich viel? Erhöht sich durch Replikation in jedem Fall die Zuverlässigkeit? Anders formuliert: R tmr > R r? R tmr Zuverlässigkeit des TMR-Verbunds, R r des einzelnen Replikats Die Replikation arbeitet korrekt, solange... Der Mehrheitsentscheid korrekt funktioniert R v Zwei Replikate korrekt funktionieren R 2/3 = R 3 r + 3R2 r (1 R r) Alle drei Replikate arbeiten korrekt oder... Ein Replikat fällt aus, hierfür gibt es drei Möglichkeiten A Insgesamt R tmr = R v (R 3 r + 3R2 r (1 R r)) 3 Strukturelle Redundanz 3.4 Nutzen 19/38
50 Zuverlässigkeitsgewinn durch Replikation Hilft viel grundsätzlich viel? Erhöht sich durch Replikation in jedem Fall die Zuverlässigkeit? Anders formuliert: R tmr > R r? R tmr Zuverlässigkeit des TMR-Verbunds, R r des einzelnen Replikats Die Replikation arbeitet korrekt, solange... Der Mehrheitsentscheid korrekt funktioniert R v Zwei Replikate korrekt funktionieren R 2/3 = R 3 r + 3R2 r (1 R r) Alle drei Replikate arbeiten korrekt oder... Ein Replikat fällt aus, hierfür gibt es drei Möglichkeiten A Insgesamt R tmr = R v (R 3 r + 3R2 r (1 R r)) R sys 1.0 R sys = R r R sys = R tmr Annahme: Perfekter Voter R v = R r TMR ist nur sinnvoll falls R r > 0.5 Praxis: Voter sollte zuverlässig sein Größenordnung R v > Strukturelle Redundanz 3.4 Nutzen 19/38
51 Verbliebene kritische Bruchstellen Kritische Bruchstellen (engl. single points of failure) Führen zu einem beobachtbaren Fehlerfall innerhalb der Fehlerhypothese Kompromittieren die fehlertolerierende Eigenschaft des Redundanzbereichs A Im Beispiel auf Folie 10 sind dies Eingabe und Ausgabe 3 Strukturelle Redundanz 3.5 Kritische Bruchstellen 20/38
52 Verbliebene kritische Bruchstellen Kritische Bruchstellen (engl. single points of failure) Führen zu einem beobachtbaren Fehlerfall innerhalb der Fehlerhypothese Kompromittieren die fehlertolerierende Eigenschaft des Redundanzbereichs A Im Beispiel auf Folie 10 sind dies Eingabe und Ausgabe Lösungsmöglichkeiten Bestimme Eingabedaten aus mehreren Sensoren Dies erfordert eine Einigung der Replikate über den Eingabewert, allen muss exakt derselbe Wert zugestellt werden Anwendung funktionaler Redundanz Sensorfusion (engl. sensor fusion) Repliziere den Ausgangsvergleich Erneuter Mehrheitsentscheid über die Ergebnisse des replizierten Vergleichs A Das ist wieder eine kritische Bruchstelle, aber die Fehlerwahrscheinlichkeit sind insgesamt geringer, verschwinden tut sie nie... Robuste Implementierung des Ausgangsvergleichs Zusätzliche Absicherung des Ergebnisses Durchführung des Mehrheitsentscheids durch den Aktor 3 Strukturelle Redundanz 3.5 Kritische Bruchstellen 20/38
53 Gliederung 1 Grundlagen Arten von Redundanz Einsatz von Redundanz 2 Strukturelle Redundanz Replikation Fehlerhypothese Voraussetzungen Nutzen Kritische Bruchstellen 3 Umsetzungsalternativen und Beispiele Hardwarebasierte Replikation Softwarebasierte Replikation 4 Diversität 4 Umsetzungsalternativen und Beispiele 21/38
54 Hardware Triple Modular Redundancy (TMR) Replikat 1 Eingabe Replikat 2 Replikat 3 Ausgabe Üblicherweise dreifache Replikation kompletter Rechenknoten Räumlich redundante Systeme A Weitgehende räumliche und zeitliche Isolation 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 22/38
55 Hardware Triple Modular Redundancy (TMR) Replikat 1 Eingabe Einigung der Eingaben Replikat 2 Replikat 3 Ausgabe Üblicherweise dreifache Replikation kompletter Rechenknoten Räumlich redundante Systeme A Weitgehende räumliche und zeitliche Isolation Abstimmung der Eingabewerte zwischen den Replikaten Die Replikate verfügen über eine gemeinsame globale Zeitbasis Das Kommunikationssystem verhindert die Steuerfehlerausbreitung A Vollständige zeitliche Isolation [6, Kapitel 8] und Replikdeterminismus 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 22/38
56 Hardware Triple Modular Redundancy (TMR) Replikat 1 Eingabe Einigung der Eingaben Replikat 2 Replikat 3 Mehrheitsentscheid Ausgabe Üblicherweise dreifache Replikation kompletter Rechenknoten Räumlich redundante Systeme A Weitgehende räumliche und zeitliche Isolation Abstimmung der Eingabewerte zwischen den Replikaten Die Replikate verfügen über eine gemeinsame globale Zeitbasis Das Kommunikationssystem verhindert die Steuerfehlerausbreitung A Vollständige zeitliche Isolation [6, Kapitel 8] und Replikdeterminismus Mehrheitsentscheid stimmt Ausgabewerte ab Vereinigung von Fehlermaskierung und -erkennung 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 22/38
57 Hardware Triple Modular Redundancy (TMR) Replikat 1 Eingabe Einigung der Eingaben Replikat 2 Replikat 3 Mehrheitsentscheid Ausgabe Üblicherweise dreifache Replikation kompletter Rechenknoten Räumlich redundante Systeme A Weitgehende räumliche und zeitliche Isolation Abstimmung der Eingabewerte zwischen den Replikaten Die Replikate verfügen über eine gemeinsame globale Zeitbasis Das Kommunikationssystem verhindert die Steuerfehlerausbreitung A Vollständige zeitliche Isolation [6, Kapitel 8] und Replikdeterminismus Mehrheitsentscheid stimmt Ausgabewerte ab Vereinigung von Fehlermaskierung und -erkennung 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 22/38
58 Hardwarebasierte Replikation Hot standby: Rechensysteme arbeiten simultan Sie verarbeiten gleichzeitig dieselben Eingaben Ihr Zustand ist jederzeit konsistent A nahtloser Ersatz für ausgefallene Replikate Umsetzungsalternativen und Zustände 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 23/38
59 Hardwarebasierte Replikation Hot standby: Rechensysteme arbeiten simultan Sie verarbeiten gleichzeitig dieselben Eingaben Ihr Zustand ist jederzeit konsistent A nahtloser Ersatz für ausgefallene Replikate Umsetzungsalternativen und Zustände Warm standby: Unterscheidung von Primär- und Sekundärsystem Sekundärsystem läuft im Hintergrund Regelmäßige Zustandssicherung (engl. checkpoint) des Primärsystems Rückkehr zur letzten Sicherung im Fehlerfall (engl. recovery) Primär- und Sekundärsystem sind zeitweise inkonsistent A Höherer Aufwand im Falle der Fehlererholung 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 23/38
60 Hardwarebasierte Replikation Hot standby: Rechensysteme arbeiten simultan Sie verarbeiten gleichzeitig dieselben Eingaben Ihr Zustand ist jederzeit konsistent A nahtloser Ersatz für ausgefallene Replikate Umsetzungsalternativen und Zustände Warm standby: Unterscheidung von Primär- und Sekundärsystem Sekundärsystem läuft im Hintergrund Regelmäßige Zustandssicherung (engl. checkpoint) des Primärsystems Rückkehr zur letzten Sicherung im Fehlerfall (engl. recovery) Primär- und Sekundärsystem sind zeitweise inkonsistent A Höherer Aufwand im Falle der Fehlererholung Cold standby: Sekundärsystem startet im Fehlerfall Unregelmäßige und eher seltene Zustandsicherung A Potentiell großer Abstand der Redundanzen A Potentiell langwierige Fehlererholung 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 23/38
61 Hardwarebasierte Replikation Hot standby: Rechensysteme arbeiten simultan Sie verarbeiten gleichzeitig dieselben Eingaben Ihr Zustand ist jederzeit konsistent A nahtloser Ersatz für ausgefallene Replikate Umsetzungsalternativen und Zustände Warm standby: Unterscheidung von Primär- und Sekundärsystem Sekundärsystem läuft im Hintergrund Regelmäßige Zustandssicherung (engl. checkpoint) des Primärsystems Rückkehr zur letzten Sicherung im Fehlerfall (engl. recovery) Primär- und Sekundärsystem sind zeitweise inkonsistent A Höherer Aufwand im Falle der Fehlererholung Cold standby: Sekundärsystem startet im Fehlerfall Unregelmäßige und eher seltene Zustandsicherung A Potentiell großer Abstand der Redundanzen A Potentiell langwierige Fehlererholung Fokus: Replizierte Systeme im hot standby -Betrieb 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 23/38
62 Beispiel: Steuerung des Space Shuttle [2] 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 24/38
63 Beispiel: Steuerung des Space Shuttle (Forts.) Insgesamt fünf redundante Rechensysteme [1, Kapitel 4.4] Ursprünglich gewünschte: fail-operational/fail-operational/fail-safe Verlust eines Kontrollrechners ändert nichts an der Funktionsfähigkeit Das Gesamtsystem behält immer noch die Eigenschaft fail-operational Das war jedoch zu teuer Reduktion auf vier Systeme Dies bedeutet fail-operational/fail-safe Das fünfte System war aber bereits überall eingeplant Es wurde zu einem Backup-System degradiert cold standby 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 25/38
64 Beispiel: Steuerung des Space Shuttle (Forts.) Insgesamt fünf redundante Rechensysteme [1, Kapitel 4.4] Ursprünglich gewünschte: fail-operational/fail-operational/fail-safe Verlust eines Kontrollrechners ändert nichts an der Funktionsfähigkeit Das Gesamtsystem behält immer noch die Eigenschaft fail-operational Das war jedoch zu teuer Reduktion auf vier Systeme Dies bedeutet fail-operational/fail-safe Das fünfte System war aber bereits überall eingeplant Es wurde zu einem Backup-System degradiert cold standby unterschiedliche Konfiguration der Rechner je nach Missionsabschnitt TMR nur im Steigflug bzw. Sinkflug Drei Systeme laufen simultan im hot standby -Betrieb Das vierte System läuft im warm standby Das fünfte System ist das Backup cold standby Während des Shuttle in der Umlaufbahn ist, wird die Redundanz reduziert Zwei System laufen weiterhin simultan Das dritte System übernimmt Lebenserhaltungssysteme,... Das vierte und fünfte Systeme sind Backup cold standby 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 25/38
65 Beispiel: Steuerung des Boeing 777 [7] Drei identische redundante Kanäle: links, mitte, rechts Bestehend aus jeweils drei diversitären redundanten Pfaden Räumliche Verteilung innerhalb des Flugzeugs Minimierung der Auswirkungen z. B. von Blitzschlägen 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 26/38
66 Beispiel: Steuerung des Boeing 777 [7] (Forts.) Mehrheitsentscheid beim Aktor ACE = actuator control electronics Die Aktoren selbst sind ebenfalls redundant 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 27/38
67 Mehrheitsentscheid am Aktor Am Beispiel von Rohrleitungen und Ventilen Jedes Replikat kontrolliert jeweils ein Ventil Vorgehensweise und Schaltfunktion ist hochgradig problemspezifisch Auch anwendbar auf elektronische Schaltkreise und Relais 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 28/38
68 Mehrheitsentscheid am Aktor Am Beispiel von Rohrleitungen und Ventilen Jedes Replikat kontrolliert jeweils ein Ventil Vorgehensweise und Schaltfunktion ist hochgradig problemspezifisch Auch anwendbar auf elektronische Schaltkreise und Relais Reihenschaltung von Absperrventilen Replikat 1 Replikat 2 Replikat 3 Um den Fluss zu stoppen, genügt ein korrektes Replikat 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 28/38
69 Mehrheitsentscheid am Aktor Am Beispiel von Rohrleitungen und Ventilen Jedes Replikat kontrolliert jeweils ein Ventil Vorgehensweise und Schaltfunktion ist hochgradig problemspezifisch Auch anwendbar auf elektronische Schaltkreise und Relais Reihenschaltung von Absperrventilen Replikat 1 Replikat 2 Replikat 3 Um den Fluss zu stoppen, genügt ein korrektes Replikat Parallelschaltung von Absperrventilen Replikat 3 Replikat 2 Replikat 1 Um den Fluss zu ermöglichen, genügt ein korrektes Replikat 4 Umsetzungsalternativen und Beispiele 4.1 Hardwarebasierte Replikation 28/38
70 Hardwarebasierte Replikation Vorteile und Nachteile Vorteile Sehr hohe Zuverlässigkeit bei richtigem Einsatz 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 29/38
71 Hardwarebasierte Replikation Vorteile und Nachteile Vorteile Sehr hohe Zuverlässigkeit bei richtigem Einsatz Nachteile Enorm hoher Hardwareaufwand Ein Großteil der Hardwarekomponenten wird redundant ausgelegt Hiermit direkt verbunden sind Hohe Kosten viel Hardware kostet viel Hohes Gewicht viel Hardware wiegt viel Hoher Energieverbrauch viel Hardware benötigt viel Energie 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 29/38
72 Hardwarebasierte Replikation Vorteile und Nachteile Vorteile Sehr hohe Zuverlässigkeit bei richtigem Einsatz Nachteile Enorm hoher Hardwareaufwand Ein Großteil der Hardwarekomponenten wird redundant ausgelegt Hiermit direkt verbunden sind Hohe Kosten viel Hardware kostet viel Hohes Gewicht viel Hardware wiegt viel Hoher Energieverbrauch viel Hardware benötigt viel Energie Die höhere Integrationsdichte moderner Hardware könnte uns helfen Auch wenn sie andererseits höhere Fehlerraten bedingt A Mehrkernprozessoren replizieren Rechenkerne Sie erlauben die Ausführung mehrerer Replikate auf demselben Prozessor 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 29/38
73 Process-Level Redundancy [5] Grundprinzip bleibt erhalten, nur der Inhalt der SoR ändert sich Es werden keine kompletten Rechenknoten mehr repliziert Sondern nur die Berechnung selbst, repräsentiert durch einen Prozess 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 30/38
74 Process-Level Redundancy [5] Grundprinzip bleibt erhalten, nur der Inhalt der SoR ändert sich Es werden keine kompletten Rechenknoten mehr repliziert Sondern nur die Berechnung selbst, repräsentiert durch einen Prozess Prozess 1 Prozess 2 Prozess 3 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 30/38
75 Process-Level Redundancy [5] Grundprinzip bleibt erhalten, nur der Inhalt der SoR ändert sich Es werden keine kompletten Rechenknoten mehr repliziert Sondern nur die Berechnung selbst, repräsentiert durch einen Prozess Eingabe Replikation der Eingaben Prozess 1 Prozess 2 Prozess 3 Abstimmung der Ausgaben Ausgabe Fehlertoleranzimplementierung Dedizierte Fehlertoleranzimplementierung sorgt für Replikation der Eingaben und die Abstimmung der Ausgaben Zeitliche Isolation der einzelnen Replikate 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 30/38
76 Process-Level Redundancy [5] Grundprinzip bleibt erhalten, nur der Inhalt der SoR ändert sich Es werden keine kompletten Rechenknoten mehr repliziert Sondern nur die Berechnung selbst, repräsentiert durch einen Prozess Eingabe Replikation der Eingaben Prozess 1 Prozess 2 Prozess 3 Abstimmung der Ausgaben Ausgabe Fehlertoleranzimplementierung Betriebssystem Mehrkernprozessor Dedizierte Fehlertoleranzimplementierung sorgt für Replikation der Eingaben und die Abstimmung der Ausgaben Zeitliche Isolation der einzelnen Replikate Basierend auf einem Echtzeitbetriebssystem Das räumliche Isolation sichert und Mehrkernprozessoren unterstützt 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 30/38
77 Process-Level Redundancy [5] (Forts.) Funktionsweise der Fehlertoleranzimplementierung Annahme: Replikate kommunizieren nach außen nur über Systemaufrufe Diese Annahme ist für Prozesse unter Linux durchaus valide 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 31/38
78 Process-Level Redundancy [5] (Forts.) Funktionsweise der Fehlertoleranzimplementierung Annahme: Replikate kommunizieren nach außen nur über Systemaufrufe Diese Annahme ist für Prozesse unter Linux durchaus valide Emulation der Systemaufrufschnittstelle Lesende Systemaufrufe Replikation der Eingabedaten So findet automatisch eine Einigung über die Eingaben statt Schreibende Systemaufrufe Ausgaben ffern & Mehrheitsentscheid Nicht zurücknehmbare Seiteneffekte sind problematisch Sie dürfen erst durchgeführt werden, wenn ihre Korrektheit gesichert ist 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 31/38
79 Process-Level Redundancy [5] (Forts.) Funktionsweise der Fehlertoleranzimplementierung Annahme: Replikate kommunizieren nach außen nur über Systemaufrufe Diese Annahme ist für Prozesse unter Linux durchaus valide Emulation der Systemaufrufschnittstelle Lesende Systemaufrufe Replikation der Eingabedaten So findet automatisch eine Einigung über die Eingaben statt Schreibende Systemaufrufe Ausgaben ffern & Mehrheitsentscheid Nicht zurücknehmbare Seiteneffekte sind problematisch Sie dürfen erst durchgeführt werden, wenn ihre Korrektheit gesichert ist Synchronisation der einzelnen Replikate Zu ähnlichen Zeitnkten werden identische Systemaufrufe getätigt Sofern sich die einzelnen Replikate korrekt verhalten Überwachung durch Ausgangsvergleich und durch Auszeiten Die Fehlertoleranzimplementierung weiß, wann Systemaufrufe stattfinden A Replikdeterminismus 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 31/38
80 Process-Level Redundancy [5] (Forts.) Funktionsweise der Fehlertoleranzimplementierung Annahme: Replikate kommunizieren nach außen nur über Systemaufrufe Diese Annahme ist für Prozesse unter Linux durchaus valide Emulation der Systemaufrufschnittstelle Lesende Systemaufrufe Replikation der Eingabedaten So findet automatisch eine Einigung über die Eingaben statt Schreibende Systemaufrufe Ausgaben ffern & Mehrheitsentscheid Nicht zurücknehmbare Seiteneffekte sind problematisch Sie dürfen erst durchgeführt werden, wenn ihre Korrektheit gesichert ist Synchronisation der einzelnen Replikate Zu ähnlichen Zeitnkten werden identische Systemaufrufe getätigt Sofern sich die einzelnen Replikate korrekt verhalten Überwachung durch Ausgangsvergleich und durch Auszeiten Die Fehlertoleranzimplementierung weiß, wann Systemaufrufe stattfinden A Replikdeterminismus Zeitliche Isolation durch Überwachung der Laufzeit Überschreitung der Laufzeit führt z. B. zum Ablaufen einer Auszeit 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 31/38
81 Vergleich mit TMR Vorteil: Hardwareaufwand wurde deutlich reduziert Nur ein Prozessor (mit mehreren Rechenkernen) Kein gesondertes Kommunikationssystem zwischen den Replikaten Damit sind direkt verbunden Geringere Kosten, Gewicht, Energieverbrauch 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 32/38
82 Vergleich mit TMR Vorteil: Hardwareaufwand wurde deutlich reduziert Nur ein Prozessor (mit mehreren Rechenkernen) Kein gesondertes Kommunikationssystem zwischen den Replikaten Damit sind direkt verbunden Geringere Kosten, Gewicht, Energieverbrauch Nachteil: Der Grad an Redundanz nimmt unweigerlich ab Fehler in gemeinsamen Teilen können zu Gleichtaktfehlern führen Prozessorcaches, Stromversorgung, Kommunikationssystem A Kompromiss aus Kosten und Nutzen 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 32/38
83 Vergleich mit TMR Vorteil: Hardwareaufwand wurde deutlich reduziert Nur ein Prozessor (mit mehreren Rechenkernen) Kein gesondertes Kommunikationssystem zwischen den Replikaten Damit sind direkt verbunden Geringere Kosten, Gewicht, Energieverbrauch Nachteil: Der Grad an Redundanz nimmt unweigerlich ab Fehler in gemeinsamen Teilen können zu Gleichtaktfehlern führen Prozessorcaches, Stromversorgung, Kommunikationssystem A Kompromiss aus Kosten und Nutzen Dennoch: Technologie der Zukunft Mehrkernprozessoren sind unaufhaltsam auf dem Vormarsch Erste dedizierte Mehrkernprozessoren im Automobilbereich Gleichzeitig: einzelne Rechenkerne sind nicht mehr sicher genug Transiente Fehlerrate macht Redundanz unvermeidbar 4 Umsetzungsalternativen und Beispiele 4.2 Softwarebasierte Replikation 32/38
84 Gliederung 1 Grundlagen Arten von Redundanz Einsatz von Redundanz 2 Strukturelle Redundanz Replikation Fehlerhypothese Voraussetzungen Nutzen Kritische Bruchstellen 3 Umsetzungsalternativen und Beispiele Hardwarebasierte Replikation Softwarebasierte Replikation 4 Diversität 5 Diversität 33/38
85 Beispiel: Ariane 5 (vgl. Folien II/16 ff) Beide Inertialmesssysteme SRI1 und SRI2 fallen gleichzeitig aus Ein Ganzzahlüberlauf wegen einer Eingabe außerhalb der Spezifikation A Die Bordcomter OBC1 und OBC2 interpretieren den Fehlerwert falsch A Fehlerhaftes Lenkmanöver führt zur Zerstörung der Rakete 5 Diversität 34/38
86 Beispiel: Ariane 5 (vgl. Folien II/16 ff) Beide Inertialmesssysteme SRI1 und SRI2 fallen gleichzeitig aus Ein Ganzzahlüberlauf wegen einer Eingabe außerhalb der Spezifikation A Die Bordcomter OBC1 und OBC2 interpretieren den Fehlerwert falsch A Fehlerhaftes Lenkmanöver führt zur Zerstörung der Rakete Ursache war ein Gleichtaktfehler in homogenen Redundanzen Softwaredefekte sind typische Quellen für Gleichtaktfehler Wie geht man mit Softwaredefekten um? A Wende Redundanz bei der Entwicklung solcher Systeme an! 5 Diversität 34/38
87 Beispiel: Ariane 5 (vgl. Folien II/16 ff) Beide Inertialmesssysteme SRI1 und SRI2 fallen gleichzeitig aus Ein Ganzzahlüberlauf wegen einer Eingabe außerhalb der Spezifikation A Die Bordcomter OBC1 und OBC2 interpretieren den Fehlerwert falsch A Fehlerhaftes Lenkmanöver führt zur Zerstörung der Rakete Ursache war ein Gleichtaktfehler in homogenen Redundanzen Softwaredefekte sind typische Quellen für Gleichtaktfehler Wie geht man mit Softwaredefekten um? A Wende Redundanz bei der Entwicklung solcher Systeme an! Diversität (engl. diversity) heterogene Redundanzen Auch N-version programming, mehr dazu siehe z. B. [4, Kapitel 6.6] Man nehme mehrere verschiedene von allem Entwicklungsteams, Programmiersprachen, Übersetzer, Hardwareplattformen Alle entwickeln dasselbe System in mehreren Ausführungen Annahme: Die Ergebnisse sind für sich wahrscheinlich nicht fehlerfrei A Aber sie enthalten wahrscheinlich auch nicht dieselben Fehler A Gleichtaktfehler dürften hier nicht mehr auftreten 5 Diversität 34/38
Zuverlässige Systeme Fehlertoleranz
Zuverlässige Systeme Fehlertoleranz frank@upb.de Inhalt Übersicht und Namenskonventionen Was ist Fehlertoleranz Eine Anleitung in 4 Phase Redundanz und Vielfältigkeit Hardwareseitige Fehlertoleranz Softwareseitige
Vorlesung "Verteilte Systeme" Sommersemester 1999. Verteilte Systeme. 13. Fehlertoleranz. Verteilte Systeme, Sommersemester 1999 Folie 13.
Verteilte Systeme 13. Fehlertoleranz Motivation Kunde () Verteiltes System = Redundanz Rechnern Kommunikationsnetzen Grundidee Einzelne Komponente k fällt mit einer Wahrscheinlichkeit p aus Ausfallwahrscheinlichkeit
Redundanz und Replikation
Redundanz und Replikation Fehlertoleranz auf Systemebene Kurt Kanzenbach Friedrich Alexander Universität Erlangen-Nürnberg 25. November 2014 1 / 29 Redundanz und Replikation Replikation Replikation: Koordinierter
Motivation für Fehlertoleranz in VS Fehlermodelle Erreichen von Fehlertoleranz. Verteilte Systeme. 7. Fehlertoleranz
7-2 Überblick Verteilte Systeme 7. Fehlertoleranz Sommersemester 2011 Motivation für Fehlertoleranz in VS Fehlermodelle Erreichen von Fehlertoleranz Ausfallsicherheit von Prozessen Zuverlässiger Remote
12 Fehlertoleranz. Begriffe
12 Fehlertoleranz ein verteiltes System beinhaltet viele Abstraktionsebenen, die stark voneinander abhängen. - z.b. hängt der Klient von seinem Server ab, der wiederum von seinen Diensten, etc. - die Kette
Strukturelle Redundanz
Strukturelle Redundanz bezeichnet die Erweiterung eines Systems um zusätzliche (gleich- oder andersartige) für den Nutzbetrieb entbehrliche Komponenten. Beispiele: 2-von-3-Rechnersysteme redundante Kommunikationskanäle
Verteilte Systeme F. Fehlertoleranz
Verteilte Systeme F. Fehlertoleranz Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.1 Fehlertoleranz Abhängigkeiten in einem verteilten System: Client! Server! Dienste! Software!
Entwurfsmuster und Softwarearchitekturen für sicherheitskritische Systeme
1 Entwurfsmuster und Softwarearchitekturen für sicherheitskritische Systeme Für das Seminar Analyse, Entwurf und Implementierung zuverlässiger Software Von: Andreas Seibel Betreut durch: Dr. Holger Giese
Modellbasierte Software- Entwicklung eingebetteter Systeme
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für offene Kommunikationssysteme FOKUS Folie
Fehlertoleranz in eingebetteten Systemen
Hauptseminar im SS 2006 Ausgewählte Kapitel eingebetteter Systeme (AKES) Fehlertoleranz in eingebetteten Systemen Vortragender: Thomas Klöber Betreuer: Olaf Spinczyk 1 / 11 Inhalt 1 Einführung... 3 2 Tolerieren
Design and Implementation of a Soft-error Resilient OSEK Real-time Operating System
Design and Implementation of a Soft-error Resilient OSEK Real-time Operating System Florian Lukas Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich Alexander Universität Erlangen
Datensicherheit und Hochverfügbarkeit
Datensicherheit und Hochverfügbarkeit 1. Instanzfehler Aussage: Instanzfehler werden durch Crash Recovery vom DBS automatisch behandelt. Recovery Zeiten? Ausfall von Speichersubsystem, Rechner,...? Ausfall
56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network.
56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen aktiv inaktiv Node 1 ( Aktiv ) Node 2 ( Passiv ) Private Network aktiv inaktiv (exklusiver Zugriff) Abbildung 3.1: Schematische Darstellung
Drehzahl- und Drehrichtungserfassung Richtungserkennung mit Hall-Schalter
Drehzahl- und Drehrichtungserfassung Richtungserkennung mit Hall-Schalter In vielen Anwendungsfällen müssen die Drehzahl und die Drehrichtung eines Motors bekannt sein. Diese Parameter können komfortabel
Ein einfaches Modell zur Fehlerfortpflanzung
Ein einfaches Modell zur Fehlerfortpflanzung Jens Chr. Lisner lisner@dc.uni-due.de ICB / Universität Duisburg-Essen AK Fehlertoleranz 11/2006 p. Problemstellung Üblich bei der Formalisierung von Systemen:
Vorlesung "Verteilte Systeme" Sommersemester 1999. Verteilte Systeme. Adreßraum. Rechner. Verteilte Systeme, Sommersemester 1999 Folie 19.
Verteilte Systeme 19. Distributed Shared Memory Sharing!! No Sharing! Sharing? Evolution der Berechnungsmodelle Vergangenheit Gemeinsamer Speicher Einzelrechner Gegenwart Nachrichtenkommunikation Verteilte
Fehlertolerante und Selbstheilende Systeme.
Fehlertolerante und Selbstheilende Systeme. Inhalt 1. 2. Fehlermodelle 3. Fehlertoleranztechniken 4. DCE (Dual Core Execution) 5. Fehlertoleranz 6. Zusammenfassung 2/29 Motivation Computer Aufgaben immer
(Miss-) Konzeptionen von Sicherheitsprinzipien
(Miss-) Konzeptionen von Sicherheitsprinzipien Jan-Tecker Gayen und Hendrik Schäbe IfEV, TU Braunschweig und TÜV Rheinland InterTraffic Gliederung Einführung Sicherer Zustand (Sicherheits-)Prinzipien Problemfelder
Bibliotheks-basierte Virtualisierung
Dr.-Ing. Volkmar Sieh Department Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2015/2016 V. Sieh Bibliotheks-basierte Virtualisierung (WS15/16)
Virtualisierung unter GNU/Linux für Einsteiger
Virtualisierung unter GNU/Linux für Einsteiger Edgar Fast Edi Hoffmann Community FreieSoftwareOG kontakt@freiesoftwareog.org 4. Oktober 2016 Virtualisierung Begriffserklärung 2 / 22 Virtualisierung Begriffserklärung
Modellbasierte Software- Entwicklung eingebetteter Systeme
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für offene Kommunikationssysteme FOKUS Folie
Vom Testkonzept zu JUnit
Testen und Testkonzept Dipl.-Inf. (FH) Christopher Olbertz 2. Dezember 2014 Testen und Testkonzept Warum testen? Wichtig, obwohl bei Programmierern unbeliebt Stellt weitgehend korrekte Funktionsweise eines
Wie groß ist die Page Table?
Wie groß ist die Page Table? Im vorigen (typischen) Beispiel verwenden wir 20 Bits zum indizieren der Page Table. Typischerweise spendiert man 32 Bits pro Tabellen Zeile (im Vorigen Beispiel brauchten
Modes And Effect Analysis)
Gefahrenanalyse mittels FMEA (Failure Modes And Effect Analysis) Vortragender: Holger Sinnerbrink Betreuer: Holger Giese Gefahrenanalyse mittels FMEA Holger Sinnerbrink Seite: 1 Gliederung Motivation Einordnung
Verteilte Systeme. Verteilte Systeme. 5 Prozeß-Management SS 2016
Verteilte Systeme SS 2016 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 31. Mai 2016 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/14) i
Verlässliche Systeme
Verlässliche Systeme RAID, Teil 2 Rachid El Abdouni Khayari Universität der Bundeswehr München, Neubiberg, Fakultät für Informatik, Institut für Technische Informatik Herbsttrimester 2004 Datenorganisation
Seminar. PG AutoLab. Verteilte Echtzeitsysteme. Sabrina Hecke. PG 522 Fachbereich Informatik Technische Universität Dortmund Lehrstuhl XII
PG AutoLab Seminar Verteilte Echtzeitsysteme Sabrina Hecke PG 522 Fachbereich Informatik Technische Universität Dortmund Lehrstuhl XII 21. bis 23. Oktober 2007 Inhaltsverzeichnis 1 Was sind Echtzeitsysteme?
Modellgestützte Analyse und Optimierung Übungsblatt 8
Fakultät für Informatik Lehrstuhl 4 Peter Buchholz, Jan Kriege Sommersemester 2015 Modellgestützte Analyse und Optimierung Übungsblatt 8 Ausgabe: 25.05.2015, Abgabe: 01.06.2015 (12 Uhr) Aufgabe 8.1: Berechnung
Fehlertoleranzmechanismen in hochverfügbaren Clustersystemen
Holger Sattel Seminar Rechnerarchitektur WS 2003/04 Universität Mannheim Lehrstuhl Rechnerarchitektur Prof. Dr. U. Brüning Inhaltsverzeichnis Grundlagen / Begriffe Fehlertoleranz Fehlertoleranz in (Rechen-)Clustern
Statistik I für Betriebswirte Vorlesung 2
Statistik I für Betriebswirte Vorlesung 2 Prof. Dr. Hans-Jörg Starkloff TU Bergakademie Freiberg Institut für Stochastik 11. April 2016 Prof. Dr. Hans-Jörg Starkloff Statistik I für Betriebswirte Vorlesung
Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz
Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit
Seminarvortrag: Hardware-Fehlertoleranz mit Hochverfügbarkeit
Seminarvortrag: Hardware-Fehlertoleranz mit Hochverfügbarkeit Agenda Motivation Hardware-Fehlertoleranz Checkpointing and Rollback Recovery Systemverfügbarkeit VM-basierte Systeme Remus Architektur Sicherung
Verteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7.
Verteilte Systeme SS 2015 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 7. Juli 2015 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i
Hochverfügbarkeit und virtualisierte Umgebungen
Hochverfügbarkeit und virtualisierte Umgebungen Hartmut Streppel Oracle Deutschland B.V. & Co. KG München Schlüsselworte Virtualisierung, Hochverfügbarkeit, Solaris Container, Solaris Zonen, Logical Domains,
Seminar: Fehlertolerante und Selbstheilende Systeme
Seminar: Fehlertolerante und Selbstheilende Systeme Juniorprofessor Dr. Holger Giese, Stefan Henkler, Matthias Tichy FG Softwaretechnik Raum E 3.165 Tele. 60-3321 [hg,mtt,shenkler]@upb.de Fehlertoleranz
Cacheoptimierung durch Anpassung der Speicheranordnung
Cacheoptimierung durch Anpassung der Speicheranordnung Seminar Zwischensprachen und Codeoptimierung, SS 2003 Matthias Heil Matthias Heil Cacheoptimierung durch Anpassung der Speicheranordnung p.1/21 Inhalt
PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08
PIWIN II Kap. 3: Verteilte Systeme & Rechnernetze 1 PIWIN II Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II Vorlesung 2 SWS SS 08 Fakultät für Informatik Technische
Klausur. Betriebssysteme SS 2007
Matrikelnummer: 9999999 Klausur FB Informatik und Mathematik Prof. R. Brause Betriebssysteme SS 2007 Vorname: Nachname: Matrikelnummer: Geburtsdatum: Studiengang: Bitte tragen Sie auf jeder Seite Ihre
das usa team Ziegenberger Weg Ober-Mörlen Tel Fax: mail: web:
Problemanalyse das usa team Ziegenberger Weg 9 61239 Ober-Mörlen Tel. 06002 1559 Fax: 06002 460 mail: lohoff@dasusateam.de web: www.dasusateam.de 1 Problem-Analyse Entscheidungen! Probleme! Manchmal ist
Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich
Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich WS 02/03 Warum muss ein Objekt wissen, zu welcher Klasse es gehört? Damit die Klassenzugehörigkeit
Virtualisierung in der Automatisierungstechnik
Virtualisierung in der Automatisierungstechnik Ihr Referent Jürgen Flütter on/off engineering gmbh Niels-Bohr-Str. 6 31515 Wunstorf Tel.: 05031 9686-70 E-Mail: juergen.fluetter@onoff-group.de 2 Virtualisierung
KRIWAN Condition Monitoring. Umfassender Schutz, effiziente Regelung und Diagnose für Hersteller und Betreiber von Maschinen
KRIWAN Condition Monitoring Umfassender Schutz, effiziente Regelung und Diagnose für Hersteller und Betreiber von Maschinen Umfassender Maschinenschutz: Effizienz + Sicherheit durch Condition Monitoring.
COPPER Best Practices
COPPER Best Practices Version 1.0.1 Wann sollte man überhaupt COPPER verwenden? Allgemein genau dann, wenn man von der COPPER Notation oder den COPPER-Features profitieren kann. Ein wesentliches Feature
Formale Grundlagen der Fehlertoleranz in verteilten Systemen
1/27 Formale Grundlagen der Fehlertoleranz in verteilten Systemen Felix Gärtner TU Darmstadt felix@informatik.tu-darmstadt.de 2/27 Bezug zur formalen Softwareentwicklung formale SE Definitionsphase Aufsplittung
Systemanforderungen Manufacturing Execution System fabmes
Manufacturing Execution System fabmes Das Manufacturing Execution System fabmes bemüht sich trotz hoher Anforderungen an die Datenverarbeitung möglichst geringe Anforderungen an die Hardware zu stellen.
CyPhyControl. Virtualisierte Ausführungsplattform für die zuverlässige Steuerung cyber-physikalischer Systeme
CyPhyControl Virtualisierte Ausführungsplattform für die zuverlässige Steuerung cyber-physikalischer Systeme Olaf Spinczyk Markus Buschhoff Boguslaw Jablkowski AG Eingebettete Systemsoftware Informatik
Zuverlässigkeit und Sicherheit
Beispiele Verfügbarkeit von Web-Services 24/7 Redundante Hardware (Rechner, Platten), um Verfügbarkeit zu erhöhen Flugzeugsteuerung, Space Shuttle/Ariane Redundante Hardware (Rechner, Platten), um Sicherheit
Verteilte Systeme CS5001
CS5001 Th. Letschert TH Mittelhessen Gießen University of Applied Sciences Einführung Administratives Unterlagen Verwendbar: Master of Science (Informatik) Wahlpflichtfach (Theorie-Pool) Unterlagen Folien:
Vertrieb datentechnischer Geräte
Geschäftsführer: Buchwiese 16 Telefon: 0 61 26 / 93 60-0 Eingetragen: Nassauische Sparkasse Wiesbaden UST.-ID-Nr. Gerichtsstand für Voll- Jörg Alberti 65510 Idstein/Ts. Telefax: 0 61 26 / 93 60-90 Amtsgericht
Vortrag zum Ergebnis der Literaturrecherche. Fehlerinjektion mittels Trace-Architektur auf einem Mips-Prozessor. Matthias Brinker
Vortrag zum Ergebnis der Literaturrecherche Fehlerinjektion mittels Trace-Architektur auf einem Mips-Prozessor Matthias Brinker Dresden, 27.10.2016 Gliederung 1. Einleitung und Motivation 2. Trace-Architektur
Produkte und Systeme der Informationstechnologie ENERGIE- MANAGEMENT
Produkte und Systeme der Informationstechnologie ENERGIE- MANAGEMENT Folie 1 VDE-Symposium 2013 BV Thüringen und Dresden Virtualisierung von Leittechnikkomponenten Andreas Gorbauch PSIEnergie-EE Folie
Software Engineering I Prof. Dr. Martin Glinz. Fallstudie: Ariane Flug 501. Universität Zürich Institut für Informatik
Software Engineering I Prof. Dr. Martin Glinz Fallstudie: Ariane Flug 501 Universität Zürich Institut für Informatik Was geschah mit Flug 501? So hätte es aussehen sollen......und so sah es tatsächlich
Beobachtung 1: Beispiel: Intuitive Programme sind oft ineffizient.
Beobachtung 1: Intuitive Programme sind oft ineffizient. Beispiel: void swap (int i, int j) { int t; if (a[i] > a[j]) { t = a[j]; a[j] = a[i]; a[i] = t; } } 731 Ineffizienzen: Adressen a[i], a[j] werden
25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz
1 2 Dies ist ein Vortrag über Zeit in verteilten Anwendungen Wir betrachten die diskrete "Anwendungszeit" in der nebenläufige Aktivitäten auftreten Aktivitäten in einer hochgradig skalierbaren (verteilten)
Echtzeit-Multitasking
Technische Informatik Klaus-Dieter Thies Echtzeit-Multitasking Memory Management und System Design im Protected Mode der x86/pentium-architektur. Shaker Verlag Aachen 2002 Die Deutsche Bibliothek - CIP-Einheitsaufnahme
<Insert Picture Here> RAC Architektur und Installation
RAC Architektur und Installation Elmar Ströhmer Michael Künzner Oracle Server Technologies Competence Center Agenda Überblick und Architekturen von HA-Systemen Hardware Die Basis
Redundantes Speichern
Redundantes Speichern Höchste Verfügbarkeit und größtmögliche Datensicherheit durch paralleles Speichern in EBÜS Status: Freigegeben Dieses Dokument ist geistiges Eigentum der Accellence Technologies GmbH
Verteilte Echtzeitsysteme
Verteilte Echtzeitsysteme Vortragender: Stefan Henkler Betreuer: Dr. Holger Giese 1 I. Motivation Vermehrter Einsatz eingebeteter Systeme Vernetzung Task t2 Task t1 Knoten k2 WLAN Knoten k1 Shuttle S2
VS2 Slide 1. Verteilte Systeme. Vorlesung 2 vom Dr. Sebastian Iwanowski FH Wedel
VS2 Slide 1 Verteilte Systeme Vorlesung 2 vom 15.04.2004 Dr. Sebastian Iwanowski FH Wedel VS2 Slide 2 Inhaltlicher Umfang dieser Vorlesung Inhaltliche Voraussetzungen: Programmieren, Grundkenntnisse Java
PC-Komponenten. Die Bestandteile eines Computers
PC-Komponenten Die Bestandteile eines Computers Unterschied Hardware & Software Hardware: Wird zur Darstellung von Programmen benötigt Vorrausetzung für Software Software: Die auf Hardware gespeicherten
Verteilte Systeme - 5. Übung
Verteilte Systeme - 5. Übung Dr. Jens Brandt Sommersemester 2011 Transaktionen a) Erläutere was Transaktionen sind und wofür diese benötigt werden. Folge von Operationen mit bestimmten Eigenschaften: Atomicity
Einsatz von Simulationen in der Softwareentwicklung
Einsatz von Simulationen in der Softwareentwicklung Dr. rer. nat. Olaf Maibaum Deutsches Zentrum für Luft- und Raumfahrt e.v. Simulations- und Softwaretechnik, Braunschweig Dr. Olaf Maibaum. DLR, Simulations-
Prof. Dr.-Ing. Dagmar Meyer Architekturen verteilter SW-Systeme 5 SYNCHRONISATION
Prof. Dr.-Ing. Dagmar Meyer 5 SYNCHRONISATION Warum braucht man Synchronisation? Ausgangssituation Prozesse müssen sich koordinieren / synchronisieren, z. B. beim Zugriff auf gemeinsame Ressourcen. Alle
Konzepte und Methoden der Systemsoftware. Aufgabe 1: Polling vs Interrupts. SoSe bis P
SoSe 2014 Konzepte und Methoden der Systemsoftware Universität Paderborn Fachgebiet Rechnernetze Präsenzübung 3(Musterlösung) 2014-05-05 bis 2014-05-09 Aufgabe 1: Polling vs Interrupts (a) Erläutern Sie
Modul Entscheidungsunterstützung in der Logistik. Einführung in die Programmierung mit C++ Übung 2
Fakultät Verkehrswissenschaften Friedrich List, Professur für Verkehrsbetriebslehre und Logistik Modul Entscheidungsunterstützung in der Logistik Einführung in die Programmierung mit C++ Übung 2 SS 2016
Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung
Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung Wintersemester 2009/10 Prof. Dr. Dr. h.c. Manfred Broy Unter Mitarbeit von Dr. K. Spies, Dr. M. Spichkova, L. Heinemann, P.
Servicebeschreibung Serverhousing physischer Kundensysteme in den zentralen Serverräumen des ZIM
Servicebeschreibung Serverhousing physischer Kundensysteme in den zentralen Serverräumen des ZIM Juni 2016 Inhaltsverzeichnis Allgemeine Servicebeschreibung...3 Erweiterte Servicebeschreibung...3 Voraussetzung
Stochastik und Statistik für Ingenieure Vorlesung 4
Prof. Dr. Hans-Jörg Starkloff TU Bergakademie Freiberg Institut für Stochastik Stochastik und Statistik für Ingenieure Vorlesung 4 30. Oktober 2012 Quantile einer stetigen Zufallsgröße Die reelle Zahl
(a) Wie unterscheiden sich synchrone und asynchrone Unterbrechungen? (b) In welchen drei Schritten wird auf Unterbrechungen reagiert?
SoSe 2014 Konzepte und Methoden der Systemsoftware Universität Paderborn Fachgebiet Rechnernetze Präsenzübung 2 2014-04-28 bis 2014-05-02 Aufgabe 1: Unterbrechungen (a) Wie unterscheiden sich synchrone
WCET-Analyseverfahren in der automobilen Softwareentwicklung
WCET-Analyseverfahren in der automobilen Softwareentwicklung Martin Däumler 1 Robert Baumgartl 2 Matthias Werner 1 1 Technische Universität Chemnitz 2 HTW Dresden 28. November 2008 M. Däumler et al (TUC,
Simple Scope. ecos-vertiefung. Florian Franzmann Tobias Klaus Peter Wägemann
Simple Scope ecos-vertiefung Florian Franzmann Tobias Klaus Peter Wägemann Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme und Betriebssysteme) http://www4.cs.fau.de
2. Braunschweiger Linux-Tage. Vortrag über RAID. von. Thomas King. http://www.t-king.de/linux/raid1.html. 2. Braunschweiger Linux-Tage Seite 1/16
2. Braunschweiger Linux-Tage Vortrag über RAID von Thomas King http://www.t-king.de/linux/raid1.html 2. Braunschweiger Linux-Tage Seite 1/16 Übersicht: 1. Was ist RAID? 1.1. Wo wurde RAID entwickelt? 1.2.
Dynamisches Huffman-Verfahren
Dynamisches Huffman-Verfahren - Adaptive Huffman Coding - von Michael Brückner 1. Einleitung 2. Der Huffman-Algorithmus 3. Übergang zu einem dynamischen Verfahren 4. Der FGK-Algorithmus 5. Überblick über
Virtueller Speicher. SS 2012 Grundlagen der Rechnerarchitektur Speicher 44
Virtueller Speicher SS 2012 Grundlagen der Rechnerarchitektur Speicher 44 Die Idee Virtuelle Adressen Prozess 1 Speicherblock 0 Speicherblock 1 Speicherblock 2 Speicherblock 3 Speicherblock 4 Speicherblock
Industrie-Automatisierung System HIMatrix
Industrie-Automatisierung System HIMatrix Hinweis zur redundanten Verwendung von HIMatrix HIMA Paul Hildebrandt GmbH Industrie-Automatisierung HI 800 365 ADA Wichtige Hinweise Alle in diesem Handbuch genannten
Vorlesung Rechnerarchitektur. Einführung
Vorlesung Rechnerarchitektur Einführung Themen der Vorlesung Die Vorlesung entwickelt an Hand von zwei Beispielen wichtige Prinzipien der Prozessorarchitektur und der Speicherarchitektur: MU0 Arm Speicher
Thread-Erzeugung kostengünstiger als Prozesserzeugung Thread-Umschaltung kostengünstiger als Prozessumschaltung
1.5 Threaded Server Server als ein Prozess mit mehreren Threads Threads Thread als Aktivitätsträger virtueller Prozessor eigener Programmzähler eigener Stackbereich eingebettet in den Kontext eines Prozesses
2010 DataCore Software Corp. All rights reserved
Desktop Server SAN DATACORE SPEICHERVIRTUALISIERUNG = HA + PERFORMANCE + SKALIERBARKEIT + FLEXIBLITÄT 1 Schmerzpunkte der Datenträger schnell veraltet Risiko des Totalausfalls niemals schnell genug immer
Die Sicht eines Sysadmins auf DB systeme
Die Sicht eines Sysadmins auf DB systeme Robert Meyer 21. Oktober 2016 Robert Meyer Die Sicht eines Sysadmins auf DB systeme 21. Oktober 2016 1 / 20 Inhaltsverzeichnis 1 Einleitung 2 IO unter Linux typische
Mikrocontroller. eine Einführung. Florian Schmitt - 16.11.2010 1 / 34
Mikrocontroller eine Einführung Florian Schmitt - 16.11.2010 1 / 34 Inhalt Was sind Mikrocontroller, wozu sind sie nützlich? Unterschiede und Gemeinsamkeiten mit dem PC Wie funktionieren Mikrocontroller
Modellbasierende Fehlerdiagnose für Automobile und Flugzeuge
Modellbasierende Fehlerdiagnose für Automobile und Flugzeuge Tobias Brandenburger Proseminar Künstliche Intelligenz Gliederung: 1. Motivation 2. Begriff: Fehleranalyse 3. Qualitative Modelle 4. KI-Methoden
Bedeutung der Metadateien. Alle Metadaten werden in Dateien gehalten. NTFS ist ein Journal-File-System
6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6.3 Metadaten 6.3 Metadaten (2) Alle Metadaten werden in Dateien gehalten Indexnummer 0 1 2 3 4 5 6 7 8 16 17 MFT
Leitfaden Datensicherung und Datenrücksicherung
Leitfaden Datensicherung und Datenrücksicherung Inhaltsverzeichnis 1. Einführung - Das Datenbankverzeichnis von Advolux... 2 2. Die Datensicherung... 2 2.1 Advolux im lokalen Modus... 2 2.1.1 Manuelles
J. Reinier van Kampenhout Robert Hilbrich Hans-Joachim Goltz. Workshop Echtzeit Fraunhofer FIRST
Modellbasierte Generierung von statischen Schedules für sicherheitskritische, eingebettete Systeme mit Multicore Prozessoren und harten Echtzeitanforderungen J. Reinier van Kampenhout Robert Hilbrich Hans-Joachim
IT-Infrastruktur für ORBIS-KIS mit ORBIS Notfallserver
GWI 2. IT-Services Innovationstag der PlanOrg Medica GmbH Donnerstag, 18. Mai 2006, im JEMBO Park Jena IT-Infrastruktur für ORBIS-KIS mit ORBIS Notfallserver Daten- und Ausfallsicherheit Referent: Ralph
VBA-Programmierung: Zusammenfassung
VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung
Einführung in die Informatik I (autip)
Einführung in die Informatik I (autip) Dr. Stefan Lewandowski Fakultät 5: Informatik, Elektrotechnik und Informationstechnik Abteilung Formale Konzepte Universität Stuttgart 24. Oktober 2007 Was Sie bis
Diplomarbeit. Entwurf eines TI-Coaching Systems. von. Christof Kuhn
Diplomarbeit Entwurf eines TI-Coaching Systems von Christof Kuhn Warum TI-Coaching System? Theoretische Informatik fällt vielen schwer Sie ist aber sehr wichtig für die Informatik Sie ist nicht wirklich
Software-basierter Speicherschutz durch spezialisierte Java-VMs auf Mikrocontrollersystemen
Software-basierter Speicherschutz durch spezialisierte Java-VMs auf Mikrocontrollersystemen Christian Wawersich Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Universität Erlangen-Nürnberg
Randomisierte Algorithmen: Ben-Or
Randomisierte Algorithmen: Ben-Or Literatur Michael Ben-Or: Another Advantage of Free Choice: Completely Asynchronous Agreement Protocols. Proc. 2nd ACM Symposium on Principles of Distributed Computing,1983
Diskrete Strukturen Kapitel 1: Einleitung
WS 2015/16 Diskrete Strukturen Kapitel 1: Einleitung Hans-Joachim Bungartz Lehrstuhl für wissenschaftliches Rechnen Fakultät für Informatik Technische Universität München http://www5.in.tum.de/wiki/index.php/diskrete_strukturen_-_winter_15
Prüfungsfragen. Kapitel 1:
Kapitel 1: 1. Was versteht man unter einem technischen Prozess? Was unter Prozessautomatisierung? Beispiele! 2. Arten von Prozessgrößen mit Beispielen nennen! 3. Welche Typen von Vorgängen gibt es in techn.
Interrupts. Funktionsprinzip. Funktionsprinzip. Beispiel in C
Interrupts Funktionsprinzip Interrupts bei ATmega128 Beispiel in C Funktionsprinzip 1 Was ist ein Interrupt? C muss auf Ereignisse reagieren können, z.b.: - jemand drückt eine Taste - USART hat Daten empfangen
Prozessportal. Neben Prozessbeschreibungen, bietet es sich an, Abläufe grafisch zu visualisieren.
Das Prozessportal der FHöV NRW Prozessportal Das Prozessportal bietet allen Mitarbeiterinnen und Mitarbeitern der der FHöV NRW die Möglichkeit, sich über bereits beschriebene und abgebildete interne Prozesse
sedex-client Varianten für den Betrieb in einer hoch verfügbaren
Département fédéral de l'intérieur DFI Office fédéral de la statistique OFS Division Registres Team sedex 29.07.2014, version 1.0 sedex-client Varianten für den Betrieb in einer hoch verfügbaren Umgebung
Life Cycle elektrischer Komponenten
Life Cycle elektrischer Komponenten Mario Fürst Siemens Functional Safety Professional «Life Cycle» elektrischer Komponenten Quelle: ZVEI, Oktober 2010, Life-Cycle-Management für Produkte und Systeme der
Redundanztechniken. Seminararbeit für den Masterstudiengang. Informatik. von. Kamo Azad. Vogeliusweg 25. 33100, Paderborn
Redundanztechniken Seminararbeit für den Masterstudiengang Informatik von Kamo Azad Vogeliusweg 25 33100, Paderborn 6147064 Paderborn, den 11. März 2006 1 Inhaltsverzeichnis 1 Einleitung 3 2 Begriffe und
Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH
Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting
Student: Alexander Carls Matrikelnummer: Aufgabe: Beschreibung des euklidischen Algorithmus Datum:
Berufsakademie Stuttgart / Außenstelle Horb Studienbereich Technik Studiengang Informationstechnik Kurs IT2006, 2.Semester Dozent: Olaf Herden Student: Alexander Carls Matrikelnummer: 166270 Aufgabe: Beschreibung
Semantik von Programmiersprachen
Semantik von Programmiersprachen Prof. Dr. Manfred Schmidt-Schauß SS 2013 Stand der Folien: 15. April 2013 Semantik von Programmen verschiedene Semantiken: operationale Semantik (Spezifikation eines Interpreters)