Entwicklung und Erprobung innovativer Produkte - Rapid Prototyping GERMAN

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

Entwicklung und Erprobung innovativer Produkte –Rapid Prototyping

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

Entwicklung undErprobunginnovativer Produkte –Rapid PrototypingGrundlagen, Rahmenbedingungenund Realisierung

Unter Mitarbeit von Heiko Grafsowie Thorsten Rogowski und Joachim Warschat

mit 240 Abbildungen

123

Prof. Dr.-Ing. Bernd Bertsche

Universität StuttgartInstitut für MaschinenelementePfaffenwaldring 970569 [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 20073380007 Mü[email protected]

Bibliografische Information der Deutsche NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der DeutschenNationalbibliografie; detaillierte bibliografische Daten sind im Internet überhttp://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, insbesonderedie der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen undTabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen We-gen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiserVerwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkesist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechts-gesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltendenFassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegenden 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 diesemBuch berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solcheNamen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachtenwären und daher von jedermann benutzt werden dürften. Sollte in diesem Werk direkt oderindirekt auf Gesetze, Vorschriften oder Richtlinien (z. B. DIN, VDI, VDE) Bezug genommenoder 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 eigenenArbeiten die vollständigen Vorschriften oder Richtlinien in der jeweils gültigen Fassunghinzuzuziehen.

Satz: Digitale Druckvorlage der HerausgeberHerstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, LeipzigUmschlaggestaltung: WMXDesign, HeidelbergGedruckt auf säurefreiem Papier 68/3100YL – 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 Na-se vorn haben“ mit Erfolg versprechenden Neuerungen, um die Konkur-renz 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. Kun-denorientierung, sowie steigende Qualitätsanforderungen sowohl bei den Produkten wie auch den zugehörigen Prozessen bilden herausfordernde und treibende Rahmenbedingungen. Innovationen müssen in diesem turbu-lenten 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 Prototy-ping“ ist die Zielsetzung des von der DFG geförderten Sonderforschungs-bereichs 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:

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 Projektmanage-ment unterstützt und der Termin gehalten werden? Wie können Kosten und Qualität während des kompletten Produkt-entwicklungsprozesses so abgeschätzt und sicherstellt werden, dass die Zielvorgaben erreicht werden?

VI Vorwort

Welche informationstechnische Unterstützung wird benötigt, um die Vielzahl der anfallenden Informationen anwendungsübergreifend zu bündeln, zu integrieren, zu verteilen und darzustellen? 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 Produktentwicklungs-prozess 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, Be-triebswirtschaftslehre, Ingenieurwissenschaften und Informatik konnten umfassende Lösungen erarbeitet werden. Diese basieren auf dem Gedan-ken einer evolutionären und iterativen Produktentwicklung. Kennzeich-nend hierfür sind die gezielte Nutzung schneller Iterationszyklen, die situa-tionsgerechte 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 inne-hat und für viele Branchen als Beispiel und Trendsetter in der Produktent-wicklung fungiert. Durch den intensiven Dialog mit der Industrie wurde die Praxisrelevanz der erarbeiteten Ergebnisse sichergestellt. Die erarbeite-ten 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 interes-sierte Leser erhält einen umfassenden Überblick über den Stand der Tech-nik sowie eine Vielzahl von Anregungen für seine Forschungsarbeiten.

Als Sprecher des Sonderforschungsbereichs 374 „Entwicklung und Er-probung 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 Ein-satz und ausgezeichnete Zusammenarbeit an diesem gemeinsamen Projekt maßgeblich den Erfolg des Sonderforschungsbereichs sicherten:

Betriebswirtschaftliches Institut – Lehrstuhl Controlling, Stuttgart DaimlerChrysler AG, Stuttgart Höchstleistungsrechenzentrum, Stuttgart

Vorwort VII

Institut für Arbeitswissenschaft und Technologiemanagement, Stuttgart Institut für Industrielle Fertigung und Fabrikbetrieb, Stuttgart Institut für Kunststoffprüfung und Kunststoffkunde (jetzt: Institut für Kunststofftechnik), Stuttgart Institut für Maschinenelemente, Stuttgart Institut für Psychologie (jetzt: Institut für Allgemeine Psychologie), TU DresdenInstitut für Rechnergestützte Ingenieursysteme, Stuttgart Institut für Strahlwerkzeuge, Stuttgart 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 Sonder-forschungsbereiches.

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 Entwicklungszei-ten. Die in diesem Band vorgestellten Methoden und Werkzeuge sollen Ihnen dabei eine Unterstützung bieten. Wir hoffen, dass wir Ihnen als Le-ser Ideen und Anregungen für Ihre tägliche Arbeit geben können. Wenn Sie durch die Vorschläge in diesem Band schneller zu innovativen Produk-ten kommen, dann haben wir ein wichtiges Ziel erreicht, nämlich neue Me-thoden 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.................................................................................................11.1 Übersicht über den Sonderforschungsbereich 374 ...........................1

1.1.1 Ziele...........................................................................................11.1.2 Überblick ...................................................................................21.1.3 Prototypen im RPD....................................................................61.1.4 IT Unterstützung im RPD........................................................111.1.5 Sfb 374 - Aufbau und Wissenswertes......................................19

1.2 Integrationsszenario........................................................................231.2.1 Grundlegende Verbesserungen................................................261.2.2 Integration der Teilprojekte am Beispiel eines Pkw-Cockpits 27

2 Organisation und Wissenskooperation...............................................332.1 Merkmale des Rapid Product Development ...................................332.2 Anforderungen an Produktentwicklungsteams...............................34

2.2.1 Innovationsanforderungen .......................................................342.2.2 Komplexitätsanforderungen ....................................................352.2.3 Kooperationsanforderungen ....................................................38

2.3 Planungsmethoden innovativer Produkte in dezentralen Teams ....402.3.1 Grenzen einer formalen Planung für das Rapid Product Development........................................402.3.2 Potenziale der evolutionären Planung für das Rapid Product Development........................................412.3.3 Kompetenzmanagement zur Unterstützung einer evolutionären Planung für das RPD ...............................442.3.4 Das entwicklungsfähige Projektplanungssystem für das RPD 472.3.5 Zusammenfassung und Ausblick.............................................68

2.4 Wissensintensive Kooperationsprozesse bei der Entwicklung innovativer Produkte .....................................70

X Inhalt

2.4.1 Ausgangssituation.................................................................... 702.4.2 Modellentwicklung und Ableitung von Unterstützungsinstrumenten zur Wissensintegration im RPD.762.4.3 Ergebnis der Modellentwicklung zur Wissensintegration ....... 782.4.4 Ergebnisse der Analyse von Kooperationskonstellationen im Produktentwicklungsprozess (Studie 1) ............................. 822.4.5 Ergebnisse der Untersuchung von Kooperationsanforderungen im Produktentwicklungsprozess (Studie 2) ............................. 882.4.6 Handlungsempfehlungen aus Studie 1 und 2........................... 932.4.7 Ergebnisse der Untersuchung von Auswirkungen fachlicher Teamheterogenität (Studie 3) ................................. 942.4.8 Handlungsempfehlungen zur Wissensintegration aus Studie 3............................................................................ 1062.4.9 Umsetzung der Ergebnisse aus den Studien in Unterstützungsinstrumente ................................................ 1082.4.10 Ausblick............................................................................... 1102.4.11 Zusammenfassung ............................................................... 112

Literatur .............................................................................................. 114

3 Vernetztes Wissen für die interaktive Entwicklung von Prototypen .................................................................................... 123

3.1 Vernetztes Entwicklungswissen durchgehend nutzen .................. 1273.2 Aktives Semantisches Konstruktions- und Zuverlässigkeitsnetz .130

3.2.1 Semantische Vernetzung ....................................................... 1353.2.2 CAD – Datenaustausch.......................................................... 1363.2.3 Integration der Produktkostenüberwachung.......................... 1383.2.4 Integration der qualitativen und quantitativen Zuverlässigkeitsanalyse ......................................................... 1393.2.5 Anwendungsbeispiele............................................................ 1463.2.7 Zusammenfassung ................................................................. 158

3.3 Qualitätsmanagement im Rapid Prototyping................................ 1593.3.1 Frühe Phasen – Prognose und Merkmalsextraktion .............. 1613.2.2 Methoden der Risikoanalyse in der Produktkonfiguration.... 1673.2.3 Verfahren und Methoden der Prozessüberwachung .............. 1723.2.4 Systemfeedback – Umfassendes Qualitätsmanagement mit material- und prozessimmanenten Informationen........... 1763.3.5 Zusammenfassung ................................................................. 183

3.4 Kostenmanagement im Prozess des Rapid Prototyping ............... 1843.4.1 Überblick über das Forschungsprojekt .................................. 1843.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........2094.1.1 Einleitung ..............................................................................2094.1.2 Problemstellung .....................................................................2104.1.3 Meilensteine der Entwicklung, Stufe 1 – ASN, Metamodell, ECA..................................................................2104.1.4 Meilensteine der Entwicklung, Stufe 2 – Verteiltes Objektmanagement, Slot-Dämon, Transaktionskonzept .......2124.1.5 Meilensteine der Entwicklung - Stufe 3 ................................2144.1.6 Ergebnisse und ihre Bedeutung .............................................2234.1.7 Zusammenfassung der Ergebnisse.........................................2344.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 ............................................2384.2.2 Stand der Technik..................................................................2404.2.3 Das Aktive Semantische Netz ...............................................2474.2.4 Die agentenbasierte RPD-Middleware ..................................2514.2.5 Zusammenfassung .................................................................266

4.3 Teamorientiertes Kommunikationssystem für vernetztes Arbeiten .................................................................267

4.3.1 Einleitung ..............................................................................2674.3.2 Entwicklungsverlauf der Arbeiten im Teilprojekt .................2684.3.3 Stand der Forschung ..............................................................2704.3.4 Methoden...............................................................................2804.3.5 Ergebnisse..............................................................................281

4.4 Adaptive Benutzungsoberflächen.................................................2954.4.1 Einleitung ..............................................................................2954.4.2 Grundlagen von adaptiven Benutzungsoberflächen ..............2964.4.3 Das RPD-Portal .....................................................................3034.4.4 Zusammenfassung .................................................................315

Literatur ..............................................................................................316

5 Erstellung virtueller und physischer Prototypen.............................3295.1 Virtuelle Realität...........................................................................330

5.1.1 Virtuelle Realität in der Produktentwicklung ........................3305.2 Virtuelle Realität als Gestaltungs- und Evaluationswerkzeug......333

5.2.1 Montierbarkeitsuntersuchungen am Virtuellen Prototypen...3335.2.2 Visuelle Beurteilung von Objektgeometrien .........................3355.2.3 Lageänderung von 3D-Objekten im Raum............................337

XII Inhalt

5.2.4 Verbauwege, Einsehbarkeit, Beurteilung der Handlungen des Monteurs im Kontext ...................................................... 3405.2.5 Data Mining in Virtuellen Umgebungen ............................... 343

5.3 VR in der Konstruktion ................................................................ 3445.3.1 CAD-Review ......................................................................... 3445.3.2 CAD-VR Integration ............................................................. 3475.3.3 VR am Konstruktionsarbeitsplatz.......................................... 3515.3.4 Realitätsnahe Darstellung in VR ........................................... 353

5.4 Paralleles Rendering ..................................................................... 3565.5 Virtuelle und Hybride Prototypen ................................................ 362

5.5.1 Virtuelle Prototypen .............................................................. 3635.5.2 Online-Simulationen.............................................................. 3645.5.3 Hybride Prototypen ............................................................... 3705.5.4 Kooperatives Arbeiten mit virtuellen und hybriden Prototypen .............................................................. 3745.5.5 Zusammenfassung und Ausblick........................................... 377

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

5.6.1 Ausgangssituation.................................................................. 3795.6.2 Lösungsansätze...................................................................... 3815.6.3 Zusammenfassung ................................................................. 3925.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 ............................................................ 3965.7.2 Funktionalisierung von Prototypen durch das Multi Material Modelling ...................................................... 3995.7.3 Zusammenfassung und Ausblick........................................... 400

5.8 Oberflächenveredelung von RP-Bauteilen ................................... 4015.8.1 Ausgangssituation.................................................................. 4015.8.2 Anforderungen an Oberflächen ............................................. 4025.8.3 Verfahren zur Veränderung der Eigenschaften von Oberflächen ........................................................................... 4035.8.4 Lösungsansätze zur Funktionalisierung von RP-Bauteilen ...4045.8.6 Verfahrenskombinationen ..................................................... 4095.8.7 Zusammenfassung und Ausblick........................................... 411

5.9 Lasergenerieren im modularen System ........................................ 4125.9.1 Einleitung .............................................................................. 4125.9.2 Verfahrensprinzip .................................................................. 4135.9.3 Prozesssteuerung ................................................................... 4155.9.4 Prozesskontrolle durch einen Tiefensensor ........................... 420

Inhalt XIII

5.9.5 Prozessregelung.....................................................................4225.9.6 Modulares System .................................................................4275.9.7 Zusammenfassung und Ausblick...........................................429

5.10 Selektives Lasersintern von Hochleistungspolymeren mittels Nd:YAG-Laser.................................................................430

5.10.1 Einleitung ............................................................................4305.10.2 Ausgangssituation................................................................4315.10.3 Lösungsansätze....................................................................4365.10.4 Weiterentwicklung der Prozesstechnik................................4405.10.5 Verfahrenskombinationen ...................................................4425.10.6 Zusammenfassung und Ausblick.........................................442

5.11 Prototypwerkzeuge und Prototypbauteile...................................4445.11.1 Werkstoffe für Prototyp-Werkzeuge ...................................4455.11.2 Grauguss ..............................................................................4455.11.3 Stahl und Aluminium...........................................................4465.11.4 Niedrigschmelzende NE- Schwermetall-Legierungen ........4465.11.5 Kunststoffe, Polyamide und Photopolymere .......................4475.11.6 Werkzeugentwicklung .........................................................4505.11.7 3D-Visualisierung der Werkzeugkonstruktion ....................4565.11.8 Visualisierung der Simulation des Umformvorgangs..........4585.11.9 Werkzeugherstellungsprozesse............................................4605.11.10 Optimierung des Prozesses durch Einsatz des Vakuumformverfahrens ..............................................4615.11.11 Tribologische Anforderungen an die Werkzeugwirkfläche4655.11.12 Charakterisierung des Verschleißverhaltens......................4705.11.13 Einfluss des Prototypwerkzeugstoffes auf die Kriterien Prototyp-Teilequalität und Werkzeugstandzeit .................4735.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. Institut für Arbeitswissenschaft und Technologiemanagement (IAT)

Warschat, Joachim Prof. Dr.-Ing. habil.

Institut für Arbeitswissenschaft und Technologiemanagement (IAT)

1.2 Bertsche, Bernd Univ.-Prof.

Dr.-Ing. Institut für Maschinenelemente (IMA)

Graf, Heiko Dipl.-Ing. Institut für Maschinenelemente (IMA)

2 2.1 Kremer, David Dipl.-Psych. Institut für Arbeitswissenschaft

und Technologiemanagement (IAT)

Leyh, Jens Dipl.-Kfm Institut für Arbeitswissenschaft und Technologiemanagement (IAT)

2.2 Kremer, David Dipl.-Psych. Institut für Arbeitswissenschaft



2.3 Laufs, Uwe M.Comp.Sc.

Dipl.-Ing.(FH) Institut für Arbeitswissenschaft und Technologiemanagement (IAT


Spath Prof. Dr.-Ing. Institut für Arbeitswissenschaft und Technologiemanagement (IAT)

XVI Autorenverzeichnis

2.4 Bienzeisler, Bernd Dipl.-Soz.Wiss.


Kremer, David Dipl.-Psych. Institut für Arbeitswissenschaft und Technologiemanagement (IAT)

Spath Prof. Dr.-Ing. Institut für Arbeitswissenschaft und Technologiemanagement (IAT)

3, 3.1 Becker, Ralf Dipl.-Ing.(FH)

Master of De-sign

Institut für Industrielle Fertigung und Fabrikbetrieb (IFF)


Grzesiak, Andrzej Dipl.-Ing. Institut für Industrielle Fertigung und Fabrikbetrieb (IFF)

Henning, Axel Dipl.-Ing. Fraunhofer-Institut für Produkti-onstechnik und Automatisierung (IPA)

Kempf, Michael Dipl.-Math. Fraunhofer-Institut für Produkti-onstechnik und Automatisierung (IPA)

3.2 Bertsche, Bernd Univ.-Prof.

Dr.-Ing.Institut für Maschinenelemente (IMA)


Wacker, Michael Dipl.-Ing. Institut für Maschinenelemente (IMA)

3.3 Becker, Ralf Dipl.-Ing.(FH)

Master of De-sign


Grzesiak, Andrzej Dipl.-Ing. Institut für Industrielle Fertigung und Fabrikbetrieb (IFF)

Henning, Axel Dipl.-Ing. Fraunhofer-Institut für Produkti-onstechnik und Automatisierung (IPA)

Kempf, Michael Dipl.-Math. Fraunhofer-Institut für Produkti-onstechnik und Automatisierung (IPA)

Westkämper, Engelbert Univ.-Prof. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult.


3.4 Boomers, Achim Dr. Ehem. Betriebswirtschaftliches Institut (BWI)

Autorenverzeichnis XVII

Cassack, Ingo Dr. Ehem. Betriebswirtschaftliches Institut (BWI)

Horváth, Peter Univ. Prof. Dr. Dr. h.c. mult.

Ehem. Betriebswirtschaftliches Institut (BWI)

4 Diederich, Michael K. Dipl.-Inform. Institut für Arbeitswissenschaft




4.1 Mesina, Marian Dr.-Ing. Ehem. Institut für Rechner-

gestützte Ingenieursysteme (IRIS)

Roller, Dieter Univ.-Prof. Hon.-Prof. Dr.

Institut für Rechnergestützte In-genieursysteme (IRIS)

4.2 Dalakakis, Stavros Dipl.-Ing. Ehem. Institut für Rechner-

gestützte Ingenieursysteme (IRIS)

Diederich, Michael K. Dipl.-Inform. Institut für Arbeitswissenschaft und Technologiemanagement (IAT)

Roller, Dieter Univ.-Prof. Hon.-Prof. Dr.

Institut für Rechnergestützte In-genieursysteme (IRIS)



4.3 Tippmann, Volker Institut für Arbeitswissenschaft




4.4 Aslanidis, Stephanie Dipl.-Math. Ehem. Institut für Arbeitswissen-

schaft und Technologiemanage-ment (IAT)



Weisbecker, Anette Priv.-Doz. Dr.-Ing. habil.

Fraunhofer Institut für Arbeits-wirtschaft und Organisation (IAO)

XVIII Autorenverzeichnis

5 5.1 Haselberger, Frank Dipl.-Ing. Institut für Arbeitswissenschaft


Kopecki, Andreas Dipl.-Inf. Höchstleistungsrechenzentrum (HLRS)

Resch, Michael Prof. Dr.-Ing. Höchstleistungsrechenzentrum (HLRS)

Runde, Christoph Dipl.-Ing. Institut für Industrielle Fertigung und Fabrikbetrieb (IFF)

5.2 Runde, Christoph Dipl.-Ing. Institut für Industrielle Fertigung

und Fabrikbetrieb (IFF) Westkämper, Engelbert Univ.-Prof.

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


5.3 Bues, Matthias Dipl.-Ing. Institut für Arbeitswissenschaft


Haselberger, Frank Dipl.-Ing. Institut für Arbeitswissenschaft und Technologiemanagement (IAT)

Kern, Peter Prof. Dr.-Ing. Institut für Arbeitswissenschaft und Technologiemanagement (IAT)

5.4 Bues, Matthias Dipl.-Ing. Institut für Arbeitswissenschaft


Kern, Peter Prof. Dr.-Ing. Institut für Arbeitswissenschaft und Technologiemanagement (IAT)

Kopecki, Andreas Dipl.-Inf. Höchstleistungsrechenzentrum (HLRS)

Resch, Michael Prof. Dr.-Ing. Höchstleistungsrechenzentrum (HLRS)

5.5 Kopecki, Andreas Dipl.-Inf. Höchstleistungsrechenzentrum

(HLRS)Resch, Michael Prof. Dr.-Ing. Höchstleistungsrechenzentrum

(HLRS)

Autorenverzeichnis XIX

5.6 Roth-Koch, Sabine Dr.-Ing. Dipl.-Math.

Fraunhofer-Institut für Produkti-onstechnik und Automatisierung (IPA)

Westkämper, Engelbert Univ.-Prof. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult.


5.7 Biesinger, Bernd Dipl.-Ing. Institut für Industrielle Fertigung




5.8 Bohnet, Jens Dipl.-Ing. Institut für Industrielle Fertigung




5.9 Dausinger, Friedrich Prof. Dr. habil. Institut für Strahlwerkzeuge

(IFSW)Sigel, Julian Dr.-Ing. Ehem. Institut für Strahlwerk-

zeuge (IFSW) Walter, Jens Dipl.-Phys. Institut für Strahlwerkzeuge

(IFSW)

5.10 Eyerer, Peter Prof. Dr.-Ing. Institut für Kunststoffprüfung und Kunststoffkunde (IKP)

Kroh, Michael Dipl.-Ing. Institut für Kunststoffprüfung und Kunststoffkunde (IKP)

Woicke, Nina Dr.-Ing. Ehem. Institut für Kunststoffprü-fung und Kunststoffkunde (IKP)

5.11 Vorobyov, Kyrylo Dipl.-Ing. Institut für Umformtechnik (IFU)

Wagner Dr.-Ing. 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 Wettbe-werb bestehen will, muss es sich von anderen Unternehmen abheben. Dies geschieht in der Regel durch einen Qualitäts-, Preis- oder Zeitvorteil ge-genü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 ei-nem Mittelfeldplatz. Spitzentechnologien erfordern Innovationen. Innova-tionen benötigen Methoden und Werkzeuge, welche die gerade bei Spit-zentechnologien 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 anpas-sen können. Dabei können kontinuierlich die Anspruchsgruppen des Un-ternehmens, wie beispielsweise Kunden integriert werden. Dadurch wird der Innovationsprozess beschleunigt und die Innovationsfähigkeit erhöht.

Die in der Produktentwicklung durch die Umfeldbedingungen entste-henden Probleme lassen sich in vier Bereiche einordnen: Kosten-, Zeit und Qualitätsmanagement, Arbeitswissenschaftliche Grundlagen, IT-Unter-stützung sowie Prototypenerstellung, wie in Abb. 1.1 dargestellt wird.

2 1 Einleitung

Kosten-, Zeit und Qualitätsmanagement

Arbeits-wissenschaftliche Grundlagen

Prototypenerstellung

IT-Unterstützung

Produktentwicklung

Abb. 1.1. Problembereiche des Produktentwicklungsprozesses

1.1.2 Überblick

Grundlagen des Rapid Product Development

Die Forderungen nach kürzeren Entwicklungszeiten, höherer Produktquali-tä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ösun-gen. Besonders zu Beginn einer Entwicklung neuer und innovativer Pro-dukte 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 in-novativer Produkte.

Daher hatte der Sonderforschungsbereich (Sfb) 374 „Entwicklung und Erprobung innovativer Produkte - Rapid Prototyping“ als Ziel - unter Ein-beziehung eines evolutionär iterativen Ansatzes - Methoden zu erarbeiten, mit deren Hilfe aus den zur Verfügung stehenden Daten während des Ent-wicklungsfortschrittes schneller gesicherte Aussagen zu treffen sind. Des-halb steht eine frühe Verfügbarkeit der Daten hinsichtlich der Kriterien Kosten, Zeit und Qualität im Betrachtungsmittelpunkt. Im Rahmen der Ar-beiten im Sfb 374 hat sich gezeigt, dass neben der technischen Verfügbar-keit 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üt-zenden 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 Tech-nologien 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-, Kos-ten- und Qualitätsanforderungen, die arbeitswissenschaftliche Betrachtung der verteilten und multidisziplinär arbeitenden Teams sowie die Entwick-lung unterstützender Medien im Rahmen der Informations- und Kommu-nikationstechnologie.

Zur Lösung der beschriebenen Probleme bei der Entwicklung und Er-probung innovativer Produkte wurde im Sonderforschungsbereich die Me-thode des Rapid Product Development (RPD) erarbeitet. Eigenschaften dieses Konzepts evolutionärer, iterativer Produktentwicklung sind die ge-zielte Nutzung schneller Iterationszyklen, die situationsgerechte Verwen-dung von Prototypen sowie die dezentrale Struktur selbstorganisierter, vernetzter Teams.

Der evolutionäre Charakter zeigt sich an dem gewollten Wettstreit ver-schiedener Lösungsalternativen, deren Kombination und Weiterentwick-lung 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. Abgerun-det 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, physi-scher 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ätsan-forderungen 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 de-nen jedoch Simulationen und Berechnungen durchgeführt werden können.

In Zukunft werden Kombinationen aus virtuellen und physischen Proto-typen, die sogenannten Hybride, immer interessanter mit denen eventuelle Modifikationen bereits bestehender Bauteile durch Überlagerung vergli-chen 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 Entwurfs- und Konzeptionsphasen der Produktentwicklung wird bisher in der Indust-rie 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 Erstel-lung von Design-Formmodellen aus Materialien wie Clay oder Schaum-stoff 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 konven-tionellen 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 Ge-staltungsfreiheit 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


Eigenschaften darstellt. In der Produktentwicklung müssen zur drastischen Reduzierung von später auftretenden Änderungskosten sowie der Vermei-dung von verspäteten Produktstarts bereits in den frühen Phasen der Kon-struktion Zuverlässigkeitsbetrachtungen und Kostenanalysen durchgeführt, eine flexible Planung implementiert sowie Qualitätsaussagen getroffen werden.

Deshalb wurde ein Referenzmodell des Qualitätsmanagements in Ent-wicklungsnetzwerken des RPD erstellt, das alle qualitätsrelevanten Bau-steine für Entwicklungsnetzwerke wie Kommunikation, Daten-modellierung, Produkt- und Prozessqualitätsmanagement usw. integriert. Durch ihre Kombination können sowohl bekannte, als auch neue Qualitäts-management- Methoden mit integrierter Funktionalität entstehen.

Zudem sind schon in den frühen Phasen der Produktentwicklung Pla-nungsmethoden und -instrumente notwendig, die eine enge Zusammenar-beit 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 Mana-gement von Kompetenzen und darauf aufbauend die Implementierung von dynamischen Abstimmungsmechanismen zur Beschleunigung von Pla-nungsentscheidungen unterstützt.

Aufgrund des steigenden Kostendrucks müssen schon in der Konstruk-tion 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) beinhal-tet. 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 Kommunika-tion 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 Effek-te 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 Ent-wicklung von Gestaltungsempfehlungen und Instrumenten für die Unter-stü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 Iterati-onszyklen in der Produktentwicklung. Mit dem Aktiven Semantischen Netz (ASN), wird innerhalb des RPD die zentrale softwaretechnische In-tegrationskomponente zur Verfügung gestellt.

Es wurde eine Integrationsplattform als Bindeglied zwischen ASN und Anwender auf der Basis eines Multiagentensystems entwickelt und proto-typisch 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ögli-chen, und zum anderen plattformunabhängige Koordinationsmöglichkeiten für die RPD-Anwendungen bieten.

Es wurden die Aspekte einer technisch unterstützten Kooperation zwi-schen Teammitgliedern in Entwicklungsprozessen und deren Anwendbar-keit auf das RPD näher untersucht. Die Untersuchungen im Sonderfor-schungsbereich haben gezeigt, dass Kommunikation, Koordination und Wissensintegration entscheidende Faktoren für die effiziente Zusammen-arbeit in multidisziplinären Teams sind. Der intensive Austausch von Wis-sen muss auf Strukturen basieren, die einer direkten (d.h. nicht durch ein Medium gefilterten) Kommunikation nahe kommen, um die durch die De-zentralisierung 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 Proto-typen schafft VR neue Möglichkeiten.


Im Vordergrund stehen dabei formale Aspekte, Funktionalität, Monta-gemöglichkeiten, Fertigungsaspekte, Sicherheitsfragen oder physikalisch-technische Vorgänge. Ein Bereich ist die Erforschung der Wahrnehmung der Anwender in unterschiedlichen virtuellen Umgebungen (z.B. Mehr-wandprojektions-Systeme) in Verbindung mit verschiedenen Interaktions-konzepten 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 Integra-tionsformen unterschiedlicher Aufgabenstellungen in virtuellen Umgebun-gen.

Die relevanten VR-Werkzeuge wurden in eine gemeinsame Benut-zungsumgebung integriert, was die Produktentwicklung von der Idee bis zur Erstellung des Prototyps unterstützt. Durch die fortschreitende Arbeits-teilung bei der Entwicklung von Produkten ergibt sich weiterhin ein wach-sender Bedarf an Kooperationen, beispielsweise von Berechnungsingeni-euren, die an verschiedenen Standorten arbeiten. Durch die Verfügbarkeit von Hochgeschwindigkeitsnetzen haben sich klassische CSCW- Werkzeu-ge (computer supported cooperative work), wie Video-Konferenzsysteme, shared Notepads oder E-Mails als Alltagswerkzeuge etabliert. Somit stel-len kooperative virtuelle Umgebungen eine konsequente Weiterentwick-lung in diese Richtung dar und eröffnen ein bisher nicht erreichtes Potenti-al bei der Zusammenarbeit von dezentralen Entwicklungsteams. Um jedoch eine effiziente Zusammenarbeit in einer kooperativen Sitzung ge-währleisten zu können, mussten neue Interaktions- und Kooperationsme-thoden entwickelt werden, die ein gemeinsames Navigieren und Interagie-ren erlauben und dabei den Anwender nicht wie bei einer Master/Slave- Synchronisation einschränken, d.h. ein spontanes Arbeiten behindern. Um die Effizienz bei der Auswertung beispielsweise von Berechnungsergeb-nissen mit Hilfe von VR-Technologien zu steigern, mussten für die fach-spezifischen Anforderungen an die eingesetzte Hardware angepasste Inter-aktionsmethoden 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 Benut-zers 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üh-ren. 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 virtuel-len Prototypen vertieft, die durch den Einsatz von haptischen Wahrneh-mungen durch Weiter- und Neuentwicklungen bestehender Haptik-hardware verbessert wurde.

Vor allem für die multidisziplinäre Zusammenarbeit in virtuellen Um-gebungen 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 Berei-chen der Produkt-, Zeit- und Kostenplanung sowie des Qualitäts-managements sollen für Besprechungen und Präsentationen den Anwen-dern 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 Ef-fekte an realen Prototypen darzustellen und kontextbezogen auszuwerten. Konstruktionsvarianten können durch Überlagerung der Modifikationen über die vorliegende Ausgangsversion des Prototyps dargestellt und mit-einander verglichen werden. In Zukunft soll es möglich sein, reale Bauteile ohne das Anbringen von Markern mit virtuellen Darstellungen zu überla-gern.

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 Folgetechnolo-gie „Metallische Beschichtung von generativ gefertigten Prototypen“, die Verarbeitung unterschiedlicher Materialien ermöglichte. Somit konnte z.B. in einer Mehrkomponentenbauweise, bei der innerhalb eines Bauteils meh-rere Werkstoffe zum Einsatz kommen, die partielle Beschichtung ohne vorherige Maskierung genauer untersucht werden.

Ein Bedarf an Multi Material Prototypen besteht in sämtlichen Berei-chen, in denen Prototypen eingesetzt werden, z. B. zu Funktions-, Design- oder Ergonomieuntersuchungen.

Während der ersten Förderperioden wurde ausgehend von verschiede-nen Basiskomponenten ein modulares Rapid-Prototyping-System aufge-baut. Dabei wurde von dem Verfahren des Lasergenerierens ausgegangen, bei dem schichtweise dreidimensionale Geometrien aufgebaut werden. In-


dem die dafür benötigten Module, wie Pulverförderer, Laser und Bearbei-tungszentrum, 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. Hardwaremo-dule bezeichnen technisches Equipment, wie Laser und Optik, Wissens-module hingegen bezeichnen das Wissen, bestimmte Werkstoffe oder Pro-zesse 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 Proto-typing verfolgt. Diese Technologien und Prozessketten sollten sich so er-gänzen, dass in Kombination mit den verfügbaren, generativen Ferti-gungsverfahren Werkzeuge zur effizienten Herstellung eines breiten Spektrums der Prototypablauffolge bereitgestellt werden können. Das Pro-dukt dieser neuen Technologien sind die physischen Prototypen mit funk-tionellen 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 funktio-naler und technischer Prototypen mittels Lasertechniken ist die Entwick-lung 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 Prototy-pen mit seriennahem Eigenschaftsprofil realisiert werden können.

Sollen Materialien mit bestimmtem Eigenschaftsprofil im Lasersintern eingesetzt werden, müssen sowohl das Verfahren, insbesondere die Tem-peraturführung und das Beschichtungssystem, als auch der Werkstoff an-einander 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ärme-formbeständigen Thermoplasten bildete die Entwicklung des (LS)2I-Verfahrens (Liquid Silicon Infiltration of Lasersintered C-SiC Preforms) zur Herstellung endkonturnaher SiSiC-Keramikprototypen den zweiten Hauptarbeitsbereich.

Da die Verarbeitung von Werkstoffen mit unterschiedlichen Eigen-schaftsprofilen 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. Untersuchun-gen der Werkstoffverträglichkeiten bei unterschiedlichen Verfahrenskom-binationen standen im Vordergrund. Prototypische Werkzeugverfahren wurden, falls aus verfahrens- oder werkstofftechnischen Gründen erforder-lich, 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 Herstellungsver-fahrens durchgeführt werden und es können Prototypbauteile mit Eigen-schaften, die denen des Serienbauteils entsprechen, gefertigt werden. Wei-tere 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 vir-tuellen Arbeitsumgebung wird der Bauteil- und der Werkzeugentwick- lungsprozess 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 Ra-pid Product Development integriert werden. Dem Ingenieur wird eine brei-te 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.


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 Auf-bau eines aktiven semantischen Konstruktionsnetzes (ASK) unterstützt.

Das Konstruktionsnetz besteht aus Objekten (Anforderungen, Funktio-nen, Bauteile) und Beziehungen verschiedenen Typs. Durch die Verwen-dung 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 Produktentwick-lung sind viele kreative Leistungen erforderlich. Daher wird eine kontext-sensitive Unterstützung für die Anwendung von Kreativitätstechniken zur Verfügung stehen. Hierbei wird zunächst untersucht, welche Kreativitäts-techniken in den unterschiedlichen Phasen des computerunterstützten Kon-struktionsprozesses geeignet sind und welche sich sinnvoll bei verteilt ar-beitenden Konstrukteuren einsetzen lassen. Dadurch können Anfor-derungen und Erfahrungswissen direkt berücksichtigt werden. Aus den semantischen Beziehungen zwischen den Bauteilen des Konstruktionsnet-zes lassen sich das Berechnungsmodell und die topologische Anordnung der Bauteile ableiten. Zur Beherrschung des komplexen Auslegungsmo-dells über die Bauteile der Konstruktionsnetze hinweg wurde der Prototyp um weitere Strukturierungsmöglichkeiten erweitert. Zur Wiederverwen-dung entwickelter Bauteile ist eine Suchmöglichkeit auf Basis der Interval-le und Constraints entwickelt worden. Damit Konstruktionen bereits ab ei-nem frühen Zeitpunkt im Team kontrolliert entwickelt werden können, wurden Konzepte zur Segmentierung des Konstruktions- und Berech-nungsmodells mittels einer Client-/Server-Struktur und der dazugehörigen Koordinierungsmechanismen realisiert. Einige Produkte können aus zeitli-chen 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 Bauteilsuch-system müssen diesen geänderten Anforderungen angepasst werden. Ob-wohl die Zuverlässigkeit technischer Produkte heutzutage eine zunehmen-de Rolle spielt, werden Zuverlässigkeitsbetrachtungen meistens erst in späten Phasen der Produktentwicklung durchgeführt, was die Änderungs- bzw. Reparaturkosten um Größenordnungen erhöht. Mit dem "Zuverläs-sigkeits-Informationsnetz", soll das ASK zukünftig um eine Sicht erweitert

12 1 Einleitung

werden, die es dem Konstrukteur ermöglicht, in seiner gewohnten Umge-bung die Zuverlässigkeit der Bauteile und -gruppen in jeder Phase zu be-trachten und zu berücksichtigen.

Neben der Zuverlässigkeit werden auch die Qualitätsmanagementme-thoden betrachtet, die auf einzelne wertschöpfende Prozesse und Prozess-abfolgen (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 Er-stellung der Prototypen haben einen entscheidenden Einfluss auf die zu bevorzugende Methode bzw. deren exakte Ausgestaltung. Diese Metho-denbausteine mit ihren spezifischen Parametern haben definierte Schnitt-stellen und werden flexibel kombinierbar gestaltet. Durch die Anpassung der Methodenparameter werden die Methodenbausteine auf die durchzu-fü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 Kon-zeptphase werden spezielle Qualitätsmerkmale abstrahiert, die die Beson-derheiten von Entwurfsmodellen und konzeptionellen Prototypen berück-sichtigen. 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 Aus-sagen 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 wer-den deshalb die zu erwartenden geometrischen, physikalischen oder funk-tionalen Eigenschaften am hybriden Prototypen simuliert. Die Arbeiten zum Referenzmodell des Qualitätsmanagements in Entwicklungsnetzwer-ken werden in die Arbeiten zu der mehrdimensionalen Bewertung von Produkt- und Projektalternativen eingebracht. Die Arbeiten zur Berück-sichtigung netzwerkartiger Strukturen und die Einbeziehung industrieller, auch externer, Dienstleistungen in den Produktentwicklungsprozess wur-den in das Referenzmodell integriert. Durch die konsequente Rechnerun-terstützung bei der Akquisition und Speicherung von Wissen, dem Infor-mationstransport sowie dem Einsatz von Methoden zur Entscheidungs-unterstü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 Strate-gie hinsichtlich der Produktkosten spielt eine wesentliche Rolle und macht


die Entwicklung eines marktorientierten Kostengestaltungsmodells not-wendig. Im Rahmen des Rapid Product Development ermöglicht dieses In-strumentarium prototypgestützte Produktkostenvorgaben und -prognosen über den gesamten Lebenszyklus eines Produktes. Mit der Entwicklung dieses Modells ist man soweit fortgeschritten, dass nun neben dem physi-schen Produkt auch produktbegleitende Dienstleistungen einbezogen wer-den. Das physische Produkt bildet mit der Dienstleistung als Leistungs-bündel eine individuelle, nicht trennbare Problemlösung, deren Kosten es frühzeitig zielorientiert zu gestalten gilt. Darüber hinaus bieten Entwick-lungsnetzwerke den beteiligten Unternehmen die Möglichkeit, das Ent-wicklungsrisiko und den hohen Kapitalbedarf aufzuteilen und die unter-schiedlichen 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 Dienst-leistungen 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 Be-schreibung von Kosteneffekten in Entwicklungsnetzwerken. Zunächst werden wesentliche Charakteristika von Entwicklungsnetzwerken im all-gemeinen und Netzwerkkooperationen mit Prototypen im speziellen in Form eines Prozessmodells erarbeitet. Hinsichtlich eines pragmatischen Vorgehens kann die Differenzierung von Entwicklungsnetzwerken insbe-sondere aus organisatorischer, markt- und ressourcenorientierter Perspek-tive vorgenommen werden. Ein Schwerpunkt der Betrachtung und Charak-terisierung stellt dabei die organisatorische Perspektive dar, weil die Probleme von Entwicklungsnetzwerken und deren Lösungen mittels Proto-typen stark organisatorisch determiniert sind.

Wissensintegration in der verteilten Teamarbeit

Der bis in die jüngste Vergangenheit stark arbeitsteilig organisierte Pro-duktentwicklungsprozess wird durch die wachsende Zahl von hochspezia-lisierten Experten bestimmt, so dass neben der ablaufbedingten Taylorisie-rung eine wissens- und kompetenzorientierte Taylorisierung in der

14 1 Einleitung

industriellen Praxis zu beobachten ist. Dies erschwert die schnelle und fle-xible Integration von neuen Produktfunktionen und führt durch einen stark erhöhten Abstimmungsbedarf zu überproportional steigenden Planungs- und Koordinationsaufwänden. Studien zeigen, dass eine verstärkte und de-taillierte Planung jedoch nicht zielführend ist. Deshalb werden in der Zu-kunft vermehrt Methoden zur schnellen Wissensintegration und für eine effiziente Teambildung benötigt.

In den vergangenen Jahren sind Untersuchungen zu einer Standardisie-rung der Entwicklungsprozesse durchgeführt worden. Ergebnisse von For-schungsvorhaben und Beispiele aus der Industrie zeigen jedoch, dass ins-besondere die Entwicklung und Erprobung innovativer Produkte nur bedingt standardisierbar sind. Neue Ansätze aus dem Software-Management hinsichtlich der Wiederverwendbarkeit von Software-Bausteinen 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 Koope-ration zwischen den verschiedenen Teams innerhalb eines Unternehmens sowie zwischen den Teams und den Kunden bzw. den Zulieferern. Zusätz-lich werden bei komplexen Entwicklungsvorhaben, wie z. B. bei der Ges-taltung des Fahrzeuginnenraums, eine ganze Reihe von Subteams inner-halb 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 Planungswerkzeu-ge. 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 adapti-ves 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 Produktentwick-lungsprozesses eine große Herausforderung. Ein Problem stellt immer noch die situationsgerechte Bereitstellung von Prozess-, Konstruktions- und 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


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 einzelplatzori-entierten zu intelligenten und kooperationsorientierten Bearbeitungsstruk-turen zu gelangen. Dazu ist eine rollenspezifische und projektphasenab-hä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 Wissensin-tegration in adäquater Form visualisiert und zugänglich gemacht werden müssen. Eine intelligente Visualisierung muss dabei, im Gegensatz zu heu-tigen Systemen, durch Adaption den Wissensfortschritt der einzelnen ko-operierenden Experten unterstützen.

Aufgrund der zunehmenden funktionellen Abhängigkeiten innerhalb des Produkts entsteht zudem eine komplexe Vernetzung der heterogenen Ent-wicklungswerkzeuge. Um bei der Benutzung der Werkzeuge die Konsis-tenz der Ergebnisse zu gewährleisten, müssen neue Methoden zum Infor-mation Routing zwischen zu integrierenden Werkzeugen erarbeitet werden. Ein insbesondere in heterogenen und verteilten Umgebungen zu-nehmend an Bedeutung gewinnendes Problem liegt in der sicheren Über-mittlung 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üs-sen. Die Konvergenz, d.h. das Zusammenführen von traditionell getrenn-ten Medien zu einer gemeinsamen Infrastruktur erlaubt die Entwicklung von integrativen Kommunikationsdiensten für die kooperative Arbeitswei-se der Experten.

Für die Unterstützung der verteilten Zusammenarbeit von multidiszipli-när ausgerichteten Experten in der Produktentwicklung werden Instrumen-te 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 Ver-stä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 nega-tiven Einschätzung der Leistung von RPD Teams hinsichtlich der Einhal-

16 1 Einleitung

tung von Zeit, Produktentwicklungskosten und Produktqualität einherge-hen. Die Mitglieder selber empfinden dabei Stress und eine geringere Ar-beitszufriedenheit.

Für die Kooperation in den Teams sind drei unterschiedliche Muster zu identifizieren:

innerbetriebliche Kooperation in funktionsübergreifenden Teams in mit-telständischen Betrieben, innerbetriebliche Kooperation in bereichsübergreifenden Teams in in-ternational agierenden Unternehmen, unternehmensübergreifende Entwicklungsteams in mittelständischen Unternehmen.

Untersuchungen haben gezeigt, dass bei Unternehmen, die dem zweiten Muster entsprechen, mehr Probleme bezüglich der Kommunikation, Ko-operation und Wissensintegration im Vergleich zu den anderen beiden Ty-pen 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, Erfahrungs-wissen) 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 Organisati-onsstruktur, die Komplexität der Aufgabe, die Heterogenität des Teams, die technologische Unterstützungsmöglichkeiten und die Kreativitätsför-derlichkeit des Umfeldes unter besonderer Beachtung.

Um den Anforderungen gerecht zu werden, werden die Teams auf ver-schiedenen 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 wer-den kann. Hierzu dienen Portale die einen schnellen und strukturierten Zu-gang zu fachlichen und fachübergreifenden Informationen sowie informa-tionsverarbeitenden 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


gemeinsamen Wissensbasis zu erfüllen, stehen diese Informationen für je-den Experten spezifisch zur Verfügung. Dies kann durch den Einsatz adap-tiver Benutzungsoberflächen unterstützt werden. Um dieses zu ermögli-chen, müssen der Zugang und die Aufbereitung der Informationen untersucht werden. Dabei stehen neue Arten und Methoden der Darstel-lung und der Visualisierung von Daten insbesondere im Hinblick auf die Vernetzung im Vordergrund. Außerdem werden geeignete Adaptionskon-zepte, die sich auf die Auswahl der Inhalte und die Darstellung beziehen, analysiert.

Neben diesem spezifischen Zugang zu den Informationen ist eine Pla-nung für die Teams notwendig. Die Voraussetzung für das effektive und verzahnte Arbeiten von diesen verteilten Entwicklungsteams ist die Nut-zung der durch die flexiblen Organisationsprozesse geschaffenen Spiel-räume. Die Koordination autonomer Entwicklungsteams, die Unterstüt-zung 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 unter-stützt werden. Aus diesen Rahmenbedingungen und der dezentralen Struk-tur 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üt-zung einer teilweise automatisierten Koordination projektmanagement-spezifischer Tätigkeiten auf der einen Seite und zur Integration kooperie-render 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 An-spruch 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 Arbeitsumfeld-bedingungen 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 Kommu-nikation geschaffen. Diese Infrastruktur ermöglicht es, eine asynchrone In-

18 1 Einleitung

formation mit notwendigen prozessrelevanten Informationen zu hinterle-gen, um somit die Iterationen im Kommunikationsprozess zu minimieren. Durch die Implementierung gemeinsamer virtueller Arbeitsräume, die so-wohl synchron, als auch asynchron genutzt werden, können die hemmen-den 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 Produktent-wicklung lässt sich nur mit einer effektiven Unterstützung der Teammit-glieder erreichen. Diese setzt sich aus den Bereichen des Informationszu-gangs, 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 dy-namisches Wissen in Form von z.B. Ursache-Wirkungsketten repräsentie-ren. Produktentwicklung ist ein iterativer Prozess, der durch die Entste-hung und Verarbeitung von Produktdaten charakterisiert ist. Durch den intelligenten Einsatz von Regelmechanismen des ASN können diese in-konsistenten Produktdatenänderungen vermieden werden und die Prozess-steuerung aktiv im Sinne der Termintreue, Qualitätssteigerung und Kos-tenkontrolle 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, Bezie-hungsart, 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 wer-den 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äsentati-on im Rapid-Prototyping. Durch den reversiblen Charakter des ASN ist ein kontinuierlicher Aufbau einer dezentralen Wissensbasis erstmals möglich.


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, er-gonomische, funktionelle und klimatechnische Aspekte behandelt und die effiziente Erstellung hybrider Prototypen untersucht. Abhängig vom For-schungsschwerpunkt der Teilprojekte wird lediglich auf einzelne Kompo-nenten oder auf den gesamten Fahrzeuginnenraum zugegriffen.

Am Beispiel des Fahrzeuginnenraums wurden exemplarisch die im Sonderforschungsbereich gewonnen Erkenntnisse über neue Kooperations-strukturen, 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 Erkennt-nisse zur Anwendung der Forschungsergebnisse im industriellen Umfeld gewonnen.

RPD Toolbox

Die Weitergabe und Diffusion der Forschungsergebnisse an eine breite, in-teressierte Öffentlichkeit war speziell in der vierten Förderperiode ein wei-teres wichtiges Ziel des Sfb. Dazu wurde eine „RPD-Toolbox“ entwickelt, die laufend durch Veröffentlichungen über den aktuellen Stand der For-schung 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 Informatio-nen, 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 geglie-dert, in denen die Teilprojekte erfolgreich gemeinsam an einem For-schungsschwerpunkt arbeiteten (s. Abb. 1.4., Stand 2006).

Im Rahmen der Arbeiten des Projektbereiches A, „Grundlagen der Or-ganisation 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 Modellie-rung von Prozessen und Rollen des RPD sowie Konzepte für ihre Wieder-verwendbarkeit 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 Forschungs-arbeiten zusammen.

Im Rahmen des Projektbereiches D, „Erstellung virtueller und physi-scher Prototypen“ erfolgt die Entwicklung von Methoden zur Erzeugung von virtuellen Prototypen, insbesondere für die Gestaltung der virtuellen


Realität (VR) und zur Simulation und Visualisierung physikalisch-technischer Prozesse.

AGrundlagen der

Organisation und Planung

BVernetztes Wissen für die iterative Entwicklung von Proto-

typen

CWissens-

repräsentation und Kommunikation

DErstellung vir-

tueller und physischerPrototypen

ERechner-

unterstützte Fahr-zeugkonzeption

B1 Modellierendes vernetz-ten Denkens

und Handelns in der Kon-

struktion (Bertsche)

C1Ganzheitliche Mo-

delle zur Repräsenta-tion aktiven Wissens

(Roller)

D1Virtuelle Reali-tät als Gestal-tungs-, Evalu-ierungs- und

Kooperations-werkzeug

(Westkämper / Kern)

E1 Rechnerunterstützte Fahrzeugkonzeption

am Beispiel Fahr-zeuginnenraum

(DC AG)

A2Planungsmethoden

für dezentrale Entwicklungs-

teams (Spath)

B2Qualitäts-

management im Rapid

Prototyping (Westkäm-

per)

C2Adaptive Benut-zungsoberflächen

(Weisbecker)

D2Visualisierung und Simulation physikalisch-technischer Vorgänge

(Lang / Resch) A3

Arbeitswissen-schaftliche Kon-zeptionierung ko-

operativer Arbeitsformen für die Entwicklung

innovativer Produkte (Spath)

C3 Teamorientiertes

Kommunikations-system für vernetztes

Arbeiten (Warschat)

D3Aufbau und Betrieb von

Rapid Prototy-ping-

Prozessketten(Westkämper)

C4 Integrationsplattform für aktive Wissens-

kommunikation (Roller / Warschat)

D4Rapid Prototy-ping Labor zur

Herstellung funktionalerund techni-

scher Prototy-pen mittels La-sertechniken (Dausinger /

Eyerer) D5

Entwicklung von Werkzeu-gen für Proto-

typteile(Wagner)

Abb. 1.4. Gliederung in Projektbereiche und Teilprojekte

22 1 Einleitung

Dieses Basiswissen über die verschiedenen Technologien wie VR, Ra-pid 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 Entwicklungs-schritte 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 Be-reich 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 Gründung des Sfb 374 „Entwicklung und Erprobung innovativer Produkte – Rapid Prototyping“

1998 Beginn der zweiten Förderperiode 2001 Beginn der dritten Förderperiode 2003 Gründung des Transferbereichs 41 „Entwicklung und Erprobung

innovativer Produkte“ (bis 2005). Folgende Teilprojekte wurden bearbeitet:

Kostenmanagement von Produkten und Dienstleistungen in Entwicklungsnetzwerken, Prof. Horváth Feature-Erkennung und Segmentierung in Punktwolken mit Multisensorik, Prof. Westkämper Lasersintern von Polymeren mittels Nd:YAG-Laser, Prof. Ey-erer

2004 Beginn der vierten Förderperiode 2006 Start des Transferbereichs 65 (bis 2008) mit folgenden Teilprojek-

ten:Aktives sematisches Konstruktions- und Zuverlässigkeitsnetz, Prof. Bertsche Arbeitswissenschaftliche Gestaltung wissensintensiver Koope-rationsprozesse für die Entwicklung innovativer Produkte, Prof. Spath

2006 Abschluss der Forschungsarbeiten des Sfb 374

1.2 Integrationsszenario 23

1.2 Integrationsszenario

Den Begriff der Produktentwicklung assoziiert man meist mit dem traditi-onellen Vorgehen der Entwicklung von Produkten. Demnach gliedert sich die Entwicklung grob in die fünf Abschnitte:

PlanenKonzipierenKonstruierenAusarbeitenHerstellen

Am Ende jeder dieser Phasen steht ein Bewertungs- und Auswahlpro-zess, 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- o-der Qualitätsmerkmale unberücksichtigt bleiben. Je später der Fehler dann gefunden wird, desto zeit- und kostenaufwändiger sind die dann anfallen-den Korrekturmaßnahmen. Innerhalb der bereits durchlaufenen Arbeits-schritte muss zum richtigen Entwicklungspunkt zurückgesprungen werden und die nachfolgenden Schritte incl. Überprüfungen, etc. abermals abgear-beitet werden. Eine optimale und gleichzeitig aber auch schnelle und kos-tengü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ämmer-lein über einen langen Zeitraum hinweg zu entwickeln und mit einem ho-hen 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 un-terschiedlichen Produkten arbeiten oder wenn neuartige Organisations-formen 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äu-fig das Schlagwort Rapid Prototyping verwendet. Dies ist jedoch nur be-dingt korrekt, denn eine Beschleunigung des Entwicklungsprozesses ist vor allem verknüpft mit einem Umdenken bzgl. der Organisation, der Vor-gehensweise 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 Ent-wicklung.

Wie wird aber nun Rapid Prototyping in der beschleunigten Produktent-wicklung eingesetzt?

Die Technologien, die unter dem Begriff „Rapid Prototyping“ zusam-mengefasst werden, haben ein gemeinsames Ziel, das sie auf unterschied-lichsten 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 wahrs-ten 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 Modell-erstellung.

Konzeptmodell Geometriemodell 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 Design-Varianten. Auch hier können verschiedene Studien zum Design, als Proto-typ vorliegend, wertvollere Dienste bieten, als eine Computersimulation


dies vermitteln kann. Einzige Alternative hierzu stellt hier die virtuelle Re-alität (VR) dar, die die fehlende räumliche Tiefe zu kompensieren vermag und gleichzeitig die Vorzüge der Arbeit mit Computersystemen kombinie-ren kann.

Das Geometriemodell dient der Überprüfung der Maßhaltigkeit und To-leranzen. Das Material ist nicht zwangsläufig mit dem angestrebten Ferti-gungsmaterial identisch und auch Oberfläche, Farbe und mechanische Ei-genschaften müssen dem Endprodukt nicht entsprechen.

Ein Funktionsmodell dagegen muss zumindest kurzzeitig ähnlichen Be-lastungen widerstehen wie das spätere Produkt, damit seine Funktion an-hand des Prototypen auch verifiziert werden kann. Auch wenn viele Frage-stellungen bereits am Rechner simuliert werden können, stecken einige Simulationswerkzeuge noch in den Kinderschuhen. So bedarf z.B. die Un-tersuchung 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:

Als „Concept Modelling“ bezeichnet man i.d.R. Funktions-Prototypen, die als physikalisches Modell des Produktes alle oder einzelne Funktio-nen nachbilden. „Rapid Tooling“ bezeichnet RP-Verfahren, die ein Werkzeug herstel-len, welches wiederrum zur Fertigung von Serien eingesetzt werden kann.„Rapid Manufacturing“ bezeichnet die Verfahren, die Fertigteile erzeu-gen, 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 Produkt-entwicklung. Gewaltiges Optimierungspotential bieten auch die Schnitt-stellen 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 Sonderforschungs-bereich (Sfb) 374 mit dieser großen Bandbreite an Themen rund um Me-thoden und Verfahren zur beschleunigten Produktentwicklung.

1.2.1 Grundlegende Verbesserungen

Während die Produktentwicklung und die Beteiligung der unterschiedli-chen 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 ge-langen.

Besondere Beachtung fanden hierbei die Schnittstellen zwischen den Bereichen, da hier erhebliche Informationsverluste auftreten, die z.T. zeit-aufwändige und fehlerträchtige Nacharbeiten und entsprechenden Koordi-nationsaufwand 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 folgen-de Iterationszyklen und verbesserte Kommunikations- und Koordinations-formen zwar mindern, aber nicht vollständig unterbinden.

Durch die entwickelten Methoden unterstützt der Sfb 374 aber den deut-lichen Trend zu mehr Virtualisierung in der Produktentwicklung.

Waren zuvor viele Meilensteine nur durch die Herstellung realer Proto-typen erreichbar, können diese nun vermehrt mittels Digital Mock-ups (DMUs) getestet, betrachtet und verifiziert werden. Auch hier liefert der Sfb 374 seinen Beitrag.


Abb. 1.5. Kooperationsbeispiel der Teilprojekte des Sfb 374 untereinander

1.2.2 Integration der Teilprojekte am Beispiel eines Pkw-Cockpits

Um die Beiträge aller Teilprojekte am Sonderforschungsbereich eingehend zu beschreiben, wurde in den entsprechenden Arbeitskreisen die Entwick-lung eines Pkw-Cockpits der MB A-Klasse (Typ W168) nachgebildet. An diesem Beispiel ließen sich in Zusammenarbeit mit dem Kooperations-partner, 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 Kom-plexität der Themenfelder können an dieser Stelle die durchgeführten For-schungsarbeiten 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 Entwicklungsstadi-um (Quelle: DaimlerChrysler AG)

Organisation und Planung

Die Entwicklung eines Pkw-Cockpits erfordert die Integration verschiede-ner Teams, die unterschiedliche Entwicklungaufgaben bewältigen müssen. In einem Team, das sich zum Beispiel auf die Konzeption und Entwick-lung 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 ei-nem 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 ge-meinsames Ziel: die Entwicklung eines bedienfreundlichen, ergonomi-schen, 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 Ent-wicklungsverläufen äußert, steht der Projektleiter, vor der Herausforde-rung, unterschiedliche Expertisen und Perspektiven der jeweiligen Exper-ten 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


bedienen. Auf Basis typischer Barrieren der Kooperation und Wissensin-tegration 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 voran-getrieben und zum anderen die Steuerung der Wissensintegration vermit-telt 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 Entwick-lung 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 Ent-wicklung des Pkw-Cockpits gewollt. Mit dem in Kapitel 2.3 beschriebenen »entwicklungsfähigen Projektplanungssystem« wird ein Unterstützungsin-strument vorgestellt, in dem auf Basis generischer Prozessmodule, die über Parameter miteinander verbunden sind, die vielfältigen von unterschiedli-chen, 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 Iterations-zyklus vermuteten, Verursacher propagiert werden und durch den Einsatz eines problemlösungsorientierten Kompetenzmanagements schneller abge-stimmt 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-IT-Infrastruktur 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 geomet-rischen 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 Semanti-schen Netz (ASN) gespeichert. Der Vorteil des ASN gegenüber klassi-schen Datenbanken besteht darin, dass es möglich ist zur Laufzeit Daten-objekte 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 Be-dienelements, durch direkte Anpassung des Datenmodells zu berücksichti-gen.

Darüberhinaus bildet die in Kapitel 4.2 beschriebene agentenbasierte RPD-Middleware die Schnittstelle zum ASN. Sie bietet den Experten zu-sätzliche Funktionalität an, die diese im Rahmen ihrer interdisziplinären Zusammenarbeit unterstützen. So ist es, um ein Beispiel zu nennen, mög-lich, Überwachungspunkte als Trigger im ASN zu setzen, um über Verän-derungen, die durch einen anderen Experten ausgelöst wurden, informiert zu werden. Ändert sich die Form eines Bedienelements und hat der Kon-strukteur 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 zeit-nah 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 Teamorientier-te Kommunikationssystem (Kap. 4.3). Dieses unterstützt die interdiszipli-näre Zusammenarbeit der Experten durch den Bereitstellung eines oder mehrerer virtueller Kommunikationsräumen. Wird bspw. durch die Verän-derung eines Bedienelements und die damit verbundene Benachrichtigung des Cockpit-Konstrukteurs ein Fertigungskonflikt aufgedeckt, so können sich beide Konstrukteure im teamorientierten Kommunikationsraum tref-fen und unter Einsatz verschiedener Kommunikationsmittel, wie z.B. ei-nem virtuellen Flipchart, das Problem diskutieren und lösen. Dabei können Informationen aus dem ASN direkt in den Kommunikationsraum einge-bracht werden.

Als oberste Schicht wird in Kapitel 4.4. die adaptive Benutzungsober-flä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 zuge-schnitten 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.


Kosten, Qualität und Zeit

In Kapitel 3 finden sich Methoden, Ansätze und Werkzeuge, um die be-schleunigte Produktentwicklung hinsichtlich der Aspekte Qualität, Ent-wicklungskosten 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 Anforderungslis-te, über verschiedene Entwicklungsstufen, bis hin zur Erstellung eines ers-ten 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 Entwick-lung 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 verbes-sern helfen sollten. In Kap. 3.3 werden Methoden und Tools zum Komple-xitätsmanagements und der Qualitätssicherung gegeben. Hierbei werden z.B. Merkmale des Produktes extrahiert und daraus die relevanten Quali-tätsmerkmale abgegrenzt. Ebenso wurde ein Referenzmodell zum umfas-senden Qualitätsmanagement in dynamischen Strukturen erarbeitet. Es dient unter anderem als Wissensbasis für das ASK/ASZ und erhält seiner-seits 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 Her-stellkosten im Sinne des Target Costings nicht alle anfallenden Kosten er-fassen kann.

In Kap. 3.4 wurde untersucht, wie im Rapid Product Development die Entwicklung hinsichtlich der Prozesskosten kontrolliert und gesteuert wer-den kann. So wurden Leistungsbündel erfasst und bewertet und schluss-endlich 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 Mit-telkonsole 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 visuali-siert 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 ausge-klü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 Ba-sis und den beschriebenen Untersuchungen wurden auch Teile des Cock-pits mittels Rapid Prototyping Verfahren gefertigt. Dabei kamen neu ent-wickelte RP-Verfahren, wie das „Multi Material Modelling“ (MMM) (Kap. 5.7) zum Einsatz, wie auch das „Selektive Lasersintern“ an Hoch-temperaturkunststoffen (Kap. 5.10) oder das Lasergenerieren im modula-ren 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 Kunstoff-werkzeug für die Umformpresse erzeugt, was im Vergleich zu herkömmli-chen 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 in-formationstechnische Integration des Entwurfsprozesses in die RPD-Prozesskette. Forschungsergebnisse aus diesem Bereich werden in Kap. 5.6 vorgestellt.

Die Details zu den verwendeten Technologien, Methoden und Simulati-ons- 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 Diffe-renzierung 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 Neuentwick-lungen, eine gleichzeitige Verkürzung der Entwicklungszeit, die kontinu-ierliche 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 Erkenntnisfort-schritte angepasst. Erst zu einem späten Zeitpunkt wird die Entscheidung getroffen, welcher der verschiedenen Produktansätze tatsächlich in die ab-schließenden Entwicklungs- und späteren Produktionsphasen gelangt. In Anlehnung an das Motto „Survival of the fittest“ gelangen also nur dieje-nigen Produktvarianten in die (Re)Produktion, die sich als die am besten den Markt- und Produktionsanforderungen entsprechenden erwiesen ha-ben. Die wichtigsten Merkmale dieses Ansatzes umfassen:

Betonung der frühen Entwicklungsphasen parallele Entwicklung alternativer Produktkonzepte schnelle iterative Schleifen, die den Prozess von der Konstruktionsidee bis hin zur Bewertung in einem verhältnismäßig kleinen Zeitraum ab-bildenspäte Festlegung und Spezifikation des Produkts

34 2 Organisation und Wissenskooperation

schnelle Erstellung von physischen, virtuellen und hybriden Prototypen frühes Ergebnisfeedback 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 Be-reichen 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 Produk-tenwicklungsteams gegensätzliche Ziele verfolgen müssen: Einerseits möglichst innovative und kreative Produkte entwickeln, andererseits mög-lichst wenig Zeit und Kosten während der Produktentwicklung, aber auch in Hinsicht auf die Produktherstellung zu verursachen bzw. festzuschrei-ben.

Dieser Zielkonflikt soll im RPD-Kontext optimiert werden. Unterstüt-zungsmöglichkeiten für die Teammitglieder müssen deshalb einerseits die Berücksichtigung der zeit-, kosten- und qualitätsbezogenen Vorgaben för-dern, zum anderen den notwendigen Freiraum ermöglichen, der erforder-lich ist, um innovative Ergebnisse zu erzielen. Nur so kann eine quantitati-ve 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 Ko-operationsprozesse optimiert sind, aus denen Innovationen hervorgehen sollen. Innovative Lösungs- und Produktkonzepte setzen voraus, dass un-

2.2 Anforderungen an Produktentwicklungsteams 35

terschiedliches, aber komplementäres Wissen von Experten neu kombi-niert wird, um neuartige Funktionen, Produkteigenschaften oder vollstän-dig 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 Entwick-lungsaufgaben, die Fragestellungen aus unterschiedlichen technischen, wirtschaftlichen und organisatorischen Fachgebieten in sich vereinen, set-zen 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 Zusam-menarbeit 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 entste-hen und neue Lösungswege für komplexe Problemstellungen sichtbar wer-den. Gleichzeitig bedeutet die Vielzahl der repräsentierten fach- und funk-tionsgeprä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 Innovati-onsprozess, da sie die Rekombination des heterogenen Wissens verhin-dern. Durch die Bildung einer gemeinsamen Wissens- und Informationsba-sis, an der alle Teammitglieder beteiligt sind, kann dieser Integrations-prozess wirkungsvoll unterstützt werden. Die Reibungsverluste, die durch die unkoordinierte und konfliktträchtige Auseinandersetzung der Team-mitglieder 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 effi-zient die Fach- und Funktionsexperten in den Produktentwicklungsteams ihr Wissen integrieren und für die Entwicklung neuer Lösungswege nut-zen.

2.2.2 Komplexitätsanforderungen

Obwohl die Anforderungen an die Planung der parallelen Entwicklungsak-tivitäten steigen, werden durch deren Flexibilität (z.B. durch Verwerfen oder Neuaufnahme eines Produktansatzes) die Möglichkeiten einer forma-len Planbarkeit von Entwicklungsprojekten, die dem Konzept des RPD


folgen, verringert. Hinzu kommt, dass die Entwicklung und Erprobung in-novativer Produkte nur begrenzt standardisierbar ist, so dass häufig ledig-lich auf der Ebene einzelner Lösungsschritte Elemente wiederverwendet werden können. Zur Komplexität tragen auch die zunehmenden funktiona-len Abhängigkeiten innerhalb des Produkts bei. Nicht zuletzt muss der um ein vielfaches größer werdende Lösungsraum durch die einzelnen Spezia-listen bearbeitet werden können, ohne dass für den Einzelnen der Gesamt-zusammenhang aus dem Blick gerät. Die Auswirkungen der steigenden Komplexität des eigentlichen Entwicklungsprozesses werden darüber hin-aus verstärkt durch die teaminterne Komplexität, die durch die fach- und funktionsbezogenen Heterogenität der beteiligten Experten hervorgebracht wird.


Ausgelöst durch die Flexibilisierung und steigende Komplexität des Ent-wicklungsprozesses im RPD, stehen Entwicklungsteams vor einer doppel-ten Herausforderung: Zum einen steigen die Anforderungen an die koope-rative Informationsverarbeitung im Team, die bedingt sind durch die erhöhte Menge an Informationen, die wachsende Geschwindigkeit des In-formationsaustauschs als auch durch die erhöhte Menge der technischen und organisatorischen Schnittstellen im RPD-Prozess. Zum anderen ver-stärkt die Unterschiedlichkeit der im Team vertretenen Fachdisziplinen und Unternehmensfunktionen die Anforderungen an den internen Wis-sensaustausch. 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üt-zung der Produktentwicklungsteams erforderlich, um den RPD-Prozess ef-fizient umsetzen zu können.


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

Im Gegensatz zur externen Informationskomplexität ist die interne Wis-senskomplexität für Entwicklungsteams nicht offensichtlich. Durch die Häufigkeit, Intensität und Irregularität von Änderungen hinsichtlich der Zielvorgaben, Vorgehensweisen und Randbedingungen sind Entwick-lungsprojekte durch eine Dynamik gekennzeichnet, deren Konsequenzen sich in zeitlich veränderlichen, unklaren Zielvorgaben sowie unvollständi-gen Rahmenvorgaben und Einflussgrößen äußern. Aufgrund der hohen Anzahl der am Produktentwicklungsprozess Beteiligten, der hohen Dyna-mik und der starken inhaltlichen Vernetzung der einzelnen Elemente ent-stehen 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 ei-ner intensiven informationstechnologisch unterstützten Kommunikation abhängt. Aufgrund unvorhersehbarer Entwicklungszyklen sind häufige und schnelle Planungsprozesse notwendig, die sich an die Iterationszyklen an-passen können.

Wie zahlreiche Erfahrungen aus der Praxis zeigen, werden die Heraus-forderungen 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.


2.2.3 Kooperationsanforderungen

Die Arbeitsbedingungen im RPD-Kontext zeichnen sich durch einen stark erhöhten Abstimmungsbedarf und überproportional steigende Koordinati-onsaufwände aus. Die Entwicklungsteams kennzeichnet eine dezentrale Teamstruktur mit hohem Selbstorganisationsgrad, in denen eine Integrati-on von planenden und ausführenden Tätigkeiten realisiert wird. Dies be-deutet eine Abkehr von bisherigen, stark arbeitsteilig organisierten Bear-beitungsstrukturen, die den gestiegenen Innovations- und 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 Teammit-gliedern 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 Anfor-derungen sowohl an die interne wie an die teamexterne Zusammenarbeit mit einer Vielzahl von Ansprechpartnern.


Die Kooperation in fach- und funktionsgemischten Entwicklungsteams gestaltet sich aus den schon oben beschriebenen Gründen häufig schwie-rig. 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 Kommunikations-prozesse im Team. Gleichzeitig steigt der Stellenwert der Koordination der einzelnen Arbeitsbeiträge, da die parallele Bearbeitung mehrerer konkur-rierender Entwicklungsansätze ständig an den übergeordneten Entwick-lungszielen ausgerichtet werden muss. Zuletzt erfordert auch die organisa-torische 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 Produktentwick-lungsteams verstärkt potenzielle Kooperationsprobleme, da sie eine inten-sive Auseinandersetzung zwischen den einzelnen Teammitgliedern erfor-dert. 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.).


Abb. 2.2. Mögliche Erscheinungsbilder mangelnder Wissensintegration in inter-disziplinä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 skiz-zierten 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, neuar-tige 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 Kommuni-kation 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.


2.3 Planungsmethoden innovativer Produkte in dezentralen Teams

Die im RPD angestrebte enge, interdisziplinäre Zusammenarbeit von Ex-pertenteams setzt voraus, dass die beteiligten Experten nicht nur einen Zugriff auf den Planungs- und Ressourcenstatus in bezug auf ihre indivi-duellen und teambezogenen Aktivitäten haben, sondern auch die Abhän-gigkeiten ihrer Aufgabe von den nächsten innerhalb des Prozesses zu voll-ziehenden 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 dezen-tral verteilten Teams vor besondere Herauforderungen. Forschungsergeb-nisse zeigen, dass für die erfolgreiche Planung komplexer Entwicklungs-prozesse evolutionäre Aspekte der Planung in Form von intelligenten Abstimmungsmechanismen und ein effizientes Management von Exper-tenkompetenzen die Planung von dezentral verteilten Teams auf der Basis adaptiver Prozesse ergänzen müssen, damit in komplexen Entwicklungs-projekten 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 er-reichen, indem das Planungsproblem vollständig mit all seinen Interdepen-denzen erfasst und zu einem wohldefinierten, abgestimmten und bewuss-ten 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 Vorgehenswei-se betrachtet. Im Rahmen des RPD erscheint die Herausforderung, Trans-parenz in eine schlecht strukturierte Problemstellung durch Zerlegung des Planungsproblems in einfachere, leichter zu lösende Teilprobleme zu brin-gen, 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

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. nur offiziell autorisierte Planungsverantwortliche sind die Träger der Planung und deren Abstimmung erfolgt über eine entsprechende Autori-tätshierarchie mit ihren formalen Kommunikations- und Kontrollsyste-men. Als Konsequenz wird die Dynamik und Flexibilität des dem Kon-zept des RPD folgenden Entwicklungsprozesses mehr gehemmt, denn unterstützt [2.21], [2.22], [2.83]. nur das in quantifizierbarer Form explizierbare Wissen Eingang in die Planung findet. Implizites Wissen, z.B. in Form von intuitiven Fertig-keiten der am Produktentwicklungsprozess Beteiligten, also deren Kompetenzen, tritt gar nicht in den Vordergrund [2.83], [2.88]. das bei der Lösung von Problemen zur Entwicklung innovativer Produk-te notwendige Wissen von Experten in einem zeitraubenden Lernpro-zess 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]. die Ziele eines Prozesses zur Entwicklung eines innovativen Produkts werden mit der Problemlösung simultan entwickelt und nicht aus über-geordneten Zielen abgeleitet, zumal die für die Planung relevante In-formationsgrundlage 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 Planungside-als für die Planung und Steuerung von Prozessen innerhalb von RPD-Projekten 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


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ög-lichkeiten sind das Ergebnis der intellektuellen Anstrengungen der Planen-den. Die Komplexität von Problemen bei der Entwicklung innovativer Produkte entsteht nicht nur durch vielfältige, dynamische Wechselbezie-hungen innerhalb des Entwicklungsprozesses. Sie erhöht sich vor allem durch die Berücksichtigung unterschiedlicher Perspektiven der an der Pla-nung Beteiligten bei der Problemabgrenzung und deren Einbeziehung in den Planungsprozess. Unterschiedliche Perspektiven werden von der evo-lutionären Planung erwünscht, da sie vernachlässigte Sichtweisen und Problemstellungen aufdecken können, zu einer besseren Problemsicht bei-tragen 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 ver-mag [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 er-reichen. Simultan zum Problemlösungsprozess bei der Entwicklung inno-vativer 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älti-gen 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 Entwicklungspro-zess Beteiligten zu einem Plan. Planung ist danach ein Prozess des expe-rimentellen Lernens mit dem Ziel, Fehler im Problemlösungswissen suk-zessive 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].


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 Ge-meinschaft 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 Konkreti-sierung von Problemlösungen dienen. Auf dieser Basis erlauben negative bzw. positive Heuristiken die Identifikation von Veränderungsnotwendig-keiten 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 rich-tungsweisend. Eine sinnvolle Verarbeitung eines bei der Entwicklung in-novativer Produkte auftretenden komplexen, neuartigen Problems ist in ei-ner komplexitätsreduzierenden Struktur nicht möglich. Die Selbstorga-nisation wird als ein Strukturierungsmuster angesehen, das ein größeres Komplexitätsverarbeitungspotenzial besitzt als andere Strukturierungs-muster, wie z.B. hierarchische Planungssysteme [2.66]. Informations-technische 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ör-dern, die das Fundament für die Lösung der bei der Entwicklung eines in-novativen Fahrzeuginnenraums auftauchenden Problemen bilden.

Die evolutionäre Planung ist wesentlich durch folgende Merkmale ge-kennzeichnet [2.85], [2.101]:

Innovative Lösungsansätze zur Lösung von Problemen bei der Produkt-entwicklung sind subjektive Konstrukte, die nach Maßgabe der Wert-vorstellungen, Interessen, dem Hintergrundwissen und den Überzeu-gungen der an der Problemlösung bzw. dem Entwicklungsprojekt beteiligten Experten interpretiert werden. 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. Auf der Grundlage von Annahmen, Grundüberzeugungen und Werten wird das zur Handhabung von Problemen der Produktentwicklung not-wendige Problemlösungswissen sukzessive entwickelt und orientiert sich am inkrementellen Ideal.


Die sich aus der Planung entwickelnden Handlungskonzepte sind vor-läufig, potenziell fehlbar und dienen als Werkzeuge, die für den Planer lediglich Orientierungscharakter haben.Vor dem Hintergrund der Selbstorganisation vollzieht sich die Planung in Entscheidungsgremien, in denen sich die Planungs- respektive Ent-scheidungsträger problembezogen immer wieder neu ordnen. Die Organisation der Planung erfolgt nicht durch eine formale Autorität. Das problembezogene Expertenwissen ist das Fundament für die Ein-flussnahme 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 As-pekte der evolutionären Planung in die Methoden und Instrumente zu in-tegrieren, 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 dy-namischer 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 Unter-nehmen auf die internen Ressourcen zurückzuführen ist. Erfolgreiche Un-ternehmen verstehen es seiner Meinung nach, ihre Ressourcen optimal zur Wertschöpfung einzusetzen [2.92]. Dieser Ansatz wurde Mitte der siebzi-ger 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 Wettbewerbser-folges auf bestimmte Produkt-Markt-Positionen keinen umfassenden Er-klärungsansatz mehr boten.


Zunehmend stehen wieder intangible Ressourcen eines Unternehmens im Vordergrund der Betrachtung (in Anlehnung an Penrose auch als Re-source-based-view bezeichnet). So stellen Prahalad / Hamel fest, dass die Kernkompetenzen »the most powerful way to prevail in global competi-tion« sind [2.98]. Der Competence-based-view als dynamischer Strategie-ansatz 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 Ergeb-nis, 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 Wettbe-werbsvorteile 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 un-einheitlich 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 Anforde-rungen zur Weltbewältigung durch entsprechende Herausbildung bemeis-ternder Fähigkeiten des psychischen Apparates zu bewältigen“ definiert. Roth übernahm 1971 diesen Gedanken in seiner Pädagogischen Anthropo-logie und unterschied die vier Kompetenzbereiche in Sach- oder Fach-kompetenz, 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älti-gung 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.


Abb. 2.3. Definition von Kompetenzen

Innerhalb der Betriebswirtschaftslehre werden Kompetenzen als unter-nehmenseigene Ressourcen verstanden, die ein Unternehmen zur Erfüllung seines Geschäftszweckes benötigt [2.9]. Aufgrund des Paradigmenwech-sels im strategischen Management vom „market-based view“ zum „resour-ce-based view“ Anfang der neunziger Jahre verschiebt sich der Betrach-tungsgegenstand 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 Entwick-lung 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 Umkehr-schluss 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 Produktent-wicklungs-, Produktions- und Fabrikstrukturen konzentrieren sich auf die Gestaltung von Schnittstellen auf der Basis partnerschaftlicher und fluss-systemorientierter 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änderungs- und Entwicklungsprojekte auf dies Gestaltung rekursiver Organisations-strukturen und einer adaptiven Prozesslenkung zielen, ohne im Detail auf Gestaltungsempfehlungen einzugehen [2.107]. Für eine Detaillierung die-ser Gestaltungsempfehlungen ist es notwendig, Aspekte eines informati-


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 Entwick-lung, 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 Kompe-tenzen 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 Iterations-zyklen in allen Phasen der Produktentwicklung, die dem Konzept des Ra-pid Product Development (RPD) folgen, bestand darin, Planungsmethoden und -instrumente zu einem System zusammenzuführen, das eine enge Zu-sammenarbeit 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 Dy-namik der RPD-Prozesse müssen die eingesetzten Planungsmethoden und


-instrumente in der Lage sein, die sich in den Iterationszyklen dynamisch ergebenden Anforderungen an die Lösung von Problemstellungen im Ent-wicklungsprozess durch die Planung berücksichtigen zu können. Die opti-male Unterstützung der Experten des RPD bei der Koordination ihrer teaminternen und -übergreifenden Aktivitäten während sämtlicher Iterati-onszyklen 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 Allen-Zeitintervallrelationen selbst zu bestimmen. Die Definition teamübergrei-fender Schnittstellenaktivitäten erlaubt eine Vernetzung teambezogener Teilpläne, deren Aggregation zu einem Gesamtplan sowie eine kennzah-lenbasierte, situationsspezifischen Bewertung dieser Pläne [2.131].

Im zweiten Schritt wurde das TOPP um Methoden zur Ressourcenpla-nung 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 beseiti-gen [2.71].

Im dritten Schritt erfolgte eine Erweiterung des Systems um eine Pla-nungsmanagementkomponente, die eine dezentrale Generierung, Vernet-zung und Wiederverwendung von Aktivitäten und Teilprozessen auf der Basis eines Modells zur iterativen Definition von Rollen und Aufgaben er-laubt. Das Meta-Modell zur Definition generischer Prozessmodule erlaubt jedem dezentral verteilten Entwicklungsteam seine von ihm zu koordinie-renden (Teil-) Prozesse bis auf die Ebene von Einzelaktivitäten über para-metergetriebene Verknüpfungsregeln zu verbinden. Die Einbindung und Archivierung dieser generischen Prozessmodule als »Lessons learned« un-terstützen die Entwicklungsteams bei der Planung zukünftiger Projekte [2.32], [2.72], [2.73].

Diese »Lessons learned« gewährleisten, dass das Erfahrungswissen ver-gangener 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 RPD-Projekten beteiligten Experten implementiert. Dazu wurde eine Kompo-nente entwickelt, die es den Experten erlaubt, in den Iterationszyklen des RPD-Prozesses auftauchende Probleme mit Hilfen von Expertenkompe-tenzen schnell lösen zu können bzw. sich schnell mit anderen Experten ab-stimmen zu können. Das Ziel bestand darin, auf der Basis eine problemlö-sungsorientierte Management von Kompetenzen und der darauf


aufbauenden Implementierung dynamischer Abstimmungsmechanismen eine Beschleunigung von Planungsentscheidungen zu bewirken [2.19].

Abschließend wurden die bisherigen Komponenten zu einem »entwick-lungsfähigen Projektplanungssystem« migriert.

Funktionalitäten des »entwicklungsfähigen Projektplanungssystems«

Nachfolgend werden die wesentlichen Funktionalitäten des »entwicklungs-fähigen Projektplanungssystem« einschließlich einiger Hinweise hinsicht-lich der technischen Realisierung dargestellt. Die dargestellten Funktiona-litäten orientieren sich dabei an den besonderen Anforderungen, die das RPD an die Projektplanung stellen, beziehen sich auf

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 Startbedin-gungen abhängig gemacht werden, welche „logisch und“-verknüpft sind. Die Startbedingungen können sich auf die Parameterwerte beliebiger ande-rer Aktivitäten beziehen. Eine Aktivität ist somit lediglich von den rele-vanten 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 Startbe-dingungen einer Aktivität erfüllt, so wird der in jeder Aktivität enthaltene Basisparameter Kann beginnen automatisch durch Durchführung einer Pa-rameteränderungsaktion (ChangeParameterAction) auf den Wert Ja ge-setzt. 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.


Abb. 2.5. Schematische Darstellung der Verknüpfung von Aktivitäten über Start-bedingungen

Wenn der Beginn einer Aktivität direkt oder indirekt von sich selbst ab-hä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 Akti-vitä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 parametergetrie-ben Problemlösung implementierte Mechanismus vorhanden ist, sind Itera-tionen 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 (A-daptable Process) unterteilt. Diese bilden eine baumförmige Prozesshie-


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

Abb. 2.7. Projektstruktur

Abb. 2.8. Vererbungshierarchie von Parametern


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 Umset-zung 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 benutzer-

definierter Zeichenketten

Abb. 2.9. Implementierte Parameter im »entwicklungsfähigen Projektplanungs-system«

Jeder Aktivität werden bei der Erzeugung drei Basisparameter zugeord-net:

Kann beginnen (BooleanParameter): Beschreibt, ob alle Startbedingun-gen der Aktivität erfüllt sind. Hat begonnen (BooleanParameter): Beschreibt, ob die Durchführung der Aktivität bereits begonnen hat. 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 Pa-rameter zugeordnet werden, um spezifische Eigenschaften und Zustände einer Aktivität zu beschreiben.

Vor dem Hintergrund der parametergetriebenen Verknüpfung von Akti-vitäten ist der Beginn von Aktivitäten vom Fortschreiten bei der Durchfüh-rung 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 »ent-wicklungsfähige Projektplanungssystem« ein Mechanismus implementiert mit dem eine Ressource in Abhängigkeit von Bedingungen automatisch


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 Ressourcenkonflik-ten 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 Betrach-tung 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 jeweili-gen Aktivität angezeigt. Die Auflösung des Konflikts wird durch folgende Strategien ermöglicht:

Entfernen der Ressourcenzuordnung Ändern des Zuordnungszeitraums Eskalationsmechnismen zur Lösung des Ressourcenkonflikts

Bei der Entfernung einer am Konflikt beteiligten Aktivität hebt der Ver-antwortliche 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 Beteilig-ten erforderlich.


Im Rahmen einer Änderung des Zuordnungszeitraums verkürzt oder verschiebt einer der Konfliktbeteiligten freiwillig seine Ressourcenzuord-nung in einen Zeitraum, in dem die Ressource nicht belegt ist. Auch hier-bei treten keine negativen Effekte für andere Projektbeteiligte auf, was de-ren Zustimmung überflüssig macht.

Bei Ressourcenkonflikten, bei denen kein Beteiligter auf die Belegung der Ressource im Konfliktzeitraum freiwillig verzichtet, müssen Konflikt-lö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 Res-sourcenkonflikts 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 Kon-flikt 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 erfol-gen.

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


(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 ange-zeigt. 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 Zu-sammenhang stehenden Funktionalitäten an. Außerdem ist bei den Detail-ansichten vieler Objekttypen eine weitere Navigation zu den mit dem Ob-jekt in Zusammenhang stehenden Objekten möglich. So kann beispielsweise über die Detailansicht von Aktivitäten direkt zu deren Vor-gä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 an-zuzeigenden Aktivität (Viewpoint) deren Vorgänger- und Nachfolgeaktivi-tä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 Notwendig-keit 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.


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 Abbil-dung von Iterationen auf diese Weise nicht möglich, da eine solche Iterati-on 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.


Abb. 2.13. Vereinfachte Darstellung eines Prozesses mit Iteration zur Qualitätssi-cherung

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

Abb. 2.14. Vereinfachte Darstellung eines Prozesses ohne Iteration zur Qualitäts-sicherung

Derjenige, der ein Problem identifiziert, postet es ähnlich wie in einem Forum (Abb. 2.15.). Ein solches Problem-Posting enthält einen Betreff, ei-nen Problembeschreibungstext, eventuell einen Kommentar und falls mög-lich 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ögli-che Verursacher des Problems und Nachfolger können vom Problem be-troffen 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ü-


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 eingegebe-nen Daten eine Dokumentationsdatei generiert, welche an die Aktivität an-gehängt wird, in der das Problem entdeckt wurde. Daraufhin werden die während der Problemlösung in die Datenbank geschriebenen Daten ge-löscht. Die so entstandene Dokumentation findet ebenfalls Berücksichti-gung 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 Erstel-lung CAD-Modell nach der Aktivitätsbeendigung ein Problem entdeckt, so ist es nötig, das CAD-Modell zu überarbeiten. Hierzu wird der Basispara-meter Fertig (%) vom Wert 100 auf einen geringeren Wert zurückgesetzt, der dem geschätzten Durchführungsgrad der Aktivität entspricht. Auch be-troffene benutzerdefinierte Parameter, wie zum Beispiel der Parameter Sta-tische Berechnungen durchgeführt, müssen auf den Anfangswert Nein zu-rückgesetzt werden, da die zugrundeliegenden Tätigkeiten erst noch erneut durchgeführt werden müssen.


Diese Parameteränderungen führen dazu, dass zuvor erfüllte Startbedin-gungen 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 ent-stehender 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 wer-den dort analog zur Aktivität Erstellung CAD - Modell ebenfalls Parame-teränderungen notwendig. Auf diese Weise ziehen sich die bei der Prob-lemlö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 Darstel-lung jeder Aktivität eine Statusanalyse durch. Werden hierbei Unstimmig-keiten festgestellt, so werden im Statusfeld der Detaildarstellung der Akti-vitä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


jedoch die Möglichkeit, logisch unsinnige Parameterwerte zu setzen. Au-ßerdem kann es aufgrund von bedingungsgetriggerten, automatischen Än-derungen des Basisparameters Kann beginnen zu unlogischen Zuständen kommen.

Von dem »entwicklungsfähigen Projektplanungssystem« werden die folgenden unlogischen Zustände erkannt:

Startbedingungen erfüllt, aber Basisparameter Kann beginnen=NeinStartbedingungen nicht erfüllt, aber Basisparameter Kann beginnen=JaBasisparameter Hat begonnen=Ja, aber Basisparameter Kann begin-nen=NeinBasisparameter Fertig (%)>0, aber Basisparameter Kann begin-nen=NeinBasisparameter Fertig (%)>0, aber Basisparameter Hat begonnen=NeinMögliche Ursachen des Auftretens und die zu erwartende Benutzerreak-

tion auf die Bekanntgabe des unlogischen Zustands soll an dem in Abb. 2.17 dargestellten Beispiel erläutert werden:

Startbedingungen nicht erfüllt, aber Basisparameter Kann beginnen=JaMögliche Ursachen Erwartete Benutzerreaktion Falsche Benutzereingabe Benutzer korrigiert Parameterwert

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änger-aktivität aufgrund eines Problems teilweise erneut durchgeführt wer-den muss und deshalb einige Parameter zurückgesetzt werden. Ein Beispiel hierfür wäre das Herabsetzen des Wertes des Basis-parameters Fertig (%).

Der Benutzer prüft, inwiefern die Änderungen in der Vorgängerakti-vitä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 teil-weise erneut durchgeführt werden muss, sind die betroffenen Para-meterwerte 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, benutzerdefi-nierte Parameter seiner Aktivität zu löschen. Basisparameter können zwar nicht explizit gelöscht werden, jedoch kann ein Verantwortlicher die ge-


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 errei-chen. 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 ge-löscht. Daher wird eine RemovedConditionMessage pro gelöschter Bedin-gung mit den Aktivitäten verknüpft, welche von der Löschung betroffen sind. Bei der Zustandsanalyse einer Aktivität werden vorhandene Remo-vedConditionMessages ausgewertet und bei der Detaildarstellung der Ak-tivität mit Textmeldung und Warnsymbol dargestellt. Welche Bedingun-gen gelöscht wurden, wird in der Startbedingungsübersicht angezeigt. Sobald der Verantwortliche in Abhängigkeit von seiner Rolle die Kennt-nisnahme bestätigt, wird auch die entsprechende RemovedConditionMes-sage gelöscht.

Problemanalyse in Aktivitäten

Bei der Problemanalyse werden Vorgänger- und Nachfolgeaktivitäten re-kursiv nach bekannt gegebenen Problemen durchsucht. In Vorgängerakti-vitäten aufgetretene Probleme sind relevant für die Durchführung der Ak-tivität, da deren Lösung voraussichtlich zu Nacharbeiten in Vorgängeraktivitäten führt oder sogar zu Änderungen in der vor der Akti-vitä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 Ak-tivitä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 sei-ner Rolle eine Übersicht über den Status der Aktivitäten, für deren Durch-führung er verantwortlich ist. Die Darstellung enthält die Werte der Basis-parameter (Kann beginnen, Hat begonnen, Fertig (%)) jeder Aktivität, zeigt vorhandene Ressourcenkonflikte an und informiert über das mögli-che Vorhandensein von Problemen (vgl. Abb. 2.18.). Besteht bei einer Ak-tivität Handlungsbedarf, beispielsweise aufgrund eines vorhandenen Res-sourcenkonflikts oder aufgrund gefundener Unstimmigkeiten bei der Statusanalyse, so wird die Aktivität in der Liste mit dem Warnsymbol ( )


gekennzeichnet. Ist die Aktivität von einem Problem in einer anderen Ak-tivität betroffen, da sie diese als direkten oder indirekten Vorgänger oder Nachfolger hat oder steht eine Aktivität im Verdacht, ein Problem zu ver-ursachen, so wird auch sie mit dem Warnsymbol gekennzeichnet.

Von der To-Do–Liste aus kann zur Detaildarstellung der jeweiligen Ak-tivitäten navigiert werden, um weitere Informationen über den Status zu erhalten.

Steht ein Projektbeteiligter vor der Frage, welche Aktivität er als nächs-tes 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 kei-nerlei 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 »entwick-lungsfähigen Projektplanungssystems« überwachen lassen. Hierzu erstellt der Benutzer eine Benachrichtigungsaktion (SendMessageAction). Sobald die zugrundeliegenden Bedingungen für die Werte der gewählten Parame-ter der zu überwachenden Aktivität erfüllt sind, wird die Aktion ausge-fü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-


tät werden vor dem Versenden der Benachrichtigung vom »entwick-lungsfähigen Projektplanungssystem« hinzugefügt.

Lessons Learned Datenbank

Beim Abschließen eines Projektes werden alle mit dem Projekt zusam-menhängenden Daten in der Lessons Learned Datenbank archiviert. Hier-zu werden mit dem Projekt in Zusammenhang stehende Objekte wie ent-haltene 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 be-reits gemachten Erfahrungen aufgebaut werden. Da Projekte stets neuartig und einmalig sind, ergibt es jedoch keinen Sinn, ganze, bereits abgeschlos-sene Projekte als Vorlage heranzuziehen. Stattdessen können Teile (Akti-vitä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 Prozess-modul, also die Aktivitäten mitsamt ihrer Vorgänger und allen Verknüp-fungen zu kopieren, da die Durchführung einer Aktivität erst möglich ist, wenn die Vorgängeraktivitäten dafür die Vorraussetzungen geschaffen ha-ben. Das Duplizieren persistenter Objekte in der Datenbank erfolgt durch Aufruf der Methode createCopy() der Klasse DataObject. Sind die ent-sprechenden 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 Dateien-dungen und maximale Dateigröße können in der Konfigurationsdatei web.xml des »entwicklungsfähigen Projektplanungssystems« festgelegtwerden.


Problemlösungsorientiertes Management von Kompetenzen

Die im Verlauf von RPD-Projekten ad-hoc auftauchenden Probleme, kön-nen im »entwicklungsfähigen Projektplanungssystem« einzelnen Aktivi-tä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 Projektpla-nungssystems« mit einem geringem Administrationsaufwand verbunden ist.

Die Kompetenzen aller am RPD-Prozess Beteiligten zu erfassen, quali-tativ 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 Kompeten-zen 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über-sichtlicher. Um dies zu vermeiden, wurde das Anlegen, Löschen und Än-dern von Kategorien und Themenfeldern auf die kleine Menge von Teil-nehmern 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.


Verwaltung von Kompetenzen

Für die Verwaltung von Kompetenzen wird der RPD-Experte im »ent-wicklungsfähigen Projektplanungssystem« in die Lage versetzt, die von ihm beherrschten eigenen Kompetenzen zu spezifizieren, mit einer Kurz-beschreibung zu versehen und zu verschlagworten. Zur Untersützung der Verschlagwortung steht hier ein Thesaurus zur Verfügung, mit dessen Hil-de 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ügba-ren 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 ge-fordert wurden. Damit werden verschiedene Möglichkeiten zu einer intui-tiven Navigation im Kompetenzbestand eröffnet.

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


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 vor-handene Kategorienstruktur, die gegebene Themenfeldstruktur oder den Schlagwortkatalog, der auf Basis der Spezifikation der Kompetenzen dy-namisch 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 ein-gesetzt wurde und welche Dokumente in bezug auf die Kompetenz hinter-legt wurden. Auf Basis identifizierter, relevanter Kompetenzen und der e-xistierenden Verknüpfungen kann damit weiter navigiert werden.

Abb. 2.20. Visualisierung der Vernetzung von Kompetenzen, Experten und Pro-jekten


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 ur-sprünglichen Spezifikation der Kompetenzen vorgenommen wurde.


Abb. 2.22. Indirekte Expertensuche über mit einer Kompetenz verknüpfte Doku-mente

2.3.5 Zusammenfassung und Ausblick

Zur Konzeption, Entwicklung und Implementierung eines »entwicklungs-fähigen Projektplanungssystems«, die Möglichkeiten zur regelbasierten Verknüpfung von Aufgaben (Aktivitäten) und Rollen (Verantwortlichen) in generischen Prozessmodulen bietet, wurden zunächst die Anforderun-gen an die Modellierung von RPD-Prozessen ermittelt. Diese wurden zum einen aus den spezifischen planungsrelevanten Randbedingungen und An-forderungen des RPD abgeleitet. Zum anderen wurde darauf geachtet, dass die Anforderungen so spezifiziert werden konnten, dass eine spätere in-formationstechnologische Realisierung und Integration die bereits in den vergangenen Förderperioden entwickelten TOPP-Komponenten nicht kon-terkariert.

Im Rahmen der informationstechnologischen Realisierung und Integra-tion des »entwicklungsfähigen Projektplanungssystems« wurde Wert dar-auf 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-


folgt zum einen über drei grundlegende Parameter („kann beginnen“, „hat begonnen“ und „fertig %“) und zum anderen über frei definierbare Para-meter, 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 rol-lenbasierten Steuerung der RPD-Prozesse in das »entwicklungsfähige Pro-jektplanungssystem« zu implementieren. Neben der Navigation in RPD-Prozessen über Detailansichten von Aktivitäten und über Teilnetzdarstel-lungen waren die parametergetriebenen Problemlösungsmechanismen und die rollenbasierte Überwachung von Aktivitäten von besonderer Bedeu-tung. Durch Realisierung und die Implementierung einer »Lessons Lear-ned Datenbank« ist es möglich, bei der Definition von Prozessen in neuen RPD-Projekten auf die in vorherigen Projekten gesammelten und doku-mentierten Erfahrungen auf Teilprozess- und Prozessmodulebene zurück-zugreifen.

Mit der informationstechnischen Realisierung eines problemlösungsori-entierten Managements von Kompetenzen ist es möglich, Unterstützungs-mechanismen für in RPD-Projekten ad-hoc auftauchende Probleme bereit-zustellen sowie RPD-Experten in die Lage zu versetzen, sich schnell und dynamisch abzustimmen. Dazu wurde ein dezentrales Kompetenzmana-gement konzipiert und in das »entwicklungsfähige Projektplanungssys-tem« 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 Werk-zeug entstanden, dass die Planung von RPD-Projekten effizient und effek-tive unterstützt, in dem es die Möglichkeiten, die eine evolutionäre Pla-nung 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 Kunden-aktivitäten und Kundenwissen systematisch in die Planung von Innovatio-nen einbezogen werden sollen, oder »kreative Netzwerke«, in denen Pla-nungsprozesse 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


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, ori-entierte sich zum einen am Stand der Forschung auf den Gebieten des Ra-pid Product Developments, der Teamkooperation und des Wissensaus-tauschs 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 entwi-ckelnde Produkt frühzeitig überwunden werden [2.106]. Die frühe Festle-gung 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 Steue-rung 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 Mit-arbeiter die Fähigkeit des Teams erhöht werden soll, komplexe Projektauf-gaben 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 Überwin-dung disziplinspezifischer Spezialisierung werden die Voraussetzungen für kreatives und innovatives Handeln gesehen [2.124]. Es wird angenommen, dass durch eine Vernetzung von Expertisen unterschiedliche Wissensbe-stände verknüpft und wechselseitig verstärkt werden, was zu einer größe-ren 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ück-greifen können [2.13], [2.30]. Allerdings existieren auch Studien, die nega-tive Implikationen einer heterogenen Teambesetzung nachweisen. Solche dysfunktionalen Effekte werden in erster Linie mit einer geringeren Kon-sensfä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 Interakti-ons- und Kommunikationsstrukturen stark mit der Nutzung informations-technologischer 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 Unsicher-heiten 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 Problem-lösungen [2.69]. Im Fall einer interdisziplinären Kooperation zur Entwicklung von Prototypen zeichnen sich situationsspezifische Unsicher-heiten 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 Herausfor-derungen im Umgang mit Wissen und Expertise.

Dort, wo es nicht allein um die Anwendung, sondern auch um die Gene-rierung von Wissen vor dem Hintergrund der Bewältigung praktischer Ar-beitsaufgaben geht, ist die Rede von neuen Formen der „Wissensprodukti-on“, 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 In-novation aufgefasst werden kann, sondern aus dem prozessualen Wechsel-verhältnis von kognitiven Repräsentationen und sozialen Interaktionsmus-


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än-gigen 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] ent-stehen dort, wo beide Wissenstypen erfolgreich ineinander überführt wer-den 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 Ge-nerierung von Wissen ist gemäß diesem Modell die Umwandlung implizi-ter 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 in-terdisziplinären Entwicklungsteams zu beschreiben. Durch die Kombinati-on 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 implizi-te Wissen der beteiligten Akteure, z.B. in Form einer Prototypenentwick-lung als gemeinsame Wissensbasis externalisiert und für weitere Wissens-prozesse 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 erfah-ren werden kann und stark mit den Arbeitsprozessen verknüpft ist. Dabei wird auf das Problem verwiesen, dass die Beobachtung und Messung im-pliziten 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üp-fung von Wissen und Handlung den Begriff der „Könnerschaft“ [2.105] oder aber konkretisieren den Begriff des impliziten Wissen durch operati-onalisierbare Variablen, was dann als „kontextbezogenes Wissen“ (contex-tual knowledge) bezeichnet wird [2.38]. Darüber hinaus wird argumentiert, dass die Explizierung von Wissen auch von anderen Aspekten, wie z.B.


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ätsstei-gerungen (z. B. [2.94]), schnellere und qualitativ höherwertige Arbeit [2.15], [2.81] und verbesserte Entscheidungsprozesse [2.108], [2.111] fest-stellen. Auf der anderen Seite sind jedoch auch negative Effekte wie er-hö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 Entwick-lungsteams verantwortlich sind.

Während bereits Studien zum Thema demographische und kulturelle Heterogenität vorliegen (z. B. [2.7], [2.47]), ist die Frage nach dis-ziplinä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 Ent-wicklungsteams 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 An-haltspunkte 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, Aus-rü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 Pro-duktentwicklungsteams 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-


doch Strategien zur Unterstützung dieses Transfers von Mitgliedern in Produktentwicklungsteams verwendet werden, um Probleme der Wissens-integration zu verhindern bzw. zu beheben, wurde bislang nicht themati-siert. Ebenso fehlt eine Systematisierung der eingesetzten Strategien, um deren situations- und bedarfsgerechten Einsatz für verschiedene Problem-situationen 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

erkenntnismäßigem Wissen („Know-what“), dem zur Beherrschung ei-nes Fachgebietes notwendigen, durch Qualifikationsmaßnahmen erwor-benen Wissen, hochentwickelten Fertigkeiten („Know-how“); dies meint die Fähigkeit, Fachwissen auf komplizierte Probleme anzuwenden, 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, 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 qualifikatori-schen Unterstützung der Beschäftigten einher. Auf der Ebene des Fakten-wissens (Know-what) gilt es, eine zunehmend unüberschaubare Menge an Informationen zu erfassen und zu strukturieren. Datenbankgestützte EDV-Systeme und leistungsfähige CSCW-Anwendungen können dabei unter-stützend wirken. Im Gegensatz dazu lassen sich Fertigkeiten (Know-how) nicht in Datenbanken speichern oder über Computernetze übertragen. Fer-tigkeiten entstehen im Rahmen konkreter Problembearbeitung und der praktischen Anwendung von Wissen. Nur dort, wo gemeinsame Hand-lungs- 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ändigungs-schwierigkeiten auf, wenn die Paradigmen und mentalen Modelle der beteiligten Individuen voneinander abweichen und gemeinsame Deutungs- und Interpretationsmuster fehlen. Schließlich sind erfolgreiche Wissensaustauschprozesse auf die Überschneidung persönlicher Ziele und


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 Innovationspro-zesse bereitgestellt werden. Empirische Analysen lassen jedoch erkennen, dass gerade im Bereich der Wissensintegration Defizite bei der Kooperati-on interdisziplinärer Entwicklungsteams festzustellen sind [2.115]. Wis-sensintegration, verstanden als ein gemeinsames Verständnis von Begriff-lichkeiten 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 wis-senschaftlicher Untersuchungen waren, findet der Prozess der Wissensin-tegration bzw. des „groundings“ in interdisziplinären Teams erst in letzter Zeit stärkere Beachtung [2.122], [2.123]. Gleichwohl liegen für eine ver-besserte Integration unterschiedlicher Wissensarten Konzepte vor. Hier sind vor allem solche Ansätze vielversprechend, die auf eine Feinabstim-mung von Instrumenten des Wissenstransfers mit den jeweiligen Wissens-inhalten abzielen [2.33]. Die Auswahl unterschiedlicher Strategien und In-strumente 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 „Con-cept-Maps“ [2.89], „Learning histories“ [2.62] und der „Blueprinting“-Methode [2.133] Techniken zur Visualisierung unterschiedlicher Wissens-bereiche zur Verfügung. Während die Methode des Concept-Mapping auf die systematische Erfassung und Visualisierung individueller Wissensrep-räsentationen in Form der Illustration eines semantischen Netzwerkes ab-zielt, handelt es sich bei „Learning histories“ um ein narratives Erhebungs-instrument, 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 Dar-stellung aufgabenübergreifender Arbeits- und Geschäftsprozesse. Die An-wendung und Weiterentwicklung solcher Instrumente kann im Rahmen kooperativer Entwicklungsarbeit einen wichtigen Beitrag für die Schaffung einer gemeinsamen Wissensbasis und damit einer verbesserten Wissensin-tegration leisten. Zum einen können so Gemeinsamkeiten und Unterschie-de der Perspektiven und Wissensdomänen der beteiligten Akteure heraus-gearbeitet und beeinflusst werden. Zum anderen wird ein Gesamtverständnis komplexer Arbeitsprozesse gefördert. Bislang steht je-


doch die systematische Abstimmung einzelner Instrumente auf unter-schiedliche 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 ar-beitswissenschaftlichen wie auch die organisatorischen Voraussetzungen für die Überwindung einer funktionalen Arbeitsteilung und kommunikati-ver Schnittstellenprobleme zu bestimmen, um im Anschluss entsprechende Gestaltungsempfehlungen formulieren zu können. Nur wenn die Ar-beitsaufgaben in angemessener Weise mit dem Wissen und der Qualifika-tion der Beschäftigten austariert sind, lassen sich Stresssituationen und Un-terforderungen vermeiden [2.23], [2.76]. Gerade das Beispiel einer zeitkritischen Forschungs- und Entwicklungsarbeit – wie beim RPD-Verfahren – zeigt, dass die Zunahme paralleler Arbeitsprozesse eine deut-liche Erhöhung der Aufgabenkomplexität nach sich zieht. Ein umfassendes Verständnis von vor- und 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 zeit-lichen 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 da-gegen den Aufbau eines systematisch vernetzten Meta-Wissens. Ein sol-ches entlastend wirkendes Meta-Wissen hilft, verschiedene Fachdiszipli-nen, 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 Er-kenntnisse zu erwarten, die Aussagen über eine menschengerechte und ge-sundheitlich 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 »Arbeitswissenschaft-liche Konzeptionierung kooperativer Arbeitsformen für die Entwicklung innovativer Produkte« folgende Ergebnisse erarbeitet: Im ersten Schritt wurde ein Modell zur Analyse von interdisziplinären Expertenkooperatio-nen entwickelt, das aus den Teilprozessen der Kommunikation, der Koor-dination und der Wissensintegration besteht. Dieses Modell wurde im


zweiten Schritt operationalisiert und empirisch validiert, wobei die Bedeu-tung 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 Mo-dellen und Wissensebenen und der Erweiterung des Modells der Wissens-integration durch theoretische und praktische Elemente.

Der vierte Schritt zielte auf die Entwicklung von Gestaltungsempfeh-lungen und Instrumenten für die Unterstützung interdisziplinärer, koopera-tiver 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 Wis-sensintegration eingesetzt und für die spezifischen Anforderungen im Pro-duktentwicklungsprozess angepasst und bewertet. Das Ergebnis sind ex-emplarisch ü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 Teamlei-ter in interdisziplinären Entwicklungsteams stellen, werden in einem an-schließenden Transferprojekt analysiert und gemeinsam mit den entwickel-ten Handlungsempfehlungen und Instrumenten in eine morphologisch aufgebaute Gestaltungsbox zur Unterstützung von Produktentwicklungs-teams integriert.

Im Rahmen der Arbeiten wurde zunächst auf Basis theoretischer Über-legungen und empirischer Studien die Teilprozesse Kommunikation, Ko-ordination und Wissensintegration als grundlegende Elemente von Koope-rationsvorgängen identifiziert. Darauf aufbauend wurde ein entsprechendes Kooperationsmodell entwickelt, welches dann in mehreren Studien bei in-terdisziplinären Entwicklungsteams validiert wurde. Wesentliche Ergeb-nisse waren dabei

die Entwicklung und Validierung eines Instruments zur Bewertung der Kooperation in interdisziplinären Entwicklungsteams; eine erhöhte Bedeutung der Wissensintegration für den Kooperations-prozess im Vergleich zu den beiden anderen Teilprozessen der Kommu-nikation und Koordination;


die Unterscheidung unterschiedlicher Kooperationstypen, welche sich hinsichtlich der Häufigkeit von Problemen bei Kommunikation, Koor-dination und Wissensintegration voneinander abheben; phasenbezogene Unterschiede in der Problemakkumulation: die meisten Probleme bezüglich Koordination und Wissensintegration traten in der Entwurfsphase auf, in der anhand konkreter werdender Prototypen-Merkmale die unterschiedlichen Vorstellungen und Wissenshintergrün-de der Teammitglieder aufeinander stießen.

Ausgehend von diesen Ergebnissen orientierte sich das weitere Vorge-hen an drei Arbeitsschritten: Zuerst wurden im Rahmen einer Längs-schnittuntersuchung Anforderungen an die Kommunikation, Koordination und Wissensintegration in Abhängigkeit von Entwicklungsphasen unter-sucht. 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 Ar-beitspakete wurde ein Modell zur Wissensintegration abgeleitet. Im dritten Schritt wurden zunächst unterschiedliche Kooperationskonstellationen hin-sichtlich der teambezogenen Heterogenität, der Komplexität des Produkt-entwicklungsprozesses 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 arbeitswis-senschaftlicher 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 Arbeitsschwer-punkts erarbeitet. Hierzu gehörte die Zusammenfassung der Kooperations-anforderungen für fach- und funktionsgemischte Entwicklungsteams in ei-nem Kooperationsmodell (Abb. 2.23.).


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

Das Modell definiert Kooperation als Gesamtheit aus den drei Teilpro-zessen der Kommunikation, Koordination und Wissensintegration. Kom-munikation 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 Entwick-lungsaufgabe auf verschiedene Schultern zu verteilen, deren Bearbeitung zu überwachen und die verteilt erzielten Arbeitsergebnisse zu einer stim-migen 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 Ent-wicklung 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 Be-achtung 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 hete-rogenen Expertenwissens erfolgt, sondern als deren Voraussetzung auch eine gemeinsame Wissensbasis im RPD-Team entwickelt wird.


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. Ver-antwortlich 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 betei-ligten 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 ent-sprechend abgestimmte Unterstützungsinstrumente geförderten gemeinsa-men Integration der für das Projekt relevanten Wissensbereiche. Die ei-gentliche 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 Wissensintegrationspro-zesse in der Praxis nie zeitlich getrennt voneinander ab. Der Aufbau der gemeinsamen Wissensbasis erfolgt in der Regel parallel zu den innovati-ven 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


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 Meinungs-verschiedenheiten erhebliche soziale Reibungsverluste entstehen, welche die Effizienz der gesamten Teamkooperation nachhaltig senken.

Um die Dimensionen genauer zu definieren, auf denen die beschriebe-nen 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 Vorstel-lungen besetzt ist. Erst die Konkretisierung und Abstimmung der projekt-relevanten Ziele macht es möglich, die verteilt durchgeführten Arbeiten auf gemeinsame Ziele auszurichten. Die Integration auf dieser Wissens-ebene stellt damit die Voraussetzung für effiziente Koordinationsleistun-gen dar, ohne die eine Delegation von Arbeitselementen auf einzelne Teammitglieder und eine selbständige, dezentrale Bearbeitung von Teil-aufgaben nicht möglich ist.


Die Ebene des Fach- und Zusammenhangswissens stellt diejenigen Wis-sensbereiche 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 Nutzbarma-chung 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 Wissens-bereiche einordnen, welche die Nutzung des Erfahrungswissens zum Ziel haben. Hierunter fallen Vorgehensweisen und Methoden, die den Team-mitgliedern bekannt sind und zu welchen Erfahrungen vorliegen. Häufig werden auch hier Vorschläge zum Vorgehen im Entwicklungsprojekt ge-macht, ohne die implizit zugrunde liegenden Erfahrungen transparent ge-macht werden. Ohne die Berücksichtigung dieses Erfahrungswissens blei-ben Diskussionen über „das geeignete Vorgehen“ erfolglos, da die eigentlichen Vor- und Nachteile der einzelnen Methoden und Vorgehens-weisen nicht verglichen werden können.

Die Entwicklung einer gemeinsamen Wissensbasis auf der Definitions-ebene versetzt Entwicklungsteams in die Lage, von Anfang an Missver-ständnisse zu vermeiden, die durch unklar definierte Begrifflichkeiten und sonstige Festlegungen ausgelöst werden. Hierzu gehören beispielsweise re-levante 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änd-nisse, 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 Entwick-lungsteams, Barrieren des Wissensaustauschs wirkungsvoll zu vermeiden und die Kooperation des Teams maßgeblich zu vereinfachen. Wird auf al-len 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 Kooperationsan-forderungen in Teams, die den Rahmenbedingungen und Zielsetzungen


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 Kooperations-konstellationen auf die Kooperationsprozesse untersucht wurden.

In der Fallstudie wurde ein Prototypenentwicklungsteam eines internati-onal tätigen Automobilzulieferbetriebes untersucht. Zunächst wurden im betrieblichen Praxisbeispiel drei Ebenen der Kooperation identifiziert: die Kernteamebene, die teamübergreifende Ebene und die betriebsübergrei-fende Ebene. Anschließend wurden die Kooperationsebenen mit ausge-wählten Rahmenbedingungen des Entwicklungsprozesses in Beziehung gesetzt. Dies betraf die Heterogenität der Entwicklungsteams, der Kreativi-tätsförderlichkeit des Umfelds und der Komplexität des Produktentwick-lungsprozesses, die jeweils unterschiedliche Strategien für die Optimie-rung von Kooperationsprozessen voraussetzen.

Ebenen der Kooperation

Während das Kernteam unmittelbar mit der Prototypenentwicklung be-schäftigt ist, übt das Randteam auch unterstützende Funktionen wie Logis-tik, Controlling und Fertigungsplanung aus. Das gesamte Projektteam, also Kern- und Randteam, ist der Projektleitung unterstellt. Eine Differenzie-rung des Projektteams in unterschiedliche Kooperationsebenen ist notwen-dig, weil sowohl das Kernteam wie auch das Randteam im Hinblick auf die Heterogenität und die Stabilität des Teams variieren. Eine dritte Ko-operationsebene ist in der betriebsübergreifenden Ebene zu sehen. Auf die-se Ebene sind im Zuge einer kundenspezifischen Prototypenentwicklung externe Kooperationspartner (Kunden) in den Prozess der Leistungserstel-lung einzubeziehen. Setzt man die drei Kooperationsebenen mit ausge-wählten Rahmenbedingungen des Kooperationsprozesses in Beziehung, ergeben sich differenzierte Kooperationskonstellationen (vgl. Abb. 2.26.).


Rahmenbedingungen Strategien zur Optimierung von Koopera-tionsprozes-sen

Heterogenitätder Teamkon-stellation

Kreativitätsför-derlichkeit des Umfeldes

Komplexität des Entwicklungs-prozesses

Kernteam-basiert

Gewährleistungeiner hohen Teamstabilität,hoheKommuni-kationsdichte

Gewährung von Handlungsspiel-räumen, kommunikations-freundliche Ar-beitsplatzgestal-tung

Berücksichtigungsozial-emotionaler Fak-toren durch Pro-jektleitung, Ver-meidung von Burnout-Effekten

Kernteam-übergrei-fend

Gestaltung der Interaktiondurch Projekt-leitung, Projekt-leiter als Wis-sensintegrator

Entlastung durch Standardisierungvon Routinepro-zessen; Optimie-rung der Kom-munikation durch Datenbanksys-teme

Erhöhung der In-formationstrans-parenz durch Entwicklung ei-nes Instrumentes zur „Reifegrad-messung“Koo

pera

tions

eben

en

Betriebs-übergrei-fend

Stärkere kom-munikative Ein-bindung des Kunden in den Entwicklungs-prozess

Stärkere Struktu-rierung der Kun-deninteraktion, Etablierung einer Vertrauenskultur

Stärkere Anglei-chung der menta-len Modelle zwi-schen Kunden und Entwick-lungsteam

Abb. 2.26. Strategien zur Optimierung von Kooperationsprozessen nach Koopera-tionsebenen und Rahmenbedingungen der Teamarbeit

Heterogenität des Teams

Im untersuchten Unternehmen ist die Disziplinenvielfalt der Teammitglie-der innerhalb der Kernteams gering. Darüber hinaus ist die personelle Zu-sammensetzung auf Kernteamebene stabil. Abgesehen von ungeplanten Fluktuationsbewegungen sind keine Veränderungen in der Teambesetzung während einer laufenden Prototypenentwicklung vorgesehen. Sowohl die


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 Fer-tigungsplanung mit den spezifischen Anforderungen der Prototypenent-wicklung abzustimmen und in Übereinstimmung zu bringen. Der Projekt-leitung 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 Wissensinteg-rationsprozess abzubrechen und eigenverantwortliche Entscheidungen zu treffen. In der Regel gelingt jedoch eine konsensbasierte Wissensintegrati-on, wobei die Projektleitung eine wichtige Moderations- und Coaching-Funktion übernimmt.

Fokussiert man die betriebsübergreifende Ebene, müssen auch die An-sprechpartner auf Kundenseite als potenzielle Mitglieder des Entwick-lungsteams aufgefasst werden. Im Rahmen einer kundenspezifischen Leis-tungserstellung wird der Kunde als "externer Faktor" in den Produktentwicklungsprozess integriert. Damit steigt die Heterogenität des Teams. Zu beobachten sind divergierende Interessenlagen und unter-schiedliche Perspektiven, was die Kooperation vor große Herausforderun-gen 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 tau-chen im Entwicklungsprozess immer wieder nachträgliche Änderungs-wünsche (Change-request) des Kunden auf, so dass der Entwicklungspro-zess vor erhebliche Koordinations- und Anpassungsprobleme gestellt wird. Die Projektleitung kann nur begrenzt zu einer Perspektivenintegration bei-tragen, 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äts-förderliche Gestaltung des Umfeldes spezifische Strategien für eine Opti-mierung der Kooperationsprozesse. Auf der Ebene des Kernteams wird die Kooperation durch eine kreativitätsförderliche Arbeitsgestaltung unter-


stützt. So wird der Wissensaustausch im Kernteam durch die räumliche Anordnung in einem Großraumbüro nachhaltig intensiviert. Für die Kern-teammitglieder 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 Hand-lungsspielräume verfügen und standardisierte Arbeitsprozesse kaum vor-zufinden sind.

Aufgrund der räumlichen Trennung der am Kooperationsprozess betei-ligten Personen sind die kreativen Anteile der Arbeit auf kernteamüber-greifender Ebene geringer ausgeprägt. Räumliche Distanzen müssen durch technische Kommunikationsinfrastrukturen überwunden werden. Die da-mit einher gehenden Medienbrüche erschweren die kreativen Austausch-prozesse. Ferner werden im untersuchten Unternehmen Maßnahmen ge-troffen, den Wissensaustausch über die Einrichtung von datenbankgestützten Informationssystemen zu optimieren. Dies spricht da-fü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 be-triebsübergreifender Ebene problematisch. Hier ist zu beobachten, dass kreative Prozesse zwischen Kunden und Entwicklungsteam erschwert werden, wenn keine ausreichende Vertrauensbasis für den Austausch unsi-cherer und sensibler Informationen zur Verfügung steht. Darüber hinaus ist festzustellen, dass kreative Prozesse einen dysfunktionalen Charakter ent-falten können, wenn sie einseitig und „ad hoc“ erfolgen. So können nach-trägliche Änderungswünsche des Kunden im fortgeschrittenen Entwick-lungsprozess zwar unter Kreativitätsgesichtspunkten betrachtet werden. Dies wird jedoch vom Entwicklungsteam nicht als kreativer Impuls, son-dern als willkürliches Vorgehen empfunden – zumindest dann, wenn sol-che 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 Aus-tauschprozesse in überschaubare Bahnen zu lenken.

Komplexität des Entwicklungsprozesses

Die Prototypenentwicklung von Serienbauteilen ist als Ausschnitt eines gesamten Automobilentwicklungsprozesses zu sehen. Die Kfz-Entwicklung weist im Zuge minimierter Fertigungstiefen stark netzwerk-förmige Züge auf und hat mittlerweile einen extrem hohen Komplexitäts-grad erreicht. Ein wesentliches Problem diesbezüglich ist der Umgang mit


ausstehenden Informationen und Unsicherheit. So können die Kfz-Hersteller als Auftraggeber oftmals keine eindeutigen Produktspezifikatio-nen formulieren, weil sie im Zuge eines netzwerkbasierten Entwicklungs-prozesse selber (noch) nicht über die dafür notwendigen Wissensbestände verfügen. Die Folge können nachträgliche Änderungswünsche (Change-Request) und unzureichende Informationsflüsse sein, die besonders im fortgeschrittenen Stadium der Prototypenentwicklung einen großen Unsi-cherheitsfaktor darstellen.

Im Verlauf der Untersuchung konnte festgestellt werden, dass die identi-fizierten Kooperationsebenen eine unterschiedliche Problemwahrnehmung in Bezug auf die Komplexität des Produktentwicklungsprozesses aufwei-sen. Auf der kernteambasierten Ebene werden nachträgliche Änderungs-wünsche und ausstehende Informationsbestände als hochbelastendes „Chaosmanagement“ erfahren. Die Komplexität des Entwicklungsprozes-ses artikuliert sich primär als Koordinationsproblem, weil Arbeitsergebnis-se verworfen und die Prototypenentwicklung zum Teil auch in fortge-schrittenen Entwicklungsphasen neu begonnen werden muss. Der Umgang mit Unsicherheit wird als Stress erfahren, der im kognitiv emotionalen Be-reich bearbeitet werden muss. Der Projektleitung kommt in diesem Zu-sammenhang nicht nur eine koordinierende, sondern auch eine sozial-integrative Funktion zu. Dazu zählt, die individuelle Leistungsfähigkeit und Belastbarkeit der Beschäftigten frühzeitig zu erkennen, um Burnout-Effekten vorzubeugen.

Auf kernteamübergreifender Ebene artikuliert sich die Komplexität des Produktentwicklungsprozesses primär als Kommunikationsproblem. Dies-bezü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 wer-den. 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 Hinter-grund zeitlicher, betriebswirtschaftlicher und qualitätsbezogener Kennzah-len abgebildet werden. Mit einem solchen Instrument soll festgestellt wer-den, 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 un-terschiedliche Interessenlagen und heterogene Perspektiven, aber auch auf eine mangelhaftes Vertrauen im Umgang mit sensibler Information zu-


rückgeführt. Eine mögliche Lösung für eine verbesserte Wissensintegrati-on wird darin gesehen, dem Auftraggeber die eigene Perspektive nach-drü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 funkti-oniert“. Konkrete Strategien, ob und wie dies erreicht werden kann, konn-ten jedoch nicht beobachtet werden.

Für die Optimierung von Kooperationsprozessen können aus den Er-gebnissen des Arbeitspakets folgende Handlungsempfehlungen abgeleitet werden:

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 ab-zustimmen. 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 Um-gang 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.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 Ar-beitsklima 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 ferti-gen Produkt untersuchen zu können, wurde eine qualitative Fallstudie


durchgeführt. Im Rahmen einer Längsschnitt-Untersuchung wurde ein kompletter Problemlösungsprozess eines Projektteams mit Hilfe von Beo-bachtungen, Dokumentenanalyse und Befragungen analysiert. Es sollte un-tersucht werden, welche Probleme und Anforderungen in sehr komplexen, heterogenen, internationalen und interdisziplinären Kooperationen im Be-reich der digitalen Medienkunst auftreten, wie konkret mit Problemen um-gegangen wird und in welchem Zusammenhang die Problembewältigung mit dem phasenbezogenen Entwicklungsverlauf steht.

Bei dem untersuchten Entwicklungsprojekt handelte es sich um eine in-terdisziplinäre Kooperation zwischen einem amerikanischen Medienkünst-ler (Konzeption und Projektleitung), finnischen Kognitionswissenschaft-lern (SOM, Kohonen self-organizing map-Alogrithmen), ungarischen Ingenieuren / Künstlern (Hard- und Software-Entwicklung), deutschen De-signern und Psychologen und einem französischen Kurator. Das Team setzte sich aus 13 männlichen und einem weiblichen Teammitglied im Al-ter 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 (Kura-tor/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 an-fangs 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äch-lich auf die hohen Ambitionen der jüngeren, wenig projekterfahrenen Teammitglieder zurückzuführen war.


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 Diffe-renzierung der Gruppe in Subgruppen erschwert wurde. Die Kommunika-tion 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 wei-tergeleitet. Dies führte vielfach zu Missverständnissen, da der Projektleiter nicht über das notwendige Wissen über Konventionen bei den Datenfor-maten 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 Ter-minplan unter Zeitdruck: Zudem wurde die Einhaltung des Zeitplans durch die Mehrfach-Belastungen einzelner Teammitglieder erschwert. Aufgrund mangelnder Erfahrung einzelner Teammitglieder dauerten einzelne Teil-schritte länger als geplant. Zum Teil wurden auch Vereinbarungen nicht


eingehalten. Dies führte aufgrund der wechselseitigen Abhängigkeiten der Einzelaufgaben zu starken Zeitverzögerungen des Gesamtprojektes. Koor-dinationsprobleme ergaben sich aber auch aus unterschiedlichen Vorstel-lungen ü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 Ver-ständnis für die Realisation einer gemeinsamen Arbeitsaufgabe. Jede Dis-ziplin verstand vielmehr ihren Aufgabenteil als zentral und versuchte die-sen kontinuierlich zu optimieren. Dadurch wurden teilweise zusätzliche Aufgaben ausgeführt, was wiederum die Integration der Einzelbeiträge er-schwerte. Ursächlich hierfür waren offenkundig auch Schwierigkeiten beim Projektmanagement: Aufgrund der mangelnden Erfahrung des Team-leiters mit der Abwicklung solcher Projekte, wurden Besprechungen kaum vorbereitet und es existierten wenig schriftlich fixierte Kommunikations-verläufe, wie z. B. Gesprächsprotokolle etc. Aufgrund der hohen Ansprü-che, welche die Gruppe selbst an die Innovativität dieses Projektes richte-te, 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 weitrei-chenden Handlungsspielraum zu lassen, um so von der disziplinären Viel-falt lernen zu können. Dies ließ zwar dem Einzelnen viel Freiraum für die Entwicklung und Umsetzung eigener Ideen. Gleichwohl führte diese offe-ne Situation gerade am Projektstart zu Unsicherheiten und erhöhte die sub-jektiv 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 Pro-jekt zu entwickeln. Dies gelang erst dann, als mit den ersten programmier-ten 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 Team-mitglied wieder von Neuem erarbeitet werden. Als problematisch für eine gemeinsame Wissensintegration zeichnete sich auch die verwendete Fach-terminologie ab. Da teilweise gleiche Inhalte unterschiedlich benannt wur-den, waren vielfach Missverständnisse innerhalb der Gruppe zu beobach-ten. Diese disziplinspezifische Problematik zeigte sich vor allem zu


Beginn des Projekts. Gerade in der Anfangsphase tat sich das Entwick-lungsteam 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 Sub-teams 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 in-terdisziplinä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 re-sultiert, dass die Beteiligten neben einem kollektiv verbindlichen Ziel auch eigene, persönliche Ziele mit dem Projekt verfolgten, wie z. B. einen per-sö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 wa-ren.

Erfassung von Kooperationsproblemen nach Entwicklungsphasen

Um das schon beschriebene Kooperationsmodell mit seinen drei Teilpro-zessen der Kommunikation, Koordination und Wissensintegration zu vali-dieren und das Auftreten von Kooperationsproblemen nach der jeweiligen Phase des Entwicklungsprozesses zu differenzieren, wurden im Verlauf der Fallstudie auftretende Probleme der Teamkooperation erfasst. Abbil-dung 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 Koordinationsan-forderungen 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


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 Abstimmungs-prozess erst richtig an Dynamik gewinnt.

Abb. 2.28. Probleme der Teamkooperation nach Entwicklungsphasen und Teil-prozessen der Kommunikation, Koordination und Wissensintegration

2.4.6 Handlungsempfehlungen aus Studie 1 und 2

Die Erfahrungen und Ergebnisse aus einer internationalen und interdis-ziplinären Kooperation im Bereich der digitalen Medienkunst stehen im Einklang mit Ergebnissen aus Untersuchungen der vorherigen Förderperi-oden. Aufgrund der hohen Innovativität und Komplexität der Aufgabe, der sehr heterogenen Teamzusammensetzung und der fehlenden Teamerfah-rung 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 Kom-munikation, Koordination und Wissensintegration. Zur Bewältigung dieser komplexen Arbeitsituation konnten im Verlauf der Untersuchung spezielle Strategien identifiziert werden, die sich wie folgt zusammenfassen lassen:


Präzise Definition der Aufgaben und Klärung der individuellen Beiträ-ge, z. B. gemeinsame Projektentwicklung in einem einwöchigen Work-shopVertrauensaufbau am Anfang des Projekts, z. B. gemeinsamer Kick-off, stufenweise Integration der Mitglieder Dokumentation der Arbeiten und Besprechungen im Projektverlauf Klare Organisation von Besprechungen Systematische Feedbackschleifen Förderung des Perspektivenwechsels Anregung der Kommunikation auch innerhalb der Untergruppen des Teams, nicht nur über den Projektleiter Frühzeitige Einbindung neuer Teammitglieder in den Prozess der Wis-sensintegrationKonsolidierung einer gemeinsamen Wissensbasis in Subteams Möglichst frühzeitige Erstellung eines (ggf. rudimentären) Prototypen, um das gemeinsame Grundverständnis für die Entwicklungsaufgabe zu fördernVerknüpfung des Gesamtziels mit individuellen Zielvorstellungen zur Erhöhung der intrinsischen Motivation Qualifizierung des Teamleiters zur Unterstützung der Kooperationspro-zesse.

2.4.7 Ergebnisse der Untersuchung von Auswirkungen fachlicher Teamheterogenität (Studie 3)

Die hier dargestellte Studie verfolgte das Ziel, die Auswirkungen der fach-lichen Durchmischung von interdisziplinären Entwicklungsteams zu ana-lysieren, 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 Sonderforschungsbereichenam Institut für Arbeitswissenschaft und Technologiemanagement (IAT) der Universität Stuttgart und der Technischen Universität Karlsruhe gebil-det 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 Medi-zintechnik und Fabrik“, TU Karlsruhe). Insgesamt wurden Daten von 41


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 Prob-lemen im Zuge der Wissensintegration umso wahrscheinlicher, je unter-schiedlicher 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 Team-mitglieder

Einzeldisziplinen wurden zu diesem Zweck zu den übergeordneten Gruppen Naturwissenschaften (Nat), Ingenieurwissenschaften (Ing), Sozi-alwissenschaften (Soz) und Wirtschaftswissenschaften (Wi) zusammen-gefasst. 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 we-sentlich größer als zwischen zwei Vertretern der Ingenieurswissenschaften. Es lässt sich somit zeigen, dass die Häufigkeit von beobachtbaren Proble-men in Abhängigkeit von den an der Kommunikation beteiligten Diszipli-nen betrachtet werden sollte.

Während Interaktionen zwischen Sozialwissenschaften häufig an unter-schiedlich verwendeten Fachbegriffen scheitern, sind zwischen Vertretern der Naturwissenschaften unbekannte Fachbegriffe die häufigste Ursache.


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 gewer-tet 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 einher-geht. 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ühr-ten Problemursachen. Sei es die fehlende Abstimmung der einzusetzenden Methoden, der häufig verwendeten Definitionen oder kompletter Lösungs-ansätze: So selbstverständlich die eigenen Ansichten über „das richtige Vorgehen“ sind, so unverständlich scheint für den Einzelnen der Wider-spruch der anderen Teammitglieder gegen die eigenen Vorstellungen zu sein. Um aus der Konkurrenz der fachspezifischen Ansätze keine Beein-trä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-


nandersetzung ausgewichen oder werden disziplinfremde Argumente igno-riert, wirkt sich dies mit hoher Wahrscheinlichkeit negativ auf das Ergeb-nis wie auch auf das Arbeitsklima des Teams aus.

Kategorie der Problemur-sache

Beschreibung

Fehlende Ab-stimmung 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-scher Gebrauch von Definitionen

Es findet keine Klärung über Begriffe mit disziplinspezifisch unter-schiedlichen Gedankenmodellen statt. Z.B. steht der Begriff „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-gen Lösungsan-sätzen ohne vorherigeVerständnis-klärung

Die in Subteams oder durch Einzelpersonen erarbeiteten Lösungen verhinderten das gemeinsame Nachvollziehen von Denkschritten und den Aufbau eines gemeinsamen Wissens (common grounds) über Methoden, Modelle und Begriffsdefinitionen. Die Angemessenheit des Vorgehens ist für andere Disziplinen in der fertigen und komplexen Lösung kaum mehr nachprüfbar.

Mangelnde Ak-zeptanz disziplin-spezifischer Inhalte

Finden ließ sich mangelnde Anerkennung disziplinspezifischer Inhalte in den untersuchten Arbeitskreisen zwar nicht in Form offenen Widerspruchs, wohl aber in z.T. impliziten Formen von Nichtanerkennung. Dazu gehörten z.B. das Nichteingehen auf Methodenkritik oder die Bezeichnung von einzelnen Aussagen und Schlussfolgerungen als „falsch“, weil sie nicht der Sichtweise der eigenen Disziplin entsprachen.

Ausweichverhalten

Vermeidung von verbindlichen Definitionen oder Verbleiben, um in 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ässigung fachfremder Argumente

Werden Sachverhalte nicht geklärt, die aus Sicht der eigenen Disziplin irrelevant scheinen, kann dies zum Abbruch einer 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 in-terdisziplinären Teams


Erfassung der Heterogenität von Entwicklungsteams

Zur Bestimmung des Ausmaßes funktionaler Heterogenität im Team wur-de der disziplinäre Hintergrund, d. h. die Art der Ausbildung der Team-mitglieder von jedem Teilnehmer über das Item „Studierte Fächer / Fach-kombinationen“ 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 AK 2 AK 3 AK 4 AK 5 AK 6 AK 7 Maschinenbau 2 1 1 1 7 BWL 2 3 1 Elektrotechnik 3 Physik 1 1 Informatik 3 2 1 Psychologie 2 1 2 Soziologie 1 1 Mathematik 1 1 Automatisierungs-technik

1

Wirtschaftsingenieur 1 Technische Kybernetik 1 Kommunikations- wissenschaft

1

Unbekannt 5 N 4 5 6 6 6 5 15

Disziplinen 2 2 5 4 4 4 > 4 HT 0.56 0.67 1.01 1.32 1.25 1.30 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ätsin-dex HT:

i

iiiT PPH

1)(ln

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


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] ent-wickelten Kooperationsskala erfasst. Die ursprüngliche Kooperationsskala besteht aus 16 Items für Koordination (alpha = .92), 15 Items für den Be-reich 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 Untersu-chung 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, Schwie-rigkeiten 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 Kommu-nikation, .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 einge-stuft. 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 zwi-schen 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 As-pekte 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 wur-de durch die Arbeitskreisleiter (N = 7) durchgeführt.


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

Kommuni-kation

Koordination Wissens-integration

Erfolg Selbsteinschätzung 1. Gesamt -.08 .12 .42** 2. Effektivität -.25 -.36 .75** 3. Qualität -.09 -.04 .70** 4. Schnelligkeit -.03 .21 -.05 5. Zielerreichung .20 .57** -.01 6. Atmosphäre -.02 -.14 .79**

Erfolg Fremdeinschätzung 1. Gesamt .37* .16 .25 2. Effektivität .80** .21 .37* 3. Qualität .62** .49** .62* 4. Schnelligkeit .01 .63** .12 5. Zielerreichung .22 -.19 -.11 6. Atmosphäre -.23 .02 -.16 * 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 Ge-samterfolg lediglich eine tendenzielle Beziehung zur Wissensintegration aufweist, lässt sich aufgrund des Gesamtbildes dennoch davon ausgehen, dass Wissensintegration mit Teamerfolg in entscheidenden Aspekten zu-sammenhängt.

Die Zahlen, die in Abb. 2.32 wiedergeben werden, enthalten eine weite-re interessante Aussage. Vergleicht man die Unterschiede, die zwischen den Korrelationen der Selbst- und der Fremdeinschätzung mit der Teamhe-terogenität entstehen, ergeben sich auf der Ebene der Teammitglieder weitaus geringere Korrelationen als auf der Ebene der Teamleiter, wie Abb. 2.33 zeigt.


Abb. 2.33. Differenzen zwischen teaminterner und teamexterner Erfolgseinschät-zung

Insbesondere in den Variablen Effektivität, Zielerreichung und Atmo-sphä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 Erfolgsein-schätzung der Teamleiter bei heterogenen Teams sehr viel negativer aus-fä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 ge-ringen Teamerfolg nicht im gleichen Ausmaß mit der Unterschiedlichkeit der Teamkollegen zusammen zu hängen. Das aus den Beobachtungen der


Teamsitzungen stammende Zitat „das sind halt immer schwierige Sitzun-gen 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 Zusam-menhang gebracht.

Beobachtete Strategien der Wissensintegration

In der schriftlichen Befragung der interdisziplinären Teammitglieder wurden zwei Fragen mit offenem Antwortformat vorgegeben, um Strate-gien 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 Teamzusammenge-hö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 Vermitt-lung Wert gelegt wurde (23.1% aller Personen), während nur 15.4% kon-kret auf zu fachspezifische Erläuterungen verzichten wollten. Dass bei der Wissensvermittlung fachspezifische Inhalte sich als problematisch erwei-sen könnten, wurde demnach nur von wenigen (insgesamt 17.9%) Perso-nen erkannt bzw. explizit thematisiert. Konkrete Strategien zur Vermitt-lung wurden nur von vier Personen genannt (10.3 %). Neben dem Hinweis auf die Fachspezifität von Inhalten wurde meist ein Vorgehen „vom All-gemeinen zum Spezifischen“ angestrebt, was dem sukzessiven Aufbau ei-ner gemeinsamen Wissensbasis entspricht. Einen Überblick über die ge-nannten Strategien zur Verständnissicherung gibt Abb. 2.35.


Häufigkeit der Nennun-gen

Häufigkeit über Personen [N =39] Kategorie

abs. % abs. % Art der Vermittlung 56 76.7 30 76.9 Bilder 11 15.1 11 28.2 Beispiel 11 15.1 11 28.2 einfach vermitteln 9 12.3 9 23.1 auf Wissensstand ein-gehen

7 9.6 7 17.9

nicht fachspezifisch erklären

6 8.2 6 15.4

Metapher, Analogie, Abstraktion

6 8.2 6 15.4

kurz erläutern 3 4.1 3 7.7 Grundlagen erklären 3 4.1 3 7.7 Strukturierung 2 2.7 2 5.1 Vorführung am Ob-jekt

1 1.4 1 2.6

Überblick geben 1 1.4 1 2.6 Medien der Vermitt-lung

8 11.0 7 18.0

Folien, Präsentation 5 6.8 5 12.8 Handout 2 2.7 2 5.1 Email 1 1.4 1 2.6 Inhalt der Vermitt-lung

1 1.4 1 2.6

Erläuterung von Beg-riffen

1 1.4 1 2.6

Spezifische Strategie 4 5.8 4 10.3 v. Allgemeinen z. Speziellen

3 4.1 3 7.7

Hinweis auf 'Fachspezifität’

1 1.4 1 2.6

Kontrolle 4 5.5 4 10.3 nachfragen 3 4.1 3 7.7 Diskussion 1 1.4 1 2.6

73 100.0 39 100.0

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


Häufigkeit der Nennun-gen

Häufigkeit über VPs [N =39] Kategorie

Abs. % Abs. % Kontrolle 43 72.9 32 82.1 nachfragen 32 54.2 32 82.1 Reaktionen etc. beobachten

10 17.0 10 25.6

Pausen, um Dialog zu ermöglichen

1 1.7 1 2.6

Partneraktivität 6 10.2 6 15.4 erklären lassen 4 6.8 4 10.3 Feedback abwarten 1 1.7 1 2.6 Diskussion 1 1.7 1 2.6 Proaktives Handeln 3 5.1 3 7.7 vorher gut erklären 2 3.4 2 5.1 vorher Begriffe erläutern 1 1.7 1 2.6 Dokumentation 2 3.4 2 5.1 Protokoll erstellen 2 3.4 2 5.1 Spezifische Strategie 2 3.4 2 5.1 Inhalte wiederholen 2 3.4 2 5.1 Nicht möglich 3 5.1 3 7.7

59 100.0 39 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 Part-neraktivitäten, eigenes proaktives Handeln, Dokumentation und die An-wendung spezifischer Strategien. Daneben hielten immerhin drei Personen (7.7 %) die Verständnissicherung generell für nicht möglich. Die verblei-benden 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 Part-ners 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


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 Ad-ressaten angepasst. Die explizite Bezugnahme auf die fachspezifische Be-deutung eines Zusammenhangs aus der eigenen Fachrichtung wurde nur in zwei Fällen beobachtet.

Die Kontrolle des Verständnisses durch Nachfragen, welche die am häu-figsten 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 ent-weder mit unbekannten oder anders verwendeten Fachbegriffen zusam-menhä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 ge-zeigt, dass Forschungsteams sehr unterschiedlich auf das Problem der In-terdisziplinaritä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 Gelin-gen interdisziplinärer Teamarbeit im starken Maße hemmend wirken. Be-sonders 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 Ver-meidung 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 weiter-hin hilfreich, um diese komplexen Sachverhalte zu erklären und späterhin zu dokumentieren.


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:

Das Bewusstsein für die Herausforderungen der fachlichen Heterogeni-tä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 interdis-ziplinären Teams sollte von Anfang an bewusst sein, dass sie mit gegen-sätzlichen Vorstellungen über die Gestaltung des Projekts konfrontiert werden, um eine produktive Einstellung zur Lösung dieser Gegensätze zu erreichen. 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. Schnittstellen zwischen Teammitgliedern sollten frühzeitig geklärt wer-den, d.h. an welchen Stellen Informations- oder Abstimmungsbedarfe und gegenseitige Abhängigkeiten bestehen. Besondere Bedeutung kommt der Explizierung von implizitem Wissen bzw. unausgesprochener Annahmen der einzelnen Experten zu. Dies be-zieht 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 Ziel-vorstellungen des Projekts geschaffen werden. Entgegen der allgemein anerkannten Notwendigkeit der Klärung unter-schiedlicher 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 Nichtwis-sen und Nichtverstehen, um die Hemmschwelle für das Nachfragen zu senken.Notwendig erscheint eine explizite Hervorhebung der Chancen und Herausforderungen von interdisziplinärerer Teamarbeit. Es gilt ein Ar-beitsklima zu schaffen, welches hilft, dass die Teammitglieder die u.U.


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 Beg-riffe, 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 un-terstützt werden. Bei RPD-Projekten, in denen Schnelligkeit und Zielerreichung eine ho-he 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 vermei-den, sollte bei hoher fachlicher Heterogenität im Team die Wissensin-tegration durch Einsatz unterstützender Strategien verstärkt werden. Umgekehrt ist bei erkennbar hohen Anforderungen an die Wissensinteg-ration, die z. B. durch eine hohe Problemkomplexität und ungünstige Rahmenbedingungen entstehen, auch die Reduzierung der teambezoge-nen Heterogenität durch eine fachlich homogenere Besetzung der RPD-Teams möglich. Durch Beachtung der spezifischen fachlichen Interaktionskonstellatio-nen (z. B. Dyaden mit der Kombination wirtschafts- und naturwissen-schaftlicher Fachhintergrund) sollten Strategien frühzeitig und gezielt bei denjenigen Teammitgliedern angesetzt werden, zwischen denen ers-te Kooperationsprobleme erkennbar werden. Bei der Wirkungsbeurteilung der eingesetzten Strategien sowie des Teamerfolgs sollten die unterschiedlichen Bewertungsperspektiven von Teammitgliedern, Teamleitern und übergeordneten Personen berück-sichtigt werden. Durch Klärung der Frage, welche Aufgabenpakete disziplinär und wel-che interdisziplinär bearbeitet werden sollen, sollte der Prozess der Wis-sensintegration entlastet werden.

Die hier beschriebenen Handlungsempfehlungen flossen in die nachfol-gend dargestellten Trainingsmodule zur Unterstützung der Wissensintegra-tion ein, die konkrete Hilfestellung zur Optimierung des Wissensaus-tauschs in Produktentwicklungsteams leisten.


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 interdis-ziplinä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 Produktentwicklungs-teams entwickelt. Dieses beinhaltet zwei Modulblöcke: Im ersten wird die aktive Entwicklung der gemeinsamen Wissens- und Erfahrungsbasis vo-rangetrieben (Abb. 2.36.), im zweiten die Steuerung der Wissensintegrati-on auf der Verhaltensebene vermittelt (Abb. 2.37.).

Abb. 2.36. Module zur Förderung der gemeinsamen Wissensbasis in Produktent-wicklungsteams.

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 eigentli-chen Expertenwissens schaffen, und zwar schneller und systematischer, als dies normalerweise abläuft. Hierzu


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

Abb. 2.37. Module zur Steuerung der Wissensintegration auf der Verhaltens-ebene.

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


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 un-terschiedlichen Wissens- und Erfahrungsbestände einfacher miteinander verknüpft und der daraus resultierende Integrationsaufwand reduziert wer-den.

Um dieses Ziel zu erreichen,

wird die Schnittmenge aus dem im Team prinzipiell verfügbaren Exper-tenwissen und aus dem für das Projekt relevante Wissen identifiziert (Modul 7), fachspezifisches Wissen auch für Fachfremde verständlich vermittelt (Modul 8), abstrakte Vorstellungen schnell konkretisiert, visualisiert und, soweit möglich, in erste Prototypen überführt (Modul 9), die häufig auftretenden Missverständnisse durch verstärkte Verständnis-kontrolle vermieden (Modul 10), der systematische Perspektivwechsel zwischen den Teammitgliedern – insbesondere in bezug auf die besonderen Sichtweisen der Fachdiszipli-nen und Unternehmensfunktionen – gefördert (Modul 11) und die für eine effiziente Wissensintegration erforderliche Teamkultur etab-liert, 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. Priori-tät hat bei der konkreten Konzeption der Übungsabfolge die Abstimmung der Übungsinhalte auf die Wissensintegrationsbarrieren, die in einer vor-hergehenden Analyse identifiziert werden. Je nach Produktentwicklungs-team 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 Wissensintegrati-on 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


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

Abb. 2.38. Vorgehen bei der Implementierung und Durchführung der Trainings-module zur Wissensintegration

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


wicklungsteams als Teilnehmern anzuwenden (Arbeitspaket 3). Zuletzt er-folgt die Evaluation von Lern- und Transfereffekten der Teilnehmer sowie die Transfersicherung, welche die Verbreitung der erarbeiteten Erkenntnis-se und Maßnahmen im Unternehmen fördert (Arbeitspaket 4).

Wesentlich für die Wirksamkeit der Trainingseffekte ist dabei die vor-hergehende Analyse des unternehmensspezifischen Produktentwicklungs-prozesses 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 Wis-sensintegration erforderlich, die – wie die Ergebnisse des Teilprojekts zei-gen – von den Teammitgliedern nicht immer bewusst wahrgenommen werden.

2.4.11 Zusammenfassung

Ausgangspunkt der Arbeiten im Themenbereich »Wissensintensive Ko-operationsprozesse bei der Entwicklung innovativer Produkte« war die Frage, wie die Kooperationsprozesse in Produktentwicklungsteams im Hinblick auf die spezifischen Anforderungen des Rapid Product Develop-ment 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 Kom-munikation, Koordination und Wissensintegration besteht. Die Unabhän-gigkeit der drei Teilprozesse voneinander wurde empirisch belegt. Weiter-hin 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 je-doch als abhängig von dem vorhergehenden Schritt definiert, da ohne ei-nen „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 rele-vant sind, wurden die vier Bereiche „Ziel- und Priorisierungswissen“,


„Fach- und Zusammenhangswissen“, „Erfahrungs- und Umsetzungswis-sen“ sowie „Definitions- und Faktenwissen“ zugrunde gelegt.

Um die besonderen Anforderungen des RPD-Produktentwick-lungsansatzes nachvollziehen zu können, wurden u.a. zwei Fallstudien durchgeführt. In der ersten Studie wurden in einem Automobil-Zulieferunternehmen die Kooperationskonstellationen der Produktentwick-lungsteams untersucht. Die Anforderungen zur Unterstützung der Team-kooperation konnten dabei nach Art der Kooperationsebenen (kernteamba-siert, kernteamübergreifend, betriebsübergreifend) sowie nach den Rahmenbedingungen (Heterogenität der Teamkonstellation, Kreativitäts-förderlichkeit des Umfelds, Komplexität des Entwicklungsprozesses) dif-ferenziert werden. In der zweiten Studie wurde eine Längsschnittuntersu-chung des Kooperationsprozesse in einem interdisziplinären Team durchgeführt, in dem eine hohe fachliche, funktionale und nationale Hete-rogenitä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 Kooperati-onsprobleme sowie die Bedeutung der Prototypisierungsphase für die Wis-sensintegration.

Um die Zusammenhänge der Kooperations- und Wissensintegrations-prozesse an einer größeren Stichprobe zu analysieren, wurden die Arbeits-treffen von insgesamt sieben interdisziplinär zusammengesetzten Arbeits-kreisen aus zwei Sonderforschungsbereichen untersucht. Es wurden auf qualitativem Weg typische Probleme und Problemauslöser für Wissensin-tegrationsbarrieren ermittelt. Weiterhin konnten Hinweise gefunden wer-den, dass Teamleiter die negativen Auswirkungen fachlicher Teamhetero-genitä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 Wissensintegrati-on in den Teams untersucht werden. Die kombinierte qualitative und quan-titative 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 Opti-mierung von Kooperations- und Wissensintegrationsprozessen abgeleitet werden. Diese wurden in Trainingsmodule für Produktentwicklungsteams


umgesetzt, in denen Strategien zur Bewältigung typischer Barrieren der Wissensintegration vermittelt werden. Gleichzeitig steht in diesen Modu-len 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 Errei-chung der im Rapid Product Development-Ansatz angestrebten Innovati-ons- und Effizienzziele geleistet werden.

Literatur

[2.1] Aalst WMP van der (2001) How to handle dynamic change and capture man-agement 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 ap-proach 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 Per-formance 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 behav-iour 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 econ-omy. 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 communica-tion 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): 305-327

[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 ef-fects. 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. Organisationspsy-chologie 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 ex-pert 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


[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 Tech-nology and Automation (33rd ISATA), 25.-29. September 2000 in Dublin, Ireland

[2.33] Dixon NM (2000) Common Knowledge. How Companies Thrive by Shar-ing What They Know. Harvard Business School Press, Boston

[2.34] Dosi G, Nelson RR, Winter SG (2002) The nature and dynamics of organ-izational 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; Recommen-dations. 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 Produk-tentwicklung. 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: Predic-tors 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 In-formation 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 37-46

[2.50] Herbig B, Büssing A (2003) Implizites Wissen und erfahrungsgeleitetes Arbeitshandeln: Perspektiven für Arbeit und Organisation. Arbeit 12(1):36-53.

[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 prod-uct development: Diversity, communications, job stress, and outcomes. Acad-emy 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


[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 consen-sus. 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 Com-petitive Engineering, 12.-16. April in Lausanne, Switzerland. Millpress, Rot-terdam

[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 Engi-neering - A Teamoriented Project Planning System with Capacity Planning, Product Knowledge; Process Knowledge. In: Proceedings for the 32nd Inter-national 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 Sympo-sium on Automotive Technology and Automation (33rd ISATA). 25.-29. Sep-tember 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 Con-ference on Product Development, 1st Automotive and Transportation Tech-nology Congress and Exhibition (1st ATTCE). 1.-3. Oktober 2001 in Barce-lona

[2.74] Lindblom, CE (1959) The Science of Muddling Through. Public Adminis-trative 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 Manage-ment 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 Man-agement 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, Mah-wah; New Jersey

[2.90] Pascale RT (1990) Managing on the edge: how successful companies use conflict to stay ahead. Viking, London


[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, Wies-baden

[2.94] Pinto M (1989) Predictors of cross-functional cooperation in the implemen-tation 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. Disserta-tion, 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 perform-

ance 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. Jost-Jetter, 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öf-fentlichte Doktorarbeit. Friedrich-Alexander-Universität Erlangen-Nürnberg, 1995

Literatur 121

[2.109] Sethi R, Smith DC, Park, CW (2001) Cross-functional product develop-ment 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 be-tween 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 engi-neering 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 Meth-ods and Research 8(3):341-362

[2.118] Thomke S, Fujimoto S (2000) The Effect of "Front-Loading" Problem-Solving on Product Development Performance. The Journal of Product Inno-vation 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):25-30

[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 arbeits- und sozialwissenschaftlichen Perspektive: In: Harburger Beiträge zur Psychologie und Soziologie der Arbeit (14), Hamburg: TU Hamburg-Harburg, S 1-57


[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 Ac-quisition. Management Science 49(4):514-528

3 Vernetztes Wissen für die interaktive Entwicklung von Prototypen

Innovative Entwicklungen sind gekennzeichnet durch ihren engen zeitli-chen Rahmen und die hohen technischen Anforderungen an die Herstell-verfahren. Gleichzeitig steigt die Komplexität der zu entwickelnden Pro-dukte sowie die Notwendigkeit einer effizienten Nutzung vorhandenen Wissens aus unterschiedlichen Bereichen. Vor dem Hintergrund der wach-senden Informationsflut erweist sich die Möglichkeit der Integration, Auf-bereitung und Verdichtung von heterogenen Datenbeständen in der schnel-len 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, son-dern maßgeblich durch dessen Entwicklung und Produktion bestimmt. Somit können besonders in den frühen Phasen durch eine enge Verzah-nung von Informationen aus den Bereichen Konstruktion, Qualität und Fertigungsplanung unnötige Iterationszyklen vermieden und Produkte ei-ner neuen, höheren Qualität entwickelt werden (Abb. 3.1.) [3.8], [3.38], [3.37].

Eine besonders hohe Vielfalt der Datenverarbeitungsarten und des Wis-sensmanagements in den Produktentwicklungsphasen trägt oft zu Informa-tionsverlusten bei, die anschließend in Nachfolgeprozessen neu generiert werden müssen. Diese Informationen werden an unterschiedlichen Stellen im Entwicklungsprozess erzeugt und abgerufen. Geometrische Informatio-nen werden beispielsweise in der Konstruktion definiert, wobei diese In-formationen 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 3 Vernetztes Wissen für die interaktive Entwicklung von Prototypen

Abb. 3.1. Informationsdichten in der Produktentwicklung

Hieraus ergibt sich die Notwendigkeit der Einführung effizienter Integ-rationsstrategien, die sowohl den iterativen Einsatz physischer Informati-onsträger (z.B. Designmodelle, Skizzen, Entwurfspläne) und virtueller In-formationsträger (z.B. CAD-Modelle, RE-Solid-Modelle, Facetten-Modelle) 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üns-tige 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 Fehlentwick-lungen zu erkennen und entsprechend gegenzusteuern. Ebenfalls wird die Weiterverfolgung mehrer Konstruktionsvarianten ermöglicht, da ein ech-ter, 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 traditio-nelle, starre, sequentielle Entwicklungsprozesse. Ihr Potential wird nicht vollständig genutzt. Es ist folglich nicht mit einer Einsparung von Ent-wicklungskosten zu rechnen, wenn RP-Technologien als eine Art zusätzli-ches Werkzeug betrachtet und verwendet werden, sondern nur dann, wenn auch das Potenzial solcher Technologien in einer angepassten Entwick-lungsphilosophie zum richtigen Zeitpunkt eingesetzt und mit anschließen-der Analyse und Bewertung der Ergebnisse verwertet wird. Es ist der Ent-wicklungsprozess, der insgesamt dem RP-Gedanken verschrieben sein muss, um Vorteile hinsichtlich der Entwicklungszeit, der Entwicklungs-kosten und der Qualität des Produktes als Ganzem zu erzielen (Abb. 3.2.).

Abb. 3.2. Mehrdimensionales Steuerungsinstrument als Regulativ im Entwick-lungsprozess

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


effizient zu vernetzen sowie die fehlenden Bausteine in der Entwicklungs-kette 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 Konzep-tion und Vorauslegung eines Produktes können in den klassischerweise darauf folgenden Entwicklungsschritten nur zeit- und kostenintensiv korri-giert werden. Häufig erfordern sie aufwendige Anpassungen an den Kon-struktionen, nicht zuletzt deshalb, weil die Auswirkungen der konstrukti-ven 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 er-fordern 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 Lasten-heft definierten Qualitätsmerkmale eine gewichtige Rolle, sondern gerade auch die subjektiven Erwartungen der Kundschaft. Diese möglichst voll-ständig zu erfassen, ist Aufgabe der Marktstrategen und auch des Kunden-dienstes, der wertvolle Anregungen oder Kritik in die Entwicklung mit ein-fließ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 selbstver-ständlich deren Funktion. Viele dieser Qualitätsmerkmale werden vom Kunden als selbstverständlich vorausgesetzt, müssen jedoch in der Pro-duktentwicklung 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 Arma-turenträ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.


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 kon-struktive Merkmale bedingt. Die Optimierungen von Fertigungsplanung und Arbeitsvorbereitung durch die Wahl von z. B. geeigneten und wirt-schaftlichen 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. Ei-ne Beherzigung dieser Aufgabe bringt nach Erfahrungen von [3.21] eine Senkung der Herstellkosten von 10 bis 30%. Die Einführung neuer Metho-den und Konzepte zur Berücksichtigung von Kosten trägt jedoch deutlich mehr zu der Kostensenkung bei. Dem Entwickler muss verdeutlicht wer-den, dass jede technische Festlegung und jede Entscheidung auch die Kos-tenentwicklung bestimmt. Die Kosten müssen folglich simultan zur Ent-wicklung 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 Control-lings, 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 Un-ternehmens sein, setzt jedoch auch einigen Mut zur Einführung neuer Me-thoden und Konzepte voraus. Die in der Kostenanalyse existierenden Zu-sammenhänge sind nicht neu, lediglich die Umsetzung lässt meist sehr zu wünschen übrig. Ursache sind häufig die verwendeten Werkzeuge, die ei-nen 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 Fragestel-lungen rund um die Produktgestaltung. So werden sowohl die funktions-


orientierte Konzeption des Produktes wie auch seine ästhetische Gestalt bereits zu einem sehr frühen Zeitpunkt der Produktentwicklung grundle-gend bestimmt. Damit verbunden ist eine überproportional hohe Kosten-verantwortung und Entscheidungsfreiheit. Um daraus resultierende Er-kenntnisse zu nutzen, fehlen besonders Lösungen für eine verteilte Produktentwicklung in derzeitigen 3D-CAD-Systemen. Das Produktwis-sen ist nur oberflächlich integriert, Daten können gut „verwaltet“ aber nur in begrenztem Umfang von mehreren Konstrukteuren koordiniert, zeit-gleich bearbeitet und mit anderen Systemen effektiv ausgetauscht werden.

Der Einsatz sehr unterschiedlicher Werkzeuge, die einerseits ein intuiti-ves Arbeiten mit vielen Informationen am noch nicht detaillierten Produkt ermöglichen, andererseits aber auch bereits diverses Produkt- und Pro-zesswissen analysieren, ist Stand der Technik – für deren informations-technische Einbindung in die CAx-Welt gibt es bisher jedoch keine durch-gängigen Lösungen. Besonders die intuitiven Informationen aus der Prototypenherstellung konnten trotz steigender Prototypennutzung bis heu-te nicht systematisch in die Abläufe integriert werden. Ein realer Produkt-entstehungsprozess 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 ge-wonnene Wissen wird aber nur partiell und nicht systematisch in die Pro-duktentstehung eingebunden. Die Entwicklungsprozesse können aber durch das Einbinden von „intelligenten“ Prototypendaten basierend auf der Verarbeitung unvollständiger und unscharfer Produktdaten sowie „lernen-den“ Qualitätstools stark beschleunigt werden. Die Bereitstellung solcher wissensbasierter Werkzeuge auf Basis der definierten Informationsschnitt-stellen 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 Entwicklungs-prozess zur Verfügung zu stellen.


Abb. 3.3. Prozesse in der Produktentwicklung

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

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. Diesbe-züglich wurden Modelle für ein Qualitätsmanagement in der Erstellung physischer Prototypen entwickelt. Dabei wurden die folgenden Schwer-punktthemen berücksichtigt:


Bestimmung von Qualitätsmerkmalen beim Aufbau physischer und vir-tueller Prototypen und Prognose der zu erwartenden Qualität Kontextsensitive Methodenauswahl und Komplexität im Rapid Prototy-pingSimulation von Prototypenherstellprozessen Referenzmodell des Qualitätsmanagements in dynamischen Strukturen für ein umfassendes Qualitätsmanagementkonzept

In Kapitel 3.4 werden Werkzeuge und Methoden zur effizienteren Steu-erung 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 unter-schiedlichste Software eingesetzt. Für Vorauslegung und Berechnung, für Simulation und Visualisierung, für Messung und Steuerung und nicht zu-letzt für Dokumentation, Versionsverwaltung und Projektmanagement e-xistiert eine breite Palette an Programmen, die sich untereinander versu-chen, 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ögli-chen Funktionen und Daten.

Zumeist kann davon ausgegangen werden, dass ein Tool zum Lösen o-der 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 vor-dringt. Andererseits mangelt es Spezialtools häufig an Bedienkomfort und an Import- sowie Exportmöglichkeiten. Im Übrigen werben die Software-hersteller, die Zeichen der Zeit erkennend, allzu eifrig mit eben diesen Da-tenaustauschmö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 Funktio-nen damit auch abgedeckt sind. Es bedeutet lediglich, dass einige Grund-funktionen 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 Berechnungs-tools. Mehrfache Iterationen beispielsweise zwischen Geometrieanpassung und Festigkeits- oder Strömungssimulationen, häufig noch mit Gewichts- oder Formoptimierungstools erfordern ein hohes Maß an Konvertierungs-vorgängen, die meist nur uni-direktional funktionieren. Ist man sich dessen nicht bewusst, so können während der Iterationsschleifen wichtige Bauteil-informationen 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-/CFD-Softwareherstellern. Wann und ob jedoch umfassende bi-direktionale Da-tenkonvertierungen realisiert werden, bleibt abzuwarten.

Ein weiteres Problem stellt die mangelnde Produkttransparenz dar. Än-derungen an einem Bauteil eines Systems wirken sich i. d. R. auch auf an-dere 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, schlimmsten-falls gar erst in der Vorserie zutage treten. Korrekturen zu diesem Zeit-punkt sind unnötig kostspielig und verlängern die Entwicklungszeit.

Ähnlich verhält es sich mit der Kostenentwicklung und der Produktzu-verlä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-


verlässigkeit lassen sich an vielen Beispielen jüngst vergangener Entwick-lungen aufzeigen und bringen kleine wie auch große Unternehmen glei-chermaßen gehörig ins Schwitzen. Denn nicht nur das Produkt selbst leidet unter einer geringen Zuverlässigkeit, sondern es befleckt schnell das Fir-menimage, den guten Ruf in der Öffentlichkeit und vergrault damit let-zendlich 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 ent-wickelt werden kann, wenn zur richtigen Zeit auf die notwendigen Infor-mationen zugegriffen werden kann. Ehrlenspiel zeigt in [3.21] grundsätzli-che Mechanismen zur Kostensteigerung und -senkung auf und führt neben der Informationsverfügbarkeit auch Organisation und Kommunikation so-


wie Kompetenz und Erfahrung als Voraussetzung für kostengünstige Pro-duktentwicklung an (Abb. 3.4.).

Das Institut für Maschinenelemente (IMA) der Universität Stuttgart entwickelt seit einigen Jahren ein Konstruktionssystem, das viele der ge-nannten 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 wel-chem viele Vorgaben noch unscharf oder unbekannt sind. Das Aktive Se-mantische Konstruktions- und Zuverlässigkeitsnetz (ASK/ASZ) bietet die Möglichkeit, ein Produkt mit all seinen Baugruppen bis hinunter zur Bau-teilebene hierarchisch und umfassend abzubilden und seine Daten intelli-gent miteinander zu verknüpfen. Dies bietet eine ganze Reihe von Vortei-len, u.a:

Informationen werden schnell gefunden, nicht mehr aufwendig in verschiedenen Quellen gesucht. Vollständige Vernetzung der Produktinformationen. Darstellung al-ler Abhängigkeiten durch Modellierung eines vollständigen Produktab-bildes.Ein gemeinsames Berechnungsmodell für alle Entwicklungsphasen.Auslegung auch mit unscharfen Informationen und Intervallen unter Ausnutzung des vollen Lösungsraumes. Die Auswirkungen von Parame-tervariationen auf das gesamte Produkt sind sofort ersichtlich. Bi-direktionaler Datenaustausch mit modernen 3D-CAD Systemen.Einfache Bearbeitung und Detaillierung der Produktkomponenten. Nut-zung vorhandener Schnittstellen zu FEM-, NC-, RP- oder PDM-Software möglich. Berechnung der Systemzuverlässigkeit. Beschleunigte Produktent-wicklung und Qualitätsverbesserung durch frühzeitige Betrachtung der Systemzuverlässigkeit. Qualitative und quantitative Zuverlässigkeitsbe-trachtung mit Importanzanalyse. Kostenabschätzung bereits während der Konzeptionierung. Kosten-intensive 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 Regelwer-ken 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-


führt. Dabei evtl. auftretende Kollisionen werden durch Benutzerinterakti-on 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 Produktent-wicklung stehe können. Unterschieden wird u.a. zwischen Konstruktions-objekten, Anforderungsobjekten, Funktionsobjekten, Organisations-objekten, oder Dokumentationsobjekten.

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


Als Formen der Beziehung werden mittels unterschiedlicher Kanten zwischen den Knoten etwa dargestellt: Propagation, Forderungen, Anord-nungen, 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 mit-einander zu verknüpfen [3.47], [3.53]. Ausgehend von einer Anforde-rungsliste, einem Lastenheft oder ähnlichen Vorgaben werden Funktions-prinzipien 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 Zu-verlä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 zu-dem einen Überblick über die genaue Produkt- und Bauteilstruktur.

Das gemeinsame Berechnungsmodell erlaubt es, mehrere Parameter in nahezu beliebigen mathematischen und logischen Zusammenhängen mit-einander zu kombinieren, bzw. mit Hilfe von Constraints in Beziehung zu-einander zu setzen. Auf diese Weise werden Variablen miteinander ver-knüpft und schrittweise zunächst durch weit gefasste Wertebereiche, später dann mit immer engeren Intervallen bis hin zu diskreten Werten beschrie-ben. Aus den Verknüpfungen der Variablen miteinander entsteht ein In-formationsnetz, das innerhalb eines Bauteils, einer Baugruppe oder sogar über das ganze Produkt hinweg Informationen verknüpft und so auch komplexe Zusammenhänge abzubilden vermag.


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 al-le, nicht alle beliebig kombinierbar und vor allem nur mit konkreten fest-gelegten 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 Varian-ten 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 of-fen 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 Konstruk-teurs, 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 ver-meiden und Zeit einsparen.


Die Anbindung an ein 3D-CAD-System erfolgte mit Pro Engineer® der Firma PTC. Dieses System verfügte als eines der Ersten über eine Schnitt-stelle 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 entspre-chend 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, PDM-Anbindung, etc. vollständig erhalten und somit weiterhin nutzbar.

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

Umgekehrt ist es möglich, ein CAD-Modell in Pro Engineer® zu modi-fizieren 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-


gungsstudien, ohne dazu explizit jeden Wertebereich auf fixe Werte ein-grenzen 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 Diskre-panzen zwischen F/E- und Controllingabteilungen. Der Spagat zwischen einem optimal gestalteten und dennoch wirtschaftlichen Produkt, das zu-dem noch zu einem konkurrenzfähigen Preis auf den Markt gebracht wer-den 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 Op-fer, 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 Sit-zungen anberaumt werden müssen, erhalten F/E-Abteilungen vielerorts ei-gene Controller, die auf die speziellen Erfordernisse und Hintergründe hin sensibilisiert werden.

In der Regel werden allerdings nur bestimmte Meilensteine der Ent-wicklung auf die Einhaltung von Zielkosten hin überprüft. In diesem Sta-dium 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 realisier-bar. 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 Werk-stoffen, 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 Produktzuver-lässigkeit gespart wird, sind höhere Kosten für Garantie- und Kulanzleis-


tungen und deren Abwicklung einzubeziehen. Auch Ersatzleistungen für Maschinenausfälle, Sach- und Personenschäden sind ein enormes Kosten-risiko, das es auszuschließen gilt.

Aus diesem Grund ist es sinnvoll, möglichst umfassende und genaue Kostenabschätzungen bereits zu Beginn der Produktentwicklung anzustel-len 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 kos-tenintensive Bauteile hinweisen und in sehr enger Abstimmung mit den Konstrukteuren Abhilfe schaffen. Das Aktive Semantische Konstruktions- und Zuverlässigkeitsnetz ist in der Lage, eine Konstruktion auf die Einhal-tung 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 Her-stellkosten im Laufe der Entwicklung ständig aktualisiert. Wird der Kos-tenrahmen gesprengt, können die Mehrkosten beispielsweise durch kon-struktive 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 Ga-rantie- und Kulanzkosten wird im Rahmen des jüngst gestarteten Transfer-projektes 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ässigkeits- und Verfügbarkeitskennwerte gerecht zu werden. Die Entwicklung zuver-lässiger Produkte erfolgt unter Randbedingungen, die sich zunehmend ver-schärfen. Die Zuverlässigkeit wird einerseits durch kürzere Entwicklungs-zeiten, 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].


Heutzutage werden die Anforderungen an ein Produkt bezüglich der ge-forderten Zuverlässigkeit im Feld schon im Lastenheft vorgegeben. Zu diesem Zeitpunkt gilt diese Zielvorgabe als interner Maßstab für die Ent-wicklung eines Produktes. Um diese Zielvorgabe über den gesamten Ent-wicklungsprozess verfolgen zu können, bedarf es einem Zuverlässigkeits-system, 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 er-füllen [3.7], siehe Abb. 3.8.

Zuverlässigkeitsbetrachtungen sollten daher aufgrund der hohen Anfor-derungen 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 Produktentwicklungs-phase).


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 Umge-bung 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äventi-ven Identifizierung von kritischen Baugruppen bzw. Komponenten und de-ren 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 Ein-fluss-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 Fehler-zusammenhä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 Optimie-rung und weitere Risikominimierung ermöglicht werden kann. Darüber hinaus bietet die FMEA nach VDA 4 [3.74], durch ihre ausführliche Vor-


gehensweise in fünf Arbeitsschritten eine Vielzahl an Schnittstellen zu an-deren qualitativen Zuverlässigkeitsmethoden, die mit ihr bereits mit abge-deckt werden können [3.61], [3.60]. Zu einer der wichtigsten Methoden-schnittstellen gehört die Schnittstelle zur FTA (Fault Tree Analysis), die sich in weiten Bereichen in aktuellen FMEA Software Tools ebenso dar-stellen lässt, z. B. in Form eines Fehlernetzes aus dem 2. Schritt der FMEA bzw. in Form von FTA-Grafikmodulen. Eine weitere methodische Schnitt-stelle 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 re-nommierten 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 über-nommen werden. Dabei kann mit Hilfe einer qualitativen Vorbetrachtung eine Einteilung in zuverlässigkeitsrelevante oder auch nicht relevante Komponenten unterschieden werden. Dieser Aufbau eines Zuverlässig-keitsnetzes erfolgt teilautomatisiert, d.h. es können Komponenten unter-schiedlicher Parameterstruktur einzeln als auch vordefiniert aus der Daten-bank gelesen und ins ASZ implementiert werden.

Werden nach dem Erstellen des Zuverlässigkeitsnetzes Änderungen von Parameterwerten an der zugrunde liegenden ASK-Konstruktion vorge-nommen, so können mit einem speziellen Menüpunkt alle Änderungen an zuverlässigkeitsrelevanten Parametern übernommen und ggf. die Parame-ter der Verteilungsfunktionen korrigiert werden. Das entwickelte Zuverläs-sigkeitsprogramm 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ön-nen dann übernommen werden.


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 heutzu-tage 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-


durch, dass für die Verschleiß- und Ermüdungsausfälle, ausgehend von dem Ausfallverhalten der Systemelemente, eine Aussage über das Ausfall-verhalten des Systems ermöglicht wird [3.73].

Im aktiven semantischen Zuverlässigkeitssystem wurden deshalb ver-schiedene Ausfallverteilungen implementiert, um für die unterschiedlichs-ten Bauteile und Systeme das Ausfallverhalten ermitteln zu können. Wird beispielsweise für ein Bauteil eine konstante Ausfallrate ermittelt, so er-folgt 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 drei-parametrische Weibullverteilung bietet hierbei den Vorteil, eine ausfall-freie Zeit als Parameter in die Betrachtung einfließen zu lassen. Weitere wichtige Verteilungsarten zur Beschreibungen von Zuverlässigkeitsbe-trachtungen sind die Normalverteilung als auch die Lognormalverteilung. Um diese wichtigen Verteilungen bei der Durchführung einer Zuverlässig-keitsanalyse im Konstruktionsprozess integrieren zu können, wurde fol-gende Verteilungsarten in das Zuverlässigkeitsnetz integriert:

Exponentialverteilung WeibullverteilungLognormalverteilung Normalverteilung

Nach dem Booleschen Modell kann über die gesamte Konstruktion eine Systemzuverlässigkeit berechnet werden. Dabei ist es möglich, die Glei-chung 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äs-sigkeitsprogramm grafisch dargestellt werden. Tools für die optische Auf-bereitung und anwenderfreundliche Darstellung sind ebenso integriert wor-den 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 Para-meterstruktur.


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 Importanzbe-rechnung 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 errei-chen. Der Einsatz einer Importanzberechnung reduziert deutlich die Ent-wicklungszeit eines Produktes und verringert zudem die Entwicklungskos-ten.


Abb. 3.13. Importanzberechnung (links) und Systemgleichung (rechts) des Misch-systems aus Abb. 3.11.

Insgesamt wurde im Sfb 374 ein Aktives Semantisches Zuverlässig-keitsnetz aufgebaut, welches dem Entwickler zu jedem Zeitpunkt im Ent-wicklungsprozess 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 vorangetrie-ben 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, sol-len 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 resultieren-den Anforderungsanalyse kann das ASK/ASZ bereits in den frühen Phasen der Produktentwicklung sinnvoll eingesetzt werden. Stück für Stück wird


ein Produktabbild in Form eines Netzes erstellt und je nach Entwicklungs-stand mit immer präziseren Informationen konkretisiert.

Zu Beginn des Entwicklungprozesses wird der Konstrukteur bei der Lö-sungssuche durch gebräuchliche Methoden der Kreativitätstechniken un-terstü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 Pro-dukt zu erstellen. Unter Zuhilfenahme von analytischen, intuitiv und dis-kursiv betonten Methoden sowie Konstruktionskatalogen werden poten-tielle Lösungsansätze erstellt und miteinander kombiniert. Mit verschiedenen Bewertungsmethoden [3.50], [3.56] werden die unterschied-lichen 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 Produkt-entwicklung in Verbindung mit kurzen Iterationszyklen die Verfolgung mehrerer Lösungsansätze, die untereinander kombiniert und variiert wer-den können, um eine optimale Lösung zu erreichen.

Im ASK/ASZ werden die Lösungsprinzipien in Funktionsbausteine zer-legt 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 ho-hem 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.


Abb. 3.14. Kreativitätstechnik-Server am IMA

Da in der ersten Phase der Produktentwicklung zunächst nur die Anfor-derungen definiert sind, ist es sinnvoll, diese bereits im ASK detailliert ab-zulegen. Neben der Dokumentation der Produktentwicklung dient die An-forderungsliste 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 Funktio-nen und ihre Zusammenhänge detailliert abbildbar sind. In Abb. 3.15 wur-den so die einzelnen Funktionen ihren Baugruppen, bzw. Bauteilen zuge-ordnet.

Erkennbar sind in dieser Abbildung auch unterschiedliche Konkreti-sierungsstufen. Während der im unteren Bereich sichtbare elektro-mechanische Aktor als eigene Baugruppe bereits aus verschiedenen Bau-teilen besteht, sind diese beim elektro-mechanischen Aktor (2) als Teile der Steuerung (2) oben rechts im Bild noch nicht ausgestaltet. Dennoch ist die-


ser bereits in der Konstruktion als geplante Baugruppe vorhanden und kann hinsichtlich der Zuverlässigkeits- und Kostenbetrachtung bereits be-rücksichtigt werden. Auch Anschlussgrößen können bereits konkret ge-plant werden. Auf diese Weise werden moderne Methoden der beschleu-nigten 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 au-tomatischen 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 auf-gedeckt, weil z.B. mehrere Konstrukteure an verschiedenen Komponenten entwickeln, so können Kollisionen, durch einen Koordinationsprozess un-ter den betreffenden Entwicklern abgestimmt, beseitigt werden.


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. Ha-ben sie einen Stand erreicht, den sie an alle weiteren Mitarbeiter übermit-teln wollen, so lösen sie einen Updateprozess aus, der sämtliche Änderun-gen von den übrigen am Server registrierten Clients einsammelt und auf Konsistenz überprüft. Sind die Änderungen konsistent, so werden alle Än-derungen in das Basisnetz überführt und die Clients arbeiten mit dieser ab-geä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 un-bemerkt jeweils ihre eigenen Entwicklungszweige eröffnen, die im An-schluss zeitaufwändig wieder zusammengeführt werden müssen.

Das hinterlegte Rechtemodell stellt sicher, dass ein Entwickler nur sol-che Bauteile verändert, zu deren Änderung er auch berechtigt ist. Tangie-ren seine Anpassungen Bauteile, zu deren Änderung keine Berechtigung vorliegt, so wird wiederum ein Abstimmungsprozess in Gang gesetzt.

Besondere Beachtung verdient auch das phasenübergreifende Berech-nungsmodell [3.53]. Mittels Parametern, die mit Intervallen, Listen oder


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 Ver-knüpfung von Intervallen liefert folglich auch wieder Intervalle als Ergeb-nisgrößen. Durch schrittweises Einschränken der Intervalle werden somit die anderen Parameterintervalle ebenfalls eingeengt. Auf diese Weise ge-langt 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 Sitzlehnenver-stellung eines Pkw-Sitzes

Auf diese Weise werden bereits in frühen Phasen der Produktentwick-lung 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 To-leranzfeldanalysen lassen sich mittels dieser Überprüfung durchführen.


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 hineinge-zoomt werden, wobei die umliegenden Komponenten ausgeblendet wer-den. Analog dazu kann man auch Baugruppen „aufklappen“, um bei-spielsweise deren Bauteile mit benachbarten Bauteilen in Beziehung zu


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 kon-kretisiert und erste Produktmodelle erstellt. Hierzu werden im CAD-System die Modelle erstellt und die korrespondierenden Parameter mit de-nen im ASK über die entsprechende Schnittstelle gekoppelt. Von jetzt an können wahlweise im CAD-System oder im ASK/ASZ Änderungen vor-genommen werden, die automatisch in das jeweils andere System über-nommen werden.

Diese bi-direktionale Schnittstelle ist deshalb so wichtig, weil auf diese Art keine Bauteilinformationen verloren gehen. Die im ASK/ASZ als abs-trakte 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 Kupplungssys-tem (AKS) als Teil des A-Klasse Cockpits.


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

Ist ein bestimmter Konkretisierungsgrad in der Erstellung der Produkt-struktur erreicht, so ist für kritische Bauteile eine qualitative Zuverlässig-keitsanalyse anzuraten. Bei der FMEA (Fehler-Möglichkeits- und Ein-fluss-Analyse) werden Systeme in ihre Bestandteile zerlegt und deren Funktion ermittelt. Die negierte Funktion ergibt die entsprechende Fehl-funktion, deren Ursache und Auswirkung auf das Gesamtsystem genau spezifiziert wird. Mit verschiedenen Faktoren für Auftretenswahr-scheinlichkeit, 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ässigkeits-netz 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ücksich-tigt wird. Zudem spart dieser Vorgang enorme Zeit, da normalerweise im Zuge der FMEA zunächst alle diese Daten aufwändig gesammelt werden müssen.


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 Entdeckungs- und 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 un-terschieden werden können. Je nach Entwicklungsstand kann es sinnvoll sein, nur bestimmte Komponenten in den Systemeditor des ASZ zu impor-


tieren. Aus diesem Grunde stehen dem Benutzer drei Wahlmöglichkeiten zu Verfügung (s. Abb. 3.10.):

Import solcher Elemnte, die bereits Daten enthalten Import sämtlicher Elemente 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 ei-nes bestimmten Bereiches der Konstruktion durchzuführen, um z.B. be-sonders kritische Bereiche getrennt zu untersuchen, oder um Bereiche aus-zusparen, die in der Entwicklung noch nicht weit genug fortgeschritten sind.

Im Systemeditor des ASZ werden die Konstruktionselemente nun ent-sprechend ihres Zuverlässigkeits-Kontextes zueinander platziert und erge-ben 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 darge-stellt sind, werden nun die Zuverlässigkeitsparameter hinterlegt, die das Ausfallverhalten der einzelnen Komponenten beschreiben. Um das Aus-fallverhalten des Gesamtsystems zu ermitteln, werden die einzelnen Daten miteinander verrechnet.

Mit der Importanzanalyse kann nun überprüft werden, welche System-zuverlässigkeit zu einem vorgegebenen Zeitpunkt vorliegt, ob die Sollvor-gaben erfüllt wurden und welche Zuverlässigkeit die einzelnen Kompo-nenten zu diesem Zeitpunkt erreichen. Wird die geforderte


Systemzuverlässigkeit nicht erreicht, so werden die schwächsten Glieder hervorgehoben und markiert. Auf diese Weise sind sofort die Komponen-ten 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, Ausfallwahrschein-lichkeit und Überlebenswahrscheinlichkeit. Jedes der Diagramme kann in unterschiedlichen Darstellungsformen angezeigt werden, als Normalvertei-lung, Log-Normalverteilung und als Weibullverteilung.

In Abb. 3.23 ist die Ausfallwahrscheinlichkeit am Beispiel der Hand-schaltung dargestellt. Die Daten wurden zur Wahrung der Vertraulichkeit absichtlich verzerrt und auf nicht veröffentlichte Werte normiert. Sie ent-sprechen nicht den tatsächlichen Daten und dienen hier lediglich der De-monstration der Vorgehensweise.

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



Das Aktive Semantische Konstruktions- und Zuverlässigkeitsnetz ASK/ASZ ist ein Softwareprototyp zur Unterstützung von interdis-ziplinä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 Entwicklungs-prozesses und auch darüber hinaus produktbegleitend eigesetzt zu werden.

Das ASK/ASZ ersetzt hierbei nicht die bereits verwendeten und im Un-ternehmen etablierten Softwarewerkzeuge, sondern ist als Bindeglied da-zwischen anzusehen. Es dockt an bestehende CAD-Systeme, Datenbanken und Zuverlässigkeitssoftware an und stellt diesen Daten zur Weiterverar-beitung 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 Be-rücksichtigung von Zielkosten und der Systemzuverlässigkeit zu entwi-ckeln.

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 A-Klasse 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ön-nen so im Sinne eines Variantenmanagements als Bausteine eines Baukas-tens abgelegt und wieder verwendet werden.

Die integrierte Bauteilbibliothek erleichtert die wirtschaftliche Produkt-entwicklung durch die Verwendung im Unternehmen bereits bekannter Komponenten und vermeidet unnötige doppelte Entwicklung.

Durch den verwendeten Ansatz des semantischen Netzes können Aus-wirkungen 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 Qua-lität der Produkte sowie ein frühest möglicher Markteintritt erfordert ein Umdenken bezüglich der organisatorischen und technischen Abläufe in ei-nem 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ätsmanagementme-thoden eingesetzt, die auf einzelne wertschöpfende Prozesse und Prozess-ketten anwendbar sind. Andererseits kommen Methoden zur globalen In-tegration von Kompetenzen, Informationen und Ressourcen im ganzen Unternehmen zum Einsatz. Dabei werden Verfahren zur Verfügung ge-stellt, die den Anwender während eines Produktentwicklungsprojektes durch eine kontextsensitive Auswahl und Anpassung von Methoden unter-stützen, indem Expertenwissen breit verfügbar gemacht wird. Besonders in der Prototypenfertigung müssen jedoch neue Ansätze und Techniken imp-lementiert werden, um den Anforderungen an die hohe Qualität in kleinen Stückzahlen gerecht zu werden. Nur so können aussagekräftige Informati-onen über die spätere Produktqualität gewonnen werden. Zum Erreichen dieser Ziele werden durch die Bereitstellung geeigneter Methoden Instru-mente 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 unterschied-lichster Technologien unterstützt, als auch die informationstechnischen, methodischen und organisatorischen Aspekte beachtet [3.30]. Deshalb um-fassen die Forschungsthemen im Bereich des Qualitätsmanagements spe-ziell die folgenden Bereiche:


Prognose der Produktqualität in frühen Phasen (z. B. auf Basis erster vager Markmaldefinitionen) Absicherung und Optimierung der Entwicklungsqualität durch wissens-basierte Systeme Methodische und technische Unterstützung von Qualitätsprüfungen (z. B. Informationsextraktion aus der zerstörungsfreien 3D Prüfung) Grundlagen für Richtlinien im Rapid Prototyping (Prüfverfahren, Prüf-planung, Prototypen-Reviews und Audits)

Ein umfassendes Qualitätsmanagementkonzept ist notwendig, um zu ei-nem effizienten, flexiblen und unternehmensangepassten Produktentwick-lungsprozess zu gelangen. Mit dem Einsatz von Verfahren des Rapid Pro-totyping 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ätsmanage-ment-Toolbox ein Werkzeug entwickelt, das den Unternehmen als Hilfs-mittel 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 Leistungspo-tenzial 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 Ra-pid Prototyping Verfahren aufzuzeigen. Dadurch können das Verständnis und die Kommunikation zwischen unterschiedlichen Teilphasen und Be-reichen im Produktentwicklungsprozess optimiert und zielgerichtet die Anwendung und Nutzung der Verfahren durch entsprechende Handlungs-


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

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 so-wie 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 Pro-dukte hohe Ansprüche hinsichtlich Qualität und technischen Standard bei gleichzeitig immer stärkerer Individualisierung gestellt werden. Im Wett-bewerb rücken deshalb zusätzliche, vom Design geschaffene Differenzie-rungsmerkmale 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 unternehmens-strategisches Heraushebungs- und Alleinstellungsmerkmal.

Qualitätsmerkmale beim Aufbau virtueller Designmodelle

Die frühen Produktentwicklungsphasen liefern erste Entwürfe in Design-modellen und konzeptionellen Prototypen, die Varianten in Form und Funktion repräsentieren und deren Herstellung bisher fast nur per Handar-beit erfolgt. Diese Modelle repräsentieren zunächst nicht vollständig aus-detaillierte, unscharfe Produktdaten, die ein Festlegen und Verifizieren von Qualitätsmerkmalen im klassischen Sinn einer CAD-Modelliermethode (vollständige, skalierte Produktdaten) nicht ermöglichen. Eine Einbezie-hung in die RPD-Prozesskette erfordert deshalb Methoden zur Abstraktion und Quantifizierung von Qualitätsaussagen. Diese basieren auf Modellier-strategien zum Aufbau Rapid-Prototyping-fähiger virtueller Designmodel-le. Mit der Einbindung der frühen Entwurfsphasen in die Rapid-Product-


Development-Prozesskette soll einerseits der Designer die Möglichkeit er-halten, Werkzeuge aus den vielfältigen Rapid Prototyping Verfahren nut-zen 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 Model-lierung klassischer und konventioneller Designmittel wie Skizze, Ent-wurfspläne oder handgefertigtes Formmodell. Für die Abstraktion und De-finition relevanter Modelleigenschaften für die Simulation geometrischer, physikalischer oder funktionaler Eigenschaften am physischen Prototypen (z. B. metallisches funktionelles Beschichten) und / oder virtuellen Proto-typen (z. B. Strömungssimulation) müssen dazu die virtuellen Interpretati-onen der Entwurfsmodelle und / oder des konzeptionellen Prototypen auf-bereitet werden. Dabei muss ermöglicht werden, aus mit geeigneter Sensorik erfassten unscharfen Produktdaten und somit, im Hinblick auf CAD-Modelle, unvollständigen Entwurfsmodellen, Rapid-Prototyping-fähige virtuelle Modelle zu erzeugen.

Für die Methoden zur Qualitätssicherung, die die Besonderheiten von Entwurfsmodellen und konzeptionellen Prototypen berücksichtigen, wur-den die aus digitalisierten Designmodellen aufgebauten CAD-gerechten Modellstrukturen genutzt. Diese eignen sich für das Erfassen von Model-len 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 Licht-kanten auf Designmodellen voraus. Die Idee geht auf Aussagen von De-


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ätzli-che 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 be-einflussen, 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 Parame-ter, die diese signifikant beeinflussen sowie über potenzielle Risiken der Entwicklung schwer zu treffen sind. Die hohe Dynamik und die komple-xen Iterationszyklen in Entwicklungsnetzwerken erschweren solche Prog-nosen noch zusätzlich [3.6]. Deshalb wird ein Bewertungsmodell zur Ver-fü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 erken-nen, damit rechtzeitig entgegengesteuert werden kann. Dabei ist es not-wendig, 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ätsbeeinflussen-den Randbedingungen und Elementarprozessen des Rapid Prototyping dar.


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üs-se von entwicklungsrelevanten Aktivitäten wie z. B. Prototypherstellung und Prozessbeherrschung auf die Produktqualität modellieren. Der Zu-sammenführung der Erkenntnisse aus verschiedenen Bereichen kam dabei eine zentrale Bedeutung zu. Auf der obersten Ebene des hierarchisch struk-turierten Modells wurden zunächst vier Wissensklassen modelliert, die alle einen direkten Einfluss auf die Qualität des Endprodukts haben (Abb. 3.27.):

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 aktuel-len Entwicklung, welche auch auf Informationen der Vergangenheit basie-


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 gegebe-nenfalls 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 Ex-pertenbefragungen erworbenes Wissen, das in mehreren Iterationen suk-zessive optimiert wurde, im Modell abgebildet. Auf einer zweiten Hierar-chieebene wurden die vier oben genannten Einflussklassen verfeinert. So ist beispielsweise in Abb. 3.28 das Modell der Klasse Prognosefähigkeitdes 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 Erfah-rung, die man bisher mit dieser Art von Prototyp gesammelt hat (PT-Erprobung), und andererseits von der Aussagefähigkeit des Prototypen ab. Die Aussagefähigkeit wiederum hängt auf der einen Seite von den charak-teristischen Eigenschaften des Prototypen wie Oberflächengüte, Belastbar-keit usw. ab, die ihrerseits durch die Wahl der Materialien und Herstellver-fahren beeinflusst werden. Auf der anderen Seite fließen Prozessfähig-


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 Bewer-tungsmodells wurden auf analoge Weise modelliert. Das Modell kann an beliebiger Stelle verfeinert werden, indem weitere Hierarchieebenen hin-zugefügt werden. Das so konstruierte qualitative Modell wurde mit Hilfe von Wahrscheinlichkeiten quantifiziert, die den im obigen Teilmodell dar-gestellten Knoten, die im wahrscheinlichkeitstheoretischen Sinne Zufalls-variablen 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 Informationsge-halt 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, zu-nä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 wer-den 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 mehrdimensio-nalen 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 erwar-tenden Herstellkosten sowie die geschätzte Zeit bis hin zur Serienreife pro-gnostiziert, 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 Hil-fe 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. Zufalls-variablen 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 Ab-schätzung der Wahrscheinlichkeitswerte durch den Experten als auch für


die oben angesprochenen Lernalgorithmen ein wichtiges Effizienzkriteri-um. In unserem Modell wurden deshalb die Anzahlen der Zustände meis-tens zwischen zwei und maximal fünf gewählt. Nur wenige Variablen bil-den 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 be-schreibt 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 Develop-ment 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 Pro-duktentwicklung und die Modularisierung des Entwicklungsprozesses füh-ren 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ön-nen 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 be-reits in den frühen Phasen die funktionellen Zusammenhänge und Quali-tätsmerkmale erkannt und potenzielle Fehlerquellen reduziert werden.

In diesem Teilprojekt wurden die physischen Prototypen und die zuge-hörigen Prozesse und Methoden untersucht, um mit den RP-Verfahren nicht nur die einzelnen Prototypen zu bauen, sondern auch Qualitätskrite-rien für neue komplexe Produkte zu untersuchen. Die komponentenbasier-te integrative Bauweise bietet zwar eine hohe Flexibilität, birgt aber die Gefahr einer schwer zu handhabenden kombinatorischen Vielfalt. Die Ra-


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 Konzepti-on 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 verbes-serte Produkteigenschaften, kontrollierte Änderungen der Geometrien und Funktionserweiterung erreicht werden. Darüber hinaus wurden Ansätze aus der Analogie- sowie Strukturierungsmethodik untersucht und Quali-tätsmodelle in den frühen Produktentwicklungsphasen entwickelt. Ab-schließend wird noch eine Implementierung dieser wissensbasierten Me-thodik zur Vermeidung und Reduktion der Komplexität für die hier betrachteten Szenarien entwickelt und als ein Baustein in der Qualitäts-toolbox 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 Methoden-ausführung an die problem- und unternehmensspezifischen Randbedin-gungen. 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 fle-xible und bedarfsorientierte Methodenanwendung bei den Aktivitäten wäh-rend der Produktentwicklung gerecht zu werden.

Die kontextsensitive Methodenauswahl ist im Wesentlichen ein Ent-scheidungsproblem mit endlich vielen Entscheidungsalternativen, das von gewissen Randbedingungen, deren Gesamtheit den Kontext bildet, beein-flusst 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 he-ranzuziehen, da diese die obigen Anforderungen erfüllen [3.40].

Zu den wichtigsten Eigenschaften dieser Einflussdiagramme gehört un-ter anderen, dass sich das unsichere Wissen im Produktentwicklungspro-zess z. B. bezüglich der nicht vollständig spezifizierten Randbedingungen


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 Kno-ten die Variablen – in dieser Anwendung z. B. Randbedingungen, Eig-nungskriterien o. ä. – darstellen und die Kanten die Existenz direkter kau-saler Zusammenhänge denotieren (Abb. 3.29.). Hierbei wird die Stärke dieser Abhängigkeiten auf Basis bedingter Wahrscheinlichkeiten angege-ben und Knoten ohne Einflüsse werden durch a-priori-Wahrscheinlich-keiten quantifiziert. Das in Abb. 3.29 (a) angegebene Beispiel für ein Bay-es’sches Netz spiegelt folgenden Sachverhalt wider: Für die Methodenauswahl werden Eignungskriterien wie Zielführung, Aufwand-Nutzen-Verhältnis o. ä. herangezogen, d. h., die Eignung der Methoden wird anhand bestimmter Kriterien bewertet. Die Wahl der Methode hat ei-nen Einfluss auf die Bewertungskriterien, was im Abb. 3.29 (a) durch die beiden Kausalpfeile dargestellt ist. Ferner hängen die Kriterien von kon-textspezifischen Randbedingungen im RPD wie z. B. dem Innovationsgrad der Entwicklung ab. Diese Kausalität ist im Beispiel, das nur einen Aus-schnitt des gesamten Netzes darstellt, ebenfalls durch einen Pfeil repräsen-tiert.

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 Entschei-dungsknoten repräsentieren alle Alternativen einer bestimmten Entschei-


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 Ent-scheidungen und werden von den Entscheidungsknoten zumindest indirekt beeinflusst. Ein Nutzenknoten kann dabei nur Vorgänger und keine Nach-folger besitzen [3.55].

In unserer Anwendung soll eine Entscheidung bezüglich der zu wählen-den Methode getroffen werden. Im Beispiel aus Abb. 3.29 (a) werden wir deshalb den Zufallsknoten Methode in einen Entscheidungsknoten um-wandeln, 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 so-wohl 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 Me-thode unter Berücksichtigung der prototypenspezifischen Randbedingun-gen beurteilen lässt. Entscheidendes Kriterium für die Bewertung der al-ternativen 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 eben-falls besonderes Augenmerk gelegt werden. Die drei übrigen Kriterien Flexibilität, Integrierbarkeit und Universalität spielen eine ergänzende Rol-le, 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 ei-nen Prototyp, der – je nach dem, welche Merkmale an ihm verifiziert wer-den sollen – bestimmte, geforderte Eigenschaften aufweisen soll. Wichtig für die Auswahl ist immer der Kontext, das heißt, es müssen einerseits ge-nerell relevante Randbedingungen wie Produktkomplexität, Kostenrestrik-tionen, Zeitrestriktionen usw. sowie andererseits situationsspezifische Randbedingungen wie mechanische Eigenschaften, thermische Eigen-schaften, elektrische Eigenschaften und optische Eigenschaften des ausge-härteten Harzes des Prototypen spezifiziert werden. Ein Ausschnitt des


entwickelten Einflussdiagramms für die kontextsensitive Methodenaus-wahl 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 einer-seits mit Hilfe des vorhandenen a-priori-Wissens wie z. B. funktionale Zu-sammenhänge zwischen den Knoten und andererseits durch Erfahrungs-wissen von Experten aus den jeweiligen Problembereichen bewerkstelligt.

Der Einsatz Bayes’scher Netze zur Methodenauswahl hat gegenüber be-kannten Ansätzen deutliche Vorteile. Er erlaubt es, die komplexen Interde-pendenzen 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ähig-keit der Wahrscheinlichkeitstabellen (Parameter Learning) [3.33], [3.54] durch bereits aufgetretene Entscheidungssituationen von erheblicher Be-deutung. 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-


dik wurde auch als Grundlage für das Entscheidungs-Modul in der Quali-tä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 heteroge-nen Datenbeständen in der schnellen Produktentwicklung als ein wesentli-cher 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üfergebnis-se ähnlicher Merkmale Kennwerte ermittelt, die Vorhersagen auf die zu erwartende Qualität des Prozesses zulassen. Dafür muss eine Ähnlichkeits-relation 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 Kenn-wertermittlung notwendigen Merkmale und Prüfergebnisse aus einer Da-tenbank 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-


sondere Geometriemerkmale betrachtet werden. Folgende Parameter erge-ben sich hierbei als relevant:

Werkstoff – der Materialschwund gilt im Allgemeinen als Hauptursache für den Bauteilverzug Bauteilgröße – die Maßabweichung steigt mit zunehmender Bauteilgrö-ße an Hatchabstand – der Hatchabstand beeinflusst die Bauteilschrumpfung Resolution – je höher die Resolution, desto geringer ist die Verzerrung und die dadurch entstehende Ungenauigkeit Schichtdicke – die Schichtdicke beeinflusst die Genauigkeit in Richtung der z-Achse erheblich

Um Kennzahlen zur Messung der Fähigkeit des Stereolithografieprozes-ses 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 Herstell-prozesses 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 Merkmals-klasse zugeordnet

SollwertToleranz:ToleranzNormierte

(1)

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

n

1i i

sollii

D t|xx|

n1:A

(2)

i

sollii

n,...,1iM t|xx|max:A

(3)

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-


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 folgen-dermaßen ab: zunächst werden die Forderungen an den zu fertigenden Pro-totyp 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 meh-rere Teile in der Teiledatenbank zurückgegriffen werden. Das Fähigkeits-modul entscheidet aufgrund der Merkmalsart, welche Kennwerte zur Vor-hersage 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 Forde-rungen transformiert.

Simulation von Prototypenherstellprozessen

Kerngedanke der Simulation ist die Möglichkeit der qualitativen Bewer-tung eines RP-Prozesses und des damit hergestellten Prototypen. Dabei wird die Qualität des Prototypen immer als Grad der Erfüllung der spezifi-zierten Anforderungen verstanden. Die korrekte Übersetzung der Kun-


denwünsche in technische Anforderungen an ein Produkt und an die Mus-ter innerhalb des Entwicklungsprozesses entscheidet über die Produkt-qualität.

Nicht nur die richtige Auswahl des RP-Verfahrens, sondern auch die Wahl geeigneter Werkstoffe sowie Einstell- und Umgebungsparametersind für den zu erstellenden Prototypen wichtig. Dadurch werden ver-schiedene Eigenschaften des zukünftigen Produktes festgelegt. Diese Ent-scheidungen werden heutzutage vom Menschen in der Regel vom Ent-wickler (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 qualitati-ven 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 Proto-typing unterstützt. Der Entwickler wird somit im Iterationsprozess entlas-tet, 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)


Durch das Modell wird die Entwicklung der RP-Prototypen effizienter gestaltet, die Anzahl der Zyklen verringert und damit der gesamte Ent-wicklungsprozess beschleunigt. Dies bedeutet eine Verbesserung des RP-Prozesses. 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 herange-zogen werden. Weiterhin ist es in der Lage, sich neuen und unbekannten Parametern (Umgebung, Material, Produkt) anzupassen. Als Versuchs- und Modellanlage diente das sogenannte „Multi Material Modelling“-Verfahren (MMM).

Das stochastische Simulationsmodell stellt ein nahezu wirklichkeitsge-treues Abbild des realen MMM-Prozesses dar. Mit Hilfe von Expertenwis-sen ü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 Ge-samtmodells 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 opti-mieren und andererseits das Modell sukzessive zu verbessern. Das Simula-tionsmodell 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 Mus-terherstellung 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 Ge-samtkonzept, durch dessen Einführung und Umsetzung Insellösungen und isolierte Methoden vermieden werden. Wesentliche Elemente dieses Ge-samtkonzeptes sind flexible und bereichsübergreifende Strukturen, aufga-benü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:


Produktmerkmale und Prototypenklassen, Prozesse und Prozessketten der Prototypenherstellung, Prüfplanung, Prototypenprüfung und Review

sowie ein Modul zur Entscheidungsunterstützung bei der Auswahl von ge-eigneten Prototypen bzw. Prototypenherstellverfahren. Zur Entscheidungs-findung wurden hier einerseits Informationen aus den technischen Berei-chen 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 Pro-totypenherstellung 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 unterschied-lichen Produktentwicklungsphasen in der Toolbox zur Verfügung gestellt.

Das Modell besitzt schon anfangs eine eindeutige Produktklassenzuord-nung, es existieren einzelne Stufen bzw. Module, die einen unterschiedli-chen Detaillierungsgrad haben können und der Ablauf ist gut visualisierbar und somit gut nachvollziehbar. Es ermöglicht außerdem eine ausführliche


Definition der Kundeninformationen und ist für unterschiedliche Aus-gangssituationen nutzbar, wobei es optimal für die Situation der vorhande-nen 3D-Daten geeignet ist. Es ist für den Umgang mit unsicherem bzw. ungenauem Wissen bei Verwendung einer entsprechenden Methode an-wendbar. 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 entwi-ckelt. Nach dem Sammeln der benötigten Informationen und Produkt-merkmale wird das Bauteil in der ersten Entscheidungsebene einer Pro-duktklasse zugeordnet. Hierzu werden sogenannte Klassierungskriterien verwendet. Es wurden fünf Produktklassen erarbeitet: Konzeptmodell, Ge-ometriemodell 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 Pro-duktklasse 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 Material-eigenschaften, zu der Umgebungsanbindung, der Qualität und der Wirt-schaftlichkeit. Bei jedem dieser Punkte kann gewählt werden, ob detaillier-te Angaben dazu gemacht werden wollen, wodurch man zu weiteren Abfragen gelangt, oder ob man eine pauschale Bewertung abgeben möch-te. 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 Entscheidungs-modell 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 Kri-terien, zu denen quantitative und qualitative Angaben gemacht werden können. Falls keine genauen Werte vorliegen, können Wertigkeiten ange-geben werden. Interessant wäre auch eine Implementierung der Möglich-keit Wertebereiche einzugeben. Die Daten, die durch diesen Vorgang erar-beitet wurden, werden in einem Wissenspool gespeichert. In diesem Pool ist außerdem das gelernte Wissen des Systems aus vorigen Anwendungs-


fällen abgespeichert, wobei hierzu eine Bewertung der getroffenen Ent-scheidung notwendig ist. Zudem dient dem Wissenspool ein Startwissen als Basis, das über den Systemadministrator eingelernt wird. Das so ge-sammelte Wissen muss nun noch richtig kombiniert und analysiert werden, um das richtige generative Fertigungsverfahren auszuwählen. Diese Auf-gabe übernimmt eine Entscheidungsmethodik, die auf Grund der erarbeite-ten 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üh-ren, falls inzwischen genauere Daten zur Verfügung stehen.

Modul: Prozesse und Prozessketten der Prototypenherstellung

Durch zahlreiche Neu- und Weiterentwicklungen im Bereich der generati-ven Fertigungsverfahren sowie durch die verschiedenen Kombinations-möglichkeiten mit Folgetechnologien und einer immer größer werdenden Materialvielfalt ist die Gesamtheit der Herstellmöglichkeiten von Prototy-pen nur noch schwer überschaubar. Bei der Auswahl eines Verfahrens zur Prototypenfertigung kommen daher meist nur die technologischen Mög-lichkeiten der Prozesse, der einsetzbare Werkstoff sowie der Einsatzzweck des Prototypen als Auswahlkriterien zum Tragen. Für die Fertigung kom-plexer und eventuell mehrteiliger Prototypen bedarf es jedoch auch einer Fertigungsterminierung sowie einer Verträglichkeitsprüfung von Werk-stoffen und Fertigungsverfahren hinsichtlich der Prototypmontage. Metho-den und Instrumentarien zur ablauf- und prozesstechnischen Planung einer qualitativ, zeitlich und wirtschaftlich optimalen Fertigungsfolge. Hier sind auch Folgen von mehreren Einzelprototypen unter Beachtung der Potenzi-ale sowohl generativer als auch klassischer Fertigungsverfahren zu beach-ten und im Bezug auf die Dienstleisterintegration zu definieren.

Diese Sammlung ist trotz der Vielzahl von Kriterien jederzeit erweiter-bar 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än-den eine grundlegende Überprüfung der Vollständigkeit der Sammlung stattfinden.

Darüber hinaus besteht dieses Modul aus einer Abfrage über Produkt-merkmale, welche eine eindeutige Zuordnung zu einer der oben genannten Produktklassen zulässt. Anschließend werden für die entsprechende Pro-duktklasse weitere Abfragen vorgenommen, die der Präzisierung der Pro-duktbeschreibung dient. Diese Abfragen enthalten sowohl die Möglichkeit


genaue als auch ungenaue Angaben zu machen. Anschließend werden die-se Informationen einem Wissenspool zugeführt, welcher schon anderes Wissen enthält. Dies kann Wissen von Experten oder aber auch, falls mög-lich, Wissen des Systems beinhalten (gelerntes Wissen). Abschließend ent-scheidet eine Interferenzkomponente, welches Verfahren als bestes vorge-schlagen wird. Diese Interferenzkomponente stellt eine Entscheidungs-methodik, die auf Grund der Ausprägungen in den Informationen ein Verfahren vorschlägt, dar. Anschließen lässt sich eventuell noch eine ge-nauere, aufwendigere Kostenrechnung als zuvor.

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


Modul: Prüfplanung, Prototypenprüfung und Reviews

Die Prototypenprüfung unterliegt zahlreichen Einflussfaktoren. Nur durch die Gestaltung, Planung und Beherrschung dieser Faktoren sind die not-wendigen Informationen extrahierbar und weiterverwendbar. Weil nach verwendetem Verfahren und Prozessparametern so Bauteile mit mögli-cherweise 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 Anforde-rungen 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 orien-tiert sich an der Eignung für den bestimmten Einsatzfall und damit an der Erfüllung der jeweils spezifischen Anforderungen. Da mit einem Prototy-pen in der Regel nur eine begrenzte Anzahl an Merkmalen evaluiert wer-den sollen, sind diese bei der Auslegung und der Bestellung exakt zu defi-nieren. Eine unklare Definition oder Absprache kann zu erheblichem Mehraufwand (Kosten, Lieferzeit) und/oder zu mangelhafter Qualität füh-ren. 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 Effizienzsteige-rungen 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üfmerk-malen 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 Produkt-entwicklungsprozess mehr ableitbar ist. In beiden Fällen müssen Maßnah-men 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.


Im Rahmen des Review steht dieses Wissen in Form des Prüfindex zur Verfügung. Dieser stellt die zeitlichen und logischen Abhängigkeiten die-ser Merkmale sowie die Verknüpfung der Entwicklungsergebnisse (Pro-dukt/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-how-Bildung (z. B. Prüfindex). Als Basis für die Generierung von Steuerungs-informationen durch das Review wird die Analyse des Erkenntnispotenzi-als eines Prototypen genutzt. Da das Erkenntnispotenzial von Prototypen situationsabhängig ist, setzt das Review ereignisgesteuerte Beurteilungsak-tivitäten voraus. Zeitgesteuerte Bewertungen, z. B. im Rahmen von perio-dischem Prototyping, können diese ergänzen, jedoch können sie Monito-ring-Funktionen bei der Ereignisüberwachung keineswegs ersetzen.

Das Ziel des Prototypenaudits ist es, Erfahrungswissen über die Anwen-dung und Umsetzung verschiedener Qualitätsmanagementmaßnahmen in der Praxis nutzbar zu machen und das aus diesen Maßnahmen hervorge-


gangene Wissen zu systematisieren und zur Vorbeugung nutzbar zu ma-chen. Da neben der Generierung neuen Wissens auch die Bewährung die-ses Wissens in der Praxis erforderlich ist, beinhaltet das Prototypenaudit – neben der Ermittlung und Anregung von Verbesserungen und der Fehler-behebung – 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 Produkt-entwicklung 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 Er-gebnis zu kommen. Hierzu war es allerdings notwendig, die richtige Ent-scheidungsmethode 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 re-levanter 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 Mittelkonso-lenkomponenten konstruiert. Anschließend wurden die Ergebnisse dieser Überprüfungen dokumentiert.


Die Methoden des Rapid Product Development dienen zur zielgerichteten frühzeitigen und effektiven Umsetzung von Prozessen und Vorgehenswei-sen, 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 La-bor aufgebaut, das die verschiedenen Technologien zur Erstellung physi-scher Prototypen im Prozessmodell integriert, das anderseits Methoden in einer Toolbox erfasst, die Interaktionen zwischen den einzelnen Technolo-


gien und Prozessen unterstützt. Aus dem Prozessmodell ergaben sich die variablen und die nicht variablen Schnittstellen für den Ansatz des evoluti-onä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 verbin-den.

Die in der bisherigen Forschung gemachten Untersuchungen haben ge-zeigt, 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 Produktentwicklungs-prozesses 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 phy-sischen Produktes und der begleitenden Dienstleistungen (Leistungsbün-del) determiniert. Um für ein Leistungsbündel die Kosten, die während des gesamten Lebenszyklus entstehen zielorientiert planen, steuern und kon-trollieren 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 Sonderforschungsberei-ches (insb. mit der DaimlerChrysler AG) aber auch empirische Studien bestätigen die Bedeutung eines entwicklungsbegleitenden Kostenmanage-ments für den langfristigen Unternehmenserfolg. Vor Beginn der letzten Antragssituation existierten noch keine überzeugenden Konzepte, die auf eine Integration der prototypgestützten Kostengestaltung von Leistungs-bündeln aus physischem Produkt und Dienstleistung sowie der lebenszyk-lusoptimierten Kostengestaltung von Rapid Product Development-Netzwerken ausgerichtet waren.

Das Ziel dieser Arbeiten besteht in der Entwicklung von Konzepten, wie im Rahmen des Rapid Product Development (RPD) prototypgestützte Pro-duktvorgaben und -prognosen für Leistungsbündel aus physischem Pro-dukt und Dienstleistungen sowie unter Betrachtung von Entwicklungs-

3.4 Kostenmanagement im Prozess des Rapid Prototyping 185

netzwerken lebenszyklusorientiert geplant, gesteuert und kontrolliert wer-den können. Ziel der Forschungsaktivitäten ist es, eine Basis für die kos-tenorientierte, lebenszyklusoptimierte Steuerung der Produktentwicklung zu legen. Das Rapid Product Development ist dabei ein wesentliches In-strument zur Erhöhung der Effizienz und Effektivität im Rahmen der Neu-produktentwicklung. Prototypen haben sich bisher als sehr gutes Instru-ment zur lebenszyklusorientierten Kostenprognose gezeigt. Unter einem solchen Prototypen kann dabei eine jede Vorabversion des späteren Leis-tungsbündels (bestehend aus physischem Produkt und Dienstleistung) an-gesehen werden, die wenigstens einige Eigenschaften dieses Leistungs-bündels aufweist. Die bisherigen Forschungsergebnisse konnten belegen, dass physische und virtuelle Prototypen geeignet sind, die Defizite bei der Generierung und Verarbeitung kostenrelevanter Informationen zu reduzie-ren.

3.4.2 Ergebnisse und ihre Bedeutung

Ziele

Ein wesentliches Ziel der Arbeiten war die Übertragung der Forschungser-gebnisse 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 Entwick-lungsprozesses angestrebt. Zur Erreichung dieses Ergebnisses wurden ei-nige Teilziele verfolgt. So wurde ein Prozesskostenmodell für ein Ent-wicklungsnetzwerk 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 Netzwerk-

1 Zur Wahrung der Vertraulichkeit wurde der Name des Praxispartners adaptiert.


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

Phase 1: Analyse der Ist-Situation bei der TOOLING GmbH & Co.

(1) Prozessorientierte Analyse des Entwicklungsnetzwerkes

Innerhalb der vernetzten Produktentwicklung existieren bei der TOOLING GmbH & Co. eine enorme Bandbreite unterschiedlicher Prozesse. Auf-grund der Vielfalt und Verschiedenartigkeit von Entwicklungsprozessen wird deren Charakterisierung und Typologisierung notwendig. Eine Cha-rakterisierung 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 Produkti-on sind Entwicklungsvorhaben mit einem gewissen Neuigkeitsgrad ver-bunden und haben im Allgemeinen Projektcharakter [3.71]. Neuigkeit be-deutet 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äu-figkeit, 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 Unter-nehmen führen zu Komplexität. Allgemein kann Komplexität als eine Kombination aus der Anzahl der Aufgabenelemente und deren Verknüp-fung untereinander definiert werden [3.63]. Unter Variabilität wird das Ausmaß von Prozessänderungen hinsichtlich Häufigkeit, Intensität, Irregu-larität und Geschwindigkeit verstanden [3.66]. Modifikationen im Ent-wicklungsprozess 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 Entwicklungsvor-habens. 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-


schwierigkeiten zu erwarten. Dadurch wächst die Gefahr von unnötiger Doppelarbeit, Motivationsbarrieren und einer Unverwendbarkeit der Er-gebnisse.

(2) Identifikation und Charakterisierung der Leistungsbündel

Ausgehend von den speziellen Gegebenheiten bei der TOOLING GmbH & Co. wurden in diesem Arbeitspaket Produkte und produktbegleitendeDienstleistungen identifiziert. Dabei boten sich diverse Möglichkeiten zur Festlegung von Leistungsbündeln. Kombinationen aus Produkt und pro-duktbegleitender Dienstleistung ließen sich so bei Positions- und Sicher-heitsschalter gleichermaßen feststellen. Die Identifikation der Leistungs-bündel führte für die vorliegende Untersuchung, aufgrund der großen praktischen Bedeutung, zu einem Leistungsbündel von Zustimmungsschal-ter und Engineering-Dienstleistung („Web-to-CAD-Service“). Diese Engi-neeringdienstleistung wurde dabei ausgewählt, da bei dieser ein hohes Wachstumspotenzial existierte und bei der Erstellung zahlreiche Prototy-pen eingesetzt werden. Gleichzeitig bestand zu den begleitenden Zustim-mungsschaltern 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 Dienstleistungzum physischen Produkt ist das wesentliche, notwendige Merkmal der be-trachteten, 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 ho-hen, direkten Verbindung vom Produkt bzw. Produktmodell zur begleiten-den Dienstleistung. Im Rahmen des Forschungsprojektes erfolgte eine wei-tere 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 Kos-ten- 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


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 Ad-ressat 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 ex-ternen Faktors wiesen Leistungsbündel häufig einen hohen Individualisie-rungsgrad auf. Im Vergleich zu physischen Produkten existierte weiterhin oft eine geringere Standardisierung bei produktbegleitenden Dienstleistun-gen, die mit einer Erschwerung der Planung einhergeht [3.58]. So ist ex-emplarisch eine Identifikation von standardisierten Prozessen schwerer möglich, was wiederum Auswirkungen auf eine prototypgestützte, pro-zessorientierte Kosten- und Erlösplanung von produktbegleitenden Dienst-leistungen hat [3.75]. Für die praktische Realisierung der Kosten- und Er-lösplanung hat sich weiterhin eine Differenzierung der produktbeglei-tenden Dienstleistung hinsichtlich ihrer Stellung im Produktlebenszyklusals Einflussfaktor gezeigt. Je nachdem, ob die betrachtete Dienstleistung stärker auf die Entwicklungs-, Produktions- oder Nachsorgephase zielt, re-sultieren Auswirkungen auf die Möglichkeit zur Nutzung des Prototypen. Zur weiteren Charakterisierung der Leistungsbündel erfolgte weiterhin ei-ne Typologisierung nach Eigenschaften des Produktes bzw. des Prototypen nach Funktion, Substanz, Konkretisierung und Erstellung des Prototyps.

Die Prototypfunktionen werden in den verschiedenen Wissenschafts-zweigen 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 Fo-kus der Arbeit standen [3.49], [3.69]. Aus der Perspektive einer prototyp-gestützten Kosten- und Erlösplanung für produktbegleitende Dienstleis-tungen 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 die-sen unterschiedlichen Substanzen resultierten wiederum virtuelle und phy-sische Prototypen. Bei der Charakterisierung von Prototypen nach der Konkretisierung erfolgte eine Differenzierung nach dem wahrnehmbaren Stadium im Produktentwicklungszyklus. Dabei wird von zahlreichen Au-toren in zeitlicher Reihenfolge in Design-, geometrischen, Funktions- und technischen Prototyp unterschieden [3.46], [3.39], [3.31], [3.18].


Erk

ennt

nist

heor

etis

che

Funk

tion

Psychologische Perspektive

Ingenieurwissen-schaftlichePerspektive

Betriebswirtschaft-liche Perspektive

Hacker & Sachse

Herzog VDI Bullinger et al.

Specht et al.

Vorlie-gende Arbeit

Inter-pretati-on

Reprä-senta-tion

Selekti-on

Heuris-tischeFunkti-on

Analyse-hilfe

Evaluati-onshilfe

Lösungs-hilfe

Spei-cherhilfe

Kommu-nikations-hilfe

Doku-mentati-ons-hilfe

Illustra-tion

Problem-definiton

Lösungs-findung

Lösungs-beschrei-bung

Lösungs-beurteilung

Lösungs-auswahl

Unterstüt-zung bei der ErbarbeitungalternativerKonzepte

Unterstüt-zung einer späten Ent-scheidungund Spezifi-kation des Produktes

Unterstüt-zung bei der Pla-nung und Steuerung

Informationund Kom-munikation

Einbindungvon Anfor-derungendes Kun-den und Lieferanten

Analyse

Gestal-tung/Ent-schei-dung

Doku-menta-tion

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 Ergebnis-se 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]. Hin-sichtlich 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 Prozess-merkmalen, wurde ein Prozessmodell für das vorliegende Entwicklungs-


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 erfolg-te 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 Ideenge-nerierung innerhalb der operativen Produktplanung wird nicht näher ein-gegangen. Die Betrachtung der Produktplanung kann jedoch nicht voll-ständig unterbleiben, weil die Phasen der Anforderungsdefinition und Produktkonzeption eher planenden Charakter aufweisen. Aus diesem Grund existieren Überschneidungen zu den beiden Planungsphasen. Das-selbe gilt auch für den gesamten Prozess der Produktentwicklung, bei dem es vielfach zu Überlappungen, Rückkopplungsschleifen und Verzweigun-gen kommt [3.77]. Während die Phasen die abzuarbeitenden Arbeitspakete beschreiben, liegen an ihren Schnittstellen sogenannte Meilensteine bezie-hungsweise Design Reviews [3.12], [3.52]. Sie fungieren als Kontroll-punkte für die Einhaltung der Ziele von Entwicklungsprozessen. Aufbau-end auf den ersten und dritten Arbeitspaketen wird im fünften Arbeitspaket auf die Erfassung und Klassifizierung von Interdependenzen in Netzwer-ken eingegangen.

(4) Prototypgestützte, prozessorientierte Klassifikation der Leistungsbündel

Auf der Basis der Identifikation und Charakterisierung der Leistungs-bü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 doku-mentieren 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ätz-liche Untergliederung, mit der die Potenziale von Prototypen zur Pla-nungsunterstü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 Prototyp-unterstützung aufgezeigt [3.64]. Prozesse ersten Grades wiesen dabei eine direkte Verbindung zum physischen Produkt auf. Eine Veränderung am


physischen Produkt hatte so unmittelbare Auswirkungen auf die Potenzia-le, den Prozess und das Ergebnis. Ein indirekter Bezug zum physischen Produkt bzw. zu Prototypen dieses Produktes ließ sich bei Prozessen zwei-ten Grades herstellen. Bei diesen Services resultierte nur eine mittelbare Reaktion auf die Veränderung des Prototyps. Prozesse dritten Grades um-fassten schließlich Aktivitäten, die keine oder nur eine sehr lose Verbin-dung zum physischen Produkt haben (z. B. Geschäftsbereich leiten). Die Analogie dieser Unterscheidung zu lmi (für die Prozesse ersten und zwei-ten Grades) und lmn (dritten Grades) ist offensichtlich. Allerdings steht bei dieser Differenzierung nicht die Mengeninduktion, sondern allein die Ver-bindung zum physischen Produkt im Fokus.

Durch den Prototypbezug der Teilprozesse konnte ebenfalls eine Bezie-hung zum physischen Produkt hergestellt werden. Als Ergebnis dieses Ar-beitspaketes konnte damit eine prototypgestützte, geschlossene Systematik von physischem Produkt und begleitenden Dienstleistungen erreicht wer-den. Dieses beruhte dabei auf den Charakterisierungen, die bereits im Ar-beitspaket 2 bestimmt werden konnte.

(5) Erfassung und Bewertung der Interdependenzen

Grundsätzlich führen Leistungs- und Ressourcenverflechtungen in Netz-werken zu Interdependenzen und Entscheidungsproblemen. Bei der Erar-beitung des oben beschriebenen Prozessmodells hat sich herauskristalli-siert, 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 Koordinationskos-ten spielt dabei eine wichtige Rolle, weil vielfach hohe wechselseitige Ab-hängigkeiten zwischen den Partnern existieren. Aus diesem Grund wird im Folgenden eine Fokussierung auf die Analyse von Koordinationsgestal-tungsfeldern vorgenommen, die für eine spätere Abschätzung von Kosten-effekten in Netzwerken zwingend erforderlich ist.

Organisatorische Koordinationsgestaltungsfelder der Aufbauorganisa-tion. Im Rahmen der realisierten Ausprägung von Zentralisation bzw. Dezentralisation des Netzwerkes besteht ein wesentliches Gestaltungs-feld in der Abstimmung der dezentralen Einheiten im Hinblick auf das gemeinsame Entwicklungsziel des Netzwerkes. Dabei ist der erforderli-che Koordinationsbedarf davon abhängig, ob ein pyramidales oder po-lyzentrisches Netzwerk vorliegt [3.79]. Handelt es sich um den ersten Typ, können eine Gestaltung der Kosten und die Bestimmung der Koor-dinationsinstrumente durch ein fokales Unternehmen erfolgen. Bei ei-nem polyzentrischen Entwicklungsnetzwerk resultieren aus der starken


Dezentralisation ein großer Koordinationsbedarf und damit erhöhte Kosten [3.79]. Koordinationsgestaltungsfelder hinsichtlich der Funktio-nalisierung bestehen vor allem bei der Aufgaben- und Kompetenzzu-ordnung 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 be-inhaltet die Gestaltung der für das Netzwerk vorteilhaften Arbeitszerle-gung weiteren Abstimmungsbedarf und damit höhere Kosten [3.35]. Organisatorische Koordinationsgestaltungsfelder der Ablauforganisati-on. Hinsichtlich der Ablauforganisation besteht ein wesentlicher Koor-dinationsgestaltungsbedarf in der Aufspaltung des komplexen Gesamt-entwicklungsprozesses 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, Ver-einbarungen, Kontrolle des Zielerreichungsgrades bzw. der Entwick-lungsziele und die Anpassung als Gestaltungsfelder identifizieren. Ab-stimmungsbedarfe 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 be-trachteten 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. Koordinationsgestaltungsfelder hinsichtlich materieller Ressourcen.Koordinationsgestaltungsfelder hinsichtlich der materiellen Ressourcen resultieren vor allem aus infrastrukturellen Interdependenzen. In Ent-wicklungsnetzwerken werden Abstimmungen insb. durch die angestreb-te Nutzung von Erfahrungskurveneffekten bzw. Größendegressionsef-fekten sowie durch eine stärkere Fokussierung zur Realisierung von Economies of Scobe erforderlich [3.57]. Durch eine gemeinsame Be-schaffung von materiellen Ressourcen, bspw. durch den Aufbau eines Rapid Prototyping Labors, können im Rahmen der Nutzung für die ein-zelnen Netzwerkpartner Kosten von Input-Faktoren reduziert werden [3.19]. Die vielfältigen Beziehungsmöglichkeiten und Verhandlungspa-rameter verursachen weitere Transaktionskosten, die in die Gesamtbe-trachtung zu integrieren sind [3.62]. 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 bes-seren Veranschaulichung der Entwicklungsergebnisse beitragen, als we-


sentliche Diskussionsgrundlage für die Weiterentwicklung dienen und Defizite beim Entwicklungs-Know-how aufzeigen. Das Koordinations-gestaltungsfeld 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 Entwick-lungsnetzwerk wichtig, wie eine kommunikative Abstimmung zwischen den einzelnen Unternehmen erfolgt. Durch den Einsatz von internetba-sierten 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 verein-fachten 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. Gra-des) zu Grunde gelegt werden. Zunächst galt es, ein allgemeines Prozess-modell für die Erstellung des Leistungsbündels aus Zustimmungsschalter und Engineeringdienstleistung festzulegen. Das Ergebnis dieser Grobana-lyse zeigt die folgende Abbildung, bei der auch die für die beiden Bestand-teile des Leistungsbündels wichtigen Hauptprozesse 2 und 3 bereits her-vorgehoben sind. Insgesamt wurden in die Untersuchung des Geschäfts-prozesses „Vermarktung eines Engineering-Leistungsbündels“ fünf Haupt-prozesse in die detaillierte Betrachtung und kostenrechnerische Unter-suchung integriert.

Die erste Analyse ließ sich dabei auch bereits am Designprototypendurchfü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 geomet-rischen Prototypen. Bei näherer Betrachtung des Hauptprozesses 2 ließen


sich vier Teilprozesse zuordnen. Beginnend mit der Aufnahme der Kun-dendaten sowie der Durchführung der Berechnung, bestand der Hauptpro-zess 2 „Engineeringdienstleistung“ weiterhin aus der konstruktiven Emp-fehlung sowie der Dokumentation. In einer Detaillierungsstufe erfolgte weiterhin eine kritische Analyse und Zuordnung der verschiedenen Tätig-keiten zu den Teilprozessen. Bei dieser Erhebung und Festlegung der ver-schiedenen Teilprozesse galt es besonders eine praxisorientierte Lösung bei gleichzeitiger hoher Realitätsnähe zu finden. Ausgehend von der kon-kreten 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-


tematischen Darstellung soll die Vorgehensweise im Folgenden an den beiden Kostenstellen „Konstruktion“ sowie „Vertrieb Zustimmungsschal-ter“ näher veranschaulicht werden. Zur genaueren Untersuchung und bes-seren Möglichkeit der Steuerung wurde bei der kostenorientierten Bewer-tung ebenfalls eine Gliederung nach der Beziehung zum Prototypen in Prozesse ersten bis dritten Grades vorgenommen. Die Prozesse ersten Gra-des haben dabei direkte Beziehung zum Prototypen. Dies bewirkt, dass Änderungen am Prototypen auch unmittelbare Auswirkungen auf die ver-schiedenen Teilprozesse haben. Bei Prozessen zweiten Grades ist diese Beziehung hingegen nur indirekt. Somit lässt sich nur mittelbar eine Wir-kungsbeziehung 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 ei-ne Veränderung des Produktmodells nicht zwingend zu geänderten Teil-prozessen und Teilprozesskosten führt.

Für die kostenorientierte Bewertung war es dabei wesentlich, dass die gesamten Kapazitäten der Kostenstelle auf die Teilprozesse verteilt wur-den. Weiterhin wurde bei der vorliegenden Untersuchung zusätzlich noch eine Differenzierung in genutzte und ungenutzte Kapazitäten vorgenom-men und damit die Möglichkeit zur Durchführung eines TD ABC (Time Driven Activity Based Costing) gegeben. Durch die Unterscheidung konn-te auch untersucht werden, wie eine Veränderung bei einzelnen Prozess-zeiten 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 geo-metrischen 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. Proto-typen 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 betroffe-nen Kostenstellen identifiziert werden. Somit standen bisherige Kosten-stellenkosten für die Planung zur Verfügung. Am geometrischen Prototy-pen erfolgte eine erste Planung der Sollzeiten für die verschiedenen Teilprozesse. Gleichzeitig konnten auch die Nettokapazität und die Kos-tenstellenkosten für die beiden betroffenen Kostenstellen geplant werden. Dadurch konnten bereits am geometrischen Prototypen erstmalig die Stun-denkostensätze und damit die geplanten Leerkosten ermittelt werden.


(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 Themen-bereiche. So wurden in der kombinierten Hauptprozessverdichtung zum einen die Kosten des Leistungsbündels „Web-to-CAD“ als auch die netz-werkorientierten Koordinationskosten zusammengefasst. Basis der Kalku-lation stellten dabei die Kapazitäten dar, die im Rahmen der Teilprozessbe-trachtung auf die verschiedenen Teilprozesse umgelegt wurden. Dabei ließen sich auch die Mengen und Prozesskostensätze zur Planung der ge-samten Prozesskosten nutzen. Für den Hauptprozess 2 waren dabei die Teilprozesse „Durchführung der Berechnung“, „Konstruktive Empfeh-lung“, „Aufnahme der Kundendaten“ sowie „Dokumentation“ mit zu in-tegrieren. (Die gesamten Teilprozesskosten für den Teilprozess „Durch-führung der Berechnung“ ergeben sich so z. B. durch Multiplikation von 1500 Mengeneinheiten mit dem Prozesskostensatz von 32,47 €). Die Ge-samtkosten 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 be-rü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 Zustim-mungsschalter und Engineeringdienstleistung, sondern auch für den ge-samten Hauptprozess durchgeführt. Die im Rahmen der Planperioden sin-kenden Koordinationskosten können die Kostensteigerung bei den Teilprozessen der Engineeringdienstleistung überkompensieren.


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 in-formationstechnische Umsetzung der instrumentellen Neuerung mittels ei-nes 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ähl-ten Bereich auch die gesamten Kosten verteilen zu können. In die vorlie-gende 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 Leis-tungsbündel anfallen. Anschließend wurde eine Tätigkeits- und Teilpro-zessbetrachtung durchgeführt und daraufhin die gesamten Kapazitäten ver-teilt. 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 Steuerungs-funktion war weiterhin die prototypgestützte Ermittlung und Darstellung der Zielkostenlücken. Ausgehend von dem angestrebten Zielumsatz wur-


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 Be-stimmung der Zielkostenlücken, die im Bezug zu minimalen und maxima-len Drifting Costs resultierten. Die qualitative Analyse untersucht die für eine Kooperation in Frage kommenden Prozesse bei TOOLING hinsicht-lich der Einflussgrößen auf die Verursachung von Transaktionskosten. In diesem Praxisprojekt wurden die beiden Entwicklungsprozesse „Kompo-nentenentwicklung“ sowie „Systemintegration und Test“ im Hinblick auf die herausgearbeiteten Transaktionskosteneinflussgrößen untersucht. Da-bei wurden die Mitarbeiter von TOOLING aus unterschiedlichen Unter-nehmensbereichen zu den beschriebenen Entwicklungsprozessen befragt. Nachdem die Mitarbeiter über die qualitativen Einflussgrößen der Trans-aktionskosten befragt wurden, erfolgt im nächsten Abschnitt die Verknüp-fung 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 Elektronikfunkun-ternehmen (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 Prozes-sen in der Produktion sind Entwicklungsvorhaben mit einem gewissen Neuigkeitsgrad verbunden. Ein hoher Neuigkeitsgrad erschwert die Prog-nostizierbarkeit und verursacht außerdem einen entsprechenden Zeitauf-wand für die Suche und Erarbeitung neuer Problemlösungen. Entwick-lungsprojekte 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ön-nen schnell zu einer sehr hohen Komplexität führen, die einen sinnvollen Einsatz des Excel-Tools nicht mehr gewährleisten. Ein Weiteres bedeuten-des 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: As-sembly 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 Risi-kooptimierung 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 Motoren-bau“, 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 Deve-lopment – ein ganzheitliches Produktentwicklungskonzept, in: Konstruktion, Jg. 48, 1996, Nr. 10, S. 305-334

[3.10] Bullinger HJ, Warschat J (1997) „Forschungs- und Entwicklungsmanage-ment“, Stuttgart, Teubner, 1997

[3.11] Bürgel HD, Haller C, Binder M (1996) F&E-Management, München: Vah-len, 1996

[3.12] Burghardt M (2002) Projektmanagement: Leitfaden für die Planung, Über-wachung und Steuerung von Entwicklungsprojekten, 6. Aufl., Erlangen 2002


[3.13] Cassack I (2002) Prozessorientiertes Kostenmanagement am Beispiel der prototypgestützten Kostengestaltung für Dienstleistungen. In: REFA-Nachrichten, 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: Internet-Einkaufsplattformen. In: WISU, Jg. 29, 2001, Nr. 2, S. 200-206

[3.20] Ehrlenspiel K (1995) „Integrierte Produktentwicklung“, Carl Hanser Ver-lag, 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 Produkt-

entwicklung“, Springer-Verlag Berlin Heidelberg, 1996 [3.25] Gomes de Sá A (2001) Virtual Prototyping als innovative Absiche-

rungsmethode 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 Kongress-Gesellschaft: CAT.PRO 2005 : 21. Internationale Fachmesse für innovative Produktentwicklung, Daten- und Prozessmanagement, 04.-07.10.2005, Stutt-gart. 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ück-spanntechnik : 4. Fachtagung Prozesszeitverkürzung und Rüstkostenoptimie-rung, Ingolstadt, 17./18. Mai 2006. Landsberg/Lech : verlag moderne indust-rie, 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 Solu-tions and Best Practice Concepts. Proceedings. International User's Confer-ence 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, Washing-ton, 1996

[3.34] Heckerman D, Geiger D, Chickering D (1995) Learning Bayesian Net-works: 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 & Manufactur-ing - 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 Associ-ates, 2005, S. 112-114

[3.37] Henning A, Grzesiak A (2006) Rapid Prototyping, Tooling & Manufactur-ing - 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 Associ-ates, 2006, S. 115-116

[3.38] Henning A, Grzesiak A, Roth-Koch S, Becker R, Effenberger I, Westkäm-per E (2005) Rapid Prototyping and Manufacturing - Trends and Develop-ments in Germany. In: Society of Manufacturing Engineers: Rapid Prototyp-ing 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 Sys-tems 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 maxi-mum 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üh-ren. In: ZfO, Jg. 68, 1999, Nr. 5, S. 292-295


[3.45] Kempf M, Grzesiak A (2003) Entscheidungsunterstützung in der Produkt-entwicklung - Problemorientierte Auswahl eines Lösungskonzepts durch kon-textsensitive 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 Proto-typing – Bedarf und Potentiale, in: VDI-Zeitung, Jg. 135, 1993, Nr. 8, S. 92-94

[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“, Springer-Verlag, Berlin Heidelberg, 1995

[3.49] Kühnel J (1995) Datenrepräsentation durch Prototypen: erweiterte Konzep-te 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ün-chen Wien, 1995

[3.52] Madauss BJ (1997) Projektkostenschätzung im Rahmen der Produktent-wicklung, In: Horváth, P. u.a. (Hrsg., 1997), S. 20-31

[3.53] Marx P (1998) “Durchgängige, bauteilübergreifende Auslegung vom Ma-schinenelementen 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, Regula-tion 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 in-ternational conference of QRM 2004, 1st and 2nd April 2004, Oxford, Eng-land, pp 35-38

Literatur 203

[3.62] Picot A, Dietl H, Franck E (1999) Organisation: Eine ökonomische Per-spektive. 2. Aufl., Stuttgart: Schäffer-Poeschel, 1999

[3.63] Picot A, Reichwald R, Nippa M (1988) Zur Bedeutung der Entwicklungs-aufgabe 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 Dienstleistungs-bereich – Konzeption eines prozeßkostengestützten Instrumentariums, Wies-baden 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 Produktentwick-lungen: Praxis des wettbewerbsorientierten Entwicklungsmanagements, Stutt-gart 1992

[3.67] Spath D, Demuß L (2003) Entwicklung hybrider Produkte – Gestaltung ma-terieller und immaterieller Leistungsbündel, in: Bullinger, Scheer (Hrsg., 2003), S. 467-506

[3.68] Specht G, Beckmann C, Amelingmeyer J (2002) F&E-Managment: Kom-petenz im Innovationsmanagement, 2. Aufl., Stuttgart 2002

[3.69] Spitta T (1989) Software Engineering und Prototyping: eine Konstruktions-lehre 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 Kon-struieren 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 De-sign 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 Entwicklungspro-jekten im Rapid Product Development“, Springer-Verlag, 1999


[3.81] Zwecker J, Düll-Mühlbach I, Eßwein G (1994) Erhöhung der Prozeßfähig-keit - 'Forgiving Systems', Konferenz-Einzelbericht: Starke Märkte - Compo-sites stellen sich dem Wettbewerb, 26. Int. AVK-Tagung, Arbeitsgemein-schaft 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 multi-disziplinä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 Integra-tion 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 aufbereite-ten Informationen ebenfalls unterstützende Methoden für die Teamkoope-ration und -kommunikation notwendig. Als Grundlage einer teamübergrei-fenden 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 be-leuchtet werden (Abb. 4.1.).

Die vier Ebenen werden durch Nutzeraktionen von oben nach unten zur Datenbeschaffung und von unten nach oben zur Datenaufbereitung durch-laufen. Beim Durchlauf von oben nach unten wird die Informationsbe-schaffung durch die einzelnen Ebenen und den damit verbundenen An-wendungen immer weiter verfeinert. Während im umgekehrten Durchlauf, von unten nach oben, die gewonnenen Informationen durch die entspre-chenden Verfahren für den Experten situationsgerecht aufbereitet werden.

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

Dabei erbringt jede Ebene eine Dienstleistung für die darüber liegende E-bene und nutzt gleichzeitig die angebotene Dienstleistung der darunter lie-genden Ebene.

Abb. 4.1. Architektur der RPD-IT-Infrastruktur

Auf der obersten Ebene befindet sich das RPD-Portal (Kap. 4.4 „Adap-tive Benutzungsoberflächen“). Das RPD-Portal stellt die visuelle Schnitt-stelle zum Nutzer dar. Es bietet einen einheitlichen Zugriff auf die RPD-Anwendungen 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 Prototypen-verfahren und deren Anwendungen (Kap. 5).

Die teamorientierte Kommunikation (Kap. 4.3 „Teamorientiertes Kom-munikationssystem für vernetztes Arbeiten“) stellt dabei eine Funktionali-tät zur Verfügung, die sowohl die RPD-Anwendungen als auch den Exper-ten bei der Datenmanipulation unterstützen. Zu diesem Zweck wurden zwei Richtungen zur IT-basierten Unterstützung der teamorientierten Zu-sammenarbeit 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 Abstimmungsprozes-ses der Termin für alle Beteiligten als verbindlich angesehen werden kann. Die zweite IT-basierte Unterstützung der teamorientierten Zusammenar-beit verfolgt den synchronen Kommunikationsansatz. Hierfür wird ein drei-dimensionaler Teamraum zur Verfügung gestellt, in dem alle Exper-ten eines Teams zeitgleich zusammenarbeiten können. Dabei können Er-gebnisse des RPD, bspw. in Form von virtuellen Prototypen, gemeinsam betrachtet und begutachtet werden. Zusätzlich können Informationen, die-ses Beispiel weiterverfolgend, über den Prototypen im Teamraum hinter-lassen 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 An-wendungen 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 Inkon-sistenzen führen können. Das ASN bietet daher die Möglichkeit Randbe-dingungen (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 über-wacht werden und unter Einhaltung der Bedingung andere Informations-elemente automatisch angepasst werden.

Diese Verfahren sind auf das ASN beschränkt. Des Weiteren ist es nicht die Aufgabe einer Datenhaltung Informationen situationsgerecht und auf-


gabenbezogen dem Nutzer zur Verfügung zu stellen. Zu dem Zwecke wur-de 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 informati-onsverarbeitende, -überwachende und -verwaltende Dienst-leistungen für die RPD-Anwendungen, ebenso wie eine Koordinations-unterstützung. Zu den informationsverarbeitenden Dienstleistungen gehören die Informati-onsbeschaffung und -aufbereitung, sowie die Unterstützung der Datenein-gabe und der Transaktionsschutz. Durch die Informationsbeschaffung er-hä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 In-formationsü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 Nut-zung zu überwachen. Damit kann der Nutzer schnell auf neue Gegebenhei-ten, wie bspw. einen neuen Prototypen, reagieren.

Aufgrund der Größe und der räumlichen Aufteilung der Nutzer und ih-rer Anwendung bietet sich eine Verteilung des ASN in kleinere zusam-menhängende Instanzen an. Dafür wurde ein Synchronisations-mechanismus 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 Teamar-beit. 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 Aufga-ben, die er erledigen muss. Die Fertig-stellung meldet er der Koordinati-onskomponenten der RPD-Middleware, die anhand des vorher vereinbar-ten Koordinationsprotokolls neue Koordinationsschritte einleitet. Dabei ist zu beachten, dass entlang des Produktentstehungsprozesses langandauern-de Koordinationsvorgänge stattfinden können.


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 ak-tiven Wissens“) über die RPD-Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“) und der teamorientierten Kommunikati-on (Kap. 4.3 „Teamorientiertes Kommunikationssystem für vernetztes Ar-beiten“) hin zur obersten Ebene, dem RPD-Portal (Kap. 4.4 „Adaptive Be-nutzungsoberflächen“).

4.1 Ganzheitliche Modelle zur Repräsentation aktiven Wissens

4.1.1 Einleitung

Innerhalb des Rapid Product Development (RPD) stellt das ASN die zent-rale Integrationskomponente zur Verfügung. Sie bietet allen Wissensberei-chen 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


4.1.2 Problemstellung

Die frühen Phasen der Produktentwicklung sind von einem hohen Bedarf an Informationen interdisziplinärer Art gekennzeichnet. Eine den RPD-Bedü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 mehre-ren 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 Sperrmecha-nismen muss gewährleistet werden, dass keine, sich widersprechende, pa-rallel 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 datentechni-sche Grundlage für eine integrierte Software-Architektur für Rapid Pro-duct 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 (Event-Condition-Action) gesteuert [4.59], [4.158], untersucht. Die entwickelte aktive Komponente ist in der Lage, Schlussfolgerungen in der Wissensba-sis durchzuführen und auch externe Applikationen, insbesondere Benach-richtigungsmechanismen, zu starten [4.158]. Die Notwendigkeit einer ide-alerweise plattformunabhängigen Schnittstelle für eine prozessüber-


greifende Wissensbasis wurde erkannt und als eine der zentralen For-schungsaufgaben untersucht.

Abb. 4.3. Graphische Darstellung des ASN-Metamodells

Die Kenntnisse aus der prototypischen Entwicklung dieser Schnittstelle und den experimentellen Integrationsuntersuchungen wurden aus prototy-pischen 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:

Durch das ASN sollen alle an der Produktentwicklung beteiligten Wis-sensgebiete abgebildet werden. Die Wissensbasis des ASN soll dabei den gesamten Entwicklungspro-zess unterstützen. Das ASN-Konzept besteht aus dem Metamodell des Semantischen Net-zes und der aktiven Komponente. 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. Die aktive Komponente dient der Propagierung von Wissen durch das semantische Netz. Dies ermöglicht z.B. die Erhaltung von Konsistenz-bedingungen beim Zugriff auf das ASN.


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 Ac-tion.Events werden durch die Ausführung von Zugriffsfunktionen auf das ASN ausgelöst. Die objektorientierten C++ Zugriffsfunktionen werden durch die ASN-API aufgerufen. 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 Ob-jektmanagement, Slot-Dämon, Transaktionskonzept

In der zweiten Entwicklungsstufe (1998-2000) wurde die ASN-Konzeption in umfangreicher Weise fortgeführt und erweitert. Unter den erzielten Er-gebnissen ist vor allem die Erweiterung der ASN-Architektur zu einem verteilten Objektmanagement (s. Abb. 4.5) gemäß Common Object Re-quest Broker Architecture (CORBA) [4.114], die vollständige Konzeption und Umsetzung des kooperativen Transaktionskonzepts und die Erweite-rung 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 ver-teilte Speicherung dieser Objekte in verschiedenen Objekt-Servern.


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 Slot-Dämonen (s. Abb. 4.6) entwickelt [4.60]. Die Slot-Dämonen erlauben


hierbei das Abspeichern von Berechnungsvorschriften und Konsistenz-bedingungen als Attributwerte. Diese werden zum Abfragezeitpunkt aus-gewertet und die entsprechenden Aktionen durchgeführt. Während Trans-aktionskonzepte konventioneller Datenbanksysteme zu unflexibel für dynamische Entwicklungsprozesse sind und kooperatives Arbeiten nur un-zureichend unterstützen, wurde für die Wissensbasis ein Transaktions-konzept 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 Evolutions-schritt in der Entwicklung ganzheitlicher Modelle zur Wissensrepräsenta-tion vollzogen worden. Unter den erzielten Ergebnissen sind vor allem fol-gende Schwerpunkte zu nennen:

Die Weiterentwicklung des ASN auf der Basis von EJBs (Enterprise Ja-va Beans) [4.188], [4.139], [4.175], [4.173], insbesondere von Entity-Java-Beans, Session-Beans, remote- und home-Interfaces und Client-Software, die Schaffung der Voraussetzungen für die Internetfähigkeit des ASN und die Bereitstellung der Formulare für manuelle Änderun-gen der ASN-Datenbasis. Diese Entwicklungen wurden um eine agen-tenbasierte Middleware (Kap. 4.2 „Agentenbasierte Middleware als In-tegrationsplattform für aktive Wissenskommunikation im Rapid Product Development“) ergänzt. 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 objektart-spezifische Abfragen lassen sich durch eine von den Objektarten unab-hängige parametrische Abfrage ersetzen. Für die Semantik der ASN-Daten spielt die genaue Unterscheidung der Objektarten, Beziehungsar-ten, Ereignisarten und Aktionsarten eine sehr wichtige Rolle. Anhand der praktischen Erfahrungen wurde auch die Funktionalität des ASN weiterentwickelt. An dieser Stelle sind vor allem die neuen Daten-


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 ASN-Versionen werden die Constraints nicht in den Attributen der Objekte (nicht in den Merkmalslots), sondern separat gespeichert. Die neue Da-tenstruktur erlaubt, dass ein Attributwert in mehrere Constraints einbe-zogen 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. Auch die aktuelle Konzeption des ASN als Plattform der Wissensreprä-sentation erlaubt nun eine weitgehende Datenbankunabhängigkeit. Zu-sä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 ASN-Klassenmodells erlaubt es zudem, Transaktionen bezüglich des ASN-weiten 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 ver-schiedene 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 Erweite-rung der Datenstrukturen gesehen. Das weiterentwickelte ASN-Datenmodell erlaubt verschiedene Konsistenzzustände der ASN-Wissensbasis zu definieren und zu benutzen und dadurch die Transaktions-sicherheit zu unterstützen. In Kombination mit der Benutzung eines Appli-kation-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.


Verteiltes Objektmanagement

In dezentralen Arbeitsteams, wie sie im RPD üblich und notwendig sind, stehen die Informationen meistens nicht lokal zur Verfügung. Eine verteil-te Software-Architektur wurde bereits, wie oben beschrieben, untersucht. Für die Zugriffsgeschwindigkeit auf die notwendigen Daten spielt der phy-sikalische Speicherungsort eine sehr wichtige Rolle. Daten sollen physika-lisch 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 phy-sikalischen 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 entwickeln-den Caching-Mechanismen zu lösen [4.175]. Der benutzte Applikations-Server ist in der Lage, mögliche Datenverluste durch Systemausfälle abzu-fangen.

Informationsaustausch, Kommunikation, Dokumentation

Der dritte wichtige Aufgabenbereich innerhalb der Entwicklung einer zent-ralen 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 Bearbei-tung der ASN-Objekte sind eine notwendige Voraussetzung für eine er-folgreiche 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 be-sondere Rolle spielt dabei die Client-Software, die es erlaubt, durch benut-zerspezifische Programme auf alle Objekte der ASN-Datenbasis zuzugrei-fen, sie zu erstellen, zu löschen und zu ändern. Zur Flexibilisierung der ASN-Zugriffe wurde eine Middleware entwickelt, die auf den ASN auf-setzt und dabei zusätzliche Funktionalität den RPD-Nutzern bzw. RPD-Anwendungen zur Verfügung stellt (Kap. 4.2 „Agentenbasierte Middlewa-


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.


Das bisherige ASN-Datenmodell wurde weiterentwickelt. In die aktuelle Version wurden mehrere neue Ansätze aus dem „Unified Relational Data-modell“ (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 Mo-dell Konzeption (im Weiteren UDM), Datenbanken mit einem sehr kom-plexen Design ohne Informationsverlust in Datenbanken mit sehr einfa-chem 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 wer-den. Somit stellt das URDM ein direkt verwendbares Datenmodell, wie auch ein Metamodell dar. Ein Teil der Design-Information einer komple-xen 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 Tabel-len 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 Datenfel-der/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 ob-jektorientierten ASN-Implementierung als Instanzen der Klasse „Con-cepts“ 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 Verwal-tungszwecke die Felder (Attribute) „Status“, „von“ und „bis“. Zwischen


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 verschiede-ner Tabellen oder Klassen vorgesehen und möglich sind. Im URDM wer-den die tatsächlich existierenden Beziehungen auf der Instanzebene in der Tabelle „Netz“ gespeichert. Die Tabelle „Netz“ enthält mindestens 4 Da-tenfelder: „Objekt“, „Beziehungsart“, „Verbundenes Objekt“ und „Bezie-hungsdetail“. 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 Ge-genstü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 ent-nehmen. Die Abb. 4.7 zeigt das klassische Design einer Testdatenbank. In der Abb. 4.9 wurde das URDM-Design dargestellt. Die Tabellen „Ob-jects“, „Attributes“ und „Net“ wären für die Benutzung der Datenbank ausreichend. Es ist jedoch sinnvoll, die vorgesehenen Objektarten, Bezie-hungsarten 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 Abarbei-tung 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 Än-derung des Datenbankdesigns und ohne Programmierung von neuen Klas-sen möglich.

4.1 Ganzheitliche M

odelle zur Repräsentation aktiven W

issens 219

Abb. 4.7. B

eispiel für das klassische Datenbankdesign


Abb. 4.8. Ausschnitt aus dem ASN-Klassenmodell


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

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



Die ASN-Wissensbasis besteht aus der ASN-Datenbank, EJBs und Client-Software und schließlich aus einer Ansammlung von anwendungs-spezifischen, in der Datenbank nur referenzierten Objekten. Die Objekte sind z. B. Betriebssystemdateien, die im Netzwerk oder verschiedene ftp-Objekte, 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 In-stanzen der Klasse „Attributes“ sind. Für die Erfassung der Speicherung-sorte der referenzierten Objekte wurde im ASN die Klasse „Pfad“ ange-legt. Ein referenziertes Objekt kann außerhalb der ASN-Datenbank in beliebig vielen Kopien, mit frei wählbarem Ort im Netzwerk, oder im In-ternet existieren. Alle Kopien der referenzierten Objekte und deren Spei-cherungsorte werden in den Instanzen der Klasse „Pfad“ erfasst. Aller-dings darf nur eine Kopie den Masterstatus haben. Nur die Merkmale dieser Kopie werden in der ASN-Datenbasis erfasst. Wenn an einer ande-ren Kopie wesentliche Änderungen durchgeführt wurden, muss die Mas-terkopie 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 selb-stä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 Bezie-hung „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 Daten-bank, die physikalisch an einem Ort gespeichert ist. Die ASN-Implementierung mit EJBs und Application-Server erlaubt es, auch auf mehrere Datenbanken zuzugreifen, die physikalisch an verschiedenen Or-ten 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


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 Da-tenbasis. Die ASN-Implementierung auf der Basis von EJBs erlaubt es, auch über einen anderen Weg die Zugriffe auf die Datenbasis zu beschleu-nigen. 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 RPD-Nutzern 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 RPD-Domänen in das ASN übernehmen und verwalten kann.

4.1.6 Ergebnisse und ihre Bedeutung

Die wesentlichen Vorteile der dritten Entwicklungsstufe liegen in der Um-setzung der Anforderungen der Teilprojekte durch die Erweiterung des Da-tenmodells, die Bereitstellung des EJBs-basierten ASN, der Client-Software und der Middleware für den Zugriff auf die Datenbasis (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wis-senskommunikation im Rapid Product Development“).

Das auf der Basis von Enterprise Java Beans implementierte objektori-entierte 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 ent-standenen 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 Client-Software de facto zwei Repräsentationen der ASN-Datenbasis angeboten und unterstützt. Die UDM-kompatible Repräsentation der Datenbasis er-laubt es, sehr unterschiedliche Objektarten, Merkmalarten und Bezie-


hungsarten zwischen den Objekten auf gleiche Art zu handhaben. Dadurch können die Abfragen und die Auswertungen der ASN-Daten sehr erleich-tert werden.


Benutzung von Defaults Defaults (Voreinstellungswerte) sind Standard-Annahmen, die solange ge-troffen werden, bis detaillierte Informationen vorhanden sind. Die Default-Daten sind in den bereits vorhandenen ASN-Objekten, in deren Dualbe-ziehungen und in den Constraints gespeichert. Das ASN-Datenmodell gibt die Voraussetzungen dafür, dass diese Daten jederzeit auf die dazu geeig-neten Objekte übertragbar sind. Alle in der ASN-Wissensbasis bereits vor-handenen Daten können den Objekten als Defaults (Voreinstellungswerte) zugewiesen werden. In der jetzigen ASN-Version gibt es verschiedene Ar-ten 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 Spei-cherung der externen Objekte, die zulässigen Kombinationen der Ereignis-se, Bedingungen und Aktionen und andere. Alle in den alten Projekten ge-sammelten Informationen können als Default-Daten für neue Projekte verwendet werden. Welche Daten bei neuen Objekten (z.B. bei neuen Pro-jekten) tatsächlich als Defaults verwendet werden, kann nicht pauschal vorausgesagt werden. Als Grundlage für diese Auswahl wird der Ähnlich-keitsgrad bzw. die semantische Distanz zwischen dem neuen Objekt und den vorhandenen Objekten benutzt. Da in der Entwurfsphase die vollstän-dige Information über die neuen Objekte meist fehlt, kann der Ähnlich-keitsgrad nur aus den Anforderungen an das neue Objekt abgeleitet wer-den.

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 objektartbe-zogene Anwendungen/Methoden notwendig. Die Merkmalwerte in den Pa-rameterlisten 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 be-rechnen 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


Funktionalität, Kosten und Qualität von Prototypen zu erfassen. Durch die Trennung der Merkmalwerte und Constraintsbeschreibungen in der ASN-Datenstruktur ist es möglich, auch beliebig komplexe Zusammenhänge des RPD-Wissens zu parametrisieren. Zur symbolischen Repräsentation para-metrischer 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, ver-wendet werden. Die Berechnung der abgeleiteten Größen aus den Vorga-begrößen kann optional von den Constraints, die Bestandteil der ASN-Datenbasis sind, auch in die externen Anwendungen für die Erzeugung von neuen Objekten verlegt werden. Der jetzige Ansatz für die Parametri-sierung 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 ex-terne Objekte, wie z. B. CAD-Modelle, NC-Programme, FEM-Berech-nungen, 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 Vor-aussetzung für die optimierte Datenhaltung. In der ASN-Datenbasis wird in den Instanzen der Klasse „Pfad“ pro Kopie folgende Information ge-speichert: 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 Daten-auswertungen verwendet. Die sonstigen Kopien, die keinen Masterstatus besitzen, können beliebig geändert und bearbeitet werden. Wenn die Bear-beitung 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 ASN-Wissensbasis 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 MechanismenDie Caching-Mechanismen wurden in Betracht gezogen, um die Zugriffe auf die Daten in der ASN-Wissensbasis zu beschleunigen. Die ASN-Datenstrukturen wurden so konzipiert, dass man das Benutzerverhalten auf verschiedene Weise registrieren kann. Die Entwicklung der dafür not-wendigen Methoden ist in einem weiteren Entwicklungsschritt in Koopera-tion mit der Entwicklung der Adaptiven Benutzungsoberflächen (Kap. 4.4 „Adaptive Benutzungsoberflächen“) vorgesehen. Die dadurch gewonnene


Information kann als Grundlage genutzt werden, um die notwendigen Ca-ching-Maßnahmen abzuleiten. Diese Aufgabe kann jedoch anders und ein-facher 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 Belas-tung entspricht und somit realistischer gehandhabt wird als bei Maßnah-men, 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 Middle-ware (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, wer-den als Merkmale in der Datenbasis erfasst. Die Merkmale eines oder mehrerer Objekte können durch Constraints miteinander gekoppelt wer-den. Für die Transaktions- und Datensicherheit wurde eine Konzeption ausgearbeitet, die verschiedene Konsistenzzustände der Wissensbasis un-terscheidet. 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 Ob-jekte und deren Attribute systematisch zu untersuchen und deren Abbil-dung in die Statusmerkmalwerte festzulegen.

Konsistenzzustand 1: Die Daten in der Datenbasis sind vollständig und widerspruchsfrei. Die in der Datenbasis enthaltenen Objektmerkmale er-fü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. Konsistenzzustand 2: Die ASN-Wissensbasis ist nicht im Konsistenz-zustand 1, aber die Datenbasis enthält die notwendige Information, um den Konsistenzzustand 1 im Bedarfsfall automatisch oder manuell (z.B.


Anpassungen der CAD-Modelle) herbeizuführen. Beispiel: Die Merk-malwerte 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 re-lativ viel Zeit in Anspruch nehmen und kann als „lange“ Transaktion der Wissensbasis gesehen werden. Um den Konsistenzzustand 2 zu er-reichen, werden im ersten Schritt bei den betroffenen Objekten und Ob-jektmerkmalen 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 Informations-verlust, da die Statusmerkmale erst nach der vollständigen Durchfüh-rung der Berechnungsvorgänge zurückgesetzt werden. Das ASN bleibt auch nach dem Systemabsturz im Konsistenzzustand 2.

Abb. 4.11. ASN-Wissensbasis

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


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 ma-nuell durch den Systembetreuer durchgeführt werden. Wichtig ist, dass beim ASN-Betrieb der Konsistenzzustand 2 aus dem Zustand 3 durch kur-ze Transaktionen erreicht werden kann. Die Zustandsübergänge können mit Hilfe der Implementierung von ECA-Regeln, mit dem Transaktions-Agenten oder manuell (durch Formularereignisse) angestoßen werden. Die detaillierte Beschreibung der implementierungsunabhängigen ASN-Transaktionssicherheit wird in [4.168] publiziert.

Ein besonderer Beitrag zur Transaktionssicherheit wird vom Applikati-ons-Server geleistet. Der Server ist in der Lage, nach dem Absturz und nach dem Neustart des Systems die auf der Ebene der Java-Beans ablau-fenden 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 „Relati-ons“ (Beziehungen) wurden mit den Zeitattributen „von“ und „bis“ ausges-tattet. Es wäre denkbar, bei jeder Änderung in der Datenbasis den alten Zustand der Objekte und Datensätze mit den Zeitattributen in einer separa-ten Datenbasis zu speichern und bei den geänderten Objekten und Daten-sätzen die Zeitattribute anzupassen. Auf diese Weise könnte ein permanen-tes, partielles Backup der Datenbasis durchgeführt werden. Allerdings müssten dann im Falle einer Änderung der Objekte in der aktuellen Daten-basis die Attribute „von“ und „bis“ und bei den Daten in der „Backup“-Datenbasis das Attribut „bis“ geändert werden. Diese Technik wird mo-mentan 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 wer-den. 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 au-tomatische Anpassung der Merkmalwerte in der Datenbasis und in den ex-


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ög-lichkeit, den Objekten beliebige Merkmale zuzuweisen oder wegzuneh-men. 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 Wis-sensdefizit 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 Tole-ranzgrenzen können einem Objekt als Zusatzmerkmale zugewiesen wer-den. Das Modell ist in der Lage zu beschreiben, dass die Werte eines Merkmals aus einer Wertliste übernommen werden können. Bei der Hand-habung von Auswahloptionen kann auch unsicheres Wissen berücksichtigt werden. Als weitere Möglichkeit, unsicheres Wissen zu beschreiben, kön-nen Wahrscheinlichkeiten für die Merkmalwerte benutzt werden. Das Da-tenmodell wäre in der Lage, auch statistische Verteilungen für Merkmal-werte 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 folgen-de besondere Merkmale auf:

Die Formeln werden nur einmal gespeichert (s. Instanzen der Klasse „Formulas“) und eventuell mehrmals benutzt. Die Formeln und Constraints werden separat gespeichert, in der Be-schreibung von Constraints werden die Formeln nur referenziert (s. In-stanzen der Klasse „ConstrFormeln“). Eine Constraints-Bedingung kann wahlweise verschiedene Formeln, welche die gleiche Argumentanzahl und Argumentart haben, verwenden. Ein Merkmalwert kann in mehreren Constraints, optional als Eingabe-größe oder als berechnete Größe, benutzt werden. Was vorgegeben ist und was berechnet werden muss, kann der ASN-Anwender frei festle-gen. Die Bedeutung dieser Funktionalität ist aus der Abb. 4.12 ersicht-lich. Diese Information und die Zuweisung der Merkmale zu Variablen


der benutzten Formeln wird in den Instanzen der Klasse „ConstrRelati-on“ 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 Constraintsbedin-gungen 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 Pa-rameterwerten x1, x2,...xn können direkt im ASN, mit Hilfe eines For-melinterpreters durchgeführt werden. Durch die Constraints können verschiedene Merkmalwerte von ver-schiedenen 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 ge-schlossene 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 zwi-schen 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 berechne-te 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

4.1 Ganzheitliche M

odelle zur Repräsentation aktiven W

issens 231

Abb.

4.13. B

eispiel für

die V

erbreitung der

Änderungen

im

ASN

durch

Constraints


ASN-Clientsoftware

Einer der wichtigsten Software-Bausteine im ASN ist die Client-Software. Die Methoden der Client-Klasse werden als gemeinsame Programm-schnittstelle für alle ASN-Softwareentwickler benutzt. Die Benutzung der Client-Software ermöglicht es, die ASN-Programmentwicklungen unab-hängig von im Hintergrund benutztem Datenbanksystem durchzuführen. Die Programmierer und ASN-Benutzer können arbeiten, ohne den Spei-cherort der ASN-Datenbasis explizit zu kennen. Als Voraussetzung für die Bereitstellung der Client-Software wurden zuerst alle notwendigen Metho-den 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 ASN-Daten

Für Testzwecke und auch für die praktische Benutzung der ASN-Datenbasis sind verschiedene GUI-Formulare sehr nützlich. Diese Admi-nistrationsoberflächen wurden entwickelt, um auch den Nichtpro-grammierern zu erlauben, die ASN-Datenbasis zu nutzen. Der Übergang


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 Objek-te 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 Datenmo-dells für alle Dataretrieval-Vorgänge. Im UDM-Modell werden alle Ob-jektarten des klassischen Datenmodells auf gleiche Art behandelt. Das Gleiche gilt auch für alle Beziehungsarten und Merkmalarten, die im klas-sischen 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.

„Suche alle Objekte mit Merkmal X“ – das Vorhandensein des Merk-mals „X“ wird geprüft, „Suche alle Objekte mit Merkmal X und Merkmalwert XW“ – ein Merkmal und Merkmalwert werden geprüft, „Suche alle Objekte vorgegebener Art“ z. B. Person, Projekt, Prototyp usw.„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 ent-wickelt. Diese Methoden sind unabhängig von Objektart, Merkmalart und Beziehungsart. Sie benutzen jedoch Objektarten, Merkmale, Merkmalwer-te und festgelegte Mengen von Beziehungsarten als Parameter in der Krite-rienbeschreibung für die Abfragen.



Das ASN-Datenmodell erlaubt es, Objekte, die außerhalb der ASN-Datenbank existieren und mit externen Anwendungen erzeugt und bearbei-tet werden, in der ASN-Datenbank mit allen relevanten Merkmalen zu er-fassen und zu verwalten. Die ASN-Implementierung auf der Basis von EJBs gibt im Prinzip auch die Möglichkeit, mit physikalisch verteilten Da-tenbanken zu arbeiten. Bestimmte notwendige Voraussetzungen für die au-tomatische 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, Anre-gungen und auch kritischen Aussagen zu Ergebnissen der ersten Entwick-lungsstufen. Die Entwicklung des ASN und der RPD-Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplattform für aktive Wis-senskommunikation im Rapid Product Development“) hat dazu beigetra-gen, dass das ASN heute als gemeinsame Integrationsplattform zur Verfü-gung steht. Die wichtigsten Grundideen und auch die Anwendungs-anleitung 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 Beziehun-gen durchgeführt und die Ergebnisse in UML-Klassendiagrammen abge-bildet. Diese klassische Darstellung des Datenbankdesigns wurde als Ar-beitsbasis auch in der dritten Entwicklungsstufe benutzt und auf der Basis von Enterprise Java Beans implementiert. Aber bei der EJB-Implementierung wurde auch die UDM-Sicht der Datenbasis voll berück-sichtigt 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 Design-Form kann in die andere reversible transformiert werden), stehen dem ASN-Benutzer, bei der Benutzung einer Datenbank zum ersten Mal, beide


Sichten auf die Daten gleichzeitig zur Verfügung. Der Benutzer kann, wenn er will, weiter die Klassen aus dem klassischen Datenmodell benut-zen, 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 Ab-fragen zu handhaben.

Die Objekte können eine unbegrenzte Anzahl an Attributen erhalten, sogar nachträglich und auch solche Attribute, die im klassischen Klassen-modell nicht vorgesehen waren. Es ist möglich, neue Objektarten, Bezie-hungsarten und Merkmale anzulegen, ohne neue Klassen zu programmie-ren, 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 Da-tenmodell benutzt wurden. Dadurch wird im Vergleich zur klassischen Da-tenbankrepräsentation die Vielfalt der notwendigen Abfragen wesentlich reduziert [4.161], [4.162].

Die neue Modellierung von Constraints wurde von der UDM-Reprä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 Mehrfach-beziehungen dar. Für die Unterstützung von constraintsbasierten Suchab-fragen (suche alle Objekte und deren Merkmale, die durch die Änderung des Merkmals „M“ bei dem Objekt „A“ geändert werden...) wurden spe-zielle Suchmethoden entwickelt.


Für das RPD wird als Basis für die RPD-Modellierung das Aktive Seman-tische 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 Data-retrieval, bei den Datenauswertungen und bei der Handhabung und Be-schreibung 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-


matischen Systeme in das ASN zu integrieren um komplexe Gleichungs-systeme lösen zu können und Optimierungsberechnungen durchzuführen.


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 umge-setzt, was in diesen Entwicklungen bereitgestellt wird. Hier grenzt sich un-ser Ansatz gegenüber den anderen Benutzern dieser Technologie nicht ab. Die Differenzen zu anderen liegen in den Möglichkeiten des ASN-Datenmodells.

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 Zusatz-attributen wie „Status“, „von“ und „bis“ erlaubt das ASN-Datenmodell ei-ne 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 unterschiedli-chem 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 Optio-nen offen. Ein Beispiel dafür ist die Zuweisung der Merkmale zu Objek-ten, die hierarchisch eingeordnet wurden. Zu jedem Knotenpunkt der Hie-rarchie gehört eine Menge von spezifischen Merkmalen. Durch den Pfad von dem Stammpunkt der Hierarchie zu einem Objekt ist bestimmt, wel-che Merkmale ein Objekt besitzen soll. Im ASN ist es möglich, „Merkmal-trägerobjekte“ zu definieren, deren Aufgabe es ist, nur die Merkmale und Merkmalwerte zu speichern. Solche „Merkmalträgerobjekte“ werden ande-ren ASN-Objekten zugewiesen. Diese Zuweisung wird mit Hilfe der Dual-beziehung „A enthält Merkmale von B“ beschrieben und kann mit UDM-Standardabfragen ausgewertet werden. Im ASN ist auch eine andere inte-ressante Alternative möglich. Die ASN-Implementierung auf der Basis von EJBs erlaubt als Merkmalwerte auch Objekte zu benutzen. Auf diese Wei-se könnte die aus der Hierarchiezugehörigkeit folgende Merkmalzuwei-sung auch realisiert werden.


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:

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. Absicherung der Änderungen der Wissensbasis durch die Festlegung und Anwendung von unterschiedlichen Konsistenzstufen. Weiterentwicklung des ECA-Ansatzes durch die optimierte Hand-habung der kombinatorischen Vielfalt. Entwicklung von bisher einfachem Constraintsmodelling zu komplexen Constraints und Integration von hochentwickelten Constraintsolvern. Integration der vom ASN unabhängig laufenden Anwendungen mit Hil-fe der Datenschnittstellen, Programmschnittstellen oder durch direkte Kommunikation zwischen der Anwendung und dem ASN. Effektivere Nutzung der ASN-Wissensbasis, Weiterentwicklung von mächtigen Abfragemechanismen, Dataretrieval mit Hilfe der Ähnlich-keitssuche.Die Entwicklung von Komponenten zur Informationsstrukturierung für eine internetbasierte ASN-Wissens-Visualisierung und Wissens-reprä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 Visualisie-rung durch ASN-Anwendungen zur Verfügung. Damit ist es zum einen möglich, Wissen ortsunabhängig und fachübergreifend aufbereitet zur Be-arbeitung 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 Infor-mationen rund um die RPD-Prozesse, auf der anderen Seite die Unterstüt-zung der automatisierten Aufbereitung des Wissens bereit. Beide Eigen-schaften und Funktionsbereiche steigern die Qualität und Geschwindigkeit des Informationsaustausches von Beginn des RPD-Prozesses an. Hoch-komplexe Prozessabläufe können durch die Analyse vorangegangener Pro-


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 be-steht 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 Wis-sensbasis 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 De-velopment

4.2.1 Die Herausforderung: Wissenskommunikation im Rapid Product Development

Das Rapid Product Development zeichnet sich unter anderem durch die In-tegration 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 Informatio-nen, die für den RPD-Prozess von Bedeutung sind, im ASN ab. Dieses ex-plizite Wissen ist dabei logisch nach den Zusammenhängen zwischen den Wissensbereichen strukturiert. Wodurch das ASN den verteilten Entwick-lungsteams 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 Kom-munikations- 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 Kommuni-kationsumgebung 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 RPD-Anwendungen 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 de-ren semantischen Zusammenhängen in einem objektorientierten Umfeld. Zusätzlich besitzt das ASN eine aktive Komponente in Form eines Regel-werks, um Informationen einer Wissensdomäne in eine andere innerhalb des ASN propagieren zu können.

Die Funktionen des ASN sind auf eine datenorientierte Ebene be-schränkt. Der Zugriff auf das ASN wird durch eine objektorientierte Pro-grammierschnittstelle 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 erweiter-te Zugriffs- und Information-Retrieval-Methoden für die Informationsbe-schaffung und -aufbereitung in der RPD-Middleware realisiert worden, die


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 Aus-lesen von Informationen wurden transaktionsgestützte Methoden entwi-ckelt, 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 Kommu-nikation zwischen dem ASN und den RPD-Anwendungen realisiert. Er-eignisse, 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 be-steht daher in der Bereitstellung von Funktionalität zur Informationsver-mittlung. Diese teilt sich in die Überwachung von Informationen im ASN und in die Koordination der RPD-Anwendungen entlang des Produktent-stehungsprozesses auf.

Neben diesen inhaltlichen Problemstellungen berücksichtigt die RPD-Middleware auch infrastrukturelle Fragestellungen, wie z. B. die Vertei-lung 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 Be-schreibung 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 allgemei-ne 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 Um-gebung handelt [4.106], in der weitere Agenten existieren. Die A-genten interagieren untereinander [4.172] auf der Basis eines ge-meinsamen 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-


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:

Logic based agents: Diese Agenten bestimmen ihre Ausgabefunktion durch das logische Schließen auf der Basis von logischen Zusammen-hängen, die in der Datenbasis des Agenten abgelegt sind [4.82], [4.113]. Reactive agents: Dieser Agententyp besitzt einen Satz von Aktionen, die er abhängig von der Umgebung ausführt. Es besteht ein direkter Zu-sammenhang zwischen der aktuellen Situation der Umgebung und der Aktion des Agenten darauf [4.25], [4.63]. Belief-desire-intention (BDI) agents: Das Schlussfolgern im BDI-Ansatz [4.83] basiert auf Datenstrukturen, die durch die Annahmen (be-liefs), Wünsche (desires) und Ziele (intentions) repräsentiert werden [4.21], [4.22]. Layered architectures: Die Problembearbeitung wird in Layered Ar-chitectures durch mehrere Softwareebenen realisiert, die jeweils einen bestimmten Teil zur Entscheidungsfindung beitragen. Es wird zwischen horizontaler und vertikaler Schichtbildung unterschieden. Die horizonta-le Schichtbildung (s. Abb. 4.17) bedeutet, dass der Agent in unterschied-liche 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].


Abb. 4.17. Schematische Darstellung der Layered-Architektur

Kommunikationsbeziehungen und -wege

Für die Auswahl des richtigen Kommunikationsweges werden drei Arten von Kommunikationsbeziehungen unterschieden.

1-zu-1: Es kommuniziert genau ein Partner mit einem anderen Partner. 1-zu-n: Es kommuniziert ein Partner mit beliebig vielen anderen Part-nern.m-zu-n: Es kommunizieren mehrere Partner mit beliebig vielen Ande-ren.

Um diese Kommunikationsbeziehungen informationstechnisch abbilden zu können, gibt es in der Netzwerktechnologie [4.190] drei Arten von Kommunikationswegen:

Unicast: Die Unicast-Technologie setzt die 1-zu-1 – Kommunikation um. Es wird genau ein Kommunikationskanal zwischen zwei Kommu-nikationspartner geschaltet. 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. Multicast: Die Multicast-Technologie bildet ebenso wie der Broadcast-Ansatz die 1-zu-n – bzw. m-zu-n – Kommunikation ab. Die Gruppen-bildung erfolgt durch die Kommunikationspartner und ist auf keine räumliche Nähe, wie Netzwerke, beschränkt.


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 Kommuni-kation, also der beabsichtigten Wirkung, dem Inhalt der Nachricht und dem Ergebnis der Kommunikation [4.110]. Da der reine Inhalt einer Nach-richt oft missverständlich ist, müssen Regeln für die Interpretation des In-halts 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 Kom-munikation von Computersystemen untereinander übertragbar ist. In der Sprechakttheorie wurden hierbei Kommunikationsregeln erarbeitet und ei-ne Grammatik sowie ein Basis-Wortschatz festgelegt. Die Sprechakttheo-rie ist auch bei der Teamkoordination im RPD von großer Bedeutung [4.37].

Derzeit existieren Standardisierungsbestrebungen für zwei viel verspre-chende Agenten-Kommunikations-Sprachen, die die inhaltliche Strukturie-rung der Nachricht zum Ziel haben. Eine direkte Gegenüberstellung beider Ansätze findet sich in Labrou [4.118] und Luck [4.129]. Dabei ist zwi-schen 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 spezi-fiziert, 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 Mani-pulation Language (KQML) als eine Programmiersprache, die Sprechakte nutzt, um eine inhaltsorientierte Kommunikation zwischen Agenten aufzu-bauen [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 Informa-tionsgehalt 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].


Die eigentliche Nachricht wird in die KQML-Nachricht im Knowledge In-terchange 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 Standardisierungs-bestrebungen 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 funktionieren-de Kommunikation nicht ausreichend; es müssen Koordinationsprotokolle definiert werden, die den Kommunikationsablauf zwischen den Bestand-teilen der RPD-Middleware und den RPD-Anwendungen bestimmen. Die Koordinationsprotokolle haben folgende Ziele [4.146], [4.145], [4.105]:

Vermeidung von Chaos hat zum Ziel, durch die Zusammenführung al-ler Teilergebnisse, ein Gesamtziel zu erreichen. Schaffung einer einheitlichen Umgebung, die die Randbedingungen beinhaltet, in denen die Komponenten arbeiten. Koordination von verteilten Informationen, Ressourcen und Ver-antwortlichkeiten, um eine klare Zuständigkeit zu erhalten. Auflösung von Abhängigkeiten zwischen zwei Komponenten.Effizientes Arbeiten bspw. durch die Aufgabenaufteilung auf speziali-sierte Agententypen.

Dabei wird zwischen den folgenden Klassen von Koordinationsproto-kollen unterschieden [4.94]:

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]. Vertragsprotokoll: Das Vertragsprotokoll, auch Contract Net Protocol (CNP) [4.45], [4.179] genannt, beruht auf dem Vertragsprinzip. Ein A-gent bietet eine Leistung an und garantiert, dass die Leistung erbracht


wird. Möchte ein anderer Agent diese Leistung nutzen, so schließt er mit dem anbietenden Agenten einen Vertrag ab. Blackboard-Ansatz: Unter dem Blackboard-Ansatz wird ein zentralis-tisches Verfahren verstanden, wo alle Informationen an einem Ort, dem Blackboard, abgelegt werden. Auf diesen Ort haben alle Koordinations-beteiligte Zugriff. Die Koordination erfolgt durch Auswertung der vor-handenen Informationen auf dem Blackboard [4.58], [4.104], [4.39], [4.87], [4.142], [4.147]. Verhandlungsansatz: Der Verhandlungsansatz ist ein verteiltes Verfah-ren, bei dem alle Koordinationspartner gleichberechtigt sind. Zwischen den Koordinationspartnern wird ein Verhandlungsprotokoll bspw. re-gelbasiert [4.18] oder durch ein Zustandübergangsdiagramm spezifiziert [4.10]. Marktmechanismen: Marktmechanismen [4.200] funktionieren nach dem Prinzip der Marktwirtschaft. Die einzelnen Koordinationskompo-nenten bieten ihre Lösung, hinterlegt durch einen Preis, an. Eine gang-bare 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 Spei-cher 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

die Unterteilung komplexer Systeme in einfachere Subsysteme mit dem Ziel, eine höhere Stabilität und Wartbarkeit durch Senkung der Kom-plexität der Teilkomponenten zu erreichen. 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 un-terschieden:


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 – Prin-zip 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. Verteilte Systeme: In den verteilten Systemen [4.191] gibt es keine di-rekte 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ück-sichtigen, dass im Vergleich zur Client/Server – Architektur eine belie-bige 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 Um-ständen an mehrere Ziele gerichtet ist oder Antworten von mehreren Zielen erwartet [4.1].

Repräsentationssprachen

Im Datenbankumfeld wird zwischen dem relationalen und dem objektori-entierten 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 so-wohl selbständige Sprachen für Ad-hoc-Anfragen sein, als auch in einer bestimmten Wirtssprache eingebettet werden [4.86]. Beiden Anfragespra-chen ist eines gemeinsam, sie dienen ausschließlich zur Informationsbe-schaffung unter der Voraussetzung, dass das Datenmodell zum Zeitpunkt der Anfrage bereits bekannt ist. Ein Navigieren oder eine Anfrage mit un-vollständigem Wissen ist nicht möglich.

XML [4.23] ist ein Standard, der beim Austausch von Daten nur die In-terpretation der Daten definiert, ohne Dateiformate oder Programmier-schnittstellen zu definieren und der somit eine Lösung für den Datenaus-tausch zwischen inkompatiblen Systemen bietet. XML wird häufig eingesetzt, wenn es um Datenmanipulation und -übertragung sowie Ver-waltung 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 se-mantischen Inhalt der Information hinterlegt ist.


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 einge-setzten Datenbanktechnologie und an dem verwendeten Datenmodell. Das Datenmodell gibt dabei Auskunft in welchem semantischen Zusammen-hang die Daten zueinander stehen.

Für die Weiterverarbeitung von Informationen, die in einer Repräsenta-tionssprache formuliert sind, werden unter anderem Anfragesprachen be-nötigt. Diese verhalten sich zu den Repräsentationssprachen wie SQL zum relationalen Datenbankparadigma.

Aufbauend auf den XML-Dokumenten existieren eine Vielzahl von An-fragesprachen bzw. Erweiterungen des vorgeschlagenen Standards XML-QL [4.49] und XQuery als Erweiterung von XML-QL des W3-Konsortiums [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 Problemstel-lung bereits erwähnt, stellt die RPD-Middleware das Bindeglied zwischen ASN und RPD-Anwendungen dar. Für das Verständnis der RPD-Middleware wird daher die genaue Kenntnis des Aufbaus und der Funkti-onsweise 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 Daten-bankschema überführt wird. Im RPD kann sich aber das Datenmodell


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 detail-lierter abgebildet werden als in Datenbanken. So ist z. B. eine Differenzie-rung von verschiedenen Relationstypen möglich.

Diese Vorteile und die Aufteilung des ASN auf zwei Abstraktionsebe-nen stellen eine höhere Flexibilität gegenüber Datenbankansätzen dar und können effektiv im RPD eingesetzt werden. In der ersten Abstraktionsebe-ne wird die Funktionalität, d. h. die Programmlogik des ASN, abgelegt, sowie die Struktur der Datenablage definiert. Die zweite Abstraktionsebe-ne ist die Instanzebene, die die eigentlichen Informationen beinhaltet. Die semantischen Zusammenhänge der Informationen sind über ein objektori-entiertes 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ömm-lichen Softwareentwicklung entworfen wird, sondern um ein Metamodell. Mit Hilfe des Metamodells (s. Abb. 4.18) kann ein klassisches Datenmo-dell abgebildet werden. Die Basis des Metamodells umfasst sieben Objekte von denen die ersten vier im weiteren Verlauf dieses Kapitels von Bedeu-tung sind und die Elemente darstellen, die für die Abbildung eines Daten-modells im herkömmlichen Sinne benötigt werden. Dabei ist das ASN hie-rarchisch über die Elemente Net, Concept, Attribute aufgebaut [4.27], [4.28], [4.167], [4.166].

Net: Die Klasse Net des Metamodells beschreibt ein Aktives Semanti-sches Netz. Das Netz beinhaltet über die Aggregation alle benötigten In-formationen um ein Netz abzubilden und stellt die oberste Hierarchie-ebene dar. Concept: Die Klasse Concept steht für einen Begriff oder eine Informa-tionseinheit in einem bestimmten Aktiven Semantischen Netz. Die Kon-zepte sind typisiert, sodass anhand des Typs entschieden werden kann, welche Attribute das Konzept besitzen soll. Die Klasse Concept bildet damit die mittlere Hierarchiestufe. Attribute: Mit Hilfe der Klasse Attribute werden die Attribute der Kon-zepte realisiert. Durch die Aggregation zwischen Concept und Attributeist es möglich, zur Laufzeit beliebig viele Attribute dem Konzept hinzu-


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 Attribu-te 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 Rela-tionen 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 al-le Instanzen der Klassen Interface, Net, Concept, Attribute und Relationmit 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 An-teil dar. Client: Hierbei handelt es sich um den clientseitigen Anteil der Schnitt-stelle 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. Das-selbe 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 bezeich-net.


Abb. 4.18. Aufbau des ASN auf Strukturebene

Instanzebene

Im Gegensatz zur Strukturebene werden auf der Instanzebene die Informa-tionen in das ASN geschrieben. Es werden dabei Netze instanziiert, Kon-zepte 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 not-wendig um den Wert eines Attributs auszulesen.

Zum Beispiel beinhaltet auf der Struktur-Ebene das Netz für die Ent-wicklung 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äsen-tiert 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 Attribu-ten Vorname Karl und Nachname Mayer sowie eine Instanz Konzept vom Typ Team mit dem Namen Entwicklung sein. Des Weiteren wird eine Re-lation Teamzugehörigkeit zwischen dem Team und der Person hergestellt.


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 darge-stellt, die folgenden Komponenten:

Abb. 4.20. Architektur der RPD-Middleware


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 JAVA-Schnittstelle. Bei der Schnittstelle zu den RPD-Anwendungen wurde eine nachrichtenbasierte Schnittstelle auf Basis des XML-Standards [4.23] ent-wickelt. Dies hat den großen Vorteil, dass ein programmier-sprachenunabhä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 Kommunikati-onspartner (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 ver-wendet. Dieser hat die Form <AgentName> / <AgentType> / <ID>. Der AgentName repräsentiert dabei einen logischen Namen des verwendeten Agenten bzw. der RPD-Anwendung, wie z.B. Koordinati-on_Projektplanung. Der AgentType gibt Auskunft über den zu verwende-ten 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 Kommunikations-möglichkeit in Form einer Multicast-Umgebung geschaffen. Diese hat die entscheidenden Vorteile, dass zum einen nur eine Adresse als Zugangs-punkt 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 Kommunikationsum-gebung aufgespannt werden. Die einzelnen Komponenten der RPD-Middleware entnehmen die für sie bestimmten Nachrichten aus der Multi-cast-Umgebung, wobei die Auswahl der Nachrichten anhand der Empfän-ger-UAI erfolgt.

Masterfunktionalität der RPD-Middleware: Durch die Verwendung des Multicast-Ansatzes ergibt sich die Frage-stellung, wie wird ein Agent direkt aufgefunden und angesprochen, bzw.


wie werden neue Agenten instanziiert. Dieses Problem wird gelöst durch die Implementierung einer zentralen Stelle, die alle nicht direkt adressier-baren 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 Instan-ziierungsaufforderungen, 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 zent-rale Stelle aus, ist die RPD-Middleware unbrauchbar. Um dieses zu umge-hen, 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, bestim-men die Agenten mit Hilfe des Tokenring-Protokolls [4.96] einen Master-Agenten 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 er-folgt 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 Multi-cast-Verbindungen ist eine Segmentierung auf Seiten des Senders und ein Zusammenfügen auf Seiten des Empfängers notwendig (Segmentierungs-schicht). 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-


kommunikation vorbehalten. Über diese Schicht werden die spezifischen Nachrichten je Agententyp ausgetauscht. Diese sind in die XML-Tags <data> und </data> im Nachrichtenformat der Adressierungsschicht einge-schlossen (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=” “>

<data></data>

</request>

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 RPD-Middleware um einen neuen Agenten des gewünschten Typs zu instanziie-ren (1). Der Master-Agent instanziiert den entsprechenden Agenten und gibt im die Dienstanforderung weiter (2). Der neu instanziierte Agent mel-det sich bei der RPD-Anwendung mit einer Acknowledge-Nachricht um dieser den Abschluss des Instanziierungsvorgangs anzuzeigen (3). Darauf-hin leitet die RPD-Anwendung den Auftrag an den Agenten (4). Der Auf-trag 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 ge-wechselt. In dieser Phase werden je nach Agententyp beliebig viele, unter-schiedliche Nachrichten ausgetauscht (7).

In (8) wird der Agent durch die RPD-Anwendung nach Erbringung der angeforderten Dienstleistung beendet.


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.):

Kommunikation: Das Kommunikationsmodul stellt die Schnittstelle des Agenten nach außen dar. Alle Nachrichten werden dort verschickt, empfangen und aufbereitet. Des Weiteren reagiert das Kommunikati-onsmodul selbständig auf Verfügbarkeitsanfragen des Master-Agenten. Zusätzlich überprüft das Kommunikationsmodul zyklisch, ob ein Mas-ter-Agent im System vorhanden ist. Verwaltung: Das Verwaltungsmodul steuert den gesamten Agenten; es stellt damit das Kernstück des Agenten dar. Die vom Kommunikations-modul gelieferten Informationen werden vom Verwaltungsmodul in die


Datenbasis geschrieben und die Problemlösungskomponente angesto-ßen. Nach erfolgter Abarbeitung der Aufgabe holt das Verwaltungsmo-dul die Ergebnisse aus der Datenbasis und stellt sie über das Kommuni-kationsmodul der anfragenden RPD-Anwendung oder des anfragenden Agenten zur Verfügung. 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 fin-det unter Zuhilfenahme der in der Datenbasis abgelegten Informationen statt.Datenbasis: Die Datenbasis enthält alle für die Bearbeitung der Aufga-be 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 ei-nem 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.).


Abb. 4.25. Angriffspunkte der RPD-Middleware

Dies sind [4.43]:

Informationsüberwachung: Ziel dieser Maßnahme ist es Informatio-nen gezielt im ASN zu überwachen und bei Veränderung dieses der RPD-Anwendung aktiv zu melden. Diese Aufgabe nimmt der Monitor-Agent wahr. 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 Aggregati-ons-Agent entwickelt.

Neben der reinen Informationsaufbereitung wurden auch Mechanis-men 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 Infor-mationen in das ASN notwendig. Dieses wird durch den Transaktions-Agenten realisiert. Koordination: Ein weiteres Ziel der Integration der RPD-Experten ist die Koordination der RPD-Anwendungen der Experten entlang des Pro-duktentstehungsprozesses. Hierfür wurde ein Koordinations-Agent kon-zipiert.


Infrastruktur: Als Infrastrukturmaßnahme wurde der Synchro-nisations-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 je-den Agenten eine Anfragesprache entwickelt, mit der die Aufgabenstel-lung 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 nachrichten-basiert. Die Nachrichten werden für jeden Agenten zu einem Satz von Nachrichten zusammengefasst. Ein Protokoll pro Agent definiert die mög-liche Abfolge der Nachrichten, wie sie im Laufe der Kommunikation zwi-schen 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-AgentDer Monitor-Agent hat zum Ziel, die RPD-Anwendung über Informations-veränderungen aller Art im ASN zu unterrichten, ohne dass die RPD-Anwendung 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 recheninten-sive 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 RPD-Anwendung, von Interesse. Diese Spezialität von semantischen Netzen be-deutet, dass eine flexible Überwachung über die Werteüberwachung hin-aus 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:

Vergleich von Attributwerten mit anderen Attributwerten oder Fixwer-tenKomplexe Vergleiche durch Boole’sche Verknüpfungen von Teil-vergleichen


Funktionale Vergleiche wie Strukturfunktionen (Versionsänderungen / Löschoperationen), Zugriffsfunktionen (Anzahl Zugriffe, Version) und mathematischen Funktionen.

Die Überwachungsbedingung wird durch die RPD-Anwendung spezifi-ziert. Diese kann jederzeit den Monitor-Agenten beenden, wenn er nicht mehr benötigt wird.

Retrieval-AgentFü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:

Scharfe Suchmethoden: Diese umfassen die Nachbildung der ASN-Schnittstelle. Zur Anwendung der scharfen Suchmethoden muss die Struktur der abgelegten Informationen bekannt sein, d.h. bei der Anfra-ge muss der Anfragende bereits wissen, ob bspw. die Adresse eines Mitarbeiters als verknüpftes Objekt oder als explizites Attribut abgelegt ist.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üpfungs-typen 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 zwi-schen dem Suchbegriff und dem Ergebnis ist, desto näher kommt das Ergebnis dem gesuchten Wert und desto besser wird es bewertet. Navigation: Entspricht das Ergebnis nicht den gewünschten Vorstellun-gen, bzw. ist es nicht detailliert genug, so kann mit Hilfe der Navigation das nähere Umfeld der Ergebnismenge erkundet werden. Quantitative und qualitative Suche: Mit Hilfe von speziellen Schlüs-selwörtern wie z.B. „wie viele“ kann die Ergebnismenge quantifiziert werden.


Um die Suche zu beschleunigen kann neben der kompletten Durchsu-chung 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 unter-schiedlicher Art gruppiert werden können.

Der Aggregations-Agent erhält als Anfrage eine Menge von Suchanfra-gen, 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.).


Abb. 4.27. Funktionsweise des Aggregations-Agenten

Die Ergebnisse der parallel arbeitenden Retrieval-Agenten werden durch den Aggregations-Agenten zusammengefasst und in der XML-Darstellung der RPD-Anwendung präsentiert. Dabei kann anhand den Gruppierungsinformationen die Ergebnisse der einzelnen Teilanfragen zu-geordnet werden.

Input-AgentDie 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 nutzer-abhä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 Kompo-nenten.

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.


Bedingung: Durch die Anfrageelemente der Bedingung können beding-te Eingaben getätigt werden. Im Bedingungsteil können sowohl Fixwer-te als auch Elemente aus dem ASN zum Vergleich herangezogen wer-den. Im Ausführungsteil werden dann je nach Bedingungsauswertung Informationen ins ASN geschrieben. Hierfür werden die Anfrageele-mente aus der ASN-Schnittstelle genutzt. Die Bedingungsanweisung o-rientiert sich an der Spezifikation der Bedingungsanweisung des Moni-tor-Agenten.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. Kooperative Eingabe: Die kooperative Eingabe dient zur Abstimmung von Eingaben, die von unterschiedlichen RPD-Anwendungen vorge-nommen werden. Durch den Einsatz dieses Sprachelements wird eine Eingabe durch eine bestimmte RPD-Anwendung erzwungen, je nach-dem 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-AgentDie Komplexität des gesamten Systems spiegelt sich nicht nur in den Wis-sensrepräsentationsformen des ASN wieder, sondern auch in der Schwie-rigkeit umfangreiche Serviceleistung anzubieten. Da es allerdings bei ei-nem solchen Betrieb zu mehreren gleichzeitigen Zugriffen kommt, sollte eine Konsistenz-Garantie gewährleistet werden. Das ist eine zentrale Auf-gabe des Transaktions-Agenten und wird durch die Implementierung von Protokollen wie two-phase locking und two-phase commit realisiert. Vo-rausgegangene Entwicklungen im Bereich der relationalen Datenbanksys-teme bzw. Transaction Processing liefern eine Grundlage für die Entwick-lung dieses Agententyps. Folgende Charakteristiken besitzt der Transaktions-Agent:

Lock Manager als Mechanismus für Concurrency Control für das Setzen und Aufheben der entsprechenden Sperren. Entwicklung einer Transaktionssprache für die Zusammenarbeit mit an-deren Agenten innerhalb des Multiagentensystems. Kooperationsfähigkeit mit anderen Agenten für komplexe Aufgaben.


Speicherung von Informationen während des Transaktionsprozesses. User Interface für transaktionsrelevante Informationen.

Das Model des Transaktions-Agenten ist in Abb. 4.28 dargestellt. Die-ses stützt sich einerseits auf die Client-Server Technologie und anderer-seits 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 Kom-mando set_lock_for bezeichnet die Vorbereitung einer Transaktion. Es ga-rantiert, 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 ei-ne Weiterführung der Transaktion verhindern. Das Kommando do_update_for beschreibt die Transaktionsverarbeitung, d.h. die Modifika-tion 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-AgentIm Rahmen der Zusammenarbeit der RPD-Experten unterschiedlicher Domänen entstehen entlang des Produktentstehungsprozesses eine Viel-


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 brin-gen eine informationstechnische Unterstützung sinnvoll und notwendig.

Der Koordinations-Agent bietet hierfür eine Lösung an. Er implemen-tiert 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 Zu-stände repräsentieren Koordinationspunkte und die Zustandswechsel trei-ben die Koordination voran (s. Abb. 4.29.). Das Zustandübergangsdia-gramm wurde derart erweitert, dass es nun auch möglich ist, Eingaben, die für die Zustandswechsel verantwortlich sind, von der sendenden RPD-Anwendung ebenso abhängig zu machen, wie die Ausgabe auf eine be-stimmte 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 Zu-standübergangsdiagramm durch die RPD-Experten definiert und dann dem Koordinations-Agenten übergeben. Anschließend schicken die RPD-Anwendungen ihre Eingabe-Nachrichten, initiieren damit Zustandswechsel


und führen die Koordination solange fort, bis ein Endzustand erreicht wur-de und damit die Koordination beendet ist.

Synchronisations-AgentIn der Erprobungsphase des ASN hat sich gezeigt, dass dieses mit wach-sender Größe sehr unübersichtlich wird und Performanzprobleme aufweist. Eine weitere Erkenntnis ist, dass das ASN sich in verschiedene eng ver-zahnte 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 Kon-zepte, 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 Syn-chronisation 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 Synchronisations-Agent werden die zu synchronisierenden Elemente mit Hilfe von Überwa-chungspunkten im ASN überwacht. Allerdings ist die Bedingungsanwei-sung 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 In-formationselementen, die in einem Segment A überwacht werden sollen, um sie in ein Segment B hinein zu synchronisieren. Es ist dabei zu beach-ten, dass die Synchronisation immer nur in eine Richtung ausgeführt wird mit dem Vorteil, dass beliebige Synchronisationsvorgänge, auch Dreiecks-synchronisationen, aufgebaut werden können. Nachteilig wirkt sich dabei aus, dass für eine einfache Synchronisation zwischen zwei Segmenten zwei Synchronisations-Agenten benötigt werden.



Durch den Einsatz der RPD-Middleware konnte die gemeinsame Arbeit der RPD-Experten und die Benutzung des ASN nachhaltig verbessert wer-den. So wurde im Bereich der Informationsüberwachung die Möglichkeit geschaffen, Veränderungen im ASN aktiv und ohne zusätzlichen Auf-wand, 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 Ver-ständnis für die abgelegten Informationen frühzeitig aufgebaut werden kann. Durch den Transaktions-Agenten wird zusätzlich ein Transaktions-schutz bei der Eingabe aufgebaut, während der Aggregations-Agent die strukturierte Zusammenfassung von Suchergebnissen ermöglicht.

Der Themenschwerpunkt Koordination befasst sich mit der informati-onstechnischen Unterstützung des Produktentstehungsprozesses und nicht mit der Datenmanipulation. Durch das frei definierbare Koordinationspro-tokoll in Form eines Zustandübergangsdiagramms können Abstimmungs-vorgänge IT-technisch unterstützt werden ohne die Flexibilität des RPD-Prozesses einzuschränken.

Der Synchronisations-Agent als Strukturmaßnahme verbessert nachhal-tig die Anwendbarkeit des ASN. Er beschleunigt zugleich auch die Abar-beitung der Anfragen des Retrieval-Agenten und damit auch des Aggrega-tions-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 vernetz-tes Arbeiten

4.3.1 Einleitung

Die zunehmende Komplexität von Produkten und somit der Entwicklungs-aufgaben erzwingen eine Integration von Experten unterschiedlicher Fach-richtungen. Durch diese interdisziplinäre Zusammenarbeit sollen Syner-gien 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 integrie-ren. Die Lösung für die Unternehmen liegt im Aufbau organisationsüber-greifender, virtueller Teams, in die auch Lieferanten und Kunden einbezo-gen werden.

Zusätzlich erfordern die für eine schnelle Produktentwicklung charakte-ristischen Iterationszyklen eine Arbeitsweise, die sich wesentlich von der bisherigen, auf sequentieller Bearbeitung beruhenden, unterscheidet. Ins-besondere in modernen Entwicklungsprozessen (wie z.B. Simultaneous Engineering, Rapid Product Development), in denen keine konkreten Ab-sprachen und Entwicklungskonstellationen feststehen, müssen Gedanken und Modelle möglichst explizit kommuniziert werden, damit eine gemein-same Wissensbasis zwischen den multidisziplinären Experten aufgebaut werden kann [4.185]. Le Hen & Sorito [4.123] stellen jedoch in ihrer Ana-lyse folgende Defizite bei verteilter Kooperation in der Produktentwick-lung fest:

Kein einheitlicher und verbindlicher Kooperationsprozess vor dem „Start of Production“. Asynchrone Anbindung: Teilnehmer können auf wichtige Produktin-formationen erst zu spät zugreifen. Als Konsequenz sind häufige Rei-sen, Telefongespräche und Faxe notwendig, um Informationen zu be-kommen. Künftig sollen Teilnehmer früher auf 3D-Modelle zugreifen können.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.


Dadurch findet weitestgehend eine entkoppelte und dadurch sequentielle Produktentwicklung statt. Ein intensiver Austausch, der auf Strukturen ba-siert, die der Kommunikation in einer realen, nicht verteilten Arbeitssitua-tion 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 Herausforderun-gen an die heutige Produktentwicklung (Schnelligkeit, Komplexität) besser begegnen zu können. Neben der effizienten arbeitswissenschaftlichen Ana-lyse 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 Sup-ported Cooperative Work) und CMC (Computer Mediated Communicati-on) für geeignete Kommunikations- und Kooperationsinfrastrukturen un-tersucht und hinsichtlich des Einsatzes in der Produktentwicklung evaluiert worden. Hierfür wurden unterschiedliche Entwicklungsszenarien am Bei-spiel 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 Sin-ne des RPD berücksichtigen. Diese waren ausgelegt auf die Zusammenar-beit 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üg-barkeit die geeigneten Technologien auswählt.

In den Szenarien hat sich jedoch gezeigt, dass eine Ausweitung auf eine Team-Team-Zusammenarbeit, die technische und organisatorische Gren-zen ü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 Multi-Team Plattform, die Umsetzung eines situativ unterstützenden Sitzungs-managements, die Erarbeitung technischer Lösungen für dynamisch aufge-stellte, verteilte Teams und die Realisierung einer prototypischen Koopera-tionsplattform. Diese Plattform kommuniziert über die Agenten der Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrationsplatt-

4.3 Teamorientiertes Kommunikationssystem für vernetztes Arbeiten 269

form für aktive Wissenskommunikation im Rapid Product Development“) mit dem ASN (Kap. 4.1 „Ganzheitliche Modelle zur Repräsentation akti-ven Wissens“) und wurde in das RPD-Portal (Kap. 4.4 „Adaptive Benut-zungsoberflächen“) integriert. Die Plattform stellt folgende Komponenten zur Verfügung:

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 Umge-bung geladen werden. Ebenso besteht die Möglichkeit Powerpointprä-sentationen zu importieren [4.192]. Ein sprechakt-basiertes Nachrichtensystem für die asynchrone Kommu-nikation. Das Nachrichtensystem erweitert herkömmliche E-Mail-Funktionalitäten um personen- und kontextrelevante Parameter. Durch die einheitliche und strukturierte Ablage von Informationen und die In-tegration von zeitlichen und inhaltlichen Parametern in die Nachricht (Antwortzeit, Sprechakt, etc.), unterstützt dieses System effektiv die un-terschiedlichen 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]. Eine Groupware-Anwendung, die herkömmliche Tools wie Gruppenka-lender, 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üh-rende Integration mit den anderen RPD Applikationen im Mittelpunkt. Zu-sammen 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 End-geräte und die damit zusammenhängende Nutzung von Augmented Reali-ty-Funktionen im Entwicklungsprozess (in Zusammenarbeit mit dem Teil-projekt „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.


In Zusammenarbeit mit Teilprojekt „Planungsmethoden für dezentrale Entwicklungsteams“ (Kap. 2) wurde für das Kooperationssystem an einem Kommunikationsmanagement (z.B. Abbildung von Kommunikations-Workflows) gearbeitet, das die unstrukturierten Kommunikationsabläufe im RPD besser handhabbar macht. Daneben wurde die sprechakttheoreti-sche 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 ver-stärkt auch die Agenten aus Kap. 4.2 „Agentenbasierte Middleware als In-tegrationsplattform für aktive Wissenskommunikation im Rapid Product Development“ eingebunden.

4.3.3 Stand der Forschung

Die Arbeiten für teamorientierte Kommunikationssysteme liegen im For-schungsgebiet der Computer Supported Cooperative Work (CSCW). Als interdisziplinäres Forschungsgebiet integriert die CSCW-Forschung ver-schiedene sozial-, ingenieurwissenschaftliche und technische Disziplinen. Da – wie oben geschildert – für das teamorientierte Kommu-nikationssystem verschiedenartige Ausprägungen von CSCW-Anwen-dungen prototypisch entwickelt wurden, soll hier, anstelle eines allgemei-nen Ü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 Envi-ronments, 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 The-mengebiets gegeben werden.

Collaborative Virtual Environments (CVE)

„Collaborative Virtual Environments“ (CVE) sind integrierte kooperative Systeme, die sich durch zwei wesentliche Eigenschaften von herkömmli-chen CSCW-Anwendungen (z.B. MS Exchange) unterscheiden:

die RaummetapherIm Gegensatz zu CSCW-Anwendungen, die die Desktopmetapher nut-zen, um verschiedene Systeme (E-Mail, Audio-/Videokonferenz etc.) zu integrieren, findet bei CVE die Integration der Systeme in einem Raum


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 virtu-ellen Raums gemeinsam nutzbar. D.h. hier wird die ursprünglich für Einzelarbeitsplätze entworfene Desktopmetapher auf mehrere Arbeits-plä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. AvatareAvatar (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 Ava-tar wird eine Person in einem virtuellen Raum repräsentiert, andere Per-sonen, die sich in dem gleichen Raum befinden, können durch ihre Ava-tare wahrgenommen werden.

Einer der Hauptgründe für die Entscheidung, das teamorientierte Kom-munikationssystem 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 Ob-jekte oder deren Repräsentationen helfen bei diesen Tätigkeiten durch eine Möglichkeit der visuellen oder haptischen Wahrnehmung des Erschei-nungsbildes bzw. der physikalischen Eigenschaften. Sie dienen der seman-tischen Repräsentation ihrer räumlichen Verhältnisse (auch zu anderen Ob-jekten) und ihrer Eigenschaft, die Aufmerksamkeit der Benutzer auf sich zu ziehen. Diese Objekte sind mehr als nur Informationsquellen; sie kon-stituieren die kooperative Aktivität, indem sie einen Bezugsrahmen für Kommunikation und Gruppeninteraktion schaffen [4.136].

Diese Erkenntnisse wurden im Visual Engineering umgesetzt. Die For-schung 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 Untersu-chung mit Gestaltern und Ingenieuren aus Designbüros und der Automo-bilindustrie 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,


um einen Interpretations- und Transformationsspielraum, der für die Iden-tifikation 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 Tele-Working und virtueller Präsenz, d.h. arbeitswissenschaftlichen Frage-stellungen, zum anderen auf der Erprobung unterschiedlicher Netzwerk-technologien für den Anwendungsfall einer verteilten Mehrbenutzer VR-Umgebung [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 Experi-mente anhand von drei Szenarien mit unterschiedlichen CVE-Applikationen in Verbindung mit AR-Technologien durch:

Ein Sicherheitsszenario, in dem Mitarbeiter die räumlichen Charakteris-tika einer großen industriellen Anlage verstehen mussten, um die Kon-sequenzen für sicherheitsrelevantes Verhalten von Menschen, die in die-ser Umgebung leben und arbeiten, besser beurteilen zu können.Ein Szenario, in dem Designer sich in einem virtuellen Raum treffen, um ein Design zu besprechen bzw. damit zu interagieren (haptisches feedback).Ein Szenario, in dem mehrere Personen etwas gemeinsam erstellen. Während dieser Experimente wurde das soziale Verhalten der Proban-den und deren Performanz, die verschiedenen Aufgaben betreffend, un-tersucht [4.178], [4.182], [4.183].

In diesem letzten der auf DIVE basierenden Projekte wurden massive technische Probleme bei der simultanen Manipulation von Objekten fest-gestellt. 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 ge-nannten Projekten wird hier speziell auf den Anwendungsbereich der Pro-duktentwicklung, insbesondere des Rapid Product Development, fokus-


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 kooperations-unterstützender Werkzeuge. Ishi [4.99] definiert „seam“ als eine räumli-che, 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 Ar-beit, zwischen asynchroner und synchroner Kommunikation oder zwischen konventioneller Software und Groupware. Neuere Forschungen beschäfti-gen 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 For-schung 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 Benutzungsober-flä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 U-ser 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 Simulatio-nen dem Benutzer zugänglich gemacht werden. Ein real vorliegendes Ob-jekt 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 Tren-nung zwischen realer und virtueller Welt verschmelzen und bietet neben einer großen Immersion auch die Möglichkeit zur Umsetzung völlig neuer


kooperativer Entwicklungsszenarien, z.B. die Zusammenarbeit an hybriden Prototypen.

Im Projekt ARVIKA werden Augmented-Reality-Technologien zur Un-terstü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 rechnergenerier-ten virtuellen Objekten erlauben Augmented Reality-Techniken im Sinne einer erweiterten Realität das situationsgerechte Agieren in realen Arbeits-umgebungen.

Das Projekt ARVIKA kam bisher zu folgenden Erkenntnissen: Aug-mented 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 AR-Techniken beim Vergleich von Crash-Ergebnissen genannt. Nach einem Crashtest überlagert das AR-System im Sichtfeld des Entwicklungsingeni-eurs 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 AR-Technologien auch kooperativ sinnvoll genutzt werden können. Interessant ist in diesem Zusammenhang eine Untersuchung von [4.75], der die An-wendungsmöglichkeiten von AR beim telekooperativen Lernen untersuch-te. 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 von-einander getrennt sind. Die Einsatzmöglichkeiten und möglichen Anwen-dungsszenarien für AR im verteilten kooperativen Arbeiten in der Pro-duktentwicklung 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 um-gesetzt (Kap. 4.3.5 „Ergebnisse“).

Gesprächsunterstützende Techniken

In multidisziplinären Teams klagen die Mitglieder häufig über Verständ-nisprobleme und mangelnde Offenheit gegenüber ihren Ansichten [4.48].


Die Verwendung von Fachsprachen und die unterschiedlichen Lösungsan-sätze der Fachgebiete führen häufig zu Nicht- oder Missverstehen und ver-hindern die Entwicklung einer übereinstimmenden Vorstellung von der gemeinsam zu lösenden Aufgabe. Steinheider und Bayerl [4.186] unter-suchten 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 he-raus, dass eine ausgeglichene Kommunikationsstruktur (gleiche Ge-sprächsbeteiligung aller Teammitglieder) sowie die Visualisierung von Zu-sammenhä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äu-fig angewandt wird und immer mehr an Bedeutung gewinnt, werden ge-sprächsunterstützende Techniken, die eine ausgeglichene Kommuni-kationsstruktur 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 asyn-chrone Kommunikationsmöglichkeiten und die Begehbarkeit einer virtuel-len Lernumgebung auszeichnet, jedoch als technische Ausstattung ledig-lich 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 betriebli-chen Situation durch Moderation vorsieht. Erste Ergebnisse zeigen, dass Moderationstechniken auch in virtuellen Umgebungen erfolgreich ange-wendet 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 vor-hersagbare als auch nicht vorhersagbare Zusammenhänge. Im Verlauf ei-ner 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


Beteiligten und deren jeweilige Handlungsumwelten. Zusammen ergibt sich ein veränderliches Kommunikationsumfeld. Daher kann von komple-xen Vorgängen (Systemen) gesprochen werden, die meist diskontinuierlich sind und sich in ihrer Heterogenität aus vielen kleinen simultanen Einzel-prozessen zusammensetzen [4.194]. Das bedeutet, dass deren Wechselwir-kung untereinander nicht fest verbunden ist, so dass ein Gesamtprozess un-terschiedliche Entwicklungen nehmen kann. Der Begriff Emergenz bedeutet ein „Springen“ oder „Auftauchen“ von Ereignissen und Entwick-lungen 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 einfa-chen Zusammenhängen hervorgehen können. Der Begriff der Emergenz stammt aus der Evolutions- und Systemtheorie und beschreibt einen rekur-siven Prozess von Selektion (Auswahl), Mutation (Veränderung) und Re-stabilisierung (Wiederherstellung). Es tritt ein nicht vorhersagbarer Zu-stand ein, dessen Vorgeschichte wiederum nicht ableitbar ist.

Man unterscheidet harte und weiche Emergenz. Bei der weichen Emer-genz wird eine gewisse Deduzierbarkeit angenommen. Bei der harten E-mergenz wird eine Deduzierbarkeit ausgeschlossen [4.194].

Emergenz in der Kommunikation Vergangenheit Zukunft weiche Emer-

genz harte Emer-

genz weiche Emer-

genz harte E-

mergenz Rückverfolgung von Partnern und Hergang heutiges Ziel ab-leitbar aus der Kommunikation es muss nicht der gesamte Hergang sichtbar sein, je-doch die Prozess-struktur

keine Rückver-folgung von Partnern und Hergang heutiges Ziel nicht ableitbar Notwendigkeit der Explizie-rung von Rand-bedingungen gesamter Pro-zess muss sichtbar sein, damit er nach-vollzogen wer-den kann

gerichteter Pro-zess – Ziel ist definiert Ablauf richtet sich nach einem groben Workflow Ansprechpart-ner werden nach Fachdis-ziplinen aus-gewählt

Ziel ist nur grob defi-niert Ansprech-partner wechselnim zeitli-chen Ver-lauf keine De-termi-nierbarkeit

Abb. 4.30. Emergenz in der Kommunikation


Die Unterscheidung in harte und weiche Emergenz ist im weiteren Ver-lauf der Betrachtung der Kommunikation im RPD hilfreich, da diese hier-mit weiter strukturiert werden kann. Abbildung 4.30 zeigt eine Aufschlüs-selung 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 Pro-zesse 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 zusammen-geführt worden sind. Die harte Emergenz beschreibt somit die Ausgangssi-tuation, unter der im Rahmen des RPD kommuniziert werden muss. Ein Weg, speziell für die asynchrone Kommunikation, emergente Kommuni-kation zu strukturieren, ist die Erarbeitung von Sprechakten, die helfen, Probleme, Wirkzusammenhänge und intendierte Handlungen zu beschrei-ben.

Sprechhandlungen können als Basis dienen, die Kommunikationsanfor-derung 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 ei-ner Drohung haben können. Jede Reaktion auf einen Kommunikationsakt hält sich an (implizite) Konventionen (Kontingenz), nach denen diese er-folgen sollen. Daher sind Sprechen, Handeln, Situationsbezug, Erfahrung und die Einflüsse aus der umgebenden Realität immer unauflösbar mitein-ander 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 hervorgeru-fen. 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-


taktpartner gegeben ist. Um die Differenzen zu vermindern ist eine gleich-gewichtige Explizierung beiderseitiger Bedingungen erforderlich. Diffe-renzen zwischen dem Sprechakt (mündliche Kommunikation) und dem Schreibakt (schriftliche Kommunikation) sind von Henne [4.88] näher un-tersucht worden. Er weist darauf hin, dass dem Sprechakt die weitergehen-de Eigenschaft der Spontanität unterliegt. Der Schreibakt kann hingegen rückgängig gemacht werden, solange die Aufzeichnung noch nicht ver-sandt 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:

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. 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. Der perlokutionäre Akt beschreibt die vom Sender beabsichtigten Effek-te des Sprechaktes auf die Empfänger. Somit ergeben sich Konsequen-zen 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 Sen-ders 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 Kommunikati-onsbrüche dar. Somit muss versucht werden, eine Gleichheitsbeziehung zwischen den beabsichtigten und den eintretenden Effekten einer Sprech-handlung bei asynchroner Kommunikation zu erreichen. An dieser Stelle werden die Anforderungen an das Team und die wissensintegrativen Pro-zesse deutlich. Durch die unterschiedlichen Verstehenswelten besteht so-wohl in der Teamkonstellation als auch bei der Wissensintegration die Ge-fahr, dass ein perlokutionärer Akt missglückt und damit die vom Sender begonnene kommunikative Handlung nicht den gesetzten Erwartungen des


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 ver-meiden und somit effizienter zu kommunizieren. Zusätzlich wurde zurück-gegriffen 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 soft-waretechnisch umzusetzen.

Workflow-Systeme helfen dort, wo standardisierte Abfolgen existieren und bekannte Prozesse und deren Einflüsse genutzt werden können. In die-sem Zusammenhang bedeutet das Management eines Workflows die Mo-dellierung, Optimierung und Automatisierung von Geschäftsprozessen. Gemeint sind sämtliche Prozesse, die im Rahmen eines betrieblichen Um-feldes anfallen und zu einem definierten Ziel hin ablaufen.

Auch für die Kommunikation in der Produktentwicklung spielt ein si-tuativ strukturierter Ablauf eine wichtige Rolle. Hierdurch können Infor-mationswege minimiert und die Nachrichten gezielt an weiterverarbeitende Instanzen (Agenten, Experten) weitergeleitet werden. Für die nur schlecht standardisierbaren Prozesse in der evolutionären Produktentwicklung bie-tet sich die Umsetzung eines kommunikationsbasierten Workflows im Ge-gensatz zum Aktivitäten gesteuerten Workflow an. Der Aufbau eines sol-chen 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 Sys-tem) war es, Diskussionsvorgänge zu archivieren und mittels einer forma-len Struktur übersichtlich darzustellen [4.115]. Hierdurch sollten Diskussi-onen 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:

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 mitein-ander verknüpft, sodass sie den evolutionären Prozessen nicht gerecht werden.


Der Prototyp SEPIA ist ein hybrides Argumentationsstrukturierungs-programm. 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. Das System COSMOS (Configurable Structured Message Oriented Sys-tem) unterstützt, basierend auf der Sprechakt-Theorie, die Kommunika-tionsvorgä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 Anfor-derungen 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 ver-teilte 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 fin-den. 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 Arbeits-prozessen 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 Do-kumentenflüsse analysieren, da sich diese dynamisch im evolutionären Fortschritt der Zusammenarbeit ändern. Für die Realisierung der Koopera-tionsplattform wurde daher ein experimenteller Ansatz gewählt, um auf Anwenderrückmeldungen effektiv reagieren zu können. Angestrebt war die anwendungsorientierte Entwicklung von Kommunikations-


Basistechnologien unter Berücksichtigung von Benutzeranforderungen bei der ergonomischen Gestaltung von interaktiven Systemen.

Die Vorgehensweise wurde an ISO 13407 „Benutzergerechte Gestal-tung interaktiver Systeme“ angelehnt und umfasst die fünf Phasen

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 Uni-fied Modeling Language (UML)-Verfahren bzw. Softwaretestverfahren zum Einsatz [4.20], [4.73]. Den methodischen Kern der Arbeit bilden be-nutzerzentrierte Verfahren des Usability Engineering und Testing. Grund-lage dieser Verfahren ist ein partizipativer und iterativer Ansatz. Die Ent-wicklung 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 zwi-schen verschiedenen Unterstützungsmöglichkeiten handelt, kann lediglich die Ausführung der einzelnen Arbeitsschritte sowie das erreichte Gesamt-ergebnis 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 Inspec-tion 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 Konzeptio-nierung kooperativer Arbeitsformen für die Entwicklung innovativer Pro-dukte“ (Kap. 2) entwickelten Kooperationsmodell wurde ein erster Proto-typ der Kooperationsplattform als „Proof of Concept“ entwickelt [4.192], [4.196]. Dieser Prototyp wurde in einer WAMP-Umgebung (Windows Be-triebssystem, Apache Web Server, MySQL Datenbank, PHP Scriptspra-che) und der SCOL-Entwicklungsumgebung für Mehrbenutzer 3D-


Umgebungen implementiert. Die Entscheidung zugunsten von SCOL ge-genüber VRML-basierten Formaten fiel insbesondere aus zwei Gründen:

Das SCOL-Format erwies sich als wesentlich performanter im Betrieb über das Internet als die VRML Systeme (SGI Cosmo, blaxxun, etc.) Die SCOL-Umgebung bietet neben einer Mehrbenutzerfähigkeit auch eine Menge integrierter Kommunikationsmodule (Chat, Instant Messa-ging Audio/Videokonferenz). Diese Funktionen konnten bei den ande-ren betrachteten Systemen nur durch zusätzliche Programme bzw. Plug-ins realisiert werden.

Der entwickelte Prototyp stellt neben den oben genannten Kommuni-kationstechnologien 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 asyn-chrone Kommunikation stand ein datenbankbasiertes Nachrichtensystem zur Verfügung. Teamstrukturen, Mitarbeiterprofile und der Status der Mit-arbeiter 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 aufge-nommen, 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 gela-den werden konnte, konnte nur eine begrenzte Auswahl von Objekten be-trachtet 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 virtu-ellen 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 „Ganz-heitliche Modelle zur Repräsentation aktiven Wissens“) bzw. die entwi-ckelte agentenbasierte Middleware (Kap. 4.2 „Agentenbasierte Middlewa-re als Integrationsplattform für aktive Wissenskommunikation im Rapid Product Development“) und umfasst folgende Bestandteile:


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, so-dass dem Anwender ein Information und Kommunikation integrierendes System zur Verfügung steht, auf das benutzerfreundlich über eine einheit-liche Webschnittstelle zugegriffen werden kann (s. Abb. 4.31.).

Bei den Groupwareanwendungen und dem Audio-/Videokonferenz-system wurde auf bestehende Softwarelösungen zurückgegriffen. Die fol-gende Darstellung konzentriert sich auf die Eigenentwicklungen für das teamorientierte Kommunikationssystem.


Dreidimensionale Teamräume

Ziel bei der Realisierung war es, ein erweiterbares Multi-User-System zu schaffen, in das einfach weitere Funktionalitäten und Applikationen einge-bunden werden können. Aus diesem Grund wurde eine Kernanwendung entwickelt, die es erlaubt, zusätzliche Funktionalitäten in Form von Plug-Ins zu programmieren und anzuschließen.

Die Anwendung wurde in Java unter Verwendung der Java 3D-API ge-schrieben. 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 (Kartenab-frage, 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 ers-tellen 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 Interakti-onsdaten in verteilten 3D-Anwendungen. Die Implementierung, die client-seitig hinter den einzelnen Tags gehalten werden, sind in Java realisiert. Die ankommenden XML-Dokumente werden von einem SAX Parser aus-gewertet. Nach Benutzer-Tags getrennt wird dann intern eine Datenstruk-tur 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 Proto-koll 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öglich-keiten.

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


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 arbeits-relevante Informationen visualisiert und Teambesprechungen durchgeführt werden können.

Der Arbeitsplatz (s. Abb. 4.32.) eines Teammitglieds zeigt im Falle sei-ner 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 ver-schiedene vordefinierte Stati und zusätzlich eine freie Eingabe anbietet. Der Benutzer kann zudem eingeben, wo und auf welche Weise er zu errei-chen 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, Anzei-getafeln, persönliche asynchrone Groupwarekomponenten und Screenshots seines Bildschirms laden.

Abb. 4.32. Arbeitsplatz mit Visualisierung der aktuellen Bildschirmansicht


Im Teambereich (s. Abb. 4.33.) können team- bzw. projektrelevante In-formationen ü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 arbei-tenden Teams im RPD zeigt sich, dass bei herkömmlichen Kommunikati-onssystemen (basierend auf E-Mail) ein Defizit hinsichtlich der Explizie-rung 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 „reich-haltigeres“ Werkzeug, insbesondere im Hinblick auf die zeitliche und in-haltliche 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-


tern in die Nachricht (Antwortzeit, Sprechakt, etc.), unterstützt dieses Sys-tem 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 übertra-gen werden müssen.

Im Folgenden wird das Modul des asynchronen Nachrichten-Systems als Software-Prototyp mit seinen Funktionalitäten näher erläutert. Entspre-chend der Kodierung bei einer E-Mail Adresse wird der Nutzer personali-siert über seinen Namen und seinen Lokalisierungsbereich (na-me@domain) definiert. Diese Kennung hat den Vorteil, dass anhand der Systemadresse bereits klar ist, um wen es sich handelt. Anhand der Lokali-tät ist eine eindeutigere Identifizierung der Person möglich. Die zusätzli-che 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:

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 kon-tinuierlicher Pflege dieser Daten ergibt sich ein Leistungsportfolio des Nutzers, das es ermöglicht, die eigenen Wissensbereiche dem Team zu vi-sualisieren. 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.


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 befin-den sich gesammelt in der obersten Struktur, können aber auch direkt sor-tiert nach den Bereichen eingesehen werden, sofern diese vom Sender spe-zifiziert wurden. Die Struktur der Ordner ist für alle Teammitglieder die gleiche und wird vom Administrator bzw. Nutzer mit Administrator-Rechten festlegt. Hierdurch wird vermieden, dass zum gleichen Thema un-terschiedliche 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 Kontingen-zen wird in einem gemeinsamen Workshop vorgenommen und in Form ei-


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 fin-den sind) werden hier weitere Informationen hinzugefügt. Die Felder er-möglichen die Zuordnung der Nachricht zu den definierten Projektberei-chen, 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 Informati-onen 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


des Administrations-Werkzeuges vordefiniert. Hierdurch wird ein einheit-liches 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 unter-schiedliche 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 ge-meinsame Groupware.

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

Unterstützung von Terminabsprachen durch den automati-schen Terminplaner

Terminabsprachen sind zeitaufwendig. Die Automatisierung bestimmter Teile einer Terminabsprache, wie z.B. der Suche nach einem freien Zeit-punkt 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 al-le Beteiligten wesentlich reduzieren.

Für das teamorientierte Kommunikationssystem wurde in Zusammen-arbeit mit der Entwicklung der RPD-Middleware (Kap. 4.2 „Agenten-basierte Middleware als Integrationsplattform für aktive Wissens-kommunikation im Rapid Product Development“), die Agenten zum Auffinden und Koordinieren von Daten, die im ASN abgelegt sind, bereit-stellt, prototypisch eine Software entwickelt, die einen großen Teil der Terminplanung automatisiert. Der Prototyp ermöglicht es, die Termine ei-ner beliebigen Anzahl Teilnehmer zu koordinieren. Dabei werden ver-schiedene Parameter wie z.B. Ort (online, im Haus, regional, national, in-


ternational, Berücksichtigung der Reisezeit), benötigte Ressourcen (Raum, Tafeln, Beamer, etc.), Thema (Einladung zusätzlicher Experten) berück-sichtigt. 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 In-tervall, 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ögli-chen Terminen suchen. Eine anwendungsinterne Logik steuert die Rück-gabedaten der Agenten und setzt den neuen Termin fest. Wenn ein Termin


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 fehlgeschla-genen Terminfestlegung informiert.

Weitere Funktionen (Termindaten ändern, Teilnehmer entfernen, Ter-min 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 „Visuali-sierung und Simulation physikalisch-technischer Vorgänge“ (Kap. 5.5) be-gonnen worden.

Durch die von diesem Teilprojekt entwickelten AR-Methoden lassen sich bestehende Produktentstehungsvorgänge weiter beschleunigen. Ent-wickler können gemeinsam über dasselbe Bauteil diskutieren und Design-fragen klären. Beispielsweise können Materialeigenschaften wie Farbe o-der Oberflächenstruktur während der Simulation verändert werden. Ebenso


ist es möglich, bewegliche Teile, Umformprozesse oder Strömungsverläu-fe zu simulieren.

Allerdings mussten sich die Teilnehmer dazu an einem gemeinsamen Standort versammeln. Ziel der Arbeiten am teamorientierten Kommunika-tionssystem war es, einerseits die Software so zu erweitern, dass koopera-tive AR an verteilten Standorten ermöglicht wird und andererseits das Sys-tem 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 Mar-ker 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 al-le 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, Frame-rate 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 Kommunikations-prozess 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 zeitli-chen Barrieren zu minimieren.

Ein Prototyp für ein integriertes Kommunikationssystem für vernetztes Arbeiten wurde realisiert. Die durchgeführten Forschungs- und Entwick-lungsarbeiten 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 Zusammen-arbeit, sofern dem Nutzer keine Hilfsmittel gegeben werden, diese Kom-


plexität zu reduzieren. Um Komplexität beschreiben zu können, wurde un-ter 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 expli-zit übertragen werden, werden intendierte Handlungen mit überliefert. Hieraus ergeben sich einheitliche Verhaltensmuster im Team, die zu weni-ger 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 Gruppenwahr-nehmung relevante Informationen erweitert. Die Software baut auf den gemeinsamen Informationen aus dem ASN, der Datenbasis für kommuni-kationsrelevante Daten, einem Webserver, zur Erreichbarkeit über das In-ternet, und Java Server Pages (JSP)-Skripten, zum Aufbau semistrukturier-ter 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 Zusam-menarbeit mit der Entwicklung der RPD-Middleware (Kap. 4.2 „Agenten-basierte Middleware als Integrationsplattform für aktive Wissenskommu-nikation Rapid Product Development“) ein System zur automatischen Terminplanung entwickelt. Das System nimmt Terminwünsche unter Be-rücksichtigung von Zeit, Ort (Anreisezeit), benötigten Ressourcen und e-ventuellen 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 Arbei-ten zur Unterstützung der Gruppenwahrnehmung (Awareness) die Schwerpunkte auf der Entwicklung verteilter Präsentations-, Moderations- und Visualisierungswerkzeuge. Diese Werkzeuge dienen der Kommunika-tionsstrukturierung und der Veranschaulichung von Sachverhalten, beides wichtige Vorraussetzungen für eine gelungene Kommunikation und Wis-sensintegration in multidisziplinären Teams. Es wurde ein 3D-Multi-User-System entwickelt, das es verteilt arbeitenden Teams erlaubt, sich an ei-nem virtuellen Arbeitsplatz zu treffen, multimodal zu kommunizieren und Besprechungen zu strukturieren. Von entscheidender Bedeutung im itera-tiven 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 XML-basiertes Protokoll entwickelt, das als Schnittstelle zu anderen Applikatio-nen 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 er-möglicht damit eine bessere Orientierung bei der Team-Team-Kooperation. Darüber hinaus wird das Auffinden und das sofortige Kon-taktieren relevanter Ansprechpartner erleichtert.

Die Werkzeuge für die asynchrone und synchrone Kommunikation wurden vollständig integriert und somit ein nahtloser („seamless“) Über-gang 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 Adaptive Benutzungsoberflächen

4.4.1 Einleitung

Die sehr heterogene, interdisziplinäre Arbeitsumgebung des Rapid Product Development (RPD) erfordert den Entwurf und die Realisierung von fle-xiblen und dynamischen Arbeitsumgebungen mit einem übersichtlichen Zugang zu den darin abgebildeten Informationsräumen. Eingebettet in dy-namische 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 ver-schiedene Disziplinen und Kompetenzen. Weiterhin unterscheiden sie sich durch unterschiedliche Qualifikationen und Ziele [4.184]. Ziel ist die op-


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 Informa-tions- und Problemlösungsangebote führt zum Modell des adaptiven web-basierten 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 Informati-onen 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 Stan-dard 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 Anpas-sung sowie die Unabhängigkeit von Betriebssystemen. Damit ist jedem Nutzer der Zugriff von einem beliebigen, mit einem Browser ausgestatte-ten 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übersicht-lichkeit führen.

Die Gestaltungsanforderungen an ein Portal als Informationszugang sind [4.208]: hohe Benutzungsfreundlichkeit, fortwährende Aktualität, ho-her Informations- und Nutzengrad sowie Individualisierbarkeit und Inter-aktivität. Ebenfalls zu berücksichtigen ist eine adäquate Anpassung der Hardware, um ausreichende Schnelligkeit zu gewährleisten.


Dialoggestaltung

Die Kommunikation zwischen Mensch und Rechner erfolgt in Form eines Dialoges. Grundsätze der Dialoggestaltung sind: Aufgabenangemessen-heit, Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität und Fehlerrobustheit [4.53], [4.207]. Eine angemessene Dialoggestaltung sollte ferner das Einbringen des individuellen Erfahrungs- und Hand-lungswissens unterstützen sowie Besonderheiten und Präferenzen von Be-nutzern beachten. Der Dialog zwischen Mensch und Maschine muss in Aufbau und Ablauf an die zu unterstützenden Aufgaben und Prozesse so-wie 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]:

Humanorientierte Kriterien wie Bedürfnis nach Durchschaubarkeit, Vorhersehbarkeit und Beeinflussbarkeit der Arbeitsbedingungen, Frei-heitsgrade bei der Aufgabenbearbeitung, minimales Beanspruchen men-taler Kapazität durch den Dialog, individuell unterschiedliche Denk- und Arbeitsstile, individuelle Kenntnisse und Dialogerfahrungen, Aufgabenbezogene Kriterien wie Benutzungshäufigkeit, Benutzungs-intensität, Benutzungsregelmäßigkeit bei der Aufgabenbearbeitung so-wie die Aufgabenkomplexität, 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 be-wahren. Andererseits soll sie den Benutzern die Inanspruchnahme von In-formationen und Werkzeugen zu jedem Zeitpunkt ermöglichen. Die Ent-scheidung, ob eine Adaption in der vorgeschlagenen Weise durchgeführt wird, sollte letztlich in jedem Fall beim Nutzer liegen. Bei Nutzervor-schlägen muss vom System deren Realisierbarkeit geprüft werden. Dage-gen 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ücksich-tigen [4.7], [4.95], [4.85]:

Funktionalität (Grad, zu dem ein System vorgesehene Aufgaben ange-messen übernimmt bzw. bearbeitet): Der Funktionalitätsgrad sollte auf


der Basis einer Aufgaben-Analyse durch die Benutzer selbst festgelegt werden können. Konsistenz (Zuverlässigkeit bzw. Berechenbarkeit des System-verhaltens): Die Erwartungen der Benutzer sollen erfüllt und Überra-schungseffekte vermieden werden. Einheitlichkeit im Design und regel-hafte Gestaltung tragen zur Gedächtnisentlastung bei. Flexibilität (Ausmaß der Beeinflussbarkeit des Systemverhaltens im Sinne objektiv vorhandener Freiheitsgrad): Die Steuerung des Dialogab-laufs sollte den Benutzern weitestgehend überlassen werden, um unter-schiedliche 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 Anwen-dungsbereich ab. Burmester und Komischke [4.33] verlangen eine starke Nutzerführung beim Einsatz in der industriellen Prozessführung, gleichzei-tig jedoch Flexibilität in dem Sinn, dass die Nutzeroberfläche an verschie-dene Nutzerklassen anpassbar sein sollte. Unter dem Aspekt der Konsis-tenz 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. Bur-mester et al. [4.34] zeigen, dass die Aspekte der ästhetischen Form in der Beurteilung von Interfaces vor allem in die Faktoren Qualität und Brauch-barkeit 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:

Die interaktive, echtzeitfähige Anwendung von Visualisierungs-methoden. Diese ermöglicht eine schnelle Reaktion auf die Ergebnisse von Analysen und Änderungen anderer Teammitglieder. Die individuelle Kombination verschiedener Visualisierungsmethoden zur Erkundung des Informationsraums auf verschiedenen Abstraktions-ebenen und in variablen Detaillierungsgrad [4.76]. 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 da-her sowohl für die Bedienung des Systems als auch für die Informati-onspräsentation eingesetzt werden.


Adaption

Diese arbeitswissenschaftlichen Erkenntnisse fordern eine adaptierbare und adaptive Gestaltung von Dialogschnittstellen, insbesondere unter Be-rücksichtigung von Kooperationsaspekten [4.68].

Bei der Gestaltung adaptiver oder adaptierbarer Systeme stellt sich im-mer auch die Frage nach der Benutzungsfreundlichkeit. Hier muss abge-wogen werden zwischen der Übernahme von Aufgaben durch das System zur Arbeitserleichterung für den Nutzer und dem Beibehalten der Kontrol-lierbarkeit durch den Nutzer. Zur Untersuchung der Nutzungsfreundlich-keit 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] grundle-gende Anforderungen an personalisierte Benutzungsoberflächen, deren Be-rücksichtigung als Voraussetzung für die Nutzungsakzeptanz gesehen wird. Diese sind:

Gewährleistung eines guten „ersten Eindrucks“. Dies bedeutet leichte Orientierung und wenig Lernaufwand, um schnell die angebotenen In-formationen nutzen zu können. Schnelle Anpassung an wechselnde Interessen. Vermeidung des „Tunnel-Blicks“, also eine zu große Einschränkung des Nutzers.Vermeidung von Mehraufwand für den Nutzer, in dem Sinne dass der Nutzer nicht aufgefordert wird, bspw. Metainformationen explizit ein-zustellen.Vermeidung von „Brüchigkeit“. Aktionen des Nutzers sollten keine gravierenden, nicht umkehrbaren Konsequenzen nach sich ziehen. Angebot mehrerer Einstiegspunkte zur Information. 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 über-prüft werden. Üblich sind hierbei Interviews oder Richtlinien; es existieren jedoch auch Tools zur systematischen Überprüfung der Benutzungsfreund-lichkeit von Benutzungsoberflächen, wie bspw. in [4.206] vorgestellt. Die-se nehmen keinen speziellen Bezug auf Anforderungen, die an adaptierba-re Oberflächen gestellt werden müssen. Im Wesentlichen sind die


Vorgehensweisen jedoch übertragbar und somit auch in diesem Teilprojekt anwendbar.

Die Adaption einer Oberfläche empfiehlt sich aus verschiedenen Grün-den [4.150]: Unterschiedliche Nutzer haben unterschiedliche Ziele (Adap-tion an die Aufgabe bzw. Sicht), derselbe Nutzer benötigt zu verschiede-nen Zeitpunkten unterschiedliche Informationen (Adaption an den Prozess), die Oberfläche soll funktional wachsen können (individuelle A-daption).

Dabei sollten folgende Kriterien berücksichtig werden: dem Nutzer soll-te keine zusätzliche Arbeit entstehen, die Benutzung sollte für jede Art von Nutzer vereinfacht werden, einschließlich Anfänger, Experten und Gele-genheitsnutzer. Der Zugang zu anderen Oberflächen und Applikationen sollte gewährleistet sein, ohne dass irgendwelche Meta-Informationen be-reitgestellt werden müssen. Der Mensch als Administrator muss die letzte Kontrolle behalten. Unter Berücksichtigung dieser Kriterien wird die O-berfläche in Form der Szenen an den Experten und den Problemlösungs-prozess 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“, „Wor-an“, „Warum“ und „Wie“ angepasst wird. Diese Unterscheidung ist sicher auch für die Entwicklung eines RPD-Portals relevant und hilfreich, um un-terschiedliche Ebenen und Aktionen zu spezifizieren.

Diese Klassifikation lässt sich durch die Dimension „mit Hilfe welcher Technik angepasst wird“, erweitern. Luedi stellt dazu verschiedene Tech-niken vor (s. Abb. 4.39.). Mit Hilfe der Unterscheidung zwischen benut-zergesteuerter und systemgesteuerter Auswahl gibt er eine Übersicht über Personalisierungstechniken:

Techniken zur Personalisierung Push mittels Agenten Pull vom Benutzer

System gesteu-ert

Benutzer gesteu-ert

System gesteuert Benutzer gesteu-ert

Rule based matching

Konfigurierbare „Agenten“

Kategorisierte Benutzer

Profilgenerierung nach Auswahl-menü

Lernen durch Benutzerver-halten

Rankings „Playback“ Volltextsuche

Collaborative Fil-tering

Collaborative Fil-tering

Abb. 4.39. Personalisierungstechniken [4.131]


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 ver-schiedenen Rechten und Pflichten bei der Nutzung einer Kommuni-kationsplattform und mit der zur Verfügungstellung entsprechender Funk-tionen 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 „Tu-tor“). 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 Mit-glied des Betriebsrats gewählt worden (bedingungsabhängige Rolle „Be-triebsratsmitglied“).

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 Umge-bung 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 wer-den, 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 (VDI-Norm) mit Aufgaben und Informationsbausteinen auf die Rollen, um so einen Zusammenhang zwischen Informationsbausteinen und Rollen her-stellen zu können.

Unterschiedliche Rollen im Produktentwicklungsprozess lassen sich insbesondere über die Zuordnung zu den unterschiedlichen Unterneh-mensbereichen 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 In-tensität. Dies bringt mit sich, dass auch die Informationsflüsse zwischen den Beteiligten verschieden ausgeprägt sind.


Bei [4.93] werden die Unternehmensbereiche Konstruktion/Design, Ar-beitsplanung, Marketing/Vertrieb, Produktion, Controlling, Qualitätssiche-rung, Versuch und Forschung/Entwicklung unterschieden und die Informa-tionsflüsse zwischen diesen Bereichen untersucht. Hier bestand in den Bereichen Konstruktion/Design und Forschung/Entwicklung ein sehr ho-her Informationsaustausch mit anderen Bereichen (nämlich jeweils fünf) während der Bereich Arbeitsplanung nur mit zwei anderen Bereichen In-formationen austauschte.

In der Untersuchung von [4.156] waren folgende Abteilungen im Ent-wicklungsprozess 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 Ent-wicklungsprozess wie in Abb. 4.40.

Eine Analyse der Informationsflüsse zeigt, dass ein Großteil der Infor-mationen vom Entwicklungsingenieur an andere Abteilungen weitergege-ben wird (vornehmlich Produktmanager, Technischer Einkauf, Fertigung und Qualitätswesen), es gleichzeitig jedoch nur wenig Rückflüsse an den Entwicklungsingenieur gibt.

Projektphase Aktion Abteilung Lastenheft PM Klären Kostenabschätzung R&D Erstbesprechung PM, R&D, TEK, QW,

Fertigung, Dok Konstruktion R&D, QW, Fertigung Konstruktionsfreigabe PM, R&D, TEK, QW,

Fertigung, Dok

Entwicklung

Abstimmung „make or buy“

Fertigung, R&D, TEK

Prototypenbau R&D, Fertigung, QW Prototypenprüfung QW, R&D Sonstiges Service, Dok

Prototypenbau

Erprobung PM Fertigung Fertigung, R&D Freigabe QW

Erstserie

Produktstartvorbereitung PM, (R&D)

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


Nach Langenberg ist der Informationsaustausch ausgeglichener:

Sicht Abteilung An Konstruktion Von Konstruktion Produktplanung Produktanforder-

ungen Produktspezifi-kation

Arbeitsplanung / NC-Programmierung

Planungsanforder-ungen

Geometrie

Fertigung Fertigungsanfor-der-ungen

Fertigungsmerk- male

Montage Montageanforder-ungen

Montagehinweise

Tech-nische Sicht

Qualitätssicherung Prüfauswertungen Qualitätsanforder- ungen

Controlling Sollwertvorgaben Ist-Kosten Versand Versandrestriktio-

nenVerpackungsan-forderungen

Fertigungssteue-rung, BDE

Fertigungsbedingte Änderungen

Konstruktive Ände-rungen

Kapazitätsplanung Engpässe Aufwandsschätzung Materialwesen Halbzeuge, Norm-

teileStücklisten

Kalkulation Kostenvorgabe Kostenfaktoren

Kaufmän-nische Sicht

Vertrieb Kundenanforde-rungen

Produktdokumen-tation

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 vor-handenen Informationen geschaffen werden. Eine besondere Herausforde-rung dabei ist die Repräsentation interdisziplinärer, vernetzter Daten. Da-durch kann die Wissensintegration in interdisziplinären Teams unterstützt werden. Der potentielle Nutzer eines solchen RPD-Portals ist Mitglied ei-nes Teams, das in den Produktentwicklungsprozess involviert ist. Die Zielgruppe umfasst also einen heterogenen Personenkreis mit sehr unter-schiedlichen Funktionen und Interessen (bspw. Prototypenbau vs. Control-ling). Dem wird durch rollenspezifische Filterung Rechnung getragen.


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 Individuali-sierbarkeit.

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 Rei-he der ISO – Normen 14915, die sich speziell auf multimediale Benut-zungsschnittstellen 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änd-lich 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 Anforderun-gen 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 Manage-mentebene Balken- und Meilensteinpläne adäquat, auf der Teamebene Netz- und Aufgabenpläne und auf der Individualebene schließlich persön-liche Aufgabenlisten.


Welche Information? Für wen? Von wem? Optimierter Teilplan pro Team

Team, Teamleiter Planung, Projektmana-gement, Teamleitung

Gesamtplan (des Pro-jektplans)

Projektleiter Planung, Projektmana-gement, Teamleitung

Konfliktanzeige (bei Ressourcenkonflik-ten)

Teamleiter, Projektleiter Planung, Projektmana-gement, Teamleitung

Anforderungsliste Controlling Entwurf Kosten, Qualität, Zeit Controlling Entwurf Bearbeiter-Informationen

Alle Entwurf

Targetkosten Entwicklungsplanung/ Konstruktion

Controlling

Ziel-Design Design Controlling Anforderungen Funk-tionalität (z.B. Einsatzgebiet)

Entwicklungsplanung / Konstruktion

Controlling

Anforderungen an Material

Entwicklungsplanung / Konstruktion

Controlling

Kalkulation Konstruktion Controlling Vergleichsangebote von Konkurrenten

Konstruktion Controlling

Einsparungspotenzial (produktbezogen)

Konstruktion Controlling

Bericht Konstruktion, Prototyp-erstellung

Prototyperstellung

Schwundmaße Prototyperstellung Prototyperstellung Links auf externe In-formationen (z.B. rap-tec)

Fachfremde mit Interes-se, 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 stati-sche Rollen inne, kann es sinnvoll sein, Hierarchieebenen abzubilden [4.61], [4.109].

Bei temporären Rollen kann die Zuordnung abhängen vom Kontext, ei-ner Bedingung oder einer Entscheidung.


Anforderungen an die Formalisierung In klassischen, objektorientierten Modellen stellt jedes Objekt die Instanz von genau einer Klasse dar. Damit entsteht aber eine unveränderliche Ob-jektstruktur. Ein Objekt kann in seinem Lebenszyklus dann nicht verschie-dene Rollen annehmen [4.11].

Aus diesen Überlegungen ergeben sich folgende Anforderungen an ein Rollenmodell [4.11].

„Objekte können während ihrer Lebensphase mehrere Rollen annehmen und auch wieder ablegen.“ „Ein Objekt kann eine Rolle mehrfach annehmen.“ „Objekte können Rollen dynamisch annehmen und wieder aufgeben.“ „Jedes Objekt besitzt unabhängig von seinen aktuell vorhandenen Rol-len eine eindeutige Objektidentifikation.“ „Die einzelnen Rollen können unabhängig voneinander angenommen und wieder abgelegt werden.“ „Mehrere Rollen können sich auf gemeinsame Daten sowie ein gemein-sames Verhalten beziehen.“ „Ein bestimmtes Verhalten kann rollenspezifisch sein.“ „Rollen können die Sichtbarkeit von Eigenschaften beschränken.“ „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 einge-loggten 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 ge-steigert werden. Es gibt komplizierte und aufwändige Systeme, die jedoch nur eine inkrementelle Verbesserung in der Benutzbarkeit mit sich brin-gen. Das bedeutet, dass der Aufwand für das Adaptionssystem immer in Relation zu dem erwarteten Nutzen bleiben sollte. Eine weitere Gefahr be-steht 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 über-nehmenden Funktionen in einem klassisch organisierten Unternehmen de-


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 Funkti-onen, die vor allem dem Management der Abläufe, der Planung und der Steuerung dienen. Bei DaimlerChrysler werden folgende Funktionen un-terschieden: Projektmanagement, Purchasing, Produktentwicklung, Pro-duktion, Logistik, Sales – Marketing, Controlling, Aftersales, Produktions-planung, Design, Powertrain, Qualitätsmanagement, Zulieferer [4.92].

Da der Schwerpunkt auf die frühen Phasen der Produktentstehung ge-legt wird, sollen die Bereiche Zulieferer, Logistik, Produktion und Aftersa-les 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 Control-ling, 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 Erar-beitung von Koordinationslösungen als Aufgabe für die Teammitglieder [4.154]. Bender hat in ihrer Dissertation ein integriertes Prozessmodell er-arbeitet, das Elemente des Projektmanagements, der Konstruktionsmetho-dik und der Gruppenarbeit verbindet [4.15]. Aussage ist, dass beim Mana-gement eines Produktentwicklungsprozesses alle drei Bereiche zu berücksichtigen seien. Folglich entstehen aus allen drei Bereichen Aufga-ben und Anforderungen an beteiligte Personen. Diese werden in der Grup-pe eigenverantwortlich verteilt. Der Bereich Projektmanagement enthält Elemente zur Projektstrukturierung, zum Projektcontrolling und zum Ein-satz von Methoden im Teammeeting. In der Konstruktionsmethodik wer-den 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 gestell-ten Informationen haben sich auch die verschiedenen Arbeitsebenen „Ma-nagement-, Hierarchie- und Individualebene“ herausgestellt [4.143]. So sehen Nölle und Kabel auf der Managementebene Balken- und Meilen-steinplä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.).


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 auszuge-hen, dass jeder Beteiligte alle drei Ausprägungen (mit unterschiedlicher Gewichtung) belegt. Bzgl. der Einflussgröße „Hierarchieebene“ kann je-dem Beteiligten abhängig vom speziellen Team X eindeutig eine Ausprä-gung zugeordnet werden. In der Einflussgröße „Funktion“ kann jeder Be-teiligte 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 je-doch prinzipiell denkbar.


Einflussgröße Ausprägung Beschreibung Design zuständig für Konstruktions-

entwurfProduktentwicklung zuständig für Konstruktionser-

stellung auf Basis Konstrukti-onsentwurf, Prototypenbau, Einarbeitung Versuchsergeb-nisse, Einarbeitung Konzeptän-derungen

Produktionsplanung zuständig für Fertigungspla-nung, Logistikplanung, Materi-alflussplanung, ...

Beschaffung zuständig für Beschaffung Sales / Marketing zuständig für Ermittlung von

Fremdbezugsdaten, Aufnahme von Kundenanforderungen, ...

Projektmanagement zuständig für Projektplanung und - steuerung, -koordination, -verfolgung, Ressourcenpla-nung, ...

Controlling zuständig für Kostenplanung,Terminplanung, Wirtschaft-lichkeitsrechnung,

Funktion

Qualitätsmanagement zuständig für Qualitätsplanung, Qualitätsüberwachung, Spezifi-kation Qualitätsanforderungen, ...

Nicht Teamangehöriger nicht Teil des Team X Teammitglied Teil des Team X ohne Lei-

tungsfunktion

Hierarchieebene

Teamleiter Teil des Team X mit Leitungs-funktion

operativ inhaltliche Ausgestaltung der Projektphasen, Einsatz von Entwicklungsmethoden, ...

steuernd Projektstrukturierung, -controlling, ...

Tätigkeiten

kommunikativ 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


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

Klasse Attribut für Funktion für Hier-archieebene

Mitarbeiter funktion Controlling /

Projektmanagement Teamleiter

personalkosten_ betrag

Controlling / Projektmanagement

Teamleiter

personalkosten_ waehrung

Controlling / Projektmanagement

laufendeProjekte Controlling / Projektmanagement

Teamleiter, persönlich

beendeteProjekte Teamleiter, persönlich

hausanschrift persönlich Geschaefts-

anschrift Team X

Unternehmensbe-reich

Projektmanagement, Controlling

mitarbeiter

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

Ist einem Informationsobjekt (Klasse oder Attribut) eine Rollen-ausprägung zugeordnet, so ist es für einen Nutzer, der eine dieser Rollen-ausprägungen besetzt, relevant. Die Tabelle ist so zu lesen, dass Zuord-nungen 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 ange-zeigt, die seiner Rolle zugeordnet wurden. Um zu vermeiden, dass durch diesen Filtermechanismus dem Nutzer relevante Informationen nicht zu-gänglich gemacht werden, kann der Filter auf jeder Portalseite ausgeschal-tet und die gesamte zur Verfügung stehende Information angefordert wer-den. 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


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 Än-derungen anpassen. Zur Zeit ist dieser Mechanismus nur einstufig imple-mentiert (ja / nein). Um eine Gewichtung der Interessen zu ermöglichen, die die Schwerpunkte der Arbeit widerspiegeln, ist jedoch eine feinere Ab-stufung in der nächsten Entwicklungsstufe vorgesehen.

Die hier gewählte Adaptionsstrategie verknüpft nach Luedi [4.131] be-nutzergesteuerte „Profilgenerierung“ mit systemgesteuertem „rule-based matching“ (s. Abb. 4.46.). Damit wird durch die systemgesteuerte Kompo-nente dem Nutzer Administrationsaufwand abgenommen, da dieser seine Auswahl nicht auf Basis der einzelnen Informationsobjekte tätigen muss. Durch die benutzergesteuerte Profilgenerierung bleibt die Kontrollierbar-keit des Systems gewährleistet.

Abb. 4.46. Komponenten der Informationsfilterung im RPD-Portal

In der Regelbasis werden die Abhängigkeiten zwischen den Einfluss-größen des Rollenprofils und den zur Verfügung stehenden Informations-objekten beschrieben. Diese Regelbasis wird auf Basis der oben beschrie-benen 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-


sen. Flexibel wird das System dadurch, dass der Nutzer jederzeit die Mög-lichkeit hat, sein Profil anzupassen.

Konzeption des RPD-Portals

Die Gesamtarchitektur beschreibt die Informations- und die Navigations-architektur.

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 über-tragen. Der Bereich Inhalte beinhaltet die projekt-, produkt-, und prozess-spezifischen Daten. Im Bereich Kommunikation werden die für den inter-personellen Austausch relevanten Funktionen und Informationen, wie bspw. Teamdaten bereitgestellt. Dieser Bereich wird im Wesentlichen durch das teamorientierte Kommunikationssystem (Kap. 4.3 „Teamorien-tiertes 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 oh-ne die Existenz des Portals wertlos wären (im Gegensatz zu den Informati-onen unter Inhalte, die auch relevant sind, wenn kein Portal existiert).

Inhalte Kommunikation Mehrwerte Seiten-Info Projekt / Pro-dukt

Planung Ressourcen ASN ...

Forum Team MessagingChat Video ...

News Suche Admin / For-mulardienst NotizenPers. Termin-kalender ...

Webmaster Sitemap Hilfe...

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

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


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

Die Navigationsarchitektur wurde sehr klassisch konzipiert, da hier si-chergestellt ist, dass ergonomische Kriterien berücksichtigt werden (s. Abb. 4.49.). So liegt bspw. die Hauptleiste der Navigation am linken Sei-tenrand, 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 ge-rade 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 Be-reich Planung nur den Nutzern angezeigt, die eine planungsrelevante Rolle besetzt haben. Im ASN wird das Suchen, Browsen und Eingeben von In-formationen in das zentrale Datennetz ermöglicht. Der Bereich Team un-terstützt die Projektteilnehmer in der Kommunikation. Der persönliche Ar-beitsplatz dient zum Zurechtlegen oft verwendeter Dokumente, zum Verwalten des persönlichen Kalenders, von Notizen und der Aufgabenlis-te. Unter Portal-Admin kann das Benutzerprofil angepasst werden. Jeder Nutzer kann hier Anpassungen vornehmen, um die Kontrollierbarkeit zu gewährleisten.


Abb. 4.49. Navigationsarchitektur

Abb. 4.50. Portalarchitektur


In Abb. 4.50 ist die Architektur des RPD-Portals dargestellt. Dabei wird deutlich, dass die nutzerspezifischen Informationsanteile, wie Rollen, Auf-gaben 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 RPD-Middleware (Kap. 4.2 „Agentenbasierte Middleware als Integrations-plattform für aktive Wissenskommunikation im Rapid Product Develop-ment“). Die Integration der einzelnen RPD-Anwendungen erfolgt über spezielle Portlets.


Zur Realisierung eines nutzerfreundlichen Informationsportals im RPD-Prozess müssen ergonomische, prozess- und rollenspezifische Anforde-rungen berücksichtigt werden. Im RPD-Portal stehen dabei die rollenspezi-fischen 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 Funk-tionen 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 abgeleg-ten, für ihn relevanten Informationen. Eine weitere Unterstützung des Nut-zers 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üp-fung und räumliche Zuordnung abstrakter Informationen. Dieses Navigati-onsservlet wurde in den Prototyp des Portals integriert. Weitere RPD-Applikationen 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.


Literatur

[4.1] Agha GA, Jamali N (1999) Concurrent Programming for DAI. In: Multi-agent 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 Ap-

proach 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 Me-

chanics 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 meth-odology 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 Va-riantenmodellen. Darmstadt, Technische Universität, Diss, Darmstädter Dis-sertationen 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,. (Auto-motive and transportation technology. International Symposium on Automo-tive Technology and Automation 2000). S 131–134

[4.13] Beck A, Janssen C (1993) Vorgehen und Methoden für aufgaben- und be-nutzerangemessene 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: Collabora-tive 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 Produkt-entwicklung. 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 Dal-las, 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 Uni-versity 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), XML-Standards. 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 Re-port. 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 Mid-dleware to support construction in Rapid Product Development with an active semantic network. In: Proceedings of the 2nd International Conference on Ro-botics. October 14–16 2004 in Timisoara & Resita, Rumania, pp 35–36

[4.28] Bullinger HJ, Warschat J, Diederich MK (2004) Multi-agent-based Mid-dleware 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 Pro-duction Research. CD-ROM : 29 July - 3 August 2001, Prague, Czech Repub-lic. 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


[4.32] Bullinger HJ et al. (2002) Usability engineering für web-basierte Applikati-onen. 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üh-rung. 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. So-ciety of Automotive Engineers -SAE- : ATTCE 2001, Automotive and Trans-portation Technology Congress and Exhibition. Proceedings. vol.3: Manufac-turing : Barcelona, Spain. Warrendale, Pa. : SAE (SAE-P 369) S 19–24

[4.37] Cebulla T (2004) Entwicklung einer asynchronen Kommunikations-unterstü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, Emery-ville CA. Fa Compu-Shack, Neuwied

[4.39] Corkill DD, Gallagher Q, et al (1988) GBB: A generic blackboard devel-opment system. In: Blackboard Systems, Engelmore R, Morgan T (eds), Ad-dison 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 Confer-ence 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) Multiagentensys-tem zur Wissenskommunikation in der Produktentstehung – Rapid Product Development. In: Wirtschaftsinformatik 2005 – eEconomy, eGovernment, eSociety / Ferstl OK, Sinz EJ, Eckert S, Isselhorst T (Hrsg). Heidelberg: Phy-sica-Verlag, S. 1621–1640. ISBN: 3-7908-1574-8

[4.44] Date CJ, Darwen H (1993) A Guide to SQL Standard. 3rd Edition, Addison-Wesley. ISBN: 0201964260

[4.45] Davis R, Smith RG (1983) Negotiation as a Metaphor for Distributed Prob-lem 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 Ar-beiten 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 Zusam-menarbeit. 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: con-tracting 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 Tech-nology and Automation (33rd ISATA), September 25–27, 2000 in Dublin, Ire-land

[4.52] Diederich MK, Leyh J (2001) Agent Based Middleware to Coordinate Dis-tributed Development Teams in the Rapid Product Development. In: Proceed-ings for the Conference on Product Development, 1st Automotive and Trans-portation Technology Congress and Exhibition (1st ATTCE) October 1–4, 2001 in Barcelona, Spain

[4.53] DIN66234 Norm Teil 8 (1988) Bildschirmarbeitsplätze: Grundsätze ergo-nomischer 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 A-cademic 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ücksichti-gung 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.


[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 Commu-nication 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 Lan-guage. 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 interakti-ven Softwaresystemen. Dortmund

[4.69] FIPA (2002) ACL Message Structure Specification. In: Foundation for In-telligent 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 Sys-tem Frameworks. In: ACM Crossroads, Special Issue on Intelligent Agents Is-sue vol 5.4, pp 18–24. URL: http://www.acm.org/crossroads/xrds5-4/multiagent.html (07.01.2005)

[4.73] Fowler M., Scott K. (1998) UML konzentriert: die neue Standard-Objektmodellierungssprache 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 Mecha-tronics 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 Intel-ligence. 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 Phasenorien-tierten Software-Ergonomie-Beratung bei der Benutzungsschnittstellen-Entwicklung

[4.85] Hacker W (1994) Arbeits- und organisationspsychologische Grundlagen der Software-Ergonomie. Eberleh E et al (Hrsg.), Einführung in die Software-Ergonomie, 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 Software-Methoden. Springer, Berlin

[4.90] Herrtwich RG, Hommel G (1994) Nebenläufige Programme. Springer-Lehrbuch, Springer Verlag

[4.91] Hinderer H (2005) Eine Vorgehensweise zur Erstellung von Informations-systemen für die zwischenbetriebliche Zusammenarbeit im Vertrieb techni-scher Produkte. Stuttgart, Univ., Diss., Jost-Jetter Verlag, Heimsheim

[4.92] Holdefer U (2002) Methodeneinsatz aber wann? Methodenwirrwarr. Kmap-Forum, Wissensmanagement – mit Methode zum Erfolg, 27. Juni 2002, Karls-ruhe.

[4.93] Hriso M (1999) Konzeption und Auswertung einer empirischen Studie zum Informationsmanagement in der Produktentwicklung. Unveröffentlichte Stu-dienarbeit am IAT, Universität Stuttgart

[4.94] Huhns MN, Stephens LM (1999) Multiagent Systems and Societies of A-gents. 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. Psy-chologisches 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


[4.98] Ishi H, Ullmer B (1997) Tangible Bits: Towards Seamless Interfaces be-tween 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 In-telligence. 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 Re-search and Development. In: Autonomous Agents and Multi-Agent Systems Journal, Jennings NR, Sycara K, Georgeff M (eds), Luwer academic Publish-ers, Boston, vol 1, Issue 1, pp 7–38

[4.107] Jennings NR, Sycara K, Wooldridge M (1998) A Roadmap of Agent Re-search 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 in-telligent interface design challenges. In: Interacting with Computers 12, S 357–381

[4.109] Kempf F (2002) Referenzmodell zur integrierten Kommunikationsunter-stü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 Com-munication Languages. In: IEEE Intelligent Systems 14 vol 2, pp 45–52

[4.119] Langenberg L (2000) Firmenspezifische Wissensportale für die Produkt-entwicklung. Bochum, Univ., Diss., Zugl. Aachen: Shaker, 2001 (Schriften-reihe 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. Addi-

son-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 – Kon-zepte 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 Sympo-sium 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, Roc-quencourt, 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 Com-puterized Service Supporting System. In human-computer Interaction: Ergo-nomics 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 Kommu-nikationsformen. In: Nagl M, Westfechtel B (Hrsg) Integration von Entwick-lungssystemen 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.


[4.133] MapleSoft (2003) New Features and Benefits of Maple 8. URL:http://www.maplesoft.com/products/Maple8/whatsnew/features.shtml#programming

[4.134] Mešina M (2002) ASN und die relationalen Datenbanksysteme (Realisie-rungsaspekte). 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/moderation-vr/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 con-duct 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, Archi-tectures 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, techni-cal, and usage dimensions of collaborative virtual environments, Presence-Teleoperators and Virtual Environments, MIT Press 8(2), pp 218–236

[4.145] Nwana HS (1994) Negotiation Strategies: An Overview. In: BT Laborato-ries internal report

[4.146] Nwana HS (1996) Software Agents: An Overview. In: Knowledge Engi-neering 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, Decem-ber 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: Sprin-ger, 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, Fa-kultät Wirtschaftswissenschaften, Universität Dresden

[4.157] Roller D, Bihler M (1996) Objektorientierte Konzepte für Produktdaten-modellierung 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 - Proceed-ings 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 Col-laborative 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 proto-type 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: Elektrotech-nik 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 Auto-motive Industries, Automotive Automation Ltd. / Roller D (ed.). 1997 in Croydon, England, pp 253–262


[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 Competi-tive 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 Engi-neering, Elsevier Science B.V 42. 2002, pp 223–245

[4.166] Roller D, Eck O, Dalakakis S (2002) A Knowledge Base for Rapid Prod-uct 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 lock-ing in knowledge base for rapid product development. In: Cooperative De-sign, 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 net-work for supporting rapid prototyping. In: ISATA Proceedings. Mechatronics - Efficient Computer Support for Engineering, Manufacturing, Test-ing&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 Chal-lenges, 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, U-niversitä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 Cogni-tive 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 Envi-ronment: A Comparative Study, Presence: Teleoperators and Virtual Envi-ronments 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 environ-ments, IEEE Virtual Reality, Houston, pp 58–63

[4.183] Steed A et al. (1999) The London Travel Demonstrator, VRST’99, Pro-ceedings of the ACM Symposium on Virtual Reality Software and Technol-ogy, 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: ISATA-Dü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 Envi-ronment. 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 devel-opment. 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 communica-tion 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 ver-netztes Arbeiten. In: Vernetzt planen und produzieren. Fachtagung : 12.–14. Oktober. S 163–167

[4.197] Warschat J, Cebulla T, et al. (2002) Systemumgebung einer multidiszipli-när wissensbasierten Produktentwicklung. In: Modelle, Werkzeuge und Infra-strukturen zur Unterstützung von Entwicklungsprozessen, 20.–22. März 2002


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 Coopera-tive 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). Cam-bridge, Massachusetts; London, England: The MIT Press, pp 27–78

[4.205] Wooldridge M, Jennings NR (1995) Intelligent Agents: Theory and Prac-tice. 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. Online-Zeitschrift zu Fragen der Mensch-Maschine-Interaktion, Nr 3, S 1–17

[4.207] Zülch G, Stowasser S, Fischer AE (1998) Gestaltung des Dialogs zwi-schen Benutzer und Rechner, Ergonomische Aspekte der Software-Gestaltung, 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 Erstel-lung virtueller und physischer Prototypen. Die Forschungsaufgaben inner-halb dieses Bereichs umfassen:

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 be-reits erste Studien zur späteren Montierbarkeit oder Strömungs-simulationen 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 Printtechnolo-gien erste physische Prototypen „gebaut“ werden. Diese Prototypen kön-nen als erste Anschauungsmuster zum Einsatz kommen. Durch eine nach-folgende 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 Werkzeu-gen zur Blechumformung. Es wird dadurch möglich, nach den Prinzipien des RP kostengünstig Werkzeuge zur Herstellung von Kleinserien zu er-zeugen.

330 5 Erstellung virtueller und physischer Prototypen

5.1 Virtuelle Realität

Die Technologie der virtuellen Realität wird heute zunehmend in der in-dustriellen Produktentwicklung eingesetzt. Am Höchstleistungs-rechenzentrum der Universität Stuttgart (HLRS), Institut für Arbeitswis-senschaften und Technologiemanagement (IAT) und Institut für industriel-le Fertigung und Fabrikbetrieb (IFF) werden die Grundlagen der Software- und Gerätetechnik für dieses Verfahren erforscht und entwickelt. Der fol-gende Abschnitt erläutert hierzu einige allgemeine Grundlagen und Begrif-fe.

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 „vir-tuelle Welt“ von Ivan Sutherland [5.155] und „künstliche Realität“ von Myron W. Krueger [5.98] um die Aspekte der Interaktivität und Koopera-tion zu erweitern. Die damit beschriebene Technologie umfasst Vorrich-tungen, um den Benutzern durch realitätsnahe Stimulation der Sinne ein „eingebunden sein“ in eine synthetisch generierte Umgebung zu vermit-teln. Die Empfindung, eingebunden zu sein, wird als Immersion, die tech-nischen Vorrichtungen hierfür auch als immersive Umgebung oder immer-sives System bezeichnet. Da die Begriffe virtuell und Realität im Widerspruch zueinander stehen, wird für diese Form der Mensch-Maschine-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 Interak-tion 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 so-wie in der intuitiven Interaktion im 3D-Raum. Die immersive, interaktive Darstellung unterstützt maßgeblich das Verständnis für komplexe Zusam-menhänge und vereinfacht die Fehlererkennung. Die freie Interaktion er-laubt 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 6-Wand-Stereoprojektionsräumen, die ein Gesichtsfeld von bis zu 360° bie-ten. Für stereoskopisches Sehen sind dabei zwei unterschiedliche perspek-tivische 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 Kop-fes 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 In-teraktion mit der VR-Anwendung. Die räumliche Lage von Objekten wird häufig durch drei Koordinaten der Position und drei Winkel der Orientie-rung 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-


nutzer, sich relativ zu den dargestellten 3D-Daten zu bewegen und mit die-sen zu interagieren. Diese Messung wird als Tracking bezeichnet und muss in Echtzeit erfolgen. Sie basiert meist auf elektromagnetischen oder opti-schen Verfahren, es existieren jedoch auch Lösungen auf Basis von Inerti-alsensorik 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-Viewpoint-Rendering [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 ge-trennt. An Monitoren oder Projektionswänden erfolgt die Sichtkanaltren-nung meist durch spezielle Brillen, die auf Verfahren nach dem Shutter-Prinzip, 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 Verbin-dung mit Projektoren paarweise unterschiedlich ausgerichtete, linear oder zirkular polarisierte Filter an den Objektiven sowie an der Brille des Be-nutzers 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 Filter-paar 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 e-lektro-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 ana-lysiert oder bearbeitet werden, sind zumeist aus 3D-CAD-Geometrien ab-geleitet. 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 Tesselie-rung, 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 Dreiecksstruk-tur gebildet wird, desto genauer ist zwar die Flächenbeschreibung, ande-rerseits steigen hierbei jedoch durch die höhere Polygonzahl auch die An-forderungen an die Grafikleistung der VR-Bildgenerierung.

Die hier beschriebenen Technologien finden derzeit die größte Verbrei-tung in den industriell eingesetzten VR-Systemen. Daneben gibt es aller-dings noch eine Vielzahl weiterer Lösungen zur Realisierung immersiver Umgebungen.

5.2 Virtuelle Realität als Gestaltungs- und Evaluations-werkzeug

5.2.1 Montierbarkeitsuntersuchungen am Virtuellen Prototypen

Die Untersuchung eines digitalen Prototyps umfasst neben ästhetischen auch funktionale Aspekte. Im Rahmen der durchgeführten Forschungsar-beiten stand die Überprüfung der Eignung des Prototyps auf seine Produ-zierbarkeit im Vordergrund: Aussagen zur Fertigbarkeit und Montierbar-keit (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-


chungspunkte im Bereich der manuellen Montage sind die Objektgeomet-rien, die Verbauwege, die Eignung von Montagehilfen, die Einsehbarkeit des Montagebereichs sowie die Handhabbarkeit der Baugruppen. Dem-nach müssen Geometrien und Bewegungsbahnen beurteilt werden, dazu die Lage von 3D-Objekten im Raum verändert werden sowie die Einseh-barkeit des Bereichs und die Handlungen des Monteurs im Kontext bewer-tet werden.

Für die Überprüfung manueller Montageprozesse mit Hilfe von 3D-Werkzeugen stehen zwei prinzipielle Ansätze zur Verfügung:

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 Anima-tion 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 techno-logischen Ansatz wird mindestens ein Standard-PC-Arbeitsplatz benö-tigt.Die Szene wird einschließlich der zu verbauenden Objekte und einer e-ventuellen 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 Wahr-nehmungsorgane und der korrekte Bezug seiner Extremitäten zur 3D-Szene müssen sichergestellt sein. Die zu diesem Zweck benötigte Posi-tionserfassung kann auch dazu verwendet werden, die räumlichen Ar-beitsabläufe zu protokollieren und für Auswertungen (Ausführungszei-ten, Ergonomie, Kollisionsprüfung) weiter zu verwenden. Für diesen technologischen Ansatz wird zwingend eine Umgebung Virtueller Rea-lität benötigt.

Die Vorteile des zweiten Ansatzes liegen darin, dass einerseits der Mon-tageablauf nicht gesondert programmiert werden muss und andererseits der Benutzer einen realistischeren subjektiven Eindruck der Gegebenheiten er-hä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 ange-führten Aufgaben sind allerdings so vielschichtig, dass eine einzelne Um-


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 Auf-gabe 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]. Weiter-hin muss die wahrgenommene Objektgröße maximiert werden [5.171], [5.21]. Für die visuelle Überprüfung von Geometrien bieten sich Rückpro-jektionssysteme, insbesondere Workbench-Lösungen an [5.21]. Um geo-metrische 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 eingerich-tet, 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 (VRML-Materialmodell, s. Abb. 5.5.), Shading (Gouraud Shading, Phong Sha-ding), Schattierung (Shadow Maps, s. Abb. 5.4.), Struktur-/Reliefdar-stellung über Texturen (Bump Mapping), perspektivische Offcenter-Projektion für immersive Darstellungen mit Tracking sowie Stereoskopie.


Abb. 5.3. Vom Menschen genutzte graphische Tiefenkriterien

Abb. 5.4. Verwendung eines lokalen Beleuchtungsmodells und Shadow Maps


Abb. 5.5. Verwendung von Transparenz zur Lagebeurteilung

Die VR-Arbeitsumgebungen, die auf der Basis der vorgestellten Tech-niken eine Vielzahl der graphischen Tiefenkriterien erfüllen, sind in An-wendungsszenarien erprobt worden. Sie ermöglichen eine gute visuelle Beurteilbarkeit von Objektgeometrien sowie deren Lage zueinander, ins-besondere 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 translatori-sche 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 beid-hä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 Rei-bung räumlicher Eingaben und Greifoperationen zu leisten [5.73], [5.177], [5.150]. Damit rücken neben der graphischen Darstellung auch die akusti-sche Ausgabe und die Kraftreflexion in den Fokus.


Das IFF hat für Aufgaben der Objektpositionierung unter Berücksichti-gung 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 ei-nem präzisen räumlichen Bezugssystem zu arbeiten. Multimodales Feed-back wird an den Händen vermittelt: an der linken Hand sorgen kleine Mo-toren mit Exzentern für Vibrationsreize, so dass sich hier Oberflächenstrukturen und Kollisionen der Hand mit virtuellen Geomet-rien 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 ge-griffen 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 eige-nen Körper des Benutzers, in diesem Fall durch die Handgelenke, aufge-bracht wird.

Vor diesem Hintergrund wurde eine zweite haptische Umgebung für ei-nen 3-Seiten-Projetionsraum entwickelt, welche im Gegensatz zu den Da-


tenhandschuhen die Kollisionskraftausgabe auf die Arme und den Rumpf des Bedieners ermöglicht. Da kraftreflektierende Gelenkarmsysteme einer-seits 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 ge-führt wird. Die Fäden werden aktiv nachgeführt und ermöglichen so die Positionserfassung des Mediators. Gleichzeitig können die Motoren, wel-che die Fäden nachführen, blockieren bzw. ein Drehmoment aufbringen. Damit läßt sich bei geeigneter Berechnung der Drehmomente eine gerich-tete Kraft auf den Mediator aufbringen. Da das Gestell, welches die Moto-ren 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


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

Das Führen von Objekten läßt sich mit dem SPIDAR so korrekt abbil-den. 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. Ge-wichtskräfte virtueller Objekte lassen sich ebenso abbilden wie das Ge-wicht 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 je-doch 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 Einbe-zug des Benutzers in die Virtuelle Umgebung erforderlich [5.171]. Für die Erfassung motorischer Abläufe muss der Arbeitsraum entsprechend groß


sein. Die Abbildung verschiedener Greiftechniken erfordert die entspre-chende 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äumli-cher Umgebung gefordert ist [5.21].

Virtuelle Umgebungen auf der Basis von Projektionssystemen, in wel-chen haptisch, eventuell sogar auf Basis natürlicher Handbewegungen, in-teragiert 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 ent-weder nur die eigene Hand oder nur die Projektionsfläche korrekt (scharf) sichtbar. Aus diesem Grund wird normalerweise in derartigen Systemauf-bauten 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 Relati-on der Abstände vom Kopf zu den Armen und zum Rest der Szene nicht mehr. Kommt es jedoch, beispielsweise im Rahmen ergonomischer Unter-suchungen, auf die richtige Relation an, so sind derartige Aufbauten damit also prinzipiell problematisch.

Am IFF wurde aus diesem Grund eine Virtuelle Umgebung auf der Ba-sis eines Head Mounted Displays (Abkürzung HMD) erstellt. Die volliso-lierte Funktionsweise umgeht dabei das Akkomodationsproblem bei der Benutzung von Projektionssystemen in Verbindung mit haptischen Syste-men: der Benutzer sieht lediglich in die 3D-Szene - Sichtkonflikte mit rea-len Extremitäten treten nicht auf. Als haptische Ein-/Ausgabegeräte wur-den 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.).


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

Zur Auswertung manueller Arbeitsvorgänge ist eine Vielzahl von Be-wertungswerkzeugen am Markt verfügbar. Diese gilt es zu nutzen, um ob-jektive Bewertungen der haltungs- und tätigkeitsbezogenen Arbeitsbelas-tungen 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 vi-suell beurteilen. Eine quantitative Bewertung von Komfort und Ergonomie ist über den Export der Bewegungsbahnen des Monteurs an ein Arbeits-platzgestaltungswerkzeug möglich.


5.2.5 Data Mining in Virtuellen Umgebungen

Interaktionen mit dem Aktiven Semantischen Netz

Ansätze zum Data Mining mittels Virtueller Umgebungen kamen ur-sprünglich aus allgemeinen Ansätzen zur Visualisierung größerer (wissen-schaftlicher) 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 Desktop-Computersystemen ü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


können so prozessorientiert interpretiert und aufgetragen werden. Darstel-lungsmetaphern 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 Informatio-nen 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 erstre-cken sich von der Evaluierung von Designstudien und Konstruktionsdaten-sä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 VR-Anwendungen bisher nicht immer vollständig abgedeckt werden. Hierbei müssen in einer VR-Sitzung für ein Produkt entsprechend mehrere, aufga-benspezifische 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 Bedie-nung durch jeweils unterschiedliche Interaktionstechniken. Eine quasi-standardisierte Interaktionsform wie sie bei Desktop-Rechnern durch O-berflächen wie Windows, X Window System oder MacOS heute vorliegen, erleichtert die Benutzung wie auch die Einarbeitung in neue Applikatio-nen. Anwendungen in virtuellen Umgebungen entbehren jedoch bisher ei-ne vergleichbare Standardisierung ihrer Benutzungsschnittstellen.

Am IAT wurde untersucht, in welcher Form die bisher in separaten VR-Anwendungen durchgeführten Tätigkeiten der Aufgabenbereiche Design-Review, Montierbarkeitsbetrachtung, Ergonomieanalyse und CAD-Evaluation in einer gemeinsamen Applikation mit durchgängiger Benut-zungsschnittstelle 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 Sechs-wand-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 an-hand 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 Doku-mentationsfunktionen 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.


„Einsatz des Hardware-Shadings“). Die Durchführung von Montierbar-keitsbetrachtungen ist auf Basis einer kontinuierlichen Kollisionserken-nung 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 weitergehen-de Präparation der Modelle hinsichtlich Entkernen, Polygonreduktion und Healing [5.133], [5.158] erforderlich sein, um die Datenmenge an die ver-fügbare Rechenleistung anzupassen und gegebenenfalls Tesselierungsfeh-ler zu beheben. Bei sehr umfangreichen 3D-Modellen kann die zur Dar-stellung 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 Ap-plikation 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 effi-zient um zusätzliche Module für neue Funktionalitäten erweitert werden können und lehnt sich an die Standards zur Entwicklung von 2D-Desktop-Anwendungen an. Auf dieser Basis können auch zukünftig VR-Applikationen mit hohem Interaktionsgrad und komplexen Funktionalitä-ten modular entwickelt, optimiert und erweitert werden.

Die bisher häufig nur in separaten Anwendungen vorliegenden Funktio-nalitäten aus den Bereichen Design-Review, Montierbarkeitsbetrachtung, Ergonomieanalyse und CAD-Evaluation sind nun in einer gemeinsamen Anwendung mit durchgängiger und intuitiv bedienbarer Benutzungs-schnittstelle verfügbar. Die Anwendung wird derzeit im VR-Center von DaimlerChrysler getestet. Die bisher erforderlichen Rüstzeiten bei mehre-ren Einzelanwendungen konnten reduziert werden, was insbesondere bei komplex strukturierten Produktdatensätzen, die bei industriellen Anwen-dern häufig in Einzelteilen aus dem PDM-System bezogen werden, zu Zeitersparnis führt. Die Anwendung kann flexibel auf verschiedenen Pro-jektionssystemen wie Projektionsraum, Projektionswand, immersiver Ar-beitstisch, Datenhelm und monoskopischer Bildschirmarbeitsplatz in Ver-bindung 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-


gestützten Fertigungsplanung. Hierbei steht neben den aufgabenspezifi-schen, 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 be-schränkt sich jedoch auf die „passive“ Evaluation und Analyse von 3D-Produktmodellen. 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 entfern-ten Arbeitsplatz des verantwortlichen Ingenieurs möglich. Die aufwändi-gen Iterationen zwischen Desktop-CAD- und VR-System im Produktent-wicklungsprozess 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 Um-gebungen ist in der Forschung seit längerer Zeit Gegenstand von Untersu-chungen [5.34], [5.40], [5.153]. Hingegen wurde die parametrische Erzeu-gung und Manipulation mathematisch definierter Konstruktionsdatensätze, die Grundlage der industriellen CAD-basierten Produktentwicklung ist, als VR-Anwendung bisher nur ansatzweise realisiert. Auch die CAD-Softwarehersteller zeigen sich bezüglich der Unterstützung von VR-Technologie bisher noch zurückhaltend, wenngleich erste Vorstöße in die-se 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, di-rekt 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 Opti-mierung der Gestaltung noch innerhalb der Evaluationssitzung in VR durchgeführt werden. Zur Integration von CAD und VR können unter-schiedliche Strategien verfolgt werden:


Integration eines CAD-Kerns in das VR-System

Der höchste Integrationsgrad zwischen beiden Systemen wird dann er-reicht, wenn die Bedienung des CAD-Systems durch die Benutzungs-schnittstelle 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 reali-sierten Ansatz wurde der bestehende CAD-Kern OpenCASCADE [5.119] in das VR-System Lightning integriert und eine immersive Benutzungs-schnittstelle zum Zugriff auf die Modellierfunktionen entwickelt (s. Abb. 5.12.).

Der CAD-Kern dient zur Generierung und Verwaltung der mathemati-schen 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 Teile-konstruktion (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.


CAD auf dem virtuellen Desktop in VR

Das System „Sensing Surfaces“ des IAT ermöglicht die Fernbedienung ei-ner Windows- oder UNIX-Workstation aus der virtuellen Umgebung. Hiermit kann der Konstrukteur das CAD-System mit dem Produktdaten-satz von seinem Arbeitsplatzrechner oder beliebigen anderen, im Netz er-reichbaren Rechnern in ein Fenster innerhalb der VR-Anwendung einblen-den und bedienen [5.29]. Änderungen an der CAD-Konstruktion im CAD-System, 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 compu-ting) auf, das einen Verteilungsmechanismus für Rechnersysteme mit gra-phischer 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


der virtuellen Umgebung wird der Bildschirminhalt des entfernten Rech-ners auf eine Geometrie-Ebene projiziert und kann durch die VR-Eingabegeräte bedient werden. Ein vom Eingabegerät ausgehender, virtu-eller Selektionsstrahl steuert den Mauszeiger, während für alphanumeri-sche Eingaben eine virtuelle Tastatur eingeblendet oder eine physische Tastatur verwendet werden kann. Neben dem CAD-System stehen auch al-le weiteren, auf dem entfernten Rechner installierten Anwendungen in der virtuellen Umgebung zu Verfügung [5.13]. Für diesen und den im folgen-den Abschnitt dargestellten Ansatz wird ein begrenztes Ausmaß an Pro-duktkomplexität vorausgesetzt, bei der noch keine gesonderte Datenaufbe-reitung zwischen CAD und VR-Visualisierung zwischengeschaltet werden muss.

Einsatz eines mobilen CAD-Rechners in VR

Dieser Ansatz verbindet das CAD-System eines drahtlos vernetzten Note-books mit der immersiven VR-Anwendung. Die VR-Anwendung ermög-licht die Evaluation des Produktes in der immersiven Umgebung. Die hier-bei zu Tage tretenden Änderungserfordernisse können direkt in der virtuellen Umgebung durch die, dem Ingenieur vertraute, CAD-Benutzungsschnittstelle 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.


Anschließend wird die am Notebook geänderte Produktkomponente in die VR-Anwendung übertragen und ersetzt dort die vorhergehende Versi-on der Produktkomponente. Dabei werden nicht alle, sondern nur die je-weils veränderten Geometrien des Produktes vom Notebook an das VR-System übertragen. Für den ergonomischen Einsatz eines portablen Rech-ners 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 wer-den.

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 VR-System besteht große Flexibilität bezüglich der in den immersiven Syste-men 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 Unter-stützung der VR-Anzeige- und Interaktionstechnik durch die bereits beste-henden CAx-Systeme profitieren, wodurch der derzeit teilweise noch hohe Aufwand für die Datenaufbereitung zwischen CAD- und VR-Anwendungen bei komplexen Produktgeometrien ebenfalls nicht mehr er-forderlich 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 best-möglich in bestehende Arbeitsabläufe zu integrieren. Immersive Arbeits-plä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 Projektgegebenhei-ten, der typischen Produktgröße und an den Präferenzen der jeweiligen Nutzer orientieren. In der Regel sind die gegenwärtig in der Industrie ein-


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 Qua-litä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üro-arbeitsplätzen verfügbar zu machen (s. Abb. 5.15.). PIcasso erweitert den klassischen Bildschirmarbeitsplatz des Benutzers um ein kompaktes, ergo-nomisches 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 Produkt-entwicklungsarbeiten 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 da-durch auch bei der, für Bildschirmarbeitsplätze empfohlenen Mindest-leuchtdichte von 300 Lux betrieben werden. Bei herkömmlichen, projekti-onsbasierten VR-Systemen ist meist eine Abdunkelung der Umgebung auf 1-50 Lux erforderlich. Auch die Auflösung des Bildes erreicht bei PIcasso


mit etwa 37% des maximalen Auflösungsvermögens des menschlichen Auges einen vergleichsweise hohen Wert, da gängige Systeme heute hier-von durchschnittlich nur etwa 13-23% erzielen. Zur Positionsbestimmung der Augen und der Eingabegeräte wird ein präzises und latenzarmes opti-sches 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 im-mersive Interaktion wurde eine Reihe unterschiedlicher, drahtloser und drahtgebundener Interaktionsgeräte entwickelt, die inzwischen teilweise bereits als Produkte kommerziell angeboten werden. Der Betrieb von PI-casso erfolgt durch Rückprojektion auf Basis zweier LCD- oder DLP-Projektoren. Die Stereoseparation wird durch Polarisations- oder Spektral-filter [5.36] im Passiv-Stereo-Modus realisiert. Die Bildgenerierung erfolgt durch zwei herkömmliche, synchronisierte Grafik-PCs mit beliebigen, ste-reoskopiefähigen 3D-Anwendungen, wie zum Beispiel der am IAT entwi-ckelten 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 angestreb-ten, vergleichsweise niedrigen Systemkosten, den kompakten Abmessun-gen, der ausgezeichneten Bildqualität und der geplanten Modularität erge-ben 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 gear-beitet.

5.3.4 Realitätsnahe Darstellung in VR

In den folgenden Kapiteln „Einsatz des Hardware-Shadings“ und „Paralle-les Rendering“ werden zwei Verfahren beschrieben, durch die eine Ver-besserung der Darstellungsqualität und eine Erhöhung der Leistungsfähig-keit von VR-Systemen erzielt werden kann. Diese Verfahren eignen sich sowohl für die Produktentwicklung als auch für viele weitere Aufgaben-stellungen, in denen VR heute zum Einsatz kommt.


Einsatz des Hardware-Shadings

Eine wesentliche Komponente jedes VR-Systems ist die Echtzeit-Bildgenerierung. 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 anmutung-streue Visualisierung besonders bei Gestaltungsaufgaben von Bedeutung.

VR-Systeme nach dem Stand der Technik verwenden für die Bild-Generierung spezielle Hardware [5.114], die heute in den meisten PC-Graphikcontrollern integriert ist und daher oft auch als GPU (Graphics Processing Unit) bezeichnet wird. Moderne GPUs enthalten statt fest ver-drahteter 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 Rendering-verfahren sind zwar oft auf VR-Anwendungen übertragbar, der in der digi-talen Produktentstehung akzeptable Aufwand für die visuelle Modellaufbe-reitung ist jedoch um Größenordnungen geringer als bei Computerspielen.

Es wurden daher Methoden und Werkzeuge entwickelt, die eine hoch-wertige 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 Anforde-rung, dass auch komplexe visuelle Effekte ähnlich wie bisherige, nur aus Beleuchtungsparametern und eventuell Texturen bestehende Materialdefi-nitionen handhabbar sein müssen. Daraus folgt die Notwendigkeit der vollständigen Beschreibbarkeit eines visuellen Effektes möglichst inner-halb 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 dar-stellbar ist, erfordert jedoch noch weitere Informationen, z.B. Parameter und verwendete Ressourcen. Zudem kann ein Effekt aus mehreren Rende-ring-Durchläufen (Passes) bestehen.

Es existierten bereits einige Ansätze für Dateiformate zur Effekt-beschreibung. Deren Analyse ergab, dass das CgFX-Format von NVIDIA obige Anforderungen weitgehend erfüllt [5.118]. Zudem existieren Soft-warewerkzeuge, mit denen CgFX-Effekte erstellt werden können. Daher wurde eine prototypische Realisierung der Shaderunterstützung im VR-System Lightning des IAT auf der Basis dieses Formates durchgeführt. Dies erforderte vor allem eine umfangreiche Modifikation und Erweite-rung des zugrunde liegenden Szenegraphen-Renderers.


Auf VR-Systemebene steht nun ein dediziertes Materialobjekt zur Ver-fügung, das beliebigen Geometrien zugewiesen werden kann. Diese Funk-tionalität ist jedoch für die Fachanwender, hauptsächlich Gestalter, so noch nicht zugänglich. Es war daher ein Werkzeug zu entwickeln, das den Ge-staltern selbst die einfache visuelle Aufbereitung ihrer Modelle ermöglicht. Von den Anwendern wurde dabei ein unmittelbares visuelles Feedback al-ler Änderungen als besonders wichtig bewertet. Für eine optimale Prozess-integration war zudem Flexibilität hinsichtlich der verwendbaren Ein-gangs-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 er-möglicht (s. Abb. 5.16.). Die Benutzungsoberfläche wurde dabei so gestal-tet, 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 Desk-top zur Datenpräparation und im VR-System zur Datenanalyse eingesetzt werden.


Der Einsatz programmierbarer Grafikhardware ermöglicht eine erheb-lich höhere visuelle Qualität im Echtzeitrendering. Es wurde gezeigt, dass bei optimaler Integration diese Qualität auch in der Virtuellen Realität er-reicht 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 Mo-dellen auch bei Verwendung der neuesten Graphikkarten-Generation oft noch nicht ausreichend, insbesondere in Kombination mit komplexen visu-ellen Effekten. Daher wurde am IAT auch untersucht, inwieweit durch Pa-rallelisierung der Bildberechnung auf mehrere Rechner und damit Gra-phikkarten 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 reflek-tierten 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 CAD-Review komplexer Produkte erzeugt wird, erfordert auch neue Herange-hensweisen 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 pro-grammierbarer Vertex- und Fragmentprozessoren der GPU zur Darstellung komplexer visueller Effekte, wie dies im Abschnitt zur realitätsnahen Dar-stellung in VR beschrieben wurde. Durch eine Reduktion des Detaillie-rungsgrades 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. Zu-dem ist dieser Reduktionsprozess oft mit manueller Aufbereitung der Da-ten verbunden. Eine Möglichkeit, solche Einschränkungen und Fehler zu eliminieren, besteht darin, nur den jeweils betrachteten Teilbereich im De-tail 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 wer-den 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 einfa-ches Handhaben der Datensätze sowie ein intuitives Arbeiten mit diesen nicht mehr möglich. Diese Methode ist besser für Präsentationsfilme ge-eignet denn für Datensatzanalysen.

Eine elegantere Lösung ist hier, die Graphikerzeugung zu parallelisie-ren. Hierbei wird die Bilderzeugung auf mehrere Renderknoten, beispiels-weise in Form separater Graphikworkstations, verteilt. Dies ist insbesonde-re 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 Echtzeit-Bildgenerierung erreicht werden kann und welche Auswirkungen die un-terschiedlichen 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 Unter-abschnitte 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 Verringe-rung 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-


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 Daten-sä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 Spei-cher 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 Graphikpi-peline 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 Bildschirm-bereich 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 Darstel-lungsknoten geschickt, der diese überlagert und anzeigt. Damit dies funk-tioniert, 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 Gra-phikelemente, sogenannte Primitive, bevor sie verteilt und weiterverarbei-tet werden. Diese Art der Parallelisierung ist jedoch derzeit unüblich, da es


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 be-trachtet werden. Sowohl Sort-First als auch Sort-Last haben ihre spezifi-schen 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 Auf-wand, 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 Ob-jekte, oder andere Objekte überlagern die Transparenz, obwohl sie eigent-lich durch diese durchscheinen sollten. Auch finden Farbverfälschungen statt, wenn verschiedene transparente Objekte nicht in der richtigen Rei-henfolge verschmolzen werden. Dafür ist Sort-Last auf der Renderknoten-seite 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ög-lich, da dieser keine Informationen über Objekte auf anderen Renderkno-ten besitzt.


Die Anforderungen von VR an das Echtzeitrendering unterscheiden sich von anderen Anwendungen erheblich, insbesondere hinsichtlich folgender Punkte

Ausreichend hohe Bildwiederholrate, um eine immersive Wahrnehmung zu ermöglichen. Kurze Latenzzeit zwischen Interaktion und deren sichtbarer Auswir-kung. Zur Laufzeit veränderliche Szenen, hauptsächlich durch Benutzerinter-aktionen.

Diese Kriterien wurden beim Entwurf des Echtzeitrenderingsystems be-sonders 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 unter-schiedliche Aufgaben mittels des oben beschriebenen parallelen Rende-ringsystems untersucht. Als besonders geeignet erwies sich die Sort-First-Parallelisierung, bei der das Endbild in Teilbereiche unterteilt wird und je-der Renderingknoten einen solchen Teilbereich berechnet. Dieses Verfah-


ren stellt die geringsten Anforderungen an die Netzbandbreite, die zudem anders als bei anderen Verfahren nicht von der Anzahl der Renderingkno-ten 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 un-terteilt werden, dass eine hinreichend feinkörnige Zuordnung der Szenen-teile 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, dynami-sche 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 dar-zustellende Szene zerlegt und auf die Renderingknoten verteilt wird, hat den Vorteil, dass die Lastverteilung nicht sichtabhängig ist; auch die räum-liche Strukturierung der Szene spielt nur eine untergeordnete Rolle. We-sentlicher Nachteil beim Einsatz von Sort-Last in einem Cluster-Renderingsystem ist jedoch die sehr hohe benötigte Netzbandbreite, da je-der 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 be-grenzte Anzahl von Clusterknoten dennoch einsetzbar sein [5.30].

Es konnte gezeigt werden, dass durch Parallelisierung der Bilderzeu-gung 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 Anwendun-gen einsetzbar. Mit dem entwickelten Verfahren zur Sort-First-Last-verteilung wird bei kleinen Clustergrößen ein hoher Skalierungsgewinn er-reicht; 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 Funkti-onsblöcke Applikation, dynamische Lastverteilung und Combiner können dabei auf einem einzelnen Clusterknoten zusammengefasst werden.


Obwohl sich die Renderingprozesse fast linear parallelisieren lassen, ist jedoch kein linearer Speedup zu verzeichnen, da das Auslesen des Gra-phikspeichers und das Senden über das Netzwerk einen großen Zeitbedarf aufweist. Insbesondere beim Sort-Last-Rendering, bei dem unter Umstän-den die volle Bildschirmgröße mehrfach versandt wird, ist dies ein Prob-lem. Hocheffiziente Komprimierungsverfahren lassen sich auch nur teil-weise 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 Infini-band 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 Rende-ringmethoden 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 Entwick-lungsrichtung, die am IAT verfolgt werden wird, sind asymmetrische Pa-rallelisierungsansätze, die nicht direkt auf die verteilte Berechnung des Endbildes, sondern von Vorstufen der eigentlichen Bildberechnung abzie-len.

5.5 Virtuelle und Hybride Prototypen

Visualisierung und Simulation physikalisch-technischer Zu-sammenhä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 Eigen-schaften des zukünftigen Produktes untersucht werden. Da sich die Erstel-lung 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 er-setzen kann, ist die vollständige Modellierung des Objektes im Rechner und der Bestimmung dessen Eigenschaften über Simulationen. Diese vir-tuellen Prototypen können in idealer Weise schnelle Iterationszyklen un-terstü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 erstel-len, möglicherweise weil die experimentelle Verifikation der Simulations-ergebnisse notwendig ist, kann die Integration virtueller Komponenten in die Betrachtung des realen Prototypen eine Verbesserung des Verständnis-ses der Ergebnisse bewirken. So können beispielsweise an einem solchen hybriden Prototypen die experimentellen und simulierten Ergebnisse über-lagert 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, wel-che ein einfaches Aufsetzen und Manipulieren verschiedenster Szenarien erlaubt, ist so unmöglich. Wichtige Vergleiche zwischen Simulationser-gebnissen und Experimenten sind oft nicht trivial, da verschiedene Ansich-ten 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 Ent-wickler anreisen müssen, um sich mit ihren Kollegen austauschen zu kön-nen. 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 ent-wickelt und getestet. Normalerweise steht am Ende dieser Tests die Erstel-lung 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 Proto-typen 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 Be-rechnungsgitter umgewandelt werden, mit welchen die spezifische Simula-tion umgehen kann. Üblicherweise handelt es sich hierbei um eine hoch-komplexe Arbeit, welche ein großes Expertenwissen voraussetzt.


Abb. 5.20. Übliches Vorgehen bei der Erzeugung und Evaluation virtueller Proto-typen

Nach Beendigung der Simulation folgt ein Post-Processing-Schritt, wel-cher die Daten für die darauffolgende Visualisierung vorbereitet. Beson-ders 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 er-reichbar 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 Prototy-pen erlauben, schon in einer frühen Entwicklungsphase Probleme zu er-kennen und zu beseitigen.

5.5.2 Online-Simulationen

Die Simulationen, welche im Rahmen des Prototyping durchgeführt wer-den 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 ge-schickt, welche die Ergebnisse errechnet und zur Weiterverarbeitung auf die Festplatte schreibt. Obwohl heute viele Simulationsaufgaben auf einem


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, Ten-denzen im Simulationsablauf schnell auszuwerten und unmittelbar Ein-gangsparameter ändern zu können, um einen umfassenden Überblick über die Produkteigenschaften zu erhalten. Die meisten Simulationspakete bie-ten die Möglichkeit, den Simulationsverlauf zu überwachen, erlauben aber kaum eine gleichzeitige, umfangreiche Visualisierung oder die Verände-rung 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-


den können. Direkt heißt in diesem Fall, dass Simulationen erste Ergebnis-se innerhalb einer Minute oder weniger zur Verfügung stellen. Interessant wird dies insbesondere, wenn in die laufende Simulation eingegriffen wer-den 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 ne-ben oder in dem Objekt und kann unmittelbar verschiedene Parameter än-dern. 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 weiterlei-tet. Was diese Art von Simulationen so interessant macht ist die direkte In-tegration von High-Performance-Computing-Ressourcen in den Rapid-Prototyping-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 Mo-dule als separater Prozess implementiert. Module können über eine graphi-sche 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 Maus-klicks zusammenstellen. Eine Besonderheit dabei ist, dass diese Module nicht auf einem einzelnen Rechner laufen müssen, sondern beliebig auf un-terschiedliche Computer verteilt werden können. Dies ist vor allem dann wichtig, wenn sehr große Datenmengen visualisiert werden müssen, wel-che einen großen Post-Processing-Aufwand benötigen. Auch bleiben so auf der Visualisierungsmaschine möglichst viele Ressourcen frei, um in-teraktive Frameraten bei der Darstellung zu erreichen.

Durch seinen modularen Aufbau eignet sich COVISE hervorragend, laufende Simulationen in den Auswertungszyklus zu integrieren und in-nerhalb der Visualisierung zu steuern. So wurde unter anderem in Zusam-menarbeit 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 interak-tiv zu optimieren [5.125]. Unter Zuhilfenahme eines ICEM HEXA-Gittergenerators können die Luftdüsen sogar an der Konsole frei verscho-ben 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,


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 so-genannte User Subroutines den Zugriff auf interne Datenstrukturen der laufenden Simulation. User Subroutines sind Funktionen, die, so sie imp-lementiert 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 Super-computer, auf dem die Simulation abläuft, und eine Visualisierungswork-station, welche das Post-Processing, die Darstellung und die Interaktion übernimmt. Im Regelfall würden diese Aufgaben auch auf verteilten Ma-schinen 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 COVISE-Modul, welches die Simulation auf dem Supercomputer startet, die Para-meter weitergibt und die resultierenden Daten von der Simulation entge-gennimmt. Das Modul übernimmt auch über Feedback-Nachrichten die Kommunikation mit der Virtual-Reality-Umgebung. In einem vollständi-gen Szenario würden noch weitere Komponenten ins Spiel kommen. So


sorgt ein spezielles Modul für die Parameteränderungen, welche die Geo-metrieerzeugung 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 im-mersiven Umgebung wie CAVE, Powerwall, Curved Surfaces oder Head Mounted Displays (HMD) anwendbar. Auch ist er über Module, sogenann-te Plugins, erweiterbar. Diese laufen jedoch nicht in einem eigenen Pro-zess, sondern sind als dynamische Bibliotheken zur Laufzeit ladbar. Über diese Plugins sind neue Funktionalitäten ohne Zuhilfenahme des vollstän-digen Sourcecodes des Renderers implementierbar. Sie sind auch dafür zu-ständig, Interaktionen aus dem Renderer an COVISE-Module über Feed-back-Nachrichten weiterzugeben. Diese Nachrichten können aus vielfältigen Quellen stammen:

Regler im VR-Menü können bewegt werden, um Parameter zu ändern. Spezielle Geometrien können als Ansatzpunkte für Interaktionen dienen. So kann im obigen Beispiel der Klimaauslegung des Fahrzeuginnen-raums die Einströmrichtung und -geschwindigkeit über das Bewegen der Pfeile manipuliert werden, welche an den Einströmdüsen angezeigt werden.Über einen TabletPC oder PDA können direkt Zahlenwerte eingestellt, Schieberegler bedient oder Optionen mittels Komboboxen ausgewählt werden.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 dreidi-mensionalen 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, las-sen sich diese Demonstrationen über das TabletUI zusammen mit vorberei-teten Flügen durch die Szene sehr elegant durchführen. PDAs eignen sich


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 Schie-beregler 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 inte-ressante 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 Freiheits-graden erfordern eine gewisse Einarbeitungszeit, danach kann jedoch oft effektiver damit gearbeitet werden. Abb. 5.24 zeigt als Beispiel einen drei-dimensionalen Interaktor für die Simulation der Klimaanlage im Fahrzeu-ginnenraum, 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 Tem-peratur der einströmenden Luft geregelt werden. Ein solcher Interaktor ist wesentlich intuitiver als reine Schieberegler oder Zahlenwerte, da Meta-phern verwandt werden, die der Erwartungshaltung des Benutzers entge-genkommen.


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

5.5.3 Hybride Prototypen

Werden reale Prototypen mit virtuellen Inhalten verknüpft, entstehen hy-bride 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 vorge-nommen, Informationen zu derzeit im Sichtfeld befindlichen Objekten eingeblendet oder andere Visualisierungen direkt am Produkt vorgenom-men 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 Mo-dells Parameter einer Simulation zu steuern, um so eine intuitive Eingabe-möglichkeit direkt am Produktprototypen zu haben [5.14].

Die Verfolgung der Objekte geschieht derzeit mit Hilfe spezieller Mar-ker, welche von Computer-Vision-Methoden leicht erkannt werden können und aus denen direkt die Position des Markers ermittelt werden kann. Das


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 Ver-zerrung berechnet, die bei der Rotation und Translation des Markers ent-steht. Direktes Tracking über die Analyse der Objektgeometrie, das die Verwendung von Markern unnötig werden ließe, ist derzeit noch nicht ro-bust 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 not-wendig 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 physi-scher 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) ei-nen 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


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 er-geben, 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 Um-gebung 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ög-lich macht.

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


Über hybride Prototypen können jedoch nicht nur Darstellungen an rea-len Objekten betrachtet werden, sondern auch beispielsweise Online-Simulationen gesteuert werden. So kann bei der Auslegung der Klimaan-lage (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 Fahr-zeuginnenraum 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 Simu-lation 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äch-lich 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 ver-folgten Objekten direkt die Gittererzeugung für eine Simulation beeinflus-sen kann. Durch Verschieben der Gegenstände in einem realen Modell kann gleichzeitig die Position der Geometrien im virtuellen Modell verän-dert 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ög-lich ist, wurde für die Supercomputing 2004 ein Modell des Messestandes des HLRS erstellt. Mit diesem Modell wurde eine Strömungssimulation


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 Proto-typen

In einer globalisierten Wirtschaft, in der immer mehr Teile der Produkt-entwicklung an Zulieferer oder um den Globus verteilte Außenstellen ab-gegeben 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 er-heblichem 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 virtu-elle 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ünf-tige 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, vir-tuelle 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 Ska-lierung zwischen den Partnern genau synchronisiert. Jeder Beteiligte kann in seiner Umgebung frei navigieren, die Positionsänderungen werden di-rekt an die übrigen Teilnehmer verteilt. Diese Art der Kopplung wird in COVER „Tight Coupling“ genannt und eignet sich insbesondere für klei-nere 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“)


und den Partnern größtmögliche Bewegungsfreiheit zu erlauben. Dadurch kann jeder die dargestellten Objekte aus dem Blickwinkel und mit der Ska-lierung 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 3D-Maus 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 Blick-richtung und der Gestik für die Partner schon sehr viel ableitbar ist und an-dererseits das Objekt, welches betrachtet wird, nicht zu sehr durch die A-


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 Hand-bewegung des Avatars übermittelt. Auch können virtuelle Marker an dem Objekt befestigt werden, um besondere Regions-of-Interest zu kennzeich-nen.

Abb. 5.30. Eine kollaborative Sitzung mit Videoconferencing

Kommuniziert wird nicht nur über Gestiken, sondern auch über Audio- oder Videoconferencing. Wird ein Videoconferencingtool verwandt, ist es bei einer immersiven Umgebung wie einer CAVE wichtig, dass das Video-fenster 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 ausrei-chend, die Videofenster regulär neben der dreidimensionalen Darstellung anzuzeigen. Auf diese Art und Weise lässt sich mit den verschiedenen Pro-jektpartnern 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 quali-tativ hochwertige Audioverbindung.

Auch hybride Prototypen lassen sich kooperativ auswerten [5.16]. Abb. 5.31 zeigt ein Szenario, in der eine Luftströmung in einer Innenstadt-situation visualisiert wird. Die Marker repräsentieren zum einen Objekte, welche sich auf dem Platz zwischen den Gebäuden befinden, zum anderen


bestimmen sie die Position virtueller Objekte wie Schnittflächen oder Par-tikelbahnen, welche die Ergebnisse der Simulation visualisieren. Das Er-gebnis 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 Interakto-ren in der virtuellen Umgebung mit der Visualisierung arbeiten. Auch das physische Manipulieren der Objekte kann ermöglicht werden, wie Unter-suchungen von Brave et. al. [5.23] zeigen.

Abb. 5.31. Kollaborative hybride Prototypen


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 Verbesserun-gen, die für einen solchen wichtig und wünschenswert wären, gibt aber dennoch Anregungen, die derzeitigen Prozesse auf Flaschenhälse und Rei-bungsverluste hin zu untersuchen und zu überdenken.


Ein anderer Bereich, der ein möglicher Ansatzpunkt wäre, um den RP-Prozess zu verbessern und zu beschleunigen, wäre beispielsweise eine noch bessere Durchgängigkeit zwischen CAD – Gittererzeugung – Simula-tion und Visualisierung. Dies ist jedoch nur mit etablierten Standards mög-lich, nicht nur im Bereich der Dateiformate sondern auch in der Anbin-dung externer Programmmodule an die jeweiligen Applikationen, welche von jedem Hersteller verfolgt werden. Derzeit finden sich nur Insellösun-gen, die für eine beschränkte Anzahl an Programmpaketen funktionieren, aber keine umfassende Austauschbarkeit gewährleisten.

Hybride Prototypen bergen viele im Entwicklungsalltag noch ungenutz-te Potenziale. Der Vergleich zwischen Simulation und Experiment wird sehr vereinfacht. Für die Entwickler eröffnen sich neue Interaktionsmög-lichkeiten, 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 Ein-satz 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 Positi-on zu verfolgen. Die benötigten Marker jedoch sind meist unhandlich, dür-fen nicht verdeckt werden und überdecken zudem selbst teilweise die Ge-ometrie.

Parallele Renderingverfahren eignen sich hervorragend, auch ohne ver-lustbehaftetes 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 bei-spielsweise die Entwicklung eines Raytracers in Hardware. Der Vorteil ei-nes Raytracers ist es, dass der Zeitaufwand beim Rendern komplexer Sze-nen 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 we-sentlich 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 Admi-nistrationsaufwand 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 ih-re Stärken nicht nur in der schnellen Produktentwicklung aus, sondern auch in anderen Bereichen. Parallele Renderingmethoden sind auch im Be-reich 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ön-nen 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


Der Entwurfsprozess in den frühen Phasen der Produktentwicklung um-fasst 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 Produktkonzep-tion und der Produktausarbeitung – insbesondere in informationstechni-scher 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


das Produkt und seine Funktionalität (Produktgestaltung). Im Ergebnis lie-gen erste Entwürfe in Konzeptmodellen vor, die Varianten in Form und Funktion repräsentieren und deren Herstellung bisher fast nur per Handar-beit 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 detaillie-rende CAD-Modellierungsschritte rechnerintern zu geschlossenen Volu-menbeschreibungen - 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 De-signer zu ermöglichen Rapid Prototyping-Verfahren und weitere Werk-zeuge 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 infor-mationstechnische 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 Parallelisie-rung von Teilprozessen funktioniert nur mit einem konsequent durchgän-gigen und vollständigen Informationsaustausch in einer hybriden Modell-welt 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 RPD-Prozess muss deshalb eine Angleichung der unterschiedlichen Modellkon-zepte von Designern und Konstrukteuren betrieben werden. Das Konzept-modell, Ergonomiemodell und das Designmodell des Designers muss zum Konzeptmodell des Konstrukteurs werden, das ohne Informationsverluste in den Geometrieprototypen und/oder Funktionsprototypen zum Ausarbei-ten des CAD-Modells überführt werden kann.

Gleichzeitig müssen neue rechnerinterne Modellstrukturen aufgebaut werden (z.B. virtuelle Skizzen, Feature-Modelle). Dabei muss dem Um-stand Rechnung getragen werden, dass auch (im Sinne von CAD) unvoll-ständige Designermodelle und beliebige Messpunktwolken von Objekten schnell und datensicher zu Volumenmodellen (Solids) für das Rapid Proto-typing aufgebaut werden können [5.168]. Spezielle Anstrengungen gelten hier einer automatischen Bearbeitung, um die Schnelligkeit der Herstel-lung mittels Rapid Prototyping nicht einzuschränken. In der Concept Mo-delling-Anwendung, wo die entwicklungsnahe Umsetzung von noch nicht


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

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 techni-scher Sicht wird damit die Überführung seiner (auch sehr frühen) Konzep-te in Vor-CAD-Modelle unterstützt und über die Schaffung einer neuarti-gen Hybridkommunikationsplattform die Zusammenarbeit mit dem Konstrukteur verbessert [5.168].

Das umfasst die Möglichkeit, die noch unvollständig ausgeprägten Kon-zeptmodelle als Prototypen zu realisieren. Dabei werden Verfahrenskom-binationen und/oder Multi Material Modelling-Verfahren eingesetzt, wobei aber zwingend eine geschlossene Volumenbeschreibung mit verfahrens-steuernder Segmentierung der Oberfläche erforderlich ist [5.95]. Die un-terschiedlichen Modellebenen, die sich in handgefertigten Kreativ- und Konzeptmodellen und daraus abgeleiteten rapid-prototyping-fähigen Mo-dellen 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.

Erprobung Berechnung Konstruktion Entwurf/ Design

Entwicklung / Ausarbeitung Konzeption Planung /

Definition Idee

Konzeptmodell

Ergonomiemodell

Designmodell

Funktionsmodell

Prototyp

Muster

nach

VD

ID

Konzeptmodell

Geometrieprototyp

Funktionsprototyp

Technischer Prototyp

nach

N

CG

na

ch V

DI2

221


Das Vorgehen: Die informationstechnische Integration des Entwurfs-prozesses 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 Pro-duktes 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-, Ergonomie- und Designmodellen weiterentwickelt werden. Der Designer kann so ei-nerseits 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 Basisent-wurf widerspiegeln, bietet sich dem Designer außerdem die Möglichkeit der Ausarbeitung verschiedener Detailentwürfe, die vergleichbar und so-mit bewertbar sind.


Des Weiteren bieten spezifisch abgestimmte und insbesondere auch ge-eignet 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 Konzeptmodel-le basieren noch nicht, wie erwähnt, auf vollständigen, skalierten Produkt-daten, sondern dienen dazu:

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 Integra-tionsstrategien ab, die den iterativen Einsatz physischer wie virtueller Mo-delle unterschiedlicher Ausprägung (in hybriden Modellstrukturen) umfas-sen und somit einen Modellwechsel mit unterschiedlicher Informations-tiefe ermöglichen sollen. Die informationstechnische Unterstützung bezieht sich auf die Prozesse Digitalisieren und Rekonstruieren geometri-scher Elemente und Sachverhalte. Die Erweiterung aktueller Digitalisier-strategien muss dabei typische Anforderungen wie die Feature-Bear-beitung und die Einbindung unvollständiger und unscharfer Produktdaten berücksichtigen. Daraus ergeben sich neue, produktspezifische Anwen-dungen 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 wesent-licher Entwurfsschritt, der einerseits frei kreativ ist, andererseits bereits ei-ner Reihe unterschiedlicher Rahmenbedingungen (z.B. funktionale Vorga-ben) unterliegt. Bislang existiert keine zuverlässige, klassifizierte Zuordnung von Formkonzepten und geometrischen Strukturen. Eine frühe-re Untersuchung von Anforderungen an die in dieser Frühphase der Pro-duktentwicklung eingesetzten virtuellen Modelle ergab jedoch, dass als formgebende Merkmale Objektkonturen modelliert werden, die mit weite-ren Querschnitts- oder Silhouette-Informationen zum Körpermodell wei-terentwickelt werden [5.169].

Daher müssen festgelegte Merkmale wie Gestaltungslinien oder Licht-kanten sowie grobe Umrisse oder Texturen erfasst werden. Für die neue


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 Punkt-wolken auf der Oberfläche, die deren kartesische Koordinaten in einem de-finierten 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 Volumenbeschrei-bung 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 Design-Linien und Design-Elemente unter ganz bestimmten Beleuchtungs-bedingungen - das sind Lichtkanten auf dem Objekt [5.154]. Das Vorge-hen 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 Ver-knüpfung von (2D-)Bilddaten und 3D-Objektkoordinaten zulassen. Der re-sultierende Aufbau einer Digitalisierstation für den Designer muss weiter-hin 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 Ka-merablickrichtungen errechnet werden, sich in einem gemeinsamen Koor-dinatensystem befinden. Dies ist für eine einfache, designgerechte Run-dumerfassung von Objekten wichtig. Die Wahl des Sensors schränkt aber


das Ergebnis der Arbeiten nicht ein. Jeder optische Sensor, der diesen An-forderungen 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 Entste-hung von Lichtkanten auf Designermodellen voraus. Die Idee geht auf Aussagen von Designern zurück, wonach Lichtkanten die Form eines Pro-duktes in der menschlichen Wahrnehmung prägen. In einem ersten Ar-beitsschritt 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 we-nig 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 be-rü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ünsti-gen Beleuchtungsverhältnissen für die 3D-Erfassung ergaben (zum Bei-spiel durch die für ein kontrastreiches Hervortreten von Gestaltlinien not-wendige flache Beleuchtung), wurden durch Anpassen der Messanordnung gelöst. Wo dies nicht möglich war, wurde eine Lösung durch die Aufnah-me 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 gegen-sätzliche Materialien, wie zum Beispiel Hartschaum.

Für die Extraktion und Auswertung der Design-Linien lagen folgende Daten vor:

(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 dienendie Grauwerte der einzelnen Bildpunkte die zu jedem Bildpunkt (2D) gehörigen kartesischen Koordinaten im Raum.


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 Be-schreibung der Bildaufnahme mit dem eingesetzten Kolibri-Messsystem. Jede Kameraposition liefert Bilder mit variierenden Beleuchtungssituatio-nen. Abhängig von der Beleuchtungsrichtung erscheinen in den Aufnah-men 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 zu-rückgehen und für die Extraktion der Feature-Linie nicht in Betracht gezo-gen werden sollten. Der entwickelte Algorithmus muss also bestimmte Lichtkanten verbinden und andere eliminieren können. Dies wird unter an-derem durch eine Parallelitätsbetrachtung unter Berücksichtigung des Ab-standes 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 Kantenope-

rator (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 unterschiedli-chen Beleuchtungsbedingungen, um Schattenkanten zu eliminieren.


4. Die in dieser Art bereinigten Kontursegmente sind noch unterbrochen. Also: Suche die längste zusammenhängende Kontur, die die Feature-Linie 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 3D-Kontur aus der Punktwolke.

Mit diesem Vorgehen können alle beleuchteten Objektkanten, auch die-jenigen, die einen Radiusverlauf haben oder nur eine schwache Krüm-mungsänderung zeigen, mit für die Aufgabenstellung ausreichender Ge-nauigkeit 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 Entfer-nungsbilder. Da hier eine dichte Messpunktwolke zugrunde gelegt werden muss, um relevante Ergebnisse zu erzielen und darüber hinaus nur Objekt-kanten gleicher Krümmung sicher extrahiert werden können, ist dieser An-satz 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 (PROFORM-DESIGN)

Wire Frame-Modellierer

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


wird semi-automatisch, eine die Topologie des Objektes beschreibende, geschlossene Wire Frame-Darstellung generiert. Hierfür wurden verschie-dene Funktionen implementiert, mit denen die aus den einzelnen Kamera-ansichten extrahierten 3D-Konturen, die nicht von einer topologischen Segmentierung des Objektes herrühren, vervollständigt und stetig ge-schlossen 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 Kameraan-sichten 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 Punkt-wolke nutzen. Darüber hinaus besteht die Möglichkeit auszuwählen, ob Lücken automatisch oder manuell überbrückt werden sollen. Die automati-sche Methode ist insbesondere bei kleinen Unterbrechungen des Kurven-verlaufes 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 3D-Modell weiterentwickeln, ohne zuvor ein komplettes CAD-Modell gene-rieren zu müssen.

Dabei musste beachtet werden, dass das in diesem Entwicklungsschritt aus dem virtuellen Wire Frame-Modell abgeleitete Flächenmodell nicht


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ültig-keitserklärung der Eingangsmodelle beschreibt [5.121]. Die in der Recher-che 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 entspre-chend plausibel aufgebauten Geometriemodellen die Fehler von entspre-chend verfügbarer Rapid Prototyping-Software bereits weitestgehend au-tomatisch behoben werden können. Die Anstrengungen mussten deshalb auf die Erzeugung plausibler Geometriemodelle gelegt werden.

Hierzu wurde zunächst auch kommerziell verfügbare Software herange-zogen, um die Flächen des virtuellen Designmodells zu Volumen zu erwei-tern. Beispielhaft wurde dazu die Software Magics 7.0 benutzt. Hier kön-nen über die Basisfunktionen:

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 funktio-nierte 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 imple-mentierten Methoden zur Umwandlung von Flächenmodellen in Volu-menmodelle.

Hier muss ein volumenorientierter Ansatz zum Einsatz kommen. Bishe-rige Lösungen basieren auf der Erzeugung eines geschlossenen Flächen-modells (meist im STL-Format). Prinzipiell ist auch die Verwendung di-rekter 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-


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 re-gelgeometrischer Grundkörper in den Punktwolken. Hierfür existieren be-reits einzelne Softwarelösungen, die aber den Anforderungen noch nicht genügen.

Solid-Extraktion

Die Ziele der Arbeiten fokussierten deshalb auf das Erfassen und Model-lieren von Solids zur direkten volumenorientierten Beschreibung von Pro-dukten. Das Erfassen stützt sich dabei auf multisensorielle geometrische und visuelle Information. Für die Beschreibung wurden Verfahren zur se-mi-automatischen Extraktion und anschließend automatischen und hoch-genauen Einpassung regelgeometrischer Objekte entwickelt.

In einem ersten Schritt wurden zur Erfassung geeignete Sensoren einge-setzt. 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 Digitalisie-rung wurden Verfahren aus der Bildverarbeitung genutzt.

Im nächsten Schritt erfolgt die 3D-Segmentierung. Für die Segmentie-rung wurden die bereits entwickelten Verfahren zum Erfassen von Gestalt- und 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 vorhande-nen Verfahren zur Extraktion von Feature-Linien untersucht. Das ergab, dass die Feature-Linien in der Form von Kurven weniger geeignet sind, je-doch 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 re-gelgeometrisches Objekt interpretieren. Die eigentliche Trennung in ein-zelne Punktwolken erfolgt durch ein Region Growing-Verfahren. So kön-nen schon mit diesem einfachen Verfahren der groben Trennung in


gekrümmte und ebene Bereiche Segmentierungen vorgenommen werden, deren Punktmengen einzelne Objekte interpretieren.

Auf dieser Basis wurde eine Strategie für eine automatische Segmentie-rung entwickelt. Die Strategie beachtet, dass Bereiche starker Krüm-mungsä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üm-mung (Punktwolkensegmentierung über Region Growing und Schwell-wertbestimmung) wurden zu einem Verfahren zur automatischen Segmen-tierung von Messpunktwolken zusammengeführt. Das Region Growing-Verfahren 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 Software-Systeme ü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) er-folgt auf der Basis von am IFF entwickelten Algorithmen zur automati-schen Best Fit-Einpassung von regelgeometrischen Elementen.


Diese Best Fit-Algorithmen, die ein flexibles, effizientes und genaues Einpassen beliebiger Kurven und Flächen in eine 3D-Messpunktwolke er-möglichen, wurden ursprünglich für den Bereich der Messtechnik entwi-ckelt und sind daher hochgenau. Die Algorithmen basieren auf der Metho-de der Least Squares-Approximation und minimieren die Summe der quadratischen orthogonalen Abstände der Punktdaten zu der zu identifizie-renden 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 Punktwolkenverar-beitung und Visualisierung, integriert. Das erlaubt den Aufbau und die Nutzung iterativer Modellstrukturen (Entwurfsmodelle des Designers, ab-geleitete virtuelle Modelle). Durch die Implementierung einer grafischen Benutzungsoberfläche wird die Durchführung von Versuchen mit unter-schiedlichen Parametern zur Kanten- und Feature-Linienextraktion erleich-tert. Gleichzeitig können Daten mit anderen CAx- oder Rapid Prototyping-Systemen ü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.


Für die Realisierung der aus Sicht des Projektes innerhalb von Rapid Pro-duct Development (RPD)-Prozessketten aktiven fünf Hauptstrategien, die auf den Durchlauf vieler, schneller Entwicklungszyklen als aktives Pro-zesselement, auf das Einbeziehen eines frühen Ergebnis-Feedbacks, auf


eine Betonung früher Entwicklungsphasen, auf das Erarbeiten alternativer Produktkonzepte und auf die Vorverlegung des Zeitpunktes der Produkt-spezifikation 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 Produkt-entwicklung 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 rechnerin-tern-virtuellen Welt und ihren Technologien. Im Ergebnis werden insbe-sondere deutlich mehr Entwicklungszyklen als in der konventionellen Pro-duktentwicklung ermöglicht, was einerseits die schnelle Erarbeitung alternativer Konzepte für das Produkt mit sich bringt und andererseits Ent-scheidungen zur Produktauslegung und –spezifikation praktisch zu belie-bigen Zeitpunkten ermöglicht. Das bedeutet auch ein früheres Ergebnis-Feedback und führt, im Gegensatz zur konventionellen Produktentwick-lung, 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:

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 unter-schiedlichen Stellen im Entwicklungsprozess in unterschiedlicher Dichte und Detailtreue erzeugt. Ihre Analyse zeigte schon in der oben genannten Prozesskette deren iterativen, aber auch stark anwendungsorientierten Cha-rakter. Zum Beispiel wurde in einer Auflistung der Forderungen an CAD-Systeme gezeigt, dass eine reine Weitergabe von Facettenflächen (STL-Daten) im dynamischen RPD-Prozess nicht ausreichend ist.

In der Betrachtung der Entwurfs- und Konzeptionsphase gilt das insbe-sondere, 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 RPD-Prozessketten in den Schritten:


Daten- und informationstechnische Integration des Entwurfsprozesses Multi Material Modelling für den iterativen Aufbau von konzeptionellen Prototypen 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 RPD-Prozesskette 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-CAD-Flächenmodells wird in Abb. 5.39 am Beispiel einer Luftdüse demonst-riert.

5.6.4 Ausblick

Die Verknüpfung unterschiedlicher Eigenschaften und Funktionalitäten in einem konzeptionellen Prototypen gelingt nur durch die Verwendung meh-rerer unterschiedlicher Materialien. Das Multi Material Modelling er-schließ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 Funk-tionalitä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 Eigen-schaftsprofilen auszustatten.

Einen Schritt weiter geht die Verwendung von gradierten Materialien, die Prototypen mit kontinuierlich verlaufenden Eigenschaftsprofilen er-möglichen. Visionäres Ziel ist hierbei die Herstellung individualisierter und auf spezielle Anwendungen exakt zugeschnittener Produkte.

Die RPD-Prozesskette muss dazu weiter zur Produktentstehungs-prozesskette qualifiziert werden, was insbesondere die Weiterentwicklung des Rapid Prototyping zu einem Rapid Manufacturing-Verfahren beinhal-tet. 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, auf-grund immanenter gestalterischer Freiheiten optimierte Produkte zu erzeu-gen. 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 Funktions-prototypen

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


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 Ent-wicklungsstadien 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 Arbeitser-gebnisse 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 Ba-sis konventioneller Designarbeiten, wie Skizzen oder handgefertigten Formmodellen, muss in den Rapid Product Development-Prozess integriert werden. Es soll hierdurch ermöglicht werden aus „unscharfen“ Produktda-ten und somit, im Hinblick auf CAD-Systeme, unvollständigen Entwurfs-modellen, 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 zu-sätzliche Möglichkeiten des Verifizierens und Präsentierens seiner Model-le 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 Basis-modell, 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-


rial auf mit kommerziellen Rapid Prototyping-Verfahren gefertigten Bau-teilen die bereits das Grunddesign widerspiegeln. Je nach Umfang der ge-wünschten Weitergestaltung und des Volumens des Bauteiles besteht je-doch 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 ferti-gen [5.96]. Die Versuchsanlage besteht hierzu aus zwei separat arbeiten-den 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 ei-ne Computersteuerung wird die Verfahrbewegung der Achsen und somit der Bauplattform durchgeführt.

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


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 Steuerpro-grammes wird die Geometrie des zu generierende Bauteiles in Schichten unterteilt und Steuerinformationen erzeugt. Die reinen Verfahrinformatio-nen 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 thermoplasti-schen 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 dauer-haft [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 wer-den.

Für den o.g. Anwendungsfall, einem Designer mehrere identische Ba-sismodelle für eine weitere kreative Ausarbeitung zur Verfügung zu stel-len, wurde das MMM-Verfahren dazu eingesetzt, einen stabilen Grund-körper aus thermoplastischem Werkstoff zu erzeugen und diesen mit einer verformbaren Oberfläche aus Modellierclay zu versehen. Da das MMM-Verfahren, 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 um-hüllenden Modell in der gewünschten Stärke des Modelliermaterials ver-sehen. In der Anlagensteuerung werden anschließend die Schicht-informationen 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 ei-ner Grundidee verschiedene Gestaltungsvarianten zu erarbeiten und zu vergleichen.


5.7.2 Funktionalisierung von Prototypen durch das Multi Mate-rial Modelling

Ein Ziel innerhalb des Rapid Product Development ist es, bereits frühzeitig alle relevanten Eigenschaften des späteren Endproduktes anhand verschie-dener Prototypen und Modelle zu überprüfen. Funktionsprüfungen an ein-zelnen Prototypbauteilen sind inzwischen durch die Wahl eines geeigneten Fertigungsverfahrens meist ebenso realisierbar wie die einfache Bemuste-rung, die die ersten RP-Verfahren zum Ziel hatten [5.140], [5.97]. Ein wei-terer 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 Pro-totyps 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 ei-ne 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 Proto-typen an sich und die umgebende Supportstruktur zur Abstützung. Hier-durch wurde es bei einigen Verfahren ermöglicht, das eigentliche Bauteil vom stützenden Supportmaterial einfacher als bisher zu lösen. Beispiels-weise durch die Verwendung wasserlöslicher Werkstoffe für die Stütz-strukturen 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 Po-tenzial 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


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:

Kombination von hartem und weichem Werkstoff (direktes Einbringen von Dichtungen, weiterbearbeitbare Grundmodelle (s.o.)) Kombination nicht haftender Werkstoffe (Bewegliche Baugruppen) Kombination haftender Werkstoffe (Ästhetische oder haptische Eigen-schaften, Werkstoffe für partielle metallische Beschichtung ohne Mas-kierung)

Gerade die Einsatzmöglichkeit des Verfahrens für eine partielle metalli-sche 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 ästheti-sche Eigenschaften von Bauteilen, die über eine metallische Beschichtung erzeugt werden, könnten einfacher und vor allem schneller prüfbar ge-macht werden und somit den Rapid Product Development Prozess unter-stützen.


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 alle-rerster Linie für eine Bemusterung von Bauteilen entwickelt wurden, sich immer mehr in die Richtung der Fertigung von seriennahen, voll einsetzba-ren Prototypen bewegten. Es wurde schnell klar, dass sich durch die Spezi-alisierung der Verfahren auf einige wenige Werkstoffe eine Lücke auftat. Anwendungsgebiete wurden gesucht und das Verfahren prototypisch reali-siert. Mit der realisierten Versuchsanlage ist es möglich, mit zwei unter-schiedlichen Werkstoffen ein Bauteil generativ zu fertigen. Prinzipiell be-steht 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 Aus-bringung aus einer Düse eine gezielte Durchmischung in veränderlichen Volumenanteilen erreicht und somit weitere Anwendungsgebiete erschlos-sen 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 STL-Datenformat hat den entscheidenden Nachteil, dass ausschließlich Geo-metrieinformatinen zur Verfügung gestellt werden. Die Möglichkeit inner-halb moderner 3D-CAD-Systeme Bauteilbereiche zu selektieren und die-sen bestimmte Eigenschaften zuzuordnen besteht bereits. Eine Zuordnung und informationstechnische Weiterverarbeitung von Werkstoffinformatio-nen 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 Verfah-ren wie das Multi Material Modelling zum Einsatz kommen sollen.

5.8 Oberflächenveredelung von RP-Bauteilen


Zu Beginn der Entwicklung und Produktion von RP-Teilen hat sich die Forschung und Industrie stark auf die Fertigung von Design- und An-schauungsmodellen konzentriert. Dazu parallel hat sich das Einsatzgebiet von generativ gefertigten Bauteilen immer stärker erweitert. Mit der fort-schreitenden Entwicklung neuer Materialien und Verfahren zur Produktion von RP-Teilen (Kap. 5.7 und 5.9) rücken ganz neue Einsatzgebiete für ge-nerativ 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 Kunststoff-spritzgussformen zur Produktion von Kleinserien aus Stahlpulver gesintert und danach direkt als Werkzeug eingesetzt [5.112].


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 gefer-tigte Bauteile gestellt, die oft durch Verfahren aus der Oberflächen-technologie 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 deko-rative Anforderungen unterteilt. Dabei sind:

Funktionelle Anforderungen

KorrosionsbeständigkeitVerschleißbeständigkeitGleiteigenschaften RauheitHärteFestigkeitDichteLeitfähigkeit

Dekorative Anforderungen

FarbeGlanzDeckvermögen RauheitEinebnung

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


5.8.3 Verfahren zur Veränderung der Eigenschaften von Ober-flächen

Die Oberflächentechnologie umfasst Verfahren der Oberflächen-behandlung 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 Ei-genschaften (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ächeneigen-schaften voraus.

Abb. 5.41. Verfahren der Oberflächentechnik


5.8.4 Lösungsansätze zur Funktionalisierung von RP-Bauteilen

Im Rahmen des Sfb 374 wurden Verfahren zur Oberflächenreinigung, O-berflächenveränderung und Verfahren zur Erzeugung von metallischen Schichten sowie keramischen Schichtsystemen auf RP-Bauteilen unter-sucht. Diese Verfahren können schematisch in drei Grundverfahren einge-teilt werden (s. Abb. 5.42.). Neben den Verfahren der Beschichtung von RP-Bauteilen wurden auch Verfahren zur Vorbehandlung und zur geziel-ten 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ünsti-gen Verarbeitbarkeit haben Kunststoffe Metalle in vielen Anwendungsbe-reichen verdrängt. Den genannten Vorteilen stehen aber auch gewisse Nachteile gegenüber. Dies gilt insbesondere für die Oberflächen-eigenschaften einiger Kunststoffsorten. So genügen Kunststoffe oft nicht den dekorativen Anforderungen oder sind einem Verschleiß durch Rei-bung und Gebrauch nicht dauerhaft gewachsen. Diese Nachteile können durch eine metallische Beschichtung der RP-Bauteile ausgeglichen wer-den. Der Haftungsverbund zwischen metallischer Beschichtung und Kunststoffsubstrat ist bei unbehandelten Bauteilen aber oft ungenügend. Dies liegt an den unterschiedlichen thermischen Ausdehnungskoeffizien-


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 ver-mindert 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 ermit-telten Untersuchungen vor allem eine Verfahrenskombination [5.111], [5.109] aus:

Reinigung der Kunststoffsubstrate von Verunreinigungen Erhöhung der Oberflächenenergie der Substrate

Eine erste Reinigung findet in der Regel nasschemisch in einem Ultra-schallbad statt. Hier wurden verschiedene wässrige und nichtwässrige Rei-niger untersucht. Es hat sich gezeigt, dass die Schichthaftung in erster Li-nie 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 Reinigungser-gebnis hat. Wichtig ist nur, dass eine Reinigung zur Entfernung der anhaf-tenden Verunreinigungen stattfindet [5.164].

In einem zweiten Prozessschritt findet in einem Niederdruckplasma eine Feinstreinigung und Oberflächenmodifizierung statt. Dabei kommen Pro-zessgase wie Argon, Sauerstoff, Stickstoff, Wasserstoff, Luft und Ammo-niak 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 Be-reich zwischen 1*10-3mBar und 5 mBar. Die Behandlungsdauer beträgt in der Regel nur wenige Sekunden bis einige Minuten. Die im Plasma gebil-deten energiereichen Spezies des Prozessgases sowie die Vakuum-UV-Strahlung führen zu unterschiedlichen Reaktionen mit dem RP-Bauteil. Die Teilchenenergie von Ionen kann in einem Radiofrequenz-Plasma eini-ge 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 Poly-merradikale entstehen. Diese können ihrerseits wieder neue Bindungen eingehen. Reaktive Teilchen der Prozessgase können mit dem Polymer re-agieren und funktionelle Gruppen bilden, beispielsweise Carbonyle, Car-boxyle oder Hydroxyle. Diese Gruppen haben einen stark polaren Charak-


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 Para-meter Gasart, Prozessdruck, Ätzzeit und Anregungsfrequenz an das vorzu-behandelnde RP-Bauteil angepasst sein [5.107]. Am IFF haben dazu meh-rere Untersuchungsreihen mit variierenden Kunststoffarten, Schichtma-terialien, 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 Ver-fügung. Generell kann aber zwischen

Chemical-Vapour-Deposition (CVD) und 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 beschich-tenden Bauteil entsteht, wird beim PVD-Prozess das Schichtmaterial phy-sikalisch in die Dampfphase überführt und schlägt sich durch Kondensati-on 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 Grund-verfahren unterteilt werden: Aufdampfen, Kathodenzerstäuben (Sputtern) und Ionenplattieren. Beim Aufdampfen und Sputtern wird die Schicht durch überwiegend elektrisch neutrale Teilchen aufgebaut, die verfahrens-bedingt 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äh-rend der Transportphase durch eine an das Bauteil angelegte Spannung (Biasspannung) in ihrer Geschwindigkeit gezielt beeinflusst werden kön-nen. Aufgrund der deutlich höheren Teilchenenergien werden Keimbil-dung, 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-


nationen unterteilt werden. Im Rahmen des Sfb kamen aber vorwiegend die Verfahren

Anodisches Lichtbogenverdampfen (PLASCO®-Verfahren), Lichtbogengestütztes Aufdampfen (VALICO®-Verfahren) und das Kathodisches Lichtbogenverdampfen (Arc-PVD) zum Einsatz

Beim anodischen Lichtbogenverdampfen wird das Schichtmaterial durch auftreffende Elektronen stark erhitzt und verdampft. Die dabei ent-stehende Metalldampfwolke wird durch weiterhin auftreffende Elektronen anschließend partiell ionisiert. Der Ionisationsanteil des Beschichtungsma-terials 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 Beschichtungs-materials ist mit den Werten des anodischen Lichtbogenverdampfens ver-gleichbar.

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 beschleuni-gen. Diese Verfahren ermöglichen die Abscheidung dünner metallischer


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 Schich-ten 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 Kondensati-onswä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 Eigenschaf-ten von Bauteilen verbessern lassen. Galvanische Verfahren benötigen a-ber 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 hoch-glä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 be-schichten.

Chemische Beschichtung / außenstromlose Metallabscheidung

Eine Möglichkeit, auch nichtleitende RP-Bauteile in einem nass-chemischen Prozess zu metallisieren stellt die chemische Abscheidung von Nickel oder Kupfer dar. Bei diesem Verfahren handelt es sich um ein nass-chemisches Verfahren ohne eine äußere Stromquelle [5.149]. Das zu be-schichtende RP-Bauteil wird mit Palladium bekeimt. An dieser Palladium-bekeimung kann eine Anoden/Kathodenreaktion stattfinden. Es findet am Palladiumkeim eine Oxidation von [H2PO2] und [H2O] zu [3H+]; [HPO3]2


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 Kunst-stoffbauteilen 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 Kunst-stoffen zur selektiven Schichtabscheidung entwickelt. Durch diese Verfah-ren 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. Chemisch-außenstromlose Prozesse benötigen zuerst umfangreiche Voruntersuchun-gen, welche für jeden einzelnen Kunststofftyp durchgeführt werden müs-sen. 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 klei-nen Stückzahlen vorliegen, musste eine andere Möglichkeit gefunden wer-den, um eine leitfähige Startmetallschicht auf das Kunststoffbauteil aufzu-bringen. 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 di-cken metallischen Schicht versehen werden. Diese Technologie wurde im Rahmen der Forschungsprojekte „Erforschung der Verfahrenskombination zur Erzeugung elektromagnetisch schirmender Schichten“ und „Metallisie-rung faserverstärkter Kunststoffe mittels kombinierter galvanischer / phy-sikalischer Beschichtungsverfahren“ entwickelt.

Dazu eignen sich die im Haus erforschten und weiterentwickelten PVD-Prozesse. Durch angepasste Vorbehandlungs- und Beschichtungs-technologien wird es möglich, eine dünne, haftfeste Startmetallschicht auf Kunststoffbauteile abzuscheiden. Diese Prozesse eignen sich gut für kleine


Stückzahlen und erlauben eine schnelle Beschichtung und Fertiggalvani-sierung von RP-Bauteilen. Hier wurden besonders die Verfahren des ano-dischen Lichtbogens und der Arc-Verdampfung untersucht. Besondere Er-folge zur Steigerung der Haftfestigkeit von Metall auf Kunststoff konnte durch die Nachrüstung der Arc-PVD-Anlage mit einem Mikrowellengene-rator 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 Schich-ten wurde dadurch ermöglicht.

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

Außenstromlose Beschichtung mit anschließender galvani-scher Nachverstärkung

Diese Prozesskombination ist besonders für hinterschnittene und / oder komplex geformte Bauteile interessant. Da sich eine Startmetallschicht un-abhängig von elektrischer Feldverteilung abscheiden lässt. Auch bei immer wiederkehrender Beschichtung von RP-Bauteilen aus dem gleichen Kunst-stoff stellt dieses Verfahren eine interessante Variante dar, da es bei festge-legten, prozesssicheren Parametern mit geringerem Aufwand zu betreiben ist als eine PVD-Startmetallisierung.

Da das Schichtmetall und der darunter liegende Kunststoff unterschied-liche Ausdehnungskoeffizienten haben, kam es zu Beginn der Untersu-chungen immer wieder zu Schichtablösungen, sobald das RP-Bauteil wie-


der auf Raumtemperatur abgekühlt wurde. Wichtig war hier besonders ei-ne Entwicklung zu niederen Badtemperaturen bis auf ca. 30°C. Erst durch diesen Schritt konnten haftfeste Grundmetallschichten auf Kunststoff RP-Bauteilen erzeugt werden. Das anschließende Nachgalvanisieren erfolgt in Hochglanz-Nickelbädern. Aus Korrosionsschutzgründen kann als End-schicht zusätzlich eine Chromschicht aufgebracht werden.


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 verschiede-nen 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 Bau-teile können direkt galvanisch beschichtet werden und sind dadurch etwas einfacher beschichtbar. Da nun Verfahren zur Verfügung stehen, um RP-Bauteile zu beschichten, wird seit einiger Zeit eine Markteinführung dieser Prozesse angestrebt.

Ein zukünftiges Ziel wird es sein, die Verfahren prozesssicherer zu ges-talten. Im Haus werden zurzeit Untersuchungen unternommen, um die je-weils passenden Parameter für die in den Versuchen eingesetzten indus-triellen Anlagen zu ermitteln.

Anfang diesen Jahres wurde die Arc-PVD-Anlage mit einem Mikrowel-lenplasmagenerator 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 Schichtcharakte-ristik bei der Beschichtung selbst in Bezug auf die Haftfestigkeit und Ho-mogenitä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


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än-dert hat sich aber gerade in den letzten Jahren die Geschwindigkeit, mit der ihre Herstellung erfolgt. Immer kürzer werdende Produktlebenszyklen er-fordern 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 Materi-als eingeschränkt. Daher muss insbesondere bei Prototypen aus metalli-schen Werkstoffen oft auf alternative Werkstoffe ausgewichen werden. Hier wurden jedoch beim Lasersintern in den letzten Jahren deutliche Fort-schritte 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 me-tallische Prototypen herzustellen. Besonders interessant ist dabei die Mög-lichkeit 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än-derungen 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 o-der 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 geeig-netes messtechnisches Equipment zur Verfügung stehen, das die Beobach-tung des Prozesses und damit auch eine Qualitätskontrolle ermöglicht. Ide-alerweise ließen sich diese Kenntnisse in einer Prozessregelung umsetzen,

5.9 Lasergenerieren im modularen System 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 ge-zielt für bestimmte Produktgruppen (Drehteile, Formen) ausgelegt werden, sodass sie sich für die Herstellung solcher Prototypen und Kleinserien be-sonders 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 al-lerdings mit Laserbeschichten überwiegend das Verfahren bezeichnet wird, flächig für den Verschleißschutz aufzutragen, bezieht sich das Laser-generieren 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 La-serstrahls im Brennfleck leicht angeschmolzen. Gleichzeitig wird pulver-förmiges Zusatzmaterial in das Schmelzbad gebracht und ebenfalls aufge-


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 Pul-ver-Gas-Gemisch durch eine ringförmig um den Laserstrahl verlaufende Düse in das Schmelzbad fokussiert wird. Die andere Möglichkeit ist die la-terale 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 beein-flussen.

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 Frei-formen gestalten.

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

Seit der Patentierung des Verfahrens 1976 [5.59] wurde es an verschie-denen Orten weiterentwickelt und technisch umgesetzt, einige davon spe-ziell 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 unter-schiedliche Namen tragen, findet sich in [5.143].

Das Lasergenerieren kann mit einer Vielzahl unterschiedlicher Materia-lien durchgeführt werden. Neben Eisen- und Stahlwerkstoffen werden häu-fig Ni- und Co-Legierungen eingesetzt, vor allem um harte und ver-schleiß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-


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 Gleichge-wichtes 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 Quer-schnitts 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 Beschich-ten 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).


Relevante Prozessparameter

Um Spuren mit bestimmten geometrischen Eigenschaften gezielt generie-ren zu können, muss bekannt sein, durch welche Parameter der Prozess und damit auch die generierten Spuren zu beeinflussen sind. Die wichtigs-ten Prozessparameter sind die Laserleistung PL, die Geschwindigkeit v, der am Pulverförderer eingestellte Pulvermassenstrom dm/dt und die Brenn-fleckgröße.

Die Auswertung der Zusammenhänge von Prozessparametern und Aus-sehen der Spuren zeigt, dass die Spurhöhe h maßgeblich durch den Pul-vermassenstrom 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 Ände-rungen 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

dtdm

vch 1

(1)

ausgedrückt werden, mit einer Konstanten c. Hingegen wird die Spurbreite primär durch die Brennfleckgröße be-

stimmt. Bei gaußförmiger Intensitätsverteilung, wie sie bei fasergekoppel-ten Lasern außerhalb des Fokus auftritt, wird sie sekundär durch die Laser-


leistung verändert. Der Pulvermassenstrom tangiert die Spurbreite nicht. Um sie gezielt zu verändern muss also die Brennfleckgröße geändert wer-den, was durch spezielle Optiken möglich ist, wie in Abschn. „Vario-Optik“ beschrieben.

Die Tiefe der Spur wird durch die Laserleistung und den Pulvermassen-strom 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 wer-den. 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 Pul-ver- und Laserfokus knapp unter der vorhergehenden Spuroberfläche lie-gen. 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.


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 Aus-trittsö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 ein-deutige Vorzugsrichtung und der Prozess verhält sich je nach Verfahrrich-tung anders. Durch geschickte Korrekturen ist es aber möglich, eine Late-raldü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

vhhvkorr

0 (2)

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


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

h in mm vkorr in mm/min hkorr in mmschleppend 1,07 400 (= v0) 1.11 seitlich 0,83 310 1.15 stechend 0,60 224 1.24 seitlich 0,93 347 1.14

Abb. 5.51. Beispiel für eine Geschwindigkeitskorrekur

Vario-Optik

Zur Einstellung der Spurbreite ist der Brennfleckdurchmesser entschei-dend. 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 be-gegnen, wurde eine spezielle Optik entwickelt, mit der die Brennfleckgrö-ße bei gleich bleibendem Arbeitsabstand stufenlos einstellbar ist. Diese ar-beitet ähnlich einem Zoomobjektiv und ist in Abb. 5.52 dargestellt.

Abb. 5.52. Die Spezialoptik zur Einstellung unterschiedlicher Spurbreiten


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. Da-durch lassen sich Aufbauten mit variierenden Spurdurchmessern generie-ren. 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 mes-sen. 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 be-grenzt. 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. Die-se können direkt durch die Optik im Schmelzbad messen, arbeiten passiv und werden durch die ungünstigen Bedingungen um das Schmelzbad her-um kaum tangiert. Diese werden für die Prozessregelung (Kap. 5.9.5) ein-gesetzt.


Abb. 5.54. Aufbau des Tiefensensors

Ein weiteres interessantes passives System ist der Tiefensensor der Fir-ma LaserTec, der zur Messung der Tiefe beim Laserabtragen entwickelt wurde. Sein Aufbau ist in Abb. 5.54 dargestellt. Das vom Schmelzbad e-mittierte 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 Ab-stand der beiden Lichtpunkte auf dem Schirm.

0

100

200

300

400

500

600

700

800

900

1000

0 5 10 15 20 25 30 35 40 45Messstrecke in mm

Mes

swer

t in

µm

SensormessungSensormessung geglättetTastschnittmessung

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


Das Messergebnis muss durch komplexe Algorithmen ausgewertet und gefiltert werden, bevor ein brauchbares Messsignal für die Spurhöhe vor-liegt. 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 NC-Programm 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. Aller-dings ist es sehr schwierig, eine gut funktionierende und zuverlässige Re-gelung aufzubauen. Da die Regelung den Prozess beeinflusst, besteht im-mer 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 Rege-lung, die die Temperatur im Schmelzbad konstant hält, indem sie die La-serleistung nachführt. Diese Art der Temperaturreglung, die in der Laser-technik häufig eingesetzt wird [5.71], [5.76], [5.77], [5.12], muss für das Lasergenerieren so eingestellt werden, dass die geregelten Aufbauten qua-litativ 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


Wärme durch den Steg nach unten abzuführen. Es bildet sich ein Tempera-turstau 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 nachge-fü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 ei-nige Mühe, da sie auch bei stabil laufender Regelung einen deutlichen Ein-fluss auf die Spuranfänge haben. Abb. 5.57 illustriert dies für den I-Anteil eines PID-Reglers.


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 recht-winkligen 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än-gig 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/PL

0,5 an, die sich aus den Messwerten für Rückreflex und Laser-leistung 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 beein-flusst. 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 Geschwindig-keitsregelung nur der Zugriff auf den Geschwindigkeitsoverride innerhalb bestimmter Grenzen gewährt.


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

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

105 stell

NCUvv

(3)

beeinflusst das Stellsignal der Regelung Ustell die im NC-Programm vorge-gebene Geschwindigkeit vNC. Die Änderung ist hierbei limitiert auf v=0,5..1,5vNC.

Der Aufbau des Regelschemas ist in Abb. 5.59 dargestellt. Die Mess-werte für die Laserleistung und den Rückreflex werden zunächst zu mhverarbeitet. 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 Geschwindig-keitsvorgaben von vNC=100..900 mm/min. Gleichzeitig entsprach der Sollwert für mh einem Wert, der der bei v=400 mm/min erreichten Spur-höhe entspricht. Auf der Ordinate sind die real gefahrenen Geschwindig-keiten dargestellt. Ohne Regelung verlaufen sie entlang der dunkelgrauen Kurve. Mit Regelung können sie innerhalb der beiden hellgrauen Kurven, die die Regelgrenzen darstellen, variieren.


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 vorge-gebene Geschwindigkeit unverändert und korrigiert sie danach wieder nach unten, bis er bei v=900 mm/min an die Regelgrenze stößt.


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 Nachbe-arbeitung. 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 laserintegrier-ten Fertigungssystems für weitere Anwendungsfälle aus dem Bereich der Prototypenproduktion und Werkzeugmodifikation weiterentwickeln. Je nach Aufgabenstellung lassen sich ohne großen Aufwand weitere etablier-te 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. erwei-tert. 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 ausge-legt werden. Dies führt zu einem modularen Aufbau flexibler Fertigungs-systeme sowohl hinsichtlich der Maschinen wie auch der Steuerungstech-nik. So kann ein spezifisches System aus einem Baukasten vorhandener


Module nach Bedarf zusammengesetzt werden. Abb. 5.61 zeigt das Sche-ma 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 ei-nem Dreh- und einem Fräszentrum gezeigt werden. Alle Zusatzmodule


sowie die Handhabung besaßen dabei eigene Steuerungen und kommuni-zierten mit einem autarken Leitrechner, der den gesamten Herstellungspro-zess koordinierte. Abb. 5.62 zeigt ein Bild des Systems in der Drehma-schine, Abb. 5.53 ein damit hergestelltes Flügelrad.


In breiten Anwendungsfeldern gibt es einen bislang weitgehend unge-deckten 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 Ferti-gungssystem für Prototypen oder Werkzeugmodifikationen zusammenzu-setzen 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 auftra-genden Teil zuständig. Bei genauer Kenntnis der relevanten Prozesspara-meter, ihres Einflusses auf das Ergebnis und einiger Regeln für die Kom-bination von Einzelspuren zu komplexen Körpern, kann das Laser-generieren zum Aufbau fast beliebiger 3D-Gebilden eingesetzt werden. Um die Handhabung des Prozesses zu vereinfachen, konnten Messverfah-ren gefunden werden, die eine Qualitätskontrolle und Prozessüberwachung ermöglichen. Diese lassen sich bedingt auch zu einer Regelung des Prozes-ses einsetzen, was die Bedienungsfreundlichkeit des Prozesses deutlich er-höht.

Damit ist das Lasergenerieren wie auch das modulare System schon in einem fortgeschrittenen Stadium, was einen verstärkten Einsatz in der In-dustrie erwarten und erhoffen lässt.


5.10 Selektives Lasersintern von Hochleistungspolyme-ren 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 kom-merziell erhältliche Anlagen für das Rapid Prototyping [5.179]. Diese be-schränkten sich auf einige wenige Materialien und waren oft nur als De-sign Prototypen einsetzbar. Das IKP hat diese Fragestellung deshalb mit aufgenommen, um die Qualität und die Vielfalt der verwendbaren Materia-lien und Prototypen zu erhöhen.

An der rasanten Entwicklung, die seitdem das Rapid Prototyping ge-nommen 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 La-serverfahren zu erstellen („Rapid Tooling“) oder sogar Kleinserien zu fer-tigen („Rapid Manufacturing“).

Das IKP hat diese kommerzielle Entwicklung durch entsprechende For-schungsprojekte begleitet. In den letzten zehn Jahren haben am IKP im Be-reich 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 Fo-kus 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 im-mer 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 empi-risch gearbeitet wird.

5.10 Lasersintern von Hochleistungspolymeren mittels Nd:YAG-Laser 431


Im Folgenden wird die Ausgangssituation der „Rapid“-Technologien um-rissen, 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 Fertigungs-verfahren. 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 Technolo-gien 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]:

Konzeptmodelle: Diese Modelle sind nicht mechanisch belastbar und dienen allein der dreidimensionalen Anschauung. Funktionsmodelle: Diese Modelle haben ähnliche Eigenschaften wie die in der späteren Serienfertigung hergestellten Bauteile. Werkzeuge („Rapid Tooling“): Es werden Werkzeuge erzeugt, die mit anderen Fertigungsverfahren kombiniert werden. Kleinserien („Rapid Manufacturing“): Die gefertigten Geometrien ent-sprechen 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 Funktionsmo-dell zur Kleinserie fließend.

Die Marktentwicklung der „Rapid“-Technologien ist sehr rasant. Stän-dig gibt es neue Verfahren, so dass mittlerweile eine große Anzahl von Konzepten existiert, die grundsätzlich dem generativen Schichtaufbau ent-sprechen. Etablierte Verfahren sind:

Stereolithoghraphie (SLA): Aushärten von duroplastischen Harzsyste-men mittels Lasers Selektives Lasersintern (s. u.) Schicht-Laminat-Verfahren (LLM, LOM): Ausschneiden einer Schicht-kontur und Verkleben der einzelnen Schichten


Schmelzeauftragsverfahren (FDM): Aufschmelzen eines Kunststoff-strangs, Auftragen der Schmelze über eine Düse und Erstarren der Schmelze 3D-Drucken (3DP): Drucken von „Tinte“ in ein Pulverbett. Die „Tinte“ verklebt die Partikel miteinander durch Aushärtung oder Anlösen. Lasergenerieren: Materialauftrag durch lokales Aufschmelzen von Me-tallpulver durch einen Laser

Laserverfahren

Viele von den oben genannten Verfahren setzen Laser ein, um einen loka-len 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]:

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 kei-ne 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 Lasersin-terns benutzt [5.56]. He-Cd: Der He-Cd-Laser ist ein Gaslaser, der Licht mit den Wellenlän-gen 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 Stereoli-thographieanlagen zum Aushärten von UV sensitiven Harzsystemen eingesetzt [5.56]. Ar-Ionen: Der Ar-Ionen-Laser ist ein weiterer Gaslaser. Der Ar-Ionen-Laser besitzt verschiedene Emissionslinien. Die für die Stereolithogra-phie benötigte UV-Linie wird durch doppelt-ionisierte Übergänge, wel-che wesentlich höhere Ströme in der Plasmaentladung erfordern, er-zeugt. Daher lassen sich nur die großen High-Power-Laser auf UV-Betrieb umbauen [5.179], deren Einsatz entsprechend leistungs- bzw. kostenintensiv ist. Nd dotiert: Ein Nd:YAG-Laser ist ein Festkörperlaser, der als aktives Medium einen Neodym-dotierten Yttrium-Aluminium-Granat-Kristall


verwendet und infrarote Strahlung mit einer Wellenlänge von 1,064 µmemittiert. Dieser Laser ist in der Industrie sehr gebräuchlich, da er ver-gleichbare Kosten wie ein CO2-Laser verursacht [5.151]. Ein Vorteil gegenüber dem CO2-Laser ist, dass Glasoptiken eingesetzt werden kön-nen.

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 Par-tikel genauso entscheidend wie die Schmelz- und Erstarrungskinetik des Materials.

Eine SLS-Anlage besteht damit im Wesentlichen aus folgenden Teilen (s. Abb. 5.63):

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. Beschichtungsanlage und z-Achsen-Verstellung: Nach jedem Sintervor-gang wird das Pulverbett eine Schichtdicke nach unten verfahren. Auf der bereits versinterten Struktur wird über eine Pulverzufuhr und eine Nivelliereinheit neues Pulver aufgebracht.Laser mit x-y-Spiegeln: Steuerbare Spiegel lenken den Laserstrahl an die Stelle, an der das Pulver selektiv aufgeschmolzen werden soll. Steuerrechner: Der Steuerrechner erstellt im Idealfall die Schichtgeo-metrie aus der dreidimensionalen Bauteilgeometrie. Er steuert alle zuvor genannten Anlagenteile in der richtigen Reihenfolge an, um eine effi-ziente Zeitnutzung zu garantieren.

Grundsätzlich können beliebige Pulver versintert werden, am Markt ha-ben sich zurzeit aber vor allem Kunststoffpulver und Metallpulver durch-gesetzt.

Bei den Kunststoffpulvern muss zwischen amorphen Thermoplasten (z. B. Polystyrol (PS) und Polymethylmethacrylat (PMMA)) und teilkristalli-nen Thermoplasten (z.B. Polyamid (PA)) unterschieden werden. Amorphe Thermoplaste erweichen langsam im Bereich ihrer Glasübergangs-temperatur, die Viskosität nimmt aber nur langsam mit steigender Tempe-ratur ab. Teilkristalline Thermoplaste schmelzen oft bei etwas höheren


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 ent-scheidenden Einfluss auf die Qualität der Sinterproben aus. Zu diesen Pa-rametern gehören die Laserleistung PL, die Scangeschwindigkeit vs (Be-lichtungsgeschwindigkeit) 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


Vorarbeiten am IKP

Am IKP wurden in den Jahren 1995 – 2003 zwei Lasersinteranlagen auf-gebaut. 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]:

Der Versuch, PET als Rapid Prototyping Material zu adaptieren, schei-terte an den optischen Eigenschaften des Werkstoffs bei der Wellenlän-ge des CO2-Lasers.Hochschmelzende Kunststoffe wie Polyethersulfon (PES) und Poly-etheretherketon (PEEK) zeigten auf Grund ihrer chemischen Struktur nur eine minimale Eindringtiefe im Wellenlängenbereich des CO2-Lasers.Es konnte ein thermoplastischer Elastomerwerkstoff (TPE) erfolgreich versintert werden (s. Abb. 5.65 links). Allerdings gab es beim Grundma-terial erhebliche Chargenschwankungen und Alterung, die nicht ab-schließ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 mo-dular aufgebaut und können sehr leicht an neue wissenschaftliche Anforde-rungen 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 La-sersinterns mit dem neuen System an PA und PS gezeigt werden. Dabei


wurde Ruß als Koppelmedium eingesetzt, um die Energieabsorption zu steuern.

Resultierende Zielsetzung

Das Hauptziel dieses Teilprojektes knüpft an die vorangegangenen Arbei-ten an und basiert auf der Adaption von neuartigen Polymeren für die ent-wickelte Lasersinter-Prozesstechnik mit Hilfe des Nd:YAG-Lasers und ei-nes 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ögli-chen.

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 ho-her Steifigkeit und Festigkeit, der bisher allein den spritzgegossenen Pro-ben 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 Forschungs-anwendungen getestet, da es sich als biokompatibel erwiesen hat [5.92]. In diesem Bereich ist das Selektive Lasersintern sehr attraktiv, da diese Tech-nologie großes Potenzial zur Herstellung individuell angepasster Implanta-te für den einzelnen Patienten birgt.

Zukünftig sind den möglichen Einsatzgebieten der Hochleistungskunst-stoffe 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 Kop-pelmedium macht diesen Ansatz attraktiv. Es wäre eine „universelle“ La-seranlagentechnik 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-


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 weni-ger als 1% der Laserenergie zum Aufschmelzen des Kunststoffs genutzt wird.

Untersuchungen an Einschichtproben haben den Einfluss der einge-brachten Energie gezeigt [5.86], [5.163]. Die Sintertiefe 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 Einzel-schichtproben 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 E-nergie 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ßan-teil als Additiv zum Material möglichst gering gesetzt, um die Beeinflus-sung durch den Ruß zu minimieren. Zusätzlich hat der Rußgehalt auch ei-nen Einfluss auf das Kristallisationsverhalten des Kunststoffs, da er


keimbildende Wirkung hat. Der genaue Einfluss der Keimbildung auf das Gesamtsystem wurde aber bisher noch nicht untersucht.

Weitere Untersuchungen der mechanischen Eigenschaften von Mehr-schichtproben 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 zeit-lich 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 Arbeitsfens-ter festzulegen und qualitative Prozesse darzustellen. Die mittlere Energie-dichte ist jedoch nicht geeignet, alleinige Kenngröße für die Parameterop-timierung zu sein.

Neben den Laserparametern und dem Rußgehalt wurde auch die Zu-sammensetzung des Polymerpulvers variiert. Die Untersuchungen umfass-ten neben den reinen PEEK- und Polyetherketon- (PEK) Pulvern auch Mi-schungen dieser Pulver. Bei gleichen Laserparametern ergaben sich bessere mechanische Eigenschaften (Festigkeit, Steifigkeit) für die Mi-schungen 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 Ener-giedichte


Optimiert man für jede Polymermischung die Sinterparameter, ergeben sich vergleichbare mechanische Eigenschaften bei allen Mischungen. Da-mit 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 Mehr-schichtproben dargestellt. Die Probe links ist poröser, die Probe rechts kompakter. Dies führt dazu, dass die rechte Probe bei gleicher Schichtdi-cke 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-


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 Sinter-parameter 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 Sin-terkammer bereits temperaturbeständig ausgelegt worden ist.

Als ein weiterer Schritt musste die Verfahrenstechnik verfeinert werden, damit die einzelnen Schichten nicht durch den Nivelliervorgang zueinan-der 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 schmel-zenden 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 ei-ne leichte Schichtinhomogenität einstellt. Durch die leicht gerippte Struk-tur der ersten Schicht kann diese gut von der Basisplatte gelöst werden.


Dreidimensionale Sintergeometrien

Aufbauend auf die Ergebnisse der materialtechnischen Basisuntersuchun-gen und der Weiterentwicklung der am IKP vorhandenen Prozesstechnik konnten einfache dreidimensionale Körper (PEEK, PEK und PEEK / PEK-Compounds) 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 eben-falls gesintert werden. Es wurde exemplarisch ein Ausschnitt einer Spie-gelfußgeometrie, bestehend aus 10 Schichten mit je 0,2 mm Schichtdicke, hergestellt (s. Abb. 5.72.). Die Konturschärfe ist auch bei den spitzen E-cken sehr gut. Allerdings tritt bei zunehmendem Schichtaufbau ein stärke-rer Verzug der gesamten Geometrie auf, der höhere Aufbauten verhindert.


Hier sind noch Verbesserungen erforderlich. Ein Ansatz ist dabei, die Pul-verdichte des Bettes vor dem Sintervorgang zu erhöhen.

5.10.5 Verfahrenskombinationen

Es wurden außerdem verschiedene Verfahrenskombinationen im Zusam-menhang mit dem neuen Lasersinterverfahren erprobt. Als aussichtsreichs-te Kombination wird im Folgenden kurz auf das Metallbeschichten der ge-sinterten 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 Be-schichtungsverfahren 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 Materi-als durch die Beschichtung verbessert werden. Eine geschickte Verfah-renskombination vergrößert also das mögliche Einsatzspektrum der Bau-teile.


Die „Rapid“-Technologien sind ein immer noch wachsender Markt. In den letzten fünfzehn Jahren hat sich eine Vielzahl von unterschiedlichen gene-rativen 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 Laser-sintern 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 Absorpti-onsverhalten des jeweiligen Kunststoffs funktioniert.


In einer ersten Phase konnte das Wirkprinzip an PS und PA grundsätz-lich bewiesen werden. Da diese beiden Kunststoffe auch mit herkömmli-chen CO2-Laseranlagen gesintert werden können, stellen sie gute Refe-renzmaterialien 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 un-tersucht. 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 Verfahrens-kombinationen des Selektiven Lasersinterns mit anderen Technologien ge-testet. Dabei hat sich besonders das nachgeschaltete Metallbeschichten als zukunftsträchtige Variante erwiesen.

Das am IKP neu entwickelte Verfahren, mit dem Nd:YAG-Laser Ther-moplaste zu sintern, hat in den durchgeführten Studien sehr großes Poten-zial gezeigt. Viele Einflussparameter sind allerdings zurzeit nur wenig o-der 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 Zusam-menspiel der mechanischen Eigenschaften und möglichst geringem Ver-zug. In diesem Bereich muss insbesondere die Anlagentechnik weiter op-timiert 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 ei-ner bestimmten Bauhöhe das Pulver umgestellt werden kann. Dies kann man sich auch örtlich, beispielsweise an Krafteinleitungspunkten, vorstel-len. 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 Gestal-tung bieten.


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 durch-laufen werden.

Die Entwicklungs- und Herstellungsprozesse der dafür notwendigen Werkzeuge sind zeitintensiv und erstrecken sich häufig über einen Zeit-raum von mehreren Monaten. Beim Einsatz von Prototyp-Werkzeugsystemen und Beschränkung auf die formgebenden Operationen lassen sich Prototypteile unter geringerem Aufwand in kurzer Zeit anferti-gen.

Die hier durchgeführten Forschungsarbeiten beschränken sich auf die Verfahren der Blechumformung und unterteilen sich in Werkzeugentwick-lung und Werkzeugherstellung. In beiden Fällen steht die Beschleunigung des Prozesses im Vordergrund.

In den vergangenen Jahren ist die Prozesssimulation wesentlich verbes-sert worden. Das hat auch dazu geführt, dass ihr Einsatz im Werkzeug- und Bauteilentwicklungsprozess stark zugenommen hat.

Werden für frühe Machbarkeitsstudien nahezu ausschließlich virtuelle Prototypen verwendet, müssen reale Prototypwerkzeuge den späteren Se-rienprozess 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 einge-setzt werden. Außerdem ist es möglich, den Anlauf der Serienwerkzeuge durch die Fertigung von Bauteilen mit dem Prototypwerkzeug zu unter-stützen.

Eine Voraussetzung, Zeit und Kosten während der Werkzeugentwick-lung zu sparen, ist das Vermeiden von Iterationsschleifen, die auf nicht fer-tigungsgerechte Bauteilauslegung und –konstruktion zurückzuführen sind. Um dies zu erreichen, sind bereits zu einem frühen Zeitpunkt der Produkt-entwicklung Entwicklerteams aus unterschiedlichen Fachbereichen und auch Fachleute, die sich mit nachfolgenden Fertigungstechnologien befas-sen, 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 Proto-typwerkzeuge 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 la-gen zunächst in den begrenzten Möglichkeiten der mechanischen Bearbei-tung. 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 unlegier-ten 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


(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 Zugfestig-keit und Härte der Graugusssorten.

Im Gegensatz zu Serien-Werkzeugen wird bei Prototypwerkzeugen auf-grund der niedrigen Gesamtstückzahl und aus Kostengründen auf Legie-rungselemente 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 hervorragen-den Oberflächen und gestattet aufgrund gleicher Ausführung der Ziehrah-men 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 Zerspanungsauf-wand 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 Prototyp-Werkzeugbaus. 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 eintei-len.

In der Technik haben die niedrigschmelzenden Metalle in legierter Form breite Anwendung als Weichlote (DIN EN 29453/ DIN 1707), Lagermetal-le (DIN 4381), Zinnlegierungen für Gussstücke (DIN EN 611), Zinklegie-rungen 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-


9), Zinnlegierungen und Zinngerät (EN 611) gefunden und sind größten-teils 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 niedri-gen Schmelzpunkt, abgeleitet werden. Die wichtigsten binären Zustands-diagramme niedrigschmelzender Legierungen sind in Ternary Alloys [5.27], [5.67] enthalten. Die Materialeigenschaften der genannten Legie-rungen 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, de-finierten Schmelzpunkt, eine dünnflüssige Schmelze und durch ein fein-körniges Gefüge aus. Sie sind somit für den Gießprozess hervorragend ge-eignet.

Im Prototypwerkzeugbau werden zur Herstellung von formgebenden Blechumformwerkzeugen vorwiegend Bismut-Zinn- und Feinzink-Legierungen verwendet [5.67].

5.11.5 Kunststoffe, Polyamide und Photopolymere

In den 50er Jahren wurden Kunststoffe im Betriebsmittelbau zur Übertra-gung der räumlichen Geometrie des Urmodelles auf Kopier- bzw. Tu-schiermodelle 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 Stahl-pulver gefüllt, die des Werkzeughinterbaus hingegen mit Quarzsand. We-gen des Füllstoffzusatzes Quarzsand werden sie häufig auch als Polymer-betonwerkzeuge bezeichnet.

Aufgrund der unzureichenden mechanischen Belastbarkeit des Quarz-sandhinterbaus 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 Ver-lauf wurden sie auch zunehmend als Werkzeugstoff für Prototypwerkzeu-ge 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 Photopoly-meren in Form von Acrylaten und Epoxidharzen zur generativen Herstel-lung von Prototypwerkzeugen untersucht.


Neben den erwähnten duroplastischen Gießharzen stehen dem Hersteller von Prototypwerkzeugen heute auch sogenannte Blockmaterialien zur Ver-fügung. Darunter versteht man vom Kunststoffhersteller zu Blöcken und Platten vorgegossene Kunststoff-Halbzeuge, die in der Regel aus Epoxid- und 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 schwin-den. Dies erklärt auch, warum selbst Polyamid-Blockmaterialien und phe-nolharzverleimtes 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 PUR- Formstoffen handelt es sich um Polyaddukte. Polyamide (PA) und Phenol-harze (PF) sind hingegen Vertreter der Polykondensate. Der Formstoff ent-steht 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.). Kenn-zeichnend 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 Nat-ronlauge (NaOH) zu Diglycidylether. In Abhängigkeit vom eingesetzten Mengen (Mol)-Verhältnis der Ausgangskomponenten erhält man Produkte


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är-kungsmaterialien weitveränderbar [5.60]. Polyurethanformstoffe (PUR) entstehen durch Polyaddition von Isocyana-ten (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 An-zahl der Moleküle der Ausgangsstoffe. Auf diese Art lassen sich Thermo-plaste, Elastomere sowie Duroplaste unterschiedlicher Eigenschaften her-stellen.

Als Polyamide (PA) bezeichnet man polymere Stoffe, die in ihren Ket-tenmolekü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) auf-gebaut sein. Die Formstoffe entstehen im Gegensatz zu EP- und PUR- Formstoffen 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 Polymerisa-tion eines Reaktionsgemisches aus Caprolactam und einem Katalysator in einer beheizten Form [5.69].


Grundsätzlich richten sich die mechanischen Eigenschaften der Polya-mide nach dem PA-Typ, der Kristallinität und dem Wassergehalt. Bei ho-her 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üssi-gen Gemisch von Monomeren (Einzelmolekülen) ein verketteter, ausge-hä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 wer-den 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. Darun-ter sind vor allem die Stempelergänzungs- und Ziehrahmenflächen zu ver-stehen. Eine falsche Auslegung der Prototypwerkzeugpaarung Niederhalter und Matrize bedeutet, dass die Prototyp-Teile nicht oder nur mit erhebli-chen Schwierigkeiten bzw. mit hohem Ausschuss gefertigt werden können.

Da Prototypwerkzeuge auch dazu dienen, die Anlage von Serien-Werkzeugen fertigungstechnisch abzusichern, beeinträchtigt und verzögert eine falsche Auslegung des Prototypwerkzeugs auch den Entwicklungs- und 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ächenpres-sungen 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’ tu-schiert. Beim Weichtuschieren wird an Stellen, an denen der Werkstoff-fluss begünstigt werden soll und somit weniger Flächenpressung notwen-dig 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 ei-ne 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


von Verschleißerscheinungen oder Werkstoffdifferenzen während des Pro-zesses dar. Dieser Verschleiß kann dazu führen, dass ein erneutes Tuschie-ren erforderlich wird.

Insgesamt ist das Tuschieren ein sehr zeitaufwändiger und kosteninten-siver Prozess, für den geschultes und hochqualifiziertes Personal notwen-dig ist, und der nicht eindeutig reproduzierbar ist. Dadurch ist auch eine Übertragbarkeit vom Prototyp- auf das spätere Serien-Werkzeug nur be-schränkt möglich.

Ziel für den Prototypen-Werkzeugbau sollte ein Werkzeugkonzept sein, welches ein Eintuschieren auf ein Minimum reduziert oder sogar überflüs-sig macht. Des Weiteren sollte auf verschleißbeständigere Werkstoffe oder Beschichtungen verzichtet werden können. Auf verschleißbedingte Ände-rungen 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 ent-sprechen.

Aus diesem Grund wurde ein hierfür sehr vielversprechendes Werk-zeugkonzept, das am Institut für Umformtechnik entwickelt wurde, für die Prototypenwerkzeugherstellung überprüft.

Im Gegensatz zu konventionellen Werkzeugkonzepten, bei denen Nie-derhalter und Matrize sehr steif ausgeführt werden und die unterschiedli-chen 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 Plat-ten miteinander verbunden sind, aufgebaut (s. Abb. 5.78.).

Abb. 5.78. Prinzip des segmentelastischen Niederhalters [5.141]


Die obere Platte wirkt dabei zwischen den Pyramidenstümpfen als elas-tisches Gelenk. Man ist somit in der Lage, über das Ziehkissen partiell un-terschiedliche Niederhalterkräfte in die unterschiedlichen Segmentflächen einzuleiten. Die Flächenpressungen in den Nachbarbereichen werden hier-durch kaum beeinflusst [5.78]. Im Vergleich zur konventionellen Nieder-halterkonstruktion ermöglicht dies die gezielte Steuerung der Niederhalter-flächenpressung und somit des Materialflusses in bestimmten Nieder-halterbereichen [5.141].

Durch diese Werkzeugbauweise entfällt das ansonsten gerade bei Werk-zeugen 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 Werkzeugwirk-flä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 ausschlagge-bend. 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-Niederhalter-Systeme in idealisierte Segmente zerlegt. Diese Matrizen- und Niederhal-tersegmente haben kubische Abmessungen und sind jeweils einer Nieder-halterkraft 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 Ziehteil-

flansch wird als Referenz die mittlere Flächenpressung zp herangezogen,


die bei einer gleichmäßigen Verteilung in der gesamten Kontaktfläche vor-liegen würde. Es ist die mittlere Flächenpressung eines Segments

sA S

Nz

Sz A

FdAyxp

Ap ,1

(1)

Sie errechnet sich als Verhältnis der Niederhalterkraft FN zur Quer-schnittsfläche AS des Matrize-Niederhalter-Segments. Alle weiteren Anga-ben über die Flächenpressung werden auf die mittlere Flächenpressung be-zogen.

Somit werden definiert:

Maximale relative Flächenpressung z

maxzmax p

pp ,

100% (2)

Minimale relative Flächenpressung z

minzmin p

pp ,

100% (3)

relative Flächenpressungsdifferenz

minmaxz

minzmaxz pp100%p

ppp ,,

(4)

Die relative Flächenpressungsdifferenz p wird als Beurteilungs-kriterium 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 pist, um so weiter nähern sich pmax und pmin der mittleren Flächenpressung

zp an. Ist die minimale relative Flächenpressung pmin nahezu 0, so besteht die Gefahr, dass das Werkzeug lokal vom Blech abhebt, was unter ande-rem zu Faltenbildung führen kann.

Als weiteres Beurteilungskriterium wird die

relative Segmentmasse massivS

verripptS

MM

m,

,100% (5)


als Verhältnis der Masse der verrippten Segmentvariante MS,verrippt zurMasse eines unverrippten Matrize-Niederhalter-Segments MS,massiv heran-gezogen [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 1 2 3 4 5 6 7 Niederhal-ter

Matrize

Flä-chenpres-sungs-verteilung

pmax [%] 106 588 275 210 178 139 129 pmin [%] 96 0 0 0 0 67 65

p [%] 10 588 275 210 178 72 64 Masse m[%]

100 47,9 58,3 51,8 51,8 61,0 74,9

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]


Die konventionellen Werkzeugverrippungen (Abb. 5.81. / Paarung 2 und 3) bewirken hohe Gewichtseinsparungen. Allerdings ergeben sich hin-sichtlich 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 hier-von 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ückhalte-kraft wirkt. Außerdem wird in den Bereichen mit geringer Flächenpres-sung 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ächenpres-sung optimiert, bis ein Gutteil gefertigt werden kann. Dieser arbeitsinten-sive Vorgang des Einarbeitens, der insbesondere bei engen Verfahrens-grenzen 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 segmentelas-tischem Niederhalter (Paarung 4 bis 7) gegenüber den konventionellen Werkzeugpaarungen geringere Werte der relativen Flächenpressungsdiffe-renz auf. Die Paarung segmentelastischer Niederhalter und prismatisch verrippte Matrize (Paarung 6) ist ein sehr guter Kompromiss bezüglich re-lativer 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 defi-nierte Fläche übertragen kann, und zum anderen zwischen den mit Nieder-halterkraft beaufschlagten Flächen so elastisch ist, dass die eingeleitete Kraft die Nachbarflächen nicht beeinflusst. Bei Verwendung konventionel-ler Niederhalter, die in Kasten- oder C-Profil Verrippung ausgeführt sind, ist dies nicht möglich. Diese Profile sind zu biegesteif ausgeführt und be-sitzen 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-


ten Matrize ist hier die beste Alternative. Die Anwendung obiger Ergeb-nisse steigert zwar den Herstellungsaufwand der Prototyp-Werkzeuge, er-möglicht allerdings die Herstellung von Prototyp-Blechformteilen, die in ihren Eigenschaften den Serienteilen entsprechen. Die systematisierte Aus-legung des segmentelastischen Niederhalters in Verbindung mit einer ver-rippten Struktur der Matrize stellt eine wesentliche Verbesserung des Kon-struktions- und Auslegungsprozesses bei beachtlich reduzierter Werkzeug-einarbeitungszeit 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. Hier-zu ist es zunächst notwendig, die Werkzeugkonstruktion in die 3D-Visualisierung mittels Virtual Reality (VR) zu integrieren und daraus ent-stehende Vorteile abzuleiten.

Im bisherigen Konstruktionsprozess wird vor der Freigabe der Kon-struktion von der Ziehanlagengeometrie meist ein Styropormodell herge-stellt. Anhand dieses Modells können dann die Konstrukteure die Werk-zeuggeometrie diskutieren und gegebenenfalls Änderungen vornehmen. Für ein Abtragen von Werkstoff werden meist Messer oder Sägen einge-setzt. Als Anbauwerkstoff kann Knetmasse verwendet werden. Im Ver-gleich 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 dis-kutieren.

Dieser Prozess hat jedoch verschiedene Nachteile. Die Herstellung des Modells ist mit Kosten- und Zeitaufwand verbunden und die Vorgehens-weise 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 ex-terne 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 durch-fü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.


All diese Forderungen werden von der 3D-Visualisierung mittels der Technologie der Virtuellen Realität erfüllt. Durch den Einsatz der 3D-Visualisierung anstatt spanend hergestellter Styropormodelle wird es mög-lich, die aktuellen Geometriedaten schnell in die VR-Umgebung zu integ-rieren 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 PC-Technik herauszuheben. Da die Berechnung der darzustellenden Grafikda-ten sehr rechenintensiv ist, waren für die Anwendung bisher teure Grafik-workstations notwendig. Die VR-Technologie ist durch einen beachtlichen Anstieg der Rechen- und Grafikleistung im PC-Bereich zunehmend inte-ressanter geworden [5.28], [5.80]. Im Rahmen der Untersuchungen wurden verschiedene Werkzeuge mittels VR visualisiert. Es ist möglich, die Werk-zeugkonstruktion 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


Vor allem bei komplexen Prozessabläufen ist es äußerst hilfreich, an-hand 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 FEM-Prozesssimulation 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-Prozess-simulationen die Werkzeugkonstruktion unterstützen (Abb. 5.83.).

Abb. 5.83. Einsatz der FEM-Prozesssimulation im Prototyp-Werkzeug-Ent-wicklungsprozess [5.141]

Bei so genannten Einschrittberechnungsverfahren wird, ausgehend von der Endgeometrie des Bauteils, in einem Schritt auf die Ausgangs-geometrie der Platine zurückgerechnet. Es reicht zur Prozesssimulation al-lein 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än-zungsflächen und des Ziehrahmens, durchgeführt werden [5.141].

Ist die Werkzeug- bzw. Wirkflächenkonstruktion fortgeschritten, kön-nen genauere Berechnungen mit impliziten oder expliziten FEM-Tools durchgeführt werden. Diese sind verglichen mit den Einschrittverfahren


zwar rechenintensiver, liefern jedoch auch entsprechend höherwertigere Ergebnisse [5.82].

Die FEM-Simulation wird im Werkzeugentwicklungsprozess inzwi-schen immer häufiger als Ersatz des klassischen Prototyping eingesetzt. Soll die Simulation reale Prototypbauteile ersetzen, muss die Visualisie-rung der CAD-Daten und der Simulationsergebnisse als Diskussionsgrund-lage dienen. Gefordert wird eine möglichst plastische Darstellung, die von mehreren Personen gleichzeitig und bequem betrachtet und diskutiert wer-den kann. Hierzu wurde eine Kopplung der visualisierten animierten 3D-Werkzeugkonstruktion und der FEM-Prozesssimulation realisiert (Abb. 5.84.) [5.162].

Abb. 5.84. Mit der Visualisierung der Werkzeugkonstruktion verknüpfte FEM-Prozesssimulation [5.141].

Die Arbeit mit virtuellen Prototypen eröffnet zusätzlich die Möglichkeit des kollaborativen Arbeitens. Hierunter versteht man das Zusammen-arbeiten örtlich voneinander getrennt arbeitender Teams an einer Datenba-sis. Speziell im Bereich der Entwicklung von Werkzeugen für die Blech-umformung, die sehr stark auf dem Erfahrungswissen der daran beteiligten Personen basiert, ist es von hohem Interesse, Expertenwissen nicht nur lo-kal verfügbar zu haben, sondern auch über größere Entfernungen entspre-chendes 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 Integra-tion der animierten Werkzeugkonstruktion in Verbindung mit der FEM-


Prozesssimulation stellt eine wesentliche Verbesserung des Konstruktions-prozesses 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 Ge-ometrien räumlich beschreiben, ist eine abformtechnische Herstellung von Werkzeugbauteilen ohne vorhergehende Zerspanung in der Regel nicht mehr möglich. Die zur Steuerung der Bearbeitungsmaschinen erforderli-chen 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:

Fräsbearbeitung von Werkteilen aus Halbzeugen Fräsbearbeitung von Gießmodellen für den Genauguss von Werkzeug-teilenFräsbearbeitung von Gießmodellen für das konturnahe Vorgießen von Werkzeugteilen

In der Regel sind mit den genannten Vorgehensweisen folgende Werk-stoffe verbunden:

Fräsbearbeitung von Werkzeugteilen aus

Halbzeugen

Fräsbearbeitung von Gießmodellen für den Genauguss von Werk-

zeugteilen

Fräsbearbeitung von Gießmodellen für das konturnahe Vorgießen von Werkzeugteilen

Kunststoffe (EP,PUR,PA)

Kunststoffe (EP,PUR)

Kunststoffe (EP,PUR)

Aluminium Bismut/ Zinn-Legierungen

Freizink- Legierung G-ZnAl4Cu3

Stahl [Feinzink- 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 Prototyp-werkzeugen für die Blechumformung. Der Schwerpunkt liegt dabei in der Erprobung des Vakuumformverfahrens zur Herstellung von Gießformen.


Das Verfahren soll eine schnellere, kostengünstigere und umweltfreundli-chere Fertigung von Gießformen für Umformwerkzeuge aus Feinzink-Legierungen (z.B. ZAMAK) ermöglichen [5.81].

5.11.10 Optimierung des Prozesses durch Einsatz des Vakuum-formverfahrens

Aus der Beschreibung der Prozessschritte geht hervor, dass je nach Be-schaffenheit der Modelle die Verfestigung der Form auf chemischem oder mechanischem Wege erfolgt. Steigende Entsorgungs- bzw. Wiederaufar-beitungskosten, 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 Yoshi-masa Kubo und Nataka Kunii in der Leichtmetallgießerei Kabushiki Kais-ha Akita in Nagano, Japan erfunden und weltweit zum Patent angemeldet (s. Abb. 5.87.).


Abb. 5.87. Schematischer Ablauf der Formherstellung mit dem Vakuumformver-fahren [5.81]

Im VDG- Merkblatt R203 wird das Verfahren definiert als „Verfahren zur Herstellung von Formteilen aus binderfreiem, rieselfähigem Sand


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 Modell-platte 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) installier-ten Anlage besteht die Modellplatte aus einem mikroporösen Duroplast-Aluminium-Verbundwerkstoff. Dieser Werkstoff verfügt über eine rich-tungsabhängige Permeabilität für Gase und niedrigviskose Flüssigkeiten und ist ohne Porenverschluss spanend zu bearbeiten.

Oberhalb der in einem Rahmen gespannten thermoplastischen Modell-folie befindet sich eine Flächenheizung, welche die Folie erwärmt und da-durch 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 beauf-schlagt. Dabei legt sich die Folie an die Kontur des Modells an. Anschlie-ßend wird bei anhaltendem Unterdruck auf die Folie eine Schlichte aufge-tragen.

Der doppelwandige und an seiner Innenseite mit „Saugfenstern“ verse-hene Formkasten wird auf die Modelleinrichtung abgesenkt und mit fein-kö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 Form-teil 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 wer-den (s. Abb. 5.88.) [5.81].


Abb. 5.88. Vakuumformanlage am Institut

Anhand der durchgeführten Untersuchungen ergeben sich folgende Vor- und Nachteile:

Vorteile:

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:

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


5.11.11 Tribologische Anforderungen an die Werkzeug-wirkfläche

Die Übertragbarkeit der aus dem Umformvorgang mit Prototyp-Werkzeugen resultierenden Bauteileigenschaften auf die Serienprodukt-eigenschaften erfordert eine identische Ziehanlage und den gleichen Mate-rialfluss.

Die Tribosysteme Niederhalter- Schmierstoff- Blech und Blech- Schmierstoff- Matrize spielen in diesem Zusammenhang eine wesentliche Rolle. Letztlich sind gleiche Reibkräfte bei Prototyp- und Serienwerk-zeugen 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 Rei-bungs- und Verschleißkennwerten wurde das Verhalten der Werkzeug-stoffe charakterisiert.

Bei der hier eingesetzten und am IFU entwickelten Streifenziehanlage wird ein ebener Blechstreifen auf einem Ziehschlitten fixiert und unter ei-nem 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 Werkzeug-oberfläche, den verwendeten Schmierstoff, die aufgetragene Schmierstoff-menge, eine bestimmte Flächenpressung und Ziehgeschwindigkeit.

Abb. 5.89. Prinzip Streifenziehen ohne Umlenkung (a: beidseitig/ b: einseitig) [5.161]


Gemessen werden für verschiedene Niederhalterdrücke pN der Verlauf der Reibkraft FR über dem Ziehweg und daraus abgeleitet die Reibungs-zahl . Die Anlage ist in der Dissertation [5.161] beschrieben. Zur Beurtei-lung der Reibungseigenschaften der Werkzeugstoffe dient hier einerseits die Höhe der Reibkraft und andererseits der Reibkraftverlauf in Abhängig-keit von der Flächenpressung. Die Versuchsbedingungen und Versuchser-gebnisse sind in den Abb. 5.90 bis Abb. 5.97 dargestellt.

Metalle Kunststoffe Grauguss

GG 25 FGH- EP1

Epoxid- Frontgussharz (Gefüllt mit Eisenpulver)

Feinzink- Legierung G- ZnAl4Cu3

FGH- PUR1 Polyurethan- Frontgussharz

(ungefüllt)Bismut/ Zinn- Legierung

Bi57Sn 43 FGH- PUR3

Polyurethan- Frontgussharz (ungefüllt)

Abb. 5.90. Untersuchte Werkstoffe [5.67]

Werkzeugstoff Mittlere Reibzahl Werkzeugstoff Mittlere Reibzahl GG25 0,117 FGH- EP1 0,092

G-ZnAl4Cu3 0,073 FGH- PUR1 0,107 Bi57Sn43 0,142 FGH-PUR3 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 Ziehba-cken 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ättung-svorgang. nach lediglich einem Versuch bei Bi57Sn43. Dies lässt hohen abrasiven Verschleiß vermuten.


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].


Metalle Kunststoffe Grauguss

GG 25 FGH- EP1

Epoxid- Frontgussharz (Gefüllt mit Eisenpulver)

Feinzink- Legierung G- ZnAl4Cu3

FGH- PUR1 Polyurethan- Frontgussharz

(ungefüllt)Bismut/ Zinn- Legierung

Bi57Sn 43

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 Verbin-dung mit den beschriebenen Versuchsparametern überschlägig folgende Reihenfolge: Bi57Sn43, GG25, Kunststoffe, G-ZnAl4Cu3 [5.67].

Die Versuchsergebnisse lassen den Schluss zu, dass keiner der unter-suchten Prototyp-Werkzeugstoffe ein mit dem Referenzwerkstoff GG25 identisches Reibverhalten aufweist.


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 Pro-totyp-Werkzeugstoffe [5.67]


Für die Praxis haben die Ergebnisse folgende Bedeutung: Aufgrund des gemessenen, niedrigeren Reibkraftniveaus bei Prototypwerkzeugen aus G-ZnAl4Cu3 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 Rei-bungskrä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 Polyurethan-Oberflä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ßbe-trag 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 senk-recht zur Ziehrichtung nach Abschluss der Versuche sind hingegen in Abb. 5.95 und 5.96 enthalten.


Abb. 5.98. Verschleißbetrag als Funktion der Hubzahl für metallische Prototyp-Werkstoffe [5.67].

Abb. 5.99. Verschleißbetrag als Funktion der Hubzahl für polymere Prototyp- Werkstoffe [5.67].


Abb. 5.100. Profilschnitt durch die Ziehkantenrundung metallischer Prototyp-Werkzeuge nach 5000 Hüben für G-ZnAl4Cu3 und nach 1000 Hüben für Bi57Sn43.

Abb. 5.101. Profilschnitt durch die Ziehkantenrundung polymerer Prototyp-Werkzeuge 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 Ver-schleißbeständigkeit, schneidet der Werkzeugwerkstoff Polyamid (BM PA1), gefolgt von der Feinzinklegierung G-ZnAl4Cu3 (ZAMAK), am bes-ten 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ändig-keit aller Werkstoffe. Die Versuchsreihe musste hier bereits nach 1000


Hüben abgebrochen werden. Durch Verwendung von Kunstharzen für den Frontguss auf Polyurethan- oder Epoxidharzbasis kann eine mittlere Ver-schleißbeständigkeit erzielt werden. Das Oberflächenharz OFH-PUR2 zeigt im Test innerhalb der Gruppe der polymeren Werkstoffe den höchs-ten 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, wo-bei hier das Verschleißverhalten der Frontgussharze FGH-EP1 und FGH-PUR 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 Prototyp-Werkzeugen und nachfolgender Vergleichsuntersuchungen zu ermögli-chen, wurden drei Prototyp-Ziehwerkzeuge für dasselbe Ziehteil, eine Sitzkissenschale, aus verschiedenen Werkzeugstoffen und unter Berück-sichtigung verschiedener Vorgehensweisen hergestellt.

Nach der Werkzeugeinarbeitung folgte die Herstellung von je 100 Zieh-teilen unter identischen Versuchsbedingungen. Die Versuchspresse verfüg-te über Messelemente zur Erfassung der Kraft-Wegverläufe für Stößel- und 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.


Abb. 5.102. Ausgewählte Profilschnitte für die Werkzeugvermessung und Zieh-teilanalyse [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 Mat-rize. Sie zeigen eine hohe Verschleißbeständigkeit der Werkzeugstoffe G-ZnAl4Cu3 und BM-PA1.


Werkzeugstoff G-ZnAl4Cu3 Bi57Sn43 BM-PA1 Teilestückzahl 0 100 0 100 0 100

R2 7,5 7,5 - - 7,35 7,35 R3 7,4 7,4 - - 7,7 7,8 R6 7,2 7,3 6,0 6,6 7,9 8,1 R7 20,7 21 17,9 18,3 20,9 20,9 R8 7,2 7,2 15,1 16,7 5,8 6,2

Radien am Stempel(in mm)

R11 7,4 7,5 6,8 7,0 7,4 7,5 R1 6,5 6,6 6,7 6,9 6,5 6,6 R4 13,4 13,4 13,4 14,0 13,7 14 R5 12,1 12,3 14,0 15,5 12,7 12,8 R9 6,5 6,5 7,1 7,2 6,5 6,7

Radien an der Matri-

ze (in mm) R10 6,5 6,5 - - 6,5 6,6

Summe der Radien 1,4,5,6,7,8,9,11 (in mm)

81 81,8 87 92,2 81,4 82,8

Abb. 5.105. Gemessene Radien am Werkzeug vor und nach Abschluß der Versu-che [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ächen-qualitä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 Werk-stoffflusses Wegen des geringen E-Moduls des Kunststoffs führt die Her-stellung 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 Bau-teils führen. Auch wird die Übertragbarkeit der Ergebnisse auf das Serien-werkzeug 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 ge-nauen Positionierung der Metalleinsätze, so dass jeder Krafteinleitungs-


punkt der Zieheinrichtung räumlich definiert ist. Vier Führungsplatten, die an den Metalleinsätzen und an der Grundplatte befestigt sind, gewährleis-ten 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über-tragungselemente, die Kraft von der Zieheinrichtung in die Niederhalter-wirkfläche übertragen. Zwischen den Elementen wirkt das Kunstharz als Gelenk [5.142].

Durch den Einsatz eines segmentelastischen Niederhalters und der An-wendung von Mehrpunktzieheinrichtungen ist eine gezielte lokale Beein-flussung des Werkstoffes während des Tiefziehprozesses möglich, was neue Möglichkeiten zur Erzielung eines reproduzierbaren Umform-prozesses und zur Verbesserung der Produktgüte eröffnet. Abb. 5.107 zeigt die Ergebnisse von der Vermessung der Flächenpressung unter dem Nie-derhalter.


Abb. 5.107. Vermessung der Flächenpressung unter dem segmentelastischen Nie-derhalter [5.102].

Erste Untersuchungen haben gezeigt, dass im Vergleich mit einem kon-ventionellen segmentelastischen Niederhalter aus Grauguss tiefere Bautei-le 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 Ver-wendung eines Kunststoffniederhalters mit Metalleinsätzen [5.102].


Bei dem neuen Niederhalterkonzept wird eine neue Konstruktionsmög-lichkeit für die Herstellung von Prototypteilen und den Anlauf der Serien-produktion präsentiert.

Der Niederhalter wird hinsichtlich folgender Punkte untersucht:

Druckverteilung.Einfluss des Kunststoffes: Mit dem neuen Niederhalterkonzept wurden verschiedene Kunststofftypen untersucht. Die Anwendung von thermo-plastischen Kunststoffen ist wegen deren Reibungseigenschaften und des wirtschaftlichen Recyclings von Interesse. 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 Werkzeugher-stellung 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 Sur-

faces. 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 shap-ing (LENS) - a tool for direct fabrication of metal parts. In: Proc. of the laser materials processing conference ICALEO'98, 16.-19. Nov. 1998, Orlando. Or-lando: 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 Ap-plications 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 Re-gelung. 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. Commu-nications of the ACM, Bd. 45, Nr. 7, 64-70

[5.17] Bimber O (2005) The Ultimate Display - What Will It Be? In: IEEE Com-puter 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. Diplo-marbeit, Technische Universität Baunschweig

[5.21] Bowman D (2002) Principles for the Design of Performance-oriented In-teraction Techniques. In: Stanney KM (Hrsg) Handbook of Virtual Environ-ments. 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 Collabo-ration 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 Reali-tyGrid. 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


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.E8-E14.

[5.33] Chin J, Coveney P V, Harting J (2004) The TeraGyroid Project - Collabora-tive Steering and Visualization in an HPC Grid for Modelling Complex Flu-ids. Proc. of the UK e-Science All Hands Meeting

[5.34] Chu CCP, Dani TH, Gadh T (1997) Multi-sensory user-interface for a vir-tual-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 Visualisierungssys-teme. 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, Firmen-schrift

[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 Kleinserien- Karosseriebau. 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 Envi-ronments 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 Im-mersive 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 Werkzeugwerk-stoffe. 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 Stutt-gart

[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. Stutt-gart: Forschungsgesellschaft für Strahlwerkzeuge mbH, S.125-128.

[5.49] Eschl J (2001) Die mechanischen Eigenschaften von Stereolithographiema-terialien 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 Interna-tional 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, Pro-duction and Service. Proc. International Symposium on Mixed and Aug-mented 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 micro-structure 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.


[5.56] Gebhard A (2000) Rapid Prototyping, Werkzeuge für die schnelle Produkt-entwicklung, 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 & la-

ser 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 aufge-

baut. Industrieanzeiger (1994) 18/94, S.46-50. [5.64] Haferkamp H, Bach FW, Gerken J (1997) Rapid Prototyping - Direkte Her-

stellung metallischer Komponenten durch Laserstrahl-Auftragschweißen. In: VDI-Gesellschaft Werkstofftechnik (Hrsg.): Effizienzsteigerung durch inno-vative Werkstofftechnik, Werkstofftag ´95, 15.-16.03.1995, Aachen (VDI Be-richte 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 Pro-totyp- Blechumformwerkzeugen. Dissertation, Universität Stuttgart

[5.68] Häussermann M (2002) Zur Gestaltung von Tiefziehwerkzeugen hinsicht-lich des Einsatzes auf hydraulischen Vielpunktzieheinrichtungen. Dissertati-on, 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 & Manufactur-ing - State of the Industry – Germany. In: Wohlers Report 2005 S 112-114

[5.71] Herziger G, Loosen P (Hrsg.) (1993) Werkstoffbearbeitung mit Laserstrah-lung. 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 Graph-ics and Interactive Techniques, ACM Special Interest Group on Software En-gineering, ACM Special Interest Group on Computer-Human Interaction (Hrsg) Symposium on User Interface Software and Technology archive. Pro-ceedings 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 Laserstrahlge-nerieren. 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 manipu-lation. In: Bauersfeld P, Bennett J, Lynch G. (Hrsg) Proceedings of the SIGCHI conference on Human factors in computing, 3.-7. Mai 1992, Monte-rey. 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- Werk-zeugen 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 Hydro-mechanical Deep- Drawing. (Im Rahmen Proceedings of the Seventh Interna-tional Conference on Computational Plasticity. Barcelona, Spain 7-10 April 2003)

[5.83] Hutchins EL, Hollan JD, Norman DA (1986) Direct Manipulation Inter-faces. In: Norman DA, Draper, SE (Hrsg) User-Centred System Design: New Perspectives on Human-Computer Interaction. Erlbaum, Hillsdale/New Jer-sey, 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 be-

tween 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-PVD-Prozeß. Produktionstechnik-Berlin 167, Carl Hanser Verlag München Wien

[5.90] Keller B (1998) Rapid-Prototyping: Grundlagen zum selektiven Lasersin-tern 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/GLSLangSpecFull11059pdf

[5.92] Kirchner F (2002) Hochleistungsthermoplaste in der Medizintechnik, VDI-Berichte: Hochtemperaturthermoplaste, Band 1687, VDI-Verlag, Würzburg, S. 209-222


[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-. Werkzeug- und 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 Tech-nologies RAPTIA – Intelligent Manufacturing Systems Rapid Product Devel-opment Project. In: Time-Compression Technologies: Harnessing the 4th Di-mension 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 arti-ficial 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) Us-ing Virtual Environments as Training Simulators: Measuring Transfer. In: Stanney KM (Hrsg) Handbook of Virtual Environments. Design, Implementa-tion, and Applications. Erlbaum, Mahwah/New Jersey, S 403-414

[5.101] Leonard W (2001) Selektive Metallisierung von 3Dimensionalen Bautei-len. 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 Pro-ceedings, 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 al-loy. In: Mordike, B.L. Hrsg.): Laser treatment of materials, Proc. of the Euro-pean 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üssel-dorf: 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 Atmos-pheric 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 Be-schichtungsverfahren. Kunststoff-Oberflächenveredelung 1996:69-88

[5.110] Markschläger P, (1998) Reaktive Abscheidung von Metalloxiden auf Po-lycarbonat zur Erzeugung transparenter Verschleißschutzschichten. Disserta-tion 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ünn-schichttechnologien 92:617-630

[5.112] Methner M, (2006) Direkter Weg. Das Metall-Lasersintern verkürzt die Zeit für das Herstellen komplexer Spritzgusswerkzeuge. MM - Maschinen-markt. 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.882-891.

[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 Im-mersive Projection Technology Workshop, May 11-12, 1998, Iowa State Uni-versity, Ames

[5.118] Nvidia (2006) http://developernvidiacom/page/cg_mainhtml NVIDIA Corp

[5.119] Open CASCADE Technology (2006), 3D modeling & numerical simula-tion Bei: http://www.opencascade.org/

[5.120] Pfeifer R (2006) Entwicklung von Rapid Prototyping Verfahren zur Her-stellung verlorener Modelle für den Feinguss, Dissertation Universität Stutt-gart


[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: Be-rechnung 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äts-Umgebung. 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 Visuali-zation 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 Eurograph-ics Workshop in Stuttgart Wien: Springer, 2001 (Springer Computer Science), S 93 – 102

[5.129] Roll K, Altan T, Tekkaya AE, Hermann M (1999) Virtuelle Umformtech-nik. In Geiger M (Hrsg) Umformtechnik 2000 Plus. Meisenbach, Bamberg

[5.130] Rösener B, Kickelhain J Naundorf G (2003) RPID's: Elektrisch funktions-fähige Prototypen ohne Spritzgießformen. In: PLUS Produktion von Leiter-platten 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 Work-shop on Geometric Modeling 7, pp 207-219

[5.132] Roth-Koch S (2001) Hybride Entwurfsmodelle im Rapid Product Devel-opment. 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 3D-Daten für die Echtzeitvisualisierung in High-End-Qualität http://www.rtt.ag

[5.134] Schock D (1996) Gußeisenwerkstoffe für Umformwerkzeuge In: Ta-gungsband zum Seminar Reibung und Verschleiß, MAT INFO Werkstoff- In-formationsgesellschaft 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, Har-bour 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: Anwen-dungsbeispiele 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 Fertigungsverfah-ren. In: Gießerei-Praxis 10: 15-17

[5.141] Siegert K, Huhn S (2002) Anwendung der Virtuelle Realität in der Pro-zessoptimierung und Werkzeugentwicklung. In: Siegert (Hrsg) Neuere Ent-wicklungen in der Blechumformung. MAT INFO Werkstoff- Informationsge-sellschaft mbH, Frankfurt am Main, S 161-174

[5.142] Siegert K, Huhn S, de Souza J HC (2005) Rapid Tooling und Rapid Ma-nufacturing 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 prototy-ping by process combination. In: Campbell, R.I (Hrsg.): Proc. of the 7th Euro-pean 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 Inter-action. Proc. IEEE Virtual Reality 2005, pp. 107–113

[5.146] Slinger C, Cameron C, Stanley M (2005) Computer-Generated Hologra-phy as a Generic Display Technology. In: IEEE Computer 38, Nr. 8, pp. 46-53

[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 Abtra-

gen 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


[5.152] Stierlen P (2002) Rapid Prototyping von Keramiken – Entwicklung eines Verfahrens zur Herstellung reaktionsgebundener SiSiCPrototypen, Dissertati-on Universität Stuttgart

[5.153] Stork A, Amicis R (2000) ARCADE/VT - A Virtual Table-centric model-ing system In: Proceedings of 4th International Immersive Projection Tech-nology Workshop (IPT 2000), June 19-20, 2000, Ames, Iowa

[5.154] Stotz M, Rot-Koch S (2003) A New Feature Orientated Digitising Strat-egy Integrating the Conceptual Design into the Design Engineering. In: 3D Modelling 2003 – Num 3D 23.-24.4. Paris, France, Harbour Conferences, Di-nard

[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 Vakuum- Formverfahren auf die Güte von Gußteilen aus der Legierung G-AlSi12. Dis-sertation, 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 Fein-

blechen. 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 Tempe-rature Resistant Polymers with Carbon Black Additives, Intern. Polymer Pro-cessing 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 Ma-nufacturing 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 Con-ceptual and Stylistics Design into the Virtual Product Development. In: Pro-ceedings International CIRP Design Seminar, 6.-8.6.2001, Stockholm, Schweden, Design Theory, Methodology and its Integration with Computa-tional 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 Ori-ented 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 Segmentie- rung von Messpunktwolken in regelgeometrische Elemente. In: tm - Techni-sches 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. Ox-ford 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 func-tional metallic components. In: Proc. of the laser materials processing confer-ence 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. Indust-

rieanzeiger, 5/96, S.30-32.

Documents

Entwicklung und Erprobung innovativer Produkte - Rapid Prototyping GERMAN