Motivation
-
Upload
dane-hodges -
Category
Documents
-
view
18 -
download
0
description
Transcript of Motivation
Service-orientiertes Betriebssystem für
ubiquitäreSensorsysteme
Diplomarbeitsvortrag
Andrea SayerBetreuer: Christian Decker
Telecooperation Office (TecO)
2
Motivation
• bisherige Particle-Entwicklung: 2-Task-System• Unterbrechung der Anwendung durch Funkstack alle 13ms • Hauptaufgabe ubiquitärer Systeme: Kontexterkennung
• Probleme: • Zu unflexibel, ständige Neuimplementierung wiederkehrender
Aufgaben, Ausführung periodischer Aufgaben nur eingeschränkt möglich
• Keine Unterstützung der Kontexterfassung, keine zeitnahe Ausführung
3
Ziele
• Bereitstellung von Abstraktionen, Trennung unabhängiger Programmteile, Wiederverwendbarkeit, Flexibilität
=> Periodisches Laufzeitsystem
• Wiederverwendung von Ergebnissen vorhergehender Ausführungen, Zeitnähe
=> Datenflussorientiertes System
4
Gliederung
• Periodisches Laufzeitsystem • Servicekonzept • Aufbau des Laufzeitsystems• Dynamisches Einfügen von Services
• Datenflussorientierung• Struktur und Ausführungsstrategien• Qualitätsmetriken• Schedulingverfahren
• Implementierung
• Zusammenfassung
5
Servicekonzept
• Aufteilung des Systems in Anwendung und Services
• Anwendung• unterbrechbar, initialisiert Services und
verarbeitet Serviceausgaben
• Service• Konfiguration:
Parameter des Service: Periode, nextArrivalTime,...
• Servicefunktion: ununterbrechbar• Ausgabepuffer:
Schnittstelle zur Anwendung oder anderen Services
• Zustand: WAITING, READY
6
Laufzeitsystem
• Waiting Queue• Enthält Services im Zustand WAITING• Geordnet nach nächster Ankunftszeit
• Ready Queue• Services im Zustand READY• Geordnet nach Priorität
• Scheduler• Sortiert Services in die Ready Queue ein
• Dispatcher• Überprüft die Waitingqueue auf Services, die ihre nächste
Ankunftszeit erreicht haben und übergibt diese an den Scheduler
11
Dynamisches Einfügen von Services(2)
• Ausführung von Java Services unter Verwendung der ParticleVM
12
Gliederung
• Periodisches Laufzeitsystem • Servicekonzept • Aufbau des Laufzeitsystems• Dynamisches Einfügen von Services
• Datenflussorientierung• Struktur und Ausführungsstrategien• Qualitätsmetriken• Schedulingverfahren
• Implementierung
• Zusammenfassung
13
Datenflussorientierung
• Bisher: periodisches Laufzeitsystem• Problem: fehlende Koordination der Datenverarbeitung,
keine Berücksichtigung der Datenabhängigkeiten, somit keine Zeitnähe
• Datenflussorientierte Systeme: Ausführung ist vom Vorhandensein der Eingabewerte abhängig => Für ubiquitäre Systeme: Wenn Kontext vorhanden, dann entspr. Anwendungsteil ausführen (d.h. Vermeidung von Redundanz)
14
Verwandte Arbeiten
•Datenflussarchitekturen: Hardwarearchitektur, datenflussoriente Befehlsausführung, für ressourcenbeschränkte Sensorknoten nicht geeignet
•Data Flow Languages: Programmiersprache für Datenflussrechner
•Flow-Based Programming (J.P.Morrison): Programmierparadigma, Gesamtanwendung aus Blackbox-Komponenten, Datenaustausch über Puffer
Gemeinsamkeiten mit dem Servicekonzept, aber hochgradig asynchron, keine periodischen Ausführungen
=> Datenflussorientiertes System für Sensorknoten
15
Graphstruktur
• Schichtenmodell• Anordnung von Services gemäß ihrer
Datenabhängigkeiten• Datenquelle, Systemantrieb,
periodische Services• Datenverarbeitung, datenorientierte
Services
• Graphstruktur
• Gerichteter, azyklischer Graph (DAG)• Jeder Service darf nur einem Baum
angehören• Jedem Puffer ist genau ein Eingabeservice zugewiesen• Services können aus mehreren Puffern lesen• Ein Service kann mehrere Ausgabepuffer haben
16
Pfadbasierte Ausführung
• Pfadweises Ausführen von Services• Pfade des Baumes bilden Scheduling-
einheiten• Abarbeitung des Pfades ist ununterbrechbar
Ausnahmen:• Interner Abbruch: Abbruch auf
Veranlassung eines Services => Scheduler soll Pfad benachteiligen• Externer Abbruch: Abbruch wegen veralteter Eingabedaten => Pfad soll bei nächster
Schedulingentscheidung bevorzugt werden• Kontrollierter Pfadabbruch:
Aggregation, Verarbeitung von Daten abweichend vom normalen Datenfluss
17
Qualitätsbestimmung
• Datenechtzeit• Realisation des Zeitnäheprinzips
• Services• Periodisch: Jitter• Datenverarbeitend: Alter der Daten im Eingabepuffer
• Pfade
P=100ms
q Trace j q s imit s i Trace j und Succ s i EMPTY
1
1 0,75
0,75
0,6
18
Scheduling – Zeitnähe(1)
• Systemqualität: Maß für die Zeitnähe
• Finden einer optimalen Lösung ist komplex (NP-vollständig?) => Annäherung durch Heuristiken
• Grapheigenschaften für Heuristiken, die die Systemqualität beeinflussen:
Pfadlaufzeiten Gemeinsame Teilpfade Perioden
max q Trace j
19
Scheduling – Zeitnähe(2)
• Shortest Total Delay First:• Bevorzugung des Pfades, der alle anderen Pfade am geringsten verzögert• Hoher Overhead
• Highest Quality First: • Pfad mit höchster Qualität wird bevorzugt• Problem: Abhängigkeit von der Anfangsreihenfolge
• Shortest Path First:• Zeitl. kürzester Pfad wird bevorzugt• Keine Berücksichtigung der Baumstruktur/Periodenlängen
• Erweiterung von Shortest Path First• Berücksichtigung gemeinsamer Teilpfade• Berücksichtigung der Periodenlängen• Gute Simulationsergebnisse• Problem: unbekannte oder schwankende Ausführungszeiten
20
Scheduling – Fairness
• Least Quality First• Pfade, die eine niedrige Qualität erreicht haben, sollen bei
der nächsten Ausführung bevorzugt werden• Oszillation zwischen zwei Schedulingreihenfolgen führt zu
unterschiedlich ausgeprägten Schwankungen
• Qualitätsbudget Verfahren• Aktuelle Qualität wird von Qualitätsbudget abgezogen• Höchstes Budget wird bevorzugt• Neuer Parameter: Anfangsbudget
21
Scheduling - Bewertung
• First In First Out (FIFO): • Geringer Overhead• Keine Fairness oder hohe Systemqualität
• Prioritäten: Priorisierung von Pfaden durch Entwickler (statisch)• Geringer Overhead• Fairness und hohe Systemqualität hängen von den Absichten
des Entwicklers ab
• Erweiterung von Shortest Path First:• Gute Annäherung an die optimale Systemqualität• Relativ hoher Overhead, keine Fairness• Voraussetzung: vorhersehbare Ausführungszeiten, schwierig
für datenorientierte Services
• Qualitätsbudget-Verfahren:• Fairness, relativ geringer Overhead• Keine besonders hohe Systemqualität
22
Implementierung• Particle (229)
• Small Device C Compiler (SDCC)• Systemgröße
• POS: 18% Code, 17% Data• PBS, PVM, POS: 100% Code, 92% Data
• Overhead: geringer als beim periodischen System, etwas höherer Speicheraufwand
• Dispatcher: Timer1 Interrupt• Kommunikation: AwareCon V5
• Kommunikationsservice• Unterbrechung von
Services durch den Funkstack
• JavaVM• PC
• Vorverarbeitung• GraphViz• Simulation
Funktion Laufzeit(Zyklen)
periodisch pfadbasiert
Service_calc_next()
407 407
Dispatch() 2140 2472
Schedule()
FIFO
5 einzelne Services: 1208
1 Pfad mit 5 Services: 504
23
Zusammenfassung
• Abstraktionen und Trennung unabhängiger Programmteile durch ein Laufzeitsystem
• Mehr Flexibilität: dynamisches Einbinden von Java Services
• Unterstützung der Kontexterkennung und zeitnahe Ausführung durch das graphbasierte Scheduling
• Momentan laufende Arbeiten:• Einsatz für die AwarePen Anwendung