SuS-07.2: Ausblick - TU Dortmund

ess.cs.uni.dortmund.de

SuS-07.2: Ausblick - TU Dortmund

Software ubiquitärer Systeme

Ausblick

Olaf Spinczyk

Arbeitsgruppe Eingebettete Systemsoftware

Lehrstuhl für Informatik 12

TU Dortmund

Olaf.Spinczyk@tu-dortmund.de

http://ess.cs.uni-dortmund.de/~os/

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

1


Inhalt

● Evaluationsergebnis

● Prüfung

● Lehrveranstaltungen der Arbeitsgruppe ESS

● Themen Diplom- und Masterarbeiten

07.2Ausblick 2


Evaluationsergebnis

... findet man auf der Webseite zu SuS

● Gesamtergebnis: sehr gut (1.55)

● Leichte Diskrepanz zwischen Vorlesung (1.24) und Übung (1.84)

● Auffälligkeiten

● Bewertung der Vorlesung → alles


Evaluationsergebnis (2)

● Einzelmeinungen:

● „zu viele Kürzel“

● „teilweise waren die PDF-Dateien nicht erreichbar“

● „pure::variants sollte nicht behandelt werden“

● „hervorragende Rechnerausstattung für Übungsaufgaben“

● „es macht Spaß c++/ac++ zu hacken“

● ESS-Kummerkasten (→ SuS Webseite)

● Für alle, die uns noch mehr sagen wollen

07.2Ausblick 4


Inhalt

● Evaluationsergebnis

● Prüfung

● Lehrveranstaltungen der Arbeitsgruppe ESS

● Themen Diplom- und Masterarbeiten

07.2Ausblick 5


Prüfung/Schein

● Prüfung: Mit Anmeldeformular zu mir kommen

● kein Prüfungstermin zwischen 9.8. und 24.8.2010 möglich

● nicht „auf die lange Bank“ schieben

● Teilnahmescheine: Im LS12 Sekretariat abholen

● Für alle Studenten/Studentinnen, die die Aufgaben geschafft haben

07.2Ausblick 6


Inhalt/Ablauf der Prüfung

● Primär Fragen zum Stoff der Vorlesung

● Stoff der Übung wird als Hintergrundwissen vorausgesetzt

● Nicht prüfungsrelevant ist die Gastvorlesung

● Christian Kleine-Cosack: Die FINCA

07.2Ausblick 7


Inhalt

● Evaluationsergebnis

● Prüfung

● Lehrveranstaltungen der Arbeitsgruppe ESS

● Themen Diplom- und Masterarbeiten

07.2Ausblick 8


LVs der Arbeitsgruppe ESS

● Bachelor Fachprojekt

● FP-SWA – „Software im Automobil“ (WS 10/11)

- Praktische Durchführung einer SW-Entwicklung für Autos

● Master-Basis

● SUS – „Software ubiquitärer Systeme“ (SS11)

- Basisveranstaltung für „Eingebettete und Verteilte Systeme“

- Ein vertikaler Streifzug durch die Systemsoftware ubiquitärer Systeme

● Master-Vertiefung

● BSB – „Betriebssystembau“ (WS 10/11)

- Vertiefung im Bereich der Betriebssysteme

- Bau eines eigenen PC Betriebssystems im Rahmen der Übung

● AFFESS – „Aktuelle Forschungsfragen

der eingebetteten Systemsoftware“ (WS 11/12?)

- Wechselnde Themen mit starkem Forschungsbezug

● PGs

07.2Ausblick 9


„Betriebssystembau“

● Immer im Wintersemester

● Wahlveranstaltung 2V + 2Ü

● Schwerpunktgebiete: „Softwarekonstruktion“ und

„Rechnerarchitektur, eingebettete Systeme und Simulation“

Lunar Lander

Eine Mondlandesimulation

auf

Basis der Übungsbetriebssystems

OO-StuBS.

07.2Ausblick 10


„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

07.2Ausblick 11


Inhalt

● Evaluationsergebnis

● Prüfung

● Lehrveranstaltungen der Arbeitsgruppe ESS

● Themen Diplom- und Masterarbeiten

07.2Ausblick 12


Themenbereiche

● Hardware-Produktlinien (Matthias Meier)

● Maßgeschneiderte MPSoCs auf FPGAs

● Software-Produktlinien (Horst Schirmeier)

● Statische Anwendungsanalyse

● Maßgeschneiderte Systemsoftware

● Virtualisierung in eingeb. Systemen (Jochen Streicher)

● Maßgeschneiderte Betriebssysteme für virtuelle Maschinen

● Echtzeitüberwachung im „Virtual Machine Monitor“

● Aspektorientierte Programmierung (Olaf Spinczyk)

● AspectC++ und Anwendungen

07.2Ausblick 13


Zuverlässigkeit in einem MPSoC

● Wie wirkt sich die verteilte Architektur auf die

Zuverlässigkeit des Gesamtsystems aus?

● Welche Vorteile bietet die verteilte Architektur?

● Anvisierte Ziele:

● Implementierung einer verteilten Überwachung

● Implementierung

von Redundanz

07.2Ausblick 14


Konfigurierbares On-Chip-Netzwerk

● Entwicklung einer konfigurierbaren Crossbar-Struktur für

das bereits existierende LavA-Multiprozessorsystem

● Implementierung

in VHDL

● Vergleich mit

existierenden

Kommunikationsstrukturen

(Bus und Ring)

Sender

0

Sender

1

Sender

2

Sender

3

Empf.

0

Empf.

1

Empf.

2

Empf.

3

07.2Ausblick 15


Aspekte in Hardware (1)

● Hardwarebeschreibungssprachen

● Syntax wie bei Programmiersprachen (VHDL ↔ ADA, Verilog ↔ C)

● Semantik deutlich abweichend: Beschreibung von HW-Strukturen

● Wie sehen querschneidende Belange in Hardware aus?

● ...und was beschreiben sie?

- Struktur der Hardware? Temporale Abhängigkeiten? Kontroll-/Datenfluss?

● Beispiel: State Machine eines UART

● Konfigurierbare Parität (gerade/ungerade/mark/space) einbauen

● State Machine: Startbit → Bit0 → … → Bit7 → Paritätsbit → Stopbit

- Separate State Machine für Senden und Empfangen von Daten

case STATE_TXD is ...

when S8 =>

TXDS


Aspekte in Hardware (2)

● Aufgaben:

● Finden von Beispielen für querschneidende Belange in “real world”

VHDL

- Synthese von Schaltungen, Simulation, Verifikation

● Bestimmung der Joinpoint-Semantik und einer Pointcut-Sprache

- Definition einer Spracherweiterung für VHDL

● Implementieren eines Prototyps für AspectVHDL

- VHDL-Parser existieren bereits

● Evaluation

- Aufwand zur Implementierung von Hardwareeigenschaften mit

AspectVHDL

07.2Ausblick 17


Domänenspezifische ISAs für VMs

● ISA nicht optimal

● Größe des Bytecodes

● Geschwindigkeit der VM

● Domänenspezifische ISA

● Stackmachine nötig, reichen Register?

● Datentypen?

Compiler

● Welche Instruktionen werden wirklich benötigt?

● Mühsame Anpassung von Hand?

code for eventCAN-ID: 528, MSG: [1], MASK: [1]

35: JZ CAddr: 60 DAddr: 16

39: MOVIV ImmVal: 0 DAddr: 16

45: MOVIV ImmVal: 5 DAddr: 15

51: DELAY DAddr: 15

53: SEND CAN-ID: 529, MSG: [0]

57: JMP CAddr: 79

60: NOP

61: MOVIV ImmVal: 1 DAddr: 16

67: MOVIV ImmVal: 5 DAddr: 15

73: DELAY DAddr: 15

75: SEND CAN-ID: 529, MSG: [1]

79: RET

01 00 23 00 50 00 0c 00 0a 00 10 12 00 01 01 01

00 01 00 40 04 12 01 a8 00 00 00 00 0d a8 64 00

00 00 0f f4 0f 0e 00 a8 68 01 00 00 0f f6 0f 0e

00 80 05 00 20 a0 3c 00 10 a8 00 00 00 00 10 a8

05 00 00 00 0f 88 0f 40 11 12 00 80 4f 00 00 a8

01 00 00 00 10 a8 05 00 00 00 0f 88 0f 40 11 12

01 20

07.2Ausblick 18

VM

Besser:

Modell für die

Anwendungsdomäne,

Generierung der ISA!


Timing Protection

● Rüstzeug: Real-Time Calculus

● α e (Δt) – Max. Häufigkeit des Ereignisses e

in einem Δt großen Zeitintervall

● WCET e – Max. Dauer der Behandlung von e

● TP in AUTOSAR: Monitoring der

✔ WCET

✗ Inter-Arrival Time I e →

● Aufgabe

● Implementierung der verbesserten TP

● Aufbau eines Szenarios

- verschiedene Tasks senden periodisch

Nachrichten auf dem CAN-Bus

- Berechnung/Validierung der α-Kurven

● Evaluation

α e ∆t floor ∆t

I e

jochen.streicher@tu-dortmund.de

07.2Ausblick 19


α(∆t)

α(∆t)

∆t

∆t


Automatische Maßschneiderung

● Autom. Maßschneiderung der C-Standardbibliothek

● z.B. dietlibc: bereits sehr klein, dennoch monolithisch

- Konfigurierbarkeit: Modularisierung insbesondere querschneidender

Belange noch nicht vorhanden!

● Wie erkennt man, welche Features die Anwendung braucht?

→ Art und Weise der Benutzung der API!

● Automatisierung der Merkmalselektion: Ein Aufruf von …

pthread_mutex_lock(&mutex);

… lässt z.B. darauf schließen, dass die Features THREADING und

MUTEX der dietlibc eingeschaltet sein müssen.

● Wenn innerhalb eines Threads weitere API-Aufrufe vorkommen,

müssen diese u. U. reentrant sein.

07.2Ausblick 20


Konformitätstest für Android-Apps

● Analysegewahre Android-API

● Problem: sehr viele unterschiedliche Android-Devices

- ~100.000 Apps im „Market“, alle mit unterschiedlichen Anforderungen

- Welche App läuft auf welchem Device?

- vorangegangene Arbeit: statische Analyse von Android-Apps, Ableitung

von Merkmal-Bedarf

● Aber: Analyse scheitert in vielen Fällen daran, dass die Android-API

dieses Vorgehen nicht vorsieht!

● Wie müsste die Android-API aussehen, damit die Analyse immer

gelingt? Wird die Analyse dadurch auch schneller / einfacher? Die

Ergebnisse qualitativ besser?

07.2Ausblick 21


Weitere Themen

● Echtzeiteigenschaften in einem konfigurierbaren MPSoC

● Entwicklung von Mechanismen zur Analyse des Echtzeitverhaltens

des Gesamtsystems

● CiAO (aspektorientiert, konfigurierbar)

● Plattentreiber/Dateisystem (x86)

● CiAO personality für Linux-Anwendungen (abhängig)

● AspectC++

● Anwendungen für den neuen Introspection Mechanismus

● Beispiel: Treiber-Framework für Linux

● Dein Lieblingsthema hier.

07.2Ausblick 22

Weitere Magazine dieses Users
Ähnliche Magazine