PG-Infoheft WS15/16 - TU Dortmund

INFO
zu den
Projektgruppen
der Fakultät für Informatik
mit
Beginn im WiSe 2015/16
Malte Isberner
Projektgruppen-Beauftragter
OH 14 / Raum 107
Tel.: +49(231)755-5806
E-Mail: [email protected]
Postadresse:
Technische Universität Dortmund
Lehrstuhl Informatik V
44221 Dortmund
Inhalt
• Vorbemerkungen
• Projektgruppen WiSe 2015/16 und Termine der Einzelpräsentationen
• Zum Auswahlverfahren
• Anmeldung zu den Projektgruppen
• Zur Stellung der Projektgruppen in den Prüfungsordnungen
• Übersicht zu den Voraussetzungen der einzelnen Projektgruppen
• Kurzbeschreibung der Projektgruppen
Vorbemerkungen
Projektgruppen gibt es an den Hochschulen der Bundesrepublik seit ca. 1970. Sie wurden im wesentlichen aufgrund der Forderungen von Studenten der 68-er und Nach-68-er Generation in Studienpläne und
Prüfungsordnungen aufgenommen. Zentrale Forderungen waren:
• selbstbestimmtes Lernen
• interdisziplinäre Ausbildung
• berufsbezogene Studiengänge
wobei gesellschaftsbezogene Aspekte des Studiums besonders betont werden sollten. Wenn in der Fakultät
für Informatik auch lediglich der „Berufspraxisbezug“ der Ausbildung die wesentliche Begründung für die
Einführung der Projektgruppen bildete, erscheinen vor obigem Hintergrund die folgenden Überlegungen
wichtig. Lernende und Lehrende kommen bei der Projektarbeit in eine völlig neue, ungewohnte und sicherlich teilweise schwierig zu akzeptierende Situation. Für die Studenten heißt das zunächst: weg von der
Konsumentenhaltung aus Vorlesungen, weg vom Bearbeiten vorgegebener Aufgaben aus Übungen, Praktika
und Seminaren – stattdessen selbständiges Strukturieren der Arbeit, selbständiges Erarbeiten von Problemen und eigenverantwortliches Lösen der Probleme. Für die Lehrenden heißt das: weg von der Rolle als
nie versagende Wissensquelle, die auch in der schwierigsten Situation immer noch eine richtige Lösung
hervorbringt – stattdessen auch Zugestehen von fachlicher Autorität an Studenten. Und das wiederum heißt
zu akzeptieren, dass die Lehrenden weder für alle fachlichen Probleme fertige Lösungen, noch bei jeder
persönlichen Auseinandersetzung ideale Ratschläge zur Verhinderung von Streitigkeiten haben.
Zusammengefasst heißt das:
Projektarbeit lebt vom Engagement der Projektgruppenmitglieder (Studenten und Veranstalter) und stirbt
bei einem Mangel davon. Noch stärker als bei anderen Lehrveranstaltungsformen liegt es in der Verantwortung jedes Teilnehmers (auch hier Studenten und Veranstalter), was er für sich und die Gruppe daraus
macht.
Projektgruppen WiSe 2015/16 und Termine der Einzelpräsentationen
Nr.
Veranstalter
Einzelpräsentation
Krumm, Burkert
01.06.2015, 15:15 Uhr,
OH16/205
B Big Data – Datenanalyse im großen Stil
Morik, Bockermann
26.05.2015, 14:15 Uhr,
OH12/4.013
C Solar Doorplate – Energiegewahre Systemsoftware für ubiquitäre Systeme
Lochmann, Buschhoff,
Spinczyk
01.06.2015, 16:00 Uhr,
OH16/205
D
Spielende kooperierende Agenten
Quadflieg, Hildebrand,
Eichhorn
21.05.2015,
14:1515:45 Uhr, OH12/3.013
E
MoSAIC – Model-based Self-Adaption of
Industry 4.0 Configurations
Neubauer, Naujokat,
Bauer, Steffen
28.05.2015, 14:15 Uhr,
OH14/105
A
Thema der Projektgruppe
Gamification4Rehabilitation
Zum Auswahlverfahren
Bei der Anmeldung ist anzugeben, mit welcher Priorität Sie welche Projektgruppe wählen:
1=höchste Priorität
5=niedrigste Priorität
0=an dieser PG bin ich nicht interessiert
Es ist nicht erlaubt, die gleiche Priorität mehrfach zu vergeben. Jeder Veranstalter erhält die Anmeldungen, bei denen seine Projektgruppe mit erster Priorität angegeben ist und wählt sich seine Teilnehmer nach
fachlichen Gesichtspunkten aus. Nicht besetzte Plätze in einer Projektgruppe werden durch überzählige
Studenten aus anderen Projektgruppen entsprechend den Prioritäten besetzt. Jede Projektgruppe muss mindestens 8 und darf höchstens 12 Teilnehmer haben.
Die PG-Teilnehmer werden nach folgendem Verfahren ausgewählt und auf die PGs verteilt:
1. Die Projektgruppen-Bewerberinnen und Bewerber werden gemäß ihrer ersten Priorität denVeranstalterinnen und Veranstaltern zugeordnet.
2. Die Projektgruppen-Veranstalterinnen und Veranstalter wählen davon insgesamt maximal neun Teilnehmerinnen und Teilnehmer aus.
3. Weitere Teilnehmerinnen und Teilnehmer werden aus dem Bewerber-Pool mit ersten Priorität abhängig vom Zeitpunkt ihres Vordiploms bzw. Beginn des Master-Studiums (je weiter in der Vergangenheit, um so größere Priorität) bestimmt; bei gleichem Zeitpunkt entscheidet das Los. Wenn
eine Bewerberin oder ein Bewerber bereits eine Projektgruppe aus Gründen, die sie oder er selbst
zu verantworten hat, abgebrochen hat oder ausgeschlossen wurde, zählt der Zeitpunkt an dem diese
Projektgruppe abgeschlossen wurde oder wird.
4. Ist die Gesamtzahl von zwölf Teilnehmerinnen und Teilnehmern in einzelnen Projektgruppen nicht
erreicht, wird das Verfahren ab (2) gemäß der zweiten Priorität, in weiteren Runden gemäß der dritten
Priorität etc. durchgeführt.
5. Die Projektgruppen-Beauftragten führen nach Abschluss des Vergabeverfahrens Nachrückerlisten aus
denen die Veranstalterinnen und Veranstalter in Absprache mit den Projektgruppenbeauftragten eine
Bewerberin oder einen Bewerber auswählen, um alle Projektgruppenplätze zu besetzen, wenn eine
Teilnehmerin oder ein Teilnehmer einen Platz nicht in Anspruch nimmt.
Anmeldung zu den Projektgruppen
Vordiplom / begonnenes Master-Studium ist Voraussetzung (Stichtag: 03.06.2015)
Die Anmeldung erfolgt bis zum
03.06.2015 (12:00 Uhr)
online unter
https://projektgruppen.cs.tu-dortmund.de
Hier finden Sie auch weitere Informationen zu den Projektgruppen.
Zur Stellung der Projektgruppen in der Prüfungsordnungen
Master Die Projektgruppe stellt ein unbenotetes Pflichtmodul in den Masterstudiengängen Informatik
und Angewandte Informatik dar. Kriterien zum Bestehen des Moduls sind in der Projektgruppenordnung
näher erläutert.
Diplom Die Teilnahme an einer Projektgruppe ist Pflicht für alle diejenigen Studenten, die im Hauptfach
Informatik oder Ingenieur-Informatik studieren. Für die erfolgreiche Teilnahme gibt es einen Schein, der
dem Antrag auf Zulassung zur letzten Diplomprüfung beigefügt werden muss. Kriterien zur Scheinvergabe
sind in der Projektgruppenordnung näher erläutert.
Projektgruppenordnung
Die Projektgruppenordnung im Web unter dem folgenden Link abrufbar:
http://projektgruppen.cs.tu-dortmund.de/
Hinweis zum Arbeitsaufwand in Projektgruppen:
Immer wieder gibt es Diskussionen über den Arbeitsaufwand, der für eine Projektgruppe aufgebracht werden muss. Für die Studierenden ist es wichtig zu wissen, dass die im Vorlesungsverzeichnis genannten
8 SWS pro Semester NICHTS bzw. nur wenig mit dem tatsächlichen Arbeitsaufwand zu tun haben, der
für die PG-Arbeit notwendig ist. In gleicher Weise, wie z. B. bei einer Lehrveranstaltung mit 6 SWS (4
SWS Vorlesung, 2 SWS Übung) erhebliche Vor- und Nacharbeit bis zum Bestehen der Prüfung notwendig ist, ist auch bei PGs deutlich mehr Zeit aufzubringen als etwa 8 Stunden pro Woche. Man rechnet für
durchschnittlich begabte Studierende mit dem Faktor 2,5 über die gesamten 2 Semester, auch hier wie bei
Prüfungen inkl. der vorlesungsfreien Zeit. Durchschnittlich begabte Studierende sollten mit einer tatsächlichen durchschnittlichen Arbeitsbelastung von etwa 15-20 Stunden pro Woche rechnen, weniger Begabte
wie bei Prüfungen mit teilweise deutlich mehr, sehr Begabte mit deutlich weniger. Die Teilnahme an weiteren Lehrveranstaltungen ist entsprechend zu planen. Der Aufwand für die PG sollte etwa der Hälfte eines
Vollzeitstudiums entsprechen.
Ansprechpartner:
Sollte es im Verlauf der Projektgruppenarbeit zu Schwierigkeiten, z. B. wegen zu hoher Anforderungen,
zu großem Arbeitsaufwand oder ähnlichem kommen, steht der Projektgruppenbeauftragte der Fakultät für
Informatik als Ansprechpartner zur Verfügung.
Übersicht zu den Voraussetzungen der einzelnen Projektgruppen
(V) Voraussetzung
(W) wünschenswert
(M) mindestens eine
(2) mindestens zwei
A: Gamification4Rehabilitation (Krumm, Burkert)
• Kenntnisse im Bereich Rechnernetze und verteilte Systeme (V)
• Kenntnisse in der objektorientierten Programmierung in Java (V)
• Kenntnisse Service-orientierter Architekturen (W)
B: Big Data - Datenanalyse im großen Stil (Morik, Bockermann)
• Programmierkenntnisse in Java (V)
• Kenntnisse in objektorientierter Modellierung und Programmierung (V)
• DVEW – Vorlesung Darstellung, Verarbeitung und Erwerb von Wissen (W)
• KI/ML – Vorlesung Künstliche Intelligenz/Maschinelles Lernen (W)
• KDD – Vorlesung Wissensentdeckung in Datenbanken (W)
• Vorlesung Verteilte Algorithmen (W)
C: Solar Doorplate - Energiegewahre Systemsoftware für ubiquitäre Systeme (Lochmann, Buschhoff,
Spinczyk)
• Kenntnisse aus der Vorlesung „Betriebssystembau“, „Software ubiquitärer Systeme“ oder einer vergleichbaren, nachgewiesen durch erfolgreiche Prüfung oder Übungsteilnahme (einschließlich der laufenden Veranstaltung „Software ubiquitärer Systeme“) (V)
• Verständnis englischsprachiger Artikel und Handbücher (V)
• Unix-/Linux-Kenntnisse (W)
• Programmierkenntnisse C/C++ (W)
• Hardwarenahe Programmierung (W)
D: Spielende kooperierende Agenten (Quadflieg, Hildebrand, Eichhorn)
• Erfolgreicher Abschluss wenigstens einer der Veranstaltungen Darstellung, Verarbeitung und Erwerb
von Wissen (DVEW) oder Einführung in die Computational Intelligence, oder Nachweis vergleichbarer Kenntnisse (V)
• Erfahrungen im Umgang mit unixartigen Betriebssystemen (W)
• Praktische Kenntnisse in objektorientierter Programmierung, z.B. in der Sprache C# (W)
• Vorkenntnisse im Bereich Wissensrepräsentation und/oder Computational Intelligence, wie sie zum
Beispiel durch Besuch der Master-Veranstaltungen Commonsense Reasoning oder Fortgeschrittene
Themen der Wissensrepräsentation erworben werden können (W)
• Vorkenntnisse zu Unity3D, z.B. aus dem Fachprojekt Digital Entertainment Technologies (W)
E: MoSAIC - Model-based Self-Adaption of Industry 4.0 Configurations (Neubauer, Naujokat, Bauer,
Steffen)
• Fundierte Kenntnisse in mindestens einer objektorientierten Programmiersprache, zum Beispiel Java
oder C(++|#) (V)
• Elementare Kenntnisse über Modellierungstechniken, wie sie zum Beispiel in den Vorlesungen „Formale Methoden des Systementwurfs“, „Virtualisierung und Compilation“, „Softwarekonstruktion“
und „Dienstleistungsinformatik“ vermittelt werden (V)
• Kenntnisse im Umgang mit Eclipse-Werkzeugen und -Programmierung (W)
• Kenntnisse im Bereich der Automatisierungstechnik (W)
9
A) Gamification4Rehabilitation
1. Thema der Projektgruppe:
Gamification4Rehabilitation
2. Zeitraum:
WS 2015/2016 und SS 2016
3. Veranstalter: Prof. Dr. Heiko Krumm / M.Sc. Malte Burkert
Fakultät für Informatik, LS IV, FG RvS, OH16, Raum 217/219, Tel.
4674/5427
4. Aufgabe
In den letzten Jahren wurde die Entwicklung rund
um die Erfahrung virtueller Welten immer weiter
getrieben. Nachdem verschiedenste VideospielPlattformen kaum merkliche Weiterentwicklungen
mehr hinsichtlich des Spieleerlebnis gemacht
haben, wurde 2006 die Spielekonsole Wii auf den
Markt gebracht.
Der klassische Spielekontroller wurde durch einen
bewegungssensitiven Kontroller ausgetauscht, Abbildung 1 Paperdude VR der Firma Globacore
durch den die Steuerung von Videospielen durch
Bewegungen möglich wurde. Es folgten 2010 die PlayStation-Move mit einem ähnlichen Ansatz
sowie die Kinect-Kamera von Microsoft, durch die gänzlich auf einen Kontroller verzichtet werden
kann. Durch die Kinect können Spiele auch ausschließlich durch Bewegungen des Körpers
gesteuert werden.
Neben der Entwicklung von unterschiedlichen Steuerungsmöglichkeiten wurde auch an der
Wahrnehmung virtueller Realitäten gearbeitet. Ausgabegeräte, wie z.B. die Oculus Rift,
Großbildleinwände oder den Betrachter umgebende Displays erzeugen ein Gefühl der Immersion.
D.h. die betrachtende Person taucht immer weiter in die virtuelle Welt ein und hat ein verstärktes
Gefühl ein Teil dieser Welt zu sein.
Die Kombination der Kontrolle virtueller Realitäten über natürliche Körperbewegungen mit einer
gesteigerten Immersion führt zu einer neuen Wahrnehmung virtueller Realitäten. Diese
Wahrnehmung kann insbesondere bei der Umsetzung von Sportspielen ausgenutzt werden. Der
reine Spielegedanke rückt in den Hintergrund und die sensorbasierte Spieleumgebung kann zum
Beispiel für medizinisch motivierte sportliche Aktivitäten genutzt werden.
Im medizinischen Umfeld führen sportliche Aktivitäten zum Beispiel nach einem Herzinfarkt oder
einer Herzklappenoperation zur unmittelbaren Verbesserung der Lebensumstände, so dass
Patienten so schneller in das alltägliche Leben zurückkehren können. Häufig sinkt im Alltag jedoch
die Motivation für das regelmäßige Durchführen von Rehabilitationsmaßnahmen, obwohl diese
notwendig wären. Eine sensorbasierte Spieleumgebung kann im Rehabilitationssport genutzt
werden, um die langfristige und regelmäßige Durchführung notwendiger Übungen zu
gewährleisten.
Erhöhung des Immersionsgrades in einer sensorbasierten Spieleumgebung
Ergometer werden nicht nur in Rehabilitationszentren oder Fitnessstudios, sondern häufig auch zu
Hause für Rehabilitationsmaßnahmen oder aus rein sportlichen Gründen (Ausdauertraining im
Winter) eingesetzt. Um Monotonie und abnehmender Motivation beim Training vorzubeugen, wird
eine virtuelle Realität erzeugt, so dass ein regelmäßiges Training wahrscheinlicher ist. Der Spieler
begibt sich hierfür in eine 3D-Welt, in der er Aufgaben löst und sich mit anderen
Spielern/Spielständen messen kann. Ein reales mit Sensorik ausgestattetes Ergometer sowie die
Körperbewegungen dienen der Steuerung des Spielgeschehens. Vorbild für die Aufgabe der
10
A) Gamification4Rehabilitation
Abbildung 2 a) Flugsimulator für die Pilotenausbildung b)
Aufbau des Hörorgans c) 4D-Kino mit sich bewegenden
Sesseln d) Ergometer auf Bewegungsplattform
1
Projektgruppe ist das Projekt Paperdude VR der Firma Globacore (s. Abbildung 1). Hier wird ein
Spielerlebnis mit Hilfe einer Kinect, der Oculus Rift sowie einem Ergometer erzeugt. Ein typisches
Szenario eingebettet in den Kontext einer Rehabilitation könnte beispielsweise wie folgt aussehen:
Frau D. ist 42 Jahre alt und wurde nach einer Vorsorgeuntersuchung als Risikokandidat für eine
Herzerkrankung eingestuft. Um typischen Risikofaktoren für diese Erkrankung vorzubeugen nimmt
sie an dem Pilotprojekt „Gamification4Rehabilitation“ teil. Dazu legt sie sich vor der
Trainingseinheit medizinische Sensoren an, die für die Überwachung ihrer Vitalparameter benötigt
werden und der Dokumentation des Trainingsfortschritts dienen. Anschließend setzt sie sich auf
das mit weiterer Sensorik ausgestattete Ergometer, setzt sich die 3D-Brille auf und begibt sich für
ihre Trainingsmaßnahme in eine virtuelle Realität.
Frau D. wählt eingangs den Spielmodus Paperboy (ein Videospiel-Klassiker von 1984) aus,
dessen Ziel es ist durch eine Straße mit Hindernissen zu fahren und Zeitungen zu verteilen. Die
Zeitungen werden beim Vorbeifahren in Briefkästen und Einfahrten geworfen. Punkte gibt es für
ausgewichene Gegenstände und mit Zeitungen getroffene Briefkästen und Einfahrten.
Frau D. ist gut dabei und schafft es den meisten Hindernissen auszuweichen. Lediglich mit der
Treffsicherheit läuft es noch nicht so gut. Die Koordination von Fahren und gleichzeitigem Werfen
der Zeitungen erfordert Konzentration und ist ziemlich anstrengend für Frau D. Am Ende der Fahrt
bekommt sie ihren Punktestand angezeigt und sieht, dass sie sich im Vergleich zu ihren letzten
Fahrten verbessert hat. Sie hat einen neuen Highscore aufgestellt.
Durch die Beschreibung wird klar, dass trotz 3D-Brille, Ergometer und Erkennung der
Wurfbewegungen durch eine Kinect-Kamera ein wichtiger Punkt zur realistischen Wahrnehmung
der virtuellen Fahrt fehlt. Für ein vollständiges immersives Fahrgefühl fehlt die Rückkopplung aus
der virtuellen in die reale Welt. Es werden lediglich Bewegungen aus der realen in die virtuelle
Welt übertragen. Es fehlt jedoch ein fehlendes mechanisches Feedback des Systems, welches im
Rahmen der Projektgruppe durch eine Bewegungsplattform auf der das Ergometer (s. Abbildung
2d) angebracht ist, umgesetzt werden soll.
Der gleiche Effekt wird bereits in der Ausbildung von Piloten in Flugsimulatoren (s. Abbildung
2a)2) oder in sogenannten 4D- bzw. 5D-Kinos (Kinositze befinden sich auf einer sich bewegenden
1
2
http://www.globacore.com/paperdude-vr/
http://www.flugsimulator.com/lufthansa-flugsimulator.html
11
A) Gamification4Rehabilitation
3
Plattform Abbildung 2c) eingesetzt. Die Bewegung, die im Flugsimulator oder im Kinosaal
erzeugt wird, wird vom Menschen in den Bogengängen des Ohrs wahrgenommen (s. Abbildung
2b)4. Die in den Bodengängen befindliche Flüssigkeit schwappt umher und vermittelt den
Bewegungseindruck.
Technischer Hintergrund
Im Rahmen der Projektgruppe sollen verschiedene aktuelle Themen aus der Informatik bearbeitet
werden. Mit den einzelnen Komponenten, wie der Kinect oder der Oculus Rift hat sich die IT
inzwischen schon relativ ausführlich beschäftigt. Die Kombination der Einzelkomponenten soll es
ermöglichen eine spielgetriebene Rehabilitationsmöglichkeit zu schaffen. Ein aus vernetzten
Komponenten bestehendes System das realle und virtuelle Elemente kombiniert wird auch als
Cyper-Physical-System (CPS) bezeichnet.
Die Schnittstelle zur virtuellen Realität besteht aus dem technisch modifizierten Ergometer
(Lenkbewegung sowie Bremskraft ist über entsprechende Sensorik softwaretechnisch
auswertbar), der Oculus Rift (Senorik für die Bewegung des Kopfes) sowie einer Kinect, die die
Körperbewegungen des Patienten erfassen. Diese wird in der virtuellen Realität für die Steuerung
des Spielgeschehens genutzt. Neben der visuellen Darstellung der virtuellen visuellen Realität
über die Oculus Rift, ist ein spürbares Feedback des Systems einerseits durch die
Bewegungsplattform, die mit Hilfe einer speicherprogrammierbaren Steuerung kontrolliert werden
kann sowie andererseits durch die Kontrolle des Trittwiderstands vom Ergometer gegeben. So
können z.B. verschiedene Untergrundbeläge, Hindernisse oder Steigungen in der Spielwelt in der
realen Welt erfahrbar gemacht werden.
Der Einsatz dieser Vielzahl an technisch unterschiedlichen Geräten bedingt die
Auseinandersetzung mit der Kommunikation in verteilten System und somit der Anwendung
verschiedener Kommunikationsprotokolle, Systementwürfe und Schnittstellen der Einzelsysteme
untereinander. Mit einer möglichen Erweiterung zur Mehrspielerfähigkeit muss auch die erhöhte
Komplexität eines solchen Systems im Systementwurf und bei der Umsetzung beachtet werden.
Die 3D-Welt und die virtuelle Realität stellt eine weitere Basis für die spielbasierte
Rehabilitationsmaßnahme dar. Sie bietet somit einen weiteren Teilbereich der Informatik mit dem
sich die Projektgruppe auseinandersetzen muss. Es muss eine geeignete Spiele-Engine (z.B.
Unity3D) gewählt werden, um ein immersives Spielerlebnis umsetzen zu können. Sensordaten
müssen entsprechend aufbereitet und in der virtuellen Welt widergespiegelt werden. Außerdem
müssen Spielereignisse und –Situationen entsprechend mit Hilfe von Bewegungsplattform und
Trittwiderstand des Ergometers von der virtuellen in die reale Welt transformiert werden. Bei der
Umsetzung ist kein sehr hoher Grad an Realitätsnähe erforderlich, da es primär um den Spaß für
den Patienten bzw. Spieler geht.
Industrielle Partner
Die Umsetzung des Projekts geschieht in Kooperation mit verschiedenen Partnern aus Industrie
und Gesundheitsweisen. Die Schüchstermann-Schiller’schen Kliniken, eines der großen
Herzzentren Deutschlands, steht dem Projekt für medizinische Fragen zur Seite. Dazu wird die
Projektgruppe die Klinik besuchen und vor Ort die Anforderungen an die Umsetzung des Projekts
definieren. Der Großteil im Projekt verwendeten medizinischen Sensoren wird von der Firma
Corscience bereitgestellt, die bei Klärungsbedarf zur Verfügung steht.
3
4
http://www.seereisedienst.de/uploads/pics/msc-orchestra-4d-kino.jpg
http://www.apotheken-umschau.de/Ohren/Morbus-Meniere-Ursachen-148959_2.html
12
A) Gamification4Rehabilitation
Ziele der Projektgruppe
Ziel der PG ist es, Konzepte und Ideen für die Umsetzung eines Spieles für die Unterstützung von
Rehabilitationsmaßnahmen zu erarbeiten. Hierbei soll eine sensorgestützte Spieleplattform
entwickelt werden, die die folgenden Sensoren und Komponten zur immersiven Wahrnehmung
umfassen soll: Kinect, Oculus Rift, auf Bewegungsplattform montiertes Ergometer. Das Ergometer
sowie Körperbewegungen sollen primär die Steuerung des virtuellen Spielecharakters
übernehmen, während die Oculus Rift und die Bewegungsplattform für die Erzeugung einer
immersiven Wahrnehmung verwendet werden sollen.
Außerdem sollen gezielt Sensoren für die Überwachung von Vitalparametern eingesetzt werden
(wie z.B. Sensor für Herzfrequenz-Messung). Die geeignete Wahl und Einbettung in das
Gesamtkonzept ist im Rahmen der Projektgruppe zu entwickeln.
Als Ausgangsbasis für die Umsetzung dienen Technologien für die Spiele-Engine (z.B. Unity3D),
für die Middleware (z.B. OSGi) und für die Bewegungsplattform, welche evaluiert und ausgewählt
werden müssen. Die Minimalziele werden im Abschnitt 6 detailliert ausgeführt. Diese können
durch die Umsetzung weiterer Spiele, Einbindung weiterer Sensoren oder Komponenten zur
direkten Überwachung der Vitalparameter durch einen Arzt erweitert werden.
5. Teilnahmevoraussetzungen
Voraussetzungen:
Wünschenswert:
Kenntnisse im Bereich Rechnernetze und verteilte Systeme
Kenntnisse in der objektorientierten Programmierung in Java
Kenntnisse Service-orientierter Architekturen
6. Minimalziel
Das Minimalziel der Projektgruppe besteht aus folgenden Punkten



Konzeptionierung und Umsetzung eines Spieles (z.B. Paperboy) unter Verwendung der oben
genannten Sensorik (Kinect, Oculus Rift, erweitertes Ergometer inkl. Bewegungsplattform sowie
medizinische Sensoren)
Entwicklung eines Steuerungssystems, das Systemgrößen der virtuellen Welt auf die
Bewegungsplattform überträgt
Darstellung des Spielgeschehens für außenstehende Betrachter des Systems
7. Literatur
a)
Bücher und Artikel zum Einlesen



b)
Gerd Wütherich, Nils Hartmann, Bernd Kolb, Mathias Lübken: Die OSGi Service Plattform. dpunkt.verlag, 2008
Broy, Manfred.: Cyber-Physical Systems: Innovation durch softwareintensive eingebettete Systeme. Springer,
2010
Melzer, Ingo: Service-orientierte Architekturen mit Web Services: Konzepte – Standards – Praxis. Spektrum
Verlag, 2010
Wissenschaftliche Publikationen




Dobrev, Famolari, Kurzke, Miller: Device and service discovery in home networks with OSGi, Computer
Magazine, IEEE, Aug 2002, Volume: 40, Issue: 8, S. 86-92
Lee, E.A., “Cyber Physical Systems: Design Challenges”, Object Oriented Real-Time Disitributed Computing
(ISORC), 2008 11th IEEE International Symposium on, pp. 363-369, 5-7 May 2008
Myriam Lipprandt, Jan Krüger, Detlev Willemsen, Christoph Fiehe, Elmar Zeeb, et al.: “OSAMI-D: An Open
Service Platform for Healthcare Monitoring Applications”, IEEE International Conference on Human System
Interaction (HIS 2009), Catania, Italien, 2009
O. Schulzyk et al.: A Bicycle Simulator Based on a Motion Platform in a Virtual Reality Environment – FIVIS
Project, Advances in Medical Engineering, Springer Proceedings in Physics Volume 114, 2007
8. Rechtlicher Hinweis
Die Ergebnisse der Projektarbeit und die dabei erstellte Software sollen der Fakultät für Informatik
uneingeschränkt für Lehr- und Forschungszwecke zur freien Verfügung stehen. Darüber hinaus sind keine
Einschränkungen der Verwertungsrechte an den Ergebnissen der Projektgruppe und keine
Vertraulichkeitsvereinbarungen vorgesehen.
13
B) Big Data
Projektgruppenantrag
1. Thema Big Data – Datenanalyse im großen Stil
2. Zeitraum Wintersemester 2015/2016 und Sommersemester 2016
3. Umfang
8 SWS pro Semester
4. Veranstalter
Prof. Dr. Katharina Morik
Fachbereich Informatik
Lehrstuhl 8
OH-12 Raum 4.007
Tel. 0231/755-5101
[email protected]
Dipl.-Inf. Christian Bockermann
Fachbereich Informatik
Lehrstuhl 8
OH-12 Raum 4.019
Tel. 0231/755-6487
[email protected]
5. Aufgabe
Die Aufgabe der Projektgruppe ist die Zusammenstellung und Implementierung einer
Umgebung um Analyseprozesse f¨
ur große Datenmengen auf Basis moderner, verteilter
Big Data Architekturen auszuf¨
uhren. Die Grundlage f¨
ur die Untersuchung solcher Architekturen bildet ein Anwendungsfall der Astro-Physik, bei dem jede Nacht Datenmengen
im Terabyte-Bereich gesammelt werden.
Motivation Die Verarbeitung großer Mengen von Daten ist zu einer Schl¨
usselqualifikation in der heutigen IT-Landschaft geworden. Waren bisher SQL Datenbanken gefragt,
mangelt es Unternehmen heute immer mehr an Experten, die mit Big Data Technologien wie Map&Reduce, NoSQL, verteilten Key-Value Stores oder verteilten Streaming
Engines umgehen k¨onnen. Dabei geht es nicht mehr nur um Datenmassen, die in riesigen
Datencentern gespeichert liegen und darauf warten, analysiert zu werden, sondern immer mehr um die realzeitliche Verarbeitung von Daten: Je schneller das Ergebnis einer
Analyse bereitsteht, um so schneller kann man darauf basierend Entscheidungen treffen.
Die unterschiedlichen Anforderungen an die Analyse hat f¨
ur die Modellierung von Big
Data Systemen in den letzten Jahren die sogenannte Lambda-Architektur hervorgebracht:
λ-Architektur
Speed Layer
Serving Layer
Batch Layer
Basierend auf einer Dreiteilung in Serving-Layer, Batch-Layer und Speed-Layer sind
moderne Big Data Systeme eine Zusammenstellung unterschiedlicher verteilter Komponenten. F¨
ur jede dieser Komponenten existieren m¨
achtige Open-Source Frameworks,
wie beispielsweise die freie Implementierung des Map&Reduce Paradigmas [4] im Apache
Hadoop Projekt. Mit Apache Kafka [8, 7] oder Apache Storm [5] gibt es hochskalierbare,
clusterf¨
ahige Systeme f¨
ur die Echtzeitverarbeitung von Datenstr¨
omen.
1
14
B) Big Data
Modellierung von Big Data Umgebungen Die Entwicklung der unterschiedlichen Big
Data Komponenten erfordert ein hohes Maß an Expertenwissen, um die jeweiligen Umgebungen an einen bestimmten Anwendungsfall anzupassen. Es fehlt zudem ein vereinheitlichender Ansatz, um Big Data Systeme einfach zu modellieren. Der Sonderforschungsbereich SFB-876 der TU Dortmund widmet sich seit geraumer Zeit der Analyse
von Daten im Rahmen von Big Data. Das am Lehrstuhl 8 entwickelten streams Framework bietet einen Ansatz in diese Richtung: Mit Hilfe eine Abstraktionsschicht (API),
sowie einer XML Beschreibung lassen sich mit streams Datenfl¨
usse modellieren und in
verschiedenen Komponenten einer Big Data Architektur ausf¨
uhren. Andere Ans¨
atze, wie
RapidMiner Radoop, versuchen, bestehende Modellierungs- und Analysewerkzeuge wie
RapidMiner [9] auf Big Data Systeme zu portieren.
Big Data Analyse von Astrophysikalischen Experimenten
Die Projektgruppe widmet sich genau diesem aktuellen Thema und wird die Konzepte moderner Big Data Architekturen nicht nur kennenlernen, sondern an einer realen,
physikalischen Forschungsfrage erproben: Der Fachbereich Physik der TU Dortmund
betreibt, zur Untersuchung kosmischer Strahlung [6], das FACT Teleskop [1] auf der
Insel La Palma. Ziel derartiger Cherenkov Teleskope ist die Suche und Charakterisierung
von Quellen kosmischer Strahlung anhand von Cherenkov-Strahlung, die als Effekt der
Gamma-Strahlen meßbar ist. Durch langfristige Beobachtung k¨
onnen so Supernovaexplosionen, Kollisionen von Neutronensternen oder aktive galaktische Kerne (hinter denen
supermassive Schwarze L¨ocher stecken) erkannt und untersucht werden [3].
Das FACT Teleskop stellt einen Prototypen f¨
ur mehrere, geplanten Arrays von Cherenkov Teleskopen dar (CTA Projekt). Das einzelne FACT Teleskop selbst erzeugt dabei
je Nacht Daten von etwa 1 TB Umfang. F¨
ur die Untersuchung der kosmischen Strahlung basierend auf den Teleskop-Daten ist eine Datenvorverarbeitung auf dem riesigen
Datenbestand notwendig (vgl. Abbildung 1).
Calibration,
Cleaning
Feature
Extraction
Signal
Separation
Energy
Estimation
Abbildung 1: Verarbeitungsschritte der FACT Teleskop-Daten
Die Physik entwickelt diese Verarbeitungskette auf einer sehr anwendungsspezifischen
Ebene, ohne eine weitergehende Ber¨
ucksichtigung einer verteilten, hochskalierenden Umsetzung. Die Modellierung der FACT Vorverarbeitung erfolgt u
¨ber die XML Spezifikationen des streams Frameworks [2], das innerhalb des SFB-876 an der TU Dortmund
entwickelt wurde.
Im Rahmen dieser Projektgruppe sollen nun unterschiedliche Tools und Systeme untersucht werden, mit Hilfe derer die physikalischen Daten m¨
oglichst effizient verarbeitet werden k¨
onnen. Dazu m¨
ussen die XML-Prozessmodelle der Physiker auf verteilte Prozesse
skalierbarer Clustersysteme abgebildet werden. Ein erster Prototyp f¨
ur die Ausf¨
uhrung
von XML spezifizierten Prozessen auf Apache Hadoop existiert bereits und kann als
Grundlage f¨
ur die Projektgruppe benutzt werden.
2
15
B) Big Data
Mit dem Cluster des Sonderforschungsbereiches steht der Projektgruppe eine ComputingUmgebung bereit, um Big Data Anwendungen zu modellieren und umzusetzen. Das
erm¨
oglicht den Teilnehmern
• die Konzepte und Umsetzung verteilter Anwendungen in einem eigenen Cluster
kennen zu lernen;
• aktuelle Big Data Systeme in einer realen Umgebung zu testen;
• Skalierungsproblematiken und Ausfallsicherheit zu untersuchen;
• sich Schl¨
usselqualifikationen f¨
ur aktuelle Technologien anzueignen.
Ziel ist dabei sowohl, dass die Teilnehmer sich eine Expertise im Umgang mit Big Data
Architekturen aneignen, als auch die Entwicklung einer Plattform zum Modellieren von
Big Data Anwendungen, basierend auf bestehender Software (Integration). Die Projektgruppe bietet damit die M¨oglichkeit, sich in einem extrem spannenden Umfeld mit den
packenden Forschungsfragen aktueller IT-Systeme zu besch¨
aftigen und diese innerhalb
der Datenanalyse eines realen Forschungsprojektes auszuprobieren.
Die Ergebnisse der Projektgruppe sollen die Physiker dabei unterst¨
utzen, ihre Analysen
in Zukunft noch effizienter durchzuf¨
uhren – ohne dabei selbst in die Tiefen der Big Data
Technologien abtauchen zu m¨
ussen. Eine gute Umsetzung von z.B. streams Prozessen auf
Cluster-Umgebungen soll nach M¨oglichkeit auch zur realzeitlichen Analyse der TeleskopDaten vor Ort genutzt werden. F¨
ur einen single-node Ansatz basierend auf streams ist
dies bereits der Fall.
6. Teilnahmevoraussetzungen
1. Programmierkenntnisse in Java (V)
2. Kenntnisse in objektorientierter Modellierung und Programmierung (V)
3. DVEW - Vorlesung Darstellung, Verabeitung und Erwerb von Wissen (W)
4. KI/ML - Vorlesung K¨
unstliche Intelligenz /Maschinelles Lernen (W)
5. KDD - Vorlesung Wissensentdeckung in Datenbanken (W)
6. Vorlesung Verteilte Algorithmen (W)
(V) – Voraussetzung; (W) – w¨
unschenswert.
7. Minimalziele
Die Projektgruppe bietet den Teilnehmern ein hohes Maß an Flexibilit¨
at zur Ausgestaltung der beiden Semester. Die Folgenden Punkte sind als Minimalziel gesetzt:
1. Ausf¨
uhrung einfacher XML Prozessdefinitionen auf einem Hadoop Cluster
2. Umsetzung und Evaluierung der Datenvorverarbeitung von FACT Daten mit verschiedenen Big Data Systemen
3. Konzeptionierung, Entwurf und Implementierung eines generischen Modellierungstools f¨
ur Big Data Systeme
4. Erstellen eines Endberichts
3
16
B) Big Data
8. Rechtlicher Hinweis
Die Ergebnisse der Projektarbeit und die dabei erstellte Software sollen den Fachbereichen der TU Dortmund uneingeschr¨
ankt f¨
ur Lehr- und Forschungszwecke zur freien
Verf¨
ugung stehen. Dar¨
uber hinaus sind keine Einschr¨
ankungen der Verwertungsrechte
an den Ergebnissen der Projektgruppe und keine Vertraulichkeitsvereinbarungen vorgesehen.
Literatur
[1] H. Anderhub et al. Fact - the first cherenkov telescope using a g-apd camera for
tev gamma-ray astronomy. Nuclear Instruments and Methods in Physics Research
A, 639:58–61, May 2011.
[2] Christian Bockermann. The streams framework, 2012.
[3] Bradley W. Carroll and Dale A. Ostlie. An Introduction to Modern Astrophysics.
Addison-Wesley, San Francisco: Pearson, 2nd (international) edition, 2007.
[4] Jeffrey Dean and Sanjay Ghemawat. Mapreduce: Simplified data processing on large
clusters. Commun. ACM, 51(1):107–113, January 2008.
[5] Nathan Marz et.al.
nathanmarz/storm/.
Twitter storm framework, 2011.
https://github.com/
[6] B. Falkenburg and W. Rhode. From Ultra Rays to Astroparticles: A Historical Introduction to Astroparticle Physics. SpringerLink : B¨
ucher. Springer, 2012.
[7] Ken Goodhope, Joel Koshy, Jay Kreps, Neha Narkhede, Richard Park, Jun Rao, and
Victor Yang Ye. Building linkedin’s real-time activity data pipeline. IEEE Data Eng.
Bull., 35(2):33–45, 2012.
[8] Jay Kreps, Neha Narkhede, and Jun Rao. Kafka: a Distributed Messaging System
for Log Processing. In Proceedings of the 6th International Workshop on Networking
Meets Databases, 2011.
[9] Ingo Mierswa, Michael Wurst, Ralf Klinkenberg, Martin Scholz, and Timm Euler.
Yale: Rapid prototyping for complex data mining tasks. In Lyle Ungar, Mark Craven, Dimitrios Gunopulos, and Tina Eliassi-Rad, editors, KDD ’06: Proceedings of
the 12th ACM SIGKDD international conference on Knowledge discovery and data
mining, pages 935–940, New York, NY, USA, August 2006. ACM.
4
17
C) Solar Doorplate
Projektgruppenantrag
1
Thema
Solar Doorplate
Energiegewahre Systemsoftware f¨
ur ubiquit¨are Systeme
2
Zeitraum
WiSe 2015/16 und SoSe 2016
3
Veranstalter
Alexander Lochmann, Informatik 12, OH-16, Raum E02, Tel. 6141, [email protected]
Markus Buschhoff, Informatik 12, OH-16, Raum 103, Tel. 6317, [email protected]
Olaf Spinczyk, Informatik 12, OH-16, Raum E01, Tel. 6322, [email protected]
4
Aufgabe
Abbildung 1: Konzept-Visualisierung: So k¨
onnte das geplante T¨
urschild aussehen.
4.1
Motivation
Ubiquit¨are Systeme und Wireless Sensor Networks (WSNs) sind kleinste eingebettete Systeme, die h¨
aufig in
großer Anzahl eingesetzt werden, um Messaufgaben durchzuf¨
uhren oder um Einfluss auf das Lebensumfeld von
Menschen zu nehmen. Solche Systeme werden f¨
ur verschiedene Zwecke eingesetzt, z.B. f¨
ur die Netzanbindung
von intelligenten“ Waren und Alltagsartikeln (Internet of Things), die Identifizierung und Vernetzung von
”
Waren in Produktion und Logistik (Industrie 4.0), die Komfort- und Sicherheitssteuerung in Geb¨
auden (Smart
¨
Home) und die Uberwachung
von physikalischen Gr¨
oßen in Ger¨
aten, Versorgungsnetzen und Baukonstruktionen
(Cyberphysical Systems).
1
18
C) Solar Doorplate
Hierbei ist die Energieversorgung oft ein zentrales Problem, da solche Systeme einerseits nicht immer an
Versorgungsnetze angeschlossen werden k¨onnen, z.B. wegen einer Ausbringung im Freien, andererseits aber
auch ein Batteriebetrieb oft nicht m¨oglich ist, da ein Batteriewechsel bei einer großen Zahl von Systemen nicht
praktikabel ist.
Das Einsparen und Verwalten der Ressource Energie wird hier somit zu einer wichtigen Aufgabe: Der Energieertrag durch Solarzellen oder ¨ahnliche Harvesting-Technologien muss gr¨
oßer sein, als der Energieverbrauch
der eingesetzten Komponenten. Dies muss nicht nur bei der Auswahl der Hardware, sondern auch beim Entwurf der Software ber¨
ucksichtigt werden [SK11]. Die dazu eingesetzten Techniken sind die Energie¨
uberwachung
durch Hardware, das Energy-Accounting [KB09] durch Software und der verbrauchsorientierte Einsatz von
Systemkomponenten [DBN12]. Dem zugrunde liegen Energiemodelle f¨
ur Peripherie und Komponenten, die so
einfach strukturiert sein m¨
ussen, dass sie zur Berechnung des Energieverbrauchs auf dem eingebetteten System
verwendet werden k¨onnen [KPMB08, ZTQ+ 10, BGS12].
Im Bereich der Software strebt man hierbei wiederverwendbare Komponenten an, die im Betriebssystem
eines eingebetteten Systems untergebracht werden und dadurch allgemeing¨
ultig die Nutzung aller Komponenten
u
¨berwachen und steuern [BMM13, ZELV02, Bus14].
Neben diesen Punkten muss auch der Umgang mit Daten in einer konkreten Anwendung genauer betrachtet
werden. Hier ergeben sich die Fragen, wie h¨
aufig Daten erhoben und verarbeitet werden m¨
ussen und u
¨ber
welche Kommunikationskan¨ale Daten ausgetauscht werden. Insbesondere beim Einsatz von energiezehrender
Funktechnologie m¨
ussen Protokolle und Kommunikationspartner gut auf die Zielsetzung des Energiesparens
abgestimmt werden, um sowohl die Verf¨
ugbarkeit der Daten als auch die Verf¨
ugbarkeit des angestrebten Dienstes
zu gew¨ahrleisten [PSVP12].
Die hier angerissenen Techniken werfen die Frage auf, wie man Anwendungssoftware und eingebettete Betriebssysteme konzipiert, die diesen Anforderungen gerecht werden und dabei m¨
oglichst wenig Overhead erzeugen: Denn neben der Energie sind in solchen Systemen auch Speicher und Rechenkapazit¨
at knappe Ressourcen.
4.2
Aufgabenstellung
Im Rahmen der Projektgruppe soll von den Studierenden exemplarisch f¨
ur die oben angesprochene Klasse von
Systemen bzw. Anwendungen ein Netzwerk aus intelligenten T¨
urschildern konzipiert und prototypisch realisiert
werden. Folgende Nutzungsszenarien sind daf¨
ur angedacht: Die T¨
urschilder sollen u
¨ber ein Display Auskunft
u
ber
die
aktuelle
Raumbelegung
geben.
Bei
B¨
u
ros
wird
die
Anwesenheit
der
jeweiligen
Mitarbeiter oder der
¨
aktuelle Aufenthaltsort angezeigt. Ist ein Mitarbeiter beispielsweise gerade abwesend, kann ein Besucher durch
Einstecken der UniCard einen Vermerk mit der Bitte um Kontaktaufnahme hinterlassen. Beim Einsatz f¨
ur einen
Seminarraum wird auf dem Display die aktuelle Veranstaltung sowie die Dauer der Belegung angezeigt. Ein
¨
Raumadministrator soll u
andern k¨
onnen. Die Anderungen
¨ber eine geeignete Schnittstelle die Raumbelegung ver¨
werden dann u
urschilder weitergegeben.
¨ber ein Gateway an die verschiedenen T¨
Eine vergleichbare Funktionalit¨at wurde von der Universit¨
at Augsburg bereits im Rahmen eines Forschungsprojektes namens Smart Doorplate“ entwickelt. Dabei lag der wissenschaftliche Schwerpunkt jedoch auf den
”
m¨oglichen Nutzungsszenarien. Im Rahmen unserer Projektgruppe soll es stattdessen prim¨
ar darum gehen, eine funktionierende Plattform zu konzipieren und zu realisieren, die vollkommen energieautark auf Basis von
Solarzellen1 arbeitet. Dabei sollen allgemeine Erkenntnisse u
¨ber Struktur und Funktionsweise energiegewahrer
Systemsoftware gewonnen werden.
Als technische Basis f¨
ur den ersten Prototypen ist das inBin 2 [ERBtH12] vorgesehen. Es handelt sich dabei
um eine Entwicklung des Fraunhofer Instituts f¨
ur Materialfluss und Logistik (IML), mit dem wir im Rahmen
eines Forschungsprojekts kooperieren und das seine Unterst¨
utzung f¨
ur die Projektgruppe auf der Ebene der
Hardware-Plattform zugesagt hat. Das inBin bezieht seine Energie aus einem Kondensator, der u
¨ber eine IndoorSolarzelle geladen wird. Die Systemsoftware muss den Energieverbrauch sowohl von einzelnen Hardware- als auch
einzelnen Softwarekomponenten absch¨atzen k¨
onnen, um so die verbleibende Energie, und daraus resultierend
die Restlaufzeit, ermitteln zu k¨onnen. Anhand solcher Informationen k¨
onnen beispielsweise die Funkparameter
dynamisch gew¨ahlt werden oder optionale Komfortfunktionen“ deaktiviert werden, um den Energieverbrauch
”
situationsabh¨angig zu reduzieren.
Je nach Umgebungsbedingungen ist es jedoch nicht vermeidbar, dass die Versorgungsspannung unter einen
kritischen Pegel f¨allt. F¨
ur diesen Fall muss die Systemsoftware imstande sein, das System wieder in einen betriebsbereiten Zustand zu bringen, sobald wieder hinreichend Energie verf¨
ugbar ist. In erster Instanz ist z.B. ein
vollst¨andiger Neustart des Systems denkbar. Es k¨
onnen aber auch komplexere Mechanismen wie Checkpointing
oder persistente Objekte in Erw¨agung gezogen werden.
Als Ausgangspunkt f¨
ur die Software-Entwicklung soll das eingebettete Betriebssystem Kratos dienen, das
derzeit von unserer Arbeitsgruppe entwickelt wird [Bus14].
1 Zum
Einsatz kommen sollen Solarzellen, die speziell f¨
ur den Betrieb im Innenraumbereich geeignet sind.
of activity/automation embedded systems/Products/InBin.html
2 http://www.iml.fraunhofer.de/en/fields
2
19
C) Solar Doorplate
Die Systemsoftware soll insbesondere auch einen energiegewahren Netzwerkprotokollstapel einschließen. Wie
¨
bereits erw¨ahnt, werden die T¨
urschilder u
bei der Raumbelegung durch das Gateway informiert.
¨ber Anderungen
Es muss sichergestellt werden, dass jeder Knoten u
¨ber ihn betreffende Modifikationen des Belegungsplans informiert wird. Hierbei muss die besondere Anordnung der T¨
urschilder ber¨
ucksichtigt werden. Unter Umst¨anden
sind nicht alle Knoten direkt vom Gateway erreichbar. Da jedoch die T¨
urschilder station¨
ar sind, k¨
onnen einige
beispielsweise als Relay-Station fungieren, um die Weiterleitung von Daten zu realisieren. Das Kommunikationsverhalten kann sich z.B. an dem Tag-Nacht-Zyklus oder an der Position eines Knotens innerhalb des Flures
orientieren, um so die Energiepotentiale effizient ausnutzen. Gleichermaßen k¨
onnen die Kommunikationsparameter an die aktuelle bzw. zu erwartende Versorgungssituation angepasst werden.
Bei Interesse kann in Kooperation mit dem Fraunhofer Institut eine erweiterte Hardwareplattform konzipiert
und prototypisch realisiert werden. Hier sind beispielsweise die Anbindung eines SmartCard -Leseger¨
ates oder
anderer Eingabem¨oglichkeiten denkbar.
5
Teilnahmevoraussetzungen
5.1
Voraussetzung
• Kenntnisse aus der Vorlesung Betriebssystembau“, Software ubiquit¨
arer Systeme“ oder einer vergleich”
”¨
baren, nachgewiesen durch erfolgreiche Pr¨
ufung oder Ubungsteilnahme
(einschließlich der laufenden Veranstaltung Software ubiquit¨arer System“).
”
• Verst¨andnis englischsprachiger Artikel und Handb¨
ucher
5.2
Wu
¨ nschenswert
• Unix-/Linux-Kenntnisse
• Programmierkenntnisse C/C++
• Hardwarenahe Programmierung
6
Minimalziele
• Realisierung einer einfachen T¨
urschildanwendung auf Basis von Kratos auf der inBin-Plattform
• Funktionierende Kommunikation zwischen intelligenten T¨
urschildern und Gateway innerhalb eines Raumes mit einer starken Lichtquelle (einfaches Routing und Anwendungsprotokoll)
• Erstellung der wichtigsten Energiemodelle (Solarzelle/Energiespeicher, Funk, Display) und Bereitstellung
in der Systemsoftwareplattform
• Realisierung einer einfachen Schnittstelle f¨
ur die Bedienung durch einen Raumadministrator
7
Literatur
[BGS12]
Markus Buschhoff, Christian G¨
unter, and Olaf Spinczyk. A unified approach for online and offline
estimation of sensor platform energy consumption. In 8th InternationalWireless Communications
and Mobile Computing Conference (IWCMC), pages 1154–1158, August 2012.
[BMM13]
Nicolas Berthier, Florence Maraninchi, and Laurent Mounier. Synchronous programming of device
drivers for global resource control in embedded operating systems. ACM Transactions on Embedded
Computing Systems (TECS), 12(1s):39:1–39:26, March 2013.
[Bus14]
Markus Buschhoff. Kratos - a resource aware, tailored operating system. In Katharina Morik and
Wolfgang Rhode, editors, Technical report for Collaborative Research Center SFB 876 - Graduate
School, number 10. December 2014.
[DBN12]
Soumya Kanti Datta, Christian Bonnet, and Navid Nikaein. Android power management: Current
and future trends. In Enabling Technologies for Smartphone and Internet of Things (ETSIoT),
2012 First IEEE Workshop on, pages 48–53. IEEE, 2012.
[ERBtH12] J Emmerich, Moritz Roidl, Tobias Bich, and Michael ten Hompel. Entwicklung von energieautarken,
intelligenten Ladehilfsmitteln am Beispiel des inBin. Logistics Journal, 2012, 2012.
3
20
C) Solar Doorplate
[KB09]
Simon Kellner and Frank Bellosa. Energy accounting support in tinyos. PIK-Praxis der Informationsverarbeitung und Kommunikation, 32(2):105–109, 2009.
[KPMB08] S. Kellner, M. Pink, D. Meier, and E.-O. Blass. Towards a realistic energy model for wireless sensor
networks. In Fifth Annual Conference on Wireless on Demand Network Systems and Services, pages
97–100, January 2008.
[PSVP12]
U. Prathap, D.P. Shenoy, K.R. Venugopal, and L.M. Patnaik. Wireless sensor networks applications
and routing protocols: Survey and research challenges. In Cloud and Services Computing (ISCOS),
2012 International Symposium on, pages 49–56, Dec 2012.
[SK11]
S. Sudevalayam and P. Kulkarni. Energy harvesting sensor nodes: Survey and implications. Communications Surveys Tutorials, IEEE, 13(3):443–461, Third 2011.
[ZELV02]
Heng Zeng, Carla S Ellis, Alvin R Lebeck, and Amin Vahdat. Ecosystem: Managing energy as a
first class operating system resource. ACM SIGPLAN Notices, 37(10):123–132, 2002.
[ZTQ+ 10] Lide Zhang, Birjodh Tiwana, Zhiyun Qian, Zhaoguang Wang, Robert P Dick, Zhuoqing Morley
Mao, and Lei Yang. Accurate online power estimation and automatic battery behavior based power
model generation for smartphones. In Proceedings of the eighth IEEE/ACM/IFIP international
conference on Hardware/software codesign and system synthesis, pages 105–114. ACM, 2010.
8
Rechtlicher Hinweis
Die Ergebnisse der Projektarbeit und die dabei erstellten Software sollen der Fakult¨
at f¨
ur Informatik und dem
Sonderforschungsbereich SFB-876 uneingeschr¨
ankt f¨
ur Lehr- und Forschungszwecke zur freien Verf¨
ugung stehen.
Dar¨
uber hinaus sind keine Einschr¨ankungen der Verwertungsrechte an den Ergebnissen der Projektgruppe und
keine Vertraulichkeitsvereinbarungen vorgesehen.
4
21
D) Spielende kooperierende Agenten
Spielende kooperierende Agenten
Jan Quadflieg, LS 11
Lars Hildebrand, LS 1
Christian Eichhorn, LS 1
1 Thema
Spielerische Umgebungen bieten in vielen Anwendungsgebieten eine gute Testumgebung zur Erprobung von
Methoden. Hierbei sind einfache Computerspiele mit beliebig programmierbaren Umgebungen und den frei
in ihrer Schwierigkeit steigerbaren Aufgaben besonders geeignet f¨ur die Erprobung von Ans¨atzen aus der Informatik. Die Projektgruppe Spielende kooperierende Agenten besch¨aftigt sich mit Softwareagenten, die als
Spielfiguren in kooperativen Computerspielen mittels vordefinierter Regeln mit Ausnahmen einerseits und erlerntem Verhalten andererseits bekannte wie unbekannte Aufgaben (hier: Spielumgebungen, genannt Level)
l¨osen. Hierzu werden verschiedene Methoden aus den Bereichen der Wissensrepr¨asentation und der Computational Intelligence untersucht und erprobt, um ein bestm¨ogliches Ergebnis zu erhalten. Durch die Auswahl
von Ans¨atzen beider Gebiete werden gezielt Methoden kombiniert, die u¨ blicherweise getrennt voneinander
angewendet werden, sodass sich die St¨arken der jeweiligen Ans¨atze erg¨anzen.
Das oder die zu l¨osenden Spiele werden von den Teilnehmern mittels der Spielengine Unity3D [Tec15] selbst
implementiert, wobei das kooperative Spiel Geometry Friends [RMP08, GAI15] als Inspiration und als Einstieg
dient.
2
Zeitraum
Wintersemester 2015/16 und Sommersemester 2016
3
Veranstalter
Jan Quadflieg, Informatik 11, B Otto-Hahn-Straße 14, Raum 240, T + 49 231 755 7708,
k [email protected]
Lars Hildebrand, Informatik 1, B Otto-Hahn-Straße 12, Raum 3.018, T + 49 231 755 6375,
k [email protected]
Christian Eichhorn, Informatik 1, B Otto-Hahn-Straße 12, Raum 3.007, T + 49 231 755 6522,
k [email protected]
4 Aufgabe
Ziel dieser PG ist die Entwicklung und Evaluierung eines Multiagentenansatzes zur L¨osung von kooperativen
Spielen. Hierzu werden unterschiedliche Ans¨atze verfolgt: Es wird eine Regelbasis aufgestellt, die erfolgreiche
Spielz¨uge f¨ur allgemeine Situationen beschreibt. Dieses Wissen wird einer Planungskomponente zur Verf¨ugung
gestellt, die f¨ur ein gegebenes Level einen m¨oglichst erfolgreichen Plan erstellt. Durch Einsatz von Lernverfahren und Methoden der Computational Intelligence (CI) wird zudem in Trainingsleveln Verhalten gelernt,
das zus¨atzlich zum regelbasierten Wissen das Erreichen einer erfolgreichen L¨osung verbessert. Die durch diese
Verfahren gewonnenen L¨osungen werden in den Trainingsleveln und in unbekannten Leveln getestet und der
Erfolg mit geeigneten Maßen verglichen. Hierbei sind die Spieler/-figuren im verwendeten kooperativen Spiel
als autonom agierende Softwareagenten zu realisieren, die nicht durch eine zentrale Einheit gesteuert werden,
wobei Kommunikation zwischen den Agenten notwendig ist.
Eine M¨oglichkeit f¨ur ein kooperatives Spiel, das eine geeignete Testumgebung f¨ur dieses Projekt darstellt, ist
Geometry Friends, ein auf Kooperation ausgelegtes Jump ’n’ Run/Puzzle-Spiel f¨ur zwei Spieler. Jeder Spieler
22
D) Spielende kooperierende Agenten
(a) Geometry Friends Spielfiguren
(b) Level mit einfachen Hindernissen
Abbildung 1: (a) Geometry Friends Spielfiguren Kugel und Rechteck mit Volumenver¨anderung (gepunktet,
links) und Kantenl¨angenver¨anderung (gepunktet, rechts) und Bewegungsm¨oglichkeiten (Pfeile). (b) Beispiellevel von Geometry Friends, Rauten sind ,,einzusammelnde“ Objekte.
kontrolliert dabei eine der beiden Figuren, einen Kreis und ein Rechteck, die unterschiedliche F¨ahigkeiten
haben: Wie in Abbildung 1(a) dargestellt ist, kann der Kreis seinen Radius begrenzt a¨ ndern und das Rechteck
kann bei konstantem Fl¨acheninhalt seine Seitenl¨angen anpassen und sich so in Breite oder H¨ohe ausdehnen.
Beide Figuren k¨onnen sich horizontal u¨ ber Ebenen bewegen und der Kreis kann zus¨atzlich springen und das
Rechteck ,,umwerfen“. Ziel des Spiels ist, in einer 2D Umgebung mit den zwei Spielfiguren in m¨oglichst
kurzer Zeit eine Reihe von u¨ ber das Level verteilten Diamanten (Rauten) zu sammeln (siehe Abbildung 1(b),
Quelle [GAI15]).
Auf beide Figuren wirken Schwerkraft und Reibung und es gibt allgemeine Begrenzungen und Hindernisse.
Komplexere Level enthalten Bereiche, in denen sich nur eine der beiden Spielfiguren bewegen kann. Um die
Level, die sich durch die Anordnung der (sich u.U. auch bewegenden) Hindernisse, Diamanten und Startpositionen der Figuren unterscheiden, erfolgreich zu l¨osen, m¨ussen die Spieler folgende Schritte durchf¨uhren:
Zu Beginn steht die Analyse, welche Diamanten durch den Kreis, welche durch das Rechteck und welche kooperativ erreicht werden k¨onnen. Dabei m¨ussen auch Abh¨angigkeiten in der Reihenfolge des Sammelns der
Diamanten ber¨ucksichtigt werden. Aus dieser Analyse ergeben sich Handlungsauftr¨age f¨ur die beiden Spieler.
Schließlich m¨ussen diese Auftr¨age unter Ber¨ucksichtigung der simulierten physikalischen Gesetze von beiden
Spielern koordiniert ausgef¨uhrt werden.
Geometry Friends ist seit 2013 Gegenstand von Wettbewerben im Rahmen der IEEE Konferenz Computational Intelligence in Games (CIG) und (seit 2015) der Genetic and Evolutionary Computation Conference
(GECCO). Teilnehmer des Wettbewerbs sind aufgefordert, Agenten zu entwickeln, welche die Steuerung die
beiden Spielfiguren u¨ bernehmen. Die Ergebnisse der ersten beiden Wettbewerbe 2013 & 2014 belegen die
Komplexit¨at der Aufgabe: W¨ahrend die eingereichten Agenten in vorab bekannten Leveln brauchbare Ergebnisse erzielten, scheitern sie h¨aufig schon fr¨uhzeitig bei unbekannten Leveln. Ein Ziel der PG ist, zu erproben,
ob ein auf den genannten Ans¨atzen beruhendes Verfahren hier bessere Ergebnisse liefert, insbesondere mit
Hinblick auf die Generalisierbarkeit.
¨
Mogliches
Vorgehen
Um mehr Freiheiten bez¨uglich der Schnittstellen zum eingesetzten Spiel zu haben, soll die PG zuerst das
Spiel Geometry Friends oder ein vergleichbares Spielkonzept mit Hilfe von Unity3D umsetzen. In der Seminarphase erwerben die Teilnehmer die n¨otigen Grundkenntnisse u¨ ber Inferenzen aus regelbasiertem Wissen,
Methoden der Computational Intelligence und Planung, um sich f¨ur jeweils einen vielversprechenden Ansatz
aus diesen Themengebieten entscheiden k¨onnen, der zur L¨osung des implementierten Spiel geeignet scheint.
Ein m¨oglicher Startpunkt hierbei ist Fuzzy Logik, weil sie sowohl in CI, Schlussfolgerungs- als auch Planungsans¨atzen Anwendung findet und sich somit als ein erster, aufgaben¨ubergreifender Ansatz anbietet. In
dieser Phase ist zudem ein passendes Wahrnehmungsmodell (insbesondere f¨ur den Levelaufbau) zu entwickeln. Gleichzeitig ist ein passendes Agentenmodell zu w¨ahlen, wobei sich eine Modellierung der Agenten als
BDI-Agenten [Woo09] (Vgl. Abbildung 2) unter Verwendung des am LS 1 entwickelten Framework Angerona [KJKI14] anbietet. Da die Agenten nicht durch eine zentrale Instanz gesteuert werden sollen, ist ausserdem
23
D) Spielende kooperierende Agenten
BDI-Agent
Optionserzeugung
Desires
Filter
Intentions
Handeln
Wahrnehmen
Beliefs
Umgebung
Abbildung 2: BDI-Agentenmodell mit Handlungsschleife
ein Modell der Kommunikation mit dem dazugeh¨origen Protokoll zu entwickeln.
Darauf aufbauend werden Regeln f¨ur erfolgreiches Spielen durch eigene Praxis erworben, w¨ahrend gleichzeitig ein passender un¨uberwachter Lernansatz die ausgew¨ahlte CI-Methode trainiert. Mithilfe der Erfahrungen
aus dieser Projektphase werden geeignete Qualit¨atsmaße f¨ur spielende Agenten entwickelt.
In der folgenden PG-Phase werden dann weitere Methoden zur L¨osung der genannten Aufgaben implementiert und mittels der entwickelten Qualit¨atsmaße gegeneinander getestet, um schließlich die optimale Konfiguration der spielenden planenden Agenten zu erhalten. Die Erfolge und Erfahrungen der PG-Phasen werden in
einem Zwischen- und einem Endbericht zusammengefasst.
Seminarphase / Tutorien
Um alle Teilnehmer/innen auf den gleichen Wissensstand bez¨uglich der in Frage kommenden Methoden zu
bringen, findet zu Beginn der PG ein Blockseminar statt. Themen f¨ur die Seminarphase werden in der letzten
Woche des Sommersemesters 2015 (KW 29) vergeben. In Absprache mit der Projektgruppe findet die Seminarphase als Blockveranstaltung in der ersten Vorlesungswoche des Wintersemesters 2015/16 (KW 43) oder in
der vorlesungsfreien Zeit vor dem Wintersemester (KW 39) statt. Dieses Blockseminar wird nach M¨oglichkeit
nicht an der Universit¨at, sondern in einem Tagungshaus in der n¨aheren Umgebung stattfinden. Weiterhin werden zu Beginn des Wintersemesters, begleitend zur Arbeit der Projektgruppe, kleinere Tutorien im Rahmen der
regelm¨aßigen Treffen stattfinden. Diese werden von den PG Teilnehmer/innen gehalten und dienen dem gemeinsamen Erlernen wichtiger technischer F¨ahigkeiten, beispielsweise ,,C# f¨ur Java-Programmierer“, ,,LATEX“,
,,Angerona“ o.¨a., und komplettieren mit einem praktisch/prozeduralen Blickwinkel die eher als konzeptionell/theoretisch angelegten Seminare.
5 Teilnahmevoraussetzungen
Notwendig: Erfolgreicher Abschluss wenigstens einer der Veranstaltungen
• Darstellung, Verarbeitung und Erwerb von Wissen (DVEW)
• Einf¨uhrung in die Computational Intelligence
oder Nachweis vergleichbarer Kenntnisse.
¨
Wunschenswert:
• Erfahrungen im Umgang mit unixartigen Betriebssystemen
• Praktische Kenntnisse in objektorientierter Programmierung, z.B. in der Sprache C#
24
D) Spielende kooperierende Agenten
• Vorkenntnisse im Bereich Wissensrepr¨asentation und/oder Computational Intelligence, wie sie zum Beispiel durch Besuch der Master-Veranstaltungen Commonsense Reasoning oder Fortgeschrittene Themen
der Wissensrepr¨asentation erworben werden k¨onnen.
• Vorkenntnisse zu Unity3D, z.B. aus dem Fachprojekt Digital Entertainment Technologies
6
Minimalziel
Das Minimalziel der PG ist die exemplarische Implementierung eines geeigneten Spiels f¨ur Unity3D, inklusive
einer Agentenkomponente, die in der Lage ist, die Spielfiguren zu steuern, sowie der Erstellung einer Wissensbasis mit Regeln f¨ur erfolgreiches Spielverhalten. Die Agentenkomponente muss, wenigstens prototypisch, ein
Lernverfahren aus dem Bereich der Computational Intelligence, eine Komponente zur Ableitung von Wissen
aus Regeln (Inferenzkomponente) und eine Planungskomponente realisieren. Ein Abschlussbericht dokumentiert die Ergebnisse und Erkenntnisse. Die Projektgruppe berichtet der Fakult¨at in einem Fachgespr¨ach u¨ ber
Ablauf und Ergebnis ihrer Arbeit.
7
Literaturverzeichnis
[BKI14]
B EIERLE, Christoph ; K ERN -I SBERNER, Gabriele: Methoden wissensbasierter Systeme – Grundlagen, Algorithmen, Anwendungen. 5., u¨ berarbeitete und erweiterte. Heidelberg : Springer Vieweg, 2014
[EFL+ 00] E ITER, Thomas ; FABER, Wolfgang ; L EONE, Nicola ; P FEIFER, Gerald ; P OLLERES, Axel: Planning under Incomplete Knowledge. In: Proceedings of the First International Conference on Computational Logic
(CL2000), volume 1861 of Lecture Notes in Computer Science, Springer, 2000, S. 807–821
[GA14]
G EORGIEVSKI, Ilce ; A IELLO, Marco: An Overview of Hierarchical Task Network Planning. In: CoRR
abs/1403.7426 (2014)
[GAI15]
GAIPS: Geometry Friends. http://gaips.inesc-id.pt:8081/geometryfriends/?page_
id=6, 2015
¨
[KJKI14] K R UMPELMANN
, Patrick ; JANUS, Tim ; K ERN -I SBERNER, Gabriele: Angerona - A Multiagent Framework
for Logic Based Agents with Application to Secrecy Preservation / Technische Universit¨at Dortmund. 2014
(3). – Forschungsbericht
[NGT04] NAU, Dana ; G HALLAB, Malik ; T RAVERSO, Paolo: Automated Planning: Theory & Practice. San Francisco,
CA, USA : Morgan Kaufmann Publishers Inc., 2004
[RMP08] ROCHA, Jos´e B. ; M ASCARENHAS, Samuel ; P RADA, Rui: Game Mechanics for Cooperative Games. In:
Zon Digital Games 2008. Porto, Portugal : Centro de Estudos de Comunicac¸a˜ o e Sociedade, Universidade do
Minho, November 2008, S. 72–80
[RW12]
¨
R OPSTORFF
, Sven ; W IECHMANN, Robert: Scrum in der Praxis: Erfahrungen, Problemfelder und Erfolgsfaktoren. 1. Auflage. dpunkt.verlag GmbH, 2012
[Ste11]
S TERRER, Christian: pm k.i.s.s. Projektmanagement: keep it short and simple. 1. Auflage. Goldegg Verlag,
2011
[Tec15]
T ECHNOLOGIES, Unity: Unity3D. http://www.unity3d.com, 2015
[Woo09]
W OOLDRIDGE, Michael: An Introduction to MultiAgent Systems. 2nd Edition. Wiley Publishing, 2009
8
Rechtlicher Hinweis
Die Ergebnisse der Projektarbeit und die dabei erstellten Software sollen der Fakult¨at f¨ur Informatik uneingeschr¨ankt f¨ur Lehr- und Forschungszwecke zur freien Verf¨ugung stehen. Dar¨uber hinaus sind keine Einschr¨ankungen der Verwertungsrechte an den Ergebnissen der Projektgruppe und keine Vertraulichkeitsvereinbarungen vorgesehen.
25
E) MoSAIC
1 Thema
MoSAIC
Model-based Self-Adaption of Industry 4.0 Configurations
2 Zeitraum
Wintersemester 2015/2016 und Sommersemester 2016
3 Veranstalter
Dr. Johannes Neubauer <[email protected]>, Tel. 7779
Dipl.-Inf. Stefan Naujokat <[email protected]>, Tel. 7734
Dipl.-Inf. Oliver Bauer <[email protected]>, Tel. 7752
Prof. Dr. Bernhard Steffen <[email protected]>, Tel. 5801
Informatik Lehrstuhl 5, Otto-Hahn-Straße 14, Raum 112/111/107/102
4 Aufgabe
Selbstadaptierende Systeme, d.h. Systeme, die ihr Verhalten zur
Erreichung definierter Ziele auf Basis von Beobachtungen von Weiterf¨uhrende Informationen und
Umwelt- und Systemver¨anderungen selbstt¨
atig anpassen, haben
Ank¨
undigungen finden sich auf unserer
in den letzten Jahren vermehrte Aufmerksamkeit erhalten [6]. Webseite: https://v.gd/mosaic
Praktische Relevanz erh¨alt das Thema durch das Ziel, CyberPhysical Systems (CPS) in der industriellen Produktion ( Cyber-Physical Production Systems“,
”
CPPS), wie sie in dem Zukunftsprojekt Industrie 4.0“ der Bundesregierung vorgesehen werden [7],
”
fortschreitend selbstadaptiv und selbstorganisierend zu gestalten. Ziel dieser Projektgruppe soll sein,
einen modellbasierten Ansatz zur Industrie-4.0-Selbstadaption zu erarbeiten und zu implementieren,
sowie diesen dann an einem praktisch relevanten Szenario aus der Industrie – der Automation von
Verpackungsaufgaben – zu evaluieren.
Abbildung 1: Beispielhafte Skizze f¨
ur den Projektaufbau
1
http://en.wikipedia.org/wiki/Delta robot
1
Verpackungsautomation hat sich zu einer eindrucksvollen Disziplin entwickelt,
bei der spezialisierte Roboter in rasender
Geschwindigkeit komplexe Verpackungsformen mit verschiedenen Produkten
bef¨
ullen. Ein konkretes Beispiel hierf¨
ur
1
sind Deltaroboter f¨
ur sogenannte Pick
”
and Place Packaging“-Aufgaben. Sie sind
in der Lage, Produkte wie verschiedene
Kekse oder Pralin´es auf einem Fließband
visuell zu lokalisieren, zu identifizieren,
zu greifen und in das daf¨
ur vorgesehenen
Fach der Schachtel zu platzieren. Allerdings ist die Erstellung zuverl¨
assiger und
effizienter Programme f¨
ur derartige Anlagen ein komplexes technisches Unterfangen, welches f¨
ur jedes Verpackungsszenario erneut erfolgen muss. Zudem
ist es in der Regel nicht m¨
oglich, dynamisch auf Produktionsschwankungen zu
reagieren oder den Ausfall einzelner Roboter zu kompensieren, da die Programmierung eines solchen Verhaltens mit den
26
E) MoSAIC
zur Verf¨
ugung stehenden Mitteln [3, 9] nicht mit vertretbarem Aufwand zu realisieren w¨
are. Teure
Ausfallzeiten oder ineffizientes Verhalten, das nicht auf die aktuelle Situation angepasst ist, sind die
Folge. Um dieser g¨angigen Problematik in der Produktion entgegenzuwirken, m¨
ussen M¨
oglichkeiten
¨
geschaffen werden, die Entwicklung von Systemen, welche sich selbst m¨
oglichst optimal auf Anderungen
von Rahmenbedingungen einstellen, einfach und effizient umzusetzen.
Im Rahmen dieser Projektgruppe soll ein modellbasiertes selbstadaptierendes Framework entwickelt werden, das den laufenden Betrieb einer aus
Deltarobotern bestehenden Verpackungsanlage
¨
u
bewertet und das Ver¨ berwacht, Anderungen
halten der Roboter dynamisch konfiguriert, ohne
dass neuer Programmcode erzeugt und in Betrieb
genommen werden muss. Hierbei kann auf den Ergebnissen der im SoSe 2014 und WiSe 2014/2015
stattgefundenen Projektgruppe InProX [5] aufgebaut werden, in deren Rahmen bereits eine
dom¨
anenspezifische grafische Modellierungssprache, die Pick and Place Packaging Language“
”
(3PL, vgl. Abb. 2) entwickelt wurde. Programme
in dieser von vielen technischen Details abstrahierender Spezifikationssprache k¨onnen vollautomatisch in ausf¨
uhrbaren Code f¨
ur Deltaroboter
u
¨bersetzt werden.
Unterst¨
utzt wird die Arbeit der Projektgruppe
von den Spezialisten f¨
ur Verpackungsautomation
der Firma Omron Europe B.V. (Standorte Barcelona und D¨
usseldorf), die den Fortschritt der PG
verfolgen und die Anwendbarkeit der Konzepte in
der Praxis beurteilen k¨onnen. Zudem stellen sie
einen NJ“ Motion Controller, eine auf Roboter
”
spezialisierte Speicherprogrammierbare Steuerung
(SPS), und die entsprechende Entwicklungsumgebung Sysmac Studio“ zur Verf¨
ugung, sodass
”
die von der PG entwickelten Komponenten unter praxisnahen Bedingungen eingesetzt werden
k¨onnen.
Abbildung 1 skizziert einen beispielhaften Aufbau eines selbst adaptierenden Robotersystems
im Kontext der Verpackungsautomation mit Deltarobotern. Der dargestellte NJ Controller enth¨
alt Abbildung 2: Beispiel f¨
ur eine Verpackungsstrategie
verschiedene Softwarekomponenten, die die grundmodelliert in der 3PL
legenden Steuerungsbefehle der Roboter realisieren. Mittels des 3PL-Modells k¨onnen Verpackungsstrategegien f¨
ur Deltaroboter modelliert werden, die
zur Laufzeit auf die NJ u
¨ bertragen werden sollen. So werden die Schritte der Codegenerierung, der
Compilierung und des Deployments unn¨
otig, und damit die Anpassung des Verhalten zur Laufzeit
m¨
oglich. Durch die visuelle Erfassung der Fließbandbelegung soll es m¨
oglich sein, das Vorgehen f¨
ur einen
n¨
achsten Zeitabschnitt zu planen. Dabei soll darauf geachtet werden, dass bestimmte Kriterien, wie
beispielsweise die m¨oglichst gleichm¨aßige Auslastung aller Deltaroboter, bei der Planung eingehalten
werden. Aus diesen Pl¨anen soll dann die dynamische Konfiguration f¨
ur die NJ erzeugt werden.
Die Entwicklung von Konzepten, wie aus den Aufzeichnungen von Fließbandbelegungen geeignete
Verpackungstrategien geplant und inferiert werden k¨
onnen, bildet einen Hauptteil der PG. Sie sollen auf
2
27
E) MoSAIC
Basis verschiedener formaler Methoden, insbesondere Maschinenlernen [8], Planen [11] und Synthesebasierter Vervollst¨andigung von Spezifikationen [10] realisiert werden.
Ziele
Zun¨
achst ist die von der PG InProX entwickelte
dom¨
anenspezifische Sprache 3PL so zu erweitern,
dass mit ihr modellierte Verpackungsstrategien
auf dem NJ Motion Controller dynamisch ausgef¨
uhrt werden k¨onnen. Dann sind Kriterien f¨
ur
eine optimale Ausf¨
uhrung von Verpackungsszenarien zu definieren. Hier ist es geplant, eine weitere
Abbildung 3: Workflow f¨
ur das Planungs und 3PLdom¨
anenspezifische Sprache zu entwickeln, mit
Inferenzsystem.
welcher diese Kriterien formuliert werden k¨
onnen.
Des Weiteren sollen Verfahren erarbeitet werden,
die dazu geeignet sind, diese Kriterien auf ihre G¨
ultigkeit hin zu u
ufen. Sollten diese Kriterien
¨ berpr¨
nicht erf¨
ullt sein, wird das weitere Vorgehen anhand von gemessenen Umgebungsparametern, wie
beispielsweise die Fließbandbelegung, automatisch neu geplant und angepasst (vgl. Abb. 3). Durch die
M¨
oglichkeit, die modellierten Verpackungsstrategien interpretiert auszuf¨
uhren, soll das Anhalten der
Anlage vermieden werden.
Technologien
Im Laufe der Projektruppe InProX wurde auf Basis von Cinco [1, 12] die grafische Modellierungssprache
3PL entwickelt. Mit dieser DSL ist es m¨
oglich, Verpackungstrategien zu modellieren. Bestandteil
dieser L¨
osung ist ein Codegenerator, der es erm¨
oglicht, modellierte Strategien in Programmcode
f¨
ur eine Speicherprogrammierbare Steuerung (SPS), wie der NJ Motion Controller von Omron, zu
u
uber hinaus ist es m¨oglich, die Ausf¨
uhrung des Programmcodes mit der Simulations¨ bersetzen. Dar¨
und Visualisierungssoftware V-REP [4] darzustellen.
Cinco selbst ist ein Werkzeug auf Basis des Eclipse Modeling Frameworks (EMF), mit dem aus einer
Metamodell-Beschreibung einer DSL sehr leicht ein auf Eclipse basierendes Modellierungswerkzeug
f¨
ur diese DSL generiert werden kann. Durch ein Meta-Plugin-Konzept lassen sich diese Werkzeuge
erweitern, um beispielsweise Codegenerierung zu erm¨
oglichen.
Die Firma Omron verf¨
ugt mit der NJ-Serie u
¨ ber eine Reihe von SPS-Controllern, die unter anderem
f¨
ur Motion-Aufgaben wie die Steuerung von Deltarobotern verwendet werden. Das Sysmac Studio
ist eine Entwicklungsumgebung, das f¨
ur die Programmierung verwendet wird. Da diese Controller
in Industrieanlagen u
ussen, verf¨
ugt die NJ u
¨ berwacht werden m¨
¨ ber eine Webschnittstelle, mit der
¨
Uberwachungs- und Steuerungsbefehle u
onnen. Die CX-Compolet API [2] kann
¨ bermittelt werden k¨
verwendet werden, um derartige Aufgaben zu l¨
osen.
5 Teilnahmevoraussetzungen
Vorausgesetzt werden:
• Fundierte Kenntnisse in mindestens einer objektorientierten Programmiersprache, zum Beispiel
Java oder C(++|#)
• Elementare Kenntnisse u
¨ber Modellierungstechniken, wie sie zum Beispiel in den Vorlesungen For”
male Methoden des Systementwurfs“, Virtualisierung und Compilation“, Softwarekonstruktion“
”
”
und Dienstleistungsinformatik“ vermittelt werden.
”
Hilfreich sind zudem:
• Kenntnisse im Umgang mit Eclipse-Werkzeugen und -Programmierung
• Kenntnisse im Bereich der Automatisierungstechnik
3
28
E) MoSAIC
6 Minimalziel
Die Minimalziele der PG sind:
• Erweiterung des 3PL-Tools um eine Komponente zur interpretierten Ausf¨
uhrung von 3PLProgrammen
¨
• Entwicklung einer Komponente zur Ubertragung
von 3PL-Programmen zur Laufzeit auf die NJ
• Erstellung eines Konzepts zur Erstellung von Pl¨
anen f¨
ur Verpackungsstrategien aus sensorisch
erfassten Bandbelegungen
• Erstellung einer dom¨anenspezifischen Sprache zur Beschreibung von Zielen f¨
ur die Planung
• Entwicklung eines Frameworks zur Inferenz von 3PL-Programmen aus erstellten Pl¨
anen
7 Literatur
[1] Cinco Website:. http://cinco.scce.info/.
[2] CX-Compolet. http://www.ia.omron.com/products/family/63/.
[3] IEC Standard 61131-3 - Programmable Controllers - Part 3: Programming Languages. http:
//webstore.iec.ch/webstore/webstore.nsf/Artnum_PK/47556.
[4] v-rep: virtual robot experimentation platform. http://www.coppeliarobotics.com/.
[5] A. Berg, C. P. Donfak, J. Gaedecke, E. Ogkler, S. Plate, K. Schamber, D. Schmidt, Y. S¨
onmez,
F. Treinat, J. Weckwerth, P. Wolf, and P. Zweihoff. PG 582 InProX: Industrial Programing by
Example, 2015. Vorabversion auf PG-Webseite verf¨
ugbar: https://v.gd/mosaic.
[6] R. de Lemos et al. Software engineering for self-adaptive systems: A second research roadmap. In
Software Engineering for Self-Adaptive Systems II, volume 7475 of Lecture Notes in Computer
Science, pages 1–32. Springer Berlin Heidelberg, 2013.
[7] A. Hellinger, V. Stumpf, and C. Kobsda. Umsetzungsempfehlungen f¨
ur das Zukunftsprojekt
Industrie 4.0. Promotorengruppe Kommunikation der Forschungsunion Wirtschaft – Wissenschaft
and acatech – Deutsche Akademie der Technikwissenschaften e.V, 2013.
[8] F. Howar, M. Isberner, M. Merten, and B. Steffen. LearnLib Tutorial: From Finite Automata
to Register Interface Programs. In Proceedings of ISoLA (1), volume 7609 of Lecture Notes in
Computer Science, pages 587–590. Springer Verlag, 2012.
[9] K.-H. John and M. Tiegelkamp. IEC 61131-3: Programming Industrial Automation Systems:
Concepts and Programming Languages, Requirements for Programming Systems, Decision-Making
Aids. Springer, 2 edition, 2010.
[10] A.-L. Lamprecht, S. Naujokat, T. Margaria, and B. Steffen. Synthesis-Based Loose Programming. In
Proceedings of the 7th International Conference on the Quality of Information and Communications
Technology (QUATIC 2010), Sept. 2010.
[11] S. M. LaValle. Planning Algorithms. Cambridge University Press, Cambridge, U.K., 2006. Available
at http://planning.cs.uiuc.edu/.
[12] S. Naujokat, L.-M. Traonouez, M. Isberner, B. Steffen, and A. Legay. Domain-Specific Code
Generator Modeling: A Case Study for Multi-faceted Concurrent Systems. In Proc. of the 6th Int.
Symp. on Leveraging Applications of Formal Methods, Verification and Validation, Part I (ISoLA
2014), number 8802 in LNCS, pages 463–480. Springer, 2014.
8 Rechtlicher Hinweis
Die Ergebnisse der Projektarbeit und die dabei erstellte Software sollen der Fakult¨
at f¨
ur Informatik
uneingeschr¨
ankt f¨
ur Lehr- und Forschungszwecke zur freien Verf¨
ugung stehen. Dar¨
uber hinaus sind
keine Einschr¨
ankungen der Verwertungsrechte an den Ergebnissen der Projektgruppe und keine
Vertraulichkeitsvereinbarungen vorgesehen.
4