Hier eine Themenübersicht, gefolgt von etwas detaillierteren Darstellungen. Die meisten Themen lassen sich sowohl als Bachelor-/Master-/Diplomarbeit als auch, mit eingeschränktem Umfang, als Studienarbeit definieren. Generell sind Themenvariationen möglich, und auch selbst definierte Themen aus dem Bereich Echtzeitsysteme/Eingebettete Systeme können gerne besprochen werden.
Hinweis: Es ist Studierenden ausdrücklich empfohlen, sich frühzeitig bei den verschiedenen Lehrstühlen über mögliche Themen der Abschlussarbeit zu informieren. WWW-Seiten wie diese hier sind ein guter erster Anlaufpunkt, und es ist eine gute Idee, sich vor einem Gespräch mit einem potenziellen Betreuer (Professor, Assistenten -- generell die Dozenten von Lehrveranstaltungen) über mögliche Themen einen Blick auf diese Seiten zu werfen. Es ist jedoch erfahrungsgemäß schwierig, auf solchen Seiten vollständige und aktuelle Informationen bereitzustellen; sie sollten daher eher als grober Indikator der jeweils möglichen Themenfelder dienen denn als konkrete Ausschreibungen. Um zu erfahren, welche Themen konkret verfügbar sind, zu dem angestrebten Zeitrahmen, sollte man auf jeden Fall die Dozenten konsultieren.

Betreuung: Hauke Fuhrmann

Heute haben sich eine ganze Reihe von Modellierungssprachen durchgesetzt, die grafische Modelle verwenden. Dazu zählen beispielsweise die Unified Modeling Language (UML) oder die Werkzeugketten Simulink/Stateflow von Mathworks und SCADE von Esterel-Technologies. Letztere werden insbesondere auch im Entwurf eingebetteter und sicherheitskritischer Systeme (z.B. in Fahr- und Flugzeugen) eingesetzt.

Wer bereits mit diesen Werkzeugen gearbeitet hat, kennt aber auch die Schwächen dieses Prozesses: Während die grafische Visualisierung hilfreich bei der Analyse des Systems sein kann, ist die Erstellung eines grafischen Modells meist sehr Zeitaufwändig. In den bisher meist vorherrschenden WYSIWYG Editoren müssen sich die Entwickler selbst um niedrige Tätigkeiten verdient machen, die mit dem eigentlichen System nichts zu tun haben: Zeichnen, Positionieren und Navigieren in einem grafischen Modell sind häufig die zeitraubendsten Schritte bei diesem Prozess. Das KIEL Projekt hat bereits eindrucksvoll bewiesen, dass automatisches Layout von grafischen Modellen eine Vielzahl von neuen Möglichkeiten im modellbasierten Prozess ermöglicht.

In einer Neuauflage dieses Ansatzes soll diese Basisidee auch für andere Sprachen umgesetzt werden, insbesondere für Datenflussprachen wie SCADE und Simulink. Im Rahmen dieses Projektes gibt es Raum für zahlreiche Arbeiten mit übersichtlichem Umfang, die einen schönen (aber in sich abgeschlossenen) Beitrag zur Verbesserung der Handhabbarkeit vom modellbasierten Entwurf leisten können.

Das Projekt selbst soll mit innovativen state-of-the-art Techniken des Software-Entwurfs entwickelt werden und bietet daher den Entwicklern Einblick in einen hoffentlich interessanten Entwicklungsprozess. Dies beinhaltet: Das Framework soll auf Eclipse aufgesetzt werden und selbst modellbasiert mit UML objektorientiert in Java entwickelt werden, wobei auch Projektmanagement Werkzeuge wie Trac zum Einsatz kommen.

Einzelne Themenkomplexe des Projektes:

• Integration in eine Rich-Client Plattform: Eine reichhaltige Plattform wie beispielsweise Eclipse wird immer mehr von Firmen und Entwicklern als Basis für ihre eigenen Werkzeuge genutzt. Dies soll Synergien mit bereits verfügbaren Plug-Ins erzielen, damit sich das eigentliche Projekt nur um seine eigenen Ideen zu kümmern braucht und von anderen Plug-Ins profitieren kann. Außerdem kann somit das eigene Projekt auch leichter in der Allgemeinheit Anwendung finden.
• Innovative Ansätze von Editoren: Strukturbasierte Editoren nehmen dem Entwickler grafischer Modelle die zeitraubenden Layout-Operationen komplett ab. Somit kann man sich voll auf das eigentliche System Under Development (SUD) konzentrieren. Dies kann den Entwicklungsprozess um ein vielfaches effizienter gestalten, wie schon das KIEL Projekt gezeigt hat.
• Synthese von grafischen Modellen: Aus beispielsweise textuellen Beschreibungen eines Modells lassen sich mit automatischem Layout grafische Modelle synthetisieren. Dies kann man beispielsweise (wie in KIEL) dazu nutzen, die Modelle in einem Text-Editor zu manipulieren, wobei Text und Grafik dann automatisch synchronisiert werden. Auch anderen Datenquellen (z.B. Datenbanken) könnten dann als Synthesegrundlage dienen.
• Focus und Kontext: Zur Visulisierung von grafischen Modellen ließe sich die Navigation im Modell automatisieren: Anstatt einer einzigen statischen Ansicht des Modells, in der sich der Benutzer manuell navigieren muss, könnten mehrere dynamisch generierte Ansichten auf die "interessanten" Stellen im Modell einen Fokus legen. Es ließen sich also interessante Operatoren beispielsweise "ausklappen" und andere "einklappen" oder ausblenden. Auch weitere Ansätze sind hier denkbar und bieten ein weites Feld...
• ... Es gibt noch viele weitere Ideen, oder falls Sie eigene Ideen in diesem Kontext mitbringen, umso besser. Sprechen Sie hierzu einfach den Betreuer an!

Betreuung: Claus Traulsen /Reinhard v. Hanxleden

Klassische Prozessorarchitekturen sind auf das Ausführungsmodell sequentieller, imperativer Programmiersprachen ausgerichtet. Dieses Ausführungsmodell ist jedoch wenig geeignet für reaktive Systeme, welche kontinuierlich auf ihre Umwelt reagieren und dabei eine Reihe nebenläufiger Aktivitäten ausführen. Die synchrone Programmiersprache Esterel bietet hier ein besser geeignetes Ausführungsmodell, und es gibt inzwischen Ansätze, dieses Ausführungsmodell auch direkt auf der Prozessorebene zu unterstützen, was Vorteile hinsichtlich Ausführungsgeschwindigkeit, Programmgröße, Stromverbrauch und insbesondere der zeitlichen Vorhersagbarkeit bietet. Der Kiel Esterel Processor (KEP) bietet ein Experimentierfeld für diesen reactive processing Ansatz, und hierzu können eine Reihe von Themen bearbeitet werden. Beispielhaft seien genannt:

• Erweiterung des KEP-Compilers um Unterstützung einer "Host-Language" (z.B. Entwurf eines Compilers, welcher eine Teilmenge von C auf den KEP übersetzt)
• Vergleich zwischen KEP und BAL:

  Die BAL ist virtuelle Maschine für Esterel Programme, die an der Columbia University in der Gruppe von Stephen Edwards entwickelt wurde. Hauptmerkmal ist hierbei die geringe Größe des kompilierten Codes. Die Eigenschaften von KEP und BAL sollen verglichen werden, sowohl als virtuelle Maschinen, als auch als Hardwareimplementierung.

• Eine formale Semantik für KEP Assembler/ Klassifizierung der gültigen KEP Programme:

  Die Semantik des KEP Assemblers ist operational durch die Ausführung des KEPs gegeben. Insbesondere um die Korrektheit der Übersetzung von KEP nach KEP-Assembler nachzuweisen, wäre es wünschenswert, eine direktere Semantik des Assemblers zu haben. In diesem Zusammenhang stellt sich auch die Frage, welche Esterelprogramme überhaupt korrekt auf dem KEP ausgeführ werden können.

• Übersezung von SCADE Modellen in KRP Assembler

Betreuung: Reinhard v. Hanxleden

Die Programmiersprache Esterel besitzt ein synchrones Ausführungsmodell. Dies bedeutet, dass der Status gesendeter Signale konzeptionell sofort in anderen nebenläufigen Programmteilen wirksam wird. Um nun nicht im Kontrollfluss Inkonstistenzen zu erzeugen ist die Reihenfolge der Signal-Sendung und -Auswertung wichtig: Es müssen immer erst potentielle Signal-Sendungen ausgeführt werden, bevor der Signal-Status ausgewertet werden kann. Die Compilation von Esterel Programmen muss also Signal-Abhängigkeiten berücksichtigen. Lässt sich aus strukturellen Gründen in einem Programm eine solche Ausführungs-Reihenfolge nicht herstellen, so muss das Programm als ungültig abgelehnt werden. Führen zyklische Abhängigkeiten dazu, dass die Reihenfolgen von Signal-Aussendungen und -Auswertungen nicht statisch bei der Compilation, sondern erst dynamisch zur Laufzeit aufgelöst werden können, so führt dies i.A. ebenfalls zu einer Ablehnung des Programmes, da dies ein aufwendiges ineffizientes Laufzeitsystem erfordern würde.
Am Lehrstuhl ist nun ein Verfahren entwickelt worden, um solche zyklischen Abhängigkeiten in Esterel-Programmen aufzulösen. Hierzu wird die Struktur des Programmes in Teilen transformiert, die Funktion des Programmes bleibt jedoch erhalten.
In diesem Kontext sind Themenstellungen für Bachelor-/Master-/Diplom- und Studienarbeiten beispielhaft genannt:

• Optimierung der Transformation:
  Bei Nachweis gewisser Eigenschaften eines Esterel-Programmes lassen sich vereinfachte Transformationsregeln anstelle der allgemeinen Lösung anwenden. Dies ermöglicht dann eine effizientere Transformation. Aufgabe ist es nun, solche Vereinfachungen zu erstellen und zu definieren, welche Eigenschaften Esterel-Programme haben müssen, damit diese Vereinfachungen zulässig sind. Die Überprüfung dieser Eigenschaften sollte dann in den Transformationsalgorithmus integriert werden.
• Optimierung von Esterel-Programmen nach der Transformation:
  Die Transformation produziert in der jetzigen Form viel redundanten Code. Dies umfasst beispielsweise neu eingeführte Signale, die emittiert aber nie ausgewertet werden, Signal-Ausdrücke die ein konstantes Ergebnis haben oder Code der nicht erreichbar ist. Ziel dieser Aufgabe ist es nun, solche Redundanzen in einem Esterel-Programm zu erkennen und zu entfernen. Dies muss dabei nicht zwangläufig auf von der Transformation produzierte Programme beschränkt sein.
• Erweiterung des Esterel-Compilers zur Sichtbarmachung des Programmzustandes:
  Bei der Ausführung eines compilierten Esterel-Programmes wird der Zustand der Ausführung in Variablen (bzw. Registern) gehalten. Diese Variablen sind aber aus dem Esterel-Programm heraus nicht verfügbar. Der Ausführungszustand des Programmes wird aber bei der Auflösung zyklischer Abhängigkeiten benötigt. Anstatt nun wie bisher zusätzliche Zustandssignale einzuführen, könnten auch die internen Zustandsvariablen sichtbar gemacht werden. Hierzu ist eine Erweiterung des Esterel-Compilers nötig.
• Erweiterung der Transformation um non-Kernel Statements, valued Signals:
  Die Transformation zyklischer Abhängigkeiten in Esterel-Programmen ist in der bisherigen Lösung auf die Kernel-Befehle von Esterel beschränkt. Befehle die im Kernel nicht enthalten sind, müssen erst in Kernel-Befehle expandiert werden. Eine Erweiterung auf den erweiterten Befehlssatz würde die Effizienz der Transformation verbessern. Weiterhin ist die Transformation bisher nur auf pure-Signals beschränkt. Es fehlt noch eine Berücksichtigung von valued-Signals.
• Anwendung auf Lustre:
  Die Datenfluss-Sprache Lustre basiert ebenfalls wie Esterel auf einem synchronen Ausführungsmodell. Daher sind auch Lustre-Programme anfällig für zyklische Abhängigkeiten. Idee ist nun, die Prinzipien der Transformation konstruktiver zyklischer Esterel-Programme auf zyklische Lustre-Programme anzuwenden.

 Betreuung: Miro Spönemann

Ein sehr wichtiger Teil des KIELER Projekts is das automatische Layout von Eclipse Diagrammen. Hierfür gibt es bereits Werkzeuge, die gute Algorithmen enthalten, so dass viele Diagramme bereits jetzt übersichtlich und automatisiert angeordnet werden können (siehe z.B. Graphviz). Für einige besondere Arten von Diagrammen sind diese allgemeinen Algorithmen jedoch nicht geeignet, da zusätzliche Anforderungen an das Layout erfüllt werden müssen. Beispiele hierfür sind Datenflussdiagramme, wie sie in SCADE und Simulink verwendet werden, oder UML Klassendiagramme.

Dieses Teilprojekt dient zum einen zur Anbindung von Layout-Algorithmen an Eclipse und Implementierung von dafür geeigneten Schnittstellen, und zum anderen zur Entwicklung neuer Algorithmen, die auch mit speziellen Diagrammtypen umgehen können. Dabei sind sowohl sehr praktische Arbeiten, wie die Java-Programmierung für Eclipse, als auch theoretische Arbeiten, wie der Entwurf und die Analyse von Algorithmen auf Basis von Graphentheorie, zu leisten.

Zur Zeit liegt der Schwerpunkt auf dem Layout von Datenflussdiagrammen. Der wesentliche Unterschied dieser Diagramme gegenüber normalen Graphen entsteht durch Ports und Hyperkanten. Es sollen neue Layout-Algorithmen entwickelt werden, die mit diesen Anforderungen umgehen können und gute Zeichnungen liefern. Eine erste Grundlage wurde mit dem hierarchischen Ansatz geschaffen. Weitere Ansätze könnten folgende sein:

• Topology-Shape-Metrics: Die grundlegenden Phasen dieses Ansatzes sind Planarisierung, Orthogonalisierung und Kompaktierung. In diesem Bereich ist einiges an theoretischer Vorarbeit zu leisten, um ein Verfahren zu erhalten, das die Anforderungen von Datenflussdiagrammen berücksichtigt.
• Hierarchisches Layout mit Aufwärtsplanarisierung: Hier wird zunächst eine Aufwärtsplanarisierung durchgeführt, und das Ergebnis wird wie beim hierarchischen Layout nach Sugiyama angeordnet. Es gibt bereits Implementierungen dieses Ansatzes, die für den Umgang mit Ports und Hyperkanten erweitert werden müssten.
• Schaltkreisdiagramme: Diagramme, in denen analoge oder digitale Schaltkreise dargestellt werden, haben eine starke Ähnlichkeit zu Datenflussdiagrammen. Bestehende Verfahren zur Darstellung solcher Diagramme sollten evaluiert und implementiert werden.
• Eigene Ideen: Falls Sie eigene Ideen und Ansätze mitbringen, können diese gerne besprochen werden!