1. Monitoring Distributed
Real-Time Systems:
A Survey and Future Directions
Maik Heller
MAI3 2010
16.12.2010
1
2. Gliederung
• 1.Problemstellung – Airbus 330 Flugsystem
• 2.Begriffsdefinitionen und Grundlagen
• 3.Monitore: Einführung und Forschungsstand
• 4.Monitor-Architekturen für verteilte Echtzeitsysteme
• 5. Wichtige zu überwachende Eigenschaften im Monitoring
• 6.Zusammenfassung und Ausblick
2
3. 1.Problemstellung – Airbus 330 Flugsystem
ADR: Air Data Reference
(Höhe, Geschwindigkeit)
Air Data
Inertial
Reference
Units Inertial Reference (IR)
(Flugbahn, GPS)
Flugcomputer
3 PRIMS
ADRIU 1 scheiterte:
-3 primäre Flugcomputer (PRIMS 1-3) -> Einer ist Master
Computer akzeptierte
Vorfall: Fehlerverhalten eines Master: Wechsel von PRIM 1 zu 2
aber korrupte Daten:
-PRIM 3 zeigt Fehler an: Crew schaltet von ADRIU 1 zu 3
->System scheiterte
Weiteres Fehlverhalten : Wechsel von PRIM 2 zu 1
->Kein Switchen 3
-Durch Fehlverhalten manuelle Flugkontrolle ->Notlandung
möglich
5. 2.1 Echtzeitsysteme (Real-time Systems)
• Ein Echtzeitsystem ist ein beliebiges System, bei
welchem die Zeit, zu der ein Output als Reaktion auf
einen Input erfolgt, von Wichtigkeit ist.
• Das Intervall zwischen Input-Zeit und Output -Zeit
muss dabei hinreichend klein sein, um eine
akzeptierbare Pünktlichkeit zu erzielen.
5
6. 2.1 Echtzeitsysteme (Intervallabhängigkeit)
-> Output ist nur korrekt, wenn er auch zu einem korrekten
Zeitpunkt erfolgt !
Unterscheidung in:
• Weiche Echtzeitsysteme:
– Die Ergebnisse von weichen Echtzeittasks sind nach der
Deadline weiterhin von Nutzen. Verursachen keinen Schaden.
– > z.B. Videostreaming mit Performanceeinbrüchen
(Bildfehler)
• Harte Echtzeitsysteme:
– Eine Überschreitung der Antwortzeit wird als ein Fehler
gewertet. Führt zum Scheitern des Systems.
– > z.B. Sicherheitskritisches System (Reaktor, Shuttle)
6
7. 2.2 Verteilte Echtzeitsysteme
• In einem verteilten Echtzeitsystem besteht das
Berechnungs-Cluster aus mehreren
Echtzeitcomputersystemen (Knoten), die über ein
Echtzeit- Kommunikationssystem verbunden sind.
• Antwortzeiten (Deadlines) des Kommunikationssystems 7
müssen zusätzlich eingehalten werden!
9. 2.3 Konzepte für fehlertolerante Systeme
• In einem verteilten Echtzeitsystem können Fehler auftreten
-Verlust einer Nachricht
-Fehlerhafte Nachricht
Ausfall eines Knotens / Komponente
->Fehler einer Komponente (fault) liefert Fehlerzustand (error) und führt zu
einem Fehlverhalten des gesamten Systems (failure)
• Fehlertoleranz:
– Hard- und Software-Fehler sollten das Echtzeitsystem nicht zum
Totalausfall führen
• Fehlerentdeckung:
– Wissen über das korrekte Verhalten der Berechnung
– Vergleich von zwei redundanten Kanälen (Pilot / Co-Pilot)
9
10. 2.3 Konzepte für fehlertolerante Systeme
• Eindämmungsbereiche: Fault-Containment Region (abk. FCR)
– Fehler in Knoten (faults) sollen eingedämmt werden
– Methode: physikalische Trennung der FCR, aber:
• Kommunizieren über gemeinsame Kanäle
• elektromagnetische Strahlung kann Funktion beeinträchtigen
• Einstufen von Fehlern nach Hybrid fault model (Thambiduarai, Park)
• Strukturierte Sammlung von Informationen, Probleme und Konsequenzen
– Basiert auf versendete Nachrichten von anderen Knoten
– Gutartiger Knoten: Versendet fehlerfreie Nachrichten (pass CRC-Check)
– Synchronisierte Systeme: Nachrichten zu unerwarteten Zeiten auch gut
– Symmetrischer Knoten: Gleiche Nachrichten zu jedem Empfänger, N. beliebig
– Asymmetrischer Knoten(byzantinisch): Unterschiedliche Nachrichten zu
unterschiedlichen Empfängern, 1 Botschaft nicht fehlerhaft
• Maximal fault assumption: MFA (NASA´s SPIDER, basiert auf HFM)
• Max Art, Anzahl und Empfangsrate von Fehlern für jeden FCR unter denen
System funktionieren soll
• Statistisches Modell: Zuverlässigkeit der Hardware, Umwelt, weitere Faktoren
10
• Flugverkehr:10 -9 Fehler pro Betriebsstunde -> sonst Gefahr
12. 3.1 Einführung Monitoring
• Fehlertolerante Konzepte in sicherheitskritischen
Systemen können scheitern! ->Monitoring notwendig
• Definition Monitor:
– Ein Monitor beobachtet das Verhalten eines Systems und
erkennt, wenn es im Einklang mit einer bestimmten
Spezifikation ist.
– Das überwachte System kann ein Programm, Hardware,
Netzwerk, oder jede Kombination sein
– Überwachte System: System under observation (SUO)
– Falls SUO die Spezifikationen verletzt -> Warnung ausgegeben
– Historisch: Monitoring auf funktionale Korrektheit ausgelegt
• Aber auch auf non-funktional, wie Leistung
12
13. 3.1 Einführung Monitoring
• Vergangenheit: Fokus auf off-line monitoring
– Datensammlung und Analyse erfolgt offline (nicht dynamisch)
• Fokus aktueller Forschung: Online-monitoring
– Spezifikation wird mit ausführten Programm dynamisch geprüft
(Praktisch: beim Testen, z.B. hohe Ressourcen)
• Online-Monitoring: Implementierung
– in-line: Monitor im Programmcode wie Kommentare
• Anna CCS: Aus Kommentare mit Eigenschaften werden
Funktionen generiert, arbeiten an dieser Stelle als Monitor
• JAVA 5:Grundlegende Behauptungen in Code möglich
– out-line: Monitor außerhalb des Programms als eigener Prozess
13
– Auch Kombination von out- und inline möglich
14. 3.2 Allgemeiner Forschungsstand des Monitoring
• Forschungsherausforderungen an online monitoring:
– Implementieren von effizienten Monitoren, welche mit
Verhaltensspezifizierungen höheren Ebenen synthetisiert werden
– Voraussetzung dafür: Monitor teilt Ressourcen mit beobachteten System
– Fokus der Synthese: Sicherheitseigenschaften aus „temporal logic“
(zeitabhängige Logik) zu gewinnen: wie z.B. „Es kann niemals was schlimmes
passieren“
• z.B. EAGLE: Regeln-basiertes Framework, mit LTL
– Effiziente Monitore aus linear temporal logic (LTL) generieren-> realtime Nasa rover
Forschung: Monitoring Java applications und erkennen von deadlocked threads
State-of-the-Art: MaC & MOP
Ausnahme für “C”: Requirement monitoring and recovery (RMOR) 14
-
15. 3.3 Forschungsstand Monitoring: MAC
• Monitoring and Checking (MaC) Framework
– Ziel: Weiche Echtzeitsysteme in Java
– Unterscheidung: in Integration und Monitor Aufgaben
• Out- oder in-line ->komplex Outline
– Sicherheitsspezifizierungen in Meta Event Definition Language
(MEDL) ->zeitliche Satzlogik von Ereignissen und Bedingungen
– Interpretiert über einen Pfad von Beobachtungen
• The Primitive Event Definition
Language (PEDL): definiert Ereignisse,
Mapping von Spezifikationen
• PEDL-Compiler: Input= Java
Implementierung und PEDl
Spezifizierung
• 2 Produkte: Filter(sensor):beobachtet
Monitor-Objekte;E.-R.:Erkennt
geschickte Ereignisse
• MEDL-Compiler: erzeugt Verifier,
überprüft ob Event R. MEDL 15
Spezifizierungen einhält
16. 3.4 Forschungsstand Monitoring: MOP
• MOP (Monitoring-Oriented Programming)
• Ein Software-Entwicklungs- und Analyse Framework
– Verringerung der Kluft zwischen formaler Spezifikation und
Implementierung durch bilden eines gemeinsamen Systems
– Laufzeitüberwachung als fundamentales Prinzip
– Monitore werden automatisch aus angegebenen Eigenschaften
synthetisiert
– Dynamisches Verhalten während Ausführung, bei Fehlverhalten
werden festgelegte Aktionen vom Nutzer ausgeführt->Self-recovery!
-JavaMOP: MOP Tool für
Java
BusMOP: MOP tool für
Monitoring consumer off-
the-shelf Produkte, über 16
den PCI buss
17. 3.5 Forschungsstand Monitoring: Verteilte Systeme
• Großteil der Forschung des Monitoring auf einheitliche,
monolithische Software
• Bauer: zentraler Ansatz
– Monitoring Ansatz für lokale Eigenschaften erfordert nur Verweis eines
Programms auf lokalen Knoten
– Jeder Knoten überprüft sicherheitstechnische Eigenschaften
– Sendet Bericht an zentrale Diagnose-Engine
– Versucht Ursprung des Problems zu diagnostizieren und in sicheren
Zustand zu lenken
• Bhargavan: Überwachung verteilter Netzwerkprotokolle, wie TCP
– Black-Box-Monitore: keine Kenntnisse des internen Zustands
– Zeigen Netzwerktraffic, mimen Protokollaktivitäten als Reaktion des
überwachten Inputs, vergleichen Output im Netzwerk
– NERL: Network Event Recognition Language, Spezifizierung der
Netzwerkereignisse mit spezialisierten Compiler
17
19. 4.1 Theorie: Monitoring verteilter Echtzeitsysteme Systeme
Argumentation:
Monitore für DRTs brauchen keine neue Theorieansatz,
subsumieren von aktuellen theoretischen Erkenntnissen
ist hinreichend
These: „Monitore für ein verteiltes System sind andere
Prozesse in einem verteilten System“
– Impliziert: gibt keine „allwissende“ Ansicht zu verteilten
Systemen
– Monitor (Benutzer oder Prozess) sammelt Informationen wie jeder
anderer Prozess im verteilten System
– Monitor hat mehr Privilegien: z.B. genauere physikalische Uhr,
direkte Kommunikationskanäle zu jedem Knoten
– >könnte aber jeder andere Prozess auch bekommen
19
20. 4.1 Theorie: Monitoring verteilter Echtzeitsysteme Systeme
• Konsequenzen für Monitoring DRT´s:
– Jede theoretische Begrenztheit für verteilte Systeme gilt auch für deren
Monitore
– Verteilte Systeme: gut entwickelt, fundamentale Grenzen für
Synchronisation, Fehlertoleranz, Fehlererkennung und Überwachung
• Jedoch Komplexität in Bezug zu Synchronisation und Fehlern:
– Macht verteilte Programmierung komplex
– 2 Formen der Synchronisation:
• Einfache Einigung: nach Reihenfolge der Ereignisse: logical clock
synchronization
• bei echter Zeit(wall-clock time), synchr. mit physikalischen Uhren
– Uhren können sich aber nur in einem kleinen Zeitfenster synchronisieren
– Fehler: Monitor selbst auch fehleranfällig: erkennt Fehler in SUO, kann
aber auch an welchen erleiden ->“babbling monitor“: Sendet kont. 20
Fehler an System
21. 4.2 Hardware- / Softwareunterscheidung
• Monitor-Ansätze werden in Hard – und Softwarelösungen unterschieden, bisher
wurden Softwareansätze diskutiert
• Unterscheidung für fehlertolerante Echtzeitsysteme weniger nützlich, sowohl aus
Echtzeit, als auch fehlertoleranten Aspekten heraus
• Echtzeitgarantien sind abhängig von Verhalten
von Soft- und Hardware
• Einseitige Monitore nicht praktikabel
->Wahrscheinlichkeitsaussage ob Hardware oder
Softwarefehler
• Deutlich oder öfters Frist nicht eingehalten
Logikfehler ist wahrscheinlicher als
Hardwarefehler
• Einzelfallbetrachung nicht ausreichend zur
Analyse von Fehlern
• ->Wahrscheinlichkeitsmodelle mit Variablen der 21
Umwelt und Ausfallrate der Hardware
22. 4.3 Anforderungen an Monitor Architekturen
• Monitor-Architektur: Integration von einen oder mehreren Monitoren in
das SUO (System Under Observation)
• Die Architektur schließt die ganze zusätzliche Hardware & Verbindungen
ein, die erforderlich sind, die Überwachung auszuführen.
• Welche Anforderungen müssen Monitorarchitekturen erfüllen?:
• 1.Funktionalität: Der Monitor ändert nichts an der Funktionalität des SUO
bis das SUO seine Spezifikationen verletzt.
• 2.Planbarkeit: Die Monitor-Architektur veranlasst das SUO nicht, seine
harten Echtzeitgarantien zu verletzen, es sei denn, dass das SUO seine
Spezifizierung verletzt.
• 3.Zuverlässigkeit: Die Zuverlässigkeit der SUO, im Rahmen der Monitor
Architektur, ist größer oder gleich der Zuverlässigkeit der SUO alleine.
• 4.Zertifizierbarkeit: Die Monitor-Architektur erfordert nicht übermäßig
Änderungen am Quellcode oder Objektcode der SUO. 22
23. 4.4 Monitor – Architekturen für verteilte Echtzeitsysteme
• Welche potentiellen Monitorarchitekturen kommen
für verteilte Echtzeitsysteme in Frage?
• 3 abstrakte Monitorarchitekturen welche die 4
Anforderungen erfüllen
• Architekturen sind auf konzeptionelle Ebene:
– Können in zukünftigen Studien untersucht werden
• Abbildungen zeigen verteilte SUO mit Monitor-
Architektur
– Monitorarchitektur mit Reihe verteilter Prozesse x1, x2… xn in
Verbindung mit Leiterbahn
23
24. 4.4 Monitor – Architekturen für verteilte Echtzeitsysteme
Bus-Monitor Architektur
– Monitor überwacht Verkehr am Datenbus des SUO
– Empfängt Nachrichten wie jeder andere Prozess
– Stille Teilnehmer: zusätzliche Fehlerprüfung oder prüfen der
Einhaltung des Kommunikationsprotokoll
– Nur bei katastrophalen Fehler sendet es Nachrichten zu den
Prozessen durch den Bus
• Einfach: Realsierung durch
Peripherie-Hardware
• Siehe Bhargavan: TCP-Pakete
abfangen
• Begrenzt: Beurteilt nur Aktivitäten
im Bus, SUO könnte es selber regeln
24
• commercial-off-the-shelf Produkte
25. 4.4 Monitor – Architekturen für verteilte Echtzeitsysteme
Single-Process Monitor Architektur
• Bus zu teilen kann zu Fehlern führen, falls Monitor defekt ist
und Bus mit Nachrichten flutet
• Jeder Prozess und einzelner Monitor ist an Datenbus
angebunden
• Einzelner Prozess sendet Daten zu einzelnen Monitor zum
Vergleich -> Monitor signalisiert Prozess Fehler
• Separater Monitor Bus zur
Überwachung der Nachrichten
• Monitor gefährdet nicht
Kommunikation und SUO,
Designfehler werden reduziert
25
26. 4.4 Monitor – Architekturen für verteilte Echtzeitsysteme
Distributed Process - Architektur
– Verteilte Monitor: M0 … Mn überwacht Prozess x0... xn
– Monitor Mi auf gleicher Hardware wie Prozess xi (günstigere
Hardwarekosten) oder FCR (sicherer da physikalisch getrennt)
– Monitor-Verbindung kann Fehlertolerant sein, auch wenn SUO
Verbindung es nicht ist -> Fehlertoleranz wird garantiert
– Verteilte Online-Monitore müssen kommunizieren
->Einigungen zu Diagnosen
• Vergleich zu Single Process Architektur:
Zuverlässige Kontrolle, da Monitore verteilt
• Beschützer: Monitor Mi als Vormund eines Prozess xi
• „Plapper“-Prozess kann nicht wie Single-Process
Monitor Architektur alles blockieren
• Komplexität kann Zuverlässigkeit des Monitor 26
reduzieren, Aufwand ist so hoch wie SUO selbst
28. 5.1 Rückblick Problemstellung MFA
Was soll in Monitoren überwacht werden?
• Sicherheitskritische Systeme können durch Design-Fehler (systematische Fehler) scheitern,
z.B. durch falsche Architekturkonzepte ->Hier muss Monitoring ansetzen
Rückblick MFA: Konzeption Fehlertoleranter Systeme
• Sicherheitskritische Systeme wurden entworfen um MFA (max Fehler-Annahme) stand zu
halten, stat. Einbezug von Umweltkriterien
• Faktoren sind zur Designzeit der Systeme unterspezifiziert -> System wird nach geschätzter
Betriebszeit weitergenutzt oder für andere Aufgaben verwendet
• MFA: Besteht Annahme, dass keine systematischen Softwarefehler existieren -> Designer
unterschätzen die MFA, die zur Erreichung der gewünschten Zuverlässigkeit benötigt wird
• Geschätzte Zuverlässigkeit < tatsächliche Zuverlässigkeit
28
• Lösung durch Monitore?
29. 5.2 Monitoring Konsens Verletzungen –
„Fault-Model“ - Verletzungen
• Monitor Konsens (Übereinstimmung der Kommunikation):
• Monitor kann (fehlenden) Konsens zwischen verteilten Komponenten
feststellen
• Ziel des Konsens: Jeder Empfänger einer Broadcast-Nachricht erhält
den selben Wert
• Überwachung des Konsens während der Laufzeit:
– Empfangene Werte müssen überprüft werden
– Exakte Übereinstimmung: Jeder Empfänger bekommt gleichen Wert
– Geschätzte Übereinstimmung: Empfänger bekommt ungefähren Wert,
welcher innerhalb eines kleinen Delta liegt
• Im Fokus: Asymmetr./Byzantischer Fehler (wurden ausgeschlossen!)
– Empfänger tauschen Nachrichten aus, um Werte zu vergleichen und Konsens
zu garantieren ->Problem des Konsens
– Monitore können je nach Architektur zur Lösung beitreten:
– Bus-Architektur: - Broadcast-Nachrichten: Monitor nur weiterer Empfänger
– Single-Process: + Jeder Knoten zu Monitor verbunden 29
– Distrubuted-Process: ++ Jeder Knoten einen Monitor
30. 5.3 Monitoring Konsens Verletzungen –
„Point-to-Point Error-Checking“
• Punkt-zu-Punkt Fehlerprüfung weißt dem Empfänger nach, falls eine
Nachricht während der Übertragung beschädigt wurde
• CRC s (cylic redundant checks) ist das Standard-verfahren um
Punkt-zu-Punkt Kommunikationsfehler zu finden
– Können Burstfehler oder zufällige Bitfehler sein
– Einfach in Hardware zu implementieren
– Einsatz in embedded-systems
• CRC´s arbeiten jedoch nicht ulta-zuverlässig
– Hauptproblem: Netzwerkkapselung fälscht CRC-Sequenzen
(Schrödingers CRC)->Problem des byzantinischen Fehlers
– Falsche Nachrichten werden als fehlerfrei „erkannt“
• Lösung: Architektur fehlertolerant (re)designen, eigener Bus
– Optimierung: Monitore mit CRC-Check implementieren
– Vorteil: CRC braucht weniger Bandbreite als die Nachricht
– Spezielle Monitoring-Nachrichten von Knoten zu Monitor 30
31. 5.4Monitoring Konsens Verletzungen –
„Timing violations “
• Harte Echtzeitsysteme liefern Echtzeitzeitgarantien, wenn Timing-
Annahmen vom System gehalten werden, wenn Bedingungen
(Constraints) wie:
– Nachrichtenverzögerung, Resynchronisation, …
eingehalten werden.
• Bedingungen können nicht direkt überwacht werden
– Ein Monitor hat nicht mehr Möglichkeiten als das SUO
– Constraints verbinden im Wesentlichen die Werte von lokalen
Hardware-Uhren zu einander und zur "echten" ("wall-clock")
physischen Zeit.
– Monitore können nur Abwesenheit von Fehlern aufzeigen
– Fehlerursache (Hard-Software) kann nicht bestimmt werden
– Lösung: Monitore mit Wahrscheinlichkeitsmodellen
• Erfordern aber korrekte Umweltvariablen 31
32. 6.Zusammenfassung
• Was sind Monitore?
– Input: Lokale Zustands-Abbildungen der einzelnen Knoten/Prozesse
– Daten sind fehlerbehafte Wahrscheinlichkeiten und Ansammlung von
Zustandszeiten
– Zustand ist von relativer Häufigkeit
– Output ist eine Konsens Verletzung
• Vorteile von Monitoren:
– Ultra - Sicherheitskritische Systeme profitieren von neuen Ansätzen, in
Verbindung zu vorgestellten Architekturen
– Überwachung der vorgestellten Konsensklassen deckt einen Großteil der
auftretenden Fehler ab
– Erfolgreiche Monitore erfordern auch ein entsprechende Hardwarearchitektur
• Zukunft: Zwei potentielle Architekturen:
• Verteilt:
– Monitore sind verteilten Knoten und tauschen Konsens-Daten aus
• Zentral:
– Knoten senden Konsens-Daten zu einem zentralen Monitor
• Folge: Monitorkonzepte und Architekturen nach Verwendungszweck
• Kombinieren verschiedener Architekturen 32
