Software ubiquitärer Systeme - ess.cs.uni-dortmund.de · Experimentierplattform „Fail* ......

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/SS2014/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: mehr als gut (1.64)● Vorlesung kam sehr gut an (1.25),

die Übung und der Stoff „nur“ gut (1.94; 1.98)● „Gesamtbewertung“ auch sehr gut (1.48)● Besser als im Vorjahr (1.79 → 1.64)

● Positive Auffälligkeiten:● Der Stoff ist geeignet um auf den Beruf vorzubereiten (1.83)● Dialog zwischen Lehrkraft und Studierenden (1.12)

● Negative Auffälligkeiten:● Abstimmung Übung/Vorlesung (2.42)● Aufwand für Übungen (5.94 → 6.76, Soll ist 5.0)


Evaluationsergebnis (2)

● Einzelmeinungen:● V: „Ich hätte gern weniger über das Software-Engineering gehört,

dafür mehr vom Rest, das war manchmal etwas zäh.“● V: „Es wäre schön, wenn es zur Vorlesung ein passendes Buch

geben würde.“● V: „Teilweise kommt es bei den PDFs zu Darstellungsfehlern auf

Android-Geräten, z.B. das Tutorial für [unleserlich] C++.“● Ü: „Das Einfließen der Übungspunkte in Klausurnote wäre super!“● Ü: „In der Rechnerübung wäre ein 2. Übungsleiter gut. Die Zeit

reicht meist nicht zur Bearbeitung aller Aufgaben.“● Ü: „Praktische Übungen sind gut, aber zuverlässige Uhren (Batterie)

und evtl mehr Programmier-Sticks wären schön“

● 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 30.7. und 18.8.2014 möglich● nicht „auf die lange Bank“ schieben

● Teilnahmescheine: Bei Christoph Borchert melden (Mail)● Für alle Studenten/Studentinnen, die die Aufgaben geschafft haben● Erledigung nach seinem Urlaub


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

● Stoff der Übung wird als Hintergrundwissen vorausgesetzt

● Nicht prüfungsrelevant sind folgende Vorlesungen:● Gast-Vorlesungen (FINCA und Smart Homes)● VL „Hardware: Kommunikation“



● 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“ (SS15)

- Basisveranstaltung für „Eingebettete und Verteilte Systeme“

- Ein vertikaler Streifzug durch die Systemsoftware ubiquitärer Systeme

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

- Vertiefung im Bereich der Betriebssysteme

- Bau eines eigenen PC Betriebssystems im Rahmen der Übung

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

- 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, Fehlerinjektion (Horst Schirmeier)● Experimentierplattform „Fail*“

● 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


Simulation ressourcengew. Systeme● Kontext MobiSim

● ein am LS12 entwickelterSimulator für Systemplattformen

● Zweck: Bestimmung/Vorhersagedes Ernergieverbrauchs einerPlattform in bestimmtenAnwendungsszenarien

● Aufgabe● Kopplung von MobiSim mit

Simulatoren für die Umgebung- Funknetzwerk

- Ablaufende (logistische) Prozesse

● Kooperation mit E-Technik und Logistik● Nutzung einer HLA-Implementierung● Evaluation









● Dies und Das


HW-Produktlinien: Das LavA-Projekt● Anwendungsspezifische Maßschneiderung von

Systemsoftware und Hardware

● Wissen wird automatisiertaus der Anwendungabgeleitet ...

● … und zur optimalenKonfigurierung der unterenSchichten verwendet

● APIs bilden jeweils die zuanalysierende Schnittstellezwischen den Schichten

● Generierte System kann zurAusführung auf ein FPGAgeladen werden

● System wird durch automa-tiesierte Design SpaceExploration optimiert

„Design SpaceExploration“


AspectVHDL● Querschneidende Belange existieren auch auf Hardware-Ebene

● Herausforderungen:● Wie können Aspekte für die

Hardwarebeschreibungssprache VHDL aussehen?

● Wo können Aspekte bei dem Design von Hardware gewinnbringend eingesetzt werden?

● Anvisierten Ziele:● Erweiterung der Sprache

„AspectVHDL“● Erweiterung des Aspektwebers

(Java)









● 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


Fehlertolerante Anwendungssoftware● Linux-Anwendungen absichern gegen Speicherfehler

● 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

● Implementierung mit AspectC++

● Voraussetzungen? Sehr gute C++ Kenntnisse!


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 λ









● 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


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


Dies und Das● AspectC++

● Exemplarische Anwendung neuer Sprachelemente, z.B. „Tags“

● Spracherweiterungen

● IDE-Integration, z.B. Visual Studio

● SimpleAspectC● „Industrietaugliche“ AOP-Lösung für C

● Kooperation Materna/DRV● Monitoring/Analyse von VoIP-Verbindungen im WAN

● Scheduling in föderierten Cloud-Umgebungen

● Dein Lieblingsthema hier● Einfach vorbeikommen und beraten lassen!


So, das war's

Arbeitsgruppe Eingebettete SystemsoftwareLehrstuhl 12

Vielen Dank!Ich hoffe, wir sehen uns wieder.

Date post:	13-Sep-2019
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Software ubiquitärer Systeme - ess.cs.uni-dortmund.de · Experimentierplattform „Fail* ......

Documents