Entwicklung und Erprobung innovativer Produkte - Rapid Prototyping GERMAN

Bernd Bertsche · Hans-Jörg Bullinger (Hrsg.) Entwicklung und Erprobung innovativer Produkte – Rapid Prototyping Bernd...

Author: Bernd Bertsche | Hans-Jorg Bullinger

63 downloads 3024 Views 16MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Bernd Bertsche · Hans-Jörg Bullinger (Hrsg.) Entwicklung und Erprobung innovativer Produkte – Rapid Prototyping

Bernd Bertsche · Hans-Jörg Bullinger (Hrsg.)

Entwicklung und Erprobung innovativer Produkte – Rapid Prototyping Grundlagen, Rahmenbedingungen und Realisierung Unter Mitarbeit von Heiko Graf sowie Thorsten Rogowski und Joachim Warschat

mit 240 Abbildungen

123

Prof. Dr.-Ing. Bernd Bertsche Universität Stuttgart Institut für Maschinenelemente Pfaffenwaldring 9 70569 Stuttgart [email protected] Prof. Dr.-Ing. habil. Prof. e.h. mult. Dr. h.c. mult. Hans-Jörg Bullinger Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Postfach 200733 80007 München [email protected]

Bibliografische Information der Deutsche Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN 978-3-540-69879-1 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2007 Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Sollte in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z. B. DIN, VDI, VDE) Bezug genommen oder aus ihnen zitiert worden sein, so kann der Verlag keine Gewähr für die Richtigkeit, Vollständigkeit oder Aktualität übernehmen. Es empfiehlt sich, gegebenenfalls für die eigenen Arbeiten die vollständigen Vorschriften oder Richtlinien in der jeweils gültigen Fassung hinzuzuziehen. Satz: Digitale Druckvorlage der Herausgeber Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: WMXDesign, Heidelberg Gedruckt auf säurefreiem Papier 68/3100 YL – 5 4 3 2 1 0

Vorwort

„Wenn wir Schlittschuh über dünnes Eis laufen, liegt unser Heil nur in der Schnelligkeit.“ meinte Ralph Waldo Emerson (1803-82), amerikanischer Philosoph und Dichter. Innovationsorientierte Unternehmen müssen in der Lage sein zu beschleunigen, wenn es drauf ankommt. Sie müssen „die Nase vorn haben“ mit Erfolg versprechenden Neuerungen, um die Konkurrenz auf dem überlasteten Eis förmlich stehen zu lassen. Wie sieht das Umfeld in der Forschung und Entwicklung heutzutage aus? Zeit- und Kostendruck, eine stark differenzierte Markt- bzw. Kundenorientierung, sowie steigende Qualitätsanforderungen sowohl bei den Produkten wie auch den zugehörigen Prozessen bilden herausfordernde und treibende Rahmenbedingungen. Innovationen müssen in diesem turbulenten und komplexen Umfeld nicht nur zielgerichtet und Ressourcen schonend sondern auch schnell und effizient entwickelt werden. „Wer auf dünnem Eis verharrt, kann schnell einbrechen.“ „Entwicklung und Erprobung innovativer Produkte – Rapid Prototyping“ ist die Zielsetzung des von der DFG geförderten Sonderforschungsbereichs 374, dessen Ergebnisse in diesem Band beschrieben werden. Hauptanliegen ist dabei die Verkürzung der für die Produktentwicklung benötigten Zeit unter den aktuellen Rahmenbedingungen. Dieses Ziel kann nur ganzheitlich und interdisziplinär gelöst werden. Ausgehend von der Fragestellung: „Welche Methoden und Werkzeuge können Unternehmen dabei unterstützen, innovative Produkte in kurzer Zeit zu entwickeln?“ ergeben sich weitere Fragen, auf die in diesem Band eingegangen wird: x Wie kann die Arbeit in interdisziplinären Teams möglichst effektiv organisiert werden? Wie wird Wissen aus unterschiedlichen Disziplinen effizient integriert? Wie kann bei den vorhandenen flexiblen iterativen Prozessen schon in den frühen Entwicklungsphasen das Projektmanagement unterstützt und der Termin gehalten werden? x Wie können Kosten und Qualität während des kompletten Produktentwicklungsprozesses so abgeschätzt und sicherstellt werden, dass die Zielvorgaben erreicht werden?

VI

Vorwort

x Welche informationstechnische Unterstützung wird benötigt, um die Vielzahl der anfallenden Informationen anwendungsübergreifend zu bündeln, zu integrieren, zu verteilen und darzustellen? x Wie können möglichst früh Aussagen über die Eigenschaften der in der Entwicklung befindlichen Produkte gemacht werden? Wie können physische, virtuelle und hybride Prototypen den Produktentwicklungsprozess beschleunigen und beitragen, die Qualitäts- und Kostenziele zu erreichen? Während der zwölfjährigen Laufzeit des Sonderforschungsbereichs 374 wurden die dargestellten Fragen intensiv und systematisch erforscht. Durch die interdisziplinäre Verknüpfung der Fachgebiete Psychologie, Betriebswirtschaftslehre, Ingenieurwissenschaften und Informatik konnten umfassende Lösungen erarbeitet werden. Diese basieren auf dem Gedanken einer evolutionären und iterativen Produktentwicklung. Kennzeichnend hierfür sind die gezielte Nutzung schneller Iterationszyklen, die situationsgerechte Verwendung von Prototypen sowie die dezentrale Struktur selbstorganisierter, vernetzter Teams. Als Anwendungsfeld wurde die Automobilbranche gewählt, weil diese durch ihre Größe und Stärke in Deutschland eine klare Vorreiterrolle innehat und für viele Branchen als Beispiel und Trendsetter in der Produktentwicklung fungiert. Durch den intensiven Dialog mit der Industrie wurde die Praxisrelevanz der erarbeiteten Ergebnisse sichergestellt. Die erarbeiteten und anwendungsorientiert dargestellten Ergebnisse ermöglichen dem Leser einen intensiven Einstieg in das Thema und geben Anregungen zum Einsatz im Unternehmen. Die entwickelten Methodiken und Techniken werden praxisnah beschrieben und erläutert. Der wissenschaftlich interessierte Leser erhält einen umfassenden Überblick über den Stand der Technik sowie eine Vielzahl von Anregungen für seine Forschungsarbeiten. Als Sprecher des Sonderforschungsbereichs 374 „Entwicklung und Erprobung innovativer Produkte – Rapid Prototyping“ danken wir an dieser Stelle der Deutschen Forschungsgemeinschaft für ihre Unterstützung und die gute Kooperation, die diesen Sonderforschungsbereich erst möglich machten. Wir danken den am Sfb 374 beteiligten Institutionen, deren Einsatz und ausgezeichnete Zusammenarbeit an diesem gemeinsamen Projekt maßgeblich den Erfolg des Sonderforschungsbereichs sicherten: x Betriebswirtschaftliches Institut – Lehrstuhl Controlling, Stuttgart x DaimlerChrysler AG, Stuttgart x Höchstleistungsrechenzentrum, Stuttgart

Vorwort

VII

x Institut für Arbeitswissenschaft und Technologiemanagement, Stuttgart x Institut für Industrielle Fertigung und Fabrikbetrieb, Stuttgart x Institut für Kunststoffprüfung und Kunststoffkunde (jetzt: Institut für Kunststofftechnik), Stuttgart x Institut für Maschinenelemente, Stuttgart x Institut für Psychologie (jetzt: Institut für Allgemeine Psychologie), TU Dresden x Institut für Rechnergestützte Ingenieursysteme, Stuttgart x Institut für Strahlwerkzeuge, Stuttgart x Institut für Umformtechnik, Stuttgart Unser Dank geht nicht zuletzt an die Autoren und die Redaktion, bestehend aus Dipl.-Ing. Jens Bohnet, Dipl.-Inform. Michael Diederich, Dipl.-Kfm. Jens Leyh, sowie cand. fmt. Markus Prasse, unter der Leitung von Dipl.-Ing. Heiko Graf. Sie haben durch ihre Flexibilität und intensive Absprache ermöglicht, dieses Herausgeberwerk integrativ zu schreiben und die komplexen Zusammenhänge umfassend und prägnant darzustellen. Weiterhin danken wir Prof. Dr.-Ing. Joachim Warschat und Dipl.Wirtsch.-Ing. Thorsten Rogowski von der Geschäftsstelle des Sfb 374 für die nicht immer einfache Koordination der Arbeiten des gesamten Sonderforschungsbereiches. Der deutschen Wirtschaft fällt es schwer mit dem beschleuigten Tempo der globalisierten Märkte Schritt zu halten. Der entscheidende Stellhebel zum schnelleren "time to market" ist die Verkürzung der Entwicklungszeiten. Die in diesem Band vorgestellten Methoden und Werkzeuge sollen Ihnen dabei eine Unterstützung bieten. Wir hoffen, dass wir Ihnen als Leser Ideen und Anregungen für Ihre tägliche Arbeit geben können. Wenn Sie durch die Vorschläge in diesem Band schneller zu innovativen Produkten kommen, dann haben wir ein wichtiges Ziel erreicht, nämlich neue Methoden und Werkzeuge aus der Forschung in die industrielle Praxis zu transferieren und damit die deutschen Unternehmen zu stärken. Bezogen auf das eingangs zitierte Bild von Ralph Waldo Emerson heißt das, dass sie den benötigten Schwung erhalten, um auf dem dünner gewordenen Eis davon zu fliegen. Stuttgart, im Dezember 2006

Hans-Jörg Bullinger Bernd Bertsche

Inhalt

1 Einleitung................................................................................................. 1 1.1 Übersicht über den Sonderforschungsbereich 374 ........................... 1 1.1.1 Ziele........................................................................................... 1 1.1.2 Überblick ................................................................................... 2 1.1.3 Prototypen im RPD.................................................................... 6 1.1.4 IT Unterstützung im RPD........................................................ 11 1.1.5 Sfb 374 - Aufbau und Wissenswertes...................................... 19 1.2 Integrationsszenario........................................................................ 23 1.2.1 Grundlegende Verbesserungen................................................ 26 1.2.2 Integration der Teilprojekte am Beispiel eines Pkw-Cockpits 27 2 Organisation und Wissenskooperation ............................................... 33 2.1 Merkmale des Rapid Product Development ................................... 33 2.2 Anforderungen an Produktentwicklungsteams............................... 34 2.2.1 Innovationsanforderungen ....................................................... 34 2.2.2 Komplexitätsanforderungen .................................................... 35 2.2.3 Kooperationsanforderungen .................................................... 38 2.3 Planungsmethoden innovativer Produkte in dezentralen Teams .... 40 2.3.1 Grenzen einer formalen Planung für das Rapid Product Development........................................ 40 2.3.2 Potenziale der evolutionären Planung für das Rapid Product Development........................................ 41 2.3.3 Kompetenzmanagement zur Unterstützung einer evolutionären Planung für das RPD ............................... 44 2.3.4 Das entwicklungsfähige Projektplanungssystem für das RPD 47 2.3.5 Zusammenfassung und Ausblick............................................. 68 2.4 Wissensintensive Kooperationsprozesse bei der Entwicklung innovativer Produkte ..................................... 70

X

Inhalt

2.4.1 Ausgangssituation.................................................................... 70 2.4.2 Modellentwicklung und Ableitung von Unterstützungsinstrumenten zur Wissensintegration im RPD. 76 2.4.3 Ergebnis der Modellentwicklung zur Wissensintegration ....... 78 2.4.4 Ergebnisse der Analyse von Kooperationskonstellationen im Produktentwicklungsprozess (Studie 1) ............................. 82 2.4.5 Ergebnisse der Untersuchung von Kooperationsanforderungen im Produktentwicklungsprozess (Studie 2) ............................. 88 2.4.6 Handlungsempfehlungen aus Studie 1 und 2........................... 93 2.4.7 Ergebnisse der Untersuchung von Auswirkungen fachlicher Teamheterogenität (Studie 3) ................................. 94 2.4.8 Handlungsempfehlungen zur Wissensintegration aus Studie 3............................................................................ 106 2.4.9 Umsetzung der Ergebnisse aus den Studien in Unterstützungsinstrumente ................................................ 108 2.4.10 Ausblick............................................................................... 110 2.4.11 Zusammenfassung ............................................................... 112 Literatur .............................................................................................. 114 3 Vernetztes Wissen für die interaktive Entwicklung von Prototypen .................................................................................... 123 3.1 Vernetztes Entwicklungswissen durchgehend nutzen .................. 127 3.2 Aktives Semantisches Konstruktions- und Zuverlässigkeitsnetz . 130 3.2.1 Semantische Vernetzung ....................................................... 135 3.2.2 CAD – Datenaustausch.......................................................... 136 3.2.3 Integration der Produktkostenüberwachung .......................... 138 3.2.4 Integration der qualitativen und quantitativen Zuverlässigkeitsanalyse ......................................................... 139 3.2.5 Anwendungsbeispiele............................................................ 146 3.2.7 Zusammenfassung ................................................................. 158 3.3 Qualitätsmanagement im Rapid Prototyping................................ 159 3.3.1 Frühe Phasen – Prognose und Merkmalsextraktion .............. 161 3.2.2 Methoden der Risikoanalyse in der Produktkonfiguration .... 167 3.2.3 Verfahren und Methoden der Prozessüberwachung .............. 172 3.2.4 Systemfeedback – Umfassendes Qualitätsmanagement mit material- und prozessimmanenten Informationen........... 176 3.3.5 Zusammenfassung ................................................................. 183 3.4 Kostenmanagement im Prozess des Rapid Prototyping ............... 184 3.4.1 Überblick über das Forschungsprojekt .................................. 184 3.4.2 Ergebnisse und ihre Bedeutung ............................................. 185 Literatur .............................................................................................. 199

Inhalt

XI

4 Wissensrepräsentation und Kommunikation (RPD-IT-Infrastruktur) ..................................................................... 205 4.1 Ganzheitliche Modelle zur Repräsentation aktiven Wissens........ 209 4.1.1 Einleitung .............................................................................. 209 4.1.2 Problemstellung ..................................................................... 210 4.1.3 Meilensteine der Entwicklung, Stufe 1 – ASN, Metamodell, ECA.................................................................. 210 4.1.4 Meilensteine der Entwicklung, Stufe 2 – Verteiltes Objektmanagement, Slot-Dämon, Transaktionskonzept ....... 212 4.1.5 Meilensteine der Entwicklung - Stufe 3 ................................ 214 4.1.6 Ergebnisse und ihre Bedeutung ............................................. 223 4.1.7 Zusammenfassung der Ergebnisse......................................... 234 4.1.8 Offene Fragen und Ausblick.................................................. 236 4.2 Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development ............. 238 4.2.1 Die Herausforderung: Wissenskommunikation im Rapid Product Development ............................................ 238 4.2.2 Stand der Technik.................................................................. 240 4.2.3 Das Aktive Semantische Netz ............................................... 247 4.2.4 Die agentenbasierte RPD-Middleware .................................. 251 4.2.5 Zusammenfassung ................................................................. 266 4.3 Teamorientiertes Kommunikationssystem für vernetztes Arbeiten ................................................................. 267 4.3.1 Einleitung .............................................................................. 267 4.3.2 Entwicklungsverlauf der Arbeiten im Teilprojekt ................. 268 4.3.3 Stand der Forschung .............................................................. 270 4.3.4 Methoden ............................................................................... 280 4.3.5 Ergebnisse.............................................................................. 281 4.4 Adaptive Benutzungsoberflächen ................................................. 295 4.4.1 Einleitung .............................................................................. 295 4.4.2 Grundlagen von adaptiven Benutzungsoberflächen .............. 296 4.4.3 Das RPD-Portal ..................................................................... 303 4.4.4 Zusammenfassung ................................................................. 315 Literatur .............................................................................................. 316 5 Erstellung virtueller und physischer Prototypen............................. 329 5.1 Virtuelle Realität........................................................................... 330 5.1.1 Virtuelle Realität in der Produktentwicklung ........................ 330 5.2 Virtuelle Realität als Gestaltungs- und Evaluationswerkzeug...... 333 5.2.1 Montierbarkeitsuntersuchungen am Virtuellen Prototypen... 333 5.2.2 Visuelle Beurteilung von Objektgeometrien ......................... 335 5.2.3 Lageänderung von 3D-Objekten im Raum............................ 337

XII

Inhalt

5.2.4 Verbauwege, Einsehbarkeit, Beurteilung der Handlungen des Monteurs im Kontext ...................................................... 340 5.2.5 Data Mining in Virtuellen Umgebungen ............................... 343 5.3 VR in der Konstruktion ................................................................ 344 5.3.1 CAD-Review ......................................................................... 344 5.3.2 CAD-VR Integration ............................................................. 347 5.3.3 VR am Konstruktionsarbeitsplatz.......................................... 351 5.3.4 Realitätsnahe Darstellung in VR ........................................... 353 5.4 Paralleles Rendering ..................................................................... 356 5.5 Virtuelle und Hybride Prototypen ................................................ 362 5.5.1 Virtuelle Prototypen .............................................................. 363 5.5.2 Online-Simulationen.............................................................. 364 5.5.3 Hybride Prototypen ............................................................... 370 5.5.4 Kooperatives Arbeiten mit virtuellen und hybriden Prototypen .............................................................. 374 5.5.5 Zusammenfassung und Ausblick........................................... 377 5.6 Daten- und informationstechnische Integration des Entwurfsprozesses in die RPD-Prozesskette .......................... 379 5.6.1 Ausgangssituation.................................................................. 379 5.6.2 Lösungsansätze...................................................................... 381 5.6.3 Zusammenfassung ................................................................. 392 5.6.4 Ausblick................................................................................. 395 5.7 Multi Material Modelling von Design- und Funktionsprototypen..................................................................... 395 5.7.1 Multi Material Modelling für den iterativen Aufbau von konzeptionellen Prototypen ............................................................ 396 5.7.2 Funktionalisierung von Prototypen durch das Multi Material Modelling ...................................................... 399 5.7.3 Zusammenfassung und Ausblick........................................... 400 5.8 Oberflächenveredelung von RP-Bauteilen ................................... 401 5.8.1 Ausgangssituation.................................................................. 401 5.8.2 Anforderungen an Oberflächen ............................................. 402 5.8.3 Verfahren zur Veränderung der Eigenschaften von Oberflächen ........................................................................... 403 5.8.4 Lösungsansätze zur Funktionalisierung von RP-Bauteilen ... 404 5.8.6 Verfahrenskombinationen ..................................................... 409 5.8.7 Zusammenfassung und Ausblick........................................... 411 5.9 Lasergenerieren im modularen System ........................................ 412 5.9.1 Einleitung .............................................................................. 412 5.9.2 Verfahrensprinzip .................................................................. 413 5.9.3 Prozesssteuerung ................................................................... 415 5.9.4 Prozesskontrolle durch einen Tiefensensor ........................... 420

Inhalt

XIII

5.9.5 Prozessregelung ..................................................................... 422 5.9.6 Modulares System ................................................................. 427 5.9.7 Zusammenfassung und Ausblick........................................... 429 5.10 Selektives Lasersintern von Hochleistungspolymeren mittels Nd:YAG-Laser................................................................. 430 5.10.1 Einleitung ............................................................................ 430 5.10.2 Ausgangssituation................................................................ 431 5.10.3 Lösungsansätze.................................................................... 436 5.10.4 Weiterentwicklung der Prozesstechnik................................ 440 5.10.5 Verfahrenskombinationen ................................................... 442 5.10.6 Zusammenfassung und Ausblick......................................... 442 5.11 Prototypwerkzeuge und Prototypbauteile................................... 444 5.11.1 Werkstoffe für Prototyp-Werkzeuge ................................... 445 5.11.2 Grauguss .............................................................................. 445 5.11.3 Stahl und Aluminium........................................................... 446 5.11.4 Niedrigschmelzende NE- Schwermetall-Legierungen ........ 446 5.11.5 Kunststoffe, Polyamide und Photopolymere ....................... 447 5.11.6 Werkzeugentwicklung ......................................................... 450 5.11.7 3D-Visualisierung der Werkzeugkonstruktion .................... 456 5.11.8 Visualisierung der Simulation des Umformvorgangs.......... 458 5.11.9 Werkzeugherstellungsprozesse............................................ 460 5.11.10 Optimierung des Prozesses durch Einsatz des Vakuumformverfahrens .............................................. 461 5.11.11 Tribologische Anforderungen an die Werkzeugwirkfläche465 5.11.12 Charakterisierung des Verschleißverhaltens...................... 470 5.11.13 Einfluss des Prototypwerkzeugstoffes auf die Kriterien Prototyp-Teilequalität und Werkzeugstandzeit ................. 473 5.11.14 Segment-elastischer Niederhalter aus Kunstharz mit Pyramidenstumpfförmigen Stahl-Einsätzen................. 475 Literatur .............................................................................................. 478

Autorenverzeichnis

Kap.

Name, Vorname

Titel

Institut

1 1.1

Rogowski, Thorsten

Dipl.-Wirtsch.Ing.

Warschat, Joachim

Prof. Dr.-Ing. habil.

Institut und (IAT) Institut und (IAT)

Bertsche, Bernd Graf, Heiko

Univ.-Prof. Dr.-Ing. Dipl.-Ing.

Institut für Maschinenelemente (IMA) Institut für Maschinenelemente (IMA)

Kremer, David

Dipl.-Psych.

für Arbeitswissenschaft Technologiemanagement

Leyh, Jens

Dipl.-Kfm


Kremer, David

Dipl.-Psych.


Leyh, Jens

Dipl.-Kfm


Laufs, Uwe

M.Comp.Sc. Dipl.-Ing.(FH)


Leyh, Jens

Dipl.-Kfm

Spath

Prof. Dr.-Ing.

Institut und (IAT Institut und (IAT) Institut und (IAT)

1.2

2 2.1

2.2

2.3

für Arbeitswissenschaft Technologiemanagement für Arbeitswissenschaft Technologiemanagement



für Arbeitswissenschaft Technologiemanagement für Arbeitswissenschaft Technologiemanagement

XVI

Autorenverzeichnis

2.4

Bienzeisler, Bernd

Dipl.Soz.Wiss.

Kremer, David

Dipl.-Psych.

Spath

Prof. Dr.-Ing.

Becker, Ralf Graf, Heiko

Dipl.-Ing.(FH) Master of Design Dipl.-Ing.

Grzesiak, Andrzej

Dipl.-Ing.

Henning, Axel

Dipl.-Ing.

Kempf, Michael

Dipl.-Math.

Bertsche, Bernd Graf, Heiko

Univ.-Prof. Dr.-Ing. Dipl.-Ing.

Wacker, Michael

Dipl.-Ing.

Becker, Ralf Grzesiak, Andrzej

Dipl.-Ing.(FH) Master of Design Dipl.-Ing.

Henning, Axel

Dipl.-Ing.

Kempf, Michael

Dipl.-Math.

Westkämper, Engelbert

Univ.-Prof. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult.

Boomers, Achim

Dr.

3, 3.1

3.2

3.3

3.4

Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Industrielle Fertigung und Fabrikbetrieb (IFF) Institut für Maschinenelemente (IMA) Institut für Industrielle Fertigung und Fabrikbetrieb (IFF) Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA) Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA) Institut für Maschinenelemente (IMA) Institut für Maschinenelemente (IMA) Institut für Maschinenelemente (IMA) Institut für Industrielle Fertigung und Fabrikbetrieb (IFF) Institut für Industrielle Fertigung und Fabrikbetrieb (IFF) Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA) Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA) Institut für Industrielle Fertigung und Fabrikbetrieb (IFF)

Ehem. Betriebswirtschaftliches Institut (BWI)

Autorenverzeichnis

4

4.1

4.2

Cassack, Ingo

Dr.

Horváth, Peter

Univ. Prof. Dr. Dr. h.c. mult.

Diederich, Michael K.

Dipl.-Inform.

Warschat, Joachim


Mesina, Marian

Dr.-Ing.

Roller, Dieter

Univ.-Prof. Hon.-Prof. Dr.

Dalakakis, Stavros

Dipl.-Ing.

Diederich, Michael K.

Dipl.-Inform.

Roller, Dieter

Univ.-Prof. Hon.-Prof. Dr. Prof. Dr.-Ing. habil.

Warschat, Joachim

4.3

4.4

Tippmann, Volker Warschat, Joachim


Aslanidis, Stephanie

Dipl.-Math.

Warschat, Joachim


Weisbecker, Anette

Priv.-Doz. Dr.Ing. habil.

XVII

Ehem. Betriebswirtschaftliches Institut (BWI) Ehem. Betriebswirtschaftliches Institut (BWI) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Ehem. Institut für Rechnergestützte Ingenieursysteme (IRIS) Institut für Rechnergestützte Ingenieursysteme (IRIS) Ehem. Institut für Rechnergestützte Ingenieursysteme (IRIS) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Rechnergestützte Ingenieursysteme (IRIS) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Ehem. Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Fraunhofer Institut für Arbeitswirtschaft und Organisation (IAO)

XVIII

Autorenverzeichnis

5 5.1

Haselberger, Frank

Dipl.-Ing.

Kopecki, Andreas

Dipl.-Inf.

Resch, Michael

Prof. Dr.-Ing.

Runde, Christoph

Dipl.-Ing.

Runde, Christoph

Dipl.-Ing.



Bues, Matthias

Dipl.-Ing.

Haselberger, Frank

Dipl.-Ing.

Kern, Peter

Prof. Dr.-Ing.

Bues, Matthias

Dipl.-Ing.

Kern, Peter

Prof. Dr.-Ing.

Kopecki, Andreas

Dipl.-Inf.

Resch, Michael

Prof. Dr.-Ing.

Kopecki, Andreas

Dipl.-Inf.

Resch, Michael

Prof. Dr.-Ing.

5.2

5.3

5.4

5.5

Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Höchstleistungsrechenzentrum (HLRS) Höchstleistungsrechenzentrum (HLRS) Institut für Industrielle Fertigung und Fabrikbetrieb (IFF) Institut für Industrielle Fertigung und Fabrikbetrieb (IFF) Institut für Industrielle Fertigung und Fabrikbetrieb (IFF)

Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Institut für Arbeitswissenschaft und Technologiemanagement (IAT) Höchstleistungsrechenzentrum (HLRS) Höchstleistungsrechenzentrum (HLRS) Höchstleistungsrechenzentrum (HLRS) Höchstleistungsrechenzentrum (HLRS)

Autorenverzeichnis 5.6

5.7

5.8

5.9

5.10

5.11

Roth-Koch, Sabine

Dr.-Ing. Dipl.-Math.



Biesinger, Bernd

Dipl.-Ing.



Bohnet, Jens

Dipl.-Ing.



Dausinger, Friedrich

Prof. Dr. habil.

Sigel, Julian

Dr.-Ing.

Walter, Jens

Dipl.-Phys.

Eyerer, Peter

Prof. Dr.-Ing.

Kroh, Michael

Dipl.-Ing.

Woicke, Nina

Dr.-Ing.

Vorobyov, Kyrylo Wagner

Dipl.-Ing. Dr.-Ing.

XIX

Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA) Institut für Industrielle Fertigung und Fabrikbetrieb (IFF)

Institut für Industrielle Fertigung und Fabrikbetrieb (IFF) Institut für Industrielle Fertigung und Fabrikbetrieb (IFF)

Institut für Industrielle Fertigung und Fabrikbetrieb (IFF) Institut für Industrielle Fertigung und Fabrikbetrieb (IFF)

Institut für Strahlwerkzeuge (IFSW) Ehem. Institut für Strahlwerkzeuge (IFSW) Institut für Strahlwerkzeuge (IFSW) Institut für Kunststoffprüfung und Kunststoffkunde (IKP) Institut für Kunststoffprüfung und Kunststoffkunde (IKP) Ehem. Institut für Kunststoffprüfung und Kunststoffkunde (IKP) Institut für Umformtechnik (IFU) Institut für Umformtechnik (IFU)

1 Einleitung

1.1 Übersicht über den Sonderforschungsbereich 374 1.1.1 Ziele Seit einigen Jahren sind die Märkte von mehreren Faktoren geprägt: Die Kundenwünsche werden differenzierter, die Konkurrenz internationaler und die Produktentwicklungszeiten kürzer. Diese Umfeldfaktoren waren ein Treiber für die Gründung des Sonderforschungsbereichs. Bis heute hat sich die Situation weiter verschärft. Wenn ein Unternehmen im Wettbewerb bestehen will, muss es sich von anderen Unternehmen abheben. Dies geschieht in der Regel durch einen Qualitäts-, Preis- oder Zeitvorteil gegenüber der Konkurrenz. Es müssen also differenzierte Kundenwünsche möglichst schnell in geforderter Qualität befriedigt werden können. Laut der BMBF-Studie „Zur technologischen Leistungsfähigkeit Deutschlands 2006“ (Legler, H.; Gehrke, B.; BMBF, 2006) liegt Deutschland im Bereich der Spitzentechnologie im Vergleich zu anderen Industrieländern auf einem Mittelfeldplatz. Spitzentechnologien erfordern Innovationen. Innovationen benötigen Methoden und Werkzeuge, welche die gerade bei Spitzentechnologien inhärente hohe Dynamik des Innovationsprozesses bewältigen können. Hier setzt das in diesem Buch beschriebene Konzept des Rapid Product Development an. Iterativ einsetzbaren Instrumenten wurden entwickelt. Diese können kurzfristig an ein verändertes Unternehmensumfeld anpassen können. Dabei können kontinuierlich die Anspruchsgruppen des Unternehmens, wie beispielsweise Kunden integriert werden. Dadurch wird der Innovationsprozess beschleunigt und die Innovationsfähigkeit erhöht. Die in der Produktentwicklung durch die Umfeldbedingungen entstehenden Probleme lassen sich in vier Bereiche einordnen: Kosten-, Zeit und Qualitätsmanagement, Arbeitswissenschaftliche Grundlagen, IT-Unterstützung sowie Prototypenerstellung, wie in Abb. 1.1 dargestellt wird.

2

1 Einleitung Arbeitsw issenschaftliche Grundlagen Prototypenerstellung

Produktentw icklung

Kosten-, Zeit und Qualitätsmanagement

IT-Unterstützung

Abb. 1.1. Problembereiche des Produktentwicklungsprozesses

1.1.2 Überblick Grundlagen des Rapid Product Development Die Forderungen nach kürzeren Entwicklungszeiten, höherer Produktqualität und schnellerer Reaktionsgeschwindigkeit auf Kundenwünsche bei gleichzeitig immer geringeren Budgets und steigender Produktkomplexität haben die Produktentwicklung zu einem entscheidenden Faktor für den Unternehmenserfolg gemacht und zwingen zu neuen Ansätzen und Lösungen. Besonders zu Beginn einer Entwicklung neuer und innovativer Produkte sind sichere Aussagen bezogen auf die Qualität, die Kosten und die Entwicklungszeit eines Produkts schwer oder gar nicht zu treffen. Bedingt ist dies durch die hohe Komplexität in der Entwicklung und Erprobung innovativer Produkte. Daher hatte der Sonderforschungsbereich (Sfb) 374 „Entwicklung und Erprobung innovativer Produkte - Rapid Prototyping“ als Ziel - unter Einbeziehung eines evolutionär iterativen Ansatzes - Methoden zu erarbeiten, mit deren Hilfe aus den zur Verfügung stehenden Daten während des Entwicklungsfortschrittes schneller gesicherte Aussagen zu treffen sind. Deshalb steht eine frühe Verfügbarkeit der Daten hinsichtlich der Kriterien Kosten, Zeit und Qualität im Betrachtungsmittelpunkt. Im Rahmen der Arbeiten im Sfb 374 hat sich gezeigt, dass neben der technischen Verfügbarkeit von Daten und Informationen, insbesondere auch die Zusammenarbeit zwischen den Beteiligten gestärkt werden muss. Das zukünftige Vorgehen im Rahmen einer innovativen Produktentwicklung muss daher sowohl die Zusammenarbeit der verteilt arbeitenden Experten, als auch die unterstützenden Technologien berücksichtigen. Um die Komplexität der Produkte, der Verfahren und der zur Verfügung stehenden Beziehungen zwischen den unterschiedlichen Daten und Informationen zu verringern, sind Technologien notwendig, die diese Abhängigkeiten handhabbar machen kön-

1.1 Übersicht über den Sonderforschungsbereich 374

3

nen. Die Themenstellungen im Sonderforschungsbereich waren deshalb die Herstellung virtueller und physischer Prototypen, die Vernetzung des Wissens in der Konstruktion, die integrative Betrachtung der Zeit-, Kosten- und Qualitätsanforderungen, die arbeitswissenschaftliche Betrachtung der verteilten und multidisziplinär arbeitenden Teams sowie die Entwicklung unterstützender Medien im Rahmen der Informations- und Kommunikationstechnologie. Zur Lösung der beschriebenen Probleme bei der Entwicklung und Erprobung innovativer Produkte wurde im Sonderforschungsbereich die Methode des Rapid Product Development (RPD) erarbeitet. Eigenschaften dieses Konzepts evolutionärer, iterativer Produktentwicklung sind die gezielte Nutzung schneller Iterationszyklen, die situationsgerechte Verwendung von Prototypen sowie die dezentrale Struktur selbstorganisierter, vernetzter Teams. Der evolutionäre Charakter zeigt sich an dem gewollten Wettstreit verschiedener Lösungsalternativen, deren Kombination und Weiterentwicklung sowie deren Anpassung an sich ändernde Marktbedingungen. Hierzu müssen frühzeitig Erkenntnisfortschritt und Wissenszuwachs unterstützt sowie Fehlentwicklungen vermieden werden (s. Abb. 1.2.).

Abb. 1.2. Konzept des Rapid Product Development

Die Entwicklung einer integrativen Softwareplattform wurde genau so intensiv durchgeführt wie die Entwicklung in den Bereichen des Rapid Prototyping: physisches, virtuelles sowie hybrides Prototyping. Abgerundet wurde dies durch die Diskussion mit Praktikern, insbesondere mit dem

4

1 Einleitung

Projektpartner DaimlerChrysler, durch die Anregungen für die Forschung eingebracht werden können. Virtuelle, physische und hybride Prototypen Ein Schwerpunkt der Arbeiten im Sfb ist die Erstellung virtueller, physischer und hybrider Prototypen. Auf diesen Themenbereich konzentrieren sich die Arbeiten im Teilbereich D (s. Abb. 1.4.) des Sfb. Die zunehmende Komplexität von Produkten, gestiegene Qualitätsanforderungen sowie kürzere Entwicklungszeiten erfordern schon in frühen Phasen der Produktentwicklung einen umfassend bewertbaren Prototypen. Virtuelle Prototypen sind Bauteile, die nur im Computer existieren, an denen jedoch Simulationen und Berechnungen durchgeführt werden können. In Zukunft werden Kombinationen aus virtuellen und physischen Prototypen, die sogenannten Hybride, immer interessanter mit denen eventuelle Modifikationen bereits bestehender Bauteile durch Überlagerung verglichen und bewertet werden können. Für die physische Generierung der im Computer modellierten virtuellen Komponenten werden Verfahren des Rapid Prototyping eingesetzt. Mit diesen beiden Entwicklungsprozessen lassen sich schon frühzeitig detaillierte Eigenschaften über das spätere Produkt ermitteln. Die Einbindung der Rapid-Prototyping-Technologie in die Entwurfsund Konzeptionsphasen der Produktentwicklung wird bisher in der Industrie nur in geringem Umfang realisiert. Zwar finden sich Ansätze (schnelle Verifikation von Entwürfen in Concept Modelling Systemen), diese sind jedoch nicht durchgängig methodisch ausgeprägt. Bisher erfolgt die Erstellung von Design-Formmodellen aus Materialien wie Clay oder Schaumstoff größtenteils per Hand. Das Ziel war jedoch Verfahren zur Verfügung zu stellen, die eine automatisierte Erzeugung konzeptioneller Prototypen gestatten. Dazu ist es notwendig, Konzepte und Entwürfe, die mit konventionellen Designmitteln, wie Skizzen oder handgefertigten Formmodellen, entwickelt wurden, in virtuelle Modelle zu überführen und in den Rapid Product Development-Prozess zu integrieren. Dem Designer bleibt die Gestaltungsfreiheit am physischen Modell erhalten, während ihm gleichzeitig virtuelle Werkzeuge zur Verifizierung und Präsentation seiner Konzepte in die Hand gegeben werden. Kosten-, Zeit und Qualitätsmanagement Die Wettbewerbsposition eines Unternehmens wird entscheidend von der Fähigkeit bestimmt, eine Leistung am Markt anbieten zu können, die für den Kunden das Optimum aus kostenmäßigen, zeitlichen und qualitativen


5

Eigenschaften darstellt. In der Produktentwicklung müssen zur drastischen Reduzierung von später auftretenden Änderungskosten sowie der Vermeidung von verspäteten Produktstarts bereits in den frühen Phasen der Konstruktion Zuverlässigkeitsbetrachtungen und Kostenanalysen durchgeführt, eine flexible Planung implementiert sowie Qualitätsaussagen getroffen werden. Deshalb wurde ein Referenzmodell des Qualitätsmanagements in Entwicklungsnetzwerken des RPD erstellt, das alle qualitätsrelevanten Bausteine für Entwicklungsnetzwerke wie Kommunikation, Datenmodellierung, Produkt- und Prozessqualitätsmanagement usw. integriert. Durch ihre Kombination können sowohl bekannte, als auch neue Qualitätsmanagement- Methoden mit integrierter Funktionalität entstehen. Zudem sind schon in den frühen Phasen der Produktentwicklung Planungsmethoden und -instrumente notwendig, die eine enge Zusammenarbeit multidisziplinärer Experten-Teams innerhalb des RPD hinsichtlich des Projektmanagements unterstützen. Sie müssen in der Lage sein, die sich in den Iterationszyklen dynamisch verändernden Strukturen bei der Planung zu berücksichtigen. Es wurde deshalb ein Planungssystem entwickelt, das ein problemorientiertes Management von Kompetenzen und darauf aufbauend die Implementierung von dynamischen Abstimmungsmechanismen zur Beschleunigung von Planungsentscheidungen unterstützt. Aufgrund des steigenden Kostendrucks müssen schon in der Konstruktion die Weichen für eine effiziente Entwicklung innovativer und trotzdem möglichst ausgereifter und marktoptimierter Produkte gestellt werden. Es wurde daher der Prototyp eines Konstruktionssystems entwickelt, der den Aufbau eines Aktiven Semantischen Konstruktionsnetzes (ASK) beinhaltet. Das ASK beinhaltet auch Funktionalitäten, die eine noch effizientere sowie kosten- und zuverlässigkeitsoptimierte Konstruktion unterstützen, sowie eine phasenunabhängige Modellierung des Konstruktionsproblems ermöglichen. Dadurch wird eine optimierte Kooperation und Kommunikation multidisziplinärer Entwicklungsteams ermöglicht, in dem das ASK u.a. als Basis zur Integration von Zeit, Kosten und Qualität dient. Arbeitswissenschaftliche Grundlagen Durch die Zusammenführung von Expertenwissen aus unterschiedlichen Bereichen in kooperativen Teams verspricht man sich synergetische Effekte sowie die Nutzung und Verstärkung der kreativen Potenziale der Teammitglieder; durch das iterative Vorgehen kann auf das Produkt im Vergleich zu einem sequenziellen Vorgehen wesentlich länger Einfluss genommen werden. Die Schwerpunkte der Untersuchungen im Bereich A

6

1 Einleitung

(s. Abb. 1.4.) in der vierten Förderperiode lagen abschließend in der Entwicklung von Gestaltungsempfehlungen und Instrumenten für die Unterstützung interdisziplinärer, kooperativer Arbeiten in RPD-Teams. Integrierte Softwareplattform Die Forschungsaktivitäten des Sfb 374 konzentrierten sich auch auf die Entwicklung von Methoden und Werkzeugen zur Verkürzung der Iterationszyklen in der Produktentwicklung. Mit dem Aktiven Semantischen Netz (ASN), wird innerhalb des RPD die zentrale softwaretechnische Integrationskomponente zur Verfügung gestellt. Es wurde eine Integrationsplattform als Bindeglied zwischen ASN und Anwender auf der Basis eines Multiagentensystems entwickelt und prototypisch realisiert. Ziel der Integrationsplattform war die Bereitstellung von Middleware-Funktionalitäten, die zum einen den Zugriff auf das Aktive Semantische Netz (ASN) auf einer höheren Abstraktionsebene ermöglichen, und zum anderen plattformunabhängige Koordinationsmöglichkeiten für die RPD-Anwendungen bieten. Es wurden die Aspekte einer technisch unterstützten Kooperation zwischen Teammitgliedern in Entwicklungsprozessen und deren Anwendbarkeit auf das RPD näher untersucht. Die Untersuchungen im Sonderforschungsbereich haben gezeigt, dass Kommunikation, Koordination und Wissensintegration entscheidende Faktoren für die effiziente Zusammenarbeit in multidisziplinären Teams sind. Der intensive Austausch von Wissen muss auf Strukturen basieren, die einer direkten (d.h. nicht durch ein Medium gefilterten) Kommunikation nahe kommen, um die durch die Dezentralisierung der Teams gesetzten räumlichen und zeitlichen Barrieren zu minimieren. Ein Prototyp für ein integriertes Kommunikationssystem für vernetztes Arbeiten mit den Schwerpunkten multidisziplinäre Teamkommunikation und die Team-Team-Zusammenarbeit wurde realisiert. 1.1.3 Prototypen im RPD Einsatz virtueller Prototypen Der Einsatz der Virtuellen Realität (VR) als Werkzeug zur Gestaltung, Evaluierung und Unterstützung der Kooperation im Entwicklungsprozess war ein Schwerpunkt im Sfb 374. Im Rahmen der Darstellung von Prototypen schafft VR neue Möglichkeiten.


7

Im Vordergrund stehen dabei formale Aspekte, Funktionalität, Montagemöglichkeiten, Fertigungsaspekte, Sicherheitsfragen oder physikalischtechnische Vorgänge. Ein Bereich ist die Erforschung der Wahrnehmung der Anwender in unterschiedlichen virtuellen Umgebungen (z.B. Mehrwandprojektions-Systeme) in Verbindung mit verschiedenen Interaktionskonzepten zur Gestaltung, Simulation, Montage/Demontage und Überprüfung von Fertigungsaspekten. Für die Entwicklung wird dazu das fast vollständige Spektrum heute erhältlicher VR-Ein- und Ausgabesysteme genutzt. Ein Forschungsschwerpunkt lag in der Untersuchung von Integrationsformen unterschiedlicher Aufgabenstellungen in virtuellen Umgebungen. Die relevanten VR-Werkzeuge wurden in eine gemeinsame Benutzungsumgebung integriert, was die Produktentwicklung von der Idee bis zur Erstellung des Prototyps unterstützt. Durch die fortschreitende Arbeitsteilung bei der Entwicklung von Produkten ergibt sich weiterhin ein wachsender Bedarf an Kooperationen, beispielsweise von Berechnungsingenieuren, die an verschiedenen Standorten arbeiten. Durch die Verfügbarkeit von Hochgeschwindigkeitsnetzen haben sich klassische CSCW- Werkzeuge (computer supported cooperative work), wie Video-Konferenzsysteme, shared Notepads oder E-Mails als Alltagswerkzeuge etabliert. Somit stellen kooperative virtuelle Umgebungen eine konsequente Weiterentwicklung in diese Richtung dar und eröffnen ein bisher nicht erreichtes Potential bei der Zusammenarbeit von dezentralen Entwicklungsteams. Um jedoch eine effiziente Zusammenarbeit in einer kooperativen Sitzung gewährleisten zu können, mussten neue Interaktions- und Kooperationsmethoden entwickelt werden, die ein gemeinsames Navigieren und Interagieren erlauben und dabei den Anwender nicht wie bei einer Master/SlaveSynchronisation einschränken, d.h. ein spontanes Arbeiten behindern. Um die Effizienz bei der Auswertung beispielsweise von Berechnungsergebnissen mit Hilfe von VR-Technologien zu steigern, mussten für die fachspezifischen Anforderungen an die eingesetzte Hardware angepasste Interaktionsmethoden entwickelt werden. Sie sind intuitiv zu bedienen und ermöglichen eine präzise Interaktion mit dem virtuellen Prototyp. Durch Einsatz von haptischen Eingabegeräten wird dabei der Tastsinn des Benutzers mit ausgenutzt. Die derzeit masselose Welt der virtuellen Prototypen wird dadurch realistischer und einfacher zu bedienen. Dem Benutzer wird ein realistischerer Eindruck der manuellen Tätigkeit vermittelt, wenn er Gegenstände anfassen und spüren kann. Für diese Umsetzung mussten Schwerpunkte vertieft werden wie die Untersuchung von Maßnahmen, um immersive, virtuelle Umgebungen aus den Laborbedingungen in ergonomische Industriearbeitsplätze zu überführen. Des Weiteren mussten 3D-Formen und –objekte in immersiver und

8

1 Einleitung

virtueller Umgebung generiert und modifiziert werden. Als letzter Schwerpunkt wurde die manuelle Montage/Demontagetätigkeit in virtuellen Prototypen vertieft, die durch den Einsatz von haptischen Wahrnehmungen durch Weiter- und Neuentwicklungen bestehender Haptikhardware verbessert wurde. Vor allem für die multidisziplinäre Zusammenarbeit in virtuellen Umgebungen wurden neue Konzepte benötigt, die es ermöglichen, Daten der unterschiedlichsten Bereiche direkt am virtuellen Prototypen einblenden zu können. So genannte Metadaten und ihre Zusammenhänge aus den Bereichen der Produkt-, Zeit- und Kostenplanung sowie des Qualitätsmanagements sollen für Besprechungen und Präsentationen den Anwendern in der virtuellen Umgebung zugänglich gemacht werden. Zudem können Prototypen nicht nur aus virtuellen sondern auch in Verknüpfung mit physischen Teilprototypen bestehen. Mit dem so genannten hybriden Prototypen ist es nun möglich, die Vorteile beider Bereiche miteinander zu verbinden. Hybride Prototypen werden dazu verwendet, physikalische Effekte an realen Prototypen darzustellen und kontextbezogen auszuwerten. Konstruktionsvarianten können durch Überlagerung der Modifikationen über die vorliegende Ausgangsversion des Prototyps dargestellt und miteinander verglichen werden. In Zukunft soll es möglich sein, reale Bauteile ohne das Anbringen von Markern mit virtuellen Darstellungen zu überlagern. Verfahren und Prozesse im RPD für die Erstellung von Prototypen Im RPD werden (im Sinn von CAD-Modellen) unvollständig ausgelegte Designmodelle zu rapid-prototyping-fähigen Modellen entwickelt. Zur maschinengestützten Herstellung dieser Modelle wurde u.a. das „Multi Material Modelling“ eingesetzt, das in Verbindung mit der Folgetechnologie „Metallische Beschichtung von generativ gefertigten Prototypen“, die Verarbeitung unterschiedlicher Materialien ermöglichte. Somit konnte z.B. in einer Mehrkomponentenbauweise, bei der innerhalb eines Bauteils mehrere Werkstoffe zum Einsatz kommen, die partielle Beschichtung ohne vorherige Maskierung genauer untersucht werden. Ein Bedarf an Multi Material Prototypen besteht in sämtlichen Bereichen, in denen Prototypen eingesetzt werden, z. B. zu Funktions-, Designoder Ergonomieuntersuchungen. Während der ersten Förderperioden wurde ausgehend von verschiedenen Basiskomponenten ein modulares Rapid-Prototyping-System aufgebaut. Dabei wurde von dem Verfahren des Lasergenerierens ausgegangen, bei dem schichtweise dreidimensionale Geometrien aufgebaut werden. In-


9

dem die dafür benötigten Module, wie Pulverförderer, Laser und Bearbeitungszentrum, möglichst autark gehalten werden, kann nicht nur in Bezug auf das Lasergenerieren ein hoher Grad an Flexibilität erreicht werden, sondern es ist möglich, auch andere Laserprozesse, wie Abtragen oder auch spanende Prozesse, in den Rapid Prototyping Prozess einzubeziehen. Die Weiterentwicklung dieser Idee führt zum „Modularen System“. Dabei wird je nach Anwendungsfall ein Grundmodul „Werkzeugmaschine“ mit weiteren Hardware- oder auch Wissensmodulen kombiniert. Hardwaremodule bezeichnen technisches Equipment, wie Laser und Optik, Wissensmodule hingegen bezeichnen das Wissen, bestimmte Werkstoffe oder Prozesse einsetzen zu können. Herstellung physischer Prototypen Um schnelle und zuverlässige Aussagen zu den einzelnen Eigenschaften und Produktaspekten zu erzielen, werden Technologien und Prozessketten benötigt, welche die zu untersuchenden Eigenschaften des Endprodukts möglichst schnell und genau abbilden. Dieser Ansatz wird im Rapid Prototyping verfolgt. Diese Technologien und Prozessketten sollten sich so ergänzen, dass in Kombination mit den verfügbaren, generativen Fertigungsverfahren Werkzeuge zur effizienten Herstellung eines breiten Spektrums der Prototypablauffolge bereitgestellt werden können. Das Produkt dieser neuen Technologien sind die physischen Prototypen mit funktionellen Eigenschaften. Diese müssen in verschiedenen Stoffen herstellbar sein, um einer optimalen Abbildung der Eigenschaften des Endprodukts möglichst nahe zu kommen. Die am besten geeigneten Technologien und Prozesse unter den Kriterien Qualität, Kosten und Zeit sind zu ermitteln. Die Zielsetzung des Rapid-Prototyping-Labors zur Herstellung funktionaler und technischer Prototypen mittels Lasertechniken ist die Entwicklung von Verfahren zur schnellen Prototypherstellung. Der Laser bietet sich aufgrund seiner räumlichen und zeitlichen Steuerbarkeit als ideales Werkzeug für den Formgebungsprozess an. Die Lasersinter-Technologie bietet zudem den Vorteil einer breiteren Werkstoffpalette, womit Prototypen mit seriennahem Eigenschaftsprofil realisiert werden können. Sollen Materialien mit bestimmtem Eigenschaftsprofil im Lasersintern eingesetzt werden, müssen sowohl das Verfahren, insbesondere die Temperaturführung und das Beschichtungssystem, als auch der Werkstoff aneinander angepasst werden. Für Bauteile mit guter Oberfläche muss der Werkstoff als Pulver mit geeigneter Kornform und -größe vorliegen. Im Bereich der Materialuntersuchung und -entwicklung für das Rapid Prototyping fokussierten sich die Arbeiten des Sfb 374 in den letzten För-

10

1 Einleitung

derperioden auf thermoplastische Pulvermaterialien für die Anwendung im Feinguss, auf elastische Pulvermaterialien und auf Bindersysteme für die Verarbeitung keramischer Pulver. Neben den Untersuchungen an wärmeformbeständigen Thermoplasten bildete die Entwicklung des (LS)2IVerfahrens (Liquid Silicon Infiltration of Lasersintered C-SiC Preforms) zur Herstellung endkonturnaher SiSiC-Keramikprototypen den zweiten Hauptarbeitsbereich. Da die Verarbeitung von Werkstoffen mit unterschiedlichen Eigenschaftsprofilen in einem Bauteil mit den verfügbaren RP-Technologien nur eingeschränkt möglich war/ist, wurde die Verknüpfung unterschiedlicher Verfahren untersucht. Das Ziel war die Adaption mehrfacher komplexer Funktionalitäten und Eigenschaften vergleichbarer Bauteile. Untersuchungen der Werkstoffverträglichkeiten bei unterschiedlichen Verfahrenskombinationen standen im Vordergrund. Prototypische Werkzeugverfahren wurden, falls aus verfahrens- oder werkstofftechnischen Gründen erforderlich, mit in die Untersuchungen einbezogen. Neben der Herstellung der Prototypen, ist besonders im Bereich der Umformtechnik die Werkzeugherstellung von besonderer Bedeutung. Hiermit kann die Überprüfung der Serientauglichkeit des Herstellungsverfahrens durchgeführt werden und es können Prototypbauteile mit Eigenschaften, die denen des Serienbauteils entsprechen, gefertigt werden. Weitere Schwerpunkte sind die Entwicklung eines Expertensystems und der Einsatz der VR-Technologie bei der Werkzeugentwicklung. Durch die Verknüpfung von Konstruktion und FEM-Prozess-Simulation in einer virtuellen Arbeitsumgebung wird der Bauteil- und der Werkzeugentwicklungsprozess beschleunigt. Die VR Technologie ermöglicht durch die dreidimensionale Projektion eine wesentlich anschaulichere Darstellung von Konstruktions- und Simulationsdaten. Zusammenfassend sieht man, dass die für das Rapid Product Development wichtigen Bereiche des Rapid Prototyping in das Gesamtkonzept des Rapid Product Development integriert werden. Dem Ingenieur wird eine breite Palette an unterschiedlichen Methoden zur frühen Überprüfung und Gestaltung der Konstruktion mittels virtueller, physischer und hybrider Prototypen an die Hand gegeben. Für diese Problemstellungen wurden innerhalb des Sfb 374 Methoden, Konzepte und erste prototypische Lösungen entwickelt.


11

1.1.4 IT Unterstützung im RPD Vernetztes Wissen in der Konstruktion Um vernetztes Denken und Handeln in der Konstruktion zu ermöglichen, wurde der Prototyp eines Konstruktionssystems entwickelt, der den Aufbau eines aktiven semantischen Konstruktionsnetzes (ASK) unterstützt. Das Konstruktionsnetz besteht aus Objekten (Anforderungen, Funktionen, Bauteile) und Beziehungen verschiedenen Typs. Durch die Verwendung von Constraints und Intervallen zur Auslegung ist der Aufbau eines durchgängigen Berechnungsmodells während des Konstruktionsprozesses möglich. Besonders in den Konzept- und Entwurfsphasen der Produktentwicklung sind viele kreative Leistungen erforderlich. Daher wird eine kontextsensitive Unterstützung für die Anwendung von Kreativitätstechniken zur Verfügung stehen. Hierbei wird zunächst untersucht, welche Kreativitätstechniken in den unterschiedlichen Phasen des computerunterstützten Konstruktionsprozesses geeignet sind und welche sich sinnvoll bei verteilt arbeitenden Konstrukteuren einsetzen lassen. Dadurch können Anforderungen und Erfahrungswissen direkt berücksichtigt werden. Aus den semantischen Beziehungen zwischen den Bauteilen des Konstruktionsnetzes lassen sich das Berechnungsmodell und die topologische Anordnung der Bauteile ableiten. Zur Beherrschung des komplexen Auslegungsmodells über die Bauteile der Konstruktionsnetze hinweg wurde der Prototyp um weitere Strukturierungsmöglichkeiten erweitert. Zur Wiederverwendung entwickelter Bauteile ist eine Suchmöglichkeit auf Basis der Intervalle und Constraints entwickelt worden. Damit Konstruktionen bereits ab einem frühen Zeitpunkt im Team kontrolliert entwickelt werden können, wurden Konzepte zur Segmentierung des Konstruktions- und Berechnungsmodells mittels einer Client-/Server-Struktur und der dazugehörigen Koordinierungsmechanismen realisiert. Einige Produkte können aus zeitlichen Gründen nicht mehr von Grund auf neu entwickelt werden, sondern sollten möglichst viele bestehende Teile oder Varianten bestehender Teile verwenden. Daher wird eine Möglichkeit zur Generierung von Baureihen entwickelt, die besonders die Ähnlichkeits- und dezimalgeometrischen Normzahlgesetze beachtet. Die Auslegungsrechnung und das Bauteilsuchsystem müssen diesen geänderten Anforderungen angepasst werden. Obwohl die Zuverlässigkeit technischer Produkte heutzutage eine zunehmende Rolle spielt, werden Zuverlässigkeitsbetrachtungen meistens erst in späten Phasen der Produktentwicklung durchgeführt, was die Änderungsbzw. Reparaturkosten um Größenordnungen erhöht. Mit dem "Zuverlässigkeits-Informationsnetz", soll das ASK zukünftig um eine Sicht erweitert

12

1 Einleitung

werden, die es dem Konstrukteur ermöglicht, in seiner gewohnten Umgebung die Zuverlässigkeit der Bauteile und -gruppen in jeder Phase zu betrachten und zu berücksichtigen. Neben der Zuverlässigkeit werden auch die Qualitätsmanagementmethoden betrachtet, die auf einzelne wertschöpfende Prozesse und Prozessabfolgen (lokal) anwendbar sind. Dabei werden Verfahren zur Verfügung gestellt, die den Anwender während eines Produktentwicklungsprojektes bei der kontextsensitiven Auswahl und Parametrisierung von Methoden unterstützen. Der gesamte Produktentstehungsprozess, also von der reinen Entwicklungsphase mit der Definition der Rahmenbedingungen und der Aufgabenstellung, bis hin zur Auswahl von Fertigungsverfahren zur Erstellung der Prototypen haben einen entscheidenden Einfluss auf die zu bevorzugende Methode bzw. deren exakte Ausgestaltung. Diese Methodenbausteine mit ihren spezifischen Parametern haben definierte Schnittstellen und werden flexibel kombinierbar gestaltet. Durch die Anpassung der Methodenparameter werden die Methodenbausteine auf die durchzuführende Aufgabenstellung optimal ausgerichtet. In einzelnen Elementen des Entwicklungsnetzwerkes können verschiedene Bausteine angewandt werden, die anschließend zu einem Gesamtmethodenkonzept kombiniert werden. Für die qualitative Absicherung der Prozessschritte in der Konzeptphase werden spezielle Qualitätsmerkmale abstrahiert, die die Besonderheiten von Entwurfsmodellen und konzeptionellen Prototypen berücksichtigen. Als Grundlage werden Rapid-Prototyping-fähige virtuelle Entwurfsmodelle betrachtet, die bereits qualitative Aussagen bezüglich des Entwurfes und Produktkonzeptes beinhalten (z.B. Ergonomie). Diese Aussagen sind aber bislang nicht formalisiert und können so nicht mit den Qualitätsmerkmalen der späteren CAD-Konstruktion in Bezug gesetzt werden. Zur Formalisierung qualitätsrelevanter Produkteigenschaften werden deshalb die zu erwartenden geometrischen, physikalischen oder funktionalen Eigenschaften am hybriden Prototypen simuliert. Die Arbeiten zum Referenzmodell des Qualitätsmanagements in Entwicklungsnetzwerken werden in die Arbeiten zu der mehrdimensionalen Bewertung von Produkt- und Projektalternativen eingebracht. Die Arbeiten zur Berücksichtigung netzwerkartiger Strukturen und die Einbeziehung industrieller, auch externer, Dienstleistungen in den Produktentwicklungsprozess wurden in das Referenzmodell integriert. Durch die konsequente Rechnerunterstützung bei der Akquisition und Speicherung von Wissen, dem Informationstransport sowie dem Einsatz von Methoden zur Entscheidungsunterstützung wird der Informationsfluss wesentlich beschleunigt und der Wissenstransfer über verschiedene Entwicklungsbereiche hinweg möglich. Nicht nur die Qualität und die Entwicklungszeit, sondern auch die Strategie hinsichtlich der Produktkosten spielt eine wesentliche Rolle und macht


13

die Entwicklung eines marktorientierten Kostengestaltungsmodells notwendig. Im Rahmen des Rapid Product Development ermöglicht dieses Instrumentarium prototypgestützte Produktkostenvorgaben und -prognosen über den gesamten Lebenszyklus eines Produktes. Mit der Entwicklung dieses Modells ist man soweit fortgeschritten, dass nun neben dem physischen Produkt auch produktbegleitende Dienstleistungen einbezogen werden. Das physische Produkt bildet mit der Dienstleistung als Leistungsbündel eine individuelle, nicht trennbare Problemlösung, deren Kosten es frühzeitig zielorientiert zu gestalten gilt. Darüber hinaus bieten Entwicklungsnetzwerke den beteiligten Unternehmen die Möglichkeit, das Entwicklungsrisiko und den hohen Kapitalbedarf aufzuteilen und die unterschiedlichen Fähigkeiten und Kernkompetenzen zu bündeln. Wenn sich ein allgemeiner Standard bei einem Produkt herausgebildet hat, bieten Dienstleistungen oftmals die einzige Möglichkeit einer eigenständigen Profilierung gegenüber der Konkurrenz. Produktbegleitende Dienstleistungen werden von den Unternehmen in einem immer stärkeren Maße als zusätzliche Erlösquellen benutzt, verursachen andererseits aber auch Kosten. Prototypen übernehmen dabei die Aufgabe, Kostenvorgaben und prognosen für produktnahe Dienstleistungen wie Wartung, Instandhaltung oder Schulung ableiten zu können. Daher wird eine Systematisierung der Bestandteile von Leistungsbündeln entwickelt. Darauf aufbauend ergeben sich spezifische Merkmale, die Aufschluss über die Art und Intensität der Verbindung von Dienstleistung und physischem Produkt ermöglichen, um dadurch Hinweise auf eine mögliche Entbündelung zu erhalten. Wichtig ist weiterhin eine eingehende Typologisierung und nähere Beschreibung von Kosteneffekten in Entwicklungsnetzwerken. Zunächst werden wesentliche Charakteristika von Entwicklungsnetzwerken im allgemeinen und Netzwerkkooperationen mit Prototypen im speziellen in Form eines Prozessmodells erarbeitet. Hinsichtlich eines pragmatischen Vorgehens kann die Differenzierung von Entwicklungsnetzwerken insbesondere aus organisatorischer, markt- und ressourcenorientierter Perspektive vorgenommen werden. Ein Schwerpunkt der Betrachtung und Charakterisierung stellt dabei die organisatorische Perspektive dar, weil die Probleme von Entwicklungsnetzwerken und deren Lösungen mittels Prototypen stark organisatorisch determiniert sind. Wissensintegration in der verteilten Teamarbeit Der bis in die jüngste Vergangenheit stark arbeitsteilig organisierte Produktentwicklungsprozess wird durch die wachsende Zahl von hochspezialisierten Experten bestimmt, so dass neben der ablaufbedingten Taylorisierung eine wissens- und kompetenzorientierte Taylorisierung in der

14

1 Einleitung

industriellen Praxis zu beobachten ist. Dies erschwert die schnelle und flexible Integration von neuen Produktfunktionen und führt durch einen stark erhöhten Abstimmungsbedarf zu überproportional steigenden Planungsund Koordinationsaufwänden. Studien zeigen, dass eine verstärkte und detaillierte Planung jedoch nicht zielführend ist. Deshalb werden in der Zukunft vermehrt Methoden zur schnellen Wissensintegration und für eine effiziente Teambildung benötigt. In den vergangenen Jahren sind Untersuchungen zu einer Standardisierung der Entwicklungsprozesse durchgeführt worden. Ergebnisse von Forschungsvorhaben und Beispiele aus der Industrie zeigen jedoch, dass insbesondere die Entwicklung und Erprobung innovativer Produkte nur bedingt standardisierbar sind. Neue Ansätze aus dem SoftwareManagement hinsichtlich der Wiederverwendbarkeit von SoftwareBausteinen können aber auf den Produktentwicklungsprozess übertragen werden, sodass zumindest erprobte Lösungsschritte als Erfahrungswissen abgelegt und wieder verwendet werden können. Die schnelle Produktentwicklung erfordert häufig eine intensive Kooperation zwischen den verschiedenen Teams innerhalb eines Unternehmens sowie zwischen den Teams und den Kunden bzw. den Zulieferern. Zusätzlich werden bei komplexen Entwicklungsvorhaben, wie z. B. bei der Gestaltung des Fahrzeuginnenraums, eine ganze Reihe von Subteams innerhalb des Entwicklungsteams gebildet. Experten sind häufig Mitglied in mehreren Teams, sodass in der Regel eine Multiteamarbeit vorliegt. Sie stellt ganz neue Anforderungen an die unterstützenden Planungswerkzeuge. Diese müssen an das dynamische Umfeld und an die wechselnden Aufgabenstellungen angepasst sein. Notwendig, aber momentan nur in Grundzügen vorhanden, sind deshalb sowohl ein teamabhängiges adaptives Rollenkonzept für die Experten als auch Methoden für Navigation und Transparenz während der Kooperation. Informationsbereitstellung Für eine iterative, evolutionäre Produktentwicklung ist die Nutzung von fachübergreifenden Informationen in allen Phasen des Produktentwicklungsprozesses eine große Herausforderung. Ein Problem stellt immer noch die situationsgerechte Bereitstellung von Prozess-, Konstruktionsund Technologiewissen aber auch von Wissen über Zeiten, Kosten und Qualitäten dar. Der komplexer werdende Lösungsraum muss durch jeden Spezialisten situativ und aufgabenangemessen bearbeitet werden können, ohne dass der Gesamtzusammenhang verloren geht. Ziel dabei muss sein, das gesamte


15

aktuelle interdisziplinäre Wissen eines Unternehmens zur Verfügung zu stellen. Eine wesentliche Herausforderung für zukünftige Systemgenerationen zur Unterstützung der Produktentwicklung ist es daher, von einzelplatzorientierten zu intelligenten und kooperationsorientierten Bearbeitungsstrukturen zu gelangen. Dazu ist eine rollenspezifische und projektphasenabhängige Aufbereitung einer aktiven Wissensbasis notwendig, unter gleichzeitigem Anbieten einer Gesamtübersicht. Hierfür gibt es derzeit nur begrenzt einsatzfähige Instrumente. Das komplexe Wissen ist in der Regel durch multimediale Inhalte repräsentiert, die für eine schnelle Wissensintegration in adäquater Form visualisiert und zugänglich gemacht werden müssen. Eine intelligente Visualisierung muss dabei, im Gegensatz zu heutigen Systemen, durch Adaption den Wissensfortschritt der einzelnen kooperierenden Experten unterstützen. Aufgrund der zunehmenden funktionellen Abhängigkeiten innerhalb des Produkts entsteht zudem eine komplexe Vernetzung der heterogenen Entwicklungswerkzeuge. Um bei der Benutzung der Werkzeuge die Konsistenz der Ergebnisse zu gewährleisten, müssen neue Methoden zum Information Routing zwischen zu integrierenden Werkzeugen erarbeitet werden. Ein insbesondere in heterogenen und verteilten Umgebungen zunehmend an Bedeutung gewinnendes Problem liegt in der sicheren Übermittlung der für die Produktentwicklung relevanten Informationen. Die zur Kommunikation eingesetzten Dienste unterliegen dabei einer hohen Innovationsdynamik, sodass neue Unterstützungsfunktionen für den gesamten Produktentwicklungsprozess realisiert werden können und müssen. Die Konvergenz, d.h. das Zusammenführen von traditionell getrennten Medien zu einer gemeinsamen Infrastruktur erlaubt die Entwicklung von integrativen Kommunikationsdiensten für die kooperative Arbeitsweise der Experten. Für die Unterstützung der verteilten Zusammenarbeit von multidisziplinär ausgerichteten Experten in der Produktentwicklung werden Instrumente entwickelt, die die Probleme in diesen Teams analysieren und Ansätze zu deren Lösung geben. Weiterhin werden Strategien zur Förderung der Wissensintegration in multidisziplinären Teams analysiert und erprobt, die die schnellere Schaffung einer gemeinsamen Wissensbasis erlauben. Unter einer gemeinsamen Wissensbasis ist ein gemeinsam geteiltes Verständnis wichtiger Begriffe und ihrer Zusammenhänge zu verstehen. In Untersuchungen ist festgestellt worden, dass Probleme im Bereich der Kommunikation, Koordination und Wissensintegration mit einer negativen Einschätzung der Leistung von RPD Teams hinsichtlich der Einhal-

16

1 Einleitung

tung von Zeit, Produktentwicklungskosten und Produktqualität einhergehen. Die Mitglieder selber empfinden dabei Stress und eine geringere Arbeitszufriedenheit. Für die Kooperation in den Teams sind drei unterschiedliche Muster zu identifizieren: x innerbetriebliche Kooperation in funktionsübergreifenden Teams in mittelständischen Betrieben, x innerbetriebliche Kooperation in bereichsübergreifenden Teams in international agierenden Unternehmen, x unternehmensübergreifende Entwicklungsteams in mittelständischen Unternehmen. Untersuchungen haben gezeigt, dass bei Unternehmen, die dem zweiten Muster entsprechen, mehr Probleme bezüglich der Kommunikation, Kooperation und Wissensintegration im Vergleich zu den anderen beiden Typen existieren. Wichtige Einflussfaktoren sind dabei die unterschiedlichen Freiheitsgrade für die Teammitglieder bzgl. der Selbstorganisation und die Kooperationserfahrung, die die Teammitglieder mitbringen. Daher ist es wichtig zu erkennen, welche Arten von Wissen (Fachwissen, Erfahrungswissen) vorliegen und wie das für die Produktentwicklung notwendige Wissen bei unterschiedlichen Wissensdomänen und Rollen repräsentiert wird. Weiterhin muss geklärt werden wie eine Integration des Wissens in multidisziplinären Teams abläuft bzw. unterstützt werden kann. Dabei steht der Einfluss von den Rahmenbedingungen wie: z.B. die Organisationsstruktur, die Komplexität der Aufgabe, die Heterogenität des Teams, die technologische Unterstützungsmöglichkeiten und die Kreativitätsförderlichkeit des Umfeldes unter besonderer Beachtung. Um den Anforderungen gerecht zu werden, werden die Teams auf verschiedenen Ebenen näher betrachtet. Diese Ebenen betreffen den Zugang zu den Informationen, die Planung der Teams und die Kommunikation zwischen den Mitgliedern. Der Zugang zu diesem Wissen muss zentral und rollenspezifisch zur Verfügung stehen, damit eine effektive Unterstützung gewährleistet werden kann. Hierzu dienen Portale die einen schnellen und strukturierten Zugang zu fachlichen und fachübergreifenden Informationen sowie informationsverarbeitenden Applikationen in allen Phasen der Produktentwicklung ermöglichen. Durch die hohe Komplexität bei Produkten und Prozessen fallen bei der Produktentwicklung viele Informationen in heterogener Struktur an. Diese setzen sich aus CAD-Daten, Kostenberechnungen, Werkstoffdaten, Stücklisten, etc. zusammen. Um die Forderung nach einer


17

gemeinsamen Wissensbasis zu erfüllen, stehen diese Informationen für jeden Experten spezifisch zur Verfügung. Dies kann durch den Einsatz adaptiver Benutzungsoberflächen unterstützt werden. Um dieses zu ermöglichen, müssen der Zugang und die Aufbereitung der Informationen untersucht werden. Dabei stehen neue Arten und Methoden der Darstellung und der Visualisierung von Daten insbesondere im Hinblick auf die Vernetzung im Vordergrund. Außerdem werden geeignete Adaptionskonzepte, die sich auf die Auswahl der Inhalte und die Darstellung beziehen, analysiert. Neben diesem spezifischen Zugang zu den Informationen ist eine Planung für die Teams notwendig. Die Voraussetzung für das effektive und verzahnte Arbeiten von diesen verteilten Entwicklungsteams ist die Nutzung der durch die flexiblen Organisationsprozesse geschaffenen Spielräume. Die Koordination autonomer Entwicklungsteams, die Unterstützung arbeitsintensiver und planerischer Tätigkeiten sowie die Realisierung zuverlässiger und transparenter Planungsergebnisse ist dafür notwendig. Hierdurch soll die kontinuierliche Generierung von Ideen gefördert und der Aufbau von Wissen entlang des Produktentwicklungsprozesses unterstützt werden. Aus diesen Rahmenbedingungen und der dezentralen Struktur in den Entwicklungsprojekten heraus ergeben sich Anforderungen an die Planung hinsichtlich der methodischen Unterstützung, der Klärung von Zielvorgaben, der Verarbeitung unvollständiger und inkonsistenter Daten, der durchgängigen Unterstützung der Dokumentation und Planung und der Integration und Förderung informeller Abstimmungsprozesse. Als Lösung entstand das »entwicklungsfähige Projektplanungssystem« zur Unterstützung einer teilweise automatisierten Koordination projektmanagementspezifischer Tätigkeiten auf der einen Seite und zur Integration kooperierender Entwicklungsteams auf der anderen Seite. Mittels der Nutzung des Multi-Agenten-Systems wird dabei die Anwendbarkeit auf dezentrale Strukturen im RPD ermöglicht. Die Dezentralität wirkt sich jedoch nicht nur auf den Zugang zum Wissen und der Planung der Teams aus, sondern bildet auch für die Kommunikation zwischen den Mitgliedern in diesen multidisziplinären Teams einen entscheidenden Faktor. Die aus dem Anspruch der Beschleunigung von Iterationszyklen und der Erhöhung des Wissenszuwachses im Entwicklungsprozess abgeleiteten Anforderungen bedürfen somit einer Plattform, die sowohl spontane als auch längerfristige Absprachen unterstützt. Dabei müssen auch die jeweiligen Arbeitsumfeldbedingungen der Mitglieder erfasst werden, da sich nur auf diesem Wege unnötige Iterationszyklen in der Kommunikation der Experten vermeiden lassen. Um die Steigerung der Effizienz in der Kommunikation zu erhalten wird eine Brücke zwischen der synchronen und der asynchronen Kommunikation geschaffen. Diese Infrastruktur ermöglicht es, eine asynchrone In-

18

1 Einleitung

formation mit notwendigen prozessrelevanten Informationen zu hinterlegen, um somit die Iterationen im Kommunikationsprozess zu minimieren. Durch die Implementierung gemeinsamer virtueller Arbeitsräume, die sowohl synchron, als auch asynchron genutzt werden, können die hemmenden Einflussfaktoren aus der räumlichen und zeitlichen Distanz minimiert werden. Weiterhin wird durch die Zusammenlegung verteilt arbeitender Teams an einen virtuellen Ort die Bildung von Awareness unterstützt und somit eine effizientere Koordination von Arbeitsabläufen ermöglicht. Die Unterstützung der Teams in der evolutionären und iterativen Produktentwicklung lässt sich nur mit einer effektiven Unterstützung der Teammitglieder erreichen. Diese setzt sich aus den Bereichen des Informationszugangs, der Planung zur Nutzung freier Ressourcen und der Kommunikation untereinander zusammen. Die ASN-Technologie Ziel der Entwicklung des Aktiven Semantischen Netzes (ASN) ist die adäquate Speicherung und Wiederverwendung aller Informationen, die beim gesamten Produktentwicklungsprozess anfallen. Solch ein System muss neben statischen Produkt-, Technologie- und Projektdaten vor allem dynamisches Wissen in Form von z.B. Ursache-Wirkungsketten repräsentieren. Produktentwicklung ist ein iterativer Prozess, der durch die Entstehung und Verarbeitung von Produktdaten charakterisiert ist. Durch den intelligenten Einsatz von Regelmechanismen des ASN können diese inkonsistenten Produktdatenänderungen vermieden werden und die Prozesssteuerung aktiv im Sinne der Termintreue, Qualitätssteigerung und Kostenkontrolle unterstützt werden. Schwerpunkte der Arbeit waren die Formulierung eines Metamodells und die Implementierung auf ein objektorientiertes Datenbanksystem, die Erfassung der Semantik im ASN durch die Konzepte Objektart, Beziehungsart, Merkmalart und Objektänderungsart. Es werden nicht nur einfache Beziehungen zwischen diesen Objekten, sondern auch die Beziehungen zwischen deren Teilen in Betracht gezogen. Die ASN-„Intelligenz“, die nicht als Daten und ECA-Regeln erfasst werden kann, wurde mittels Agenten-Software realisiert. Agenten können mit Hilfe der JAVA-Beans basierten Schnittstelle Objekte instanziieren, die der spezifischen Sichtweise des Benutzers entsprechen. Zusammenfassend erlaubt das ASN eine konkrete Wissensrepräsentation im Rapid-Prototyping. Durch den reversiblen Charakter des ASN ist ein kontinuierlicher Aufbau einer dezentralen Wissensbasis erstmals möglich.


19

1.1.5 Sfb 374 - Aufbau und Wissenswertes Praxisbezug und Dissemination Die Weiterentwicklung der erforschten Methoden und Modelle wurde am Beispiel des Fahrzeuginnenraums in Zusammenarbeit mit dem Partner DaimlerChrysler AG durchgeführt. Dabei wurden z.B. gestalterische, ergonomische, funktionelle und klimatechnische Aspekte behandelt und die effiziente Erstellung hybrider Prototypen untersucht. Abhängig vom Forschungsschwerpunkt der Teilprojekte wird lediglich auf einzelne Komponenten oder auf den gesamten Fahrzeuginnenraum zugegriffen. Am Beispiel des Fahrzeuginnenraums wurden exemplarisch die im Sonderforschungsbereich gewonnen Erkenntnisse über neue Kooperationsstrukturen, die Integration von Wissen über Konstruktion, Kosten, Zeit und Qualität sowie die Erstellung von Prototypen zusammengeführt. Mit den aus dem Sonderforschungsbereich hervorgegangenen fünf Transferprojekten wurden durch eine enge Kooperation wichtige Erkenntnisse zur Anwendung der Forschungsergebnisse im industriellen Umfeld gewonnen. RPD Toolbox Die Weitergabe und Diffusion der Forschungsergebnisse an eine breite, interessierte Öffentlichkeit war speziell in der vierten Förderperiode ein weiteres wichtiges Ziel des Sfb. Dazu wurde eine „RPD-Toolbox“ entwickelt, die laufend durch Veröffentlichungen über den aktuellen Stand der Forschung unterrichtet. In der „RPD-Toolbox“ (Abb. 1.3.) werden die entwickelten Methoden unter einer benutzerfreundlichen Oberfläche aufbereitet. Die Ergebnisse werden der Öffentlichkeit durch ein Web-Interface zugänglich gemacht. Ergänzend zu diem Buch sind in der Toolbox auch technische Informationen, Demoversionen und Multimediainhalte verfügbar. Die RPD Toolbox ist erreichbar unter: http://www.rpdtoolbox.sfb374.uni-stuttgart.de.

20

1 Einleitung

Abb. 1.3. RPD-Toolbox

Organisation des Sonderforschungsbereichs 374 Der Sfb 374 wurde in die nachfolgenden fünf Projektbereiche gegliedert, in denen die Teilprojekte erfolgreich gemeinsam an einem Forschungsschwerpunkt arbeiteten (s. Abb. 1.4., Stand 2006). Im Rahmen der Arbeiten des Projektbereiches A, „Grundlagen der Organisation und Planung“ wurden die personellen, organisatorischen und planerischen Aspekte des Rapid Product Development erforscht. Mit Hilfe eines arbeitssystemübergreifenden Ansatzes wurden multiteamorientierte Konzepte und Methoden erarbeitet. Es wurden Instrumente zur Modellierung von Prozessen und Rollen des RPD sowie Konzepte für ihre Wiederverwendbarkeit bei der Planung zukünftiger Projekte entwickelt. Im Projektbereich B, „Vernetztes Wissen für die iterative Entwicklung von Prototypen“ wurden Methoden zur Integration von Konstruktions-, Qualitäts- und Kostenwissen entwickelt. Der Projektbereich C, „Wissensrepräsentation und Kommunikation“ fasste die informations- und kommunikationstechnischen Forschungsarbeiten zusammen. Im Rahmen des Projektbereiches D, „Erstellung virtueller und physischer Prototypen“ erfolgt die Entwicklung von Methoden zur Erzeugung von virtuellen Prototypen, insbesondere für die Gestaltung der virtuellen


21

Realität (VR) und zur Simulation und Visualisierung physikalischtechnischer Prozesse. A Grundlagen der Organisation und Planung

B C D E Vernetztes WissensErstellung virRechnerWissen für repräsentation und tueller und unterstützte Fahrdie iterative Kommunikation physischer zeugkonzeption Entwicklung Prototypen von Prototypen B1 C1 D1 E1 Modellieren Ganzheitliche Mo- Virtuelle Reali- Rechnerunterstützte des vernetz- delle zur Repräsenta- tät als Gestal- Fahrzeugkonzeption ten Denkens tion aktiven Wissens tungs-, Evaluam Beispiel Fahrund Handelns (Roller) ierungs- und zeuginnenraum in der KonKooperations(DC AG) struktion werkzeug (Bertsche) (Westkämper / Kern) A2 B2 C2 D2 Planungsmethoden QualitätsAdaptive BenutVisualisierung für dezentrale management zungsoberflächen und Simulation Entwicklungsim Rapid (Weisbecker) physikalischteams Prototyping technischer (Spath) (WestkämVorgänge per) (Lang / Resch) A3 C3 D3 ArbeitswissenTeamorientiertes Aufbau und schaftliche KonKommunikationsBetrieb von zeptionierung kosystem für vernetztes Rapid Prototyoperativer Arbeiten pingArbeitsformen für (Warschat) Prozessketten die Entwicklung (Westkämper) innovativer Produkte (Spath) C4 D4 Integrationsplattform Rapid Prototyfür aktive Wissens- ping Labor zur kommunikation Herstellung (Roller / Warschat) funktionaler und technischer Prototypen mittels Lasertechniken (Dausinger / Eyerer) D5 Entwicklung von Werkzeugen für Prototypteile (Wagner)

Abb. 1.4. Gliederung in Projektbereiche und Teilprojekte

22

1 Einleitung

Dieses Basiswissen über die verschiedenen Technologien wie VR, Rapid Prototyping, Rapid Tooling wird entsprechend aufbereitet und allen im Sonderforschungsbereich Beteiligten über das Aktive Semantische Netz (ASN) zur Verfügung gestellt. Der Einsatz von Höchstleistungsrechnern unterstützt dabei eine anschauliche Visualisierung einzelner Entwicklungsschritte und macht die Kopplung virtueller und physischer Prototypen möglich. Die Erforschung dieser hybriden Prototypen ist ein teilprojektübergreifendes Aufgabengebiet des Projektbereiches D. In dem Projektbereich E, „Rechnerunterstützte Fahrzeugkonzeption am Beispiel Fahrzeuginnenraum“, wurde umfassendes Wissen aus dem Bereich der Fahrzeugentwicklung bereitgestellt. Zusammen mit Ergebnissen der Forschungsarbeiten in den Projektbereichen A – D konnten Daten im Hinblick auf eine rechnergestützte Fahrzeugkonzeption, insbesondere zur Funktions- und Geometrieauslegung, ganzheitlich betrachtet werden. Zeitleiste 1995 1998 2001 2003

2004 2006

2006

Gründung des Sfb 374 „Entwicklung und Erprobung innovativer Produkte – Rapid Prototyping“ Beginn der zweiten Förderperiode Beginn der dritten Förderperiode Gründung des Transferbereichs 41 „Entwicklung und Erprobung innovativer Produkte“ (bis 2005). Folgende Teilprojekte wurden bearbeitet: x Kostenmanagement von Produkten und Dienstleistungen in Entwicklungsnetzwerken, Prof. Horváth x Feature-Erkennung und Segmentierung in Punktwolken mit Multisensorik, Prof. Westkämper x Lasersintern von Polymeren mittels Nd:YAG-Laser, Prof. Eyerer Beginn der vierten Förderperiode Start des Transferbereichs 65 (bis 2008) mit folgenden Teilprojekten: x Aktives sematisches Konstruktions- und Zuverlässigkeitsnetz, Prof. Bertsche x Arbeitswissenschaftliche Gestaltung wissensintensiver Kooperationsprozesse für die Entwicklung innovativer Produkte, Prof. Spath Abschluss der Forschungsarbeiten des Sfb 374

1.2 Integrationsszenario

23

1.2 Integrationsszenario Den Begriff der Produktentwicklung assoziiert man meist mit dem traditionellen Vorgehen der Entwicklung von Produkten. Demnach gliedert sich die Entwicklung grob in die fünf Abschnitte: x x x x x

Planen Konzipieren Konstruieren Ausarbeiten Herstellen

Am Ende jeder dieser Phasen steht ein Bewertungs- und Auswahlprozess, mit dessen Hilfe die optimale Variante erkoren und weiter verfolgt wird. Nachteilig wirkt sich diese Vorgehensweise aber dann aus, wenn in den Auswahl- und Bewertungsprozessen Fehler geschehen und Funktions- oder Qualitätsmerkmale unberücksichtigt bleiben. Je später der Fehler dann gefunden wird, desto zeit- und kostenaufwändiger sind die dann anfallenden Korrekturmaßnahmen. Innerhalb der bereits durchlaufenen Arbeitsschritte muss zum richtigen Entwicklungspunkt zurückgesprungen werden und die nachfolgenden Schritte incl. Überprüfungen, etc. abermals abgearbeitet werden. Eine optimale und gleichzeitig aber auch schnelle und kostengünstige Produktentwicklung ist nur schwer durchführbar. Schaut man sich die Rahmenbedingungen für die Produktentwicklung näher an, so finden sich schnell weitere Aspekte, die gerade die frühen Phasen der Produktentwicklung maßgeblich beeinflussen. Es reicht schon lange nicht mehr, ein gutes Produkt im stillen Kämmerlein über einen langen Zeitraum hinweg zu entwickeln und mit einem hohen Reifegrad auf den Markt zu bringen. Die Geschwindigkeit, in denen heutzutage neue oder überarbeitete Produkte vom Markt erwartet werden, verringert naturgemäß die Zeit, die für die Entwicklung zu Verfügung steht. Mittelständische Unternehmen können dieses Zeitfenster zumindest geringfügig erhöhen, wenn mehrere Entwicklerteams überlappend an unterschiedlichen Produkten arbeiten oder wenn neuartige Organisationsformen für das Entwicklungspersonal wie Poolbildung o.ä. Einzug halten. In vielen Bereichen des Maschinenbaus, der Luft- und Raumfahrt und der Automobilindustrie ist daher eine beschleunigte Produktentwicklung gefragt, um sich am Markt behaupten oder gar halten zu können.

24

1 Einleitung

Beschleunigte Produktentwicklung ist nicht gleichzusetzen mit Rapid Prototyping Im gleichen Atemzug mit beschleunigter Produktentwicklung wird häufig das Schlagwort Rapid Prototyping verwendet. Dies ist jedoch nur bedingt korrekt, denn eine Beschleunigung des Entwicklungsprozesses ist vor allem verknüpft mit einem Umdenken bzgl. der Organisation, der Vorgehensweise und Methoden. Beschleunigte Produktentwicklung bedingt nicht zwangsläufig den Einsatz des Rapid Prototyping als Prozess, obwohl sich dieser Gedanke zugegebenermaßen geradezu aufdrängt. Rapid Product Development muss also im Unternehmen verinnerlicht und gelebt werden und das bedingt, dass sich alle Geschäftsprozesse auf eine veränderte Arbeitsweise einstellen – nicht nur Forschung und Entwicklung. Wie wird aber nun Rapid Prototyping in der beschleunigten Produktentwicklung eingesetzt? Die Technologien, die unter dem Begriff „Rapid Prototyping“ zusammengefasst werden, haben ein gemeinsames Ziel, das sie auf unterschiedlichsten Arten zu erreichen versuchen. Lapidar ausgedrückt, sollen sie es ermöglichen, dass die Entwickler zu einem möglichst frühen Zeitpunkt den aktuellen Entwicklungsstand in die Hand nehmen können. Sie versuchen ein möglichst realitätsnahes Abbild des Produktes zu erstellen, das nicht nur am Bildschirm betrachtet, sondern auch gefühlt, gedreht und im wahrsten Sinne des Wortes „erprobt“ werden kann. Je exakter das RP-Verfahren dabei das später zu fertigende Produkt in seinen Eigenschaften nachbildet, desto besser. Unterschieden werden muss aber auch nach dem Zweck der Modellerstellung. x Konzeptmodell x Geometriemodell x Funktionsmodell Ein Konzeptmodell benötigt keinerlei mechanische Eigenschaften des Endproduktes, wohl aber Oberflächen, die in Form und Beschaffenheit dem Endprodukt nahe stehen. Diese werden erstellt, um die Formgebung des Produktes voranzutreiben und dienen als Anschauungsmodelle – meist in verkleinertem Maßstab – der Beurteilung und Bewertung von DesignVarianten. Auch hier können verschiedene Studien zum Design, als Prototyp vorliegend, wertvollere Dienste bieten, als eine Computersimulation


25

dies vermitteln kann. Einzige Alternative hierzu stellt hier die virtuelle Realität (VR) dar, die die fehlende räumliche Tiefe zu kompensieren vermag und gleichzeitig die Vorzüge der Arbeit mit Computersystemen kombinieren kann. Das Geometriemodell dient der Überprüfung der Maßhaltigkeit und Toleranzen. Das Material ist nicht zwangsläufig mit dem angestrebten Fertigungsmaterial identisch und auch Oberfläche, Farbe und mechanische Eigenschaften müssen dem Endprodukt nicht entsprechen. Ein Funktionsmodell dagegen muss zumindest kurzzeitig ähnlichen Belastungen widerstehen wie das spätere Produkt, damit seine Funktion anhand des Prototypen auch verifiziert werden kann. Auch wenn viele Fragestellungen bereits am Rechner simuliert werden können, stecken einige Simulationswerkzeuge noch in den Kinderschuhen. So bedarf z.B. die Untersuchung des akustischen Verhaltens im Fahrzeuginnenraum nach wie vor einen Modellaufbau. Gerade bei solchen Beispielen ist es von unschätzbarem Wert, wenn die Modellaufbauten dem aktuellen Stand der Entwicklung entsprechen und man sozusagen „auf Knopfdruck“ ein neues Modell generieren kann. Nur so können Entwicklungen auch entsprechend schnell verifiziert werden. Derzeit werden solche Modellaufbauten nur bei größeren Meilensteinen der Entwicklung hergestellt, da ein anderes Vorgehen zu teuer wäre. Mit Fortschritten in der Technik der RP-Verfahren könnte sich dies jedoch bald ändern. Neben dieser Unterscheidung wird als Unterscheidungskriterium auch häufig herangezogen, für welche Phasen des Entwicklungsprozesses, bzw. für welchen Fertigungsschritt der Prototyp erstellt wird: x Als „Concept Modelling“ bezeichnet man i.d.R. Funktions-Prototypen, die als physikalisches Modell des Produktes alle oder einzelne Funktionen nachbilden. x „Rapid Tooling“ bezeichnet RP-Verfahren, die ein Werkzeug herstellen, welches wiederrum zur Fertigung von Serien eingesetzt werden kann. x „Rapid Manufacturing“ bezeichnet die Verfahren, die Fertigteile erzeugen, welche direkt am Produkt eingesetzt werden können. Wie bereits eingangs erwähnt, ist die Fertigungstechnologie an sich nicht das alleinig entscheidende Kriterium für die beschleunigte Produktentwicklung. Gewaltiges Optimierungspotential bieten auch die Schnittstellen der an der Produktentwicklung beteiligten Bereiche und auch das unternehmerische Gesamtkonzept von der Auftragserteilung bis hin zur

26

1 Einleitung

Auslieferung. Aus diesem Grund beschäftigte sich der Sonderforschungsbereich (Sfb) 374 mit dieser großen Bandbreite an Themen rund um Methoden und Verfahren zur beschleunigten Produktentwicklung. 1.2.1 Grundlegende Verbesserungen Während die Produktentwicklung und die Beteiligung der unterschiedlichen Entwicklungsabteilungen auch im Bereich des Rapid Prototyping im Großen und Ganzen eher linear aufgebaut ist, versucht der Sfb 374 diese etablierten Strukturen aufzubrechen und zu einem iterativen, zyklischen Ablauf hin zu entwickeln, bei dem große und kleine Iterationsschleifen permanent immer wieder durchlaufen werden, um schlussendlich zu einem optimalen und gleichzeitig kostengünstigen Produkt in kürzerer Zeit zu gelangen. Besondere Beachtung fanden hierbei die Schnittstellen zwischen den Bereichen, da hier erhebliche Informationsverluste auftreten, die z.T. zeitaufwändige und fehlerträchtige Nacharbeiten und entsprechenden Koordinationsaufwand erfordern. In Abb. 1.4 sind die Verbindungen zwischen den einzelnen beteiligten Projekten dargestellt. Hierbei handelt sich sowohl um Daten- als auch um Informationsaustausch zwischen den Teilprojekten. Die nicht umrandeten Teilprojekte treten hierbei als Informations- und Datenplattform für alle anderen Teilprojekte auf. Die Definition und Verifizierung von bestimmten Meilensteinen der Produktentwicklung lässt sich durch kurze und schnell aufeinander folgende Iterationszyklen und verbesserte Kommunikations- und Koordinationsformen zwar mindern, aber nicht vollständig unterbinden. Durch die entwickelten Methoden unterstützt der Sfb 374 aber den deutlichen Trend zu mehr Virtualisierung in der Produktentwicklung. Waren zuvor viele Meilensteine nur durch die Herstellung realer Prototypen erreichbar, können diese nun vermehrt mittels Digital Mock-ups (DMUs) getestet, betrachtet und verifiziert werden. Auch hier liefert der Sfb 374 seinen Beitrag.


27

Abb. 1.5. Kooperationsbeispiel der Teilprojekte des Sfb 374 untereinander

1.2.2 Integration der Teilprojekte am Beispiel eines PkwCockpits Um die Beiträge aller Teilprojekte am Sonderforschungsbereich eingehend zu beschreiben, wurde in den entsprechenden Arbeitskreisen die Entwicklung eines Pkw-Cockpits der MB A-Klasse (Typ W168) nachgebildet. An diesem Beispiel ließen sich in Zusammenarbeit mit dem Kooperationspartner, der DaimlerChrysler AG, die Forschungsergebnisse weitestgehend demonstrieren. Um die Demonstration der Forschungsergebnisse möglichst einfach und anschaulich zu halten, beschränken sich die folgenden Erläuterungen auf Entwicklungsausschnitte der Bereiche der Luftdüsen, der Bedienelemente im Mittelteil und der äußeren Schaltung. Aufgrund der Vielfalt und Komplexität der Themenfelder können an dieser Stelle die durchgeführten Forschungsarbeiten und erzielten Ergebnisse nur angedeutet werden. Details sind in den folgenden Kapiteln zu finden, auf die hier im Folgenden immer wieder verwiesen wird. Die jeweiligen Forschungsergebnisse werden dort dann u.a. an weiteren Beispielen erläutert, die die Forschungsarbeiten ggf. umfassender veranschaulichen.

28

1 Einleitung

Abb. 1.6. Cockpit der MB A-Klasse (W168) in einem frühen Entwicklungsstadium (Quelle: DaimlerChrysler AG)

Organisation und Planung Die Entwicklung eines Pkw-Cockpits erfordert die Integration verschiedener Teams, die unterschiedliche Entwicklungaufgaben bewältigen müssen. In einem Team, das sich zum Beispiel auf die Konzeption und Entwicklung der Bedienelemente und der äußern Schaltung konzentriert, haben Experten, die sich auf die Anwendungsergonomie der Bedienelemente konzentrieren eine herausgehobene Stellung. Demgegenüber haben in einem Team, das sich für die Entwicklung der Luftdüsen verantwortlich zeichnet, Experten, die Strömungssimulationen vornehmen können eine exponierte Stellung. Alle Experten verfolgen mit ihrer unterschiedlichen Expertise ein gemeinsames Ziel: die Entwicklung eines bedienfreundlichen, ergonomischen, zeitgemäß designten Pkw-Cockpits. Insbesondere aufgrund der für das RPD signifikanten iterativ evolutionären Vorgehensweise, die sich in einer hohen Dynamik und Komplexität bei möglichen alternativen Entwicklungsverläufen äußert, steht der Projektleiter, vor der Herausforderung, unterschiedliche Expertisen und Perspektiven der jeweiligen Experten auf ein Ziel, die Entwicklung des Pkw-Cockpits zu integrieren. Dazu kann er sich der in Kapitel 2.4 beschriebenen und auf Basis empirischer Studien entwickelten Unterstützungsinstrumente zur Wissensintegration


29

bedienen. Auf Basis typischer Barrieren der Kooperation und Wissensintegration in interdisziplinären Teams können Trainingskonzepte bei der Entwicklung des Pkw-Cockpits eingesetzt werden, mit denen zum einen die Entwicklung einer gemeinsamen Wissens- und Erfahrungsbasis vorangetrieben und zum anderen die Steuerung der Wissensintegration vermittelt werden kann. Ein früher und das Projekt stetig begleitender Einsatz dieser Instrumente kann die Effizienz und Effektivität der Kooperation von Experten in interdisziplinären Teams verbessern. Signifikant für die intensive Kooperation von Experten bei der Entwicklung alternativer Konzepte für das Pkw-Cockpit ist darüber hinaus eine große Vielfalt voneinander abhängiger Prozesse und Aktivitäten. Nach Maßgabe des RPD-Konzepts ist hier eine schnelle Anpassung der Prozesse und Aktivitäten an die jeweiligen spezifischen Situationen bei der Entwicklung des Pkw-Cockpits gewollt. Mit dem in Kapitel 2.3 beschriebenen »entwicklungsfähigen Projektplanungssystem« wird ein Unterstützungsinstrument vorgestellt, in dem auf Basis generischer Prozessmodule, die über Parameter miteinander verbunden sind, die vielfältigen von unterschiedlichen, interdisziplinären Teams durchzuführenden Aktivitäten koordiniert werden können. Mit dem »entwicklungsfähigen Projektplanungssystem« können ad-hoc auftauchende Probleme bis zu einem, in einem Iterationszyklus vermuteten, Verursacher propagiert werden und durch den Einsatz eines problemlösungsorientierten Kompetenzmanagements schneller abgestimmt werden. Schaffung einer RPD-IT-Infrastruktur Für die Arbeit von dezentral organisierten Entwicklerteams ist ein enormer Koordinations- und Kommunikationsaufwand zu betreiben. Um diesen nach Möglichkeit zu minimieren und zu optimieren, wurde eine RPD-ITInfrastruktur geschaffen. Diese beinhaltet eine flexible Datenhaltung in vorm eines semantischen Netzes, einer agentenbasierten Middleware, einer Kommunikationsumgebung und einer einheitlichen Benutzungsoberfläche. Sie ist in Schichten angeordnet (Kap. 4). Für das Entwicklungsbeispiel des Pkw-Cockpits wurden neben geometrischen und beschreibenden Prototypdaten auch organisatorische Daten wie z.B. zu den beteiligten Personen und deren Zuständigkeiten hinterlegt. Diese Daten werden in dem in Kapitel 4.1 vorgestellten Aktiven Semantischen Netz (ASN) gespeichert. Der Vorteil des ASN gegenüber klassischen Datenbanken besteht darin, dass es möglich ist zur Laufzeit Datenobjekte um weitere Bestandteile zu erweitern. So ist es durch den Einsatz des ASN möglich, während der Entwicklung des Pkw-Cockpits neu auftre-

30

1 Einleitung

tende Eigenschaften, wie z.B. die Helligkeit eines neu entwickelten Bedienelements, durch direkte Anpassung des Datenmodells zu berücksichtigen. Darüberhinaus bildet die in Kapitel 4.2 beschriebene agentenbasierte RPD-Middleware die Schnittstelle zum ASN. Sie bietet den Experten zusätzliche Funktionalität an, die diese im Rahmen ihrer interdisziplinären Zusammenarbeit unterstützen. So ist es, um ein Beispiel zu nennen, möglich, Überwachungspunkte als Trigger im ASN zu setzen, um über Veränderungen, die durch einen anderen Experten ausgelöst wurden, informiert zu werden. Ändert sich die Form eines Bedienelements und hat der Konstrukteur des Pkw-Cockpits einen Überwachungspunkt auf die Form des Bedienelements gesetzt, so wird er automatisch von der RPD-Middleware informiert und kann diese Veränderung im Design des Pkw-Cockpits zeitnah ohne direkte Rückkopplung mit dem Konstrukteur des Bedienelements in seine Überlegungen einbeziehen. Auf diesen beiden datenorientierten Schichten bauen die spezialisierten RPD-Anwendungen, wie das ASK, etc. ebenso auf, wie das Teamorientierte Kommunikationssystem (Kap. 4.3). Dieses unterstützt die interdisziplinäre Zusammenarbeit der Experten durch den Bereitstellung eines oder mehrerer virtueller Kommunikationsräumen. Wird bspw. durch die Veränderung eines Bedienelements und die damit verbundene Benachrichtigung des Cockpit-Konstrukteurs ein Fertigungskonflikt aufgedeckt, so können sich beide Konstrukteure im teamorientierten Kommunikationsraum treffen und unter Einsatz verschiedener Kommunikationsmittel, wie z.B. einem virtuellen Flipchart, das Problem diskutieren und lösen. Dabei können Informationen aus dem ASN direkt in den Kommunikationsraum eingebracht werden. Als oberste Schicht wird in Kapitel 4.4. die adaptive Benutzungsoberfläche beschrieben. Diese vereinheitlicht zum einen den Zugang zu den RPD-Anwendungen und ermöglicht zum anderen eine konfigurierbare Nutzungsschnittstelle, die speziell auf die Bedürfnisse der Experten zugeschnitten werden kann. So erhält ein Konstrukteur die Konstruktionsdaten des Pkw-Cockpits dargestellt, während adaptive Benutzungsoberfläche die Kosten der einzelnen Komponenten des Cockpits für den Kostenrechner aufbereitet. Durch den Einsatz der RPD-IT-Infrastruktur werden die Experten der interdisziplinär agierenden Teams, in ihrer Arbeit visuell, interaktiv und kommunikativ unterstützt.


31

Kosten, Qualität und Zeit In Kapitel 3 finden sich Methoden, Ansätze und Werkzeuge, um die beschleunigte Produktentwicklung hinsichtlich der Aspekte Qualität, Entwicklungskosten und -zeit zu optimieren. Vorgestellt wird u.a. der Softwareprototyp eines Konstruktionssystems, dem Aktiven Semantischen Konstruktions- und Zuverlässigkeitsnetz (ASK/ASZ), das phasenübergreifend die Produktentwicklung bereits ab den frühesten Entwicklungsphasen unterstützt und hierbei von Beginn an Systemzuverlässigkeit und Herstellkosten besonders berücksichtigt. Nach der Vorstellung der Fähigkeiten werden in Kap. 3.2 beispielhaft Arbeiten mit und am Pkw-Cockpit, speziell der Schaltung erläutert. So wurde die Entwicklung des Pkw-Cockpits von der Erstellung einer Anforderungsliste, über verschiedene Entwicklungsstufen, bis hin zur Erstellung eines ersten Prototypen modelliert. Ein besonderer Schwerpunkt lag hierbei auf der Einbeziehung von Zuverlässigkeitsanalysen, sowohl qualitativer, als auch quantitativer Art und auch auf dem modularen Aufbau durch die Entwicklung eines Baukastensystems. Bei der Entwicklung mit Hilfe des ASK/ASZ wurden zu verschiedenen Zeitpunkten spezielle Expertensysteme zu Rate gezogen, die vor allem letzten Endes Entwicklungszeit einsparen und die Produktqualität verbessern helfen sollten. In Kap. 3.3 werden Methoden und Tools zum Komplexitätsmanagements und der Qualitätssicherung gegeben. Hierbei werden z.B. Merkmale des Produktes extrahiert und daraus die relevanten Qualitätsmerkmale abgegrenzt. Ebenso wurde ein Referenzmodell zum umfassenden Qualitätsmanagement in dynamischen Strukturen erarbeitet. Es dient unter anderem als Wissensbasis für das ASK/ASZ und erhält seinerseits Informationen aus den Rapid Prototyping Verfahren, die in Kap. 5 vorgestellt werden. Neben der Berücksichtigung von Herstellkosten im ASK/ASZ, müssen zur Kostensenkung auch die Prozesskosten herangezogen und optimiert werden. Dies ist u.a. deshalb notwendig, weil die Betrachtung der Herstellkosten im Sinne des Target Costings nicht alle anfallenden Kosten erfassen kann. In Kap. 3.4 wurde untersucht, wie im Rapid Product Development die Entwicklung hinsichtlich der Prozesskosten kontrolliert und gesteuert werden kann. So wurden Leistungsbündel erfasst und bewertet und schlussendlich Werkzeuge entwickelt, die einen Prozess an sich transparent und beherrschbar machen.

32

1 Einleitung

Erstellung virtueller und physischer Prototypen Auch am Beispiel des Pkw-Cockpits wurden bestimmte Bereiche der Mittelkonsole und des Armaturenträgers in Simulationen und der virtuellen Realität (VR) analysiert. Auf diese Weise konnte z.B. ohne teure Strömungsversuche das Strömungsverhalten der Luftdüsen in der virtuellen Realität dem physischen Modell durch Techniken der Augmented Reality (AR) mittels einer 3D-Shutter Brille überlagert und so effektiver visualisiert werden (Kap. 5.5). Eine neu entwickelte Software ermöglichte die direkte Kopplung eines CAD-Systems mit einer so genannten Cave, die das intuitive Arbeiten mit dem CAD-System in der virtuellen Realität ermöglicht und mittel ausgeklügelter Datenrückkopplung auf einfache Art und Weise Bewegungs- und Montageanalysen zulässt (Kap. 5.2, 5.3, 5.5). So wurden am Beispiel des Pkw-Cockpits Montierbarkeitsuntersuchungen und Ergonomiestudien durchgeführt. Nach der Entwicklung des Cockpits auf theoretischer und virtueller Basis und den beschriebenen Untersuchungen wurden auch Teile des Cockpits mittels Rapid Prototyping Verfahren gefertigt. Dabei kamen neu entwickelte RP-Verfahren, wie das „Multi Material Modelling“ (MMM) (Kap. 5.7) zum Einsatz, wie auch das „Selektive Lasersintern“ an Hochtemperaturkunststoffen (Kap. 5.10) oder das Lasergenerieren im modularen System (Kap. 5.9). Neue Beschichtungtechnologien ermöglichen das Aufbringen von Funktionsbeschichtungen (Kap. 5.8) und ermöglichen so die Erweiterung des Einsatzfeldes herkömmlicher Prototypen. So wurden die herkömmlichen Bedienelemente durch ein Multifunktionsdisplay mit entsprechender Buttonleisten ersetzt. Die Entwicklung in der Blechumformung ermöglichten die rein virtuelle Konstruktion und Evaluation von Blechträgern im Bereich des Cockpits und die Simulation des Umformvorgangs. Auf diese Weise wurde mit dem entwickelten Rapid Prototyping Labor auf modernste Weise ein Kunstoffwerkzeug für die Umformpresse erzeugt, was im Vergleich zu herkömmlichen Werkzeugen einen enormen Kosten- und Zeitvorteil darstellt (Kap. 5.11). Designstudien sollen ohne zeitraubende Umwege möglichst schnell als Designmodell gefertigt werden. Hierzu unabdingbar ist die daten- und informationstechnische Integration des Entwurfsprozesses in die RPDProzesskette. Forschungsergebnisse aus diesem Bereich werden in Kap. 5.6 vorgestellt. Die Details zu den verwendeten Technologien, Methoden und Simulations- und Visualisierungswerkzeugen finden sich im Kapitel 5.

2 Organisation und Wissenskooperation

2.1 Merkmale des Rapid Product Development Vor dem Hintergrund einer zunehmenden Innovationsdynamik und Differenzierung von Kundenwünschen im internationalen Wettbewerb gewinnt für Unternehmen die Fähigkeit an Bedeutung, Produktentwicklungszeiten zu verkürzen und eine kontinuierliche Abstimmung der Produktmerkmale mit den Kunden zu gewährleisten. Die steigenden Marktanforderungen verlangen von Unternehmen eine stetig wachsende Zahl von Neuentwicklungen, eine gleichzeitige Verkürzung der Entwicklungszeit, die kontinuierliche Abstimmung mit Kundenwünschen und nicht zuletzt die schnelle und flexible Integration neuer Produktfunktionen. Um diese Ziele zu erreichen und zudem innovative Produkte schnell und kostengünstig entwickeln zu können, bedient sich die Methode des Rapid Product Developments (RPD) eines evolutionären Vorgehens [2.18], [2.16], [2.17]. Verschiedene konkurrierende Lösungsalternativen werden in parallel verlaufenden Iterationszyklen bearbeitet und zeitnah an sich verändernde Marktbedingungen, Kundenwünsche und Erkenntnisfortschritte angepasst. Erst zu einem späten Zeitpunkt wird die Entscheidung getroffen, welcher der verschiedenen Produktansätze tatsächlich in die abschließenden Entwicklungs- und späteren Produktionsphasen gelangt. In Anlehnung an das Motto „Survival of the fittest“ gelangen also nur diejenigen Produktvarianten in die (Re)Produktion, die sich als die am besten den Markt- und Produktionsanforderungen entsprechenden erwiesen haben. Die wichtigsten Merkmale dieses Ansatzes umfassen: x Betonung der frühen Entwicklungsphasen x parallele Entwicklung alternativer Produktkonzepte x schnelle iterative Schleifen, die den Prozess von der Konstruktionsidee bis hin zur Bewertung in einem verhältnismäßig kleinen Zeitraum abbilden x späte Festlegung und Spezifikation des Produkts

34


x schnelle Erstellung von physischen, virtuellen und hybriden Prototypen x frühes Ergebnisfeedback x Optimierung der erfolgsrelevanten Faktoren Kosten, Zeit und Qualität Für die einzelnen Produktentwicklungsteams ergeben sich aus diesen Merkmalen wiederum Veränderungen ihrer Arbeitsprozesse, die den Bereichen Innovationsanforderungen, Komplexitätsanforderungen und Teamanforderungen zugeordnet werden können.

2.2 Anforderungen an Produktentwicklungsteams

2.2.1 Innovationsanforderungen Voraussetzung für den nachhaltigen Markterfolg von vielen Unternehmen ist heute die Entwicklung von innovativen Produkten. Nur durch neuartige Funktionen und Designs, originelle und kreative Lösungen, Entwicklung neuartiger Nutzenaspekte und marktbezogener Alleinstellungsmerkmale sowie durch verstärkte Bedienung immer neuer Kundenwünsche können Marktanteile erobert oder gesichert werden. Dies bedeutet, dass Produktenwicklungsteams gegensätzliche Ziele verfolgen müssen: Einerseits möglichst innovative und kreative Produkte entwickeln, andererseits möglichst wenig Zeit und Kosten während der Produktentwicklung, aber auch in Hinsicht auf die Produktherstellung zu verursachen bzw. festzuschreiben. Dieser Zielkonflikt soll im RPD-Kontext optimiert werden. Unterstützungsmöglichkeiten für die Teammitglieder müssen deshalb einerseits die Berücksichtigung der zeit-, kosten- und qualitätsbezogenen Vorgaben fördern, zum anderen den notwendigen Freiraum ermöglichen, der erforderlich ist, um innovative Ergebnisse zu erzielen. Nur so kann eine quantitative wie qualitative Steigerung kreativer Leistungen, besonders in den frühen Produktentwicklungsphasen, erzielt werden. Auswirkungen auf Kooperation, Wissensintegration und Planung Die erhöhten Innovationsanforderungen an Produktentwicklungsteams können nur bewältigt werden, wenn die teaminternen Wissens- und Kooperationsprozesse optimiert sind, aus denen Innovationen hervorgehen sollen. Innovative Lösungs- und Produktkonzepte setzen voraus, dass un-


35

terschiedliches, aber komplementäres Wissen von Experten neu kombiniert wird, um neuartige Funktionen, Produkteigenschaften oder vollständig neue Produkte zu entwickeln. Dadurch kann die Stärke heterogener Expertenteams, der kombinierte Einsatz des vielfältigen Wissens der Teammitglieder, erst nutzbar gemacht werden. Vielschichtige Entwicklungsaufgaben, die Fragestellungen aus unterschiedlichen technischen, wirtschaftlichen und organisatorischen Fachgebieten in sich vereinen, setzen diese Heterogenität der Teams voraus. Die ständige Herausforderung, möglichst schnell möglichst innovative Produkte zu entwickeln, verlangt deshalb von den Mitarbeitern eine Kooperationsform, die systematischen Wissensaustausch unterstützt. Neuartige Ideen können nicht dem Zufall überlassen werden, sondern müssen durch die Art und Weise der Zusammenarbeit zwischen den Teammitgliedern gefördert werden. Aufgrund der Heterogenität des in Entwicklungsteams vorhandenen Wissens bedeutet dies, dass die Identifikation, der Abgleich und die Neukombination des Expertenwissens unterstützt werden müssen, damit Synergieeffekte entstehen und neue Lösungswege für komplexe Problemstellungen sichtbar werden. Gleichzeitig bedeutet die Vielzahl der repräsentierten fach- und funktionsgeprägten Sichtweisen der Teammitglieder, dass diese der Abstimmung und Integration bedürfen. Aus ihrer Gegensätzlichkeit heraus konkurrierende Vorstellungen der Experten über Ziele, Vorgehen und Methoden erschweren neben einer konsistenten Planung die Teamkooperation und behindern den Innovationsprozess, da sie die Rekombination des heterogenen Wissens verhindern. Durch die Bildung einer gemeinsamen Wissens- und Informationsbasis, an der alle Teammitglieder beteiligt sind, kann dieser Integrationsprozess wirkungsvoll unterstützt werden. Die Reibungsverluste, die durch die unkoordinierte und konfliktträchtige Auseinandersetzung der Teammitglieder mit ihren unterschiedlichen Denk- und Lösungsansätzen entstehen können, sind erfolgskritisch. Die Ausprägung der relevanten Faktoren Kosten, Zeit und Qualität hängt nicht zuletzt davon ab, wie effizient die Fach- und Funktionsexperten in den Produktentwicklungsteams ihr Wissen integrieren und für die Entwicklung neuer Lösungswege nutzen. 2.2.2 Komplexitätsanforderungen Obwohl die Anforderungen an die Planung der parallelen Entwicklungsaktivitäten steigen, werden durch deren Flexibilität (z.B. durch Verwerfen oder Neuaufnahme eines Produktansatzes) die Möglichkeiten einer formalen Planbarkeit von Entwicklungsprojekten, die dem Konzept des RPD

36


folgen, verringert. Hinzu kommt, dass die Entwicklung und Erprobung innovativer Produkte nur begrenzt standardisierbar ist, so dass häufig lediglich auf der Ebene einzelner Lösungsschritte Elemente wiederverwendet werden können. Zur Komplexität tragen auch die zunehmenden funktionalen Abhängigkeiten innerhalb des Produkts bei. Nicht zuletzt muss der um ein vielfaches größer werdende Lösungsraum durch die einzelnen Spezialisten bearbeitet werden können, ohne dass für den Einzelnen der Gesamtzusammenhang aus dem Blick gerät. Die Auswirkungen der steigenden Komplexität des eigentlichen Entwicklungsprozesses werden darüber hinaus verstärkt durch die teaminterne Komplexität, die durch die fach- und funktionsbezogenen Heterogenität der beteiligten Experten hervorgebracht wird. Auswirkungen auf Kooperation, Wissensintegration und Planung Ausgelöst durch die Flexibilisierung und steigende Komplexität des Entwicklungsprozesses im RPD, stehen Entwicklungsteams vor einer doppelten Herausforderung: Zum einen steigen die Anforderungen an die kooperative Informationsverarbeitung im Team, die bedingt sind durch die erhöhte Menge an Informationen, die wachsende Geschwindigkeit des Informationsaustauschs als auch durch die erhöhte Menge der technischen und organisatorischen Schnittstellen im RPD-Prozess. Zum anderen verstärkt die Unterschiedlichkeit der im Team vertretenen Fachdisziplinen und Unternehmensfunktionen die Anforderungen an den internen Wissensaustausch. Aus den unterschiedlichen Wissensbeständen der einzelnen Teammitglieder muss eine gemeinsame Wissensbasis entstehen, um ein von allen getragenes Vorgehen im Entwicklungsprojekt zu ermöglichen. Der gesteigerten externen Informationskomplexität steht also eine interne Wissenskomplexität gegenüber. Beide machen eine wirksame Unterstützung der Produktentwicklungsteams erforderlich, um den RPD-Prozess effizient umsetzen zu können.


37

Abb. 2.1. Externe Informations- und interne Wissenskomplexität von interdisziplinären Teams

Im Gegensatz zur externen Informationskomplexität ist die interne Wissenskomplexität für Entwicklungsteams nicht offensichtlich. Durch die Häufigkeit, Intensität und Irregularität von Änderungen hinsichtlich der Zielvorgaben, Vorgehensweisen und Randbedingungen sind Entwicklungsprojekte durch eine Dynamik gekennzeichnet, deren Konsequenzen sich in zeitlich veränderlichen, unklaren Zielvorgaben sowie unvollständigen Rahmenvorgaben und Einflussgrößen äußern. Aufgrund der hohen Anzahl der am Produktentwicklungsprozess Beteiligten, der hohen Dynamik und der starken inhaltlichen Vernetzung der einzelnen Elemente entstehen komplexe unsichere interne Wirkungszusammenhänge zwischen den einzelnen Teilprozessen. Die hohen technischen Anforderungen an die Produkte und die Komplexität der Projekte führen zu der Notwendigkeit einer interdisziplinären Zusammenarbeit, deren Erfolg maßgeblich von einer intensiven informationstechnologisch unterstützten Kommunikation abhängt. Aufgrund unvorhersehbarer Entwicklungszyklen sind häufige und schnelle Planungsprozesse notwendig, die sich an die Iterationszyklen anpassen können. Wie zahlreiche Erfahrungen aus der Praxis zeigen, werden die Herausforderungen an den teaminternen Wissensaustausch häufig unterschätzt und führen nicht selten zu suboptimalen Teamergebnissen. Hier wird eine proaktive und systematische Unterstützung erforderlich, um unsichtbare Barrieren frühzeitig zu erkennen und zu umgehen.

38


2.2.3 Kooperationsanforderungen Die Arbeitsbedingungen im RPD-Kontext zeichnen sich durch einen stark erhöhten Abstimmungsbedarf und überproportional steigende Koordinationsaufwände aus. Die Entwicklungsteams kennzeichnet eine dezentrale Teamstruktur mit hohem Selbstorganisationsgrad, in denen eine Integration von planenden und ausführenden Tätigkeiten realisiert wird. Dies bedeutet eine Abkehr von bisherigen, stark arbeitsteilig organisierten Bearbeitungsstrukturen, die den gestiegenen Innovationsund Flexibilitätsanforderungen nicht gerecht werden. Darüber hinaus sind die schnelle Bildung der Teams, die Ausbildung von Subteams innerhalb eines Entwicklungsprojekts und eine hohe Zahl von interdisziplinären Teammitgliedern Rahmenbedingungen des RPD. Kooperationszusammenhänge bilden sich nicht nur zwischen den internen (Sub-) Teams, sondern auch durch zeitweise oder kontinuierliche Kooperation mit (bzw. Integration von) Kunden- und Lieferantenteams. Dadurch ergeben sich erhöhte Anforderungen sowohl an die interne wie an die teamexterne Zusammenarbeit mit einer Vielzahl von Ansprechpartnern. Auswirkungen auf Kooperation, Wissensintegration und Planung Die Kooperation in fach- und funktionsgemischten Entwicklungsteams gestaltet sich aus den schon oben beschriebenen Gründen häufig schwierig. Der hohe Selbstorganisationsgrad, die Integration von planenden und ausführenden Tätigkeiten sowie die Anbindung an externe Kunden und Lieferanten führen zu erhöhten Anforderungen an die Kommunikationsprozesse im Team. Gleichzeitig steigt der Stellenwert der Koordination der einzelnen Arbeitsbeiträge, da die parallele Bearbeitung mehrerer konkurrierender Entwicklungsansätze ständig an den übergeordneten Entwicklungszielen ausgerichtet werden muss. Zuletzt erfordert auch die organisatorische Gliederung der Entwicklungsprojekte in Leitungs- und Subteams kontinuierliche Abstimmungsvorgänge, insbesondere um eine verlässliche Entscheidungsbasis für die Priorisierung bzw. das Verwerfen einzelner Entwicklungsansätze zu gewährleisten. Die Heterogenität von fach- und funktionsgemischten Produktentwicklungsteams verstärkt potenzielle Kooperationsprobleme, da sie eine intensive Auseinandersetzung zwischen den einzelnen Teammitgliedern erfordert. Wo dies nicht in einer konstruktiven Art und Weise gelingt, sind Störungen der Teamkooperation wahrscheinlich, die in verschiedener Ausprägung auftreten können (siehe Abb. 2.2.).


39

Abb. 2.2. Mögliche Erscheinungsbilder mangelnder Wissensintegration in interdisziplinären Teams

Verläuft die Integration des unterschiedlichen und oft gegensätzlichen Wissens nicht erfolgreich, können dafür häufig die in der Abbildung skizzierten Auslöser verantwortlich gemacht werden. Insbesondere implizites, d.h. verinnerlichtes Wissen, das nicht mit den anderen Teammitgliedern abgestimmt ist, kann nachhaltige Störungen des Wissensaustauschs auslösen. Abweichende Zielvorstellungen, fehlende begriffliche Festlegungen bzw. Klärungen von Begriffen, mangelnde Verständnissicherung und die unzureichende Nutzung des prinzipiell im Team vorhandenen Wissens können zu den dargestellten Störungen führen. Diese betreffen jedoch nicht nur den Wissensaustausch und damit die Fähigkeit des Teams, neuartige Lösungen für komplexe Entwicklungsanforderungen zu generieren. Die Barrieren des Wissensaustauschs machen sich auch in den anderen beiden Teilprozessen der Kooperation, also den Kommunikations- und Koordinationsprozessen, negativ bemerkbar. Die Effizienz der Kommunikation im Entwicklungsteam wird durch divergierende Vorstellungen von den Sachverhalten, über die man spricht, und unterschiedlich verwendeter Begrifflichkeiten genauso gemindert wie die Koordination, wenn ziel- und steuerungsrelevante Informationen nicht ausreichend ausgetauscht werden.

40


2.3 Planungsmethoden innovativer Produkte in dezentralen Teams Die im RPD angestrebte enge, interdisziplinäre Zusammenarbeit von Expertenteams setzt voraus, dass die beteiligten Experten nicht nur einen Zugriff auf den Planungs- und Ressourcenstatus in bezug auf ihre individuellen und teambezogenen Aktivitäten haben, sondern auch die Abhängigkeiten ihrer Aufgabe von den nächsten innerhalb des Prozesses zu vollziehenden Schritten abschätzen können müssen. Die kontinuierliche Dynamik des Entwicklungsprozesses durch sich ständig ändernde und von der Planung zu berücksichtigende Variablen stellt die Planung von dezentral verteilten Teams vor besondere Herauforderungen. Forschungsergebnisse zeigen, dass für die erfolgreiche Planung komplexer Entwicklungsprozesse evolutionäre Aspekte der Planung in Form von intelligenten Abstimmungsmechanismen und ein effizientes Management von Expertenkompetenzen die Planung von dezentral verteilten Teams auf der Basis adaptiver Prozesse ergänzen müssen, damit in komplexen Entwicklungsprojekten des RPD zügig hochwertige Ergebnisse erzielt werden können. 2.3.1 Grenzen einer formalen Planung für das Rapid Product Development Die formale Planung folgt dem synoptischen Planungsideal. Die Aufgabe des Planers besteht danach in einer Generierung integrierter Totalpläne, welche die planerischen Entscheidungen bei der Entwicklung innovativer Produkte zu einem kohärenten Gebilde vereinen [2.113]. Vom Planer wird die vollständige Analyse des Planungsproblems sowie die Analyse aller denkbaren Handlungsalternativen und ihrer Bewertung im Hinblick auf das von der Produktentwicklung verfolgte Ziel gefordert. Von zentraler Bedeutung ist dabei das Ziel, eine möglichst hohe Planungsintegrität zu erreichen, indem das Planungsproblem vollständig mit all seinen Interdependenzen erfasst und zu einem wohldefinierten, abgestimmten und bewussten Plan aggregiert wird. [2.67], [2.110]. Um dieses Ziel zu erreichen, wird der Versuch, hierarchisch aufgebaute, komplexe Probleme, wie es bei der Entwicklung eines Fahrzeuginnenraums gegeben ist, in einem hierarchisch aufgebauten Aufgabengefüge zu lösen, als die effizienteste Vorgehensweise betrachtet. Im Rahmen des RPD erscheint die Herausforderung, Transparenz in eine schlecht strukturierte Problemstellung durch Zerlegung des Planungsproblems in einfachere, leichter zu lösende Teilprobleme zu bringen, in dem das Problem der Entwicklung eines Fahrzeuginnenraums wohlstrukturiert, also dekomponiert wird, als nicht lösbar [2.3], [2.11].

2.3 Planungsmethoden innovativer Produkte in dezentralen Teams

41

Dies ist im wesentlichen darauf zurückzuführen, dass x die Formalisierung des Planungssystems in bezug auf die eingesetzten Kommunikationsmedien, die Prozesse und die Strukturen von einer zu hohen Bedeutung für das synoptische Planungsideal ist. x nur offiziell autorisierte Planungsverantwortliche sind die Träger der Planung und deren Abstimmung erfolgt über eine entsprechende Autoritätshierarchie mit ihren formalen Kommunikations- und Kontrollsystemen. Als Konsequenz wird die Dynamik und Flexibilität des dem Konzept des RPD folgenden Entwicklungsprozesses mehr gehemmt, denn unterstützt [2.21], [2.22], [2.83]. x nur das in quantifizierbarer Form explizierbare Wissen Eingang in die Planung findet. Implizites Wissen, z.B. in Form von intuitiven Fertigkeiten der am Produktentwicklungsprozess Beteiligten, also deren Kompetenzen, tritt gar nicht in den Vordergrund [2.83], [2.88]. x das bei der Lösung von Problemen zur Entwicklung innovativer Produkte notwendige Wissen von Experten in einem zeitraubenden Lernprozess erworben wurde. Es ist nicht, wie im Rahmen einer hierarchischen Planung notwendig, zentralisierbar. Der Problemlösungsprozess bei der Produktentwicklung basiert auf einer horizontalen Kommunikation und Abstimmung, die durch eine hierarchische Planung konterkariert wird [2.6], [2.8]. x die Ziele eines Prozesses zur Entwicklung eines innovativen Produkts werden mit der Problemlösung simultan entwickelt und nicht aus übergeordneten Zielen abgeleitet, zumal die für die Planung relevante Informationsgrundlage inadäquat, inkonsistent und verzerrt ist [2.48], [2.53], [2.59], [2.113]. Die deduktive Ableitung von Zielen im Rahmen der hierarchischen Planung erscheint damit für das RPD problematisch. Damit ist eine formale Planung im Sinne des synoptischen Planungsideals für die Planung und Steuerung von Prozessen innerhalb von RPDProjekten kritisch zu beurteilen. 2.3.2 Potenziale der evolutionären Planung für das Rapid Product Development Der Blickwinkel einer evolutionären Planung konzentriert sich auf das Phänomen der Neuerung, des Wandels und der Bewältigung dynamischer Veränderungen. Organisatorische Einheiten, wie z.B. RPD-Projektteams, sind aus der Perspektive der Planung evolvierende und entwicklungsfähige Systeme, welche die Fähigkeit besitzen, aus eigenen Kräften Neuerungen

42


und Wandel zu initiieren. Neben flacheren Hierarchien, der Betonung der Teamorientierung sowie informeller Aspekte werden Prozesse, Flexibilität und Wandel betont [2.55], [2.87]. Die hohe Dynamik und Komplexität von RPD-Projekten spiegelt sich darin wieder, dass die zu planenden Prozesse permanenten Änderungen unterworfen sind. Diese Änderungen sind auf Ereignisse innerhalb der Prozesse zurückzuführen, die ein Problem induzieren. Die Wahrnehmung eines Sachverhaltes als Problem bei der Entwicklung eines innovativen Fahrzeuginnenraums sowie die Identifikation potenzieller Handlungsmöglichkeiten sind das Ergebnis der intellektuellen Anstrengungen der Planenden. Die Komplexität von Problemen bei der Entwicklung innovativer Produkte entsteht nicht nur durch vielfältige, dynamische Wechselbeziehungen innerhalb des Entwicklungsprozesses. Sie erhöht sich vor allem durch die Berücksichtigung unterschiedlicher Perspektiven der an der Planung Beteiligten bei der Problemabgrenzung und deren Einbeziehung in den Planungsprozess. Unterschiedliche Perspektiven werden von der evolutionären Planung erwünscht, da sie vernachlässigte Sichtweisen und Problemstellungen aufdecken können, zu einer besseren Problemsicht beitragen und geeignetere Vorschläge für die Problemlösung leisten können [2.90]. Damit werden für die Lösung von Problemen bei der Entwicklung innovativer Produkte Planungsansätze benötigt, die die Fehlbarkeit des Wissens stärker berücksichtigen als es das synoptische Planungsideal vermag [2.61], [2.63], [2.78], [2.101]. Anstatt einer ganzheitlichen Lösung von Planungsproblemen verfolgt die evolutionäre Planung eine Politik der kleinen inkrementellen Schritte, um kontinuierliche und geringfügige Verbesserungen des Status quo zu erreichen. Simultan zum Problemlösungsprozess bei der Entwicklung innovativer Produkte werden Handlungsalternativen, Handlungskonsequenzen und geeignete Ziele entwickelt. Ziele werden nicht deduktiv abgeleitet, sondern rücken in den Vordergrund, wenn Entscheidungen über konkrete Handlungsalternativen notwendig sind. Eine hohe Planungsintegrität ist damit nicht oder nur schwer möglich. Vor dem Hintergrund der vielfältigen Anforderungen an die Planung bei der Lösung von Problemen, die den Entwicklungsprozess begleiten, lassen sich Entscheidungen nicht zu einem integrierten und kohärenten Gebilde zusammenfassen. Die Güte eines Plans besteht danach in der Zustimmung der an einem Entwicklungsprozess Beteiligten zu einem Plan. Planung ist danach ein Prozess des experimentellen Lernens mit dem Ziel, Fehler im Problemlösungswissen sukzessive zu eliminieren. Das für die Planung relevante Handlungswissen und die Handlungskonsequenzen haben damit den Charakter vorläufiger Gestaltungsentwürfe und nicht den Stellenwert fester Handlungsnormen [2.37], [2.74], [2.82], [2.101].


43

Damit rückt bei einer evolutionären Planung innerhalb des RPD die Frage in den Vordergrund, wie neues Wissen zur Lösung von Problemen durch eine inkrementelle Vorgehensweise generiert und bewertet werden kann. Überzeugungen, Wertvorstellungen und Weltanschauungen der Gemeinschaft der Planenden repräsentieren das strategische Wissen, das die Erkenntnisprozesse und den Pfad bei der schnellen Produktentwicklung bestimmt, indem sie als Selektionsfilter und Deutungsmuster zur Konkretisierung von Problemlösungen dienen. Auf dieser Basis erlauben negative bzw. positive Heuristiken die Identifikation von Veränderungsnotwendigkeiten und eine qualitative Veränderung der bei der Produktentwicklung verfolgten Strategie mit den entsprechenden Handlungskonsequenzen [2.101], [2.118]. Die Idee der Selbstorganisation ist für die evolutionäre Planung richtungsweisend. Eine sinnvolle Verarbeitung eines bei der Entwicklung innovativer Produkte auftretenden komplexen, neuartigen Problems ist in einer komplexitätsreduzierenden Struktur nicht möglich. Die Selbstorganisation wird als ein Strukturierungsmuster angesehen, das ein größeres Komplexitätsverarbeitungspotenzial besitzt als andere Strukturierungsmuster, wie z.B. hierarchische Planungssysteme [2.66]. Informationstechnische Werkzeuge zur Unterstützung einer evolutionären Planung von Produktentwicklungsprojekten müssen daher flexible Informations- und Entscheidungskanäle unterstützen, um projektweite Lernprozesse zu fördern, die das Fundament für die Lösung der bei der Entwicklung eines innovativen Fahrzeuginnenraums auftauchenden Problemen bilden. Die evolutionäre Planung ist wesentlich durch folgende Merkmale gekennzeichnet [2.85], [2.101]: x Innovative Lösungsansätze zur Lösung von Problemen bei der Produktentwicklung sind subjektive Konstrukte, die nach Maßgabe der Wertvorstellungen, Interessen, dem Hintergrundwissen und den Überzeugungen der an der Problemlösung bzw. dem Entwicklungsprojekt beteiligten Experten interpretiert werden. x Dezentrales, intuitives und stillschweigendes Wissen steht bei der Handhabung von Problemen im Vordergrund. Die Einbeziehung und Partizipation der beteiligten Wissensträger in den Planungsprozess ist für das Erreichen „guter“ Planungsziele notwendig. x Auf der Grundlage von Annahmen, Grundüberzeugungen und Werten wird das zur Handhabung von Problemen der Produktentwicklung notwendige Problemlösungswissen sukzessive entwickelt und orientiert sich am inkrementellen Ideal.

44


x Die sich aus der Planung entwickelnden Handlungskonzepte sind vorläufig, potenziell fehlbar und dienen als Werkzeuge, die für den Planer lediglich Orientierungscharakter haben. x Vor dem Hintergrund der Selbstorganisation vollzieht sich die Planung in Entscheidungsgremien, in denen sich die Planungs- respektive Entscheidungsträger problembezogen immer wieder neu ordnen. x Die Organisation der Planung erfolgt nicht durch eine formale Autorität. Das problembezogene Expertenwissen ist das Fundament für die Einflussnahme der Planungsträger auf die Planungsprozesse. Die Entwicklung und Implementierung von Methoden und Instrumenten zur Planung des RPD-Prozesses steht damit vor der Herausforderung das Potenzial der analytischen Planung umfassend zu nutzen und zugleich Aspekte der evolutionären Planung in die Methoden und Instrumente zu integrieren, um die mit der analytischen Planung verbundenen Probleme zu beheben. Dies bezieht sich, wie sich bei den laufenden Arbeiten gezeigt hat, nicht nur auf Fuzzy Constraint Netzwerken zur Unterstützung von Einzelentscheidungen innerhalb der Prozesse einer Produktentwicklung und die Geschäftsprozessgestaltung mit Hilfe von Referenzbausteinen zur Unterstützung von Einzelentscheidungen bzw. die Berücksichtigung dynamischer Veränderungen [2.1], [2.2], [2.70], [2.102]. 2.3.3 Kompetenzmanagement zur Unterstützung einer evolutionären Planung für das RPD Wissens- und Kompetenzmanagement haben genauer betrachtet eine lange Tradition. Sie gehen auf die Arbeiten des Wirtschaftstheoretikers Penrose in den fünfziger Jahren zurück, der in seinem Buch »Theory of the Firm« darlegte, dass der Unterschied in der ökonomischen Leistung von Unternehmen auf die internen Ressourcen zurückzuführen ist. Erfolgreiche Unternehmen verstehen es seiner Meinung nach, ihre Ressourcen optimal zur Wertschöpfung einzusetzen [2.92]. Dieser Ansatz wurde Mitte der siebziger Jahre von dem Ansatz der Harvard Business School abgelöst, allen voran von Michael Porter, der erfolgreiches, unternehmerisches Handeln als Resultat der optimalen Steuerung der fünf Marktkräfte ansah [2.96], [2.97]. Dieser Market-based-view verlor allerdings aufgrund des zunehmend dynamischeren und komplexeren Unternehmensumfeldes an Bedeutung, da die Fokussierung des Unternehmens- und Wettbewerbserfolges auf bestimmte Produkt-Markt-Positionen keinen umfassenden Erklärungsansatz mehr boten.


45

Zunehmend stehen wieder intangible Ressourcen eines Unternehmens im Vordergrund der Betrachtung (in Anlehnung an Penrose auch als Resource-based-view bezeichnet). So stellen Prahalad / Hamel fest, dass die Kernkompetenzen »the most powerful way to prevail in global competition« sind [2.98]. Der Competence-based-view als dynamischer Strategieansatz des Resource-based-view stellt v.a. die Bewertung, Entwicklung und den Einsatz der Kompetenzen in den Mittelpunkt der Betrachtung. Einen zusätzlichen Bedeutungszuwachs erhielt die Betrachtung der Wissens- und Kompetenzfelder durch zahlreiche Studien mit dem Ergebnis, dass Wissen und Kompetenzen die entscheidenden Erfolgsfaktoren für Innovationen sind [2.44], [2.45]. Sie sind somit die Grundlage für neue und einzigartige Leistungen, die Unternehmen weitreichende Wettbewerbsvorteile bringen. Sie unterliegen jedoch einer Halbwertszeit, die sich durch den ständigen Wandel immer weiter verkürzt [2.132]. Um die Nachhaltigkeit von Innovationen zu garantieren, ist deshalb nicht nur auf den Bestand der Kompetenzen, der sich v.a. in der Bewertung der vorhandenen ausdrückt, sondern vielmehr auf deren Entwicklung im Unternehmens- und Umweltkontext abzuheben. Dabei ist die Kompetenzentwicklung nicht nur auf die Erweiterung der bestehenden Ressourcen beschränkt, sondern muss ebenso den Übergang in für das Unternehmen neue und erfolgsversprechende Kompetenz- und Wissensfelder sowie das Verfolgen alternativer Entwicklungspfade berücksichtigen. Diesen Entwicklungsgedanken greift der Ansatz des Kompetenzmanagements auf. Der Begriff der Kompetenz wird in der wissenschaftlichen Literatur uneinheitlich verwendet [2.34]. Zusätzlich existiert eine Vielzahl verwandter Begriffe, die teilweise synonym verwendet werden oder Teildefinitionen des Begriffs der Kompetenz sind. Erstmalig taucht der Begriff 1965 in einem Aufsatz von Whyte auf, der Kompetenz als „die Fähigkeit eines Individuums, die gegebenen Anforderungen zur Weltbewältigung durch entsprechende Herausbildung bemeisternder Fähigkeiten des psychischen Apparates zu bewältigen“ definiert. Roth übernahm 1971 diesen Gedanken in seiner Pädagogischen Anthropologie und unterschied die vier Kompetenzbereiche in Sach- oder Fachkompetenz, Methodenkompetenz, Sozialkompetenz und Selbstkompetenz [2.103]. Diese Definitionen bewegen sich auf der Ebene des Individuums und beschreiben Fähigkeiten, die ein Mensch zur sachgerechten Bewältigung von Aufgaben benötigt sowie das Bewusstsein, für deren Erfüllung nach geltenden Maßstäben die Verantwortung zu tragen. Die Entwicklung der Kompetenzen erfolgt dabei über Lernprozesse.

46


Abb. 2.3. Definition von Kompetenzen

Innerhalb der Betriebswirtschaftslehre werden Kompetenzen als unternehmenseigene Ressourcen verstanden, die ein Unternehmen zur Erfüllung seines Geschäftszweckes benötigt [2.9]. Aufgrund des Paradigmenwechsels im strategischen Management vom „market-based view“ zum „resource-based view“ Anfang der neunziger Jahre verschiebt sich der Betrachtungsgegenstand vom Management der Individualkompetenzen zum Management der organisationalen Kompetenzen [2.98]. Diese lassen sich als Fähigkeiten, „which allow a firm to exploit these competences through innovation” definieren [2.120]. Tidd stellt heraus, dass das Management der organisationalen Kompetenzen dann sinnvoll ist, wenn die Entwicklung neuer Produkte auf Basis einer “Technology Push”- Strategie erfolgt, d.h., der Erfolg sich im Wesentlichen auf die Verwendung für den Markt neuer Technologien in den Produkten gründet. Dies lässt den Umkehrschluss zu, dass Unternehmen, die neue Produkte entwickeln wollen, ihre Kompetenzen entsprechend kennen, vernetzen, einsetzen und entwickeln müssen. Die Vernetzung von Kompetenzen im Rahmen veränderter Produktentwicklungs-, Produktions- und Fabrikstrukturen konzentrieren sich auf die Gestaltung von Schnittstellen auf der Basis partnerschaftlicher und flusssystemorientierter Beziehungen, in denen Vertrauensbeziehungen eine große Rolle spielen [2.77], [2.129], [2.130]. Im Rahmen des systemischen Projektmanagements existieren Instrumente für komplexe Veränderungsund Entwicklungsprojekte auf dies Gestaltung rekursiver Organisationsstrukturen und einer adaptiven Prozesslenkung zielen, ohne im Detail auf Gestaltungsempfehlungen einzugehen [2.107]. Für eine Detaillierung dieser Gestaltungsempfehlungen ist es notwendig, Aspekte eines informati-


47

onstechnologisch gestützten Managements von Kompetenzen in virtuellen bzw. dezentral verteilten Teams zu berücksichtigen [2.29], [2.43], [2.4]. Von besonderer Bedeutung sind hier Methoden in bezug auf die Entwicklung, Akquisition und den Transfer projektrelevanten Expertenwissens [2.12], [2.84], [2.119], [2.134].

Abb. 2.4. Definition des Kompetenzmanagements für das RPD

Vor diesem Hintergrund ist für eine iterativ, evolutionäre Planung von Entwicklungsprojekten die dem Konzept des RPD folgen von Bedeutung, wie das vorhandene Wissen kooperierender Experten bzw. deren Kompetenzen in Situationen, in denen im Prozess auftauchende Probleme schnell abgestimmt und gelöst werden müssen, genutzt werden können. 2.3.4 Das entwicklungsfähige Projektplanungssystem für das RPD Meilensteine der Entwicklung Die Ausgangsituation für eine zielorientierte Unterstützung der Iterationszyklen in allen Phasen der Produktentwicklung, die dem Konzept des Rapid Product Development (RPD) folgen, bestand darin, Planungsmethoden und -instrumente zu einem System zusammenzuführen, das eine enge Zusammenarbeit interdisziplinärer Experten-Teams, die ihre Abläufe selbst bestimmen, aus der Perspektive des Projektmanagements unterstützt. Vor dem Hintergrund der Interdisziplinarität der Teams sowie der Dynamik der RPD-Prozesse müssen die eingesetzten Planungsmethoden und

48


-instrumente in der Lage sein, die sich in den Iterationszyklen dynamisch ergebenden Anforderungen an die Lösung von Problemstellungen im Entwicklungsprozess durch die Planung berücksichtigen zu können. Die optimale Unterstützung der Experten des RPD bei der Koordination ihrer teaminternen und -übergreifenden Aktivitäten während sämtlicher Iterationszyklen des Entwicklungsprozesses stand dabei im Vordergrund. Im ersten Schritt wurde ein »Teamorientierten Projektplanungssystem« (TOPP) entwickelt, das jedem dezentralen Team die Möglichkeit bietet, die zeitliche Planung für sein Teilprojektziel auf Basis disjunktiver AllenZeitintervallrelationen selbst zu bestimmen. Die Definition teamübergreifender Schnittstellenaktivitäten erlaubt eine Vernetzung teambezogener Teilpläne, deren Aggregation zu einem Gesamtplan sowie eine kennzahlenbasierte, situationsspezifischen Bewertung dieser Pläne [2.131]. Im zweiten Schritt wurde das TOPP um Methoden zur Ressourcenplanung für dezentral operierende Entwicklungsteams und Mechanismen zur Lösung auftretender Ressourcenkonflikte erweitert. Damit ist es für die dezentral verteilten Entwicklungsteams möglich, die Abstimmung ihrer Teilpläne zu optimieren und zeitplanerische Konflikte schneller zu beseitigen [2.71]. Im dritten Schritt erfolgte eine Erweiterung des Systems um eine Planungsmanagementkomponente, die eine dezentrale Generierung, Vernetzung und Wiederverwendung von Aktivitäten und Teilprozessen auf der Basis eines Modells zur iterativen Definition von Rollen und Aufgaben erlaubt. Das Meta-Modell zur Definition generischer Prozessmodule erlaubt jedem dezentral verteilten Entwicklungsteam seine von ihm zu koordinierenden (Teil-) Prozesse bis auf die Ebene von Einzelaktivitäten über parametergetriebene Verknüpfungsregeln zu verbinden. Die Einbindung und Archivierung dieser generischen Prozessmodule als »Lessons learned« unterstützen die Entwicklungsteams bei der Planung zukünftiger Projekte [2.32], [2.72], [2.73]. Diese »Lessons learned« gewährleisten, dass das Erfahrungswissen vergangener Projekte für zukünftige Projekte genutzt werden kann. Allerdings kann dieses Erfahrungswissen nur indirekt, aus einer ex-post Betrachtung in laufende Projekte einbezogen werden. Zur Abrundung und Erhöhung des Reifegrads des bisherigen Systems wurden Möglichkeiten zur Nutzung des Erfahrungswissens der an RPDProjekten beteiligten Experten implementiert. Dazu wurde eine Komponente entwickelt, die es den Experten erlaubt, in den Iterationszyklen des RPD-Prozesses auftauchende Probleme mit Hilfen von Expertenkompetenzen schnell lösen zu können bzw. sich schnell mit anderen Experten abstimmen zu können. Das Ziel bestand darin, auf der Basis eine problemlösungsorientierte Management von Kompetenzen und der darauf


49

aufbauenden Implementierung dynamischer Abstimmungsmechanismen eine Beschleunigung von Planungsentscheidungen zu bewirken [2.19]. Abschließend wurden die bisherigen Komponenten zu einem »entwicklungsfähigen Projektplanungssystem« migriert. Funktionalitäten des »entwicklungsfähigen Projektplanungssystems« Nachfolgend werden die wesentlichen Funktionalitäten des »entwicklungsfähigen Projektplanungssystem« einschließlich einiger Hinweise hinsichtlich der technischen Realisierung dargestellt. Die dargestellten Funktionalitäten orientieren sich dabei an den besonderen Anforderungen, die das RPD an die Projektplanung stellen, beziehen sich auf x x x x x x

die parameterbasierte Verknüpfung von Aktivitäten, die Navigation in generischen Prozessmodulen, eine parametergetriebene Problemlösung, eine rollenbasierten Überwachung von Aktivitäten, die Implementierung einer Lessons Learned Datenbank und ein problemlösungsorientiertes Kompetenzmanagement.

Parameterbasierte Verknüpfung von Aktivitäten Die Verknüpfung von Aktivitäten erfolgt über Startbedingungen. Der frühest mögliche Beginn einer Aktivität kann von beliebig vielen Startbedingungen abhängig gemacht werden, welche „logisch und“-verknüpft sind. Die Startbedingungen können sich auf die Parameterwerte beliebiger anderer Aktivitäten beziehen. Eine Aktivität ist somit lediglich von den relevanten Eigenschaften ihrer Vorgänger abhängig, wodurch ermöglicht wird, dass eine Aktivität bereits begonnen werden kann, wenn die Durchführung ihrer Vorgänger lediglich im relevanten Maße erfolgt ist. Sind alle Startbedingungen einer Aktivität erfüllt, so wird der in jeder Aktivität enthaltene Basisparameter Kann beginnen automatisch durch Durchführung einer Parameteränderungsaktion (ChangeParameterAction) auf den Wert Ja gesetzt. In Abb. 2.5 ist der Beginn von Aktivität 3 davon abhängig, dass der IntegerRangeParameter p1 in Aktivität 1 einen Wert größer 50 und der Parameter p3 in Aktivität 2 den Wert Ja hat.

50


Abb. 2.5. Schematische Darstellung der Verknüpfung von Aktivitäten über Startbedingungen

Wenn der Beginn einer Aktivität direkt oder indirekt von sich selbst abhängt, entsteht ein Loop. In dem in Abb. 2.6 dargestellten Beispiel kann die Durchführung von Aktivität 3 unter anderem erst beginnen, wenn Aktivität 1 den Zustand p1>50 erreicht hat. Der Beginn von Aktivität 1 hängt jedoch davon ab, dass Aktivität 3 bereits den Zustand p5>70 hat. Ist dies nicht von Anfang an gegeben, wird keine der beiden Aktivitäten jemals beginnen können, da die Startbedingungen der jeweils anderen Aktivität niemals erfüllt werden. Es kommt so zu einem Deadlock, wodurch der weitere Projektverlauf blockiert ist.

Abb. 2.6. Verknüpfung von Startbedingungen mit Loop

Da darüber hinaus Loops in Projektplänen außer bei Iterationen nicht auftreten und zur Abbildung von Iterationen der bei der parametergetrieben Problemlösung implementierte Mechanismus vorhanden ist, sind Iterationen verboten. Vor dem Einfügen einer Bedingung wird geprüft, ob dies einen Loop verursachen würde. In diesem Falle wird das Einfügen nicht zugelassen. Ein Projekt (Project) ist in eine beliebige Anzahl adaptiver Prozesse (Adaptable Process) unterteilt. Diese bilden eine baumförmige Prozesshie-


51

rarchie, welche der Strukturierung der enthaltenen Aktivitäten (Activity) dient (vgl. Abb. 2.7.).

Abb. 2.7. Projektstruktur

Abb. 2.8. Vererbungshierarchie von Parametern

52


Parameter bilden Eigenschaften und den Status von Aktivitäten ab. Wie in Abb. 2.8 dargestellt hat ein Parameter einen Namen, einen Beschreibungstext und einen Typ. Um dem Benutzer zu ermöglichen, möglichst alle Eigenschaften und Zustände einer Aktivität durch Parameter abzubilden, werden verschiedene Parametertypen zur Verfügung gestellt. Die in der prototypischen Umsetzung des »entwicklungsfähigen Projektplanungssystems« implementierten Parametertypen sind in der folgenden Abb. 2.9 dargestellt: Klassenname Abbildbare Werte BooleanParameter Ja/Nein IntegerRangeParameter Ganzzahliger Wert aus einem zu definierenden Zahlenbereich PercentParameter Ganzzahliger Wert zwischen 0 und 100 DataSetParaemter Beliebiges Objekt einer Menge der benutzerdefinierten Objekte StringSetParameter Zeichenkette aus der Menge benutzerdefinierter Zeichenketten Abb. 2.9. Implementierte Parameter im »entwicklungsfähigen Projektplanungssystem«

Jeder Aktivität werden bei der Erzeugung drei Basisparameter zugeordnet: x Kann beginnen (BooleanParameter): Beschreibt, ob alle Startbedingungen der Aktivität erfüllt sind. x Hat begonnen (BooleanParameter): Beschreibt, ob die Durchführung der Aktivität bereits begonnen hat. x Fertig (%) (PercentParameter): Beschreibt, zu wie viel Prozent die Durchführung der Aktivität bereits erfolgt ist. Außerdem können einer Aktivität beliebig viele benutzerdefinierte Parameter zugeordnet werden, um spezifische Eigenschaften und Zustände einer Aktivität zu beschreiben. Vor dem Hintergrund der parametergetriebenen Verknüpfung von Aktivitäten ist der Beginn von Aktivitäten vom Fortschreiten bei der Durchführung der Vorgängeraktivitäten abhängig. Daher kann auch der Zeitraum, in dem zur Durchführung einer Aktivität eine bestimmte Ressource benötigt werden wird, nicht genau vorhergesehen werden. Daher wurde im »entwicklungsfähige Projektplanungssystem« ein Mechanismus implementiert mit dem eine Ressource in Abhängigkeit von Bedingungen automatisch


53

zugeordnet werden kann. Der Verantwortliche der Aktivität legt hierzu Bedingungen fest, von denen die Nutzung der Ressource abhängt. Sind alle Bedingungen erfüllt, so wird die Ressource durch Ausführung einer Ressourcenzuordnungsaktion (AllocateRessourceAction) automatisch der Aktivität zugeordnet. Sollte im Projektverlauf vor der automatischen Zuordnung der geeignete Belegungszeitraum absehbar werden, so kann die Ressource auch nachträglich manuell zugeordnet werden. Dies ist sinnvoll, da zur frühzeitigen Auflösung von Ressourcenkonflikten die Zuordnung von Ressourcen möglichst früh erfolgen muss. Darüber hinaus war es notwendig, die Lösung von Ressourcenkonflikten entsprechende zu überarbeiten. Ein Ressourcenkonflikt tritt auf, wenn eine Ressource mindestens zwei Aktivitäten zugeordnet ist und sich dabei mindestens zwei Belegungszeiträume überschneiden. Das Vorhandensein von Ressourcenkonflikten kann vom Projektplanungstool durch Betrachtung der Start- und Endzeitpunkte sx und ex ermittelt werden (vgl. Abb. 2.10.).

Abb. 2.10. Ressourcenkonflikte

Das Auftreten eines Ressourcenkonfliktes wird den Verantwortlichen der vom Konflikt betroffenen Aktivitäten in der Detailansicht der jeweiligen Aktivität angezeigt. Die Auflösung des Konflikts wird durch folgende Strategien ermöglicht: x Entfernen der Ressourcenzuordnung x Ändern des Zuordnungszeitraums x Eskalationsmechnismen zur Lösung des Ressourcenkonflikts Bei der Entfernung einer am Konflikt beteiligten Aktivität hebt der Verantwortliche seine Ressourcenzuordnung freiwillig auf. Da die Aufhebung freiwillig geschieht und keine anderen Projektbeteiligten dadurch negativ beeinträchtigt werden, ist hierfür keine Zustimmung der anderen Beteiligten erforderlich.

54


Im Rahmen einer Änderung des Zuordnungszeitraums verkürzt oder verschiebt einer der Konfliktbeteiligten freiwillig seine Ressourcenzuordnung in einen Zeitraum, in dem die Ressource nicht belegt ist. Auch hierbei treten keine negativen Effekte für andere Projektbeteiligte auf, was deren Zustimmung überflüssig macht. Bei Ressourcenkonflikten, bei denen kein Beteiligter auf die Belegung der Ressource im Konfliktzeitraum freiwillig verzichtet, müssen Konfliktlösungsstrategien angewendet werden, welche nicht konsensfähig sind, da Konfliktbeteiligte gegen ihren Willen auf die Verwendung der Ressource verzichten müssen. Für diesen Fall, in dem die oben genannten Strategien zu keinem Ergebnis führen, kann in letzter Instanz eine Lösung des Ressourcenkonflikts durch Eskalation erzwungen werden. Hierbei wird der Projektleiter herangezogen, um die Ressource einem Konfliktbeteiligten zuzuweisen. Da der Projektleiter einen umfassenden Überblick über das Projekt haben sollte, ist er am ehesten geeignet, auf diese Weise den Konflikt im Sinne des Erfolgs des Gesamtprojekts aufzulösen. Navigation in generischen Prozessmodulen Die Navigation innerhalb der generischen Prozessmodule kann sowohl über hierarchische Strukturen als auch über eine Teilnetzdarstellung erfolgen.

Abb. 2.11. Detailansicht einer Aktivität

Die Navigation durch die vorhandenen Datenobjekte über hierarchische Strukturen erfolgt über die Navigationsleiste im linken Frame des Fensters


55

(Abb. 2.11.). Die Daten sind hierarchisch nach Kategorien strukturiert. Durch Klicken auf den Namen eines Datenobjekts im Kategorienavigator wird im rechten Frame die Detaildarstellung des jeweiligen Objekts angezeigt. Des Weiteren steht ein History – Feld zur Verfügung, mit dessen Hilfe bereits angezeigte Kategorien direkt annavigiert werden können. Die Detailansicht des jeweiligen Objekts bietet die mit diesem in Zusammenhang stehenden Funktionalitäten an. Außerdem ist bei den Detailansichten vieler Objekttypen eine weitere Navigation zu den mit dem Objekt in Zusammenhang stehenden Objekten möglich. So kann beispielsweise über die Detailansicht von Aktivitäten direkt zu deren Vorgängern und Nachfolgern sowie dem übergeordneten, adaptiven Prozess navigiert werden. Eine weitere Navigationsmöglichkeit bietet die Teilnetzdarstellung von Aktivitätsnetzen. Von der Detaildarstellung einer Aktivität aus kann in die Teilnetzdarstellung gewechselt werden. Diese zeigt ausgehend von der anzuzeigenden Aktivität (Viewpoint) deren Vorgänger- und Nachfolgeaktivitäten an. Diese werden in Beziehungsebenen unterteilt angezeigt, wobei der Projektverlauf von links nach rechts dargestellt ist. Durch Klicken auf eine der dargestellten Vorgänger- oder Nachfolgeaktivitäten kann in deren Teilnetzdarstellung gewechselt werden, durch Klicken auf das + selbst wird in die Detailansicht der Aktivität gewechselt (Abb. 2.12.). Diese Form der Darstellung hat den Vorteil, dass sie mit verschachtelten HTML – Tabellen abgebildet werden kann, und daher keine Notwendigkeit besteht, browserseitig aktive Inhalte zu verwenden. Allerdings führt die mögliche Mehrfachdarstellung von Aktivitäten neben einer besseren linearen Lesbarkeit auch zu einer gewissen Redundanz.

56


Abb. 2.12. Navigation über Teilnetzdarstellung

Parametergetriebene Problemlösung Maßnahmen zur Qualitätsprüfung- und Sicherung werden in der Projektplanung in der Regel in Form von Iterationen abgebildet. Hierbei werden einige Aktivitäten durchgeführt und danach das Ergebnis geprüft. Stellt sich dabei heraus, dass das erzielte Ergebnis nicht zufriedenstellend ist, so werden Aktivitäten so lange erneut durchgeführt, bis eine zufriedenstellende Lösung erzielt wurde. Da im »entwicklungsfähigen Projektplanungssystem« die Aktivitäten, wie zuvor dargestellt, über Startbedingungen verknüpft sind, ist die Abbildung von Iterationen auf diese Weise nicht möglich, da eine solche Iteration einen Loop darstellen würde. Stattdessen wird ein Mechanismus zur Verfügung gestellt, der Loops vermeidet und frühzeitiges Auffinden und Lösen von Problemen besser unterstützt.


57

Abb. 2.13. Vereinfachte Darstellung eines Prozesses mit Iteration zur Qualitätssicherung

Der Problemlösungs- und Qualitätssicherungsmechanismus des »entwicklungsfähigen Projektplanungssystems« ermöglicht jedem Verantwortlichen einer Aktivität, bei der Durchführung der Aktivität gefundene Probleme sofort nach deren Auftreten bekannt zu geben und zu dokumentieren. Gezielte Qualitätsprüfungen können als gewöhnliche Aktivitäten abgebildet werden, deren Abschluss vom Erfolg der durchzuführenden Prüfung abhängt.

Abb. 2.14. Vereinfachte Darstellung eines Prozesses ohne Iteration zur Qualitätssicherung

Derjenige, der ein Problem identifiziert, postet es ähnlich wie in einem Forum (Abb. 2.15.). Ein solches Problem-Posting enthält einen Betreff, einen Problembeschreibungstext, eventuell einen Kommentar und falls möglich einen Lösungsvorschlag. Außerdem können die Vorgängeraktivitäten ausgewählt werden, bei denen der Identifizierer des Problems die Ursache des Problems vermutet. Das Problemposting wird dann mit der Aktivität verknüpft, in der das Problem entdeckt wurde. Als vom Problem betroffen können die Verantwortlichen von Aktivitäten angesehen werden, deren Aktivitäten Vorgänger oder Nachfolger der Aktivität sind, in der das Problem gefunden wurde. Vorgänger sind mögliche Verursacher des Problems und Nachfolger können vom Problem betroffen sein, weil die Problembehebung den Projektverlauf verändern und verzögern kann. Die Betroffenen werden in Abhängigkeit von ihrere Rolle in der Detailansicht der jeweiligen Aktivität sowie ihrer To Do – Liste über das Vorhandensein des Problems informiert und können durch Anfü-

58


gen von Kommentaren zum Problem sowie von Lösungsvorschlägen zur Problemlösung beitragen. Hat der Problemverursacher eine Lösung für das Problem gefunden, so muss er die Problemlösung dokumentieren. Danach wird aus den beim Problemlösungsvorgang von den beteiligten eingegebenen Daten eine Dokumentationsdatei generiert, welche an die Aktivität angehängt wird, in der das Problem entdeckt wurde. Daraufhin werden die während der Problemlösung in die Datenbank geschriebenen Daten gelöscht. Die so entstandene Dokumentation findet ebenfalls Berücksichtigung bei der Lessons Learned Datenbank

Abb. 2.15. Erstellung eines Problempostings

Bei der Durchführung der Problemlösung kann es zu Auswirkungen auf Nachfolgeaktivitäten kommen. Wird beispielsweise in der Aktivität Erstellung CAD-Modell nach der Aktivitätsbeendigung ein Problem entdeckt, so ist es nötig, das CAD-Modell zu überarbeiten. Hierzu wird der Basisparameter Fertig (%) vom Wert 100 auf einen geringeren Wert zurückgesetzt, der dem geschätzten Durchführungsgrad der Aktivität entspricht. Auch betroffene benutzerdefinierte Parameter, wie zum Beispiel der Parameter Statische Berechnungen durchgeführt, müssen auf den Anfangswert Nein zurückgesetzt werden, da die zugrundeliegenden Tätigkeiten erst noch erneut durchgeführt werden müssen.


59

Diese Parameteränderungen führen dazu, dass zuvor erfüllte Startbedingungen der Nachfolgeaktivitäten nun nicht mehr erfüllt sein könnten. Ist dies der Fall, so wird dies durch die Aktivitätsanalyse festgestellt und den betroffenen Aktivitätsverantwortlichen visualisiert. Möglicherweise entstehender erhöhter Abstimmungsbefard kann mit Hilfe des in Kap. 4.3 entwickelten »teamorientierten Kommunikationssystems für vernetztes Arbeiten« befriedigt werden. Steht nun fest, dass die Überarbeitung des CAD-Modells auch Auswirkungen auf Nachfolgeaktivitäten hat, so werden dort analog zur Aktivität Erstellung CAD - Modell ebenfalls Parameteränderungen notwendig. Auf diese Weise ziehen sich die bei der Problemlösung entstandenen Änderungen ausgehend vom Problemverursacher im Projektfluss nach hinten durch, bis sich alle betroffenen Aktivitäten wieder in einem konsistenten Zustand befinden. Rollenbasierte Überwachung von Aktivitäten Das »entwicklungsfähige Projektplanungssystem« führt vor der Darstellung jeder Aktivität eine Statusanalyse durch. Werden hierbei Unstimmigkeiten festgestellt, so werden im Statusfeld der Detaildarstellung der Aktivität Warnmeldungen angezeigt (vgl. Abb. 2.16.). Aufgrund dieser Warnmeldungen kann der Verantwortliche der Aktivität entscheiden, wie er darauf reagieren möchte.

Abb. 2.16. Warnmeldungen in Detailansicht einer Aktivität

Jeder Projektbeteiligte hat die Möglichkeit, die Parameterwerte seiner Aktivitäten im Rahmen derer Wertebereiche frei zu setzen. Dies eröffnet

60


jedoch die Möglichkeit, logisch unsinnige Parameterwerte zu setzen. Außerdem kann es aufgrund von bedingungsgetriggerten, automatischen Änderungen des Basisparameters Kann beginnen zu unlogischen Zuständen kommen. Von dem »entwicklungsfähigen Projektplanungssystem« werden die folgenden unlogischen Zustände erkannt: x Startbedingungen erfüllt, aber Basisparameter Kann beginnen=Nein x Startbedingungen nicht erfüllt, aber Basisparameter Kann beginnen=Ja x Basisparameter Hat begonnen=Ja, aber Basisparameter Kann beginnen=Nein x Basisparameter Fertig (%)>0, aber Basisparameter Kann beginnen=Nein x Basisparameter Fertig (%)>0, aber Basisparameter Hat begonnen=Nein Mögliche Ursachen des Auftretens und die zu erwartende Benutzerreaktion auf die Bekanntgabe des unlogischen Zustands soll an dem in Abb. 2.17 dargestellten Beispiel erläutert werden: Startbedingungen nicht beginnen=Ja Mögliche Ursachen Falsche Benutzereingabe

erfüllt,

Die Startbedingungen sind nicht mehr erfüllt, da Parameterwerte, auf welche sich eine oder mehrere Startbedingungen beziehen, ihren Wert geändert haben. Dies kann auftreten, wenn eine Vorgängeraktivität aufgrund eines Problems teilweise erneut durchgeführt werden muss und deshalb einige Parameter zurückgesetzt werden. Ein Beispiel hierfür wäre das Herabsetzen des Wertes des Basisparameters Fertig (%).

aber

Basisparameter

Kann

Erwartete Benutzerreaktion Benutzer korrigiert Parameterwert Der Benutzer prüft, inwiefern die Änderungen in der Vorgängeraktivität Auswirkungen auf die eigene Aktivität haben. Es empfiehlt sich, Kontakt zum Verantwortlichen der Vorgängeraktivität aufzunehmen. Falls sich daraus ergeben sollte, dass die eigene Aktivität ganz oder teilweise erneut durchgeführt werden muss, sind die betroffenen Parameterwerte zu ändern, beispielsweise muss der Wert des Parameters Fertig (%) verringert werden.

Abb. 2.17. Beispiel für einen unlogischen Zustand

Der Verantwortliche einer Aktivität hat die Möglichkeit, benutzerdefinierte Parameter seiner Aktivität zu löschen. Basisparameter können zwar nicht explizit gelöscht werden, jedoch kann ein Verantwortlicher die ge-


61

samte Aktivität löschen, wodurch auch die Basisparameter, welche durch eine Kompositionsreferenz verknüpft sind, gelöscht werden. Das Löschen von Parametern und Aktivitäten ist zwingend notwendig, um die für die Verknüpfung generischer Prozessmodule notwendige Flexibilität zu erreichen. Das Löschen führt jedoch zu Problemen, sobald Bedingungen von Nachfolgeaktivitäten darauf verweisen. Beim Löschen von Parametern werden daher auch die darauf verweisenden anderen Bedingungen gelöscht. Daher wird eine RemovedConditionMessage pro gelöschter Bedingung mit den Aktivitäten verknüpft, welche von der Löschung betroffen sind. Bei der Zustandsanalyse einer Aktivität werden vorhandene RemovedConditionMessages ausgewertet und bei der Detaildarstellung der Aktivität mit Textmeldung und Warnsymbol dargestellt. Welche Bedingungen gelöscht wurden, wird in der Startbedingungsübersicht angezeigt. Sobald der Verantwortliche in Abhängigkeit von seiner Rolle die Kenntnisnahme bestätigt, wird auch die entsprechende RemovedConditionMessage gelöscht. Problemanalyse in Aktivitäten Bei der Problemanalyse werden Vorgänger- und Nachfolgeaktivitäten rekursiv nach bekannt gegebenen Problemen durchsucht. In Vorgängeraktivitäten aufgetretene Probleme sind relevant für die Durchführung der Aktivität, da deren Lösung voraussichtlich zu Nacharbeiten in Vorgängeraktivitäten führt oder sogar zu Änderungen in der vor der Aktivität liegenden Projektstruktur, von der die Aktivität abhängt. Probleme in Nachfolgeaktivitäten einer Aktivität können relevant sein, da die Ursache des Problems möglicherweise in der Aktivität selbst oder in einer ihrer Vorgängeraktivitäten liegt. Probleme werden in der Detailansicht von Aktivitäten mit Warnmeldungen- und Symbolen kenntlich gemacht, und die Funktionalitäten zur Problemlösung werden zur Verfügung gestellt. To Do – Liste und Überwachung von Aktivitäten Die To Do – Liste bietet jedem Projektbeteiligten in Abhängigkeit von seiner Rolle eine Übersicht über den Status der Aktivitäten, für deren Durchführung er verantwortlich ist. Die Darstellung enthält die Werte der Basisparameter (Kann beginnen, Hat begonnen, Fertig (%)) jeder Aktivität, zeigt vorhandene Ressourcenkonflikte an und informiert über das mögliche Vorhandensein von Problemen (vgl. Abb. 2.18.). Besteht bei einer Aktivität Handlungsbedarf, beispielsweise aufgrund eines vorhandenen Ressourcenkonflikts oder aufgrund gefundener Unstimmigkeiten bei der Statusanalyse, so wird die Aktivität in der Liste mit dem Warnsymbol ( )

62


gekennzeichnet. Ist die Aktivität von einem Problem in einer anderen Aktivität betroffen, da sie diese als direkten oder indirekten Vorgänger oder Nachfolger hat oder steht eine Aktivität im Verdacht, ein Problem zu verursachen, so wird auch sie mit dem Warnsymbol gekennzeichnet. Von der To-Do–Liste aus kann zur Detaildarstellung der jeweiligen Aktivitäten navigiert werden, um weitere Informationen über den Status zu erhalten. Steht ein Projektbeteiligter vor der Frage, welche Aktivität er als nächstes durchführen soll, so kann er sich ad hoc für eine geeignete Aktivität entscheiden. Die zur Durchführung geeigneten Aktivitäten sind durch keinerlei Warnsymbole gekennzeichnet und sämtliche Startbedingungen sind erfüllt (Parameter Kann beginnen=Ja).

Abb. 2.18. To- Do-Liste

Benutzer können für sie relevante Aktivitäten mit Hilfe des »entwicklungsfähigen Projektplanungssystems« überwachen lassen. Hierzu erstellt der Benutzer eine Benachrichtigungsaktion (SendMessageAction). Sobald die zugrundeliegenden Bedingungen für die Werte der gewählten Parameter der zu überwachenden Aktivität erfüllt sind, wird die Aktion ausgeführt. Eine solche Benachrichtigung enthält eine editierbare Betreffzeile sowie einen editierbaren Beschreibungstext und wird bis zur Auslieferung in der Datenbank aufbewahrt. Aktuelle Zustandsinformationen der Aktivi-


63

tät werden vor dem Versenden der Benachrichtigung vom »entwicklungsfähigen Projektplanungssystem« hinzugefügt. Lessons Learned Datenbank Beim Abschließen eines Projektes werden alle mit dem Projekt zusammenhängenden Daten in der Lessons Learned Datenbank archiviert. Hierzu werden mit dem Projekt in Zusammenhang stehende Objekte wie enthaltene adaptive Prozesse und Aktivitäten in der Datenbank als abgeschlossen gekennzeichnet. Parameterwerte von Aktivitäten werden auf den Anfangswert zurückgesetzt. Diese Daten können bei späteren Projekten als Vorlage herangezogen werden. Dadurch kann auf bei der Durchführung vergangener Projekte bereits gemachten Erfahrungen aufgebaut werden. Da Projekte stets neuartig und einmalig sind, ergibt es jedoch keinen Sinn, ganze, bereits abgeschlossene Projekte als Vorlage heranzuziehen. Stattdessen können Teile (Aktivitäten) von Projekten ausgewählt werden, die im neuen Projekt ähnlich sind. Wird eine in der Lessons Learned Datenbank enthaltene Aktivität als geeignet angesehen, so kann diese kopiert und ins neue Projekt eingefügt werden. Hierzu stehen zwei Möglichkeiten zur Auswahl. Beim Kopieren einer einzelnen Aktivität wird lediglich die ausgewählte Aktivität zusammen mit den ihr direkt zugehörigen Objekten (Parameter, Dokumentation) kopiert und in einen adaptiven Prozess des neuen Projekts eingefügt. Jedoch besteht auch die Möglichkeit jedes generische Prozessmodul, also die Aktivitäten mitsamt ihrer Vorgänger und allen Verknüpfungen zu kopieren, da die Durchführung einer Aktivität erst möglich ist, wenn die Vorgängeraktivitäten dafür die Vorraussetzungen geschaffen haben. Das Duplizieren persistenter Objekte in der Datenbank erfolgt durch Aufruf der Methode createCopy() der Klasse DataObject. Sind die entsprechenden Daten ins neue Projekt als Kopie eingefügt, so können diese beliebig bearbeitet und angepasst werden. Von besonderer Bedeutung ist hier das Anhängen von Dokumenten. Projekten, adaptiven Prozessen und Aktivitäten können Dokumente als Dateien zugeordnet werden. Der Dateiupload erfolgt unter Verwendung der kostenlosen Bibliothek JSPSmartUpload. Diese Bibliothek übernimmt die Annahme der vom Browser gesendeten Multipart-Daten und bietet die Möglichkeit, Dateien anhand der Dateiendung oder durch Beschränkung der maximalen Dateigröße vom Upload auszuschließen. Erlaubte Dateiendungen und maximale Dateigröße können in der Konfigurationsdatei web.xml des »entwicklungsfähigen Projektplanungssystems« festgelegt werden.

64


Problemlösungsorientiertes Management von Kompetenzen Die im Verlauf von RPD-Projekten ad-hoc auftauchenden Probleme, können im »entwicklungsfähigen Projektplanungssystem« einzelnen Aktivitäten bei ihrem Auftreten zugeordnet werden. Damit existiert zwar für den für die Aktivität verantwortlichen Projektmitarbeiter ein Hinweis auf die Existenz eines Problems, aber für den Fall, dass er dieses Problem nicht selbst lösen kann, muss er in die Lage versetzt werden, nach entsprechenden Kompetenzträgern zu suchen, die ihn unterstützen, sein Problem zu beseitigen. Daher wurde in das »entwicklungsfähige Projektplanungssystem« ein dezentrales Kompetenzmanagemt integriert. Dezentrales Kompetenzmanagement Der Nutzen eines effektiven Kompetenzmanagement zur Unterstützung der Lösung von aufgetauchten Problemen hängt stark vom vorhandenen Datenbestand ab. Daher lag ein besonderer Schwerpunkt auf der Frage, wie es am ehesten möglich ist, einen aktuellen, möglichst umfassenden Datenbestand zu erreichen und auf Dauer zu erhalten. Des weiteren war darauf zu achten, dass dieser Teil des »entwicklungsfähigen Projektplanungssystems« mit einem geringem Administrationsaufwand verbunden ist. Die Kompetenzen aller am RPD-Prozess Beteiligten zu erfassen, qualitativ zu bewerten und den Datenbestand dauerhaft aktuell zu halten, ist bei einer zentralen Lösung mit hohem Aufwand verbunden. Stattdessen wurde ein dezentraler Ansatz gewählt: Jeder Kompetenzträger kann selbst neue Kompetenzen anlegen oder sich bereits im »entwicklungsfähigen Projektplanungssystem« bestehende Kompetenzen zuordnen. Dadurch verringert sich der zentrale Administrationsaufwand deutlich. Anders verhält es sich bei der Kategorisierung von Kompetenzen. Eine sinnvolle Gliederung des gesamten Kompetenzkontingentes erfordert ein hohes Maß an Planung. Könnte jeder Teilnehmer auch selbst Kategorien anlegen, würde die Struktur allmählich immer redundanter und unübersichtlicher. Um dies zu vermeiden, wurde das Anlegen, Löschen und Ändern von Kategorien und Themenfeldern auf die kleine Menge von Teilnehmern mit Administrationsrechten beschränkt. Sollte ein Benutzer einmal keine geeignete Kategorie für eine neu anzulegende Kompetenz finden, muss er diese bei einem Teilnehmer mit Administrationsrechten beantragen.


65

Verwaltung von Kompetenzen Für die Verwaltung von Kompetenzen wird der RPD-Experte im »entwicklungsfähigen Projektplanungssystem« in die Lage versetzt, die von ihm beherrschten eigenen Kompetenzen zu spezifizieren, mit einer Kurzbeschreibung zu versehen und zu verschlagworten. Zur Untersützung der Verschlagwortung steht hier ein Thesaurus zur Verfügung, mit dessen Hilde die bereits vorgenommene Verschlagwortung durch weitere Einträge ergänzt werden kann. Zur weiteren Spezifikation der Kompetenz kann der RPD-Experte wichtige Dokumente hinterlegen. Darüber hinaus ordnet der RPD-Experte seine Kompetenzen geeigneten Themenfeldern und Kategorien zu, um so die Voraussetzungen dafür zu schaffen, dass eine strukturierte Darstellung und Navigation im verfügbaren Kompetenzbestand möglich ist. Wie in Abbildung 2.19 zu sehen ist, wird eine neu angelegte Kompetenz in dem Profil des RPD-Experten hinterlegt. Ferner kann der Experte seine Kompetenzen mit Projekten und Aktivitäten verknüpfen, in denen sie gefordert wurden. Damit werden verschiedene Möglichkeiten zu einer intuitiven Navigation im Kompetenzbestand eröffnet.

Abb. 2.19. Individuelle Spezifikation der Kompetenzen durch die RPD-Experten bzw. Projektmitarbeiter

66


In Abbildung 2.20 ist beispielhaft zu sehen, dass eine Kompetenz von mehreren RPD Experten beherrscht wird und in einem Projekt zum Einsatz gekommen ist. Einen weiteren Zugang zu dem Kompetenzbestand erhält der Nutzer durch die in Abbildung 2.21 (links) dargestellte Navigation über die vorhandene Kategorienstruktur, die gegebene Themenfeldstruktur oder den Schlagwortkatalog, der auf Basis der Spezifikation der Kompetenzen dynamisch generiert wird. Darüber hinaus werden für die Identifikation von Kompetenzträgern Suchalgorithmen zur Verfügung gestellt. Das in Abbildung 2.21 (rechts) dargestellte Suchergebnis für eine Kompetenz umfasst das der Kompetenz zugeordnete Themenfeld, die Kompetenzträger, die Kompetenzkategorien, den Überblick, in welchen Aktivitäten bzw. Projekten die Kompetenz eingesetzt wurde und welche Dokumente in bezug auf die Kompetenz hinterlegt wurden. Auf Basis identifizierter, relevanter Kompetenzen und der existierenden Verknüpfungen kann damit weiter navigiert werden.

Abb. 2.20. Visualisierung der Vernetzung von Kompetenzen, Experten und Projekten


67

Abb. 2.21. Expertensuche zur Lösung von ad-hoc in Aktivitäten aufgetauchten Problemen

Die Integration der Suchmaschine »Apache Lucene« erlaubt darüber hinaus den Zugang zu Kompetenzen über Dokumente (vgl. Abb. 2.22.) Hierbei wird indirekt durch Volltextsuche in den von den RPD-Experten hinterlegten Dokumenten auf die Kompetenzen zurückgeschlossen. Der Vorteil dieser Art der Suche ist, dass weitere Kompetenzen identifiziert werden können, auch wenn keine explizite Verschlagwortung bei der ursprünglichen Spezifikation der Kompetenzen vorgenommen wurde.

68


Abb. 2.22. Indirekte Expertensuche über mit einer Kompetenz verknüpfte Dokumente

2.3.5 Zusammenfassung und Ausblick Zur Konzeption, Entwicklung und Implementierung eines »entwicklungsfähigen Projektplanungssystems«, die Möglichkeiten zur regelbasierten Verknüpfung von Aufgaben (Aktivitäten) und Rollen (Verantwortlichen) in generischen Prozessmodulen bietet, wurden zunächst die Anforderungen an die Modellierung von RPD-Prozessen ermittelt. Diese wurden zum einen aus den spezifischen planungsrelevanten Randbedingungen und Anforderungen des RPD abgeleitet. Zum anderen wurde darauf geachtet, dass die Anforderungen so spezifiziert werden konnten, dass eine spätere informationstechnologische Realisierung und Integration die bereits in den vergangenen Förderperioden entwickelten TOPP-Komponenten nicht konterkariert. Im Rahmen der informationstechnologischen Realisierung und Integration des »entwicklungsfähigen Projektplanungssystems« wurde Wert darauf gelegt, dass sowohl die Verknüpfung von Aktivitäten in generischen Prozessmodulen, als auch die Steuerung bzw. ein flexibles Management der Prozesse intuitiv möglich war. Die Verknüpfung der Aktivitäten er-


69

folgt zum einen über drei grundlegende Parameter („kann beginnen“, „hat begonnen“ und „fertig %“) und zum anderen über frei definierbare Parameter, um spezifische Eigenschaften einer Aktivität adäquat beschreiben zu können. Auf der Basis dieser Art der Verknüpfung von Aufgaben in RPD-Prozessen war es notwendig, grundlegende Funktionalitäten zur rollenbasierten Steuerung der RPD-Prozesse in das »entwicklungsfähige Projektplanungssystem« zu implementieren. Neben der Navigation in RPDProzessen über Detailansichten von Aktivitäten und über Teilnetzdarstellungen waren die parametergetriebenen Problemlösungsmechanismen und die rollenbasierte Überwachung von Aktivitäten von besonderer Bedeutung. Durch Realisierung und die Implementierung einer »Lessons Learned Datenbank« ist es möglich, bei der Definition von Prozessen in neuen RPD-Projekten auf die in vorherigen Projekten gesammelten und dokumentierten Erfahrungen auf Teilprozess- und Prozessmodulebene zurückzugreifen. Mit der informationstechnischen Realisierung eines problemlösungsorientierten Managements von Kompetenzen ist es möglich, Unterstützungsmechanismen für in RPD-Projekten ad-hoc auftauchende Probleme bereitzustellen sowie RPD-Experten in die Lage zu versetzen, sich schnell und dynamisch abzustimmen. Dazu wurde ein dezentrales Kompetenzmanagement konzipiert und in das »entwicklungsfähige Projektplanungssystem« integriert. RPD-Experten können damit zum einen ihre Kompetenzen spezifizieren, verwalten und einzelnen Projekten bzw. Aktivitäten in denen sie benötigt werden, zuordnen. Zum anderen ermöglicht die Integration von verschiedenen Navigationsmöglichkeiten in der Kompetenzstruktur von Projekten, von Suchmöglichkeiten und von einer Visulsierung der Vernetzung von Kompetenzen, Experten, Projekte sowie Aktivitäten eine schnelle Identifikation von Experten, die zu einer Problemlösung benötigt werden. Mit dem »entwicklungsfähigen Projektplanungssystem« ist ein Werkzeug entstanden, dass die Planung von RPD-Projekten effizient und effektive unterstützt, in dem es die Möglichkeiten, die eine evolutionäre Planung bietet, ausschöpft. Darüber hinaus bietet das »entwicklungsfähige Projektplanungssystem« das Potenzial, Konzepte zu unterstützen, die im Innovationsmanagement zur Zeit diskutiert werden, wie z.B. »Open Innovation«, bei dem Kundenaktivitäten und Kundenwissen systematisch in die Planung von Innovationen einbezogen werden sollen, oder »kreative Netzwerke«, in denen Planungsprozesse auf der einen Seite kreative Kooperationsprozesse für die Planung von Innovationen systematisch eingesetzt werden sollen und auf der anderen Seite unkonventionelle, innovative Lösungen in Abhängigkeit

70


von der Problemkategorie und den Kompetenzen der Beteiligten entstehen können.

2.4 Wissensintensive Kooperationsprozesse bei der Entwicklung innovativer Produkte

2.4.1 Ausgangssituation Die Konzeption der Arbeiten, die im Teilprojekt durchgeführt wurden, orientierte sich zum einen am Stand der Forschung auf den Gebieten des Rapid Product Developments, der Teamkooperation und des Wissensaustauschs in Teams. Zum anderen wurde der Stand der Technik in Form der praktischen Anwendung von Unterstützungsinstrumenten berücksichtigt. Stand der Forschung Wesentliches Kernelement des Rapid Product Development Ansatzes ist die interdisziplinäre Zusammenarbeit von Experten aus unterschiedlichen Wissensdomänen zur Beschleunigung von Entwicklungsprozessen und zur Verkürzung von Produktentwicklungszyklen. Durch die Nutzung einer möglichst breiten Wissensbasis sollen Kenntnisdefizite über das zu entwickelnde Produkt frühzeitig überwunden werden [2.106]. Die frühe Festlegung auf Funktions-, Qualitäts- und Kostenmerkmale erfordert ein fachübergreifendes Verständnis des Entwicklungsprozesses wie auch umfassende Kenntnisse über Märkte und eingesetzte Technologien [2.18]. Es gilt deshalb, unterschiedliche Perspektiven in die Planung und Steuerung des Entwicklungsprozesses möglichst frühzeitig einzubeziehen und in allen Iterationszyklen zu berücksichtigen [2.121]. Generell gilt für fach- und funktionsgemischte Projektteams, dass durch den kombinierten Einsatz des spezifischen Know-hows der einzelnen Mitarbeiter die Fähigkeit des Teams erhöht werden soll, komplexe Projektaufgaben zu bewältigen und innovative Lösungen zu erarbeiten [2.13], [2.125]. In der interdisziplinären Kooperation von Experten, dem Zusammentreffen unterschiedlicher Wissensstrukturen und der Überwindung disziplinspezifischer Spezialisierung werden die Voraussetzungen für kreatives und innovatives Handeln gesehen [2.124]. Es wird angenommen, dass durch eine Vernetzung von Expertisen unterschiedliche Wissensbestände verknüpft und wechselseitig verstärkt werden, was zu einer größeren gemeinsamen Wissensbasis führt [2.116]. Besonders im Rahmen kom-

2.4 Wissensintensive Kooperationsprozesse für innovative Produkte

71

plexer Aufgaben- und Problemstellungen scheinen interdisziplinär besetzte Teams Leistungsvorteile zu besitzen, da sie potenziell auf eine größere Vielfalt an Wissen, Kompetenzen und Problemlösungsstrategien zurückgreifen können [2.13], [2.30]. Allerdings existieren auch Studien, die negative Implikationen einer heterogenen Teambesetzung nachweisen. Solche dysfunktionalen Effekte werden in erster Linie mit einer geringeren Konsensfähigkeit [2.64] und einem gesteigerten Konfliktpotenzial begründet [2.31], [2.91]. Insgesamt sind Defizite bei der Analyse hochspezialisierter, interdisziplinärer Entwicklungskooperationen zu erkennen [2.112], [2.123]. In arbeitsorganisatorischer Hinsicht handelt es sich bei interdisziplinärer Entwicklungsarbeit um kollaborative Arbeit, die sich zumeist als zeitlich befristete Projektarbeit konstituiert. Weil die Kooperation immer häufiger in überregional vernetzten Handlungsräumen stattfindet, sind die Interaktions- und Kommunikationsstrukturen stark mit der Nutzung informationstechnologischer Infrastrukturen verbunden [2.75], [2.79], [2.93]. In Bezug auf die Arbeitsqualität weist kooperative Entwicklungsarbeit typische Merkmale von „Wissensarbeit“ auf. Als Wissensarbeit werden komplexe organisierte Tätigkeiten bezeichnet, die mit der Bearbeitung von Unsicherheiten und Risiken verbunden sind, wobei sich die Unsicherheiten erst im Verlauf des Arbeitsprozesses selbst näher eingrenzen lassen [2.51], [2.127]. Wissensarbeit reduziert sich mithin nicht auf die Anwendung wissenschaftlich gesicherter Expertisen, sondern zielt auf die Interpretation von Informationen für die Bereitstellung situationsspezifischer Problemlösungen [2.69]. Im Fall einer interdisziplinären Kooperation zur Entwicklung von Prototypen zeichnen sich situationsspezifische Unsicherheiten z. B. in einer mangelnden Produktspezifikation in den frühen Entwicklungsphasen ab, wobei die Kooperation zusätzlich durch die kommunikativen Schnittstellenprobleme einer räumlich verteilten und zeitlich befristeten Zusammenarbeit erschwert wird. Werden zwischen den beteiligten Akteuren bereits in einem frühen Entwicklungsstadium auch unsichere Informationen ausgetauscht, ergeben sich neuartige Herausforderungen im Umgang mit Wissen und Expertise. Dort, wo es nicht allein um die Anwendung, sondern auch um die Generierung von Wissen vor dem Hintergrund der Bewältigung praktischer Arbeitsaufgaben geht, ist die Rede von neuen Formen der „Wissensproduktion“, die durch inter- und transdisziplinäre Konstellationen gekennzeichnet sind [2.40]. Empirische Studien zeigen, dass die organisierte Produktion und Reproduktion von Wissen weder als Zufall noch als zielgerichtete Innovation aufgefasst werden kann, sondern aus dem prozessualen Wechselverhältnis von kognitiven Repräsentationen und sozialen Interaktionsmus-

72


tern resultiert und sowohl von organisatorischen Rahmenbedingungen wie auch von technischen Artefakten beeinflusst wird [2.65]. Vor diesem Hintergrund wird betont, dass ein effizientes Management von Wissen im Rahmen der organisationalen Leistungserstellung nur durch eine Verknüpfung von personengebundenen und personenunabhängigen Wissensformen auf Prozessebene erreicht werden kann [2.128]. Hier hat die Basisunterscheidung von implizitem und explizitem Wissen [2.95] den Blick für die Wechselwirkung von individuellem und kollektivem Wissen geschärft. Nach dem Modell von Nonaka und Takeuchi [2.88] entstehen dort, wo beide Wissenstypen erfolgreich ineinander überführt werden können, spiralförmige Wissensprozesse, die – von der individuellen Ebene ausgehend – auf eine kollektive Ebene übergehen und schließlich die interorganisationale Ebene erreichen können. Entscheidend für die Generierung von Wissen ist gemäß diesem Modell die Umwandlung impliziter in explizite Wissensformen, was als „Externalisierung“ bezeichnet wird. Im Gegensatz zu eindimensionalen Vorstellungen, die Wissen allein als Aufnahme und Verarbeitung von Information verstehen, betonen die Autoren, dass Informationen nur in Verbindung mit konkreten Handlungen in einem dynamischen Kontext zu sinnhaftem Wissen verarbeitet werden können. Dieses Modell scheint geeignet, die Wissensintegrationsprozesse in interdisziplinären Entwicklungsteams zu beschreiben. Durch die Kombination individueller Wissensdomänen und Perspektiven kommt es entlang des Arbeitsprozesses zu einer kritischen Masse an Expertise. Dadurch können beschleunigte Wissensprozesse in Gang gesetzt werden, wenn das implizite Wissen der beteiligten Akteure, z.B. in Form einer Prototypenentwicklung als gemeinsame Wissensbasis externalisiert und für weitere Wissensprozesse anschlussfähig gehalten wird. Auch die informatische Perspektive [2.42], [2.60] und die psychologische Arbeitsforschung [2.50] betonen die Bedeutung impliziten Wissens für die Bewältigung von Arbeitsaufgaben. Implizites Wissen wird dabei konzipiert als erfahrungsgeleitetes Wissen, welches von den Beschäftigten nur über konkrete Arbeitssituationen erfahren werden kann und stark mit den Arbeitsprozessen verknüpft ist. Dabei wird auf das Problem verwiesen, dass die Beobachtung und Messung impliziten Wissens oftmals an der mangelhaften Operationalisierung dieser Wissensform scheitert. Andere Autoren abstrahieren daher vom Begriff des impliziten Wissens und bevorzugen für die Beschreibung der Verknüpfung von Wissen und Handlung den Begriff der „Könnerschaft“ [2.105] oder aber konkretisieren den Begriff des impliziten Wissen durch operationalisierbare Variablen, was dann als „kontextbezogenes Wissen“ (contextual knowledge) bezeichnet wird [2.38]. Darüber hinaus wird argumentiert, dass die Explizierung von Wissen auch von anderen Aspekten, wie z.B.


73

der Motivation zur Wissenspreisgabe abhängig ist [2.10], [2.28]. Wissen wird folglich situativ von den Individuen rekonstruiert und repräsentiert deren Erwartungen über bestimmte Ursache-Wirkungszusammenhänge [2.99]. Die bisherigen Erfahrungen mit interdisziplinärer Arbeit lassen den zweischneidigen Charakter von Expertenkooperationen erkennen [2.46]. So lassen sich auf der einen Seite positive Effekte wie Produktivitätssteigerungen (z. B. [2.94]), schnellere und qualitativ höherwertige Arbeit [2.15], [2.81] und verbesserte Entscheidungsprozesse [2.108], [2.111] feststellen. Auf der anderen Seite sind jedoch auch negative Effekte wie erhöhtes Stresserleben [2.58] oder Probleme mit der Einhaltung von Kosten und Zeit [2.39] beobachtbar. Kaum behandelt wurde jedoch die Frage, welche Faktoren für die sehr unterschiedlichen Ergebnisse von Entwicklungsteams verantwortlich sind. Während bereits Studien zum Thema demographische und kulturelle Heterogenität vorliegen (z. B. [2.7], [2.47]), ist die Frage nach disziplinären Unterschieden bisher nur vereinzelt berücksichtigt worden [2.46], [2.86], [2.104]. Studien zu den Effekten funktionaler Heterogenität auf die Leistungsfähigkeit und Innovativität von Produktentwicklungs- und Managementteams zeigen ein gemischtes Bild (z. B. [2.20], [2.35], [2.41], [2.81], [2.109], [2.111]). Mit der genaueren Betrachtung der Konflikte fachspezifischer Dyaden im Interaktionsprozess von RPD-Teams wird der Notwendigkeit zur Differenzierung der Auswirkungen funktionaler Heterogenität Rechnung getragen. Wie Pelled et al. [2.91] in einer Untersuchung an Forschungs- und Entwicklungsteams feststellten, führt funktionale Heterogenität gehäuft zu aufgabenrelevanten Konflikten. Welche genauen Ursachen diese Konflikte hatten, wird allerdings nicht dargestellt. Da in diesen jedoch wichtige Anhaltspunkte für die Entwicklung von Unterstützungsmethoden zu sehen sind, wurde im Rahmen der Arbeiten gezielt nach einzelnen Ursachen für Probleme und Konflikte in der interdisziplinären Teamarbeit gesucht. Im allgemeinen wird angenommen, dass die Entwicklung adäquater mentaler Modelle hinsichtlich Faktoren wie Aufgaben, Mitgliedern, Ausrüstung und Situation zu besseren Teamleistungen, höherer Motivation und besserer Koordination beiträgt (vgl. [2.24]). Solche Effekte ließen sich vor allem für Teams mit aktuell hoher Arbeitsbelastung nachweisen (z. B. [2.25], [2.36], [2.80]). Dieser Wirkungsbereich wurde jedoch bisher nicht in Hinblick auf die spezifischen Anforderungen von interdisziplinären Produktentwicklungsteams untersucht. Als Voraussetzung dafür, dass sich ein common ground zwischen den Teammitgliedern etabliert, wird der erfolgreiche und aktive Transfer von Wissen zwischen Teammitgliedern gesehen [2.5], [2.26], [2.126]. Wie je-

74


doch Strategien zur Unterstützung dieses Transfers von Mitgliedern in Produktentwicklungsteams verwendet werden, um Probleme der Wissensintegration zu verhindern bzw. zu beheben, wurde bislang nicht thematisiert. Ebenso fehlt eine Systematisierung der eingesetzten Strategien, um deren situations- und bedarfsgerechten Einsatz für verschiedene Problemsituationen im Produktentwicklungsprozess gewährleisten zu können. Stand der Technik Aufgrund der Vielschichtigkeit von „Wissen“ im Kontext organisationaler Verwertungs- und Produktionsprozesse bietet es sich an, bei der Analyse von Wissensprozessen verschiedene Ebenen des Wissens zu differenzieren [2.100]. Man kann diesbzgl. unterscheiden zwischen x erkenntnismäßigem Wissen („Know-what“), dem zur Beherrschung eines Fachgebietes notwendigen, durch Qualifikationsmaßnahmen erworbenen Wissen, x hochentwickelten Fertigkeiten („Know-how“); dies meint die Fähigkeit, Fachwissen auf komplizierte Probleme anzuwenden, x dem Verständnis der systemischen Zusammenhänge („Know-why“), d.h. fundierte Kenntnisse über komplexe Kausalzusammenhänge und die Fähigkeit, situationsspezifische Problemlösungen zu erarbeiten, x und der Kreativität aus eigenem Antrieb („Care-why“), womit Wille, Motivation und Zielstrebigkeit angesprochen sind. Die einzelnen Ebenen gehen mit unterschiedlichen Anforderungen und Perspektiven zur technologischen, organisatorischen und qualifikatorischen Unterstützung der Beschäftigten einher. Auf der Ebene des Faktenwissens (Know-what) gilt es, eine zunehmend unüberschaubare Menge an Informationen zu erfassen und zu strukturieren. Datenbankgestützte EDVSysteme und leistungsfähige CSCW-Anwendungen können dabei unterstützend wirken. Im Gegensatz dazu lassen sich Fertigkeiten (Know-how) nicht in Datenbanken speichern oder über Computernetze übertragen. Fertigkeiten entstehen im Rahmen konkreter Problembearbeitung und der praktischen Anwendung von Wissen. Nur dort, wo gemeinsame Handlungs- und Erfahrungsräume geschaffen werden, kann ein Austausch auf der Ebene von Fertigkeiten stattfinden. Auf der Ebene des Systemverständnisses (Know-why) treten oftmals Verständigungsschwierigkeiten auf, wenn die Paradigmen und mentalen Modelle der beteiligten Individuen voneinander abweichen und gemeinsame Deutungsund Interpretationsmuster fehlen. Schließlich sind erfolgreiche Wissensaustauschprozesse auf die Überschneidung persönlicher Ziele und


75

Interessen (Care-why) angewiesen. Alle Beteiligten müssen motiviert sein, defensive Handlungsstrategien zu überwinden und Problemlösungen im Kollektiv zu erarbeiten. Nur wenn die Integration der unterschiedlichen Wissensebenen gelingt, kann das relevante Wissenspotenzial der Beteiligten für Innovationsprozesse bereitgestellt werden. Empirische Analysen lassen jedoch erkennen, dass gerade im Bereich der Wissensintegration Defizite bei der Kooperation interdisziplinärer Entwicklungsteams festzustellen sind [2.115]. Wissensintegration, verstanden als ein gemeinsames Verständnis von Begrifflichkeiten und Zusammenhängen, fungiert dabei als Basis für gelungene Kommunikations- und Koordinationsprozesse. Während die Rolle der Kommunikation und der Koordination bereits häufiger Gegenstand wissenschaftlicher Untersuchungen waren, findet der Prozess der Wissensintegration bzw. des „groundings“ in interdisziplinären Teams erst in letzter Zeit stärkere Beachtung [2.122], [2.123]. Gleichwohl liegen für eine verbesserte Integration unterschiedlicher Wissensarten Konzepte vor. Hier sind vor allem solche Ansätze vielversprechend, die auf eine Feinabstimmung von Instrumenten des Wissenstransfers mit den jeweiligen Wissensinhalten abzielen [2.33]. Die Auswahl unterschiedlicher Strategien und Instrumente des Wissenstransfers hängt dabei sowohl von der Art des Wissens, der Art der Arbeitsaufgabe wie auch von den Besonderheiten der beteiligten Personen ab. In der Literatur werden unterschiedliche Strategien und Instrumente zur Wissensintegration diskutiert. So stehen z.B. mit den Methoden von „Concept-Maps“ [2.89], „Learning histories“ [2.62] und der „Blueprinting“Methode [2.133] Techniken zur Visualisierung unterschiedlicher Wissensbereiche zur Verfügung. Während die Methode des Concept-Mapping auf die systematische Erfassung und Visualisierung individueller Wissensrepräsentationen in Form der Illustration eines semantischen Netzwerkes abzielt, handelt es sich bei „Learning histories“ um ein narratives Erhebungsinstrument, mit dem relevante Wissensprozesse im Anschluss an bewältigte Arbeitsaufgaben ex post rekonstruiert werden. Das Instrument des Blueprinting schließlich zielt auf die systematische Erfassung und Darstellung aufgabenübergreifender Arbeits- und Geschäftsprozesse. Die Anwendung und Weiterentwicklung solcher Instrumente kann im Rahmen kooperativer Entwicklungsarbeit einen wichtigen Beitrag für die Schaffung einer gemeinsamen Wissensbasis und damit einer verbesserten Wissensintegration leisten. Zum einen können so Gemeinsamkeiten und Unterschiede der Perspektiven und Wissensdomänen der beteiligten Akteure herausgearbeitet und beeinflusst werden. Zum anderen wird ein Gesamtverständnis komplexer Arbeitsprozesse gefördert. Bislang steht je-

76


doch die systematische Abstimmung einzelner Instrumente auf unterschiedliche Wissensarten und -ebenen aus. Gelingt die gezielte Fortentwicklung und Zusammenführung solcher Erhebungstechniken, kann damit auch ein Beitrag für eine ganzheitliche Arbeitsgestaltung geleistet werden [2.54]. Hier gilt es zunächst, die arbeitswissenschaftlichen wie auch die organisatorischen Voraussetzungen für die Überwindung einer funktionalen Arbeitsteilung und kommunikativer Schnittstellenprobleme zu bestimmen, um im Anschluss entsprechende Gestaltungsempfehlungen formulieren zu können. Nur wenn die Arbeitsaufgaben in angemessener Weise mit dem Wissen und der Qualifikation der Beschäftigten austariert sind, lassen sich Stresssituationen und Unterforderungen vermeiden [2.23], [2.76]. Gerade das Beispiel einer zeitkritischen Forschungs- und Entwicklungsarbeit – wie beim RPDVerfahren – zeigt, dass die Zunahme paralleler Arbeitsprozesse eine deutliche Erhöhung der Aufgabenkomplexität nach sich zieht. Ein umfassendes Verständnis von vorund nachgelagerten Arbeitsprozessen wird daher zu einem zentralen Faktor für gelungene Kooperationsverläufe [2.14]. Dort, wo ein solches übergreifendes Verständnis ausbleibt, ist mit erhöhten zeitlichen und psychischen Belastungen der Beschäftigten zu rechnen. Die Schaffung kollektiver Interpretationsmuster in Form einer "gemeinsamen Sprache" bzw. eines "common ground" [2.27] in Kombination mit einem tiefgreifenden Verständnis um komplexe Arbeitsprozesse ermöglicht dagegen den Aufbau eines systematisch vernetzten Meta-Wissens. Ein solches entlastend wirkendes Meta-Wissen hilft, verschiedene Fachdisziplinen, Denk- und Vorgehensweisen zu integrieren, indem es als "Brücke" zwischen potenziell isolierten Wissens- und Erfahrungsbereichen fungiert [2.52]. Durch die Einbettung von Faktoren der Wissensintegration in einen weitläufigeren sozialen und organisatorischen Kontext sind deshalb Erkenntnisse zu erwarten, die Aussagen über eine menschengerechte und gesundheitlich zuträgliche Gestaltung der Arbeitswelt in hochinnovativen Beschäftigungsumfeldern zulassen. 2.4.2 Modellentwicklung und Ableitung von Unterstützungsinstrumenten zur Wissensintegration im RPD Im Verlauf des Sfb 374 wurden im Themenbereich »Arbeitswissenschaftliche Konzeptionierung kooperativer Arbeitsformen für die Entwicklung innovativer Produkte« folgende Ergebnisse erarbeitet: Im ersten Schritt wurde ein Modell zur Analyse von interdisziplinären Expertenkooperationen entwickelt, das aus den Teilprozessen der Kommunikation, der Koordination und der Wissensintegration besteht. Dieses Modell wurde im


77

zweiten Schritt operationalisiert und empirisch validiert, wobei die Bedeutung der Teilprozesse für unterschiedliche Kooperationstypen untersucht wurde. Auf diesen Ergebnissen aufbauend bestand die Aufgabenstellung im dritten Schritt in der Weiterentwicklung des Kooperationsmodells, der Analyse des Zusammenhangs zwischen Wissensintegration, mentalen Modellen und Wissensebenen und der Erweiterung des Modells der Wissensintegration durch theoretische und praktische Elemente. Der vierte Schritt zielte auf die Entwicklung von Gestaltungsempfehlungen und Instrumenten für die Unterstützung interdisziplinärer, kooperativer Arbeiten in RPD-Teams. Dazu erfolgte eine Systematisierung und Validierung der in den bisherigen Förderphasen entwickelten Strategien zur Unterstützung der Wissensintegration für RPD-Teams anhand von Rahmenbedingungen und Kriterien des erweiterten Kooperationsmodells. Darüber hinaus wurden bestehende Methoden zur Unterstützung der Wissensintegration eingesetzt und für die spezifischen Anforderungen im Produktentwicklungsprozess angepasst und bewertet. Das Ergebnis sind exemplarisch überprüfte Methoden und Vorgehensweisen zur Sicherung bzw. Verbesserung der Wissensintegration in RPD-Teams sowie durch wissenschaftlich fundierte Untersuchungen abgesicherte Instrumente zur Beurteilung der Qualität des Wissensintegrationsprozesses. Die konkreten Anforderungen, die sich an Teammitglieder und insbesondere an Teamleiter in interdisziplinären Entwicklungsteams stellen, werden in einem anschließenden Transferprojekt analysiert und gemeinsam mit den entwickelten Handlungsempfehlungen und Instrumenten in eine morphologisch aufgebaute Gestaltungsbox zur Unterstützung von Produktentwicklungsteams integriert. Im Rahmen der Arbeiten wurde zunächst auf Basis theoretischer Überlegungen und empirischer Studien die Teilprozesse Kommunikation, Koordination und Wissensintegration als grundlegende Elemente von Kooperationsvorgängen identifiziert. Darauf aufbauend wurde ein entsprechendes Kooperationsmodell entwickelt, welches dann in mehreren Studien bei interdisziplinären Entwicklungsteams validiert wurde. Wesentliche Ergebnisse waren dabei x die Entwicklung und Validierung eines Instruments zur Bewertung der Kooperation in interdisziplinären Entwicklungsteams; x eine erhöhte Bedeutung der Wissensintegration für den Kooperationsprozess im Vergleich zu den beiden anderen Teilprozessen der Kommunikation und Koordination;

78


x die Unterscheidung unterschiedlicher Kooperationstypen, welche sich hinsichtlich der Häufigkeit von Problemen bei Kommunikation, Koordination und Wissensintegration voneinander abheben; x phasenbezogene Unterschiede in der Problemakkumulation: die meisten Probleme bezüglich Koordination und Wissensintegration traten in der Entwurfsphase auf, in der anhand konkreter werdender PrototypenMerkmale die unterschiedlichen Vorstellungen und Wissenshintergründe der Teammitglieder aufeinander stießen. Ausgehend von diesen Ergebnissen orientierte sich das weitere Vorgehen an drei Arbeitsschritten: Zuerst wurden im Rahmen einer Längsschnittuntersuchung Anforderungen an die Kommunikation, Koordination und Wissensintegration in Abhängigkeit von Entwicklungsphasen untersucht. Anschließend wurden die mentalen Modelle der Teilnehmer eines interdisziplinären Forscherteams in Hinsicht auf rollen- und wissensdomänenabhängige Unterschiede analysiert. Aus den Ergebnissen beider Arbeitspakete wurde ein Modell zur Wissensintegration abgeleitet. Im dritten Schritt wurden zunächst unterschiedliche Kooperationskonstellationen hinsichtlich der teambezogenen Heterogenität, der Komplexität des Produktentwicklungsprozesses sowie der Kreativitätsförderlichkeit des Umfelds untersucht. Die Ergebnisse wurden anschließend in die Entwicklung eines erweiterten Kooperationsmodells integriert und dieses im Rahmen einer empirischen Untersuchung evaluiert. Zuletzt wurden die technologischen Unterstützungsmöglichkeiten für die Wissensintegration aus arbeitswissenschaftlicher Perspektive bewertet. 2.4.3 Ergebnis der Modellentwicklung zur Wissensintegration Um die theoretische Grundlage für die Arbeiten zu legen, wurden zunächst Modelle über die grundlegenden Zusammenhänge des Arbeitsschwerpunkts erarbeitet. Hierzu gehörte die Zusammenfassung der Kooperationsanforderungen für fach- und funktionsgemischte Entwicklungsteams in einem Kooperationsmodell (Abb. 2.23.).


79

Abb. 2.23. Kooperationsmodell mit den drei Teilprozessen der Kommunikation, Koordination und Wissensintegration [2.115].

Das Modell definiert Kooperation als Gesamtheit aus den drei Teilprozessen der Kommunikation, Koordination und Wissensintegration. Kommunikation umfasst dabei den Austausch von Informationen und Wissen zwischen den Teammitgliedern, also gewissermaßen den Transport von Wissensinhalten zwischen den Beteiligten. Unter Koordination wird die zielorientierte Delegation, Steuerung und Zusammenführung der einzelnen Arbeitsbeiträge verstanden, die es ermöglicht, die komplexe Entwicklungsaufgabe auf verschiedene Schultern zu verteilen, deren Bearbeitung zu überwachen und die verteilt erzielten Arbeitsergebnisse zu einer stimmigen Lösung zusammen zu führen. Um die Kooperation im RPD-Kontext erfolgreich zu gestalten, müssen alle drei Teilprozesse effizient ablaufen. Entsprechend ergeben sich aus diesem Modell Ansatzpunkte für die Entwicklung von Unterstützungsinstrumenten, um die Kooperationsprozesse in Produktentwicklungsteams nachhaltig zu optimieren. Da die beiden Teilprozesse der Kommunikation und der Koordination sowohl im Forschungs- als auch im Praxiskontext bereits hinlänglich Beachtung gefunden haben, wurde im weiteren Verlauf der Arbeiten der Hauptaugenmerk auf den Teilprozess der Wissensintegration gelegt (Abb. 2.24.). Wissensintegration wird dabei als zweistufiger Prozess verstanden, in dessen Verlauf nicht nur die Integration und Neukombination des heterogenen Expertenwissens erfolgt, sondern als deren Voraussetzung auch eine gemeinsame Wissensbasis im RPD-Team entwickelt wird.

80


Abb. 2.24. Das zweistufige Brücken-Modell der Wissensintegration

Das Modell beschreibt die Ausgangslage in Produktentwicklungsteams als Aufeinandertreffen von Fachexperten, die ihr Wissen zwar in das Team mitbringen, es jedoch zunächst nicht unmittelbar einbringen können. Verantwortlich für diesen Umstand sind Barrieren, die durch die Heterogenität der einzelnen Vorstellungen über Ziele, Vorgehensweisen, Erfahrungen und Definitionen entstehen. Je stärker der Spezialisierungsgrad der beteiligten Experten ist, desto größer werden diese Barrieren, die durch die mangelhafte Ausprägung einer gemeinsamen Wissensbasis verursacht werden. Die Entwicklung dieser Wissensbasis erfolgt erst im zweiten Schritt, und zwar im Sinne einer systematisch verfolgten und durch entsprechend abgestimmte Unterstützungsinstrumente geförderten gemeinsamen Integration der für das Projekt relevanten Wissensbereiche. Die eigentliche Zusammenführung des innovationsrelevanten Expertenwissens bleibt davon zunächst unberührt. Erst wenn die gemeinsame Wissensbasis in ausreichendem Umfang hergestellt ist, kann der letzte und eigentliche Schritt der Wissensintegration erfolgen: Das hoch differenzierte Wissen der Teammitglieder kann abgeglichen, zusammengeführt und innovative Lösungen durch Re-Kombination des Wissens entwickelt werden. Im Gegensatz zum Modell laufen diese beiden Wissensintegrationsprozesse in der Praxis nie zeitlich getrennt voneinander ab. Der Aufbau der gemeinsamen Wissensbasis erfolgt in der Regel parallel zu den innovativen Sprüngen, die durch die Integration des heterogenen Wissens erzielt werden. Die Trennung zeigt jedoch die Ursachen von Störungen auf, die entstehen, wenn die Integration des Wissens ohne ausreichend erstellte


81

gemeinsame Wissensbasis durchgeführt werden soll. Ist die Wissensbasis nicht ausreichend belastbar, behindern sich beide Prozesse gegenseitig in ihrer Effizienz. Gleichzeitig können durch die resultierenden Meinungsverschiedenheiten erhebliche soziale Reibungsverluste entstehen, welche die Effizienz der gesamten Teamkooperation nachhaltig senken. Um die Dimensionen genauer zu definieren, auf denen die beschriebenen Wissensintegrationsprozesse ablaufen, wurde ein von Quinn [2.100] adaptiertes Modell der Wissensebenen verwendet. Dieses beinhaltet die Ebenen des projektrelevanten Wissens von Teammitgliedern, auf denen die Bildung einer gemeinsamen Wissensbasis vorrangig betrieben werden sollte (Abb. 2.25.).

Abb. 2.25. Modell der projektrelevanten Wissensebenen für die Entwicklung einer gemeinsamen Wissensbasis in Produktentwicklungsteams (modifiziert nach [2.49], [2.100])

Die erste Wissensebene betrifft das Ziel- und Priorisierungswissen, das aufgrund der Teamheterogenität häufig implizit mit individuellen Vorstellungen besetzt ist. Erst die Konkretisierung und Abstimmung der projektrelevanten Ziele macht es möglich, die verteilt durchgeführten Arbeiten auf gemeinsame Ziele auszurichten. Die Integration auf dieser Wissensebene stellt damit die Voraussetzung für effiziente Koordinationsleistungen dar, ohne die eine Delegation von Arbeitselementen auf einzelne Teammitglieder und eine selbständige, dezentrale Bearbeitung von Teilaufgaben nicht möglich ist.

82


Die Ebene des Fach- und Zusammenhangswissens stellt diejenigen Wissensbereiche der einzelnen Teammitglieder dar, welche für die Lösung der Entwicklungsanforderungen relevant sind. Herausforderung ist hierbei, sowohl die Identifikation dieser Wissensbereiche zu gewährleisten, als auch den Transfer in den Projektkontext und damit dessen Nutzbarmachung für die Fragestellung des Projekts zu ermöglichen. Herausforderung ist wiederum, das bei einem Teammitglied häufig implizit vorliegende Wissen für die anderen Beteiligten sichtbar und verständlich zu machen. Auf der Ebene des Umsetzungswissens lassen sich diejenigen Wissensbereiche einordnen, welche die Nutzung des Erfahrungswissens zum Ziel haben. Hierunter fallen Vorgehensweisen und Methoden, die den Teammitgliedern bekannt sind und zu welchen Erfahrungen vorliegen. Häufig werden auch hier Vorschläge zum Vorgehen im Entwicklungsprojekt gemacht, ohne die implizit zugrunde liegenden Erfahrungen transparent gemacht werden. Ohne die Berücksichtigung dieses Erfahrungswissens bleiben Diskussionen über „das geeignete Vorgehen“ erfolglos, da die eigentlichen Vor- und Nachteile der einzelnen Methoden und Vorgehensweisen nicht verglichen werden können. Die Entwicklung einer gemeinsamen Wissensbasis auf der Definitionsebene versetzt Entwicklungsteams in die Lage, von Anfang an Missverständnisse zu vermeiden, die durch unklar definierte Begrifflichkeiten und sonstige Festlegungen ausgelöst werden. Hierzu gehören beispielsweise relevante interne und externe Beteiligte des Projekts, Benennungen von fachlichen Zusammenhängen, Definitionen von Methoden etc. Entstehen aufgrund von mangelnder Klärung auf dieser Wissensebene Missverständnisse, können Fehler entstehen, die bei später Aufdeckung sehr zeit- und kostenintensiv werden können. Die systematische und frühzeitige Entwicklung einer gemeinsamen Wissensbasis erlaubt es danach fach- und funktionsgemischten Entwicklungsteams, Barrieren des Wissensaustauschs wirkungsvoll zu vermeiden und die Kooperation des Teams maßgeblich zu vereinfachen. Wird auf allen Wissensebenen ein gemeinsames Verständnis der projektrelevanten Wissensbereiche hergestellt, können nach diesem Modell die angestrebten Lösungen effizienter erzielt und Innovationssprünge leichter hergestellt werden. 2.4.4 Ergebnisse der Analyse von Kooperationskonstellationen im Produktentwicklungsprozess (Studie 1) Ausgangspunkt der Arbeiten war die Untersuchung von Kooperationsanforderungen in Teams, die den Rahmenbedingungen und Zielsetzungen


83

des Rapid Product Development unterliegen. In einem Zulieferbetrieb der Automobilindustrie wurde daher eine explorative Fallstudie durchgeführt, in der die Auswirkungen der unterschiedlichen Team- und Kooperationskonstellationen auf die Kooperationsprozesse untersucht wurden. In der Fallstudie wurde ein Prototypenentwicklungsteam eines international tätigen Automobilzulieferbetriebes untersucht. Zunächst wurden im betrieblichen Praxisbeispiel drei Ebenen der Kooperation identifiziert: die Kernteamebene, die teamübergreifende Ebene und die betriebsübergreifende Ebene. Anschließend wurden die Kooperationsebenen mit ausgewählten Rahmenbedingungen des Entwicklungsprozesses in Beziehung gesetzt. Dies betraf die Heterogenität der Entwicklungsteams, der Kreativitätsförderlichkeit des Umfelds und der Komplexität des Produktentwicklungsprozesses, die jeweils unterschiedliche Strategien für die Optimierung von Kooperationsprozessen voraussetzen. Ebenen der Kooperation Während das Kernteam unmittelbar mit der Prototypenentwicklung beschäftigt ist, übt das Randteam auch unterstützende Funktionen wie Logistik, Controlling und Fertigungsplanung aus. Das gesamte Projektteam, also Kern- und Randteam, ist der Projektleitung unterstellt. Eine Differenzierung des Projektteams in unterschiedliche Kooperationsebenen ist notwendig, weil sowohl das Kernteam wie auch das Randteam im Hinblick auf die Heterogenität und die Stabilität des Teams variieren. Eine dritte Kooperationsebene ist in der betriebsübergreifenden Ebene zu sehen. Auf diese Ebene sind im Zuge einer kundenspezifischen Prototypenentwicklung externe Kooperationspartner (Kunden) in den Prozess der Leistungserstellung einzubeziehen. Setzt man die drei Kooperationsebenen mit ausgewählten Rahmenbedingungen des Kooperationsprozesses in Beziehung, ergeben sich differenzierte Kooperationskonstellationen (vgl. Abb. 2.26.).

84


Kooperationsebenen

Strategien zur Rahmenbedingungen Optimierung von KooperaHeterogenität KreativitätsförKomplexität des tionsprozesder Teamkonderlichkeit des Entwicklungssen stellation Umfeldes prozesses Gewährleistung einer hohen Teamstabilität, Kernteamhohe basiert Kommunikationsdichte

Gewährung von Handlungsspielräumen, kommunikationsfreundliche Arbeitsplatzgestaltung

Berücksichtigung sozialemotionaler Faktoren durch Projektleitung, Vermeidung von Burnout-Effekten

Gestaltung der Interaktion durch ProjektKernteamleitung, Projektübergreileiter als Wisfend sensintegrator

Entlastung durch Standardisierung von Routineprozessen; Optimierung der Kommunikation durch Datenbanksysteme

Erhöhung der Informationstransparenz durch Entwicklung eines Instrumentes zur „Reifegradmessung“

Stärkere kommunikative Einbindung des Kunden in den Entwicklungsprozess

Stärkere Strukturierung der Kundeninteraktion, Etablierung einer Vertrauenskultur

Stärkere Angleichung der mentalen Modelle zwischen Kunden und Entwicklungsteam

Betriebsübergreifend

Abb. 2.26. Strategien zur Optimierung von Kooperationsprozessen nach Kooperationsebenen und Rahmenbedingungen der Teamarbeit

Heterogenität des Teams Im untersuchten Unternehmen ist die Disziplinenvielfalt der Teammitglieder innerhalb der Kernteams gering. Darüber hinaus ist die personelle Zusammensetzung auf Kernteamebene stabil. Abgesehen von ungeplanten Fluktuationsbewegungen sind keine Veränderungen in der Teambesetzung während einer laufenden Prototypenentwicklung vorgesehen. Sowohl die


85

fachliche Homogenität wie auch die Stabilität des Kernteams tragen maßgeblich zu einer erfolgreichen Wissensintegration bei. So gelang es dem Team in Bezug auf die Arbeitsaufgabe einen gemeinsamen „common ground“ zu bilden und unterschiedliche Perspektiven – soweit vorhanden – zu integrieren. Auf der kernteamübergreifenden Ebene nimmt die Heterogenität der Teams wie auch die personelle Instabilität erkennbar zu. Auf dieser Ebene gilt es, übergreifende Perspektiven wie Kostenrechnung, Logistik und Fertigungsplanung mit den spezifischen Anforderungen der Prototypenentwicklung abzustimmen und in Übereinstimmung zu bringen. Der Projektleitung kommt dabei eine zentrale Rolle in Bezug auf die Wissensintegration zu. So ist die Projektleitung mit den notwendigen Kompetenzen ausgestattet, um in kritischen Situationen den Wissensintegrationsprozess abzubrechen und eigenverantwortliche Entscheidungen zu treffen. In der Regel gelingt jedoch eine konsensbasierte Wissensintegration, wobei die Projektleitung eine wichtige Moderations- und CoachingFunktion übernimmt. Fokussiert man die betriebsübergreifende Ebene, müssen auch die Ansprechpartner auf Kundenseite als potenzielle Mitglieder des Entwicklungsteams aufgefasst werden. Im Rahmen einer kundenspezifischen Leistungserstellung wird der Kunde als "externer Faktor" in den Produktentwicklungsprozess integriert. Damit steigt die Heterogenität des Teams. Zu beobachten sind divergierende Interessenlagen und unterschiedliche Perspektiven, was die Kooperation vor große Herausforderungen stellt. Während die Kfz-Hersteller als Kunden frühe Festlegungen für die Prototypenentwicklung vermeiden, ist das Entwicklungsteam ab einem bestimmten Zeitpunkt auf genaue Spezifikationen angewiesen. Zudem tauchen im Entwicklungsprozess immer wieder nachträgliche Änderungswünsche (Change-request) des Kunden auf, so dass der Entwicklungsprozess vor erhebliche Koordinations- und Anpassungsprobleme gestellt wird. Die Projektleitung kann nur begrenzt zu einer Perspektivenintegration beitragen, weil der Kunde zwar potenzieller, nicht aber expliziter Bestandteil des Entwicklungsteams ist. Es wurde daher von den Befragten der Wunsch geäußert, den Kunden stärker kommunikativ in den Entwicklungsprozess einzubinden, um zu verbesserten Feedback-Schleifen zu gelangen. Kreativitätsförderlichkeit des Umfeldes Die einzelnen Kooperationsebenen verlangen in Bezug auf die kreativitätsförderliche Gestaltung des Umfeldes spezifische Strategien für eine Optimierung der Kooperationsprozesse. Auf der Ebene des Kernteams wird die Kooperation durch eine kreativitätsförderliche Arbeitsgestaltung unter-

86


stützt. So wird der Wissensaustausch im Kernteam durch die räumliche Anordnung in einem Großraumbüro nachhaltig intensiviert. Für die Kernteammitglieder besteht die Möglichkeit, Ideen im direkten Kontakt zu entwickeln bzw. auszutauschen. Für ein kreativitätsförderliches Umfeld auf Kernteamebene spricht auch, dass die Beschäftigten über große Handlungsspielräume verfügen und standardisierte Arbeitsprozesse kaum vorzufinden sind. Aufgrund der räumlichen Trennung der am Kooperationsprozess beteiligten Personen sind die kreativen Anteile der Arbeit auf kernteamübergreifender Ebene geringer ausgeprägt. Räumliche Distanzen müssen durch technische Kommunikationsinfrastrukturen überwunden werden. Die damit einher gehenden Medienbrüche erschweren die kreativen Austauschprozesse. Ferner werden im untersuchten Unternehmen Maßnahmen getroffen, den Wissensaustausch über die Einrichtung von datenbankgestützten Informationssystemen zu optimieren. Dies spricht dafür, dass auf kernteamübergreifender Ebene der reibungslose Austausch von Information und Faktenwissen Voraussetzung für die Schaffung eines kreativitätsförderlichen Umfeldes ist. Unter Kreativitätsgesichtspunkten gestaltet sich die Kooperation auf betriebsübergreifender Ebene problematisch. Hier ist zu beobachten, dass kreative Prozesse zwischen Kunden und Entwicklungsteam erschwert werden, wenn keine ausreichende Vertrauensbasis für den Austausch unsicherer und sensibler Informationen zur Verfügung steht. Darüber hinaus ist festzustellen, dass kreative Prozesse einen dysfunktionalen Charakter entfalten können, wenn sie einseitig und „ad hoc“ erfolgen. So können nachträgliche Änderungswünsche des Kunden im fortgeschrittenen Entwicklungsprozess zwar unter Kreativitätsgesichtspunkten betrachtet werden. Dies wird jedoch vom Entwicklungsteam nicht als kreativer Impuls, sondern als willkürliches Vorgehen empfunden – zumindest dann, wenn solche Wünsche enorme Anpassungsschwierigkeiten nach sich ziehen. Auf Seiten des untersuchten Unternehmens sind daher Wünsche auszumachen, zu einer stärkeren Strukturierung der Kundeninteraktion zu gelangen, um über eindeutig formulierte Standards und Anforderungsprofile die Austauschprozesse in überschaubare Bahnen zu lenken. Komplexität des Entwicklungsprozesses Die Prototypenentwicklung von Serienbauteilen ist als Ausschnitt eines gesamten Automobilentwicklungsprozesses zu sehen. Die KfzEntwicklung weist im Zuge minimierter Fertigungstiefen stark netzwerkförmige Züge auf und hat mittlerweile einen extrem hohen Komplexitätsgrad erreicht. Ein wesentliches Problem diesbezüglich ist der Umgang mit


87

ausstehenden Informationen und Unsicherheit. So können die KfzHersteller als Auftraggeber oftmals keine eindeutigen Produktspezifikationen formulieren, weil sie im Zuge eines netzwerkbasierten Entwicklungsprozesse selber (noch) nicht über die dafür notwendigen Wissensbestände verfügen. Die Folge können nachträgliche Änderungswünsche (ChangeRequest) und unzureichende Informationsflüsse sein, die besonders im fortgeschrittenen Stadium der Prototypenentwicklung einen großen Unsicherheitsfaktor darstellen. Im Verlauf der Untersuchung konnte festgestellt werden, dass die identifizierten Kooperationsebenen eine unterschiedliche Problemwahrnehmung in Bezug auf die Komplexität des Produktentwicklungsprozesses aufweisen. Auf der kernteambasierten Ebene werden nachträgliche Änderungswünsche und ausstehende Informationsbestände als hochbelastendes „Chaosmanagement“ erfahren. Die Komplexität des Entwicklungsprozesses artikuliert sich primär als Koordinationsproblem, weil Arbeitsergebnisse verworfen und die Prototypenentwicklung zum Teil auch in fortgeschrittenen Entwicklungsphasen neu begonnen werden muss. Der Umgang mit Unsicherheit wird als Stress erfahren, der im kognitiv emotionalen Bereich bearbeitet werden muss. Der Projektleitung kommt in diesem Zusammenhang nicht nur eine koordinierende, sondern auch eine sozialintegrative Funktion zu. Dazu zählt, die individuelle Leistungsfähigkeit und Belastbarkeit der Beschäftigten frühzeitig zu erkennen, um BurnoutEffekten vorzubeugen. Auf kernteamübergreifender Ebene artikuliert sich die Komplexität des Produktentwicklungsprozesses primär als Kommunikationsproblem. Diesbezüglich ist zu beobachten, dass die nur lose an den Entwicklungsprozess angeschlossenen Bereiche und Abteilungen erwarten, kontinuierlich mit aktuellen Informationen über den Entwicklungsprozess versorgt zu werden. Um dies zu gewährleisten, wird in dem untersuchten Unternehmen die Entwicklung eines Instrumentes zur Reifegradmessung angestrebt. Der Reifegrad eines jeweiligen Prototypen soll kontinuierlich vor dem Hintergrund zeitlicher, betriebswirtschaftlicher und qualitätsbezogener Kennzahlen abgebildet werden. Mit einem solchen Instrument soll festgestellt werden, ob ein Prototyp innerhalb der verbleibenden Entwicklungsfrist auch dann noch auf Seriengradreife entwickelt werden kann, wenn sich Verzögerungen im Entwicklungsprozess einstellen. Auf betriebsübergreifender Ebene schließlich manifestiert sich die Komplexität des Entwicklungsprozesses in erster Linie als ein Problem der Wissensintegration. In der Wahrnehmung der Beteiligten Akteure werden die im Entwicklungsprozess auftauchenden Unsicherheiten zumeist auf unterschiedliche Interessenlagen und heterogene Perspektiven, aber auch auf eine mangelhaftes Vertrauen im Umgang mit sensibler Information zu-

88


rückgeführt. Eine mögliche Lösung für eine verbesserte Wissensintegration wird darin gesehen, dem Auftraggeber die eigene Perspektive nachdrücklicher zu vermitteln, um so zu einer Annäherung der mentalen Modelle zu gelangen. Im Interview sagte dazu eine leitender Funktionsträger: „Wir müssen dem Kunden stärker vermitteln, wie sein Denken funktioniert“. Konkrete Strategien, ob und wie dies erreicht werden kann, konnten jedoch nicht beobachtet werden. Für die Optimierung von Kooperationsprozessen können aus den Ergebnissen des Arbeitspakets folgende Handlungsempfehlungen abgeleitet werden: x In Folge spezifischer Rahmenbedingungen des Entwicklungsprozesses und unterschiedlicher Ebenen der Kooperation können sich variierende Kooperationskonstellationen ergeben. Dort, wo sich dies innerhalb eines Entwicklungsprozesses abzeichnet, sind Strategien zur Optimierung von Kooperationsprozessen auf die jeweilige Kooperationskonstellation abzustimmen. x Der Berücksichtigung von sozial-emotionalen Faktoren kommt gerade im Zusammenhang zyklischer und iterativer Entwicklungsprozesse eine wichtige Bedeutung für erfolgreiche Kooperationsverläufe zu. Der Umgang mit unsicheren Informationen wie auch Kommunikations- und Koordinationsprobleme werden von den Beschäftigten nicht selten als psychischer Stress erfahren. Hier gilt es, Überlastungen einzelner Teammitglieder frühzeitig zu erkennen und ihnen entgegen zu wirken. Die Projektleitung nimmt hierbei eine wichtige Coaching-Funktion wahr. x Die Integration des Kunden als "externer Faktor" in den Prozess der Leistungserstellung bringt eine besondere Problematik mit sich. Auch auf der betriebsübergreifenden Ebene gilt es, ein vertrauensvolles Arbeitsklima zu schaffen und die kommunikativen Feedback-Schleifen zu intensivieren. Auf diese Weise kann der Prozess der Wissensintegration nachhaltig gefördert werden; mögliche Änderungswünsche des Kunden können frühzeitiger erkannt bzw. kommuniziert werden. 2.4.5 Ergebnisse der Untersuchung von Kooperationsanforderungen im Produktentwicklungsprozess (Studie 2) Um die Anforderungen in hoch interdisziplinären Entwicklungsteams und einen kompletten Entwicklungsprozess von der Konzeption bis zum fertigen Produkt untersuchen zu können, wurde eine qualitative Fallstudie


89

durchgeführt. Im Rahmen einer Längsschnitt-Untersuchung wurde ein kompletter Problemlösungsprozess eines Projektteams mit Hilfe von Beobachtungen, Dokumentenanalyse und Befragungen analysiert. Es sollte untersucht werden, welche Probleme und Anforderungen in sehr komplexen, heterogenen, internationalen und interdisziplinären Kooperationen im Bereich der digitalen Medienkunst auftreten, wie konkret mit Problemen umgegangen wird und in welchem Zusammenhang die Problembewältigung mit dem phasenbezogenen Entwicklungsverlauf steht. Bei dem untersuchten Entwicklungsprojekt handelte es sich um eine interdisziplinäre Kooperation zwischen einem amerikanischen Medienkünstler (Konzeption und Projektleitung), finnischen Kognitionswissenschaftlern (SOM, Kohonen self-organizing map-Alogrithmen), ungarischen Ingenieuren / Künstlern (Hard- und Software-Entwicklung), deutschen Designern und Psychologen und einem französischen Kurator. Das Team setzte sich aus 13 männlichen und einem weiblichen Teammitglied im Alter zwischen 24 und 51 Jahren zusammen. Die Erfahrungen mit der Arbeit in interdisziplinären Teams waren bei den meisten Mitgliedern gering. Aufgrund der räumlichen Verteilung der Beteiligten (Helsinki, Budapest, Stuttgart und Paris) fand die Kommunikation hauptsächlich über E-Mail bzw. Telefon statt; es wurde in Englisch bzw. Französisch (Kurator/Künstler) kommuniziert. Die Komplexität dieser Projektkonstellation stellte sich aufgrund der Innovativität, der Integration von Wissenschaft und Kunst und der technischen Realisierung als außerordentlich hoch dar. Probleme bezüglich der Kommunikation Aufgrund der räumlichen Entfernung waren persönliche Treffen selten; die Kommunikation fand hauptsächlich über E-Mail statt. Dies machte es anfangs schwer, Vertrauen zwischen den Beteiligten aufzubauen, und zwar um so mehr, als sich nur der Künstler und das ungarische Teams sich vorher kannten. Darüber hinaus gab es wenig Gemeinsamkeiten zwischen den Teammitgliedern: neben den unterschiedlichen Muttersprachen und kulturellen Unterschieden variierte auch das Alter (zwischen 25 und 51 Jahren) und die Berufserfahrung stark (Student bis langjährige Tätigkeit). Insbesondere am Projektstart konnten starke Spannungen zwischen den Subgruppen festgestellt werden. So war es nur schwer möglich, Schwierigkeiten im Projektteam offen anzusprechen. Ebenso war die Kompromissbereitschaft der Beteiligten zunächst gering, was hauptsächlich auf die hohen Ambitionen der jüngeren, wenig projekterfahrenen Teammitglieder zurückzuführen war.

90


Die phasenbezogenen Aufgaben an das Projektteam und die jeweiligen Kommunikationsstrukturen zwischen den Teammitgliedern sind in Abb. 2.27 dargestellt.

Abb. 2.27. Phasenbezogene Kommunikationsstrukturen des interdisziplinären Medieninstallations-Entwicklungsprojekts

Es wird deutlich, dass die Zusammenarbeit zusätzlich durch die Differenzierung der Gruppe in Subgruppen erschwert wurde. Die Kommunikation in der Anfangsphase des Projekts fand in erster Linie zwischen dem Projektleiter (GL) und den zuständigen Teilprojektleitern in Finnland und Ungarn statt. Auch alle relevanten Informationen zwischen dem finnischen und dem ungarischen Team wurden zunächst über den Projektleiter weitergeleitet. Dies führte vielfach zu Missverständnissen, da der Projektleiter nicht über das notwendige Wissen über Konventionen bei den Datenformaten verfügte. Verbesserte Kommunikationsprozesse konnten erst in der Realisierungsphase des Projekts beobachtet werden, als eine direkte Kommunikation zwischen beiden Gruppen über E-Mail erfolgte. Probleme bezüglich der Koordination Das Projekt stand von Anfang an durch einen relativ eng gesteckten Terminplan unter Zeitdruck: Zudem wurde die Einhaltung des Zeitplans durch die Mehrfach-Belastungen einzelner Teammitglieder erschwert. Aufgrund mangelnder Erfahrung einzelner Teammitglieder dauerten einzelne Teilschritte länger als geplant. Zum Teil wurden auch Vereinbarungen nicht


91

eingehalten. Dies führte aufgrund der wechselseitigen Abhängigkeiten der Einzelaufgaben zu starken Zeitverzögerungen des Gesamtprojektes. Koordinationsprobleme ergaben sich aber auch aus unterschiedlichen Vorstellungen über die inhaltlichen Ziele des Projektes bzw. aus abweichenden Auffassungen über die zu leistenden Einzelbeiträge und die jeweilige Kompetenzverteilung. So fehlte gerade zu Beginn des Projektes ein Verständnis für die Realisation einer gemeinsamen Arbeitsaufgabe. Jede Disziplin verstand vielmehr ihren Aufgabenteil als zentral und versuchte diesen kontinuierlich zu optimieren. Dadurch wurden teilweise zusätzliche Aufgaben ausgeführt, was wiederum die Integration der Einzelbeiträge erschwerte. Ursächlich hierfür waren offenkundig auch Schwierigkeiten beim Projektmanagement: Aufgrund der mangelnden Erfahrung des Teamleiters mit der Abwicklung solcher Projekte, wurden Besprechungen kaum vorbereitet und es existierten wenig schriftlich fixierte Kommunikationsverläufe, wie z. B. Gesprächsprotokolle etc. Aufgrund der hohen Ansprüche, welche die Gruppe selbst an die Innovativität dieses Projektes richtete, konnten die Ziele am Anfang nicht klar definiert werden, so dass zunächst nur eine sehr grobe Projektplanung vorgenommen wurde. Der Teamleiter verfolgte bewusst das Ziel, den einzelnen Mitglieder weitreichenden Handlungsspielraum zu lassen, um so von der disziplinären Vielfalt lernen zu können. Dies ließ zwar dem Einzelnen viel Freiraum für die Entwicklung und Umsetzung eigener Ideen. Gleichwohl führte diese offene Situation gerade am Projektstart zu Unsicherheiten und erhöhte die subjektiv empfundene Belastung der Teammitglieder. Das relativ hohe Maß an Unbestimmtheit und Unsicherheit spiegelte sich letztlich auch in der vertraglichen Situation der Beteiligten wider. Da keine bindenden Verträge abgeschlossen bzw. Aufträge erteilt wurden, kam es immer wieder zu Nachverhandlungen wegen der nachträglich höheren Arbeitsaufwände. Probleme bezüglich der Wissensintegration Aufgrund der unterschiedlichen Wissensdomänen hatten die Beteiligten zunächst Schwierigkeiten, ein gemeinsames Grundverständnis für das Projekt zu entwickeln. Dies gelang erst dann, als mit den ersten programmierten Prototypen Artefakte zur Verfügung standen, die das abstrakte Problem konkretisierten und so das Verständnis erleichterten. Allerdings musste das so gewonnene Grundverständnis mit jedem neu hinzugekommenen Teammitglied wieder von Neuem erarbeitet werden. Als problematisch für eine gemeinsame Wissensintegration zeichnete sich auch die verwendete Fachterminologie ab. Da teilweise gleiche Inhalte unterschiedlich benannt wurden, waren vielfach Missverständnisse innerhalb der Gruppe zu beobachten. Diese disziplinspezifische Problematik zeigte sich vor allem zu

92


Beginn des Projekts. Gerade in der Anfangsphase tat sich das Entwicklungsteam schwer, das fachspezifische Denken zu überwinden und sich in die Perspektive der anderen Disziplinen hineinzuversetzen. Dies wurde durch die Teamsprache Englisch zusätzlich erschwert. Die einzelnen Subteams führten daraufhin außerplanmäßige Vorbesprechungen durch, um sich zunächst einmal auf eine gemeinsame Position zu einigen, die dann im Projektteam gemeinsam vertreten werden konnte. Die Probleme der interdisziplinären Zusammenarbeit konnten jedoch letztlich durch eine hohe Motivation der Gruppe und ein starkes "Commitment" der beteiligten Teammitglieder überwunden werden. Dabei lassen die Untersuchungen darauf schließen, dass das hohe Maß an Motivation nicht zuletzt daraus resultiert, dass die Beteiligten neben einem kollektiv verbindlichen Ziel auch eigene, persönliche Ziele mit dem Projekt verfolgten, wie z. B. einen persönlichen Imagegewinn durch die Teilnahme an einer Ausstellung im Centre Pompidou. Dies motivierte selbst in schwierigen Phasen, in denen durchaus Zweifel am positiven Ausgang des Vorhabens zu vernehmen waren. Erfassung von Kooperationsproblemen nach Entwicklungsphasen Um das schon beschriebene Kooperationsmodell mit seinen drei Teilprozessen der Kommunikation, Koordination und Wissensintegration zu validieren und das Auftreten von Kooperationsproblemen nach der jeweiligen Phase des Entwicklungsprozesses zu differenzieren, wurden im Verlauf der Fallstudie auftretende Probleme der Teamkooperation erfasst. Abbildung 2.28 fasst die Ergebnisse auf einem aggregierten Niveau zusammen. Wie die Abbildung zeigt, liegt der Schwerpunkt der identifizierten Kooperationsprobleme in den beiden Bereichen Koordination und Wissensintegration. Hier wiederum treten die Anforderungen je nach Entwicklungsphase sehr unterschiedlich auf: Die Koordinationsanforderungen steigen erst mit dem Verlauf des Projekts an, da sich die Komplexität des Projekts erst mit der wachsenden Aufgabenverteilung und Differenzierung der Arbeitsergebnisse erhöht. Dagegen zeigen sich Probleme im Bereich Wissensintegration von Anfang an als bedeutsam, da schon in der Konzeptionsphase die unterschiedlichen Vorstellungen über Ziele und Vorgehen des Projektes aufeinander prallen. Die dritte Projektphase, in welcher die Anforderungen an die Koordinations- und Wissensintegrationsleistungen des Teams erheblich ansteigen, beinhaltet die Herstellung des ersten physischen Prototypen. Hier nehmen die gedanklichen Vorstellungen konkrete Gestalt an und bilden gleichsam eine Projektionsfläche, auf der die Teammitglieder ihre unterschiedlichen


93

Sichtweisen stärker konkretisieren können, als dies vorher im abstrakten Diskussionsraum der Fall war. Dies hat zur Folge, dass durch die am Prototyp transparenter werdenden Gestaltungsoptionen (z.B. in Form von Abhängigkeiten zwischen einzelnen Funktionen) die gegensätzlichen Vorstellungen viel stärker zum Vorschein kommen und der Abstimmungsprozess erst richtig an Dynamik gewinnt.

Abb. 2.28. Probleme der Teamkooperation nach Entwicklungsphasen und Teilprozessen der Kommunikation, Koordination und Wissensintegration

2.4.6 Handlungsempfehlungen aus Studie 1 und 2 Die Erfahrungen und Ergebnisse aus einer internationalen und interdisziplinären Kooperation im Bereich der digitalen Medienkunst stehen im Einklang mit Ergebnissen aus Untersuchungen der vorherigen Förderperioden. Aufgrund der hohen Innovativität und Komplexität der Aufgabe, der sehr heterogenen Teamzusammensetzung und der fehlenden Teamerfahrung fast aller Mitglieder waren die Anforderungen an die Kooperationsfähigkeit der Teammitglieder außerordentlich hoch. An die Projektleitung stellte dies hohe Anforderungen zur Unterstützung der Teilprozesse Kommunikation, Koordination und Wissensintegration. Zur Bewältigung dieser komplexen Arbeitsituation konnten im Verlauf der Untersuchung spezielle Strategien identifiziert werden, die sich wie folgt zusammenfassen lassen:

94


x Präzise Definition der Aufgaben und Klärung der individuellen Beiträge, z. B. gemeinsame Projektentwicklung in einem einwöchigen Workshop x Vertrauensaufbau am Anfang des Projekts, z. B. gemeinsamer Kick-off, stufenweise Integration der Mitglieder x Dokumentation der Arbeiten und Besprechungen im Projektverlauf x Klare Organisation von Besprechungen x Systematische Feedbackschleifen x Förderung des Perspektivenwechsels x Anregung der Kommunikation auch innerhalb der Untergruppen des Teams, nicht nur über den Projektleiter x Frühzeitige Einbindung neuer Teammitglieder in den Prozess der Wissensintegration x Konsolidierung einer gemeinsamen Wissensbasis in Subteams x Möglichst frühzeitige Erstellung eines (ggf. rudimentären) Prototypen, um das gemeinsame Grundverständnis für die Entwicklungsaufgabe zu fördern x Verknüpfung des Gesamtziels mit individuellen Zielvorstellungen zur Erhöhung der intrinsischen Motivation x Qualifizierung des Teamleiters zur Unterstützung der Kooperationsprozesse. 2.4.7 Ergebnisse der Untersuchung von Auswirkungen fachlicher Teamheterogenität (Studie 3) Die hier dargestellte Studie verfolgte das Ziel, die Auswirkungen der fachlichen Durchmischung von interdisziplinären Entwicklungsteams zu analysieren, um Barrieren und Unterstützungsmöglichkeiten identifizieren zu können. Untersuchte Stichprobe Beteiligt waren an der Studie sieben interdisziplinär zusammengesetzte Arbeitskreise (AKs), die sich im Rahmen von Sonderforschungsbereichen am Institut für Arbeitswissenschaft und Technologiemanagement (IAT) der Universität Stuttgart und der Technischen Universität Karlsruhe gebildet hatten. Zwei Arbeitskreise entstammten dem Sfb 374 („Rapid Product Development“, Universität Stuttgart), vier dem Sfb 467 („Wandlungsfähige Produktionssysteme im turbulenten Umfeld“, Universität Stuttgart) und einer dem Sfb 425 („Elektromagnetische Verträglichkeit in der Medizintechnik und Fabrik“, TU Karlsruhe). Insgesamt wurden Daten von 41


95

Personen ausgewertet, wobei sich die Arbeitskreise aus durchschnittlich 6.7 Personen zusammensetzten. Kooperationsprobleme nach fachlichen Disziplinen Wie im Kooperationsmodell postuliert wird, ist die Entstehung von Problemen im Zuge der Wissensintegration umso wahrscheinlicher, je unterschiedlicher die mentalen Modelle der Beteiligten sind. Aus diesem Grund wurde der fachliche Hintergrund der Probanden, der die mentalen Modelle maßgeblich beeinflusst, in Hinsicht auf die interdisziplinären Paarungen in Gesprächsabschnitten mit Konfliktaufkommen untersucht (Abb. 2.29.).

Abb. 2.29. Anteil beobachteter Probleme nach disziplinären Paarungen der Teammitglieder

Einzeldisziplinen wurden zu diesem Zweck zu den übergeordneten Gruppen Naturwissenschaften (Nat), Ingenieurwissenschaften (Ing), Sozialwissenschaften (Soz) und Wirtschaftswissenschaften (Wi) zusammengefasst. In Abbildung 2.29 ist der prozentuale Anteil von Problemen für die unterschiedlichen Paarungen von Disziplinen dargestellt. So ist etwa die Anzahl von Problemen zwischen Natur- und Sozialwissenschaften wesentlich größer als zwischen zwei Vertretern der Ingenieurswissenschaften. Es lässt sich somit zeigen, dass die Häufigkeit von beobachtbaren Problemen in Abhängigkeit von den an der Kommunikation beteiligten Disziplinen betrachtet werden sollte. Während Interaktionen zwischen Sozialwissenschaften häufig an unterschiedlich verwendeten Fachbegriffen scheitern, sind zwischen Vertretern der Naturwissenschaften unbekannte Fachbegriffe die häufigste Ursache.

96


Einzelne Problemursachen scheinen demnach nicht für das Gesamtteam relevant zu sein, sondern manifestieren sich primär innerhalb einzelner, spezifischer disziplinärer Paarungen. Dies kann als Hinweis darauf gewertet werden, dass es für das Auftreten von Problematiken nicht so sehr auf die Anzahl von Fachrichtungen im Team ankommt, sondern vielmehr auf ihre Art bzw. ihre Unähnlichkeit. Die Befunde zur Auswirkung von funktionaler Heterogenität auf die Anzahl der Kooperationsprobleme zeigen, dass steigende Heterogenität mit einer deutlichen Zunahme an aufgabenrelevanten Problemen einhergeht. Während Studien an Arbeitsgruppen und Managementteams eine ähnliche Zunahme aufgabenrelevanter Probleme bei heterogeneren Teams fanden [2.56], [2.57], [2.91], ließen sich deren Aussagen für interdisziplinäre Forschungsteams nicht bestätigen. Im Gegensatz zu den zitierten Studien zeigte sich eine eindeutige negative Beziehung der Problemhäufigkeit zum Teamerfolg. Eine mögliche Erklärung für diese unterschiedlichen Befunde könnte im unterschiedlichen Ausmaß funktionaler Heterogenität in den Stichproben zu suchen sein. Die positive Wirkung aufgabenbezogener Konflikte wird meist zurückgeführt auf ihr Potenzial zur Klärung und Verdeutlichung von Standpunkten und Ansätzen. Zu vermuten ist, dass bei einer zu starken Abweichung der personenbezogenen Wissensbestände die Grundlagen fehlen, um eine gemeinsame Sicht der Aufgabe zu entwickeln, so dass sich das klärende Potenzial aufgabenrelevanter Konflikte hier nicht im gleichen Maße entfalten kann wie in homogeneren Teams. Problemursachen Im qualitativen Teil der Untersuchung wurden mittels Videoauswertung die Ursachen ermittelt, die in den Sitzungen der interdisziplinären Teams für Kooperationsprobleme verantwortlich waren. Wie wichtig die teaminterne Klärung von Vorstellungen ist, welche die Teammitglieder aufgrund ihrer fachlichen Vorprägung oft implizit in die gemeinsame Diskussion einbringen, zeigen die in der Abb. 2.30 aufgeführten Problemursachen. Sei es die fehlende Abstimmung der einzusetzenden Methoden, der häufig verwendeten Definitionen oder kompletter Lösungsansätze: So selbstverständlich die eigenen Ansichten über „das richtige Vorgehen“ sind, so unverständlich scheint für den Einzelnen der Widerspruch der anderen Teammitglieder gegen die eigenen Vorstellungen zu sein. Um aus der Konkurrenz der fachspezifischen Ansätze keine Beeinträchtigung der Kooperation entstehen zu lassen, ist die offene und aktive Beschäftigung mit den scheinbaren Widersprüchen notwendig. Werden fachfremde Inhalte dagegen nicht akzeptiert, wird der inhaltlichen Ausei-


97

nandersetzung ausgewichen oder werden disziplinfremde Argumente ignoriert, wirkt sich dies mit hoher Wahrscheinlichkeit negativ auf das Ergebnis wie auch auf das Arbeitsklima des Teams aus. Kategorie der Problemursache

Beschreibung

Fehlende Abstimmung der Methodenwahl

Einseitige Übernahme von fachspezifischen Methoden oder Konzepten, ohne deren Eignung für die vorliegende Problemstellung aus den unterschiedlichen Perspektiven zu prüfen bzw. deren Einsatzkonzept anzupassen. Disziplinspezifi- Es findet keine Klärung über Begriffe mit disziplinspezifisch unterscher Gebrauch schiedlichen Gedankenmodellen statt. Z.B. steht der Begriff von Definitionen „Motivation“ im Bereich Psychologie mit sehr unterschiedlichen Theorien und Modellen in Bezug und bezeichnet sehr komplexe Zusammenhänge. Dagegen wird der gleiche Begriff im Sprachgebrauch anderer Disziplinen vergleichsweise reduktionistisch verwendet. Einsatz von ferti- Die in Subteams oder durch Einzelpersonen erarbeiteten Lösungen gen Lösungsan- verhinderten das gemeinsame Nachvollziehen von Denkschritten sätzen ohne und den Aufbau eines gemeinsamen Wissens (common grounds) vorherige über Methoden, Modelle und Begriffsdefinitionen. Die VerständnisAngemessenheit des Vorgehens ist für andere Disziplinen in der klärung fertigen und komplexen Lösung kaum mehr nachprüfbar. Mangelnde Ak- Finden ließ sich mangelnde Anerkennung disziplinspezifischer zeptanz Inhalte in den untersuchten Arbeitskreisen zwar nicht in Form disziplinoffenen Widerspruchs, wohl aber in z.T. impliziten Formen von spezifischer Nichtanerkennung. Dazu gehörten z.B. das Nichteingehen auf Inhalte Methodenkritik oder die Bezeichnung von einzelnen Aussagen und Schlussfolgerungen als „falsch“, weil sie nicht der Sichtweise der eigenen Disziplin entsprachen. Ausweichverhalt Vermeidung von verbindlichen Definitionen oder Verbleiben, um in en der aktuellen Situation entweder Konflikte zu entschärfen oder kurzfristig zu einer Lösung zu gelangen. Stattdessen wurden möglichst allgemeine und unverbindliche Formulierungen gewählt. Dadurch wird eine konsistente Terminologie und damit ein verlässliches gemeinsames Verständnis von Sachverhalten und Konzepten verhindert. Vernachlässigun Werden Sachverhalte nicht geklärt, die aus Sicht der eigenen g fachfremder Disziplin irrelevant scheinen, kann dies zum Abbruch einer Argumente eventuell für das Gesamtteam relevanten Diskussion und damit zu einer Einschränkung der Wissensvermittlung führen.

Abb. 2.30. Qualitativ ermittelte Problemursachen für Kooperationsprobleme in interdisziplinären Teams

98


Erfassung der Heterogenität von Entwicklungsteams Zur Bestimmung des Ausmaßes funktionaler Heterogenität im Team wurde der disziplinäre Hintergrund, d. h. die Art der Ausbildung der Teammitglieder von jedem Teilnehmer über das Item „Studierte Fächer / Fachkombinationen“ erfragt. In den Arbeitskreisen waren insgesamt elf verschiedene Disziplinen vertreten. Die Anzahl verschiedener Disziplinen in den Arbeitskreisen lag bei durchschnittlich drei Disziplinen und bewegt sich zwischen minimal zwei und maximal fünf (Abb. 2.31.). Disziplin AK 1 Maschinenbau BWL Elektrotechnik 3 Physik 1 Informatik Psychologie Soziologie Mathematik Automatisierungstechnik Wirtschaftsingenieur Technische Kybernetik Kommunikationswissenschaft Unbekannt N 4 2 ¦ Disziplinen HT 0.56

AK 2 2

AK 3 1

3

2

AK 4 1 2

2 1

AK 5 3 1 1 1

1

AK 6 1 1

1 2 1

1 1

5 2 0.67

6 5 1.01

AK 7 7

1

1 6 4 1.32

6 4 1.25

5 4 1.30

5 15 >4 0.68

Abb. 2.31. Disziplinen nach Arbeitskreisen

Das Ausmaß der funktionalen Heterogenität eines Arbeitskreises wurde bestimmt über den von Teachman [2.117] entwickelten Heterogenitätsindex HT:

HT

i

¦ Pi (ln Pi ) i 1

mit i Anzahl unterschiedlicher Disziplinen im Team und Pi Wahrscheinlichkeit des Auftretens einer Einzeldisziplin im Team, wobei Pi sich errechnet über die Anzahl der Personen im Team mit der gleichen Disziplin geteilt durch die Gesamtzahl an Personen im Team. Der Index gibt bei


99

steigendem HT ein zunehmendes Ausmaß an Heterogenität wieder. Bei vollständiger Homogenität wird HT = 0. Erfassung der Wissensintegration Wissensintegration als wesentlicher Teilprozess der Kooperation [2.114] wurde über eine modifizierte Form der von Steinheider et al. [2.115] entwickelten Kooperationsskala erfasst. Die ursprüngliche Kooperationsskala besteht aus 16 Items für Koordination (alpha = .92), 15 Items für den Bereich Kommunikation (alpha = .84) und 17 Items für Wissensintegration (alpha = .95; N = 86). Zusätzlich enthält sie ein Item zur Motivation. Die Items sind durchgehend negativ formuliert. Für die vorliegende Untersuchung wurde die Hälfte der Items positiv umformuliert. Beispielfragen für die Subskalen lauten: „Teammitglieder halten projektrelevante Ideen und Informationen zurück“ (Koordination), „Es ist im Team möglich, Schwierigkeiten offen anzusprechen“ (Kommunikation), „Teammitglieder sind bereit, sich auf eine andere Sichtweise einzulassen“ (Wissensintegration) und „Teammitglieder zeigen zu wenig Engagement“ (Motivation). Die modifizierte Kooperationsskala hat einen alpha-Wert von .75 für Kommunikation, .76 für Koordination und .78 für Wissensintegration (N = 34). Zusammenhang zwischen Wissensintegration und Teamerfolg Als vermittelnder Faktor zwischen Heterogenität und Teamerfolg sowie der Anzahl beobachtbarer Probleme wurde die Wissensintegration eingestuft. Wissensintegration wird dabei innerhalb des Modells von Steinheider et al. [2.114] als unabhängig von den beiden anderen Kooperationsfaktoren Kommunikation und Koordination betrachtet. Wie die Korrelationen zwischen den Kooperationsaspekten darstellen, zeigt sich diese Annahme in dieser Arbeit weitgehend bestätigt (r = .30; p < .10 mit Kommunikation; r = 06; p = .70 mit Koordination). Der Erfolg der Arbeitskreise wurde über eine fünf Items umfassende Skala in Form der Selbsteinschätzung durch die Teammitglieder erfasst. Die Einschätzung erfolgte auf einer fünfstufigen Skala von 1 (stimmt nicht) bis 5 (stimmt völlig). Die Items beziehen sich auf verschiedene Aspekte des Arbeitsprozesses (z. B. „Wie schätzen Sie die Arbeit im Team ein bezüglich: Ausmaß der Zielerreichung?“). Die interne Konsistenz der Skalen lag bei .70 (N = 40). Die Fremdeinschätzung des Teamerfolgs wurde durch die Arbeitskreisleiter (N = 7) durchgeführt.

100


Der postulierte Einfluss der Wissensintegration auf den Gesamterfolg ließ sich sowohl in der Selbst- wie in der Fremdeinschätzung finden (Abb. 2.32.).

Erfolg Selbsteinschätzung 1. Gesamt 2. Effektivität 3. Qualität 4. Schnelligkeit 5. Zielerreichung 6. Atmosphäre

Kommunikation

Koordination

Wissensintegration

-.08 -.25 -.09 -.03 .20 -.02

.12 -.36 -.04 .21 .57** -.14

.42** .75** .70** -.05 -.01 .79**

.16 .21 .49** .63** -.19 .02

.25 .37* .62* .12 -.11 -.16

Erfolg Fremdeinschätzung 1. Gesamt .37* 2. Effektivität .80** 3. Qualität .62** 4. Schnelligkeit .01 5. Zielerreichung .22 6. Atmosphäre -.23 * p < .05; ** p < .01; einseitiger Test

Abb. 2.32. Korrelationen zwischen Teilaspekten der Kooperation und interner bzw. externer Einschätzung des Teamerfolgs

Vor allem Effektivität und Qualität zeigen in beiden Einschätzungen signifikante positive Korrelationen. Auch wenn der extern beurteilte Gesamterfolg lediglich eine tendenzielle Beziehung zur Wissensintegration aufweist, lässt sich aufgrund des Gesamtbildes dennoch davon ausgehen, dass Wissensintegration mit Teamerfolg in entscheidenden Aspekten zusammenhängt. Die Zahlen, die in Abb. 2.32 wiedergeben werden, enthalten eine weitere interessante Aussage. Vergleicht man die Unterschiede, die zwischen den Korrelationen der Selbst- und der Fremdeinschätzung mit der Teamheterogenität entstehen, ergeben sich auf der Ebene der Teammitglieder weitaus geringere Korrelationen als auf der Ebene der Teamleiter, wie Abb. 2.33 zeigt.


101

Abb. 2.33. Differenzen zwischen teaminterner und teamexterner Erfolgseinschätzung

Insbesondere in den Variablen Effektivität, Zielerreichung und Atmosphäre weisen die Einschätzungen der Teamleiter eine deutlich höhere (negative) Korrelation mit der Heterogenität des Teams auf, als das bei den Teammitgliedern selbst der Fall ist. Dies bedeutet, dass die Erfolgseinschätzung der Teamleiter bei heterogenen Teams sehr viel negativer ausfällt, als die der Teammitglieder. Dies legt die Vermutung nahe, dass Teamleiter aufgrund ihrer Leitungs- und Moderationsfunktion sowie ihrer Ziel- und Effizienzverantwortung sehr viel stärker die Probleme erkennen, die sich (erkennbar oder nicht erkennbar) durch die Heterogenität des Teams ergeben. Für Teammitglieder scheint dagegen die Ursache für geringen Teamerfolg nicht im gleichen Ausmaß mit der Unterschiedlichkeit der Teamkollegen zusammen zu hängen. Das aus den Beobachtungen der

102


Teamsitzungen stammende Zitat „das sind halt immer schwierige Sitzungen mit der Gruppe“ unterstützt diese Annahme. Kooperationsprobleme werden demnach zwar von den Teammitgliedern erkannt, werden aber nicht mit der Unterschiedlichkeit der einzelnen Vorstellungen in Zusammenhang gebracht. Beobachtete Strategien der Wissensintegration In der schriftlichen Befragung der interdisziplinären Teammitglieder wurden zwei Fragen mit offenem Antwortformat vorgegeben, um Strategien der Wissensvermittlung und der Verständnissicherung speziell gegenüber Partnern anderer Fachbereiche abzufragen („Wie gehen Sie selbst vor, wenn Sie Fachwissen vermitteln wollen, bei dem Sie davon ausgehen können, dass es den anderen Teammitgliedern nicht bekannt ist? – Wie stellen Sie sicher, dass Sie verstanden werden?“). Die Antworten aller Versuchspersonen wurden unabhängig von ihrer Teamzusammengehörigkeit inhaltlich gruppiert. Wie Abb. 2.34 zeigt, waren Nennungen im Bereich Art der Vermittlung erwartungsgemäß am häufigsten mit 76.7% aller Nennungen von 76.9% aller Personen. Bilder und Beispiele schienen hier jeweils 28.2% der Personen als bevorzugte Vorgehensweise, während nur 17.9% auf den spezifischen Wissenstand Bezug nahmen. Hervorzuheben ist auch, dass auf prinzipielle Einfachheit der Vermittlung Wert gelegt wurde (23.1% aller Personen), während nur 15.4% konkret auf zu fachspezifische Erläuterungen verzichten wollten. Dass bei der Wissensvermittlung fachspezifische Inhalte sich als problematisch erweisen könnten, wurde demnach nur von wenigen (insgesamt 17.9%) Personen erkannt bzw. explizit thematisiert. Konkrete Strategien zur Vermittlung wurden nur von vier Personen genannt (10.3 %). Neben dem Hinweis auf die Fachspezifität von Inhalten wurde meist ein Vorgehen „vom Allgemeinen zum Spezifischen“ angestrebt, was dem sukzessiven Aufbau einer gemeinsamen Wissensbasis entspricht. Einen Überblick über die genannten Strategien zur Verständnissicherung gibt Abb. 2.35.


Kategorie Art der Vermittlung Bilder Beispiel einfach vermitteln auf Wissensstand eingehen nicht fachspezifisch erklären Metapher, Analogie, Abstraktion kurz erläutern Grundlagen erklären Strukturierung Vorführung am Objekt Überblick geben Medien der Vermittlung Folien, Präsentation Handout Email Inhalt der Vermittlung Erläuterung von Begriffen Spezifische Strategie v. Allgemeinen z. Speziellen Hinweis auf 'Fachspezifität’ Kontrolle nachfragen Diskussion ¦

Häufigkeit der Nennungen abs. % 56 76.7 11 15.1 11 15.1 9 12.3 7 9.6

103

Häufigkeit über Personen [N =39] abs. % 30 76.9 11 28.2 11 28.2 9 23.1 7 17.9

6

8.2

6

15.4

6

8.2

6

15.4

3 3 2 1

4.1 4.1 2.7 1.4

3 3 2 1

7.7 7.7 5.1 2.6

1 8

1.4 11.0

1 7

2.6 18.0

5 2 1 1

6.8 2.7 1.4 1.4

5 2 1 1

12.8 5.1 2.6 2.6

1

1.4

1

2.6

4 3

5.8 4.1

4 3

10.3 7.7

1

1.4

1

2.6

4 3 1 73

5.5 4.1 1.4 100.0

4 3 1 39

10.3 7.7 2.6 100.0

Abb. 2.34. Absolute und prozentuale Häufigkeiten der genannten Strategien zur Wissensvermittlung

104


Kategorie Kontrolle nachfragen Reaktionen etc. beobachten Pausen, um Dialog zu ermöglichen Partneraktivität erklären lassen Feedback abwarten Diskussion Proaktives Handeln vorher gut erklären vorher Begriffe erläutern Dokumentation Protokoll erstellen Spezifische Strategie Inhalte wiederholen Nicht möglich ¦

Häufigkeit der Nennungen Abs. % 43 72.9 32 54.2 10 17.0

Häufigkeit über VPs [N =39] Abs. % 32 82.1 32 82.1 10 25.6

1

1.7

1

2.6

6 4 1 1 3 2 1 2 2 2 2 3 59

10.2 6.8 1.7 1.7 5.1 3.4 1.7 3.4 3.4 3.4 3.4 5.1 100.0

6 4 1 1 3 2 1 2 2 2 2 3 39

15.4 10.3 2.6 2.6 7.7 5.1 2.6 5.1 5.1 5.1 5.1 7.7 100.0

Abb. 2.35. Absolute und prozentuale Häufigkeiten der genannten Strategien zur Verständnissicherung

Kategorien waren hier Kontrolle des Verständnisses, Warten auf Partneraktivitäten, eigenes proaktives Handeln, Dokumentation und die Anwendung spezifischer Strategien. Daneben hielten immerhin drei Personen (7.7 %) die Verständnissicherung generell für nicht möglich. Die verbleibenden Personen versuchten mehrheitlich über die aktive Kontrolle das Verständnis abzusichern. Am häufigsten wurde hierbei das Nachfragen genannt (54.2% aller Strategien), danach die Beobachtung von Reaktionen und Antworten des Partners (17.0 %). Eine eigene aktive Rolle des Partners wurde nur von 15.4% aller Personen erwogen, meist im Sinne eines Erklären-Lassens von Sachverhalten (10.3 %). Weitere Angaben betrafen entweder proaktives Handeln wie gutes Erklären im Vorfeld (3.4 %) oder aber die Dokumentation zur Sicherung des Erreichten (3.4 %). Als einzige spezifische Strategie ist das Wiederholen von Sachverhalten anzusehen, welche jedoch nur von zwei Personen (5.1 %) genannt wurde. Bei Betrachtung der tatsächlich im Team verwendeten Strategien zur Wissensvermittlung und Verständnissicherung fielen einige Diskrepanzen zu den selbstberichteten Daten auf. Während etwa der Einsatz von Skizzen


105

und Bildern bei Erklärungen neuer, komplexer Sachverhalte relativ üblich war, wurde die verbale Vermittlung von Inhalten entgegen den Angaben kaum an den Wissenstand bzw. die fachspezifischen Eigenheiten des Adressaten angepasst. Die explizite Bezugnahme auf die fachspezifische Bedeutung eines Zusammenhangs aus der eigenen Fachrichtung wurde nur in zwei Fällen beobachtet. Die Kontrolle des Verständnisses durch Nachfragen, welche die am häufigsten genannte Strategie im Bereich Verständnissicherung war, wurde real kaum eingesetzt. „Erklären lassen“ als Strategie kam überhaupt nicht vor. Die Wichtigkeit des Bereiches „Begriffsklärung“ für die Teamarbeit zeigt sich jedoch deutlich, indem 56.2% aller beobachteten Probleme entweder mit unbekannten oder anders verwendeten Fachbegriffen zusammenhängen. Im Gegenzug sind nicht einmal zehn Prozent aller Strategien (Videodaten) inhaltlich auf die Vermittlung oder Klärung von Begriffen ausgerichtet (9.8% aller Strategien). Der größte Teil der Strategien bezog sich dagegen entweder auf den Arbeitsinhalt, (60.9 %) oder auf die zu verwendende Methodik (18.5 %). Die qualitativen Analysen der Arbeitskreisarbeit haben weiterhin gezeigt, dass Forschungsteams sehr unterschiedlich auf das Problem der Interdisziplinarität reagieren. Ein unkritischer Umgang mit diesem Thema, der die Differenzen der disziplinspezifischen Sichtweisen weitestgehend ignoriert, kann zu einer Vielzahl von Problemen führen, die auf das Gelingen interdisziplinärer Teamarbeit im starken Maße hemmend wirken. Besonders zu erwähnen sind hier Aspekte wie die mangelnde Akzeptanz der Expertise anderer Disziplinen, die Verwendung bzw. das Beharren auf nicht allgemein akzeptierten Methoden einer Einzeldisziplin oder die Vermeidung von Festlegungen in Bezug auf Begriffe und Vorgehensweisen. Der Vergleich der am stärksten heterogen zusammengesetzten Teams brachte Anhaltspunkte dafür, welche Strategien für einen effektiveren Umgang mit Interdisziplinarität in der Forschung hilfreich sind. Darunter fallen sowohl die frühe, eindeutige Klärung von Fachbegriffen als auch die der Schnittstellen zwischen Teammitgliedern. Zu letzteren gehört auch die Frage, welche Inhalte disziplinär und welche interdisziplinär bearbeitet werden sollten. Zentral dürfte auch das gemeinsame Erarbeiten disziplinär komplexer Sachverhalte im Team sein. Visualisierungen scheinen weiterhin hilfreich, um diese komplexen Sachverhalte zu erklären und späterhin zu dokumentieren.

106


2.4.8 Handlungsempfehlungen zur Wissensintegration aus Studie 3 Folgende Strategien und Handlungsempfehlungen zur Unterstützung der Wissensintegration lassen sich aus der dargestellten Studie ableiten: x Das Bewusstsein für die Herausforderungen der fachlichen Heterogenität ist in der Regel nur gering ausgeprägt. Hier sollte die Notwendigkeit zur konstruktiven Auseinandersetzung mit den - fachlich bedingten Unterschieden betont werden. Den Teammitgliedern in interdisziplinären Teams sollte von Anfang an bewusst sein, dass sie mit gegensätzlichen Vorstellungen über die Gestaltung des Projekts konfrontiert werden, um eine produktive Einstellung zur Lösung dieser Gegensätze zu erreichen. x Die Anpassung der eigenen Ausführungen an den Wissenstand bzw. die fachliche Perspektive des Empfängers erfolgt den Ergebnissen nach in der Regel nur sehr selten. Die Fähigkeit zum Hineinversetzen in die Denkweise der anderen Teammitglieder (fachliche Empathiefähigkeit) erleichtert jedoch die interdisziplinäre Verständigung und sollte deshalb gefördert werden. x Schnittstellen zwischen Teammitgliedern sollten frühzeitig geklärt werden, d.h. an welchen Stellen Informations- oder Abstimmungsbedarfe und gegenseitige Abhängigkeiten bestehen. x Besondere Bedeutung kommt der Explizierung von implizitem Wissen bzw. unausgesprochener Annahmen der einzelnen Experten zu. Dies bezieht sich auf alle Wissensebenen im Kooperationsmodell (know-what, know-how, know-why, care-why). So muss ein für alle Teammitglieder verbindliches Verständnis sowohl über Begriffsdefinitionen als auch über einzusetzende Maßnahmen, Hintergrundzusammenhänge und Zielvorstellungen des Projekts geschaffen werden. x Entgegen der allgemein anerkannten Notwendigkeit der Klärung unterschiedlicher Vorstellungen im Team findet die diesbezügliche Strategie des „Nachfragens“ den Ergebnissen zufolge nur selten statt. Hier kommt es darauf an, mögliche Barrieren für diese Strategie zu beseitigen. Dies kann z. B. dadurch geschehen, dass die Offenbarung von Nicht-Wissen von ihrem implizit negativem Charakter befreit wird. Wichtig ist hier ein konstruktives und offenes Verhalten beim Auftreten von Nichtwissen und Nichtverstehen, um die Hemmschwelle für das Nachfragen zu senken. x Notwendig erscheint eine explizite Hervorhebung der Chancen und Herausforderungen von interdisziplinärerer Teamarbeit. Es gilt ein Arbeitsklima zu schaffen, welches hilft, dass die Teammitglieder die u.U.


x

x

x

x

x

x

x

107

mühsame Integration ihrer verschiedenen Perspektiven als notwendigen und produktiven Teil enger Kollaboration verstehen. Der Strategieeinsatz sollte insbesondere am Anfang der Teamarbeit die Bildung einer gemeinsamen Wissensbasis (common ground) über Begriffe, Zusammenhänge und Ziele der Projektarbeit unterstützen. Insbesondere bei RPD-Projekten, in denen Effektivität und Qualität eine hohe Bedeutung haben, sollte die Wissensintegration wirkungsvoll unterstützt werden. Bei RPD-Projekten, in denen Schnelligkeit und Zielerreichung eine hohe Bedeutung haben, sollte die potenziell problemverstärkende Wirkung von fachlicher Heterogenität beachtet werden (siehe nächster Punkt). Um Beeinträchtigungen der Effektivität von RPD-Prozessen zu vermeiden, sollte bei hoher fachlicher Heterogenität im Team die Wissensintegration durch Einsatz unterstützender Strategien verstärkt werden. Umgekehrt ist bei erkennbar hohen Anforderungen an die Wissensintegration, die z. B. durch eine hohe Problemkomplexität und ungünstige Rahmenbedingungen entstehen, auch die Reduzierung der teambezogenen Heterogenität durch eine fachlich homogenere Besetzung der RPDTeams möglich. Durch Beachtung der spezifischen fachlichen Interaktionskonstellationen (z. B. Dyaden mit der Kombination wirtschafts- und naturwissenschaftlicher Fachhintergrund) sollten Strategien frühzeitig und gezielt bei denjenigen Teammitgliedern angesetzt werden, zwischen denen erste Kooperationsprobleme erkennbar werden. Bei der Wirkungsbeurteilung der eingesetzten Strategien sowie des Teamerfolgs sollten die unterschiedlichen Bewertungsperspektiven von Teammitgliedern, Teamleitern und übergeordneten Personen berücksichtigt werden. Durch Klärung der Frage, welche Aufgabenpakete disziplinär und welche interdisziplinär bearbeitet werden sollen, sollte der Prozess der Wissensintegration entlastet werden.

Die hier beschriebenen Handlungsempfehlungen flossen in die nachfolgend dargestellten Trainingsmodule zur Unterstützung der Wissensintegration ein, die konkrete Hilfestellung zur Optimierung des Wissensaustauschs in Produktentwicklungsteams leisten.

108


2.4.9 Umsetzung der Ergebnisse aus den Studien in Unterstützungsinstrumente Die Ergebnisse der Arbeiten zeigen häufige Ursachen für Barrieren der Kooperation und der Wissensintegration auf, die besonders in interdisziplinären Entwicklungsteams auftreten. Um die dadurch identifizierten Stellhebel für die Unterstützung wissensintegrativer Prozesse zu nutzen, wurde ein Trainingskonzept für die Mitglieder von Produktentwicklungsteams entwickelt. Dieses beinhaltet zwei Modulblöcke: Im ersten wird die aktive Entwicklung der gemeinsamen Wissens- und Erfahrungsbasis vorangetrieben (Abb. 2.36.), im zweiten die Steuerung der Wissensintegration auf der Verhaltensebene vermittelt (Abb. 2.37.).

Abb. 2.36. Module zur Förderung der gemeinsamen Wissensbasis in Produktentwicklungsteams.

Die Module des ersten Blocks beinhalten Trainingsübungen, in denen die Bildung der gemeinsamen Wissensbasis vorangetrieben wird. Dieser Schritt soll – entsprechend des Brücken-Modells der Wissensintegration [2.68] – die Voraussetzung für die innovative Kombination des eigentlichen Expertenwissens schaffen, und zwar schneller und systematischer, als dies normalerweise abläuft. Hierzu


109

x werden die impliziten Vorstellungen der Teammitglieder sichtbar gemacht (Modul 1), x projektrelevantes Erfahrungswissen identifiziert (Modul 2), x die Kommunikation von fachspezifischem Expertenwissen unterstützt (Modul 3), x die wichtigsten projektrelevanten Wissenstransferprozesse an teaminternen und -externen Schnittstellen aufgezeichnet (Modul 4), x Barrieren identifiziert, die den effizienten Wissensaustausch zwischen den Teammitgliedern erschweren (Modul 5) und x Maßnahmen zur Überwindung der Wissensbarrieren in Zusammenarbeit mit dem Team entwickelt (Modul 6).

Abb. 2.37. Module zur Steuerung der Wissensintegration auf der Verhaltensebene.

Da die Untersuchungen gezeigt haben, dass Barrieren der Wissensintegration zwar zunächst durch die fachliche Teamheterogenität ausgelöst wer-

110


den, die tatsächlichen Auswirkungen auf den Kooperationsprozess aber entscheidend durch das Verhalten der Teammitglieder geprägt werden, zielt der zweite Modulblock auf die verhaltensorientierte Steuerung der Wissensintegration. Mit den darin versammelten Methoden sollen die unterschiedlichen Wissens- und Erfahrungsbestände einfacher miteinander verknüpft und der daraus resultierende Integrationsaufwand reduziert werden. Um dieses Ziel zu erreichen, x wird die Schnittmenge aus dem im Team prinzipiell verfügbaren Expertenwissen und aus dem für das Projekt relevante Wissen identifiziert (Modul 7), x fachspezifisches Wissen auch für Fachfremde verständlich vermittelt (Modul 8), x abstrakte Vorstellungen schnell konkretisiert, visualisiert und, soweit möglich, in erste Prototypen überführt (Modul 9), x die häufig auftretenden Missverständnisse durch verstärkte Verständniskontrolle vermieden (Modul 10), x der systematische Perspektivwechsel zwischen den Teammitgliedern – insbesondere in bezug auf die besonderen Sichtweisen der Fachdisziplinen und Unternehmensfunktionen – gefördert (Modul 11) und x die für eine effiziente Wissensintegration erforderliche Teamkultur etabliert, wozu auch die Definition der Führungsaufgaben gehört, mit denen der Wissensaustausch unterstützt werden kann (Modul 12). Die Übungen aus den einzelnen Modulen können bedarfsgerecht in das Training integriert werden, so dass je Trainingstag eine Mischung aus mehreren Modulen und auch aus beiden Modulblöcken möglich ist. Priorität hat bei der konkreten Konzeption der Übungsabfolge die Abstimmung der Übungsinhalte auf die Wissensintegrationsbarrieren, die in einer vorhergehenden Analyse identifiziert werden. Je nach Produktentwicklungsteam und den jeweiligen Rahmenbedingungen des RPD-Kontexts können diese Barrieren unterschiedlich ausfallen und machen eine entsprechende Ausrichtung der Trainingsinhalte erforderlich. 2.4.10 Ausblick Die zukünftige Umsetzung der Trainingsmodule für die Wissensintegration in Produktentwicklungsteams, die aus den Ergebnissen des Teilprojekts abgeleitet wurden, wird im realen RPD-Kontext durchgeführt. Zielstellung ist dabei die Anpassung, Anwendung und Evaluation der Instrumente, um


111

eine zielorientierte Unterstützung des teambezogenen Wissenstransfers zu erreichen (Abb.2.38.).

Abb. 2.38. Vorgehen bei der Implementierung und Durchführung der Trainingsmodule zur Wissensintegration

Das Implementierungskonzept sieht daher ein zweistufiges Verfahren vor, das nach vorhergehender Analyse der wissensintegrativen Anforderungen (Arbeitspaket 1) zunächst die Anpassung der Module ermöglicht (Arbeitspaket 2), um diese bedarfsgerecht modifiziert mit den Produktent-

112


wicklungsteams als Teilnehmern anzuwenden (Arbeitspaket 3). Zuletzt erfolgt die Evaluation von Lern- und Transfereffekten der Teilnehmer sowie die Transfersicherung, welche die Verbreitung der erarbeiteten Erkenntnisse und Maßnahmen im Unternehmen fördert (Arbeitspaket 4). Wesentlich für die Wirksamkeit der Trainingseffekte ist dabei die vorhergehende Analyse des unternehmensspezifischen Produktentwicklungsprozesses und die darauf abgestimmte Anpassung der Trainingseinheiten. Da die Transfer- und Umsetzungswahrscheinlichkeit der Trainingsinhalte unmittelbar von deren aufwandsarmer Anwendbarkeit abhängt, kommt es darauf an, die konkreten wissensintegrativen Anforderungen an die Teammitglieder herauszuarbeiten, welche diese in ihrer Arbeit erleben. Unabhängig davon ist eine Sensibilisierung für Anforderungen der Wissensintegration erforderlich, die – wie die Ergebnisse des Teilprojekts zeigen – von den Teammitgliedern nicht immer bewusst wahrgenommen werden. 2.4.11 Zusammenfassung Ausgangspunkt der Arbeiten im Themenbereich »Wissensintensive Kooperationsprozesse bei der Entwicklung innovativer Produkte« war die Frage, wie die Kooperationsprozesse in Produktentwicklungsteams im Hinblick auf die spezifischen Anforderungen des Rapid Product Development optimiert werden können. Zunächst wurden die dafür relevanten Kooperations- und Wissensintegrationsprozesse untersucht und Modelle zur Abbildung dieser Zusammenhänge entwickelt. Kooperation wurden demnach definiert als Teamprozess, der aus den drei Teilprozessen Kommunikation, Koordination und Wissensintegration besteht. Die Unabhängigkeit der drei Teilprozesse voneinander wurde empirisch belegt. Weiterhin wurde der Prozess der Wissensintegration als ein zweistufiger Prozess beschrieben, in dem die Entwicklung einer gemeinsamen Wissensbasis im Produktentwicklungsteam den ersten und grundlegenden Schritt darstellt. Der zweite Schritt beinhaltet den eigentlichen kreativen Prozess, in dem das unterschiedliche Expertenwissen zusammengefügt und innovative Lösungen produziert werden. Dieser eigentliche innovative Prozess wurde jedoch als abhängig von dem vorhergehenden Schritt definiert, da ohne einen „gemeinsamen Nenner“ zwischen den Teammitgliedern in Hinsicht auf projektrelevante Wissensbereiche die Heterogenität des Teams die produktive Zusammenführung des Wissens erheblich behindert wird. Als Wissensebenen, die für die Bildung einer gemeinsamen Wissensbasis relevant sind, wurden die vier Bereiche „Ziel- und Priorisierungswissen“,


113

„Fach- und Zusammenhangswissen“, „Erfahrungs- und Umsetzungswissen“ sowie „Definitions- und Faktenwissen“ zugrunde gelegt. Um die besonderen Anforderungen des RPD-Produktentwicklungsansatzes nachvollziehen zu können, wurden u.a. zwei Fallstudien durchgeführt. In der ersten Studie wurden in einem AutomobilZulieferunternehmen die Kooperationskonstellationen der Produktentwicklungsteams untersucht. Die Anforderungen zur Unterstützung der Teamkooperation konnten dabei nach Art der Kooperationsebenen (kernteambasiert, kernteamübergreifend, betriebsübergreifend) sowie nach den Rahmenbedingungen (Heterogenität der Teamkonstellation, Kreativitätsförderlichkeit des Umfelds, Komplexität des Entwicklungsprozesses) differenziert werden. In der zweiten Studie wurde eine Längsschnittuntersuchung des Kooperationsprozesse in einem interdisziplinären Team durchgeführt, in dem eine hohe fachliche, funktionale und nationale Heterogenität vorlag. Es wurden spezifische Probleme in den Teilprozessen Kommunikation, Koordination und Wissensintegration erfasst und den Phasen des Produktentwicklungsprozesses zugeordnet. Die Ergebnisse bestätigten die Relevanz der Wissensintegration in Bezug auf Kooperationsprobleme sowie die Bedeutung der Prototypisierungsphase für die Wissensintegration. Um die Zusammenhänge der Kooperations- und Wissensintegrationsprozesse an einer größeren Stichprobe zu analysieren, wurden die Arbeitstreffen von insgesamt sieben interdisziplinär zusammengesetzten Arbeitskreisen aus zwei Sonderforschungsbereichen untersucht. Es wurden auf qualitativem Weg typische Probleme und Problemauslöser für Wissensintegrationsbarrieren ermittelt. Weiterhin konnten Hinweise gefunden werden, dass Teamleiter die negativen Auswirkungen fachlicher Teamheterogenität stärker mit unzureichenden Teamergebnissen in Zusammenhang bringen. Teammitglieder erkennen demnach die Problematik fachlicher Unterschiede weniger, was die Notwendigkeit zur Sensibilisierung von Teammitgliedern für Herausforderungen der Wissensintegration aufzeigt. In der Untersuchung konnten konkrete Strategien der Wissensintegration in den Teams untersucht werden. Die kombinierte qualitative und quantitative Analyse zeigte jedoch teilweise erhebliche Diskrepanzen zwischen den von den Teammitgliedern angegebenen und den von ihnen tatsächlich angewendeten Strategien. So wurde zwar die Strategie „Nachfragen“ fast immer von den Befragten angegeben, in der konkreten Teamsitzung aber sehr selten angewendet, auch wenn Unklarheiten oder Missverständnisse bestanden. Aus allen Untersuchungen konnten Handlungsempfehlungen zur Optimierung von Kooperations- und Wissensintegrationsprozessen abgeleitet werden. Diese wurden in Trainingsmodule für Produktentwicklungsteams

114


umgesetzt, in denen Strategien zur Bewältigung typischer Barrieren der Wissensintegration vermittelt werden. Gleichzeitig steht in diesen Modulen die aktive Entwicklung einer gemeinsamen Wissensbasis für das Team im Vordergrund, um die Voraussetzung für innovative Verknüpfungen des heterogenen Expertenwissens zu innovativen Lösungen zu schaffen. So kann auf Teamebene ein wirkungsvoller Beitrag zur nachhaltigen Erreichung der im Rapid Product Development-Ansatz angestrebten Innovations- und Effizienzziele geleistet werden.

Literatur [2.1] Aalst WMP van der (2001) How to handle dynamic change and capture management information: An Approach based on generic Workflow Models? Computer Systems Science and Engineering 15(5):267-276 [2.2] Aalst WMP van der, Basten T (2002) Inheritance of Workflows. An approach to tackling problems related to change. Theoretical Computer Science 270(1-2):125-203 [2.3] Adam D (1997) Planung und Entscheidung: Modelle - Ziele - Methoden. 4., vollst. überarb. und wesentl. erw. Aufl., Nachdr., Gabler, Wiesbaden [2.4] Ahuja MK, Galetta DF, Carley KM (2003) Individual Centralità and Performance in Virtual R&D Groups: An Empirical Study. Management Science 49(1):21-38 [2.5] Algon J (1997) Classifications of tasks, steps, and information-related behaviour of individuals on project teams. In: Vakkari P, Salvolainen R, Dervin B (Hrsg) Information seeking in context. Taylor Graham, London, S 205-221 [2.6] Aoki M (1990) Information, incentives and bargaining in the Japanese economy. Cambridge Univ. Pr., Cambridge [2.7] Ayoko O, Härtel C, Callan V (2002) Resolving the puzzle of productive and destructive conflict in culturally heterogeneous workgroups: A communication accomodation theory approach. The International Journal of Conflict Management, 13(2):165-195 [2.8] Bartlett CA, Ghoshal S (1993) Beyond the M-Form: Toward a Managerial Theory of the Firm. Strategic Management Journal 14:23-46 [2.9] Bea FX, Haas J (2005) Strategisches Management. 4. neu bearb. Aufl., Lucius & Lucius, Stuttgart [2.10] Below von C (2001) Wissen preisgeben: Die Angst der Experten vor dem Machtverlust. In: Antoni C, Sommerlatte T (Hrsg) Report Wissensmanagement - Wie deutsche Firmen ihr Wissen profitabel machen. 3. Aufl., Symposion Publishing, Düsseldorf [2.11] Berens W, Delfmann W (2002) Quantitative Planung. 2. überarb. Aufl., Schäffer-Poeschel, Stuttgart [2.12] Borgatti SP; Cross, R (2003) A Relational View of Information Seeking and Learning in Social Networks. Management Science 49(4):432-445

Literatur

115

[2.13] Bowers C, Pharmer J; Salas E (2000) When member heterogeneity is needed in work-teams. A meta-analysis. Small Group Research 31(3): 305327 [2.14] Brödner P (1996) Erfolgsfaktor Produktentwicklung. Bericht aus einem Industrie-Arbeitskreis. In: Brödner P, Paul H, Hamburg I (Hrsg) Kooperative Konstruktion und Entwicklung. Nutzungsperspektiven von CAD-Systemen. Hampp, München, S 17-39 [2.15] Brödner P (2000) The future of work in a knowledge-based economy. In: ICT/CIREM. International Seminar on Economy and Work in the Knowledge Society. Barcelona, February 24-25 [2.16] Bullinger HJ, Warschat J Wörner K, Wißler K (1996) Rapid Product Development - ein iterativer Lösungsansatz zur Verkürzung der Entwicklungszeiten in dynamischen Umfeldern. VDI-Z 138(5):20-23 [2.17] Bullinger HJ, Wißler K, Wörner K (1996) Rapid Product Development. FB/IE 45(2):67-73 [2.18] Bullinger HJ, Fischer D, Wißler K (1997) Rapid Product Development: Schneller von der Idee zum innovativen Produkt. Industrie Management 13:52-54. [2.19] Bullinger HJ, Warschat J, Dangelmaier M, Leyh J (2002) Vernetzte Planung in den frühen Phasen der Produktentwicklung. Dargestellt am Konzept des »Rapid Product Development« (RPD). In: Wirth S (Hrsg) Vernetzt planen und produzieren. Neue Entwicklungen in der Gestaltung von Forschungs-, Produktions- und Dienstleistungsnetzen. Schäffer-Poeschel, Stuttgart, S 83-124 [2.20] Bunderson J, Sutcliffe K (2002) Comparing alternative conceptualizations of functional diversity in management teams: Process and performance effects. Acadamy of Management Journal 45(5):875-893 [2.21] Burgelman RA (1983) Corporate Entrepreneurship; Strategic Management: Insights from a Process View. Management Science 29(12):1349-1364 [2.22] Burgelman RA (1988) Strategy Making as Social Learning Process: The Case of Internal Corporate Venturing. Interfaces 18(3):74-85 [2.23] Büssing A, Glaser J (1993) Qualifikationserfordernisse und Qualifikationsmöglichkeiten als gesundheits- und persönlichkeitsfördernde Merkmale in der Arbeitstätigkeit. Zeitschrift für Arbeits- u. Organisationspsychologie 37:154-162 [2.24] Cannon-Bowers J, Salas E (2001) Reflections on shared cognition. Journal of Organizational Behaviour 22:195-202. [2.25] Cannon-Bowers J, Salas E, Converse S (1993) Shared mental models in expert teamdecision making. In: Castellan NJ (ed) Individual and group decision making. Lawrence Erlbaum Associates, Hillsdale, S 221-246 [2.26] Chew F (1994) The relationship of information needs to issue relevance and media use. Journalisme Quarterly 71(3):676-688. [2.27] Clark HH (1996) Using Language. Cambridge University Press, Cambridge [2.28] Davenport TH, Prusak L (1998) Working Knowledge. How Organisations Manage What They Know. Harvard Business School Press, Boston

116


[2.29] Dennis AR, Garfield MJ (2003) The Adoption and Use of GSS in Project Teams: Toward More Participative Processes and Outcomes. MIS Quarterly 27(2):289-323 [2.30] Denton H (1997) Multidisciplinarity team-based project work: Planning factors. Design Studies 18:155-170 [2.31] Devine DJ, Clayton, LD, Philips JL, Dunford BB, Melner SB (1999) Teams in organizations. Prevalence, characteristics, and effectiveness. Small Group Research 30(6):678-711 [2.32] Diederich MK, Leyh J (2000) Dynamic Planning Portal for Rapid Product Development. In: Proceedings for the Conference on Rapid Prototyping in the Automotive Industries, 33rd International Symposium on Automotive Technology and Automation (33rd ISATA), 25.-29. September 2000 in Dublin, Ireland [2.33] Dixon NM (2000) Common Knowledge. How Companies Thrive by Sharing What They Know. Harvard Business School Press, Boston [2.34] Dosi G, Nelson RR, Winter SG (2002) The nature and dynamics of organizational capabilities, Oxford University Press, New York [2.35] Drach-Zahavy A, Somech A (2001) Understanding team innovation: The role of team processes and structures. Group Dynamics 5(2):111-123 [2.36] Entin E, Serfaty D (1999) Adaptive team coordination. Human Factors 41(2):312-325 [2.37] Fredrickson JW (1983) Strategic Process Research: Questions; Recommendations. Academy of Management Review 8(4):565-575 [2.38] Frenkel SJ, Korczynski M, Shire KA, Tam M (1999) On the Front Line. Organization of Work in the Information Economy. ILR Press, Ithaca, NY. [2.39] Gebhardt A (1996) Rapid Prototyping. Werkzeuge für die schnelle Produktentwicklung. Carl Hanser Verlag, München, Wien [2.40] Gibbons M (2005) The New Production of Knowledge. The Dynamics of Science and Research in Contemporary Societies. Sage Publ., London [2.41] Gladstein-Ancona D, Caldwell D (1992) Demography and design: Predictors of new product team performance. Organization Science 3(4):321-341 [2.42] Goesmann T, Herrmann T (2000) Wissensmanagement und Geschäftsprozessunterstützung – am Beispiel des Workflow Memory Information System WoMIS. In: Herrmann T (Hrsg) Verbesserung von Geschäftsprozessen mit flexiblen Workflow-Management-Systemen (Bd. 4) Physika, Heidelberg: Physica, S 83-101 [2.43] Griffith TL, Sawyer JE, Meale MA (2003) Virtualness and Knowledge in Teams: Managing the Love Triangle of Organizations, Individuals, and Information Technology. MIS Quarterly 27(2):265-287 [2.44] Hall R, Andriani P (1998) Analysing intangible resources and managing knowledge in a supply chain context. European Management Journal 16(6):685-697 [2.45] Hall R, Andriani P (2002) Managing Knowledge for Innovation. Long Range Planning 35(1):29-48

Literatur

117

[2.46] Hambrick D, Cho T, Chen M (1996) The influence of top management team heterogeneity on firms' competitive moves. Administrative Science Quarterly 41(4):659 -684 [2.47] Harrison D, Price KH, Gavin JH, Florey AT (2002) Time, teams, and task performance: Changing effects of surface- and deep-level diversity on group functioning. Academy of Management Journal 45(5):1029-1045 [2.48] Hauschildt, J (1988) Zielbildung und Problemlösung. In: Witte E, Hauschildt J, Grün O (Hrsg) Innovative Entscheidungsprozesse. Die Ergebnisse des Projektes 'Columbus'. Mohr, Tübingen, S 56-78 [2.49] Hermann S (2002) Wissensarbeit erkennen und unterstützen. In: Wissensintegration und –koordination, Schlüsselkompetenzen wissensintensiver Dienstleistungsunternehmen. IRB-Verlag, Stuttgart, S 3746 [2.50] Herbig B, Büssing A (2003) Implizites Wissen und erfahrungsgeleitetes Arbeitshandeln: Perspektiven für Arbeit und Organisation. Arbeit 12(1):3653. [2.51] Hermann S, Schnalzer K (2003) Wissensintensive Arbeit – Analyse und Gestaltung. Wirtschaftspsychologie 5(1):17-20 [2.52] Herrmann T, Kienle A, Reiband N (2003) Metawissen als Voraussetzung für den Wissensaustausch und die Kooperation beim Wissensmanagement. Zeitschrift für Medienpsychologie 15(1):3-12 [2.53] Herstatt, C (1999) Theorie und Praxis der frühen Phasen des Innovationsprozesses. Aufgaben, Gestaltungsansätze und praktische Bestandsaufnahme. IO-Management 68(10):80-91 [2.54] Iwanowa A, Hacker W (1984) Das Tätigkeitsbewertungssystem - Ein Hilfsmittel beim Erfassen potentiell gesundheits- und entwicklungsfördernder objektiver Tätigkeitsmerkmale. Psychologie und Praxis - Zeitschrift für Arbeits- und Organisationspsychologie 28(2):57-66 [2.55] Jantsch E (1975) Design for Evolution: Self-Organization and Planning in the Life of Human Systems. G. Braziller, New York [2.56] Jehn K (1995) A multimethod examination of the benefits and detriments of intragroup conflict. Administrative Science Quarterly 40(2):256-282 [2.57] Jehn KA (1997) A qualitative analysis of conflict types and dimensions in organizational groups. Administrative Science Quarterly 42(3):530-557 [2.58] Keller R (2001) Cross-functional project groups in research and new product development: Diversity, communications, job stress, and outcomes. Academy of Management Journal 44(3):547-555 [2.59] Khurana A, Rosenthal SR (1998) Towards Holistic ''Front Ends'' In New Product Development. The Journal of Product Innovation Management 15(1):57-74 [2.60] Kienle A, Menold N, Herrmann T (2003) Technische und organisatorische Gestaltungsoptionen für unternehmensinterne Wissensmanagementprojekte. In: Herrmann T, Mambrey P, Shire K (Hrsg) Wissensgenese, Wissensteilung und Wissensorganisation in der Arbeitspraxis. Westdeutscher Verlag, Opladen, S 109-153

118


[2.61] Kirsch W (1998) Die Handhabung von Entscheidungsproblemen: Einführung in die Theorie der Entscheidungsprozesse. 5., überarb. Aufl., Kirsch, Herrsching [2.62] Kleiner A, Roth G (1997) How to Make Experience Your Company's Best Teacher. Harvard Business Review 75(5):172-177 [2.63] Klimecki R, Probst G, Eberl P (1994) Entwicklungsorientiertes Management. Schäffer-Poeschel, Stuttgart [2.64] Knight D, Pearce CL, Smith KG, Olian JD, Sims HP, Smith KA, Flood P (1999) Top management team diversity, group process, and strategic consensus. Strategic Management Journal 20(5):445-465. [2.65] Knorr-Cetina K (1984) Die Fabrikation von Erkenntnis. Zur Anthropologie der Naturwissenschaft. Suhrkamp, Frankfurt/Main [2.66] Knyphausen D zu (1988) Unternehmungen als evolutionsfähige Systeme. Überlegungen zu einem evolutionären Konzept für die Organisationstheorie. Kirsch, Herrsching [2.67] Koch H (1982) Integrierte Unternehmensplanung. Gabler, Wiesbaden [2.68] Kremer D, Bienzeisler, B (2004) Improving the Efficiency and Innovation Capability of Collaborative Engineering: The Knowledge Integration Training for Teams (KITT). In: Horváth I; Xirouchakis P (Hrsg) Proceedings of the TMCE 2004, Fifth International Symposium on Tools and Methods for Competitive Engineering, 12.-16. April in Lausanne, Switzerland. Millpress, Rotterdam [2.69] Kurtz T (2003) Professionen und Wissensberufe. Sind Professionen Wissensberufe, sind alle Wissensberufe Professionen? Arbeit 12(1):5-15 [2.70] Lang K (1997) Gestaltung von Geschäftsprozessen mit Referenzbausteinen. Deutscher Universitätsverlag, Wiesbaden. Erlangen-Nürnberg, Univ., Diss., 1996 [2.71] Leyh J, Fischer D (1999) Team Oriented Project Planning for Global Engineering - A Teamoriented Project Planning System with Capacity Planning, Product Knowledge; Process Knowledge. In: Proceedings for the 32nd International Symposium on Automotive Technology; Automation. 14.-18. Juni 1999 in Wien [2.72] Leyh J, Diederich MK (2000) Evolutionary Planning Methodology for the Early Phases of Product Development. In: Proceedings for the Conference on Rapid Prototyping in the Automotive Industries, 33rd International Symposium on Automotive Technology and Automation (33rd ISATA). 25.-29. September 2000 in Dublin. [2.73] Leyh J, Diederich, MK (2001) Distributed Planning in the Rapid Product Development using adaptable process modules. In: Proceedings for the Conference on Product Development, 1st Automotive and Transportation Technology Congress and Exhibition (1st ATTCE). 1.-3. Oktober 2001 in Barcelona [2.74] Lindblom, CE (1959) The Science of Muddling Through. Public Administrative Review 19(2):79-88 [2.75] Luczak H, Eversheim W (Hrsg.) (1999) Telekooperation. Industrielle Anwendungen in der Produktentwicklung. Springer-Verlag, Berlin, 1999

Literatur

119

[2.76] Luczak H, Schmidt L, Springer J (2003) Gestaltung von Arbeitssystemen nach ergonomischen und gesundheitsförderlichen Prinzipien. In: Bullinger HJ, Warnecke HJ, Westkämper E (Hrsg) Neue Organisationsformen im Unternehmen - ein Handbuch für das moderne Management. Springer-Verlag, Berlin, S 421-458 [2.77] Lutz S, Clieminski GV, Wiendahl HP (2002) Produzieren in Netzwerken – Eine Frage des Vertrauens. phi – Produktionstechnik Hannover informiert 3(4), S 4-5 [2.78] Malik F (2006) Strategie des Managements komplexer Systeme: ein Beitrag zur Management-Kybernetik evolutionärer Systeme. 9., unveränd. Aufl., Haupt, Bern, Stuttgart, Wien [2.79] Mambrey P, Pankoke-Babatz U, Budweg S, Poschen M, Törpel B (2003) Vernetzte Handlungsräume: Zur Ausgestaltung technisch unterstützter, verteilter Wissensarbeit. In: Herrmann T, Mambrey P, Shire K (Hrsg) Wissensgenese, Wissensteilung und Wissensorganisation in der Arbeitspraxis. Westdeutscher Verlag, Opladen, S 155-197 [2.80] Mathieu JE, Goodwin GF, Heffner TS, Salas E, Cannon-Bowers JA (2000) The influence of shared mental models on team process and performance. Journal of Applied Psychology 85(2):273-393 [2.81] McDonough III E (2000) An investigation of factors contributing to the success of cross-functional teams. Journal of Product Innovation Management 17(3):221-235 [2.82] Mintzberg H (1973) Strategy-Making in Three Modes. California Management Review 16(2):44-53 [2.83] Mintzberg H (1994) The Rise; Fall of Strategic Planning. Reconceiving Roles for Planning, Plans, Planners. Prentice Hall, New York [2.84] Nadler J, Thompson L, Boven L Van (2003) Learning Negotiation Skills: Four models of Knowledge Creation and Transfer. Management Science 49(4):529-540 [2.85] Nelson RR, Winter SG (19829 An Evolutionary Theory of Economic Change. The Belknap Press of Harvard Univ. Press, Cambridge, Mass. [2.86] Nihtilä J (1999) R&D-Production integration in the early phases of new product development projects. Journal of Engineering and Technology Management 16(1):55-81 [2.87] Nohria N, Berkley JD (1994) The Virtual Organization: Bureaucracy, Technology, and the Implosion of Control. California Management Review 36(4):70-92 [2.88] Nonaka I, Takeuchi H (1995) The Knowledge Creating Company. How Japanese Companies Create the Dynamics of Innovation. University Press, Oxford [2.89] Novak JD (1998) Learning, Creating and Using Knowledge. Concept Maps as Facilitative Tools in Schools and Cooperations. Lawrence Erlbaum, Mahwah; New Jersey [2.90] Pascale RT (1990) Managing on the edge: how successful companies use conflict to stay ahead. Viking, London

120


[2.91] Pelled L, Eisenhardt K, Xin K (1999) Exploring the black box: An analysis of work group diversity, conflict and performance. Administrative Science Quarterly 44(1):1-28 [2.92] Penrose ET (1996) The Theory of the Growth of the Firm. 3. ed., rev. ed., repr. Oxford University Press, Oxford [2.93] Picot A, Reichwald R, Wigand R (2003) Die grenzenlose Unternehmung. Information, Organisation und Management, Lehrbuch zur Unternehmensführung im Informationszeitalter. 5.akt. Aufl., Gabler, Wiesbaden [2.94] Pinto M (1989) Predictors of cross-functional cooperation in the implementation of marketing decisions. AMA Educator's Proceedings, 55:154-158 [2.95] Polanyi M (1985) Implizites Wissen. Suhrkamp, Frankfurt/Main [2.96] Porter ME (2004) Competitive strategy: techniques for analyzing industries and competitors. 1. Free Press export ed, Free Press, New York, NY [2.97] Porter ME (2004), Competitive advantage: creating and sustaining superior performance. 1. Free Press ex. Ed, Free Press, New York, NY [2.98] Prahalad CK, Hamel G (1990) The core competence of the corporation. Harvard Business Review 68(5-6):79-91 [2.99] Probst G, Raub S, Romhardt K (1998) Wissen managen. Wie Unternehmen ihre wertvollste Ressource optimal nutzen. 2. Aufl., Gabler, Wiesbaden [2.100] Quinn J, Anderson P, Finkelstein S (1996) Das Potential in den Köpfen gewinnbringender nutzen. Harvard Businessmanager 18(3):95-104 [2.101] Reihlen M (1997) Entwicklungsfähige Planungssysteme: Grundlagen, Konzepte und Anwendungen zur Bewältigung von Innovationsproblemen. Deutscher Universitätsverlag, Wiesbaden. Dissertation, Universität zu Köln 1996 [2.102] Roggatz A (1998) Entscheidungsunterstützung für die frühen Phasen der integrierten Produkt- und Prozessgestaltung. Shaker Verlag, Aachen. Dissertation, RWTH Aachen 1997 [2.103] Roth H (1971) Pädagogische Anthropologie, Schroedel, Hannover 1971 [2.104] Sarin S, Mahajn V (2001) The effect of reward structures on the performance of cross-functional product development teams. Journal of Marketing, 65(2):35-53 [2.105] Schreyögg G, Geiger D (2002) Knowledge, Narrations and Könnerschaft. Putting Knowledge into Perspective. In: Diskussionsbeiträge des Instituts für Management der Freien Universität Berlin, Nr. 18. Berlin: FU, Fachbereich Wirtschaftswiss. [2.106] Schumacher O (2002) Teamorientiertes Kommunikationssystem für Rapid Product Development. Bericht IPA-IAO Forschung und Praxis, Nr. 360. JostJetter, Heimsheim. Dissertation, Universität Stuttgart 2002 [2.107] Schwaninger M; Körner M (2003) Systemisches Projektmanagement. zfo 72(2):75-85 [2.108] Schäfer-Pietig R (1995) Suboptimale Gruppenentscheidungen: Untersuchung zur Informationsnutzung und Entscheidungshilfe. Unveröffentlichte Doktorarbeit. Friedrich-Alexander-Universität Erlangen-Nürnberg, 1995

Literatur

121

[2.109] Sethi R, Smith DC, Park, CW (2001) Cross-functional product development teams, creativity, and the innovativeness of new consumer products. Journal of Marketing Research 38(1):73-85 [2.110] Simon, H.A (1977) The New Science of Management Decision. 3rd rev. ed., Prentice-Hall, Englewood Cliffs [2.111] Simons T, Pelled L, Smith K (1999) Making use of diversity: Diversity, debate, and decision comprehensiveness in top management teams. Academy of Management Journal 42(6):662-673 [2.112] Spieß E (1998) Formen der Kooperation – Bedingungen und Perspektiven. Göttingen: Hogrefe [2.113] Stacey RD (1992) Managing the Unknowable: Strategic Boundaries between Order and Chaos in Organizations. Jossey-Bass, San Francisco [2.114] Steinheider B, Ganz W, Nogge W, Warschat J (1999) A model to support expert co-operation. In: Roller R (Hrsg) Automotive mechatronics design and engineering, ISATA Croydon, S 159-162 [2.115] Steinheider B (2001) Supporting the co-operation of R&D-teams in the product development process. In: Proceedings of the 5th conference on engineering design and automation, 5.-8. August 2001 in Las Vegas, Nevada [2.116] Sydow J (1996) Wissensintensiv durch Netzwerkorganisation – Strukturationstheoretische Analyse eines wissensintensiven Netzwerkes. In: Schreyögg G, Conrad P (Hrsg) Managementforschung 6. De Gruyter, Berlin, S 191-234 [2.117] Teachman J (1980) Analysis of population diversity. Sociological Methods and Research 8(3):341-362 [2.118] Thomke S, Fujimoto S (2000) The Effect of "Front-Loading" ProblemSolving on Product Development Performance. The Journal of Product Innovation Management 17(2):128-142 [2.119] Thomas-Hunt MC, Ogden TY, Neale MA (2003) Who's Really Sharing? Effects of Social and Expert Status on Knowledge Exchange Within Groups. Management Science 49(4):464-477 [2.120] Tidd J (2000) From Knowledge Management to Strategic Competence: Measuring Technological, Market and Organizational Innovation. Series on Technology Management 3, London: Imperial Collage Press [2.121] Warschat J, Diederich M, Leyh J (2002) Wissensmanagement in verteilten Prozessen des Rapid Product Development. Künstliche Intelligenz 24(1):2530 [2.122] Wehner T, Raeithel A, Clases C, Endres E (1996) Von der Mühe und den Wegen der Zusammenarbeit. In: Endres E, Wehner T (Hrsg) Zwischenbetriebliche Kooperation – Die Gestaltung von Lieferbeziehungen. Psychologie Verlags Union, Weinheim, S 39-58 [2.123] Wehner T, Clases C, Manser T (1999) Wissensmanagement: State of the Art. Einführung in ein transdisziplinäres Thema und Darstellung der arbeitsund sozialwissenschaftlichen Perspektive: In: Harburger Beiträge zur Psychologie und Soziologie der Arbeit (14), Hamburg: TU HamburgHarburg, S 1-57

122


[2.124] Weingart P (1995) Crossing Boundaries in Science. Nomos-Verl.-Ges., Baden-Baden [2.125] Weingart P (2000) Interdisciplinarity – The paradoxical discourse. In: Weingart P, Stehr N (Hrsg) Practicing Interdisciplinarity. University Press, Toronto, S 25-42 [2.126] Wilson, T (1997) Information behaviour: An interdisciplinary perspective. Information Processing and Management 33(4):551-572 [2.127] Willke H (1998) Organisierte Wissensarbeit. Zeitschrift für Soziologie 27(3):161-177 [2.128] Willke H (2001) Systemisches Wissensmanagement. 2., neubearb. Aufl., Lucius & Lucius, Stuttgart [2.129] Wirth S (2000) Von hierarchischen Unternehmens- zu hierarchielosen (-armen) kompetenzzellenbasierten Produktionsnetzen. In: Wojda F (Hrsg) Innovative Organisationsformen. Schäffer-Poeschel, Stuttgart, S 167-209 [2.130] Wirth S (2002) Kompetenznetze wandeln Produktions- und Fabrikstrukturen. In: Wirth S (Hrsg) Vernetzt planen und produzieren – Neue Entwicklungen in der Gestaltung von Forschungs-, Produktions- und Dienstleistungsnetzen. Schäffer-Poeschel, Stuttgart, S 13-30 [2.131] Wörner K (1999) System zur dezentralen Planung von Entwicklungsprojekten im Rapid Product Development. Springer, Berlin, Heidelberg. Dissertation, Universität Stuttgart, 1998 [2.132] Zahn E, Foschiani S, Tilebein M (1999) Wissen und Strategiekompetenz als Basis für die Wettbewerbsfähigkeit von Unternehmen. Universität Stuttgart, Betriebswirtschaftliches Institut, Arbeitspapier Nr. 4/1999 [2.133] Zeithaml V, Bitner MJ (2000) Services Marketing. McGraw Hill, New York [2.134] Zellmer-Bruhn ME (2003) Interruptive Events and Team Knowledge Acquisition. Management Science 49(4):514-528

3 Vernetztes Wissen für die interaktive Entwicklung von Prototypen

Innovative Entwicklungen sind gekennzeichnet durch ihren engen zeitlichen Rahmen und die hohen technischen Anforderungen an die Herstellverfahren. Gleichzeitig steigt die Komplexität der zu entwickelnden Produkte sowie die Notwendigkeit einer effizienten Nutzung vorhandenen Wissens aus unterschiedlichen Bereichen. Vor dem Hintergrund der wachsenden Informationsflut erweist sich die Möglichkeit der Integration, Aufbereitung und Verdichtung von heterogenen Datenbeständen in der schnellen Produktentwicklung als ein wesentlicher Wettbewerbsfaktor. Die Komplexität, das Design und die notwendigen Fertigungsverfahren werden bereits am Anfang der Produktentstehung durch die Konstruktion weitestgehend festgelegt. Die Kosten eines Produktes werden deshalb nicht nur durch die begleitenden Geschäfts- und Marketingprozesse, sondern maßgeblich durch dessen Entwicklung und Produktion bestimmt. Somit können besonders in den frühen Phasen durch eine enge Verzahnung von Informationen aus den Bereichen Konstruktion, Qualität und Fertigungsplanung unnötige Iterationszyklen vermieden und Produkte einer neuen, höheren Qualität entwickelt werden (Abb. 3.1.) [3.8], [3.38], [3.37]. Eine besonders hohe Vielfalt der Datenverarbeitungsarten und des Wissensmanagements in den Produktentwicklungsphasen trägt oft zu Informationsverlusten bei, die anschließend in Nachfolgeprozessen neu generiert werden müssen. Diese Informationen werden an unterschiedlichen Stellen im Entwicklungsprozess erzeugt und abgerufen. Geometrische Informationen werden beispielsweise in der Konstruktion definiert, wobei diese Informationen teilweise durch das Pflichten- und Lastenheft vorgegeben sind. Die Qualitätsdaten werden durch das Qualitätsmanagement festgelegt und überwacht. Die benötigten Einstell- und Prozessdaten werden von den jeweiligen Anlagenbedienern generiert.

124


Abb. 3.1. Informationsdichten in der Produktentwicklung

Hieraus ergibt sich die Notwendigkeit der Einführung effizienter Integrationsstrategien, die sowohl den iterativen Einsatz physischer Informationsträger (z.B. Designmodelle, Skizzen, Entwurfspläne) und virtueller Informationsträger (z.B. CAD-Modelle, RE-Solid-Modelle, FacettenModelle) umfassen. Zusätzlich ermöglicht dies die für die Entwurfsphase geeigneten Zeit-, Kosten- und Qualitätsanalysen ohne Informationsverlust durchzuführen. Zeit-, Kosten- und Qualitätsaspekte in den frühen Produktentstehungsphasen Rapid Product Development bedient sich Verfahren, die eine kostengünstige und frühzeitige Evaluation des gegenwärtigen Entwicklungsstandes

3.1 Vernetztes Entwicklungswissen durchgehend nutzen

125

erlauben. Dadurch ist es möglich, zu einem frühen Zeitpunkt Fehlentwicklungen zu erkennen und entsprechend gegenzusteuern. Ebenfalls wird die Weiterverfolgung mehrer Konstruktionsvarianten ermöglicht, da ein echter, funktionaler Prototyp mit realen Werkstoffen und Fertigungsverfahren erst sehr spät gefertigt werden muss. Bis dahin bleibt der vollständige Lösungsraum erhalten, was eine optimale Realisierung der Zielvorgaben und eine qualitätsgerechte Überwachung der Produktentwicklung erlaubt [3.27]. Die Grundlage aller Betrachtungen sind optimale Konstruktionsprozesse basierend auf der Anwendung von RP-Technologien. Die RP-Prozesse werden heute jedoch lediglich zusätzlich eingesetzt, eingebettet in traditionelle, starre, sequentielle Entwicklungsprozesse. Ihr Potential wird nicht vollständig genutzt. Es ist folglich nicht mit einer Einsparung von Entwicklungskosten zu rechnen, wenn RP-Technologien als eine Art zusätzliches Werkzeug betrachtet und verwendet werden, sondern nur dann, wenn auch das Potenzial solcher Technologien in einer angepassten Entwicklungsphilosophie zum richtigen Zeitpunkt eingesetzt und mit anschließender Analyse und Bewertung der Ergebnisse verwertet wird. Es ist der Entwicklungsprozess, der insgesamt dem RP-Gedanken verschrieben sein muss, um Vorteile hinsichtlich der Entwicklungszeit, der Entwicklungskosten und der Qualität des Produktes als Ganzem zu erzielen (Abb. 3.2.).

Abb. 3.2. Mehrdimensionales Steuerungsinstrument als Regulativ im Entwicklungsprozess

Es stehen somit die Interaktionen zwischen den einzelnen Prozessen, Methoden und Technologien im Vordergrund, um das Entwicklungswissen zwischen den Bereichen Konstruktion, Qualität, Planung und Controlling

126


effizient zu vernetzen sowie die fehlenden Bausteine in der Entwicklungskette mit modernen Methoden des Rapid Product Development und des Kosten- und Wissensmanagements zu ergänzen. Entwicklungszeit reduzieren Ein bedeutender Faktor im Wettbewerb mit konkurrierenden Unternehmen stellt die Entwicklungszeit dar. Ungünstige Entscheidungen in der Konzeption und Vorauslegung eines Produktes können in den klassischerweise darauf folgenden Entwicklungsschritten nur zeit- und kostenintensiv korrigiert werden. Häufig erfordern sie aufwendige Anpassungen an den Konstruktionen, nicht zuletzt deshalb, weil die Auswirkungen der konstruktiven Maßnahmen allzu oft nicht im Zusammenhang mit anderen Bauteilen eines Produktes betrachtet werden. Gerade bei der Produktentwicklung in mehreren Teams werden Fehlentwicklungen erst spät aufgedeckt und erfordern die zeitintensive Koordination und Durchführung entsprechender Korrekturmaßnahmen [3.28]. Produktqualität erfassen und fördern Durch einen unzureichenden Informationsaustausch wird besonders die Qualität eines Produktes bereits frühzeitig maßgeblich beeinflusst. Die Qualität eines Produktes misst sich direkt an den Erwartungen des Kunden. Hierbei spielen nicht nur die in Form von Anforderungslisten oder Lastenheft definierten Qualitätsmerkmale eine gewichtige Rolle, sondern gerade auch die subjektiven Erwartungen der Kundschaft. Diese möglichst vollständig zu erfassen, ist Aufgabe der Marktstrategen und auch des Kundendienstes, der wertvolle Anregungen oder Kritik in die Entwicklung mit einfließen lassen kann. Hierbei ist die Zuverlässigkeit des Produktes von zentraler Bedeutung. Entscheidend für den Gesamteindruck sind aber auch Verarbeitungsqualität, Robustheit von Bedienelementen und selbstverständlich deren Funktion. Viele dieser Qualitätsmerkmale werden vom Kunden als selbstverständlich vorausgesetzt, müssen jedoch in der Produktentwicklung gesondert berücksichtigt werden. Die Gewichtung einzelner Qualitäts- und Zuverlässigkeitsmerkmale kann sich dabei schnell erheblich verschieben. So wird dem Käufer eines Pkw eine grandiose Laufleistung seines Getriebes schnell nebensächlich erscheinen, wenn sein Blinkerhebel alle 1.000 km abbricht, oder der Armaturenträger ab einer bestimmten Geschwindigkeit lautstark zu vibrieren beginnt. Indes spielt eine hochwertige Verarbeitung keine Rolle, wenn der Pkw aufgrund mangelnder Zuverlässigkeit nicht mehr funktioniert.


127

Entscheidend ist also neben der Einhaltung von Qualitätsmerkmalen in Fertigung und Montage vor allem die Gesamtzuverlässigkeit des Systems, die überwiegend konzeptionell und konstruktiv bedingt ist. Kostenentwicklung steuern Die Herstellkosten eines Produktes werden zum größten Teil durch konstruktive Merkmale bedingt. Die Optimierungen von Fertigungsplanung und Arbeitsvorbereitung durch die Wahl von z. B. geeigneten und wirtschaftlichen Fertigungsverfahren, effizienten Arbeitsabläufen, optimalen Maschinenauslastungen, etc. können die Gesamtkosten nur noch geringfügig beeinflussen. Kostensenkung ist eine Gemeinschaftsaufgabe, zu der sich neben der Fertigung auch die Entwicklung verpflichten muss. Abteilungsegoismus und Informationsverweigerung treiben die Kosten unnötig in die Höhe. Eine Beherzigung dieser Aufgabe bringt nach Erfahrungen von [3.21] eine Senkung der Herstellkosten von 10 bis 30%. Die Einführung neuer Methoden und Konzepte zur Berücksichtigung von Kosten trägt jedoch deutlich mehr zu der Kostensenkung bei. Dem Entwickler muss verdeutlicht werden, dass jede technische Festlegung und jede Entscheidung auch die Kostenentwicklung bestimmt. Die Kosten müssen folglich simultan zur Entwicklung kontrolliert und berücksichtigt werden [3.20]. Das bedeutet auch, dass zum Entscheidungszeitpunkt die relevanten Kosten vorliegen und verglichen werden. Optimal wäre folglich eine permanent simultan erfolgende Bewertung der Entwicklung nach den Gesichtspunkten der Konstruktion, des Controllings, der Fertigung und inzwischen auch in vielen Bereichen des Designs. Ebenso darf eine Einschätzung der Bereiche Beschaffung und Vertrieb, sowie nicht zuletzt auch der Geschäftsführung nicht fehlen. Diesem Ziel möglichst nahe zu kommen, sollte Vorgabe eines jeden Unternehmens sein, setzt jedoch auch einigen Mut zur Einführung neuer Methoden und Konzepte voraus. Die in der Kostenanalyse existierenden Zusammenhänge sind nicht neu, lediglich die Umsetzung lässt meist sehr zu wünschen übrig. Ursache sind häufig die verwendeten Werkzeuge, die einen geschlossenen Informationsfluss nicht zulassen – sowohl was die Kommunikation, als auch was die Informationsverfügbarkeit angeht.

3.1 Vernetztes Entwicklungswissen durchgehend nutzen Aus dem Einsatz des Rapid Prototyping entstehen grundlegende Fragestellungen rund um die Produktgestaltung. So werden sowohl die funktions-

128


orientierte Konzeption des Produktes wie auch seine ästhetische Gestalt bereits zu einem sehr frühen Zeitpunkt der Produktentwicklung grundlegend bestimmt. Damit verbunden ist eine überproportional hohe Kostenverantwortung und Entscheidungsfreiheit. Um daraus resultierende Erkenntnisse zu nutzen, fehlen besonders Lösungen für eine verteilte Produktentwicklung in derzeitigen 3D-CAD-Systemen. Das Produktwissen ist nur oberflächlich integriert, Daten können gut „verwaltet“ aber nur in begrenztem Umfang von mehreren Konstrukteuren koordiniert, zeitgleich bearbeitet und mit anderen Systemen effektiv ausgetauscht werden. Der Einsatz sehr unterschiedlicher Werkzeuge, die einerseits ein intuitives Arbeiten mit vielen Informationen am noch nicht detaillierten Produkt ermöglichen, andererseits aber auch bereits diverses Produkt- und Prozesswissen analysieren, ist Stand der Technik – für deren informationstechnische Einbindung in die CAx-Welt gibt es bisher jedoch keine durchgängigen Lösungen. Besonders die intuitiven Informationen aus der Prototypenherstellung konnten trotz steigender Prototypennutzung bis heute nicht systematisch in die Abläufe integriert werden. Ein realer Produktentstehungsprozess und Prototypenphasen sind in Abb. 3.3 anhand einer Mittelkonsolenentwicklung dargestellt. Derzeitige Entwicklungsabläufe wurden in den letzten Jahren durch die Einführung von Rapid Prototyping Technologien zwar optimiert, das gewonnene Wissen wird aber nur partiell und nicht systematisch in die Produktentstehung eingebunden. Die Entwicklungsprozesse können aber durch das Einbinden von „intelligenten“ Prototypendaten basierend auf der Verarbeitung unvollständiger und unscharfer Produktdaten sowie „lernenden“ Qualitätstools stark beschleunigt werden. Die Bereitstellung solcher wissensbasierter Werkzeuge auf Basis der definierten Informationsschnittstellen war somit die Hauptmotivation in diesem Forschungsvorhaben [3.36], [3.37]. Die anschließenden Kapitel zeigen die interessantesten Ergebnisse und Forschungsansätze, die dazu beitragen, den Informationsfluss durchgängig zu gestalten, sowie die fehlenden Komponenten und Methoden in den frühen Produktentwicklungsphasen bereitzustellen und dem Entwickler ein mehrdimensionales Steuerungsinstrument als Regulativ im Entwicklungsprozess zur Verfügung zu stellen.


129

Abb. 3.3. Prozesse in der Produktentwicklung

In Kapitel 3.2 wird ausgeführt, welche Mängel aus Sicht des Entwicklers in der derzeitigen Produktentwicklung bestehen und wie man mithilfe eines semantischen Netzes die vielfältigen Anforderungen an die Produktentwicklung bewältigen kann. Gerade in den frühen Phasen der Produktentwicklung sollen ausgehend von den Ergebnissen der Produktplanung bereits die Aspekte Kosten und Zuverlässigkeit neben den technischen Aspekten berücksichtigt werden. Besonders beleuchtet werden die Aspekte: x x x x x x

Informationsverfügbarkeit Informationsvernetzung Berechnungen mit unscharfen Vorgaben Erhaltung des Lösungsraumes Zuverlässigkeitsanalysen in frühen Phasen Berücksichtigung von Herstellkosten

Abschließend wird anhand eines Beispieles die Funktionsweise eines entsprechenden Softwareprototypen erläutert. Die zentrale Motivation im Kapitel 3.3 besteht in der Entwicklung einer Konfigurationssystematik mit geeigneten Parametern und Regeln sowie einer Methodik zur Qualitätsanalyse virtueller und physischer Modelle. Darüber hinaus wurde der Einfluss verschiedener Qualitätsmethoden in der Produktentwicklung im Bezug auf die Prototypenherstellung untersucht, um die notwendige Integration und Nutzung des vorhandenen Wissens in dynamischen, unternehmensspezifischen Strukturen zu steuern. Diesbezüglich wurden Modelle für ein Qualitätsmanagement in der Erstellung physischer Prototypen entwickelt. Dabei wurden die folgenden Schwerpunktthemen berücksichtigt:

130


x Bestimmung von Qualitätsmerkmalen beim Aufbau physischer und virtueller Prototypen und Prognose der zu erwartenden Qualität x Kontextsensitive Methodenauswahl und Komplexität im Rapid Prototyping x Simulation von Prototypenherstellprozessen x Referenzmodell des Qualitätsmanagements in dynamischen Strukturen für ein umfassendes Qualitätsmanagementkonzept In Kapitel 3.4 werden Werkzeuge und Methoden zur effizienteren Steuerung der Kostenentwicklung vorgestellt, die speziell den Bedürfnissen des Rapid Prototyping Developments angepasst sind. Anhand von Beispielen werden Vorgehensweisen, sowie die Hintergründe zur Entwicklung dieser Tools demonstriert und die Einsatzgrenzen definiert.

3.2 Aktives Semantisches Konstruktions- und Zuverlässigkeitsnetz In der Produktentwicklung wird für verschiedene Aufgaben die unterschiedlichste Software eingesetzt. Für Vorauslegung und Berechnung, für Simulation und Visualisierung, für Messung und Steuerung und nicht zuletzt für Dokumentation, Versionsverwaltung und Projektmanagement existiert eine breite Palette an Programmen, die sich untereinander versuchen, den Rang abzulaufen und in straffem Konkurrenzkampf untereinander um Marktanteile streben. Wie die Vergangenheit gezeigt hat, ist es allein vor diesem Hintergrund äußerst schwierig und vor allem langwierig, Standards zu entwickeln, die mehr beinhalten, als nur den kleinsten gemeinsamen Nenner aller möglichen Funktionen und Daten. Zumeist kann davon ausgegangen werden, dass ein Tool zum Lösen oder Bearbeiten einer begrenzten speziellen Aufgabe leistungsfähiger ist, als ein Programm, dessen Aufgabe eine ganz andere ist, das aber mit einer Reihe von Erweiterungen und Add-ons ansatzweise in Spezialgebiete vordringt. Andererseits mangelt es Spezialtools häufig an Bedienkomfort und an Import- sowie Exportmöglichkeiten. Im Übrigen werben die Softwarehersteller, die Zeichen der Zeit erkennend, allzu eifrig mit eben diesen Datenaustauschmöglichkeiten. Hier sitzen jedoch immer wieder viele Käufer vorschnell verallgemeinernden Marketingphrasen auf. Kompatibilität oder Unterstützung von bestimmten Fremdprodukten oder Datenstandards be-

3.2 Aktives Semantisches Konstruktions- und Zuverlässigkeitsnetz

131

deutet eben noch lange nicht, dass dringend benötigte Daten oder Funktionen damit auch abgedeckt sind. Es bedeutet lediglich, dass einige Grundfunktionen und Daten verwertet werden – letztendlich kann das Programm mit den entsprechenden Daten „irgendetwas anfangen“ – was genau dieses „irgendetwas“ umfasst, gilt es im Einzelnen sehr genau zu hinterfragen. Der Einsatz solch unterschiedlicher Software birgt neben ihren Vorzügen vor allem einen gravierenden Nachteil. Entwickler arbeiten nicht nur mit einem dieser Tools, sondern gleich mit einer ganzen Reihe davon. Da aber ein automatisierter Datenexport und -import nur begrenzt möglich ist, werden Daten häufig mehrfach in unterschiedlichen Systemen eingegeben und müssen auch konsistent gehalten werden. Mit jedem dieser Schritte gehen somit zwangsläufig mit der Zeit Informationen verloren, die dann zeitaufwendig wieder rekonstruiert oder beschafft werden müssen. Soll ein solcher Zyklus auch noch iterativ zu Verbesserungen führen, so kostet es enorme Anstrengungen, die Datensätze und Versionen zu verwalten. Ein klassisches Beispiel findet sich in den CAx-Bereichen und Berechnungstools. Mehrfache Iterationen beispielsweise zwischen Geometrieanpassung und Festigkeits- oder Strömungssimulationen, häufig noch mit Gewichtsoder Formoptimierungstools erfordern ein hohes Maß an Konvertierungsvorgängen, die meist nur uni-direktional funktionieren. Ist man sich dessen nicht bewusst, so können während der Iterationsschleifen wichtige Bauteilinformationen verloren gehen. Namhafte Hersteller von CAD-Software versuchen mittlerweile, diese Lücken zu schließen und bieten integrierte Berechnungstools an. Diese reichen allerdings bestenfalls für überschlägige Alltagsberechnungen aus, genügen jedoch bei weitem nicht gehobenen Ansprüchen. Da diese Tatsache den Herstellern nicht verborgen blieb, bilden sich derzeit verstärkt Kooperationen zwischen CAD- und FEM-/CFDSoftwareherstellern. Wann und ob jedoch umfassende bi-direktionale Datenkonvertierungen realisiert werden, bleibt abzuwarten. Ein weiteres Problem stellt die mangelnde Produkttransparenz dar. Änderungen an einem Bauteil eines Systems wirken sich i. d. R. auch auf andere Bauteile aus und erfordern weitere Korrekturen. Nicht immer sind diese Auswirkungen aber einfach und klar ersichtlich, was schnell zu einer ganzen Reihe von Problemen führt, die erst auf Prüfständen, schlimmstenfalls gar erst in der Vorserie zutage treten. Korrekturen zu diesem Zeitpunkt sind unnötig kostspielig und verlängern die Entwicklungszeit. Ähnlich verhält es sich mit der Kostenentwicklung und der Produktzuverlässigkeit. Diese werden i. d. R. viel später analysiert, als dies möglich wäre. Aus dem Ruder gelaufene Kosten und Probleme mit der Produktzu-

132


verlässigkeit lassen sich an vielen Beispielen jüngst vergangener Entwicklungen aufzeigen und bringen kleine wie auch große Unternehmen gleichermaßen gehörig ins Schwitzen. Denn nicht nur das Produkt selbst leidet unter einer geringen Zuverlässigkeit, sondern es befleckt schnell das Firmenimage, den guten Ruf in der Öffentlichkeit und vergrault damit letzendlich Kundschaft.

Abb. 3.4. Kosten beeinflussende Mechanismen in der Produktentwicklung nach Ehrlenspiel [3.21]

Es gilt die auch hier die Grundregel, dass nur dann kosteneffizient entwickelt werden kann, wenn zur richtigen Zeit auf die notwendigen Informationen zugegriffen werden kann. Ehrlenspiel zeigt in [3.21] grundsätzliche Mechanismen zur Kostensteigerung und -senkung auf und führt neben der Informationsverfügbarkeit auch Organisation und Kommunikation so-


133

wie Kompetenz und Erfahrung als Voraussetzung für kostengünstige Produktentwicklung an (Abb. 3.4.). Das Institut für Maschinenelemente (IMA) der Universität Stuttgart entwickelt seit einigen Jahren ein Konstruktionssystem, das viele der genannten Probleme beseitigt und den Konstrukteur während der gesamten Produktenwicklung unterstützt. Ausdrücklich auch und gerade in den frühen Phasen der Produktenwicklung, selbst zu einem Zeitpunkt, zu welchem viele Vorgaben noch unscharf oder unbekannt sind. Das Aktive Semantische Konstruktions- und Zuverlässigkeitsnetz (ASK/ASZ) bietet die Möglichkeit, ein Produkt mit all seinen Baugruppen bis hinunter zur Bauteilebene hierarchisch und umfassend abzubilden und seine Daten intelligent miteinander zu verknüpfen. Dies bietet eine ganze Reihe von Vorteilen, u.a: x Informationen werden schnell gefunden, nicht mehr aufwendig in verschiedenen Quellen gesucht. x Vollständige Vernetzung der Produktinformationen. Darstellung aller Abhängigkeiten durch Modellierung eines vollständigen Produktabbildes. x Ein gemeinsames Berechnungsmodell für alle Entwicklungsphasen. Auslegung auch mit unscharfen Informationen und Intervallen unter Ausnutzung des vollen Lösungsraumes. Die Auswirkungen von Parametervariationen auf das gesamte Produkt sind sofort ersichtlich. x Bi-direktionaler Datenaustausch mit modernen 3D-CAD Systemen. Einfache Bearbeitung und Detaillierung der Produktkomponenten. Nutzung vorhandener Schnittstellen zu FEM-, NC-, RP- oder PDMSoftware möglich. x Berechnung der Systemzuverlässigkeit. Beschleunigte Produktentwicklung und Qualitätsverbesserung durch frühzeitige Betrachtung der Systemzuverlässigkeit. Qualitative und quantitative Zuverlässigkeitsbetrachtung mit Importanzanalyse. x Kostenabschätzung bereits während der Konzeptionierung. Kostenintensive Entwicklungen können frühzeitig erkannt und korrigiert, bzw. kompensiert werden. Die Bezeichnung „aktiv“ steht in diesem Begriff für die Interaktion mit dem Konstruktionsnetz, denn dieses führt nach vorgegebenen Regelwerken aufgrund von bestimmten Eingaben des Entwicklers im gesamten Netz kontrolliert Änderungen durch. Diese „Propagation“ von Änderungen ist also ein aktiver Vorgang, den das Konstruktionssystem selbständig durch-

134


führt. Dabei evtl. auftretende Kollisionen werden durch Benutzerinteraktion abgefangen. „Semantisch“ steht für die intelligente Verknüpfung von voneinander abhängigen Eigenschaften der Knoten in diesem Netz, die wiederrum durch unterschiedlich geprägte Kanten in Beziehung miteinander stehen. Unterschiedliche Knotenarten repräsentieren in diesem Konstruktionsnetz die verschiedenen Objekte, die im Zusammenhang mit der Produktentwicklung stehe können. Unterschieden wird u.a. zwischen Konstruktionsobjekten, Anforderungsobjekten, Funktionsobjekten, Organisationsobjekten, oder Dokumentationsobjekten.

Abb. 3.5. Aktives Semantisches Konstruktionsnetz (ASK) am Beispiel einer elektro-mechanischen PKW-Sitzlehnenverstellung


135

Als Formen der Beziehung werden mittels unterschiedlicher Kanten zwischen den Knoten etwa dargestellt: Propagation, Forderungen, Anordnungen, Strukturen, Funktionen oder Organisation. Auf die wichtigsten Funktionen und Stärken des ASK/ASZ wird in den folgenden Unterkapiteln eingegangen. 3.2.1 Semantische Vernetzung In der heutigen Produktentwicklung besteht ein Problem darin, dass eine Unmenge an Informationen weit verstreut aus einer Vielzahl von Quellen beschafft und in einer ebenso großen Zahl an Anwendungen wieder benötigt und abgerufen werden. Die meisten Informationen stehen überdies noch in Abhängigkeiten zueinander, die es zu berücksichtigen gilt. Im Laufe der Produktentwicklung müssen solche Informationen jedoch nicht nur einmal eingeholt, sondern vielmehr permanent aktualisiert werden – und das konsistent überall dort, wo sie verwendet werden. Genau hier drängt sich die Rechnerunterstützung geradezu auf. Mit dem am IMA entwickelten Softwareprototypen ASK/ASZ ist man in der Lage, sämtliche Informationen zu einem Produkt abzulegen und intelligent miteinander zu verknüpfen [3.47], [3.53]. Ausgehend von einer Anforderungsliste, einem Lastenheft oder ähnlichen Vorgaben werden Funktionsprinzipien erstellt, diese bewertet und durch Baugruppen bis hin zu den einzelnen Bauteilen vom Abstrakten zum Konkreten hin entwickelt. Dies erfolgt unter permanenter Berücksichtigung von Kosten, Qualität und Zuverlässigkeit von Beginn an. Es wird also ein Netz an Informationen und Verknüpfungen geschaffen, das in der Lage ist, von Beginn an den Konstrukteur zu unterstützen. Durch die vollständige Modellierung des gesamten Produktes erhält er zudem einen Überblick über die genaue Produkt- und Bauteilstruktur. Das gemeinsame Berechnungsmodell erlaubt es, mehrere Parameter in nahezu beliebigen mathematischen und logischen Zusammenhängen miteinander zu kombinieren, bzw. mit Hilfe von Constraints in Beziehung zueinander zu setzen. Auf diese Weise werden Variablen miteinander verknüpft und schrittweise zunächst durch weit gefasste Wertebereiche, später dann mit immer engeren Intervallen bis hin zu diskreten Werten beschrieben. Aus den Verknüpfungen der Variablen miteinander entsteht ein Informationsnetz, das innerhalb eines Bauteils, einer Baugruppe oder sogar über das ganze Produkt hinweg Informationen verknüpft und so auch komplexe Zusammenhänge abzubilden vermag.

136


Abb. 3.6. Semantische Vernetzung

Nun mag man zu Recht anführen, dass moderne CAD-Systeme einzelne dieser Funktionen oder Analysen ebenfalls bieten. Ja – allerdings nicht alle, nicht alle beliebig kombinierbar und vor allem nur mit konkreten festgelegten Parametern. Eine der großen Stärken des ASK besteht in der Fähigkeit, nicht nur mit fixen Werten operieren zu können, sondern auch mit Wertebereichen oder vordefinierten Wertelisten. Gerade diese Möglichkeit ist in den frühen Entwicklungsphasen unverzichtbar, wenn man sich den gesamten Lösungsraum bewahren will. Selbstverständlich können in CAD-Systemen unterschiedliche Varianten analysiert werden und nahezu jeder Hersteller bietet inzwischen auch umfangreiche Werkzeuge zur Versionsverwaltung an. Es ist jedoch ein Unterschied, ob man ein Produkt betrachtet und sich durch Vorgabe von immer engeren Intervallen bis zum Schluss alle Lösungsmöglichkeiten offen halten kann, oder ob man sich frühzeitig auf eine dedizierte Variante festlegen muss, weil die verwendete Software eine andere Vorgehensweise nicht wirklich unterstützt. 3.2.2 CAD – Datenaustausch Im Rahmen der Entwicklung des Konstruktionssystems war schnell klar, dass die Anbindung an ein grundlegendes Handwerkszeug eines Konstrukteurs, dem CAD-System, realisiert werden musste. Schließlich soll das ASK/ASZ ja nicht herkömmliche Systeme ersetzen oder als ein weiteres Werkzeug ohne jegliche Kopplung parallel eingesetzt werden, sondern den Konstrukteur unterstützen, ihm Arbeit abnehmen und somit Fehler vermeiden und Zeit einsparen.


137

Die Anbindung an ein 3D-CAD-System erfolgte mit Pro Engineer® der Firma PTC. Dieses System verfügte als eines der Ersten über eine Schnittstelle zur automatisierten Anpassung von Parametern einer Konstruktion von außerhalb des Programms. Hierzu waren aber Eingriffe sowohl in das Programm, als auch in das ASK notwendig. Über entsprechende Programmfunktionen können nun vom ASK in das CAD-Modell Parameterwerte übertragen werden und das Bauteil entsprechend mitsamt seinen Wertebereichen visualisiert werden. Dabei bleiben sämtliche Funktionen des CAD-Systems erhalten. Auf diese Weise bleiben auch Zusatzfunktionen wie etwa Datenexport, FEM-Analysen, PDMAnbindung, etc. vollständig erhalten und somit weiterhin nutzbar.

Abb. 3.7. Kopplung von CAD-Modell und ASK/ASZ am Beispiel einer PkwSitzlehnenverstellung

Umgekehrt ist es möglich, ein CAD-Modell in Pro Engineer® zu modifizieren und die Daten in das ASK zu übertragen. Der Konstrukteur wird also nicht aus seinem gewohnten Arbeitsumfeld herausgerissen, was die Einführung einer solchen Software deutlich erleichtert, wenn nicht sogar erst ermöglicht. Ein Informationsverlust tritt bei diesem bi-direktionalen Datenaustausch nicht auf. Auch im Austausch mit dem CAD-System werden nicht nur fixe Werte, sondern auch Wertebereiche für jeden Parameter unterstützt. Die farblich gekennzeichneten Ober- und Untergrenzen eines Intervalls ermöglichen eine schnelle Beurteilung der Geometrie sowie Kollisions- und Bewe-

138


gungsstudien, ohne dazu explizit jeden Wertebereich auf fixe Werte eingrenzen zu müssen. Auf diese Weise sind auch komplexe, räumliche und kinematische Analysen möglich, wie sie im Kap. 5 beschrieben werden. Dazu wäre das ASK alleine nicht im Stande. 3.2.3 Integration der Produktkostenüberwachung Der Kostendruck in Entwicklung und Produktion führt häufig zu Diskrepanzen zwischen F/E- und Controllingabteilungen. Der Spagat zwischen einem optimal gestalteten und dennoch wirtschaftlichen Produkt, das zudem noch zu einem konkurrenzfähigen Preis auf den Markt gebracht werden soll, ist nicht gerade einfach. So manch ein Unternehmen musste sein hochwertiges Produkt aufgrund zu geringer Umsätze doch wieder vom Markt nehmen, bzw. hat sich hoffnungslos verkalkuliert und ist daran zugrunde gegangen. Andere Produkte fallen derart dem Rotstift zum Opfer, dass die Qualität oder gar der Funktionsumfang darunter leidet. Eine Ursache dafür ist sicher darin zu suchen, dass Controller häufig nur unzureichende Einblicke in die komplexen Vorgänge und Zusammenhänge in der Entwicklung erlangen. Damit nicht wegen jeder Kostenoptimierungsmaßnahme größere Sitzungen anberaumt werden müssen, erhalten F/E-Abteilungen vielerorts eigene Controller, die auf die speziellen Erfordernisse und Hintergründe hin sensibilisiert werden. In der Regel werden allerdings nur bestimmte Meilensteine der Entwicklung auf die Einhaltung von Zielkosten hin überprüft. In diesem Stadium ist ein Großteil der Entwicklung jedoch bereits gelaufen und das Produkt bereits in vielen Eckpunkten festgelegt. Eine Umgestaltung ist zu diesem Zeitpunkt nur mit erheblichem Kosten- und Zeitaufwand realisierbar. Auch Änderungen des Lösungsprinzips sind in solch einem Stadium kaum denkbar. Die Berücksichtigung von Kosten ist aber bereits viel früher möglich und auch ratsam, da kostspielige Entwicklungen meist im Vorfeld bereits erkennbar werden – sei es aufgrund der Verwendung von speziellen Werkstoffen, teuer zu fertigenden komplexen Geometrien oder kostspieligen Dauerversuchen zur Verifizierung der Zuverlässigkeit. Der Ausfall von kostengünstigen Komponenten kann schnell zur Kostenfalle werden, wenn diese nicht gut zugänglich sind und zur Wartung oder Reparatur größere Maschinenteile zerlegt werden müssen [3.21], [3.56]. Ebenfalls nicht zu vernachlässigen sind mögliche Folgekosten, die in Form von Garantie- und Kulanzkosten entstehen. Wo an der Produktzuverlässigkeit gespart wird, sind höhere Kosten für Garantie- und Kulanzleis-


139

tungen und deren Abwicklung einzubeziehen. Auch Ersatzleistungen für Maschinenausfälle, Sach- und Personenschäden sind ein enormes Kostenrisiko, das es auszuschließen gilt. Aus diesem Grund ist es sinnvoll, möglichst umfassende und genaue Kostenabschätzungen bereits zu Beginn der Produktentwicklung anzustellen und diese in möglichst kurzen Iterationszyklen zu aktualisieren [3.21]. Einige der Kosten kann der Konstrukteur bereits mit jeder Anpassung selbst verifizieren, aber auch die Arbeitsvorbereitung sollte möglichst früh Einblick in die Entwicklung eines Produktes bekommen. Ein Fachmann für die Arbeitsvorbereitung oder ein Controller kann so frühzeitig auf kostenintensive Bauteile hinweisen und in sehr enger Abstimmung mit den Konstrukteuren Abhilfe schaffen. Das Aktive Semantische Konstruktionsund Zuverlässigkeitsnetz ist in der Lage, eine Konstruktion auf die Einhaltung bestimmter Kostenrahmen hin zu überprüfen und eine Abstimmung über Änderungen zwischen beliebig vielen Beteiligten zu koordinieren. Hierzu werden in entsprechenden Eingabemasken die Zielkosten für jede Baugruppe, bzw. für jedes Element festgelegt und die zu erwartenden Herstellkosten im Laufe der Entwicklung ständig aktualisiert. Wird der Kostenrahmen gesprengt, können die Mehrkosten beispielsweise durch konstruktive Maßnahmen, oder aber durch eine andere Materialwahl gesenkt oder an anderer Stelle des Produktes kompensiert werden. Die Einbeziehung eines Berechnungsmodells zur Abschätzung von Garantie- und Kulanzkosten wird im Rahmen des jüngst gestarteten Transferprojektes weiter verbessert und ebenfalls in das ASK/ASZ integriert. 3.2.4 Integration der qualitativen und quantitativen Zuverlässigkeitsanalyse Steigende Anforderungen an ein Produkt hinsichtlich der Funktionalität und Qualität sind heutzutage die Maßgabe der Kunden an die Entwickler. Durch die immerfort verkürzten Entwicklungszeiten als auch die höhere Komplexität technischer Produkte wird es für die Unternehmen immer schwieriger den hohen Marktanforderungen hinsichtlich Zuverlässigkeitsund Verfügbarkeitskennwerte gerecht zu werden. Die Entwicklung zuverlässiger Produkte erfolgt unter Randbedingungen, die sich zunehmend verschärfen. Die Zuverlässigkeit wird einerseits durch kürzere Entwicklungszeiten, verringerte Entwicklungskosten, höhere Komplexität und größere Funktionalität und andererseits von wachsenden Kundenanforderungen, Minimierung der Fehlerkosten und steigender Produkthaftung beeinflusst [3.7].

140


Heutzutage werden die Anforderungen an ein Produkt bezüglich der geforderten Zuverlässigkeit im Feld schon im Lastenheft vorgegeben. Zu diesem Zeitpunkt gilt diese Zielvorgabe als interner Maßstab für die Entwicklung eines Produktes. Um diese Zielvorgabe über den gesamten Entwicklungsprozess verfolgen zu können, bedarf es einem Zuverlässigkeitssystem, das einen ständigen Vergleich zwischen Zuverlässigkeitsziel- und Zuverlässigkeitsistgrößen erlaubt.

Abb. 3.8. Methoden zur Sicherstellung der Zuverlässigkeit

Eine hohe Produktzuverlässigkeit wird heute nicht mehr alleine auf dem klassischen Weg über ausgereifte Konstruktionsmethoden und -verfahren sichergestellt; vielmehr wird mit der Anwendung spezieller analytischer Zuverlässigkeitsmethoden versucht, die gestiegenen Anforderungen zu erfüllen [3.7], siehe Abb. 3.8. Zuverlässigkeitsbetrachtungen sollten daher aufgrund der hohen Anforderungen in allen Phasen des Produktentstehungsprozesses vorgenommen werden, also auch während der Produktentwicklung. Üblich ist heute im Bereich der Zuverlässigkeitstechnik die Anwendung von Methoden zum frühzeitigen Aufdecken von Schwachstellen (z. B. FMEA [3.73]) und von Maßnahmen zur Zuverlässigkeitsabschätzung in der Produktentwicklungsphase).


141

In Abb. 3.9 ist die aktuelle Vorgehensweise zur Durchführung einer analytischen Zuverlässigkeitsanalyse schrittweise dargestellt.

Abb. 3.9. Vorgehensweise bei der Zuverlässigkeitsanalyse

Bei der Systemanalyse wird das System oder Produkt zu seiner Umgebung hin abgegrenzt und die Funktionsweise aufgezeigt. Das Ergebnis der Systemanalyse ist ein Funktionsblockdiagramm, das als Grundlage für die quantitativen und qualitativen Betrachtungen dient [3.73]. Qualitative Zuverlässigkeitsmethoden werden eingesetzt zur präventiven Identifizierung von kritischen Baugruppen bzw. Komponenten und deren möglichen Fehler. Zudem kann mithilfe der qualitativen Methode eine Definition geeigneter Vermeidungsmaßnahmen aufgestellt werden. Präventive Methoden bieten den Vorteil, dass sie sich im Vorfeld und damit frühzeitig mit dem Produkt beschäftigen. Weiter bieten diese Methoden die Möglichkeit, eventuelle Kosten, die durch ein späteres Fehlerauftreten verursacht werden, weiter zu reduzieren und in der Fehlerbeseitigung (rule of ten) einfließen zu lassen. Die FMEA (Fehler- Möglichkeits- und Einfluss-Analyse) ist die am häufigsten eingesetzte Methode, welche eine weit verbreitete Anwendung in Forschung und Entwicklung findet. Bei der Anwendung der FMEA werden die strukturellen und funktionalen Fehlerzusammenhänge dargestellt und bewertet. Mithilfe der Definition von Vermeidungs- und Entdeckungsmaßnahmen und deren Bewertung ist eine anschließende Risikopriorisierung möglich, anhand derer eine Optimierung und weitere Risikominimierung ermöglicht werden kann. Darüber hinaus bietet die FMEA nach VDA 4 [3.74], durch ihre ausführliche Vor-

142


gehensweise in fünf Arbeitsschritten eine Vielzahl an Schnittstellen zu anderen qualitativen Zuverlässigkeitsmethoden, die mit ihr bereits mit abgedeckt werden können [3.61], [3.60]. Zu einer der wichtigsten Methodenschnittstellen gehört die Schnittstelle zur FTA (Fault Tree Analysis), die sich in weiten Bereichen in aktuellen FMEA Software Tools ebenso darstellen lässt, z. B. in Form eines Fehlernetzes aus dem 2. Schritt der FMEA bzw. in Form von FTA-Grafikmodulen. Eine weitere methodische Schnittstelle ist z.B. zum Ishikawa Diagramm gegeben. Um eine qualitative Betrachtung im Konstruktionsprozess realitätsnah zu erfassen, wurde im Rahmen des Sfb 374 eine Schnittstelle zu einer renommierten FMEA – Software geschaffen. Mit Hilfe dieser Schnittstelle ist es gelungen, die qualitative Methode FMEA im aktiven semantischen Zuverlässigkeitssystem zu integrieren. Somit es möglich, unabhängig und zu jedem Zeitpunkt im Konstruktionsprozess eine Zuverlässigkeitsstruktur aufzubauen und den aktuellen Stand qualitativ zu bewerten. Bei einer Zuverlässigkeitsuntersuchung von einem Konstruktionssystem müssen die Bauteile, Baugruppen oder Systeme vom ASK ins ASZ übernommen werden. Dabei kann mit Hilfe einer qualitativen Vorbetrachtung eine Einteilung in zuverlässigkeitsrelevante oder auch nicht relevante Komponenten unterschieden werden. Dieser Aufbau eines Zuverlässigkeitsnetzes erfolgt teilautomatisiert, d.h. es können Komponenten unterschiedlicher Parameterstruktur einzeln als auch vordefiniert aus der Datenbank gelesen und ins ASZ implementiert werden. Werden nach dem Erstellen des Zuverlässigkeitsnetzes Änderungen von Parameterwerten an der zugrunde liegenden ASK-Konstruktion vorgenommen, so können mit einem speziellen Menüpunkt alle Änderungen an zuverlässigkeitsrelevanten Parametern übernommen und ggf. die Parameter der Verteilungsfunktionen korrigiert werden. Das entwickelte Zuverlässigkeitsprogramm prüft hierbei alle zuverlässigkeitsrelevanten Parameter der zugrunde liegenden ASK-Konstruktion auf Änderungen. Danach wird für geänderte Elemente der Datendialog angezeigt und die Parameter können dann übernommen werden.


143

Abb. 3.10. Auswahldialog des ASZ zur Datenübernahme aus dem ASK

Der Aufbau des Zuverlässigkeitssystems als auch die Anordnung der einzelnen Komponenten ist hierbei nicht begrenzt. Somit ist es möglich, Serien-, Parallel, als auch Mischformen beliebig aufzubauen und nach den Gesichtspunkten der Zuverlässigkeitstechnik genauestens zu analysieren.

Abb. 3.11. Systemeditor des ASK/ASZ zum Anpassen des Zuverlässigkeitsnetzes am Beispiel eines einfachen Mischsystems

Eine rein qualitative Aussage über die Produktzuverlässigkeit ist heutzutage zur Gewährleistung der hohen Zuverlässigkeitsanforderungen nicht mehr ausreichend. Vielmehr sollten durch quantitative Analysen Aussagen über das Ausfallverhalten des Systems gemacht werden. Dies erfolgt da-

144


durch, dass für die Verschleiß- und Ermüdungsausfälle, ausgehend von dem Ausfallverhalten der Systemelemente, eine Aussage über das Ausfallverhalten des Systems ermöglicht wird [3.73]. Im aktiven semantischen Zuverlässigkeitssystem wurden deshalb verschiedene Ausfallverteilungen implementiert, um für die unterschiedlichsten Bauteile und Systeme das Ausfallverhalten ermitteln zu können. Wird beispielsweise für ein Bauteil eine konstante Ausfallrate ermittelt, so erfolgt die Beschreibung des Ausfalls mit Hilfe der Exponentialverteilung. Eine weitere sehr universell einsetzbare Variante ist die Weibullverteilung. Diese im Maschinenbau vielfach bewährte Methode kann dabei in einer zwei- und dreiparametrischen Verteilungsart eingesetzt werden. Die dreiparametrische Weibullverteilung bietet hierbei den Vorteil, eine ausfallfreie Zeit als Parameter in die Betrachtung einfließen zu lassen. Weitere wichtige Verteilungsarten zur Beschreibungen von Zuverlässigkeitsbetrachtungen sind die Normalverteilung als auch die Lognormalverteilung. Um diese wichtigen Verteilungen bei der Durchführung einer Zuverlässigkeitsanalyse im Konstruktionsprozess integrieren zu können, wurde folgende Verteilungsarten in das Zuverlässigkeitsnetz integriert: x x x x

Exponentialverteilung Weibullverteilung Lognormalverteilung Normalverteilung

Nach dem Booleschen Modell kann über die gesamte Konstruktion eine Systemzuverlässigkeit berechnet werden. Dabei ist es möglich, die Gleichung der Systemzuverlässigkeit als auch die Boolesche Matrix grafisch anzeigen zulassen. Die bei einer Zuverlässigkeitsbetrachtung zugehörigen Ergebniswerte wie Zuverlässigkeit, Ausfallwahrscheinlichkeit, Ausfallrate, Ausfalldichte und Überlebenswahrscheinlichkeit können mit dem entwickelten Zuverlässigkeitsprogramm grafisch dargestellt werden. Tools für die optische Aufbereitung und anwenderfreundliche Darstellung sind ebenso integriert worden wie die Möglichkeit einer Exportierung der Grafiken (s. Abb. 3.12.) aus dem Zuverlässigkeitsprogramm heraus. Der Einsatz von Zuverlässigkeitsdatenbanken vereinfacht hierbei dem Entwickler die Parametereingabe von Bauteilen unterschiedlichster Parameterstruktur.


145

Abb. 3.12. Systemgraf der Ausfallwahrscheinlichkeit des Mischsystems aus Abb. 3.11.

Wird in der Anforderung einer Konstruktion eine Zielzuverlässigkeit vereinbart, so muss diese Zuverlässigkeit schon im Entwicklungsstadium des Produktes beachtet werden. Mittels einer integrierten Importanzberechnung ist es möglich, nicht nur die geforderte Zielzuverlässigkeit der erreichten Zuverlässigkeit des untersuchten Systems gegenüberzustellen, sondern auch das zuverlässigkeitskritischste Bauteil analytisch zu erfassen. Damit wird dem Konstrukteur direkt aufgezeigt, welches Bauteil eines Systems für die geforderte Zuverlässigkeit modifiziert werden sollte, um den größten Einfluss hinsichtlich der Zuverlässigkeitsbetrachtung zu erreichen. Der Einsatz einer Importanzberechnung reduziert deutlich die Entwicklungszeit eines Produktes und verringert zudem die Entwicklungskosten.

146


Abb. 3.13. Importanzberechnung (links) und Systemgleichung (rechts) des Mischsystems aus Abb. 3.11.

Insgesamt wurde im Sfb 374 ein Aktives Semantisches Zuverlässigkeitsnetz aufgebaut, welches dem Entwickler zu jedem Zeitpunkt im Entwicklungsprozess eine qualitative als auch quantitative Aussage über den aktuellen Stand der Zuverlässigkeit liefert. In Kombination mit dem ASK ist damit eine Softwareumgebung geschaffen, welche eine ganzheitliche Betrachtung von Bauteilen, Baugruppen und Produktsystemen ermöglicht. Steigende Anforderungen an ein Produkt im Entwicklungsprozess können durch den Einsatz dieses Systems verbessert und maßgeblich vorangetrieben werden. Die Reduzierung von Entwicklungskosten und -zeit durch den Einsatz dieses aktiven semantischen Systems zeigt hier die entscheidende Anwendbarkeit bei innovativen Produkten. 3.2.5 Anwendungsbeispiele Nachdem die wichtigsten Fähigkeiten des ASK/ASZ erläutert wurden, sollen nun am Beispiel eines Pkw-Cockpits und der daran angebundenen so genannten äußeren Schaltung die wesentlichen Bestandteile des Aktiven Semantischen Konstruktions- und Zuverlässigkeitsnetzes veranschaulicht werden. Ausgehend von der Produktplanungsphase und der daraus resultierenden Anforderungsanalyse kann das ASK/ASZ bereits in den frühen Phasen der Produktentwicklung sinnvoll eingesetzt werden. Stück für Stück wird


147

ein Produktabbild in Form eines Netzes erstellt und je nach Entwicklungsstand mit immer präziseren Informationen konkretisiert. Zu Beginn des Entwicklungprozesses wird der Konstrukteur bei der Lösungssuche durch gebräuchliche Methoden der Kreativitätstechniken unterstützt. Ziel der Lösungssuche ist es, entsprechend der Anforderungsliste und der unternehmerischen Rahmenbedingungen (z.B. dem Target Costing) einen optimalen Lösungsvorschlag für das zu entwickelnde Produkt zu erstellen. Unter Zuhilfenahme von analytischen, intuitiv und diskursiv betonten Methoden sowie Konstruktionskatalogen werden potentielle Lösungsansätze erstellt und miteinander kombiniert. Mit verschiedenen Bewertungsmethoden [3.50], [3.56] werden die unterschiedlichen Lösungsvarianten dann bewertet. Hierzu werden auch die in Kap. 3.3 näher erläuterten Tools herangezogen. Im Unterschied zur konventionellen Produktentwicklung (z.B. nach VDI-Richtlinien [3.73], [3.74]) wird jedoch nicht nur das in dieser Phase als die optimale Lösung beurteilte Konzept weiter verfolgt, sondern alle realisierbaren Konzepte. Dies ermöglicht in der beschleunigten Produktentwicklung in Verbindung mit kurzen Iterationszyklen die Verfolgung mehrerer Lösungsansätze, die untereinander kombiniert und variiert werden können, um eine optimale Lösung zu erreichen. Im ASK/ASZ werden die Lösungsprinzipien in Funktionsbausteine zerlegt dargestellt und in weiteren Konkretisierungsschritten mit Baugruppen und schließlich auch Bauteilen verknüpft. Spätestens zu diesem Zeitpunkt lassen sich erste Aussagen über die zu erwartenden Herstellkosten treffen, selbst wenn die Produktkonzepte zunächst nur in Form von abstrakten Komponenten vorliegen. Abschätzungen über die Produktzuverlässigkeit können aus Erfahrungswerten abgeleitet werden. Auch Aussagen über in Frage kommende Herstellverfahren und über die Produktqualität können bereits in dieser Phase der Produktentwicklung angestellt werden. Zwar sind diese Aussagen noch mit relativ hohen Ungenauigkeiten versehen, zur Aufdeckung von Schwachstellen und Tendenzen sind sie jedoch von hohem Wert. Einige Methoden zur Bewertung der Produktqualität werden in Kapitel 3.3 näher erläutert. Methoden der Kreativitätstechnik zur Lösungsfindung und Bewertung wurden im Projektverlauf am IMA [3.50] aufbereitet und über ein Webinterface interaktiv zu Verfügung gestellt.

148


Abb. 3.14. Kreativitätstechnik-Server am IMA

Da in der ersten Phase der Produktentwicklung zunächst nur die Anforderungen definiert sind, ist es sinnvoll, diese bereits im ASK detailliert abzulegen. Neben der Dokumentation der Produktentwicklung dient die Anforderungsliste zur Überprüfung der gesteckten und erreichten Ziele. Eine vollständige und erweiterbare Anforderungsliste ist mitentscheidend für den späteren Erfolg des Produktes am Markt. Daran anknüpfend beginnt die zweite Phase der Produktentwicklung i.d.R. mit der Konzeptionierung von Lösungsvarianten. In dieser Phase werden Anforderungen auf Funktionen abgebildet, die es zu erfüllen gilt. Bereits hier greift die Unterstützung durch das ASK/ASZ, da die Funktionen und ihre Zusammenhänge detailliert abbildbar sind. In Abb. 3.15 wurden so die einzelnen Funktionen ihren Baugruppen, bzw. Bauteilen zugeordnet. Erkennbar sind in dieser Abbildung auch unterschiedliche Konkretisierungsstufen. Während der im unteren Bereich sichtbare elektromechanische Aktor als eigene Baugruppe bereits aus verschiedenen Bauteilen besteht, sind diese beim elektro-mechanischen Aktor (2) als Teile der Steuerung (2) oben rechts im Bild noch nicht ausgestaltet. Dennoch ist die-


149

ser bereits in der Konstruktion als geplante Baugruppe vorhanden und kann hinsichtlich der Zuverlässigkeits- und Kostenbetrachtung bereits berücksichtigt werden. Auch Anschlussgrößen können bereits konkret geplant werden. Auf diese Weise werden moderne Methoden der beschleunigten Produktentwicklung [3.23], wie das Concurrent Engineering oder das Simultaneous Engineering [3.48], [3.51] bestens unterstützt und auch gefördert.

Abb. 3.15. Verknüpfungen von Funktionen mit Baugruppen am Beispiel eines automatischen Kupplungssystems der MB A-Klasse

Es besteht in keiner Weise mehr die Notwendigkeit, verfrüht bestimmte Parameter festlegen zu müssen, sondern der Konstrukteur wird angehalten, mit Variablen zu arbeiten, die erst nach und nach weiter eingeschränkt werden. Durch besonders kurz aufeinander folgende Iterationszyklen wird das Produkt permanent in der jeweils vorliegenden Detailtiefe optimiert und auf Kollisionen im Entwicklungsprozess überprüft. Wird eine solche aufgedeckt, weil z.B. mehrere Konstrukteure an verschiedenen Komponenten entwickeln, so können Kollisionen, durch einen Koordinationsprozess unter den betreffenden Entwicklern abgestimmt, beseitigt werden.

150


Verwendet werden hierzu die im Aktiven Semantischen Netz abgelegten Informationen zu den verantwortlichen Konstrukteuren der kollidierenden Komponenten.

Abb. 3.16. Updateprozess beim verteilten Arbeiten mit dem ASK/ASZ

Dargestellt ist in Abb. 3.16 der Updateprozess bei der verteilten Arbeit mehrerer Konstrukteure am ASK/ASZ. Konstrukteur 1 und 2 laden sich zu beginn ihrer Arbeit den gegenwärtigen Stand der Entwicklung in ihren Client und nehmen fortan Anpassungen in ihrem Änderungsnetz vor. Haben sie einen Stand erreicht, den sie an alle weiteren Mitarbeiter übermitteln wollen, so lösen sie einen Updateprozess aus, der sämtliche Änderungen von den übrigen am Server registrierten Clients einsammelt und auf Konsistenz überprüft. Sind die Änderungen konsistent, so werden alle Änderungen in das Basisnetz überführt und die Clients arbeiten mit dieser abgeänderten Version weiter. Werden jedoch Unstimmigkeiten festgestellt, so werden die verantwortlichen Beteiligten darüber informiert, um diese zu beseitigen. Auf diese Weise wird verhindert, dass mehrere Entwickler unbemerkt jeweils ihre eigenen Entwicklungszweige eröffnen, die im Anschluss zeitaufwändig wieder zusammengeführt werden müssen. Das hinterlegte Rechtemodell stellt sicher, dass ein Entwickler nur solche Bauteile verändert, zu deren Änderung er auch berechtigt ist. Tangieren seine Anpassungen Bauteile, zu deren Änderung keine Berechtigung vorliegt, so wird wiederum ein Abstimmungsprozess in Gang gesetzt. Besondere Beachtung verdient auch das phasenübergreifende Berechnungsmodell [3.53]. Mittels Parametern, die mit Intervallen, Listen oder


151

diskreten Werten unterschiedlicher Ausprägung belegt werden können, ist es möglich, bereits in frühen Phasen mit der zu diesem Zeitpunkt noch herrschenden unzureichenden Produktdefinition umzugehen und dennoch zielführende Berechnungen anzustellen. Zusammenhänge werden in Form von Constraints dargestellt und auf diese Weise auch Parameter miteinander verknüpft. Hierbei sei betont, dass mit den definierten Intervallen, bzw. Listen gerechnet wird. Die Verknüpfung von Intervallen liefert folglich auch wieder Intervalle als Ergebnisgrößen. Durch schrittweises Einschränken der Intervalle werden somit die anderen Parameterintervalle ebenfalls eingeengt. Auf diese Weise gelangt man schrittweise dann zu diskreten und gleichzeitig optimierten Lösungen, ohne vorzeitig den möglichen Lösungsraum einengen zu müssen und mögliche Lösungen auszuschließen.

Abb. 3.17. Schrittweise Diskretisierung einer Übersetzung in der Sitzlehnenverstellung eines Pkw-Sitzes

Auf diese Weise werden bereits in frühen Phasen der Produktentwicklung Auswirkungen von Parametervariationen ersichtlich. Unerwartete Konsequenzen einer Änderung können so frühzeitig im gesamten Produkt, nicht nur in angrenzenden Bauteilen, erkannt werden und der Konstrukteur kann angemessen darauf reagieren. Diese Überprüfung durch das zu Grunde liegende Berechnungsmodell schließt geometrische Bedingungen und Abhängigkeiten mit ein, auch Toleranzfeldanalysen lassen sich mittels dieser Überprüfung durchführen.

152


Die permanente Überprüfung auf die Einhaltung von Zielkosten deckt kostenträchtige Fehlentwicklungen frühstmöglich auf und vermeidet so, dass konzeptionelle Entscheidungen sich erst nachträglich als Kostenfallen erweisen. Die Ergebnisse können durch die bi-direktionale Kopplung an das CAD-System sofort visualisiert werden.

Abb. 3.18. Ausschnitt aus dem Berechnungsmodell zur manuellen Schaltung mit AKS der MB A-Klasse

Verschiedene Ansichten und ein hierarchischer Aufbau ermöglichen es, stets den Überblick auch in komplexen Konstruktionen zu bewahren. So kann der Projektmanager den Fokus auf organisatorische Daten und Fortschritte legen, während der Entwickler eher die Berechnungssicht und die Deteils der Produktstruktur mit einblendet. Neben unterschiedlichen Sichten kann auch in Baugruppen hineingezoomt werden, wobei die umliegenden Komponenten ausgeblendet werden. Analog dazu kann man auch Baugruppen „aufklappen“, um beispielsweise deren Bauteile mit benachbarten Bauteilen in Beziehung zu


153

setzen. Eine Übersicht bietet der Hierarchie-Baum (Abb. 3.19.), der die Produktstruktur übersichtlich darstellt.

Abb. 3.19. Hierarchiebaum der Abbildung eines A-Klasse Cockpits im ASK/ASZ

In der Ausgestaltungs-Phase werden die Konzepte und Entwürfe konkretisiert und erste Produktmodelle erstellt. Hierzu werden im CADSystem die Modelle erstellt und die korrespondierenden Parameter mit denen im ASK über die entsprechende Schnittstelle gekoppelt. Von jetzt an können wahlweise im CAD-System oder im ASK/ASZ Änderungen vorgenommen werden, die automatisch in das jeweils andere System übernommen werden. Diese bi-direktionale Schnittstelle ist deshalb so wichtig, weil auf diese Art keine Bauteilinformationen verloren gehen. Die im ASK/ASZ als abstrakte Elemente vorliegenden Bauteile können im CAD-System visualisiert und ausgestaltet werden. So entsteht das CAD-Modell (Abb. 3.20.), hier wieder am Beispiel der Handschaltung mit automatischem Kupplungssystem (AKS) als Teil des A-Klasse Cockpits.

154


Abb. 3.20. CAD-Modell der manuellen Schaltung mit AKS der MB A-Klasse

Ist ein bestimmter Konkretisierungsgrad in der Erstellung der Produktstruktur erreicht, so ist für kritische Bauteile eine qualitative Zuverlässigkeitsanalyse anzuraten. Bei der FMEA (Fehler-Möglichkeits- und Einfluss-Analyse) werden Systeme in ihre Bestandteile zerlegt und deren Funktion ermittelt. Die negierte Funktion ergibt die entsprechende Fehlfunktion, deren Ursache und Auswirkung auf das Gesamtsystem genau spezifiziert wird. Mit verschiedenen Faktoren für Auftretenswahrscheinlichkeit, Auswirkung und Entdeckungswahrscheinlickeit versehen, kann so eine Risikoprioritätszahl (RPZ) ermittelt werden, mit deren Hilfe abgewägt werden kann, an welchen Bauteilen besondere Maßnahmen zu treffen sind. Mit dem Aktiven Semantischen Konstruktions- und Zuverlässigkeitsnetz ist eine solche FMEA sehr effektiv vorbereitbar. Die komplette Produktstruktur wird in das ASZ eingelesen und von dort in das FMEA-Tool „IQ-FMEA“ transferiert (Abb. 3.21.). Hier werden nachfolgend dann die entsprechenden Formblätter ggf. noch ergänzt. Durch diesen teilautomatisierten Vorgang wird sichergestellt, dass die komplette Produktstruktur mit allen Einzelteilen in der FMEA berücksichtigt wird. Zudem spart dieser Vorgang enorme Zeit, da normalerweise im Zuge der FMEA zunächst alle diese Daten aufwändig gesammelt werden müssen.


155

Abb. 3.21. Aus dem ASK/ASZ importierte Bauteilstruktur in FMEA-Software

Die FMEA hat zum Ziel, die Produktqualität zu verbessern. Sinnvoll ist also, die im Zuge einer ersten Iterationsschleife erarbeiteten Entdeckungsund Vermeidungsmaßnahmen durchzuführen und daraufhin erneut mittels einer FMEA die optimierten Systeme zu bewerten. Die qualitative Zuverlässigkeitsanalyse setzt die Kenntnis hinreichend genauer Ausfalldaten voraus. Sind diese jedoch durch Vorgängerprodukte oder Simulationen abschätzbar, oder durch Prüfstandsversuche bekannt, so kann das Ausfallverhalten ganzer Systeme ermittelt werden. Die zu untersuchende Konstruktion wird hierzu aus dem ASK in das ASZ übernommen, wobei bei der Datenübernahme verschiedene Fälle unterschieden werden können. Je nach Entwicklungsstand kann es sinnvoll sein, nur bestimmte Komponenten in den Systemeditor des ASZ zu impor-

156


tieren. Aus diesem Grunde stehen dem Benutzer drei Wahlmöglichkeiten zu Verfügung (s. Abb. 3.10.): x Import solcher Elemnte, die bereits Daten enthalten x Import sämtlicher Elemente x Import von manuell ausgewählten Elementen Im Normalfall werden sämtliche Elemente der Konstruktion importiert. In bestimmten Fällen kann es jedoch sinnvoll sein, eine Systemanalyse eines bestimmten Bereiches der Konstruktion durchzuführen, um z.B. besonders kritische Bereiche getrennt zu untersuchen, oder um Bereiche auszusparen, die in der Entwicklung noch nicht weit genug fortgeschritten sind. Im Systemeditor des ASZ werden die Konstruktionselemente nun entsprechend ihres Zuverlässigkeits-Kontextes zueinander platziert und ergeben so ein Zuverlässigkeitssystem. In Abb. 3.22 ist dies am Beispiel der äußeren Handschaltung mit AKS durchgeführt.

Abb. 3.22. Zuverlässigkeitssystem einer Handschaltung der MB A-Klasse

Zu jedem der einzelnen Zuverlässigkeitsknoten, die in Abb. 3.22 dargestellt sind, werden nun die Zuverlässigkeitsparameter hinterlegt, die das Ausfallverhalten der einzelnen Komponenten beschreiben. Um das Ausfallverhalten des Gesamtsystems zu ermitteln, werden die einzelnen Daten miteinander verrechnet. Mit der Importanzanalyse kann nun überprüft werden, welche Systemzuverlässigkeit zu einem vorgegebenen Zeitpunkt vorliegt, ob die Sollvorgaben erfüllt wurden und welche Zuverlässigkeit die einzelnen Komponenten zu diesem Zeitpunkt erreichen. Wird die geforderte


157

Systemzuverlässigkeit nicht erreicht, so werden die schwächsten Glieder hervorgehoben und markiert. Auf diese Weise sind sofort die Komponenten identifiziert, die die Zuverlässigkeit des Gesamtsystems maßgeblich negativ beeinflussen. Zur Veranschaulichung können die einzelnen Ausfallkurven und auch die Kurve des Gesamtsystems über der Zeit grafisch dargestellt werden. Zur Auswahl stehen dabei Ausfalldichte, Ausfallrate, Ausfallwahrscheinlichkeit und Überlebenswahrscheinlichkeit. Jedes der Diagramme kann in unterschiedlichen Darstellungsformen angezeigt werden, als Normalverteilung, Log-Normalverteilung und als Weibullverteilung. In Abb. 3.23 ist die Ausfallwahrscheinlichkeit am Beispiel der Handschaltung dargestellt. Die Daten wurden zur Wahrung der Vertraulichkeit absichtlich verzerrt und auf nicht veröffentlichte Werte normiert. Sie entsprechen nicht den tatsächlichen Daten und dienen hier lediglich der Demonstration der Vorgehensweise.

Abb. 3.23. Normierte Ausfallwahrscheinlichkeit über der Zeit der Handschaltung mit AKS einer MB A-Klasse

158


3.2.7 Zusammenfassung Das Aktive Semantische Konstruktions- und Zuverlässigkeitsnetz ASK/ASZ ist ein Softwareprototyp zur Unterstützung von interdisziplinären Teams in der Produktentwicklung. Die besonderen Stärken liegen in der Verwendung in frühen Phasen der Produktentwicklung und in seiner felxiblen Anwendbarkeit. Im Gegensatz zu kommerziell erwerblichen Anwendungen ist es kein Spezialtool, das zu einem dedizierten Zeitpunkt für eine einzige Aufgabe Anwendung findet, sondern es ist darauf ausgelegt, während des gesamten Entwicklungsprozesses und auch darüber hinaus produktbegleitend eigesetzt zu werden. Das ASK/ASZ ersetzt hierbei nicht die bereits verwendeten und im Unternehmen etablierten Softwarewerkzeuge, sondern ist als Bindeglied dazwischen anzusehen. Es dockt an bestehende CAD-Systeme, Datenbanken und Zuverlässigkeitssoftware an und stellt diesen Daten zur Weiterverarbeitung zu Verfügung. Gleichzeitig stellt es sämtliche nur erdenkliche Produktionformationen unter einer einfach zu bedienenden Oberfläche dar, die es ermöglicht, jederzeit mit konsistenten Daten im gesamten Team, wie auch im Unternehmen koordiniert zu arbeiten und unter besonderer Berücksichtigung von Zielkosten und der Systemzuverlässigkeit zu entwickeln. Die Unterstützung in der Entwicklung reicht von Einzelprodukten, über Produktreihen bis hin zu Produktsystemen und Baukästen und erweitert so den Einsatzbereich über den des RPD hinaus bis zur Serienentwicklung. Im ASK/ASZ wurden mit diesen modularen Funktionen Teile des AKlasse Cockpits in unterschiedlichen Varianten abgebildet, die zeigen, wie unterschiedliche Konfigurationen von Bausteinen in ihrer Kombination überprüft und modelliert werden können. Unterschiedliche Varianten können so im Sinne eines Variantenmanagements als Bausteine eines Baukastens abgelegt und wieder verwendet werden. Die integrierte Bauteilbibliothek erleichtert die wirtschaftliche Produktentwicklung durch die Verwendung im Unternehmen bereits bekannter Komponenten und vermeidet unnötige doppelte Entwicklung. Durch den verwendeten Ansatz des semantischen Netzes können Auswirkungen von Entwicklungsansätzen auf das gesamte Produkt sichtbar gemacht werden, was zu optimierten und gleichzeitig kostengünstigen Lösungen führt. Das verwendete Berechnungsmodell kann mit unscharfen Parametern umgehen und erlaubt so eine der Grundvorraussetzungen des Rapid Pro-

3.3 Qualitätsmanagement im Rapid Prototyping

159

duct Development – der späten Produktfestlegung und zudem auch den Einsatz in frühsten Entwicklungsstadien, wo einzelne Parameter noch nicht definiert sein können.

3.3 Qualitätsmanagement im Rapid Prototyping Die Schaffung bzw. Sicherung von Wettbewerbsvorteilen durch hohe Qualität der Produkte sowie ein frühest möglicher Markteintritt erfordert ein Umdenken bezüglich der organisatorischen und technischen Abläufe in einem Unternehmen. Dazu gehören eine optimale Verknüpfung der Kriterien Zeit, Kosten und Qualität (Bedingungen für die volle Zufriedenstellung der Kunden und den Erfolg des Unternehmens) und eine qualitätsbewusste und prozessorientierte Betrachtungsweise [3.29]. Zur Erreichung dieser Ziele werden einerseits Qualitätsmanagementmethoden eingesetzt, die auf einzelne wertschöpfende Prozesse und Prozessketten anwendbar sind. Andererseits kommen Methoden zur globalen Integration von Kompetenzen, Informationen und Ressourcen im ganzen Unternehmen zum Einsatz. Dabei werden Verfahren zur Verfügung gestellt, die den Anwender während eines Produktentwicklungsprojektes durch eine kontextsensitive Auswahl und Anpassung von Methoden unterstützen, indem Expertenwissen breit verfügbar gemacht wird. Besonders in der Prototypenfertigung müssen jedoch neue Ansätze und Techniken implementiert werden, um den Anforderungen an die hohe Qualität in kleinen Stückzahlen gerecht zu werden. Nur so können aussagekräftige Informationen über die spätere Produktqualität gewonnen werden. Zum Erreichen dieser Ziele werden durch die Bereitstellung geeigneter Methoden Instrumente zur Integration von Qualitätsstrategien und -techniken zur Verfügung gestellt. Die einzelnen Techniken allein garantieren noch nicht die Entwicklung innovativer, qualitativ hochwertiger und am Markt erfolgreicher Produkte. Zur Realisierung dieses Ziels ist ein ganzheitliches Konzept (Zeit, Kosten und Qualität) erforderlich, das sowohl den flexiblen Einsatz unterschiedlichster Technologien unterstützt, als auch die informationstechnischen, methodischen und organisatorischen Aspekte beachtet [3.30]. Deshalb umfassen die Forschungsthemen im Bereich des Qualitätsmanagements speziell die folgenden Bereiche:

160


x Prognose der Produktqualität in frühen Phasen (z. B. auf Basis erster vager Markmaldefinitionen) x Absicherung und Optimierung der Entwicklungsqualität durch wissensbasierte Systeme x Methodische und technische Unterstützung von Qualitätsprüfungen (z. B. Informationsextraktion aus der zerstörungsfreien 3D Prüfung) x Grundlagen für Richtlinien im Rapid Prototyping (Prüfverfahren, Prüfplanung, Prototypen-Reviews und Audits) Ein umfassendes Qualitätsmanagementkonzept ist notwendig, um zu einem effizienten, flexiblen und unternehmensangepassten Produktentwicklungsprozess zu gelangen. Mit dem Einsatz von Verfahren des Rapid Prototyping entstehen grundlegende Fragestellungen rund um die Produktgestaltung. So werden sowohl die funktionsorientierte Konzeption des Produktes wie auch seine ästhetische Gestalt bereits zu einem sehr frühen Zeitpunkt der Produktentwicklung betrachtet. Deshalb wurde durch die Integration der einzelnen Lösungsansätze in einer Qualitätsmanagement-Toolbox ein Werkzeug entwickelt, das den Unternehmen als Hilfsmittel für ihre unternehmensspezifischen Aufgaben zur Verfügung steht und die Bildung von Insellösungen im Entwicklungsprozess vermeidet (Abb. 3.24.).

Abb. 3.24. Konfigurierbare RPD-Qualitäts-Toolbox

Ziel der Forschung in diesem Vorhaben war nicht nur, das Leistungspotenzial der verschiedenen Rapid Prototyping Verfahren in Bezug auf die Qualitätssicherung in der Entwicklung darzustellen, sondern auch durch eine effektive Methodenanwendung Schwachstellen des Einsatzes der Rapid Prototyping Verfahren aufzuzeigen. Dadurch können das Verständnis und die Kommunikation zwischen unterschiedlichen Teilphasen und Bereichen im Produktentwicklungsprozess optimiert und zielgerichtet die Anwendung und Nutzung der Verfahren durch entsprechende Handlungs-


161

empfehlungen verbessert werden. Der methodische Baukasten wird den folgenden Phasen zugeordnet: x x x x

Frühe Phasen – Prognose und Merkmalsextraktion (3.3.1) Methoden der Risikoanalyse in der Produktkonfiguration (3.3.2) Verfahren und Methoden der Prozessüberwachung (3.3.3) Systemfeedback – Umfassendes Qualitätsmanagement mit material- und prozessimmanenten Informationen (3.3.4)

Darüber hinaus wird gezeigt, wie durch eine effektive Verbindung der Methoden und Prüftechniken der Bogen von der Generierung der Daten, über die Nutzung des generierten Wissens in der Entwicklung bis hin zur Qualitätskontrolle des Produktes in Form von Vollständigkeitsprüfung sowie Soll-Ist-Vergleich mit den Ausgangsdaten, gespannt werden kann. 3.3.1 Frühe Phasen – Prognose und Merkmalsextraktion Die frühen Produktentwicklungsphasen sind von Designarbeit geprägt und beinhalten vor allem das Finden und Entwickeln von Konzepten für das Produkt und seine Funktionalität. Dabei fließt ein, dass heute an die Produkte hohe Ansprüche hinsichtlich Qualität und technischen Standard bei gleichzeitig immer stärkerer Individualisierung gestellt werden. Im Wettbewerb rücken deshalb zusätzliche, vom Design geschaffene Differenzierungsmerkmale in den Vordergrund. Eine ästhetisch-funktionale Gestalt ist nicht nur für den Endverbraucher ein Kaufargument für oder gegen das Produkt, sondern gilt auch bei den Unternehmen selbst als unternehmensstrategisches Heraushebungs- und Alleinstellungsmerkmal. Qualitätsmerkmale beim Aufbau virtueller Designmodelle Die frühen Produktentwicklungsphasen liefern erste Entwürfe in Designmodellen und konzeptionellen Prototypen, die Varianten in Form und Funktion repräsentieren und deren Herstellung bisher fast nur per Handarbeit erfolgt. Diese Modelle repräsentieren zunächst nicht vollständig ausdetaillierte, unscharfe Produktdaten, die ein Festlegen und Verifizieren von Qualitätsmerkmalen im klassischen Sinn einer CAD-Modelliermethode (vollständige, skalierte Produktdaten) nicht ermöglichen. Eine Einbeziehung in die RPD-Prozesskette erfordert deshalb Methoden zur Abstraktion und Quantifizierung von Qualitätsaussagen. Diese basieren auf Modellierstrategien zum Aufbau Rapid-Prototyping-fähiger virtueller Designmodelle. Mit der Einbindung der frühen Entwurfsphasen in die Rapid-Product-

162


Development-Prozesskette soll einerseits der Designer die Möglichkeit erhalten, Werkzeuge aus den vielfältigen Rapid Prototyping Verfahren nutzen zu können, andererseits sollen die oben geforderten Methoden zur Qualitätssicherung zur Verfügung stehen (Abb. 3.25.).

Abb. 3.25. Designmodelle für die Merkmalsextraktion

Die Integration des Entwurfsprozesses eines Produktes in die Rapid Product Development Prozesskette beschreibt zunächst die digitale Modellierung klassischer und konventioneller Designmittel wie Skizze, Entwurfspläne oder handgefertigtes Formmodell. Für die Abstraktion und Definition relevanter Modelleigenschaften für die Simulation geometrischer, physikalischer oder funktionaler Eigenschaften am physischen Prototypen (z. B. metallisches funktionelles Beschichten) und / oder virtuellen Prototypen (z. B. Strömungssimulation) müssen dazu die virtuellen Interpretationen der Entwurfsmodelle und / oder des konzeptionellen Prototypen aufbereitet werden. Dabei muss ermöglicht werden, aus mit geeigneter Sensorik erfassten unscharfen Produktdaten und somit, im Hinblick auf CAD-Modelle, unvollständigen Entwurfsmodellen, Rapid-Prototypingfähige virtuelle Modelle zu erzeugen. Für die Methoden zur Qualitätssicherung, die die Besonderheiten von Entwurfsmodellen und konzeptionellen Prototypen berücksichtigen, wurden die aus digitalisierten Designmodellen aufgebauten CAD-gerechten Modellstrukturen genutzt. Diese eignen sich für das Erfassen von Modellen unterschiedlicher Ausprägung, Dimension und Materialien und sind gleichzeitig dem gewohnten Arbeitsumfeld des Designers angepasst [3.76]. Die Methoden sind an Gestaltungslinien (Lichtkanten) ausgerichtet. Ihrer Einführung ging eine Untersuchung über die Entstehung von Lichtkanten auf Designmodellen voraus. Die Idee geht auf Aussagen von De-


163

signern zurück, wonach Lichtkanten die Form eines Produktes in der menschlichen Wahrnehmung prägen. (Abb. 3.26.)

Abb. 3.26. Bestimmung der Form durch Lichtkanten

Die Untersuchungen wurden an unterschiedlichen, in der Designbranche für die Herstellung von Modellen verwendeten Materialien durchgeführt. So wurden Materialien, die gewisse Glanzeigenschaften haben, wie zum Beispiel Clay, getestet, wie auch im Reflexionsverhalten total gegensätzliche Materialien wie zum Beispiel Hartschaum. Entscheidungsunterstützung zur Prognose der Produktqualität In den frühen Phasen einer Produktentwicklung sind die Möglichkeiten zur Produktgestaltung mit dem Ziel, die Qualität des Produktes positiv zu beeinflussen, besonders hoch. Die hierfür entscheidenden Faktoren stehen jedoch in einem komplexen Verhältnis zueinander, wodurch verlässliche Aussagen über die zu erwartende Qualität des Endproduktes, über Parameter, die diese signifikant beeinflussen sowie über potenzielle Risiken der Entwicklung schwer zu treffen sind. Die hohe Dynamik und die komplexen Iterationszyklen in Entwicklungsnetzwerken erschweren solche Prognosen noch zusätzlich [3.6]. Deshalb wird ein Bewertungsmodell zur Verfügung gestellt, das einerseits Wissenselemente aus den verschiedensten Bereichen zusammenführt und andererseits auch bei unsicherem Wissen zuverlässige Qualitätsprognosen ermöglicht [3.5]. Ziel dieser Prognosen ist es, potenzielle Fehlentwicklungen zu erkennen, damit rechtzeitig entgegengesteuert werden kann. Dabei ist es notwendig, sowohl die technischen als auch die organisatorischen Prozesse zu modellieren, um sie besser prognostizieren zu können. Eine geeignete Lösung stellt eine simulationsbasierte Bewertung von qualitätsbeeinflussenden Randbedingungen und Elementarprozessen des Rapid Prototyping dar.

164


Dadurch kann eine wahrscheinlichkeitstheoretisch fundierte Abschätzung über die zu erwartende Qualität der Entwicklung gemacht werden.

Abb. 3.27. Das Bewertungsmodell auf der obersten Hierarchieebene

Das entwickelte Bewertungsmodell soll die Auswirkungen und Einflüsse von entwicklungsrelevanten Aktivitäten wie z. B. Prototypherstellung und Prozessbeherrschung auf die Produktqualität modellieren. Der Zusammenführung der Erkenntnisse aus verschiedenen Bereichen kam dabei eine zentrale Bedeutung zu. Auf der obersten Ebene des hierarchisch strukturierten Modells wurden zunächst vier Wissensklassen modelliert, die alle einen direkten Einfluss auf die Qualität des Endprodukts haben (Abb. 3.27.): x x x x

die Qualität der Zusammenarbeit im Entwicklungsnetzwerk, die Prognosefähigkeit der Prototypen, das technische Entwicklungsrisiko und die Prozessfähigkeit der Prototypenherstellverfahren.

Es wurden also verschiedene Aspekte der Produktentwicklung in das Bewertungsmodell integriert. Die Qualität des Endprodukts hängt von den obigen vier Bereichen ab. Das Modell bezieht sowohl Risiken der aktuellen Entwicklung, welche auch auf Informationen der Vergangenheit basie-


165

ren können, als auch Wissen über Prototypen und ihre Fertigungsverfahren mit ein. Des Weiteren wurden die verschiedenen Teilentwicklungen im Entwicklungsnetzwerk sowie die zwischen diesen Subsystemen gegebenenfalls existierenden Interdependenzen berücksichtigt. In einem ersten Schritt wurde zunächst das qualitative Modell erstellt, das die Zusammenhänge, Kausalitäten und Abhängigkeiten der einzelnen Wissenselemente enthält. Hierzu wurde bekanntes Wissen und durch Expertenbefragungen erworbenes Wissen, das in mehreren Iterationen sukzessive optimiert wurde, im Modell abgebildet. Auf einer zweiten Hierarchieebene wurden die vier oben genannten Einflussklassen verfeinert. So ist beispielsweise in Abb. 3.28 das Modell der Klasse Prognosefähigkeit des Prototypen auf der nächsten Ebene dargestellt.

Abb. 3.28. Teilmodell „Prognosefähigkeit des Prototypen“

Die Prognosefähigkeit des Prototypen hängt einerseits von der Erfahrung, die man bisher mit dieser Art von Prototyp gesammelt hat (PTErprobung), und andererseits von der Aussagefähigkeit des Prototypen ab. Die Aussagefähigkeit wiederum hängt auf der einen Seite von den charakteristischen Eigenschaften des Prototypen wie Oberflächengüte, Belastbarkeit usw. ab, die ihrerseits durch die Wahl der Materialien und Herstellverfahren beeinflusst werden. Auf der anderen Seite fließen Prozessfähig-

166


keitskennwerte, eventuelle Verfahrens- und Maschinenfehler sowie die Anforderungen, die an den aktuellen Prototypen gestellt werden, in die Bewertung der Aussagefähigkeit mit ein. Die übrigen drei Klassen auf der obersten Hierarchiestufe des Bewertungsmodells wurden auf analoge Weise modelliert. Das Modell kann an beliebiger Stelle verfeinert werden, indem weitere Hierarchieebenen hinzugefügt werden. Das so konstruierte qualitative Modell wurde mit Hilfe von Wahrscheinlichkeiten quantifiziert, die den im obigen Teilmodell dargestellten Knoten, die im wahrscheinlichkeitstheoretischen Sinne Zufallsvariablen repräsentieren, zugeordnet werden. Den Knoten ohne Vorgänger werden sogenannte a-priori-Wahrscheinlichkeiten zugeordnet, die durch Erfahrungswissen geschätzt werden können. Falls kein Wissen vorhanden ist, wird dem Knoten die Verteilung mit dem maximalen Informationsgehalt zugeordnet, was im Falle endlich vieler Zustände die Gleichverteilung ist [3.42], [3.41]. Das Modell wird in der Hierarchie top-down quantifiziert, das heißt, zunächst werden nur die Verteilungen der ersten Hierarchiestufe angegeben. Das hieße in unserem Modell, dass für die vier Klassen Prozessfähigkeit, Prognosefähigkeit des Prototypen, technisches Entwicklungsrisiko sowie Integration der Entwicklungsnetzwerke zunächst Zustände definiert werden müssen und anschließend jeweils eine diskrete Verteilung eingeführt werden muss. Damit können schon in frühen Phasen grobe Vorhersagen über die Produktqualität gemacht werden. Je tiefer das Modell verfeinert bzw. quantifiziert wird, desto verlässlicher werden die Prognosen. Zusätzlich zur technischen und organisatorischen Betrachtung können auch Zeit- und Kostenaspekte mit in das Modell integriert werden. Hierzu notwendige Informationen werden unter anderen von dem mehrdimensionalen Steuerungsinstrument Zeit, Kosten, Qualität geliefert. Es wird also eine Bewertung in einem dreidimensionalen Raum vorgenommen. Nach einer derartigen Vorhersage, die sowohl die Qualität als auch die zu erwartenden Herstellkosten sowie die geschätzte Zeit bis hin zur Serienreife prognostiziert, muss im Einzelfall entschieden werden, welche Maßnahmen gegebenenfalls zu treffen sind. Das, wie oben beschrieben, durch Expertenwissen quantifizierte Modell kann durch beobachtete Werte bestimmter Parameter des Modells mit Hilfe von Lernalgorithmen verbessert werden [3.34]. Das geschieht durch das Lernen der Wahrscheinlichkeitswerte im Modell. Im Allgemeinen ist es sinnvoll, bei den einzelnen Knoten bzw. Zufallsvariablen die Anzahl der Zustände nicht zu groß zu wählen. Damit wird die Quantifizierung des Modells erheblich erleichtert, da die bedingten Wahrscheinlichkeitstabellen kleiner ausfallen. Dies ist sowohl für die Abschätzung der Wahrscheinlichkeitswerte durch den Experten als auch für


167

die oben angesprochenen Lernalgorithmen ein wichtiges Effizienzkriterium. In unserem Modell wurden deshalb die Anzahlen der Zustände meistens zwischen zwei und maximal fünf gewählt. Nur wenige Variablen bilden hier Ausnahmen wie z. B. der Knoten Produktqualität, der als Ergebnisknoten von besonderer Wichtigkeit ist und deshalb detaillierter modelliert wurde. Ein zweites Beispiel ist die Zufallsvariable Material, die die für die Prototypenherstellungsverfahren möglichen Werkstoffe beschreibt und somit hier so viele Zustände notwendig sind, wie Werkstoffe benutzt werden. 3.2.2 Methoden der Risikoanalyse in der Produktkonfiguration Betrachtet man die Anwendbarkeit von Qualitätsmanagementmaßnahmen bei den Basisprozessen im Unternehmen (wie z. B. Risikomanagement) so zeigt sich, dass diese Prozesse insbesondere im Rapid Product Development bisher vernachlässigt wurden. Die Arbeiten in diesem Projekt dienen unter anderem dazu, das bestehende Nachholpotenzial der wesentlichen Basis- und Supportprozesse im Feld der Produktkonfiguration sowie des technischen Risikomanagements zu befriedigen. Unterstützung der Produktkonfiguration durch Komplexitätsbetrachtung im Rapid Prototyping Die Veränderung der Rahmenbedingungen in der kundenspezifischen Produktentwicklung und die Modularisierung des Entwicklungsprozesses führen zur Entstehung einer enormen Vielfalt möglicher Produktvarianten und Produktinnovationen. Bei dieser Entwicklung können die Vorgaben für das Produktdesign sehr unterschiedlich sein. Auf der Grundlage von Ideen, Designvorgaben, Skizzen oder von physisch existierenden Bauteilen können neue Produkte konzipiert und auf Basis geeigneter Prototypen getestet werden. Die Folgen der erhöhten Produktkomplexität sind bereits hier deutlich erkennbar. Durch eine gezielte Produktentwicklung in hybrider (digitaler und physischer) Umgebung und Erprobung können jedoch bereits in den frühen Phasen die funktionellen Zusammenhänge und Qualitätsmerkmale erkannt und potenzielle Fehlerquellen reduziert werden. In diesem Teilprojekt wurden die physischen Prototypen und die zugehörigen Prozesse und Methoden untersucht, um mit den RP-Verfahren nicht nur die einzelnen Prototypen zu bauen, sondern auch Qualitätskriterien für neue komplexe Produkte zu untersuchen. Die komponentenbasierte integrative Bauweise bietet zwar eine hohe Flexibilität, birgt aber die Gefahr einer schwer zu handhabenden kombinatorischen Vielfalt. Die Ra-

168


pid Technologien bieten hier völlig neue gestalterische Freiheiten, die in der Produktentwicklung gewinnbringend eingesetzt werden können. Es wird deutlich, dass die Konstruktionen verändert werden können, in dem die Produktgeometrien und -parameter frühzeitig genau charakterisiert werden. Die Ausnutzung der neu gewonnenen Freiheiten in der Konzeption und Konstruktion von Produkten führt zu einer Geometrieoptimierung, zu einer Komponentenreduktion und zu einer besseren Produktqualität [3.4]. Auf Basis der entwickelten Konfigurationssystematiken können verbesserte Produkteigenschaften, kontrollierte Änderungen der Geometrien und Funktionserweiterung erreicht werden. Darüber hinaus wurden Ansätze aus der Analogie- sowie Strukturierungsmethodik untersucht und Qualitätsmodelle in den frühen Produktentwicklungsphasen entwickelt. Abschließend wird noch eine Implementierung dieser wissensbasierten Methodik zur Vermeidung und Reduktion der Komplexität für die hier betrachteten Szenarien entwickelt und als ein Baustein in der Qualitätstoolbox integriert [3.26]. Methodik zur kontextsensitiven Methodeauswahl Die Methodenanwendung in der Produktentwicklung stellt in der Praxis häufig ein Problem dar. Auf der einen Seite gibt es Schwierigkeiten mit der Auswahl einer für eine gegebene Problemstellung geeigneten Methode und andererseits mangelt es an der geeigneten Anpassung der Methodenausführung an die problem- und unternehmensspezifischen Randbedingungen. Insbesondere die durch die speziellen Anforderungen des Rapid Prototyping an die Methodenanwendung veränderten Rahmenbedingungen machen eine effiziente Methodenauswahl noch schwieriger. Deshalb wird eine Methodik zur kontextsensitiven Methodenauswahl bereitgestellt, die den Entwickler unterstützt, den Forderungen an eine flexible und bedarfsorientierte Methodenanwendung bei den Aktivitäten während der Produktentwicklung gerecht zu werden. Die kontextsensitive Methodenauswahl ist im Wesentlichen ein Entscheidungsproblem mit endlich vielen Entscheidungsalternativen, das von gewissen Randbedingungen, deren Gesamtheit den Kontext bildet, beeinflusst wird. Dieser Kontext ist meistens nicht vollständig spezifizierbar, so dass mit unsicherem und unvollständigem Wissen gearbeitet werden muss. Es liegt nahe, die sogenannten Einflussdiagramme zur Modellbildung heranzuziehen, da diese die obigen Anforderungen erfüllen [3.40]. Zu den wichtigsten Eigenschaften dieser Einflussdiagramme gehört unter anderen, dass sich das unsichere Wissen im Produktentwicklungsprozess z. B. bezüglich der nicht vollständig spezifizierten Randbedingungen


169

geeignet darstellen lässt und mit Methoden der Wahrscheinlichkeitstheorie sinnvolle Schlussfolgerungen gezogen werden können [3.14], [3.16], [3.43], [3.59]. Einflussdiagramme stellen eine Erweiterung Bayes’scher Netze dar. Bayes’sche Netze sind gerichtete azyklische Graphen, in denen die Knoten die Variablen – in dieser Anwendung z. B. Randbedingungen, Eignungskriterien o. ä. – darstellen und die Kanten die Existenz direkter kausaler Zusammenhänge denotieren (Abb. 3.29.). Hierbei wird die Stärke dieser Abhängigkeiten auf Basis bedingter Wahrscheinlichkeiten angegeben und Knoten ohne Einflüsse werden durch a-priori-Wahrscheinlichkeiten quantifiziert. Das in Abb. 3.29 (a) angegebene Beispiel für ein Bayes’sches Netz spiegelt folgenden Sachverhalt wider: Für die Methodenauswahl werden Eignungskriterien wie Zielführung, AufwandNutzen-Verhältnis o. ä. herangezogen, d. h., die Eignung der Methoden wird anhand bestimmter Kriterien bewertet. Die Wahl der Methode hat einen Einfluss auf die Bewertungskriterien, was im Abb. 3.29 (a) durch die beiden Kausalpfeile dargestellt ist. Ferner hängen die Kriterien von kontextspezifischen Randbedingungen im RPD wie z. B. dem Innovationsgrad der Entwicklung ab. Diese Kausalität ist im Beispiel, das nur einen Ausschnitt des gesamten Netzes darstellt, ebenfalls durch einen Pfeil repräsentiert.

Abb. 3.29. Ausschnitt aus dem Entscheidungsnetz für die Methodenauswahl

Bei den Einflussdiagrammen werden zwei neue Knotentypen eingeführt, nämlich die Nutzenknoten und die Entscheidungsknoten. Die Entscheidungsknoten repräsentieren alle Alternativen einer bestimmten Entschei-

170


dung und können mit Zufallsknoten im Sinne eines Bayes’schen Netzes beliebig verknüpft werden. Nutzenknoten repräsentieren die Präferenzen des entscheidenden Agenten bezüglich einer oder einer Menge von Entscheidungen und werden von den Entscheidungsknoten zumindest indirekt beeinflusst. Ein Nutzenknoten kann dabei nur Vorgänger und keine Nachfolger besitzen [3.55]. In unserer Anwendung soll eine Entscheidung bezüglich der zu wählenden Methode getroffen werden. Im Beispiel aus Abb. 3.29 (a) werden wir deshalb den Zufallsknoten Methode in einen Entscheidungsknoten umwandeln, der durch ein Rechteck dargestellt wird (Abb. 3.29 (b)). Nun muss noch ein Nutzenknoten definiert werden, um die Güte der jeweiligen Entscheidung – in unserem Fall die gewählte Methode – zu bewerten. Dies kann auf einer beliebigen reellen Skala geschehen, z. B. einem Intervall von 0 bis 100, wobei 0 den geringsten Nutzen und 100 den größten Nutzen darstellt. Der Nutzen – im Netz als Raute dargestellt – hängt hierbei sowohl von der gewählten Methode als auch von den Bewertungskriterien ab. Das so entwickelte Einflussdiagramm zur Entscheidungshilfe bezüglich Methodenunterstützung in der Produktentwicklung [3.45] wurde mit Hilfe einer geeigneten Software implementiert. Mit dieser Software lassen sich Bayes’sche Netze und Einflussdiagramme abbilden sowie die zugehörigen Inferenzmechanismen benutzen. Für die Methodenauswahl wurden sechs Bewertungskriterien betrachtet, mit deren Hilfe sich die Eignung jeder Methode unter Berücksichtigung der prototypenspezifischen Randbedingungen beurteilen lässt. Entscheidendes Kriterium für die Bewertung der alternativen Methoden ist, dass diese zielführend sind. Als Nächstes müssen die Akzeptanz und das Aufwand-Nutzen-Verhältnis betrachtet werden. Ohne Akzeptanz bei den Mitarbeitern wird jede Methodenanwendung nur bedingt erfolgreich sein. Auf das Aufwand-Nutzen-Verhältnis muss ebenfalls besonderes Augenmerk gelegt werden. Die drei übrigen Kriterien Flexibilität, Integrierbarkeit und Universalität spielen eine ergänzende Rolle, um die Bewertung noch weiter zu optimieren. Ein Beispiel für eine kontextsensitive Auswahl ist die Entscheidung über den zu verwendenden Werkstoff beim Stereolithograhieprozess für einen Prototyp, der – je nach dem, welche Merkmale an ihm verifiziert werden sollen – bestimmte, geforderte Eigenschaften aufweisen soll. Wichtig für die Auswahl ist immer der Kontext, das heißt, es müssen einerseits generell relevante Randbedingungen wie Produktkomplexität, Kostenrestriktionen, Zeitrestriktionen usw. sowie andererseits situationsspezifische Randbedingungen wie mechanische Eigenschaften, thermische Eigenschaften, elektrische Eigenschaften und optische Eigenschaften des ausgehärteten Harzes des Prototypen spezifiziert werden. Ein Ausschnitt des


171

entwickelten Einflussdiagramms für die kontextsensitive Methodenauswahl ist in Abb. 3.30 dargestellt.

Abb. 3.30. Das für die Methodenauswahl entwickelte Einflussdiagramm

Die Quantifizierung des Modells, d. h., die Spezifikation der für das Entscheidungsmodell notwendigen Wahrscheinlichkeitswerte wurde einerseits mit Hilfe des vorhandenen a-priori-Wissens wie z. B. funktionale Zusammenhänge zwischen den Knoten und andererseits durch Erfahrungswissen von Experten aus den jeweiligen Problembereichen bewerkstelligt. Der Einsatz Bayes’scher Netze zur Methodenauswahl hat gegenüber bekannten Ansätzen deutliche Vorteile. Er erlaubt es, die komplexen Interdependenzen aller bei der Entscheidungsfindung relevanten Größen geeignet als Einflussdiagramm zu modellieren und die Kausalzusammenhänge im Diagramm wie oben erläutert zu quantifizieren. Ferner ist die Lernfähigkeit der Wahrscheinlichkeitstabellen (Parameter Learning) [3.33], [3.54] durch bereits aufgetretene Entscheidungssituationen von erheblicher Bedeutung. Aufgrund dieser Lernalgorithmen ist es gewährleistet, dass sich das Modell einerseits im Laufe des Einsatzes immer mehr an die reale Welt anpasst und andererseits in der Lage ist, sich an sich verändernde Gegebenheiten im Problembereich dynamisch zu adaptieren. Die Metho-

172


dik wurde auch als Grundlage für das Entscheidungs-Modul in der Qualitätsmanagement-Toolbox verwendet (siehe Kapitel 3.2.4). 3.2.3 Verfahren und Methoden der Prozessüberwachung Vor dem Hintergrund der wachsenden Informationsflut erweist sich die Möglichkeit der Integration, Aufbereitung und Verdichtung von heterogenen Datenbeständen in der schnellen Produktentwicklung als ein wesentlicher Wettbewerbsfaktor. Zur frühzeitigen Simulation qualitätsrelevanter Größen muss ein geeignetes Modell entwickelt werden, mit dessen Hilfe Zusammenhänge und Interdependenzen zwischen Prozessparametern, Funktions- und Produktmerkmalen abgebildet werden. Prozessfähigkeit von Prototypenherstellprozessen Die klassischen Methoden [3.2], [3.1] zur Beurteilung der Prozessfähigkeit kann bei der Fertigung von Einzelteilen oder geringen Stückzahlen, wie sie bei Prototypenherstellprozessen die Regel sind, nicht mehr angewandt werden. Des weiteren spiegelt das zugrunde liegende Prozessmodell vor allem komplexere Prozesse nicht adäquat wider, da bei den klassischen Methoden lediglich ein Qualitätsmerkmal betrachtet wird. Kenngrößen, die die Fähigkeit von Prototypenherstellverfahren unter fertigungstypischen Bedingungen widerspiegeln, können mit diesen Methoden nicht ermittelt werden. Da die klassischen Ansätze der Prozessbeurteilung [3.81], [3.65] auf die Prozessfähigkeitsanalyse von Prototypenherstellverfahren nicht übertragbar sind, müssen alternative stochastische Modelle herangezogen werden, um einen Beitrag zur Ermittlung von Kennwerten für die Güte der Prototypenprozesse zu leisten. Hierzu eignet sich eine Vorgehensweise, die aufgrund der Prüfergebnisse ähnlicher Merkmale Kennwerte ermittelt, die Vorhersagen auf die zu erwartende Qualität des Prozesses zulassen. Dafür muss eine Ähnlichkeitsrelation eingeführt werden, um Merkmale geeignet zu gruppieren bzw. zu klassifizieren. Des weiteren musste eine Methodik angewandt werden, bei gegebenen Forderungen an den zu fertigenden Prototypen, die zur Kennwertermittlung notwendigen Merkmale und Prüfergebnisse aus einer Datenbank von bereits durchgeführten Prototypenprüfungen zu selektieren. Um die oben ausgeführten Ziele zu erreichen, müssen zunächst die bei dem betrachteten Prototypenherstellprozess qualitätsrelevanten Einflüsse ermittelt werden. Beispielhaft wurde hierzu ein Stereolithografieprozess mit anschließendem metallischen Beschichten ausgewählt, wobei insbe-


173

sondere Geometriemerkmale betrachtet werden. Folgende Parameter ergeben sich hierbei als relevant: x Werkstoff – der Materialschwund gilt im Allgemeinen als Hauptursache für den Bauteilverzug x Bauteilgröße – die Maßabweichung steigt mit zunehmender Bauteilgröße an x Hatchabstand – der Hatchabstand beeinflusst die Bauteilschrumpfung x Resolution – je höher die Resolution, desto geringer ist die Verzerrung und die dadurch entstehende Ungenauigkeit x Schichtdicke – die Schichtdicke beeinflusst die Genauigkeit in Richtung der z-Achse erheblich Um Kennzahlen zur Messung der Fähigkeit des Stereolithografieprozesses bezüglich der Geometrie heranziehen zu können, muss zunächst eine Methode der Klassifizierung eingeführt werden. Für eindimensionale Maße können die Längen- bzw. Breitenmaße gleichzeitig betrachtet werden. Die Höhenmaße müssen jedoch aufgrund der Eigenschaften des Herstellprozesses getrennt betrachtet werden. Für lineare Maße wird folgende Ähnlichkeitsrelation eingeführt: Falls die einzelnen Merkmale sich gar nicht oder nur geringfügig in ihrer normierten Toleranz unterscheiden, werden sie als ähnlich betrachtet und somit einer bestimmten Merkmalsklasse zugeordnet Normierte Toleranz :

Toleranz Sollwert

(1)

vorliegen, die einer bestimmten Merkmalsklasse entstammen, werden die folgenden beiden Kennwerte gebildet:

AD :

| xi xisoll | ti 1

(2)

| xi xisoll | 1 ,... ,n ti

(3)

1 n

n

¦ i

AM : max i

Beim ersten Kennwert (2) wird über die Abweichungen der Merkmale von ihrem Sollwert durch die jeweilige Toleranz gemittelt, was ein Maß für die Streuung der Messwerte darstellt. Beim zweiten Kennwert (3) wird das Maximum dieser Abweichungen betrachtet. Er sagt etwas darüber aus, ob alle Werte innerhalb der geforderten Toleranz liegen. Aufgrund dieser bei-

174


den Kennwerte wird dann entschieden, wie geeignet der Prozess für den zu fertigenden Prototyp zu sein scheint.

Abb. 3.31. Vorgehensweise zur Prognose der zu erwartenden Prozessfähigkeit

Die Vorgehensweise bei dieser Art der Prozessbeurteilung läuft folgendermaßen ab: zunächst werden die Forderungen an den zu fertigenden Prototyp wie Merkmalsart, Sollwerte, Toleranzen, verwendete Werkstoffe, Größe des Bauteils oder Ähnliche definiert. Das Fähigkeitsmodul sucht nun davon ausgehend diejenigen Prüfergebnisse zur Kennzahlermittlung aus, die an möglichst ähnlichen Merkmalen durchgeführt worden sind (Abb. 3.31.). Dabei muss je nach Anwendungsfall auf ein einziges oder aber auf mehrere Teile in der Teiledatenbank zurückgegriffen werden. Das Fähigkeitsmodul entscheidet aufgrund der Merkmalsart, welche Kennwerte zur Vorhersage der Prozessqualität herangezogen werden. Die entsprechenden Kennwerte werden anschließend ermittelt und anhand gegebener Regeln in eine Prozessfähigkeitsvorhersage bezüglich der oben definierten Forderungen transformiert. Simulation von Prototypenherstellprozessen Kerngedanke der Simulation ist die Möglichkeit der qualitativen Bewertung eines RP-Prozesses und des damit hergestellten Prototypen. Dabei wird die Qualität des Prototypen immer als Grad der Erfüllung der spezifizierten Anforderungen verstanden. Die korrekte Übersetzung der Kun-


175

denwünsche in technische Anforderungen an ein Produkt und an die Muster innerhalb des Entwicklungsprozesses entscheidet über die Produktqualität. Nicht nur die richtige Auswahl des RP-Verfahrens, sondern auch die Wahl geeigneter Werkstoffe sowie Einstell- und Umgebungsparameter sind für den zu erstellenden Prototypen wichtig. Dadurch werden verschiedene Eigenschaften des zukünftigen Produktes festgelegt. Diese Entscheidungen werden heutzutage vom Menschen in der Regel vom Entwickler (nach Absprache mit dem Konstrukteur) getroffen. Meist werden mehrere Herstellungszyklen verschiedener RP-Verfahren benötigt, damit das RP-Produkt schließlich die entsprechenden funktionalen und qualitativen Anforderungen des Endproduktes schon als Prototyp erfüllt. Um den RP-Prozess zu verbessern und die Entwicklungsdauer zu verkürzen, wurde ein stochastisches Simulationsmodell aufgebaut. Abb. 3.32 (links) zeigt im Prinzip das heutige Vorgehen, während Abb. 3.32 (rechts) das Modell vorstellt, das den Menschen im Rapid Prototyping unterstützt. Der Entwickler wird somit im Iterationsprozess entlastet, behält aber alle direkten und indirekten Einflussmöglichkeiten auf das Prozessergebnis, zum Beispiel auf Änderungen der Produktanforderungen.

Abb. 3.32. Iterationsprozess im RP (links), sowie unterstützende Funktion des vorgestellten Modells (rechts)

176


Durch das Modell wird die Entwicklung der RP-Prototypen effizienter gestaltet, die Anzahl der Zyklen verringert und damit der gesamte Entwicklungsprozess beschleunigt. Dies bedeutet eine Verbesserung des RPProzesses. Dabei kann eine Aussage über die Qualität der RP-Prozesse, als auch Hinweise zu Verbesserungen gemacht werden. Das Modell kann auch bei unsicherem Wissen für Aussagen und Entscheidungen herangezogen werden. Weiterhin ist es in der Lage, sich neuen und unbekannten Parametern (Umgebung, Material, Produkt) anzupassen. Als Versuchsund Modellanlage diente das sogenannte „Multi Material Modelling“Verfahren (MMM). Das stochastische Simulationsmodell stellt ein nahezu wirklichkeitsgetreues Abbild des realen MMM-Prozesses dar. Mit Hilfe von Expertenwissen über funktionale Zusammenhänge, empirische Informationen, Daten aus der Vergangenheit sowie sonstiges Vorwissen wurde das strukturelle Modell um eine quantitative Komponente erweitert. Mit Hilfe des Gesamtmodells kann der betrachtete Prozess simuliert werden. Die vorgestellte Strategie gibt dem Entwickler ein Rüstzeug, das es ihm ermöglicht, in einem iterativen Prozess einerseits den RP-Prozess zu optimieren und andererseits das Modell sukzessive zu verbessern. Das Simulationsmodell hat somit zwei Haupteinsatzgebiete. Das Modell kann vom Hersteller einer RP-Anlage zu deren Optimierung verwendet werden und auf der anderen Seite vom Produktentwickler genutzt werden, um die Musterherstellung schneller zum gewünschten Ziel zu bringen. 3.2.4 Systemfeedback – Umfassendes Qualitätsmanagement mit material- und prozessimmanenten Informationen Die Arbeiten zum Qualitätsmanagement wurden eingebunden in ein Gesamtkonzept, durch dessen Einführung und Umsetzung Insellösungen und isolierte Methoden vermieden werden. Wesentliche Elemente dieses Gesamtkonzeptes sind flexible und bereichsübergreifende Strukturen, aufgabenübergreifend integrierte Informationsmodelle bzw. Sichtweisen sowie Unterstützung durch geeignete technologische Systeme und Infrastruktur. Qualitätsmanagement-Toolbox: Gesamtkonzept In Bezug auf das Gesamtkonzept wurde ein nachvollziehbarer diskursiver Entscheidungsablauf erarbeitet, um intuitive Entscheidungen zu reduzieren und bereits vorhandenes Expertenwissen zu integrieren. Hierzu wurden die folgenden Module erarbeitet:


177

x Produktmerkmale und Prototypenklassen, x Prozesse und Prozessketten der Prototypenherstellung, x Prüfplanung, Prototypenprüfung und Review sowie ein Modul zur Entscheidungsunterstützung bei der Auswahl von geeigneten Prototypen bzw. Prototypenherstellverfahren. Zur Entscheidungsfindung wurden hier einerseits Informationen aus den technischen Bereichen und andererseits aus den Bereichen Konstruktion (Merkmale), Kosten und Zeit einbezogen (Abb. 3.33.).

Abb. 3.33. Gesamtkonzept der Qualitäts-Toolbox mit den einzelnen Modulen

Die gemeinsame Betrachtung von Zeit, Kosten und Qualität bei der Prototypenherstellung ist nicht nur ein Aspekt der Prototypenplanung, aber des ganzen Produktentwicklungsprozesses. Aus diesem Grund müssen auch hier die entwickelten Methoden und Verfahren funktional wie auch informationstechnisch integriert werden. Das zugrunde liegende Modell ermöglicht die flexible Reaktion auf veränderte Rahmenbedingungen und wird im Rahmen der Projektauswahl (präventiv) und der Projektsteuerung (präventiv und im regelnden Sinne) eingesetzt. Hierbei werden innerhalb der RPD-Iterationszyklen die Qualitäts-, Kosten- und Zeitkennzahlen zu Steuerungs- oder Regelungsinformationen verdichtet und den unterschiedlichen Produktentwicklungsphasen in der Toolbox zur Verfügung gestellt. Das Modell besitzt schon anfangs eine eindeutige Produktklassenzuordnung, es existieren einzelne Stufen bzw. Module, die einen unterschiedlichen Detaillierungsgrad haben können und der Ablauf ist gut visualisierbar und somit gut nachvollziehbar. Es ermöglicht außerdem eine ausführliche

178


Definition der Kundeninformationen und ist für unterschiedliche Ausgangssituationen nutzbar, wobei es optimal für die Situation der vorhandenen 3D-Daten geeignet ist. Es ist für den Umgang mit unsicherem bzw. ungenauem Wissen bei Verwendung einer entsprechenden Methode anwendbar. Ein weiterer wichtiger Pluspunkt liegt darin, dass die Kosten vor Entscheidung mit in die Betrachtungen einfließen und auch danach, wenn mehr Informationen vorliegen, ausführlich geprüft werden können. Modul: Produktmerkmale und Prototypenklassen In diesem Modul wird die Zuordnung anhand eines Ebenenmodells entwickelt. Nach dem Sammeln der benötigten Informationen und Produktmerkmale wird das Bauteil in der ersten Entscheidungsebene einer Produktklasse zugeordnet. Hierzu werden sogenannte Klassierungskriterien verwendet. Es wurden fünf Produktklassen erarbeitet: Konzeptmodell, Geometriemodell und Funktionsmodell sowie geometrisches Produkt und (funktionelles) Produkt für Rapid Manufacturing Anwendungen (direkte Herstellung von Produkten auf Basis der Schichtbauverfahren). Nach der Produktklassenzuordnung wird für die entsprechende Produktklasse eine präzisere Abfrage zu den Produktmerkmalen durchgeführt. Hierbei kann der Anwender zu folgenden Punkten Angaben machen: den mechanischen Einflüssen, den geometrischen Eigenschaften, den Materialeigenschaften, zu der Umgebungsanbindung, der Qualität und der Wirtschaftlichkeit. Bei jedem dieser Punkte kann gewählt werden, ob detaillierte Angaben dazu gemacht werden wollen, wodurch man zu weiteren Abfragen gelangt, oder ob man eine pauschale Bewertung abgeben möchte. Bei der pauschalen Bewertung hat der Anwender die Wahl zwischen unwichtig bzw. keine Angaben, wichtig und sehr wichtig. Allerdings ist zu erwarten, dass bei vielen pauschalen Angaben die Genauigkeit der daraus abgeleiteten Entscheidung sinkt und diese nur bis zu einem gewissen Grad die richtige Entscheidung repräsentiert. Deshalb muss die Möglichkeit der Kennzeichnung dieser Ungenauigkeit mit der auf dieses Entscheidungsmodell angewandten Methode gegeben sein. Durch Wählen der Möglichkeit detaillierter Angaben zu dem jeweiligen Themenfeld zu machen, gelangt man jeweils zu einer Auflistung von Kriterien, zu denen quantitative und qualitative Angaben gemacht werden können. Falls keine genauen Werte vorliegen, können Wertigkeiten angegeben werden. Interessant wäre auch eine Implementierung der Möglichkeit Wertebereiche einzugeben. Die Daten, die durch diesen Vorgang erarbeitet wurden, werden in einem Wissenspool gespeichert. In diesem Pool ist außerdem das gelernte Wissen des Systems aus vorigen Anwendungs-


179

fällen abgespeichert, wobei hierzu eine Bewertung der getroffenen Entscheidung notwendig ist. Zudem dient dem Wissenspool ein Startwissen als Basis, das über den Systemadministrator eingelernt wird. Das so gesammelte Wissen muss nun noch richtig kombiniert und analysiert werden, um das richtige generative Fertigungsverfahren auszuwählen. Diese Aufgabe übernimmt eine Entscheidungsmethodik, die auf Grund der erarbeiteten Wissensbasis ein solches Verfahren auswählt. Dieses Modul wird, wie oben bereits erwähnt, Inferenzkomponente genannt. Abschließend lässt sich noch nach der Entscheidung eine präzisere Kostenrechnung durchführen, falls inzwischen genauere Daten zur Verfügung stehen. Modul: Prozesse und Prozessketten der Prototypenherstellung Durch zahlreiche Neu- und Weiterentwicklungen im Bereich der generativen Fertigungsverfahren sowie durch die verschiedenen Kombinationsmöglichkeiten mit Folgetechnologien und einer immer größer werdenden Materialvielfalt ist die Gesamtheit der Herstellmöglichkeiten von Prototypen nur noch schwer überschaubar. Bei der Auswahl eines Verfahrens zur Prototypenfertigung kommen daher meist nur die technologischen Möglichkeiten der Prozesse, der einsetzbare Werkstoff sowie der Einsatzzweck des Prototypen als Auswahlkriterien zum Tragen. Für die Fertigung komplexer und eventuell mehrteiliger Prototypen bedarf es jedoch auch einer Fertigungsterminierung sowie einer Verträglichkeitsprüfung von Werkstoffen und Fertigungsverfahren hinsichtlich der Prototypmontage. Methoden und Instrumentarien zur ablauf- und prozesstechnischen Planung einer qualitativ, zeitlich und wirtschaftlich optimalen Fertigungsfolge. Hier sind auch Folgen von mehreren Einzelprototypen unter Beachtung der Potenziale sowohl generativer als auch klassischer Fertigungsverfahren zu beachten und im Bezug auf die Dienstleisterintegration zu definieren. Diese Sammlung ist trotz der Vielzahl von Kriterien jederzeit erweiterbar und keinesfalls als absolut vollständig anzusehen. Es sollte sogar, um dem Wandel, der aus den Entwicklungen im Verfahrensbereich herrührt, der hergestellten Maschinen gerecht zu werden, in regelmäßigen Abständen eine grundlegende Überprüfung der Vollständigkeit der Sammlung stattfinden. Darüber hinaus besteht dieses Modul aus einer Abfrage über Produktmerkmale, welche eine eindeutige Zuordnung zu einer der oben genannten Produktklassen zulässt. Anschließend werden für die entsprechende Produktklasse weitere Abfragen vorgenommen, die der Präzisierung der Produktbeschreibung dient. Diese Abfragen enthalten sowohl die Möglichkeit

180


genaue als auch ungenaue Angaben zu machen. Anschließend werden diese Informationen einem Wissenspool zugeführt, welcher schon anderes Wissen enthält. Dies kann Wissen von Experten oder aber auch, falls möglich, Wissen des Systems beinhalten (gelerntes Wissen). Abschließend entscheidet eine Interferenzkomponente, welches Verfahren als bestes vorgeschlagen wird. Diese Interferenzkomponente stellt eine Entscheidungsmethodik, die auf Grund der Ausprägungen in den Informationen ein Verfahren vorschlägt, dar. Anschließen lässt sich eventuell noch eine genauere, aufwendigere Kostenrechnung als zuvor.

Abb. 3.34. Modul für die Prozesse und Prozessketten


181

Modul: Prüfplanung, Prototypenprüfung und Reviews Die Prototypenprüfung unterliegt zahlreichen Einflussfaktoren. Nur durch die Gestaltung, Planung und Beherrschung dieser Faktoren sind die notwendigen Informationen extrahierbar und weiterverwendbar. Weil nach verwendetem Verfahren und Prozessparametern so Bauteile mit möglicherweise unterschiedlichen Eigenschaften entstehen, ist der Abgleich mit den jeweils spezifischen Anforderungen bei der Beurteilung der Qualität der Prototypen besonders zu beachten. Bei der Formulierung der Anforderungen an den Prototypen ist daher auch auf deren Auswirkungen auf die Art und den Umfang der damit notwendigen Prüfungen zu achten. Die Qualität eines Bauteils und somit auch die eines Prototypen orientiert sich an der Eignung für den bestimmten Einsatzfall und damit an der Erfüllung der jeweils spezifischen Anforderungen. Da mit einem Prototypen in der Regel nur eine begrenzte Anzahl an Merkmalen evaluiert werden sollen, sind diese bei der Auslegung und der Bestellung exakt zu definieren. Eine unklare Definition oder Absprache kann zu erheblichem Mehraufwand (Kosten, Lieferzeit) und/oder zu mangelhafter Qualität führen. Die Ausprägung der Anforderungen hängt vom Anwendungsfall, der Art der zu überprüfenden Merkmale und den verwendeten Materialien ab. Die Anforderungen können auch innerhalb eines Bauteils variieren (z. B. kritische Maße). Einige wesentliche Eigenschaften hängen dabei von der Wahl des Werkstoffes und der verwendeten Technologie ab. Es sind die jeweils gültigen Prüfvorschriften zu vereinbaren und anzuwenden. Durch den Einsatz des entwickelten Moduls bei der Qualitätsprüfung von Prototypen wird eine starke Verzahnung zwischen den Aufgaben der Qualitätsprüfung von Prototypen und der Produktentwicklung ermöglicht. Übergeordnete Ziele hierbei sind Wirtschaftlichkeits- und Effizienzsteigerungen in der Qualitätsbeurteilung (Abb. 3.35.). Die Aufgabe des Review besteht wiederum in der Aktualisierung von Prüfprozessen, Prüfplänen, Prüfverfahren, Prüfmethoden und Prüfmerkmalen entsprechend dem Produktentwicklungsfortschritt seit dem Anstoß der Qualitätsprüfungen. Handlungsbedarf für das Review besteht immer dann, wenn im fortschreitenden Produktentwicklungsprozess entweder Änderungen von für die Aussagekraft der Prototypenprüfung relevanten Produktmerkmalen erfolgten oder kein Erkenntnisgewinn für den Produktentwicklungsprozess mehr ableitbar ist. In beiden Fällen müssen Maßnahmen zur Neu- oder Änderungsplanung der Prototypen-Prüfung ergriffen werden. Die Entscheidungen müssen hierbei bis in die Prototypenfertigung und Fertigungsplanung propagiert werden. So kann im Extremfall sogar die Prototypenfertigung abgebrochen werden.

182


Im Rahmen des Review steht dieses Wissen in Form des Prüfindex zur Verfügung. Dieser stellt die zeitlichen und logischen Abhängigkeiten dieser Merkmale sowie die Verknüpfung der Entwicklungsergebnisse (Produkt/Prototypenmerkmale) mit den Prüfmerkmalen her. Dieses Wissen wird z. B. bei der Neu- und Änderungsplanung der Prototypenprüfungen sowie bei Entscheidungen der Prototypen-Fertigungsplanung genutzt.

Abb. 3.35. Einbindung des Review in die Prototypenprüfung

Das Zielsystem wurde aus zwei wesentlichen Komponenten aufgebaut: Abfolgesteuerung und Terminierung sowie Wissens- und Know-howBildung (z. B. Prüfindex). Als Basis für die Generierung von Steuerungsinformationen durch das Review wird die Analyse des Erkenntnispotenzials eines Prototypen genutzt. Da das Erkenntnispotenzial von Prototypen situationsabhängig ist, setzt das Review ereignisgesteuerte Beurteilungsaktivitäten voraus. Zeitgesteuerte Bewertungen, z. B. im Rahmen von periodischem Prototyping, können diese ergänzen, jedoch können sie Monitoring-Funktionen bei der Ereignisüberwachung keineswegs ersetzen. Das Ziel des Prototypenaudits ist es, Erfahrungswissen über die Anwendung und Umsetzung verschiedener Qualitätsmanagementmaßnahmen in der Praxis nutzbar zu machen und das aus diesen Maßnahmen hervorge-


183

gangene Wissen zu systematisieren und zur Vorbeugung nutzbar zu machen. Da neben der Generierung neuen Wissens auch die Bewährung dieses Wissens in der Praxis erforderlich ist, beinhaltet das Prototypenaudit – neben der Ermittlung und Anregung von Verbesserungen und der Fehlerbehebung – auch die Überwachung der Wirksamkeit eingeleiteter Maßnahmen. Das Prototypenaudit wird durch die übergreifende Betrachtung von Qualitäts-, Zeit- und Kostenaspekten zum Management-Instrument für die Qualitätsförderung in Produktentwicklungsprojekten und der Produktentwicklung im Allgemeinen. Entscheidungsmodul Durch Verwendung des erarbeiteten Entscheidungsablaufes ist es möglich, ungenau beschriebenes Wissen bzw. Informationen zu nutzen und damit mit vorhandenen oder eventuell entstehenden Unsicherheiten zu einem Ergebnis zu kommen. Hierzu war es allerdings notwendig, die richtige Entscheidungsmethode als Inferenzkomponente einzusetzen. Diese musste fähig sein, mit diesen Unsicherheiten auf logische Weise eine Entscheidung zu treffen oder dem Benutzer vorzuschlagen. Durch die generischen Konstrukte zur Beschreibung der methoden- und bereichsübergreifenden Informationen sowie funktionaler und anderer relevanter Zusammenhänge ist es möglich, gleiche Modellierungsansätze für ähnliche Strukturen und Elemente zu nutzen. Das durch die generischen Konstrukte gebildete Metamodell bildet somit den Integrationskern für weitere Anwendungen. Zur Überprüfung des Entscheidungsmodells wurden die Mittelkonsolenkomponenten konstruiert. Anschließend wurden die Ergebnisse dieser Überprüfungen dokumentiert. 3.3.5 Zusammenfassung Die Methoden des Rapid Product Development dienen zur zielgerichteten frühzeitigen und effektiven Umsetzung von Prozessen und Vorgehensweisen, um mit Prototypen eine möglichst genaue Aussage über die späteren Serienbauteile machen zu können. Die Prototypen müssen dazu nicht nur die technologischen Eigenschaften der Serienbauteile enthalten, sondern auch Informationen über wirtschaftliche Randbedingungen liefern. Hierzu wurde einerseits ein dezentral vernetztes Rapid Prototyping Labor aufgebaut, das die verschiedenen Technologien zur Erstellung physischer Prototypen im Prozessmodell integriert, das anderseits Methoden in einer Toolbox erfasst, die Interaktionen zwischen den einzelnen Technolo-

184


gien und Prozessen unterstützt. Aus dem Prozessmodell ergaben sich die variablen und die nicht variablen Schnittstellen für den Ansatz des evolutionär iterativen Vorgehens im Rahmen des RPD. Die Informationsflüsse trugen deutlich dazu bei, die verschiedene Produktdaten speziell mit den Themenbereichen „Grundlagen der Organisation und Planung“ (Kap. 2) und „Erstellung virtueller und physischer Prototypen“ (Kap. 5) zu verbinden. Die in der bisherigen Forschung gemachten Untersuchungen haben gezeigt, dass die Kopplung von virtuellen und physischen Prototypen, in Kombination oder als jeweils eigenständige Evaluierungsmöglichkeit, ein hohes Potenzial in Bezug auf die Validierung des Produktentwicklungsprozesses bieten.

3.4 Kostenmanagement im Prozess des Rapid Prototyping

3.4.1 Überblick über das Forschungsprojekt Die Kostenposition von Unternehmen ist für deren Wettbewerbsfähigkeit von entscheidender Bedeutung. Die in einem Unternehmen anfallenden Kosten werden dabei zu großen Teilen bereits in der Entwicklung des physischen Produktes und der begleitenden Dienstleistungen (Leistungsbündel) determiniert. Um für ein Leistungsbündel die Kosten, die während des gesamten Lebenszyklus entstehen zielorientiert planen, steuern und kontrollieren zu können, ist es notwendig, die wesentlichen Entscheidungsträger in den Unternehmen bereits frühzeitig mit relevanten Informationen zu versorgen. Die Arbeit mit den Praxispartnern des Sonderforschungsbereiches (insb. mit der DaimlerChrysler AG) aber auch empirische Studien bestätigen die Bedeutung eines entwicklungsbegleitenden Kostenmanagements für den langfristigen Unternehmenserfolg. Vor Beginn der letzten Antragssituation existierten noch keine überzeugenden Konzepte, die auf eine Integration der prototypgestützten Kostengestaltung von Leistungsbündeln aus physischem Produkt und Dienstleistung sowie der lebenszyklusoptimierten Kostengestaltung von Rapid Product DevelopmentNetzwerken ausgerichtet waren. Das Ziel dieser Arbeiten besteht in der Entwicklung von Konzepten, wie im Rahmen des Rapid Product Development (RPD) prototypgestützte Produktvorgaben und -prognosen für Leistungsbündel aus physischem Produkt und Dienstleistungen sowie unter Betrachtung von Entwicklungs-


185

netzwerken lebenszyklusorientiert geplant, gesteuert und kontrolliert werden können. Ziel der Forschungsaktivitäten ist es, eine Basis für die kostenorientierte, lebenszyklusoptimierte Steuerung der Produktentwicklung zu legen. Das Rapid Product Development ist dabei ein wesentliches Instrument zur Erhöhung der Effizienz und Effektivität im Rahmen der Neuproduktentwicklung. Prototypen haben sich bisher als sehr gutes Instrument zur lebenszyklusorientierten Kostenprognose gezeigt. Unter einem solchen Prototypen kann dabei eine jede Vorabversion des späteren Leistungsbündels (bestehend aus physischem Produkt und Dienstleistung) angesehen werden, die wenigstens einige Eigenschaften dieses Leistungsbündels aufweist. Die bisherigen Forschungsergebnisse konnten belegen, dass physische und virtuelle Prototypen geeignet sind, die Defizite bei der Generierung und Verarbeitung kostenrelevanter Informationen zu reduzieren. 3.4.2 Ergebnisse und ihre Bedeutung Ziele Ein wesentliches Ziel der Arbeiten war die Übertragung der Forschungsergebnisse auf kleine und mittelständische Unternehmen im Maschinenbau, die stark in F&E investieren. Als innovativer Partner des Transferbereiches konnte die TOOLING1 GmbH & Co. gewonnen werden. Ein bedeutendes Resultat des Transferprojektes wurde mit der Optimierung des Entwicklungsprozesses angestrebt. Zur Erreichung dieses Ergebnisses wurden einige Teilziele verfolgt. So wurde ein Prozesskostenmodell für ein Entwicklungsnetzwerk konzipiert und dann in einem Excel-Tool umgesetzt. Aus dem konkreten Einsatz dieses Instrumentes bei der Firma TOOLING wurden anschließend Verbesserungsmaßnahmen abgeleitet. Methoden und Arbeitsprogramm Methodisch wurden im Rahmen des Transferbereiches bei der Firma TOOLING GmbH & Co. die im Rahmen des Teilprojektes T1 des Tfb 41 entwickelten Methoden, Modelle und Vorgehensweisen realisiert. Daher sollte eine dynamische, lebenszyklusorientierte Kostenbetrachtung für Leistungsbündel erfolgen, bei der auch Lern- und Erfahrungskurveneffekte in die Betrachtung integriert werden. Weiterhin wurde der Fokus nicht nur auf ein Unternehmen gelegt, sondern eine Integration von Netzwerk1

Zur Wahrung der Vertraulichkeit wurde der Name des Praxispartners adaptiert.

186


partnern der Firma TOOLING durchgeführt. Auf die generellen Phasen zur Praxisimplementierung wird im Folgenden näher eingegangen: Phase 1: & Co.

Analyse der Ist-Situation bei der TOOLING GmbH

(1) Prozessorientierte Analyse des Entwicklungsnetzwerkes Innerhalb der vernetzten Produktentwicklung existieren bei der TOOLING GmbH & Co. eine enorme Bandbreite unterschiedlicher Prozesse. Aufgrund der Vielfalt und Verschiedenartigkeit von Entwicklungsprozessen wird deren Charakterisierung und Typologisierung notwendig. Eine Charakterisierung kann anhand der vier Merkmale Neuigkeit, Komplexität, Variabilität und Strukturiertheit der Entwicklungsprozesse durchgeführt werden [3.63], [3.71]. Im Gegensatz zu den vorwiegend repetitiven Prozessen in der Produktion sind Entwicklungsvorhaben mit einem gewissen Neuigkeitsgrad verbunden und haben im Allgemeinen Projektcharakter [3.71]. Neuigkeit bedeutet dabei das Schaffen von etwas Neuem, das sich qualitativ von Existierendem unterscheidet [3.66]. Dabei drückt der Neuigkeitsgrad aus, inwiefern Abweichungen von geplanten Abläufen hinsichtlich ihrer Häufigkeit, Unvorhersehbarkeit und ihres Ausmaßes zu erwarten sind [3.63] und wird von einigen Autoren als eingenständiges Merkmal herangezogen [3.68]. Die Unvorhersehbarkeit der Prozesse und die fehlende Erfahrung verbunden mit der Vielzahl der einzubeziehenden Bereiche und Unternehmen führen zu Komplexität. Allgemein kann Komplexität als eine Kombination aus der Anzahl der Aufgabenelemente und deren Verknüpfung untereinander definiert werden [3.63]. Unter Variabilität wird das Ausmaß von Prozessänderungen hinsichtlich Häufigkeit, Intensität, Irregularität und Geschwindigkeit verstanden [3.66]. Modifikationen im Entwicklungsprozess sind oft auf unrealistische Zielvorgaben, unzureichende Planung von Produktanforderungen, zu große Innovationsschritte oder auf unzuverlässige Netzwerkpartner zurückzuführen. Mit steigender Zahl der Änderungen erhöhen sich auch die Anforderungen des Entwicklungsvorhabens. Vor allem die Planung und Kontrolle der Entwicklungsbeteiligten wächst mit zunehmender Variabilität und Schnittstellenanzahl. Unter dem Strukturiertheitsgrad wird die sachliche und zeitliche Bestimmbarkeit des Entwicklungszieles (Produkt) und des Entwicklungsprozesses (Problemlösungsweg) verstanden [3.63]. Durch eine Strukturierung sollen komplexe Aufgaben überschaubar und handhabbar gemacht werden [3.11]. Je kleiner der Strukturiertheitsgrad ist, desto eher sind Prognose- und Abstimmungs-


187

schwierigkeiten zu erwarten. Dadurch wächst die Gefahr von unnötiger Doppelarbeit, Motivationsbarrieren und einer Unverwendbarkeit der Ergebnisse. (2) Identifikation und Charakterisierung der Leistungsbündel Ausgehend von den speziellen Gegebenheiten bei der TOOLING GmbH & Co. wurden in diesem Arbeitspaket Produkte und produktbegleitende Dienstleistungen identifiziert. Dabei boten sich diverse Möglichkeiten zur Festlegung von Leistungsbündeln. Kombinationen aus Produkt und produktbegleitender Dienstleistung ließen sich so bei Positions- und Sicherheitsschalter gleichermaßen feststellen. Die Identifikation der Leistungsbündel führte für die vorliegende Untersuchung, aufgrund der großen praktischen Bedeutung, zu einem Leistungsbündel von Zustimmungsschalter und Engineering-Dienstleistung („Web-to-CAD-Service“). Diese Engineeringdienstleistung wurde dabei ausgewählt, da bei dieser ein hohes Wachstumspotenzial existierte und bei der Erstellung zahlreiche Prototypen eingesetzt werden. Gleichzeitig bestand zu den begleitenden Zustimmungsschaltern eine sehr enge Beziehung und ein hoher Innovationsgrad. Die Auswahl basierte somit auf der spezifischen Charakterisierung der Kombination von begleitender Engineeringdienstleistung und dem Produkt des Zustimmungsschalter. Generell können die Leistungsbündel dabei nach den Merkmalen der Dienstleistung sowie den des Produktes bzw. Prototypen charakterisiert werden. Die Verbindung der Dienstleistung zum physischen Produkt ist das wesentliche, notwendige Merkmal der betrachteten, produktbegleitenden Services. Für die im Fokus stehenden Dienstleistungen muss sich eine materielle Beziehung zum Produkt bzw. dessen Produktmodell erstellen lassen. Die Ausprägung dieses Merkmals befindet sich dabei auf einem Kontinuum von keiner bis zu einer sehr hohen, direkten Verbindung vom Produkt bzw. Produktmodell zur begleitenden Dienstleistung. Im Rahmen des Forschungsprojektes erfolgte eine weitere Spezialisierung nach dem Innovationsgrad der einbezogenen produktbegleitenden Dienstleistung. Aus einer logischen Schlussfolgerung resultierend, wurden nur Services betrachtet, deren begleitende Produkte einer Entwicklung unterliegen. Falls dies nicht der Fall ist, kann zur Kosten- und Erlösplanung der Dienstleistung ein bereits existierendes Produkt verwendet werden und die Notwendigkeit des Einsatzes von Prototypen würde nicht bestehen. Diese Argumentation verdeutlicht auch, dass mit steigendem Innovationsgrad des Produktes der Einsatz von Prototypen tendenziell vorteilhafter erscheint. Neben dieser logischen Argumentation erscheint eine prototypgestützte Betrachtung ebenfalls vorteilhaft, weil bei

188


diesen eine Kombination mit dem Service Engineering gut erfolgen kann [3.67]. Neben den bisher aufgezeigten Gestaltungsformen war weiterhin im Rahmen der Betrachtung des Unternehmens mit Blickrichtung auf den Adressat des Services zu klären, ob sowohl unternehmensinterne als auch externe produktbegleitende Dienstleistungen für die Betrachtung geeignet waren [3.15]. Die Engineeringdienstleistung wurde ausgewählt, da sie für beide Adressatengruppen geeignet erschien. Durch die Integration des externen Faktors wiesen Leistungsbündel häufig einen hohen Individualisierungsgrad auf. Im Vergleich zu physischen Produkten existierte weiterhin oft eine geringere Standardisierung bei produktbegleitenden Dienstleistungen, die mit einer Erschwerung der Planung einhergeht [3.58]. So ist exemplarisch eine Identifikation von standardisierten Prozessen schwerer möglich, was wiederum Auswirkungen auf eine prototypgestützte, prozessorientierte Kosten- und Erlösplanung von produktbegleitenden Dienstleistungen hat [3.75]. Für die praktische Realisierung der Kosten- und Erlösplanung hat sich weiterhin eine Differenzierung der produktbegleitenden Dienstleistung hinsichtlich ihrer Stellung im Produktlebenszyklus als Einflussfaktor gezeigt. Je nachdem, ob die betrachtete Dienstleistung stärker auf die Entwicklungs-, Produktions- oder Nachsorgephase zielt, resultieren Auswirkungen auf die Möglichkeit zur Nutzung des Prototypen. Zur weiteren Charakterisierung der Leistungsbündel erfolgte weiterhin eine Typologisierung nach Eigenschaften des Produktes bzw. des Prototypen nach Funktion, Substanz, Konkretisierung und Erstellung des Prototyps. Die Prototypfunktionen werden in den verschiedenen Wissenschaftszweigen unterschiedlich beschrieben. Die folgende Abb. 3.36 gibt einen Überblick über die Aufgaben. Neben diesen Sichtweisen existieren weitere Betrachtungen aus anderen Wissenschaftszweigen, die jedoch nicht im Fokus der Arbeit standen [3.49], [3.69]. Aus der Perspektive einer prototypgestützten Kosten- und Erlösplanung für produktbegleitende Dienstleistungen war weiterhin von wesentlicher Bedeutung, welche Substanz die Prototypen hatten. Generell konnten dabei virtuelle und physische bzw. materielle Komponenten identifiziert werden [3.9], [3.25], [3.31]. Aus diesen unterschiedlichen Substanzen resultierten wiederum virtuelle und physische Prototypen. Bei der Charakterisierung von Prototypen nach der Konkretisierung erfolgte eine Differenzierung nach dem wahrnehmbaren Stadium im Produktentwicklungszyklus. Dabei wird von zahlreichen Autoren in zeitlicher Reihenfolge in Design-, geometrischen, Funktions- und technischen Prototyp unterschieden [3.46], [3.39], [3.31], [3.18].


Psychologische Perspektive Hacker & Sachse

x

x

x

x

x

Analysehilfe Evaluationshilfe Lösungshilfe Speicherhilfe Kommunikationshilfe Dokumentations-hilfe

Herzog

x

Erkenntnistheoretische Funktion

x

Ingenieurwissenschaftliche Perspektive

x

x

Interpretation Repräsentation

x

x

x

Selektion x

x

x

Heuristische Funktion

x

VDI

Bullinger et al.

Problemdefiniton

Unterstützung bei der Erbarbeitung alternativer Konzepte

Lösungsfindung Lösungsbeschreibung Lösungsbeurteilung Lösungsauswahl

Betriebswirtschaftliche Perspektive Specht et al.

x

x

Unterstützung einer späten Entscheidung und Spezifikation des Produktes

189

x

Unterstützung bei der Planung und Steuerung Information und Kommunikation Einbindung von Anforderungen des Kunden und Lieferanten

Vorliegende Arbeit x

x

x

Analyse Gestaltung/ Entscheidung Dokumentation

Illustration

Abb. 3.36. Ausgewählte Differenzierungen der Funktionen von Prototypen

Diese Modelle werden zunehmend konkreter und repräsentieren immer mehr das angestrebte Endprodukt. Die Prototypen resultieren als Ergebnisse der Produktentwicklung in der Design-, Konzeptions-, Entwurfs- sowie Ausarbeitungsphase und liefern immer detailliertere Informationen, die für die Planung von produktbegleitenden Dienstleistungen verwendet werden können. Die genaue Bezeichnung der einzelnen Produktmodelle differiert dabei zwischen verschiedenen Unternehmen und Branchen [3.22]. Hinsichtlich der Charakterisierung von Leistungsbündeln nach der Erstellung des Prototyps wurde eine Differenzierung in konventionelle Verfahren und Methoden des Rapid Prototypings vorgenommen. Im Fokus standen dabei Leistungsbündel, die mit RP-Verfahren erstellt wurden. Auch dies war bei dem betrachteten Zustimmungsschalter gegeben. (3) Erarbeitung eines betriebswirtschaftlichen Prozessmodells für das Entwicklungsnetzwerk Aufbauend auf den im ersten Arbeitspaket beschriebenen Prozessmerkmalen, wurde ein Prozessmodell für das vorliegende Entwicklungs-

190


netzwerk erarbeitet. Bei der Entwicklung des Prozessmodells wurde darauf geachtet, die beteiligten Unternehmen zu integrieren. Dies wurde dadurch erreicht, dass die eigentliche Produktentwicklung bei TOOLING in sechs Prozessschritte unterteilt wurde. Innerhalb dieser einzelnen Schritte erfolgte die Definition verschiedener Teilprozesse, bei denen mit einem oder mehreren Netzwerkpartnern zusammengearbeitet werden musste. Bei der Erarbeitung eines betriebswirtschaftlichen Prozessmodells für das Entwicklungsnetzwerk wurde der Produktentwicklungsprozess aus dem Produktentstehungsprozess herausgegriffen [3.17]. Auf die Ideengenerierung innerhalb der operativen Produktplanung wird nicht näher eingegangen. Die Betrachtung der Produktplanung kann jedoch nicht vollständig unterbleiben, weil die Phasen der Anforderungsdefinition und Produktkonzeption eher planenden Charakter aufweisen. Aus diesem Grund existieren Überschneidungen zu den beiden Planungsphasen. Dasselbe gilt auch für den gesamten Prozess der Produktentwicklung, bei dem es vielfach zu Überlappungen, Rückkopplungsschleifen und Verzweigungen kommt [3.77]. Während die Phasen die abzuarbeitenden Arbeitspakete beschreiben, liegen an ihren Schnittstellen sogenannte Meilensteine beziehungsweise Design Reviews [3.12], [3.52]. Sie fungieren als Kontrollpunkte für die Einhaltung der Ziele von Entwicklungsprozessen. Aufbauend auf den ersten und dritten Arbeitspaketen wird im fünften Arbeitspaket auf die Erfassung und Klassifizierung von Interdependenzen in Netzwerken eingegangen. (4) Prototypgestützte, prozessorientierte Klassifikation der Leistungsbündel Auf der Basis der Identifikation und Charakterisierung der Leistungsbündel wurde in diesem Arbeitspaket eine durchgängige prozessorientierte Klassifikation der Leistungsbündel bei der Firma TOOLING angestrebt. Prototypen haben sich dabei in den bisherigen Forschungstätigkeiten als ein sehr gutes Instrument gezeigt, um wesentliche Informationen dokumentieren und kommentieren zu können [3.13]. Bei der angewendeten Konzeption erfolgte neben der Unterscheidung in lmi- und lmn-Prozesse in Anlehnung an Reckenfelderbäumer eine zusätzliche Untergliederung, mit der die Potenziale von Prototypen zur Planungsunterstützung detaillierter identifizierbar und beschreibbar waren. So wurden die in die Rechnung eingehenden Dienstleistungsteilprozesse nach ihrer Verbindung zum physischen Produkt in Prozesse ersten, zweiten und dritten Grades differenziert und damit die Möglichkeiten einer Prototypunterstützung aufgezeigt [3.64]. Prozesse ersten Grades wiesen dabei eine direkte Verbindung zum physischen Produkt auf. Eine Veränderung am


191

physischen Produkt hatte so unmittelbare Auswirkungen auf die Potenziale, den Prozess und das Ergebnis. Ein indirekter Bezug zum physischen Produkt bzw. zu Prototypen dieses Produktes ließ sich bei Prozessen zweiten Grades herstellen. Bei diesen Services resultierte nur eine mittelbare Reaktion auf die Veränderung des Prototyps. Prozesse dritten Grades umfassten schließlich Aktivitäten, die keine oder nur eine sehr lose Verbindung zum physischen Produkt haben (z. B. Geschäftsbereich leiten). Die Analogie dieser Unterscheidung zu lmi (für die Prozesse ersten und zweiten Grades) und lmn (dritten Grades) ist offensichtlich. Allerdings steht bei dieser Differenzierung nicht die Mengeninduktion, sondern allein die Verbindung zum physischen Produkt im Fokus. Durch den Prototypbezug der Teilprozesse konnte ebenfalls eine Beziehung zum physischen Produkt hergestellt werden. Als Ergebnis dieses Arbeitspaketes konnte damit eine prototypgestützte, geschlossene Systematik von physischem Produkt und begleitenden Dienstleistungen erreicht werden. Dieses beruhte dabei auf den Charakterisierungen, die bereits im Arbeitspaket 2 bestimmt werden konnte. (5) Erfassung und Bewertung der Interdependenzen Grundsätzlich führen Leistungs- und Ressourcenverflechtungen in Netzwerken zu Interdependenzen und Entscheidungsproblemen. Bei der Erarbeitung des oben beschriebenen Prozessmodells hat sich herauskristallisiert, dass die Erfassung und Klassifizierung von Inderdependenzen für die Entwicklung eines Kostengestaltungsmodells bei der TOOLING GmbH & Co. sehr bedeutend ist. Besonders die Betrachtung von Koordinationskosten spielt dabei eine wichtige Rolle, weil vielfach hohe wechselseitige Abhängigkeiten zwischen den Partnern existieren. Aus diesem Grund wird im Folgenden eine Fokussierung auf die Analyse von Koordinationsgestaltungsfeldern vorgenommen, die für eine spätere Abschätzung von Kosteneffekten in Netzwerken zwingend erforderlich ist.

x Organisatorische Koordinationsgestaltungsfelder der Aufbauorganisation. Im Rahmen der realisierten Ausprägung von Zentralisation bzw. Dezentralisation des Netzwerkes besteht ein wesentliches Gestaltungsfeld in der Abstimmung der dezentralen Einheiten im Hinblick auf das gemeinsame Entwicklungsziel des Netzwerkes. Dabei ist der erforderliche Koordinationsbedarf davon abhängig, ob ein pyramidales oder polyzentrisches Netzwerk vorliegt [3.79]. Handelt es sich um den ersten Typ, können eine Gestaltung der Kosten und die Bestimmung der Koordinationsinstrumente durch ein fokales Unternehmen erfolgen. Bei einem polyzentrischen Entwicklungsnetzwerk resultieren aus der starken

192


Dezentralisation ein großer Koordinationsbedarf und damit erhöhte Kosten [3.79]. Koordinationsgestaltungsfelder hinsichtlich der Funktionalisierung bestehen vor allem bei der Aufgaben- und Kompetenzzuordnung bei einer Projektorganisation. In diesem Kontext ist bis auf die operative Ebene festzulegen, welche organisatorische Zuweisung von Verantwortlichkeiten auf die einzelnen Partner erfolgt [3.44]. Dabei beinhaltet die Gestaltung der für das Netzwerk vorteilhaften Arbeitszerlegung weiteren Abstimmungsbedarf und damit höhere Kosten [3.35]. x Organisatorische Koordinationsgestaltungsfelder der Ablauforganisation. Hinsichtlich der Ablauforganisation besteht ein wesentlicher Koordinationsgestaltungsbedarf in der Aufspaltung des komplexen Gesamtentwicklungsprozesses in einzelne Teilprozesse, deren organisatorische Verankerung durch Teilprozessverantwortliche und in der Abstimmung der einzelnen Schritte [3.3]. Hinsichtlich des Transaktionsinhaltes lassen sich die Teilprozesse der Anbahnung einer Netzwerkkooperation, Vereinbarungen, Kontrolle des Zielerreichungsgrades bzw. der Entwicklungsziele und die Anpassung als Gestaltungsfelder identifizieren. Abstimmungsbedarfe bestehen in Bezug auf diese einzelnen Teilprozesse sowie deren Integration in dem gesamten Prozess. Die Intensität der Koordination ist dabei abhängig von der Integrationsintensität der betrachteten Gesamtprozesse [3.32], [3.78]. Je stärker die Einbindung der einzelnen Unternehmen ist, desto mehr Koordination ist erforderlich und desto höhere Kosten werden tendenziell anfallen. x Koordinationsgestaltungsfelder hinsichtlich materieller Ressourcen. Koordinationsgestaltungsfelder hinsichtlich der materiellen Ressourcen resultieren vor allem aus infrastrukturellen Interdependenzen. In Entwicklungsnetzwerken werden Abstimmungen insb. durch die angestrebte Nutzung von Erfahrungskurveneffekten bzw. Größendegressionseffekten sowie durch eine stärkere Fokussierung zur Realisierung von Economies of Scobe erforderlich [3.57]. Durch eine gemeinsame Beschaffung von materiellen Ressourcen, bspw. durch den Aufbau eines Rapid Prototyping Labors, können im Rahmen der Nutzung für die einzelnen Netzwerkpartner Kosten von Input-Faktoren reduziert werden [3.19]. Die vielfältigen Beziehungsmöglichkeiten und Verhandlungsparameter verursachen weitere Transaktionskosten, die in die Gesamtbetrachtung zu integrieren sind [3.62]. x Koordinationsgestaltungsfelder hinsichtlich immaterieller Ressourcen. Ein wesentlicher Abstimmungsbedarf in Bezug auf die immateriellen Ressourcen besteht in der Optimierung der Zusammenarbeit zwischen den einzelnen Netzwerkpartnern. Prototypen können dabei zu einer besseren Veranschaulichung der Entwicklungsergebnisse beitragen, als we-


193

sentliche Diskussionsgrundlage für die Weiterentwicklung dienen und Defizite beim Entwicklungs-Know-how aufzeigen. Das Koordinationsgestaltungsfeld des Lernens der Netzwerkpartner ist meistens durch eine hohe Komplexität geprägt. Aus diesem Grund ist eine Quantifizierung des interorganisationalen Lernens nur sehr schwer möglich. Im Rahmen der immateriellen Ressourcen ist für die Zusammenarbeit im Entwicklungsnetzwerk wichtig, wie eine kommunikative Abstimmung zwischen den einzelnen Unternehmen erfolgt. Durch den Einsatz von internetbasierten Informations- und Kommunikationssystemen wird häufig eine Reduktion des Abstimmungsaufwandes angestrebt [3.70]. Allerdings ist dadurch lediglich eine Verringerung und keine vollständige Vermeidung von Koordinationskosten möglich. Phase 2:

Konzeption des konkreten marktorientierten Kostengestaltungsmodells

(6) Prozessorientierte Abbildung der Leistungsbündel im Kostengestaltungsmodell Durch eine erweiterte prototypgestützte Prozesskostenrechnung wurde in diesem Arbeitspaket die Abbildung der Leistungsbündel in einem vereinfachten Kostengestaltungsmodell bei der Firma TOOLING erreicht. Dabei konnte die Klassifikation aus dem Arbeitspaket 4 und die Differenzierung der Teilprozesse nach der Beziehung zum Prototyp (in Prozesse 1.-3. Grades) zu Grunde gelegt werden. Zunächst galt es, ein allgemeines Prozessmodell für die Erstellung des Leistungsbündels aus Zustimmungsschalter und Engineeringdienstleistung festzulegen. Das Ergebnis dieser Grobanalyse zeigt die folgende Abbildung, bei der auch die für die beiden Bestandteile des Leistungsbündels wichtigen Hauptprozesse 2 und 3 bereits hervorgehoben sind. Insgesamt wurden in die Untersuchung des Geschäftsprozesses „Vermarktung eines Engineering-Leistungsbündels“ fünf Hauptprozesse in die detaillierte Betrachtung und kostenrechnerische Untersuchung integriert. Die erste Analyse ließ sich dabei auch bereits am Designprototypen durchführen. In ausführlichen Interviews mit Führungskräften der TOOLING GmbH & Co. wurden die bisherigen Geschäftsprozesse und Hauptprozesse analysiert und in einem einfachen Geschäftsprozessmodell für das Leistungsbündel zusammengefasst (vgl. Abb. 3.37). Exemplarisch soll die weitere Konkretisierung für den Teil der Engineeringdienstleistung näher erläutert werden. Dabei erfolgte die Darstellung anhand des geometrischen Prototypen. Bei näherer Betrachtung des Hauptprozesses 2 ließen

194


sich vier Teilprozesse zuordnen. Beginnend mit der Aufnahme der Kundendaten sowie der Durchführung der Berechnung, bestand der Hauptprozess 2 „Engineeringdienstleistung“ weiterhin aus der konstruktiven Empfehlung sowie der Dokumentation. In einer Detaillierungsstufe erfolgte weiterhin eine kritische Analyse und Zuordnung der verschiedenen Tätigkeiten zu den Teilprozessen. Bei dieser Erhebung und Festlegung der verschiedenen Teilprozesse galt es besonders eine praxisorientierte Lösung bei gleichzeitiger hoher Realitätsnähe zu finden. Ausgehend von der konkreten Ausgestaltung der einzelnen Teilprozesse konnten anschließend auch die spezifischen Prozesseinflussgrößen identifiziert werden, die als Kostentreiber wesentliche Stellhebel zur Kostenbeeinflussung darstellten.

Abb. 3.37. Geschäftsprozessmodell mit Tätigkeitsanalyse

(7) Kostenorientierte Bewertung der einzelnen Teilprozesse Ausgehend von der Bestimmung der einzubeziehenden Bereiche konnten in einem weiteren Schritt bei der TOOLING GmbH, aufbauend auf dem bereits aufgezeigten Prozessmodell, Hypothesen über die Hauptprozesse und ihre Cost Driver vorgenommen werden. Diese dienten als Basis für die prozesskostenorientierte Bewertung der einzelnen Teilprozesse. Zur sys-


195

tematischen Darstellung soll die Vorgehensweise im Folgenden an den beiden Kostenstellen „Konstruktion“ sowie „Vertrieb Zustimmungsschalter“ näher veranschaulicht werden. Zur genaueren Untersuchung und besseren Möglichkeit der Steuerung wurde bei der kostenorientierten Bewertung ebenfalls eine Gliederung nach der Beziehung zum Prototypen in Prozesse ersten bis dritten Grades vorgenommen. Die Prozesse ersten Grades haben dabei direkte Beziehung zum Prototypen. Dies bewirkt, dass Änderungen am Prototypen auch unmittelbare Auswirkungen auf die verschiedenen Teilprozesse haben. Bei Prozessen zweiten Grades ist diese Beziehung hingegen nur indirekt. Somit lässt sich nur mittelbar eine Wirkungsbeziehung vom Prototypen hin zu den Kosten der Teilprozesse erstellen. Prozesse dritten Grades weisen schließlich keine bzw. nur eine sehr lose Beziehung von den Teilprozessen zum Prototypen auf, sodass eine Veränderung des Produktmodells nicht zwingend zu geänderten Teilprozessen und Teilprozesskosten führt. Für die kostenorientierte Bewertung war es dabei wesentlich, dass die gesamten Kapazitäten der Kostenstelle auf die Teilprozesse verteilt wurden. Weiterhin wurde bei der vorliegenden Untersuchung zusätzlich noch eine Differenzierung in genutzte und ungenutzte Kapazitäten vorgenommen und damit die Möglichkeit zur Durchführung eines TD ABC (Time Driven Activity Based Costing) gegeben. Durch die Unterscheidung konnte auch untersucht werden, wie eine Veränderung bei einzelnen Prozesszeiten auf die genutzte Kapazität und auf Leerkosten wirkten. Durch die Einbeziehung der Prototypenunterstützung wurden gleichfalls Stellhebel zur Beeinflussung von Kostenstruktur, -niveau und -verlauf aufgezeigt. Die Durchführung der Teilprozessplanung und die Einbindung von geometrischen und technischen Prototypen erforderten einen zusätzlichen Zeitaufwand für zahlreiche Mitarbeiter im Hause TOOLING. Auch die Erneuerung der Prozesskapazitätsdaten und die zahlreichen Schätzungen führten zu einer enormen Mehrbelastung des betroffenen Personals. Prototypen wurden im Rahmen des Time Driven Activity Based Costing bei TOOLING zur Planung der Sollzeiten und Stundenkostensätze verwendet. Bereits am Designprototypen konnten, wie bereits aufgezeigt, die betroffenen Kostenstellen identifiziert werden. Somit standen bisherige Kostenstellenkosten für die Planung zur Verfügung. Am geometrischen Prototypen erfolgte eine erste Planung der Sollzeiten für die verschiedenen Teilprozesse. Gleichzeitig konnten auch die Nettokapazität und die Kostenstellenkosten für die beiden betroffenen Kostenstellen geplant werden. Dadurch konnten bereits am geometrischen Prototypen erstmalig die Stundenkostensätze und damit die geplanten Leerkosten ermittelt werden.

196


(8) Prozessorientierte Verknüpfung und Dynamisierung der Kostenbestandteile Ausgehend von der prozessorientierten Abbildung der Leistungsbündel und der kostenorientierten Bewertung der Teilprozesse erfolgte im AP 8 eine Verknüpfung und Dynamisierung der Kalkulation. Dabei erfolgte auch eine Zusammenführung der zunächst getrennt bearbeiteten Themenbereiche. So wurden in der kombinierten Hauptprozessverdichtung zum einen die Kosten des Leistungsbündels „Web-to-CAD“ als auch die netzwerkorientierten Koordinationskosten zusammengefasst. Basis der Kalkulation stellten dabei die Kapazitäten dar, die im Rahmen der Teilprozessbetrachtung auf die verschiedenen Teilprozesse umgelegt wurden. Dabei ließen sich auch die Mengen und Prozesskostensätze zur Planung der gesamten Prozesskosten nutzen. Für den Hauptprozess 2 waren dabei die Teilprozesse „Durchführung der Berechnung“, „Konstruktive Empfehlung“, „Aufnahme der Kundendaten“ sowie „Dokumentation“ mit zu integrieren. (Die gesamten Teilprozesskosten für den Teilprozess „Durchführung der Berechnung“ ergeben sich so z. B. durch Multiplikation von 1500 Mengeneinheiten mit dem Prozesskostensatz von 32,47 €). Die Gesamtkosten von 355.632,- € ergaben sich für 2005 dabei aus der Addition der Kosten für das Leistungsbündel „Web-to-CAD“ mit den Kosten für die Koordination des Entwicklungsnetzwerkes. Das marktorientierte Kostengestaltungsmodell musste des Weiteren berücksichtigen, dass sich die Kosten im Zeitablauf verändern können (z. B. Lernkurveneffekte). Daher wurde in der Betrachtung eine Dynamisierung der Kostenbestandteile vorgesehen. So wurde die Kostenplanung nicht nur für die einzelnen Teilprozesse des Leistungsbündels aus Zustimmungsschalter und Engineeringdienstleistung, sondern auch für den gesamten Hauptprozess durchgeführt. Die im Rahmen der Planperioden sinkenden Koordinationskosten können die Kostensteigerung bei den Teilprozessen der Engineeringdienstleistung überkompensieren.


197

Abb. 3.38. Verdichtung der Kosten für Leistungsbündel und Netzwerkkosten

(9) Aufbau eines Excel-Tools für das Kostenmanagement in Entwicklungsnetzwerken Als wichtig für die praktische Anwendung zeigte sich gleichzeitig die informationstechnische Umsetzung der instrumentellen Neuerung mittels eines innovativen Excel-Tools für die marktorientierte Steuerung. Diese Umsetzung bot dabei den großen Vorteil der einfachen Adaptierbarkeit und unkomplizierten Nutzung des IT-Tools. Gleichzeitig konnten damit erste praktische Erfahrungen bei der kostenrechnerischen Steuerung der Leistungsbündel gemacht werden.Wesentliche Kostenstelleninformationen wurden ebenfalls in das Excel-Tool mit integriert, um für den ausgewählten Bereich auch die gesamten Kosten verteilen zu können. In die vorliegende Betrachtung flossen bei der Firma TOOLING die Kostenstellen der Konstruktion und des Vertriebes ein. Dabei wurde als Hypothese für die Hauptprozesse angenommen, dass die gesamten Kosten für das eine Leistungsbündel anfallen. Anschließend wurde eine Tätigkeits- und Teilprozessbetrachtung durchgeführt und daraufhin die gesamten Kapazitäten verteilt. Es ergaben sich die Kosten für die einzelnen Teilprozesse, die in der Aggregation zu den Kosten der Hauptprozesse führten. Wichtig zur anschaulichen Umsetzung und Erfüllung der Steuerungsfunktion war weiterhin die prototypgestützte Ermittlung und Darstellung der Zielkostenlücken. Ausgehend von dem angestrebten Zielumsatz wur-

198


den sowohl anhand des geometrischen als auch des technischen Prototypen die Gesamtzielkosten und die am Prototypen beeinflussbaren Zielkosten bestimmt. Diese Zielkosten waren dann erneut Ausgangspunkt zur Bestimmung der Zielkostenlücken, die im Bezug zu minimalen und maximalen Drifting Costs resultierten. Die qualitative Analyse untersucht die für eine Kooperation in Frage kommenden Prozesse bei TOOLING hinsichtlich der Einflussgrößen auf die Verursachung von Transaktionskosten. In diesem Praxisprojekt wurden die beiden Entwicklungsprozesse „Komponentenentwicklung“ sowie „Systemintegration und Test“ im Hinblick auf die herausgearbeiteten Transaktionskosteneinflussgrößen untersucht. Dabei wurden die Mitarbeiter von TOOLING aus unterschiedlichen Unternehmensbereichen zu den beschriebenen Entwicklungsprozessen befragt. Nachdem die Mitarbeiter über die qualitativen Einflussgrößen der Transaktionskosten befragt wurden, erfolgt im nächsten Abschnitt die Verknüpfung der quantitativ erhobenen Transaktionskosten mit den qualitativen Einflussgrößen. Phase 3:

Inbetriebnahme des Kostengestaltungsmodells bei der Firma TOOLING sowie Entwicklung des Praxisleitfadens

(10) Pilotanwendung des Kostengestaltungsmodells Der TOOLING-Zustimmungsschalter wird in Zusammenarbeit mit zwei weiteren Unternehmen entwickelt. Bei einem Unternehmen handelt es sich um einen Industriedesigner und beim zweiten um einen Elektronikfunkunternehmen (Aufgabe dieses Unternehmens ist es, eine absolut zuverlässige Funkverbindung zu gewährleisten.) Der Zustimmungsschalter kann, im Gegensatz zu den bisher auf dem Markt erhältlichen Schaltern, lediglich mit einer Hand bedient werden. Des Weiteren kann man sich damit frei bewegen. Um das Modell zu bewerten, wurde eine Vielzahl von Gesprächen mit den Mitarbeitern der TOOLING GmbH & Co. geführt. Die Merkmale von Produktentwicklungsprozessen spielten dabei eine ganz entscheidende Rolle. Im Gegensatz zu den vorwiegend repetitiven Prozessen in der Produktion sind Entwicklungsvorhaben mit einem gewissen Neuigkeitsgrad verbunden. Ein hoher Neuigkeitsgrad erschwert die Prognostizierbarkeit und verursacht außerdem einen entsprechenden Zeitaufwand für die Suche und Erarbeitung neuer Problemlösungen. Entwicklungsprojekte mit einem sehr hohen Neuigkeitsgrad eignen sich deshalb weniger für den Einsatz des konzipierten Excel-Tools. Bei derartigen Vor-

Literatur

199

haben konnten die befragten Mitarbeiter z. B. nur sehr ungenaue Aussagen über die zu erwartende Transaktionskostenhöhe machen. Ähnliches gilt auch für die Komplexität. Die Unvorhersehbarkeit bestimmter Prozesse und die fehlende Erfahrung auf dem jeweiligen Entwicklungsgebiet können schnell zu einer sehr hohen Komplexität führen, die einen sinnvollen Einsatz des Excel-Tools nicht mehr gewährleisten. Ein Weiteres bedeutendes Kriterium stellt die Strukturierbarkeit dar. Durch eine Strukturierung sollen komplexe Aufgaben überschaubar und handhabbar gemacht werden.

Literatur [3.1] Abel V (1994) Vertrauensbereiche für Prozessfähigkeitsindices, QZ 39 (1994) 11, pages 1262-1265 [3.2] Ashok S (1996) Statistical process control, The Indian Textile Journal 106 (1996) 11, pages 46-48 [3.3] Bach N, Buchholz W (1997) Innovationen als Projekt oder Prozess? In: ZfO, Jg. 66, 1997, Nr. 6, S. 340-346 [3.4] Becker R, Grzesiak A, Henning A (2005) Rethink assembly design. In: Assembly Automation 25 (2005), Nr. 4, S. 262-266 [3.5] Bedford T, Cooke R (2001) Probabilistic Risk Analysis: Foundations and Methods, Cambridge University Press, 2001 [3.6] Berger S (2002) Wissensmanagement in der Produktentwicklung - Methoden und Instrumente des Wissensmanagements. In: Zukunftssicherung und Risikooptimierung in der Produktentwicklung: Fraunhofer IPA-Tagung F81, 14. November 2002 in Stuttgart / Westkämper, Engelbert (Hrsg.); Schraft, Rolf Dieter (Hrsg.); Sihn, Wilfried (Hrsg.). Stuttgart: Fraunhofer IPA-Tagung, 2002, S. 151-161 [3.7] Bertsche B, Lechner G (2004) „Zuverlässigkeit im Fahrzeug- und Motorenbau“, 3. Auflage, Springer Verlag, Berlin Heidelberg, 2004 [3.8] Blessing N, Grzesiak A (2004) Rapid Prototyping, Tooling & Manufacturing - State of the Industry - Germany. In: Wohlers, Terry T.: Wohlers Report 2004 : Rapid Prototyping & Tooling State of the Industry. Annual Worldwide Progress Report. Fort Collins, Co, USA : Wohlers Associates, 2004, S. 133 [3.9] Bullinger HJ, Warschat J, Wißler KF, Seitz V (1996) Rapid Product Development – ein ganzheitliches Produktentwicklungskonzept, in: Konstruktion, Jg. 48, 1996, Nr. 10, S. 305-334 [3.10] Bullinger HJ, Warschat J (1997) „Forschungs- und Entwicklungsmanagement“, Stuttgart, Teubner, 1997 [3.11] Bürgel HD, Haller C, Binder M (1996) F&E-Management, München: Vahlen, 1996 [3.12] Burghardt M (2002) Projektmanagement: Leitfaden für die Planung, Überwachung und Steuerung von Entwicklungsprojekten, 6. Aufl., Erlangen 2002

200


[3.13] Cassack I (2002) Prozessorientiertes Kostenmanagement am Beispiel der prototypgestützten Kostengestaltung für Dienstleistungen. In: REFANachrichten, Jg. 55, 2002, Nr. 6, S. 23-26 [3.14] Castillo E, Gutiérrez JK, Hadi AS (1997) Expert Systems and Probabilistic Network Models. New York: Springer Verlag, 1997 [3.15] Corsten H (2001) Dienstleistungsmanagement. 4. Aufl., München; Wien: Oldenbourg, 2001 [3.16] Cowell RG u.a. (1999) Probabilistic Networks and Expert Systems, Springer Verlag, New York, 1999 [3.17] Czichowsky A (2003) Netzeffekte. In: Controlling, Jg. 15, 2003, Nr. 1, S. 57-59 [3.18] Dreher S (2003) Prototypen-Management, in: Futur, Jg. 5, 2003, Nr. 1, S. 10f [3.19] Dudenhöfer F (2001) Betriebswirtschaftslehre: InternetEinkaufsplattformen. In: WISU, Jg. 29, 2001, Nr. 2, S. 200-206 [3.20] Ehrlenspiel K (1995) „Integrierte Produktentwicklung“, Carl Hanser Verlag, München Wien, 1995 [3.21] Ehrlenspiel K, Kiewert A, Lindemann U (2005) „Kostengünstig entwickeln und konstruieren“, Springer, 2005 [3.22] Fischer D, Warschat J (1997) Rapid Prototyping, in: Bullinger, Warschat (Hrsg., 1997), S. 205-219 [3.23] Fraunhofer IPA, Rapid Product Development“ [3.24] Geuer A (1996) „Einsatzpotential des Rapid Prototyping in der Produktentwicklung“, Springer-Verlag Berlin Heidelberg, 1996 [3.25] Gomes de Sá A (2001) Virtual Prototyping als innovative Absicherungsmethode im Produkterprobungsprozeß, Stuttgart 2001 [3.26] Grzesiak A (2005) Qualität durch Design : Effiziente Produktgestaltung in hybriden Modellwelten für Kleinserien. In: Stuttgarter Messe- und KongressGesellschaft: CAT.PRO 2005 : 21. Internationale Fachmesse für innovative Produktentwicklung, Daten- und Prozessmanagement, 04.-07.10.2005, Stuttgart. Stuttgart, 2005, 24 S [3.27] Grzesiak A (2006) Serienfertigung in Losgröße 1. In: Digital Engineering (2006), Nr. 1, S. 54-55 [3.28] Grzesiak A, Becker R (2006) Generative Verfahren zur Herstellung von Betriebsmitteln. In: Werkstückspanntechnik GmbH: Praxistagung Werkstückspanntechnik : 4. Fachtagung Prozesszeitverkürzung und Rüstkostenoptimierung, Ingolstadt, 17./18. Mai 2006. Landsberg/Lech : verlag moderne industrie, 2006, 24 S [3.29] Grzesiak A, Mistelbauer J, Henning A (2005) Rapid Manufacturing chances and risks for small and medium size enterprises. In: Meyer, Rudolf (Ed.); Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung / Fraunhofer-Allianz Rapid Prototyping: Euro-u Rapid 2005 : High-Tech Solutions and Best Practice Concepts. Proceedings. International User's Conference on Rapid Prototyping & Rapid Tooling & Rapid Manufacturing. Leipzig, May 10-12, 2005. Magdeburg, 2005, Vortrag A3/1

Literatur

201

[3.30] Grzesiak A, Mistelbauer J, Henning A (2005) Umstieg dringend empfohlen. In: Werkzeug & Formenbau (2005), Nr. 3 (Juli), S. 10-11 [3.31] Haller B (2002) Optimierung von Prozessketten für die Herstellung von Prototyp-Blechumformwerkzeugen, Stuttgart 2002 [3.32] Haritz A (2000) Innovationsnetzwerke. Ein systemorientierter Ansatz. Wiesbaden: Gabler 2000 [3.33] Heckerman D (1996) A Tutorial on Learning with Bayesian Nerworks, Technical Report MSR-TR-95-06, Mictosoft Research, Redmond, Washington, 1996 [3.34] Heckerman D, Geiger D, Chickering D (1995) Learning Bayesian Networks: The Combination of Knowledge and Statistical Data, Technical Report MSR-TR-94-09, Mictosoft Research, Redmond, Washington, 1995 [3.35] Heimerl S (2000) INTERACTIVA Biotechnologie GmbH: Virtuelles Labor für biotechnologische Basisprodukte. In: Netzwerk-Unternehmer: Fallstudien netzwerkintegrierter Spin-offs, Ventures, Start-ups und KMU / Reiß, M. (Hrsg.), München: Vahlen, 2000, S. 279-304 [3.36] Henning A, Grzesiak A (2005) Rapid Prototyping, Tooling & Manufacturing - State of the Industry - Germany. In: Wohlers, Terry T.: Wohlers Report 2005 : Rapid Prototyping & Tooling & Manufacturing. State of the Industry. Annual Worldwide Progress Report. Fort Collins, Co, USA : Wohlers Associates, 2005, S. 112-114 [3.37] Henning A, Grzesiak A (2006) Rapid Prototyping, Tooling & Manufacturing - State of the Industry - Germany. In: Wohlers, Terry T.: Wohlers Report 2006 : Rapid Prototyping & Tooling & Manufacturing. State of the Industry. Annual Worldwide Progress Report. Fort Collins, Co, USA : Wohlers Associates, 2006, S. 115-116 [3.38] Henning A, Grzesiak A, Roth-Koch S, Becker R, Effenberger I, Westkämper E (2005) Rapid Prototyping and Manufacturing - Trends and Developments in Germany. In: Society of Manufacturing Engineers: Rapid Prototyping and Manufacturing 2005 - Advanced Product Development Solutions CD-ROM : May 10-12, 2005 Dearborn, Michigan, USA. Technical Session Proceedings. Dearborn, MI, USA : SME, 2005, 12 S [3.39] Horváth P, Lamla J, Höfig M (2004) Rapid Prototyping – der schnelle Weg zum Produkt, in: Harvard Business Manager, Jg., 17, 2004, Nr. 3, S. 42-53 [3.40] Horvitz EJ, Breese JS, Henrion M (1988) Decision Theory in Expert Systems and Artificial Intelligence, 1988 [3.41] Jaynes ET (1983) Papers on Probability, Statistics and Statistical Physics / Rosenkrantz, R.D.; Reidel, D. (Hrsg.), Dordrecht, Holland, 1983 [3.42] Jaynes ET (1979) Where do we stand on maximum entropy? In: The maximum entopy formalism / Levine, R.D.; Tribus, M. (Hrsg.), Cambridge, MIT Press, 1979 [3.43] Jensen F (2001) Bayesian Networks and Decision Graphs, Springer Verlag, New York, 2001 [3.44] Jöstingmeier B, Lessel M (1999) Innovationsprojekte erfolgreich durchführen. In: ZfO, Jg. 68, 1999, Nr. 5, S. 292-295

202


[3.45] Kempf M, Grzesiak A (2003) Entscheidungsunterstützung in der Produktentwicklung - Problemorientierte Auswahl eines Lösungskonzepts durch kontextsensitive Methodenkonfiguration. In: wt Werkstatttechnik online (2003) Heft 6, S. 494-497 [3.46] König W, Eversheim W, Celi I, Nöken S, Ullmann C (1993) Rapid Prototyping – Bedarf und Potentiale, in: VDI-Zeitung, Jg. 135, 1993, Nr. 8, S. 9294 [3.47] Kopsch J (1998) “Unterstützung der Konstruktionstätigkeiten mit einem Aktiven Semantischen Netz”, Dissertation, IMA University of Stuttgart, 1998 [3.48] Krottmaier J (1995) „Leitfaden Simultaneous Engineering“, SpringerVerlag, Berlin Heidelberg, 1995 [3.49] Kühnel J (1995) Datenrepräsentation durch Prototypen: erweiterte Konzepte und ihre Anwendung in der Bild- und Sprachverarbeitung, München 1995 [3.50] Lambeck P, Bertsche B (2004) „Combining Design and Creativity Tools“, Paper 292, INTERNATIONAL DESIGN CONFERENCE - DESIGN 2004, Dubrovnik, May 18 - 21, 2004 [3.51] Lincke W (1995) „Simultaneous Engineering“, Carl Hanser Verlag München Wien, 1995 [3.52] Madauss BJ (1997) Projektkostenschätzung im Rahmen der Produktentwicklung, In: Horváth, P. u.a. (Hrsg., 1997), S. 20-31 [3.53] Marx P (1998) “Durchgängige, bauteilübergreifende Auslegung vom Maschinenelementen mit unscharfen Vorgaben”, Dissertation, IMA University of Stuttgart, 1998 [3.54] Neapolitan RE (2003) Learning Bayesian Networks, Prentice Hall Series In Artificial Intelligence, New Jersey 2003 [3.55] Neapolitan RE (1990) Probabilisitic Reasoning in Expert Systems. New York: Wiley, 1990 [3.56] Pahl G, Beitz W, Feldhusen J, Grote KH (2005) „Konstruktionslehre“, 6.Auflage, Springer-Verlag, Berlin Heidelberg, 2005 [3.57] Paprottka S (1996) Unternehmenszusammenschlüsse: Synergiepotenziale und ihre Umsetzungsmöglichkeiten durch Integration. Wiesbaden: Gabler, 1996 [3.58] Paul M, Reckenfelderbäumer M (2001) Preisbildung und Kostenrechnung auf der Basis neuer Kostenrechnungsverfahren, in: Bruhn, Meffert (2001), S. 627-659 [3.59] Pearl J (1988) Probabilistic Reasoning in Intelligent Systems - Networks of Plausible Inference, San Francisco: Morgan Kaufmann, 1988 [3.60] Pickard K, Müller P, Bertsche B (2004) FMEA as Design Monitor, Regulation and Management Tool Parallel to Product Design Cycle for Optimised Quality Assurance. Proc. PSAM 7 / ESREL ´04-Conference, 14. - 18. June 2004, Berlin, Germany, pp. 3287-3292 [3.61] Pickard K, Müller P, Bertsche B (2004) Synergies of FMEA and other qualitative quality methods for an optimised quality assurance. Proc. 5th international conference of QRM 2004, 1st and 2nd April 2004, Oxford, England, pp 35-38

Literatur

203

[3.62] Picot A, Dietl H, Franck E (1999) Organisation: Eine ökonomische Perspektive. 2. Aufl., Stuttgart: Schäffer-Poeschel, 1999 [3.63] Picot A, Reichwald R, Nippa M (1988) Zur Bedeutung der Entwicklungsaufgabe für die Entwicklungszeit: Ansätze für die Entwicklungszeitgestaltung, in: Brockhoff, K. u.a. (1988), S. 112-137 [3.64] Reckenfelderbäumer M (1995) Marketing-Accounting im Dienstleistungsbereich – Konzeption eines prozeßkostengestützten Instrumentariums, Wiesbaden 1995 [3.65] Ruffing B (1993) Prozesse durch Kennwerte 'fähig' beurteilen, QZ 38 (1993) 4, pages 241-244 [3.66] Schmelzer HJ (1992) Organisation und Controlling von Produktentwicklungen: Praxis des wettbewerbsorientierten Entwicklungsmanagements, Stuttgart 1992 [3.67] Spath D, Demuß L (2003) Entwicklung hybrider Produkte – Gestaltung materieller und immaterieller Leistungsbündel, in: Bullinger, Scheer (Hrsg., 2003), S. 467-506 [3.68] Specht G, Beckmann C, Amelingmeyer J (2002) F&E-Managment: Kompetenz im Innovationsmanagement, 2. Aufl., Stuttgart 2002 [3.69] Spitta T (1989) Software Engineering und Prototyping: eine Konstruktionslehre für administrative Softwaresysteme, Berlin et al. 1989 [3.70] Thielemann F (1999) Innovation durch Kooperation. In: Innovationsintegral Mittelstand: Kompetenzentwicklung in Medienkooperationen / Ciesinger, K.G.; Siebecke, D.; Thielemann, F. (Hrsg.). Münster, 1999, S. 47-82 [3.71] Vahs D, Burmester R (2002) Innovationsmanagement: Von der Produktidee zur erfolgreichen Vermarktung, 2. Aufl., Stuttgart 2002 [3.72] VDA (2003) Band 4, Sicherung der Qualität vor Serieneinsatz - Sicherung der Qualität während der Produktrealisierung – Methoden und Verfahren, VDA 4, 1. Auflage 2003 [3.73] VDI (1977) “VDI-Richtlinie 2221: Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte”, VDI-Verlag, Düsseldorf, 1977 [3.74] VDI (1993) “VDI-Richtlinie 2222: Konzipieren technischer Produkte”, VDI-Verlag, Düsseldorf, 1993 [3.75] Weber J, Schäffer U (2001) Controlling in Dienstleistungsunternehmen, in: Bruhn, Meffert (2001), S. 899-913 [3.76] Westkämper E, Roth-Koch S, Stotz M (2003) A New Design Orientated Digitalization Technology - Integration of the Conceptual Design into the Design Process. In: CIRP Design Seminar 2003, 12.-14. Mai 2003 in Grenoble, Tagungsband + CD ROM [3.77] Weule H (2002) Integriertes Forschungs- und Entwicklungsmanagement: Grundlagen, Strategien, Umsetzung, München und Wien 2002 [3.78] Wildemann H (1998) Entwicklungs-, Produktions- und Vertriebsnetzwerke in der Zulieferindustrie. München: TCW, 1998 [3.79] Wildemann H (1997) Koordination von Unternehmensnetzwerken. In: ZfB, Jg. 67, 1997, Nr. 4, S. 417-439 [3.80] Wörner K (1999) „System zur dezentralen Planung von Entwicklungsprojekten im Rapid Product Development“, Springer-Verlag, 1999

204


[3.81] Zwecker J, Düll-Mühlbach I, Eßwein G (1994) Erhöhung der Prozeßfähigkeit - 'Forgiving Systems', Konferenz-Einzelbericht: Starke Märkte - Composites stellen sich dem Wettbewerb, 26. Int. AVK-Tagung, Arbeitsgemeinschaft Verstärkte Kunststoffe, Berlin, pages P2/1-8, 1994

4 Wissensrepräsentation und Kommunikation (RPD-IT-Infrastruktur)

Zur Beschleunigung der Entwicklung neuer und innovativer Produkte und angrenzender Dienstleistungen ist eine effektive Zusammenarbeit multidisziplinärer Experten erforderlich. Diese müssen über zeitliche, örtliche und fachliche Grenzen hinweg kooperieren, damit verteiltes Wissen zur Lösungsfindung herangezogen werden kann. Daher wurden für das Rapid Product Development (RPD) Vorgehensweisen und IT-basierte Lösungen zur aktiven Wissensrepräsentation und Kommunikation entwickelt, die den evolutionären und iterativen Anforderungen des RPD gerecht werden und expertenspezifische Anwendungen unterstützen. Die Plattform zur Integration fachübergreifenden Wissens muss der Dynamik, insbesondere in den Phasen der Ideenausarbeitung, gerecht werden und eine Möglichkeit zur aktiven Zusammenarbeit der Experten bereitstellen. Die Anforderungen an die Unterstützung der RPD-Experten entlang des Produktentstehungsprozesses beziehen sich auf unterschiedliche Ebenen. So sind neben einem einheitlichen Zugang zu situationsgerecht aufbereiteten Informationen ebenfalls unterstützende Methoden für die Teamkooperation und -kommunikation notwendig. Als Grundlage einer teamübergreifenden Zusammenarbeit muss ein einheitlicher Datenpool mit einer flexiblen, auf die Aufgaben der einzelnen Experten zugeschnittenen Schnittstelle zur Verfügung stehen. Dabei müssen in das Gesamtsystem die aufgabenorientierten RPD-Werkzeuge integrierbar sein. Zu diesem Zwecke wurde eine RPD-IT-Infrastruktur geschaffen, die als Mittler zwischen den einzelnen, spezifischen RPD-Aufgaben fungiert. Sie besteht aus vier Ebenen, die im weiteren Verlauf dieses Kapitels näher beleuchtet werden (Abb. 4.1.). Die vier Ebenen werden durch Nutzeraktionen von oben nach unten zur Datenbeschaffung und von unten nach oben zur Datenaufbereitung durchlaufen. Beim Durchlauf von oben nach unten wird die Informationsbeschaffung durch die einzelnen Ebenen und den damit verbundenen Anwendungen immer weiter verfeinert. Während im umgekehrten Durchlauf, von unten nach oben, die gewonnenen Informationen durch die entsprechenden Verfahren für den Experten situationsgerecht aufbereitet werden.

206


Dabei erbringt jede Ebene eine Dienstleistung für die darüber liegende Ebene und nutzt gleichzeitig die angebotene Dienstleistung der darunter liegenden Ebene.

Abb. 4.1. Architektur der RPD-IT-Infrastruktur

Auf der obersten Ebene befindet sich das RPD-Portal (Kap. 4.4 „Adaptive Benutzungsoberflächen“). Das RPD-Portal stellt die visuelle Schnittstelle zum Nutzer dar. Es bietet einen einheitlichen Zugriff auf die RPDAnwendungen unter Berücksichtigung der Aufgabenstellung des Nutzers. Dies bedeutet das Portal passt sich den Aufgaben des Nutzers an, so dass für jeden Benutzer ein entsprechendes Profil erzeugt wird, mit dessen Hilfe er Zugang zu den für ihn relevanten Informationen erhält. Dadurch wird der Experte von einer Überfrachtung von Informationen geschützt. Der Experte agiert dann im Rahmen seiner Rolle. Die zweite Ebene beinhaltet die einzelnen RPD-Anwendungen und die teamorientierte Kommunikation. Bei den RPD-Anwendungen handelt es sich um spezifische Anwendungen je nach RPD-Aufgabe. Dies können zum Beispiel Projektmanagementwerkzeuge (Kap. 2), Konstruktions- /

4.1 Ganzheitliche Modelle zur Repräsentation aktiven Wissens

207

Qualitäts- und Kostenwerkzeuge (Kap. 3) ebenso sein, wie Prototypenverfahren und deren Anwendungen (Kap. 5). Die teamorientierte Kommunikation (Kap. 4.3 „Teamorientiertes Kommunikationssystem für vernetztes Arbeiten“) stellt dabei eine Funktionalität zur Verfügung, die sowohl die RPD-Anwendungen als auch den Experten bei der Datenmanipulation unterstützen. Zu diesem Zweck wurden zwei Richtungen zur IT-basierten Unterstützung der teamorientierten Zusammenarbeit verfolgt. Zum einen wurde eine asynchrone Teamumgebung entwickelt. Dieses Werkzeug dient zum Austausch von Informationen in Form von Nachrichten und zur Terminabsprache unter Berücksichtigung bereits bestehender Termine, d.h. das System unterstützt den Nutzer bei der Terminvereinbarung, so dass nach Abschluss des Abstimmungsprozesses der Termin für alle Beteiligten als verbindlich angesehen werden kann. Die zweite IT-basierte Unterstützung der teamorientierten Zusammenarbeit verfolgt den synchronen Kommunikationsansatz. Hierfür wird ein drei-dimensionaler Teamraum zur Verfügung gestellt, in dem alle Experten eines Teams zeitgleich zusammenarbeiten können. Dabei können Ergebnisse des RPD, bspw. in Form von virtuellen Prototypen, gemeinsam betrachtet und begutachtet werden. Zusätzlich können Informationen, dieses Beispiel weiterverfolgend, über den Prototypen im Teamraum hinterlassen werden. Der Nutzer wird dabei durch ein Avatar, bspw. einem Foto von sich, im Teamraum dargestellt, so dass der persönliche Bezug nicht verloren geht. Die beiden untersten Schichten befassen sich mit Datenhaltung und verwaltung. Die Datenhaltung erfolgt durch ein semantisches Netz, das um zusätzliche Funktionalitäten angereichert ist, die die Datenmanipulation unterstützen. Es entsteht das Aktive Semantische Netz (ASN) (Kap. 4.1 „Ganzheitliche Modelle zur Repräsentation aktiven Wissens“). Das ASN besitzt kein starres Datenmodell, wie es üblicherweise für spezifische Anwendungen verwendet wird. Der Vorteil dieses Ansatzes liegt darin, dass beliebige Informationen, wie sie entlang des Produktentstehungsprozesses entstehen, strukturiert abgelegt werden können. Bei der Vernetzung von Informationen entstehen Abhängigkeiten von Informationen, die zu Inkonsistenzen führen können. Das ASN bietet daher die Möglichkeit Randbedingungen (Constraints) in Form von Formeln zu definieren, die dann die Informationsinhalte entsprechend anpassen. Ein weiteres Merkmal des ASN ist die Entwicklung von Event-Condition-Action-(ECA)-Regeln zur aktiven Informationspropagation. So können Informationselemente überwacht werden und unter Einhaltung der Bedingung andere Informationselemente automatisch angepasst werden. Diese Verfahren sind auf das ASN beschränkt. Des Weiteren ist es nicht die Aufgabe einer Datenhaltung Informationen situationsgerecht und auf-

208


gabenbezogen dem Nutzer zur Verfügung zu stellen. Zu dem Zwecke wurde eine agentenbasierte RPD-Middleware als Vermittlerschicht zwischen ASN und RPD-Anwendungen eingezogen (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“). Die RPD-Middlware erbringt dabei auf der Basis des ASN informationsverarbeitende, -überwachende und -verwaltende Dienst-leistungen für die RPD-Anwendungen, ebenso wie eine Koordinations-unterstützung. Zu den informationsverarbeitenden Dienstleistungen gehören die Informationsbeschaffung und -aufbereitung, sowie die Unterstützung der Dateneingabe und der Transaktionsschutz. Durch die Informationsbeschaffung erhält der Nutzer die Möglichkeit Informationen im ASN zu finden ohne das Datenmodell und die interne Struktur im Detail kennen zu müssen. Es werden dabei scharfe und unscharfe Suchmethoden eingesetzt, so dass der Nutzer einen Überblick über die vorhandenen Informationen, gewichtet nach seinem Suchkriterium, erhält. Die Informationsaufbereitung fasst die Ergebnisse der Informations-beschaffung nach Nutzerkriterien zusammen. Die Eingabeunterstützung erleichtert dem Nutzer das Einstellen von neuen Informationen in das ASN und ermöglicht in Verbindung mit der Informationsüberwachung die Dateneingabe in Abhängigkeit zu den bereits vorhanden Daten zu setzen. Hierfür wird ein Transaktionsschutz benötigt, um unterbrechungsfrei Daten in das ASN einstellen zu können. Mit Hilfe der Informationsüberwachung wird der Nutzer in die Lage versetzt, für ihn wichtige im ASN hinterlegte Informationen auf Veränderung oder Nutzung zu überwachen. Damit kann der Nutzer schnell auf neue Gegebenheiten, wie bspw. einen neuen Prototypen, reagieren. Aufgrund der Größe und der räumlichen Aufteilung der Nutzer und ihrer Anwendung bietet sich eine Verteilung des ASN in kleinere zusammenhängende Instanzen an. Dafür wurde ein Synchronisationsmechanismus als verwaltende Dienstleistung entwickelt. Die Aufgabe der Synchronisation ist es, die überlappenden Informationselemente zwischen den ASN-Instanzen synchron zu halten. Die Koordination dient der Unterstützung der Nutzer bei ihrer Teamarbeit. Die RPD-Middleware bietet hierzu als Dienstleistung die Möglichkeit ein beliebiges Koordinationsprotokoll zu definieren und abzuarbeiten. Dies bedeutet, jeder Nutzer erhält entlang des Koordinationsprotokolls Aufgaben, die er erledigen muss. Die Fertig-stellung meldet er der Koordinationskomponenten der RPD-Middleware, die anhand des vorher vereinbarten Koordinationsprotokolls neue Koordinationsschritte einleitet. Dabei ist zu beachten, dass entlang des Produktentstehungsprozesses langandauernde Koordinationsvorgänge stattfinden können.


209

Die RPD-Middleware ist in Form eines Agentensystems aufgebaut und stellt für jede der beschriebenen Aufgaben einen Agententyp zur Verfügung von dem beliebig viele instanziiert werden können. Die folgende detaillierte Beschreibung der RPD-IT-Infrastruktur erfolgt von unten (ASN) (Kap. 4.1 „Ganzheitliche Modelle zur Repräsentation aktiven Wissens“) über die RPD-Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“) und der teamorientierten Kommunikation (Kap. 4.3 „Teamorientiertes Kommunikationssystem für vernetztes Arbeiten“) hin zur obersten Ebene, dem RPD-Portal (Kap. 4.4 „Adaptive Benutzungsoberflächen“).


4.1.1 Einleitung Innerhalb des Rapid Product Development (RPD) stellt das ASN die zentrale Integrationskomponente zur Verfügung. Sie bietet allen Wissensbereichen im RPD eine gemeinsame Plattform für eine integrierte Wissensbasis und ermöglicht damit eine Verzahnung aller Wissensbereiche.

Abb. 4.2. ASN als Integrationsgrundlage für die Unterstützung der RPD-Prozesse

210


4.1.2 Problemstellung Die frühen Phasen der Produktentwicklung sind von einem hohen Bedarf an Informationen interdisziplinärer Art gekennzeichnet. Eine den RPDBedürfnissen entsprechende Wissensbasis muss in der Lage sein, Objekte und Beziehungen verschiedener Art erfassen zu können. Die besonderen Anforderungen an die Wissensbasis entstehen durch die Dynamik der RPD-Prozesse. Die Wissensbasis repräsentiert meistens keinen stabilen und konsistenten Zustand, sondern nur den aktuellen Zustand von mehreren parallel laufenden Entwicklungsprozessen. Das Finden und Anwenden von Maßnahmen zur Synchronisierung der Bearbeitungsprozesse und zur Wiederherstellung von Konsistenz gehört zu den wichtigsten Aufgaben. Für die vorhandenen Produktdaten müssen Repräsentationsmechanismen entwickelt werden und die inkrementelle Verfeinerung und Ergänzung des Wissens im Laufe des Entwicklungsprozesses muss möglich sein. Die Wissensbasis dient zur Unterstützung der kooperativen Arbeit dezentraler Teams, die auf gemeinsame Datenobjekte koordiniert zugreifen. Für die Beschleunigung der Entwicklungsprozesse soll auch parallele Arbeit an mehreren Kopien der Objekte möglich sein. Durch geeignete Sperrmechanismen muss gewährleistet werden, dass keine, sich widersprechende, parallel verlaufende Bearbeitungsvorgänge stattfinden können. Dabei muss dafür Sorge getragen werden, dass Sperren maßvoll eingesetzt werden. Die RPD-Wissensbasis soll von allen Wissensbereichen benutzt werden und stellt im Rahmen des Produktentstehungsprozesses die datentechnische Grundlage für eine integrierte Software-Architektur für Rapid Product Development-Prozesse dar. Die grundlegenden Arbeiten wurden im Rahmen des Sonderforschungsbereich 374 „Entwicklung und Erprobung innovativer Produkte – Rapid Prototyping“ durchgeführt. 4.1.3 Meilensteine der Entwicklung, Stufe 1 – ASN, Metamodell, ECA In der ersten Entwicklungsstufe (1995-1997) wurden ein Metamodell und eine objektorientierte Datenbasis entwickelt [4.60]. Das bildete die Basis des Aktiven Semantischen Netzes (ASN) [4.77], [4.178], [4.157], [4.160]. Es wurden Ansätze der aktiven Komponenten, über ECA-Regeln (EventCondition-Action) gesteuert [4.59], [4.158], untersucht. Die entwickelte aktive Komponente ist in der Lage, Schlussfolgerungen in der Wissensbasis durchzuführen und auch externe Applikationen, insbesondere Benachrichtigungsmechanismen, zu starten [4.158]. Die Notwendigkeit einer idealerweise plattformunabhängigen Schnittstelle für eine prozessüber-


211

greifende Wissensbasis wurde erkannt und als eine der zentralen Forschungsaufgaben untersucht.

Abb. 4.3. Graphische Darstellung des ASN-Metamodells

Die Kenntnisse aus der prototypischen Entwicklung dieser Schnittstelle und den experimentellen Integrationsuntersuchungen wurden aus prototypischen Evaluierungszyklen gewonnen. Im Speziellen ist die Grundlage für die Entwicklung eines kooperativen Transaktionskonzeptes [4.159], [4.163], [4.165] erarbeitet worden. Kurzbeschreibung der in der ersten Phase festgelegten Architektur des aktiven semantischen Netzes: x Durch das ASN sollen alle an der Produktentwicklung beteiligten Wissensgebiete abgebildet werden. x Die Wissensbasis des ASN soll dabei den gesamten Entwicklungsprozess unterstützen. x Das ASN-Konzept besteht aus dem Metamodell des Semantischen Netzes und der aktiven Komponente. x Das semantische Netz stellt eine Struktur dar, bei der die Knoten die Objekte der realen Welt und die Kanten die Beziehungen zwischen den Knoten repräsentieren. x Die aktive Komponente dient der Propagierung von Wissen durch das semantische Netz. Dies ermöglicht z.B. die Erhaltung von Konsistenzbedingungen beim Zugriff auf das ASN.

212


x Der aktiven Komponente liegt ein Event-Condition-Action (ECA)Regelmechanismus zugrunde. Durch einen Event wird überprüft, ob die Condition erfüllt ist. Im positiven Fall erfolgt die Ausführung einer Action. x Events werden durch die Ausführung von Zugriffsfunktionen auf das ASN ausgelöst. x Die objektorientierten C++ Zugriffsfunktionen werden durch die ASNAPI aufgerufen. x Die Transaktionssemantik der bestehenden ASN-API wird durch kurze Transaktionen bestimmt.

Abb. 4.4. ASN-Metamodell, Beziehungsslots

4.1.4 Meilensteine der Entwicklung, Stufe 2 – Verteiltes Objektmanagement, Slot-Dämon, Transaktionskonzept In der zweiten Entwicklungsstufe (1998-2000) wurde die ASN-Konzeption in umfangreicher Weise fortgeführt und erweitert. Unter den erzielten Ergebnissen ist vor allem die Erweiterung der ASN-Architektur zu einem verteilten Objektmanagement (s. Abb. 4.5) gemäß Common Object Request Broker Architecture (CORBA) [4.114], die vollständige Konzeption und Umsetzung des kooperativen Transaktionskonzepts und die Erweiterung der aktiven Komponente hervorzuheben. Durch Verwendung des CORBA-Standards wurde nicht nur der verteilte, systemunabhängige Zugriff auf Objekte der Wissensbasis ermöglicht, sondern auch eine verteilte Speicherung dieser Objekte in verschiedenen Objekt-Servern.


213

Abb. 4.5. Organisation des verteilten Objektmanagements

Abb. 4.6. Der Slot-Dämon innerhalb der Client- Server-Anwendung

Als Ergänzung zur Benutzung von ECA-Regeln wurden die SlotDämonen (s. Abb. 4.6) entwickelt [4.60]. Die Slot-Dämonen erlauben

214


hierbei das Abspeichern von Berechnungsvorschriften und Konsistenzbedingungen als Attributwerte. Diese werden zum Abfragezeitpunkt ausgewertet und die entsprechenden Aktionen durchgeführt. Während Transaktionskonzepte konventioneller Datenbanksysteme zu unflexibel für dynamische Entwicklungsprozesse sind und kooperatives Arbeiten nur unzureichend unterstützen, wurde für die Wissensbasis ein Transaktionskonzept entwickelt, das die speziellen Anforderungen des RPD-Prozesses umsetzt [4.59], [4.165], [4.164]. Das Konzept erlaubt die gemeinsame Nutzung und Weiterentwicklung von Produktdaten durch mehrere verteilte Entwicklungsteams. 4.1.5 Meilensteine der Entwicklung - Stufe 3 In der dritten Entwicklungsstufe (2002-2003) ist ein weiterer Evolutionsschritt in der Entwicklung ganzheitlicher Modelle zur Wissensrepräsentation vollzogen worden. Unter den erzielten Ergebnissen sind vor allem folgende Schwerpunkte zu nennen: x Die Weiterentwicklung des ASN auf der Basis von EJBs (Enterprise Java Beans) [4.188], [4.139], [4.175], [4.173], insbesondere von EntityJava-Beans, Session-Beans, remote- und home-Interfaces und ClientSoftware, die Schaffung der Voraussetzungen für die Internetfähigkeit des ASN und die Bereitstellung der Formulare für manuelle Änderungen der ASN-Datenbasis. Diese Entwicklungen wurden um eine agentenbasierte Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“) ergänzt. x Des Weiteren ist die Weiterentwicklung des ASN-Klassenmodells zu erwähnen und die Erarbeitung eines vereinheitlichten Klassenmodells (im Weiteren UDM als Abkürzung für Unified Data Modell) [4.134], [4.166], [4.161], [4.162] das es erlaubt, Objekte verschiedener Art auf gleiche Weise zu handhaben. Das weiterentwickelte ASN-Datenmodell erleichtert die Informationswiedergewinnung. In den Abfragen können nicht nur die Attributwerte, sondern es kann auch das Vorhandensein der Attribute als Abfragekriterium benutzt werden. Mehrere objektartspezifische Abfragen lassen sich durch eine von den Objektarten unabhängige parametrische Abfrage ersetzen. Für die Semantik der ASNDaten spielt die genaue Unterscheidung der Objektarten, Beziehungsarten, Ereignisarten und Aktionsarten eine sehr wichtige Rolle. x Anhand der praktischen Erfahrungen wurde auch die Funktionalität des ASN weiterentwickelt. An dieser Stelle sind vor allem die neuen Daten-


215

strukturen für die Erfassung von Constraints und die Lösungsansätze für die Berücksichtigung der kombinatorischen Vielfalt bei der Anwendung von ECA-Regeln zu erwähnen. Im Unterschied zu den vorherigen ASNVersionen werden die Constraints nicht in den Attributen der Objekte (nicht in den Merkmalslots), sondern separat gespeichert. Die neue Datenstruktur erlaubt, dass ein Attributwert in mehrere Constraints einbezogen werden kann. Des Weiteren kann in jedem Constraint für jeden beteiligten Merkmalwert festgelegt werden, ob er dort als Vorgabe oder als zu berechnende Größe benutzt wird. x Auch die aktuelle Konzeption des ASN als Plattform der Wissensrepräsentation erlaubt nun eine weitgehende Datenbankunabhängigkeit. Zusätzlich ist die Nutzung des Internets als Transportmedium für Daten und Informationen sowie als Wissensressource möglich. Die Flexibilität der Objektdefinitionen und die Referenzkonzeption des ASNKlassenmodells erlaubt es zudem, Transaktionen bezüglich des ASNweiten Bandbreitenbedarfs wesentlich zu optimieren und ist in einem prototypischen ASN realisiert worden. Repräsentation der Semantik von Produktdaten Für die Repräsentation der Semantik von Produktdaten wurden bereits verschiedene Ansätze entwickelt. Für die Weiterentwicklung war das Ziel, Ansätze zu finden, welche die iterative, evolutionäre Arbeitsweise im RPD-Prozess besonders effizient unterstützen können. Hierzu gehört die Handhabung und Nutzung von Defaults und die Bereitstellung der Daten für parametrische Modelle. Das ASN-Datenmodell sollte auch in der Lage sein, unvollständige Produktinformationen zu benutzen und schrittweise im Prozess der Produktentwicklung den Informationsinhalt zu vergrößern und eine feinere Produktbeschreibung zu erlauben. Es wurde untersucht, inwieweit bei der parametrischen Modellierung auch die Zusammenhänge zwischen der Produktentwicklungszeit, der Qualität und den Kosten erfasst werden können. Als Weg zur Lösung dieser Aufgabe wurde die Erweiterung der Datenstrukturen gesehen. Das weiterentwickelte ASNDatenmodell erlaubt verschiedene Konsistenzzustände der ASNWissensbasis zu definieren und zu benutzen und dadurch die Transaktionssicherheit zu unterstützen. In Kombination mit der Benutzung eines Applikation-Servers [4.173] wird gewährleistet, dass sich die ASN-Wissensbasis entweder immer in einem vollständig konsistenten Zustand befindet oder die Datenbasis die notwendige Information enthält, wie ein vollständig konsistenter Zustand erreicht werden kann.

216


Verteiltes Objektmanagement In dezentralen Arbeitsteams, wie sie im RPD üblich und notwendig sind, stehen die Informationen meistens nicht lokal zur Verfügung. Eine verteilte Software-Architektur wurde bereits, wie oben beschrieben, untersucht. Für die Zugriffsgeschwindigkeit auf die notwendigen Daten spielt der physikalische Speicherungsort eine sehr wichtige Rolle. Daten sollen physikalisch dort gespeichert werden, wo sie am häufigsten benutzt werden. Das ASN sollte in der Lage sein, die Benutzerzugriffe auf die Netzobjekte zu registrieren, um diese Information als Basis für die optimierte Auswahl des Speicherungsortes nutzen zu können. Diese Auswahl sollte ursprünglich automatisch getroffen werden. Da die Netzwerke inzwischen wesentlich schneller geworden sind und es möglich ist, von einem Objekt mehrere Kopien zu verwalten und benutzen zu können, wird die Auswahl des physikalischen Speicherungsortes dem Benutzer überlassen. Die aktuelle ASN-Version wurde vollständig auf der Basis von Enterprise Java Beans (EJBs) implementiert. Auf dieser Basis ist die Entwicklung von Systemen mit verteilten Komponenten gegenüber früher viel einfacher geworden als mit CORBA, DCOM oder Java RMI direkt gearbeitet wurde [4.175]. Auf der Basis von EJBs ist es möglich, auch die Aufgaben der zu entwickelnden Caching-Mechanismen zu lösen [4.175]. Der benutzte ApplikationsServer ist in der Lage, mögliche Datenverluste durch Systemausfälle abzufangen. Informationsaustausch, Kommunikation, Dokumentation Der dritte wichtige Aufgabenbereich innerhalb der Entwicklung einer zentralen Datenhaltung besteht darin, den fortlaufenden Informationsaustausch und die Kommunikation zu allen Wissensdomänen aufrechtzuerhalten und weiter zu entwickeln. Das ASN stellt die zentrale Integrationskomponente innerhalb der schnellen Produktentwicklung dar. Die Koordination bei der Festlegung der Aufgaben und die Kommunikation während der Bearbeitung der ASN-Objekte sind eine notwendige Voraussetzung für eine erfolgreiche Realisierung der RPD-Projekte. Zu lösende Aufgaben sind nicht nur die Bereitstellung des Datenmodells, sondern auch die Bereitstellung von Methoden für die Benutzung der gemeinsamen Datenbasis. Eine besondere Rolle spielt dabei die Client-Software, die es erlaubt, durch benutzerspezifische Programme auf alle Objekte der ASN-Datenbasis zuzugreifen, sie zu erstellen, zu löschen und zu ändern. Zur Flexibilisierung der ASN-Zugriffe wurde eine Middleware entwickelt, die auf den ASN aufsetzt und dabei zusätzliche Funktionalität den RPD-Nutzern bzw. RPDAnwendungen zur Verfügung stellt (Kap. 4.2 „Agentenbasierte Middlewa-


217

re als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“). Für die Überprüfung und Bearbeitung sämtlicher Daten in der ASN-Datenbank wurden leistungsfähige Formulare entworfen und entwickelt. Mit diesen Formularen können auch Nichtprogrammierer die ASN-Datenbank effektiv benutzen. Repräsentation der Semantik von Produktdaten Das bisherige ASN-Datenmodell wurde weiterentwickelt. In die aktuelle Version wurden mehrere neue Ansätze aus dem „Unified Relational Datamodell“ (im Weiteren URDM) übernommen. Die Grundidee wurde bereits in [4.174] beschrieben und im Rahmen der Forschungsarbeiten am Institut für Rechnergestützte Ingenieursysteme (IRIS) systematisch untersucht [4.134], [4.166], [4.161], [4.162], [4.135], [4.169] und weiterentwickelt. Es ist das Hauptziel der URDM-Konzeption, bzw. der Unified Data Modell Konzeption (im Weiteren UDM), Datenbanken mit einem sehr komplexen Design ohne Informationsverlust in Datenbanken mit sehr einfachem Design umzuwandeln. Eine solche Umwandlung ist reversibel und kann für die Tabellen einer relationalen Datenbank genauso wie für die Klassen einer objektorientierten Datenbank angewendet werden. Jede komplexe relationale Datenbank kann in die URDM-Form überführt werden. Somit stellt das URDM ein direkt verwendbares Datenmodell, wie auch ein Metamodell dar. Ein Teil der Design-Information einer komplexen konventionell strukturierten Datenbank (also die Metadaten) wird in der Datenebene des URDM bzw. UDM abgebildet. Die Beschreibung der Grundidee (diese Aussagen gelten für die Tabellen der relationalen Datenbanksysteme (RDBS) und auch für die Klassen der objektorientierten Datenbanksysteme (OODBS)) ist folgende: Gegeben sei eine Menge von objektartspezifischen Tabellen im RDBS-Kontext oder Klassen im OODBS-Kontext mit verschiedenen Datenfeldern/Attributen. Alle diese Tabellen/Klassen werden im URD in einer Tabelle/Klasse mit dem Namen „Attributes“ abgebildet, die mindestens 3 Datenfelder/Attribute enthält: Objekt_ID (bzw. eindeutiger Name), Merkmal (Merkmalname oder ID) und Merkmalwert. Als weitere Datenfelder der Klasse „Attribute“ wurden noch als "Metadaten" die Attribute „Status“, „von“ und „bis“ („von“ und „bis“ für die zeitliche Gültigkeit) zusätzlich eingeführt. Alle Objekte werden in der Tabelle „Objekte“ bzw. in der objektorientierten ASN-Implementierung als Instanzen der Klasse „Concepts“ erfasst. Die Tabelle „Objekte“, hat genauso wie die entsprechende Klasse „Concepts“, mindestens die Attribute „Objekt_ID“ (bzw. einen eindeutigen Objektnamen), "Objektart" und zusätzlich für die Verwaltungszwecke die Felder (Attribute) „Status“, „von“ und „bis“. Zwischen

218


den Tabellen in relationalen Datenbanken und den Klassen in den OODBS existieren verschiedene Beziehungen. Im Datenbankdesign wird festgelegt und beschrieben, welche Beziehungen zwischen den Objekten verschiedener Tabellen oder Klassen vorgesehen und möglich sind. Im URDM werden die tatsächlich existierenden Beziehungen auf der Instanzebene in der Tabelle „Netz“ gespeichert. Die Tabelle „Netz“ enthält mindestens 4 Datenfelder: „Objekt“, „Beziehungsart“, „Verbundenes Objekt“ und „Beziehungsdetail“. Für Verwaltungszwecke ist es sinnvoll, die Tabelle „Netz“ noch um die Datenfelder „Status“, „von“ und „bis“ zu ergänzen. Bei der objektorientierten Implementierung des ASN-Datenmodells wurde als Gegenstück zur Tabelle „Netz“ nicht eine Klasse „Netz“ gebildet, sondern die Klasse „RelationConBeans“ erzeugt, deren Methoden den Zugang zur gleichen Information und die Handhabung der gleichen Information, wie die Tabelle „Netz“, erlauben. Der Vergleich zwischen klassischem und UDM-Design ist aus den Abb. 4.7 und 4.9 einerseits und aus den Abb. 4.8 und 4.10 andererseits zu entnehmen. Die Abb. 4.7 zeigt das klassische Design einer Testdatenbank. In der Abb. 4.9 wurde das URDM-Design dargestellt. Die Tabellen „Objects“, „Attributes“ und „Net“ wären für die Benutzung der Datenbank ausreichend. Es ist jedoch sinnvoll, die vorgesehenen Objektarten, Beziehungsarten und Merkmalarten in separaten Tabellen zu erfassen. Dadurch kann gewährleistet werden, dass nur solche Objektarten, Beziehungsarten und Merkmalarten benutzt werden, die zuerst anhand der Analyse der RPD-Prozesse zugelassen und in den Zusatztabellen eingetragen wurden. Die Abb. 4.8 zeigt das ASN-Klassendiagramm. In der Abb. 4.10 wurde das ASN-Klassendiagramm in der UDM-Repräsentation dargestellt. Die ASN-Klassendiagramme sind sehr komplex und enthalten mehr als 100 Klassen. Das ASN-Klassendiagramm kann sich während der Abarbeitung des Produktentstehungsprozesses ändern, so dass die Abbildung des ASN-Klassenmodells dynamisch erfolgen muss. Weitere Steigerung der Komplexität des Datenmodells ist zu erwarten. Bei der Benutzung von UDM-Repräsentation ist die Integration von neuen Objektarten, Beziehungsarten und Merkmalarten jederzeit ohne Änderung des Datenbankdesigns und ohne Programmierung von neuen Klassen möglich.


Abb. 4.7. Beispiel für das klassische Datenbankdesign

219

220


Abb. 4.8. Ausschnitt aus dem ASN-Klassenmodell


221

Abb. 4.9. Vereinfachte Darstellung der ASN-Datenbank in der UDMRepräsentation (ohne Constraints)

Abb. 4.10. ASN-Klassenmodell (vereinfacht) in der UDM-Repräsentation

222


Verteiltes Objektmanagement Die ASN-Wissensbasis besteht aus der ASN-Datenbank, EJBs und ClientSoftware und schließlich aus einer Ansammlung von anwendungsspezifischen, in der Datenbank nur referenzierten Objekten. Die Objekte sind z. B. Betriebssystemdateien, die im Netzwerk oder verschiedene ftpObjekte, die im Internet verteilt sind. Die in der Datenbank referenzierten Objekte werden in eine passende Objektart eingeordnet und mit den im ASN-Kontext notwendigen Attributen ausgestattet. Somit existieren sie in der Datenbank als Instanzen der Klasse „Concepts“, deren Attribute Instanzen der Klasse „Attributes“ sind. Für die Erfassung der Speicherungsorte der referenzierten Objekte wurde im ASN die Klasse „Pfad“ angelegt. Ein referenziertes Objekt kann außerhalb der ASN-Datenbank in beliebig vielen Kopien, mit frei wählbarem Ort im Netzwerk, oder im Internet existieren. Alle Kopien der referenzierten Objekte und deren Speicherungsorte werden in den Instanzen der Klasse „Pfad“ erfasst. Allerdings darf nur eine Kopie den Masterstatus haben. Nur die Merkmale dieser Kopie werden in der ASN-Datenbasis erfasst. Wenn an einer anderen Kopie wesentliche Änderungen durchgeführt wurden, muss die Masterkopie mit einer solchen Kopie synchronisiert werden. Als Alternative zur Synchronisierung (diese Entscheidung kann nur der Benutzer treffen) kann die geänderte Kopie, die zuerst keinen Masterstatus hat, als ein selbständig referenziertes Objekt in der ASN-Datenbasis deklariert werden. Sie bekommt einen neuen Namen, in der Klasse „Pfad“ eine neue Instanz mit dem Masterstatus und durch die Beziehungen wird registriert, dass es sich um eine neue Version des vorher bearbeiteten Objekts handelt. Die Beziehung „A ist Version von B...“ kann zusätzlich auch durch die festgelegte Namenskonvention berücksichtigt werden (z. B. Objektname_V1 usw.). Es ist selbstverständlich, dass die referenzierten Objekte und deren Kopien dort gespeichert werden, wo man sie direkt braucht. Die hier beschriebene Handhabung der referenzierten Objekte bezieht sich nur auf einen Aspekt der Problematik „verteilte Wissensbasis“. Ein anderer Aspekt läge darin, mit verteilter Datenbasis oder mit mehreren Replikas einer Datenbank zu arbeiten. Die aktuelle Version arbeitet im Hintergrund mit einer MySQL-Datenbank oder auch einer anderer Datenbank, die physikalisch an einem Ort gespeichert ist. Die ASNImplementierung mit EJBs und Application-Server erlaubt es, auch auf mehrere Datenbanken zuzugreifen, die physikalisch an verschiedenen Orten gespeichert sind. In der UDM-kompatiblen Sicht der ASN-Datenbasis können alle Klasseninstanzen mit Änderungsdatum ausgestattet werden. Damit ist eine mögliche Voraussetzung vorhanden, mehrere Replikas der ASN-Datenbasen automatisch zu synchronisieren. Bei widersprüchlichen


223

Daten in den Replikas können die Instanzen neueren Datums übernommen werden. Eine wichtige Voraussetzung für diese Vorgehensweise ist die Koordination und ständige Kooperation zwischen den Benutzern der Datenbasis. Die ASN-Implementierung auf der Basis von EJBs erlaubt es, auch über einen anderen Weg die Zugriffe auf die Datenbasis zu beschleunigen. Der vorgesehene Weg ist das Applications-Server-Clustering. Bei dieser Lösung arbeiten mehrere Applications-Server parallel [4.175]. Wenn nur mit einer Datenbasis gearbeitet wird, muss entsprechend der Verteilung der Benutzer im Netzwerk optimal gewählt werden. Informationsaustausch, Kommunikation, Dokumentation Der Informationsaustausch und die Kommunikation zwischen den RPDNutzern und ihrer Anwendungen wurde durchgehend praktiziert. Dies war eine wichtige Voraussetzung für den Aufbau und die Weiterentwicklung des ASN-Datenmodells in der Form, dass man die Daten aller RPDDomänen in das ASN übernehmen und verwalten kann. 4.1.6 Ergebnisse und ihre Bedeutung Die wesentlichen Vorteile der dritten Entwicklungsstufe liegen in der Umsetzung der Anforderungen der Teilprojekte durch die Erweiterung des Datenmodells, die Bereitstellung des EJBs-basierten ASN, der ClientSoftware und der Middleware für den Zugriff auf die Datenbasis (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“). Das auf der Basis von Enterprise Java Beans implementierte objektorientierte ASN-Datenmodell weist folgende Besonderheit auf: Der Benutzer kann weiter mit dem in den früheren Versionen festgelegten klassischen Klassenmodell arbeiten. In diesem Modell existieren Klassen, wie z. B. Personen, Projekte, Prototypen und Klassen für verschiedene Objektarten, die bereits mit allen notwendigen Attributen ausgestattet wurden. Diese Attribute können weiter benutzt werden. Die Benutzung des klassischen Klassenmodells ist vorteilhaft bei der Erzeugung der Objekte mit deren spezifischen, immer vorhandenen Default-Merkmalen. Die dadurch entstandenen Daten können jedoch auch durch die Methoden der an das UDM angelehnten Klassen „Concepts“, „Attributes“ und „RelationConBeans“ selektiert und bearbeitet werden. Es werden auf der Basis der ClientSoftware de facto zwei Repräsentationen der ASN-Datenbasis angeboten und unterstützt. Die UDM-kompatible Repräsentation der Datenbasis erlaubt es, sehr unterschiedliche Objektarten, Merkmalarten und Bezie-

224


hungsarten zwischen den Objekten auf gleiche Art zu handhaben. Dadurch können die Abfragen und die Auswertungen der ASN-Daten sehr erleichtert werden. Repräsentation der Semantik von Produktdaten Benutzung von Defaults Defaults (Voreinstellungswerte) sind Standard-Annahmen, die solange getroffen werden, bis detaillierte Informationen vorhanden sind. Die DefaultDaten sind in den bereits vorhandenen ASN-Objekten, in deren Dualbeziehungen und in den Constraints gespeichert. Das ASN-Datenmodell gibt die Voraussetzungen dafür, dass diese Daten jederzeit auf die dazu geeigneten Objekte übertragbar sind. Alle in der ASN-Wissensbasis bereits vorhandenen Daten können den Objekten als Defaults (Voreinstellungswerte) zugewiesen werden. In der jetzigen ASN-Version gibt es verschiedene Arten von Defaults, wie z. B. Formeln, Constraints, Ansammlungen von Merkmalen und Merkmalwerten, Teilnetze der Beziehungen zwischen den Objekten, Auswahllisten für Merkmalwerte, Defaultadressen für die Speicherung der externen Objekte, die zulässigen Kombinationen der Ereignisse, Bedingungen und Aktionen und andere. Alle in den alten Projekten gesammelten Informationen können als Default-Daten für neue Projekte verwendet werden. Welche Daten bei neuen Objekten (z.B. bei neuen Projekten) tatsächlich als Defaults verwendet werden, kann nicht pauschal vorausgesagt werden. Als Grundlage für diese Auswahl wird der Ähnlichkeitsgrad bzw. die semantische Distanz zwischen dem neuen Objekt und den vorhandenen Objekten benutzt. Da in der Entwurfsphase die vollständige Information über die neuen Objekte meist fehlt, kann der Ähnlichkeitsgrad nur aus den Anforderungen an das neue Objekt abgeleitet werden. Parametrische Modellierung von RPD-Wissen Im ASN können als Produktmerkmale Parameterlisten angelegt werden. Diese Datenlisten können für die automatische Erzeugung der abgeleiteten Objekte, wie z. B. CAD-Modelle, benutzt werden. Für die Erzeugung der neuen Objekte aus den Parameterdaten sind noch zusätzliche objektartbezogene Anwendungen/Methoden notwendig. Die Merkmalwerte in den Parameterlisten können auch in Constraints verwendet werden. Dadurch sind die Voraussetzungen gegeben, die es ermöglichen, vor der Neuerstellung der CAD-Modelle von den Vorgabegrößen die abgeleiteten Größen zu berechnen und die Optimierungsberechnungen durchzuführen. Genauso ist es möglich, empirische Erfahrungen in Formeln zu beschreiben und durch die Benutzung von interdisziplinären Constraints Zusammenhänge zwischen


225

Funktionalität, Kosten und Qualität von Prototypen zu erfassen. Durch die Trennung der Merkmalwerte und Constraintsbeschreibungen in der ASNDatenstruktur ist es möglich, auch beliebig komplexe Zusammenhänge des RPD-Wissens zu parametrisieren. Zur symbolischen Repräsentation parametrischer Werte werden die von den Constraints separat gespeicherten Formeln benutzt. In einer Constraintsbedingung können je nach Bedarf wahlweise verschiedene Formeln, welche die gleiche Syntax haben, verwendet werden. Die Berechnung der abgeleiteten Größen aus den Vorgabegrößen kann optional von den Constraints, die Bestandteil der ASNDatenbasis sind, auch in die externen Anwendungen für die Erzeugung von neuen Objekten verlegt werden. Der jetzige Ansatz für die Parametrisierung des ASN-Wissens erlaubt die Parametrisierung sehr flexibel zu handhaben und entspricht allen vorgesehenen Anforderungen. Verteilung von Daten Die ASN-Wissensbasis enthält in der ASN-Datenbasis Referenzen auf externe Objekte, wie z. B. CAD-Modelle, NC-Programme, FEM-Berechnungen, Dokumentationen der Produkte usw. Von jedem referenzierten Objekt können mehrere Kopien erstellt und an verschiedenen Stellen im Netzwerk oder im Internet gespeichert werden. Dies ist eine wichtige Voraussetzung für die optimierte Datenhaltung. In der ASN-Datenbasis wird in den Instanzen der Klasse „Pfad“ pro Kopie folgende Information gespeichert: Objektname, Pfad, Status und vollständiger Dateiname. Von den Kopien darf nur eine Kopie den Masterstatus haben. Nur die Inhalte der Kopie mit Masterstatus sind garantiert korrekt und werden für die Datenauswertungen verwendet. Die sonstigen Kopien, die keinen Masterstatus besitzen, können beliebig geändert und bearbeitet werden. Wenn die Bearbeitung einen bestimmten Stand erreicht hat (z.B. aus dem vorhandenen CAD-Modell wurde eine neue Version erstellt), können die modifizierten Kopien auch als neue Objekte mit einem neuen Namen in der ASNWissensbasis eingetragen werden. Diese neuen Objekte bekommen auch einen neuen Eintrag als Instanz der Klasse „Pfad“ und den Masterstatus. Danach können wieder Kopien ohne Masterstatus erstellt werden. Caching Mechanismen Die Caching-Mechanismen wurden in Betracht gezogen, um die Zugriffe auf die Daten in der ASN-Wissensbasis zu beschleunigen. Die ASNDatenstrukturen wurden so konzipiert, dass man das Benutzerverhalten auf verschiedene Weise registrieren kann. Die Entwicklung der dafür notwendigen Methoden ist in einem weiteren Entwicklungsschritt in Kooperation mit der Entwicklung der Adaptiven Benutzungsoberflächen (Kap. 4.4 „Adaptive Benutzungsoberflächen“) vorgesehen. Die dadurch gewonnene

226


Information kann als Grundlage genutzt werden, um die notwendigen Caching-Maßnahmen abzuleiten. Diese Aufgabe kann jedoch anders und einfacher durch ein Applications-Server-Clustering gelöst werden [4.175]. Das Clustering erlaubt es, mehrere Rechner parallel zu nutzen, wodurch die Anfragelast an das ASN automatisch optimal verteilt wird und die Zugriffe auf das ASN beschleunigt werden. Ein wesentlicher Vorteil dieser Vorgehensweise liegt darin, dass die Lastenverteilung der aktuellen Belastung entspricht und somit realistischer gehandhabt wird als bei Maßnahmen, die nur aus den Erfahrungswerten abgeleitet werden. Deswegen wird das Server-Clustering als Lösung bevorzugt. Transaktionen und Datensicherheit Die ASN-Wissensbasis besteht aus der ASN-Datenbasis, aus der Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“), die das Datenmanagementsystem und andere Funktionalitäten realisiert und aus der Menge der externen, referenzierten Objekte (s. Abb. 4.11.). Einige RPD-Objekte wie z. B. Projekte, Personen u. a. sind voll in der Datenbasis beschrieben, andere Objekte (z. B. CAD-Modelle) sind nur in den externen Dateien vollständig beschrieben und in der Datenbasis nur referenziert. Nur ein Teil der Objektmerkmale, die im ASN-Kontext relevant sind, werden als Merkmale in der Datenbasis erfasst. Die Merkmale eines oder mehrerer Objekte können durch Constraints miteinander gekoppelt werden. Für die Transaktions- und Datensicherheit wurde eine Konzeption ausgearbeitet, die verschiedene Konsistenzzustände der Wissensbasis unterscheidet. Die Idee mit mehreren Konsistenzzuständen einer Datenbank zu arbeiten wurde bereits in der Fachliteratur beschrieben [4.86]. Für die ASN-Implementierung war es notwendig, alle denkbaren Zustände der Objekte und deren Attribute systematisch zu untersuchen und deren Abbildung in die Statusmerkmalwerte festzulegen. x Konsistenzzustand 1: Die Daten in der Datenbasis sind vollständig und widerspruchsfrei. Die in der Datenbasis enthaltenen Objektmerkmale erfüllen alle Constraintsbedingungen. Die in der Datenbasis enthaltenen Objektmerkmale entsprechen den Merkmalwerten in den referenzierten Dateien (Beispiel – die Produktmerkmale Volumen oder Oberfläche entsprechen den Werten im CAD-Modell). Umgekehrt entsprechen auch die Eigenschaften der referenzierten Dateien (z.B. CAD-Modelle) den Vorgaben in der Datenbasis. x Konsistenzzustand 2: Die ASN-Wissensbasis ist nicht im Konsistenzzustand 1, aber die Datenbasis enthält die notwendige Information, um den Konsistenzzustand 1 im Bedarfsfall automatisch oder manuell (z.B.


227

Anpassungen der CAD-Modelle) herbeizuführen. Beispiel: Die Merkmalwerte einiger Objekte wurden geändert. Die Berechnung der von den Constraints abhängigen Merkmale kann z. B. durch die Lösung von Gleichungssystemen durchgeführt werden. Die Lösung selbst könnte relativ viel Zeit in Anspruch nehmen und kann als „lange“ Transaktion der Wissensbasis gesehen werden. Um den Konsistenzzustand 2 zu erreichen, werden im ersten Schritt bei den betroffenen Objekten und Objektmerkmalen Statusattribute gesetzt, die zeigen, was und aus welchen Eingabegrößen berechnet werden soll. Das Setzen von Statusmerkmalen kann als eine „kurze“ Transaktion gesehen werden. Ein Systemabsturz bei der Lösung der Gleichungssysteme bedeutet keinen Informationsverlust, da die Statusmerkmale erst nach der vollständigen Durchführung der Berechnungsvorgänge zurückgesetzt werden. Das ASN bleibt auch nach dem Systemabsturz im Konsistenzzustand 2.

Abb. 4.11. ASN-Wissensbasis

x Konsistenzzustand 3: Die ASN-Wissensbasis ist in keinem der Konsistenzzustände 1 oder 2. Die ASN-Benutzer sind jedoch in der Lage, einen der Konsistenzzustände 1 oder 2 herbeizuführen. Auch der Konsi-

228


tenzzustand 3 ist durchaus legitim und im ASN-Betrieb vorgesehen. Bei einem totalen Ausfall der ASN-Datenbasis muss es möglich sein, mit verschiedenen Anwendungen weiter zu arbeiten und die externen, in der Datenbasis referenzierten Dateien, weiterzuentwickeln. Der Übergang zu den Konsistenzzuständen 1 oder 2 muss zum Teil manuell durch den Systembetreuer durchgeführt werden. Wichtig ist, dass beim ASN-Betrieb der Konsistenzzustand 2 aus dem Zustand 3 durch kurze Transaktionen erreicht werden kann. Die Zustandsübergänge können mit Hilfe der Implementierung von ECA-Regeln, mit dem TransaktionsAgenten oder manuell (durch Formularereignisse) angestoßen werden. Die detaillierte Beschreibung der implementierungsunabhängigen ASNTransaktionssicherheit wird in [4.168] publiziert. Ein besonderer Beitrag zur Transaktionssicherheit wird vom Applikations-Server geleistet. Der Server ist in der Lage, nach dem Absturz und nach dem Neustart des Systems die auf der Ebene der Java-Beans ablaufenden Transaktionen fortzusetzen. Somit ist die Absicherung von kurzen Transaktionen durch den Applikations-Server gewährleistet. Die ASN-Datenbasis stellt das „Herzstück“ des ASN dar. Alle Instanzen der Klassen „Concepts“ (Objekte), „Attributes“ (Merkmale) und „Relations“ (Beziehungen) wurden mit den Zeitattributen „von“ und „bis“ ausgestattet. Es wäre denkbar, bei jeder Änderung in der Datenbasis den alten Zustand der Objekte und Datensätze mit den Zeitattributen in einer separaten Datenbasis zu speichern und bei den geänderten Objekten und Datensätzen die Zeitattribute anzupassen. Auf diese Weise könnte ein permanentes, partielles Backup der Datenbasis durchgeführt werden. Allerdings müssten dann im Falle einer Änderung der Objekte in der aktuellen Datenbasis die Attribute „von“ und „bis“ und bei den Daten in der „Backup“Datenbasis das Attribut „bis“ geändert werden. Diese Technik wird momentan im ASN nicht benutzt, aber sie stellt einen interessanten Aspekt einer Sicherheitsphilosophie dar. Referenzierte externe Dateien und Applikationen Die Änderungen von referenzierten, externen Dateien (s. Abb. 4.11.), wie z.B. CAD-Modelle, werden von externen Applikationen (Catia, MS Excel) durchgeführt. Solche Änderungen können als „lange“ Transaktionen der Wissensbasis, aber nicht als Transaktionen der Datenbasis betrachtet werden. Sie erfüllen im Sinne von ACID nicht die Atomaritätsbedingung. Die bearbeiteten Zwischenstufen können als Versionen gespeichert werden. Für jede Version einer externen Datei kann ein Objekt mit passenden Merkmalen in der Datenbasis erstellt und zugewiesen werden. Für die automatische Anpassung der Merkmalwerte in der Datenbasis und in den ex-


229

ternen, referenzierten Dateien müssen anwendungsspezifische Programme entwickelt werden. Der Anpassungsvorgang entspricht dem Übergang von Konsistenzzustand 2 oder 3 in den Konsistenzzustand 1. Unsicheres und unpräzises Wissen Zu den wichtigsten Eigenschaften des ASN-Datenmodells gehört die Möglichkeit, den Objekten beliebige Merkmale zuzuweisen oder wegzunehmen. Hier werden die Grenzen des alten Klassenmodels (wonach jede Klasse nur eine feste, begrenzte Anzahl an Attributen besitzt) aufgehoben. Das Fehlen eines Merkmals (z.B. bei einem Objekt der Objektart Quader fehlt das Merkmal „Länge“) stellt eine Möglichkeit dar, die Unsicherheit bzw. das Fehlen des Wissens in der Datenbasis abzubilden. Dieses Wissensdefizit kann durch Abfragen im ASN festgestellt werden. Für die Handhabung unpräzisen Wissens wurden im erweiterten Datenmodell für die Merkmalwerte Toleranzgrenzen vorgesehen. Eine oder beide Toleranzgrenzen können einem Objekt als Zusatzmerkmale zugewiesen werden. Das Modell ist in der Lage zu beschreiben, dass die Werte eines Merkmals aus einer Wertliste übernommen werden können. Bei der Handhabung von Auswahloptionen kann auch unsicheres Wissen berücksichtigt werden. Als weitere Möglichkeit, unsicheres Wissen zu beschreiben, können Wahrscheinlichkeiten für die Merkmalwerte benutzt werden. Das Datenmodell wäre in der Lage, auch statistische Verteilungen für Merkmalwerte zu integrieren. Die praktische Nutzung dieser Funktionalität ist erst im Bedarfsfall für die folgende Forschungsperiode vorgesehen. Die Handhabung von Constraints Die neuen Datenstrukturen für die Constraintsbeschreibung weisen folgende besondere Merkmale auf: x Die Formeln werden nur einmal gespeichert (s. Instanzen der Klasse „Formulas“) und eventuell mehrmals benutzt. x Die Formeln und Constraints werden separat gespeichert, in der Beschreibung von Constraints werden die Formeln nur referenziert (s. Instanzen der Klasse „ConstrFormeln“). Eine Constraints-Bedingung kann wahlweise verschiedene Formeln, welche die gleiche Argumentanzahl und Argumentart haben, verwenden. x Ein Merkmalwert kann in mehreren Constraints, optional als Eingabegröße oder als berechnete Größe, benutzt werden. Was vorgegeben ist und was berechnet werden muss, kann der ASN-Anwender frei festlegen. Die Bedeutung dieser Funktionalität ist aus der Abb. 4.12 ersichtlich. Diese Information und die Zuweisung der Merkmale zu Variablen

230

x x

x

x


der benutzten Formeln wird in den Instanzen der Klasse „ConstrRelation“ gespeichert. Die Constraints können wahlweise aktiviert oder deaktiviert werden. Es ist vorgesehen, die in den Constraints enthaltenen Informationen an die externen Anwendungen, wie z.B. Maple [4.78], [4.133], [4.201] weiterzugeben. In den Anwendungen werden aus den Constraintsbedingungen abgeleitete Gleichungssysteme oder auch Ungleichungssysteme gelöst und die Rechenergebnisse an das ASN weitergegeben. Einfache Berechnungen in der Form a=f(x1,x2...xn), mit bekannten Parameterwerten x1, x2,...xn können direkt im ASN, mit Hilfe eines Formelinterpreters durchgeführt werden. Durch die Constraints können verschiedene Merkmalwerte von verschiedenen Objekten gekoppelt werden.

Die Abb. 4.12 zeigt in vereinfachter Form die Datenstrukturen für die Erfassung von Constraints. In der Abb. 4.13 sind die Constraints als geschlossene Schleifen dargestellt. Das Merkmal Nr. 706 des Objekts O4 wurde im Constraint Nr. 604 als berechnete Größe, im Constraint Nr. 607 jedoch als Eingabegröße benutzt. Die Übertragung der Änderungen zwischen den Objekten ist dadurch bestimmt, welche Merkmale in den Constraints als Eingabegröße und welche als berechnete Größe festgelegt wurden. Die Festlegung des Merkmals Nr. 700 im Objekt O4 als berechnete Größe hätte die Verbreitung von Merkmaländerungen vom Objekt O5 zum Objekt O2 zur Folge.

Abb. 4.12. Datenstrukturen für die Erfassung von Formeln und Constraints


231

Abb. 4.13. Beispiel für die Verbreitung der Änderungen im ASN durch Constraints

232


ASN-Clientsoftware Einer der wichtigsten Software-Bausteine im ASN ist die Client-Software. Die Methoden der Client-Klasse werden als gemeinsame Programmschnittstelle für alle ASN-Softwareentwickler benutzt. Die Benutzung der Client-Software ermöglicht es, die ASN-Programmentwicklungen unabhängig von im Hintergrund benutztem Datenbanksystem durchzuführen. Die Programmierer und ASN-Benutzer können arbeiten, ohne den Speicherort der ASN-Datenbasis explizit zu kennen. Als Voraussetzung für die Bereitstellung der Client-Software wurden zuerst alle notwendigen Methoden für die Entity-Java Beans, Home- und Remote-Interfaces und für die Sessions-Beans entwickelt (s. Abb. 4.14.).

Abb. 4.14. EJB-basierter Zugriff auf die ASN-Databasis

Bereitstellung der Formulare für die Bearbeitung von ASNDaten Für Testzwecke und auch für die praktische Benutzung der ASNDatenbasis sind verschiedene GUI-Formulare sehr nützlich. Diese Administrationsoberflächen wurden entwickelt, um auch den Nichtprogrammierern zu erlauben, die ASN-Datenbasis zu nutzen. Der Übergang


233

von Konsistenzzustand 3 in höhere Konsistenzzustände kann u.a. mit Hilfe der Dateneingabe und Änderungen in Formularen durchgeführt werden. Verfeinerung der Sperrmechanismen In den früheren ASN-Versionen konnten die Sperren nur auf ganze Objekte gesetzt werden. In der aktuellen Version besitzen nicht nur die Objekte, sondern auch deren Merkmale ein Statusattribut. Dadurch ist es möglich, selektiv einzelne Objektmerkmale zu sperren bzw. freizugeben. Diese Funktionalität wurde als eine von mehreren vorgesehenen Maßnahmen für die Steigerung der Möglichkeiten für parallele Bearbeitung der Objekte entwickelt. Die Bedeutung der UDM-Repräsentation für die Datensuche und Datenauswertung Eine besondere Bedeutung besitzt die UDM-Repräsentation des Datenmodells für alle Dataretrieval-Vorgänge. Im UDM-Modell werden alle Objektarten des klassischen Datenmodells auf gleiche Art behandelt. Das Gleiche gilt auch für alle Beziehungsarten und Merkmalarten, die im klassischen Datenmodell benutzt wurden. Durch die kombinierte Benutzung von nur vier Grundabfragearten können nahezu alle (Ausnahme – z.B. die constraintsbasierte Suche) im ASN-Kontext wichtigen Suchvorgänge durchgeführt werden. x „Suche alle Objekte mit Merkmal X“ – das Vorhandensein des Merkmals „X“ wird geprüft, x „Suche alle Objekte mit Merkmal X und Merkmalwert XW“ – ein Merkmal und Merkmalwert werden geprüft, x „Suche alle Objekte vorgegebener Art“ z. B. Person, Projekt, Prototyp usw. x „Suche alle Knotenpunkte im Netz, mit denen das Objekt A durch eine vorgegebene Menge von Beziehungsarten verknüpft ist“ – z.B. {„ist ähnlich“; „ist abgeleitet“; „ist abhängig“...}. Für diese Grundabfragearten wurden entsprechende Suchmethoden entwickelt. Diese Methoden sind unabhängig von Objektart, Merkmalart und Beziehungsart. Sie benutzen jedoch Objektarten, Merkmale, Merkmalwerte und festgelegte Mengen von Beziehungsarten als Parameter in der Kriterienbeschreibung für die Abfragen.

234


Verteiltes Objektmanagement Das ASN-Datenmodell erlaubt es, Objekte, die außerhalb der ASNDatenbank existieren und mit externen Anwendungen erzeugt und bearbeitet werden, in der ASN-Datenbank mit allen relevanten Merkmalen zu erfassen und zu verwalten. Die ASN-Implementierung auf der Basis von EJBs gibt im Prinzip auch die Möglichkeit, mit physikalisch verteilten Datenbanken zu arbeiten. Bestimmte notwendige Voraussetzungen für die automatische Synchronisierung sind im Datenmodell vorgesehen. Damit ist die Grundlage für ein verteiltes Objektmanagement gelegt. Integrationsplattform Das ASN-Datenmodell und die Implementierung auf der Basis von EJBs ist das Ergebnis einer gründlichen Auswertung aller Anforderungen, Anregungen und auch kritischen Aussagen zu Ergebnissen der ersten Entwicklungsstufen. Die Entwicklung des ASN und der RPD-Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“) hat dazu beigetragen, dass das ASN heute als gemeinsame Integrationsplattform zur Verfügung steht. Die wichtigsten Grundideen und auch die Anwendungsanleitung wurden schriftlich dokumentiert und stehen allen Teilbereichen zur Verfügung. 4.1.7 Zusammenfassung der Ergebnisse ASN-Datenmodell Das ASN-Datenmodell wurde weiterentwickelt und auf der Basis von EJBs implementiert. Bereits im Verlauf der zweiten Entwicklungsstufe wurde eine detaillierte Analyse der ASN-Objektarten und deren Beziehungen durchgeführt und die Ergebnisse in UML-Klassendiagrammen abgebildet. Diese klassische Darstellung des Datenbankdesigns wurde als Arbeitsbasis auch in der dritten Entwicklungsstufe benutzt und auf der Basis von Enterprise Java Beans implementiert. Aber bei der EJBImplementierung wurde auch die UDM-Sicht der Datenbasis voll berücksichtigt und für diese Sicht notwendige Klassen und Methoden entwickelt. Im Unterschied zu relationalen Datenbanken, bei denen man entweder das klassische oder das URDM-Datenbankdesign benutzen kann (eine DesignForm kann in die andere reversible transformiert werden), stehen dem ASN-Benutzer, bei der Benutzung einer Datenbank zum ersten Mal, beide


235

Sichten auf die Daten gleichzeitig zur Verfügung. Der Benutzer kann, wenn er will, weiter die Klassen aus dem klassischen Datenmodell benutzen, um z.B. Objekte anzulegen, Merkmalwerte festzulegen, Beziehungen aufzubauen usw. Die UDM-Repräsentation der Datenbanken öffnet dem Benutzer damit ganz neue Möglichkeiten. Erst im UDM ist es möglich, die Zugehörigkeit der Objekte zu Klassen des klassischen DB-Designs abzufragen und als unsicheres Wissen in Abfragen zu handhaben. Die Objekte können eine unbegrenzte Anzahl an Attributen erhalten, sogar nachträglich und auch solche Attribute, die im klassischen Klassenmodell nicht vorgesehen waren. Es ist möglich, neue Objektarten, Beziehungsarten und Merkmale anzulegen, ohne neue Klassen zu programmieren, denn die Klassen des UDM-Modells stellen eine sehr offene Datenstruktur dar. In der UDM-Repräsentation werden alle Objektarten des klassischen Datenmodells auf gleiche Art behandelt. Das Gleiche gilt auch für alle Beziehungsarten und Merkmalarten, die im klassischen Datenmodell benutzt wurden. Dadurch wird im Vergleich zur klassischen Datenbankrepräsentation die Vielfalt der notwendigen Abfragen wesentlich reduziert [4.161], [4.162]. Die neue Modellierung von Constraints wurde von der UDMRepräsentation abgeleitet. Im Unterschied zu Dualbeziehungen zwischen den Objekten, die in der Tabelle „Netz“ bzw. in den Instanzen der Klasse „RelationConBeans“ beschrieben sind, stellen die Constraints Mehrfachbeziehungen dar. Für die Unterstützung von constraintsbasierten Suchabfragen (suche alle Objekte und deren Merkmale, die durch die Änderung des Merkmals „M“ bei dem Objekt „A“ geändert werden...) wurden spezielle Suchmethoden entwickelt. Repräsentation der Semantik von Produktdaten Für das RPD wird als Basis für die RPD-Modellierung das Aktive Semantische Netz benutzt. Die EJBs-basierte ASN-Implementierung erlaubt das klassische Datenbankdesign genauso wie das Unified Data Model-Design zu benutzen. Die besonderen Vorteile der UDM-Sicht liegen beim Dataretrieval, bei den Datenauswertungen und bei der Handhabung und Beschreibung von Constraints. Im RPD wird angestrebt, das sichere und das unsichere Wissen in gleicher Weise zu handhaben. Das Hauptanliegen der vorgesehenen Weiterentwicklung ist ferner die einheitliche Handhabung aller Ereignisarten, Objektarten und Beziehungsarten bei der Anwendung von ECA-Regeln. Die neuen Datenstrukturen für die Beschreibung von Constraints sind eine wichtige Voraussetzung dafür, die speziellen mathe-

236


matischen Systeme in das ASN zu integrieren um komplexe Gleichungssysteme lösen zu können und Optimierungsberechnungen durchzuführen. Verteiltes Objektmanagement In diesem Bereich wurde die Entwicklung von Enterprise Java Beans und von Applikations-Servern beobachtet und bei der ASN-Weiterentwicklung umgesetzt. Somit wird im ASN auch in Zukunft alles Notwendige umgesetzt, was in diesen Entwicklungen bereitgestellt wird. Hier grenzt sich unser Ansatz gegenüber den anderen Benutzern dieser Technologie nicht ab. Die Differenzen zu anderen liegen in den Möglichkeiten des ASNDatenmodells. Bei der Synchronisierung von Replikas einer Datenbank werden im Konfliktfall (bei unterschiedlichen Daten in den Replikas) die Daten aus der Masterreplika übernommen. Durch die Benutzung von Zusatzattributen wie „Status“, „von“ und „bis“ erlaubt das ASN-Datenmodell eine viel flexiblere Steuerung der automatischen Synchronisierung. Durch die Benutzung von UDM ist die Zusammenführung von Datenbanken sehr vereinfacht. Das UDM ermöglicht sogar, Datenbanken mit unterschiedlichem Design zusammenzuführen. 4.1.8 Offene Fragen und Ausblick Das ASN-Datenmodell wurde sehr allgemein angelegt und gerade die UDM-Repräsentation lässt einige Modellierungsmöglichkeiten als Optionen offen. Ein Beispiel dafür ist die Zuweisung der Merkmale zu Objekten, die hierarchisch eingeordnet wurden. Zu jedem Knotenpunkt der Hierarchie gehört eine Menge von spezifischen Merkmalen. Durch den Pfad von dem Stammpunkt der Hierarchie zu einem Objekt ist bestimmt, welche Merkmale ein Objekt besitzen soll. Im ASN ist es möglich, „Merkmalträgerobjekte“ zu definieren, deren Aufgabe es ist, nur die Merkmale und Merkmalwerte zu speichern. Solche „Merkmalträgerobjekte“ werden anderen ASN-Objekten zugewiesen. Diese Zuweisung wird mit Hilfe der Dualbeziehung „A enthält Merkmale von B“ beschrieben und kann mit UDMStandardabfragen ausgewertet werden. Im ASN ist auch eine andere interessante Alternative möglich. Die ASN-Implementierung auf der Basis von EJBs erlaubt als Merkmalwerte auch Objekte zu benutzen. Auf diese Weise könnte die aus der Hierarchiezugehörigkeit folgende Merkmalzuweisung auch realisiert werden.


237

Aus den praktischen Erfahrungen mit dem ASN und mit Rücksicht auf die vorgesehene allgemeine Entwicklung im Bereich des RPD, ergeben sich folgende Schwerpunkte für die ASN-Weiterentwicklung: x Steigerung der ASN-Effektivität durch weiterentwickelte Ansätze für parallele Bearbeitung der ASN-Objekte und die Optimierung der Sperrmechanismen. Diese Ansätze stützen sich auf die Steigerung der Granularität der Wissensbasis und die automatische Synchronisierung von parallel bearbeiteten Kopien der bearbeiteten Objekte. x Absicherung der Änderungen der Wissensbasis durch die Festlegung und Anwendung von unterschiedlichen Konsistenzstufen. x Weiterentwicklung des ECA-Ansatzes durch die optimierte Handhabung der kombinatorischen Vielfalt. x Entwicklung von bisher einfachem Constraintsmodelling zu komplexen Constraints und Integration von hochentwickelten Constraintsolvern. x Integration der vom ASN unabhängig laufenden Anwendungen mit Hilfe der Datenschnittstellen, Programmschnittstellen oder durch direkte Kommunikation zwischen der Anwendung und dem ASN. x Effektivere Nutzung der ASN-Wissensbasis, Weiterentwicklung von mächtigen Abfragemechanismen, Dataretrieval mit Hilfe der Ähnlichkeitssuche. x Die Entwicklung von Komponenten zur Informationsstrukturierung für eine internetbasierte ASN-Wissens-Visualisierung und Wissensrepräsentation. Im ASN werden Daten und Informationen vorgehalten und gepflegt. Zusammen mit semantischen Informationen repräsentiert dieser Inhalt die Wissensbasis im RPD. Dieses Wissen wird im laufenden Prozess in das ASN eingebunden. Über diesen Aspekt hinaus werden Prozessstrukturen und Prozessabläufe registriert und stehen für eine Analyse und Visualisierung durch ASN-Anwendungen zur Verfügung. Damit ist es zum einen möglich, Wissen ortsunabhängig und fachübergreifend aufbereitet zur Bearbeitung und zur Information zur Verfügung zu stellen. Zum anderen ist es möglich, Prozesswissen kompakt und konkret weiterzugeben und weiter zu entwickeln. Das ASN stellt somit auf der einen Seite das Netz der Daten und Informationen rund um die RPD-Prozesse, auf der anderen Seite die Unterstützung der automatisierten Aufbereitung des Wissens bereit. Beide Eigenschaften und Funktionsbereiche steigern die Qualität und Geschwindigkeit des Informationsaustausches von Beginn des RPD-Prozesses an. Hochkomplexe Prozessabläufe können durch die Analyse vorangegangener Pro-

238


zesse optimiert werden. Die Beherrschbarkeit von Prozessen höherer Komplexität ist durch die Nachvollziehbarkeit vorangegangener Prozesse mit einem geringeren Aufwand gegeben. Ein weiterer Nutzen des ASN besteht in der fachspezifischen Auswertung der Daten und Informationen und zwar weitgehend unabhängig von Herausgebern und Autoren des Wissens des ASN. Die aus dem URDM abgeleitete offene Datenstruktur der Wissensbasis erlaubt es, beliebige neue Objektarten, Beziehungsarten und Constraints zu integrieren, ohne die Notwendigkeit die ASN-Programme zu ändern. Somit wird der Wissenszuwachs nur in Daten abgebildet, ohne neue Klassen und Methoden (Programme) entwickeln zu müssen.

4.2 Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development

4.2.1 Die Herausforderung: Wissenskommunikation im Rapid Product Development Das Rapid Product Development zeichnet sich unter anderem durch die Integration einer Vielzahl von Experten aus unterschiedlichen Bereichen, wie Konstruktion, Prototypenbau, Kostenrechnung und Projektplanung aus, die in dezentralen Entwicklungsteams zusammengefasst arbeiten [4.124], [4.125], [4.51]. Die einzelnen Experten greifen dabei auf hoch spezialisierte RPD-Anwendungen aus ihrem Fachbereich zurück, die jede für sich betrachtet über ein eigenes Datenmodell und Andockpunkte zur Applikation verfügt. Wie in Kap. 4.1 „Ganzheitliche Modelle zur Repräsentation aktiven Wissens“ angesprochen, wurde als erster Integrationsschritt das Aktive Semantische Netz (ASN) als gemeinsame Datenbasis implementiert [4.65]. Die Experten der unterschiedlichen RPD-Domänen legen ihre Informationen, die für den RPD-Prozess von Bedeutung sind, im ASN ab. Dieses explizite Wissen ist dabei logisch nach den Zusammenhängen zwischen den Wissensbereichen strukturiert. Wodurch das ASN den verteilten Entwicklungsteams eine gemeinsame Grundlage der Datenhaltung zur Verfügung stellt, die alle Wissensdomänen des Produktentstehungsprozesses in einem integrierten Produktmodell repräsentiert und die Voraussetzung für Kommunikations- und Kooperationsmechanismen ist (s. Abb. 4.15.).

4.2 Agentenbasierte Middleware zur Wissenskommunikation im RPD

239

Abb. 4.15. RPD-Wissendomänen

Es hat sich gezeigt, dass neben der reinen Datenhaltung eine Kommunikationsumgebung als Basis für den Informationsaustausch zwischen den prozessbegleitenden RPD-Anwendungen benötigt wird, da diese über kein Wissen der Kommunikationsmöglichkeiten der jeweils anderen RPDAnwendungen verfügen. Die einzige Kommunikationsmöglichkeit ohne Berücksichtigung der im weiteren Verlauf dieses Kapitels vorgestellten RPD-Middleware besteht durch den direkten Informationsaustausch über das ASN. Das ASN erlaubt das Ablegen von strukturierten Informationen und deren semantischen Zusammenhängen in einem objektorientierten Umfeld. Zusätzlich besitzt das ASN eine aktive Komponente in Form eines Regelwerks, um Informationen einer Wissensdomäne in eine andere innerhalb des ASN propagieren zu können. Die Funktionen des ASN sind auf eine datenorientierte Ebene beschränkt. Der Zugriff auf das ASN wird durch eine objektorientierte Programmierschnittstelle ermöglicht. Bei der Anwendung des ASN hat sich jedoch gezeigt, dass diese nahezu auf das Funktionsspektrum traditioneller Datenbanksysteme beschränkt bleibt, solange für die erweiterten Repräsentationskonstrukte keine adäquaten Anfragestrukturen bereitgestellt werden. Somit entsteht die Notwendigkeit eine erweiterte Funktionalität zur Integration der interdisziplinären Anwendungen mit dem ASN, in Form einer RPD-Middleware aufzubauen. Zur effektiveren Ausnutzung der Möglichkeiten des ASN sind erweiterte Zugriffs- und Information-Retrieval-Methoden für die Informationsbeschaffung und -aufbereitung in der RPD-Middleware realisiert worden, die

240


Zugriffe auf ASN-Modelle auf derselben Abstraktionsstufe gestatten, wie sie zur Modellierung von Informationen im ASN verwendet werden. Neben dem datenstrukturunabhängigen Zugriff auf das ASN zum Auslesen von Informationen wurden transaktionsgestützte Methoden entwickelt, die einen flexibleren und verbesserten Zugriff bei der gemeinsamen Einstellung von Informationen in das ASN ermöglichen. Zudem wird durch die RPD-Middleware eine asynchrone Kommunikation zwischen dem ASN und den RPD-Anwendungen realisiert. Ereignisse, die beispielsweise die Interaktion eines Experten mit dem System erfordern, werden durch intelligente Weiterleitung der Information an die entsprechende RPD-Anwendung gesendet und durch diese dem Experten nutzbar gemacht. Ein wesentlicher Bestandteil der RPD-Middleware besteht daher in der Bereitstellung von Funktionalität zur Informationsvermittlung. Diese teilt sich in die Überwachung von Informationen im ASN und in die Koordination der RPD-Anwendungen entlang des Produktentstehungsprozesses auf. Neben diesen inhaltlichen Problemstellungen berücksichtigt die RPDMiddleware auch infrastrukturelle Fragestellungen, wie z. B. die Verteilung von Aufgaben und die Aufteilung des großen Datenbestandes im ASN. Nach dem Stand der Technik und einer kurzen Einführung in die für die RPD-Middleware relevanten Teile des ASN wird im Anschluss zuerst die agentenbasierte Middleware im Detail vorgestellt bevor die genaue Beschreibung der RPD-Agenten folgt. 4.2.2 Stand der Technik Agentenarchitekturen und –modelle In Wooldrige [4.205], [4.204] und Flores-Mendez [4.72] ist eine allgemeine Definition des Begriffs Agent gegeben: „Ein Agent ist eine künstlich erstellte Einheit, die ihre Umgebung wahrnimmt [4.26], [4.171] und proaktiv oder reaktiv in dieser Umgebung handelt [4.106], in der weitere Agenten existieren. Die Agenten interagieren untereinander [4.172] auf der Basis eines gemeinsamen Verständnisses von Kommunikation und Repräsentation von Informationen [4.64].“ Dabei ist unter dem Begriff der Umgebung entweder die reale Welt, ein Nutzer, der über eine Schnittstelle mit dem Agenten interagiert, eine Men-


241

ge anderer Agenten, das Internet oder Kombinationen davon zu verstehen. Die Umgebung wirkt über Eingaben auf den Agenten ein und wird durch Ausgaben des Agenten beeinflusst (s. Abb. 4.16).

Abb. 4.16. Schematische Darstellung eines zustandbehafteten Agenten

Bei der Betrachtung der Agentenarchitekturen unterscheidet Wooldridge [4.204] zwischen vier Architekturtypen: x Logic based agents: Diese Agenten bestimmen ihre Ausgabefunktion durch das logische Schließen auf der Basis von logischen Zusammenhängen, die in der Datenbasis des Agenten abgelegt sind [4.82], [4.113]. x Reactive agents: Dieser Agententyp besitzt einen Satz von Aktionen, die er abhängig von der Umgebung ausführt. Es besteht ein direkter Zusammenhang zwischen der aktuellen Situation der Umgebung und der Aktion des Agenten darauf [4.25], [4.63]. x Belief-desire-intention (BDI) agents: Das Schlussfolgern im BDIAnsatz [4.83] basiert auf Datenstrukturen, die durch die Annahmen (beliefs), Wünsche (desires) und Ziele (intentions) repräsentiert werden [4.21], [4.22]. x Layered architectures: Die Problembearbeitung wird in Layered Architectures durch mehrere Softwareebenen realisiert, die jeweils einen bestimmten Teil zur Entscheidungsfindung beitragen. Es wird zwischen horizontaler und vertikaler Schichtbildung unterschieden. Die horizontale Schichtbildung (s. Abb. 4.17) bedeutet, dass der Agent in unterschiedliche Module aufgeteilt wird, die verschiedene Aufgaben realisieren. Im Gegensatz dazu werden bei der vertikalen Schichtenbildung alle Module der Reihe nach durchlaufen. Dabei kann die Ausgabe direkt nach der obersten Schicht erzeugt werden oder durch die unterste Schicht nach einem Rücklauf durch alle Schichten [4.204], [4.107], [4.141].

242


Abb. 4.17. Schematische Darstellung der Layered-Architektur

Kommunikationsbeziehungen und -wege Für die Auswahl des richtigen Kommunikationsweges werden drei Arten von Kommunikationsbeziehungen unterschieden. x 1-zu-1: Es kommuniziert genau ein Partner mit einem anderen Partner. x 1-zu-n: Es kommuniziert ein Partner mit beliebig vielen anderen Partnern. x m-zu-n: Es kommunizieren mehrere Partner mit beliebig vielen Anderen. Um diese Kommunikationsbeziehungen informationstechnisch abbilden zu können, gibt es in der Netzwerktechnologie [4.190] drei Arten von Kommunikationswegen: x Unicast: Die Unicast-Technologie setzt die 1-zu-1 – Kommunikation um. Es wird genau ein Kommunikationskanal zwischen zwei Kommunikationspartner geschaltet. x Broadcast: Die Broadcast-Technologie realisiert die 1-zu-n – bzw. die m-zu-n – Kommunikation. Die Kommunikationspartner gehören dabei einer Gruppe an und jeder erhält die Informationen, die ein Mitglied der Gruppe verschickt. Die Gruppenbildung erfolgt auf räumlicher Ebene und ist auf Netzwerke beschränkt. x Multicast: Die Multicast-Technologie bildet ebenso wie der BroadcastAnsatz die 1-zu-n – bzw. m-zu-n – Kommunikation ab. Die Gruppenbildung erfolgt durch die Kommunikationspartner und ist auf keine räumliche Nähe, wie Netzwerke, beschränkt.


243

Die Multicast-Technologie weist in ihrer Grundform [4.190] die Schwäche des zuverlässigen Zustellens von Informationen auf, d. h. es wird nicht dafür garantiert, dass eine Informationseinheit den Empfänger erreicht bzw. in welcher Reihenfolge mehrere verschickte Informationseinheiten bei den Empfängern ankommen. Erweiterungen des Multicast-Protokolls, wie beispielsweise das Light-weight Reliable Multicast Protocol (LRMP) [4.126], gleichen diese Schwäche durch Mechanismen des Transmission Control Protocols (TCP) [4.151], [4.152], [4.153] aus. Kommunikationssprachen Die inhaltlichen Gesichtspunkte befassen sich mit dem Ziel der Kommunikation, also der beabsichtigten Wirkung, dem Inhalt der Nachricht und dem Ergebnis der Kommunikation [4.110]. Da der reine Inhalt einer Nachricht oft missverständlich ist, müssen Regeln für die Interpretation des Inhalts der Nachricht definiert werden, dies ist zum Beispiel auf der Basis der Sprechakttheorie [4.41], [4.50], [4.140], [4.195] möglich. Dabei wurde untersucht, inwieweit der Aufbau der natürlichen Sprache auf die Kommunikation von Computersystemen untereinander übertragbar ist. In der Sprechakttheorie wurden hierbei Kommunikationsregeln erarbeitet und eine Grammatik sowie ein Basis-Wortschatz festgelegt. Die Sprechakttheorie ist auch bei der Teamkoordination im RPD von großer Bedeutung [4.37]. Derzeit existieren Standardisierungsbestrebungen für zwei viel versprechende Agenten-Kommunikations-Sprachen, die die inhaltliche Strukturierung der Nachricht zum Ziel haben. Eine direkte Gegenüberstellung beider Ansätze findet sich in Labrou [4.118] und Luck [4.129]. Dabei ist zwischen einer inneren und einer äußeren Sprache zu unterscheiden, wobei die innere Sprache in die Äußere eingebettet ist. Die Aufgabe der äußeren Sprache ist das Adressierungsmanagement der Nachricht. Hier wird spezifiziert, an wen die Nachricht gerichtet ist und wie sie strukturiert ist. Die innere Sprache definiert die eigentliche Nachricht [4.81]. Ein Beispiel für die äußere Sprache ist die Knowledge Query and Manipulation Language (KQML) als eine Programmiersprache, die Sprechakte nutzt, um eine inhaltsorientierte Kommunikation zwischen Agenten aufzubauen [4.66], [4.67], [4.65], [4.80], [4.116], [4.117], [4.94]. Mit KQML können strukturierte Anfragen an andere Agenten gestellt und der Informationsgehalt der Antwort interpretiert werden [4.57]. KQML weist aber auch Lücken auf, wie z. B. die Möglichkeit, dass ein Agent im Rahmen seiner Aufgabe ein Arbeitspaket an andere Agenten stellen kann [4.42].

244


Die eigentliche Nachricht wird in die KQML-Nachricht im Knowledge Interchange Format (KIF) [4.111] als innere Sprache eingebettet [4.80]. Die andere Standardisierungsbestrebung erfolgt durch die Foundation for Intelligent Physical Agents (FIPA). Die FIPA hat bereits als Agent Communication Language (ACL) für die Kommunikation eine message structure standardisiert [4.69]. Auch die FIPA-ACL Semantik ist durch die FIPA-Communicative Act Library (CAL) spezifiziert worden [4.70]. Zum Austausch von Informationen wird neben anderen Content Languages auch das KIF berücksichtigt und standardisiert. Die Standardisierungsbestrebungen der FIPA bauen dabei auf den Entwicklungen von KQML und KIF auf. Koordinationsprotokolle für eine aktive RPD-Middleware Die reine Festlegung des Kommunikationspfads ist für eine funktionierende Kommunikation nicht ausreichend; es müssen Koordinationsprotokolle definiert werden, die den Kommunikationsablauf zwischen den Bestandteilen der RPD-Middleware und den RPD-Anwendungen bestimmen. Die Koordinationsprotokolle haben folgende Ziele [4.146], [4.145], [4.105]: x Vermeidung von Chaos hat zum Ziel, durch die Zusammenführung aller Teilergebnisse, ein Gesamtziel zu erreichen. x Schaffung einer einheitlichen Umgebung, die die Randbedingungen beinhaltet, in denen die Komponenten arbeiten. x Koordination von verteilten Informationen, Ressourcen und Verantwortlichkeiten, um eine klare Zuständigkeit zu erhalten. x Auflösung von Abhängigkeiten zwischen zwei Komponenten. x Effizientes Arbeiten bspw. durch die Aufgabenaufteilung auf spezialisierte Agententypen. Dabei wird zwischen den folgenden Klassen von Koordinationsprotokollen unterschieden [4.94]: x Kooperationsprotokolle: Kooperationsprotokolle arbeiten nach dem Prinzip „Teile-und-Herrsche“. Dabei werden Aufgaben aufgeteilt und die Ergebnisse wieder zusammengeführt. Das Aufteilen der Aufgaben kann zum Zeitpunkt des Systementwurfs stattfinden beispielsweise durch Aufteilung auf spezielle Agententypen oder während der Laufzeit durch Analyse der Aufgabe [4.57], [4.112]. x Vertragsprotokoll: Das Vertragsprotokoll, auch Contract Net Protocol (CNP) [4.45], [4.179] genannt, beruht auf dem Vertragsprinzip. Ein Agent bietet eine Leistung an und garantiert, dass die Leistung erbracht


245

wird. Möchte ein anderer Agent diese Leistung nutzen, so schließt er mit dem anbietenden Agenten einen Vertrag ab. x Blackboard-Ansatz: Unter dem Blackboard-Ansatz wird ein zentralistisches Verfahren verstanden, wo alle Informationen an einem Ort, dem Blackboard, abgelegt werden. Auf diesen Ort haben alle Koordinationsbeteiligte Zugriff. Die Koordination erfolgt durch Auswertung der vorhandenen Informationen auf dem Blackboard [4.58], [4.104], [4.39], [4.87], [4.142], [4.147]. x Verhandlungsansatz: Der Verhandlungsansatz ist ein verteiltes Verfahren, bei dem alle Koordinationspartner gleichberechtigt sind. Zwischen den Koordinationspartnern wird ein Verhandlungsprotokoll bspw. regelbasiert [4.18] oder durch ein Zustandübergangsdiagramm spezifiziert [4.10]. x Marktmechanismen: Marktmechanismen [4.200] funktionieren nach dem Prinzip der Marktwirtschaft. Die einzelnen Koordinationskomponenten bieten ihre Lösung, hinterlegt durch einen Preis, an. Eine gangbare Lösung wird anhand des Preis/Leistungsverhältnisses ausgewählt. Verteilte Systeme Verteilte Systeme als grundlegende Architektur für Multiagentensysteme werden von Tanenbaum [4.191] folgendermaßen definiert: „Ein verteiltes System ist ein System, das auf einer Menge von Rechnern ausgeführt wird, die nicht über einen gemeinsamen Speicher verfügen, und das sich dem Benutzer wie ein einzelner Rechner darstellt.“ Daraus ergeben sich für den Einsatz von verteilten Systemen [4.90], [4.121], [4.189] verschiedene Randbedingungen, wie x die Unterteilung komplexer Systeme in einfachere Subsysteme mit dem Ziel, eine höhere Stabilität und Wartbarkeit durch Senkung der Komplexität der Teilkomponenten zu erreichen. x die Auslagerung von immer wieder kehrenden gleichartigen Aufgaben mit dem Ziel, diese Teilsysteme nur einmal entwickeln zu müssen und immer wieder nutzen zu können. In den verteilten Systemen werden zwei prinzipielle Architekturen unterschieden:

246


x Client/Server: Unter den Client/Server – Systemen [4.79] sind alle die Systeme zu verstehen, bei denen ein Server einen Dienst anbietet und ein Client diesen Dienst nutzt. Dabei kann ein Client die Dienste von verschiedenen Servern in Anspruch nehmen. Das Client/Server – Prinzip kann auch hierarchisch angewandt werden, sodass ein Server als Client die Dienste eines anderen Servers benutzt. Die Client/Server – Systeme verfolgen ein einfaches 1-zu-1 – Kommunikationsschema. x Verteilte Systeme: In den verteilten Systemen [4.191] gibt es keine direkte Aufteilung von Dienstanbieter und Dienstnutzer. Die beteiligten Komponenten agieren lösungsorientiert und können dabei sowohl als Dienstanbieter wie auch als Dienstnutzer fungieren. Dabei ist zu berücksichtigen, dass im Vergleich zur Client/Server – Architektur eine beliebige Kommunikation, auch m-zu-n – Kommunikation, gewählt werden kann. So ist es möglich, dass jede Komponente des verteilten Systems zu jedem Zeitpunkt eine Kommunikation initiieren kann, die unter Umständen an mehrere Ziele gerichtet ist oder Antworten von mehreren Zielen erwartet [4.1]. Repräsentationssprachen Im Datenbankumfeld wird zwischen dem relationalen und dem objektorientierten Paradigma unterschieden. Eine weit verbreitete Anfragesprache für relationale Datenbanken ist die Structured Query Language (SQL) [4.44] und für die objektorientierte Welt die Object Query Language (OQL) [4.35], [4.55]. Diese Anfragesprachen stellen ausdrucksmächtige, mengenorientierte Datenbankschnittstellen zur Verfügung und können sowohl selbständige Sprachen für Ad-hoc-Anfragen sein, als auch in einer bestimmten Wirtssprache eingebettet werden [4.86]. Beiden Anfragesprachen ist eines gemeinsam, sie dienen ausschließlich zur Informationsbeschaffung unter der Voraussetzung, dass das Datenmodell zum Zeitpunkt der Anfrage bereits bekannt ist. Ein Navigieren oder eine Anfrage mit unvollständigem Wissen ist nicht möglich. XML [4.23] ist ein Standard, der beim Austausch von Daten nur die Interpretation der Daten definiert, ohne Dateiformate oder Programmierschnittstellen zu definieren und der somit eine Lösung für den Datenaustausch zwischen inkompatiblen Systemen bietet. XML wird häufig eingesetzt, wenn es um Datenmanipulation und -übertragung sowie Verwaltung von semistrukturierten Daten und Datenintegration geht, da mit Hilfe der Schema Sprache Data Type Definition (DTD) die Struktur des XML-Dokuments vorgegeben wird und damit auch Wissen über den semantischen Inhalt der Information hinterlegt ist.


247

Resource Description Framework (RDF) [4.122], [4.24] baut auf XML auf. RDF zeichnet sich dadurch aus, dass neben der reinen Information auch Strukturinformation abgelegt werden kann. So werden mit Hilfe eines Graphen die strukturellen Zusammenhänge der Informationen abgebildet. Anfragesprachen Unter den Anfragesprachen werden Sprachen verstanden, mit deren Hilfe Informationen aus einem vorgegebenen Datenbestand extrahiert werden können. Diese Sprachen orientieren sich dementsprechend an der eingesetzten Datenbanktechnologie und an dem verwendeten Datenmodell. Das Datenmodell gibt dabei Auskunft in welchem semantischen Zusammenhang die Daten zueinander stehen. Für die Weiterverarbeitung von Informationen, die in einer Repräsentationssprache formuliert sind, werden unter anderem Anfragesprachen benötigt. Diese verhalten sich zu den Repräsentationssprachen wie SQL zum relationalen Datenbankparadigma. Aufbauend auf den XML-Dokumenten existieren eine Vielzahl von Anfragesprachen bzw. Erweiterungen des vorgeschlagenen Standards XMLQL [4.49] und XQuery als Erweiterung von XML-QL des W3Konsortiums [4.19]. Dabei wird neben der Suche auf XML-Dokumente auch die Struktur der XML-Dokumente berücksichtigt. So ist mit Hilfe von For-Let-Where-Or-Return (FLWOR)-Ausdrücken [4.138] möglich neben der reinen Informationsbeschaffung, durch die Ausdrücke FLW, auch die Form des Rückgabewertes, durch den Ausdruck R, zu bestimmen [4.127]. 4.2.3 Das Aktive Semantische Netz Das ASN ist die zentrale Datenhaltung des RPD. Wie in der Problemstellung bereits erwähnt, stellt die RPD-Middleware das Bindeglied zwischen ASN und RPD-Anwendungen dar. Für das Verständnis der RPDMiddleware wird daher die genaue Kenntnis des Aufbaus und der Funktionsweise des ASN benötigt. Die Entwicklung des Aktiven Semantischen Netzes für das RPD anstatt eines klassischen Datenbankansatzes wurde aus verschiedenen Gründen verfolgt (Kap. 4.1 „Ganzheitliche Modelle zur Repräsentation aktiven Wissens“). Zum einen bieten semantische Netze eine höhere Flexibilität in der Datenstrukturierung. Beim klassischen Datenbankansatz wird während der Softwareentwicklung ein Datenmodell entworfen, das in ein Datenbankschema überführt wird. Im RPD kann sich aber das Datenmodell

248


durch den Einsatz neuer Verfahren und Werkzeuge ändern. Semantische Netze sind in der Lage diese dynamischen Änderungen des Datenmodells abbilden zu können. Zum anderen können in semantischen Netzen Zusammenhänge detaillierter abgebildet werden als in Datenbanken. So ist z. B. eine Differenzierung von verschiedenen Relationstypen möglich. Diese Vorteile und die Aufteilung des ASN auf zwei Abstraktionsebenen stellen eine höhere Flexibilität gegenüber Datenbankansätzen dar und können effektiv im RPD eingesetzt werden. In der ersten Abstraktionsebene wird die Funktionalität, d. h. die Programmlogik des ASN, abgelegt, sowie die Struktur der Datenablage definiert. Die zweite Abstraktionsebene ist die Instanzebene, die die eigentlichen Informationen beinhaltet. Die semantischen Zusammenhänge der Informationen sind über ein objektorientiertes Datenmodell beschrieben. Strukturebene Auf der Strukturebene wird definiert, wie die Daten abgelegt werden. Es wurde hierfür ein flexibles Grundgerüst entworfen, das es erlaubt, Daten zu strukturieren und das Datenmodell beliebig zu erweitern. Es handelt sich hierbei nicht um ein klassisches Datenmodell, wie es in der herkömmlichen Softwareentwicklung entworfen wird, sondern um ein Metamodell. Mit Hilfe des Metamodells (s. Abb. 4.18) kann ein klassisches Datenmodell abgebildet werden. Die Basis des Metamodells umfasst sieben Objekte von denen die ersten vier im weiteren Verlauf dieses Kapitels von Bedeutung sind und die Elemente darstellen, die für die Abbildung eines Datenmodells im herkömmlichen Sinne benötigt werden. Dabei ist das ASN hierarchisch über die Elemente Net, Concept, Attribute aufgebaut [4.27], [4.28], [4.167], [4.166]. x Net: Die Klasse Net des Metamodells beschreibt ein Aktives Semantisches Netz. Das Netz beinhaltet über die Aggregation alle benötigten Informationen um ein Netz abzubilden und stellt die oberste Hierarchieebene dar. x Concept: Die Klasse Concept steht für einen Begriff oder eine Informationseinheit in einem bestimmten Aktiven Semantischen Netz. Die Konzepte sind typisiert, sodass anhand des Typs entschieden werden kann, welche Attribute das Konzept besitzen soll. Die Klasse Concept bildet damit die mittlere Hierarchiestufe. x Attribute: Mit Hilfe der Klasse Attribute werden die Attribute der Konzepte realisiert. Durch die Aggregation zwischen Concept und Attribute ist es möglich, zur Laufzeit beliebig viele Attribute dem Konzept hinzu-


x

x

x

x

249

zufügen bzw. zu entfernen. Dies ist ein Unterschied zum klassischen Datenmodell, wo die Attribute fest in der Klasse verankert sind und nicht zur Laufzeit angepasst werden können. Der Typ des Attributs gibt an, welche Art von Wert im Attribut gespeichert ist. Die Klasse Attribute ist die unterste Hierarchieebene. Relation: Die Klasse Relation dient zur Vernetzung. Hier werden die Informationselemente (Konzepte) miteinander verknüpft. Dabei ist zu beachten, dass es sich um gerichtete Verknüpfungen handelt. Die Relationen sind ebenfalls wie die Konzepte und Attribute typisiert mit dem Ziel die Art der Relation zu spezifizieren, d. h. hier wird spezifiziert, ob es sich bei einer Relation beispielsweise um eine Komposition oder eine Assoziation handelt. ID: Diese Klasse ist eine Hilfsklasse und wird lediglich benötigt, um alle Instanzen der Klassen Interface, Net, Concept, Attribute und Relation mit einer eindeutigen Bezeichnung auszustatten. Interface: Die Klasse Interface ist die Schnittstelle zwischen dem ASN und der RPD-Anwendung. Da es sich beim ASN um eine Client/Server – Applikation handelt, stellt die Klasse Interface den serverseitigen Anteil dar. Client: Hierbei handelt es sich um den clientseitigen Anteil der Schnittstelle zwischen der RPD-Anwendung und dem ASN.

Um auf der Instanzebene die Informationen eindeutig ansprechen zu können, ist ein strenges Namenskonzept notwendig. So besitzen alle Netze einen eindeutigen Namen über den sie angesprochen werden können. Dasselbe gilt für die drei Elemente Concept, Attribute und Relation. Lediglich der Bereich in dem der Name eindeutig sein muss unterscheidet sich. So muss ein Konzept eindeutig sein innerhalb des Netzes zu dem es gehört, während ein Attribut eine eindeutige Auszeichnung im Rahmen des ihm übergeordneten Konzepts besitzen muss. Die Eindeutigkeit der Relation wird durch das Konzept bestimmt von dem die Relation ausgeht. Dieses Konzept wird auch als ausgehendes Konzept bzw. Startkonzept bezeichnet.

250


Abb. 4.18. Aufbau des ASN auf Strukturebene

Instanzebene Im Gegensatz zur Strukturebene werden auf der Instanzebene die Informationen in das ASN geschrieben. Es werden dabei Netze instanziiert, Konzepte mit ihren Attributen hinzugefügt und über Relationen untereinander vernetzt. So gehört ein instanziiertes Attribut genau einem Konzept an und dieses genau einem Netz. Die Angaben Netz, Konzept, Attribut sind notwendig um den Wert eines Attributs auszulesen. Zum Beispiel beinhaltet auf der Struktur-Ebene das Netz für die Entwicklung der Luftdüse ein Konzept vom Typ Person, das neben anderen Attributen auch die Attribute Vor- und Nachname besitzt. Diese Personen gehören dann einem Team an, das ebenfalls durch ein Konzept repräsentiert wird und mindestens das Attribut Name mit dem Teamnamen besitzt (s. Abb. 4.19.). Auf der Instanz-Ebene kann dies z. B. eine Instanz Netz mit dem Namen Luftdüse, eine Instanz Konzept mit dem Namen Person1 und den Attributen Vorname Karl und Nachname Mayer sowie eine Instanz Konzept vom Typ Team mit dem Namen Entwicklung sein. Des Weiteren wird eine Relation Teamzugehörigkeit zwischen dem Team und der Person hergestellt.


251

Abb. 4.19. Struktur des ASN auf Instanzebene

4.2.4 Die agentenbasierte RPD-Middleware Die Architektur der RPD-Middleware Die Architektur der RPD-Middleware umfasst, wie in Abb. 4.20 dargestellt, die folgenden Komponenten:

Abb. 4.20. Architektur der RPD-Middleware

252


Schnittstellen zur RPD-Middleware Die RPD-Middleware besitzt zwei Schnittstellen, die erste zum ASN, die zweite zu den RPD-Anwendungen. Die ASN-Schnittstelle ist durch das ASN vorgegeben. Es handelt sich hierbei um eine proprietäre JAVASchnittstelle. Bei der Schnittstelle zu den RPD-Anwendungen wurde eine nachrichtenbasierte Schnittstelle auf Basis des XML-Standards [4.23] entwickelt. Dies hat den großen Vorteil, dass ein programmiersprachenunabhängiger Zugriff und damit beliebige Anbindungen möglich wurden. Einheitliche Kommunikationssprache An die Kommunikation zwischen Anwendung und RPD-Middleware sind zwei Anforderungen geknüpft. Zum einen wird für jeden Kommunikationspartner (Anwendung oder Agent) eine eindeutige Adresse benötigt und zum anderen müssen die ausgetauschten Nachrichten zur Interpretierung standardisiert werden. Als eindeutige, logische Adresse wird der Unique Agent Identifier verwendet. Dieser hat die Form / / . Der AgentName repräsentiert dabei einen logischen Namen des verwendeten Agenten bzw. der RPD-Anwendung, wie z.B. Koordination_Projektplanung. Der AgentType gibt Auskunft über den zu verwendeten Agenten. Dieses Feld wird für die Instanziierung und die Auswahl des Nachrichtensatzes verwendet. Um die Eindeutigkeit der UAI innerhalb der RPD-Middleware garantieren zu können wird in der Regel die Systemzeit als ID verwendet. Multicast-Umgebung: Aufgrund der Forderung nach einem einfachen und flexiblen Zugang zur RPD-Middleware wurde eine stabile und fehlertolerante Kommunikationsmöglichkeit in Form einer Multicast-Umgebung geschaffen. Diese hat die entscheidenden Vorteile, dass zum einen nur eine Adresse als Zugangspunkt benötigt wird, über die alle Agenten angesprochen werden können, und zum anderen kann die Middleware mit dieser Technologie beliebig über das Netzwerk (auch Internet) als geschlossene Kommunikationsumgebung aufgespannt werden. Die einzelnen Komponenten der RPDMiddleware entnehmen die für sie bestimmten Nachrichten aus der Multicast-Umgebung, wobei die Auswahl der Nachrichten anhand der Empfänger-UAI erfolgt. Masterfunktionalität der RPD-Middleware: Durch die Verwendung des Multicast-Ansatzes ergibt sich die Fragestellung, wie wird ein Agent direkt aufgefunden und angesprochen, bzw.


253

wie werden neue Agenten instanziiert. Dieses Problem wird gelöst durch die Implementierung einer zentralen Stelle, die alle nicht direkt adressierbaren Nachrichten empfängt und bewertet. Bei nicht direkt adressierbaren Nachrichten handelt es sich bspw. um Anfragen an noch nicht instanziierte Agenten. Die zentrale Stelle der RPD-Middleware empfängt diese Instanziierungsaufforderungen, wählt anhand des AgentTypes aus der UAI den benötigten Agententyp aus und instanziiert diesen. Die Verwendung einer zentralen Stelle innerhalb der RPD-Middleware stellt einen so genannten „Single-Point-of-Failure“ dar, d.h. fällt die zentrale Stelle aus, ist die RPD-Middleware unbrauchbar. Um dieses zu umgehen, wurde die zentrale Stelle in Form einer Masterfunktionalität [4.52], [4.197] als Komponente in jeden Agenten eingebracht, so dass jeder Agent als Master-Agent innerhalb der RPD-Middleware agieren kann. Um zu verhindern, dass mehr als ein Master-Agent gleichzeitig aktiv ist, bestimmen die Agenten mit Hilfe des Tokenring-Protokolls [4.96] einen MasterAgenten aus ihrer Mitte. Ebenfalls wird durch das Tokenring-Protokoll der aktuelle Master-Agent überwacht und bei Bedarf ein neuer bestimmt. Nachrichtenübermittlung: Die Multicast-Umgebung implementiert das Nachrichtensystem. Dabei erfolgt die Kommunikation, ähnlich dem OSI-Sieben-Schichtenmodell [4.46], durch vier Kommunikationsebenen (s. Abb. 4.21.).

Abb. 4.21. Schichtenmodell der Kommunikationsumgebung

Die unterste Schicht, die Nachrichtentransportschicht, versendet die Nachrichten über ein Multicast-Protokoll, in diesem Fall LRMP von Inria [4.126]. Aufgrund der Größenbeschränkung von IP-Paketen über Multicast-Verbindungen ist eine Segmentierung auf Seiten des Senders und ein Zusammenfügen auf Seiten des Empfängers notwendig (Segmentierungsschicht). Innerhalb der Adressierungsschicht wird mit Hilfe der Sender(sender) bzw. Empfänger-UAI (destination) die Zustellung der Nachricht gesteuert (s. Abb. 4.22.). Die vierte und oberste Schicht ist der Agenten-

254


kommunikation vorbehalten. Über diese Schicht werden die spezifischen Nachrichten je Agententyp ausgetauscht. Diese sind in die XML-Tags und im Nachrichtenformat der Adressierungsschicht eingeschlossen (s. Abb. 4.22.) [4.43]. Diese vier Schichten werden wie im OSI-Sieben-Schichtenmodell auf Seiten des Senders von oben nach unten und auf Seiten des Empfängers von unten nach oben durchlaufen. <request sender=” “ destination=” “ reqControl=” “ dataType=” “> Abb. 4.22. Befehlsformat für die Kommunikation zwischen den Agenten

In Abb. 4.23 ist ein standardisierter Kommunikationsablauf dargestellt, wie er von jedem Agenten der RPD-Middleware durchgeführt wird. In der Dienstanforderungsphase wendet sich die RPD-Anwendung an die RPDMiddleware um einen neuen Agenten des gewünschten Typs zu instanziieren (1). Der Master-Agent instanziiert den entsprechenden Agenten und gibt im die Dienstanforderung weiter (2). Der neu instanziierte Agent meldet sich bei der RPD-Anwendung mit einer Acknowledge-Nachricht um dieser den Abschluss des Instanziierungsvorgangs anzuzeigen (3). Daraufhin leitet die RPD-Anwendung den Auftrag an den Agenten (4). Der Auftrag wird durch den Agenten syntaktisch und semantisch geprüft (5) und das Ergebnis der Prüfung wird der RPD-Anwendung mitgeteilt (6). Nach erfolgreicher Prüfung wird in die Dienstbearbeitungsphase gewechselt. In dieser Phase werden je nach Agententyp beliebig viele, unterschiedliche Nachrichten ausgetauscht (7). In (8) wird der Agent durch die RPD-Anwendung nach Erbringung der angeforderten Dienstleistung beendet.


255

Abb. 4.23. Standardisierter Kommunikationsablauf mit der RPD-Middleware

Agentenaufbau und Funktionsweise: In Fatima [4.62] ist der interne Aufbau eines Agenten beschrieben, wie er häufig in Multiagentensystemen verwendet wird. Der Agent besteht aus vier Komponenten (s. Abb. 4.24.): x Kommunikation: Das Kommunikationsmodul stellt die Schnittstelle des Agenten nach außen dar. Alle Nachrichten werden dort verschickt, empfangen und aufbereitet. Des Weiteren reagiert das Kommunikationsmodul selbständig auf Verfügbarkeitsanfragen des Master-Agenten. Zusätzlich überprüft das Kommunikationsmodul zyklisch, ob ein Master-Agent im System vorhanden ist. x Verwaltung: Das Verwaltungsmodul steuert den gesamten Agenten; es stellt damit das Kernstück des Agenten dar. Die vom Kommunikationsmodul gelieferten Informationen werden vom Verwaltungsmodul in die

256


Datenbasis geschrieben und die Problemlösungskomponente angestoßen. Nach erfolgter Abarbeitung der Aufgabe holt das Verwaltungsmodul die Ergebnisse aus der Datenbasis und stellt sie über das Kommunikationsmodul der anfragenden RPD-Anwendung oder des anfragenden Agenten zur Verfügung. x Problemlösung: Das Problemlösungsmodul bearbeitet die eigentliche Aufgabe. Das Problemlösungsmodul ist daher in seinem inneren Aufbau von Agententyp zu Agententyp unterschiedlich. Die Problemlösung findet unter Zuhilfenahme der in der Datenbasis abgelegten Informationen statt. x Datenbasis: Die Datenbasis enthält alle für die Bearbeitung der Aufgabe wichtigen Daten. Ebenfalls dient sie zur Zwischenspeicherung von Teilergebnissen der Problemlösungskomponente und zur Ablage des Endergebnisses.

Abb. 4.24. Agenten-Architektur nach Fatima [4.62]

Die RPD-Agenten Ausgehend von der Problemstellung und den Anforderungen nach einem flexiblen und mächtigen Zugang zum ASN zur besseren Integration der RPD-Experten, besteht die RPD-Middleware aus drei Säulen und einer Infrastrukturmaßnahme zur Wissenskommunikation (s. Abb. 4.25.).


257

Abb. 4.25. Angriffspunkte der RPD-Middleware

Dies sind [4.43]: x Informationsüberwachung: Ziel dieser Maßnahme ist es Informationen gezielt im ASN zu überwachen und bei Veränderung dieses der RPD-Anwendung aktiv zu melden. Diese Aufgabe nimmt der MonitorAgent wahr. x Informationsbeschaffung / -aufbereitung und -verarbeitung: Die Aufgaben dieser Komponente sind die Beschaffung von Informationen aus dem ASN ohne genaue Kenntnis über die Struktur der abgelegten Information zu besitzen. Hierfür wurde der Retrieval-Agent entwickelt. Die gewonnenen Erkenntnisse müssen u. U. je nach Komplexität für die RPD-Anwendung aufbereitet werden. Dafür wurde der Aggregations-Agent entwickelt. Neben der reinen Informationsaufbereitung wurden auch Mechanismen für das kooperative Einstellen von Informationen in das ASN benötigt. Diese Aufgabe übernimmt der Input-Agent. Des Weiteren ist ein Transaktionsschutz beim Einstellen von Informationen in das ASN notwendig. Dieses wird durch den TransaktionsAgenten realisiert. x Koordination: Ein weiteres Ziel der Integration der RPD-Experten ist die Koordination der RPD-Anwendungen der Experten entlang des Produktentstehungsprozesses. Hierfür wurde ein Koordinations-Agent konzipiert.

258


x Infrastruktur: Als Infrastrukturmaßnahme wurde der Synchronisations-Agent entwickelt. Dieser hat die Aufgabe die Möglichkeit zu schaffen das ASN über das Internet hinweg aufspannen zu können. Für die Realisierung der Aufgaben der einzelnen Agenten wurde für jeden Agenten eine Anfragesprache entwickelt, mit der die Aufgabenstellung den Agenten mitgeteilt wird und das Ergebnis bzw. die Ergebnisse des Agenten strukturiert der RPD-Anwendung repräsentiert wird. Die Übermittlung der Aufgabenstellung und der Ergebnisse erfolgt nachrichtenbasiert. Die Nachrichten werden für jeden Agenten zu einem Satz von Nachrichten zusammengefasst. Ein Protokoll pro Agent definiert die mögliche Abfolge der Nachrichten, wie sie im Laufe der Kommunikation zwischen Agenten und RPD-Anwendung ausgetauscht werden. Im Folgenden werden die Schwerpunkte der sieben Agenten dargestellt. Eine genaue Beschreibung, sowie eine Demoversion findet sich unter http://www.rpdtoolbox.sfb374.uni-stuttgart.de. Monitor-Agent Der Monitor-Agent hat zum Ziel, die RPD-Anwendung über Informationsveränderungen aller Art im ASN zu unterrichten, ohne dass die RPDAnwendung aufwendige und fehlerträchtige Überwachungsmechanismen implementieren muss. Der Monitor-Agent hat daher die Möglichkeit direkt im ASN Überwachungspunkte zu setzen, so dass jede Veränderung ihm vom ASN gemeldet wird. Dadurch entfallen aufwendige und rechenintensive Polling-Mechanismen und jede Veränderung, auch kurzzeitige, wird dem Monitor-Agenten angezeigt. Neben der reinen Überwachung von Informationen ist die Überwachung von Strukturänderungen, wie das Verbinden zweier Konzepte für die RPDAnwendung, von Interesse. Diese Spezialität von semantischen Netzen bedeutet, dass eine flexible Überwachung über die Werteüberwachung hinaus benötigt wird. Aus diesem Grund wurde die Überwachung durch den Monitor-Agenten als Bedingungsanweisung ähnlich dem IF-Statement aus den Programmiersprachen spezifiziert. Die Überwachungsbedingung, die in der Anfragesprache als Aufgabe durch die RPD-Anwendung definiert wird, beinhaltet folgende Komponenten: x Vergleich von Attributwerten mit anderen Attributwerten oder Fixwerten x Komplexe Vergleiche durch Boole’sche Verknüpfungen von Teilvergleichen


259

x Funktionale Vergleiche wie Strukturfunktionen (Versionsänderungen / Löschoperationen), Zugriffsfunktionen (Anzahl Zugriffe, Version) und mathematischen Funktionen. Die Überwachungsbedingung wird durch die RPD-Anwendung spezifiziert. Diese kann jederzeit den Monitor-Agenten beenden, wenn er nicht mehr benötigt wird. Retrieval-Agent Für die Informationsbeschaffung wurde der Retrieval-Agent entwickelt. Seine Aufgabe besteht darin, Informationen möglichst flexibel und ohne Kenntnis der internen Ablagestruktur im ASN aufzufinden. Aufgrund des speziellen Aufbaus des ASN (s. Absch. 4.2.3 „Das Aktive Semantische Netz“) wurde eine eigene Anfragesprache, die ASN-QL, in Anlehnung an die XML-Query entwickelt. Diese Sprache unterstützt: x Scharfe Suchmethoden: Diese umfassen die Nachbildung der ASNSchnittstelle. Zur Anwendung der scharfen Suchmethoden muss die Struktur der abgelegten Informationen bekannt sein, d.h. bei der Anfrage muss der Anfragende bereits wissen, ob bspw. die Adresse eines Mitarbeiters als verknüpftes Objekt oder als explizites Attribut abgelegt ist. x Unscharfe Suchmethoden: Mit Hilfe der unscharfen Suchmethoden wird im ASN eine Suche durchgeführt, für die die interne Struktur der Information nicht benötigt wird. Dies bedeutet, es werden ebenso alle Strukturelemente bei der Suche berücksichtigt, wie alle Verknüpfungstypen zwischen Konzepten. Des Weiteren besteht die Möglichkeit durch reguläre Ausdrücke den Suchbegriff zu erweitern. Die Ergebnismenge wird, entsprechend dem Suchbegriff gewichtet, als Liste ausgegeben. Zur Bestimmung der Reihenfolge der Ergebnisse wird das Kosinusmaß herangezogen, d.h. die quantifizierbaren Attribute der Ergebniskonzepte spannen einen n-dimensionalen Raum auf. Je kleiner der Winkel zwischen dem Suchbegriff und dem Ergebnis ist, desto näher kommt das Ergebnis dem gesuchten Wert und desto besser wird es bewertet. x Navigation: Entspricht das Ergebnis nicht den gewünschten Vorstellungen, bzw. ist es nicht detailliert genug, so kann mit Hilfe der Navigation das nähere Umfeld der Ergebnismenge erkundet werden. x Quantitative und qualitative Suche: Mit Hilfe von speziellen Schlüsselwörtern wie z.B. „wie viele“ kann die Ergebnismenge quantifiziert werden.

260


Um die Suche zu beschleunigen kann neben der kompletten Durchsuchung des ASN der Suchraum begrenzt werden. In diesem Fall wird ein Startkonzept und eine maximale Umgebungsdistanz definiert, die angibt, wie weit um das Startkonzept herum gesucht werden soll. Um die Suche zu vereinfachen wird der Suchraum aus dem ASN ausgelesen, in eine XML-Darstellung transformiert und diese durchsucht (s. Abb. 4.26).

Abb. 4.26. Abarbeitung einer Retrieval-Abfrage

Aggregations-Agent Der Aggregations-Agent bereitet die gefundenen Informationen kompakt für die RPD-Anwendung auf. Dabei müssen auch Informationen unterschiedlicher Art gruppiert werden können. Der Aggregations-Agent erhält als Anfrage eine Menge von Suchanfragen, die er auf entsprechende Retrieval-Agenten aufteilt, d.h. er nutzt den Retrieval-Agenten als informationsbeschaffende Komponente. Es wird je Suchanfrage ein Retrieval-Agent instanziiert (s. Abb. 4.27.).


261

Abb. 4.27. Funktionsweise des Aggregations-Agenten

Die Ergebnisse der parallel arbeitenden Retrieval-Agenten werden durch den Aggregations-Agenten zusammengefasst und in der XMLDarstellung der RPD-Anwendung präsentiert. Dabei kann anhand den Gruppierungsinformationen die Ergebnisse der einzelnen Teilanfragen zugeordnet werden. Input-Agent Die Aufgabe des Input-Agenten ist die Unterstützung des kooperativen Einstellens von Informationen in das ASN. Dies bedeutet der Input-Agent unterstützt die RPD-Anwendung beim Einstellen von Informationen so, dass die Eingabe einer Information durch eine RPD-Anwendung abhängig ist von der Eingabe einer anderen RPD-Anwendung. Neben der nutzerabhängigen Eingabe wird auch die Masseneingabe unterstützt, so wie die Eingabe von Informationen, die abhängig sind von anderen Informationen im ASN. Die Anfragesprache des Input-Agenten besteht daher aus vier Komponenten. x ASN-Schnittstelle: Die Anfrageelemente der ASN-Schnittstelle bilden die bestehende ASN-Schnittstelle nach. Diese Anfrageelemente werden ebenso genutzt um Attributwerte zu setzen, auszulesen, und zu löschen, wie Konzepte zu erstellen, zu verlinken, zu löschen bzw. Verlinkungen aufzuheben, etc.

262


x Bedingung: Durch die Anfrageelemente der Bedingung können bedingte Eingaben getätigt werden. Im Bedingungsteil können sowohl Fixwerte als auch Elemente aus dem ASN zum Vergleich herangezogen werden. Im Ausführungsteil werden dann je nach Bedingungsauswertung Informationen ins ASN geschrieben. Hierfür werden die Anfrageelemente aus der ASN-Schnittstelle genutzt. Die Bedingungsanweisung orientiert sich an der Spezifikation der Bedingungsanweisung des Monitor-Agenten. x Masseneingabe: Die Anfragesprache des Input-Agenten beinhaltet das Sprachelement „Foreach“ zur Masseneingabe. Dabei wird die Menge an Informationen, die verarbeitet wird entweder durch Fixwerte bestimmt oder durch eine Abfrage aus dem ASN. x Kooperative Eingabe: Die kooperative Eingabe dient zur Abstimmung von Eingaben, die von unterschiedlichen RPD-Anwendungen vorgenommen werden. Durch den Einsatz dieses Sprachelements wird eine Eingabe durch eine bestimmte RPD-Anwendung erzwungen, je nachdem welche RPD-Anwendung bestimmt wurde. Mit Hilfe der vorgestellten Sprachelemente wird eine kleines Programm erzeugt, dass durch den Input-Agenten sequentiell abgearbeitet wird. Die ausführliche Sprachdefinition und ein Softwareprototyp finden sich unter http://www.rpdtoolbox.sfb374.uni-stuttgart.de. Transaktions-Agent Die Komplexität des gesamten Systems spiegelt sich nicht nur in den Wissensrepräsentationsformen des ASN wieder, sondern auch in der Schwierigkeit umfangreiche Serviceleistung anzubieten. Da es allerdings bei einem solchen Betrieb zu mehreren gleichzeitigen Zugriffen kommt, sollte eine Konsistenz-Garantie gewährleistet werden. Das ist eine zentrale Aufgabe des Transaktions-Agenten und wird durch die Implementierung von Protokollen wie two-phase locking und two-phase commit realisiert. Vorausgegangene Entwicklungen im Bereich der relationalen Datenbanksysteme bzw. Transaction Processing liefern eine Grundlage für die Entwicklung dieses Agententyps. Folgende Charakteristiken besitzt der Transaktions-Agent: x Lock Manager als Mechanismus für Concurrency Control für das Setzen und Aufheben der entsprechenden Sperren. x Entwicklung einer Transaktionssprache für die Zusammenarbeit mit anderen Agenten innerhalb des Multiagentensystems. x Kooperationsfähigkeit mit anderen Agenten für komplexe Aufgaben.


263

x Speicherung von Informationen während des Transaktionsprozesses. x User Interface für transaktionsrelevante Informationen. Das Model des Transaktions-Agenten ist in Abb. 4.28 dargestellt. Dieses stützt sich einerseits auf die Client-Server Technologie und andererseits auf die für die RPD-Middleware entwickelte Agentenplattform. Die Anfragesprache an den Transaktions-Agenten (ASN-TL) beinhaltet den Befehlssatz zur Abarbeitung des Transaktionsvorgangs. Das Kommando set_lock_for bezeichnet die Vorbereitung einer Transaktion. Es garantiert, dass alle für die Transaktion notwendigen Sperren noch vor der Ausführung der Modifikation gesetzt werden. Wäre das Setzen der Sperren nicht erfolgreich, dann würde das System Mechanismen aktivieren, die eine Weiterführung der Transaktion verhindern. Das Kommando do_update_for beschreibt die Transaktionsverarbeitung, d.h. die Modifikation der Objekte im ASN nach den Anforderungen der RPD-Agenten, die die Transaktion anfordert. Die anderen drei Kommandos, do_rollback_for, do_commit_for und do_abort_for, bezeichnen das Ende der Transaktion. Mit diesen Kommandos kann der Nutzer, der die Transaktion angefordert hat, den Prozess der Transaktionsverarbeitung kontrollieren.

Abb. 4.28. Das Modell des Transaktions-Agenten

Koordinations-Agent Im Rahmen der Zusammenarbeit der RPD-Experten unterschiedlicher Domänen entstehen entlang des Produktentstehungsprozesses eine Viel-

264


zahl von Abstimmungs- und Synchronisationsvorgängen. Diese werden heutzutage durch Telefonate, Besprechungen mit Anwesenheit, aber auch durch Videokonferenzen durchgeführt. Hierfür ist bei der Verteiltheit und dem großen zeitlichen Aufwand, die solche Besprechungen mit sich bringen eine informationstechnische Unterstützung sinnvoll und notwendig. Der Koordinations-Agent bietet hierfür eine Lösung an. Er implementiert ein flexibles, frei definierbares Abstimmungsprotokoll, durch das die Experten sich synchronisieren können. Durch die schnellen und häufigen Anpassungen im RPD-Prozess muss das Protokoll anpassungsfähig sein. Deshalb wurde als Definition für das Koordinationsprotokoll das Zustandübergangsdiagramm gewählt. Die Zustände repräsentieren Koordinationspunkte und die Zustandswechsel treiben die Koordination voran (s. Abb. 4.29.). Das Zustandübergangsdiagramm wurde derart erweitert, dass es nun auch möglich ist, Eingaben, die für die Zustandswechsel verantwortlich sind, von der sendenden RPDAnwendung ebenso abhängig zu machen, wie die Ausgabe auf eine bestimmte Menge von RPD-Anwendungen begrenzt werden kann.

Abb. 4.29. Ein einfaches Koordinationsprotokoll

Das Zustandübergangsdiagramm wird im Koordinations-Agenten durch einen endlichen Automaten repräsentiert. Im ersten Schritt wird das Zustandübergangsdiagramm durch die RPD-Experten definiert und dann dem Koordinations-Agenten übergeben. Anschließend schicken die RPDAnwendungen ihre Eingabe-Nachrichten, initiieren damit Zustandswechsel


265

und führen die Koordination solange fort, bis ein Endzustand erreicht wurde und damit die Koordination beendet ist. Synchronisations-Agent In der Erprobungsphase des ASN hat sich gezeigt, dass dieses mit wachsender Größe sehr unübersichtlich wird und Performanzprobleme aufweist. Eine weitere Erkenntnis ist, dass das ASN sich in verschiedene eng verzahnte Bereiche aufteilt, wobei je Bereich eine RPD-Domäne zugeordnet werden kann. Dadurch wird deutlich, dass die RPD-Domänen sich häufig in ihrem Bereich aufhalten und nur an den Schnittstellen mit den anderen Bereichen in Berührung zueinander kommen. Es bietet sich daher eine Segmentierung des ASN an. Die einzelnen Segmente, inklusive der Konzepte, die an den Schnittstellen liegen, sollten dabei möglichst nah den RPD-Anwendungen der entsprechenden Domänen zur Verfügung gestellt werden, um Netzwerkverzögerungen zu vermeiden. Dies bedeutet, dass die einzelnen Segmente über das Internet verteilt sind. Der Synchronisations-Agent verbindet die einzelnen Segmente des ASN und führt sie zu einem ASN zusammen. Dabei werden Veränderungen, die in einem Segment vorgenommen wurden und die für ein weiteres Segment von Bedeutung sind, in beiden Segmenten synchron gehalten. Die Synchronisation ist nicht auf zwei Segmente beschränkt, es könnten auch drei und mehr Segmente synchron gehalten werden. In der Realisierung des Synchronisations-Agenten wurde konsequent die Idee des Monitor-Agenten weiterverfolgt. Auch im SynchronisationsAgent werden die zu synchronisierenden Elemente mit Hilfe von Überwachungspunkten im ASN überwacht. Allerdings ist die Bedingungsanweisung des Monitor-Agenten nicht ausreichend. Es werden auch Elemente benötigt, die es erlauben ganze Netze zu überwachen. Die Anfragesprache des Synchronisations-Agenten berücksichtigt diese neuen Sprachelemente und ermöglicht die Definition einer Menge von Informationselementen, die in einem Segment A überwacht werden sollen, um sie in ein Segment B hinein zu synchronisieren. Es ist dabei zu beachten, dass die Synchronisation immer nur in eine Richtung ausgeführt wird mit dem Vorteil, dass beliebige Synchronisationsvorgänge, auch Dreieckssynchronisationen, aufgebaut werden können. Nachteilig wirkt sich dabei aus, dass für eine einfache Synchronisation zwischen zwei Segmenten zwei Synchronisations-Agenten benötigt werden.

266


4.2.5 Zusammenfassung Durch den Einsatz der RPD-Middleware konnte die gemeinsame Arbeit der RPD-Experten und die Benutzung des ASN nachhaltig verbessert werden. So wurde im Bereich der Informationsüberwachung die Möglichkeit geschaffen, Veränderungen im ASN aktiv und ohne zusätzlichen Aufwand, aufseiten der Experten und deren RPD-Anwendungen zur Verfügung zu stellen und damit einen Mehrwert anzubieten. Durch den Einsatz der Agenten der Informationsbeschaffung, aufbereitung und -verarbeitung ist es nun möglich, Informationen aus dem ASN auszulesen ohne die interne Struktur des ASN oder des Datenmodells kennen zu müssen. Der Input-Agent unterstützt die Zusammenarbeit der RPD-Experten bei der Eingabe von Daten, so dass ein gemeinsames Verständnis für die abgelegten Informationen frühzeitig aufgebaut werden kann. Durch den Transaktions-Agenten wird zusätzlich ein Transaktionsschutz bei der Eingabe aufgebaut, während der Aggregations-Agent die strukturierte Zusammenfassung von Suchergebnissen ermöglicht. Der Themenschwerpunkt Koordination befasst sich mit der informationstechnischen Unterstützung des Produktentstehungsprozesses und nicht mit der Datenmanipulation. Durch das frei definierbare Koordinationsprotokoll in Form eines Zustandübergangsdiagramms können Abstimmungsvorgänge IT-technisch unterstützt werden ohne die Flexibilität des RPDProzesses einzuschränken. Der Synchronisations-Agent als Strukturmaßnahme verbessert nachhaltig die Anwendbarkeit des ASN. Er beschleunigt zugleich auch die Abarbeitung der Anfragen des Retrieval-Agenten und damit auch des Aggregations-Agenten. Ganzheitlich betrachtet liefert die RPD-Middleware einen Mehrwert für die RPD-Nutzer. Es werden wichtige Funktionalitäten über die üblichen Datenmanipulationen hinaus angeboten und die Zugriffszeiten nachhaltig verkürzt, wodurch eine quantitative und qualitative Verbesserung des RPD-Prozesses erreicht werden kann.

4.3 Teamorientiertes Kommunikationssystem für vernetztes Arbeiten

4.3.1 Einleitung Die zunehmende Komplexität von Produkten und somit der Entwicklungsaufgaben erzwingen eine Integration von Experten unterschiedlicher Fachrichtungen. Durch diese interdisziplinäre Zusammenarbeit sollen Synergien genutzt und kreative Prozesse angestoßen werden [4.176]. Aufgrund der sich rasant wandelnden Märkte und der dadurch bedingten Forderung nach immer schnelleren Entwicklungszyklen bleibt allerdings wenig Zeit, jeweils neue Experten in die eigenen Unternehmensstrukturen zu integrieren. Die Lösung für die Unternehmen liegt im Aufbau organisationsübergreifender, virtueller Teams, in die auch Lieferanten und Kunden einbezogen werden. Zusätzlich erfordern die für eine schnelle Produktentwicklung charakteristischen Iterationszyklen eine Arbeitsweise, die sich wesentlich von der bisherigen, auf sequentieller Bearbeitung beruhenden, unterscheidet. Insbesondere in modernen Entwicklungsprozessen (wie z.B. Simultaneous Engineering, Rapid Product Development), in denen keine konkreten Absprachen und Entwicklungskonstellationen feststehen, müssen Gedanken und Modelle möglichst explizit kommuniziert werden, damit eine gemeinsame Wissensbasis zwischen den multidisziplinären Experten aufgebaut werden kann [4.185]. Le Hen & Sorito [4.123] stellen jedoch in ihrer Analyse folgende Defizite bei verteilter Kooperation in der Produktentwicklung fest: x Kein einheitlicher und verbindlicher Kooperationsprozess vor dem „Start of Production“. x Asynchrone Anbindung: Teilnehmer können auf wichtige Produktinformationen erst zu spät zugreifen. Als Konsequenz sind häufige Reisen, Telefongespräche und Faxe notwendig, um Informationen zu bekommen. Künftig sollen Teilnehmer früher auf 3D-Modelle zugreifen können. x 3D-Modelle werden fast ausschließlich in Entwicklungszentren benutzt. Andere Teilnehmer (oder „nicht CAD-Anwender“) greifen meist auf 2D-Zeichnungen zu. Die Benutzung von 3D-Modellen ist jedoch ein Eckstein des heutigen Produktentstehungsprozesses.

268


Dadurch findet weitestgehend eine entkoppelte und dadurch sequentielle Produktentwicklung statt. Ein intensiver Austausch, der auf Strukturen basiert, die der Kommunikation in einer realen, nicht verteilten Arbeitssituation nahe kommt und räumliche und zeitliche Barrieren überbrückt, bleibt meistens aus. Ziel der Entwicklung des teamorientierten Kommunikationssystems war es, diese Strukturen unter arbeitswissenschaftlichen Gesichtspunkten zu untersuchen und technologisch zu unterstützen, um den Herausforderungen an die heutige Produktentwicklung (Schnelligkeit, Komplexität) besser begegnen zu können. Neben der effizienten arbeitswissenschaftlichen Analyse der Zusammenarbeit im RPD, gehörte die prototypische Entwicklung von unterstützenden Informations- und Kommunikationstechnologien zu den Hauptaufgaben in diesem Teilprojekt. 4.3.2 Entwicklungsverlauf der Arbeiten im Teilprojekt In der ersten Förderperiode sind Basisdienste für CSCW (Computer Supported Cooperative Work) und CMC (Computer Mediated Communication) für geeignete Kommunikations- und Kooperationsinfrastrukturen untersucht und hinsichtlich des Einsatzes in der Produktentwicklung evaluiert worden. Hierfür wurden unterschiedliche Entwicklungsszenarien am Beispiel des Fahrzeugsitzes und im Rahmen von Arbeiten im Ergonomielabor aufgestellt. In der zweiten Förderperiode wurden erste Softwarelösungen erarbeitet, die die besonderen Gegebenheiten der Zusammenarbeit im Sinne des RPD berücksichtigen. Diese waren ausgelegt auf die Zusammenarbeit der Teammitglieder, die verteilt an einem Prototyp arbeiten. Für den Aufbau und den Ablauf der Kommunikation ist der Persönliche Assistent entwickelt worden, der je nach Kooperationskonstellationen und Verfügbarkeit die geeigneten Technologien auswählt. In den Szenarien hat sich jedoch gezeigt, dass eine Ausweitung auf eine Team-Team-Zusammenarbeit, die technische und organisatorische Grenzen überwindet, notwendig ist. Daher ergaben sich für das Modell der teamorientierten Kommunikationsplattform erweiterte Anforderungen, die in der dritten Förderperiode untersucht wurden. Thematisch gliederten sich die Arbeiten in die Erweiterung des Kooperationsmodells für eine MultiTeam Plattform, die Umsetzung eines situativ unterstützenden Sitzungsmanagements, die Erarbeitung technischer Lösungen für dynamisch aufgestellte, verteilte Teams und die Realisierung einer prototypischen Kooperationsplattform. Diese Plattform kommuniziert über die Agenten der Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplatt-


269

form für aktive Wissenskommunikation im Rapid Product Development“) mit dem ASN (Kap. 4.1 „Ganzheitliche Modelle zur Repräsentation aktiven Wissens“) und wurde in das RPD-Portal (Kap. 4.4 „Adaptive Benutzungsoberflächen“) integriert. Die Plattform stellt folgende Komponenten zur Verfügung: x 3D-Teamräume für die synchrone Visualisierung und Bearbeitung von virtuellen Prototypen, Entwurfsskizzen, Bildern und Präsentationen. Die Anwendung ist ein Java Applet, kann also webbasiert betrieben werden und stellt neben gängigen synchronen Kommunikationstechnologien wie Chat, Instant Messaging und Audio-/Videoconferencing Tools zur Gesprächsstrukturierung (Präsentations-/Moderationstechniken) zur Verfügung. Beliebige 3D-Modelle können zur Laufzeit in die Umgebung geladen werden. Ebenso besteht die Möglichkeit Powerpointpräsentationen zu importieren [4.192]. x Ein sprechakt-basiertes Nachrichtensystem für die asynchrone Kommunikation. Das Nachrichtensystem erweitert herkömmliche E-MailFunktionalitäten um personen- und kontextrelevante Parameter. Durch die einheitliche und strukturierte Ablage von Informationen und die Integration von zeitlichen und inhaltlichen Parametern in die Nachricht (Antwortzeit, Sprechakt, etc.), unterstützt dieses System effektiv die unterschiedlichen Sprechakte (Handlungsbedingungen). Der Empfänger bzw. die Empfängergruppe erhält eine Sicht auf die Daten, bei der beim Abruf von Nachrichten keine großen Datenmengen übertragen werden müssen [4.36]. x Eine Groupware-Anwendung, die herkömmliche Tools wie Gruppenkalender, Gruppenordner, etc. zur Verfügung stellt. In der vierten Förderperiode stand neben der Weiterentwicklung und Ergänzung der im Prototyp entwickelten Funktionalitäten eine weiterführende Integration mit den anderen RPD Applikationen im Mittelpunkt. Zusammen mit dem Teilprojekt „Arbeitswissenschaftliche Konzeptionierung kooperativer Arbeitsformen für die Entwicklung innovativer Produkte“ (Kap. 2) wurden weitere gesprächsunterstützende bzw. -strukturierende Techniken ausgewählt und umgesetzt. Einen Schwerpunkt bildete die Anbindung an verschiedene mobile Endgeräte und die damit zusammenhängende Nutzung von Augmented Reality-Funktionen im Entwicklungsprozess (in Zusammenarbeit mit dem Teilprojekt „Virtuelle Realität als Gestaltungs- und Evaluationswerkzeug“ (Kap. 5.2)). Verschiedene kooperative Szenarien für die simultane Arbeit an virtuellen und physischen Prototypen wurden prototypisch umgesetzt.

270


In Zusammenarbeit mit Teilprojekt „Planungsmethoden für dezentrale Entwicklungsteams“ (Kap. 2) wurde für das Kooperationssystem an einem Kommunikationsmanagement (z.B. Abbildung von KommunikationsWorkflows) gearbeitet, das die unstrukturierten Kommunikationsabläufe im RPD besser handhabbar macht. Daneben wurde die sprechakttheoretische Analyse fortgesetzt und um Aspekte des Erreichbarkeitsmanagements erweitert. In der Folge wurde ein Softwareprototyp entwickelt, der die Terminierung von Sitzungen automatisiert bearbeitet und dadurch den Nutzer von zeitaufwendigen Terminabsprachen befreit. Dabei wurden verstärkt auch die Agenten aus Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“ eingebunden. 4.3.3 Stand der Forschung Die Arbeiten für teamorientierte Kommunikationssysteme liegen im Forschungsgebiet der Computer Supported Cooperative Work (CSCW). Als interdisziplinäres Forschungsgebiet integriert die CSCW-Forschung verschiedene sozial-, ingenieurwissenschaftliche und technische Disziplinen. Da – wie oben geschildert – für das teamorientierte Kommunikationssystem verschiedenartige Ausprägungen von CSCW-Anwendungen prototypisch entwickelt wurden, soll hier, anstelle eines allgemeinen Überblicks über das Forschungsgebiet CSCW, näher auf die aktuelle Forschung in den betroffenen Teilgebieten eingegangen werden. Daher gliedert sich dieser Abschnitt in die Punkte Collaborative Virtual Environments, Augmented Reality, gesprächsunterstützende Techniken und sprechakt-basiertes Kommunikationsmanagement. Ziel dieses Abschnitts ist nicht die erschöpfende Darstellung der Forschungstätigkeiten, vielmehr soll ein (einführender) Überblick über aktuelle Fragestellungen des Themengebiets gegeben werden. Collaborative Virtual Environments (CVE) „Collaborative Virtual Environments“ (CVE) sind integrierte kooperative Systeme, die sich durch zwei wesentliche Eigenschaften von herkömmlichen CSCW-Anwendungen (z.B. MS Exchange) unterscheiden: x die Raummetapher Im Gegensatz zu CSCW-Anwendungen, die die Desktopmetapher nutzen, um verschiedene Systeme (E-Mail, Audio-/Videokonferenz etc.) zu integrieren, findet bei CVE die Integration der Systeme in einem Raum


271

statt. Alle in diesem Raum befindlichen Objekte und Dokumente sind für die Personen, die sich innerhalb des Raums aufhalten, zugänglich. Ebenso sind alle integrierten CSCW-Applikationen innerhalb des virtuellen Raums gemeinsam nutzbar. D.h. hier wird die ursprünglich für Einzelarbeitsplätze entworfene Desktopmetapher auf mehrere Arbeitsplätze in einem Raum erweitert und dadurch dem räumlichen Aspekt von Gruppenarbeit Rechnung getragen. Die Räume können entweder zwei- oder dreidimensional gestaltet sein. x Avatare Avatar (von Sanskrit Avatara, deutsch „Herabkunft“) bezeichnet im Hinduismus die körperliche Manifestation eines unsterblichen Wesens, z.B. einer Gottheit in Menschengestalt, auf der Erde. Durch einen Avatar wird eine Person in einem virtuellen Raum repräsentiert, andere Personen, die sich in dem gleichen Raum befinden, können durch ihre Avatare wahrgenommen werden. Einer der Hauptgründe für die Entscheidung, das teamorientierte Kommunikationssystem CVE zu nutzen bzw. zu entwickeln, liegt darin, dass es in den meisten aktuellen Technologien zur Unterstützung der verteilten, kooperativen Zusammenarbeit Defizite in der Interaktion mit räumlichen Gegenständen gibt [4.177]. Dies ist besonders dann der Fall, wenn es um das Design und die Entwicklung komplexer räumlicher Gegenstände geht, wie z.B. in der Fahrzeugentwicklung oder im Anlagenbau. Physische Objekte oder deren Repräsentationen helfen bei diesen Tätigkeiten durch eine Möglichkeit der visuellen oder haptischen Wahrnehmung des Erscheinungsbildes bzw. der physikalischen Eigenschaften. Sie dienen der semantischen Repräsentation ihrer räumlichen Verhältnisse (auch zu anderen Objekten) und ihrer Eigenschaft, die Aufmerksamkeit der Benutzer auf sich zu ziehen. Diese Objekte sind mehr als nur Informationsquellen; sie konstituieren die kooperative Aktivität, indem sie einen Bezugsrahmen für Kommunikation und Gruppeninteraktion schaffen [4.136]. Diese Erkenntnisse wurden im Visual Engineering umgesetzt. Die Forschung ebenso wie Erfahrungen aus der Praxis in diesem Bereich haben gezeigt, dass die Visualisierung von Objekten ein integraler Bestandteil kooperativer Prozesse in der Produktentwicklung ist. Bei einer Untersuchung mit Gestaltern und Ingenieuren aus Designbüros und der Automobilindustrie stellte Deisinger [4.47] fest, dass es als sehr wichtig erachtet wird, im frühen Stadium des kreativen Prozesses eine Idee in greifbare Form zu bringen. Erst dann besteht die Möglichkeit, die Idee effektiv zu bewerten, darüber zu reflektieren und sie gegebenenfalls zu verändern. In diesem Stadium werden verschiedene Lösungen und Alternativen für das Problem generiert. Dabei ist eine gewisse Unschärfe der Skizze erwünscht,

272


um einen Interpretations- und Transformationsspielraum, der für die Identifikation von Alternativen notwendig ist, zu gewährleisten. Ein Versuch, den oben beschriebenen Anforderungen zu entsprechen, wurde z. B. durch das Projekt „Distributed Interactive Virtual Environment (DIVE)“ [4.54], [4.74] unternommen. In DIVE wurde ein internetbasiertes Multi-User Virtual Reality System entwickelt, das es Teilnehmern erlaubt, sich in einer dreidimensionalen Umgebung virtuell zu treffen, zu sehen und zu interagieren. Auf DIVE basierend wurde das Projekt „Collaborative Virtual Environments (COVEN)“ [4.14], [4.193], [4.144] durchgeführt. In diesem Projekt lagen zum einen die Schwerpunkte auf kooperativem TeleWorking und virtueller Präsenz, d.h. arbeitswissenschaftlichen Fragestellungen, zum anderen auf der Erprobung unterschiedlicher Netzwerktechnologien für den Anwendungsfall einer verteilten Mehrbenutzer VRUmgebung [4.40]. Das „Internet2 Collaborative Virtual Environments (CVE) Project“ [4.97] des University College London, der University of North Carolina Chapel Hill und des Massachusetts Institute of Technology führte Experimente anhand von drei Szenarien mit unterschiedlichen CVEApplikationen in Verbindung mit AR-Technologien durch: x Ein Sicherheitsszenario, in dem Mitarbeiter die räumlichen Charakteristika einer großen industriellen Anlage verstehen mussten, um die Konsequenzen für sicherheitsrelevantes Verhalten von Menschen, die in dieser Umgebung leben und arbeiten, besser beurteilen zu können. x Ein Szenario, in dem Designer sich in einem virtuellen Raum treffen, um ein Design zu besprechen bzw. damit zu interagieren (haptisches feedback). x Ein Szenario, in dem mehrere Personen etwas gemeinsam erstellen. Während dieser Experimente wurde das soziale Verhalten der Probanden und deren Performanz, die verschiedenen Aufgaben betreffend, untersucht [4.178], [4.182], [4.183]. In diesem letzten der auf DIVE basierenden Projekte wurden massive technische Probleme bei der simultanen Manipulation von Objekten festgestellt. Da in den frühen Projekten hauptsächlich arbeitswissenschaftliche Aspekte von CVE untersucht wurden, konnten diese technischen Probleme nicht erkannt werden. Die Entwicklung des teamorientierten Kommunikationssystems bewegt sich im Rahmen der CVE Forschung, aber im Gegensatz zu den oben genannten Projekten wird hier speziell auf den Anwendungsbereich der Produktentwicklung, insbesondere des Rapid Product Development, fokus-


273

siert. In den beiden letzten Förderperioden wurde eine CVE entwickelt, in der die oben genannten technischen Probleme bezüglich der Manipulation von Objekten prototypisch gelöst wurden (Kap. 4.3.5 „Ergebnisse“). Seamlessness und Augmented Reality (AR) Ein wichtiges Ziel der Forschungen im CSCW ist die Nahtlosigkeit (engl.: seamlessness) im Zusammenhang unterschiedlicher kooperationsunterstützender Werkzeuge. Ishi [4.99] definiert „seam“ als eine räumliche, temporale oder funktionale Einschränkung, die den Benutzer dazu zwingt, sich zwischen verschiedenen Räumen und Benutzungsarten zu bewegen. Diese Einschränkungen, auch „gaps“ (Lücken) genannt, werden in erster Linie durch technische Hindernisse (z.B. die Filtercharakteristik des Mediums Computer) hervorgerufen. Einer Lücke liegt eine technische Trennung von zwei oder mehreren Kommunikations- oder Arbeitsmodi zugrunde, z.B. die Trennung zwischen individueller und kooperativer Arbeit, zwischen asynchroner und synchroner Kommunikation oder zwischen konventioneller Software und Groupware. Neuere Forschungen beschäftigen sich vermehrt mit der Trennung zwischen Software-Werkzeugen und physischen Werkzeugen sowie der Problematik, dass physische Artefakte bislang nicht mit elektronischen Artefakten interagieren können. Die Forschung ist besonders für den Bereich CVE relevant, da hier Menschen, die in verschiedenen realen Arbeitswelten getrennt voneinander arbeiten, an einem virtuellen Arbeitsplatz zusammengeführt werden, um dort möglichst effizient zu kooperieren. Die meisten Technologien und Benutzungsoberflächen für CVE bieten jedoch sehr wenige Möglichkeiten, die Trennung zwischen der realen und der virtuellen (Arbeits-) Welt aufzuheben oder zumindest zu überbrücken. Im Rahmen der Forschungen zu „Tangible User Interfaces“ (TUI) wurde die Möglichkeit zur Verwendung von realen Objekten als Benutzungsschnittstellen untersucht [4.98]. Diese greifbaren Objekte sind intuitiv zu handhaben, da die Manipulation des physischen Objekts direkt auf das virtuelle Objekt übertragen wird. Ein anderer Ansatz wird in der Forschung zu dem Bereich „Augmented Reality“ (AR) verfolgt. Augmented Reality „vermischt“ die Realität mit der Virtualität, so dass zusätzlich zu der real wahrgenommenen Umgebung virtuell dargestellte Informationen, Objekte, Animationen und Simulationen dem Benutzer zugänglich gemacht werden. Ein real vorliegendes Objekt kann somit virtuell um bestimmte Eigenschaften erweitert werden. So könnten z.B. an einem physikalischen Prototypen virtuelle Veränderungen vorgenommen werden. Eine kooperative AR-Umgebung lässt die Trennung zwischen realer und virtueller Welt verschmelzen und bietet neben einer großen Immersion auch die Möglichkeit zur Umsetzung völlig neuer

274


kooperativer Entwicklungsszenarien, z.B. die Zusammenarbeit an hybriden Prototypen. Im Projekt ARVIKA werden Augmented-Reality-Technologien zur Unterstützung von Arbeitsprozessen in Entwicklung, Produktion und Service für komplexe technische Produkte und Anlagen erforscht und realisiert [4.3]. Durch die visuelle Überlagerung realer Objekte mit rechnergenerierten virtuellen Objekten erlauben Augmented Reality-Techniken im Sinne einer erweiterten Realität das situationsgerechte Agieren in realen Arbeitsumgebungen. Das Projekt ARVIKA kam bisher zu folgenden Erkenntnissen: Augmented Reality-Techniken können dazu beitragen, Anwendungen aus dem Bereich Virtual Reality wesentlich einfacher zu lösen, wenn der haptische Eindruck, der bei VR durch spezielle Hardware erfolgen muss, im sog. "Mixed Mock-Up" durch reale Objekte bzw. Teile abgedeckt wird. Einige Problemstellungen im Produktentwicklungsprozess sind einfach durch AR zu lösen, wie z.B. der direkte Vergleich zwischen Versuchsergebnissen und Berechnungsresultaten. Beispielhaft wird hier der Einsatz von ARTechniken beim Vergleich von Crash-Ergebnissen genannt. Nach einem Crashtest überlagert das AR-System im Sichtfeld des Entwicklungsingenieurs die durch die Simulation vorhergesagte Verformung über das reale Crashfahrzeug. Differenzen werden "auf einen Blick" sichtbar und direkt bewertbar [4.5], [4.4]. Für die Zusammenarbeit im RPD stellt sich die Frage, inwieweit ARTechnologien auch kooperativ sinnvoll genutzt werden können. Interessant ist in diesem Zusammenhang eine Untersuchung von [4.75], der die Anwendungsmöglichkeiten von AR beim telekooperativen Lernen untersuchte. In dieser Untersuchung wurde ein Szenario entwickelt, in dem alle Teilnehmer auf ein Objekt bezogene, virtuelle Informationen ergänzen können, obwohl nur einer der Teilnehmer das Objekt unmittelbar real wahrnimmt. Daraus ergibt sich eine aktive Mitgestaltungsmöglichkeit an einem realen Objekt, obwohl die teilnehmenden Personen räumlich voneinander getrennt sind. Die Einsatzmöglichkeiten und möglichen Anwendungsszenarien für AR im verteilten kooperativen Arbeiten in der Produktentwicklung sind bisher jedoch noch nicht im Detail ausgearbeitet und erforscht worden. Für das teamorientierte Kommunikationssystem wurden in der letzten Förderperiode erste Szenarien entwickelt und technisch umgesetzt (Kap. 4.3.5 „Ergebnisse“). Gesprächsunterstützende Techniken In multidisziplinären Teams klagen die Mitglieder häufig über Verständnisprobleme und mangelnde Offenheit gegenüber ihren Ansichten [4.48].


275

Die Verwendung von Fachsprachen und die unterschiedlichen Lösungsansätze der Fachgebiete führen häufig zu Nicht- oder Missverstehen und verhindern die Entwicklung einer übereinstimmenden Vorstellung von der gemeinsam zu lösenden Aufgabe. Steinheider und Bayerl [4.186] untersuchten in einer Studie die Zusammenhänge zwischen der Heterogenität von Teams, den verwendeten Strategien zur Wissensintegration, dem Ausmaß der Wissensintegration und dem Erfolg der Teams. Sie fanden heraus, dass eine ausgeglichene Kommunikationsstruktur (gleiche Gesprächsbeteiligung aller Teammitglieder) sowie die Visualisierung von Zusammenhängen die negativen Auswirkungen einer heterogenen Teamzusammensetzung mildern können. Obwohl der kompetente Einsatz von Methoden zur Strukturierung der Ideenfindung und -realisierung in Gruppen in der Arbeitspraxis schon häufig angewandt wird und immer mehr an Bedeutung gewinnt, werden gesprächsunterstützende Techniken, die eine ausgeglichene Kommunikationsstruktur fördern (Moderation, Präsentation, Visualisierung), in heutigen CSCW-Systemen so gut wie nicht unterstützt. In dem Projekt „Moderation VR“ beschäftigt man sich mit der kooperativen Nutzung von Moderations- und Kreativitätstechniken [4.137]. Die Werkzeuge werden im Rahmen einer Lernplattform eingesetzt, die sich u.a. durch Group-Awareness-Komponenten, synchrone und asynchrone Kommunikationsmöglichkeiten und die Begehbarkeit einer virtuellen Lernumgebung auszeichnet, jedoch als technische Ausstattung lediglich einen Standard-PC voraussetzt. Die Begehbarkeit der Lernumgebung wird durch die Virtual Reality-Technologie ermöglicht. Mit Hilfe von Computerprogrammen werden Datensätze multimedial umgesetzt und als dreidimensionale Datenräume simuliert. Die Lernenden, repräsentiert durch Avatare, treffen sich z.B. in einem virtuell begehbaren Lernraum und bekommen ein Fallbeispiel, das die Lösung einer komplexen betrieblichen Situation durch Moderation vorsieht. Erste Ergebnisse zeigen, dass Moderationstechniken auch in virtuellen Umgebungen erfolgreich angewendet werden können. Der Einsatz dieser Techniken sollte auch für das RPD untersucht werden, da die effektive Unterstützung der verteilten Teams gewährleistet werden muss. Sprechakt-basiertes Kommunikationsmanagement Bei der Kommunikation in verteilten RPD-Teams entstehen sowohl vorhersagbare als auch nicht vorhersagbare Zusammenhänge. Im Verlauf einer Kommunikation können immer neue Randbedingungen auftreten, die eine Verlaufsplanung in die Zukunft erschweren. Diese Planung betrifft sowohl die Informationen an sich als auch die unterschiedlich integrierten

276


Beteiligten und deren jeweilige Handlungsumwelten. Zusammen ergibt sich ein veränderliches Kommunikationsumfeld. Daher kann von komplexen Vorgängen (Systemen) gesprochen werden, die meist diskontinuierlich sind und sich in ihrer Heterogenität aus vielen kleinen simultanen Einzelprozessen zusammensetzen [4.194]. Das bedeutet, dass deren Wechselwirkung untereinander nicht fest verbunden ist, so dass ein Gesamtprozess unterschiedliche Entwicklungen nehmen kann. Der Begriff Emergenz bedeutet ein „Springen“ oder „Auftauchen“ von Ereignissen und Entwicklungen und beschreibt eine Ordnung, die nicht aus den zusammengesetzten Eigenschaften ihrer Teile erklärt werden kann. Das bedeutet: ein spontanes Entstehen von Entwicklungen, wodurch komplexe Strukturen aus einfachen Zusammenhängen hervorgehen können. Der Begriff der Emergenz stammt aus der Evolutions- und Systemtheorie und beschreibt einen rekursiven Prozess von Selektion (Auswahl), Mutation (Veränderung) und Restabilisierung (Wiederherstellung). Es tritt ein nicht vorhersagbarer Zustand ein, dessen Vorgeschichte wiederum nicht ableitbar ist. Man unterscheidet harte und weiche Emergenz. Bei der weichen Emergenz wird eine gewisse Deduzierbarkeit angenommen. Bei der harten Emergenz wird eine Deduzierbarkeit ausgeschlossen [4.194]. Emergenz in der Kommunikation Vergangenheit weiche Emerharte Emergenz genz x Rückverfolgung x keine Rückverfolgung von von Partnern und Partnern und Hergang Hergang x heutiges Ziel abx heutiges Ziel leitbar aus der Kommunikation nicht ableitbar x es muss nicht der x Notwendigkeit gesamte Hergang der Expliziesichtbar sein, jerung von Randbedingungen doch die Prozessstruktur x gesamter Prozess muss sichtbar sein, damit er nachvollzogen werden kann Abb. 4.30. Emergenz in der Kommunikation

Zukunft weiche Emergenz x gerichteter Prozess – Ziel ist definiert x Ablauf richtet sich nach einem groben Workflow x Ansprechpartner werden nach Fachdisziplinen ausgewählt

harte Emergenz x Ziel ist nur grob definiert x Ansprechpartner wechseln im zeitlichen Verlauf x keine Determinierbarkeit


277

Die Unterscheidung in harte und weiche Emergenz ist im weiteren Verlauf der Betrachtung der Kommunikation im RPD hilfreich, da diese hiermit weiter strukturiert werden kann. Abbildung 4.30 zeigt eine Aufschlüsselung und den Charakter des hier verwendeten Begriffs der Emergenz. Die Unterscheidung ist nach der Betrachtungsrichtung (Vergangenheit vs. Zukunft) vorgenommen worden, da der Blick in die Vergangenheit einen wesentlichen Einfluss auf die durchzuführenden wissensintegrativen Prozesse hat und die Betrachtung der Zukunft die Auswirkungen der aktuellen Kommunikationssituation im Team zeigt. In den RPD-Teams liegt zu Beginn der Arbeiten eine harte Emergenz vor, da bei der Diskussion der ersten Ideen nur grobe Ziele feststehen. Es liegt keine vollständige Beschreibung der Idee, des Problems bzw. des Sachverhaltes vor. Das bedeutet, dass wesentliche Informationen fehlen, die für einen effektiven Austausch wichtig sind. Außerdem steht zu diesem Zeitpunkt noch nicht fest, ob überhaupt die richtigen Experten zusammengeführt worden sind. Die harte Emergenz beschreibt somit die Ausgangssituation, unter der im Rahmen des RPD kommuniziert werden muss. Ein Weg, speziell für die asynchrone Kommunikation, emergente Kommunikation zu strukturieren, ist die Erarbeitung von Sprechakten, die helfen, Probleme, Wirkzusammenhänge und intendierte Handlungen zu beschreiben. Sprechhandlungen können als Basis dienen, die Kommunikationsanforderung zu strukturieren und den heute noch immer relativ unstrukturierten asynchronen Informationsaustausch zu definieren, da gleiche Äußerungen die Absicht einer Mitteilung, eines Versprechens, einer Warnung oder einer Drohung haben können. Jede Reaktion auf einen Kommunikationsakt hält sich an (implizite) Konventionen (Kontingenz), nach denen diese erfolgen sollen. Daher sind Sprechen, Handeln, Situationsbezug, Erfahrung und die Einflüsse aus der umgebenden Realität immer unauflösbar miteinander verbunden [4.203]. Die richtige Deutung ist jedoch abhängig von der gemeinsamen und individuellen Verstehensebene, die die beteiligten Kommunikationspartner verbindet. Im RPD treffen Experten aufeinander, die in unterschiedlichen fachlichen Zusammenhängen arbeiten. Die Frage stellt sich, inwieweit Mitteilungen näher konkretisiert oder spezifiziert werden können, damit die kontextrelevanten Informationen richtig und verständlich übermittelt werden. Das Gelingen einer Handlung ist kein fest definierter Zustand, sondern ein relatives Ziel [4.88]. Diese Relativität wird durch die unterschiedlichen Verstehensvoraussetzungen beim Sender und beim Adressaten hervorgerufen. Zur Erfüllung einer Erwartung haben der synchrone Sprechakt und der asynchrone Schreibakt unterschiedliche Voraussetzungen, da beim Sprechakt die Möglichkeit einer direkten Rückmeldung durch den Kon-

278


taktpartner gegeben ist. Um die Differenzen zu vermindern ist eine gleichgewichtige Explizierung beiderseitiger Bedingungen erforderlich. Differenzen zwischen dem Sprechakt (mündliche Kommunikation) und dem Schreibakt (schriftliche Kommunikation) sind von Henne [4.88] näher untersucht worden. Er weist darauf hin, dass dem Sprechakt die weitergehende Eigenschaft der Spontanität unterliegt. Der Schreibakt kann hingegen rückgängig gemacht werden, solange die Aufzeichnung noch nicht versandt ist, so dass sich eine Möglichkeit zur Überarbeitung und Reflexion bietet. Dabei finden bei dem Verfasser meist schon erste Überlegungen über die Auswirkungen der Nachricht beim Empfänger statt, wodurch Kontingenzen und Störgrößen zur Wirkung kommen. Anlehnend an Austin [4.6] ergeben sich bei Sprechakten drei wichtige Wirkhandlungen: x Der lokutionäre Akt umfasst die gesamte Handlung des Aussprechens eines Satzes. Er umschreibt alles, was der Sender an Wörtern mit einer bestimmten Bedeutung äußert. Allerdings hat das Geäußerte noch keine Bedeutung für den Empfänger. Somit steht die Äußerung frei im Raum. x Der illokutionäre Akt beschreibt die Kategorisierung der Äußerung aus der Sicht des Senders. Somit wird die Art der Handlung (Frage, Befehl, Aussage) festgelegt und die Absicht des Sendenden deutlich. x Der perlokutionäre Akt beschreibt die vom Sender beabsichtigten Effekte des Sprechaktes auf die Empfänger. Somit ergeben sich Konsequenzen aus den Wirkungen des Sprechaktes auf den jeweiligen Empfänger und (je nach Sozialisation) ein entsprechendes Verhalten. Der lokutionäre Akt stellt die Art der Explizierung der Informationen des Senders dar. Der illokutionäre Akt verdeutlicht die Absicht des Senders und muss somit in einer Nachricht erkennbar sein. Der perlokutionäre Akt ist der zentrale Kommunikationsakt und wirkt sich auf den Sender und den Empfänger aus. Die nicht vom Sender beabsichtigte Wirkung auf die Kommunikationspartner stellt das zentrale Kriterium für Kommunikationsbrüche dar. Somit muss versucht werden, eine Gleichheitsbeziehung zwischen den beabsichtigten und den eintretenden Effekten einer Sprechhandlung bei asynchroner Kommunikation zu erreichen. An dieser Stelle werden die Anforderungen an das Team und die wissensintegrativen Prozesse deutlich. Durch die unterschiedlichen Verstehenswelten besteht sowohl in der Teamkonstellation als auch bei der Wissensintegration die Gefahr, dass ein perlokutionärer Akt missglückt und damit die vom Sender begonnene kommunikative Handlung nicht den gesetzten Erwartungen des


279

Senders entspricht. Dies kann zum einen an der mangelnden Explizierung der Absichten durch den Sender liegen. Zum anderen besteht die Gefahr, dass der Sender nicht auf dem Sprachniveau des Empfängers ist und somit die Nachricht einfach nicht verstanden wird. Für das teamorientierte Kommunikationssystem wurde versucht auf der Grundlage der Sprechakt-Theorie Methoden und Tools zu entwickeln, die den multidisziplinären Teams im RPD helfen, Missverständnisse zu vermeiden und somit effizienter zu kommunizieren. Zusätzlich wurde zurückgegriffen auf Argumentationsmodelle, die eine bessere Strukturierung von Kommunikationsvorgängen zum Ziel haben. Ziel war es, Modelle für eine Art „Kommunikations-Workflow“ zu entwickeln und diese Modelle softwaretechnisch umzusetzen. Workflow-Systeme helfen dort, wo standardisierte Abfolgen existieren und bekannte Prozesse und deren Einflüsse genutzt werden können. In diesem Zusammenhang bedeutet das Management eines Workflows die Modellierung, Optimierung und Automatisierung von Geschäftsprozessen. Gemeint sind sämtliche Prozesse, die im Rahmen eines betrieblichen Umfeldes anfallen und zu einem definierten Ziel hin ablaufen. Auch für die Kommunikation in der Produktentwicklung spielt ein situativ strukturierter Ablauf eine wichtige Rolle. Hierdurch können Informationswege minimiert und die Nachrichten gezielt an weiterverarbeitende Instanzen (Agenten, Experten) weitergeleitet werden. Für die nur schlecht standardisierbaren Prozesse in der evolutionären Produktentwicklung bietet sich die Umsetzung eines kommunikationsbasierten Workflows im Gegensatz zum Aktivitäten gesteuerten Workflow an. Der Aufbau eines solchen Workflows kann im Vergleich zu den Arbeiten der Argumentationsstrukturierung betrachtet werden. Seit den 50er Jahren werden Argumentationsmodelle vielseitig genutzt. Vornehmliches Interesse der IBIS Methode (Issue Based Information System) war es, Diskussionsvorgänge zu archivieren und mittels einer formalen Struktur übersichtlich darzustellen [4.115]. Hierdurch sollten Diskussionen in größerem Umfeld und ein Wiederauffinden von Argumenten unterstützt werden. Eine Aufstellung unterschiedlicher Systeme wurde von Ludwig [4.132] vorgenommen. An dieser Stelle sollen nur einige wichtige genannt werden: x Das sprechaktbasierte System Coordinator definiert eine Organisation als Netz von Verpflichtungen. Hierdurch werden die einzelnen Aktivitäten transparent gemacht [4.38]. Jedoch sind die Handlungen fest miteinander verknüpft, sodass sie den evolutionären Prozessen nicht gerecht werden.

280


x Der Prototyp SEPIA ist ein hybrides Argumentationsstrukturierungsprogramm. Hierfür stehen sowohl synchrone als auch asynchrone Kommunikationsabläufe zur Verfügung [4.187]. Auch dieses System unterstützt das gemeinsame Arbeiten an Vorgängen. Konzeptionell kann dieses System als Grundlage für ein Management der Kommunikation im RPD genutzt werden. x Das System COSMOS (Configurable Structured Message Oriented System) unterstützt, basierend auf der Sprechakt-Theorie, die Kommunikationsvorgänge, insbesondere im Büroumfeld. Dieses System darf von dem Nutzer frei strukturiert werden, jedoch kann der Empfänger nur so antworten wie der Sender es ihm zugesteht [4.202]. Für die Arbeiten am teamorientierten Kommunikationssystem wurden Erkenntnisse aus diesen Projekten genutzt, um auf die spezifischen Anforderungen des RPD zugeschnittene Modelle und Lösungen zu erarbeiten. 4.3.4 Methoden Ziel der Arbeiten im Sonderforschungsbereich 374 war es, innovative Konzepte für ein Kommunikations- und Kooperationssystem für die verteilte Produktentwicklung zu erarbeiten und prototypisch umzusetzen. Um neben einer reinen Technikentwicklung auch den zukünftigen Benutzer von Anfang an zu berücksichtigen, sollten vor allen Dingen methodische Verfahren für eine benutzerzentrierte Systemgestaltung Anwendung finden. Im Gegensatz zur technozentrierten Gestaltung, bei der das technisch Machbare im Mittelpunkt des Interesses steht, wird hier sichergestellt, dass das entwickelte System den Anforderungen von Mitarbeitern und Arbeitsprozessen entspricht, die Benutzungsschnittstellen softwareergonomisch gestaltet sind und durch spezifische, für den konkreten Anwendungsfall entwickelte Funktionalitäten Verbesserungen in der Arbeitsorganisation und im Arbeitsablauf ermöglicht werden. Im RPD wird bewusst vermieden, den Prozessablauf von Beginn an festzulegen. Daher können keine Methoden angewendet werden, die eine Analyse und Gestaltung des Systems basierend auf einer Prozessanalyse vornehmen. Ebenso wenig helfen Ansätze, die die Informations- und Dokumentenflüsse analysieren, da sich diese dynamisch im evolutionären Fortschritt der Zusammenarbeit ändern. Für die Realisierung der Kooperationsplattform wurde daher ein experimenteller Ansatz gewählt, um auf Anwenderrückmeldungen effektiv reagieren zu können. Angestrebt war die anwendungsorientierte Entwicklung von Kommunikations-


281

Basistechnologien unter Berücksichtigung von Benutzeranforderungen bei der ergonomischen Gestaltung von interaktiven Systemen. Die Vorgehensweise wurde an ISO 13407 „Benutzergerechte Gestaltung interaktiver Systeme“ angelehnt und umfasst die fünf Phasen x x x x x

Szenarienbasierte Anforderungserhebung Konzeption und Spezifikation Prototypenentwicklung und Integration Evaluation, Test und Verifikation Auswertung der Ergebnisse und Dokumentation

In den fünf Phasen wurden unterschiedliche Methoden für das Design, die Entwicklung und die Evaluierung der Softwareprototypen verwendet. Für das Design und die Prototypenentwicklung kamen herkömmliche Unified Modeling Language (UML)-Verfahren bzw. Softwaretestverfahren zum Einsatz [4.20], [4.73]. Den methodischen Kern der Arbeit bilden benutzerzentrierte Verfahren des Usability Engineering und Testing. Grundlage dieser Verfahren ist ein partizipativer und iterativer Ansatz. Die Entwicklung des Systems durchläuft dabei mehrere Zyklen, in denen die zukünftigen Benutzer direkt in die Evaluation eingebunden werden. Da es sich bei diesen Evaluationsverfahren nicht um vergleichende Studien zwischen verschiedenen Unterstützungsmöglichkeiten handelt, kann lediglich die Ausführung der einzelnen Arbeitsschritte sowie das erreichte Gesamtergebnis hinsichtlich der gestellten Arbeitsaufgabe beurteilt werden. Der Fokus der Untersuchungen liegt in diesem frühen Entwicklungsstadium eines Systems auch weniger auf dem Vergleich mit anderen Systemen als auf der Sicherstellung der Konsistenz des Benutzungskonzepts sowie der Eignung des Systems für die Anwendungsszenarien. In der Konzeptionsphase und in der Evaluierungsphase wurden Inspection Verfahren auf Basis der „Mechanics of Collaboration“ [4.8], [4.9] und der „Collaboration Usability Analysis“ [4.148] verwendet. 4.3.5 Ergebnisse Basierend auf dem von Teilprojekt „Arbeitswissenschaftliche Konzeptionierung kooperativer Arbeitsformen für die Entwicklung innovativer Produkte“ (Kap. 2) entwickelten Kooperationsmodell wurde ein erster Prototyp der Kooperationsplattform als „Proof of Concept“ entwickelt [4.192], [4.196]. Dieser Prototyp wurde in einer WAMP-Umgebung (Windows Betriebssystem, Apache Web Server, MySQL Datenbank, PHP Scriptsprache) und der SCOL-Entwicklungsumgebung für Mehrbenutzer 3D-

282


Umgebungen implementiert. Die Entscheidung zugunsten von SCOL gegenüber VRML-basierten Formaten fiel insbesondere aus zwei Gründen: x Das SCOL-Format erwies sich als wesentlich performanter im Betrieb über das Internet als die VRML Systeme (SGI Cosmo, blaxxun, etc.) x Die SCOL-Umgebung bietet neben einer Mehrbenutzerfähigkeit auch eine Menge integrierter Kommunikationsmodule (Chat, Instant Messaging Audio/Videokonferenz). Diese Funktionen konnten bei den anderen betrachteten Systemen nur durch zusätzliche Programme bzw. Plugins realisiert werden. Der entwickelte Prototyp stellt neben den oben genannten Kommunikationstechnologien auch die Möglichkeit, Präsentationen und Videofilme in mehrere dreidimensionale Teamräume vorzuführen, zur Verfügung. Auf der Weboberfläche konnte zusätzlich ein Shared Whiteboard für gemeinsame Skizzen und Zeichnungen verwendet werden. Für die asynchrone Kommunikation stand ein datenbankbasiertes Nachrichtensystem zur Verfügung. Teamstrukturen, Mitarbeiterprofile und der Status der Mitarbeiter konnten sowohl innerhalb dieses Nachrichtensystems als auch in der 3D-Umgebung visualisiert werden. Bei Tests in verschiedenen Anwendungsszenarien zeigte sich, dass die Kommunikationsmöglichkeiten von den Anwendern zwar positiv aufgenommen, die Visualisierung von Prototypen jedoch als nicht ausreichend empfunden wurde. Zum einen wurde die mangelnde Beweglichkeit der 3D-Objekte kritisiert, zum anderen der statische Zustand der virtuellen Umgebung. Da 3D-Content nicht dynamisch während einer Sitzung geladen werden konnte, konnte nur eine begrenzte Auswahl von Objekten betrachtet werden. Dies und die Notwendigkeit, das System mit den anderen Systemen der IT-Plattform zu integrieren, führte zu der Entscheidung, ein webfähiges 3D-Mehrbenutzersystem von Grund auf neu zu entwickeln. Dieses System sollte einerseits die notwendigen Features für die Visualisierung von virtuellen Prototypen (dynamisches Laden zur Laufzeit, Bewegen, Skalieren, Editieren) zur Verfügung stellen und andererseits Schnittstellen für andere Applikationen bieten, die eine Integration in das Gesamtsystem erlauben. Die Funktionen des realisierten Software-Prototyps werden im Folgenden geschildert. Das integrierte Kooperationssystem benutzt das ASN (Kap. 4.1 „Ganzheitliche Modelle zur Repräsentation aktiven Wissens“) bzw. die entwickelte agentenbasierte Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“) und umfasst folgende Bestandteile:


x x x x x x

283

Dreidimensionale Teamräume Sprechaktbasiertes Nachrichtensystem Groupware-Anwendungen (Terminkalender, Gruppenordner, etc.) Automatisierte Terminplanung unter Nutzung der Agententechnologie Audio/Videokonferenzsystem Kooperative Augmented Reality

Abb. 4.31. Integration der 3D Teamräume und der asynchronen Anwendungen im Portal

Diese Bestandteile wurden an verschiedenen Stellen in das entwickelte RPD-Portal (Kap. 4.4 „Adaptive Benutzungsoberflächen“) integriert, sodass dem Anwender ein Information und Kommunikation integrierendes System zur Verfügung steht, auf das benutzerfreundlich über eine einheitliche Webschnittstelle zugegriffen werden kann (s. Abb. 4.31.). Bei den Groupwareanwendungen und dem Audio-/Videokonferenzsystem wurde auf bestehende Softwarelösungen zurückgegriffen. Die folgende Darstellung konzentriert sich auf die Eigenentwicklungen für das teamorientierte Kommunikationssystem.

284


Dreidimensionale Teamräume Ziel bei der Realisierung war es, ein erweiterbares Multi-User-System zu schaffen, in das einfach weitere Funktionalitäten und Applikationen eingebunden werden können. Aus diesem Grund wurde eine Kernanwendung entwickelt, die es erlaubt, zusätzliche Funktionalitäten in Form von PlugIns zu programmieren und anzuschließen. Die Anwendung wurde in Java unter Verwendung der Java 3D-API geschrieben. Um die Anwesenheit eines Nutzers darzustellen, ist jeder durch ein sogenanntes Avatar in der 3D-Umgebung repräsentiert. Jeder Benutzer kann Wände generieren, auf denen Präsentationen (z.B. erstellt mit MS Powerpoint), 2D-CAD-Zeichnungen, Projektpläne, etc. dem Team gezeigt werden können. Des Weiteren können Moderationswerkzeuge (Kartenabfrage, Ein-Punkt Abfrage, etc.) zur Strukturierung von Sitzungen genutzt werden, um die Wissensintegration der beteiligten Experten zu fördern. Mit Hilfe von verschiedenen Importfiltern (VRML, X3D, LWO) können virtuelle 3D-Prototypen in diesem Raum visualisiert werden. Es wurden Editorfunktionalitäten implementiert, die es erlauben, 3D-Skizzen zu erstellen und Prototypen zu modellieren. Diese Funktionalitäten können z.B. für Designabsprachen oder Einbauuntersuchungen genutzt werden. Der Austausch der Interaktionsdaten über das Internet findet über ein eigens entwickeltes XML-Protokoll statt: das MU3D. MU3D ist ein XML-basiertes Protokoll zum Austausch von Interaktionsdaten in verteilten 3D-Anwendungen. Die Implementierung, die clientseitig hinter den einzelnen Tags gehalten werden, sind in Java realisiert. Die ankommenden XML-Dokumente werden von einem SAX Parser ausgewertet. Nach Benutzer-Tags getrennt wird dann intern eine Datenstruktur aufgebaut, die die Baumstruktur der ankommenden Daten abbildet. Diese Daten werden an die einzelnen Userinstanzen weitergegeben; sie entscheiden dann, ob Elemente eingefügt oder aktualisiert werden sollen. Alle aufwendigen Objekte werden in eigenen Threads konstruiert und erst nach Fertigstellung in die Szene eingefügt. Es ist möglich, beliebig komplexe Zusammenfassungen von Funktionen durch die Definition eines Tags in das Protokoll einzubinden. Das Protokoll erlaubt es also, das System individuellen Bedürfnissen anzupassen und anwendungsbezogen zu erweitern. Insofern ist dieses System nicht nur für den Einsatz in der Produktentwicklung nützlich, sondern bietet auch in anderen Branchen und Anwendungsgebieten vielfältige Einsatzmöglichkeiten. Das Protokoll bietet auch die Möglichkeit, Zustände und Abläufe in den 3D-Welten abzuspeichern und zu einem späteren Zeitpunkt wieder in den


285

Server einzuschleifen und somit wiederzugeben. Dadurch können ganze Sitzungen konserviert bzw. protokolliert werden. Ein Teamraum besteht aus den kreisförmig angeordneten Arbeitsplätzen der Teammitglieder und einem Teambereich, in dem team- und arbeitsrelevante Informationen visualisiert und Teambesprechungen durchgeführt werden können. Der Arbeitsplatz (s. Abb. 4.32.) eines Teammitglieds zeigt im Falle seiner Abwesenheit seinen Status an. Wenn der Benutzer nicht eingeloggt ist, wird „Offline“ angezeigt. Ist der Benutzer „online“, aber gerade nicht an seinem Arbeitsplatz, hat er die Möglichkeit, seinen momentanen Status einzugeben. Hierzu steht ihm ein Eingabefeld zur Verfügung, das verschiedene vordefinierte Stati und zusätzlich eine freie Eingabe anbietet. Der Benutzer kann zudem eingeben, wo und auf welche Weise er zu erreichen ist. Die Erreichbarkeit wird auch im Offline-Status angezeigt. Der Benutzer hat weiterhin die Möglichkeit, die Aufnahme einer Webcam von seinem realen Arbeitsplatz für die anderen sichtbar zu machen. Jedes Teammitglied kann von seinem Arbeitsplatz 3D-Objekte, Anzeigetafeln, persönliche asynchrone Groupwarekomponenten und Screenshots seines Bildschirms laden.

Abb. 4.32. Arbeitsplatz mit Visualisierung der aktuellen Bildschirmansicht

286


Im Teambereich (s. Abb. 4.33.) können team- bzw. projektrelevante Informationen über Anzeigetafeln visualisiert werden.

Abb. 4.33. Teambereich mit geladener Präsentationswand und einem Prototyp. Die Avatare sind in dieser Version als Augen dargestellt, um die Blickrichtung anzuzeigen.

Dieser Bereich ist als Informations- und Kommunikationsraum gedacht, daher kommen hier die Moderationswerkzeuge zum Einsatz, die an den einzelnen Arbeitsplätzen nicht zur Verfügung stehen. Asynchrones Nachrichten-System Das Nachrichtensystem erweitert herkömmliche E-Mail-Funktionalitäten um personen- und kontextrelevante Parameter. In multidisziplinär arbeitenden Teams im RPD zeigt sich, dass bei herkömmlichen Kommunikationssystemen (basierend auf E-Mail) ein Defizit hinsichtlich der Explizierung der Absichten besteht. Um diesen Mangel zu minimieren, bietet der Prototyp des asynchronen Nachrichtensystems die Darstellung erweiterter Informationen. Das konzipierte und entwickelte sprechaktbasierte Modul zur asynchronen Kommunikation bietet gegenüber der E-Mail ein „reichhaltigeres“ Werkzeug, insbesondere im Hinblick auf die zeitliche und inhaltliche kommunikationsbasierte Wissensintegration [4.12], [4.29], [4.30], [4.31], [4.36]. Durch die einheitliche und strukturierte Ablage von Informationen und die Integration von zeitlichen und inhaltlichen Parame-


287

tern in die Nachricht (Antwortzeit, Sprechakt, etc.), unterstützt dieses System effektiv die unterschiedlichen Sprechakte (Handlungsbedingungen). Der Empfänger bzw. die Empfängergruppe erhält eine Sicht auf die Daten, bei der beim Abruf von Nachrichten keine großen Datenmengen übertragen werden müssen. Im Folgenden wird das Modul des asynchronen Nachrichten-Systems als Software-Prototyp mit seinen Funktionalitäten näher erläutert. Entsprechend der Kodierung bei einer E-Mail Adresse wird der Nutzer personalisiert über seinen Namen und seinen Lokalisierungsbereich (name@domain) definiert. Diese Kennung hat den Vorteil, dass anhand der Systemadresse bereits klar ist, um wen es sich handelt. Anhand der Lokalität ist eine eindeutigere Identifizierung der Person möglich. Die zusätzliche Eingabe eines Passwortes sichert dabei das System vor Fremdnutzung. Nach erfolgreichem Login erscheint die Sicht auf die Daten. Diese Sicht besteht aus einer Navigationsleiste, die den Zugriff auf: x x x x

neue Nachrichten alte Nachrichten unbeantwortete bzw. vom Empfänger noch nicht gelesene Nachrichten eigene gesendete Nachrichten

ermöglicht. Weiterhin werden von diesem Fenster aus die persönlichen Einstellungen des Nutzers vorgenommen. Zum einen kann von hier seine aktuelle Auslastung und sein Erreichbarkeits-Status definiert werden. Er kann außerdem seine Arbeitsgebiete und Aufgaben aktualisieren. Bei kontinuierlicher Pflege dieser Daten ergibt sich ein Leistungsportfolio des Nutzers, das es ermöglicht, die eigenen Wissensbereiche dem Team zu visualisieren. Zum anderen kann das Passwort an dieser Stelle aktualisiert werden. Abb. 4.34 zeigt die Übersichtsseite und die separaten Fenster zur Änderung des Profils und des Passwortes.

288


Abb. 4.34. Übersichtsseite des Nachrichtensystems

Wählt der Nutzer die „neuen Nachrichten“ aus der Übersichtsseite, so sind alle Projektbereiche für ihn ersichtlich. Die neuen Nachrichten befinden sich gesammelt in der obersten Struktur, können aber auch direkt sortiert nach den Bereichen eingesehen werden, sofern diese vom Sender spezifiziert wurden. Die Struktur der Ordner ist für alle Teammitglieder die gleiche und wird vom Administrator bzw. Nutzer mit AdministratorRechten festlegt. Hierdurch wird vermieden, dass zum gleichen Thema unterschiedliche Kategorien angelegt werden, sodass sich bei der Ablage alle an die gleiche Struktur halten müssen. Diese wird in einer gemeinsamen Sitzung festgelegt und vom Administrator im System angelegt. Neben dem Sender und dem Betreff der Nachricht wird die erwartete Antwortzeit und der Sprechakt visualisiert. Hierdurch kann die Absicht des Senders schnell identifiziert und die Nachrichten können nach den vorab definierten Kontingenzen beurteilt werden. Die Festlegung der Kontingenzen wird in einem gemeinsamen Workshop vorgenommen und in Form ei-


289

ner Teamregel festgehalten. Nur wenn alle Beteiligten sich an diese Regeln halten, kann die Effektivität im Nachrichtenaustausch gesteigert werden. Als weitere Funktionalität kann der Nutzer die Spalten für ihn sortiert anzeigen lassen. Somit sind mehrfache Sortierungen je nach Bedarf des Anwenders möglich.

Abb. 4.35. Webseite „Nachricht verfassen“ mit den Sprechaktlisten

Das Verfassen einer Nachricht ist über ein Eingabefenster (Abb. 4.35.) möglich. Neben den standardisierten Eingaben (die in einer E-Mail zu finden sind) werden hier weitere Informationen hinzugefügt. Die Felder ermöglichen die Zuordnung der Nachricht zu den definierten Projektbereichen, der Priorisierung, dem Sprechakt (die Absicht hinter der Nachricht), dem expliziten Wunsch nach einem Feedback, der Antwortzeit und dem Verfallsdatum der Nachricht. Das Verfallsdatum dient dazu, die Informationen im System auf einem aktuellen Stand zu halten. Hierdurch wird die Eingangsbox der Nutzer von bereits nicht mehr relevanten Nachrichten entlastet. Die Felder werden, ebenso wie bei den Projektbereichen, mittels

290


des Administrations-Werkzeuges vordefiniert. Hierdurch wird ein einheitliches Auftreten innerhalb des Teams gewährleistet. Dieser Ansatz folgt dem heute gängigen Verfahren einer „moderierten“ Sitzung. Teil der Arbeiten zum sprechakt-basierten Nachrichtensystem war auch die Untersuchung von Technologien, die es ermöglichen, durch unterschiedliche Endgeräte auf einen gemeinsamen Datenbestand zuzugreifen. Die Nutzung von IP-Telefonen und Mobiltelefonen mit integriertem Browser ermöglicht die Visualisierung zentral erfasster Daten. Abb. 4.36 zeigt die Umsetzung einer WAP-Integration mit dem Zugriff auf die gemeinsame Groupware.

Abb. 4.36. WAP Interface auf einem IP-Telefon und einem Handy

Unterstützung von Terminabsprachen durch den automatischen Terminplaner Terminabsprachen sind zeitaufwendig. Die Automatisierung bestimmter Teile einer Terminabsprache, wie z.B. der Suche nach einem freien Zeitpunkt für ein Treffen oder die Reservierung von Ressourcen, die für die Durchführung des Treffens notwendig sind, würde den Zeitaufwand für alle Beteiligten wesentlich reduzieren. Für das teamorientierte Kommunikationssystem wurde in Zusammenarbeit mit der Entwicklung der RPD-Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“), die Agenten zum Auffinden und Koordinieren von Daten, die im ASN abgelegt sind, bereitstellt, prototypisch eine Software entwickelt, die einen großen Teil der Terminplanung automatisiert. Der Prototyp ermöglicht es, die Termine einer beliebigen Anzahl Teilnehmer zu koordinieren. Dabei werden verschiedene Parameter wie z.B. Ort (online, im Haus, regional, national, in-


291

ternational, Berücksichtigung der Reisezeit), benötigte Ressourcen (Raum, Tafeln, Beamer, etc.), Thema (Einladung zusätzlicher Experten) berücksichtigt. Wird ein Termin eingetragen, kann der entsprechende Benutzer über verschieden Endgeräte (mobile Anbindung) benachrichtigt werden.

Abb. 4.37. Use Case Modell für den Anwendungsfall „Termin anlegen“

Beispielhaft ist in Abb. 4.37 der Anwendungsfall „Termin anlegen“ dargestellt. Der Initiator gibt hier Terminbeginn und das Terminende vor. Des Weiteren grenzt er den Suchraum für die Zeitplanung ein, d.h. das Intervall, in dem letztendlich ein Termin gefunden werden soll, falls der Termin zu dem ursprünglich gewählten Zeitpunkt nicht festgesetzt werden konnte. Er wählt die Teilnehmer, die er zum Termin einladen möchte und benennt das Thema und den Ort des Treffens. Mit diesen Daten werden der Retrieval- und der Koordinationsagent gefüttert, die im ASN nach möglichen Terminen suchen. Eine anwendungsinterne Logik steuert die Rückgabedaten der Agenten und setzt den neuen Termin fest. Wenn ein Termin

292


erfolgreich gesetzt werden konnte, so wird er im ASN gespeichert und eine Benachrichtigung wird an alle Teilnehmer versendet. Konnte kein Termin festgelegt werden, so wird der Benutzer über den Grund der fehlgeschlagenen Terminfestlegung informiert. Weitere Funktionen (Termindaten ändern, Teilnehmer entfernen, Termin löschen, Benachrichtigung versenden und Termine anzeigen) werden über eine Weboberfläche im Portal zur Verfügung gestellt. Bestimmte Funktionen, wie z.B. das Ändern eines Termins, werden dem Benutzer nur präsentiert, falls er die nötigen Rechte besitzt, d.h. in diesem Fall muss er der Initiator des Termins sein.

Abb. 4.38. Benutzerschnittstelle für den automatischen Terminplaner

Kooperative Augmented Reality Arbeiten an einem Modul für kooperative Augmented Reality (AR) sind in den letzten zwei Jahren in Zusammenarbeit mit dem Teilprojekt „Visualisierung und Simulation physikalisch-technischer Vorgänge“ (Kap. 5.5) begonnen worden. Durch die von diesem Teilprojekt entwickelten AR-Methoden lassen sich bestehende Produktentstehungsvorgänge weiter beschleunigen. Entwickler können gemeinsam über dasselbe Bauteil diskutieren und Designfragen klären. Beispielsweise können Materialeigenschaften wie Farbe oder Oberflächenstruktur während der Simulation verändert werden. Ebenso


293

ist es möglich, bewegliche Teile, Umformprozesse oder Strömungsverläufe zu simulieren. Allerdings mussten sich die Teilnehmer dazu an einem gemeinsamen Standort versammeln. Ziel der Arbeiten am teamorientierten Kommunikationssystem war es, einerseits die Software so zu erweitern, dass kooperative AR an verteilten Standorten ermöglicht wird und andererseits das System in die Kooperationsplattform zu integrieren. Um das kooperative Arbeiten mit AR zu ermöglichen, wurde in die von dem Teilprojekt „Visualisierung und Simulation physikalisch-technischer Vorgänge“ (Kap. 5.5) entwickelte Software „OpenCOVER“ ein Modul „RemoteAR“ eingebunden, dass der Übertragung eines Kamerabildes dient. Dieses Kamerabild nimmt die Umgebung der Senderseite, in der ein physischer Prototyp präsentiert wird, auf. Auf diesem Prototyp sind Marker angebracht, die es erlauben, Bewegungen des Prototypen zu tracken und ergänzende virtuelle Inhalte korrekt zu platzieren. Das Bild wird in ein Video kodiert und übertragen. Auf Empfängerseite können nun 2D- und 3D-Inhalte (Bauteile, Simulationen, etc.) auf die Marker gesetzt werden. Die Software berechnet das überlagerte Gesamtbild und überträgt es an alle Teilnehmer. Bisher wurde das System mit einer Framerate von 7 bis 12 Bildern pro Sekunde bei einer Bildauflösung von 800 x 600 Pixeln getestet. Zusätzlich zu den reinen Videodaten werden noch Parameter wie Auflösung, Framerate etc. übertragen, die auf dem Zielrechner für die korrekte Darstellung des Bildes benötigt werden. Zusammenfassung der Ergebnisse Die für die Entwicklung innovativer Produkte notwendige gemeinsame Verständnis- und Wissensbildung setzt einen intensiven Kommunikationsprozess unter den beteiligten Experten voraus. Der intensive Austausch von Wissen muss auf Strukturen basieren, die einer direkten (d.h. nicht durch ein Medium gefilterten) Kommunikation nahe kommen, um die durch die Dezentralisierung der Teams gesetzten räumlichen und zeitlichen Barrieren zu minimieren. Ein Prototyp für ein integriertes Kommunikationssystem für vernetztes Arbeiten wurde realisiert. Die durchgeführten Forschungs- und Entwicklungsarbeiten an diesem Prototyp können in die Bereiche der asynchronen und der synchronen Kommunikation aufgeteilt werden. Asynchrone Kommunikation Die Anzahl an Informationen steigert die Komplexität in der Zusammenarbeit, sofern dem Nutzer keine Hilfsmittel gegeben werden, diese Kom-

294


plexität zu reduzieren. Um Komplexität beschreiben zu können, wurde unter der Sichtweise der Emergenz die Interaktion in den verteilten Teams näher analysiert. Hierdurch sind Einflussparameter identifiziert worden, die eine Störung der Kommunikation in der verteilten Zusammenarbeit über Fachdisziplinen hinweg verursachen können. Durch die Entwicklung von Sprechakten, die in der Übermittlung explizit übertragen werden, werden intendierte Handlungen mit überliefert. Hieraus ergeben sich einheitliche Verhaltensmuster im Team, die zu weniger Störungen in der Zusammenarbeit führen. Es wurde ein asynchrones Kommunikationssystem entwickelt, das die Eigenschaften herkömmlicher, asynchroner Nachrichten um inhaltsspezifische und für die Gruppenwahrnehmung relevante Informationen erweitert. Die Software baut auf den gemeinsamen Informationen aus dem ASN, der Datenbasis für kommunikationsrelevante Daten, einem Webserver, zur Erreichbarkeit über das Internet, und Java Server Pages (JSP)-Skripten, zum Aufbau semistrukturierter Kommunikation, auf. Das System hilft den Beteiligten, Intentionen und Ziele der asynchronen Nachrichten zu explizieren und zu gewichten. Um zeitaufwendige Terminabsprachen zu verkürzen wurde in Zusammenarbeit mit der Entwicklung der RPD-Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation Rapid Product Development“) ein System zur automatischen Terminplanung entwickelt. Das System nimmt Terminwünsche unter Berücksichtigung von Zeit, Ort (Anreisezeit), benötigten Ressourcen und eventuellen zusätzlichen Experten auf und sucht den bestmöglichen Termin für alle Beteiligten automatisch. Synchrone Kommunikation Die in der Forschung zum Thema Collaborative Virtual Environments (CVE) häufig verwendete Raummetapher wurde für die Entwicklung der synchronen Kommunikationstechnologien übernommen und in Form eines dreidimensionalen virtuellen Arbeitsraums umgesetzt. Aufgrund des hohen Kommunikations- und Koordinationsbedarfs im RPD lagen neben Arbeiten zur Unterstützung der Gruppenwahrnehmung (Awareness) die Schwerpunkte auf der Entwicklung verteilter Präsentations-, Moderationsund Visualisierungswerkzeuge. Diese Werkzeuge dienen der Kommunikationsstrukturierung und der Veranschaulichung von Sachverhalten, beides wichtige Vorraussetzungen für eine gelungene Kommunikation und Wissensintegration in multidisziplinären Teams. Es wurde ein 3D-Multi-UserSystem entwickelt, das es verteilt arbeitenden Teams erlaubt, sich an einem virtuellen Arbeitsplatz zu treffen, multimodal zu kommunizieren und Besprechungen zu strukturieren. Von entscheidender Bedeutung im iterativen Prozess des RPD ist die Präsentation von Modellen und virtuellen

4.4 Adaptive Benutzungsoberflächen

295

Prototypen. Daher bietet die virtuelle Umgebung die Möglichkeit, virtuelle Prototypen zu visualisieren und in begrenztem Umfang zu editieren bzw. zu modellieren. Für den Austausch der Interaktionsdaten wurde ein XMLbasiertes Protokoll entwickelt, das als Schnittstelle zu anderen Applikationen bzw. Endgeräten dient. In Zusammenarbeit mit dem Teilprojekt „Visualisierung und Simulation physikalisch-technischer Zusammenhänge“ (Kap. 5.5) wurde ein System für kooperatives Arbeiten mit Augmented Reality Methoden erarbeitet. Das System ermöglicht die Zusammenarbeit an hybriden Prototypen über verteilte Standorte hinweg. Integriertes Kooperationssystem Das integrierte Kooperationssystem bietet sowohl im asynchronen als auch im synchronen Bereich eine Visualisierung von Teamstrukturen und ermöglicht damit eine bessere Orientierung bei der Team-TeamKooperation. Darüber hinaus wird das Auffinden und das sofortige Kontaktieren relevanter Ansprechpartner erleichtert. Die Werkzeuge für die asynchrone und synchrone Kommunikation wurden vollständig integriert und somit ein nahtloser („seamless“) Übergang von asynchroner zu synchroner Kommunikation verwirklicht. Das Kommunikationssystem ist weiterhin mit den Werkzeugen, die in anderen Teilbereichen entwickelt wurden, über das Portal und das ASN integriert worden.


4.4.1 Einleitung Die sehr heterogene, interdisziplinäre Arbeitsumgebung des Rapid Product Development (RPD) erfordert den Entwurf und die Realisierung von flexiblen und dynamischen Arbeitsumgebungen mit einem übersichtlichen Zugang zu den darin abgebildeten Informationsräumen. Eingebettet in dynamische Strukturen und Prozesse können sich nicht nur die Beteiligten, sondern auch die Arbeitsinhalte im Entwicklungsverlauf rasch ändern. Die Arbeitsumgebungen müssen in äußerst flexibler und dynamischer Weise an die sich wechselnden spezifischen Bedürfnisse eines Teammitarbeiters und dessen Aufgaben anpassbar sein. Die Teammitarbeiter vertreten verschiedene Disziplinen und Kompetenzen. Weiterhin unterscheiden sie sich durch unterschiedliche Qualifikationen und Ziele [4.184]. Ziel ist die op-

296


timale Unterstützung der RPD-Experten bei der Produktentwicklung und somit bei einem speziellen Problemlösungsprozess. Die Weiterentwicklung dieser Methoden zur Gestaltung einer adaptiven Benutzungsschnittstelle in Hinblick auf handlungsunterstützende Informations- und Problemlösungsangebote führt zum Modell des adaptiven webbasierten RPD-Portals. 4.4.2 Grundlagen von adaptiven Benutzungsoberflächen Portale Die starke Zunahme von Informationen und Applikationen innerhalb des RPD-Prozesses führt zu einer zunehmenden Belastung der Entwickler und Experten. Die angestrebte Arbeitsentlastung durch aufbereitete Informationen und vielfältige Problemlösungssoftware stellt sich wegen der hohen Komplexität als eher arbeitshemmend heraus. Durch die Einrichtung von Portalen soll dieser Problematik begegnet werden [4.180]. Dahingehende Ansätze aus der Industrie befassen sich vorwiegend mit der strukturierten Darstellung relevanter interner und externer Projektdaten in einem Standard Web Browser. So zum Beispiel in [4.2] und [4.16], wo das von der Gesellschaft für Mathematik und Datenverarbeitung (GMD) entwickelte BSCW-System vorgestellt wird. Dabei handelt es sich um einen „shared workspace“ der die kooperative Arbeit innerhalb eines Teams unterstützen soll. Ein anderes Projekt zur Navigation in hochdynamischen Intranets wurde von der Universität Zürich bearbeitet. Hier, in ABDRAII [4.155], wurden auch persönliche Portale erstellt. Liu [4.128] stellt die Vor- und Nachteile web-basierter Oberflächen dar. Zu den Vorzügen gehören schnelles Design und unkomplizierte Anpassung sowie die Unabhängigkeit von Betriebssystemen. Damit ist jedem Nutzer der Zugriff von einem beliebigen, mit einem Browser ausgestatteten Rechner möglich. Nachteile sind Sicherheitslücken und die mit der Webtechnologie üblicherweise verbundene Fensterdarstellung, denn eine zu große Anzahl sich überlappender Fenster kann schnell zu Unübersichtlichkeit führen. Die Gestaltungsanforderungen an ein Portal als Informationszugang sind [4.208]: hohe Benutzungsfreundlichkeit, fortwährende Aktualität, hoher Informations- und Nutzengrad sowie Individualisierbarkeit und Interaktivität. Ebenfalls zu berücksichtigen ist eine adäquate Anpassung der Hardware, um ausreichende Schnelligkeit zu gewährleisten.


297

Dialoggestaltung Die Kommunikation zwischen Mensch und Rechner erfolgt in Form eines Dialoges. Grundsätze der Dialoggestaltung sind: Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität und Fehlerrobustheit [4.53], [4.207]. Eine angemessene Dialoggestaltung sollte ferner das Einbringen des individuellen Erfahrungs- und Handlungswissens unterstützen sowie Besonderheiten und Präferenzen von Benutzern beachten. Der Dialog zwischen Mensch und Maschine muss in Aufbau und Ablauf an die zu unterstützenden Aufgaben und Prozesse sowie an die zukünftigen Benutzer und deren Fähigkeiten, Kenntnisse und Fertigkeiten angepasst werden [4.198], [4.13]. Berücksichtig werden sollen dabei [4.84]: x Humanorientierte Kriterien wie Bedürfnis nach Durchschaubarkeit, Vorhersehbarkeit und Beeinflussbarkeit der Arbeitsbedingungen, Freiheitsgrade bei der Aufgabenbearbeitung, minimales Beanspruchen mentaler Kapazität durch den Dialog, individuell unterschiedliche Denkund Arbeitsstile, individuelle Kenntnisse und Dialogerfahrungen, x Aufgabenbezogene Kriterien wie Benutzungshäufigkeit, Benutzungsintensität, Benutzungsregelmäßigkeit bei der Aufgabenbearbeitung sowie die Aufgabenkomplexität, x Interaktionstechnische Kriterien, also die Verantwortung für den Dialog und Initiative im Dialog zwischen Benutzern und Systemen. Arbeitswissenschaftliche Grundlagen Die adaptive Benutzungsoberfläche soll die Benutzer einerseits vor einer unüberschaubaren Informationsflut und erhöhter Systemkomplexität bewahren. Andererseits soll sie den Benutzern die Inanspruchnahme von Informationen und Werkzeugen zu jedem Zeitpunkt ermöglichen. Die Entscheidung, ob eine Adaption in der vorgeschlagenen Weise durchgeführt wird, sollte letztlich in jedem Fall beim Nutzer liegen. Bei Nutzervorschlägen muss vom System deren Realisierbarkeit geprüft werden. Dagegen bedeutet die Ausführung der Adaption für den Benutzer nur unnötige Arbeit, die daher vom System übernommen werden sollte. Dabei sind für die Gestaltung des Dialogs zwischen Menschen und rechnergestützen Werkzeugen folgende Kriterien besonders zu berücksichtigen [4.7], [4.95], [4.85]: x Funktionalität (Grad, zu dem ein System vorgesehene Aufgaben angemessen übernimmt bzw. bearbeitet): Der Funktionalitätsgrad sollte auf

298


der Basis einer Aufgaben-Analyse durch die Benutzer selbst festgelegt werden können. x Konsistenz (Zuverlässigkeit bzw. Berechenbarkeit des Systemverhaltens): Die Erwartungen der Benutzer sollen erfüllt und Überraschungseffekte vermieden werden. Einheitlichkeit im Design und regelhafte Gestaltung tragen zur Gedächtnisentlastung bei. x Flexibilität (Ausmaß der Beeinflussbarkeit des Systemverhaltens im Sinne objektiv vorhandener Freiheitsgrad): Die Steuerung des Dialogablaufs sollte den Benutzern weitestgehend überlassen werden, um unterschiedliche Vorgehensweisen zu ermöglichen. Die Abfolge einzelner Arbeitsschritte sollte so wenig wie möglich vorgegeben sein. Dabei hängt der Grad der zugelassenen Flexibilität auch vom Anwendungsbereich ab. Burmester und Komischke [4.33] verlangen eine starke Nutzerführung beim Einsatz in der industriellen Prozessführung, gleichzeitig jedoch Flexibilität in dem Sinn, dass die Nutzeroberfläche an verschiedene Nutzerklassen anpassbar sein sollte. Unter dem Aspekt der Konsistenz muss auch berücksichtigt werden, dass beim Nutzer durch Begriffe wie „intelligente Oberfläche“ und ähnliches keine überhöhte Erwartungen an die Leistungsfähigkeit des Systems geweckt werden [4.108]. Nicht zu vergessen ist auch das ästhetische Design des Interfaces. Burmester et al. [4.34] zeigen, dass die Aspekte der ästhetischen Form in der Beurteilung von Interfaces vor allem in die Faktoren Qualität und Brauchbarkeit einfließen und so zu einer höheren Akzeptanz durch den Nutzer führen. Für die Erkundung von Informationsräumen aus dem Engineering sind folgende Aspekte besonders zu berücksichtigen: x Die interaktive, echtzeitfähige Anwendung von Visualisierungsmethoden. Diese ermöglicht eine schnelle Reaktion auf die Ergebnisse von Analysen und Änderungen anderer Teammitglieder. x Die individuelle Kombination verschiedener Visualisierungsmethoden zur Erkundung des Informationsraums auf verschiedenen Abstraktionsebenen und in variablen Detaillierungsgrad [4.76]. x Die Einbeziehung von Kognition und Perzeption der Benutzer in die Gestaltung der Benutzungsoberfläche [4.170]: Ziel von Visualisierung und Interaktion ist ein Mentalmodell des Anwenders. Techniken, die Erkenntnisse aus der Kognitionsforschung berücksichtigen, sollten daher sowohl für die Bedienung des Systems als auch für die Informationspräsentation eingesetzt werden.


299

Adaption Diese arbeitswissenschaftlichen Erkenntnisse fordern eine adaptierbare und adaptive Gestaltung von Dialogschnittstellen, insbesondere unter Berücksichtigung von Kooperationsaspekten [4.68]. Bei der Gestaltung adaptiver oder adaptierbarer Systeme stellt sich immer auch die Frage nach der Benutzungsfreundlichkeit. Hier muss abgewogen werden zwischen der Übernahme von Aufgaben durch das System zur Arbeitserleichterung für den Nutzer und dem Beibehalten der Kontrollierbarkeit durch den Nutzer. Zur Untersuchung der Nutzungsfreundlichkeit können Methoden des empirischen Testens sowie modellbasierte Auswertungen herangezogen werden. Ebenso ist eine Kombination dieser Methoden möglich [4.149]. Billsus et al. beschreiben in [4.17] grundlegende Anforderungen an personalisierte Benutzungsoberflächen, deren Berücksichtigung als Voraussetzung für die Nutzungsakzeptanz gesehen wird. Diese sind: x Gewährleistung eines guten „ersten Eindrucks“. Dies bedeutet leichte Orientierung und wenig Lernaufwand, um schnell die angebotenen Informationen nutzen zu können. x Schnelle Anpassung an wechselnde Interessen. x Vermeidung des „Tunnel-Blicks“, also eine zu große Einschränkung des Nutzers. x Vermeidung von Mehraufwand für den Nutzer, in dem Sinne dass der Nutzer nicht aufgefordert wird, bspw. Metainformationen explizit einzustellen. x Vermeidung von „Brüchigkeit“. Aktionen des Nutzers sollten keine gravierenden, nicht umkehrbaren Konsequenzen nach sich ziehen. x Angebot mehrerer Einstiegspunkte zur Information. x Respektierung der individuellen Privatsphäre. Bei dieser Aufzählung ist zu berücksichtigen, dass die Autoren in ihrem Beitrag vor allem auf die Gestaltung von Shop-Seiten im Internet abzielen. Der Großteil der Gestaltungsempfehlungen ist jedoch sicherlich auch auf andere, interne Applikationen anzuwenden. Die Benutzerfreundlichkeit kann mittels verschiedener Methoden überprüft werden. Üblich sind hierbei Interviews oder Richtlinien; es existieren jedoch auch Tools zur systematischen Überprüfung der Benutzungsfreundlichkeit von Benutzungsoberflächen, wie bspw. in [4.206] vorgestellt. Diese nehmen keinen speziellen Bezug auf Anforderungen, die an adaptierbare Oberflächen gestellt werden müssen. Im Wesentlichen sind die

300


Vorgehensweisen jedoch übertragbar und somit auch in diesem Teilprojekt anwendbar. Die Adaption einer Oberfläche empfiehlt sich aus verschiedenen Gründen [4.150]: Unterschiedliche Nutzer haben unterschiedliche Ziele (Adaption an die Aufgabe bzw. Sicht), derselbe Nutzer benötigt zu verschiedenen Zeitpunkten unterschiedliche Informationen (Adaption an den Prozess), die Oberfläche soll funktional wachsen können (individuelle Adaption). Dabei sollten folgende Kriterien berücksichtig werden: dem Nutzer sollte keine zusätzliche Arbeit entstehen, die Benutzung sollte für jede Art von Nutzer vereinfacht werden, einschließlich Anfänger, Experten und Gelegenheitsnutzer. Der Zugang zu anderen Oberflächen und Applikationen sollte gewährleistet sein, ohne dass irgendwelche Meta-Informationen bereitgestellt werden müssen. Der Mensch als Administrator muss die letzte Kontrolle behalten. Unter Berücksichtigung dieser Kriterien wird die Oberfläche in Form der Szenen an den Experten und den Problemlösungsprozess angepasst. Specht stellt in seiner Dissertation [4.181] ein „Klassifikationssystem für adaptive Methoden“ vor, das für computerbasierte Lehr/Lernsysteme entwickelt wurde. Dabei unterscheidet er die Dimensionen „Was“, „Woran“, „Warum“ und „Wie“ angepasst wird. Diese Unterscheidung ist sicher auch für die Entwicklung eines RPD-Portals relevant und hilfreich, um unterschiedliche Ebenen und Aktionen zu spezifizieren. Diese Klassifikation lässt sich durch die Dimension „mit Hilfe welcher Technik angepasst wird“, erweitern. Luedi stellt dazu verschiedene Techniken vor (s. Abb. 4.39.). Mit Hilfe der Unterscheidung zwischen benutzergesteuerter und systemgesteuerter Auswahl gibt er eine Übersicht über Personalisierungstechniken: Techniken zur Personalisierung Push mittels Agenten Pull vom Benutzer System gesteu- Benutzer gesteuSystem gesteuert Benutzer gesteuert ert ert Rule based Konfigurierbare Kategorisierte Profilgenerierung matching „Agenten“ Benutzer nach Auswahlmenü Lernen durch Rankings „Playback“ Volltextsuche Benutzerverhalten Collaborative FilCollaborative Filtering tering Abb. 4.39. Personalisierungstechniken [4.131]


301

Rollen „Eine Rolle ist ein zusammenhängendes System von Verhaltensweisen, die Personen abverlangt werden“, [4.56]. Eine Person nimmt im Laufe ihrer kollaborativen Tätigkeit eine Fülle verschiedener Rollen ein, die mit verschiedenen Rechten und Pflichten bei der Nutzung einer Kommunikationsplattform und mit der zur Verfügungstellung entsprechender Funktionen verbunden sind. Zur Illustration sei ein kurzes Beispiel beschrieben: Person A ist Produktionsleiter (statische Rolle „Produktionsleiter“). Für ein aktuelles Projekt ist er gleichzeitig Projektleiter (temporäre Rolle „Tutor“). Person A leitet eine Projektbesprechung (kontextabhängige Rolle „Moderator“) und ist Protokollant bei den Abteilungssitzungen (temporäre Rolle „Protokollant“). Von den Beschäftigten der Firma ist er zum Mitglied des Betriebsrats gewählt worden (bedingungsabhängige Rolle „Betriebsratsmitglied“). Rollenkonzepte sind vor allem deshalb wichtig, da sich bei komplexen Tätigkeiten gewisse Aufgaben nicht einzelnen Organisationseinheiten und den damit verbundenen Personen und Funktionen zuordnen lassen [4.199], [4.89]. Diese Aufgaben sind an temporäre oder statische Rollen gebunden und werden von der Person ausgefüllt, die diese bestimmte Rolle gerade inne hat. Die Anforderung an eine kommunikationsunterstützende Umgebung ist es, die verschiedenen auftretenden und für die Kollaboration und Kommunikation relevanten Rollen abzubilden und Personen zuzuordnen, um dadurch den Anwendern rollenspezifische Funktionen, Werkzeuge und Rechte zur Verfügung zu stellen bzw. zu verweigern [4.130], [4.109]. Grundlegend unterschieden werden können statische und temporäre Rollen. Eine Rolle kann unter anderem über die Aufgaben definiert werden, deren Erfüllung von ihr erwartet wird. Auch hier muss unterschieden werden, ob es sich dabei um statische oder temporäre Aufgaben handelt. Herausforderung ist die Abbildung des Prozessmodells des RPD (VDINorm) mit Aufgaben und Informationsbausteinen auf die Rollen, um so einen Zusammenhang zwischen Informationsbausteinen und Rollen herstellen zu können. Unterschiedliche Rollen im Produktentwicklungsprozess lassen sich insbesondere über die Zuordnung zu den unterschiedlichen Unternehmensbereichen identifizieren, denn mit dieser Zuordnung ist häufig die Verfolgung unterschiedlicher Interessen verbunden und die Einbindung in den Prozess erfolgt zu verschiedenen Zeitpunkten in unterschiedlicher Intensität. Dies bringt mit sich, dass auch die Informationsflüsse zwischen den Beteiligten verschieden ausgeprägt sind.

302


Bei [4.93] werden die Unternehmensbereiche Konstruktion/Design, Arbeitsplanung, Marketing/Vertrieb, Produktion, Controlling, Qualitätssicherung, Versuch und Forschung/Entwicklung unterschieden und die Informationsflüsse zwischen diesen Bereichen untersucht. Hier bestand in den Bereichen Konstruktion/Design und Forschung/Entwicklung ein sehr hoher Informationsaustausch mit anderen Bereichen (nämlich jeweils fünf) während der Bereich Arbeitsplanung nur mit zwei anderen Bereichen Informationen austauschte. In der Untersuchung von [4.156] waren folgende Abteilungen im Entwicklungsprozess involviert: Technisches Produktmanagement (PM), Entwicklung (R&D), Qualitätswesen (QW), Technischer Einkauf (TEK), Fertigung, Service und Dokumentation (Dok). Die Aufgabenverteilung dieser Abteilungen verteilt sich über den Entwicklungsprozess wie in Abb. 4.40. Eine Analyse der Informationsflüsse zeigt, dass ein Großteil der Informationen vom Entwicklungsingenieur an andere Abteilungen weitergegeben wird (vornehmlich Produktmanager, Technischer Einkauf, Fertigung und Qualitätswesen), es gleichzeitig jedoch nur wenig Rückflüsse an den Entwicklungsingenieur gibt. Projektphase Klären Entwicklung

Aktion Lastenheft Kostenabschätzung Erstbesprechung Konstruktion Konstruktionsfreigabe

Prototypenbau

Erstserie

Abstimmung „make or buy“ Prototypenbau Prototypenprüfung Sonstiges Erprobung Fertigung Freigabe Produktstartvorbereitung

Abteilung PM R&D PM, R&D, TEK, QW, Fertigung, Dok R&D, QW, Fertigung PM, R&D, TEK, QW, Fertigung, Dok Fertigung, R&D, TEK R&D, Fertigung, QW QW, R&D Service, Dok PM Fertigung, R&D QW PM, (R&D)

Abb. 4.40. Einbindung der Abteilungen in ein Entwicklungsprojekt (nach [4.156])


303

Nach Langenberg ist der Informationsaustausch ausgeglichener: Sicht Technische Sicht

Abteilung Produktplanung Arbeitsplanung / NCProgrammierung Fertigung Montage Qualitätssicherung

Kaufmännische Sicht

Controlling Versand Fertigungssteuerung, BDE Kapazitätsplanung Materialwesen Kalkulation Vertrieb

An Konstruktion Produktanforderungen Planungsanforderungen

Von Konstruktion Produktspezifikation Geometrie

Fertigungsanforder-ungen Montageanforderungen Prüfauswertungen

Fertigungsmerkmale Montagehinweise

Sollwertvorgaben Versandrestriktionen Fertigungsbedingte Änderungen Engpässe Halbzeuge, Normteile Kostenvorgabe Kundenanforderungen

Qualitätsanforderungen Ist-Kosten Verpackungsanforderungen Konstruktive Änderungen Aufwandsschätzung Stücklisten Kostenfaktoren Produktdokumentation

Abb. 4.41. Informationsressourcen und -flüsse für die Konstruktion (nach [4.119])

4.4.3 Das RPD-Portal Anforderungen an das RPD-Portal Allgemeine Anforderungen Mit dem RPD-Portal soll ein strukturierter Zugang zu den im ASN vorhandenen Informationen geschaffen werden. Eine besondere Herausforderung dabei ist die Repräsentation interdisziplinärer, vernetzter Daten. Dadurch kann die Wissensintegration in interdisziplinären Teams unterstützt werden. Der potentielle Nutzer eines solchen RPD-Portals ist Mitglied eines Teams, das in den Produktentwicklungsprozess involviert ist. Die Zielgruppe umfasst also einen heterogenen Personenkreis mit sehr unterschiedlichen Funktionen und Interessen (bspw. Prototypenbau vs. Controlling). Dem wird durch rollenspezifische Filterung Rechnung getragen.

304


Im Bereich der Software-Ergonomie definieren Normen wie [4.53] Teil 8 oder [4.103] allgemeine softwareergonomische Anforderungen. Diese sind: Aufgabenangemessenheit, Erwartungskonformität, Fehlerrobustheit, Steuerbarkeit, Erlernbarkeit, Selbstbeschreibungsfähigkeit und Individualisierbarkeit. Webbasierte Applikationen, wie ein Portal, zeichnen sich zudem durch besondere Aufgabenheterogenität aus [4.32]. Informationsgewinnung und Verarbeitung stehen zwar im Mittelpunkt. Ebenso sollen aber Aufgaben der Kommunikation und Kooperation, des Lernens oder der Transaktion darüber abgewickelt werden [4.91]. Generell handelt es sich um besonders wissensintensive, kooperative oder kreative Kontexte. Hier bieten die Reihe der ISO – Normen 14915, die sich speziell auf multimediale Benutzungsschnittstellen bezieht, Gestaltungshinweise [4.100], [4.101], [4.102]. Aus einer Nutzerbefragung bzgl. des Prototyps hatte sich ergeben, dass das Design insgesamt sachlich und übersichtlich und die Struktur verständlich wiedergeben sein sollten. Dreidimensionale Darstellungen sollten nur dort eingesetzt werden, wo sie das Verständnis unterstützen (bspw. bei der Navigation durch ein Modell). Die Darstellung in einem separaten neuen Informationsfenster sollte vermieden werden. Anforderungen an Rollen Es wurden mit Hilfe halb-strukturierter Interviews inhaltliche Anforderungen von potentiellen Portal-Nutzern ermittelt. Eine Zusammenfassung der Ergebnisse findet sich in folgender Tabelle (s. Abb. 4.42). Die Zielgruppe wird hier in den meisten Fällen aufgrund ihrer Funktion unterschieden. Ergänzend dazu finden sich Anforderungen bzgl. der Teamebene in der Literatur. So werden in [4.143] Managementebene, Teamebene und Individualebene unterschieden und ihnen verschiedene Arten von Inhalten zugeordnet. So sind beispielsweise auf der Managementebene Balken- und Meilensteinpläne adäquat, auf der Teamebene Netz- und Aufgabenpläne und auf der Individualebene schließlich persönliche Aufgabenlisten.


Welche Information? Optimierter Teilplan pro Team Gesamtplan (des Projektplans) Konfliktanzeige (bei Ressourcenkonflikten) Anforderungsliste Kosten, Qualität, Zeit BearbeiterInformationen Targetkosten Ziel-Design Anforderungen Funktionalität (z.B. Einsatzgebiet) Anforderungen an Material Kalkulation Vergleichsangebote von Konkurrenten Einsparungspotenzial (produktbezogen) Bericht Schwundmaße Links auf externe Informationen (z.B. raptec)

Für wen? Team, Teamleiter

305

Von wem? Planung, Projektmanagement, Teamleitung Planung, Projektmanagement, Teamleitung Planung, Projektmanagement, Teamleitung

Projektleiter Teamleiter, Projektleiter Controlling Controlling Alle

Entwurf Entwurf Entwurf

Entwicklungsplanung/ Konstruktion Design Entwicklungsplanung / Konstruktion

Controlling

Entwicklungsplanung Konstruktion Konstruktion Konstruktion

Controlling

/

Controlling Controlling

Controlling Controlling

Konstruktion

Controlling

Konstruktion, Prototyperstellung Prototyperstellung Fachfremde mit Interesse, Prototyperstellung

Prototyperstellung Prototyperstellung extern

Abb. 4.42. Inhaltliche Anforderungen an ein RPD-Portal

„Die Rollenzuordnung zu einer Person kann statisch oder temporär sein. Sie kann als statisch betrachtet werden, wenn die Zuordnung über Monate hinweg stabil bleibt. Dies sind meist die Kernrollen der Personen wie bspw. Abteilungsleiter, Entwickler oder Seminarleiter. Es können keine, eine oder mehrere Rollen zugeordnet sein. Hat eine Person mehrere statische Rollen inne, kann es sinnvoll sein, Hierarchieebenen abzubilden [4.61], [4.109]. Bei temporären Rollen kann die Zuordnung abhängen vom Kontext, einer Bedingung oder einer Entscheidung.

306


Anforderungen an die Formalisierung In klassischen, objektorientierten Modellen stellt jedes Objekt die Instanz von genau einer Klasse dar. Damit entsteht aber eine unveränderliche Objektstruktur. Ein Objekt kann in seinem Lebenszyklus dann nicht verschiedene Rollen annehmen [4.11]. Aus diesen Überlegungen ergeben sich folgende Anforderungen an ein Rollenmodell [4.11]. x „Objekte können während ihrer Lebensphase mehrere Rollen annehmen und auch wieder ablegen.“ x „Ein Objekt kann eine Rolle mehrfach annehmen.“ x „Objekte können Rollen dynamisch annehmen und wieder aufgeben.“ x „Jedes Objekt besitzt unabhängig von seinen aktuell vorhandenen Rollen eine eindeutige Objektidentifikation.“ x „Die einzelnen Rollen können unabhängig voneinander angenommen und wieder abgelegt werden.“ x „Mehrere Rollen können sich auf gemeinsame Daten sowie ein gemeinsames Verhalten beziehen.“ x „Ein bestimmtes Verhalten kann rollenspezifisch sein.“ x „Rollen können die Sichtbarkeit von Eigenschaften beschränken.“ x „Rollen können in einer eigenen Rollenhierarchie angeordnet werden.“ Rollenmodell Für die Anpassung von Benutzungsschnittstellen ist die Erstellung von Benutzermodellen notwendig. Dies bedeutet, dass das System einen eingeloggten Nutzer identifiziert und ihm ein Modell zuordnen kann. Dieses Modell ist ausschlaggebend dafür, wie sich das System dem Nutzer gegenüber verhält und wird im weiteren als „Rolle“ bezeichnet. Laut Fischer [4.71] sind bei der Rollenmodellierung folgende Punkte zu beachten: Der Gewinn, der durch Benutzermodelle erreicht werden kann, sollte noch gesteigert werden. Es gibt komplizierte und aufwändige Systeme, die jedoch nur eine inkrementelle Verbesserung in der Benutzbarkeit mit sich bringen. Das bedeutet, dass der Aufwand für das Adaptionssystem immer in Relation zu dem erwarteten Nutzen bleiben sollte. Eine weitere Gefahr besteht darin, dass für die Bildung der Rolle Informationen zu Grunde gelegt werden, die unpassend oder veraltet sind. Rollen müssten also validiert werden, was sich häufig sehr schwierig gestaltet. Bei Veralterung müssen Rollen angepasst werden. Zunächst lässt sich die Rolle einfach über eine Zuordnung der zu übernehmenden Funktionen in einem klassisch organisierten Unternehmen de-


307

finieren. Im Prozess der Produktentstehung kann man dabei zwei große Kategorien unterscheiden. Zum einen gibt es Funktionen und Aufgaben, die vor allem produkt- und prozessorientiert sind und zum anderen Funktionen, die vor allem dem Management der Abläufe, der Planung und der Steuerung dienen. Bei DaimlerChrysler werden folgende Funktionen unterschieden: Projektmanagement, Purchasing, Produktentwicklung, Produktion, Logistik, Sales – Marketing, Controlling, Aftersales, Produktionsplanung, Design, Powertrain, Qualitätsmanagement, Zulieferer [4.92]. Da der Schwerpunkt auf die frühen Phasen der Produktentstehung gelegt wird, sollen die Bereiche Zulieferer, Logistik, Produktion und Aftersales hier nur eine nachgeordnete Rolle spielen. Der Bereich Powertrain ist sicher sehr spezifisch und wird deshalb hier ebenfalls vernachlässigt. Die anderen Funktionen finden sich wahrscheinlich so oder ähnlich in vielen anderen Projekten der Produktentstehung wieder. Die Aufgaben Controlling, Projektmanagement und Qualitätsmanagement sind hierbei zu den managementorientierten Aufgaben zu zählen. Neben dieser funktionsorientierten Unterscheidung von Aufgaben und der damit verbundenen Rollen stellt sich – bei Teamarbeit – auch die Erarbeitung von Koordinationslösungen als Aufgabe für die Teammitglieder [4.154]. Bender hat in ihrer Dissertation ein integriertes Prozessmodell erarbeitet, das Elemente des Projektmanagements, der Konstruktionsmethodik und der Gruppenarbeit verbindet [4.15]. Aussage ist, dass beim Management eines Produktentwicklungsprozesses alle drei Bereiche zu berücksichtigen seien. Folglich entstehen aus allen drei Bereichen Aufgaben und Anforderungen an beteiligte Personen. Diese werden in der Gruppe eigenverantwortlich verteilt. Der Bereich Projektmanagement enthält Elemente zur Projektstrukturierung, zum Projektcontrolling und zum Einsatz von Methoden im Teammeeting. In der Konstruktionsmethodik werden die Projektphasen inhaltlich ausgestaltet sowie Entwicklungsmethoden eingesetzt. Begleitend müssen Methoden zur Gruppenarbeit zur Verfügung stehen. Als relevant für die Detaillierungsebene der zur Verfügung gestellten Informationen haben sich auch die verschiedenen Arbeitsebenen „Management-, Hierarchie- und Individualebene“ herausgestellt [4.143]. So sehen Nölle und Kabel auf der Managementebene Balken- und Meilensteinpläne, auf der Hierarchieebene Netzpläne und Aufgabenlisten und auf der Individualebene persönliche Aufgabenlisten als relevante Inhalte [4.143]. Auf Grundlage dieser Ergebnisse der Literaturrecherche wurde unter Berücksichtigung der Anforderungsanalyse das im Folgenden erläuterte Rollenmodell aufgestellt (s. Abb. 4.43.).

308


Abb. 4.43. Einflussgrößen des Rollenmodells und deren Ausprägungen

Als wesentliche Einflussgrößen wurden „Funktion“, „Tätigkeiten“ und „Hierarchieebene“ identifiziert. Die individuelle Ausprägung dieser Größen beeinflusst den Informationsbedarf. Die einzelnen Ausprägungen der Einflussgrößen sind in der Tabelle (s. Abb. 4.44.) beschrieben. Es ist zu beachten, dass die drei Einflussgrößen unterschiedlich zu handhaben sind. Bzgl. der Einflussgröße „Tätigkeiten“ ist davon auszugehen, dass jeder Beteiligte alle drei Ausprägungen (mit unterschiedlicher Gewichtung) belegt. Bzgl. der Einflussgröße „Hierarchieebene“ kann jedem Beteiligten abhängig vom speziellen Team X eindeutig eine Ausprägung zugeordnet werden. In der Einflussgröße „Funktion“ kann jeder Beteiligte mehrere Ausprägungen belegen. Die hier aufgeführten Ausprägungen sind an den Themenbereich des Sonderforschungsbereichs (Sfb) 374 angepasst. Eine Übertragung auf andere Einsatzbereiche ist jedoch prinzipiell denkbar.


Einflussgröße Funktion

Ausprägung Design Produktentwicklung

Produktionsplanung Beschaffung Sales / Marketing Projektmanagement

Controlling Qualitätsmanagement

Hierarchieebene

Nicht Teamangehöriger Teammitglied Teamleiter

Tätigkeiten

operativ steuernd kommunikativ

309

Beschreibung zuständig für Konstruktionsentwurf zuständig für Konstruktionserstellung auf Basis Konstruktionsentwurf, Prototypenbau, Einarbeitung Versuchsergebnisse, Einarbeitung Konzeptänderungen zuständig für Fertigungsplanung, Logistikplanung, Materialflussplanung, ... zuständig für Beschaffung zuständig für Ermittlung von Fremdbezugsdaten, Aufnahme von Kundenanforderungen, ... zuständig für Projektplanung und - steuerung, -koordination, -verfolgung, Ressourcenplanung, ... zuständig für Kostenplanung, Terminplanung, Wirtschaftlichkeitsrechnung, zuständig für Qualitätsplanung, Qualitätsüberwachung, Spezifikation Qualitätsanforderungen, ... nicht Teil des Team X Teil des Team X ohne Leitungsfunktion Teil des Team X mit Leitungsfunktion inhaltliche Ausgestaltung der Projektphasen, Einsatz von Entwicklungsmethoden, ... Projektstrukturierung, controlling, ... Gruppenarbeit, Teammeetings, Abstimmungsprozesse, ...

Abb. 4.44. Erläuterungen der Ausprägungen des Rollenmodells

Auf Grundlage dieser Differenzierungen lässt sich nun eine Einteilung in „Wissensdomänen“ vornehmen. Allgemein kann eine Wissensdomäne Informationen sowie Prozess- und Methodenwissen zu einem bestimmten Themenbereich beinhalten. Im Bereich der Informationstechnologie wird der Begriff häufig im Zusammenhang mit Expertensystemen benutzt und bezeichnet dort gerade den Einsatzbereich, der durch das Expertensystem

310


abgedeckt wird. Für das RPD-Portal liefert das ASN die zentrale Wissensbasis. Als Wissensdomäne sollen hier Teilmengen des ASN bezeichnet werden, die bestimmten Rollenausprägungen zugeordnet werden können (s. Abb. 4.45.). Klasse Mitarbeiter

Attribut

für Funktion

für Hierarchieebene

funktion

Controlling / Projektmanagement Controlling / Projektmanagement Controlling / Projektmanagement Controlling / Projektmanagement

Teamleiter

personalkosten_ betrag personalkosten_ waehrung laufendeProjekte beendeteProjekte

Unternehmensbereich

hausanschrift Geschaeftsanschrift mitarbeiter

Teamleiter

Teamleiter, persönlich Teamleiter, persönlich persönlich Team X

Projektmanagement, Controlling

Abb. 4.45. Exemplarische Zuordnung von Objekten des ASN zu Wissensdomänen

Ist einem Informationsobjekt (Klasse oder Attribut) eine Rollenausprägung zugeordnet, so ist es für einen Nutzer, der eine dieser Rollenausprägungen besetzt, relevant. Die Tabelle ist so zu lesen, dass Zuordnungen der Klasse auch für alle Attribute dieser Klasse gelten. Adaptionsstrategie für das RPD-Portal Entsprechend des oben beschriebenen Rollenmodells und der Einteilung der im ASN vorgehaltenen Informationsobjekte, werden einem Nutzer mit einem bestimmten Rollenprofil zunächst die Informationsobjekte angezeigt, die seiner Rolle zugeordnet wurden. Um zu vermeiden, dass durch diesen Filtermechanismus dem Nutzer relevante Informationen nicht zugänglich gemacht werden, kann der Filter auf jeder Portalseite ausgeschaltet und die gesamte zur Verfügung stehende Information angefordert werden. Das hier vorgestellte Modell beinhaltet also keine Sicherheitsmechanismen, die persönliche Zugriffsrechte steuern. Diese wären bei einem Einsatz in der Industrie mit dem Modell zu kombinieren. Das Rollenprofil wird teilweise durch einen Master-User (Administrator oder Teamleiter) und teilweise durch den Nutzer selber bestimmt. So wird


311

die Ausprägung der Teamebene durch den Teamleiter bestimmt, während die Ausprägung der Funktion vom Nutzer selber bestimmt werden kann. Dieser kann selber am besten beurteilen, welche angrenzenden Disziplinen seine Arbeit beeinflussen und welche Informationen somit für ihn relevant sind. Im Laufe des Projektes können sich diese Bereiche sogar verlagern und der Nutzer kann selber einfach seine Informationsauswahl diesen Änderungen anpassen. Zur Zeit ist dieser Mechanismus nur einstufig implementiert (ja / nein). Um eine Gewichtung der Interessen zu ermöglichen, die die Schwerpunkte der Arbeit widerspiegeln, ist jedoch eine feinere Abstufung in der nächsten Entwicklungsstufe vorgesehen. Die hier gewählte Adaptionsstrategie verknüpft nach Luedi [4.131] benutzergesteuerte „Profilgenerierung“ mit systemgesteuertem „rule-based matching“ (s. Abb. 4.46.). Damit wird durch die systemgesteuerte Komponente dem Nutzer Administrationsaufwand abgenommen, da dieser seine Auswahl nicht auf Basis der einzelnen Informationsobjekte tätigen muss. Durch die benutzergesteuerte Profilgenerierung bleibt die Kontrollierbarkeit des Systems gewährleistet.

Abb. 4.46. Komponenten der Informationsfilterung im RPD-Portal

In der Regelbasis werden die Abhängigkeiten zwischen den Einflussgrößen des Rollenprofils und den zur Verfügung stehenden Informationsobjekten beschrieben. Diese Regelbasis wird auf Basis der oben beschriebenen Wissensdomänen erstellt. Sie ist als relativ fix anzusehen, das heißt, nach einer gewissen Erprobungszeit sollte sie nicht mehr geändert werden. Bei Veränderungen in der Informationsbasis ASN ist sie jedoch anzupas-

312


sen. Flexibel wird das System dadurch, dass der Nutzer jederzeit die Möglichkeit hat, sein Profil anzupassen. Konzeption des RPD-Portals Die Gesamtarchitektur beschreibt die Informations- und die Navigationsarchitektur. Für die Erstellung der Informationsarchitektur sind vier Komponenten zu beachten [4.120]. Diese sind: Inhalte, Kommunikation, Mehrwerte und Seiten-Info. Dieser Ansatz lässt sich auf Informationsportale im RPD übertragen. Der Bereich Inhalte beinhaltet die projekt-, produkt-, und prozessspezifischen Daten. Im Bereich Kommunikation werden die für den interpersonellen Austausch relevanten Funktionen und Informationen, wie bspw. Teamdaten bereitgestellt. Dieser Bereich wird im Wesentlichen durch das teamorientierte Kommunikationssystem (Kap. 4.3 „Teamorientiertes Kommunikationssystem für vernetztes Arbeiten“) behandelt. Der Bereich Mehrwerte stellt Funktionalitäten und Informationen bereit, die den Umgang mit den Portalseiten erleichtern und komfortabel machen. Hinter Seiten-Info verbergen sich portalspezifische Informationen, die ohne die Existenz des Portals wertlos wären (im Gegensatz zu den Informationen unter Inhalte, die auch relevant sind, wenn kein Portal existiert). Inhalte Projekt / Produkt x Planung x Ressourcen x ASN x ...

Kommunikation Forum x Team x Messaging x Chat x Video x ...

Mehrwerte News x Suche x Admin / Formulardienst x Notizen x Pers. Terminkalender x ...

Seiten-Info Webmaster x Sitemap x Hilfe x ...

Abb. 4.47. Unterscheidung von Portal-Inhalten nach [4.120]

Unter Berücksichtigung dieser Unterscheidung wurde die in Abb. 4.48 beschriebene Informationsarchitektur definiert.


313

Abb. 4.48. Informationsarchitektur für das RPD-Portal

Die Navigationsarchitektur wurde sehr klassisch konzipiert, da hier sichergestellt ist, dass ergonomische Kriterien berücksichtigt werden (s. Abb. 4.49.). So liegt bspw. die Hauptleiste der Navigation am linken Seitenrand, da hier die Aufmerksamkeit des Betrachters am höchsten ist. Die Leiste enthält nicht mehr als sieben Unterpunkte, da eine höhere Anzahl von Unterpunkten nur schwer vom Nutzer verarbeitet werden könnte. Nach dem Login wird der Nutzer auf die Projekt-Seite geleitet. Hier muss er aus der Liste seiner Projekte auswählen, an welchem Projekt er gerade arbeiten möchte. In diesem Bereich werden dem Nutzer im Folgenden ausschließlich mit diesem Projekt in Beziehung stehende Informationen angezeigt. Über die anderen Navigationspunkte der linken Leiste gelangt der Nutzer zu projektübergreifenden Informationen. Dabei wird der Bereich Planung nur den Nutzern angezeigt, die eine planungsrelevante Rolle besetzt haben. Im ASN wird das Suchen, Browsen und Eingeben von Informationen in das zentrale Datennetz ermöglicht. Der Bereich Team unterstützt die Projektteilnehmer in der Kommunikation. Der persönliche Arbeitsplatz dient zum Zurechtlegen oft verwendeter Dokumente, zum Verwalten des persönlichen Kalenders, von Notizen und der Aufgabenliste. Unter Portal-Admin kann das Benutzerprofil angepasst werden. Jeder Nutzer kann hier Anpassungen vornehmen, um die Kontrollierbarkeit zu gewährleisten.

314


Abb. 4.49. Navigationsarchitektur

Abb. 4.50. Portalarchitektur


315

In Abb. 4.50 ist die Architektur des RPD-Portals dargestellt. Dabei wird deutlich, dass die nutzerspezifischen Informationsanteile, wie Rollen, Aufgaben und die Zugehörigkeit zu bestimmten Wissensdomänen im ASN (Kap. 4.1 „Ganzheitliche Modelle zur Repräsentation aktiven Wissens“) abgelegt sind. Der Zugriff erfolgt hierbei über die agentenbasierte RPDMiddleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“). Die Integration der einzelnen RPD-Anwendungen erfolgt über spezielle Portlets. 4.4.4 Zusammenfassung Zur Realisierung eines nutzerfreundlichen Informationsportals im RPDProzess müssen ergonomische, prozess- und rollenspezifische Anforderungen berücksichtigt werden. Im RPD-Portal stehen dabei die rollenspezifischen Aspekte im Vordergrund. Die Rolle eines Nutzers wird durch die Einflussgrößen Funktion, Teamebene und Tätigkeiten bestimmt. Die Rolle eines Nutzers steht in Zusammenhang mit seinem Informationsbedarf und ist somit geeignet, im Informationsfilter als Information über den Nutzer eingesetzt zu werden. Die Zuordnung von Wissensdomänen zu den Funktionen stellt die Grundlage für die Regelbasis dieses Informationsfilters dar. Der Nutzer kann einen Teil seines Rollenprofils selber bestimmen, wodurch er die Möglichkeit hat, den Informationsfilter zu kontrollieren. So erhält ein Nutzer zielgerichtet Zugang zu den im zentralen ASN abgelegten, für ihn relevanten Informationen. Eine weitere Unterstützung des Nutzers erfolgt durch die Strukturierung der Informationen. Diese erfolgt über die Unterteilung des Portals in thematische Portlets zu Projekt, Planung, ASN und Team. Zur gemeinsamen Darstellung heterogener Informationen wurde das Konzept der bauteilzentrierten Navigation entwickelt. Dabei werden neben den Produktdaten auch Kosten- oder Teamdaten mit den Bauteilen in Verbindung gebracht und ermöglichen somit eine Verknüpfung und räumliche Zuordnung abstrakter Informationen. Dieses Navigationsservlet wurde in den Prototyp des Portals integriert. Weitere RPDApplikationen wurden ebenfalls teilweise integriert. So kann bspw. der ASN-Explorer aus dem Teilprojekt „Virtuelle Realität als Gestaltungs- und Evaluationswerkzeug“ (Kap. 5.2) über das Portal bedient werden, sowie Anwendungen aus der „Teamorientieren Kommunikation“ (Kap. 4.3 „Teamorientiertes Kommunikationssystem für vernetztes Arbeiten“). Ein Banner zeigt bspw. ständig den Online-Status der anderen Teammitglieder an. Der Austausch von Informationen erfolgt über das ASN.

316


Literatur [4.1] Agha GA, Jamali N (1999) Concurrent Programming for DAI. In: Multiagent Systems – A Modern Approach to Distributed Artificial Intelligence / Weiss G (ed). Cambridge, Massachusetts; London, England: The MIT Press, pp 505–537 [4.2] Appelt W, Hinrichs E, Woetzel G (1998) Effectiveness and efficiency: the need for tailorable user interface on the Web. In: Computer Networks and ISDN Systems 30, S 409–508 [4.3] ARVIKA (2003) http://www.arvika.de/www/index.htm, 26.06.2006 [4.4] Arvika (2001) Augmented Reality for Industrial Applications - A New Approach to Increase Productivity? 2002 Proceedings of the 6th International Scientific Conference on Work With Display Units, S 380–381 [4.5] Arvika (2002) Augmented Reality in der Automobilindustrie,. IX - Magazin für professionelle Datenverarbeitung, Hannover, Heise S 142–145 [4.6] Austin JL (1962) How to Do Things with Words. Oxford. Clarendon Press [4.7] Baitsch C, Katz C, Spinas P, Ulich E (1989) Computergestützte Büroarbeit. Ein Leitfaden für die Organisation und Gestaltung. [4.8] Baker K et al. (2001) Heuristic Evaluation of Groupware Based on the Mechanics of Collaboration. In: Little M R & Nigay L (eds) Engineering for Human-Computer Interaction (8th IFIP International Conference, EHCI 2001, Toronto, Canada, May), Lecture Notes in Computer Science vol 2254, pp 123–139, Springer Verlag [4.9] Baker K et al. (2002) Empirical development of a heuristic evaluation methodology for shared workspace groupware. In: Proceedings of the 2002 ACM Conference on Computer Supported Cooperative Work. New Orleans, Nov., ACM Press, pp 96–105 [4.10] Barbuceanu M, Teigen R (1999) Higher Level Integration by Multi-Agent Architectures. In: Handbook of Information System Architectures / Bernus P (ed). Springer Verlag [4.11] Baumgart J (2003) Analyse, Entwurf und Generierung von Rollen- und Variantenmodellen. Darmstadt, Technische Universität, Diss, Darmstädter Dissertationen D17, Darmstadt [4.12] Baur B, Cebulla T (2000) Innovative cooperation structures in the rapid product development process. In: Roller D, Simultaneous Engineering and Rapid Product Development. Epsom: ISATA-Düsseldorf Trade Fair,. (Automotive and transportation technology. International Symposium on Automotive Technology and Automation 2000). S 131–134 [4.13] Beck A, Janssen C (1993) Vorgehen und Methoden für aufgaben- und benutzerangemessene Gestaltung von graphischen Benutzungsschnittstellen. In Coy, W, Gorny, P, Kopp, I, Skarpelis, C (Hrsg.) Menschengerechte Software als Wettbewerbsfaktor. Teubner, Stuttgart, S 200-221 [4.14] Bedford SD et al. (1997) Visualising and Populating the Web: Collaborative Virtual Environments for Browsing, Searching and Inhabiting Webspace. Proc. JENC'97 (8th Joint European Networking Conference), Edinburgh, UK

Literatur

317

[4.15] Bender B (2001) Zielorientiertes Kooperationsmanagement in der Produktentwicklung. München, Technische Universität, Diss. [4.16] Bentley R, Appelt, W et al (1997) Basic Support for Cooperative Work on the World Wide Web. In: International Journal of Human Computer studies: Special issue on Novel Applications of the WWW [4.17] Billsus D, et al. (2002) Adaptive interfaces for ubiquitous web access, Communications of the ACM, vol 45 no 5, May 2002 [4.18] Blake MB (2001) Rule-Driven Coordination Agents: A Self-Configurable Agent Architecture for Distributed Control. In: 5th International Symposium on Autonomous Decentralized Systems, ISADS, March 26–28, 2001 in Dallas, Texas, pp 271–277 [4.19] Boag S, Chamberlin D et al (2003) XQuery 1.0: An XML Query Language. URL: http://www.w3.org/TR/2003/WD-xquery-20031112/ (07.01.2005) [4.20] Booch, G. (1994): Object-Oriented Analysis and Design with Applications. Benjamin/Cummings. [4.21] Bratman ME (1987) Intentions, Plans, and Practical Reason. Harvard University Press: Cambridge, MA [4.22] Bratman ME, Israel DJ, Pollack ME (1988) Plans and resource-bounded practical reasoning. Computational Intelligence, pp 349–355 [4.23] Bray T, Paoli J, et al (2004) Extensible Markup Language (XML), XMLStandards. URL: http://www.w3.org/TR/2004/REC-xml-20040204/ (07.01.2005) [4.24] Brickley D, Guha RV (2000) Resource Description Framework (RDF) Schema Specification 1.0. W3C Candidate Recommendation, Technical Report. URL: http://www.w3.org/TR/2000/CR-rdf-schema-20000327/ (07.01.2005) [4.25] Brooks RA (1986) A robust layered control system for a mobile robot. In: IEEE Journal of Robotics and Automation, Nr. 2 (1), pp 14–23 [4.26] Brooks RA (1991) Intelligence Without Reason. Massachusetts Institute of Technology; Artificial Intelligence Laboratory, A.I. Memo Number 1293 [4.27] Bullinger HJ, Warschat J, Diederich MK (2004) Multi-agent-based Middleware to support construction in Rapid Product Development with an active semantic network. In: Proceedings of the 2nd International Conference on Robotics. October 14–16 2004 in Timisoara & Resita, Rumania, pp 35–36 [4.28] Bullinger HJ, Warschat J, Diederich MK (2004) Multi-agent-based Middleware to support construction in Rapid Product Development with an active semantic network. In: Robotica & Management, pp 18–24 [4.29] Bullinger HJ et al. (2001) Kooperative virtuelle Produktentwicklung. WT. Werkstattstechnik 91, Nr.2, S 63–67 [4.30] Bullinger HJ et al. (2001) An effective communication infrastructure for engineering cooperation. ICPR 2001, 16th International Conference on Production Research. CD-ROM : 29 July - 3 August 2001, Prague, Czech Republic. Prag, S 14 [4.31] Bullinger HJ et al. (2001) Planning and integration of product development. Handbook of industrial engineering: Technology and operations management. New York : Wiley S 1283–1295

318


[4.32] Bullinger HJ et al. (2002) Usability engineering für web-basierte Applikationen. In: Informationstechnik und Technische Informatik: it + it 44 Nr 1, S 5– 13 [4.33] Burmester M, Komischke T (1999) Nutzeranforderungen als Grundlage für die Entwicklung innovativer User Interfaces in der industriellen Prozeßführung. In: Software-Ergonomie ’99 – Design von Informationswelten, S 53–62 [4.34] Burmester M, Platz A, Rudolph U, Wild B (1999) Aesthetic design – just an add on? In: Human-Compuer Interaction: Ergonomics and User Interfaces 1, S 671–675 [4.35] Cattell RGG, Barry D, et al. (2000) The Object Database Standard – ODMG 3.0. Morgan Kaufmann Publishers Inc., ISBN: 1-55860-647-5 [4.36] Cebulla T (2001) Teamoriented speechacts in manufacturing processes. Society of Automotive Engineers -SAE- : ATTCE 2001, Automotive and Transportation Technology Congress and Exhibition. Proceedings. vol.3: Manufacturing : Barcelona, Spain. Warrendale, Pa. : SAE (SAE-P 369) S 19–24 [4.37] Cebulla T (2004) Entwicklung einer asynchronen Kommunikationsunterstützung für multidisziplinäre Teams. Jost-Jetter Verlag, Stuttgart, Univ., Diss. [4.38] Coordinator (1989) Handbuch Coordinator II. Deutsche Übersetzung des Handbuchs zur Software Coordinator II der Fa. Action Technologies, Emeryville CA. Fa Compu-Shack, Neuwied [4.39] Corkill DD, Gallagher Q, et al (1988) GBB: A generic blackboard development system. In: Blackboard Systems, Engelmore R, Morgan T (eds), Addison Wesly Publishing Company [4.40] COVEN (2003) http://coven.lancs.ac.uk/home.htm 26.062006 [4.41] Covington MA (1996) Toward a New Type of Language for Electronic Commerce. In: Proceedings of the 29th Annual Hawaii International Conference on System Sciences, vol. 4., pp 329–336. [4.42] Covington MA (1998) Speech Acts, Electronic Commerce, and KQML. In: Decision Support Systems 22. Elsevier, pp 203–211. URL: http://www.ai.uga.edu/~mc/speechac.pdf (07.01.2005) [4.43] Dalakakis S, Diederich MK, Roller D, Warschat J (2005) Multiagentensystem zur Wissenskommunikation in der Produktentstehung – Rapid Product Development. In: Wirtschaftsinformatik 2005 – eEconomy, eGovernment, eSociety / Ferstl OK, Sinz EJ, Eckert S, Isselhorst T (Hrsg). Heidelberg: Physica-Verlag, S. 1621–1640. ISBN: 3-7908-1574-8 [4.44] Date CJ, Darwen H (1993) A Guide to SQL Standard. 3rd Edition, AddisonWesley. ISBN: 0201964260 [4.45] Davis R, Smith RG (1983) Negotiation as a Metaphor for Distributed Problem solving. In: Artificial Intelligence 20 vol 1, pp 63–109 [4.46] Day JD, Zimmermann H (1983) The OSI Reference Model. In: Proceedings of the IEEE, vol 71, pp 1334–1340 [4.47] Deisinger J (2002) Immersives Modellieren In: wt Werkstatttechnik online. 16992 Heft 1/2, S 16–18 [4.48] Defila R, Di Giulio A (1996) Vorraussetzungen zu interdisziplinärem Arbeiten und Grundlagen ihrer Vermittlung. In: Blasinger PW, Defila R, Di Giu-

Literatur

319

lio A (Hrsg.), Ökologie und Interdisziplinarität – eine Beziehung mit Zukunft? Wissenschaftsforschung zur Verbesserung der fachübergreifenden Zusammenarbeit. Birkhäuser Verlag: Basel [4.49] Deutsch A, Fernandez MF, et al (1998) XML-QL: A Query Language for XML. In: WWW The Query Language Workshop (QL) in Cambridge, MA. URL: http://www.w3.org/TR/1998/NOTE-xml-ql-19980819/ (07.01.2005) [4.50] Dewitz SK, Lee RM (1989) Legal procedures as formal conversations: contracting on a performative network. In: Proceedings of the 10th International Conference on Information Systems, pp 53–65 [4.51] Diederich MK, Leyh J (2000) Dynamic Planning Portal for Rapid Product Development. In: Proceedings for the Conference on Rapid Prototyping in the Automotive Industries, 33rd International Symposium on Automotive Technology and Automation (33rd ISATA), September 25–27, 2000 in Dublin, Ireland [4.52] Diederich MK, Leyh J (2001) Agent Based Middleware to Coordinate Distributed Development Teams in the Rapid Product Development. In: Proceedings for the Conference on Product Development, 1st Automotive and Transportation Technology Congress and Exhibition (1st ATTCE) October 1–4, 2001 in Barcelona, Spain [4.53] DIN66234 Norm Teil 8 (1988) Bildschirmarbeitsplätze: Grundsätze ergonomischer Dialoggestaltung. DIN 06. [4.54] DIVE 2003: http://www.sics.se/dive/dive.html (26.06.2006) [4.55] Doug B (1998) ODMG 2.0: A Standard for Object Storage. Component Strategies [4.56] Drosdowski G (Hrsg.) (2002) Duden, 4., neu überarbeitete und erweiterte Auflage. Bibliografisches Institut, Mannheim [4.57] Durfee EH, Lesser VR, Corkill DD (1987) Coherent Cooperation among Communicating Problem Solvers. In: IEEE Transactions on Computers C-36 , vol 11, pp 1275–1291 [4.58] Durfee EH (1988) Coordination of Distributed Problem Solver. Kluwer Academic Publisher, Boston [4.59] Eck O (2000) Ein kooperatives Transaktionssystem für CAD-Datenbanken. Shaker Verlag, Stuttgart, Univ., Diss. [4.60] Eck O, Rieg B (1999) Die Beschreibung des Slotdämonen. Bericht Institut für Informatik der Universität Stuttgart, 1999 [4.61] Esswein W (1993) Das Rollenmodell der Organisation: Die Berücksichtigung aufbauorganisatorischer Regelungen in Unternehmensmodellen. Wirtschaftsinformatik, 35, (6), S 551–561 [4.62] Fatima SS, Uma G (1998) An Adaptive Organizational Policy for Multi Agent Systems – AASMAN. In: International Conference on Multi Agent Systems (ICMAS). IEEE Computer Society / B, W (ed). pp 120–127 [4.63] Ferber J (1996) Reactive distributed artificial intelligence. In: Foundations of Distributed Artificial Intelligence, O’Hare GMP, Jennings N R (eds), 1996, pp 287–317.

320


[4.64] Finin T, Labrou Y, Mayfield J (1997) KQML as an Agent Communication Language. In: Software Agents, Bradshaw JM (eds), Menlo Park, Calif.; AAAI Press, pp 291–316. [4.65] Finin T, Weber J, et al (1992) Specification of the KQML Agent Communication Language plus example agent policies and architectures. In: The DARPA Knowledge Sharing Initiative, External Interfaces Working Group [4.66] Finin T, Weber J, et al (1993) Draft Specification of the KQML Agent Communication Language plus example agent policies and architectures. Manuscript obtained from http://www.cs.umbc.edu (07.01.2005) [4.67] Finin T, Fritzson R, et al (1994) KQML as an Agent Communication Language. In: Proceedings of the 3rd International Conference on Information and Knowledge management (CIKM ’94) in Gaithersburg, Maryland, USA. ACM Press, pp 456–463 [4.68] Fink J, Nill A (1996) Benutzerorientierte Adaptivität und Adaptierbarkeit im Projekt AVANTI. In: Adaptivität und Benutzermodellierung in interaktiven Softwaresystemen. Dortmund [4.69] FIPA (2002) ACL Message Structure Specification. In: Foundation for Intelligent Physical Agents (3-12-2002) Nr. SC00061G [4.70] FIPA (2002) Communication Act Library Specification. In: Foundation for Intelligent Physical Agents (12-3-2002) Nr. SC00037J [4.71] Fischer G (2000) User Modeling in Human-Computer Interaction. In: User Modeling and User-Adapted Interaction; Kluwer Academic Publishers [4.72] Flores-Mendez RA (1999) Towards a Standardization of Multi-Agent System Frameworks. In: ACM Crossroads, Special Issue on Intelligent Agents Issue vol 5.4, pp 18–24. URL: http://www.acm.org/crossroads/xrds54/multiagent.html (07.01.2005) [4.73] Fowler M., Scott K. (1998) UML konzentriert: die neue StandardObjektmodellierungssprache anwenden. Bonn: Addison-Wesley-Longman [4.74] Frècon E, Stenius M (1998) DIVE: A scaleable network architecture for distributed virtual environments. Distributed Systens Engineering Journal 1998, vol 5, No 3, pp 91–100. [4.75] Frenz M et al. (2002) Erweiterte real-virtuelle Welten. Konzeptionelle Überlegungen zum Einsatz in der beruflichen Bildung. In: Unternehmen der Zukunft, Aachen, S 7 [4.76] Gallagher RE (1995) Computer Visualization: Graphics Techniques for Scientigic and Engineering Analysis. Boca Raton, CRC Press [4.77] Gao F, Roller D (1998) A semantics-based product model: principles and representations. In: Proceedings of 31st ISATA, Volume Automotive Mechatronics Design and Engineering / Roller D (ed.). 1998 in Croydon, England, pp 127–135. [4.78] Garvan F (2001) The Maple book. Publisher: Chapman & Hall/CRC 2001 [4.79] Geihs K (1995) Client/Server-Systeme: Grundlagen und Architekturen. Thomson’s Aktuelle Tutorien, Thomson Publishing [4.80] Genesereth MR, Fikes RE (1992) Knowledge Interchange Format Version 3.0 Reference Manual. In: Report Logic vol 1

Literatur

321

[4.81] Genesereth MR, Ketchpel SP (1994) Software Agents. In: Communications of the ACM 37 vol 7, pp 48–53 [4.82] Genesereth MR, Nilsson M (1987) Logical Foundations of Artificial Intelligence. Morgan Kaufmann Publishers: San Mateo, CA [4.83] Georgeff M, Pell B, et al (1999) The Belief-Desire-Intention Model of Agency. In: Proceedings of the 5th International Workshop on Intelligent Agents V: Agent Theories, Architectures, and Languages (ATAL-98), 1555 / Müller J, Singh MP, Rao AS (eds). Heidelberg, Germany: Springer-Verlag, pp 1–10. [4.84] Gorny P, Forbig P (1993) Projekt Expose. Expertensystem zur Phasenorientierten Software-Ergonomie-Beratung bei der BenutzungsschnittstellenEntwicklung [4.85] Hacker W (1994) Arbeits- und organisationspsychologische Grundlagen der Software-Ergonomie. Eberleh E et al (Hrsg.), Einführung in die SoftwareErgonomie, Berlin; de Gryuter [4.86] Härder T, Rahm E (1999) Datenbanksysteme – Konzepte und Techniken der Implementierung. Springer, ISBN: 3-540-65040-7 [4.87] Hayes-Roth B (1985) A blackboard architecture for control. In: Artificial Intelligence 26, p 251 [4.88] Henne H (1975) Sprachpragmatik. Nachschrift einer Vorlesung. Tübingen. Niemeyer Verlag [4.89] Herbst D et al. (2000) Unterstützung flexibler Kooperation durch SoftwareMethoden. Springer, Berlin [4.90] Herrtwich RG, Hommel G (1994) Nebenläufige Programme. SpringerLehrbuch, Springer Verlag [4.91] Hinderer H (2005) Eine Vorgehensweise zur Erstellung von Informationssystemen für die zwischenbetriebliche Zusammenarbeit im Vertrieb technischer Produkte. Stuttgart, Univ., Diss., Jost-Jetter Verlag, Heimsheim [4.92] Holdefer U (2002) Methodeneinsatz aber wann? Methodenwirrwarr. KmapForum, Wissensmanagement – mit Methode zum Erfolg, 27. Juni 2002, Karlsruhe. [4.93] Hriso M (1999) Konzeption und Auswertung einer empirischen Studie zum Informationsmanagement in der Produktentwicklung. Unveröffentlichte Studienarbeit am IAT, Universität Stuttgart [4.94] Huhns MN, Stephens LM (1999) Multiagent Systems and Societies of Agents. In: Multiagent Systems – A Modern Approach to Distributed Artificial Intelligence / Weiss G (ed.). Cambridge, Massachusetts; London, England: The MIT Press, pp 79–120 [4.95] Hüttner J, Wandke H, Rätz A (1995) Benutzerfreundliche Software. Psychologisches Wissen für die ergonomische Schnittstellengestaltung. Paschke Verlag, Berlin [4.96] IEEE 802.5: Tokenring [4.97] Internet2 Collaborative Virtual Environments Project (2003) http://www.cs.ucl.ac.uk/ research/vr/Projects/Internet2

322


[4.98] Ishi H, Ullmer B (1997) Tangible Bits: Towards Seamless Interfaces between People, Bits and Atoms. In proceedings of CHI 97, Atlanta, Georgia, USA, ACM Press, pp 234–241 [4.99] Ishi H et al. (1994) Iterative Design of Seamless Collaboration Media. Communications of the ACM , vol 37, No. 8, pp 83–97 [4.100] Norm ISO DIS 14915-1 (2001) Software ergonomics for multimedia user interfaces: Introduction and framework. [4.101] Norm ISO CD 14915-2 (2001) Software ergonomics for mulitmedia user interfaces: Media control and navigation. [4.102] Norm ISO DIS 14915-3 (2001) Software ergonomics for multimedia user interfaces: Media selection and integration. [4.103] Norm EN ISO 9241 (1993) Ergonomic requirements for office work w. visual display terminals. Draft 1993. [4.104] Jagannathan V Blackboard Architectures and Applications. Academic Press, London [4.105] Jennings NR (1990) Coordination Techniques for Distributed Artificial Intelligence. In: Foundations of Distributed Artificial Intelligence / O’Hare GMP, Jennings NR (eds). London: Wiley, pp 187–210 [4.106] Jennings NR, Sycara K, Wooldridge M (1998) A Roadmap of Agent Research and Development. In: Autonomous Agents and Multi-Agent Systems Journal, Jennings NR, Sycara K, Georgeff M (eds), Luwer academic Publishers, Boston, vol 1, Issue 1, pp 7–38 [4.107] Jennings NR, Sycara K, Wooldridge M (1998) A Roadmap of Agent Research and Development. In: Autonomous Agents and Multi-Agent Systems vol 1, pp 275–306 [4.108] Keeble R, Macredie R (2000) Assistant agents for the world wide web intelligent interface design challenges. In: Interacting with Computers 12, S 357–381 [4.109] Kempf F (2002) Referenzmodell zur integrierten Kommunikationsunterstützung von kooperierenden, örtlich verteilten Akteuren. Stuttgart, Univ., Diss., Jost-Jetter Verlag, Heimsheim [4.110] KI: Moderne Methoden der Künstlichen Intelligenz. URL: http://www.ki.informatik.hu-berlin.de/lehre/ss01/MMKIVL.shtml, 2001. (07.01.2005) [4.111] KIF: Knowledge Interchange Format. URL: http://www.cs.umbc.edu/kse/kif/, 1994. (07.01.2005) [4.112] Kirn S, Gasser L (1998) Organizational Approaches to Coordination in Multi-Agent Systems. In: Arbeitsbericht Nr. 9 [4.113] Konolige K (1986) A Deduction Model of Belief. Pitman Publishing: London and Morgan Kaufmann: San Mateo, CA [4.114] Koschel A (1999) Ereignisgetriebene CORBA-Dienste für heterogene, verteilte Informationssysteme. Dissertation, Universität Karlsruhe, 1999 [4.115] Kunz W, Rittel HWJ (1970) Issues as Elements of Information Systems. Arbeitspapier Nr. 131 am Institut für Planung an der Universität Stuttgart [4.116] Labrou Y, Finin T (1994) A semantics approach for KQML – a general purpose communication language for software agents. In: Proceedings of the

Literatur

323

3rd international conference on Information and knowledge management in Gaithersburg, Maryland, USA. ACM Press, pp 447–455 [4.117] Labrou Y, Finin T (1997) A Proposal for a new KQML Specification. URL: http://www.cs.umbc.edu/kqml/papers/kqml97.pdf, (07.01.2005) [4.118] Labrou Y, Finin T, Peng Y (1980) The current landscape of Agent Communication Languages. In: IEEE Intelligent Systems 14 vol 2, pp 45–52 [4.119] Langenberg L (2000) Firmenspezifische Wissensportale für die Produktentwicklung. Bochum, Univ., Diss., Zugl. Aachen: Shaker, 2001 (Schriftenreihe Institut für Konstruktionstechnik, Bd 2000, 8), Shaker-Verlag, Aachen [4.120] Lettau C (2000) Das Web-Pflichtenheft. Bonn, MITP-Verl., 2000. [4.121] Langsford A, Moffett JD (1980) Distributed Systems Management. Addison-Wesley [4.122] Lassila O, Swick R (1999) Resource Description Framework (RDF) Model and Syntax Specification. W3C Recommendation. Technical Report. URL: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ (07.01.2005) [4.123] Le Hen G, Sorito R (2002) DMU-basierte Kooperation bei Bosch – Konzepte und Ideen für zukünftige Arbeitsweisen. ProSTEP Symposium 2002: Life Cycle Management. [4.124] Leyh J, Diederich MK (2000) Evolutionary Planning Methodology for the Early Phases of Product Development. In: Proceedings for the Conference on Rapid Prototyping in the Automotive Industries, 33rd International Symposium on Automotive Technology and Automation (33rd ISATA), September 25–27, 2000 in Dublin, Ireland [4.125] Leyh J, Diederich MK (2001) Distributed and Incremental Planning in the Rapid Product Development. In: Proceedings for the Conference on Product Development, 1st Automotive and Transportation Technology Congress and Exhibition (1st ATTCE) October 1–4, 2001 in Barcelona, Spain [4.126] Liao T (2000) Light-weight reliable Multicast Protocol. In: INRIA, Rocquencourt, BP 105. Le Chesnay Cedex, France. URL: http://webcanal.inria.fr/lrmp/ (07.01.2005) [4.127] Liu M, Ling TW (2002) Towards Declarative XML Querying. In: The 3rd International Conference on Web Information Systems Engineering (WISE ’00), pp 127–138 [4.128] Liu TH, Hwang SL, Wang JC (1999) WWW Interface Design for Computerized Service Supporting System. In human-computer Interaction: Ergonomics and User Interfaces 1, S 735–739 [4.129] Luck M, McBurney P, Preist C (2003) Agent Technology: Enabling Next Generation Computing. AgentLink [4.130] Luczak H et al. (1998) Personenorientierte Arbeitsprozesse und Kommunikationsformen. In: Nagl M, Westfechtel B (Hrsg) Integration von Entwicklungssystemen in Ingenieuranwendungen. Springer, Berlin [4.131] Luedi AF (1997) Personalize or Perish. In: EM – Electronic Markets 7 Nr 3, S 22–25 [4.132] Ludwig B (1996) Computerunterstützung der Argumentation in Gruppen: Aufbereitung einer Sprechaktsequenz nach Habermas und Vorstellung eines Prototypen. Deutscher Univ.-Verlag, Wiesbaden. Hohenheim, Univ.Diss.

324


[4.133] MapleSoft (2003) New Features and Benefits of Maple 8. URL:http://www.maplesoft.com/products/Maple8/whatsnew/features.shtml#p rogramming [4.134] Mešina M (2002) ASN und die relationalen Datenbanksysteme (Realisierungsaspekte). Bericht Nr. 2002/03, Juli 2002. Institut für Informatik, Fakultät Informatik, Universität Stuttgart [4.135] Mešina M, Roller D, Lampasona C (2004) Unified relational data model and data retrieval for rapid prototype development. In: Tools and Methods of Competitive Engineering- Proceedings Fifth International Symposium on Tools and Methods of Competitive Engineering. April 13–17, 2004 in Lausanne, Switzerland [4.136] Minneman S, Harrison S (1996) A Bike in Hand: a Study of 3D Objects in Design. In: Cross N, Christiaans H, Dorst K. (eds) Analysing Design Activity, J. Wiley, Chichester [4.137] Moderation VR (2003) http://www.pm.iao.fhg.de/moderationvr/index.html 26.06.2006 [4.138] Moeller A (2003) XML-Tutorial: FLWR expressions. URL: http://www.brics.dk/~amoeller/XML/querying/flwrexp.html (07.01.2005) [4.139] Monson-Haefel R (2002) Enterprise Java Beans. Kempten, Druckerei Kösel 2002, ISBN 3-89721-297-8 [4.140] Moore SA (1993) Saying and doing: uses of a formal language in the conduct of business. Pennsylvania, Univ., Diss. [4.141] Müller JP, Pischel M, Thiel M (1995) Modelling reactive behaviour in vertically layered agent architectures. In: Intelligent Agents: Theories, Architectures and Languages (LNAI Volume 890), Wooldridge M, Jennings NR (eds), Springer Verlag: Berlin, pp 261–276 [4.142] Nii HP (1986) Blackboard Systems: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures. In: The AI Magazine, pp 39–53. [4.143] Nölle T, Kabel S (2002) Concurrent Engineering Teams – Anforderungen an eine Softwareunterstützung. In: Unternehmen der Zukunft, Aachen Nr 3, S 8–9 [4.144] Normand V et al. (1999) COVEN project: Exploring applicative, technical, and usage dimensions of collaborative virtual environments, PresenceTeleoperators and Virtual Environments, MIT Press 8(2), pp 218–236 [4.145] Nwana HS (1994) Negotiation Strategies: An Overview. In: BT Laboratories internal report [4.146] Nwana HS (1996) Software Agents: An Overview. In: Knowledge Engineering Review 11 vol 3, pp 205–244 [4.147] O’Grady P, Leer KH (1990) A Hybrid Actor and Blackboard Approach to manufacturing Cell Control. In: Journal of Intelligent and Robotic Systems vol 3, Kluwer Academic Publishers, The Netherlands, pp 67–72 [4.148] Pinelle D et al. (2003) Task Analysis for Groupware Usability Evaluation: Modeling Shared-Workspace Tasks with the Mechanics of Collaboration. In: ACM Transactions on Computer-Human Interaction, vol. 10, No. 4, December 2003, pp 281–311

Literatur

325

[4.149] Paganelli L, Paternò F (2002) Intelligent Analysis of User Interactions with Web Applications. In: Proc. of the Conf. of Intelligent User Interfaces (IUI’02), Januar 13–16, 2002, San Francisco, California, USA / ACM, New York, S 111–118 [4.150] Perkowitz O (1999) Towards adaptive Web sites: conceptual framework and case study. In: Computer Networks 31, S 1245–1258 [4.151] RFC 793 Transmission Control Protocol. URL: http://www.ietf.org/rfc/rfc0793.txt?number=793. (07.01.2005) [4.152] RFC 1122 Requirements for Internet Hosts – Communication Layers. URL: http://www.ietf.org/rfc/rfc1122.txt?number=1122. (07.01.2005) [4.153] RFC 1323 TCP Extensions for High Performance. URL: http://www.ietf.org/rfc/rfc1323.txt?number=1323. (07.01.2005) [4.154] Riedel D, Voigt P (1998) Management und Organisation. In: Integriertes Änderungsmanagement / Lindemann U, Reichwald R (Hrsg.), Berlin: Springer, S 61–75 [4.155] Riedl R (2000) ABDRA II – User & Administration Support in Large Intranets. URL: http://www.rereth.ethz.ch [4.156] Rogwoski T (2002) Darstellung der und Optimierungsvorschläge für die Informationsweitergabe in FuE-Teams. Unveröffentlichte Diplomarbeit, Fakultät Wirtschaftswissenschaften, Universität Dresden [4.157] Roller D, Bihler M (1996) Objektorientierte Konzepte für Produktdatenmodellierung und CAD-Datenhaltung. In: Proceedings-Reihe der Informatik '96, Band 5 Produktmodellierung / Roller D (ed.). 1996 in Klagenfurt, pp 91– 108 [4.158] Roller D, Eck O (1996) A rule based transaction model for cooperative multiuser environments. In: Advances in Computer-Aided Design - Proceedings of CADEX ´96, IEEE Computer Society Press. 1996 in Los Alamitos, California, pp 171–177 [4.159] Roller D, Eck O (1997) Active cooperative transaction model for shared design databases. In: Proceedings TeamCad: GVU/NIST Workshop on Collaborative Design / Rossignak J (ed.). May 12-13, 1997 in Atlanta, pp 193– 204 [4.160] Roller D, Eck O (1998) Constraint propagation using an active semantic network. In: Geometric Constraint Solving & Application / Brüderlin B, Roller D (eds.). 1998 in Berlin, pp 43–57 [4.161] Roller D, Mešina M (2003) Unified relational data model and rapid prototype development. In: Proceedings of the 14th International Conference “Process' Control 03”, June 8-11, 2003 in Strbské Pleso, Slovakia, p 63 [4.162] Roller D, Mešina M (2003) Unified relational datamodel. In: Elektrotechnik CAD: CAE Systeme - Konstruktion und Fertigung / Roller D, Schäfer D (eds.). Workshop Elektrotechnik CAD. October 9-10, 2003 in Stuttgart, pp 23 [4.163] Roller D, Bihler M, Eck O (1997) ASN: active, distributed knowledge base for rapid prototyping. In: Proceedings of 30th ISATA, Volume Rapid Prototyping in the Automotive Industries & Laser Applications in the Automotive Industries, Automotive Automation Ltd. / Roller D (ed.). 1997 in Croydon, England, pp 253–262

326


[4.164] Roller D, Dalakakis S, Eck O (2002) A knowledge base for rapid product development. In: Proceedings of TMCE 2002 Tools and Methods of Competitive Engineering. 2002 in Wuhan, China, pp. 171–188 [4.165] Roller D, Eck O, Dalakakis S (2002) Integrated version and transaction group model for shared engineering databases. In: Data & Knowledge Engineering, Elsevier Science B.V 42. 2002, pp 223–245 [4.166] Roller D, Eck O, Dalakakis S (2002) A Knowledge Base for Rapid Product Development. In: TMCE, Horvath I, Peigen L, et al. (eds) [4.167] Roller D, Mesina M, Dalakakis S (2002) An Active Semantic Network for Rapid Prototyping. In: Proceedings of the 5th Conference “Informatics and Algorithms 2002” in Kosice, Slovakei, pp 47–55 [4.168] Roller D, Mešina M, Lampasona C (2005) Concurrency control and locking in knowledge base for rapid product development. In: Cooperative Design, Visualization, and Engineering / Luo Y (ed.). September 18–21, 2005 in Palma de Mallorca, Spain, pp 79–85 [4.169] Roller D, Eck O, Bihler M, Stolpmann M (1995) An active semantic network for supporting rapid prototyping. In: ISATA Proceedings. Mechatronics - Efficient Computer Support for Engineering, Manufacturing, Testing&Reliability, Automotive Automation Ltd. / Soliman J, Roller D (eds). 1995 in Croydon, England, pp 41–48 [4.170] Rosenblum L, et al (1994) Scientific Visualization: Advances and Challenges, London, Academic Press [4.171] Russell SJ, Norvik P (1995) Artificial Intelligence: A Modern Approach. Prentice Hall, Englewood Cliffs, N.J. [4.172] Shoham Y (1997) An Overview on Agentoriented Programming. Software Agents, Bradshaw JM (eds), Menlo Park, Calif.; AAAI Press, pp 271–290 [4.173] Schaefer A (2003) The JBoss group: JBoss 3.0 quick start guide. URL: http://heanet.dl.sourceforge.net/sourceforge/jboss/QuickStart-30x.pdf. [4.174] Schempp T (1998) ISIS - Informationssystem für historische Statistik, Universität Zürich 1998. URL: http://www.hist.unizh.ch/gs+edv/ss1998/databank /isis/isdmo3.html [4.175] Schmietendorf A, Dimitrov E, Dumke R (2002) Enterprise Java Beans. Bonn: mitp-Verlag, 2002 [4.176] Schunn, CD et al. (1998) The Growth of Multidisciplinarity in the Cognitive Science Society. Cognitive Science 22 (1), pp 107–130. [4.177] Shaked E: http://www.internettelephony.com/archive/2.03.04/Features/ feature4. htm 08.04.06 [4.178] Slater M et al. (2002) Small Group Behavior in a Virtual and Real Environment: A Comparative Study, Presence: Teleoperators and Virtual Environments 9(1), pp 37–51 [4.179] Smith RG (1980) Contract Net Protocol: High Level Communication and Control in a Distributed Problem Solver. In: IEEE Transaction on Computers 29, pp 1104–1130 [4.180] Spath D, Hinderer H (Hrsg.) (2005) Marktübersicht Portalsoftware 2005. Fraunhofer IRB, Stuttgart

Literatur

327

[4.181] Specht M (1998) Adaptive Methoden in computerbasierten Lehr/Lernsystemen. Trier, Universität, Diss. [4.182] Steed A et al. (1999) Leadership and collaboration in virtual environments, IEEE Virtual Reality, Houston, pp 58–63 [4.183] Steed A et al. (1999) The London Travel Demonstrator, VRST’99, Proceedings of the ACM Symposium on Virtual Reality Software and Technology, pp 50–57 [4.184] Steinheider B (2000) Cooperation in Interdisciplinary R & D-Teams. In: Simultaneous Engineering and Rapid Product Development, ISATA 2000, Sept 25-27 2000, Dublin, Ireland / Roller D (Hrsg.), Epsom: ISATADüsseldorf Trade Fair, S 125–130 [4.185] Steinheider B, Bayerl PS (2003) Wissensintegration in interdisziplinaeren Teams - Probleme und Strategien. Wirtschaftspsychologie Nr. 1, pp 26–29 [4.186] Steinheider B et al. (1999) Kooperation in interdisziplinären Teams. In: 8. Dresdner Symposium für Arbeits- und Organisationspsychologie [4.187] Streitz J et al. (1992) SEPIA: A Cooperative Hypermedia Authoring Environment. In: Proceedings of the 4th ACM Conference on Hypertext ECHT `92. Milan, Italy. pp 11–22 [4.188] Sun Microsystems Inc. Enterprise Java Beans. URL: http://java.sun.com/products/jdk/1.2/docs/api/ [4.189] Tanenbaum AS (1994) Moderne Betriebssysteme. Hanser [4.190] Tanenbaum AS (1996) Computer Networks – Third Edition. New Jersey, USA: Prentice-Hall, URL http://www.opnet.com/ services/university/tanenbaum.html (07.01.2005) [4.191] Tanenbaum AS, van Steen M (2002) Distributed Systems: Principles and Paradigms. Prentice-Hall [4.192] Tippmann V (2001) Co-operation platform for distributed product development. Society of Automotive Engineers -SAE-: ATTCE 2001, Automotive and Transportation Technology Congress and Exhibition. Proceedings. vol.3: Manufacturing : Barcelona, Spain. Warrendale, Pa.: SAE (SAE-P 369). S 19– 24 [4.193] Tromp J et al. (1998) Small Group Behavior in the COVEN Project, IEEE CG&A, 18(6), pp 53–63 [4.194] Wägenbaur, T (2002) Emergenz - Der Sprung von der Evolutions- in die Kommunikationstheorie und Ästhetik. http://paraluie.de/archiv/sprung/emergenz (20.02.2002) [4.195] Warschat J, Cebulla T (2001) Speechact based teamoriented communication system. 3rd International Workshop on Emergent Synthesis, IWES'01. Bled, Slovenia, March 12th – 13th [4.196] Warschat J et al. (2000) Teamorientiertes Kommunikationssystem für vernetztes Arbeiten. In: Vernetzt planen und produzieren. Fachtagung : 12.–14. Oktober. S 163–167 [4.197] Warschat J, Cebulla T, et al. (2002) Systemumgebung einer multidisziplinär wissensbasierten Produktentwicklung. In: Modelle, Werkzeuge und Infrastrukturen zur Unterstützung von Entwicklungsprozessen, 20.–22. März 2002

328


in Aachen / Nagl, M.; Westfechtel, B. (Hrsg.). Aachen: Wiley-VCH, S. 293– 307. ISBN 3-527-27769-2 [4.198] Weisbecker A (1995) Ein Verfahren zur automatischen Generierung von software-ergonomisch gestalteten Benutzungsoberflächen. Stuttgart, Univ., Diss., Springer, Berlin, Heidelberg [4.199] Weisbecker A (2002) Software-Management für komponentenbasierte Software-Entwicklung. Stuttgart, Univ., Habil., Jost-Jetter Verlag, Heimsheim [4.200] Wellmann MP (1995) A Computational Market Model for Distributed Configuration Design. In: AI EDAM, pp125–133 [4.201] Westermann T (2003) Mathematische Probleme lösen mit Maple. Springer, Berlin [4.202] Wilson P (1988) COSMOS –A Review of Computer Supported Cooperative Work. Research and its relationship to the Cosmos project. Arbeitspapier der Computer Sciences Company. [4.203] Wittgenstein L (1971) Philosophische Untersuchungen. In: Wittgenstein L Schriften, Frankfurt am Main, Suhrkamp Verlag, S 279–544 [4.204] Wooldridge M (1999) Intelligent Agents. In: Multiagent Systems – A Modern Approach to Distributed Artificial Intelligence / Weiss G (ed). Cambridge, Massachusetts; London, England: The MIT Press, pp 27–78 [4.205] Wooldridge M, Jennings NR (1995) Intelligent Agents: Theory and Practice. In: The Knowledge Engineering Review 10 vol 2, pp 114–152 [4.206] Zülch G, Stowasser S (2000) Usability Evaluation of User Interfaces with the Computer-aided Evaluation Tool PROKUS. In: MMI-Interaktiv. OnlineZeitschrift zu Fragen der Mensch-Maschine-Interaktion, Nr 3, S 1–17 [4.207] Zülch G, Stowasser S, Fischer AE (1998) Gestaltung des Dialogs zwischen Benutzer und Rechner, Ergonomische Aspekte der SoftwareGestaltung, Teil 5. In: Ergo-Med, Heidelberg 22 Nr. 3, S 154–159 [4.208] Zülch G, Stowasser S, Fischer AE (1999) Internet und World Wide Web – zukünftige Aufgaben der Kommunikationsergonomie, Ergonomische Aspekte der Software-Gestaltung Teil 9. In: Ergo-Med, Heidelberg 23 Nr 2, S 96–100

5 Erstellung virtueller und physischer Prototypen

Innerhalb des Sfb 374 beschäftigte sich ein Arbeitsbereich mit der Erstellung virtueller und physischer Prototypen. Die Forschungsaufgaben innerhalb dieses Bereichs umfassen: x x x x x

Virtuelle Realität als Gestaltungs- und Evaluierungswerkzeug Visualisierung und Simulation physikalisch-technischer Vorgänge Aufbau und Betrieb von Rapid Prototyping Prozessketten Erzeugung von Prototypen mittels Lasertechnik Entwicklung von Werkzeugen für Prototypenteile

Ziel war der Aufbau einer Prozesskette, die speziell auf die Fertigung von Prototypen zugeschnitten ist. Dabei soll schon in den frühen Phasen des Produktdesigns auf die speziellen Anforderungen an die Erzeugung von RP-Bauteilen eingegangen werden. An den aus Designvorlagen erstellten virtuellen Prototypen können bereits erste Studien zur späteren Montierbarkeit oder Strömungssimulationen durchgeführt werden. Dies ermöglicht schon zu einem sehr frühen Stadium erste Iterationsschleifen, um die Prototypen besser an die an sie gestellten Anforderungen anzupassen. Mit den aus diesen Prozessen gewonnenen Daten können durch Lasersinterverfahren oder Printtechnologien erste physische Prototypen „gebaut“ werden. Diese Prototypen können als erste Anschauungsmuster zum Einsatz kommen. Durch eine nachfolgende Beschichtung kann auch weitgehend eine Oberfläche wie beim später zum Einsatz kommenden Bauteil erreicht werden. Ein weiterer, sehr interessanter Ansatzpunkt ist der Bau von Werkzeugen zur Blechumformung. Es wird dadurch möglich, nach den Prinzipien des RP kostengünstig Werkzeuge zur Herstellung von Kleinserien zu erzeugen.

330


5.1 Virtuelle Realität Die Technologie der virtuellen Realität wird heute zunehmend in der industriellen Produktentwicklung eingesetzt. Am Höchstleistungsrechenzentrum der Universität Stuttgart (HLRS), Institut für Arbeitswissenschaften und Technologiemanagement (IAT) und Institut für industrielle Fertigung und Fabrikbetrieb (IFF) werden die Grundlagen der Softwareund Gerätetechnik für dieses Verfahren erforscht und entwickelt. Der folgende Abschnitt erläutert hierzu einige allgemeine Grundlagen und Begriffe. 5.1.1 Virtuelle Realität in der Produktentwicklung Der Begriff der virtuellen Realität (VR) wurde Ende der 80er Jahre durch Jaron Lanier [5.99] eingeführt, um die vorangegangene Beschreibung „virtuelle Welt“ von Ivan Sutherland [5.155] und „künstliche Realität“ von Myron W. Krueger [5.98] um die Aspekte der Interaktivität und Kooperation zu erweitern. Die damit beschriebene Technologie umfasst Vorrichtungen, um den Benutzern durch realitätsnahe Stimulation der Sinne ein „eingebunden sein“ in eine synthetisch generierte Umgebung zu vermitteln. Die Empfindung, eingebunden zu sein, wird als Immersion, die technischen Vorrichtungen hierfür auch als immersive Umgebung oder immersives System bezeichnet. Da die Begriffe virtuell und Realität im Widerspruch zueinander stehen, wird für diese Form der MenschMaschine-Schnittstelle auch der Begriff der virtuellen Umgebung oder des Virtual Environment (VE) verwendet. Im Einsatz von VR in der industriellen Produktentwicklung ist heute die stereoskopische Sicht auf computergenerierte Geometrien und die Interaktion mit der Anwendung durch handgeführte Eingabegeräte am weitesten verbreitet. Die Technologie ermöglicht die räumliche Darstellung, Analyse und Interaktion mit 3D-Produktmodellen und -eigenschaften. Sie kann bei manchen Aufgabenstellungen bereits heute die Herstellung kostspieliger, physischer Prototypen durch virtuelle Prototypen (Digital Mockup, DMU) ersetzen. Immer kürzer werdende Zyklen in der Produktentwicklung lassen die Nachfrage nach dem Einsatz virtueller Prototypen steigen. VR bietet gegenüber Desktop-basierten DMU-Anwendungen Vorteile insbesondere in der Wahrnehmung räumlich komplex strukturierter Konstruktionen sowie in der intuitiven Interaktion im 3D-Raum. Die immersive, interaktive Darstellung unterstützt maßgeblich das Verständnis für komplexe Zusammenhänge und vereinfacht die Fehlererkennung. Die freie Interaktion erlaubt das einfache Betrachten wichtiger Punkte und Parameter. Wo auf

5.1 Virtuelle Realität

331

dem Desktop noch umständlich Zahlenwerte und Koordinaten eingegeben werden müssen, reicht in VR oft ein Klick an die gewünschte Stelle. Die Anzeige der Daten erfolgt meist durch einen geeigneten Monitor, Datenhelm (Head Mounted Display, HMD) oder durch Projektion. Bei Projektionssystemen existieren verschiedene Bauformen, beginnend bei kompakten Einwand-Anlagen über Curved Screens bis hin zu 4-, 5- und 6Wand-Stereoprojektionsräumen, die ein Gesichtsfeld von bis zu 360° bieten. Für stereoskopisches Sehen sind dabei zwei unterschiedliche perspektivische Ansichten der 3D-Daten, passend für die aktuelle Raumlage des rechten und linken Auges des Benutzers, bereitzustellen. Zwei technische Hürden sind hierzu zu überwinden: Für die dynamische, räumliche Sicht auf die dargestellten Geometrien ist die Position der Augen bzw. des Kopfes des Benutzers zu messen und an die Bildgenerierung zu übertragen.

Abb. 5.1. VR-Komponenten zum Betrieb eines Stereoprojektionsraums (CAVE©)

Gleiches gilt für die Position der Hand oder des Eingabegerätes zur Interaktion mit der VR-Anwendung. Die räumliche Lage von Objekten wird häufig durch drei Koordinaten der Position und drei Winkel der Orientierung ausgedrückt und verfügt folglich über sechs Freiheitsgrade. Für beide Messungen gilt, dass jeweils alle sechs Freiheitsgrade der räumlichen Lage von Kopf und Hand kontinuierlich und mindestens in der Frequenz einer ergonomischen Bildrate zu erfassen sind. Die Messergebnisse fließen in die Bildgenerierung und Anwendungssteuerung ein und erlauben dem Be-

332


nutzer, sich relativ zu den dargestellten 3D-Daten zu bewegen und mit diesen zu interagieren. Diese Messung wird als Tracking bezeichnet und muss in Echtzeit erfolgen. Sie basiert meist auf elektromagnetischen oder optischen Verfahren, es existieren jedoch auch Lösungen auf Basis von Inertialsensorik und Ultraschall. Hier zeigt sich jedoch auch eine Limitierung der virtuellen Realität: Wollen mehrere Personen eine virtuelle Umgebung gemeinsam nutzen, so stellt sich die Perspektive für die Betrachter ohne Trackingsystem an der Brille etwas verzerrt dar. Auch kann meist nur ein Benutzer mit der Szene interagieren. Ansätze wie Multi-ViewpointRendering [5.145] oder Multi-Viewer VR [5.18] versprechen hier Abhilfe, befinden sich aber noch im Entwicklungsstadium. Zur Trennung der beiden Sichtkanäle für das rechte und linke Auge werden verschiedene technische Lösungsstrategien verfolgt: Die beiden Bilder werden bei Datenhelmen durch zwei separate Okular-Monitore getrennt. An Monitoren oder Projektionswänden erfolgt die Sichtkanaltrennung meist durch spezielle Brillen, die auf Verfahren nach dem ShutterPrinzip, Polarisations- oder Spektralfiltern basieren.

Abb. 5.2. Kanaltrennung nach dem Shutter-Prinzip

Nach dem Shutter-Prinzip wird in schneller Folge wechselweise die Sicht durch das linke oder rechte Brillenglas ermöglicht. Hierzu ist die Bildgenerierung synchronisiert, die für die jeweilige Öffnungszeit das Bild in der für das entsprechende Auge richtigen perspektivischen Darstellung zeigt (s. Abb. 5.2.). Das Polarisationsverfahren hingegen setzt in Verbindung mit Projektoren paarweise unterschiedlich ausgerichtete, linear oder zirkular polarisierte Filter an den Objektiven sowie an der Brille des Benutzers ein. Spektralfilter werden in gleicher Weise wie Polarisationsfilter an den Projektorobjektiven und an der Brille eingesetzt, trennen die beiden Bilder jedoch mittels eines Kammfilters, der aus den drei Projektor-

5.2 Virtuelle Realität als Gestaltungs- und Evaluationswerkzeug

333

Grundfarben jeweils unterschiedliche, schmalbandige Frequenzbereiche für das rechte und linke Auge passieren lässt, die durch ein weiteres Filterpaar in der Brille nur dem jeweiligen Auge zugeführt werden [5.36]. Die so genannten autostereoskopischen Verfahren erlauben stereoskopische Sicht ohne körpergetragene Hilfsmittel [5.74]. Sie basieren auf dem elektro-holographischen oder dem Richtungsmultiplexprinzip [5.65], [5.104], [5.43], [5.146]. Richtungsmultiplexverfahren senden verschiedene Bilder in räumlich verschiedene Richtungen aus. Realisiert wird das über beugungs-, brechungs-, reflexions- oder parallaxenbasierte Ansätze [5.65]. Die 3D-Modelle der Konstruktionen, die in den VR-Anwendungen analysiert oder bearbeitet werden, sind zumeist aus 3D-CAD-Geometrien abgeleitet. Im CAD-System liegen die Oberflächenbeschreibungen dabei noch in mathematisch präziser Form vor, während sie beim Exportieren für VR in Dreiecksnetze zerlegt werden. Dieses Verfahren wird als Tesselierung, die Dreiecke auch als Polygone bezeichnet. Allerdings verringert sich hierbei durch den sogenannten Sehnenfehler die Genauigkeit der räumlichen Beschreibung gekrümmter Flächen und Kurven, der abhängig vom Detaillierungsgrad der Tesselierung beziehungsweise der Größe der abgeleiteten ebenen Dreiecke ist. Generell gilt: Je feiner die Dreiecksstruktur gebildet wird, desto genauer ist zwar die Flächenbeschreibung, andererseits steigen hierbei jedoch durch die höhere Polygonzahl auch die Anforderungen an die Grafikleistung der VR-Bildgenerierung. Die hier beschriebenen Technologien finden derzeit die größte Verbreitung in den industriell eingesetzten VR-Systemen. Daneben gibt es allerdings noch eine Vielzahl weiterer Lösungen zur Realisierung immersiver Umgebungen.


5.2.1 Montierbarkeitsuntersuchungen am Virtuellen Prototypen Die Untersuchung eines digitalen Prototyps umfasst neben ästhetischen auch funktionale Aspekte. Im Rahmen der durchgeführten Forschungsarbeiten stand die Überprüfung der Eignung des Prototyps auf seine Produzierbarkeit im Vordergrund: Aussagen zur Fertigbarkeit und Montierbarkeit (Design for Assembly) gilt es schon in frühen Phasen der Produktentwicklung zu generieren, da mit dem zeitlichen Vorverlegen von Korrekturen die Änderungskosten sinken. Die interessierenden Untersu-

334


chungspunkte im Bereich der manuellen Montage sind die Objektgeometrien, die Verbauwege, die Eignung von Montagehilfen, die Einsehbarkeit des Montagebereichs sowie die Handhabbarkeit der Baugruppen. Demnach müssen Geometrien und Bewegungsbahnen beurteilt werden, dazu die Lage von 3D-Objekten im Raum verändert werden sowie die Einsehbarkeit des Bereichs und die Handlungen des Monteurs im Kontext bewertet werden. Für die Überprüfung manueller Montageprozesse mit Hilfe von 3DWerkzeugen stehen zwei prinzipielle Ansätze zur Verfügung: x Die gesamte Szene einschließlich der zu verbauenden Objekte und des Monteurs wird abgebildet. Das Modell des Monteurs umfasst dabei ein Menschmodell, welches die Bewegungsfreiheitsgrade eines Menschen umfasst und sich animieren läßt. Der Montagevorgang wird als Animation formuliert. Moderne Planungswerkzeuge, die nach diesem Schema funktionieren, simulieren gleichzeitig Belastungs- und Komfortwerte für den Monteur. Die ergonomische Auswertung des Prozesses, gleichzeitig der virtuellen Arbeitsumgebung, wird damit möglich. Für diesen technologischen Ansatz wird mindestens ein Standard-PC-Arbeitsplatz benötigt. x Die Szene wird einschließlich der zu verbauenden Objekte und einer eventuellen Arbeitsumgebung, allerdings ohne den Monteur als Modell abgebildet. Der Benutzer schlüpft selbst in die Rolle des Monteurs und führt den Montageprozess durch. Zu diesem Zweck ist der Benutzer immersiv in die Szene einzubetten: der korrekte Bezug seiner Wahrnehmungsorgane und der korrekte Bezug seiner Extremitäten zur 3DSzene müssen sichergestellt sein. Die zu diesem Zweck benötigte Positionserfassung kann auch dazu verwendet werden, die räumlichen Arbeitsabläufe zu protokollieren und für Auswertungen (Ausführungszeiten, Ergonomie, Kollisionsprüfung) weiter zu verwenden. Für diesen technologischen Ansatz wird zwingend eine Umgebung Virtueller Realität benötigt. Die Vorteile des zweiten Ansatzes liegen darin, dass einerseits der Montageablauf nicht gesondert programmiert werden muss und andererseits der Benutzer einen realistischeren subjektiven Eindruck der Gegebenheiten erhält und er damit implizites Expertenwissen und Erfahrungswissen besser einbringen kann. Das für die Aufgabe geeignete VR-System ergibt sich nach der Analyse der Untersuchungspunkte und der Benutzerinteraktionen. Die oben angeführten Aufgaben sind allerdings so vielschichtig, dass eine einzelne Um-


335

gebung nicht zielführend einsetzbar ist. Vielmehr sind unterschiedliche Systemansätze für unterschiedliche Aufgaben zu verwenden. 5.2.2 Visuelle Beurteilung von Objektgeometrien Damit Objektabmessungen und -distanzen visuell korrekt eingeschätzt werden können, sollte generell aufgrund der geometrischen Natur der Aufgabe eine Vielzahl der graphischen Tiefenkriterien (s. Abb. 5.3) erfüllt sein [5.73], [5.150], im Nahbereich insbesondere die Bewegungsparallaxe (also die Nutzung von Relativbewegungen zwischen Objekt und Betrachter) [5.171] und qualitativ gute Beleuchtung und Schattierung [5.171]. Weiterhin muss die wahrgenommene Objektgröße maximiert werden [5.171], [5.21]. Für die visuelle Überprüfung von Geometrien bieten sich Rückprojektionssysteme, insbesondere Workbench-Lösungen an [5.21]. Um geometrische Objekte und räumliche Strukturen besser zu verstehen, werden teil-transparente Darstellungen eingesetzt [5.74], [5.100]. Das IFF hat mit diesen Randbedingungen VR-Arbeitsplätze eingerichtet, die auf der Basis eines L-förmigen Projektionssystems (HoloBench) und auf Basis einer 3-Seiten-Projektionswand arbeiten. Beide Systeme sind mit Headtracking ausgestattet. Die eingesetzten Renderer beherrschen einfache, lokale Lichtmodelle (Point Light, Spot Light, Directional Light nach OpenGL/VRML), Materialmodelle mit Transparenz (VRMLMaterialmodell, s. Abb. 5.5.), Shading (Gouraud Shading, Phong Shading), Schattierung (Shadow Maps, s. Abb. 5.4.), Struktur-/Reliefdarstellung über Texturen (Bump Mapping), perspektivische OffcenterProjektion für immersive Darstellungen mit Tracking sowie Stereoskopie.

336


Abb. 5.3. Vom Menschen genutzte graphische Tiefenkriterien

Abb. 5.4. Verwendung eines lokalen Beleuchtungsmodells und Shadow Maps


337

Abb. 5.5. Verwendung von Transparenz zur Lagebeurteilung

Die VR-Arbeitsumgebungen, die auf der Basis der vorgestellten Techniken eine Vielzahl der graphischen Tiefenkriterien erfüllen, sind in Anwendungsszenarien erprobt worden. Sie ermöglichen eine gute visuelle Beurteilbarkeit von Objektgeometrien sowie deren Lage zueinander, insbesondere im Vergleich zu einfachen 3D-Darstellungen. 5.2.3 Lageänderung von 3D-Objekten im Raum Um die Lage von 3D-Objekten im Raum zu ändern, sind Eingabegeräte mit den der Aufgabe entsprechenden Freiheitsgraden zu verwenden [5.79], [5.73], [5.50], [5.21]. Bei freier Lageänderung sind damit drei translatorische und drei rotatorische Freiheitsgrade vorzusehen. Direkte, räumliche Eingabegeräte sind für Positionieraufgaben zu verwenden [5.171], [5.21]. Direkte natürliche Interaktionstechniken mit der Hand sollten ermöglicht werden, anstatt Werkzeuge oder Metaphern zu verwenden [5.83], [5.21], insbesondere, falls sich alles Relevante in Armreichweite befindet [5.177], [5.21]. Für präzise Eingaben in einem räumlichen Bezugsrahmen ist beidhändige Interaktion zu verwenden [5.74], [5.73], [5.21]. Techniken der kombinierten Navigation und Objektmanipulation sind zu berücksichtigen, falls für die Objektpositionierung manövriert werden muss [5.21]. Weiterhin ist die multimodale Ausgabe von Kraft, Kollision und Reibung räumlicher Eingaben und Greifoperationen zu leisten [5.73], [5.177], [5.150]. Damit rücken neben der graphischen Darstellung auch die akustische Ausgabe und die Kraftreflexion in den Fokus.

338


Das IFF hat für Aufgaben der Objektpositionierung unter Berücksichtigung der genannten Anforderungen zwei Arbeitsumgebungen realisiert: Der Workbench-Arbeitsplatz (s. Abb. 5.6) wurde zusätzlich mit zwei Datenhandschuhen ausgestattet, die es dem Benutzer ermöglichen, in einem präzisen räumlichen Bezugssystem zu arbeiten. Multimodales Feedback wird an den Händen vermittelt: an der linken Hand sorgen kleine Motoren mit Exzentern für Vibrationsreize, so dass sich hier Oberflächenstrukturen und Kollisionen der Hand mit virtuellen Geometrien anzeigen lassen. An der rechten Hand ermöglicht ein Ektoskelett mit Seilzügen die Kraftausgabe auf die Finger, so dass sich mit diesem Aufbau Greifoperationen begleiten lassen. Der Benutzer spürt, dass er Objekte gegriffen hat.

Abb. 5.6. Workbench-Arbeitsplatz

Dieser auf Datenhandschuhen basierende Ansatz ermöglicht zwar das präzise Arbeiten und erzeugt haptisches Feedback direkt an den Fingern, jedoch wirkt dieses Feedback nicht direkt auf die Motorik des Menschen, über die letztendlich die Positionseingaben erfolgen: die Arme und der Rumpf. Der Grund liegt darin, dass es sich bei den Datenhandschuhen um körperbasierte Systeme handelt, bei denen die Gegenkraft durch den eigenen Körper des Benutzers, in diesem Fall durch die Handgelenke, aufgebracht wird. Vor diesem Hintergrund wurde eine zweite haptische Umgebung für einen 3-Seiten-Projetionsraum entwickelt, welche im Gegensatz zu den Da-


339

tenhandschuhen die Kollisionskraftausgabe auf die Arme und den Rumpf des Bedieners ermöglicht. Da kraftreflektierende Gelenkarmsysteme einerseits auch in ihren größten Bauformen einen Arbeitsraum von nur ca. 1m³ besitzen und zudem im Einsatz in Projektionsräumen die Sicht behindern würden, wurde die Verwendung dieser Klasse an haptischen Systemen verworfen. Stattdessen ist ein SPIDAR-System (Space Interface Device for Artificial Reality) entwickelt worden. Das SPIDAR ist ein an Fäden oder Drähten gezogener Mediator (s. Abb. 5.7), welcher durch den Benutzer geführt wird. Die Fäden werden aktiv nachgeführt und ermöglichen so die Positionserfassung des Mediators. Gleichzeitig können die Motoren, welche die Fäden nachführen, blockieren bzw. ein Drehmoment aufbringen. Damit läßt sich bei geeigneter Berechnung der Drehmomente eine gerichtete Kraft auf den Mediator aufbringen. Da das Gestell, welches die Motoren trägt, fest im Raum installiert ist, handelt es sich bei diesem Aufbau um ein erdbasiertes System: Kraft wird damit auf den bewegenden Arm und Rumpf des Benutzers, also modal richtig, aufgebracht.

Abb. 5.7. Ansicht des SPIDAR-Mediators

340


Abb. 5.8. Verwendung eines SPIDAR-Systems in einem Projektionsraum

Das Führen von Objekten läßt sich mit dem SPIDAR so korrekt abbilden. Objektkollision und Reibung als Folge von Verbauoperationen lassen sich als gerichtete Kräfte in einer sehr großen Arbeitsumgebung (s. Abb. 5.8) bei sehr geringer Sichtbehinderung modal richtig ausgeben. Gewichtskräfte virtueller Objekte lassen sich ebenso abbilden wie das Gewicht des haptischen Interfaces kompensieren. Damit hat das SPIDAR in diesem Aufgabentyp zahlreiche Vorteile gegenüber dem kinästhetischen Datenhandschuh. Aufgrund der realisierten geringeren Abtastrate ist es jedoch momentan noch nicht möglich, etwa virtuelle Objekte mit dem SPIDAR so abzutasten, um deren Oberflächenstruktur wahrzunehmen. Dazu wären Abtastraten von ca. 1kHz erforderlich. 5.2.4 Verbauwege, Einsehbarkeit, Beurteilung der Handlungen des Monteurs im Kontext Beim Durchführen und Erlernen motorischer Abläufe ist ein starker Einbezug des Benutzers in die Virtuelle Umgebung erforderlich [5.171]. Für die Erfassung motorischer Abläufe muss der Arbeitsraum entsprechend groß


341

sein. Die Abbildung verschiedener Greiftechniken erfordert die entsprechende Erfassung der Hand [5.35]. Falls möglich, sollte die natürliche Kopfbewegung zur Orientierungsänderung verwendet werden [5.21]. Bei der Navigation sind Stereoskopie und Texturgradient wichtig [5.171]. Ein Head Mounted Display sollte benutzt werden, falls Immersion in räumlicher Umgebung gefordert ist [5.21]. Virtuelle Umgebungen auf der Basis von Projektionssystemen, in welchen haptisch, eventuell sogar auf Basis natürlicher Handbewegungen, interagiert werden soll, sind prinzipiell mit einem Akkommodationsproblem behaftet: Da die Entfernung der Augen des Benutzers zu seinen Händen und zur Projektionsfläche, etwa der Leinwand, nicht in allen Fällen gleich ist, er jedoch nur auf eine räumliche Tiefe fokussieren kann, ist damit entweder nur die eigene Hand oder nur die Projektionsfläche korrekt (scharf) sichtbar. Aus diesem Grund wird normalerweise in derartigen Systemaufbauten noch zusätzlich ein 3D-Modell des Arms in der Szene eingeblendet, welcher sich idealerweise mit dem Benutzerarm bewegt. Dadurch kann der Benutzer ausschließlich auf die Projektionsfläche fokussieren. Damit der virtuelle Arm jedoch vom Benutzer überhaupt gesehen werden kann, darf er sich nicht in der richtigen relativen Position zum Benutzer befinden, da er sonst hinter dem realen Arm des Benutzers verschwinden würde. Wenn er aber an anderer Stelle angezeigt werden muss, stimmt damit die Relation der Abstände vom Kopf zu den Armen und zum Rest der Szene nicht mehr. Kommt es jedoch, beispielsweise im Rahmen ergonomischer Untersuchungen, auf die richtige Relation an, so sind derartige Aufbauten damit also prinzipiell problematisch. Am IFF wurde aus diesem Grund eine Virtuelle Umgebung auf der Basis eines Head Mounted Displays (Abkürzung HMD) erstellt. Die vollisolierte Funktionsweise umgeht dabei das Akkomodationsproblem bei der Benutzung von Projektionssystemen in Verbindung mit haptischen Systemen: der Benutzer sieht lediglich in die 3D-Szene - Sichtkonflikte mit realen Extremitäten treten nicht auf. Als haptische Ein-/Ausgabegeräte wurden wiederum die Datenhandschuhe verwendet, da einerseits die Finger und Hände ohnehin zu tracken sind und andererseits die Datenhandschuhe permanent am Körper gebunden sind und daher nicht vom Benutzer zur Verwendung gefunden werden müssen. Diese Eigenschaft ist besonders vor dem Hintergrund der isolierten Sicht des HMD-Benutzers sinnvoll. Mit diesem Systemaufbau läßt sich die Geometrie, auch Einsehbarkeit von 3D-Umgebungen unter Einbezug der realen Abmessungen und Lage des Monteurs erfassen. Die Erfassung und Bewertung kann sowohl durch den Monteur selbst erfolgen, oder auch durch externe Beobachter, die durch das am IFF entwickelte Multi-User-VR-System hinzugezogen werden können (s. Abb. 5.9.).

342


Abb. 5.9. Beobachtung des Monteurs im Multi-User-System

Zur Auswertung manueller Arbeitsvorgänge ist eine Vielzahl von Bewertungswerkzeugen am Markt verfügbar. Diese gilt es zu nutzen, um objektive Bewertungen der haltungs- und tätigkeitsbezogenen Arbeitsbelastungen zu ermitteln, welche beim Arbeiten in der Virtuellen Umgebung auftreten. Hierzu wurde beim IFF eine Exportschnittsstelle zwischen der VR-Programmumgebung und einem Ergonomiewerkzeug zur Übergabe der Bewegungsabläufe des Monteurs entwickelt. Mit der erstellten Arbeitsumgebung lassen sich demnach Verbauwege, die Einsehbarkeit und die Handlungen des Monteurs im Kontext direkt visuell beurteilen. Eine quantitative Bewertung von Komfort und Ergonomie ist über den Export der Bewegungsbahnen des Monteurs an ein Arbeitsplatzgestaltungswerkzeug möglich.


343

5.2.5 Data Mining in Virtuellen Umgebungen Interaktionen mit dem Aktiven Semantischen Netz Ansätze zum Data Mining mittels Virtueller Umgebungen kamen ursprünglich aus allgemeinen Ansätzen zur Visualisierung größerer (wissenschaftlicher) Datenmengen (Stichwort „scientific visualization“) [5.117], [5.108] wobei aber auch sehr frühe Ansätze zur haptischen Darstellung nicht vergessen werden dürfen [5.26]. Die den normalen DesktopComputersystemen überlegenen Möglichkeiten der VR, mehr räumliche Tiefeninformationen zu transportieren, eröffnen Vorteile bei der Nutzung dieser weiteren Dimension [5.124].

Abb. 5.10. Interaktion mit dem ASN im Projektionsraum

Gegenstand der Darstellung innerhalb des Sonderforschungsbereichs sind einzelne Knotenpunkte des Aktiven Semantischen Netzes (ASN) wie beispielsweise Ressourcen des Produktentwicklungsprozesses sowie deren Verbindung zueinander. Diese sind als Netzwerke darstellbar oder auch als Punktwolken in Koordinatensystemen, deren Achsen von logischen oder hierarchischen Ordnungen ausgemacht werden. Ergebnisse einer Analyse

344


können so prozessorientiert interpretiert und aufgetragen werden. Darstellungsmetaphern in Computerdarstellungen dienen allgemein dazu, Inhalte über eine für den Betrachter besser zu erfassende Art zu transportieren (etwa Terminverläufe über Fehlfarben). Mittels dieser Technik sind auch in der Anzeige von Netzwerken und Punktwolken zusätzliche Informationen unterzubringen.

5.3 VR in der Konstruktion In der industriellen Produktentwicklung werden virtuelle Umgebungen heute zur Bearbeitung verschiedener Fragestellungen über den gesamten Produktlebenszyklus hinweg eingesetzt. Die Anwendungsbereiche erstrecken sich von der Evaluierung von Designstudien und Konstruktionsdatensätzen über die Analyse von Simulationsergebnissen und die Optimierung von Prozessen bis hin zur Betrachtung von Montage-, Benutzungs- und Wartungsaspekten [5.84], [5.157], [5.160]. In den folgenden Abschnitten wird die Unterstützung von Konstruktionsaufgaben durch VR-basiertes CAD-Review und parametrisches Modellieren näher betrachtet. 5.3.1 CAD-Review In den VR-Bearbeitungsprozessen sind meist mehrere unterschiedliche Fragestellungen zu untersuchen, die von einzelnen, dedizierten VRAnwendungen bisher nicht immer vollständig abgedeckt werden. Hierbei müssen in einer VR-Sitzung für ein Produkt entsprechend mehrere, aufgabenspezifische VR-Anwendungen nacheinander eingesetzt werden. Dies kann zu einem deutlichen Mehraufwand für die Datenaufbereitung und die Anwendungs-Rüstzeiten führen und erschwert gegebenenfalls die Bedienung durch jeweils unterschiedliche Interaktionstechniken. Eine quasistandardisierte Interaktionsform wie sie bei Desktop-Rechnern durch Oberflächen wie Windows, X Window System oder MacOS heute vorliegen, erleichtert die Benutzung wie auch die Einarbeitung in neue Applikationen. Anwendungen in virtuellen Umgebungen entbehren jedoch bisher eine vergleichbare Standardisierung ihrer Benutzungsschnittstellen. Am IAT wurde untersucht, in welcher Form die bisher in separaten VRAnwendungen durchgeführten Tätigkeiten der Aufgabenbereiche DesignReview, Montierbarkeitsbetrachtung, Ergonomieanalyse und CADEvaluation in einer gemeinsamen Applikation mit durchgängiger Benutzungsschnittstelle integriert werden können.

5.3 VR in der Konstruktion

345

Abb. 5.11. VR-Anwendung für CAD-Review auf Basis von Lightning im Sechswand-Stereoprojektionsraum HyPI6 am IAT.

Zur Realisierung der Anwendung für das VR-CAD-Review war eine geeignete Auswahl der zu implementierenden Funktionalitäten für die vier Anwendungsbereiche zu treffen. Die Auswahl wurde unter anderem anhand exemplarischer Produktentwicklungsszenarien bestimmt. Für das CAD-Review (s. Abb. 5.11) stehen nun Funktionen wie Positionieren, Schnittebene, Prüfung auf Materialüberschneidungen, Distanzmessung, Ein- und Ausblenden von Komponenten, sowie Annotations- und Dokumentationsfunktionen bereit. Für die Ergonomieanalyse wurden die Menschmodelle Anthropos und Charad [5.41], [5.42], [5.84] in die Anwendung integriert. Sie dienen zur Betrachtung von Körpermaßen, Sicht- und Greifräumen und erlauben die Simulation des Komfortempfindens der eingenommenen Haltung. Für die Aufgaben des Design-Review werden Funktionalitäten zur Material- und Farbwahl von Produktoberflächen und zur Ausleuchtung bereitgestellt. Zur realitätsnahen Darstellung von Materialoberflächen wurde Unterstützung für Hardware-Shader in das VR-System Lightning integriert (s. Abschn.

346


„Einsatz des Hardware-Shadings“). Die Durchführung von Montierbarkeitsbetrachtungen ist auf Basis einer kontinuierlichen Kollisionserkennung der einzelnen Produktkomponenten zueinander realisiert. Hierzu wurde die freie Softwarebibliothek FreeSOLID eingesetzt [5.52], [5.147]. Im Produktentwicklungsprozess werden die Produktgeometrien aus dem CAD-System als Dreiecksnetze exportiert und können in Formaten wie vrml, inventor, stl, flt oder obj in die VR-Anwendung geladen werden. Bei sehr komplexen oder umfangreichen Produktdaten kann eine weitergehende Präparation der Modelle hinsichtlich Entkernen, Polygonreduktion und Healing [5.133], [5.158] erforderlich sein, um die Datenmenge an die verfügbare Rechenleistung anzupassen und gegebenenfalls Tesselierungsfehler zu beheben. Bei sehr umfangreichen 3D-Modellen kann die zur Darstellung erforderliche Rechenleistung so hoch sein, dass die Bildwiederholrate sichtbar einbricht und eine ergonomische und flüssige Bilddarstellung nicht mehr realisierbar ist. In diesem Fall können die in Abschn. „Paralleles Rendering“ beschriebenen Verfahren angewendet werden, um die Grafikleistung weiter zu erhöhen. Zur effizienten Implementierung der umfangreichen Funktionalitäten der verschiedenen Anwendungsfelder in eine gemeinsame, modulare Applikation wurde ein Anwendungsrahmenwerk entwickelt. Es handelt sich dabei um eine komponentenbasierte Klassenbibliothek für das VR-System Lightning. Sie stellt eine Reihe vorgefertigter Bausteine bereit, die effizient um zusätzliche Module für neue Funktionalitäten erweitert werden können und lehnt sich an die Standards zur Entwicklung von 2D-DesktopAnwendungen an. Auf dieser Basis können auch zukünftig VRApplikationen mit hohem Interaktionsgrad und komplexen Funktionalitäten modular entwickelt, optimiert und erweitert werden. Die bisher häufig nur in separaten Anwendungen vorliegenden Funktionalitäten aus den Bereichen Design-Review, Montierbarkeitsbetrachtung, Ergonomieanalyse und CAD-Evaluation sind nun in einer gemeinsamen Anwendung mit durchgängiger und intuitiv bedienbarer Benutzungsschnittstelle verfügbar. Die Anwendung wird derzeit im VR-Center von DaimlerChrysler getestet. Die bisher erforderlichen Rüstzeiten bei mehreren Einzelanwendungen konnten reduziert werden, was insbesondere bei komplex strukturierten Produktdatensätzen, die bei industriellen Anwendern häufig in Einzelteilen aus dem PDM-System bezogen werden, zu Zeitersparnis führt. Die Anwendung kann flexibel auf verschiedenen Projektionssystemen wie Projektionsraum, Projektionswand, immersiver Arbeitstisch, Datenhelm und monoskopischer Bildschirmarbeitsplatz in Verbindung mit magnetischen oder optischen Trackingsystemen eingesetzt werden. Die Applikation wird kontinuierlich weiterentwickelt und bildet die Basis für neue VR-Anwendungen wie beispielsweise zur VR-


347

gestützten Fertigungsplanung. Hierbei steht neben den aufgabenspezifischen, spezialisierten Funktionen stets auch der gesamte Funktionsumfang der vier oben beschriebenen Anwendungsbereiche des CAD-Review zu Verfügung. 5.3.2 CAD-VR Integration In vielen industriellen Anwendungsfeldern tragen virtuelle Umgebungen in der Produktentwicklung bereits heute zur Steigerung von Effizienz und Entscheidungssicherheit bei. Ein großer Teil dieser Anwendungen beschränkt sich jedoch auf die „passive“ Evaluation und Analyse von 3DProduktmodellen. Werden bei der VR-Evaluation Konstruktionsfehler oder Verbesserungspotenziale an den virtuellen Prototypen identifiziert, so ist die Korrektur bisher meist nur durch die Desktop-Anwendung am entfernten Arbeitsplatz des verantwortlichen Ingenieurs möglich. Die aufwändigen Iterationen zwischen Desktop-CAD- und VR-System im Produktentwicklungsprozess können zu erheblichem zeitlichem Aufwand führen. Durch Bereitstellung von CAD-Modellierfunktionalitäten auch innerhalb des VR-Systems kann dieser Zeitaufwand verringert werden. Das konzeptionelle, immersive Freihand-Modellieren in virtuellen Umgebungen ist in der Forschung seit längerer Zeit Gegenstand von Untersuchungen [5.34], [5.40], [5.153]. Hingegen wurde die parametrische Erzeugung und Manipulation mathematisch definierter Konstruktionsdatensätze, die Grundlage der industriellen CAD-basierten Produktentwicklung ist, als VR-Anwendung bisher nur ansatzweise realisiert. Auch die CADSoftwarehersteller zeigen sich bezüglich der Unterstützung von VRTechnologie bisher noch zurückhaltend, wenngleich erste Vorstöße in diese Richtung zu verzeichnen sind [5.37], [5.128]. Die beiden bisher getrennten „Welten“ CAD und VR wurden am IAT zusammengeführt, um die Anzahl der Iterationen zwischen Analyse in VR und Modifikation am CAD-Desktop und damit auch die Entwicklungszeit zu verringern. Besteht innerhalb der VR-Anwendung die Möglichkeit, direkt auf die Konstruktionsdatensätze des bearbeiteten Produkts und damit aller, das Produkt bestimmenden geometrischen Parameter zuzugreifen, so kann sowohl die Korrektur von Konstruktionsfehlern wie auch die Optimierung der Gestaltung noch innerhalb der Evaluationssitzung in VR durchgeführt werden. Zur Integration von CAD und VR können unterschiedliche Strategien verfolgt werden:

348


Integration eines CAD-Kerns in das VR-System Der höchste Integrationsgrad zwischen beiden Systemen wird dann erreicht, wenn die Bedienung des CAD-Systems durch die Benutzungsschnittstelle der VR-Anwendung stattfindet. Dieser Ansatz erfordert die Integration des CAD-Kerns in die VR-Software oder aber zumindest eine sehr enge Koppelung zwischen beiden Systemen. Bei dem am IAT realisierten Ansatz wurde der bestehende CAD-Kern OpenCASCADE [5.119] in das VR-System Lightning integriert und eine immersive Benutzungsschnittstelle zum Zugriff auf die Modellierfunktionen entwickelt (s. Abb. 5.12.). Der CAD-Kern dient zur Generierung und Verwaltung der mathematischen Beschreibung der modellierten Produktgeometrien, während das VR-Softwaresystem als grafisches Frontend die Geometrien darstellt und die Modellier-Interaktionen ermöglicht. Neben den Funktionen zur Teilekonstruktion (Part-design) wird auch eine Reihe von Zwangsbedingungen (Constraints) für den Zusammenbauvorgang (Assembly) angeboten. Der Austausch parametrischer Geometriemodelle mit anderen CAD-Systemen erfolgt über die standardisierten Datenformate STEP oder IGES.

Abb. 5.12. CAD-VR: Integration eines CAD-Kerns in das VR-System Lightning des IAT. Die Modellierung erfolgt durch eine 3D-Benutzungsschnittstelle.


349

CAD auf dem virtuellen Desktop in VR Das System „Sensing Surfaces“ des IAT ermöglicht die Fernbedienung einer Windows- oder UNIX-Workstation aus der virtuellen Umgebung. Hiermit kann der Konstrukteur das CAD-System mit dem Produktdatensatz von seinem Arbeitsplatzrechner oder beliebigen anderen, im Netz erreichbaren Rechnern in ein Fenster innerhalb der VR-Anwendung einblenden und bedienen [5.29]. Änderungen an der CAD-Konstruktion im CADSystem, die in dem in VR eingeblendeten Fenster durchgeführt werden, können umgehend in der laufenden VR-Evaluationsanwendung aktualisiert werden (s. Abb. 5.13.). Damit entfällt der sonst erforderliche Wechsel des Arbeitsplatzes zwischen VR-Evaluation und CAD-Modifikation.

Abb. 5.13. Sensing Surfaces: VR-Anwendung zur Fernbedienung eines entfernten Bildschirmarbeitsplatz-Rechners.

Die Entwicklung setzt auf das Protokoll VNC (virtual network computing) auf, das einen Verteilungsmechanismus für Rechnersysteme mit graphischer Benutzungsschnittstelle anbietet. Im entwickelten Ansatz wird der Bildschirminhalt des fernbedienten Rechners durch die dort laufende VNC-Server-Anwendung kontinuierlich an das VR-System übermittelt. In

350


der virtuellen Umgebung wird der Bildschirminhalt des entfernten Rechners auf eine Geometrie-Ebene projiziert und kann durch die VREingabegeräte bedient werden. Ein vom Eingabegerät ausgehender, virtueller Selektionsstrahl steuert den Mauszeiger, während für alphanumerische Eingaben eine virtuelle Tastatur eingeblendet oder eine physische Tastatur verwendet werden kann. Neben dem CAD-System stehen auch alle weiteren, auf dem entfernten Rechner installierten Anwendungen in der virtuellen Umgebung zu Verfügung [5.13]. Für diesen und den im folgenden Abschnitt dargestellten Ansatz wird ein begrenztes Ausmaß an Produktkomplexität vorausgesetzt, bei der noch keine gesonderte Datenaufbereitung zwischen CAD und VR-Visualisierung zwischengeschaltet werden muss. Einsatz eines mobilen CAD-Rechners in VR Dieser Ansatz verbindet das CAD-System eines drahtlos vernetzten Notebooks mit der immersiven VR-Anwendung. Die VR-Anwendung ermöglicht die Evaluation des Produktes in der immersiven Umgebung. Die hierbei zu Tage tretenden Änderungserfordernisse können direkt in der virtuellen Umgebung durch die, dem Ingenieur vertraute, CADBenutzungsschnittstelle auf dem Notebook durchgeführt werden (s. Abb. 5.14.).

Abb. 5.14. Kopplung des CAD-Review im VR-System mit dem CAD-System am Tablet-PC.


351

Anschließend wird die am Notebook geänderte Produktkomponente in die VR-Anwendung übertragen und ersetzt dort die vorhergehende Version der Produktkomponente. Dabei werden nicht alle, sondern nur die jeweils veränderten Geometrien des Produktes vom Notebook an das VRSystem übertragen. Für den ergonomischen Einsatz eines portablen Rechners im VR-System ist eine am Körper fixierbare Haltevorrichtung oder ein Stehtisch empfehlenswert. Bei diesem, wie auch dem vorangegangenen Ansatz können prinzipiell unterschiedliche CAD-Systeme eingesetzt werden. Die vorgestellten Ansätze zeigen verschiedene Integrationsstrategien auf, die den direkten Zugriff auf die geometrische Produktdefinition im CAD-System erlauben. Durch eine lose Koppelung von CAD- und VRSystem besteht große Flexibilität bezüglich der in den immersiven Systemen eingesetzten Desktop-Anwendungen. So kann in einer Arbeitssitzung neben CAD beispielsweise auch auf unternehmensweite PDM-Systeme, Spezifikationsdokumente oder auch auf Kommunikationstools wie E-Mail oder Audio-/Videokonferenz-Anwendungen zugegriffen werden. Die Produktentwicklung würde insbesondere von einer direkten Unterstützung der VR-Anzeige- und Interaktionstechnik durch die bereits bestehenden CAx-Systeme profitieren, wodurch der derzeit teilweise noch hohe Aufwand für die Datenaufbereitung zwischen CAD- und VRAnwendungen bei komplexen Produktgeometrien ebenfalls nicht mehr erforderlich wäre. 5.3.3 VR am Konstruktionsarbeitsplatz Mit den gegenwärtig verfügbaren VR-Installationen ist es nicht oder nur schwer möglich, VR-Technologien in allen Stadien der Prozesskette zu nutzen. Aktuelle VR-Installationen sind nicht zuletzt aus Kostengründen häufig nur als zentrale VR-Center konzipiert. Die am Entwicklungsprozess beteiligten Personen nutzen VR-Center mehr oder weniger regelmäßig um den aktuellen Entwicklungsstand zu analysieren und zu diskutieren. Um die Vorzüge der VR-Technologie in allen Entwicklungsphasen nutzen zu können, ist es hingegen notwendig, für den Büroarbeitsplatz taugliche, kompakte und kostengünstige VR-Installationen zu entwickeln und bestmöglich in bestehende Arbeitsabläufe zu integrieren. Immersive Arbeitsplätze müssen sehr gute ergonomische Eigenschaften aufweisen, die ermüdungsfreies Arbeiten auch über längere Zeit erlauben. Die Gestaltung und Dimensionierung des Arbeitsplatzes muss sich an den Projektgegebenheiten, der typischen Produktgröße und an den Präferenzen der jeweiligen Nutzer orientieren. In der Regel sind die gegenwärtig in der Industrie ein-

352


gesetzten VR-Installationen kaum zur Langzeitnutzung geeignet und nur schwer in die Büroarbeitsplätze der Produktentwickler integrierbar. Am IAT wurde zur Lösung dieser Fragestellung die ergonomische Qualität gegenwärtiger VR-Systeme untersucht, mit bestehenden Richtlinien für Bildschirmarbeitsplätze abgeglichen und mögliche Verbesserungsmaßnahmen für zukünftige VR-Systeme erarbeitet. Auf dieser Basis wurde die Konzeptstudie PIcasso entwickelt, um die VR-Technologie auch an Büroarbeitsplätzen verfügbar zu machen (s. Abb. 5.15.). PIcasso erweitert den klassischen Bildschirmarbeitsplatz des Benutzers um ein kompaktes, ergonomisches VR-System mit einer in den Tisch integrierten Anzeige. Die Bildschirmdiagonale beträgt dabei etwa 125-150cm (bzw. 50“-60“). Diese Anzeige kann sowohl stereoskopisch für VR, als auch monoskopisch für die Büroarbeit eingesetzt werden. So lassen sich beispielsweise Produktentwicklungsarbeiten mit bestehenden CAx-Tools am Desktop-Rechner gemeinsam mit der Analyse in VR durchführen.

Abb. 5.15. Konzeptstudie PIcasso: kombinierter Bildschirm- und VR-Arbeitsplatz

Durch die, für Projektionssysteme vergleichsweise kleine Schirmfläche wird eine für VR-Systeme hohe Helligkeit erreicht. Das System kann dadurch auch bei der, für Bildschirmarbeitsplätze empfohlenen Mindestleuchtdichte von 300 Lux betrieben werden. Bei herkömmlichen, projektionsbasierten VR-Systemen ist meist eine Abdunkelung der Umgebung auf 1-50 Lux erforderlich. Auch die Auflösung des Bildes erreicht bei PIcasso


353

mit etwa 37% des maximalen Auflösungsvermögens des menschlichen Auges einen vergleichsweise hohen Wert, da gängige Systeme heute hiervon durchschnittlich nur etwa 13-23% erzielen. Zur Positionsbestimmung der Augen und der Eingabegeräte wird ein präzises und latenzarmes optisches Trackingsystem mit zwei bis drei Kameras eingesetzt. Hierdurch entfällt die elektromagnetische Belastung der Umgebung, wie sie von den heute noch verbreiteten, magnetfeldbasierten Trackingsystemen ausgeht. Der Arbeitstisch bietet die Möglichkeit, das VR-System in sitzender Haltung zu nutzen. Hierbei können die Arme im VR-Modus und der damit einhergehenden Interaktion in den sechs Freiheitsgraden des Raumes zur Entlastung stets auch auf der Tischfläche abgesetzt werden. Für die immersive Interaktion wurde eine Reihe unterschiedlicher, drahtloser und drahtgebundener Interaktionsgeräte entwickelt, die inzwischen teilweise bereits als Produkte kommerziell angeboten werden. Der Betrieb von PIcasso erfolgt durch Rückprojektion auf Basis zweier LCD- oder DLPProjektoren. Die Stereoseparation wird durch Polarisations- oder Spektralfilter [5.36] im Passiv-Stereo-Modus realisiert. Die Bildgenerierung erfolgt durch zwei herkömmliche, synchronisierte Grafik-PCs mit beliebigen, stereoskopiefähigen 3D-Anwendungen, wie zum Beispiel der am IAT entwickelten VR-Software Lightning oder geeigneten CAx-Applikationen. Kompakte, modular aufgebaute immersive Arbeitsplatzsysteme eignen sich nicht nur als Konstruktions- und Entwicklungsarbeitsplätze, sondern sind auch für andere Bereiche sinnvoll einsetzbar, in denen Information aus der räumlichen Struktur von 3D-Daten hervorgeht. Aus den angestrebten, vergleichsweise niedrigen Systemkosten, den kompakten Abmessungen, der ausgezeichneten Bildqualität und der geplanten Modularität ergeben sich eine Vielzahl neuer Einsatzszenarien wie z.B. in Architektur, Medizin, Psychologie oder auch im Umfeld von virtuellem Training und Marketing. Für die weitere Verbreitung der Technologie wird derzeit unter anderem intensiv an günstigeren Lösungen für die Positionsmessung gearbeitet. 5.3.4 Realitätsnahe Darstellung in VR In den folgenden Kapiteln „Einsatz des Hardware-Shadings“ und „Paralleles Rendering“ werden zwei Verfahren beschrieben, durch die eine Verbesserung der Darstellungsqualität und eine Erhöhung der Leistungsfähigkeit von VR-Systemen erzielt werden kann. Diese Verfahren eignen sich sowohl für die Produktentwicklung als auch für viele weitere Aufgabenstellungen, in denen VR heute zum Einsatz kommt.

354


Einsatz des Hardware-Shadings Eine wesentliche Komponente jedes VR-Systems ist die EchtzeitBildgenerierung. Die darstellbare Szenenkomplexität und Bildqualität sind Parameter, die für die Anwendbarkeit von VR für eine gegebene Aufgabe entscheidend sind. In der digitalen Produktentstehung ist eine anmutungstreue Visualisierung besonders bei Gestaltungsaufgaben von Bedeutung. VR-Systeme nach dem Stand der Technik verwenden für die BildGenerierung spezielle Hardware [5.114], die heute in den meisten PCGraphikcontrollern integriert ist und daher oft auch als GPU (Graphics Processing Unit) bezeichnet wird. Moderne GPUs enthalten statt fest verdrahteter Funktionseinheiten programmierbare Vektorprozessoren [5.103]. Damit wird eine erheblich größere Flexibilität hinsichtlich der für die Bildgenerierung anwendbaren Algorithmen erreicht. Dies wird bisher vor allem in Computerspielen genutzt; die dort eingesetzten Renderingverfahren sind zwar oft auf VR-Anwendungen übertragbar, der in der digitalen Produktentstehung akzeptable Aufwand für die visuelle Modellaufbereitung ist jedoch um Größenordnungen geringer als bei Computerspielen. Es wurden daher Methoden und Werkzeuge entwickelt, die eine hochwertige visuelle Qualität auch mit relativ geringem Aufwand und hohem Integrationsgrad in den digitalen Produktenstehungsprozess ermöglichen. Die Analyse der Prozesse ergab die wesentliche technische Anforderung, dass auch komplexe visuelle Effekte ähnlich wie bisherige, nur aus Beleuchtungsparametern und eventuell Texturen bestehende Materialdefinitionen handhabbar sein müssen. Daraus folgt die Notwendigkeit der vollständigen Beschreibbarkeit eines visuellen Effektes möglichst innerhalb eines einzigen Datenformates. Für die Programmierung der Vertex- und Fragmentprozessoren der GPU stehen Compiler für C-ähnliche Hochsprachen zur Verfügung [5.91]. Die vollständige Beschreibung eines visuellen Effektes, der von der GPU darstellbar ist, erfordert jedoch noch weitere Informationen, z.B. Parameter und verwendete Ressourcen. Zudem kann ein Effekt aus mehreren Rendering-Durchläufen (Passes) bestehen. Es existierten bereits einige Ansätze für Dateiformate zur Effektbeschreibung. Deren Analyse ergab, dass das CgFX-Format von NVIDIA obige Anforderungen weitgehend erfüllt [5.118]. Zudem existieren Softwarewerkzeuge, mit denen CgFX-Effekte erstellt werden können. Daher wurde eine prototypische Realisierung der Shaderunterstützung im VRSystem Lightning des IAT auf der Basis dieses Formates durchgeführt. Dies erforderte vor allem eine umfangreiche Modifikation und Erweiterung des zugrunde liegenden Szenegraphen-Renderers.


355

Auf VR-Systemebene steht nun ein dediziertes Materialobjekt zur Verfügung, das beliebigen Geometrien zugewiesen werden kann. Diese Funktionalität ist jedoch für die Fachanwender, hauptsächlich Gestalter, so noch nicht zugänglich. Es war daher ein Werkzeug zu entwickeln, das den Gestaltern selbst die einfache visuelle Aufbereitung ihrer Modelle ermöglicht. Von den Anwendern wurde dabei ein unmittelbares visuelles Feedback aller Änderungen als besonders wichtig bewertet. Für eine optimale Prozessintegration war zudem Flexibilität hinsichtlich der verwendbaren Eingangs-Datenformate sowie der Datenhaltung für die Szenenbeschreibung von besonderer Bedeutung. Als Ergebnis steht das Softwarewerkzeug VRfx zur Verfügung, das die effiziente Erstellung visuell hochwertiger VR-Modelle durch Gestalter ermöglicht (s. Abb. 5.16.). Die Benutzungsoberfläche wurde dabei so gestaltet, dass Anwender gängiger Modelliersysteme wie Maya oder 3ds Max das Werkzeug nach sehr kurzer Einarbeitungszeit anwenden können.

Abb. 5.16. VRfx-Benutzungsoberfläche. Die Design-Anwendung kann am Desktop zur Datenpräparation und im VR-System zur Datenanalyse eingesetzt werden.

356


Der Einsatz programmierbarer Grafikhardware ermöglicht eine erheblich höhere visuelle Qualität im Echtzeitrendering. Es wurde gezeigt, dass bei optimaler Integration diese Qualität auch in der Virtuellen Realität erreicht werden kann. Für die Anwendbarkeit in der Produktentstehung sind dabei neben einer performanten Implementierung vor allem die Integration in den Prozess sowie die Handhabbarkeit von besonderer Bedeutung. Allerdings ist der erreichbare Datendurchsatz bei hochkomplexen Modellen auch bei Verwendung der neuesten Graphikkarten-Generation oft noch nicht ausreichend, insbesondere in Kombination mit komplexen visuellen Effekten. Daher wurde am IAT auch untersucht, inwieweit durch Parallelisierung der Bildberechnung auf mehrere Rechner und damit Graphikkarten diese Durchsatzgrenze überwunden werden kann; hierzu mehr im nächsten Abschnitt. Eine weitere wesentliche Steigerung des visuellen Realismus ist von globalen Beleuchtungsverfahren wie Raytracing oder Photon Mapping zu erwarten, die, im Gegensatz zu den rein lokalen Beleuchtungsmodellen des Hardware-Echtzeitrenderings, auch die Wirkung des von Objekten reflektierten Lichtes auf andere Objekte berücksichtigen. Der Rechenaufwand hierfür ist nochmals um ein Vielfaches höher. Durch optimierte, parallele Implementierungen steht Raytracing heute jedoch bereits an der Schwelle zur Echtzeitfähigkeit auch im VR-Einsatz. Bei der Weiterentwicklung des VR-Systems am IAT wird der Integration globaler Beleuchtungsverfahren daher besondere Bedeutung beigemessen.

5.4 Paralleles Rendering Die wachsende Menge an Daten, welche von Simulationen oder im CADReview komplexer Produkte erzeugt wird, erfordert auch neue Herangehensweisen an die Visualisierung. Denn obwohl Graphikworkstations in den letzten Jahren immens an Leistung gewonnen haben, ist es immer noch unmöglich, die Daten, welche für aufwendige Simulationen erzeugt werden, ohne Detailreduktion zu visualisieren, denn ein Endbild kann nur von einem einzigen Graphikprozessor (GPU) berechnet werden. Damit sind die maximal darstellbare Szenenkomplexität und -qualität vom Durchsatz einer einzelnen GPU begrenzt. Komplexere 3D-Objekte lassen sich oft nicht interaktiv darstellen, insbesondere bei Verwendung programmierbarer Vertex- und Fragmentprozessoren der GPU zur Darstellung komplexer visueller Effekte, wie dies im Abschnitt zur realitätsnahen Darstellung in VR beschrieben wurde. Durch eine Reduktion des Detaillierungsgrades und damit der Datensatzgröße können Artefakte entstehen, die

5.4 Paralleles Rendering

357

die Auswertung des Datensatzes erschweren oder verfälschen können. Zudem ist dieser Reduktionsprozess oft mit manueller Aufbereitung der Daten verbunden. Eine Möglichkeit, solche Einschränkungen und Fehler zu eliminieren, besteht darin, nur den jeweils betrachteten Teilbereich im Detail darzustellen, während die umgebenden Geometrien nur vereinfacht dargestellt werden. Solche „Out-of-Core“-Visualisierungen sind jedoch sehr komplex umzusetzen und erlauben meist nicht den vollen Überblick über das betrachtete Objekt. Besser sind hier „Level-of-Detail“Betrachtungen, welche je nach Skalierungsgrad eine feinere Darstellung einblenden. Diese Form der Darstellung ist jedoch sehr speicherintensiv, da die Daten mehrfach in unterschiedlichen Auflösungen vorgehalten werden müssen. Eine weitere Möglichkeit, mit solchen Daten umzugehen, ist es, die Visualisierung nicht interaktiv zu erzeugen. Dies erlaubt eine höchstmögliche Qualität, allerdings ist hier eine Immersion und ein einfaches Handhaben der Datensätze sowie ein intuitives Arbeiten mit diesen nicht mehr möglich. Diese Methode ist besser für Präsentationsfilme geeignet denn für Datensatzanalysen. Eine elegantere Lösung ist hier, die Graphikerzeugung zu parallelisieren. Hierbei wird die Bilderzeugung auf mehrere Renderknoten, beispielsweise in Form separater Graphikworkstations, verteilt. Dies ist insbesondere deswegen interessant, da sich derzeit eingesetzte Renderingverfahren relativ trivial und fast linear parallelisieren lassen. Die Untersuchungen am IAT und HLRS basieren auf der Frage, inwieweit durch Einsatz mehrerer GPUs diese Skalierbarkeit der EchtzeitBildgenerierung erreicht werden kann und welche Auswirkungen die unterschiedlichen Verteilungsformen auf die Bildgenerierungsleistung haben. Dabei sollten nach Möglichkeit nur Standardhardware-Komponenten, also Cluster aus Standard-PCs zum Einsatz kommen, um die Hardwarekosten für die Realisierung eines Echtzeitrendering-Clusters in Grenzen zu halten [5.30]. Es gibt verschiedene Möglichkeiten, die Parallelisierung zu realisieren. Die einfachste Methode ist, den Bildschirmbereich in gleich große Unterabschnitte aufzuteilen. So muss eine Graphikworkstation nur noch einen kleinen Teil des Gesamtbildes erzeugen, wodurch sich die erreichbare Bildwiederholrate erhöht. Da jedoch in den verschiedenen Bildbereichen die Objektkomplexität sehr unterschiedlich ist, sind die Graphikknoten oft sehr ungleich ausgelastet. Dies führt in der Gesamtheit zu einer Verringerung der Rendergeschwindigkeit, da das Gesamtbild erst erzeugt werden kann, wenn der langsamste Knoten seine Berechnungen beendet hat. Eine gewisse Abhilfe kann hier ein dynamisches Verkleinern und Vergrößern des Bildbereichs nach jedem erzeugten Bild sein, um die Last zwischen den einzelnen Knoten wieder annähernd gleich zu verteilen. Die Einzelbil-

358


der der Renderknoten werden dann an einen Darstellungsknoten geschickt, der diese zu einem Gesamtbild zusammensetzt. Ein solches „Tile-based Rendering“ ist ausreichend, um die Darstellung relativ komplexer Datensätze, welche von mittelgroßen Clustern erzeugt werden, in interaktiven Frameraten zu ermöglichen. Steigt die Datensatzgröße jedoch weiter an, so dass die Geometrien des Datensatzes nicht mehr vollständig in den Speicher der Graphikworkstation passen, sind andere Verfahren nötig, die schon den Datensatz auf die verschiedenen Rechner verteilen. Diese sind in drei Kategorien unterteilt, je nachdem an welcher Stelle der Graphikpipeline die Aufteilung und Sortierung von Objekt- in den Bildschirmraum durchgeführt wird: Sort-First, Sort-Middle und Sort-Last [5.113]. Im Sort-First-Verfahren übernimmt wie beim „Tile-based Rendering“ jeder Rechnerknoten einen bestimmten Teilbereich des Bildschirms, in den er zeichnet. Die Geometrien jedoch sind nicht vollständig im Speicher des Knotens abgelegt, sondern nur diejenigen, die im designierten Bildschirmbereich sichtbar sind. Wird das Objekt verschoben oder gedreht, werden jeweils die nötigen Geometrien in den Speicher geladen und nicht mehr benötigte wieder gelöscht.

Abb. 5.17. Tiled-/Sort-First-Rendering

Bei Sort-Last werden einzelne Geometrien der gesamten Szene statisch auf die Renderknoten verteilt. Jeder Knoten rendert seine Objekte in der endgültigen Auflösung. Die einzelnen Bilder werden dann an den Darstellungsknoten geschickt, der diese überlagert und anzeigt. Damit dies funktioniert, muss noch die Information mitgeschickt werden, wie weit jeder Pixel des Bildes entfernt ist. Nur so ist sichergestellt, dass sich die Objekte korrekt überlagern und gegebenenfalls verdecken. Sort-Middle schließlich wandelt die Geometrien schon in einfache Graphikelemente, sogenannte Primitive, bevor sie verteilt und weiterverarbeitet werden. Diese Art der Parallelisierung ist jedoch derzeit unüblich, da es


359

für heutige Graphikkarten einen starken Leistungsverlust bedeuten würde, hier in die Pipeline einzugreifen und die Daten zu extrahieren. Sie ist daher nur in spezieller Hardware implementiert und soll hier nicht weiter betrachtet werden. Sowohl Sort-First als auch Sort-Last haben ihre spezifischen Vor- und Nachteile. Sort-First zeichnet sich durch eine einfache Implementierung insbesondere auf Seiten des Darstellungsknotens aus. Die Bilder müssen nur aneinandergesetzt werden und können dann zeitnah angezeigt werden. Sort-Last erfordert hier einen wesentlich größeren Aufwand, da zum einen die Tiefeninformationen ausgewertet werden müssen und zum anderen die Überlagerung transparenter Geometrien nicht trivial ist. Werden letztere nicht gesondert behandelt, stellen sich unerwünschte Effekte ein. Transparente Geometrien überlagern vollständig andere Objekte, oder andere Objekte überlagern die Transparenz, obwohl sie eigentlich durch diese durchscheinen sollten. Auch finden Farbverfälschungen statt, wenn verschiedene transparente Objekte nicht in der richtigen Reihenfolge verschmolzen werden. Dafür ist Sort-Last auf der Renderknotenseite einfacher zu realisieren, da die Objekte nur einmal aufgeteilt werden müssen und sich dann meist deren Verteilung nicht mehr ändert.

Abb. 5.18. Sort-Last-Rendering

Sort-First erfordert hier ein ständiges Überprüfen, welche Geometrien im Bildschirmbereich derzeit sichtbar sind und welche nicht. Das Laden und Entfernen der Geometrien im Speicher erfordert teilweise einen sehr großen Kommunikationsaufwand, der sich stark auf die Renderleistung auswirken kann. Dafür ist der Sort-First-Renderer effektiver, da verdeckte Objekte nicht vollständig gezeichnet werden müssen, sondern vorzeitig verworfen werden können. Beim Sort-Last-Renderer ist dies nicht möglich, da dieser keine Informationen über Objekte auf anderen Renderknoten besitzt.

360


Die Anforderungen von VR an das Echtzeitrendering unterscheiden sich von anderen Anwendungen erheblich, insbesondere hinsichtlich folgender Punkte x Ausreichend hohe Bildwiederholrate, um eine immersive Wahrnehmung zu ermöglichen. x Kurze Latenzzeit zwischen Interaktion und deren sichtbarer Auswirkung. x Zur Laufzeit veränderliche Szenen, hauptsächlich durch Benutzerinteraktionen. Diese Kriterien wurden beim Entwurf des Echtzeitrenderingsystems besonders berücksichtigt. Die grundlegende Architektur des Systems am IAT zeigt Abb. 5.19.

Abb. 5.19. Architektur des parallelen Renderingsystems am IAT

Am IAT wurde die Eignung der beschriebenen Verfahren für unterschiedliche Aufgaben mittels des oben beschriebenen parallelen Renderingsystems untersucht. Als besonders geeignet erwies sich die Sort-FirstParallelisierung, bei der das Endbild in Teilbereiche unterteilt wird und jeder Renderingknoten einen solchen Teilbereich berechnet. Dieses Verfah-


361

ren stellt die geringsten Anforderungen an die Netzbandbreite, die zudem anders als bei anderen Verfahren nicht von der Anzahl der Renderingknoten abhängt. Es erfordert jedoch eine dynamische Lastverteilung durch Anpassung der Bildunterteilung an die (sichtabhängige) Verteilung der sichtbaren Szenenteile im Bild. Auch muss dazu die Szene räumlich so unterteilt werden, dass eine hinreichend feinkörnige Zuordnung der Szenenteile zu den einzelnen Bildbereichen möglich ist. Andernfalls werden zu viele Szenenteile von mehr als einem Renderingknoten dargestellt, was den Skalierungsgewinn wieder reduziert. Für die sichtabhängige, dynamische Lastverteilung wurde ein effizientes prädiktives Verfahren entwickelt, das keine Kohärenz der Lastverteilung in aufeinander folgenden Bildern erfordert und sich daher besonders für veränderliche Szenen eignet. Am HLRS wurde auch ein Tiled-Renderer für VR implementiert. Dieser entspricht in seinem Aufbau prinzipiell dem des IAT. Hierbei kann der Master (Combiner) auf einem Rendering-Knoten betrieben werden. Das Compositing für Sort-First ist nicht sehr rechenintensiv, weshalb sich der Master-Knoten meist im Leerlauf befindet. Durch die Integration in einen Renderknoten stehen die ansonsten dedizierten Masterknoten für weitere Renderaufgaben voll zur Verfügung. Die Sort-Last-Parallelisierung, bei der anstelle des Bildraumes die darzustellende Szene zerlegt und auf die Renderingknoten verteilt wird, hat den Vorteil, dass die Lastverteilung nicht sichtabhängig ist; auch die räumliche Strukturierung der Szene spielt nur eine untergeordnete Rolle. Wesentlicher Nachteil beim Einsatz von Sort-Last in einem ClusterRenderingsystem ist jedoch die sehr hohe benötigte Netzbandbreite, da jeder Renderingknoten den vollen Bildausschnitt berechnet und zudem zum Zusammensetzen des Endbildes auch die Tiefeninformation der Teilbilder benötigt wird. Durch spezielle Datenkompressionsverfahren und Einsatz schneller Netzwerkhardware wie der Scalable Coherent Interface (SCI) Technologie kann das Sort-Last-Parallelisierungsverfahren für eine begrenzte Anzahl von Clusterknoten dennoch einsetzbar sein [5.30]. Es konnte gezeigt werden, dass durch Parallelisierung der Bilderzeugung eine erhebliche Steigerung des Durchsatzes erzielt werden kann. Das entwickelte parallele Echtzeitrenderingsystem ist in das VR-Framework Lightning des IAT integriert und daher für eine Vielzahl von Anwendungen einsetzbar. Mit dem entwickelten Verfahren zur Sort-First-Lastverteilung wird bei kleinen Clustergrößen ein hoher Skalierungsgewinn erreicht; in einer Konfiguration mit vier Renderingknoten kann die Framerate um den Faktor 3 erhöht werden. Bei größeren Clustern (mehr als acht Knoten) reduziert sich der Skalierungsgewinn jedoch. Die Funktionsblöcke Applikation, dynamische Lastverteilung und Combiner können dabei auf einem einzelnen Clusterknoten zusammengefasst werden.

362


Obwohl sich die Renderingprozesse fast linear parallelisieren lassen, ist jedoch kein linearer Speedup zu verzeichnen, da das Auslesen des Graphikspeichers und das Senden über das Netzwerk einen großen Zeitbedarf aufweist. Insbesondere beim Sort-Last-Rendering, bei dem unter Umständen die volle Bildschirmgröße mehrfach versandt wird, ist dies ein Problem. Hocheffiziente Komprimierungsverfahren lassen sich auch nur teilweise einsetzen, da diese den Prozessor erhöht belasten. Es ist also vor dem Einsatz abzuwägen, ob sich parallele Renderingmethoden jeweils lohnen, oder ob sie sogar zu einer Verringerung der erreichten Framerate führen. Neue Netzwerktechnologien wie 10 Gigabit Ethernet oder Infiniband werden die Anwendbarkeit der Sort-Last-Parallelisierung verbessern. Mit der Installation eines Rendering-Clusters mit Infiniband-Connect am HLRS wird diese Richtung zentral verfolgt werden. Für den Rapid-Prototyping-Prozess erlaubt der Einsatz paralleler Renderingmethoden das interaktive Erkunden wesentlich größerer Datensätze mit einer höheren Genauigkeit, als dies vorher möglich war. Damit lassen sich Evaluierungen virtueller Prototypen in wesentlich kürzerer Zeit mit höherer Qualität durchführen. Eine weitere Forschungs- und Entwicklungsrichtung, die am IAT verfolgt werden wird, sind asymmetrische Parallelisierungsansätze, die nicht direkt auf die verteilte Berechnung des Endbildes, sondern von Vorstufen der eigentlichen Bildberechnung abzielen.

5.5 Virtuelle und Hybride Prototypen Visualisierung und Simulation physikalisch-technischer Zusammenhänge In jedem Entwicklungsprozess bilden Prototypen ein wichtiges Element, um Entscheidungen über den weiteren Verlauf der Produktentstehung zu treffen. Oft können nur anhand realer Modelle die tatsächlichen Eigenschaften des zukünftigen Produktes untersucht werden. Da sich die Erstellung eines realen Prototypen oft teuer und zeitaufwendig gestaltet, sind Einsparungen in diesem Bereich natürlich erstrebenswert. Ein Weg, der den realen Modellbau ergänzt und inzwischen auch schon oft komplett ersetzen kann, ist die vollständige Modellierung des Objektes im Rechner und der Bestimmung dessen Eigenschaften über Simulationen. Diese virtuellen Prototypen können in idealer Weise schnelle Iterationszyklen unterstützen, da Änderungen bestimmter Parameter und des Aussehens des Produktes oft innerhalb weniger Sekunden oder Minuten vorgenommen

5.5 Virtuelle und Hybride Prototypen

363

werden können. Ist es jedoch nötig, einen physischen Prototypen zu erstellen, möglicherweise weil die experimentelle Verifikation der Simulationsergebnisse notwendig ist, kann die Integration virtueller Komponenten in die Betrachtung des realen Prototypen eine Verbesserung des Verständnisses der Ergebnisse bewirken. So können beispielsweise an einem solchen hybriden Prototypen die experimentellen und simulierten Ergebnisse überlagert und gemeinsam betrachtet werden. Derzeitig eingesetzten virtuellen Prototypen fehlen oft jedoch wichtige Eigenschaften, welche Rapid-Prototyping-Prozesse benötigen. So ist der Ablauf zwischen Geometrieerzeugung, Simulation und Visualisierung oft nicht durchgängig, sondern in mehrere Schritte unterteilt und erfordert den manuellen Eingriff unterschiedlicher Experten. Eine frühzeitige und schnelle Abschätzung der Eigenschaften des zukünftigen Produktes, welche ein einfaches Aufsetzen und Manipulieren verschiedenster Szenarien erlaubt, ist so unmöglich. Wichtige Vergleiche zwischen Simulationsergebnissen und Experimenten sind oft nicht trivial, da verschiedene Ansichten getrennt in Übereinstimmung gebracht werden müssen. Das verteilte Entwickeln virtueller Prototypen wird derzeit sehr mangelhaft unterstützt. Wird an mehreren entfernten Standorten an einem Produkt geforscht, so bedeutet die Diskussion von Teilergebnissen oft, dass die beteiligten Entwickler anreisen müssen, um sich mit ihren Kollegen austauschen zu können. Dies erfordert Zeit; Zeit, die bei der Entwicklung des Produktes fehlt oder diese in die Länge zieht. 5.5.1 Virtuelle Prototypen Virtuelle Prototypen sind längst fester Bestandteil bei der Entwicklung neuer Produkte. Virtuelle Prototypen werden vollständig im Rechner entwickelt und getestet. Normalerweise steht am Ende dieser Tests die Erstellung eines tatsächlichen, physikalischen Prototyps. Das Ziel ist jedoch, auch auf diesen verzichten zu können, da dessen Erstellung zusätzliche Zeit erfordert. Ein typischer Verlauf der Erstellung eines virtuellen Prototypen für die Simulation physikalisch-technischer Vorgänge und deren Auswertung findet in mehreren Schritten statt (s. Abb. 5.20). Am Anfang steht die Geometrieerzeugung. Üblicherweise wird diese durch einen Konstrukteur mittels eines CAD-Programms erzeugt. Um mit diesen Daten Simulationen durchführen zu können, müssen diese in Berechnungsgitter umgewandelt werden, mit welchen die spezifische Simulation umgehen kann. Üblicherweise handelt es sich hierbei um eine hochkomplexe Arbeit, welche ein großes Expertenwissen voraussetzt.

364


Abb. 5.20. Übliches Vorgehen bei der Erzeugung und Evaluation virtueller Prototypen

Nach Beendigung der Simulation folgt ein Post-Processing-Schritt, welcher die Daten für die darauffolgende Visualisierung vorbereitet. Besonders effektiv lassen sich solche virtuellen Prototypen innerhalb immersiver virtueller Umgebungen studieren. Hier hat der Konstrukteur den Eindruck, direkt vor dem Objekt zu stehen, was das Interagieren mit dem Objekt und das Verstehen der Ergebnisse wesentlich greifbarer und intuitiver macht. Dabei haben virtuelle Prototypen viele Vorteile. Beispielsweise können Punkte am Objekt betrachtet werden, die am realen Prototypen nicht erreichbar wären. Auch können Situationen beobachtet werden, bei denen reguläre Messungen oder Betrachtungen unmöglich wären. Materialien können auf Mausklick ausgetauscht, Geometrien und Randbedingungen angepasst werden. Der größte Vorteil ist jedoch, dass es virtuelle Prototypen erlauben, schon in einer frühen Entwicklungsphase Probleme zu erkennen und zu beseitigen. 5.5.2 Online-Simulationen Die Simulationen, welche im Rahmen des Prototyping durchgeführt werden und auf Supercomputern oder massiv parallelen Clustern laufen, sind meist Batch-Jobs. Vor Beginn der Simulation werden relevante Parameter angegeben und in eine Konfigurationsdatei geschrieben. Danach wird die Simulation über ein Batch Queuing System an die Computing Platform geschickt, welche die Ergebnisse errechnet und zur Weiterverarbeitung auf die Festplatte schreibt. Obwohl heute viele Simulationsaufgaben auf einem


365

preisgünstigen PC-Cluster im interaktiven Modus erledigt werden können, hat dies nicht zu einer Verbesserung der grundlegenden Arbeitsmethoden geführt. Denn ungeachtet dessen, dass diese Methode sehr einfach ist, ist sie nicht dafür geeignet, schnell wichtige Eigenschaften des Produktes zu ermitteln, wie es insbesondere beim Rapid Prototyping erforderlich ist. Hier ist es wichtig, die Entwicklung der Simulation zu beobachten, Tendenzen im Simulationsablauf schnell auszuwerten und unmittelbar Eingangsparameter ändern zu können, um einen umfassenden Überblick über die Produkteigenschaften zu erhalten. Die meisten Simulationspakete bieten die Möglichkeit, den Simulationsverlauf zu überwachen, erlauben aber kaum eine gleichzeitige, umfangreiche Visualisierung oder die Veränderung relevanter Daten oder sogar der Objektgeometrien. Ein vollständig automatisierter Entwicklungszyklus wie in Abb. 5.20 dargestellt ist derzeit in der Industrie unüblich, obwohl er eine sehr enge Iterationsschleife zur Verfügung stellt. Auch fehlen meist intuitive Auswertungsmöglichkeiten wie eine virtuelle Umgebung und Interaktionsmöglichkeiten in einer Kombination aus drei- und zweidimensionalen Eingabegeräten.

Abb. 5.21. Online-Simulation einer Klimaanlage im Fahrzeugraum

Online-Simulation bedeutet, dass bei laufenden oder abgeschlossenen Simulationen deren Ergebnisse direkt in der Visualisierung bewertet wer-

366


den können. Direkt heißt in diesem Fall, dass Simulationen erste Ergebnisse innerhalb einer Minute oder weniger zur Verfügung stellen. Interessant wird dies insbesondere, wenn in die laufende Simulation eingegriffen werden kann, um Parameter der Simulation manipulieren zu können [5.22], [5.25], [5.31], [5.33], [5.115], [5.122]. Besonders effektiv funktioniert das aus einer VR-Umgebung heraus [5.123]. Der Konstrukteur steht direkt neben oder in dem Objekt und kann unmittelbar verschiedene Parameter ändern. Innerhalb weniger Sekunden werden Randbedingungen oder sogar Gitter verändert und an die Simulation weitergegeben, die die Ergebnisse wieder sofort an die Visualisierung in der Virtuellen Umgebung weiterleitet. Was diese Art von Simulationen so interessant macht ist die direkte Integration von High-Performance-Computing-Ressourcen in den RapidPrototyping-Prozess. Eine Umgebung, die es erlaubt, Visualisierung und Simulation direkt zu koppeln und eine enge Interaktionsschleife zwischen diesen aufzubauen, ist COVISE (COllaborative VIsualization and Simulation Environment). COVISE ist eine verteilte und kooperative Visualisierungsumgebung, die modular aufgebaut ist [5.127], [5.126]. Jeder Schritt in der Visualisierung – Einlesen der Daten, Extrahieren von Features, Abbilden von Daten auf Geometrien und Farben und das Darstellen der Ergebnisse – ist über Module als separater Prozess implementiert. Module können über eine graphische Benutzungsschnittstelle miteinander verbunden werden und bilden so eine Modul-Pipeline. Über Parameter können die Module konfiguriert werden. Somit lassen sich komplexe Visualisierungen mit wenigen Mausklicks zusammenstellen. Eine Besonderheit dabei ist, dass diese Module nicht auf einem einzelnen Rechner laufen müssen, sondern beliebig auf unterschiedliche Computer verteilt werden können. Dies ist vor allem dann wichtig, wenn sehr große Datenmengen visualisiert werden müssen, welche einen großen Post-Processing-Aufwand benötigen. Auch bleiben so auf der Visualisierungsmaschine möglichst viele Ressourcen frei, um interaktive Frameraten bei der Darstellung zu erreichen. Durch seinen modularen Aufbau eignet sich COVISE hervorragend, laufende Simulationen in den Auswertungszyklus zu integrieren und innerhalb der Visualisierung zu steuern. So wurde unter anderem in Zusammenarbeit mit DaimlerChrysler der Strömungslöser STAR-CD in COVISE integriert. Hier wird durch eine intuitive Steuerung ermöglicht, über die Änderung der Einströmrichtung sowie der Stärke und Temperatur der Luftströmung die Auslegung der Klimaanlage in einem Fahrzeug interaktiv zu optimieren [5.125]. Unter Zuhilfenahme eines ICEM HEXAGittergenerators können die Luftdüsen sogar an der Konsole frei verschoben und in ihrer Form geändert, die Position der Sitze verschoben und der Fahrer ausgetauscht werden. Man erhält also eine Art virtuellen Prüfstand,


367

welcher sowohl zur schnellen Überprüfung anfänglicher Konzepte als auch verschiedenster Parametervariationen in jedem Stadium der Entwicklung dienen kann. Viele kommerzielle Programme, so auch STAR-CD, erlauben über sogenannte User Subroutines den Zugriff auf interne Datenstrukturen der laufenden Simulation. User Subroutines sind Funktionen, die, so sie implementiert sind, an bestimmten Stellen des Simulationsablaufs aufgerufen werden. Dies kann man nutzen, um Daten zwischen Simulationsprogramm und einem COVISE-Modul auszutauschen. In Abb. 5.22 ist schematisch aufgeführt, wie sich Online-Simulationen mittels COVISE durchführen lassen. In diesem einfachen Fall sind zwei Rechner beteiligt: Ein Supercomputer, auf dem die Simulation abläuft, und eine Visualisierungsworkstation, welche das Post-Processing, die Darstellung und die Interaktion übernimmt. Im Regelfall würden diese Aufgaben auch auf verteilten Maschinen laufen, um die Last besser zu verteilen. Die Anbindung ist in zwei unterschiedlichen Komponenten implementiert.

Abb. 5.22. Verteilte Online-Simulation mit STAR-CD

Die eine Komponente läuft auf dem Supercomputer und ist als User Subroutine der Simulation realisiert. Die zweite besteht in einem COVISEModul, welches die Simulation auf dem Supercomputer startet, die Parameter weitergibt und die resultierenden Daten von der Simulation entgegennimmt. Das Modul übernimmt auch über Feedback-Nachrichten die Kommunikation mit der Virtual-Reality-Umgebung. In einem vollständigen Szenario würden noch weitere Komponenten ins Spiel kommen. So

368


sorgt ein spezielles Modul für die Parameteränderungen, welche die Geometrieerzeugung beeinflussen, und ein Tesseliermodul für die abschließende Gittergenerierung aus den parametrisierten Geometriedaten für die Simulation. Zur Darstellung der Ergebnisse wird der COVISE Virtual Environment Renderer (COVER) verwendet [5.126]. Dieser Renderer ist in jeder immersiven Umgebung wie CAVE, Powerwall, Curved Surfaces oder Head Mounted Displays (HMD) anwendbar. Auch ist er über Module, sogenannte Plugins, erweiterbar. Diese laufen jedoch nicht in einem eigenen Prozess, sondern sind als dynamische Bibliotheken zur Laufzeit ladbar. Über diese Plugins sind neue Funktionalitäten ohne Zuhilfenahme des vollständigen Sourcecodes des Renderers implementierbar. Sie sind auch dafür zuständig, Interaktionen aus dem Renderer an COVISE-Module über Feedback-Nachrichten weiterzugeben. Diese Nachrichten können aus vielfältigen Quellen stammen: x Regler im VR-Menü können bewegt werden, um Parameter zu ändern. x Spezielle Geometrien können als Ansatzpunkte für Interaktionen dienen. So kann im obigen Beispiel der Klimaauslegung des Fahrzeuginnenraums die Einströmrichtung und -geschwindigkeit über das Bewegen der Pfeile manipuliert werden, welche an den Einströmdüsen angezeigt werden. x Über einen TabletPC oder PDA können direkt Zahlenwerte eingestellt, Schieberegler bedient oder Optionen mittels Komboboxen ausgewählt werden. x Simulationen lassen sich auch von außerhalb mit Hilfe von Techniken der erweiterten Realität steuern. Alle diese Eingabemöglichkeiten zeigen spezifische Vor- und Nachteile. Zweidimensionale Eingabeformen zeigen eine hohe Akzeptanz sowohl bei gelegentlichen Benutzern virtueller Umgebungen als auch bei geübten Spezialisten. Insbesondere die Eingabemöglichkeit über den TabletPC hat sich im täglichen Gebrauch bewährt, um Parameter der Simulation zu steuern. Störend hierbei ist nur der „Context Switch“ zwischen der dreidimensionalen Darstellung und dem zweidimensionalen Benutzerinterface und dem damit verbundenen Wechsel des Eingabegeräts (3D-Maus – TabletPC-Stift). Insbesondere bei größeren Demonstrationen vor einem großen Publikum hat sich der TabletPC bewährt. Da das zu COVER gehörige TabletUI auch eine Navigationskomponente und den vollständigen Zugriff auf alle benötigten Komponenten der VR-Umgebung erlaubt, lassen sich diese Demonstrationen über das TabletUI zusammen mit vorbereiteten Flügen durch die Szene sehr elegant durchführen. PDAs eignen sich


369

aufgrund ihrer kleinen Dimensionen für die Steuerung der Simulation nur, wenn wenige Parameter eingestellt werden müssen, die in ausreichend großer Darstellung auf dem PDA erscheinen können. Wie in Abb. 5.23 ersichtlich, eignet sich das TabletPC User Interface auch hervorragend, um direkt Zahlenwerte anzugeben. Daneben ist die gleiche Eingabemaske als VR-Menü dargestellt. Hier können über Schieberegler die Werte verändert werden. Vorteilhaft ist hier, dass die Aktion in der immersiven virtuellen Umgebung stattfindet und mit dem selben Eingabegerät vorgenommen wird wie die anderen auch. Von Nachteil ist, dass die Eingabe ungenau ist und dass das Parameterfenster zeitweise interessante Objektstellen verdeckt und dann zur Seite geschoben werden muss.

Abb. 5.23. User Interface über TabletPC und VR-Menü

Dreidimensionale Interaktionen direkt am Objekt mit vielen Freiheitsgraden erfordern eine gewisse Einarbeitungszeit, danach kann jedoch oft effektiver damit gearbeitet werden. Abb. 5.24 zeigt als Beispiel einen dreidimensionalen Interaktor für die Simulation der Klimaanlage im Fahrzeuginnenraum, der die Luftdüse und deren Parameter repräsentiert. Der Pfeil regelt dabei die Einströmrichtung der Luft. Er kann angefasst und frei um den Rotationspunkt der Luftdüse bewegt werden. Über eine Scheibe kann die Einströmgeschwindigkeit der Luft angepasst werden. Über eine weitere Steuerscheibe – hier nicht im Bild – kann auch die Temperatur der einströmenden Luft geregelt werden. Ein solcher Interaktor ist wesentlich intuitiver als reine Schieberegler oder Zahlenwerte, da Metaphern verwandt werden, die der Erwartungshaltung des Benutzers entgegenkommen.

370


Abb. 5.24. Dreidimensionaler Interaktor zur Bedienung einer Luftdüse

5.5.3 Hybride Prototypen Werden reale Prototypen mit virtuellen Inhalten verknüpft, entstehen hybride Prototypen. Die Verknüpfung selbst geschieht mittels einer Technik, welche als „Erweiterte Realität“ (Augmented Reality – AR) bezeichnet wird [5.9], [5.10]. Üblicherweise wird eine Szene mittels einer Kamera aufgenommen, welche mit einem Rechner verbunden ist. Dieser analysiert das ankommende Kamerabild und überlagert es mit virtuellen Inhalten wie Simulationsergebnissen oder anderen Informationen. Dies wird derzeit in vielfältigen Anwendungen genutzt. So können Simulationsergebnisse mit Experimenten verglichen, Variantenstudien an realen Prototypen vorgenommen, Informationen zu derzeit im Sichtfeld befindlichen Objekten eingeblendet oder andere Visualisierungen direkt am Produkt vorgenommen werden [5.5], [5.7], [5.53]. Es ist sogar möglich, mit sogenannten „Tangible Interfaces“ [5.87], [5.173] über Veränderungen des realen Modells Parameter einer Simulation zu steuern, um so eine intuitive Eingabemöglichkeit direkt am Produktprototypen zu haben [5.14]. Die Verfolgung der Objekte geschieht derzeit mit Hilfe spezieller Marker, welche von Computer-Vision-Methoden leicht erkannt werden können und aus denen direkt die Position des Markers ermittelt werden kann. Das


371

häufig eingesetzte ARToolKit [5.6] benutzt dafür spezielle quadratische Marker, welche eine eindeutige Kennzeichnung im Inneren des Quadrates besitzen. Die Markerposition wird nun aus der Größe, Position und Verzerrung berechnet, die bei der Rotation und Translation des Markers entsteht. Direktes Tracking über die Analyse der Objektgeometrie, das die Verwendung von Markern unnötig werden ließe, ist derzeit noch nicht robust genug, um universell eingesetzt zu werden. So eignen sich Verfahren, welche beispielsweise zur Selbstlokalisation in der Robotik eingesetzt werden, um virtuelle Inhalte in statische Umgebungen einzubetten [5.38]. Jedoch ist die genaue Bestimmung der Rotation und Translation, welche bei der Überlagerung eines realen Prototypen mit virtuellen Inhalten notwendig wäre, bisher nicht möglich. Um reale Prototypen mit virtuellen Inhalten zu verknüpfen, können prinzipiell zwei Methoden angewandt werden. Einerseits kann ein physischer Prototyp in eine immersive Projektionsumgebung gestellt und durch im Hintergrund liegende, virtuelle Objekte ergänzt werden. Andererseits können virtuelle Bilder mittels eines Head Mounted Displays (HMD) einen realen Prototypen überlagern. Bei Verwendung eines HMD ist die Immersion natürlich wesentlich besser als in der Projektionsumgebung, da sich die virtuellen Objekte nahtlos in die Umgebung einfügen.

Abb. 5.25. Überlagerung eines realen SLK-Modells mit virtuellen Inhalten mit Hilfe eines HMD

372


Bei HMD gibt es zweierlei Ausführungen. Sogenannte „See-Through“HMD besitzen ein halbverspiegeltes Brillenglas, auf welches die virtuellen Inhalte projiziert werden. Vorteilhaft hierbei ist, dass diese Brillen sehr leicht und bequem zu tragen sind, jedoch lassen sich reale Bilder durch den halbdurchlässigen Spiegel nicht vollständig überlagern. Auch können sich Abweichungen zwischen der Position der realen und virtuellen Objekte ergeben, da die Erzeugung der Geometrien im Rechner zusätzlich Zeit benötigen. Insbesondere bei schnellen Kopf- oder Objektbewegungen ist ein deutlicher Versatz zwischen realen und virtuellen Objekten zu sehen, der sich oft störend auswirkt. Neben diesen halbdurchlässigen Displays gibt es voll geschlossene Brillen, die das Bild direkt auf kleinen Monitoren in der Brille darstellen. Somit lässt sich auf kleinstem Raum eine immersive Umgebung schaffen. Um nun nicht nur virtuelle Objekte, sondern auch reale Objekte sehen zu können, werden kleine Kameras auf dem HMD befestigt, deren Bilder mit den virtuellen Objekten überlagert und in die Displays des HMD eingespeist werden. Hier gibt es dann keinen störenden Versatz bei der Darstellung der unterschiedlichen Umgebungen, da das Kamerabild mit der virtuellen Darstellung synchronisiert werden kann. Nachteilig ist bei dieser Konstruktion das Gewicht, welches ein langes Arbeiten unmöglich macht.

Abb. 5.26. Realer Interaktor zur Bedienung einer Luftdüse


373

Über hybride Prototypen können jedoch nicht nur Darstellungen an realen Objekten betrachtet werden, sondern auch beispielsweise OnlineSimulationen gesteuert werden. So kann bei der Auslegung der Klimaanlage (Kap. 5.5.2) der Einströmwinkel nicht nur in der virtuellen Realität eingestellt werden, sondern auch über eine reale Luftdüse, welche im Fahrzeuginnenraum oder einer Nachbildung dessen montiert ist. In Abb. 5.26 wurde als Repräsentant für die Luftdüse eine Platte auf ein Kugelgelenk montiert, welches eine freie Bewegung um einen Drehpunkt ermöglicht. Auf der Platte ist ein Marker angebracht, welcher die Positionsbestimmung der Platte erlaubt. Wird nun das Luftdüsenmodell bewegt, registriert der Rechner die neue Einströmrichtung und kann nun die Parameter der Simulation dahingehend ändern. Der tatsächliche Start der Simulation wird durch ein kurzes Verdecken des Markers ausgelöst. Dies hat den Vorteil, dass die Simulation nur dann benachrichtigt werden muss, wenn tatsächlich ein Berechnungsergebnis gewünscht wird. Solch ein realer Interaktor hat durchaus Vorteile. So kann beispielsweise gleich überprüft werden, ob die Luftdüse komfortabel erreichbar ist.

Abb. 5.27. Strömungssimulation gesteuert über ein Tangible Interface

Interessant sind solche Tangible Interfaces auch, wenn man mit den verfolgten Objekten direkt die Gittererzeugung für eine Simulation beeinflussen kann. Durch Verschieben der Gegenstände in einem realen Modell kann gleichzeitig die Position der Geometrien im virtuellen Modell verändert werden, welches sowohl an eine virtuelle Umgebung als auch an einen Gittergenerator gekoppelt ist. So lässt sich die Simulation aufs Einfachste und Intuitivste steuern. Wird ein Gegenstand verschoben, ändert sich auch automatisch das Simulationsgitter. Als Demonstration, wie so etwas möglich ist, wurde für die Supercomputing 2004 ein Modell des Messestandes des HLRS erstellt. Mit diesem Modell wurde eine Strömungssimulation

374


gesteuert, welche den Luftstrom der Klimaanlage des Messestandes um die Tische, Plakat- und Videowände ermittelte. 5.5.4 Kooperatives Arbeiten mit virtuellen und hybriden Prototypen In einer globalisierten Wirtschaft, in der immer mehr Teile der Produktentwicklung an Zulieferer oder um den Globus verteilte Außenstellen abgegeben werden, ist es wichtig, Ergebnisse auch über große Entfernungen diskutieren und präsentieren zu können, damit eine physische Anwesenheit der im Projekt beteiligten Personen nicht mehr notwendig ist. Dies spart hochqualifizierten Experten nicht nur Zeit, sondern verringert auch in erheblichem Maße Kosten. Zusammen mit einer größeren Verfügbarkeit von VR-Installationen und schnellen Netzen, auch bei Betrieben mittlerer Größe, ergeben sich neue Möglichkeiten, Produktentwicklung rein über virtuelle Treffen abzuwickeln, bei denen mittels Video-Conferencing-Tools über virtuelle Prototypen diskutiert wird. Richtig eingesetzt können hier alle Aspekte der Produktentwicklung diskutiert und präsentiert werden. Forschungseinrichtungen können ihre Ergebnisse austauschen, Experten konsultiert oder Schulungen angeboten werden. Bei internationalen Konzernen kann das zu entwickelnde Produkt einfach dem Management präsentiert und Reviews durchgeführt werden. Wieder eignen sich hier virtuelle Umgebungen hervorragend, das zukünftige Produkt schon in der Planungsphase greifbar zu machen. Bei der Präsentation der Prototypen und beim kooperativen Arbeiten sind oft verschiedene Modi zur Interaktion mit der virtuellen Umgebung erforderlich [5.24]. In COVER sind drei Möglichkeiten implementiert, virtuelle Welten und die Analyseschritte in diesen zu synchronisieren. Bei der Diskussion neuer Produkte ist es oft wichtig, dass alle Partner den gleichen Blickwinkel auf die Dinge haben, damit keine Missverständnisse auftreten können. Bei einer solch engen Kopplung wird der Standpunkt und die Skalierung zwischen den Partnern genau synchronisiert. Jeder Beteiligte kann in seiner Umgebung frei navigieren, die Positionsänderungen werden direkt an die übrigen Teilnehmer verteilt. Diese Art der Kopplung wird in COVER „Tight Coupling“ genannt und eignet sich insbesondere für kleinere Objekte und bei Präsentationen in Expertengruppen. Sollen Präsentationen durchgeführt werden, ist es oft nicht erwünscht, dass alle Partner mit der virtuellen Welt interagieren können. Hier wird ein Modus benötigt, bei dem jeweils nur ein festgelegter Partner, der „Master“, agieren kann, während die „Slaves“ nur zusehen können. Es ist aber auch möglich, die virtuellen Welten nur lose zu koppeln („Loose Coupling“)


375

und den Partnern größtmögliche Bewegungsfreiheit zu erlauben. Dadurch kann jeder die dargestellten Objekte aus dem Blickwinkel und mit der Skalierung betrachten, wie er möchte. Es werden jedoch alle Veränderungen der Welt an die Partner weitergeleitet und dort dargestellt. Die Personen selbst, welche sich in der Szene befinden, werden als Avatare an der Stelle dargestellt, an der sie sich befinden. Derzeit stellt COVER Avatare über eine Brille, die die Kopfposition angibt, eine Hand und eine Bodenplatte, die die Füße repräsentiert, dar. Alle Positionierungen können einfach aus den Trackingdaten gewonnen werden, welche dem VR-Renderer in den jeweiligen Installationen durch die Position der 3D-Brille und der 3DMaus zur Verfügung stehen.

Abb. 5.28. Verschiedene Kopplungsarten: Links Tight/Master-Slave Coupling, rechts Loose Coupling

Abb. 5.29. Links: Ein Avatar in einer virtuellen, kollaborativen Sitzung. Rechts ein mit einem Marker versehenes Objekt

Diese Art der Darstellung hat den Vorteil, dass einerseits aus der Blickrichtung und der Gestik für die Partner schon sehr viel ableitbar ist und andererseits das Objekt, welches betrachtet wird, nicht zu sehr durch die A-

376


vatare verdeckt wird. Einzig in großen Modellen, wie sie beispielsweise in der Architektur vorkommen, ist es aufgrund der Größenverhältnisse oft schwierig, den Partner zu erkennen. Bei den üblichen Szenarien, die bei der Produktentwicklung auftreten, ist dies jedoch selten der Fall. Um Besonderheiten an dem Objekt hervorzuheben muss der Partner nur auf diese zeigen. Für die anderen Partner wird diese Geste über die Handbewegung des Avatars übermittelt. Auch können virtuelle Marker an dem Objekt befestigt werden, um besondere Regions-of-Interest zu kennzeichnen.

Abb. 5.30. Eine kollaborative Sitzung mit Videoconferencing

Kommuniziert wird nicht nur über Gestiken, sondern auch über Audiooder Videoconferencing. Wird ein Videoconferencingtool verwandt, ist es bei einer immersiven Umgebung wie einer CAVE wichtig, dass das Videofenster direkt eingeblendet wird. Daher ist das Videoconferencingtool „AccessGrid“ [5.1] in COVER eingebunden. Dieser kann in einem frei schwebenden Fenster den Videostream des jeweiligen Partners einblenden. Bei einfachen VR-Einrichtungen wie einer Powerwall ist es meist ausreichend, die Videofenster regulär neben der dreidimensionalen Darstellung anzuzeigen. Auf diese Art und Weise lässt sich mit den verschiedenen Projektpartnern kommunizieren, als wären sie physisch mit in der virtuellen Umgebung. Allerdings zeigten Tests mit verschiedenen Versuchspersonen, dass das Einblenden des Videofensters kaum Vorteile beim kooperativen Arbeiten bringt. Wichtiger ist hier eine möglichst störungsfreie und qualitativ hochwertige Audioverbindung. Auch hybride Prototypen lassen sich kooperativ auswerten [5.16]. Abb. 5.31 zeigt ein Szenario, in der eine Luftströmung in einer Innenstadtsituation visualisiert wird. Die Marker repräsentieren zum einen Objekte, welche sich auf dem Platz zwischen den Gebäuden befinden, zum anderen


377

bestimmen sie die Position virtueller Objekte wie Schnittflächen oder Partikelbahnen, welche die Ergebnisse der Simulation visualisieren. Das Ergebnis lässt sich auf dem Bildschirm oder in einer virtuellen Umgebung verfolgen. Sowohl hybride wie auch virtuelle Set-Ups lassen sich beliebig kombinieren. Jeder Partner kann über seine Marker oder durch Interaktoren in der virtuellen Umgebung mit der Visualisierung arbeiten. Auch das physische Manipulieren der Objekte kann ermöglicht werden, wie Untersuchungen von Brave et. al. [5.23] zeigen.

Abb. 5.31. Kollaborative hybride Prototypen

5.5.5 Zusammenfassung und Ausblick In diesem Abschnitt wurden einige Methoden gezeigt, um die Verwendung virtueller Prototypen sinnvoll im Rapid-Prototyping-Prozess zu erlauben. Dies ist sicherlich kein vollständiger Überblick über all die Verbesserungen, die für einen solchen wichtig und wünschenswert wären, gibt aber dennoch Anregungen, die derzeitigen Prozesse auf Flaschenhälse und Reibungsverluste hin zu untersuchen und zu überdenken.

378


Ein anderer Bereich, der ein möglicher Ansatzpunkt wäre, um den RPProzess zu verbessern und zu beschleunigen, wäre beispielsweise eine noch bessere Durchgängigkeit zwischen CAD – Gittererzeugung – Simulation und Visualisierung. Dies ist jedoch nur mit etablierten Standards möglich, nicht nur im Bereich der Dateiformate sondern auch in der Anbindung externer Programmmodule an die jeweiligen Applikationen, welche von jedem Hersteller verfolgt werden. Derzeit finden sich nur Insellösungen, die für eine beschränkte Anzahl an Programmpaketen funktionieren, aber keine umfassende Austauschbarkeit gewährleisten. Hybride Prototypen bergen viele im Entwicklungsalltag noch ungenutzte Potenziale. Der Vergleich zwischen Simulation und Experiment wird sehr vereinfacht. Für die Entwickler eröffnen sich neue Interaktionsmöglichkeiten, welche sich wesentlich intuitiver und handhabbarer zeigen als das Eingeben neuer Zahlenkolonnen in Simulation und Post-Processing, ja sogar handhabbarer als die Interaktion in einer virtuellen Umgebung, wie an den vielen Beispielen der Tangible Interfaces ersichtlich ist. Jedoch kranken sie an verschiedenen Problemen, welche den weitverbreiteten Einsatz der Methode verhindern. So sind die meist verwandten HMD sehr schwer und unhandlich und eignen sich nicht für längeres Arbeiten mit dem Prototypen. Auch ist es immer noch nicht möglich, Objekte ohne Marker zu registrieren und in der erforderlichen Genauigkeit deren Position zu verfolgen. Die benötigten Marker jedoch sind meist unhandlich, dürfen nicht verdeckt werden und überdecken zudem selbst teilweise die Geometrie. Parallele Renderingverfahren eignen sich hervorragend, auch ohne verlustbehaftetes Post-Processing größere Datensätze zu betrachten. Derzeit sind die oben im Abschnitt angesprochenen Verfahren von Vorteil, da sie auf derzeitige Graphikhardware abgestimmt sind. In diesem Bereich haben sich jedoch in letzter Zeit interessante Entwicklungen ergeben, wie beispielsweise die Entwicklung eines Raytracers in Hardware. Der Vorteil eines Raytracers ist es, dass der Zeitaufwand beim Rendern komplexer Szenen nicht nahezu linear steigt wie bei derzeitigen, dreiecksbasierten Renderingverfahren. Diese sind zwar anfänglich wesentlich schneller als Raytracing, bei sehr komplexen Szenen mit vielen Objekten wird jedoch bald ein Break-Even-Point erreicht, ab dem sich Raytracingmethoden wesentlich performanter zeigen. Auch lassen sich natürliche Phänomene wie Kaustiken und Schatten mit diesen besser berechnen. Mit dem Aufbau eines vollvernetzten, kollaborativen Arbeitsplatzes können dem Entwickler neue Möglichkeiten an die Hand gegeben werden, Experten zu konsultieren, Ergebnisse zu diskutieren oder Ihre Arbeit zu präsentieren. Hier sind oft jedoch unzuverlässige Netze oder nicht intuitiv und umständlich bedienbare und einrichtbare Software ein Hinderungs-

5.6 Datenintegration des Entwurfsprozesses in die RPD-Prozesskette

379

grund, dieses Potenzial voll zu nutzen. Derzeit entstehende Infrastrukturen wie beispielsweise das Skype-Netzwerk, welches ohne jeglichen Administrationsaufwand selbst durch Firewalls und Router funktioniert, zeigen den richtigen Weg, der gegangen werden muss, um tatsächliche Telepräsenz Realität werden zu lassen.Die hier vorgestellten Verfahren spielen ihre Stärken nicht nur in der schnellen Produktentwicklung aus, sondern auch in anderen Bereichen. Parallele Renderingmethoden sind auch im Bereich des Marketing interessant, in dem hochqualitative Bilder in Echtzeit erzeugt werden sollen. Augmented Reality kann in der Produktion und der Wartung eingesetzt werden, um kontextspezifische Details einzublenden, beispielsweise ein Handbuch oder eine Handlungsanweisung. Weiterhin wäre denkbar, wichtige Daten direkt einzuspielen, wie beispielsweise Temperaturen, Geschwindigkeiten und anderes. Tangible Interfaces können beispielsweise in der Architektur angewandt werden, um Gebäude zu plazieren oder Innenräume zu planen oder auch in der Produktionsplanung, um ganze Produktionsstätten aufzubauen. Virtuelle Prototypen werden mit ihrer wachsenden Komplexität immer weiter die physikalischen Prototypen verdrängen und vollständig ersetzen. Um diese jedoch für schnelle Entwicklungszyklen benutzbar zu machen, sind neue Ansätze wie die vorgestellten nötig.

5.6 Daten- und informationstechnische Integration des Entwurfsprozesses in die RPD-Prozesskette

5.6.1 Ausgangssituation Der Entwurfsprozess in den frühen Phasen der Produktentwicklung umfasst die Entwicklungsschritte von der Idee über die Grundkonzeption und die Festlegung der Funktion des Produktes, über die Erarbeitung von Lösungsansätzen und deren Bewertung bis hin zur Produktdefinition. Die konventionelle Produktentwicklung trennt die Phasen der Produktkonzeption und der Produktausarbeitung – insbesondere in informationstechnischer Hinsicht. Die Produktausarbeitung wird dabei heute konsequent von CAx-Systemen, vorrangig von CAD-Systemen begleitet und unterstützt. Die Einbindung der frühen Entwurfsphasen in die Produktentwicklung im allgemeinen und in die RPD-Prozessketten im speziellen ist jedoch nicht methodisch ausgeprägt [5.132]. Die frühen Produktentwicklungsphasen sind von Designarbeit geprägt und beinhalten vor allem das Finden und Entwickeln von Konzepten für

380


das Produkt und seine Funktionalität (Produktgestaltung). Im Ergebnis liegen erste Entwürfe in Konzeptmodellen vor, die Varianten in Form und Funktion repräsentieren und deren Herstellung bisher fast nur per Handarbeit erfolgt. Grund hierfür ist das Fehlen von geeigneten Werkzeugen, mit denen Konzepte, die in Kreativarbeitsschritten entworfen wurden (Skizzen, Designmodelle aus Clay usw.), digital erfasst und weiterhin ohne detaillierende CAD-Modellierungsschritte rechnerintern zu geschlossenen Volumenbeschreibungen - meist als STL-Datensatz – für das Rapid Prototyping aufbereitet werden können [5.131]. Ziel der Projektarbeiten war es, mit der Einbindung der frühen Entwurfsphasen in die RPD-Prozesskette dem Designer zu ermöglichen Rapid Prototyping-Verfahren und weitere Werkzeuge aus den vielfältigen RPD-Verfahren, die auf seine Anforderungen abgestimmt sind, nutzen zu können. Hier sind die Herausforderungen zu sehen: Nur die durchgängig informationstechnische Absicherung des gesamten Produktgestaltungs- und Produktausarbeitungsprozesses ermöglicht die Umsetzung der gesamten Anforderungen an eine RPD-Prozesskette. Im Einzelnen betrifft das die frühzeitige Festlegung von Materialien und Fertigungsstrategien und von Konstruktionsmerkmalen zur Vermeidung inhomogener Konstruktionsergebnisse. Die zeitoptimierende Parallelisierung von Teilprozessen funktioniert nur mit einem konsequent durchgängigen und vollständigen Informationsaustausch in einer hybriden Modellwelt physischer und virtueller Prototypen, der eine reibungslose Kommunikation gestattet. Hier spielt das Maß der Rechnerintegration in den Prozessen eine maßgebliche Rolle, auch hier insbesondere basierend auf einer hybriden Modellstruktur [5.57]. Zur Umsetzung eines durchgängigen Informationskonzeptes im RPDProzess muss deshalb eine Angleichung der unterschiedlichen Modellkonzepte von Designern und Konstrukteuren betrieben werden. Das Konzeptmodell, Ergonomiemodell und das Designmodell des Designers muss zum Konzeptmodell des Konstrukteurs werden, das ohne Informationsverluste in den Geometrieprototypen und/oder Funktionsprototypen zum Ausarbeiten des CAD-Modells überführt werden kann. Gleichzeitig müssen neue rechnerinterne Modellstrukturen aufgebaut werden (z.B. virtuelle Skizzen, Feature-Modelle). Dabei muss dem Umstand Rechnung getragen werden, dass auch (im Sinne von CAD) unvollständige Designermodelle und beliebige Messpunktwolken von Objekten schnell und datensicher zu Volumenmodellen (Solids) für das Rapid Prototyping aufgebaut werden können [5.168]. Spezielle Anstrengungen gelten hier einer automatischen Bearbeitung, um die Schnelligkeit der Herstellung mittels Rapid Prototyping nicht einzuschränken. In der Concept Modelling-Anwendung, wo die entwicklungsnahe Umsetzung von noch nicht


381

Idee

Planung / Definition

Konzeption

Entwicklung / Ausarbeitung Entwurf/ Design

Konstruktion

Berechnung

Erprobung

nach VDI2221

ausgearbeiteten virtuellen Modellen in die physische Realität Vorrang vor einer hohen Modellgenauigkeit hat, ist das eine Grundvoraussetzung.

Konzeptmodell

nach VDID

Ergonomiemodell Designmodell Funktionsmodell Prototyp Muster Konzeptmodell

nach NCG

Geometrieprototyp Funktionsprototyp Technischer Prototyp

Abb. 5.32. Modellkonzepte von Designern und Konstrukteuren nach Gebhardt

5.6.2 Lösungsansätze Mit der Einbindung der frühen Entwurfsphasen in die RPD-Prozesskette soll der Designer die Möglichkeit erhalten, Rapid Prototyping-Verfahren und weitere Werkzeuge aus den vielfältigen RPD-Verfahren nutzen zu können, die auf konzeptionelles Arbeiten abgestimmt sind. Aus technischer Sicht wird damit die Überführung seiner (auch sehr frühen) Konzepte in Vor-CAD-Modelle unterstützt und über die Schaffung einer neuartigen Hybridkommunikationsplattform die Zusammenarbeit mit dem Konstrukteur verbessert [5.168]. Das umfasst die Möglichkeit, die noch unvollständig ausgeprägten Konzeptmodelle als Prototypen zu realisieren. Dabei werden Verfahrenskombinationen und/oder Multi Material Modelling-Verfahren eingesetzt, wobei aber zwingend eine geschlossene Volumenbeschreibung mit verfahrenssteuernder Segmentierung der Oberfläche erforderlich ist [5.95]. Die unterschiedlichen Modellebenen, die sich in handgefertigten Kreativ- und Konzeptmodellen und daraus abgeleiteten rapid-prototyping-fähigen Modellen ausprägen, werden dazu datentechnisch aufbereitet und verknüpft. Damit werden schrittweise geometrische Datenmodelle aufgebaut. Die Schritte können über das Aktive Semantische Netz abgesichert werden.

382


Das Vorgehen: Die informationstechnische Integration des Entwurfsprozesses eines Produktes in die RPD-Prozesskette beschreibt zunächst die digitale Modellierung klassischer und konventioneller Designmittel wie Skizze, Entwurfspläne oder handgefertigtes Formmodell. So werden die kreativen und meist in realen Modellen interpretierten Entwürfe des Produktes eingebunden. Dabei werden aus mit geeigneter Sensorik flächenhaft oder volumenhaft erfassten „unscharfen“ Produktdaten und, im Hinblick auf CAD-Modelle, unvollständigen Geometrieprototypen, mittels Rapid Prototyping physische Prototypen erzeugt, die zu Konzept-, Ergonomieund Designmodellen weiterentwickelt werden. Der Designer kann so einerseits das reale Modell frei kreativ gestalten, andererseits eröffnen ihm die aufgebauten virtuellen Modellstrukturen – die Geometrieprototypen Vor-CAD-Modell, Reverse Engineering Solid-Modell und Facettenmodell – zusätzliche Möglichkeiten des Verifizierens und der Präsentation seiner Entwürfe und Konzepte.

Abb. 5.33. Integration Konzeptions- und Entwurfsphase im RPD-Prozess

Durch die Fertigung mehrerer Prototypen, die allesamt den Basisentwurf widerspiegeln, bietet sich dem Designer außerdem die Möglichkeit der Ausarbeitung verschiedener Detailentwürfe, die vergleichbar und somit bewertbar sind.


383

Des Weiteren bieten spezifisch abgestimmte und insbesondere auch geeignet kombinierte Beschichtungsverfahren die Möglichkeit, Prototypen über dekorative Aspekte hinaus zusätzlich zu funktionalisieren. Die Randbedingungen: Die frühen Entwurfsphasen werden von intuitiven Arbeitsmethoden geprägt, die auf eine sowohl technische wie ästhetische Formfindung und -gestaltung zielen. Die hierbei erzeugten Konzeptmodelle basieren noch nicht, wie erwähnt, auf vollständigen, skalierten Produktdaten, sondern dienen dazu: x x x x x

technische Funktionen und Abläufe darzustellen, Formen, Raum, Farbe zu interpretieren, Variationen des Entwurfs aufzuzeigen, Proportionen zu klären und Beziehungen von Flächen und Formen gegeneinander zu stellen.

Lösungsschritte: Hieraus leitet sich die Kernfrage für mögliche Integrationsstrategien ab, die den iterativen Einsatz physischer wie virtueller Modelle unterschiedlicher Ausprägung (in hybriden Modellstrukturen) umfassen und somit einen Modellwechsel mit unterschiedlicher Informationstiefe ermöglichen sollen. Die informationstechnische Unterstützung bezieht sich auf die Prozesse Digitalisieren und Rekonstruieren geometrischer Elemente und Sachverhalte. Die Erweiterung aktueller Digitalisierstrategien muss dabei typische Anforderungen wie die Feature-Bearbeitung und die Einbindung unvollständiger und unscharfer Produktdaten berücksichtigen. Daraus ergeben sich neue, produktspezifische Anwendungen im Kontext von Design und Konstruktion. An die Digitalisiertechniken sind teilweise andere Anforderungen als im Fertigungs- und Qualitätssicherungsbereich zu stellen, da es nicht darauf ankommt, ein Modell in allen Einzelheiten maßstabsgetreu und mit hoher Genauigkeit zu erfassen. Insbesondere die Formkonzeption ist ein wesentlicher Entwurfsschritt, der einerseits frei kreativ ist, andererseits bereits einer Reihe unterschiedlicher Rahmenbedingungen (z.B. funktionale Vorgaben) unterliegt. Bislang existiert keine zuverlässige, klassifizierte Zuordnung von Formkonzepten und geometrischen Strukturen. Eine frühere Untersuchung von Anforderungen an die in dieser Frühphase der Produktentwicklung eingesetzten virtuellen Modelle ergab jedoch, dass als formgebende Merkmale Objektkonturen modelliert werden, die mit weiteren Querschnitts- oder Silhouette-Informationen zum Körpermodell weiterentwickelt werden [5.169]. Daher müssen festgelegte Merkmale wie Gestaltungslinien oder Lichtkanten sowie grobe Umrisse oder Texturen erfasst werden. Für die neue

384


Digitalisierstrategie wurde deshalb das Erfassen von Körperkonturen und Körperquerschnitten, die mit spezieller Beleuchtung des Körpers sichtbar gemacht werden, gewählt. Die zu digitalisierenden Merkmale sind also nicht notwendig flächenbezogen. Sie werden nicht durch beliebige Punktwolken auf der Oberfläche, die deren kartesische Koordinaten in einem definierten Objektkoordinatensystem darstellen, repräsentiert, sondern sind formlinienbezogen oder zielen auf das Erfassen einzelner Punkte. Hierzu muss ein optisches Messsystem eingesetzt werden, bei dem die geometrische und visuelle Information aus Grauwertbildern gewonnen werden kann und gleichzeitig Raumkoordinaten zur Verfügung stehen. Außerdem muss eine vollständige Wire Frame-Modellierung (3D-Former) auf der Basis von Feature-Linien als Grundlage einer Volumenbeschreibung festgelegt werden. Ein Wire Frame beschreibt hier ein geschlossenes, formdefinierendes Kantenmodell des Objektes. Zum Aufbau rapid-prototyping-fähiger Modellstrukturen aus erfassten Gestaltungslinien und -merkmalen wurden zwei Ansätze zur Extraktion formgebender Merkmale umgesetzt. Modellstruktur Feature-Linien Der erste Ansatz bezieht sich auf die Extraktion charakteristischer DesignLinien und Design-Elemente unter ganz bestimmten Beleuchtungsbedingungen - das sind Lichtkanten auf dem Objekt [5.154]. Das Vorgehen beruht auf einer optischen Auswertung der Kanteninformation in einer Kameraaufnahme. Da aber dreidimensionale Modelle aufgebaut werden müssen, ist es notwendig, zu der gefundenen Design-Linie (Lichtkante) die zugehörige 3D-Kante des Objektes zu extrahieren. Der zu verwendende Sensor für die Digitalisierung des Objektes muss deshalb zum einen ein Graustufenbild des Objektes liefern und zum anderen eine direkte Verknüpfung von (2D-)Bilddaten und 3D-Objektkoordinaten zulassen. Der resultierende Aufbau einer Digitalisierstation für den Designer muss weiterhin variable Modelldimensionen und die Extraktion weiterer visueller Information (Textur, Farbe) zulassen. Nach diesen Kriterien wurde für die Projektarbeiten der Kolibri-Sensor (Fraunhofer IOF) ausgewählt [5.135]. Bei diesem ist es möglich, dass die 3D-Koordinaten direkt durch die Pixelkoordinaten der Graustufenbilder indiziert werden. Zudem ist das Messsystem selbstkalibrierend, das heißt, dass Teilpunktwolken, die durch Auswertung von unterschiedlichen Kamerablickrichtungen errechnet werden, sich in einem gemeinsamen Koordinatensystem befinden. Dies ist für eine einfache, designgerechte Rundumerfassung von Objekten wichtig. Die Wahl des Sensors schränkt aber


385

das Ergebnis der Arbeiten nicht ein. Jeder optische Sensor, der diesen Anforderungen genügt, kann hier eingesetzt werden. Die implementierte Digitalisierstrategie eignet sich für das Erfassen von Modellen unterschiedlicher Ausprägung, Dimension und Materialien und ist gleichzeitig dem gewohnten Arbeitsumfeld des Designers angepasst [5.154], [5.167]. Ihrer Einführung ging eine Untersuchung über die Entstehung von Lichtkanten auf Designermodellen voraus. Die Idee geht auf Aussagen von Designern zurück, wonach Lichtkanten die Form eines Produktes in der menschlichen Wahrnehmung prägen. In einem ersten Arbeitsschritt mussten die subjektiven Beschreibungen einer „Lichtkante“ konkretisiert werden. Dabei wurde festgestellt, dass die Lichtkanten, die die Formleitlinien beschreiben, auf unterschiedlichen optischen Effekten beruhen. So werden gewisse Gestaltlinien durch Reflexionen auf einer wenig gekrümmten Oberfläche definiert, andere werden durch Hell-DunkelÜbergänge, die von (mehr oder weniger scharfen) Objektkanten herrühren, erzeugt. Dies wurde bei der Auswertung der im Bild sichtbaren Kanten berücksichtigt. Um die Lichtkanten in der gewünschten Art auf dem Objekt sichtbar zu machen, wurden Konzepte für eine günstige Positionierung der Beleuchtung entwickelt. Probleme im Messaufbau, die sich aus ungünstigen Beleuchtungsverhältnissen für die 3D-Erfassung ergaben (zum Beispiel durch die für ein kontrastreiches Hervortreten von Gestaltlinien notwendige flache Beleuchtung), wurden durch Anpassen der Messanordnung gelöst. Wo dies nicht möglich war, wurde eine Lösung durch die Aufnahme von zusätzlichen Bildern mit speziell eingestellten Lichtverhältnissen, die nicht für die 3D-Rekonstruktion genutzt wurden, gefunden. Die Untersuchungen wurden an unterschiedlichen, in der Designbranche für die Herstellung von Modellen verwendeten Materialien durchgeführt. So wurden sowohl Materialien getestet, die gewisse Glanzeigenschaften haben, wie zum Beispiel Clay, sowie im Reflexionsverhalten total gegensätzliche Materialien, wie zum Beispiel Hartschaum. Für die Extraktion und Auswertung der Design-Linien lagen folgende Daten vor: x (n * m) + h Bitmap-Bilder, aufgenommen von n Kamerapositionen mit jeweils m verschiedenen Beleuchtungssituationen und eventuell noch h zusätzliche Bilder, die nur der Darstellung von bestimmten Lichtkanten dienen x die Grauwerte der einzelnen Bildpunkte x die zu jedem Bildpunkt (2D) gehörigen kartesischen Koordinaten im Raum.

386


Abb. 5.34. Kantenextraktion mit wechselnder Beleuchtung (PROFORMDESIGN)

Um eine Feature-Linie in dem Bild zu erkennen, kann man sich nicht nur auf das Anwenden eines Kantenfilters beschränken, sondern muss die aufgenommene Szene geeignet analysieren. Dazu vorab eine kurze Beschreibung der Bildaufnahme mit dem eingesetzten Kolibri-Messsystem. Jede Kameraposition liefert Bilder mit variierenden Beleuchtungssituationen. Abhängig von der Beleuchtungsrichtung erscheinen in den Aufnahmen unterschiedliche Lichtkanten. Diese beschreiben das Objekt nicht als Ganzes, sondern nur einen Teil der gesuchten Gestaltungslinien. Deshalb werden Bilder aus unterschiedlichen Beleuchtungssituationen verwendet, um die in einer Kameraposition enthaltenen Linien zu vervollständigen. Die Bilder mit unterschiedlichen Beleuchtungssituationen werden noch für eine andere Aufgabe genutzt. In den einzelnen Bildern existieren auch Licht-Schatten-Grenzen, die auf Schattenwurf von Teilen des Objektes zurückgehen und für die Extraktion der Feature-Linie nicht in Betracht gezogen werden sollten. Der entwickelte Algorithmus muss also bestimmte Lichtkanten verbinden und andere eliminieren können. Dies wird unter anderem durch eine Parallelitätsbetrachtung unter Berücksichtigung des Abstandes der parallelen Kanten realisiert. Die einzelnen Schritte sind: 1. Wähle eine feste Kameraposition. 2. Für jedes Bild aus dieser Kameraposition: Suche mit einem Kantenoperator (z.B. Canny-Operator) Kanten in dem Bild. Extrahiere die Kanten (Feature-Linien) aus jedem Bild als 2D-Kontur. 3. Für alle 2D-Konturen aus den verschiedenen Beleuchtungssituationen: Betrachte den Abstand der „parallelen“ Konturen aus den unterschiedlichen Beleuchtungsbedingungen, um Schattenkanten zu eliminieren.


387

4. Die in dieser Art bereinigten Kontursegmente sind noch unterbrochen. Also: Suche die längste zusammenhängende Kontur, die die FeatureLinie in diesem Bereich beschreibt und wähle sie aus der Menge der 2D-Konturen aus. 5. Für alle zusammenhängenden 2D-Konturen: Suche jeweils die 3DKontur aus der Punktwolke. Mit diesem Vorgehen können alle beleuchteten Objektkanten, auch diejenigen, die einen Radiusverlauf haben oder nur eine schwache Krümmungsänderung zeigen, mit für die Aufgabenstellung ausreichender Genauigkeit gefunden werden. Modellstruktur Krümmungslinien Der zweite Ansatz basiert auf der Auswertung des Krümmungsverhaltens in einer 3D-Messpunktwolke und der Extraktion von Krümmungskanten [5.136]. Der Ansatz beruht auf der alleinigen Verwendung der Entfernungsbilder. Da hier eine dichte Messpunktwolke zugrunde gelegt werden muss, um relevante Ergebnisse zu erzielen und darüber hinaus nur Objektkanten gleicher Krümmung sicher extrahiert werden können, ist dieser Ansatz nur ergänzend zum Lichtkantenansatz zu sehen. Der Algorithmus wurde in einem anderen Projekt des Institutes entwickelt und stand zu Vergleichszwecken ebenfalls zur Verfügung.

Abb. 5.35. Bestimmung von Bereichen gleicher Krümmung (PROFORMDESIGN)

Wire Frame-Modellierer Für den Aufbau eines Geometrieprototypen in CAD-gerechten Modellstrukturen wurde ein Wire Frame-Modellierer (3D-Former) aufgebaut und implementiert [5.154]. Aus den aus einzelnen Kameraansichten extrahierten und als 3D-Kontur (Folge von Punkten) ausgegeben Feature-Linien

388


wird semi-automatisch, eine die Topologie des Objektes beschreibende, geschlossene Wire Frame-Darstellung generiert. Hierfür wurden verschiedene Funktionen implementiert, mit denen die aus den einzelnen Kameraansichten extrahierten 3D-Konturen, die nicht von einer topologischen Segmentierung des Objektes herrühren, vervollständigt und stetig geschlossen werden.

Abb. 5.36. Wire Frame-Modell einer Luftdüse

Die Punktsequenzen, die die Konturen beschreiben, werden zunächst in glatte Spline-Kurven konvertiert. Um eine komplette Beschreibung des Objektes zu erhalten, werden die Konturen aus verschiedenen Kameraansichten zusammengeführt. Wesentliche Bestandteile des 3D-Formers sind Funktionen zum Schließen von Lücken. Davon existieren Varianten, die entweder nur Informationen über die Kurven selbst oder auch die Punktwolke nutzen. Darüber hinaus besteht die Möglichkeit auszuwählen, ob Lücken automatisch oder manuell überbrückt werden sollen. Die automatische Methode ist insbesondere bei kleinen Unterbrechungen des Kurvenverlaufes angebracht. Solid-Modellierer Ziel war es zunächst, dem Designer Werkzeuge an die Hand zu geben, die ihm, nachdem er eine Reihe von Designentwürfen in virtuellen Modellen realisiert hat, deren Materialisierung über Rapid Prototyping ermöglichen. Er kann somit seine Gestaltungsideen und –prinzipien am realen 3DModell weiterentwickeln, ohne zuvor ein komplettes CAD-Modell generieren zu müssen. Dabei musste beachtet werden, dass das in diesem Entwicklungsschritt aus dem virtuellen Wire Frame-Modell abgeleitete Flächenmodell nicht


389

notwendigerweise ein komplettes Volumenmodell / Solid darstellt, wie es für Rapid Prototyping Voraussetzung ist. Untersucht wurden deshalb zunächst Strategien zum Schließen von Flächenmodellen auf der Basis kommerziell verfügbarer Software. Dabei wurde unter anderem auf eine Recherche des WTEC (World Technology Evaluation Center, Inc.) / JTEC (Japanese Technology Evaluation Center) zurückgegriffen, die die Voraussetzung für RP-Modelle über eine Gültigkeitserklärung der Eingangsmodelle beschreibt [5.121]. Die in der Recherche aufgelisteten Fehlermöglichkeiten in den geometrischen Modellen und die dazu aufgelisteten Reparaturschritte waren dann die Basis der Analyse kommerzieller Softwareprodukte. Hierbei zeigte sich, dass bei entsprechend plausibel aufgebauten Geometriemodellen die Fehler von entsprechend verfügbarer Rapid Prototyping-Software bereits weitestgehend automatisch behoben werden können. Die Anstrengungen mussten deshalb auf die Erzeugung plausibler Geometriemodelle gelegt werden. Hierzu wurde zunächst auch kommerziell verfügbare Software herangezogen, um die Flächen des virtuellen Designmodells zu Volumen zu erweitern. Beispielhaft wurde dazu die Software Magics 7.0 benutzt. Hier können über die Basisfunktionen: x x x x

Fläche verdicken Fläche spiegeln Kasten bauen und Boolsche Funktionen

bereits Volumenmodelle erstellt werden. Allerdings ergeben sich bei stark gekrümmten oder komplex verschnittenen Formen Abweichungen im Facettenmodell, die korrigiert werden müssen. In wenigen Fällen funktionierte das bereits mit der automatischen Korrektur, meist musste manuell nachgebessert werden. Zur Verbesserung der Situation, insbesondere zur Verminderung der Reparaturschritte, erscheint der direkte Aufbau von Volumenmodellen sinnvoller als die Verbesserung der in den kommerziellen Paketen implementierten Methoden zur Umwandlung von Flächenmodellen in Volumenmodelle. Hier muss ein volumenorientierter Ansatz zum Einsatz kommen. Bisherige Lösungen basieren auf der Erzeugung eines geschlossenen Flächenmodells (meist im STL-Format). Prinzipiell ist auch die Verwendung direkter Volumenmodelle, sogenannter Solids, möglich. Dieses Vorgehen wäre in den meisten Bereichen des Maschinenbaus von Vorteil, da die Konstruktionen aus regelgeometrischen Grundkörpern und deren Ver-

390


schneidungen bestehen, die analytisch als Solids beschreibbar sind. So sind zum Beispiel nur etwa 10% der Flächen einer Karosseriekonstruktion reine Freiformflächen und somit nicht einfach analytisch beschreibbar. Basis einer Solid-Beschreibung aus Punktwolken ist das Erkennen regelgeometrischer Grundkörper in den Punktwolken. Hierfür existieren bereits einzelne Softwarelösungen, die aber den Anforderungen noch nicht genügen. Solid-Extraktion Die Ziele der Arbeiten fokussierten deshalb auf das Erfassen und Modellieren von Solids zur direkten volumenorientierten Beschreibung von Produkten. Das Erfassen stützt sich dabei auf multisensorielle geometrische und visuelle Information. Für die Beschreibung wurden Verfahren zur semi-automatischen Extraktion und anschließend automatischen und hochgenauen Einpassung regelgeometrischer Objekte entwickelt. In einem ersten Schritt wurden zur Erfassung geeignete Sensoren eingesetzt. Zur Ableitung geometrischer und visueller Information wurden die Entfernungs- und Reflektivitätsbilder ausgewertet. Die Information wurde über eine 3D-Punktwolke strukturiert. Für die Auswertung der Digitalisierung wurden Verfahren aus der Bildverarbeitung genutzt. Im nächsten Schritt erfolgt die 3D-Segmentierung. Für die Segmentierung wurden die bereits entwickelten Verfahren zum Erfassen von Gestaltund Feature-Linien genutzt und neue, spezifische Verfahren entwickelt [5.168], [5.2]. Verfolgt wurde zunächst der Ansatz, Feature-Linien als die Berandung jenes Bereiches in der Punktwolke anzusehen, der ein regelgeometrisches Element interpretiert. Dazu wurden zuerst die im Projekt bereits vorhandenen Verfahren zur Extraktion von Feature-Linien untersucht. Das ergab, dass die Feature-Linien in der Form von Kurven weniger geeignet sind, jedoch können die Punkte der Punktwolke, durch welche die Linie / Kante verläuft, gut für einen Vorsegmentierungsschritt verwendet werden. Auf der anderen Seite wurde ein regionsbasierter Ansatz verfolgt. Dabei wurden in einem ersten Schritt auf der Basis der vorab entwickelten Krümmungsberechnung zur Feature-Linienextraktion Bereiche gleicher Krümmung in der Punktwolke segmentiert. In der Folge wurden weitere Verfahren zur Krümmungsberechnung implementiert, ebenso Verfahren, die auf der Basis triangulierter Punktwolken arbeiten. Dadurch erhält man jedoch noch keine Trennung in einzelne Punktwolken, die jeweils ein regelgeometrisches Objekt interpretieren. Die eigentliche Trennung in einzelne Punktwolken erfolgt durch ein Region Growing-Verfahren. So können schon mit diesem einfachen Verfahren der groben Trennung in


391

gekrümmte und ebene Bereiche Segmentierungen vorgenommen werden, deren Punktmengen einzelne Objekte interpretieren. Auf dieser Basis wurde eine Strategie für eine automatische Segmentierung entwickelt. Die Strategie beachtet, dass Bereiche starker Krümmungsänderung (die also Objekte mit scharfen Kanten interpretieren) aus der Punktwolke entfernt werden. Der feature-linienbasierte Ansatz wird zur Vorsegmentierung angewendet. Für eine weitere Segmentierung wurde die Punktwolke in 2 – 4 Klassen ähnlicher Krümmung eingeteilt. Hierfür finden Schwellwertverfahren Anwendung. Die entwickelten und implementierten Verfahren zur automatischen Schwellwertfindung basieren auf der Analyse der Histogramme über alle Krümmungswerte zu den einzelnen Messpunkten. Es werden jeweils Punkte mit ähnlicher Krümmung gesucht. Dabei wurden Histogramme mit Klasseneinteilung über eine Toleranzbreite untersucht und benutzt. Die einzelnen entwickelten Algorithmen zur Krümmungsberechnung und der Segmentierung und Abtrennung von Bereichen ähnlicher Krümmung (Punktwolkensegmentierung über Region Growing und Schwellwertbestimmung) wurden zu einem Verfahren zur automatischen Segmentierung von Messpunktwolken zusammengeführt. Das Region GrowingVerfahren wurde dahingehend erweitert, dass jetzt zusätzlich nur Punkte mit einem ähnlichen Krümmungswerte hinzugenommen werden. Ähnlich heißt hierbei, dass er in der selben Klasse von Krümmungswerten liegt. Damit konnte der Engpass verfügbarer kommerzieller SoftwareSysteme überwunden werden, die nur regelgeometrische Objekte einfacher Art erkennen und immer noch relativ viel Benutzerinteraktion erfordern.

Abb. 5.37. Segmentierung in regelgeometrische Bereiche – Prüfkörperbeispiel

Die folgende Objekterkennung (in Segmenten und im Gesamtraum) erfolgt auf der Basis von am IFF entwickelten Algorithmen zur automatischen Best Fit-Einpassung von regelgeometrischen Elementen.

392


Diese Best Fit-Algorithmen, die ein flexibles, effizientes und genaues Einpassen beliebiger Kurven und Flächen in eine 3D-Messpunktwolke ermöglichen, wurden ursprünglich für den Bereich der Messtechnik entwickelt und sind daher hochgenau. Die Algorithmen basieren auf der Methode der Least Squares-Approximation und minimieren die Summe der quadratischen orthogonalen Abstände der Punktdaten zu der zu identifizierenden Kurve oder Fläche. Die Algorithmen liefern auch für ungleichmäßig verteilte und verrauschte Messpunkte sehr gute Ergebnisse [5.4], [5.3].

Abb. 5.38. Best Fit-Algorithmus demonstriert am Beispiel der Luftdüse

Implementierung: Die Algorithmen wurden in der objektorientierten Entwicklungsumgebung OpenCAS.CADE implementiert und in GUGS, einem am IFF entwickelten Windows-Programm zur Punktwolkenverarbeitung und Visualisierung, integriert. Das erlaubt den Aufbau und die Nutzung iterativer Modellstrukturen (Entwurfsmodelle des Designers, abgeleitete virtuelle Modelle). Durch die Implementierung einer grafischen Benutzungsoberfläche wird die Durchführung von Versuchen mit unterschiedlichen Parametern zur Kanten- und Feature-Linienextraktion erleichtert. Gleichzeitig können Daten mit anderen CAx- oder Rapid PrototypingSystemen über die Standardschnittstellen (STEP, IGES, DXF, STL) oder über b-rep-Modelle ausgetauscht werden. Um die Daten anderen Anwendern, zum Beispiel im virtuellen Rapid Prototyping-Labor (Kap. 5.5) oder zum Kostenmanagement (Kap. 3.4) zur Verfügung zu stellen, wurden in GUGS auch Dialoge eingefügt, mit denen direkt auf das Aktive Semantische Netz zugegriffen werden kann. 5.6.3 Zusammenfassung Für die Realisierung der aus Sicht des Projektes innerhalb von Rapid Product Development (RPD)-Prozessketten aktiven fünf Hauptstrategien, die auf den Durchlauf vieler, schneller Entwicklungszyklen als aktives Prozesselement, auf das Einbeziehen eines frühen Ergebnis-Feedbacks, auf


393

eine Betonung früher Entwicklungsphasen, auf das Erarbeiten alternativer Produktkonzepte und auf die Vorverlegung des Zeitpunktes der Produktspezifikation gerichtet sind, spielt die daten- und informationstechnische Integration aller prozessrelevanten Technologien eine zentrale Rolle. So wie sich das Rapid Prototyping „vom Werkzeug für die schnelle Produktentwicklung zum Werkzeug für die schnelle Produktentstehung“ [5.57] entwickelt hat, verbindet der RPD-Prozess die physisch-reale Welt der Modelle und Prototypen im Produktentstehungsprozess mit der rechnerintern-virtuellen Welt und ihren Technologien. Im Ergebnis werden insbesondere deutlich mehr Entwicklungszyklen als in der konventionellen Produktentwicklung ermöglicht, was einerseits die schnelle Erarbeitung alternativer Konzepte für das Produkt mit sich bringt und andererseits Entscheidungen zur Produktauslegung und –spezifikation praktisch zu beliebigen Zeitpunkten ermöglicht. Das bedeutet auch ein früheres ErgebnisFeedback und führt, im Gegensatz zur konventionellen Produktentwicklung, zu einer Betonung der frühen, Kosten und Wertigkeit des Produktes bestimmenden Produktentwicklungsphasen. In der aufgebauten RPD-Prozesskette wurden die frühen Phasen der Produktentwicklung informationstechnisch integriert: x x x x x x

Aufbau Konzeptmodell (erweitertes GUGS-System) Rapid Prototyping-Datenaufbereitung (erweitertes GUGS-System) CAD-System (z.B. ProEngineer) Rapid Prototyping (z.B. Stereolithographie, Concept Modelling) Nachbearbeitung (PVD-Beschichten) Prüfen des Prototypen.

Voraussetzung hierbei war, dass die relevanten Informationsschichten in den Prozessschritten identifiziert wurden. Informationen werden an unterschiedlichen Stellen im Entwicklungsprozess in unterschiedlicher Dichte und Detailtreue erzeugt. Ihre Analyse zeigte schon in der oben genannten Prozesskette deren iterativen, aber auch stark anwendungsorientierten Charakter. Zum Beispiel wurde in einer Auflistung der Forderungen an CADSysteme gezeigt, dass eine reine Weitergabe von Facettenflächen (STLDaten) im dynamischen RPD-Prozess nicht ausreichend ist. In der Betrachtung der Entwurfs- und Konzeptionsphase gilt das insbesondere, da hier zunächst „unscharfe“ Prototypdaten (Geometrie, Ausprägung, Material, funktionale Eigenschaften usw.) bearbeitet werden. Das im Projekt wichtigste Ziel der Arbeiten war deshalb die Aufbereitung dieser „unscharfen“ Information für den durchgängigen Betrieb von RPDProzessketten in den Schritten:

394


x Daten- und informationstechnische Integration des Entwurfsprozesses x Multi Material Modelling für den iterativen Aufbau von konzeptionellen Prototypen x Metallisches Beschichten konzeptioneller Prototypen.

Abb. 5.39. Entstehung eines Vor-CAD-Flächenmodells am Beispiel eine Luftdüse

Die informationstechnische Einbindung der Prozessschritte in die RPDProzesskette wurde über das Aktive Semantische Netz realisiert.

5.7 Multi Material Modelling von Design- und Funktionsprototypen

395

Der daraus resultierende Ablauf bei der Entstehung eines Vor-CADFlächenmodells wird in Abb. 5.39 am Beispiel einer Luftdüse demonstriert. 5.6.4 Ausblick Die Verknüpfung unterschiedlicher Eigenschaften und Funktionalitäten in einem konzeptionellen Prototypen gelingt nur durch die Verwendung mehrerer unterschiedlicher Materialien. Das Multi Material Modelling erschließt hierbei Anwendungsgebiete, die momentan mit Rapid Prototyping nicht abgedeckt werden können. Der Einsatz mehrerer unterschiedlicher Verfahren in einer Kombination oder die Verwendung eines Verfahrens mit unterschiedlichen Materialien kann ein vielfältiges Spektrum an Funktionalitäten und Werkstoffkombinationen aufzeigen. Verfahren der metallischen Beschichtung von Prototypenwerkstoffen bieten die Möglichkeit, durch Ausnutzung der mechanischen, elektrischen und dekorativen Schichteigenschaften, Prototypen mit erweiterten Eigenschaftsprofilen auszustatten. Einen Schritt weiter geht die Verwendung von gradierten Materialien, die Prototypen mit kontinuierlich verlaufenden Eigenschaftsprofilen ermöglichen. Visionäres Ziel ist hierbei die Herstellung individualisierter und auf spezielle Anwendungen exakt zugeschnittener Produkte. Die RPD-Prozesskette muss dazu weiter zur Produktentstehungsprozesskette qualifiziert werden, was insbesondere die Weiterentwicklung des Rapid Prototyping zu einem Rapid Manufacturing-Verfahren beinhaltet. Die Einführung von Rapid Prototyping-Verfahren zur Herstellung von Endprodukten bietet dann neben der Möglichkeit, bestimmte Produkte mit effektiveren Verfahren zu produzieren, insbesondere die Möglichkeit, aufgrund immanenter gestalterischer Freiheiten optimierte Produkte zu erzeugen. Große Potenziale sind hier im optimalen Einsatz von Ressourcen im Verhältnis zur angestrebten Funktionalität zu finden. Die Produkte werden schon während des Entwicklungsprozesses auf festigkeits- als auch auf gewichts- und materialoptimierte Gestaltung gelenkt.

5.7 Multi Material Modelling von Design- und Funktionsprototypen Eine Vielzahl von neuen Verfahren und Technologien haben in den letzten Jahren Einzug in den Produktentwicklungsprozess gefunden und sich auch etabliert. Hierzu zählen insbesondere die generativen Fertigungsverfahren

396


mit deren Hilfe der Produktentwicklungsprozess abermals beschleunigt wurde. Ergänzt werden diese klassischen Rapid Prototyping-Verfahren zur Herstellung physischer Prototypen durch computergestützte Technologien, die es ermöglichen, virtuelle Entwurfsmodelle und Prototypen zu erstellen. Die Kombination von virtuellen und physischen Modellen kann als Abbild des späteren Serienproduktes Aufschluss über dessen Eigenschaften wie Gestalt, Merkmalsausprägungen und Funktion geben. Prototypen sind gleichzeitig wichtige Informationsträger der einzelnen Prozessschritte, wie auch der Prozesskette in ihrer Gesamtheit. Sie sind deshalb in allen Entwicklungsstadien in digitaler oder realer Repräsentation notwendig [5.174], [5.70]. 5.7.1 Multi Material Modelling für den iterativen Aufbau von konzeptionellen Prototypen Die frühen Produktentwicklungsphasen sind von klassischer Designarbeit geprägt und beinhalten vor allem das Finden und Entwickeln von Ideen und Konzepten für das Produkt und seine Funktionalität. Als Arbeitsergebnisse liegen erste Entwürfe vor, die meist zahlreiche Varianten in Form und Funktion repräsentieren. Mit der Einbindung dieser frühen Phasen der Produktentwicklung in die Rapid Product Development-Prozesskette erhält der Designer die Möglichkeit zur Nutzung der unterschiedlichen Rapid Prototyping-Verfahren nach seinen individuellen Ansprüchen. Die dazu notwendige digitale Modellierung der Konzepte und Entwürfe auf der Basis konventioneller Designarbeiten, wie Skizzen oder handgefertigten Formmodellen, muss in den Rapid Product Development-Prozess integriert werden. Es soll hierdurch ermöglicht werden aus „unscharfen“ Produktdaten und somit, im Hinblick auf CAD-Systeme, unvollständigen Entwurfsmodellen, mittels generativer Fertigungsverfahren physische Prototypen zu erzeugen, die als Designmodelle weiterentwickelt werden können. Damit wird dem Designer die Gestaltungsfreiheit am physischen Modell erhalten, während ihm die gleichzeitig aufgebauten virtuellen Modellstrukturen zusätzliche Möglichkeiten des Verifizierens und Präsentierens seiner Modelle bieten [5.166]. Insbesondere für den iterativen Aufbau von konzeptionellen Prototypen und Designmodellen in den frühen Produktentwicklungsphasen wäre die Generierung von Basismodellen mit manuell weitergestaltbarer Oberfläche ein hilfreiches Werkzeug für den Designer. Ein stabiles Form- oder Basismodell, umgeben von einer weicheren, mechanisch verformbaren Hülle könnte die Ausgangsbasis für unterschiedliche Detaillösungen liefern. Ein möglicher Ansatz hierzu ist das manuelle Aufbringen von Modelliermate-


397

rial auf mit kommerziellen Rapid Prototyping-Verfahren gefertigten Bauteilen die bereits das Grunddesign widerspiegeln. Je nach Umfang der gewünschten Weitergestaltung und des Volumens des Bauteiles besteht jedoch die Gefahr, dass das Grunddesign des Basismodelles verloren geht. Aus diesen Überlegungen heraus wurde am Universitätsinstitut IFF das Multi Material Modelling (MMM-)Verfahren entwickelt und prototypisch realisiert. Das MMM-Verfahren ist eine Weiterentwicklung des ebenfalls am IFF entstandenen Multiphase-Jet-Solidification Verfahrens und hat zum Ziel, Prototypen in einer Mehrwerkstoffbauweise generativ zu fertigen [5.96]. Die Versuchsanlage besteht hierzu aus zwei separat arbeitenden Extrudiervorrichtungen, die je nach Einsatzzweck unterschiedliche Werkstoffe extrudieren können. Die Extruder sind senkrecht über einer in 3-Achsen verfahrbaren Plattform angebracht, auf die das durch eine enge Düse extrudierte Material strangweise abgelegt wird (Abb. 5.40.). Über eine Computersteuerung wird die Verfahrbewegung der Achsen und somit der Bauplattform durchgeführt.

Abb. 5.40. Prototypisch realisiertes Multi Material Modelling System am IFF

398


Als Ausgangsmodell wird, wie bei den gängigen RP-Verfahren, ein CAD-Modell im STL-Datenformat verwendet. Da das STL-Format nur die Geometrie eines Objektes beschreibt, wurde es für den Einsatz im MMM um Informationen zum Werkstoff des Objektes bzw. von Bereichen des Objektes erweitert. Innerhalb eines am Institut entwickelten Steuerprogrammes wird die Geometrie des zu generierende Bauteiles in Schichten unterteilt und Steuerinformationen erzeugt. Die reinen Verfahrinformationen werden dabei um Technologieinformationen ergänzt, die innerhalb der Schichten den verschiedenen Werkstoffen eine Extrudiereinheit zuordnen. So ist es möglich innerhalb jeder Schicht zwei unterschiedliche Werkstoffe einzusetzen. Nach jeder erzeugten Schicht wird die Bauplattform um den Betrag einer Schichtdicke abgesenkt. Durch den Einsatz von thermoplastischen Kunststoffen, die in den Extrudiervorrichtungen bei teilweise sehr hohen Temperaturen plastifiziert werden, verbinden sich die übereinander liegenden Schichten sowie die Stränge einer Schicht untereinander dauerhaft [5.15]. Über Sensoren für den Massedruck und die Temperatur sowie einem Tachogenerator zur Drehzahlbestimmung der Extruderschnecke können über eine externe Regeleinheit die Prozessparameter überwacht und je nach zu verarbeitendem Material exakt eingestellt und nachgeführt werden. Für den o.g. Anwendungsfall, einem Designer mehrere identische Basismodelle für eine weitere kreative Ausarbeitung zur Verfügung zu stellen, wurde das MMM-Verfahren dazu eingesetzt, einen stabilen Grundkörper aus thermoplastischem Werkstoff zu erzeugen und diesen mit einer verformbaren Oberfläche aus Modellierclay zu versehen. Da das MMMVerfahren, wie bereits beschrieben, schichtweise arbeitet, müssen in jeder Schicht auch beide Werkstoffe zum Einsatz kommen. Innerhalb eines CAD-Systems wird hierzu das Basismodell entwickelt und mit einem umhüllenden Modell in der gewünschten Stärke des Modelliermaterials versehen. In der Anlagensteuerung werden anschließend die Schichtinformationen erzeugt und das Bauteil aufgebaut. Ein Designer oder ein Designerteam käme mit Hilfe dieses Verfahrens zu einem Werkzeug, das ihnen die Möglichkeit gibt in kurzer Zeit aus einer Grundidee verschiedene Gestaltungsvarianten zu erarbeiten und zu vergleichen.


399

5.7.2 Funktionalisierung von Prototypen durch das Multi Material Modelling Ein Ziel innerhalb des Rapid Product Development ist es, bereits frühzeitig alle relevanten Eigenschaften des späteren Endproduktes anhand verschiedener Prototypen und Modelle zu überprüfen. Funktionsprüfungen an einzelnen Prototypbauteilen sind inzwischen durch die Wahl eines geeigneten Fertigungsverfahrens meist ebenso realisierbar wie die einfache Bemusterung, die die ersten RP-Verfahren zum Ziel hatten [5.140], [5.97]. Ein weiterer Weg schnell und kostengünstig zu einem Prüfmuster zu gelangen, kann beispielsweise bei Funktionsuntersuchungen für die lediglich die Forderung besteht, einen Prototypen im Serienwerkstoff überprüfen zu müssen, der Weg über das Rapid Tooling beschritten werden, bei dem man über nachfolgende Prozesse von einem generativ gefertigten Bauteil, etwa durch Abformen und Gießen, zu einem seriennahen Funktionsprototypen gelangen kann [5.58], [5.96]. Jedoch sind nicht alle Eigenschaften eines Produktes anhand eines Prototyps ohne weiteres vorauszusagen oder zu überprüfen. Funktionen von Bauteilen und Baugruppen, die als Endprodukt aus mehreren Werkstoffen mit unterschiedlichen Eigenschaften bestehen, müssen im Prototypstadium anhand virtueller Modelle simuliert oder, wenn möglich, durch Montage verschiedener Einzelteile gefertigt werden. Ist dies nicht möglich bleibt bisher nur der Einsatz mehrerer unterschiedlicher Prototypen oder aber eine Funktionalisierung durch weitere Bearbeitungsschritte, die sich sowohl auf die Kosten als auch auf die Zeit negativ auswirken. In solchen Fällen hätte ein Prototypverfahren, das Bauteile aus mehreren unterschiedlichen Werkstoffen direkt fertigen kann, erhebliche Vorteile [5.165]. Bisherige Ansätze bei der Verarbeitung mehrerer unterschiedlicher Werkstoffe innerhalb eines generativen Fertigungsprozesses beschränkten sich auf die Verwendung von unterschiedlichen Materialien für den Prototypen an sich und die umgebende Supportstruktur zur Abstützung. Hierdurch wurde es bei einigen Verfahren ermöglicht, das eigentliche Bauteil vom stützenden Supportmaterial einfacher als bisher zu lösen. Beispielsweise durch die Verwendung wasserlöslicher Werkstoffe für die Stützstrukturen entfällt das teilweise zeitaufwendige mechanische Nacharbeiten der Bauteile. Die Gefahr ein filigranes Bauteil hierbei zu beschädigen wird ebenfalls deutlich reduziert. Der Einsatz verschiedener Werkstoffe zur Realisierung bestimmter funktionaler oder auch ästhetischer Eigenschaften birgt jedoch noch Potenzial in der generativen Fertigung. Ein Ansatz hierzu ist wiederum das am IFF entwickelte Multi Material Modelling Verfahren. Dieses Verfahren bietet die Möglichkeit, mehrere Werkstoffe innerhalb eines Bauteiles zu

400


kombinieren und hierdurch Eigenschaften abzubilden, die sonst nur mit erhöhtem Aufwand überprüft werden können. Realisierbar sind sowohl Werkstoffkombinationen, die eine haftende Verbindung eingehen, wie auch Kombinationen, die nur temporär während des Fertigungsprozesses aneinander haften und sich nach Fertigstellung des Bauteiles mechanisch oder thermisch voneinander lösen lassen. Das Einsatzgebiet hierbei ist vielfältig: x Kombination von hartem und weichem Werkstoff (direktes Einbringen von Dichtungen, weiterbearbeitbare Grundmodelle (s.o.)) x Kombination nicht haftender Werkstoffe (Bewegliche Baugruppen) x Kombination haftender Werkstoffe (Ästhetische oder haptische Eigenschaften, Werkstoffe für partielle metallische Beschichtung ohne Maskierung) Gerade die Einsatzmöglichkeit des Verfahrens für eine partielle metallische Beschichtung von generativ gefertigten Bauteilen ohne vorherige Maskierung birgt großes Potenzial [5.130]. Ermöglicht wird dies durch den Einsatz von Werkstoffen die eine metallische Beschichtung ermöglichen bzw. diese gezielt verhindern. Eine schnelle und kostengünstige Fertigung von Bauteilen mit beispielsweise elektrisch leitfähigen und isolierenden Bereichen ist somit möglich. Doch auch weitere funktionelle oder ästhetische Eigenschaften von Bauteilen, die über eine metallische Beschichtung erzeugt werden, könnten einfacher und vor allem schneller prüfbar gemacht werden und somit den Rapid Product Development Prozess unterstützen. 5.7.3 Zusammenfassung und Ausblick Die Entwicklung des Multi Material Modelling Verfahrens war nur ein kleiner Baustein innerhalb der Laufzeit des Projektes. Die Idee hierzu wurde geboren als die etablierten Rapid Prototyping Verfahren, die in allererster Linie für eine Bemusterung von Bauteilen entwickelt wurden, sich immer mehr in die Richtung der Fertigung von seriennahen, voll einsetzbaren Prototypen bewegten. Es wurde schnell klar, dass sich durch die Spezialisierung der Verfahren auf einige wenige Werkstoffe eine Lücke auftat. Anwendungsgebiete wurden gesucht und das Verfahren prototypisch realisiert. Mit der realisierten Versuchsanlage ist es möglich, mit zwei unterschiedlichen Werkstoffen ein Bauteil generativ zu fertigen. Prinzipiell besteht für das Multi Material Modelling jedoch keine Beschränkung in der Anzahl der gleichzeitig zu verarbeitenden Werkstoffe. Ebenso könnte

5.8 Oberflächenveredelung von RP-Bauteilen

401

durch eine Zusammenführung von plastifiziertem Material vor der Ausbringung aus einer Düse eine gezielte Durchmischung in veränderlichen Volumenanteilen erreicht und somit weitere Anwendungsgebiete erschlossen werden. Im Gegensatz zum relativ einfachen mechanischen Aufbau des Systems ist die informationstechnische Umsetzung schwieriger zu realisieren. Das in den meisten Rapid Prototyping Verfahren angewendete STLDatenformat hat den entscheidenden Nachteil, dass ausschließlich Geometrieinformatinen zur Verfügung gestellt werden. Die Möglichkeit innerhalb moderner 3D-CAD-Systeme Bauteilbereiche zu selektieren und diesen bestimmte Eigenschaften zuzuordnen besteht bereits. Eine Zuordnung und informationstechnische Weiterverarbeitung von Werkstoffinformationen für diese Bereiche ist jedoch nicht vorgesehen. Eine Ausgabe der CAD-Daten in der Form eines erweiterten STL-Datenformates ist jedoch die Grundvoraussetzung für eine durchgängige Prozesskette in der Verfahren wie das Multi Material Modelling zum Einsatz kommen sollen.


5.8.1 Ausgangssituation Zu Beginn der Entwicklung und Produktion von RP-Teilen hat sich die Forschung und Industrie stark auf die Fertigung von Design- und Anschauungsmodellen konzentriert. Dazu parallel hat sich das Einsatzgebiet von generativ gefertigten Bauteilen immer stärker erweitert. Mit der fortschreitenden Entwicklung neuer Materialien und Verfahren zur Produktion von RP-Teilen (Kap. 5.7 und 5.9) rücken ganz neue Einsatzgebiete für generativ gefertigte Bauteile in den Fokus der Forschung und der Industrie. Durch die Weiterentwicklung der Printtechnologie zur Fertigung von RP-Bauteilen ist es heute möglich, neben Duroplasten und Epoxidharzen auch Elastomere zu verbauen. So kann bspw. ein Dichtelement aus einem Elastomer direkt aus CAD-Daten erzeugt werden, ohne zuerst eine Form fertigen zu müssen. Lasergesinterte Polyamid-Kunststoffe können bereits heute so verbaut werden, dass diese später als funktionelle Aktoren einsetzbar sind. Es ist heute möglich, gesinterte Stahl- oder Bronzebauteile direkt als Funktions- und Testbauteile einzusetzen. So werden bereits Kunststoffspritzgussformen zur Produktion von Kleinserien aus Stahlpulver gesintert und danach direkt als Werkzeug eingesetzt [5.112].

402


Blechumformwerkzeuge werden durch RP-Technologien angefertigt. Mit diesen Werkzeugen können anschließend Bleche in kleinen Serien umgeformt werden [5.75]. Durch dieses mittlerweile stark angewachsene Einsatzspektrum von RP-Bauteilen werden auch immer neue Anforderungen an generativ gefertigte Bauteile gestellt, die oft durch Verfahren aus der Oberflächentechnologie gelöst werden können. Dabei muss zuerst einmal klar sein, welche Anforderungen an ein RP-Bauteil gestellt werden. 5.8.2 Anforderungen an Oberflächen Diese Anforderungen werden im Allgemeinen in funktionelle und in dekorative Anforderungen unterteilt. Dabei sind: Funktionelle Anforderungen x x x x x x x x

Korrosionsbeständigkeit Verschleißbeständigkeit Gleiteigenschaften Rauheit Härte Festigkeit Dichte Leitfähigkeit

Dekorative Anforderungen x x x x x

Farbe Glanz Deckvermögen Rauheit Einebnung

Oft werden an ein Bauteil kombinierte Anforderungen gestellt wie bspw. „Korrosionsschutz und Glanz“ oder „Verschleißbeständigkeit und Leitfähigkeit“. Die daraus resultierenden verschiedenartigen Anforderungsprofile verlangen häufig eine Kombination von verschiedenen Verfahren aus der Oberflächentechnik [5.170].


403

5.8.3 Verfahren zur Veränderung der Eigenschaften von Oberflächen Die Oberflächentechnologie umfasst Verfahren der Oberflächenbehandlung und Verfahren der Oberflächenbeschichtung. Bei den Arbeiten im Rahmen des SFBs wurden Verfahren der Oberflächenbehandlung und der Oberflächenbeschichtung erforscht. In der Regel werden auch Verfahren kombiniert, um die geforderten Eigenschaften (Eigenschaftsprofile) zu erreichen. So gehen der Beschichtung von RP-Bauteilen in der Regel ein angepasstes Reinigungsverfahren und/oder ein Verfahren zur gezielten Veränderung der Oberflächeneigenschaften voraus.

Abb. 5.41. Verfahren der Oberflächentechnik

404


5.8.4 Lösungsansätze zur Funktionalisierung von RP-Bauteilen Im Rahmen des Sfb 374 wurden Verfahren zur Oberflächenreinigung, Oberflächenveränderung und Verfahren zur Erzeugung von metallischen Schichten sowie keramischen Schichtsystemen auf RP-Bauteilen untersucht. Diese Verfahren können schematisch in drei Grundverfahren eingeteilt werden (s. Abb. 5.42.). Neben den Verfahren der Beschichtung von RP-Bauteilen wurden auch Verfahren zur Vorbehandlung und zur gezielten Eigenschaftsveränderung der Oberflächen untersucht.

Abb. 5.42. Einteilung und Kombination von Beschichtungsverfahren

Oberflächenvorbehandlung Viele RP-Bauteile werden heute aus Kunststoffen gefertigt. Aufgrund ihres günstigen Verhältnisses von Festigkeit zu Dichte und ihrer kostengünstigen Verarbeitbarkeit haben Kunststoffe Metalle in vielen Anwendungsbereichen verdrängt. Den genannten Vorteilen stehen aber auch gewisse Nachteile gegenüber. Dies gilt insbesondere für die Oberflächeneigenschaften einiger Kunststoffsorten. So genügen Kunststoffe oft nicht den dekorativen Anforderungen oder sind einem Verschleiß durch Reibung und Gebrauch nicht dauerhaft gewachsen. Diese Nachteile können durch eine metallische Beschichtung der RP-Bauteile ausgeglichen werden. Der Haftungsverbund zwischen metallischer Beschichtung und Kunststoffsubstrat ist bei unbehandelten Bauteilen aber oft ungenügend. Dies liegt an den unterschiedlichen thermischen Ausdehnungskoeffizien-


405

ten von Metall und Kunststoff, an den anhaftenden Verunreinigungen auf der Bauteiloberfläche und der stark unterschiedlichen Oberflächenenergie von Metall und Kunststoff. Kunststoffe haben in der Regel eine niedrige spezifische Oberflächenenergie [5.20]. Dies verhindert eine Benetzung der abgeschiedenen Metallschicht bei der Bedampfung mit Metall und vermindert die Grenzflächenhaftung zwischen dem Kunststoffsubstrat und der metallischen Beschichtung. Um eine ausreichende Haftung zwischen dem Substrat und der Schicht zu erreichen, eignete sich nach den am IFF ermittelten Untersuchungen vor allem eine Verfahrenskombination [5.111], [5.109] aus: x Reinigung der Kunststoffsubstrate von Verunreinigungen x Erhöhung der Oberflächenenergie der Substrate Eine erste Reinigung findet in der Regel nasschemisch in einem Ultraschallbad statt. Hier wurden verschiedene wässrige und nichtwässrige Reiniger untersucht. Es hat sich gezeigt, dass die Schichthaftung in erster Linie durch das Anhaften von Ölen und Fetten vermindert wird. Aus diesem Grund ist eine nasschemische Reinigung besonders zur Entfernung dieser Verschmutzungen geeignet. Es hat sich in den Untersuchungen gezeigt, dass die Art des Reinigers keinen großen Einfluss auf das Reinigungsergebnis hat. Wichtig ist nur, dass eine Reinigung zur Entfernung der anhaftenden Verunreinigungen stattfindet [5.164]. In einem zweiten Prozessschritt findet in einem Niederdruckplasma eine Feinstreinigung und Oberflächenmodifizierung statt. Dabei kommen Prozessgase wie Argon, Sauerstoff, Stickstoff, Wasserstoff, Luft und Ammoniak zur Anwendung. Die Gase werden durch elektrische Entladungen im Kilo-, Mega- oder Gigaherzbereich angeregt. Steht dabei eine Ätzwirkung des verwendeten Gases im Vordergrund, wird mit sehr reaktiven Gasen wie CF4 oder SF6 gearbeitet. Der Prozessdruck bewegt sich in einem Bereich zwischen 1*10-3mBar und 5 mBar. Die Behandlungsdauer beträgt in der Regel nur wenige Sekunden bis einige Minuten. Die im Plasma gebildeten energiereichen Spezies des Prozessgases sowie die Vakuum-UVStrahlung führen zu unterschiedlichen Reaktionen mit dem RP-Bauteil. Die Teilchenenergie von Ionen kann in einem Radiofrequenz-Plasma einige 10eV betragen. Damit liegt die Energie höher als die Bindungsenergie vieler organischer Verbindungen. Durch das Aufbrechen von Bindungen des Polymers an der Oberfläche der Kunststoff-RP-Bauteile können Polymerradikale entstehen. Diese können ihrerseits wieder neue Bindungen eingehen. Reaktive Teilchen der Prozessgase können mit dem Polymer reagieren und funktionelle Gruppen bilden, beispielsweise Carbonyle, Carboxyle oder Hydroxyle. Diese Gruppen haben einen stark polaren Charak-

406


ter und führen zu einer deutlichen Erhöhung der Oberflächenenergie. Um die gewünschten Effekte an der Oberfläche zu erzielen, müssen die Parameter Gasart, Prozessdruck, Ätzzeit und Anregungsfrequenz an das vorzubehandelnde RP-Bauteil angepasst sein [5.107]. Am IFF haben dazu mehrere Untersuchungsreihen mit variierenden Kunststoffarten, Schichtmaterialien, Prozessgasen und Anregungsfrequenzen stattgefunden. Dabei hat sich gezeigt, dass sich die Schichthaftung von bspw. [SiOx] von 5,8 N/mm² auf 12,0 N/mm² durch die Vorbehandlung in einem angeregten Plasma steigern lässt [5.110]. Beschichtung aus der Gas- oder Dampfphase Zur Beschichtung von RP-Bauteilen aus der Gas- oder Dampfphase stehen eine ganze Reihe von verschiedenen Prozessen und Anlagentypen zur Verfügung. Generell kann aber zwischen x Chemical-Vapour-Deposition (CVD) und x Physical-Vapour-Deposition (PVD) unterschieden werden. Während bei einem CVD-Prozess die Schicht durch eine chemische Reaktion an der Oberfläche mit dem zu beschichtenden Bauteil entsteht, wird beim PVD-Prozess das Schichtmaterial physikalisch in die Dampfphase überführt und schlägt sich durch Kondensation am zu beschichtenden Bauteil nieder. CVD-Prozesse benötigen oft hohe Temperaturen und/oder eine andere Art der Energieeinkopplung wie bspw. Mikrowellen- oder UV-Strahlung um eine Schicht auf dem Bauteil abzuscheiden. Bei den Arbeiten im Rahmen des Sfb 374 hat eine Konzentration auf PVD-Verfahren stattgefunden. Die PVD-Verfahren können in drei Grundverfahren unterteilt werden: Aufdampfen, Kathodenzerstäuben (Sputtern) und Ionenplattieren. Beim Aufdampfen und Sputtern wird die Schicht durch überwiegend elektrisch neutrale Teilchen aufgebaut, die verfahrensbedingt unterschiedliche Energien haben. Beim Aufdampfen beträgt diese 0,1 bis 0,5eV beim Kathodenzerstäuben 1 bis 40eV. Beim Ionenplattieren handelt es sich dagegen um das Abscheiden geladener Teilchen, die während der Transportphase durch eine an das Bauteil angelegte Spannung (Biasspannung) in ihrer Geschwindigkeit gezielt beeinflusst werden können. Aufgrund der deutlich höheren Teilchenenergien werden Keimbildung, Verankerung und Schichtwachstum begünstigt, so dass haftfeste, kompakte Schichten entstehen [5.89]. Das Ionenplattieren wiederum kann in eine ganze Vielzahl von verschiedene Verfahren und Verfahrenskombi-


407

nationen unterteilt werden. Im Rahmen des Sfb kamen aber vorwiegend die Verfahren x Anodisches Lichtbogenverdampfen (PLASCO®-Verfahren), x Lichtbogengestütztes Aufdampfen (VALICO®-Verfahren) und das x Kathodisches Lichtbogenverdampfen (Arc-PVD) zum Einsatz Beim anodischen Lichtbogenverdampfen wird das Schichtmaterial durch auftreffende Elektronen stark erhitzt und verdampft. Die dabei entstehende Metalldampfwolke wird durch weiterhin auftreffende Elektronen anschließend partiell ionisiert. Der Ionisationsanteil des Beschichtungsmaterials kann zwischen 1-30% betragen. Beim lichtbogengestützten Aufdampfen wird das Beschichtungsmaterial durch die Zufuhr von thermischer Energie verdampft und anschließend in einem Plasma nachionisiert. Der Ionisationsanteil des Beschichtungsmaterials ist mit den Werten des anodischen Lichtbogenverdampfens vergleichbar. Beim Arc-PVD-Verfahren verdampft und ionisiert ein thermischer Lichtbogen das als Kathode geschaltete Beschichtungsmaterial. Der dabei entstehende Metalldampf weist einen Ionisationsanteil zwischen 50% und 100% auf.

Abb. 5.43. Reflektorbauteile mit unterschiedlichen Metallschichten

Durch den ionisierten Anteil des Metalldampfes ist es möglich, einzelne Metallatome gezielt auf das zu beschichtende Bauteil hin zu beschleunigen. Diese Verfahren ermöglichen die Abscheidung dünner metallischer

408


Schichten von wenigen Nanometern bis zu einigen Mikrometern Dicke. Diese Schichten weisen eine gute Haftung mit dem darunter liegenden Grundmaterial auf. Die PVD-Prozesse eignen sich aber nicht, um Schichten dicker als 5µm abzuscheiden, da die Prozesszeiten enorm lang werden. Außerdem werden große Mengen von Wärme in das Bauteil eingetragen, da der Metalldampf an der Oberfläche kondensiert und die Kondensationswärme zum überwiegenden Teil vom Bauteil aufgenommen wird. Galvanische Beschichtung von RP-Bauteilen Galvanische Beschichtungsverfahren sind weit verbreitet und ermöglichen eine kostengünstige und qualitativ hochwertige Oberflächenveredelung. Es stehen eine Vielzahl von Verfahren und Schichtsystemen zur Verfügung, durch die sich die mechanischen, korrosiven und dekorativen Eigenschaften von Bauteilen verbessern lassen. Galvanische Verfahren benötigen aber generell einen elektrisch leitfähigen Untergrund, um an der Oberfläche der Bauteile freie Ladungen zur Abscheidung von Metallionen zur Verfügung zu stellen. So ist es bspw. möglich, gesinterte Bronzebauteile mit einer dekorativen Nickelschicht zu versehen. Das Nickelschichtsystem ebnet die Rauheit des Sinterpulvers ein und erzeugt bei ausreichender Schichtdicke eine hochglänzende Oberfläche. Aus Stahlpulver gesinterte RP-Bauteile können mit einer korrosionshemmenden Chromschicht versehen werden. Durch den Auftrag einer Hartchromschicht lässt sich der Widerstand gegen abrasiven Verschleiß von Metallsinterbauteilen stark erhöhen und eine Verwendung im Alltagsgebrauch kann möglich werden. Galvanische Schichten können im Bereich von einigen Mikrometern bis wenigen Millimetern abgeschieden werden. Dem Vorteil der enormen Vielzahl von abscheidbaren Metallen steht der Nachteil entgegen, dass die galvanischen Verfahren nur auf elektrisch leitfähigen Bauteilen möglich sind. Dieses Verfahren eignet sich, um metallische RP-Bauteile zu beschichten. Chemische Beschichtung / außenstromlose Metallabscheidung Eine Möglichkeit, auch nichtleitende RP-Bauteile in einem nasschemischen Prozess zu metallisieren stellt die chemische Abscheidung von Nickel oder Kupfer dar. Bei diesem Verfahren handelt es sich um ein nasschemisches Verfahren ohne eine äußere Stromquelle [5.149]. Das zu beschichtende RP-Bauteil wird mit Palladium bekeimt. An dieser Palladiumbekeimung kann eine Anoden/Kathodenreaktion stattfinden. Es findet am Palladiumkeim eine Oxidation von [H2PO2] und [H2O] zu [3H+]; [HPO3]2


409

und [2e-] statt. Mit den bei dieser Reaktion frei werdenden Elektronen können im Elektrolyt gelöste Metallionen zu einer metallischen Schicht reduziert werden (Reduktionsreaktion [Men+] und [ne-] zu [Me0]). Die Ecken und Kanten des Untergrunds werden exakt nachgebildet. Hinterschneidungen und Sacklochbohrungen sind bei diesem Verfahren auch gleichmäßig beschichtbar. Außenstromlose Verfahren eignen sich in der Regel nicht, um dicke Schichten aufzutragen, da die Bäder nur 8µm bis 12µm Schicht in der Stunde bilden. Da die Bäder auch oft bei erhöhten Temperaturen arbeiten (Nickel ca. 80°C) ist die Beschichtung von Kunststoffbauteilen in diesen Bädern problematisch. Auch Unebenheiten können mit außenstromlosen Verfahren nur bedingt eingeebnet werden. Im Lauf des Sfb wurden Verfahren zur außenstromlosen Beschichtung von Kunststoffen zur selektiven Schichtabscheidung entwickelt. Durch diese Verfahren wird es möglich, dreidimensionale RP-Bauteile mit Leiterbahnen zu versehen [5.101]. 5.8.6 Verfahrenskombinationen PVD-Beschichtung kombiniert mit galvanischen Verfahren Besonders bei der Beschichtung von RP-Bauteilen ist eine nasschemische Beschichtung der Kunststoffe schwierig und fehleranfällig. Chemischaußenstromlose Prozesse benötigen zuerst umfangreiche Voruntersuchungen, welche für jeden einzelnen Kunststofftyp durchgeführt werden müssen. Bei sehr kleinen Stückzahlen ist eine vorausgehende Testreihe meist zu teuer oder nicht möglich. Da RP-Bauteile in der Regel nur in sehr kleinen Stückzahlen vorliegen, musste eine andere Möglichkeit gefunden werden, um eine leitfähige Startmetallschicht auf das Kunststoffbauteil aufzubringen. Durch die Kombination einer dünnen, durch PVD-Technik aufgebrachten Startmetallschicht und einer anschließenden galvanischen Nachverstärkung kann auch ein nichtleitender RP-Kunststoff mit einer dicken metallischen Schicht versehen werden. Diese Technologie wurde im Rahmen der Forschungsprojekte „Erforschung der Verfahrenskombination zur Erzeugung elektromagnetisch schirmender Schichten“ und „Metallisierung faserverstärkter Kunststoffe mittels kombinierter galvanischer / physikalischer Beschichtungsverfahren“ entwickelt. Dazu eignen sich die im Haus erforschten und weiterentwickelten PVDProzesse. Durch angepasste Vorbehandlungs- und Beschichtungstechnologien wird es möglich, eine dünne, haftfeste Startmetallschicht auf Kunststoffbauteile abzuscheiden. Diese Prozesse eignen sich gut für kleine

410


Stückzahlen und erlauben eine schnelle Beschichtung und Fertiggalvanisierung von RP-Bauteilen. Hier wurden besonders die Verfahren des anodischen Lichtbogens und der Arc-Verdampfung untersucht. Besondere Erfolge zur Steigerung der Haftfestigkeit von Metall auf Kunststoff konnte durch die Nachrüstung der Arc-PVD-Anlage mit einem Mikrowellengenerator erzielt werden. Die Feinstreinigung, Oberflächenmodifikation und Beschichtung findet jetzt in einem Prozess ohne Unterbrechung statt. Die Biasspannung konnte gesenkt werden und das Aufbringen dickerer Schichten wurde dadurch ermöglicht.

Abb. 5.44. RP-Bauteile beschichtet durch Kombinationsverfahren zur Erzeugung angepasster Oberflächen.

Außenstromlose Beschichtung mit anschließender galvanischer Nachverstärkung Diese Prozesskombination ist besonders für hinterschnittene und / oder komplex geformte Bauteile interessant. Da sich eine Startmetallschicht unabhängig von elektrischer Feldverteilung abscheiden lässt. Auch bei immer wiederkehrender Beschichtung von RP-Bauteilen aus dem gleichen Kunststoff stellt dieses Verfahren eine interessante Variante dar, da es bei festgelegten, prozesssicheren Parametern mit geringerem Aufwand zu betreiben ist als eine PVD-Startmetallisierung. Da das Schichtmetall und der darunter liegende Kunststoff unterschiedliche Ausdehnungskoeffizienten haben, kam es zu Beginn der Untersuchungen immer wieder zu Schichtablösungen, sobald das RP-Bauteil wie-


411

der auf Raumtemperatur abgekühlt wurde. Wichtig war hier besonders eine Entwicklung zu niederen Badtemperaturen bis auf ca. 30°C. Erst durch diesen Schritt konnten haftfeste Grundmetallschichten auf Kunststoff RPBauteilen erzeugt werden. Das anschließende Nachgalvanisieren erfolgt in Hochglanz-Nickelbädern. Aus Korrosionsschutzgründen kann als Endschicht zusätzlich eine Chromschicht aufgebracht werden. 5.8.7 Zusammenfassung und Ausblick Innerhalb des Sfb wurden am IFF und IPA zahlreiche Untersuchungen und Verfahren zur Vorbehandlung und Beschichtung von RP-Bauteilen aller Art unternommen. Da alle Beschichtungsverfahren ihre spezifischen „Stärken“ und „Schwächen“ aufweisen, kann kein Verfahren als am besten geeignet oder als nicht geeignet bezeichnet werden. Als besonders flexibel hat sich das Kombinationsverfahren aus „PVD-Beschichtung kombiniert mit galvanischen Verfahren“ erwiesen. Es ermöglicht die Beschichtung einer großen Vielzahl von verschiedenen Kunststoffen ohne großen Testaufwand für die einzelnen Werkstoffe. Sind viele RP-Bauteile des gleichen Ausgangsmaterials vorhanden, oder sind die RP-Bauteile stark hinterschnitten, kann ein chemisch-galvanisches Verfahren sinnvoll sein. Für metallische RP-Bauteile gilt diese Einschränkung nicht. Diese Bauteile können direkt galvanisch beschichtet werden und sind dadurch etwas einfacher beschichtbar. Da nun Verfahren zur Verfügung stehen, um RPBauteile zu beschichten, wird seit einiger Zeit eine Markteinführung dieser Prozesse angestrebt. Ein zukünftiges Ziel wird es sein, die Verfahren prozesssicherer zu gestalten. Im Haus werden zurzeit Untersuchungen unternommen, um die jeweils passenden Parameter für die in den Versuchen eingesetzten industriellen Anlagen zu ermitteln. Anfang diesen Jahres wurde die Arc-PVD-Anlage mit einem Mikrowellenplasmagenerator ausgerüstet. Durch die Zusammenfassung der beiden Prozesse Oberflächenaktivierung und Beschichtung kann die Prozesszeit deutlich verringert werden. In den weiteren Versuchen soll nun geklärt werden, ob sich durch das Mikrowellenplasma auch die Schichtcharakteristik bei der Beschichtung selbst in Bezug auf die Haftfestigkeit und Homogenität beeinflussen lässt. Des Weiteren wird versucht auch keramische Schichtsysteme auf RP-Bauteile aufzubringen. Außerdem wurden Verfahren untersucht um RP-Bauteile mit Aluminium zu metallisieren und die Al-Schicht anschließend mit einer [Al2O3] Schicht vor abrasivem Verschleiß zu schützen. Dies

412


würde es ermöglichen auch sehr dünne Schichten haftfest und gegenüber dem täglichen Gebrauch widerstandsfähiger zu gestalten.

5.9 Lasergenerieren im modularen System

5.9.1 Einleitung Schon seit jeher besteht die Notwendigkeit, neuen Produktideen die Form von Prototypen zu geben und sie auf diese Weise testen zu können. Geändert hat sich aber gerade in den letzten Jahren die Geschwindigkeit, mit der ihre Herstellung erfolgt. Immer kürzer werdende Produktlebenszyklen erfordern immer schnellere Neuentwicklungen und haben so in den letzten Jahren dazu geführt, dass sich viele verschiedene Verfahren zum Rapid Prototyping etabliert haben. Bei vielen Verfahren ist allerdings der Prototyp hinsichtlich des Materials eingeschränkt. Daher muss insbesondere bei Prototypen aus metallischen Werkstoffen oft auf alternative Werkstoffe ausgewichen werden. Hier wurden jedoch beim Lasersintern in den letzten Jahren deutliche Fortschritte gemacht und es befinden sich neue Verfahren in der Entwicklung wie das Selektive Laserschmelzen oder das Lasercusing (Kap. 5.10). Auch das Verfahren des Lasergenerierens zielt darauf, funktionale metallische Prototypen herzustellen. Besonders interessant ist dabei die Möglichkeit auf bestehende (metallische) Formen aufbauen zu können und dies sogar mit verschiedenen, dem Belastungsfall angepassten Materialien. Dies prädestiniert das Lasergenerieren vor allen anderen Verfahren dafür, bestehende metallische Prototypen zu modifizieren, wie es bei Designänderungen innerhalb der Produktentwicklungszyklen oft gefordert wird, und dadurch die Flexibilität gegenüber Änderungswünschen zu erhöhen. Unter solche metallische Prototypen fallen vor allem Spritzgussformen und Werkzeuge für Klein- und Testserien (Kap. 5.11). Ob das Lasergenerieren nun zum Rapid Prototyping, Rapid Tooling oder zur Werkzeugmodifikation eingesetzt wird, das Verfahren und damit die grundsätzlich zu lösenden Probleme sind gleich. Die Regeln für die Steuerung des Prozesses müssen bekannt sein, so dass beliebige Aufbauten realisiert werden können. Um den Bearbeiter zu entlasten, sollte ein geeignetes messtechnisches Equipment zur Verfügung stehen, das die Beobachtung des Prozesses und damit auch eine Qualitätskontrolle ermöglicht. Idealerweise ließen sich diese Kenntnisse in einer Prozessregelung umsetzen,


413

sodass verschiedene Regler dafür sorgen, dass die Aufbauten in optimaler Weise umgesetzt werden. Da das Lasergenerieren keine Aufbauten in Endqualität erzeugen kann, empfiehlt sich die Kombination mit einem spanenden Prozess wie dem Fräsen. Eine Anlage, die beide Bearbeitungsmöglichkeiten bietet, kann gezielt für bestimmte Produktgruppen (Drehteile, Formen) ausgelegt werden, sodass sie sich für die Herstellung solcher Prototypen und Kleinserien besonders eignet. Im Folgenden werden der Prozess sowie einige Ansätze zur Steuerung, Kontrolle und Regelung des Prozesses beschrieben, die in den letzten Jahren entwickelt wurden. Ferner wird das Konzept des Modularen Systems vorgestellt, das sich mit der Kombination des Lasergenerierens mit anderen Verfahren befasst. 5.9.2 Verfahrensprinzip Das Lasergenerieren ist eine Variante des Laserbeschichtens. Während allerdings mit Laserbeschichten überwiegend das Verfahren bezeichnet wird, flächig für den Verschleißschutz aufzutragen, bezieht sich das Lasergenerieren insbesondere auf den Aufbau komplexer dreidimensionaler Konturen [5.143]. Das Prinzip des Lasergenerierens besteht darin, pulverförmiges Material auf ein Werkstück aufzuschweißen, sodass es eine fest haftende, erhabene Spur bildet (s. Abb. 5.45.).

Abb. 5.45. Der Prozess mit koaxialer und lateraler Pulverzufuhr

Dazu wird das Material des Werkstücks mit Hilfe eines fokussierten Laserstrahls im Brennfleck leicht angeschmolzen. Gleichzeitig wird pulverförmiges Zusatzmaterial in das Schmelzbad gebracht und ebenfalls aufge-

414


schmolzen. Nach der Erstarrung haftet das Zusatzmaterial fest auf dem Werkstück. Dieser Vorgang erfolgt schnell und kontinuierlich. Abbildung 5.45 zeigt die beiden gängigen Methoden der Pulverzufuhr. Im linken Bild wird das Zusatzmaterial koaxial zugeführt, indem ein Pulver-Gas-Gemisch durch eine ringförmig um den Laserstrahl verlaufende Düse in das Schmelzbad fokussiert wird. Die andere Möglichkeit ist die laterale Zufuhr, bei der das Pulver-Gas-Gemisch durch eine röhrchenförmige Düse von der Seite in das Schmelzbad gelangt. Durch die Zuführung von Prozessgas wird das Verhalten der Schmelze positiv beeinflusst und eine Oxidation verhindert. Bei den meisten Pulverförderern wird das Gas gleichzeitig zum Pulvertransport eingesetzt und zusammen mit dem Pulver dem Schmelzbad zugeführt. Häufig werden aber auch zusätzliche Düsen eingesetzt, um den Gasanteil zu erhöhen oder den Pulverstrom zu beeinflussen. Abb. 5.46 zeigt links Einzelspuren, wie sie durch das Lasergenerieren erzeugt werden. Aus mehreren Einzelspuren werden durch Neben- und Übereinanderlegen Schichten, Wände und Volumenkörper erzeugt. Rechts ist eine flächenhafte Beschichtung aus drei Lagen zu sehen. Durch die freie Kombinierbarkeit der Einzelspuren lassen sich fast beliebige Freiformen gestalten.

Abb. 5.46. Beispiel für Einzelspuren und eine mehrlagige Beschichtung

Seit der Patentierung des Verfahrens 1976 [5.59] wurde es an verschiedenen Orten weiterentwickelt und technisch umgesetzt, einige davon speziell zum Rapid Prototyping [5.64], [5.61], [5.8], [5.32], [5.181], [5.144], [5.63], [5.116] und zur Werkzeugmodifikation einschließlich Reparaturen [5.61], [5.178], [5.180], [5.62], [5.139], [5.138], [5.11], [5.47]. Eine sehr ausführliche Übersicht über die Verfahrensvarianten, die zumeist unterschiedliche Namen tragen, findet sich in [5.143]. Das Lasergenerieren kann mit einer Vielzahl unterschiedlicher Materialien durchgeführt werden. Neben Eisen- und Stahlwerkstoffen werden häufig Ni- und Co-Legierungen eingesetzt, vor allem um harte und verschleißbeständige Funktionsflächen herzustellen [5.71], [5.159], [5.55], [5.48], [5.176]. Prinzipiell lassen sich auch keramische oder Hartstoffe hinzufügen, was allerdings für das Rapid Prototyping von geringer Bedeu-


415

tung ist [5.137], [5.88], [5.54], [5.106]. Neben den Fe-Werkstoffen lassen sich als Zusatzwerkstoffe auch Al- und Ti-Legierungen einsetzen [5.159], [5.105]. 5.9.3 Prozesssteuerung Beschreibung der Spuren Eine einzelne Spur kann als eine (Schweiß-)Raupe der Länge l beschrieben werden. Bei Vorliegen eines thermischen und massenmäßigen Gleichgewichtes ist die Spur in Bezug auf Breite und Höhe über die gesamte Länge konstant. Es ist also nicht notwendig die gesamte Spur zu beschreiben, sondern es genügt die Betrachtung des in der Regel kreisförmigen Querschnitts der Spur mit der Breite b und der Höhe h (s. Abb. 5.47.).

Abb. 5.47. Spurquerschnitte

Durch das Anschmelzen des Grundmaterials entsteht die Wurzel. In Abb. 5.47 rechts ist dieses unterhalb der Werkstückoberfläche liegende Gebiet, in dem sich Grund- und Zusatzmaterial vermischen, deutlich zu erkennen. Es wird durch die Wurzeltiefe t oder den Aufmischungsgrad, d.h. das Verhältnis der Flächen von Wurzel und Spur, charakterisiert. Mit zunehmendem Aufmischungsgrad ist der Übergang vom Beschichten zum Legieren fließend. Bei schlecht kombinierbaren Materialien birgt ein hoher Aufmischungsgrad die Gefahr unerwünschter intermetallischer Phasen in sich, weswegen beim Beschichten in der Regel versucht wird, mit möglichst geringen Aufmischungsgraden zu arbeiten (s. Abb. 5.47 links).

416


Relevante Prozessparameter Um Spuren mit bestimmten geometrischen Eigenschaften gezielt generieren zu können, muss bekannt sein, durch welche Parameter der Prozess und damit auch die generierten Spuren zu beeinflussen sind. Die wichtigsten Prozessparameter sind die Laserleistung PL, die Geschwindigkeit v, der am Pulverförderer eingestellte Pulvermassenstrom dm/dt und die Brennfleckgröße. Die Auswertung der Zusammenhänge von Prozessparametern und Aussehen der Spuren zeigt, dass die Spurhöhe h maßgeblich durch den Pulvermassenstrom bestimmt wird, sofern genügend Laserleistung zur Verfügung steht. Dieser lässt sich indirekt auch über die Geschwindigkeit v beeinflussen. Eine signifikante Abhängigkeit von der Laserleistung ist nicht zu erkennen. Dies ist in Abb. 5.48 illustriert, wobei hier die Änderungen von dm/dt und v in der effektiven Geschwindigkeit veff bezogen auf ein festes dm/dt zusammengefasst sind.

Abb. 5.48. Spurhöhe über effektiver Geschwindigkeit

In einer Faustformel zusammengefasst, kann h durch

§ 1 dm · h c ¨ ¸ © v dt ¹

(1)

ausgedrückt werden, mit einer Konstanten c. Hingegen wird die Spurbreite primär durch die Brennfleckgröße bestimmt. Bei gaußförmiger Intensitätsverteilung, wie sie bei fasergekoppelten Lasern außerhalb des Fokus auftritt, wird sie sekundär durch die Laser-


417

leistung verändert. Der Pulvermassenstrom tangiert die Spurbreite nicht. Um sie gezielt zu verändern muss also die Brennfleckgröße geändert werden, was durch spezielle Optiken möglich ist, wie in Abschn. „VarioOptik“ beschrieben. Die Tiefe der Spur wird durch die Laserleistung und den Pulvermassenstrom bestimmt. Während die Leistung die Gesamttiefe t+h bestimmt, ist der Pulvermassenstrom für die Verteilung von h und t verantwortlich. Aufbau komplexer Geometrien Einzelne Spuren können zu fast beliebigen 3D-Gebilden kombiniert werden. Dabei bestehen die „Grundgeometrien“ aus Flächen und Wänden, die gebildet werden, indem eine Spur neben bzw. über die andere gelegt wird (s. Abb. 5.49.).

Abb. 5.49. Wand und Fläche als Grundelemente

Bei mehrlagigen Spuraufbauten ist es wichtig die Spurhöhen genau zu kennen und die z-Position für die nächste Spur so einzustellen, dass Pulver- und Laserfokus knapp unter der vorhergehenden Spuroberfläche liegen. Es können auch zur Herstellung einer definierten Schichthöhe und Oberfläche nach jeder Schicht Egalisierungsfräsprozesse durchgeführt werden. Dies führt jedoch zu einem höheren Zeit- und Materialaufwand und ist bei guter Prozessführung nicht notwendig [5.143], [5.116], [5.93], [5.94]. Volumenkörper werden durch Übereinanderlegen von beschichteten Flächen gebildet, ebenso lassen sich Hohlräume füllen.

418


Richtungsunabhängigkeit Für den Aufbau komplexer Geometrien kann entweder grundsätzlich in nur einer Raumrichtung oder beliebig in der Fläche verfahren werden. Für den letzteren Fall ist es wünschenswert, dass die einzelnen Spuren immer gleich aussehen, egal in welche Richtungen sie gezogen werden, also keine Richtungsabhängigkeit vorliegt. Dazu wird in der Regel mit einer Koaxialdüse gearbeitet, deren Austrittsöffnung ringförmig um den Laserstrahl verläuft. Im Gegensatz dazu kommt das Pulver bei der Lateraldüse seitlich aus einer in der xy-Ebene fest definierten Richtung (vgl. Abb. 5.45). Daher ergibt sich hier eine eindeutige Vorzugsrichtung und der Prozess verhält sich je nach Verfahrrichtung anders. Durch geschickte Korrekturen ist es aber möglich, eine Lateraldüse quasi-richtungsunabhängig zu betreiben. Abhängig davon, wie der Geschwindigkeitsvektor zur Richtung des Pulvers steht, können die drei Grundrichtungen schleppend, stechend und seitlich unterschieden werden. Für jede Richtung fällt die Spurhöhe anders aus und alle weiteren Richtungen lassen sich auf diese Grundrichtungen zurückführen. In Abb. 5.50 ist dies anhand des Aufbaus eines Rechtecks verdeutlicht.

Abb. 5.50. Aufbau eines Rechtecks mit Lateraldüse. Abhängigkeit der Spurhöhe von der Pulverrichtung

Für die Korrektur wird zunächst die gewünschte Höhe h0 festgelegt. Bei der Geschwindigkeit v wird die (nicht korrekte) Spurhöhe h erhalten. Nun wird die Geschwindigkeit über

vkorr

h0 v h

(2)

korrigiert. Abb. 5.51 zeigt ein Beispiel für eine solche Geschwindigkeitskorrektur. Als Sollhöhe wurde die Spurhöhe der schleppenden Spur


419

gewählt. Nachdem die Korrekturen für einen Aufbau mit der Lateraldüse einmal ermittelt wurden, kann so die Lateraldüse quasi-richtungsunabhängig - also der Koaxialdüse vergleichbar - eingesetzt werden. schleppend seitlich stechend seitlich

h in mm 1,07 0,83 0,60 0,93

vkorr in mm/min 400 (= v0) 310 224 347

hkorr in 1.11 1.15 1.24 1.14

mm

Abb. 5.51. Beispiel für eine Geschwindigkeitskorrekur

Vario-Optik Zur Einstellung der Spurbreite ist der Brennfleckdurchmesser entscheidend. Dieser kann in einem bestimmten Rahmen durch Defokussierung eingestellt werden, dann aber muss die Düse entsprechend neu justiert werden. Daher kommt diese Möglichkeit nicht für Veränderungen der Spurbreite während des Prozesses in Frage. Um diesem Problem zu begegnen, wurde eine spezielle Optik entwickelt, mit der die Brennfleckgröße bei gleich bleibendem Arbeitsabstand stufenlos einstellbar ist. Diese arbeitet ähnlich einem Zoomobjektiv und ist in Abb. 5.52 dargestellt.

Abb. 5.52. Die Spezialoptik zur Einstellung unterschiedlicher Spurbreiten

420


Da die Fokussierlinse fix ist und die Brennfleckgröße nur durch die zwei beweglichen Linsen eingestellt wird, kann immer in der Brennebene der Fokussierlinse gearbeitet wird. Die beweglichen Linsen werden über Motoren gesteuert und sind über einen Rechner mit der NC-Steuerung der Handhabung verbunden. Dadurch lassen sich Aufbauten mit variierenden Spurdurchmessern generieren. Ein Beispiel ist in Abb. 5.53 in Form einer Flügelschaufel gezeigt, die von einem dicken zu einem dünnen Ende verläuft.

Abb. 5.53. Prototypische Turbinenschaufel mit variierendem Spurdurchmesser

5.9.4 Prozesskontrolle durch einen Tiefensensor Um zu einer Qualitätskontrolle oder Prozessregelung zu kommen, müssen Sensoren gefunden werden, die in der Lage sind, im Schmelzbad zu messen. Hier ist es heiß, der Bereich über dem Schmelzbad ist von direktem und reflektiertem Laserlicht erfüllt, Pulverpartikel und Schmelzspritzer fliegen herum und durch Optik und Pulverzufuhr ist der Raum eng begrenzt. Durch die starken, unregelmäßigen Emissionen des Schmelzbades scheiden aktive optische Systeme aus. Der Einsatz von Kamerasystemen ist möglich, erfordert aber einen hohen Aufwand bei der Auswertung der Daten. Tauglich sind damit vor allem Sensoren auf Photodiodenbasis. Diese können direkt durch die Optik im Schmelzbad messen, arbeiten passiv und werden durch die ungünstigen Bedingungen um das Schmelzbad herum kaum tangiert. Diese werden für die Prozessregelung (Kap. 5.9.5) eingesetzt.


421

Abb. 5.54. Aufbau des Tiefensensors

Ein weiteres interessantes passives System ist der Tiefensensor der Firma LaserTec, der zur Messung der Tiefe beim Laserabtragen entwickelt wurde. Sein Aufbau ist in Abb. 5.54 dargestellt. Das vom Schmelzbad emittierte Licht wird durch einen Doppelspalt in zwei Strahlen aufgeteilt, die als Lichtpunkte von einem Schirm detektiert werden. Bei einer Höhenänderung der Lichtquelle, d.h. des Schmelzbades, ändert sich auch der Abstand der beiden Lichtpunkte auf dem Schirm. 1000 900

Messwert in µm

800 700 600 500 400 300 Sensormessung Sensormessung geglättet Tastschnittmessung

200 100 0 0

5

10

15 20 25 30 Messstrecke in mm

35

40

45

Abb. 5.55. Vergleich von Sensor- und Tastschnittmessung bei einer Einzelspur

422


Das Messergebnis muss durch komplexe Algorithmen ausgewertet und gefiltert werden, bevor ein brauchbares Messsignal für die Spurhöhe vorliegt. Ein Beispiel für eine in-situ Höhenmessung mit diesem Sensor im Vergleich mit einer nachträglich durchgeführten Tastschnittmessung ist in Abb. 5.55 gegeben. Der Sensor liefert sehr gute Ergebnisse, jedoch ist der Aufwand für die Einrichtung und Kalibrierung sehr hoch. 5.9.5 Prozessregelung Mit einer gezielten Prozesssteuerung lassen sich durch das Lasergenerieren fast beliebige Geometrien herstellen. Dabei ist der Prozess sehr stabil. Der Nachteil liegt jedoch darin, dass sehr viele Feinheiten explizit im NCProgramm vorgegeben werden müssen. So z.B. das Abschalten des Lasers bei Spurüberkreuzungen oder die Zurücknahme der Laserleistung bei höheren Aufbauten. Dieses Vorgehen führt bei komplexen Geometrien sehr schnell zu einem unverhältnismäßig hohen Aufwand und erfordert ein sehr genaues Wissen um den Prozess. Hier kann eine Prozessregelung viel Arbeit abnehmen. Sie hat ferner den Vorteil, dass sie nicht nur auf systematische, sondern auch auf spontan auftretende Fehler reagiert, wie eine Stockung des Pulverstromes. Allerdings ist es sehr schwierig, eine gut funktionierende und zuverlässige Regelung aufzubauen. Da die Regelung den Prozess beeinflusst, besteht immer auch das Risiko fehlerhafter Regeleingriffe. Im schlimmsten Fall bewirken diese genau das Gegenteil dessen, was vom Regler erwartet wird. Temperaturregelung Bei längerer Prozesszeit, vor allem bei höheren Aufbauten, kommt es zu einem Wärmestau. Dies kann entweder durch eine gezielte Zurücknahme der Laserleistung verhindert werden oder durch den Einsatz einer Regelung, die die Temperatur im Schmelzbad konstant hält, indem sie die Laserleistung nachführt. Diese Art der Temperaturreglung, die in der Lasertechnik häufig eingesetzt wird [5.71], [5.76], [5.77], [5.12], muss für das Lasergenerieren so eingestellt werden, dass die geregelten Aufbauten qualitativ nicht schlechter sind als die gesteuerten. Als Beispiel sei die Vermeidung des Temperaturstaus beim Wandaufbau gegeben. Beim Aufbau von Wänden wird in der untersten Spur die Wärme über die Kontaktstelle radial in das Werkstück abgeleitet. Bei den nächsten Spuren kann die Ableitung jedoch nur noch durch den dünnen Steg der Wand erfolgen. Je schmaler die Wand ist, desto schwieriger ist es, die


423

Wärme durch den Steg nach unten abzuführen. Es bildet sich ein Temperaturstau aus, der durch die Überhitzung des Schmelzbades die Qualität des Wandaufbaus mindert. Um dies zu verhindern, wird die Temperatur über ein Pyrometer oder eine Photodiode gemessen und die Laserleistung entsprechend nachgeführt. In Abb. 5.56 ist deutlich zu erkennen, dass die Temperatur konstant bleibt, während die Laserleistung kontinuierlich heruntergeregelt wird.

Abb. 5.56. Aufbau einer Wand mit Temperaturreglung

Der Entwurf des Reglers und die Einstellung der Parameter erfordert einige Mühe, da sie auch bei stabil laufender Regelung einen deutlichen Einfluss auf die Spuranfänge haben. Abb. 5.57 illustriert dies für den I-Anteil eines PID-Reglers.

424


Abb. 5.57. Einfluss unterschiedlicher I-Parameter auf Wandaufbauten

Prüft man Wände, die mit verschiedenen PID-Einstellungen aufgebaut werden, hinsichtlich dieses Effektes, so zeigt sich, dass er durch schnelle P-Regler verstärkt und durch träge I-Regler abgemildert wird. Allerdings ist die tolerierbare Trägheit des Reglers durch die Forderung nach rechtwinkligen Wandanfängen begrenzt. Gute Ergebnisse lassen sich mit reinen I-Reglern unterhalb der Schwingungsgrenze erzielen. Höhenregelung Eine Regelung der Spurhöhe kann interessant sein, wenn richtungsabhängig gearbeitet wird, also bspw. mit Lateraldüsen oder in Zwangslagen. Wie für die Temperaturregelung wird zunächst ein Messwert für die Spurhöhe benötigt. Für diesen Zweck bietet sich die zusammengesetzte Größe mh=RR/PL0,5 an, die sich aus den Messwerten für Rückreflex und Laserleistung zusammensetzt und nur von der Spurhöhe abhängt (s. Abb. 5.58). Des Weiteren wird eine Stellgröße benötigt, die die Spurhöhe beeinflusst. Nach Abschn. „Relevante Prozessparameter“ eignen sich dafür der Pulvermassenstrom oder die Geschwindigkeit. Da der Pulvermassenstrom nur mit großer Latenz auf Änderungen der Sollvorgabe reagiert, wird hier die Geschwindigkeit bevorzugt. Um sich dabei nicht der Möglichkeit der Geschwindigkeitsvorgabe über das NC-Programm zu berauben und das Risiko bei fehlerhafter Regelung zu begrenzen, wurde der Geschwindigkeitsregelung nur der Zugriff auf den Geschwindigkeitsoverride innerhalb bestimmter Grenzen gewährt.


425

Abb. 5.58. Der kombinierte Wert mh in Abhängigkeit von der Spurhöhe

Für die technische Umsetzung wurde die Override-Vorgabe der Steuerung mit einem analogen Eingang verbunden. Dieser kann mit 0..10 V beaufschlagt werden. Über

v

vNC

5 U stell 10

(3)

beeinflusst das Stellsignal der Regelung Ustell die im NC-Programm vorgegebene Geschwindigkeit vNC. Die Änderung ist hierbei limitiert auf v=0,5..1,5vNC. Der Aufbau des Regelschemas ist in Abb. 5.59 dargestellt. Die Messwerte für die Laserleistung und den Rückreflex werden zunächst zu mh verarbeitet. Mit der Sollvorgabe für mh ergibt sich die durch eine gleitende Mittelung geglättete Regeldifferenz. Diese wird von einem PID-Regler verarbeitet und führt zu dem analogen Ausgangssignal für den Stellwert, das wie oben beschrieben in der Maschine weiterverarbeitet wird. Ein Beispiel für die Auswirkung der Regelung für einfache Spuren ist in Abb. 5.60 gezeigt. Aufgebaut wurden neun Spuren mit Geschwindigkeitsvorgaben von vNC=100..900 mm/min. Gleichzeitig entsprach der Sollwert für mh einem Wert, der der bei v=400 mm/min erreichten Spurhöhe entspricht. Auf der Ordinate sind die real gefahrenen Geschwindigkeiten dargestellt. Ohne Regelung verlaufen sie entlang der dunkelgrauen Kurve. Mit Regelung können sie innerhalb der beiden hellgrauen Kurven, die die Regelgrenzen darstellen, variieren.

426


Abb. 5.59. Regelschema für den Höhenregler

Es ist gut zu erkennen, dass der Regler versucht, die Geschwindigkeit zunächst nach oben zu korrigieren. Bei v=400 mm/min lässt er die vorgegebene Geschwindigkeit unverändert und korrigiert sie danach wieder nach unten, bis er bei v=900 mm/min an die Regelgrenze stößt.


427

Abb. 5.60. Beispiel für die Funktionsweise des Höhenreglers

5.9.6 Modulares System Das Lasergenerieren als „lokal urformendes Verfahren“ bietet ein großes Potenzial für Anwendungen des Rapid Prototyping, Rapid Tooling und der Werkzeugmodifikation. Jedoch ergibt sich aus der freien Erstarrung der Schmelze ohne formgebende Werkzeuge die Notwendigkeit einer Nachbearbeitung. Dies kann z.B. durch Fräsen geschehen, was die Kombination des Lasergenerierens mit dem Fräsen in einer Maschine nahe legt. Dadurch können die Investitionskosten in Grenzen gehalten werden, gleichzeitig ist der wechselweise Betrieb beider Verfahren möglich. Nach diesem Ansatz lässt sich das Konzept des flexiblen laserintegrierten Fertigungssystems für weitere Anwendungsfälle aus dem Bereich der Prototypenproduktion und Werkzeugmodifikation weiterentwickeln. Je nach Aufgabenstellung lassen sich ohne großen Aufwand weitere etablierte Laserverfahren wie Schneiden, Schweißen oder Härten einbeziehen. Als Plattform dient jeweils die Handhabung, also z.B. das Fräszentrum. Dieses wird um weitere Module wie Laser, Optiken, Pulverzuführung etc. erweitert. Natürlich ist es weder notwendig noch zweckmäßig, alle möglichen Verfahrensvarianten in einer einzigen Anlage zu integrieren. Aus Gründen der Handhabbarkeit sollte die Zusammensetzung eines solchen Systems viel mehr auf die Anforderungen einer Produkt- oder Teilefamilie ausgelegt werden. Dies führt zu einem modularen Aufbau flexibler Fertigungssysteme sowohl hinsichtlich der Maschinen wie auch der Steuerungstechnik. So kann ein spezifisches System aus einem Baukasten vorhandener

428


Module nach Bedarf zusammengesetzt werden. Abb. 5.61 zeigt das Schema eines solchen Systems für die Kombination von Lasergenerieren und spanender Bearbeitung.

Abb. 5.61. Schema einer modular aufgebauten Kombination von Lasergenerieren und spanender Bearbeitung

Abb. 5.62. Bilder eines modularen Beispielsystems

Die Tauglichkeit solcher modularen Systeme konnte beispielhaft auf einem Dreh- und einem Fräszentrum gezeigt werden. Alle Zusatzmodule


429

sowie die Handhabung besaßen dabei eigene Steuerungen und kommunizierten mit einem autarken Leitrechner, der den gesamten Herstellungsprozess koordinierte. Abb. 5.62 zeigt ein Bild des Systems in der Drehmaschine, Abb. 5.53 ein damit hergestelltes Flügelrad.

5.9.7 Zusammenfassung und Ausblick In breiten Anwendungsfeldern gibt es einen bislang weitgehend ungedeckten Bedarf an automatisiert hergestellten Musterteilen wie auch an Modifikationen bestehender Werkzeuge. Ein modulares Fertigungssystem aus einer teilespezifischen Werkzeugmaschine mit integrierter Ausrüstung zum Lasergenerieren bietet hier einen flexiblen Ansatz, diesen Bedarf zu decken. Dazu konnte ein Konzept entworfen werden, um mehrere einzelne Elemente in modularer Form zu einem flexiblen laserintegrierten Fertigungssystem für Prototypen oder Werkzeugmodifikationen zusammenzusetzen und steuerungstechnisch zu verknüpfen. Während das Fräsen oder Drehen dabei die abtragenden Funktionen übernimmt, wie sie z.B. zur Nachbearbeitung notwendig sind, ist das Lasergenerieren für den auftragenden Teil zuständig. Bei genauer Kenntnis der relevanten Prozessparameter, ihres Einflusses auf das Ergebnis und einiger Regeln für die Kombination von Einzelspuren zu komplexen Körpern, kann das Lasergenerieren zum Aufbau fast beliebiger 3D-Gebilden eingesetzt werden. Um die Handhabung des Prozesses zu vereinfachen, konnten Messverfahren gefunden werden, die eine Qualitätskontrolle und Prozessüberwachung ermöglichen. Diese lassen sich bedingt auch zu einer Regelung des Prozesses einsetzen, was die Bedienungsfreundlichkeit des Prozesses deutlich erhöht. Damit ist das Lasergenerieren wie auch das modulare System schon in einem fortgeschrittenen Stadium, was einen verstärkten Einsatz in der Industrie erwarten und erhoffen lässt.

430


5.10 Selektives Lasersintern von Hochleistungspolymeren mittels Nd:YAG-Laser

5.10.1 Einleitung Als das Institut für Kunststoffprüfung und Kunststoffkunde (IKP) vor über zwölf Jahren in diesen Bereich eingestiegen ist, gab es nur wenige kommerziell erhältliche Anlagen für das Rapid Prototyping [5.179]. Diese beschränkten sich auf einige wenige Materialien und waren oft nur als Design Prototypen einsetzbar. Das IKP hat diese Fragestellung deshalb mit aufgenommen, um die Qualität und die Vielfalt der verwendbaren Materialien und Prototypen zu erhöhen. An der rasanten Entwicklung, die seitdem das Rapid Prototyping genommen hat, zeigt sich, dass das IKP damit den „Zahn der Zeit“ getroffen hat. Die Vielfalt der Verfahren und der Materialien ist mittlerweile sehr breit [5.56] und entwickelt sich nach wie vor weiter. Neben dem Erstellen von Prototypen ist es mittlerweile auch möglich, Werkzeuge mittels Laserverfahren zu erstellen („Rapid Tooling“) oder sogar Kleinserien zu fertigen („Rapid Manufacturing“). Das IKP hat diese kommerzielle Entwicklung durch entsprechende Forschungsprojekte begleitet. In den letzten zehn Jahren haben am IKP im Bereich der „Rapid“-Technologien (z. T. in Zusammenarbeit mit der Daimler Chrysler AG) sieben wissenschaftliche Mitarbeiter promoviert [5.19], [5.46], [5.49], [5.90], [5.120], [5.152], [5.172], was die hohe Bedeutung dieses Themas am Institut verdeutlicht.In den letzten Jahren wurde der Fokus auf das pulverbasierte Lasersintern gelegt. Auch weiterhin gibt es Forschungs- und Entwicklungsbedarf für das Verständnis und die Verbesserung der „Rapid“-Technologien. Derzeit kann nur ein Teil aller möglichen Werkstoffe eingesetzt werden, noch immer sind oft die Eigenschaften der spritzgegossenen denen der gesinterten Bauteile überlegen. Das Verständnis der Thermodynamik und der damit verbundenen Energieeinkopplung, -aufnahme, -weitergabe und -abgabe ist bisher nur oberflächlich vorhanden, so dass nach wie vor sehr viel empirisch gearbeitet wird.

5.10 Lasersintern von Hochleistungspolymeren mittels Nd:YAG-Laser

431

5.10.2 Ausgangssituation Im Folgenden wird die Ausgangssituation der „Rapid“-Technologien umrissen, das Selektive Lasersintern beschrieben und die für das IKP daraus resultierende Problemstellung dargestellt. „Rapid“-Technologien Bei den „Rapid“-Technologien handelt es sich um generative Fertigungsverfahren. Das bedeutet, dass die dreidimensionale Struktur durch schichtweises Aneinanderfügen erstellt wird. Die Begrifflichkeit des Rapid Prototypings hat sich so weit eingebürgert, dass es zu einem feststehendem Begriff geworden ist. Allerdings gehen die damit verbundenen Technologien mittlerweile über die Prototypenherstellung hinaus. Deshalb wird hier allgemeiner von den „Rapid“-Technologien gesprochen. Diese Technologien lassen sich für vier verschiedene Fertigungsebenen nutzen [5.56]: x Konzeptmodelle: Diese Modelle sind nicht mechanisch belastbar und dienen allein der dreidimensionalen Anschauung. x Funktionsmodelle: Diese Modelle haben ähnliche Eigenschaften wie die in der späteren Serienfertigung hergestellten Bauteile. x Werkzeuge („Rapid Tooling“): Es werden Werkzeuge erzeugt, die mit anderen Fertigungsverfahren kombiniert werden. x Kleinserien („Rapid Manufacturing“): Die gefertigten Geometrien entsprechen in ihren Eigenschaften den im Einsatz gewünschten. Die Trennung der einzelnen Ebenen ist nicht einfach und hängt sehr stark von den gewünschten Bauteileigenschaften ab. Gerade im Bereich des Lasersinterns von Polyamid ist z.B. der Übergang vom Funktionsmodell zur Kleinserie fließend. Die Marktentwicklung der „Rapid“-Technologien ist sehr rasant. Ständig gibt es neue Verfahren, so dass mittlerweile eine große Anzahl von Konzepten existiert, die grundsätzlich dem generativen Schichtaufbau entsprechen. Etablierte Verfahren sind: x Stereolithoghraphie (SLA): Aushärten von duroplastischen Harzsystemen mittels Lasers x Selektives Lasersintern (s. u.) x Schicht-Laminat-Verfahren (LLM, LOM): Ausschneiden einer Schichtkontur und Verkleben der einzelnen Schichten

432


x Schmelzeauftragsverfahren (FDM): Aufschmelzen eines Kunststoffstrangs, Auftragen der Schmelze über eine Düse und Erstarren der Schmelze x 3D-Drucken (3DP): Drucken von „Tinte“ in ein Pulverbett. Die „Tinte“ verklebt die Partikel miteinander durch Aushärtung oder Anlösen. x Lasergenerieren: Materialauftrag durch lokales Aufschmelzen von Metallpulver durch einen Laser Laserverfahren Viele von den oben genannten Verfahren setzen Laser ein, um einen lokalen Energieeintrag zu realisieren. Sie stellen damit die wichtigste Gruppe der „Rapid“-Technologien dar. Grundsätzlich gibt es verschiedene Laser, die bei diesen Verfahren zum Einsatz kommen. Im Folgenden wird auf die Laser kurz eingegangen, die bei „Rapid“-Prozessen eingesetzt werden [5.56]: x CO2: Der CO2-Laser ist ein Gaslaser mit einer Wellenlänge von 10,6 µm. Dieser Lasertyp lässt sich kostengünstig bauen und wird deshalb vielfach in industriellen Anwendungen eingesetzt. Da es allerdings keine für die Wellenlänge von 10,6 µm transparenten Gläser gibt, muss die optische Umlenkung und Fokussierung allein über (Parabol-)Spiegel oder Zinkselinid-Linsen erfolgen [5.179]. CO2-Laser werden bei den „Rapid“-Technologien bei vielen kommerziellen Anlagen des Lasersinterns benutzt [5.56]. x He-Cd: Der He-Cd-Laser ist ein Gaslaser, der Licht mit den Wellenlängen von 325nm (UV) und 442nm (blau) emittiert. Er ist ein im Betrieb vergleichsweise teurer Laser und hat deshalb einen sehr eingeschränkten industriellen Einsatzbereich [5.179]. Er wird jedoch in einigen Stereolithographieanlagen zum Aushärten von UV sensitiven Harzsystemen eingesetzt [5.56]. x Ar-Ionen: Der Ar-Ionen-Laser ist ein weiterer Gaslaser. Der Ar-IonenLaser besitzt verschiedene Emissionslinien. Die für die Stereolithographie benötigte UV-Linie wird durch doppelt-ionisierte Übergänge, welche wesentlich höhere Ströme in der Plasmaentladung erfordern, erzeugt. Daher lassen sich nur die großen High-Power-Laser auf UVBetrieb umbauen [5.179], deren Einsatz entsprechend leistungs- bzw. kostenintensiv ist. x Nd dotiert: Ein Nd:YAG-Laser ist ein Festkörperlaser, der als aktives Medium einen Neodym-dotierten Yttrium-Aluminium-Granat-Kristall


433

verwendet und infrarote Strahlung mit einer Wellenlänge von 1,064 µm emittiert. Dieser Laser ist in der Industrie sehr gebräuchlich, da er vergleichbare Kosten wie ein CO2-Laser verursacht [5.151]. Ein Vorteil gegenüber dem CO2-Laser ist, dass Glasoptiken eingesetzt werden können. Selektives Lasersintern (SLS) Ein sehr verbreitetes Laserverfahren ist das Selektive Lasersintern. Bei diesem Verfahren werden Pulverkörner zu einer Schicht verschmolzen. Dabei liegen die Partikel lose in einem temperierten Pulverbett. Durch den Schmelzprozess verlaufen die einzelnen Partikel ineinander, reduzieren dabei ihre Oberfläche (versintern) und erstarren wieder als Verbund. Dabei sind die Oberflächenspannung und die Viskosität der geschmolzenen Partikel genauso entscheidend wie die Schmelz- und Erstarrungskinetik des Materials. Eine SLS-Anlage besteht damit im Wesentlichen aus folgenden Teilen (s. Abb. 5.63): x Beheizbares Pulverbett: Die Heizung wird in der Regel über einen Ofen realisiert. Um thermischen Abbau zu vermeiden, wird der Ofen unter Umständen mit Schutzgas gespült. x Beschichtungsanlage und z-Achsen-Verstellung: Nach jedem Sintervorgang wird das Pulverbett eine Schichtdicke nach unten verfahren. Auf der bereits versinterten Struktur wird über eine Pulverzufuhr und eine Nivelliereinheit neues Pulver aufgebracht. x Laser mit x-y-Spiegeln: Steuerbare Spiegel lenken den Laserstrahl an die Stelle, an der das Pulver selektiv aufgeschmolzen werden soll. x Steuerrechner: Der Steuerrechner erstellt im Idealfall die Schichtgeometrie aus der dreidimensionalen Bauteilgeometrie. Er steuert alle zuvor genannten Anlagenteile in der richtigen Reihenfolge an, um eine effiziente Zeitnutzung zu garantieren. Grundsätzlich können beliebige Pulver versintert werden, am Markt haben sich zurzeit aber vor allem Kunststoffpulver und Metallpulver durchgesetzt. Bei den Kunststoffpulvern muss zwischen amorphen Thermoplasten (z. B. Polystyrol (PS) und Polymethylmethacrylat (PMMA)) und teilkristallinen Thermoplasten (z.B. Polyamid (PA)) unterschieden werden. Amorphe Thermoplaste erweichen langsam im Bereich ihrer Glasübergangstemperatur, die Viskosität nimmt aber nur langsam mit steigender Temperatur ab. Teilkristalline Thermoplaste schmelzen oft bei etwas höheren

434


Temperaturen, werden dann aber durch Aufschmelzen ihrer kristallinen Phase schnell viskos. Der Rekristallisationsprozess hat einen zusätzlichen Einfluss auf das Sinterverhalten der teilkristallinen Thermoplaste. In Abb. 5.64 ist der Sintervorgang schematisch für einige Sinterlinien dargestellt. Die Belichtungsparameter des SLS-Prozesses üben einen entscheidenden Einfluss auf die Qualität der Sinterproben aus. Zu diesen Parametern gehören die Laserleistung PL, die Scangeschwindigkeit vs (Belichtungsgeschwindigkeit) und der Hatchabstand hs (Linienabstand). Sie bestimmen wesentlich die Sintertiefe į und die Sinterbreite ws.

Abb. 5.63. Prinzip einer Lasersinteranlage (nach [5.45])

Abb. 5.64. Schematische Darstellung des Sintervorgangs


435

Vorarbeiten am IKP Am IKP wurden in den Jahren 1995 – 2003 zwei Lasersinteranlagen aufgebaut. Die erste Anlage ist eine CO2-Laseranlage. Mit dieser Anlage wurden breite Materialeignungstests durchgeführt. Während sich PA und PS sehr gut mit der CO2-Anlage sintern ließen, gab es bei anderen Materialien folgende Ergebnisse [5.85]: x Der Versuch, PET als Rapid Prototyping Material zu adaptieren, scheiterte an den optischen Eigenschaften des Werkstoffs bei der Wellenlänge des CO2-Lasers. x Hochschmelzende Kunststoffe wie Polyethersulfon (PES) und Polyetheretherketon (PEEK) zeigten auf Grund ihrer chemischen Struktur nur eine minimale Eindringtiefe im Wellenlängenbereich des CO2Lasers. x Es konnte ein thermoplastischer Elastomerwerkstoff (TPE) erfolgreich versintert werden (s. Abb. 5.65 links). Allerdings gab es beim Grundmaterial erhebliche Chargenschwankungen und Alterung, die nicht abschließend geklärt werden konnten. An der CO2-Anlage wurden außerdem erfolgreich Untersuchungen zur Adaption von keramischen Werkstoffen für das Lasersintern (s. Abb. 5.65 rechts) durchgeführt [5.152]. Die Anlage und ihre Steuerung sind sehr modular aufgebaut und können sehr leicht an neue wissenschaftliche Anforderungen angepasst werden.

Abb. 5.65. Proben aus TPE (Rohr) und Keramik (Schaufelrad)

Das anlagentechnische Know-How konnte in den Jahren 2001 bis 2003 genutzt werden, um eine zweite Laseranlage mit einem Nd:YAG-Laser zu konzipieren. Es konnte zunächst eine grundsätzliche Machbarkeit des Lasersinterns mit dem neuen System an PA und PS gezeigt werden. Dabei

436


wurde Ruß als Koppelmedium eingesetzt, um die Energieabsorption zu steuern. Resultierende Zielsetzung Das Hauptziel dieses Teilprojektes knüpft an die vorangegangenen Arbeiten an und basiert auf der Adaption von neuartigen Polymeren für die entwickelte Lasersinter-Prozesstechnik mit Hilfe des Nd:YAG-Lasers und eines lasersensitiven Additivs. Grundsätzlich ist die Zielsetzung, das bisher übliche Materialspektrum für das Selektive Lasersintern zu erweitern, um neuartige und innovative Anwendungen z.B. im Automobil- oder auch Medizinsektor zu ermöglichen. Als erstes Ziel wurden dabei zunächst die hochtemperaturbeständigen Kunststoffe fokussiert. Für dieses Marktsegment sind die Materialkosten grundsätzlich höher, so dass die entsprechend höheren Verfahrenskosten weniger ins Gewicht fallen als bei den Standardkunststoffen. Die Hochleistungskunststoffe eröffnen ebenfalls den Marktbereich hoher Steifigkeit und Festigkeit, der bisher allein den spritzgegossenen Proben vorbehalten ist. Es sind deshalb auch neue Anwendungen z. B. in der Luft- und Raumfahrt denkbar. In der Medizintechnik wird PEEK als Implantat bereits in Forschungsanwendungen getestet, da es sich als biokompatibel erwiesen hat [5.92]. In diesem Bereich ist das Selektive Lasersintern sehr attraktiv, da diese Technologie großes Potenzial zur Herstellung individuell angepasster Implantate für den einzelnen Patienten birgt. Zukünftig sind den möglichen Einsatzgebieten der Hochleistungskunststoffe grundsätzlich kaum Grenzen gesetzt und können insbesondere dort entstehen, wo heute noch vielfach Metalle eingesetzt werden. Langfristig ist außerdem angedacht, die neue Anlagentechnik auch für andere Kunststoffe zu nutzen. Die Einkopplung der Energie über ein Koppelmedium macht diesen Ansatz attraktiv. Es wäre eine „universelle“ Laseranlagentechnik denkbar, die nacheinander und vielleicht sogar als Werkstoffverbund beliebige thermoplastische Kunststoffe sintern kann. 5.10.3 Lösungsansätze Materialtechnische Basisuntersuchungen Der thermodynamische Hintergrund des Selektiven Lasersinterprozesses ist extrem komplex. Für die vorliegenden Untersuchungen wurde die E-


437

nergieeinkopplung, wie in Abb. 5.66 dargestellt, über ein Koppelmedium (Ruß) realisiert. Es erfolgt dabei gleichzeitig eine teilweise Einkopplung der Energie im Ruß durch Absorption, Wärmeabgabe durch Konvektion, Leitung und Strahlung sowohl an das umliegende Polymer als auch an die Luft bzw. an das verwendete Inertgas.

Abb. 5.66. Schematische Darstellung der neuen Einkoppeltechnik

Vergleiche der durch den Laser zur Verfügung gestellten mit der zum Schmelzen des Kunststoffs benötigten Energie haben ergeben, dass weniger als 1% der Laserenergie zum Aufschmelzen des Kunststoffs genutzt wird. Untersuchungen an Einschichtproben haben den Einfluss der eingebrachten Energie gezeigt [5.86], [5.163]. Die Sintertiefe G erhöht sich mit zunehmendem Energieeintrag, d. h. es können dickere Schichten gesintert werden. Dieser Prozess lässt sich allerdings nicht unbegrenzt weiterführen, da die Oberfläche der Probe zunehmend verschmolzen wird, es entstehen zunehmend verzogene, inhomogene Strukturen. Es konnten nur Einzelschichtproben bis etwa 500 µm Schichtdicke hergestellt werden. Zum Einfluss des Rußgehalts wurden sowohl an Einschicht- als auch an Mehrschichtproben Untersuchungen [5.163], [5.175] durchgeführt. Bei diesen Untersuchungen zeigte sich, dass es ähnlich der eingebrachten Energie einen idealen Bereich für den Rußanteil gibt. Mit steigendem Rußgehalt steigt die mechanische Steifigkeit bei gleich bleibenden Laserparametern deutlich an. Nichtsdestotrotz wird der Rußanteil als Additiv zum Material möglichst gering gesetzt, um die Beeinflussung durch den Ruß zu minimieren. Zusätzlich hat der Rußgehalt auch einen Einfluss auf das Kristallisationsverhalten des Kunststoffs, da er

438


keimbildende Wirkung hat. Der genaue Einfluss der Keimbildung auf das Gesamtsystem wurde aber bisher noch nicht untersucht. Weitere Untersuchungen der mechanischen Eigenschaften von Mehrschichtproben fanden unter Variation der Parameter Laserleistung und Scangeschwindigkeit statt. Die Geschwindigkeit erhöhte sich parallel zur Laserleistung. Das führt bei gleich bleibender mittlerer Energiedichte zeitlich lokal zu einer höheren Temperatur, da die gleichzeitige Energieabgabe geringer ist. Mit steigender Geschwindigkeit nimmt deshalb die Steifigkeit und Festigkeit zu, wie in Abb. 5.67 zu erkennen ist. Es bildet sich keine ausgeprägte Streckspannung aus. Dieses Ergebnis zeigt, dass die mittlere Energiedichte eine wichtige Kenngröße ist, um das generelle Arbeitsfenster festzulegen und qualitative Prozesse darzustellen. Die mittlere Energiedichte ist jedoch nicht geeignet, alleinige Kenngröße für die Parameteroptimierung zu sein. Neben den Laserparametern und dem Rußgehalt wurde auch die Zusammensetzung des Polymerpulvers variiert. Die Untersuchungen umfassten neben den reinen PEEK- und Polyetherketon- (PEK) Pulvern auch Mischungen dieser Pulver. Bei gleichen Laserparametern ergaben sich bessere mechanische Eigenschaften (Festigkeit, Steifigkeit) für die Mischungen als für die reinen Komponenten. Allerdings verhalten sich die Mischungen etwas spröder als die reinen Polymerpulver [5.86].

Abb. 5.67. Einfluss der Scangeschwindigkeit bei gleich bleibender mittlerer Energiedichte


439

Optimiert man für jede Polymermischung die Sinterparameter, ergeben sich vergleichbare mechanische Eigenschaften bei allen Mischungen. Damit ist das ausschließliche Mischen von verschiedenen Kunststoffpulvern nicht ausreichend, um die Sinterergebnisse grundsätzlich zu verbessern. In Abb. 5.68 sind beispielhaft zwei Querschnitte lasergesinterter Mehrschichtproben dargestellt. Die Probe links ist poröser, die Probe rechts kompakter. Dies führt dazu, dass die rechte Probe bei gleicher Schichtdicke etwas dünner ist. Darin liegt auch die Hauptursache für den stärkeren Verzug der stärker versinterten Proben.

Abb. 5.68. Querschnitte durch Sinterproben

Betrachtet man Dünnschnitte der gesinterten Proben in höherer Vergrößerung im Transmissionselektronenmikroskop, lassen sich die Übergänge zwischen den ehemals separaten Partikeln detektieren.

Abb. 5.69. „Sinternähte“ an PEEK Proben

Abb. 5.69 zeigt beispielhaft zwei dieser Übergänge bzw. Nahtstellen. Sie stellen Schwachstellen im Material dar und führen zusammen mit den Kerbwirkungen an den Nahträndern (s. Abb. 5.69 rechts oben) zur Redu-

440


zierung der mechanischen Festigkeit im Vergleich zu spritzgegossenen Proben. 5.10.4 Weiterentwicklung der Prozesstechnik Die am IKP zur Verfügung stehende Anlage ist sehr offen gestaltet, um weitere Modifizierungen leicht durchführen zu können. Gleiches gilt für die selbst adaptierte Steuerungssoftware. Fast alle Parameter lassen sich variieren. Im Handbetrieb ist sogar eine schichtweise Variation der Sinterparameter möglich. Zurzeit ist die Bauteilkammer nicht temperiert, da die Sinterversuche bei Raumtemperatur bereits sehr erfolgreich waren. Ein nachträgliches Nachrüsten der Temperiereinheit ist allerdings leicht möglich, da die Sinterkammer bereits temperaturbeständig ausgelegt worden ist. Als ein weiterer Schritt musste die Verfahrenstechnik verfeinert werden, damit die einzelnen Schichten nicht durch den Nivelliervorgang zueinander verschoben werden. Das Problem wurde durch die Bereitstellung einer Basisplatte aus einem polymeren Werkstoff, auf den aufgebaut wird, gelöst (s. Abb. 5.70.).

Abb. 5.70. Gesinterte Geometrie auf gesäuberter Basisplatte

Dabei ist es wichtig, dass diese Basisplatte aus einem niedriger schmelzenden Kunststoff ist. Versuche mit verschiedenen Basisplattenmaterialien haben ergeben, dass sich z. B. Polyethylen gut als Basisplattenmaterial eignet. Um die Ablösbarkeit der Struktur von der Basisplatte zu gewähren, wird die erste Schicht mit etwas höhere Leistung gesintert, so dass sich eine leichte Schichtinhomogenität einstellt. Durch die leicht gerippte Struktur der ersten Schicht kann diese gut von der Basisplatte gelöst werden.


441

Dreidimensionale Sintergeometrien Aufbauend auf die Ergebnisse der materialtechnischen Basisuntersuchungen und der Weiterentwicklung der am IKP vorhandenen Prozesstechnik konnten einfache dreidimensionale Körper (PEEK, PEK und PEEK / PEKCompounds) gesintert werden. Beispielhaft sind in Abb. 5.71 eine Pyramide mit 20x20 mm2 Grundfläche und 10 mm Höhe (links) sowie ein Rohr mit 10 mm Innenradius, 15 mm Außenradius und 10 mm Höhe dargestellt (rechts).

Abb. 5.71. Einfache Geometrien aus gesintertem PEEK

Abb. 5.72. Schichtgeometrie (Ausschnitt aus Spiegelfuß) aus gesintertem PEEK (rechts)

Komplexere Strukturen können mit dem beschriebenen Verfahren ebenfalls gesintert werden. Es wurde exemplarisch ein Ausschnitt einer Spiegelfußgeometrie, bestehend aus 10 Schichten mit je 0,2 mm Schichtdicke, hergestellt (s. Abb. 5.72.). Die Konturschärfe ist auch bei den spitzen Ecken sehr gut. Allerdings tritt bei zunehmendem Schichtaufbau ein stärkerer Verzug der gesamten Geometrie auf, der höhere Aufbauten verhindert.

442


Hier sind noch Verbesserungen erforderlich. Ein Ansatz ist dabei, die Pulverdichte des Bettes vor dem Sintervorgang zu erhöhen. 5.10.5 Verfahrenskombinationen Es wurden außerdem verschiedene Verfahrenskombinationen im Zusammenhang mit dem neuen Lasersinterverfahren erprobt. Als aussichtsreichste Kombination wird im Folgenden kurz auf das Metallbeschichten der gesinterten Strukturen eingegangen. Ausführlichere Informationen zum Beschichten von Kunststoffe sind in Kap. 5.8 zu finden. Hochtemperaturbeständige Kunststoffe eignen sich sehr gut, um mit Metallen beschichtet zu werden. Dies liegt daran, dass bei einigen Beschichtungsverfahren ein höherer Energieeintrag in den darunter liegenden Kunststoff (Substrat) erfolgt. Insbesondere bei dickerem Materialauftrag kann dieser Energieeintrag bei Standardkunststoffen zum Aufschmelzen des Substrats führen. Neben den optischen Eigenschaften (farbiger Metallglanz, Oberfläche), die im industriellen Einsatz von nicht unwesentlicher Bedeutung sind, können auch andere Eigenschaften (Härte und Kratzfestigkeit) des Materials durch die Beschichtung verbessert werden. Eine geschickte Verfahrenskombination vergrößert also das mögliche Einsatzspektrum der Bauteile. 5.10.6 Zusammenfassung und Ausblick Die „Rapid“-Technologien sind ein immer noch wachsender Markt. In den letzten fünfzehn Jahren hat sich eine Vielzahl von unterschiedlichen generativen Prozessen etabliert, die mit verschiedenen Prinzipien funktionieren. Den größten Anteil haben dabei laserbasierte Systeme, insbesondere die Stereolithographie für duroplastische Kunststoffe und das Selektive Lasersintern für thermoplastische Kunststoffe und Metalle. Das IKP, das seit langem Erfahrung im Rapid Prototyping hat, sieht für thermoplastische Kunststoffe im Selektiven Lasersintern zukünftig das größte Potenzial und hat deshalb im Labormaßstab eine neue Laseranlage mit einem Nd:YAG-Laser aufgebaut. Der Energieeintrag erfolgt nicht direkt im Kunststoff, sondern über ein zusätzliches Koppelmedium. Dies ist zurzeit Ruß, der sich erwärmt und die Energie an das umliegende Polymerpulver, welches dann verschmilzt, abgibt. Dieses Prinzip hat den Vorteil, dass es unabhängig vom Absorptionsverhalten des jeweiligen Kunststoffs funktioniert.


443

In einer ersten Phase konnte das Wirkprinzip an PS und PA grundsätzlich bewiesen werden. Da diese beiden Kunststoffe auch mit herkömmlichen CO2-Laseranlagen gesintert werden können, stellen sie gute Referenzmaterialien aber keine wirkliche Neuerung dar. Deshalb hat das IKP mit seinem neuen Verfahren den Sprung in die Hochleistungskunststoffe gewagt und die Kunststoffe PEEK und PEK untersucht. Auch hier konnte zunächst die grundsätzliche Machbarkeit des neuen Verfahrens gezeigt werden. Mit diesen vier sehr unterschiedlichen Kunststoffen ist ein Weg aufgezeigt worden, der es ermöglicht, langfristig eine breite Palette an Kunststoffen mit diesem neuen Verfahren zu sintern. Nach einigen Adaptionen in der Anlagentechnik wurde gezeigt, dass grundsätzlich auch stabile und konturscharfe dreidimensionale Strukturen gesintert werden können. Die Optimierung von geringem Verzug bei gleichzeitig guten mechanischen Eigenschaften steht noch aus. Im Verbund mit anderen Forschungsinstituten wurden auch Verfahrenskombinationen des Selektiven Lasersinterns mit anderen Technologien getestet. Dabei hat sich besonders das nachgeschaltete Metallbeschichten als zukunftsträchtige Variante erwiesen. Das am IKP neu entwickelte Verfahren, mit dem Nd:YAG-Laser Thermoplaste zu sintern, hat in den durchgeführten Studien sehr großes Potenzial gezeigt. Viele Einflussparameter sind allerdings zurzeit nur wenig oder gar nicht untersucht. Ein wichtiger Faktor ist z. B. das Koppelmedium. Während am IKP bisher nur Ruß untersucht wurde, sind aus dem Gebiet des Laserbeschriftens und Laserschweißens auch andere Additive bekannt, die im Bereich des Nd:YAG-Lasers sensitiv sind. Zur Verbesserung der Eigenschaften wären auch Nanotubes als Additiv denkbar. Hier eröffnet sich damit ein weites Feld weiterer Möglichkeiten. Der höchste Optimierungsbedarf ist allerdings nach wie vor im Zusammenspiel der mechanischen Eigenschaften und möglichst geringem Verzug. In diesem Bereich muss insbesondere die Anlagentechnik weiter optimiert werden. Längerfristig wäre eine Anlagentechnik denkbar, die multifunktional ist und mit der beliebige thermoplastische Kunststoffe lasergesintert werden können. Es sind dann sogar Werkstoffverbunde denkbar, bei denen bei einer bestimmten Bauhöhe das Pulver umgestellt werden kann. Dies kann man sich auch örtlich, beispielsweise an Krafteinleitungspunkten, vorstellen. Durch intelligentes, gezieltes Zudosieren eines zweiten Pulvers oder Verstärkungsstoffes könnten Eigenschaftssprünge zwischen verschiedenen Werkstoffen beziehungsweise Kunststoffen vermindert oder vermieden werden. Eine solche Anlage könnte ganz neue Möglichkeiten der Gestaltung bieten.

444


5.11 Prototypwerkzeuge und Prototypbauteile Entwicklung und Herstellung von Prototypwerkzeugen und Prototypbauteilen Die Herstellung von Bauteilen mittels der Verfahren der Blechumformung machen in der Regel aufwändige Betriebsmittel notwendig. Aufgrund der Komplexität der Bauteile müssen häufig mehrere Fertigungsstufen durchlaufen werden. Die Entwicklungs- und Herstellungsprozesse der dafür notwendigen Werkzeuge sind zeitintensiv und erstrecken sich häufig über einen Zeitraum von mehreren Monaten. Beim Einsatz von PrototypWerkzeugsystemen und Beschränkung auf die formgebenden Operationen lassen sich Prototypteile unter geringerem Aufwand in kurzer Zeit anfertigen. Die hier durchgeführten Forschungsarbeiten beschränken sich auf die Verfahren der Blechumformung und unterteilen sich in Werkzeugentwicklung und Werkzeugherstellung. In beiden Fällen steht die Beschleunigung des Prozesses im Vordergrund. In den vergangenen Jahren ist die Prozesssimulation wesentlich verbessert worden. Das hat auch dazu geführt, dass ihr Einsatz im Werkzeugund Bauteilentwicklungsprozess stark zugenommen hat. Werden für frühe Machbarkeitsstudien nahezu ausschließlich virtuelle Prototypen verwendet, müssen reale Prototypwerkzeuge den späteren Serienprozess möglichst genau abbilden. Dies bedeutet vor allem, dass die mittels Prototypwerkzeugen hergestellten Prototyp-Umformteile in ihren Eigenschaften den Serienteilen entsprechen sollen. Hierdurch erreicht man eine Verifizierung der Ziehanlagengeometrie und Prototypteile mit Serienbauteileigenschaften. Diese können daher für Crashuntersuchungen und Belastungstests mit höherer Genauigkeit eingesetzt werden. Außerdem ist es möglich, den Anlauf der Serienwerkzeuge durch die Fertigung von Bauteilen mit dem Prototypwerkzeug zu unterstützen. Eine Voraussetzung, Zeit und Kosten während der Werkzeugentwicklung zu sparen, ist das Vermeiden von Iterationsschleifen, die auf nicht fertigungsgerechte Bauteilauslegung und –konstruktion zurückzuführen sind. Um dies zu erreichen, sind bereits zu einem frühen Zeitpunkt der Produktentwicklung Entwicklerteams aus unterschiedlichen Fachbereichen und auch Fachleute, die sich mit nachfolgenden Fertigungstechnologien befassen, in den Entwicklungsprozess einzubeziehen.

5.11 Prototypwerkzeuge und Prototypbauteile

445

5.11.1 Werkstoffe für Prototyp-Werkzeuge Abb. 5.73 zeigt eine Einteilung der zur Herstellung formgebender Prototypwerkzeuge in der Praxis üblichen Werkzeugstoffe in Anlehnung an das Ordnungssystem der Werkstoffe.

Abb. 5.73. Einleitung der Werkstoffe für Prototyp-Blechumformwerkzeuge [5.66]

5.11.2 Grauguss Grauguss, auch als „Gusseisen mit Lamellengraphit“ bezeichnet, wird seit vielen Jahren als Werkstoff für Großwerkzeuge verwendet. Die Gründe lagen zunächst in den begrenzten Möglichkeiten der mechanischen Bearbeitung. Erst später entdeckte man die für Ziehwerkzeuge vorteilhaften guten Reibungs- und Notlaufeigenschaften von Grauguss [5.72]. Verantwortlich hierfür sind die kohlkopfartigen und im Schliffbild als lamellar sichtbaren Graphiteinschlüsse im Grundgefüge aus Eisen (Fe), Eisencarbid (Fe3C) und Graphit (C) [5.134]. Die Zugfestigkeit, nicht die chemische Zusammensetzung, der unlegierten Graugusssorten war bis 1997 nach DIN 1691 und ist heute nach DIN EN 1561 genormt. Die für Umformwerkzeuge wichtigsten Eigenschaften sind in der DIN EN 1561 dargestellt. Zur Steigerung der Härte und somit auch der Verschleißbeständigkeit wird Grauguss für den Serienwerkzeugbau mit Chrom (Cr), Molybdän

446


(Mo) und Vanadium (V) legiert. Die VDI- Richtlinie 3388 (Ausgabe 1983 und 1999) „Werkstoffe für Schneid- und Umformwerkzeuge“ schreibt den Gehalt an Legierungselementen vor und enthält Angaben über Zugfestigkeit und Härte der Graugusssorten. Im Gegensatz zu Serien-Werkzeugen wird bei Prototypwerkzeugen aufgrund der niedrigen Gesamtstückzahl und aus Kostengründen auf Legierungselemente verzichtet und unlegierter Grauguss GG25 (EN-GJL-250) verwendet. Prototypwerkzeuge aus Grauguss GG25 werden eingesetzt, wenn eine höhere Verschleißbeständigkeit gefordert wird. Sie erlauben die Herstellung höherer Stückzahlen oder auch Kleinserien. Ferner ermöglicht dieses Werkzeugsystem das Ziehen von Außenhautteilen mit hervorragenden Oberflächen und gestattet aufgrund gleicher Ausführung der Ziehrahmen eine Übertragbarkeit der Werkzeuganlage auf die Serien- Werkzeuge [5.67]. 5.11.3 Stahl und Aluminium Stahl und Aluminium werden insbesondere in Form von Halbzeugen im Prototypwerkzeugbau für Werkzeugteile bei geringem Zerspanungsaufwand verwendet. Für den Werkstoff Aluminium sprechen die geringe Dichte und die leichte Zerspanbarkeit. Nachteilig ist der im Vergleich zu Stahl hohe Preis des Werkstoffes. Für relativ geringe Gesamtstückzahlen genügen aus der Gruppe der Stahlwerkstoffe Baustähle den Anforderungen des PrototypWerkzeugbaus. Sie werden häufig einerseits zur Werkzeugherstellung für Fahrwerksteile und andererseits für ebene Niederhalter bei Werkzeugen in Mischbauweise verwendet. 5.11.4 Niedrigschmelzende NE- Schwermetall-Legierungen Metalle, die eine größere Dichte als 5 kg/dm3 aufweisen, werden als Schwermetalle bezeichnet. Diese lassen sich nach (Werkstoff-Handbuch 1960) [5.27] in hochschmelzende und niedrigschmelzende Metalle einteilen. In der Technik haben die niedrigschmelzenden Metalle in legierter Form breite Anwendung als Weichlote (DIN EN 29453/ DIN 1707), Lagermetalle (DIN 4381), Zinnlegierungen für Gussstücke (DIN EN 611), Zinklegierungen für Gussstücke (DIN EN 1244/ DIN 1743), Schriftmetalle (DIN16312), Blei- Druckgusslegierungen (DIN 1741), Hartblei (DIN EN 12548/ DIN 17640- 2), Akkumulatorenblei (DIN EN 12548/ DIN 17640-


447

9), Zinnlegierungen und Zinngerät (EN 611) gefunden und sind größtenteils nach EN bzw. DIN genormt. Allein durch Legierungen der Elemente Cadmium (Cd), Zinn (Sn), Blei (Pb) und Bismut (Bi) können sechs binäre Eutektika, vier ternäre Eutektika und ein quaternäres Eutektikum, d.h. Legierungen mit definiertem niedrigen Schmelzpunkt, abgeleitet werden. Die wichtigsten binären Zustandsdiagramme niedrigschmelzender Legierungen sind in Ternary Alloys [5.27], [5.67] enthalten. Die Materialeigenschaften der genannten Legierungen werden häufig noch durch Zulegieren mit den Metallen Aluminium (Al), Antimon (Sb), Indium (In) und Kupfer (Cu) verändert. Eutektische Legierungen zeichnen sich dabei durch einen niedrigen, definierten Schmelzpunkt, eine dünnflüssige Schmelze und durch ein feinkörniges Gefüge aus. Sie sind somit für den Gießprozess hervorragend geeignet. Im Prototypwerkzeugbau werden zur Herstellung von formgebenden Blechumformwerkzeugen vorwiegend Bismut-Zinn- und FeinzinkLegierungen verwendet [5.67]. 5.11.5 Kunststoffe, Polyamide und Photopolymere In den 50er Jahren wurden Kunststoffe im Betriebsmittelbau zur Übertragung der räumlichen Geometrie des Urmodelles auf Kopier- bzw. Tuschiermodelle eingesetzt. Epoxidharze waren hierfür aufgrund des geringen Schwunds bei der Aushärtung und der relativ hohen Festigkeit hervorragend geeignet. Später wurden sie auch zur Herstellung von Prototypziehwerkzeugen verwendet. Die Harze der Werkzeugwirkfläche werden hierfür in der Regel mit Stahlpulver gefüllt, die des Werkzeughinterbaus hingegen mit Quarzsand. Wegen des Füllstoffzusatzes Quarzsand werden sie häufig auch als Polymerbetonwerkzeuge bezeichnet. Aufgrund der unzureichenden mechanischen Belastbarkeit des Quarzsandhinterbaus werden diese Werkzeuge häufig mit Stahlrahmen gekoffert oder mit Stahleinlagen bzw. Zugankern verstärkt [5.67]. In den 70er Jahren wurden dann Polyurethanharze aufgrund ihrer Zähigkeit erstmals mit Erfolg für Klopfmodelle eingesetzt. Im weiteren Verlauf wurden sie auch zunehmend als Werkzeugstoff für Prototypwerkzeuge verwendet. In dieser Anwendung verdrängten sie in den 90er Jahren auch teilweise die kostengünstigeren Epoxidharze [5.39]. In der Forschung wird darüber hinaus auch der Einsatz von Photopolymeren in Form von Acrylaten und Epoxidharzen zur generativen Herstellung von Prototypwerkzeugen untersucht.

448


Neben den erwähnten duroplastischen Gießharzen stehen dem Hersteller von Prototypwerkzeugen heute auch sogenannte Blockmaterialien zur Verfügung. Darunter versteht man vom Kunststoffhersteller zu Blöcken und Platten vorgegossene Kunststoff-Halbzeuge, die in der Regel aus Epoxidund Polyurethanreaktionsharzmassen beim Hersteller gegossen werden. Da die Werkzeugkontur am Halbzeug aufgebracht wird, eignen sich hierfür auch Materialien, die bei der Aushärtung der Formstoffe schwinden. Dies erklärt auch, warum selbst Polyamid-Blockmaterialien und phenolharzverleimtes Schichtpressholz, auch Obo-Holz genannt, Eingang in den Werkzeugbau gefunden haben. Prinzipiell lassen sich synthetisch hergestellte Kunststoffe nach Art der Verkettungsreaktion in Polymerisate, Polykondensate und Polyaddukte einteilen. Bei den im Werkzeugbau vorwiegend verwendeten EP- und PURFormstoffen handelt es sich um Polyaddukte. Polyamide (PA) und Phenolharze (PF) sind hingegen Vertreter der Polykondensate. Der Formstoff entsteht durch die exotherme Verkettungsreaktion von Harz und Härter aus der Reaktionsharzmasse (s. Abb. 5.74.):

Abb. 5.74. Exotherme Verkettungsreaktion von Harz und Härter [5.67]

Die gebräuchlichsten Epoxidformstoffe (EP) sind Polyaddukte aus den Ausgangsstoffen Epichlorhydrin und Disphenol (s. Abb. 5.75.). Kennzeichnend für Epichlorhydrin ist der instabile Dreiring, der auch für die Reaktionsfreudigkeit der Epoxidharze verantwortlich ist [5.1].

Abb. 5.75. Epichlorhydrin (links) und Disphenol (rechts) – Ausgangsstoffe der Epoxidharze [5.67]

Die beiden Komponenten reagieren im Beisein von überschüssiger Natronlauge (NaOH) zu Diglycidylether. In Abhängigkeit vom eingesetzten Mengen (Mol)-Verhältnis der Ausgangskomponenten erhält man Produkte


449

unterschiedlicher Molekülgröße. Mit steigender Kettenlänge nimmt das Molekulargewicht und die Viskosität zu. Die Eigenschaften der Epoxidformstoffe sind durch die Vielzahl der einsetzbaren Verbindungen, Vernetzersubstanzen, Füllstoffe und Verstärkungsmaterialien weitveränderbar [5.60]. Polyurethanformstoffe (PUR) entstehen durch Polyaddition von Isocyanaten (R-NCO) und mehrwertigen Alkoholen (R-OH, Polyol) (s. Abb. 5.76. [5.44])

Abb. 5.76. Polyaddition von Isocyanat und Polyol zu Urethan [5.44], [5.67]

Die Art der Vernetzung (linear oder räumlich) ist abhängig von der Anzahl der Moleküle der Ausgangsstoffe. Auf diese Art lassen sich Thermoplaste, Elastomere sowie Duroplaste unterschiedlicher Eigenschaften herstellen. Als Polyamide (PA) bezeichnet man polymere Stoffe, die in ihren Kettenmolekülen in stetiger Reihenfolge die Amidgruppe enthalten (s. Abb. 5.77.).

Abb. 5.77. Amidgruppe [5.67]

Sie können entweder aus einem Ausgangsstoff (Caprolactam bei PA 6) oder zwei Ausgangsstoffen (Diamine und Dicarbonsäure bei PA 6.6) aufgebaut sein. Die Formstoffe entstehen im Gegensatz zu EP- und PURFormstoffen durch Polykondensation. Zur Unterscheidung der Polyamide wird dem Gattungsnamen PA im Falle eines Ausgangsstoffes die Anzahl der Kohlenstoffatome zwischen jeweils zwei, in der Polymerkette aufeinanderfolgenden Stickstoffatomen angehängt. Bei zwei Ausgangsstoffen hingegen gibt die erste Zahl nach der Gattung PA die Anzahl der Kohlenstoffatome der Diamine an, die zweite Zahl die Anzahl der Kohlenstoffatome der Dicarbonsäure [5.60], [5.69]. Bei den für den Werkzeugbau erhältlichen Blockmaterialien handelt es sich um Gusspolyamid PA 6-G. Der Formstoff entsteht durch Polymerisation eines Reaktionsgemisches aus Caprolactam und einem Katalysator in einer beheizten Form [5.69].

450


Grundsätzlich richten sich die mechanischen Eigenschaften der Polyamide nach dem PA-Typ, der Kristallinität und dem Wassergehalt. Bei hoher Kristallinität sind die Formstoffe steif und hart, nach Wasseraufnahme sehr zäh. Polyamide verfügen über gute Gleiteigenschaften, sind abriebfest, schweißbar und gut spanbar. Bei Photopolymeren erfolgt die Verknüpfung einzelner Monomere zu Makromolekülen durch Polymerisation. Hierbei entsteht aus einem flüssigen Gemisch von Monomeren (Einzelmolekülen) ein verketteter, ausgehärterter Formstoff. Die Kettenreaktion wird dabei durch Einwirkung von UV- Strahlung ausgelöst. Photopolymere spielen als Gießharze bei Stereolithographieverfahren eine entscheidende Rolle. In Form von Acrylaten und Epoxidharzen werden sie hierbei mittels eines Laser-Strahls ausgehärtet [5.67]. 5.11.6 Werkzeugentwicklung Den zentralen Punkt im Prototyp-Werkzeugentwicklungsprozess für Blechumformwerkzeuge stellt die Entwicklung der Ziehanlage dar. Darunter sind vor allem die Stempelergänzungs- und Ziehrahmenflächen zu verstehen. Eine falsche Auslegung der Prototypwerkzeugpaarung Niederhalter und Matrize bedeutet, dass die Prototyp-Teile nicht oder nur mit erheblichen Schwierigkeiten bzw. mit hohem Ausschuss gefertigt werden können. Da Prototypwerkzeuge auch dazu dienen, die Anlage von SerienWerkzeugen fertigungstechnisch abzusichern, beeinträchtigt und verzögert eine falsche Auslegung des Prototypwerkzeugs auch den Entwicklungsund Herstellungsprozess von Serien-Werkzeugen. Die Einarbeitung von Tiefziehwerkzeugen erfolgt in der Regel durch manuelles Tuschieren. Beim Tuschieren werden die Werkzeughälften so aufeinander abgestimmt, dass über erhöhte oder verminderte Flächenpressungen und in der Folge hiervon erhöhte oder verminderte Reibungskräfte der Werkstofffluss unter dem Niederhalter gesteuert werden kann. Hierbei wird das Werkzeug an unterschiedlichen Stellen ’weich’ und ’hart’ tuschiert. Beim Weichtuschieren wird an Stellen, an denen der Werkstofffluss begünstigt werden soll und somit weniger Flächenpressung notwendig ist, auf der Werkzeugoberfläche mehr Material abgetragen als beim Harttuschieren. Beim Harttuschieren soll durch hohe Reibungskräfte der Werkstofffluss unter dem Niederhalter behindert werden. Deshalb wird eine höhere Flächenpressung benötigt und weniger Material abgetragen. Ein Problem stellt dabei außer dem benötigten Erfahrungswissen auch die Veränderung der Flächenpressungsverteilung unter dem Niederhalter aufgrund


451

von Verschleißerscheinungen oder Werkstoffdifferenzen während des Prozesses dar. Dieser Verschleiß kann dazu führen, dass ein erneutes Tuschieren erforderlich wird. Insgesamt ist das Tuschieren ein sehr zeitaufwändiger und kostenintensiver Prozess, für den geschultes und hochqualifiziertes Personal notwendig ist, und der nicht eindeutig reproduzierbar ist. Dadurch ist auch eine Übertragbarkeit vom Prototyp- auf das spätere Serien-Werkzeug nur beschränkt möglich. Ziel für den Prototypen-Werkzeugbau sollte ein Werkzeugkonzept sein, welches ein Eintuschieren auf ein Minimum reduziert oder sogar überflüssig macht. Des Weiteren sollte auf verschleißbeständigere Werkstoffe oder Beschichtungen verzichtet werden können. Auf verschleißbedingte Änderungen der Werkzeugoberfläche sollte schnell und einfach reagiert werden können. Wichtig ist, dass bereits im Prototypstadium Umformteile erzeugt werden können, die den späteren Serienteilen in ihren Eigenschaften entsprechen. Aus diesem Grund wurde ein hierfür sehr vielversprechendes Werkzeugkonzept, das am Institut für Umformtechnik entwickelt wurde, für die Prototypenwerkzeugherstellung überprüft. Im Gegensatz zu konventionellen Werkzeugkonzepten, bei denen Niederhalter und Matrize sehr steif ausgeführt werden und die unterschiedlichen Flächenpressungen wie oben aufgeführt mittels Tuschieren realisiert werden, ist das Prinzip hier geändert. Das Werkzeug besteht aus einer möglichst steifen Matrize und einem segmentelastischen Niederhalter. Der segmentelastische Niederhalter ist aus Pyramidenstümpfen, die durch Platten miteinander verbunden sind, aufgebaut (s. Abb. 5.78.).

Abb. 5.78. Prinzip des segmentelastischen Niederhalters [5.141]

452


Die obere Platte wirkt dabei zwischen den Pyramidenstümpfen als elastisches Gelenk. Man ist somit in der Lage, über das Ziehkissen partiell unterschiedliche Niederhalterkräfte in die unterschiedlichen Segmentflächen einzuleiten. Die Flächenpressungen in den Nachbarbereichen werden hierdurch kaum beeinflusst [5.78]. Im Vergleich zur konventionellen Niederhalterkonstruktion ermöglicht dies die gezielte Steuerung der Niederhalterflächenpressung und somit des Materialflusses in bestimmten Niederhalterbereichen [5.141]. Durch diese Werkzeugbauweise entfällt das ansonsten gerade bei Werkzeugen für die Prototypteilefertigung unerwünschte Tuschieren. Durch die gezielte Einstellung der Pinolenkräfte lässt sich die Flächenpressung und somit der Materialfluss ohne eine weitere Bearbeitung der Werkzeugwirkflächen verändern. Hierbei spielt es keine Rolle, ob die Niederhalterkräfte über ein Vielpunktziehkissen der Presse oder über eine in das Werkzeug integrierte Vielpunktzieheinrichtung eingeleitet werden. Allerdings ist für die Verteilung der Flächenpressung unterhalb des Niederhalters nicht nur die Ausführung des Niederhalters ausschlaggebend. Es muss zusätzlich die Bauweise der Matrize, d.h. der Gegenfläche, mit in Betracht gezogen werden. Für eine systematische Untersuchung werden die Matrize-NiederhalterSysteme in idealisierte Segmente zerlegt. Diese Matrizen- und Niederhaltersegmente haben kubische Abmessungen und sind jeweils einer Niederhalterkraft FN zugeordnet (s. Abb. 5.79.).

Abb. 5.79. Segmentweise Betrachtung von Matrize-Niederhalter-Systemen [5.68]

Zur Beurteilung der Verteilung der Flächenpressung pz(x,y) zwischen Blech und Niederhalter sowie zwischen Blech und Matrize am Ziehteilflansch wird als Referenz die mittlere Flächenpressung p z herangezogen,


453

die bei einer gleichmäßigen Verteilung in der gesamten Kontaktfläche vorliegen würde. Es ist die mittlere Flächenpressung eines Segments

pz

1 AS

³

p z x, y dA

As

FN AS

(1)

Sie errechnet sich als Verhältnis der Niederhalterkraft FN zur Querschnittsfläche AS des Matrize-Niederhalter-Segments. Alle weiteren Angaben über die Flächenpressung werden auf die mittlere Flächenpressung bezogen. Somit werden definiert: Maximale relative Flächenpressung

pmax

Minimale relative Flächenpressung

pmin

p z , max

100% (2)

pz

p z , min pz

100%

(3)

relative Flächenpressungsdifferenz

'p

p z , max p z , min pz

100%

pmax pmin

(4)

Die relative Flächenpressungsdifferenz 'p wird als Beurteilungskriterium herangezogen. Zusammen mit der graphischen Darstellung der Flächenpressungsverteilung kann eine Aussage über die Gleichmäßigkeit der Flächenpressung in der Kontaktfläche gemacht werden. Je geringer 'p ist, um so weiter nähern sich pmax und pmin der mittleren Flächenpressung

pz an. Ist die minimale relative Flächenpressung pmin nahezu 0, so besteht die Gefahr, dass das Werkzeug lokal vom Blech abhebt, was unter anderem zu Faltenbildung führen kann. Als weiteres Beurteilungskriterium wird die relative Segmentmasse

m

M S , verrippt M S , massiv

100%

(5)

454


als Verhältnis der Masse der verrippten Segmentvariante MS,verrippt zur Masse eines unverrippten Matrize-Niederhalter-Segments MS,massiv herangezogen [5.68]. Als Niederhalter- und Matrizenbauformen wurden folgende Geometrien untersucht (s. Abb. 5.80.).

Abb. 5.80. Untersuchte Segmentformen [5.68]

Als Referenz dient eine massive Matrizen-Niederhalterpaarung (Abb. 5.81 / Paarung 1) mit einer relativen Segmentmasse von 100% und einer relativen Flächenpressungsdifferenz von 10% (Abb. 5.81.). Paarung Niederhalter

1

2

3

4

5

6

7

178 0 178 51,8

139 67 72 61,0

129 65 64 74,9

Matrize Flächenpressungsverteilung pmax [%] 106 588 275 210 pmin [%] 96 0 0 0 ¨p [%] 10 588 275 210 Masse m 100 47,9 58,3 51,8 [%] pmax maximale relative Flächenpressung. pmin minimale relative Flächenpressung. ¨p relative Flächenpressungsdifferenz.

Abb. 5.81. Vergleichende Betrachtung von Niederhalter-Matrize-Paarungen [5.68]


455

Die konventionellen Werkzeugverrippungen (Abb. 5.81. / Paarung 2 und 3) bewirken hohe Gewichtseinsparungen. Allerdings ergeben sich hinsichtlich der Flächenpressung am Ziehteilflansch starke Unterschiede. So treten dort, wo sich zwei Vertikalrippen der Matrize und des Niederhalters gegenüberstehen, sehr hohe Flächenpressungen auf, wohingegen zwischen den Vertikalrippen nahezu keine Flächenpressung vorliegt. Die Folge hiervon ist, dass in Bereichen mit hoher Flächenpressung das Material stark zurückgehalten wird, also auf das Blech eine starke Rückhaltekraft, und in Bereichen mit niedriger Flächenpressung auf das Blech wenig Rückhaltekraft wirkt. Außerdem wird in den Bereichen mit geringer Flächenpressung die Faltenbildung 1. Art begünstigt [5.148]. Um diese ungünstige Flächenpressungsverteilung zu reduzieren, müssen die Kontaktflächen von Matrize und Niederhalter eintuschiert werden. Der Materialfluss wird dabei solange lokal durch Anpassen der Flächenpressung optimiert, bis ein Gutteil gefertigt werden kann. Dieser arbeitsintensive Vorgang des Einarbeitens, der insbesondere bei engen Verfahrensgrenzen viel Kenntnis über den Umformvorgang erfordert, kann mit einer verbesserten Werkzeugverrippung erheblich reduziert werden. Wie aus Abb. 5.81 ersichtlich ist, weisen die Werkzeugpaarungen mit segmentelastischem Niederhalter (Paarung 4 bis 7) gegenüber den konventionellen Werkzeugpaarungen geringere Werte der relativen Flächenpressungsdifferenz auf. Die Paarung segmentelastischer Niederhalter und prismatisch verrippte Matrize (Paarung 6) ist ein sehr guter Kompromiss bezüglich relativer Werkzeugmasse (61%) und relativer Flächenpressungsdifferenz (72%). Bei Einsatz einer Vielpunktzieheinrichtung kann durch eine gezielte Veränderung einer einzelnen Niederhalterkraft partiell eine Erhöhung der Flächenpressung erreicht werden. Hierfür benötigt man einen Niederhalter, der zum einen in sich steif ist und die eingeleitete Kraft auf eine klar definierte Fläche übertragen kann, und zum anderen zwischen den mit Niederhalterkraft beaufschlagten Flächen so elastisch ist, dass die eingeleitete Kraft die Nachbarflächen nicht beeinflusst. Bei Verwendung konventioneller Niederhalter, die in Kasten- oder C-Profil Verrippung ausgeführt sind, ist dies nicht möglich. Diese Profile sind zu biegesteif ausgeführt und besitzen eine für diesen Zweck ungünstige Anordnung der Rippenwände. Ein segmentelastischer Niederhalter hingegen erfüllt diese Kriterien und ist für den Einsatz auf Vielpunktzieheinrichtungen bestens geeignet. Konventionell verrippte Matrizen besitzen zwar eine hohe Steifigkeit, können aber, wie oben gezeigt, die Flächenpressung nicht gleichmäßig verteilen. Zwar erfüllt die massive Matrize diese Kriterien genauso wie die prismatisch verrippte Matrize, aber auf Grund ihres großen Gewichtes ist sie eher nicht in Betracht zu ziehen. Der Einsatz einer prismatisch verripp-

456


ten Matrize ist hier die beste Alternative. Die Anwendung obiger Ergebnisse steigert zwar den Herstellungsaufwand der Prototyp-Werkzeuge, ermöglicht allerdings die Herstellung von Prototyp-Blechformteilen, die in ihren Eigenschaften den Serienteilen entsprechen. Die systematisierte Auslegung des segmentelastischen Niederhalters in Verbindung mit einer verrippten Struktur der Matrize stellt eine wesentliche Verbesserung des Konstruktions- und Auslegungsprozesses bei beachtlich reduzierter Werkzeugeinarbeitungszeit dar. 5.11.7 3D-Visualisierung der Werkzeugkonstruktion Wie in Kap. 5.5 „Virtuelle und Hybride Prototypen“ beschrieben, ist ein Schwerpunkt der hier durchgeführten Untersuchungen die Verbesserung der Werkzeugentwicklung durch den Einsatz der Virtuellen Realität. Hierzu ist es zunächst notwendig, die Werkzeugkonstruktion in die 3DVisualisierung mittels Virtual Reality (VR) zu integrieren und daraus entstehende Vorteile abzuleiten. Im bisherigen Konstruktionsprozess wird vor der Freigabe der Konstruktion von der Ziehanlagengeometrie meist ein Styropormodell hergestellt. Anhand dieses Modells können dann die Konstrukteure die Werkzeuggeometrie diskutieren und gegebenenfalls Änderungen vornehmen. Für ein Abtragen von Werkstoff werden meist Messer oder Sägen eingesetzt. Als Anbauwerkstoff kann Knetmasse verwendet werden. Im Vergleich zum CAD-Modell auf dem Bildschirm oder der ausgedruckten CAD-Zeichnung ist es anhand des Styropormodells wesentlich einfacher möglich, die 3D-Flächen mit mehreren Personen zu betrachten und zu diskutieren. Dieser Prozess hat jedoch verschiedene Nachteile. Die Herstellung des Modells ist mit Kosten- und Zeitaufwand verbunden und die Vorgehensweise ist nicht rechnerbasiert. Die veränderte Werkzeuggeometrie muss digitalisiert werden, bevor mit der Werkzeugentwicklung bzw. – herstellung fortgefahren werden kann. Hinzu kommt, dass die Diskussion nur vor Ort am vorhandenen Modell durchgeführt werden kann. Sollen externe Experten oder Personen in die Diskussion einbezogen werden, ist das wiederum mit Zeit- und Kostenaufwand verbunden. Es wäre wünschenswert, den kompletten Prozess rechnerbasiert durchführen zu können, wobei hierfür ein möglichst plastischer Eindruck der Werkzeuggeometrie unumgänglich ist. Weiterhin ist es notwendig, die Konstruktion mit mehreren Personen auch an unterschiedlichen Orten gleichzeitig zu betrachten.


457

All diese Forderungen werden von der 3D-Visualisierung mittels der Technologie der Virtuellen Realität erfüllt. Durch den Einsatz der 3DVisualisierung anstatt spanend hergestellter Styropormodelle wird es möglich, die aktuellen Geometriedaten schnell in die VR-Umgebung zu integrieren und auch komplexe Bewegungsabläufe innerhalb eines Werkzeuges deutlich darstellen zu können. Dies ist mit Styropormodellen nicht oder nur sehr begrenzt möglich. Als Vorteile des Systems sind seine Mobilität sowie die verwendete PCTechnik herauszuheben. Da die Berechnung der darzustellenden Grafikdaten sehr rechenintensiv ist, waren für die Anwendung bisher teure Grafikworkstations notwendig. Die VR-Technologie ist durch einen beachtlichen Anstieg der Rechen- und Grafikleistung im PC-Bereich zunehmend interessanter geworden [5.28], [5.80]. Im Rahmen der Untersuchungen wurden verschiedene Werkzeuge mittels VR visualisiert. Es ist möglich, die Werkzeugkonstruktion und vor allem die Relativbewegung verschiedener Werkzeugteile zueinander zu betrachten und darauf basierend Änderungen vorzunehmen [5.141].

Abb. 5.82. Einrichtung zur 3D- Visualisierung am Institut für Umformtechnik

458


Vor allem bei komplexen Prozessabläufen ist es äußerst hilfreich, anhand von beliebigen Schnitten die Werkzeugbewegung nachvollziehen zu können und auch eine manuelle Kollisionsbetrachtung durchzuführen. 5.11.8 Visualisierung der Simulation des Umformvorgangs Eine Erweiterung der im vorigen Abschnitt beschriebenen Visualisierung der animierten Werkzeugkonstruktion stellt die Integration der FEMProzesssimulation in die VR-Umgebung dar. Diese erlaubt eine schnelle Bewertung des Prozessablaufes und der durchgeführten Änderungen am Werkzeug hinsichtlich der Beeinflussung des Umformvorgangs. Schon sehr früh im Entwicklungsprozess können FEM-Prozesssimulationen die Werkzeugkonstruktion unterstützen (Abb. 5.83.).

Abb. 5.83. Einsatz der FEM-Prozesssimulation im Prototyp-Werkzeug-Entwicklungsprozess [5.141]

Bei so genannten Einschrittberechnungsverfahren wird, ausgehend von der Endgeometrie des Bauteils, in einem Schritt auf die Ausgangsgeometrie der Platine zurückgerechnet. Es reicht zur Prozesssimulation allein die Bauteilgeometrie. Eine exakte Abbildung des Umformprozesses ist mit Einschrittberechnungen nicht möglich [5.129], jedoch können einfach und schnell Machbarkeitsuntersuchungen, erste Platinenformfestlegungen und eine Gestaltung der Wirkflächen, insbesondere der Stempelergänzungsflächen und des Ziehrahmens, durchgeführt werden [5.141]. Ist die Werkzeug- bzw. Wirkflächenkonstruktion fortgeschritten, können genauere Berechnungen mit impliziten oder expliziten FEM-Tools durchgeführt werden. Diese sind verglichen mit den Einschrittverfahren


459

zwar rechenintensiver, liefern jedoch auch entsprechend höherwertigere Ergebnisse [5.82]. Die FEM-Simulation wird im Werkzeugentwicklungsprozess inzwischen immer häufiger als Ersatz des klassischen Prototyping eingesetzt. Soll die Simulation reale Prototypbauteile ersetzen, muss die Visualisierung der CAD-Daten und der Simulationsergebnisse als Diskussionsgrundlage dienen. Gefordert wird eine möglichst plastische Darstellung, die von mehreren Personen gleichzeitig und bequem betrachtet und diskutiert werden kann. Hierzu wurde eine Kopplung der visualisierten animierten 3DWerkzeugkonstruktion und der FEM-Prozesssimulation realisiert (Abb. 5.84.) [5.162].

Abb. 5.84. Mit der Visualisierung der Werkzeugkonstruktion verknüpfte FEMProzesssimulation [5.141].

Die Arbeit mit virtuellen Prototypen eröffnet zusätzlich die Möglichkeit des kollaborativen Arbeitens. Hierunter versteht man das Zusammenarbeiten örtlich voneinander getrennt arbeitender Teams an einer Datenbasis. Speziell im Bereich der Entwicklung von Werkzeugen für die Blechumformung, die sehr stark auf dem Erfahrungswissen der daran beteiligten Personen basiert, ist es von hohem Interesse, Expertenwissen nicht nur lokal verfügbar zu haben, sondern auch über größere Entfernungen entsprechendes Wissen in den Entwicklungsprozess integrieren zu können. Durch den Einsatz der VR-Technologie ist es möglich, den kompletten Werkzeugentwicklungsprozess rechnerbasiert durchzuführen. Die Integration der animierten Werkzeugkonstruktion in Verbindung mit der FEM-

460


Prozesssimulation stellt eine wesentliche Verbesserung des Konstruktionsprozesses von Prototypwerkzeugen für die Blechumformung dar. 5.11.9 Werkzeugherstellungsprozesse Da die Geometrie der Bauteile und die Ziehanlagen heute überwiegend am Bildschirm entwickelt werden und lediglich Datensätze die genannten Geometrien räumlich beschreiben, ist eine abformtechnische Herstellung von Werkzeugbauteilen ohne vorhergehende Zerspanung in der Regel nicht mehr möglich. Die zur Steuerung der Bearbeitungsmaschinen erforderlichen NC-Programme werden heute nach Abschluss der Konstruktion auf Basis des Werkzeugdatensatzes erstellt. Bei der nachfolgenden Anfertigung der Werkzeugteile lassen sich heute in der betrieblichen Praxis grundsätzlich drei Wege unterscheiden: x Fräsbearbeitung von Werkteilen aus Halbzeugen x Fräsbearbeitung von Gießmodellen für den Genauguss von Werkzeugteilen x Fräsbearbeitung von Gießmodellen für das konturnahe Vorgießen von Werkzeugteilen In der Regel sind mit den genannten Vorgehensweisen folgende Werkstoffe verbunden: Fräsbearbeitung von Werkzeugteilen aus Halbzeugen Kunststoffe (EP,PUR,PA) Aluminium Stahl

Fräsbearbeitung von Gießmodellen für den Genauguss von Werkzeugteilen Kunststoffe (EP,PUR) Bismut/ ZinnLegierungen [Feinzink- Legierung] (G-ZnAl4Cu3)

Fräsbearbeitung von Gießmodellen für das konturnahe Vorgießen von Werkzeugteilen Kunststoffe (EP,PUR) Freizink- Legierung G-ZnAl4Cu3 Grauguß EN-GJL-250

Abb. 5.85. Bearbeitung der untersuchten Werkstoffe

In der Dissertation [5.67] sind die Herstellungsprozesse in Abhängigkeit vom Werkstoff beschrieben worden. Die folgenden Ausführungen betreffen die Herstellung von Prototypwerkzeugen für die Blechumformung. Der Schwerpunkt liegt dabei in der Erprobung des Vakuumformverfahrens zur Herstellung von Gießformen.


461

Das Verfahren soll eine schnellere, kostengünstigere und umweltfreundlichere Fertigung von Gießformen für Umformwerkzeuge aus FeinzinkLegierungen (z.B. ZAMAK) ermöglichen [5.81]. 5.11.10 Optimierung des Prozesses durch Einsatz des Vakuumformverfahrens Aus der Beschreibung der Prozessschritte geht hervor, dass je nach Beschaffenheit der Modelle die Verfestigung der Form auf chemischem oder mechanischem Wege erfolgt. Steigende Entsorgungs- bzw. Wiederaufarbeitungskosten, lange Aushärtungszeiten der Formstoffe und der hohe Aufwand für die mechanische Bearbeitung der Werkzeugteile verstärken den Wunsch nach einer Prozessoptimierung. Die Alternativen zu den heute üblichen Formverfahren lassen sich aus der Einteilung der Formverfahren ableiten (s. Abb. 5.86.).

Abb. 5.86. Einteilung der Formverfahren [5.51]

Das Vakuum-Gießform-Herstellungsverfahren wurde 1971 von Yoshimasa Kubo und Nataka Kunii in der Leichtmetallgießerei Kabushiki Kaisha Akita in Nagano, Japan erfunden und weltweit zum Patent angemeldet (s. Abb. 5.87.).

462


Abb. 5.87. Schematischer Ablauf der Formherstellung mit dem Vakuumformverfahren [5.81]

Im VDG- Merkblatt R203 wird das Verfahren definiert als „Verfahren zur Herstellung von Formteilen aus binderfreiem, rieselfähigem Sand


463

durch Unterdruck in einem Formkasten“. Die Abdichtung des Formkastens zum Modell und nach außen erfolgt durch Kunststofffolien [5.156]. Der Unterdruck bleibt bis zum Erstarren der Schmelze in der Form bestehen. Abb. 5.87 zeigt das Verfahrensprinzip zur Erzeugung einer geschlossenen Gießform. Zu Beginn wird das HSC-gefräste Gießmodell auf der Modellplatte des Vakuumkastens befestigt. Die Modellplatte besteht entweder aus einer mit zahlreichen Düsen versehenen Schichtholzplatte oder aus einem porösen Werkstoff. Bei der am Institut für Umformtechnik (IFU) installierten Anlage besteht die Modellplatte aus einem mikroporösen DuroplastAluminium-Verbundwerkstoff. Dieser Werkstoff verfügt über eine richtungsabhängige Permeabilität für Gase und niedrigviskose Flüssigkeiten und ist ohne Porenverschluss spanend zu bearbeiten. Oberhalb der in einem Rahmen gespannten thermoplastischen Modellfolie befindet sich eine Flächenheizung, welche die Folie erwärmt und dadurch formbar macht. Nach dem Erwärmen der Folie wird diese auf das Modell abgesenkt. Der Vakuumkasten wird mit einem Unterdruck von 0,5 bis 0,6 bar beaufschlagt. Dabei legt sich die Folie an die Kontur des Modells an. Anschließend wird bei anhaltendem Unterdruck auf die Folie eine Schlichte aufgetragen. Der doppelwandige und an seiner Innenseite mit „Saugfenstern“ versehene Formkasten wird auf die Modelleinrichtung abgesenkt und mit feinkörnigem, binderfreiem Sand gefüllt. Danach wird der Sand durch Rütteln vorverdichtet. Das Formteil wird mit einer Kunststofffolie abgedeckt und der Unterdruck über den Formkasten in die Sandform eingeleitet. Nach Abschalten des Unterdrucks im Modellträger lässt sich das Formteil vom Modell abheben. Wird nicht in die offene Form gegossen, sondern eine zweite Formhälfte benötigt, kann diese auf die gleiche Weise erzeugt werden. Nach gegebenenfalls erforderlichem Einlegen von Kernen kann dann die zweiteilige Form zusammengesetzt werden. Der Unterdruck muss während des Gießens und Erstarrens der Schmelze aufrecht erhalten werden (s. Abb. 5.88.) [5.81].

464


Abb. 5.88. Vakuumformanlage am Institut

Anhand der durchgeführten Untersuchungen ergeben sich folgende Vorund Nachteile: Vorteile: x x x x x x x x x x

Umweltfreundlichkeit Geringe Formstoffkosten Billige Modellwerkstoffe Hohe Maßgenauigkeit Geringe Wandstärken erzielbar (verbesserte Fließstrecke) Hohe Oberflächengüte Geringe Putzkosten Geringe mechanische Belastung der Formkästen Bessere Arbeitsbedingungen Einfache Anlagetechnik Nachteile:

x x x x x x x

Hohe Investitionen bei geringer Formleistung Hoher Energieverbrauch Staubprobleme beim Entformen Lange Abkühlzeiten (hohe Isolationswirkung der Form) Auftrag von Schlichte erforderlich Erhöhter Aufwand durch Luftkanäle Lizenzgebühren


465

5.11.11 Tribologische Anforderungen an die Werkzeugwirkfläche Die Übertragbarkeit der aus dem Umformvorgang mit PrototypWerkzeugen resultierenden Bauteileigenschaften auf die Serienprodukteigenschaften erfordert eine identische Ziehanlage und den gleichen Materialfluss. Die Tribosysteme Niederhalter- Schmierstoff- Blech und BlechSchmierstoff- Matrize spielen in diesem Zusammenhang eine wesentliche Rolle. Letztlich sind gleiche Reibkräfte bei Prototyp- und Serienwerkzeugen zu fordern. Dies bedeutet bei gleicher Werkzeuggeometrie, aber unterschiedlichem Werkstoff, eine Anpassung des Schmierstoffes und/oder der Niederhalterpressung. Die Standzeit eines Werkzeugsystems und somit die Anzahl der damit anzufertigenden Blechformteile ist hingegen von der Verschleißbeständigkeit der Werkzeugfläche abhängig. Mit der Ermittlung von Reibungs- und Verschleißkennwerten wurde das Verhalten der Werkzeugstoffe charakterisiert. Bei der hier eingesetzten und am IFU entwickelten Streifenziehanlage wird ein ebener Blechstreifen auf einem Ziehschlitten fixiert und unter einem Ziehbacken, der mit einem definierten Niederhalterdruck gegen den Blechstreifen gepresst wird, hindurchgezogen (Abb. 5.89.). Die hierbei ermittelte Reibungszahl gilt für die gegebene Blech- und Werkzeugoberfläche, den verwendeten Schmierstoff, die aufgetragene Schmierstoffmenge, eine bestimmte Flächenpressung und Ziehgeschwindigkeit.

Abb. 5.89. Prinzip Streifenziehen ohne Umlenkung (a: beidseitig/ b: einseitig) [5.161]

466


Gemessen werden für verschiedene Niederhalterdrücke pN der Verlauf der Reibkraft FR über dem Ziehweg und daraus abgeleitet die Reibungszahl P. Die Anlage ist in der Dissertation [5.161] beschrieben. Zur Beurteilung der Reibungseigenschaften der Werkzeugstoffe dient hier einerseits die Höhe der Reibkraft und andererseits der Reibkraftverlauf in Abhängigkeit von der Flächenpressung. Die Versuchsbedingungen und Versuchsergebnisse sind in den Abb. 5.90 bis Abb. 5.97 dargestellt. Metalle Grauguss GG 25 Feinzink- Legierung G- ZnAl4Cu3 Bismut/ Zinn- Legierung Bi57Sn 43

Kunststoffe FGH- EP1 Epoxid- Frontgussharz (Gefüllt mit Eisenpulver) FGH- PUR1 Polyurethan- Frontgussharz (ungefüllt) FGH- PUR3 Polyurethan- Frontgussharz (ungefüllt)

Abb. 5.90. Untersuchte Werkstoffe [5.67]

Werkzeugstoff Mittlere Reibzahl Werkzeugstoff GG25 0,117 FGH- EP1 G-ZnAl4Cu3 0,073 FGH- PUR1 Bi57Sn43 0,142 FGH-PUR3

Mittlere Reibzahl 0,092 0,107 0,089

Abb. 5.91. Experimentell ermittelte mittlere Reibzahlen [5.67]

Grundsätzlich geht aus den Abb. 5.92 und 5.93 hervor, dass die Ziehbacken nach dem Poliervorgang unterschiedliche Oberflächentopographien aufweisen. Werkzeuge aus der Feinzinklegierung G-ZnAl4Cu3 lassen sich dabei am besten polieren. Der eingelagerte Graphit bei GG25 und die Füllstoffe der Kunststoffe vermindern ihre Polierfähigkeit und sind für die etwas höheren Rauheitswerte im Ausgangszustand verantwortlich. Auffällig ist der starke Anstieg der Rauheit der Ziehbackenoberfläche und der Einglättungsvorgang. nach lediglich einem Versuch bei Bi57Sn43. Dies lässt hohen abrasiven Verschleiß vermuten.


467

Abb. 5.92. Verlauf der Reibungskraft in Abhängigkeit von der Flächenpressung für metallische Prototyp-Werkzeugstoffe [5.67].

Abb. 5.93. Verlauf der Reibungskraft in Abhängigkeit von der Flächenpressung für metallische Prototyp-Werkzeugstoffe [5.67].

468


Metalle Grauguss GG 25 Feinzink- Legierung G- ZnAl4Cu3 Bismut/ Zinn- Legierung Bi57Sn 43

Kunststoffe FGH- EP1 Epoxid- Frontgussharz (Gefüllt mit Eisenpulver) FGH- PUR1 Polyurethan- Frontgussharz (ungefüllt)

Abb. 94. Untersuchte Werkstoffe

Abb. 5.95. Reibkraft in Abhängigkeit von der Anzahl der Züge für metallische Prototyp-Werkzeugstoffe [5.67].

Ordnet man die Werkstoffe nach der Reibzahl, so ergibt sich in Verbindung mit den beschriebenen Versuchsparametern überschlägig folgende Reihenfolge: Bi57Sn43, GG25, Kunststoffe, G-ZnAl4Cu3 [5.67]. Die Versuchsergebnisse lassen den Schluss zu, dass keiner der untersuchten Prototyp-Werkzeugstoffe ein mit dem Referenzwerkstoff GG25 identisches Reibverhalten aufweist.


469

Abb. 5.96. Rauheit RZDIN quer zur Ziehrichtung in Abhängigkeit von der Anzahl der Züge für metallische Prototyp-Werkzeugstoffe [5.67].

Abb. 5.97. Reibungskraft in Abhängigkeit der Anzahl der Züge für polymere Prototyp-Werkzeugstoffe [5.67]

470


Für die Praxis haben die Ergebnisse folgende Bedeutung: Aufgrund des gemessenen, niedrigeren Reibkraftniveaus bei Prototypwerkzeugen aus GZnAl4Cu3 und Kunststoffen, im Gegensatz zu Bi57Sn43 müssen in der Regel Maßnahmen ergriffen werden, um den Materialfluss zusätzlich zu hemmen. Die Erhöhung der Niederhalterkraft, eine der möglichen Maßnahmen, führt dabei automatisch zu einer höheren Werkzeugbelastung. Die unter bestimmten Versuchsbedingungen auftretenden, degressiven Reibkraftverläufe der Kunststoffe bei hoher Flächenpressung haben zur Folge, dass unter den gegebenen Bedingungen zur Erzielung höherer Reibungskräfte die Niederhalterkraft überproportional gesteigert werden muss [5.67]. 5.11.12 Charakterisierung des Verschleißverhaltens Der wesentliche Verschleiß an den Wirkflächen von Tiefziehwerkzeugen ist auf adhäsive und abrasive Verschleißvorgänge zurückzuführen. Die Beurteilung des Verschleißverhaltens erfolgte durch Messung des örtlichen Verschleißbetrages der Modellmatrize an der Ziehkantenrundung und in ihrem ebenen Bereich unter dem Niederhalter. Zur Messung wurden die genannten Bereiche der Modellwerkzeuge mit einem Tastschnittgerät quer zur Ziehrichtung vor und nach 100, 300, 500, 1000, 2000 und 5000 Hüben abgetastet und der Inhalt der verschlissenen Fläche anhand der Meßschriebe in mm2 bestimmt. Der Flächeninhalt der PolyurethanOberflächenharz Probe (OFH-PUR2) nach 5000 Hüben wurde als 100% Verschleiß definiert und alle übrigen Meßergebnisse in % zu dieser Fläche angegeben (s. Abb. 5.98., 5.99.). Abb. 5.93 und 5.94 zeigen die gemessenen Werte für den Verschleißbetrag unter dem Niederhalter in % über der Anzahl der Hübe, bezogen auf den Verschleiß des Werkzeuges aus dem Oberflächenharz OFH-PUR2. Die Profilschnitte der Ziehkantenrundung der Modellwerkzeuge senkrecht zur Ziehrichtung nach Abschluss der Versuche sind hingegen in Abb. 5.95 und 5.96 enthalten.


471

Abb. 5.98. Verschleißbetrag als Funktion der Hubzahl für metallische PrototypWerkstoffe [5.67].

Abb. 5.99. Verschleißbetrag als Funktion der Hubzahl für polymere PrototypWerkstoffe [5.67].

472


Abb. 5.100. Profilschnitt durch die Ziehkantenrundung metallischer PrototypWerkzeuge nach 5000 Hüben für G-ZnAl4Cu3 und nach 1000 Hüben für Bi57Sn43.

Abb. 5.101. Profilschnitt durch die Ziehkantenrundung polymerer PrototypWerkzeuge nach 5000 Hüben [5.67].

Beurteilt man die Profilschnitte durch die Ziehkante unabhängig von der Werkzeugstoffgruppe (Abb. 5.101.) und lediglich hinsichtlich der Verschleißbeständigkeit, schneidet der Werkzeugwerkstoff Polyamid (BM PA1), gefolgt von der Feinzinklegierung G-ZnAl4Cu3 (ZAMAK), am besten ab. In Kombination mit den hohen mechanischen Kennwerten wird hiermit die Tendenz der Feinzink-Legierung zu höheren Standzeiten bestätigt. Das Modellwerkzeug aus der eutektischen Bismut-Zinn-Legierung Bi57Sn43 zeigte hingegen im Test die schlechteste Verschleißbeständigkeit aller Werkstoffe. Die Versuchsreihe musste hier bereits nach 1000


473

Hüben abgebrochen werden. Durch Verwendung von Kunstharzen für den Frontguss auf Polyurethan- oder Epoxidharzbasis kann eine mittlere Verschleißbeständigkeit erzielt werden. Das Oberflächenharz OFH-PUR2 zeigt im Test innerhalb der Gruppe der polymeren Werkstoffe den höchsten Ziehkantenverschleiß. Die Darstellung des Verschleißes unter dem Niederhalter (Abb. 5.93. und Abb. 5.94.) bestätigt die Tendenzen aus Abb. 5.95 und Abb. 5.96, wobei hier das Verschleißverhalten der Frontgussharze FGH-EP1 und FGHPUR 1 mit dem der Feinzink-Legierung G-ZnAl4Cu3 nahezu identisch ist. Die weiteren Verschleißuntersuchungen sind in [5.67] dargestellt. 5.11.13 Einfluss des Prototypwerkzeugstoffes auf die Kriterien Prototyp-Teilequalität und Werkzeugstandzeit Ziel dieser Untersuchungen war es, die Auswirkungen der mechanischen und tribologischen Eigenschaften der Werkzeugstoffe auf die Teilequalität (Maßhaltigkeit, Festigkeit, Oberflächengüte) zu ermitteln. Um eine Beurteilung der Hestellungsprozesse von PrototypWerkzeugen und nachfolgender Vergleichsuntersuchungen zu ermöglichen, wurden drei Prototyp-Ziehwerkzeuge für dasselbe Ziehteil, eine Sitzkissenschale, aus verschiedenen Werkzeugstoffen und unter Berücksichtigung verschiedener Vorgehensweisen hergestellt. Nach der Werkzeugeinarbeitung folgte die Herstellung von je 100 Ziehteilen unter identischen Versuchsbedingungen. Die Versuchspresse verfügte über Messelemente zur Erfassung der Kraft-Wegverläufe für Stößelund Niederhalterkräfte, die ebenfalls in Abhängigkeit von der Teileanzahl ausgewertet wurden. Da die Maßhaltigkeit der Blechformteile (s. Abb. 5.97.) direkt mit der Verschleißbeständigkeit der Werkzeuge im Zusammenhang steht, wurden die Ober- und Unterteile der Werkzeuge nach der Werkzeugausprobe und nach der Fertigung von 100 Ziehteilen entlang der Schnitte A-A (s. Abb. 5.103.) und D-D (s. Abb. 5.104.) vermessen.

474


Abb. 5.102. Ausgewählte Profilschnitte für die Werkzeugvermessung und Ziehteilanalyse [5.67]

Abb. 5.103. Digitalisierte Radien am Werkzeug im Längsschnitt A-A [5.67].

Abb. 5.104. Digitalisierte Radien am Werkzeug im Längsschnitt D-D [5.67]

Abb. 5.105 zeigt die gemessenen Werkzeugradien an Stempel und Matrize. Sie zeigen eine hohe Verschleißbeständigkeit der Werkzeugstoffe GZnAl4Cu3 und BM-PA1.


Werkzeugstoff

Teilestückzahl

R2 Radien am R3 Stempel R6 (in mm) R7 R8 R11 R1 Radien an R4 der MatriR5 ze R9 (in mm) R10 Summe der Radien 1,4,5,6,7,8,9,11 (in mm)

G-ZnAl4Cu3 0 7,5 7,4 7,2 20,7 7,2 7,4 6,5 13,4 12,1 6,5 6,5 81

100 7,5 7,4 7,3 21 7,2 7,5 6,6 13,4 12,3 6,5 6,5 81,8

Bi57Sn43

0 6,0 17,9 15,1 6,8 6,7 13,4 14,0 7,1 87

100 6,6 18,3 16,7 7,0 6,9 14,0 15,5 7,2 92,2

475

BM-PA1

0 7,35 7,7 7,9 20,9 5,8 7,4 6,5 13,7 12,7 6,5 6,5 81,4

100 7,35 7,8 8,1 20,9 6,2 7,5 6,6 14 12,8 6,7 6,6 82,8

Abb. 5.105. Gemessene Radien am Werkzeug vor und nach Abschluß der Versuche [5.67]

Trotz des geringen Verschleißes am Werkzeug aus BM-PA 1 konnte die Einprägung aufgrund der geringen Drucksteifigkeit des Werkstoffes nur ungenügend ausgeprägt werden. Die weiteren Ergebnisse über die Bauteilfestigkeit und die Oberflächenqualität sind in der Arbeit von [5.67] dargestellt. 5.11.14 Segment-elastischer Niederhalter aus Kunstharz mit Pyramidenstumpfförmigen Stahl-Einsätzen Wie bereits ausgeführt bietet die Änderung der Flächenpressung während des Umformprozesses eine weitere Möglichkeit der Steuerung des Werkstoffflusses Wegen des geringen E-Moduls des Kunststoffs führt die Herstellung eines Niederhalters aus reinem Kunststoff zu großen Differenzen der Flächenpressung zwischen Blech und Niederhalter sowie zwischen Blech und Ziehring. Das kann zu geringen Flächenpressungen zwischen den Krafteinleitungspunkten bis hin zu Falten im Flanschbereich des Bauteils führen. Auch wird die Übertragbarkeit der Ergebnisse auf das Serienwerkzeug beeinträchtigt. Abb. 5.106 zeigt das CAD-Modell des Niederhalters. Hier besteht der Niederhalter aus einer Vielzahl kegelförmiger Metalleinsätze, die auf einer Grundplatte aus Stahl aufgeschraubt sind. Die Grundplatte dient der genauen Positionierung der Metalleinsätze, so dass jeder Krafteinleitungs-

476


punkt der Zieheinrichtung räumlich definiert ist. Vier Führungsplatten, die an den Metalleinsätzen und an der Grundplatte befestigt sind, gewährleisten die Führung des Niederhalters im Werkzeug während des Tiefziehens. Die Niederhalterwirkfläche wird an der größeren Seite der Metalleinsätze von einer ca. 30 mm dicken Kunststoffschicht gebildet.

Abb. 5.106. Niederhalter aus Polyurethan mit Metalleinsätzen [5.142]

Die Metalleinsätze fungieren in dieser Konstruktion als Kraftübertragungselemente, die Kraft von der Zieheinrichtung in die Niederhalterwirkfläche übertragen. Zwischen den Elementen wirkt das Kunstharz als Gelenk [5.142]. Durch den Einsatz eines segmentelastischen Niederhalters und der Anwendung von Mehrpunktzieheinrichtungen ist eine gezielte lokale Beeinflussung des Werkstoffes während des Tiefziehprozesses möglich, was neue Möglichkeiten zur Erzielung eines reproduzierbaren Umformprozesses und zur Verbesserung der Produktgüte eröffnet. Abb. 5.107 zeigt die Ergebnisse von der Vermessung der Flächenpressung unter dem Niederhalter.


477

Abb. 5.107. Vermessung der Flächenpressung unter dem segmentelastischen Niederhalter [5.102].

Erste Untersuchungen haben gezeigt, dass im Vergleich mit einem konventionellen segmentelastischen Niederhalter aus Grauguss tiefere Bauteile gezogen werden können (s. Abb. 5.108.). Die Oberflächenqualität des Bauteils wird verbessert [5.102].

Abb. 5.108. Erweiterung des Arbeitsbereichs der Blechhalterkraft bei der Verwendung eines Kunststoffniederhalters mit Metalleinsätzen [5.102].

478


Bei dem neuen Niederhalterkonzept wird eine neue Konstruktionsmöglichkeit für die Herstellung von Prototypteilen und den Anlauf der Serienproduktion präsentiert. Der Niederhalter wird hinsichtlich folgender Punkte untersucht: x Druckverteilung. x Einfluss des Kunststoffes: Mit dem neuen Niederhalterkonzept wurden verschiedene Kunststofftypen untersucht. Die Anwendung von thermoplastischen Kunststoffen ist wegen deren Reibungseigenschaften und des wirtschaftlichen Recyclings von Interesse. x die Möglichkeit, den Kunststoff nach der Benutzung des Niederhalters zu recyclen und die Metalleinsätze in einem neuen Niederhalter wieder verwenden zu können. Das Prinzip bietet neue Möglichkeiten für eine schnelle Werkzeugherstellung und Werkzeugänderung, wobei die Metalleinsätze für weitere Werkzeuge wiederverwendet werden können.

Literatur [5.1] AccessGrid Homepage http://www.accessgrid.org [5.2] Ahn SJ (2004) Least Squares Orthogonal Distance Fitting of Curves and Surfaces. In: Lecture Notes in Computer Science Vol 3151. Springer, Berlin u a (Dissertation.Universität Stuttgart) [5.3] Ahn SJ, Effenberger I, Fulga S (2004) Automated Segmentation and Object Recognition in 3D Data Sets. In: Computing and Solutions in Manufacturing Engineering COSME´04, Brasov, Romania [5.4] Ahn S, Rauh W, Cho HS, Warnecke HJ (2002) Orthogonal Distance Fitting of Implicit Curves and Surfaces. In: IEEE Transactions on Pattern Analysis and Machine Intelligence 24, Nr 5 [5.5] ARTESAS Homepage http://www.artesas.de [5.6] ARToolKit Homepage. http://www.hitl.washington.edu/artoolkit [5.7] ARVIKA Homepage http://www.arvika.de [5.8] Atwood C, Griffith ML, Harwell LD, Schlienger ME, Ensz MT, Smugeresky JE, Romero JA, Greene DL, Reckaway DE (1998) Laser engineered net shaping (LENS) - a tool for direct fabrication of metal parts. In: Proc. of the laser materials processing conference ICALEO'98, 16.-19. Nov. 1998, Orlando. Orlando: Laser institute of America, ICALEO 1998, S.E1-E7. [5.9] Azuma R (1997) A Survey of Augmented Reality. Presence: Teleoperators and Virtual Environments 6, 4, 355-385

Literatur

479

[5.10] Azuma R, Baillot Y, Behringer R, Feiner S, Julier S, MacIntyre B (2001) Recent Advances in Augmented Reality. IEEE Computer Graphics and Applications 21, 6, 34-47 [5.11] Backes G, Kreutz EW, Gasser A, Hoffmann E, Keutgen S, Wissenbach K, Poprawe R (1998) Laser-shape reconditioning and manufacturing of tools and machine parts. In: Proc. of the laser materials processing conference ICALEO'98, 16.-19. Nov. 1998, Orlando. Orlando: Laser institute of America, S.48-55. [5.12] Backes G, Kreutz EW, Wissenbach K (1995) Qualitätssicherung durch Regelung. F&E Nr.1, S.58-60. [5.13] Bauer W, Kern P, Haselberger F (2002): Emerging issues in the productive use of Virtual Environments In: 6th International Scientific Conference on Work With Display Units, May 22-25 2002, Berchtesgaden, Germany [5.14] Becker M, Wössner U (2005) Tangible Interfaces for Interactive Flow Simulation. The 2nd Russian-German Advanced Research Workshop on Computational Science and High Performance Computing [5.15] Biesinger B, Grzesiak A (2004) Procedure for multi-material modelling of concept prototypes. Rapid Production 2004 (2004), pp 35-40 [5.16] Billinghurst M, Kato H (2002) Collaborative Augmented Reality. Communications of the ACM, Bd. 45, Nr. 7, 64-70 [5.17] Bimber O (2005) The Ultimate Display - What Will It Be? In: IEEE Computer 38, Nr. 8, pp. 29-30 [5.18] Blach R, Bues M, Hochstrate J, Springer J, Fröhlich B (2005) Experiences with Multi-Viewer Stereo Displays Based on LC-Shutters and Polarization. IEEE VR Workshop Emerging Display Technologies, Bonn. [5.19]Blumenstock T., Analyse der Eigenspannungen während der Aushärtung von Epoxidharzen, Dissertation Universität Stuttgart (2002) [5.20] Bonhoff N, (1998) Oberflächenenergie von Chromnitridschichten. Diplomarbeit, Technische Universität Baunschweig [5.21] Bowman D (2002) Principles for the Design of Performance-oriented Interaction Techniques. In: Stanney KM (Hrsg) Handbook of Virtual Environments. Design, Implementation, and Applications. Erlbaum, Mahwah/New Jersey, S 277-300 [5.22] Bowman D, e. al. (2003) Virtual-SAP: An Immersive Tool for Visualizing the Response of Building Structures to Environmental Conditions. Proc. IEEE Virtual Reality 2003, Los Angeles [5.23] Brave S, Ishii H, Dahley A (1998) Tangible Interfaces for Remote Collaboration and Communication. Proceedings of CSCW ’98 [5.24] Breckenridge A, Woessner U, Sanielevici S, Keller R, Pierson L, Welling J, Schulze J (2003) Distributed, On-Demand, Data-Intensive and Collaborative Simulation Analysis. Future Generation Computer Systems, Bd. 19/6, 849-859 [5.25] Brooke J M, Coveney P V, e. al. (2003) Computational Steering in RealityGrid. Proc. of the UK e-Science All Hands Meeting [5.26] Brooks FP, Ouh-Young M, Batter JJ, Kilpatrick PJ (1990) Project GROPE Haptic displays for scientific visualization, September 1990, ACM

480


SIGGRAPH Computer Graphics, Proceedings of the 17th annual conference on Computer graphics and interactive techniques SIGGRAPH '90, Volume 24, Issue 4 [5.27] Brunhuber (1960) Legierungshandbuch der Nichteisenmetalle, Schiele und Schön. Berlin [5.28] Bues M (2001) Virtual Reality für den Mittelstand. VDI-Z 143 10, 46-47 [5.29] Bues M, Blach R, Haselberger F (2003) Sensing Surfaces: Bringing the Desktop into Virtual Environments 7th International Immersive Projection Technologies Workshop, Zürich [5.30] Bues M, Hinkenjann A, Olry T, Schupp S (2003) Attacking the Network Bottleneck of Parallel Rendering with Commodity Hardware In: Proceedings of SVR 2003, 6th Symposium on Virtual Reality, Ribeirao Preto, Brazil [5.31] Canfield T, Papka M E, e. al. (1996) Toward Real-time Interactive Virtual Prototyping of Mechanical Systems: Experiences Coupling Virtual Reality with Finite Element Analysis. Proc. High Performance Computing 1996, New Orleans, LA [5.32] Chen ZD, Mai TA, Lim GC (1998) Rapid tooling by laser cladding. In: Proc. of the laser materials processing conference ICALEO'98, 16.-19. Nov. 1998, Orlando. Orlando: Laser institute of America, ICALEO 1998, S.E8E14. [5.33] Chin J, Coveney P V, Harting J (2004) The TeraGyroid Project - Collaborative Steering and Visualization in an HPC Grid for Modelling Complex Fluids. Proc. of the UK e-Science All Hands Meeting [5.34] Chu CCP, Dani TH, Gadh T (1997) Multi-sensory user-interface for a virtual-reality-based Computer aided design system. In: Computer-Aided Design (1997), Vol 29, Nr 10, S 709-725 [5.35] Cutkosky M, Howe R (1990) Human Grasp Choice and Robotic Grasp Analysis. In: Venkataraman ST, Iberall T (Hrsg) Dextrous Robot Hands. Springer, New York, S 5-31 [5.36] DaimlerChrysler (2006) Infitec Wellenlängenmultiplex Visualisierungssysteme. http://www.infitec.net/infitec.pdf [5.37] Dassault Systeme (2003) CAD-System CATIA. Online in Internet: URL: http://www.ibm.com/de/catia/, IBM Product-Lifecycle Management, Firmenschrift [5.38] Davidson A J (2003) Real-Time Simultaneous Localisation and Mapping with a Single Camera. In. Proc. ICCV 2003 [5.39] Deiler G, Schweiker T (2005) Kunststoff senkt die Kosten im KleinserienKarosseriebau. Blech Inform 4: 36-40 [5.40] Deisinger J, Blach R, Wesche G et al (2000) Towards Immersive Modeling - Challenges and Recommendations: A Workshop Analyzing the Needs of Designers In: Proceedings of the 6th Eurographics Workshop on Virtual Environments 1-2 Juni, 2000, Amsterdam, The Netherlands JD Mulder, R van Liere (eds) Wien, New York: Springer [5.41] Deisinger J, Breining R (2000c) Ergonaut A Tool for Ergonomic Analyses in Virtual Environments In: Virtual Environments 2000, Proceedings of the 6th Eurographics Workshop on Virtual Environments, June 1-2, 2000, Am-

Literatur

481

sterdam, The Netherlands JD Mulder, R van Liere (eds) Wien, New York: Springer [5.42] Deisinger J, Breining R, Rößler A et al (2000b) Immersive Ergonomic Analyses of Console Elements in a Tractor Cabin Proceedings of the 4th Immersive Projection technologies Workshop, June 19-20, 2000, Iowa, USA Iowa State University [5.43] Dodgson NA (2005) Autostereoscopic 3D Displays. In: IEEE Computer 38, Nr. 8, pp. 31-36 [5.44] Doege E, Frank C (1998) Verschleißverhalten polymerer Werkzeugwerkstoffe. Bänder Bleche Rohre 11: 30-35 [5.45] Dolenc A (1993) Software Tools for Rapid Prototyping Technologies in Manufacturing, Acta Polytechnica Scandinavica, Helsinki University of Technology [5.46] Dusel KH (2000) Rapid Tooling – Spritzgießen mit Prototyp-Werkzeugen und der Einfluss auf die Bauteileigenschaften, Dissertation Universität Stuttgart [5.47] Eimann K (2000) Instandsetzen von Werkezeugen mit Laserstrahlung}. Vortrag, Aachener Kolloquium für Lasertechnik AKL'2000, 30.-31. Mai 2000, Aachen. Tagungsband, Aachen: Fraunhofer-Institut für Lasertechnik u.a., 2000, S.169-180. [5.48] Eimann K, Drach M, Wissenbach K, Gasser A (2003) Lasereinsatz im Werkzeug und Formenbau}. In: Hügel, H; Dausinger, F.; Müller, M. (Hrsg.): Tagungsband zu den Stuttgarter Lasertagen 2003, 25.-26. Sept. 2003. Stuttgart: Forschungsgesellschaft für Strahlwerkzeuge mbH, S.125-128. [5.49] Eschl J (2001) Die mechanischen Eigenschaften von Stereolithographiematerialien während der Aushärtung, Dissertation Universität Stuttgart [5.50] Flaig T (1998) Work Task Analysis and Selection of Interaction Devices in Virtual Environments. In: Heudin JC (Hrsg) Virtual Worlds. First International Conference. Proceedings. Springer, Berlin, S 88-96 [5.51] Flemming E, Tilch W (1993) Formstoffe und Formverfahren. Dt. Verlag für Grundstoffindustrie, Leipzig Stuttgart [5.52] FreeSOLID (2006) Software Library for Interference Detection http://sourceforge.net/projects/freesolid [5.53] Friedrich W (2002) ARVIKA - Augmented Reality for Development, Production and Service. Proc. International Symposium on Mixed and Augmented Reality (ISMAR'02) [5.54] Fux V, Nowotny S, Pollack D, Luft A, Schwarz W (1992) Laser cladding with amorphous hardfacing alloys. In: Mordike, B.L. (Hrsg.): Laser treatment of materials, Proc. of the european conference on laser treatment of materials, 1992 (ECLAT'92). Oberusel: DGM Informationsgesellschaft Verlag, 1992, S.387-392. [5.55] Gassmann R, Luft S, Schädlich A, Techel A (1992) Adhesion and microstructure of laser cladded coatings. In: Mordike, B.L. (Hrsg.): Laser treatment of materials, Proc. of the european conference on laser treatment of materials, 1992 (ECLAT'92). Oberusel: DGM Informationsgesellschaft Verlag, 1992, S.405-410.

482


[5.56] Gebhard A (2000) Rapid Prototyping, Werkzeuge für die schnelle Produktentwicklung, 2.Aufl., Hanser Verlag, München [5.57] Gebhardt A (2000) Rapid Prototyping. 2. Aufl, Carl Hanser, München Wien [5.58] Gebhardt A (2005) Rapid Prototyping. Hanser, München Wien [5.59] Gnanamuthu DS (1976) Cladding, Patentschrift US 3095 21 80, 1976. [5.60] Gräfen H (1991) Lexikon Werkstofftechnik. VDI-Verlag, Düsseldorf [5.61] Graydon O (1998) Jets of molten metal make industrial parts. Optics & laser europe 2/1998, S.33-35. [5.62] Haferkamp H e.a. (1999) Lasereinsatz zur Vergütung und Reparatur im Werkzeugbau. wt werkstatttechnik 89 (1999) H.7/8, S.381-383. [5.63] Haferkamp H, Gerken J, Schmidt H, Marquering M (1994) Schnell aufgebaut. Industrieanzeiger (1994) 18/94, S.46-50. [5.64] Haferkamp H, Bach FW, Gerken J (1997) Rapid Prototyping - Direkte Herstellung metallischer Komponenten durch Laserstrahl-Auftragschweißen. In: VDI-Gesellschaft Werkstofftechnik (Hrsg.): Effizienzsteigerung durch innovative Werkstofftechnik, Werkstofftag ´95, 15.-16.03.1995, Aachen (VDI Berichte 1151). Düsseldorf 1995, S.459-466. [5.65] Halle M (1997) Autostereoscopic Displays and Computer Graphics. In: ACM SIGGRAPH Computer Graphics 31 (1997), Nr. 2, pp. 58-62 [5.66] Haller B (1998) Prototyp- Werkzeugsysteme für die Blechumformung. In: Siegert (Hrsg) Neuere Entwicklungen in der Blechumformung. MAT INFO Werkstoff- Informationsgesellschaft mbH, Frankfurt am Main, S 523- 555 [5.67] Haller B (2002) Optimierung von Prozeßketten für die Herstellung von Prototyp- Blechumformwerkzeugen. Dissertation, Universität Stuttgart [5.68] Häussermann M (2002) Zur Gestaltung von Tiefziehwerkzeugen hinsichtlich des Einsatzes auf hydraulischen Vielpunktzieheinrichtungen. Dissertation, Universität Stuttgart [5.69] Hellerich, Harsch, Haenle (1996) Werkstoff- Führer Kunststoffe.Hanser, München, Wien [5.70] Henning A, Grzesiak A (2005) Rapid Prototyping, Tooling & Manufacturing - State of the Industry – Germany. In: Wohlers Report 2005 S 112-114 [5.71] Herziger G, Loosen P (Hrsg.) (1993) Werkstoffbearbeitung mit Laserstrahlung. Wien, München: Carl Hanser Verlag. [5.72] Hilbert HL (1963) Gegossene Werkstoffe für den Großwerkzeugbau. Werkstatt und Betrieb 96: 179-183 [5.73] Hinckley K (1996) Haptic Issues for Virtual Manipulation. Dissertation, Charlottesville, University of Virginia [5.74] Hinckley K, Pausch R, Goble J C, Kassell N F (1994) A Survey of Design Issues in Spatial Input. In: ACM Special Interest Group on Computer Graphics and Interactive Techniques, ACM Special Interest Group on Software Engineering, ACM Special Interest Group on Computer-Human Interaction (Hrsg) Symposium on User Interface Software and Technology archive. Proceedings of the 7th annual ACM symposium on User interface software and technology, 1994, Marina del Rey/Kalifornien/USA. ACM Press, New York, S 213-222.

Literatur

483

[5.75] Hoffmann H, Stanchev S (2004) Bauteile schon im Werkzeug individuell gestalten. Blech InForm 5: 28-30 [5.76] Hoffmann E (1998) Hestellung metallischer Bauteile durch Laserstrahlgenerieren. Dissertation, RWTH Aachen. Shaker Verlag, Aachen. [5.77] Hoffmann E, Backes G, Gasser A, Kreutz EW, Stromeyer R, Wissenbach K (1996) Prozessüberwchung durch Temperaturregelung beim Generieren mit CO2-Laserstrahlung. Laser und Optoelektronik 28 (1996) Nr.3, S.59-67. [5.78] Hohnhaus J (1999) Optimierung des Systems Vielpunktzieheinrichtung / Werkzeug. Dissertation, Universität Stuttgart [5.79] Houde S (1992) Iterative design of an interface for easy 3D direct manipulation. In: Bauersfeld P, Bennett J, Lynch G. (Hrsg) Proceedings of the SIGCHI conference on Human factors in computing, 3.-7. Mai 1992, Monterey. ACM Press, New York, S 135-142 [5.80] Hübner S (2001) Für den kleinen Geldbeutel. Computer & Automation 11, 34, 43-45 [5.81] Huhn S, Haller B, Ismailoglu Y (2000) Herstellung von Prototyp- Werkzeugen für die Blechumformung. In: Siegert (Hrsg) Neuere Entwicklungen in der Blechumformung. MAT INFO Werkstoff- Informationsgesellschaft mbH, Frankfurt am Main, S 457- 478 [5.82] Huhn S, Jäger S (2003) Virtual Tool and Process Development for Hydromechanical Deep- Drawing. (Im Rahmen Proceedings of the Seventh International Conference on Computational Plasticity. Barcelona, Spain 7-10 April 2003) [5.83] Hutchins EL, Hollan JD, Norman DA (1986) Direct Manipulation Interfaces. In: Norman DA, Draper, SE (Hrsg) User-Centred System Design: New Perspectives on Human-Computer Interaction. Erlbaum, Hillsdale/New Jersey, S 87-124 [5.84] Icidio (2006) http://www.icido.de [5.85] IKP, SFB 374-D4, Bericht für den Zeitraum 1998-2000 [5.86] IKP (2005) TFB 41-T3, Abschlußbericht [5.87] Ishii H, Ullmer B (1997) Tangible Bits: Towards Seamless Interfaces between People, Bits and Atoms [5.88] Jasim KM, Rawlings RD, West DRF (1993) Metal-ceramic functionally gradient material produced by laser processing. J. of materials science 28, S.2820-2826. [5.89] Javor-Sander M, (1995) Beschichtung von Funktionsflächen im Arc-PVDProzeß. Produktionstechnik-Berlin 167, Carl Hanser Verlag München Wien [5.90] Keller B (1998) Rapid-Prototyping: Grundlagen zum selektiven Lasersintern von Polymerpulvern, Dissertation Universität Stuttgart [5.91] Kessenich J, Baldwin D, Rost R (2004) The opengl shading language http://osssgicom/projects/oglsample/opengl shading language http://osssgicom/projects/oglsample/registry/ARB/GLSLangSpecFull11059pd f [5.92] Kirchner F (2002) Hochleistungsthermoplaste in der Medizintechnik, VDIBerichte: Hochtemperaturthermoplaste, Band 1687, VDI-Verlag, Würzburg, S. 209-222

484


[5.93] Klocke F, Clemens U (1996) Auf gute Zusammenarbeit. Form+Werkzeug 3/96, S.42-44. [5.94] Klocke F, Nöken S (1996) Lasergenerieren metallischer Bauteile und Werkzeuge. In: Rapid Prototyping - Innovationen für den Modell-. Werkzeugund Formenbau, 4.-5. März 1996 Aachen. Handbuch zum Seminar, Aachen. [5.95] Koch KU (2000) Verfahren zur Herstellung von individuellen Implantaten auf der Basis resorbierbarer Werkstoffe. Dissertation. Universität Stutgart [5.96] Koch KU (2000) Verfahren zur Herstellung von individuellen Implantaten auf der Basis resorbierbarer Werkstoffe. Dissertation, Universität Stuttgart [5.97] Koch KU, Feenstra F (2000) European Network Offensive for Rapid Technologies RAPTIA – Intelligent Manufacturing Systems Rapid Product Development Project. In: Time-Compression Technologies: Harnessing the 4th Dimension Time-Compression Technologies 2000 (Conference 10th - 11th October Cardiff, UK. London, GB: Rapid News Publ, pp 5-9 [5.98] Krueger MW, Gionfriddo T, Hinrichsen K (1985) VIDEOPLACE—an artificial reality (1985). Proceedings of the SIGCHI conference on Human factors in computing systems table of contents. San Francisco, California, United States, pp 35-40. [5.99] Lanier J, Biocca F (1992) An insider's view of the future of virtual reality. In: Journal of Communication 42, Oxford University Press, pp. 150-172. [5.100] Lathan CE, Tracey MR, Sebrechts M, Clawson D, Higgins G (2002) Using Virtual Environments as Training Simulators: Measuring Transfer. In: Stanney KM (Hrsg) Handbook of Virtual Environments. Design, Implementation, and Applications. Erlbaum, Mahwah/New Jersey, S 403-414 [5.101] Leonard W (2001) Selektive Metallisierung von 3Dimensionalen Bauteilen. Fachtagung des FhG-Verbunds „Polymere Oberflächen“ [5.102] Liewald M (2006) Aktuelle Tendenzen in der Forschung auf dem Gebiet der Blechumformung am Institut für Umformtechnik (IFU) der Universität Stuttgart. In: Liewald (Hrsg) Neuere Entwicklungen in der Blechumformung. MAT INFO Werkstoff- Informationsgesellschaft mbH, Frankfurt am Main, S 371-402 [5.103] Lindholm E, Kilgard MJ, Moreton H (2001) A user-programmable vertex engine. In: Eugene Fiume, editor, SIGGRAPH 2001, Computer Graphics Proceedings, volume 35 of Annual Conference Series, pages 149-158 ACM Press / ACM SIGGRAPH [5.104] Lipton L,Feldman M (2002) A new autostereoscopic display technology: The Syntha-Gram™. In: Woods, A.J.; Merritt, J.O.; Benton, S.A.; Bolas, M.T.; Society of Photo-Optical Instrumentation Engineers SPIE (Hrsg.): Stereoscopic Displays and Virtual Reality Systems IX, Proceedings of the SPIE, Vol. 4660. Bellingham/Wash./USA: SPIE, 2002,pp. 229-235 [5.105] Liu Y, Mazumder J (1992) Laser cladding of Ni-Al-bronze on cast Al alloy. In: Mordike, B.L. Hrsg.): Laser treatment of materials, Proc. of the European conference on laser treatment of materials, 1992 (ECLAT'92). Oberusel: DGM Informationsgesellschaft Verlag, S.381-386. [5.106] Lugscheider, E. e.a.: One-step-powder-cladding of oxide ceramics on metal substrate with CO2-laser radiation. In: Proc. of the 5th european confer-

Literatur

485

ence on laser treatment of materials (ECLAT'94), 26.-27. Sept. 1994. Düsseldorf: Deutscher Verband für Schweißtechnik DVS Verlag, (DVS Berichte 163), S.213-218. [5.107] Lux T, (2002) Haftfestigkeit von Kupferschichten auf Polyimid beim licht-bogengestützen Aufdampfen. Dissertation Universität Stuttgart, Institut für Industrielle Fertigung und Fabrikbetrieb [5.108] Macêdo M, Cook D, Brown TJ (2000) Visual Data Mining in Atmospheric Science Data, April 2000, Data Mining and Knowledge Discovery, Volume 4 Issue 1, Kluwer Academic Publishers, Boston [5.109] Mann D, Leyendeck F, (1996) Haftungsaspekte bei kombinierten Beschichtungsverfahren. Kunststoff-Oberflächenveredelung 1996:69-88 [5.110] Markschläger P, (1998) Reaktive Abscheidung von Metalloxiden auf Polycarbonat zur Erzeugung transparenter Verschleißschutzschichten. Dissertation Universität Stuttgart, Institut für Industrielle Fertigung und Fabrikbetrieb [5.111] Mertz K, Fessmann J, (1992) Verbundprojekt: Kombination von PVD und Galvanik-Teilvorhaben: Metallisierung faserverstärkter Kunststoffe mittels kombinierter galvanischer / physikalischer Beschichtungsverfahren. Dünnschichttechnologien 92:617-630 [5.112] Methner M, (2006) Direkter Weg. Das Metall-Lasersintern verkürzt die Zeit für das Herstellen komplexer Spritzgusswerkzeuge. MM - Maschinenmarkt. Das IndustrieMagazin 4: 34-35 [5.113] Molnar S, Cox M, Ellsworth D, Fuchs H (1994) A Sorting Classification of Parallel Rendering. In: IEEE Computer Graphics and Applications, July/August 1994 (Vol 14, No 4), pp 23–32 [5.114] Montrym JS, Baum DR, Dignam DL, Migdal CJ (1997) InfiniteReality: a real-time graphics system In: Proceedings of the 24th annual conference on Computer graphics and interactive techniques, p293-302 [5.115] Mulder J, van Wijk J, van Liere R (1998) Computational steering in the CAVE. Software Engineering (SEN) SEN-R9818 [5.116] Murphy M, Lee C, Steen WM (1993) Studies in rapid prototyping by laser surface cladding. In: Proc. of the int. conf. of lasers and electro-opt. ICALEO'93, 24.-28.Okt. 1993, Orlando. Orlando: Laser institute of America, S.882891. [5.117] Nelson L, Cook D, Cruz-Neira C (1998) XGobi vs the C2: An Experiment Com-paring Data Visualization in an Immersive Virtual Environment with a Workstation Display. In Cruz-Neira C, Riedel O (eds) 2nd International Immersive Projection Technology Workshop, May 11-12, 1998, Iowa State University, Ames [5.118] Nvidia (2006) http://developernvidiacom/page/cg_mainhtml NVIDIA Corp [5.119] Open CASCADE Technology (2006), 3D modeling & numerical simulation Bei: http://www.opencascade.org/ [5.120] Pfeifer R (2006) Entwicklung von Rapid Prototyping Verfahren zur Herstellung verlorener Modelle für den Feinguss, Dissertation Universität Stuttgart

486


[5.121] Prinz F B (1997) Rapid Prototyping in Europe and Japan. In: JTEC/WTEC Panel Report, Japanese Technology Evaluation Center / World Technology Evaluation Center [5.122] Rainer D, Lang U, Werner A, Klimetzek F (2002) Interaktives Virtual Reality Design einer Klimaanlage im Fahrzeuginnenraum.VDI-Tagung: Berechnung und Simulation im Fahrzeugbau, 2002 [5.123] Rainer D, Ruprecht A, Eisinger R, Göde E (1999) Virtual Numerical Test Bed for Intuitive Design of Hydro Turbine Components. Hydropower into the Next Century, Gmünden, Austria, 1999 [5.124] Raja D, Bowman D, Lucas J, North C (2004) Exploring the Benefits of Immersion in Abstract Information Visualization. In: Proceedings of the 8th International Immersive Projection Technology Workshop, 13.-14. Mai 2004, Ames, S 1-7 [5.125] Rantzau D (2003) Ein modulares Konzept für die interaktive Auswertung von Simulationsdaten in einer verteilten und immersiven Virtuellen-RealitätsUmgebung. Diss. Universität Stuttgart [5.126] Rantzau D, Frank K, Lang U, Rainer D, Wössner U (1998) COVISE in the CUBE: An Environment for Analyzing Large and Complex Simulation Data, Proc. 2nd Workshop on Immersive Projection Technology (IPTW '98), Ames, Iowa [5.127] Rantzau D, Lang U, Rühle R (1996) Collaborative and Interactive Visualization in a Distributed High Performance Software Environment, Proceedings of the International Workshop on High Performance Computing for Graphics and Visualization, Swansea, Wales, '96 [5.128] Rantzau D, Maurer F, Mayer C et al. (2001) The integration of immersive Virtual Reality applications into Catia V5. In: Proceedings of the Eurographics Workshop in Stuttgart Wien: Springer, 2001 (Springer Computer Science), S 93 – 102 [5.129] Roll K, Altan T, Tekkaya AE, Hermann M (1999) Virtuelle Umformtechnik. In Geiger M (Hrsg) Umformtechnik 2000 Plus. Meisenbach, Bamberg [5.130] Rösener B, Kickelhain J Naundorf G (2003) RPID's: Elektrisch funktionsfähige Prototypen ohne Spritzgießformen. In: PLUS Produktion von Leiterplatten und Systemen 5: 123-129 [5.131] Roth-Koch S (2000) Generating CAD Models from Sketches. In: Cugini U, Wozny M (Ed) Geometric Modeling: Fundamentals and Applications GEO-7, 2-4.10., Parma, Italy; IFIP WG5.2, Parma: IFIP TC5/WG5.2 Workshop on Geometric Modeling 7, pp 207-219 [5.132] Roth-Koch S (2001) Hybride Entwurfsmodelle im Rapid Product Development. In: Tagungsband: Vom Rapid Prototyping zur Virtuellen Realität, Euroforum –Konferenz vom 23.-24.10. in Stuttgart, Düsseldorf [5.133] RTT (2006) DeltaGen: Anwendung zur Aufbereitung komplexer 3DDaten für die Echtzeitvisualisierung in High-End-Qualität http://www.rtt.ag [5.134] Schock D (1996) Gußeisenwerkstoffe für Umformwerkzeuge In: Tagungsband zum Seminar Reibung und Verschleiß, MAT INFO Werkstoff- Informationsgesellschaft mbH, Oberursel

Literatur

487

[5.135] Schreiber W, Notni G (2000) Theory and arrangements of self-calibrating whole-body three-dimensional measurement systems using fringe projection technique. Optical Engineering 39: 159-169 [5.136] Schuhmann N (2001) New Methods for Feature-Line Extraction from Point Clouds. In: Numérisation 3D-Scanning-2001, 4-5.4. Paris, France, Harbour Conferences, Dinard [5.137] Schüßler A (1994) Guter Schutz - Einschmelzen von Keramikteilchen in Randschichten von Stahlbauteilen. Maschinenmarkt 100 Nr.7, S.28-31. [5.138] Seefeld T, Theiler C, Kohn H (1999) Beschichten mit dem Laserstrahl. Der Praktiker 6/99, S.248-251. [5.139] Seefeld T, Theiler C, Kohn H (1999) Laserstrahlbeschichten: Anwendungsbeispiele aus dem Schiffsmaschinenbau, der Off-Shore-Technik und dem Werkzeugbau. LaserOpto 31 Nr.6, S.68-73. [5.140] Seitz S (2000) Laser-Sintern auf dem Weg zum echten Fertigungsverfahren. In: Gießerei-Praxis 10: 15-17 [5.141] Siegert K, Huhn S (2002) Anwendung der Virtuelle Realität in der Prozessoptimierung und Werkzeugentwicklung. In: Siegert (Hrsg) Neuere Entwicklungen in der Blechumformung. MAT INFO Werkstoff- Informationsgesellschaft mbH, Frankfurt am Main, S 161-174 [5.142] Siegert K, Huhn S, de Souza J HC (2005) Rapid Tooling und Rapid Manufacturing in der Blechumformung: stand, Trends und Bedarf für seriennahe Prototypbauteile und Werkzeuge für kleine Stückzahlen. (Vortrag im Rahmen Euro- u Rapid 2005 am 10-12.05.05 in Leipzig) [5.143] Sigel J. (2006) Lasergenerieren metallischer Bauteile mit variablem Strahldurchmesser in modularen Fertigungsystemen. Dissertation, Universität Stuttgart. München: Utz-Verlag. [5.144] Sigel J, Dausinger F, Hügel H, Liu ZF (1998) Laser based rapid prototyping by process combination. In: Campbell, R.I (Hrsg.): Proc. of the 7th European conference on rapid prototyping and manufacturing, 7.-9. Juli 1998, Aachen. Nottingham: University of Nottingham, S.175-184 [5.145] Simon A, Scholz S (2005) Multi-Viewpoint Images for Multi-User Interaction. Proc. IEEE Virtual Reality 2005, pp. 107–113 [5.146] Slinger C, Cameron C, Stanley M (2005) Computer-Generated Holography as a Generic Display Technology. In: IEEE Computer 38, Nr. 8, pp. 4653 [5.147] SOLID (2006) Collision detection library. http://www.dtecta.com/ [5.148] Sommer N (1986) Niederhalterdruck und Gestaltung des Niederhalters beim Tiefziehen von Feinblechen. Dissertation, Universität Hannover [5.149] Spur G, Stöferle T (1987) Handbuch der Fertigungstechnik Band 4 Abtragen Beschichten. Carl Hanser Verlag München Wien [5.150] Stanney KM, Mourant RR, Kennedy RS (1998) Human Factors Issues in Virtual Environments: A Review of the Literature. In: Presence 7, Nr. 4, S 327-351 [5.151] Steen WM (2003) Laser material processing, 3. Aufl, Springer Verlag, London

488


[5.152] Stierlen P (2002) Rapid Prototyping von Keramiken – Entwicklung eines Verfahrens zur Herstellung reaktionsgebundener SiSiCPrototypen, Dissertation Universität Stuttgart [5.153] Stork A, Amicis R (2000) ARCADE/VT - A Virtual Table-centric modeling system In: Proceedings of 4th International Immersive Projection Technology Workshop (IPT 2000), June 19-20, 2000, Ames, Iowa [5.154] Stotz M, Rot-Koch S (2003) A New Feature Orientated Digitising Strategy Integrating the Conceptual Design into the Design Engineering. In: 3D Modelling 2003 – Num 3D 23.-24.4. Paris, France, Harbour Conferences, Dinard [5.155] Sutherland I (1965) The Ultimate Display. In: Information Processing 1965: Proceedings of IFIP Congress 65, New York, 24.-29. Mai 1965): pp. 508 [5.156] Tsiafoulis A (1993) Einfluß wichtiger Fertigungsparameter beim VakuumFormverfahren auf die Güte von Gußteilen aus der Legierung G-AlSi12. Dissertation, Technische Universität Berlin [5.157] Visenso (2006) http://www.visenso.de [5.158] VIZup (2006) Polygon reduction tool http://www.vizup.com [5.159] Volz R (1998) Optimiertes Beschichten von Gußeisen-, Aluminium- und Kupfergrundwerkstoffen mit Lasern. Dissertation, Universität Stuttgart. Laser in der Materialbearbeitung, Forschungsberichte des IFSW. Stuttgart, Leipzig: B.G. Teubner Verlag. [5.160] VRcom (2006) http://www.vrcom.de [5.161] Wagner S (1996) 3D- Beschreibung der Oberflächenstruckturen von Feinblechen. Dissertation, Universität Stuttgart [5.162] Wagner S (2004) Blechumformung am IFU. In: Siegert (Hrsg) Forschung am Institut für Umformtechnik (IFU) der Universität Stuttgart. MAT INFO Werkstoff- Informationsgesellschaft mbH, Frankfurt am Main, S 77-144 [5.163] Wagner T., Höfer T., Knies S., Eyerer P., Laser Sintering of High Temperature Resistant Polymers with Carbon Black Additives, Intern. Polymer Processing XIX (2004) 4, S 395-401 [5.164] Westkämper E, (2003) Entwicklung und Erprobung innovativer Produkte. Ergebnisbericht der Förderperiode 01-03 SFB374 [5.165] Westkämper E, Koch K U, Biesinger B (2002) Innovative Generative Manufacturing of 3Dimensional Structures. In: Production Engineering 9 Nr 1, pp 43-46 [5.166] Westkämper E, Roth-Koch S (2001) Integrating the Early Stages of Conceptual and Stylistics Design into the Virtual Product Development. In: Proceedings International CIRP Design Seminar, 6.-8.6.2001, Stockholm, Schweden, Design Theory, Methodology and its Integration with Computational Tools to support Teams of Competence - the Road to Wealth, Kjellberg, T. (Hrsg.), Stockholm, 2001, pp 61-65 [5.167] Westkämper E, Roth-Koch S, Stotz M (2003) A new design orientated digitalization technology (CIRP Design Seminar im Jahre 2003, pp 1-10)

Literatur

489

[5.168] Westkämper E, Roth-Koch S, Stotz M (2004) A New Strategy for Oriented Digitizing Integrating Conceptual Design into Design Engineering. In: Production Engineering: Research and Development 11, Nr. 2, pp 125-128 [5.169] Westkämper E, Stotz M, Effenberger I (2006) Automatische Segmentierung von Messpunktwolken in regelgeometrische Elemente. In: tm - Technisches Messen 73, Nr. 1, S. 60-66 [5.170] Westkämper E, Warneke H-J (2004) Einführung in die Fertigungstechnik. Teubner Stuttgart Leibzig Wiesbaden [5.171] Wickens B (1995) Cognitive Issues in Virtual Reality. In: Barfield W, Furness TA (Hrsg) Virtual environments and advanced interface design. Oxford University Press, Oxford, S 514-541 [5.172] Wiedemann B, (1997) Verzugsursachen stereolithographisch hergestellter photopolymerer Bauteile und die Auswirkungen der Prozeßführung auf ihr Eigenschaftsprofil, Dissertation Universität Stuttgart [5.173] Wierse A (2002) Eine object-orientierte Datenverwaltung für eine verteilte Visualisierungsumgebung. Diss. Universität Stuttgart [5.174] Wohlers T (2005) Wohlers Report Annual Worldwide Progress Report. Fort Collins, Co, USA Wohlers Associates [5.175] Woicke N, Wagner T, Eyerer P (2005) Carbon assisted Laser Sintering of thermoplastic polymers, ANTEC, Boston [5.176] Xue L; Islam M (1998) Free-form laser consolidation for producing functional metallic components. In: Proc. of the laser materials processing conference ICALEO'98, 16.-19. Nov. 1998, Orlando. Orlando: Laser institute of America, S.E15-E24. [5.177] Ziegler R (1997) System zum integrierten Einsatz von haptischen Displays in Virtuellen Umgebungen. Dissertation, Technische Universität Darmstadt [5.178] N.N. (1999) Ein CNC-gestütztes Laserschweißverfahren eröffnet neue Perspektiven für den Materialaufbau. EuroLaser, 3/99 (Internet Archiv). [5.179] N.N. http://www.wikipedia.de [5.180] N.N. (1999) Instandsetzen und Reparieren. EuroLaser, 6/99, S.58-60. [5.181] N.N. (1996) System kombiniert HSC und Laserauftragschweißen. Industrieanzeiger, 5/96, S.30-32.

Entwicklung und Erprobung innovativer Produkte - Rapid Prototyping GERMAN

Entwicklung und Erprobung innovativer Produkte: Rapid Prototyping. Grundlagen, Rahmenbedingungen und Realisierung

Rapid Control Prototyping: Methoden und Anwendungen GERMAN

Rapid Prototyping Technology

Rapid systems prototyping with VHDL

Rapid Prototyping Casebook (Casebook S.)

Individualisierte Produkte - Komplexität beherrschen in Entwicklung und Produktion (VDI-Buch)

Individualisierte Produkte - Komplexität beherrschen in Entwicklung und Produktion

Rapid Prototyping of Digital Systems: SOPC Edition

Software Lifecycle. Management und Entwicklung GERMAN

Rapid Prototyping: Principles and Applications (2nd Edition)

Pharmazeutische Produkte und Verfahren

CAD-CAM & Rapid Prototyping Application Evaluation

Emotionen - Entwicklung und Regulation

Microsoft SQL Server 7.0 - Kompendium . Für Administration und Entwicklung GERMAN

Mobile Python - Rapid prototyping of applications on the mobile platform

Ein Vorgehensmodell für den Einsatz von Rapid Prototyping

Mobile Python: Rapid prototyping of applications on the mobile platform

Methodische Entwicklung technischer Produkte. Methoden flexibel und situationsgerecht anwenden (VDI-Buch)

Kommunikation in Forschung und Entwicklung

Mobile Python: Rapid prototyping of applications on the mobile platform

Integration von Advanced Control in der Prozessindustrie: Rapid Control Prototyping (German Edition)

Rapid Prototyping: Theory and Practice (Manufacturing Systems Engineering Series)

Entwicklung landschaftsvertraglicher Bauweisen fur uberstrombare Damme German

Software-Entwicklung für Echtzeitsysteme (German Edition)

Konzeptentwicklung und Gestaltung technischer Produkte, 2. Auflage

Kundendienst. Serviceleistungen für Kunden und Produkte

Prototyping techniques

Orgon Produkte

Mambo: Installation, Administration, Anwendung und Entwicklung

Entwicklung und Anwendung explizit korrelierter Wellenfunktionsmodelle

Entwicklung und Erprobung innovativer Produkte - Rapid Prototyping GERMAN

Entwicklung und Erprobung innovativer Produkte: Rapid Prototyping. Grundlagen, Rahmenbedingungen und Realisierung

Rapid Control Prototyping: Methoden und Anwendungen GERMAN

Rapid Prototyping Technology

Rapid systems prototyping with VHDL

Rapid Prototyping Casebook (Casebook S.)

Individualisierte Produkte - Komplexität beherrschen in Entwicklung und Produktion (VDI-Buch)

Individualisierte Produkte - Komplexität beherrschen in Entwicklung und Produktion

Rapid Prototyping of Digital Systems: SOPC Edition

Software Lifecycle. Management und Entwicklung GERMAN

Rapid Prototyping: Principles and Applications (2nd Edition)

Pharmazeutische Produkte und Verfahren

CAD-CAM & Rapid Prototyping Application Evaluation

Emotionen - Entwicklung und Regulation

Microsoft SQL Server 7.0 - Kompendium . Für Administration und Entwicklung GERMAN

Mobile Python - Rapid prototyping of applications on the mobile platform

Ein Vorgehensmodell für den Einsatz von Rapid Prototyping

Mobile Python: Rapid prototyping of applications on the mobile platform

Methodische Entwicklung technischer Produkte. Methoden flexibel und situationsgerecht anwenden (VDI-Buch)

Kommunikation in Forschung und Entwicklung

Mobile Python: Rapid prototyping of applications on the mobile platform

Integration von Advanced Control in der Prozessindustrie: Rapid Control Prototyping (German Edition)

Rapid Prototyping: Theory and Practice (Manufacturing Systems Engineering Series)

Entwicklung landschaftsvertraglicher Bauweisen fur uberstrombare Damme German

Software-Entwicklung für Echtzeitsysteme (German Edition)

Konzeptentwicklung und Gestaltung technischer Produkte, 2. Auflage

Kundendienst. Serviceleistungen für Kunden und Produkte

Prototyping techniques

Orgon Produkte

Mambo: Installation, Administration, Anwendung und Entwicklung

Entwicklung und Anwendung explizit korrelierter Wellenfunktionsmodelle

Recommend Documents