INFO zu den Projektgruppen der Fakultät für Informatik mit Beginn im WiSe 2011

Transkript

1 INFO zu den Projektgruppen der Fakultät für Informatik mit Beginn im WiSe 2011 Maik Merten Projektgruppen-Beauftragter OH 14 / Raum 128 Tel.: (0231) pgadmin@ls4.cs.uni-dortmund.de Postadresse: Technische Universität Dortmund Lehrstuhl Informatik V Dortmund

2 Inhalt Vorbemerkungen Projektgruppen WiSe 2011 und Termine der Einzelpräsentationen Zum Auswahlverfahren Anmeldung zu den Projektgruppen Zur Stellung der Projektgruppen in der Diplomprüfungsordnung Übersicht zu den Voraussetzungen der einzelnen Projektgruppen Kurzbeschreibung der Projektgruppen Vorbemerkungen Projektgruppen gibt es an den Hochschulen der Bundesrepublik seit ca 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.

3 Projektgruppen WiSe 2011 und Termine der Einzelpräsentationen Nr. Thema der Projektgruppe Veranstalter Einzelpräsentation A GlobalSensing Krumm, Dohndorf , 14:15 Uhr, GB-V, R.420 B Fußballspielende humanoide Roboter Schwiegelshohn, Urbann, Czarnetzki C Process-Cloud for Business Doedt, Boßelmann, Steffen D ChipSim Fisseler, Müller, Joliet, Kersting , 14:00 Uhr, IRF , 12:15 Uhr, OH-14, R , 12:15 Uhr, OH-14, E04

4 Zum Auswahlverfahren Bei der Anmeldung ist anzugeben, mit welcher Priorität Sie welche Projektgruppe wählen: 1=höchste Priorität 4=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 PG-Bewerber werden gemäß ihrer 1. Priorität den Veranstaltern zugeordnet. 2. Die PG-Veranstalter wählen davon insgesamt maximal 9 Teilnehmer nach fachlichen Gesichtspunkten aus. 3. Weitere Teilnehmer werden aus den Bewerbern mit 1. Priorität abhängig vom Zeitpunkt ihres Vordiploms (je weiter in der Vergangenheit, um so größere Priorität; für Bewerber, die bereits an einer PG erfolglos teilgenommen haben, gilt der Zeitpunkt der letzten Anmeldung) bestimmt; bei gleichem Zeitpunkt entscheidet das Los. 4. Ist die Gesamtzahl 12 in einzelnen PGs nicht erreicht, wird das Verfahren ab (2.) gemäß 2. Priorität, in einer weiteren Runde gemäß 3. Priorität etc. durchgeführt. 5. Nachrücklisten (max. 3 Nachrücker pro PG) werden erst nach Abschluss des Verteilverfahrens vom Veranstalter erstellt. Anmeldung zu den Projektgruppen Vordiplom ist Voraussetzung (Stichtag: ) Die Anmeldung erfolgt bis (12.00 Uhr) online unter Weitere Informationen zu Projektgruppen können auch unter abgerufen werden.

5 Zur Stellung der Projektgruppen in der Prüfungsordnung Die Teilnahme an einer Projektgruppe ist Pflicht für alle Studierenden des Master-Studiengangs Informatik und für Studierende von Diplomstudiengängen mit Hauptfach Informatik oder Ingenieur-Informatik. 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. Die Projektgruppenordnung kann beim Projektgruppenbeauftragten eingesehen werden. Sie ist auch auf dem WWW-Server des LS4 unter abrufbar. 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 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.

6 Übersicht zu den Voraussetzungen der einzelnen Projektgruppen (V) Voraussetzung (W) wünschenswert (M) mindestens eine (2) mindestens zwei A: GlobalSensing (Krumm, Dohndorf) Kenntnisse im Bereich Rechnernetze und verteilter Systeme (V) Kenntnisse in objektorientierter Programmierung, Java(V) Kenntnisse Service-orientierter Architekturen (W) B: Fußballspielende humanoide Roboter (Schwiegelshohn, Urbann, Czarnetzki) Kenntnisse zur objektorientierter Programmierung (V) Kenntnisse zur C++-Programmierung oder die Bereitschaft, sich dort einzuarbeiten (V) Kenntnisse zu Matlab (W) Kenntnisse zu evolutionären Algorithmen oder anderen Optimierungsverfahren (W) C: Process-Cloud for Business (Doedt, Boßelmann, Steffen) Fundierte Kenntnisse mindestens einer objektorientierten Programmiersprache (z. B. Java) (V) Kenntnisse im Gebiet Software-Design und Implementierung (V) Interesse an neuen Technologien und Bereitschaft, sich dort einzuarbeiten (V) Grundlegende Kenntnisse serviceorientierter Architekturen (W) Grundlegende Kenntnisse zur Geschäftsprozessmodellierung (W) Datenbankkenntnisse (W) D: ChipSim (Fisseler, Müller, Joliet, Kersting) Kenntnisse in Geometrieverarbeitung, Computergrafik oder grafischer Datenverarbeitung (V) Kenntnisse einer objektorientierten Programmiersprache (z. B. C++ oder Java) (V) Kenntnisse in geometrischem Modellieren, Datenvisualisierung oder digitaler Bildverarbeitung (W) Kenntnisse in Software-Technologie (W) DirectX- oder OpenGL-Programmierung (W)

7 A) GlobalSensing 7 1. Thema der Projektgruppe: GlobalSensing 2. Zeitraum: WS 2011/2012 und SS Umfang: 8 SWS 4. Veranstalter: Prof. Dr. Heiko Krumm / Dipl. Inf. Oliver Dohndorf FB Informatik, LS IV, FG RvS, GBV, Raum 406b / 409a, Tel / Aufgabe Im Zuge der fortschreitenden Technologisierung erschließen gerade intelligente Umgebungen und körpernahe Sensoren neue Mehrwerte im Alltag der Menschen. Gerade vor dem Hintergrund einer alternden Gesellschaft bieten diese Assistenzsysteme innovative Lösungen zur Sicherstellung von Gesundheitsversorgung, Autonomie und gesellschaftlicher Teilhabe älterer und kranker Menschen. Eine der größten Herausforderungen bei der Umsetzung solcher Systeme ist der Umgang mit deren Dynamik, etwa der wechselnden Signalqualität von am Körper getragenen Sensoren, der Veränderung der installierten Sensorik oder der Umgebung. Beispielhaft ergibt sich folgendes Anwendungsszenario: Herr A. ist 48 Jahre alt und übt beruflich eine sitzende Tätigkeit aus. Aufgrund seines erhöhten Gewichts, seiner mangelnden Bewegung und seiner Krankengeschichte gilt Herr A. als Risikopatient für einen zukünftigen Herzanfall. Zur Minimierung des Risikos entscheidet sich Herr A. dafür ein speziell auf seine Bedürfnisse zugeschnittenes Vorsorgeprogramm in Kooperation mit einem medizinischen Institut durchzuführen. In seiner Jugend ist Herr A. viel Rad gefahren, bis der berufliche Stress eine Weiterführung des Hobbies unterband. Diese alte Liebe möchte Herr A. wieder aufgreifen, da sich die Sportart Radfahren aufgrund ihrer Eigenschaften (Ausdauersport, gelenkschonend bei Übergewicht) bestens für das Vorsorgeprogramm eignet. Auf seiner nun regelmäßig stattfindenden Tour nach Feierabend verwendet Herr A. die von dem medizinischen Institut bereitgestellten Sensoren ein kombinierter EKG- und Pulssensor und ein GPS-fähiges Smartphone und hält sich strikt an die Trainingsvorgaben der Betreuer, die einen persönlichen Trainingsplan erarbeitet haben. Dieser Plan gibt ein kombiniertes last- und pulsgesteuertes Training vor, Herr A. soll immer einen bestimmten Lastkorridor einhalten und eine max. Pulsfrequenz darf nicht überschritten werden. Schon vor dem Trainingsbeginn gibt es das erste Problem, der zur Verfügung gestellte Pulssensor ist defekt. Zum Glück hat Herr A. noch einen weiteren Sensor eines anderen Herstellers, den er auch benutzen kann. Während seiner Tour passieren verschiedene Ereignisse, die es notwendig machen den Trainingsplan dynamisch anzupassen. Direkt beim Start erkennt die Trainingssteuerung einen erhöhten Wert an Birkenpollen, so dass ein generell moderateres Training durchgeführt wird. Herr A. überquert den örtlichen Berg mit einer nennenswerten Steigung, infolge dessen erhöht sich die Pulsfrequenz stark und der Lastkorridor wird nach unten korrigiert. Auf der anschließenden Abfahrt und der Fahrt über die Landstraße mit starkem Rückenwind sinkt der Puls wieder soweit ab, dass der Lastkorridor wieder den ursprünglichen Wert annimmt. Als Herr A. auf einen Feldweg mit Kopfsteinpflaster abbiegt erkennt die Trainingssteuerung auf dem Smartphone Probleme mit dem Herzen. Durch die Information über die Bodenbeschaffenheit erkennt das System die Probleme aber als Bewegungsartefakte und ein Alarm wird nicht ausgelöst. Herr A. beendet seine Tour ohne weitere Zwischenfälle.

8 8-2 - A) GlobalSensing Bei dem nächsten Treffen mit den medizinischen Betreuern wird die Tour eingehend analysiert. Herr A. hat in einigen Teilbereichen signifikant erhöhte Pulswerte zu verzeichnen. Dennoch muss er sich keine Gedanken machen, da diese Anstiege alle Folge von Umwelteinflüssen waren. Steigende Temperaturen, einsetzender Sonnenschein, Gegenwind, Schotterwege und Steigungen können den problematischen Bereichen zugeordnet werden. Dennoch geht Herr A. nicht völlig zufrieden nach Hause, die Auswertung aller vorhandenen Daten ergibt, dass sich der Fitness-Level im Vergleich zur letzten Leistungsanalyse nicht verbessert hat. Bisher existierende ambiente Systeme sind fest mit den benötigten Sensoren gekoppelt, ihre Nutzung und Konfiguration sind aufeinander ausgelegt. Dadurch resultiert ein sehr hoher Entwicklungsaufwand, dessen Reduzierung eine große Herausforderung darstellt. Durch die Einführung eines neuartigen Sensor-Brokers entsteht eine Sensor-Infrastruktur, die unabhängig von den Anwendungen existiert und einfach in flexibler aber zuverlässiger und auf die Anwendungsanforderungen abgestimmter Weise von unterschiedlichen Anwendungen genutzt werden kann. Abbildung 1: Schematischer Aufbau des Sensor-Brokers Im vorgestellten Szenario leistet der Broker verschiedene Aufgaben zur Durchsetzung der genannten Paradigmen. Er ermöglicht anwendungsseitig die Abstraktion von Kommunikationsprotokollen und Datenformaten einzelner Sensoren. Hierdurch konnte der Patient bspw. seinen Pulssensor austauschen, ohne dass dies Auswirkungen auf die Applikation hat. Dieser Anwendungsfall motiviert eine zusätzliche Anforderung, nämlich dass Daten unabhängig von der Ausprägung des Sensors abgefragt werden können. Der Anwendung ist es grundsätzlich egal, von welchem Sensor die Pulsdaten kommen. Weiterhin kann der Broker Sensordaten mit verschiedenen Angaben, wie z.b. die Position des Sensors, physikalischen Maßeinheiten oder der Signalgüte, anreichern. Im Beispiel wird das EKG mit Daten aus dem Bewegungssensor des Smartphone annotiert, um so bei großen Erschütterungen die Daten als gestört zu markieren. Neben der Annotation von Daten können durch eine Aggregation verschiedener Sensoren neue, hochwertigere Daten entstehen. Der aktuelle Pollenwert wird dabei bspw. aus dem Mittelwert verschiedener Pollen- und Wettersensoren aus der Umgebung berechnet, oder ein Belastungswert des Trainierenden kann so aus der Herzfrequenz, der Geschwindigkeit, dem Geländeprofil und den Wetterdaten generiert werden. Dabei können die Daten aus unterschiedlichen Domänen stammen im Anwendungsbsp. aus der Meteorologie, aus Geoinformationen, und aus den Vitaldaten - und sowohl dynamisch zur Laufzeit verarbeitet werden als auch im Nachhinein, wie zur Ermittlung des Fittness-Level.

9 A) GlobalSensing Abbildung 2: Sensor-Broker Aus technischer Sicht ist der Broker dafür verantwortlich, dass zwischen den aus den Anwendungen stammenden Sensor-Nachfragen und den Sensor-Angeboten zur Laufzeit dynamisch passende Paarungen gefunden, gekoppelt und verwaltet werden. Aufgrund der geografischen Weite der einzelnen Sensoren ist der Broker durch eine verteilte, lose gekoppelte Architektur geprägt. Dabei stellt der Ansatz Service-orientierter Strukturen bzw. Architekturen (SOA) einen vielversprechenden Lösungsansatz dar. Es gibt verschiedene Technologien die das SOA-Paradigma umsetzen, wie bspw. OSGi eine dynamische Softwarekomponentenplattform oder das Devices Profile for Web Services (DPWS) eine Realisierung von Web-Services auf eingebetteten Systemen. So kann die Kommunikation der Anwendung mit dem Broker über offene und standardisierte Kommunikationsprotokolle, wie z.b. das genannte DPWS erfolgen. Ziele der Projektgruppe Ziel der PG ist es, Konzepte und Ideen für einen Sensor-Broker speziell für die besonderen Anforderungen ambienter Systeme zu entwickeln und diese anhand des vorgestellten Szenarios umzusetzen. Die Entwicklung erfolgt dabei in Zusammenarbeit mit verschiedenen Partnern aus Industrie und Gesundheitswesen. Die Firma Corscience stellt die medizinischen Sensoren zur Verfügung, zur Klärung medizinischer Fragestellungen stehen die Schüchtermann-Schiller schen Kliniken, eine auf Rehabilitation von Herzpatienten spezialisierte Klinik, zur Seite. Als Ausgangsbasis für die Implementierung dienen die erwähnten Technologien OSGi und DPWS, insbesondere der von der Firma MATERNA in Zusammenarbeit mit dem LS4 entwickelte Java Multi Edition DPWS Stack (JMEDS), sowie das quelloffene Android-Betriebssystem für die mobilen Komponenten. 6. Teilnahmevoraussetzungen Voraussetzungen: Wünschenswert: Kenntnisse im Bereich Rechnernetze und verteilter Systeme Kenntnisse in der objektorientierten Programmierung Java Kenntnisse Service-orientierter Architekturen

10 A) GlobalSensing 7. Minimalziel Das Minimalziel besteht aus 2 Teilen: Entwurf und Entwicklung eines Sensor-Brokers, der in der Lage ist die Anforderungen ambienter Systeme (Ressourcen-Effizienz, Stabilität, Anpassbarkeit, Datensicherheit) aus der medizinischen Domäne zu erfüllen. Die wichtigsten Anforderungen für den Broker müssen erfasst, bewertet und umgesetzt werden Entwurf und Entwicklung eines ambienten Systems, in dem die Funktionen von drei Sensoren aus unterschiedlichen Domänen über den Sensor-Broker integriert werden. Dieses System bildet die Grundlage für den beschriebenen Anwendungsfall, der beispielhaft implementiert werden soll und als Erprobung für die Broker-Architektur dient. 8. Literatur A] Bücher und Artikel zum Einlesen Gerd Wütherich, Nils Hartmann, Bernd Kolb, Mathias Lübken: Die OSGi Service Plattform. dpunkt.verlag, 2008 Thomas Künneth: Android 3: Apps entwickeln mit dem Android SDK. Galileo Computing, 2011 Kossmann, D., Leymann, F.: Web Services. Informatik-Spektrum 27(2), , (2004). Michael Kuschke, Ludger Wölfel: Web Services kompakt. Spektrum Akademischer Verlag, B] 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 Christoph Fiehe, Anna Litvina, Ingo Lück, Oliver Dohndorf, Jens Kattwinkel, Franz-Josef Stewing, Jan Krüger, Heiko Krumm: Location-Transparent Integration of Distributed OSGi Frameworks and Web Services. IEEE 23nd International Conference on Advanced Information Networking and Applications - Workshop SOCNE (AINA 2009), Bradford, UK, May Qi Han, Doug Hakkarinen, Pruet Boonma, Junichi Suzuki: Quality-Aware Sensor Data Collection. International Journal of Sensor Networks, Vol. 7,3; 2010 Sofie Van Hoecke, Kristof Steurbaut, Kristof Taveirne, Filip De Turck and Bart Dhoedt: QDesign and implementation of a secure and user-friendly broker platform supporting the end-to-end provisioning of e-homecare services; Journal of Telemedicine and Telecare 2010; 16: C] Internet Ressourcen The Devices Profile for Web Services (DPWS), Spezifikation: DPWS Einführung im Microsoft MSDN: OSGi Spezifikation: 9. Rechtlicher Hinweis Die Ergebnisse der Projektarbeit und die dabei erstellten 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.

11 B) Fußballspielende humanoide Roboter 11 Projektgruppenantrag: Fuÿballspielende humanoide Roboter 1 PGThema Maschinelles Lernen in der autonomen humanoiden Robotik. 2 PGZeitraum Wintersemester 20011/2012 und Sommersemester PGUmfang Jeweils 8 Semesterwochenstunden. 4 PG-Veranstalter Prof. Dr.Ing. Uwe Schwiegelshohn Raum IRF 314 uwe.schwiegelshohn@udo.edu Dipl.-Inf. Oliver Urbann Raum IRF 310 oliver.urbann@udo.edu Dipl.-Inf. Stefan Czarnetzki Raum IRF 304 stefan.czarnetzki@udo.edu 5 PG-Aufgabe Institut für Roboterforschung, Abteilung Informationstechnik Roboterfuÿball ist ein wichtiger, weltweit anerkannter Benchmark für KI-Systeme und autonome mobile Roboter. Die internationale Initiative RoboCup fördert diese Forschung und veranstaltet hierzu internationale Turniere, die allen Forschern die Möglichkeit geben, das Erreichte im direkten Vergleich zu testen und gemeinsam Fortschritte zu erzielen [2, 3]. In der Standard-Platform-League treten Roboter gleicher Bauart gegeneinander an. Unterschiede ergeben sich allein aus der Software. Die Roboter der Firma Aldebaran-Robotics [1] vom Typ Nao (siehe Abbildung 1) haben eine humanoide Form mit zahlreichen Freiheitsgraden und besitzen eine Vielzahl unterschiedlicher Sensoren, mit denen sie sich und ihre Umwelt wahrnehmen können. Das dazu entwickelte Software-Framework besteht aus Modulen, zusammengefasst zu den Bereichen Wahrnehmung und Bewegungsplanung. Eine Vielzahl dieser Module sind auf eine gute Parametrisierung der implementierten Algorithmen angewiesen. Diese müssen derzeit 1

12 12 B) Fußballspielende humanoide Roboter (a) Roboterfuÿballspiel auf der WM (b) Nao von Aldebaran Robotics. Abbildung 1: Roboterfuÿball in der SPL. regelmäÿig, beispielsweise vor dem Beginn eines Fuÿballspiels, zeitaufwändig manuell eingestellt werden. Ziel der Projektgruppe ist die Anwendung maschineller Lernverfahren zur Optimierung dieser Parameter. Hierfür kommen vor allem Black-Box-Verfahren in Frage, beispielsweise evolutionäre Algorithmen [8], Hill Climbing, Particle Swarm Optimization, Reinforcement Learning Bewegungsplanung [10] usw. Eine der wesentlichen Herausforderungen bei der Arbeit mit huma- noiden Robotern ist die Bewegungsplanung. Zweibeiniges Laufen wurde im theoretischen Bereich bereits aktiv erforscht. Das dynamische Modell eines laufenden Roboters lässt sich e zient berechnen und führt auch in Simulationen zu einem stabilen Lauf. Bereits in der Projektgruppe 521 wurde einer der vielversprechensten Ansätze unter den Laufalgorithmen für den Nao implementiert [7] und um eine Sensorkontrolle erweitert [5, 4]. Es zeigt sich in der Praxis allerdings, dass schnelles und stabiles Laufen nur durch eine gute Einstellung der Parameter des Lauf-Algorithmus erreicht werden kann. Die wesentliche Ursache für instabile Läufe sind Fehler bei der Umsetzung der berechneten Soll-Gelenkwinkel [6]. Ursache dafür sind die in den Gelenken zum Einsatz kommenden PID-Regler und Flexibilitäten und Toleranzen in der Mechanik. Dabei ist zu erkennen, dass die Abweichung zwischen Soll- und Ist-Winkel zusammenhängend mit dem Drehmoment am Gelenk steigt. Da diese Ungenauigkeiten schwer vorherzuberechnen sind, ist es beim derzeitigen Stand notwendig den Lauf regelmäÿig zu tunen, was zeitaufwändig ist und auch nicht immer zum gewünschten Ergebnis führt. Die oben erwähnten BlackBox-Optimierungsverfahren sollen daher auf ihre Eignung untersucht werden, einige der Parameter automatisch mit dem Ziel zu optimieren, dass der Roboter möglichst wenig schwankt. Wie bereits erwähnt sind Abweichungen in den Gelenken der Hauptgrund, warum theoretisch korrekte Läufe in der Praxis teilweise instabil sind. Eine höhere Übereinstimmung 2

13 B) Fußballspielende humanoide Roboter 13 vom Modell und Realität würde einen gröÿeren Bereichen theoretischer Läufe praktisch anwendbar machen und auch Konzepte wie Parametrisierung im Hinblick auf Energieezienz erlauben. Daher soll weiterhin ein neues Verfahren (im Folgenden Drehmomentsausgleich genannt) entwickelt und implementiert werden, das eine Funktion approximiert, die bei der Eingabe des Drehmoments am Gelenk 1 einen modizierten Soll-Winkel erzeugt, so dass der Ist-Winkel möglichst genau mit dem eigentlichen Soll-Gelenkwinkel übereinstimmt. Vereinfacht gesagt soll beispielsweise im Fall, dass der Ist-Winkel zu klein ist, ein gröÿerer Soll-Winkel zum Gelenk geschickt werden, so dass der Ist-Winkel näher am eigentlichen Soll liegt. Auch hier sollen die Parameter des Algorithmus automatisch während des realen Laufs optimiert werden. Wahrnehmung Der Bereich Wahrnehmung ist ebenso wichtig wie die Bewegungsplanung. Damit der Roboter korrekte Entscheidungen treen kann, wohin er gehen soll, in welche Richtung er schieÿen soll usw., ist es notwendig, Positionen von Objekten aus den Kamerabildern möglichst genau zu extrahieren. Die jeweils aktuelle Orientierung der Kamera exakt zu kennen ist dafür essentiell. Schon kleine Winkelfehler panzen sich zu groÿen Fehlern in der Entfernungsabschätzung fort. Ungenauigkeiten in der sogenannten Kamera- Matrix entstehen aber immer wieder durch Dekalibrierung während des Transports der Roboter oder durch Stürze und Zusammenstöÿe während der Spiele. Eine regelmäÿige Parametrisierung der Kamera-Matrix ist daher notwendig, und soll in Rahmen dieser Projektgruppe versuchsweise maschinell optimiert werden. Für den Fall, dass die neu entwickelten Methoden und Algorithmen auf unserem eigenen Fuÿballfeld gute Ergebnisse zeigen, werden diese in unserem Wettkampf-Code übernommen und auf den German Open 2012 und der Weltmeisterschaft RoboCup 2012 zum Einsatz gebracht. 6 PG-Teilnahmevoraussetzungen Kenntnisse zu objektorientierter Programmierung (Voraussetzung) der C++-Programmierung oder die Bereitschaft, sich dort einzuarbeiten (Voraussetzung) Matlab (wünschenswert) evolutionären Algorithmen oder anderen Optimierungsverfahren (wünschenswert) 1 Für Details zur Berechnung von Drehmomenten bei kinematischen Baumstrukturen siehe [9]. 3

14 14 B) Fußballspielende humanoide Roboter 7 Minimalziele Implementierung und Evaluation von wenigstens drei wählbaren Optimierungsverfahren (bspw. die oben vorgeschlagenen) und des Drehmomentsausgleichs. Die Optimierungsverfahren sollen auf die genannten Bereiche (Optimierung der Laufparameter, des Drehmomentsausgleichs oder der Kamera-Matrix) angewendet und mit einander verglichen werden. In wenigstens einem Bereich muss selbständig eine Verbesserung (geringere Schwankung bei unterschiedlichen Geschwindigkeiten, genauere Bestimmung der Objektpositionen) eintreten können. Literatur [1] Aldebaran robotics website [2] GermanOpen website [3] RoboCup website [4] Stefan Czarnetzki, Sören Kerner, and Oliver Urbann. Applying dynamic walking control for biped robots. In Proceedings RoboCup 2009 International Symposium, Graz, Austria, July [5] Stefan Czarnetzki, Sören Kerner, and Oliver Urbann. Observer-based dynamic walking control for biped robots. Robotics and Autonomous Systems, 57(8):839845, [6] D. Gouaillier, C. Collette, and C. Kilner. Omni-directional closed-loop walk for nao. In Humanoid Robots (Humanoids), th IEEE-RAS International Conference on, pages , [7] Shuuji Kajita, Fumio Kanehiro, Kenji Kaneko, Kiyoshi Fujiwara, Kazuhito Yokoi, and Hirohisa Hirukawa. Biped walking pattern generator allowing auxiliary zmp control. In IROS, pages IEEE, [8] Hans-Paul Schwefel. Evolution and Optimum Seeking. Sixth-Generation Computer Technology. Wiley Interscience, New York, [9] Bruno Siciliano and Oussama Khatib, editors. Handbook of Robotics. Springer, Berlin, Heidelberg, [10] Richard S. Sutton and Andrew G. Barto. Reinforcement Learning: An Introduction. MIT Press, Rechtliche Hinweise: Die Ergebnisse der Projektarbeit inkl. der dabei erstellten Software sollen dem Institut für Roboterforschung und der Fakultät für Informatik uneingeschränkt zur freien Forschung zur Verfügung stehen. Darüber hinaus sind keine Einschränkungen der Verwertungsrechte an den Ergebnissen der Projektgruppe und keine Vertraulichkeitsvereinbarungen vorgesehen. 4

15 C) Process-Cloud for Business 15 PG PCB Process-Cloud for Business Projektgruppe des Lehrstuhls für Programmiersysteme (LS 5) 1. Thema Nutzung von Cloud-Computing-Technologien zur Beherrschung komplexer Geschäftsprozess-Umgebungen 2. Zeitraum Wintersemester 2011/2012 und Sommersemester Umfang Jeweils 8 Semesterwochenstunden 4. Veranstalter Markus Doedt, OH14, R.130, Tel. 7756, markus.doedt@tu-dortmund.de Steve Boßelmann, OH14, R.138, Tel. 5802, steve.bosselmann@tu-dortmund.de Prof. Dr. Bernhard Steffen, Informatik, LS 5 5. Aufgabe Die Projektgruppe hat zum Ziel, aktuelle Technologien im Cloud-Computing-Umfeld als mögliche Grundlage für ein rechenzentrumsfreies Geschäftsprozessmanagement insbesondere hinsichtlich Skalierbarkeit und Steuerbarkeit zu evaluieren. Das soll gleichzeitig Klarheit darüber verschaffen, inwieweit die Kritik [1] von Peter König Das Buzzword Cloud Computing ist gut gewählt, ist es doch genauso wattig und schwer zu greifen wie das, was es im Grund bezeichnet, nämlich schleichende Abstraktion. gerechtfertigt ist. 5.1 Motivation Geschäftsprozessmanagement (auch Business Process Management, kurz BPM [2] [3] [4]) hat heutzutage eine unbestritten wichtige Rolle eingenommen gerade in großen Unternehmen. Durch die Dokumentation, Ausführung und Beobachtung von Geschäftsprozessen ist sich das Unternehmen seiner geschäftlichen Vorgänge bewusst und hat somit erst die Möglichkeit, diese strukturiert zu optimieren. Außerdem kann durch ein durchgängiges BPM die Nachvollziehbarkeit von Geschäftsvorgängen ermöglicht werden, was gerade in Folge heutiger Gesetzgebungen wie Basel II oder dem US-amerikanischen Sarbanes-Oxley-Act von besonderer Bedeutung ist. Die Vorgänge im Unternehmen werden also vor allem effizienter und nachvollziehbarer. Die elektronisch ausführbaren Geschäftsprozesse sind dabei oft Orchestrierungen großer Enterprise- Systeme (z.b. ERP-, CRM- oder SCM-Systeme). Diese Systeme werden besonders durch ihre großen Datenmengen charakterisiert. Gerade in Zeiten häufiger Unternehmensfusionen und Übernahmen entstehen dabei oft extrem heterogene Systemlandschaften mit z.b. gleich mehreren ERP-Systemen. Gleichzeitig wird besonders in diesem Umfeld der Wunsch nach fast grenzenloser Skalierbarkeit begründet. Genau hier sieht Cloud-Computing [5] nach einer vielversprechenden Lösung aus. Cloud-Computing ist mittlerweile nicht mehr nur Hype sondern eine real verfügbare Lösung geworden, da bereits eine ganze Reihe Softwarelösungen und Angebote auf dem Markt existieren. Anbieter wie zum Beispiel Google, Microsoft, Amazon oder Salesforce haben jeweils ausgereifte Produkte in ihrem Portfolio, die es ermöglichen, Anwendungen in der Cloud zu deployen. Das bedeutet, dass man sich selbst als Kunde keine Gedanken über Dinge, wie z.b. die Skalierung machen muss. In der Cloud werden immer so viele Ressourcen zur Verfügung gestellt, wie wirklich zum aktuellen Zeitpunkt benötigt werden und man bezahlt auch nur genau so viel. Auch viele andere technische Fragen muss sich der Kunde hier gar nicht stellen, da fertig benutzbare Services vom Cloud-Dienstleister angeboten werden und als Black Box benutzt werden können. Durch Cloud-Technologie kann man also den Einsatz eigener Rechner sowie den eigenen Administrationsaufwand deutlich verringern. In dieser Projektgruppe soll erarbeitet werden, inwieweit heutige Cloud-Angebote eingesetzt werden können, um skalierbare Geschäftsprozesse zu realisieren. Das kann zum Beispiel so aussehen, dass rechenintensive Teilprozesse, wie sie zum Beispiel bei Datenmigrationsszenarien und den damit PG PCB Seite 1

16 16 C) Process-Cloud for Business verbundenen Transformationen auftreten, von der zentralen Prozessverwaltungseinheit in die Cloud ausgelagert werden und z.b. auf der Google App Engine ausgeführt werden (siehe Abbildung 1). Andererseits können auch spezielle Dienste einer Cloud-Plattform, wie z.b. der Persistenz-Service oder der Timer-Service, genutzt werden. Dazu müssen die Dienste in die BPM-Plattform eingebunden werden. 5.2 Cloud-Technologien Abbildung 1: Durch die Cloud unterstützte Geschäftsprozesse Cloud-Technologien lassen sich im Wesentlichen in drei Kategorien einteilen: SaaS (Software as a Service), IaaS (Infrastructure as a Service) und PaaS (Plattform as a Service). Bei SaaS handelt es sich um nichts anderes als um Webapplikationen, die durch den Einsatz von Ajax-Technologien sehr ähnlich zu Desktopapplikationen sind. Ein gutes Beispiel hierfür ist zum Beispiel Google Text und Tabellen. Anstatt sich ein Office-Paket zu kaufen und an allen Mitarbeiter-Arbeitsplätzen zu installieren, benutzt man einfach das Office-Paket in der Cloud. Für diese PG ist diese Kategorie weniger interessant. Interessanter ist IaaS, wie es zum Beispiel von Amazon angeboten wird. Hier werden spezielle Infrastrukturdienste im Web angeboten, wie zum Beispiel Amazon S3 zur Datenspeicherung oder Amazon EC2 zur Nutzung von Rechenleistung. Auch einfache Dienste, wie z.b. Dropbox, kann man dieser Kategorie zuordnen. Es durchaus denkbar, IaaS-Lösungen im BPM-Bereich einzusetzen. Die für die PG wohl interessanteste Cloud-Kategorie ist PaaS, wie es zum Beispiel von Google mit der App Engine oder von Salesforce mit Force.com angeboten wird. Hier stehen komplette Plattformen zur Verfügung, auf die man einfach seine eigenen Applikationen deployen kann, ohne sich über die dahinterliegende, konkrete technische Infrastruktur Gedanken zu machen. Auch Microsoft hält mit Windows Azure eine Cloud-Lösung bereit, die je nach Einsatzart im Bereich IaaS oder PaaS eingeordnet werden kann. 5.3 Geschäftsprozess-Management Bei der Modellierung und Ausführung von Geschäftsprozessen verfolgt der Lehrstuhl 5 den Ansatz XMDD (extreme Model Driven Design, [6] [7] [8]). Dabei handelt es sich um eine Kombination der PG PCB Seite 2

17 C) Process-Cloud for Business 17 Ideen aus den Bereichen der Service-Orientierung [9], des Extreme Programming, des Model-driven Designs und der Aspekt-Orientierung. Im Zentrum der Entwicklung steht immer der ausführbare Prozess, der vom Anwendungsexperten modelliert wird. Dabei besteht der Prozess aus wiederverwendbaren, einfach zu benutzenden Bausteinen. Wichtig ist hier, dass der Anwendungsexperte selbst die Kontrolle über seine Prozesslandschaft hat und jederzeit agil Änderungen vornehmen kann, ohne große Aufträge an die IT-Abteilung weiterzugeben. Zur Umsetzung des XMDD-Konzeptes werden in der Projektgruppe verschiedene Technologien eingesetzt. Zur Modellierung der Prozesse wird das Eclipse Modelling Framework [10] eingesetzt. Dabei sind hier entsprechende Metamodelle und Erweiterungen speziell für den Einsatz im Bereich BPM schon fertig. Zur Ausführung der Prozesse wird die freie Prozessengine jbpm [11] von JBoss eingesetzt. 5.4 Anwendungsgebiet Enterprise-Systeme Die aktuell am Lehrstuhl 5 untersuchten Geschäftsprozesse bestehen meist aus einer Orchestrierung heterogener Systeme [12], besonders ERP-Systemen (Enterprise Resource Planing) wie z.b. SAP-ERP, Microsoft Dynamics oder Intuit Quickbooks, aber auch Office-Applikationen wie Microsoft Office oder OpenOffice oder auch schon Cloud-Dienste von Salesforce.com. Die Herausforderungen bestehen hier insbesondere in der Beherrschung der unterschiedlichen Technologien sowie der unterschiedlichen Datenmodelle und den daraus resultierenden komplexen Datentransformationen. Es existieren bereits Lösungen zur Ansteuerung der erwähnten Systeme. In Abbildung 2 sieht man ein Beispielszenario aus dem Amazon-Umfeld. Abbildung 2: Anwendungsbeispiel 5.5 Generelle Vorgehensweise Am Anfang der Projektgruppe wird die Einarbeitung in die theoretischen Grundlagen serviceorientierter Architekturen, des Geschäftsprozess-Management und des Cloud-Computings stehen. Anschließend werden bestehende Cloud-Lösungen betrachtet und dahingehend untersucht, inwieweit sie dazu dienen können, bei der Beherrschung von Geschäftsprozessen zu helfen. Danach können parallel verschiedene gefundene Möglichkeiten in praktischen Implementierungsversuchen genauer analysiert werden. Es ist beispielsweise vorstellbar, einen existierenden Java- Codegenerator zu benutzen, um einen Geschäftsprozess (oder auch nur einen Teilprozess) in Java- Code zu übersetzen und diesen dann auf die Google App Engine zu deployen. Ein anderes Team könnte untersuchen, ob mit Windows Azure ähnliches möglich ist. Anstelle des Generierungsansatzes könnte man auch Prozess-Engines wie z.b. jbpm in der Cloud deployen und so die Geschäftsprozesse in der Cloud ausführen zu lassen. Abhängig davon, was genau an Cloud-Dienstleistung angeboten wird, kann der Aufwand hier sehr unterschiedlich sein. Die Palette möglicher Nutzungen ließe sich hier noch weiter fortsetzen. Hier soll die Projektgruppe auch selbst kreativ mitarbeiten. Wichtig ist dabei auch zu betrachten, dass auch mehrere verschiedene Lösungen (auch von verschiedenen Anbietern) kombiniert werden können. Jeder Ansatz ist dabei auf seine spezifischen Stärken und Schwächen hin zu untersuchen. PG PCB Seite 3

18 18 C) Process-Cloud for Business 6. Teilnahmevoraussetzungen Erforderlich Fundierte Kenntnisse mindestens einer objektorientierten Programmiersprache (z. B. Java) Kenntnisse im Gebiet Software-Design und Implementierung Interesse an neuen Technologien und Bereitschaft, sich dort einzuarbeiten Wünschenswert Grundlegende Kenntnisse serviceorientierter Architekturen Grundlegende Kenntnisse zur Geschäftsprozessmodellierung Datenbankkenntnisse 7. Minimalziele Einarbeitung in grundlegende Theorien und Formalismen von serviceorientierten Architekturen und zur Modellierung von Geschäftsprozessen Eingehende Recherche im Bereich Cloud-Computing und Einarbeitung in aktuelle Technologien aus diesem Bereich Erfolgreiche Ausarbeitung eines Geschäftsprozesses unter Zuhilfenahme der erwähnten Technologien, mit sich anschließend erfolgtem Deployment auf einer kommerziellen Cloud- Plattform Systematischer Vergleich der implementierten Lösungen 8. Literatur [1] Peter König, Axel Kossel. Heiter bis wolkig. c't Magazin für Computertechnik, S. 111, Ausg. 6, Feb [2] W.M.P. van der Aalst: Business Process Management Demystified: A Tutorial on Models, Systems and Standards for Workflow Management. In Lectures on Concurrency and Petri Nets, volume 3098 of LNCS, pages Springer-Verlag, Berlin, [3] Peter Dadam: The Future of BPM: Flying with the Eagles or Scratching with the Chickens?, In Business Process Management, volume 5240 of LNCS, Springer-Verlag, Berlin, 2008 [4] Stephane Cagnon, Thomas Woodley: BPM and SOA: Synergies and Challenges. In Web Information Systems Engineering 2005, volume 3806 of LNCS, Springer-Verlag, Berlin, 2005 [5] Brian Hayes. Cloud computing. In Commun. ACM 51, 7 (July 2008), [6] Tiziana Margaria, Bernhard Steffen: Agile IT: Thinking in User-Centric Models. ISoLA 2008: [7] Tiziana Margaria, Bernhard Steffen: Service Engineering: Linking Business and IT. IEEE Computer 39(10): (2006) [8] Tiziana Margaria, Bernhard Steffen: Continuous Model-Driven Engineering, IEEE Computer 42(10): (2009) [9] He, H. What is Service-Oriented Architecture. [10] R. C. Gronback: Eclipse Modeling Project - A Domain-Specific Language (DSL) Toolkit. Addison-Wesley Longman, Amsterdam; Auflage: 1 (6. März 2009) [11] JBoss jbpm: [12] Markus Doedt, Bernhard Steffen, Requirement-Driven Evaluation of Remote ERP-System Solutions: A Service-oriented Perspective, eingereicht bei IEEE Software Engineering Workshop (SEW), 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. PG PCB Seite 4

19 D) ChipSim 19 Projektgruppenantrag: ChipSim 1. Thema: Modellierung und Simulation plastoelastischer Objektinteraktionen 2. Zeitraum: WS 2011/2012, SoSe Umfang: jeweils 8 SWS pro Semester 4. Veranstalter: Dipl.-Inform. Denis Fisseler (LS VII) fisseler@ls7.cs.tu-dortmund.de Tel.: 6328 Prof. Dr. Heinrich Müller (LS VII) mueller@ls7.cs.tu-dortmund.de Tel.: 6324 Dipl.-Inf. Raffael Joliet (ISF) joliet@isf.de Tel.: 2364 Dr.-Ing. Dipl.-Inform. Petra Kersting (ISF) pkersting@isf.de Tel.: Aufgabe: Zahlreiche Komponenten in der Luft- und Raumfahrttechnik (Abbildung 1) wie beispielsweise Turbinenschaufeln werden mittels spanender Fertigungsverfahren hergestellt [HCL + 05]. Zur optimalen Prozessauslegung werden Simulationssysteme eingesetzt [WMK + 02], welche den Materialabtrag und die daraus resultierenden Kräfte gut abbilden sowie die Kinematik des Prozesses inklusive Kollisionsberechnung sehr gut simulieren können. Zur detaillierten Analyse des Fräsprozesses ist darüber hinaus eine genaue Betrachtung des Materialabtrags notwendig. Diese sogenannte Spanbildung lässt sich allgemein dadurch beschreiben, dass sich ein in erster Näherung starrer Körper (die Schneide) durch einen anderen nichtstarren Körper (das Werkstück) bewegt (Abbildung 2a), der dadurch plastischen und elastischen Deformationen unterworfen wird (Abbildung 2b). Im Gegensatz zu relativ rechenzeitaufwändigen Finite- Elemente-Simulationen (Abbildung 2c) haben sich partikelbasierte Simulationssysteme als vielversprechend erwiesen [LESL07, Bic07], da diese eine wesentlich einfachere Beschreibung der physikalischen und geometrischen Effekte erlauben. Ausgehend von dieser Problemstellung ist die Zielsetzung dieser Projektgruppe der Entwurf und die Implementierung eines interaktiven Simulations- und Visualisierungssystems zur Untersuchung der Spanbildung. Dazu können ein Smoothed-Particle-Ansatz wie beispielsweise Smoothed Particle Hydrodynamics (SPH)[AW09], Moving-Least-Squares-Approximation (MLS) oder einfache Ersatzsysteme [NMK + 05] entwickelt und umgesetzt werden. Hierzu benötigte Datenstrukturen, Algorithmen und Konzepte sind aus entsprechenden Vorlesunwww.airbus.de Spanende Bearbeitung Abbildung 1: Anwendungsbeispiel aus der Luft- und Raumfahrttechnik

20 20 D) ChipSim a) 1 b) 3 c) Werkzeug 2 Werkstück 3 Abgetrenntes Material (Span) Abbildung 2: a) Simulation eines Spanbildungsprozesses (DaimlerChrysler AG, wbk), b) reale Spanbildung. Es wird Material abgenommen (Span) und unter der Schneide hindurchgedrückt (iwf) und c) vernetzte Modellierung eines Spans (Kennametal Technologies GmbH) gen wie zum Beispiel MMI, GM, DV oder GDV bekannt. Mithilfe des zu entwickelnden Softwaresystems zur Modellierung und Simulation plastoelastischer Objektinteraktionen sollen realistische Effekte wie zum Beispiel Quetschvorgänge unter der Schneide (vergleiche Abbildung 2b) qualitativ abgebildet werden. Aufgabenbeschreibung: Zur Lösung der Problemstellung sind im Rahmen dieser Projektgruppe Methoden der geometrischen Modellierung und Visualisierung sowie mathematische Lösungsverfahren zu entwerfen, zu implementieren und anhand einfacher geometrischer Anwendungsfälle und des komplexeren Spanbildungsvorganges zu validieren. Zur Umsetzung der geplanten Teilaufgaben ergeben sich daraus folgende Arbeitsschritte, die von Kleingruppen bearbeitet werden können: 1. Modellerstellung: Als Grundlage ist zunächst ein Modell zu erstellen, das in der Lage ist, geometrische Objekte und ihre Eigenschaften zu beschreiben. Hierzu können bereits bekannte Methoden (wie beispielsweise SPH [Mon05]) eingesetzt und an die spezielle Aufgabenstellung angepasst werden. Dabei sollte eine erweiterbare objektorientierte Modellierung im Vordergrund stehen, die allerdings auch hohe Berechnungsgeschwindigkeiten zulässt. Neben der Integration einfacher geometrischer Primitive soll auch eine Schnittstelle für komplexe Objekte implementiert werden, die auf der Basis eines flexiblen Beschreibungsformats wie XML basiert. 2. Kollisionsdetektion: Zur Simulation der Objektinteraktion ist unter Verwendung von Methoden der Kollisionserkennung eine Kopplung zwischen geometrischen und partikelbasierten Komponenten der Simulation zu entwerfen. Neben der konkreten Kollisionserkennung sollen auch Beschleunigungstechniken wie zum Beispiel Hüllvolumen und hierarchische Raumunterteilungsverfahren zum Einsatz kommen [AM91]. 3. 3D-Visualisierung: Für einen intuitiven Zugang zu Modellen und späteren Ergebnissen ist eine flexible Echtzeitvisualisierung zu realisieren. Außerdem können physikalische

21 D) ChipSim 21 Abbildung 3: Simulierte Kollision einer plastoelastischen Kugel mit einer starren Fläche [FE08] Größen, wie zum Beispiel Geschwindigkeiten, unter Verwendung von geeigneten Visualisierungskonzepten dargestellt werden. 4. GPGPU-Programmierung: Zur Implementierung einer interaktiven Visualisierung bietet sich die Verwendung einer existierenden grafischen Programmierschnittstelle wie OpenGL [MB05] und die Nutzung von GPGPU-Techniken an. Auch können diese Techniken zur Beschleunigung von Berechnungen unter Verwendung GPU-basierter Ansätze (Cuda, OpenCL) genutzt werden. 5. Grundlegende Tests mit geometrischen Primitiven: Zur Validierung des entwickelten Frameworks sind einfache Testfälle zu generieren und zu implementieren. Mindestens visuell sollen sich dabei in der Simulation realistische Effekte zeigen. Dieses können einfache Kollisionen zwischen primitiven geometrischen Objekten sein, die generierten Bahnen folgen oder Kräften unterliegen. 6. Realisieren einer Zerspansimulation: Das in den vorherigen Schritten implementierte Simulationsframework wird in diesem Arbeitspaket erweitert, um den Materialabtrag während eines Fräsprozesses nachbilden zu können. Hierzu müssen grundlegende Methoden für die Beschreibung von Bewegungsbahnen und zur Modellierung des Werkzeugs entwickelt werden. Anhand einer einfachen Relativbewegung zwischen Werkzeug und Material ist zu überprüfen, ob die Simulation realistische Effekte vorhersagen kann (Abbildung 2b). Bei der Umsetzung dieser Anforderungen in ein Softwaresystem sollen verschiedene Entwurfsphasen durchlaufen werden [Bal96], welche u. a. die Erstellung von Lasten- und Pflichtenheft oder die Erstellung von Gantt Charts beinhaltet. Zudem sollen adäquate Werkzeuge (Quellcodeverwaltung, Wiki-System, Bugtracking) eingesetzt werden dieses geht mit der angestrebten modularen Umsetzung einher. Die Themenstellung beinhaltet aktuelle Forschungsschwerpunkte des LS VII und des ISF und bietet damit den Studierenden die Möglichkeit für anschließende Master- oder Diplomarbeiten. 6. Teilnahmevoraussetzungen: Notwendige Voraussetzungen Kenntnisse in Geometrieverarbeitung, Computergrafik oder grafischer Datenverarbeitung Kenntnisse einer objektorientierten Programmiersprache (z. B. C++ oder Java) Wünschenswert Kenntnisse in geometrischem Modellieren, Datenvisualisierung oder digitaler Bildverarbeitung Kenntnisse in Software-Technologie DirectX- oder OpenGL-Programmierung