Software ubiquitärer Systeme - ess.cs.tu-dortmund.de · 07.2 – Ausblick 9 LVs der Arbeitsgruppe ESS Bachelor Fachprojekt FP-SWA – „Software im Automobil“ (WS 14/15?)-Praktische

11

Software ubiquitärer SystemeAusblick

Olaf SpinczykArbeitsgruppe Eingebettete Systemsoftware

Lehrstuhl für Informatik 12TU Dortmund [email protected]://ess.cs.uni-dortmund.de/~os/

http://ess.cs.tu-dortmund.de/DE/Teaching/SS2013/SuS/

mailto:[email protected]

07.2 – Ausblick 22

Inhalt● Evaluationsergebnis

● Prüfung

● Lehrveranstaltungen der Arbeitsgruppe ESS

● Themen Diplom- und Masterarbeiten


Evaluationsergebnis... findet man auf der Webseite zu SuS

● Gesamtergebnis: gut (1.82)● Vorlesung kam sehr gut an (1.4),

die Übung und der Stoff „nur“ gut (2.00; 2.03)● „Gesamtbewertung“ auch sehr gut (1.53)● Im letzten Jahr besser, aber auch weniger Teilnehmer

● Positive Auffälligkeiten:● Der Stoff ist geeignet um auf den Beruf vorzubereiten (1.71)● Die Veranstaltung ist gut organisiert (1.17)

● Negative Auffälligkeiten:● Nicht optimale Eignung der Literatur (2.2)● Vorstellung der Lösungen (2.53)● Aufwand für Übungen (5.94, Soll ist 5.0)


Evaluationsergebnis (2)

● Einzelmeinungen:● V: „Die Struktur, besonders die Einbindung von Querschnittsthemen

furch die gesamte Vorlesung ist sehr gut gelungen. Der ruhige und besonnene Vortragsstil gefällt mir gut.“

● V: „Zu viele Folien (~50/Vorlesung)“● V: „äußerst sympathisches Auftreten des Professors“● M: „Vollständig online bereits zu Semesterbeginn!“● Ü: „mehr Übungen (Sensorik)“● Ü: „Die Aufgaben sind sehr interessant, aber der Umfang für 90

Minuten meiner Meinung einfach zu hoch. Der Raum für die Theorie ist zu klein.“ (3 x ähnliche Kommentare)

● ESS-Kummerkasten (→ SuS Webseite)● Für alle, die uns noch mehr sagen wollen



● Prüfung




Prüfung/Schein● Prüfung

● Termin per Mail mit Frau Graute im LS12-Sekretariat ausmachen:[email protected]

● Danach mit dem Anmeldeformular zu ihr (14 Tage Vorlauf beachten)● Kein Prüfungstermin zwischen 6.8. und 30.8.2013 möglich● nicht „auf die lange Bank“ schieben

● Teilnahmescheine: Bei Christoph Borchert melden● Für alle Studenten/Studentinnen, die die Aufgaben geschafft haben● Kurzfristig erledigen


Inhalt/Ablauf der Prüfung● Primär Fragen zum Stoff der Vorlesung

● Stoff der Übung wird als Hintergrundwissen vorausgesetzt

● Nicht prüfungsrelevant sind Gastvorlesungen

● Besuch in der FINKA



● Prüfung




LVs der Arbeitsgruppe ESS● Bachelor Fachprojekt

● FP-SWA – „Software im Automobil“ (WS 14/15?)- Praktische Durchführung einer SW-Entwicklung für Autos

● Master-Basis● SUS – „Software ubiquitärer Systeme“ (SS14)

- Basisveranstaltung für „Eingebettete und Verteilte Systeme“

- Ein vertikaler Streifzug durch die Systemsoftware ubiquitärer Systeme

● Master-Vertiefung● BSB – „Betriebssystembau“ (WS 13/14)

- Vertiefung im Bereich der Betriebssysteme

- Bau eines eigenen PC Betriebssystems im Rahmen der Übung

● AFFESS – „Aktuelle Forschungsfragen der eingebetteten Systemsoftware“ (WS 14/15?)

- Wechselnde Themen mit starkem Forschungsbezug

● PGs, Seminare


„Betriebssystembau“● Immer im Wintersemester● Wahlveranstaltung 2V + 2Ü

● Schwerpunktgebiete: „Softwarekonstruktion“ und„Rechnerarchitektur, eingebettete Systeme und Simulation“

Lunar LanderEine Mondlande-simulation aufBasis der Übungs-betriebssystemsOO-StuBS.

Lunar LanderEine Mondlande-simulation aufBasis der Übungs-betriebssystemsOO-StuBS.


„Betriebssystembau“● V: Vertiefung des Themenbereichs „Betriebssysteme“

● Praktische Aspekte des Betriebssystembaus

- Wie implementiert man einen Kontextwechsel?

- Wie koordiniert man Aktivitäten eines Interrupt-Handlers?

- Wie programmiert man die „nackte“ Hardware?

● Betriebssystemkomponenten und deren Entwurf

● PC-Technologie aus Betriebssystemsicht

● Ü: Entwicklung eines einfachen PC-Betriebssystems● „Tafelübungen“ und betreute Rechnertermine

● 3er-Gruppen

● Programmierung in C++

● 6 (+1) Aufgaben



● Prüfung




Wanted: (Diplom|Master)and(en|innen)● Allgemeines

● Empirisches Arbeiten → Bauen, Messen, Bewerten● Anwendungsorientierung ist unser Querschnittsthema

- in verschiedenen Bereichen der eingebetteten Systemsoftware

● Themen


Themenbereiche● Datenerhebung in ubi. Systemen (Jochen Streicher)

● Energieoptimierung, Software-Sensoren, Android

● Energiemodelle (Markus Buschhoff)● Modellierung von HW, SW und deren Zusammenspiel

● Hardware-Produktlinien (Matthias Meier)● Maßgeschneiderte MPSoCs auf FPGAs

● Fehlertoleranz, SW-Produktlinien (Horst Schirmeier)● Fehlerinjektion: Experimentierplattform „Fail*“● Maßgeschneiderte Infrastruktursoftware

● Fehlertoleranz, Aspekte (Christoph Borchert)● Softwarebasierte Fehlertoleranzmechanismen in Systemsoftware

● Virtualisierung und Echtzeit (Boguslaw Jablkowski)● Hypervisor-basierte Fehlertoleranz

● Dies und Das









● Dies und Das


Sensorbaukasten

● Idee● Virtuelle Sensoren

- benutzen andere Sensoren (evtl. auch virtuell)

- liefern high-level-Kontext (Aktivität, Bewegung,…)

● Fernziel: Energie sparen- Verschiedene Provider für

einen Sensortyp

- automatische Suche nach dem billigsten Provider

Low-Power PositionierungLow-Power Positionierung

Pos

Pos

Applikation

GPSGPS

Pos

Bewegung

Acc.-SensorAcc.-Sensor

Beschleunigung

Bew.-DetektorBew.-Detektor

Bewegung

Beschleunigungoffoff

Bewegung

...

Bewegungsdetektor

Energie.Qualität

varianz()

> 0.8*1.1

*25s-1

Beschl..

Beschleunigungssensor

EnergieFreq?

+100mW

*20mWs Sensor

● Aufgaben● Problemanalyse & Konzeption des Modells● Prototypische Implementierung


Sensorbaukasten: Metamodell

SchnittstelleSchnittstelle

BewegungsdetektionBewegungsdetektion

Pos

Beschleunigung

Bewegung

virtueller Sensorvirtueller Sensor

Pos

Schnittstelle

Schnittstelle

Schnittstelle ...

DatenCap.Konfig.

BeschleunigungBeschleunigung

Beschl.Cap.acc./freq.

Quality {value : type...

}Data {

value : type...

}Capabilities {

power(...)value : type...

}

Quality {accuracy : intfrequency : int

}Data {

x, y, z : float}Capabilities {

power(acc, freq)max_frequency : intmax_acc : inttrigger : bool

}

Pos

Bosch BMA150Bosch BMA150

Beschl.Cap.acc./freq.

trig.

power = accuracy*frequency*0.01 + 2.5mW

max_frequency = 40Hzmax_accuracy = 0.03trigger = true

Metamodell

Konkrete Schnittstelle Ausprägung einer Schnittstelle

Konkreter virtueller Sensor









● Dies und Das


Ressourcengewahre Treiber

● Treiber sollen den internen Zustand der Hardware kennen und steuern können.

● Dazu: Unterbau mit “Hardware Access Layer”

● Automatisch generierte Benchmarks sollen Hardware-Zustände erkunden und Parameter (Zeitverhalten, Energieverbrauch bestimmen).

● Idee: Vom Automatenmodell zur Software mittels Model-Driven Software Development.

● Ziel: Modellierung von Hardware, Generierung von Treibern und Benchmarks

Multi-Priced Timed Automata (MPTA)

idle low mid high

Treiber

Erweitert Funktionalität des Hardware Access Layer

Profiling Benchmark

Iteriert über alle Zustände und protokolliert Messungen

(Zeit, Energie)

Hardware Access Layer

kennt alle HW-Zustände und kann diese direkt ansteuern


Neue Energiemodelle für MobiSIM

● MobiSIM ist ein am LS12 entwickelter Simulator für Systemplattformen

● Kernziel: Bestimmung des Energieverbrauchs einer Plattform

● Benötigt: Erarbeitung und Implementierung weiterer Energiemodelle für Komponenten, z.B. TI-Chronos Plattform, Modelle für Funknetzwerke (WiFi, LTE-A, usw)









● Dies und Das


AspectC++ bei Bosch









● Dies und Das


Flight Control Video Stream

Timer RAM Reg. ...

Alarms Events ...

Scheduling ...

Fehlertoleranz: Projekt● Annahme: zukünftige Hardware teilweise unzuverlässig

● Strukturgrößen werden immer kleiner● Energiesparen durch weiteres Senken der Betriebsspannung

● Idee:● selektives Härten von Anwendungs- und Betriebssystemsoftware

● Fragestellung:● Welche Teile des Systems passend

für die Anwendung härten?(Welche Teile sind besonders anfällig?)

● Wie gut wirkt ein Härtungs-verfahren?(Stürzt das System jetzt weniger häufig ab? Wird die für den Anwendungsfall benötigte Dienstgüte jetzt erreicht?)


Analyse/Bewertung: FI-Experimente● Problem: „Echte“ unzuverlässige Hardware ist schwer

zu bekommen und verhält sich, nunja, … unzuverlässig.● Ansatz: Simulatorbasierte Fehlerinjektionsexperimente

● FI-Experimentierframework Fail*● massiv parallele Durchführung

vieler, teils sehr lang laufender Einzelexperimente

● Fragestellung: Wie lässt sich dieExperimentlaufzeit verkürzen?

● Aufgabe:● Entwickeln einer Heuristik zum

vorzeitigen Experimentabbruch● Auswahl/Entwurf und Bewertung von Abbruchkriterien● Ziel: starke Verkürzung der Gesamtlaufzeit bei geringem

Genauigkeitsverlust

0s

10s

20s

30s

40s

„Golden R

un“kurzz. fehlerhafter

Systemzustand

Fehlerinjektion

Erkennung+Behebung

Zustand wieder wieim „Golden Run“?

Abbruch!

(offizielles Experimentende)









● Dies und Das


Betriebssystem-Stabilität (Christoph)● Hardwareprobleme oft katastrophal für Betriebssysteme

● z.B. Speicherfehler im Task-Scheduler → Crash- Ursachen: Elektromagnetische Strahlung,

Spannungsschwankung, Alterung der Hardware, …

● Zuverlässigkeit durch modulare Fehlertoleranz erhöhen● AOP-basierte, state-of-the-art Mechanismen anwenden

- z.B. Datenstrukturen um Prüfsummen erweitern

● Betriebssystem: Fiasco L4 Mikrokernel● Sehr gut dokumentiert (Doxygen)

● Voraussetzungen? Sehr gute C++ Kenntnisse!









● Dies und Das


Proaktive Fehlertoleranztechniken● Ziel: Proaktive und automatische Fehlertoleranz- und

Zuverlässigkeitslösungen● a priori Wissen über alternative Systemkonfigurationen nutzen● schnelle und intelligente Umstrukturierung des Systems im Fehlerfall

● Methode: Formalen Methoden zur Leistungsbewertung● Erforschung des Konfigurationsraumes● Analyse der Konfigurationskandidaten


Scheduling von Gastsystemen

● Modellierung vom Scheduling als Optimierungsproblem● Ansatz:

● Evolutionäre Algorithmen● Real-Time Calculus

- Leistungsbewertung in der Fitnessfunktion

● Evaluation durch Vergleich mit anderen Techniken:● z.B. Integer Linear Programming (ILP)

Server Server LAN Server

VM1

VM3

VM4C1

C2 VM5

VM2

Server LAN Server

VM1

VM3

VM4C1

C2 VM5

VM2Server - Crash !

21 32 3

1

Neue Konfiguration?

Deadlines ?


Checkpointing-Scheduling

● Checkpointing (Fehlertoleranz-Technik):● Schnappschuss des globalen Zustandes eines Prozesses/Systems ● Wiederherstellung im Falle eines Versagens

● Echtzeitfähiges checkpointing:● Schnappschuss mehrmals pro Sekunde● Verteilte Systeme → sehr hohe Kommunikationsanforderungen

● Wie gut kann checkpointing synchronisiert werden?

Arbeitsstationen/Server

LAN

Backup-Server


VM-Verträglichkeit● In Kooperation mit

● Beobachtung: Virtuelle Maschinen lassen sich unterschiedlich gut auf demselben Rechner gemeinsam ausführen.

● Aufgabe● Ursachenforschung

- Page Sharing, CPU- und E/A-Verhalten, Nutzerverhalten, ...

● Konzept- automatische Klassifikation von virtuellen Maschinen

- Ansatz für verbesserte Platzierung von VMs (Scheduling)

● Evaluation- Prototypische Implementation des Klassifikationsverfahrens

● Basis● Reale Monitoring-Daten einer Cloud-Plattform (vmware ESX)









● Dies und Das


C++ Template Meta-Programme● Wie debuggt man so etwas eigentlich?

● Gar nicht! (Zurzeit)

● C++ Template Meta-Programmierung ist funktionale Programmierung!● Analogie zum Debuggen von z.B. Haskell Programmen

● Aufgabe: Implementierung eines Debuggers● Zwischenschritte in einem Template Meta-Programm analysieren

- Compile-Zeit Konstanten, Template Instanziierungen, …

● Setzen von Breakpoints

● Basis: C++ Parser → Clang (Puma)● Erweiterung um Debugging-Funktionalität λ


AspectC++● Anwendungen

● Z.B. für den neuen Introspection-Mechanismus und Tags

● Sprache

● Z.B. Aspekt/Pointcut/Advice-Templates, C++ 11

● IDE-Integrationen

● Visual Studio, Eclipse & Co

● SimpleAspectC

● Die „industrietaugliche AOP-Lösung“ für C


Dein Lieblingsthema hier● Einfach vorbeikommen und beraten lassen!


So, das war's

Arbeitsgruppe Eingebettete SystemsoftwareLehrstuhl 12

Vielen Dank!Ich hoffe, wir sehen uns wieder.

Documents

Software ubiquitärer Systeme - ess.cs.tu-dortmund.de · 07.2 – Ausblick 9 LVs der Arbeitsgruppe ESS Bachelor Fachprojekt FP-SWA – „Software im Automobil“ (WS 14/15?)-Praktische