Echtzeitdatenerfassung und Datenkonsolidierung zur ... · Universitat des Saarlandes, FR...
Transcript of Echtzeitdatenerfassung und Datenkonsolidierung zur ... · Universitat des Saarlandes, FR...
Universitat des Saarlandes, FR Informatik
Max-Planck-Institut fur Informatik, AG5
Diplomarbeit im Fach Informatik
Echtzeitdatenerfassung und
Datenkonsolidierung zur
Qualitatssicherung einer
Getriebefertigungsstrecke
Autor
Christian Nicolaus
Betreuer
Prof. Dr.-Ing. Gerhard Weikum
Dr. Manfred Hensel
Datum der Abgabe
28. Juli 2005
Zusammenfassung
Im Getriebewerk der Opel Powertrain GmbH in Russelsheim werden im Rahmen der Qualitats-
sicherung an den einzelnen Montage-Stationen Prozessdaten erfasst. Diese Arbeit befasst sich mit
der Entwicklung eines Systems zur Bereinigung und Integration der an den Montage-Stationen an-
fallenden Prozessdaten, um eine einheitliche Basis fur spatere Data Mining-Analysen und sonstige
Datenabfragen zu schaffen.
Ich versichere hiermit, dass ich die vorliegende Arbeit selbstandig verfasst und keine anderen als
die angegebenen Quellen und Hilfsmittel verwendet habe.
Christian Nicolaus
Saarbrucken, 28. Juli 2005
Danksagung
Diese Arbeit entstand in der Fachrichtung Informatik an der Universitat des Saarlandes in Zusam-
menarbeit mit der Opel Powertrain GmbH in Russelsheim. Ich mochte an dieser Stelle folgenden
Personen danken:
Herrn Dr. Manfred Hensel von der EDS Deutschland GmbH, fur die ausgesproch-
en freundliche Unterstutzung bei allen auftretenden
Fragen und Problemen sowie die gute Betreuung der
Arbeit.
Frau Britta Basler von der EDS Deutschland GmbH, fur die kritischen
und hilfreichen Anmerkungen.
Herrn Prof. Dr.-Ing. Gerhard Weikum fur die Betreuung der Arbeit seitens der Universitat.
Allen anderen beteiligten Personen der Opel Powertrain GmbH, der Adam Opel AG so-
wie der EDS Deutschland GmbH, die mir bei sowohl
fachlichen als auch organisatorischen Fragen behilflich
waren.
Inhaltsverzeichnis
1 Einleitung 1
1.1 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Umfeld der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Die Opel Powertrain GmbH . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Das Getriebewerk in Russelsheim . . . . . . . . . . . . . . . . . . . . . 3
1.3 Inhaltsuberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Bestandsaufnahme 6
2.1 Verbindungstechniken in der Getriebemontage . . . . . . . . . . . . . . . . . . . 6
2.2 Shims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Aufbau der Montagelinie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Aufbau einer Montage-Station . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Aufbau eines Operationsstands . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Erfassung von Prozessdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Abweichungen vom normalen Montageprozess . . . . . . . . . . . . . . . . . . 13
3 Anforderungen 15
3.1 Relevante Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Schraubkraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Presskraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3 Shim-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.4 Ausschleusungsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Relevante Stationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Datenkonsolidierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Aufbewahrung der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6 Systemumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
i
INHALTSVERZEICHNIS ii
4 Datenerfassung und Datenubertragung 19
4.1 Datenerfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Periodische versus sofortige Datenubertragung . . . . . . . . . . . . . . . . . . 20
4.3 Ubertragung der Schraub- und Presskraftdaten . . . . . . . . . . . . . . . . . . . 21
4.3.1 Das Q-DAS ASCII-Transferformat . . . . . . . . . . . . . . . . . . . . 21
4.3.2 DFD/DFX versus DFQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.3 Anforderungen an die zu erzeugenden DFQ-Dateien . . . . . . . . . . . 24
4.4 Ubertragung der Kombinationsdaten . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 Ubertragung der Shim-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6 Ubertragung der Ausschleusungsdaten . . . . . . . . . . . . . . . . . . . . . . . 29
5 Grundlagen zur Datenkonsolidierung 30
5.1 Datenqualitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 Datenqualitatsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.1 Single Source-Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.2 Multi Source-Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Datentransformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4 Datenbereinigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.4.1 Parsen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4.2 Integritatskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4.3 Ausreißererkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5 Die Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5.1 Datenanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5.2 Definition des Zielschemas . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.5.3 Definition der Datenbereinigungsprozesse . . . . . . . . . . . . . . . . . 46
6 Datenkonsolidierung 48
6.1 Datenanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1.1 Kombinationsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1.2 Presskraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1.3 Schraubkraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.1.4 Shim-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.1.5 Ausschleusungsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.1.6 Beziehungen zwischen den Quellen und Multi Source-Probleme . . . . . 58
6.2 Definition des Zielschemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3 Definition der Datenbereinigungsprozesse . . . . . . . . . . . . . . . . . . . . . 66
6.3.1 Einlesen und Bereinigen der Kombinationsdaten . . . . . . . . . . . . . 69
6.3.2 Einlesen und Bereinigen der Schraub- und Presskraftdaten . . . . . . . . 72
6.3.3 Einlesen und Bereinigen der Shim-Daten . . . . . . . . . . . . . . . . . 75
INHALTSVERZEICHNIS iii
6.3.4 Einlesen und Bereinigen der Ausschleusungsdaten . . . . . . . . . . . . 76
6.3.5 Bereinigen der Import- und Fehlertabellen . . . . . . . . . . . . . . . . . 76
7 Implementierung 77
7.1 Die Applikation QSF40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.2 Das Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8 Tests der Applikation QSF40 82
8.1 Die Applikation QSF40Sim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.2 Durchfuhrung der Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9 Fazit 85
A Tabellen 88
Abbildungsverzeichnis
1.1 Aufbau des F40-Getriebes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Schematischer Aufbau des Getriebewerks . . . . . . . . . . . . . . . . . . . . . 5
2.1 Einpressung einer Welle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Kraft-Weg-Diagramm einer Pressvorgangs . . . . . . . . . . . . . . . . . . . . . 8
2.3 Layout der Montagelinie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Grundstruktur des Q-DAS ASCII-Transferformats (Zeichnung angelehnt an [6]) . 22
4.2 Beispiel fur eine DFQ-Datei mit Schraubkraftdaten . . . . . . . . . . . . . . . . 27
4.3 Beispiel fur eine DFQ-Datei mit Presskraftdaten . . . . . . . . . . . . . . . . . . 28
4.4 Auszug aus einer Datei mit Kombinationsdaten . . . . . . . . . . . . . . . . . . 29
4.5 Auszug aus einer Datei mit Shim-Daten . . . . . . . . . . . . . . . . . . . . . . 29
4.6 Auszug aus einer Datei mit Ausschleusungsdaten . . . . . . . . . . . . . . . . . 29
5.1 Hierarchie von Qualitatskriterien nach [4] . . . . . . . . . . . . . . . . . . . . . 31
5.2 Klassifizierung von Qualitatsproblemen nach [2] . . . . . . . . . . . . . . . . . 33
5.3 Ausreißererkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.1 Logisches Datenbankmodell (ohne Fehlertabellen) . . . . . . . . . . . . . . . . 60
6.2 EQUI-Join zur Zuordnung der Schraub- und Presskraftdaten aus der Vormontage
zu den einzelnen Getrieben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.1 Aufbau der Applikation QSF40 . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
iv
Tabellenverzeichnis
2.1 Aufbau der Kombinationstabelle . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Ubersicht der qualitatsrelevanten Stationen . . . . . . . . . . . . . . . . . . . . . 17
4.1 Anzahl erzeugter Dateien in einem Zeitraum von acht Stunden bei einer Durch-
satzrate von 350 Getrieben in acht Stunden) . . . . . . . . . . . . . . . . . . . . 20
4.2 Schlusselfelder eines Werteeintrags . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1 Statistik zu Beispiel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Statistik zu Beispiel 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Statistik zu Beispiel 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1 Metadaten der Kombinationsdaten . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Metadaten der Presskraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3 Toleranzbereiche fur Pressoperationen . . . . . . . . . . . . . . . . . . . . . . . 53
6.4 Sollwerte und Toleranzbereiche fur Schrauboperationen . . . . . . . . . . . . . . 54
6.5 Metadaten der Schraubkraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.6 Metadaten der Shim-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.7 Metadaten der Ausschleusungsdaten . . . . . . . . . . . . . . . . . . . . . . . . 58
6.8 Die Tabelle TRANSMISSION . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.9 Die Tabelle STATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.10 Die Tabelle SCREWING OPERATION . . . . . . . . . . . . . . . . . . . . . . 62
6.11 Die Tabelle PRESSING OPERATION . . . . . . . . . . . . . . . . . . . . . . . 62
6.12 Die Tabelle LIMIT SCREWING . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.13 Die Tabelle SCREWING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.14 Die Tabelle LIMIT PRESSING . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.15 Die Tabelle PRESSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.16 Die Tabelle SHIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.17 Die Tabelle ERROR MEASUREMENT . . . . . . . . . . . . . . . . . . . . . . 66
6.18 Die Tabelle ERROR SHIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.19 Die Tabelle ERROR COMBINATION . . . . . . . . . . . . . . . . . . . . . . . 67
v
TABELLENVERZEICHNIS vi
6.20 Die Tabelle SYSTEM PARAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.21 Die Tabelle IMPORT COMBINATION . . . . . . . . . . . . . . . . . . . . . . 69
6.22 Die Tabelle COMBINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.23 Die Tabelle IMPORT MEASUREMENT . . . . . . . . . . . . . . . . . . . . . 73
A.1 Codes zur Identifizierung der Qualitatsmerkmale . . . . . . . . . . . . . . . . . 89
A.2 Von einer DFQ-Datei zu untersutzende Schlusselfelder eines Qualitatsmerkmals . 89
Kapitel 1
Einleitung
1.1 Ziel der Arbeit
Aufgrund der hohen Kundenerwartung und der in der EU geltenden Gewahrleistungspflicht sind
die Automobilhersteller bemuht, qualitativ hochwertige Produkte zu liefern. Denn hohe Produkt-
qualitat halt die Zahl der Beanstandungen seitens der Kunden gering, erhoht damit die Kundenzu-
friedenheit und spart erhebliche Kosten ein. Da hohe Produktqualitat schließlich einen wichtigen
Wettbewerbsvorteil darstellt, bekommt die Qualitatssicherung einen immer hoheren Stellenwert.
Im Zuge der Verbesserung der Qualitatssicherung bauen die Unternehmen ihre Qualitatsmanage-
mentsysteme aus. Ein IT-gestutztes Qualitatsmanagementsystem zur durchgehenden Produktions-
kontrolle in der Serienfertigung ermoglicht es, Ruckmeldungen aus dem Fertigungsprozess in die
zukunftige Fertigung einzubeziehen, so dass ein kontinuierlicher Qualitatsuberprufungs- und Ver-
besserungsprozess sichergestellt wird. Um die Einflussfaktoren der Produktion auf das Produkt
zu erkennen, werden qualitatsrelevante Prozessdaten des Fertigungsprozesses erfasst, gespeichert
und durch anschließendes Data Mining analysiert. Beim Data Mining handelt es sich um einen
automatisierten Prozess, der große Datenbestande anhand von statistischen Verfahren und Tech-
niken des maschinellen Lernens nach signifikanten Mustern und Trends durchsucht, die sonst
unerkannt geblieben waren. Data Mining kann als zentrale Phase eines als Knowledge Discove-
ry in Databases (KDD) bezeichneten Prozesses aufgefasst werden. Dieser nicht-triviale Prozess
enthalt u. a. eine Phase zur Interpretation und Konsolidierung von Mining-Ergebnissen. Die in
dieser Phase gewonnenen Erkenntnisse konnen moglicherweise Anreize fur spatere Maßnahmen
zur Qualitatsverbesserung darstellen.
Im Rahmen der Qualitatssicherung in der Getriebemontage bei der Opel Powertrain GmbH wer-
den im Getriebewerk in Russelsheim an den einzelnen Montage-Stationen qualitatsrelevante Pro-
zessdaten erfasst und lokal gespeichert. Die durch die lokale Datenspeicherung verursachte Ver-
teilung der Prozessdaten auf die einzelnen Montage-Stationen erschwert jedoch einfache Datenab-
1
KAPITEL 1. EINLEITUNG 2
fragen und verhindert eine ganzheitliche Sicht auf die Prozessdaten, so dass umfassendere Daten-
analysen nicht moglich sind. Daher ist es erforderlich, die an den Montage-Stationen anfallenden
Prozessdaten auf einem zentralen Server zusammenzufuhren und in ein einheitliches Datensche-
ma zu integrieren. Infolge dessen wird ein schnellerer und genauerer Mining-Prozess ermoglicht,
da die Daten auf einer einheitlichen Basis vorliegen.
Eine erfolgreiche Integration von Daten verschiedener Quellen erfordert im Allgemeinen eine
Konsolidierung der Quelldaten. Zum einen ist haufig die Homogenisierung der Daten erforder-
lich, um die mitunter in unterschiedlichen Formaten gespeicherten Daten aneinander anzuglei-
chen und an die gemeinsame, in der Regel normalisierte, Zieldatenbank auf dem zentralen Server
anzupassen. Zum anderen bedarf es einer Bereinigung der Quelldaten, da die Daten haufig mit
Datenmangeln unterschiedlicher Art behaftet sind. Typische Datenmangel sind beispielsweise:
• Inkorrekte Angaben, verursacht durch Eingabe-, Mess- oder Verarbeitungsfehler
• Logisch widerspruchliche Angaben
• Fehlende Angaben
• Duplikate im Datenbestand
Die Ursachen fur Datenmangel oben genannter Art sind vielfaltig. In der Regel wird jedoch die
Qualitat der Daten maßgeblich durch die Datenerfassungsphase im Quellsystem bestimmt. Wird
die Datenerfassung beispielsweise von einer Person durchgefuhrt, so konnen durch mangelnde
Fertigkeiten oder mangelnde Konzentration des Datenerfassers falsche Daten gespeichert werden.
Aber auch bei der automatischen Datenerfassung konnen durch defekte oder unzureichend justier-
te Messgerate falsche Daten geliefert werden. Schließlich konnen unzureichende Eingabekon-
trollen oder mangelhafte Datenverarbeitungsprozesse, die der Erfassung nachgeschaltet sind, Da-
tenmangel wie etwa fehlende Daten, logisch widerspruchliche Daten oder Duplikate begunstigen.
In der Datenubertragungsphase, in der die Datenbestande von den Quellsystemen zum Server
ubertragen werden, konnen Datenmangel aus technischen Fehlern (z. B. Netzwerkfehlern) so-
wie fehlerhaften Datenverarbeitungsprozessen zur Vor- bzw. Nachbereitung der Datenubertragung
(z. B. Export aus einer Datenbank) resultieren.
Da Datenmangel oben genannter Art die Ergebnisse statistischer Verfahren verfalschen, haben sie
einen negativen Einfluss auf die Ergebnisse aus den Data Mining-Analysen, was wiederum in-
nerhalb des KDD-Prozesses zu falschen Schlussfolgerungen in der Phase der Interpretation und
Konsolidierung von Mining-Ergebnissen fuhren kann. Weil demnach Datenmangel den effekti-
ven Nutzen der Daten vermindern konnen, ist der Prozess der Datenbereinigung mittlerweile ein
elementarer Bestandteil der Datenintegration geworden. Der Datenbereinigungsprozess umfasst
KAPITEL 1. EINLEITUNG 3
samtliche Maßnahmen, fehlerhafte Daten zu erkennen und zu beseitigen, um die Qualitat der Da-
ten zu erhohen. Aufgrund der großen Datenmengen, die gewohnlicher Weise erzeugt werden, ist
es unvermeidlich, die Datenbereinigung weitestgehend automatisiert durchzufuhren.
Ziel dieser Arbeit ist es, fur das Getriebewerk der Opel Powertrain GmbH in Russelsheim ein
System zu entwickeln, welches kontinuierlich neu erfasste Prozessdaten konsolidiert und in eine
zentrale Datenbank schreibt, um damit eine einheitliche Basis fur Datenanalysen zu schaffen. Mit
dem Ziel einer fruhzeitigen und automatisierten Fehlererkennung soll das System Fehler behaftete
Prozessdaten aussortieren und in einen Fehler-Report schreiben.
1.2 Umfeld der Arbeit
1.2.1 Die Opel Powertrain GmbH
Seit Juli 2001 ist die Opel Powertrain GmbH ein Tochterunternehmen der Fiat-GM-Powertrain.
Die Verwaltungszentrale der Fiat-GM-Powertrain befindet sich in Turin. Russelsheim ist Ent-
wicklungs- und Produktionsstandort fur Getriebe und Antriebstechnik mit ca. 1.750 Mitarbei-
tern. Insgesamt beschaftigt die Fiat-GM-Powertrain 24.000 Mitarbeiter an 17 Fertigungsstand-
orten und 7 Forschungs- und Entwicklungszentren in neun Landern Europas, Afrikas, Asiens und
Sudamerikas. Die Jahresproduktion umfasst ca. 5 Millionen Getriebe und ca. 5 Millionen Motor-
en. Der Jahresumsatz belauft sich auf insgesamt 7 Milliarden Euro. Die Fiat-GM-Powertrain ist
damit das weltweit großte eigenstandige Unternehmen auf dem Antriebssektor. Zu den Kunden
zahlen u. a. Alfa Romeo, Fiat, Chevrolet, Cadillac, Lancia, Opel, Saab und Vauxhall.
1.2.2 Das Getriebewerk in Russelsheim
Im Russelsheimer Getriebewerk werden gegenwartig ausschließlich F40-Getriebe in verschieden-
en Ausfuhrungen (Typen) produziert. Das F40-Getriebe ist ein 6-Gang-Schaltgetriebe fur lei-
stungsstarke Frontantriebe. Die Typenvielfalt wird durch die Erfullung von individuellen Kun-
denwunschen (z. B. Ubersetzung, Materialbeschaffenheit bestimmter Teile, etc.) verursacht. Der
grundlegende Aufbau des Getriebes und damit auch der Montageprozess sind jedoch bei allen
Typen identisch. Abbildung 1.1 stellt den grundlegenden Aufbau des Getriebes dar, die zentralen
Komponenten des Getriebes sind das Differential in Kombination mit dem Stirnrad, die untere und
die obere Hauptwelle, die Antriebswelle sowie das Getriebe- und das Kupplungsgehause.
Abbildung 1.2 zeigt den schematischen Aufbau des Getriebewerks. Im Logistikbereich werden die
Rohteile aus der Schmiede angeliefert, die dann entsprechend ihrer Verwendung auf die Wellen-
fertigung oder Zahnradfertigung verteilt werden. Anschließend werden die bearbeiteten Rohteile
der Harterei zugefuhrt. In der Harterei werden die Teile durch eine Warmebehandlung gehartet.
Dieser Prozess ist notwendig, da ungehartete Teile den hohen Kraften, die in einem Getriebe auf-
KAPITEL 1. EINLEITUNG 4
Abbildung 1.1: Aufbau des F40-Getriebes
treten, nicht standhalten wurden. Nach der Behandlung in der Harterei und anschließend erfolgter
Prazisionsnachbearbeitung werden die Teile in den Montagebereich transportiert, wo sie zu einem
voll funktionsfahigen Getriebe zusammengesetzt werden. Die vorliegende Arbeit beschrankt sich
ausschließlich auf den Bereich der Datenerfassung im Montagebereich.
1.3 Inhaltsuberblick
Nach dieser Einleitung wird in Kapitel 2 eine Bestandsaufnahme durchgefuhrt. Dabei wird jenes
Wissen uber den Aufbau der Montagelinie sowie uber die verschiedenen Ablaufe in der Montage-
linie vermittelt, welches zum Verstandnis spaterer Diskussionen fuhrt.
In Kapitel 3 werden die Anforderungen seitens der Opel Powertrain GmbH an das zu entwickeln-
de System beschrieben.
Kapitel 4 geht zunachst auf die Datenerfassung an den Montage-Stationen sowie auf die Verfah-
rensweise bei der Ubertragung der Daten von den Montage-Stationen zum Server ein. Anschlie-
ßend werden die Dateiformate, die bei der Datenubertragung zur Anwendung kommen, beschrie-
ben.
Kapitel 5 befasst sich mit den notwendigen Grundlagen zur Datenkonsolidierung. Der Begriff der
Datenqualitat wird prazisiert und die verschiedenen Datenmangel, die fur die Verringerung der Da-
tenqualitat verantwortlich sein konnen, werden genauer erlautert. Abschließend werden mogliche
KAPITEL 1. EINLEITUNG 5
Abbildung 1.2: Schematischer Aufbau des Getriebewerks
Methoden zur Datenbereinigung sowie eine allgemeingultige Vorgehensweise zur Datenkonsoli-
dierung beschrieben.
In Kapitel 6 wird die zuvor beschriebene Vorgehensweise zur Datenkonsolidierung auf den vorlie-
genden Anwendungsfall angewendet und eine Losung fur das zu entwickelnde System diskutiert.
Kapitel 7 geht auf die Implementierung der realisierten Losung ein.
Kapitel 8 erlautert die Vorgehensweise sowie die erzielten Ergebnisse bei den durchgefuhrten Tests
der Implementierung.
Abschließend wird in Kapitel 9 ein Fazit gezogen.
Kapitel 2
Bestandsaufnahme
In diesem Kapitel werden zunachst die notwendigen Grundlagen aus dem Maschinenbau erlautert
(Abschnitte 2.1 und 2.2). Anschließend werden der grobe Ablauf des Montageprozesses (Ab-
schnitt 2.3) sowie der Aufbau einer Montage-Station (Abschnitt 2.4) und eines Operationsstandes
(Abschnitt 2.5) beschrieben. Außerdem wird auf die Prozessdatenerfassung in der Montagelinie
eingegangen (Abschnitt 2.6). Abschließend werden die vorkommenden Abweichungen vom Mon-
tageprozess erlautert, da diese Einfluss auf die Erfassung der Prozessdaten haben (Abschnitt 2.7).
2.1 Verbindungstechniken in der Getriebemontage
Bei der Getriebemontage werden die einzelnen Teile auf zwei verschiedene Arten miteinander
verbunden. Bei den beiden Verbindungsarten handelt es sich um Press- sowie Schraubenverbin-
dungen.
Pressverbindungen
Wie in Abbildung 2.1 angedeutet, werden bei einer Pressverbindung zwei Teile zusammengefugt,
indem sie mithilfe einer Presse ineinander gepresst werden. Wahrend vor dem Pressvorgang zwi-
schen dem Außen- und dem Innenteil einUbermaß besteht, wirkt nach dem Pressvorgang aufgrund
der Werkstoffpressung in der Fugeflache zwischen beiden Teilen eine Haftkraft, durch die die bei-
den Teile zusammengehalten werden [9]. Der Krafteverlauf eines Pressvorgangs lasst sich durch
ein Kraft-Weg-Diagramm (siehe Abbildung 2.2) beschreiben, welches die aufgewendete Anpress-
kraft in Abhangigkeit des vom Pressstempel zuruckgelegten Weges angibt. Im Rahmen der Qua-
litatssicherung ist insbesondere die aufgewendete Kraft bei Abschluss des Pressvorgangs von Be-
deutung. Da das exakte Erreichen des Sollwertes aus technischen Grunden nicht moglich ist, wird
fur die aufzuwendende Anpresskraft ein Toleranzbereich festgelegt, der beim Pressvorgang ein-
gehalten werden muss. Wahrend das Uberschreiten der oberen Toleranzgrenze zur Beschadigung
6
KAPITEL 2. BESTANDSAUFNAHME 7
Abbildung 2.1: Einpressung einer Welle
der entsprechenden Teile fuhren kann, hat das Unterschreiten der unteren Toleranzgrenze einen
ungenugenden Zusammenhalt der Teile zur Folge.
Schraubenverbindungen
Eine Schraubenverbindung ist eine losbare Verbindung von Teilen durch eine oder mehrere Schrau-
ben. Wird eine Kopfschraube angezogen, dann entsteht eine Zugkraft (Vorspannkraft) �� in der
Schraube und eine gleich hohe Druckkraft zwischen den zu verschraubenden Teilen. Beim Drehen
der Schraube mussen das mit �� steigende Reibungsmoment im Gewinde und das Reibungsmo-
ment unterhalb des Kopfes uberwunden werden [9]. Die Summe der beiden Momente ergeben
das Anziehdrehmoment, welches fur die Qualitatssicherung eine relevante Große darstellt. Wie
bei einem Pressvorgang lasst sich auch der Krafteverlauf eines Schraubvorgangs durch ein Kraft-
Weg-Diagramm beschreiben. Es zeigt das aufgewendete Drehmoment in Abhangigkeit der vom
Schrauber durchgefuhrten Drehbewegung. Bei einem Schraubvorgang ist es wichtig, dass das auf-
gewendete Drehmoment bei Abschluss des Schraubvorgangs in einem fest definierten Toleranzbe-
reich liegt. Ein zu geringes Anziehdrehmoment kann dazu fuhren, dass mogliche Relativbewegun-
gen der Teile gegeneinander nicht genugend verhindert werden. Ein zu hohes Anziehdrehmoment
kann eine Beschadigung der Schraube oder des Gewindes und somit ein Versagen der Schrauben-
verbindung zur Folge haben.
2.2 Shims
Aufgrund der Getriebekonstruktion und der Maßtoleranzen bei der Fertigung der einzelnen Getrie-
beteile existiert langsseitig zwischen den drei existierenden Wellen (Antriebswelle, Obere Haupt-
welle, Untere Hauptwelle) und der Gehausewand sowie zwischen dem Differentialgehause und der
KAPITEL 2. BESTANDSAUFNAHME 8
Abbildung 2.2: Kraft-Weg-Diagramm einer Pressvorgangs
Gehausewand jeweils ein Spiel. Um diese Spiele auszugleichen, wird zwischen den eben genann-
ten Teilen und der Gehausewand jeweils eine Scheibe (Shim) eingesetzt, die in etwa vergleichbar
mit einer Unterlegscheibe fur Schrauben ist. Insgesamt existieren 25 verschiedene Shim-Großen,
die zum Ausgleich vorhandener Spiele verwendet werden konnen.
2.3 Aufbau der Montagelinie
Abbildung 2.3 zeigt das Layout der Montagelinie. Die weißen Rechtecke stellen Stationen dar,
an denen Getriebe oder Getriebekomponenten von Maschinen bearbeitet werden. Bei der Bear-
beitung werden uberwiegend Schraub- und Pressoperationen durchgefuhrt. In dieser Arbeit wird
unter einer Schrauboperation ein einzelner Schraubvorgang und unter einer Pressoperation ein
einzelner Pressvorgang verstanden. Die grauen Rechtecke skizzieren Operationsstande, an denen
Schrauboperationen oder sonstige Tatigkeiten von einer Person durchgefuhrt werden.
Die Montagelinie gliedert sich in drei Verkettungsabschnitte. Wahrend der Verkettungsabschnitt 1
(VK1) die Vormontage des Differentials und der verschiedenen Wellen umfasst, werden im Ver-
kettungsabschnitt 2 (VK2) die Vormontage des Getriebe- und des Kupplungsgehauses sowie die
Endmontage des Getriebes durchgefuhrt. Der Verkettungsabschnitt 3 (VK3) dient zur Endkontrol-
le des Getriebes sowie zur Durchfuhrung einiger abschließender Arbeiten am Getriebe.
KAPITEL 2. BESTANDSAUFNAHME 9
Abbildung 2.3: Layout der Montagelinie
KAPITEL 2. BESTANDSAUFNAHME 10
Ein Ausgangspunkt der Montagelinie sind die Stationen ST010 und ST011, die fur die Vormon-
tage des Differentials zustandig sind. Beide fuhren exakt die gleichen Montageschritte durch und
laufen wahlweise im Einzel- oder im Doppelbetrieb. Jedes montierte Differential gelangt uber ein
Laufband zur Station ST040, an der das Stirnrad montiert wird. Dabei werden jeweils ein Differ-
ential und ein Stirnrad miteinander verschraubt. Jedes montierte Stirnrad wird jeweils auf einer
separaten Palette, die an den nachfolgenden Stationen jeweils mit einer weiteren Getriebekompo-
nente bestuckt wird, abgelegt. Jede der drei nachfolgenden Stationen ST060, ST070 und ST080
ist fur die Vormontage genau eines Wellentyps (Untere Hauptwelle, Obere Hauptwelle, Antriebs-
welle) zustandig. Bei der Wellenvormontage werden im Wesentlichen die Zahnrader der einzelnen
Gange auf die Wellen aufgepresst. Nach Durchlaufen der Station ST080 verfugt jede Palette uber
ein Differential, welches mit einem Stirnrad verbunden ist, sowie uber drei verschiedene Wellen
und damit uber einen kompletten Wellensatz, der fur das Innenleben eines Getriebes erforderlich
ist.
Ein weiterer Ausgangspunkt der Montagelinie ist die Station ST110. Wahrend an der Station
ST110 die Vormontage des Getriebegehauses erfolgt, wird an der Station ST120 die Vormonta-
ge des Kupplungsgehauses durchgefuhrt. Bei der Vormontage dieser beiden Gehausekomponenten
werden insbesondere Dichtungsringe in die verschiedenen Gehauseoffnungen eingepresst. Zusam-
mengesetzt bilden die beiden Gehausekomponenten das komplette Gehause eines Getriebes. Die
Getriebe- und Kupplungsgehause werden jeweils auf separaten Paletten in abwechselnder Reihen-
folge in die Station ST140 eingeschleust.
Die Laufbander der beiden Ausgangspunkte der Montagelinie munden in die Station ST140, an
der die Endmontage des Getriebes beginnt. Sobald jeweils eine Palette mit einem kompletten
Wellensatz aus der Wellenvormontage sowie eine Palette mit einem Kupplungsgehause aus der
Gehausevormontage eingeschleust wurden, wird der Wellensatz in das Kupplungsgehause einge-
bracht und die bei diesem Vorgang frei werdende Palette ausgeschleust. Das auf einer weiteren Pa-
lette aus der Gehausevormontage folgende Getriebegehause wird im weiteren Verlauf unmittelbar
hinter der Palette des Kupplungsgehauses mit dem inzwischen eingebrachten Wellensatz transpor-
tiert, um an der Station ST190 zum Verschließen des Getriebes verwendet zu werden. Aufgrund
dieses Prozessablaufs entscheidet sich an der Station ST140 aus welchen Wellen und aus wel-
chen Gehausekomponenten ein Getriebe zusammengesetzt wird. An der darauf folgenden Station
ST150 werden durch Ermitteln der vorhandenen Spiele die benotigten Shim-Großen ermittelt. Der
Einbau der entsprechenden Shims wird an der Station ST160 durchgefuhrt. Außerdem wird an die-
ser Station das Einstellen der Lager vorgenommen. An der Station ST190 werden nach erfolgtem
Dichtmittelauftrag die beiden Gehausekomponenten zusammengeschraubt. Wahrend am Operati-
onsstand OP210 gegebenenfalls Korrekturen der Gehauseverschraubungen durchgefuhrt werden,
wird am Operationsstand OP220 die Schaltmechanik montiert.
KAPITEL 2. BESTANDSAUFNAHME 11
Im Verkettungsabschnitt 3 werden an den Stationen ST250, ST260 und ST270 akustische End-
kontrollen durchgefuhrt, bei denen das montierte Getriebe im laufenden Betrieb getestet wird. Die
darauf folgenden Stationen sind fur einige abschließende Arbeiten zustandig, wie beispielsweise
die Olaufbereitung sowie das Einlasern der Getriebe-Seriennummer in das Getriebegehause. Als
letzte Tatigkeit wird an der Station ST300 ein Etikett mit der Getriebe-Seriennummer gedruckt,
welches anschließend zur logistischen Erfassung des Getriebes eingescannt wird. Von diesem Mo-
ment an steht das fertig montierte Getriebe dem Vertrieb zur Verfugung.
2.4 Aufbau einer Montage-Station
An jeder Montage-Station befinden sich verschiedene Fugevorrichtungen, deren Art und Anzahl
von den durchzufuhrenden Operationen abhangt. Fur Schrauboperationen existieren ausschließ-
lich Schraubvorrichtungen der Firma Bosch und fur Pressoperationen ausschließlich Pressvorrich-
tungen der Firma Promess. Jede Fugevorrichtung verfugt wiederum uber mindestens eine Spindel,
die je nach Art der Fugevorrichtung ein einzelner Schrauber oder ein einzelner Pressstempel ist.
Jeder Spindel ist eine Spindelnummer zugewiesen, dazu werden die Press- und Schraubspindeln
einer Montage-Station jeweils von � bis � durchnummeriert. Eine eindeutige Spindelnummernzu-
ordnung, uber alle Press- und Schraubspindeln einer Montage-Station betrachtet, existiert nicht.
Abgesehen von ein paar Ausnahmen bei den Pressspindeln, bei denen Verpressungen in zwei
Schritten durchgefuhrt werden, wird jedes Teil genau einmal von ein und derselben Spindel be-
arbeitet. Erfolgt eine Verpressung in zwei Schritten, so kann jeder Schritt als eine eigene Press-
operation aufgefasst werden. Jede Spindel ist mit einem Steuergerat verbunden, welches fur die
Steuerung der entsprechenden Spindel und zum Empfangen der an dieser Spindel anfallenden Pro-
zessdaten verantwortlich ist.
Des Weiteren ist jede Station mit einem gewohnlichen Rechner (Microsoft WindowsNT 4.0) aus-
gestattet, der uber ein lokales 10MBit-Netzwerk mit dem zentralen Server verbunden ist. In je-
dem Rechner ist eine speicher-programmierbare Steuereinheit (SPS) eingebaut, die wiederum mit
den an der Montage-Station befindlichen Steuergeraten verbunden ist. Eine SPS ist ein Automa-
tisierungsgerat, welches die autarke Steuerung des gesamten Montageprozesses an der Montage-
Station ubernimmt. Uber eine Steuerungssoftware auf dem Rechner der Montage-Station konnen
jeder Spindel die Sollwerte sowie die Toleranzbereiche fur Weg (Drehwinkel/Einpresstiefe) und
Kraft (Drehmoment/Einpresskraft) zugewiesen werden.
2.5 Aufbau eines Operationsstands
Operationsstande dienen insbesondere der Durchfuhrung kleinerer Reparaturen an Werkstucken.
Beispielsweise kann am Operationsstand OP050 eine Verschraubung von einem Arbeiter korrigiert
werden, wenn diese zuvor an der Station ST040 aus irgendwelchen Grunden nicht zufriedenstel-
KAPITEL 2. BESTANDSAUFNAHME 12
Feldname Felddatentyp BeschreibungID OPEL Text Getriebe-SeriennummerID SAAB Text Kunden-Seriennummer (SAAB)ID FIAT Text Kunden-Seriennummer (FIAT)TIMESTAMP Datum/Uhrzeit Zeitpunkt der ErfassungV ID1 Text Virtuelle Kennung: Stirnrad/Differential (ST040)V ID2 Text Virtuelle Kennung: Untere Hauptwelle (ST060)V ID3 Text Virtuelle Kennung: Obere Hauptwelle (ST070)V ID4 Text Virtuelle Kennung: Antriebswelle (ST080)V ID5 Text Virtuelle Kennung: Getriebegehause (ST110)V ID6 Text Virtuelle Kennung: Kupplungsgehause (ST120)
Tabelle 2.1: Aufbau der Kombinationstabelle
lend durchgefuhrt wurde. Die Verschraubung erfolgt in diesem Fall mit einem Handschrauber. Am
Operationsstand OP090 besteht die Moglichkeit, auf einer Palette eine fehlerhafte Getriebekompo-
nente aus der Wellenvormontage auszutauschen. Das Austauschen einer Welle ist beispielsweise
dann notwendig, wenn bei der besagten Welle das Aufpressen eines Zahnrades in einer der zuvor
durchlaufenen Stationen fehlgeschlagen ist. Eine Reparatur von fehlerhaften Verpressungen er-
folgt grundsatzlich nicht, stattdessen werden die betroffenen Teile ausgetauscht und verschrottet.
2.6 Erfassung von Prozessdaten
Jeweils zu Beginn der Montage eines Stirnrades (Station ST040) und der Vormontage einer Welle
(Stationen ST060, ST070 und ST080) sowie der Vormontage einer Gehausekomponente (Statio-
nen ST110 und ST120) weist die jeweilige Montage-Station der entstehenden Komponente eine
achtstellige Seriennummer zu, die als virtuelle Kennung bezeichnet wird. Jede Montage-Station
verwendet dabei ein eigenes Nummernband. Die erzeugte Kennung wird auf einen elektronischen
Datentrager unterhalb der Palette geschrieben, auf der die Komponente abgelegt wird. Der Daten-
trager ist in der Lage, die Seriennummern samtlicher auf der Palette befindlichen Teile zu spei-
chern.
Sobald an der Station ST140 die fur ein Getriebe notwendigen Komponenten aus der Vormontage
kombiniert werden, wird dem in diesem Moment entstehenden Getriebe eine Getriebe-Seriennum-
mer zugewiesen. Ist das Getriebe fur die Kunden Saab oder Fiat vorgesehen, so erhalt das Getriebe
zusatzlich zur Getriebe-Seriennummer eine Kunden-Seriennummer. Die virtuellen Kennungen auf
den Datentragern der drei Paletten aus der Vormontage werden ausgelesen und zusammen mit der
zugewiesenen Getriebe-Seriennummer und ggf. der Kunden-Seriennummer in eine Tabelle einer
Microsoft Access-Datenbank geschrieben, deren Aufbau in Tabelle 2.1 dargestellt ist. Damit lasst
sich fur jedes Getriebe nachvollziehen, aus welchen Komponenten es zusammengesetzt wurde.
Mit Ausnahme der Palette, die nach Einbringung des Wellensatzes in das Kupplungsgehause aus-
KAPITEL 2. BESTANDSAUFNAHME 13
geschleust wird, werden die virtuellen Kennungen auf den Datentragern der Paletten durch die
zugewiesene Getriebe-Seriennummer ersetzt. Von diesem Zeitpunkt an hat nur noch die Getriebe-
Seriennummer Gultigkeit.
Wahrend der Bearbeitung einer Komponente bzw. eines Getriebes durch eine Montage-Station
sendet die SPS uber einen Datenbus Steuerbefehle an die Steuergerate der einzelnen Spindeln,
dabei wird auch die Seriennummer des zu bearbeitenden Teils ubermittelt. Wie bereits erwahnt,
wird in der Vormontage die Seriennummer an der jeweiligen Montage-Station selbst erzeugt, in
der Endmontage wird die Seriennummer des bearbeiteten Getriebes aus dem Datentrager unter-
halb der Palette ausgelesen. Die an den Steuergeraten anfallenden Prozessdaten werden samt der
Seriennummer des bearbeiteten Teils direkt von dem jeweiligen Steuergerat an den Rechner der
Montage-Station gesendet. Prozessdaten einer fehlgeschlagenen Operation werden dabei mit ei-
nem entsprechenden Fehlercode versehen. Die auf dem Rechner installierte Steuerungssoftware
speichert die von den Steuergeraten empfangenen Prozessdaten im lokalen Dateisystem. Handelt
es sich bei den Prozessdaten um Daten einer Schrauboperation, so werden die Werte in dem von
der Firma Aton GmbH entwickelten Datenbankformat Nexum gespeichert. Prozessdaten einer
Pressoperation werden dagegen in eine Microsoft Access-Datenbank geschrieben. Die eben ge-
nannten Datenhaltungssysteme fur die Prozessdaten von Schraub- und Pressoperationen werden
an dieser Stelle nicht weiter beschrieben, da sie im Rahmen dieser Arbeit nicht weiter verwendet
werden sollen (vgl. Abschnitt 4.1).
2.7 Abweichungen vom normalen Montageprozess
Aufgrund von Ausfallen von Fugevorrichtungen oder aufgrund von fehlgeschlagenen Operationen
kann es zu Abweichungen vom normalen Montageprozess kommen. Da diese Umstande Einfluss
auf die Datenerfassung haben, werden diese kurz beschrieben:
• Kommt es zu einem Ausfall einer Schraubvorrichtung, fuhren die Arbeiter die Verschrau-
bungen mithilfe eines Handschraubers durch. Wie bei der Durchfuhrung einer Verschrau-
bung an einem Operationsstand, erfolgt in diesem Fall keine Erfassung der zugehorigen
Prozessdaten.
• Wie in Abschnitt 2.5 erwahnt, kann am Operationsstand OP090 ein Austausch einer Getrie-
bekomponente erfolgen. In diesem Fall wird die virtuelle Kennung der ausgetauschten Kom-
ponente auf dem Datentrager der Palette nicht durch die Kennung der neuen Komponente
ersetzt. Stattdessen erhalt das Datenfeld auf dem Datentrager lediglich den Wert”99999999“
um den Austausch der Komponente als Solchen zu erfassen. Eine Ruckverfolgung von Pro-
zessdaten fur die Ersatzkomponente ist demnach nicht mehr moglich.
KAPITEL 2. BESTANDSAUFNAHME 14
• Falls innerhalb des Verkettungsabschnittes 2 eine Pressoperation fehlschlagt, wird das be-
troffene Getriebe ausgeschleust und wahlweise repariert oder verschrottet. Im Falle einer
Reparatur wird das defekte Teil durch ein intaktes Teil ersetzt und das Getriebe anschlie-
ßend wieder eingeschleust. Der Austausch des defekten Teils wird DV-technisch nicht er-
fasst. Im Falle einer Verschrottung wird das Getriebe komplett auseinander gebaut. Wahrend
die defekten Teile verschrottet werden, dienen die intakten Teile zukunftig als Ersatzteile.
Kapitel 3
Anforderungen
Die Aufgabenstellung in der vorliegenden Arbeit ist in Kapitel 1 erlautert. Es sollen qualitatsre-
levante Merkmale der in der Montagelinie anfallenden Prozessdaten erfasst, uber das Netzwerk
auf einen zentralen Server ubertragen und in konsolidierter Form in einer Datenbank gespeichert
werden. Die genauen Anforderungen seitens der Opel Powertrain GmbH an das zu entwickelnde
System werden in diesem Kapitel beschrieben.
3.1 Relevante Daten
Es existieren drei verschiedene Arten von Daten, die im Rahmen der Qualitatssicherung relevant
sind und als Qualitatsdaten bezeichnet werden. Es handelt sich dabei um Schraub- und Presskraft-
daten sowie Shim-Daten.
3.1.1 Schraubkraftdaten
Zu einer Schrauboperation sollen folgende Merkmale erfasst werden:
• Getriebe-Seriennummer und Kunden-Seriennummer
• Stationsnummer und Spindelnummer
• Endstand des Drehwinkels
• Endstand des Anziehdrehmoments
• Aktuell geltender unterer und oberer Grenzwert fur den Endstand des Drehwinkels
• Aktuell geltender unterer und oberer Grenzwert fur den Endstand des Anziehdrehmoments
• Zeitpunkt der Operation
15
KAPITEL 3. ANFORDERUNGEN 16
3.1.2 Presskraftdaten
Zu einer Pressoperation sollen folgende Attribute erfasst werden:
• Getriebe-Seriennummer und Kunden-Seriennummer
• Stationsnummer, Spindelnummer und Schrittnummer1
• Endstand der Einpresstiefe
• Endstand der Einpresskraft
• Aktuell geltender unterer und oberer Grenzwert fur den Endstand der Einpresstiefe
• Aktuell geltender unterer und oberer Grenzwert fur den Endstand der Einpresskraft
• Zeitpunkt der Operation
3.1.3 Shim-Daten
An der Station ST150 werden die fur ein Getriebe zu verwendenden Shim-Großen ermittelt. Dabei
sollen folgende Attribute erfasst werden:
• Getriebe-Seriennummer und Kunden-Seriennummer
• Shim-Klasse
• Getriebekomponente, fur die das Shim verwendet werden soll
• Zeitpunkt der Erfassung
3.1.4 Ausschleusungsdaten
Erganzend zu den bisher genannten Qualitatsdaten soll der Zeitpunkt erfasst werden, zu dem ein
Getriebe aus der letzten Station (ST300) ausgeschleust wird und damit die Montagelinie ordnungs-
gemaß verlasst.
3.2 Relevante Stationen
Obwohl an allen Stationen in den Verkettungsabschnitten 1 und 2 Press- und/oder Schrauboper-
ationen durchgefuhrt werden, sind im Rahmen der Qualitatssicherung nur die Schraub- und Press-
kraftdaten relevant, die an den in Tabelle 3.1 aufgelisteten Stationen erfasst werden. Zusatzlich
zeigt die Tabelle, uber wie viele Schraub- und Pressspindeln die einzelnen Stationen verfugen.
1Falls eine Verpressung in zwei Schritten durchgefuhrt wird, dient die Schrittnummer zur Unterscheidung der beidenPressoperationen.
KAPITEL 3. ANFORDERUNGEN 17
Station AnzahlSchraub-spindeln
AnzahlPressspin-deln
Montageschritt
ST040 2 1 Montage des StirnradesST110 2 5 Vormontage des GetriebegehausesST120 1 9 Vormontage des KupplungsgehausesST140 1 4 Einpressen der InnenringeST150 - - Ermitteln der zu verwendenden Shim-GroßenST160 - 4 Einstellen der Lager sowie Einbau der ShimsST300 - - Erfassen des Ausschleusungszeitpunktes
Tabelle 3.1: Ubersicht der qualitatsrelevanten Stationen
3.3 Datenkonsolidierung
Bei der Datenkonsolidierung sollen folgende Anforderungen berucksichtigt werden:
• Bei allen Messwerten ist eine Genauigkeit von zwei Stellen nach dem Komma ausreichend.
• Qualitatsdaten, die aufgrund einer fehlgeschlagenen Operation bereits vom Messsystem mit
einem entsprechenden Fehlercode versehen wurden, sollen nicht gespeichert werden. In ei-
nem solchen Fall kann man davon ausgehen, dass die betroffene Operation wiederholt wird
oder das Getriebe ausgeschleust und verschrottet wird.
• Falls eine Operation wiederholt wird, sollen nur jene Daten erfasst werden, die mit der wie-
derholten Durchfuhrung im Zusammenhang stehen. Die Daten des ersten Versuchs sollen
in diesem Fall verworfen werden. Obwohl mehrere Messungen, die das gleiche Getriebe
und die gleiche Operation betreffen, verschiedene Entitaten der Realitat sind, werden die
entsprechenden Datensatze als Duplikate bezeichnet.
• Qualitatsdaten, die aufgrund fehlerhafter Werte nicht gespeichert werden konnen, sollen
in einen Fehler-Report geschrieben werden. Eine Korrektur von falschen oder fehlenden
Werten soll in keinem Fall erfolgen.
• Falls fur ein Getriebe nicht zu allen Operationen ein entsprechender Datensatz vorhanden
ist, so wird dies toleriert.
3.4 Frontend
Es soll ein Frontend zur Verfugung gestellt werden, mit dem der Anwender nach Getrieben suchen
und sich Qualitatsdaten anzeigen lassen kann. Das Frontend soll mit der JSP/Servlet-Technologie
KAPITEL 3. ANFORDERUNGEN 18
realisiert werden. Im Folgenden werden zwei Anwendungsfalle beschrieben, um die Anforder-
ungen an das Frontend zu verdeutlichen.
Anwendungsfall 1
Der Anwender gibt entweder eine vollstandige Seriennummer (Getriebe-Seriennummer oder Kun-
den-Seriennummer) oder die ersten Zeichen der Seriennummer ein und startet die Suche. An-
schließend wird dem Anwender eine Auswahlliste der zur Sucheingabe passenden Seriennummern
angezeigt. Nach Auswahl einer Seriennummer wird dem Anwender eine Liste derjenigen Sta-
tionen angezeigt, zu denen Qualitatsdaten bezuglich des ausgewahlten Getriebes verfugbar sind.
Nach Auswahl einer Station wird dem Anwender die Gesamtheit aller an der Station angefallenen
Qualitatsdaten bezuglich des ausgewahlten Getriebes angezeigt.
Anwendungsfall 2
Der Anwender spezifiziert einen Getriebetyp und/oder einen Zeitraum fur den Ausschleusungs-
zeitpunkt und startet die Suche. Anschließend werden dem Anwender die Seriennummern derje-
nigen Getriebe angezeigt, die alle spezifizierten Suchkriterien erfullen.
3.5 Aufbewahrung der Daten
Die erfassten Qualitatsdaten mussen fur einen Zeitraum von mindestens zwei Jahren aufbewahrt
werden. Diese Anforderung ergibt sich aus den Richtlinien in [8], die eine Grundlage zur ISO-
Zertifizierung darstellen. Angesichts der geplanten Data Mining-Analysen wird jedoch von einem
Aufbewahrungszeitraum von mindestens zehn Jahren ausgegangen.
3.6 Systemumgebung
Die konsolidierten Daten sollen in einer Oracle ��-Datenbank unter Sun Solaris gespeichert wer-
den. Als Programmiersprache soll Java J2SE 1.4 oder hoher verwendet werden. Bei der Imple-
mentierung soll berucksichtigt werden, dass die gesamte Konsolidierung moglichst in einer ei-
genstandigen Applikation erfolgt, um eine schwache Kopplung mit anderen Applikationen auf
dem Server sicherzustellen.
Kapitel 4
Datenerfassung und Datenubertragung
In diesem Kapitel wird zunachst auf die Datenerfassung an den Montage-Stationen (Abschnitt 4.1)
sowie auf die Verfahrensweise bei der Ubertragung der Daten von den Montage-Stationen zum
Server (Abschnitt 4.2) eingegangen. In den darauf folgenden Abschnitten werden die bei der Da-
tenubertragung verwendeten Dateiformate detailliert beschrieben.
4.1 Datenerfassung
Das Auslesen der Schraub- und Presskraftdaten aus den Steuergeraten an den einzelnen Montage-
Stationen erfolgt durch die Steuerungssoftware, die von dem Lieferanten der jeweiligen Fuge-
vorrichtung entwickelt und betrieben wird. Die bisher verwendeten Datenhaltungssysteme an den
Montage-Stationen fur die Schraub- und Presskraftdaten (vgl. Abschnitt 2.6) werden jedoch im
Rahmen dieser Arbeit nicht verwendet. Stattdessen kommt eine Textdateibasierte Datenhaltung
im so genannten Q-DAS ASCII-Transferformat, welches in Abschnitt 4.3.1 naher beschrieben
wird, zur Anwendung. Auf diese Weise wird die Moglichkeit geschaffen, bei Bedarf die Schraub-
und Presskraftdaten der Quellsysteme mit anderweitiger Statistik-Software (z. B. QS-STAT), die
das Q-DAS-Dateiformat als Eingabeformat unterstutzt, zu verarbeiten. Aus technischen Grunden
existiert fur jedes Steuergerat ein Datei-erzeugendes System, so dass die an den einzelnen Steu-
ergeraten einer Montage-Station anfallenden Schraub- und Presskraftdaten jeweils in separaten
Dateien gespeichert werden. Fur die Erfassung der Kombinationsdaten, der Shim-Daten sowie
der Ausschleusungsdaten sind ebenfalls die Lieferanten der jeweiligen Vorrichtung verantwort-
lich. Zur Erfassung der Kombinationsdaten wird das bestehende Datenhaltungssystem (vgl. Ab-
schnitt 2.6) dahingehend modifiziert, dass das in Abschnitt 4.4 beschriebene Dateiformat erzeugt
wird. Fur Shim-Daten und Ausschleusungsdaten bestehen zum Bearbeitungszeitpunkt der Arbeit
noch keine Datenhaltungssysteme. Fur diese Datenarten wird jeweils ein Datei-erzeugendes Sys-
tem eingerichtet. Die Dateiformate, die dabei zur Anwendung kommen, werden in den Abschnit-
ten 4.5 und 4.6 beschrieben.
19
KAPITEL 4. DATENERFASSUNG UND DATENUBERTRAGUNG 20
Station Anzahl Datei-erzeugende Syste-me
Anzahl Dateien(periodisch, Peri-odendauer: achtStunden)
Anzahl Dateien(sofort)
ST040 5 5 1750ST110 6 6 2100ST120 10 10 3500ST140 5 5 1750ST150 1 1 350ST160 4 4 1400ST300 1 1 350
Tabelle 4.1: Anzahl erzeugter Dateien in einem Zeitraum von acht Stunden bei einer Durchsatzratevon 350 Getrieben in acht Stunden)
4.2 Periodische versus sofortige Datenubertragung
Die Ubertragung der an den Montage-Stationen anfallenden Daten zum Server erfolgt automati-
siert in Form von Textdateien mittels des File-Transfer-Protocols (FTP). Zu Beginn dieser Arbeit
ist ungeklart, ob die Datenubertragung sofort oder periodisch erfolgen soll. Andere Verfahrenswei-
sen sind aus technischen und unternehmenspolitischen Grunden von vornherein ausgeschlossen.
Unter der sofortigen Datenubertragung wird in dieser Arbeit eine Verfahrensweise verstanden, bei
der eine Datenubertragung zum Server ausgelost wird, sobald in einem Steuergerat alle Daten
bezuglich eines bearbeiteten Teils eingetroffen sind. Dies bedeutet, dass fur jedes bearbeitete Teil
eine separate Quelldatei erzeugt wird, die sofort nach Speicherung der entsprechenden Daten ab-
geschlossen und zum Server ubertragen wird.
Unter der periodischen Datenubertragung wird in dieser Arbeit eine Verfahrensweise verstanden,
bei der die Datenubertragung zum Server in periodischen Zeitabstanden erfolgt. Dazu werden
alle Daten, die wahrend einer definierten Zeitperiode in einem Steuergerat eintreffen, in einer Da-
tei gespeichert. Nach Ablauf einer Zeitperiode wird diese Datei abgeschlossen und zum Server
ubertragen.
Vorteile der sofortigen Datenubertragung sind die geringere Verlustrate der Daten sowie die gleich-
maßigere Auslastung des Netzwerkes. Nachteilig wirkt sich jedoch das hohe Dateiaufkommen aus,
da als Konsequenz einer sofortigen Datenubertragung pro Steuergerat und bearbeitetem Teil eine
Datei erzeugt wird. Tabelle 4.1 zeigt die Anzahl der innerhalb einer achtstundigen Zeitperiode er-
zeugten Dateien bei einer periodischen Datenubertragung im Vergleich zur Anzahl der im selben
Zeitraum erzeugten Dateien bei einer sofortigen Datenubertragung. Im Falle eines Server- oder
KAPITEL 4. DATENERFASSUNG UND DATENUBERTRAGUNG 21
Netzwerkausfalls mussen die im Zeitraum des Ausfalls erzeugten Dateien im lokalen Dateisys-
tem des Rechners an der Montage-Station gepuffert werden. Bei der sofortigen Datenubertragung
wurden je nach Dauer des Ausfalls einige hundert oder gar tausend Dateien anfallen, die nach
Behebung des Ausfalls zum Server ubertragen werden mussten. Die Praxis hat gezeigt, dass eine
Montage-Station dazu nicht in der Lage ist. Erfahrungsgemaß kommt es zu einem Rechnerab-
sturz an der betroffenen Montage-Station, was wiederum den Ausfall der Montage-Station und
zuletzt den Ausfall der gesamten Montagelinie zur Folge hatte. Die Instabilitat der Rechner an den
Montage-Stationen wird durch die Steuerungssoftware der Lieferanten verursacht.
Aufgrund der beschriebenen Nachteile, die sich aus einer sofortigen Datenubertragung ergeben,
wird die periodische Datenubertragung gewahlt. Dazu werden samtliche in einem Steuergerat ein-
treffenden Daten in eine Datei geschrieben, die nach Ablauf einer Schicht abgeschlossen und zum
Server ubertragen wird. Als Periodendauer wird die Dauer einer Schicht (acht Stunden) gewahlt,
weil dadurch die Datenubertragung zwischen zwei Schichten erfolgen kann und damit eine Beein-
trachtigung des Montageprozesses an der Montage-Station als Folge der Datenubertragung ausge-
schlossen werden kann.
Die Lieferanten sind damit beauftragt, unter Berucksichtigung der in den folgenden Abschnitten
beschriebenen Anforderungen an die Dateiformate entsprechende Prozesse zur Datenerfassung
und Datenubertragung einzurichten. Die Verantwortung fur alle Prozesse von der Erfassung bis
zur Ablieferung der Daten auf dem Server verbleibt bei der Abteilung Getriebefertigung.
4.3 Ubertragung der Schraub- und Presskraftdaten
Wie bereits erwahnt, erfolgt die Ubertragung der Schraub- und Presskraftdaten im Q-DAS ASCII-
Transferformat, welches im folgenden Abschnitt naher beschrieben wird. Da das Dateiformat
komplex ist, werden dabei lediglich die fur diese Arbeit relevanten Strukturen des Dateiformats
beschrieben. Das Dateiformat ermoglicht es außerdem, denselben Sachverhalt auf verschiedene
Arten im Bezug auf Struktur und Datenreprasentation darzustellen. Die in den folgenden Ab-
schnitten beschriebene Darstellungsweise ist jene, die mit den Lieferanten vereinbart wurde.
4.3.1 Das Q-DAS ASCII-Transferformat
Das Q-DAS ASCII-Transferformat wurde von der Q-DAS GmbH in Zusammenarbeit mit dem
Automobilhersteller Ford entwickelt und in [6] definiert. Motivation fur die Definition des Trans-
ferformates war, ein einheitliches Dateiformat zum Austausch von Qualitatsdaten zwischen ver-
schiedenen Systemen zu bieten. Dabei sollte sich das Dateiformat insbesondere durch folgende
Eigenschaften auszeichnen [6]:
Transparenz Es sollte einen einfachen und transparenten Aufbau haben, welches fur den Anwen-
KAPITEL 4. DATENERFASSUNG UND DATENUBERTRAGUNG 22
Abbildung 4.1: Grundstruktur des Q-DAS ASCII-Transferformats (Zeichnung angelehnt an [6])
der leserlich und editierbar ist.
Flexibilitat Es sollte so flexibel sein, dass man beliebig viele Inhalte und somit beliebig viele
Qualitatsmerkmale von verschiedenen Teilen erfassen kann.
Komprimierbarkeit Der Inhalt einer Q-DAS-Datei sollte sich gut komprimieren lassen.
Mittlerweile hat sich das Dateiformat zum weltweiten Standard insbesondere in der Automobil-
industrie etabliert. Neben dem Q-DAS ASCII-Transferformat wurde neuerdings auch ein XML-
basiertes Format QML zur Darstellung von Qualitatsdaten definiert.
Wie aus Abbildung 4.1 ersichtlich, besteht das Q-DAS ASCII-Transferformat aus einem Beschrei-
bungs- und einem Werteteil. Die beiden Teile konnen entweder in zwei getrennte Dateien oder in
eine gemeinsame Datei geschrieben werden. Wahrend eine Datei, die beide Teile beinhaltet, mit
der Endung DFQ gekennzeichnet wird, tragen eine Wertedatei die Endung DFX und eine Beschrei-
bungsdatei die Endung DFD. Um ein zusammengehoriges DFD/DFX-Datei-Paar zuordenbar zu
machen, werden die zusammengehorigen Dateien abgesehen von ihrer Dateiendung gleichnamig
benannt. Sowohl der Beschreibungsteil als auch der Werteteil basieren auf Schlusselfeldern, deren
jeweilige Bedeutung in [6] eindeutig definiert wurde.
Beschreibungsteil
Im Beschreibungsteil werden Informationen abgelegt, die zur Interpretation und Auswertung der
im Werteteil gespeicherten Daten notwendig sind. Dies sind u. a. Informationen uber die Quali-
tatsmerkmale, zu denen Messwerte im Werteteil der Datei gespeichert sind. Ein Qualitatsmerkmal
KAPITEL 4. DATENERFASSUNG UND DATENUBERTRAGUNG 23
ist eine qualitatsrelevante Große wie etwa das aufgewendete Drehmoment bei einer Schraubope-
ration. Jedes Schlusselfeld im Beschreibungsteil steht in einer eigenen Zeile und besteht aus einer
Schlusselnummer, gefolgt von einem Leerzeichen und dem eigentlichen Feldinhalt.
Am Anfang des Beschreibungsteils, im so genannten Kopf, befindet sich das Schlusselfeld K0100,
in dem die Gesamtanzahl der im Beschreibungsteil beschriebenen Qualitatsmerkmale hinterlegt
ist. Es folgen jeweils in einem Block die Teiledaten (K1000 - K1999), die Merkmalsdaten (K2000
- K2999), die Prufplandaten (K3000 - K3999), die Verwaltungsdaten (K4000 - K4999) sowie die
Sonstigen Daten (K5000 - K5999). Im Folgenden wird lediglich auf die Merkmalsdaten einge-
gangen, da die ubrigen Daten des Beschreibungsteils fur die Datenauswertung im Rahmen dieser
Arbeit nicht relevant sind.
Wie bereits erwahnt, konnen in einer Q-DAS-Datei Messwerte zu beliebig vielen Qualitatsmerk-
malen gespeichert werden. Mithilfe der Merkmalsdaten werden die Eigenschaften aller Qualitats-
merkmale, zu denen Messwerte bei der Bearbeitung eines Teils erfasst und im Werteteil gespei-
chert wurden, beschrieben. Dies sind z. B. Eigenschaften wie Art der Messgroße, verwendete
Messeinheit oder die Grenzwerte, die fur dieses Qualitatsmerkmal zum Zeitpunkt der Opera-
tion an der Montage-Station eingestellt waren. Zur Beschreibung eines Qualitatsmerkmals die-
nen die Schlusselfelder K2000 - K2999 (z. B. Schlusselfeld K2142 fur die verwendete Messein-
heit). Werden in einer Q-DAS-Datei mehrere Qualitatsmerkmale beschrieben, so werden folg-
lich einige der Schlusselfelder mehrfach verwendet. Um die verwendeten Schlusselfelder ein-
zelnen Qualitatsmerkmalen zuordnen zu konnen, werden die beschriebenen Qualitatsmerkmale
von � bis � durchnummeriert, so dass jedes Qualitatsmerkmal eine eindeutige Merkmalsnum-
mer erhalt. Zur Zuordnung eines Schlusselfeldes zu einem Qualitatsmerkmal wird schließlich die
Schlusselnummer des Schlusselfeldes um die jeweilige Merkmalsnummer erganzt (z. B. K2001/1).
Soll der angegebene Wert eines Schlusselfeldes fur alle Merkmale gelten, kann als Merkmalsnum-
mer der Wert”�“ angegeben werden (z. B. K2001/0).
Werteteil
Bei der Bearbeitung eines Teils wird zu jedem im Beschreibungsteil beschriebenen Qualitats-
merkmal ein Messwert erfasst. Fur jeden Messwert wird im Werteteil ein Werteeintrag angelegt,
der neben dem eigentlichen Messwert noch weitere Schlusselfelder beinhaltet. Tabelle 4.2 zeigt
eine Ubersicht aller Schlusselfelder eines Werteeintrags. Die Feldinhalte der Schlusselfelder ei-
nes Werteeintrags werden in aufsteigender Reihenfolge der Schlusselnummern ohne Angabe die-
ser hintereinander geschrieben und durch das Zeichen”¶“ voneinander getrennt. Keines dieser
Schlusselfelder darf dabei weggelassen werden, wobei jedoch einige von ihnen je nach Anforde-
rung leer sein durfen. Die Werteeintrage der einzelnen Messwerte bezuglich eines bearbeiteten
Teils werden wiederum in aufsteigender Reihenfolge der Merkmalsnummern in eine Zeile hin-
tereinander geschrieben und durch das Zeichen”¤“ voneinander getrennt. Seriennummern im
Schlusselfeld K0006 wird grundsatzlich das Zeichen”#“ vorangestellt. Der �-te Werteeintrag ei-
KAPITEL 4. DATENERFASSUNG UND DATENUBERTRAGUNG 24
Schlusselfeld Schlussel Bedeutung
Messwert K0001 der erfasste MesswertAttribut K0002 ein Fehlercode (ein Wert ungleich
”0“ bedeutet, dass die
Operation fehlgeschlagen ist)Datum/Zeit K0004 ein Zeitstempel, der den genauen Zeitpunkt der Operation
bzw. der Messung angibtEreignis K0005 (nicht relevant)Seriennummer K0006 die Seriennummer des bearbeiteten TeilsSpindelnummer K0007 die Nummer der Spindel, an der die Operation durch-
gefuhrt wurdeStation K0008 die Nummer der Montage-Station, an der die Operation
durchgefuhrt wurdeMaschine K0010 (nicht relevant)Prufmittel K0012 (nicht relevant)
Tabelle 4.2: Schlusselfelder eines Werteeintrags
ner Zeile ist mit denjenigen Merkmalsdaten in Verbindung zu bringen, die im Beschreibungsteil
mit der Merkmalsnummer � versehen sind. Jede Zeile beinhaltet also so viele Werteeintrage, wie
Qualitatsmerkmale definiert wurden, womit jede Zeile samtliche Qualitatsdaten beinhaltet, die bei
der Bearbeitung genau eines Teils gespeichert wurden.
4.3.2 DFD/DFX versus DFQ
Es wird die Variante mit einer gemeinsamen DFQ-Datei gewahlt, da dadurch die Zahl der zu
verarbeitenden Dateien nicht unnotig verdoppelt wird und zum anderen das einander Zuordnen
der DFD/DFX-Paare entfallt. Die gewahlte Variante ist demnach effizienter und weniger feh-
leranfallig.
4.3.3 Anforderungen an die zu erzeugenden DFQ-Dateien
Wie in Abschnitt 4.1 erwahnt, sind fur die Datei-erzeugenden Systeme die Lieferanten der jeweili-
gen Fugevorrichtung verantwortlich. Da die Lieferanten weder die gleichen Steuergerate noch die
gleiche Steuerungssoftware verwenden und damit unterschiedliche technische Grundvorausset-
zungen haben, ergeben sich zwischen den DFQ-Dateien fur Schraub- und Presskraftdaten Unter-
schiede bezuglich ihrer Merkmalsstruktur. Die Schlusselfelder, die bei der Speicherung eines Qua-
litatsmerkmals von einer in der Montagelinie erzeugten DFQ-Datei unterstutzt werden mussen,
wurden in einem fur alle Lieferanten verbindlichen Pflichtenheft (vgl. [5]) definiert. Fur die Da-
tenauswertungen im Rahmen dieser Arbeit ist jedoch nur ein Teil der definierten Schlusselfelder
erforderlich. Die erforderlichen Schlusselfelder sind im Anhang in Tabelle A.2 aufgefuhrt. Im
Folgenden soll auf die Merkmalsstrukturen eingegangen und der Aufbau der DFQ-Dateien an
KAPITEL 4. DATENERFASSUNG UND DATENUBERTRAGUNG 25
konkreten Beispielen erlautert werden.
Merkmalsstruktur einer DFQ-Datei mit Schraubkraftdaten (Lieferant Bosch)
Werden an einer Montage-Station Schrauboperationen durchgefuhrt, so verfugt diese Montage-
Station uber genau ein Steuergerat fur alle an der Station befindlichen Schraubspindeln. Demnach
existiert an einer solchen Montage-Station genau ein Datei-erzeugendes System fur alle an der
Montage-Station anfallenden Schraubkraftdaten. Vor dem Hintergrund, dass die Datenubertragung
schichtweise erfolgt, wird an der Montage-Station pro Schicht genau eine Datei erzeugt, in der die
Messungen aller Schraubspindeln der gesamten Schicht gespeichert sind. Da bei jeder Schraubop-
eration zwei Qualitatsmerkmale (Drehwinkel/Drehmoment) erfasst werden, beinhaltet eine DFQ-
Datei einer Montage-Station mit � Schraubspindeln Messwerte zu �� Qualitatsmerkmalen. Die
Qualitatsmerkmale”Drehwinkel“ und
”Drehmoment“ einer Spindel mit der Spindelnummer � er-
halten dabei die Merkmalsnummern ��� � und ��.
Fallbeispiel: Eine DFQ-Datei mit Schraubkraftdaten
Im Folgenden wird der Aufbau einer DFQ-Datei mit Schraubkraftdaten an einem konkreten Bei-
spiel, welches in Abbildung 4.2 dargestellt ist, beschrieben. Der kursiv dargestellte Text ist nicht
Bestandteil der Datei, er soll lediglich zur Erklarung der einzelnen Zeilen beitragen.
Die Schlusselfelder K0100 bis K2142/4 stellen den Beschreibungsteil der DFQ-Datei dar. Das
Schlusselfeld K0100 bildet den Kopf und gibt die Anzahl der beschriebenen Qualitatsmerkmale
und damit die Anzahl der Messwerte an, die bei der Bearbeitung eines Teils erfasst und im Wer-
teteil gespeichert wurden. Der Wert”4“ impliziert, dass die Montage-Station, an der die Datei
erzeugt wurde, uber zwei Schraubspindeln verfugt. Die Schlusselfelder K2001/1 bis K2142/1
beschreiben die Eigenschaften des ersten Qualitatsmerkmals. Aus dem Schlusselfeld K2001/1
mit dem Wert”0017DW“ lasst sich entnehmen, dass es sich bei diesem Qualitatsmerkmal um
das Merkmal”Drehwinkel“ handelt. Die verschiedenen Codes zur Identifizierung eines Qua-
litatsmerkmals wurden in [1] definiert und sind im Anhang in Tabelle A.1 aufgelistet. Die Schlus-
selfelder K2110/1 und K2111/1 geben den unteren und den oberen Grenzwert an, der fur den
Drehwinkel zum Zeitpunkt der Operation an der Montage-Station eingestellt war. In gleicher
Weise wird mittels der Schlusselfelder K2001/2 bis K2142/2 das zweite Qualitatsmerkmal be-
schrieben. Bei diesem Qualitatsmerkmal handelt es sich um das Merkmal”Drehmoment“. Die
Schlusselfelder K2001/3 bis K2142/3 und K2001/4 bis K2142/4 beschreiben wiederum das dritte
und vierte Qualitatsmerkmal, bei denen es sich um die Merkmale”Drehwinkel“ und
”Drehmo-
ment“ handelt. Laut Vereinbarung mit den Lieferanten sind die ersten beiden Qualitatsmerkmale
der ersten Spindel und das dritte und vierte Qualitatsmerkmal der zweiten Spindel zuzuordnen.
Die Information, welcher Spindel ein Qualitatsmerkmal zuzuordnen ist, lasst sich im Ubrigen
auch aus einem der dem Qualitatsmerkmal zugehorigen Werteeintrage im Werteteil ermitteln, da
KAPITEL 4. DATENERFASSUNG UND DATENUBERTRAGUNG 26
jeder Werteeintrag uber ein Schlusselfeld K0007 zur Angabe der Spindel verfugt.
Der Werteteil der DFQ-Datei beginnt nach dem Schlusselfeld K2142/4. Im abgebildeten Beispiel
sind die Messwerte zweier bearbeiteter Getriebe gespeichert. Die zu einem Getriebe erfassten
Messwerte sind in den Werteeintragen der vier Qualitatsmerkmale, die durch das Zeichen”¤“
voneinander getrennt sind, gespeichert. Der �-te Werteeintrag einer Zeile im Werteteil ist dem
�-ten Qualitatsmerkmal aus dem Beschreibungsteil zuzuordnen. Aus den ersten beiden Werteein-
tragen der ersten Zeile im Werteteil geht also hervor, dass das Getriebe mit der Seriennummer
”R–0435467HH“ am 12.01.2004 um 12:33 Uhr von der Spindel mit der Spindelnummer
”1“ be-
arbeitet wurde, der Drehwinkel und das Drehmoment betrugen dabei 70.260796° und 10.978796
Nm. Der Drehwinkel und das Drehmoment bei der Bearbeitung desselben Getriebes an der Spin-
del mit der Spindelnummer”2“ betrugen dagegen 95.045683° und 12.900307 Nm.
Merkmalsstruktur einer DFQ-Datei mit Presskraftdaten (Lieferant Promess)
Werden an einer Montage-Station Pressoperationen durchgefuhrt, so ist jede Pressspindel mit ei-
nem eigenen Steuergerat verbunden. Die Anzahl der Datei-erzeugenden Systeme ist daher iden-
tisch mit der Anzahl der an der Montage-Station befindlichen Pressspindeln, so dass an der Mon-
tage-Station fur jede Spindel pro Schicht eine eigene Datei erzeugt wird. Bei jeder Pressoper-
ation werden zwei Qualitatsmerkmale (Einpresstiefe/Einpresskraft) erfasst. Wird eine Verpres-
sung in zwei Schritten durchgefuhrt, werden fur die zweite Pressoperation zwei weitere Qua-
litatsmerkmale in der DFQ-Datei gespeichert. Die Qualitatsmerkmale”Einpresstiefe“ und
”Ein-
presswinkel“ einer Pressoperation mit der Schrittnummer � erhalten die Merkmalsnummern ����
und ��.
Fallbeispiel: Eine DFQ-Datei mit Presskraftdaten
Abbildung 4.3 zeigt ein Beispiel fur eine DFQ-Datei mit Presskraftdaten. Die Schlusselfelder
K0100 bis K2142/4 stellen den Beschreibungsteil der Datei dar. Der Wert”4“ des Schlusselfeldes
K0100 impliziert, dass die Pressoperation an der ersten Spindel in zwei Schritten erfolgt. Die
Spindelnummer ist aus dem Schlusselfeld K0007 eines der im Werteteil gespeicherten Werteein-
trage zu ermitteln. Die Schlusselfelder K2001/1 bis K2142/1 beschreiben die Eigenschaften des
ersten Qualitatsmerkmals. Aus dem Schlusselfeld K2001/1 mit dem Wert”1503ET“ lasst sich ent-
nehmen, dass es sich bei diesem Qualitatsmerkmal um das Merkmal”Einpresstiefe“ handelt. Die
Schlusselfelder K2110/1 und K2111/1 geben den unteren und den oberen Grenzwert an, der fur
die Einpresstiefe zum Zeitpunkt der Operation an der Montage-Station eingestellt war. In glei-
cher Weise wird mittels der Schlusselfelder K2001/2 bis K2142/2 das zweite Qualitatsmerkmal
beschrieben. Bei diesem Qualitatsmerkmal handelt es sich um das Merkmal”Einpresskraft“. Laut
Vereinbarung mit den Lieferanten sind die ersten beiden Qualitatsmerkmale der ersten Pressope-
ration (Schrittnummer”1“) zuzuordnen. Die Schlusselfelder K2001/3 bis K2142/3 und K2001/4
KAPITEL 4. DATENERFASSUNG UND DATENUBERTRAGUNG 27
K0100 4 Anzahl Merkmale in der DateiK2001/1 0017DW Merkmalscode für erstes MerkmalK2110/1 45.0 Unterer Grenzwert für Drehwinkel von Spindel 1K2111/1 105.0 Oberer Grenzwert für Drehwinkel von Spindel 1K2142/1 ˚ Messeinheit für Drehwinkel von Spindel 1K2001/2 1916DM Merkmalscode für zweites MerkmalK2110/2 2.0 Unterer Grenzwert für Drehmoment von Spindel 1K2111/2 12.0 Oberer Grenzwert für Drehmoment von Spindel 1K2142/2 Nm Messeinheit für Drehmoment von Spindel 1K2001/3 0017DW Merkmalscode für drittes MerkmalK2110/3 75.0 Unterer Grenzwert für Drehwinkel von Spindel 2K2111/3 180.0 Oberer Grenzwert für Drehwinkel von Spindel 2K2142/3 ˚ Messeinheit für Drehwinkel von Spindel 2K2001/4 1916DM Merkmalscode für viertes MerkmalK2110/4 10.0 Unterer Grenzwert für Drehmoment von Spindel 2K2111/4 14.0 Oberer Grenzwert für Drehmoment von Spindel 2K2142/4 Nm Messeinheit für Drehmoment von Spindel 270.260796¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶1¶140¶¶¤ 10.978796¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶1¶140¶¶¤ 95.045683¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶2¶140¶¶¤ 12.900307¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶2¶140¶¶89.862006¶0¶12.01.2004/12:35:07¶¶#R--0435468HH¶1¶140¶¶¤ 11.007295¶0¶12.01.2004/12:35:07¶¶#R--0435468HH¶1¶140¶¶¤ 99.003619¶0¶12.01.2004/12:35:07¶¶#R--0435468HH¶2¶140¶¶¤ 13.170942¶0¶12.01.2004/12:35:07¶¶#R--0435468HH¶2¶140¶¶
Abbildung 4.2: Beispiel fur eine DFQ-Datei mit Schraubkraftdaten
bis K2142/4 beschreiben wiederum das dritte und das vierte Qualitatsmerkmal, bei denen es sich
um die Merkmale”Einpresstiefe“ und
”Einpresskraft“ der zweiten Pressoperation (Schrittnummer
”2“) handelt.
Der Werteteil der DFQ-Datei beginnt nach dem Schlusselfeld K2142/4. Im abgebildeten Bei-
spiel sind die Messwerte zweier bearbeiteter Getriebe gespeichert. Die zu dem Getriebe erfas-
sten Messwerte sind in den Werteeintragen der vier Qualitatsmerkmale, die durch das Zeichen”¤“
voneinander getrennt sind, gespeichert. Auch hier ist der �-te Werteeintrag einer Zeile im Werte-
teil dem �-ten Qualitatsmerkmal aus dem Beschreibungsteil zuzuordnen. Aus den ersten beiden
Werteeintragen der ersten Zeile im Werteteil geht also hervor, dass das Getriebe mit der Seri-
ennummer”R–0435467HH“ am 12.01.2004 um 12:33 Uhr zum ersten Mal von der Spindel mit
der Spindelnummer”1“ bearbeitet wurde, die Einpresstiefe und die Einpresskraft betrugen da-
bei 23.265796 mm und 10.278796 kN. Bei der zweiten Bearbeitung desselben Getriebes von der
Spindel mit der Spindelnummer”1“ betrugen die Einpresstiefe und die Einpresskraft 27.145603
mm und 12.800347 kN.
KAPITEL 4. DATENERFASSUNG UND DATENUBERTRAGUNG 28
K0100 4 Anzahl Merkmale in der DateiK2001/1 1503ET Merkmalscode für erstes MerkmalK2110/1 20.0 Unterer Grenzwert für Einpresstiefe von Schritt 1K2111/1 130.0 Oberer Grenzwert für Einpresstiefe von Schritt 1K2142/1 mm Messeinheit für Einpresstiefe von Schritt 1K2001/2 1505EK Merkmalscode für zweites MerkmalK2110/2 10 Unterer Grenzwert für Einpresskraft von Schritt 1K2111/2 14 Oberer Grenzwert für Einpresskraft von Schritt 1K2142/2 kN Messeinheit für Einpresskraft von Schritt 1K2001/3 1503ET Merkmalscode für drittes MerkmalK2110/3 20.0 Unterer Grenzwert für Einpresstiefe von Schritt 2K2111/3 130.0 Oberer Grenzwert für Einpresstiefe von Schritt 2K2142/3 mm Messeinheit für Einpresstiefe von Schritt 2K2001/4 1505EK Merkmalscode für viertes MerkmalK2110/4 10 Unterer Grenzwert für Einpresskraft von Schritt 2K2111/4 14 Oberer Grenzwert für Einpresskraft von Schritt 2K2142/4 kN Messeinheit für Einpresskraft von Schritt 223.265796¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶1¶140¶¶¤ 10.278796¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶1¶140¶¶¤ 27.145663¶0¶12.01.2004/12:34:16¶¶#R--0435467HH¶1¶140¶¶¤ 12.800347¶0¶12.01.2004/12:34:16¶¶#R--0435467HH¶1¶140¶¶27.462006¶0¶12.01.2004/12:34:49¶¶#R--0435468HH¶1¶140¶¶¤ 12.557295¶0¶12.01.2004/12:34:49¶¶#R--0435468HH¶1¶140¶¶¤ 29.993619¶0¶12.01.2004/12:35:12¶¶#R--0435468HH¶1¶140¶¶¤ 13.370342¶0¶12.01.2004/12:35:12¶¶#R--0435468HH¶1¶140¶¶
Abbildung 4.3: Beispiel fur eine DFQ-Datei mit Presskraftdaten
Benamung der DFQ-Dateien
Um zu vermeiden, dass mehrere DFQ-Dateien den gleichen Namen erhalten, was beimUbertragen
an den zentralen Server zum moglichen Uberschreiben einer Datei auf dem Server fuhren konnte,
erfolgt die Namensgebung nach einer Namenskonvention, die in [1] festgelegt wurde und fur alle
Lieferanten verbindlich ist. Die Namenskonvention stellt sicher, dass jede in der Montagelinie
erzeugte DFQ-Datei einen eindeutigen Namen erhalt. Da der Aufbau des Dateinamens fur die
Datenauswertung im Rahmen dieser Arbeit nicht relevant ist, wird auf die Namenskonvention
nicht weiter eingegangen.
4.4 Ubertragung der Kombinationsdaten
Die Kombinationsdaten werden ebenfalls schichtweise von der Station ST140 zum Server uber-
tragen. Dazu wird nach Abschluss einer Schicht die Gesamtheit aller Kombinationsdaten aus der
in Abschnitt 2.6 beschriebenen Tabelle (vgl. Tabelle 2.1) einer Microsoft Access-Datenbank im
CSV-Format exportiert (Full-Dump). Im Gegensatz zu allen anderen Datenarten werden also bei
der Ubertragung der Kombinationsdaten nicht nur die wahrend der vorangegangenen Schicht er-
fassten Daten, sondern alle jemals in der Access-Datenbank erfassten Daten ubertragen. Abbil-
dung 4.4 zeigt einen beispielhaften Auszug aus der CSV-Datei.
KAPITEL 4. DATENERFASSUNG UND DATENUBERTRAGUNG 29
R--04165473ML;;;13.01.2004 10:12:23;3C29lgN7;5C29WBnD;5C29nqfD;5C28rC63;4C2CRp93;5C27Rc47;6C22AbiE;6C22TbTC;
R--90000100CE;;12140000001008;13.01.2004 10:18:01;443GRsj1;443GXvEF;443Go9Q2;443HXIDG;443Hp0OJ;443HI7kE;
R--04165475HH;M68102P0010;;13.01.2004 10:37:59;443GVhP0;443GrQh7;443Gr3bE;443HdMZ1;443Hw056;443HuOZG;
Abbildung 4.4: Auszug aus einer Datei mit Kombinationsdaten
4.5 Ubertragung der Shim-Daten
Die Shim-Daten werden an der Station ST150 in eine CSV-Datei geschrieben, die nach Abschluss
einer Schicht abgeschlossen und an den Server ubertragen wird. Wie die DFQ-Dateien erhalten
auch die erzeugten Shim-Dateien einen eindeutigen Dateinamen. Abbildung 4.5 zeigt einen exem-
plarischen Auszug aus einer Shim-Datei. Wahrend die Werte in der zweiten Spalte die ermittelten
Shim-Klassen darstellen, geben die Werte in der dritten Spalte die Getriebekomponente an, fur die
das entsprechende Shim verwendet werden soll.
R--04165473HH;10;HWU;13.01.2004 10:12:23R--04165473HH;11;HWO;13.01.2004 10:12:23R--04165473HH;1;AWE;13.01.2004 10:12:23R--04165473HH;8;DIF;13.01.2004 10:12:23R--04165474HH;12;HWU;13.01.2004 10:37:59
Abbildung 4.5: Auszug aus einer Datei mit Shim-Daten
4.6 Ubertragung der Ausschleusungsdaten
Die Ausschleusungszeitpunkte der einzelnen Getriebe werden an der Station ST300 in eine CSV-
Datei geschrieben, die nach Abschluss einer Schicht an den Server ubertragen wird. Abbildung 4.6
zeigt einen exemplarischen Auszug aus der Datei.
R--04165473HH;13.01.2004 10:12:23R--04165474HH;13.01.2004 10:18:01R--04165475HH;13.01.2004 10:37:59R--04165476HH;13.01.2004 10:45:11
Abbildung 4.6: Auszug aus einer Datei mit Ausschleusungsdaten
Kapitel 5
Grundlagen zur Datenkonsolidierung
Die Datenkonsolidierung dient der Integration der Daten der unterschiedlichen Quellsysteme in
ein einheitliches Zielschema. Da Datenmangel in den Quelldaten die Datenqualitat und dadurch
auch den effektiven Nutzen der Daten verringern konnen, mussen die Quelldaten wahrend des
Integrationsprozesses von Datenmangeln befreit werden. Schließlich soll eine ganzheitliche Sicht
auf moglichst fehlerfreie und in sich schlussige Daten der Quellsysteme zur Verfugung stehen.
Um dieses Ziel zu erreichen, mussen nach Erzeugen der Zieltabellen die in unterschiedlicher Form
vorliegenden Quelldaten transformiert werden, um sie an die Zieltabellen anzupassen. Außerdem
bedarf es zur Erkennung und Beseitigung der Datenmangel einer Datenbereinigung. In diesem
Kapitel wird zunachst der Begriff der Datenqualitat genauer definiert (Abschnitt 5.1) sowie auf
die verschiedenen Arten von Datenmangeln eingegangen (Abschnitt 5.2), die fur die Verringe-
rung der Datenqualitat verantwortlich sein konnen. Im Anschluss daran wird auf den Prozess der
Datentransformation (Abschnitt 5.3) sowie der Datenbereinigung (Abschnitt 5.4) naher eingegan-
gen. Im Abschluss dieses Kapitels (Abschnitt 5.5) wird eine allgemeingultige Vorgehensweise zur
Datenkonsolidierung beschrieben.
5.1 Datenqualitat
Daten dienen der Reprasentation von Tatsachen oder Entitaten aus einem Ausschnitt der Rea-
litat [4]. In dieser Arbeit liegen die Daten einem relationalen Datenmodell zugrunde, in dem
Entitaten der Realitat durch �-Tupel reprasentiert werden und die Attributwerte der Tupel die
Eigenschaften der reprasentierten Entitaten beschreiben. Die Attributwerte werden dabei durch
Zeichenketten codiert. Gleichartige Tupel werden zu jeweils einer Relation zusammengefasst. Die
Tupel einer Relation mussen dem Schema der Relation, dem so genannten Relationen-Schema,
entsprechen. Dies bedeutet, dass die Struktur der Tupel einer Relation durch das zugehorige
Relationen-Schema bestimmt wird. Das Relationen-Schema definiert eine Liste von Attributen
und fur jedes dieser Attribute eine Grammatik, die wiederum die Menge der Zeichenketten de-
30
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 31
Abbildung 5.1: Hierarchie von Qualitatskriterien nach [4]
finiert, die das jeweilige Attribut als Wert annehmen darf. Die Daten unterliegen damit strengen
Regeln, der so genannten Syntaktik. Die Semantik dagegen beschaftigt sich mit der Bedeutung
dieser Zeichenketten, also mit dem Wissen, welches durch die Daten reprasentiert wird. Ein ef-
fektiver Nutzen der Daten erfordert eine moglichst hohe Datenqualitat. In [10] wird Datenqua-
litat bezeichnet als die Gesamtheit aller Eigenschaften von Daten hinsichtlich der Adaquatheit,
die Anforderungen einer Anwendungssituation zu erfullen. Da die Definition von Datenqualitat
als fitness-for-use in der Praxis nicht Ziel fuhrend ist, bedarf es der Identifizierung von allge-
meingultigen Kriterien von Datenqualitat. In der Literatur finden sich verschiedene Ansatze zur
Definition von Datenqualitatskriterien, die sich in der Methodik zur Bestimmung von Kriterien
unterscheiden. In Abbildung 5.1 ist eine Hierarchie von Qualitatskriterien dargestellt, die aus dem
klassischen Ansatz zur Definition von Datenqualitat hervorgeht. Dieser Ansatz bezieht sowohl die
syntaktischen Eigenschaften (z. B. Einheitlichkeit der Reprasentation) als auch die semantischen
Eigenschaften (z. B. Korrektheit) von Daten ein. Die vorgestellte Hierarchie resultiert aus verschie-
denen Qualitatskriterien, die sich wiederum in weitere Kriterien unterteilen lassen. Sie ist aus [4]
ubernommen und verdient keineswegs den Anspruch auf Vollstandigkeit. Beispielsweise lassen
sich einzelne Qualitatskriterien in weitere noch spezifischere Qualitatskriterien aufteilen. Die fol-
genden Definitionen zu den einzelnen Qualitatskriterien sind ebenfalls aus [4] ubernommen.
• Vollstandigkeit ist die Eigenschaft, dass in einem Tupel alle Attributwerte vorhanden sind.
Daruber hinaus kann unter Vollstandigkeit auch die Eigenschaft verstanden werden, dass
alle in der abgebildeten Realitat vorkommenden Entitaten im Datenbestand reprasentiert
sind.
• Gultigkeit ist die Eigenschaft, dass jedes Tupel im Datenbestand eine Entitat reprasentiert,
die auch tatsachlich in der abgebildeten Realitat existiert.
• Integritat ist die Eigenschaft, dass alle und nur diejenigen Entitaten, die in der Realitat
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 32
existieren, von einem Tupel im Datenbestand reprasentiert werden.
• Einheitlichkeit ist die Eigenschaft, dass alle Werte innerhalb eines Attributs einheitlich ver-
wendet werden und daher gleichartig interpretiert werden konnen.
• Schema-Konformitat ist die Eigenschaft, dass jedes Tupel zum Schema seiner Relation kon-
form ist. Dies bedeutet, dass jedes Tupel im Bezug auf seine Struktur und seine Werte syn-
taktisch korrekt ist.
• Konsistenz ist die Eigenschaft, dass die Tupel im Datenbestand syntaktisch korrekt sind und
keine Unregelmaßigkeiten aufweisen.
• Korrektheit ist die Eigenschaft, dass eine genaue, einheitliche und vollstandige Reprasenta-
tion der abgebildeten Realitat vorliegt. In diesem Fall sind alle der bisher genannten Krite-
rien erfullt.
• Eindeutigkeit ist die Eigenschaft, dass im Datenbestand keine Duplikate existieren. Als Du-
plikate werden Tupel verstanden, die dieselbe Entitat der abgebildeten Realitat reprasentieren,
aber nicht notwendigerweise in allen Attributen ubereinstimmen.
Daten, die korrekt und eindeutig sind und dabei die einzelnen Kriterien zu 100% erfullen, stellen
ein prazises Abbild der Realitat dar und sind daher Daten von hochster Qualitat. Unter Praxisbe-
dingungen variiert gewohnlich der Erfullungsgrad einzelner Kriterien und der Erfullungsgrad von
100% kann oft nicht erreicht werden. Metriken, auf deren Basis Erfullungsgrade von Kriterien be-
stimmt werden konnen und damit letztlich die Qualitat von Daten gemessen werden kann, werden
nicht eingefuhrt.
5.2 Datenqualitatsprobleme
Ein Datenqualitatsproblem besteht, wenn Daten aufgrund ihrer Eigenschaften den in Abschnitt 5.1
beschriebenen Qualitatskriterien nicht genugen und infolge dessen die Datenqualitat verringert
ist. Das Erkennen von Daten, die den Qualitatskriterien nicht genugen, und das Identifizieren
der Ursachen bzw. der Verursacher stellt eine wesentliche Grundlage fur Maßnahmen zur Ver-
besserung der Qualitat von Daten dar. In [2] wird bei Datenqualitatsproblemen zwischen Single
Source- und Multi Source-Problemen unterschieden. Single Source-Probleme resultieren aus Da-
tenmangeln, die bereits bei der Integration von Daten einer Datenquelle auftreten konnen. Multi
Source-Probleme resultieren dagegen aus Datenmangeln, die im direkten Zusammenhang mit der
Integration von Daten mehrerer Datenquellen stehen. Innerhalb beider Problembereiche wird wie-
derum zwischen schema- und instanzbezogenen Problemen unterschieden. Die Klassifizierung
nach [2] ist in Abbildung 5.2 dargestellt.
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 33
Abbildung 5.2: Klassifizierung von Qualitatsproblemen nach [2]
5.2.1 Single Source-Probleme
Single Source-Probleme werden haufig durch eine fehlerhafte Datenerfassung verursacht. Eine
Vielzahl moglicher Fehlerarten steht im Zusammenhang mit einer manuellen Dateneingabe. Auf
diese Fehlerarten wird nicht weiter eingegangen, da die Datenerfassung im Rahmen dieser Arbeit
ausschließlich automatisch erfolgt. Bei der automatischen Datenerfassung konnen durch Fehlfunk-
tionen der Erfassungssysteme (z. B. Messsysteme) falsche Werte zuruckgeliefert werden. Daruber
hinaus konnen auch der Erfassung nachgeschaltete Datenverarbeitungsprozesse fur Datenmangel
verantwortlich sein. Eine unzureichende Eingabe bzw. Integritatskontrolle (vgl. Abschnitt 5.4.2)
kann die unterschiedlichen Datenmangel begunstigen, da in diesem Fall ungultige Dateneingaben
von der Applikation oder von dem Datenhaltungssystem nicht zuruckgewiesen werden.
Single Source-Probleme, die durch ein verbessertes Schemadesign oder eine verbesserte Inte-
gritatskontrolle vermieden werden konnen, werden als schemabezogene Single Source-Probleme
bezeichnet. Diese Probleme treten insbesondere in Quellsystemen mit einer Textdateibasierten
Datenhaltung auf, da in diesem Fall ein Schema im eigentlichen Sinne nicht existiert, sondern le-
diglich Restriktionen zu Format und Struktur der Daten bestehen, deren Einhaltung jedoch nicht
uberpruft wird. Erfolgt die Datenhaltung in einem Datenbanksystem, sind die Qualitatsprobleme
haufig auf ein mangelhaftes Schemadesign oder auf die ungenugende Verwendung von Integritats-
Constraints zuruckzufuhren [2]. Letzteres geschieht in der Regel, um den mit der Verwendung von
Integritats-Constraints verbundenen Overhead klein zuhalten. Schemabezogene Qualitatsprobleme
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 34
sind grundsatzlich auch auf Instanzebene sichtbar. Im Folgenden werden einige schemabezogene
Single Source-Probleme erlautert, die im Rahmen dieser Arbeit relevant sind.
Wert außerhalb des zulassigen Wertebereichs Werte, die außerhalb des Wertebereichs des ent-
sprechenden Attributs liegen, sind unzulassige Werte und verletzen das Kriterium der Schema-
Konformitat.
Beispiel: timestamp = 30.13.2004
Ungultige Kombination von Attributwerten In diesem Fall ist aufgrund der Kombination der
Attributwerte eine Integritatsbedingung verletzt. Dies ist beispielsweise der Fall, wenn eine
funktionale Abhangigkeit zwischen zwei oder mehreren Attributen durch die Attributwer-
te nicht erfullt und somit ein Widerspruch erzeugt wird. Eine funktionale Abhangigkeit
besteht, wenn ein Attributwert von einem Wert eines anderen Attributs bestimmt wird. In
diesem Fall ist das Kriterium der Gultigkeit verletzt.
Beispiel: age = 22, birth date = 10.02.1977, current date = 14.08.2004
Fehlender Wert Wenn zu einem Attribut kein Wert angegeben ist, obwohl die Angabe eines Wer-
tes fur das betroffene Attribut verpflichtend ist, wird das Kriterium der Vollstandigkeit ver-
letzt.
Nichteindeutigkeit von Schlusseln Das Kriterium der (Schlussel-)Eindeutigkeit wird verletzt durch
das doppelte Vorkommen eines Wertes in einem Attribut, welches den Primarschlussel dar-
stellt.
Beispiel: emp1 = (id = 1, name = smith)
emp2 = (id = 1, name = miller)
Verletzung der referentiellen Integritat Die referentielle Integegritat wird verletzt, wenn ein
durch den Fremdschlussel referenziertes Tupel nicht existiert.
Beispiel: emp1 = (id = 1, name = smith)
id = 1 existiert in der Master-Relation nicht
Instanzbezogene Single Source-Probleme resultieren aus Datenmangeln, die auch durch eine um-
fassende Eingabe- bzw. Integritatskontrolle nicht vermieden werden konnen. Im Folgenden sind
einige instanzbezogene Single Source-Probleme aufgefuhrt.
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 35
Falscher Wert Falsche Werte sind Werte, die zwar keine Integritatsbedingungen verletzen, aber
dennoch falsch sind, weil sie die Realitat nicht korrekt abbilden. Falsche Werte sind in erster
Linie auf eine falsche Erfassung (z. B. Tipp- oder Messfehler) zuruckzufuhren und verletzen
das Kriterium der Gultigkeit.
Fehlender Wert Bei Attributen, fur die die Angabe eines Wertes nicht verpflichtend ist, erweist
sich die unterschiedliche Semantik von nicht vorhandenen Angaben als problematisch, da
das Fehlen eines Wertes auf drei verschiedene Arten interpretiert werden kann:
1. Es gibt in der Realitat keinen Wert fur das betroffene Attribut.
2. Es gibt in der Realitat einen Wert fur das betroffene Attribut, jedoch war der Wert bei
Erfassung des Datensatzes nicht bekannt.
3. Es ist nicht bekannt, ob es in der Realitat ein Wert fur das betroffene Attribut existiert.
In den beiden letzteren Fallen ist das Kriterium der Vollstandigkeit verletzt.
Fehlendes Tupel Aufgrund des Fehlens eines ganzen Tupel ist das Kriterium der Vollstandigkeit
verletzt.
Duplikate Duplikate treten auf, wenn die gleiche Entitat aus der Realitat durch zwei Tupel re-
prasentiert wird, deren Attributwerte nicht notwendigerweise identisch sind. In diesem Fall
wird das Kriterium der Eindeutigkeit verletzt.
Beispiel: emp1 = (id = 1, name = john smith)
emp2 = (id = 2, name = j. smith)
Aus den genannten Beispielen ist ersichtlich, dass Single Source-Probleme eine unterschiedliche
Tragweite haben konnen. Die verschiedenen Probleme konnen sich uber einzelne Attribute, uber
mehrere Attribute eines Tupels oder uber den gesamten Datenbestand der Quelle erstrecken. Dem-
nach konnen Datenmangel eine unterschiedliche Komplexitat aufweisen.
Wie bereits erwahnt, werden die Datenmangel in erster Linie durch eine fehlerhafte Erfassung
erzeugt. Werden die Quelldaten uber ein Netzwerk ubertragen, konnen Ubertragungsfehler Da-
tenmangel verursachen (z. B. fehlerhafte Werte in Textdateien infolge einer fehlerhaften FTP-
Ubertragung). Fehlerhafte Datenverarbeitungsprozesse zur Vor- bzw. Nachbereitung der Daten-
ubertragung (z. B. Export aus einer Datenbank) konnen wiederum Mangel an den Daten zur Folge
haben.
In [4] wird unter den Datenmangeln zwischen syntaktischen und semantischen Fehlern unterschie-
den. Ein syntaktischer Fehler bezieht sich immer auf die Struktur der Tupel oder auf das Format
der Werte, die zur Reprasentation von Entitateneigenschaften verwendet werden. Ein syntaktischer
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 36
Fehler liegt beispielsweise vor, wenn ein Tupel nicht die erwartete Anzahl von Attributen besitzt
oder ein verwendeter Attributwert nicht im Wertebereich des entsprechenden Attributs liegt. Se-
mantisch falsche Daten dagegen sind zwar syntaktisch korrekt, bilden jedoch die Realitat nicht
korrekt ab. Semantisch falsche Daten liegen beispielsweise dann vor, wenn Integritatsbedingungen
verletzt werden, Duplikate existieren oder Tupel falsche Werte aufweisen.
5.2.2 Multi Source-Probleme
Wenn Daten aus verschiedenen Quellen in ein einheitliches Zielschema integriert werden, konnen
zusatzlich zu den Single Source-Problemen weitere Probleme entstehen, die als Multi Source-
Probleme bezeichnet werden. Multi Source-Probleme konnen durch eine starke Heterogenitat der
Quellen im Bezug auf die verwendeten Datenhaltungssysteme und Schemata verursacht werden.
Heterogene Systemlandschaften existieren haufig, wenn die Systemlandschaft historisch gewach-
sen ist und die einzelnen Quellsysteme unabhangig voneinander von verschiedenen Organisati-
onseinheiten entwickelt wurden und dabei jedes Quellsystem speziell an die Bedurfnisse der je-
weiligen Organisationseinheit angepasst wurde.
Auf der Schemaebene kann eine heterogene Systemlandschaft zu strukturellen Konflikten fuhren.
Strukturelle Konflikte resultieren aus unterschiedlichen Modellierungen eines Sachverhaltes (z. B.
unterschiedliche Datentypen, Speichern von mehreren Werten in einem Attribut, statt in getrenn-
ten Attributen).
Auf Instanzebene konnen Attribute unterschiedlicher Quellen trotz gleichen Datentyps unterschied-
lich reprasentiert sein. Dies tritt beispielsweise auf, wenn in den verschiedenen Quellen ein unter-
schiedliches Datumsformat verwendet wird.
Beispiel: Quelle 1: timestamp = 11.12.1977
Quelle 2: timestamp = 1977-12-11
Außerdem kann es vorkommen, dass Werte unterschiedlich interpretiert werden mussen, wenn et-
wa bei Messwerten eine nicht einheitliche Messeinheit verwendet wird. Beim Zusammenfuhren
von Daten aus verschiedenen Quellen konnen Duplikate auftreten, wenn Tupel aus verschiedenen
Quellen die gleiche Entitat in der Realitat reprasentieren. Haufig tritt jedoch in diesem Fall nur
eine teilweise Uberlappung der Tupel auf, da sie je nach Aufgabe der jeweiligen Datenquelle ver-
schiedene Informationen beinhalten. Nicht zuletzt konnen Werte aus verschiedenen Quellen einen
logischen Widerspruch erzeugen, wenn etwa die Datenerfasser der verschiedenen Quellsysteme
uber einen unterschiedlichen Wissensstand bezuglich eines Sachverhaltes verfugen oder infolge
einer mangelnden Zeitsynchronisation der Quellsysteme logisch widerspruchliche Datums- und
Zeitangaben gespeichert werden.
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 37
5.3 Datentransformation
Ein Bestandteil der Datenintegration ist die Transformation der Quelldaten, um die Daten der
einzelnen Quellsysteme hinsichtlich ihrer Reprasentation aneinander anzugleichen und an das
einheitliche Zielschema anzupassen. Mithilfe von Datentransformationen werden demnach Multi
Source-Probleme beseitigt, die durch eine uneinheitliche Reprasentation oder auch durch struk-
turelle Konflikte verursacht werden. Der gesamte Vorgang geschieht in der Regel anhand fest
definierter Transformationsregeln. Im Folgenden werden einige Beispiele fur Datentransforma-
tionen aufgefuhrt. Dabei geht es ausschließlich um die Transformation von Daten, nicht um die
Transformation von Datenstrukturen bzw. Schemata. Ein definiertes Zielschema, ggf. als Resul-
tat einer abgeschlossenen Schemaintegration, ist dafur eine unverzichtbare Vorraussetzung (vgl.
Abschnitt 5.5.2).
Anpassung des Datentyps
Falls der Datentyp eines Quellattributs nicht mit dem des entsprechenden Zielattributs uberein-
stimmt, ist eine Konvertierung der Attributwerte erforderlich. z. B.:
Zeichenkette � Datum
Zeichenkette � Zahl
Anpassung der Datenreprasentation
Manchmal wird ein bestimmtes Merkmal im Quellsystem anders reprasentiert als im Zielsystem
z. B.:
Quellsystem M (Mannlich)
F (Weiblich)
Zielsystem M (Mannlich)
W (Weiblich)
Hier muss die Reprasentation der Quelldaten an die des Zielsystems angepasst werden.
Angleichung der Messeinheit
Numerische Merkmalsauspragungen besitzen in der Regel eine Messeinheit. Dabei kann die in
einem Quellattribut verwendete Messeinheit von der im Zielattribut benotigten abweichen. In die-
sem Fall ist eine Umrechnung zur Angleichung erforderlich. z. B.:
cm � m
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 38
Separierung und Kombination von Attributwerten
Manchmal kann es vorkommen, dass in den Quellsystemen zusammengefasste Attributwerte im
Zielsystem in einzelne Attribute aufgespaltet werden mussen. Diesen Vorgang nennt man Separie-
rung, wahrend der umgekehrte Fall, das Zusammenfugen von einzelnen Attributen aus den Quel-
len als Kombination von Attributwerten bezeichnet wird. Die Zerlegung beziehungsweise Kom-
bination von Attributen kann nach einer vorher festgelegten Regel oder Berechnungsvorschrift
geschehen.
5.4 Datenbereinigung
Ein weiterer Bestandteil der Datenintegration ist die Bereinigung der Quelldaten. Der Prozess der
Datenbereinigung ist in der Literatur nicht einheitlich definiert. Allgemein versteht man unter einer
Datenbereinigung die Durchfuhrung verschiedener Maßnahmen mit dem Zweck samtliche Fehler
und Ungereimtheiten zu erkennen und zu beseitigen, um ein korrektes und eindeutiges Abbild
der Realitat zu erhalten [4]. Ursprunglich zielte die Datenbereinigung auf die Eliminierung von
Duplikaten ab (z. B. Sorted-Neighbourhood-Methode), die insbesondere bei der Integration von
Daten aus verschiedenen Quellen auftreten konnen. Infolge dessen ist die Datenbereinigung zu
einem elementaren Bestandteil der Datenintegration geworden. Eine universelle Methode fur eine
umfassende und vollstandige Datenbereinigung existiert nicht. Stattdessen existiert zur Datenbe-
reinigung eine Vielzahl verschiedener Methoden, die jeweils auf die Behebung eines bestimmten
Qualitatsproblems abzielen. Darunter existieren Methoden sowohl zur Erkennung von Datenfeh-
lern als auch zur Korrektur von falschen oder fehlenden Werten. Weist ein Datenbestand mehrere
unterschiedliche Qualitatsprobleme auf, so mussen zur vollstandigen Datenbereinigung verschie-
dene Methoden in angemessener Weise miteinander kombiniert werden. Die Bereinigung von Da-
ten erfordert grundsatzlich ein gutes Wissen uber die Daten bzw. den abzubildenden Sachverhalt,
deshalb hangt der Erfolg der Datenbereinigung vor allem vom verfugbaren Wissen ab. Insbesonde-
re wenn statistische Verfahren (vgl. Abschnitt 5.4.3) zur Anwendung kommen, kann die Datenbe-
reinigung nur mit einer gewissen Fehlerwahrscheinlichkeit erfolgen. Aus diesem Grund ist haufig
eine handische Nachbearbeitung der als fehlerhaft identifizierten Daten notwendig, weshalb der
Prozess der Datenbereinigung auch als semi-automatisch bezeichnet wird. In den folgenden Ab-
schnitten werden Methoden vorgestellt, die bei der Datenbereinigung zur Anwendung kommen.
Dabei werden nur jene Methoden vorgestellt, die zur weiteren Argumentation in dieser Arbeit re-
levant sind. Methoden zur Korrektur von Daten werden nicht erlautert, da falsche oder fehlende
Werte laut Anforderungen nicht korrigiert werden sollen. Stattdessen sollen die betroffenen Tupel
ignoriert bzw. in einen Fehler-Report geschrieben werden.
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 39
5.4.1 Parsen
Zum wirksamen Erkennen von syntaktischen Fehlern eignen sich Parser [4]. Ein Parser fur eine
Grammatik � ist ein Programm, das entscheidet, ob ein gegebenes Wort ein Element der durch
die Grammatik � definierten Sprache ist. Im Kontext der Datenbereinigung werden Parser zum
Einlesen von Quelldateien und zur Uberprufung ihrer Dateistruktur eingesetzt. Daruber hinaus
kann mithilfe von Parsern entschieden werden, ob die Struktur eines Tupels der erwarteten Struktur
entspricht und die einzelnen Attributwerte in den entsprechenden Wertemengen enthalten sind.
Auf diese Weise konnen mit einer hohen Zuverlassigkeit Daten erkannt werden, die das Kriterium
der Schema-Konformitat verletzen.
5.4.2 Integritatskontrolle
Eine Moglichkeit, fehlerhafte Daten zu erkennen, besteht in der Uberprufung der Daten im Hin-
blick auf das Erfullen der geltenden Integritatsbedingungen.
Daten besitzen zu jeder Zeit eine bestimmte Konfiguration von Attributwerten mit dem Zweck
einen Sachverhalt aus der Realitat abzubilden. Da die Realitat bestimmten Einschrankungen und
Regeln unterliegt (z. B. kann die aufgewendete Kraft bei einem Einpressvorgang immer nur po-
sitiv sein), stellen nicht alle moglichen Konfigurationen von Attributwerten ein korrektes Ab-
bild der Realitat dar. Daher werden uber die Definition des Datenmodells hinaus statische Inte-
gritatsbedingungen definiert, die in ihrer Gesamtheit die Menge aller zulassigen Attributwertkom-
binationen definieren. Attributwertkombinationen, die nicht die definierten Integritatsbedingungen
erfullen, sind folglich als fehlerhaft zu bezeichnen. Integritatsbedingungen werden insbesondere
aus funktionalen Abhangigkeiten oder aus applikationsspezifischen Geschaftsregeln (Business-
Rules) abgeleitet. Beispiele fur Geschaftsregeln sind:
• Regeln zur Prufung der Einhaltung von Wertebereichen
• Regeln zur Prufung gultiger Attributwertkombinationen
• Regeln zur Prufung der Einhaltung von Berechnungsvorschriften
• IF ... THEN ... -Regeln
Wie aus den Beispielen ersichtlich, konnen Integritatsbedingungen eine unterschiedliche Trag-
weite haben. Die Bedingungen konnen sich auf einzelne Attribute, mehrere Attribute eines Tupels
oder auch auf Attribute verschiedener Tupel beziehen.
Relationale Datenbanksysteme wie z. B. Oracle bieten mittels der Abfragesprache SQL die Mog-
lichkeit eines deklarativen Weges Integritatsbedingungen (Integritats-Constraints) zu definieren. In
einem solchen Fall wird die Integritatskontrolle durch das Datenbanksystem selbst durchgefuhrt.
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 40
Dabei werden schreibende Datenbankzugriffe, die deklarierte Integritatsbedingungen verletzen,
vom Datenbanksystem zuruckgewiesen. Der Vorteil besteht darin, dass es zur Uberprufung der
definierten Integritatsbedingungen keiner applikationsseitigen Implementierung bedarf, was die
Entwicklung der Applikation erheblich vereinfacht.
Im relationalen Datenmodell, dem eine relationale Datenbank zu Grunde liegt, existieren insge-
samt vier verschiedene Arten von Integritatsbedingungen, die im Folgenden kurz beschrieben wer-
den:
Entitats-Integritat Die Entitats-Integritat sichert uber den Primarschlussel die Schlusseleindeu-
tigkeit einer Tabelle. Ein Primarschlussel � einer Tabelle besteht aus einer Teilmenge ihrer
Attribute, so dass niemals zwei Tupel den gleichen Wert fur � besitzen und keine Teilmen-
ge von � existiert, die die Eindeutigkeitseigenschaft besitzt. Alternative Schlussel konnen
zusatzlich als ein UNIQUE-Schlussel deklariert werden. Damit kann gewahrleistet werden,
dass die Werte in bestimmten Spalten oder Spaltenkombinationen eindeutig sind.
Referentielle Integritat Die referentielle Integritat sichert die Gultigkeit eines Verweises zwi-
schen zwei Tabellen uber einen Fremdschlussel. Ein Fremdschlussel bezuglich einer Relati-
on �� ist eine Teilmenge �� von Attributen einer Relation ��, so dass zu jedem Zeitpunkt
fur �� gilt: Zu jedem Wert von �� existiert ein gleicher Wert im Schlusselattribut irgend-
eines Tupels von Relation ��.
Domanenbedingungen Bedingungen dieser Art beziehen sich auf die Werte, die ein Attribut
annehmen darf. Der Datentyp des Attributs wird bereits durch die Spaltendefinition impli-
ziert. Daruber hinaus kann die Menge der moglichen Werte eines Attributs mithilfe einer
CHECK-Klausel (z. B. CHECK (FORCE > 0)) weiter eingeschrankt werden. Durch ein
NOT NULL-Constraint wird verhindert, dass in den entsprechenden Spalten fehlende Werte
vorkommen konnen.
Unternehmensbedingungen Unternehmensbedingungen umfassen alle Integritatsbedingungen,
die nicht durch die bisher genannten Bedingungen abgedeckt werden. Unternehmensbe-
dingungen konnen mithilfe einer CHECK-Klausel definiert werden, sofern sich diese nur
auf Attribute innerhalb eines Tupels beziehen. Komplexere Unternehmensbedingungen, die
sich nicht nur auf Attribute eines Tupels beziehen, lassen sich dagegen mit Triggern realisie-
ren. Ein Trigger in einer Oracle-Datenbank ist im Wesentlichen eine PL/SQL-Prozedur, die
mit einer Tabelle assoziiert ist und automatisch aufgerufen wird, wenn auf der Tabelle eine
beliebige Schreiboperation ausgefuhrt wird. PL/SQL ist eine prozedurale Erweiterung von
Oracle-SQL, die Sprachkonstrukte zur Verfugung stellt, die ahnlich sind mit Konstrukten ei-
ner imperativen Programmiersprache. Damit wird es dem Entwickler ermoglicht, komplexe-
re Anwendungen zu entwickeln, die den Gebrauch von Kontrollstrukturen und prozedurale
Strukturen wie Prozeduren, Funktionen und Module erfordern.
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 41
Abbildung 5.3: Ausreißererkennung
Mithilfe der Integritatskontrolle lassen sich alle Fehler erkennen, die in Abschnitt 5.2 im Zu-
sammenhang mit schemabezogenen Single Source-Problemen genannt werden. Der Erfolg der
Integritatskontrolle hangt dabei im hohen Maß von der Grundlichkeit der Analyse der geltenden
Integritatsbedingungen (Integritatsanalyse) ab.
5.4.3 Ausreißererkennung
Ein weiterer Ansatz ungultige Daten zu erkennen, besteht in der Ausreißererkennung. Bei der
Ausreißererkennung werden die zu bereinigenden Daten auf Muster oder Trends hin untersucht,
denen der Großteil dieser Daten entspricht. Daten, die von diesen Mustern oder Trends abwei-
chen, werden als Ausreißer bezeichnet und als potentielle Fehlerkandidaten betrachtet. Auf diese
Weise konnen auch ungultige Daten erkannt werden, die mithilfe des alleinigen Wissens aus der
Integritatsanalyse nicht erkannt werden wurden. Zur Ausreißererkennung existiert eine Vielzahl
von verschiedenen Verfahren, von denen ein Großteil auf Methoden des Data Mining basiert (z. B.
Clustering- oder Assoziationsregel-Algorithmen). Diese Methoden eignen sich gut zur multiva-
riaten Ausreißererkennung, also zur Erkennung von komplexen Fehlern. Voraussetzung fur die
Anwendung dieser Methoden ist jedoch, dass sehr große Datenbestande zur Verfugung stehen [3].
Wie in Abbildung 5.3 schematisch dargestellt, kann bei einfacheren statistischen Verfahren auf
Basis korrekter Beispieldaten ein statistisches Modell erstellt werden, mit dem spater neu ein-
treffende und zu bereinigende Datensatze verglichen werden. Datensatze, die von diesem Modell
abweichen, werden dann als potentielle Ausreißer betrachtet. Zur kontinuierlichen Verbesserung
des Modells empfiehlt es sich, das Modell in regelmaßigen Abstanden zu aktualisieren.
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 42
Als Beispiel sei ein statistisches Verfahren zur univariaten Ausreißererkennung erwahnt, welches
sich gut zur Erkennung von Ausreißern unter eindimensionalen Messwerten eignet. Das im Fol-
genden beschriebene Verfahren macht sich die Tschebyscheff-Ungleichung zunutze.
Die Tschebyscheff-Ungleichung lautet
� ��� � � � �� � � ���
�
wobei � eine Zufallsvariable ist und die Variablen � und den Durchschnitt und die Standardab-
weichung der Zufallsvariablen � darstellen.
Fur � � � � gilt dann
� ��� � � � �� � �
�����
� fur � ��
�fur � �
�
�fur � �
was beispielsweise bedeutet, dass bei einer Zufallsvariablen � mindestens 75% der Werte im In-
tervall �� � � � � �� liegen (bei speziellen Verteilungen kann dieser Wert bedeutend großer
sein). Demnach weichen Werte, die außerhalb des Intervalls �� � � � � �� liegen, von einem
sehr großen Teil (mindestens 75%) der Daten ab.
Im Kontext der Datenbereinigung lasst sich fur ein Attribut � durch Ermitteln des Durchschnitts
�� und der Standardabweichung � ein statistisches Modell erzeugen. Ein Wert� eines Attributs �
kann dann als Ausreißer in Betracht gezogen werden, wenn fur den Wert� gilt: � � ���� oder
� � ����. Der Wert fur muss an den jeweiligen Anwendungsfall und an die Werteverteilung
des Attributs � angepasst werden [3].
5.5 Die Vorgehensweise
Die in diesem Abschnitt beschriebene Vorgehensweise zur Datenkonsolidierung ist im Wesentli-
chen an die in [4] beschriebene Vorgehensweise angelehnt. Danach stellt die Datenkonsolidierung
einen Prozess dar, der folgende Phasen durchlauft:
1. Datenanalyse
2. Definition des gemeinsamen Zielschemas
3. Definition der Datenbereinigungsprozesse
4. Implementierung der Datenbereinigungsprozesse
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 43
5. Einlesen der Quelldaten und Ausfuhren der Datenbereinigungsprozesse
Die Datenanalyse dient zur Ermittlung des zur Datenintegration erforderlichen Wissens uber die
Dateneigenschaften sowie die auftretenden Datenqualitatsprobleme. Daraufhin wird das Schema
der Zieldatenbank definiert, welches samtliche Daten aus den Quellsystemen aufnehmen kann.
In der anschließenden Phase zur Definition der Datenbereinigungsprozesse werden Regeln fur
notwendige Datentransformationen definiert, die spater bei der eigentlichen Datenintegration zur
Anpassung der Quelldaten an das Zielschema angewendet werden sowie geeignete Methoden zur
Datenbereinigung gewahlt. Schließlich werden Prozesse definiert, die die zeitliche Abfolge zur
Durchfuhrung der notwendigen Transformationen und Bereinigungsschritte festlegen. Nach er-
folgter Implementierung konnen die Daten durch Ausfuhrung der Datenbereinigungsprozesse ein-
gelesen, konsolidiert und in die Datenbank geladen werden.
Im Regelfall sollen die ersten vier Phasen einmalig und die funfte Phase in regelmaßigen Abstanden
wiederholt durchlaufen werden. Bei Bedarf konnen selbstverstandlich vorangegangene Phasen
wiederholt werden, wenn beispielsweise neue Qualitatsmangel in Erscheinung treten oder es einer
Korrektur bzw. Anderung eines Datenbereinigungsprozesses bedarf. In den folgenden Abschnitten
werden die ersten drei Phasen detaillierter beschrieben.
5.5.1 Datenanalyse
Aufgrund der Verteilung der Daten auf verschiedene Systeme ist es im ersten Schritt erforder-
lich, die im Zielsystem abzubildenden Daten zu identifizieren und zu analysieren. Ziel der Ana-
lyse ist es, moglichst gutes Wissen uber die Inhalte und die Struktur der zu integrierenden Daten
zu gewinnen und dabei mogliche Qualitatsprobleme (vgl. Abschnitt 5.2) aufzudecken. Grundla-
ge fur die Datenanalyse sind Dokumentationen zu den Quellsystemen sowie bereits vorhandene
Beispieldaten. Daruber hinaus konnen auch Interviews mit Sachverstandigen weitere notwendige
Informationen liefern. Der Grad der Analyse der Daten ist je nach Anwendungsfall verschieden
und hangt mitunter davon ab, welche Methoden zur Datenbereinigung angewendet werden. In [2]
werden zwei Ansatze zur Datenanalyse genannt.
Beim ersten Ansatz, der als Data Profiling bezeichnet wird, werden im Sinne eines Meta-Re-
engineering durch Sichten der Daten sowie durch Anwenden von einfachen statistischen Methoden
Metadaten uber die einzelnen Attribute ermittelt. In der Regel werden dabei fur jedes im Rahmen
der Datenintegration relevante Attribut folgende Eigenschaften ermittelt:
• Datentyp
• Wertebereich
• typische Muster von Werten bei Zeichenketten
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 44
• Minimale und maximale Lange von Werten
• Minimaler und maximaler Wert bei numerischen Werten
• Vorkommen von Nullwerten
• Eindeutigkeit
• Haufigkeitsverteilung von Werten
• Ermittlung des Durchschnittswertes, des Medians sowie der Standardabweichung bei nu-
merischen Werten
Das Ermitteln der oben genannten Metadaten ist in verschiedener Hinsicht von Bedeutung. Zum
einen stellen die Ergebnisse des Data Profiling eine Grundlage fur die Definition des Zielschemas
sowie von Integritatsbedingungen dar und zum anderen kann das Data Profiling zur Identifizie-
rung von Datenqualitatsproblemen beitragen. Mithilfe der aufgestellten Haufigkeitsverteilungen
und der ermittelten statistischen Kenngroßen wie der Standardabweichung und des Durchschnitts-
wertes konnen spater innerhalb des Datenbereinigungsprozesses falsche Werte (univariate Aus-
reißer) entdeckt werden (vgl. Abschnitt 5.4.3). Statistische Kenngroßen wie Durchschnittswert,
Median und haufigster Wert konnen zur Korrektur von fehlenden oder falschen Werten herange-
zogen werden.
Wie der Vorgang des Data Profiling zur Identifizierung von moglichen Qualitatsproblemen fuhrt,
wird im Folgenden anhand einiger Beispiele erlautert.
Beispiel 1 Tabelle 5.1 zeigt die Statistik eines Attributs, fur welches die Eindeutigkeitseigen-
schaft gilt. Das Abweichen der beiden Werte voneinander zeigt, dass Attributwerte mehrmals vor-
kommen und demnach die Eindeutigkeitseigenschaft verletzt ist.
Anzahl Zeilen 32 056Anzahl verschiedener Werte 32 039
Tabelle 5.1: Statistik zu Beispiel 1
Beispiel 2 In Tabelle 5.2 sind alle in einem Attribut GESCHLECHT vorkommenden Werte so-
wie deren Haufigkeiten aufgefuhrt. Das dreifache Vorkommen des Wertes”S“ lasst auf ungultige
Werte schließen. Handelt es sich bei dem Attribut um ein Pflichtfeld, deuten die Vorkommen des
Wertes NULL auf fehlende Werte in diesem Attribut hin.
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 45
Attribut Inhalt Anzahl Vorkommen
GESCHLECHT M 4 657GESCHLECHT W 4 456GESCHLECHT S 3GESCHLECHT NULL 10
Tabelle 5.2: Statistik zu Beispiel 2
Attribut Inhalt der Quelle 1 Inhalt der Quelle 2
GESCHLECHT M MGESCHLECHT W F
Tabelle 5.3: Statistik zu Beispiel 3
Beispiel 3 In Tabelle 5.3 sind zu zwei verschiedenen Quellen jeweils alle in einem Attribut GE-
SCHLECHT vorkommenden Werte aufgefuhrt. Die unterschiedlichen Werte in den beiden Quel-
len, deuten auf eine uneinheitliche Reprasentation der Daten hin.
Bei den bisher erlauterten Analysen werden die einzelnen Attribute immer isoliert voneinander
betrachtet. Aufgrund von applikationsspezifischen Geschaftsregeln existieren haufig aber auch
Abhangigkeiten zwischen Attributen, die sich sowohl auf mehrere Attribute eines Tupels als auch
auf Attribute mehrerer inhaltlich zusammenhangender Tupel erstrecken konnen. Aus diesem Grund
werden auf Basis der geltenden Geschaftsregeln Integritatsbedingungen definiert, anhand derer
fehlerhafte Daten erkannt werden konnen (vgl. Abschnitt 5.4.2).
Ein zweiter Ansatz im Rahmen der Datenanalyse ist die Anwendung von Data Mining-Methoden,
mit deren Hilfe auch Dateneigenschaften (z. B. Trends, Muster, etc.) aufgedeckt werden konnen,
die nicht ohne weiteres aus Geschaftsregeln abgeleitet werden konnen. Die dabei gewonnenen
Informationen uber die Daten konnen zur Erkennung und Korrektur von fehlerhaften Daten ver-
wendet werden.
Datenqualitatsprobleme, die aus Schema- oder Datenkonflikten resultieren, geben Aufschluss uber
die zur Datenintegration notwendigen Datentransformationen. In diesem Zusammenhang mussen
die Quelldaten auch auf redundante Informationen hin untersucht werden. Dabei werden Attribute
in den Quelldaten ermittelt, die moglicherweise gleiche Informationen beinhalten und somit bei
der Zusammenfuhrung der Quelldaten entfernt werden konnen.
5.5.2 Definition des Zielschemas
Unter Berucksichtigung der in der Datenanalyse gewonnenen Informationen uber die Daten der
Quellsysteme und der dokumentierten Anforderungen wird ein normalisiertes Datenmodell er-
stellt, welches in der Lage ist alle zu integrierenden Daten aufzunehmen. Eine aufwandige Sche-
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 46
maintegration, bei der die lokalen Schemata aus den Quellsystemen in ein einheitliches Schema
uberfuhrt werden und etwaige strukturelle Konflikte beseitigt werden, erubrigt sich in diesem An-
wendungsfall, da die Datenhaltungssysteme der Quellsysteme auf Textdateien basieren und daher
keine komplexen Schemata besitzen. Auf die Probleme, die mit einer Schemaintegration verbun-
den sein konnen, sowie deren Losungsansatze wird daher nicht weiter eingegangen. Die Anforde-
rungen, die bei einer Schemaintegration an das Zielschema gestellt werden, lassen sich allerdings
auf den vorliegenden Anwendungsfall ubertragen und entsprechend anpassen. Die Anforderungen
sind im Folgenden aufgefuhrt:
• Die in den ursprunglichen Quelldateien enthaltenen Informationen sollen vollstandig uber-
nommen werden (Vollstandigkeit)
• Im Zielschema sollen keine redundanten Strukturen vorkommen (Minimalitat)
• Das Zielschema soll verstandlich sein (Verstandlichkeit)
• Die im Zielschema enthaltenen Informationen mussen aquivalent zu den Informationen in
den Quelldateien sein (Korrektheit)
5.5.3 Definition der Datenbereinigungsprozesse
Basierend auf den Ergebnissen der Datenanalyse wird ein so genannter ETL-Prozess (Extraction,
Transformation, Loading) definiert.
In der Extraktionsphase werden die Quelldaten aus den Quellsystemen extrahiert, an den Server
ubertragen und in die Importtabellen eines vom Zielschema abgegrenzten Datenbeschaffungsbe-
reichs importiert. Die Attribute der Importtabellen ergeben sich aus der Analyse der Quellsysteme
und nehmen die Daten auf, die fur die Integration der Daten in das Zielschema benotigt werden.
Beim Importvorgang werden die Daten in der Regel unverandert ubernommen und gegebenenfalls
archiviert, um uber die Moglichkeit einer Wiederherstellung der Originaldaten zu verfugen.
In der anschließenden Transformationsphase werden die notwendigen Transformationen und Be-
reinigungsschritte durchgefuhrt. Hierzu mussen Regeln fur die notwendigen Datentransformatio-
nen bezuglich Struktur und Reprasentation definiert und geeignete Methoden zur Datenbereini-
gung gewahlt werden. Außerdem muss ein Prozess definiert werden, der die zeitliche Abfolge zur
Durchfuhrung der notwendigen Transformationen und Bereinigungsschritte festlegt. Eine Vorga-
be, in welcher Reihenfolge bestimmte Transformations- und Bereinigungsschritte durchgefuhrt
werden sollten, existiert nicht. Sinnvollerweise erfolgt anfangs eine Uberprufung der Daten im
Hinblick auf die syntaktische Korrektheit, da das Erfullen dieses Kriteriums unumganglich fur die
weitergehende Datenbereinigung ist. Die anschließende Behandlung der einzelnen semantischen
Fehler sollte moglichst in Reihenfolge zunehmender Komplexitat erfolgen. Die Transformation
und Bereinigung der Daten erfolgt gewohnlich in einem ebenfalls vom Zielschema abgegrenz-
ten Transformationsbereich (Staging Area), der aus verschiedenen Zwischentabellen besteht. Auf
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 47
diese Weise kann die Aufbereitung der Daten durchgefuhrt werden, ohne dass die Zieltabellen da-
von beeintrachtigt werden. Somit ist gewahrleistet, dass in den Zieltabellen immer nur vollstandig
konsolidierte Daten vorliegen. Nach Durchlaufen der Transformationsphase liegen im Transfor-
mationsbereich die Quelldaten in einer Form vor, wie sie in das Zielschema ubernommen werden
konnen.
In der Ladephase werden die bereinigten Daten schließlich in das Zielsystem ubertragen.
Kapitel 6
Datenkonsolidierung
In diesem Kapitel wird die in Kapitel 5 beschriebene Vorgehensweise zur Datenkonsolidierung auf
den vorliegenden Anwendungsfall angewendet. Im folgenden Abschnitt wird zunachst eine Analy-
se der einzelnen Quellsysteme durchgefuhrt (Abschnitt 6.1). Basierend auf den dabei gewonnenen
Informationen werden im Anschluss ein einheitliches Zielschema erstellt (Abschnitt 6.2) und die
notwendigen Datenbereinigungsprozesse definiert (Abschnitt 6.3). Auf die Implementierung der
Datenbereinigungsprozesse wird in Kapitel 7 eingegangen.
6.1 Datenanalyse
Zur Durchfuhrung der Datenanalyse wurden vorhandene Prozessdaten aus den bestehenden Da-
tenhaltungssystemen in Tabellen einer Oracle-Datenbank importiert. Damit war es moglich, mit-
tels der Abfragesprache SQL einzelne Datenabfragen effizient durchzufuhren, um sich ein Bild
uber die vorhandenen Daten und Qualitatsprobleme zu machen. In den folgenden Abschnitten wer-
den die Metadaten sowie weitere Integritatsbedingungen der einzelnen Quellsysteme aufgefuhrt,
außerdem werden die Single Source-Probleme der Quellsysteme beschrieben. Syntaktisch falsche
oder fehlende Werte konnen in fast allen Quellsystemen vorkommen. Erfolgt am Operationsstand
OP090 ein Austausch einer Komponente aus der Wellenvormontage, konnen der Ersatzkomponen-
te keine Schraub- und Presskraftdatensatze zugeordnet werden, da beim Austausch die virtuelle
Kennung der Ersatzkomponente nicht erfasst wird. Dieser Fall fuhrt demnach zum Verlust von
Schraub- und Presskraftdatensatzen. Die eben genannten Qualitatsprobleme werden in den fol-
genden Abschnitten nicht jedes Mal explizit genannt. Auf Multi Source-Probleme wird in einem
separaten Abschnitt eingegangen.
6.1.1 Kombinationsdaten
Die Metadaten der Kombinationsdaten ergeben sich im Wesentlichen aus [7] und sind in Tabel-
le 6.1 dargestellt. Die Getriebe-Seriennumner besteht aus 13 ASCII-Zeichen und hat folgenden
48
KAPITEL 6. DATENKONSOLIDIERUNG 49
Aufbau:
Stelle Bedeutung
1-3 Kurzel fur das Werk (R-- = Russelsheim)
4+5 Produktionsjahr (verfugt das Getriebe uber eine SAAB-Kunden-Seriennummer, wird
die Angabe fur das Produktionsjahr auf”00“ gesetzt)
6-11 fortlaufende Nummer
12+13 zweistelliger Alpha-Code, der den Getriebetyp angibt
Da die Zusammensetzungen der Kunden-Seriennummern fur diese Arbeit nicht relevant sind, wird
auf diese nicht weiter eingegangen.
Feldname Datentyp Wertebereich Min./Max.Lange
ID OPEL (Getriebe-Seriennummer)
Text wird durch den regularen Aus-druck R–[0-9]�8�[A-Z]�2� be-schrieben
13 / 13
ID FIAT (FIAT-Kunden-Seriennummer)
Text wird durch den regularenAusdruck [0-9]�2�-[0-9]�1�-[0-9]�3�-[0-9]�7� beschrieben
16 / 16
ID SAAB (SAAB-Kunden-Seriennummer)
Text wird durch den re-gularen Ausdruck FM6[0-9]�1�[4,5,B]�1�[A-Z]�5�[0-9]�3� beschrieben
13 / 13
TIMESTAMP (Zeitpunkt derErfassung)
Datum Format: dd.MM.yyyy hh:mm:ss
V ID1 bis V ID6 (Virtuel-le Kennungen der StationenST040, ST060, ST070, ST080,ST110, ST120)
Text achtstellige Zeichenkette 8 / 8
Tabelle 6.1: Metadaten der Kombinationsdaten
Weitere Integritatsbedingungen
• Alle Felder sind eindeutig.
• Abgesehen von den Feldern ID FIAT und ID SAAB sind alle Felder Pflichtfelder.
• Einem Getriebe kann nur eine Kunden-Seriennummer zugewiesen sein� ID FIAT != NULL
XOR ID SAAB != NULL
KAPITEL 6. DATENKONSOLIDIERUNG 50
Single Source-Probleme
Aufgrund von Erfassungsfehlern durch die Software an der Station ST140 weisen die Kombina-
tionsdaten relativ viele fehlende oder abgeschnittene Werte in allen Feldern mit Ausnahme des
Feldes TIMESTAMP auf. In einigen Zeitraumen sind 10% der Datensatze fehlerhaft. Das Feh-
len eines Wertes im Feld ID OPEL tritt offensichtlich auf, wenn ein Getriebe wiederholt in die
Station ST140 eingeschleust wird, da das Einfugen eines Datensatzes mit einer bereits existen-
ten Getriebe-Seriennummer dazu fuhrt, dass der Datensatz zwar eingefugt wird, aber das Feld
ID OPEL leer bleibt. Daruber hinaus fuhrt das wiederholte Einschleusen eines Getriebes an der
Station ST140 und das damit verbundene erneute Erfassen der Kombinationsdaten zur Verletzung
der Eindeutigkeitseigenschaft in den Feldern V ID1, V ID2, V ID3, V ID4, V ID5 und V ID6.
Wird bei einer erneuten Einschleusung ein anderer Wellensatz als bei der vorangegangen Ein-
schleusung verwendet, weisen die Datensatze der beiden Einschleusungen in den Feldern V ID1,
V ID2, V ID3, V ID4, V ID5 und V ID6 unterschiedliche Werte auf.
6.1.2 Presskraftdaten
Obwohl sich die DFQ-Dateien der einzelnen Quellsysteme in ihrer Merkmalsstruktur unterschei-
den, sind die zu einer einzelnen Pressoperation erfassten Datenfelder in allen Quellsystemen iden-
tisch. Aus diesem Grund werden in diesem Abschnitt die Presskraftdaten aller Quellsysteme ge-
meinsam behandelt. In Tabelle 6.2 sind die Metadaten der Presskraftdaten aufgefuhrt. Da die
Felder in den DFQ-Dateien lediglich uber ihre Schlussel identifiziert werden, sind zur besseren
Lesbarkeit zusatzlich frei vergebene Feldnamen angegeben, die spater teilweise auch bei der De-
finition des Zielschemas verwendet werden.
Das Feld PART NUMBER beinhaltet die Seriennummer des bearbeiteten Teils. Stammt der Da-
tensatz von einer Montage-Station aus der Vormontage, so ist die Seriennummer die achtstellige
virtuelle Kennung, ansonsten die 13-stellige Getriebe-Seriennummer. Das Feld ATTRIBUTE spei-
chert einen Fehlercode zwischen 0 und 255. Der Wert”0“ bedeutet, dass die Operation sowie die
Messung erfolgreich waren. Die gultigen Werte fur die Felder STATION und SPINDLE sowie de-
ren gultige Wertekombination ergeben sich aus den gestellten Anforderungen (vgl. Abschnitt 3.2).
An der funften Pressspindel der Station ST110 sowie an allen Pressspindeln der Station ST140
wird jedes Teil zweimal bearbeitet. Hieraus ergeben sich der Wertebereich fur das Feld STEP so-
wie die gultigen Wertekombinationen der Felder STATION, SPINDLE und STEP. Die Werte der
Felder MEASUREMENT VALUE DIM1 (Einpresstiefe) und MEASUREMENT VALUE DIM2
(Einpresskraft) hangen von den Grenzwerteinstellungen an den Montage-Stationen ab, die in
den Feldern LOWER LIMIT DIM1 (Unterer Grenzwert fur Einpresstiefe), UPPER LIMIT DIM1
(Oberer Grenzwert fur die Einpresstiefe), LOWER LIMIT DIM2 (Unterer Grenzwert fur die Ein-
presskraft) und UPPER LIMIT DIM2 (Oberer Grenzwert fur Einpresskraft) ubertragen werden.
KAPITEL 6. DATENKONSOLIDIERUNG 51
Feldname Datentyp Wertebereich Min./Max.Lange
K0006 - PART NUMBER(Teile-Seriennummer)
Text wird durch den regularen Aus-druck R–[0-9]�8�[A-Z]�2� be-schrieben; bei Daten, die an denStationen ST040, ST110, ST120erzeugt werden: achtstellige Zei-chenkette
13 / 13bzw. 8 / 8
K0002 - ATTRIBUTE (Fehler-code)
ganzeZahl
[0;255]
K0008 - STATION (Station) Text �040, 110, 120, 140, 160� 3 / 3K0007 - SPINDLE (Spindel) ganze
Zahl[1;9]
STEP (Schritt) ganzeZahl
[1;2]
K0004 - TSTAMP (Erfassungs-datum)
Datum Format: dd.MM.yyyy/hh:mm:ss
K2110 - LOWER LIMIT DIM1(Untere Grenze fur Einpresstie-fe)
Zahl � 0
K2111 - UPPER LIMIT DIM1(Obere Grenze fur Einpresstiefe)
Zahl � 0
K2110 - LOWER LIMIT DIM2(Untere Grenze fur Einpres-skraft)
Zahl
K2111 - UPPER LIMIT DIM2(Obere Grenze fur Einpres-skraft)
Zahl
K0001 - MEASURE-MENT VALUE DIM1(Messwert fur Einpresstie-fe)
Zahl � 0
K0001 - MEASURE-MENT VALUE DIM2(Messwert fur Einpresskraft)
Zahl
Tabelle 6.2: Metadaten der Presskraftdaten
KAPITEL 6. DATENKONSOLIDIERUNG 52
Datensatze erfolgreicher Pressoperationen durfen selbstverstandlich nur Messwerte beinhalten,
die innerhalb der jeweiligen Grenzwerteinstellungen liegen. Im Laufe der Zeit andern sich die
Grenzwerteinstellungen an den Montage-Stationen, so dass sich auch die Werteverteilungen in
den Feldern fur die Einpresstiefe und die Einpresskraft andern. Inwiefern sich die Grenzwertein-
stellungen zukunftig andern werden, lasst sich aufgrund der in der Montagelinie herrschenden
Unwagbarkeiten nicht vorhersagen.
Im Allgemeinen definiert die Abteilung Fertigungsplanung Vorgaben fur die an den Montage-
Stationen einzustellenden Grenzwerte fur die Einpresskraft. Diese Vorgaben werden jedoch von
der Abteilung Getriebefertigung nicht immer eingehalten. Hierfur ist in erster Linie ein gewisser
Interessenskonflikt zwischen den beiden Abteilungen verantwortlich.
Die Abteilung Fertigungsplanung hat ein Interesse an mechanisch einwandfrei funktionierenden
Getrieben in hoher Fertigungsqualitat und gibt der Abteilung Getriebefertigung Grenzwerte fur
die einzelnen Pressoperationen vor, die unverbindliche Richtwerte darstellen. Bei der Vorgabe der
Grenzwerte werden Aspekte der Schaltbarkeit, der Oldichtigkeit und der mechanischen Dauer-
belastbarkeit berucksichtigt. Dies kann bedeuten, dass eine niedrigere Produktionszahl angestrebt
wird, wenn dabei gleichzeitig die Qualitat des einzelnen Getriebes steigt. Vorteile dieses Vorge-
hens sind weniger Garantierucknahmen und geringere Ausschusskosten.
Die Abteilung Getriebefertigung dagegen hat ein Interesse an einer storungsfrei gefertigten hohen
Produktionszahl. Zur Erreichung dieses Ziels wird mit einer geringeren Prazision, also mit brei-
teren Toleranzbereichen produziert, was nicht im Sinne einer hohen Fertigungsqualitat ist, aber
dennoch zu akzeptablen Ergebnissen fuhren kann.
Aufgrund von Informationen seitens der Planungsabteilung kann jedoch die Aussage getroffen
werden, dass sich voraussichtlich die eingestellten Grenzwerte fur die Einpresskraft, unabhangig
von der angestrebten Fertigungsprazision, innerhalb der in Tabelle 6.3 aufgefuhrten Toleranzberei-
che bewegen werden. Werte, die nicht innerhalb der aufgefuhrten Toleranzbereiche liegen, konnen
also als falsche Werte (z. B. durch Erfassungs- oder Ubertragungsfehler verursacht) betrachtet
werden. Analysen von Beispieldaten haben allerdings ergeben, dass bei vereinzelten Spindeln der
Wert fur den unteren Grenzwert fur die Einpresskraft beabsichtigt im negativen Bereich liegt.
Grenzwerteinstellungen im negativen Bereich sind physikalisch unsinnig und werden lediglich
aus betriebstechnischen Grunden vorgenommen. Aus diesem Grund wird der Wertebereich fur
das Feld LOWER LIMIT DIM2 (Unterer Grenzwert fur die Einpresskraft) in den negativen Be-
reich ausgedehnt.
In welchen Bereichen sich die an den Montage-Stationen eingestellten Grenzwerte fur die Ein-
presstiefe und damit auch die Messwerte fur die Einpresstiefe bewegen werden, lasst sich aus
heutiger Sicht nicht beurteilen. Die an den Montage-Stationen eingestellten Grenzwerte fur die
Einpresstiefe werden von der Abteilung Getriebefertigung bestimmt und konnen sich ebenfalls
im Laufe der Zeit aufgrund verschiedener betriebsbedingter Faktoren andern. Fur die Grenzwerte
der Einpresstiefe existieren auch keine Vorgaben seitens der Abteilung Fertigungsplanung, da die
KAPITEL 6. DATENKONSOLIDIERUNG 53
Station Spindel ToleranzbereichAnpresskraft(kN)
Station Spindel ToleranzbereichAnpresskraft(kN)
ST040 1 ]0;15] ST120 7 ]0;10]ST110 1 ]0;8] ST120 8 ]0;10]ST110 2 ]0;8] ST120 9 ]0;8]ST110 3 ]0;8] ST140 1 ]0;10]ST110 4 ]0;8] ST140 2 ]0;10]ST110 5 ]0;8] ST140 3 ]0;10]ST120 1 ]0;8] ST140 4 ]0;10]ST120 2 ]0;8] ST160 1 ]0;15]ST120 3 ]0;8] ST160 2 ]0;10]ST120 4 ]0;8] ST160 3 ]0;10]ST120 5 ]0;10] ST160 4 ]0;10]ST120 6 ]0;10]
Tabelle 6.3: Toleranzbereiche fur Pressoperationen
Werte fur die Einpresstiefe keine hohe Relevanz haben. Entscheidend ist, dass bei einer Operation
die angestrebte Einpresskraft erreicht wird, um die ausreichende Festigkeit der Pressverbindung
zu gewahrleisten. Aufgrund der genannten Unwagbarkeiten in der Montagelinie lassen sich also
anhand von Beispieldaten keine Aussagen uber die Werteverteilung in den genannten Feldern so-
wie uber die Beziehung zwischen den Feldern fur die Einpresstiefe und die Einpresskraft treffen.
Aus diesem Grund soll auf weitere statistische Analysen der Presskraftdaten verzichtet werden.
Weitere Integritatsbedingungen
1. Alle Felder sind Pflichtfelder.
2. Fur die Kombination der Felder (PART NUMBER, STATION, SPINDLE, STEP) gilt die
Eindeutigkeitseigenschaft.
3. Der Messwert fur die Einpresstiefe liegt zwischen dem unteren und dem oberen Grenzwert
fur die Einpresstiefe
� LOWER LIMIT DIM1 �MEASURING VALUE DIM1 � UPPER LIMIT DIM1
4. Der Messwert fur die Einpresskraft liegt zwischen dem unteren und dem oberen Grenzwert
fur die Einpresskraft
� LOWER LIMIT DIM2 �MEASURING VALUE DIM2 � UPPER LIMIT DIM2
Single Source-Probleme
Wird bei einem Getriebe eine Pressoperation wiederholt, so wird die Eindeutigkeitseigenschaft
der Feldkombination (PART NUMBER, STATION, SPINDLE, STEP) verletzt.
KAPITEL 6. DATENKONSOLIDIERUNG 54
Station Spindel ToleranzbereichDrehwinkel (°)
Sollwert Drehmo-ment (Nm)
ToleranzbereichDrehmoment(Nm)
ST040 1 [45;105] 60 [30;150]ST040 2 [45;60] 30 [20;75]ST110 1 - 20 [18;22]ST110 2 - 10 [8;12]ST120 1 - 10 [8;12]ST140 1 - 45 [38;52]
Tabelle 6.4: Sollwerte und Toleranzbereiche fur Schrauboperationen
Semantisch falsche Messwerte in Form von Ausreißern, die durch Fehlmessungen verursacht wer-
den, werden in der Regel direkt von dem jeweiligen Messsystem erkannt. In diesem Fall wird der
entsprechende Datensatz mit einem Fehlercode versehen.
Semantisch falsche Werte, verursacht durch nachgeschaltete Datenebereinigungsprozesse (z. B.
Datenspeicherung, Datenubertragung oder Datenimport), sind jedoch nicht auszuschließen.
6.1.3 Schraubkraftdaten
Wie bei den Pressoperationen sind die bei einer Schrauboperation erfassten Datenfelder in allen
Quellsystemen identisch. Aus diesem Grund werden auch die Schraubkraftdaten aller Quellsyste-
me in einem gemeinsamen Abschnitt behandelt. In Tabelle 6.5 sind die Metadaten der Schraub-
kraftdaten aufgefuhrt. Auch hier sind zur besseren Lesbarkeit zusatzlich frei vergebene Feldnamen
angegeben.
Die Wertebereiche der Felder PART NUMBER und ATTRIBUTE sind identisch mit denen der
gleichnamigen Felder der Presskraftdaten. Die gultigen Werte fur die Felder SPINDLE und STA-
TION sowie deren gultige Wertekombinationen ergeben sich bei den Schraubkraftdaten ebenfalls
aus den gestellten Anforderungen (vgl. Abschnitt 3.2). Wie bei den Pressvorrichtungen konnen
sich im Laufe der Zeit die Grenzwerteinstellungen an den Schraubvorrichtungen und damit auch
die Wertebereiche der Felder fur den Drehwinkel und das Drehmoment andern. Prazisere Aussa-
gen uber die Eigenschaften der Felder MEASUREMENT VALUE DIM2 (Drehmoment), LOW-
ER LIMIT DIM2 (Unterer Grenzwert fur das Drehmoment) und UPPER LIMIT DIM2 (Oberer
Grenzwert fur das Drehmoment) lassen sich aus den Vorgaben fur die Sollwerte seitens der Abtei-
lung Fertigungsplanung, die in Tabelle 6.4 aufgefuhrt sind, ableiten. Die eingesetzten Schrauber
sind sehr prazise und erreichen in der Regel den Sollwert fur das Drehmoment mit einer Abwei-
chung von +/- 0,5 Nm. Starker abweichende Drehmomente, die jedoch innerhalb der aufgefuhrten
Toleranzbereiche liegen, konnen trotzdem zu akzeptablen Ergebnissen fuhren. Die Grenzwert-
einstellungen an den Montage-Stationen werden von der Abteilung Getriebefertigung vorgenom-
KAPITEL 6. DATENKONSOLIDIERUNG 55
men und konnen sich im Lauf der Zeit andern. Bei der Bemessung der Grenzwerte steht in erster
Linie ein reibungsloser Montageprozess im Vordergrund, dabei werden unter Umstanden auch
Faktoren wie z. B. der aktuell verwendete Schraubentyp oder der aktuell montierte Getriebetyp
berucksichtigt. Voraussichtlich werden sich die eingestellten Grenzwerte jedoch innerhalb der in
Tabelle 6.4 aufgefuhrten Toleranzbereiche bewegen. Wie bei den Presskraftdaten konnen also Wer-
te, die nicht innerhalb der angegebenen Toleranzbereiche liegen, als falsche Werte betrachtet wer-
den.
In welchen Bereichen sich die an den Montage-Stationen eingestellten Grenzwerte und damit
auch die Messwerte fur den Drehwinkel bewegen werden, lasst sich aus heutiger Sicht nur fur
die Schraubspindeln der Station ST040 beurteilen (vgl. Tabelle 6.4). Fur die Spindeln der ubrigen
Stationen existieren auch keine Vorgaben fur den Drehwinkel seitens der Abteilung Fertigungs-
planung, da bei diesen Spindeln die Zahl der ausgefuhrten Umdrehungen keine Relevanz hat.
Entscheidend ist lediglich, dass das geforderte Drehmoment erreicht wird, um die notwendige Fe-
stigkeit der Schraubenverbindung zu gewahrleisten.
Wie bei den Presskraftdaten soll auf weitere statistische Analysen der Schraubkraftdaten verzichtet
werden.
Weitere Integritatsbedingungen
1. Alle Felder sind Pflichtfelder.
2. Fur die Kombination der Felder (PART NUMBER, STATION, SPINDLE) gilt die Eindeu-
tigkeitseigenschaft.
3. Der Messwert fur Drehwinkel liegt zwischen dem unteren und dem oberen Grenzwert fur
den Drehwinkel
� LOWER LIMIT DIM1 �MEASURING VALUE DIM1 � UPPER LIMIT DIM1
4. Der Messwert fur Drehmoment liegt zwischen dem unteren und dem oberen Grenzwert fur
das Drehmoment
� LOWER LIMIT DIM2 �MEASURING VALUE DIM2 � UPPER LIMIT DIM2
Single Source-Probleme
Wird bei einem Getriebe eine Schrauboperation wiederholt, so wird die Eindeutigkeitseigenschaft
der Feldkombination (PART NUMBER, STATION, SPINDLE) verletzt.
Es konnen ganze Schraubkraftdatensatze fehlen, wenn aufgrund eines Ausfalls einer Schraubspin-
del die entsprechenden Verschraubungen mithilfe eines Handschraubers durchgefuhrt werden.
Auch bei Schrauboperationen werden semantisch falsche Messwerte in Form von Ausreißern von
dem jeweiligen Messsystem erkannt.
KAPITEL 6. DATENKONSOLIDIERUNG 56
Feldname Datentyp Wertebereich Min./Max.Lange
K0006 - PART NUMBER(Teile-Seriennummer)
Text wird durch den regularen Aus-druck R–[0-9]�8�[A-Z]�2� be-schrieben; bei Daten, die an denStationen ST040, ST110, ST120erzeugt werden: achtstellige Zei-chenkette
13 / 13bzw. 8 / 8
K0002 - ATTRIBUTE (Fehler-code)
ganzeZahl
[0;255]
K0008 - STATION (Station) Text �040, 110, 120, 140� 3 / 3K0007 - SPINDLE (Spindel) ganze
Zahl[1;2]
K0004 - TSTAMP (Erfassungs-datum)
Datum Format: dd.MM.yyyy/hh:mm:ss
K2110 - LOWER LIMIT DIM1(Untere Grenze fur Drehwinkel)
Zahl
K2111 - UPPER LIMIT DIM1(Obere Grenze fur Drehwinkel)
Zahl
K2110 - LOWER LIMIT DIM2(Untere Grenze fur Drehmo-ment)
Zahl
K2111 - UPPER LIMIT DIM2(Obere Grenze fur Drehmo-ment)
Zahl
K0001 - MEASURE-MENT VALUE DIM1(Messwert fur Drehwinkel)
Zahl
K0001 - MEASURE-MENT VALUE DIM2(Messwert fur Drehmoment)
Zahl
Tabelle 6.5: Metadaten der Schraubkraftdaten
KAPITEL 6. DATENKONSOLIDIERUNG 57
Feldname Datentyp Wertebereich Min./Max.Lange
OPEL ID (Getriebe-Seriennummer)
Text wird durch den regularen Aus-druck R–[0-9]�8�[A-Z]�2� be-schrieben
13 / 13
SHIM CLASS (Shim-Klasse) ganzeZahl
[1,25]
SHAFT (Art der Komponente) Text �HWO, HWU, AWE, DIF�,(HWO = Hauptwelle oben,HWU = Hauptwelle unten,AWE = Antriebswelle, DIF =Differentialgehause)
3 / 3
TSTAMP (Zeitpunkt der Erfas-sung)
Datum Format: dd.MM.yyyy hh:mm:ss
Tabelle 6.6: Metadaten der Shim-Daten
6.1.4 Shim-Daten
Die Metadaten der Shim-Daten sind in Tabelle 6.6 aufgefuhrt. Das Feld OPEL ID beinhaltet die
13-stellige Getriebe-Seriennummer. Das Feld SHIM CLASS beinhaltet nicht die absolute Angabe
fur die Shim-Große, sondern einen Wert zwischen 1 und 25. Jeder Wert reprasentiert dabei eine
Shim-Große (Shim-Klasse). Der Wertebereich des Feldes SHAFT setzt sich aus vier dreistelligen
Kurzeln zusammen, die jeweils eine Komponentenart reprasentieren.
Weitere Integritatsbedingungen
• Fur die Kombination der Felder (OPEL ID, SHAFT) gilt die Eindeutigkeitseigenschaft.
• Alle Felder sind Pflichtfelder.
• Das Feld OPEL ID ist ein Fremdschlussel, der die Kombinationsdaten referenziert.
Single Source-Probleme
Die Eindeutigkeitseigenschaft der Feldkombination (OPEL ID, SHAFT) wird verletzt, wenn ein
Getriebe die Station ST150 wiederholt durchlauft.
6.1.5 Ausschleusungsdaten
Die Metadaten der Ausschleusungsdaten sind in Tabelle 6.7 aufgefuhrt.
KAPITEL 6. DATENKONSOLIDIERUNG 58
Feldname Datentyp Wertebereich Min./Max.Lange
OPEL ID (Getriebe-Seriennummer)
Text wird durch den regularen Aus-druck R–[0-9]�8�[A-Z]�2� be-schrieben
13 / 13
TSTAMP (Zeitpunkt der Aus-schleusung)
Datum Format: dd.MM.yyyy hh:mm:ss
Tabelle 6.7: Metadaten der Ausschleusungsdaten
Weitere Integritatsbedingungen
• Fur das Feld OPEL ID gilt die Eindeutigkeitseigenschaft.
• Beide Felder sind Pflichtfelder.
• Das Feld OPEL ID ist ein Fremdschlussel, der die Kombinationsdaten referenziert.
Single Source-Probleme
Die Eindeutigkeitseigenschaft des Feldes OPEL ID wird verletzt, wenn ein Getriebe die Station
ST300 wiederholt durchlauft.
6.1.6 Beziehungen zwischen den Quellen und Multi Source-Probleme
Fremdschlusselbeziehungen zwischen den Daten der einzelnen Quellsysteme wurden bereits be-
schrieben.
Der Ablauf des Montageprozesses, also die Reihenfolge der durchgefuhrten Operationen, ist sta-
tisch. Aus diesem Grund mussen die Zeitstempel der einzelnen Datensatze bezuglich eines Ge-
triebes zeitchronologisch in der Reihenfolge liegen, wie die entsprechenden Operationen in der
Montagelinie durchgefuhrt werden. Aufgrund einer nicht funktionierenden Synchronisierung der
Zeiteinstellungen an den Montage-Stationen kann es allerdings zu widerspruchlichen Zeitangaben
kommen. Infolge von Aus- und Einschleusungen konnen sich die Reihenfolgen der Paletten in
der Montagelinie andern. Eine Operation kann nur durchgefuhrt werden, wenn alle ihre vorange-
gangenen Operationen erfolgreich durchgefuhrt wurden. Wird eine Operation wiederholt, mussen
zwangsweise auch alle nachfolgenden Operationen wiederholt werden, was zur Folge hat, dass die
bereits erfassten Messwerte der nachfolgenden Operationen ungultig werden. Dieser Fall tritt ein,
wenn ein Getriebe ausgeschleust, auseinandergebaut und nicht wieder in dieselbe Station, sondern
einige Stationen vorher eingeschleust wird.
Aus Interviews mit Fertigungsplanern geht hervor, dass keine wechselseitigen Einflusse zwischen
Operationen, die dasselbe Getriebe bearbeiten, bekannt sind. Demnach existieren, abgesehen von
KAPITEL 6. DATENKONSOLIDIERUNG 59
den Beziehungen bezuglich der Fremdschlussel und der Zeitstempel, keinerlei Abhangigkeiten
zwischen den einzelnen Datensatzen, aus denen weitere Integritatsbedingungen abgeleitet werden
konnen.
Aufgrund der standardisierten Speicherung der Schraub- und Presskraftdaten existieren keine we-
sentlichen Multi Source-Probleme. Die erfassten Merkmale bei einer Operation sowie die zu de-
ren Speicherung verwendete Datenreprasentation, sind bei allen Quellsystemen identisch. In allen
DFQ-Dateien werden dieselben Datumsformate sowie bei Messwerten und Grenzwerteinstellun-
gen dieselben Messeinheiten verwendet. Es wird lediglich in den DFQ-Dateien ein anderes Da-
tumsformat verwendet als in den Dateien der ubrigen Quellsysteme. Außerdem ist die Prazision
in den Feldern fur die Grenzwerte und die tatsachlich gemessenen Werte bei den Schraub- und
Presskraftdaten deutlich hoher als jene, die in den Anforderungen definiert wurde. Des Weiteren
existieren keine Datenuberlappungen. Wenn man von den Daten aus der Wellen- und Gehause-
vormontage absieht, ist das einander Zuordnen aller Datensatze einer Getriebe-Entitat problemlos
moglich, da die Getriebe-Seriennummer als globaler Schlussel fungiert.
6.2 Definition des Zielschemas
In diesem Abschnitt wird das logische Datenbankmodell des Zielsystems vorgestellt, dabei werden
die einzelnen Tabellen in ihrem Aufbau und deren Beziehungen zueinander beschrieben. Abbil-
dung 6.1 zeigt eine Gesamtubersicht der Tabellen ohne die Fehlertabellen.
Die Tabelle TRANSMISSION
Jedes montierte Getriebe wird mit seiner Getriebe-Seriennummer in der Tabelle TRANSMIS-
SION (vgl. Tabelle 6.8) erfasst. Die Spalte OPEL ID speichert die Getriebe-Seriennummer und
dient als Primarschlussel. Wird das Getriebe fur die Kunden Fiat oder Saab montiert, so wird die
entsprechende Kunden-Seriennummer in die Spalte CUSTOMER ID geschrieben. Die Spalte DA-
TE EXIT speichert den Zeitpunkt, zu dem das Getriebe die letzte Montage-Station (ST300) und
somit die Montagelinie verlassen hat. Die Spalte DATE INSERT speichert den Einfugezeitpunkt
des Datensatzes.
Die Tabelle STATION
Diese Tabelle (vgl. Tabelle 6.9) speichert alle qualitatsrelevanten Montage-Stationen. Die Spal-
te STATION ID stellt den Primarschlussel der Tabelle dar. Die Spalten STATION NAME, IN-
VENTORY NO und MANUFACTURER dienen zur Erfassung weiterer optionaler Angaben wie
Beschreibung, Inventarnummer und Hersteller der Montage-Station zur Anzeige im Frontend.
KAPITEL 6. DATENKONSOLIDIERUNG 60
TRANSMISSION
PK OPEL_ID
CUSTOMER_IDDATE_EXITDATE_INSERT
PRESSING_OPERATION
PK OP_ID
SPINDLESTEPLOWER_FORCE_TESTUPPER_FORCE_TEST
FK1 STATION_ID
STATION
PK STATION_ID
STATION_NAMEINVENTORY_NOMANUFACTURER
SHIM
PK,FK1 OPEL_IDPK SHAFT
SHIM_CLASSTSTAMP
PRESSING
PK,FK1 OP_IDPK,FK2 OPEL_ID
FK3 LIMIT_IDFORCEDISTANCETSTAMP
SCREWING
PK,FK3 OPEL_IDPK,FK2 OP_ID
FK1 LIMIT_IDANGLETORQUETSTAMP
LIMIT_PRESSING
PK LIMIT_ID
LOWER_LIMIT_DISTANCEUPPER_LIMIT_DISTANCELOWER_LIMIT_FORCEUPPER_LIMIT_FORCE
LIMIT_SCREWING
PK LIMIT_ID
LOWER_LIMIT_ANGLEUPPER_LIMIT_ANGLELOWER_LIMIT_TORQUEUPPER_LIMIT_TORQUE
SCREWING_OPERATION
PK OP_ID
SPINDLELOWER_TORQUE_TESTUPPER_TORQUE_TEST
FK1 STATION_IDLOWER_ANGLE_TESTUPPER_ANGLE_TEST
IMPORT_COMBINATION
PK DATE_ST140
OPEL_IDFIAT_IDSAAB_IDVID_ST040VID_ST110VID_ST120
COMBINATION
PK OPEL_IDPK STATION_ID
VIRTUAL_IDDATE_ST140DATE_INSERT
IMPORT_MEASUREMENT
PK PART_NUMBERPK SPINDLEPK STATIONPK STEPPK TYPE
ATTRIBUTELOWER_LIMIT_DIM1LOWER_LIMIT_DIM2MEASURING_VALUE_DIM1MEASURING_VALUE_DIM2TSTAMPUPPER_LIMIT_DIM1UPPER_LIMIT_DIM2DATE_INSERT
SYSTEM_PARAM
PK ATTRIBUTE
VALUE
Zieltabellen
Importtabellen
Abbildung 6.1: Logisches Datenbankmodell (ohne Fehlertabellen)
KAPITEL 6. DATENKONSOLIDIERUNG 61
Feldname Datentyp Beschreibung Beispiel
OPEL ID CHAR(13) Getriebe-Seriennummer
R--04123456MH
CUSTOMER ID VARCHAR2(16) Kunden-Seriennummer
M68102P0010
DATE INSERT DATE Einfugedatum 07.01.04 12:13:46DATE EXIT DATE Zeitpunkt der Aus-
schleusung06.01.04 19:17:56
Tabelle 6.8: Die Tabelle TRANSMISSION
Feldname Datentyp Beschreibung Beispiel
STATION ID CHAR(3) Stationsnummer 140STATION NAME VARCHAR2(20) Stationsname Station 140INVENTORY NO VARCHAR2(6) Inventarnummer 745552MANUFACTURER VARCHAR2(20) Herstellername LSW
Tabelle 6.9: Die Tabelle STATION
Die Tabelle SCREWING OPERATION
Jeder Eintrag in der Tabelle SCREWING OPERATION (vgl. Tabelle 6.10) reprasentiert eine qua-
litatsrelevante Schrauboperation in der Montagelinie. Die Spalte STATION ID stellt einen Fremd-
schlussel dar und referenziert auf die gleichnamige Spalte der Tabelle STATION, so dass je-
der Schrauboperation die Station zugeordnet wird, an der die Operation durchgefuhrt wird. Die
Spalte SPINDLE speichert die Spindelnummer. Die Spalte OP ID stellt einen kunstlich erzeug-
ten Primarschlussel dar und speichert Werte, die durch die Kombination der Werte in den Spal-
ten STATION ID und SPINDLE erzeugt werden. In den Spalten LOWER ANGLE TEST, UP-
PER ANGLE TEST, LOWER TORQUE TEST und UPPER TORQUE TEST werden die in Ta-
belle 6.4 aufgefuhrten Toleranzbereiche fur den Drehwinkel sowie das Drehmoment erfasst. Die
Toleranzbereiche werden zur Datenbereinigung neu eintreffender Schraubkraftdaten verwendet
(vgl. Abschnitte 6.1.3 und 6.3.2).
Die Tabelle PRESSING OPERATION
Jeder Eintrag in der Tabelle PRESSING OPERATION (vgl. Tabelle 6.11) reprasentiert eine qua-
litatsrelevante Pressoperation in der Montagelinie. Auch in dieser Tabelle stellt die Spalte STA-
TION ID einen Fremdschlussel dar. Die Spalten SPINDLE und STEP speichern die Spindel- und
Schrittnummer. Die Spalte OP ID stellt einen kunstlich erzeugten Primarschlussel dar und spei-
chert Werte, die durch die Kombination der Werte in den Spalten STATION ID, SPINDLE und
STEP erzeugt werden. In den Spalten LOWER FORCE TEST und UPPER FORCE TEST wer-
KAPITEL 6. DATENKONSOLIDIERUNG 62
Feldname Datentyp Beschreibung Beispiel
OP ID CHAR(5) Kunstlich erzeugterPrimarschlussel
14002
STATION ID CHAR(3) Stationsnummer 140SPINDLE NUMBER(2) Spindelnummer 2LOWER ANGLE TEST NUMBER(6,2) Unterer Prufwinkel 40.00UPPER ANGLE TEST NUMBER(6,2) Oberer Prufwinkel 120.00LOWER TORQUE TEST NUMBER(6,2) Unteres Prufmoment 2.00UPPER TORQUE TEST NUMBER(6,2) Oberes Prufmoment 14.00
Tabelle 6.10: Die Tabelle SCREWING OPERATION
Feldname Datentyp Beschreibung Beispiel
OP ID CHAR(7) Kunstlich erzeugterPrimarschlussel
1400201
STATION ID CHAR(3) Stationsnummer 140SPINDLE NUMBER(2) Spindelnummer 2STEP NUMBER(2) Schrittnummer 1LOWER FORCE TEST NUMBER(4,2) Untere Prufkraft 0.1UPPER FORCE TEST NUMBER(4,2) Obere Prufkraft 4.5
Tabelle 6.11: Die Tabelle PRESSING OPERATION
den die in Tabelle 6.3 aufgefuhrten Toleranzbereiche fur die Einpresskraft gespeichert. Sie wer-
den zur Datenbereinigung neu eintreffender Presskraftdaten verwendet wird (vgl. Abschnitte 6.1.2
und 6.3.2).
Die Tabelle LIMIT SCREWING
Die Tabelle LIMIT SCREWING (vgl. Tabelle 6.12) speichert alle in der gesamten Montageli-
nie vorkommenden Grenzwerteinstellungen fur Schrauboperationen. Dabei handelt es sich um die
Grenzwerteinstellungen, die an den Montage-Stationen eingestellt werden und mit den Messwer-
ten zusammen ubertragen werden. Die Spalten LOWER LIMIT TORQUE und LOWER LIMIT -
ANGLE reprasentieren die unteren Grenzwerte fur Drehmoment und Drehwinkel und die Spalten
UPPER LIMIT TORQUE und UPPER LIMIT ANGLE die oberen Grenzwerte fur Drehmoment
und Drehwinkel. Die Spalte LIMIT ID stellt einen kunstlich generierten Primarschlussel dar.
Diese Tabelle ist durch eine Normalisierung der Tabelle SCREWING entstanden, der ursprunglich
die Spalten fur die Grenzwerteinstellungen angehorten. Die Normalisierung wurde durchgefuhrt,
um eine große Redundanz in der Tabelle SCREWING zu vermeiden. Grenzwerteinstellungen an
den Montage-Stationen konnen uber Wochen hinweg unverandert bleiben, so dass bei einer nicht-
normalisierten Tabelle SCREWING einige tausend Datensatze exakt die selbe Wertebelegung fur
die Grenzwerteinstellungen besitzen wurden.
KAPITEL 6. DATENKONSOLIDIERUNG 63
Feldname Datentyp Beschreibung Beispiel
LIMIT ID NUMBER Kunstlich generierterPrimarschlussel
12
LOWER LIMIT ANGLE NUMBER(6,2) Unterer Grenzwert fur Dreh-winkel
40.0
UPPER LIMIT ANGLE NUMBER(6,2) Oberer Grenzwert fur Dreh-winkel
150.0
LOWER LIMIT TORQUE NUMBER(6,2) Unterer Grenzwert fur Dreh-moment
8.23
UPPER LIMIT TORQUE NUMBER(6,2) Oberer Grenzwert fur Dreh-moment
12.23
Tabelle 6.12: Die Tabelle LIMIT SCREWING
Feldname Datentyp Beschreibung Beispiel
OP ID CHAR(5) Schlussel fur Operation 14002OPEL ID CHAR(13) Getriebe-Seriennummer R--04123450MHLIMIT ID NUMBER Schlussel fur Grenzwertein-
stellungANGLE NUMBER(6,2) Gemessener Drehwinkel 80TORQUE NUMBER(6,2) Gemessenes Drehmoment 10TSTAMP DATE Zeitpunkt der Operation 12.12.1995
12:34:34
Tabelle 6.13: Die Tabelle SCREWING
Die Tabelle SCREWING
Die Tabelle SCREWING (vgl. Tabelle 6.13) dient zur Speicherung der bei Durchfuhrung ei-
ner Schrauboperation erfassten Messwerte fur den Drehwinkel und das Drehmoment. Die erfas-
sten Messwerte werden in den Spalten ANGLE und TORQUE gespeichert. Die Spalte TSTAMP
speichert den Zeitpunkt der Durchfuhrung der Operation. Die Spalten OPEL ID, LIMIT ID und
OP ID stellen Fremdschlussel dar und referenzieren auf die gleichnamigen Spalten der Tabellen
TRANSMISSION, LIMIT SCREWING und SCREWING OPERATION. Sie ordnen den Messwer-
ten das bearbeitete Getriebe, die bei Durchfuhrung der Operation eingestellten Grenzwerte sowie
die jeweilige Schrauboperation in der Tabelle SCREWING OPERATION zu.
Die Tabelle LIMIT PRESSING
Die Tabelle LIMIT PRESSING (vgl. Tabelle 6.14) ist analog zur Tabelle LIMIT SCREWING
aufgebaut und speichert alle in der gesamten Montagelinie vorkommenden Grenzwerteinstellun-
gen fur Pressoperationen.
KAPITEL 6. DATENKONSOLIDIERUNG 64
Feldname Datentyp Beschreibung Beispiel
LIMIT ID NUMBER Kunstlich generierterPrimarschlussel
12
LOWER LIMIT DISTANCE NUMBER(6,2) Unterer Grenzwert furEinpresstiefe
220.0
UPPER LIMIT DISTANCE NUMBER(6,2) Oberer Grenzwert furEinpresstiefe
270.0
LOWER LIMIT FORCE NUMBER(4,2) Unterer Grenzwert furEinpresskraft
10.0
UPPER LIMIT FORCE NUMBER(4,2) Oberer Grenzwert furEinpresskraft
14.0
Tabelle 6.14: Die Tabelle LIMIT PRESSING
Feldname Datentyp Beschreibung Beispiel
OP ID CHAR(7) Schlussel fur Operation 1400201OPEL ID CHAR(13) Getriebe-Seriennummer R--04123450MHLIMIT ID NUMBER Schlussel fur Grenzwertein-
stellungDISTANCE NUMBER(6,2) Gemessene Einpresstiefe 237.27FORCE NUMBER(4,2) Gemessene Einpresskraft 12.23TSTAMP DATE Zeitpunkt der Operation 12.12.1995
12:34:34
Tabelle 6.15: Die Tabelle PRESSING
Die Tabelle PRESSING
Die Tabelle PRESSING (vgl. Tabelle 6.15) ist analog zur Tabelle SCREWING aufgebaut und
dient zur Speicherung der bei Durchfuhrung einer Pressoperation erfassten Messwerte fur die
Einpresstiefe und die Einpresskraft.
Die Tabelle SHIM
Die Tabelle SHIM (vgl. Tabelle 6.16) speichert die fur ein Getriebe ermittelten Shim-Klassen. Die
Spalte OPEL ID dient als Fremdschlussel und referenziert auf die gleichnamige Spalte der Tabelle
TRANSMISSION. Die Spalten SHIM CLASS und SHAFT dienen zur Speicherung der Shim-
Klasse sowie eines Kurzels fur die Getriebekomponente, fur die das Shim verwendet werden soll.
Die Spalte TSTAMP speichert den Zeitpunkt der Erfassung des Datensatzes an der Station ST150.
Die Spalten OPEL ID und SHIM CLASS bilden einen zusammengesetzten Primarschlussel der
Tabelle SHIM.
KAPITEL 6. DATENKONSOLIDIERUNG 65
Feldname Datentyp Beschreibung Beispiel
OPEL ID CHAR(13) Getriebe-Seriennummer R--04123456MHSHIM CLASS NUMBER(2,0) Shim-Klasse 12SHAFT CHAR(3) Kurzel fur Komponente HWOTSTAMP DATE Zeitpunkt der Erfassung 12.01.2004
12.12.12
Tabelle 6.16: Die Tabelle SHIM
Die Tabelle ERROR MEASUREMENT
In dieser Tabelle (vgl. Tabelle 6.17) werden alle Schraub- und Presskraftdaten gespeichert, die
aufgrund fehlerhafter Werte nicht in die Zieltabellen ubernommen werden konnten. Alle Spal-
tenwerte werden als Text gespeichert, um auch Datensatze erfassen zu konnen, die Formatfehler
in numerischen Spalten aufweisen. Die Spalte MSG dient zur Speicherung eines Hinweistextes,
weshalb der Datensatz nicht in die Zieltabellen ubernommen wurde. Die Spalte DATE INSERT
speichert das Einfugedatum des Datensatzes.
Die Spalten LOWER LIMIT DIM1, UPPER LIMIT DIM1 und MEASUREMENT VALUE DIM1
speichern den unteren und den oberen Grenzwert sowie den Messwert fur den Weg (Einpres-
stiefe/Drehwinkel). Die Spalten LOWER LIMIT DIM2, UPPER LIMIT DIM2 und MEASURE-
MENT VALUE DIM2 speichern den unteren und den oberen Grenzwert sowie den Messwert fur
die aufgewendete Kraft (Einpresskraft/Drehmoment). In der Spalte TYPE wird erfasst, ob es sich
bei dem Datensatz um einen Presskraftdatensatz oder um einen Schraubkraftdatensatz handelt.
Die Tabelle ERROR SHIM
In dieser Tabelle (vgl. Tabelle 6.18) werden alle Shim-Daten gespeichert, die aufgrund fehlerhafter
Werte nicht in die Zieltabellen ubernommen werden konnten. Auch in dieser Tabelle werden alle
Werte als Text gespeichert, außerdem verfugt diese Tabelle ebenfalls uber die Spalten MSG und
DATE INSERT zum Erfassen eines Hinweistextes und des Einfugedatums.
Die Tabelle ERROR COMBINATION
In dieser Tabelle (vgl. Tabelle 6.19) werden alle Kombinationsdaten gespeichert, die aufgrund
fehlerhafter Daten nicht in die Zieltabellen ubernommen werden konnten.
Die Tabelle SYSTEM PARAM
Diese Tabelle (vgl. Tabelle 6.20) stellt eine Hilfstabelle dar, in der Parameter abgelegt werden, die
uber verschiedene Instanzen der Datenbereinigungsprozesse hinweg gesichert werden mussen. In
KAPITEL 6. DATENKONSOLIDIERUNG 66
Feldname Datentyp Beschreibung
PART NUMBER VARCHAR2(20) SeriennummerATTRIBUTE VARCHAR2(20) FehlercodeSTATION VARCHAR2(20) StationsnummerSPINDLE VARCHAR2(20) SpindelnummerSTEP VARCHAR2(20) SchrittnummerMEASURING VALUE DIM1 VARCHAR2(20) Messwert fur Einpresstie-
fe/DrehwinkelMEASURING VALUE DIM2 VARCHAR2(20) Messwert fur Einpres-
skraft/DrehmomentLOWER LIMIT DIM1 VARCHAR2(20) Unterer Grenzwert fur Einpresstie-
fe/DrehwinkelUPPER LIMIT DIM1 VARCHAR2(20) Oberer Grenzwert fur Einpresstie-
fe/DrehwinkelLOWER LIMIT DIM2 VARCHAR2(20) Unterer Grenzwert fur Einpres-
skraft/DrehmomentUPPER LIMIT DIM2 VARCHAR2(20) Oberer Grenzwert fur Einpres-
skraft/DrehmomentTSTAMP VARCHAR2(20) Zeitpunkt der OperationTYPE CHAR(1) Art des Datensatzes (0=Schraubkraft-
datensatz/1=Presskraftdatensatz)MSG VARCHAR2(255) HinweistextDATE INSERT DATE Einfugedatum
Tabelle 6.17: Die Tabelle ERROR MEASUREMENT
der Spalte ATTRIBUTE wird der Parametername und in der Spalte VALUE der zugehorige Wert
erfasst.
6.3 Definition der Datenbereinigungsprozesse
Die Datenbereinigungsprozesse dienen dazu, die von den Montage-Stationen empfangenen Daten
einzulesen und zu transformieren, um sie damit hinsichtlich ihrer Struktur und Reprasentation an
das gemeinsame Zielschema anzupassen. Dabei sollen Daten, die offensichtlich fehlerhaft sind
bzw. die in Abschnitt 5.1 genannten Qualitatskriterien nicht erfullen, aussortiert werden.
Bei der Uberprufung der Quelldaten auf die Erfullung der einzelnen Qualitatskriterien ist es sinn-
voll, die Daten anfangs unter syntaktischen Gesichtspunkten zu uberprufen. Dazu konnen die
wahrend der Datenanalyse ermittelten Informationen uber die jeweiligen Datentypen sowie die ty-
pischen Muster der Werte verwendet werden. Wahrend dessen erfolgt auch ein Vollstandigkeitstest,
um zu prufen, ob zu allen Feldern entsprechende Werte vorhanden sind. Der Test auf Vollstan-
digkeit ist einfach durchzufuhren, da bis auf die Kunden-Seriennummer alle Felder Pflichtfel-
KAPITEL 6. DATENKONSOLIDIERUNG 67
Feldname Datentyp Beschreibung
OPEL ID VARCHAR2(20) Getriebe-SeriennummerSHIM CLASS VARCHAR2(20) Shim-KlasseSHAFT VARCHAR2(20) KomponenteTSTAMP VARCHAR2(20) Zeitpunkt der ErfassungMSG VARCHAR2(255) FehlermeldungDATE INSERT DATE Einfugedatum
Tabelle 6.18: Die Tabelle ERROR SHIM
Feldname Datentyp Beschreibung
OPEL ID VARCHAR2(20) Getriebe-SeriennummerFIAT ID VARCHAR2(20) Kunden-Seriennummer (FIAT)SAAB ID VARCHAR2(20) Kunden-Seriennummer (SAAB)DATE ST140 VARCHAR2(20) Zeitpunkt der Erfassung an der Station ST140VID ST040 VARCHAR2(20) Virtuelle Kennung ST040VID ST110 VARCHAR2(20) Virtuelle Kennung ST110VID ST120 VARCHAR2(20) Virtuelle Kennung ST120MSG VARCHAR2(255) HinweistextDATE INSERT DATE Einfugedatum
Tabelle 6.19: Die Tabelle ERROR COMBINATION
der sind. Das Fehlen einer Kunden-Seriennummer wird als nicht kritisch beurteilt und toleriert.
Aufgrund dessen tritt in diesem Fall die Problematik, die aus den unterschiedlichen Interpreta-
tionsmoglichkeiten eines nicht vorhandenen Wertes resultieren kann (vgl. Abschnitt 5.1), nicht
auf. Anhand der beiden genannten Uberprufungen konnen alle Datensatze, die die Kriterien der
Vollstandigkeit und der Schema-Konformitat verletzen, erkannt werden. Die Erfullung der beiden
Kriterien ist Voraussetzung fur die Uberprufung der semantischen Korrektheit.
Nach erfolgter Uberprufung der syntaktischen Korrektheit sollten die Quelldaten auf semantische
Korrektheit hin uberpruft werden. Die Uberprufung der Werte erfolgt mithilfe des Wissens uber
die Wertebereiche und die Integritatsbedingungen, welches wahrend der Datenanalyse erworben
wurde.
Die Eindeutigkeit der Qualitatsdaten ist einfach sicherzustellen, da alle Datensatze uber eine be-
stimmte Feldkombination eindeutig identifizierbar sind (z. B. bei Schraubkraftdatensatze anhand
der Seriennummer des bearbeiteten Teils und der Angaben fur die Station und die Spindel). Eine
aufwandige Duplikateliminierung, wie sie beispielsweise bei Adressdaten erforderlich ist, entfallt
in diesem Anwendungsfall. Duplikate infolge einer mehrfachen Datenubertragung konnen pro-
blemlos vermieden werden. Bei Duplikaten, die durch eine wiederholte Durchfuhrung einer Ope-
KAPITEL 6. DATENKONSOLIDIERUNG 68
Feldname Datentyp Beschreibung Beispiel
ATTRIBUTE VARCHAR2(50) Parametername LAST COMBINATION DATEVALUE VARCHAR2(50) Wert 12.12.1995 12:34:34
Tabelle 6.20: Die Tabelle SYSTEM PARAM
ration verursacht werden, soll grundsatzlich der Datensatz mit dem großeren Zeitstempel gespei-
chert werden. Eine Plausibilitatsuberprufung der Zeitstempel soll nicht erfolgen, da die Zeitsyn-
chronisierung der Montage-Stationen nicht einwandfrei funktioniert. ImUbrigen wird der Kor-
rektheit der Zeitstempel keine hohe Prioritat beigemessen, da keine Datenanalysen geplant sind,
die die Plausibilitat der Zeitstempel voraussetzen wurden.
Wie bereits in Abschnitt 5.1 beschrieben, kann unter dem Kriterium der Vollstandigkeit auch die
Eigenschaft verstanden werden, dass alle Entitaten der Realitat im Datenbestand reprasentiert sind.
Obwohl der Vollstandigkeitstest, ob fur ein Getriebe zu allen Operationen ein entsprechender Da-
tensatz vorhanden ist, aufgrund des bekannten Aufbaus der Montagelinie und der damit bekannten
Anzahl der zu erwartenden Datensatze einfach zu realisieren ware, wird auf ihn verzichtet, da die-
ses Kriterium laut Anforderungen nicht erfullt werden muss.
Das Kriterium Einheitlichkeit ist durch die standardisierte Reprasentation der Schraub- und Pres-
skraftdaten weitgehend gegeben. Es mussen lediglich Transformationen der Quelldaten bezuglich
ihrer Struktur durchgefuhrt werden, um sie in die normalisierte Zieldatenbank schreiben zu konnen.
Die Bereinigung der Datensatze beschrankt sich damit auf die Uberprufung der Eindeutigkeit,
der Vollstandigkeit und der Gultigkeit der Werte mithilfe der in Abschnitt 6.1 ermittelten Inte-
gritatsbedingungen. Alle durchzufuhrenden Uberprufungen konnen mithilfe entsprechender Inte-
gritats-Constraints in den Zieltabellen durchgefuhrt werden.
Bei der Definition der Datenbereinigungsprozesse wurde von dem in Abschnitt 5.5.3 beschrie-
benen Schema eines ETL-Prozesses abgewichen. Es existieren demnach keine strikt getrenn-
ten Phasen fur Extraktion, Transformation und Laden der Daten, da die temporare Speicherung
samtlicher Daten in einem Transformationsbereich in diesem Anwendungsfall nicht unbedingt als
notwendig erscheint und daher unnotigen Overhead verursachen wurde. Eine Speicherung von Da-
tensatzen im Transformationsbereich ist erforderlich, wenn komplexere Abhangigkeiten zwischen
Datensatzen existieren, so dass die Bereinigung eines Datensatzes das Vorhandensein anderer Da-
tensatze voraussetzt. Dies ist beispielsweise der Fall, wenn mehrere Datensatze zur Erkennung von
logischen Widerspruchen einander abgeglichen werden mussen. Da die Zeitstempelbeziehungen
außer Acht gelassen werden sollen, bestehen keine Abhangigkeiten, die es vor dem Ladevorgang
KAPITEL 6. DATENKONSOLIDIERUNG 69
Feldname Datentyp Beschreibung
OPEL ID VARCHAR2(25) Getriebe-SeriennummerFIAT ID VARCHAR2(25) Kunden-Seriennummer (FIAT)SAAB ID VARCHAR2(25) Kunden-Seriennummer (SAAB)DATE ST140 DATE Zeitpunkt der Erfassung an der Station ST140VID ST040 VARCHAR2(15) Virtuelle Kennung: Stirnrad/Differential
(ST040)VID ST110 VARCHAR2(15) Virtuelle Kennung: Getriebegehause (ST110)VID ST120 VARCHAR2(15) Virtuelle Kennung: Kupplungsgehause
(ST120)
Tabelle 6.21: Die Tabelle IMPORT COMBINATION
zu uberprufen gilt. Ein Teil der Quelldaten kann demnach im Arbeitsspeicher transformiert wer-
den und direkt in die Zieltabellen geladen werden. Das temporare Speichern der Quelldaten in
Hilfstabellen wird daher auf die Schraub- und Presskraftdaten aus der Vormontage beschrankt.
Bei diesen Quelldaten ist das temporare Speichern unvermeidlich, da sie vor dem Ladevorgang in
die Zieltabellen aufgrund der nicht existenten Getriebe-Seriennummer mit den Kombinationsda-
ten kombiniert werden mussen. Daruber hinaus sollen an den Quelldaten keine Korrekturen von
falschen Werten vorgenommen werden, so dass bereits wahrend des Einlesevorgangs der Quellda-
teien als fehlerhaft identifizierte Datensatze gar nicht erst in den Transformationsbereich geladen
werden mussen, sondern direkt in einen Fehler-Report geschrieben werden konnen.
Zur Bereinigung der eintreffenden Quelldaten sind insgesamt funf verschiedene Prozesse definiert:
1. Einlesen und Bereinigen der Kombinationsdaten
2. Einlesen und Bereinigen der Schraub- und Presskraftdaten
3. Einlesen und Bereinigen der Shim-Daten
4. Einlesen und Bereinigen der Ausschleusungsdaten
5. Bereinigen der Import- und Fehlertabellen
Der funfte Prozess dient nicht der eigentlichen Datenbereinigung, sondern lediglich zum Loschen
nicht mehr benotigter Datensatze in den Import- und Fehlertabellen. In den folgenden Abschnitten
werden die genannten Prozesse in ihrem Ablauf beschrieben.
6.3.1 Einlesen und Bereinigen der Kombinationsdaten
Dieser Prozess dient der Speicherung der Kombinationsdaten in einer Form, wie sie im nach-
folgenden Prozess zur Zuordnung der Schraub- und Presskraftdaten aus der Vormontage zu den
KAPITEL 6. DATENKONSOLIDIERUNG 70
einzelnen Getrieben verwendet werden konnen. Der Aufbau der Kombinationsdatei ist in Tabel-
le 2.1 und ein exemplarischer Auszug aus dieser in Abbildung 4.4 dargestellt.
Der Inhalt der Kombinationsdatei wird unverandert in die Tabelle IMPORT COMBINATION (vgl.
Tabelle 6.21) geladen. Lediglich die Spalten V ID2, V ID3 und V ID4 werden entfernt, da die
Erfassung der mit diesen virtuellen Kennungen verbundenen Messwerte nicht im Anforderungs-
bereich liegen und die Spalten TIMESTAMP, V ID1, V ID5 und V ID6 werden auf die Spalten
DATE ST140, VID ST040, VID ST110 und VID ST120 der Tabelle IMPORT COMBINATION
abgebildet. Daruber hinaus erfolgt bereits beim Parsen der Datei eine syntaktische Uberprufung
der Werte in der Spalte TIMESTAMP, weil die syntaktische Korrektheit fur die weitere Verar-
beitung der Daten erforderlich ist. Da die Quelldatei nicht nur die Kombinationsdaten der vor-
angegangenen Schicht, sondern alle jemals erfassten Kombinationsdaten beinhaltet (Full-Dump),
wird vor Beendigung dieses Prozesses der Zeitstempel des jungsten Eintrages der Tabelle IM-
PORT COMBINATION in die Tabelle SYSTEM PARAM (vgl. Tabelle 6.20) geschrieben. Damit
wird ein Zeiger auf den zuletzt integrierten Datensatz uber die aktuelle Prozessinstanz hinweg
bis zu einer erneuten Prozessausfuhrung festgehalten. Bei einem erneuten Start dieses Prozesses
werden dann nur die Dateieintrage in die Tabelle IMPORT COMBINATION geschrieben, deren
Zeitstempel großer sind als der Zeitstempel des in der vorangegangen Prozessinstanz zuletzt inte-
grierten Datensatzes. Auf diese Weise wird vermieden, dass bei jeder Ausfuhrung dieses Prozesses
der gesamte Inhalt der Quelldatei importiert werden muss. Nach dem Einlesen der Quelldatei be-
steht der gesamte Datenbestand der Kombinationsdaten in der Tabelle IMPORT COMBINATION
zur Verfugung, ohne dass nochmals auf die Quelldatei zugegriffen werden muss, sofern ein Zugriff
auf altere Daten notwendig werden sollte.
Im weiteren Verlauf werden alle Datensatze aus der Tabelle IMPORT COMBINATION, die seit
der letzten Prozessausfuhrung hinzugekommen sind und demnach bis dahin nicht integriert wur-
den, selektiert und wie folgt transformiert:
(OPEL ID, FIAT ID, (OPEL ID, CUSTOMER ID, DATE ST140),
SAAB ID, DATE ST140, � (OPEL ID, VID ST040, ’ST040’, DATE ST140),
VID ST040, VID ST110, (OPEL ID, VID ST110, ’ST110’, DATE ST140),
VID ST120) (OPEL ID, VID ST120, ’ST120’, DATE ST140)
Die Felder SAAB ID und FIAT ID verschmelzen dabei zu einem Feld CUSTOMER ID, da jedes
Getriebe maximal nur eine Kunden-Seriennummer besitzen kann.
Tritt ein Datensatz mit fehlender Getriebe-Seriennummer und vorhandener Kunden-Seriennummer
auf, so wird in der Tabelle IMPORT COMBINATION nach einem Eintrag gesucht, der die glei-
che Kunden-Seriennummer und einen kleineren Zeitstempel tragt. Besitzt der gefundene Ein-
KAPITEL 6. DATENKONSOLIDIERUNG 71
trag eine gultige Getriebe-Seriennummer, so wird diese fur die weitere Verarbeitung herange-
zogen. Datensatze mit nicht vorhandener Getriebe-Seriennummer und nicht vorhandener Kunden-
Seriennummer werden verworfen und in die Tabelle ERROR COMBINATION geschrieben. Hin-
tergrund dieser Vorgehensweise ist, dass bei einer fehlenden Getriebe-Seriennummer moglich-
erwiese eine erneute Einschleusung des Getriebes stattgefunden hat und bei der erneuten Er-
fassung der Kombinationsdaten der Wert fur die Getriebe-Seriennummer verloren gegangen ist.
Verfugt der Datensatz uber eine Kunden-Seriennummer, kann uber diese der Datensatz der vor-
angegangenen Einschleusung gefunden und anhand dieses Datensatzes die zugehorige Getriebe-
Seriennummer ermittelt werden.
Der Datensatz (OPEL ID, CUSTOMER ID, DATE ST140) wird in die Tabelle TRANSMISSI-
ON geschrieben, wobei die ersten beiden Attribute des Datensatzes auf die gleichnamigen Spal-
ten der Tabelle abgebildet werden. Das Attribut DATE ST140 wird dagegen auf die Spalte DA-
TE EXIT der Tabelle abgebildet, um die genannte Spalte mit dem Erfassungsdatum der Station
ST140 vorzubelegen. Auf diese Weise steht der ungefahre Montagezeitpunkt zur Verfugung, falls
in der Montagelinie aus irgendwelchen Grunden kein Ausschleusungszeitpunkt erfasst werden
sollte (vgl. auch Abschnitt 6.3.2). Existiert bereits ein entsprechender Datensatz in der Tabelle
TRANSMISSION, so wird die Spalte CUSTOMER ID des vorhandenen Datensatzes aktualisiert.
Ist der in der Spalte DATE EXIT gespeicherte Zeitstempel des vorhandenen Datensatzes kleiner
als der des einzufugenden Datensatzes, wird auch die Spalte DATE EXIT entsprechend aktuali-
siert. Die Vollstandigkeit wird sichergestellt, indem alle Spalten der Tabelle TRANSMISSION mit
Ausnahme der Spalte CUSTOMER ID als NOT NULL deklariert sind. Eine Plausibilitatskontrolle
der Getriebe-Seriennummer erfolgt mithilfe einer CHECK-Klausel.
Die Datensatze (OPEL ID, VID ST040, ’ST040’, DATE ST140), (OPEL ID, VID ST110, ’ST110’,
DATE ST140) und (OPEL ID, VID ST120, ’ST120’, DATE ST140) werden in die Tabelle COM-
BINATION geschrieben. Die Attribute OPEL ID und DATE ST140 werden dabei auf die gleich-
namigen Spalten der Tabelle abgebildet. Die Attribute VID ST040, VID ST010 und VID ST120
werden dagegen in die Spalte VIRTUAL ID und die Zeichenketten ’ST040’, ’ST110’ und ’ST120’
in die Spalte STATION ID geschrieben. Alle Spalten der Tabelle COMBINATION sind als NOT
NULL deklariert. Die Eindeutigkeit in der Tabelle COMBINATION wird durch den Primarschlussel,
der sich aus den Spalten OPEL ID und STATION ID zusammensetzt, sichergestellt. Ein bereits
vorhandener Datensatz mit gleichem Schlusselwert wie der neu zu speichernde Datensatz, wird
uberschrieben, sofern der neu zu speichernde Datensatz den großeren Zeitstempel der beiden Da-
tensatze besitzt. Wird ein Fehler in einem der durch die Transformation entstandenen Datensatze
gefunden, wird der ursprungliche Datensatz, aus dem der betroffene Datensatz bei der Transfor-
mation hervorgegangen ist, in die Tabelle ERROR COMBINATION geschrieben.
KAPITEL 6. DATENKONSOLIDIERUNG 72
Feldname Datentyp Beschreibung
OPEL ID CHAR(13) Getriebe-SeriennummerVIRTUAL ID CHAR(8) Virtuelle KennungSTATION ID CHAR(3) StationsnummerDATE ST140 DATE Zeitpunkt der Erfassung an der Station ST140DATE INSERT DATE Einfugedatum
Tabelle 6.22: Die Tabelle COMBINATION
Nach Beendigung dieses Prozesses stehen alle Kombinationsdaten der vorangegangenen Schicht
in der Tabelle COMBINATION zur Verfugung, um spater die Schraub- und Presskraftdaten aus
der Vormontage den jeweiligen Getrieben zuordnen zu konnen. Dabei ist sichergestellt, dass die
Daten syntaktisch korrekt und vollstandig sind. Außerdem beinhalten die Daten zu jedem Getrie-
be, welches mehrmalig durch die Station ST140 geschleust wurde, die jeweils zuletzt erfassten
Kombinationen.
6.3.2 Einlesen und Bereinigen der Schraub- und Presskraftdaten
Da die Schraub- und Presskraftdaten aufgrund ihrer gleichartigen Struktur auf gleiche Weise ver-
arbeitet werden konnen und sich lediglich die Zieltabellen der beiden Datenarten unterscheiden,
werden die Schraub- und Presskraftdaten von demselben Prozess verarbeitet. Das Dateiformat
der Schraub- und Presskraftdateien ist in Abschnitt 4.3.1 beschrieben. Der gesamte Prozess zur
Verarbeitung der Schraub- und Presskraftdaten gliedert sich in zwei Phasen:
1. Phase Aus den Inhalten des Beschreibungsteils sowie den einzelnen Werteeintragen im Werte-
teil einer DFQ-Datei werden die Datensatze (PART NUMBER, ATTRIBUTE, STATION, SPIND-
LE, STEP, MEASURING VALUE DIM1, MEASURING VALUE DIM2, LOWER LIMIT DIM1,
UPPER LIMIT DIM1, LOWER LIMIT DIM2, UPPER LIMIT DIM2, TSTAMP, TYPE) erzeugt.
Das Attribut TYPE dient zur Unterscheidung zwischen Schraub- und Presskraftdaten und anhand
dessen Wert werden die Zieltabellen fur den zu speichernden Datensatz gewahlt. Ein Datensatz,
der im Attribut ATTRIBUTE einen Wert ungleich”0“ aufweist, wird direkt in die Tabelle ER-
ROR MEASUREMENT geschrieben, da ein solcher Datensatz von einer fehlgeschlagenen Ope-
ration stammt und laut Anforderungen nicht gespeichert werden soll. Weist der Wert des Attributs
ATTRIBUTE den Wert”0“ auf, so werden die einzelnen Attributwerte des Datensatzes in die
fur das Zielsystem erforderlichen Datentypen konvertiert. Im weiteren Verlauf wird zwischen Da-
tensatzen unterschieden, die aufgrund ihrer Herkunft (Vormontage oder Endmontage) uber eine
virtuelle Kennung oder eine Getriebe-Seriennummer verfugen.
Ein Datensatz, der aus der Vormontage stammt und daher im Attribut PART NUMBER uber ei-
KAPITEL 6. DATENKONSOLIDIERUNG 73
Feldname Datentyp Beschreibung
PART NUMBER VARCHAR2(8) SeriennummerATTRIBUTE NUMBER(3) FehlercodeSTATION CHAR(3) StationsnummerSPINDLE NUMBER(2) SpindelnummerSTEP NUMBER(1) SchrittnummerMEASURING VALUE DIM1 NUMBER(6,2) Messwert fur Einpresstie-
fe/DrehwinkelMEASURING VALUE DIM2 NUMBER(5,2) Messwert fur Einpres-
skraft/DrehmomentLOWER LIMIT DIM1 NUMBER(6,2) Unterer Grenzwert fur Einpresstie-
fe/DrehwinkelUPPER LIMIT DIM1 NUMBER(6,2) Oberer Grenzwert fur Einpresstie-
fe/DrehwinkelLOWER LIMIT DIM2 NUMBER(5,2) Unterer Grenzwert fur Einpres-
skraft/DrehmomentUPPER LIMIT DIM2 NUMBER(5,2) Oberer Grenzwert fur Einpres-
skraft/DrehmomentTSTAMP VARCHAR2(20) Zeitpunkt der OperationTYPE CHAR(1) Art des Datensatzes (0=Schraubkraft-
datensatz/1=Presskraftdatensatz)DATE INSERT DATE Einfugedatum
Tabelle 6.23: Die Tabelle IMPORT MEASUREMENT
ne virtuelle Kennung verfugt, wird unverandert in die Tabelle IMPORT MEASUREMENT (vgl.
Tabelle 6.23) geschrieben. Der Primarschlussel dieser Tabelle setzt sich zusammen aus den Spal-
ten PART NUMBER, STATION, SPINDLE, STEP und TYPE. Ein bereits vorhandener Datensatz
mit gleichem Schlusselwert wie der neu zu speichernde Datensatz, wird uberschrieben, sofern
der neu zu speichernde Datensatz den großeren Zeitstempel der beiden Datensatze besitzt. Eine
Uberprufung auf Einhaltung der definierten Wertebereiche sowie weiterer Integritatsbedingungen
erfolgt an dieser Stelle nicht.
Ein Datensatz, die aus der Endmontage stammt und daher im Attribut PART NUMBER bereits
uber eine Getriebe-Seriennummer verfugt, wird direkt in die Zieltabellen geschrieben. Dazu wird
ein zu speichernder Datensatz zunachst wie folgt transformiert:
KAPITEL 6. DATENKONSOLIDIERUNG 74
(PART NUMBER, ATTRIBUTE, (MEASURING VALUE DIM1,
STATION, SPINDLE, STEP, MEASURING VALUE DIM2,
MEASURING VALUE DIM1, PART NUMBER, TSTAMP),
MEASURING VALUE DIM2,
LOWER LIMIT DIM1, � (LOWER LIMIT DIM1,
UPPER LIMIT DIM1, UPPER LIMIT DIM1,
LOWER LIMIT DIM2, LOWER LIMIT DIM2,
UPPER LIMIT DIM2, UPPER LIMIT DIM2)
TSTAMP, TYPE)
Je nach Datenart wird der Datensatz (LOWER LIMIT DIM1, UPPER LIMIT DIM1, LOWER -
LIMIT DIM2, UPPER LIMIT DIM2) in die Tabelle LIMIT PRESSING oder LIMIT SCREWING
geschrieben, sofern ein entsprechender Datensatz in der jeweiligen Zieltabelle noch nicht existiert.
Die Attribute LOWER LIMIT DIM1 und UPPER LIMIT DIM1 werden dabei je nach Zieltabelle
auf die Spalten LOWER LIMIT ANGLE und UPPER LIMIT ANGLE oder LOWER LIMIT -
DISTANCE und UPPER LIMIT DISTANCE abgebildet. Die Attribute LOWER LIMIT DIM2
und UPPER LIMIT DIM2 werden dagegen auf die Spalten LOWER LIMIT TORQUE und UP-
PER LIMIT TORQUE oder LOWER LIMIT FORCE und UPPER LIMIT FORCE abgebildet.
Alle Spalten der beiden Zieltabellen sind als NOT NULL deklariert.
Der Datensatz (MEASURING VALUE DIM1, MEASURING VALUE DIM2, PART NUMBER,
TSTAMP) wird zusammen mit den Attributen OP ID und LIMIT ID je nach Datenart in die Ta-
belle SCREWING oder PRESSING geschrieben. Der Wert fur das Attribut OP ID wird aus der
Wertekombination der Attribute STATION ID, SPINDLE und ggf. STEP des ursprunglichen Da-
tensatzes ermittelt. Der Wert fur das Attribut LIMIT ID entspricht dem Schlusselwert der entspre-
chenden Grenzwerteinstellung in der Tabelle LIMIT PRESSING bzw. LIMIT SCREWING. Die
Attribute OP ID, TSTAMP und LIMIT ID werden beim Einfugen auf die gleichnamigen Spal-
ten der Zieltabelle abgebildet und das Attribut PART NUMBER wird in die Spalte OPEL ID
der Zieltabelle geschrieben. Die Attribute MEASUREMENT VALUE DIM1 und MEASURE-
MENT VALUE DIM2 werden je nach Zieltabelle auf die Spalten DISTANCE und FORCE oder
ANGLE und TORQUE abgebildet. Alle Spalten der beiden Zieltabellen SCREWING und PRES-
SING sind als NOT NULL deklariert. Die Eindeutigkeit in den beiden Tabellen wird jeweils durch
den Primarschlussel, der sich aus den Spalten OPEL ID und OP ID zusammensetzt, sichergestellt.
Ein bereits vorhandener Datensatz mit gleichem Schlusselwert wie der neu zu speichernde Daten-
satz, wird uberschrieben, sofern der neu zu speichernde Datensatz den großeren Zeitstempel der
beiden Datensatze besitzt.
Die Uberprufung der ermittelten Integritatsbedingungen bezuglich der Wertebereiche und der Ein-
haltung der Toleranzbereiche, die in den Tabellen SCREWING OPERATION und PRESSING
KAPITEL 6. DATENKONSOLIDIERUNG 75
OPERATION erfasst sind (vgl. Abschnitt 6.2), erfolgen mithilfe von CHECK-Klauseln und Trig-
gern. Bei Verletzung einer Integritatsbedingung wird der ursprungliche Datensatz in die Tabelle
ERROR MEASUREMENT geschrieben.
Sollte in der Tabelle TRANSMISSION kein Datensatz mit entsprechender Getriebe-Seriennummer
existieren, wird der Datensatz von diesem Prozess vor Einfugen des Press- bzw. Schraubkraft-
datensatzes angelegt. Diese Vorgehensweise ermoglicht es auch Datensatze zu speichern, deren
Getriebe-Seriennummer nicht in der Kombinationstabelle auftaucht. Diese Vorgehensweise ist
ausdrucklich erwunscht.
Da es ungewiss ist, ob die Station ST300 jemals Ausschleusungsdaten senden wird, wird nach
jedem Speichern eines Press- oder Schraubkraftdatensatzes der Wert des Attributs TSTAMP in die
Spalte DATE EXIT des entsprechenden Getriebe-Datensatzes in der Tabelle TRANSMISSION
eingetragen, sofern der neue Zeitstempel großer als der vorhandene ist. Nach Abarbeitung aller
Datensatze eines Getriebes beinhaltet die Spalte DATE EXIT schließlich einen Zeitpunkt, der dem
tatsachlichen Ausschleusungszeitpunkt zeitlich gesehen am nachsten liegt. Diese Vorgehensweise
bleibt auch dann bestehen, wenn die Station ST300 Daten sendet. Auf diese Weise konnen Ausfalle
bei der Datenerfassung an der Station ST300 kompensiert werden.
2. Phase Nachdem alle neu eingetroffenen DFQ-Dateien verarbeitet wurden, werden die Schraub-
und Presskraftdatensatze aus der Vormontage mit den Kombinationsdaten kombiniert, um die
einzelnen Datensatze den einzelnen Getrieben zuzuordnen. Dazu werden die Datensatze in der
Tabelle COMBINATION mit denen in der Tabelle IMPORT MEASUREMENT kombiniert. Ab-
bildung 6.2 zeigt den dabei verwendeten EQUI-Join. Die Datensatze aus der Vormontage, die nach
der Kombination uber eine Getriebe-Seriennummer verfugen, werden schließlich auf die gleiche
Weise in die Zieltabellen geladen wie die Daten aus der Endmontage in der ersten Phase.
6.3.3 Einlesen und Bereinigen der Shim-Daten
Das Dateiformat einer Shim-Datei ist in Abschnitt 4.5 beschrieben. Die Shim-Datei wird zei-
lenweise eingelesen, dabei wird jeder Datensatz nach erfolgter Datentypkonvertierung der Fel-
der SHIM CLASS und TSTAMP in die Tabelle SHIM geschrieben. Alle Spalten in der Tabel-
le SHIM sind als NOT NULL deklariert. Zur Definition der gultigen Wertebereiche der Spalten
SHIM CLASS und SHAFT sind entsprechende CHECK-Klauseln deklariert. Die Eindeutigkeit in
der Tabelle SHIM wird durch den Primarschlussel, der sich aus den Spalten OPEL ID und SHAFT
zusammensetzt, sichergestellt. Ein bereits vorhandener Datensatz mit gleichem Schlusselwert wie
der neu zu speichernde Datensatz, wird uberschrieben, sofern der neu zu speichernde Datensatz
den großeren Zeitstempel der beiden Datensatze besitzt. Sollte in der Tabelle TRANSMISSION
kein Datensatz mit entsprechender Getriebe-Seriennummer existieren, so wird der Datensatz von
KAPITEL 6. DATENKONSOLIDIERUNG 76
SELECTOPEL_ID, I.PART_NUMBER,ATTRIBUTE, SPINDLE,STATION, STEP,TYPE, TSTAMP,MEASURING_VALUE_DIM1, MEASURING_VALUE_DIM2,LOWER_LIMIT_DIM1, LOWER_LIMIT_DIM2,UPPER_LIMIT_DIM1, UPPER_LIMIT_DIM2
FROMCOMBINATION C, IMPORT_MEASUREMENT I
WHEREC.VIRTUAL_ID = I.PART_NUMBER
ANDSTATION_ID = STATION
Abbildung 6.2: EQUI-Join zur Zuordnung der Schraub- und Presskraftdaten aus der Vormontagezu den einzelnen Getrieben
diesem Prozess vor Einfugen des Shim-Datensatzes angelegt. Fehlerhafte Shim-Datensatze wer-
den in die Tabelle ERROR SHIM geschrieben.
6.3.4 Einlesen und Bereinigen der Ausschleusungsdaten
Das Eingabeformat einer Datei mit Ausschleusungsdaten ist in Abschnitt 4.6 beschrieben. Je-
des in der Quelldatei erfasste Ausschleusungsdatum wird nach erfolgter Datentypkonvertierung
in die Spalte DATE EXIT des entsprechenden Getriebe-Datensatzes in der Tabelle TRANSMIS-
SION eingetragen. Ein in der Spalte DATE EXIT bereits eingetragener Zeitstempel wird dabei
uberschrieben, sofern der neu einzutragende Zeitstempel großer als der bestehende ist. Sollte in
der Tabelle TRANSMISSION kein Datensatz mit entsprechender Getriebe-Seriennummer existie-
ren, so wird der Datensatz von diesem Prozess angelegt.
6.3.5 Bereinigen der Import- und Fehlertabellen
Um ein zu starkes Anwachsen der Datenmengen in den Fehler- sowie Importtabellen zu ver-
hindern, werden die einzelnen Tabellen regelmaßig bereinigt. Dazu werden Datensatze, deren
Einfugezeitpunkte langer als eine bestimmte Zeitspanne zuruckliegen und daher mit hoher Wahr-
scheinlichkeit nicht mehr benotigt werden, aus den Tabellen geloscht. Der Einfugezeitpunkt eines
Datensatzes wird der Spalte DATE INSERT entnommen. Fur jede Tabelle wird ein eigener Wert
fur die”Verfallszeitspanne“ definiert.
Kapitel 7
Implementierung
In diesem Kapitel wird auf die Implementierung der in Abschnitt 6.3 definierten Datenbereini-
gungsprozesse (Abschnitt 7.1) sowie des Frontends (Abschnitt 7.2) eingegangen.
7.1 Die Applikation QSF40
Die einzelnen Datenbereinigungsprozesse sind unter Verwendung der Programmiersprache Java
(J2SE 1.4.1) innerhalb einer Standalone-Applikation mit dem Namen”QSF40“ implementiert. Es
werden also keine externen Tools zum Einlesen der CSV-Dateien verwendet oder sonstige Pro-
gramme/Skripte auf Betriebsystemebene aufgerufen. Demnach existiert abgesehen von der Da-
tenbank keine Kopplung mit anderen Applikationen, so dass die Applikation plattformunabhangig
ist und einfach installiert werden kann. Der Aufbau der Applikation in ihren wesentlichen Kom-
ponenten ist in Abbildung 7.1 schematisch dargestellt. Die einzelnen Datenbereinigungsprozesse
sind dabei in grauer Farbe dargestellt. Die durchgezogenen Pfeile skizzieren die verschiedenen
Datenflusse und die gestrichelten Pfeile deuten Prozessaufrufe an.
Der Timer startet in konstanten Zeitabstanden den Thread”ConsolidationTask“. Dieser Thread
ruft schließlich nacheinander die einzelnen Datenbereinigungsprozesse auf, die fur das Einlesen
der Quelldateien und das Abspeichern der Quelldaten in der Datenbank verantwortlich sind. Zu-
griffe auf die Datenbank durch die Datenbereinigungsprozesse erfolgen ausschließlich uber eine
Datenbankabstraktionssschicht. Der Logger unterstutzt das Application-Logging und der Session-
Buffer ermoglicht allen anderen Komponenten einen Zugriff auf verschiedene Konfigurationsein-
stellungen der Applikation, die uber eine Konfigurationsdatei vorgenommen werden konnen. Die
ausfuhrbare Klasse der Applikation ist die Klasse qsf40.QSF40.
Der Timer
Bei dem Timer handelt es sich um eine Instanz der Klasse java.util.Timer, die in der Me-
thode main der Klasse qsf40.QSF40 und damit kurz nach dem Starten der Applikation erzeugt
77
KAPITEL 7. IMPLEMENTIERUNG 78
Datenbank
Applikation QSF40
Tim
er Consolidation-Task
ShimFileReader
CombinationTask
CleaningTask
CombinationDataLoadingTask
Se
ssio
n-
Bu
ffer
Log
ger
DFQFileReader
Combination-FileReader
ExitData-FileReader
Measurement-LoadingTask
ShimData-LoadingTask
ExitData-LoadingTask
Da
ten
ban
k-a
bstr
aktio
ns-
sch
ich
t
Abbildung 7.1: Aufbau der Applikation QSF40
wird. Der Thread”ConsolidationTask“, der von dem Timer gestartet wird, wird durch die von der
Klasse java.util.TimerTaskabgeleiteten Klasse qsf40.tasks.ConsolidationTask
implementiert. Zur Registrierung des”ConsolidationTask“ -Threads beim Timer wird die Methode
scheduleAtFixedRate()des Timer-Objektes verwendet. Diese Methode stellt sicher, dass
der Thread”ConsolidationTask“ und damit die Datenbereinigung in konstanten Zeitabstanden,
unabhangig davon wie lange die einzelnen Ausfuhrungen der Datenbereinigung dauern, gestartet
wird. Der Zeitabstand zwischen zwei Ausfuhrungen der Datenkonsolidierung sowie der Zeitpunkt
der ersten Ausfuhrung nach dem Start der Applikation konnen uber die bereits erwahnte Konfigu-
rationsdatei definiert werden.
Die Datenbankabstraktionsschicht
Die Datenabstraktionsschicht wird durch die Klasse qsf40.DBConnection implementiert. Sie
kapselt ein java.sql.Connection-Objekt und samtliche SQL-Statements, die im Rahmen
der Datenkonsolidierung zur Anwendung kommen, in entsprechenden Methoden. Daruber hinaus
ist die Klasse fur das Offnen und Schließen der Datenbankverbindung verantwortlich. Zugriffe auf
die Datenbank durch die Datenbereinigungsprozesse erfolgen ausschließlich uber entsprechende
Methodenaufrufe der Datenbankabstraktionsschicht.
Der Logger
Mithilfe des Loggers konnen Fehlermeldungen und sonstige Meldungen seitens der Applikati-
on protokolliert werden, um das Uberwachen und Debuggen der Applikation zu erleichtern. Der
KAPITEL 7. IMPLEMENTIERUNG 79
Logger ist mithilfe der Java Logging API (Paket java.util.logging) realisiert. Das Log-
Level sowie das Verzeichnis, in dem die Log-Datei gespeichert wird, konnen ebenfalls uber die
Konfigurationsdatei definiert werden.
Die Datei-Parser
Zum Einlesen der Quelldateien steht fur jeden Quelldatei-Typ ein eigener Datei-Parser zur Verfu-
gung. Die verschiedenen Datei-Parser sind in den folgenden Klassen implementiert:
• qsf40.reader.CombinationFileReader (Kombinationsdaten)
• qsf40.reader.ShimFileReader (Shim-Daten)
• qsf40.reader.ExitDataFileReader (Ausschleusungsdaten)
• qsf40.reader.DFQFileReader (Schraub- und Presskraftdaten)
Der Parser fur DFQ-Dateien ist dabei in der Lage, alle in der Montagelinie erzeugten DFQ-Dateien
einzulesen. Alle Parser-Klassen implementieren eine Methode readLine(), die je nach Parser-
Klasse ein Objekt der Klasse qsf40.Combination,qsf40.Shim,qsf40.ExitDataoder
ein Array mit Objekten der Klasse qsf40.Measurement zuruckliefert. Die ersten drei ge-
nannten Klassen kapseln jeweils alle Werte einer Zeile der entsprechenden CSV-Datei. Die Klasse
Measurement kapselt alle relevanten Werte, die zu einer Schraub- bzw. Pressoperation gespei-
chert werden sollen. Jedes Measurement-Objekt besitzt damit sowohl Werte der zuletzt ge-
lesenen Zeile aus dem Werteteil als auch Werte aus dem Beschreibungsteil, der unmittelbar nach
Offnen der DFQ-Datei komplett ausgewertet wird. Werte weiterer nicht relevanter Schlusselfelder,
die ggf. in einer DFQ-Datei gespeichert sind, werden beim Einlesen ignoriert. Die Anzahl der
Measurement-Objekte im zuruckgelieferten Array ist abhangig von der Anzahl der Qualitats-
merkmale, die bei der Bearbeitung eines Teils erfasst wurden (Anzahl Spindeln bei Schraubkraft-
dateien, Anzahl Schritte bei Presskraftdateien).
Der SessionBuffer
Die Klasse qsf40.SessionBuffer dient der Speicherung verschiedener Konfigurationsein-
stellungen der Applikation sowie einer Referenz auf das Logger-Objekt uber die gesamte Lauf-
zeit der Applikation. Bei der Implementierung der Klasse wurde das Singleton-Muster realisiert,
so dass uber einen Aufruf der Methode getInstance() aus allen Komponenten der Appli-
kation auf das Singleton-Objekt und damit auf die Konfigurationseinstellungen und den Logger
zugegriffen werden kann. Beim ersten Aufruf der Methode getInstance(), der in der Me-
thode main der Klasse qsf40.QSF40 vor Erzeugung der Timer-Instanz erfolgt, werden die
in der Datei qsf40.properties gespeicherten Konfigurationseinstellungen eingelesen. Die
KAPITEL 7. IMPLEMENTIERUNG 80
Konfigurationsdatei beinhaltet im Wesentlichen die Verbindungsdaten zur Datenbank, die Namen
der Eingangsverzeichnisse, das Log-Level, die Zeitspanne zwischen zwei Ausfuhrungszeitpunkten
der Datenbereinigung sowie die Zeitspannen, nach denen Datensatze aus den jeweiligen Fehler-
und Hilfstabellen geloscht werden sollen (vgl. Abschnitt 6.3.5). Uber entsprechende Methoden-
aufrufe konnen die Einstellungen abgefragt werden. Nach Einlesen der Konfigurationsdatei wird
das Logger-Objekt erzeugt und ein Verbindungstest zur Datenbank durchgefuhrt. Tritt dabei ein
Fehler auf, wird die Applikation vorzeitig beendet.
Die Datenbereinigungsprozesse
Fur jeden der in Abschnitt 6.3 definierten Datenbereinigungsprozesse existiert eine eigene Klasse.
Dabei handelt es sich um folgende Klassen:
• qsf40.tasks.CombinationDataLoadingTask (Laden und Bereinigen der Kom-
binationsdaten)
• qsf40.tasks.MeasurementLoadingTask (Laden und Bereinigen der Schraub- und
Presskraftdaten - 1. Phase)
• qsf40.tasks.CombinationTask (Laden und Bereinigen der Schraub- und Presskraft-
daten - 2. Phase)
• qsf40.tasks.ShimDataLoadingTask (Laden und Bereinigen der Shim-Daten)
• qsf40.tasks.ExitDataLoadingTask (Laden und Bereinigen der Ausschleusungs-
daten)
• qsf40.tasks.CleaningTask (Bereinigen der Fehler- und Hilfstabellen)
Jede dieser Klassen verfugt uber eine Methode run(), die den entsprechenden Datenbereini-
gungsprozess implementiert und von dem Thread”ConsolidationTask“ aufgerufen wird. Jeder
Bereinigungsprozess, der Quelldateien einliest, uberpruft anfangs das Eingangsverzeichnis auf
neu eingetroffene Quelldateien. Jeder Datenbereinigungsprozess verfugt dabei uber ein eigenes
Eingangsverzeichnis, welches in der Konfigurationsdatei spezifiziert werden kann. Beinhaltet das
Eingangsverzeichnis keine Quelldateien, so wird der Prozess beendet. Anderenfalls werden alle
Quelldateien im Eingangsverzeichnis nacheinander mithilfe des passenden Datei-Parsers eingele-
sen. Die in den Quelldateien gespeicherten Daten werden gemaß den in Abschnitt 6.3 beschriebe-
nen Definitionen der Datenbereinigungsprozesse verarbeitet. Nach erfolgreichem Abarbeiten ei-
ner Quelldatei wird diese aus dem Eingangsverzeichnis geloscht. Sobald alle Dateien erfolgreich
abgearbeitet und geloscht wurden, wird der Datenbereinigungsprozess beendet. Zur Speicherung
der Schraub- und Presskraftdaten greifen die beiden Prozesse”MeasurementLoadingTask“ (Laden
und Bereinigen der Schraub- und Presskraftdaten - 1. Phase) und”CombinationTask“ (Laden und
KAPITEL 7. IMPLEMENTIERUNG 81
Bereinigen der Schraub- und Presskraftdaten - 2. Phase) auf dieselbe Routine zu.
Bei der Implementierung der Datenbereinigungsprozesse wurde ein großes Augenmerk auf die
Ausnahmebehandlung gelegt, um eine hohe Stabilitat der Applikation zu erreichen sowie Da-
tenverluste zu vermeiden. Es wird sichergestellt, dass eine Quelldatei nur dann geloscht wird,
wenn sie auch fehlerfrei abgearbeitet werden konnte. Bei schwerwiegenden Fehlern (z. B. Nicht-
Erreichbarkeit der Datenbank) wird ein Datenbereinigungsprozess direkt mit einer entsprechenden
Fehlermeldung beendet.
7.2 Das Frontend
Das Frontend wurde mithilfe von JavaServerPages (JSP) realisiert. Aufgrund der wenig komplexen
Business-Logik wurde auf ein Prasentationsframework (z. B. Struts) zur Trennung von Business-
Logik und Layout oder auf einen Application-Server verzichtet. Bei der Implementierung wurde
u. a. fur die Datenbankanbindung die Java Standard Tag Library verwendet. Als Servlet-Container,
in dessen Umgebung die Seiten implementiert und getestet wurden, wurde der Tomcat 4.1 verwen-
det. Insgesamt besteht das Frontend aus den folgenden JSP-Dateien:
• search.jsp. Diese Seite ist die Startseite des Frontends, sie zeigt eine Eingabemaske zur
Spezifizierung der Suchkriterien an, fuhrt die Suche durch und zeigt nach einer erfolgreichen
Suche die Trefferliste an (vgl. Anwendungsfalle 1 und 2 in Abschnitt 3.4).
• station overview.jsp. Diese Seite zeigt, nachdem in der Trefferliste ein Getriebe
ausgewahlt wurde, alle Stationen an, zu denen Qualitatsdaten des ausgewahlten Getriebes
in der Datenbank vorhanden sind (vgl. Anwendungsfall 1 in Abschnitt 3.4).
• pressing screwing data.jsp. Diese Seite zeigt, nachdem in der Liste der Statio-
nen eine Station ausgewahlt wurde, alle Schraub- und Presskraftdaten bezuglich des aus-
gewahlten Getriebes und der ausgewahlten Station an (vgl. Anwendungsfall 1 in Abschnitt 3.4).
• shim data.jsp. Diese Seite zeigt die Shim-Daten eines Getriebes an. Sie wird aufgeru-
fen, wenn auf der Seite station overview.jsp die Station ST150 ausgewahlt wurde
(vgl. Anwendungsfall 1 in Abschnitt 3.4).
Kapitel 8
Tests der Applikation QSF40
In diesem Kapitel wird die Vorgehensweise bei den durchgefuhrten Tests der Applikation QSF40
erlautert. Da ein Test der Applikation unter Realbedingungen, also bei laufendem Montagebetrieb
nicht durchgefuhrt werden konnte, weil die Prozesse zurUbertragung der Daten von den Montage-
Stationen zum Server bis zuletzt nicht eingerichtet waren, wurde eine GUI-gestutze Applikation
mit dem Namen”QSF40Sim“ implementiert, die das Verhalten der Montagelinie aus Sicht der
Applikation QSF40 simuliert. In Abschnitt 8.1 wird diese Applikation in ihrem Aufbau und ihrer
Funktionsweise grob beschrieben. In Abschnitt 8.2 werden schließlich die durchgefuhrten Tests
erlautert.
8.1 Die Applikation QSF40Sim
Die Applikation QSF40Sim simuliert das Verhalten der Montagelinie, indem sie Quelldateien in
die Eingangsverzeichnisse der Applikation QSF40 ubertragt, was unter Realbedingungen durch
die Datenubertragungsprozesse geschieht. Die abgelegten Quelldateien beinhalten dabei Prozessda-
ten, die von der Applikation QSF40Sim selbst erzeugt werden. Die verwendeten Dateiformate sind
aquivalent zu den Original-Dateiformaten aus der Montagelinie.
Die Applikation QSF40Sim stellt ein komplettes Modell der Montagelinie dar. Der Aufbau der
Montagelinie wird im Wesentlichen durch Instanzen folgender Klassen abgebildet:
• qsf40sim.Palette
• qsf40sim.Spindle
• qsf40sim.ControlUnit
• qsf40sim.Station
Objekte der Klasse Palette reprasentieren Paletten, auf denen Teile transportiert werden, und
speichern daher Seriennummern von Komponenten bzw. Getrieben. Spindle-Objekte reprasen-
82
KAPITEL 8. TESTS DER APPLIKATION QSF40 83
tieren Spindeln und sind fur das Erzeugen von Prozessdaten zustandig. ControlUnit-Objekte
stellen die Datei-generierenden Systeme dar. Sie ubertragen nach Abschluss einer Schicht die in
den Spindle-Objekten erzeugten Daten in Form von Textdateien in die Eingangsverzeichnisse
der Applikation QSF40. Die Station-Objekte reprasentieren die Stationen der Montagelinie.
Uber Referenzen ist jedes Station-Objekt sowohl mit dem Objekt der vorgeschalteten Station
als auch mit dem Objekt der nachgeschalteten Station verknupft. Ein Station-Objekt ist fur die
Annahme und Weitergabe von Palette-Objekten zustandig. Nach Annahme eines Palette-
Objektes liest das Station-Objekt die Seriennummer aus und veranlasst die Erzeugung von
Prozessdaten zu der eingelesenen Seriennummer. Da die Ausgangsstationen, die Endstation sowie
die Station ST140 ein anderes Verhalten als die sonstigen Stationen aufweisen, existieren fur diese
Stationen entsprechende Unterklassen der Klasse Station.
Zur Abbildung des Montageprozesses wurde das Erzeuger/Verbraucher-Muster implementiert.
Jedes Station-Objekt lauft innerhalb eines eigenen Threads und verhalt sich gleichzeitig aus
Sicht seines Vorganger-Objektes als”Verbraucher“ und aus Sicht seines Nachfolger-Objektes als
”Erzeuger“ von Palette-Objekten, indem es kontinuierlich bei seinem Vorganger-Objekt ein
Palette-Objekt anfordert und es nach einer definierten Durchlaufzeit an sein Nachfolger-Objekt
freigibt. Produziert ein Station-Objekt wesentlich langsamer als sein Nachfolger-Objekt, so
muss das Nachfolger-Objekt solange warten, bis ihm ein neues Palette-Objekt ubergeben wird.
Gleichermaßen konnen sich Palette-Objekte aufstauen, wenn ein Station-Objekt wesentlich
langsamer als sein Vorganger-Objekt arbeitet. Uberschreitet die Zahl der aufgestauten Palette-
Objekte einen bestimmten Wert, kommt es zu einem”Produktionsstillstand“ bei dem Vorganger-
Objekt.
Die Spindle-Objekte erzeugen mithilfe von Zufallsgeneratoren (Klasse java.util.Random)
Prozessdaten, worunter sich auch Daten mit syntaktischen Fehlern und fehlenden Werten befinden.
Daruber hinaus konnen auch Anderungen der Grenzwerteinstellungen sowie Wiederholungen von
Operationen simuliert werden. Die Dauer einer Schicht sowie die Durchlaufzeiten der einzelnen
Stationen konnen spezifiziert werden. Indirekt lasst sich mithilfe dieser Parameter die Stuckzahl
der in einer Schicht montierten Getriebe definieren.
8.2 Durchfuhrung der Tests
Die Basisklassen der Applikation QSF40 wurden fortlaufend wahrend der Implementierungspha-
se getestet. Zweck der Tests war es mithilfe von Testfallklassen die korrekte Funktionsweise der
einzelnen Klassen zu testen, wie etwas das korrekte Einlesen von Quelldateien durch die ent-
sprechenden Datei-Parser oder das korrekte Ausfuhren der SQL-Statements in der Datenbankab-
straktionsschicht. Zum Testen der Parser-Klassen wurden sowohl selbst erzeugte Dateien aller
Quelldatei-Typen als auch DFQ-Dateien, die von dem Lieferanten Promess zur Verfugung gestellt
wurden, verwendet. In einem nachsten Schritt wurden mithilfe der Basisklassen die Datenberei-
KAPITEL 8. TESTS DER APPLIKATION QSF40 84
nigungsprozesse implementiert und hinsichtlich ihrer korrekten Funktionsweise isoliert voneinan-
der getestet. In einem letzten Schritt wurden die Implementierungen der einzelnen Bereinigungs-
prozesse zu einer ganzen Applikation zusammengefugt. Bei den anschließenden Tests der Ap-
plikation standen im Gegensatz zu den vorangegangenen Tests Aspekte wie Speicherverbrauch,
CPU-Auslastung und Stabilitat unter moglichst realistischen Bedingungen im Vordergrund. Ein
Vorteil bei der Zuhilfenahme der Applikation QSF40Sim bestand in der Moglichkeit, die Schicht-
dauer, die in der Realitat acht Stunden betragt, deutlich zu verkurzen ohne dabei die Menge
der erzeugten Daten zu reduzieren. Damit war es moglich die Applikation QSF40 uber einen
langeren Zeitraum mit realistischen Datenmengen zu testen, wobei lediglich die Zeitraume zwi-
schen zwei Ausfuhrungszeitpunkten der Datenbereinigungsprozesse verkurzt waren. Wahrend der
Testdurchfuhrungen liefen die Applikation QSF40 sowie die Oracle-Datenbank (Oracle 9.1, Stan-
dardinstallation) auf einer Sun UltraSPARC 60 Workstation mit einem 450MHz Prozessor und
2GB Arbeitspeicher unter Sun Solaris 8.0. Die Applikation QSF40Sim lief wahrend dessen auf
einem separaten Personal Computer. Die von der Applikation QSF40Sim erzeugten Quelldateien
wurden fortlaufend uber das Netzwerk in die auf der Sun Workstation befindlichen Eingangsver-
zeichnisse kopiert.
Bei allen Testdurchfuhrungen betrug die Schichtdauer 45 Minuten und die Durchsatzrate ca. 350
Getriebe/Schicht. Theoretisch hatte die Schichtdauer auch auf wenige Minuten verkurzt werden
konnen, doch benotigt die Applikation QSF40 einen Zeitraum von bis zu 40 Minuten, die Daten ei-
ner Schicht (350 Getriebe, 12.250 Datensatze) in die normalisierte Datenbank zu schreiben. Um zu
gewahrleisten, dass die Applikation QSF40 bis Abschluss einer Schicht alle Daten der vorangegan-
gen Schicht abgearbeitet hat, wurde die genannte Schichtdauer gewahlt. Die Gesamtdauer jeweils
einer Testdurchfuhrung war unterschiedlich lang und lag zwischen einer Schichtdauer und drei
Tagen. Bei allen Tests lag die CPU-Auslastung wahrend der Ausfuhrung der Datenbereinigungs-
prozesse in einem unkritischen Bereich, der Speicherverbrauch lag ebenfalls nach anfanglichem
Ansteigen konstant bei einem unkritischen Wert.
Mithilfe der durchgefuhrten Tests konnten Unzulanglichkeiten bei der Ausnahmebehandlung auf-
gedeckt werden. Nach einigen Verbesserungen bei der Ausnahmebehandlung lief die Applikation
schließlich stabil.
Kapitel 9
Fazit
Die Heterogenitat der Quellsysteme ist nicht sehr stark ausgepragt, da nur wenige Hersteller an der
Entwicklung der Quellsysteme beteiligt sind und die Formate fur die Schraub- und Presskraftdaten
standardisiert sind. Außerdem existieren zwischen den einzelnen Datensatzen keine komplexen
Abhangigkeiten. Die Bereinigung der Quelldaten kann mithilfe der in der Zieldatenbank definier-
ten Integritats-Constraints durchgefuhrt werden, wobei allerdings auf eine Plausibilitatskontrolle
der Zeitstempel verzichtet wird. Infolge der eben genannten Punkte ist die Integration der Quell-
daten unproblematisch.
Die Implementierung der Datenbereinigungsprozesse als Standalone-Applikation in Java ohne Zu-
hilfenahme externer Tools stellt eine schwache Kopplung zu anderen Applikationen sicher. Es ist
ohne großen Aufwand moglich, Qualitatsdaten weiterer Spindeln, die ursprunglich nicht im An-
forderungsbereich lagen, von der Applikation erfassen zu lassen. Hierzu muss lediglich in einer
bestimmten Tabelle der Zieldatenbank ein Datensatz angelegt werden.
Trotz nicht abgeschlossener Einrichtung der Datenubertragungsprozesse in der Montagelinie konn-
te die Applikation mithilfe der Applikation QSF40Sim unter annahernd realistischen Bedingun-
gen getestet werden. Unter Testbedingungen funktionierte die implementierte Losung im Bezug
auf Performance und Stabilitat gut, so dass die Testergebnisse als positiv zu bewerten sind.
Mit der Applikation QSF40 zur Datenkonsolidierung sowie dem realisierten Frontend zur Erzeu-
gung aller geforderten Reports, sind alle gestellten Anforderungen der Opel Powertrain GmbH
erfullt.
Unabhangig davon sei jedoch erwahnt, dass die Datenqualitat stark von der Disziplin der Arbeiter
und deren strikter Einhaltung des Fertigungsprozesses abhangt. Gelegentlich werden Getriebe auf
Paletten ausgetauscht, ohne dass die Getriebe-Seriennummer auf dem Datentrager der betroffe-
nen Palette entsprechend aktualisiert wird. Dies gilt auch fur den Austausch von Komponenten
und deren virtuelle Kennungen bei Reparaturen. Es ist vorgekommen, dass ein fertig montiertes
Getriebe auseinandergebaut, die auf dem Gehause eingelaserte Getriebe-Seriennummer ausgefeilt
wurde und das Getriebe anschließend unter einer anderen Getriebe-Seriennummer in die Monta-
85
KAPITEL 9. FAZIT 86
gelinie eingeschleust wurde. In solchen Fallen konnen selbstverstandlich trotz Durchfuhrung einer
Datenbereinigung keine korrekten Daten zur Verfugung gestellt werden.
Literaturverzeichnis
[1] Fiat-GM-Powertrain Manufacturing Engineering. General specification for measuring value-
generating systems at SPC applications, Version 2.0, 2003
[2] Rahm, Erhard; Do, Hong-Hai. Data Cleaning: Problems and Current Approaches, IEEE
Bulletin of the Technical Committee on Data Engineering, Vol 23 No. 4, December 2000
[3] Maletic, Jonathan; Marcus, Andrian. Data Cleaning: Beyond Integrity Analysis, in Procee-
dings of The Conference on Information Quality (IQ2000), Massachusetts Institute of Techno-
logy, October 20-22, 2000, pp. 200-209
[4] Muller, Heiko; Freytag, Johann-Christoph. Problems, Methods, and Challenges in Compre-
hensive Data Cleansing, Technical Report HUB-IB-164, Humboldt University Berlin, 2003
[5] Opel Powertrain Manufacturing Engineering. Pflichtenheft SPC-Netzwerk, 2001
[6] Q-DAS GmbH. Q-DAS ASCII Transferformat, 2003
[7] BAB Automationstechnik GmbH. Programmbeschreibung Opel F40 - Station 140, 2002
[8] General Motors Engineering. GME Liste der Aufbewahrungszeiten fur Qualitatsdokumente
und -aufzeichnungen, D10A1D4 Revision 5, 2000
[9] Grote, K.-H.; Beitz, W. Taschenbuch fur den Maschinenbau, Springer, 19. Auflage, 1997
[10] Witten, I.H.; Frank, E. Data Mining - Praktische Werkzeuge und Techniken fur das maschi-
nelle Lernen, Hanser, 2001
87
Anhang A
Tabellen
88
ANHANG A. TABELLEN 89
Code Merkmal
0017DW Drehwinkel0017AR Drehwinkel1916DM Drehmoment1916TQ Drehmoment1503ET Einpresstiefe1503PD Einpresstiefe1505EK Einpresskraft1505PF Einpresskraft
Tabelle A.1: Codes zur Identifizierung der Qualitatsmerkmale
Schlusselfeld Bedeutung
K0001 MesswertK0002 FehlercodeK0004 ZeitstempelK0006 SeriennummerK0007 SpindelnummerK0008 StationsnummerK2001 MerkmalscodeK2110 Unterer GrenzwertK2111 Oberer Grenzwert
Tabelle A.2: Von einer DFQ-Datei zu untersutzende Schlusselfelder eines Qualitatsmerkmals