SlideShare ist ein Scribd-Unternehmen logo
1 von 32
Monitoring Distributed
          Real-Time Systems:
A Survey and Future Directions
                       Maik Heller
                       MAI3 2010
                       16.12.2010
                                 1
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
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
2.Begriffsdefinitionen und Grundlagen
• 2.1 Echtzeitsysteme
• 2.2 Verteilte Echtzeitsysteme
• 2.3 Konzepte für fehlertolerante Systeme




                                             4
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
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
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!
2.2 Verteilte Echtzeitsysteme – Bsp. Flugzeug




                                                8
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
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
3. Monitoring: Einführung und Forschungsstand

•   3.1 Einführung Monitoring
•   3.2 Allgemeiner Forschungsstand des Monitoring
•   3.3 Forschungsstand Monitoring: MAC
•   3.4 Forschungsstand Monitoring: MOP
•   3.5 Forschungsstand Monitoring: Verteilte Systeme




                                                        11
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
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
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

        -
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
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
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
4.Monitor-Architekturen für verteilte Echtzeitsysteme



•   4.1 Theorie: Monitoring verteilter Echtzeitsysteme Systeme
•   4.2 Hardware- / Softwareunterscheidung
•   4.3 Anforderungen an Monitor Architekturen
•   4.4 Monitor – Architekturen für verteilte Echtzeitsysteme




                                                            18
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
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
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
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
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
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
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
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
5. Wichtige zu überwachende Eigenschaften im Monitoring



• 5.1 Rückblick Problemstellung MFA
• 5.2 Monitoring Konsens Verletzungen -
  „Fault-Model“ - Verletzungen
• 5.3 Monitoring Konsens Verletzungen –
  „Point-to-Point Error-Checking“
• 5.4Monitoring Konsens Verletzungen –
  „Timing violations “


                                                      27
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?
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
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
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
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

Weitere ähnliche Inhalte

Andere mochten auch

Definiciones
DefinicionesDefiniciones
DefinicionesAnylara
 
IID-Designprojekt Präsentation
IID-Designprojekt PräsentationIID-Designprojekt Präsentation
IID-Designprojekt PräsentationGexTM
 
Presentacion evaluacion3
Presentacion evaluacion3Presentacion evaluacion3
Presentacion evaluacion3Ines_Santiago
 
Netbiscuits - 9 Tipps
Netbiscuits - 9 Tipps Netbiscuits - 9 Tipps
Netbiscuits - 9 Tipps Daniel Haller
 
Mobile Strategy / Apps, WebApps, HybridApps
Mobile Strategy / Apps, WebApps, HybridAppsMobile Strategy / Apps, WebApps, HybridApps
Mobile Strategy / Apps, WebApps, HybridAppsDaniel Haller
 
9 Ways to Earn
9 Ways to Earn9 Ways to Earn
9 Ways to Earneinjhel25m
 
Social Media & Rekrutierung - Hype oder Standard (7. April Schaffhausen)
Social Media & Rekrutierung - Hype oder Standard (7. April Schaffhausen)Social Media & Rekrutierung - Hype oder Standard (7. April Schaffhausen)
Social Media & Rekrutierung - Hype oder Standard (7. April Schaffhausen)Yves Maeder
 
THAK Workshop »Kunst und Kommunikation im Social Web« am 09. April 2014
THAK Workshop »Kunst und Kommunikation im Social Web« am 09. April 2014THAK Workshop »Kunst und Kommunikation im Social Web« am 09. April 2014
THAK Workshop »Kunst und Kommunikation im Social Web« am 09. April 2014Frank Koebsch
 
E&G: Den Kapitalmärkten steht ein turbulentes Jahr 2012 bevor
E&G: Den Kapitalmärkten steht ein turbulentes Jahr 2012 bevorE&G: Den Kapitalmärkten steht ein turbulentes Jahr 2012 bevor
E&G: Den Kapitalmärkten steht ein turbulentes Jahr 2012 bevorEllwanger & Geiger Privatbankiers
 
PLANEACION Y DESARROLLO ESTRATEGICO DE LOS NEGOCIOS ELECTRONICOS
PLANEACION Y DESARROLLO ESTRATEGICO DE LOS NEGOCIOS ELECTRONICOSPLANEACION Y DESARROLLO ESTRATEGICO DE LOS NEGOCIOS ELECTRONICOS
PLANEACION Y DESARROLLO ESTRATEGICO DE LOS NEGOCIOS ELECTRONICOSGIOBANNACHAPARRO
 
DIE MARKTMEINUNG AUS STUTTGART: Aktienmärkte weiter im Fokus der Schuldenkrise
DIE MARKTMEINUNG AUS STUTTGART: Aktienmärkte weiter im Fokus der SchuldenkriseDIE MARKTMEINUNG AUS STUTTGART: Aktienmärkte weiter im Fokus der Schuldenkrise
DIE MARKTMEINUNG AUS STUTTGART: Aktienmärkte weiter im Fokus der SchuldenkriseEllwanger & Geiger Privatbankiers
 

Andere mochten auch (19)

Büromarktbericht Stuttgart 2012 / 2013
Büromarktbericht Stuttgart 2012 / 2013Büromarktbericht Stuttgart 2012 / 2013
Büromarktbericht Stuttgart 2012 / 2013
 
Definiciones
DefinicionesDefiniciones
Definiciones
 
Ellwanger & Geiger: Kapital & Märkte, Ausgabe Oktober 2013
Ellwanger & Geiger: Kapital & Märkte, Ausgabe Oktober 2013Ellwanger & Geiger: Kapital & Märkte, Ausgabe Oktober 2013
Ellwanger & Geiger: Kapital & Märkte, Ausgabe Oktober 2013
 
IID-Designprojekt Präsentation
IID-Designprojekt PräsentationIID-Designprojekt Präsentation
IID-Designprojekt Präsentation
 
Presentacion evaluacion3
Presentacion evaluacion3Presentacion evaluacion3
Presentacion evaluacion3
 
Kapital & Märkte, Ausgabe August 2014
Kapital & Märkte, Ausgabe August 2014Kapital & Märkte, Ausgabe August 2014
Kapital & Märkte, Ausgabe August 2014
 
Ljhkl
LjhklLjhkl
Ljhkl
 
Netbiscuits - 9 Tipps
Netbiscuits - 9 Tipps Netbiscuits - 9 Tipps
Netbiscuits - 9 Tipps
 
Mobile Strategy / Apps, WebApps, HybridApps
Mobile Strategy / Apps, WebApps, HybridAppsMobile Strategy / Apps, WebApps, HybridApps
Mobile Strategy / Apps, WebApps, HybridApps
 
Tengo el corazon
Tengo el corazonTengo el corazon
Tengo el corazon
 
9 Ways to Earn
9 Ways to Earn9 Ways to Earn
9 Ways to Earn
 
Social Media & Rekrutierung - Hype oder Standard (7. April Schaffhausen)
Social Media & Rekrutierung - Hype oder Standard (7. April Schaffhausen)Social Media & Rekrutierung - Hype oder Standard (7. April Schaffhausen)
Social Media & Rekrutierung - Hype oder Standard (7. April Schaffhausen)
 
THAK Workshop »Kunst und Kommunikation im Social Web« am 09. April 2014
THAK Workshop »Kunst und Kommunikation im Social Web« am 09. April 2014THAK Workshop »Kunst und Kommunikation im Social Web« am 09. April 2014
THAK Workshop »Kunst und Kommunikation im Social Web« am 09. April 2014
 
DIE MARKTMEINUNG AUS STUTTGART: Frauen an die Macht
DIE MARKTMEINUNG AUS STUTTGART: Frauen an die MachtDIE MARKTMEINUNG AUS STUTTGART: Frauen an die Macht
DIE MARKTMEINUNG AUS STUTTGART: Frauen an die Macht
 
Crowdsourcing Summit: Ideenreichtum & Innovationen aus der Crowd
Crowdsourcing Summit: Ideenreichtum & Innovationen aus der CrowdCrowdsourcing Summit: Ideenreichtum & Innovationen aus der Crowd
Crowdsourcing Summit: Ideenreichtum & Innovationen aus der Crowd
 
E&G: Den Kapitalmärkten steht ein turbulentes Jahr 2012 bevor
E&G: Den Kapitalmärkten steht ein turbulentes Jahr 2012 bevorE&G: Den Kapitalmärkten steht ein turbulentes Jahr 2012 bevor
E&G: Den Kapitalmärkten steht ein turbulentes Jahr 2012 bevor
 
PLANEACION Y DESARROLLO ESTRATEGICO DE LOS NEGOCIOS ELECTRONICOS
PLANEACION Y DESARROLLO ESTRATEGICO DE LOS NEGOCIOS ELECTRONICOSPLANEACION Y DESARROLLO ESTRATEGICO DE LOS NEGOCIOS ELECTRONICOS
PLANEACION Y DESARROLLO ESTRATEGICO DE LOS NEGOCIOS ELECTRONICOS
 
DIE MARKTMEINUNG AUS STUTTGART
DIE MARKTMEINUNG AUS STUTTGARTDIE MARKTMEINUNG AUS STUTTGART
DIE MARKTMEINUNG AUS STUTTGART
 
DIE MARKTMEINUNG AUS STUTTGART: Aktienmärkte weiter im Fokus der Schuldenkrise
DIE MARKTMEINUNG AUS STUTTGART: Aktienmärkte weiter im Fokus der SchuldenkriseDIE MARKTMEINUNG AUS STUTTGART: Aktienmärkte weiter im Fokus der Schuldenkrise
DIE MARKTMEINUNG AUS STUTTGART: Aktienmärkte weiter im Fokus der Schuldenkrise
 

Ähnlich wie Präsentation Monitoring 31.1.2011

Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse
Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse
Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse QAware GmbH
 
OSMC 2011 | Performance-Vergleich von Nagios Monitoring Lösungen by Christoph...
OSMC 2011 | Performance-Vergleich von Nagios Monitoring Lösungen by Christoph...OSMC 2011 | Performance-Vergleich von Nagios Monitoring Lösungen by Christoph...
OSMC 2011 | Performance-Vergleich von Nagios Monitoring Lösungen by Christoph...NETWAYS
 
IT Workplace Performance - Anwenderzufriedenheit messbar machen
IT Workplace Performance - Anwenderzufriedenheit messbar machenIT Workplace Performance - Anwenderzufriedenheit messbar machen
IT Workplace Performance - Anwenderzufriedenheit messbar machenBeck et al. GmbH
 
Multi analyzer software (MAS 555)
Multi analyzer software (MAS 555)Multi analyzer software (MAS 555)
Multi analyzer software (MAS 555)LauraArias292153
 
Lims Vortrag von Sieberth und Krenn
Lims Vortrag von Sieberth und KrennLims Vortrag von Sieberth und Krenn
Lims Vortrag von Sieberth und Krennwernerweninger
 
Autonomic Computing - Diagnosis - Pinpoint Summary
Autonomic Computing - Diagnosis - Pinpoint SummaryAutonomic Computing - Diagnosis - Pinpoint Summary
Autonomic Computing - Diagnosis - Pinpoint SummaryOliver Stadie
 
Die Bedeutung der Diagnose in der Fahrzeugentwicklung
Die Bedeutung der Diagnose in der FahrzeugentwicklungDie Bedeutung der Diagnose in der Fahrzeugentwicklung
Die Bedeutung der Diagnose in der FahrzeugentwicklungSchleissheimer GmbH
 
Comprehensive Security Concept For Process Control Systems V2006
Comprehensive Security Concept For Process Control Systems V2006Comprehensive Security Concept For Process Control Systems V2006
Comprehensive Security Concept For Process Control Systems V2006kaestnja
 
Streaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der WahlStreaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der WahlMatthias Niehoff
 
Plant check Mobile Industrie Anlagenkontrollen
Plant check Mobile Industrie AnlagenkontrollenPlant check Mobile Industrie Anlagenkontrollen
Plant check Mobile Industrie AnlagenkontrollenYakup Bozkurt
 
Automatisierter Software-Test unter Java
Automatisierter Software-Test unter JavaAutomatisierter Software-Test unter Java
Automatisierter Software-Test unter JavaGFU Cyrus AG
 
Industrie 4.0 Checkliste
Industrie 4.0 ChecklisteIndustrie 4.0 Checkliste
Industrie 4.0 ChecklisteSrenRose1
 
It workplace performance anwenderzufriedenheit messbar machen
It workplace performance   anwenderzufriedenheit messbar machenIt workplace performance   anwenderzufriedenheit messbar machen
It workplace performance anwenderzufriedenheit messbar machenBeck et al. GmbH
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
 
PROFACTOR Gruppe | Complete Inspect
PROFACTOR Gruppe | Complete InspectPROFACTOR Gruppe | Complete Inspect
PROFACTOR Gruppe | Complete InspectPROFACTOR Group
 
Splunk Discovery Köln - 17-01-2020 - Security Operations mit Splunk
Splunk Discovery Köln - 17-01-2020 - Security Operations mit SplunkSplunk Discovery Köln - 17-01-2020 - Security Operations mit Splunk
Splunk Discovery Köln - 17-01-2020 - Security Operations mit SplunkSplunk
 
130605 blog - drools
130605   blog - drools130605   blog - drools
130605 blog - droolsjava-pe
 
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...NETWAYS
 

Ähnlich wie Präsentation Monitoring 31.1.2011 (20)

Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse
Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse
Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse
 
OSMC 2011 | Performance-Vergleich von Nagios Monitoring Lösungen by Christoph...
OSMC 2011 | Performance-Vergleich von Nagios Monitoring Lösungen by Christoph...OSMC 2011 | Performance-Vergleich von Nagios Monitoring Lösungen by Christoph...
OSMC 2011 | Performance-Vergleich von Nagios Monitoring Lösungen by Christoph...
 
IT Workplace Performance - Anwenderzufriedenheit messbar machen
IT Workplace Performance - Anwenderzufriedenheit messbar machenIT Workplace Performance - Anwenderzufriedenheit messbar machen
IT Workplace Performance - Anwenderzufriedenheit messbar machen
 
DTN Routing Verfahren
DTN Routing VerfahrenDTN Routing Verfahren
DTN Routing Verfahren
 
Multi analyzer software (MAS 555)
Multi analyzer software (MAS 555)Multi analyzer software (MAS 555)
Multi analyzer software (MAS 555)
 
Lims Vortrag von Sieberth und Krenn
Lims Vortrag von Sieberth und KrennLims Vortrag von Sieberth und Krenn
Lims Vortrag von Sieberth und Krenn
 
Autonomic Computing - Diagnosis - Pinpoint Summary
Autonomic Computing - Diagnosis - Pinpoint SummaryAutonomic Computing - Diagnosis - Pinpoint Summary
Autonomic Computing - Diagnosis - Pinpoint Summary
 
Die Bedeutung der Diagnose in der Fahrzeugentwicklung
Die Bedeutung der Diagnose in der FahrzeugentwicklungDie Bedeutung der Diagnose in der Fahrzeugentwicklung
Die Bedeutung der Diagnose in der Fahrzeugentwicklung
 
Comprehensive Security Concept For Process Control Systems V2006
Comprehensive Security Concept For Process Control Systems V2006Comprehensive Security Concept For Process Control Systems V2006
Comprehensive Security Concept For Process Control Systems V2006
 
Streaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der WahlStreaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der Wahl
 
Plant check Mobile Industrie Anlagenkontrollen
Plant check Mobile Industrie AnlagenkontrollenPlant check Mobile Industrie Anlagenkontrollen
Plant check Mobile Industrie Anlagenkontrollen
 
Automatisierter Software-Test unter Java
Automatisierter Software-Test unter JavaAutomatisierter Software-Test unter Java
Automatisierter Software-Test unter Java
 
Industrie 4.0 Checkliste
Industrie 4.0 ChecklisteIndustrie 4.0 Checkliste
Industrie 4.0 Checkliste
 
It workplace performance anwenderzufriedenheit messbar machen
It workplace performance   anwenderzufriedenheit messbar machenIt workplace performance   anwenderzufriedenheit messbar machen
It workplace performance anwenderzufriedenheit messbar machen
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
PROFACTOR Gruppe | Complete Inspect
PROFACTOR Gruppe | Complete InspectPROFACTOR Gruppe | Complete Inspect
PROFACTOR Gruppe | Complete Inspect
 
Splunk Discovery Köln - 17-01-2020 - Security Operations mit Splunk
Splunk Discovery Köln - 17-01-2020 - Security Operations mit SplunkSplunk Discovery Köln - 17-01-2020 - Security Operations mit Splunk
Splunk Discovery Köln - 17-01-2020 - Security Operations mit Splunk
 
130605 blog - drools
130605   blog - drools130605   blog - drools
130605 blog - drools
 
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
 
Monitoring klassisch oder Cloud
Monitoring klassisch oder CloudMonitoring klassisch oder Cloud
Monitoring klassisch oder Cloud
 

Präsentation Monitoring 31.1.2011

  • 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
  • 4. 2.Begriffsdefinitionen und Grundlagen • 2.1 Echtzeitsysteme • 2.2 Verteilte Echtzeitsysteme • 2.3 Konzepte für fehlertolerante Systeme 4
  • 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!
  • 8. 2.2 Verteilte Echtzeitsysteme – Bsp. Flugzeug 8
  • 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
  • 11. 3. Monitoring: Einführung und Forschungsstand • 3.1 Einführung Monitoring • 3.2 Allgemeiner Forschungsstand des Monitoring • 3.3 Forschungsstand Monitoring: MAC • 3.4 Forschungsstand Monitoring: MOP • 3.5 Forschungsstand Monitoring: Verteilte Systeme 11
  • 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
  • 18. 4.Monitor-Architekturen für verteilte Echtzeitsysteme • 4.1 Theorie: Monitoring verteilter Echtzeitsysteme Systeme • 4.2 Hardware- / Softwareunterscheidung • 4.3 Anforderungen an Monitor Architekturen • 4.4 Monitor – Architekturen für verteilte Echtzeitsysteme 18
  • 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
  • 27. 5. Wichtige zu überwachende Eigenschaften im Monitoring • 5.1 Rückblick Problemstellung MFA • 5.2 Monitoring Konsens Verletzungen - „Fault-Model“ - Verletzungen • 5.3 Monitoring Konsens Verletzungen – „Point-to-Point Error-Checking“ • 5.4Monitoring Konsens Verletzungen – „Timing violations “ 27
  • 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