Motivation

1. Service-orientiertes Betriebssystem fürubiquitäreSensorsystemeDiplomarbeitsvortragAndrea SayerBetreuer: Christian DeckerTelecooperation 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 object .class

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

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

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?