Service-orientiertes Betriebssystem für ubiquitäre Sensorsysteme Diplomarbeitsvortrag Andrea Sayer Betreuer: 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

7 Benutzersicht

8 Dynamisches Einfügen von Services(1) Verteilung von Objekten mit der ParticleVM. class

9 Dynamisches Einfügen von Services(1) Verteilung von Objekten mit der ParticleVM. class

10 Dynamisches Einfügen von Services(1) Verteilung von Objekten mit der ParticleVM. class object

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 1 10,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

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) periodischpfadbasiert Service_calc _next() 407 Dispatch() Schedule() FIFO 5 einzelne Services: 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

24 Fragen?