Verlässliche Echtzeitsysteme
|
|
- Elke Kaiser
- vor 6 Jahren
- Abrufe
Transkript
1 Verlässliche Echtzeitsysteme Redundante Ausführung Fabian Scheler Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme und Betriebssysteme) www4.informatik.uni-erlangen.de 12. Juni 2012 Gliederung 2/39 Fragestellungen Maskierung transienter Hardwarefehler durch redundante Ausführung grundlegender Aufbau replizierter Systeme Auf welcher Ebene wird angewandt? Welche Eigenschaften müssen die einzelnen Replikate erfüllen? Triple Modular Redundancy die klassische Lösung für die Auslegung fehlertoleranter Systeme auf Ebene des Knotens bzw. der Hardware Fokussierung auf Triple Modular Redundancy prinzipiell sind n-fach redundante Systeme denkbar, n = 2,... Process-Level Redundancy redundante Ausführung unter Zuhilfenahme von Mehrkernprozessoren auf Ebene von Prozessen bzw. Software Vermeidung von Gleichtaktfehlern durch Diversität replizierte Entwicklung der einzelnen en Gliederung 3/39 4/39
2 Klassifikation Erinnerung: transiente Fehler (engl. transient faults) (s. Folie III/9) treten wie sporadische Fehler unregelmäßig auf... münden i. d. R. aber nicht in einem permanenten Fehler Datenfehler (SDC) und unkorrigierbare Fehler (DUE, s. Folie III/11) gutartiger Defekt Defekt korrigiert nein korrigiert gutartiger Defekt Fehlerhaftes Bit gelesen? nein nein Beeinflusst Ergebnis? ja (Quelle: Architecture Design for Soft Errors [4]) Bit abgesichert? ja SDC nein falscher DUE erkannt Beeinflusst Ergebnis? ja DUE Fehlervermeidung ungehemmte Fehlerfortpflanzung führt zum Systemversagen Datenfehler (engl. silent data corruption) 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 je nach Anwendung erforderlich Problematik: eine entsprechend robuste Auslegung einzelner Komponenten ist häufig nicht möglich diese Komponente müsste frei von konzeptionellen Fehler sein, also keinerlei Hardware- oder Softwaredefekte etc. enthalten sie müsste auch allerlei widrigen äußeren Umständen trotzen Lösung: man benötigt ein System, das einzelne Fehler tolerieren kann einzelne Komponenten können 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) 2.1 5/ /39 Fehlertoleranz durch Zustand redundanter Systeme Wie verhalten sich die redundanten Systeme zueinander? Fehlertoleranz erfordert immer räumliche typisch für hardwarebasierte Fehlertoleranzlösungen mehrfache Auslegung: Prozessoren, Speicher, Sensoren, Aktoren,... redundante Instanzen agieren häufig simultan zeitliche typisch für software-basierte Herangehensweisen meist wird nur die Berechnung redundant ausgeführt mehrfache, zeitlich versetzte Ausführung redundanter Komponenten funktionale mehrfache Herleitung desselben Sachverhalt auf verschiedenen Wegen Geschwindigkeit Drehzahlmesser bzw. Beschleunigungssensor orthogonal zu räumlicher und zeitlicher hot standby redundante Systeme arbeiten simultan sie verarbeiten gleichzeitig dieselben Eingaben ihr Zustand ist jederzeit konsistent nahtloser Ersatz für ausgefallene en warm standby Unterscheidung von Primär- und Sekundärsystem Sekundärsystem läuft im Hintergrund regelmäßige Zustandssicherung des Primärsystems (engl. checkpoint) Rückkehr zur letzten Sicherung im Fehlerfall (engl. recovery) Primär- und Sekundärsystem sind zeitweise inkonsistent höherer Aufwand im Falle der Fehlererholung cold standby Sekundärsystem startet im Fehlerfall unregelmäßige und eher seltene Zustandsicherung potentiell großer Abstand der en potentiell langwierige Fehlererholung Fokus: zeitlich und räumlich redundante Ausführung Fokus: redundante Systeme im hot standby -Betrieb 2.2 7/ /39
3 Ziel der Was man mit dem Mehraufwand eigentlich bezweckt! 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) 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: Fehlermaskierung ist der koordinierte Einsatz redundanter Elemente Anordnung in einer Sphere of Replication (SoR) [6] sie maskiert transparent Fehler in einzelnen Replikaten Eingabe der Eingaben Replikat 1 Replikat 2 Replikat n Vergleich der Ausgaben Eingaben werden repliziert und auf die Replikate verteilt in einem Ausgangsvergleich werden die Ausgaben abgestimmt Ausgabe Offene Fragestellungen: Wie viele Replikate benötigt man, um das zuverlässig tun zu können? Wie behebt man verbliebene kritische Bruchstellen? Was passiert bei Fehler in der Eingabe oder im Ausgangsvergleich? 2.2 9/39 10/39 Wie viele Replikate braucht man? Unter der Annahme, dass höchstens f Fehler auftreten? Zahl benötigter Replikate hängt von der Art des Fehlverhaltens ab [3] Annahme: von n Replikaten sind in folgender Weise f fehlerhaft fail-silent Anzahl der Replikate n = f + 1 ein Knoten erzeugt korrekt oder gar keine Antworten führt das Fehlerverhalten zum Stillstand des Knoten crash failure für einen Knoten der einfachste Fehlermodus werden alle anderen Replikate informiert, ist das ein fail-stop failure fail-consistent Anzahl der Replikate n = 2f + 1 ein Knoten kann auch fehlerhafte Antworten erzeugen alle anderen Knoten sehen konsistent dasselbe Fehlverhalten malicious Anzahl der Replikate n = 3f + 1 bösartige, fehlerhafte Knoten erzeugen verschiedene Antworten die übrigen Knoten haben keine konsistente Sicht auf das Fehlverhalten ggf. bekommt jedes Replikat eine andere (fehlerhafte?) Antwort Synonym: byzantinische Fehler (engl. byzantine failures) Wie viele Replikate braucht man? (Forts.) Vorabwissen kann helfen, die Zahl der Replikate zu reduzieren hohe Fehlererkennungsrate (engl. error detection coverage) das Fehlverhalten wird innerhalb des Knotens erkannt ein Ausbrechen des Fehler ist hier nicht tolerierbar umfasst sowohl Fehlverhalten im Wertebereich... falsche Eingabewerte oder Berechnungsergebnisse können beispielweise durch Zusicherungen abgefangen werden Durchführung häufig im Rahmen zyklischer Selbsttests als auch Fehlverhalten im Zeitbereich einzelne Aufgaben überschreiten ihre maximale Ausführungszeit quasselnde Idioten (engl. babbling idiot) überlasten das Kommunikationssystem durch zeitlich unkoordinierten Nachrichtenversand das korrekte Systemverhalten ist a-priori bekannt und kann genutzt werden, um fail-silent -Verhalten zu implementieren zwei Replikate reichen in diesem Fall aus, um einen Fehler zu tolerieren sonst: Mehrheitsentscheid liefert das korrekte Verhalten hierfür benötigt man dann ein drittes Replikat 11/39 12/39
4 Verbliebene kritische Bruchstellen kritische Bruchstellen (engl. single points of failure) führen zu einem beobachtbaren Fehlerfall innerhalb der kompromittieren also die fehlertolerierende Eigenschaft der SoR in der SoR auf Folie VII/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 Sensorfusion (engl. sensor fusion) repliziere den Ausgangsvergleich erneuter Mehrheitsentscheid über die Ergebnisse des replizierten Vergleichs 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 durch z. B. arithmetische Signaturen Durchführung des Mehrheitsentscheids durch den Aktor 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 13/39 14/39 Fehlerisolation Replikate fallen unabhängig voneinander aus 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 sind z. B.... Softwaredefekte und... das Übergreifen eines Fehlers auf andere Replikate einzelne Replikate sind gegeneinander abzuschotten ein Dienst, den die SoR zur Verfügung stellt 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 CPU ist zu verhindern ein Amok laufender Faden könnte in einer Schleife festhängen selbiges gilt für alle gemeinsamen Betriebsmittel 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 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) 15/39 16/39
5 Replikdeterminismus Korrekt arbeitende Replikate müssen identische Ergebnisse liefern. Replikate sind replikdeterministisch (engl. replica determinate), wenn sie ihr von außen beobachtbarer Zustand identisch ist, und... sie zum ungefähr gleichen Zeitpunkt 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! korrekte Replikate könnten 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 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 unterschiedliche Reihenfolge beobachteter Ereignisse unterschiedlicher zeitlicher Fortschritt der einzelnen Replikate Oszillatoren verschiedener Replikate sind nie exakt gleich 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 17/39 18/39 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 Zeitpunkt der Eingabe 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,... (engl. fault hypothesis) Annahmen über das Verhalten einzelner Replikate im Fehlerfall in der Praxis betrachtet man für Echtzeitsysteme Replikate, die... einen transienten Fehler tolerieren können sich fail-silent oder zumindest fail-consistent verhalten unabhängig voneinander ausfallen Gleichtaktfehler müssen also ausgeschlossen werden sich replikdeterministisch verhalten ermöglicht eine einfache Umsetzung des Mehrheitsentscheids 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 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 für Echtzeitsysteme ein nicht tolerierbarer zeitlicher Aufwand 19/ /39
6 Gliederung Triple Modular Redundancy (TMR) falls Fehler im Wertebereich nicht zu verhindern sind Eingabe Einigung der Eingaben Replikat 1 Replikat 2 Replikat 3 Mehrheitsentscheid Ausgabe üblicherweise dreifache kompletter Rechenknoten räumlich redundante Systeme im hot standby -Betrieb 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 vollständige zeitliche Isolation [5, Kapitel 8] und Replikdeterminismus Mehrheitsentscheid (engl. voter) stimmt Ausgabewerte ab Vereinigung von Fehlermaskierung und -erkennung 21/39 22/39 Wann hat TMR einen Nutzen? Hilft viel grundsätzlich viel? Beispiel: Steuerung des Space Shuttle [2] Erhöht sich durch TMR in jedem Fall die Zuverlässigkeit? anders formuliert: R tmr > R r? R tmr Zuverlässigkeit des TMR-Verbunds, R r des einzelnen Replikats der TMR-Verbund arbeitet korrekt, solange... der Mehrheitsentscheid korrekt funktioniert R v zwei Replikate korrekt funktionieren R 2/3 = R 3 r + 3R 2 r (1 R r ) alle drei Replikate arbeiten korrekt oder... ein Replikat fällt aus, hierfür gibt es drei Möglichkeiten insgesamt R tmr = R v (R 3 r + 3R 2 r (1 R r ) > R r? R sys 1.0 R sys = R r R sys = R tmr Annahme: perfekter Voter R v = TMR ist nur sinnvoll falls R r > 0.5 Praxis: Voter sollte zuverlässig sein Größenordnung R v > R r 23/39 24/39
7 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 reduziert zwei System laufen weiterhin simultan das dritte System übernimmt Lebenserhaltungssysteme,... das vierte und fünfte Systeme sind Backup cold standby 25/39 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 26/39 Beispiel: Steuerung des Boeing 777 [7] (Forts.) Gliederung Mehrheitsentscheid beim Aktor ACE = actuator control electronics die Aktoren selbst sind ebenfalls redundant 27/39 28/39
8 Vorteile und Nachteile von TMR Vorteile von TMR sehr hohe Zuverlässigkeit bei richtigem Einsatz Nachteile von TMR 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 Mehrkernprozessoren replizieren Rechenkerne sie erlauben die Ausführung mehrerer Replikate auf demselben Prozessor 29/39 Process-Level Redundancy [6] 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 der Eingaben Prozess 1 Prozess 2 Prozess 3 Fehlertoleranzimplementierung Betriebssystem Mehrkernprozessor Abstimmung der Ausgaben eine dedizierte Fehlertoleranzimplementierung sorgt für die der Eingaben und die Abstimmung der Ausgaben und die zeitliche Isolation der einzelnen Replikate hierfür greift sie auf ein Betriebssystem zurück das räumliche Isolation sichert und Mehrkernprozessoren unterstützt Ausgabe 30/39 Process-Level Redundancy [6] (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 der Eingabedaten so findet automatisch eine Einigung über die Eingaben statt schreibende Systemaufrufe Ausgaben puffern & 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 Zeitpunkten werden identische Systemaufrufe getätigt sofern sich die einzelnen Replikate korrekt verhalten Überwachung durch Ausgangsvergleich und durch Auszeiten die Fehlertoleranzimplementierung weiß, wann Systemaufrufe stattfinden Replikdeterminismus zeitliche Isolation durch Überwachung der Laufzeit Überschreitung der Laufzeit führt z. B. zum Ablaufen einer Auszeit 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 nimmt unweigerlich ab Fehler in gemeinsamen Teilen können zu Gleichtaktfehlern führen Prozessorcaches, Stromversorgung, Kommunikationssystem 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 unvermeidbar 31/39 32/39
9 Gliederung Rückblick: Ariane 5 (s. Folie II/18) beide Inertialmesssysteme SRI1 und SRI2 fallen gleichzeitig aus ein Ganzzahlüberlauf wegen einer Eingabe außerhalb der Spezifikation die Bordcomputer OBC1 und OBC2 interpretieren den Fehlerwert falsch fehlerhaftes Lenkmanöver führt zur Zerstörung der Rakete Ursache war ein Gleichtaktfehler in homogenen en Softwaredefekte sind typische Quellen für Gleichtaktfehler Wie geht man mit Softwaredefekten um? Wende bei der Entwicklung solcher Systeme an! Diversität (engl. diversity) heterogene en auch N-version programming, mehr dazu siehe z. B. [3, 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 aber sie enthalten wahrscheinlich auch nicht dieselben Fehler Gleichtaktfehler dürften hier nicht mehr auftreten 33/39 34/39 Diversität ist sehr umstritten! Problem: diese Annahme stimmt nicht unbedingt! Gleichtaktfehler verursachende Defekte rühren oft aus der Spezifikation diese betrifft alle diversitären Entwicklungsvorhaben gleichermaßen was auch auf die Ariane 5 zugetroffen hätte... verwende verschiedene Spezifikationen als Ausgangspunkt Wie bekommt man dann die verschiedenen Ausgaben unter einen Hut? dies erfordert komplexe Verfahren beim Mehrheitsentscheid exakte Mehrheitsentscheide (engl. exact voting) sind vergleichsweise trivial unscharfe Mehrheitsentscheide (engl. non-exact voting) sind aus heutiger Sicht hingegen nicht besonders vielversprechend... Diversität findet dennoch erfolgreich Anwendung (s. Folie VII/26) z. B. in asymmetrisch redundanten Systemen eine komplexe Berechnung wird durch eine einfache Komponente kontrolliert gepaart mit fail-safe-verhalten im Fehlerfall was bei Eisenbahnsignalanlagen sehr gut funktioniert z. B. in der Reaktornotabschaltung vieler Kernkraftwerke der Mehrheitsentscheid funktioniert nach dem Schema auf Folie VII/14 Gliederung 35/39 36/39
10 Zusammenfassung Toleranz von SDCs und DUEs hat mehrere Dimensionen Grundvoraussetzung für Fehlertoleranz räumlich, zeitlich, funktional,{hot, warm, cold} standby Fehlererkennung, -diagnose, -eindämmung, -maskierung koordinierter Einsatz von der Eingaben, Abstimmung der Ausgaben Replikate für fail-silent, fail-consistent, malicious zeitliche und räumliche Isolation einzelner Replikate Triple Modular Redundancy Hardwareredundanz dreifache Auslegung, toleriert Fehler im Wertbereich Zuverlässigkeit von Replikat und Gesamtsystem Process Level Redundancy TMR in Software reduziert Kosten von TMR, zulasten eines geringeren Schutzes Diversität versucht Gleichtaktfehler auszuschließen Literaturverzeichnis [1] Computers in Spaceflight: The NASA Experience. Apr [2] Carlow, G. D.: Architecture of the space shuttle primary avionics software system. In: Communications of the ACM 27 (1984), Nr. 9, S DOI / ISSN [3] Kopetz, H. : Real-Time Systems: Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers, ISBN [4] Mukherjee, S. : Architecture Design for Soft Errors. San Francisco, CA, USA : Morgan Kaufmann Publishers Inc., ISBN [5] Scheler, F. : Echtzeitsysteme /39 7 Bibliographie 38/39 Literaturverzeichnis (Forts.) [6] Shye, A. ; Moseley, T. ; Reddi, V. J. ; Blomstedt, J. ; Connors, D. A.: Using Process-Level Redundancy to Exploit Multiple Cores for Transient Fault Tolerance. In: Proceedings of the 37th International Conference on Dependable Systems and Networks (DSN 07). Washington, DC, USA : IEEE Computer Society Press, Jun ISBN , S [7] Yeh, Y. : Triple-triple redundant 777 primary flight computer. In: Proceedings of the 1996 IEEE Aerospace Applications Conference. Washington, DC, USA : IEEE Computer Society Press, Febr ISBN , S Bibliographie 39/39
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
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
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!
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
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
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
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?
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
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
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
Zeitgesteuerte Kommunikationssysteme für Hard-Real-Time Anwendungen. Jörn Sellentin
Zeitgesteuerte Kommunikationssysteme für Hard-Real-Time Anwendungen Jörn Sellentin Agenda Anforderungen an die Kommunikation in Fahrzeugen Verlässliche Kommunikation (Dependability) Fehlertoleranz (Fault
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
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
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
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
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:
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
Verteilte Systeme. Einführung. Prof. Dr. Oliver Haase
Verteilte Systeme Einführung Prof. Dr. Oliver Haase 1 Definition A distributed system is a collection of independent computers that appears to its users as a single coherent system. - Andrew Tanenbaum
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
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
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
Reaktive Systeme und synchrones Paradigma
Sascha Kretzschmann Freie Universität Berlin Reaktive Systeme und synchrones Paradigma Einführung in das Seminar über synchrone Programmiersprachen Worum geht es? INHALT 2 Inhalt 1. Einleitung - Wo befinden
Hochverfügbarkeit mit Windows Server vnext. Carsten Rachfahl Microsoft Hyper-V MVP
Hochverfügbarkeit mit Windows Server vnext Carsten Rachfahl Microsoft Hyper-V MVP Carsten Rachfahl www.hyper-v-server.de Roling Cluster Upgrade Herausforderung: Update eines Failover Clusters ohne Downtime
Moderne Betriebssysteme. Kapitel 8. Kapitel 8. Folie: 1. Multiprozessorsysteme. Autor: Andrew S. Tanenbaum
Moderne Betriebssysteme Kapitel 8 Multiprozessorsysteme Kapitel 8 Folie: 1 Multiprozessorsysteme Autor: Andrew S. Tanenbaum Pearson Studium 2009 2 3 4 5 6 7 Betriebssystemarten für Multiprozessoren Jede
Oracle Hot Standby. XE, SEOne, SE. Maximum Performance Mode. WIN, Linux, Unix Einfache Lösung. bis zu 10 Standby DB
Network Failure Management Graceful Switchover XE, SEOne, SE WIN, Linux, Unix Einfache Lösung Oracle Hot Standby Maximum Performance Mode 100% Java Kompression bis zu 10 Standby DB Die Oracle Experten
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
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
(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
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
RAID. Name: Artur Neumann
Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID
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
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
Überblick. 2 Bestandsaufnahme 2.1 Beispiele von verteilten Systemen 2.2 Anwendungsszenarien 2.3 Vorteile 2.4 Problembereiche
Überblick 2 Bestandsaufnahme 2.1 Beispiele von verteilten Systemen 2.2 Anwendungsszenarien 2.3 Vorteile 2.4 Problembereiche c rk,wosch,jk VS (SS 2015) 2 Bestandsaufnahme 2 1 Prozessorfarm @Google c rk,wosch,jk
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:
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
informiert Safety Integrity Level (SIL) Funktionale Sicherheit in der Anlageninstrumentierung Experience In Motion
informiert Safety Integrity Level (SIL) Funktionale Sicherheit in der Anlageninstrumentierung Mit Veröffentlichung der EN 12952 bzw. 53 im Dezember 2008 wurde auch für den Bereich der Ausrüstung von Dampf-
Lehrveranstaltung Speichersysteme Sommersemester 2009
Lehrveranstaltung Speichersysteme Sommersemester 2009 Kapitel 6: Double Disk Failures André Brinkmann Data CorrupDon in the Storage Stack Was sind Latent Sector Errors Was ist Silent Data CorrupDon Checksum
9: Verteilte Algorithmen
9: Verteilte Algorithmen Verteiltes System: Zusammenschluss unabhängiger Computer ( Knoten ), das sich für den Benutzer als einzelnes System präsentiert. (Begriffsbildung nach A. Tanenbaum hatten wir schon)
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
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
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
Fehlertoleranz auf Basis des Hypervisors
Fehlertoleranz auf Basis des Hypervisors Hendrik Borghorst 6. März 2013 Hendrik Borghorst Fehlertoleranz auf Basis des Hypervisors 1/45 1 Einleitung Fehlertoleranz durch Replikation 2 Replikation durch
Proling von Software-Energieverbrauch
Proling von Software-Energieverbrauch Seminar Ausgewählte Kapitel der Systemsoftwaretechnik: Energiegewahre Systemsoftware im Sommersemester 2013 Michael Fiedler 6. Juni 2013 1 Motivation (1) Grundproblem
Übersicht. Nebenläufige Programmierung. Praxis und Semantik. Einleitung. Sequentielle und nebenläufige Programmierung. Warum ist. interessant?
Übersicht Aktuelle Themen zu Informatik der Systeme: Nebenläufige Programmierung: Praxis und Semantik Einleitung 1 2 der nebenläufigen Programmierung WS 2011/12 Stand der Folien: 18. Oktober 2011 1 TIDS
Überblick über Oracle Technologie im Bereich Hochverfügbarkeit. Tage der Datenbanken FH Köln Campus Gummersbach 20. Juni 2013 Dierk Lenz
Überblick über Oracle Technologie im Bereich Hochverfügbarkeit Tage der Datenbanken FH Köln Campus Gummersbach 20. Juni 2013 Dierk Lenz Herrmann & Lenz Services GmbH Erfolgreich seit 1996 am Markt Firmensitz:
RAC auf Sun Cluster 3.0
RAC auf Sun Cluster 3.0 Schlüsselworte RAC, OPS, Sun Cluster, Performance, Availability Zusammenfassung Oracle hat mit dem Real Application Cluster (RAC) aus einer Hochverfügbarkeitslösung eine Höchstverfügbarkeitslösung
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
Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008
Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Jörg Rödel Virtualization - Whats out there? Virtualisierung hat bereits längere Geschichte auf x86 Startete mit VMware Setzte
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
Fehlertolerante verteilte Systeme, Peer-To-Peer Netzwerke
Fehlertolerante verteilte Systeme, Peer-To-Peer Netzwerke Hauptseminar im SS 2002 Hans Reiser, Rüdiger Kapitza Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Universität Erlangen-Nürnberg
Zero Effort Backup (ZEB) automatische Datensicherung über das Internet
Ralph Lehmann. Computerservice und IT-Beratung. Kochstraße 34. 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Kochstraße 34 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Tel.:
3. Stud.IP-Entwickler-Workshop 2. Juni 2006 Workshop 3c: Stud.IP-Enterprise-Edition André Noack, Frank Elsner
3. Stud.IP-Entwickler-Workshop 2. Juni 2006 Workshop 3c: Stud.IP-Enterprise-Edition André Noack, Frank Elsner Gliederung Das Problem: Skalierbarkeit LAMP Tuning Mehr als ein Server Stud.IP und shared nothing
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
Betriebssysteme Kap A: Grundlagen
Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten
Risiko- und Gefahrenanalyse und deren Berücksichtigung beim Entwurf von Sicherheitskritischen Systeme. Kelen-Yo Rodrigue
Risiko- und Gefahrenanalyse und deren Berücksichtigung beim Entwurf von Sicherheitskritischen Systeme Kelen-Yo Rodrigue Überblick Einleitung Präsentation des Neigemoduls des Shuttles Systemanforderungen
CORBA. Systemprogrammierung WS 2006-2007
CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA
Mailbox Cluster Konzepte
Ideen für grosse Mailstores Mailbox Cluster Konzepte Felix J. Ogris (fjo@dts.de) Version 1.0 2008-05-25 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis 1 Schema 4 2 Storage 5 2.1 Mailbox- und
Uhrensynchronisation. Dipl.-Inf. J. Richling Wintersemester 2003/2004
Uhrensynchronisation Dipl.-Inf. J. Richling Wintersemester 2003/2004 Motivation Zeit kann in Anwendungen eine große Rolle spielen, insbesondere bei Echtzeitsystemen Häufig wichtiger noch als korrekte Zeit:
Folie 1: Fehlerbaumanalyse (FTA) Kurzbeschreibung und Ziel Die Fehlerbaumanalyse im Englischen als Fault Tree Analysis bezeichnet und mit FTA
Folie 1: Fehlerbaumanalyse (FTA) Kurzbeschreibung und Ziel Die Fehlerbaumanalyse im Englischen als Fault Tree Analysis bezeichnet und mit FTA abgekürzt dient der systematischen Untersuchung von Komponenten
Military Air Systems
Trennung von Applikationen unterschiedlicher Kritikalität in der Luftfahrt durch Software en am Beispiel des Real-time Operating Systems PikeOS Dr. Bert Feldmann DGLR Workshop Garching, 09.10.2007 Seite
RAID Redundant Array of Independent [Inexpensive] Disks
RAID Redundant Array of Independent [Inexpensive] Disks Stefan Wexel Proseminar Algorithms and Data Structures im WS 2011/2012 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik
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.
Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank
Message Broker (MB) Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße
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.
TAV Übung 3. Übung 3: Verteilte Datenhaltung
Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.
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
Prozessindustrie EN 61508 / EN 61511. VL PLT2, SS 2012 Professur für Prozessleittechnik
Funktionale Sicherheit in der Prozessindustrie EN 6508 / EN 65 VL PL2, SS 202 Professur für Prozessleittechnik ik Übersicht PL-Schutzeinrichtungen Sicherheitsgrundnorm h it EN 6508 Funktionale Sicherheit
Parallelrechner (1) Anwendungen: Simulation von komplexen physikalischen oder biochemischen Vorgängen Entwurfsunterstützung virtuelle Realität
Parallelrechner (1) Motivation: Bedarf für immer leistungsfähigere Rechner Leistungssteigerung eines einzelnen Rechners hat physikalische Grenzen: Geschwindigkeit von Materie Wärmeableitung Transistorgröße
Grundlagen verteilter Systeme
Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern
Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems.
Das zeitliche Verhalten von Echtzeitsoftware zu analysieren und sicher zu stellen, dass die Anforderungen an das Echtzeitverhalten erfüllt werden kann sehr aufwendig und teuer sein. In diesem Artikel sollen
Verfügbarkeit von Applikationen und Failover Szenarien. Winfried Wojtenek. wojtenek@mac.com
Verfügbarkeit von Applikationen und Failover Szenarien Winfried Wojtenek wojtenek@mac.com Verfügbarkeit % Tage Stunden Minuten 99.000 3 16 36 99.500 1 20 48 99.900 0 9 46 99.990 0 0 53 99.999 0 0 5 Tabelle
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
Betriebssysteme K_Kap11C: Diskquota, Raid
Betriebssysteme K_Kap11C: Diskquota, Raid 1 Diskquota Mehrbenutzer-BS brauchen einen Mechanismus zur Einhaltung der Plattenkontingente (disk quotas) Quota-Tabelle enthält Kontingenteinträge aller Benutzer
Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim
Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,
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
Hochverfügbarkeit - wie geht das?
THINKIT DOIT ORBIT Hochverfügbarkeit - wie geht das? AGENDA Überblick Standby-Datenbanken FailSafe (Windows) Real Application Cluster (RAC) Architektur der Maximalen Verfügbarkeit Fragen? WAS IST HIGH
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
Dedup-Technik wie funktioniert es?
Dedup-Technik wie funktioniert es? v.1.3. Stand: Oktober 2010 Wiesbaden Deduplizierung Wie funktioniert es? 2 Inhalt Was ist Deduplizierung? Was bewirkt Deduplizierung? Source- Target- und Speichermanagement-Deduplizierung
Verteilte Datenbanken. Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München
Kapitel 8 Verteilte Datenbanken Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München 2008 Thomas Bernecker, Tobias Emrich unter Verwendung der Folien des Datenbankpraktikums aus dem Wintersemester
Lösungsskizzen zur Abschlussklausur Betriebssysteme
Lösungsskizzen zur Abschlussklausur Betriebssysteme 24. Januar 2013 Name: Vorname: Matrikelnummer: Studiengang: Hinweise: Tragen Sie zuerst auf allen Blättern (einschlieÿlich des Deckblattes) Ihren Namen,
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
I N F O R M A T I O N V I R T U A L I S I E R U N G. Wir schützen Ihre Unternehmenswerte
I N F O R M A T I O N V I R T U A L I S I E R U N G Wir schützen Ihre Unternehmenswerte Wir schützen Ihre Unternehmenswerte Ausfallsicherheit durch Virtualisierung Die heutigen Anforderungen an IT-Infrastrukturen
Informatik-Sommercamp 2012. Mastermind mit dem Android SDK
Mastermind mit dem Android SDK Übersicht Einführungen Mastermind und Strategien (Stefan) Eclipse und das ADT Plugin (Jan) GUI-Programmierung (Dominik) Mastermind und Strategien - Übersicht Mastermind Spielregeln
Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003
Task! evt. parallel zu bearbeitende Ausführungseinheit! Beispiel: Task A Zündung Task B Einspritzung Task C Erfassung Pedalwert Zeit t J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Echtzeitbetriebssysteme
Atomic Basic Blocks Eine kontrollflussunabhängige Zwischendarstellung für Echtzeitsysteme
Atomic Basic Blocks Eine kontrollflussunabhängige Zwischendarstellung für Echtzeitsysteme Fabian Scheler Martin Mitzlaff Wolfgang Schröder-Preikschat Informatik 4 Verteilte Systeme und Betriebssysteme
The Unbreakable Database System
The Unbreakable Database System Real Application Cluster Unterföhring, 04.2005 M. Kühn 1 Comparisson HA - HA Ziele, DataGuard, HA Oracle, RAC RAC Features - Cache Fusion, TAF, Load Balancing RAC on Solaris
Oracle Automatic Storage Management (ASM) Best Practices
Oracle Automatic Storage Management (ASM) Best Practices Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 Agenda ASM Funktionalität und Architektur Storage Management
Software Engineering. Sommersemester 2012, Dr. Andreas Metzger
Software Engineering (Übungsblatt 1) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Besonderheiten und Eigenschaften von Software; Interne und Externe Eigenschaften 1 Aufgabe 1.1 Software
Band M, Kapitel 7: IT-Dienste
Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0 E-Mail: Hochverfuegbarkeit@bsi.bund.de Internet: https://www.bsi.bund.de Bundesamt für Sicherheit
Unit Tests mit Junit 4. Dario Borchers
Unit Tests mit Junit 4 Dario Borchers Agenda Warum testgetriebene Entwicklung von Software? - Motivation Was ist testgetriebene Entwicklung? - Prozess der testgetriebenen Entwicklung - Arten von Tests
Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme
Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme Dipl.-Ing. Michael
Validierung und Verifikation
Martin Glinz Harald Gall Software Engineering Kapitel 7 Validierung und Verifikation Universität Zürich Institut für Informatik 2005, 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe
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
Performance Monitoring Warum macht es Sinn?
Performance Monitoring Warum macht es Sinn? achermann consulting ag Nicola Lardieri Network Engineer Luzern, 25.5.2011 Inhalt Definition Monitoring Warum Performance Monitoring? Performance Monitoring
Endorsed SI Anwenderbericht: Einsatz von System Platform 2012 R2 in virtualisierten Umgebungen zur Prozessvisualisierung
Endorsed SI Anwenderbericht: Einsatz von System Platform 2012 R2 in virtualisierten Umgebungen zur Prozessvisualisierung Fritz Günther 17.03.2014 Folie 1 Agenda Was ist Virtualisierung Server- / Clientvirtualisierung
VBA-Programmierung: Zusammenfassung
VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung
Fehlerdiagnose / Fehlerbehandlung
Lerneinheit Fehlerdiagnose / Fehlerbehandlung Inhaltsübersicht Diagnosefunktionen in STEP 7 Fehlerarten und dazugehörige Organisationsbausteine Arten von Organisationsbausteinen Ronald Kleißler Seite 1