Aufbereitung von Produktmodellen der Industrie zur Verwendung in

Professur für Mediengestaltung
Institut für Software- und Multimediatechnik
Fakultät Informatik
Diplomarbeit
AUFBEREITUNG VON PRODUKTMODELLEN
D E R I N D U S T R I E Z U R V E RW E N D U N G I N I N T E R A K T I V E N
3D-ANWENDUNGEN
sebastian erler
E I D E S S TAT T L I C H E E R K L Ä R U N G
Hiermit versichere ich, die vorliegende Diplomarbeit zum Thema
Aufbereitung von Produktmodellen der Industrie zur Verwendung in
interaktiven 3D-Anwendungen
vollkommen selbstständig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich
gemacht zu haben.
Dresden, 13.09.2012
Sebastian Erler
D AT E N Z U R D I P L O M A R B E I T
TITEL
Aufbereitung von Produktmodellen der Industrie zur Verwendung
in interaktiven 3D-Anwendungen
EINGEREICHT VON
Sebastian Erler
IM STUDIENGANG
Medieninformatik
EINGEREICHT AM
13.09.2012
V E R A N T W O RT L I C H E R H O C H S C H U L L E H R E R
UND BETREUER
Prof. Dr.-Ing. habil. Rainer Groh
Technische Universität Dresden
Fakultät Informatik
Institut für Software- und Multimediatechnik
Professur für Mediengestaltung
EXTERNER BETREUER
Robert Bonča
T-Systems - Multimedia Solutions GmbH
Business Unit E-Business Solutions
v
K U R Z FA S S U N G
Herstellende Unternehmen erzeugen im Rahmen der digitalen Produktentwicklung zunehmend umfassendere Beschreibungen ihrer Produkte. Gleichzeitig entstehen im Bereich des Webs und der mobilen
Endgeräte neue Anreize, diese Inhalte mithilfe der 3D-Grafik zu präsentieren. Für die Forschung stellt sich die Frage, durch welche Prozesse und Werkzeuge die Produktmodelle für die Nutzung in immersiven Anwendungen optimal aufbereitet werden können. Diese
Arbeit stellt nach einer Analyse der in diesem Kontext umzusetzenden Aufgaben ein Konzept zur automatischen Produktmodellaufbereitung vor. Durch die Integration vorhandener Werkzeuge in eine
Softwarelösung und die Bereitstellung von Schnittstellen nach außen,
können große Mengen von Produktmodellen mit geringem Aufwand
für 3D-Anwendungen aufbereitet werden.
ABSTRACT
In the field of digital product development, manufacturing companies are creating increasingly comprehensive product models. At the
same time a technological progress of 3D-applications for the web
and mobile devices can be observed. These advancements lead to a
rising number of opportunities to visualize products using 3D technologies. The upcoming question is how to process product models
in an optimal way to suit the demands of the mentioned 3d technologies. This work presents a concept to automatically process product
data following predefined tasks for this type of problem. The basic
idea is to integrate existing tools in a server side software solution
and to provide the processed data in a service-oriented manner. The
presented work enables the effective processing of large amounts of
product models to be used in 3d-applications.
vii
I N H A LT S V E R Z E I C H N I S
1 einleitung
1.1
1.2
1.3
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .
Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . .
2 grundlagen
2.1
2.2
2.3
Produktmodelle . . . . . . . . . . . . . . . . . . . .
2.1.1 Der Produktlebenszyklus . . . . . . . . . .
2.1.2 Inhalt und Struktur von Produktmodellen
STEP – Standard für den Produktdatenaustausch
2.2.1 Überblick . . . . . . . . . . . . . . . . . . .
2.2.2 Anwendungsprotokolle . . . . . . . . . . .
2.2.3 Anwendungsprotokoll 214 . . . . . . . . .
3D-Darstellung im Web und auf mobilen Geräten
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 verwandte arbeiten
3.1
3.2
3.3
3.4
4.2
4.3
4.4
Analyse des Problems . . . . . . . . . . . . . . . . . . .
4.1.1 Interessengruppen . . . . . . . . . . . . . . . . .
4.1.2 Rahmenbedingungen . . . . . . . . . . . . . . .
4.1.3 Anforderungen . . . . . . . . . . . . . . . . . . .
4.1.4 Vor- und Nachbedingungen der Produktmodellaufbereitung . . . . . . . . . . . . . . . . . . . .
Aufgaben der Produktmodellaufbereitung . . . . . . .
Modellierung des Softwaresystems . . . . . . . . . . . .
4.3.1 Subsystem: PLM-System . . . . . . . . . . . . . .
4.3.2 Subsystem: CAD2Web-Server . . . . . . . . . . .
4.3.3 Subsystem: 3D-Client . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . .
5 implementierung
5.1
5.2
5.3
5.4
5.5
Zielstellung der Implementierung
Abstraktion des PLM-Systems . .
CAD2Web-Server . . . . . . . . . .
3D-Client . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . .
5
5
6
7
11
12
13
15
19
23
Datenformate für den Austausch und die Visualisierung von Produkten . . . . . . . . . . . . . . . . . . . .
Serviceorientierte Ansätze im kollaborativen Produktdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entwicklungen im Bereich verteilter Visualisierungen .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . .
4 konzeption
4.1
1
1
2
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
27
29
32
35
35
35
36
37
39
43
48
53
55
59
60
63
63
63
64
67
69
ix
x
inhaltsverzeichnis
6 auswertung
6.1
6.2
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
71
72
a anhang
75
b glossar
81
literaturverzeichnis
87
ABBILDUNGSVERZEICHNIS
Abbildung 1
Abbildung 2
Abbildung 3
Abbildung 4
Abbildung 5
Abbildung 6
Abbildung 7
Abbildung 8
Abbildung 9
Abbildung 10
Abbildung 11
Abbildung 12
Abbildung 13
Abbildung 14
Abbildung 15
Abbildung 16
Abbildung 17
Abbildung 18
Phasen und Tätigkeiten des Produktlebenszyklus 6
Inhalte von Produktmodellen . . . . . . . . . .
9
Grundlagen des Variantenmanagements im AP
214 (STEP) . . . . . . . . . . . . . . . . . . . . . 18
3D-Formate im Engineering-Umfeld . . . . . . 25
Die Interessengruppen . . . . . . . . . . . . . . 35
Produktmodellaufbereitung mechatronischer Produkte . . . . . . . . . . . . . . . . . . . . . . . . 39
CAD Software: SolidWorks 2010 Premium . . 40
Volumenmodelle und Parametrisierung . . . . 41
Freiformflächen am Beispiel NURBS . . . . . . 42
Zusammensetzung von Polygonnetzen . . . . 42
UML-Anwendungsfalldiagramm . . . . . . . . 49
UML-Aktivitätsdiagramm: Produkt hinzufügen 51
UML-Architektur-Montagediagramm . . . . . 52
Komponenten des CAD2Web-Subsystems . . . 55
3D-Anwendungen zur Integration in den CAD2Web-Server . . . . . . . . . . . . . . . . . . . . 57
Abstraktion des PLM-Systems . . . . . . . . . . 63
Softwarekomponenten im Prozess der Produktmodellaufbereitung . . . . . . . . . . . . . . . . 65
Unity 3D-Webclient und Uploadformular . . . 67
TA B E L L E N V E R Z E I C H N I S
Tabelle 1
Tabelle 2
Tabelle 3
Tabelle 4
Tabelle 5
Tabelle 6
Tabelle 7
Tabelle 8
Strukturierung von ISO 10303 (STEP) in Serien
Wichtige Anwendungsprotokolle im mechanischen Design . . . . . . . . . . . . . . . . . . . .
Gegenüberstellung der Konzepte des Austauschs
und des Teilens von CAD-Daten . . . . . . . .
Anforderungen an die 3D-Anwendung und den
Prozess der Produktdatenaufbereitung . . . . .
Kernaufgaben der Produktmodellaufbereitung
Übersicht – STEP-Bibliotheken (SDK) . . . . .
Umgesetzte Aufgaben der Produktmodellaufbereitung . . . . . . . . . . . . . . . . . . . . . .
Durch den X3D Unity Parser unterstützte X3DKnoten . . . . . . . . . . . . . . . . . . . . . . .
13
14
28
37
43
59
64
68
xi
Tabelle 9
Tabelle 10
ISO 10303 (STEP) – Anwendungsprotokolle . .
ISO 10303 (STEP) – Units of Functionality im
AP214 . . . . . . . . . . . . . . . . . . . . . . . .
ABKÜRZUNGSVERZEICHNIS
Ajax
Asynchronous JavaScript and XML
AP
Application Protocol
API
Application Programming Interface
CAD
Computer-Aided Design
CAE
Computer-Aided Engineering
CAM
Computer-Aided Manufacturing
CORBA
Common Object Request Broker Architecture
DCC
Digital Content Creation
DCOM
Distributed Component Object Model
DIN
Deutsches Institut für Normung
DOM
Document Object Model
GUI
Graphical User Interface
HPC
High Performance Computing
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
ISO
International Organization for Standardization
JSDAI
Java Standard Data Access Interface
JSON
JavaScript Object Notation
JT
Jupiter Tesselation
LOD
Level of Detail
NURBS
Non-Uniform Rational B-Spline
OpenGL
Open Graphics Library
PDM
Product Data Management
xii
77
79
abkürzungsverzeichnis
PLM
Product Lifecycle Management
REST
Representational State Transfer
RFC
Remote Function Call
RMI
Remote Method Invocation
SDK
Software Development Kit
SOA
Service-Oriented Architecture
SOAP
Simple Object Access Protocol
STEP
STandard for the Exchange of Product model data
UML
Unified Modeling Language
UoF
Unit of Functionality
URL
Uniform Resource Locator
VPE
Virtuelle Produktentstehung
VR
Virtual Reality
VRML
Virtual Reality Modeling Language
W3C
World Wide Web Consortium
WebGL
Web Graphics Library
WS
Webservice
WSDL
Web Services Description Language
WWW
World Wide Web
XML
Extensible Markup Language
XSLT
Extensible Stylesheet Language Transformation
X3D
Extensible 3D
xiii
1
EINLEITUNG
1.1
motivation
Unternehmen, welche mechatronische Produkte herstellen – etwa in
der Automobilindustrie oder im Maschinen- und Anlagenbau – sehen
sich aktuell mit einem erheblichen Wandel der Marktbedingungen
konfrontiert. Eine wesentliche Ursache für diesen Wandel ist in der
Globalisierung zu sehen.
Auf der einen Seite führt sie zu einer potentiellen Erweiterung des
Absatzmarktes und auf der anderen Seite zu einer Zunahme der Konkurrenz durch globale Mitbewerber am Markt. Beide Entwicklungen
stellen neue Anforderungen an produzierende Unternehmen.
Die Erschließung neuer Absatzmärkte führt zu heterogener werdenden Zielgruppen mit verschiedenen Ansprüchen an die Produkte. Im Automobilbau zeigt sich zum Beispiel der Trend, durch eine
steigende Anzahl von Fahrzeugvarianten mit zunehmender Ausstattungsvielfalt möglichst viele Kundenwünsche bedienen zu wollen.
Das Ziel ist eine höhere Marktabdeckung.
Auch im Maschinen- und Anlagenbau müssen zunehmend eigentlich standardisierte Produkte an die Anforderungen des Auftraggebers angepasst werden [Kon07, S. 19]. Dies macht es zum Beispiel
einem Vertriebsmitarbeiter schwer, für einen Kunden mit speziellen
Anforderungen das richtige Produkt unter Tausenden bis Millionen
theoretisch möglicher Zusammenstellungen zu wählen. Ebenso hat es
der Kunde schwer sich über die möglichen Varianten eines Produktes
zu informieren.
Abhilfe für dieses Problem versprechen elektronische Produktkonfiguratoren. Sie unterstützen den Vertriebsmitarbeiter oder den Endkunden bei der Zusammenstellung eines Produktes aus vorgegebenen Produktkomponenten unter Beachtung von Konfigurationsregeln.
So übernehmen sie beispielsweise die Prüfung, ob bestimmte Konfigurationen von Produkten technisch realisierbar sind, führen Preisberechnungen durch und erzeugen Stücklisten. Dadurch wird die fehlerfreie Erstellung von Angeboten in kürzester Zeit ermöglicht.
In diesem Zusammenhang kommt auch der 3D-Visualisierung eine
tragende Rolle zu. Sie ermöglicht die sofortige Darstellung des konfigurierten Produktes und stellt damit eine wichtige Form der Kommunikation dar. Die Anwendung von 3D-Technologien im Vertrieb
bleibt dabei nicht auf das Zusammenspiel mit Produktkonfiguratoren beschränkt. Generell ist es von großem Nutzen dem Kunden die
1
Entwicklung:
komplexer werdende
mechatronische
Produkte
Folge:
Bedarf an
3D-Visualisierung
und -Konfiguration
2
Entwicklung:
zunehmend virtuelle
Produktentwicklung
einleitung
zunehmend komplexer werdenden mechatronischen Produkte räumlich erfahrbar zu machen.
Die zweite wichtige Folge der Globalisierung, neben der angesprochenen Erweiterung der Zielgruppe und der damit einher gehenden
Erhöhung der Produktkomplexität, stellt der zunehmende Konkurrenzdruck dar. Durch moderne Logistik und Kommunikationskanäle sind Kunden immer weniger an lokale Hersteller gebunden. Dies
äußert sich für Unternehmen beispielsweise in einem zunehmenden
Innovationsdruck, steigenden Qualitätsansprüchen und dem Zwang,
die Produkteinführungszeit (engl. time to market) verringern zu müssen. All dies ist verbunden mit der Anforderung die Kosten für die
Entwicklung und die Produktion zu senken.
Um diesen Entwicklungen Rechnung zu tragen, setzten Unternehmen seit Jahren verstärkt auf die virtuelle Produktentstehung (engl.
virtual engineering). Darunter wird die durchgehende Rechnerunterstützung bei der Produkt- und Produktionsentwicklung auf Basis digitaler realitätsnaher Modelle verstanden.
Um in heutigen globalen Märkten erfolgreich zu sein, müssen
Unternehmen, und dies schließt kleine und mittelständische Unternehmen explizit ein, adäquate Kompetenzen im Bereich der
virtuellen Produktentstehung aufbauen. [ES09, S.47]
Herausforderung:
Ergebnisse virtueller
Produktentwicklung
optimal für
3D-Anwendungen
nutzen
Die dargestellten Trends, in Form des steigenden Bedarfs an Lösungen zur Produktkonfiguration und -visualisierung einerseits und der
zunehmenden Verbreitung der virtuellen Produktentstehung andererseits, werfen die folgende Frage auf: In wieweit lassen sich die Ergebnisse der virtuellen Produktentstehung für Lösungen zur Konfiguration und zur Visualisierung von mechatronischen Produkten nutzen?
1.2
ziele
Das Ziel dieser Arbeit liegt in der Erstellung eines Konzepts zur optimierten Nutzung von Produktmodellen im Kontext von interaktiven 3D-Anwendungen.
Dabei stellen die Produktmodelle das Ergebnis der virtuellen Produktentstehung in produzierenden Unternehmen dar. Neben der Betrachtung, was die Ergebnisse dieses Prozesses sind und in welcher
Form sie vorliegen, stellt sich vor allem die Frage, wie die resultierenden Daten für 3D-Applikationen bereitgestellt werden können.
Da die Produktmodelle nicht primär für die Nutzung in interaktiven 3D-Anwendungen zu Vertriebszwecken optimiert wurden, legt
dies weiterhin die Notwendigkeit der Aufbereitung dieser Daten nahe. Aus diesem Grunde wird untersucht, welche Schritte der Datenverarbeitung nötig sind, welche existierenden Werkzeuge dazu herangezogen werden können und wie sich diese in eine Gesamtsoftwarearchitektur integrieren lassen.
1.3 aufbau der arbeit
3
Besonderes Augenmerk bei der Entwicklung einer solchen Softwarearchitektur soll auf einem möglichst hohen Automatisierungsgrad liegen. Es wird zu untersuchen sein, wie weit auf manuelle Bearbeitung der Datensätze verzichtet werden kann und welche Kompromisse dabei unter Umständen in Kauf genommen werden müssen.
Weiterhin besteht die Anforderung, Produktmodelle und Teile von
Produktmodellen zur Laufzeit in eine 3D-Anwendung nachladen zu
können. Dies stellt eine wichtige Voraussetzung für den Einsatz im
Kontext von 3D-Webanwendungen dar.
1.3
aufbau der arbeit
An dieser Stelle soll ein Überblick über den Inhalt der vorliegenden
Arbeit gegeben werden, um das methodische Vorgehen beim Erarbeiten der Lösung nachvollziehen zu können.
In Kapitel 1 wird auf aktuelle Entwicklungen im Umfeld der herstellenden Industrie hingewiesen, welche die Grundlage für die zu
bearbeitende Aufgabenstellung bilden. Aus der beschriebenen Situation und den daraus resultierenden Anforderungen der Unternehmen
wird weiterhin die Zielstellung formuliert.
Kapitel 2 führt in die Grundlagen der zu verarbeitenden Produktmodelle ein und stellt relevante 3D-Technologien vor.
Um die Produktinformationen der Industrie sinnvoll in 3D-Applikationen nutzen zu können, ist es nötig, die Inhalte von Produktmodellen zu kennen und zu verstehen. Dazu werden der Produktlebenszyklus, die Inhalte und die Strukturen von Produktmodellen
untersucht. Daraufhin erfolgt die Vorstellung von STEP als wichtigen
Standard zur Repräsentation von Produktdaten. Nachdem damit das
Fundament für das Verständnis der Produktdaten auf Seiten der herstellenden Industrie geschaffen ist, werden mögliche Technologien
zur Darstellung dieser Informationen beschrieben. Dies sind im Besonderen neuere Technologien zur Implementierung von 3D-Anwendungen für das Web und für mobile Geräte.
Kapitel 3 dient der Diskussion relevanter Arbeiten auf dem Gebiet
der verteilten Visualisierung. Der Schwerpunkt liegt im Besonderen
auf aktuellen Entwicklungen im Bereich der kollaborativen Produktentwicklung. Dazu werden 3D-Formate im Engineering-Umfeld sowie Konzepte und Softwaresysteme zur Verteilung, Verarbeitung und
Visualisierung von Produktdaten betrachtet. Darüber hinaus erfolgt
eine Betrachtung allgemeiner Trends im Feld der verteilten Visualisierung im Hinblick auf Hardwareplattformen, Browserentwicklugnen
sowie neue Geschäftsmodelle.
Im Kapitel 4 werden die bis dahin vorgestellten Erkenntnisse zur
Entwicklung einer neuen Lösung genutzt. Dazu ist es zunächst nötig
auf die besonderen Anforderungen einer 3D-Anwendung zur Präsentation von Produkten außerhalb des Engineerings einzugehen. An-
Einleitung
Grundlagen
Verwandte Arbeiten
Konzeption
4
Implementierung
Auswertung
einleitung
schließend wird das Konzept zur optimierten Bereitstellung und Verarbeitung von Produktdaten für 3D-Anwendungen entwickelt. Der
Fokus liegt dabei im Besonderen auf der Quelle der Produktdaten,
deren Verarbeitung sowie deren Visualisierung.
Das Kapitel 5 beschreibt die prototypische Implementierung der
vorgestellten Softwarearchitektur. Es wird auf die Auswahl konkreter
Werkzeuge und Softwarebibliotheken zur Umsetzung eingegangen
und dargelegt, welche Teile der Konzeption implementiert sind.
Kapitel 6 fasst die Ergebnisse dieser Arbeit zusammen und zeigt
Potential für die theoretische und praktische Weiterentwicklung der
vorgestellten Lösung auf.
2
GRUNDLAGEN
2.1
produktmodelle
Um die in der Industrie entstehenden Informationen rund um Produkte besser in 3D-Anwendungen nutzen zu können, ist ein grundlegendes Verständnis für die Verarbeitung und Speicherung dieser
Informationen in den Unternehmen nötig.
Wenn im Rahmen dieser Arbeit von Unternehmen oder der herstellenden Industrie gesprochen wird, ist damit primär der Sektor des
Maschinen- und Anlagenbaus gemeint. In diesem Zusammenhang
sind mit Produkten die Erzeugnisse dieser Branchen gemeint. Man
spricht auch von mechatronischen Produkten. Der Begriff bezeichnet Systeme, die Elemente der Mechanik, Elektronik und Informatik
vereinen. Fabrikate der Automobil- sowie der Luft- und Raumfahrtindustrie gehören ebenfalls dazu.
Im Folgenden wird zu klären sein, welche Informationen die herstellende Industrie über deren Erzeugnisse verwaltet, in welcher Form
die Daten abgelegt werden und welche Möglichkeiten zum Auslesen
der Informationen bestehen. Somit bilden die folgenden drei Themen
die Schwerpunkte dieses Kapitels:
• Inhalt von Produktmodellen
• Struktur von Produktmodellen
• Auslesen von Produktmodellen
Erst wenn klar ist welche Informationen wie zur Verfügung stehen,
lassen sich Ansätze für eine optimierte Nutzung der Daten im Kontext der 3D-Visualisierung finden.
Da der Begriff des Produktmodells eine wesentliche Rolle innerhalb der vorliegenden Arbeit spielt, muss dieser zunächst erläutert
werden. Anschließend veranschaulicht die Vorstellung des Produktlebenszyklus den Ursprung der produktbeschreibenden Informationen. Um den Inhalt und die Struktur von Produktmodellen besser
verstehen zu können, werden die möglichen Inhalte vorgestellt, um
dann auf konkrete Standards und Dateiformate einzugehen, welche
in der Lage sind, die entsprechenden Informationen abzubilden. Die
Möglichkeiten zum Auslesen jener Informationen lassen sich nachfolgend durch die Diskussion wesentlicher Merkmale informationstechnischer Systeme zur Verwaltung von Produktdaten erkennen.
Zunächst wird das Konzept des Produktmodells vorgestellt. Es
existieren verschiedene Definitionen dessen, was der Begriff Produkt-
5
6
grundlagen
Anforderungen
Sammeln der
Anforderungen
Produktplanung
Programm- /
Portfolioplanung
Projektplan,
Team- & Budgetbestimmung
Anforderungsbestimmung
Methodik
Konzeption
Entwicklung
Mechanische
Konstruktion
Elektrische
Konstruktion
Elektronische
Konstruktion
Softwarekonzeption
Simulation
DMU/PMU
Prozessplanung
Produktion
Betrieb
Prozessplanung
Herstellung
Distribution
Werkzeugdesign
Zusammenbau
Service
Herstellungsressourcenfestlegung
Qualitätsabsicherung
Wartung &
Revision
Recycling
Recycling
Einkauf
Simulation/
Testen
Testen
Dokumentation
Abbildung 1: Phasen und Tätigkeiten des Produktlebenszyklus, nach
[ES09, S. 9]
modell bezeichnet. Diese Arbeit geht von folgendem Verständnis des
Begriffs aus (vgl. [ES09, S. 27], [Nur09, S. 54]).
produktmodell: Ein Produktmodell ist die modellhafte Darstellung eines Produktes in digitaler Form. Ziel ist die Abbildung
des Produkts mit seinen für den gesamten Lebenszyklus relevanten Informationen.
2.1.1
Phasen im
Produktlebenszyklus
Der Produktlebenszyklus
Wie für viele weitere Erzeugnisse lässt sich auch für mechatronische
Produkte ein Lebenszyklus erkennen. Dieser beschreibt die Phasen
im Leben eines Produktes von den ersten Überlegungen bis hin zur
Entsorgung. Nach STARK ist der Lebenszyklus jedoch nicht einheitlich, sondern stets abhängig von der Sicht auf diesen. Für den Vertrieb
könnten sich die Phasen als Produkteinführung, Anstieg des Absatzes, Sättigung des Marktes und Absinken des Absatzes darstellen.
Der Produktlebenszyklus lässt sich ebenfalls aus dem Blickwinkel
des Herstellers oder des Endkunden betrachten sowie im Hinblick
auf die globale Ressourcenkette [Sta05, S. 17-19].
Für die weiteren Betrachtungen ist die Sicht vom Hersteller von besonderer Bedeutung. Schließlich ist es der Hersteller, der im Rahmen
der virtuellen Produktentwicklung (VPE) die wesentlichen Informationen zu seinen Produkten verwaltet und speichert.
Der Produktlebenszyklus ist aus dem Grunde von Bedeutung, da
mit jeder Phase aus Sicht des Unternehmens bestimmte Tätigkeiten
verbunden sind. Zu diesen Tätigkeiten werden Informationen über
die Produkte verarbeitet und gespeichert. Der Produktlebenszyklus
dient hier dem Überblick der im produzierenden Unternehmen für
ein Produkt anfallenden Daten. Abbildung 1 zeigt die Phasen im Produktlebenszyklus mit den zugehörigen Tätigkeiten.
In den mittleren Phasen Produktplanung, Entwicklung, Prozessplanung und Produktion fallen in herstellenden Unternehmen traditio-
2.1 produktmodelle
nell die meisten Informationen an. Dieser Teil wird als Produktentstehungsprozess bezeichnet [ES09, S. 10]. Ziel des Produktentstehungsprozesses, als Bereich des Produktlebenszyklus, ist die vollständige
elektronische Beschreibung des virtuellen Produktes. Die Dokumente betreffen dazu neben dem Produkt selbst auch deren Produktion.
In diesem Zusammenhang wird auch deutlich, dass sich der Lebenszyklus weniger auf das konkrete physische Produkt in den Händen
des Kunden bezieht, als viel mehr auf die intellektuelle Beschreibung
der Produktreihe als Eigentum des Unternehmens. In den Unternehmen setzt sich zunehmend die Erkenntnis durch, dass es nicht ausreichend ist, nur Daten des Produktentwicklungsprozesses einheitlich zu speichern und zu verarbeiten. Eine ganzheitliche Sichtweise
auf den Produktlebenszyklus verbreitet sich zunehmend. Herstellende Unternehmen verwalten heute auch Daten, welche die Produkte betreffen, nachdem sie die Werkshallen verlassen haben. Aktivitäten in diesem Zusammenhang werden als Product Lifecycle Management (PLM) bezeichnet.
2.1.2
Inhalt und Struktur von Produktmodellen
Durch den Lebenszyklus der Produkte ist bereits deutlich geworden,
aus welchen Aktivitäten und Phasen sich die produktbezogenen Informationen ergeben. An dieser Stelle soll dargestellt werden, welche
Daten in Industrieunternehmen potentiell zu deren Produkten vorliegen und wie sich diese inhaltlich strukturieren lassen. Weiterhin ist
von Interesse, welche dieser Daten besonders relevant für die Verwendung in 3D-Anwendungen zu Vertriebszwecken sind.
Generell lässt sich feststellen, dass es eine vollständige Auflistung
aller möglichen Informationen zu Produkten nicht geben kann. Welche Daten ein Unternehmen über seine Produkte führt, hängt unter
anderem von der Branche, dem Unternehmen und nicht zuletzt von
der Art der Produkte ab. Es wäre nicht sinnvoll alle Typen von Informationen auflisten zu wollen, die je über ein Produkt der hier fokussierten Branchen angefallen sind. In diesem Sinne lässt sich kein
allgemeingültiges Informationsmodell für mechatronische Produkte
formulieren. Wohl aber lassen sich jene Daten bezeichnen, die besonders häufig in solchen Unternehmen anfallen und als branchenüblich
gelten.
In der Literatur finden sich unterschiedliche Ansätze, um die Inhalte von Produktmodellen strukturiert aufzuführen. Es lassen sich
Aspekte erkennen wie die Phase im Lebenszyklus, in der die Informationen erzeugt werden. Auch eine Kategorisierung danach, ob ein
direkter Bezug zum Produkt besteht oder nicht, ist denkbar. Bei Daten mit direktem Produktbezug wird auch von produktdefinierenden oder produktbeschreibenden Daten gesprochen [SI08, S. 7]. Dem
gegenüber stehen etwa Informationen zu Bestellprozessen, der Ferti-
7
8
grundlagen
gung oder dem Personalwesen, die zwar eine Zugehörigkeit zu einer
konkreten Produktreihe erkennen lassen, diese selbst jedoch nicht direkt beschreiben.
Nach EIGNER und STELZER ergibt sich der Inhalt von Produktmodellen aus folgenden Teilen [ES09, S 28]:
• Produktstammsatz und Produktstruktur
• Dokumente und Dokumentenstruktur
Unter Stammdaten werden dabei jene Daten verstanden, die selbstständig, ohne Beziehung zu anderen Daten aussagefähig sind. Beschreibungen der Geometrie oder Preisinformationen fallen beispielsweise in diese Kategorie. Strukturdaten stellen dagegen die Beziehungen zwischen den Ausprägungen von Stammdaten her. Stücklisten
erfüllen unter anderem dieses Kriterium.
Ein Dokument stellt laut DIN 6789 eine als Einheit gehandhabte Zusammenstellung von Informationen dar, die nicht flüchtig auf einen
Informationsträger gespeichert sind [ES09, S. 29]. Sie lassen sich in
technische und kommerzielle Dokumente einteilen und enthalten eine Dokumentenstruktur. Sie basieren weiterhin auf Industriestandards,
proprietären Formaten oder genormten Formaten.
SAAKSVUORI und IMMONEN betrachten Produktdaten hingegen unter anderen Aspekten. Sie erkennen in Bezug auf den Inhalt
von Produktdaten im Groben drei Gruppen [SI08, S. 7]:
• Daten zur Produktdefinition
• Daten zum Produktlebenszyklus
• Metadaten zur Beschreibung der Produkt- und Lebenszyklusdaten
Daten zur Produktdefinition beschreiben dabei physikalische oder
funktionale Eigenschaften. Dies beinhaltet sowohl technische Daten,
als auch abstrakte oder konzeptionelle Informationen. Daten dieser
Gruppe dienen somit der kompletten Definition des Produktes.
In der zweiten Gruppe sehen SAAKSVUORI und IMMONEN jene
Daten, mit Bezug zu Prozessen des Produktlebenszyklus. Dies beinhaltet Informationen aus den Bereichen Forschung, Design, Produktion, Nutzung, Wartung und Produktbeseitigung. Auch offizielle Regularien und Vorschriften fallen in diese Kategorie.
Darüber hinaus gehören zu den Produktdaten auch Metainformationen. Im Sinne einer Information über Informationen beschreiben
sie wiederum die Daten der Produktdefinition und die des Produktlebenszyklus. Beispiele dafür sind Angaben zur Art der Informationen,
zum Ablageort, zum Autor oder zu den Zugriffsbeschränkungen.
2.1 produktmodelle
Produktdatenmodell
Technische Informationen
Kommerzielle Informationen
Produkt-Geometrie
Absatz
Darstellung 3D/2D
Darstellungsangaben
Abmessungen
Toleranzen
Produkt-Technologie
Werkstoff
Oberflächen-Farbe
Oberflächen-Muster
Oberflächen-Reflexion
Oberflächen-Transparenz
Festkörper-Simulation
Kinematische-Simulation
Funktion
Physikalische Eigenschaften
Technische Klassifikation
Teileart
Normierte Benennung
Statusdaten
Varianten-Entwurfsstückliste
Varianten-Planungsstückliste
Varianten-Auslieferungsstückliste
Varianten-Wartungsstückliste
Dokumentation
Fertigung
Fertigungspläne
Betriebsmittel
Schablonen
Methodenpläne
NC-Programmierung
Urmodelle
Qualitätssicherung
Verkaufspreis
Rabatte
Bonuskonditionen
Mindestverkaufsmenge
Verpackungsmengen
Bestand
Akkumulierte Bestände
Akkumul. reservierte Bestände
Mindestbestand
Bedarf
Bedarfsart
Akkumulierter gedeckter Bedarf
Disposition
Beschaffungsart
Dispositionsart
Dispositionsstufe
Ersatzteileart
Kalkulation
Materialkosten
Lohnkosten
Maschinenkosten
Auftragswiederholkosten
Lagerkostensatz
Produktion
Materialkosten
Lohnkosten
Maschinenkosten
Auftragswiederholkosten
Beschaffung
Lohnkosten
Maschinenkosten
Auftragswiederholkosten
Abbildung 2: Inhalte von Produktmodellen
9
10
grundlagen
Bezogen auf die Kategorisierung von Produktdaten nach SAAKSVUORI und IMMONEN besitzen die produktdefinierenden Informationen der ersten Gruppe die höchste Relevanz für diese Arbeit. Diese
sind für die Nutzung im Rahmen von 3D-Anwendungen besonders
von Interesse. Schließlich soll in einer Anwendung zur Vertriebsunterstützung vor allem das Produkt selbst beschrieben und beworben
werden.
Im Folgenden wird daher besonders zu klären sein, welche Daten
mit direktem Produktbezug innerhalb produzierender Unternehmen
anfallen und welchen Nutzen diese im Kontext von 3D-Vertriebsanwendungen haben können.
Eine Übersicht von Informationen, die häufig zu Produkten in der
Industrie verwaltet werden, ist in Abbildung 2 dargestellt. Im Groben
lässt sich eine Einteilung nach Inhalten mit technischen Bezug und
Inhalten mit kommerziellen Bezug treffen. Zu den technischen Daten
gehören zum einen Angaben mit direktem Produktbezug, etwa Beschreibungen der Geometrie oder der Technologie des Artikels. Zum
anderen existieren technische Informationen mit weniger direktem
Produktbezug. Diese Gruppe von Daten bezieht sich hauptsächlich
auf Prozesse der Fertigung. Da die Letztgenannten nicht das Produkt
selbst beschreiben, sind sie für die Betrachtungen im Rahmen dieser
Arbeit weniger von Interesse.
Neben der Aufzählung der Inhalte von Produktmodellen ist in Abbildung 2 auch die Relevanz der jeweiligen Inhalte für die Verwendung in 3D-Vertriebsanwendungen dargestellt. Die grau abgebildeten Inhalte sind für solche Anwendungen weniger relevant. Essentiell
sind hingegen die geometrischen Informationen, die in den Phasen
des Designs und der Konstruktion mit Werkzeugen des CAD entstehen.
Neben zweidimensionalen Zeichnungen betrifft dies vor allem dreidimensionale Modelle der Produkte. Diese liegen in sogenannten Volumenmodellen vor und stellen mathematisch präzise Beschreibungen der Produktgeometrie dar. Bei dieser Art von Geometrierepräsentation lässt sich die Form jederzeit anhand von Parametern ändern. Für den Prozess der Konstruktion ist diese Methode günstig,
da sie nachträgliche Änderungen an der Form ermöglicht und diese darüber hinaus für Prozesse der Fertigung sehr präzise beschreibt.
Für 3D-Anwendungen zur Präsentation der Produkte ist diese Form
der Geometriebeschreibung ungeeignet, da sie hohe Anforderungen
an die Rechenleistung bei der Darstellung stellt. In Kapitel 4 wird
dieses Problem näher beschrieben und Lösungsmöglichkeiten vorgestellt. Relevant für die Darstellung im Kontext einer Vertriebsanwendung sind neben der Geometrie selbst auch Angaben über die Abmessungen von Teilen und Baugruppen.
Bezogen auf die Technologie der Produkte sind besonders Angaben zur Beschaffenheit, zur Struktur und zu physikalischen Eigen-
2.2 step – standard für den produktdatenaustausch
schaften von Interesse. Die Beschaffenheit wird durch Angaben zum
Werkstoff und durch Oberflächeneingenschaften wie Farbe, Reflexion
oder Transparenz beschrieben. Informationen zur Struktur der Produkte liegen explizit in Form von Stücklisten, aber auch implizit innerhalb der 3D-Modelle vor.
Der im Kapitel 1 beschriebene Umstand der zunehmenden Komplexität von Artikeln zeigt sich in der Form der Strukturdarstellung
innerhalb von Produktmodellen. Die Stücklisten beschreiben die Hierarchie und die Quantität von Baugruppen und Einzelteilen, aus denen Produkte zusammengesetzt sind. Dabei besteht ein Produkt aus
einer oder mehreren Baugruppen und eine Baugruppe wiederum aus
mehreren Einzelteilen. Die einzelnen Produktvarianten sind nicht explizit in einer Stückliste aufgelistet, sondern in Form von regelbasierten Variantenstücklisten beschrieben (vgl. [ES09, S. 87]). Zudem existieren verschiedene Stücklisten aus Sicht des Produktlebenszyklus.
Neben den Entwurfs- und Planungsstücklisten sind besonders die
Auslieferungs- und Wartungsstücklisten für die Nutzung in 3D-Anwendungen relevant.
Die Beschreibung von physikalischen Eingenschaften erfolgt in der
Regel durch Messung oder Simulation. Dazu gehören Angaben des
Gewichts oder der Oberflächensteifigkeit, bis hin zu Ergebnissen der
Festkörper- und Kinematiksimulation.
Bezüglich der kommerziellen Informationen über Produkte interessieren im Hinblick auf vertriebsunterstützende Anwendungen vor
allem die Absatzinformationen wie Verkaufspreise, Rabatte oder Bonuskonditionen.
2.2
step – standard für den produktdatenaustausch
In diesem Abschnitt wird beschrieben, auf Grundlage welcher Formate Produktdaten in der Praxis gespeichert und verarbeitet werden. Diese Problematik ist innerhalb der produzierenden Industrie
nach wie vor ein aktuelles Thema (siehe [Fro11], [DBM+ 07], [BDP07]).
Aufgrund der vielschichtigen Anforderungen unterschiedlicher Branchen und einer Vielzahl von Softwarelösungen sind die Standards in
diesem Bereich hoch komplex.
Für die Betrachtung im Rahmen dieser Arbeit wird mit STEP der
aktuell wohl wichtigste internationale Standard in dieser Domäne näher betrachtet (vgl. [Fro11, S. 4]). Der Fokus liegt im Besonderen auf
den Fragen, welche Produktinformationen von einem solchen Standard abgedeckt sind und wie diese üblicherweise ausgetauscht werden. Neben diesen Fragen wird es für ein Grundverständnis dieser
wichtigen Norm auch nötig sein, die Grundstrukturen des Standards
kurz vorzustellen.
11
12
grundlagen
2.2.1
Überblick
ist ein durch die internationale Normungsorganisation ISO zertifizierter Standard für den Austausch von Produktdaten. Die formelle
Bezeichnung lautet ISO 10303. Die Abkürzung STEP beschreibt hingegen den Inhalt des Standards und steht für STandard for the Exchange
of Product model data. Der Standard stellt in Bezug auf Produktdaten
folgende Funktionalitäten zur Verfügung (vgl. [And00, S. 10]):
STEP
• Speicherung
• Austausch
• Archivierung
• Transformation
Ziele von STEP
Es werden Mechanismen bereitgestellt, die besonders die systemunabhängige Beschreibung und den Austausch von Produktdaten ermöglichen. Der Fokus liegt dabei auf der Abdeckung von Produktinformationen bezogen auf den gesamten Produktlebenszyklus.
Als Folge der Standardisierung zählt STEP heute zu den wichtigsten
Austauschformaten im Bereich der virtuellen Entwicklung mechatronischer Produkte. Üblicherweise wird STEP innerhalb von CAD, CAM,
CAE, PDM, PLM und anderen CAx-Systemen für den Datenaustausch
verwendet.
Dabei stellt STEP nicht einfach nur ein Datenformat dar. Es lässt
sich viel mehr als Sammlung von Standards verstehen, zu der kontinuierlich neue Teile hinzukommen. In diesem Sinne spricht man von
ISO 10303 auch als Normenreihe [And00, S. 45].
Tabelle 1 zeigt den groben Inhalt des STEP-Standards durch dessen
Einteilung in Serien. Sie fassen inhaltlich zusammengehörige Teile
der Norm zusammen. Der Aufbau kann so verstanden werden, dass
zunächst grundlegende Strukturen und Inhalte definiert werden, um
sie in verschiedenen höheren Anwendungsbereichen nutzen zu können. Als Beispiel sei die Modellierungssprache EXPRESS erwähnt. Eigens für STEP entwickelt, ermöglicht sie das Erstellen von Referenzmodellen für mehrere Anwendungsdomänen. So wurden mit Hilfe
dieser Modellierungssprache spezialisierte Referenzmodelle für den
Datenaustausch im Bereich des Automobil- sowie des Schiffbaus definiert.
In diesem Sinne können die Teile (engl. parts) 1-100 als grundlegende Werkzeuge verstanden werden, um die Beschreibung und den
Austausch von Produktinformationen in unterschiedlichen Anwendungsbereichen zu ermöglichen. Zu diesen grundlegenden Inhalten
zählen neben der bereits erwähnten Modellierungssprache etwa Festlegungen zur Implementierung und Qualitätssicherung von Softwarelösungen. Erwähnenswert sind darüber hinaus die Inhalte der 40erSerie. Dort werden generische Ressourcen zur Beschreibung der Geo-
2.2 step – standard für den produktdatenaustausch
serie
inhalt
1-10
Einführende Dokumente, Zielsetzung, Aufbau der
Norm
10er
Spezifikationsmethoden zur Beschreibung von Modellen (Modellierungssprache EXPRESS)
20er
Normen zur Implementierung von Softwarelösungen
30er
Methoden zur Konformitätsprüfung von Implementierungen
40er
Anwendungsneutrale Produktmerkmale (z. B. Geometriemodell, Produktstruktur, Präsentationsmodell)
100er
Anwendungsbezogene
Basismodelle
Zeichnungserstellungs-, Kinematikmodell)
200er
Anwendungsprotokolle (AP) zur Verwendung von Produktmodellen in bestimmten Anwendungskontexten
300er
Testfälle zur Konformitätsprüfung der AP
500er
Allgemeine Konstrukte des Produktmodells
(z. B.
Tabelle 1: Strukturierung von ISO 10303 (STEP) in Serien (vgl. [And00, S. 44])
metrie und der Struktur von Produkten sowie Angaben zur Präsentation von Produktdaten bereitgestellt.
2.2.2
Anwendungsprotokolle
Die vorgestellten Grundstrukturen werden durch sogenannte Anwendungsprotokolle (AP) für bestimmte Domänen genutzt. Deren Inhalte
definieren die Teile der 200er-Serie. In folgende Gruppen von Anwendungsbereichen lassen sich die AP im Wesentlichen gliedern:
• Mechanisches Design
• Elektronik
• Schiffbau
• Fertigung
• Life Cycle Support
Eine Liste der Anwendungsprotokolle ist im Anhang in Tabelle 9
dargestellt. Davon sind für die Praxis allerdings nur wenige relevant.
Die mit Abstand am weitesten verbreiteten Protokolle finden sich innerhalb der Gruppe des mechanischen Designs. Die Inhalte und Refe-
13
14
grundlagen
jahr
ap-nr
name
1994
AP 203
Configuration-controlled 3D designs of mechanical parts and assemblies
1995
AP 214
Core data for automotive mechanical design
processes
2012
AP 242
Managed model based 3d engineering
Tabelle 2: Wichtige Anwendungsprotokolle (AP) im mechanischen Design
und deren Veröffentlichungsdaten
renzmodelle dieser Anwendungsprotokolle sind es, die durch CAD, PDM- oder PLM-Systeme implementiert werden, um Produktdaten
zwischen ihnen auszutauschen.
Tabelle 2 stellt die wichtigsten Anwendungsprotokolle vor, die im
Bereich des mechanischen Designs relevant sind. Am Veröffentlichungsdatum ist zu erkennen, in welcher Reihenfolge diese erschienen sind.
Dabei umfasst das spätere Anwendungsprotokoll jeweils die Inhalte
des Vorherigen und erweitert diese entsprechend den Erfahrungen
und Bedürfnissen der Industrie.
Das Anwendungsprotokoll 214 ist, von den drei genannten, aktuell von größter Bedeutung. Es ist überhaupt eines der in der Praxis
meistgenutzten Teile der ISO 10303 Normenreihe für den Produktdatenaustausch. Aus dem Grund wird darauf im folgenden Kapitel
gesondert eingegangen.
aktuelle entwicklungen In Tabelle 2 wird weiterhin das AP
242 genannt. Es stellt den Folgestandard des aktuell genutzten Protokolls AP 214 dar und soll voraussichtlich Ende 2012 als ISO-Standard
verabschiedet werden.
Die Daten sollen dabei verstärkt im XML-Format abgelegt und
ausgetauscht werden [Prob]. Dadurch lassen sie sich leichter in internetbasierte Anwendungen integrieren. Vor allem im Bereich des
WWW wird das XML-Format häufig zur Verarbeitung und Verbreitung strukturierter Informationen eingesetzt. Daher ist zu erwarten,
dass aufgrund von weit verbreitetem know-how und einer Vielzahl
von Werkzeugen zur XML-Verarbeitung künftige Datenmodelle der
Industrie besser weiterverarbeitet werden können. Bisher gestaltet
sich das Lesen und Schreiben von Daten im STEP-Format, ohne erhebliches Wissen um den Standard und spezielle Softwarebibliotheken,
als schwierig.
Weiterhin kommt im Standardisierungsprozess des AP 242 auch der
Umstand zum tragen, dass die Ergebnisse der virtuellen Produktentwicklung zunehmend für Anwendungen im Visualisierungsumfeld
2.2 step – standard für den produktdatenaustausch
genutzt werden sollen. So wird im Rahmen der Entwicklung dieser
Norm speziell auf Anforderungen der Visualisierung eingegangen.
Zu diesem Zweck soll die Normung des AP 242 eng mit dem,
ebenfalls aktuell in der Standardisierung befindlichen, Grafikformat
Jupiter Tesselation (JT) abgestimmt werden. Es ist geplant, beide Formate so zu spezifizieren, dass JT als leichtgewichtiges Format für die
Repräsentation der Geometrie dient und STEP als Informationsträger
für Daten des Produktlebenszyklus genutzt wird.
Das JT-Format ist dazu deutlich stärker auf Anforderungen der Visualisierung in verteilten Umgebungen optimiert. Möglichkeiten der
Kompression beschleunigen beispielsweise die Übertragung der Daten und verschiedene Detailgrade (Level of Detail (LOD)) der Geometrie sorgen für eine Anpassung der Geometriekomplexität an die
Leistungsfähigkeit der darstellenden Geräte.
2.2.3
Anwendungsprotokoll 214
Wie bereits erwähnt, stellt das AP 214 einen der wichtigsten Teile der
ISO 10303 dar und ist damit ein weit verbreitetes Format für den Austausch von Produktdaten im Bereich des mechanischen Designs. Der
Name Core data for automotive mechanical design processes lässt vermuten, es handle sich um einen Standard ausschließlich zur Verwendung
in der Automobilindustrie. Die Norm findet jedoch auch in der Luftund Raumfahrtindustrie sowie im Maschinen- und Anlagenbau breite Anwendung (vgl. [Scr06, S. iv]).
Der Fokus dieses Anwendungsprotokolls liegt auf Daten, die während der Designphase entstehen. Dies beinhaltet den Austausch von
produktbeschreibenden Daten, wie Geometrien auf der einen Seite
und den Austausch von organisatorischen Daten, etwa jene der Prozessplanung, auf der anderen Seite [And00, S. 132]. Im Vordergrund
stehen dabei die Produktstruktur und die Handhabung der Varianten von Produkten, die in der Automobilindustrie üblicherweise zahlreich sind.
Welche Produkteigenschaften durch STEP entsprechend des AP 214
beschrieben werden, ist im Standard durch eine Reihe von Funktionseinheiten, Unit of Functionality (UoF) genannt, festgelegt. Der
Standard ordnet diese Funktionseinheiten dabei in folgende logische
Gruppen entsprechend deren Inhalten:
• Oberflächeneigenschaften
• Zeichnungen
• Externe Referenzen
• Formmerkmale
• Geometrie
15
16
grundlagen
• Kinematik
• Messdaten
• Produkteigenschaften
• Darstellung
• Produktstruktur
• Toleranzen
Im Anhang sind in Tabelle 10 die logischen Gruppen mit den entsprechenden UoF des AP 214 aufgelistet. Im Folgenden soll nur auf
die für diese Arbeit wichtigsten Inhalte näher eingegangen werden.
In Unterabschnitt 2.1.2 sind bereits die generellen Inhalte von Produktmodellen im Umfeld des Maschinen- und Anlagenbaus genannt
worden. Viele davon finden sich im AP 214 wieder.
oberflächeneigenschaften Der Standard bietet die Möglichkeit die Oberflächenbeschaffenheit von Produkten zu beschreiben. Dazu gehören vor allem visuelle und haptische Informationen. Zu den
visuellen Informationen zählen Angaben wie Farb-IDs, Farbnamen,
die Reflektivität, die Bezeichnung der Musterung (z.B. für Sitzbezüge) oder der Grad der Transparenz der Oberfläche. Darüber hinaus
lassen sich auch Informationen zum Härtegrad und zur Oberflächenrauigkeit machen. Angaben zum Werkstoff sind ebenfalls möglich.
geometrie Die UoF der Gruppe Geometrie des Anwendungsprotokolls 214 definieren acht mögliche Formen der Geometrierepräsentation (siehe Tabelle 10, Anhang). Einige beschreiben lediglich grundlegende geometrische Primitiven oder erweitern andere Teile um bestimmte Eigenschaften. So lassen sich im wesentlichen folgende vier
Formen geometrischer Modelle im Anwendungsprotokoll 214 erkennen:
• Drahtgittermodelle
• Flächenmodelle
• Konstruktive Festkörpergeometrien
• Punktwolken
Die Drahtgittermodelle (engl. wireframe models) besitzen keine
Flächen und bestehen lediglich aus Punkten, Linien und Kurven. Die
Norm kennt zwei- und dreidimensionale Drahtgittermodelle.
Oberflächenmodelle (engl. surface model), in der durch STEP definierten Form, beschreiben die Hüllen geometrischer Körper. Dabei
besteht die Hülle aus einer Sammlung von miteinander verbundenen
Flächen. Diese Flächen werden wiederum zwischen Punkten, Kanten
2.2 step – standard für den produktdatenaustausch
oder Kurven aufgezogen. Das AP 214 kennt in dem Zusammenhang
Oberflächenmodelle, die nur aus planaren Flächen bestehen und jene,
die auch kurvige Geometriekörper enthalten können.
Konstruktive Festkörpergeometrien ermöglichen den Austausch von
Geometrien, wie sie in der Regel im Rahmen der CAD-Modellierung
anfallen. Ein solches Modell setzt sich aus Primitiven wie Würfeln,
Zylindern oder Kugeln zusammen, die durch boolesche Operationen
zu komplexeren Formen verknüpft werden. Die Objekte, sog. solids,
können darüber hinaus veränderbare Parameter besitzen, deren Werte die Geometrie beeinflussen.
Punktwolken sind zwar nicht durch eine eigene UoF beschrieben,
aber dennoch im Standard enthalten. Sie stellen eine Sammlung kartesischer Koordinaten, mit oder ohne Richtungsvektor dar und entstehen üblicherweise als Ergebnis von 3D-Scans.
Neben den vier vorgestellten Formen der Geometrierepräsentation definiert das AP 214 ein sogenanntes Verbundmodell (engl. compound model). Dieses stellt jedoch keine eigene geometrische Beschreibungsform dar. Ein Verbundmodell sammelt verschiedene geometrische Objekte und vereint sie in einem topologisch verbundenen
Modell. Dazu gehören Drahtgitter- und Flächenmodelle sowie konstruktive Festkörpergeometrien.
produktstruktur: variantenmanagement Das Prinzip hinter der Handhabung der Variantenvielfalt durch STEP beruht auf einer generischen Produktstruktur (vgl. [MPMS98, S. 1]). Das heißt, es
existiert keine einzigartige Bezeichnung für jede produzierbare Variante eines Produktes. Es werden vielmehr Regeln definiert, die eine
Kombination verschiedener Komponenten spezifizieren. Das Ziel der
Anwendung dieser Regeln ist es, zu prüfen, ob die Kombination bestimmter Produktkomponenten zulässig ist.
Um die grundlegenden Konzepte des Variantenmanagements, auf
Basis des AP 214, anschaulich darzustellen, soll ein Beispiel herangezogen werden. Abbildung 3 stellt eine einfache generische Produktstruktur eines Fahrzeuges dar. Die Grafik beschränkt sich dabei auf
die wichtigsten Konzepte. Das Anwendungsprotokoll 214 bietet zur
Beschreibung von Produktvarianten einige Möglichkeiten mehr. Das
im Beispiel vorgestellte Produktmodell könnte bei gleicher Bedeutung auch in anderer Form definiert werden.
Das Grundkonzept dieser generischen Produktstruktur basiert auf
der Definition von Produktklassen (product class) und deren näherer
Beschreibung durch Eigenschaften. Zu diesen Eigenschaften gehören Spezifikationskategorien (specication category), Spezifikationen
(specication), Spezifikationsausdrücke (specication expression) und Spezifikationseinbeziehungen (specication inclusion). Diese Eigenschaften werden als Anwendungsobjekte (application objects) bezeichnet
und sind in Abbildung 3 rechts dargestellt. Auf der linken Seite der
17
18
grundlagen
»Wohnmobil«
PRODUCT CLASS
class_category_association;
mandatory
»Motorisierung«
class_specification_association;
replaceable standard
SPECIFICATION
CATEGORY
category
»Motor 2,3l«
SPECIFICATION
alternative_solution
»Motor 2,8l«
»Komfort-Paket«
»Dachfenster«
»Dachantenne«
»Tempomat«
NOT [Dachfenster AND Dachantenne]
class_condition_association;
validity
if [Komfort-Paket]:
Dachfenster AND Tempomat
SPECIFICATION
EXPRESSION
SPECIFICATION
INCLUSION
class_inclusion_association;
Abbildung 3: Grundlagen des Variantenmanagements im AP 214 (STEP)
2.3 3d-darstellung im web und auf mobilen geräten
Abbildung finden sich die zugehörigen Instanzen dieser Anwendungsobjekte entsprechend des Beispiels.
Eine Produktklasse stellt dabei eine Menge gleichartiger Produkte
dar, die durch ein Unternehmen angeboten werden. Spezifikationen
dienen dazu, die Produktklasse im Hinblick auf Charakteristik und
Funktion näher zu beschreiben. Sie stellen in der Regel zur Produktklasse eine »besteht-aus« Beziehung her. Damit beschreiben sie Produktkomponenten und können zu Kategorien von Spezifikationen
zusammengefasst werden. Eine solche Spezifikationskategorie stellt
eine Eigenschaft dar, die ein Produkt prinzipiell besitzen kann. Erst
durch eine Spezifikation nimmt diese einen konkreten Wert an.
Im Beispiel hält die Produktklasse Wohnmobil eine Beziehung zur
Kategorie Motorisierung mit dem Parameter mandatory, was darauf
hinweist, dass ein Produkt dieser Klasse eine Spezifikation dieser Kategorie besitzen muss. Darüber hinaus sind auch optionale Kategorien möglich.
Für Spezifikationen können Alternativen angegeben werden. Im
Beispiel geschieht dies durch eine Verbindung vom Typ alternative_solution zwischen den Spezifikationen Motor 2,3l und Motor 2,8l. Eine dieser Spezifikationen stellt dabei zunächst die Standardbelegung
dar.
Ein Spezifikationsausdruck (specication expression) stellt einen logischen Ausdruck zur Formulierung gültiger Konfigurationen dar. Er
setzt sich aus Operatoren und Operanden zusammen. Als Operanden können entsprechend des Beispiels Spezifikationen dienen, welche durch die Operationen AND, OR, ONEOF und NOT verknüpft
sind.
Spezifikationseinbeziehungen binden weitere Spezifikationen ein,
falls bestimmte Spezifikationen in der Variante bereits enthalten sind.
Dies können im Sinne des Beispiels vordefinierte Pakete sein. Denn
jede Spezifikation besitzt eine Eigenschaft package, wodurch sich Spezifikationen einem Paket zuordnen lassen.
2.3
3d-darstellung im web und auf mobilen geräten
Die Idee, dreidimensionale Inhalte in das Web zu bringen, ist nicht
neu. Schon Ende der neunziger Jahre wurde mit VRML97 eine Markupsprache entwickelt, auf deren Grundlage 3D-Inhalte im Browser
dargestellt werden können. Verschiedene Gründe führten jedoch dazu, dass ein räumliches Erlebnis im Web zunächst die Ausnahme
blieb. Allgemein geringe Rechenleistungen und fehlende Hardwareunterstützung für 3D-Darstellungen gehörten genauso dazu, wie
langsame Internetverbindungen und mangelnde Initiative auf Seiten
der Browserhersteller. Zur Anzeige von VRML im Web wurden spezielle Plugins benötigt.
19
20
grundlagen
In allen genannten Punkten wurden seitdem erhebliche Fortschritte
gemacht. Mehrkernprozessoren und dedizierte Grafikhardware, selbst
auf kleineren mobilen Geräten, sind mittlerweile die Regel und nicht
die Ausnahme. Breitbandige Internetverbindungen trugen in den letzten Jahren zur rasenden Verbreitung von Videoinhalten im Web bei.
Damit steht auch der Übertragung dreidimensionaler Inhalte kein
Übertragungsproblem im Wege.
Vor allem aktuelle Anstrengungen der Standardisierungsgremien
und Browserhersteller 3D-Darstellungen mit HTML 5 zu harmonisieren wecken Zuversicht, dass solche Anwendungen in Zukunft starke
Verbreitung finden (vgl. [Vö12, S. 111]). Im folgenden werden drei aktuelle 3D-Technologien im Bereich des Web und mobiler Plattformen
vorgestellt:
• WebGL [Weba]
• Unity3D [Uni]
• Stage 3D [Stab]
webgl Seit 2009 wird unter der Schirmherrschaft der Khronos Group
und Mozilla der offene Webstandard Web Graphics Library (WebGL)
entwickelt. Dadurch hält hardwarebeschleunigte 3D-Grafik Einzug
in den Browser. Technisch stellt WebGL eine JavaScript Bindung auf
OpenGL Embedded Systems (ES) 2.0 dar. Das heißt in einem Browser mit entsprechender Unterstützung des Standards können Grafikbefehle mithilfe von JavaScript direkt auf der Grafikkarte ausgeführt
werden.
Wie auch bei den beiden, im Folgenden vorgestellten Technologien,
wird bei dieser 3D-API ein prozeduraler Ansatz verfolgt. Damit ist gemeint, dass in Funktionen definiert wird, wie der Inhalt auf den Bildschirm gezeichnet wird. Deklarative Techniken wie X3DOM [X3D]
und XML3D [XML] setzen dagegen, ähnlich wie HTML, auf die Auszeichnung der Inhalte und beschreiben damit was dargestellt wird.
Ein wesentlicher Vorteil von WebGL besteht darin, dass kein Browser-Plugin zur Darstellung der 3D-Inhalte benötigt wird. Die Technologie ist direkt im Browsern implementiert.
Da die Grafikprogrammierung jedoch auf OpenGL basiert, was traditionell nicht zu den Kernkompetenzen eines Webentwicklers gehört, existieren Frameworks, mit denen auf höherer Ebene Applikationen geschrieben werden können. Zwei verbreitete Vertreter dieser
JavaScript Bibliotheken sind Three.js [Thr] und GLGE [GLG].
unity 3d Mit Unity3D bietet das US-Amerikanische Unternehmen Unity Technologies eine 3D-Engine an, die es ermöglicht für
eine Vielzahl von Plattformen zu entwickeln. Anwendungen können
neben dem Webbrowser auch für mobile Geräte auf Basis von Android oder iOS entwickelt werden. Zur Ausführung im Browser wird die
2.3 3d-darstellung im web und auf mobilen geräten
Installation eines Plugins vorausgesetzt, die sich beim Aufruf einer
3D-Webapplikation allerdings schnell und unkompliziert durchführen lässt.
Auch die Erstellung klassischer Desktopanwendungen für WindowsBetriebssysteme und Mac OS X sind möglich. Eine komfortable grafische Entwicklungsumgebung bietet Unterstützung bei der Erstellung
der Programme. Zur Programmierung dienen die Skriptsprachen JavaScript, Boo und C#.
Für diese Technologie sprechen die umfangreichen Funktionen vorhandener Bibliotheken, die gute Integration weiterer 3D-Werkzeuge in den Entwicklungsprozess sowie die grafische Unterstützung
bei der Entwicklung. Darüber hinaus ist es für das Erreichen einer
breiten Zielgruppe sehr nützlich, einmal entwickelte Anwendung für
mehrere Softwareplattformen exportieren zu können.
stage 3d Mit Stage 3D (ehemals Molehill) steht seit Ende 2011
nun auch für die Flash-Plattform hardwarebeschleunigte 3D-Grafik
bereit. Technisch stellt es eine API für die Skriptsprache ActionScript
3.0 dar, die wiederum unter Windows auf die Grafikbibliothek DirectX
9 zugreift und unter Mac OS X und Linux auf OpenGL 1.3. Aufgrund
der hohen Verbreitung des Flash-Plugins in Browsern stellt es eine
Alternative zu den beiden vorher genannten Techniken dar. Im April
2012 verfügten über 95% der Nutzer im Web über das Flash Plugin.
Bereits 64% hatten die, zu dem Zeitpunkt, aktuelle Version 11 installiert und damit 3D-Unterstützung [Staa].
21
3
V E R WA N D T E A R B E I T E N
Im Folgenden werden Arbeiten vorgestellt, die sich mit dem Austausch von Produktmodellen, deren Verarbeitung sowie deren Visualisierung befassen. Vor allem neuere Forschungen im Bereich der virtuellen Produktentwicklung sind für die vorliegende Arbeit relevant.
Die Handhabung und Darstellung der Entwicklungsstände beinhaltet ähnliche Aufgaben wie die spätere Verarbeitung und Präsentation
finaler Produktmodelle.
Durch die im Kapitel 1 bereits angesprochenen Folgen der Globalisierung, ergeben sich für die herstellende Industrie neue Entwicklungsprozesse. Unternehmen trennen sich aktuell zunehmend von
der Strategie, die Produktentwicklung vollständig selbst durchzuführen. Es kommt mehr und mehr zu einer Fokussierung auf Kernkompetenzen und die Auslagerung von Aktivitäten an Partnerunternehmen [KMH10, S. 1].
Bei dieser Teilung von Aufgaben spricht man von kollaborativer
Produktentwicklung. Häufig sind die Teilnehmer dieser Kollaborationen über den Globus verteilt. Daraus folgen spezielle Anforderungen
an den Austausch der Produktdaten und der Bedarf einer möglichst
direkten Kommunikation am Modell.
Ein Problemfeld der kollaborativen Produktentwicklung – auch kollaboratives Design genannt – ist die Thematik der verteilten Visualisierung. Dabei wird im Wesentlichen die Darstellung von Inhalten
in einem verteilten System verstanden. Diese ist nicht auf den Einsatz im Bereich der Produktentwicklung beschränkt. Gegenstand der
Visualisierung können ebenso wissenschaftliche Daten sein.
3.1
datenformate für den austausch und die visualisierung von produkten
Für die Repräsentation von Produktmodellen mit samt der Geometrie
existieren eine Reihe von Datenformaten, die jeweils für bestimmte Anwendungsfälle unterschiedlich geeignet sind. Besonders interessant sind auf der einen Seite Formate für einen möglichst vollständigen Austausch der Produktmodelle und auf der anderen Seite leichtgewichtige Formate für die Darstellung und die Übertragung im Internet. Mehrere Untersuchungen widmeten sich in dieser Hinsicht
der Gegenüberstellung verbreiteter 3D-Formate im Engineering-Umfeld [Fro11] [BFS10] [DBM+ 07].
BECKERS et al. untersuchten Anwendungsgebiete und geeignete Formate für die 3D-Visualisierung im Bereich des Engineering
23
24
verwandte arbeiten
[BFS10]. Sie sehen mögliche Einsatzgebiete vor allem in denen der
Konstruktion nachgelagerten Phasen. Dazu gehören etwa Vertrieb,
Marketing und Kundendienst. Aktuelle Anwendungsszenarien seien,
neben jenen der Produktentwicklung, die High-End Visualisierung.
Für den Einsatz im Rahmen der genannten Szenarien schlagen
BECKERS et al. ein neutrales leichtgewichtiges Visualisierungsformat
vor. Wichtig sei weiterhin dessen Standardisierung, um die Anzahl
der eingesetzten Formate in der Praxis im Interesse der Nutzer einzuschränken. Dabei wird JT als vielversprechendes Format zur Lösung
dieser Aufgaben hervorgehoben. Dieses stellt ein besonders leichtgewichtiges Format mit Möglichkeiten der Kompression und unterschiedlich detailreichen 3D-Modellen dar, um eine zügige Übertragung und verschiedene Level-of-Detail zu realisieren.
JT ist sowohl in der Lage, tesselierte Geometrien zu speichern, als
auch exakte Produktrepräsentationen, wie sie für Aufgaben der Entwicklung benötigt werden. Besonders interessant ist das Format durch
die Option Material-, Farb- und Texturinformationen speichern zu
können. Materialinformationen – insbesondere Texturen – sind bei
Austauschformaten im Kontext der herstellenden Industrie die Ausnahme, zur hochwertigen Darstellung von Produkten jedoch oft unverzichtbar.
BECKERS et al. stellen in ihrer Arbeit Untersuchungen zur Praxistauglichkeit des Formates im Hinblick auf die Unterstützung durch
die Hersteller von branchenüblicher Software an. Dazu wurden die
im Automobilbau verbreiteten CAD-Anwendungen CATIA V5 [Cat],
Pro/ENGINEER [Proa] und NX [NX] auf deren Qualität in Bezug auf
die Unterstützung von JT betrachtet. Gemeint sind damit die Fähigkeiten, das Format einlesen und auf die innere Datenstruktur abbilden
zu können, wie auch die umgekehrte Prozedur in Form des Exports
der Produktdaten.
Dieser Praxistest zeige eine größtenteils korrekte Verarbeitung der
Geometrie, aber nur in wenigen Fällen den richtigen Umgang mit
Farbwerten (RGB). Eine Konvertierung von Texturen konnte bei den
getesteten Softwarepaketen jedoch nicht nachvollzogen werden.
Das Resümee der Arbeit liegt darin, JT zum Zeitpunkt der Untersuchung nicht für den produktiven Einsatz zu empfehlen [BFS10, S. 339].
Der Stand sei jedoch ermutigend und lässt darauf schließen, dass in
absehbarer Zeit eine ähnlich umfangreiche Unterstützung und Robustheit der Implementierungen, wie auch bei STEP erwartet werden
kann [BFS10, S. 342].
In einer weiteren Studie wurde die Eignung ausgewählter 3D-Formate für den Einsatz in häufig auftretenden Anwendungsszenarien im Engineering-Umfeld untersucht [Fro11]. Die Ergebnisse sollen
einen Überblick und eine Orientierungshilfe zur Identifizierung des
3.1 datenformate für den austausch und die visualisierung von produkten
Legende
Sehr gut geeignet
Gut geeignet
Geeignet mit Einschränkungen
Szenario
STEP
3D XML
JT
3D PDF
Viewing
Datenaustausch
DMU
Dokumentation
und Archivierung
Portable PLM
Document
Abbildung 4: 3D-Formate im Engineering-Umfeld, nach [Fro11, S. 4]
passenden 3D-Formats für bestimmte Aufgaben geben. Identifiziert
wurden dabei folgende Szenarien.
1. Visualisierung von Engineering-Daten
2. Datenaustausch
3. Digital Mock-Up
4. Dokumentation und Archivierung
5. Verwendung von 3D-Informationen in Bereichen mit Engineering-Bezug
Relevant für die vorliegende Arbeit sind im besonderen die Ergebnisse bezüglich der ersten drei Anwendungsfälle. Abbildung 4 stellt
zusammenfassend die Resultate der Untersuchung dar.
Für das erste Szenario stellt sich die Frage nach dem besten Format für die Darstellung in 3D-Viewern und die realitätsnahe Abbildung in VR-Systemen. Für diesen Anwendungsfall wurden die Performanz der Darstellung, sowie die Möglichkeit der Abbildung von
Metadaten berücksichtigt. Weitere Anforderungen für die Visualisierung sieht FROEHLICH in einer quellsystemunabhängigen Darstellung, einer Filterung durch verschiedene Sichten oder Ebenen und in
der Unterstützung von Texturen und Lichtquellen für die Darstellung
in VR-Systemen.
Die Studie kommt zu dem Schluss, dass sich für den Anwendungsfall der Visualisierung von Engineering-Daten JT und 3D-PDF am besten eignen würden. Die Stärken von JT seien in diesem Zusammenhang die Fokussierung auf eine leichtgewichtige Repräsentation der
Visualisierung
25
26
Datenaustausch
Digital Mock-Up
verwandte arbeiten
Modelle in Form von tesselierter Geometrie. Darüber hinaus sei die
Verfügbarkeit von kostenfreien 3D-Viewern ein Grund für die Bewertung [Fro11, S. 19].
Für das Szenario des Datenaustausches wurden die 3D-Formate
auf deren Potenzial hin untersucht, die Geometrie möglichst exakt
und die Produktstruktur möglichst vollständig repräsentieren zu können. Für den Austausch von Daten im Engineering-Umfeld ist neben
der Übertragung der Geometrie auch die Übertragung von textbasierten Produktbeschreibungen und von 3D-Annotationen gefordert.
Gefordert ist für diesen Anwendungsfall weiterhin, dass der Datenaustausch in einer Form erfolgt, welche die Nachbearbeitung der Produktmodelle begünstigt.
FROEHLICH empfiehlt für den Datenaustausch, mit den soeben
beschriebenen Anforderungen, die Nutzung von STEP. Es sei prädestiniert für dieses Szenario, da es eine ausgereifte internationale Norm
darstellt und eine Vielzahl von Anwendungen dieses Format unterstützen. Darüber hinaus wird angeführt, dass der Einsatz von STEP
zum Datenaustausch bereits gängige Praxis in den Branchen Automobil- und Maschinenbau, sowie in der Luft- und Raumfahrt sei.
Für den Austausch reiner Geometriedaten würde sich darüber hinaus auch JT eignen. Dieses Format habe allerdings noch keinen so
hohen Reifegrad wie STEP erlangt [Fro11, S. 19].
Das dritte durch FROEHLICH betrachtete Szenario befasst sich mit
der Prüfung von mechanischen Zusammenhängen von Produkten anhand computergestützter Versuchsmodelle. Für diese Prüfung werden neben der Geometrie auch Metainformationen und die Produktstruktur benötigt. Für Simulationen wie die Kollisionsprüfung sind
Hüllgeometrien des Produktes in tesselierter Form erforderlich.
Wie Abbildung 4 erkennen lässt, legen die Ergebnisse der Arbeit
den Einsatz des JT-Formates für das Digital Mock-Up nahe. Dieses
sei aufgrund der leichtgewichtigen facettierten (tesselierten) Geometrieformen besonders für diesen Anwendungsfall geeignet. Es wird
jedoch angemerkt, dass JT Einschränkungen in der Repräsentation
von Kinematiken habe [Fro11, S. 20].
Die Studie stellt fest, dass trotz der generellen Empfehlungen der
3D-Formate für bestimmte Szenarien eine Gewichtung der Eigenschaften für den konkreten Anwendungsfall in einem Unternehmen erforderlich ist [Fro11, S. 6].
Für den in dieser Arbeit fokussierten Anwendungsfall einer 3DAnwendung für Vertriebszwecke lassen sich aus dieser Arbeit wichtige Hinweise auf das zu verwendende Datenformat entnehmen. Der
in der vorliegenden Arbeit fokussierte Anwendungsfall vereint Anforderungen der von FROEHLICH betrachteten Szenarien Viewing
und Datenaustausch. Unterschiede bestehen jedoch darin, dass die
hier angestrebte 3D-Anwendung zur Vertriebsunterstützung über eine bloße Betrachtung der Geometrie hinaus geht. Ein 3D-Viewer mit
3.2 serviceorientierte ansätze im kollaborativen produktdesign
vorgefertigtem festen Funktionsumfang ist daher ungeeignet für die
Darstellung der Produkte.
Bezogen auf den Datenaustausch stellt der Anwendungsfall dieser Arbeit ebenfalls die Anforderung ein Produkt möglichst vollständig beschreiben zu können, verzichtet jedoch auf die Möglichkeit
der Nachbearbeitung von Produktmodellen. Aufgrund der Ergebnisse von FROEHLICH wurden STEP und JT als besonders interessante
Formate für die in dieser Arbeit zu lösenden Aufgabe identifiziert. JT
ist jedoch kaum in der Lage, Informationen zu Produkten über die
Geometrie hinaus zu repräsentieren. Ein weiteres Manko ist die, im
Vergleich zu STEP, noch nicht so starke Verbreitung in der Industrie
und das Vorhandensein nur eines SDKs (JT Open Toolkit) zur Entwicklung von Anwendungen mit JT-Unterstützung in der für Webanwendungen unvorteilhaften Programmiersprache C++.
3.2
serviceorientierte ansätze im kollaborativen produktdesign
Neben dem Format für den Datenaustausch spielt auch die Methode eine entscheidende Rolle. Dies gilt sowohl für das in dieser Arbeit
angestrebte Szenario der Aufbereitung von Produktmodellen zur Darstellung in vertriebsorientierten 3D-Anwendungen, als auch für das
in der herstellenden Industrie aktuelle Thema der kollaborativen Produktentwicklung.
Im Bereich der verteilten Systeme nimmt in diesem Zusammenhang das Konzept der serviceorientierten Architekturen (SOA) einen
hohen Stellenwert ein. Eine Reihe von Arbeiten befasste sich mit der
Anwendung dieses Konzeptes auf Problemstellungen des kollaborativen Designs [KMH10] [SLV08] [YTD06] [CLG06].
KIM et al. entwickelten ein Framework zum Teilen von CAD-Daten auf Basis von Webservices. Firmen soll damit eine Integration von
IT-Systemen für die temporäre Zusammenarbeit während der Produktentwicklung ermöglicht werden. Mit Hilfe von standardisierten
Schnittstellen, Datenformaten und Protokollen kann eine lose Kopplung solcher Systeme für den Datenaustausch realisiert werden. Damit werden Daten zwischen Softwaresystemen geteilt und nicht mehr
im herkömmlichen Sinne durch Import und Export von Dateien ausgetauscht.
Tabelle 3 stellt die Unterschiede zwischen dem Austausch und dem
Teilen von Daten am Beispiel von CAD-Daten gegenüber.
Das Ziel eines serviceorientierten Ansatzes ist es, die Abhängigkeiten zwischen den beteiligten Systemen zu minimieren. Die Änderung
einer Komponente beeinflusst andere Komponenten in einer serviceorientierten Architektur nur minimal. Webservices setzen das Konzept der SOA nach Auffassung von KIM et al. am besten um und lösen die Probleme ähnlicher Kommunikationstechnologien wie COR-
27
28
verwandte arbeiten
austausch von cad-daten
teilen von cad-daten
Veranlasst durch Urheber
Veranlasst durch Empfänger
Konvertierung in neutrales
Nutzung einer API des
Format
Urhebers
Daten bestimmt durch festen
Daten auf Anfrage in Echtzeit
Zeitpunkt
Erzeugung einer Kopie
Einheitlicher Datenbestand
Tabelle 3: Gegenüberstellung der Konzepte des Austauschs und des Teilens
von CAD-Daten (vgl. [KMH10, S. 3])
BA, JavaRMI oder DCOM. Dazu gehören beispielsweise die Plattformabhängigkeit und Schwierigkeiten beim Passieren von Firewalls
[KMH10, S. 4].
Das von KIM et al. entwickelte Softwaresystem zum Austausch
von Konstruktionsdaten stützt sich auf eine mehrschichtige Architektur zur Abstraktion der jeweils darunter liegenden Schicht. Die drei
Schichten sind folgende [KMH10, S. 7].
• Web Service Layer
• CAD Adaptor Layer
• CAD System Layer
Die erste Schicht stellt die Schnittstelle nach außen dar und bietet entsprechend dem SOAP-Protokoll für Webservices eine Beschreibung der verfügbaren Dienste in Form einer WSDL an. Auf Anfrage
durch einen Client liefert der Dienst ein auf XML basierendes, durch
die Autoren der Arbeit selbst definiertes, Datenformat mit den entsprechenden Konstruktionsdaten.
Der CAD Adapter als zweite Schicht dient der Abstraktion der darunter liegenden CAD-Systeme. Durch seine neutrale API stellt er eine
Überbrückung der high-level Webservice Schicht und der low-level
CAD-System Schicht dar. Damit ist ein Tausch des CAD-Systems mit
nur minimalen Anpassungen verbunden.
Die unterste Schicht stellt die API der Konstruktionssoftware dar,
welche durch deren Hersteller vorgegeben ist.
KIM et al. führen weiterhin an, dass sie datenzentrierte Schnittstellen statt methodenzentrierten Schnittstellen für ihre Architektur einsetzen. Diese seien simpler und ermöglichten die Übertragung größerer Datenmengen pro Transaktion. Potenzielle Schwächen sehen die
Autoren der genannten Arbeit in der offenen Natur von Webservices.
In dieser Hinsicht seien Anforderungen an Sicherheit, Autorisierung
und Authentifizierung zu berücksichtigen [KMH10, S. 6].
3.3 entwicklungen im bereich verteilter visualisierungen
Bezogen auf die Aufgabenstellung der vorliegenden Arbeit dienen
die Erkenntnisse von KIM et al. der Konzipierung der Schnittstellen und Komponenten einer Softwarearchitektur zur Aufbereitung
von Produktdaten. Besonders hervorzuheben sind dabei die Eigenschaften der Serviceorientierung, welche eine lose Kopplung von Systemkomponenten ermöglicht, die mehrschichtige Architektur zur Abstraktion darunter liegender Ebenen sowie die Datenzentriertheit des
vorgestellten Konzeptes.
Zur Anwendung der Erkenntnisse der eben diskutierten Arbeit
auf die vorliegende Aufgabenstellung unterliegt jedoch Einschränkungen. KIM et al. fokussierten ihre Arbeit auf den Austausch von
CAD-Daten. Es wurden weder weitergehende Produktinformationen
im Sinne von Metainformationen in die Überlegungen einbezogen,
noch spielt die Aufbereitung der Daten eine Rolle. Es lassen sich lediglich die Informationen nach außen bereitstellen, die das CAD-System auf unterster Ebene durch seine API anbietet. Darüber hinaus
stellt die Nutzung eines eigenen XML-Formates eine Einschränkung
in der Interoperabilität mit anderen Anwendungen dar.
3.3
aktuelle entwicklungen im bereich der verteilten
visualisierung
In den letzten Jahren führten ein Reihe von Entwicklungen in der
Informationstechnik zu neuen Lösungen und Geschäftsmodellen. An
dieser Stelle sollen dies betreffend wichtige Technologien und Paradigmen vorgestellt und Lösungen im Bereich der kollaborativen Visualisierung angesprochen werden, die davon profitieren.
MOUTON et al. führten in diesem Zusammenhang eine Untersuchung aktueller Trends im Bereich der verteilten Visualisierung durch
[MSG11]. Die folgenden Ausführungen stützen sich auf die Erkenntnisse dieser Arbeit, beschränken sich jedoch nicht darauf.
entwicklungen Eine prägende Technologie in jüngster Zeit ist
das cloud computing. Durch eine Abstraktion der zugrunde liegenden Hardware von IT-Infrastrukturen können Rechenleistung und
Dienste dynamisch an den Bedarf angepasst werden. Dabei spielt
im Besonderen der Einsatz virtueller Maschinen eine Rolle. Diese
sind auf mehreren physischen Rechnern verteilt und vereinnahmen
je nach Bedarf mehr oder weniger Ressourcen.
Darauf aufbauende Geschäftsmodelle ermöglichen die flexible Nutzung von Infrastrukturen und damit verbunden die Abrechnung im
Sinne des »pay-per-use« ohne größere Vorabinvestitionen [MSG11, S.
105].
Ein weiterer relevanter Trend ist die Veränderung des Formfaktors von Computern hin zu kleineren mobilen Geräten. Wichtig ist
in diesem Zusammenhang, dass sich der Gebrauch von Mobilgerä-
29
30
verwandte arbeiten
ten längst nicht nur auf Multimediaanwendungen im Freizeitbereich
beschränkt.
Beim Einsatz privat erworbener Geräte in Unternehmen durch die
Mitarbeiter spricht man vom Trend des »bring-your-own-device«. Da
von den Mitarbeitern oft hohe Flexibilität erwartet wird, setzten diese zunehmend auf den Einsatz von Smartphones und Tablets als Produktivwerkzeuge [Goo12, S. 3]. Hinzu kommt, dass die Leistungsfähigkeit dieser Geräteklasse im Laufe weniger Jahre deutlich gestiegen
ist. Seit dem Frühjahr 2012 sind Quad-Core Prozessoren für Smartphones auf dem Markt, eine Technologie, die bis vor kurzem noch
PC-Workstations vorbehalten war (vgl. [Hei]). Dies, zusammen mit
den hohen Bandbreiten der Mobilfunknetze, führt zur Situation, dass
für die Visualisierung im Privaten, wie auch im Unternehmensumfeld, zunehmend kleinere mobile Geräte attraktiv werden.
Durch die hohe Bandbreite der Netze und die hardwarebeschleunigte Video-Dekodierung lassen sich hochauflösende Videoströme auf
mobile Geräte übertragen und abspielen.
Diese Form des Streamings im Bereich interaktiver 3D-Grafikanwendungen zeigt der gaming-on-demand Anbieter OnLive [OnL]. Dessen Lösung erlaubt es, auf mobilen Geräten Videospiele mit den höchsten Anforderungen an Rechenleistung spielen zu können. Ermöglicht
wird dies durch die Ausführung der Anwendung auf einem Server
des Anbieters, in Verbindung mit dem Streaming eines speziell komprimierten Videoformates auf den mobilen Client. Vom Client zum
Server werden lediglich Nutzereingaben übertragen. Diese Idee löst
sich vom klassischen Konzept, eine 3D-Anwendung nur auf dem Gerät ausführen zu können, auf dem sie installiert ist.
Diesem Ansatz des Renderns der 3D-Szenen auf dem Server mit
anschließender Übertagung als Videostream, steht das Konzept des
clientseitigen Renderns gegenüber. Dabei wird der Szenengraph auf
das Gerät übertragen und das Bild lokal berechnet.
In diesem Zusammenhang gibt es aktuelle Anstrengungen des Web3D Konsortiums, eine Methode zur binären Kompression des X3DFormates zu standardisieren. In komprimierter Form soll dieses Format, genannt X3D-binary, nur etwa 10% des Datenvolumens der herkömmlich textkodierten Variante ausmachen. Damit eignet es sich
besonders zur Übertragung von 3D-Inhalten im Kontext des Internet. Seit 2011 liegt die zweite Version des Standards mit dem Status
»final-draft« vor, der letzten Stufe vor der Veröffentlichung als internationaler Standard [Webb].
Weitere relevante Entwicklungen betreffen das Web und im Besonderen die Standardisierung im Umfeld von HTML 5. Spätestens mit
dem Aufkommen von Ajax, als Konzept der asynchronen Kommunikation im Web, begann eine Migration von klassischen Desktopanwendungen in das Web.
3.3 entwicklungen im bereich verteilter visualisierungen
Der aktuelle Prozess der Spezifizierung der WebSocket API durch
das W3C geht noch einen Schritt weiter und ermöglicht eine bidirektionale asynchrone Kommunikation im Vollduplex Übertragungsmodus [W3C]. Vollduplex meint dabei, dass zeitgleich mit maximaler
Geschwindigkeit sowohl gesendet als auch empfangen werden kann.
Auch die File API und die Unterstützung von Videos in HTML 5
werden komplexere Webanwendungen ermöglichen, ohne auf ein Browser-Plugin angewiesen zu sein.
Vor allem aber wird WebGL die Implementierung von Anwendungen zur verteilten und kollaborativen Visualisierung im Web vorantreiben. Erst dadurch werden ohne Plugins dreidimensionale Inhalte hardwarebeschleunigt im Browser dargestellt. Unter der Schirmherrschaft der Khronos Group entwickelt, bietet WebGL die Möglichkeit, mittels JavaScript 3D-Objekte auf die Leinwand (»canvas«) von
HTML 5 zu zeichnen.
anwendung der entwicklungen Eine Anwendung der genannten Technologien liegt in der kollaborativen Visualisierung wissenschaftlicher Inhalte. Im Rahmen des COLLAVIZ (Remote Collaborative Visualizer) Projektes [COL] wurde ein Framework zur Durchführung von numerischen Simulationen von mechanischen Komponenten entwickelt.
Teil des Projektes ist eine webbasierte Komponente zur Steuerung
und Darstellung der Simulationsergebnisse [NKB10]. Unter Verwendung von HTML 5, Ajax und WebGL können in einer nativen Webanwendung Parameter für die Simulation eingestellt und nach der
Durchführung die Ergebnisse betrachtet und Nachjustierungen vorgenommen werden. Durch diese Lösung werden Dienste des High
Performance Computing HPC vom Web aus nutzbar.
Durch die Nutzung von standardisierten Webtechnologien ist eine
Nutzung dieser Lösung mit mobilen Geräten möglich. NIEBLING et
al. stellen im dem Zusammengang fest, dass die Grafikleistung moderner Mobilgeräte ausreichend ist, um auch große Polygonanzahlen in hoher Frequenz zu rendern. Sie sehen jedoch beim Parsen der
3D-Daten nach der Übertragung vom Server zum Client einen potenziellen Flaschenhals. Beim Einlesen der Geometrie mittels JavaScript
sehen sie, trotz der in letzter Zeit deutlich schneller gewordenen JavaScript-Browserengines, Optimierungsbedarf [NKB10, S. 107].
Eine weitere Arbeit im Rahmen der kollaborativen wissenschaftlichen Visualisierung nimmt sich der eben besprochenen Performanzprobleme beim Übertragen und Parsen von 3D-Inhalten an. MAGLO
et al. entwickelten – ebenfalls im Rahmen des angesprochenen COLLAVIZ Projektes – ein Framework zum progressiven Streaming von
binären X3D Daten [MLL+ 10]. Damit lässt sich ein 3D-Modell in verschiedenen Detailgraden (LOD) übertragen und nach und nach verfeinern. Der Einsatz des 3D-Streamings für webbasierte Anwendungen
31
32
verwandte arbeiten
im Kontext des kollaborativen Designs wird auch durch FUH und LI
[FL05, S. 573-576] anschaulich vorgestellt.
Eine weitere Software zur Visualisierung wissenschaftlicher Inhalte
wurde von CALLIERI et al. implementiert. Auf Basis von WebGL und
der JavaScript Bibliothek SpiderGL [Ben] lassen sich durch ihre Lösung Erkenntnisse der Molekularbiologie interaktiv im Web darstellen. Die Autoren der Studie stellen unter anderem fest, dass sich mit
3D-Webtechnologien im Anwendungsfall der Darstellung von Proteinen ein ähnlich ansprechender visueller Stil im Vergleich zur vorgerenderten Videos, erzeugt durch die Software Blender [Ble], erreichen
lässt [CADB+ 10, S. 122].
3.4
zusammenfassung
Es wurden Arbeiten vorgestellt, die einen Beitrag im Feld der verteilten Visualisierung leisten. BECKERS et al. untersuchten die Eignung verschiedener 3D-Formate im Umfeld des kollaborativen Designs [BFS10]. Die Ergebnisse zeigen, dass es derzeit kein Format
gibt, dass uneingeschränkt für unterschiedliche Anwendungsfälle zu
empfehlen ist. Für die in der vorliegenden Arbeit besonders relevanten Anwendungsszenarien des Datenaustausches und des Betrachtens dreidimensionaler Produktmodelle zeigten sich die Standards
STEP, sowie JT als besonders geeignet. Das weiterhin vorgeschlagene
Format 3D PDF soll für diese Arbeit als Datencontainer aufgrund
mangelnder Unterstützung der Interaktivität sowie der Integration
in eigene Anwendungen nicht weiter betrachtet werden.
In Bezug auf aktuelle Architekturkonzepte verteilter Visualisierungssysteme zeigen sich in mehreren Arbeiten die Vorteile offener serviceorientierter Ansätze [KMH10][NKB10]. WebServices erweisen sich als
besonders geeignet für die Kommunikation zwischen Softwareanwendungen oder -komponenten im Problemfeld der Aufbereitung und
Darstellung von Produktmodellen (vgl. [YTD06], [CLG06]). Durch
den Datenaustausch per HTTP gibt es damit vor allem in Unternehmensnetzwerken keine Probleme durch Firewallbeschränkungen.
In den verwandten Arbeiten mit dem Schwerpunkt der Verarbeitung und Bereitstellung mechatronischer Produktmodelle zeigte sich
weiterhin mehrmals der Einsatz des Client/Server Konzeptes in der
Form Storage-Server-Client. Dabei kamen auf der Serverseite in der
Regel mehrere Schichten zur Abstraktion verschiedener Softwareebenen zur Anwendung (vgl. [KMH10], [SPSS08], [CCW06], [ZSG04]).
MOUTON et al. beschreiben im Bereich der verteilten Visualisierung mehrere Trends, besonders in Bezug auf Hardwareplattformen
und Browserentwicklungen. Sie sehen im mobilen Zugriff auf highend Visualisierungen durch den Einsatz von cloud computing und
aktuelle Web-3D Technologien wie WebGL großes Potenzial. Weiterhin
schlagen sie die Entwicklung eines Systems zum hybriden Client/Ser-
3.4 zusammenfassung
ver Rendering vor. Durch Kombination des Streamings gerenderter
Bilder und der Übertragung des Szenengraphen würden sich lokale
Ressourcen der Clients optimal nutzen lassen [MSG11, S. 107].
33
4
KONZEPTION
4.1
analyse des problems
Um für die Problemstellung dieser Arbeit in strukturierter Weise eine zielorientierte Lösung erarbeiten zu können, ist ein hinreichendes
Verständnis für das Problem von Nöten. Dabei ist die Problematik der
Produktmodellverarbeitung nicht losgelöst vom umgebenden Kontext zu betrachten.
Dies bedeutet, den Sachverhalt nicht nur aus rein technischer Sicht
zu betrachten, sondern betriebswirtschaftliche Prozesse und den Menschen als Teil der Lösung zu verstehen. Es stellen sich beispielsweise
die Fragen, welche Interessengruppen in die Thematik involviert sind
und wie deren Ziele und Anforderungen in Bezug auf eine Lösung
aussehen.
4.1.1
Interessengruppen
Grundsätzlich lassen sich drei Parteien erkennen, die es für die Lösungsfindung zu berücksichtigen gilt. Dies sind der Hersteller der
mechatronischen Erzeugnisse, der Entwickler einer Softwarelösung
zur Vermarktung dieser Produkte sowie der Endkunde im Sinne des
Nutzers der Visualisierungsanwendung.
Abbildung 5 beschreibt schematisch die Situation und zeigt die
genannten Interessengruppen. Die Pfeile weisen auf den Pfad der
Produktdaten im Prozess der Entwicklung einer 3D-Vertriebsanwendung hin. Der Hersteller hält ein digitales Produktmodell vor, dessen Informationen am Ende dem Kunden in verständlicher Form zugänglich gemacht werden sollen. In der Regel wird das herstellende
Unternehmen jedoch auf die Expertise eines Spezialisten für die Entwicklung von Anwendungen zu Vertriebszwecken angewiesen sein.
Der Rolle des Entwicklers kommen dabei im Wesentlichen die Aufgaben der Aufbereitung der produktbeschreibenden Daten sowie die
Erstellung der Softwareanwendung zur Präsentation dieser Daten zu.
In den vorangegangenen Kapitel ist bereits die Situation beim Hersteller näher beschrieben worden. Der Abschnitt 2.1 verdeutlicht mit
dem Lebenszyklus von Produkten bereits wesentliche Prozesse in den
betreffenden Unternehmen. Darüber hinaus wurden die Inhalte der
verwalteten Produktinformationen vorgestellt.
Im Folgenden liegt der Fokus daher auf den Interessengruppen Entwickler und Endkunde. Es wird zu klären sein, welche Anforderungen die beteiligten Gruppen in diesem Kontext an eine Lösung stellen.
35
HERSTELLER
Produktmodell
ENTWICKLER
Datenaufbereitung
Anwendungslogik
ENDKUNDE
3D-Anwendung
Abbildung 5: Die
Interessengruppen
36
konzeption
Wichtig ist in diesem Zusammenhang, dass sowohl Anforderungen
an den Prozess der Datenverarbeitung und der Anwendungsentwicklung bestehen, als auch an die resultierende Anwendung selbst. Zum
Teil sind die Anforderungen an die Lösung jedoch nicht direkt auf
Ansprüche der Interessengruppen zurückzuführen, sondern auch abhängig von bestimmten Rahmenbedingungen. Diese sollen zunächst
identifiziert werden.
4.1.2
Fähigkeiten
Hardware
Software
Rahmenbedingungen
Die folgenden Rahmenbedingungen beziehen sich auf die resultierende 3D-Anwendung und können als Voraussetzungen seitens der
Nutzer zur Ausführung dieser Applikation verstanden werden.
Die Voraussetzungen zur Bedienung der Anwendung lassen sich
als nicht-technische Rahmenbedingungen beschreiben. Sie beziehen
sich in erster Linie auf die Fähigkeiten der Benutzer. Im Kontext von
3D-Vertriebsanwendungen kann man nicht davon ausgehen, dass die
Nutzer über weitreichende Kenntnisse im Umgang mit komplexen
3D-Softwarewerkzeugen verfügen, wie sie üblicherweise bei der Konstruktion von Maschinen genutzt werden. In der Regel verfügen die
Endkunden jedoch über Kenntnisse im Umgang mit Webanwendungen. Darüber hinaus hat der Kunde eine bestimmte Sicht auf ein Produkt. Diese deckt sich nicht zwingend mir der Sicht, die der Hersteller auf sein Produkt hat. Man kann in dem Zusammenhang auch von
verschiedenen mentalen Modellen eines Produktes sprechen.
Als Voraussetzungen zur Ausführung der Anwendung sind technische Rahmenbedingungen zu betrachten. Diese betreffen sowohl die
Hard-, als auch die Software der genutzten Geräte. Da die Zielgruppe der 3D-Anwendung die potentiellen Käufer der mechatronischen
Produkte sind und nicht etwa Vertriebsmitarbeiter des herstellenden
Unternehmens, ist mit einer heterogenen Rechnerlandschaft auf Seiten der Nutzer zu rechnen. Es ist nicht der Fall, dass sich Unternehmensrichtlinien definieren lassen, welche die verwendete Hardund Software zur Ausführung der Anwendung vorschreiben. Somit
kann von unterschiedlichen Rechnertypen wie Desktop-PCs oder mobilen Geräten, etwa Notebooks, ausgegangen werden. Dies bedingt
beispielsweise variierende Leistungsmerkmale und unterschiedliche
Eingabemöglichkeiten der Geräte.
Ähnliches gilt in Bezug auf die verwendete Software. Dies betrifft
vor allem das Betriebssystem im Hinblick auf native Anwendungen,
sowie den verwendeten Browser hinsichtlich Webanwendungen. Jeweils sind verschiedene Ausstattungen zu berücksichtigen.
4.1 analyse des problems
3d-anwendung
datenaufbereitung
– Webtauglichkeit
– Skalierbarkeit
– Darstellungsrealismus
– Assoziationswahrung
– Aktualität
– Schnittstellenneutralität
– Unverfälschtheit
Tabelle 4: Anforderungen an die 3D-Anwendung und den Prozess der Produktdatenaufbereitung
4.1.3
Anforderungen
Die angesprochenen Rahmenbedingungen führen zu Anforderungen,
die zum einen die 3D-Applikation betreffen und zum anderen den
Prozess der Datenaufbereitung zur Nutzung von Produktmodellen
für diese Anwendung. Dabei beeinflussen Anforderungen an die 3DAnwendung häufig auch die vorangehende Datenverarbeitung.
webtauglichkeit Die Anforderung der Webtauglichkeit bezieht
sich primär auf die 3D-Anwendung. Um einen möglichst großen Kundenkreis zu erreichen, ist es unabdingbar, dass eine Webanwendung
in allen gängigen Browsern ausführbar ist. Darüber hinaus ist es von
Vorteil, wenn dazu keine Installation eines Browser-Plugins vorausgesetzt wird.
Im Kontext von Webanwendungen muss beim Nutzer mit unterschiedlichen, teils geringen, Bandbreiten gerechnet werden. Dieses
Problem wird durch die mitunter komplexen Produkte mit hohen
Datenvolumen verschärft, die es zu übertragen und darzustellen gilt.
Aus dieser Situation ergibt sich die Anforderung, Teile von Produktmodellen auf Anfrage nachladen zu können. Die Ladezeiten wären
nicht vertretbar, sollten Produktreihen vor dem Starten der Anwendung erst vollständig geladen werden müssen. Nach Möglichkeit sind
nur jene Daten zu übertragen, die für den Nutzer zum entsprechenden Zeitpunkt von Interesse sind.
Für die Datenverarbeitung bedeutet die Anforderung der Webtauglichkeit somit die Bereitstellung der Produktdaten in nicht-monolithischen, im Web üblichen, Formaten.
darstellungsrealismus Der Darstellungsrealismus als Anforderung an die 3D-Anwendung bezieht sich auf die optische Qualität
in der Abbildung von Oberflächen. Für die Darstellung mechatronischer Produkte ist deren visuelle Anmutung in der Regel von großer
Bedeutung. Generell soll die Hochwertigkeit dieser Produkte vermittelt werden. Bei vielen Darstellungen ist daher Fotorealismus angestrebt.
37
38
konzeption
aktualität Für eine Vertriebsanwendung ist die Aktualität der
Daten von hoher Bedeutung. Unwahrscheinlich ist eine Änderung
der grundlegenden produktdefinierenden Daten, wie die Form oder
physikalische Eigenschaften. Für kommerzielle Informationen, zum
Beispiel Preise und Rabatte, gilt dies jedoch nicht. Dazu kommen Marketingkampagnen, wie die Bündelung verschiedener Ausprägungen
des Produktes zu einem Paket, die im Nachgang der Produktveröffentlichung denkbar sind. Demnach sind Schnittstellen der Vertriebsanwendung zu Informationssystemen nötig.
unverfälschtheit Bei der Aufbereitung der Produktdaten für
3D-Anwendungen ist eine Reduktion und Filterung aufgrund der Datenmenge und Quellformate unerlässlich. Dabei ist aber ein optimaler
Kompromiss zwischen Kompaktheit und Genauigkeit der produktbeschreibenden Daten anzustreben. Dies könnte unter anderem die
Produktform bei der Reduzierung der Geometriekomplexität betreffen. Beispielsweise ist das Karosseriedesign in der Automobilindustrie ein entscheidender Verkaufsfaktor. Es darf in der 3D-Darstellung
nicht zu einer sichtbaren Abweichung vom Original kommen.
skalierbarkeit Mit Bezug auf den Verarbeitungsprozess der Produktdaten meint die Skalierbarkeit die Fähigkeit, mit potentiell vielen komplexen und variantenreichen Produkten umgehen zu können.
Damit stellt sie eine Anforderungen des Entwicklers an den Verarbeitungsprozess und nicht an die Anwendung selbst dar. Ein Konzept
zur Produktdatenaufbereitung sollte im Hinblick auf die zu verarbeitende Datenmenge genauso in kleinen wie großen Projekten anwendbar sein.
assoziationswahrung Wichtig bei der Verarbeitung der Produktdaten ist es, die Verbindung der Daten untereinander zu wahren. Damit ist vor allem gemeint, die Verknüpfung von Geometrie
mit Zusatzinformationen während Konvertierungs- und Filterungsprozessen nicht zu verlieren. Dazu gehören zum Beispiel die Hierarchie und relative Positionierung von Baugruppen und Bauteilen oder
die Zugehörigkeit physikalischer Eigenschaften zu bestimmten Baugruppen.
schnittstellenneutralität Eine Softwarelösung zur (teilautomatisierten) Aufbereitung von Produktmodellen sollte neutrale
Schnittstellen nach außen zur Verfügung stellen. Dies bezieht sich
zum einen auf eine möglichst breite Unterstützung der von Herstellern genutzten Softwaresysteme zur Bereitstellung der Quelldaten.
Zum anderen gilt dies auch für die Schnittstellen, mit denen die
aufbereiteten Produktdaten für 3D-Anwendungen zur Verfügung gestellt werden.
4.1 analyse des problems
Vorbedingung
Aufbereitung
Nachbedingung
Quellformat
geometrische
Informationen
nicht-geometrische
Informationen
Zielformat
Abbildung 6: Produktmodellaufbereitung mechatronischer Produkte
4.1.4
Vor- und Nachbedingungen der Produktmodellaufbereitung
Die Schritte der Aufbereitung von Produktdaten hängen neben den
bereits angesprochenen Anforderungen wesentlich von den genutzten Technologien und Formaten ab. Damit sind auf der einen Seite
die Software und Datenformate zur Erzeugung von Produktmodellen gemeint und auf der anderen Seite jene Technologien, die nach
einer Datenaufbereitung zur Darstellung der Produkte, zum Beispiel
im Web, zum Einsatz kommen.
Allgemein kann der Zustand der Produktmodelle vor der Verarbeitung als Vorbedingung bezeichnet werden und jener danach als
Nachbedingung. Dieser Umstand, der im Folgenden noch genauer
zu untersuchen sein wird, ist in Abbildung 6 dargestellt. Darüber
hinaus lässt sich eine Unterteilung der Datenverarbeitung in die Aufbereitung von geometrischen Daten und die Aufbereitung von nichtgeometrischen Daten treffen.
vorbedingungen Die Situation vor der Verarbeitung der produktbeschreibenden Daten ist charakterisiert durch die Software und
Formate, mit denen Produkte innerhalb von Unternehmen entwickelt
und verwaltet werden.
Elementare Werkzeuge der Produktentwicklung stellen Softwarelösungen für das CAD dar. Abbildung 7 zeigt exemplarisch die Applikation SolidWorks mit dem Konstruktionsmodell eines Kompressors.
Die in solchen Systemen entstehende Geometrie stellt die Grundlage für weitere Prozesse der Produktentwicklung dar. Darunter fallen
etwa physikalische Berechnungen im Rahmen der Festkörpersimulation oder Fertigungsprozesse im Sinne des CAM.
39
40
konzeption
Abbildung 7: CAD Software: SolidWorks 2010 Premium
Die Geometrie liegt üblicherweise in Form von Volumen- und Flächenmodellen vor. Dabei handelt es sich um mathematische Beschreibungen der Formen. Diese haben die Eigenschaft auch kurvige Formen sehr exakt zu beschreiben und nicht etwa nur eine Annäherung
darzustellen.
Volumenmodelle, auch als konstruktive Festkörpergeometrie bezeichnet (vgl. Unterabschnitt 2.2.3), werden aus einfachen Objekten
durch Kombinationen der Objekte miteinander erzeugt. Die Verknüpfung dieser Primitiven erfolgt mit Hilfe von booleschen Operationen,
wie in Abbildung 8 dargestellt. Auf diese Weise können durch Kombination von Objekten durch Vereinigung, Bildung der Differenz oder
des Schnittes, komplexe Objekte hervorgebracht werden. Weiterhin
können Teile von Volumenmodellen mit Parametern versehen und somit nachträglich leicht verändert werden. Beispiele dafür sind Durchmesser, Materialstärken oder Radien.
Volumenmodelle besitzen die Eigenschaft, wie der Name bereits
andeutet, einen geschlossenen Körper zu bilden. Sie unterscheiden
somit zwischen einem inneren und einem äußeren Bereich des Modells.
Eine weitere verbreitete Repräsentationsform von Geometrie im
CAD-Bereich sind Freiformflächen. Ähnlich wie Volumenmodelle eignen sie sich für Anwendungsfälle, bei denen es auf Präzision ankommt. Diesen Formen liegen mathematische Beschreibungen in Form
von polynomialen Funktionen zugrunde. Auf diese Weise können organische Kurven mittels weniger Kontrollpunkte definiert und schnell
verändert werden. Verbreitete Arten von Freiformen in der Ebene
4.1 analyse des problems
=
Vereinigung
=
Differenz
=
Schnitt
Parameter
+
10 mm
=
Abbildung 8: Volumenmodelle und Parametrisierung
sind Bézier- und B-Spline-Kurven. Mittels NURBS werden diese Prinzipien auf den Raum übertragen (siehe Abbildung 9). Auf Grund der
komplexen Formen ist diese Methode prädestiniert für Anwendungen wie das Design von Karosserieteilen in der Automobilbranche.
nachbedingungen Die Situation nach der Verarbeitung der Daten ist geprägt durch die verwendeten Technologien zur Darstellung
der Produktmodelle. Davon hängt ab, in welcher Form die Daten an
diesem Punkt vorliegen müssen. Der Fokus liegt letztlich darin, dem
Kunden das Produkt mit seiner Geometrie und weiteren nichtgeometrischen Informationen zu präsentieren und eine Konfiguration komplexer Produkte zu ermöglichen.
Da eine Veränderung der Produktinformationen in dieser Phase
nicht mehr stattfindet, werden Lösungen aus dem Bereich der virtuellen Realität oder 3D-Web Technologien eingesetzt. Dies bedingt eine spezielle Repräsentationsform der Geometrie. Entgegen den Werkzeugen des CAD, bei denen mit mathematischen Beschreibungen der
Formen gearbeitet wird, sind hier polygonale Geometrien gefordert.
Ein Polygon (Vieleck) ist dabei Teil der Hülle eines Objektes und
setzt sich aus Punkten und Kanten zusammen. Übliche Polygone sind
Dreiecke (engl. triangles) und Vierecke (engl. quadrilateral). Ein Polygonnetz (engl. mesh) setzt sich wiederum aus mehreren Polygonen
zusammen und beschreibt auf diese Weise die Oberfläche eines geometrischen Objektes. Abbildung 10 zeigt das Verhältnis von Punkten,
Kanten, Polygonen und Polygonnetzen.
41
42
konzeption
Abbildung 9: Freiformflächen am Beispiel NURBS
Punkte
Kanten
Polygone
Polygonnetz
(vertex)
(edge)
(face)
(mesh)
Abbildung 10: Zusammensetzung von Polygonnetzen
4.2 aufgaben der produktmodellaufbereitung
geometrische daten
nichtgeometrische daten
Extraktion
Reduktion
Tesselierung
Oberflächenbeschreibung
Animation
Konvertierung
Zerlegung
Bereitstellung
Tabelle 5: Kernaufgaben der Produktmodellaufbereitung
4.2
aufgaben der produktmodellaufbereitung
Wie bereits erläutert wurde, ist die Verarbeitung von Produktdaten
auf der einen Seite für die Geometrie eines Produktes zu betrachten
und auf der anderen Seite für die nichtgeometrischen Daten (vgl. Abbildung 6). Für beide Typen von Daten fallen somit im Rahmen der
Produktmodellaufbereitung eine Reihe von Bearbeitungsschritte an.
Diese ergeben sich unter anderem aus den Rahmenbedingungen
des Problemfeldes und den Anforderungen an die Softwareanwendung zur Präsentation der Modelle gegenüber dem Kunden (vgl. Unterabschnitt 4.1.2, Unterabschnitt 4.1.3). Darüber hinaus ergeben sich
die Aufgaben aus dem Zustand der Daten auf Seiten des Herstellers
und aus dem benötigten Zustand der Daten zur Präsentation der Produkte in einer Vertriebsanwendung. Bezogen auf die Aufgaben der
Produktmodellaufbereitung spielen die Vor- und Nachbedingungen
dieses Prozesses eine entscheidende Rolle (vgl. Unterabschnitt 4.1.4).
Tabelle 5 stellt die allgemeinen Aufgaben der Produktdatenaufbereitung dar. Dabei gibt es Arbeitsschritte, die prinzipiell für geometrische und nichtgeometrische Daten auszuführen sind. Einige betreffen darüber hinaus speziell die 3D-Modelle. Die genannten Aufgaben
werden im Folgenden näher beschrieben.
extraktion Für die Aufbereitung der Daten stellt sich zunächst
die Aufgabe, die Informationen aus dem Eingangsdatensatz zu extrahieren. Bestimmte Teile der Produktmodelle erfordern eine gesonderte Behandlung, weshalb sie vom Rest der Daten separiert werden
müssen. Dies trifft besonders für die getrennte Extraktion von geometrischen und nichtgeometrischen Daten zu, falls diese in einer Datei
vorliegen. Dies kann etwa bei einer STEP-Datei als Eingangsdatensatz
43
44
konzeption
der Fall sein. Wichtig bei dieser Aufgabe ist es, die Assoziationen
zwischen den Daten nicht zu verlieren. Ein Produkt besitzt in diesem Sinne eine geometrische Gestalt und darüber hinaus verschiedene beschreibende Eigenschaften. Wenn verschiedene Informationen
getrennt aus dem Eingangsdatensatz entnommen werden, muss sichergestellt sein, dass jederzeit klar ist, zu welchem Produkt oder
Teil eines Produktes ein Informationsblock gehört.
Entfernen von
Geometrie
Vereinfachen von
Geometrie
Vernachlässigung
unrelevanter
Daten
reduktion Die Aufgabe der Reduktion von geometrischen Daten
beinhaltet zwei Facetten. Die erste besteht darin, Teile der Geometrie
komplett zu entfernen und die zweite liegt in der Reduktion der Datenmenge, mit denen die Formen beschrieben werden. Beide Methoden führen zu zwei Vorteilen. Zum einen werden die Übertragungszeiten der 3D-Modelle zum Client verringert, was sich besonders im
Umfeld von 3D-Webanwendungen positiv bemerkbar macht. Auf der
anderen Seite beanspruchen schlankere 3D-Modelle die Grafikhardware weniger. Dies führt allgemein zu einer flüssigeren Ausführung
von 3D-Anwendungen.
Mit dem Entfernen von Geometrie ist gemeint, das bestimmte Bauteile komplett oder teilweise aus dem 3D-Modell entfernt werden.
Dies gilt besonders für Kleinteile, da sie in der Regel wenig zur Gesamterscheinung eines Produktes beitragen, jedoch in der Summe erhebliche Hardwareressourcen binden. Das Entfernen von Geometrie
ist somit nötig, falls Teile der Geometrie für die Gesamterscheinung
wenig relevant sind oder im Inneren eines Objektes liegen und daher
nicht zu sehen sind. Ein weiterer Anwendungsfall, der diesen Arbeitsschritt nötig macht, ist der Schutz von intellektuellem Eigentum. So
können bestimmte Teile entfernt werden, die Aufschluss über die innere Funktionsweise eines Produktes liefern.
Die Vereinfachung von Geometrie meint hingegen die Optimierung
des polygonalen Modells auf einen angemessenen Detailgrad. Dabei
ist der bestmögliche Kompromiss zwischen Formtreue des reduzierten Modells und größter Datenreduktion anzustreben. Für die Vereinfachung der Geometrie gibt es im Wesentlichen zwei Ansatzpunkte.
Dabei ist zu unterscheiden, ob die Vereinfachung während oder nach
der Tesselierung durchgeführt wird. Im ersten Fall wird die mathematisch beschriebene CAD-Geometrie direkt im optimalen Detailgrad in
eine polygonale Repräsentation überführt. Dieser Fall ist anzustreben,
jedoch schwer automatisierbar. Der zweite Fall läuft darauf hinaus,
die polygonale Geometrie nachträglich zu vereinfachen, falls das Modell nach der Tesselierung zu hoch aufgelöst ist. Dazu existieren eine
Reihe von Algorithmen, die abhängig von Eingabeparametern, Formen unterschiedlich stark vereinfachen.
Eine Reduktion der Datenmenge ist auch in Bezug auf nichtgeometrische Informationen von Bedeutung. Am Ende sollten möglichst
nicht mehr Daten an die 3D-Anwendung übertragen werden, als im
4.2 aufgaben der produktmodellaufbereitung
jeweiligen Anwendungskontext nötig ist. Dies kann bedeuten, dass
nur der relevante Teil der Quelldaten überhaupt berücksichtigt und
weiterverarbeitet wird.
tesselierung Für die Repräsentation der Form von Produkten
ergeben sich besondere Aufgaben. Es ist nicht ausreichend diese Informationen aus dem Eingangsdatensatz zu extrahieren, in ein anderes Dateiformat zu überführen und in Teile zu zerlegen. Die innere
Struktur dieser Daten macht eine Überführung in eine andere Form
notwendig.
Auf Grund der unterschiedlichen Repräsentationsformen von Geometrie, die für die Konstruktion auf der einen Seite und für die interaktive Darstellung auf der anderen Seite verwendet werden, ergibt
sich die Notwendigkeit der Tesselierung (Kachelung) der Objekte.
Die Formen werden von einer mathematischen Beschreibung in
ein Polygonnetz überführt und somit diskretisiert. Dieser Prozess, im
Englischen als meshing, mesh construction oder grid generation bezeichnet, zielt auf eine Annäherung an die Originalform durch Polygone
ab.
Zunächst werden Punkte entlang der Kurven verteilt und diese anschließend zu einem Gitternetz verbunden. Die häufigste Grundform
bei der Erstellung des Polygonnetzes aus den Punkten stellen Dreiecke dar. Ein Verfahren, welches über die letzten Jahre besonders viel
Aufmerksamkeit in diesem Bereich erlangte, ist die Triangulierung
mittels des Algorithmus von Delaunay und darauf aufbauende Ansätze (vgl. [FG08, S. 114]). Diese Methode ermöglicht die Kontrolle
über die Stärke der Approximation des zu triangulierenden Objektes
[CCW06, S. 273]. Damit liegt das Geometriemodell nach der Tesselierung im Optimalfall in der richtigen Auflösung vor und eine weitere
Vereinfachung der Geometrie, wie im Folgenden Absatz beschrieben,
ist nicht notwendig.
oberflächenbeschreibung Der Fokus von Konstruktionswerkzeugen aus dem Bereich des CAD liegt üblicherweise nicht auf der
fotorealistischen Darstellung der Produkte, sondern auf deren Form,
Struktur und physikalischen Eigenschaften. Für eine Präsentation der
Produkte für Vertriebszwecke ist allerdings eine hochwertige Materialanmutung erforderlich. Die bloße Zuweisung von Farben für die
Bauteile und Baugruppen ist nicht ausreichend.
Aus diesem Grunde stellt eine Teilaufgabe, während der Produktmodellaufbereitung, die Bearbeitung der Materialoberflächen der Modelle dar. In der Computergrafik werden zur hochwertigen Darstellung von Oberflächen spezielle Shader in Verbindung mit Texturen
eingesetzt. Diese bedingen in der Regel allerdings einen gewissen
manuellen Aufwand. Es wird im Folgenden noch zu klären sein, wel-
45
46
konzeption
che Lösungsmöglichkeiten und Potentiale der Automatisierung sich
für diese Aufgabe bieten.
animation Szenen der 3D-Computergrafik werden erst durch Bewegung und Animation wirklich dreidimensional. Auch eine statische Grafik kann ein Gefühl von Raumtiefe vermitteln. Schwierig
wird es allerdings, wenn ein Objekt von allen Seiten gezeigt werden
soll oder zeitliche Abläufe darzustellen sind.
Neben der Bewegung der Kamera in der Szene bieten sich dafür
Möglichkeiten der Animation von Objekten an. Gemeint ist in diesem Zusammenhang die Veränderung bestimmter Eigenschaften von
Teilen oder ganzen Produkten über eine Zeitspanne hinweg. Beispiele für solche veränderlichen Eigenschaften sind die Position, Rotation
oder Skalierung von Objekten. Für die Darstellung mechatronischer
Produkte kann auch die Animation von Materialeigenschaften wie
Transparenz oder das Verformen von Objekten interessant sein.
Praktisch ergeben sich drei Szenarien für die Anwendung von Animationen im hier diskutierten Kontext:
1. Erstellung durch Hersteller (CAD)
2. Erstellung durch 3D-Artist (DCC)
3. Erstellung durch 3D-Entwickler (Scripting)
Animation durch
CAD-Werkzeuge
Animation durch
DCC-Werkzeuge
Im ersten Fall werden die Animationen auf der Herstellerseite umgesetzt. Dazu bieten CAD-Anwendungen Möglichkeiten die Kinematik von Bauteilen und Baugruppen näher zu beschreiben. Üblicherweise dient dies dem Zweck Kollisionen von Teilen zu erkennen oder
Simulationen durchzuführen. Es ist jedoch auch möglich in Softwarewerkzeugen der Konstruktion Animationen und zum Teil sogar Filme
zu erstellen. Für den hier diskutierten Anwendungsfall können die erstellten Bewegungsabläufe zur weiteren Verarbeitung in ein neutrales
Datenformat exportiert werden. X3D und dessen Vorgänger VRML
sind Beispiele universeller 3D-Formate, die Animationen aufnehmen
können. Die CAD-Software SolidEdge mit dem integrierten Animationswerkzeug Simply Motion bietet beispielsweise die Möglichkeit,
Animationen zu erstellt und zur weiteren Verwendung samt den 3DDaten zu exportieren [Wag09, S. 17].
Liefert der Produkthersteller keine Animationen mit den darzustellenden Produktmodellen aus, können diese auch nachträglich erzeugt werden.
Eine Möglichkeit der späteren Erstellung der Animationen liegt im
Gebrauch von Werkzeugen der DCC. Damit ist Software gemeint, die
zur Medienproduktion von 3D-Artists eingesetzt wird. Diese Tools,
wie etwa Autodesk 3ds Max oder Blender, bieten Möglichkeiten, Keyframeanimationen zu erstellen und ebenso, wie bereits für CAD-Werkzeuge erwähnt, diese zu exportieren. Bei der Keyframeanimation wer-
4.2 aufgaben der produktmodellaufbereitung
den für die zu animierenden Parameter manuell feste Werte für bestimmte Zeitpunkte vorgegeben. Diese Keyframes – oder Schlüsselbilder – geben diskrete Stationen der Animation vor. Sämtliche dazwischen liegenden Werte für die sogenannten Interframes können
anschließend automatisch vom Rechner interpoliert werden.
Über die Keyframeanimation hinaus gibt es die Möglichkeit, Animationen zu programmieren. Damit wird die Veränderung von Parametern nicht durch vorgegebene Werte zu bestimmten Zeitpunkten
vorgegeben, sondern durch Programmlogik kontinuierlich verändert.
Dazu wird die Animation nicht erstellt und in ein 3D-Format exportiert, sondern in der Skriptsprache, der zur Darstellung genutzten
3D-Engine, geschrieben. Dies bietet die Möglichkeit, die Animation
dynamischer zu gestalten und zum Beispiel vom Zustand der 3D-Anwendung oder von Eingaben des Benutzers abhängig zu machen.
konvertierung Die Geometrie mechatronischer Produkte entsteht, wie bereits angesprochen, mit Werkzeugen des CAD. Dazu
verwendete Dateiformate sind, neben den nativen Formaten eines
jeden CAD-Programms, verschiedene Austauschformate, wie etwa
STEP. Die in diesem Bereich verwenden Dateiformate sind jedoch speziell für Anforderungen der mechatronischen Konstruktion optimiert
und nicht für die hochwertige Darstellung in 3D-Anwendungen zur
Präsentation vor dem Endkunden. Aus diesem Grund ist eine Überführung der geometrischen Informationen in ein universelles Visualisierungsformat nötig. Beispiele hierfür sind X3D, Collada oder FBX.
Diese sind speziell für die Speicherung von Polygonnetzen optimiert,
wie sie nach dem Prozess der Tesselierung entstehen und bieten bessere Möglichkeiten die Oberflächen der Modelle zu beschreiben. Dazu gehört beispielsweise die Einbettung von Texturen. Hinzu kommt,
dass die CAD-Formate nicht für die Verwendung im Kontext von 3DWebanwendungen geeignet sind.
Auch produktbeschreibende Informationen aus dem Bereich des
PLM sollten für eine weitere Nutzung durch Webanwendungen in ein
günstiges Format überführt werden. Für diesen Zweck sind auf XML
basierende Formate oder JSON deutlich besser geeignet.
zerlegung Primär aus der Anforderung der Webfähigkeit der resultierenden 3D-Anwendung und der damit begrenzten Bandbreite
für Datenübertragungen resultiert die Aufgabe, die Daten der Produktmodelle in Teilen übertragen zu können. Je nach Komplexität des
Produktes ist es sinnvoll, dessen Geometrie nicht als Ganzes zu übertragen und darzustellen. Eine Zerlegung in Bauteile und Baugruppen
ist nötig. Vorteilhaft ist dies außerdem bei Anwendungsfällen wie der
Konfiguration, bei der Baugruppen und Bauteile Alternativen füreinander darstellen.
47
Animation durch
Scripting
48
konzeption
Der Austausch von 3D-Objekten in einer Anwendung lässt sich
effizienter gestalten, falls diese in Teilen nachgeladen und verarbeitet werden können. Dies gilt für geometrische Informationen genauso wie für nichtgeometrische. Produktbeschreibende Informationen
müssen zunächst als Einzelkomponenten angesprochen und verarbeitet werden, um sie auf Anfrage zur Verfügung stellen zu können.
bereitstellung Nachdem die Produktmodelle entsprechend den
Anforderungen zur Darstellung in vertriebsorientierten 3D-Anwendung vorbereitet wurden, müssen sie eben diesen Anwendungen bereitgestellt werden. Um die Aktualität der Produktinformationen in
einer solchen 3D-Anwendung zu gewährleisten, ist eine Lösung erforderlich, die ein nachträgliches Hinzufügen und Verändern des Datenbestandes ermöglicht. Für diesen Anwendungsfall ist es ungenügend
die Produktmodelle statisch in die 3D-Software einzubetten. Auch im
Hinblick auf die Anforderung der Skalierbarkeit des Datenaufbereitungsprozesses stellt die manuelle Übergabe der Daten mit anschließender Integration in die 3D-Anwendung durch einen Entwickler eine Hürde dar.
Zur Lösung bietet sich eine Onlineschnittstelle an, die das gezielte
Nachladen von Produktinformationen auf Anfrage des Nutzers ermöglicht. Eine solche Schnittstelle lässt sich beispielsweise in Form
von Webservices umsetzten. Dabei werden zur Kommunikation zwischen Softwareanwendungen wohldefinierte Funktionalitäten nach
außen zur Verfügung gestellt.
4.3
modellierung des softwaresystems
Nach der Analyse des Problems kann eine Lösung erarbeitet werden,
um die Produktmodelle entsprechend den Anforderungen und den
zu lösenden Teilaufgaben aufbereiten zu können. Vor der Beschreibung von Einzelheiten des Systems, sollen zunächst grundlegende
Gedanken zur Lösungsfindung dargelegt werden. Zur Bearbeitung
der in Tabelle 5 identifizierten Aufgaben wird ein Softwaresystem
vorgeschlagen, das alle am Problemfeld beteiligten Interessengruppen bei deren Aktivitäten unterstützt. Dieses Gesamtsystem wird im
Folgenden als CAD2Web-Softwaresystem bezeichnet.
Der grundlegende Charakter der Lösung wird wesentlich durch
zwei Anforderungen bestimmt. Zum einen ist hoher Realismus bei
der Darstellung von Produkten in der 3D-Anwendung gefordert. Zum
anderen wird die Lösung maßgeblich geprägt durch die Anforderung
der Skalierbarkeit des Datenaufbereitungsprozesses.
Um große Datenmengen im Sinne vieler Produkte aufbereiten zu
können, ist ein möglichst hoher Grad an Automatisierung anzustreben. In der Aufbereitung von Produktmodellen stellen sich jedoch
Aufgaben, die vollständig maschinell nur schwer zu bewältigen sind.
4.3 modellierung des softwaresystems
49
CAD2Web Softwaresystem
Hersteller
Produkt hinzufügen
« extends »
Produktdaten nachbearbeiten
« extends »
Geometrieoptimierung
3D-Entwickler
Texturierung
Animation
« includes »
Produktmodell freigeben
Produkte auflisten
Nutzer
Produktdetails anfordern
Abbildung 11: UML-Anwendungsfalldiagramm des Szenarios der Datenaufbereitung
Aus den in Tabelle 5 dargestellten Aufgaben der Produktmodellaufbereitung zählen vor allem jene betreffend der Geometrie dazu. Im
Besonderen lassen sich die Arbeiten der Geometriereduktion, Oberflächenbeschreibung und Animation mit qualitativ besseren Ergebnissen händisch durchführen.
Daher stellt sich für den Prozess der Datenaufbereitung eine Kombination aus Automatisierung und manueller Nachbearbeitung als
beste Lösung dar. Der grundlegende Charakter der vorgestellten Lösung lässt sich in folgenden Punkten festhalten:
• durchgängige Automatisierung
• optionale Nachbearbeitung
• Datenaustausch durch Standards
• serviceorientierter Ansatz
Um eine hohe Zahl von Produktmodellen in kürzester Zeit verarbeiten und somit für vertriebsorientierte 3D-Anwendungen bereitstellen zu können, wird ein automatisierter Prozess bereitgestellt. Bei
besonders hohen Anforderungen an die Qualität der resultierenden
Daten kann zusätzlich eine Optimierung und Anreicherung der resultierenden Modelle mit speziellen Werkzeugen manuell erfolgen.
Kernkonzept der
Lösung
50
konzeption
Abbildung 11 zeigt die wesentlichen Aktivitäten der am System
beteiligten Akteure. Das Anwendungsfalldiagramm zeigt allerdings
nur von Menschenhand durchgeführte Prozesse und nicht etwa das
gesamte Funktionsspektrum.
Zur letztendlichen Darstellung der Produktmodelle müssen diese dem System durch den Hersteller zunächst zugänglich gemacht
werden. Damit initiiert dieser den Prozess der Datenaufbereitung.
Die Aktivität Produkt hinzufügen bezeichnet allerdings nicht nur den
Schritt des Einspielens der Quelldaten, sondern schließt die Verarbeitung der Daten und die anschließende Freigabe mit ein. In diesem
Sinne ist ein Produkt dem System hinzugefügt, wenn es letztendlich
nach außen für Nutzer von 3D-Anwendungen zur Verfügung steht.
Dies kann optional durch einen 3D-Entwickler nachbearbeitet werden. Der Prozess des Hinzufügens eines Produktes zum Softwaresystem stellt eine grundlegende Operation dar und wird daher noch
vertieft (vgl. Abbildung 12).
Darüber hinaus interagiert der Nutzer mit dem System, indem er
sich die Menge der enthaltenen Produkte präsentieren lässt und zu
ausgewählten Produkten beschreibende Informationen anfragt. Der
Akteur Nutzer steht stellvertretend für die Endkunden und die Vertriebsmitarbeiter und bildet somit eine Zusammenfassung dieser Interessengruppen.
Der Ablauf des Hinzufügens eines Produktes zum System ist in Abbildung 12 in Form eines UML-Aktivitätsdiagramm dargestellt. Die
drei am Prozess beteiligten Akteure übernehmen folgende Aufgaben:
• Hersteller: Erzeugen der Daten
• CAD2Web-Server: automatische Verarbeitung
• 3D-Entwickler: Freigabe und manuelle Nachbearbeitung
Auf Seiten des Herstellers werden bei diesem Ablauf zunächst Austauschformate durch Spezialsoftware erzeugt. Diese kommen zum
einen aus den CAD-Werkzeugen und zum anderen aus den PLM-Systemen. Der CAD2Web-Server hält einen eigenen Datenbestand, um
im Falle eines Ausfalls des PLM-Servers den Dienst aufrecht erhalten
zu können. Dieser führt auf Basis der Eingangsdaten die Verarbeitung der geometrischen Daten und sonstigen Produktinformationen
durch. Eine tiefer gehende Beschreibung des CAD2Web-Servers wird
im Unterabschnitt 4.3.2 gegeben.
Letztendlich erfolgt eine Freigabeprüfung, der automatisch verarbeiteten Produktmodelle, durch einen 3D-Entwickler bzw. 3D-Designer. Diesem wird Zugriff auf die verarbeiteten Produktmodelle ermöglicht, um sie bei Bedarf mit Spiezialwerkzeugen weiter zu optimieren oder anreichern zu können.
Die Struktur des Softwaresystems orientiert sich an der Struktur
des Problems. Für die Verarbeitung der Produktmodelle existieren
4.3 modellierung des softwaresystems
« subsystem »
CAD2Web - Server
Hersteller
3D-Entwickler
CADFormat
Austauschformat
erzeugen
STEP
Produktdaten
hochladen
Bestand
prüfen
[Produkt
vorhanden?]
Ja
Nein
STEP
Verarbeitung
Geometrie
X3D
Verarbeitung
Nichtgeometrie
XML
Freigabe
Ja
Nein
Geometrieoptimierung
Texturierung
Animation
Abbildung 12: UML-Aktivitätsdiagramm: Produkt hinzufügen
51
52
konzeption
GUI - Graphical User Interface
WS - Webservice
CAD2Web Softwaresystem
Hersteller
PLM - System
GUI
WS
WS
CAD2Web - Server
3D-Entwickler
GUI
WS
WS
3D-Client
Nutzer
GUI
Abbildung 13: UML-Architektur-Montagediagramm
Vor- bzw. Nachbedingungen in Form des gegebenen Zustands der
Quelldaten und des geforderten Zustandes der Zieldaten. Aus diesen Bedingungen ergibt sich das in der Datenverarbeitung klassische
EVA-Prinzip: Eingabe-Verarbeitung-Ausgabe.
Diesem Schema entsprechend sind die in Abbildung 13 dargestellten drei Komponenten bzw. Subsysteme des Gesamtsoftwaresystems
zu sehen. Dieses Prinzip trifft zum einen für das Systems als Ganzes,
als auch für die Komponenten im Einzelnen zu. Auf die Teilkomponenten wird im Folgenden noch näher einzugehen sein.
Für die Gesamtarchitektur des Systems gilt, dass die Subsysteme
untereinander über definierte Schnittstellen zur Kommunikation verfügen müssen. Für eine solche Kommunikation zwischen verteilten
Softwaresystemen existieren eine Reihe von Mechanismen. Beispiele
solcher Technologien sind, JavaRMI [Gro11] für den Methodenaufruf
zwischen verteilten Java-Anwendungen, CORBA [Sie96] als Spezifikation einer objektorientierten Middleware für verteilte Systeme und
DCOM [Red97] für die Kommunikation von Prozessen auf WindowsBetriebssystemen über ein Netzwerk.
Aus der Anforderung der Schnittstellenneutralität (siehe Tabelle 4)
geht jedoch hervor, dass die Schnittstelle unabhängig von der zur Programmierung der Komponenten verwendeten Sprache oder des ein-
4.3 modellierung des softwaresystems
53
gesetzten Betriebssystems sein sollte. Webservices (WS) stellen eine
solche sprachen- und plattformneutrale Technologie zur Kommunikation zwischen Softwareanwendungen dar. Von den genannten Technologien entsprechen sie am besten dem Gedanken der serviceorientierten Architektur (SOA) und eignen sich besonders für den Einsatz
im WWW [KMH10, S. 2].
Für deren Implementierung bieten sich zum einen das SOAP-Protokoll und zum anderen das REST-Programmierparadigma an. Für
weitere Informationen zu Webservices sei auf [Mel10] und [WP11]
verwiesen.
Neben den Webservice-Schnittstellen für die Maschine–zu–Maschine Kommunikation der Komponenten untereinander, sind grafische
Benutzungsschnittstellen (GUI) erforderlich. Sie dienen der Interaktion der beteiligten Interessengruppen mit dem System. Zu diesen grafisch gestützten Aktivitäten gehören das Einpflegen der Quelldaten
auf Herstellerseite, die Umsetzung des Freigabeprozesses, die optionale manuelle Nachbearbeitung durch einen 3D-Entwickler und das
Konsumieren der Produkte durch den Nutzer mithilfe einer 3D-Anwendung.
Auf Herstellerseite wird das Einpflegen von Daten dabei zum einen
durch Hinzufügen zum PLM-System ermöglicht und zum anderen
durch direkten Upload auf den CAD2Web-Server.
Die jeweiligen Schnittstellen werden im Folgenden für die einzelnen Subsysteme näher beschrieben.
4.3.1
Subsystem: PLM-System
In herstellenden Unternehmen werden zur Umsetzung einer Strategie des Produktdatenmanagements spezielle Anwendungsserver eingesetzt. Entsprechend, des im Unterabschnitt 2.1.1 vorgestellten Produktlebenszyklus, beschreiben die Daten sämtliche Phasen innerhalb
der Lebensdauer eines Produktes. Diese produktbezogenen Informationen werden mithilfe solcher Systeme verwaltet und gepflegt.
Zur internen Repräsentation der Daten werden in diesen Systemen
zwar eigene Logiken und Strukturen eingesetzt, für die Interoperabilität mit anderen Anwendungen stehen jedoch sogenannte LoaderKonzepte bereit. Dadurch ist es möglich, die interne Struktur aus
externen Files aufzubauen und umgekehrt externe Files aus der internen Struktur zu generieren.
Dem zweiten Fall, in Form des Datenexports, kommt hier besondere Aufmerksamkeit zu. Im Kontext der vorgestellten Lösung dienen
PLM-Systeme als Datenquelle für den Aufbereitungsprozess.
Für diesen Anwendungsfall kann es nützlich sein, die Freigabeverwaltung und Sicherheitsmechanismen dieser Systeme zu nutzen. So
ist es beispielsweise denkbar, nur jene Produkte und Baugruppen mit
PLM-System als
Datenquelle
54
Datenschnittstellen
konzeption
dem Status »freigegeben« bereitzustellen oder über Benutzerberechtigungen den Zugriff auf die Produktpalette einzuschränken.
Häufig legen Unternehmen vereinfachte Geometriemodelle zusammen mit den Konstruktions- und Fertigungsmodellen in den PLM-Systemen ab, die unternehmensintern zur Visualisierung genutzt werden [ES09]. Nach einer Prüfung im Einzelfall können diese Daten
direkt für die Darstellung der Geometrie genutzt und so Verarbeitungsschritte eingespart werden.
Für den Export von Daten aus einem PLM-Server sind grundsätzlich zwei Typen von Schnittstellen zu unterscheiden. Zum einen ist
dies die Datenschnittstelle. Sie bezieht sich auf die Formate der Daten,
welche aus dem System heraus generiert werden können. Weiterhin
sind die Kommunikationsschnittstellen von Interesse. Sie legen fest,
durch welche Technologien eine Anwendung mit dem PLM-System
kommuniziert. Auf diese Weise können entfernte Funktionsaufrufe
realisiert oder Produktinformationen in einem Austauschformat angefordert werden.
Im Hinblick auf die Datenschnittstelle existieren zwei Austauschformate, die in PLM-Systemen besonders häufig eingesetzt werden
(vgl. [HS07, S. 529]):
• STEP
• XML-basierte Formate
Im erstgenannten Fall werden die internen Datenstrukturen durch
Nutzung eines STEP-Toolkits entweder in das Dateiformat STEP physical file (ISO 10303 Part 21) oder STEP-XML (ISO 10303 Part 28) überführt. Die Lösung mySAP PLM bietet beispielsweise die Möglichkeit,
Objekte für die Freigabe im STEP-Format zu selektieren und stellt diese mithilfe eines STEP Servers und eines RFC Servers für andere Systeme zur Verfügung [HS07, S. 530].
Die zweite wichtige Datenschnittstelle stellen XML-basierte Formate dar. Diese werden vom PLM-System ebenfalls durch einen Mapper aus den internen Strukturen erzeugt. Hierbei bieten sich jedoch
Möglichkeiten die XML-Struktur speziell an die zu lösende Aufgabe
anzupassen. Darüber hinaus besitzen verschiedene Systeme spezielle
XML-Schemata. Dieser Ansatz bietet zwar mehr Flexibilität, lässt es,
im Gegensatz zu STEP mit den klar definierten Anwendungsprotokollen, aber an Einheitlichkeit mangeln.
Davon abgesehen stellt XML eine interessante Alternative dar. Die
Beschreibungssprache ist ebenfalls ein herstellerunabhängiger Standard. Darüber hinaus ist die Verarbeitung der so beschriebenen Daten
einfacher. Verglichen mit STEP sind keine teuren Bibliotheken sowie
Spezialwissen zur Entwicklung von Software, die dieses Format unterstützt, nötig. Ein weiterer Vorteil ist die einfache Kombinierbarkeit
mit HTTP. Dadurch eignen sich in XML beschriebene Daten besonders für den Einsatz im Web.
4.3 modellierung des softwaresystems
55
GUI - Graphical User Interface
WS - Webservice
CAD2Web - Server
Controller
Prozessor:
Geometrie
GUI
Datenhaltung
WS
Prozessor:
Produktbeschreibung
Abbildung 14: Komponenten des CAD2Web-Subsystems
Für den Austausch mit anderen Anwendungen stellen PLM-Systeme eine ganze Reihe von Technologien bereit. Die für diesen Anwendungsfall favorisierte Kommunikationsschnittstelle stellen Webservices
dar. Sie ermöglichen eine Interaktion zwischen Software-Agenten durch
Aufruf von URLs und den Austausch von XML-Artefakten. Solche
Dienste stellen damit eine lose Kopplung von Funktionskomponenten im Sinne einer serviceorientierten Architektur dar und sind dabei weder auf bestimmte Plattformen, noch Programmiersprachen beschränkt.
Eine weitere in diesem Zusammenhang erwähnenswerte Technologie, genannt PDMEnabler, wurde von der Objects Management Group
standardisiert. Diese PDMEnabler stellen CORBA-Objekte dar und
dienen dem Zugriff auf Eigenschaften und Methoden zur Manipulation von PDM-Daten. Das Konzept umfasst mehrere funktionale Module, darunter auch explizit den Im- und Export von STEP-Daten.
Für weitere Informationen zu PLM-Systemen und deren Schnittstellen sei auf [ES09] und [HS07] verwiesen.
4.3.2
Subsystem: CAD2Web-Server
Der in Abbildung 14 dargestellte CAD2Web-Server stellt die eigentliche Softwarelösung zur Realisierung des Aufbereitungsprozesses der
Produktdaten dar. Strukturell integriert er einen Application- und
einen Webserver. Der Applicationserver dient der Verarbeitung von
Quelldaten und der Webserver der Bereitstellung von Zieldaten.
Kommunikationsschnittstellen
56
Controller
Prozessor:
Geometrie
konzeption
Der Controller ist für die Kommunikation nach außen und für die
Steuerung interner Komponenten verantwortlich. Was die Eingangsseite der Daten angeht, ist eine Kommunikation mit dem PLM-System
nötig, um festzustellen ob neue Quelldaten im Sinne neuer Produkte vorliegen. Im Wesentlichen bieten sich dazu zwei Möglichkeiten.
Bei der ersten, dem sogenannten polling, wird zyklisch eine Anfrage
gestellt, ob neue Daten vorliegen. Beim zweiten Mechanismus, dem
pushing, informiert der PLM-Server aktiv den CAD2Web-Server über
Änderungen.
Für das Hinzufügen und Abfragen neuer Quelldaten wird folgende Strategie vorgeschlagen. Ein Polling-Mechanismus im Controller
fragt periodisch am PLM-Server an, ob neue Produktmodelle zur Verarbeitung vorliegen. Dies hat den Vorteil, dass ein Polling-Mechanismus im Rahmen von Webservices leicht zu implementieren ist. Darüber hinaus ist nicht davon auszugehen, dass auf Seiten des Herstellers in Abständen von Minuten oder Sekunden neue Produkte hinzukommen. Denkbar wäre demnach eine Abfrage im Minuten- oder
Stundentakt. Zusätzlich wird durch die grafische Benutzungsoberfläche des CAD2Web-Servers die Möglichkeit geboten, die Abfrage manuell zu starten. Dadurch kann der Datenimport, zum Beispiel nach
der Installation des Servers manuell angestoßen werden.
Für Anwendungsfälle, in denen keine Anbindung eines PLM-Systems als Datenquelle möglich ist, muss eine Alternative bereitgestellt
werden. Dieses Problem kann beispielsweise dadurch gelöst werden,
indem der CAD2Web-Server über eine Webanwendung den Upload
von Produktmodellen ermöglicht.
Für die Kommunikation mit den 3D-Clients ist ebenfalls die Bereitstellung einer Schnittstelle erforderlich. In diesem Sinne nimmt der
Controller Anfragen entgegen und liefert angeforderte Informationen
in Form der Zieldaten.
Ein wichtiger Gedanke in Bezug auf die Geometrieverarbeitung ist
die Integration vorhandener Softwaretools in den CAD2Web-Server.
Da auf dem Markt ausgereifte Lösungen existieren, bietet es sich an,
diese zu nutzen. Eine Eigenentwicklung wäre mit erheblichem Aufwand verbunden. Wesentliche Punkte für die Auswahl solcher Werkzeuge, im hier diskutierten Kontext, sind die Funktionalitäten und
die Möglichkeiten der Integration. Für die Erweiterbarkeit in Bezug
auf die Anforderungen an die Gesamtarchitektur ist ein großer Funktionsumfang dieser Kernkomponenten unabdingbar.
Zwei besonders geeignete Werkzeuge sollen im Folgenden unter
den hier interessanten Gesichtspunkten vorgestellt werden:
• Okino PolyTrans [Pol]
• Autodesk 3ds Max [3ds]
4.3 modellierung des softwaresystems
Beide Werkzeuge, dargestellt in Abbildung 15, bieten vor allem ausgereifte Funktionen zur Geometriebearbeitung und die Möglichkeit
des Scriptings.
(a) Okino PolyTrans
(b) Autodesk 3ds Max 2013
Abbildung 15: 3D-Anwendungen zur Integration in den CAD2Web-Server
Wie der Name PolyTrans bereits andeutet – Polygon und Transformation – ist die Applikation aus den Anforderungen der Datenkonvertierung von 3D-Modellen entstanden. Daraus resultiert eine sehr
gute Unterstützung für den Import von 3D-Formaten aus dem industriellen Umfeld. Während der nun 24-jährigen Entwicklungszeit ist
der Funktionsumfang über die Konvertierung hinaus stark gestiegen.
Zur Automatisierung von Aufgaben bietet PolyTrans Möglichkeiten durch Skripte auf eine Reihe interner Funktionen zuzugreifen.
Dazu stehen unter anderem, die von Microsoft entwickelten Skriptsprachen, VBScript und JScript zur Verfügung. Der so erstellte Pro-
57
58
Prozessor:
Produktbeschreibung
konzeption
grammcode kann nicht nur aus der grafischen Oberfläche heraus,
sondern auch durch Aufruf des Programm per Kommandozeile an
PolyTrans übergeben und abgearbeitet werden.
Autodesk 3ds Max wird vor allem zur Erstellung von 3D-Animationen, Videospielen und zur Architekturvisualisierung eingesetzt. Man
bezeichnet Werkzeuge in diesem Umfeld üblicherweise als DCC-Tools.
Besonders geeignet für die hier zu lösenden Aufgaben ist diese Software, da sie Funktionen bietet, um visuell hochwertige Ergebnisse zu
erzielen und gleichzeitig in der Lage ist, Datenformate aus dem Bereich der Konstruktion zu verarbeiten. Als eines von wenigen Werkzeugen dieser Art ist diese Applikation in der Lage das Industrieformat STEP einzulesen.
Sämtliche Funktionen, die im Rahmen der grafischen Benutzungsoberfläche ausgeführt werden können, sind in Autodesk 3ds Max
durch externe Skripte aufrufbar. Dafür wurde eigens die Skriptsprache MAXScript entwickelt. Diese Programmierbarkeit zusammen mit
der Möglichkeit, Skripte beim Start der Anwendung durch Kommandozeilenparameter übergeben zu können, ermöglichen die Einbindung von Autodesk 3ds Max in eigene Anwendungen. Auf diese
Weise können Aufgaben im Rahmen einer automatisierten Verarbeitungspipeline an die Anwendung delegiert werden.
Bei der Verarbeitung nichtgeometrischer Daten geht es darum, die
beschreibenden Informationen zu einem Produkt aus dem STEP-File
zu extrahieren und in ein neutrales Format, wahlweise XML, zu überführen. In dieser Form können die Informationen leichter in Teilen
ausgeliefert und von 3D-Anwendungen interpretiert werden. Zur Extraktion der Daten aus dem STEP-Format bieten sich softwareseitig
zwei Optionen an. Dies ist zum einen die Programmierung mithilfe
von Spezialbibliotheken und zum anderen die Definition von Transformationsregeln basierend auf XSLT.
Es existieren Bibliotheken für verschiedene Programmiersprachen,
um STEP-Daten zu lesen, zu manipulieren und zu schreiben. Ihnen
allen ist gemein, dass sie sehr robust sind und, in Bezug auf die STEPSpezifikation, über einen umfangreichen Funktionsumfang verfügen
[Fro11, S. 15]. Tabelle 6 stellt drei verbreitete STEP-Bibliotheken in einer Übersicht dar.
Liegen die Produktmodelle in dem XML-basierten Format STEPXML (ISO 10303 Part 28) vor, bietet sich eine alternative Verarbeitungsmethode zu den genannten STEP-Bibliotheken an. In dem Fall
lassen sich die Produktmodelle mit XSLT verarbeiten und dadurch
in ein anderes XML-Format überführen. Dabei werden für einzelne XML-Knoten der Eingangsdaten Verarbeitungsregeln durch XSLTTemplates definiert. Dieses Szenario setzt die Implementierung dieser
Templates für sämtliche zu berücksichtigenden Inhalte des STEP Standards voraus.
4.3 modellierung des softwaresystems
59
JSDAI (Java Standard Data Access Interface) [JSD]
Lizenz
open source, proprietär
Entwickler
LKSoft GmbH
Programmiersprache
Java
ST-Developer [STD]
Lizenz
proprietär
Entwickler
STEP Tools Inc. (USA)
Programmiersprache
C++, Java
STEP Class Library [STE]
Lizenz
open source
Entwickler
(Community Projekt)
Programmiersprache
C++, Python
Tabelle 6: Übersicht – STEP-Bibliotheken (SDKs)
Von den vorgestellten Möglichkeiten zur Verarbeitung STEP-basierter
Daten scheint die Bibliothek JSDAI besonders für den Einsatz im Kontext der vorliegenden Aufgabenstellung geeignet. Sie bietet Werkzeuge, um die Quelldaten auf Standardkonformanz zu testen. Darüber
hinaus ist die Unterstützung künftiger Anwendungsprotokolle über
einen Compiler gegeben, mit dessen Hilfe Java-Klassen aus der Modellierung dieser AP generiert werden können. Nicht zuletzt eignet
sich diese Bibliothek aufgrund der Programmiersprache Java, mit deren Hilfe sich so entwickelte Softwarekomponenten gut in eine serverseitige Webanwendung integrieren lassen.
Auf dem CAD2Web-Server müssen die Quelldaten für die Verarbeitung und die Zieldaten für die Bereitstellung nach außen verfügbar sein. Der Controller legt die Quelldaten in Form von STEP-Dateien in einem speziellen Bereich ab. Diese werden durch die Verarbeitungskomponenten gelesen und die Resultate in Form von X3D
und XML-Dateien abgelegt. Bei einer Anfrage durch einen 3D-Client
greift der Controller auf die vorgehaltenen Zieldaten zu und liefert
sie per HTTP an die anfragende Anwendung aus.
4.3.3
Subsystem: 3D-Client
An dieser Stelle sollen die Mindestanforderungen an 3D-Technologien dargelegt werden, die nötig sind, um die vom CAD2Web-Server
gelieferten Inhalte interpretieren und darstellen zu können. Die drei
Datenhaltung
60
Kommunikation
mittels HTTP
API zur Szenengraphmanipulation
konzeption
in Abschnitt 2.3 vorgestellten Technologien (Unity3D, WebGL, Stage
3D) erfüllen die Anforderungen und können somit zur Implementierung eines 3D-Clients im Rahmen des hier vorgestellten Gesamtkonzeptes eingesetzt werden.
Der Grundgedanke der Gesamtlösung besteht darin, Produktmodelle »live« dem System hinzuzufügen. Demnach sind die konkreten Produktmdodelle zur Zeit der Entwicklung der 3D-Anwendung
nicht bekannt. Die prinzipielle Struktur der Inhalte ist zwar klar, um
die Programmlogik der Software entsprechend erstellen zu können,
die eigentlichen Inhalte werden jedoch zur Laufzeit geladen und instanziiert.
Da der CAD2Web-Server die verarbeiteten Produktmodelle durch
Webservices bereitstellt, ist eine Kommunikation mit der 3D-Anwendung durch HTTP erforderlich. Dabei ist es technisch unerheblich,
ob es sich beim 3D-Client um eine Webanwendung im Browser, eine
klassische Desktopanwendung oder um eine App auf einem mobilen
Gerät handelt. Eine 3D-Anwendung kann die gelieferten Inhalte generell verarbeiten, so lange sie über eine Internetverbindung und die
Möglichkeit verfügt, Inhalte aus dem Web aufzurufen.
Die Produktmodelle werden der anfragenden Applikation ähnlich
einer klassischen Webseite in Textform übermittelt. Dabei kommen
übliche Kodierungen wie etwa UTF-8 zum Einsatz. Der Unterschied
liegt lediglich darin, dass die Geometrien und nichtgeometrischen
Daten nicht als HTML-Dokument an den Client übertragen werden,
sondern in Form von X3D und weiteren XML-Formaten.
Wie auch bei der Interpretation klassischer zweidimensionaler Webseiten durch den Browser, kennt die darstellende Anwendung das
Format und kann die Inhalte entsprechend darstellen. Für immersive
Webanwendungen erfordert die interaktive Darstellung die Modifikation des Szenengraphen zur Laufzeit. 3D-Technologien bieten dafür
jeweils eine eigene API, um Objekte der 3D-Szene zu manipulieren
oder neue hinzuzufügen.
4.4
zusammenfassung
Um eine Lösung für die Optimierung der Produktmodellaufbereitung zu finden, wurde zunächst die Problemstellung analysiert, um
anschließend ein Konzept für die Softwareunterstützung zu entwickeln. Es zeigten sich drei am Lösungsprozess beteiligte Interessengruppen. Dies sind der Hersteller als Urheber der Produktmodelle,
der Entwickler im Sinne eines Dienstleisters zur manuellen Produktmodellaufbereitung und Anwendungsentwicklung sowie der Endkunde als Nutzer der 3D-Anwendung. Weiterhin wurden in diesem
Kontext Anforderungen an eine Lösung beschrieben. Diese beziehen
sich zum einen auf den Prozess der Datenaufbereitung und zum anderen auf die 3D-Applikation zur Darstellung der Produkte.
4.4 zusammenfassung
Um Teilaufgaben für den Prozess der Produktmodellaufbereitung
ableiten zu können, wurde die Struktur der Produktgeometrie näher
betrachtet. Dies beinhaltet den Zustand der Daten auf der Eingangsseite des Prozesses und den benötigten Zustand der Daten auf der
Ausgangsseite für die Darstellung in einer 3D-Anwendung.
Die Betrachtungen führten zur Konzeption eines Softwaresystems
bestehend aus drei Hauptkomponenten mit dem Ziel, die vorliegende Problemstellung durch Automatisierung zu lösen und gleichzeitig
eine optionale manuelle Nachbearbeitung zu unterstützen.
61
5
IMPLEMENTIERUNG
5.1
zielstellung der implementierung
Im Folgenden wird die prototypische Implementierung des in Kapitel 4 beschriebenen Konzeptes zur Unterstützung der Produktmodellaufbereitung beschrieben. Ziel der Implementierung ist es, den Prozess der Aufbereitung von Anfang bis Ende zu unterstützen. Bezüglich des Umfangs der Funktionalitäten – also der Breite des Prozesses
– erfolgt jedoch eine Einschränkung auf die wesentlichen Bereiche.
Zur Beschreibung der Implementierung wird nachfolgend die Umsetzung der drei Subsysteme der Lösung in Anlehnung an Abschnitt 4.3
erläutert.
5.2
abstraktion des plm-systems
Um der Anforderung der Aktualität der Daten zu genügen, wurde in
Abschnitt 4.3 die Anbindung eines PLM-Systems als Datenquelle vorgeschlagen. Ebenfalls sind STEP und XML als übliche Exportformate
für diese Systeme genannt worden. Auf Grundlage dieser Kenntnis
dient ein Webserver, welcher Daten in den genannten Formaten als Ergebnis von Anfragen liefert, als Abstraktion eines PLM-Systems. Diese Maßnahme vereinfacht den Kommunikationsaufwand für die Beschaffung der Daten im Rahmen des Prototypen erheblich. Dadurch
kann eine Fokussierung auf die Verarbeitung der Daten erfolgen.
Ein Webserver liefert in diesem Szenario beim Aufruf einer URL
eine Liste der verfügbaren Produktmodelle in Form von XML. Darin enthalten sind für jedes Produkt dessen Name sowie die Namen
der zugehörigen STEP-Dateien, welche die Produktmodelle beinhalten. Diese können ebenfalls durch Senden eines HTTP-Requests vom
CAD2Web-Server angefragt werden. Durch diese Konstruktion können größere Mengen von Produktmodellen beim Starten des CAD-
Webserver
products.xml
1. Req(Produktliste)
Resp(products.xml)
ProduktA.stp
2. Req(ProduktA)
ProduktB.stp
..
.
Resp(ProduktA.stp)
CAD2Web-Server
config.xml
Webserver-URL
..
.
Abbildung 16: Abstraktion des PLM-Systems
63
64
implementierung
geometrische daten
nichtgeometrische daten
Extraktion
Reduktion
Tesselierung
Oberflächenbeschreibung
Animation
Konvertierung
Zerlegung
Bereitstellung
Tabelle 7: Umgesetzte Aufgaben der Produktmodellaufbereitung
2Web-Servers initial geladen und verarbeitet sowie durch zyklische
Abfragen neu hinzugekommene Produktmodelle berücksichtigt werden. Die Adresse des abstrahierten PLM-Systems ist der Serveranwendung dabei vorher durch eine Konfigurationsdatei bekannt gemacht
worden. Abbildung 16 stellt diesen Zusammenhang grafisch dar.
5.3
cad2web-server
Der Server zur Verarbeitung und Bereitstellung der Produktmodelle
hat das Ziel, die in Abschnitt 4.2 identifizierten Aufgaben der Produktmodellaufbereitung abzuarbeiten. Im Rahmen der prototypischen
Implementierung werden die in Tabelle 7 hervorgehobenen Aufgaben
unterstützt. Die Abarbeitung dieser Kernaufgaben stellt die Voraussetzung für einen Verarbeitungsprozess im Sinne der Zielstellung dieser Arbeit dar.
Die automatische Umsetzung der Reduktion von geometrischen
Daten sowie die automatisierte Erstellung von Animationen stellen
dagegen zusätzliche Funktionalitäten dar, die eine solche Lösung optimieren, beziehungsweise erweitern würden. Die algorithmische Lösung dieser Aufgaben repräsentiert ein Problem höherer Komplexität
und erfordert weiteres Evaluieren und Implementieren von Softwarekomponenten. Die Zerlegung der Datenpakete stellt weniger komplexe Anforderungen an die Implementierung, dient jedoch – ähnlich
wie die Reduktion der Daten – der Optimierung der Performance.
Die drei in Tabelle 7 nicht hervorgehobenen Aufgaben wurden aus
den genannten Gründen nicht in die vorliegende Implementierung
aufgenommen.
Im Folgenden wird beschrieben, welche in die Serveranwendung
integrierten Werkzeuge die automatisierte Umsetzung der Aufgaben
5.3 cad2web-server
GEOMETRISCHE
DATEN
NICHTGEOMETRISCHE
DATEN
STEP
3DS Max
JSDAI
Java
Objekt
VRML
CyberX3D
for Java
Java API
for XML
X3D
Jersey, Java
Server Pages
X3D
Abbildung 17: Softwarekomponenten im Prozess der Produktmodellaufbereitung
ermöglichen. Es ist zu klären, welchen Komponenten in der Anwendung welche Aufgaben zugeordnet sind. Darüber hinaus sollen die
Ausführungen dem Verständnis des Verarbeitungsprozesses mit den
sich darin ändernden Repräsentationsformen der Produktmodelle dienen.
Das Rückgrat der Serveranwendung stellt ein in Java implementierter Teil dar. Dieser Programmteil dient der Steuerung von weiteren Softwarekomponenten im Sinne des in Abschnitt 4.3 eingeführten Controllers. Zur Ausführung dieser Applikation kommt Apache
Tomcat [Tom] zum Einsatz. Tomcat stellt als Servlet-Container eine
Umgebung zur Ausführung von Java-Code bereit. Durch den integrierten HTTP-Server können Java-Anwendungen als serverseitige
Webanwendungen eingesetzt werden. Auf dieser Grundlage ist die
grafische Schnittstelle des Prototyps darüber hinaus mit JavaServer
Pages umgesetzt.
Der Prozess, der innerhalb des CAD2Web-Servers abläuft und für
den die Java-Anwendung das Bindeglied darstellt, ist in Abbildung 17
abgebildet. Es sind sowohl, die zur Verarbeitung geometrischer und
nichtgeometrischer Daten, eingesetzte Software zu erkennen, als auch
die jeweilige Eingabe- und Ausgabestruktur der Daten. Der Verarbeitungsprozess kann als Abbildung zwischen den Datenformaten STEP
65
66
implementierung
und X3D verstanden werden. Darüber hinaus findet eine Veränderung der inhaltlichen Struktur der Daten statt.
Zur Verarbeitung der Geometrien wird zum einen die externe Software Autodesk 3ds Max bemüht, und zum anderen die Java-Bibliothek CyberX3D for Java [Cyb] eingebunden. Durch die Scriptingfunktionalität von Autodesk 3ds Max wird mittels eines MAXScripts ein
Batch-Prozess zur Konvertierung mehrerer Produktmodelle vom STEPFormat nach VRML ausgeführt. Die inhaltliche Schnittmenge der beiden Formate hat zur Folge, dass bei diesem Prozess sämtliche nichtgeometrische Informationen unberücksichtigt bleiben. Aus den Quelldaten wird somit die Geometrie extrahiert, tesseliert und in ein universelles Visualisierungsformat überführt.
Zur letztendlichen Konvertierung nach X3D dient die erwähnte
Java-Bibliothek CyberX3D for Java. Dabei ist es essentiell, dass die Bezeichner von Baugruppen und Teilen mitgeführt werden, um später
die Zuordnung von weiteren Informationen zur Geometrie gewährleisten zu können. Dieses Kriterium führte zum Ausschluss weiterer
getesteter Bibliotheken wie zum Beispiel VrmlMerge [Vrm].
Für die Extraktion und Verarbeitung nichtgeometrischer Informationen kommt die Java-Bibliothek des Werkzeuges JSDAI zum Einsatz.
Mit deren Hilfe lassen sich die Quelldaten im STEP-Format auslesen
und im Falle des Prototyps textuelle Informationen zur Beschreibung
der Produkte sowie zur Verwendung von Materialien in Java weiterverarbeiten. Die bei der Verarbeitung der Geometrie vorher erzeugten
X3D-Daten werden in diesem Schritt mit den erwähnten produktbeschreibenden Informationen angereichert.
Nach außen hin erfolgt die Bereitstellung der Daten durch einen sogenannten RESTFul Webservice. Dabei wird für je eine aufzurufende
URL ein bestimmter Dienst geboten. Man spricht in diesem Zusammenhang auch von Ressourcen. Der Webservice ist mittels der JavaBibliothek Jersey [Jer] implementiert und bietet für die 3D-Clients
zwei Dienste an. Die Struktur der URLs für deren Aufruf stellt sich
wie folgt dar:
• http://SERVER-ADRESSE/CAD2Web/rest
• 1.) /getproducts
• 2.) /getProductX3D?productname=PRODUKTNAME
Die Ergebnisse werden, wie im Umfeld von Webservices üblich,
in Form von XML geliefert. Der erste Dienst übergibt auf Anfrage
eine Liste der im System enthaltenen Produkte. Der zweite gibt bei
Angabe eines Produktes das zugehörige aufbereitete Produktmodell
in Form von X3D zurück.
5.4 3d-client
Abbildung 18: Unity 3D-Webclient und Uploadformular
5.4
3d-client
Abbildung 18 zeigt die grafische Schnittstelle des Systems in Form
eines HTML-Formulares für den Upload der Produktmodelle und
ebenfalls die 3D-Webanwendung zur Präsentation dieser Inhalte. Das
Formular dient neben dem vereinfachten PLM-System als zweite Quelle zum Einspielen von Daten in das System. Der Kompaktheit halber
wird das Formular zusammen mit der 3D-Anwendung auf einer Seite
präsentiert. In einer Produktivumgebung würde entsprechend des in
Kapitel 4 beschriebenen Szenarios das Hinzufügen von Produktmodellen in einem geschützten Bereich durch einen Mitarbeiter erfolgen.
Die Implementierung des 3D-Clients ist mithilfe von Unity3D als
Webanwendung umgesetzt. Durch die Wahl dieser Technologie ist
es mit relativ geringem Aufwand möglich, die 3D-Anwendung auch
für andere Plattformen als den Webplayer zu portieren. Im Fokus
stehen dabei besonders Android und iOS als Betriebssysteme mobiler
Geräte.
Da dem Client die URL des CAD2Web-Servers bekannt ist, erfolgt
beim Start zunächst eine Abfrage der vorhandenen Produkte. Nach
dem Parsen der erhaltenen XML-Datei erfolgt die Darstellung der
Produkte in Form einer Liste. Die Produktmodelle selbst werden an
67
68
implementierung
x3d-knoten
beschreibung
Transform
Gruppierungsknoten für das Koordinatensystem der Kindknoten
IndexedFaceSet
Geometrie: Polygone als Vierecke
IndexedTriangleSet
Geometrie: Polygone als Dreiecke
Shape
beinhaltet Geometrie- und Materialknoten
Appearence
beinhaltet Oberflächenbeschreibungen
Material
beinhaltet numerische Werte für Shader
MetadataString
Name-Wert Paare zur Beschreibung von
X3D-Knoten
Tabelle 8: Durch den X3D Unity Parser unterstützte X3D-Knoten
X3D Unity Parser
nichtgeometrische
Informationen:
Produktbeschreibung und
Materialangaben
dieser Stelle jedoch nicht übertragen. Um die Ladezeit zu verringern
und Ressourcen nicht unnötig zu belasten, erfolgt dies erst bei der
Auswahl eines Produktes durch den Nutzer. Da das Herunterladen
und Parsen der Produktmodelle je nach Komplexität circa eine Sekunde bis mehrere Dutzend Sekunden in Anspruch nimmt, wird dem
Nutzer nur Wartezeit für Produkte abverlangt, die für ihn relevant
sind. Einmal geladen, bleiben die Modelle im Speicher der Webanwendung und erscheinen bei erneuter Auswahl sofort.
Zur Anzeige der Geometrie ist ein mapping von X3D auf die interne Datenstruktur von Unity nötig. Die Recherche zeigte, dass diese
Funktionalität zum Zeitpunkt der Durchführung dieser Arbeit weder
durch die Unity-eigenen Entwicklungswerkzeuge, noch durch Skripte von Dritten verfügbar ist. Daher wurde zum Einlesen von X3D-Inhalten zur Laufzeit ein eigener Parser entwickelt.
Tabelle 8 zeigt die unterstützten X3D-Knoten. Diese stellen einen
Ausschnitt der in der Spezifikation von X3D definiten Knotenmenge dar. Der Parser deckt somit nicht die gesamten, sondern die für
diesen Anwendungsfall relevanten Inhalte dieses Standards ab.
Bezüglich nichtgeometrischer Informationen werden vom 3D-Client
Beschreibungen der Produkte und Angaben zu den Materialien – beziehungsweise Werkstoffen – der Baugruppen und Teile unterstützt.
Sobald ein Produkt ausgewählt ist, erscheint dessen textuelle Beschreibung oberhalb der Produktliste, sofern diese in den Quelldaten vorhanden ist.
Durch Angabe des Werkstoffs, aus dem ein Teil besteht, lässt sich
durch die 3D-Anwendung ein passender Shader auf das 3D-Objekt
anwenden und diesem damit spezielle optische Eigenschaften zuweisen. Zu diesem Zweck ist eine Materialbibliothek vorhanden, welche
5.5 zusammenfassung
die Eigenheiten verschiedener Werkstoffe bezogen auf deren Darstellung beinhaltet. Einem Teil kann eine Materialgruppe zugewiesen
sein, wodurch für das betreffende Objekt ein spezieller Shader und
bestimmte optische Eigenschaften, wie die Größe von Glanzpunkten,
gesetzt werden. Der Prototyp unterstützt die Gruppen Metall, Plastik,
Gummi und Glas. Die Zuweisung der Farbe wird in diesen Fällen aus
den Quelldaten übernommen, die üblicherweise in den CAD-Anwendungen bei der Erstellung der Geometrie gesetzt werden.
Neben den Materialgruppen ist auch die Anwendung konkreter
Materialien auf Teile möglich. Dies ist exemplarisch für die Materialien Aluminium, Kupfer und Gold umgesetzt. Bei der Beschreibung
eines Bauteils mit diesen Materialien wird neben dem entsprechenden Shader ein vordefinierter Farbwert für das 3D-Objekt gesetzt.
Für den Fall, dass in den Produktmodellen keine solche Angaben
über die Werkstoffe enthalten sind, kommt ein festgelegter Shader
zur Anwendung und die Farbinformationen werden den Quelldaten
entnommen.
5.5
zusammenfassung
Die prototypische Implementierung setzt die wichtigsten Teile des
Konzeptes aus Abschnitt 4.3 in Form von drei Teilsystemen um. Zur
Simulation des PLM-Systems auf der Eingangsseite kommt ein Webserver zum Einsatz. Weiterhin können dem System Produktmodelle
über ein Upload-Formular hinzugefügt werden.
Die Verarbeitung der Daten basiert auf einer serverseitigen Java-Anwendung, die vorhandene Softwarewerkzeuge und Bibliotheken integriert. Geometrische Teile werden mittels Autodesk 3ds Max und CyberX3D for Java verarbeitet. Für die Aufbereitung nichtgeometrischer
Produktdaten kommen JSDAI und die Java API zur XML-Verarbeitung
zum Einsatz. Nach außen werden REST-basierte Dienste angeboten,
um die aufbereiteten Produktmodelle für Clientanwendungen nutzbar zu machen.
Ein solcher 3D-Client wurde mithilfe der Unity3D-Technologie implementiert, um die Darstellung geometrischer und nichtgeometrischer Informationen im Web zu demonstrieren.
69
6
A U S W E RT U N G
6.1
fazit
Um die Ergebnisse der digitalen Produktentwicklung für 3D-Anwendungen besser nutzbar zu machen, wurde ein Konzept entwickelt,
welches eine Softwareunterstützung für die Aufbereitung der Daten
vorsieht.
Als Anforderungsanalyse für eine mögliche Lösung, wurde das
Problemfeld mit den Anforderungen zum einen an den Aufbereitungsprozess und zum anderen an die 3D-Anwendung zur Darstellung der verarbeiteten Produktmodelle untersucht. Weiterhin konnten Aufgaben identifiziert werden, die innerhalb der Produktmodellaufbereitung durchzuführen sind, um die Quelldaten in der gewünschten Weise nutzen zu können.
Die Recherche identifizierte STEP als besonders relevantes Format
für die Eingangsseite eines Verarbeitungsprozesses. Dessen Nutzung
erlaubt potenziell eine sehr umfangreiche Beschreibung von Produkten deutlich über bloße Geometrien hinaus. Um das Potenzial dieses
Standards für die vorliegende Aufgabe zu erkennen, wurde er näher
untersucht. Der Fokus lag dabei besonders auf möglichen Inhalten
von Produktmodellen.
Das Konzept zur Lösung der identifizierten Aufgaben im Rahmen
der Produktmodellaufbereitung schlägt im Kern eine Kombination
aus automatischer Verarbeitung und einer händischen Nachbearbeitung vor. Aus der Betrachtung themenverwandter wissenschaftlicher
Arbeiten geht hervor, dass für eine Softwarelösung eine dreischichtige Architektur nach dem Client/Server-Prinzip mit Fokus auf Serviceorientierung sinnvoll ist.
Für die Lösung der gestellten Aufgaben zeigte sich eine Integration bestehender Werkzeuge als vielversprechender Weg. Eine eigene Implementierung sämtlicher benötigter Funktionalitäten scheint
mit vertretbarem Aufwand nicht realisierbar zu sein. Daher wurden
vorhandene Softwarewerkzeuge und -bibliotheken recherchiert und
vorgestellt: Zum einen jene zur Bearbeitung der Aufgaben im Rahmen des Aufbereitungsprozesses und zum anderen Technologien zur
Darstellung der Produkte in einer 3D-Anwendung mit Fokus auf der
webbasierten Präsentation.
In diesem Zusammenhang stellte sich heraus, dass eine Trennung
der Verarbeitung geometrischer Daten und nichtgeometrischer Daten
nötig ist. Der Grund dafür ist im Mangel an verfügbaren Werkzeugen
zu sehen, die in der Lage sind, beide Typen von produktbezogenen
71
72
auswertung
Informationen, in der für den vorliegenden Anwendungsfall, geeigneten Weise zu verarbeiten.
Insgesamt wird die Nutzung von standardisierten und weit verbreiteten Formaten zur Repräsentation und Verarbeitung der Produktmodelle empfohlen. Neben STEP als Quellformat auf Seiten der Industrie,
sollten Formate auf Basis von XML zum Einsatz kommen. Für die
Darstellung der aufbereiteten Modelle empfiehlt sich besonders X3D
aufgrund weit verbreiteter Werkzeuge und der guten Integration im
Kontext des Web.
Zur Demonstration der Umsetzbarkeit des entwickelten Lösungskonzeptes dient ein Prototyp in Form einer Serveranwendung und
eines 3D-Clients. Darüber hinaus wird die Anbindung eines PLM-Systems als Datenquelle auf Seiten der Industrie simuliert.
Die in Java umgesetzte Serverapplikation integriert mehrere bestehende Softwarekomponenten mit dem Ziel der Verarbeitung und Bereitstellung geometrischer und nichtgeometrischer Produktinformationen. Neben der Abarbeitung definierter Aufgaben und der Verwaltung der zum System hinzugefügten Produktmodelle, werden die Ergebnisse der Aufbereitung durch einen Webservice nach außen zur
Verfügung gestellt.
Die Demonstration der Nutzung von verarbeiteten Produktdaten
veranschaulicht ein mittels Unity3D implementierter 3D-Client zur
Ausführung im Browser. Dieser präsentiert neben den geometrischen
Informationen auch zusätzliche Beschreibungen und verarbeitet Angaben zum Werkstoff einer Baugruppe oder eines Bauteils resultierend in einer entsprechenden Darstellung.
Zusammenfassend zeigt die Arbeit Möglichkeiten einer optimierten Aufbereitung von Produktmodellen durch den Einsatz vorhandener Werkzeuge in einem automatisierten Prozess auf. Dadurch wird
im Besonderen der manuelle Aufwand bei der Abwicklung großer
Mengen von Produktmodellen reduziert und die Umsetzung größerer Projekte zur Visualisierung von Industrieprodukten erleichtert.
6.2
ausblick
Bezüglich des vorgestellten Konzeptes und der prototypischen Implementierung bieten sich verschiedene Ansatzpunkte zur Weiterentwicklung an. Diese betreffen zum einen die Erweiterung der Funktionalität, und zum anderen Optimierungen der Ausführungsgeschwindigkeit und der Darstellungsqualität.
erweiterung der funktionalität Um den Prototypen zu einem Produktivsystem auszubauen, ist es sinnvoll, die Schnittstellen
zu verfeinern und zu erweitern. Dazu gehört die Anbindung eines
konkreten PLM-Systems auf der Eingangsseite, wie auch zusätzliche
6.2 ausblick
Webservices auf der Ausgangsseite der Serveranwendung. Die Abdeckung zusätzlicher Inhalte von Produktmodellen und deren Auslieferung, in Form von kompakten Informationspaketen, führt darüber
hinaus zu einer größeren Breite an möglichen Anwendungsszenarien
der vorgestellten Lösung.
Für die Verwaltung der aufbereiteten Daten ist weiterhin die Implementierung einer grafischen Schnittstelle des CAD2Web-Servers sinnvoll. Somit wäre zur Unterstützung der manuellen Nachbearbeitung
ein Freigabemechanismus umsetzbar. Produkte werden zur Anzeige
für den Nutzer in diesem Szenario erst nach manueller Prüfung freigeschaltet. In diesem Zusammenhang bietet sich auch die Implementierung von Zugriffsrechten und die Anbindung an eine Datenbank
zur Sicherung der Produktmodelle an.
Neben den genannten funktionalen Erweiterungen der Anwendung
zur Verarbeitung der Produktmodelle liegt auch eine Verbesserung
der Robustheit und Fehlertoleranz nahe. Der Einsatz externer Werkzeuge kann zu unerwartetem Verhalten und zu Ausnahmen führen,
die nicht zum Versagen des Dienstes insgesamt führen dürfen.
Potenzial besteht ebenfalls in der Unterstützung der manuellen
Nachbearbeitung von Produktmodellen, indem DCC-Werkzeuge wie
3ds Max oder Cinema 4D eng in den Prozess integriert werden. Durch
die Möglichkeit Plugins für diese Anwendungen zu entwickeln bietet
sich eine Funktionalität zur Synchronisation mit dem Datenbestand
des CAD2Web-Servers an. So könnten die Auswirkungen von Änderungen, etwa der Reduktion der Komplexität geometrischer Objekte, direkt im 3D-Client zur Präsentation der Produkte nachvollzogen
werden.
Im Hinblick auf den prototypisch umgesetzten 3D-Client ist eine
Erweiterung der Funktionalität in folgenden Punkten erstrebenswert.
Um eine authentischere Materialanmutung der Teile und Baugruppen zu erzielen bietet sich der Ansatz an, abhängig vom definierten
Werkstoff neben den Shadern und deren Parametern auch Texturen
automatisch zuzuweisen. In diesem Zusammenhang kann die Möglichkeit betrachtet werden, die Abbildung von Texturen auf Geometriekörper durch ein sogenanntes Cube- oder Sphere-Mapping als Alternative zum händischen UV-Mapping durchzuführen. Für die Erweiterung der grafischen Benutzungsschnittstelle des 3D-Clients bieten sich zum einen die Anzeige von beschreibenden Informationen
direkt am Objekt an und zum anderen die Darstellung der Produktstruktur.
Um vergleichende Aussagen für unterschiedliche 3D-Technologien
für das vorliegende Anwendungsszenario zu treffen, ist die Implementierung weiterer prototypischer 3D-Clients zu empfehlen. Besonders die Umsetzung einer Anwendung auf Basis von WebGL ist interessant, um Erkenntnisse bezüglich der Performanz beim Hinzufügen
73
74
auswertung
von Inhalten zur Laufzeit sowie der Effizienz der Entwicklung zu
gewinnen.
optimierung der performanz Im Bereich der Performanz der
Lösung bieten sich ebenfalls Punkte für weitergehende Arbeiten. Diese betreffen sowohl die Software zur Verarbeitung, als auch jene für
die Darstellung der Produktmodelle.
Im Hinblick auf die Verarbeitung der Produktdaten auf dem Server besteht Optimierungspotenzial, um sowohl die Verarbeitungsgeschwindigkeit, als auch die Größe der resultierenden Produktmodelle
zu verbessern. Neben der Optimierung des Java-Codes der prototypischen Implementierung selbst, bestehen ebenfalls Möglichkeiten, die
zum Teil quelloffenen Java-Bibliotheken zur Datenverarbeitung anzupassen. Dadurch lässt sich unter anderem die Erzeugung von kompakteren Ausgabedaten realisieren.
Zur Verbesserung der Ausführungsgeschwindigkeit und zur Verkürzung von Ladezeiten wird der Einsatz von Methoden zur Kompression und zum Streaming nahegelegt. Die Kompression von Inhalten bietet sich dabei für geometrische wie auch nichtgeometrische
Produktinformationen an. Als externes Kompressionsformat bietet
sich beispielsweise ZIP an. Für dieses offene Format gibt es eine Vielzahl von Implementierungen zur Kompression und Dekompression.
Für die Geometrie existieren Datenformate, welche die Komprimierung der Inhalte direkt unterstützen. Dazu gehören unter anderem JT
und X3D-binary.
Die Implementierung von progressivem Streaming von binären Geometriedaten kann darüber hinaus helfen, die User-Experience deutlich zu verbessern. In diesem Fall muss kaum mehr auf die Übertragung von Daten gewartet werden. Geometrische Objekte können mit
dieser Technik sofort angezeigt werden und unterliegen anschließend
einer zunehmenden Verfeinerung.
75
76
A
anhang
ANHANG
domäne, nr.
name
Mechanisches
Design
AP 201
Explicit draunting
AP 202
Associative draughting
AP 203
Configuration-controlled 3D designs of mechanical parts and assemblies
AP 204
Mechanical design using boundary representation
AP 207
Sheet metal die planning and design
AP 209
Composite and metal structural analysis and related design
AP 214
Core data for automotive mechanical design processes
AP 235
Materials information for the design and verification of products
AP 236
Furniture product data and project data
AP 242
Managed model based 3d engineering
Elektronik
AP 210
Electronic assembly, interconnect and packaging
design
AP 212
Electrotechnical design and installation
AP 227
Plant spatial configuration
Schiffbau
AP 215
Ship arrangement
AP 216
Ship moulded forms
AP 218
Ship structures
Fertigung
AP 219
Dimensional inspection information exchange
AP 223
Exchange of design and manufacturing product
information for cast parts
AP 224
Mechanical product definition for process plans
using machining features
AP 238
Application interpreted model for computer numeric controllers (NC)
AP 240
Process plans for machined products
anhang
domäne, nr.
name
Life cycle support
AP 239
Product Life-cycle support
AP 221
Functional data and schematic representation of
process plants
AP 241
Generic Model for Life Cycle Support of AEC Facilities
Weitere
AP 235
Building elements using explicit shape representation
AP 232
Technical data packaging core information and
exchange
AP 233
Systems engineering data representation
AP 237
Fluid dynamics
Tabelle 9: Anwendungsprotokolle (AP) der Normenreihe ISO 10303 (STEP)
77
78
anhang
gruppe, name
inhalt
Oberflächenbeschaffenheit
surface_condition
Oberflächeneigenschaften
Zeichnungen
explicit_draughting
Zeichnungsannotationen
associative_annotation
Beziehungen von Zeichnungsannotationen
Externe Referenzen
external_reference_mechanism
externe Dokumente
Formmerkmale
user_defined_feature
Nutzerdefinierte
gen
Beschreibun-
included_feature
Beschreibung von Formen
generative_featured_shape
parametrisierte Formen
Geometrie
wireframe_model_2d
2D-Punkte, -Kurven
wireframe_model_3d
3D-Drahtgitter Grundkörper
connected_surface_model
3D-Kurven
faceted_b_rep_model
3D-Hüllgeometrie
b_rep_model
3D-Hüllgeometrie mit Kurven
und Topologie
compound_model
3D-Verbundmodell
csg_model
3D-Volumenmodell
geometrically_bounded_surface_model
3D-Grundgeometrieobjekte
anhang
gruppe, name
inhalt
Kinematik
kinematics
Kinematiksimulation
Messdaten
measured_data
Messdaten
Produkteigenschaften
item_property
Objekteigenschaften
Darstellung
geometric_presentation
Geometriedarstellung
annotated_presentation
Annotationsdarstellung
shaded_presentation
Lichtquellen
Produktstruktur
product_management_data
Produktmanagement
element_structure
Objektstrukturierungen
item_definition_structure
Objektbeziehungen
effectivity
Zeitspannen
work_management
Projektmanagement
classification
Kategorien von Objekten
specification_control
Variantenmanagement
process_plan
Prozessinformationen
Toleranzen
dimension_tolerance
absolute Toleranzen
geometric_tolerance
relative Toleranzen
Tabelle 10: Units of Functionality (UoF) des AP 214 der Normenreihe ISO
10303 (STEP)
79
B
GLOSSAR
Ajax
(Asynchronous JavaScript and XML) Konzept zur asynchronen Datenübertragung
zwischen Webserver und Browser; Webseite muss nicht mehr für jede Interaktion
komplett neu geladen werden . 30, 31
API
(Application
Programming
Interface)
Schnittstelle von Programmbibliotheken
oder Programmteilen zu deren Nutzung
in anderen Anwendungen . 20, 21, 28, 29,
31, 60, 69
CAD
(Computer Aided Design) Methode des
Konstruierens eines Produktes mithilfe
elektronischer Datenverarbeitung . 10, 12,
14, 17, 24, 27–29, 39–41, 44–47, 50, 69
CAE
(Computer Aided Engineering) Der breite
Einsatz computergestützter Technik im Ingeneurwesen. CAD und CAM sind Teil davon . 12
CAM
(Computer Aided Manufacturing) Einsatz
von Software zur Steuerung von Maschinen bei der Herstellung von Werkstücken
. 12, 39
CORBA
(Common Object Request Broker Architecture) Standard zur Kommunikation von
Softwarekomponenten zwischen verschiedenen Computern; Ermöglicht Zugriff auf
Softwareobjekte in entfernten Adressräumen; Übertragung per TCP/IP Protokoll .
27, 52, 55
DCC
(Digital Content Creation) Bezeichnet die
Erstellung und Modifikation digitaler Inhalte; Hauptsächlich auf Erzeugung multimedialer Inhalte bezogen: Animation, Audio, Grafik, Video . 46, 58, 73
81
82
Glossar
DCOM
(Distributed Component Object Model)
Technologie von Microsoft zur Kommunikation von Anwendungen im Netzwerk;
Erweiterung des Component Object Model (COM) zur Interprozesskommunikation; Abgelöst durch Windows Communication Foundation (WCF) . 28, 52
GUI
(Graphical User Interface) Benutzungsschnittstelle zur grafischen Interaktion mit
elektronischen Geräten (Computern) anstelle klassischer Steuerung mittels Textkommandos . 53
HPC
(High Performance Computing) Bereich
des computergestützten Rechnens; Nutzung erheblicher Ressourcen an Rechentechnik zur Bearbeitung einer Aufgabe; Üblicherweise Einsatz von Supercomputern .
31
HTML
(Hypertext Markup Language) Wichtigste Beschreibungssprache von Inhalten im
WWW zur Darstellung im Web-Browser .
20, 30, 31, 60, 67
HTTP
(Hypertext Transfer Protocol) Übertragungsprotokoll auf Anwendungsebene
zum Datenaustausch im WWW; Setzt auf
TCP/IP Protokolle auf . 32, 54, 59, 60, 63,
65
JSON
(JavaScript Object Notation) Format
zum Austausch von Daten in JavaScriptNotation; Mensch- und Maschinenlesbar;
Kompakter und einfacher als XML aber
weniger vielseitig . 47
NURBS
(Non-Uniform Rational B-Spline) Mathematisches Modell zur Repräsentation
kurviger Oberflächen; Haupteinsatzgebiet:
Computergrafik; Präzise Beschreibung von
Oberflächen bei wenigen Kontrollpunkten
. 41, 42
Glossar
OpenGL
(Open Graphics Library) Standard zur
Spezifikation
einer
plattformund
programmiersprachenunabhängigen
API zur Entwicklung von 2D- und 3DGrafikanwendungen; Alternative: DirectX
(Microsoft) . 20, 21
Parser
Computerprogramm zur Zerlegung und
Umwandlung einer Eingabe in ein für die
Weiterverarbeitung brauchbares Format .
68
Produktkonfiguration
Beschreibt das Zusammensetzen eines
Produktes aus vorgegebenen Produktkomponenten (Selektion und Kombination)
und die Selektion inhaltlicher Ausprägungen der Komponenteneigenschaften
(Parametrisierung)
unter
Einhaltung
der Konfigurationsregeln; Konfigurationsmöglichkeiten ergeben sich aus den
Selektions-, Kombinations- und Parametrisierungsmöglichkeiten eines Produktes
eingeschränkt durch die Konfigurationsregeln [Sch06, S. 41]. 2
Produktkonfigurator
Multifunktionales, rechnergestütztes System ausgestattet mit grafischen Benutzungsschnittstelle; Leitet Kunden oder Vertriebsmitarbeiter durch den Prozess der
Produktkonfiguration; Steht als Bindeglied
zwischen Produktentwicklung, Fertigung
und Kundenwünschen. 1
REST
(Representational State Transfer) Programmierparadigma für Webanwendungen und
Webservices; Idee: eine URL repräsentiert
das Ergebnis einer serverseitigen Aktion;
Einfacher als SOAP und WSDL . 53, 69
RFC
(Remote Function Call) Schnittstelle zur
Kommunikation von SAP-Systemen untereinander oder mit Drittanwendungen . 54
RMI
(Remote Method Invocation) Java-API für
den objektorientierten Aufruf von Methoden zwischen Softwarekomponenten im
Netzwerk . 28, 52
83
84
Glossar
SDK
(Software Development Kit) Sammlung
von Werkzeugen zur Softwareentwicklung
für eine bestimmte Plattform . 27
Shader
Computerprogramme zur Berechnung von
Beleuchtungseffekten in der Computergrafik . 68, 69
SOA
(Service-Oriented Architecture) Prinzipien
und Methoden der Softwareentwicklung;
Ziel: Erzeugung von Softwarekomponenten als lose gekoppelte interoperable Dienste; Komponenten stellen wohldefinierte
und bekannte Funktionalitäten nach außen
bereit . 27, 53
SOAP
(Simple Object Access Protocol) Ein auf
XML basierendes Protokoll zum Austausch
strukturierter Informationen im Kontext
von Webservices; Üblicherweise Nutzung
von HTTP als Übertragungsprotokoll auf
Anwendungsebene . 28, 53
UML
(Unified Modeling Language) AllzweckModellierungssprache im Bereich der
objektorientierten
Softwareentwicklung;
Stellt Diagrammtypen zur Beschreibung
von Struktur und Verhalten von Software
bereit . 49–52
URL
(Uniform Resource Locator) Zeichenkette zur Adressierung von Ressourcen im
WWW . 55, 63, 66, 67
VPE
(Virtuelle
Produktentstehung)
Durchgehende Rechnerunterstützung bei der
Produkt- und Produktionsentwicklung;
Intensive Anwendung von Simulations-,
Validierungs-, und Verifikationstechniken
auf Basis digitaler realitätsnaher Modelle;
Ziel: frühere Erarbeitung des Produktund Produktionswissens, frühzeitiges
Erkennen von Produkteigenschaften, Reduzierung physischer Prototypen [ES09, S.
48]. 6
VR
(Virtual Reality) Simulation von realen
oder künstlichen Umgebungen mittels immersiven 3D-Technologien; Oft unter Einsatz stereoskopischer Displays . 25
Glossar
VRML
(Virtual Reality Modeling Language) Standardisiertes Dateiformat zur Repräsentation 3-dimensionaler Inhalte; Entwickelt für
den Einsatz im WWW; Nachfolger: X3D .
19, 46, 66
WS
(Web Service) Softwareanwendung zur
Kommunikation mit anderen SoftwareAgenten unter Verwendung XML-basierter
Nachrichten und unter Nutzung internetbasierter Protokolle; Dienst ist durch Uniform Resource Identifier (URI) eindeutig
identifizierbar . 53
WSDL
(Web Services Description Language)
XML-basierte Sprache zur Beschreibung
von Funktionen, Daten, Datentypen und
Austauschprotokollen von Webservices .
28
X3D
(Extensible 3D) XML-basiertes Dateiformat
zur Repräsentation 3-dimensionaler Inhalte; Unter anderem inhaltliche Erweiterung
von VRML . 30, 31, 46, 47, 59, 60, 66, 68, 72,
74
XML
(Extensible Markup Language) MetaAuszeichnungssprache zur Repräsentation
hierarchisch strukturierter Daten in Textform; Ermöglicht Definition anwendungsspezifischer Sprachen; Weite Verbreitung
im Internet . 14, 28, 29, 47, 54, 55, 58–60,
63, 66, 67, 69, 72
XSLT
(Extensible Stylesheet Language Transformation) Programmiersprache zur Transformation von XML-Dokumenten; Basiert
selbst auf XML; Teil der Extensible Stylesheet Language (XSL) zur Definition von
Layouts von XML-Dokumenten . 58
85
L I T E R AT U R V E R Z E I C H N I S
[3ds] Autodesk, Inc.: Autodesk 3ds Max Website. http://www.
autodesk.de/3dsmax. – abgerufen am 26.07.2012
[And00] Anderl, Reiner [.: STEP : standard for the exchange of product model data ; eine Einführung in die Entwicklung, Implementierung und industrielle Nutzung der Normenreihe ISO
10303 (STEP). Stuttgart ; Leipzig : Teubner, 2000. – ISBN
3–519–06377–8
[BDP07] Ball, Alexander ; Ding, Lian ; Patel, Manjula:
Lightweight Formats for Product Model Data Exchange and Preservation / UKOLN, University of
Bath.
Version: 2007.
http://homes.ukoln.ac.uk/
~ab318/eprints/PV2007_Ball_Paper.pdf. 2007. – Forschungsbericht
[Ben] Benedetto, Marco D.: SpiderGL Website.
spidergl.org/. – abgerufen am 07.08.2012
http://
[BFS10] Beckers, Raphael ; Fröhlich, Arnulf ; Stjepandic,
Josip:
Anwendung und Potenziale universeller Visualisierungsformate / ProSTEP AG.
Version: 2010.
http://www.transmechatronic.de/uploads/tx_
vitramemberadmin/literature/Anwendung_und_
Potenziale_universeller_Visualisierungsformate.
pdf. 2010. – Forschungsbericht
[Ble] Blender Foundation:
Blender Website.
blender.org. – abgerufen am 07.08.2012
http://www.
[CADB+ 10] Callieri, Marco ; Andrei, Raluca M. ; Di Benedetto,
Marco ; Zoppè, Monica ; Scopigno, Roberto: Visualization methods for molecular studies on the web platform.
In: Proceedings of the 15th International Conference on Web
3D Technology. New York, NY, USA : ACM, 2010 (Web3D
’10). – ISBN 978–1–4503–0209–8, 117–126
[Cat] Dassault Systemes Deutschland GmbH: Catia Website.
http://www.3ds.com/de/products/catia/. – abgerufen
am 17.08.2012
[CCW06] Chu, Chih-Hsing ; Cheng, Ching-Yi ; Wu, Che-Wen:
Applications of the Web-based collaborative visualization in distributed product development. In: Computers in Industry 57 (2006), Nr. 3, 272 - 282. http://
87
88
literaturverzeichnis
dx.doi.org/10.1016/j.compind.2005.12.004. –
DOI
10.1016/j.compind.2005.12.004. – ISSN 0166–3615
[CLG06] Chen, Xiang ; Li, Min ; Gao, Shuming: A Web Service
for Exchanging Procedural CAD Models Between Heterogeneous CAD Systems. Version: 2006. http://dx.doi.
org/10.1007/11686699_23. In: Shen, Wei-ming (Hrsg.)
; Chao, Kuo-Ming (Hrsg.) ; Lin, Zongkai (Hrsg.) ; Barthès, Jean-Paul (Hrsg.) ; James, Anne (Hrsg.): Computer
Supported Cooperative Work in Design II Bd. 3865. Springer
Berlin / Heidelberg, 2006. – ISBN 978–3–540–32969–5,
225-234
[COL] COLLAVIZ Website. http://www.collaviz.org/. – abgerufen am 07.08.2012
[Cyb] Satoshi
Konno:
CyberX3D
for
Java
Website.
http://www.cybergarage.org/twiki/bin/view/Main/
CyberX3DForJava. – abgerufen am 31.08.2012
[DBM+ 07] Ding, Lian ; Ball, Alexander ; Matthews, Jason ; McMahon, Christopher A. ; Patel, Manjula: Product Representation in Lightweight Formats for Product Lifecycle Management (PLM). In: Representations (2007), Nr.
September, 19 – 21. http://opus.bath.ac.uk/12768/
[ES09] Eigner, Martin ; Stelzer, Ralph: Product Lifecycle Management : ein Leitfaden für Product Development und Life
Cycle Management. 2., neu bearb. Aufl. Berlin ; Heidelberg : Springer, 2009. – ISBN 3–540–44373–8
[FG08] Frey, Pascal J. ; George, Paul L.: Mesh generation / application to finite elements. 2. ed. London : ISTE [u.a.], 2008.
– ISBN 9781848210295
[FL05] Fuh, JYH ; Li, WD: Advances in collaborative CAD:
the-state-of-the art. In: Computer-aided design 37 (2005),
04, Nr. 5, 11. http://www.sciencedirect.com/science/
article/pii/S0010448504001575. ISBN 0010–4485
[Fro11] Froehlich, Arnulf: 3D-Formate im Engineering-Umfeld
- ein Vergleich. (2011), 04. http://www.pdfgenerator3d.
com/nc/de/produkt/whitepaper.html
[GLG] GLGE Website. http://www.glge.org/. – abgerufen am
26.07.2012
[Goo12] Good Technology, Inc.: Good Technology Device Activations Report - Q1 2012. http://media.www1.good.com/
documents/Good_Data_Q1_2012.pdf. Version: 2012
literaturverzeichnis
[Gro11] Grosso, William: Java RMI. O’Reilly Media, 2011 http:
//slub.eblib.com/patron/FullRecord.aspx?p=769348.
– ISBN 9781449315900
[Hei] Heinfling, Benjamin:
Test: HTC One X.
http:
//www.chip.de/artikel/HTC-One_X-Handy-Test_
55411079.html. – veröffentlicht am 13.04.2012, abgeru-
fen am 17.08.2012
[HS07] Hartmann, Gerd ; Schmidt, Ulrich: Product lifecycle management with SAP / the complete guide to mySAP PLM strategy, technology and implementation. 1. ed., repr. Bonn
[u.a.] : Galileo Press, 2007. – ISBN 9781592290369
[Jer] Jersey Website. http://jersey.java.net/. – abgerufen
am 01.09.2012
[JSD] LKSoftWare GmbH: JSDAI Website. http://www.jsdai.
net. – abgerufen am 24.07.2012
[KMH10] Kim, Byung ; Mun, Duhwan ; Han, Soonhung: Retrieval of CAD model data based on Web Services for collaborative product development in a distributed environment. In: The International Journal of Advanced Manufacturing Technology 50 (2010), Nr. 9-12, 1085-1099. http:
//dx.doi.org/doi:10.1007/s00170-010-2571-0. – DOI
doi:10.1007/s00170–010–2571–0
[Kon07] Produktkonfiguration - auch sinnvoll für den Mittelstand? In: Konstruktion : Zeitschrift für Produktentwicklung
und Ingenieur-Werkstoffe 59 (2007), Nr. 11/12, S. 19–21
[Mel10] Melzer, Ingo: Service-orientierte Architekturen mit Web
Services / Konzepte - Standards - Praxis. 4. Aufl. Heidelberg
: Spektrum-Akad.-Verl., 2010. – ISBN 9783827425492
[MLL+ 10] Maglo, Adrien ; Lee, Ho ; Lavoué, Guillaume ; Mouton, Christophe ; Hudelot, Céline ; Dupont, Florent:
Remote scientific visualization of progressive 3D meshes
with X3D. In: Proceedings of the 15th International Conference on Web 3D Technology. New York, NY, USA : ACM,
2010 (Web3D ’10). – ISBN 978–1–4503–0209–8, 109–116
[MPMS98] Männistö, Tomi ; Peltonen, Hannu ; Martio, Asko
; Sulonen, Reijo: Modelling generic product structures
in STEP. In: Computer-Aided Design 30 (1998), Nr. 14, 1111
- 1118. http://dx.doi.org/10.1016/S0010-4485(98)
00067-0. – DOI 10.1016/S0010–4485(98)00067–0. – ISSN
0010–4485
89
90
literaturverzeichnis
[MSG11] Mouton, Christophe ; Sons, Kristian ; Grimstead, Ian:
Collaborative Visualization: Current Systems and Future
Trends, 2011
[NKB10] Niebling, Florian ; Kopecki, Andreas ; Becker, Martin:
Collaborative steering and post-processing of simulations on HPC resources: everyone, anytime, anywhere. In:
Proceedings of the 15th International Conference on Web 3D
Technology. New York, NY, USA : ACM, 2010 (Web3D
’10). – ISBN 978–1–4503–0209–8, 101–108
[Nur09] Nurcahya, Erwin Z.: Ein Produktdatenmodell für das rechnerunterstützte Variantenmanagement. Aachen : Shaker,
2009. – ISBN 978–3–8322–8309–4
[NX] Siemens Industry Software GmbH & Co. KG: NX Website. http://www.plm.automation.siemens.com/de_de/
products/nx/. – abgerufen am 17.08.2012
[OnL] OnLive, Inc.: OnLive Website. https://www.onlive.com.
– abgerufen am 06.08.2012
[Pol] Okino Computer Graphics, Inc.:
PolyTrans Website.
http://www.okino.com/conv/conv.htm. – abgerufen am
26.07.2012
[Proa] Parametric Technology Corporation: Creo Parametric
(ehemals Pro/ENGINEER) Website. http://www.ptc.com/
product/creo/parametric. – abgerufen am 17.08.2012
[Prob] ProSTEPiViP:
step-ap-242.html.
http://www.prostep.
org/de/projekte/step-ap-242.html. –
abgerufen am
09.08.2012
[Red97] Redmond, Frank E.: DCOM / Microsoft Distributed Component Object Model. Foster City, CA [u.a.] : IDG Books
Worldwide, 1997. – ISBN 0764580442
[Sch06] Scheer, Christian: Kundenorientierter Produktkonfigurator
: Erweiterung des Produktkonfiguratorkonzeptes zur Vermeidung kundeninitiierter Prozessabbrüche bei Präferenzlosigkeit
und Sonderwünschen in der Produktspezifikation. Berlin :
Logos-Verl., 2006. – ISBN 3–8325–1392–2
[Scr06] Scra: STEP APPLICATION HANDBOOK ISO 10303
VERSION 3. In: North (2006), Nr. June
[SI08] Saaksvuori, Antti ; Immonen, Anselmi: Product Lifecycle
Management. Springer, 2008. – ISBN 9783540781721
[Sie96] Siegel, Jon: CORBA fundamentals and programming. New
York [u.a.] : Wiley, 1996. – 693 S. – ISBN 0471121487
literaturverzeichnis
[SLV08] Srinivasan, Vijay ; Lämmer, Lutz ; Vettermann, Steven: On Architecting and Implementing a Product Information Sharing Service. In: Journal of Computing
and Information Science in Engineering 8 (2008), Nr. 1, S.
011006. http://dx.doi.org/10.1115/1.2840775. – DOI
10.1115/1.2840775
[SPSS08] Stelzer, Ralph ; Petermann, DIrk ; Saske, Bernhard
; Steger, Wolfgang: Kollaborationsumgebung in einer
heterogenen CAD-VR Systemlandschaft. (2008)
[Staa] Flash Player Version Market Share and User Statistics.
http://www.statowl.com/flash.php. – abgerufen am
26.07.2012
[Stab] Adobe Systems, Inc.:
Stage 3D Website.
http://www.
adobe.com/devnet/flashplayer/stage3d.html. – abge-
rufen am 24.07.2012
[Sta05] Stark, John: Product Lifecycle Management : 21st Century
Paradigm for Product Realisation. Springer, 2005. – ISBN
9781846280672
[STD] STEP Tools Inc.:
ST-Developer Website.
http://
www.steptools.com/products/stdev/. – abgerufen am
11.09.2012
[STE] STEP Class Library Website.
https://github.com/
mpictor/StepClassLibrary. – abgerufen am 11.09.2012
[Thr] Three.js Github Repository. https://github.com/mrdoob/
three.js. – abgerufen am 26.07.2012
[Tom] Apache Software Foundation: Apache Tomcat Website.
http://tomcat.apache.org/. – abgerufen am 31.08.2012
[Uni] Unity Technologies: Unity3D Website. http://unity3d.
com/. – abgerufen am 24.07.2012
[Vö12] Völkl, Gerhard: 3D-Darstellungen im Webbrowser. In:
iX Kompakt: Webdesign (2012), 02, S. 110–111
[Vrm] VrmlMerge Website. http://www.deem7.com/. – abgerufen am 10.09.2012
[W3C] World Wide Web Consortium:
The WebSocket API
Working Draft - 24 Mai 2012. http://www.w3.org/TR/
websockets/. – abgerufen am 06.08.2012
[Wag09] Wagner, Otmar: Arbeitsheft zur Computeranimation zum Lehrplanbereich Kunst und Kommunikation.
(2009).
http://www.kunst-rs-bayern.de/userfiles/
Visuelle_Medien/AH-Computeranimation.pdf
91
92
literaturverzeichnis
[Weba] Khronos Group: WebGL Website. http://www.khronos.
org/webgl/. – abgerufen am 24.07.2012
[Webb] Web3D Consortium: X3D and Related Specifications. http:
//www.web3d.org/x3d/specifications/. –
abgerufen
am 06.08.2012
[WP11] Wilde, Erik ; Pautasso, Cesare: REST : From Research
to Practice. Springer Fachmedien, 2011 http://slub.
eblib.com/patron/FullRecord.aspx?p=799087. – ISBN
9781441983039
[X3D] Fraunhofer Institut für Grafische Datenverarbeitung
(IGD): X3DOM Website. http://www.x3dom.org/. – abgerufen am 23.07.2012
[XML] Universität des Saarlandes, Professur für Computergrafik: XML3D Website. http://www.xml3d.org/. – abgerufen am 23.07.2012
[YTD06] Yang, Xinhua ; Tang, Feilong ; Deng, Wu: Research
on a Generalized Die CAD System Architecture Based
on SOA and Web Service. Version: 2006. http://dx.
doi.org/10.1007/11610496_83. In: Shen, Heng (Hrsg.)
; Li, Jinbao (Hrsg.) ; Li, Minglu (Hrsg.) ; Ni, Jun (Hrsg.)
; Wang, Wei (Hrsg.): Advanced Web and Network Technologies, and Applications Bd. 3842. Springer Berlin / Heidelberg, 2006. – ISBN 978–3–540–31158–4, 625-631
[ZSG04] Zhang, Shusheng ; Shen, Weiming ; Ghenniwa,
Hamada:
A review of Internet-based product information sharing and visualization.
In: Computers in Industry 54 (2004), Nr. 1, 1 - 15. http://
dx.doi.org/10.1016/j.compind.2003.09.002. – DOI
10.1016/j.compind.2003.09.002. – ISSN 0166–3615