Universität Ulm
|
89069 Ulm
|
Germany
Fakultät für Ingenieurwis-
senschaften, Informatik
und Psychologie
Institut für Datenbanken und
Informationssysteme
Direktor: Prof. Dr. Manfred Reichert
Integration heterogener Produktdaten in
verteilten, komplexen Entwicklungsprozessen
Dissertation zur Erlangung des Doktorgrades Dr. rer. nat.
der Fakultät für Ingenieurwissenschaften, Informatik und Psychologie der Universität Ulm
Vorgelegt von:
Julian Tiedeken
aus Friesoythe
2018
Amtierender Dekan: Prof. Dr. Maurits Ortmanns
Gutachter: Prof. Dr. Manfred Reichert
Prof. Dr. Richard Lenz
Tag der Promotion: 17.07.2019
2
Inhaltsverzeichnis
I. Problembeschreibung und -analyse 13
1. Einleitung 15
1.1. Hintergrund....................................... 15
1.2. Problemstellung..................................... 16
1.3. Forschungsfragen.................................... 20
1.4. Beitrag ......................................... 22
1.5. Forschungsmethodik .................................. 22
1.6. Aufbau .......................................... 23
2. Grundlagen 25
2.1. DatenundInformationen ............................... 25
2.1.1. Evolutionvs.Versionierung.......................... 26
2.2. Produktentwicklung .................................. 26
2.2.1. ProduktundProduktdaten .......................... 26
2.2.2. Produktstruktur und -st¨
ucklisten ....................... 28
2.2.3. Systemlandschaft und Prozesse ........................ 29
2.3. Integration ....................................... 34
2.3.1. Terminologie .................................. 34
2.3.2. Klassifikation.................................. 38
2.3.3. Integrationsprozess . . . ............................ 38
2.3.4. Architekturen.................................. 39
2.3.5. Integrationsstrategien ............................. 40
2.3.6. Integrationskonflikte.............................. 41
2.4. Informationsqualit¨
at .................................. 45
2.4.1. Schemakonzeptqualit¨
at ............................ 45
2.4.2. Instanzqualit¨
at................................. 45
2.4.3. Produktdatenqualit¨
at ............................. 46
2.4.4. Integrationsqualit¨
at .............................. 46
3. Anforderungsanalyse 49
3.1. Literaturstudie ..................................... 49
3.2. ExplorativeUntersuchung............................... 52
3.2.1. Anwendungsfall 1: Integration elektrischer und geometrischer Komponenten 52
3.2.2. Anwendungsfall 2: Integration der vollst¨
andigen Produktentwicklung . . . 54
3.3. Anforderungen ..................................... 55
4. Stand der Technik 59
4.1. Heterogenit¨
at,Autonomie,Integration........................ 59
4.1.1. F¨
oderierteDatenbanksysteme......................... 59
3
Inhaltsverzeichnis
4.1.2. DataWarehouseSysteme ........................... 67
4.1.3. Peer-Daten-Management-Systeme ...................... 71
4.1.4. ToolIntegration ................................ 74
4.1.5. WeitereVorgehensweisen ........................... 77
4.2. Standards........................................ 78
4.2.1. Informationsmodellstandards ......................... 78
4.2.2. Inhaltsaustauschstandards........................... 79
4.2.3. Inhaltsstandards ................................ 79
4.2.4. Standards f¨
urdasKonfigurationsmanagement................ 86
4.2.5. Qualit¨
atsstandards............................... 87
4.2.6. AbgleichderAnforderungen.......................... 89
4.3. Zusammenfassung ................................... 91
II. L¨osungskonzepte 93
5. PROCEED-Rahmenwerk im ¨
Uberblick 95
5.1. LebenszysklusderProduktdatenintegration ..................... 95
5.2. Integration ....................................... 96
6. Integration heterogener Produktdaten 99
6.1. Projektvorbereitung .................................. 99
6.2. ManuelleSchemaintegration.............................. 100
6.2.1. Abbildung von Informationssystemen auf lokale Produktontologien .... 100
6.2.2. GlobaleProduktontologie ........................... 123
6.2.3. Abbildung lokaler Produktontologien auf eine globale Produktontologie . 126
6.2.4. MethodikenzurErstellunglokalerundglobalerProduktontologien.... 141
6.2.5. InitialesIntegrationsprojekt.......................... 144
6.3. AutomatischeInstanzintegration ........................... 151
6.3.1. InitialeIntegration............................... 151
6.4. ManuelleInstanzintegration.............................. 156
6.4.1. Aufgabe1:FehlendeKorrespondenzenerstellen............... 157
6.4.2. Aufgabe 2: Integrationskonflikte aufl¨
osen................... 159
6.4.3. Aufgabe 3: Fehlerhafte Korrespondenzen l¨
oschen .............. 159
7. Bestimmung der Integrationsqualit¨at 161
7.1. Vollst¨
andigkeitundKonsistenz ............................ 161
7.2. Metriken f¨
urlokaleProduktontologien ........................ 162
7.2.1. Lokale Schemakonzept-Vollst¨
andigkeit.................... 162
7.2.2. Lokale SCAR-Vollst¨
andigkeit ......................... 163
7.2.3. Lokale SCAA-Vollst¨
andigkeit ......................... 163
7.2.4. Kombination aus SCAR- und SCAA-Vollst¨
andigkeit ............ 164
7.2.5. Lokale Instanz-Vollst¨
andigkeit ........................ 164
7.3. Metriken f¨
urglobaleProduktontologien ....................... 165
7.3.1. Globale Schemakonzept-Vollst¨
andigkeit ................... 165
7.3.2. Globale Instanz-Vollst¨
andigkeit........................ 165
4
Inhaltsverzeichnis
7.3.3. Globale Instanzattribut-Vollst¨
andigkeit ................... 166
7.3.4. GlobaleInstanzattribut-Konsistenz...................... 167
7.4. Integrationsplanung und -¨
uberwachung........................ 168
8. Evolution integrierter Produktdaten 173
8.1. Ripple-Effekt ...................................... 174
8.2. Instanz¨
anderungen ................................... 176
8.2.1. Hinzuf¨
ugeneinerKorrespondenz ....................... 176
8.2.2. L¨
oscheneinerKorrespondenz ......................... 179
8.2.3. Hinzuf¨
ugeneinerInstanz ........................... 181
8.2.4. L¨
oscheneinerInstanz ............................. 182
8.2.5. L¨
oscheneinesAttributwertes ......................... 184
8.2.6. ¨
AnderneinesAttributwerts .......................... 187
8.3. Schema¨
anderungen ................................... 191
8.3.1. SCAA hinzuf¨
ugen ............................... 191
8.3.2. L¨
oscheneinerSCAA.............................. 192
8.3.3. ¨
Anderung einer SCAA ............................. 194
8.3.4. Hinzuf¨
ugeneinerSCAR ............................ 194
8.3.5. L¨
oscheneinerSCAR.............................. 196
8.3.6. ¨
Anderung einer SCAR ............................. 198
III. Evaluation 201
9. Proof-of-Concept Implementierung 203
9.1. PROCEEDSystemarchitektur ............................ 203
9.2. Grundlagen ....................................... 205
9.3. Realisierung der L¨
osungskonzepte........................... 209
9.3.1. Metaproduktontologie ............................. 209
9.3.2. Abbildung einer Produktontologie ...................... 216
9.3.3. Abbildung des Produktontologie-Mappings ................. 220
9.3.4. SicherstellungderstrukturellenKonsistenz ................. 222
9.3.5. Realisierung von Integrationsqualit¨
atsmetriken ............... 224
9.3.6. Realisierung des Integrationsalgorithmus sowie der ¨
Anderungsoperationen 225
10.Fallstudie 229
10.1. Abgleich von St¨
ucklisten mit PROCEED ....................... 229
10.1.1.Motivation ................................... 229
10.1.2. Anwendungsf¨
alle ................................ 229
10.1.3.Systeme..................................... 230
10.1.4.IntegrationmitHilfedesPROCEED-Rahmenwerkes ............ 231
10.1.5.Erkenntnisse .................................. 235
5
Inhaltsverzeichnis
IV. Zusammenfassung 237
11.Zusammenfassung und Ausblick 239
11.1.Zusammenfassung ................................... 239
11.2.Ausblick......................................... 240
6
Abk¨urzungsverzeichnis
AF Anwendungsfall
Cor Korrepondenz (engl. correspondence)
DMU Digital Mock-Up
ECU elektronisches Steuerger¨
at (engl. electronic control unit)
EDI Electronic Data Interchange
FDBS F¨
oderiertes Datenbanksystem
GPO globale Produktontologie
Ind Instanz (engl. individual)
LPO lokale Produktontologie
MPO Masterproduktontologie
OWL Web Ontology Language
PDIL Produktdatenintegrationsebene (engl. product data integration layer)
PDIS Produktdatenintegrationssystem
PDMS Produktdatenmanagementsystem
PROCEED PROactive Consistency for E/E product Data management
SC Schemakonzept (engl. schema concept)
SCAA Schemakonzept-Attributaktion (engl. schema concept attribute action)
SCAR Schemakonzept-Attributregel (engl. schema concept attribute rule)
STEP Standard for the Exchange of Product Data
UML Unified Modeling Language
XML Extensible Markup Language
7
Kurzfassung
Moderne Produkte, wie etwa Automobile oder Maschinen, werden infolge der zunehmenden Di-
gitalisierung komplexer. Neben mechanischen Bauteilen umfassen sie zahlreiche mechatronische,
elektronische und elektrische Bauteile. Um unterschiedliche Kundenbed¨
urfnisse, l¨
anderspezifische
Charakteristiken oder gesetzliche Anforderungen bedienen zu k¨
onnen, muss f¨
ur diese Produkte
eine hohe Variabilit¨
at erm¨
oglicht werden.
Die Produktentwicklung erfolgt ¨
ublicherweise system- und komponentenorientiert und wird mit
Methoden des Concurrent Engineering realisiert. Unterschiedliche Anforderungen und Aufgaben
der Produktentwickler f¨
uhren zu einer autonomen, heterogenen IT-Systemlandschaft, die sowohl
aus etablierten Informationssystemen, etwa Produktdatenmanagement-Systemen, aber auch aus
fachbereichsspezifischen L¨
osungen besteht. W¨
ahrend zwischen den etablierten Informationssys-
temen h¨
aufig Austauschschnittstellen existieren, erfolgt der Abgleich von Produktdaten aus die-
sen Systemen mit fachbereichsspezifischen L¨
osungen h¨
aufig manuell oder gar nicht. Zus¨
atzlich
ist die IT-Systemlandschaft der Produktentwicklung einem st¨
andigem Wandel unterworfen, so
dass Austauschschnittstellen kontinuierlich angepasst und erweitert werden m¨
ussen.
W¨
ahrend die unabh¨
angige Entwicklung von Systemen und Komponenten die Entwicklungszeit
reduziert, wird es zu verschiedenen Zeitpunkten w¨
ahrend der Produktentwicklung notwendig,
die autonomen, heterogenen Produktdaten zu synchronisieren. Fehlerhafte und inkonsistente
Produktdaten in sp¨
aten Entwicklungsphasen f¨
uhren zu erheblichen Kosten, so dass die Kontrol-
le der Vollst¨
andigkeit und Konsistenz von Produktdaten m¨
oglichst fr¨
uh sichergestellt werden
sollte, um eine hohe Produktqualit¨
at zu gew¨
ahrleisten.
Gegenstand dieser Arbeit ist das PROactive Consistency for E/E product Data management
(PROCEED)-Framework, dass die Integration autonomer, heterogener Produktdaten erm¨
oglicht.
PROCEED unterst¨
utzt den gesamten Lebenszyklus der Integration von Produktdaten, beginnend
mit der initialen Integration, ¨
uber die Steuerung und ¨
Uberwachung des Integrationsprozesses
sowie die Unterst¨
utzung von Schema- und Daten¨
anderungen.
Um die strukturelle Heterogenit¨
at von Produktdaten zu ¨
uberwinden, werden Informationssys-
teme in sog. Produktontologien abstrahiert. Die Produktontologien werden anschließend mit
Hilfe von Abbildungsregeln und -aktionen in eine gemeinsame Sicht ¨
uberf¨
uhrt. Auf Basis dieses
Modells werden Qualit¨
atsmetriken der Integration, wie z.B. die Konsistenz und Vollst¨
andigkeit
definiert. Zus¨
atzlich wird das dynamische Verhalten bei ¨
Anderungen von Schema und Daten der
Produktontologien erl¨
autert. Schließlich wir das PROCEED-Rahmenwerk prototypisch realisiert
und in einer Fallstudie angewandt.
9
Vorwort
Die vorliegende Arbeit entstand in Zusammenarbeit zwischen dem Institut f¨
ur Datenbanken und
Informationssysteme der Universit¨
at Ulm und der Daimler AG in B¨
oblingen.
An dieser Stelle m¨
ochte ich mich bei allen Personen bedanken, die mich w¨
ahrend der Erstellung
der vorliegenden Arbeit unterst¨
utzt und gepr¨
agt haben. Allen voran danke ich Prof. Dr. Man-
fred Reichert, der die Betreuung der Arbeit auf Seiten der Universit¨
at ¨
ubernommen hat. Als
Doktorvater danke ich ihm ganz besonders f¨
ur sein Engagement und seine Geduld.
Ich danke Prof. Dr. Richard Lenz f¨
ur die ¨
Ubernahme des Zweitgutachtens sowie den Mitar-
beitern des Institutes f¨
ur Datenbanken und Informationssysteme, die immer mit Rat und Tat
zur Seite standen. Hier sei vor allem Dr. R¨
udiger Pryss erw¨
ahnt, der mich bereits w¨
ahrend des
Studiums geformt und gef¨
ordert hat. Des weiteren m¨
ochte ich mich bei Prof. Dr. Thomas Bauer,
Dr. Thomas Ringler und Cord Rodefeld f¨
ur die inspirierenden Diskussionen bedanken.
Mein ganz pers¨
onlicher Dank gilt Dr. Joachim Herbst, der f¨
ur mich die optimalen organisa-
torischen Rahmenbedingungen innerhalb der Daimler AG geschaffen hat. Sein unerm¨
udlicher
Einsatz und seine breites Netzwerk innerhalb der Daimler AG haben mir einen tiefen Einblick
in die Produktentwicklung erm¨
oglicht. Vor allem die unz¨
ahligen Diskussionen, die immer von
tiefem fachlichen Wissen als auch einer Portion Pragmatismus gepr¨
agt waren, werden mir noch
lange in Erinnerung bleiben.
Zu guter Letzt danke ich meiner Familie und meinen Freunden f¨
ur ihre Geduld und Verst¨
andnis.
Ganz besonders danke ich meiner Freundin Fantina, die mir w¨
ahrend der gesamten Zeit immer
den R¨
ucken frei gehalten hat. Ohne sie w¨
are die Arbeit nicht m¨
oglich gewesen.
Ulm, im Oktober 2018
11
Teil I
Problembeschreibung und -analyse
1. Einleitung
1.1. Hintergrund
Kontinuierliche Produktinnovationen und stetig steigende Kundenanforderungen f¨
uhren zu im-
mer komplexeren Produkten, w¨
ahrend gleichzeitig die Entwicklungszeiten durch den zunehmen-
den Wettbewerb stetig k¨
urzer werden sollen [Con12]. An der Entwicklung eines komplexen Pro-
duktes, etwa eines Automobiles [MHHR06], sind heutzutage 500 bis 1000 Entwickler beteiligt,
zu denen unter anderem Anforderungsanalysten, Softwareentwickler, Zulieferer oder Testspe-
zialisten geh¨
oren. Zur Erledigung ihrer Entwicklungsaufgaben verwenden Entwickler autonome,
heterogene Informationssysteme1, die jeweils f¨
ur spezifische Anwendungsf¨
alle maßgeschneidert
sind. Folglich werden die verschiedenen Perspektiven auf Produktdaten (z.B. Anforderungen,
Software, geometrische Modelle) in spezifischen, oftmals heterogenen Datenmodellen gespei-
chert.
Die Produktentwicklung erfolgt in der Regel durch die Zusammenarbeit simultan arbeitender
Teams, w¨
ahrend der Entwicklungsprozess linear verl¨
auft [CRS`13]. Dadurch werden die einzel-
nen Produktdaten zu verschiedenen Zeitpunkten erstellt. Um unterschiedliche Kundenw¨
unsche
sowie l¨
anderspezifische und gesetzliche Anforderungen bedienen zu k¨
onnen, ist eine hohe Pro-
duktvariabilit¨
at pr¨
avalent.
Trotz der autonomen, heterogenen Speicherung von Produktdaten wird es w¨
ahrend der Ent-
wicklung notwendig, diese zu unterschiedlichen Zeitpunkten in eine vollst¨
andige und konsistente
Form zu integrieren. Da die Komponenten komplexer Produkte von einander abh¨
angen k¨
onnen
(z.B. vernetzte Steuerger¨
ate in einem Fahrzeug) und teilweise durch Entwickler anderer Herstel-
ler realisiert werden, k¨
onnenFehlerw
¨
ahrend der Entwicklung auftreten, etwa nach ¨
Anderungen
an Spezifikationen, die aufgrund fehlender Schnittstellen nicht automatisch an nachfolgende In-
formationssysteme kommuniziert wurden. Um diesen Problemen entgegen zu wirken, werden in
Entwicklungsprojekten sog. Meilensteine definiert, an denen z.B. die Konsistenz von Produkt-
datenaspekten ¨
uberpr¨
uft und abgesichert wird.
Da Informationssysteme zur Unterst¨
utzung spezifischer Aufgaben entwickelt werden, kann es
vorkommen, dass die Produktdaten mittels unterschiedlicher Variabilit¨
ats- und Versionierungs-
mechanismen dokumentiert werden. Dar¨
uber hinaus bieten die Datenmodelle der Informati-
onssysteme große Freiheitsgrade in der Speicherung von Produktdaten. So bieten einige Infor-
mationssysteme z.B, Freitextfelder an, die beliebige, unstrukturierte Daten enthalten k¨
onnen,
wohingegen andere Informationssysteme strenge Einschr¨
ankungen f¨
ur Datentypen und die In-
halte von Attributen besitzen. Die Integration solcher strukturierter und unstrukturierter Daten
ist sehr komplex und fehleranf¨
allig.
1Wenn im weiteren Verlauf der Arbeit von Informationssystemen gesprochen wird, sind im engeren Sinne An-
wendungssysteme gemeint [HMN15].
15
1. Einleitung
1.2. Problemstellung
Abbildung 1.1 zeigt die Komplexit¨
at eines Produktes f¨
ur mehrere Ebenen. Ein Produkt be-
steht aus unterschiedlichen Bauteilen, ein Automobil etwa aus mechanischen (z.B. Karosserie)
und elektrischen Bauteilen (z.B. Sensoren, Steuerger¨
ate und Aktuatoren). Um L¨
ander-, Markt-
und Kunden-Anforderungen zu bedienen, sind einige Bauteile optional, w¨
ahrend f¨
ur andere von
ihnen Varianten existieren [ATW`15, HBR10, Hal10]. Das heißt, es lassen sich verschiedene
Produktvarianten konfigurieren. Die Auswahl von optionalen und variablen Bauteilen wird als
Produktkonfiguration bezeichnet [Ste12].
Ein Beispiel f¨
ur ein komplexes Produkt ist ein Automobil: Neben tausenden mechanischen Bau-
teilen umfasst ein modernes Fahrzeug mehr als 100 Steuerger¨
ate, Sensoren und Aktuatoren
[MHR06, MHR07, MHR08]. Durch die vielen variablen Merkmale sind theoretisch mehrere Mil-
lionen Fahrzeugkonfigurationen m¨
oglich. Insgesamt hat sich die Anzahl der Produktvarianten
in den letzten 15 Jahren mehr als verdoppelt [Con12]. ¨
Ahnliches gilt in Bezug auf moderne
Produktionsanlagen und Cyber-physische Systeme [HPS`18, KPSR18].
F¨
ur die verschiedenen Ebenen in Abbildung 1.1 existieren unterschiedliche Probleme. Der Fokus
dieser Arbeit liegt auf den Ebenen Produktdaten,Informationssysteme und Prozesse. Bei der
Produktkonfiguration existiert in der Regel kein durchg¨
angiges Featuremodell zur Beschreibung
m¨
oglicher Konfigurationen eines Produktes entlang der verschiedenen Informationssysteme. So
verwenden letztere propriet¨
are Modelle, die teils nur implizit dokumentiert sind. Produktdaten
sind, wie bereits erw¨
ahnt, ¨
uber autonome, heterogene Informationssysteme verteilt. Eine expli-
zite Dokumentation zusammengeh¨
origer Produktdaten ¨
uber die Grenzen von Informationssys-
temen, hinweg ist nicht vorhanden. Durch die heterogenen, konzeptionellen Datenmodelle der
einzelnen Systeme werden daher Variabilit¨
at und Versionierung von Produktdaten meist unter-
schiedlich gehandhabt. Die Qualit¨
at der dokumentierten Aspekte h¨
angt von der Entwicklungs-
phase ab und ist in den fr¨
uhen Phasen oft durch Fehler und unvollst¨
andige Informationen ge-
pr¨
agt. Neben der Autonomie und Heterogenit¨
at der Informationssysteme erschweren technische
Aspekte , wie etwa fehlende Schnittstellen, ebenso wie soziokulturelle Aspekte (z.B. verschiedene
Verantwortlichkeiten und Interessen der beteiligten Entwickler, Weitergabe impliziten Wissens)
die Integration verschiedener Produktdaten und Informationssysteme. Nicht zuletzt stellt die
fehlende System- und Prozessorientierung der Informationssysteme [RW12, BBR11], inklusive
der Abstimmung von ¨
Anderungen untereinander, sowie die mangelnde IT-Unterst¨
utzung von
Entwicklungsprozessen [Gra16, GOR12] eine weitere H¨
urde f¨
ur die Integration dar.
Produktdaten sind alle Dokumente und elektronisch gespeicherten Entwicklungsergebnisse, die
w¨
ahrend der Entwicklung von Bauteilen anfallen. Sie dienen der l¨
uckenlosen Nachvollziehbar-
keit der Entwicklung und m¨
ussen auf Grund rechtlicher Vorschriften, etwa der Produkthaftung,
aufbewahrt werden. Produktdaten umfassen unterschiedliche Aspekte, wie zum Beispiel Anfor-
derungsspezifikationen, Schaltpl¨
ane, Leitungssatzdiagramme, geometrische CAD-Modelle oder
Software. H¨
aufig werden diese Aspekte in unterschiedlichen Informationssystemen von Entwick-
lern zu verschiedenen Zeitpunkten dokumentiert. Der hohe Freiheitsgrad der Informationssys-
teme f¨
uhrt dazu, dass Attribute einzelner Aspekte (z.B. die Bezeichnung) wahlfrei und ohne
Ber¨
ucksichtigung einheitlicher Vorgaben gespeichert werden. So ist es in der Praxis ¨
ublich, dass
f¨
ur ein und dieselbe Komponente unterschiedliche Bezeichnungen in den verschiedenen Informati-
onssystemen verwendet werden. Dadurch ist eine automatische Zuordnung zusammengeh¨
orender
Aspekte nicht ohne weiteres m¨
oglich.
16
1.2. Problemstellung
D G
]
[
\;
)HDWXUH0RGHOOH
RSWLRQDOPDQGDWRULVFK
$QIRUGHUX
QJHQ
)XQNWLRQHQ 6RIWZDUH *HRPHWULH +DUGZDUH
E<
3URGXNWNRQILJXUDWLRQHQ
%DXWHLOH
F
E
D
D
(QWZLFNOXQJVSUR]HVV
bQGHUXQJVSUR]HVV
%DXWHLO
3UR]HVVH
,QIRUPDWLRQVV\VWHPH
3URGXNWGDWHQDVSHNWH
3URGXNWNRQILJXUDWLRQ
NN
$
%
$
E;
N
D
]
$
%¤
)HKOHQGH'XUFKJlQJLJNHLW
6FKQLWWVWHOOHQ
+HWHURJHQLWlW
+HWHURJHQLWlW
G<
E
\
'DWHQTXDOLWlW
9HUVFKLHGHQH9DULDELOLWlW
3URGXNW
««
«
«
«
««
«
«
«
NHLQHGXUFKJlQJLJH,7
8QWHUVWW]XQJ
9HUDQWZRUWOLFKNHLWHQ
bQGHUXQJHQ
$XWRQRPLH
E;
N
D
]
/HJHQGH
G<
E
\
$ %
$ %
Abbildung 1.1.: Komplexit¨
at der Produktentwicklung
Beispiel 1 (Bauteil). Abbildung 1.2 zeigt exemplarisch verschiedene Artefakte eines
einzelnen T¨
ursteuerger¨
ates f¨
ur ein Automobil, die in unterschiedlichen Informationssys-
temen dokumentiert sein k¨
onnen. Ein T¨
ursteuerger¨
at ist f¨
ur unterschiedliche Sicherheits-
und Komfortfunktionen zust¨
andig und bedient z.B. Aktuatoren f¨
ur die Spiegelverstellung,
den Blinker, das T¨
urschloss oder den Fensterhebermotor. F¨
ur die unterschiedlichen Aspek-
te existieren mehrere Versionen, die zu verschiedenen Zeitpunkten dokumentiert worden
sind. Die erw¨
ahnte Variabilit¨
at von Bauteilen wird in den Informationssystemen unter-
schiedlich realisiert. W¨
ahrend eine Anforderungsspezifikation alle m¨
oglichen Varianten eines
T¨
ursteuerger¨
ates beschreibt, werden f¨
ur die unterschiedlichen Varianten eigene Funktions-
modelle erstellt, die wiederum in Softwaremodellen realisiert werden. Schließlich existie-
ren drei unterschiedliche geometrische Modelle der T¨
ursteuerger¨
ategeh¨
ause, die von unter-
schiedlichen Herstellern angeliefert werden [Kat15]. Diese unterschiedlichen Methoden zur
zeitlichen Dokumentation und Variabilit¨
at von Produktdaten erschweren die Integration
erheblich.
W¨
ahrend der Entwicklung eines Produktes ist es aufgrund der simultanen Entwicklung [Beu02]
essentiell, dass Produktdaten regelm¨
aßig auf verschiedene Eigenschaften, wie etwa Konsistenz
und Korrektheit, untersucht werden, um Fehler m¨
oglichst fr¨
uh zu erkennen und beseitigen
[RTW15]. Um solche Anwendungsf¨
alle (AF)zu realisieren, m¨
ussen Produktdaten aus hetero-
17
1. Einleitung
$
D
[
[
\
U
S
$QIRUGHUX
QJHQ
)XQNWLRQHQ
6RIWZDUH
*HRPHWULH
+DUGZDUH
$
V
S
DDDD
$ 1DPH 7UVWHXHUJHUlW
9DULDELOLWlW(LQ'RNXPHQWEHVFKUHLEW
DOOHP|JOLFKHQ 9DULDQWHQ
W
U
1DPH'0B)/'0B)5'0B5/'0B55
9DULDELOLWlW)XQNWLRQVPRGHOOEHVFKUHLEWJHQDX
HLQH 9DULDQWH
EEE
FF
GG
1DPH 78(5B)DKUHU 78(5B%HLIDKUHU
78(5BKLQWHQ
9DULDELOLWlW-HGHV0RGHOOEHVFKUHLEWHLQH
XQWHUVFKLHGOLFKHJHRPHWULVFKH)RUP
]
1DPH 78(5B)DKUHUB0D[ 78(5B%HLIDKUHU
78(5BKLQWHQ
9DULDELOLWlW8QWHUVFKLHGOLFKH+HUVWHOOHU
X
T
1DPH'0B)/'0B)5'0B5/'0B55
9DULDELOLWlW (LQH6RIWZDUHIUDOOHVRZLH&RGLHU
GDWHLHQ
T T T
W
,QIRUPDWLRQVV\VWHPH
=HLW
$UWHIDNWH
/HJHQGH $ E S [ W
3URGXNWGDWHQ 1DFKIROJHU%H]LHKXQJ
Abbildung 1.2.: Produktdaten w¨
ahrend der Entwicklung
genen, autonomen Informationssystemen integriert werden.
Abbildung 1.3 zeigt f¨
ur das dargestellte Beispiel zwei Anwendungsf¨
alle. Im Anwendungsfall 1
sollen Anforderungen und Funktionsmodelle f¨
ur Steuerger¨
ate abgeglichen werden. Dazu m¨
ussen
zu den einzelnen Anforderungsspezifikationen in den jeweiligen Versionen die zugeh¨
origen Funk-
tionsmodelle in den entsprechenden Versionen ermittelt werden. Dar¨
uber hinaus m¨
ussen Be-
ziehungen zwischen unterschiedlichen Varianten bestimmt werden. Im speziellen Fall bedeutet
dies, dass zu allen Anforderungsspezifikationen alle realisierenden Varianten der Funktionsmo-
delle bestimmt werden m¨
ussen.
Im Anwendungsfall 2 sollen allen aktuellen Aspekte eines Bauteils integriert werden, damit
eine holistische Sicht geschaffen wird. Dazu m¨
ussen Produktdaten aus allen Informationssyste-
men integriert werden. Hier kommt erschwerend hinzu, dass mehr als zwei Informationssysteme
integriert werden m¨
ussen und somit ein ”gemeinsamer Nenner“ f¨
ur Variabilit¨
ats- und Versio-
nierungsmechanismen gefunden werden muss.
Heutzutage sind solche Anwendungsf¨
alle schwer zu realisieren, da Beziehungen zwischen zu-
sammengeh¨
origen Produktdaten fehlen. In der Praxis wird die Integration dieser Produktdaten
manuell durchgef¨
uhrt, was sowohl zeitaufw¨
andig als auch fehleranf¨
allig ist. Die Beziehungen
18
1.2. Problemstellung
$QZHQGXQJVIDOO
$QZHQGXQJVIDOO
$
D
[
[
\
S
$QIRUGHUXQJHQ
)XQNWLRQHQ
6RIWZDUH
*HRPHWULH
+DUGZDUH
$
S
DDDD
$
%%
EE
] ]
U
V
W
U
""
""
W
"
"
,QIRUPDWLRQVV\VWHPH
=HLW
/HJHQGH $ E
S
S [ W
3URGXNWGDWHQ 1DFKIROJHU%H]LHKXQJ .RUUHVSRQGHQ]
Abbildung 1.3.: Anwendungsf¨
alle f¨
ur Produktdaten
zwischen zusammengeh¨
orenden Aspekten sind, wenn ¨
uberhaupt, nur implizit vorhanden. Bei
der Entwicklung komplexer Produkte sind f¨
ur die Entwicklung von Bauteilen unterschiedliche
Mitarbeiter verantwortlich. ¨
Anderungen an Bauteilen k¨
onnen Auswirkungen auf weitere haben
und m¨
ussen folglich koordiniert werden, wodurch eine manuelle Integration erschwert wird. In
einigen F¨
allen existieren Kopplungen zwischen Applikationen. In der Regel handelt es sich hier-
bei um den Abgleich von Daten aus zwei Informationssystemen, eine ganzheitliche Integration
von mehreren Produktdaten findet jedoch nicht statt.
19
1. Einleitung
Neben diesen semantischen und technischen Problemen kann die Qualit¨
at der dokumentierten
Produktdaten sehr unterschiedlich sein. In fr¨
uhen Entwicklungsphasen werden oft Entwicklungs-
ergebnisse vorheriger Produkte wiederverwendet und angepasst. Deshalb ist eine vollst¨
andige
Integration aller Produktdaten zu allen Zeitpunkten nicht m¨
oglich bzw. der Aufwand w¨
urde in
keinem Verh¨
altnis zum Nutzen stehen. Vielmehr ist eine bedarfsgerechte Integration notwendig.
Dass heißt, dass nur diejenigen Produktdaten integriert werden sollten, die zur Realisierung
eines Anwendungsfalls ben¨
otigt werden.
Ziel der Integration von Produktdaten aus heterogenen, autonomen Informationssystemen ist die
Unterst¨
utzung einer Vielzahl und Vielfalt an Anwendungsf¨
allen. Folglich muss eine Integration
zu einem bestimmten Zeitpunkt vollst¨
andig und konsistent erfolgen. Damit diese Eigenschaf-
ten erreicht werden k¨
onnen, muss der Integrationsprozess ¨
uberwacht werden, wof¨
ur wiederum
Kennzahlen ben¨
otigt werden, welche die gew¨
unschten Integrationseigenschaften messen.
Da Informationssysteme i.A. autonom sind, erfolgen Datenmodell¨
anderungen unabh¨
angig von-
einander, was bei der Integration von Produktdaten ber¨
ucksichtigt werden muss. Durch Daten-
modell¨
anderungen darf bereits existierendes Integrationswissen nicht unbrauchbar werden. Mit
Integrationswissen sind vor allem Beziehungen zwischen Produktdaten gemeint.
1.3. Forschungsfragen
Um ein Rahmenwerk zu entwickeln, welches die vorangehend genannten Probleme adressiert,
m¨
ussen verschiedene Ziele ber¨
ucksichtigt werden (siehe Tabelle 1.1).
Nr. Ziel
Z1 Integration heterogener und autonomer Produktdaten zur Realisierung von Anwen-
dungsf¨
allen
Z2 Ber¨
ucksichtigung von ¨
Anderungen auf Schema- und Datenebene
Z3 ¨
Uberwachung und Kontrolle des Integrationsprozesses
Tabelle 1.1.: Forschungsziele
Zun¨
achst muss untersucht werden, wie Produktdaten aus autonomen und heterogenen Informati-
onssystemen mit verschiedenen Mechanismen zur Dokumentation von Variabilit¨
at und Versionie-
rung integriert werden k¨
onnen (Z1). Ein Beispiel f¨
ur Variabilit¨
atsmechanismen in der Automobil-
industrie stellen Anforderungsspezifikationen und Funktionsmodelle f¨
ur Steuerger¨
ate dar (siehe
Abbildung 1.4). W¨
ahrend eine Anforderungsspezifikation f¨
ur ein Steuerger¨
at alle m¨
oglichen Vari-
anten beschreibt, m¨
ussen ggf. f¨
ur jede dieser Varianten eigene Funktionsmodelle erstellt werden.
Da die Beziehungen zwischen Anforderungsspezifikationen und Funktionsmodellen h¨
aufig nicht
explizit dokumentiert werden, sondern lediglich implizites Wissen der Entwickler darstellen,
kann es vorkommen, dass ¨
Anderungen an Anforderungsspezifikationen nicht in entsprechende
Funktionsmodelle ¨
ubernommen werden.
Sind Produktdaten einmal integriert, muss untersucht werden, wie sich unterschiedliche ¨
Ander-
ungen sowohl an den Schemata der autonomen Informationssysteme als auch an dessen Daten
auf die bereits bestehende Integration auswirken (Z2). Um beim vorherigen Beispiel zu bleiben,
werden nach einer initialen Integration von Anforderungsspezifikationen und Funktionsmodellen
¨
Anderungen an einigen Spezifikationen vorgenommen. Das heißt, dass neue Versionen in einem
20
1.3. Forschungsfragen
.RPSRQHQWHQODVWHQKHIW
)XQNWLRQVPRGHOO
)XQNWLRQVPRGHOO
)XQNWLRQVPRGHOO
$QIRUGHUXQJ
«
$QIRUGHUXQJQ
Abbildung 1.4.: Variabilit¨
at von Funktionsmodellen
Informationssystem vorhanden sind. Anschließend muss ¨
uberpr¨
uft werden, welche Schritte not-
wendig sind, um auf diese neuen Produktdaten zu reagieren.
Da die Integration der Produktdaten nur teil-automatisiert erfolgen kann, muss der manuelle
Integrationsprozess ¨
uberwacht werden. Dazu muss untersucht werden, welche Eigenschaften der
Integration geeignet sind. Schließlich muss der Integrationsprozess ¨
uberwacht werden (Z3).
Aus diesen Forschungszielen leiten wir folgende Forschungsfragen ab:
•Forschungsfrage 1: Wie lassen sich komplexe Produktdaten aus heterogenen, autono-
men Informationssystemen in Entwicklungsumgebungen integrieren, die unterschiedliche
Konzepte zur Repr¨
asentation von Variabilit¨
at und Versionierung aufweisen?
–Welche Ans¨
atze und Architekturen existieren zur Integration heterogener, autonomer
Informationssysteme? Was sind die Vor- und Nachteile der einzelnen Ans¨
atze?
–Wie sieht eine Methodik zur Integration heterogener Produktdaten aus?
–Welche Standards existieren f¨
ur den Austausch von Produktdaten? Welche Vor- und
Nachteile bieten diese?
–Wie lassen sich die Beziehungen zwischen zusammengeh¨
origen Aspekten beschreiben
und auswerten?
–Welche Ans¨
atze zur Datenintegration bietet Konzepte zur Unterst¨
utzung manueller
Integrationsaufgaben?
•Forschungsfrage 2: Wie l¨
asst sich der Prozess der Integration ¨
uberwachen?
–Welche Eigenschaften lassen sich bei der Integration bestimmen und wie sieht ein
Monitoringprozess aus?
–Wie lassen sich diese Eigenschaften zu definierten Zeitpunkten garantieren?
21
1. Einleitung
•Forschungsfrage 3: Wie beeinflussen strukturelle und inhaltliche ¨
Anderungen bereits
integrierte Produktdaten?
–Wie lassen sich ¨
Anderungen kompensieren und welche Schritte sind notwendig, um
Vollst¨
andigkeit und Konsistenz wiederherzustellen?
–Existieren ¨
Anderungen, die bisherige Integrationsinformationen unbrauchbar machen?
•Forschungsfrage 4: Mit Hilfe welcher Technologien l¨
asst sich die Integration heterogener
Produktdaten umsetzen?
–Welche Vorraussetzungen muss eine IT-Landschaft besitzen, um eine Integration zu
erm¨
oglichen?
–Wie lassen sich Integrationsprozesse in eine bestehende IT-Landschaft einbinden und
welche Aufgaben und Rollen werden ben¨
otigt?
1.4. Beitrag
Das im Rahmen der vorliegenden Dissertation entwickelte PROCEED-Rahmenwerk adressiert al-
le der in Abschnitt 1.3 hergeleiteten Fragestellungen. Der Hauptbeitrag der Arbeit liegt in der
Bereitstellung von Konzepten, Techniken und Methoden zur Integration autonomer, heterogener
Produktdaten ¨
uber deren gesamten Lebenszyklus hinweg. Dieser Lebenszyklus reicht von der
Abstraktion konzeptioneller Datenmodelle aus autonomen, heterogenen Informationssystemen
in lokale Produktontologien (engl. local product ontologies, LPOs), ¨
uber die Definition von In-
tegrationsregeln und -aktionen, bis hin zur Unterst¨
utzung von ¨
Anderungen bereits integrierter
Produktdaten.
Es werden unterschiedliche Qualit¨
atskriterien f¨
ur integrierte Produktdaten eingef¨
uhrt und ein
allgemeiner Integrationsprozess, inklusive allen beteiligten Aktivit¨
aten und Rollen, definiert.
Zus¨
atzlich werden visuelle Darstellungskonzepte zur Reduktion der Komplexit¨
at bei manuellen
Integrationsaufgaben erl¨
autert. Die dargestellten Konzepte und Methoden sind generisch und
damit dom¨
anenunabh¨
angig. Sie lassen sich auf beliebige Produkte (z.B. Fahrzeug, Flugzeug,
Maschine, Software) anwenden. Schließlich werden die entwickelten Konzepte prototypisch im-
plementiert und anhand einer Fallstudie praktisch evaluiert.
1.5. Forschungsmethodik
Der Prozess der angewandten Forschung unterteilt sich in folgende vier Aktivit¨
aten:
1. Problemanalyse
2. Anforderungsanalyse
3. L¨
osungsentwurf
4. Evaluation
Da es das Ziel der Arbeit ist, ein Realweltproblem zu l¨
osen, wurde in der vorliegenden Arbeit die
Forschungsmethodik aus Abbildung 1.5 angewandt, sie basiert auf dem Design Science Paradig-
ma [HMPR04]. Zun¨
achst erfolgt die Problemanalyse, danach werden Anforderungen hergeleitet
22
1.6. Aufbau
(siehe Kapitel 3) und L¨
osungen entworfen (siehe Kapitel 5, 6, 7 und 8). Schließlich werden
letztere implementiert (siehe Kapitel 9) und evaluiert (siehe Kapitel 10). Im Detail wird das
Problem anhand der Dom¨
ane der Automobilindustrie und im Speziellen f¨
ur die Entwicklung
von E/E-Komponenten [MHR06, MHR07] beschrieben.
Erkenntnisse der Dom¨
ane fließen in die Anforderungsanalyse genau so ein wie eine Literatur-
studie zur Integration von Produktdaten. Auf Basis dieser Anforderungen werden L¨
osungen
entworfen und durch Prototypen evaluiert. Erkenntnisse der prototypischen Evaluierung wie-
derum fließen in den L¨
osungsentwurf ein und f¨
uhren somit zu einer R¨
uckkopplung zwischen den
beiden Phasen.
Abbildung 1.5.: Forschungsmethodik
1.6. Aufbau
Die Arbeit gliedert sich in vier Teile: Der erste Teil umfasst die Problembeschreibung und -
analyse. Dazu z¨
ahlen sowohl die Grundlagen, die f¨
ur das weitere Verst¨
andnis der Arbeit er-
forderlich sind, als auch die notwendige Anforderungsanalyse. Diese werden anschließend mit
verwandten Arbeiten abgeglichen, um die Relevanz der Arbeit zu unterstreichen.
Der zweite Teil stellt das PROCEED-Rahmenwerk vor, welches die L¨
osung f¨
ur die Handhabung
der in Teil I identifizierten Probleme bietet. In Kapitel 6 wird die Integration von Produktdaten
aus autonomen, heterogenen Informationssystemen erl¨
autert. Anschließend werden verschiede-
ne Eigenschaften zur Qualit¨
at (z.B. Vollst¨
andigkeit und Konsistenz) der Integration beschrieben
(siehe Kapitel 7), bevor in Kapitel 8 ¨
Anderungsoperationen vorgestellt werden. Schließlich wer-
den die prototypische Implementierung der Konzepte in Kapitel 9 erl¨
autert und deren praktische
Anwendung in Kapitel 10 er¨
ortert.
Im dritten Teil der Arbeit werden die zuvor dargestellten Konzepte anhand unterschiedlicher
Fallstudien validiert. Im letzten und vierten Teil werden die wesentlichen Erkenntnisse zusam-
mengefasst und ein Ausblick gegeben.
23
2. Grundlagen
Dieses Kapitel definiert grundlegende Begriffe, die f¨
ur das weitere Verst¨
andnis der Arbeit not-
wendig sind. Zun¨
achst werden allgemein g¨
ultige Begriffe zu Daten und Informationen gegeben,
bevor Begriffe und Prozesse der Produktentwicklung in der Automobilindustrie erl¨
autert werden.
Anschließend werden Aspekte der Integration von Informationen sowie deren Qualit¨
at beschrie-
ben.
2.1. Daten und Informationen
Um die Integration von Produktdaten zu definieren, m¨
ussen zun¨
achst die Begriffe Daten und
Information erl¨
autert werden. Eine bekannte Definition bietet die DIKW1-Hierarchie nach Ack-
off [Ack89]2. Ackhoff strukturiert die Begriffe Daten,Informationen,Wissen und Weisheit als
Pyramide, bei der Daten als Fundament f¨
ur Informationen dienen.
Definition 1 (Daten). Daten sind Fakten oder Beobachtungen ¨
uber Gegenst¨
ande der
physischen Welt, etwa Dinge oder Menge von Dingen. Ohne einen Kontext oder eine Inter-
pretation besitzen Daten keine Bedeutung.
Definition 2 (Information). Informationen sind Daten, die einen Mehrwert f¨
ur das
Verst¨
andnis eines Subjektes besitzen. Folglich ¨
ubertragen Daten entsprechende Informatio-
nen von einem Sender zu einem Empf¨
anger.
Um Daten und Informationen maschinenlesbar zu machen, m¨
ussen Dinge der physischen Welt
mit Hilfe von Konzepten beschrieben werden, die durch Symbole repr¨
asentiert werden (siehe
Abbildung 2.1).
.RQ]HSW
6\PERO 'LQJ
PHLQW
HUZHFNW
UHSUlVHQWLHUWGXUFK VWHKWIU
V\PEROLVLHUWGXUFK
Abbildung 2.1.: Zusammenh¨
ange zwischen Konzept, Symbol und Ding. Semiotisches Dreieck nach
[ORMC23]
1Data, Information, Knowledge, Wisdom
2Eine genaue Untersuchung zu den existierenden Definitionen ist in [Row07] zu finden.
25
2. Grundlagen
Definition 3 (Konzeptualisierung). Konzeptualisierung ist das Ermitteln und Beschrei-
ben aller notwendigen Konzepte einer Dom¨
ane, um Dinge und Mengen von Dingen der
physischen Welt mit Hilfe von Informationssystemen zu verarbeiten.
Eine Konzeptualisierung bildet somit die Grundlage f¨
ur die Erstellung aller Informationssyste-
me, egal ob das zugrundeliegende semantische Datenmodell auf einem relationalen bzw. objek-
torientierten Datenmodell oder einer Ontologie basiert. F¨
ur letztere existiert keine einheitliche
Definition, die am meisten verwendete stammt von [Gru93] (siehe Definition 4).
Definition 4 (Ontologie). Eine Ontologie ist eine explizite Spezifikation einer geteilten
Konzeptualisierung.
2.1.1. Evolution vs. Versionierung
Da Dinge der Realwelt nicht statisch sind, sondern st¨
andigen ¨
Anderungen [Len03] unterliegen,
m¨
ussen Konzepte und dementsprechend auch Daten und Informationen angepasst werden. Je
nach dem jeweils zugrunde liegendem semantischen Datenmodell eines Informationssystems muss
zwischen Schemaevolution und Ontologieevolution unterschieden werden.
Nach [JDB`98] unterst¨
utzt eine Datenbank die Evolution, wenn nach ¨
Anderungen des Sche-
mas keine bestehenden Daten verloren gehen. Weiter unterst¨
utzt eine Datenbank Versionie-
rung, wenn verschiedene Schemata genutzt werden k¨
onnen, um Daten abfragen zu k¨
onnen. Die
entsprechenden Begriffe werden in der Literatur f¨
ur prozessorientierte Informationssysteme ent-
sprechend erweitert [RRD04a, RRD04b].
Schemaevolution und -versionierung
”Es wird zwischen Schemaevolution und Schemaversionierung unterschieden. Schemaevolution
ist die F¨
ahigkeit das Schema einer mit Daten gef¨
ullten Datenbank zu ¨
andern, ohne dass dabei
Daten verloren gehen“ [Rod95]. Schema-Versionierung bedeutet, auf alle Daten (alte und neue)
¨
uber verschiedene Schnittstellen zugreifen zu k¨
onnen.
2.2. Produktentwicklung
Zentraler Prozess eines produzierenden Unternehmens ist der Produktentwicklungsprozess. Die-
ser definiert alle Aktivit¨
aten und Rollen, die notwendig sind, um Produkte zu entwickeln. Im
Folgenden werden die Grundlagen der Produktentwicklung am Beispiel der Automobilindustrie
erl¨
autert; sie sind f¨
ur das weitere Verst¨
andnis der Arbeit erforderlich sind. Die grundlegen-
den Prozesse und Informationssysteme sind in anderen Dom¨
anen (etwa der Luftfahrtindustrie)
¨
ahnlich, so dass die gewonnen Erkenntnisse der Arbeit generisch auf andere Dom¨
anen ¨
ubertragen
werden k¨
onnen.
2.2.1. Produkt und Produktdaten
Ein Produkt ist ein physisches Erzeugnis und stellt das Ergebnis eines Entwicklungsprozesses dar,
an dem eine Vielzahl unterschiedlicher Personengruppen beteiligt sind (z.B. Entwickler, Projekt-
manager, Tester, Lieferanten). F¨
ur die Entwicklung komplexer Produkte, wie etwa Automobilen
26
2.2. Produktentwicklung
oder Flugzeugen, hat sich eine System- und Komponentenorientierte Entwicklung durchgesetzt.
Zun¨
achst werden die Funktionen eines Produktes spezifiziert und anschließend auf verschiedene,
untereinander vernetzte Systeme verteilt. Letztere wiederum werden durch das Zusammenspiel
unterschiedlicher Komponenten, auch Bauteile genannt, nebenl¨
aufig realisiert. In diesem Zusam-
menhang wird auch von Concurrent Engineering gesprochen [Beu02, PMR93, YB03].
[SAS05] beschreibt Produktdaten als diejenigen Daten, die von der Konzeption des Produktes
bis zu dessen Fertigung ben¨
otigt werden. Zu ihnen z¨
ahlen Computer-Aided Design (CAD) Da-
ten, Computer-Aided Manufacturing (CAM) Daten, Computer-Aided Engineering (CAE) Daten,
Product Data Management (PDM) und weitere Daten.
Definition 5 (Produktdaten). Produktdaten umfassen alle Dokumente, Erzeugnisse,
Modelle und Protokolle, die w¨
ahrend der Entwicklung eines Produktes anfallen k¨
onnen. Sie
sind die Grundlage der Produktion und m¨
ussen auf Grund rechtlicher Rahmenbedingungen
(z.B. Produkthaftung) dokumentiert werden.
Typischerweise besteht ein komplexes Produkt aus mehreren tausend Bauteilen. Um die Entwick-
lungszeit von Produkten zu reduzieren, werden diese Bauteile nebenl¨
aufig durch unterschiedliche
Verantwortliche entwickelt. Um die unterschiedlichen Bauteile zuordnen zu k¨
onnen, besitzen sie
eindeutige Bauteilnummern. Dabei erfolgt die Entwicklung von Bauteilen in der Regel durch un-
terschiedliche Zusammenarbeitsmodelle unter Beteiligung einer Vielzahl von Zulieferern [Kat15].
Beispiel 2 (Produktdaten). Ein Beispiel f¨
ur ein System eines Fahrzeuges ist eine Autot¨
ur.
Dieses System realisiert verschiedene Funktionen (z.B. die Spiegelverstellung oder Fenster-
bet¨
atigung) mit Hilfe unterschiedlicher Komponenten. Abbildung 2.2 zeigt schematisch den
Aufbau einer Autot¨
ur, die neben mechanischen Komponenten (z.B. Innen- und Außenver-
kleidung, Scharniere) aus mechatronischen Komponenten (z.B. Außenspiegel, T¨
urschließung
und Schalterblock zur Bedienung des Fensters und des Außenspiegels) besteht. Schließlich
gibt es rein elektrische und elektronische Komponenten, etwa den Fensterhebermotor, den
Lautsprecher oder das T¨
ursteuerger¨
at, welches f¨
ur die Ansteuerung der verschiedenen Ak-
tuatoren verantwortlich ist.
Ein Produkt durchl¨
auft w¨
ahrend seiner Entwicklung einen definierten Produktlebenszyklus,in
dessen Verlauf, zu den einzelnen Komponenten verschiedene Produktdaten anfallen. Letzte-
re sind in der Regel ¨
uber eine Vielzahl autonomer, heterogener Informationssysteme verteilt
[Sta11]. Zu den Produktdaten einer Komponente z¨
ahlen sowohl Modelle (z.B. Systemmodelle,
Simulationsmodelle), E-CAD Modelle3(z.B. Leitungss¨
atze, Steuerger¨
ate, Sensoren, Aktuatoren,
Schaltpl¨
ane), M-CAD4Modelle (z.B. Bauteilgeometrien, Konstruktionszeichnungen), als auch
Daten (z.B. Anforderungs- und Testspezifikationen).
Die verschiedenen Produktdaten eines Produktes werden ¨
ublicherweise durch viele Beteiligte zu
unterschiedlichen Zeitpunkten erstellt, genutzt und ge¨
andert. Entwickler beschreiben ein Bauteil
aus speziellen Sichten (z.B. Anforderungsspezifikation, geometrische Modellierung, Softwareent-
wicklung oder Test), die jeweils durch spezifische Informationssysteme unterst¨
utzt werden sollen.
3Elektronisches CAD
4Mechanisches CAD
27
2. Grundlagen
6FKORVV
6FKDOWHUEORFN
$XHQVSLHJHO
%DVV
+RFKW|QHU
7UVWHXHUJHUlW
3URGXNWGDWHQ
$QIRUGHUXQJVVSH]LILNDWLRQHQ
7HVWVSH]LILNDWLRQHQ
6\VWHPPRGHOOH
6LPXODWLRQVPRGHOOH
&$6(0RGHOOH
(&$'0RGHOOH
0&$'0RGHOOH
6LPXODWLRQVHUJHEQLVVH
'08%HUHFKQXQJHQ
=HLFKQXQJHQ
«
3UR]HVVH
3URGXNWHQWZLFNOXQJVSUR]HVV
bQGHUXQJVPDQDJHPHQW
.RQILJXUDWLRQVPDQDJHPHQW
«
%HWHLOLJWH
(QWZLFNOHU
3URMHNWPDQDJHU
7HVWHU
/LHIHUDQWHQ
«
)HQVWHUKHEHUPRWRU
6FKDUQLHUH
,QQHQYHUNOHLGXQJ
$XHQYHUNOHLGXQJ
Abbildung 2.2.: Geometrie einer Autot¨
ur
Definition 6 (Produktdaten). Produktdaten beschreiben einen Ausschnitt an Produkt-
daten aus einem fachlichen Bereich. Diese Daten k¨
onnen in einem oder mehreren Infor-
mationssystemen verwaltet werden. Innerhalb dieser Systeme k¨
onnen gleiche Aspekte in
unterschiedlichen Datenstrukturen repr¨
asentiert sein.
Beispiel 3 (Produktdaten eines Automobils). Abbildung 2.3 zeigt die Verteilung von
Bauteilaspekten der Produktentwicklung eines großen deutschen Automobilherstellers.
6DFKQXPPHUQ
%DXWHLO
9DULDQWHQLQIRUPDWLRQ
%DXWHLOYHUVLRQ
$QIRUGHUXQJHQ
.RPSRQHQWHQ
ODVWHQKHIW
.RPSRQHQWHQ
ODVWHQKHIWYHUVLRQ
*HRPHWULH
%DXWHLOJHRPHWULH
*HRPHWULHYDULDQWH
7HVW
.RPSRQHQWHQWHVW
,QWHJUDWLRQVWHVW
.RPSRQHQWHQWHVWYHUVLRQ
,QWHJUDWLRQVWHVWYHUVLRQ
(3'0
6WHFNHU
.RPSRQHQWH
.RPSRQHQWHQ
YDULDQWH
.RPSRQHQWHQ
YDULDQWHQYHUVLRQ
$UFKLWHNWXU
.RPSRQHQWH
$UFKLWHNWXUYHUVLRQ
6LJQDO
.RPSRQHQWH
.RPSRQHQWHQ
YDULDQWHQYHUVLRQ
.RPSRQHQWHQYDULDQWH
6WFNOLVWH
.RPSRQHQWHQ
Abbildung 2.3.: Verteilung von Produktdaten ¨
uber Informationssysteme
2.2.2. Produktstruktur und -st¨ucklisten
Die strukturierte Anordnung von Bauteilen wird als Produktstruktur bezeichnet und spiegelt die
Beziehungen und Abh¨
angigkeiten von Bauteilen und Zusammenbauten5untereinander wider.
5Zusammenbauten sind Bauteile, die sich aus mehreren Bauteilen zusammensetzen und in der Regel von Zulie-
ferern bezogen werden. Daher besitzen sie in der Regel nur eine Bauteilnummer.
28
2.2. Produktentwicklung
Eine spezielle Produktstruktur der Produktentwicklung ist die sog. (Struktur-)St¨
uckliste.6Sie
bildet die hierarchische Struktur ab, die ein Produkt von oben nach unten in Bauteile und Zu-
sammenbauten zerlegt. Eine St¨
uckliste ist notwendig, um ein spezifisches Produkt herzustellen.
Sie ist somit f¨
ur die Bestellung und Bauteilebedarfsermittlung essentiell. In der Regel werden
f¨
ur unterschiedliche Aufgaben w¨
ahrend der Entwicklung unterschiedliche Produktstrukturen ver-
wendet [SI08].
Beispiel 4 (Produktstruktur). In Abbildung 2.4 sind ein exemplarischer Auszug der Pro-
duktstruktur sowie eine Strukturst¨
uckliste f¨
ur die zuvor beschriebene Autot¨
ur dargestellt. In
der Produktstruktur auf der linken Seite werden Bauteile in Gruppen (z.B. Innenverklei-
dung,Spiegel) zusammengefasst. Innerhalb einer Gruppe k¨
onnen mehrere ¨
ahnliche Bautei-
le vorhanden sein. In der Strukturst¨
uckliste auf der rechten Seite ist aus der Produktstruktur
eine spezifische Autot¨
ur konfiguriert. Das heißt, es sind sowohl die ben¨
otigten Mengen ein-
zelner Bauteile als auch Gruppen bestimmt. F¨
ur alle Bauteile, f¨
ur die mehrere Alternativen
vorhanden sind, ist genau eine ausgew¨
ahlt.
*)DKUHUWU
*,QQHQYHUNOHLGXQJ
*$XHQVSLHJHO
6WDQGDUGVSLHJHO
*/DXWVSUHFKHU
*%DVV
*+RFKW|QHU
6WDQGDUG
3UHPLXP
6WDQGDUG
3UHPLXP
*6FKORVV
%DVLVVFKORVV
6LFKHUKHLWVVFKORVV
*6FKDOWHUEORFN
)DKUHUWU
1U (EHQH *UXSSH7HLO 0HQJH
,QQHQYHUNOHLGXQJ
/DXWVSUHFKHU
%DVV
3UHPLXP
+RFKW|QHU
3UHPLXP
6SKlULVFK
6SKlULVFK(&*ODV
*7UVWHXHUJHUlW
6WDQGDUG
0D[LPDO
/LPRXVLQH
&RXSp
&RGH
)HQVWHUKHEHUPRWRU
6FKDUQLHU
$XHQYHUNOHLGXQJ
6FKDOWHUEORFN
/LPRXVLQH
« « « ««
/LPRXVLQH
&RGH %HVFKUHLEXQJ
&RXSp
3UHPLXP6RXQGV\VWHP
*HZlKOWH&RGHV/LPRXVLQH3UHPLXP6RXQGV\VWHP
HUK|KWHU'LHEVWDKOVFKXW]
3URGXNWVWUXNWXU
&RGHUHJHOQ
6WUXNWXUVWFNOLVWHNRQILJXULHUW
Abbildung 2.4.: Beispiel einer Produktstruktur sowie Strukturst¨
uckliste
2.2.3. Systemlandschaft und Prozesse
In Abbildung 2.5 ist eine generische IT-Systemlandschaft f¨
ur Automotive Engineering Dienste
dargestellt. Einen ¨
ahnlichen Aufbau beschreiben [TRS15, Kat15]. Gemeinsam ist beide Land-
6Dar¨
uberhinaus existieren weitere St¨
ucklisten wie z.B. die Strukturst¨
uckliste, die Variantenst¨
uckliste oder die
Verwendungsst¨
uckliste, welche jedoch f¨
ur das weitere Verst¨
andnis der Arbeit nicht notwendig sind.
29
2. Grundlagen
schaften, dass w¨
ahrend der verschiedenen Phasen der Entwicklung unterschiedliche Informati-
onssysteme verwendet werden.
Beispiel 5 (IT-Entwicklungslandschaft). Der Lebenszyklus der Entwicklung ist in Ab-
bildung 2.5 in Spezifikation,Geometrie,E/E und Software,Simulation und Berech-
nung sowie Test unterteilt. Die dargestellte Systemlandschaft stellt ein Idealbild dar, Ab-
weichungen sind m¨
oglich. Der Austausch von Produktdaten zwischen den verschiedenen
Informationssystemen erfolgt ¨
uber ein Produktdaten Backbone. Zur Unterst¨
utzung der
Entwicklung existiert eine Vielzahl an Prozessen [BHR05, BRB05, M¨
ul09], wovon ein Teil
durch Informationssysteme unterst¨
utzt werden, w¨
ahrend andere manuell gelebt werden.
Neben dem Projekt- und Stammdatenmanagement sind vor allem das St¨
ucklisten- und
¨
Anderungsmanagement essentiell. Da die Entwicklung von Komponenten und gesamten Sys-
temen h¨
aufig in Zusammenarbeit mit Lieferanten geschieht, ist die Integration von Liefe-
rantendaten eine weitere Herausforderung.
6WFNOLVWHQPDQDJHPHQW
0DVWHU'DWD0DQDJHPHQW
bQGHUXQJVPDQDJHPHQW
3URMHNWPDQDJHPHQW
/LHIHUDQWHQLQWHJUDWLRQ
$QIRUGHUXQJ
HQ &$' (&$'
(3'0 3ODQXQJ
6WFNOLVWHQ
3'0
+:6:
6LPXODWLRQV
GDWHQ 7HVWGRNX
,QIRUPDWLRQVV\VWHPH
)DFKSUR]HVVH
+:6:
$QIRUGHUXQJV
VSH]LILNDWLRQ
'HVLJQ
5HDOLVLHUXQJ
7HVW
$EQDKPH
90RGHOO
3URGXNWGDWHQ
%DFNERQH
,QIRUPDWLRQV
V\VWHP 'DWHQQXW]XQJ
(QWZLFNOXQJV
SKDVH
/HJHQGH 6FKQLWWVWHOOH
Abbildung 2.5.: Generische Systemlandschaft der Produktentwicklung im Automobilbereich (ange-
lehnt an [Kat15])
[Web14] detailliert weitere Prozesse der Produktentwicklung, zum Beispiel die virtuelle Produkt-
entwicklung oder das Qualit¨
atsmanagement, die im weiteren nicht ausgef¨
uhrt werden.
30
2.2. Produktentwicklung
Produktentwicklung
Der Produktentwicklungsprozess ist durch folgende Merkmale gekennzeichnet: Systeme und Kom-
ponenten werden in unterschiedlichen Zusammenarbeitsmodellen zwischen Herstellern und Zu-
lieferern entwickelt. Der Entwicklungsprozess verl¨
auft nach dem V-Modell [BR05], der sich grob
in die f¨
unf Phasen Anforderungsspezifikation,Design,Realisierung,Test und Abnahme
einteilen l¨
asst (vgl. Abbildung 2.5). Neben den zuvor genannten Prozessen wie Konfigurations-
und ¨
Anderungsmanagement [BRB05, BRB06] ist die Produktentwicklung in unterschiedliche
Fachprozesse unterteilt. Beispiele f¨
ur Fachprozesse sind etwa die Entwicklung von elektrischen
und elektronischen Komponenten, die virtuelle Produktentwicklung, die mechanische Konstruk-
tion, die Motorentwicklung und die Antriebsstrangentwicklung. Entlang dieser Fachprozesse
sind Meilensteine definiert, die vordefinierte Entwicklungsst¨
ande zu einem festen Zeitpunkt re-
pr¨
asentieren. Die Synchronisation der Fachprozesse erfolgt ¨
uber sog. Quality Gates7. An diesen
Punkten sind eindeutige Qualit¨
atskriterien festgelegt, die erf¨
ullt sein m¨
ussen, damit die Ent-
wicklung in die n¨
achste Entwicklungsphase ¨
ubergehen kann [PNSD07]. W¨
ahrend Quality Gates
zeitlich flexibel sind, besitzen Meilenstein feste Deadlines, was dazu f¨
uhrt, dass diese Deadlines
nicht immer eingehalten werden [PS14].
Beispiel 6 (Meilenstein). In Abbildung 2.6 existieren mehrere Meilensteine f¨
ur unter-
schiedliche Fachprozesse. Beispielsweise m¨
ussen in der mechanischen Konstruktion zun¨
achst
alle geometrischen Modelle und Zeichnungen freigegeben werden, bevor eine Kollisionsunter-
suchung durch digitale Mock-Ups (DMU)8durchgef¨
uhrt werden kann. Weitere Beispiele f¨
ur
Meilensteine sind die Absicherung der E/E-Architektur oder Hardware-in-the-Loop (HiL)9.
Beispiel 7 (Quality Gate). In Abbildung 2.6 sind drei Quality Gates dargestellt, d.h.
Lastenheft,Realisierung und Prototyp. Sie teilen den Entwicklungsprozess in unterschied-
liche Phasen ein. Der ¨
Ubergang von einer in die n¨
achste Phase geschieht nur, wenn die
zuvor definierten Qualit¨
atskriterien des Quality Gates erf¨
ullt sind. Beispielsweise kann die
Prototypen-Phase erst dann begonnen werden, wenn z.B. Geometrien und Konstruktions-
zeichnungen f¨
ur alle Komponenten freigegeben sind.
7Das System wird auch als Stage-Gate-System bezeichnet [Coo90]. Weitere Synonyme f¨
ur Gates bzw. Quality
Gates sind Gateways, Synchropunkte, Q-Checks, Moments of Truth [PS14].
8DMU ist die digitale Absicherung etwa zur Bestimmung von Kollisionen von Bauteilen durch geometrische
Modelle.
9HiL wird in sp¨
aten Entwicklungsphasen eingesetzt, um das Verhalten zwischen mehreren Bauteilen durch phy-
sische Prototypen zu simulieren. Umgebungsvariablen eines Fahrzeuges wie etwa die aktuelle Geschwindigkeit
oder Lenkwinkel werden durch Echtzeitrechner simuliert.
31
2. Grundlagen
6WDJH*DWH6\VWHP
0HFKDQLVFKH.RQVWUXNWLRQ
(((QWZLFNOXQJ
9LUWXHOOH3URGXNWHQWZLFNOXQJ
/HJHQGH 4XDOLW\*DWH 0HLOHQVWHLQ
(($UFKLWHNWXUDEJHVLFKHUW +DUGZDUHLQ
WKH/RRS
.ROOLVLRQVXQWHUVXFKXQJ
$EVLFKHUXQJ
5HDOLVLHUXQJ/DVWHQKHIW 3URWRW\S
)UMHGH.RPSRQHQWHLVW
GDV/DVWHUKDIWYROOVWlQGLJ
XQGIUHLJHJHEHQ
.RQ]HSWHVLQGDEJHVLFKHUW
*HRPHWULHXQG
=HLFKQXQJHQVLQG
IUHLJHJHEHQ
=HLFKQXQJHQ*HRPHWULH
IUHLJHJHEHQ
.RPSRQHQWHQODVWHQKHIWH
IUHLJHJHEHQ
Abbildung 2.6.: Stage-Gate-Modell am Beispiel von Fachprozessen
Konfigurationsmanagement
Wie anhand der Produktstruktur der Autot¨
ur bereits zu erkennen ist, besitzen Produkte va-
riable und optionale Bauteile. Die Gr¨
unde f¨
ur variable und optionale Bauteile sind vielf¨
altig:
Einerseits m¨
ochten Hersteller ihren Kunden die M¨
oglichkeit bieten, ein Produkt nach Vorlie-
ben und W¨
unschen zu w¨
ahlen, andererseits existieren in verschiedenen L¨
andern unterschiedliche
Rechtsgrundlagen, so dass Bauteile f¨
ur diese unterschiedlichen Gegebenheiten entwickelt werden
m¨
ussen. So existieren in der Europ¨
aischen Union und in den Vereinigten Staaten verschiedene
Grenzwerte f¨
ur Emissionen von Kraftfahrzeugen.
Merkmale eines Produktes, die zu Variabilit¨
at f¨
uhren, sind zum Beispiel geometrische Abmessun-
gen, physikalische Eigenschaften, Funktionalit¨
aten, Form, Ober߬
achen, Farben oder Materialien.
Neben dieser externen Variabilit¨
at, also durch den Kunden wahrnehmbare Unterschiede, exis-
tiert interne Variabilit¨
at. Beispiele f¨
ur letztere sind verschiedene Zulieferer f¨
ur gleiche Bauteile
in unterschiedlichen Produktionsst¨
atten.
Die Verwaltung von Produktmerkmalen wird als Konfigurationsmanagement bezeichnet und
definiert, welche Bauteile obligatorisch bzw. optional sind. Eine M¨
oglichkeit, Produktmerkmale
darzustellen, sind Feature-Diagramme [KCH`90].
Beispiel 8 (Feature-Diagramm). Abbildung 2.7 zeigt ein Feature-Diagramm f¨
ur die
zuvor beschriebene Autot¨
ur. Das Diagramm umfasst ingesamt 20 Features sowie mehrere
Constraints.DieFeaturesanklappbar,beheizt und erh¨
ohter Diebstahlschutz sind op-
tional, w¨
ahrend f¨
ur T¨
ursteuerger¨
at,Form,Glas,Lautsprecher und Design alternative
Varianten existieren.
Durch die dargestellten Features und Constraints lassen sich theoretisch 104 verschiedene Fahrer-
t¨
uren aufbauen. Die Auswahl variabler und optionaler Bauteile einer Produktstruktur wird als
Produktkonfiguration bezeichnet. Das damit verbundene Konfigurationsmanagement stellt si-
cher, dass nur sinnvolle, dass heißt baubare bzw. wirtschaftlich sinnvoll Produktkonfigurationen
gew¨
ahlt werden k¨
onnen. In der Praxis wird die Anzahl m¨
oglicher Konfigurationen auf eine
32
2.2. Produktentwicklung
)DKUHUWU
7UVWHXHUJHUlW 6SLHJHO /DXWVSUHFKHUHUK|KWHU'LHEVWDKOVFKXW] 'HVLJQ
0LQ 0D[ )RUP *ODV
6WDQGDUG $VSKlULVFK
DQNODSSEDU EHKHL]W 6WDQGDUG 3UHPLXP .ODVVLVFK 6SRUW
6WDQGDUG (&
/HJHQGH RSWLRQDO REOLJDWRULVFK DOWHUQDWLY
)HDWXUH
&RQVWUDLQWV
(&0D[
3UHPLXP0D[
Abbildung 2.7.: Feature-Diagramm einer Autot¨
ur
wirtschaftliche Anzahl eingeschr¨
ankt, um die Komplexit¨
at w¨
ahrend der Produktentwicklung zu
reduzieren.
Es existieren unterschiedliche Methoden, um variable und optionale Bauteile in der Produkt-
struktur abzubilden [Nob07]. Eine h¨
aufig verwendete Methode, variable Merkmale abzubilden,
besteht darin, diese mit Hilfe von Codes10 zu verschl¨
usseln11. Variable und optionale Bauteile
in der Produktstruktur der Autot¨
ur in Abbildung 2.4 sind mit Codes versehen. So sind etwa
die Bauteile, die zum Premium Soundsystem geh¨
oren, mit dem Code 58 versehen. W¨
ahrend der
Konfiguration einer Produktinstanz werden mit Hilfe logischer Operationen die gew¨
ahlten Codes
ausgewertet und so alle ben¨
otigten Bauteile ermittelt, die f¨
ur den Aufbau erforderlich sind.
¨
Anderungsmanagement
Wie bereits in Abschnitt 2.1.1 erw¨
ahnt, unterliegen Daten kontinuierlichen ¨
Anderungen. Integra-
ler Bestandteil der Produktentwicklung ist das ¨
Anderungsmanagement, welches ¨
Anderungsvor-
haben koordiniert und dadurch eine l¨
uckenlose Dokumentation von Bauteil¨
anderungen erm¨
oglicht
[Bob08]. Nach [Vi09] sind die folgenden Ursachen f¨
ur ¨
Anderungen an Bauteilen relevant:
•Gesetzliche ¨
Anderungen (z.B. Abgasvorschriften im Automobilbereich),
•¨
Anderungen der Markt- und Konkurrenzbedingungen,
•Interne Verbesserungen in Entwicklung, Planung oder Produktion,
•Qualit¨
ats- und Sicherheitsprobleme,
•Ausnutzung zus¨
atzlicher Optimierungspotenziale
In Abbildung 2.8 ist ein vereinfachter ¨
Anderungsprozess (Engineering-Change-Prozess) illus-
triert, der aus vier Schritten besteht. Zun¨
achst wird ein Problem beschrieben bzw. ein ¨
Anderungs-
grund identifiziert. Anschließend werden m¨
ogliche L¨
osungen f¨
ur das Problem gesucht und doku-
mentiert. Ein Entscheidungsgremium stimmt auf Basis dieser Informationen ¨
uber die ¨
Anderung
10Weitere Synonyme in der Literatur sind etwa Ausstattungen,Merkmale,Schl¨
usselelemente und Optionen
11Diese wurden bereits in der Strukturliste und der Produktstruktur in Abschnitt 2.2.2 verwendet, vgl. Abbildung
fig:productstructure
33
2. Grundlagen
ab. Wird diese genehmigt, erfolgt die Umsetzung. In der Literatur lassen sich noch weite-
re ¨
Anderungsprozesse finden, die weitere Aktivit¨
aten wie etwa die Umsetzungs¨
uberwachung
ber¨
ucksichtigen [Sta11, RBRB06].
,GHQWLILNDWLRQ /|VXQJVVXFKH $EVWLPPXQJ
5HDOLVLHUXQJ
/HJHQGH
$EOHKQXQJ
3HUVRQ *UHPLXP
Abbildung 2.8.: Beispiel f¨
ur einen Engineering-Change-Prozess
2.3. Integration
Die vorliegende Arbeit fokussiert auf die Integration heterogener Produktdaten aus autonomen
Informationssystemen. Das Forschungsfeld der Integration reicht bis in die Anf¨
ange der Daten-
verarbeitung zur¨
uck und ist auch weiter ein aktiver Untersuchungsbereich. Im Folgenden werden
die grundlegenden Prinzipien erl¨
autert.
Der Begriff Integration beschreibt das Zusammenf¨
uhren von Artefakten, die semantisch zusam-
mengeh¨
oren, jedoch ¨
uber heterogene Quellen (z.B. Informationssysteme) verteilt sind. Nach
[LN06] ergeben sich drei Grundprobleme, die bei der Integration von Informationssystemen
ber¨
ucksichtigt werden m¨
ussen: Autonomie,Verteilung und Heterogenit¨
at.
F¨
ur die Integration heterogener Informationssysteme sind im Laufe der Zeit verschiedenen Tech-
niken entstanden. Dazu z¨
ahlen das Schema Matching,dieDuplikaterkennung und die verteilte
Anfrageverarbeitung. Im Folgenden werden die grundlegende Terminologie eingef¨
uhrt und an-
schließend die Integration in verschiedene Kategorien klassifiziert. Allgemeine Begriffe wie Inte-
gration und Korrespondenzen beziehen sich im weiteren Verlauf der Arbeit auf die Integration
autonomer, heterogener Produktdaten.
2.3.1. Terminologie
Wie bereits erl¨
autert, kommen w¨
ahrend der Produktentwicklung unterschiedliche Informations-
systeme zum Einsatz, die wie folgt definiert sind:
Definition 7 (Informationssystem). Ein Informationssystem ist ein Softwaresystem zur
Ausf¨
uhrung betrieblicher Abl¨
aufe, welches die Erfassung, Verarbeitung, Speicherung und
¨
Ubertragung von Informationen automatisiert. Wir unterscheiden zwischen einem globalen
Informationssystem, welches eine einheitliche Sicht auf eine Vielzahl autonomer, heterogener
Informationssysteme durch Integration bietet. Letztere werden als lokale Informationssys-
teme bezeichnet.
34
2.3. Integration
Bei der Produktentwicklung dienen Informationssysteme der Unterst¨
utzung spezifischer Ent-
wicklungsaufgaben. Dar¨
uber hinaus m¨
ussen Anwendungsf¨
alle unterst¨
utzt werden, die Produkt-
daten aus mehreren Informationssystemen ben¨
otigen.
Definition 8 (Anwendungsfall). In Rahmen der Produktentwicklung bezeichnet ein
Anwendungsfall (AF)die Nutzung von integrierten Produktdaten aus heterogenen Informa-
tionssystemen zur Realisierung fachlicher Aufgaben. Beispiele f¨
ur solche Aufgaben sind:
•Suche / Reports,
•Dokumentationsgenerierung,
•Navigation / Visualisierung,
•Konsistenz-, Vollst¨
andigkeits- und Plausibilit¨
ats¨
uberpr¨
ufung und
•Berechnungen.
Beispiel 9 (Anwendungsfall). Abbildung 2.9 zeigt einen Anwendungsfall f¨
ur die Kon-
sistenz¨
uberpr¨
ufung von Anforderungsspezifikationen f¨
ur mechatronische Komponenten mit
den entsprechenden Funktionsmodellen. Ziel der ¨
Uberpr¨
ufung ist es festzustellen, ob f¨
ur alle
Komponenten entsprechende Funktionsmodelle vorhanden sind. Da die Komponenten durch
unterschiedliche Zulieferer erstellt werden, k¨
onnen heterogene Informationssysteme zur Mo-
dellierung zum Einsatz kommen. Nach der Integration ist es m¨
oglich, ¨
Anderungen sowohl
an den Anforderungsspezifikationen als auch den Funktionsmodellen nachzuvollziehen. Dazu
werden mit Hilfe der Korrespondenzen zwischen den Artefakten zusammengeh¨
orige Doku-
mente ermittelt, die dann von Fachanwendern gesichtet werden k¨
onnen.
YVP
$QIRUGHUXQJHQ
)XQNWLRQVPRGHOOH
LQWHUQ
6LPXOLQN
GRF
)XQNWLRQVPRGHOOH
=XOLHIHUHU$
9LV6LP
)XQNWLRQVPRGHOOH
=XOLHIHUHU%
9LVXDO6LP
P
P YVP
[PO
[PO
[PO
GRF
GRF
GRF
GRF
GRF
,QIRUPDWLRQVV\VWHPH
2(0 6XSSOLHU
3URGXNWGDWHQ
"
"
"
Abbildung 2.9.: Anwendungsfall
Die Realisierung von Anwendungsf¨
allen wird durch die Produktdatenintegration erm¨
oglicht, die
folgendermaßen definiert ist:
35
2. Grundlagen
Definition 9 (Produktdatenintegration). Produktdatenintegration ist der Prozess der
Integration autonomer, heterogener Produktdaten und dessen unterschiedliche Produktda-
ten aus lokalen Informationssystemen in eine zentrale Wissensbasis. Die Verwaltung dieser
Wissensbasis geschieht durch ein globales Informationssystem, auch Produktdatenintegrati-
onssystem (PDIS)genannt, welches die notwendigen Funktionalit¨
aten bereitstellt, um Pro-
duktdaten zu integrieren, auf ¨
Anderungen zu reagieren und Abfragen integrierter Produkt-
daten zu erm¨
oglichen.
Wie erw¨
ahnt, m¨
ussen sowohl die Schemata als auch die Daten heterogener Informationssysteme
integriert werden. Auf Grund der verschiedenen Datenmodelle, die bei der Realisierung lokaler
Informationssysteme zum Einsatz kommen, m¨
ussen die verschiedenen Begriffe vereinheitlicht
werden. Dazu definieren wir Schemakonzepte (engl. schema concepts, SC) und Instanzen (engl.
individuals, Ind) folgendermaßen:
Definition 10 (Schemakonzept). Ein Schemakonzept (engl. schema concept, SC)mo-
delliert in einem semantischen Datenmodell (z.B. ER-/UML-Diagramm) eine Menge von
Dingen der physischen Welt durch die Definition von Attributen (vgl. Definition 3). Zwi-
schen Schemakonzepten k¨
onnen Beziehungen definiert werden. Abh¨
angig vom Datenmodell
existieren weitere Synonyme, wie z.B. Klasse, Entit¨
atstyp, Relation, Typ oder Konzept. Das
Schema des PDIS wird im weiteren als globales Schema bezeichnet, w¨
ahrend Schemata von
Informationssystemen lokale Schemata heißen.
Konkrete Realweltobjekte werden im weiteren Verlauf der Arbeit als Instanzen bezeichnet. Sie
sind folgt definiert:
Definition 11 (Instanz). Ein Gegenstand einer Menge mit den gleichen Attributen
(Schemakonzept) wird als Instanz (engl. individual, Ind)bezeichnet. Jede Instanz kann Aus-
pr¨
agungen der Attribute in Form von Attributwerten haben. Je nach Datenmodell werden
die Synonyme Individuum, Auspr¨
agung, Objektinstanz, Datensatz, Tupel, Zeile, Entit¨
at
oder Objekt verwendet.
Ziel der Produktdatenintegration ist es, semantisch zusammengeh¨
orige Produktdaten zu identi-
fizieren. Deren Beziehungen werden als Korrespondenzen bezeichnet und sind wie folgt definiert:
Definition 12 (Korrespondenz). Eine Korrespondenz (engl. correspondence, Cor)ist
eine gerichtete Beziehung zwischen zwei oder mehreren Artefakten (Schemakonzept, In-
stanz, Attribut, Attributwert). Die Beziehung bedeutet, dass die korrespondieren Artefakte
in der Realwelt semantisch zusammengeh¨
oren, sie bedeutet jedoch nicht automatisch deren
¨
Aquivalenz. Zwischen zwei Artefakten k¨
onnen mehrere Korrespondenzen existieren. Kor-
respondenzen k¨
onnen mit einem numerischen Maß versehen sein, welches den Grad der
¨
Ahnlichkeit zwischen zwei Artefakten beschreibt. Korrespondenzen zwischen Schemakon-
zepten werden Schemakonzept-Korrespondenz und die zwischen zwei Instanzen als Instanz-
Korrespondenz bezeichnet.
Der Prozess zum Auffinden von Korrespondenzen wird als Matching-Prozess bezeichnet, die
Menge der gefundenen Korrespondenzen zwischen zwei Informationssystemen wiederum nennt
man Mapping:
36
2.3. Integration
Definition 13 (Matching). Matching bezeichnet den Prozess, Korrespondenzen zwischen
Artefakten (Schemakonzepte, Schemaattribute, Instanzen) zu finden. In der Regel soll dieser
Prozess soweit wie m¨
oglich automatisch ablaufen. In der Praxis werden jedoch manuelles
Eingreifen bzw. Korrigieren von Korrespondenzen notwendig.
Definition 14 (Mapping). Das Ergebnis des Matching ist das Mapping, welches alle er-
mittelten gerichteten Korrespondenzen zwischen Artefakten zweier unterschiedlicher Infor-
mationssysteme enth¨
alt. Das Mapping kann anhand unterschiedlicher Qualit¨
atsdimensionen
untersucht werden, wodurch auch die Qualit¨
at der Integration bestimmt werden kann.
Beispiel 10 beinhaltet alle zuvor definierten Begriffe.
Beispiel 10 (Terminologie). In Abbildung 2.10 werden die verschiedenen Begriffe an
Hand eines Beispiels illustriert. Das konzeptionelle Datenmodell des lokalen Informations-
system A basiert auf dem relationalen Datenmodell und ist als ER-Diagramm illustriert,
das Datenmodell des lokalen Informationssystems B hingegen wird mit Hilfe eines UML-
Klassendiagramms dargestellt. Im Zuge der Integration wurden Korrespondenzen zwischen
dem Schemakonzept Entity X und Class B sowie dem Concept aus dem globalen Informa-
tionssystem ermittelt. Weiter wurden auch Korrespondenzen zwischen Instanzen der Sche-
makonzepte bestimmt.
/RNDOHV,QIRUPDWLRQV\VWHP%
80/.ODVVHQGLDJUDPP
/RNDOHV,QIRUPDWLRQV\VWHP$
(U'LDJUDPP
(QWLW\<
$WWULEXWH
(QWLW\;
$WWULEXWH
$WWULEXWH $WWULEXWH
$WWULEXWH
&ODVV$
$WWULEXWH
$WWULEXWH
&ODVV%
$WWULEXWH
6FKHPDNRQ]HSW ,QVWDQ] ,QVWDQ].RUUHVSRQGHQ]
(QWLW\; &ODVV$
3URGXNWGDWHQLQWHJUDWLRQVV\VWHP
&RQFHSW
/HJHQGH
6FKHPD.RUUHVSRQGHQ]
Abbildung 2.10.: Terminologiebeispiel
37
2. Grundlagen
2.3.2. Klassifikation
[LN06] definiert die Informationsintegration als ”... die korrekte, vollst¨
andige und effiziente
Zusammenf¨
uhrung von Daten und Inhalt verschiedener, heterogener Quellen zu einer einheit-
lichen und strukturierten Informationsmenge zur effektiven Interpretation durch Nutzer und
Anwendungen.“ W¨
ahrend in diesem Fall die Informationsintegration nur die Integration von
Daten umfasst, definieren andere Autoren weitere Ebenen der Integration [LBK07]. [Was90]
f¨
uhrt f¨
unf Ebenen der Tool-Integration ein. Die Plattform-Integration erm¨
oglicht Interoperabi-
lit¨
at verschiedener Systeme, in dem diese auf einer virtuellen Operationsschicht laufen. Mit der
Pr¨
asentationsintegration wird ein einheitliches und konsistentes ”Look and Feel”geschaffen. F¨
ur
die Datenintegration schl¨
agt [Was90] ein gemeinsames Repository vor, welches den Datenaus-
tausch zwischen Systemen erm¨
oglicht. Mit Kontrollintegration wird die F¨
ahigkeit eines Systems
bezeichnet, sich ¨
uber Ereignisse zu benachrichtigen und Funktionen anderer Applikationen aus-
zul¨
osen12. Schließlich sorgt die Prozessintegration f¨
ur einen einheitlichen Prozess zur Steuerung
der Aktivit¨
aten ¨
uber die unterschiedlichen Systemgrenzen hinweg. Abbildung 2.11 verdeutlicht
die unterschiedlichen Ebenen der Tool-Integration. Die verschiedenen Ebenen m¨
ussen jeweils
unter dem Aspekt technischer, struktureller und semantischer Heterogenit¨
at betrachtet werden.
Abbildung 2.11.: Verschiedene Ebenen der Integration
Im weiteren Verlauf der Arbeit wird auf die Schema- und Datenintegration fokussiert, w¨
ahrend
die anderen Ebenen nicht im Fokus stehen.
2.3.3. Integrationsprozess
F¨
ur die Schema- und Datenintegration definiert [BN09] folgende generischen Integrationsprozess
(siehe Abbildung 2.12): Zun¨
achst wird ein Mapping (siehe Definition 14) zwischen den zu inte-
grierenden Datenquellen definiert. Anschließend erfolgt die Duplikaterkennung der Datens¨
atze,
bei dem Artefakte, welche die selben Realweltobjekte repr¨
asentieren, einander zugeordnet wer-
den. Danach erfolgt die Datenfusion, das heißt das Zusammenf¨
uhren der Attributwerte in eine
einheitliche Form. Schließlich k¨
onnen die integrierten Daten durch Applikationen genutzt wer-
den. Zu jeder Phase existiert eine Vielzahl an wissenschaftlichen Ans¨
atzen, die in Kapitel 4
ausf¨
uhrlich diskutiert werden.
0DSSLQJ 'XSOLNDW
HUNHQQXQJ 'DWHQIXVLRQ $SSOLNDWLRQ
'DWHQTXHOOHQ
DEELOGHQ
]XVDPPHQJHK|ULJH
5HDOZHUWREMHNWHEHVWLPPHQ
$WWULEXWH
YHUHLQKHLWOLFKHQ
,QIRUPDWLRQVV\VWHPH
NRQVROLGLHUWH
'DWHQQXW]HQ
Abbildung 2.12.: Generischer Integrationsprozess
12In anderen Arbeiten wird an dieser Stelle auch von Funktionsintegration gesprochen.
38
2.3. Integration
2.3.4. Architekturen
Integrationsans¨
atze f¨
ur Schemata und Daten unterscheiden sich in der Art, wie die Integration
der Daten erfolgt. Hier muss zwischen virtuellen und materialisierenden Ans¨
atzen unterschieden
werden. Abbildung 2.13 zeigt die zwei grundlegenden Architekturen f¨
ur die Integration hetero-
gener Datenquellen [DHI12].
•Bei Ans¨
atzen der ersten Kategorie (siehe Abbildung 2.13 a
) werden Daten aus autono-
men, heterogenen Informationssystemen in ein gemeinsames, zentrales Informationssystem
kopiert und dort integriert. Anfragen an das zentrale Informationssystem werden nur auf
den integrierten Daten ausgef¨
uhrt.
•Ans¨
atze der zweiten Kategorie (siehe 2.13 b
) kopieren keine Daten, sondern belassen diese
im urspr¨
unglichen Informationssystem. Anfragen werden an ein gemeinsames Schema ¨
uber
ein Integrationssystem gestellt; anschließend zerlegt diese die Anfrage und erzeugt Abfragen
an die einzelnen heterogenen Informationssysteme. Letztere verarbeiten die Abfragen lokal
und schicken die Ergebnisse an das Integrationssystem zur¨
uck. Dieses ist schließlich f¨
ur die
Zusammenf¨
uhrung bzw. Integration der Daten verantwortlich.
,QWHJUDWLRQVV\VWHP,QWHJUDWLRQVV\VWHP
*HPHLQVDPHV
6FKHPD
([WUDFWRU ([WUDFWRU([WUDFWRU
,QIRUPDWLRQV
V\VWHP
,QIRUPDWLRQV
V\VWHP
'DWHQ
([HFXWLRQ
(QJLQH
:UDSSHU :UDSSHU:UDSSHU
,QIRUPDWLRQV
V\VWHP
,QIRUPDWLRQV
V\VWHP
'DWHQ
*HPHLQVDPHV
6FKHPD
,QWHJUDWLRQ,QWHJUDWLRQ
,QWHJUDWLRQ
$EIUDJH $EIUDJH$EIUDJH
$QIUDJH $QIUDJH
D E
Abbildung 2.13.: Integrationsarchitekturen nach [DHI12]
Die beiden Ans¨
atze haben ihre Vor- und Nachteile. Da bei materialisierten Ans¨
atzen, neue Da-
tens¨
atze erst integriert werden m¨
ussen und virtualisierte Ans¨
atze nur mit Quelldaten arbeiten,
ist die Aktualit¨
at bei Ans¨
atzen der zweiten Kategorie besser. Auf der anderen Seite m¨
ussen die
Anfragen bei virtuellen Ans¨
atzen zun¨
achst durch lokale Informationssysteme verarbeitet wer-
den, wodurch es zu einer Verz¨
ogerung bei Anfragen kommt. Materialisierte Ans¨
atze besitzen
gegen¨
uber den virtuellen Ans¨
atzen einige Vorteile. So sind die Daten vollst¨
andig integriert und
k¨
onnen vorher um Fehler bereinigt werden, wodurch die Informationsqualit¨
at h¨
oher sein kann
39
2. Grundlagen
als bei virtuellen Ans¨
atzen. Anfrageplanung und -bearbeitung k¨
onnen bei virtuellen Ans¨
atzen
sehr komplex werden und die Vollst¨
andigkeit der Integration kann auf Grund der h¨
oheren Au-
tonomie nicht garantiert werden. F¨
allt ein Informationssystem aus oder kann eine Anfrage des
Integrationssystems nicht verarbeiten, fehlen diese Informationen in der Integration.
Ist die Datenqualit¨
at der heterogenen Informationssysteme sehr unterschiedlich, k¨
onnen die In-
tegrationssysteme in beiden Architekturen die Duplikaterkennung und Datenfusion nicht voll-
st¨
andig automatisieren. In diesem Fall ist manuelle Unterst¨
utzung durch Endanwender in beiden
Ans¨
atzen erforderlich.
2.3.5. Integrationsstrategien
Sobald mehrere Quellen integriert werden sollen, gibt es verschiedene Strategien, die in Abbil-
dung 2.14 illustriert sind. Die erste M¨
oglichkeit besteht darin, alle vorhandenen Quellen gleich-
zeitig zu integrieren (siehe Abbildung 2.14 a), d.h. zusammengeh¨
orige semantische Konzepte
aller Schemata gleichzeitig zu betrachten. Bei sehr vielen Quellen mit einer Vielzahl an Kon-
zepten kann diese Vorgehensweise einen Integrationsverantwortlichen mit zu vielen Informatio-
nen ¨
uberfordern. Auf der anderen Seite kann die Betrachtung aller Schemata auf einmal die
M¨
oglichkeit bieten, Gemeinsamkeiten zwischen verschiedenen Schemata zu identifizieren. Eine
weitere M¨
oglichkeit ist die bin¨
are Integration von Quellen (siehe Abbildung 2.14 b). Dazu werden
jeweils zwei Quellen zu einem Zwischenschema integriert, und zwei Zwischenschemata wiederum
zu einem neuen Schema. Dieses Problem wiederholt sich solange, bis nur noch ein Schema ¨
ubrig
bleibt. Der Vorteil ist, dass wesentlich weniger Konzepte auf Gemeinsamkeiten hin analysiert
werden und Integrationsverantwortliche mit weniger Komplexit¨
at zurecht kommen m¨
ussen.
Da nicht jedes Schema mit jedem anderen Schema direkt verglichen wird, kann es vorkommen,
dass Zusammenh¨
ange zwischen Schemakonzepten unterschiedlicher Quellen ¨
ubersehen werden
k¨
onnen. Eine abgewandelte Form der bin¨
aren Integration ist die gewichtete Integration (siehe
Abbildung 2.14 c). Dabei wird ein Schema identifiziert, welches am wichtigsten f¨
ur die Integration
ist, da es z.B. die meisten Konzepte einer Dom¨
ane enth¨
alt. Bei diesem Vorgehen wird dieses
Schema schrittweise mit einem weiteren Schema zu Zwischenschemata integriert. Letzteres wird
dann mit dem n¨
achsten Schema zum n¨
achsten Zwischenschema integriert. Dieser Vorgang wird
solange wiederholt, bis alle Schemata integriert sind.
D E F
/HJHQGH
4XHOOH =ZLVFKHQVFKHPD =LHOVFKHPD
Abbildung 2.14.: Integrationsstrategien
40
2.3. Integration
2.3.6. Integrationskonflikte
H¨
aufigstes Problem bei der Integration von Informationssystemen sind unterschiedliche Arten
von Heterogenit¨
at. ”Heterogenit¨
at herrscht, wenn sich zwei miteinander verbundene Informati-
onssysteme syntaktisch, strukturell oder inhaltlich unterscheiden.“ [LN06]. Die Gr¨
unde f¨
ur He-
terogenit¨
at sind vielf¨
altig und durch unterschiedliche Faktoren bedingt: Informationssysteme
basieren auf unterschiedlichen technischen Plattformen (etwa .NET, J2EE), wodurch technische
Heterogenit¨
at entsteht. Zu letzterer geh¨
oren auch die Verwendung unterschiedlicher Kommunika-
tionsprotokolle (z.B. CORBA, Web Services) oder verschiedene Schnittstellen. Dar¨
uber hinaus
werden Informationssysteme durch unterschiedliche Datenmodelle (relational, objektorientiert
oder hierarchisch) realisiert. Innerhalb dieser k¨
onnen sowohl strukturelle als auch semantische
Heterogenit¨
at auftreten. Sowohl bei der virtuellen als auch bei der materialisierten Integration
f¨
uhren diese Arten von Heterogenit¨
at zu unterschiedliche Konflikten. Diese k¨
onnen sowohl auf
der Schema- als auch Instanzebene auftreten.
Schemakonflikte
Schemakonflikte betreffen die erste Phase des generischen Integrationsprozesses (siehe Abschnitt
2.3.3). In diesem Schritt werden Abbildungen zwischen Konzepten heterogener Datenmodelle
definiert. Zu den Schemakonflikten z¨
ahlen alle Heterogenit¨
atsprobleme, die bei der Abbildung
von Schemakonzepten aus unterschiedlichen Quellen resultieren k¨
onnen. Im Folgenden werden
die wichtigsten Konflikte kurz erl¨
autert.
Beispiel 11 (Schemakonflikte). In Abbildung 2.15 sind die konzeptionellen Schemata
zweier Informationssysteme illustriert, die ¨
uberlappende Konzepte besitzen. Im Speziellen
dokumentieren beide Schemata die Bauteilaspekte eines Produktes. W¨
ahrend Informati-
onssystem A alle Bauteile (mechanische, elekromechanische, elektronische und elektrische)
dokumentiert, werden in Informationssystem B lediglich elektromechanische, elektrische und
elektronische Bauteile verwaltet.
Neben der technischen Heterogenit¨
at beider Informationssystemeatreten unterschiedliche
Schemakonflikte bei der Integration beider Schemata auf. Der Bauteilname im relationalen
Schema Aist synonym mit dem Bezeichner (label)vonComponent in B. Im Speziellen ist
Component eine Teilmenge von Bauteil.
W¨
ahrend der Herstellername eines Bauteils in Amittels einer Entit¨
at modelliert ist, wird
dieser in Schema Bdurch ein Attribut realisiert. Das Bauteilgewicht wird in Ain Gramm
angegeben, w¨
ahrend die Einheit Unzen in Schema Bverwendet wird. Auf der anderen Seite
wird der Verantwortliche eines Bauteils in Adurch zwei Attribute (RespName,RespFirst)
in Bmodelliert.
aInformationssystem A basiert auf dem relationalen Schema und wird mit einem Datenbankmanagementsys-
tem realisiert w¨
ahrend Informationssystem B in UML modelliert ist und Instanzen in Dateien persistiert.
Das Mapping (siehe Abschnitt 2.3.1) zwischen Aund Bist in Tabelle 2.1 informell dargestellt.
W¨
ahrend die Schemakonzepte aus Aund Baufeinander abgebildet werden konnten, ist keine der
Korrespondenzen zwischen Aund Bausreichend, um deren Instanzen einander eindeutig zuordnen
zu lassen. Einzige M¨
oglichkeit in diesem Fall w¨
are die Definition einer Mapping-Tabelle zwischen
der Bauteilnummer aus Aund der ID von Component aus B.
41
2. Grundlagen
,QIRUPDWLRQV\VWHP%
80/.ODVVHQGLDJUDPP
,QIRUPDWLRQV\VWHP$
(5'LDJUDPP
%DXWHLO
1U
3URGXNW
*HZLFKW
1DPH
1DPH
5HVSRQVLEOH
3URMHFW
,'
/DEHO
6XSSOLHU
5HVS1DPH
5HVS)LUVW
:HLJKW
&RPSRQHQW
7\S
)ODVKDEOH
(&8
5HVLVWDQFH
6HQVRU
+HUVWHOOHU
1U
$GGUHVV
1DPH
7\SH
$FWXDWRU
9HUDQWZRUWOLFKHU
(&8,' ³´!
/DEHO!(QJLQH&RQWURO/DEHO!
6XSSOLHU!0RWRU,QF6XSSOLHU!
5HVS1DPH!0XVWHUPDQQ5HVS1DPH!
5HVS)LUVW!0D[5HVS)LUVW!
:HLJKW!R]:HLJKW!
)ODVKDEOH!WUXH)ODVKDEOH!
(&8!
1U_1DPH_*HZLFKW_7\S_9HUDQWZRUWOLFKHU
_0RWRU_J_(_0D[0XVWHUPDQQ
_«_«_«_«
5HODWLRQDO'DWHQEDQNWDEHOOH ;0/6HULDOLVLHUXQJ
Abbildung 2.15.: Beispiele f¨
ur strukturelle und semantische Heterogenit¨
at
Im obigen Beispiel treten eine Vielzahl an Schemakonflikten auf. So ist die Benennung zwischen
synonymen Konzepten und Attributen unterschiedlich. Weiter werden gleiche Sachverhalte un-
terschiedlich modelliert. So ist der Herstellername in Aein Attribut eines eigenen Konzeptes
w¨
ahrend dieser in Blediglich als Attribut desselben Konzeptes modelliert wird.
Neben den bereits erl¨
auterten Integrationskonflikten existieren noch weitere. So k¨
onnen Tabel-
len mit gleichem Namen unterschiedliche semantische Inhalte besitzen (die Namen werden in
diesem Fall als Homonyme bezeichnet). Auch wenn zwei Tabellen die gleiche Bezeichnung haben
und den selben Inhalt beschreiben, k¨
onnen Strukturprobleme auftreten. Attribute die in einem
Konzept dokumentiert sind, k¨
onnen im synonymen Konzept fehlen oder implizit modelliert sein.
Schließlich k¨
onnen die Integrit¨
atsbedingungen von Konzepten in den Quellen unterschiedlich
Informationssystem A Beziehung Informationssystem B
Bauteil beinhaltet Component
Bauteil.Name gleich Component.RespFirst + Component.RespName
Bauteil.Gewicht gleich Component.Weight * 0.035274
Hersteller.Name gleich Component.Supplier
Tabelle 2.1.: Mapping zwischen Informationssystem A und B
42
2.3. Integration
sein. F¨
ur eine detaillierte Diskussion der weiteren Integrationskonflikte bei der Integration von
relationalen Datenmodellen wird auf [KS91] verwiesen.
Datenkonflikte
Neben den Konflikten auf der Schemaebene treten auch Konflikte bei der Integration von Instan-
zen auf. Daten k¨
onnen in unterschiedlichen Einheiten repr¨
asentiert sein (z.B. Gewicht, L¨
ange,
Zeit, W¨
ahrungen). M¨
ussen Einheiten untereinander konvertiert werden, k¨
onnen diese durch
Genauigkeitsverluste verf¨
alscht werden. H¨
aufiges Beispiel f¨
ur die Repr¨
asentation von gleichen
Sachverhalten sind Adressdaten [LN06], die unterschiedlich geschrieben werden (z.B. Karlstras-
se, Karl Str. und Karl Strasse). Weiter k¨
onnen Daten falsch dokumentiert sein, etwa wenn sie
manuell ¨
ubertragen wurden (z.B. durch Tippfehler). Schließlich tritt Heterogenit¨
at zwischen
Datens¨
atzen auf, wenn diese zu unterschiedlichen Zeitpunkten aktualisiert werden bzw. Aktua-
lisierungen nicht an nachfolgende Informationssysteme propagiert werden.
[BS06] definiert zwei Typen von Datenkonflikten: Ein key-Konflikt tritt bei der Integration von
zwei Relationen auf, wenn die Attributwerte von Instanzen in beiden Quellen identisch sind,
sich jedoch dessen Prim¨
arschl¨
ussel unterscheiden. Existieren im umgekehrten Fall von Instanzen
mit gleichen Prim¨
arschl¨
ussel und unterschiedlichen Werten f¨
ur weitere Attribute, handelt es sich
um attribute-Konflikte. W¨
ahrend letztere relativ einfach zu identifizieren sind, m¨
ussen im ersten
Fall die Attributwerte aller Instanzen aus beiden Relationen miteinander verglichen werden, um
m¨
oglich Konflikte zu identifizieren.
Beispiel 12 (Datenkonflikte). Abbildung 2.16 zeigt ein Beispiel f¨
ur Attribut- und
Schl¨
usselkonflikte. Tabelle A und Tabelle B sollen integriert werden, und es wird an-
genommen, dass keine schematischen Konflikte zwischen den beiden Tabellen existieren.
F¨
ur die Instanzen mit der Nr. 268 tritt ein Konflikt f¨
ur die korrespondierenden Attribu-
te Verantwortlicher und Responsible auf, da in beiden Tabellen verschiedene Werte
vorhanden sind. Des weiteren korrespondieren der Eintrag mit der Nr 921 aus Tabelle A
zum Eintrag mit der Nr 931 aus Tabelle B,das
¨
amtliche Attribute identische Werte besit-
zen. Da beide Instanzen unterschiedliche Prim¨
arschl¨
ussel besitzen, liegt in diesem Fall ein
Prim¨
arschl¨
usselkonflikt (Key-Konflikt) vor.
Semantische Konflikte
Semantische Heterogenit¨
at ist ein Begriff, der in vielen Disziplinen unterschiedlich verwendet
wird [Col97]. Nach [Ver97] umfasst diese Form alle Unterschiede in Bedeutung, Interpretation
und Art der Nutzung. Nach [LN06] liegt semantische Heterogenit¨
at vor, ”wenn unterschiedli-
che Elemente des Datenmodells verwendet werden, um denselben Sachverhalt zu modellieren.“.
Als Beispiel geben die Autoren das relationale Datenmodell an, bei dem derselbe Sachverhalt
entweder durch eine Relation, ein Attribut oder einen Attributwert modelliert werden kann.
Beispiel 13 (Semantische Heterogenit¨
at). Abbildung 2.17 zeigt ein Beispiel f¨
ur se-
mantische Heterogenit¨
at. Die Entit¨
aten in a), b) und c) beschreiben den selben Sachverhalt
(den Typ einer Komponente), jedoch mit unterschiedlichen Mitteln des relationalen Daten-
modells. In a) wird f¨
ur jeden Typ eine eigene Entit¨
at modelliert, w¨
ahrend in b) die vorhan-
43
2. Grundlagen
1U
«
1DPH
0RWRUVWHXHUXQJ
)HQVWHUKHEHUPRWRU
5DGDUVHQVRU
«
9HUDQWZRUWOLFKHU
0D[0XVWHUPDQQ
.DUO6FKPLGW
)UDQ]0OOHU
«
*HZLFKW
J
J
J
«
1U
«
/DEHO
0RWRUVWHXHUXQJ
)HQVWHUKHEHUPRWRU
5DGDUVHQVRU
«
5HVSRQVLEOH
0D[0XVWHUPDQQ
-RKDQQHV%DXHU
)UDQ]0OOHU
«
:HLJKW
R]
R]
R]
«
7DEHOOH$
7DEHOOH%
Abbildung 2.16.: Beispiele f¨
ur Attribut- und Schl¨
usselkonflikte
denen Typen als Attribut einer Entit¨
at ausgedr¨
uckt werden. In c) wird der Typ durch einen
Attributwert realisiert.
Ein weiteres Beispiel f¨
ur semantische Heterogenit¨
at wurde bereits im obigen Beispiel (siehe
Abbildung 2.15) angesprochen. Die Begriffe Bauteil und Component stehen synonym f¨
ur
einander. Jedoch ist ihre Bedeutung unterschiedlich. W¨
ahrend der erste Begriff alle Bauteile
eines Produktes beschreibt, sind mit dem zweiten Begriff nur diejenigen Bauteile gemeint,
die einen E/E-Anteil besitzen.
(&8
1U
6HQVRU 5HVS
/DEHO
:HLJKW
1U
$FWXDWRU 5HVS
/DEHO
:HLJKW
1U
&RPSRQHQW
5HVS
/DEHO
:HLJKW
6HQVRU
(&8
$FWXDWRU
1U
&RPSRQHQW 5HVS
/DEHO
:HLJKW
7\SH
1U
5HVS
/DEHO
:HLJKW
D
E F
Abbildung 2.17.: Beispiele f¨
ur semantische Heterogenit¨
at (relationales Datenmodell)
44
2.4. Informationsqualit¨
at
2.4. Informationsqualit¨at
Nachdem die grundlegenden Integrationsbegriffe erl¨
autert wurden, werden nun fundamentale
Begriffe zur Beschreibung und Bestimmung von Informationsqualit¨
at beschrieben. Es existiert
kein einheitlicher Begriff f¨
ur die Qualit¨
at von Daten und Informationen. Neben der ”fitness for
use“ nach [JG99], stammt die verbreiteste Definition aus der ISO 9000-Normreihe und ist sehr
abstrakt gehalten. Sie bezeichnet die Qualit¨
at von Daten, als den Grad den eine Menge an
Charakteristiken gegebene Anforderungen erf¨
ullt [Hoy09].
Bei der Kategorisierung von Qualit¨
atskriteren erfolgt eine Unterscheidung in die verschiede-
nen Ebenen, die bei der Integration von Produktdaten relevant sind. Dazu z¨
ahlen neben der
Schemakonzept- und Instanzebene auch die Ebene der Korrespondenzen zwischen Schamkon-
zepten sowie zwischen Instanzen.
2.4.1. Schemakonzeptqualit¨at
[Red97] definiert folgende Dimensionen f¨
ur die Qualit¨
at eines konzeptionellen Schemas: Kor-
rektheit bezieht sich sowohl auf das Modell, dass heißt, ob ein Datenmodell den syntaktischen
Vorgaben entspricht, als auch auf die korrekte Abbildung von Anforderungen der Realit¨
at im
Modell. Im Falle des relationalen Datenmodells sind damit unter anderem Kardinalit¨
aten und
Integrit¨
atsbedingungen gemeint. Ferner ist ein Schema minimal, wenn alle Anforderungen im
Modell repr¨
asentiert sind und keine Elemente entfernt werden k¨
onnen, ohne dass dadurch An-
forderungen unber¨
ucksichtigt bleiben. Die Vol lst¨
andigkeit misst den Grad, den ein konzeptuelles
Schema f¨
ur spezifische Anforderungen erf¨
ullt. Die Relevanz bestimmt die Anzahl an unn¨
otigen
konzeptuellen Elementen im Modell. Die visuelle Repr¨
asentation eines konzeptionellen Schemas
wird als lesbar bezeichnet, wenn bestimmte ¨
asthetische Eigenschaften, wie etwa Kompaktheit
der Darstellung, gegeben sind. Schließlich sind f¨
ur das relationale Datenmodell unterschiedli-
che Normalformen auf Basis funktionaler Abh¨
angigkeiten zwischen Relationen definiert. Diese
k¨
onnen ebenfalls zur Betrachtung der Schemaqualit¨
at in Betracht gezogen werden.
Definition 15 (Schemakonzeptqualit¨
at). Schemaqualit¨
at beschreibt den Grad der
Erf¨
ull-ung von gegebenen Charakteristika, die ein Schema zu einem Zeitpunkt besitzt.
2.4.2. Instanzqualit¨at
Instanz- bzw. Datenqualit¨
at ist ein aktives Forschungsgebiet, in dem eine Vielzahl wissenschaft-
licherArbeitenver
¨
offentlich wurden. Es existieren unterschiedliche Klassifikationssysteme und
Terminologien, und die Datenqualit¨
atseigenschaften werden von den Autoren unterschiedlich
definiert [WS96, BS06, KCH`03, WZL06, ORH05].
Mit der Normreihe ISO 8000 [Ben09] entsteht ein neuer Standard f¨
ur die Qualit¨
at von Stammda-
ten, der sowohl Datenqualit¨
atskriterien (Part 110: Master data: Exchange of characteristic data:
Syntax, semantic encoding, and conformance to data specification) als auch Prozesse f¨
ur das Da-
tenqualit¨
atsmanagement (ISO 8000:150–A frameworkfor Data Quality Management) definiert.
Eine detaillierte Betrachtung des Standards erfolgt in Abschnitt 4.2.5.
Qualit¨
atsdimensionen f¨
ur Instanzen beziehen sich auf Fehler einzelner oder mehrerer Attribut-
werte. Beispiel f¨
ur einen solchen Fehler ist z.B. ein Schreibfehler eines Namens oder einer Adresse,
der entweder bei der manuellen Eingabe durch einen Endanwender enstanden ist oder auf Fehler
45
2. Grundlagen
bei der automatischen Texterkennung zur¨
uckzuf¨
uhren ist. [LN06] beschreibt eine Liste weiterer
Fehler, wie z.B. fehlende Attributwerte, falsche Werte, falsche Referenzen oder eingebettete Wer-
te. In [BS06] werden unter anderem die Dimensionen Richtigkeit,Vol lst¨
andigkeit,Konsistenz und
Aktualit¨
at erl¨
autert.
Definition 16 (Instanzqualit¨
at). Instanzqualit¨
at beschreibt den Grad der Erf¨
ullung von
Charakteristika, die eine Menge an Instanzen zu einem Zeitpunkt besitzt.
2.4.3. Produktdatenqualit¨at
[SAS05] geht einen Schritt weiter und definiert Produktdatenqualit¨
at als Maß der Genauigkeit
(engl. accuracy) und Angemessenheit (engl. appropriateness) von Produktdaten, kombiniert mit
der Aktualit¨
at mit der diese Daten allen ben¨
otigten Personen zur Verf¨
ugung gestellt werden.
Qualit¨
at bezieht sich hier vor allem auf die Qualit¨
at von geometrischen Modellen.
Entscheidend f¨
ur die Integration heterogener Produktdaten ist deren Datenqualit¨
at. In der Rea-
lit¨
at ist die Qualit¨
at von Produktdaten und Daten im Allgemeinen sehr unterschiedlich und
von verschiedenen Faktoren abh¨
angig [HS98]. So nimmt die Datenqualit¨
at von Produktdaten
in der Regel mit zunehmender Reife zu, w¨
ahrend sie zu Beginn der Entwicklung viele Informa-
tionen fehlen. Weitere Datenqualit¨
atsprobleme des Concurrent Engineerings werden in [BLL10]
erl¨
autert. So k¨
onnen Attribute von Instanzen fehlen, falsche Werte besitzen oder falsch dokumen-
tiert sein. Die Gr¨
unde dieser Probleme sind vielf¨
altig [LN06]. Bei der automatischen Erfassung,
z.B. durch OCR-Software, oder falsche manuelle Eingaben k¨
onnen fehlerhafte Werte entstehen.
Werden Datenbest¨
ande nicht kontinuierlich aktualisiert, altern diese und spiegeln nicht mehr
die Realit¨
at wieder. Bei der Transformation unterschiedlicher Formate und Bereiche k¨
onnen
Informationen verloren gehen. Neben Datenqualit¨
atsproblemen, die in einzelnen Datenquellen
auftreten k¨
onnen, k¨
onnen bei der Integration weitere Probleme auftreten [LN06].
Definition 17 (Produktdatenqualit¨
at). Produktdatenqualit¨
at bezeichnet das Verh¨
altnis
von zuvor definierten Charakteristika (z.B. Vollst¨
andigkeit, Genauigkeit, Konsistenz) mit
definierten Zielerreichungswerten im Verh¨
altnis zur tats¨
achlichen Erf¨
ullung der Charakte-
ristika zu einem bestimmten Zeitpunkt. Charakteristika f¨
ur Produktdaten sind abh¨
angig
vom Produktdatenaspekt und die Zielerreichungswerte von der Reife eines Produktes.
2.4.4. Integrationsqualit¨at
Bisher wurden nur Dimensionen und Fehler einzelner Informationssysteme betrachtet. Werden
Schematkonzepte und Instanzen integriert, ergeben sich weitere Fehler und Qualit¨
atsdimensionen.
Wie diskutiert, treten bei der Integration heterogener Schemata strukturelle, schematische und
semantische Probleme auf. Werden Instanzen mit den gleichen Attributen integriert, k¨
onnen
Duplikate bei der Integration entstehen. Werden gemeinsame Attribute geteilt, k¨
onnen un-
terschiedliche Attributkonflikte auftreten. Attribute k¨
onnen widerspr¨
uchliche Werte besitzen,
unterschiedliche Einheiten oder Genauigkeiten aufweisen oder verschieden repr¨
asentiert sein.
W¨
ahrend die genannten Qualit¨
aten Charakteristiken betrachtet, die f¨
ur einzelne Informations-
system isoliert betrachtet werden, fokussiert die Integrationsqualit¨
at auf Charakteristiken (etwa
Vollst¨
andigkeit, Konsistenz), die f¨
ur die Bewertung der Produktdatenintegration von mehreren
Informationssystemen notwendig sind.
46
2.4. Informationsqualit¨
at
Definition 18 (Integrationsqualit¨
at). Integrationsqualit¨
at bezeichnet das Verh¨
altnis
von zuvor definierten Charakteristika (z.B. Vollst¨
andigkeit, Genauigkeit, Konsistenz) mit
definierten Zielerreichungswerten im Verh¨
altnis zur tats¨
achlichen Erf¨
ullung der Charakteris-
tika zu einem bestimmten Zeitpunkt. Charakteristika f¨
ur die Integrationsqualit¨
at betrachten
das Verh¨
altnis von mehreren zu integrierenden Informationssystemen.
47
3. Anforderungsanalyse
Dieses Kapitel leitet relevante Anforderungen zur Realisierung eines PDIS her. Zun¨
achst pr¨
asen-
tiert Abschnitt 3.1 eine Literaturstudie zu den Herausforderungen bei der Integration von
Produktdaten. Anschließend werden in Abschnitt 3.2 die IT-Landschaft f¨
ur die Entwicklung
von E/E-Komponenten bei einem Automobilhersteller analysiert und anhand zweier Fallstudi-
en entsprechende Herausforderungen und Anforderungen abgeleitet. In Abschnitt 4.2 werden
Standards im Umfeld der Produktentwicklung analysiert. Schließlich fasst Abschnitt 3.3 die
Anforderungen zusammen.
3.1. Literaturstudie
In Tabelle 3.1 sind die f¨
unf zu untersuchenden Forschungsfragen aus Abschnitt 1.3 mit Stichw¨
or-
tern aufgelistet, die f¨
ur die Ermittlung relevanter wissenschaftlicher Literatur verwendet wurden.
Diese Stichw¨
orter wurden anschließend dazu genutzt, potenzielle wissenschaftliche Literatur in
folgenden Suchmaschinen zu identifizieren:
•Google Scholar (http://scholar.google.com)
•SpringerLink (http://link.springer.com)
•IEEE xplore (http://ieeexplore.ieee.org/Xplore)
•ACM Digital Library (http://dl.acm.org/)
Die Suchergebnisse wurden anschließend gesichtet und die gewonnen Erkenntnisse zusammenge-
fasst. Danach wurden relevante Anforderungen abgeleitet. Im Folgenden werden die Erkenntnisse
der Literaturstudie zusammengefasst.
Insbesondere [Sta11] listet eine Reihe von Problemen auf, die im Zusammenhang von Produktda-
ten auftreten. Die Heterogenit¨
at von Bezeichnern, Produktstrukturen, und Repr¨
asentation sowie
unterschiedliche Abstraktionsstufen werden als Herausforderungen f¨
ur die Integration von Pro-
duktdaten genannt. Zus¨
atzlich erschweren die mangelnde Datenqualit¨
at (inkorrekte und inkon-
sistente Daten, ¨
Uberlappungen, Duplikate) sowie implizites Wissen die Integration zus¨
atzlich.
[VSW15] kommt zu folgenden Erkenntnissen: Um komplexe System zu realisieren, werden Ver-
antwortliche aus unterschiedlichen Dom¨
anen (Hardware, Software, Service) ben¨
otigt, die w¨
ah-
rend der Entwicklung dynamische und teils widerspr¨
uchliche Anforderungen produzieren. Ent-
wicklungsaufgaben werden mit Hilfe von Concurrent Engineering realisiert, zunehmends ver-
schiebt sich die Entwicklung in Richtung Digital Mock-Up (DMU). Insgesamt ist ein Trend zu
lokalen, lose gekoppelten Modellen in f¨
oderierten Umgebungen zu beobachten.
Nicht nur die Zunahme an Produktdaten insgesamt, sondern auch die wachsende Komplexit¨
at
infolge von Vernetzung komplexer Komponenten/Bauteile sowie ein fehlender Systemgedanke
f¨
ordern Heterogenit¨
at. Neben diesen technischen Probleme besitzt die Integration zus¨
atzlich eine
49
3. Anforderungsanalyse
Nr. Forschungsfrage Stichworte
1 Wie lassen sich komplexe Produktdaten aus heterogenen und au-
tonomen Informationssystemen in anspruchsvollen Entwicklungs-
umgebungen integrieren, die unterschiedliche Konzepte zur Re-
pr¨
asentation von Variabilit¨
at und Versionierung aufweisen?
”product data“
”integration“
”challenges“
2Wie l¨
asst sich die Qualit¨
at (z.B. Vollst¨
andigkeit und Konsistenz)
der Integration bestimmen? ”integration“
”quality“
3Wie beeinflussen strukturelle und inhaltliche ¨
Anderungen bereits
integrierte Produktdaten? ”integration“
”changes“
4Mit Hilfe welcher Technologie l¨
asst sich die Integration der hete-
rogenen Produktdaten umsetzen? ”integration“ ”ar-
chitecture“
5Wie l¨
asst sich die Wirtschaftlichkeit der Produktintegration be-
stimmen? ”integration“ ”in-
vestment“
Tabelle 3.1.: Forschungsfragen f¨
ur die Anforderungsanalyse
soziale Komponente, etwa die Bereitschaft implizites Wissen mit anderen zu teilen. Schließlich
erfolgt der Austausch von Produktdaten auf Basis einer Vielzahl komplexer Standards (z.B.
STEP1, AUTOSAR2,JT
3).
Daraus leiten die Autoren folgende Anforderungen ab: Die Qualit¨
at von Produktdaten und
deren Integration m¨
ussen kontinuierlich ¨
uberwacht werden. Um Datenmodellheterogenit¨
at zu
¨
uberwinden und Produktdaten unterschiedlicher Hersteller integrieren zu k¨
onnen, werden ein
standardisiertes Lieferantenintegrationsportal sowie Investitionen in entsprechende Prozesse be-
n¨
otigt. Schließlich sind ”nat¨
urliche Benutzerschnittstellen“ f¨
ur die Interaktion mit Produktdaten
notwendig.
Auch [TRS15] sieht die zunehmende Funktionalit¨
at und Komplexit¨
at als Herausforderungen
in der Produktentwicklung. W¨
ahrend f¨
ur das St¨
ucklisten- und Produktdatenmanagement teils
homogene Architekturen entlang des gesamten Entwicklungsprozesses etabliert sind, werden Da-
ten in einer heterogenen Systemlandschaft gespeichert. Vor allem im Team Data Management
(TDM) ist eine hohe Heterogenit¨
at mit bis zu 1000 unterschiedlichen Applikationen vorhanden.
Die große Anzahl an heterogenen Systemen entsteht, um neue Technologien und Entwicklun-
gen zu unterst¨
utzen. W¨
ahrend die Integration zu definierten Synchronisationspunkten erfolgt,
existiert f¨
ur Methoden, Systeme und Datenmodelle kein unternehmensweites Schema. Zusam-
mengefasst kommen die Autoren zu folgenden Anforderungen: Neben der Integration von Be-
nutzerober߬
achen muss vor allem eine konsistente Produktstruktur etabliert werden. Insgesamt
muss die Integration von Daten und Prozessen sowohl auf technischer als auch organisatorischer
Ebene erfolgen. Technisch sind hierf¨
ur offene und standardisierte Schnittstellen erforderlich.
[Kat15] sieht zus¨
atzlich eine Reduktion der Entwicklungsdauer zwischen 30 und 50 Prozent in
den letzten 30 Jahren. Auch haben sich in den letzten Jahren die Zusammenarbeitsmodelle deut-
lich ge¨
andert. Nicht nur, dass immer mehr Entwicklungsaufgaben durch Zulieferer ¨
ubernommen
werden, auch Kooperationen zwischen großen Herstellern r¨
ucken vermehrt in den Fokus. Dadurch
muss der Austausch zwischen unterschiedlichen Produktdatenmanagementsystemen (PDMS)er-
1Standard for the Exchange of Product data
2AUTomotive Open System ARchitecture
3Jupiter Tessellation
50
3.1. Literaturstudie
m¨
oglicht werden. Neben etablierten Systemen, etwa dem St¨
ucklistenmanagement, welches bis
zu 500 Schnittstellen zu anderen Systemen haben kann, besteht die IT-Landschaft im Auto-
mobilbereich aus einer Vielzahl gewachsener propriet¨
arer Applikationen, kleinen speziellen und
selbstentwickelten Applikationen sowie großen Standardapplikationen. In diesem Zusammen-
hang ist eine Konsolidierung oder ¨
Anderung der Systemlandschaft schwierig, da die Nutzung
dieser Systeme integraler Bestandteil des spezifischen Entwicklungswissens eines Unternehmens
sei. Als L¨
osung des Problems wird eine Basis-IT-Infrastruktur f¨
ur die Entwicklung von Sys-
temen vorgestellt, die neben Dokumenten-, Konfigurations-, Versions-, Release- sowie Regeln-
und Rechtemanagement vor allem aus einem zentralen Integrationsbus besteht. F¨
ur den Au-
tor ergeben sich folgende Herausforderungen im Zusammenhang mit Produktdaten: Aufgrund
der zunehmenden Bedeutung von Zulieferern ist die Integration von deren Informationssyste-
me von entscheidender Bedeutung. Da ¨
Anderungen der IT-Landschaft aufw¨
andig sind, muss
diese Schritt f¨
ur Schritt, also bedarfsgerecht, geschehen (hier wird auf eine Service-orientierte
Architektur gesetzt, bei der die IT-Landschaft modularisiert aber nicht umstrukturiert werden
soll). Dazu werden Standards wie STEP AP242 (siehe Abschnitt 4.2.3) und JT4eingesetzt. In
diesem Zusammenhang wird der Code of PLM Openness hervorgehoben. Zuletzt werden seman-
tische Netzwerke als M¨
oglichkeit diskutiert, um die Nachvollziehbarkeit zwischen verbundenen
Objekten zu erreichen.
Die skizzierten Erkenntnisse decken sich mit denen aus [CRS`13], dass CAD-Systeme nicht
mehr ausreichend f¨
ur die Dokumentation von Produktdaten seien. Die fehlende Repr¨
asentation
f¨
ur Funktionen und das Verhalten von Komponenten verhindert eine Integration aller Produkt-
daten. Vor allem Analysen integrierter Produktdaten, etwa Impact-Analysen5, lassen sich nicht
vollautomatisch durchf¨
uhren. Die Autoren leiten folgende Anforderungen ab: Interagierende In-
formationssysteme, die Wissen der Produktentwicklung speichern, m¨
ussen integriert werden.
Dabei soll ein Paradigmenwechsel erfolgen, weg vom reinen Austausch von Produktdaten hin
zu einem Austausch von Produktinformationen ¨
uber unterschiedliche Disziplinen und Dom¨
anen
hinweg entlang aller Phasen eines Produktes. Dazu ist die Entwicklung einer umfassenden Re-
pr¨
asentation von Produktentwicklungswissen erforderlich. Die Autoren empfehlen eine Integrati-
on der bereits vorhanden Systeme mit wissensbasierten Systemen, etwa auf Basis von Ontologien.
Schließlich sollen diese Systeme nachhaltig sein, da die Einf¨
uhrung neuer Informationssysteme
mit hohen Kosten und langen ¨
Ubergangszeiten verbunden ist.
[RTW15] erl¨
autern Herausforderungen im Zusammenhang mit der Integration von Variabilit¨
at
w¨
ahrend der Produktentwicklung. Variabilit¨
at tritt in jeder Phase der Produktentwicklung auf
und wird oftmals in jeder Phase unterschiedlich modelliert. Nach Ansicht der Autoren fokus-
sieren aktuelle Forschungsprojekte vor allem auf die Reduktion der externen, also durch den
Kunden wahrnehmbare, Komplexit¨
at, w¨
ahrend auf der anderen Seite die interne Variabilit¨
at
durch Standardisierung und Modularisierung reduziert werden soll. Daraus ergeben sich fol-
gende Anforderungen f¨
ur das Variabilit¨
atsmanagement bei der Produktentwicklung: Durch die
zunehmende Komplexit¨
at muss das Variantenmanagement durch formale Logiken abgebildet
werden. Da in den verschiedenen Phasen der Produktentwicklung unterschiedliche Modelle zum
Einsatz kommen, wird ein ”overall composed variability model“ ben¨
otigt, welches sehr groß und
komplex werden kann. F¨
ur eine komplette Produktlinie kann ein solches Modell bis zu 200.000
Regeln enthalten.
4Jupiter Tesselation - ISO-Standard zur Speicherung von 3D-Daten.
5Damit sind Analysen gemeint, die Auswirkungen von potenziellen ¨
Anderungen im Voraus bestimmen, um
letztere besser bewerten zu k¨
onnen.
51
3. Anforderungsanalyse
[PNSD07] beschreibt das Qualit¨
atsmanagement in der Produktentwicklung. Demnach haben
die zunehmende Produktkomplexit¨
at und die k¨
urzeren Entwicklungszeiten dazu gef¨
uhrt, dass
die Qualit¨
at der Produktentwicklung nachgelassen hat. Der Autor sieht die Beherrschung der
Komplexit¨
at von Hard- und Software als eine der Kernaufgaben der Automobilbranche an.
Dazu sei die ¨
Uberwachung des Produktentstehungsprozesses essentiell. Die Vollst¨
andigkeit und
Richtigkeit seien vor allem wichtig f¨
ur die Detaillierungsphase und m¨
ussen folglich effizient, d.h.
m¨
oglichst automatisch, erfolgen.
3.2. Explorative Untersuchung
Neben der Sichtung der wissenschaftlichen Literatur wurde die Systemlandschaft f¨
ur die Ent-
wicklung von E/E-Bauteilen eines großen deutschen Automobilherstellers untersucht [THR13b,
THR13a]. In diesem Kontext wurden Anwendungsf¨
alle betrachtet, welche die Integration von
Produktdaten aus autonomen, heterogenen Informationssystemen erfordern.
3.2.1. Anwendungsfall 1: Integration elektrischer und geometrischer Komponenten
Im ersten untersuchten Anwendungsfall wird die Integration von Produktdaten (mechanisch und
elektrisch) zweier Informationssysteme untersucht.
Elektrische Komponenten eines Fahrzeuges k¨
onnen sowohl Sensoren als auch Aktuatoren seien.
Ein Sensor (z.B. Temperatursensor) liefert die Eingabeinformationen f¨
ur Steuerger¨
ate (etwa das
Motorsteuerger¨
at), die wiederum Aktuatoren (z.B. Fensterhebermotor) ansteuern. Der Informa-
tionsaustausch zwischen Sensoren, Aktuatoren und Steuerger¨
aten kann sowohl analog als auch
digital erfolgen.
Im Informationssystem E-PDM werden elektrische Komponenten und deren Varianten verwaltet,
w¨
ahrend im Informationssystem PDM geometrische Modelle dieser Komponenten dokumentiert
werden.
Auf Grund unterschiedlicher Ausstattungsmerkmale (siehe Abschnitt 2.2.3) und Gesetzgebungen
existieren diese Komponenten in unterschiedlichen Varianten. Diese Variabilit¨
at kann sowohl auf
elektrischer Ebene (verschiedene Software, Bauteile) als auch auf physischer Ebene (Geometrie)
vorliegen. W¨
ahrend letztere zu verschiedenen Geometriemodellen im System PDM f¨
uhren, werden
erstere in E-PDM dokumentiert.
Der zu realisierende Anwendungsfall ist wie folgt: F¨
ur jede E/E-Komponente in E-PDM soll
¨
uberpr¨
uft werden, ob ein entsprechendes geometrisches Modell in PDM vorhanden ist. Dabei
sollen unterschiedliche Varianten ber¨
ucksichtigt werden.
In Abbildung 3.1 sind Ausschnitte der Datenmodelle sowie Beispielinstanzen beider Informa-
tionssysteme dargestellt. E-PDM verwaltet f¨
ur ein Fahrzeugmodell dessen Komponenten,die
wiederum in unterschiedlichen Komponentenvarianten und Komponentenvariantenversionen
existieren k¨
onnen. Auf der anderen Seite verwaltet PDM mehrere Bauteile sowie zugeh¨
orige
Bauteilversionen in unterschiedlichen Projekten. Betrachtet man die Beispielinstanzen, so
f¨
allt auf, dass in den beiden Informationssystemen die Varianten nach unterschiedlichen Kriteri-
en gespeichert werden. W¨
ahrend in E-PDM zu einer elektrischen Komponente die verschiedenen
Varianten explizit dokumentiert sind, so ist die Variabilit¨
at in PDM implizit in der Bezeichnung
der Bauteile dokumentiert. Weiter f¨
allt auf, dass beide Systeme eine unterschiedliche Anzahl an
elektrischen Komponenten bzw. Bauteilen besitzen. Dies liegt zum einen an der zuvor erw¨
ahnten
impliziten Speicherung der Variabilit¨
at in den Bauteilen, zum anderen an der Tatsache, dass
52
3.2. Explorative Untersuchung
,QIRUPDWLRQVV\VWHP3'0,QIRUPDWLRQVV\VWHP(3'0
$XHQVSLHJHO
7UVWHXHUJHUlW
/DXWVSUHFKHU
7UVFKORVV
%DVV6WDQGDUG
%DVV3UHPLXP
7UVWHXHUJHUlW0$;YRUQH
7UVWHXHUJHUlW0$;KLQWHQ
$XHQVSLHJHO(&EHKHL]W
$XHQVSLHJHOHLQIDFK
%DVV6WDQGDUG
%DVV3UHPLXP
/LPRXVLQH
$XVVHQVSLHJHO86$
$XVVHQVSLHJHO(&(
9
/LPRXVLQH
9
/DXWVSUHFKHU3UHPLXP
9
)DKU]HXJPRGHOO HOHNWULVFKH
.RPSRQHQWH
.RPSRQHQWHQ
YDULDQWH
.RQ]HSWLRQHOOH'DWHQPRGHOO
%HLVSLHOLQVWDQ]HQ
.RQ]HSWLRQHOOH'DWHQPRGHOO
%HLVSLHOLQVWDQ]HQ
3URMHNW %DXWHLO
%DXWHLOYHUVLRQ
.RPSRQHQWHQ
YDULDQWHQYHUVLRQ
9
9
9
9
9
9
9
9
9
7UUDKPHQ
9
7UUDKPHQ
9
3URMHNW %DXWHLO %DXWHLOYHUVLRQ
)DKU]HXJ
PRGHOO
HOHNWULVFKH
.RPSRQHQWH
.RPSRQHQWHQ
YDULDQWHQYHUVLRQ
.RPSRQHQWHQ
YDULDQWH
Abbildung 3.1.: Datenmodellausschnitte und Beispielinstanzen
beide Informationssysteme unterschiedliche Semantiken f¨
ur die Begriffe elektrische Komponente
und Bauteil besitzen. Ein Bauteil kann sowohl eine elektrische als auch eine rein mechanische
Komponente sein.
Nicht nur die Dokumentation von Variabilit¨
at in beiden Systemen unterscheidet sich, auch zeit-
liche ¨
Anderungen der Entwicklungsst¨
ande elektrischer Komponenten und Bauteile besitzen ver-
schiedene Semantiken. W¨
ahrend in PDM ¨
Anderungen von Geometriemodellen linear dokumentiert
werden, k¨
onnen in E-PDM komplexe Vor- und Nachfolgebeziehungen definiert werden.
Bei der Realisierung des Anwendungsfalles ergeben sich somit folgende Herausforderungen: Beide
Informationssysteme verwenden unterschiedliche Bezeichner f¨
ur die Benennungen von Bauteilen
bzw. Komponenten. Zus¨
atzlichsinddieDateninunterschiedlichenProduktstrukturengespei-
chert. Dies betrifft vor allem die unterschiedlichen Konzepte f¨
ur Variabilit¨
at und Versionierung.
W¨
ahrend in PDM Bauteile im Sinne einer St¨
uckliste hierarchisch strukturiert sind, werden die
unterschiedlichen elektrischen Varianten von Komponenten in E-PDM zusammengefasst. Der zu
integrierende gemeinsame Nenner zwischen beiden Informationssystemen ist die elektrische Kom-
ponente, die eine Teilmenge der Bauteile ist.
Folglich kann die Integration solch heterogener Produktdaten nicht vollst¨
andig automatisiert
werden. Vielmehr muss die Integration und im Speziellen die Zuordnung von semantisch zusam-
mengeh¨
origen Daten mittels manueller Interaktionen durch Endbenutzer unterst¨
utzt werden.
Aus dem illustrierten Anwendungsfall ergeben sich folgende Anforderungen an ein PDIS:DieIn-
tegration von Produktdaten muss unterschiedliche Konzepte f¨
ur Variabilit¨
at und Versionierung
von Produktdaten ber¨
ucksichtigen. Da nicht alle Korrespondenzen zwischen Artefakten auto-
matisch ermittelt werden k¨
onnen, muss ein PDIS M¨
oglichkeiten bereitstellen, Anwender bei der
53
3. Anforderungsanalyse
Integration zu unterst¨
utzen. Schließlich muss es m¨
oglich sein, die Integration von Produktdaten
nur f¨
ur Ausschnitte von Datenmodellen und eine Auswahl der Instanzen vorzunehmen, da sich
semantische Konzepte zwischen Informationssystemen unterscheiden.
3.2.2. Anwendungsfall 2: Integration der vollst¨andigen Produktentwicklung
W¨
ahrend im Anwendungsfall 1 lediglich Schemata und Daten zweier Informationssysteme inte-
griert wurden, werden nachfolgend die Herausforderungen und Anforderungen erl¨
autert, die sich
ergeben, wenn die unterschiedlichen Aspekte von Bauteilen w¨
ahrend der Produktentwicklung
vollst¨
andig integriert werden sollen. Zu den Aspekten z¨
ahlen sowohl die Anforderungsspezifi-
kationen, Konstruktionszeichnungen, geometrische Modelle, Softwaremodelle und Quelldateien,
Hardwareinformationen, Testspezifikationen und Testprotokolle.
Abbildung 3.2 zeigt exemplarisch einen Ausschnitt der Systemlandschaft der Produktentwick-
lung – eine detaillierte Beschreibung der Basis-IT-Infrastruktur findet sich in [Kat15]. Im CAD-
Bereich werden ¨
uberwiegend angepasste COTS6-Systeme eingesetzt, w¨
ahrend viele weitere In-
formationssysteme f¨
ur Kernaufgaben der Produktentwicklung (z.B. St¨
ucklisten- und ¨
Anderungs-
management) Eigenentwicklungen sind. Neben diesen werden in den ¨
ubrigen Bereichen h¨
aufig
Office-Anwendungen und eigene Applikationen eingesetzt, die oft informelle oder undokumen-
tierte Informationsmodelle besitzen, um Produktanforderungen, Funktionen und Verhalten zu
beschreiben.
&$'
3'0
6FKDOWSOlQH
(3'0
6LJQDOH
6RIWZDUH
$QIRUGHUXQJHQ
6WFNOLVWH
7HVW
$UFKLWHNWXU
/
HJHQGH
,QIRUPDWLRQVDXVWDXVFK,QIRUPDWLRQVV\VWHP
Abbildung 3.2.: System¨
ubersicht der Produktentwicklung
In Tabelle 3.2 sind die unterschiedlichen Aspekte und Artefakte von Bauteilen aufgelistet, die
6Commercial off-the-shelf
54
3.3. Anforderungen
Name Aspekt Artefakte
Requirements Engineering Anforderungen Systemlastenhefte, Komponentenlastenhefte
Architektur Entwurf Technologiedokumentation
PDM 3D-Geometrie Volumenmodelle, Simulationen, FEA
PDM 2D-Zeichnungen Konstruktionszeichnungen
E-PDM Hardware Stecker, Pins, Interne Beschaltungen
St¨
uckliste Produktstruktur Konfigurationen
Software Funktionen Funktionsmodelle
Software Verbindungen Kommunikationsmatrizen, Signale
Software Source-Code Quelldateien, Testdateien,
Testing Test Testspezifikationen und -protokolle
Tabelle 3.2.: Unterschiedliche Aspekte und Artefakte von Bauteilen
in den einzelnen Informationssysteme w¨
ahrend der Produktentwicklung ¨
ublicherweise dokumen-
tiert werden. W¨
ahrend einige Informationssysteme genau einen Aspekt von Bauteilen abdecken
(z.B. Anforderungen), werden in anderen Systemen (z.B. PDM-System) eine Vielzahl an Aspek-
ten dokumentiert.
Wie im Anwendungsfall 1 verwenden die Informationssysteme eigene Mechanismen zur Bezeich-
nung, Variabilit¨
at und Versionierung von Aspekten. W¨
ahrend zuvor nur zwei Bauteilmengen mit-
einander verglichen werden mussten, m¨
ussen nun eine Vielzahl an Mengen abgeglichen werden.
Daraus ergeben sich folgende Anforderungen: Auf Grund der Vielzahl an Informationssystemen
und der ben¨
otigten manuellen Interaktionen bei der Integration ist der kontinuierliche Abgleich
der Bauteilmengen aller Informationssysteme zu allen Zeitpunkten nicht wirtschaftlich. Die In-
tegration muss daher nach Bedarf erfolgen. W¨
ahrend ¨
Anderungen an Produktdaten sowie an
den beiden Informationssystemen im ersten Anwendungsfall noch ¨
uberschaubar waren, existiert
im zweiten Anwendungsfall ein komplexes Abh¨
angigkeitsgeflecht zwischen den einzelnen Infor-
mationssystemen. ¨
Anderungen an einem Informationssystem k¨
onnen sich auf eine Vielzahl wei-
terer Informationssysteme auswirken. Ein PDIS muss somit die Auswirkungen von ¨
Anderungen
an Produktdatenn sowie den zugrundeliegenden Informationssystemen unterst¨
utzen sowie die
m¨
oglichen Auswirkungen vor der eigentlichen Realisierung bestimmen k¨
onnen.
Grunds¨
atzlich existieren zwei Ans¨
atze, um Schemakonzepte und Instanzen heterogener Informa-
tionssysteme zu integrieren. Entweder wird ein Schema mit Schemakonzepten definiert, auf wel-
ches Schemakonzepte existierender Informationssysteme abgebildet werden (h¨
aufig Top-Down-
Integration genannt), oder es wird versucht gemeinsame existierende Schemakonzepte zu ver-
einheitlichen (Bottom-Up-Integration). Auf Grund der Vielzahl an zu integrierenden Informati-
onssystemen mit jeweils einer Menge an Schemakonzepten und Instanzen, muss ein PDIS unter-
schiedliche Integrationsmethodiken unterst¨
utzen.
3.3. Anforderungen
Dieser Abschnitt fasst die resultierenden Anforderungen an ein Konzept zur Integration von
Produktdaten in komplexen Entwicklungsprozessen zusammen.
W¨
ahrend der Produktentwicklung arbeiten unterschiedliche Personen an einem Produkt und
55
3. Anforderungsanalyse
f¨
uhren dabei verschiedene, teils nebenl¨
aufige, Aktivit¨
aten aus. Um letztere m¨
oglichst effektiv
und effizient durchf¨
uhren zu k¨
onnen, nutzen die Entwickler autonome, heterogene Informations-
modelle, mit Datenstrukturen, die auf ihre Bed¨
urfnisse zugeschnitten sind [Sta11]. Die Abl¨
osung
dieser komplexen IT-Systemlandschaft ist weder praktisch m¨
oglich noch ist sie sinnvoll. Folglich
m¨
ussen Produktdaten integriert werden. Auf Grund der heterogenen Datenstrukturen m¨
ussen
bei der Integration die verschiedenen Mechanismen f¨
ur die Modellierung von Variabilit¨
at und
Versionierung von Produktdaten besonders ber¨
ucksichtigt werden.
Durch die große Anzahl an Informationssystemen mit jeweils einer Vielzahl an Datenmodellkon-
zepten ist eine vollst¨
andige Integration all dieser Konzepte weder sinnvoll noch praktikabel. So
muss die Integration bedarfsgerecht erfolgen. Zusammenfassend ergibt dies die erste Anforderung
f¨
ur die Realisierung eines Produktdatenintegrationssystems.
Anforderung A1 (Bedarfsgerechte, Anwendungsfall-getriebene Integration). Es
muss m¨
oglich sein, beliebige Teilmengen von Produktdaten bedarfsgerecht sowie unter Ber¨
uck-
sichtigung unterschiedlicher Mechanismen f¨
ur Variabilit¨
at und Versionierung zu integrieren.
Die Integration muss Produktdaten sowohl aus unterschiedlichen Repr¨
asentationsformen
(technische Heterogenit¨
at) als auch unterschiedliche Konzeptionalisierungen (semantische
Heterogenit¨
at) unterst¨
utzen. Abh¨
angigkeiten zwischen Schemakonzepten der heterogenen
Informationssystemen m¨
ussen explizit dokumentiert werden. Neben Schemakonzepten m¨
ussen
außerdem die Instanzen von Schemakonzepten integriert werden. Die Identit¨
at von Produkt-
datenn soll m¨
oglichst automatisch ermittelt werden. Die Integration dient der Unterst¨
utzung
zuvor definierter Anwendungsf¨
alle.
Die Datenqualit¨
at der Produktdaten variiert stark und korreliert zu den einzelnen Entwick-
lungsphasen. In fr¨
uhen Entwicklungsphasen sind Informationen zu einzelnen Komponenten nur
teilweise verf¨
ugbar oder ¨
andern sich regelm¨
aßig. Dar¨
uber hinaus werden in einigen Informati-
onssystemen die Dokumentationsmethodiken definiert, ihre Einhaltung jedoch nicht konsequent
¨
uberpr¨
uft. Dies trifft zum Beispiel f¨
ur die Bezeichnung von Artefakten (z.B. Komponenten),
zu. Komplexe Produkte k¨
onnen aus mehreren tausend Komponenten bestehen, folglich kann
die Integration nicht vollst¨
andig automatisiert werden [Hei95]. Vielmehr muss ein Integrations-
prozess durch Benutzer ¨
uberwacht und unterst¨
utzt werden. Zu dessen Aufgaben z¨
ahlt es unter
anderem, Artefakte, die durch automatische Algorithmen nicht zugeordnet werden konnten, zu
¨
uberpr¨
ufen und gegebenenfalls Korrespondenzen manuell zu erstellen. Insgesamt ergibt dies die
n¨
achste Anforderung an ein PDIS.
Anforderung A2 (Unterst¨
utzung manueller Integrationsaufgaben). Ein PDIS muss
Benutzer bei unterschiedlichen Aufgaben im Integrationsprozess unterst¨
utzen. Dazu z¨
ahlt
unter anderem die Identifikation von Artefakten, f¨
ur die automatische Algorithmen keine
Korrespondenzen identifizieren konnte. Vielmehr muss ein PDIS Mechanismen bereitstellen,
die es erm¨
oglichen komplexe Produktdaten und dessen Beziehungen darzustellen.
Hauptziel der Integration von Produktdaten ist die Realisierung dom¨
anenspezifischer Anwen-
dungsf¨
alle, wie z.B. Vollst¨
andigkeits- und Korrektheitsanalysen. Diese k¨
onnen in unterschied-
lichen Phasen der Produktentwicklung (z.B. Anforderungsspezifikation, Modellierung, Imple-
mentierung/Realisierung, Test, Integration) durchgef¨
uhrt werden. Ergebnisse einer Integration
m¨
ussen somit f¨
ur solche Anwendungsf¨
alle zug¨
anglich gemacht werden. Die dritte Anforderung
an ein PDIS ist demnach:
56
3.3. Anforderungen
Anforderung A3 (Nutzung integrierter Produktdaten). Zur Realisierung dom¨
anen-
spezifischer Anwendungsf¨
alle m¨
ussen Fachanwender in der Lage sein, beliebige Abfragen
¨
uber integrierte Produktdaten stellen zu k¨
onnen. Ein PDIS muss eine M¨
oglichkeit bereitstel-
len, diese nutzen zu k¨
onnen.
Schemata von Informationssystemen k¨
onnen sehr viele Schemakonzepte umfassen, deren manu-
elle Integration mit sehr viel Aufwand verbunden ist. Auch die Integration von Instanzen dieser
Schemata kann nicht voll-automatisiert werden, auch hier ist eine Interaktion mit Endanwendern
erforderlich. Daher ben¨
otigt der Integrationsprozess einen gewissen Zeitraum bis alle erforder-
lichen Schemakonzepte und Instanzen integriert sind. Zur Realisierung eines Anwendungsfalles,
bei dem Produktdaten aus unterschiedlichen autonomen und heterogenen Informationssystemen
ben¨
otigt werden, wird in der Regel ein Zeitpunkt definiert, ab dem die integrierten Daten ver-
wendet werden sollen und keine weitere Integration mehr statt finden darf. Zu diesem Zeitpunkt
sollen alle vorhandenen Produktdaten integriert sein, d.h. zusammengeh¨
orige Produktdaten sind
mittels Korrespondenzen einander zugeordnet. Deshalb muss der Integrationsprozess ¨
uberwacht
werden, damit die Einhaltung von Nutzungszeitpunkten garantiert werden kann.
Anforderung A4 ( ¨
Uberwachung und Kontrolle des Integrationsprozesses). Ein
PDIS muss f¨
ur die Integration und dessen Fortschrittskontrolle entsprechende Prozesse mit
Aufgaben und Rollen definieren. Dabei m¨
ussen Prozesse und Rollen bereits existierende
Unternehmensprozesse und Aufgaben ber¨
ucksichtigen.
Informationssysteme entwickeln sich kontinuierlich weiter [Len03, RRD03]. ¨
Anderungen an Infor-
mationssystemen in der Produktentwicklung sind die Regel und sind Anwender- und Kundenge-
trieben. In einigen Bereichen existiert eine abgestimmte Release-Planung f¨
ur kritische Systeme,
also solche, die f¨
ur die direkte Produktion erforderlich sind. Dar¨
uber hinaus existieren jedoch ei-
ne Vielzahl an bereichsspezifischen Informationssystemen, die autonom entwickelt werden. Hier-
bei handelt es sich um spezielle Applikationen, die durch Fachanwender als Unterst¨
utzung der
t¨
aglich anfallenden Arbeit entwickelt worden sind. Dies k¨
onnen sowohl Tabellenkalkulationen
mit Berechnungen als auch kleine Datenbanken oder ¨
ahnliches sein. Diese Systeme entstehen,
da Funktionalit¨
aten in existierenden Informationssystemen fehlen oder der Aufwand der Anpas-
sung dem Nutzen nicht gegen¨
uber steht.
¨
Anderungen an einem Schema eines Informationssystems k¨
onnen Auswirkungen auf Schemata
anderer integrierter Informationssysteme haben. Wenn Produktdaten bereits integriert worden
sind, d¨
urfen Schema¨
anderungen nicht dazu f¨
uhren, dass diese integrierten Ergebnisse verloren
gehen bzw. unbrauchbar werden [CKR14]. ¨
Anderungen von Instanzen sind kontinuierlich, ein
L¨
oschen findet nur in Ausnahmen statt. Vielmehr dient die Speicherung aller Entwicklungser-
gebnisse der l¨
uckenlosen Dokumentation der Entwicklung. F¨
ur jede ¨
Anderung von Instanzen
und Schemata m¨
ussen entsprechende Operationen und Prozesse entwickelt werden, die eine
konsistente Integration sicherstellen bzw. wiederherstellen. ¨
Ublicherweise existieren in Unter-
nehmen bereits eine Vielzahl an Prozessen, so etwa auch f¨
ur die Abwicklung von ¨
Anderungen.
Deshalb m¨
ussen bei der Integration bereits existierende ¨
Anderungsprozesse im Unternehmen
ber¨
ucksichtigt werden.
57
3. Anforderungsanalyse
Anforderung A5 (Unterst¨
utzung von ¨
Anderungen). Ein PDIS muss auf ¨
Anderungen
von Schemata und Instanzen reagieren und ¨
Anderungen dieser unterst¨
utzen, ohne dass be-
reits bestehendes Integrationswissen verloren geht. Im Speziellen bedeutet dies, dass Aus-
wirkungen von ¨
Anderungen (sowohl auf Schema- als auch Instanzebene) vor der eigentlichen
Realisierung bestimmt werden k¨
onnen m¨
ussen. Bei der Realisierung von ¨
Anderungen sollen
diese m¨
oglichst vollautomatisch durchgef¨
uhrt werden.
Wie erw¨
ahnt, verwenden die zu integrierenden Informationssysteme unterschiedliche Konzep-
te zur Modellierung der Variabilit¨
at und Versionen von Produktdaten. F¨
ur die Realisierung
von Anwendungsf¨
allen k¨
onnen unterschiedliche Granularit¨
aten von Produktdatenvarianten und
-versionen ben¨
otigt werden. Die Realisierung der Produktintegration kann auf unterschiedliche
Arten erfolgen. In der Literatur wird h¨
aufig zwischen top-down- und bottom-up-Ans¨
atzen unter-
schieden. Bei ersteren werden die zu integrierenden Konzepte in einem zentralen, integrierten
Schema vorgegeben und existierende Konzepte von Informationssystemen auf diese abgebildet.
Im anderen Fall werden die existierenden Schemata von Informationssystemen auf gemeinsame
Konzepte analysiert, die integriert werden k¨
onnen. Hieraus folgt die letzte Anforderung an ein
PDIS:
Anforderung A6 (Integrationsmethodiken). Um unterschiedliche Vorgehensweisen
bei der Realisierung von Anwendungsf¨
allen zu erm¨
oglichen, muss ein PDIS eine klar defi-
nierte Methodik besitzen. Diese muss sowohl eine top-down- als auch bottom-up-Integration
unterst¨
utzen. Weiter muss diese Methodik die M¨
oglichkeit bieten, verschiedene Varianten-
und Versionsmechanismen unterst¨
utzen.
In Tabelle 3.3 sind alle Anforderungen auf einen Blick dargestellt.
Nr Anforderung Literaturstudie AF 1 AF 2
A1 Integration [Sta11] x x
A1.1 bedarfsgerecht x
A1.2 Varianten / Versionen x x
A2 Integrationsunterst¨
utzung [TRS15] x x
A3 Nutzung x x
A4 Monitoring [VSW15, PNSD07] x x
A5 Change Management x
A6 Methodiken x
Tabelle 3.3.: Anforderungen auf einen Blick
58
4. Stand der Technik
Die in Kapitel 3 ermittelten Anforderungen werden nun mit verwandten Ans¨
atzen abgeglichen.
Zun¨
achst werden Arbeiten untersucht, die sich der Integration heterogener Informationen wid-
men. Anschließend werden Standards untersucht, die verschiedene Aspekte der Integration adres-
sieren. Zuletzt werden die behandelten Ans¨
atze mit den erhobenen Anforderungen abgeglichen.
4.1. Heterogenit¨at, Autonomie, Integration
In diesem Abschnitt werden unterschiedliche Architekturen f¨
ur die Integration heterogener, auto-
nomer Informationssysteme beschrieben. Zun¨
achst werden f¨
oderierte Datenbanksysteme [SL90],
Data-Warehouses [CD97], Peer-Daten-Management-Systeme [HRZ`08] und Ans¨
atze zur Tool
Integration [KS06] diskutiert. Anschließend werden verwandte Arbeiten zu den verschiedenen
Schritten des Integrationsprozesses (vgl. Abschnitt 2.3.3) erl¨
autert.
4.1.1. F¨oderierte Datenbanksysteme
Bei f¨
oderierten Datenbanksystemen [SL90] handelt es sich um virtuell integrierende Systeme.
Dass heißt, es findet keine physische Integration der Daten aus heterogenen, autonomen Infor-
mationssystemen statt. Vor allem die Autonomie der bestehenden Informationssysteme steht im
Vordergrund f¨
oderierter Systeme. Es gibt verschiedene Referenzarchitekturen, die kurz erl¨
autert
werden. Detaillierte Informationen zu den einzelnen Ans¨
atzen finden sich in [Con97].
Referenzarchitekturen
Import-/Exportschema ist die ¨
alteste Architektur f¨
oderierter Datenbanksysteme, bei der
die Verhandlung zwischen Datenbanksystemen im Vordergrund steht. Demnach besitzt jedes
DBMS ein privates Schema, welches alle Daten beschreibt, die dieses DBMS verwaltet. Im sog.
Exportschema wird der Teil beschrieben, der anderen DBMS zur Verf¨
ugung gestellt wird. Auf
der anderen Seite besitzt jedes DBMS ein Importschema, das die genutzten Schemakonzepte
anderer Exportschemata umfasst.
Diese Architektur hat zum Ziel, eine m¨
oglichst hohe Autonomie der lokalen Systeme zu be-
wahren. F¨
ur die Integration sind sowohl Benutzer als auch lokale Administratoren der Systeme
verantwortlich. Der Zugriff auf die F¨
oderation erfolgt ¨
uber die lokalen Systeme.
Die Multidatenbank-Architektur kommt ohne ein globales Schema aus. Dabei muss ein
Benutzer mittels einer geeigneten Anfrage- und Datenmanipulationssprache die M¨
oglichkeit ha-
ben, auf die heterogenen Datenbanken zugreifen zu k¨
onnen. Die Architektur besteht aus einem
physischen Schema, das die interne Struktur der Daten beschreibt, sowie einem internen lo-
gisches Schema, welches das konzeptionelle Schema darstellt. Das konzeptionelle Schema ist
ein Ausschnitt des internen logischen Schemas bzw. stellt dessen Inhalt in einer abweichenden
Struktur dar. Mit einem externen Schema kann sich ein Benutzer in der gew¨
unschten Spra-
che ein Schema aus dem vorhandenen konzeptionellen Schemata zusammenstellen und darauf
59
4. Stand der Technik
'DWHQEDQN
SULYDWHV
6FKHPD
([SRUW
VFKHPD
,PSRUW
VFKHPD
SULYDWHV
6FKHPD
([SRUW
VFKHPD
,PSRUW
VFKHPD
'DWHQEDQN
SULYDWHV
6FKHPD
([SRUW
VFKHPD
,PSRUW
VFKHPD
'DWHQEDQN
Abbildung 4.1.: Import-/Export-Architektur
arbeiten. Abh¨
angigkeiten zwischen konzeptionellen Schemata, etwa datenbank¨
ubergreifende In-
tegrit¨
atsbedingungen oder Redundanzen, k¨
onnen im Abh¨
angigkeitsschema dokumentiert werden.
'DWHQEDQN
3K\VLVFKHV
6FKHPD
,QWHUQHVORJLVFKHV
6FKHPD
.RQ]HSWLRQHOOH
6FKHPD
([WHUQH6FKHPD
'DWHQEDQN
3K\VLVFKHV
6FKHPD
,QWHUQHVORJLVFKHV
6FKHPD
.RQ]HSWLRQHOOH
6FKHPD
([WHUQH6FKHPD
'DWHQEDQN
3K\VLVFKHV
6FKHPD
,QWHUQHVORJLVFKHV
6FKHPD
.RQ]HSWLRQHOOH
6FKHPD
([WHUQH6FKHPD
$EKlQJLJNHLWV
VFKHPD
$EKlQJLJNHLWV
VFKHPD
Abbildung 4.2.: Multidatenbank-Architektur
Bei der Multidatenbank-Architektur wird eine Multidatenbanksprache ben¨
otigt, welche die Funk-
tionen f¨
ur die Integration bereitstellt. Ein Vorteil dieser Architektur besteht darin, dass durch die
Abh¨
angigkeitsschemata datenbank¨
ubergreifende Integrit¨
atsbedingungen definiert werden k¨
onnen.
Anders als bei der Import-/Export-Architektur ist der Benutzer alleine f¨
ur die Integration ver-
antwortlich. Der Zugriff auf die F¨
oderation erfolgt ¨
uber eine globale Schnittstelle.
Die 5-Ebenen-Schema-Architektur besitzt, im Gegensatz zu den beiden vorangehend be-
handelten Architekturen, ein ¨
ubergeordnetes f¨
oderiertes Schema [SL90]. In Abbildung 4.3 sind
die f¨
unf Schemaebenen der Architektur illustriert. Das lokale Schema ist das konzeptionelle
Schema einer Datenbank, das alle Daten eines Systems umfasst. Das lokale Schema kann in
unterschiedlichen Datenmodellen vorliegen. Das Komponentenschema wiederum beseitigt die
Datenmodellheterogenit¨
at der lokalen Schemata. Einen Ausschnitt des Komponentenschemas,
das der F¨
oderation zur Verf¨
ugung gestellt werden soll, wird im Exportschema definiert. Das
f¨
oderierte Schema fast alle Exportschemata zusammen und basiert in der Regel auf einem glo-
balen (d.h. kanonischen) Datenmodell. Schließlich k¨
onnen mit Exportschemata unterschiedliche
60
4.1. Heterogenit¨
at, Autonomie, Integration
Ausschnitte des f¨
oderierten Schemas definiert werden. Anders als in den beiden zuvor diskutier-
ten Architekturen erfolgt der Zugriff auf die F¨
oderation ¨
uber ein globales System bzw. Anfragen
gegen dessen Schema. Die Integration wird durch einen globalen Administrator durchgef¨
uhrt,
wohingegen die Datenbankadministratoren der lokalen Systeme f¨
ur die Erstellung der Export-
schemata zust¨
andig sind.
I|GHULHUWHV
6FKHPD
.RPSRQHQWHQ
VFKHPD
ORNDOHV6FKHPD
([SRUWVFKHPD ([SRUWVFKHPD
H[WHUQHV6FKHPD H[WHUQHV6FKHPD
'DWHQEDQN
.RPSRQHQWHQ
VFKHPD
ORNDOHV6FKHPD
'DWHQEDQN
([SRUWVFKHPD
Abbildung 4.3.: 5-Ebenen-Architektur f¨
oderierter Datenbanksysteme (nach [SL90])
Integrationsmethoden
Bisher wurden unterschiedliche Architekturen f¨
ur f¨
oderierte Integrationssysteme vorgestellt. Im
weiteren Verlauf betrachten wir die 5-Ebenen-Schema-Architektur und diskutieren wie die In-
tegration von Exportschemata in ein f¨
oderiertes Schema realisiert werden kann. Dazu werden
unterschiedliche Methoden diskutiert.
•Zusicherungsbasierte Integration: Mit Hilfe von Zusicherungen werden diejenigen Be-
standteile zwischen Schemata beschrieben, die einander entsprechen oder in einer bestimm-
ten Beziehung zu einander stehen. Dadurch sollen strukturelle Konflikte im Integrations-
prozess automatisch aufgel¨
ost werden. Die Zusicherungen werden unabh¨
angig von einem
Datenmodell in einem generischen Datenmodell beschrieben. Der Ansatz unterscheidet un-
terschiedliche Schemakonzept- und Attributzusicherungsarten. Dazu z¨
ahlen ¨
Aquivalenz,
Inklusion, ¨
Uberlappung und Disjunktheit von Schemakonzepten und Attributen. Korre-
spondenzbeziehungen lassen sich auch f¨
ur Pfade innerhalb der Schemata definieren, analog
existieren hier die Pfad¨
aquivalenz, Pfadinklusion und Pfad¨
uberlappung sowie der Pfadaus-
schluss. Auf Basis der Zusicherungen zwischen zwei Schemata erfolgt der Integrationspro-
zess ¨
uber bin¨
are Integrationsregeln. Treten Konflikte im Integrationsprozess auf, wird im
integrierten Schema das Element der beiden Schemata verwendet, welches weniger Ein-
schr¨
ankungen besitzt.
61
4. Stand der Technik
Die Integrationsregeln werden nur f¨
ur ¨
Aquivalenzzusicherungen beschrieben. Inklusion,
¨
Uberlappung und Ausschluss werden nicht n¨
aher untersucht. Auch die Integration von
komplexen Attributen wird nicht betrachtet.
•Upward Inheritance: Hierbei handelt es sich um eine Integrationsmethode f¨
ur objekt-
orientierte Datenmodelle. Vor allem die Betrachtung von Generalisierungs- und Speziali-
sierungshierarchien spielt bei diesen Datenmodellen eine wesentliche Rolle.
Im Speziellen m¨
ussen Vererbungshierarchien aus lokalen Schemata auch im integrierten
Schema repr¨
asentiert sein. Folglich muss zu jedem Schemakonzept aus dem lokalen Sche-
ma ein ¨
aquivalentes Schemakonzept im integrierten Schema vorhanden sein. Zwei Sche-
makonzepte aus unterschiedlichen lokalen Schemata k¨
onnen nur dann in dasselbe Schema-
konzept im globalem Schema integriert werden, wenn beide die selbe Semantik besitzen.
¨
Uberlappen sich die Menge der Instanzen beider Schemakonzepte, wird f¨
ur jedes Schema-
konzept ein explizites Schemakonzept im globalem Schema angelegt. Handelt es sich um ei-
ne Teilmengenbeziehung, besteht eine Hierarchie im globalen Schema zwischen den beiden
Schemakonzepten. Anderenfalls muss ein gemeinsames Schemakonzept im globalen Sche-
ma erzeugt werden, von dem beide Schemakonzepte abgeleitet werden (Aufw¨
artsvererbung,
engl. upward inheritance).
Durch die Forderung, dass bei Hierarchien f¨
ur jedes Schemakonzept eines lokalen Schemas
ein ¨
aquivalentes Konzept im globalen Schema repr¨
asentiert sein muss, sind Umstrukturie-
rungen im globalen Schema ausgeschlossen.
•Generisches Integrationsmodell (GIM): Die zu integrierenden Schemata werden ge-
meinsam mit Hilfe der sog. GIM-Notation dargestellt. Diese bildet die Grundlage f¨
ur die
anschließende Integration. Besonderheiten dieser Methode sind die Unabh¨
angigkeit von
konkreten Datenmodellen sowie die flexible Behandlung von Generalisierungs- und Spezia-
lisierungshierarchien. Zus¨
atzlich erlaubt der GIM-Ansatz, im Gegensatz zu anderen objek-
torientierten Integrationsmethoden, die Umstrukturierung lokaler Beziehungen im globa-
len Schema. Allerdings werden Aggregationsbeziehungen sowie 1-n- und n-m-Beziehungen
nicht unterst¨
utzt.
[Con97] merkt an, dass alle bisherigen Ans¨
atze ein relativ einfaches Datenmodell als Grund-
lage f¨
ur die Integration verwenden und sieht darin eine konzeptionelle Beschr¨
ankung, merkt
gleichzeitig aber an, dass in den meisten bestehenden Datenbanksystemen nur ein Bruchteil der
Modellierungsm¨
oglichkeiten angewendet wird.
Integration durch Sichten
Eine weitere Methode zur Integration von Exportschemata in ein f¨
oderiertes Schema ist die
Definition von Sichten zwischen Exportschemata.
In Abschnitt 2.3.4 wurden bereits die zwei grundlegenden Architekturen zur Integration von
Informationssystemen erl¨
autert.
Die bisherigen Methoden haben lediglich die Integration lokaler Schemata beschrieben, jedoch
nicht adressiert wie die eigentliche Integration von Instanzen vonstatten geht. Des weiteren
fokussierten alle bisher beschriebenen Ans¨
atze auf der Integration bereits bestehender Schemata,
um ein globales Schema zu erzeugen. Dieses Vorgehen wird in der Literatur als Bottom-Up-
Ansatz bezeichnet. Eine weitere M¨
oglichkeit besteht darin, ein globales Schema zu spezifizieren
62
4.1. Heterogenit¨
at, Autonomie, Integration
und anschließend Abbildungen auf die lokalen Schemata zu definieren. Diese Vorgehen wird
als Top-Down-Ansatz bezeichnet. Abbildung 4.4 veranschaulicht beide Ans¨
atze. Beim Bottom-
Up-Ansatz werden die lokalen Schemata zun¨
achst in Komponentenschemata ¨
ubersetzt, die mit
einer gemeinsamen Modellierungssprache spezifiziert sind. Anschließend werden Exportschemata
spezifiziert, die diejenigen Schemakonzepte enthalten, die dem f¨
oderierten Schema zur Verf¨
ugung
gestellt werden. Anschließend erfolgt die Integration der Konzepte der Exportschemata in ein
gemeinsames integriertes, f¨
oderiertes Schema.
Der Beginn des Top-Down-Ansatzes ist ¨
aquivalent zu dem des Bottom-Up-Ansatzes, indem
lokale Schemata auf Komponentenschemata und anschließend auf Exportschemata abgebildet
werden. Anschließend erfolgt jedoch keine Integration der existierenden Schemakonzepte der
Exportschemata, sondern es wird ein globales Schema definiert. Erst dann werden Abbildun-
gen von Schemakonzepten des globalen Schemas auf korrespondierende Schemakonzepte der
Exportschemata definiert.
LQWHJULHUWHV6FKHPD
([SRUWVFKHPD
$QZHQGXQJ $QZHQGXQJ
([SRUWVFKHPD
'DWHQEDQN 'DWHQEDQN
*OREDOHV6FKHPD
([SRUWVFKHPD
$QZHQGXQJ $QZHQGXQJ
([SRUWVFKHPD
'DWHQEDQN 'DWHQEDQN
,QWHJUDWLRQ 0DSSLQJ
Abbildung 4.4.: Bottom-Up- und Top-Down-Ansatz
Die Integration im Bottom-Up-Ansatz sowie die Abbildungen im Top-Down-Ansatz lassen sich
mit Hilfe von Sichten im relationalen Datenmodell realisieren. F¨
ur die Definition dieser Sichten
gibt es drei Methodiken, die im Folgenden erl¨
autert werden.
Local-as-View (LaV). Die Spezifikation von Abbildungen zwischen Exportschemata und f¨
oder-
iertem Schema im Top-Down-Entwurf mit Hilfe von Sichten wird in der Literatur als Local-as-
View (LaV) bezeichnet [Len02]. Im Speziellen werden f¨
ur ein gegebenes f¨
oderiertes Schema die
Abbildungen von Exportschemata als Sichten auf das f¨
oderierte Schema definiert.
Beispiel 14 (LaV). Abbildung 4.5 illustriert ein Beispiel, in dem ein globales Schema defi-
niert wurde und existierende Exportschemata als Sichten auf dieses Schema definiert werden.
Das f¨
oderierte Schema besteht aus der Relation Komponente mit den Attributen Nr,Label,
Verantwortlicher,Lieferant und Typ. Das Exportschema von Informationssystem A
besteht aus der Relation Bauteil,w
¨
ahrend Informationssystem B die Relation Component
beinhaltet.
Die Abbildungen zwischen f¨
oderiertem Schema und den beiden Exportschemata lassen sich
63
4. Stand der Technik
durch folgende Sichten spezifizieren.
CREATE VIEW Bauteil AS
SELECT K.Nr, K.Label AS Name, K.Lieferant , K.Verantwortlicher ,
K.Typ FROM Komponente AS K
CREATE VIEW Component AS
SELECT K.Nr AS Id, K.Label AS Name, K.Lieferant AS Supplier,
K.Verantwortlicher AS Responsible FROM Komponente AS K
,QIRUPDWLRQVV\VWHP%([SRUWVFKHPD
)|GHULHUWHV6FKHPD
,QIRUPDWLRQVV\VWHP$([SRUWVFKHPD
/DEHO 9HUDQWZRUWOLFKHU /LHIHUDQW 7\S
.RPSRQHQWH
1DPH
%RVFK
+(//$
,G
6XSSOLHU
6WDWXV
DFWLYH
DFWLYH
1DPH
(QJLQH&RQWURO
+HDG/LJKWV
5HVSRQVLEOH
-UJHQ0D\HU
+DQV0OOHU
6XSSOLHU
,G
&RPSRQHQW
1DPH
0RWRUVWHXHUXQJ
6FKHLQZHUIHUYRUQH
9HUDQWZRUWOLFKHU
-UJHQ0D\HU
+DQV0OOHU
/LHIHUDQW
%RVFK
+(//$
1U
%DXWHLO
7\S
(OHNWULVFK
(OHNWULVFK
0RWRUKDXEH 3DXO.OHLQ+(//$0HFKDQLVFK
1U
Abbildung 4.5.: Beispiel f¨
ur LaV
W¨
ahrend in diesem relativ einfachen Beispiel alle Schemakonzepte der Exportschemata durch
Sichten auf das f¨
oderierte Schema definiert werden k¨
onnen, gibt es einige Einschr¨
ankungen
die mit der LaV-Methode nicht modelliert werden k¨
onnen. Existieren Beziehungen zwischen
Schemakonzepten in einem Exportschema, die keine Entsprechung im f¨
oderierten Schema besitzt,
kann diese nicht abgebildet werden. Ist ein Schemakonzept eines Exportschemas genereller als ein
korrespondierendes globales Schemakonzept, kann dies nicht in einer Sicht ausgedr¨
uckt werden.
Wie zuvor erw¨
ahnt, sind F¨
oderierte Datenbanken virtuell integrierende Systeme, dass heißt die
Instanzen verbleiben in den Informationssystemen, ohne dass ihre Daten in das f¨
oderierte Schema
kopiert werden. Folglich m¨
ussen alle Anfragen an das f¨
oderierte Schema ¨
ubersetzt und zerlegt
werden in Teilanfragen an die einzelnen Exportschemata.
64
4.1. Heterogenit¨
at, Autonomie, Integration
Grundidee des LaV-Ansatzes ist es, die einzelnen Sichten so zu einer Anfrage zu kombinieren,
dass deren Ergebnis einen Teil der Anfrage (oder die ganze Anfrage) beantworten. Das Gesam-
tergebnis ist dann die Vereinigung der Ergebnisse mehrerer Anfragen.
Diese sog. Anfrageplanung kann sehr komplex werden, und es existiert hierf¨
ur eine Vielzahl
spezieller Algorithmen [Hal01].
Global-as-View (GaV). Analog zum LaV-Ansatz wird die Spezifikation von Abbildungen zwi-
schen Exportschema und f¨
oderiertem Schema im Bottom-Up-Ansatz mit Hilfe von Sichten in der
Literatur als Global-as-View (GaV) bezeichnet [Len02]. Dass heißt, das f¨
oderierte Schema wird
als Sicht auf die Exportschemata definiert. Folglich k¨
onnen nur Schemakonzepte und Attribute
im f¨
oderierten Schema vorhanden sein, die auch in den Exportschemata spezifiziert worden sind.
Beispiel 15 (GaV).
Abbildung 4.6 illustriert ein Beispiel zur GaV-Methode. Die drei Exportschemata der In-
formationssysteme A,Bund Csollen zu einem f¨
oderierten Schema integriert werden. Jedes
Schema besitzt ein Schemakonzept (Anforderungen,Test und CASE); die Schemakonzepte
wiederum k¨
onnen zu einer Sicht aggregiert werden:
CREATE VIEW Produkt AS
SELECT A.Komponente AS Name, A.Verantwortlicher , A.Anforderun -
gen, A.Variante , C.Version, T.Test FROM Anforderungen AS A
INNER JOIN CASE AS CON A.Komponente = C.Label INNER JOIN Test
AS TON A.Komponente = T.Component
Im Gegensatz zum LaV-Ansatz ist die Anfrageplanung beim GaV-Ansatz deutlich einfacher,
da bereits in der Sichtdefinition festlegt ist, welche Elemente aus dem f¨
oderierten Schema
welchen Elementen aus den Exportschemata entsprechen. Andererseits l¨
asst sich die GaV-
Methode nur realisieren, wenn die Datenqualit¨
at der Instanzen sehr gut ist, insbesondere d¨
urfen
Prim¨
arschl¨
usselattribute keine Fehler (z.B. ung¨
ultige Verweise, Mehrfachvergabe) enthalten. Des
Weiteren geht die GaV-Methode davon aus, dass Instanzen, welche dieselben Dinge in der Real-
welt darstellen, auch gleiche Bezeichner bzw. Identifikationsmerkmale besitzen (etwa eine global
g¨
ultige Nummer oder Id).
Lokale Schemata k¨
onnen Attribute besitzen, die nicht in der globalen Sicht vorkommen m¨
ussen.
Alle Relationen der globalen Sicht m¨
ussen Relationen aus lokalen Schemata sein oder konjunktive
Anfragen dieser Relationen sein. Ist ein Schemakonzept im f¨
oderierten Schema genereller als das
korrespondierende Konzept im Exportschema, kann dies nicht in der Sicht ausgedr¨
uckt werden.
Treten ¨
Anderungen an lokalen Schemata auf, muss die Sicht des globalen Schemas neu erstellt
werden. Die Integration zusammengeh¨
origer Instanzen ist auf die verf¨
ugbaren Befehle der SQL-
Spezifikation (z.B. UNION- und JOIN-Operator) beschr¨
ankt.
65
4. Stand der Technik
,QIRUPDWLRQVV\VWHP&([SRUWVFKHPD
,QIRUPDWLRQVV\VWHP%([SRUWVFKHPD
,QIRUPDWLRQVV\VWHP$([SRUWVFKHPD
)|GHULHUWHV6FKHPD
.RPSRQHQWH
0RWRUVWHXHUXQJ
0RWRUVWHXHUXQJ
9HUDQWZRUWOLFKHU
-UJHQ0D\HU
+DQV0OOHU
$QIRUGHUXQJHQ
.DWDO\WLVFKH5HGXNWLRQ
(XUR
9DULDQWH
'LHVHO
%HQ]LQ
1DPH 9HUDQWZRUWOLFKHU $QIRUGHUXQJHQ 9DULDQWH 7HVW9HUVLRQ
$QIRUGHUXQJHQ
3URGXNW
7HVW
(UIROJUHLFK
)HKOHUKDIW
.RPSRQHQWH
0RWRUVWHXHUXQJ
7UVWHXHUJHUlW
7HVW
.RPSRQHQWH
0RWRUVWHXHUXQJ
0RWRUVWHXHUXQJ
9HUVLRQ
6RXUFH
(&0F
(&0F
3URMHFW
$
%
&$6(
Abbildung 4.6.: Beispiel f¨
ur GaV-Methode
Global-Local-as-View (GLaV). Die Global-Local-as-View (GLaV)-Methode ist eine Kombina-
tion aus den beiden vorherigen. W¨
ahrend bei der LaV-Methode das globale Schema eine Sicht
auf lokale Schemata darstellt, bilden bei der GaV-Methode lokale Schemata die Sichten auf
das globale Schema. Bei GLaV werden Sichten auf das globale Schema als Sichten der loka-
len Schemata definiert. Die Komplexit¨
at f¨
ur die Anfragebearbeitung ist die selbe wie f¨
ur den
LaV-Ansatz.
Abgleich der Anforderungen
Im Folgenden werden die Anforderungen aus Abschnitt 3.3 mit den bisherigen Erkenntnissen zu
f¨
oderierten Datenbanksystemen abgeglichen.
Anforderung 1 (Bedarfsgerechte Integration, Ber¨ucksichtigung von Variabilit¨at und Versio-
nierung) Alle existierenden Ans¨
atze f¨
ur f¨
oderierte Datenbanken gehen von guter Datenqualit¨
at
bzw. dem Vorhandensein global eindeutiger Identifikationsmerkmale aus. Diese sind in der Praxis
h¨
aufig nicht gegeben. Aufgrund der hohen Komplexit¨
at bei der Anfrageverarbeitung verwenden,
bis auf wenige Ausnahmen, alle wissenschaftlichen Ans¨
atze die GaV-Methode. Bei der Inte-
gration mit Hilfe der GaV-Methode sind nur eingeschr¨
ankte Integrationsfunktionen vorhanden,
diese beschr¨
anken sich auf JOIN- und UNION-Operationen sowie definierte SQL-Funktionen
f¨
ur relationale Datenbanken. Die meisten wissenschaftlichen Ans¨
atze sind ¨
uberwiegend Metho-
denbeschreibungen, prototypische Implementierungen der Konzepte fehlen dagegen meist und
k¨
onnen daher nicht getestet werden.
66
4.1. Heterogenit¨
at, Autonomie, Integration
Mit Hilfe f¨
oderierter Datenbanksysteme l¨
asst sich eine Integration bedarfsgerecht durchf¨
uhren,
indem nur diejenigen Schemakonzepte in Exportschemata abgebildet werden, die auch tats¨
achlich
integriert werden sollen. Es existieren keine Ans¨
atze, die sich mit der expliziten Integration von
Konzepten f¨
ur Variabilit¨
at und Versionierung im Kontext f¨
oderierter Datenbanksysteme ausein-
andersetzen.
Anforderung 2 (Benutzerunterst¨utzung) Es gibt keine Unterst¨
utzung von Integrationsauf-
gaben, etwa durch visuelle Editoren. Je nach verwendeter Architektur (Import-Export, Mul-
tidatenbank, 5-Ebenen-Schema) sind unterschiedliche Personengruppen f¨
ur die Erstellung von
Modellen sowie den Abbildungen zwischen ihnen verantwortlich. Jedoch werden die genauen
Aufgaben dieser Gruppen nicht n¨
aher spezifiziert. Ein Konzept zur Unterst¨
utzung von Integra-
tionsaufgaben, etwa die grafische Aufbereitung komplexer Arbeitsschritte, existiert nicht.
Anforderung 3 (Nutzung) Anfragen an das f¨
oderierte Schema sind mit der GaV-Methode zwar
einfach, bleiben aber auf vorhandene Schemakonzepte im f¨
oderierten Schema beschr¨
ankt. Die
Anfrageplanung mit der LaV-Methode wiederum kann sehr komplex werden.
Anforderung 4 (Monitoring) Der Integrationsprozess als solches wird nicht ¨
uberwacht bzw.
dessen Qualit¨
at nicht gemessen. Vielmehr wird aufgrund der Annahme einer guten Datenqualit¨
at
von einer vollst¨
andig automatischen Integration ausgegangen.
Anforderung 5 (Change Management) Bei ¨
Anderungen bzw. der Integration neuer Informa-
tionssysteme muss beim GaV-Ansatz die gesamte Sicht angepasst werden. Da Integrationswissen
hart in die Sichten kodiert ist, kann sich die Anpassung bei einem großen f¨
oderierten Schema
aufwendig gestalten. Beim LaV-Ansatz muss bei ¨
Anderungen die Anfrageplanung angepasst
werden. W¨
ahrend ¨
Anderungen von Schemata dazu f¨
uhren, dass solche Sichten oder die Anfrage-
bearbeitung angepasst werden m¨
ussen, sind das Einf¨
ugen, ¨
Andern und L¨
oschen von Instanzen
in f¨
oderierten Datenbanken m¨
oglich.
Anforderung 6 (Methodiken) Durch GaV, LaV und GLaV werden unterschiedlichen Metho-
den f¨
ur die Erstellung einer F¨
oderation bereitgestellt. Explizite Methoden f¨
ur die Abbildung von
Variabilit¨
ats- und Versionierungsmechnismen existieren dagegen nicht.
4.1.2. Data Warehouse Systeme
Virtuell integrierende Systeme, wie f¨
oderierte Datenbanken, weisen eine Vielzahl an Nachteilen
auf, etwa die Dauer der Anfragebearbeitung, die Verf¨
ugbarkeit von Informationssystemen oder
die Komplexit¨
at der Anfragebearbeitung betreffend.
Multidimensionale Datenmodellierung
Data Warehouses (DWHs) f¨
uhren eine materialisierte Integration durch, d.h. Daten aus lokalen
Informationssystemen werden in ein globales System kopiert, bereinigt und integriert [CD97].
DWHs kommen in verschiedenen Anwendungsf¨
allen zum Einsatz. Dazu z¨
ahlen vor allem Anwen-
dungen, bei denen die Analyse großer Datenbest¨
ande (z.B. Verkaufszahlen von Produkten oder
67
4. Stand der Technik
Korrelationen zwischen verkauften Produkten und K¨
aufergruppen) im Fokus stehen. Folglich un-
terscheidet sich die Modellierung von Daten grundlegend zu klassischen Informationssystemen,
die auf dem relationalen Datenmodell basieren. Diese Modellierung wird als multidimensionale
Datenmodellierung bezeichnet, bei der Fakten entlang verschiedener Dimensionen modelliert
werden [KR11]. Beispiele f¨
ur Fakten sind Gesch¨
aftsmetriken wie etwa Verk¨
aufe oder Telefona-
te in einem Service-Unternehmen. Zu den Dimensionen z¨
ahlen oftmals Zeitpunkte, Regionen
oder Lieferanten. Dimensionen lassen sich in der Regel hierarchisch anordnen (z.B. Jahr-Monat-
Woche-Tag). Die grafische Darstellung von Fakten kann bei drei Dimensionen als W¨
urfel erfol-
gen.
Abbildung 4.7 zeigt die grundlegende Architektur eines DWH. Zun¨
achst wird definiert, welche
Datenquellen integriert und welche Anwendungsf¨
alle unterst¨
utzt werden sollen. Anschließend
werden Schemata und Sichten des DWH sowie dessen physisches Schema definiert, bevor schließ-
lich die Datenquellen ¨
uber Schnittstellen eingebunden werden. Diese werden mit Hilfe eines zuvor
definierten Extract-Transform-Load (ETL) Prozesses in ein DWH kopiert, bereinigt (Fehler be-
seitigt, Daten in einheitliche Formate ¨
uberf¨
uhrt) und integriert. Dazu werden Skripte f¨
ur die
Datenextraktion, -transformation, -bereitstellung und -aktualisierung erstellt. Ein Integrations-
prozess ist immer anwendungsspezifisch, dass heißt der ETL-Prozess definiert nur ein abstraktes
Ablaufschema, dessen einzelne Aktivit¨
aten angepasst werden m¨
ussen. Ein wichtiger Schritt ist
die Definition eines Refresh-Plans, der spezifiziert wann Aktualisierungen von operationalen Da-
tenbanken in das DWH ¨
ubernommen werden sollen. Da letztere in der Regel mehrere Terrabyte
umfassen k¨
onnen, ist eine kontinuierliche Aktualisierung nicht praktikabel. Vielmehr geschehen
Aktualisierungen nach Bedarf oder festgelegten Zeitpunkten. Das DWH wird mit Hilfe des zu-
vor festgelegten Schemas sowie der Sichten durch die Skripte bef¨
ullt und kann anschließend f¨
ur
unterschiedliche Analysem¨
oglichkeiten aufbereitet werden.
'DWHQTXHOOHQ
'DWD:DUHKRXVH
'DWD0DUW 'DWD0DUW 'DWD0DUW
(7/
$QDO\VH
5HSRUWLQJ
'DWD
0LQLQJ
0RQLWRULQJ
$GPLQLVWUDWLRQ
Abbildung 4.7.: Architektur eines DWH, in Anlehnung an [CD97]
Star- und Snowflake-Schema
Die Abbildung multidimensionaler Daten auf eine relationale Datenbank kann mit dem Star-
oder dem Snowflake-Schema geschehen (siehe Abbildung 4.8). In beiden F¨
allen ist der Fakt ein
68
4.1. Heterogenit¨
at, Autonomie, Integration
Verkauf. Im Star-Schema wird jede Dimension in einer eigenen Tabelle gespeichert, im Fall
von a) sind dies Produkt,Zeitpunkt und Filiale. Im Fall des Snowflake-Schemas in b) erh¨
alt
jede Klassifikationsstufe eine eigene Tabelle. W¨
ahrend das Star-Schema weniger Tabellen und
damit weniger JOIN-Operationen bei Abfragen ben¨
otigt, werden Daten redundant (d.h. nicht
normalisiert) gespeichert. Anders sieht es im Snowflake-Schema aus, wo zwar die Redundanz
vermieden wird, sich Anfragen aber komplexer gestalten.
,G
7DJB,G
2UWB,G
3UHLV
9HUNDXI
=HLWB,G
7DJ
0RQDW
-DKU
=HLWSXQNW
2UWB,G
1DPH
5HJLRQ
%XQGHVODQG
/DQG
)LOLDOH
,G
1DPH
*UXSSH
3URGXNW =HLWB,G
5HJLRQB,G
3URGXNWB,G
3UHLV
9HUNDXIB,G
0RQDW
4XDUWDOB,G
=HLWB,G
5HJLRQ
/DQGB,G
5HJLRQB,G
1DPH
*UXSSH
3URGXNWB,G
7DJ
0RQDW
-DKUB,G
4XDUWDOB,'
-DKU
-DKUB,G
/DQG
/DQGB,G
D E
Abbildung 4.8.: Beispiel eines multidimensionalen Datenmodells im Star-Schema
Ein multidimensionales Datenmodell l¨
asst sich mit Hilfe eines W¨
urfels visualisieren, falls die
Anzahl der Dimensionen drei entspricht. Sind mehr Dimensionen vorhanden, handelt es sich
um einen Hyperw¨
urfel, der jedoch nicht ohne weiteres grafisch dargestellt werden kann. Auf
einem W¨
urfel sind f¨
ur DWHs spezielle Operationen definiert, welche die Navigation im bzw.
Transformation des W¨
urfels erlauben. Zu diesen Operationen z¨
ahlen u.a. roll-up,drill-down,
slice-and-dice und pivot.
=HLW
2UW
*
UXSSH
%D\HUQ
%DGHQ:UUWHPEHUJ
%UDQGHQEXUJ
«
'LHQVWOHLVWXQJHQ
gIIHQWOLFK
0LWWHOVWlQGOHU
*URXQWHUQHKPHQ
Abbildung 4.9.: W¨
urfeldarstellung eines DWH-Schemas
69
4. Stand der Technik
Da das Schema des DWH eine Vielzahl an Fakten entlang verschiedener Dimensionen speichert,
werden anwendungsspezifische Ausschnitte dieses Schemas als sog. Data Marts definiert. Abbil-
dung 4.9 zeigt einen W¨
urfel f¨
ur die visuelle Darstellung des Star-Schemas aus Abbildung 4.8
a.
Bottom-Up- und Top-Down-Entwurf
Methodisch l¨
asst sich ein Data Warehouse auf verschiedene Arten realisieren. [Inm05] schl¨
agt
dazu einen Top-Down-Ansatz vor. Dabei wird zun¨
achst ein normalisiertes Datenmodell erstellt,
bevor die Data Marts definiert werden, die dann Daten f¨
ur spezifische Gesch¨
aftsbereiche oder Ab-
teilungen bereitstellen. Dem entgegen steht der Bottom-Up-Ansatz von [KR11], in dem zun¨
achst
die Data Marts erstellt werden. Diese werden anschließend kombiniert, um das Datenmodell des
Data Warehouse zu erhalten. Beide Ans¨
atze haben ihre Vor- und Nachteile, die Anwendung
des jeweiligen Ansatzes h¨
angt vom Einsatzbereich ab. Der in [Inm05] skizzierte Ansatz ist sehr
zeitaufw¨
andig und mit hohen initialen Kosten verbunden, da die Erstellung des DWH durch
Spezialisten erfolgen muss. Daf¨
ur ist die Verwaltung eines bestehenden DWH einfach. Auf der
anderen Seite ist der Ansatz von [KR11] mit geringeren initialen Kosten verbunden und kann
schneller realisiert werden, da auch Generalisten die Integrationsaufgaben erledigen k¨
onnen.
Dagegen ist die Verwaltung eines bestehenden DWH erheblich aufw¨
andiger als mit dem ersten
Ansatz.
Abgleich der Anforderungen
Die Erkenntnisse zu Data Warehouses werden nun mit den Anforderungen aus Kapitel 3.3 ab-
geglichen.
Anforderung 1 (Bedarfsgerechte Integration, Ber¨ucksichtigung von Variabilit¨at und Versio-
nierung) W¨
ahrend der Fokus eines DWH auf der Entscheidungsunterst¨
utzung f¨
ur Unterneh-
men durch die Integration von Fakten (z.B. Verkaufszahlen) entlang verschiedener Dimensionen
liegt, ist eine Modellierung von Produktdaten durch eine multidimensionale Modellierung nicht
m¨
oglich. Wichtiges Merkmal von Daten f¨
ur DWHs ist die F¨
ahigkeit der Aggregation, welche f¨
ur
Produktdaten nur bedingt gegeben ist. DWHs bieten die M¨
oglichkeit, Daten bedarfsgerecht zu
integrieren, jedoch existieren wie bei den f¨
oderierten Datenbanksystemen (FDBS) keine explizi-
ten Konzepte f¨
ur die Integration von Variabilit¨
ats- und Versionierungskonzepten. Weiter sind
die Integrationsskripte im ETL-Prozess anwendungsspezifisch.
Anforderung 2 (Benutzerunterst¨utzung) Durch die kommerzielle Verbreitung von Data Ware-
house Systemen, besitzen diese unterschiedliche Funktionsumf¨
ange. Dazu z¨
ahlen auch Funk-
tionen zur Unterst¨
utzung der ETL-Prozesse. F¨
ur dessen Definition existiert eine Vielzahl an
Software-Systemen, die u.a. eine grafische Modellierung der ETL-Prozesse erlauben.
Anforderung 3 (Nutzung) Durch die multidimensionale Modellierung sind die M¨
oglichkeiten
f¨
ur Abfragen begrenzt. Die Anfragen an integrierte Produktdaten sind allgemeiner als eine Ein-
schr¨
ankung auf Fakten und Dimensionen, wodurch sich ein DWH nicht als Realisierung f¨
ur ein
PDIS eignet.
70
4.1. Heterogenit¨
at, Autonomie, Integration
Anforderung 4 (Monitoring) Genau wie bei der Benutzerunterst¨
utzung h¨
angen die Funktiona-
lit¨
aten f¨
ur das Monitoring eines DWH vom eingesetzten Produkt ab. IBM InfoSphere Informati-
on Server etwa ist eine Komponente f¨
ur die Integration von Daten f¨
ur ein DWH. Sie erm¨
oglicht
zudem die Definition von Monitoring-Prozessen [BBK`13]. Es lassen sich Qualit¨
atsziele f¨
ur Da-
ten definieren, ebenso wie ein entsprechender Prozess, der diese Qualit¨
atsziele ¨
uberpr¨
uft. Da es
sich lediglich um ein System zur Realisierung von ETL handelt, wird der Integrationsprozess an
sich nicht ¨
uberwacht.
Anforderung 5 (Change Management) Probleme, die durch ¨
Anderungen eines DWH entste-
hen, werden in der Literatur als View Maintenance Problem bezeichnet. Die meisten Ans¨
atze
befassen sich mit der Fragestellung, wie materialisierte Sichten konsistent mit den zugrundelie-
gendenDatenquellengehaltenwerdenk
¨
onnen. [Bel02] beschreibt, wie strukturelle ¨
Anderungen
in einem DWH unterst¨
utzt werden k¨
onnen. Dabei werden z.B. materialisierte Sichten dynamisch
angepasst, und es wird versucht, soweit sinnvoll und m¨
oglich, alte Sichten wiederzuverwenden.
Dar¨
uber hinaus k¨
onnen ¨
Anderungen am Schema des Data Warehouse unabh¨
angig von den Sche-
mata der integrierten Systeme durchgef¨
uhrt werden. Schließlich beschreibt [PVSV07] einen An-
satz, mit dem What-If-Analysen f¨
ur ¨
Anderungen an Schema und Instanzen von Datenquellen
durchgef¨
uhrt werden k¨
onnen. Dar¨
uber hinaus werden die Auswirkungen f¨
ur ETL-Prozesse be-
stimmt.
Anforderung 6 (Methodiken) Analog zu f¨
oderierten Datenbanken existieren Bottom-Up- und
Top-Down-Ans¨
atze, die unterschiedliche Szenarien unterst¨
utzen. Jedoch fehlen bei den Data
Warehouse Systemen eine explizite Unterst¨
utzung f¨
ur die Modellierung von Variabilit¨
ats- und
Versionierungskonzepten.
4.1.3. Peer-Daten-Management-Systeme
Basierend auf den Prinzipien von Peer-to-Peer-Systemen sind die Peer-Daten-Management-
Systeme entstanden [HRZ`08]. Zun¨
achst werden Grundlagen erl¨
autert, bevor die Anfragebe-
arbeitung detailliert wird. Schließlich werden die Anforderungen abgeglichen.
Grundlagen
Grundidee ist, dass Anfragen an alle Informationssysteme (Peer) gestellt werden k¨
onnen, die
Teil einer Integration sind. Damit z¨
ahlen Peer-Daten-Management-Systeme zu den virtuell inte-
grierenden Systemen. Ein Peer versucht Anfragen mit Hilfe seiner eigenen Daten sowie den Da-
ten weiterer Informationssysteme (Peers) zu beantworten. Ziele eines Peer-Daten-Management-
Systems sind die Autonomie des Peers sowie geringe Initial- und Wartungskosten, ohne Einbin-
dung eines zentralen Koordinators [RS13].
Abbildung 4.10 illustriert ein Peer-Daten-Management-System. Zwischen den verschiedenen
Peers existieren unterschiedliche Beziehungen zwischen deren Schemata. W¨
ahrend zwischen BOM,
PDM und Requirements jeweils bidirektionale Mappings bestehen, sind alle anderen Abbildungen
unidirektional. Ein Mapping zwischen den Schemata zweier Peers definiert ¨
Aquivalenzen zwi-
schen denselben Schemakonzepten sowie notwendige Transformationen. Ein Peer fungiert sowohl
als Datenquelle als auch Mediator, in dem er Anfragen an weitere Peers weiterleitet. Mappings
71
4. Stand der Technik
zwischen Schemata der Peers k¨
onnen sowohl mittels GaV -, LaV -alsauchGLaV -Ansatz defi-
niert werden (vgl. Abschnitt 4.1.1).
6FKHPD 'DWHQ 0DSSLQJ
3'0
%20
(3'0
'08
7HVWLQJ
5HTXLUHPHQWV
Abbildung 4.10.: Peer-Daten-Management
Anfragebearbeitung
Angenommen die Peers in Abbildung 4.10 besitzen alle ein gemeinsames Schemakonzept, wel-
che untereinander entsprechend der Pfeile mittels Mappings abgebildet sind. Dann k¨
onnte eine
Anfrage etwa an den Peer BOM im Netzwerk wie folgt abgearbeitet werden: Die Anfrage soll alle
Attribute des gemeinsamen Schemakonzeptes aus allen Peers zur¨
uckgeben, so dass tats¨
achlich
alle Peers abgefragt werden m¨
ussen. Abbildung 4.11 zeigt zwei sogenannte rule-goal-trees,also
Anfrageb¨
aume an das Peer-Netzwerk, die die Anfrage erf¨
ullen.
%20
3'0
'08
5HTXLUHPHQWV
7HVWLQJ
(3'0
%20
3'0
'08
5HTXLUHPHQWV
7HVWLQJ
(3'0
D E
Abbildung 4.11.: Beispiele f¨
ur Rule-Goal-Trees
Abgleich der Anforderungen
Die Erkenntnisse von Peer-Daten-Management-Systeme werden nun mit den Anforderungen aus
Kapitel 3.3 abgeglichen.
Anforderung 1 (Bedarfsgerechte Integration, Ber¨ucksichtigung von Variabilit¨at und Versio-
nierung) Da es sich bei Peer-Daten-Management-Systemen um virtuell integrierende Systeme
handelt, ist die Integration ¨
ahnlich zu bewerten wie bei f¨
oderierten Datenbanksystemen. Es
wird angenommen, dass die Datenqualit¨
at gut ist und ¨
ahnliche Schemakonzepte in den Schema-
ta der Peers vorhanden sind. Durch die fehlende Materialisierung m¨
ussen Inkonsistenzen bereits
72
4.1. Heterogenit¨
at, Autonomie, Integration
w¨
ahrend der Anfragebearbeitung vollst¨
andig aufgel¨
ost werden. Es gibt einige Konzepte, die sich
mit Konsistenzproblemen w¨
ahrend der Integration befassen. Dabei wird zwischen lokaler Inkon-
sistenz und P2P-Inkonsistenz unterschieden. Im ersten Fall sind Daten im lokalen Speicher eines
Peers inkonsistent. Im zweiten Fall ist jeder Peer lokal konsistent, aber es gibt Widerspr¨
uche
in den Daten zwischen den Peers, oder ein Peer importiert inkonsistente Daten eines anderen.
Lokale Inkonsistenz eines Peers f¨
uhrt automatisch dazu, dass das System unbrauchbar ist, da es
global inkonsistent ist. Um diesem Problem zu begegnen, lassen sich in einigen Systemen lokal
inkonsistente Peers von Abfragen ausschließen. Bei P2P-Inkonsistenz wird versucht, durch Algo-
rithmen die Inkonsistenzen automatisch aufzul¨
osen. Bestehende Ans¨
atze gehen davon aus, dass
alle Peers die gleiche Dom¨
ane teilen, d.h. dass diese gleiche Elemente f¨
ur die Repr¨
asentation von
Realweltobjekten verwenden. Wie bereits in der Anforderungsanalyse erl¨
autert, spiegel dies nicht
die Realit¨
at in der Produktentwicklung wider. Wie alle bisher diskutierten Ans¨
atze bieten auch
Peer-Daten-Management-Systeme keine expliziten Konzepte f¨
ur die Integration unterschiedlicher
Variabilit¨
ats- und Versionierungskonzepte.
Anforderung 2 (Benutzerunterst¨utzung) Da es sich um virtuell integrierende Systeme han-
delt, wird davon ausgegangen, dass die Integration von Daten im Zuge der Anfragebearbeitung
vollautomatisch und ohne Benutzerinteraktion geschieht. F¨
ur das Mapping zwischen Peers sind
keine expliziten Unterst¨
utzungskonzepte bekannt.
Anforderung 3 (Nutzung) Da die Abbildungen zwischen Schemata der Peers mit Hilfe von
LaV, GaV und GLaV erfolgen, sind die Aussagen zur Nutzung integrierter Daten ¨
ahnlich wie
bei f¨
oderierten Datenbanksystemen. Durch die dezentrale Architektur kommt zus¨
atzlich Kom-
plexit¨
at f¨
ur die Anfragebearbeitung in folge der Ermittlung der Rule-Goal-Trees hinzu.
Anforderung 4 (Monitoring) Durch die dezentrale Architektur findet keine zentrale ¨
Uberwa-
chung der Integration statt. Wie erw¨
ahnt, gehen Peer-Daten-Management-Systeme davon aus,
dass die Integration vollst¨
an-dig und konsistent in der Anfragebearbeitung erfolgt.
Anforderung 5 (Change Management) Bisher gibt es wenige Konzepte zur Unterst¨
utzung von
¨
Anderungen auf Schemaebene. Einige Ans¨
atze propagieren ¨
Anderungen lokaler Datenquellen an
ihre direkten Nachbarn, was jedoch zu vielen Problemen f¨
uhren kann [RS13]. Da ¨
Anderungen
sowohl an Schemakonzepten als auch an Instanzen eine zentrale Eigenschaft von Produktent-
wicklungsprozessen darstellen, ist die fehlende Unterst¨
utzung von ¨
Anderungsoperationen ein
Ausschlusskriterium f¨
ur die Verwendung von Peer-Daten-Management-Systemen zur Integrati-
on von Produktdaten.
Anforderung 6 (Methodiken) Da die Abbildungen zwischen den Schemakonzepten eines Peers
zu weiteren Peers entweder durch LaV- oder GaV-Abbildungen erfolgen k¨
onnen, sind, wie bei
f¨
oderierten Datenbanksystemen, zwei Methodiken f¨
ur die Modellierung von Schemakorrespon-
denzen m¨
oglich. Wie bei allen bisherigen Ans¨
atzen sind auch hier keine expliziten Konzepte f¨
ur
die Modellierung unterschiedlicher Variabilit¨
ats- und Versionierungskonzepte vorhanden.
73
4. Stand der Technik
4.1.4. Tool Integration
Bereits in Abschnitt 2.3.2 wurde diskutiert, dass eine Tool-Integration deutlich mehr umfasst,
als nur Schema- und Datenintegration. Im weiteren Verlauf sollen aber nur die Bereiche der
Schema- und Datenintegration ausgew¨
ahlter Ans¨
atze untersucht werden. Die wichtigste Gruppe
von Ans¨
atzen basiert auf sog. Triple-Graph-Grammatiken (TGG) [KS06]. Die Integration von
Informationssystemen geschieht paarweise auf Metamodellebene. Im Speziellen werden mit Hil-
fe von Korrespondenzen, die in einem eigenen Metamodell definiert werden, Elemente der zu
integrierenden Metamodelle bidirektional aufeinander abbildet.
Abbildung 4.12 illustriert die Metamodelle zweier Informationssysteme aus der Softwareentwick-
lung f¨
ur eingebettete Echtzeitsysteme in der Automobilindustrie sowie das Abbildungsmodell
zwischen beiden (siehe Abbildung 4.12b). In Abbildung 4.12a ist das Metamodell zur Spezifi-
kation von Anforderungen an eine Komponente dargestellt (RequirementsDocument). Feature
k¨
onnen zu Gruppen zusammengefasst werden (FeatureGroup) sowie Beziehungen (Dependency)
zu anderen Features haben. In Abbildung 4.12c ist zudem das Metamodell f¨
ur die Model-
lierung von UML-Use-Case-Diagrammen illustriert. Anwendungsf¨
alle (UseCaseDocument)sind
Diagramme, die in Packages zusammengefasst werden und die Beziehungen (Relationship)
zu anderen Anwendungsf¨
allen haben k¨
onnen. In Abbildung 4.12b ist zudem die Abbildung der
Metamodellelemente spezifiziert, in der semantisch zusammengeh¨
orige Schemakonzepte aufein-
ander bidirektional abgebildet sind. Demnach geh¨
ort eine FeatureGroup zu einem Package,ein
Feature zu einem UseCase sowie eine Dependency zu einer Relationship.
WUJ
VUF
Requirement
)HDWXUH*URXS
QDPH6WULQJ
)HDWXUH
QDPH6WULQJ
'HSHQGHQF\
5HTXLUHPHQWV'RFXPHQW
D
,QWHJUDWLRQ!!
)HDWXUH*URXS3DFNDJH5HODWLRQ
,QWHJUDWLRQ!!
)HDWXUH8VH&DVH5HODWLRQ
,QWHJUDWLRQ!!
'HSHQGHQF\5HODWLRQVKLS5HODWLRQ
)HDWXUH*URXS
QDPH6WULQJ
)HDWXUH
QDPH6WULQJ
'HSHQGHQF\
8VH&DVH
QDPH6WULQJ
Relationship
3DFNDJH
QDPH6WULQJ
,QWHJUDWLRQ6FKHPD
E
WUJ
VUF
Container
3DFNDJH
QDPH6WULQJ
'LDJUDP
8VH&DVH
QDPH6WULQJ
Relationship
*HQHUDOL]DWLRQ
8VH&DVH'RFXPHQW
F
Abbildung 4.12.: Metamodelle zweier Informationssysteme sowie dessen Abbildung [KS06]. Creative
Commons Lizenz Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-
ND 3.0), https://creativecommons.org/licenses/by-nc-nd/3.0/
TGGs erlauben es, bidirektionale Transformationen zwischen Paaren von Graphen zu definie-
ren, die ¨
uber einen Korrespondenzgraphen verbunden werden. Analog werden die Metamodelle
74
4.1. Heterogenit¨
at, Autonomie, Integration
in Graphgrammatiken [Roz97] ¨
uberf¨
uhrt. Die Transformation erfolgt durch sog. Graph Rewri-
ting Rules. Jede Regel besteht aus einer rechten und linken Seite. Letztere ist ein zu findenes
Muster innerhalb des Graphen, welches durch ein anderes auf der rechten Seite spezifiziertes
Muster ersetzt wird. Die Triple-Graph Grammatiken erlauben die Spezifikation von Korrespon-
denzen auf Basis von Attributen der Schemakonzepte. Abbildung 4.13 zeigt unterschiedliche Re-
geln, mit der die Metamodelle aus Abbildung 4.12 konsistent gehalten werden. Die erste Regel
createFeatureGroupAndPackage in Abbildung 4.12a ist f¨
ur die Erstellung eines neuen Modells
zust¨
andig, in dem sowohl eine FeatureGroup im Modell f¨
ur Anforderungen angelegt wird und
gleichzeitig ein Package im Model f¨
ur Use Cases. Diese beiden Modellelemente werden mitein-
ander verbunden und besitzen den selben Namen. Die zweite Regel in Abbildung 4.12b f¨
ugt
einer bestehenden FeatureGroup sowie einem zugeh¨
origem Package eine neue FeatureGroup
mit einem korrespondierendem Package hinzu.
QHZ!!
IJ)HDWXUH*URXS
3DFNDJH
QHZ!!
)HDWXUH*URXS3DFNDJH5HODWLRQ
)HDWXUH*URXS )HDWXUH*URXS3DFNDJH5HODWLRQ
QHZ!!
S3DFNDJH
QHZ!!
IJ)HDWXUH*URXS
QHZ!!
)HDWXUH*URXS3DFNDJH5HODWLRQ
QHZ!!
S3DFNDJH
QHZ!!QHZ!!
QHZ!!
QHZ!!
QHZ!!
QHZ!!
&RQVWUDLQW
IJQDPH SQDPH
&RQVWUDLQW
IJQDPH SQDPH
FUHDWH)HDWXUH*URXS$QG3DFNDJH[6WULQJ\6WULQJ
DGG)HDWXUH*URXS$QG3DFNDJH[6WULQJ\6WULQJ
QDPH [
QDPH [
QDPH \
QDPH \
D
E
8VH&DVHV
&RUUHVSRQGHQFHV
5HTXLUHPHQWV
Abbildung 4.13.: Graph rewriting rules [KS06]. Creative Commons Lizenz Attribution-
NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0),
https://creativecommons.org/licenses/by-nc-nd/3.0/
Abgleich der Anforderungen
Die Erkenntnisse zur Tool Integration werden nun mit den Anforderungen aus Kapitel 3.3 ab-
geglichen.
75
4. Stand der Technik
Anforderung 1 (Bedarfsgerechte Integration, Ber¨ucksichtigung von Variabilit¨at und Versio-
nierung) Fokus der Tool-Integrationsans¨
atze mittels TGGs ist die Sicherstellung der Konsis-
tenz zwischen Modellen. Die Integration erfolgt dabei paarweise auf Metamodell-Ebene. Bei
großer Anzahl zu integrierender Systeme, wird die Zahl der ben¨
otigten Abbildungen zwischen
den Informationssystemen sehr groß. Eine vollst¨
andige Kopplung aller nSysteme untereinander
w¨
urde n˚pn´1q{2 TGGs ben¨
otigen. Bei 10 Systemen sind dies bereits 45 potenzielle Schnittstel-
len. Bisher werden in den Abbildungsmetamodellen nur einfache Regeln f¨
ur die Beschreibung von
Beziehungen zwischen Attributen unterst¨
utzt. [KS06] f¨
uhrt außerdem an, dass die vollst¨
andige
Konsistenz der Modelle durch TGGs zu jedem Zeitpunkt in der Praxis utopistisch ist, da sich
alle Dokumente und Entwicklungsmodelle gleichzeitig weiterentwickeln m¨
ussten.
Anforderung 2 (Benutzerunterst¨utzung) Sowohl mit MOFLON [AKRS06] als auch FUJABA
[BGN`04] existieren zwei Ans¨
atze, die grafische Benutzeroberfl¨
achen f¨
ur die Definition von
TGGs sowie Graph Rewriting Rules bieten. Die Ans¨
atze gehen von einer hohen Datenqualit¨
at
aus, etwa dass Modellelemente in den zu integrierenden Informationssystemen gleich benannt
sind und sich somit eindeutig identifizieren lassen. Diese Annahme kann f¨
ur die Produktentwick-
lung jedoch aufgrund von Concurrent Engineering nicht getroffen werden. Folglich wird auch
keinegrafischeUnterst
¨
utzung f¨
ur die Au߬
osung von Konsistenzproblemen auf Modellebene (In-
stanzen) angeboten. Schließlich ist es schwierig, einen ¨
Uberblick ¨
uber das integrierte Metamodell
zu behalten, wenn die zu integrierenden Metamodelle komplex sind. In diesem Fall k¨
onnen die
Graph Rewriting Rules derart komplex werden, dass sie nur noch von Experten verwaltet werden
k¨
onnen.
Anforderung 3 (Nutzung) Der Nutzen von Tool-Integrationsans¨
atzen beschr¨
ankt sich auf die
Konsistenzsicherung von Modellen zwischen Informationssystemen. Die Integration der Meta-
modelle erfolgt nur paarweise, und ein globales Integrationsmodell fehlt in diesem Fall.
Anforderung 4 (Monitoring) Es ist keine Arbeit bekannt, die sich mit dem Monitoring des
Prozesses einer Tool-Integration besch¨
aftigt. Durch die Definition von Graph Rewriting Ru-
les wird angenommen, dass Modelle stets konsistent sind und eine manuelle Integration nicht
erforderlich ist.
Anforderung 5 (Change Management) Ziel der Tool-Integration ist die Konsistenzsicherung
von Modellen zwischen verschiedenen Informationssystemen. D.h. ¨
Anderungen von Instanzen
bzw. Modellen werden durch die Graph Rewriting Rules an das jeweils korrespondierende Infor-
mationssystem propagiert. Anders verh¨
alt es sich mit ¨
Anderungen der Metamodelle. Bisher ist
kein Ansatz bekannt, der sich mit der expliziten ¨
Anderung von Metamodellen und den daraus
resultierenden Auswirkungen auf eine bestehende Integration befasst. Im Fall einer Metamo-
dell¨
anderung muss die Integration der Schemakonzepte erneut durchgef¨
uhrt werden. Dazu z¨
ahlt
auch die Erstellung eines Abbildungsmetamodells sowie die Definition von Graph Rewriting
Rules.
Anforderung 6 (Methodiken) [KRS08] beschreibt einen Prozess zur Integration von Infor-
mationssystemen, die sowohl Anforderungen als auch Use-Case-Diagramme zur Entwicklung
76
4.1. Heterogenit¨
at, Autonomie, Integration
mechatronischer Systeme verwalten. Dazu definieren die Autoren eine Architektur, die aus ei-
nem Integrationsservice,einemModellrepository und Tooladaptern besteht. Der Integrations-
service ist f¨
ur die Erstellung sog. Traceability Links zust¨
andig, die zwischen Schemakonzepten
unterschiedlicher Metamodelle definiert werden. Der Service legt diese Informationen im Mo-
dellrepository ab und ist dar¨
uber hinaus f¨
ur die Propagation von ¨
Anderungen in Modelle der
Informationssysteme zust¨
andig. F¨
ur jedes Informationssystem, dass integriert werden soll, muss
ein Tooladapter implementiert werden. Explizite Konzepte zur Abbildung unterschiedlicher Va-
riabilit¨
ats- und Versionierungskonzepte gibt es nicht.
4.1.5. Weitere Vorgehensweisen
Wie in Abschnitt 2.3 erl¨
autert, ist Heterogenit¨
at eines der Hauptprobleme bei der Integration von
Informationssystemen. [GOP02, Tho09] schlagen L¨
osungen f¨
ur die Interoperabilit¨
at heterogener
Informationssysteme (vgl. Abschnitt 2.3.6) vor und bewerten die einzelnen Ans¨
atze.
•Kategorie 1: Alle bestehenden Informationssysteme werden durch ein System abgel¨
ost,
das alle Daten beinhaltet.
•Kategorie 2: Zwischen jeweils zwei Informationssystemen werden Datentransformationen
realisiert.
•Kategorie 3: Daten der Informationssysteme werden in ein neutrales Format ¨
uberf¨
uhrt.
•Kategorie 4: Es folgt eine manuelle Wiedereingabe von Daten.
Auf den ersten Blick erscheint die Vorgabe eines einzelnen Systems als L¨
osung f¨
ur den Aus-
tausch von Daten vorteilhaft, jedoch gibt es einige Argumente, die gegen dieses Vorgehen spre-
chen. Innerhalb eines Unternehmens haben Abteilungen unterschiedliche Anforderungen, die
m¨
oglicherweise nicht alle durch ein einzelnes System abgedeckt werden k¨
onnen. So kann ein ein-
zelnes System nur als Kompromiss angesehen werden. Schwieriger wird es, ein einzelnes System
entlang einer Wertsch¨
opfungskette mit verschiedenen Zulieferern zu etablieren. Letztere arbei-
ten h¨
aufig f¨
ur mehrere OEMs und m¨
ussten dem entsprechend f¨
ur jeden OEM ein System zum
Datenaustausch vorhalten, was erhebliche Wartungs- und Schulungskosten nach sich zieht.
In der Produktentwicklung wurde bereits versucht, mit PDM-Systemen ein zentrales System
f¨
ur die Dokumentation von Entwicklungsergebnissen zu etablieren [Sta11]. Trotzdem werden
heute viele kleine bereichsabh¨
angige Applikationen eingesetzt und entwickelt, die schneller an
¨
Anderungen (Gesetze, Innovationen) angepasst werden k¨
onnen. Schließlich l¨
ost ein einziges Sys-
tem nicht das Problem, dass Datenmodell¨
anderungen auftreten k¨
onnen oder neue Applikatio-
nen integriert werden m¨
ussen. Des weiteren ist es aus praktischer Sicht nicht realisierbar, da
bestehende IT-Landschaften in der Produktentwicklung ¨
uber Jahrzehnte gewachsen und dem
entsprechend komplex sind.
Punkt-zu-Punkt Datenaustausch hat den Nachteil, dass die Anzahl der ben¨
otigten Transforma-
toren mit der Anzahl der zu integrierenden Systeme quadratisch steigt.1Zus¨
atzlich m¨
ussen bei
Datenmodell¨
anderungen eines Systems im ung¨
unstigsten Fall alle Transformatoren zu diesem
System angepasst werden. Vertreter sind Peer-Daten-Management-Systeme oder Ans¨
atze zur
1Sollen Daten zwischen alle Systeme untereinander transformiert werden, so werden maximal n˚pn´1q
2Transfor-
mationen ben¨
otigt.
77
4. Stand der Technik
Tool-Integration. Schließlich existiert die M¨
oglichkeit, sich auf ein gemeinsames neutrales For-
mat zu einigen und dieses zu standardisieren. Auch wenn ein solches Format einen Kompromiss
zwischen allen beteiligten Systemen darstellt, bietet es doch die M¨
oglichkeit, ¨
Anderungen am
gemeinsamen Format koordiniert abzustimmen. Im Abschnitt 4.2 werden Standards betrachtet,
die in der Produktentwicklung relevant sind.
Die manuelle Wiedereingabe von Daten ist mit enormen Kosten verbunden und kann bei Fehl-
eingaben weitere Kosten nach sich ziehen. Sie ist somit nur in sehr kleinem Umfang und in
Ausnahmef¨
allen eine m¨
ogliche L¨
osung.
4.2. Standards
Eine M¨
oglichkeit zur ¨
Uberwindung von Heterogenit¨
at, ist die Standardisierung des Austauschs
von Informationen zwischen unterschiedlichen Unternehmen. W¨
ahrend die Lebenszeit eines In-
formationssystems nur wenige Jahre betragen kann, m¨
ussen Produktdaten oftmals bis zu mehre-
re Jahrzehnte aufbewahrt werden [Tho09]. Folglich ist es sinnvoll, nachhaltige Standards zu ent-
wickeln, die diesen Anforderungen gerecht werden. Im Umfeld der Produktentwicklung existiert
eine Vielzahl solcher Standards, die unterschiedliche Phasen im Entwicklungsprozess abdecken.
Dabei lassen sich Standards in verschiedene Kategorien einteilen [SRF`05, RSB`08].
Abbildung 4.14 zeigt eine schematische ¨
Ubersicht der Zusammenh¨
ange der verschiedenen Stan-
dards. Mit Hilfe von Informationsmodellstandards l¨
asst sich Wissen konzeptualisieren, d.h. Kon-
zepte der Realwelt m¨
ussen mit Hilfe von Artefakten abstrahiert und beschrieben werden. Weiter
existieren Inhaltsstandards, die Schemakonzepte f¨
ur verschiedene Anwendungsbereiche spezifizie-
ren. F¨
ur die Produktentwicklung etwa sind STEP, SysML und AUTOSAR zu nennen. W¨
ahrend
STEP versucht, alle Bereiche der Produktentwicklung zu unterst¨
utzen, fokussieren SysML2und
AUTOSAR auf der Modellierung von Systemen und Komponenten eines Produktes. Modellin-
stanzen dieser Inhaltsstandards k¨
onnen mittels verschiedener Informationsaustauschstandards
ausgetauscht werden. Erw¨
ahnenswert sind z.B. EDI,XML, SOAP und RDF. Im Folgenden wer-
den die wichtigsten Inhaltsstandards f¨
ur Produktdaten erl¨
autert und die mit ihnen einhergehen-
den Herausforderungen diskutiert. Schließlich erfolgt der Abgleich mit den Anforderungen aus
Abschnitt 3.3.
4.2.1. Informationsmodellstandards
Informationsmodelle lassen sich mit Hilfe unterschiedlicher Standards modellieren. Zu den am
weitesten verbreiteten Standards z¨
ahlen die Unified Modeling Language (UML), das relationale
Datenmodell, die Ontology Web Language (OWL) und, im Zusammenhang mit Produktdaten
zu nennen, EXPRESS. Die verschiedenen Standards unterscheiden sich aufgrund der verschie-
denen Anwendungsdom¨
anen in ihrer Methodik und Ausdrucksm¨
achtigkeit. W¨
ahrend die UML
eine grafische Sprache zur Modellierung unterschiedlicher Aspekte von Softwarekomponenten
und -systemen ist, dient OWL zur Beschreibung semantischer Wissensnetze und bietet, ¨
uber
die Modellierung hinaus, die M¨
oglichkeit Schlussfolgerungen (engl. Inferences) aus bestehendem
Wissen mit Hilfe von Algorithmen abzuleiten. EXPRESS ist eigens f¨
ur die ISO 103033entwickelt
2Systems Modeling Language ist eine auf UML 2 basierende Modellierungssprache f¨
ur das Systems Engineering.
3ISO Normreihe 10303 ”Industrial automation systems and integration - Product data representation and ex-
change“
78
4.2. Standards
,QIRUPDWLRQVDXVWDXVFK
,QIRUPDWLRQVPRGHOO
,QKDOW
3URGXNWGDWHQ
Qualität
Konfiguration
67(3 6\V0/ (/2* -7 $XWRVDU
;0/
6FKHPD 80/ (;35(66 2:/ 3/0;0/
;0/ (', 62$3 5') 26/&
Abbildung 4.14.: Inhaltsstandards im Produktlebenszyklus
worden, um eine einheitliche und systemunabh¨
angige Beschreibungssprache f¨
ur Produktdaten-
konzepte zu bieten. Neben der Beschreibung der Struktur sog. Entit¨
aten (entities) mit Attributen
(attributes) lassen sich komplexe Schreibregeln mit Hilfe arithmetischer, logischer und numeri-
scher Funktionen und Operatoren definieren. Eine logisch komplette Einheit an Entit¨
aten wird
als Schema (schema) bezeichnet.
4.2.2. Inhaltsaustauschstandards
F¨
ur den Austausch sowohl von Datenmodellen als auch deren Instanzen existiert eine Vielzahl
an Standards. Zu ihnen z¨
ahlen EDI (electronic data interchange) und XML (extensible markup
language). EDI fasst unterschiedliche elektronische Transferverfahren (z.B. ebXML, VDA re-
commendations) zusammen, die auf XML-Schema basieren. In der Vergangenheit gab es weitere
Initiativen, wie etwa STEPml4oder auch das XML-basiertes Austauschformat f¨
ur Produktdaten
PDML (Product Data Markup Langauge), welche beide ebenfalls auf XML basieren. In den letz-
ten Jahren kommt vermehrt PLM XML5zum Einsatz, ein Standard der die Beschreibung von
Produktstrukturen durch XML erm¨
oglicht.
4.2.3. Inhaltsstandards
Die Internationale Organisation f¨
ur Normung (ISO) besitzt ein eigenes technisches Komitee
(engl. Technical Committee, TC), das f¨
ur die Automatisierung und Integration von Systemen
zust¨
andig ist. Dieses TC und im Speziellen das Subkomitee 4 sind f¨
ur den Entwurf und die
4A library of XML specifications
5PLM XML ist kein internationaler Standard, sondern ein Format der Siemens PLM Software
79
4. Stand der Technik
Aktualisierung einer Vielzahl technischer Standards und Verfahrensstandards f¨
ur industrielle
Daten verantwortlich. Zu den wichtigsten Standards f¨
ur den Austausch und die Integration von
Produktdaten z¨
ahlen ISO 8000: Data Quality,ISO 10303: Standard for the Exchange of Product
Model Data (STEP), und ISO 18876: Integration of Industrial Data for Exchange, Access, and
Sharing (IIDEAS).
Die Ziele dieser Standards sind in allen F¨
allen ¨
ahnlich: Viele OEMs und Zulieferer verwenden un-
terschiedliche Informationssysteme (z.B. CAD- oder PDM-Systeme) basierend auf unterschied-
lichen Datenmodellstrukturen. Dadurch ist der Austausch von Informationen zwischen OEMs
und Zulieferern nicht ohne Weiteres m¨
oglich, und es k¨
onnen unterschiedliche Probleme auftre-
ten. Hier muss zwischen Datenaustauschproblemen (z.B. Fl¨
achen und Linien treffen sich nicht)
und Datenqualit¨
atsproblemen (z.B. doppelte Eintr¨
age) unterschieden werden.
Um diese Probleme zu adressieren, begann Mitte der 80er Jahre die Arbeit an der ISO Norm-
reihe 10303 ”Industrial automation systems and integration - Product data representation and
exchange“, informell auch als ”Standard for the Exchange of Product Data (STEP)“ bekannt.
W¨
ahrend ISO 10303 verschiedene Standards f¨
ur den Austausch von Produktdaten umfasst, wer-
den in den ISO 8000 Standards verschiedene Kriterien f¨
ur die Qualit¨
at von Daten definiert.
Eng verbunden mit letzterem ist die Normreihe ISO 22745, die eine zentrale Registry f¨
ur die
eindeutige Identifikation von Personen, Organisationen, Orten, Produkten, Services, Prozessen,
Regeln und Regularien beschreibt.
Die diversen Standards haben unterschiedliche Annahmen und Ziele und lassen sich daher nur
schwer in Einklang bringen. Dieses Problem kann aus ¨
okonomischen Gesichtspunkten nicht durch
eine zentrale Stelle oder Organisation gel¨
ost werden, vielmehr ist ein offener partizipativer Pro-
zess notwendig [SRF`05].
Im Folgenden werden technische Standards von ISO 10303 sowie der Verfahrensstandard ISO
8000 n¨
aher beleuchtet. Dar¨
uber hinaus werden noch weitere Standards nationaler Verb¨
ande
betrachtet und mit den Anforderungen aus Abschnitt 3.3 abgeglichen.
ISO 10303: Standard for the Exchange of Product Model Data (STEP)
STEP ist eine modulare ISO Normreihe mit dem Ziel, den Austausch von durch Computer-
interpretierbaren Produktinformationen ¨
uber den gesamten Lebenszyklus eines Produktes hin-
weg zu erm¨
oglichen. Hauptaugenmerk w¨
ahrend der Entwicklung des Standards war es vor allem,
den Austausch geometrischer Modelle zwischen Herstellern und Zulieferern zu erm¨
oglichen. Da-
bei stand die ¨
Ubertragung von Volumenmodellen, die auch f¨
ur den Aufbau digitaler Prototypen
(Digital Mockup) eine wichtige Voraussetzung sind, im Vordergrund [XN09].
Kern der ISO Normreihe sind sog. Application Protocols (AP), die komplexe Datenmodelle f¨
ur
spezifische Produktdatenanwendungen darstellen. In Abbildung 4.15 ist die Architektur von
STEP dargestellt. Application Protocols k¨
onnen sich aus verschiedenen Application Modules
(AMs) zusammensetzen, die verschiedene wiederverwendbare Entit¨
aten enthalten. Grundlage
f¨
ur diese Module bilden die gemeinsamen Ressourcen, die auch als integriertes Produktmodell
bezeichnet werden [AT00]. Dieses setzt sich aus den anwendungsunabh¨
angigen Produktmerkma-
len, etwa dem Geometriemodell, der Produktstruktur oder dem Pr¨
asentationsmodell sowie den
anwendungsabh¨
angigen Elementen, etwa Konstruktion oder Finite Element Analyse, zusammen.
Erstere werden als Integrated Generic Resources, letztere als Integrated Application Resources
bezeichnet. Schließlich existieren Application Interpreted Constructs, die Spezifalisierungen der
vorherigen beiden Gruppen darstellen und in mehreren Application Protocols wiederverwendbar
80
4.2. Standards
sind. Die Beschreibung aller Ressourcen, Konstrukte und Protokolle basiert auf der Informations-
modellierungssprache EXPRESS, die teilweise grafisch durch EXPRESS-G dargestellt werden
kann. Die Implementierung kann durch unterschiedliche Methoden erfolgen. Bspw. existieren
Abbildungen auf verschiedene Programmiersprachen (z.B. C, C++ und Java) ebenso besteht
die M¨
oglichkeit der Ausgabe als Text- oder XML-Datei.
Der Prozess zur Erstellung und Genehmigung eines neuen AP ist komplex und durchl¨
auft meh-
rere Phasen, in denen verschiedene Modelle entstehen [XN09]: Zun¨
achst wird ein Application
Activity Model (AAM) erstellt, das alle Aktivit¨
aten und Daten߬
usse f¨
ur ein zu erstellendes
Application Protocol enth¨
alt. Es dient als Diskussionsgrundlage nachfolgender Verfeinerungs-
runden. Auf Basis dieses Modells wir das sog. Application Reference Model (ARM) erstellt,
das alle Daten enth¨
alt, die f¨
ur eine spezifische Anwendungsdom¨
ane ben¨
otigt werden. Das ARM
wird in der eigens f¨
ur STEP entwickelten Datenmodellierungssprache EXPRESS spezifiziert, da-
mit dieses von Anwendern der Zieldom¨
ane verstanden werden k¨
onnen. Zus¨
atzlich existiert die
grafische Modellierung EXPRESS-G, die jedoch nicht die komplette Ausdrucksm¨
achtigkeit von
EXPRESS besitzt. 6Schließlich wird dieses Modell von einem STEP-Experten mit Hilfe gemein-
samer integrierter Ressourcen der STEP-Spezifikationen (engl. generic integrated resources) auf
ein Application Interpreted Model (AIM) abgebildet.
Um STEP zu modularisieren, wurden ¨
uber die Zeit unterschiedliche Konstrukte eingef¨
uhrt:
Zun¨
achst wurden Unit of Functionality und Application Interpreted Constructs (AICs) ein-
gef¨
uhrt. Diese wurden im Laufe der Zeit durch sog. Application Modules (AM) ersetzt. Letztere
stellen im Prinzip kleine Application Protocols dar, die wiederverwendet werden k¨
onnen und
besitzen wie Applications Protocols interpretierte Modelle, die als Module Interpreted Model
bezeichnet werden. Application Modules wiederum k¨
onnen weitere Applications Modules refe-
renzieren und somit komplexe Datenmodelle aufbauen. Seit der Initiierung von STEP sind eine
Vielzahl von Application Protocols f¨
ur unterschiedliche Dom¨
anen entstanden.
Zu den wichtigsten Application Protocols (APs) der Automobilindustrie z¨
ahlen:
•AP 203: Configuration controlled 3D design of mechanical parts and assemblies,
•AP 204: Mechanical design using boundary representation,
•AP 210: Electronic assembly, interconnect, and packaging design,
•AP 212: Electrotechnical design and installation,
•AP 214: Core data for automotive mechanical design processes,
•AP 242: Managed model based 3D engineering, wurden 2014 die beiden APs 203 und 214
zusammengef¨
uhrt.
”Wichtigster Themenbereich in AP 214 ist seit der Initiierung die Produktstruktur und hierbei
insbesondere die Handhabung der komplexen Variantenvielfalt, die im Automobilbau besonders
ausgepr¨
agt ist. Dies beinhaltet Themen des Produktdatenmanagements wie Spezifikation, Konfi-
guration, Klassifikation und G¨
ultigkeit, bezieht sich aber auch auf Geometrien und Konstrukti-
onselemente sowie deren graphische Darstellung” [AT00].
6EXPRESS bietet neben der Modellierung von Entit¨
aten, Attributen und Beziehungen auch die M¨
oglichkeit
komplexe Integrit¨
atsbedingungen zu definieren.
81
4. Stand der Technik
,QWHJUDWHG3URGXFW0RGHO
$SSOLFDWLRQ3URWRFROV
,QWHJUDWHG*HQHULF5HVRXUFHV
'HVFULSWLRQ
0HWKRGV
$3 $3$3 $3$3
,*5
'0
(;35(66
$SSOLFDWLRQ0RGXOHV
$0
3URGXFW
LGHQWLILFDWLRQ
$0
3URGXFW
YHUVLRQ
$0
3URGXFW
YHUVLRQ
$0«
,QWHJUDWHG$SSOLFDWLRQ
5HVRXUFHV
'0;;
(;35(66
* ,*5
,*5
,*5
,$5
,$5
,PSOHPHQWDWLRQ0HWKRGV
,0
;0/
,0
-DYD
,0
6'$,
,0
&
,0
7;7
$SSOLFDWLRQLQWHUSUHWHGFRQVWUXFWV
Abbildung 4.15.: . In Anlehnung an STEP on a Page https://web.archive.org/web/
20161221123916/http://www.mel.nist.gov/sc5/soap/soapgrf030407.pdf
(abgerufen am 19.11.2017)
In Abbildung 4.16 sind die wesentlichen Entit¨
aten der oben genannten Application Proto-
cols zur Repr¨
asentation von Produktdaten und dessen Konfiguration illustriert. An den ein-
zelnen Entit¨
aten sind jeweils die entsprechenden Application Modules dokumentiert. Appli-
cation Modules enthalten Entit¨
aten (inklusive Attributen), von denen mehr als 900 in STEP
spezifiziert sind. Der ¨
Ubersicht halber sind die Entit¨
aten als UML-Klassendiagramm anstelle
von EXPRESS dargestellt. Zentrale Entit¨
at ist das Product, welches sowohl ein Bauteil als
auch ein Dokument beschreiben kann. Jedes Produkt ist Teil eines Produktkontextes (z.B.
”mechanisch“). Variantenbeziehungen zwischen Produkten werden mittels der Entit¨
at alterna-
te product relationship hergestellt. Unterschiedliche Versionen eines Produktes werden in sog.
product definition formation abgelegt. Dar¨
uber hinaus k¨
onnen auf einzelne Produktversionen
von diesen Sichten (product definition) gebildet werden und Produkte unterschiedlichen Katego-
rien (z.B. Bauteil, Zusammenbau, Detail oder Standard) zugeordnet werden (product related pro-
duct category). STEP definiert auch die M¨
oglichkeit explizite Konfigurationen zu definieren. Dazu
fasst ein product concept mehrere configuration items zusammen, dessen Auspr¨
agungen Referen-
zen auf Produktversionen sind (configuration design).
Das integrierte Produktmodell aus Abbildung 4.16 soll als Integrationsplattform f¨
ur Informa-
tionssysteme dienen, die entlang der verschiedenen Phasen der Produktentwicklung eingesetzt
werden. Dadurch sollen alle Produktdaten abgebildet und maschinenverarbeitbar sein, wodurch
ein ”durchg¨
angiger Informationsfluss“ entsteht [AT00]. Beim integrierten Produktmodell han-
delt es sich um eine allgemeing¨
ultige, abstrakte Beschreibung von Produktdaten f¨
ur einzelne
82
4.2. Standards
LG
QDPH
GHVFULSWLRQ
3URGXFW
AM 1017
3DUW
AM 1022 'RFXPHQW
AM 1121
LG
GHVFULSWLRQ
3URGXFWBYHUVLRQ
AM 1018
RIBSURGXFW
UHODWLRQBW\SH
GHVFULSWLRQ
3URGXFWBYHUVLRQ
BUHODWLRQVKLS
AM 1020
UHODWLQJBYHUVLRQ
UHODWHGBYHUVLRQ
3DUWBYHUVLRQ
AM 1022 'RFXPHQWBYHUVLRQ
AM 1121
3DUWBYLHZB
GH¿QLWLRQ
AM 1023 GHILQHGBYHUVLRQ
$OWHUQDWHBSDUWB
UHODWLRQVKLS
AM 1134
EDVHBSURGXFW
DOWHUQDWHBSURGXFW
RIBSURGXFW RIBSURGXFW
,WHPBGHVLJQB
DVVRFLDWLRQ
AM 1056
GHVLJQ
GHVLJQ
LG
QDPH
GHVFULSWLRQ
3URGXFWB
FRQ¿JXUDWLRQ
AM 1056
FRQILJXUDWLRQ
LG
QDPH
GHVFULSWLRQ
WDUJHWBPDUNHW
3URGXFWB
FRQFHSW
AM 1060 LWHPBFRQWH[W
3URGXFWB
FRQ¿JXUDWLRQB
UHODWLRQVKLS
AM 1056
3URGXFWB
FRQ¿JXUDWLRQB
KLHUDUFKLFDOB
UHODWLRQVKLS
AM 1056
3URGXFWB
FRQ¿JXUDWLRQB
UHYLVLRQB
VHTXHQFH
AM 1056
SDUHQW
FKLOG
SUHGHFHVVRU
VXFFHVVRU
Abbildung 4.16.: Ausschnitt von STEP-Entit¨
aten verschiedener Application Modules
Dom¨
anen (z.B. Automobil- oder Elektroindustrie) erfolgt auf Basis dieser eine Spezialisierung
des Modells.
Neben dem integrierten Produktmodell existiert das STEP PDM Schema [UB02], welches diejeni-
gen Entit¨
aten aus den STEP-Ressourcen enth¨
alt, die f¨
ur das Produktdatenmanagement notwen-
dig sind. Hierbei handelt es sich nicht um einen offiziellen Standard, sondern um eine Initiative
der ProSTEP iViP7und PDES8, um Interoperabilit¨
at zwischen den verschiedenen Application
Protocols zu erm¨
oglichen. Zu den Hauptfunktionalit¨
aten des Schemas z¨
ahlen die Identifikation,
Versionierung, Klassifikation und Strukturierung sowie Eigenschaften von Bauteilen, Projekt-
management und ¨
Anderungsprozesse.
7ProSTEP iViP ist ein Verein von Mitgliedern aus Industrie und Forschung, der Anforderungen von OEMs und
Zulieferern f¨
ur die Produktentwicklung und -fertigung formuliert und Standards definiert.
8PDES, Inc. ist ein internationales Konsortium, das die Entwicklung und Implementierung von Standards f¨
ur
den Austausch von Produktdaten forciert.
83
4. Stand der Technik
ISO 18876: Integration of Industrial Data for Exchange, Access, and Sharing (IIDEAS)
Parallel zu STEP ist ein weiterer ISO Standard entstanden, der ¨
ahnliche Ziele verfolgt, jedoch
einen breiteren Fokus einnimmt und sich nicht auf Produktdaten beschr¨
ankt. Im Mittelpunkt
steht das Teilen und Integrieren von Daten anstelle ihres Austausches, wie er bei STEP ange-
strebt wird. Im Zuge der Entwicklung von ISO 18876 wurde erkannt, dass es f¨
ur die Integration
von Daten notwendig ist, die Identit¨
at zusammengeh¨
origer Daten aus heterogenen Quellen zu
bestimmen [Wes96]. D.h., bei der Integration sollen diejenigen Teile identifiziert werden, welche
das selbe Realweltobjekt repr¨
asentieren.
Der ISO-Standard 18876 definiert sowohl eine Architektur als auch eine Methodik, um Daten aus
unterschiedlichen Quellen zu integrieren [ISO03b, ISO03c]. Letztere k¨
onnen durch unterschied-
liche Modelle beschrieben und durch heterogene Modellierungssprachen realisiert sein. Dar¨
uber
hinaus sollen Konflikte zwischen Modellen aufgel¨
ost und Daten, die unterschiedliche kodiert sind,
transformiert werden.
Architektur. Die Integration von Datenquellen erfolgt durch sog. Integrationsmodelle,diewie-
derum mit anderen Datenmodellen zu neuen Integrationsmodellen integriert werden k¨
onnen. Ein
Datenmodell kann in eines oder mehrere Integrationsmodellen integriert werden. Die Kodierung
von Daten und Modellen kann wiederum durch unterschiedliche Formate (z.B. SGML, XML,
UML und EXPRESS) geschehen.
Ein Integrationsmodell setzt sich aus primitiven und abgeleiteten Konzepten zusammen. Erstere
umfassen Foundation Concepts,General Concepts und Specific Concepts. Beispiele f¨
ur Founda-
tions Concepts sind Klassifikation, Beziehungen und Komposition. Zu den General Concepts
z¨
ahlen u.a. physikalische Konzepte. Specific Concepts schließlich beziehen sich auf einen einge-
schr¨
ankten Anwendungsbereich (z.B. Automobilindustrie).
Die Integration von Datenmodellen erfolgt durch die Definition von Abbildungen (Mappings).
Diese spezifizieren die Transformationen, um Instanzen eines Modells in einem anderen Modell
repr¨
asentieren zu k¨
onnen. Dabei werden bestimmte Annahmen getroffen, etwa das Mappings
auf Transformationen der Struktur, Terminologie und Kodierung der Datenmodelle beschr¨
ankt
sind. Transformationen sind immer bidirektional, was jedoch bedeutet, dass die Transformati-
onsrichtungen separat definiert werden m¨
ussen.
Ziel des Integrationsprozesses ist es, die selben Informationen eines Daten- oder Integrationmo-
dells mit Hilfe von Transformationen darzustellen, ohne dass bei der Integration die Semantik
verloren geht. Als Ergebnis dieses Prozesses resultieren Abbildungen zwischen Datenmodellen
von Informationssystemen und Teilmengen des Integrationsmodells. Gegebenenfalls muss letz-
teres im Zuge der Integration erweitert werden, so dass dieses die Schemakonzepte der Daten-
modelle pr¨
azise ausdr¨
ucken kann.
Der Integrationsprozess l¨
asst sich in drei unterschiedliche Szenarien einteilen. Im ersten Sze-
nario existieren vor Start des Integrationsprozesses sowohl das Integrationsmodell als auch die
Datenmodelle der zu integrierenden Informationssysteme. Im zweiten Szenario existieren zwar
die Datenmodelle der zu integrierenden Informationssysteme, jedoch noch kein Integrationsmo-
dell. Im dritten Szenario existiert das Integrationsmodell, jedoch noch keine Datenmodelle der
zu integrierenden Informationssysteme, d.h. lediglich die Anforderungen an diese Datenmodelle
liegen vor.
Im Folgenden wird lediglich das erste Szenario beschrieben, da dieses die anderen Szenarien mit
abdeckt. Zun¨
achst werden das Datenmodell eines zu integrierenden Informationssystems analy-
84
4.2. Standards
siert und ¨
aquivalente Schemakonzepte aus dem Integrationsmodell identifiziert. Gegebenenfalls
muss das Integrationsmodell erweitert werden, falls nicht alle Schemakonzepte des zu integrie-
renden Datenmodells abgebildet werden k¨
onnen. Anschließend wird die Teilmenge des Inte-
grationsmodells ermittelt, welche die Konzepte des zu integrierenden Datenmodells beschreibt.
Da Datenmodelle immer in dem Anwendungskontext betrachtet werden m¨
ussen, f¨
ur den sie
erstellt wurden, muss dieser, so fern nicht explizit im Modell vorhanden, bei der Integrati-
on ber¨
ucksichtigt werden und ggf. in die Mappingspezifikation mit aufgenommen werden. Als
Beispiel kann etwa das Informationssystem E-PDM aus Abschnitt 3.2.1 betrachtet werden. Das
Schemakonzept Komponente beschreibt implizit, dass es sich im Kontext von E-PDM um elektri-
sche Komponenten handelt. Dieses wird jedoch nicht aus der Bezeichnung ersichtlich und sollte
im Zuge einer Integration explizit in einer Mappingspezifikation dokumentiert werden.
Nun werden f¨
ur beide Integrationsrichtungen strukturelle und terminologische Transformationen
zwischen Datenmodell und Integrationsmodell definiert. Sollten beide unterschiedlich kodiert
sein, muss zwischen beiden Sprachen ebenfalls eine Transformation definiert sein. Diese Schritte
werden solange wiederholt, bis alle zu integrierenden Informationssysteme abgebildet sind.
Abbildung 4.17 illustriert die ISO 18876 Architektur. Sowohl das Integrationsmodel, die Mapping-
Spezifikationen sowie die Informationssysteme besitzen Schemakonzepte und Instanzen, die in
Schemata definiert sind. Diese k¨
onnen in verschiedenen Informationsmodellen (z.B. UML, XML-
Schema, relationales Datenmodell) spezifiziert sein. Das Integrationsmodell kann entweder ein
Modell mit unterschiedlichen Abstraktionsstrufen oder Hierarchien sein, oder es existieren meh-
rere Integrationsmodelle, die integriert werden. F¨
ur jedes zu integrierende Informationssystem
ist genau eine Mapping-Spezifikation definiert, die einen Ausschnitt des Integration Model refe-
renziert. Neben strukturellen Transformationen f¨
ur die Abbildung von Schemakonzepten sowie
terminologischen Transformationen f¨
ur die Abbildung von Instanzen, k¨
onnen Einschr¨
ankungen
(engl. Constraints) definiert werden. Diese werden dann erforderlich, wenn Informationssysteme,
die integriert werden sollen, zueinander in Konflikt stehende Einschr¨
ankungen besitzen. Dann
wird es notwendig, dass Konzepte im Integrationsmodell allgemeiner definiert werden als in den
zu integrierenden Modellen.
,QIRUPDWLRQV\VWHP0DSSLQJ
6SHFLILFDWLRQ
,QWHJUDWLRQ0RGHO 0DSSLQJ
6SHFLILFDWLRQ
,QIRUPDWLRQV\VWHP
,QIRUPDWLRQPRGHO
6FKHPD
6FKHPD
NRQ]HSWH
,QVWDQ]HQ
,QIRUPDWLRQPRGHO ,QIRUPDWLRQPRGHO
6FKHPD
6FKHPD
NRQFHSWH
,QVWDQ]HQ
6WUXNWXU
7UDQVIRUPDWLRQHQ
7HUPLQRORJLVFKH
7UDQVIRUPDWLRQHQ
,QWHJUDWLRQ0RGHO
7HLOPHQJH
&RQVWUDLQWV
Abbildung 4.17.: In Anlehnung an [ISO03b]
F¨
ur die Konsolidierung von Instanzen muss eine gemeinsame, zuverl¨
assige und dauerhafte Iden-
tifikation zusammengeh¨
origer Instanzen vorhanden sein. Sollten bestehende Identifikationsmerk-
male wiederverwendet werden k¨
onnen, m¨
ussen keine zus¨
atzlichen Attribute im Integrationsmo-
dell spezifiziert werden.
85
4. Stand der Technik
Methodik. Die Methodik beschreibt wie Integrationsmodelle erstellt, erweitert und aktualisiert
werden. Dabei werden unterschiedliche Szenarien unterst¨
utzt, etwa die initiale Integration von
zwei oder mehreren Informationssystemen in ein neues Integrationsmodell. Im Folgenden werden
die verschiedenen Phasen der Methodik kurz erl¨
autert.
Die erste Phase definiert die Analyse der Informationssysteme und die damit verbundene Er-
stellung des Integrationsmodells. Zun¨
achst muss der Kontext des Informationsmodells festgelegt
werden. Steht mehr als ein Integrationsmodell zur Auswahl, so wird jenes gew¨
ahlt, das die gr¨
oßte
¨
Uberdeckung mit den zu integrierenden Informationssystemen hat. Anschließend werden die
Konzepte der Informationssysteme untersucht und Beziehungen zu Konzepten im Integrations-
modell bestimmt. Hier unterscheidet die Methodik zwischen Synonymen, Homonymen, Identit¨
at,
Kompatibilit¨
at, Inkompatibilit¨
at, Komplexit¨
at und Partitionierung.
In der zweiten Phase geht es um die Erweiterung eines Integrationsmodells f¨
ur den Fall dass
w¨
ahrend der Analysephase Konzepte identifiziert worden sind, f¨
ur die keine Entsprechung im
Integrationsmodell gefunden werden kann. Dazu m¨
ussen dem Integrationsmodell neue Kon-
zepte hinzugef¨
ugt werden, ohne aber bestehende Konzepte zu ¨
andern. Sollte es nicht m¨
oglich
sein, ¨
Anderungen am Integrationsmodell durchzuf¨
uhren, welche eine Integration neuer Konzep-
te erm¨
oglicht, muss ein neues Integrationsmodell erstellt werden. In diesem Fall wird das alte
Integrationsmodell zu einem Integrationsmodell, welches ebenfalls in das neue Modell integriert
werden muss.
Die n¨
achsten beiden Phase beschreibt die Auswahl derjenigen Teilmenge an Konzepten aus
dem Integrationsmodell, welche die Abbildung eines Informationssystems erm¨
oglichen sowie die
Integration beider. Damit sind das Modell des zu integrierenden Informationssystems sowie
die Teilmenge aus dem Integrationsmodell semantisch ¨
aquivalent. Da beide sich in Struktur
und Terminologie unterscheiden, m¨
ussen diese Unterschiede durch Transformationen aufgel¨
ost
werden.
4.2.4. Standards f¨ur das Konfigurationsmanagement
Wie in Abschnitt 2.2.3 erl¨
autert, ist das Konfigurationsmanagement einer der wichtigsten Teil-
bereiche der Produktentwicklung. Im seinem Kontext existieren unterschiedliche Standards und
Richtlinien f¨
ur die Erstellung und Pflege von Konfigurationen. Zu den verbreitetsten z¨
ahlen der
ANSI Standard EIA-649[EIA98]9sowie der ISO Standard ISO 10007 10 [ISO03a].
”Configuration management (CM): A management process for establishing and maintaining
consistency of a product’s performance, functional, and physical attributes with its requirements,
design and operational information throughout its life.“ [EIA98]
”Configuration management documents the product’s configuration“ ”Product configuration in-
formation: requirements for product design, realization, verification, operation and support“ ISO
10007
EIA-649 definiert grundlegende Begriffe und Aktivit¨
aten des Konfigurationsmanagements und
liefert dazu 50 Prinzipien. Das Konfigurationsmanagement umfasst folgenden Prozessen:
•Konfigurations- und Planungsmanagement: Definition des Geltungsbereiches, Inte-
gration in Unternehmensprozesse.
9National Consensus Standard for Configuration Management
10Quality management systems – Guidelines for configuration management
86
4.2. Standards
•Konfigurationsidentifikation: Definition der Produktstruktur und -attribute, Vergabe
eindeutiger Bauteilnummern und Etablierung eines Releaseprozesses.
•Konfigurations¨
anderungsmanagement: Identifikation von variablen Anteilen sowie
die Dokumentation aller ¨
Anderungen.
•Konfigurationsstatuskontrolle: Realisierung von Informationssystemen, Erfassung al-
ler relevanten Konfigurationsmanagementinformationen.
•Konfigurationsverifikation und -pr¨
ufung: Sicherstellung der Konsistenz von Release-
informationen, ¨
Uberpr¨
ufung der Leistungserf¨
ullung.
•Konfigurationsmanagement f¨
ur digitale Daten: Anweisungen f¨
ur die IT-Unterst¨
ut-
zung des Konfigurationsmanagement.
Die Inhalte von EIA 649 und ISO 10007 decken sich in großen Teilen, lediglich der Prozess
Konfigurationmanagement f¨
ur digitale Daten wird im ISO-Standard nicht erw¨
ahnt.
4.2.5. Qualit¨atsstandards
Auch bzgl. Datenqualit¨
at existieren verschiedene Standards, der verbreitete ISO Standard ISO
9001 [ISO08], der die Anforderungen an Qualit¨
atsmanagementsysteme definiert. Mit ISO 8000
[Ben09] ist ein Standard entstanden, der sich mit der Qualit¨
at von Daten im Speziellen besch¨
aftigt.
Dazu werden neben unterschiedlichen Rollen f¨
ur das Qualit¨
atsmanage-ment von Daten auch ver-
schiedene Prozesse beschrieben.
ISO 8000: Data Quality
Bei ISO 8000 handelt es sich um eine Normreihe von Standards zur generellen Datenqualit¨
at
bzw. zur Qualit¨
at von Masterdaten. Unter Masterdaten werden zentrale Gesch¨
aftsobjekte (etwa
Kunden-, Mitarbeiter-, Zulieferer- oder Produktdaten) verstanden, die durch eine Vielzahl von
Informationssystemen innerhalb eines Unternehmens verwendet werden [Los09]. Neben grund-
legenden Informationen zur Qualit¨
at von Daten wird in ISO 8000 ein Rahmenwerk beschrieben,
welches das Management von Datenqualit¨
at erlaubt.
Unter Datenqualit¨
at wird im Standard die Definition der ISO 9000 referenziert: ”Degree to
which a set of inherent characteristics fulfils requirements“. Die erste Normreihe (Teile 0 bis 99)
von ISO 8000 beschreibt die grundlegende Terminologie f¨
ur Datenqualit¨
at. Die zweite Norm-
reihe (Teile 100 bis 199) besch¨
aftigt sich mit der Qualit¨
at von Masterdaten. Darunter fallen
alle Informationen, Unternehmensunabh¨
angig und fundamental f¨
ur das operative Gesch¨
aft sind.
Dazu z¨
ahlen Informationen zu einzelnen Personen, Organisationen, Standorten, Waren, Services
und Regularien. Um eine einheitliche Semantik sowie zentrale Beschreibung von Konzepten
zu erm¨
oglichen wird, mit der ISO Normreihe 22745 ein zentrales technisches Verzeichnis als
Grundlage f¨
ur das Datenqualit¨
atsmanagement vorausgesetzt. Mit Hilfe eines solchen Verzeich-
nisses lassen sich Konzepte eindeutig beschreiben und identifizieren. Des weiteren werden in der
Normreihe charakteristische Eigenschaften f¨
ur Datenqualit¨
at beschrieben. Dazu z¨
ahlen die Da-
tenherkunft (Provenance), die Vollst¨
andigkeit (Completeness) sowie die Genauigkeit (Accuracy)
von Masterdaten.
87
4. Stand der Technik
Rahmenwerk. Neben grundlegenden Definitionen beschreibt die Normreihe ein Rahmenwerk
f¨
ur das Management von Datenqualit¨
at. Dieses umfasst drei Rollen und drei Prozesse (sie-
he Abbildung 4.18). Zu den Rollen z¨
ahlen der Data Manager,Data Administrator und Data
Technician. Diese f¨
uhren unterschiedliche Aktivit¨
aten in den Prozessen Data Operations,Data
Quality Monitoring und Data Quality Improvement aus.
Abbildung 4.18.: ISO 8000-150 Data Quality Management Framework
Der Prozesse Data Operations betrachtet Faktoren, welche die Datennutzung und die Daten-
qualit¨
at direkt betreffen:
•Data Architecture Management ist f¨
ur die strategische, unternehmensweite Planung der
Datenqualit¨
at verantwortlich. Zu den Aktivit¨
aten z¨
ahlt die Verwaltung unternehmens-
weiter Datenmodelle, Standards und Schnittstellen sowie deren Koordination zwischen
unterschiedlichen Informationssystemen.
•Data Design verwaltet Datenstandards und Definitionen, Datenbank-/Systemimplemen-
tierungen und deren Konfiguration. Zu den Aufgaben z¨
ahlen die Entwicklung logischer
und physischer Datenmodelle, ebenso wie die Etablierung von Standards und Regeln auf
Betriebsebene. Datenadministratoren m¨
ussen sensibel f¨
ur Anforderungen aus dem Data
Architecture Management sein sowie einen Austausch mit anderen Abteilungen pflegen,
um auf ¨
Anderungen der Anforderungen reagieren und Systemkonfigurationen anpassen zu
k¨
onnen.
•Data Processing ist der Prozess auf operativer Ebene, der f¨
ur die Erzeugung sowie Ak-
tualisierung von Daten verantwortlich ist. Zu den Aufgaben z¨
ahlt die ¨
Uberwachung des
Datenerstellungs- und Daten¨
anderungsprozesses, sowie die Protokollierung verschiedener
Parameter (z.B. Datennutzung, ¨
Anderungen).
Der zweite Prozess Data Quality Monitoring beurteilt, inwieweit bestimmte Stufen der Daten-
qualit¨
at im Unternehmen erreicht werden. Vor der Aktivit¨
at Data Quality Planning werden die
Ziele des Datenqualit¨
atsmanagement fixiert, die wiederum an den Unternehmenszielen ausge-
richtet sein m¨
ussen. Im Data Quality Criteria Setup werden Methoden und Maße festgelegt,
um Datenqualit¨
atbestimmenzuk
¨
onnen. Im Data Quality Measurement wiederum werden die-
se Methoden verwendet, um die aktuelle Datenqualit¨
at im Unternehmen verschiedenen Stufen
zuzuordnen.
88
4.2. Standards
Der letzte Prozess Data Quality Improvement korrigiert gefundene Datenfehler und beseitigt
die Gr¨
unde f¨
ur diese. Im Data Stewardship and Flow Management werden Daten߬
usse und
Verantwortlichkeiten analysiert und Datenoperationen verwaltet. In der Aktivit¨
at Data Error
Cause Analysis werden die Gr¨
unde f¨
ur Fehler analysiert, um diese nachhaltig zu eliminieren.
Schließlich werden im Data Error Correction Daten korrigiert, die nicht vorgegebenen Standards
und Kriterien entsprechen.
SASIG - Product Data Quality for the Global Automotive Industry
Auf im Umfeld der Produktentwicklung in der Automobilindustrie hat sich eine Reihe von Stan-
dards und Richtlinien f¨
ur die Qualit¨
at von Produktdaten etabliert. In den meisten F¨
allen han-
delt es sich um Vorgaben f¨
ur den Austausch von Geometrien zwischen Herstellern und Liefe-
ranten. [SAS05] stellt Richtlinien f¨
ur die Qualit¨
at von Produktdaten zusammen, die sich auf
CAD-Aspekte beschr¨
anken. Zun¨
achst werden die Begriffe ”Produktdaten“ und ”Produktdaten-
qualit¨
at“ definiert. Produktdaten sind demnach alle Daten, die von der Konzeption bis zur
Fertigung eines Produktes ben¨
otigt werden, etwa CAD-11, CAM-12, CAE-13 und PDM- Daten.
Die Richtlinie umfasst bisher nur Qualit¨
atskriterien f¨
ur geometrische Modelle und Zeichnungen;
Kriterien f¨
ur weitere Bereiche sind geplant.
4.2.6. Abgleich der Anforderungen
Die diskutierten Standards werden nun mit den Anforderungen aus Abschnitt 3.3 abgeglichen.
Anforderung 1 (Bedarfsgerechte Integration, Ber¨ucksichtigung von Variabilit¨at und
Versionierung)
Mit dem ISO Standard ISO 18876 wird eine grobe Integrationsarchitektur skizziert, jedoch keine
detaillierte Spezifikation gegeben. Diese Architektur kann als Grundlage f¨
ur ein Produktdaten-
integrationssystem herangezogen werden. Dabei bleiben jedoch viele Herausforderungen offen.
Es wird lediglich gefordert, dass die Identit¨
at von Instanzen ermittelt werden kann, um die
Instanzen zu integrieren bzw. konsolidieren. Gleiches gilt f¨
ur die Erstellung der Mappings zwi-
schen Integrationsmodell und den Modellen der zu integrierenden Informationssysteme. Wie die
genaue Transformation zwischen den Schemakonzepten aussehen soll, bleibt allerdings offen.
Damit sind auch keine expliziten Konzepte f¨
ur die Integration von Konzepten f¨
ur den Umgang
mit Variabilit¨
at und Versionierung vorhanden.
ISO 10303 ist in erster Linie entstanden, um den Austausch von Geometriemodellen zwischen
Herstellern und Lieferanten zu erm¨
oglichen. In der Literatur existieren einige Analysen zur
Verbreitung und zum praktischen Einsatz. In diesem Kontext beschreibt [GOP02] vier Haupt-
probleme, die einen praktischen Einsatz von STEP erschweren:
1. Hohe initiale Investitionskosten f¨
ur die Entwicklung bzw. Etablierung eines Standards, von
dem alle beteiligten Industriepartner profitieren,
2. Marktrisiken, die durch Rivalit¨
aten zwischen CAD-Herstellern und Firmen entstehen, die
STEP-Softwarebausteine entwickeln,
11Computer-aided design
12Computer-aided manufacturing
13Computer-aided engineering
89
4. Stand der Technik
3. Technische Risiken, die bei der Entwicklung von STEP-¨
Ubersetzern und zugeh¨
origen Tools
auftreten k¨
onnen sowie
4. Notwendigkeit einen unvoreingenommen Experten zu etablieren, der die Verhandlungen,
Entwicklung und Realisierung von Standards leitet.
Hauptanwender von ISO 10303 sind die Automobilbranche sowie die Luft- und Raumfahrt-
industrie [AT00]. Der Fokus liegt auf dem Austausch von Geometriedaten. Damit wird ein
großer Teil der modernen Produktentwicklung, etwa die E/E-Entwicklung und deren Prozes-
se [BHR05, MHR06, MHR07], zu wenig ber¨
ucksichtigt und somit nicht mehr ausreichend un-
terst¨
utzt.
Auf der einen Seite sind die Application Protocols zu komplex und die Weiterentwicklung der
Normierungen langsam. Um auf ver¨
anderte Rahmenbedingungen (z.B. neue Technologien oder
neue Kundenw¨
unsche) schneller eingehen zu k¨
onnen, wurden die Entwicklungszyklen komplexer
Produkte in den letzten Jahrzehnten deutlich verk¨
urzt. Folglich werden Application Protocols
durch Unternehmen sehr z¨
ogerlich umgesetzt.
In STEP werden allen Bauteile und Dokumente als Product dokumentiert. Stammen zwei STEP-
Files von unterschiedlichen Herstellern bzw. Zulieferern, ist das Problem der Identit¨
at von Bau-
teilen bzw. Dokumenten mit STEP nicht gel¨
ost. STEP dient lediglich dazu, den Austausch tech-
nisch zu erm¨
oglichen. Zwar ist die Theorie des Variabilit¨
atsmanagement in der Industrie gut
verstanden, jedoch fehlen durchg¨
angige Ans¨
atze, um ein unternehmensweites Variantenmanage-
ment zu erm¨
oglichen.
Anforderung 2 (Benutzerunterst¨utzung)
Weder ISO 10303 noch ISO 18876 besitzen Konzepte f¨
ur die Unterst¨
utzung von Benutzern bei
der Integration von Produktdaten.
Anforderung 3 (Nutzung)
ISO 10303 bietet unterschiedliche M¨
oglichkeiten, um Produktdaten zu kodieren. Dazu z¨
ahlen
neben einer API, die auf relationalen Datenbanken basiert, auch die Unterst¨
utzung von verschie-
denen Programmiersprachen oder auch die Kodierung als Text oder XML-Dokument.
Anforderung 4 (Monitoring)
Wie bei der Benutzeruntst¨
utzung betrachten ISO 10303 und ISO 18876 nicht das Monitoring
der Integration. Lediglich ISO 8000 sieht das Monitoring der Datenqualit¨
at als essentiell an,
beschreibt jedoch keine konkrete L¨
osung.
Anforderung 5 (Change Management)
ISO 10303 betrachtet ¨
Anderungen an Datenmodellen und deren Auswirkungen auf bereits inte-
grierte Produktdaten nicht. ISO 18876 beschreibt verschiedene Szenarien der Integration, wor-
unter auch die Anpassung des Integrationsmodells f¨
allt. Wie erw¨
ahnt, handelt es sich bei der
Architektur um eine grobe Skizze, explizite L¨
osungskonzepte werden nicht erl¨
autert.
90
4.3. Zusammenfassung
Anforderung 6 (Methodiken)
ISO 8000 und 18876 definieren zwar Rahmenwerke f¨
ur die Integration bzw. das Qualit¨
atsmanage-
ment von Daten, jedoch ist deren Beschreibung abstrakt gehalten, ohne bestehende Probleme,
etwa dem Umgang mit Variabilit¨
at und Versionierung bei der Datenintegration, zu l¨
osen.
4.3. Zusammenfassung
Wie in Tabelle 4.1 illustriert, gibt es eine L¨
ucke bei der Integration von Produktdaten, unter
Ber¨
ucksichtigung von Variabilit¨
ats- und Versionierungkonzepten. Auf Grund der verschiede-
nen Annahmen, findet nur bei Data Warehouse-Systemen eine ¨
Uberwachung des Integrations-
prozesses statt, w¨
ahrend die virtuell integrierenden Ans¨
atze (z.B, F¨
oderierte- und Peer-Daten-
Management-Systeme) von guter Datenqualit¨
at und fehlenden Integrationskonflikten ausgehen.
Ansatz A1 A1.1 A1.2 A2 A3 A4 A5 A6
F¨
oderierte Datenbanksysteme o - - - o - o o
Data Warhouse Systeme + - - + o + + o
Peer-Data-Management-Systeme o - - - o - o o
Tool Integration o - - o o - o o
ISO 10303 o - - - o - - -
ISO 18876 o - - o o - o o
ISO 8000 - - - o o o o o
Tabelle 4.1.: Abgleich der Anforderungen + : wird unterst¨
utzt o : teilweise unterst¨
utzt - : nicht un-
terst¨
utzt
91
Teil II
L¨osungskonzepte
5. PROCEED-Rahmenwerk im ¨
Uberblick
Wie die Anforderungsanalyse aus Kapitel 4 gezeigt hat, gibt es eine Forschungsl¨
ucke bzgl. der
Integration von Produktdaten, wenn grundlegende Konzepte f¨
ur den Umgang mit Variabilit¨
at
und Versionierung mit unterst¨
utzt werden sollen. Im Folgenden wird ein ¨
Uberblick ¨
uber das
im Rahmen der vorliegenden Dissertation entwickelte PROCEED-Rahmenwerk gegeben, welches
ein Produktdatenintegrationssystem bietet, dass die erl¨
auterten Probleme und Anforderungen
adressiert.
Produktdaten besitzen keine allgemeing¨
ultige Definition (vgl. Abschnitt 2.2.3). Jedes Unterneh-
men verwendet eigene Strukturen, Richtlinien und Terminologien f¨
ur den Umgang mit Produkt-
daten, so dass jedes PDMS letztlich einmalig ist. Folglich k¨
onnen zwei Produkthersteller dasselbe
PDMS verwenden und dennoch auf Grund der unterschiedlichen Unternehmensvorgaben (Pro-
duktstrukturen, Benennungen, Variabilit¨
atsmechanismen, Versionierungsstrategien) keine Pro-
duktdaten untereinander austauschen (vgl. Abschnitt 3.1). Gemeinsame Basis f¨
ur den Austausch
von Produktdaten zwischen Herstellern und Zulieferern sind Bauteile, d.h. physisch hergestellte
Erzeugnisse.
Auch die in Abschnitt 4.2 betrachteten Standards, allen voran STEP, sehen Bauteile als essenti-
elles Konzept der Produktentwicklung an. Dar¨
uber hinaus haben alle Produktentwicklungsstan-
dards gemein, dass es unterschiedliche Varianten dieser Bauteile geben kann. Um deren fort-
laufende Entwicklung und die Anforderung nach l¨
uckenloser Dokumentation zu gew¨
ahrleisten,
werden Bauteile in der Produktentwicklung versioniert. Dem entsprechend findet die Integration
heterogener Produktdaten im PROCEED-Rahmenwerk auf Bauteilebene statt.
5.1. Lebenszysklus der Produktdatenintegration
Das PROCEED-Rahmenwerk wird nachfolgend anhand des Integrationslebenszyklus erl¨
autert
(siehe Abbildung 5.1). Ziel der Produktdatenintegration ist die Unterst¨
utzung von Anwen-
dungsf¨
allen, die integrierte Produktdaten aus heterogenen Informationssystemen der Produkt-
entwicklung ben¨
otigen. Da die Qualit¨
at von Produktdaten w¨
ahrend der Produktentwicklung
unterschiedlich sein kann, erfolgt die Integration materialisiert in einem zentralem Modell. Da-
durch wird es m¨
oglich, ¨
ahnlich wie beim ETL-Prozess f¨
ur Data Warehouses (siehe Abschnitt
4.1.2), Daten zu bereinigen und korrigieren, bevor sie schließlich integriert werden.
Der Integrationslebenszyklus beginnt mit der Projektvorbereitung (1
), in der die zu realisie-
renden Anwendungsf¨
alle definiert und die relevanten Informationssysteme ermittelt werden.
Anschließend erfolgt die manuelle Schema-Integration (2
). Im Speziellen werden Abbildungen
zwischen korrespondierenden Schemakonzepten aus den zu integrierenden Informationssystemen
und dem PDIS definiert. Diese Abbildungsregeln stellen die Grundlagen f¨
ur die Integration von
Instanzen der Schemakonzepte dar. Dazu ist es notwendig, die Identit¨
at von Instanzen zwischen
den Informationssystemen und dem PDIS zu definieren. Damit ist gemeint, dass diejenigen At-
tribute der Schemakonzepte identifiziert werden m¨
ussen, die Instanzen eindeutig beschreiben.
95
5. PROCEED-Rahmenwerk im ¨
Uberblick
Zus¨
atzlich werden Aktionen definiert, die w¨
ahrend der Integration durchgef¨
uhrt werden sollen.
Die Auswertung der Abbildungsregeln erfolgt in der automatischen Datenintegration (3
).
Auf Grund unterschiedlicher Datenqualit¨
at kann diese Integration allerdings nicht immer f¨
ur
alle Instanzen korrespondierende Instanzen finden. Daher wird eine manuelle Datenintegration
notwendig ( 4
). Ist die Integration abgeschlossen, kann die Datennutzung erfolgen. Bereits mit
der manuellen Schemaintegration beginnt die ¨
Uberwachung des Integrationsprozesses, wodurch
es m¨
oglich wird, dessen Fortschritt zu beobachten ( 7
). Treten ¨
Anderungen an Produktdaten auf
(6
), m¨
ussen neue bzw. ge¨
anderte Schemakonzepte integriert ( 8
) oder aber die automatische
Integration f¨
ur neue bzw. ge¨
anderte Instanzen erneut durchgef¨
uhrt werden (vgl. 9
).
Abbildung 5.1.: Lebenszyklus der Produktdatenintegration
5.2. Integration
Bereits in Abschnitt 2.3.4 wurden die zwei grundlegenden Architekturen zur Integration hetero-
gener Systeme vorgestellt, bei denen zwischen lokalen Informationssystem und einem globalen,
integrierenden System unterschieden wird. Auf dieselbe Weise werden im PROCEED-Rahmenwerk
nun Produktdaten lokaler Informationssysteme in ein globales Produktdatenintegrationssystem
integriert, das eine ganzheitliche Sicht auf unterschiedliche Produktdaten bieten soll. Auf Grund
der unterschiedlichen Qualit¨
at von Produktdaten aus heterogenen, lokalen Informationssyste-
men erfolgt deren Integration im PROCEED-Rahmenwerk materialisiert in das PDIS.ZurUn-
terst¨
utzung von Anwendungsf¨
allen, die integrierte Produktdaten ben¨
otigen, ist ein rein lesender
96
5.2. Integration
Datenzugriff ausreichend.
Da eine vollst¨
andige Integration aller Datenmodellkonzepte in der Praxis unrealistisch ist bzw.
sich zu teuer darstellt, wird eine bedarfsgerechte, d.h. anwendungsfallgetriebene, Integration von
Schemakonzepten angestrebt. Dieses Vorgehen wird in der Literatur als Pay-as-you-Go-Prinzip
bezeichnet [DSDH08].
In PROCEED wird zwischen Schema- und Instanzintegration unterschieden. W¨
ahrend die Sche-
maintegration vollst¨
andig manuell durch Experten durchgef¨
uhrt wird, ist die Integration von
Instanzen zweigeteilt. Zun¨
achst werden auf Grundlage von Abbildungsregeln korrespondierende
Instanzen ermittelt. Die Definition von Abbildungsregeln erfolgt dabei auf Attributebene der
Schemakonzepte. F¨
ur ein Schemakonzept eines lokalen Informationssystems k¨
onnen eine oder
mehrere Regeln auf ein Schemakonzept aus dem globalen PDIS definiert werden. Die Menge
der Regeln f¨
ur ein Schemakonzeptpaar aus lokalem Informationssystem und PDIS dient dazu,
korrespondierende Instanzen dieser Schemakonzepte zu ermitteln. Neben den Regeln lassen sich
weitere Aktionen zwischen Schemakonzeptpaaren definieren, die w¨
ahrend der Integration von
Instanzen durchgef¨
uhrt werden sollen. Dies kann z.B. das Kopieren eines Attributwertes aus
dem Schemakonzept eines lokalen Informationssystems in das PDIS sein.
Nach der Definition von Abbildungsregeln und -aktionen findet eine automatische Auswertung
der Regeln auf die zu integrierenden Instanzen statt. Anschließend erfolgt die ¨
Uberpr¨
ufung der
Ergebnisse der automatischen Integration durch Fachanwender. Letztere erstellen gegebenenfalls
fehlende Korrespondenzen oder korrigieren fehlerhafte Korrespondenzen.
In der Praxis werden die verschiedenen Perspektiven auf Produktdaten in applikationsspezi-
fischen Informationssystemen gespeichert. Diese basieren auf unterschiedlichen Datenmanage-
menttechnologien, etwa relationalen Datenbanken, XML-Dokumenten oder Dateien. Um diese
technische Heterogenit¨
at zu bew¨
altigen, m¨
ussen Produktdaten in einer plattformunabh¨
angigen
Form abstrahiert werden. Aus diesem Grund werden sie im PROCEED-Rahmenwerk als wie-
derverwendbare, interoperable und plattformunabh¨
angige Ontologien verwaltet. Abbildung 5.2
gibt einen ¨
Uberblick ¨
uber die einzelnen Konzepte des PROCEED-Rahmenwerks. Datenmodell-
konzepte aus heterogenen, autonomen und lokalen Informationssystemen werden in sog. lokale
Produktontologien abstrahiert. Diese dienen dazu, unterschiedliche Arten von Heterogenit¨
aten zu
¨
uberwinden (siehe Abschnitt 2.3.6). Durch eine einheitliche Struktur lassen sich so strukturelle,
technische und semantische Heterogenit¨
aten ¨
uberwinden.
Da ein komplexes Produkt aus tausenden von Bauteilen bestehen kann, welche wiederum in
verschiedenen Varianten und Versionen vorliegen, sollte die Komplexit¨
at der Integration verrin-
gert werden. Eines der wichtigsten Strukturierungsprinzipien zur Reduktion von Komplexit¨
at
ist die Hierarchiesierung [Sim96]. Dem entsprechend werden lokale Produktdaten hierarchisch
in vier Produktdatenintegrationsebenen (engl. product data integration layer, PDILs)unterteilt.
Schemakonzepte (SCs)aus lokalen Informationssystemen werden entsprechenden PDILs zuge-
ordnet. ¨
Uber Schemakonzept-Attributregeln (engl. schema concept attribute rules, SCARs)der
gleichen PDIL aus lokalen Produktontologien (LPOs)und der globalen Produktontologie (GPO)
werden die zuvor erw¨
ahnten Abbildungsregeln definiert. W¨
ahrend der automatischen Instanzin-
tegration erfolgt die Auswertung von SCARs f¨
ur lokale und globale Produktontologien. Im Falle
von ¨
Ubereinstimmungen werden entsprechende Korrespondenzen zwischen Instanzen aus lokalen
und globalen Schemakonzepten erzeugt.
Die globale Produktontologie stellt die holistische Sicht der einzelnen lokalen Produktontolo-
gien dar und dient als zentrale Datenbasis f¨
ur die zu unterst¨
utzenden Anwendungsf¨
alle. ¨
Uber
Schemakonzept-Attributaktionen (engl. schema concept attribute actions, SCAAs)wird definiert,
97
5. PROCEED-Rahmenwerk im ¨
Uberblick
welche Attribute von lokalen Schemakonzepten in korrespondierende Instanzen der globalen
Produktontologie integriert werden.
352&(('
VF/
6&$5
6&$$
&25%
6&$5
6&$$
&25
6&$5
6&$$
&25
6&$5
6&$$
&25
'RPDLQ
([SHUW
,QWHJUDWLRQ
%RDUG
.QRZOHGJH
(QJLQHHU
'DWD 4XDOLW\
(QJLQHHU
%XVLQHVV
8VHU
,QWHJUDWLRQ
([SHUW
Lokales
Informationssystem
6FKHPDNRQ]HSW ,QVWDQ]
6&$5 6&$$
&25
6FKHPDNRQ]HSW$WWULEXW5HJHO 6FKHPDNRQ]HSW$WWULEXW$NWLRQ
.RUUHVSRQGHQ]
Lokales
Informationssystem
,17(*5$7,21 021,725,1* &+$1*(
/RNDOHV
,QIRUPDWLRQVV\VWHP
/RNDOH3URGXNWRQWRORJLH32/*OREDOH3URGXNWRQWRORJLH32*
VF/
VF/
VF/
VF*
VF*
VF*
VF*
Abbildung 5.2.: ¨
Ubersicht PROCEED-Rahmenwerk
F¨
ur die verschiedenen Schritte im Lebenszyklus der Integration sind unterschiedliche Rollen
verantwortlich, die in den folgenden Kapiteln noch im Detail erl¨
autert werden. Im Speziellen
werden die Schritte 1
bis 4
des Lebenszyklus aus Abbildung 5.1 in Kapitel 6, Schritt 7
in
Kapitel 7sowie Schritt 6
in Kapitel 8 beschrieben.
98
6. Integration heterogener Produktdaten
Die Integration heterogener Produktdaten aus autonomen, lokalen Informationssystemen um-
fasst verschiedene Aktivit¨
aten (vgl. Lebenszyklus aus Abschnitt 5.1), die in diesem Kapitel
erl¨
autert werden. Dazu z¨
ahlen die Abbildung lokaler Informationssysteme auf sog. lokale Pro-
duktontologien,diemanuelle Schemaintegration sowie die automatische und manuelle Instan-
zintegration.
6.1. Projektvorbereitung
Der erste Schritt im Lebenszyklus der Produktdateintegration ist die Projektvorbereitung. Hier-
zu z¨
ahlen:
•Anwendungsf¨
alle definieren: Zun¨
achst definieren Fachanwender eine Menge relevanter
Anwendungsf¨
alle, welche durch die Integration von Produktdaten aus heterogenen, auto-
nomen Informationssystemen unterst¨
utzt werden sollen. Dazu spezifizieren Mitglieder der
Fachabteilungen, die Beteiligte der Anwendungsf¨
alle sind, zusammen mit Integrationsex-
perten, die zu integrierenden Schemakonzepte. W¨
ahrend Mitarbeiter der Fachabteilungen
in der Regel nur die Schemakonzepte kennen, f¨
ur die sie auch im verantworteten Infor-
mationssystem zust¨
andig sind, verf¨
ugen Integrationsexperten ¨
uber umfassendes Wissen zu
den Zusammenh¨
angen mehrerer Informationssysteme.
•Informationssysteme bestimmen: Die Anwendungsf¨
alle determinieren die zu inte-
grierenden Informationssysteme. Ein Integrationsgremium wird aus Verantwortlichen der
betroffenen Informationssysteme, Integrationsexperten sowie den Initiatoren des Anwen-
dungsfalles gebildet. Nachdem dieses Gremium die Anwendungsf¨
alle freigegeben hat, wer-
den Integrationsteams gebildet.
•Integrationsumfang bestimmen (Schemakonzepte, Instanzen): Da ein Informa-
tionssystem typischerweise Dutzende von Schemakonzepten und Tausende von Instanzen
enth¨
alt, muss der Umfang der Integration m¨
oglichst exakt definiert werden. F¨
ur die zeitli-
che und logische Strukturierung existieren verschiedene Mechanismen (z.B. Zusammenfas-
sung von Instanzen nach Projekten oder Plattformen). Diese Projekte k¨
onnen nebenl¨
aufig
in unterschiedlichen Phasen vorhanden sein, d.h. der Reifegrad von Produktdatenartefak-
ten ist unterschiedlich. Folglich sollten auch nur diejenigen Instanzen integriert werden,
die f¨
ur einen Anwendungsfall definiert worden ist.
•Integrationszeitplan erstellen: Wie erw¨
ahnt, ist die Produktentwicklung in fest de-
finierte Phasen mit konkreten Zeitintervallen eingeteilt. D.h., Anwendungsf¨
alle m¨
ussen
ebenfalls in einem festgelegten Zeitraum durchgef¨
uhrt werden k¨
onnen. Dazu wird analog
zum Entwicklungsprozess ein Integrationszeitplan durch das Integrationsgremium definiert.
99
6. Integration heterogener Produktdaten
•Integrationsmethodiken festlegen: In Abschnitt 2.3.5 wurden verschiedene Integra-
tionsmethodiken vorgestellt. Ebenso lassen sich Produktdaten auf verschiedene Art und
Weise integrieren. Mit welcher Methode Schemakonzepte und Instanzen eines Informa-
tionssystems in das PDIS integriert werden, wird wieder durch das Integrationsgremium
festgelegt.
6.2. Manuelle Schemaintegration
Nach Abschluss der Projektvorbereitung, stehen die zu integrierenden Systeme fest. Dom¨
anen-
experten modellieren anschließend, zusammen mit den Administratoren der Informationssyste-
me, lokale Produktontologien. Dabei sind unterschiedliche F¨
alle zu unterscheiden. Findet eine
Integration zum ersten Mal statt und ist noch keine globale Produktontologie vorhanden, muss
zuerst eine globale Produktontologie erstellt werden. Die genaue Vorgehensweise h¨
angt dabei
von den Entscheidungen aus der Projektvorbereitung ab.
6.2.1. Abbildung von Informationssystemen auf lokale Produktontologien
W¨
ahrend Schemakonzepte der Informationssysteme in der Produktentwicklung durch unter-
schiedliche konzeptionelle Modellierungssprachen (z.B. relationales oder objektorientiertes Da-
tenmodell) definiert werden, k¨
onnen Instanzen dieser Konzepte technisch verschieden repr¨
asen-
tiert sein (z.B. relationale Datenbank oder Datei-basiert).
Um die sich hier bietende technische Heterogenit¨
at zu ¨
uberwinden, werden Schemakonzepte
und Instanzen von Informationssystemen im PROCEED-Rahmenwerk in sog. Produktontologien
abstrahiert. Diese dienen als Grundlage f¨
ur die Integration autonomer, heterogener Informati-
onssysteme in der Produktentwicklung. Eine Produktontologie etwa abstrahiert Schemakonzepte
und Instanzen von Informationssystemen der Produktentwicklung in eine definierte Struktur. Da
die definierten Konzepte f¨
ur eine spezifische Dom¨
ane – im vorliegenden Fall ist dies die Produkt-
entwicklung – gelten, handelt es sich bei Produktontologien somit um Dom¨
anenontologien.
Jedes Informationssystem, das f¨
ur die Umsetzung von Anwendungsf¨
allen integriert werden soll,
wird in dieselbe Struktur abstrahiert. Dadurch wird semantische Heterogenit¨
at vermieden. In
Abschnitt 4.1.1 wurden z.B. f¨
oderierte Datenbanksysteme als eine M¨
oglichkeit betrachtet, um
heterogene Systeme zu integrieren. Das dort vorgestellte 5-Ebenen-Schema-Modell erl¨
autert die
verschiedenen Ebenen, die bei der Integration heterogener Systeme auftreten k¨
onnen. Vergleich-
bar mit dem Komponenten- und Exportschema aus dem 5-Ebenen-Schema-Modell f¨
oderierter
Datenabanksysteme stellt eine lokale Produktontologie eine Kombination beider Schema dar.
Abbildung 6.1 zeigt das 5-Ebenen-Schema-Modells (vgl. Abb. 6.1a)) sowie die Ebenen im
PROCEED-Rahmenwerk (siehe Abb. 6.1b).
Liegen lokale Schemata in verschiedenen Datenmodellen vor, m¨
ussen sie im 5-Ebenen-Schema-
Modell zuvor in Komponentenschemata ¨
uberf¨
uhrt werden, bevor sie anschließend integriert wer-
den. Im PROCEED-Rahmenwerk findet dar¨
uber hinaus mehr als nur eine Umwandlung in ein
zuvor festgelegtes Datenmodell, in diesem Fall Ontologien, statt. Konzepte des lokalen Schemas
werden semantischen Ebenen innerhalb der lokalen Produktontologie zugeordnet. Weiter kann
implizites Wissen ¨
uber Schemata explizit dokumentiert werden.
W¨
ahrend im 5-Ebenen-Schema-Modell eine Unterscheidung zwischen Komponenten- und Ex-
portschema erfolgt, entspricht letzteres einer lokalen Produktontologie, d.h. Exportschema und
100
6.2. Manuelle Schemaintegration
lokale Produktontologie enthalten nur diejenigen Schemakonzepte und Daten, die von einem
Informationssystem f¨
ur die Integration ¨
offentlich bereitgestellt werden.
|IIHQWOLFK
SULYDW
'DWHQTXHOOH
I|GHULHUWHV
6FKHPD
.RPSRQHQWHQ
VFKHPD
ORNDOHV6FKHPD
([SRUWVFKHPD ([SRUWVFKHPD
H[WHUQHV6FKHPD H[WHUQHV6FKHPD
'DWHQEDQN
ORNDOH
3URGXNWRQWRORJLH
ORNDOHV6FKHPD
'DWHQEDQN 'DWHL 6HUYLFH
JOREDOH
3URGXNWRQWRORJLH
D(EHQHQ6FKHPD0RGHOO E(EHQHQLP352&(('5DKPHQZHUN
Abbildung 6.1.: Relation zwischen 5-Ebenen-Schema-Architektur FDBS und lokaler Produktontologie
Dom¨
anenexperten verf¨
ugen h¨
aufig ¨
uber implizites Wissen (engl. sog. tacid knowledge [LR07]).
Dazu z¨
ahlen etwa Dokumentationsmethodiken, also Vorgehensweisen und Erfahrungswerte f¨
ur
die Strukturierung und Dokumentation von Produktdaten im Rahmen eines vorgegebenen kon-
zeptionellen Datenmodells.
Ein Beispiel f¨
ur implizites Wissen, das im Zuge der Anforderungserhebung durch Interviews von
Anwendern geschildert wurde, ist wie folgt:
In einem Informationssystem werden Signale dokumentiert, die zwischen E/E-Komponenten
ausgetauscht werden. Um den Modellierungs- und Dokumentationsaufwand zu reduzieren, wer-
den E/E-Komponenten, welche sich semantisch im Sinne der Signal¨
ubermittlung gleich verhal-
ten, nur einmal dokumentiert. Erfolgt die Weitergabe dieser Produktdaten an andere Infor-
mationssysteme, werden weitere E/E-Komponenten durch Kopieren erzeugt. Geschieht dieser
Vorgang manuell durch einen Anwender, k¨
onnen Fehler beim Kopieren auftreten oder gar E/E-
Komponenten vergessen werden.
101
6. Integration heterogener Produktdaten
Diese Information kann f¨
ur die Integration n¨
utzlich sein und sollte daher explizit dokumentiert
werden. Vor allem f¨
ur die Integration von Produktdaten sind Angaben zur Dom¨
ane einer Ap-
plikation, zu verwendeten Konzepten f¨
ur die Modellierung von Variabilit¨
at und Versionierung
sowie zur Gruppierung von Produktdaten erforderlich. Diese Informationen werden in lokalen
Produktontologien als informelle Annotationen zu Schemakonzepten hinterlegt und k¨
onnen bei
der sp¨
ateren Integration in ein PDIS durch Integrationsexperten genutzt werden. Letztere k¨
onnen
auf Basis solcher Informationen bei Unklarheiten schneller R¨
ucksprache mit Dom¨
anenexperten
halten und so den Integrationsprozess beschleunigen. Das Dokumentieren zus¨
atzlicher Informa-
tionen, die erst im weiteren Verlauf n¨
utzlich werden k¨
onnen, wird in anderen Zusammenh¨
angen
auch als Look-Ahead bezeichnet [BBR11].
Grundlage f¨
ur die Produktentwicklung sind Systeme, die aus mehreren interagierenden Kompo-
nenten bestehen. Komponenten, im Folgenden auch Bauteile genannt, sind physische Erzeugnis-
se, die in St¨
ucklisten verwaltet werden und die Grundlage f¨
ur die Produktion eines Produktes
bilden (vgl. Abschnitt 2.2.2). Da w¨
ahrend der Produktentwicklung verschiedene Aspekte von
Bauteilen dokumentiert werden, ist der gemeinsame Nenner der Informationssysteme das Sche-
makonzept Bauteil, welches in den verschiedenen Systemen unterschiedlich benannt sein kann
und dabei oftmals unterschiedliche Semantik besitzt.
H¨
aufig findet eine Vermischung verschiedener Datenstrukturen zu einem Schemakonzept statt,
welches in lokalen Informationssystemen als Bauteil, Komponente oder ¨
ahnliches bezeichnet
wird. Spezielle Datenstrukturen in der Produktentwicklung sind z.B. St¨
ucklisten, CAD-Daten,
PDM-Daten, Zeichnungsdaten, die ”Bauteile” zu einem Produkt aggregieren. Bei dieser Ag-
gregation spielen sowohl zeitliche als auch logische Aspekte eine Rolle. Ein wichtiger zeitlicher
Aspekt der Produktentwicklung ist die Versionierung,w
¨
ahrend ein relevanter logischer Aspekt
das Konfigurationsmanagement ist. Wie bereits in der Problemanalyse erl¨
autert (vgl. Abschnitt
1.2), f¨
uhren unterschiedliche Anforderungen und Sichtweisen der verschiedenen Entwickler in
der Produktentwicklung dazu, dass sowohl verschiedene Datenstrukturen als auch verschiedene
Versionierungs- und Konfigurationsmechanismen verwendet werden.
Um diese Mehrdeutigkeiten aufzul¨
osen, erfolgt die Einordnung von Schemakonzepten lokaler
Produktontologien in semantisch eindeutig spezifizierte Produktdatenintegrationsebenen (engl.
product data integration layers) (PDILs). Durch die einheitliche Zuordnung von Schemakonzep-
ten lassen sich diese aus verschiedenen lokalen Produktontologien integrieren, ohne dass es zu
semantischen Konflikten kommt.
In Anlehnung an das integrierte Produktmodell von ISO 10303 (siehe Abschnitt 4.2.3) sind
diese Ebenen in PROCEED hierarchisch aufgebaut. Abbildung 6.2 illustriert den Zusammenhang
zwischen den Artefakten aus dem integrierten Produktmodell von STEP und den PDILs von
PROCEED.
Schemakonzepte, die einen Bauteilaspekt (z.B. Metadaten, Anforderungen, logistische Informa-
tionen) beschreiben, werden der Object-Produktdatenintegrationsebenen zugeordnet.
Da ein Produkt aus einer Vielzahl an Bauteilen bestehen kann, werden diese zu Kollektionen
zusammengefasst. In der Produktentwicklung werden unterschiedliche Bezeichnungen hierf¨
ur
verwendet, etwa Produkt,Modell,Baureihe und Projekt. Diese strukturierenden Schemakonzepte
werden der Product Data Collection-Produktdatenintegrationsebene zugeordnet.
Wie bereits im Kontext des integrierten Produktmodells von ISO 10303 erw¨
ahnt (vgl. Abschnitt
4.2.3), k¨
onnen Bauteile in unterschiedlichen Bauteilvarianten existieren. Informationssysteme
realisieren die Modellierung von Variabilit¨
at auf verschiedene Art und Weise. Schemakonzepte
aus lokalen Informationssystemen, die der Beschreibung von Bauteilvariabilit¨
at dienen, werden
102
6.2. Manuelle Schemaintegration
SURGXFW
SURGXFWBGHQLWLRQB
IRUPDWLRQ
DOWHUQDWHBSURGXFWB
UHODWLRQVKLS
SURGXFWBGHQLWLRQB
IRUPDWLRQBUHODWLRQV
VKLS
FRQJXUDWLRQB
GHVLJQ
FRQJXUDWLRQBLWHP
2EMHFW
3URGXFW'DWD
&ROOHFWLRQ
9DULDQW
9HUVLRQ
D,QWHJULHUWHV3URGXNWPRGHOO67(3 E3URGXNWGDWHQLQWHJUDWLRQVHEHQHQ
Abbildung 6.2.: Zusammenhang zwischen Artefakten des integrierten Produktmodells von STEP und
PROCEED
der Variant-Ebene zugeordnet.
Schließlich durchl¨
auft jedes Bauteil eine Entwicklung, in der unterschiedliche Entwicklungsst¨
ande
anfallen, die zwecks l¨
uckenloser Dokumentation der Entwicklungsergebnissen aufbewahrt werden
m¨
ussen. Schemakonzepte, die der Beschreibung zeitlicher Aspekte von Bauteilen dienen, werden
der Version-Ebene zugeordnet.
Lokale Informationssysteme m¨
ussen nicht f¨
ur jede Produktdatenintegrationsebene korrespon-
dierende Schemakonzepte besitzen. Wie erw¨
ahnt, k¨
onnen Schemakonzepte lokaler Informations-
systeme mehrere Strukturierungsmechanismen beinhalten. Weiter kann es vorkommen, dass ein
lokales Informationssystem nicht jeden Strukturierungsmechanismus unterst¨
utzt.
Auch kann es vorkommen, dass ein Schemakonzept eines lokalen Informationssystems mehre-
re Produktdatenintegrationsebenen abdeckt. In diesem Fall sollten Transformationen zwischen
lokalem Informationssystem und lokaler Produktontologie erfolgen, um eine explizite Trennung
von Strukturierungsmechanismen, wie Variabilit¨
at und Versionierung, zu erreichen.
Jedes Schemakonzept einer Produktontologie besitzt unterschiedliche Attribute. Dazu z¨
ahlen
sowohl Metadatenattribute,wieNamen,Erstellungs-/
¨
Anderungszeit, eindeutige Kennungen und
Informationen zu Zugriffsrechten, als auch Inhaltsattribute, welche die eigentlichen Entwicklungs-
ergebnisse von Bauteilen beinhalten.
Zusammengefasst definieren wir eine Produktontologie informell wie folgt:
Definition 19 (Produktontologie). Eine Produktontologie beschreibt einen oder mehre-
re Aspekte einer Menge an Bauteilen eines Produktes. Es wird zwischen lokalen Produktonto-
logien und integrierender globaler Produktontologie unterschieden. Lokale Produktontologien
beinhalten diejenigen Schemakonzepte und Instanzen lokaler Informationssysteme der Pro-
duktentwicklung, die f¨
ur die Realisierung von Anwendungsf¨
allen ben¨
otigt werden bzw. f¨
ur
eine Integration bereitgestellt werden.
Innerhalb einer lokalen Produktontologie sind Schemakonzepte und ihre Instanzen einer von
103
6. Integration heterogener Produktdaten
vier Produktdatenintegrationsebenen zugeordnet. Schemakonzepte sind auf diesen Ebenen
hierarchisch angeordnet. Zwischen einem Schemakonzept einer Ebene und einem zugeh¨
origen
Schemakonzept auf der darunterliegenden Ebene besteht eine Aggregationsbeziehung. Die
Produktdatenintegrationsebenen heißen Product Data Collection (PDC),Object (Obj),Va-
riant (Var) und Version (Ver).
Beispiel 16 (Produktontologie). Abbildung 6.3 illustriert den Zusammenhang zwischen
einem exemplarischen lokalen Schema eines Informationssystems und einer korrespondie-
renden lokalen Produktontologie. Schemakonzepte des lokalen Informationssystems werden
auf entsprechende Schemakonzepte in den verschiedenen Produktdatenintegrationsebenen
abgebildet. Der ¨
Ubersicht halber sind keine Attribute dargestellt; sie werden aus dem loka-
len Informationssystem den korrespondierenden Metadaten- oder Inhaltsattributen in der
lokalen Produktontologie zugeordnet. Schließlich wird implizites Wissen explizit mittels in-
formeller Anmerkungen in der lokalen Produktontologie dokumentiert.
Definition 20 (Produktdatenintegrationsebenen). Produktdatenintegrationsebenen
besitzen Konstrukte zur Zuordnung von Schemakonzepten aus lokalen Informationssyste-
men in Produktontologien. Mit jeder Ebene sind semantische Konzepte der Produktent-
wicklung verkn¨
upft. Sie erm¨
oglichen es, semantische Heterogenit¨
at w¨
ahrend der Integration
von Produktontologien zu beseitigen. Die Ebenen einer Produktontologie sind hierarchisch
aufgebaut und beschreiben Aggregationsbeziehungen.
Beispiel 17 (Produktdatenintegrationsebenen). Das Beispiel aus Abbildung 6.3 be-
sitzt f¨
ur jede Produktdatenintegrationsebene jeweils ein Schemakonzept. Bei dem lokalen
Informationssystem handelt es sich um ein System zur Dokumentation von Anforderungen.
Der Produktdatenaspekt der lokalen Produktontologie betrifft die Anforderungen von Kom-
ponenten. Entsprechend beschreibt das Schemakonzept Component Requirement die Anfor-
derungen f¨
ur eine Komponente, die zu einem Projekt (Project Requirements) zusammenge-
fasst werden. Da Component Requirement einen Aspekt beschreibt, ist das Schemakonzept
der Produktdatenintegrationsebene Object zugeordnet, w¨
ahrend Componente Requirement
ein Schemakonzept der Ebene Product Data Collection darstellt. Die Anforderungen ei-
ner Komponente beinhalten alle Anforderungen an alle m¨
oglichen Komponentenvarianten.
Das entsprechende Schemakonzept Component Requirement Variant ist der Produktdaten-
integrationsebene Variant zugeordnet. Zus¨
atzlich wird das zuvor erw¨
ahnte implizite Wis-
sen, dass Anforderungsspezifikationen alle Komponentenvarianten beschreiben explizit am
Schemakonzept Component Requirement Variant dokumentiert. Schließlich existieren An-
forderungsdokumente in verschiedenen Versionen, so dass das Schemakonzept Component
Requirement Version der Ebene Version zugeordnet ist.
104
6.2. Manuelle Schemaintegration
$EELOGXQJ
7UDQVIRUPDWLRQ
ORNDOHV,QIRUPDWLRQVV\VWHP ORNDOH3URGXNWRQWRORJLH
6FKHPD
3URMHFW
)HDWXUHJURXS
&RPSRQHQW
9HUVLRQ
3'&
2EMHFW
9DULDQW
9HUVLRQ
LPSOL]LWHV:LVVHQ
3URMHFW
H[SOL]LWHV
:LVVHQ
H[SOL]LWHV
:LVVHQ
)HDWXUHJURXS
H[SOL]LWHV
:LVVHQ
9HUVLRQ
H[SOL]LWHV
:LVVHQ
6FKHPDNRQ]HSW
&RPSRQHQW
0HWDGDWHQDWWULEXWH
,QKDOWVDWWULEXWH
0HWDGDWHQDWWULEXWH
,QKDOWVDWWULEXWH
0HWDGDWHQDWWULEXWH
,QKDOWVDWWULEXWH
0HWDGDWHQDWWULEXWH
,QKDOWVDWWULEXWH
0DSSLQJ6FKHPDNRQ]HSW
,QVWDQ]HQ
)HDWXUH
1DPH
0HWDGDWHQDWWULEXWH
,QKDOWVDWWULEXWH
Abbildung 6.3.: Abbildung eines lokalen Informationssystems in eine lokale Produktontologie
Bei der Abbildung von Schemakonzepten aus einem lokalen Informationssysteme in eine lokale
Produktontologie wird es ggf. notwendig, Transformationen durchzuf¨
uhren, falls keine direkten
Entsprechungen gefunden werden. Beispielsweise k¨
onnen Konzepte f¨
ur die Repr¨
asentation von
Variabilit¨
at ¨
uber mehrere Schemakonzepte im lokalen Informationssystem verteilt sein. Diese
strukturelle Heterogenit¨
at muss durch geeignete Transformationen aufgel¨
ost werden. Wie sol-
che Transformationen durchgef¨
uhrt werden k¨
onnen, h¨
angt von der jeweils zugrundeliegenden
Datenmanagementtechnologie des lokalen Informationssystems ab. Im Falle relationaler Daten-
banken k¨
onnen Transformationen durch SQL-Abfragen oder -Prozeduren durchgef¨
uhrt werden,
w¨
ahrend bei XML-Dateien XQuery oder XSLT zum Einsatz kommen k¨
onnen. Handelt es sich
um ein propriet¨
ares Format, kann die Transformation mit Hilfe verf¨
ugbarer APIs oder durch
Implementierung spezifischer Parser geschehen. Das Vorgehen der Transformation ¨
ahnelt dem
ETL-Prozess bei Data Warehouses (vgl. Abschnitt 4.1.2).
Die Behandlung von Instanzen aus einem lokalen Informationssystem kann unterschiedlich
erfolgen. Entweder werden die Instanzen im Transformationsprozess in die Produktontologie
¨
ubertragen oder sie werden nicht in lokalen Produktontologien gespeichert (materialisiert), son-
105
6. Integration heterogener Produktdaten
dern im Integrationsprozess ¨
uber Schnittstellen direkt aus dem Informationssystem abgefragt
(virtualisiert).
Beide Vorgehensweisen haben jeweils Vor- und Nachteile. Werden Instanzen in lokale Produk-
tontologien kopiert, k¨
onnen sie eine hilfreiche Informationsquelle f¨
ur die Abbildung von Sche-
makonzepten sein. Weiter ist es m¨
oglich, Daten w¨
ahrend der Transformation in lokale Produk-
tontologien zu bereinigen und damit die Datenqualit¨
at zu erh¨
ohen. Nachteilig ist, dass lokale
Produktontologien sehr groß werden k¨
onnen und Instanzen aus dem lokalen Informationssystem
und der lokalen Produktontologie synchronisiert werden m¨
ussen.
Werden Instanzen nicht in lokale Ontologien transferiert, sondern lediglich bei Bedarf von einem
lokalen Informationssystem abgerufen werden, bleiben lokale Produktontologien leichtgewichtig.
Jedoch fallen dadurch n¨
utzliche Informationen f¨
ur die Integration von Schemakonzepten auch
weg. Vorteilhaft ist, dass keine Synchronisation zwischen Instanzen aus lokalem Informations-
system und lokaler Produktontologie notwendig wird. F¨
ur die Erstellung lokaler Produkton-
tologien ist eine Zusammenarbeit zwischen Dom¨
anenexperten und Datenbankadministratoren
der einzelnen lokalen Informationssysteme erforderlich. Die Modellierung von Schemakonzepten
kann durch Knowledge Engineers unterst¨
utzt werden. Letztere sind Wissenstr¨
ager, die mit der
Modellierung von Ontologien vertraut sind und die Erfahrungen f¨
ur die Abbildung von Schema-
konzepten unterschiedlicher Datenmodellierungssprachen besitzen.
Tabelle 6.1 fasst die wesentlichen Eigenschaften eines lokalen Informationssystems und einer
lokalen Produktontologie sowie die Abbildung zwischen ihnen zusammen.
lokales
Informationssystem
lokale
Produktontologie Abbildung
Sichtbarkeit privat ¨
offentlich ¨
offentlich
Verantwortlichkeit Datenbankadministrator Dom¨
anenexperte Datenbankadministrator,
Dom¨
anenexperte
Datenmodell beliebig Ontologie abh¨
angig vom lokalen
Informationssystem
Tabelle 6.1.: Eigenschaften lokaler Informationssysteme und Produktontologien
Im Folgenden werden die einzelnen Produktdatenintegrationsebenen n¨
aher erl¨
autert.
Produktdatenintegrationsebene 1: Product Data Collection (PDC)
Die oberste Produktdatenintegrationsebene umfasst diejenigen Schemakonzepte aus lokalen In-
formationssystemen, die einen Kontext, d.h. einen G¨
ultigkeitsbereich f¨
ur Produktdaten, definie-
ren. Der Kontext von Produktdaten in der Produktentwicklung kann in den lokalen Informati-
onssystemen unterschiedlich definiert sein:
•Produkt: Ist der Kontext ein Produkt, gelten Produktdaten f¨
ur ein spezifisches Produkt
und seine Varianten.
•Plattform: Eine Plattform definiert einen Kontext, der sich ¨
uber mehrere Produkte er-
streckt. Um die Entwicklungskosten f¨
ur ein Produkt zu reduzieren, ist es im Automo-
bilbereich ¨
ublich, dass Produkte auf gemeinsamen Plattformen entwickelt werden. Unter
einer Plattform ist eine technische Basis, etwa Teile der Karosserie oder das Fahrwerk, zu
106
6.2. Manuelle Schemaintegration
verstehen, die von mehreren Produkten verwendet werden. Dass heißt, ein Produktdaten-
aspekt f¨
ur mehrere Produkte wird gleichzeitig entwickelt bzw. kann in mehreren Produkten
wiederverwendet werden.
•Projekt: Ist ein allgemeiner Begriff und der Kontext kann unterschiedlich definiert sein.
Abbildung 6.4 illustriert schematisch einen Datenmodellausschnitt mit Schemakonzepten und
Instanzen zweier lokaler Produktontologien. In Abbildung 6.4a ist der Kontext der Produktdaten
durch eine Plattform gegeben, w¨
ahrend in Abbildung 6.4b ein Produkt den Kontext bildet.
Abbildung 6.4.: Produktdatenintegrationsebene: PDC
Werden die Produktontologien aus Abbildung 6.4a und 6.4b integriert, k¨
onnen ggf. Korre-
spondenzen zwischen einigen Artefakten aus Local Product Ontology A und Local Product
Ontology B herstellt werden. Jedoch k¨
onnen f¨
ur einige Artefakte aus Local Product Ontology
Akeine Entsprechungen in Local Product Ontology gefunden werden, da Local Product
Ontology A mehrere Produkte beschreibt, w¨
ahrend Local Product Ontology A nur ein Pro-
dukt umfasst.
Um eine m¨
oglichst automatische Integration von Artefakten zu erm¨
oglichen, muss der Inte-
gratonsprozess ¨
uberwacht werden. Dazu sind Metriken, etwa zur Vollst¨
andigkeit einer Integra-
tion, notwendig. Wir definieren die Vollst¨
andigkeit der Integration einer lokalen Produkton-
tologie als den Quotienten der Instanzen, f¨
ur die entsprechende Instanzen in einer globalen
Produktontologie gefunden worden sind zur Menge aller Instanzen einer lokalen Produkton-
tologie. Soll die Vollst¨
andigkeit f¨
ur die Integration von Local Product Ontology A in Local
Product Ontology B bestimmt werden, wird das Ergebnis verf¨
alscht, da f¨
ur einige Instanzen
aus Local Product Ontology A nie Entsprechungen in Local Product Ontology B gefunden
werden k¨
onnen, da es sich um mehrere Produkte handelt.
Folglich wird die Integration von Produktdatenn vereinfacht, wenn die zu integrierenden lokalen
Produktontologien den selben Kontext verwenden. Dazu werden im PROCEED-Rahmenwerk der
Produktkontext f¨
ur lokale und globale Produktontologien gew¨
ahlt. Besitzt ein lokales Informati-
onssystem eine abweichende Aggregation, etwa eine Plattform, bei der Produktdaten aggregiert
werden, die f¨
ur mehrere Produkte g¨
ultig sind, muss im ETL-Prozess von einem lokalen In-
107
6. Integration heterogener Produktdaten
formationssystem in eine entsprechende Produktontologie eine Transformation bzw. Selektion
stattfinden.
Produktdatenintegrationsebene 2: Object-Integrationsebene
Die zweite Produktdatenintegrationsebene ist die Object-Ebene. Produkte setzen sich aus einer
Vielzahl an Bauteilen zusammen (vgl. Abschnitt 2.2.1), die entweder atomar oder zusammenge-
setzt sind. W¨
ahrend atomare Bauteile nicht weiter zerlegt werden, bestehen zusammengesetzte
Bauteile aus weiteren Unterbauteilen. Die vorliegende Arbeit fokussiert auf atomare Bauteile,
d.h. Bauteile, die eine eindeutige, global g¨
ultige Bauteilnummer besitzen und in einer St¨
uckliste
referenziert werden. F¨
ur jedes dieser Bauteile werden in lokalen Informationssystemen entspre-
chende Produktdaten verwaltet. Diese Informationssysteme k¨
onnen sowohl f¨
ur einen spezifischen
Produktdatenaspekt dienen oder mehrere Produktdaten abdecken. In der Object-Ebene werden
Schemakonzepte f¨
ur die verschiedenen Produktdaten verwaltet.
Abbildung 6.5 illustriert die obersten zwei Produktdatenintegrationsebenen einer lokalen Pro-
duktontologie. Die PDC-Integrationsebene enth¨
alt das Schemakonzept Product,w
¨
ahrend in der
Object-Integrationsebene zwei Produktdaten als Schemakonzepte Software und Hardware mo-
delliert sind.
Abbildung 6.5.: Produktdatenintegrationsebene: Object
F¨
ur die Integration ist die Dokumentation derjenigen Produktdaten essentiell, die durch ein
Schemakonzept in der Object-Integrationsebene repr¨
asentiert sind. Werden f¨
ur die Dokumen-
tation von Produktdatenn in lokalen Produktontologien global definierte Begriffe verwendet,
kann die Integration von Schemakonzepten unterst¨
utzt werden. Korrespondierende Schemakon-
zepte k¨
onnen so automatisch ermittelt werden und als Vorschl¨
age f¨
ur die manuelle Integration
von Schemakonzepten durch Integrations- und Dom¨
anenexperten dienen. Dazu wird jedes Sche-
makonzept der Object-Integrationsebene mit einem Produktdatenaspekt aus einem globalen
Repository versehen.
Produktdatenintegrationsebene 3: Variant-Integrationsebene
In der 3. Produktdatenintegrationsebene werden Variabilit¨
atskonzepte f¨
ur die einzelnen Pro-
duktdaten dokumentiert. Produkte werden in unterschiedlichen Varianten angeboten, um un-
108
6.2. Manuelle Schemaintegration
terschiedlichen Kundenw¨
unschen (Ausstattungsmerkmale) gerecht zu werden. Dar¨
uber hinaus
gibt es unterschiedliche gesetzliche Rahmenbedingungen und Regelungen, die l¨
anderspezifische
Produktvarianten erforderlich machen [HBR08].
Variabilit¨
at untergliedert sich in interne und externe Variabilit¨
at. Letztere ist durch den Nut-
zer eines Produktes erlebbar, etwa durch unterschiedliche Funktionalit¨
aten, Formen und Farben
eines Produktes. Interne Variabilit¨
at bezeichnet unterschiedliche Varianten, die in Informations-
systemen dokumentiert sind, jedoch nicht zu unterschiedlichen Produktvarianten f¨
uhren. So kann
beispielsweise ein Bauteil von mehreren Zulieferern hergestellt werden, die sich im Einkaufspreis
unterscheiden, deren Funktionalit¨
at aber identisch ist.
Diese unterschiedlichen Arten von Variabilit¨
at spiegelt sich in den Produktdatenn der verschie-
denen Informationssysteme der Produktentwicklung wider. Auf Grund der unterschiedlichen
Anforderungen und Sichtweisen der Entwickler wird Variabilit¨
at durch verschiedene Mecha-
nismen realisiert. Im Folgenden werden alternative Mechanismen f¨
ur die Repr¨
asentation von
Produktdatenvariabilit¨
at anhand unterschiedlicher Bereiche der Produktentwicklung erl¨
autert.
Requirements Engineering. Am Anfang der Produktentwicklung werden Anforderungen an
Bauteile in Anforderungsdokumenten spezifiziert. Diese Dokumente dienen der Auftragsvergabe
an externe Lieferanten und stellen die Grundlage der Produktentwicklung dar. Anforderungsdo-
kumente beschreiben funktionale und nichtfunktionale Anforderungen f¨
ur alle m¨
oglichen Bau-
teilvarianten. Letztere sind physische Erzeugnisse mit eindeutigen Sachnummern,diederPro-
duktionsplanung dienen und in St¨
ucklisten verwendet werden (siehe Abschnitt 2.2.2).
Bauteile k¨
onnen sowohl auf Hardware- als auch Software-Ebene eine gewisse Variabilit¨
at auf-
weisen. Physisch kann ein Bauteil, etwa ein Außenspiegel, unterschiedliche Formen und Farben
(externe Variabilit¨
at) besitzen und aus verschiedenen Materialien bestehen.
Alle g¨
ultigen Konfigurationen eines 150-Prozent Modells1werden in einem Feature-Modell do-
kumentiert (vgl. Abschnitt 2.2.3). Eine g¨
ultige Variante wird aus dem 150-Prozent Modell durch
Konfiguration abgeleitet.
Konstruktion. F¨
ur die Konstruktion von Bauteilen sind sowohl zweidimensionale Zeichnun-
gen als auch dreidimensionale Geometrien (Volumenmodelle) notwendig, die ¨
ublicherweise mit
Hilfe von CAD-Systemen erstellt werden. Ein Teilbereich der Konstruktion ist die Varianten-
konstruktion, bei der bestehenden Konstruktionen ¨
ubernommen und Details weggelassen oder
erg¨
anzt werden. Eine M¨
oglichkeit besteht darin, Zeichnungen mit Parametern zu erstellen, die
variabel sind. Durch das Ver¨
andern dieser Parameter lassen sich, gest¨
utzt durch CAD-Systeme,
unterschiedliche Bauteile generieren bzw. erstellen. Dieses Vorgehen wird auch als parametrische
Konstruktion bzw. parametrische Generierung bezeichnet. D.h. f¨
ur jede geometrische Bauteil-
variante wird eine explizite Zeichnung bzw. ein explizites geometrisches Modell erstellt.
W¨
ahrend f¨
ur Bauteile, die nur aus mechanischen Teilen bestehen, die unterschiedlichen geo-
metrischen Varianten explizit in einem CAD-System modelliert werden2, existiert f¨
ur Bauteile,
die auch Software enthalten, meistens nur ein Software- bzw. ein Funktionsmodell, welches alle
m¨
oglichen Varianten umfasst.
1Ein 150-Prozent Modell bezeichnet ein Modell, das alle variablen Anteile inklusive der m¨
oglichen Auspr¨
agungen
letzter beinhaltet.
2Die explizite Modellierung von geometrischen Bauteilvarianten ist notwendig, da diese Grundlagen f¨
ur DMU-
Untersuchungen (Digital Mock-Up) sind. Damit sind rechnergest¨
utzte Simulationsverfahren gemeint, mit denen
etwa Einbaukollisionen verschiedener Produktkonfigurationen ermittelt werden.
109
6. Integration heterogener Produktdaten
Softwareentwicklung. Bauteile, die Software umfassen (z.B. Steuerger¨
ate), k¨
onnen unterschied-
liche Funktionalit¨
at realisieren. H¨
aufig wird die Variabilit¨
at eines Steuerger¨
ates ¨
uber Codier-
parameter realisiert, so dass f¨
ur unterschiedliche Bauteilvarianten die gleiche Hardware- und
Software-Basis verwendet werden kann. Die Konfiguration einer bestimmten Bauteilvariante
erfolgt mittels Konfiguration verschiedener Parameter, deren Festlegung das Ausf¨
uhrungsver-
halten der Software beeinflusst.
Die Modellierung von Softwarevariabilit¨
at l¨
asst sich etwa mit Featuremodellen (vgl. Abschnitt
2.2.3) realisieren. Eine weitere Methode stellt Decision Modeling dar. Dabei m¨
ussen dom¨
anen-
spezifische Fragen mit Hilfe einer Menge m¨
oglicher Antworten/Entscheidungen beantwortet wer-
den. Die Entscheidungen sind mit Variationspunkten verbunden. Jede Entscheidung besitzt eine
Beschreibung mit den Auswirkungen, welche die Auswahl einer Entscheidung auf Artefakte ha-
ben soll [CGR`12]. W¨
ahrend die Featuremodellierung auf das Verst¨
andnis der m¨
oglichen Featu-
res abzielt, liegt der Fokus beim Decision Modeling auf der Ableitung von Entscheidungen aus
Produktkonfigurationen.
Neben der Modellierung von Variabilit¨
at sind die unterschiedlichen M¨
oglichkeiten f¨
ur deren
Realisierung ein entscheidendes Merkmal von Variabilit¨
atsmechanismen. Variabilit¨
at l¨
asst sich
in der Softwareentwicklung zu unterschiedlichen Zeitpunkten realisieren. Zu den verschiedenen
Zeitpunkten z¨
ahlen etwa die Pr¨
akompilierzeit,dieKompilierung,dasLinken oder das Deploy-
ment [CBK13]. Auch innerhalb der Softwaremodelle bzw. Entwicklungsartefakte (z.B. Quell-,
Bin¨
ar- und Konfigurationsdateien) l¨
asst sich Variabilit¨
at mittels unterschiedlicher Konstrukte
realisieren. Beispiele f¨
ur Mechanismen von Programmiersprachen sind Vererbung, Generatoren,
Parameter, Pr¨
aprozessoranweisungen und Laufzeitvariablen. Diese sind entweder Bestandteil
von Programmiersprachen oder werden von Applikationen (z.B. Compiler, Generatoren) reali-
siert. Eine detaillierte Analyse zur Modellierung und Realisierung von Variabilit¨
at findet sich in
[CBK13].
F¨
ur die Softwareentwicklung von Steuerger¨
aten gibt es zwei verschiedene Herangehensweisen:
Modellbasierte und Codebasierte Softwareentwicklung. Bei modellbasierter Softwareentwicklung
werden zun¨
achst Modelle definiert, die mit Hilfe von Codegeneratoren dann Softwareartefak-
te erzeugen (z.B. Schnittstellen). Letztere werden anschließend um Featureimplementierungen
durch Softwareentwickler vervollst¨
andigt. Beim zweiten Ansatz entf¨
allt die Modellierung und
Entwickler realisieren Features ohne zus¨
atzlichen Generierungsschritt.
Eine f¨
ur die Entwicklung eingebetteter Systeme etablierte Software-Entwicklungsmethode ist
AUTOSAR3,dasdieM
¨
oglichkeit bietet, Softwarevariabilit¨
at durch Variationspunkte (Variation
Points) und Featuremodelle (Feature Models) zu beschreiben. F¨
ur jeden Variationspunkt einer
Systemspezifikation muss in AUTOSAR der Aufl¨
osungszeitpunkt definiert werden. Dies kann
zur Systemzeit sein, w¨
ahrend der Codegenerierung, vor dem Compilieren, w¨
ahrend dem Linken
oder nach dem Bauen [SWB12].
St¨uckliste. Wie bereits in Abschnitt 2.2.3 erw¨
ahnt, ist die St¨
uckliste das zentrale Informati-
onssystem f¨
ur die Herstellung von Produkten. In der St¨
uckliste sind alle m¨
oglichen bestellbaren
Bauteilvarianten dokumentiert, die f¨
ur die Herstellung alle Produktvarianten notwendig sind.
Die Auswahl entsprechender Bauteilvarianten erfolgt mittels Konfiguration.
3AUTomotive Open System ARchitecture
110
6.2. Manuelle Schemaintegration
Aspekt Variabilit¨
atsmechanismus
Requirements Engineering Alle Varianten werden in einem Anforderungsdokument
dokumentiert.
Konstruktion
A: 1 Modell f¨
ur jede Variante angelegt
B: Ein Modell enth¨
alt alle Varianten
Ein Modell f¨
ur jede geometrische Variante
Softwareentwicklung Codierparameter, Features-Flags, Vererbung
Test Siehe Requirements Engineering
Tabelle 6.2.: Variabilit¨
atsmechanismen f¨
ur verschiedene Produktdaten
Klassifikation unterschiedlicher Variabilit¨atsmechanismen. Tabelle 6.3 fasst die beschriebe-
nen Mechanismen f¨
ur die Modellierung und Realisierung von Variabilit¨
at in der Produktentwick-
lung zusammen. Die unterschiedlichen Beispiele verdeutlichen, dass Variabilit¨
at von Produktda-
ten auf unterschiedliche Art und Weise realisiert werden kann. Weiter wird ersichtlich, dass diese
unterschiedlichen Methodiken explizit in lokalen Produktontologien in Form von Schemakonzep-
ten dokumentiert werden m¨
ussen, um die Integration unterschiedlicher Methoden erm¨
oglichen
zu k¨
onnen.
Fasst man die Beispiele zusammen, ergeben sich zwei Variabilit¨
atstypen f¨
ur Produktdaten:
•Variabilit¨
atstyp 1: Ein Artefakt (z.B. Anforderungsdokument, Konstruktionszeichnung,
geometrisches Modell, Quellcode) umfasst alle m¨
oglichen Varianten. Eine spezifische Vari-
ante wird durch Konfiguration abgeleitet. Dazu sind die variablen Bereiche des Artefaktes
durch Variabilit¨
atspunkte gekennzeichnet. Dass heißt, die Variabilit¨
at im Artefakt ist noch
nicht aufgel¨
ost. Variabilit¨
atspunkte k¨
onnen f¨
ur jeden Produktdatenaspekt unterschiedlich
realisiert sein. In der Softwareentwicklung etwa k¨
onnen Feature-Flags [MSR13] eingesetzt
werden, um variable Anteile zu realisieren, oder in der Prozessmodellierung dem entspre-
chend sog. Anpassungspunkte (engl. adjustment parts), f¨
ur die dann jeweils variable An-
teile festgelegt sind [HBR09, ATW`15].
•Variabilit¨
atstyp 2: Beim zweiten Typ wird die Variabilit¨
at bereits w¨
ahrend der Mo-
dellierung bzw. Implementierung aufgel¨
ost. Dass heißt, dass f¨
ur alle m¨
oglichen Varianten
explizite Artefakte erstellt werden, die keine Variabilit¨
aspunkte mehr aufweisen.
Aus einem Artefakt mit dem Variabilit¨
atytyp 1 lassen sich ohne weiteres Artefakte des zweiten
Typs erzeugen. Umgekehrt ist es aufw¨
andiger, aus mehreren Typ-2 Artefakten ein Typ-1 Arte-
fakt zu erstellen. Im Detail m¨
ussen zun¨
achst die Variabilit¨
atspunkte ermittelt werden, d.h. die-
jenigen Bereiche, in denen sich die Artefakte unterscheiden. Anschließend m¨
ussen die m¨
oglichen
Konfigurationen f¨
ur die Variabilit¨
atspunkte bestimmt werden.
Auf Basis der unterschiedlichen Vorgehensweisen f¨
ur den Umgang mit Variabilit¨
at in der Pro-
duktentwicklung, definieren wir folgende Taxonomie f¨
ur das Variantenmanagement:
111
6. Integration heterogener Produktdaten
Taxonomie 1 (Variantenmanagement).
•Variantenmanagement: Umfasst alle Aktivit¨
aten, um unterschiedliche Anforderun-
gen, Eigenschaften und Funktionalit¨
aten von Produkten in den unterschiedlichen In-
formationssystemen der Produktentwicklung zu verwalten. Hierbei wird zwischen ex-
terner und interner Variabilit¨
at unterschieden.
•Variabilit¨
atspunkt: Stelle in einem Artefakt, bei der eine Auswahl zwischen ver-
schiedenen Features getroffen werden kann. G¨
ultige Kombinationen von Features f¨
ur
Variabilit¨
aspunkte in einem Artefakt werden als Konfiguration bezeichnet.
•Feature: Funktionalit¨
at f¨
ur einen Variabilit¨
atspunkt, die entweder optional oder ob-
ligat ist.
•Variante: Konfiguriertes Artefakt, d.h. f¨
ur alle Variabilit¨
atspunkte wurden g¨
ultige
Belegungen.
•Variantenkollektion: Menge aller Varianten eines Artefaktes.
•Variationszeitpunkt: Zeitpunkt an dem aus der Variantenkollektion eine spezifische
Variante ausgew¨
ahlt wird.
•Variabilit¨
atsmechanismus: Technische Realisierung von Variabilit¨
at eines Artefak-
tes f¨
ur einen Produktdatenaspekt.
Informationen zu den einzelnen Variabilit¨
atsmechanismen werden in einer lokalen Produkton-
tologie dokumentiert, um eine anschließende Integration in eine globale Produktontologie zu
erleichtern. Durch die Spezifikation der Art von Variabilit¨
atsmechanismus lassen sich Aussagen
¨
uber semantische Beziehungen integrierter Artefakte treffen. Abbildung 6.6 illustriert eine lokale
Produktontologie. Der Variabilit¨
atstyp f¨
ur das Schemakonzept Part Variant in Abbildung 6.6
hat den Variabilit¨
atstyp 1, d.h. jede Instanz (inklusive hinterlegtem Artefakt) des Schemakon-
zeptes beschreibt genau eine Variante.
Abbildung 6.6.: Produktdatenintegrationsebene: Variant
112
6.2. Manuelle Schemaintegration
Produktdatenintegrationsebene 4: Version-Integrationsebene
Wie in Abschnitt 2.2.3 erl¨
autert, erfolgt die Entwicklung von Produkten system- und kompo-
nentenorientiert durch parallel entwickelnde Teams. Elementarer Gedanken der Produktentwick-
lung ist die sukzessive Verfeinerung des Reifegrades von Bauteilen. D.h. in den fr¨
uhen Phasen
der Entwicklung werden zun¨
achst Grund- und Sicherheitsfunktionen von Bauteilen entwickelt
und abgesichert. Im weiteren Verlauf werden die anderen Funktionalit¨
aten realisiert. Dar¨
uber
hinaus treten meist ¨
Anderungen am System- und Komponentendesign auf, etwa zwecks Feh-
lerbeseitigung, Design-¨
Anderungen infolge technischer Limitationen oder der Umsetzung neu
aufkommender Anforderungen oder neuer gesetzlicher Rahmenbedingungen [Hal10]. Durch das
komplexe Beziehungsgeflecht zwischen Systemen und Komponenten wirken sich ¨
Anderungen an
einemSystemm
¨
oglicherweise auf weitere Systeme aus. Folglich ist ein globaler Prozess (engl.
change management) notwendig, der diese ¨
Anderungen koordiniert.
Soll ein Bauteil ge¨
andert werden, wird ein ¨
Anderungsantrag (engl. change requests) gestellt
und der ¨
Anderungsprozess [BRB05] gestartet. Der Antrag dient der Koordination und Nach-
verfolgung der ¨
Anderung und enth¨
alt die ¨
Anderungsgr¨
unde sowie Angaben zum Antragssteller.
Ein weiterer Grund f¨
ur die revisionssichere Dokumentation von ¨
Anderungen ist die Einhaltung
gesetzlicher Anforderungen (z.B. Produkthaftung). Um die Auswirkungen einer ¨
Anderung zu
bestimmen, wird letztere von verschiedenen Verantwortlichen des Entwicklungsprozesses bewer-
tet (z.B. Systemverantwortliche, Einkaufs- und Produktionsverantwortliche) und anschließend
entweder zur Umsetzung freigegeben oder abgelehnt.
¨
Anderungen spiegeln sich in lokalen Informationssystemen in unterschiedlichen Artefaktversio-
nen von Produktdatenn wider. Obwohl Artefaktversionen von Produktdatenn zu unterschiedli-
chen Zeitpunkten im Entwicklungsprozess entstehen k¨
onnen, m¨
ussen diese ¨
uber die verschiede-
nen Informationssystemen hinweg korreliert werden. Nur so kann l¨
uckenlos nachvollzogen wer-
den, ob genehmigte ¨
Anderungsantr¨
age in den betroffenen Informationssystemen auch technisch
umgesetzt worden sind.
Um Versionierung zu realisieren, m¨
ussen Mechanismen zur eindeutigen Identifizierung von ¨
An-
derungen eines Artefaktes verf¨
ugbar sein. Dies geschieht in der Regel durch eine eindeutige
Versionsnummer [EN09]. Versionierte Artefakte stehen in Beziehungen zueinander. Wird ein
Artefakt ge¨
andert, besitzt die neue Artefaktversion einen Verweis auf seinen Vorg¨
anger und
die alte Artefaktversion entsprechend einen Nachfolgerverweis. Eine Artefaktversion kann meh-
rere Nachfolgerversionen besitzen, die parallel zueinander existieren. Weiter muss eine Unter-
scheidung zwischen aktuell g¨
ultiger und neuester Artefaktversion stattfinden. Artefakte k¨
onnen
ge¨
andert werden, ohne dass zuvor ein ¨
Anderungsantrag erstellt wurde, etwa um die Machbar-
keit einer geplanten ¨
Anderung zu dokumentieren. Die aktuelle Artefaktversion ist demnach das
Resultat des zuletzt freigegebenen ¨
Anderungsantrags.
[CW98] beschreiben unterschiedliche Realisierungsarten f¨
ur Versionierung:
•Bei der extensionalen Versionierung werden Entwicklungsst¨
ande von Artefakten explizit
durch Anwender ”eingecheckt“.
•Bei der intensionalen Versionierung hingegen werden explizite Versionen von Artefakten
bei ¨
Anderungsantr¨
agen zugeordnet.
Zusammengefasst f¨
allt in den lokalen Informationssystemen zu den verschiedenen Entwicklungs-
phasen eine Vielzahl an Artefaktversionen an, die zeitlich aufeinander aufbauen. Die Verwaltung
113
6. Integration heterogener Produktdaten
der ¨
Anderungen an diesen Artefaktversionen wird als Versionsverwaltung bezeichnet. Sie erfolgt
in den Informationssystemen mittels unterschiedlicher Mechanismen, wobei sich die konkrete
Terminologie je nach Anwendungsdom¨
ane unterscheidet.
Im Allgemeinen muss man zwischen Versionsverwaltung f¨
ur textbasierte Daten (z.B. Quellcode)
und bin¨
aren Daten (etwa geometrische CAD-Modelle) unterscheiden. Im Folgenden wird die
Versionsverwaltung von Artefakten in der Softwareentwicklung mit Ans¨
atzen aus dem CAD-
Bereich verglichen.
Eng verbunden mit der Versionsverwaltung von Produktdaten ist das Release-Management
[MHR06]. Sein Ziel ist es, diejenigen Versionen von Artefakten zu identifizieren, die f¨
ur die Auslie-
ferung eines Produktes in einem zuvor definierten Reifegrad (z.B. Absicherung, Erprobung, Aus-
lieferung) notwendig sind. Dieser Prozess muss mit dem Konfigurations- und ¨
Anderungsmanage-
ment synchronisiert werden (siehe Abschnitt 2.2.3).
In der Softwareentwicklung werden sog. Versionskontrollsysteme (englisch Source Control Ma-
nagement System, SCM) eingesetzt [Roc75]. [CAD03] vergleicht die verschiedenen Aspekte von
SCM- und PDM-Systemen, unter anderem auch die Versionierung sowie das Release-Management
von Artefakten: Weit verbreitete Systeme sind Subversion, Git, Mercurial und ClearCase. Die
Versionierung von Quellcode und weiteren Artefakten der Softwareentwicklung geschieht auf Da-
teiebene. Die Dateien werden zentral in einem SCM-Repository gespeichert, das es erm¨
oglicht,
den zeitlichen Verlauf der Entwicklung l¨
uckenlos zu dokumentieren. Werden Dateien ge¨
andert,
l¨
asst sich ein Entwicklungsstand festhalten, indem sie in das SCM-Repository eingecheckt wer-
den. Dabei werden Metadaten (z.B. Zeit), dokumentiert. Um eine kurz Erl¨
auterung zu den
gemachten ¨
Anderungen bereitzustellen, wird eine ¨
Anderungsinformation vom Verantwortlichen
in Prosaform hinterlegt.
Wichtiges Konzept von SCM-Systemen ist das Branching. Dieses erm¨
oglicht es, von einem Ent-
wicklungsstand eine Kopie im SCM-Repository anzulegen, die parallel zum Hauptentwicklungs-
stand existiert. ¨
Anderungen an Artefakten dieses Entwicklungszweiges existieren nur dort und
beeinflussen den Hauptentwicklungsstrang nicht. Branches werden f¨
ur unterschiedliche Zwecke
genutzt. So k¨
onnen neue Funktionalit¨
aten parallel entwickelt und getest werden, ohne dabei die
Arbeiten im Hauptentwicklungsstrang zu beeintr¨
achtigen. Eine weitere M¨
oglichkeit besteht dar-
in, Softwareauslieferungen (sog. Softwarereleases) mittels Branches zu erzeugen. D.h., zu einem
Zeitpunkt wird ein Branch parallel zum Hauptentwicklungsstrang f¨
ur eine Softwareauslieferung
angelegt. Alle ¨
Anderungen, welche die Auslieferung betreffen, werden nach Erstellung des Bran-
ches nur noch auf diesem eingecheckt, w¨
ahrend die Weiterentwicklung der Software auf dem
Hauptentwicklungsstrang geschieht.
Abbildung 6.7 illustriert den Zusammenhang von Hauptentwicklungsstand, Branches und Arte-
fakten. Zun¨
achst ist der Hauptentwicklungsstrang leer, d.h. er enth¨
alt keine Artefakte. Bei 1
werden die Artefakte Aund Beingecheckt. Anschließend werden in 2
¨
Anderungen an Asowie
ein neues Artefakt Cin den Hauptentwicklungsstrang eingecheckt. Bei 3
wird ein Branch vom
Hauptentwicklungsstrang erzeugt und somit der Inhalt (die Artefakte A’,Bund C) kopiert. In 4
werden ein neues Artefakt Din den Hauptentwicklungsstrang eingecheckt und das existierende
Artefakt Centfernt. Parallel werden an 5
¨
Anderungen am Artefakt A’ sowie ein neues Artefakt
Eeingecheckt.
114
6.2. Manuelle Schemaintegration
bQGHUXQJHQ
$ %
+DXSWHQWZLFNOXQJVVWUDQJ
,QKDOW
$ %
bQGHUXQJHQ
a$ &
,QKDOW
$¶ % &
%UDQFK
,QKDOW
$¶ % &
bQGHUXQJHQ
a$ (
bQGHUXQJHQ
' &
,QKDOW
$¶ % '
/HJHQGH
$ $ a$
QHXHV
$UWHIDNW
$UWHIDNW
HQWIHUQW
$UWHIDNW
JHlQGHUW
(LQFKHFNHQ 9RUJlQJHU
,QKDOW
$¶¶ % & (
Abbildung 6.7.: Branching in SCM-Systemen
Beispiele f¨
ur Artefakte in der Softwareentwicklung sind Quelldateien, Konfigurationen und Skrip-
te. Da diese textbasiert sind, lassen sich ¨
Anderungen durch Text¨
anderungsoperationen aus-
dr¨
ucken. Das heißt, bei ¨
Anderungen von Artefakten wird nicht das gesamte Artefakt, sondern
nur die ¨
Anderung zum letzen eingecheckten Stand im SCM-System gespeichert. So wird die
komplette ¨
Anderungshistorie von Artefakten dokumentiert.
Branches k¨
onnen in den Hauptentwicklungsstrang zur¨
uckgef¨
uhrt werden, was als Merging be-
zeichnet wird. Beim Merging wird versucht, den Inhalt von Artefakten auf Textebene automa-
tisch zu integrieren. Ist dies f¨
ur ein Artefakt nicht m¨
oglich, muss der Endbenutzer eingreifen und
entscheiden, was bei Integrationskonflikten geschehen soll. Zur Aufl¨
osung von Konflikten gibt
es zwei M¨
oglichkeiten: Entweder wird das Artefakt aus dem Hauptentwicklungsstrang behalten
und ¨
Anderungen aus dem Branch verworfen oder umgekehrt. Da das Merging von Artefakten
zeilenweise f¨
ur Textdokumente erfolgt, ist es m¨
oglich, dass mehrere Entwickler parallel am selben
Artefakt arbeiten k¨
onnen.
In Abbildung 6.8 wird das Mergen eines Branches zur¨
uck in den Hauptentwicklungsstrang ver-
deutlicht. Zum Zeitpunkt 1
wird ein Branch des Hauptentwicklungsstranges erzeugt und somit
die zu diesem Zeitpunkt vorhandenen Artefakte kopiert. W¨
ahrend bei 2
die ¨
Anderung des
Artefakts Asowie ein neues Artefakt Eim Branch eingecheckt werden, werden im Hauptent-
wicklungsstrang das Artefakt Cgel¨
oscht und ein neues Artefakt Deingecheckt. Bei 4
erfolgt
das Mergen des Branches zur¨
uck in den Hauptentwicklungsstrang. Lediglich die Artefakte A’
des Hauptentwicklungsstranges und A’’ aus dem Branch m¨
ussen integriert werden. Sie erzeugen
115
6. Integration heterogener Produktdaten
somit A’’’,w
¨
ahrend Cund Din den Hauptentwicklungsstrang kopiert werden und der Branch
anschließend gel¨
oscht wird.
+DXSWHQWZLFNOXQJVVWUDQJ
%UDQFK
,QKDOW
$¶ % &
bQGHUXQJHQ
a$ (
bQGHUXQJHQ
' &
,QKDOW
$¶ % '
/HJHQGH
$ $ a$
QHXHV
$UWHIDNW
$UWHIDNW
HQWIHUQW
$UWHIDNW
JHlQGHUW
(LQFKHFNHQ 9RUJlQJHU %UDQFK
,QKDOW
$¶¶¶ % ' (
,QKDOW
$¶¶ % & (
,QKDOW
$¶ % &
0HUJH
&
Abbildung 6.8.: Mergen eines Branches zur¨
uck in den Hautpentwicklungsstrang
W¨
ahrend SCM-Systeme die M¨
oglichkeit bieten, Entwicklungsst¨
ande mit Tags zu versehen, die
eine semantische Beschreibung darstellen, ist das Release-Management von Software ein nach-
gelagerter Prozess und nicht Hauptbestandteil eines SCM-Systems.
W¨
ahrend in der Softwareentwicklung ¨
uberwiegend textbasierte Artefakte verwendet werden,
kommen in der Produktentwicklung unterschiedliche Formate (z.B. XML oder Bin¨
ar-Dateien)
zum Einsatz. Einen zentralen Produktdatenaspekt stellen geometrische Modelle dar, die in PDM-
Systemen verwaltet werden (siehe Abschnitt 2.2.1). Im Gegensatz zu SCM-Systemen, werden in
PDM-Systemen auch die Beziehungen zwischen Artefakten dokumentiert. Auf Grund der unter-
schiedlichen Formate ist das Mergen von Artefakten, wie bei SCM-Systemen, nicht ohne weiteres
m¨
oglich. Folglich k¨
onnen an einem Artefakt nicht mehrere Personen gleichzeitig arbeiten. Anders
als SCM-Systeme ist das Release-Management zentraler Bestandteil von PDM-Systemen.
Beispiel 18 (PDM Versionierung). Abbildung 6.9a illustriert die Versionierung von
Artefakten in einem PDM-System. Artefakt A setzt sich aus Artefakt B und Artefakt C
zusammen. Zu letzteren existieren unterschiedliche Versionen (V1,V2 und V3).
116
6.2. Manuelle Schemaintegration
Abbildung 6.9.: Versioning von Artefakten in SCM- und PDM-Systemen
Die Beispiele aus Abbildung 6.9 illustrieren zwei M¨
oglichkeiten, wie die zeitlichen Entwicklungs-
st¨
ande von Produktdatenn gespeichert werden k¨
onnen. Die Entscheidung, wann ein Entwick-
lungsstand festgehalten werden soll, kann f¨
ur jedes Informationssystem bzw. jedem Produktda-
tenaspekt unterschiedlich sein. Wie erw¨
ahnt, existieren in der Produktentwicklung ¨
ubergeordnete
Synchronisationspunkte (vgl. Abschnitt 2.2.3). Obwohl Produktdaten in den einzelnen Informa-
tionssystemen unterschiedlich versioniert sein k¨
onnen, m¨
ussen zu den Synchronisationspunkten
entsprechende Entwicklungsst¨
ande f¨
ur eine Integration identifizierbar sein.
Im weiteren Verlauf der Arbeit wird folgende Taxonomie f¨
ur die Versionierung von Produktdaten
verwendet.
Taxonomie 2 (Versionsmanagement).
•Artefakt: Dokument, Modell oder Datei von Produktdaten, das ¨
Anderungen unter-
liegt.
•Version: Beschreibt den zeitlichen Bezug eines Artefaktes.
•Versionsnummer: Eindeutige Nummer zwecks Unterscheidung von Versionen.
•¨
Anderungsantrag: ¨
Anderungsvorhaben f¨
ur ein oder mehrere Bauteile. Dient gleich-
zeitig der Dokumentation von ¨
Anderungen, um eine durchg¨
angige Nachvollziehbarkeit
zu erm¨
oglichen.
•Baseline: Gemeinsamer, akzeptierter Zustand von Artefakten zu einem Zeitpunkt
durch alle beteiligten Verantwortlichen eines Produktes. Die Baseline dient als Grund-
lage f¨
ur die Definition von ¨
Anderungsantr¨
agen. Ein akzeptierter ¨
Anderungsantrag
¨
andert den Zustand einer Baseline.
•Vorg¨
anger und Nachfolger beschreiben die zeitliche Beziehungen zwischen Arte-
faktversionen. Vorg¨
anger einer Version ist ein Artefakt, das zeitlich vorher angelegt
117
6. Integration heterogener Produktdaten
wurde. Analog ist ein Nachfolger diejenige Version, die zeitlich nach einem Artefakt
erstellt wurde.
•Es wird zwischen aktuell g¨
ultiger und zuletzt erstellter Version unterschieden.
Zusammengefasst muss ein lokales Informationssystem folgende Eigenschaften erf¨
ullen, um in
eine lokale Produktontologie abgebildet werden zu k¨
onnen:
•Das lokale Informationssystem muss mindestens einen Produktdatenaspekt (z.B. Anfor-
derungen, Zeichnungen) enthalten,
•Bauteile sind zu Kollektionen zusammengefasst.
•Variabilit¨
at und Versionierung der Produktdaten m¨
ussen dokumentieren werden.
Formalisierung der Produktontologie
Wir definieren eine Produktontologie wie folgt:
Definition 21 (Produktontologie). Eine Produktontologie mit einem eindeutigen Be-
zeichner xist ein Tupel PO
x”pPDIL,SC
x,Ind
x, Attrx, AttrV alx, MetaAttrx,
MetaAttrV alxq,mit
•PDIL
x“tpdc, object, variant, versionuist die Menge der Produktdatenintegrations-
ebenen,
•SCx“tsc1,...,sc
nudie Menge der Schemakonzepte,
•Indx“tind1,...,ind
kudie Menge der Individuals der Schemakonzepte,
•Attrx“tattr1,...,attr
mudie Menge der Attribute von Schemakonzepten,
•AttrV alx“tattrV al1,...,attrVal
ludie Menge der Attributwerte der Individuals,
•MetaAttrx“tma1,...,ma
pudie Menge der Metaattribute f¨
ur jedes Artefakt der
Produktontologie (z.B. Schemakonzept, Instanz, Attribut),
•MetaAttrV alx“tmav1,...mav
qudie Menge der Werte f¨
ur Metaattribute
Die Struktur einer Produktontologie ist folgendermaßen definiert:
Definition 22 (Struktur einer Produktontologie). Auf diesen Mengen seien weiter
folgende Relationen definiert:
•ppdil1,pdil
2qPisAbovex“tppdc, objectq,pobject, variantq,pvariant,versionqu mit
pdil1,pdil
2PPDIL die hierarchische Ordnung der Produktdatenintegrationsebenen,
•ppdil1,pdil
2qPisBelowX“tpobject, pdcq,pvariant,objectq,pversion,variantqu mit
pdil1,pdil
2PPDIL,
•ppdil, scqPhasConceptxmit pdil PPDIL und sc PSCxdie Zuordnung von Schema-
konzepten zu Produktdatenintegrationsebenen
118
6.2. Manuelle Schemaintegration
•psca,sc
bqPscAbovexdie hierarchische Ordnung zweier Schemakonzepte sca,sc
bPSCx,
wobei scain der PDIL ¨
uber scbliegt: pdila,pdil
bPPDIL
MhasConceptxppdila,sc
aq
und hasConceptxppdilb,sc
bqgilt isAboveppdila,pdil
bq
•psca,sc
bqPscBelowxdie hierarchische Ordnung zweier Schemakonzepte sca,sc
bP
SCx,wobeiscain der PDIL unter scbliegt: pdila,pdil
bPPDIL
M,
hasConceptxppdila,sc
aqund hasConceptxppdilb,sc
bqgilt isBelowppdila,pdil
bq
•pinda,ind
bqPindAbove die hierarchische Ordnung zweier Instanzen inda,ind
bPIndx,
wobei erste zu einem Schemakonzept geh¨
ort, welches in einer Integrationsebene ¨
uberhalb
des Schemakonzeptes f¨
ur indbliegt.
•pinda,ind
bqPindBelow die hierarchische Ordnung zweier Instanzen inda,ind
bPIndx,
wobei erste zu einem Schemakonzept geh¨
ort, welches in einer Integrationsebene unter-
halb des Schemakonzeptes f¨
ur indbliegt.
•psc, attrqPhasAttributexmit sc PSCxund attr PAttrxdie Zuordnung von Attribu-
ten zu Schemakonzepten,
•psc, indqPhasIndividualxmit sc PSCxund ind PIndxdie Zuordnung von Individu-
als zu Schemakonzepten,
•pind, attrV alqPhasV aluexmit ind PIndxund attrV al PAttrV alxdie Zuordnung
von Attributwerten zu Individuals,
•pattrV al, attrqPreferencesxmit attrV al PAttrV alxund attr PAttrxdie Zuordnung
von Attributwerten zu Attributen.
•pindversion1,ind
version2qPisP redecessorxmit indversion1,ind
version2PIndversion
xdie
Zuordnung von Vorg¨
angerbeziehungen zwischen Individuals der Version-Ebene,
•pindversion1,ind
version2qPisSuccessorxmit indversion1,ind
version2PIndversion
xdie
Zuordnung von Nachfolgerbeziehungen zwischen Individuals der Version-Ebene,
•px, ma, mavqPhasMetaAttrV alxmit xPSCxŤIndxŤAttrxŤAttrV alxund ma P
MetaAttrxsowie mav PMetaAttrV alxdie Zuordnung von Metaattributwerten zu
Elementen in der Produktontologie.
Definition 23 (Hilfsrelationen). Auf Basis der Relationen werden weiter folgende Hilfs-
mengen definiert:
•SCpdil
x“tsc PSCx|Dppdil, scqPhasConceptxumit pdil PPDIL die Menge der
Schemakonzepte einer Produktdatenintegrationsebene,
•Indpdil
x“tind PIndx|@sc PSCx@ind PIndx:ppdil, scqPhasConceptx_psc, indqP
hasIndividualxumit pdil PPDIL die Menge der Individuals einer Produktdatenin-
tegrationsebene
119
6. Integration heterogener Produktdaten
Strukturelle Konsistenzbedingungen
Zwischen den Produktdatenintegrationsebenen existieren strukturelle Konsistenzbedingungen,
die bei der Modellierung von Schemakonzepten eingehalten werden m¨
ussen. Die strukturelle
Konsistenz bezieht sich sowohl auf Beziehungen zwischen Schemakonzepten als auch die Instan-
zen dieser Schamkonzepte.
Definition 24 (Strukturelle Konsistenz einer Produktontologie). Eine lokale Pro-
duktontologie ist ein Tupel
PO
L”pPDIL
L,SC
L,Ind
L, AttrL, AttrV alL, MetaAttrL, MetaAttrV alLqaund struktu-
rell konsistent, wenn folgende Bedingungen erf¨
ullt sind:
•Schemakonsistenzregel 1: Jede Produktdatenintegrationsebene besitzt mindestens
ein Schemakonzept, welche untereinander verbunden sind. Ein Schemakonzept kann
nur mit einem Schemakonzept verbunden werden, welches sich auf einer darunter
liegenden Produktdatenintegrationsebene befindet:
@pdil PPDIL
LDsc PSCLDpphil, scqPhasConceptLund @psc1,sc
2qPSCCLP O mit
sc1,sc
2PSCLgilt: Dpdil1,pdil
2PPDIL
Lmit pdil1‰pdil2und
ppdil1,pdil
2qPisAboveLund ppdil2,pdil
1qPisBelowL
Dppdil1,sc
1qPhasConceptL,Dppdil2,sc
2qPhasConceptL
•Schemakonsistenzregel 2: F¨
ur jedes Schemakonzept der Variant-Ebene ist der Va-
riabilit¨
atstyp definiert:
@sc PSCvariant
LDpsc, variantT ypeqPhasAttributeL
•Schemakonsistenzregel 3: Zus¨
atzlich ist der Versionierungstyp f¨
ur jedes Sche-
makonzept der Version-Ebene definiert:
@sc PSCversion
LDpsc, versionT ypeqPhasAttributeL
•Instanzkonsistenzregel 1: Die Instanzen einer globalen Produktontologie sind zwi-
schen den Produktdatenintegrationsebenen analog zu ihren Schemakonzepten ¨
uber
Beziehungen miteinander verkn¨
upft. Das heißt, dass f¨
ur alle Instanzen außer der PDC-
Ebene eine Beziehung zu einer Instanz auf der dar¨
uberliegenden Produktdatenintegra-
tionsebene existiert:
•Instanzkonsistenzregel 2: Die Instanzen eines Schemakonzeptes auf der Version-
Ebene sind durch Vorg¨
anger- und Nachfolger-Beziehungen geordnet:
Dpind1,ind
2qPisP redecessorLmit ind1,ind
2PIndversion
Lund
Dpind1,ind
2qPisSuccessorLmit ind1,ind
2PIndversion
L.
•Schemakonsistenzregel 4: Jedes Schemakonzept der 3. und 4. Integrationsebene ist
mit genau einem Schemakonzept auf der dar¨
uberliegenden Ebene verbunden (Ausnah-
me: Schemakonzepte der obersten Ebene):
@scaPSCVarYSCVer mit lPPDCpl, scaqPhasConceptLD!scbPSC mit pscb,sc
aqP
scAboveL
•Schemakonsistenzregel 5: Jedes Schemakonzept der 2. und 3. Integrationsebene ist
mit genau einem Schemakonzept auf der darunterliegenden Ebene verbunden
120
6.2. Manuelle Schemaintegration
@scaPSCObj
LYSCVar
Lmit lPPDCpl, scaqPhasConceptLD!scbPSC mit pscb,sc
aqP
scBelowL
aF¨
ur die Mengen gilt analog die Beschreibungen aus Definition 21.
Abbildung 6.10 zeigt ein Beispiel f¨
ur eine lokale Produktontologie aus dem Automobilbereich. Im
Einzelnen verwaltet ein Informationssystem geometrische Zeichnungen f¨
ur elektronische Steuer-
ger¨
ate (engl. electronic control units) (ECUs). Weiter verwendet dieses System spezielle Techniken
zur Speicherung von Steuerger¨
ate-varianten und -versionen, die im konzeptuellen Datenmodell
des Informationssystems verankert sind. Um die semantische Heterogenit¨
at von Datenmodellen
zur Speicherung von Produktdatenn zu vereinheitlichen, werden Datenmodellkonzepte ¨
uber eine
einheitliche hierarchische Struktur abstrahiert. Diese Hierarchie besteht aus vier Produktdaten-
integrationsebenen.
Beispiel 19 (Lokale Produktontologie). Eine Lokale Produktontologie
PO
L”pPDIL,SC
L,Ind
L, AttrL, AttrV alL, MetaAttrL, MetaAttrV alLqmit
•PDIL “tpdc, object, variant, versionu
•SCL“tP roduct, P art, P artV ariant, P artV ersionu
•IndL“tcar, engine, diesel, gas, dieselv1,dieselv
2, gasolinev1u
•AttrL“tName, V ariantT ype, V ersionT ypeu
•scAbove “tpProduct,Partq,pP art, P artV ariantq,pPartV ariant,PartV ersionqu
•scBelow “tpPart, Productq,pPartV ariant, Partq,pPartV ersion,PartV ariantqu
•indAbove “tpcar, engineq,pengine, dieselq,pengine, gasq,pdiesel, dieselv1q,
pdiesel, dieselv2q,pgas, gasolinev1qu
•indBelow “tpengine, carq,pdiesel, engineq,pgas,engineq,pdieselv1,dieselq,
pdieselv2,dieselq,pgasolinev1,gasqu
•hasConcept “tppdc, P roductq,pobject, P artq,pvariant, PartV ariantq,
pversion, PartV ersionqu
•hasAttribute “tpP roduct, Nameq,pPart,Nameq,pP artV ariant, Nameq,
pPartV ariant, V ariantT ypeq,pPartV ersion, Nameq,
pPartV ersion, V ersionTypequ
•hasIndividual “tpP roduct, Carq,pPart,engineq,pP artV ariant, dieselq,
pPartV ariant, gasolineq,pdiesel, dieselv1q,pdiesel, dieselv2q,pgasoline, gasolinev1qu
•isSuccessor “tpgasolinev2, gasolinev1quq
•isP redecessor “tpgasolinev1, gasolinev2quq
•tpgasolinev1,q,pgasolinev2,v
2qu
Entsprechend umfasst die oberste Produktdatenintegrationsebene Product Data Collection ein-
121
6. Integration heterogener Produktdaten
zelne Produkte und aggregiert so die ben¨
otigten Bauteile auf der darunter liegenden Object-
Ebene. Ein Teil kann in unterschiedlichen Ausf¨
uhrungen entwickelt werden, d.h. unterschied-
liche Features unterst¨
utzen. Diese werden in der Variant-Ebene f¨
ur jedes Objekt verwaltet.
Existiert keine spezifische Variante f¨
ur ein Objekt, wird nur eine Variante angelegt. Da sich
die Entwicklung von Teilen ¨
uber einen l¨
angeren Zeitraum erstreckt, entsteht eine Vielzahl an
Entwicklungsst¨
anden, die in der Version-Ebene verwaltet werden. Da sich aus den Namen unter
Umst¨
anden nicht automatisch ableiten l¨
asst, in welcher Beziehung einzelne Versionen zueinander
stehen, m¨
ussen diese Beziehungen, auch Versionshistorie genannt, explizit dokumentiert werden.
Zusammengefasst ist eine Produktontologie eine Baumstruktur mit fest definierten Hierarchie-
ebenen.
In Abbildung 6.10 ist in jeder Produktdatenintegrationsebene ein Schemakonzept abgebildet:
Ein Product besitzt mehrere ECU, welche wiederum in unterschiedlichen ECU Variant exis-
tieren k¨
onnen. Jede Steuerger¨
atevariante nimmt im Laufe der Zeit eine Vielzahl an Entwick-
lungsst¨
anden (ECU Version) ein. Neben den Schemakonzepten sind Instanzen dargestellt. Das
Produkt ist ein Auto (Car), das ein Steuerger¨
at zur Regelung des Motors (Engine) besitzt, der
entweder ein Dieselmotor (Diesel) oder ein Benzinmotor (Gas)ist.F
¨
ur die einzelnen Steuer-
ger¨
atevarianten existieren mehrere Entwicklungsst¨
ande.
Abbildung 6.10.: Beispiel einer lokalen Produktontologie
122
6.2. Manuelle Schemaintegration
6.2.2. Globale Produktontologie
Genau wie die konzeptuellen Datenmodelle der lokalen Informationssysteme in lokale Produk-
tontologien abstrahiert werden, ist das konzeptuelle Datenmodell des PDIS ebenfalls eine Pro-
duktontologie. Diese wird als globale Produktontologie bezeichnet.
Produkte bestehen in der Regel aus Komponenten / Teilen, die gleichzeitig durch unterschiedli-
che Abteilungen entwickelt werden. Die globale Produktontologie besitzt, genau wie die lokalen
Produktontologien, die gleichen vier Produktdatenintegrationsebenen. Dadurch ist es m¨
oglich,
Produktdaten f¨
ur jede Ebene separat zu integrieren. Die gr¨
oßte Herausforderung ergibt sich bei
der Integration von Instanzen aus lokalen Produktontologien in die globale Produktontologie.
Im Speziellen m¨
ussen diejenigen Instanzen zueinander in Beziehung gebracht werden, die sich
auf dieselben Realweltobjekte beziehen.
Definition 25 (Globale Produktontologie). Eine globale Produktontologie PO
Gdient
der Integration lokaler Produktontologien und ist ein Tupel
PO
G”pPDIL,SC
G,Ind
G, AttrG, AttrV alG, MetaAttrG, MetaAttrV alGqund besitzt die
in Definition 24 spezifizierten strukturellen Konsistenzbedingungen.
Die Integration von verschiedenen Produktdatenn kann unterschiedlich in eine globale Produk-
tontologie erfolgen. Entweder wird in einer globalen Produktontologie nur ein Schemakonzept
(vgl. Abbildung 6.11) oder f¨
ur jeden Produktdatenaspekt ein eigenes (siehe Abbildung 6.12) in
der Object-Integrationsebene angelegt.
Im ersten Fall wird eine globale Produktontologie durch die Schemakonzepte Produkt,Bauteil,
Bauteilvariante und Bauteilversion beschrieben. Alle Produktdaten der lokalen Produktontolo-
gien werden auf das Schemakonzept Bauteil abgebildet. So existiert in der globalen Produkton-
tologie f¨
ur jedes Bauteil nur eine Instanz, welche alle Produktdaten umfasst.
Product Data Collection
Project
Object
Variant
Version
Local Product Ontology Global Product Ontology
Product Data Collection
Object
Variant
Version
Local Product Ontology
Requirements
Req. Variant
Req. Version Version
Variant
Part
Product
Geometry Release
Geometry Variant
Geometry
Series
Abbildung 6.11.: Modellierung einer GPO ohne explizite Unterscheidung von Produktdaten
123
6. Integration heterogener Produktdaten
Anders verh¨
alt es sich im zweiten Fall, bei dem f¨
ur jeden Produktdatenaspekt ein eigenes Sche-
makonzept, inklusive Varianten und Versionen, modelliert wird. In diesem Fall existieren zu
jedem Schemakonzept eigene Instanzen, dessen Korrespondenzen dokumentiert werden m¨
ussen,
um Zusammengeh¨
origkeiten darzustellen. Zwar ist im zweiten Fall auf einen Blick ersichtlich,
welche Produktdaten in einer globalen Produktontologie vorhanden sind, jedoch m¨
ussen daf¨
ur
mehr Schemakonzepte modelliert werden. Außerdem entstehen mehr Instanzen in der globalen
Produktontologie zwischen denen Korrespondenzen angelegt werden m¨
ussen, um einzelne Bau-
teile zu beschreiben. Die Nachteile des zweiten Ansatzes sind zugleich die Vorteile des ersten.
Durch die geringere Anzahl von Schemakonzepten sind weniger Regeln zur Abbildung zwischen
lokaler und globaler Produktontologie notwendig.
Product Data Collection
Project
Object
Variant
Version
Local Product Ontology Global Product Ontology
Product Data Collection
Object
Variant
Version
Local Product Ontology
Requirements
Req. Variant
Req. Version Version
Req. Variant
Requirements
Product
Geometry Release
Geometry Variant
Geometry
Series
Geometry
Geometry Version
Geometry Variant
Abbildung 6.12.: Modellierung einer GPO mit expliziter Unterscheidung von Produktdatenn
Der grundlegende Aufbau einer globalen Produktontologie ist in Abbildung 6.13 illustriert. Je-
de Integrationsebene umfasst ein Schemakonzept (Product,Part,Variant und Version). Ein
Produkt (engl. Product) fasst alle Bauteile (engl. Part) zusammen, die zur Herstellung aller
m¨
oglichen Produktvarianten notwendig sind. Eine Variante (engl. Variant) beschreibt eine oder
mehrere Bauteilvarianten (je nach Variabilit¨
atstyp, siehe Abschnitt 6.2.1). F¨
ur alle Bauteile in
allen Varianten existieren mehrere Zeitpunkte (engl. Releases) zu denen Entwicklungsergebnisse
explizit global f¨
ur das Produkt dokumentiert werden. Dar¨
uber hinaus besitzt jedes Schemakon-
zept eine Reihe von Metaattributen4.
Die in der Abbildung gezeigte globale Produktontologie kann um weitere Attribute und Sche-
makonzepte erweitert werden, falls dies f¨
ur die Realisierung von Anwendungsf¨
allen notwendig
ist.
4Metaattribute k¨
onnen etwa aus dem Dublin Core [WKLW98] ¨
ubernommen werden
124
6.2. Manuelle Schemaintegration
Metaattribut Beschreibung
GUID Global eindeutige Identifikationsnummer.
Name Kurznamen f¨
ur das Schemakonzept.
Description Beschreibung des Schemakonzepts.
Zus¨
atzlich kann explizites Wissen f¨
ur eine
sp¨
atere Integration dokumentiert werden.
Last modified Zeitstempel, an dem zuletzt ¨
Anderungen
am Schemakonzept vorgenommen wur-
den.
Tabelle 6.3.: Variabilit¨
atsmechanismen f¨
ur verschiedene Produktdaten
Global Product Ontology
Product Data Collection
Name: Product
ID
...
Name
...
Object
Name: Part
ID
...
Name
...
Variant
Name: Variant
ID
...
Name
...
Version
Name: Release
ID
...
Name
...
Metainformationen:
- Responsible
- Last modied
Metainformationen:
- Responsible
- Last modied
Metainformationen:
- Responsible
- Last modied
Metainformationen:
- Responsible
- Last modied
Name: Release
Description: ...
...
GUID: G_Ver_1
Last modied:
Requirements:
Metaattribute
Responsible:
Geometric Model:
Testspecication:
Testprotocol:
Produktdatenaspekt: Anforderunge
n
Produktdatenaspekt: Test
Produktdatenaspekt: Geometrie
Name:
Description: Basisattribute
Versionsnummer:
...
... Produktdatenaspekt: ...
Abbildung 6.13.: Aufbau einer globalen Produktontologie
125
6. Integration heterogener Produktdaten
6.2.3. Abbildung lokaler Produktontologien auf eine globale Produktontologie
Nach der Modellierung lokaler und globaler Produktontologien m¨
ussen diese aufeinander abgebil-
det werden. Dazu werden Schemakonzept-Attributregeln definiert. Sie legen fest, wie Korrespon-
denzen von Instanzen zwischen zwei Schemakonzepten automatisch abgeleitet werden k¨
onnen.
W¨
ahrend der automatischen Integration werden f¨
ur ermittelte Korrespondenzen zwischen In-
stanzen sog. Schemakonzept-Attributaktionen ausgef¨
uhrt, die Attributwerte von Instanzen aus
lokalen Produktontologien in die globale Produktontologie ¨
uberf¨
uhren.
Schemakonzept-Attributregeln
Wie erw¨
ahnt, sind Informationssysteme der Produktentwicklung meist auf spezifische Anwen-
dungsf¨
alle zugeschnitten. Sie fokussieren in der Regel auf einen bestimmten Produktdaten-
aspekt. Folglich besteht eine lokale Produktontologie aus wenigen Schemakonzepten, die von
Applikations- und Dom¨
anenexpterten verwaltet werden. Auf der anderen Seiten k¨
onnen meh-
rere Tausend Instanzen f¨
ur ein Produkt vorhanden sein, was vor allem auf die Version-Ebene
zutrifft. Daher sollte die Integration dieser Instanzen, soweit m¨
oglich, automatisiert werden.
Ziel der der globalen Produktontologie ist es, eine holistische Sicht auf alle Produktdaten her-
zustellen. Folglich m¨
ussen Abbildungen zwischen den Schemakonzepten aus lokalen und glo-
baler Produktontologie definiert werden. Ziel ist es, Korrespondenzen zwischen Instanzen von
Schemakonzepten aus lokalen Produktontologien und globaler Produktontologie automatisch zu
ermitteln. Wir definieren entsprechende Korrespondenzen wie folgt:
Definition 26 (Korrespondenz). Eine Korrespondenz beschreibt einen semantischen
Zusammenhang zwischen einer Instanz einer lokalen Produktontologie und einer entspre-
chenden Instanz einer globalen Produktontologie auf der gleichen Produktdatenintegrati-
onsebene. F¨
ur eine Instanz aus einer lokalen Produktontologie k¨
onnen Korrespondenzen auf
mehrere Instanzen einer globalen Produktontologie vorhanden sein und umgekehrt.
F¨
ur eine lokale Produktontologie POLund globale Produktontologie PO
Gsind Korrespon-
denzen zwischen Instanzen wie folgt definiert:
pindL,ind
GqPCorrespondence mit indLPIndL^indGPIndG
Das Problem, dass Informationen zu Realweltobjekten ¨
uber unterschiedliche Informationssyste-
me verteilt sind, ist bereits seit den 1960er-Jahren bekannt. Um zusammengeh¨
orige Datens¨
atze
(engl. records) zu identifizieren, sind unterschiedliche Record-Linkage-Techniken [Win99] ent-
standen. Diese zielen darauf ab, Eintr¨
age aus unterschiedlichen Datens¨
atzen zu finden, die ein
Realweltobjekt beschreiben. Einige dieser Techniken basieren auf Regeln, die Attribute von Ein-
tr¨
agen in Beziehung zueinander stellen.
Dieses Vorgehen l¨
asst sich auch f¨
ur die Integration im PROCEED-Rahmenwerk anwenden. So
werden zwischen Attributen von Schemakonzepten aus lokalen Produktontologien und globa-
ler Produktontologie sog. Schemakonzept-Attributregeln (engl. schema concept attribute rules
(SCAR)) definiert. Diese Regeln werden f¨
ur jede lokale Produktontologie definiert. D.h., jedes
Schemakonzept einer lokalen Produktontologie wird auf genau ein Schemakonzept der selben
Produktdatenintegrationsebene in einer globalen Produktontologie abgebildet. Eine Schemakon-
zept-Attribut-Regel beschreibt, unter welchen Voraussetzungen die Instanzen zweier Schema-
konzepte aus lokaler und globaler Produktontologie zueinander korrespondieren, so dass eine
Korrespondenz zwischen diesen vermerkt werden kann.
126
6.2. Manuelle Schemaintegration
Schemakonzept-Attributregeln setzen sich aus einer oder mehreren Attribut-Matching-Beding-
ungen (engl. attribute matching condition (AMC) zusammen. Letztere definieren f¨
ur Attribute
eines lokalen Schemakonzeptes, wie die Korrespondenz zu Attributen eines globalen Schemakon-
zeptes mit Hilfe einer Attribut-Matching-Funktion (engl. attribute matching function (AMF))
automatisch bestimmt werden kann.
Sind zum Beispiel die Namenskonventionen zur Benennung von Instanzen ¨
ahnlich, k¨
onnen Zei-
chenkettenmetriken als Attribut-Matching-Funktion definiert werden, um Korrespondenzen zu
ermitteln. H¨
aufig teilen Produktdaten der einzelnen Informationssysteme gemeinsame Attribute
(z.B. Abk¨
urzungen, eindeutige Nummern), die ebenfalls ausgenutzt werden k¨
onnen, um korre-
spondierende Instanzen zu ermitteln. Existieren wiederkehrende Muster, etwa f¨
ur die Benennung
von Artefakten in einer Produktontologie, k¨
onnen regul¨
are Ausdr¨
ucke verwendet werden, um
Korrespondenzen zwischen lokalen Produktontologien und globaler Produktontologie zu ermit-
teln. Lassen sich keine der zuvor erw¨
ahnten Funktionen definieren, so m¨
ussen Abbildungstabellen
verwaltet werden, welche eine Liste aus Quell- und Zielattributwerten von Instanzen aus lokaler
und globaler Produktonologie darstellen. Attribut-Matching-Funktionen sind wie folgt definiert:
Definition 27 (Attribute-Matching-Funktion). F¨
ur eine lokale Produktontologie PO
L
und eine globale Produktontologie PO
Gliefert eine Attribut-Matching-Funktion f¨
ur eine
Instanz jeweils aus PO
Lund PO
Gzu einem Attribut jeweils aus AttrLund AttrGentweder
wahr (engl. true) oder falsch (engl. false). F¨
ur eine Attribut-Matching-Funktion kann ein
beliebige Anzahl an Parametern definiert sein.
matchF unction :IndLˆIndGˆAttrLˆAttrGˆParam
1,ˆ...,ˆParam
nÑttrue, falseu
Die Menge pmatchF unction1,...,matchFunction
mqPMatchFunction beschreibt die vor-
handenen Attribut-Matching-Funktionen.
Wie erw¨
ahnt, werden Attribut-Matching-Funktionen in Attribut-Matching-Bedingungen ver-
wendet, um eine automatische Identifikation von Korrespondenzen zwischen Instanzen auf Basis
zweier Attribute aus lokaler und globaler Produktontologie zu beschreiben. Diese Informationen
dienen als Grundlage f¨
ur den in Abschnitt 6.3 vorgestellten Integrationsalgorithmus.
Definition 28 (Attribute-Matching-Bedingung). F¨
ur eine lokale Produktontologie
PO
Lund eine globale Produktontologie PO
Gdefinieren wir eine Attribute-Matching-Beding-
ung wie folgt:
pattrL, attrG,mf,parqPAttributeMatchingCondition mit
attrLPAttrLund attrGPAttrGund mf PMatchingF unction
W¨
ahrend eine Attribut-Matching-Bedingung den semantischen Zusammenhang zwischen jeweils
einem Attribut eines lokalen und globalen Schemakonzeptes definiert, kann es notwendig wer-
den, mehrere Bedingungen zusammenzufassen, um so eine eindeutige Korrespondenz zwischen
Instanzen feststellen zu k¨
onnen.
Abbildung 6.14 illustriert einen Ausschnitt einer lokalen Produktontologie mit Instanzen der
untersten Produktdatenintegrationsebenen. Betrachtet man die Instanzen in dem Beispiel, so
f¨
allt auf, dass ein Attribut nicht ausreicht, um eine Instanz eindeutig zu beschreiben. W¨
urde
man nur die Abbildungsregeln der Attribute Label/Name oder Version/Release verwenden,
w¨
urden falsche Korrespondenzen w¨
ahrend der Auswertung der SCAR erzeugt werden. Folglich
m¨
ussen Schemakonzept-Attributregeln mehrere Attribute-Matching-Bedingungen zusammenfas-
sen k¨
onnen.
127
6. Integration heterogener Produktdaten
Version
Version
GPO_Ver_0001
Release: Version 1
...
Name: Engine Control
Requirements: -
LPO_I_Ver_0001
Version: V1
Label: Engine Control
...
LPO_I_Ver_0002
Version: V2
Label: Engine Control
...
LPO_I_Ver_0003
Version: V1
Label: Fuel Pump
...
LPO_SC_Ver_0001
Version
Label
...
GPO_SC_Ver_0001
Version
Name
Requirements
...
SCAR 1
Equality
Label Name
-
RegEx
Version Release
...
A
M
C
A
M
C
/RFDO3URGXFW2QWRORJ\$ *OREDO3URGXFW2QWRORJ\*
Abbildung 6.14.: SCAR mit mehreren AMC
Die Identit¨
at zwischen Instanzen kann durch unterschiedliche Attribute bestimmt werden. Bei-
spielsweise k¨
onnen zwei Instanzen durch eine gemeinsame globale definierte Referenz als Korre-
spondenzen bestimmt werden. Weiter k¨
onnen beide Instanzen den gleichen, eindeutigen Namen
besitzen. In diesem Fall k¨
onnen zwischen einem lokalen und globalen Schemakonzept mehrere
SCARs definiert werden.
Zusammenfassend definieren wir Schemakonzept-Attributregeln zwischen Schemakonzepten aus
lokaler und globaler Produktontologie wie folgt:
Definition 29 (Schemakonzept-Attributregel (SCAR)). Eine Schemakonzeptattribut-
regel SCAR :“pscL,sc
G,AMCqist ein Tupel mit folgenden Eigenschaften:
•scList ein Schemakonzept aus einer lokalen Produktontologie,
•scGist ein Schemakonzept aus der globalen Produktontologie,
•ŹiPIamciPAMC ist die Konjunktion von Attribut-Matching-Bedingungen.
Um nachvollziehen zu k¨
onnen, warum eine Korrespondenz zwischen zwei Instanzen besteht,
wird w¨
ahrend der automatischen Integration f¨
ur diese eKorrespondenz eine Begr¨
undung (engl.
correspondence justification) hinterlegt. Letztere enth¨
alt einen Verweis auf die SCAR,welchef
¨
ur
das Zustandekommen der Korrespondenz verantwortlich ist. Werden Korrespondenzen manuell
erstellt, kann ebenfalls eine Begr¨
undung durch Anwender dokumentiert werden. Wir definieren
eine Korrespondenz-Begr¨
undung wie folgt:
Definition 30 (Korrespondenz-Begr¨
undung). Folgende Funktion liefert die Begr¨
undung
zu einer Korrespondenz: getJustification :Correspondence Ñ2Justification
Eine Begr¨
undung ist eine Menge aus geordneten Paaren pcor, scarqPJustification mit
128
6.2. Manuelle Schemaintegration
cor PCorrespondence und scar PSCAR. Eine Attribute-Matching-Rule entspricht der
Konjunktion einer oder mehreren Attribute-Matching-Conditions.
Je nach Produktdatenintegrationsebene werden unterschiedliche Attribut-Matching-Funktionen
ben¨
otigt. F¨
ur die vier Produktdatenintegrationsebenen werden im Folgenden m¨
ogliche Matching-
Funktionen erl¨
autert. Da die Informationssysteme der Produktentwicklung typischerweise f¨
ur
spezifische Anwendungsf¨
alle konzipiert worden sind, verwenden diese eigene Konventionen, um
Instanzen zu benennen.
Definition 31 ( ¨
Aquivalenz-Matching-Funktion). Die einfachste Matching-Funktion
ist die ¨
Aquivalenz von Attributwerten:
equivalence :IndLˆIndLˆAttrLˆAttrGÑ"true
false
mit
equivalencepindL,ind
G,attrL, attrGq“ttrue|
DattrV alLPAttributeV alueL^
DattrV alGPAttributeV alueG:
pindL, attrV alLqPhasV alueL^
pindG, attrV alGqPhasV alueG^
pattrV alL, attrLqPReferencesL^
pattrV alG, attrGqPReferencesG^
attrV alL“attrV alGu
Sind Attributwerte infolge manueller Eingabe in verschiedenen Informationssystemen nicht iden-
tisch, sondern enthalten Fehler (z.B. fehlendes Zeichen, Vertauschung von Zeichen), k¨
onnen
¨
Ahnlichkeits- und Distanzfunktionen verwendet werden, um Korrespondenzen zwischen Attribu-
ten zu bestimmen. Hierzu geh¨
oren auch Edit-Distance-Funktionen (z.B. Levenshtein-Abstand).
Die Levenshtein-Matching-Funktion wird verwendet, um Tippfehler zu erkennen, die bei manu-
eller Eingabe entstehen k¨
onnen.
Beispiel 20 (Levenshtein-Matching-Funktion). Der Levensthein-Abstand ist die mi-
nimale Anzahl an ¨
Anderungsoperationen op1...op
n(d.h. Einf¨
ugen, L¨
oschen und Ersetzen
von Zeichen z11,...,z
1nPZeiner Zeichenkette w1PW), um eine Zeichenkette in eine
andere Zeichenkette w2“pz21,...,z
1kqPZqmit z21,...,z
1kPZqzu ¨
uberf¨
uhren.
Die Hilfsfunktion levenshtein ´distance :WˆWÑNliefert die minimale Anzahl der
¨
Anderungs-operationen, die n¨
otig ist, um eine gegebene Zeichenkette in eine andere Zei-
chenkette zu transformieren. Auf Basis dieser Funktion l¨
asst sich die ¨
Ahnlichkeitsfunktion
levenshtein ´similarity :WˆWÑr0,1swie folgt definieren:
levenshtein ´similaritypw1,w
2q“1´levenshtein ´distancepw1,w
2q
maxp|w1|,|w2|q
129
6. Integration heterogener Produktdaten
Schließlich definieren wird die Matching-Funktion
levenshtein :IndLˆIndGˆAttrLˆAttrGˆtÑttrue, falseuf¨
ur zwei Instanzen mit
einer Schwelle tals eine reelle Zahl rPr0,1s. Die Matching-Funktion ist wahr, wenn die
¨
Ahnlichkeitsfunktion gr¨
oßer oder gleich einem Schwellwert tist:
levenshteinpindLP O,ind
GP O,attrLP O, attrGP O,tq“ttrue|
levenshtein ´similaritypindlpo,ind
gpoqětu
levenshteinpindLP O,ind
GP O,attrLP O, attrGP O,tq“tfalse|
levenshtein ´similaritypindlpo,ind
gpoqătu
Zwei Zeichenketten korrespondieren zueinander, wenn eine ¨
Ahnlichkeitsfunktion einen zuvor de-
finiert Schwellenwert ¨
uberschreitet bzw. bei einer Distanzfunktion einen Wert unterschreitet.
Abbildung 6.15 illustriert ein Beispiel f¨
ur Instanzen einer lokalen und der globalen Produkton-
tologie, die Tippfehler im Namen bzw. unterschiedliche Kodierungen f¨
ur Umlaute enthalten.
Korrespondenz zwischen diesen Instanzen k¨
onnen durch Verwendung der Levenshtein-Distanz
f¨
ur die Attribute Name und Responsible bestimmt werden. Im Detail muss dazu eine Schran-
ke f¨
ur die ¨
Ahnlichkeit ermittelt werden. Tabelle 6.4 illustriert den Levenshtein-Abstand bzw.
-¨
ahnlichkeit f¨
ur die Instanzen aus LocalP roductOntologyA und GlobalP roductOntologyG.Die
Schranke zur Ermittlung von Korrespondenzen zwischen den beiden Instanzen, ist in diesem
Beispiel 0.7142.
Object
GPO_Obj_0001
...
Responsible: Johnson
Object
LPO_Obj_0001
...
Name: Mueller
LPO_Obj_0002
...
Name: Jonson
LPO_Obj_0003
...
Name: Doe
LPO_Obj_0004
...
Name: ...
GPO_Obj_0002
...
Responsible: Maier
GPO_Obj_0003
...
Responsible: Müller
/RFDO3URGXFW2QWRORJ\$ *OREDO3URGXFW2QWRORJ\*
Abbildung 6.15.: Instanzen mit ¨
ahnlichen Attributwerten
130
6.2. Manuelle Schemaintegration
LP OAGP OGLevenshtein-Abstand Levenshtein-¨
Ahnlichkeit
Mueller Johnson 7 0.0
Jonson Johnson 1 0.8571
Doe Johnson 6 0.1428
Mueller Maier 4 0.3333
Jonson Maier 6 0.0
Doe Maier 4 0.2
Mueller M¨
uller 2 0.7142
Jonson M¨
uller 6 0.0
Doe M¨
uller 5 0.1666
Tabelle 6.4.: Levenshtein-Abstand und -¨
Ahnlichkeit
Bei wiederkehrenden Mustern zwischen den Attributen lokaler und globaler Schemakonzepte
lassen sich Korrespondenzen zwischen Instanzen durch regul¨
are Ausdr¨
ucke bestimmen.
Attribut 1 Attribut 2
Version 1 V1
Version 1.1 V1.1
Version 2 V2
Version 3 V3
Tabelle 6.5.: Unterschiedliche Repr¨
asentation von Attributwerten
Definition 32 (Regul¨
arer-Ausdruck-Matching-Funktion). Durch Gruppierungen und
R¨
uckw¨
artsreferenzen lassen sich wiederkehrende Muster mit Hilfe regul¨
arer Ausdr¨
ucke reali-
sieren. Damit Korrespondenzen zwischen Attributwerten aus einer lokalen und der globalen
Produktontologie mit Hilfe regul¨
arer Ausdr¨
ucke bestimmt werden k¨
onnen, m¨
ussen die zu ver-
gleichende Attributwertpaaren konkateniert werden. Um eine eindeutige Trennung zwischen
den beiden Attributwerten zu gew¨
ahrleisten, muss eine Trennsequenz vereinbart werden, die
in keinem der beiden Attribute vorkommt.
regularExpression :IndLP O ˆIndGP O ˆAttrLP O ˆAttrGP O ˆRegEx Ñ"true
false
wobei RegEx ein regul¨
arer Ausdruck ist
regularExpressionpindLP O,ind
GP O,regexq“ttrue|
regexpindLP O,ind
GP Oq“trueu
regularExpressionpindLP O,ind
GP O,regexq“tfalse|
regexpindLP O,ind
GP Oq“falseu
131
6. Integration heterogener Produktdaten
Neben der Definition regul¨
arer Ausdr¨
ucke k¨
onnen auch Funktionen definiert werden, welche
Artefakte matchen, die in propriet¨
aren Formaten vorliegen. Lassen sich Korrespondenzen zwi-
schen Instanzen weder mittels Identit¨
at, ¨
Ahnlichkeit, regul¨
arer Ausdr¨
ucken oder propriet¨
aren
Matching-Funktionen von Attributen bestimmen, m¨
ussen Abbildungstabellen sukzessive manu-
ell aufgebaut werden.
Definition 33 (Mapping-Tabelle-Matching-Funktion). Eine Mapping-Tabelle enth¨
alt
manuell gepflegte Korrespondenzbeziehungen zwischen Attributwerten.
map :IndLP O ˆIndGP O ˆAttrLP O ˆAttrGP O ˆMap Ñ"true
false
mit pmapLP O,map
GP OqPMap wobei mapLP O PIndLP O und mapGP O PIndGP O
mit
mappindLP O,ind
GP O, attrLP O, attrGP O,Mapq“ttrue|
DpmapLP O,map
GP OqPMap :mapLP O “indLP O ^mapGP O “indGP Oqu
mappindLP O,ind
GP O, attrLP O, attrGP O,Mapq“tfalse|
EpmapLP O,map
GP OqPMap :mapLP O “indLP O ^mapGP O “indGP Oqu
Produktdaten und deren Attribute werden im Entwicklungsprozess zu unterschiedlichen Zeit-
punkten in unterschiedlicher Qualit¨
at dokumentiert. Am Anfang der Produktentwicklung werden
zun¨
achst nur einige Attribute dokumentiert, so dass es notwendig werden kann, mehr als nur
eine Attribut-Matching-Regel zwischen einem lokalen und derem globalen Schemakonzept zu
definieren.
In Abbildung 6.16 sind Schemakonzepte und Instanzen einer lokalen Produktontologien sowie
einer globalen Produktontologie dargestellt. Der Einfachheit halber werden in diesem Fall nur
die obersten beiden Produktdatenintegrationsebenen mit jeweils nur einer Instanz pro Sche-
makonzept betrachtet. Die lokale Produktontologie verwaltet Anforderungen an Komponenten
(Komponentenlastenheft)f
¨
ur Fahrzeuge (Fahrzeuganforderungen).
Ein Komponentenlastenheft besitzt einen Komponentennamen sowie einen Verantwortlichen.
Fahrzeuganforderungen sind f¨
ur ein Fahrzeug (Name) zusammengefasst.
Die globale Produktontologie beschreibt alle Produktdaten von Komponenten (Bauteil)f
¨
ur Fahr-
zeuge (Fahrzeug). Ein Bauteil besitzt einen Namen,eineNr und einen Verantwortlichen.
132
6.2. Manuelle Schemaintegration
Product Data Collection
Project
Abbreviation
Attribute 4
Name
Attribute 3
Product Data Collection
Object
Requirement
Attribute 2
Attribute 4
Attribute 1
Attribute 3
Object
Component
Attribute 2
Attribute 4
Attribute 1
Attribute 3
Requirement Variant
Attribute 2
Attribute 4
Attribute 1
Attribute 3
Variant
Variant
Component Variant
Attribute 2
Attribute 4
Attribute 1
Attribute 3
Version
Requirement Version
Version Id
Dokument Reference
Reference
Name
Version
C. Variant Version
Attribute 2
Attribute 4
Attribute 1
Attribute 3
SCAR 1
MF
AttrLPO AttrGPO
Parameter
SCAR 1
MF
AttrLPO AttrGPO
Parameter
SCAR 1
MF
AttrLPO AttrGPO
Parameter
SCAR 1
MF
AttrLPO AttrGPO
Parameter
SCAA 1
MF
AttrLPO AttrGPO
Parameter
SCAR 1
MF
AttrLPO AttrGPO
Parameter
MF
AttrLPO AttrGPO
Parameter
SCAA 1
MF
AttrLPO AttrGPO
Parameter
SCAA 1
MF
AttrLPO AttrGPO
Parameter
SCAA 1
MF
AttrLPO AttrGPO
Parameter
Global Product Ontologie G
Local Master Product Ontologie M
Car Project
Reference
Responsible
Name
Release Date
Abbildung 6.16.: Abbildung von Schemakonzepten zwischen lokaler und globaler Produktontologie
F¨
ur jedes Schemakonzept der lokalen Produktontologie ist genau eine Schemakonzept-Attribut-
regel in die globale Produktontologie definiert. SCAR 1 beschreibt die Abbildung von Fahrzeu-
ganforderungen auf Fahrzeuge. Instanzen beider Schemakonzepte korrespondieren zueinander,
genau dann, wenn der Name identisch ist. Analog beschreibt SCAR 2 die Abbildung von Kom-
ponentenlastenheft auf Bauteil. Auch hier ist die Matching-Funktion als Identit¨
at der Attribute
Komponentenname und Name definiert.
Nachdem Schemakonzept-Attributregeln f¨
ur jedes Schemakonzept einer lokalen Produktontolo-
gie definiert worden sind, kann letztere in die globale Produktontologie automatisch integriert
werden (vgl. Abbildung 6.17). Dabei werden die Regeln, beginnend mit dem Schemakonzept der
obersten Produktdatenintegationsebenen f¨
ur ihrer Instanzen paarweise mit Hilfe der Matching-
Funktion ausgewertet. F¨
ur jedes Instanzpaar (hier: (L1 1, G 1), (L1 1, G 2), (L1 1, G 3), (L1 2,
G2), (L1 2, G 2), (L2 1, G 3)) aus lokaler und globaler Produktontologie, welche die Matching-
Funktion erf¨
ullen, wird eine zugeh¨
orige Korrespondenz erzeugt.
133
6. Integration heterogener Produktdaten
Product Data Collection
Product Data Collection
GPO_Ver_0001
ID: X11
...
Name: Limousine
Requirements: -
LPO_I_Ver_0001
Responsible: John Doe
Label: Limousine
...
LPO_I_Ver_0002
Responsible: Mary Ford
Label: Coupé
...
LPO_I_Ver_0003
Responsible: ...
Label: ...
...
LPO_Requirement
Responsible
Label
...
GPO_Product
ID
Name
Requirements
...
SCAR 1
Equality
Label Name
-
A
M
C
Correspondence
Justication: SCAR1
GPO_Ver_0002
ID: Z12
...
Name: Cabriolet
Requirements: -
/RFDO3URGXFW2QWRORJ\$ *OREDO3URGXFW2QWRORJ\*
Abbildung 6.17.: Auswertung einer SCAR
Schemakonzept-Attributaktionen
W¨
ahrend eine Schemakonzept-Attributregeln Schemakonzepte aus lokaler und globaler Produk-
tontologie zueinander in Relation stellen, definieren Schemakonzept-Attributaktionen (engl. sche-
ma concept attribute action (SCAA)) diejenigen Attribute aus einer lokalen Produktontologie,
die in eine globale Produktontologie integriert werden sollen. Schemakonzept-Attributaktionen
werden, ebenso wie SCARs, paarweise f¨
ur lokale und globale Schemakonzepte definiert. Zwischen
einem lokalen und globalen Schemakonzept lassen sich nur dann SCAAs definieren, wenn f¨
ur sie
mindestens eine SCAR definiert ist.
Die globale Produktontologie bietet eine holistische Sicht auf Produktdaten. Dazu k¨
onnen Attri-
bute aus lokalen Produktontologien in die globale Produktontologie integriert bzw. kopiert wer-
den. Attributwerte lokaler Produktontologien werden in die globale Produktontologie integriert,
um die Komplexit¨
at der Informationen zum Realisieren von Anwendungsf¨
allen zu reduzieren.
Um automatisch ermitteln zu k¨
onnen, wann die Abbildung einer lokalen Produktontologie in
die globale Produktontologie abgeschlossen ist, werden die Abbildungsregeln, und besonders die
Attribute der Schemakonzepte, betrachtet. F¨
ur jedes Schemakonzept muss mindestens eine SCAR
vorhanden sein. Damit festgestellt werden kann, ob keine weiteren Regeln und Aktionen ben¨
otigt
werden, m¨
ussen die Integrationsexperten alle nicht ben¨
otigten Attribute der Schemakonzepte der
lokalen Produktontologie markieren. Nur so kann sichergestellt werden, dass kein Attribut bei
der Erstellung der Abbildung ¨
ubersehen wird.
Schemakonzepte lokaler Produktontologien k¨
onnen mehr Attribute enthalten, als f¨
ur einen An-
wendungsfall notwendig sind. Durch die Definition von SCAAs k¨
onnen die ben¨
otigten Attribute
der lokalen Produktontologien in der globalen Produktontologie ¨
ubersichtlich zusammengefasst
werden. Daraus resultiert ein schnellerer Zugriff auf die ben¨
otigten Informationen. Ohne die
Definition von SCAAs m¨
ussten mit Hilfe der Korrespondenzen Informationen aus lokalen Pro-
duktontologien ermittelt werden. Durch die Korrespondenzen zwischen Instanzen aus lokaler
und globaler Produktontologie stellen Attributwerte von Schemakonzepten, die auf Grund von
134
6.2. Manuelle Schemaintegration
SCAAs erzeugt werden, redundante Informationen dar. Folglich sind sie optional.
W¨
ahrend der automatischen Integration werden definierte SCAAs f¨
ur ermittelte Korrespondenzen
ausgef¨
uhrt: Wird f¨
ur eine Instanz Aeines Schemakonzeptes SCAeiner lokalen Produktontologie
eine korrespondierende Instanz Beines Schemakonzeptes SCBaus der globalen Produktontologie
ermittelt, werden alle SCAAs ausgef¨
uhrt, die zwischen den Schemakonzepten von Aund Bdefiniert
sind. Soll in diesem Schritt ein Attributwert von Af¨
ur ein Attribut AttrAnach AttrBin B
kopiert werden, kann ein Integrationskonflikt vorliegen, wenn ein entsprechender Attributwert
in Bvorhanden ist. Daf¨
ur kann es unterschiedliche Gr¨
unde geben:
•Fall 1: Es wurde bereits eine andere lokale Produktontologie integriert, die f¨
ur dasselbe
Schemakonzept SCBund dasselbe Attribut AttrBeine SCAA definiert hat. Weiter wurde
eine Korrespondenz zwischen einer Instanz dieser lokalen Produktontologie und Bidenti-
fiziert.
•Fall 2: Neben Asind f¨
ur andere Instanzen bereits Korrespondenzen derselben lokalen
Produktontologie identifiziert und damit auch die selbe SCAA ausgef¨
uhrt worden.
•Fall 3: Der Wert f¨
ur das Attribut AttrBin Bwurde manuell und unabh¨
angig von einer
Integration in der globalen Produktontologie dokumentiert.
Unterscheiden sich die Attributwerte, die in die globale Produktontologie kopiert werden sollen,
entsteht ein Integrationskonflikt. Folglich muss f¨
ur eine SCAA, ein Integrationsverhalten angege-
ben werden, auf dessen Grundlage sich ein solcher Integrationskonflikt aufl¨
osen l¨
asst. Zur L¨
osung
von Integrationskonflikten sind verschiedene Vorgehensweisen m¨
oglich:
•Integrationsverhalten 1 (append): Der bereits festliegende Attributwert der Instanz
in der globalen Produktontologie bleibt erhalten und der zu integrierende Attributwert der
Instanz aus der lokalen Produktontologie wird in Form einer Liste angeh¨
angt.
•Integrationsverhalten 2 (recent): Sind zu den Attributwerten in der lokalen und glo-
balen Produktontologie zus¨
atzliche Metainformationen, wie z.B. der letzte ¨
Anderungszeit-
punkt, vorhanden, kann diese Information verwendet werden, den g¨
ultigen Attributwert
aus der lokalen und globalen Produktontologie zu ermitteln.
•Integrationsverhalten 3 (interactive): Die automatische Integration kann unterbro-
chen werden, um den Integrationskonflikt manuell aufzul¨
osen.
•Integrationsverhalten 4 (local): Der existierende Attributwert wird durch den Wert
aus der lokalen Produktontologie ¨
uberschrieben.
•Integrationsverhalten 5 (global): Der existierende Attributwert der globalen Produk-
tontologie wird beibehalten, solange dieser gesetzt ist. Ansonsten wird der Attributwert
der lokalen Produktontologie ¨
ubernommen.
Einerseits k¨
onnen SCAAs verwendet werden, um Attribute von Produktdaten in die globale
Produktontologie zu integrieren und somit eine holistische Sicht auf ein Produkt herzustellen.
Andererseits kann durch Definition von SCAAs auch die Konsistenz von Attributen, die ¨
uber meh-
rere Informationssysteme und damit auch ¨
uber mehrere lokalen Produktontologien verteilt sind,
sichergestellt werden. Dazu werden f¨
ur ein Attribut der globalen Produktontologie SCAAs auf
135
6. Integration heterogener Produktdaten
Attribute aus mehreren lokalen Produktontologien definiert. Gleichzeitig wird f¨
ur diese SCAAs
das Integrationsverhalten 1 oder 2 gew¨
ahlt.
Abbildung 6.18 zeigt ein Beispiel f¨
ur ein solches Szenario. Illustriert sind die Instanzen dreier
lokaler Produktontologien und einer globalen Produktontologie der selben Integrationsebene.
Ferner seien Schemakonzepte in allen drei lokalen Produktontologien vorhanden, f¨
ur die jeweils
SCAAs definiert sind.5F¨
ur jede SCAA f¨
uhrt das Integrationsverhalten zur Bildung von Listen
f¨
ur die Werte des Attributs Name in das korrespondierende Attribut Names f¨
ur Instanzen in
der globalen Produktontologie. Nach Integration einer lokalen Produktontologie in die globale
Produktontologie k¨
onnen Inkonsistenzen ermittelt werden, indem alle Instanzen der globalen
Produktontologie bestimmt werden, f¨
ur die das Attribut Names eine Liste mit mehreren Ein-
tr¨
agen besitzt.
Correspondence
Justication: SCAR1
Correspondence
Justication: SCAR2
Requirement
Reference: X890
Attribute 4: Value
Name: Value
Document: ECM.doc
Object
Instanz Ref
Names:
Attribute 4: Value
Reference: X890
Attribute 3: Value
Object
CAD Model
Reference: X890
Attribute 4: Value
Name: Value
Attribute 3: Value
Object
Object
Test Results
Reference: X890
Attribute 4: Value
Name: Value
Attribute 3: Value
Correspondence
Justication: SCAR3
/RFDO3URGXFW2QWRORJ\$ *OREDO3URGXFW2QWRORJ\*
/RFDO3URGXFW2QWRORJ\&/RFDO3URGXFW2QWRORJ\%
Abbildung 6.18.: Konsistenz¨
uberpr¨
ufung durch SCAAs
Ein Beispiel f¨
ur strukturelle Heterogenit¨
at sind Adressinformationen: Vor- und Familienname,
Straße, Hausnummer, Postleitzahl und Ort k¨
onnen in einem konzeptuellen Datenmodell sowohl
jeweils als separate Attribute oder zusammengesetzt modelliert sein. Unterschiedliche struktu-
relle Heterogenit¨
at muss bei der Abbildung lokaler Informationssysteme in lokale Produktonto-
logien ber¨
ucksichtigt werden. SCAAs referenzieren nur ein Quell- und ein Zielattribut. Es w¨
are
andererseits m¨
oglich Aggregationsfunktionen zu definieren, die mehrere Attribute lokaler Sche-
makonzepte zu einem Attribut vereinen. Ein Beispiel f¨
ur eine solche Aggregationsfunktion ist
die Konkatenation von Zeichenketten.
F¨
ur dasselbe Schemakonzept einer lokalen Produktontologie k¨
onnen mehrere SCAAs definiert
sein. Diese d¨
urfen nicht auf dasselbe Attribut in der globalen Produktontologie verweisen, da es
sonst zu Lost-Update-Problemen kommen kann.
5Aus Gr¨
unden der ¨
Ubersichtlichkeit sind diese SCAAs nicht dargestellt.
136
6.2. Manuelle Schemaintegration
Definition 34 (Attribute-Aktion). Eine Attribut-Aktion ist ein geordnetes Tripel beste-
hend aus einem Attribut einer lokalen Produktontologie attrL, einem Attribut einer globalen
Produktontologie attrGsowie einem Integrationsverhalten behavior:
pattrL, attrG, behaviorqPAttributeAction
mit
•attrLPAttrList ein Attribut eines Schemakonzeptes einer lokalen Produktontologie,
•attrGPAttrGist ein Attribut eines Schemakonzeptes einer globalen Produktontologie,
•behavior Ptappend, recent, interactive, local, globaluist das Integrationsverhalten,
welches bei Integrationskonflikten angewendet wird.
Zusammengefasst definieren wir Schemakonzept-Attributaktionen wie folgt:
Definition 35 (Schemakonzept-Attributaktion (SCAA)). F¨
ur eine lokale Produkton-
tologie PO
Lund die globale Produktontologie PO
Gsind die Schemakonzept-Attributaktionen
pscL,sc
G,aa
1,...,aa
nqPSCAA eine Menge von geordneten Elementen mit scLPSCLund
scGPSCG. Es gelten die folgenden Eigenschaften:
•scLPSCList ein Schemakonzept aus einer lokalen Produktontologie,
•scGPSCGist ein Schemakonzept aus der globalen Produktontologie,
•paa1,...,aa
nqPAttributeAction ist die Menge der Attribut-Aktionen.
Analog zu Korrespondenzen muss das Zustandekommen von Attributwerten in der globalen
Produktontologie nachvollziehbar sein. So wird f¨
ur jeden Attributwert einer Instanz der globalen
Produktontologie die SCAA dokumentiert (inkl. Zeitpunkt), die f¨
ur den Wert verantwortlich
ist. Da Attributwerte auch manuell gepflegt werden k¨
onnen, wird zwischen automatischen und
manuellen Attributwerten unterschieden. Diese Attributwert-Begr¨
undungen (engl. attribute value
justification) definieren wir wie folgt:
Definition 36 (Attributwert-Begr¨
undung). F¨
ur einen Attributwert attrV alGeiner
Instanz einer globalen Produktontologie ist die Attributwert-Begr¨
undung (engl. attribute
value justification)eineMengeAttrV alJustification von geordneten Paaren, wobei scaa
eine Schemakonzept-Attributaktion ist:
pattrV alG, scaaqPAttrV alJustification
Zusammengefasst beschreibt f¨
ur eine lokale Produktontologie PO
Lund eine globale Produkton-
tologie PO
Gdie Menge der Schemakonzept-Attributregeln und -aktionen das sog. Produktonto-
logie-Mapping.
137
6. Integration heterogener Produktdaten
Definition 37 (Produktontologie-Mapping). Formal ist das Produktontologie-Mapping
zwischen einer lokalen und globalen Produktontologie ein Tupel
P OMappingLˆG:“pPO
L,PO
G,SCAR,SCAAqmit:
•PO
List eine lokale Produktontologie,
•PO
Gist die globale Produktontologie,
•SCAR ist die Menge der Schemakonzept-Attributregeln f¨
ur Abbildungen zwischen
PO
Lund PO
G,
•SCAA ist die Menge der Schemakonzept-Attributaktionen f¨
ur Abbildungen zwischen
PO
Lund PO
G.
Die SCARs eines Produktontologie-Mappings k¨
onnen automatisch ausgewertet werden. Im Detail
muss f¨
ur jedes Schemakonzept der lokalen Produktontologie eine Schemakonzept-Attributre-gel
in die globale Produktontologie definiert sein:
Definition 38 (Produktontologie-Mapping Vollst¨
andigkeit). Ein Produktontologie-
Mapping P OMappingLˆG:“pPO
L,PO
G,SCAR,SCAAqzwischen einer lokalen und glo-
balen Produktontologie ist genau dann vollst¨
andig wenn: @sc PSCL:Dpsc, scG,AMCqP
SCAR
Lokale Masterproduktontologie
Nach Darstellung der Regeln und Aktionen zur Abbildung von lokaler Produktontologie auf
die globale Produktontologie, wird im Folgenden erl¨
autert, wie Schemakonzepte der globalen
Produktontologie modelliert und mit Instanzen versorgt werden k¨
onnen.
Da die globale Produktontologie eine holistische Sicht auf mehrere Produktdaten bietet, muss
sie alle ben¨
otigten Instanzen f¨
ur Bauteile umfassen, die zur Realisierung von Anwendungsf¨
allen
notwendig sind. Anders ausgedr¨
uckt m¨
ussen die Instanzen der Schemakonzepte vollst¨
andig sein.
Damit diese Instanzen nicht manuell in der globalen Produktontologie gepflegt werden m¨
ussen,
ist es sinnvoll, sie aus einem existierenden Informationssystem zu versorgen. Zentrales Informa-
tionssystem der Produktentwicklung ist h¨
aufig ein PDM-System, das alle Bauteile und deren
Beziehungen untereinander verwaltet (siehe Abschnitt 2.2.2). Ein PDM-System kann genutzt
werden, um eine globale Produktontologie mit Instanzen zu versorgen. Dazu wird eine lokale
Produktontologie erstellt, die als lokale Masterproduktontologie (MPO)bezeichnet wird.
Die lokale Masterproduktontologie wird als Referenz f¨
ur Schemakonzepte in der globalen Pro-
duktontologie herangezogen. Die Daten aus dem zugrundeliegenden Informationssystem sind
vollst¨
andig und konsistent, sie enthalten alle zu integrierenden Instanzen f¨
ur ein Schemakon-
zept. Alle ¨
Anderungen an Instanzen der Masterproduktontologie werden direkt in die globale
Produktontologie ¨
ubernommen.
Abbildung 6.19 illustriert die 1:1-Abbildung zwischen lokaler Masterproduktontologie und globa-
ler Produktontologie. Jede Integrationsebene enth¨
alt genau ein Schemakonzept mit den Attribu-
ten Name und ID, um Instanzen zwischen lokaler und globaler Produktontologie eindeutig zuord-
nenzuk
¨
onnen. F¨
ur jedes Schemakonzept sind mindestens eine Schemakonzept-Attributregel und
138
6.2. Manuelle Schemaintegration
eine Schemakonzept-Attributaktion definiert. F¨
ur jede Instanz der lokalen Masterproduktonto-
logie existiert eine korrespondierende Instanz in der globalen Produktontologie mit jeweiligen
Korrespondenzen.
In der Praxis werden unterschiedliche Produktdaten in verschiedenen Informationssystemen do-
kumentiert. Nachdem mit Hilfe einer lokalen Masterproduktontologie die grundlegenden Sche-
makonzepte und Instanzen in der globalen Produktontologie abgebildet worden sind, k¨
onnen
weitere lokale Produktontologien integriert werden, um so alle notwendigen Produktdaten zu
integrieren. Anschließend k¨
onnen Schemakonzepte der globalen Produktontologie um Attribute
erweitert werden, die Informationen ¨
uber verschiedene Produktdaten speichern k¨
onnen, welche
bei der Integration durch Schemakonzept-Attributregeln versorgt werden.
In Abbildung 6.19 ist eine lokale Masterproduktontologie abgebildet. Aus Gr¨
unden der ¨
Ubersicht-
lichkeit, werden nur zwei Integrationsebenen dargestellt. In beiden ist jeweils ein Schemakonzept
mit Attributen sowie einer Menge an zugeh¨
origen Instanzen dargestellt. Die Schemakonzepte der
beiden Ebenen werden in die globale Produktontologie kopiert und ¨
uber SCARs aufeinander ab-
gebildet. Im Detail besitzt jedes Schemakonzept ein Attribut, das Instanzen eindeutig beschreibt
(z.B. eine global g¨
ultige Identifikationsnummer). F¨
ur jede Instanz der Schemakonzepte wird in
der globalen Produktontologie eine korrespondierende Instanz kopiert und ¨
uber Korresponden-
zen miteinander verbunden. Kommen Instanzen in der lokalen Masterproduktontologie hinzu,
werden diese automatisch in die globale Produktontologie kopiert und entsprechende Korrespon-
denzen angelegt. Analog wird bei der ¨
Anderung oder dem Entfernen von Instanzen verfahren.
/RFDO0DVWHU3URGXFW2QWRORJ\0 *OREDO3URGXFW2QWRORJ\*
Abbildung 6.19.: Lokale Masterproduktontologie
Wir definieren eine lokale Masterproduktontologie wie folgt:
Definition 39 (Lokale Masterproduktontologie). F¨
ur ein Produktontologie-Mapping
P OMappingMˆG:“pPO
M,PO
G,SCAR,SCAAq, bestehend aus einer globalen Produk-
tontologie PO
Gsowie einer lokalen Masterproduktontologie PO
M, gelten folgende struktu-
relle Konsistenzbedingungen:
•Jeder Produktdatenintegrationsebene enth¨
alt mindestens ein Schemakonzept mit ent-
sprechenden Korrespondenzen sc1,sc
2,sc
3,sc
4PSCM,mitpsc1,sc
2q,psc2,sc
3q,
139
6. Integration heterogener Produktdaten
psc3,sc
4qPscAboveM
–pppdc, sc1q,pobj, sc2q,pvar,sc3q,pver,sc4qq P hasConceptM
•Jedes Schemakonzept ist ¨
uber eine Schemakonzept-Attributregel in die globale Pro-
duktontologie abgebildet @sc PSCMDpsc, scG,AMCqPSCAR mit scGPSCG
•F¨
ur jede Instanz von Schemakonzepten, die in die globale Produktontologie abgebildet
sind, existiert eine korrespondierende Instanz in der globalen Produktontologie mit
einer entsprechenden Korrespondenz:
@indMPIndMund @sc PSCMf¨
ur die gilt: Dpsc, scG,AMCqPSCAR und psc, indMqP
hasIndividualMfolgt: DindGPIndGund DpindM,ind
GqPCorrespondence
Integrationsauschluss
Enth¨
alt eine Produktontologie mehr Informationen als f¨
ur eine Integration erforderlich, k¨
onnen
Schemakonzepte und Instanzen von einer Integration ausgeschlossen werden. Umfasst beispiels-
weise ein PDM-System alle Produkte eines Unternehmens, k¨
onnen zur Realisierung eines An-
wendungsfalls die Produkte, und damit Instanzen entsprechender lokaler Produktontologien, von
einer Integration ausgeschlossen werden. Der Ausschluss von Schemakonzepten und Instanzen
erfolgt manuell durch Integrationsexperten und wird im Produktontologie-Mapping (vgl. Defi-
nition 38) gespeichert. Je nach Anwendungsfall k¨
onnen auf diese Weise unterschiedliche Menge
definiert werden, die von einer Integration ausgeschlossen werden sollen. Dazu wird die Definition
des Produktontologie-Mappings wie folgt erweitert:
Definition 40 (Produktontologie-Mapping mit Ausschluss). F¨
ur ein Produktontologie-
Mapping P OMappingLˆG:“pPO
L,PO
G,SCAR,SCAAqk¨
onnen f¨
ur lokale Produktonto-
logie PO
Lund globale Produktontologie PO
Gdie Mengen SCIgnore
Xund IndIgnore
xdefiniert
werden mit:
•SCIgnore
Xist die Menge von Schemakonzepten,
•IndIgnore
Xist die Menge der Instanzen der Produktontologie PO
Xmit XPL, G,die
f¨
ur eine Integration nicht ber¨
ucksichtigt werden.
Dadurch ergeben sich folgende Mengen f¨
ur ein Produktontologie-Mapping, welches den Aus-
schluss von Schemakonzepten und Instanzen ber¨
ucksichtigt:
P OMappingIgnore
LˆG:“pPO
L,PO
G,SCAR,SCAA,SCIgnore
L,Ind
Ignore
L,SCIgnore
G,Ind
Ignore
Gq
mit
•SCIgnore
LĂPO
L.SCL
•IndIgnore
LĂPO
L.IndL
•SCIgnore
GĂPO
G.SCG
•IndIgnore
GĂPO
G.IndG
140
6.2. Manuelle Schemaintegration
6.2.4. Methodiken zur Erstellung lokaler und globaler Produktontologien
Die Modellierung lokaler und globaler Produktontologien k¨
onnen unabh¨
angig voneinander ge-
schehen. Um die Integration von Schemakonzepten und den entsprechenden Instanzen zu ver-
einfachen, ist es sinnvoll, die Modellierung untereinander abzustimmen. Darunter fallen z.B.
die Benennung von Schemakonzepten und Attributen. W¨
ahrend Variabilit¨
atsmechanismen und
Versionierung der lokalen Produktontologien durch die zugrundeliegenden Informationssyste-
me definiert sind, k¨
onnen diese in der globalen Produktontologie f¨
ur jedes Schemakonzept der
entsprechenden Ebenen frei definiert werden.
Die Modellierung lokaler Produktontologien und der globalen Produktontologie kann auf drei
verschiedene Arten erfolgen. Werden Schemakonzepte in beiden definiert, ohne die Datenmodelle
der vorhandenen Informationssysteme zu ber¨
ucksichtigen, sprechen wir im weiteren Verlauf der
Arbeit von einer Top-Down-Methodik. Im umgekehrten Fall werden zun¨
achst die Datenmodel-
le existierender Informationssysteme auf Gemeinsamkeiten analysiert (Bottom-Up-Methodik).
Schließlich k¨
onnen beide Ans¨
atze kombiniert werden und sowohl Schemakonzepte in einer glo-
balen Produktontologie vorgegeben als auch gemeinsame aus den lokalen Informationssystemen
abgeleitet werden (Mixed-Methodik).
Top-Down-Vorgehen
Bei der Top-Down-Methodik werden zun¨
achst Schemakonzepte der globalen Produktontologie,
unabh¨
angig von bestehenden Schemakonzepten, aus den zu integrierenden Informationssystemen
definiert (siehe 1
in Abbildung 6.20). Dazu werden sowohl Metaattribute, wie zum Beispiel
der Name des Schemakonzeptes oder eine Beschreibung modelliert ( 2
). Im Speziellen werden
f¨
ur die Schemakonzepte der Variant- und Version-Ebene die entsprechenden Variabilit¨
ats- und
Versionierungstypen dokumentiert (vgl. 3
und 4
). Auf Basis dieser globalen Produktontologie
werden anschließend die lokalen Produktontologien (siehe 5
) sowie Abbildungen ( 6
)zwischen
lokalen Produktontologien und der globalen Produktontologie spezifiziert.
Vorteil des Top-Down-Ansatzes ist es, dass die Begriffe f¨
ur Schemakonzepte vereinheitlicht wer-
den k¨
onnen, indem bei der Modellierung lokaler Produktontologien jeweils Bezug auf die globale
Produktontologie genommen wird. Da die globale Produktontologie zur Realisierung fachlicher
Anwendungsf¨
alle dienen soll, sind die ben¨
otigten Informationen bereits bekannt. Neben der Be-
nennung von Schemakonzepten kann auch die Granularit¨
at von Attributen aus der globalen
Produktontologie ber¨
ucksichtigt werden. Dem gegen¨
uber steht das Problem, dass bei der Mo-
dellierung der globalen Produktontologie m¨
oglicherweise Attribute aus lokalen Informationssys-
temen unber¨
ucksichtigt bleiben. Unterscheiden sich Schemakonzepte aus lokalen Informations-
systemen zu sehr von denen in der globalen Produktontologie, sind komplexe Transformationen
notwendig.
Bottom-Up-Vorgehen
Beim Bottom-Up-Ansatz werden die Schemakonzepte der lokalen Produktontologien, unabh¨
an-
gig von der globalen Produktontologie, modelliert (siehe 1
in Abbildung 6.21). Dies bedeutet,
dass die Bezeichnung von Schemakonzepten beliebig gew¨
ahlt sein k¨
onnen. Gleiches gilt f¨
ur die
Abbildung von Attributen aus den lokalen Informationssystemen in die lokalen Produktonto-
logien. M¨
oglicherweise ist die gew¨
ahlte Granularit¨
at dieser Attribute nicht passend f¨
ur eine
Integration in eine globale Produktontologie.
141
6. Integration heterogener Produktdaten
Abbildung 6.20.: Top-Down-Vorgehen
Nachdem die lokalen Produktontologien modelliert sind, werden die Schemakonzepte der ein-
zelnen Produktdatenintegrationsebenen auf Gemeinsamkeiten hin analysiert und entsprechende
Schemakonzepte in der globalen Produktontologie definiert (vgl. 2
bis 5
).
Die Vorteile beim Bottom-Up-Vorgehen sind, dass die lokalen Produktontologien unabh¨
angig von
einer globalen Produktontologie modelliert werden k¨
onnen und somit nicht von dieser abh¨
angen.
Nachteilig ist der Integrationsaufwand, der durch die potenzielle Heterogenit¨
at zwischen mehre-
ren lokalen Produktontologien entsteht.
Hybrides Vorgehen
Als dritte Option kommt eine Variante in Betracht, die Top-Down- und Bottom-Up-Vorgehen
vereint. Dabei werden essentielle Schemakonzepte und Attribute in einem Top-Down-Vorgehen
in der globalen Produktontologie vorgegeben. Anschließend werden die Schemakonzepte loka-
ler Produktontologien auf diese vorgegebenen Schemakonzepte abgebildet. Schließlich k¨
onnen
Schemakonzepte der globalen Produktontologie bei der Analyse lokaler Produktontologien um
Attribute erweitert werden (Bottom-Up-Vorgehen).
Dieser Ansatz vereint die Vorteile von Bottom-Up und Top-Down. Abbildung 6.22 zeigt zwei
142
6.2. Manuelle Schemaintegration
Abbildung 6.21.: Bottom-Up-Vorgehen
lokale Produktontologien Aund B,f
¨
ur die einige Schemakonzepte in eine globale Produktonto-
logie Gabgebildet worden sind. Zun¨
achst wurden Schemakonzepte in Gmodelliert (siehe 1
),
anschließend wurden Produktontologien erstellt ( 2
). Ein Schemakonzept aus Bwird in Gab-
gebildet ( 3
), bevor ein weiteres Schemakonzept von Bnach Gabgebildet wird ( 4
). Dann wird
das Schemakonzept in Gum ein Attribut aus Berweitert. Da bisher auf das Schemakonzept
aus Gkein weiteres Schemakonzept einer anderen lokalen Produktontologie abgebildet worden
ist, hat diese ¨
Anderung der globalen Produktontologie keine weiteren Auswirkungen. Anders
verh¨
alt es sich im Fall 6
, bei dem das Schemakonzept aus Gum ein weiteres Attribut aus
Aerweitert wird. Hier m¨
ussen alle Schemakonzepte lokaler Produktontologien, die bereits auf
dasselbe Schemakonzept aus Gabgebildet worden sind, daraufhin untersucht werden, ob sie das
neue Attribut ebenfalls verwenden.
143
6. Integration heterogener Produktdaten
*OREDO3URGXFW2QWRORJ\*
Abbildung 6.22.: Hybrides Vorgehen
6.2.5. Initiales Integrationsprojekt
Im Folgenden wird die Erstellung eines Integrationsprojektes erl¨
autert. F¨
ur einen Anwendungs-
fall werden beispielhaft zwei lokale Informationssysteme in lokale Produktontologien abgebildet
sowie in eine globale Produktontologie integriert. Abbildung 6.23 zeigt den Prozess f¨
ur die in-
itiale Erstellung eines Integrationsprojektes in BPMN-Notation [Whi08]. Ein Integrationspro-
jekt dient der Realisierung von Anwendungsf¨
allen, die auf integrierten Produktdaten basieren.
Der Prozess wird durch das Integration Board gestartet. Dessen Mitglieder erstellen gemeinsam
einen Projektplan, der die einzelnen Meilensteine und Zeitpunkte enth¨
alt. Danach definieren die
Mitglieder des Integration Board zusammen mit den Fachanwendern (engl. Business User)die
zu realisierenden Anwendungsf¨
alle. Sobald diese dokumentiert sind, k¨
onnen Integrationsexper-
ten (engl. Integration Experts) mit der Spezifikation der globalen Produktontologie beginnen.
Gleichzeitig definieren die Dom¨
anenexperten (engl. Domain Experts) die Abbildung von lokalen
Informationssystemen auf entsprechende lokale Produktontologien. Sobald die Spezifikation ab-
geschlossen ist, k¨
onnen die Integrationsexperten die Abbildungs- und Integrationsregeln (SCAR
und SCAA) definieren. Dann kann die automatische Auswertung der Regeln beginnen. Anschlie-
ßend erfolgt die manuelle Integration durch die Komponentenverantwortlichen, unterst¨
utzt durch
Datenqualit¨
atsexperten (engl. Data Quality Engineers). Wird ein Zeitpunkt erreicht, zu dem
Referenzwerte f¨
ur Integrationsmetriken spezifiziert worden sind, erfolgt eine Begutachtung der
144
6.2. Manuelle Schemaintegration
aktuellen Werte durch das Integration Board. Liegen die Werte deutlich unter den definierten
Referenzwerten, kann das Integration Board geeignete Gegenmaßnahmen definieren. Ist die In-
tegration vollst¨
andig und konsistent, k¨
onnen die Daten der globalen Produktontologie durch die
Fachanwender genutzt werden.
'DWD4XDOLW\
(QJLQHHU
0DQXHOOH,QWHJUDWLRQ
352&(('
,QLWLD OH ,QWH JUD WLRQ
%XVLQHVV8VHU
'DWHQQXW]XQJ
,QW H JUD WLR Q([S H UW
0D SSLQJ
,QWHJUDWLRQ%RDUG'RPDLQ([SHUW'HYHORSPHQW
3URMHNWYRUEHUHLWXQJ
$QZHQGXQJVIlOOH
VSH]LIL]LHUHQ
3URMHNWSODQ
HUVWHOOHQ
5HIHUHQ]ZHUWH
GHILQLHUHQ
0RGHOOLHUXQJ/32V
/RNDOH
3URGXNWRQWRORJLH
HUVWHOOHQ
7UDQVIRUPDWLRQHQ
HUVWHOOHQ
0RGHOOLHUXQJ*32
*OREDOH
3URGXNWRQWRORJLH
HUVWHOOHQ
3RSXODWLRQ
HUVWHOOHQ 6&$5V
HUVWHOOHQ
6&$$V
HUVWHOOHQ
,QLWLDOH
,QWHJUDWLRQ
VWDUWHQ
$QZHQGXQJVIlOOH
GXUFKIKUHQ
,QWHJUDWLRQV
PHWULNHQ
DXVZHUWHQ
5HIHUHQ]]HLWSXQNWHUUHLFKW
*HJHQ
PDQDKPHQ
HLQOHLWHQ
(QG]HLWSXQNWHUUHLFKW
$EIUDJHQ
IRUPXOLHUHQ
.RUUHVSRQGHQ]HQ
SIOHJHQ
0DVNHQIU
$QZHQGXQJVIlOOH
HUVWHOOHQ
6&$5VXQG
6&$$V
DXVZHUWHQ
Abbildung 6.23.: BPMN-Prozess einer initialen Produktdatenintegration
Projektvorbereitung
Beispiel 21 (Integrationsprojekt). Ziel des Integrationsprojektes sei der Abgleich von
Bauteilen f¨
ur das Produkt ”Limousine 2018“ und dessen Testergebnisse. Dazu sollen die
Stammdaten der Bauteile eines Produktes (z.B. Name, eindeutige Bauteilnummer, Test-
145
6. Integration heterogener Produktdaten
ergebnissen) abgeglichen werden. Auf Basis dieser integrierten Produktdaten lassen sich
verschiedene Anwendungsf¨
alle definieren:
•Anwendungsfall 1: Erstellung einer ¨
Ubersicht mit allen Bauteilen, f¨
ur die keine Test-
ergebnisse vorliegen.
•Anwendungsfall 2: Konsistenz¨
uberpr¨
ufung von Attributen der St¨
uckliste und der Test-
dokumentation.
1. Projektplan erstellen: Der Projektplan definiert die grundlegenden Zeitpunkte f¨
ur das
Integrationsprojekt. Dazu z¨
ahlen die Modellierung aller Produktontologien sowie die Spe-
zifikation des Mappings zwischen lokalen Produktontologien und der globalen Produkton-
tologie. Hinzu kommen die Auswahl von Instanzen und die Festlegung einer Integrationss-
trategie. Es wird zwischen Top-Down-, Bottom-Up und Hybrid-Ansatz unterscheiden.
2. Anwendungsf¨
alle spezifizieren: Ziel der Integration von Produktdaten ist die Realisie-
rung von Anwendungsf¨
allen. Beispiele f¨
ur letztere sind die Erstellung von Konsistenz¨
uber-
pr¨
ufungen oder ¨
Ubersichten.
3. Systemlandschaftsanalyse: Nach Festlegung der Integrationsziele und Spezifikation der
Anwendungsf¨
alle kann die bestehende IT-Systemlandschaft untersucht werden. Integrati-
onsexperten entscheiden zusammen mit Dom¨
anenexperten, welche Informationssysteme
f¨
ur die Realisierung der zuvor spezifizierten Anwendungsf¨
alle notwendig sind. In unse-
rem Beispiel werden die lokalen Informationssysteme Aund Bidentifiziert, wobei Adie
St¨
ucklisten f¨
ur Produkte und Bdie Testergebnisse von Produktbauteilen verwaltet.
Modellierung der globalen Produktontologie
Wie erw¨
ahnt, gibt es f¨
ur die Erstellung der globalen Produktontologie mehrere M¨
oglichkeiten.
Entweder werden Schemakonzepte unabh¨
angig von bereits bestehenden Konzepten aus loka-
len Produktontologien erstellt und beschrieben (Top-Down-Ansatz), oder es werden zun¨
achst
die lokalen Produktontologien durch Dom¨
anenexperten erstellt und danach vorhandene Sche-
makonzepte aus lokalen Produktontologien in der globalen Produktontologie wiederverwendet
(Bottom-Up-Ansatz). Auch ein Mix aus beiden Ans¨
atzen ist m¨
oglich: So k¨
onnen Schemakonzepte
in der globalen Produktontologie manuell definiert und zus¨
atzlich bestehende Konzepte aus lo-
kalen Produktontologien wiederverwendet werden (Hybrid-Ansatz). Da im vorliegenden Beispiel
die Anzahl der lokalen Informationssysteme klein ist, wird zun¨
achst die globale Produktontologie
unabh¨
angig von lokalen Produktontologien modelliert (Top-Down-Ansatz).
Das Integration Board definiert, zusammen mit den Fachanwendern, auf Grundlage der zuvor
ermittelten Anwendungsf¨
alle die ben¨
otigten Konzepte in der globalen Produktontologie. Im Spe-
ziellen legen sie f¨
ur die einzelnen Konzepte die ben¨
otigte Granularit¨
at f¨
ur Produktvarianten und
-versionen fest.
Im Beispiel in Abbildung 6.24 besteht die globale Produktontologie aus jeweils einem Schema-
konzept pro Produktdatenintegrationsebene. Das Produkt (Product) besitzt einen Namen und
eine Beschreibung. Ferner umfasst es mehrere Bauteile (Part) mit jeweils eindeutiger Bauteil-
nummer und Namen (Partnumber). Zu einem Bauteil k¨
onnen mehrere Varianten (Partvariant)
existieren, die explizit als Instanzen verwaltet werden. Der Variantentyp des Schemakonzeptes
146
6.2. Manuelle Schemaintegration
ist somit Typ 2 (vgl. Abschnitt 6.2.1). Neben einem Namen der Variante wird ein Attribut ver-
waltet, das eine Produktvariante eindeutig beschreibt. Zu jeder Bauteilvariante k¨
onnen mehrere
Versionen (Part Version) existieren. Jede Version umfasst einen Namen und eine eindeutige
Versionsnummer (Version Identifier). Zus¨
atzlich werden in diesem Schemakonzept die Produkt-
datenaspekte zusammengef¨
uhrt. Im Beispiel in Abbildung 6.24 werden f¨
ur jede Bauteilversion
die entsprechenden Testergebnisse integriert (Testresults).
Abbildung 6.24.: Integrationsbeispiel: Globale Produktontologie
Damit Produktdaten aus lokalen Produktontologien in die globale Produktontologie integriert
werden k¨
onnen, m¨
ussen in der globalen Produktontologie f¨
ur die einzelnen Konzepte Instan-
zen vorhanden sein. Diese k¨
onnen entweder manuell von Hand angelegt werden, was sehr zeit-
aufw¨
andig ist, oder es k¨
onnen Instanzen aus einer bestehenden lokalen Masterproduktontologie
als Referenz importiert und gegebenenfalls umbenannt werden. Da die St¨
uckliste in unserem
Beispiel alle ben¨
otigten Bauteile dokumentiert, wird das lokale Informationssystem Ain eine
lokale Masterproduktontologie transformiert und anschließend auf die zuvor definierten Schema-
konzepte der globalen Produktontologie abgebildet. Das lokale Informationssystem Aumfasst
Daten f¨
ur eine Vielzahl von Produkten. Da f¨
ur die Realisierung der Anwendungsf¨
alle nur die In-
stanzen eines Produktes ben¨
otigt werden, werden auch nur diese in die lokale Produktontologie
transformiert.
147
6. Integration heterogener Produktdaten
Modellierung lokaler Produktontologien
Auf Basis der Anwendungsf¨
alle erstellen die Dom¨
anenexperten lokale Produktontologien f¨
ur ih-
re Informationssysteme. Dazu definieren sie Konzepte auf den einzelnen Integrationsebenen und
dokumentieren zus¨
atzlich implizites Wissen zu diesen Konzepten. Dies k¨
onnen etwa Dokumen-
tationsmethodiken, Namensschemata oder Methoden zur Dokumentation von Produktdatenva-
riabilit¨
at und -versionierung sein. Nachdem die Konzepte erstellt wurden, m¨
ussen Transforma-
tionen auf das Datenmodell des Informationssystems spezifiziert und realisiert werden. F¨
ur das
Beispiel wird das lokale Informationssystem Bin eine lokale Produktontologie abgebildet (sie-
he Abbildung 6.25). Die Transformation von Datenmodellkonzepten des lokalen Informations-
systems in die entsprechende Produktontologie wird von Dom¨
anenexperten, unterst¨
utzt durch
Integrationsexperten, vorgenommen. F¨
ur jede Integrationsebene wird ein Schemakonzept mit
unterschiedlichen Attributen angelegt. Analog zur lokalen Masterproduktontologie werden nur
diejenigen Instanzen in die Ontologie transformiert, die zur Realisierung der zuvor definierten
Anwendungsf¨
alle notwendig sind.
Abbildung 6.25.: Integrationsbeispiel: Abbildung des Informationssystem B in eine lokale Produkton-
tologie
Abbildung 6.25 zeigt die beispielhafte Transformation des lokalen Informationssystems Bin eine
148
6.2. Manuelle Schemaintegration
entsprechende lokale Produktontologie. Das konzeptuelle Schema des lokalen Informationssys-
tems besteht aus den 5 Konzepten Testproject,Component,Version,Testcase und Testresult,
die auf die Schemakonzepte Project,Test Part,Part Variant und Part Test Release abgebildet
werden. Exemplarisch sind nur ausschnittsweise Instanzen f¨
ur die Schemakonzepte des lokalen
Informationssystems dargestellt. W¨
ahrend der Transformation werden nur die Instanzen Sedan
von Testproject auf entsprechende Instanzen der lokalen Produktontologie transformiert. Glei-
ches gilt f¨
ur alle Instanzen im lokalen Informationssystem, die mit Sedan verbunden sind. Wie zu
erkennen ist, verf¨
ugt das Schema des lokalen Informationssystems ¨
uber kein explizites Konzept
zur Repr¨
asentation von Bauteilvarianten. Vielmehr sind Informationen ¨
uber Bauteile und Vari-
anten in einem Konzept Component zusammengefasst. Als Variabilit¨
atstyp wurde eine explizite
Repr¨
asentation von Bauteilvarianten identifiziert.
Mapping
Sind alle Produktontologien spezifiziert, k¨
onnen Integrationsexperten Abbildungsregeln
(SCARs) und Abbildungsaktionen (SCAAs) zwischen lokalen Produktontologien und globaler Pro-
duktontologie definieren. Abbildung 6.26 zeigt eine beispielhafte Schema-Integration der zuvor
erl¨
auterten Informationssysteme. Der ¨
Ubersicht halber werden keine Instanzen der einzelnen
Schemakonzepte dargestellt, außerdem werden die Details der Schemakonzept-Attributregeln
ausgeblendet.
Zun¨
achst erfolgt die Abbildung zwischen der lokalen Masterproduktontologie Aund der globa-
len Produktontologie G. Dazu ist auf jeder Integrationsebene eine Schemakonzept-Attributregel
SCAR 1 bis SCAR 4 definiert. Die Schemakonzept-Attributregel SCAR 4 setzt sich zwei
Attributmatching-Bedingungen (AMC 1 und AMC 2) zusammen. Die Schemakonzept-Attribut-
aktion SCAA 1 bis SCAA 5 ¨
uberf¨
uhren die entsprechende Attributwerte f¨
ur Instanzen in die
globale Produktontologie. Analog werden anschließend Abbildungsregeln f¨
ur die lokale Produk-
tontologie Bin die globale Produktontologie Gspezifiziert.
Analog zur lokalen Masterproduktontologie spezifizieren die Schemakonzept-Attributregeln
SCAR 5 bis SCAR 8 die Abbildung der Schemakonzepte der lokalen Produktontologie Bin G.
Rollen
Im Prozess aus Abbildung 6.23 sind unterschiedliche Rollen f¨
ur das PROCEED-Rahmenwerk
definiert, die im folgenden Abschnitt n¨
aher beschrieben werden.
•Domain Expert: Ein Dom¨
anenexperte (engl. domain expert) verantwortet ein Informa-
tionssystem und kennt die verwendeten Datenmodellkonzepte. Außerdem ist er f¨
ur die
Erstellung lokaler Produktontologien verantwortlich. Dabei erstellt er die notwendigen
Transformationen von internen Datenmodellen eines Informationssystems in eine lokale
Produktontologie. Schließlich erstellt er zusammen mit Integrationsexperten die Abbil-
dungsregeln zwischen lokaler und globaler Produktontologie.
•Integration Expert: Der Integrationsexperte (engl. integration expert) kennt die Abh¨
an-
gigkeiten zwischen Schemakonzepten unterschiedlicher Informationssysteme. Er erstellt
zusammen mit dem Integration Board die Konzepte in der globalen Produktontologie,
er erstellt und pflegt die Abbildungs- und Integrationsregeln zwischen lokaler und globaler
Produktontologie in Zusammenarbeit mit Dom¨
anenexperten. Sie spezifizieren außerdem
die fachlichen Abfragen zur Realisierung von Anwendungsf¨
allen.
149
6. Integration heterogener Produktdaten
Abbildung 6.26.: Integrationsbeispiel: Ergebnis einer Schema-Integration
•Knowledge Engineer: Die Abbildung eines lokalen Informationssystems in eine kor-
respondierende Produktontologie ist nicht trivial und erfordert sowohl Wissen ¨
uber das
PROCEED-Rahmenwerk im Speziellen als auch die Modellierung von Datenmodellen im
Allgemeinen. Entsprechend unterst¨
utzt der Knowledge Engineer die Dom¨
anen- und Inte-
grationsexperten bei der Modellierung von Ontologien. Er ist Spezialist f¨
ur die Erstellung
von Ontologien und kennt deren Strukturen und Konsistenzbedingungen.
•Data Quality Engineer: Der Data Quality Engineer pflegt Korrespondenzen zwischen
lokaler und globaler Produktontologie. Er wird vom System nach der initialen Integration
¨
uber den Stand der Integration benachrichtigt. Er kann selbstst¨
andig Korrespondenzen
erstellen, l¨
oschen und bearbeiten.
•Integration- / Data-Quality-Board: Das Board definiert den zu integrierenden Um-
fang und die Integrationsmetriken (inkl. Referenzwerten). Zus¨
atzlich definieren das Board
die zu erwarteten Elemente der Integration (z.B. Komponenten oder System). Dazu k¨
onnen
es etwa ein Master-Informationssystem ausw¨
ahlen, aus dem diese Daten ¨
ubernommen wer-
den sollen.
•Software Development: Nachdem die Anwendungsf¨
alle spezifiziert sind, erstellt die Soft-
wareenwicklungsabteilung (engl. software development) entsprechende Masken.
150
6.3. Automatische Instanzintegration
6.3. Automatische Instanzintegration
Nach dem Mapping der lokalen Produktontologien in die globale Produktontologie, k¨
onnen mit
Hilfe der Abbildungsregeln geeignete Korrespondenzen ermittelt und Schemakonzept-Attribut-
aktionen ausgef¨
uhrt werden. Es muss zwischen der initialen Integration von Informationssyste-
men und dem ¨
Anderungsmanage- ment unterschieden werden. Bei der initialen Integration exis-
tieren noch keine integrierten Produktdaten bzw. lokalen Produktontologien. Nach der initialen
Integration folgt das ¨
Anderungs-management. Hierbei werden alle ¨
Anderungsf¨
alle betrachtet,
die nach einer initialen Integration auftreten k¨
onnen. Die initiale Integration wertet f¨
ur jede lo-
kale Produktontologie, die in die globale Produktontologie abgebildet ist, die definierten SCARs
f¨
ur die existierenden Instanzen aus und erstellt Korrespondenzen. F¨
ur letztere werden ebenfalls
vorhandene SCAAs ausgef¨
uhrt.
6.3.1. Initiale Integration
Die Integration von Instanzen aus den Schemakonzepten lokaler Produktontologien in die globale
Produktontologie sollte, soweit wie m¨
oglich, automatisiert werden. Da lokale Produktontologien
und globale Produktontologie die gleiche Struktur aufweisen, k¨
onnen die SCARs f¨
ur jede Pro-
duktdatenintegrationsebene separat ausgewertet werden. Im Detail erfolgt die Auswertung der
SCARs vonobennachunten,d.h.SCARs zwischen Schemakonzepten einer lokalen und der globa-
len Produktontologie in der Product-Data-Collection-Ebene werden zuerst ausgewertet. Danach
werden die SCARs auf der Object-Ebene ausgewertet. Dieser Prozess wird f¨
ur die weiteren Pro-
duktdatenintegrationsebenen fortgef¨
uhrt.
Ausgangspunkt einer initialen Integration bilden ein oder mehrere Produktontologie-Mappings
(mit oder ohne Ausschluss von Schemakonzepten und Instanzen) P OMappingL1ˆG,...,
P OMappingLnˆGlokaler Produktontologien L1,...,L
nauf eine globale Produktontologie G.
Der ¨
Ubersichtlichkeit halber wird im Folgenden nur die Integration einer bestimmten lokalen
Produktontologie in die globale Produktontologie illustriert. Damit die Instanzen einer lokalen
Produktontologie in die globale Produktontologie integriert werden k¨
onnen, muss eine Reihe von
Eigenschaften erf¨
ullt sein. Erstens m¨
ussen beide Produktontologien strukturell konsistent sein
(siehe Definition 24). Zweitens muss die Abbildung von Schemakonzepten der lokalen Produk-
tontologien auf die globale Produktontologie vollst¨
andig sein (vgl. Definition 38).
Ergebnis der initialen Integration ist eine Menge von Korrespondenzen (inkl. Begr¨
undungen)
zwischen Instanzen der lokalen Produktontologien PO
L1,...,PO
Lneinerseits und Instanzen
der globalen Produktontologie PO
Gandererseits.
Definition 41 (Initiale Integration). Algorithmus 1 liefert f¨
ur ein Produkt- ontologie-
Mapping P OMappingLˆGzwischen einer lokalen Produktontologie PO
Lund einer globa-
len Produktontologie PO
Geine Menge an Korrespondenzen (Correspondences) inklusive
Begr¨
undungen (Justifications), Attributwerte mit Begr¨
undungen (AttrValJustification) und
eine Liste mit Integrationsaufgaben (Tasklist) zwischen diesen:
integrate :P OMappingLˆGÑpCorrespondencesLˆG, Justifications,
AttrV alJustification, T asklistq
151
6. Integration heterogener Produktdaten
Algorithmus 1 (Produktontologie-Mapping auswerten)
1: procedure Integrate(P OMappingLxG)
2: Layer “tpdc, object, variant, versionu
3: Correspondences “H
4: Justification “H
5: AttrV alJustification “H
6: T asklist “H
7: for each layer PLayer do
8: for each sccur
LPSClayer
LzSCIgnore
Ldo
9: sccur
G“psc PSClayer
G|Dpsccur
L, sc, AMCqPSCARq
10: Indsccur
L,layer
L“pind PIndL|psccur
L,indqPhasIndividualL^ind RIndIgnore
Lq
11: Indsccur
L,layer
G“pind PIndG|psccur
G,indqPhasIndividualG^ind RIndIgnore
Gq
12: IndCandidatesL“H
13: IndCandidatesG“H
14: if ElPLayers :isAbovepl, layerqthen
15: IndCandidatesL“Indsccur
L,layer
L
16: else
17: for each indcur
LPIndsccur
L,layer
Ldo
18: parentIndL“pind PIndL|Dpind, indcur
LqPindAboveL
19: if DpparentIndL,xqPCorrespondence mit xPIndGthen
20: IndCandidatesL“IndCandidatesLŤindcur
L
21: end if
22: end for
23: end if
24: for each indcur
LPIndCandidatesLdo
25: if ElPLayers :isAbovepl, layerqthen
26: IndCandidatesG“Indsccur
G,layer
G
27: else
28: parentIndL“pind PIndL|Dpind, indcur
LqPindAboveL
29: ParentInd
G“pind PIndG|pparentIndL,indqPCorrespondenceq
30: for each indcur
GPParentInd
Gdo
31: indCandidateG“pind PIndG|Dpind, indcur
GqPindBelow
32: IndCandidatesG“IndCandidatesGŤindCandidateG
33: end for
34: end if
35: for each indcur
GPIndCandidatesGdo
36: for each scarcur “psccur
L,sc
cur
G,AMCqPSCAR do
37: if evaluateAMCpindcur
L,ind
cur
G, scarcur.AMCqthen
38: newCor “pindcur
L,ind
cur
G, scarcurq
39: Justification “Justification ŤpnewCor, scarcurq
40: Correspondences “Correspondences ŤnewCor
41: scaaResult “executeSCAA(newCor)
42: AttrV alJustification “AttrV alJustification Ť
scaaResult.AttrV alJustification
152
6.3. Automatische Instanzintegration
43: T asklist “T asklist ŤscaaResult.T asklist
44: end if
45: end for
46: end for
47: end for
48: end for
49: end for
50: return Correspondences, Justification, AttrV alJustification, T asklist
51: end procedure
Algorithmus 1 stellt den initialen Integrationsprozess f¨
ur ein Produktontologie-Mapping dar.
Er wertet die Schemakonzept-Attributregeln aus und f¨
uhrt f¨
ur gefundene Korrespondenzen zu-
geh¨
orige Schemakonzept-Attributaktionen aus. Im Detail erfolgt die Integration der lokalen Pro-
duktontologie in die globale Produktontologie f¨
ur jede Produktdatenintegrationsebene separat
(Zeile 2), beginnend mit der Product-Data-Collection-Ebene pdc.Zun
¨
achst sind die Menge der
Korrespondenzen, Begr¨
undungen und Attributbegr¨
undungen sowie die Aufgabenliste leer (Zei-
len 3 bis 6).
Die nachfolgenden Schritte werden f¨
ur jede Produktdatenintegrationsebene ausgef¨
uhrt (Zeile
7): F¨
ur jedes Schemakonzept sccur
Lder lokalen Produktontologie der aktuellen Ebene (Zeile
8) wird das korrespondierende Schemakonzept sccur
Gder globalen Produktontologie ¨
uber die
Schemakonzept-Attributregeln ermittelt (Zeile 9). Anschließend werden f¨
ur beide Schemakon-
zepte die zugeordneten Instanzen Indsccur
L
Lder lokalen Produktontologie (Zeile 10) sowie die Men-
ge der Instanzen Indsccur
G
Gder globalen Produktontologie (Zeile 11) bestimmt. Instanzen, die von
einer Integration ausgeschlossen worden sind (vgl. Abschnitt 6.2.3), werden nicht ber¨
ucksichtigt
(vgl. IndIgnore
Lund IndIgnore
Gin Zeilen 10 und 11).
F¨
ur die Instanzen aus lokaler und globaler Produktontologie werden paarweise die definierten
Schemakonzept-Attributregeln ausgewertet. Auf jeder Produktdatenintegrationsebene werden
hierzu diejenigen Instanzen der lokalen sowie globalen Produktontologie ermittelt, die f¨
ur einen
paarweisen Vergleich in Frage kommen. Die Menge der Kandidaten der lokalen Produktontologie
IndCandidatesLund der globalen Produktontologie IndCandidatesGsind zun¨
achst leer (Zei-
len 12, 13). Die Integration wird f¨
ur die oberste Produktdatenintegrationsebene pdc gestartet.
In diesem Fall ist die Menge IndCandidatesLgleich der Menge der Instanzen f¨
ur das aktuel-
le Schemakonzept Indsccur
L
L(Zeilen 12 bis 14). Befindet sich die Integration auf einer anderen
Produktdatenintegrationsebene, so werden nur diejenigen lokalen Instanzen f¨
ur einen Vergleich
herangezogen, f¨
ur deren zugeh¨
orige Instanzen auf der n¨
achst h¨
oheren Produktdatenintegrations-
ebene bereits Korrespondenzen ermittelt worden sind (Zeilen 12 bis 21).
Abbildung 6.27 illustriert ein Beispiel. Seien Korrespondenzen cor1,cor2 und cor3 zwischen
den Instanzen B,C,X,Yund Zder Produktdatenintegrationsebene Product Data Collection
durch eine Schemakonzept-Attributregel SCAR 1 ermittelt. Algorithmus 1 befindet sich in der
Object-Ebene. Die Menge der lokalen Instanzen, die f¨
ur einen Vergleich in Betracht gezogen
werden, sind in diesem Beispiel B1 und C1,daf
¨
ur die zugeh¨
orige Instanzen der n¨
achst h¨
oheren
Produktdatenintegrationsebene (Bund C) Korrespondenzen (cor1,cor2 und cor3) vorhanden
sind.
153
6. Integration heterogener Produktdaten
/RFDO3URGXFW2QWRORJ\/ *OREDO3URGXFW2QWRORJ\*
FRU
FRU
FRU
Abbildung 6.27.: Reduktion der Vergleiche von Instanzen
Anschließend wird die Menge der globalen Instanzen bestimmt, die f¨
ur den Vergleich herange-
zogen werden. Befindet sich die Integration auf der obersten Produktdatenintegrationsebene,
ist die Menge der Kandidaten, analog zur lokalen Produktontologie, gleich der Menge der glo-
balen Instanzen f¨
ur das aktuelle globale Schemakonzept Indsccur
G,layer
G(Zeilen 23 bis 25). Be-
findet sich der Algorithmus auf einer anderen Produktdatenintegrationsebene, wird die Menge
der globalen Instanzkandidaten ¨
uber Korrespondenzen zwischen lokalen und globalen Instanzen
wie folgt ermittelt: F¨
ur jede lokale Instanz indcur
Lder Menge der lokalen Instanzkandidaten
IndCandidatesLwird die lokale Instanz parentIndLermittelt, die sich auf der n¨
achst h¨
oheren
Produktdatenintegrationsebene befindet. Danach wird f¨
ur die Instanz parentIndLdie Menge
der korrespondierenden globalen Instanzen ParentInd
Gbestimmt (Zeilen 26 - 27). Die Menge
der globalen Instanzkandidaten IndCanidatesGergibt sich aus den zugeh¨
origen Instanzen aus
ParentInd
Gder n¨
achst tieferen Produktdatenintegrationsebene (Zeile 30).
Zur Veranschaulichung betrachten wir nochmals das Beispiel aus Abbildung 6.27. F¨
ur die lokale
Instanz B1 ergibt sich die Menge der globalen Instanzkandidaten ¨
uber die Instanz Bder n¨
achst
h¨
oheren Produktdatenintegrationsebene von B.F
¨
ur diese Instanz existieren zwei korrespondie-
rende globale Instanzen Xund Y. Die Menge der zugeh¨
origen Instanzen von Xund Yauf der
n¨
achst tieferliegenden Produktdatenintegrationsebene (X1,X2,Y1,Y2 und Y3) ist die gesuchte
Menge der globalen Instanzkandidaten f¨
ur einen Vergleich mit B1.
Nachdem die Mengen der lokalen Instanzkandidaten IndCandidatesLund der globalen Instanz-
kandidaten IndCandidatesGermittelt sind, wird jedes Element der ersten Menge mit jedem
Element der zweiten Menge verglichen (Zeile 22 und 33). Dazu wird f¨
ur jede Schemakonzept-
Attributregel, die zwischen lokalem Schemakonzept sccur
Lund globalen Schemakonzept sccur
Gdefi-
niert ist, die Menge der Attribut-Matching-Bedingungen (vgl. Abschnitt 6.2.3) f¨
ur die lokale und
globale Instanz (indcur
Lund indcur
G) ausgewertet (Zeile 35). Die Auswertung erfolgt durch Algo-
rithmus 2 evaluateAMC.Sindf
¨
ur die lokale und globale Instanz indcur
Lund indcur
Galle Attribut-
Matching-Bedingungen erf¨
ullt, wird eine neue Korrespondenz (newCor) sowie Korrespondenz-
Begr¨
undung (Justification) erstellt (Zeilen 36 bis 38). Schließlich werden f¨
ur indcur
Lund indcur
G
korrespondierende Schemakonzept-Attributaktionen f¨
ur lokale und globale Instanz ausgef¨
uhrt
(Zeile 39). Dazu wird Algorithmus 3 executeSCAA ausgef¨
uhrt. Neben Attribut-Begr¨
undungen
(siehe Abschnitt 6.2.3) liefert Algorithmus 3 eine Menge an Aufgaben zur¨
uck, die durch Inte-
154
6.3. Automatische Instanzintegration
grationskonflikte enstanden sind (Zeilen 40 und 41). Der Algorithmus terminiert, nachdem die
Auswertung von lokalen und globalen Instanzkandidaten f¨
ur alle Schemakonzepte der untersten
Produktdatenintegrationsebene beendet ist.
Die in Algorithmus 1 verwendete Funktion evaluateAMC ist in Algorithmus 2 definiert.
Algorithmus 2 (Attribut-Matching-Bedingung auswerten)
1: procedure evaluateAMC(indL,ind
G, scar)
2: for each curAmc Pscar.AMC do
3: valL“pattrV al PAttrV alL|DpattrV al, curAmc.attrLqPreferencesLmit
pindL, attrV alqPhasV alueLq
4: valG“pattrV al PAttrV alG|DpattrV al, curAmc.attrGqPreferencesGmit
pindG, attrV alqPhasV alueGq
5: if !matchpvalL,val
G, curAmc.mf, curAmc.parqthen
6: return false
7: end if
8: end for
9: return true
10: end procedure
Eingabe des Algorithmus 2 sind eine Schemakonzept-Attributregel scar sowie jeweils eine In-
stanz einer lokalen und globalen Produktontologie (indLund indG). F¨
ur jede Attribut-Matching-
Bedingung (Zeile 1) der Schemakonzept-Attributregel werden die Attributwerte der lokalen In-
stanz valLund der globalen valG(Zeilen 2 und 3) bestimmt. Stimmen die Werte bei Auswertung
der Matching-Funktion (vgl. Definition 27) der Schemakonzept-Attributregel nicht ¨
uberein, ist
mindestens eine Attribut-Matching-Bedingung dieser Regel nicht erf¨
ullt. Somit wird als Ergeb-
nis false zur¨
uckgegeben (Zeile 5). Sind alle Bedingungen erf¨
ullt, wird als Ergebnis true zur¨
uck
geliefert (Zeile 7).
Die Auswertung der Match-Funktion einer Schemakonzept-Attributregel wird im Folgenden
nicht weiter detailliert. Beispiele wurden bereits in Abschnitt 6.2.3 erl¨
autert.
Schließlich definiert der Algorithmus 3 executeSCAA die Ausf¨
uhrung der Schemakonzept-Attri-
butaktionen f¨
ur die identifizierten Korrespondenzen:
Algorithmus 3 (SCAAs ausf¨
uhren)
1: procedure executeSCAA(cor, SCAA)
2: AttrV alJustification “H
3: T asklist “H
4: for each scaacur PSCAA do
5: for each aacur Pscaacur.aa do
6: localAttrV al “pDattrV al PAttrV alL|
DpattrV al, scaacur.attrLqPreferencesL^
Dpcor.indL, attrV alqPhasV alueLq
7: localChanged “pDmetaAttrV al PMetaAttrV alL|
plocalAttrV al,1changed1, metaAttrV alqPhasMetaAttrV alL)
8: globalAttrV al “pDattrV al PAttrV alG|
DpattrV al, scaacur.attrGqPreferencesG^
Dpcor.indG, attrV alqPhasV alueGq
155
6. Integration heterogener Produktdaten
9: globalChanged “pDmetaAttrV al PMetaAttrV alL|
plocalAttributeV alue,1changed1, metaAttrV alqıhasMetaAttrV alL)
10: switch aacur.behavior do
11: case append :
12: globalAttrV al “globalAttrV al ŤlocalAttrV al
13: case recent :
14: if localChaned ąglobalChanged then
15: globalAttrV al “localAttrV al
16: end if
17: case local :
18: globalAttrV al “localAttrV al
19: case global :
20: if globalAttrV al ““ H then
21: globalAttrV al “localAttrV al
22: end if
23: case interactive :
24: T asklist “T asklist Ťpcor, aacurq
25: end for
26: AttrV alJustification “AttrV alJustification ŤpglobalAttrV al, scaaq
27: end for
28: return AttrV alJustification, T asklist
29: end procedure
Eingabe von Algorithmus 3 sind eine Menge an Schemakonzept-Attributaktionen SCAA so-
wie eine Korrespondenz cor auf dessen Instanzen die Aktionen ausgef¨
uhrt werden sollen. Die
folgenden Schritte werden f¨
ur alle Schemakonzept-Attributaktionen SCAA und deren Attribut-
Aktionen ausgef¨
uhrt (Zeilen 4 und 5). Zun¨
achst werden die Attributwerte (inklusive ¨
Anderungs-
zeitpunkte) der lokalen sowie globalen Instanz ermittelt (Zeilen 6 bis 9). Anschließend wird,
abh¨
angig vom Integrationsverhalten (siehe Abschnitt 6.2.3), der globale Attributwert globalAttr-
Val angepasst. Bei append wird der lokale Attributwert in Form einer Liste an den globalen
Attributwert angeh¨
angt (Zeilen 11 und 12). Ist der lokale Attributwert nach dem globalen At-
tributwert ge¨
andert worden, wird im Fall recent der globale durch den lokalen Attributwert
ersetzt. F¨
ur local wird immer der lokale Attributwert in die globale Produktontologie kopiert,
bei global genau dann, wenn der globale Attributwert leer ist. Im letzten Fall (interactive)wird
ein Eintrag in der Aufgabenliste (Tasklist) hinzugef¨
ugt. Welcher Attributwert in die globale
Produktontologie ¨
ubernommen wird, wird nach der automatischen Auswertung manuell ent-
schieden. Nachdem alle Attributaktionen ausgef¨
uhrt worden sind, werden die Begr¨
undungen
(AttrValJustification) sowie Aufgaben (Tasklist)zur
¨
uckgegeben (Zeile 28).
6.4. Manuelle Instanzintegration
Obwohl die Integration von Instanzen m¨
oglichst automatisch erfolgen sollte, fallen nach einer
automatischen Instanzintegration ggf. manuelle Aufgaben an. Folgende drei Arten von Aufgaben
lassen sich unterscheiden: Erstens m¨
ussen f¨
ur diejenigen lokalen Instanzen, f¨
ur die keine Kor-
respondenzen in der globalen Produktontologie automatisch ermittelt werden konnten, entspre-
chende Korrespondenzen manuell durch Experten erstellt werden. Zweitens m¨
ussen existierende
156
6.4. Manuelle Instanzintegration
Integrationskonflikte, die nicht automatisch aufgel¨
ost werden konnten, manuell aufgel¨
ost werden.
Drittens k¨
onnen w¨
ahrend der automatischen Instanzintegration auch Korrespondenzen ermittelt
worden sein, die falsch sind. Experten k¨
onnen in diesem Fall die betroffenen Korrespondenzen
manuell l¨
oschen. Ursachen sowie m¨
ogliche L¨
osungsm¨
oglichkeiten werden im Folgenden erl¨
autert.
6.4.1. Aufgabe 1: Fehlende Korrespondenzen erstellen
Nach einer automatischen Instanzintegration sind f¨
ur einige Instanzen einer lokalen Produkton-
tologie keine korrespondierenden globalen Instanzen mit Hilfe von Schemakonzept-Attributregeln
gefunden worden. Folgende Ursachen k¨
onnen daf¨
ur verantwortlich sein.
Fehlender Attributwert einer Instanz, der durch eine SCAR ausgewertet wird
Ein Attribut, welches durch eine SCAR ausgewertet wird, ist nicht dokumentiert, d.h. sein Attri-
butwert ist nicht gesetzt. Ein m¨
oglicher Grund daf¨
ur ist, dass die Entwicklung von Komponenten
eines Produktes unterschiedlich weit fortgeschritten sein kann. Wie in Abschnitt 2.2.3 erl¨
autert,
werden Komponenten parallel durch eine Vielzahl von Entwicklern realisiert. Dadurch kann ihr
Entwicklungsfortschritt zu einem bestimmten Zeitpunkt tunterschiedlich weit fortgeschritten
sein. W¨
ahrend beispielsweise Komponente A zum Zeitpunkt tspezifiziert und realisiert sein
kann, kann eine weitere Komponente B zum gleichen Zeitpunkt nur spezifiziert, jedoch nicht
realisiert, sein. Ein weiterer Grund ist, dass eine Dokumentation oder ¨
Anderung eines Attri-
butwertes in einem Informationssystem noch nicht an alle beteiligten Systeme entlang der Ent-
wicklungskette weitergeben worden ist. Schließlich kann die Dokumentation eines Attributwertes
vergessen worden sein.
L¨
osungsm¨
oglichkeit: Eine M¨
oglichkeit zur Reduzierung der Anzahl an Instanzen, f¨
ur die keine
Korrespondenzen auf Grund fehlender Attributwerte gefunden werden konnten, besteht darin,
die automatische Instanzintegration erst dann durchzuf¨
uhren, wenn m¨
oglichst viele Instanzen
mit Attributwerten dokumentiert sind.
Unterschiedliche Datenqualit¨at und inkonsistente Verwendung von Bezeichnern
Eine weitere Ursache f¨
ur fehlende Korrespondenzen von lokalen Instanzen zu globalen Instanzen
sind Unterschiede bzgl. der Datenqualit¨
at der Instanzattribute in den einzelnen Informations-
systemen. Wichtigster Aspekt der Datenqualit¨
at ist die Konsistenz von Attributwerten zwischen
Informationssystemen. So k¨
onnen f¨
ur die selben Realweltobjekte unterschiedliche Bezeichner f¨
ur
Artefakte verwendet werden oder durch verschiedene Schreibweisen oder Dokumentationsspra-
chen dokumentiert sein.
Beispiel 22 (Unterschiedliche Namenskonventionen). Baut zum Beispiel eine SCAR
auf einem Attribut auf, das wiederum auf einem Muster basiert, welches durch eine globa-
le Namenskonvention definiert ist, kann es vorkommen, dass diese Namenskonvention bei
der Dokumentation von Artefakten nicht ber¨
ucksichtigt worden ist. Tabelle 6.6 zeigt Bei-
spiele von Attributwerten f¨
ur die Bezeichnung eines Fahrersitzes, die semantisch das gleiche
bedeuten, jedoch nicht durch eine SCAR zugeordnet werden k¨
onnen, die auf Mustern basiert.
Nicht identifizierte Korrespondenzen treten zudem auf, wenn eine SCAR auf einer ¨
Ahnlichkeits-
metrik basiert (vgl. Abschnitt 6.2.3). Ist der definierte Schwellwert, ab dem zwei Attributwerte
als korrespondierend angesehen werden, zu hoch, werden nicht alle Korrespondenzen ermittelt.
157
6. Integration heterogener Produktdaten
Bezeichner
Sitz Vorne Links
Sitz VL
Seat Front Left
Sitz Fahrer
Fahrersitz Linkslenker
Driver Seat Left Steering
Tabelle 6.6.: Unterschiedliche Bezeichner aus verschiedenen Informationssystemen f¨
ur dieselbe Kompo-
nente
L¨
osungsm¨
oglichkeit: Inkonsistenzen und mangelnde Datenqualit¨
at k¨
onnen innerhalb von In-
formationssystemen vermieden werden, wenn Attribute auf eine zuvor definierte Konsistenzregel
w¨
ahrend der Dokumentation ¨
uberpr¨
uft werden. Hierzu sollte eine Vereinheitlichung von Bezeich-
nen, unter Ber¨
ucksichtigung von Dokumentationsmethodiken und Regeln f¨
ur Abk¨
urzungen, er-
folgen.
Neue Komponenten werden lokal erstellt
W¨
ahrend f¨
ur einige lokale Instanzen keine korrespondierenden Instanzen in der globalen Produk-
tontologie ermittelt werden k¨
onnen, weil Attributwerte fehlen, so k¨
onnen auch lokale Instanzen
existieren, f¨
ur die keine Korrespondenzen bestimmt werden k¨
onnen, da diese nur im lokalen
Informationssystem vorhanden sind.
Beispiel 23 (Neue Komponenten existieren nur lokal). Beispielsweise ist ein Sach-
nummernsystem / PDM-System als lokale Masterproduktontologie definiert. Wird eine neue
Komponente zun¨
achst nur versuchshalber in einem lokalen Informationssystem modelliert
und getestet, existiert f¨
ur diese Komponente noch keine Sachnummer in der lokalen Mas-
terproduktontologie und folglich auch nicht in der globalen Produktontologie.
L¨
osungsm¨
oglichkeit: F¨
ur diese lokale Instanz kann, solange keine korrespondierende Instanz
in der globalen Produktontologie gefunden wurde, bis eine entsprechende Instanz in der lokalen
Masterproduktontologie angelegt wird. Dies geschieht etwa, wenn entschieden wird die neue
Komponente in ein Produkt zu integrieren. Dazu wird eine Sachnummer erstellt (in der lokalen
Masterproduktontologie) und anschließend auch in die globale Produktontologie synchronisiert.
Entwicklung von neuen Komponenten noch nicht begonnen
Der letzte Fall ist als Sonderfall zu betrachten, da er nur dann auftreten kann, wenn die Instan-
zen einer globalen Produktontologie manuell gepflegt und nicht durch eine lokale Masterpro-
duktontologie versorgt werden. Ein neue Komponente f¨
ur ein Produkt wurde definiert und eine
entsprechende Instanz in einer globalen Produktontologie angelegt. Zu diesem Zeitpunkt wurde
noch nicht mit der Spezifikation (z.B. Anforderungen) und Realisierung begonnen, d.h. in loka-
len Informationssystemen wurden noch keine entsprechenden Artefakte und damit Instanzen in
den Produktontologien erstellt.
158
6.4. Manuelle Instanzintegration
L¨
osungsm¨
oglichkeiten: Eine M¨
oglichkeit dieses Problem zu l¨
osen besteht darin, eine lokale
Masterproduktontologie zu definieren und auf die globale Produktontologie abzubilden. Neue
Komponenten werden anschließend ausschließlich in dieser Masterproduktontologie erzeugt.
6.4.2. Aufgabe 2: Integrationskonflikte aufl¨osen
Der zweite Grund f¨
ur manuelle Aufgaben nach einer automatischen Instanzintegration sind
Integrationskonflikte, die w¨
ahrend ersterer aufgetreten sind und die manuell aufgel¨
ost werden
m¨
ussen.
Nicht synchronisierte ¨
Anderungen
Hauptursache ist das Integrationsverhalten von Schemakonzept-Attributaktionen. Wurden get¨
a-
tigte ¨
Anderungen in einem Informationssystem nicht an die anderen, im Entwicklungspro-
zess nachgelagerten, Informationssystemen synchronisiert, so existieren m¨
oglicherweise wider-
spr¨
uchliche Werte.
Wurde als Integrationsverhalten manual oder append f¨
ur eine SCAA definiert, muss f¨
ur alle
lokalen Instanzen, f¨
ur die Korrespondenzen entdeckt werden und deren Attributwerte teilweise
widerspr¨
uchlich sind, der Integrationskonflikt manuell aufgel¨
ost werden.
W¨
ahrend Instanzen mit inkonsistenten Attributwerten, die durch SCAAs mit einem append als
Integrationsverhalten ermittelt wurden, Kandidaten f¨
ur eine manuelle Konfliktaufl¨
osung sind,
m¨
ussen inkonsistente Attributwerte von Instanzen im Fall von manual zwingend manuell auf-
gel¨
ost werden, d.h. ein Data Quality Engineer (vgl. Abschnitt 6.2.5) muss einen Attributwert aus
der Liste ausw¨
ahlen. Dadurch l¨
asst sich unterscheiden, welche Instanzen am Ende des Integrati-
onsprozesses vollst¨
andig konsistent sein m¨
ussen und welche Konflikte noch in der nachgelagerten
Nutzungsphase durch Anwendungsf¨
alle aufgel¨
ost werden k¨
onnen.
6.4.3. Aufgabe 3: Fehlerhafte Korrespondenzen l¨oschen
Bisher wurden nur die F¨
alle betrachtet, in denen Korrespondenzen von lokalen und globalen
Produktontologien fehlten. Es kann aber auch vorkommen, dass w¨
ahrend der automatischen
Instanzintegration falsche Korrespondenzen ermittelt werden.
Zu niedrige Schwelle f¨ur ¨
Ahnlichkeitsfunktion
Analog zum Fall 1, bei dem bestimmte Korrespondenzen nicht gefunden werden, weil der Schwell-
wert einer Matching-Funktion zu hoch ist, kann eine zu niedrige Schwelle dazu f¨
uhren, dass
Korrespondenzen zwischen Instanzen ermittelt werden, die in der Realwelt gar nicht zueinander
geh¨
oren (False Positives) [Faw06].
Zusammengefasst m¨
ussen nach Auswertung von Schemakonzept-Attributregeln und -Aktionen
folgende manuellen Aufgaben erledigt werden:
1. Erstellen von Korrespondenzen zwischen Instanzen aus lokalen Produktontologien (falls
dies m¨
oglich ist). Dazu m¨
ussen z.B. Data Quality Engineers ¨
uber entsprechendes Hinter-
grundwissen verf¨
ugen.
2. L¨
oschen von Korrespondenzen (erfordert ebenfalls Hintergrundwissen).
159
6. Integration heterogener Produktdaten
3. Au߬
osung von Integrationskonflikten (Hintergrundwissen notwendig).
4. Ausschließen oder L¨
oschen von Instanzen (Diese Aufgabe sollte bereits vor einer automa-
tischen Intanzintegration erledigt werden).
F¨
ur alle Aufgaben sind klar definierte ¨
Anderungsoperationen notwendig, die beschreiben, wie
¨
Anderungen behandelt werden. Die Ausf¨
uhrung der Aufgaben kann durch unterschiedliche Per-
sonengruppen erfolgen. W¨
ahrend das Erstellen und L¨
oschen von Korrespondenzen fachliches
Hintergrundwissen erfordert, sollten diese Aufgaben idealerweise von den betroffenen System-
und Komponentenverantwortlichen durchgef¨
uhrt werden. F¨
ur alle Instanzen, die keinen Verant-
wortlichen dokumentiert haben, sind Data Quality Engineers daf¨
ur verantwortlich, entsprechen-
de Ansprechpartner mit dem ben¨
otigten Hintergrundwissen manuell zu identifizieren.
Die Dokumentation der Verantwortlichen kann beispielsweise durch Metainformationen erfol-
gen. Diese Verantwortlichen werden im Anschluss an die automatische Instanzintegration ¨
uber
das Integrationsergebnis informiert. Durch diese Aufteilung kann der Aufwand der manuellen
Integrationsaufgaben verteilt und beschleunigt werden.
Man beachte, dass Produktontologien hierarchisch aufgebaut sind; d.h., das manuelle Erstellen
von Korrespondenzen kann dazu f¨
uhren, dass die Auswertung von Schemakonzept-Attributregeln
und -Aktionen erneut f¨
ur einen Teilausschnitt einer Produktontologie ausgef¨
uhrt werden muss.
Dies wiederum f¨
uhrt dazu, dass m¨
oglicherweise neue Korrespondenzen gefunden werden, die
erneut zu Integrationskonflikten f¨
uhren, welche dann ebenfalls manuell aufgel¨
ost werden m¨
ussen.
Anders formuliert kann eine ¨
Anderung eine Vielzahl an abh¨
angigen ¨
Anderungen nach sich ziehen
(sog. Ripple-Effect).
Die angesprochenen ¨
Anderungsoperationen werden in Kapitel 8 detailliert. Zun¨
achst werden im
Kapitel 7 Metriken eingef¨
uhrt, die es erm¨
oglichen, eine vorgenommene Integration quantitativ
zu messen. Um bestimmen zu k¨
onnen, wie lange manuelle Integrationsaufgaben, die nach einer
initialen automatischen Integration anfallen, m¨
ussen die Aufgaben (z.B. Erstellung fehlender
Korrespondenzen, Au߬
osung von Integrationskonflikten) quantitativ beziffert werden k¨
onnen.
Dazu werden im Kapitel 7 unterschiedliche Vollst¨
andigkeits- und Konsistenzmetriken eingef¨
uhrt.
160
7. Bestimmung der Integrationsqualit¨at
Um den Integrationsprozess zu ¨
uberwachen und bewerten, werden Metriken ben¨
otigt, welche die
Qualit¨
at der resultierenden Integration messen [TBHR15]. In diesem Kapitel werden f¨
ur diesen
Zweck verschiedene Metriken entwickelt und erl¨
autert.
Ziel der Produktdatenintegration ist die Unterst¨
utzung verschiedener Anwendungsf¨
alle (vgl. De-
finition 8). Diese k¨
onnen integrierte Daten erst dann nutzen, wenn die Integration abgeschlossen
ist, d.h. wenn diese vollst¨
andig und konsistent ist. Der Nutzungszeitraum integrierter Produkt-
daten wird zuvor, in Abstimmung zwischen den Nutzern des integrierten Datenbestandes und
den Integrationsexperten, festgelegt. Um garantieren zu k¨
onnen, dass die Integration vollst¨
andig
und konsistent zum definierten Nutzungszeitpunkt ist, muss der Integrationsprozess gesteuert
und ¨
uberwacht werden.
Eine Voraussetzung f¨
ur eine automatische Instanzintegration ist die vollst¨
andige Abbildung von
Schemakonzepten der lokalen Produktontologien auf entsprechende Konzepte der globalen (vgl.
Abschnitt 6.2.3). Eine lokale Produktontologie wiederum kann genau dann automatisch auf
eine globale Produktontologie abgebildet werden, wenn f¨
ur jedes Schemakonzept mindestens
eine Schemakonzept-Attributregel definiert ist (vgl. Definition 29). Diese Eigenschaft wird im
Folgenden als lokale Schemakonzept-Vollst¨
andigkeit bezeichnet. Dar¨
uber hinaus lassen sich wei-
tere Metriken definieren, welche die Vollst¨
andigkeit von Artefakten (z.B. Schemakonzepten, In-
stanzen und Attributen) lokaler und globaler Produktontologien bestimmen und damit f¨
ur die
¨
Uberwachung des Integrationsprozesses genutzt werden k¨
onnen.
Im Abschnitt 7.1 werden die Begriffe Vollst¨
andigkeit und Konsistenz im Kontext der Integration
von Produktdaten erl¨
autert, bevor schließlich Metriken f¨
ur die lokale Produktontologie (siehe
Abschnitt 7.2) und die globale Produktontologien (siehe Abschnitt 7.3) definiert werden. Schließ-
lich wird in Abschnitt 7.4 beschrieben, wie mit Hilfe dieser Metriken der Integrationsprozess
gesteuert und ¨
uberwacht werden kann.
7.1. Vollst¨andigkeit und Konsistenz
Nachfolgend werden zun¨
achst allgemeine Definitionen f¨
ur Vol lst¨
andigkeit und Konsistenz gege-
ben, bevor in den anschließenden Abschnitten verschiedene Vollst¨
andigkeits- und Konsistenzme-
triken f¨
ur Produktontologien eingef¨
uhrt werden.
Definition 42 (Vollst¨
andigkeit). Seien M1eine Menge von Artefakten und M2eine
Referenzmenge mit M1ĂM2. Ferner sei q“|M1|
|M2|Pr0,1s. Dann: M1heißt vollst¨
andig
bezogen auf M2genau dann und nur dann, wenn q“1 gilt.
161
7. Bestimmung der Integrationsqualit¨
at
Definition 43 (Konsistenz). Sei ein bestimmter Sachverhalt (Objekt) der realen Welt in
unterschiedlichen Informationssystemen abgebildet. Dann sind die entsprechenden Beschrei-
bungen konsistent, wenn sie, bezogen auf den Sachverhalt, den selben Zustand referenzieren.
D.h., in allen Informationssystemen ist das Objekt konsistent beschrieben. Umgekehrt nen-
nen wir die Beschreibung inkonsistent, wenn in mindestens einem Informationssystem nicht
der aktuell g¨
ultige Realweltzustand des Objekts abgebildet ist.
Die folgenden Abschnitte beschreiben unterschiedliche Metriken, die f¨
ur verschiedene Artefak-
te lokaler und globaler Produktontologien bestimmt werden k¨
onnen. F¨
ur jede Metrik werden
Nutzen, Anwendung und Nutzungszeitpunkt beschrieben, gefolgt von einer formalen Definition.
7.2. Metriken f¨ur lokale Produktontologien
Eine Vollst¨
andigkeitsmetrik wurde bereits im Kontext der automatischen Instanzintegration
(siehe Abschnitt 6.3) angewendet, ohne diese formal zu definieren. Die lokale Schemakonzept-
Vol lst¨
andigkeit gibt an, wann eine automatische Instanzintegration durchgef¨
uhrt werden kann.
W¨
ahrend diese Metrik eine notwendige Bedingung darstellt, garantiert sie nicht, dass m¨
oglichst
vielen Korrespondenzen automatisch ermittelt werden k¨
onnen. Wie erw¨
ahnt k¨
onnen f¨
ur parallel
entwickelte Komponenten zwischen lokalen und globalen Produktontologien die zugeh¨
origen
Produktdaten einen unterschiedlichen Reifegrad aufweisen.
7.2.1. Lokale Schemakonzept-Vollst¨andigkeit
Dom¨
anen- und Integrationsexperten sind f¨
ur die Erstellung und Pflege der Abbildungs- und
Integrationsregeln (SCARs und SCAAs) zwischen den Schemakonzepten der lokalen Produktonto-
logien und der globalen Produktontologie verantwortlich. Der initiale Integrationsprozess einer
lokalen Produktontologie in die globale Produktontologie kann erst ausgef¨
uhrt werden, wenn f¨
ur
alle Schemakonzepte der lokalen Produktontologie jeweils mindestens eine Abbildungs- und In-
tegrationsregel definiert ist. Folglich beschreibt die lokale Schemakonzept-Vollst¨
andigkeit (engl.
Local Schema Concept Completeness)dasVerh
¨
altnis der abgebildeten Schemakonzepte einer
lokalen Produktontologie zu allen vorhanden Schemakonzepten dieser Produktontologie. Sind
beide Mengen gleich, ist die lokale Produktontologie lokal Schemakonzept-vollst¨
andig.
Lokale Schemakonzept-Vollst¨
andigkeit bildet die formale Voraussetzung f¨
ur die Ausf¨
uhrung der
automatischen Instanzintegration. Sie wird von Integrationsexperten vor der automatischen In-
stanzintegration ¨
uberwacht. Wir definieren die lokale Schemakonzept-Vollst¨
andigkeit wie folgt:
Definition 44 (Lokale Schemakonzept-Vollst¨
andigkeit). Die lokale Schemakonzept-
Vol lst¨
andigkeit (LocalSchemaConceptCompleteness) beschreibt das Verh¨
altnis der Schema-
konzepte f¨
ur die eine Schemakonzept-Attributregel definiert ist (SCMapped) zu allen Sche-
makonzepten. Schemakonzepte, die von einer Integration ausgeschlossen sind (SCIgnore
L),
werden nicht ber¨
ucksichtigt (vgl. Abschnitt 6.2.3).
162
7.2. Metriken f¨
ur lokale Produktontologien
LocalSchemaConceptCompleteness “|SCMapped|
|SCLzSCIgnore
L|Pr0,1s
mit SCMapped “tsc PSCLzSCIgnore
L|DpscL,sc
G,AAqPSCARu
mit scGPSCGsowie AA PAttributeAction
7.2.2. Lokale SCAR-Vollst¨andigkeit
Eine weitere Metrik f¨
ur lokale Produktontologien ist die lokale SCAR-Vollst¨
andigkeit.Siebe-
schreibt die Anzahl an Instanzen f¨
ur welche die f¨
ur die Auswertung durch SCARs ben¨
otigten
Attributen gesetzt sind in Relation zur Anzahl aller Instanzen. Mithilfe dieser Metrik l¨
asst sich
bestimmen, ob Korrespondenzen zwischen lokalen und globalen Instanzen automatisch ermittelt
werden k¨
onnen. Wir definieren die lokale SCAR-Vollst¨
andigkeit wie folgt:
Definition 45 (Lokale SCAR-Vollst¨
andigkeit). Die lokale SCAR-Vollst¨
andigkeit (Lo-
calSCARCompleteness) beschreibt das Verh¨
altnis der Anzahl von Instanzen, deren SCAR-
Attribute gesetzt sind (IndSCAR), in Relation zur Anzahl der Instanzen von IndL(abzgl.
der Menge ausgeschlossener Instanzen IndIgnore
L):
LocalSCARCompleteness “|IndSCAR|
|IndLzIndIgnore
L|Pr0,1s
mit IndSCAR “tind PIndL|Dsc PSCLDattrLPAttrLDattrV al PAttrV alL
DpattrL, attrG,AMCqPSCAR :psc, attrLqPhasAttributeL^
pattrV al, attrLqPreferencesL^pind, attrV alqPhasV alueLu
7.2.3. Lokale SCAA-Vollst¨andigkeit
Die lokale SCAA-Vollst¨
andigkeit beschreibt die Anzahl der Instanzen, f¨
ur welche die f¨
ur SCAAs
ben¨
otigte Attribute gesetzt sind, in Relation zu allen Instanzen (exklusive der ausgeschlosse-
nen Instanzen). W¨
ahrend die lokale SCAR-Vollst¨
andigkeit bestimmt, ob Korrespondenzen zwi-
schen lokalen und globalen Instanzen automatisch ermittelt werden k¨
onnen, bestimmt die lokale
SCAA-Vollst¨
andigkeit, ob lokale Attribute in die globale Produktontologie integrierbar sind.
Definition 46 (Lokale SCAA-Vollst¨
andigkeit). Die lokale SCAA-Vollst¨
andigkeit (Lo-
calSCAACompleteness) ist das Verh¨
altnis der Anzahl von Instanzen, dessen SCAA-Attribute
gesetzt sind (|IndSCAA|) in Relation zur Anzahl aller Instanzen |IndL|ohne die ausgeschlos-
senen Instanzen |IndIgnore
L|:
163
7. Bestimmung der Integrationsqualit¨
at
LocalSCAACompleteness “|IndSCAA|
|IndLzIndIgnore
L|Pr0,1s
mit
IndSCAA “tind PIndL|DpscL,sc
G,pattrL1, attrG1, behavior1q,...,
pattrLn, attrGn, behaviornqq P SCAA :@attr PpattrL1,...,attr
Lnq
DattrV alLPAttrV alL^pattrV alL, attrqPreferencesL
^pind, attrV alLqPhasV alueLu
7.2.4. Kombination aus SCAR- und SCAA-Vollst¨andigkeit
F¨
ur die Integration von Instanzen einer lokalen Produktontologie ist die lokale SCAR-Vollst¨
an-
digkeit nur eine hinreichende Bedingung. Zwar k¨
onnen Instanzen andere Attribute f¨
ur SCARs
beinhalten, ohne jedoch Werte f¨
ur SCAAs zu besitzen. Erst wenn ausreichend Instanzen neben
Attributwerten f¨
ur SCARs auch Werte f¨
ur SCAAs besitzen, damit eine automatische Integration
gestartet werden. Die lokale SCAR- und SCAA-Vollst¨
andigkeit definieren wir wie folgt:
Definition 47 (Lokale SCAR- und SCAA-Vollst¨
andigkeit). Die lokale SCAR- und
SCAA-Vollst¨
andigkeit (LocalSCARSCAACompleteness) ist die Anzahl der Instanzen, deren
SCAR-Attribute (IndSCAR) und SCAA-Attribute (IndSCAA) gesetzt sind, im Verh¨
altnis
zur Anzahl aller Instanzen (exklusive ausgeschlossener):
LocalSCARSCAACompleteness “|IndSCAR XIndSCAA|
|IndLzIndIgnore
L|
7.2.5. Lokale Instanz-Vollst¨andigkeit
Da die Integration der Instanzen nicht vollst¨
andig automatisiert werden kann, m¨
ussen Korre-
spondenzen von Instanzen aus lokalen Produktontologien und globaler Produktontologie ma-
nuell gepflegt werden. Um diesen manuellen Integrationsprozess zu ¨
uberwachen, wird die lokale
Instanz-Vollst¨
andigkeit (engl. Local Individual Completeness) ermittelt. Diese ist das Verh¨
altnis
der Anzahl von Instanzen, die mindestens eine Korrespondenz zu einer Instanz in der globalen
Produktontologie haben, zu allen vorhandenen Instanzen der lokalen Produktontologie. Sind
beide Mengen gleich, wird die lokale Produktontologie als lokal Instanz-Vollst¨
andig bezeichnet.
Die Metrik wird sowohl von Integrationsexperten als auch dem Integration Board w¨
ahrend des
gesamten Integrationsprozess genutzt.
Definition 48 (Lokale Instanz-Vollst¨
andigkeit). Die lokale Instanz-Vollst¨
andigkeit
(LocalIndividualCompleteness) ist das Verh¨
altnis der Anzahl von Instanzen IndMapped
Leiner
lokalen Produktontologie, f¨
ur die mindestens eine Korrespondenz auf eine Instanz in der
globalen Produktontologie besteht, zur Anzahl aller Instanzen der lokalen Produktontologie
IndL(abzgl. der Anzahl ausgeschlossener Instanzen IndIgnore
L):
164
7.3. Metriken f¨
ur globale Produktontologien
LocalIndividualCompleteness “|IndMapped
L|
|IndLzIndIgnore
L|Pr0,1s
mit IndMapped “tindLPIndL|DpindL,ind
G, scarqPCorrespondencesu
scar PSCAR sowie indGPIndG
7.3. Metriken f¨ur globale Produktontologien
W¨
ahrend die bisher vorgestellten Metriken auf lokale Produktontologien fokussieren, k¨
onnen in
eine globale Produktontologie eine Vielzahl lokaler Produktontologien integriert sein. Vollst¨
an-
digkeit- und Konsistenzmetriken beziehen sich im Kontext einer globalen Produktontologie dem-
zufolge potenziell auf eine Vielzahl an lokalen Produktontologien.
7.3.1. Globale Schemakonzept-Vollst¨andigkeit
Die globale Schemakonzept-Vollst¨
andigkeit (engl. Global Schema Concept Completeness)be-
stimmt den Anteil derjenigen Schemakonzepte einer globalen Produktontologie, f¨
ur die min-
destens eine Schemakonzept-Attributregel definiert ist. Mit Hilfe dieser Metrik kann ¨
uberpr¨
uft
werden, ob alle Schemakonzepte der globalen Produktontologie tats¨
achlich verwendet werden.
Wird die globale Produktontologie beispielsweise nach dem Top-Down-Ansatz modelliert (vgl.
Abschnitt 6.2.4), sollte nach Abschluss der manuellen Integration f¨
ur jedes Schemakonzept der
globalen Produktontologie mindestens eine Schemakonzept-Attributregel vorhanden sein. An-
derenfalls wurde entweder ein globales Schemakonzept modelliert, welches nicht ben¨
otigt wird,
oder die Integration eines lokalen Schemakonzepts wurde ¨
ubersehen.
Definition 49 (Globale Schemakonzept-Vollst¨
andigkeit). F¨
ur eine Menge an Produkt-
ontologie-Mappings {P OMappingL1ˆG,...,POMapping
LnˆG}ist die globale Schemakon-
zept-Vollst¨
andigkeit (GlobalSchemaConceptCompleteness)dasVerh
¨
altnis globaler Schema-
konzepte, f¨
ur die mindestens eine SCAR definiert ist (SCMapped
G), zur Menge aller Schema-
konzepte (SCG):
GlobalSchemaConceptCompleteness “|SCmapped
G|
|SCG|
mit SCmapped
G“tsc1
G,...,sc
k
GPSCG|psc1
L1,sc
1
Gq,psc2
L1,sc
2
Gq,...,pscm
Ln,sc
k
Gq
PSCARL1xG ď...ďSCARLnˆGu
7.3.2. Globale Instanz-Vollst¨andigkeit
Hauptziel der Integration von Produktdaten ist es, fachliche Anwendungsf¨
alle zu unterst¨
utzen.
Beispiele f¨
ur solche Anwendungsf¨
alle sind die Erstellung physischer Prototypen (z.B. Versuchs-
fahrzeug) oder Plausibilit¨
ats¨
uberpr¨
ufungen. Da die Erstellung physischer Prototypen sehr aufw¨
an-
dig und teuer ist, m¨
ussen die integrierten Produktdaten vollst¨
andig integriert werden, d.h. es
d¨
urfen keine Informationen fehlen. Aus diesem Grund m¨
ussen alle Instanzen aus der globalen
165
7. Bestimmung der Integrationsqualit¨
at
Produktontologie mit mindestens einer Instanz aus einer lokalen Produktontologie assoziiert wer-
den. Die Vollst¨
andigkeit der Korrespondenzen von Instanzen aus der globalen Produktontologie
in die lokalen Produktontologien wird als globale Instanz-Vollst¨
andigkeit (engl. Global Individu-
al Completeness) bezeichnet. Formal gibt diese Metrik das Verh¨
altnis derjenigen Instanzen der
globalen Produktontologie, die ¨
uber mindestens eine Korrespondenz zu einer lokalen Produk-
tontologie verf¨
ugen, zu allen Instanzen der globalen Produktontologie.
Durch die Definition einer lokalen Masterproduktontologie ist f¨
ur jede Instanz der globalen
Produktontologie eine Korrespondenz vorhanden. Folglich m¨
ussen die Instanzen der lokale Mas-
terproduktontologie von der Bestimmung ausgenommen werden. Werden Instanzen in der globa-
len Produktontologie manuell angelegt, ist dieses Kriterium weiter notwendig. Die Metrik wird
von Integrationsexperten und dem Integration Bord w¨
ahrend des gesamten Integrationsprozess
¨
uberwacht.
Definition 50 (Globale Instanz-Vollst¨
andigkeit). F¨
ur eine Menge an Produktonto-
logie-Mappings {P OMappingL1xG,...,POMapping
LnxG}ist die globale Instanzvollst¨
andig-
keit (GlobalIndividualCompleteness) die Anzahl der Instanzen der globalen Produktontolo-
gie, f¨
ur die mindestens eine Korrespondenz auf eine Instanz in einer lokalen Produktontologie
vorhanden ist, in Relation zu allen Instanzen.
GlobalIndividualCompleteness “|IndMapped
G|
|IndG|Pr0,1s
Die Menge der Instanzen einer globalen Produktontologie IndMapped
L,f
¨
ur die mindestens
eine Korrespondenz auf eine lokale Instanz vorhanden ist wie folgt definiert:
IndMapped
G“tind PIndG|DpindL, ind, scarqPCorrespondencesu
mit scar PSCAR sowie indLPIndL
7.3.3. Globale Instanzattribut-Vollst¨andigkeit
Produktdaten entwickeln sich ¨
uber die Zeit. Daher werden die einzelnen Attribute zu unter-
schiedlichen Zeitpunkten erfasst und dokumentiert. D.h., bei der initialen Integration fehlen
ggf. Attributwerte f¨
ur die Auswertung von SCARs oder SCAAs k¨
onnen nicht ausgef¨
uhrt werden.
Da diese Attribute ggf. f¨
ur Anwendungsf¨
alle ben¨
otigt werden, m¨
ussen sie auf Vollst¨
andigkeit
¨
uberpr¨
uft werden. Die globale Instanzattribut-Vollst¨
andigkeit (engl. Global Individual Attribute
Completeness) ist das Verh¨
altnis von Instanzen einer globalen Produktontologie, die f¨
ur jedes
Attribute einen Wert besitzen, zu allen Instanzen dieser Produktontologie. Die Metrik wird
sowohl von Integrationsexperten als auch vom Integration Board w¨
ahrend des gesamten Inte-
grationsprozesses kontrolliert.
Definition 51 (Globale Instanzattribut-Vollst¨
andigkeit).
F¨
ur eine Menge an Produktonto-logie-Mappings {P OMappingL1ˆG,...,POMapping
LnˆG}
ist die globale Instanzattribut-Vollst¨
andigkeit (GlobalIndividualAttributeCompleteness)das
166
7.3. Metriken f¨
ur globale Produktontologien
Verh¨
altnis der Anzahl globaler Instanzen f¨
ur die alle Attribut einen Wert
besitzen (|IndAttrV al
G|), zur Anzahl aller globalen Instanzen (|IndG|):
GlobalIndividualAttributeCompleteness “|IndAttrV al
G|
|IndG|Pr0,1s
mit IndAttrV al
G“tind PIndG|DscGPSCGDpsc, indqPhasIndividual
Dpattr1,...,attr
nqPAttrGund es gilt @attr Ppattr1,...,attr
nqDattrV al PAttrV alG
^DpattrV al, attrqPreferencesG^Dpind, attrV alqPhasV alueGu
7.3.4. Globale Instanzattribut-Konsistenz
Entwickler und Ingenieure arbeiten in der Regel mit lokalen Kopien von Produktdaten. Haben
diese einen bestimmten Entwicklungsstand erreicht, werden sie ¨
uber ¨
Anderungsmanagement-
prozesse bewertet. Freigegebene Produktdaten werden anschließend im Produktdatenmanage-
mentsystem abgelegt. Nicht alle Applikationen (z.B. bereichsspezifische Spezialapplikationen)
unterliegen einem zentralen ¨
Anderungsmanagement, bzw. ¨
Anderungen werden erst ab einem
definierten Zeitpunkt im Entwicklungsprozess zentral verwaltet. So kann es vorkommen, dass in
unterschiedlichen Informationssystemen unterschiedliche Entwicklungsst¨
ande von Produktdaten
dokumentiert sind.
Nach der initialen Integration k¨
onnen Korrespondenzen von Instanzen mehrerer lokaler Produk-
tontologien auf eine einzelne Instanz in der globalen Produktontologie existieren. Sind in den
jeweiligen Schemakonzepten SCAAs definiert, die in das selbe Attribut in der globalen Produk-
tontologie integrieren, kann es zu Integrationskonflikten kommen. Dies ist z.B. der Fall, wenn
ein Produktaspekt in mehreren Informationssystemen unterschiedlich dokumentiert wird. Wird
in einem dieser Informationssysteme der Attributwert ge¨
andert, kann es vorkommen, dass diese
¨
Anderung nicht an die anderen Informationssysteme weiter propagiert wird. Folglich wird eine
Metrik ben¨
otigt, um derartige Integrationskonflikte zu erkennen.
Die globale Instanzattribut-Konsistenz (engl. Global Individual Attribute Consistency)istdas
Verh¨
altnis der Anzahl von Instanzen einer globalen Produktontologie, deren Attributwerte kon-
sistent sind, d.h. die keine Integrationskonflikte aufweisen, zur Anzahl aller Instanzen der On-
tologie. Eine Instanz ist inkonsistent, wenn es mindestens zwei SCAAs aus zwei unterschiedli-
chen lokalen Produktontologien gibt, die auf das gleiche Attribut eines Schemakonzeptes in der
globalen Produktonologie verweisen und es mindestens zwei Instanzen aus diesen lokalen Pro-
duktontologien gibt, die auf die selbe Instanz in der globalen Produktontologie verweisen und
unterschiedliche Attributwerte f¨
ur die SCAAs besitzen. Sind die Attributwerte aller Instanzen der
globalen Produktontologie konsistent, wird diese als global Instanzattribut-Konsistent bezeich-
net. Die Metrik wird sowohl von Integrationsexperten als auch dem Integration Board w¨
ahrend
des gesamten Integrationsprozesses ¨
uberwacht. Sie ist folgendermaßen definiert.
Definition 52 (Globale Instanzattribut-Konsistenz). F¨
ur eine Menge an Produktonto-
logie-Mappings {P OMappingL1ˆG,...,POMapping
LnˆG}ist die globale Instanzattribut-
Konsistenz (GlobalIndividualAttributeCompleteness) des Verh¨
altnis der Anzahl inkonsis-
tenter globalen Instanzen (|IndInconsistent
G|) zur Anzahl aller globalen Instanzen (|IndG|):
167
7. Bestimmung der Integrationsqualit¨
at
GlobalIndividualAttributeCompleteness “1´|IndInconsistent
G|
|IndG|Pr0,1s
mit IndInconsistent
G“tind PIndG|DpindL1,indq,...,pindLn,indqPCorrespondences
DpattrL, attrG,AAqPSCAA DattrV alL1,...,attrVal
LmPAttrV alL
DpattrV alL1, attrLq,...,pattrV alLm, attrLqPreferencesL
DpindL1, attrV alL1q,...,pindLm, attrV alLmqPhasV alueL
und es gilt |pattrV alL1, ldots, attrV alLmq| ą 1uf¨
ur mďn
7.4. Integrationsplanung und -¨uberwachung
Die manuelle Integration von Produktdaten erfordert, je nach Anzahl der Instanzen und At-
tributwerte, eine gewisse Zeit. Um den Integrationsprozess zu steuern und ihn zu ¨
uberwachen,
ist es notwendig, zuvor definierte Soll-Zust¨
ande der Integrationsmetriken mit vorhandenen Ist-
Zust¨
anden abzugleichen. Bei Abweichungen zwischen Soll- und Ist-Zust¨
anden einzelner Metriken
k¨
onnen dann geeignete Gegenmaßnahmen getroffen werden. Dies k¨
onnte z.B. die Erh¨
ohung der
Mitarbeiterzahl oder die Verschiebung des Nutzungszeitpunktes sein. Die Definition von Soll-
Zust¨
anden einzelner Metriken geschieht durch das Integration Bord in Zusammenarbeit mit den
Fach- sowie Integrationsexperten. Ein Soll-Wert einer Integrationsmetrik ist wie folgt definiert:
Definition 53 (Soll-Wert). F¨
ur eine Menge an Produktontologie-Mappings
tP OMappingL1ˆG,...,POMapping
LnˆGuist ein Soll-Wert (MetricReferenceValue)einTu-
pel
pM,T,V qPMetricReferenceV alue mit
•MPtLocalSCCompleteness, LocalSCARCompleteness,
LocalSCAACompleteness, GlobalSchemaConceptCompleteness, . . .uist eine Integra-
tionsmetrik,
•Tist ein diskreter Zeitpunkt,
•VPr0,1sist ein reeller Wert.
Die Metriken zur Bewertung der Integrationsqualit¨
at betrachten den Stand der Integration zum
aktuellen Zeitpunkt. Sie werden jedoch in unterschiedlichen Phasen der Produktdatenintegration
ben¨
otigt. Der Prozess l¨
asst sich in zwei Phasen unterteilen, die durch jeweils zwei Zeitpunkte t1
und t2abgeschlossen werden.
Zum Zeitpunkt t0beginnt die Phase 1 mit der manuellen Schemaintegration. Hier werden fol-
gende Metriken ben¨
otigt: Lokale Schemakonzept-Vollst¨
andigkeit,Lokale SCAR-SCAA-Vollst¨
an-
digkeit und Globale Schemakonzept-Vollst¨
andigkeit. Die erste Phase endet mit dem Zeitpunkt
t1, zu dem die automatische Instanzintegration gestartet wird. Der Zeitpunkt der automati-
schen Instanzintegration ist fest definiert. Um diesen Zeitpunkt einhalten zu k¨
onnen, m¨
ussen
Soll-Zust¨
ande f¨
ur die vorangehend genannten Metriken definiert werden. Bei Abweichungen zwi-
schen Ist- zu Soll-Zust¨
anden an definierten Zeitpunkten wiederum k¨
onnen geeignete Maßnahmen
beschlossen werden, um den Termin der automatischen Instanzintegration einhalten zu k¨
onnen.
168
7.4. Integrationsplanung und -¨
uberwachung
Voraussetzung f¨
ur die automatische Instanzintegration sind folgende Werte f¨
ur die einzelnen
Metriken:
•LocalSCCompleteness “1, d.h. f¨
ur all Schemakonzepte aller lokalen Produktontologien
sind SCARs definiert.
•LocalSCARSCAACompleteness ěthreshold, d.h. die Anzahl der Instanzen, die Attri-
butwerte besitzen, die f¨
ur das Matching sowie die Integration notwendig sind, ¨
uberschreitet
einen definierten Schwellenwert (threshold).
Damit zum Zeitpunkt t1diese Zust¨
ande erreicht werden, ist es notwendig, den Verlauf der
Metriken zu ¨
uberwachen. Dazu werden Soll-Zust¨
ande s1
0,...,s
1
nzu Zeitpunkten zwischen t0
und t1definiert. An diesen Zeitpunkten werden Soll- und Ist-Zust¨
ande der definierten Metriken
abgeglichen. Soll- und Ist-Zust¨
ande lassen sich als Graph darstellen. Abbildung 7.1 illustriert
beispielhaft den zeitlichen Verlauf von Ist-Zust¨
anden f¨
ur verschiedene Integrationsmetriken vom
Zeitpunkt t0bis zur automatischen Instanzintegration zum Zeitpunkt t1.
*OREDO6&&RPSOHWHQHVV
/RFDO6&&RPSOHWHQHVV
/RFDO6&$56&$$&RPSOHWHQHVV
Abbildung 7.1.: Zeitlicher Verlauf der Metriken in Phase 1
Die Zust¨
ande f¨
ur t1und t2sowie die Zeitpunkte der Soll-Zust¨
ande werden durch das Inte-
gration Bord in Zusammenarbeit mit Integrationsexperten definiert. Die Zust¨
ande basieren auf
Erfahrungen dieser Experten, d.h. in den ersten Integrationsprojekten k¨
onnen die Abweichungen
zwischen Soll- und Ist-Zust¨
anden signifikant sein.
In Abbildung 7.1 sind, neben dem Verlauf der Ist-St¨
ande ¨
uber die Zeit zwischen t0und t1,drei
Soll-Zust¨
ande f¨
ur folgenden Integrationsmetriken definiert: 1
1Soll-Zust¨
ande k¨
onnen f¨
ur jede Integrationsmetrik zu verschiedene Zeitpunkten definiert werden.
169
7. Bestimmung der Integrationsqualit¨
at
•GlobalSCCompleteness “.53
•LocalSCCompleteness “.42
•LocalSCARSCAACompleteness “.28
W¨
ahrend der Ist-Zustand der lokalen Schemakonzept-Vollst¨
andigkeit zum Zeitpunkt s1
1in et-
wa dem definierten Referenzwert entspricht, sind die Ist-Zust¨
ande der globalen Schemakonzept-
Vol lst¨
andigkeit sowie die lokale SCAR-SCAA-Vollst¨
andigkeit deutlich unter den definierten Soll-
Zust¨
anden. Zum Zeitpunkt s1
1analysiert das Integration Bord die Ist- und Soll-Zust¨
ande der
verschiedenen Metriken und definiert ggf. notwendige Maßnahmen f¨
ur den Integrationsprozess.
Schließlich sind zum Zeitpunkt t1folgende Soll-Zust¨
ande definiert:
•GlobalSCCompleteness “1
•LocalSCCompleteness “1
•LocalSCARSCAACompleteness “0.5
Nach der automatischen Instanzintegration beginnt die Phase 2 mit der manuellen Instanzin-
tegration, in der folgende Metriken f¨
ur die Globale Instanz-Vollst¨
andigkeit und Globale Instanz-
Konsistenz ben¨
otigt werden. Analog zur ersten Phase werden auch f¨
ur die manuelle Instanzinte-
gration Soll-Zust¨
ande der einzelnen Metriken zu verschiedenen Zeitpunkten definiert. Die zweite
Phase endet mit dem Zeitpunkt t2ab dem die Nutzung beginnt. Um zum Zeitpunkt t2mit der
Nutzung der integrierten Produktdaten beginnen zu k¨
onnen, ist es auch f¨
ur die zweite Phase
notwendig, Soll-Zust¨
ande s2
0,...,s
2
mzu Zeitpunkten zwischen t1und t2zu definieren. Abbildung
7.2 illustriert den Verlauf des vorherigen Beispiels ab dem Zeitpunkt t1bis zur Nutzung ab
Zeitpunkt t2.
Zwischen t1und t2sind zwei Zeitpunkte s2
1und s2
2definiert, zu denen jeweils Soll-Zust¨
ande
f¨
ur die globale Instanz-Vollst¨
andigkeit sowie globale Instanz-Konsistenz definiert sind. W¨
ahrend
der Ist-Zustand f¨
ur die globale Instanz-Konsistenz zum Zeitpunkt s2
1etwa dem Soll-Zustand
entspricht, ist der Ist-Zustand der globalen Instanz-Vollst¨
andigkeit geringer. Analog zur ersten
Phase analysiert und bewertet das Integration Bord die Ist- und Soll-Zust¨
ande zu den einzelnen
Zeitpunkten. Voraussetzung f¨
ur die Anwendungsfallnutzung sind folgende Soll-Zust¨
ande zum
Zeitpunkt t2:
•GlobalIndCompleteness “1
•GlobalIndConsistency “1
F¨
ur das Beispiel aus Abbildung 7.2 sind in Tabelle 7.1 die Soll-Zust¨
ande f¨
ur die Produktontologie-
Mappings P OMappingL1ˆG,...,POMapping
LnˆGzusammengefasst:
170
7.4. Integrationsplanung und -¨
uberwachung
Abbildung 7.2.: Zeitlicher Verlauf der Metriken in Phase 2
Metrik Zeitpunkt Soll-Zustand
GlobalSCCompleteness s1
10.53
LocalSCCompleteness s1
10.42
LocalSCARSCAACompleteness s1
10.28
GlobalSCCompleteness t11
LocalSCCompleteness t11
LocalSCARSCAACompleteness t10.5
GlobalIndCompleteness s2
10.4
GlobalIndConsistency s2
10.84
GlobalIndCompleteness s2
10.7
GlobalIndConsistency s2
10.9
GlobalIndCompleteness t21
GlobalIndConsistency t21
Tabelle 7.1.: Soll-Zust¨
ande f¨
ur das Beispiel aus Abbildung 7.2
171
8. Evolution integrierter Produktdaten
Produktdaten unterliegen kontinuierlichen ¨
Anderungen, sei es infolge von Optimierungen oder
aufgrund neuer Standards, Regularien oder Gesetze [RW12, MRB08]. Folglich sollte ein Pro-
duktdatenintegrationsframework die Evolution von bereits integrierten Schemata und Instan-
zen unterst¨
utzen muss. Im Folgenden werden ¨
Anderungsszenarien beschrieben, die nach einer
initialen Integration auftreten k¨
onnen. F¨
ur alle Szenarien wird angenommen, dass die Integra-
tionsmenge vollst¨
andig und konsistent ist. Die in Kapitel 6 beschrieben Prozesse definieren die
notwendigen Aufgaben der einzelnen Rollen, um Produktdaten vollst¨
andig und konsistent zu
integrieren. Da Produktdaten kontinuierlichen ¨
Anderungen unterliegen ist diese statische Be-
trachtung nicht ausreichend. Vielmehr muss das PROCEED-Rahmenwerk die M¨
oglichkeit bieten,
sowohl auf Schema- als auch Instanz¨
anderungen einzelner lokaler Produktontologien reagieren
zu k¨
onnen.
Die in diesem Kapitel beschriebenen ¨
Anderungsprozesse sind reaktiv, d.h. wenn eine ¨
Anderung
an Instanzen bzw. Schemakonzepten vorgenommen wird, werden diese vom PROCEED-Rahmen-
werk erkannt. Anschließend werden Aktionen durchgef¨
uhrt, um die Konsistenz und Vollst¨
andig-
keit der globalen Produktontologie wieder herzustellen.
Die Attribute von Produktdaten werden meist zu unterschiedlichen Zeitpunkten festgelegt. Bei
der initialen Integration etwa k¨
onnen Attributwerte fehlen, die f¨
ur die Integration von Instanzen
notwendig sind, (z.B. zwecks Auswertung von SCARs oder Ausf¨
uhrung von SCAAs). Ein weiteres
Szenario f¨
ur die ¨
Anderung von Instanzattributwerten ist die Beseitigung von Fehlern.
Neben ¨
Anderungen auf Instanzebene kann es vorkommen, dass die Datenmodelle lokaler Infor-
mationssysteme angepasst werden sollen, etwa nach der Erweiterung von Informationssystemen
um neue Funktionen. Diese ¨
Anderungen an verschiedenen Artefakten lokaler Produktontologien
(Schemakonzepte, Instanzen, Korrespondenzen, Abbildungs- und Integrationsregeln) haben Ein-
fluss auf den Zustand der aktuellen Integration. Einige ¨
Anderungen lassen sich automatisieren,
w¨
ahrend andere manuelle Interaktionen erfordern.
Zus¨
atzlich zu ¨
Anderungen an Produktdaten kann es notwendig werden, ¨
Anderungen an Konzep-
ten oder gar Abbildungsregeln und -aktionen vorzunehmen. Im Folgenden werden die ¨
Anderungs-
operationen, inklusive der notwendigen Schritte, beschrieben, um diese ¨
Anderungen zu realisie-
ren.
Zun¨
achst wird in Abschnitt der sog. Ripple-Effect erl¨
autert. Demnach kann eine einzelne ¨
Ander-
ung eine Welle weiterer ¨
Anderungen bedingen, ohne dass letztere zu Beginn der ¨
Anderung
direkt ersichtlich waren. Im Abschnitt 8.2 werden ¨
Anderungsoperationen auf Datenebene, d.h.
¨
Anderungen f¨
ur Instanzen, Korrespondenzen und Attributwerte behandelt und zwar sowohl f¨
ur
lokale als auch globale Produktontologien. Abschnitt 8.3 befaßt sich mit ¨
Anderungsoperationen
auf Schemaebene, d.h. mit ¨
Anderungen an Schemakonzepten, Attributen, Schemakonzept-Attri-
butregeln und -Attributaktionen.
173
8. Evolution integrierter Produktdaten
8.1. Ripple-Effekt
¨
Anderungen im Allgemeinen und das L¨
oschen einer Korrespondenz im Speziellen k¨
onnen Auswir-
kungen auf weitere Korrespondenzen haben. Abbildung 8.1 zeigt drei unterschiedliche Szenarien
f¨
ur das L¨
oschen von Korrespondenzen. Die Korrespondenz cor2zwischen lokaler Instanz Bund
globaler Instanz Yeiner Produktdatenintegrationsebene Layer wird gel¨
oscht. Auf der darunter
liegenden Produktdatenintegrationsebene Layer+1 befindet sich eine Instanz B1,dieBzugeord-
net ist. F¨
ur letztgenannte Instanz existieren korrespondierende globale Instanzen Y1,Y2 und
Y3 ¨
uber die Korrespondenzen cor5,cor6 und cor7. Nachdem die Korrespondenz cor2 gel¨
oscht
wurde, m¨
ussen folglich auch die Korrespondenzen cor5,cor6 und cor7 gel¨
oscht werden. Exis-
tieren zu B1 wiederum Instanzen auf der Produktdatenintegrationsebene unterhalb von Layer+1
wird dieser Vorgang auch f¨
ur diese Instanzen fortgesetzt.
$
%
&
;
<
<
<
=
6&$5
6&$5
6&
6&
6&
6&
Abbildung 8.1.: Kaskadierender Effekt beim L¨
oschen von Korrespondenzen
¨
Anderungen wirken sich nicht nur kaskadierend innerhalb einer lokalen Produktontologie aus,
sondern k¨
onnen sich auch ¨
uber mehrere lokale Produktontologien erstrecken. Dies ist dann
der Fall, wenn Attribute globaler Schemakonzepte durch SCAAs einer lokalen Produktontologie
bef¨
ullt werden und gleichzeitig durch SCARs genutzt werden. In Abbildung 8.2 ist ein solches
Beispiel dargestellt. Wird der Attributwert REF von ind M 1 ge¨
andert, muss diese ¨
Anderung
in die globale Produktontologie propagiert werden. Das ge¨
anderte Attribut wird durch SCAR2
und SCAR3 der lokalen Produktontologien L1 und L2 verwendet. Folglich m¨
ussen die bestehen-
de Korrespondenzen cor2 und cor3 gel¨
oscht und die SCARs SCAR2 und SCAR3 erneut aus-
gewertet werden. Ggf. werden nun SCAAs (SCAA2, SCAA3) wiederholt ausgef¨
uhrt. Infolge die-
ser neuen Ausf¨
uhrung werden in der globalen Produktontologie m¨
oglicherweise Attributwerte
ge¨
andert (z.B. Name und Requirement), die wiederum durch SCARs (SCAR3) weiterer lokaler
Produktontologien (L2) verwendet werden. Durch diese ¨
Anderung m¨
ussen existierende Korre-
spondenzen zwischen lokaler Produktontologie L1 und globaler Produktontologie G, die durch
die Schemakonzept-Attributregel SCAR3 zustande gekommen sind, ggf. gel¨
oscht bzw. neue Kor-
respondenzen erstellt werden.
174
8.1. Ripple-Effekt
6&B0B
FRU
1DPH
5()
'HVF
7XHU
'0
>«@
6&B*B
1DPH
,'
5HTXLUHPHQW
'RRU
'0
'RRUGRF
*HRPHWU\
'225MW
6&$5 6&B/B
1DPH
$EEUHY
5HT
'RRU
'0
'RRUGRF
6&$$
6&B/B
1DPH
0RGHO
'HVF
'RRU
'225MW
>«@
FRU
6&$5
6&$$
6&$5
6&$$
FRU
LQGB0B LQGB*B LQGB/B
LQGB/B
6&$$
/RFDO0DVWHU3URGXFW2QWRORJ\0 *OREDO3URGXFW2QWRORJ\* /RFDO3URGXFW2QWRORJ\/
/RFDO3URGXFW2QWRORJ\/
Abbildung 8.2.: Auswirkungen einer Instanz¨
anderung
Die Auswirkungen von ¨
Anderungen lassen sich grafisch in Form von ripple-Graphen darstellen
(siehe Abbildung 8.3). Im Zentrum befindet sich die Instanz der initialen ¨
Anderung ind M 1.Auf
dem n¨
achst ¨
außeren Ring befinden sich die Instanzen, die direkt von der ¨
Anderung betroffen
sind (ind G 1). ¨
Anderungen, die durch direkten Instanzen hervorgerufen werden, werden auf den
n¨
achst ¨
außeren Ringen dargestellt (ind L1 1,ind L2 1).
LQGB0B
LQGB*B
LQGB/B LQGB/B
Abbildung 8.3.: Ripple-Graph f¨
ur die Darstellung einer Instanz¨
anderung
175
8. Evolution integrierter Produktdaten
8.2. Instanz¨anderungen
Im Folgenden wird der Ablauf von ¨
Anderungen mittels BPMN1-Prozessmodellen illustriert. Ab-
bildung 8.4 zeigt die verwendeten Symbole. Ein Prozess beginnt mit einem Startereignis und
terminiert mit Erreichen eines Endereignisses. Es wird zwischen User Tasks und Service Tasks
unterschieden. W¨
ahrend erstere die Interaktion mit Benutzern erfordern, laufen letztere auto-
matisch ab. Zwischen den Prozessbeteiligten k¨
onnen Nachrichten ausgetauscht und so weitere
Prozesse gestartet werden.
Bedingte Aufsplittung des Kontrollflusses werden in den Prozessmodellen ¨
uber XOR-Gateways
geregelt. Schließlich wird das Element Zeitereignis verwendet, das nach einer bestimmten Zeit
ausgel¨
ost wird.
8VHU7DVN
6HUYLFH7DVN
6WDUWHUHLJQLV (QGHUHLJQLV
6WDUWHUHLJQLV
GXUFKHPSIDQJHQH
1DFKULFKW
(QGHUHLJQLV
PLWVHQGHQHU
1DFKULFKW
1DFKULFKWVHQGHQ 1DFKULFKWHPSIDQJHQ
=HLWHUHLJQLV ;25(QWVFKHLGXQJ
Abbildung 8.4.: Legende der BPMN Symbole
Im Folgenden werden ¨
Anderungen beschrieben, die sich auf Daten lokaler und globaler Produkt-
daten (etwa Korrespondenzen, Instanzen, Attributwerte) auswirken.
8.2.1. Hinzuf¨ugen einer Korrespondenz
Abbildung 8.5 zeigt die notwendigen Schritte nach Erstellung einer neuen Korrespondenz durch
einen Data Quality Engineer (vgl. Abschnitt 6.2.5). Zun¨
achst werden alle SCAAs des entsprechen-
den Schemakonzeptes der lokalen Produktontologie ausgef¨
uhrt. Kommt es bei deren Ausf¨
uhrung
zu Konflikten, die nicht automatisch aufgel¨
ost werden k¨
onnen (siehe Abschnitt 6.2.3), muss ein
Data Quality Engineer eingreifen. Danach werden diejenigen Instanzen der lokalen Produktonto-
logie ermittelt, die sich auf der n¨
achst tieferen Produktdatenintegrationsebene befinden. Wurde
die unterste Ebene erreicht, ist die ¨
Anderung durchgef¨
uhrt und der Data Quality Engineer wird
entsprechend informiert. Anderenfalls werden f¨
ur alle ermittelten Instanzen der n¨
achst tiefe-
1Business Process Model and Notation (BPMN) ist eine grafische Sprache zur Modellierung von
Gesch¨
aftsprozessen.
176
8.2. Instanz¨
anderungen
ren Ebene die SCARs des entsprechenden Schemakonzeptes ausgewertet und Korrespondenzen
erstellt. Dadurch beginnt der Prozess wieder mit der Aktivit¨
at SCAAs ausf¨
uhren.
Konnten f¨
ur einzelne Instanzen keine Korrespondenzen durch die Regeln automatisch bestimmt
werden, muss der Data Quality Engineer diese manuell erstellen oder einzelne Instanzen von der
Integration ausschließen. F¨
ur jede gefundene Instanz werden die SCAAs ausgef¨
uhrt, der Prozess
beginnt dann wieder von vorne bis die letzte Produktdatenintegrationsebene erreicht worden ist.
Abbildung 8.5.: Manuelles Anlegen einer Korrespondenz
Abbildung 8.6 illustriert die verschiedenen Artefakte, die von der ¨
Anderungsoperation betroffen
sind. Die zu erstellende Korrespondenz cor wird f¨
ur eine Instanz indL11 eines Schemakonzepts
scL1und eine Instanz indG11 eines Schemakonzeptes scG1erstellt 1
.Zun
¨
achst werden die ent-
sprechenden SCAAs f¨
ur die Instanz indL11 ausgef¨
uhrt 2
. Anschließend werden die Instanzen
Indsub,diezuindL11 geh¨
oren und auf der n¨
achst tieferliegenden Produktdatenintegrationsebene
liegen, ermittelt 3
.F
¨
ur Indsub werden die SCARs ausgewertet und entsprechende Korrespon-
denzen erstellt 4
.F
¨
ur jede Korrespondenz werden die SCAAs ausgef¨
uhrt 5
. Die letzten drei
Schritte werden solange wiederholt, bis die letzte Produktdatenintegrationsebene erreicht wird.
Abbildung 8.6.: Manuelles Erstellen neuer Korrespondenzen
Algorithmus 4 formalisiert den zuvor beschriebenen Ablauf. Dabei wird angenommen, dass ne-
ben der Korrespondenz cor eine Begr¨
undung erstellt wurde. Anschließend m¨
ussen f¨
ur die In-
stanzen der Korrespondenz alle Schemakonzept-Attributaktionen ausgef¨
uhrt werden (siehe Zei-
177
8. Evolution integrierter Produktdaten
len 3 bis 6). F¨
ur die neue Korrespondenz wird nun ¨
uberpr¨
uft, ob die betroffene Instanz sich
nicht auf der Version-Integrationsebene befindet (siehe Zeile 9). Anschließend wird die Menge
IndCandidatesLaller lokalen Instanzen ermittelt, die sich in der n¨
achst tiefer gelegenen In-
tegrationsebene befinden und zur lokalen Instanz der Korrespondenz geh¨
oren. Analog enth¨
alt
die Menge IndCandidatesGdie betroffenenden globalen Instanzen. F¨
ur das kartesische Produkt
dieser beiden Mengen werden die entsprechenden Schemakonzept-Attributregeln ausgewertet
(vgl. Zeile 17) und bei Treffern Korrespondenzen erstellt und Schemakonzept-Attributaktionen
ausgef¨
uhrt (Zeilen 20 und 21). F¨
ur die gefundenen Korrespondenzen wird der zuvor beschriebe-
ne Vorgang (Zeilen 9 bis 29) so lange wiederholt, bis die letzte Produktdatenintegrationsebene
erreicht wird.
Algorithmus 4 (Korrespondenz hinzuf¨
ugen)
1: procedure AddCorrespondence(cor PCorrespondence)
2: SCAAcur “tscaa PSCAA |Dsc PSCLDpsc, cor.indLqPhasIndividualL
Dpsc, scG,AAqPSCAA mit scGPSCG}
3: for each scaa PSCAAcur do
4: scaaResult “executeSCAApcor, scaaqŹ
2
5: AttrV alJustification “AttrV alJustification Ť
scaaResult.AttrV alJustification
6: end for
7: Correspondencescur “cor
8: for each corcur PCorrespondencescur do
9: if !corcur.indLPIndversion
Lthen
10: IndCandidatesL“pind PIndL|Dpind, corcur.indLqPindBelowLqŹ
3
11: IndCandidatesG“pind PIndG|Dpind, corcur.indGqPindBelowGq
12: for each indcur
LPIndCandidatesLdo
13: for each indcur
GPIndCandidatesGdo
14: sccur
L“tsc PSCL|Dpsc, indcur
LqPhasIndividualLu
15: sccur
G“tsc PSCG|Dpsc, indcur
GqPhasIndividualGu
16: for each scarcur “psccur
L,sc
cur
G,AMCqPSCAR do
17: if evaluateAMCpindcur
L,ind
cur
G, scarcur.AMCqthen
18: newCor “pindcur
L,ind
cur
G, scarcurqŹ
4
19: Justification “Justification ŤpnewCor, scarcurq
20: Correspondences “Correspondences ŤnewCor
21: scaaResult “executeSCAA(newCor)Ź5
22: AttrV alJustification “AttrV alJustification Ť
scaaResult.AttrV alJustification
23: T asklist “T asklist ŤscaaResult.T asklist
24: end if
25: end for
26: end for
27: end for
28: end if
29: end for
30: end procedure
178
8.2. Instanz¨
anderungen
8.2.2. L¨oschen einer Korrespondenz
Abbildung 8.7 zeigt notwendige Schritte nach L¨
oschen einer Korrespondenz durch einen Da-
ta Quality Engineer. Zun¨
achst werden alle SCAAs des entsprechenden Schemakonzeptes in den
korrespondierenden globalen Instanzen r¨
uckg¨
angig gemacht. Danach werden die zugeordneten
Instanzen der lokalen Produktontologie ermittelt, die sich auf der n¨
achst tieferen Produkda-
tentintegrationsebene befinden. F¨
ur jede dieser Instanzen werden alle vorhandenen Instanzen
gel¨
oscht und der Prozess geht von vorne los, solange bis die letzte Ebene erreicht wird. Danach
ist die ¨
Anderung abgeschlossen und der Data Quality Engineer wird entsprechend informiert.
Abbildung 8.7.: Eine Korrespondenz wird manuell gel¨
oscht
Abbildung 8.8 zeigt die Artefakte lokaler und globaler Produktontologien, die von einer ¨
Anderung
betroffen sind. Die Korrespondenz cor1zwischen indL11 und indG11 wird gel¨
oscht 1
. Danach
m¨
ussen zun¨
achst die entsprechenden SCAAs in indG11 der globalen Produktontologie r¨
uckg¨
angig
gemacht werden 2
. In diesem Beispiel ist dies scaa1. Anschließend werden diejenigen Instanzen
ermittelt, die zu indL11 geh¨
oren und die auf der n¨
achst tieferen Produktdatenintegrationsebene
liegen 3
.F
¨
ur jede dieser Instanzen (indL21 und indL22 im Beispiel) werden in den korrespon-
dierenden Instanzen der globalen Produktontologie die SCAAs ebenfalls r¨
uckg¨
angig gemacht 4
.
Schließlich werden die Korrespondenzen von indL21 und indL22 gel¨
oscht 5
. Die Schritte 3
bis
5
werden solange wiederholt, bis die letzte Produktdatenintegrationsebene erreicht ist.
Abbildung 8.8.: Manuelles L¨
oschen einer Korrespondenz
Algorithmus 5 beschreibt eine Hilfsfunktion f¨
ur das L¨
oschen globaler Attributwerte einer Instanz.
179
8. Evolution integrierter Produktdaten
Eingabeparameter sind eine Instanz indGder globalen Produktontologie sowie eine Schemakon-
zept-Attributaktion scaa.F
¨
ur jede Attributaktion werden m¨
ogliche Attributwerte der Instanz
ermittelt und gel¨
oscht (Zeilen 2 bis 4). Schließlich wird eine Begr¨
undung f¨
ur einen Attributwert
gel¨
oscht (Zeilen 5 und 6).
Algorithmus 5 (Globale Attributwerte l¨
oschen)
1: procedure DeleteGlobalAttributValue(indGPIndG, scaa PSCAA)
2: for each aacur Pscaacur.AA do
3: deletedAttrV al “tattrV al PAttrV alG|DpindG, attrV alqPhasV alG^
DpattrV al, attrGqPreferencesGu
4: AttrV alG“AttrV alGzdeletedAttrV al
5: deletedAttrV alJust “tattrV alJust |
DpattrV alJust, scaacurqPAttrV alJustificationu
6: AttrV alJustificationG “AttrV alJustificationzdeletedAttrV alJust
7: end for
8: end procedure
Algorithmus 6 l¨
oscht die Korrespondenz cor.Zun
¨
achst muss die Begr¨
undung der gel¨
oschten Kor-
respondenz entfernt werden (Zeilen 4 bis 5). F¨
ur alle Schemakonzept-Attributaktionen m¨
ussen
die entsprechenden Attribute (inklusive Begr¨
undungen) in den korrespondierenden globalen In-
stanzen entfernt werden (Zeilen 6 bis 9). Anschließend werden die Korrespondenz gel¨
oscht und
alle Instanzen unterhalb der lokalen Instanz ermittelt (Zeilen 10 und 11). F¨
ur jede Instanz, f¨
ur
die eine Korrespondenz existiert, wird der Algorithmus rekursiv aufgerufen (Zeilen 12 bis 16).
Algorithmus 6 (Korrespondenz l¨
oschen)
1: procedure DeleteCorrespondence(cor PCorrespondence)
2: Correspondencescur “cor
3: for each corcur PCorrespondencescur do
4: justificationcur “tjPJustification |Dpcorcur,jqPJustificationu
5: Justification “Justificationzjustificationcur
6: SCAAcur “tscaa PSCAA |Dsc PSCLDscGPSCG
Dpsc, corcur.indLqPhasIndividualLDpsc, scGqPSCAAu
7: for each scaacur PSCAAcur do
8: DeleteGlobalAttributV aluespcorcur.indG, scaacurq
9: end for
10: Correspondences “Correspondenceszcorcur
11: Indsub
L“tind PIndL|Dpind, corcur.indLqPindBelowLu
12: for each indsub,cur
LPIndsub
Ldo
13: if Dpindsub,cur,ind
GqPCorrespondece then
14: DeleteCorrespondenceppindsub,cur,ind
Gqq
15: end if
16: end for
17: end for
18: end procedure
180
8.2. Instanz¨
anderungen
8.2.3. Hinzuf¨ugen einer Instanz
Abbildung 8.9 illustriert den Prozess nach Erstellung einer neuen lokalen Instanz f¨
ur ein Schema-
konzept. Wird eine neue Instanz erstellt, werden f¨
ur sie die vorhandenen SCARs ausgewertet. F¨
ur
die gefundenen Korrespondenzen wiederum werden alle definierten SCAAs ausgewertet. Treten
w¨
ahrend dieser Auswertung Integrationskonflikte auf, die nicht automatisch aufgel¨
ost werden
k¨
onnen, wird ein Data Quality Engineer entsprechend informiert. Wurde die neue Instanz nicht
auf der Version-Ebene hinzugef¨
ugt, muss f¨
ur jede Ebene unterhalb der ¨
Anderung mindestens
eine zugeordnete Instanz erstellt werden.
Abbildung 8.9.: Eine neue Instanz wurde hinzugef¨
ugt
Abbildung 8.10 zeigt exemplarisch das Erstellen einer neuen Instanz indL22 f¨
ur ein Schema-
konzept scL2PSCL1
. Zuerst werden die vorhandenen Schemakonzept-Attributregeln (SCARs)
scar2f¨
ur indL22 und die potenziell korrespondierenden Instanzen aus der globalen Produktonto-
logie Indcandidates
Gausgewertet. Weiter werden entsprechende Korrespondenzen erzeugt 2
und
f¨
ur diese die jeweiligen SCARs als Begr¨
undung hinterlegt. F¨
ur die gefundenen Korrespondenzen
werden die Aktionen SCAA ausgef¨
uhrt ( 3
).
Abbildung 8.10.: Erstellen einer neuen Instanz
Algorithmus 7 beschreibt diesen Einf¨
ugeprozess formal. Die Instanz indLeiner lokalen Produk-
tontologie wird dem Schemakonzept scLhinzugef¨
ugt. Sie kann unterhalb einer existierenden
181
8. Evolution integrierter Produktdaten
Instanz indparent
Lerstellt werden. Zun¨
achst werden die SCARs der Instanz ermittelt (Zeile 2).
F¨
ur jede SCAR werden die potenziell korrespondierenden Instanzen Indcandidates
Gder globalen
Produktontologie bestimmt (Zeile 4). F¨
ur das Kreuzprodukt aus indLund Indcandidates
Gwerden
die Attribut-Matching-Bedingungen der SCAR ausgewertet (Zeile 6). Wurden Korrespondenzen
identifiziert, werden diese, zusammen mit einer Begr¨
undung, hinzugef¨
ugt und der Algorithmus
7 aufgerufen.
Algorithmus 7 (Instanz hinzuf¨
ugen)
1: procedure AddIndividual(indL,ind
parent
L,sc
L)
2: SCARscL“tscar PSCAR |DpscL,sc
G,AMCqPSCARu
3: for each scarcur PSCARscLdo
4: Indcandidates
G“tind PIndG|Dpscarcur.scG,indqPhasIndividualGu
5: for each indcur
GPIndcandidates
Gdo
6: if evaluateAMCpindL,ind
cur
G, scarcur.AMCqthen
7: newCor “pindL,ind
cur
G, scarcurq
8: Correspondences “Correspondences ŤnewCor
9: Justification “Justification ŤpnewCor, scarcurq
10: AddCorrespondencepnewCorq
11: end if
12: end for
13: end for
14: end procedure
8.2.4. L¨oschen einer Instanz
Abbildung 8.11 zeigt den Prozess, der auf das L¨
oschen einer Korrespondenz zwischen Instanzen
aus lokalen und globalen Produktontologien reagiert. Ausl¨
oser dieser ¨
Anderung ist das manuelle
L¨
oschen durch einen Data Quality Engineer oder Dom¨
anenexperten. Wie erw¨
ahnt, muss beim
L¨
oschen von Artefakten zun¨
achst die Startebene ermittelt werden, von der aus das L¨
oschen kas-
kadierend dann von oben nach unten durchgef¨
uhrt wird. F¨
ur die korrespondierende Instanz der
globalen Produktontologie werden alle SCAAs der lokalen Produktontologie r¨
uckg¨
angig gemacht,
die Korrespondenz wird anschließend gel¨
oscht. Danach werden die zugeordneten Instanzen auf
der n¨
achst tieferen Produktdatenintegrationsebene ermittelt, f¨
ur diese werden die SCAAs eben-
falls r¨
uckg¨
angig gemacht. Dieser Vorgang wird solange wiederholt, bis die letzte Ebene erreicht
wird.
Die Korrespondenz wurde somit kaskadierend entfernt, die Integrationsmenge ist nun jedoch
nicht mehr vollst¨
andig. Damit die Fachanwender die Produktdaten nutzen k¨
onnen, m¨
ussen f¨
ur
die gel¨
oschten Korrespondenzen neue angelegt werden, oder aber die entsprechenden Instan-
zen m¨
ussen von der Integration ausgeschlossen werden. Die Korrespondenz wurde initial durch
den Data Quality Engineer gel¨
oscht, da die automatische Auswertung der SCARs und SCAAs
fehlerhaft war. Entweder kann dieser eine ”richtige“ korrespondierende Instanz in der globalen
Produktontologie ermitteln oder diese von der Integration ausschließen. Legt der Data Quality
Engineer eine neue Korrespondenz an, wird ein weiter ¨
Anderungsprozess aufgerufen.
182
8.2. Instanz¨
anderungen
Abbildung 8.11.: Eine Instanz wurde gel¨
oscht
Abbildung 8.12 veranschaulicht das L¨
oschen einer lokalen Instanz indL12 .Zun
¨
achst m¨
ussen die
SCAAs f¨
ur korrespondierende Instanzen (indG12 ) in der globalen Produktontologie r¨
uckg¨
angig
gemacht werden 1
. Anschließend werden die Korrespondenzen 2
gel¨
oscht. Danach werden die
Individuals, die zu indL12 geh¨
oren und auf der n¨
achst tieferen Produktdatenintegraionsebene
liegen, (indL21 ,ind
L22 ) ermittelt 3
. Schließlich wird die Instanz indL12 aus der lokalen Pro-
duktontologie entfernt 4
. Die Schritte 1
bis 4
werden f¨
ur die Instanzen indL21 und indL22
wiederholt, bis die letzte Produktdatenintegrationsebene erreicht wird.
Abbildung 8.12.: L¨
oschen einer Instanz
Formal wird dieser Prozess durch Algorithmus 8 beschrieben. F¨
ur die zu l¨
oschende Instanz indL
werden die bestehenden Korrespondenzen CorindLbestimmt (Zeile 2). F¨
ur alle Korrespondenzen
wird Algorithmus 8 aufgerufen, anschließend wird die Instanz entfernt (Zeilen 4 und 5).
183
8. Evolution integrierter Produktdaten
Algorithmus 8 (Instanz l¨
oschen)
1: procedure DeleteIndividual(indL)
2: CorindL“tcor PCorrespondence |DpindL,ind
GqPCorrespondenceu
3: for each corcur PCorindLdo
4: DeletedCorrespondencepcorcurq
5: IndL“IndLzcorcur.indL
6: end for
7: end procedure
8.2.5. L¨oschen eines Attributwertes
Wird ein Attributwert einer Instanz indLeiner lokalen Produktontologie gel¨
oscht, nachdem der
Attributwert bereits ¨
uber eine Korrespondenz in die globale Produktontologie integriert worden
ist, sind drei F¨
alle zu unterscheiden. Entweder wird das Attribut von einer Schemakonzept-
Attributaktion oder -Attributregel verwendet (F¨
alle 1 und 2). Schließlich kann es sich um ein
Attribut handeln, welches von keinem der beiden verwendet wird (Fall 3).
Abbildung 8.13 zeigt den ¨
Anderungsprozess eines Attributwertes einer lokalen Instanz. Sobald
der Attributwert durch einen Nutzer ge¨
andert wurde, muss ermittelt werden, ob es sich um ein
Attribut handelt, dass entweder von einer Schemakonzept-Attributaktion oder -Attributregel
verwendet wird. Im ersten Fall m¨
ussen ¨
uber bestehende Korrespondenzen diejenigen globalen
Instanzen ermittelt werden, f¨
ur die existierende Schemakonzept-Attributregeln r¨
uckg¨
angig ge-
macht werden. Im zweiten Fall werden die existierenden Korrespondenzen ebenfalls ermittelt.
Diese werden anschließend mittels Algorithmus 5 gel¨
oscht.
Abbildung 8.13.: Attributwert l¨
oschen
Abbildung 8.14 illustriert einen Ausschnitt einer lokalen Produktontologie, in der ein Attribut-
wert attrV alL12 einer Instanz indL11 ge¨
andert wurde ( 1
). Das ge¨
anderte Attribut wird durch
eine Schemakonzept-Attributaktion scaa1verwendet. Zun¨
achst m¨
ussen die korrespondierenden
Instanzen in einer globalen Produktontologie ermittelt werden ( 2
). Anschließend wird f¨
ur jede
gefundene Instanz die entsprechende Schemakonzapt-Attributaktion r¨
uckg¨
angig gemacht ( 3
).
184
8.2. Instanz¨
anderungen
Abbildung 8.14.: L¨
oschen des Attributwerts eines SCAA-Attributs
Analog dazu illustriert Abbildung 8.15 eine lokale Produktontologie, in welcher der ge¨
anderte
Attributwert durch eine Schemakonzept-Attributregel verwendet wird. Der Wert des Attributs
attrV alL12 wurde ge¨
andert 1
. Folglich m¨
ussen alle Korrespondenzen der Instanz indL11 ermit-
telt und mittels Algorithmus 6 gel¨
oscht werden 2
.
Abbildung 8.15.: L¨
oschen des Attributwerts eines SCAR-Attributs
Formal beschreibt Algorithmus 9 die ¨
Anderungsoperation. Zun¨
achst wird das Schemakonzept
des ge¨
anderten Attributs bestimmt (Zeile 2). Davon ausgehend werden die Schemakonzept-
Attributregeln und -Attributaktionen ermittelt (Zeilen 3 und 4). Es wird ¨
uber alle SCARs,in-
klusive deren Attribut-Matching-Bedingungen, iteriert. Ist das lokale Attribut der Attribut-
Matching-Bedingung gleich dem ge¨
anderten Attribut, wird Algorithmus 11 aufgerufen (Zeilen 5
bis 11). Analog wird ¨
uber die SCAAs iteriert und Algorithmus 10 ausgef¨
uhrt (Zeilen 12 bis 18).
185
8. Evolution integrierter Produktdaten
Algorithmus 9 (L¨
osche Attributwert)
1: procedure DeleteAttributeValue(indL, attrL)
2: scindL
L“tsc PSCL|Dpsc, indLqPhasIndividualLu
3: SCARindL“tscar PSCAR |DpscindL,sc
G,AMCqPSCARu
4: SCAAindL“tscaa PSCAA |DpscindL,sc
G,AAqPSCAAu
5: for each scarcur PSCARindLdo
6: for each amccur Pscarcur.AMC do
7: if amccur.attrL““ attrLthen
8: DeleteSCAARttributeV aluepindL, attrLq
9: end if
10: end for
11: end for
12: for each scaacur PSCAAindLdo
13: for each aacur Pscaacur.AA do
14: if aacur.attrL““ attrLthen
15: DeleteSCAAAttributeV aluepindL, attrLq
16: end if
17: end for
18: end for
19: end procedure
Algorithmus 10 formalisiert die in Abbildung 8.14 erl¨
auterten Schritte. Zun¨
achst werden die Kor-
respondenzen der Instanz indLbestimmt (Zeile 2). Mit Hilfe der Schemakonzept-Attributaktionen
wird das betroffene Attribut attrGdes Schemakonzepts in der globalen Produktontologie er-
mittelt (Zeilen 3 bis 11). Schließlich wird f¨
ur alle korrespondierenden Instanzen von indLder
korrespondierende Attributwert entfernt (Zeilen 12 bis 15).
Algorithmus 10 (L¨
osche SCAA-Attributwert)
1: procedure DeleteSCAAAttributeValue(indL, attrL)
2: CorindL“tcor PCorrespondence |DpindL,ind
GqPCorrespondenceu
3: scindL
L“tscLPSCL|DpscL,ind
LqPhasIndividualLu
4: SCAAindL“tscaa PSCAA |DscGPSCG^DpscindL
L,sc
GqPSCAAu
5: for each scaacur PSCAAindLdo
6: for each aacur Pscaacur.AA do
7: if aacur.attrL““ attrLthen
8: attrG“aacur.attrG
9: end if
10: end for
11: end for
12: for each indcur
GPCorindL.indGdo
13: attrV alcur “tattrV alGPAttrV alG|DpattrV alG, attrGqPreferencesG
^Dpindcur
G, attrV alGqPhasV alueGu
14: AttrV alG“AttrV alGzattrV alcur
G
15: end for
16: end procedure
Algorithmus 11 definiert die Schritte, die in Abbildung 8.15 erl¨
autert wurden. Zun¨
achst wer-
186
8.2. Instanz¨
anderungen
den die bestehenden Korrespondenzen der ge¨
anderten Instanz ermittelt (Zeile 2). Jede dieser
Instanzen wird mit Hilfe von Algorithmus 5 entfernt (Zeilen 3 bis 5).
Algorithmus 11 (L¨
osche SCAR-Attributwert)
1: procedure DeleteSCARAttributeValue(indL, attrL)
2: CorindL“tcor PCorrespondence |DpindL,ind
GqPCorrespondenceu
3: for each corcur PCorindLdo
4: DeletedCorrespondencepcorcurq
5: end for
6: end procedure
8.2.6. ¨
Andern eines Attributwerts
Das ¨
Andern eines Attributwerts ist ¨
ahnlich dem vorher beschriebenen L¨
oschen. Abbildung
8.16 zeigt die notwendigen Aktivit¨
aten f¨
ur das ¨
Andern eines Attributwerts. Analog muss zwi-
schen dem ¨
Andern eines SCAR- und SCAA-Attributs unterschieden werden. Wird ein von einer
Schemakonzept-Attributaktion verwendetes Attribut ge¨
andert, m¨
ussen zun¨
achst die korrespon-
dierenden Instanzen ermittelt werden. Anschließend sind f¨
ur diese die Attributwerte korrespon-
dierender globaler Instanzen anzupassen. Handelt es sich um ein Attribut, welches durch eine
Schemakonzept-Attributregel verwendet wurde, und existieren Korrespondenzen in eine globale
Produktontologie, m¨
ussen diese Korrespondenzen zun¨
achst gel¨
oscht werden. Anschließend wer-
den die Schemakonzept-Attributregeln neu ausgewertet und neue Korrespondenzen erstellt sowie
Schemakonzept-Attributaktionen ausgef¨
uhrt.
Abbildung 8.16.: ¨
Anderung eines Attributwerts
Abbildung 8.17 zeigt eine lokale Produktontologie, bei der f¨
ur Instanz indL11 der Attributwert
von attrL12 ge¨
andert wurde. Der Attributwert wird durch die Schemakonzept-Attributaktion
scaa1verwendet. Zun¨
achst werden alle korrespondierenden globalen Instanzen ermittelt 1
und
anschließend deren Attributwerte an den neuen lokalen Wert angepasst 2
.
187
8. Evolution integrierter Produktdaten
Abbildung 8.17.: ¨
Anderung des Werts eines SCAA-Attributs
Abbildung 8.18 zeigt die notwendigen Schritte nach der ¨
Anderung eines von einer SCAR ver-
wendeten Attributwerts. Zun¨
achst m¨
ussen alle korrespondierenden Instanzen der globalen Pro-
duktontologie ermittelt werden. Zu beachten ist, dass eine Korrespondenz zwischen Instanzen
lokaler Produktontologien und der globalen Produktontologie durch mehrere SCAR zustande
kommen k¨
onnen. Um die Integration nachvollziehbar zu machen, werden f¨
ur jede Korrespon-
denz die SCARs hinterlegt, die zu deren Erstellung gef¨
uhrt haben. Folglich kann eine Korrespon-
denz nur dann gel¨
oscht werden, wenn genau eine SCAR zur Erstellung gef¨
uhrt hat. Anderenfalls
wird lediglich die Referenz auf die SCAR entfernt. F¨
ur alle Instanzen der lokalen Produktontolo-
gie, deren Korrespondenzen zu Instanzen der globalen Produktontologie gel¨
oscht werden sollen,
werden entsprechende SCAAs des zugrundeliegenden Schemakonzeptes r¨
uckg¨
angig gemacht. An-
schließend werden die Korrespondenzen gel¨
oscht und f¨
ur die Instanzen die zugeh¨
origen Instanzen
auf der n¨
achst tieferen Produktdatenintegrationsebene ermittelt. F¨
ur all diese Instanzen werden
jeweils korrespondierende Instanzen der globalen Produktontologie ermittelt und die vorherigen
Schritte werden solange wiederholt, bis die letzte Produktdatenintegrationsebene erreicht wor-
den ist. Am Ende dieses Vorgangs sind die Korrespondenzen zwischen lokalen Produktontologien
und globaler Produktontologie kaskadierend gel¨
oscht worden. Nun m¨
ussen f¨
ur die Instanz, deren
Attributwert initial ge¨
andert wurde, die vorhandenen SCARs neu ausgewertet und entsprechen-
de Korrespondenzen erstellt werden. Wurden Korrespondenzen gefunden bzw. manuell erstellt,
m¨
ussen die SCAAs ausgef¨
uhrt werden.
188
8.2. Instanz¨
anderungen
Abbildung 8.18.: ¨
Anderung des Attributwerts eines SCAR-Attributs
Algorithmus 12 formalisiert das ¨
Andern eines Attributes. Mit Hilfe des lokalen Schemakon-
zeptes der ge¨
anderten Instanz werden die Schemakonzept-Attributregeln und -Attributaktionen
bestimmt (Zeilen 2 bis 4). Alle Schemakonzept-Attributregeln, inklusive Attribut-Matching-
Bedinungen, werden iteriert. Stimmt das lokale Attribut einer Attribut-Matching-Bedingung
mit dem betroffenen Attribut ¨
uberein, wird Algorithmus 13 ausgef¨
uhrt (Zeilen 5 bis 11). Ana-
log dazu werden in den Zeilen 12 bis 18 die Schemakonzept-Attributaktionen iteriert und bei
¨
Ubereinstimmung der Attribute der Algorithmus 14 aufgerufen.
Algorithmus 12 (¨
Andere Attributwert)
1: procedure ChangeAttributeValue(indL, attrL)
2: scindL
L“tsc PSCL|Dpsc, indLqPhasIndividualLu
3: SCARindL“tscar PSCAR |DpscindL,sc
G,AMCqPSCARu
4: SCAAindL“tscaa PSCAA |DpscindL,sc
G,AAqPSCAAu
5: for each scarcur PSCARindLdo
6: for each amccur Pscarcur.AMC do
7: if amccur.attrL““ attrLthen
8: ChangeSCAARttributeV aluepindL, attrLq
9: end if
10: end for
11: end for
12: for each scaacur PSCAAindLdo
189
8. Evolution integrierter Produktdaten
13: for each aacur Pscaacur.AA do
14: if aacur.attrL““ attrLthen
15: ChangeSCAAAttributeV aluepindL, attrLq
16: end if
17: end for
18: end for
19: end procedure
Algorithmus 13 formalisiert die in Abbildung 12 beschriebenen Schritte. Zun¨
achst m¨
ussen die
bestehenden Korrespondenzen r¨
uckg¨
angig gemacht werden (Zeilen 2 bis 5). Jede Attributregel
des Schemakonzeptes scLwird f¨
ur die ge¨
anderte Instanz indLerneut f¨
ur alle Kandidaten der
globalen Produktontologie ausgewertet (Zeilen 6 bis 10). Wird eine Korrespondenz ermittelt,
wird sie, zusammen mit einer Begr¨
undung, hinzugef¨
ugt und Algorithmus 4 wird ausgef¨
uhrt.
Algorithmus 13 (SCAR-Attributwert ge¨
andert)
1: procedure ChangeSCARAttributeValue(indL, attrL)
2: CorindL“tcor PCorrespondence |DpindL,ind
GqPCorrespondenceu
3: for each corcur PCorindLdo
4: DeletedCorrespondencepcorcurq
5: end for
6: SCARscL“tscar PSCAR |DpscL,sc
G,AMCqPSCARu
7: for each scarcur PSCARscLdo
8: Indcandidates
G“tind PIndG|Dpscarcur.scG,indqPhasIndividualGu
9: for each indcur
GPIndcandidates
Gdo
10: if evaluateAMCpindL,ind
cur
G, scarcur.AMCqthen
11: newCor “pindL,ind
cur
G, scarcurq
12: Correspondences “Correspondences ŤnewCor
13: Justification “Justification ŤpnewCor, scarcurq
14: AddCorrespondencepnewCorq
15: end if
16: end for
17: end for
18: end procedure
Algorithmus 14 formalisiert die Schritte aus Abbildung 8.17. Zuerst werden die Korrespondenzen
sowie das Schemakonzept der ge¨
anderten Instanz bestimmt (Zeilen 2 und 3). Mit Hilfe des
Schemakonzeptes werden die Schemakonzept-Attributaktionen ermittelt. Diese werden iteriert,
um das globale Attribut des korrespondierenden Schemakonzeptes zu identifizieren (Zeilen 4 bis
11). Schließlich wird f¨
ur alle korrespondierenden globalen Instanzen der betroffene Attributwert
aktualisiert (Zeilen 12 bis 1).
Algorithmus 14 (¨
Andere SCAA-Attributwert)
1: procedure ChangeSCAAAttributeValue(indL, attrL)
2: CorindL“tcor PCorrespondence |DpindL,ind
GqPCorrespondenceu
3: scindL
L“tscLPSCL|DpscL,ind
LqPhasIndividualLu
4: SCAAindL“tscaa PSCAA |DscGPSCG^DpscindL
L,sc
GqPSCAAu
190
8.3. Schema¨
anderungen
5: for each scaacur PSCAAindLdo
6: for each aacur Pscaacur.AA do
7: if aacur.attrL““ attrLthen
8: attrG“aacur.attrG
9: end if
10: end for
11: end for
12: for each corcur PCorindLdo
13: executeSCAApcorcur,SCAA
indLq
14: end for
15: end procedure
8.3. Schema¨anderungen
Neben ¨
Anderungen von Instanzen und deren Attributwerte k¨
onnen ¨
Anderungen an Schema-
konzepten und Attributen auftreten. Die Gr¨
unde f¨
ur solche ¨
Anderungen k¨
onnen vielschichtig
sein. Dazu z¨
ahlen etwa Anpassungen von Informationssystemen an neue Technologien, neue ge-
setzliche Vorgaben oder neue Unternehmensstrategien. Die folgenden Abschnitte beschreiben
¨
Anderungen unterschiedlicher Schemaartefakte.
W¨
ahrend Daten¨
anderungen durch Data Quality Engineers bzw. Anwender durchgef¨
uhrt werden,
m¨
ussen ¨
Anderungen auf Schemaebene durch das Integration Board entschieden werden. Die fol-
genden Abschnitte befassen sich, analog zu den Daten¨
anderungen, mit ¨
Anderungsoperationen f¨
ur
Artefakte der Schemaebene. F¨
ur jede Operation wird wieder der Ablauf als BPMN-Prozessmodell
illustriert. Anschließend wird dieser mittels eines Beispiels dargestellt, bevor er formalisiert wird.
8.3.1. SCAA hinzuf¨ugen
Abbildung 8.19 zeigt den Prozess f¨
ur das Anlegen einer neuen Schemakonzept-Attributaktion.
Zun¨
achst wird diese durch einen Integrationsexperten modelliert. Ist dieser Vorgang abgeschlos-
sen, werden die Instanzen des betroffenen Schemakonzeptes sowie deren Korrespondenzen be-
stimmt. F¨
ur alle Korrespondenzen der Instanzen wird die neue Schemakonzept-Attributaktion
ausgef¨
uhrt.
Abbildung 8.19.: Hinzuf¨
ugen neuer SCAAs
191
8. Evolution integrierter Produktdaten
Abbildung 8.20 zeigt beispielhaft eine lokale und die globale Produktontologie, f¨
ur die eine
neue Schemakonzept-Attributaktion scaa1erstellt wurde 1
.Zun
¨
achst werden das betroffene
Schemakonzept scL1sowie dessen Instanzen (indL11 bis indL15) bestimmt 2
. Anschließend
werden f¨
ur jede Instanz die korrespondierenden globalen Instanzen ermittelt. F¨
ur jede dieser
Instanzen wird die neue SCAA ausgef¨
uhrt 3
.
Abbildung 8.20.: Neue SCAA
Algorithmus 15 formalisiert die Schritte aus Abbildung 8.20. F¨
ur die neue Schemakonzept-
Attributaktion wird die Menge der betroffenen Instanzen bestimmt (Zeile 2). F¨
ur jede dieser In-
stanzen wiederum wird die Menge der Korrespondenzen auf globale Instanzen ermittelt (Zeilen 3
und 4). Schließlich wird f¨
ur jede dieser Korrespondenzen die neue Schemakonzept-Attributaktion
ausgef¨
uhrt (Zeile 6).
Algorithmus 15 (SCAA hinzuf¨
ugen)
1: procedure AddSCAA(scaa)
2: IndscL
L“tindLPIndL|Dpscaa.scL,ind
LqPhasIndividualLu
3: for each indcur
LPIndscL
Ldo
4: Corindcur “tDpindcur
L,ind
GqPCorrespondencesu
5: for each corcur PCorindcur do
6: executeSCAApcorcur, scaaq
7: end for
8: end for
9: end procedure
8.3.2. L¨oschen einer SCAA
Wird ein Attribut aus der globalen Produktontologie nicht mehr f¨
ur Anwendungsf¨
alle ben¨
otigt,
kann die entsprechende Schemakonzept-Attributregel durch Integrationsexperten gel¨
oscht wer-
den. Abbildung 8.21 zeigt den Ablauf der einzelnen Schritte dieser ¨
Anderungsoperation. Nach
Entfernen der Schemakonzept-Attributaktion durch einen Integrationsexperten, werden die hier-
von betroffenen Instanzen bestimmt. F¨
ur jede von ihnen werden die globalen Instanzen ¨
uber die
192
8.3. Schema¨
anderungen
existierenden Korrespondenzen ermittelt. Schließlich wird f¨
ur jede dieser korrespondierenden
globalen Instanzen der Wert des Attributs der SCAA gel¨
oscht.
Abbildung 8.21.: SCAA l¨
oschen
Abbildung 8.22 zeigt ein Beispiel, in dem eine Attributaktion eines Schemakonzepts scL1entfernt
wird 1
.Zun
¨
achst werden alle betroffenen Instanzen ¨
uber die Korrespondenzen bestimmt 2
.
Anschließend werden die Aktionen in den globalen Instanzen r¨
uckg¨
angig gemacht 3
und die
entsprechende SCAA gel¨
oscht.
Abbildung 8.22.: L¨
oschen einer SCAA
Algorithmus 16 formalisiert die Schritte aus Abbildung 8.22. Zun¨
achst wird die Menge der be-
troffenen Instanzen IndscL
Lermittelt (Zeile 2). F¨
ur jede Instanz wird dann ¨
uber die existierenden
Korrespondenzen die Menge der betroffenen globalen Instanzen ermittelt. Schließlich werden f¨
ur
jede der so ermittelten globalen Instanzen mit Hilfe von Algorithmus 5 die Attributwerte der
Schemakonzept-Attributaktion entfernt (Zeilen 3 bis 8).
193
8. Evolution integrierter Produktdaten
Algorithmus 16 (SCAA l¨
oschen)
1: procedure DeleteSCAA(scaa)
2: IndscL
L“tindLPIndL|Dpscaa.scL,ind
LqPhasIndividualLu
3: for each indcur
LPIndscL
Ldo
4: Corindcur “tcor PCorrespondences |Dpindcur
L,ind
GqPCorrespondencesu
5: for each corcur PCorindcur do
6: DeleteGlobalAttributV aluepcorcur, scaaq
7: end for
8: end for
9: end procedure
8.3.3. ¨
Anderung einer SCAA
Neben dem L¨
oschen bzw. Hinzuf¨
ugen einer Schemakonzept-Attributaktion kann eine solche
auch ge¨
andert werden, indem mindestens eine Attribut-Aktion angepasst wird. Die Schritte
der ¨
Anderungsoperation setzen sich aus dem L¨
oschen und Hinzuf¨
ugen einer SCAA zusammen
(siehe Abbildung 8.23).
Abbildung 8.23.: ¨
Andern eines SCAA-Attributs
Algorithmus 20 beschreibt den Prozess aus Abbildung 8.23 formal und setzt sich aus den beiden
Algorithmen 15 und 16 zusammen (Zeilen 2 und 3).
Algorithmus 17 (SCAA ¨
andern)
1: procedure ChangeSCAA(scaa)
2: DeleteSCAApscaaq
3: AddSCAApscaaq
4: end procedure
8.3.4. Hinzuf¨ugen einer SCAR
Wird f¨
ur ein Schemakonzept ein in einem neuen SCAR zu verwendendes Attribut erstellt, stellen
sich die ben¨
otigten ¨
Anderungsaktivit¨
aten deutlich komplexer dar als im vorherigen Fall. Die
erforderlichen Aktivit¨
aten sind in Abbildung 8.24 dargestellt. Die neue SCAR muss zun¨
achst
194
8.3. Schema¨
anderungen
durch einen Integrationsexperten modelliert werden. F¨
ur alle Instanzen des ge¨
anderten Schema-
konzeptes der lokalen Produktontologie wird die neu erstellte SCAR ausgewertet, bei Treffern
werden dann jeweils entsprechende Korrespondenzen erstellt. F¨
ur alle gefundenen Korresponden-
zen werden alle SCAAs des ge¨
anderten Schemakonzeptes ausgef¨
uhrt. Treten bei der Ausf¨
uhrung
von SCAAs um Integrationskonflikte auf, m¨
ussen diese durch einen Data Quality Engineer auf-
gel¨
ost werden. Anschließend werden f¨
ur alle Instanzen der lokalen Produktontologie, f¨
ur die
neue Korrespondenzen gefunden wurden, die zugeh¨
origen Instanzen der n¨
achst tieferen Pro-
duktdatenintegrationsebene ermittelt. Die SCARs des entsprechenden Schemakonzeptes werden
f¨
ur diese Instanzen ausgewertet, und bei Treffern werden Korrespondenzen erstellt und SCAAs
ausgef¨
uhrt. Dieser Prozess wird solange wiederholt, bis die letzte Produktdatenintegrationsebene
erreicht worden ist.
Abbildung 8.24.: Hinzuf¨
ugen einer neuen SCAR
Abbildung 8.25 zeigt ein Beispiel f¨
ur eine lokale und globale Produktontologie, f¨
ur die eine neue
Schemakonzept-Attributregel scar2zwischen den Schemakonzepten scL1und scG1modelliert
wurde 1
. Es werden die lokalen Instanzen des Schemakonzeptes scL12
und die globalen In-
stanzen von scG13
bestimmt. F¨
ur das Kreuzprodukt aus beiden Instanzmengen wird die neue
Schemakonzept-Attributregel ausgewertet 4
.F
¨
ur jede ¨
Ubereinstimmung werden eine neue Kor-
respondenz angelegt 5
und die bestehenden Schemakonzept-Attributaktionen ausgef¨
uhrt 6
.
F¨
ur die neuen Korrespondenzen wird dieser Vorgang f¨
ur die weiteren Integrationsebenen wie-
derholt 7
, bis schließlich die letzte Ebene erreicht worden ist.
195
8. Evolution integrierter Produktdaten
Abbildung 8.25.: Einf¨
ugen einer neuen SCAR
Algorithmus 18 formalisiert die Schritte aus Abbildung 8.25. Zuerst werden diejenigen In-
stanzen aus einer lokalen und der globalen Produktontologie bestimmt, f¨
ur welche die neue
Schemakonzept-Attributregel ausgewertet werden soll (Zeilen 2 und 3). F¨
ur das Kreuzprodukt
aus beiden Mengen werden die Attribut-Matching-Bedingungen der neuen SCAR ausgewertet
und bei ¨
Ubereinstimmung eine neue Korrespondenz erstellt (Zeilen 4 bis 7). Zus¨
atzlich wird eine
Begr¨
undung erzeugt (Zeile 8). Abschließend wird der Algorithmus 4 f¨
ur die neue Korrespondenz
ausgef¨
uhrt (Zeile 9).
Algorithmus 18 (SCAR hinzuf¨
ugen)
1: procedure AddSCAR(scar)
2: Indcandidates
L“tindLPIndL|Dpscar.scL,ind
LqPhasIndividualLu
3: Indcandidates
G“tindGPIndG|Dpscar.scG,ind
GqPhasIndividualGu
4: for each indcur
LPIndcandidates
Ldo
5: for each indcur
GPIndcandidates
Gdo
6: if evaluateAMCpindL,ind
cur
G, scarcur.AMCqthen
7: newCor “pindL,ind
cur
G, scarcurq
8: Correspondences “Correspondences ŤnewCor
9: Justification “Justification ŤpnewCor, scarcurq
10: AddCorrespondencepnewCorq
11: end if
12: end for
13: end for
14: end procedure
8.3.5. L¨oschen einer SCAR
Attribute von Schemakonzepten k¨
onnen auch in SCARs referenziert werden. Abbildung 8.26 zeigt
die Aktivit¨
aten, die notwendig sind, um die Integrationsmenge wieder vollst¨
andig und konsistent
zu machen.
196
8.3. Schema¨
anderungen
Zuerst m¨
ussen f¨
ur alle Instanzen des ge¨
anderten Schemakonzeptes der lokalen Produktontologie
die korrespondierenden Instanzen der globalen Produktontologie ermittelt werden. F¨
ur letztere
werden alle SCAAs des ge¨
anderten Schemakonzeptes r¨
uckg¨
angig gemacht. Danach werden die
Korrespondenzen zwischen den Instanzen aus lokalen Produktontologien und globaler Produk-
tontologie gel¨
oscht. F¨
ur alle Instanzen des ge¨
anderten Schemakonzeptes werden die zugeh¨
origen
Instanzen der n¨
achst tieferen Produktdatenintegrationsebene ermittelt. F¨
ur all diese Instanzen
wiederum werden erneut die korrespondierenden Instanzen der globalen Produktontologie be-
stimmt und die SCAAs r¨
uckg¨
angig gemacht. Dieser Vorgang wird solange wiederholt, bis die letzte
Produktdatenintegrationsebene erreicht worden ist. Nach diesen Schritten existieren Instanzen
in der lokalen Produktontologie, die nicht auf Instanzen in der globalen Produktontologie ab-
gebildet sind. Nun m¨
ussen entweder Korrespondenzen manuell durch Data Quality Engineers
erstellt werden, oder diese Instanzen m¨
ussen von der Integration ausgeschlossen werden, damit
die Integrationsmenge vollst¨
andig und konsistent ist.
Abbildung 8.26.: L¨
oschen einer SCAR
Abbildung 8.27 zeigt exemplarisch ein Szenario mit einer lokalen und globalen Produktonto-
logie, bei dem eine Schemakonzept-Attributregel scar1gel¨
oscht wurde 1
.Zuerstm
¨
ussen die
potenziell betroffenen Instanzen des lokalen Schemakonzeptes bestimmt werden 2
.F
¨
ur jede
dieser Instanzen werden vorhandene Korrespondenzen dahingehend untersucht, ob sie durch die
gel¨
oschte Schemakonzept-Attributregel erzeugt worden sind 3
.F
¨
ur diese Korrespondenzen wer-
den bestehende Schemakonzept-Attributaktionen r¨
uckg¨
angig gemacht 4
. Anschließend werden
die betroffenen Korrespondenzen gel¨
oscht 5
und der Vorgang f¨
ur die darunterliegenden Ebenen
so lange wiederholt, bis die letzte Ebene erreicht wird 6
.
197
8. Evolution integrierter Produktdaten
Abbildung 8.27.: L¨
oschen einer SCAR
Algorithmus 19 formalisiert die Schritte aus Abbildung 8.27. Zun¨
achst wird die Menge der
potenziell betroffenen lokalen Instanzen (Indcandidates
L) bestimmt (Zeile 2). F¨
ur jede Instanz wird
die Menge der existierenden Korrespondenzen iteriert (Zeilen 3 bis 5). Falls eine Korrespondenz
durch die gel¨
oschte Schemakonzept-Attributregel erzeugt wurde (Zeile 6), werden Algorithmus
6 ausgef¨
uhrt und die Korrespondenz anschließend entfernt (Zeilen 7 und 8).
Algorithmus 19 (SCAR l¨
oschen)
1: procedure DeleteSCAR(scar)
2: Indcandidates
L“tindLPIndL|Dpscar.scL,ind
LqPhasIndividualLu
3: for each indcur
LPIndcandidates
Ldo
4: Corindcur “tcor PCorrespondences |Dpindcur
L,ind
GqPCorrespondencesu
5: for each corcur PCorindcur do
6: if Dpcorcur, scarqPJustification then
7: DeleteCorrespondencepcorcurq
8: Correspondences “Correspondenceszcorcur
9: end if
10: end for
11: end for
12: end procedure
8.3.6. ¨
Anderung einer SCAR
Abbildung 8.28 zeigt die ben¨
otigen Aktivit¨
aten, wenn ein innerhalb einer SCAR verwende-
tes Attribut eines Schemakonzeptes ge¨
andert wird. Analog zum ¨
Andern einer Schemakonzept-
Attributaktion setzt sich das ¨
Andern einer Schemakonzept-Attributregel aus dem L¨
oschen und
Einf¨
ugen von Korrespondenzen zusammen. Zun¨
achst muss f¨
ur alle Instanzen der lokalen Pro-
duktontologie des ge¨
anderten Schemakonzeptes die Menge der korrespondierenden Instanzen
der globalen Produktontologie ermittelt werden. F¨
ur jedes Element dieser Menge werden all
diejenigen SCAAs der lokalen Produktontologie r¨
uckg¨
angig gemacht, die das gel¨
oschte Attribut
198
8.3. Schema¨
anderungen
referenzieren. Anschließend werden die existierenden Korrespondenzen gel¨
oscht. Danach werden
die ge¨
anderte Schemakonzept-Attributregel f¨
ur die lokalen und globalen Instanzen neu ausge-
wertet und bei Treffern entsprechende Korrespondenzen erzeugt.
Abbildung 8.28.: ¨
Anderung einer SCAR
Abbildung 8.29 illustriert eine lokale und globale Produktontologie, in der die Schemakonzept-
Attributregel scar1ge¨
andert wurde 1
. Die Schritte 2
bis 6
laufen identisch zum Abschnitt
8.3.5 ab. Nach L¨
oschen derjenigen Korrespondenzen, die durch die alte Schemakonzept-Attribut-
regel erstellt wurden, wird die neue Schemakonzept-Attributregel f¨
ur die lokalen und globalen
Instanzen ausgewertet 7
. Bei ¨
Ubereinstimmungen werden Korrespondenzen erstellt 8
und der
Vorgang f¨
ur die n¨
achst tiefere Integrationsebene fortgesetzt 9
.
Abbildung 8.29.: Bearbeitung einer SCAR
Algorithmus 20 formalisiert die zuvor beschriebenen Schritte aus Abbildung 8.29. Zun¨
achst wird
Algorithmus 19, gefolgt von Algorithmus 18, aufgerufen.
199
8. Evolution integrierter Produktdaten
Algorithmus 20 (SCAR ¨
andern)
1: procedure ChangeSCAR(scar)
2: DeleteSCARpscarq
3: AddSCARpscarq
4: end procedure
200
Teil III
Evaluation
9. Proof-of-Concept Implementierung
In diesem Kapitel wird die Architektur des PROCEED-Systems erl¨
autert, das die Konzepte aus
den Kapiteln 6 bis 8 realisiert. Des Weiteren wird die technische Realisierung der Architektur
vorgestellt, mit dem Ziel, deren technische Machbarkeit zu demonstrieren. Schließlich werden
verwandte Arbeiten diskutiert.
9.1. PROCEED Systemarchitektur
Abbildung 9.1 illustriert die zu Grunde liegende Architektur des PROCEED-Systems mittels
UML-Komponentendiagramm. Die einzelnen Komponenten der Architektur, die nachfolgend
vorgestellt werden, ergeben sich aus den in den Kapiteln 6 bis 8 vorgestellten Konzepten.
/HJHQGH
80/&RPSRQHQW
Abbildung 9.1.: Architektur des PROCEED-Systems
Der Ontology Manager verwaltet die lokalen und globalen Produktontologien und stellt die
strukturelle Konsistenz einzelner Produktontologien sicher (vgl. Abschnitt 6.2.1).
Startpunkt des PROCEED-Systems ist ein Integrationsprojekt, welches Anwendungsf¨
alle realisiert.
Ein Integrationsprojekt besteht aus genau einer globalen und mindestens einer lokalen Produk-
tontologie. Der Integration Manager realisiert den Integrationsalgorithmus aus Abschnitt 6.3
und interagiert mit dem Change Manager, welcher die ¨
Anderungsoperationen aus Kapitel 8 um-
setzt. Das Monitoring wiederum berechnet und ¨
uberwacht definierte Qualit¨
atsmetriken (siehe
Kapitel 7). Der Query Manager verwaltet Abfragen, die an die integrierten Produktdaten ge-
stellt werden. Der User Manager verwaltet die verschiedenen Rollen und Nutzer (siehe Abschnitt
6.2.5). Er ¨
ubergibt Informationen zum aktuell registrierten Benutzer des PROCEED-Systems und
hinterlegt Metadaten f¨
ur Artefakte von Produktontologien, falls ¨
Anderungen durchgef¨
uhrt wer-
203
9. Proof-of-Concept Implementierung
den. Der Task Manager weist Integrationsaufgaben, die w¨
ahrend der Integration anfallen, an
verschiedene Rollen und Nutzer zu (siehe Abschnitt 6.4).
Das PROCEED-System gliedert sich in eine existierende IT-Systemlandschaft eines Unterneh-
mens ein. Folglich m¨
ussen bestehende Systeme und die ihnen zugrundliegende Prozesse (z.B.
¨
Anderungsmanagement) bei einer Integration ber¨
ucksichtigt werden. F¨
ur die Population lokaler
Produktontologien mit Instanzen sind unterschiedliche L¨
osungen m¨
oglich. Diese L¨
osungsalterna-
tiven werden im folgenden Abschnitt diskutiert.
Im Bezug auf ¨
Anderungen in lokalen Informationssystemen muss entschieden werden, in wel-
chen Abst¨
anden diese an das PROCEED-System gemeldet werden. Dabei sind mehrere Szenarien
m¨
oglich:
1. Nach Freigabe einer ¨
Anderung in einem Informationssystem wird diese sofort an das
PROCEED-System ¨
ubermittelt. Im weiteren Verlauf bezeichnen wir dies als Ad-hoc-Integra-
tion.
2. Eine weitere M¨
oglichkeit ist es, ¨
Anderungen an das PROCEED-System zu ¨
ubermitteln, wenn
eine zuvor definierte Schwelle bzgl. der Anzahl an ¨
Anderungen ¨
uberschritten worden ist.
Diese M¨
oglichkeit wird als Schwellen-Integration bezeichnet. Damit ein lokales Informa-
tionssystem diese Variante unterst¨
utzen kann, muss es in der Lage sein, die Anzahl an
¨
Anderungen zu ¨
uberwachen.
3. Unter Zeitbasierter Integration schließlich bezeichnen wir die M¨
oglichkeit, dass lokale In-
formationssysteme ¨
Anderungen in einem festdefinierten Zeitintervall aufzeichnen und diese
am Ende des Intervalls dem PROCEED-System bereitstellen.
Neben dem zeitlichen Aspekt von ¨
Anderungen m¨
ussen die Rollen lokaler Informationssysteme
und des PROCEED-Systems definiert werden. Ein Informationssystem kann sowohl sich pas-
siv als auch aktiv in einem Systemverbund, das mehrere Systeme integriert, verhalten. Ein
Informationssystem interagiert aktiv mit einem anderen, wenn es Informationen an dieses an-
dere Informationssystem ¨
ubermittelt. F¨
ur die Integration lokaler Informationssysteme in das
PROCEED-System k¨
onnen Szenarien definiert werden, in denen lokale Informationssysteme ak-
tiv oder passiv sind.
•Im ersten Szenario sind lokale Informationssysteme aktiv, d.h. sie melden ¨
Anderungen
aktiv an das PROCEED-System (Push-Prinzip). Dies kann etwa ¨
uber API-Aufrufe oder
nachrichtenbasiert erfolgen. Im zweiten Szenario ist das PROCEED-System aktiv und ruft
die lokalen Informationssysteme auf (Pull-Prinzip). Technisch kann dies auf Grundlage
von API-Aufrufen der lokalen Informationssysteme oder nachrichtenbasiert erfolgen.
•Eine weitere M¨
oglichkeit besteht darin, dass lokale Informationssysteme ihre ¨
Anderungen
in einer strukturierten Form exportieren und als Datei zur Verf¨
ugung stellen. Das PRO-
CEED-System greift dann auf diese Dateien zu und reagiert bei Erkennung von ¨
Anderungen.
Die beiden Szenarien und ihre verschiedenen technischen Realisierungen bieten Vor- und Nachtei-
le. Im ersten Szenario muss das PROCEED-System eine klar definierte API f¨
ur ¨
Anderungsopera-
tionen zur Verf¨
ugung stellen. Weiter muss jedes lokale Informationssystem, welches in das
PROCEED-System integriert werden soll, um ¨
Anderungsoperationen erweitert werden, so dass
204
9.2. Grundlagen
bei ¨
Anderungen die API des PROCEED-Systems aufgerufen wird. Im zweiten Szenario muss je-
des lokale Informationssystem, das in das PROCEED-System integriert werden soll, ein API rea-
lisieren. Nur dann kann das PROCEED-System m¨
ogliche ¨
Anderungen abfragen. Dar¨
uber hinaus
muss jedes Informationssystem erweitert werden, um ¨
Anderungen an Produktdaten aufzuzeich-
nen, so dass diese ¨
uber die API bereitgestellt werden k¨
onnen. Eine weitere M¨
oglichkeit besteht
darin, dass die lokalen Informationssysteme keine ¨
Anderungen ¨
ubermitteln, sondern nur den ak-
tuell g¨
ultigen Stand von Produktdaten bereitstellen. In diesem Fall muss das PROCEED-System
einen Differenzvergleich zwischen den aktuellen Daten der lokalen Produktontologien und den
gemeldeten St¨
anden der lokalen Informationssysteme durchf¨
uhren, um m¨
ogliche ¨
Anderungen zu
ermitteln.
9.2. Grundlagen
Technisch ist die Architektur des PROCEED-Systems durch Teile des Semantic Web Stacks
[Bra07] realisiert. Dieser ist in Abbildung 9.2 illustriert. Die f¨
ur die Realisierung des PROCEED-
Systems verwendeten Standards (vgl. graue K¨
asten) werden im Folgenden kurz erl¨
autert.
Abbildung 9.2.: Semantic Web Stack (In Anlehnung an [Bra07])
Das Resource Description Framework (RDF) [LSo98] ist eine Spezifikation des World Wide Web
Konsortiums f¨
ur die konzeptuelle Beschreibung von Informationen. Letztere bestehen aus ein-
deutig identifizierbaren Ressourcen und deren Beziehungen untereinander. Aussagen ¨
uber Res-
sourcen werden als Tripel (Subjekt-Pr¨
adikat-Objekt) mit vordefinierter Semantik modelliert. Da
RDF aus weit verbreiteten Web-Protokollen, wie z.B. URI, HTTP und XML basiert, erm¨
oglicht
es Interoperabilit¨
at. Abbildung 9.3 zeigt ein Beispiel eines RDF-Graphen, der zwei Aussagen
enth¨
alt.
205
9. Proof-of-Concept Implementierung
Abbildung 9.3.: Beispiel eines RDF-Graphs
Zus¨
atzlich zu ihrer grafischen Repr¨
asentation, lassen sich RDF-Graphen unterschiedlich seria-
lisieren. M¨
ogliche Syntaxformate sind zum Beispiel XML und Turtle [BBLP08]. Im Folgenden
werden alle Ontologien mit Hilfe der Turtle-Syntax dargestellt. In Listing 9.1 wird das Beispiel
aus Abbildung 9.3 in Turtle-Syntax serialisiert.
1@prefix gpo:<http://www.uni´ulm.de/proceed/gpo.owl#>.
2@prefix dc:<http://purl.org/dc/elements/1.1/>.
3 gpo:ECM dc:title ”Engine Control Module ” .
4 gpo:ECM belongsToNetwork gpo:PowerTrain .
Listing 9.1: Beispiel eines RDF-Graphen in Turtle-Syntax
W¨
ahrend RDF die Interoperabilit¨
at von Ontologien erm¨
oglicht, lassen sich damit Aussagen ¨
uber
Klassen und Klassenbeziehungen (Relationen) nicht modellieren. Aus diesem Grund wurde die
RDF Vocabulary Description Language (RDFS) [BG00] entworfen. Sie definiert grundlegende
Elemente f¨
ur die Beschreibung von Ontologien. In Einzelnen lassen sich mit Hilfe von RDFS
Klassen, Hierarchien und Relationen zwischen Klassen definieren.
Listing 9.2 zeigt ein Beispiel f¨
ur eine RDFS Ontologie. Es wird die Klasse ElectronicContolUnit
definiert, f¨
ur die zwei Instanzen existieren (EngineControlModule und BodyControlModule).
Weiter wird die Eigenschaft communicatesWith definiert, die zwischen ElectronicControlUnit
spezifiziert werden kann.
1@prefix rdf: <http://www.w3.org/1999/02/22´rdf´syntax´ns#>.
2@prefix rdfs: <http://www.w3.org/2000/01/rdf´schema#>
3@base <http://www.example.org#>.
4
5 :ElectronicControlUnit rdf:type rdfs:class .
6 :EngineControlModule rdf:type :ElectronicControlUnit .
7 :BodyControlModule rdf:type :ElectronicControlUnit .
8 :communicatesWith rdfs:domain :ElectronicControlUnit .
9 :communicatesWith rdfs:range :ElectronicControlUnit .
10 :EngineControlModule :communicatesWith :BodyControlUnit .
Listing 9.2: Beispiel einer RDFS-Ontologie
Mit RDFS ist es nicht m¨
oglich, Disjunktheit auszudr¨
ucken. Zudem existieren weitere Ein-
schr¨
ankungen [Tat09], die dazu gef¨
uhrt haben, dass zus¨
atzliche Ontologie-Beschreibungssprachen
mit h¨
oherer Ausdrucksm¨
achtigkeit entstanden sind. Basierend auf RDF und RDFS erm¨
oglichen
es die Web Ontology Language (OWL)[MVH
`04] und deren Nachfolger OWL2 [MPSP`09],
Ontologien unterschiedlicher Ausdrucksm¨
achtigkeit zu modellieren. Die OWL-Spezifikation de-
finiert dazu drei sog. OWL-Profile: OWL Lite, OWL DL und OWL Full. Zu den wichtigsten
Entit¨
aten einer OWL-Ontologie z¨
ahlen owl:Class,owl:ObjectProperty,owl:DatatypeProperty und
206
9.2. Grundlagen
owl:NamedIndividual. In Listing 9.3 ist eine OWL-Ontologie in Turtle-Syntax dargestellt; die
Ontologie umfasst die beiden Klassen ECU und ECUVariant somit die Beziehung hasVariant
zwischen ihnen. F¨
ur beide Klassen ist die Eigenschaft hasName als xsd:string definiert. F¨
ur
beide Klassen ist jeweils ein Individual vorhanden (Engine und Diesel Engine). Abbildung 9.4
illustiert die OWL-Ontologie aus Listing 9.3 als RDF-Graphen.
1@prefix owl: <http://www.w3.org/2002/07/owl#>.
2@prefix rdf: <http://www.w3.org/1999/02/22´rdf´syntax´ns#>.
3@prefix xml: <http://www.w3.org/XML/1998/namespace>.
4@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
5@prefix rdfs: <http://www.w3.org/2000/01/rdf´schema#>.
6@prefix :<http://www.example.org/ontologyexample.owl#>.
7@base <http://www.example.org/ontologyexample.owl>
8
9<http://www.example.org/ontologyexample.owl>rdf:type owl:Ontology ;
10 rdfs:label ”Example” .
11 :ECU rdf:type owl:Class .
12 :ECUVariant rdf:type owl:Class .
13 :hasVariant rdf:type owl:ObjectProperty ;
14 rdfs:domain :ECU ;
15 rdfs:range :ECUVariant .
16 :hasName rdf:type owl:DatatypeProperty ;
17 rdfs:domain :ECU, ECUVariant ;
18 rdfs:range xsd:string .
19
20 :ind2 a :ECUVariant ;
21 :hasName ”Diesel Engine” .
22
23 :ind1 a :ECU ;
24 :hasName ”Engine” ;
25 :hasVariant :ind2 .
Listing 9.3: Beispiel einer OWL-Ontologie in Turtle-Syntax
Mit sog. Reasonern l¨
asst sich aus bestehendem Wissen einer Ontologie neues Wissen automatisch
ableiten [Bec09]. So ist es mit ihrer Hilfe m¨
oglich, den Modellierungsaufwand von Produktontolo-
gien zu reduzieren. Bspw. muss die Beziehung zwischen zusammengeh¨
orenden Instanzen, die sich
auf unterschiedlichen Produkdatenintegrationsebenen befinden, nur in eine Richtung modelliert
werden, w¨
ahrend die Gegenrichtung durch den Einsatz eines Reasoners automatisch ermittelt
wird. So muss zwischen zwei Instanzen indL1und indL2nur die Beziehung pindL1,ind
L2qP
isBelow (s. Definition 21) modelliert werden, die Beziehung pindL2,ind
L1qPisAbove wird
durch eine entsprechende Modellierung in der lokalen Produktontologie automatisch abgelei-
tet. Auch die Sicherstellung der strukturellen Konsistenz (siehe Abschnitt 6.2.1) kann durch die
Verwendung von Reasonern unterst¨
utzt werden (s. Abschnitt 9.3.4).
Ein weiter Teil des Semantic Web Stacks ist SPARQL [HSP13] eine Sprache, mit der sich Ab-
fragen an RDF-Graphen formulieren lassen. Da Schemata in RDF intrinsisch sind, d.h. selber
Bestandteil des RDF-Graphen sind, lassen sich neben der Abfrage von Instanzen auch Schema-
Informationen einfach mit Hilfe von SPARQL bestimmen. Listing 9.4 zeigt ein Beispiel f¨
ur eine
SPARQL-Abfrage f¨
ur den RDF-Graphen aus Listing 9.2. Zun¨
achst werden die ben¨
otigten Pr¨
afixe
definiert, bevor die Abfrageoperation formuliert wird. Die SELECT-Operation liefert, analog zu
einer SQL-Abfrage, als Ergebnis eine Tabelle zur¨
uck (siehe Tabelle 9.1). Neben SELECT existie-
ren noch weitere Operationen wie CONSTRUCT,ASK und DESCRIBE, die im folgenden aber nicht
weiter erl¨
autert werden.
207
9. Proof-of-Concept Implementierung
Abbildung 9.4.: RDF-Graph der OWL-Ontologie aus Listing 9.3
1 PREFIX rdf: <http://www.w3.org/1999/02/22´rdf´syntax´ns#>
2PREFIXowl:<http://www.w3.org/2002/07/owl#>
3 PREFIX rdfs: <http://www.w3.org/2000/01/rdf´schema#>
4 PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
5 SELECT DISTINCT ?Class ?Ind
6WHERE
7{
8 ?Class rdf:type owl:Class .
9 ?Ind rdf:type owl:NamedIndividual
10 ?Ind rdf:type ?Class .
11 }
Listing 9.4: Beispiel einer SPARQL-Abfrage
208
9.3. Realisierung der L¨
osungskonzepte
Class Ind
ECU Ind1
ECUVariant Ind2
Tabelle 9.1.: Ergebnis der SPARQL-Abfrage aus Listing 9.4
Ein weiterer Baustein des Semantic Web Stacks sind Regeln. Neben der Definition von Onto-
logien mit Hilfe der verf¨
ugbaren Beschreibungselemente (z.B. Klassen, Hierarchien und Rela-
tionen zwischen Klassen) existiert die M¨
oglichkeit, komplexere Regeln f¨
ur Ontologien mit Hilfe
der Semantic Web Rule Language (SWRL) zu definieren. In Listing 9.5 ist ein Beispiel f¨
ur
eine SWRL-Regel dargestellt. Eine SWRL-Regel besteht immer aus einem Antecedent und ei-
nem Consequent, anders ausgedr¨
uckt aus einer Bedingung und einer Folgerung. Im Beispiel be-
steht die Bedingung aus der Konjunktion zweier OWL-Objecttypes hasParent(?x1, ?x2) ^
hasBrother(?x2,?x3) sowie der Folgerung hasUncle(?x1,?x3). Konkret heißt dies, wenn es in
einer Ontologie drei Individuals a, b und cgibt, f¨
ur die hasParent(a, b) ^hasBrother(b,c)
gilt, muss auch hasUncle(a,c) gelten.
1 hasParent(?x1,?x2) ^hasBrother(?x2,?x3) ÑhasUncle(?x1,?x3)
Listing 9.5: Beispiel einer SWRL-Regel
Tabelle 9.2 fasst die Abbildungen der PROCEED-Konzepte auf OWL-Konzepte zusammen.
PROCEED OWL
Schema Koncept owl:Class
SCAR, SCAA owl:ObjectProperty
Attribut owl:DatatypeProperty
Instanz owl:NamedIndividual
Tabelle 9.2.: Beziehungen zwischen den Konzepten von PROCEED und OWL
9.3. Realisierung der L¨osungskonzepte
In den folgenden Abschnitten werden zun¨
achst die Metaproduktontologie und anschließend die
Umsetzung von SCARs und SCAAs in OWL-2 erl¨
autert, bevor die Sicherstellung der strukturel-
len Konsistenz von Produktontologien detailliert wird. Anschließend wird die Umsetzung der
weiteren Komponenten der Architektur beschrieben.
9.3.1. Metaproduktontologie
Abbildung 9.5 veranschaulicht die Serialisierung der einzelnen Produktontologien. Alle Pro-
duktontologien basieren auf einer sog. Metaproduktontologie, welche die strukturellen Vorgaben
aus Abschnitt 6.2.1 als OWL-2-Ontologie umsetzt. Jede lokale und globale Produktontologie
sowie alle Produktontologie-Mapings importieren diese Metaproduktontologie. Schemakonzept-
Attributregeln und -Aktionen sowie die Korrespondenzen zwischen einer lokalen und globa-
len Produktontologie werden in einer separaten OWL2-Ontologie gespeichert (siehe Product
Ontology Mapping). Diese Ontologie wiederum importiert die zugrundeliegende lokale Produk-
tontologie und die globale.
209
9. Proof-of-Concept Implementierung
Abbildung 9.5.: Technische Realisierung lokaler und globaler Produktontologien mit OWL-2
Zusammengefasst werden in der Metaproduktontologie folgende Konzepte des PROCEED-Rah-
menwerkes definiert:
•Produktdatenintegrationsebene,
•Lokale und globale Produktontologie,
•Strukturelle Konsistenz einer Produktontologie,
•Produktontologie-Mapping,
•Referenzwerte und
•Integrationsausschluss.
Die nachfolgende Beschreibung der OWL-2-Ontologie erfolgt mittels Turtle-Syntax. Der ¨
Ubersicht
halber gelten die Pr¨
afixe in Listing 9.7 f¨
ur alle folgenden Listings und werden nicht jedes mal
neu aufgelistet.
1@prefix owl: <http://www.w3.org/2002/07/owl#>.
2@prefix rdf: <http://www.w3.org/1999/02/22´rdf´syntax´ns#>.
3@prefix xml: <http://www.w3.org/XML/1998/namespace>.
4@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
5@prefix rdfs: <http://www.w3.org/2000/01/rdf´schema#>.
Listing 9.6: Metaproduktontologie als OWL-Ontologie
Die Metaproduktontologie ist vom Type owl:Ontology. Sie hat einen definierten Ontologie-Typ
hasOntologyType, der als owl:AnnotationProperty definiert ist. Es wird zwischen Metapro-
duktontologie MetaProductOntologyType, globaler Produktontologie GlobalProductOntology-
Type, lokaler Produktontologie LocalProductOntologyType und Produktontologie-Mapping
ProductOntologyMappingZype unterschieden.
1@prefix :<http://www.uni´ulm.de/proceed/metaontology#>.
2@base <http://www.uni´ulm.de/proceed/metaontology>.
3<http://www.uni´ulm.de/proceed/metaontology>rdf:type owl:Ontology ;
4 rdfs:label ”Meta Product Ontology” ;
210
9.3. Realisierung der L¨
osungskonzepte
5 :hasOntologyType :MetaProductOntologyType .
6 :OntologyType rdf:type owl:Class .
7 :MetaOntologyType rdf:type owl:Class ;
8 rdfs:subClassOf :OntologyType .
9 :LocalProductOntologyType rdf:type owl:Class ;
10 rdfs:subClassOf :OntologyType .
11 :LocalMasterProductOntologyType rdf:type owl:Class ;
12 rdfs:subClassOf :OntologyType .
13 :GlobalProductOntologyType rdf:type owl:Class ;
14 rdfs:subClassOf :OntologyType .
15 :ProductOntologyMappingType rdf:type owl:Class ;
16 rdfs:subClassOf :OntologyType .
17 :hasOntologyType rdf:type owl:AnnotationProperty .
Listing 9.7: Metaproduktontologie als OWL-Ontologie
Schemakonzepte werden als owl:Class modelliert und es wird zwischen lokalem und globa-
lem Schemakonzept (LocalSchemaConcept,GlobalSchemaConcept) unterschieden (siehe Listing
9.8). Attribute werden als owl:DatatypeProperty realisiert (Attribute). DieProduktdateninte-
grationsebenen (siehe Abschnitt 6.2.1) werden als OWL-Klasse realisiert (ProductDataIntegra-
tionLayer). Attribute sind rdfs:subPropertyOf :Attribute, welches ein owl:DatatypePro-
perty ist. F¨
ur jede Produktdatenintegrationsebene (ProductDataIntegrationLayer) sind ein-
ander entsprechende lokale und globale OWL-Klassen als Subklassen definiert.
1@prefix :<http://www.uni´ulm.de/proceed/metaontology#>.
2@base <http://www.uni´ulm.de/proceed/metaontology>.
3
4 :SchemaConcept rdf:type owl:Class .
5
6 :LocalSchemaConcept rdf:type owl:Class ;
7 rdfs:subClassOf :SchemaConcept .
8
9 :GlobalSchemaConcept rdf:type owl:Class ;
10 rdfs:subClassOf :SchemaConcept .
11
12 :Attribute rdf:Type owl:DatatypeProperty.
13
14 :ProductDataIntegrationLayer rdf:type owl:Class .
15 :PDCLayer rdf:type owl:Class ;
16 rdfs:subClassOf :ProductDataIntegrationLayer .
17
18 :ObjectLayer rdf:type owl:Class ;
19 rdfs:subClassOf :ProductDataIntegrationLayer .
20
21 :VariantLayer rdf:type owl:Class ;
22 rdfs:subClassOf :ProductDataIntegrationLayer .
23
24 :VersionLayer rdf:type owl:Class ;
25 rdfs:subClassOf :ProductDataIntegrationLayer .
26
27 :LocalPDCLayer rdf:type owl:Class ;
28 rdfs:subClassOf :PDCLayer .
29
30 :LocalObjectLayer rdf:type owl:Class ;
31 rdfs:subClassOf :ObjectLayer.
32
211
9. Proof-of-Concept Implementierung
33 :LocalVariantLayer rdf:type owl:Class ;
34 rdfs:subClassOf :VariantLayer .
35
36 :LocalVersionLayer rdf:type owl:Class ;
37 rdfs:subClassOf :VersionLayer .
38
39 :GlobalPDCLayer rdf:type owl:Class ;
40 rdfs:subClassOf :PDCLayer .
41
42 :GlobalObjectLayer rdf:type owl:Class ;
43 rdfs:subClassOf :ObjectLayer .
44
45 :GlobalVariantLayer rdf:type owl:Class ;
46 rdfs:subClassOf :VariantLayer .
47
48 :GlobalVersionLayer rdf:type owl:Class ;
49 rdfs:subClassOf :VersionLayer .
Listing 9.8: Metaproduktontologie als OWL-Ontologie
Listing 9.9 definiert die notwendigen OWL-Klassen und Object-Properties, um die Hierarchie
von Schemakonzepten zu modellieren. Beziehungen zwischen Schemakonzepten unterschied-
licher Produktdatenintegrationsebenen werden als owl:ObjectProperty modelliert. Letztere
werden definiert als rdfs:subPropertyOf von isBelow und isAbove. Dabei ist isAbove als
owl:inverseOf von isBelow definiert. Dadurch muss nur eine der beiden Hierarchie-Richtungen
modelliert werden, w¨
ahrend die andere durch Inferenz (mittels eines Reasoners) automatisch be-
stimmt wird.
1@prefix :<http://www.uni´ulm.de/proceed/metaontology#>.
2@base <http://www.uni´ulm.de/proceed/metaontology>.
3
4 :isBelow rdf:Type owl:ObjectProperty .
5 :isAbove rdf:Type owl:ObjectProperty ;
6 owl:inverseOf :isBelow .
Listing 9.9: Modellierung der Hierarchie von Produktontologien
Listing 9.10 fasst die notwendigen Klassen und Beziehungen zusammen, die notwendig sind, um
Schemakonzept-Attributregeln in OWL zu modellieren. SCARs zwischen Schemakonzepten aus
lokaler und globaler Produktontologie werden als owl:ObjectProperties abgebildet. Die not-
wendigen Informationen der SCARs werden als owl:AnnotationProperty definiert. Dazu z¨
ahlen
die Matching-Funktion (hasMatchingFunction), m¨
ogliche Parameter (hasMatchingParameter)
sowie das lokale und globale Attribut (hasLocalAttribute,hasGlobalAttribute). Jede SCAR
wird entsprechend der Produktdatenintegrationsebene einem OWL-Objectproperty
(hasPDCSCARTo,hasObjectSCARTo,hasVariantSCARTo,hasVersionSCARTo) untergeordnet.
1@prefix :<http://www.uni´ulm.de/proceed/metaontology#>.
2@base <http://www.uni´ulm.de/proceed/metaontology>.
3
4 :MatchingFunction rdf:type owl:Class .
5
6 :MappingTable rdf:type owl:Class ;
7 rdfs:subClassOf :MatchingFunction .
8
9 :RegularExpression rdf:type owl:Class ;
10 rdfs:subClassOf :MatchingFunction .
212
9.3. Realisierung der L¨
osungskonzepte
11
12 :StringEquivalence rdf:type owl:Class ;
13 rdfs:subClassOf :MatchingFunction .
14
15 :Levenshtein rdf:type owl:Class ;
16 rdfs:subClassOf :MatchingFunction .
17
18 :hasMatchingFunction rdf:type owl:AnnotationProperty .
19
20 :hasMatchingParameter rdf:type owl:AnnotationProperty .
21
22 :hasLocalAttribute rdf:type owl:AnnotationProperty .
23
24 :hasGlobalAttribute rdf:type owl:AnnotationProperty .
25
26 :hasSCARTo rdf:type owl:ObjectProperty .
27
28 :hasPDCSCARTo rdf:type owl:ObjectProperty ;
29 rdfs:subPropertyOf :hasSCARTo .
30
31 :hasObjectSCARTo rdf:type owl:ObjectProperty ;
32 rdfs:subPropertyOf :hasSCARTo .
33
34 :hasVariantSCARTo rdf:type owl:ObjectProperty ;
35 rdfs:subPropertyOf :hasSCARTo .
36
37 :hasVersionSCARTo rdf:type owl:ObjectProperty ;
38 rdfs:subPropertyOf :hasSCARTo .
39
40 :hasCorrespondenceProbability rdf:type owl:AnnotationProperty .
41 :hasCorrespondenceCreationType rdf:type owl:AnnotationProperty .
42
43 :CorrespondenceCreationType rdf:type owl:Class .
44
45 :AutomaticCreation rdf:type owl:Class ;
46 rdfs:subClassOf :CorrespondenceCreationType .
47
48 :ManualCreation rdf:type owl:Class ;
49 rdfs:subClassOf :CorrespondenceCreationType .
Listing 9.10: Abbildung von SCARs
Analog definiert Listing 9.11 die notwendigen Klassen und Beziehungen zur Definition von
SCAAs. Neben dem lokalen und globalen Attribut (bereits in Listing 9.9 definiert) wird das
Integrationsverhalten (hasIntegrationBehavior)ben
¨
otigt. Entsprechend der Produktdatenin-
tegrationsebene werden SCAAs OWL-Objectproperties (hasPDCSCAATo,hasObjectSCAATo,
hasVariantSCAATo,hasVersionSCAATo) untergeordnet.
1@prefix :<http://www.uni´ulm.de/proceed/metaontology#>.
2@base <http://www.uni´ulm.de/proceed/metaontology>.
3
4 :IntegrationBehavior rdf:type owl:Class .
5
6 :LatestIntegrationBehavior rdf:type owl:Class ;
7 rdfs:subClassOf :IntegrationBehavior .
8
9 :LocalIntegrationBehavior rdf:type owl:Class ;
213
9. Proof-of-Concept Implementierung
10 rdfs:subClassOf :IntegrationBehavior .
11
12 :GlobalIntegrationBehavior rdf:type owl:Class ;
13 rdfs:subClassOf :IntegrationBehavior .
14
15 :hasSCAATo rdf:type owl:ObjectProperty .
16 :hasPDCSCAATo rdf:type owl:ObjectProperty ;
17 rdfs:subPropertyOf :hasSCAATo .
18
19 :hasObjectSCAATo rdf:type owl:ObjectProperty ;
20 rdfs:subPropertyOf :hasSCAATo .
21
22 :hasVariantSCAATo rdf:type owl:ObjectProperty ;
23 rdfs:subPropertyOf :hasSCAATo .
24
25 :hasVersionSCAATo rdf:type owl:ObjectProperty ;
26 rdfs:subPropertyOf :hasSCAATo .
27
28 :hasIntegrationBehavior rdf:type owl:AnnotationProperty .
29
30 :hasAttributeJustification rdf:type owl:AnnotationProperty .
Listing 9.11: Abbildung von SCAAs
Listing 9.12 fasst grundlegende Metaattribute zusammen, die f¨
ur alle Schemakonzepte, Instan-
zen, SCARs,SCAAs und Korrespondenzen definiert werden. Zu ihnen z¨
ahlt der Ersteller eines Ar-
tefakts (Creator Metattr, der Erstellungszeitpunkt (CreationDate Metattr) sowie der letzte
¨
Anderungszeitpunkt (LastModified Metattr). Des weiteren werden Metaattribute definiert, um
Varianten- und Versionstypen f¨
ur Schemakonzepte definieren zu k¨
onnen (VariantType Metattr
und VersionType Metattr).
1@prefix :<http://www.uni´ulm.de/proceed/metaontology#>.
2@base <http://www.uni´ulm.de/proceed/metaontology>.
3
4@prefix :<http://www.uni´ulm.de/proceed/metaontology.owl#>.
5
6:CreatorMetattr rdf:type owl:DatatypeProperty ;
7 rdfs:subClassOf :Metaattribute ;
8 rdfs:domain :SchemaConcept .
9
10 :CreationDate Metattr rdf:type owl:DatatypeProperty ;
11 rdfs:subClassOf :Metaattribute ;
12 rdfs:domain :SchemaConcept .
13
14 :LastModified Metattr rdf:type owl:DatatypeProperty ;
15 rdfs:subClassOf :Metaattribute ;
16 rdfs:domain :SchemaConcept .
17
18 :hasVariantType Metaattr rdf:type owl:AnnotationProperty ;
19 rdfs:subClassOf :Metaattribute ;
20 rdfs:domain :LocalVariantLayer .
21
22 :hasVersionType Metaattr rdf:type owl:AnnotationProperty ;
23 rdfs:subClassOf :Metaattribute ;
24 rdfs:domain :LocalVersionLayer .
Listing 9.12: Definition von Metaattributen
214
9.3. Realisierung der L¨
osungskonzepte
In Listing 9.13 sind die notwendigen Klassen dargestellt, um Instanzen von einer automatischen
Integration auszuschließen. Alle Schemakonzepte, die als Subklasse von ExcludeSCFromIntegra-
tion definiert sind, werden bei der Integration sowie der Bestimmung der Integrationsqualit¨
at
nicht ber¨
ucksichtigt. Gleiches gilt f¨
ur alle Instanzen des Typs ExcludeIndFromIntegration.
1@prefix :<http://www.uni´ulm.de/proceed/metaontology#>.
2@base <http://www.uni´ulm.de/proceed/metaontology>.
3
4 :ExcludeFromIntegration rdf:type owl:Class .
5 :ExcludeSCFromIntegration rdf:type owl:Class ;
6 rdfs:subClassOf :ExcludeFromIntegration .
7 :ExcludeIndFromIntegration rdf:type owl:Class ;
8 rdfs:subClassOf :ExcludeFromIntegration .
Listing 9.13: Integrationsauschluss von Instanzen
Listing 9.14 illustriert die notwendigen Klassen, um Referenzwerte f¨
ur lokale und globale Pro-
duktontologien definieren zu k¨
onnen. Jede Integrationsqualit¨
atsmetrik aus Kapitel 7 ist der
OWL-Klasse IntegrationQualityMetric untergeordnet. Die Referenzwerte der einzelnen Me-
triken sind Instanzen der jeweiligen Klassen. Sie besitzen einen Zeitpunkt (hasDueDate) und
einen Wert (hasValue).
1@prefix :<http://www.uni´ulm.de/proceed/metaontology#>.
2@base <http://www.uni´ulm.de/proceed/metaontology>.
3
4 :IntegrationQualityMetric rdf:type owl:Class .
5 :hasDueDate rdf:type owl:DatatypeProperty ;
6 rdfs:domain :IntegrationQualityMetric ;
7 rdfs:range xsd:Date .
8
9 :hasValue rdf:type owl:DatatypeProperty ;
10 rdfs:domain :IntegrationQualityMetric ;
11 rdfs:range xsd:Float .
12
13 :LocalSCCompleteness rdf:type owl:Class ;
14 rdfs:subClassOf :IntegrationQualityMetric .
15
16 :LocalSCARCompleteness rdf:type owl:Class ;
17 rdfs:subClassOf :IntegrationQualityMetric .
18
19 :LocalSCAACompleteness rdf:type owl:Class ;
20 rdfs:subClassOf :IntegrationQualityMetric .
21
22 :LocalSCARSCAACompleteness rdf:type owl:Class ;
23 rdfs:subClassOf :IntegrationQualityMetric .
24
25 :LocalIndCompleteness rdf:type owl:Class ;
26 rdfs:subClassOf :IntegrationQualityMetric .
27
28 :GlobalSCCompleteness rdf:type owl:Class ;
29 rdfs:subClassOf :IntegrationQualityMetric .
30
31 :GlobalIndCompleteness rdf:type owl:Class ;
32 rdfs:subClassOf :IntegrationQualityMetric .
33
34 :GlobalIndAttrCompleteness rdf:type owl:Class ;
35 rdfs:subClassOf :IntegrationQualityMetric .
215
9. Proof-of-Concept Implementierung
36
37 :GlobalIndAttrConsistency rdf:type owl:Class ;
38 rdfs:subClassOf :IntegrationQualityMetric .
Listing 9.14: Definition von Referenzwerten
9.3.2. Abbildung einer Produktontologie
Basierend auf der Metaproduktontologie werden in den folgenden Listings beispielhaft eine lokale
und die globale Produktontologie mit Hilfe von OWL-2 abgebildet. In Listing 9.15 sind die
grundlegenden Eigenschaften der lokalen Produktontologie lpo1 spezifiziert. Um die Lesbarkeit
zu erh¨
ohen, enden die Bezeichnungen der Ontologie-Artefakte auf das entsprechende Konzept
des PROCEED-Rahmenwerkes. Beispielsweise enden Schemakonzepte auf SC, Instanzen auf Ind
und Attribute auf Attr.
1@prefix mo: <http://www.uni´ulm.de/proceed/metaontology.owl#>.
2@prefix :<http://www.uni´ulm.de/proceed/lpo1#>.
3@base <http://www.uni´ulm.de/proceed/lpo1>.
4
5 lpo1 rdf:type owl:Ontology ;
6 rdfs:label ”Local Product Ontology 1” ;
7 owl:versionInfo ”1.0” ;
8 rdfs:comment ”Local Product Ontology 1” ;
9 owl:imports <http://www.uni´ulm.de/proceed/metaontology.owl#>;
10 mo:ontologyType mo:LocalProductOntology .
Listing 9.15: Produktontologie als OWL-Ontologie
Die lokale Produktontologie lpo1 besitzt je ein Schemakonzept f¨
ur jede Produktdatenintegrati-
onsebene (siehe Product SC,ECU SC,ECUVariant SC und ECUVersion SC in Listing 9.16). Die
Zuordnung eines Schemakonzeptes zu einer Ebene erfolgt durch Unterordnung in die entspre-
chenden OWL-Klassen, die zuvor in der Metaproduktontologie definiert wurden.
1@prefix mo: <http://www.uni´ulm.de/proceed/metaontology.owl#>.
2@prefix :<http://www.uni´ulm.de/proceed/lpo1#>.
3@base <http://www.uni´ulm.de/proceed/lpo1>.
4
5 :Product SC rdf:type owl:Class ;
6 rdfs:label ”Product” ;
7 rdfs:subClassOf mo:LocalPDCLayer .
8:ECUSC rdf:type owl:Class ;
9 rdfs:label ”ECU” ;
10 rdfs:subClassOf mo:LocalObjectLayer .
11 :ECUVariant SC rdf:type owl:Class ;
12 rdfs:label ”ECU Variant” ;
13 rdfs:subClassOf mo:LocalVariantLayer .
14 :ECUVersion SC rdf:type owl:Class ;
15 rdfs:label ”ECU Version” ;
16 rdfs:subClassOf mo:LocalVersionLayer .
Listing 9.16: Produktontologie als OWL-Ontologie
Die Hierarchie der Schemakonzepte zeigt Listing 9.16. Zwischen jeweils zwei Schemakonzepten,
die sich auf ¨
uber- bzw. untereinanderliegenden Produktdatenintegrationsebenen befinden, sind
entsprechende OWL-Objectproperties definiert.
216
9.3. Realisierung der L¨
osungskonzepte
1@prefix mo: <http://www.uni´ulm.de/proceed/metaontology.owl#>.
2@prefix :<http://www.uni´ulm.de/proceed/lpo1#>.
3@base <http://www.uni´ulm.de/proceed/lpo1>.
4
5 :ecuBelowProduct rdf:type owl:ObjectProperty ;
6 rdfs:label ”ECUIsBelowProduct” ;
7 rdfs:subPropertyOf mo:isBelow ;
8 rdfs:domain :ECU SC ;
9 rdfs:range :Product SC .
10
11 :productAboveEcu rdf:type owl:ObjectProperty ;
12 rdfs:label ”ProductIsAboveECU” ;
13 rdfs:subPropertyOf mo:isAbove ;
14 rdfs:domain :Product SC ;
15 rdfs:range :ECU SC .
16
17 :ecuBelowProduct owl:inversOf lpo1:productAboveEcu .
18
19 :ecuVariantBelowEcu rdf:type owl:ObjectProperty ;
20 rdfs:label ”ECUVariantIsBelowECU” ;
21 rdfs:subPropertyOf mo:isBelow ;
22 rdfs:domain :ECUVariant SC ;
23 rdfs:range :ECU SC .
24
25 :ecuAboveEcuVariant rdf:type owl:ObjectProperty ;
26 rdfs:label ”EcuIsAboveECUVariant” ;
27 rdfs:subPropertyOf mo:isAbove ;
28 rdfs:domain :ECU SC ;
29 rdfs:range :ECUVariant SC .
30
31 :ecuVariantBelowEcu owl:inversOf lpo1:ecuAboveEcuVariant .
32
33 :ecuVersionBelowEcuVariant rdf:type owl:ObjectProperty ;
34 rdfs:label ”ECUVersionIsBelowECUVariant” ;
35 rdfs:subPropertyOf mo:isBelow ;
36 rdfs:domain :ECUVersion SC ;
37 rdfs:range :ECUVariant SC .
38
39 :ecuVariantAboveEcuVersion rdf:type owl:ObjectProperty ;
40 rdfs:label ”EcuVariantIsAboveECUVersion” ;
41 rdfs:subPropertyOf mo:isAbove ;
42 rdfs:domain :ECUVariant SC ;
43 rdfs:range :ECUVersion SC .
Listing 9.17: Produktontologie als OWL-Ontologie
F¨
ur die Schemakonzepte der lokalen Produktontologie lpo1 sind folgende Attribute definiert
(siehe Listing 9.18). Jeder Instanz der Schemakonzepte besitzt einen Namen (name attr). F¨
ur
das Schemakonzept ECUVariant ist ein Attribut definiert, welches die Beschreibung der Variante
beinhaltet (variant Attr). F¨
ur ECUVersion sind sowohl eine Versionsummer (versionId Attr
als auch eine Referenz auf ein Dokument (versionReference) spezifiziert. Schließlich definieren
mo:hasVariantType Metaattr und mo:hasVersionType Metaattr die Art des zugrundeliegen-
den Variantenmechanismus und der Versionierung.
217
9. Proof-of-Concept Implementierung
1@prefix mo: <http://www.uni´ulm.de/proceed/metaontology.owl#>.
2@prefix :<http://www.uni´ulm.de/proceed/lpo1#>.
3@base <http://www.uni´ulm.de/proceed/lpo1>.
4
5:nameAttr rdf:type owl:DatatypeProperty ;
6 rdfs:subPropertyOf mo:Attribute ;
7 rdfs:domain :Product SC, :ECU SC, :ECUVariant SC, :ECUVersion SC ;
8 rdfs:range xsd:string .
9
10 :variant Attr rdf:type owl:DatatypeProperty ;
11 rdfs:subPropertyPf mo:Attribute ;
12 rdfs:domain :ECUVariant ;
13 rdfs:range xsd:string .
14
15 :versionId Attr rdf:type owl:DatatypeProperty ;
16 rdfs:subPropertyPf mo:Attribute ;
17 rdfs:domain :ECUVersion ;
18 rdfs:range xsd:integer .
19
20 :versionReference Attr rdf:type owl:DatatypeProperty ;
21 rdfs:subPropertyPf mo:Attribute ;
22 rdfs:domain :ECUVersion ;
23 rdfs:range xsd:string .
24
25 :ECUVariant mo:hasVariantType Metaattr ”Typ1”ˆˆxsd:string .
26
27 :ECUVersion mo:hasVersionType Metaattr ”Baseline”ˆˆxsd:string .
Listing 9.18: Attribut als OWL-DatatypeProperty
F¨
ur die einzelnen Schemakonzepte sind die Instanzen aus Listing 9.21 in lpo1 modelliert. F¨
ur die
Hierarchiebeziehungen zwischen Instanzen ist nur eine Richtung modelliert, die andere kann mit-
tels Inferenz durch einen Reasoner bestimmt werden. Eine Instanz wird als owl:NamedIndividual
modelliert. Die Zuordnung zu einem Schemakonzept erfolgt durch die Beziehung rdf:type sowie
Attributwerte mittels Referenz entsprechender OWL-Datatype-Properties.
1@prefix :<http://www.uni´ulm.de/proceed/lpo1#>.
2@base <http://www.uni´ulm.de/proceed/lpo1>.
3
4:PDC1Ind rdf:type owl:NamedIndividual, :Product SC ;
5 rdfs:label ”Limousine2017” ;
6:nameAttr ”Limousine”ˆˆxsd:string .
7
8 :Object1 Ind rdf:type owl:NamedIndividual, :ECU SC ;
9 rdfs:label ”ECM” ;
10 :name Attr ”Engine Control Module”ˆˆxsd:string .
11
12 :Object1 Ind :ecuBelowProduct :PDC1 Individual .
13
14 :Variant1 Ind rdf:type owl:NamedIndividual, :ECUVariant SC ;
15 rdfs:label ”ECM Diesel” ;
16 :name Attr ”Engine Control Module for Diesel”ˆˆxsd:string .
17
18 :Variant2 Ind rdf:type owl:NamedIndividual, :ECUVariant SC ;
19 rdfs:label ”ECM Gasoline” ;
20 :name Attr ”Engine Control Module for Gasoline”ˆˆxsd:string .
21
218
9.3. Realisierung der L¨
osungskonzepte
22 :Variant1 Ind :ecuVariantBelowEcu :Object1 Ind .
23
24 :Variant2 Ind :ecuVariantBelowEcu :Object1 Ind .
25
26 :Version1 Ind rdf:type owl:NamedIndividual, :ECUVersion SC ;
27 rdfs:label ”ECM Diesel V1” ;
28 :name Attr ”Engine Control Module for Diesel V1”ˆˆxsd:string ;
29 :VersionId Attr 1ˆˆxsd:integer ;
30 :reference Attr ”\prj\...\ECM”ˆxsd:string
31
32 :Version2 Ind rdf:type owl:NamedIndividual, :ECUVersion SC ;
33 rdfs:label ”ECM Gasoline V1” ;
34 :name Attr ”Engine Control Module for Gasoline V1”ˆˆxsd:string .
35
36 :Version2 Ind :VersionId Attr 1ˆˆxsd:string
37
38 :Version1 Ind :ecuVariantBelowEcu :Variant1 Ind .
39
40 :Version2 Ind :ecuVariantBelowEcu :Variant2 Ind .
Listing 9.19: Instanz als OWL-NamedIndividual
Zusammengefasst illustriert Abbildung 9.6 die zuvor beschriebe lokale Produktontologie lpo1
mit Bezug auf die einzelnen Artefakte der OWL-Ontologie. Analog zeigt Abbildung 9.7 eine
m¨
ogliche globale Produktontologie, deren OWL-2-Definition der ¨
Ubersicht halber im Anhang A
(siehe Listing 11.4) zu finden ist.
Abbildung 9.6.: Grafische Darstellung der lokalen Produktontologie lpo1
219
9. Proof-of-Concept Implementierung
Abbildung 9.7.: Grafische Darstellung der globalen Produktontologie gpo
9.3.3. Abbildung des Produktontologie-Mappings
Nach Definition von lokaler und globaler Produktontologie, k¨
onnen Schemakonzept-Attribut-
regeln und -Aktionen im Produktontologie-Mapping spezifiziert werden. Listing 9.22 zeigt einen
Ausschnitt des Produktontologie-Mappings pomapping1 zwischen der lokalen Produktontologie
lpo1 und der globalen Produktontologie gpo. Die Schemakonzept-Attributregel productCor-
respondensProject SCAR definiert f¨
ur die Attribute lpo1:name Attr und gpo:label Attr eine
Matching-Funktion mo:StringEquivalence.
1@prefix lpo1: <http://www.uni´ulm.de/proceed/lpo1.owl#>.
2@prefix gpo: <http://www.uni´ulm.de/proceed/gpo.owl#>.
3@prefix :<http://www.uni´ulm.de/proceed/pomapping1#>.
4@base <http://www.uni´ulm.de/proceed/pomapping1>.
5
6 :productCorrespondesProject SCAR rdf:type owl:ObjectProperty , owl:SymmetricProperty ;
7 rdfs:subPropertyOf mo:hasPDCSCARTo .
8 :hasMatchingFunction mo:StringEquivalence ;
9 :hasMatchingParameter ”” ;
10 rdfs:domain lpo1:Product SC ;
11 rdfs:range gpo:Product SC ;
12 mo:hasLocalAttribute lpo1:name Attr .
13 mo:hasGlobalAttribute gpo:label Attr .
Listing 9.20: Beispiel einer SCAR in OWL2
220
9.3. Realisierung der L¨
osungskonzepte
Analog dazu zeit Listing 9.21 ein Beispiel f¨
ur eine Schemakonzept-Attributaktion. Die SCAA
ecuVersion2ComponentVersion SCAA definiert eine Attributaktion zwischen den Attributen
lpo1:reference Attr und gpo:ECUVersion Ref Attr mit dem Integrationsverhalten
mo:LatestIntegrationBehavior.
1@prefix lpo1: <http://www.uni´ulm.de/proceed/lpo1.owl#>.
2@prefix gpo: <http://www.uni´ulm.de/proceed/gpo.owl#>.
3@prefix :<http://www.uni´ulm.de/proceed/pomapping1#>.
4@base <http://www.uni´ulm.de/proceed/pomapping1>.
5
6 :ecuVersion2ComponentVersion SCAA rdf:type owl:ObjectProperty ;
7 rdfs:subPropertyOf mo:hasVersionSCAATo
8 :hasIntegrationBehavior mo:LatestIntegrationBehavior ;
9
10 rdfs:domain lpo1:ECU VERSION SC ;
11 rdfs:range gpo:ComponentVersion SC ;
12 mo:hasLocalAttribute lpo1:reference Attr ;
13 mo:hasGlobalAttribute gpo:ECUVersion Ref Attr .
Listing 9.21: Beispiel einer SCAA in OWL2
Werden mit Hilfe des Integrationsalgorithmus (siehe Abschnitt 6.3.1) oder mit den ¨
Anderungs-
operation (s. Kapitel 8) Korrespondenzen ermittelt, m¨
ussen sie im Produktontologie-Mapping
gespeichert werden. Listing 9.22 zeigt ein Beispiel f¨
ur eine Korrespondenz, die auf der SCAR
:productCor-respondesProject SCAR basiert. Die Korrespondenz ist zwischen der lokalen In-
stanz lpo1:PDC1 Ind und der globalen Instanz gpo:PDC2 Ind definiert, der Erstellungstyp
(mo:hasCorrespondenceCreationType)istmo:AutomaticCreation.
1@prefix mo: <http://www.uni´ulm.de/proceed/metaontology.owl#>.
2@prefix lpo1: <http://www.uni´ulm.de/proceed/lpo1.owl#>.
3@prefix gpo: <http://www.uni´ulm.de/proceed/gpo.owl#>.
4@prefix :<http://www.uni´ulm.de/proceed/pomapping1#>.
5@base <http://www.uni´ulm.de/proceed/pomapping1>.
6
7 [] a owl:Axiom ;
8 owl:annotatedProperty :productCorrespondesProject SCAR ;
9 owl:annotatedSource lpo1:PDC1 Ind ;
10 owl:annotatedTarget gpo:PDC2 Ind ;
11 mo:hasCorrespondenceProbability ”1.0”ˆˆxsd:float ;
12 mo:hasCorrespondenceCreationType mo:AutomaticCreation .
Listing 9.22: Beispiel einer Korrespondenz in OWL2
Schließlich illustriert Listing 9.23 die Modellierung einer Attribut-Begr¨
undung (siehe Definition
36) in OWL-2. Der Attributwert Link des Attributs ECU Ref Attr f¨
ur die Instanz ComponentVer-
sion1 Ind ist durch die Schemakonzept-Attributaktion ecuVersion2ComponentVersion SCAA
zustande gekommen.
1@prefix lpo1: <http://www.uni´ulm.de/proceed/lpo1.owl#>.
2@prefix gpo: <http://www.uni´ulm.de/proceed/gpo.owl#>.
3@prefix :<http://www.uni´ulm.de/proceed/pomapping1#>.
4@base <http://www.uni´ulm.de/proceed/pomapping1>.
5
6 [ rdf:type owl:Axiom ;
7 owl:annotatedTarget ”Link”ˆˆxsd:string ;
8 owl:annotatedSource :ComponentVersion1 Ind ;
9 owl:annotatedProperty :ECU Ref Attr ;
221
9. Proof-of-Concept Implementierung
10 :hasAttributeJustification :ecuVersion2ComponentVersion SCAA
11 ] .
Listing 9.23: Beispiel einer Attribut-Begr¨
undung in OWL2
9.3.4. Sicherstellung der strukturellen Konsistenz
Die in Definition 24 (siehe Abschnitt 6.2.1) spezifizierten Eigenschaften sind Voraussetzung
f¨
ur die Umsetzung der Konzepte des PROCEED-Rahmenwerkes (z.B. Integrationsalgorithmus,
¨
Anderungsoperationen). Im Folgenden wird erl¨
autert, wie die strukturelle Konsistenz einer Pro-
duktontologie im PROCEED-System technisch umgesetzt wird.
Mit Hilfe von SWRL lassen sich Regeln f¨
ur OWL-Ontologien definieren, die dem OWL-DL-
Profil (basierend auf Beschreibungslogiken) entsprechen. Zwar lassen sich mit SWRL Regeln
definieren, die ¨
uber die Ausdrucksm¨
achtigkeit von OWL-DL-Ontologien hinaus gehen, jedoch
werden zum Beispiel Ausdr¨
ucke wie rdf:type oder rdfs:Class nicht unterst¨
utzt. Aus diesem
Grund wird die Sicherstellung der strukturellen Konsistenz von Produktontologien mit Hilfe von
SPARQL-Abfragen realisiert. Zun¨
achst werden die Schemakonsistenzregeln (vgl. Kapitel 6.2.1)
wiederholte, bevor ihre Definition mittels SPAQRL erl¨
autert wird.
Schemakonsistenzregel 1: Jede Produktdatenintegrationsebene besitzt mindestens ein
Schemakonzept. Ein Schemakonzept kann nur mit einem Schemakonzept verbunden werden,
das sich auf einer darunter liegenden Produktdatenintegrationsebene befindet.
Listing 9.24 realisiert einen Teil der Schemakonsistenzregel 1 indem die Produktdatenintegra-
tionsebenen bestimmt werden, f¨
ur die keine Schemakonzepte definiert sind. ?l1 gibt die Pro-
duktdatenintegrationsebene und ?perLayer die Anzahl der Schemakonzepte zur¨
uck. Da letztere
gefiltert werden (HAVING (?perLayer leq 1)), ist diese Anzahl immer 0.
1PREFIXmo:<http://www.uni´ulm.de/proceed/metaontology#>
2 PREFIX lpo1: <http://www.uni´ulm.de/proceed/lpo1#>
3 SELECT ?l1 (COUNT(?sc) as ?perLayer)
4WHERE{
5 ?sc rdfs:subClassOf ?l1 .
6 FILTER (?l1 = mo:LocalPDCLayer || ?l1 = mo:LocalObjectLayer || ?l1 = mo:LocalVariantLayer || ?l1 =
mo:LocalVersionLayer)
7}
8GROUPBY?l1
9 HAVING (?perLayer <1)
Listing 9.24: SPARQL-Query zur Ermittlung fehlender Schemakonzepte
Listing 9.25 realisiert den restlichen Teil von Schemakonsistenzregel 1. Die Abfrage liefert alle
Schemakonzept-Paare zur¨
uck, die sich auf ¨
ubereinanderliegenden Produktdatenintegrationsebe-
nen befinden, f¨
ur die jedoch keine Hierarchie-Beziehung isBelow definiert ist. Da die Hierarchie-
Beziehungen als rdfs:subPropertyOf definiert werden und SPARQL keine Inferenzen ber¨
uck-
sichtigt, muss mit Hilfe eines Reasoners die Typisierung der Klassen vorgenommen werden.
1PREFIXmo:<http://www.uni´ulm.de/proceed/metaontology#>
2 PREFIX lpo1: <http://www.uni´ulm.de/proceed/lpo1#>
3 SELECT DISTINCT ?sc ?sc2
4WHERE{
5 ?sc rdfs:subClassOf ?l1 .
222
9.3. Realisierung der L¨
osungskonzepte
6 ?sc2 rdfs:subClassOf ?l2 .
7 FILTER ( (?l1 = mo:LocalPDCLayer && ?l2=mo:LocalObjectLayer) || (?l1 = mo:LocalObjectLayer &&
?l2=mo:LocalVariantLayer) || (?l1 = mo:LocalVariantLayer && ?l2=mo:LocalVersionLayer))
8 FILTER NOT EXISTS {
9 ?op1 rdf:type owl:ObjectProperty .
10 ?op1 rdfs:subPropertyOf mo:isBelow .
11 ?op1 rdfs:range ?sc .
12 ?op1 rdfs:domain ?sc2 .
13 }
14 }
Listing 9.25: SPARQL-Query zur Bestimmung fehlender Hierarchie-Beziehungen zwischen
Schemakonzepten
Schemakonsistenzregel 2: F¨
ur jedes Schemakonzept der Variant-Ebene ist der Varia-
bilit¨
atstyp definiert. Schemakonsistenzregel 3: F¨
ur jedes Schemakonzept der Versions-
Ebene ist der Versionstyp definiert.
Die SPARQL-Abfrage in Listing 9.26 liefert die Liste ?sc, welche diejenigen Schemakonzepte
der Variant-Ebene umfasst, f¨
ur die kein Metaattribut zur Beschreibung eines Variantentypes
definiert ist. Analog liefert Listing 9.27 die Liste entsprechend Schemakonsistenzregel 3.
1PREFIXmo:<http://www.uni´ulm.de/proceed/metaontology#>
2 PREFIX lpo1: <http://www.uni´ulm.de/proceed/lpo1#>
3 SELECT ?sc
4WHERE{
5 ?sc rdfs:subClassOf mo:LocalVariantLayer .
6 FILTER (not exists {?sc mo:hasVariantType Metaattr ?x})
7}
Listing 9.26: SPARQL-Query zur Bestimmung von Varianten-Schemakonzepten ohne Variantentyp
1PREFIXmo:<http://www.uni´ulm.de/proceed/metaontology#>
2 PREFIX lpo1: <http://www.uni´ulm.de/proceed/lpo1#>
3 SELECT ?sc
4WHERE{
5 ?sc rdfs:subClassOf mo:LocalVersionLayer .
6 FILTER (not exists {?sc mo:hasVersionType Metaattr ?x})
7}
Listing 9.27: SPARQL-Query zur Bestimmung von Versions-Schemakonzepten ohne Versionstyp
Instanzkonsistenzregel 1: Die Instanzen einer globalen Produktontologie sind zwischen
den Produktdatenintegrationsebenen, analog zu ihren Schemakonzepten, ¨
uber Beziehungen
miteinander verbunden.
In Listing 9.28 werden diejenigen Instanzen ?ind1 und ?ind2 bestimmt, die sich in ¨
ubereinander
liegenden Produktdatenintegrationsebenen befinden, f¨
ur die jedoch keine Beziehung definiert ist.
1PREFIXmo:<http://www.uni´ulm.de/proceed/metaontology#>
2 PREFIX lpo1: <http://www.uni´ulm.de/proceed/lpo1#>
3 SELECT DISTINCT ?ind1 ?ind2
4WHERE{
5 ?ind1 rdf:type ?l1 .
6 ?ind2 rdf:type ?l2 .
223
9. Proof-of-Concept Implementierung
7 ?ind1 rdf:type owl:NamedIndividual .
8 ?ind2 rdf:type owl:NamedIndividual .
9 FILTER ((not exists {?ind2 mo:isBelow ?ind1}||not exists {?ind1 mo:isAbove ?ind2})&&((?l1=mo:
LocalPDCLayer && ?l2 = mo:LocalObjectLayer) || (?l1 = mo:LocalObjectLayer && ?l2 = mo:
LocalVariantLayer) || (?l1 = mo:LocalVariantLayer && ?l2 = mo:LocalVersionLayer)) )
10 }
Listing 9.28: SPARQL-Query zur Bestimmung fehlender Hierarchie-Beziehungen zwischen
Instanzen
Instanzkonsistenzregel 2: Die Instanzen eines Schemakonzeptes auf der Version-Ebene
sind durch Vorg¨
anger- und Nachfolger-Beziehungen geordnet.
Die Vorg¨
anger- und Nachfolgerbeziehungen zwischen Instanzen der Versions-Ebene sind genau
dann nicht konsistent, wenn Instanzen existieren, f¨
ur die weder Vor- noch Nachfolgerbeziehungen
definiert sind. Die entsprechende SPARQL-Abfrage ist in Listing 9.29 dargestellt.
1PREFIXmo:<http://www.uni´ulm.de/proceed/metaontology#>
2 PREFIX lpo1: <http://www.uni´ulm.de/proceed/lpo1#>
3 SELECT DISTINCT ?ind1
4WHERE{
5 ?sc rdfs:subClassOf mo:LocalVersionLayer .
6 ?ind1 rdf:type ?sc .
7 ?ind1 rdf:type owl:NamedIndividual .
8 FILTER (not exists{?ind1 mo:isSuccessorOf ?x}&& not exists{?ind1 mo:isPredecessorOf ?x})
9}
Listing 9.29: SPARQL-Query zur Ermittlung von Versionsinstanzen ohne Vorg¨
anger und ohne
Nachfolger
9.3.5. Realisierung von Integrationsqualit¨atsmetriken
Analog zur Sicherstellung der strukturellen Konsistenz von Produktontologien lassen sich die
Integrationsqualit¨
atsmetriken mit Hilfe von SPARQL-Abfragen umsetzen. In Listing 9.30 wird
exemplarisch die lokale Schemakonzept-Vollst¨
andigkeit (vgl. Definition 44 in Kapitel 7) als
SPARQL-Abfrage definiert. Im Detail werden mit Hilfe von UNION sowohl die Anzahl der Sche-
makonzepte ?scmapped ermittelt, f¨
ur die eine Schemakonzept-Attributregel vorhanden ist, als
auch die Anzahl ?sc aller Schemakonzepte, die nicht von der Integration ausgeschlossen sind.
Das Ergebnis ?result entspricht der Differenz aus beiden vorherigen Zahlen. Analog lassen sich
alle Integrationsqualit¨
atsmetriken aus Kapitel 7 mit Hilfe von SPARQL-Abfragen definieren.
1PREFIXmo:<http://www.uni´ulm.de/proceed/metaontology#>
2 PREFIX lpo1: <http://www.uni´ulm.de/proceed/lpo1#>
3 SELECT (count (distinct ?sc) as ?scmapped) (count (distinct ?sc2) as ?sc) ( (?scmapped/?sc) as ?result)
4WHERE{
5
6{
7 ?sc rdfs:subClassOf ?scl .
8 ?scar rdfs:subPropertyOf ?scarl .
9 ?scar rdfs:domain ?sc
10 FILTER ( (?scl = mo:LocalPDCLayer && ?scarl = mo:hasPDCSCARTo) || (?scl = mo:
LocalObjectLayer && ?scarl = mo:hasObjectSCARTo) || (?scl = mo:LocalVariantLayer && ?scarl
= mo:hasVariantSCARTo) || (?scl = mo:LocalVersionLayer && ?scarl = mo:hasVersionSCARTo))
11 }
224
9.3. Realisierung der L¨
osungskonzepte
12
13 UNION
14 {
15 ?sc2 rdfs:subClassOf ?scl2 .
16 FILTER ( ?scl2 = mo:LocalPDCLayer || ?scl2 = mo:LocalObjectLayer || ?scl2 = mo:LocalVariantLayer
|| ?scl2 = mo:hasVariantSCARTo || ?scl2 = mo:LocalVersionLayer)
17 FILTER NOT EXISTS {
18 ?sc2 rdfs:subClass mo:ExcludeSCFromIntegration
19 }
20 }
21
22 }
Listing 9.30: SPARQL-Query zur Bestimmung der lokalen Schemakonzept-Vollst¨
andigkeit
9.3.6. Realisierung des Integrationsalgorithmus sowie der ¨
Anderungsoperationen
W¨
ahrend die strukturelle Konsistenz und Qualit¨
atsmetriken durch SPARQL-Abfragen reali-
siert werden, reicht dies f¨
ur die Umsetzung des Integrationsalgorithmus (siehe Abschnitt 6.3.1)
aus. Folglich wurde dieser Algorithmus softwareseitig mithilfe der OWL API [HB11] umgesetzt.
Im Detail wurde dazu ein Plugin f¨
ur den Ontologie-Editor Prot´eg´e [GMF`03] implementiert.
W¨
ahrend Prot´eg´e ein weit verbreiteter Editor zur Modellierung von Ontologien ist, reichen
die existierenden Plugins nicht aus, um alle Konzepte des PROCEED-Rahmenwerkes direkt zu
unterst¨
utzen. Folglich wurde f¨
ur Prot´eg´e ein Plugin realisiert, welches f¨
ur die Umsetzung des
PROCEED-Systems zust¨
andig ist.
Abbildung 9.8 illustriert die technische Architektur von Prot´eg´e in der Version 4. Basierend
auf Java und dem OSGi-Framework [All03] besteht Prot´eg´e aus OSGi-Plugins. W¨
ahrend The
Prot´
eg´
e 4 OWL Editor Plugin f¨
ur die Modellierung von OWL-Ontologien und die Umsetzung
einer grafischen Oberfl¨
ache zust¨
andig ist, wird die Serialisierung und Deserialisierung einer OWL-
Ontologie mittels der OWL API umgesetzt. Dar¨
uber hinaus gibt es eine Vielzahl weiterer Plugins.
F¨
ur die Realisierung des PROCEED-Systems wurden das Hermit Reasoner Plugin [SMH08]
und das Prot´
eg´
e SPARQL Plugin verwendet. Basierend auf diesem Plugin baut das PROCEED-
System als weiteres OSGI-Plugin auf den vorangehend genannten Plugins auf. Im Detail realisiert
das PROCEED Plugin die Architektur aus Abbildung 9.1.
Abbildung 9.8.: Technische Architektur des PROCEED-Systems
225
9. Proof-of-Concept Implementierung
W¨
ahrend der Editor von Prot´eg´edieM
¨
oglichkeit bietet, OWL-Ontologien zu modellieren, ist die-
ser Editor f¨
ur Dom¨
anenexperten zu komplex, um Produktontologie zu modellieren. Zur einfachen
Umsetzung der strukturellen Konsistenz wurden Konzepte f¨
ur Benutzerober߬
achen entworfen,
mittels der sich Produktontologien sowohl in Form von Graphen als auch mit Hilfe von Listen
zu erstellen lassen [Mer14]. Das Konzept definiert f¨
ur verschiedene Nutzerrollen des PROCEED-
Rahmenwerkes (siehe Abschnitt 6.2.5) unterschiedliche Sichten (z.B. Listen, Baumstrukturen
und Graphen). Zur Reduktion der Komplexit¨
at wurde zus¨
atzlich zu diesen Sichten ein Farb-
und Formkonzept zur Darstellung von und Navigation in komplexen Produktontologien entwor-
fen1[Hau15] (Grafiken zum Usability-Konzept befinden sich im Anhang G).
Teile dieser Konzepte wurden im PROCEED-Plugin f¨
ur Prot´eg´e umgesetzt. Abbildung 9.9 zegt die
Ober߬
ache, in der eine lokale und globale Produktontologie sowie Schemakonzept-Attributregeln
und -aktionen modelliert werden k¨
onnen. Auf der linken Seite ist eine lokale Produktontolo-
gie mit entsprechenden Schemakonzepten und Instanzen illustiert. F¨
ur jede Produktdatenin-
tegrationsebene existieren zwei Listen zur Darstellung von Schemakonzepten und Instanzen.
Je nachdem, welches Element (Schemakonzept, Attribut, Instanz, Attributwert) in den Listen
ausgew¨
ahlt wird, sind bestimmte ¨
Anderungsoperationen (als Buttons dargestellt) ausf¨
uhrbar.
Analog zu Schemakonzepten und Instanzen werden auch die Schemakonzept-Attributregeln und
-aktionen den Integrationsebenen entsprechend angeordnet (siehe Abbildung 9.9 Mitte).
Abbildung 9.9.: Ober߬
ache des PROCEED-Plugins f¨
ur Prot´eg´e
Abbildung 9.10 zeigt die Ober߬
ache f¨
ur die Ausf¨
uhrung der Abfragen zur Realisierung der An-
wendungsf¨
alle, die mit Hilfe der integrierten Produktdaten realisiert werden sollen (vgl. Defini-
tion 8). Auf der linken Seite ist eine Liste mit definierten SPARQL-Abfragen dargestellt. Durch
Auswahl aus der Liste wird die hinterlegte SPARQL-Abfrage in den Editor des SPARQL-Plugins
1Ein ¨
ahnlicher Ansatz wurde im Projekt niPRO f¨
ur die Visualisierung von und Navigation in Prozess-
Repositorien- und Ontologien realisiert [HMR12, MMR12, HMMR14].
226
9.3. Realisierung der L¨
osungskonzepte
geladen. Da die Integrationsqualit¨
atsmetriken auf SPARQL basieren, kann der Abfrageeditor
auch dazu verwendet werden, die einzelnen Metriken zu bestimmen.
Abbildung 9.10.: Ober߬
ache zur Ausf¨
uhrung von Abfragen
227
10. Fallstudie
Zus¨
atzlich zur skizzierten prototypischen Implementierung (vgl. Kapitel 9) wurde des PROCEED-
Rahmenwerkes in Fallstudien in der Automobilindustrie evaluiert. Dieses Kapitel stellt eine
solche Fallstudie vor und erl¨
autert, welche Erkenntnisse sich aus der Anwendung des PROCEED-
Rahmenwerkes ableiten lassen. F¨
ur jedes Integrationsszenario werden zun¨
achst die Notwendig-
keit zur Integration von Produktdaten motiviert und die zu realisierenden Anwendungsf¨
alle
beschrieben. Anschließend werden die zu integrierenden Informationssysteme und deren konzep-
tionelle Datenmodelle erl¨
autert. Schließlich wird eine L¨
osung zur Integration der Informations-
systeme mit Hilfe des PROCEED-Rahmenwerkes detailliert.
10.1. Abgleich von St¨ucklisten mit PROCEED
10.1.1. Motivation
Wie erl¨
autert, besteht ein Produkt aus einer Vielzahl von Komponenten, deren Beziehungen
zueinander eine hierarchische Produktstruktur bilden. Die Verwaltung dieser Komponenten und
ihrer Beziehungen (d.h. der Produktstruktur) erfolgt mit Hilfe von PDMS. Die konstruktive Sicht
auf ein Produkt wird als St¨
uckliste bezeichnet und durch das Traversieren der Produktstruktur
von oben nach unten erzeugt.
Entwickelt nun ein Hersteller ein Produkt in Kooperation mit einem anderen Hersteller, m¨
ussen
die Produktdaten beider Hersteller in regelm¨
aßigen Abst¨
anden abgeglichen werden. Typischer-
weise verwaltet jeder Hersteller ein eigenes PDMS f¨
ur die Dokumentation. Gleiches gilt, wenn ein-
zelne Aspekte der Entwicklung (z.B. Konstruktion, Software-Entwicklung) in unterschiedlichen
Informationssystemen dokumentiert werden. Beispielsweise werden w¨
ahrend der Entwicklung
von E/E-Komponenten (z.B. Steuerger¨
ate, Sensoren, Aktuatoren) geometrische Modelle und
deren Informationen zu Hardware und Software meist in zwei separaten PDMS verwaltet. Diese
Informationen werden von unterschiedlichen Personengruppen dokumentiert. Folglich kann es
zu Inkonsistenzen in der Dokumentation von E/E-Komponenten in den beiden Systemen kom-
men. So k¨
onnen in einen PDMS geometrische Modelle f¨
ur E/E-Komponenten vorhanden seien,
entsprechende Informationen zu Hard- und Software im anderen PDMS fehlen und umgekehrt.
10.1.2. Anwendungsf¨alle
Folgende Anwendungsf¨
alle sollen mit Hilfe der integrierten Produktdaten der beiden Informati-
onssysteme realisiert werden:
•Anwendungsfall 1: Ausgehend von zwei PDMS sollen die Mengen der dokumentierten E/E-
Komponenten f¨
ur ein Fahrzeug abgeglichen werden. Dabei sollen diejenigen Komponenten
ermittelt werden, die nur in einem der beiden Systeme dokumentiert sind.
•Anwendungsfall 2: Es sollen diejenigen E/E-Komponenten ermittelt werden, f¨
ur die keine
Geometriemodelle oder Software-Artefakte dokumentiert sind.
229
10. Fallstudie
3'0 ((3'0
%DXWHLOJHRPHWULHQ
PHFKDQLVFKHXQG((.RPSRQHQWHQ
8PIDQJ
$EOHLWXQJYRQ.RQILJXUDWLRQHQ
GXUFK&RGH5HJHOQ
:HQQNHLQH3KDVHGHILQLHUWGDQQ
OHW]WHJOWLJH9HUVLRQ
NHLQHH[SOL]LWH%QGHOXQJYRQ
9HUVLRQHQ
+DUGZDUHLQIRUPDWLRQHQ
6WHFNHU3LQV6RIWZDUH
((.RPSRQHQWHQ
8PIDQJ
%QGHOXQJYRQ9HUVLRQHQLQ
.RQILJXUDWLRQHQ
%UDQFKLQJGHU9HUVLRQHQ
NHLQHH[SOL]LWH9DULDELOLWlW
$
%
&
Z
[
3URGXNW
\
]
$
$
%
&
&
3URGXNWVWUXNWXU %DXWHLOYHUVLRQHQ 3URGXNWVWUXNWXU
Z
Z
Z
[
[
\
]
9HUVLRQVUDXP
9RUJlQJHU
3URGXNW
3KDVH
3KDVH
3KDVH
3KDVH
3KDVH
&RGH
&RGH
$Z%DXWHLO
.RQILJXUDWLRQ
&
&
/HJHQGH
,QIRUPDWLRQVV\VWHP$
$QZHQGXQJVIlOOH
.RQVLVWHQ]YRQ
((.RPSRQHQWHQ
0HQJHQYHUJOHLFKYRQ((.RPSRQHQWHQ]ZLVFKHQEHLGHQ,QIRUPDWLRQVV\VWHPHQ
:HOFKH.RPSRQHQWHQDXVGHPHLQHQ6\VWHPIHKOHQLPDQGHUHQXQGXPJHNHKUW"
:RJLEWHV:LGHUVSUFKHLQGRNXPHQWLHUWHQ$WWULEXWHQ"
:HOFKH%DXWHLOYDULDQWHQXQGYHUVLRQHQDXVEHLGHQ6\VWHPJHK|UHQ]XVDPPHQ"
$ Z%DXWHLOYHUVLRQ
,QIRUPDWLRQVV\VWHP%
'DWHQPRGHOO 'DWHQPRGHOO
Abbildung 10.1.: Integrationsszenario - Konsistenzcheck zweier PDMS ¨
uber St¨
ucklisten
•Anwendungsfall 3: Es sollen diejenigen E/E-Komponenten ermittelt werden, die sich bzgl.
der Anzahl ihrer Varianten unterscheiden. Obwohl beide Systeme unterschiedliche Mecha-
nismen zur Dokumentation von Bauteilvarianten und -versionen verwenden k¨
onnen, kann
die Auflistung von zusammengeh¨
origen Varianten und Versionen aus beiden Systemen
Hinweise auf m¨
ogliche Inkonsistenzen geben.
10.1.3. Systeme
Abbildung 10.1 illustriert die konzeptionellen Datenmodelle der beiden zu integrierenden In-
formationssysteme. W¨
ahrend Informationssystem A die Geometriedaten von sowohl mechani-
sche als auch E/E-Bauteilen speichert, werden im Informationssystem B detaillierte Informatio-
nen zur Hard- und Software von E/E-Komponenten dokumentiert. In beiden Systemen werden
die E/E-Komponenten mittels unterschiedlicher Strukturen und Namenskonventionen dokumen-
230
10.1. Abgleich von St¨
ucklisten mit PROCEED
tiert.
•Im Informationssystem A werden Bauteile hierarchisch gespeichert. Dabei kommt es vor,
dass Bauteile wiederum hierarchisch durch weitere Bauteile spezifiziert sind.
•Das Informationssystem B hingegen speichert die E/E-Komponenten in einer Liste.
Beide Systeme verwenden unterschiedliche Konventionen zur Dokumentation von Variabilit¨
at
und Versionierung:
•Im Informationssystem A sind Bauteile mit Code-Regeln versehen, mit deren Hilfe sich
Produkte konfigurieren lassen (Variabilit¨
at). Das heißt, aus einer Produktstruktur mit al-
len Bauteilen l¨
asst sich ein konkretes Produkt ableiten. Alle Bauteile lassen sich versionie-
ren, wodurch Versionsb¨
aume entstehen k¨
onnen. Neben den Versionen lassen sich Bauteile
zus¨
atzlich zu projektspezifischen Meilensteinen zuordnen.
•Informationssystem B hingegen bietet keine explizite Unterst¨
utzung zur Dokumentation
von Variabilit¨
at. Versionen von E/E-Komponenten werden zu Konfigurationen geb¨
undelt,
ohne dabei auf ein konkretes Produkt Bezug zu nehmen. Auch im Informationssystem B
k¨
onnen Versionsb¨
aume einzelner E/E-Komponenten entstehen.
Einzige Gemeinsamkeit beider Systeme ist eine Zuordnung der Artefakte zu globalen Bauteil-
nummern. In der Praxis unterscheidet sich die Qualit¨
at der Dokumentation dieser Bauteilnum-
mern in beiden Systemen. W¨
ahrend in Informationssystem A die Zuordnung von Bauteilen
zu Bauteilnummern sehr gut dokumentiert ist, fehlen diese Informationen im Informationssys-
tem B f¨
ur fr¨
uhe Phasen der Produktentwicklung. H¨
aufig werden bei der Entwicklung neuer
E/E-Komponenten bestehende Informationen und Attribute vorheriger Komponentenversionen
kopiert und erst im weiteren Verlauf der Entwicklung nachdokumentiert bzw. angepasst. So
kann es vorkommen, dass f¨
ur E/E-Komponenten im Informationssystem B Bauteilnummern
dokumentiert sind, die nicht g¨
ultig sind bzw. noch nicht angepasst wurden.
Beide Systeme haben unterschiedliche Mengenger¨
uste: W¨
ahrend Informationssystem A sowohl
mechanische Bauteile als auch E/E-Bauteile verwaltet, fallen pro Produkt (in diesem Fall Fahr-
zeuge) bis zu Zehntausend Bauteile an. Durch die Variabilit¨
at und Versionierung ergeben sich
somit mehrere Zehntausende Artefakte, die integriert werden m¨
ussen. Auf der anderen Seite
verwaltet Informationssystem B nur E/E-Komponenten. Pro Fahrzeug ergeben sich hier bis zu
150 Bauteile. Bezieht man alle Versionen mit ein, sind aus diesem System mehrere Tausend
Artefakte pro Fahrzeug zu integrieren.
10.1.4. Integration mit Hilfe des PROCEED-Rahmenwerkes
Um die beiden Informationssysteme mit Hilfe des PROCEED-Rahmenwerkes zu integrieren und
die geschilderten Anwendungsf¨
alle zu realisieren, sind folgende Schritte notwendig:
1. Ausw¨
ahlen einer Integrationsmethodik
2. Definition einer globalen Produktontologie
3. Definition einer lokaler Masterproduktontologie
231
10. Fallstudie
4. Definition einer lokalen Produktontologie inklusive Abbildung in die globale Produkton-
tologie
5. Spezifikation von Integrationsqualit¨
ats-Metriken
6. Formulierung von Abfragen f¨
ur Anwendungsf¨
alle
1. Integrationsmethodik: Da nur zwei Informationssysteme zu integrieren sind, f¨
ur die bisher
noch keine lokalen Produktontologien existieren, wird als Integrationsmethodik eine globale
Produktontologie Top-Down definiert.
2. Globale Produktontologie: Die globale Produktontologie besteht aus jeweils einem Schema-
konzept pro Produktdatenintegrationsebene und orientiert sich am lokalen Informationssystem
A: Ein Produkt (Product) besteht aus mehreren Bauteilen (Component), welche unterschiedliche
Varianten (Component Variant) besitzen k¨
onnen. F¨
ur jede Bauteilvariante werden verschiedene
Entwicklungsst¨
ande dokumentiert (Component Version). Eine Bauteilvariante l¨
asst sich durch
eine eindeutige Identifikation (Code) beschreiben. Jeder Entwicklungsstand einer Bauteilvarian-
te ist ebenfalls durch eine eindeutige Identifikation (PartId) sowie einer fortlaufenden Nummer
(Version Id) gekennzeichnet. Ein Entwicklungsstand der globalen Produktontologie umfasst
sowohl eine geometrische Zeichnung (Geometry) als auch einen Softwarestand (Software). F¨
ur
Component Variant wird der Variabilit¨
atstyp 2 festgelegt (vgl. Abschnitt 6.2.1), d.h. f¨
ur jede
Bauteilvariante wird eine eigene, explizite Instanz in der globalen Produktontologie dokumen-
tiert. Die Entwicklungsst¨
ande der Bauteilvarianten werden kontinuierlich dokumentiert.
3. Lokale Masterproduktontologie: Da die Datenqualit¨
at der dokumentierten Komponenten,
inklusive ihrer eindeutigen Identifikationsnummern, im lokalen Informationssystem Asehr hoch
ist, wird Informationssystem Aauch zur Definition einer Masterproduktontologie verwendet. In
Abbildung 10.2 sind die entsprechende lokale Masterproduktontologie Msowie Abbildungen in
die globale Produktontologie Gillustriert.
4. Lokale Produktontologie: Entsprechend wird f¨
ur das lokale Informationssystem Beine lo-
kale Produktontologie definiert. Abbildung 10.3 illustriert die lokale Produktontologie Lf¨
ur das
lokale Informationssystem B.
Ein Produkt (Product) setzt sich auf mehreren E/E-Komponenten (EE Component) zusammen.
F¨
ur eine E/E-Komponente k¨
onnen mehrere Varianten (EE Component Variant) vorhanden sein,
die wiederum in unterschiedlichen Versionen (EE Component Version) existieren k¨
onnen. Jedes
dieser Schemakonzepte besitzt als Attribut einen Namen (Name), f¨
ur Varianten existiert ein Attri-
but, das einen Variantenbezeichner (Variant)enth
¨
alt; analog beschreibt das Attribut Version
Id eine Versionsnummer. Schließlich ist die Referenz der Software der E/E-Komponente in der
lokalen Produktontologie modelliert (Reference).
5. Integrationsqualit¨atsmetriken: Da nur eine lokale Produktontologie vorhanden ist, ist zur
Realisierung von Anwendungsfall 1 nur die lokale und globale Instanzvollst¨
andigkeit notwendig
(siehe Kapitel 7).
232
10.1. Abgleich von St¨
ucklisten mit PROCEED
Abbildung 10.2.: Produktontologien des Integrationsszenarios
6. Abfragen Im folgenden Abschnitt werden die notwendigen Abfragen an die globale Produk-
tontologie zur Realisierung der drei Anwendungsf¨
alle beschreiben.
Listing 10.1 illustriert die SPARQL-Abfragen zur Realisierung des Anwendungsfalls 1.
1PREFIXmo:<http://www.uni´ulm.de/proceed/metaontology#>
2PREFIXgpo:<http://www.uni´ulm.de/proceed/gpo#>
3 PREFIX lpo1: <http://www.uni´ulm.de/proceed/lpo1#>
4 PREFIX pom1: <http://www.uni´ulm.de/proceed/pom1#>
5 SELECT DISTINCT ?component
6WHERE{
7 ?component rdf:type gpo:Component SC .
8 ?component gpo:ComponentType ”ECU”ˆˆxsd:string .
9 FILTER NOT EXISTS {
10 ?component pom:CorrespondesToSCAR ?lpo Ind .
11 ?lpo Ind rdf:type lpo1:LocalSchemaConcept .
12 }
13 }
Listing 10.1: SPARQL-Query f¨
ur den Anwendungsfall 1
233
10. Fallstudie
Abbildung 10.3.: Lokale Produktontologie LPO
In Listing 10.2 ist die SPARQL-Abfrage f¨
ur den Anwendungsfall 2 spezifiziert.
1PREFIXgpo:<http://www.uni´ulm.de/proceed/gpo#>
2 SELECT DISTINCT ?componentVersion
3WHERE{
4 ?componentVersion rdf:type gpo:ComponentVersion SC .
5 FILTER (not exists {?componentVersion gpo:Geometry Attr ?value }||
6notexists{?componentVersion gpo:Software Attr ?value })
7}
8}
Listing 10.2: SPARQL-Query f¨
ur den Anwendungsfall 2
Listing 10.3 beschreibt die SPARQL-Abfrage f¨
ur den Anwendungsfall 3. Es werden zun¨
achst
diejenigen lokalen und globalen Instanzen ermittelt, die zueinander korrespondieren (Zeile 6).
F¨
ur die lokale Instanz werden die Anzahl der zugeh¨
origen Instanzen auf der Varianten-Ebene
ermittelt (Zeilen 7 bis 13). Analog werden die globalen Instanzen bestimmt (Zeilen 14 bis 20).
Es werden alle Paare von lokalen und globalen Instanzen herausgefiltert, f¨
ur die die Anzahl der
Varianten gleich ist (siehe Zeile 21).
234
10.1. Abgleich von St¨
ucklisten mit PROCEED
1PREFIXgpo:<http://www.uni´ulm.de/proceed/gpo#>
2 SELECT DISTINCT ?localInd ?globalInd
3WHERE{
4 ?localInd rdf:type mo:LocalObjectLayer .
5 ?globalInd rdf:type mo:GlobalObjectLayer .
6 ?localInd pom1:correspondesTo ?globalInd .
7{
8 SELECT (COUNT (?var) as ?localVarCnt)
9WHERE{
10 ?localInd mo:isAbove ?var
11 }
12 GROUP BY ?var
13 }
14 {
15 SELECT (COUNT (?var) as ?globalVarCnt)
16 WHERE {
17 ?globalInd mo:isAbove ?var
18 }
19 GROUP BY ?var
20 }
21 FILTER (?localVarCnt != ?globalVarCnt)
22 }
Listing 10.3: SPARQL-Query f¨
ur den Anwendungsfall 3
10.1.5. Erkenntnisse
Die Fallstudie zeigt die Integration eines h¨
aufigen Szenarios in der Produktentwicklung. Da beide
Informationssysteme sehr heterogene Datenmodelle besitzen, ist zun¨
achst ein initialer Aufwand
f¨
ur die Modellierung der Produktontologien notwendig. Die Auswahl von Variabilit¨
ats- und Ver-
sionierungsmechanismus muss sorgsam gew¨
ahlt werden, da eine sp¨
atere ¨
Anderung die Anpassung
von bereits integrierten Instanzen in der globalen Produktontologie nach sich ziehen. Vor allem
die Nutzung der Anwendungsf¨
alle ¨
uber einen l¨
angeren Zeitraum der Produktentwicklung, bei
dem sich Produktdaten kontinuierlich ¨
andern, bietet das PROCEED-Rahmenwerk den Vorteil,
dass diese ¨
Anderungen sehr einfach ¨
uber die diskutierten ¨
Anderungsoperationen (vgl. Kapitel
8) in der globalen Produktontologie realisiert werden k¨
onnen.
Außerdem zeigt sich an diesem Beispiel, dass bereits mit der Integration von zwei Informati-
onssystemen eine Vielzahl komplexer Anwendungsf¨
alle realisiert werden kann. In der Praxis ist
es sinnvoll mit der Integration weniger Informationssysteme zu beginnen. Der initiale Modellie-
rungsaufwand amortisiert sich mit zunehmender Anzahl zu integrierender Informationssysteme.
235
Teil IV
Zusammenfassung
11. Zusammenfassung und Ausblick
Die Integration von Produktdaten ist essentiell, um die Prozesse rund um die Produktentwick-
lung bestm¨
oglichzuunterst
¨
utzen. Die Beseitigung von Fehlern in sp¨
ateren Entwicklungspha-
sen ist mit erheblichen Kosten verbunden. Deshalb ist besonders in fr¨
uhen Phasen der Pro-
duktentwicklung der regelm¨
aßige Abgleich der Entwicklungsst¨
ande,d.h.die¨
Uberpr¨
ufung der
Vollst¨
andigkeit und Konsistenz von Produktdaten, notwendig. Hierzu bedarf es einer Integrati-
on autonomer, heterogener Informationssysteme.
Concurrent Engineering und die verschiedenen Anforderungen und Aufgaben der Produktent-
wicklung f¨
uhren zur Verwendung unterschiedlicher Methoden um Produktvariabilit¨
at und -
versionierung zu dokumentieren. Existierende Konzepte und Rahmenwerke fokussieren entweder
auf Schema- oder Instanzintegration, und bieten keine ausreichende Unterst¨
utzung, um verschie-
denen Konzepte f¨
ur Produktvariabilit¨
at und -versionierung angemessen bei der Produktdaten-
integration zu ber¨
ucksichtigen.
11.1. Zusammenfassung
Die vorliegende Arbeit liefert mit PROCEED ein Rahmenwerk zur Integration komplexer Pro-
duktdaten, das den gesamten Integrationslebenszyklus unterst¨
utzt. Von der initialen Integration,
¨
uber die Steuerung und ¨
Uberwachung des Integrationsprozesses hin zur Evolution integrierter
Produktdaten:
•Umgang mit Heterogenit¨
at durch Abstraktion: Durch die Einf¨
uhrung von Pro-
duktontologien kann der Umgang mit technischer und semantischer Heterogenit¨
at der zu
integrierenden Produktdaten erheblich vereinfacht werden. Gleichzeitig wird durch die ein-
heitliche Strukturierung innerhalb der Produktontologien in vier Integrationsebenen der
Aufwand einer automatischen Auswertung von Integrationsregeln verringert. Die Doku-
mentation von implizitem Wissen in den Produktontologien kann zudem den manuellen
Integrationsaufwand w¨
ahrend der Schema- und Instanzintegration reduzieren.
•Definition von Abbildungsregeln und -aktionen: Neben den Abbildungsregeln zwi-
schen Produktontologien, die eine automatische Bestimmung von Korrespondenzen zwi-
schen Instanzen erlaubt, k¨
onnen mit Hilfe von Integrationsaktionen eine integrierte Sicht
von Produktdaten geschaffen werden.
•Automatische Bestimmung von Korrespondenzen: Durch die Definition von Ab-
bildungsregeln zwischen lokaler und globaler Produktontologie l¨
asst sich die Ermittlung
korrespondierender Instanzen automatisieren.
•Steuerung und ¨
Uberwachung des Integrationsprozesses: Die Definition von Qua-
lit¨
atsmetriken f¨
ur die Integration lokaler Produktontologien in eine globale Produktonto-
logie erlauben es, den Integrationsprozess zu steuern und ¨
uberwachen.
239
11. Zusammenfassung und Ausblick
•Definition von ¨
Anderungsoperationen: Durch die Bereitstellung von ¨
Anderungsoper-
ationen, sowohl f¨
ur Schemakonzepte als auch Instanzen, ist es m¨
oglich, eine bereits erstellte
globale Produktontologie stets mit dem Entwicklungstand der lokalen Produktontologien
zu synchronisieren. Dadurch kann die Evolution von integrierten Produktdaten bewerk-
stelligt werden.
•Dom¨
anenunabh¨
angiger Ansatz: Produktdatenintegration und der Umgang mit der
Variabilit¨
at und Versionierung von Produktdaten sind keine Konzepte, die nur in der
Automobilindustrie anzutreffen sind. Das entwickelte Konzept der Produktontologien ori-
entiert sich an den Problemstellungen, die auch von g¨
angigen Austauschstandards (z.B.
STEP) adressiert werden. Genau wie STEP ist PROCEED ein Ansatz, der auf Produktdaten
im Allgemeinen fokussiert und folglich in anderen Dom¨
anen, etwa der Luftfahrtindustrie
oder dem Schiffbau Anwendung finden kann.
•Konzepte zur Benutzerunterst¨
utzung: Neben der technischen L¨
osung wurden auch
Konzepte durch Unterst¨
utzung von Endanwendern betrachtet.
11.2. Ausblick
¨
Uber die diskutierten Aspekte der vorliegenden Arbeit hinaus gibt es weitere Themenbereiche,
die Gegenstand weiterer Untersuchungen seien k¨
onnen:
•Die Integration im PROCEED-Rahmenwerk fokussiert auf einzelne Schemakonzepte, eine
Integration mehrerer Schemakonzepte sowie Beziehungen zwischen diesen werden nicht
ber¨
ucksichtigt. Neben einzelnen Aspekten von Produktdaten ist die Integration von Be-
ziehungen zwischen Produktdaten sinnvoller Gegenstand weiterer Untersuchungen. Die
Ber¨
ucksichtigung dieser Beziehungen bietet zudem vielversprechende Perspektiven hin-
sichtlich der Koordination der zugeh¨
origen Teilentwicklungensprozesse (f¨
ur entsprechende
Arbeiten siehe [RR06, MRH07, KR09, SKAR17, SAR18]).
•Ziel der vorliegenden Arbeit ist die Unterst¨
utzung von lesenden Anwendungsf¨
allen autono-
mer, heterogener Produktdaten. Werden Inkonsistenzen, unvollst¨
andige Attribute oder feh-
lende Instanzen in der globalen Produktontologie identifiziert, kann eine Behebung nur in
den entsprechenden lokalen Informationssystemen erfolgen. Die M¨
oglichkeit, ¨
Anderungen
in der globalen Produktontologie vorzunehmen, die anschließend in die einzelnen lokalen
Informationssysteme propagiert werden, kann den Prozess von ¨
Anderungen beschleunigen.
•Die Arbeit hat verschiedene Teilprozesse der Produktdatenintegration und -evolution ex-
plizit modelliert. Hier bietet eine Automation dieser Prozesse mittels Prozess-Management-
Technologien [MRB08] vielversprechende Perspektiven, etwa in Bezug auf Koordinati-
on [MWR08], Flexibilit¨
at [Rei00, RRMD09, BBTR14, BBTR15], Variabilit¨
at [LRW09,
ATW`15], Effektivit¨
at [LR16, LR12], Mobilit¨
at [PTKR10, PTR10] und Compliance
[KRK17, KR17].
•Schließlich sollten weitere Fallstudien vorgenommen werden, um Erfahrungswerte f¨
ur die
Auswahl sowohl der zu verwendenden Integrationsmethodik als auch die Festlegung von
Soll-Werten f¨
ur die Steuerung des Integrationsprozesses zu ermitteln.
240
Literaturverzeichnis
[Ack89] R.L. Ackoff. From Data to Wisdom. Journal of Applied Systems Analysis, 16(1):3–9,
1989.
[AKRS06] C. Amelunxen, A. K¨
onigs, T. R¨
otschke, and A. Sch¨
urr. MOFLON: A Standard-
Compliant Metamodeling Framework with Graph Transformations. In European
Conference on Model Driven Architecture-Foundations and Applications (ECMDA-
FA 2006), pages 361–375. Springer, 2006.
[All03] OSGi Alliance. OSGi Service Platform, Release 3. IOS Press, Inc., 2003.
[AT00] R. Anderl and D. Trippner. STEP – STandard for the Exchange of Product Mo-
del Data: Eine Einf¨
uhrung in die Entwicklung, Implementierung und industrielle
Nutzung der Normenreihe ISO 10303 (STEP). B.G. Teubner Stuttgart, 2000.
[ATW`15] C. Ayora, V. Torres, B. Weber, M. Reichert, and V. Pelechano. VIVACE: A Frame-
work for the Systematic Evaluation of Variability Support in Process-Aware Infor-
mation Systems. Information and Software Technology, 57:248–276, January 2015.
[BBK`13] C.Ballard,M.Bhide,H.Kache,B.Kitzberger,B.Porst,Y.H.Sheng,H.C.Smith,
and IBM Redbooks. IBM Information Server: Integration and Governance for
Emerging Data Warehouse Demands. IBM Redbooks. IBM Redbooks, 2013.
[BBLP08] D. Beckett, T. Berners-Lee, and E. Prud’hommeaux. Turtle-terse RDF triple lan-
guage. W3C Team Submission, 14(7), 2008.
[BBR11] S. Buchwald, T. Bauer, and M. Reichert. Bridging the Gap Between Business Pro-
cess Models and Service Composition Specifications. In Service Life Cycle Tools and
Technologies: Methods, Trends and Advances, pages 124–153. Idea Group Referenc,
November 2011.
[BBTR14] T. Bauer, S. Buchwald, J. Tiedeken, and M. Reichert. Konzeption eines SOA-
Repository mit Analysef¨
ahigkeiten. In Proceedings Informatik 2014, number P-232
in Lecture Notes in Informatics (LNI), pages 1565–1576. Koellen-Verlag, September
2014.
[BBTR15] T. Bauer, S. Buchwald, J. Tiedeken, and M. Reichert. A SOA Repository with
Advanced Analysis Capabilities - Improving the Maintenance and Flexibility of
Service-Oriented Applications. In 17th International Conference on Enterprise In-
formation Systems (ICEIS 2015), pages 238–248, April 2015.
[Bec09] S. Bechhofer. OWL: Web Ontology Language. In Encyclopedia of Database Systems,
pages 2008–2009. Springer, 2009.
241
Literaturverzeichnis
[Bel02] Z. Bellahsene. Schema Evolution in Data Warehouses. Knowledge and Information
Systems, 4(3):283–304, 2002.
[Ben09] P.R. Benson. ISO 8000 Data Quality: The fundamentals, part 1. Real-World Deci-
sion Support (RWDS) Journal, 3(4), 2009.
[Beu02] T. Beuter. Workflow-Management f¨
ur Produktentwicklungsprozesse. PhD thesis,
Universit¨
at Ulm, 2002.
[BG00] D. Brickley and R. V. Guha. Resource Description Framework (RDF) Schema
Specification 1.0: W3C Candidate Recommendation. Technical report, W3C, Cam-
bridge, MA, 2000.
[BGN`04] S. Burmester, H. Giese, J. Niere, M. Tichy, J.P. Wadsack, R. Wagner, L. Wendehals,
and A. Z¨
undorf. Tool integration at the meta-model level: the Fujaba approach. In-
ternational Journal on Software Tools for Technology Transfer, 6(3):203–218, 2004.
[BHR05] U. Bestfleisch, J. Herbst, and M. Reichert. Requirements for the Workflow-based
Support of Release Management Processes in the Automotive Sector. In 12th Eu-
ropean Concurrent Engineering Conference (ECEC’05), pages 130–134, April 2005.
[BLL10] J. Blechinger, F. Lauterwald, and R. Lenz. Supporting the Production of High-
Quality Data in Concurrent Plant Engineering Using a MetaDataRepository. In
AMCIS, page 95, 2010.
[BN09] J. Bleiholder and F. Naumann. Data Fusion. ACM Computing Surveys, 41(1):1,
2009.
[Bob08] R. Bobrik. Konfigurierbare Visualisierung komplexer Prozessmodelle. PhD thesis,
Universit¨
at Ulm, 2008.
[BR05] M. Broy and A. Rausch. Das neue V-Modell XT - Ein anpassbares Vorgehensmodell
f¨
ur Software und System Engineering. Informatik-Spektrum, 28(3):220–229, 2005.
[Bra07] S. Bratt. Semantic Web and Other Technologies to Watch. Talks at W3C, January,
2007.
[BRB05] R. Bobrik, M. Reichert, and T. Bauer. Requirements for the Visualization of
System-Spanning Business Processes. In 1st Int’l Workshop on Business Pro-
cess Monitoring and Performance Management (BPMPM’05) in conjunction with
(DEXA’05), pages 948–954. IEEE Computer Society Press, August 2005.
[BRB06] R. Bobrik, M. Reichert, and T. Bauer. Proviado - Personalized and Configurable
Visualizations of Business Processes. In 7th Int’l Conf on Electronic Commerce and
Web Technologies (EC-WEB’06), number 4082 in LNCS, pages 61–71. Springer,
September 2006.
[BS06] C. Batini and M. Scannapieco. Data Quality - Concepts, Methodologies and Tech-
niques, 2006.
242
Literaturverzeichnis
[CAD03] I. Crnkovic, U. Asklund, and A.P. Dahlqvist. Implementing and Integrating Product
Data Management and Software Configuration Management. Artech House, 2003.
[CBK13] R. Capilla, J. Bosch, and K.-C. Kang. Systems and Software Variability Manage-
ment - Concepts, Tools and Experiences. Springer, 2013.
[CD97] S. Chaudhuri and U. Dayal. An Overview of Data Warehousing and OLAP Tech-
nology. ACM SIGMOD Record, 26(1):65–74, 1997.
[CGR`12] K. Czarnecki, P. Gr¨
unbacher,R.Rabiser,K.Schmid,andA.Wasowski. Cool
Features and Tough Decisions: A Comparison of Variability Modeling Approa-
ches. In Proceedings of the Sixth International Workshop on Variability Modeling
of Software-Intensive Systems (VaMoS’12), pages 173–182. ACM, 2012.
[CKR14] C.M. Chiao, V. K¨
unzle, and M. Reichert. Towards Schema Evolution in Object-
aware Process Management Systems. In International Workshop on the Evolution
of Information Systems and their Design Methods (EMISA 2014), number P-234
in Lecture Notes in Informatics (LNI), pages 101–115. Koellen-Verlag, September
2014.
[Col97] R.M. Colomb. Impact of Semantic Heterogeneity on Federating Databases. The
Computer Journal, 40(5):235–244, 1997.
[Con97] S. Conrad. F¨
oderierte Datenbanksysteme: Konzepte der Datenintegration.Springer-
Verlag, 1997.
[Con12] Roland Berger Strategy Consultants. http://www.rolandberger.de/media/pdf/
Roland_Berger_Master_product_complexity_20121108.pdf, November 2012.
[Coo90] R.G. Cooper. Stage-Gate Systems: A New Tool for Managing New Products. Busi-
ness Horizons, 33(3):44–54, 1990.
[CRS`13] S.K. Chandrasegaran, K. Ramani, R.D. Sriram, I. Horv´ath, A. Bernard, R.F. Harik,
and W. Gao. The evolution, challenges, and future of knowledge representation in
product design systems. Computer-Aided Design, 45(2):204–228, 2013.
[CW98] R. Conradi and B. Westfechtel. Version Models for Software Configuration Mana-
gement. ACM Computing Surveys, 30(2):232–282, 1998.
[DHI12] A. Doan, A. Halevy, and Z. Ives. Principles of Data Integration. Elsevier, 2012.
[DSDH08] A. Das Sarma, X. Dong, and A. Halevy. Bootstrapping Pay-As-You-Go Data In-
tegration Systems. In Proceedings of the 2008 ACM SIGMOD international confe-
rence on Management of data (SIGMOD ’08), pages 861–874. ACM, 2008.
[EIA98] EIA-649 - National Consensus Standard for Configuration Management. Norm,
ANSI, 1430 Broadway, New York, NY 10018, USA, 1998.
[EN09] M. Eigner and M.F. Nem. Common Versioning of Product Data and Engineering
Processes. In Proceedings of the 2nd International Conference on Research into
Design (ICORD 09), 2009.
243
Literaturverzeichnis
[Faw06] T. Fawcett. An introduction to ROC analysis. Pattern Recognition Letters,
27(8):861–874, 2006.
[GMF`03] J.H. Gennari, M.A. Musen, R.W. Fergerson, W.E. Grosso, M. Crub´ezy, H. Eriksson,
N.F. Noy, and S.W. Tu. The evolution of Prot´eg´e: an environment for knowledge-
based systems development. International Journal of Human-Computer Studies,
58(1):89–123, 2003.
[GOP02] M.P. Gallaher, A.C. O’Connor, and T. Phelps. Economic Impact Assessment of the
International Standard for the Exchange of Product Model Data (step) in Trans-
portation Equipment Industries. NIST planning report, pages 02–5, 2002.
[GOR12] G. Grambow, R. Oberhauser, and M. Reichert. Towards Automated Process Assess-
ment in Software Engineering. In 7th Int’l Conf on Software Engineering Advances
(ICSEA’12), pages 289–295, November 2012.
[Gra16] G. Grambow. Context-aware Process Management for the Software Engineering
Domain. PhD thesis, Ulm University, July 2016.
[Gru93] T. R. Gruber. A Translation Approach to Portable Ontology Specifications. Know-
ledge Acquisition, 5(2):199–220, 1993.
[Hal01] A.Y. Halevy. Answering queries using views: A survey. The VLDB Journal,
10(4):270–294, 2001.
[Hal10] A. Hallerbach. Management von Prozessvarianten. PhD thesis, Universit¨
at Ulm,
2010.
[Hau15] S. Hausladen. Visualisierung und Navigation komplexer Produktdaten. Bachelor
thesis, Universit¨
at Ulm, 2015.
[HB11] M. Horridge and S. Bechhofer. The OWL API: A Java API for OWL ontologies.
Semantic Web, 2(1):11–21, 2011.
[HBR08] A. Hallerbach, T Bauer, and M. Reichert. Context-based Configuration of Pro-
cess Variants. In 3rd International Workshop on Technologies for Context-Aware
Business Process Management (TCoB 2008), pages 31–40, June 2008.
[HBR09] A. Hallerbach, T. Bauer, and M. Reichert. Guaranteeing Soundness of Configurable
Process Variants in Provop. In 11th IEEE Conference on Commerce and Enterprise
Computing (CEC’09), pages 98–105. IEEE Computer Society Press, July 2009.
[HBR10] A. Hallerbach, T. Bauer, and M. Reichert. Capturing Variability in Business Process
Models: The Provop Approach. Journal of Software: Evolution and Process, 22(6-
7):519–546, 2010.
[Hei95] S. Heiler. Semantic Interoperability. ACM Computing Surveys, 27(2):271–273, 1995.
[HMMR14] M. Hipp, B. Michelberger, B. Mutschler, and M. Reichert. Navigating in Process
Model Repositories and Enterprise Process Information. In IEEE 8th International
Conference on Research Challenges in Information Science (RCIS 2014), pages
1–12. IEEE Computer Society Press, May 2014.
244
Literaturverzeichnis
[HMN15] H.R. Hansen, J. Mendling, and G. Neumann. Wirtschaftsinformatik. Walter de
Gruyter GmbH & Co KG, 2015.
[HMPR04] A.R. Hevner, S.T. March, J. Park, and S. Ram. Design Science Research in Infor-
mation Systems. Management Information Systems Quarterly, 28:75–105, 2004.
[HMR12] M. Hipp, B. Mutschler, and M. Reichert. Navigating in Complex Business Processes.
In 23rd Int’l Conf on Database and Expert Systems Applications (DEXA’12), Part
II, number 7447 in LNCS, pages 466–480. Springer, 2012.
[Hoy09] D. Hoyle. ISO 9000: Quality Systems Handbook. Elsevier, 6. edition, 2009.
[HPS`18] B. Hoppenstedt, R. Pryss, B. Stelzer, F. Meyer-Br¨
otz, K. Kammerer, A. Treß, and
M. Reichert. Techniques and Emerging Trends for State of the Art Equipment
Maintenance Systems - A Bibliometric Analysis. Applied Sciences, 8:1–29, June
2018.
[HRZ`08] K. Hose, A. Roth, A. Zeitz, K.-U. Sattler, and F. Naumann. A Research Agenda
for Query Processing in Large-Scale Peer Data Management Systems. Information
Systems, 33(7):597–610, 2008.
[HS98] M.A. Hern´andez and S.J. Stolfo. Real-world Data is Dirty: Data Cleansing and The
Merge/Purge Problem. Data Mining and Knowledge Discovery, 2(1):9–37, 1998.
[HSP13] S. Harris, A. Seaborne, and E. Prud’hommeaux. SPARQL 1.1 query language. W3C
Recommendation, 21(10), 2013.
[Inm05] W.H. Inmon. Building the Data Warehouse. John Wiley & sons, 3rd edition, 2005.
[ISO03a] ISO 10007: Quality management systems – Guidelines for configuration manage-
ment. Standard, International Organization for Standardization, Geneva, CH, 2003.
[ISO03b] ISO 18876-1: Integration of industrial data for exchange, access and sharing – Part
1: Architecture overview and description. Standard, International Organization for
Standardization, Geneva, CH, 2003.
[ISO03c] ISO 18876-2: Integration of industrial data for exchange, access and sharing – Part
2: Integration and mapping methodology. Standard, International Organization for
Standardization, Geneva, CH, 2003.
[ISO08] ISO 9001: Quality Management Systems – Requirements. Standard, International
Organization for Standardization, Geneva, CH, 2008.
[JDB`98] C.S. Jensen, C.E. Dyreson, M. B¨
ohlen, J. Clifford, R. Elmasri, S.K. Gadia, F. Gran-
di,P.Hayes,S.Jajodia,W.K
¨
afer, et al. The Consensus Glossary of Temporal
Database Concepts — February 1998 Version. In Temporal Databases: Research
and Practice, pages 367–405. Springer, 1998.
[JG99] J. M. Juran and A. B. Godfrey. Juran’s Quality Handbook. McGraw-Hill, 1999.
[Kat15] A Katzenbach. Automotive. In Concurrent Engineering in the 21st Century, pages
607–638. Springer, 2015.
245
Literaturverzeichnis
[KCH`90] K.C. Kang, S.G. Cohen, J.A. Hess, W.E. Novak, and A.S. Peterson. Feature-
Oriented Domain Analysis (FODA) Feasibility Study. Technical report, Carnegie-
Mellong University - Software Engineering Institute, 1990.
[KCH`03] W. Kim, B. Choi, E. Hong, S. Kim, and D. Lee. A Taxonomy of Dirty Data. Data
Mining and Knowledge Discovery, 7(1):81–99, 2003.
[KPSR18] K. Kammerer, R. Pryss, K. Sommer, and M. Reichert. Towards Context-aware
Process Guidance in Cyber-Physical Systems with Augmented Reality. In 4th Inter-
national Workshop on Requirements Engineering for Self-Adaptive, Collaborative,
and Cyber Physical Systems (RESACS’18). IEEE Computer Society Press, 2018.
[KR09] V. K¨
unzle and M. Reichert. Towards Object-aware Process Management Systems:
Issues, Challenges, Benefits. In 10th Int’l Workshop on Business Process Mode-
ling, Development, and Support (BPMDS’09), number 29 in LNBIP, pages 197–210.
Springer, June 2009.
[KR11] R. Kimball and M. Ross. The Data Warehouse Toolkit: The Complete Guide to
Dimensional Modeling. John Wiley & Sons, 2011.
[KR17] D. Knuplesch and M. Reichert. A Visual Language for Modeling Business Process
Compliance Rules. Software & Systems Modeling, 16:715–736, 2017.
[KRK17] D. Knuplesch, M. Reichert, and A. Kumar. A framework for visually monitoring
business process compliance. Information Systems, 64:381–409, March 2017.
[KRS08] F. Klar, S. Rose, and A. Sch¨
urr. A Meta-model-Driven Tool Integration Deve-
lopment Process. In International United Information Systems Conference, pages
201–212. Springer, 2008.
[KS91] W. Kim and J. Seo. Classifying Schematic and Data Heterogeneity in Multidatabase
Systems. IEEE Computer, 24(12):12–18, 1991.
[KS06] A. K¨
onigs and A. Sch¨
urr. Tool Integration with Triple Graph Grammars - A Survey.
Electronic Notes in Theoretical Computer Science, 148(1):113–150, 2006.
[LBK07] R. Lenz, M. Beyer, and K.A. Kuhn. Semantic Integration in Healthcare Networks.
volume 76, pages 201–207. Elsevier, 2007.
[Len02] M. Lenzerini. Data Integration: A Theoretical Perspective. In Proceedings of the
twenty-first ACM SIGMOD-SIGACT-SIGART symposium on Principles of data-
base systems, pages 233–246. ACM, 2002.
[Len03] R. Lenz. Integration und Evolution ablaufunterst¨
utzender Informationssysteme im
Krankenhaus. GI-Arbeitskreis EA - Fr¨
uhjahrskonferenz, pages 34–41, 2003.
[LN06] U. Leser and F. Naumann. Informationsintegration: Architekturen und Methoden
zur Integration verteilter und heterogener Datenquellen. dpunkt, 2006.
[Los09] D. Loshin. Master Data Management. Morgan Kaufmann, 2009.
246
Literaturverzeichnis
[LR07] R. Lenz and M. Reichert. IT Support for Healthcare Processes - Premises, Chal-
lenges, Perspectives. Data and Knowledge Engineering, 61(1):39–58, May 2007.
[LR12] M. Lohrmann and M. Reichert. Efficacy-aware Business Process Modeling. In
20th International Conference on Cooperative Information Systems (CoopIS 2012),
number 7565 in LNCS, pages 38–55. Springer, September 2012.
[LR16] M. Lohrmann and M. Reichert. Effective application of process improvement pat-
terns to business processes. Software & Systems Modeling, 15(2):353–375, May
2016.
[LRW09] C. Li, M. Reichert, and A. Wombacher. Discovering Reference Models by Mining
Process Variants Using a Heuristic Approach. In 7th Int’l Conference on Business
Process Management (BPM’09), number 5701 in LNCS, pages 344–362. Springer,
September 2009.
[LSo98] O. Lassila, R.R. Swick, and other. Resource Description Framework (RDF) Model
and Syntax Specification, 1998.
[Mer14] J. Merkel. Entwurf eines Usability-Konzeptes f¨
ur das Produktdatenintegrationssys-
tem PROCEED. Master thesis, Universit¨
at Ulm, 2014.
[MHHR06] D. M¨
uller, J. Herbst, M. Hammori, and M. Reichert. IT Support for Release Ma-
nagement Processes in the Automotive Industry. In International Conference on
Business Process Management (BPM’06), pages 368–377. Springer, 2006.
[MHR06] D. M¨
uller, J. Herbst, and M. Reichert. Flexibility of Data-Driven Process Struc-
tures. In BPM’06 Int’l Workshops, Workshop on Dynamic Process Management
(DPM’06), number 4103 in LNCS, pages 181–192. Springer, September 2006.
[MHR07] D. M¨
uller, J. Herbst, and M. Reichert. Data-driven Modeling and Coordination of
Large Process Structures. In 15th Int’l Conf on Cooperative Information Systems
(CoopIS 2007), number 4803 in LNCS, pages 131–149. Springer, November 2007.
[MHR08] D. M¨
uller, J. Herbst, and M. Reichert. A New Paradigm for the Enactment and
Dynamic Adaptation of Data-driven Process Structures. In 20th Int’l Conf on
Advanced Information Systems Engineering (CAiSE’08), number 5074 in LNCS,
pages 48–63. Springer, June 2008.
[MMR12] B. Michelberger, B. Mutschler, and M. Reichert. Process-oriented Information Lo-
gistics: Aligning Enterprise Information with Business Processes. In 16th IEEE
International EDOC Conference (EDOC 2012), pages 21–30. IEEE Computer So-
ciety Press, September 2012.
[MPSP`09] B. Motik, P.F. Patel-Schneider, B. Parsia, C. Bock, A. Fokoue, P. Haase,
R. Hoekstra, I. Horrocks, A. Ruttenberg, U. Sattler, et al. OWL 2 Web Ontology
Language: Structural Specification and Functional-Style Syntax. W3C Recommen-
dation, 27(65):159, 2009.
247
Literaturverzeichnis
[MRB08] B. Mutschler, M. Reichert, and J. Bumiller. Unleashing the Effectiveness of
Process-oriented Information Systems: Problem Analysis, Critical Success Factors
and Implications. IEEE Transactions on Systems, Man, and Cybernetics (Part C),
38(3):280–291, May 2008.
[MRH07] D. M¨
uller, M. Reichert, and J. Herbst. Data-driven Modeling and Coordination of
Large Process Structures. In 15th Int’l Conf on Cooperative Information Systems
(CoopIS 2007), number 4803 in LNCS, pages 131–149. Springer, November 2007.
[MSR13] C. Manz, M. Stupperich, and M. Reichert. Towards Integrated Variant Management
in Global Software Engineering: An Experience Report. In 8th IEEE Internatio-
nal Conference on Global Software Engineering (ICGSE’13), pages 168–172. IEEE
Computer Society Press, August 2013.
[M¨
ul09] D. M¨
uller. Management datengetriebener Prozessstrukturen. PhD thesis, Univer-
sit¨
at Ulm, 2009.
[MVH`04] D.L. McGuinness, F. Van Harmelen, et al. OWL Web Ontology Language Overview.
W3C Recommendation, 10(10), 2004.
[MWR08] B. Mutschler, B. Weber, and M. Reichert. Workflow Management versus Case
Handling: Results from a Controlled Software Experiment. In 23rd Annual ACM
Symposium on Applied Computing (SAC’08), Special Track on Coordination Mo-
dels, Languages and Architectures, pages 82–89. ACM Press, March 2008.
[Nob07] S.H. Nobari. Methode zur wirkungsorientierten Beschreibung variantenreicher Er-
zeugnisse (WIBER): Handhabung der Komplexit¨
at in der technischen Erzeugnisdo-
kumentation. Shaker, 2007.
[ORH05] P. Oliveira, F. Rodrigues, and P.R. Henriques. A Formal Definition of Data Quality
Problems. In Proceedings of the 2005 International Conference on Information
Quality (MIT IQ Conference), 2005.
[ORMC23] C.K. Ogden, I. A. Richards, B. Malinowski, and F. G. Crookshank. The Meaning
of Meaning. Kegan Paul London, 1923.
[PMR93] B. Prasad, R. S Morenc, and R.M. Rangan. Information Management for Concur-
rent Engineering: Research Issues. Concurrent Engineering, 1(1):3–20, 1993.
[PNSD07] T. Prefi, I. Neum¨
arker, R. Schmitt, and K. Daniel. Qualit¨
atsmanagement in der
Produktentwicklung. Masing Handbuch Qualit¨
atsmanagement, 5:405–433, 2007.
[PS14] T. Pfeifer and R. Schmitt. Masing Handbuch Qualit¨
atsmanagement. Carl Hanser
Verlag GmbH Co KG, 2014.
[PTKR10] R. Pryss, J. Tiedeken, U. Kreher, and M. Reichert. Towards Flexible Process Sup-
port on Mobile Devices. In Proc CAiSE’10 Forum - Information Systems Evolution,
number 72 in LNBIP, pages 150–165. Springer, 2010.
[PTR10] R. Pryss, J. Tiedeken, and M. Reichert. Managing Processes on Mobile Devices:
The MARPLE Approach. In CAiSE’10 Demos, June 2010.
248
Literaturverzeichnis
[PVSV07] G. Papastefanatos, P. Vassiliadis, A. Simitsis, and Y. Vassiliou. What-If Analysis
for Data Warehouse Evolution. In International Conference on Data Warehousing
and Knowledge Discovery (DaWaK 2007), pages 23–33. Springer, 2007.
[RBRB06] S. Rinderle, R. Bobrik, M. Reichert, and T. Bauer. Businesss Process Visualization
- Use Cases, Challenges, Solutions. In 8th Int’l Conf on Enterprise Information Sys-
tems (ICEIS’06) Track on Information Systems Analysis and Specification, pages
204–211, May 2006.
[Red97] T.C. Redman. Data Quality for the Information Age. Artech House, Inc., Norwood,
MA, USA, 1997.
[Rei00] M. Reichert. Dynamische Ablauf¨
anderungen in Workflow-Management-Systemen.
PhD thesis, Universit¨
at Ulm, 2000.
[Roc75] M.J. Rochkind. The Source Code Control System. IEEE Transactions on Software
Engineering, (4):364–370, 1975.
[Rod95] J.F. Roddick. A Survey of Schema Versioning Issues for Database Systems. Infor-
mation and Software Technology, 37(7):383–393, 1995.
[Row07] J.E. Rowley. The wisdom hierarchy: representations of the DIKW hierarchy. Journal
of Information Science, 2007.
[Roz97] G. Rozenberg. Handbook of Graph Grammars and Computing, volume 1. World
Scientific, 1997.
[RR06] S. Rinderle and M. Reichert. Data-Driven Process Control and Exception Handling
in Process Management Systems. In 18th Int’l Conf on Advanced Information
Systems Engineering (CAiSE’06), number 4001 in LNCS, pages 273–287. Springer,
June 2006.
[RRD03] M. Reichert, S Rinderle, and P. Dadam. On the Common Support of Workflow
Type and Instance Changes under Correctness Constraints. In 11th Int’l Conf
Cooperative Information Systems (CooplS 2003), number 2888 in LNCS, pages 407–
425. Springer, November 2003.
[RRD04a] S. Rinderle, M. Reichert, and P. Dadam. Correctness Criteria for Dynamic Changes
in Workflow Systems: A Survey. Data & Knowledge Engineering, 50(1):9–34, 2004.
[RRD04b] S. Rinderle, M. Reichert, and P. Dadam. Flexible Support of Team Processes by
Adaptive Workflow Systems. Distributed and Parallel Databases, 16(1):91–116, July
2004.
[RRMD09] M. Reichert, S. Rinderle-Ma, and P. Dadam. Flexibility in Process-aware Informa-
tion Systems. LNCS Transactions on Petri Nets and Other Models of Concurrency
(ToPNoC), Special Issue on Concurrency in Process-aware Information Systems,
2:115–135, March 2009.
[RS13] A. Roth and S. Skritek. Peer Data Management. Dagstuhl Follow-Ups, 5, 2013.
249
Literaturverzeichnis
[RSB`08] S. Rachuri, E. Subrahmanian, A. Bouras, S.J. Fenves, S. Foufou, and R.D. Sriram.
Information sharing and exchange in the context of product lifecycle management:
Role of standards. Computer-Aided Design, 40(7):789–800, 2008.
[RTW15] Georg Rock, Karsten Theis, and Patrick Wischnewski. Variability Management.
In Concurrent Engineering in the 21st Century, pages 491–519. Springer, 2015.
[RW12] M. Reichert and B. Weber. Enabling Flexibility in Process-Aware Information Sys-
tems: Challenges, Methods, Technologies. Springer, Berlin-Heidelberg, 2012.
[SAR18] S. Steinau, K. Andrews, and M. Reichert. The Relational Process Structure. In
30th Int’l Conference on Advanced Information Systems Engineering (CAiSE 2018),
number 10816 in LNCS, pages 53–67. Springer, 2018.
[SAS05] SASIG. Product Data Quality Guidelines for the Global Automotive Industry,
Version 2 revision 1. Technical report, SASIG, 2005.
[SI08] A. Saaksvuori and A. Immonen. Product Lifecycle Management. Springer Science
& Business Media, 2008.
[Sim96] H.A. Simon. The Sciences of the Artificial. MIT press, 3rd edition, 1996.
[SKAR17] S. Steinau, V. K¨
unzle, K. Andrews, and M. Reichert. Coordinating Business Pro-
cesses Using Semantic Relationships. In 19th IEEE Conference on Business Infor-
matics (CBI 2017), pages 33–42. IEEE Computer Society Press, July 2017.
[SL90] A.P. Sheth and J.A. Larson. Federated Database Systems for Managing Distributed,
Heterogeneous, and Autonomous Databases. ACM Computing Surveys, 22(3):183–
236, 1990.
[SMH08] R. Shearer, B. Motik, and I. Horrocks. HermiT: A Highly-Efficient OWL Reasoner.
In OWLED, volume 432, page 91, 2008.
[SRF`05] E. Subrahmanian, S. Rachuri, S.J. Fenves, S. Foufou, and R.D. Sriram. Challenges
in Supporting Product Design and Manufacturing in a Networked Economy: A PLM
perspective. In Proceedings of the International Conference on Product Lifecycle
Management (PLM 05), pages 495–506, 2005.
[Sta11] J. Stark. Product Lifecycle Management. Springer, 2011.
[Ste12] V. Steller. OpenConfigurator - A Practical Approach to Configurator Implementa-
tion. Master’s thesis, Ulm University, 2012.
[SWB12] M. Schulze, J. Weiland, and D. Beuche. Automotive Model-Driven Development
and the Challenge of Variability. In Proceedings of the 16th International Software
Product Line Conference (SPLC’12) – Volume 1, pages 207–214. ACM, 2012.
[Tat09] A. Tatnall. Web Technologies: Concepts, Methodologies, Tools, and Applications:
Concepts, Methodologies, Tools, and Applications. IGI Global, 2009.
250
Literaturverzeichnis
[TBHR15] J. Tiedeken, T. Bauer, J. Herbst, and M. Reichert. Determining the Quality of
Product Data Integration. In 23rd International Conference on Cooperative Infor-
mation Systems (CoopIS 2015), number 9415 in Lecture Notes in Computer Science,
pages 267–284. Springer, 2015.
[Tho09] J. W. Thomas. Data-Exchange Standards and International Organizations: Adop-
tion and Diffusion. IGI Global, 2009.
[THR13a] J. Tiedeken, J. Herbst, and M. Reichert. Managing Complex Data for Electrical/E-
lectronic Components: Challenges and Requirements. In Proc BTW’13 Workshops,
15th Conf on Database Systems, Technology, and Web (BTW’13), number 216 in
Lecture Notes in Informatics (LNI), pages 141–150. Koellen-Verlag, March 2013.
[THR13b] J. Tiedeken, J. Herbst, and M. Reichert. On the Integration of Electrical/Electronic
Product Data in the Automotive Domain. Datenbank Spektrum, 13(3):189–199,
September 2013.
[TRS15] D. Trippner, S. Rude, and A. Schreiber. Challenges to Digital Product and Process
Development Systems at BMW. In Concurrent Engineering in the 21st Century,
pages 555–569. Springer, 2015.
[UB02] M. Ungerer and K. Buchanan. Usage Guide for the STEP PDM Schema v4.3, 202.
[Ver97] W.W.M. Vermeer. Semantic Interoperability for Legacy Databases. 1997.
[Vi09] VDA and ProSTEP iViP. ECM Recommendation Part 0 (ECM), Version 2.0.
Technical report, SASIG, 2009.
[VSW15] W.J.C. Verhagen, J. Stjepandi´c, and N. Wognum. Challenges of CE. In Concurrent
Engineering in the 21st Century, pages 807–833. Springer, 2015.
[Was90] A.I. Wasserman. Tool Integration in Software Engineering Environments. In Soft-
ware Engineering Environments, pages 137–149. Springer, 1990.
[Web14] J. Weber. Automotive Development Processes. Springer, 2014.
[Wes96] M. West. Integration of Industrial Data for Exchange, Access, and Sharing (II-
DEAS). Technical report, 1996. Accessed: 2016-07-15.
[Whi08] S.A. White. BPMN Modeling and Reference Guide: Understanding and Using
BPMN. Future Strategies Inc., 2008.
[Win99] W.E Winkler. The State of Record Linkage and Current Research Problems. In
Statistical Research Division, US Census Bureau. Citeseer, 1999.
[WKLW98] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf. Dublin Core Metadata for Resource
Discovery. Technical report, 1998.
[WS96] Richard Y Wang and Diane M Strong. Beyond Accuracy: What Data Quality
Means to Data Consumers. Journal of Management Information Systems, 12(4):5–
33, 1996.
251
Literaturverzeichnis
[WZL06] R.Y. Wang, M. Ziad, and Y.W. Lee. Data Quality. Springer Science & Business
Media, 2006.
[XN09] X. Xu and A.Y.C. Nee. Advanced Design and Manufacturing Based on STEP.
Springer Science & Business Media, 2009.
[YB03] A. Yassine and D. Braha. Complex Concurrent Engineering and the Design Struc-
ture Matrix Method. Concurrent Engineering, 11(3):165–176, 2003.
252
Anhang
A Globale Produktontologie gpo
1@prefix owl: <http://www.w3.org/2002/07/owl#>.
2@prefix rdf: <http://www.w3.org/1999/02/22´rdf´syntax´ns#>.
3@prefix xml: <http://www.w3.org/XML/1998/namespace>.
4@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
5@prefix rdfs: <http://www.w3.org/2000/01/rdf´schema#>.
6@prefix mo: <http://www.uni´ulm.de/proceed/metaontology.owl#>.
7@prefix :<http://www.uni´ulm.de/proceed/gpo#>.
8@base <http://www.uni´ulm.de/proceed/gpo>.
9
10 gpo rdf:type owl:Ontology ;
11 rdfs:label ”Global Product Ontology” ;
12 owl:versionInfo ”1.0” ;
13 rdfs:comment ”Global Product Ontology” ;
14 owl:imports <http://www.uni´ulm.de/proceed/metaontology.owl#>;
15 mo:ontologyType mo:GlobalProductOntology .
16
17 :Product SC rdf:type owl:Class ;
18 rdfs:label ”Product” ;
19 rdfs:subClassOf mo:GlobalPDCLayer .
20
21 :Component SC rdf:type owl:Class ;
22 rdfs:label ”Component” ;
23 rdfs:subClassOf mo:GlobalObjectLayer .
24
25 :ComponentVariant SC rdf:type owl:Class ;
26 rdfs:label ”Component Variant” ;
27 rdfs:subClassOf mo:GlobalVariantLayer .
28
29 :ComponentVersion SC rdf:type owl:Class ;
30 rdfs:label ”Component Version” ;
31 rdfs:subClassOf mo:GlobalVersionLayer .
32
33 :ComponentBelowProduct rdf:type owl:ObjectProperty ;
34 rdfs:label ”ComponentIsBelowProduct” ;
35 rdfs:subPropertyOf mo:isBelow ;
36 rdfs:domain :Component SC ;
37 rdfs:range :Product SC .
38
39 :ProductAboveComponent rdf:type owl:ObjectProperty ;
40 rdfs:label ”ProductIsAboveComponent” ;
41 rdfs:subPropertyOf mo:isAbove ;
42 rdfs:domain :Product SC ;
43 rdfs:range :Component SC .
44
45 :ComponentBelowProduct owl:inversOf :ProductAboveComponent .
253
Literaturverzeichnis
46
47 :VariantBelowComponent rdf:type owl:ObjectProperty ;
48 rdfs:label ”ComponentVariantIsBelowComponent” ;
49 rdfs:subPropertyOf mo:isBelow ;
50 rdfs:domain :ComponentVariant SC ;
51 rdfs:range :Component SC .
52
53 :ComponentAboveVariant rdf:type owl:ObjectProperty ;
54 rdfs:label ”ComponentIsAboveComponentVariant” ;
55 rdfs:subPropertyOf mo:isAbove ;
56 rdfs:domain :Component SC ;
57 rdfs:range :ComponentVariant SC .
58
59 :VariantBelowComponent owl:inversOf :ComponentAboveVariant .
60
61 :VersionBelowVariant rdf:type owl:ObjectProperty ;
62 rdfs:label ”ComponentVersionIsBelowComponentVariant” ;
63 rdfs:subPropertyOf mo:isBelow ;
64 rdfs:domain :ComponentVersion SC ;
65 rdfs:range :ComponentVariant SC .
66
67 :VariantAboveVersion rdf:type owl:ObjectProperty ;
68 rdfs:label ”ComponentVariantIsAboveComponentVersion” ;
69 rdfs:subPropertyOf mo:isAbove ;
70 rdfs:domain :ComponentVariant SC ;
71 rdfs:range :ComponentVersion SC .
72 :VersionBelowVariant owl:inversOf :VariantAboveVersion .
73
74 :ComponentVersionNr Attr rdf:type owl:DatatypeProperty ;
75 rdfs:domain :ComponentVersion SC ;
76 rdfs:range xsd:string ;
77 rdfs:subPropertyOf mo:Attribute .
78
79 :ECU Ref Attr rdf:type owl:DatatypeProperty ;
80 rdfs:domain :ComponentVersion SC ;
81 rdfs:range xsd:string ;
82 rdfs:subPropertyOf mo:Attribute .
83
84 :GeometryModelRef Attr rdf:type owl:DatatypeProperty ;
85 rdfs:domain :ComponentVersion SC ;
86 rdfs:subPropertyOf mo:Attribute .
87
88 :Label Attr rdf:type owl:DatatypeProperty ;
89 rdfs:range xsd:string ;
90 rdfs:subPropertyOf mo:Attribute .
91
92 :VariantCoding Attr rdf:type owl:DatatypeProperty ;
93 rdfs:domain :ComponentVariant SC ;
94 rdfs:range xsd:string ;
95 rdfs:subPropertyOf mo:Attribute .
Listing 11.1: Globale Produktontologie als OWL-Ontologie
254
Literaturverzeichnis
B Produktontologien des Integrationsszenarios 1
1@prefix owl: <http://www.w3.org/2002/07/owl#>.
2@prefix rdf: <http://www.w3.org/1999/02/22´rdf´syntax´ns#>.
3@prefix xml: <http://www.w3.org/XML/1998/namespace>.
4@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
5@prefix rdfs: <http://www.w3.org/2000/01/rdf´schema#>.
6@prefix mo: <http://www.uni´ulm.de/proceed/metaontology.owl#>.
7@prefix :<http://www.uni´ulm.de/proceed/gpo#>.
8@base <http://www.uni´ulm.de/proceed/gpo>.
9
10 gpo rdf:type owl:Ontology ;
11 rdfs:label ”Global Product Ontology” ;
12 owl:versionInfo ”1.0” ;
13 rdfs:comment ”Global Product Ontology” ;
14 owl:imports <http://www.uni´ulm.de/proceed/metaontology.owl#>;
15 mo:ontologyType mo:GlobalProductOntology .
16
17 :Product SC rdf:type owl:Class ;
18 rdfs:label ”Product” ;
19 rdfs:subClassOf mo:GlobalPDCLayer .
20
21 :Component SC rdf:type owl:Class ;
22 rdfs:label ”Component” ;
23 rdfs:subClassOf mo:GlobalObjectLayer .
24
25 :ComponentVariant SC rdf:type owl:Class ;
26 rdfs:label ”Component Variant” ;
27 rdfs:subClassOf mo:GlobalVariantLayer .
28
29 :ComponentVersion SC rdf:type owl:Class ;
30 rdfs:label ”Component Version” ;
31 rdfs:subClassOf mo:GlobalVersionLayer .
32
33 :ComponentBelowProduct rdf:type owl:ObjectProperty ;
34 rdfs:label ”ComponentIsBelowProduct” ;
35 rdfs:subPropertyOf mo:isBelow ;
36 rdfs:domain :Component SC ;
37 rdfs:range :Product SC .
38
39 :ProductAboveComponent rdf:type owl:ObjectProperty ;
40 rdfs:label ”ProductIsAboveComponent” ;
41 rdfs:subPropertyOf mo:isAbove ;
42 rdfs:domain :Product SC ;
43 rdfs:range :Component SC .
44
45 :ComponentBelowProduct owl:inversOf :ProductAboveComponent .
46
47 :VariantBelowComponent rdf:type owl:ObjectProperty ;
48 rdfs:label ”ComponentVariantIsBelowComponent” ;
49 rdfs:subPropertyOf mo:isBelow ;
50 rdfs:domain :ComponentVariant SC ;
51 rdfs:range :Component SC .
52
53 :ComponentAboveVariant rdf:type owl:ObjectProperty ;
54 rdfs:label ”ComponentIsAboveComponentVariant” ;
255
Literaturverzeichnis
55 rdfs:subPropertyOf mo:isAbove ;
56 rdfs:domain :Component SC ;
57 rdfs:range :ComponentVariant SC .
58
59 :VariantBelowComponent owl:inversOf :ComponentAboveVariant .
60
61 :VersionBelowVariant rdf:type owl:ObjectProperty ;
62 rdfs:label ”ComponentVersionIsBelowComponentVariant” ;
63 rdfs:subPropertyOf mo:isBelow ;
64 rdfs:domain :ComponentVersion SC ;
65 rdfs:range :ComponentVariant SC .
66
67 :VariantAboveVersion rdf:type owl:ObjectProperty ;
68 rdfs:label ”ComponentVariantIsAboveComponentVersion” ;
69 rdfs:subPropertyOf mo:isAbove ;
70 rdfs:domain :ComponentVariant SC ;
71 rdfs:range :ComponentVersion SC .
72 :VersionBelowVariant owl:inversOf :VariantAboveVersion .
73
74
75 :Name Attr rdf:type owl:DatatypeProperty ;
76 rdfs:range xsd:string ;
77 rdfs:subPropertyOf mo:Attribute .
78
79 :Responsible Attr rdf:type owl:DatatypeProperty ;
80 rdfs:range xsd:string ;
81 rdfs:subPropertyOf mo:Attribute .
82
83 :Id Attr rdf:type owl:DatatypeProperty ;
84 rdfs:domain :Product SC ;
85 rdfs:range xsd:string ;
86 rdfs:subPropertyOf mo:Attribute .
87
88 :SOP Attr rdf:type owl:DatatypeProperty ;
89 rdfs:domain :Product SC ;
90 rdfs:range xsd:string ;
91 rdfs:subPropertyOf mo:Attribute .
92
93 :Abbreviation Attr rdf:type owl:DatatypeProperty ;
94 rdfs:domain :Component SC ;
95 rdfs:range xsd:string ;
96 rdfs:subPropertyOf mo:Attribute .
97
98 :Type Attr rdf:type owl:DatatypeProperty ;
99 rdfs:domain :Component SC ;
100 rdfs:range xsd:string ;
101 rdfs:subPropertyOf mo:Attribute .
102
103 :Code Attr rdf:type owl:DatatypeProperty ;
104 rdfs:domain :ComponentVariant SC ;
105 rdfs:range xsd:string ;
106 rdfs:subPropertyOf mo:Attribute .
107
108 :VersionId Attr rdf:type owl:DatatypeProperty ;
109 rdfs:domain :ComponentVersion SC ;
110 rdfs:range xsd:integer ;
256
Literaturverzeichnis
111 rdfs:subPropertyOf mo:Attribute .
112
113 :PartId Attr rdf:type owl:DatatypeProperty ;
114 rdfs:domain :ComponentVersion SC ;
115 rdfs:range xsd:integer ;
116 rdfs:subPropertyOf mo:Attribute .
117
118 :Requirements Attr rdf:type owl:DatatypeProperty ;
119 rdfs:domain :ComponentVersion SC ;
120 rdfs:range xsd:string ;
121 rdfs:subPropertyOf mo:Attribute .
122
123 :Geometry Attr rdf:type owl:DatatypeProperty ;
124 rdfs:domain :ComponentVersion SC ;
125 rdfs:range xsd:string ;
126 rdfs:subPropertyOf mo:Attribute .
127
128 :Software Attr rdf:type owl:DatatypeProperty ;
129 rdfs:domain :ComponentVersion SC ;
130 rdfs:range xsd:string ;
131 rdfs:subPropertyOf mo:Attribute .
Listing 11.2: Globale Produktontologie als OWL2-Ontologie
C Lokale Produktontologie lpo1
1@prefix owl: <http://www.w3.org/2002/07/owl#>.
2@prefix rdf: <http://www.w3.org/1999/02/22´rdf´syntax´ns#>.
3@prefix xml: <http://www.w3.org/XML/1998/namespace>.
4@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
5@prefix rdfs: <http://www.w3.org/2000/01/rdf´schema#>.
6@prefix mo: <http://www.uni´ulm.de/proceed/metaontology.owl#>.
7@prefix :<http://www.uni´ulm.de/proceed/lpo1#>.
8@base <http://www.uni´ulm.de/proceed/lpo1>.
9
10 lpo1 rdf:type owl:Ontology ;
11 rdfs:label ”Local Product Ontology 1” ;
12 owl:versionInfo ”1.0” ;
13 rdfs:comment ”Local Product Ontology 1” ;
14 owl:imports <http://www.uni´ulm.de/proceed/metaontology.owl#>;
15 mo:ontologyType mo:LocalProductOntologyType .
16
17 :Product SC rdf:type owl:Class ;
18 rdfs:label ”Product” ;
19 rdfs:subClassOf mo:LocalPDCLayer .
20
21 :ECU SC rdf:type owl:Class ;
22 rdfs:label ”ECU” ;
23 rdfs:subClassOf mo:LocalObjectLayer .
24
25 :ECUVariant SC rdf:type owl:Class ;
26 rdfs:label ”ECU Variant” ;
27 rdfs:subClassOf mo:LocalVariantLayer .
28
29 :ECUVersion SC rdf:type owl:Class ;
30 rdfs:label ”ECU Version” ;
257
Literaturverzeichnis
31 rdfs:subClassOf mo:LocalVersionLayer .
Listing 11.3: Lokale Produktontologie lpo1 als OWL-Ontologie
D Lokale Masterproduktontologie mpo
1@prefix owl: <http://www.w3.org/2002/07/owl#>.
2@prefix rdf: <http://www.w3.org/1999/02/22´rdf´syntax´ns#>.
3@prefix xml: <http://www.w3.org/XML/1998/namespace>.
4@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
5@prefix rdfs: <http://www.w3.org/2000/01/rdf´schema#>.
6@prefix mo: <http://www.uni´ulm.de/proceed/metaontology.owl#>.
7@prefix :<http://www.uni´ulm.de/proceed/mpo#>.
8@base <http://www.uni´ulm.de/proceed/mpo>.
9
10 mpo rdf:type owl:Ontology ;
11 rdfs:label ”Local Master Product Ontology” ;
12 owl:versionInfo ”1.0” ;
13 rdfs:comment ”Local Master Product Ontology” ;
14 owl:imports <http://www.uni´ulm.de/proceed/metaontology.owl#>;
15 mo:ontologyType mo:LocalMasterProductOntologyType .
16
17 :Product SC rdf:type owl:Class ;
18 rdfs:label ”Product” ;
19 rdfs:subClassOf mo:LocalPDCLayer .
20
21 :Part SC rdf:type owl:Class ;
22 rdfs:label ”Part” ;
23 rdfs:subClassOf mo:LocalObjectLayer .
24
25 :PartVariant SC rdf:type owl:Class ;
26 rdfs:label ”Part Variant” ;
27 rdfs:subClassOf mo:LocalVariantLayer .
28
29 :PartVersion SC rdf:type owl:Class ;
30 rdfs:label ”Part Variant Version” ;
31 rdfs:subClassOf mo:LocalVersionLayer .
Listing 11.4: Globale Produktontologie als OWL-Ontologie
E Mapping zwischen lpo1 und gpo
1@prefix owl: <http://www.w3.org/2002/07/owl#>.
2@prefix rdf: <http://www.w3.org/1999/02/22´rdf´syntax´ns#>.
3@prefix xml: <http://www.w3.org/XML/1998/namespace>.
4@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
5@prefix rdfs: <http://www.w3.org/2000/01/rdf´schema#>.
6@prefix mo: <http://www.uni´ulm.de/proceed/metaontology.owl#>.
7@prefix :<http://www.uni´ulm.de/proceed/pom1#>.
8@base <http://www.uni´ulm.de/proceed/pom1>.
9
10 pom1 rdf:type owl:Ontology ;
11 rdfs:label ”Product Ontology Mapping 1” ;
12 owl:versionInfo ”1.0” ;
13 rdfs:comment Product Ontology Mapping” ;
14 owl:imports <http://www.uni´ulm.de/proceed/metaontology.owl#>;
258
Literaturverzeichnis
15 owl:imports <http://www.uni´ulm.de/proceed/lpo1#>;
16 owl:imports <http://www.uni´ulm.de/proceed/gpo#>;
17 mo:ontologyType mo:ProductOntologyMappingType .
18
19
20 :productCorrespondesProduct SCAR rdf:type owl:ObjectProperty , owl:SymmetricProperty ;
21 rdfs:label ”SCAR11”
22 rdfs:subPropertyOf mo:hasPDCSCARTo .
23 mo:hasMatchingFunction mo:StringEquivalence ;
24 mo:hasMatchingParameter ”” ;
25 rdfs:domain lpo1:Product SC ;
26 rdfs:range gpo:Product SC ;
27 mo:hasLocalAttribute lpo1:Name Attr ;
28 mo:hasGlobalAttribute gpo:Name Attr .
29
30 :ECUCorrespondesComponent SCAR rdf:type owl:ObjectProperty , owl:SymmetricProperty ;
31 rdfs:label ”SCAR12”
32 rdfs:subPropertyOf mo:hasObjectSCARTo .
33 mo:hasMatchingFunction mo:StringEquivalence ;
34 mo:hasMatchingParameter ”” ;
35 rdfs:domain lpo1:ECU SC ;
36 rdfs:range gpo:Component SC ;
37 mo:hasLocalAttribute lpo1:Name Attr ;
38 mo:hasGlobalAttribute gpo:Abbreviation Attr .
39
40 :ECUVariantCorrespondesComponentVariant SCAR rdf:type owl:ObjectProperty , owl:SymmetricProperty
;
41 rdfs:label ”SCAR13”
42 rdfs:subPropertyOf mo:hasVariantSCARTo .
43 mo:hasMatchingFunction mo:StringEquivalence ;
44 mo:hasMatchingParameter ”” ;
45 rdfs:domain lpo1:ECUVariant SC ;
46 rdfs:range gpo:ComponentVariant SC ;
47 mo:hasLocalAttribute lpo1:Name Attr ;
48 mo:hasGlobalAttribute gpo:Name Attr .
49
50
51 :ECUVersionCorrespondesComponentVersion SCAR rdf:type owl:ObjectProperty , owl:SymmetricProperty
;
52 rdfs:label ”SCAR14”
53 rdfs:subPropertyOf mo:hasVersionSCARTo ;
54 rdfs:domain lpo1:ECUVersion SC ;
55 rdfs:range gpo:ComponentVersion SC .
56
57
58 :Name AMC rdf:type owl:ObjectProperty ;
59 rdf:type mo:AttributeMatchingCondition ;
60
61 rdfs:subPropertyOf :ECUVersionCorrespondesComponentVersion SCAR ;
62 mo:hasMatchingFunction mo:StringEquivalence ;
63 mo:hasMatchingParameter ”” ;
64 mo:hasLocalAttribute lpo1:Name Attr ;
65 mo:hasGlobalAttribute gpo:Name Attr .
66
67 :VersionId AMC rdf:type owl:ObjectProperty ;
68 rdf:type mo:AttributeMatchingCondition ;
259
Literaturverzeichnis
69 rdfs:subPropertyOf :ECUVersionCorrespondesComponentVersion SCAR ;
70 mo:hasMatchingFunction mo:StringEquivalence ;
71 mo:hasMatchingParameter ”” ;
72 mo:hasLocalAttribute lpo1:VersionId Attr ;
73 mo:hasGlobalAttribute gpo:VersionId Attr .
74
75 :ECUVersion2ComponentVersion SCAA rdf:type owl:ObjectProperty ;
76 rdfs:label ”SCAA1”
77 rdfs:subPropertyOf mo:hasVersionSCAATo
78 mo:hasIntegrationBehavior mo:LatestIntegrationBehavior ;
79
80 rdfs:domain lpo1:ECUVersion SC ;
81 rdfs:range gpo:ComponentVersion SC ;
82 mo:hasLocalAttribute lpo1:reference Attr ;
83 mo:hasGlobalAttribute gpo:Software Attr .
Listing 11.5: Produktontologie-Mapping zwischen lpo1 und gpo
F Mapping zwischen mpo und gpo
1@prefix owl: <http://www.w3.org/2002/07/owl#>.
2@prefix rdf: <http://www.w3.org/1999/02/22´rdf´syntax´ns#>.
3@prefix xml: <http://www.w3.org/XML/1998/namespace>.
4@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
5@prefix rdfs: <http://www.w3.org/2000/01/rdf´schema#>.
6@prefix mo: <http://www.uni´ulm.de/proceed/metaontology.owl#>.
7@prefix :<http://www.uni´ulm.de/proceed/pom2#>.
8@base <http://www.uni´ulm.de/proceed/pom2>.
9
10 pom2 rdf:type owl:Ontology ;
11 rdfs:label ”Product Ontology Mapping 2” ;
12 owl:versionInfo ”1.0” ;
13 rdfs:comment Product Ontology Mapping” ;
14 owl:imports <http://www.uni´ulm.de/proceed/metaontology.owl#>;
15 owl:imports <http://www.uni´ulm.de/proceed/mpo#>;
16 owl:imports <http://www.uni´ulm.de/proceed/gpo#>;
17 mo:ontologyType mo:ProductOntologyMappingType .
18
19
20 :productCorrespondesProduct SCAR rdf:type owl:ObjectProperty , owl:SymmetricProperty ;
21 rdfs:label ”SCAR21”
22 rdfs:subPropertyOf mo:hasPDCSCARTo .
23 mo:hasMatchingFunction mo:StringEquivalence ;
24 mo:hasMatchingParameter ”” ;
25 rdfs:domain mpo:Product SC ;
26 rdfs:range gpo:Product SC ;
27 mo:hasLocalAttribute mpo:Name Attr ;
28 mo:hasGlobalAttribute gpo:Name Attr .
29
30 :partCorrespondesComponent SCAR rdf:type owl:ObjectProperty , owl:SymmetricProperty ;
31 rdfs:label ”SCAR22”
32 rdfs:subPropertyOf mo:hasObjectSCARTo .
33 mo:hasMatchingFunction mo:StringEquivalence ;
34 mo:hasMatchingParameter ”” ;
35 rdfs:domain mpo:Part SC ;
36 rdfs:range gpo:Component SC ;
260
Literaturverzeichnis
37 mo:hasLocalAttribute mpo:Name Attr ;
38 mo:hasGlobalAttribute gpo:Name Attr .
39
40 :partVariantCorrespondesComponentVariant SCAR rdf:type owl:ObjectProperty , owl:SymmetricProperty
;
41 rdfs:label ”SCAR23”
42 rdfs:subPropertyOf mo:hasVariantSCARTo .
43 mo:hasMatchingFunction mo:StringEquivalence ;
44 mo:hasMatchingParameter ”” ;
45 rdfs:domain mpo:PartVariant SC ;
46 rdfs:range gpo:ComponentVariant SC ;
47 mo:hasLocalAttribute mpo:Name Attr ;
48 mo:hasGlobalAttribute gpo:Name Attr .
49
50 :PartVersionCorrespondesComponentVersion SCAR rdf:type owl:ObjectProperty , owl:SymmetricProperty
;
51 rdfs:label ”SCAR24”
52 rdfs:subPropertyOf mo:hasVersionSCARTo ;
53 rdfs:domain mpo:ECUVersion SC ;
54 rdfs:range gpo:ComponentVersion SC .
55
56
57 :Name AMC rdf:type owl:ObjectProperty ;
58 rdf:type mo:AttributeMatchingCondition ;
59 rdfs:label ”SCAA1”
60 rdfs:subPropertyOf :PartVersionCorrespondesComponentVersion SCAR ;
61 mo:hasMatchingFunction mo:StringEquivalence ;
62 mo:hasMatchingParameter ”” ;
63 mo:hasLocalAttribute mpo:Name Attr ;
64 mo:hasGlobalAttribute gpo:Name Attr .
65
66 :VersionId AMC rdf:type owl:ObjectProperty ;
67 rdf:type mo:AttributeMatchingCondition ;
68 rdfs:subPropertyOf :PartVersionCorrespondesComponentVersion SCAR ;
69 mo:hasMatchingFunction mo:StringEquivalence ;
70 mo:hasMatchingParameter ”” ;
71 mo:hasLocalAttribute mpo:VersionId Attr ;
72 mo:hasGlobalAttribute gpo:VersionId Attr .
73
74 :Product2Product1 SCAA rdf:type owl:ObjectProperty ;
75 rdfs:label ”SCAA21”
76 rdfs:subPropertyOf mo:hasPDCSCAATo
77 mo:hasIntegrationBehavior mo:LatestIntegrationBehavior ;
78
79 rdfs:domain mpo:Product SC ;
80 rdfs:range gpo:Product SC ;
81 mo:hasLocalAttribute mpo:responsible Attr ;
82 mo:hasGlobalAttribute gpo:responsible Attr .
83
84 :Product2Product2 SCAA rdf:type owl:ObjectProperty ;
85 rdfs:label ”SCAA22”
86 rdfs:subPropertyOf mo:hasPDCSCAATo
87 mo:hasIntegrationBehavior mo:LatestIntegrationBehavior ;
88
89 rdfs:domain mpo:Product SC ;
90 rdfs:range gpo:Product SC ;
261
Literaturverzeichnis
91 mo:hasLocalAttribute mpo:Id Attr ;
92 mo:hasGlobalAttribute gpo:Id Attr .
93
94 :Product2Product3 SCAA rdf:type owl:ObjectProperty ;
95 rdfs:label ”SCAA23”
96 rdfs:subPropertyOf mo:hasPDCSCAATo
97 mo:hasIntegrationBehavior mo:LatestIntegrationBehavior ;
98
99 rdfs:domain mpo:Product SC ;
100 rdfs:range gpo:Product SC ;
101 mo:hasLocalAttribute mpo:SOP Attr ;
102 mo:hasGlobalAttribute gpo:SOP Attr .
103
104
105 :Part2Component1 SCAA rdf:type owl:ObjectProperty ;
106 rdfs:label ”SCAA24”
107 rdfs:subPropertyOf mo:hasObjectSCAATo
108 mo:hasIntegrationBehavior mo:LatestIntegrationBehavior ;
109
110 rdfs:domain mpo:Part SC ;
111 rdfs:range gpo:Component SC ;
112 mo:hasLocalAttribute mpo:Abbreviation Attr ;
113 mo:hasGlobalAttribute gpo:Abbreviation Attr .
114
115 :Part2Component2 SCAA rdf:type owl:ObjectProperty ;
116 rdfs:label ”SCAA25”
117 rdfs:subPropertyOf mo:hasObjectSCAATo
118 mo:hasIntegrationBehavior mo:LatestIntegrationBehavior ;
119
120 rdfs:domain mpo:Part SC ;
121 rdfs:range gpo:Component SC ;
122 mo:hasLocalAttribute mpo:Type Attr ;
123 mo:hasGlobalAttribute gpo:Type Attr .
124
125 :PartVariant2ComponentVariant1 SCAA rdf:type owl:ObjectProperty ;
126 rdfs:label ”SCAA26”
127 rdfs:subPropertyOf mo:hasVariantSCAATo
128 mo:hasIntegrationBehavior mo:LatestIntegrationBehavior ;
129
130 rdfs:domain mpo:PartVariant SC ;
131 rdfs:range gpo:ComponentVariant SC ;
132 mo:hasLocalAttribute mpo:Code Attr ;
133 mo:hasGlobalAttribute gpo:Code Attr .
134
135 :PartVersion2ComponentVersion1 SCAA rdf:type owl:ObjectProperty ;
136 rdfs:label ”SCAA27”
137 rdfs:subPropertyOf mo:hasVersionSCAATo
138 mo:hasIntegrationBehavior mo:LatestIntegrationBehavior ;
139
140 rdfs:domain mpo:PartVersion SC ;
141 rdfs:range gpo:ComponentVersion SC ;
142 mo:hasLocalAttribute mpo:PartId Attr ;
143 mo:hasGlobalAttribute gpo:PartId Attr .
144
145 :PartVersion2ComponentVersion2 SCAA rdf:type owl:ObjectProperty ;
146 rdfs:label ”SCAA28”
262
Literaturverzeichnis
147 rdfs:subPropertyOf mo:hasVersionSCAATo
148 mo:hasIntegrationBehavior mo:LatestIntegrationBehavior ;
149
150 rdfs:domain mpo:PartVersion SC ;
151 rdfs:range gpo:ComponentVersion SC ;
152 mo:hasLocalAttribute mpo:Geometry Attr ;
153 mo:hasGlobalAttribute gpo:Geometry Attr .
Listing 11.6: Produktontologie-Mapping zwischen mpo und gpo
G Usability Konzept
Abbildung 11.1.: Grafische Darstellung von lokaler und globaler Produktontologie inklusive SCARs
263
Literaturverzeichnis
Abbildung 11.2.: Baumdarstellung von lokaler und globaler Produktontologie
264
Literaturverzeichnis
Abbildung 11.3.: Dashboard-Ansicht f¨
ur die Anzeige von Fehlern, Hinweisen und Metriken
265
Literaturverzeichnis
Abbildung 11.4.: Darstellung des grafischen Verlaufs von Qualit¨
atsmetriken
266
