Serviceorientiertes Betriebssystem fr ubiquitre Sensorsysteme Diplomarbeitsvortrag Andrea Sayer

Service-orientiertes Betriebssystem für ubiquitäre Sensorsysteme Diplomarbeitsvortrag Andrea Sayer Betreuer: Christian Decker Telecooperation Office (Tec. O)

Motivation • bisherige Particle-Entwicklung: 2 -Task-System • Unterbrechung der Anwendung durch Funkstack alle 13 ms • 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 2

Ziele • Bereitstellung von Abstraktionen, Trennung unabhängiger Programmteile, Wiederverwendbarkeit, Flexibilität => Periodisches Laufzeitsystem • Wiederverwendung von Ergebnissen vorhergehender Ausführungen, Zeitnähe => Datenflussorientiertes System 3

Gliederung • Periodisches Laufzeitsystem • Servicekonzept • Aufbau des Laufzeitsystems • Dynamisches Einfügen von Services • Datenflussorientierung • Struktur und Ausführungsstrategien • Qualitätsmetriken • Schedulingverfahren • Implementierung • Zusammenfassung 4

Servicekonzept • Aufteilung des Systems in Anwendung und Services • Anwendung • unterbrechbar, initialisiert Services und verarbeitet Serviceausgaben • Service • Konfiguration: Parameter des Service: Periode, next. Arrival. Time, . . . • Servicefunktion: ununterbrechbar • Ausgabepuffer: Schnittstelle zur Anwendung oder anderen Services • Zustand: WAITING, READY 5

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 6

Benutzersicht 7

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

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

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

Dynamisches Einfügen von Services(2) • Ausführung von Java Services unter Verwendung der Particle. VM 11

Gliederung • Periodisches Laufzeitsystem • Servicekonzept • Aufbau des Laufzeitsystems • Dynamisches Einfügen von Services • Datenflussorientierung • Struktur und Ausführungsstrategien • Qualitätsmetriken • Schedulingverfahren • Implementierung • Zusammenfassung 12

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

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 14

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 15

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 16

Qualitätsbestimmung • Datenechtzeit • Realisation des Zeitnäheprinzips • Services • Periodisch: Jitter • Datenverarbeitend: Alter der Daten im Eingabepuffer P=100 ms 1 • Pfade 1 0, 75 0, 6 17

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 Systemqualität beeinflussen: Pfadlaufzeiten Gemeinsame Teilpfade Perioden 18

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 19

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 20

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 21

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: Timer 1 Interrupt • Kommunikation: Aware. Con V 5 • Kommunikationsservice • Unterbrechung von Services durch den Funkstack • Java. VM Funktion Laufzeit(Zyklen) periodisch pfadbasiert Service_calc _next() 407 Dispatch() 2140 2472 Schedule() FIFO 5 einzelne Services: 1208 1 Pfad mit 5 Services: 504 • PC • Vorverarbeitung • Graph. Viz • Simulation 22

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 Aware. Pen Anwendung 23

Fragen? 24