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

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

.classobject

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

24

Fragen?