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 Shuttle S1 Kommunikation zwischen zwei Shuttle zur Einhaltung des zul. Abstands Problem: Ausfall einer Komponente Wie sollen Unfälle vermieden werden? Ist ein Fail State möglich? Wie lange sind die Daten (zeitl.) gültig? 2
Agenda I. Motivation II. Grundlagen und Konsistenzprobleme III. Architektur IV. Echtzeit Kommunikation V. Ausblick 3
II. Grundlagen Echtzeitsystem Verhalten ist abhängig von logischem Ergebnis + physischer Zeit Harte Deadline Hartes RT System (bzw. Sicherheitskritisches System) Zeitliche Anforderungen Max. Antwortzeit: Max. Intervall zwischen Stimulus und Antwort Charakteristiken von Applikationen Fail Safe: Erreichbarer Fail State muss vorhanden sein Computersystem (Knoten) mit hoher Fehlerentdeckung Fail Operational: Ein Fail State kann im Fall eines Fehlers nicht erreicht werden Computersystem (Knoten) muss minimalen Service nach Fehlerauftritt anbieten Fehlertolerante Systeme 4
Fehlertolerante Systeme Komponenten Fehler Katastrophe Fehlerermittlung a Priori über festgelegte Constraints und Wissen über das korrekte Verhalten der Berechnung Vergleich von redundanten Kanälen Realisierung Replikation der Knoten Fehlerentdeckung und Fehlermaskierung Architektur muss replica determism unterstützen gleiche Ergebnisse in Werte- und Zeit-Domäne 5
Fail Silent Knoten Client Anfrage Fehlertoleranz - Realisierung Triple Modular Redundanz Client Anfrage Verteilte Echtzeitsysteme Service Anbieter Server Antwort Service Anbieter Fehler- entdeckung Fehler- entdeckung Richtiges oder kein Ergebnis 2 aktive Knoten + Schatten Schattenknoten mit aktiven Knoten synchronisiert Vorteil Nach Fehler schnelles wiederherstellen der Redundanz Schatten benötigt keine zus. Bandbreite Redundanz bleibt während Reparatur erhalten Service Anbieter Service Anbieter Voter Server Antwort Service Anbieter Voter ermittelt richtiges Ergebnis Vorteil Vergleichsweise einfach zu realisieren Nur ein Ergebnis 6
State Arten Reintegration eines Knoten History-State (H-State): dynamische Datenstruktur, Veränderung mit Berechungsfortschritt, relevante Informationen für Knotenneustart Ground-State (G-State): Kein Task aktiv, Kommunikationskanäle leer, Minmaler H-State Initial-State (I-State): relevante Informationen für Knotenstart Selbsttest nach Knotenfehler Transienter Fehler beginne mit Reintegration Permanenter Fehler Dauerhafter transienter Fehler Reintegrationspunkt H-State Synchron mit Umgebung H-State Minimal 7
Real Time Entity, Image und Objekt Knoten k2 W L A N Knoten k1 Rad RT Entity RT Image RT Objekt RT Entity: Relevante Zustandsvariable Zustandsänderung ist eine Echtzeitfunktion Beobachtung: Atomares Triple <Name(RT Entity), t(obs), Wert(RT Entity)> Event und Zustandsbeobachtung RT Image: Aktuelles Abbild einer RT Entity Gültig solange akkurate Repräsentation gewahrt ist (Zeit-, Wert-Domäne) Spezifizierung des Gültigkeitsintervalls Basiert auf Beobachtung und/oder Zustandsbestimmung Speicherung innerhalb des Systems oder im Aktor 8
Knoten k2 RT Objekt: W L A N RT Objekt Knoten k1 Container für RT Image oder RT Entity Assoziiert mit einer RT Uhr Rad Granularität des Ticks muss mit Dynamik der RT Entity übereinstimmen Verteiltes RT Objekt: Replizierte RT Objekte verteilt an verschieden Stellen Jede lokale Instanz bietet spezifischen Service an Einhaltung spezifischer Constraints um Qualität des verteilten RT Objektes zu garantieren (z.b. Uhr Synchronisation mit spezifizierter Genauigkeit) Verteilte Echtzeitsysteme RT Entity RT Image RT Objekt 9
Kontrollbereich (sphere of control) Verteilte Echtzeitsysteme Kontrolliertes Objekt Rad Knoten k2 W L A N Knoten k1 Task t1 RT Entity RT Image RT Objekt WCETsend WCCOM WCETrec Real Time Jede RT Entity ist im Kontrollbereich (SOC) eines Subsystems Subsystem hat Autorität um den Wert der RT Entity zu setzen Ausserhalb SOC kann nur beobachtet werden (Veränderungen der Werte der RT Entity haben keine Auswirkungen) 10
Zeitliche Genauigkeit Verteilte Echtzeitsysteme WC Trans d acc t obs obs t i-k t i-1 t i=t =t use Real Time Bezugspunkt letzte Historie (recent history RH) der beobachteten RT Entity RH i zum Zeitpunkt t ist eine geordnete Menge von Zeitpunkten {t i, t i-1,..., t i-k } Länge d acc =z(t i )- z(t i-k ) gibt zeitl. Genauigkeit an RT Image ist zeitl. genau zum Zeitpunkt t i, wenn ex. t j Є RH i : Value(RT Image at t i ) = Value(RT Entity at t j ) Intervall der zeitl. Genauigkeit ist durch die Dynamik der RT Entity bestimmt WC Trans =t use -t obs = WCET send +WCCOM+WCET rec WC Trans >d acc Zustandsschätzung (state estimation) 11
Zustandsschätzung Verteilte Echtzeitsysteme Modellbildung einer RT Entity innerhalb eines RT Objekts um wahrscheinlichen zukünftigen Zustandswert der Entity zu berechnen Periodisch durch das RT Objekt ausgeführt, welches das RT Image speichert Periode wird durch Tick des RT Objekts bestimmt Erweitert zeitliches Genauigkeitsintervall des RT Image Bessere Übereinstimmung mit RT Entity Nur Anwendbar wenn Verhalten der RT Entity wohldefinierten chem./phys. Prozess unterliegt Beispiel: Berechnung der Bremsgeschwindigkeit 12
Klassifikation RT Image Verteilte Echtzeitsysteme d acc aktuelles RT Image d update : Update Periode t obs t update t trans t use Real Time Parametrisches RT Image d acc > (d update + WC Trans ) Phasensitives RT Image WC Trans < d acc <= (d update + WC Trans ) Zusätzliche Constraints für Scheduling 13
Knoten rec Nachrichten Nutzung WCCOM WCCOM Verteilte Echtzeitsysteme Knoten send A Knoten send B MCCOM t PermanentB COM Jitter =WCCOM =WCCOM - MCCOM t senda t sendb t recb t reca Wann wird Nachricht am Objekt O permanent? Alle Vorher gesendeten Nachrichten müssen am Objekt O eingetroffen sein Aktionsverzögerung: Intervall zwischen Absendezeitpunkt am Sender und Permanenzzeitpunkt am Receiver Wie lange dauert Aktionsverzögerung? Mit globaler Uhr: WCCOM + 2g (Sendezeitpunkt wird mitgesandt) Ohne globale Uhr: 2WCCOM MCCOM +gl Aktionsverzögerung > d acc Zustandsschätzung 14
III. Architektur Übersicht Verteilte Echtzeitsysteme Task t2 Task t1 Besteht aus einer Menge von Cluster Cluster besteht aus einer Menge von Fehlertoleranten-Einheiten (FTU) FTU besteht aus einem oder mehreren Knoten Host Computer Communication-Network Interface Communication Controller Knoten hat eine Menge von nebenläufig ausführbaren Tasks, die die gewünschte Funktion ausführen Knoten D Knoten B Knoten A RT Communication System Gateway RT Communication System Knoten E Knoten C Communication Controller + physische Verbindung ergibt das RT-Kommunikationssystem 15
Task Sequentielle Ausführung eines Programms Unterscheidung zwischen Simple Task (S-Task) und Complex Task (C-Task) C-Task beinhaltet ein Synchronisationselement ( wait ) Input Task ti compute H-State Output 16
Knoten Verteilte Echtzeitsysteme Hardware-Software Einheit mit wohldefinierter Funktion innerhalb des verteilten Computersystems Verhalten in zeitlicher- und Werte-Domäne CPU, Speicher I-State, H-State H und G-StateG Host Computer Communication-Network Interface Verbirgt Protokolllogik / Host Computer Fehlerentdeckung Communication Controller 17
Fehlertolerante-Einheit, Cluster, Gateway Fehlertolerante-Einheit Abstraktion zur Verwirklichung von Fehlertoleranz durch Replikation Besteht aus einer Menge von replizierten Knoten Cluster Menge von FTUs Gateway Austausch der relevanten Informationen zwischen zwei Cluster Besteht aus 2 CNIs 18
Architektur Eigenschaften Composability Eigenschaften des Subsystems dürfen bei Integration nicht verloren gehen Systemeigenschaften folgen aus den Subsystemeigenschaften Wird durch Kommunikationssystem erreicht Scalability Offen gegenüber Änderungen Erweiterbarkeit Knoten innerhalb Kanalkapazität hinzufügen Andernfalls Knoten als Gateway umfunktionieren Einschränkung der Komplexität Zuverlässigkeit Fehlerentdeckungszonen Replikation 19
IV. Echtzeit Kommunikation Anforderungen Kleine und vorhersagbare Protokollverzögerung Permanenz der Nachricht am Empfänger CNI Minimaler Jitter Multicast Kommunikation Zeitliche Kapselung der Knoten Unterstützung verschiedener Systemkonfigurationen Fehlerentdeckung 20
Flusskontrolle Verteilte Echtzeitsysteme Explizite Flusskontrolle Empfänger sendet Acknowledgement nach erhalt der Nachricht zum Sender Sender in SOC vom Empfänger Fehlerentdeckung beim Sender Implizite Flusskontrolle A Priori festlegen wann Nachrichten gesendet werden Benötigt globale Zeitbasis Fehlerentdeckung beim Empfänger Trashing Problem: Durchsatz wird verringert bei plötzlicher Zunahme der Last Implizite Flusskontrolle besser für RT Systeme 21
Event und Time Triggered Protokoll Verteilte Echtzeitsysteme ET Protokoll: Protokollausführung wird durch Event beim Sender ausgelöst Fehlerentdeckung liegt beim Sender Benötigt explizite Flusskontrolle Acknowledgement vom Empfänger zum Sender Erhöhte Netzbelastung TT Protokoll: Sendezeitpunkt einer Nachricht ist a priori festgelegt Fehlerentdeckung liegt beim Empfänger Unidirektional 22
Design Konflikt z.b. Flexibilität vs. Fehlerentdeckung a priori Verhalten festlegen ETP TTP 23
V. Aussichten OO Entwicklung (verteilter) eingebetteter Systeme (rtsj, drtsj) Einsatz von Standardkomponenten Kostenminimierung und schnellere Entwicklung Entwicklung wiederverwendbarer Software 24