Verteilte Echtzeitsysteme

Verteilte Echtzeitsysteme
Verteilte Echtzeitsysteme
Vortragender:
Stefan Henkler
Betreuer:
Dr. Holger Giese
1
Verteilte Echtzeitsysteme
I. Motivation
• Vermehrter Einsatz eingebeteter Systeme
• Vernetzung
Task t1
Task t2
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
Verteilte Echtzeitsysteme
Agenda
I.
II.
III.
IV.
V.
Motivation
Grundlagen und Konsistenzprobleme
Architektur
Echtzeit Kommunikation
Ausblick
3
Verteilte Echtzeitsysteme
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
Verteilte Echtzeitsysteme
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
Verteilte Echtzeitsysteme
Fehlertoleranz - Realisierung
Fail Silent Knoten
Client Anfrage
Service
Anbieter
Service
Anbieter
FehlerFehlerentdeckung
FehlerFehlerentdeckung
Server
Antwort
•
•
•
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
Triple Modular Redundanz
Client Anfrage
Service
Anbieter
Service
Anbieter
Service
Anbieter
Voter
Server
Antwort
• Voter ermittelt richtiges Ergebnis
Vorteil
• Vergleichsweise einfach zu
realisieren
• Nur ein Ergebnis
6
Verteilte Echtzeitsysteme
Reintegration eines Knoten
State Arten
• 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
Verteilte Echtzeitsysteme
Real Time Entity, Image und Objekt
Knoten k2
W
L
A
N
Knoten k1
RT Entity:
• Relevante Zustandsvariable
• Zustandsänderung ist eine
Echtzeitfunktion
Beobachtung:
• Atomares Triple <Name(RT Entity),
t(Obs), Wert(RT Entity)>
• Event und Zustandsbeobachtung
Rad
RT Entity
RT Image
RT Objekt
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
Verteilte Echtzeitsysteme
RT Objekt
Knoten k2
W
L
A
N
Knoten k1
Rad
RT Entity
RT Image
RT Objekt
RT Objekt:
• Container für RT Image oder RT Entity
• Assoziiert mit einer RT Uhr
• 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)
9
Verteilte Echtzeitsysteme
Kontrollbereich (sphere of control)
Kontrolliertes
Objekt
Knoten k2
W
L
A
N
Rad
WCETsend
•
•
•
WCCOM
Knoten k1
Task t1
RT Entity
RT Image
RT Objekt
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
Verteilte Echtzeitsysteme
Zeitliche Genauigkeit
WCTrans
dacc
tobs ti-k
•
•
•
•
•
ti-1 ti=tuse
Real Time
Bezugspunkt letzte Historie (recent history RH) der beobachteten RT Entity
RHi zum Zeitpunkt t ist eine geordnete Menge von Zeitpunkten {ti, ti-1, ..., ti-k}
¾ Länge dacc=z(ti)- z(ti-k) gibt zeitl. Genauigkeit an
RT Image ist zeitl. genau zum Zeitpunkt ti, wenn ex. tj Є RHi: Value(RT Image at ti)
= Value(RT Entity at tj)
Intervall der zeitl. Genauigkeit ist durch die Dynamik der RT Entity bestimmt
WCTrans=tuse-tobs = WCETsend+WCCOM+WCETrec
WCTrans>dacc
Zustandsschätzung (state estimation)
11
Verteilte Echtzeitsysteme
Zustandsschätzung
•
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
Verteilte Echtzeitsysteme
Klassifikation RT Image
dacc aktuelles RT Image
tobs
tupdate
ttrans
Parametrisches RT Image
• dacc > (dupdate + WCTrans)
dupdate: Update Periode
tuse
Real Time
Phasensitives RT Image
• WCTrans < dacc <= (dupdate + WCTrans)
¾ Zusätzliche Constraints für
Scheduling
13
Verteilte Echtzeitsysteme
Nachrichten Nutzung
WCCOM
WCCOM
Knotenrec
Knotensend A
Knotensend B
tPermanentB
COMJitter=WCCOM - MCCOM
MCCOM
tsendA tsendB
trecB
trecA
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 > dacc
Zustandsschätzung
14
Verteilte Echtzeitsysteme
III. Architektur – Übersicht
Besteht aus einer Menge von Cluster
Task t2
Cluster besteht aus einer Menge von
Fehlertoleranten-Einheiten (FTU)
Task t1
FTU besteht aus einem oder mehreren
Knoten
Host Computer
CommunicationCommunication-Network Interface
Communication Controller
Knoten hat eine Menge von nebenläufig
ausführbaren Tasks, die die gewünschte
Funktion ausführen
Knoten D
Knoten A
Knoten B RT Communication
System
Knoten C
Gateway
RT Communication
System
Knoten E
Communication Controller + physische Verbindung
ergibt das RT-Kommunikationssystem
15
Verteilte Echtzeitsysteme
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
Output
H-State
16
Verteilte Echtzeitsysteme
Knoten
•
•
Hardware-Software Einheit mit wohldefinierter Funktion innerhalb des
verteilten Computersystems
Verhalten in zeitlicher- und Werte-Domäne
CPU, Speicher
I-State , H-State und G-State
Host Computer
CommunicationCommunication-Network Interface
Verbirgt Protokolllogik / Host Computer
Fehlerentdeckung
Communication Controller
17
Verteilte Echtzeitsysteme
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
Verteilte Echtzeitsysteme
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
Verteilte Echtzeitsysteme
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
Verteilte Echtzeitsysteme
Flusskontrolle
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
Verteilte Echtzeitsysteme
Event und Time Triggered
Protokoll
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
Verteilte Echtzeitsysteme
Design Konflikt
• z.B. Flexibilität vs. Fehlerentdeckung
• a priori Verhalten festlegen
ETP
TTP
23
Verteilte Echtzeitsysteme
V. Aussichten
•
•
•
•
OO Entwicklung (verteilter) eingebetteter Systeme (rtsj, drtsj)
Einsatz von Standardkomponenten
Kostenminimierung und schnellere Entwicklung
Entwicklung wiederverwendbarer Software
24