Kapitel 1 Einleitung

Transcription

Universität des Saarlandes, FR Informatik
Max-Planck-Institut für Informatik, AG5
Diplomarbeit im Fach Informatik
Echtzeitdatenerfassung und
Datenkonsolidierung zur
Qualitätssicherung 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 Rüsselsheim werden im Rahmen der Qualitätssicherung 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 anfallenden Prozessdaten, um eine einheitliche Basis für spätere Data Mining-Analysen und sonstige
Datenabfragen zu schaffen.
Ich versichere hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als
die angegebenen Quellen und Hilfsmittel verwendet habe.
Christian Nicolaus
Saarbrücken, 28. Juli 2005
Danksagung
Diese Arbeit entstand in der Fachrichtung Informatik an der Universität des Saarlandes in Zusammenarbeit mit der Opel Powertrain GmbH in Rüsselsheim. Ich möchte an dieser Stelle folgenden
Personen danken:
Herrn Dr. Manfred Hensel
von der EDS Deutschland GmbH, für die ausgesprochen freundliche Unterstützung bei allen auftretenden
Fragen und Problemen sowie die gute Betreuung der
Arbeit.
Frau Britta Basler
von der EDS Deutschland GmbH, für die kritischen
und hilfreichen Anmerkungen.
Herrn Prof. Dr.-Ing. Gerhard Weikum
für die Betreuung der Arbeit seitens der Universität.
Allen anderen beteiligten Personen
der Opel Powertrain GmbH, der Adam Opel AG sowie 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 Rüsselsheim . . . . . . . . . . . . . . . . . . . . .
Inhaltsüberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4
1.3
2
3
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
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
4
5
Datenerfassung und Datenübertragung
19
4.1
Datenerfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.2
Periodische versus sofortige Datenübertragung
. . . . . . . . . . . . . . . . . .
20
4.3
Übertragung 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
Übertragung der Kombinationsdaten . . . . . . . . . . . . . . . . . . . . . . . .
28
4.5
Übertragung der Shim-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.6
Übertragung der Ausschleusungsdaten . . . . . . . . . . . . . . . . . . . . . . .
29
Grundlagen zur Datenkonsolidierung
30
5.1
Datenqualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.2
Datenqualitätsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
Integritätskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.4.3
Ausreißererkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Die Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.5.1
Datenanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.5.2
5.5.3
Definition des Zielschemas . . . . . . . . . . . . . . . . . . . . . . . . .
Definition der Datenbereinigungsprozesse . . . . . . . . . . . . . . . . .
45
46
5.5
6
ii
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
7
8
9
iii
6.3.4
Einlesen und Bereinigen der Ausschleusungsdaten . . . . . . . . . . . .
76
6.3.5
Bereinigen der Import- und Fehlertabellen . . . . . . . . . . . . . . . . .
76
Implementierung
77
7.1
Die Applikation QSF40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
7.2
Das Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
Tests der Applikation QSF40
82
8.1
Die Applikation QSF40Sim . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
8.2
Durchführung der Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
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 für eine DFQ-Datei mit Schraubkraftdaten . . . . . . . . . . . . . . . .
27
4.3
4.4
Beispiel für eine DFQ-Datei mit Presskraftdaten . . . . . . . . . . . . . . . . . .
Auszug aus einer Datei mit Kombinationsdaten . . . . . . . . . . . . . . . . . .
28
29
4.5
Auszug aus einer Datei mit Shim-Daten . . . . . . . . . . . . . . . . . . . . . .
29
4.6
Auszug aus einer Datei mit Ausschleusungsdaten . . . . . . . . . . . . . . . . .
29
5.1
Hierarchie von Qualitätskriterien nach [4] . . . . . . . . . . . . . . . . . . . . .
31
5.2
Klassifizierung von Qualitätsproblemen 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
7.1
. . . . . . . . . . . . . . . .
zu den einzelnen Getrieben . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
Aufbau der Applikation QSF40 . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
iv
Tabellenverzeichnis
2.1
Aufbau der Kombinationstabelle . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1
Übersicht der qualitätsrelevanten Stationen . . . . . . . . . . . . . . . . . . . . .
17
4.1
Anzahl erzeugter Dateien in einem Zeitraum von acht Stunden bei einer Durchsatzrate von 350 Getrieben in acht Stunden) . . . . . . . . . . . . . . . . . . . .
20
4.2
Schlüsselfelder eines Werteeintrags . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.1
Statistik zu Beispiel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.2
45
5.3
45
6.1
6.2
Metadaten der Kombinationsdaten . . . . . . . . . . . . . . . . . . . . . . . . .
Metadaten der Presskraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
51
6.3
Toleranzbereiche für Pressoperationen . . . . . . . . . . . . . . . . . . . . . . .
53
6.4
Sollwerte und Toleranzbereiche für 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 Qualitätsmerkmale . . . . . . . . . . . . . . . . .
89
A.2 Von einer DFQ-Datei zu untersützende Schlüsselfelder eines Qualitätsmerkmals .
89
Kapitel 1
Einleitung
1.1 Ziel der Arbeit
Aufgrund der hohen Kundenerwartung und der in der EU geltenden Gewährleistungspflicht sind
die Automobilhersteller bemüht, qualitativ hochwertige Produkte zu liefern. Denn hohe Produktqualität hält die Zahl der Beanstandungen seitens der Kunden gering, erhöht damit die Kundenzufriedenheit und spart erhebliche Kosten ein. Da hohe Produktqualität schließlich einen wichtigen
Wettbewerbsvorteil darstellt, bekommt die Qualitätssicherung einen immer höheren Stellenwert.
Im Zuge der Verbesserung der Qualitätssicherung bauen die Unternehmen ihre Qualitätsmanagementsysteme aus. Ein IT-gestütztes Qualitätsmanagementsystem zur durchgehenden Produktionskontrolle in der Serienfertigung ermöglicht es, Rückmeldungen aus dem Fertigungsprozess in die
zukünftige Fertigung einzubeziehen, so dass ein kontinuierlicher Qualitätsüberprüfungs- und Verbesserungsprozess sichergestellt wird. Um die Einflussfaktoren der Produktion auf das Produkt
zu erkennen, werden qualitätsrelevante 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 Datenbestände anhand von statistischen Verfahren und Techniken des maschinellen Lernens nach signifikanten Mustern und Trends durchsucht, die sonst
unerkannt geblieben wären. Data Mining kann als zentrale Phase eines als Knowledge Discovery in Databases (KDD) bezeichneten Prozesses aufgefasst werden. Dieser nicht-triviale Prozess
enthält u. a. eine Phase zur Interpretation und Konsolidierung von Mining-Ergebnissen. Die in
dieser Phase gewonnenen Erkenntnisse können möglicherweise Anreize für spätere Maßnahmen
zur Qualitätsverbesserung darstellen.
Im Rahmen der Qualitätssicherung in der Getriebemontage bei der Opel Powertrain GmbH werden im Getriebewerk in Rüsselsheim an den einzelnen Montage-Stationen qualitätsrelevante Prozessdaten erfasst und lokal gespeichert. Die durch die lokale Datenspeicherung verursachte Verteilung 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 Datenanalysen nicht möglich sind. Daher ist es erforderlich, die an den Montage-Stationen anfallenden
Prozessdaten auf einem zentralen Server zusammenzuführen und in ein einheitliches Datenschema zu integrieren. Infolge dessen wird ein schnellerer und genauerer Mining-Prozess ermöglicht,
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 häufig die Homogenisierung der Daten erforderlich, um die mitunter in unterschiedlichen Formaten gespeicherten Daten aneinander anzugleichen 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 häufig mit
Datenmängeln unterschiedlicher Art behaftet sind. Typische Datenmängel sind beispielsweise:
• Inkorrekte Angaben, verursacht durch Eingabe-, Mess- oder Verarbeitungsfehler
• Logisch widersprüchliche Angaben
• Fehlende Angaben
• Duplikate im Datenbestand
Die Ursachen für Datenmängel oben genannter Art sind vielfältig. In der Regel wird jedoch die
Qualität der Daten maßgeblich durch die Datenerfassungsphase im Quellsystem bestimmt. Wird
die Datenerfassung beispielsweise von einer Person durchgeführt, so können durch mangelnde
Fertigkeiten oder mangelnde Konzentration des Datenerfassers falsche Daten gespeichert werden.
Aber auch bei der automatischen Datenerfassung können durch defekte oder unzureichend justierte Messgeräte falsche Daten geliefert werden. Schließlich können unzureichende Eingabekontrollen oder mangelhafte Datenverarbeitungsprozesse, die der Erfassung nachgeschaltet sind, Datenmängel wie etwa fehlende Daten, logisch widersprüchliche Daten oder Duplikate begünstigen.
In der Datenübertragungsphase, in der die Datenbestände von den Quellsystemen zum Server
übertragen werden, können Datenmängel aus technischen Fehlern (z. B. Netzwerkfehlern) sowie fehlerhaften Datenverarbeitungsprozessen zur Vor- bzw. Nachbereitung der Datenübertragung
(z. B. Export aus einer Datenbank) resultieren.
Da Datenmängel oben genannter Art die Ergebnisse statistischer Verfahren verfälschen, haben sie
einen negativen Einfluss auf die Ergebnisse aus den Data Mining-Analysen, was wiederum innerhalb des KDD-Prozesses zu falschen Schlussfolgerungen in der Phase der Interpretation und
Konsolidierung von Mining-Ergebnissen führen kann. Weil demnach Datenmängel den effektiven Nutzen der Daten vermindern können, ist der Prozess der Datenbereinigung mittlerweile ein
elementarer Bestandteil der Datenintegration geworden. Der Datenbereinigungsprozess umfasst
3
sämtliche Maßnahmen, fehlerhafte Daten zu erkennen und zu beseitigen, um die Qualität der Daten zu erhöhen. Aufgrund der großen Datenmengen, die gewöhnlicher Weise erzeugt werden, ist
es unvermeidlich, die Datenbereinigung weitestgehend automatisiert durchzuführen.
Ziel dieser Arbeit ist es, für das Getriebewerk der Opel Powertrain GmbH in Rüsselsheim ein
System zu entwickeln, welches kontinuierlich neu erfasste Prozessdaten konsolidiert und in eine
zentrale Datenbank schreibt, um damit eine einheitliche Basis für Datenanalysen zu schaffen. Mit
dem Ziel einer frühzeitigen 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. Rüsselsheim ist Entwicklungs- und Produktionsstandort für Getriebe und Antriebstechnik mit ca. 1.750 Mitarbeitern. Insgesamt beschäftigt die Fiat-GM-Powertrain 24.000 Mitarbeiter an 17 Fertigungsstandorten und 7 Forschungs- und Entwicklungszentren in neun Ländern Europas, Afrikas, Asiens und
Südamerikas. Die Jahresproduktion umfasst ca. 5 Millionen Getriebe und ca. 5 Millionen Motoren. Der Jahresumsatz beläuft sich auf insgesamt 7 Milliarden Euro. Die Fiat-GM-Powertrain ist
damit das weltweit größte eigenständige Unternehmen auf dem Antriebssektor. Zu den Kunden
zählen u. a. Alfa Romeo, Fiat, Chevrolet, Cadillac, Lancia, Opel, Saab und Vauxhall.
1.2.2 Das Getriebewerk in Rüsselsheim
Im Rüsselsheimer Getriebewerk werden gegenwärtig ausschließlich F40-Getriebe in verschiedenen Ausführungen (Typen) produziert. Das F40-Getriebe ist ein 6-Gang-Schaltgetriebe für leistungsstarke Frontantriebe. Die Typenvielfalt wird durch die Erfüllung von individuellen Kundenwünschen (z. B. Übersetzung, 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 Kupplungsgehäuse.
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 Wellenfertigung oder Zahnradfertigung verteilt werden. Anschließend werden die bearbeiteten Rohteile
der Härterei zugeführt. In der Härterei werden die Teile durch eine Wärmebehandlung gehärtet.
Dieser Prozess ist notwendig, da ungehärtete Teile den hohen Kräften, die in einem Getriebe auf-
4
Abbildung 1.1: Aufbau des F40-Getriebes
treten, nicht standhalten würden. Nach der Behandlung in der Härterei und anschließend erfolgter
Präzisionsnachbearbeitung werden die Teile in den Montagebereich transportiert, wo sie zu einem
voll funktionsfähigen Getriebe zusammengesetzt werden. Die vorliegende Arbeit beschränkt sich
ausschließlich auf den Bereich der Datenerfassung im Montagebereich.
1.3 Inhaltsüberblick
Nach dieser Einleitung wird in Kapitel 2 eine Bestandsaufnahme durchgeführt. Dabei wird jenes
Wissen über den Aufbau der Montagelinie sowie über die verschiedenen Abläufe in der Montagelinie vermittelt, welches zum Verständnis späterer Diskussionen führt.
In Kapitel 3 werden die Anforderungen seitens der Opel Powertrain GmbH an das zu entwickelnde System beschrieben.
Kapitel 4 geht zunächst auf die Datenerfassung an den Montage-Stationen sowie auf die Verfahrensweise bei der Übertragung der Daten von den Montage-Stationen zum Server ein. Anschließend werden die Dateiformate, die bei der Datenübertragung zur Anwendung kommen, beschrieben.
Kapitel 5 befasst sich mit den notwendigen Grundlagen zur Datenkonsolidierung. Der Begriff der
Datenqualität wird präzisiert und die verschiedenen Datenmängel, die für die Verringerung der Datenqualität verantwortlich sein können, werden genauer erläutert. Abschließend werden mögliche
5
Abbildung 1.2: Schematischer Aufbau des Getriebewerks
Methoden zur Datenbereinigung sowie eine allgemeingültige Vorgehensweise zur Datenkonsolidierung beschrieben.
In Kapitel 6 wird die zuvor beschriebene Vorgehensweise zur Datenkonsolidierung auf den vorliegenden Anwendungsfall angewendet und eine Lösung für das zu entwickelnde System diskutiert.
Kapitel 7 geht auf die Implementierung der realisierten Lösung ein.
Kapitel 8 erläutert die Vorgehensweise sowie die erzielten Ergebnisse bei den durchgeführten Tests
der Implementierung.
Abschließend wird in Kapitel 9 ein Fazit gezogen.
Kapitel 2
Bestandsaufnahme
In diesem Kapitel werden zunächst die notwendigen Grundlagen aus dem Maschinenbau erläutert
(Abschnitte 2.1 und 2.2). Anschließend werden der grobe Ablauf des Montageprozesses (Abschnitt 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 Montageprozess erläutert, 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 Schraubenverbindungen.
Pressverbindungen
Wie in Abbildung 2.1 angedeutet, werden bei einer Pressverbindung zwei Teile zusammengefügt,
indem sie mithilfe einer Presse ineinander gepresst werden. Während vor dem Pressvorgang zwischen dem Außen- und dem Innenteil ein Übermaß besteht, wirkt nach dem Pressvorgang aufgrund
der Werkstoffpressung in der Fügefläche zwischen beiden Teilen eine Haftkraft, durch die die beiden Teile zusammengehalten werden [9]. Der Kräfteverlauf eines Pressvorgangs lässt sich durch
ein Kraft-Weg-Diagramm (siehe Abbildung 2.2) beschreiben, welches die aufgewendete Anpresskraft in Abhängigkeit des vom Pressstempel zurückgelegten Weges angibt. Im Rahmen der Qualitätssicherung ist insbesondere die aufgewendete Kraft bei Abschluss des Pressvorgangs von Bedeutung. Da das exakte Erreichen des Sollwertes aus technischen Gründen nicht möglich ist, wird
für die aufzuwendende Anpresskraft ein Toleranzbereich festgelegt, der beim Pressvorgang eingehalten werden muss. Während das Überschreiten der oberen Toleranzgrenze zur Beschädigung
6
KAPITEL 2. BESTANDSAUFNAHME
7
Abbildung 2.1: Einpressung einer Welle
der entsprechenden Teile führen kann, hat das Unterschreiten der unteren Toleranzgrenze einen
ungenügenden Zusammenhalt der Teile zur Folge.
Schraubenverbindungen
Eine Schraubenverbindung ist eine lösbare Verbindung von Teilen durch eine oder mehrere Schrauben. 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 müssen das mit
steigende Reibungsmoment im Gewinde und das Reibungsmo-
ment unterhalb des Kopfes überwunden werden [9]. Die Summe der beiden Momente ergeben
das Anziehdrehmoment, welches für die Qualitätssicherung eine relevante Größe darstellt. Wie
bei einem Pressvorgang lässt sich auch der Kräfteverlauf eines Schraubvorgangs durch ein KraftWeg-Diagramm beschreiben. Es zeigt das aufgewendete Drehmoment in Abhängigkeit der vom
Schrauber durchgeführten Drehbewegung. Bei einem Schraubvorgang ist es wichtig, dass das aufgewendete Drehmoment bei Abschluss des Schraubvorgangs in einem fest definierten Toleranzbereich liegt. Ein zu geringes Anziehdrehmoment kann dazu führen, dass mögliche Relativbewegungen der Teile gegeneinander nicht genügend verhindert werden. Ein zu hohes Anziehdrehmoment
kann eine Beschädigung der Schraube oder des Gewindes und somit ein Versagen der Schraubenverbindung zur Folge haben.
2.2 Shims
Aufgrund der Getriebekonstruktion und der Maßtoleranzen bei der Fertigung der einzelnen Getriebeteile existiert längsseitig zwischen den drei existierenden Wellen (Antriebswelle, Obere Hauptwelle, Untere Hauptwelle) und der Gehäusewand sowie zwischen dem Differentialgehäuse und der
8
Abbildung 2.2: Kraft-Weg-Diagramm einer Pressvorgangs
Gehäusewand jeweils ein Spiel. Um diese Spiele auszugleichen, wird zwischen den eben genannten Teilen und der Gehäusewand jeweils eine Scheibe (Shim) eingesetzt, die in etwa vergleichbar
mit einer Unterlegscheibe für Schrauben ist. Insgesamt existieren 25 verschiedene Shim-Größen,
die zum Ausgleich vorhandener Spiele verwendet werden können.
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 Bearbeitung werden überwiegend Schraub- und Pressoperationen durchgeführt. In dieser Arbeit wird
unter einer Schrauboperation ein einzelner Schraubvorgang und unter einer Pressoperation ein
einzelner Pressvorgang verstanden. Die grauen Rechtecke skizzieren Operationsstände, an denen
Schrauboperationen oder sonstige Tätigkeiten von einer Person durchgeführt werden.
Die Montagelinie gliedert sich in drei Verkettungsabschnitte. Während der Verkettungsabschnitt 1
(VK1) die Vormontage des Differentials und der verschiedenen Wellen umfasst, werden im Verkettungsabschnitt 2 (VK2) die Vormontage des Getriebe- und des Kupplungsgehäuses sowie die
Endmontage des Getriebes durchgeführt. Der Verkettungsabschnitt 3 (VK3) dient zur Endkontrolle des Getriebes sowie zur Durchführung einiger abschließender Arbeiten am Getriebe.
Abbildung 2.3: Layout der Montagelinie
9
10
Ein Ausgangspunkt der Montagelinie sind die Stationen ST010 und ST011, die für die Vormontage des Differentials zuständig sind. Beide führen exakt die gleichen Montageschritte durch und
laufen wahlweise im Einzel- oder im Doppelbetrieb. Jedes montierte Differential gelangt über ein
Laufband zur Station ST040, an der das Stirnrad montiert wird. Dabei werden jeweils ein Differential und ein Stirnrad miteinander verschraubt. Jedes montierte Stirnrad wird jeweils auf einer
separaten Palette, die an den nachfolgenden Stationen jeweils mit einer weiteren Getriebekomponente bestückt wird, abgelegt. Jede der drei nachfolgenden Stationen ST060, ST070 und ST080
ist für die Vormontage genau eines Wellentyps (Untere Hauptwelle, Obere Hauptwelle, Antriebswelle) zuständig. Bei der Wellenvormontage werden im Wesentlichen die Zahnräder der einzelnen
Gänge auf die Wellen aufgepresst. Nach Durchlaufen der Station ST080 verfügt jede Palette über
ein Differential, welches mit einem Stirnrad verbunden ist, sowie über drei verschiedene Wellen
und damit über einen kompletten Wellensatz, der für das Innenleben eines Getriebes erforderlich
ist.
Ein weiterer Ausgangspunkt der Montagelinie ist die Station ST110. Während an der Station
ST110 die Vormontage des Getriebegehäuses erfolgt, wird an der Station ST120 die Vormontage des Kupplungsgehäuses durchgeführt. Bei der Vormontage dieser beiden Gehäusekomponenten
werden insbesondere Dichtungsringe in die verschiedenen Gehäuseöffnungen eingepresst. Zusammengesetzt bilden die beiden Gehäusekomponenten das komplette Gehäuse eines Getriebes. Die
Getriebe- und Kupplungsgehäuse werden jeweils auf separaten Paletten in abwechselnder Reihenfolge in die Station ST140 eingeschleust.
Die Laufbänder der beiden Ausgangspunkte der Montagelinie münden 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 Kupplungsgehäuse aus der
Gehäusevormontage eingeschleust wurden, wird der Wellensatz in das Kupplungsgehäuse eingebracht und die bei diesem Vorgang frei werdende Palette ausgeschleust. Das auf einer weiteren Palette aus der Gehäusevormontage folgende Getriebegehäuse wird im weiteren Verlauf unmittelbar
hinter der Palette des Kupplungsgehäuses mit dem inzwischen eingebrachten Wellensatz transportiert, 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 welchen Gehäusekomponenten ein Getriebe zusammengesetzt wird. An der darauf folgenden Station
ST150 werden durch Ermitteln der vorhandenen Spiele die benötigten Shim-Größen ermittelt. Der
Einbau der entsprechenden Shims wird an der Station ST160 durchgeführt. Außerdem wird an dieser Station das Einstellen der Lager vorgenommen. An der Station ST190 werden nach erfolgtem
Dichtmittelauftrag die beiden Gehäusekomponenten zusammengeschraubt. Während am Operationsstand OP210 gegebenenfalls Korrekturen der Gehäuseverschraubungen durchgeführt werden,
wird am Operationsstand OP220 die Schaltmechanik montiert.
11
Im Verkettungsabschnitt 3 werden an den Stationen ST250, ST260 und ST270 akustische Endkontrollen durchgeführt, bei denen das montierte Getriebe im laufenden Betrieb getestet wird. Die
darauf folgenden Stationen sind für einige abschließende Arbeiten zuständig, wie beispielsweise
die Ölaufbereitung sowie das Einlasern der Getriebe-Seriennummer in das Getriebegehäuse. Als
letzte Tätigkeit wird an der Station ST300 ein Etikett mit der Getriebe-Seriennummer gedruckt,
welches anschließend zur logistischen Erfassung des Getriebes eingescannt wird. Von diesem Moment an steht das fertig montierte Getriebe dem Vertrieb zur Verfügung.
2.4 Aufbau einer Montage-Station
An jeder Montage-Station befinden sich verschiedene Fügevorrichtungen, deren Art und Anzahl
von den durchzuführenden Operationen abhängt. Für Schrauboperationen existieren ausschließlich Schraubvorrichtungen der Firma Bosch und für Pressoperationen ausschließlich Pressvorrichtungen der Firma Promess. Jede Fügevorrichtung verfügt wiederum über mindestens eine Spindel,
die je nach Art der Fügevorrichtung 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 Spindelnummernzuordnung, über alle Press- und Schraubspindeln einer Montage-Station betrachtet, existiert nicht.
Abgesehen von ein paar Ausnahmen bei den Pressspindeln, bei denen Verpressungen in zwei
Schritten durchgeführt werden, wird jedes Teil genau einmal von ein und derselben Spindel bearbeitet. Erfolgt eine Verpressung in zwei Schritten, so kann jeder Schritt als eine eigene Pressoperation aufgefasst werden. Jede Spindel ist mit einem Steuergerät verbunden, welches für die
Steuerung der entsprechenden Spindel und zum Empfangen der an dieser Spindel anfallenden Prozessdaten verantwortlich ist.
Des Weiteren ist jede Station mit einem gewöhnlichen Rechner (Microsoft WindowsNT 4.0) ausgestattet, der über ein lokales 10MBit-Netzwerk mit dem zentralen Server verbunden ist. In jedem Rechner ist eine speicher-programmierbare Steuereinheit (SPS) eingebaut, die wiederum mit
den an der Montage-Station befindlichen Steuergeräten verbunden ist. Eine SPS ist ein Automatisierungsgerät, welches die autarke Steuerung des gesamten Montageprozesses an der MontageStation übernimmt. Über eine Steuerungssoftware auf dem Rechner der Montage-Station können
jeder Spindel die Sollwerte sowie die Toleranzbereiche für Weg (Drehwinkel/Einpresstiefe) und
Kraft (Drehmoment/Einpresskraft) zugewiesen werden.
2.5 Aufbau eines Operationsstands
Operationsstände dienen insbesondere der Durchführung kleinerer Reparaturen an Werkstücken.
Beispielsweise kann am Operationsstand OP050 eine Verschraubung von einem Arbeiter korrigiert
werden, wenn diese zuvor an der Station ST040 aus irgendwelchen Gründen nicht zufriedenstel-
Feldname
ID OPEL
ID SAAB
ID FIAT
TIMESTAMP
V ID1
V ID2
V ID3
V ID4
V ID5
V ID6
Felddatentyp
Text
Text
Text
Datum/Uhrzeit
Text
Text
Text
Text
Text
Text
12
Beschreibung
Getriebe-Seriennummer
Kunden-Seriennummer (SAAB)
Kunden-Seriennummer (FIAT)
Zeitpunkt der Erfassung
Virtuelle Kennung: Stirnrad/Differential (ST040)
Virtuelle Kennung: Untere Hauptwelle (ST060)
Virtuelle Kennung: Obere Hauptwelle (ST070)
Virtuelle Kennung: Antriebswelle (ST080)
Virtuelle Kennung: Getriebegehäuse (ST110)
Virtuelle Kennung: Kupplungsgehäuse (ST120)
Tabelle 2.1: Aufbau der Kombinationstabelle
lend durchgeführt wurde. Die Verschraubung erfolgt in diesem Fall mit einem Handschrauber. Am
Operationsstand OP090 besteht die Möglichkeit, auf einer Palette eine fehlerhafte Getriebekomponente 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 erfolgt grundsätzlich 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 Gehäusekomponente (Stationen 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
Datenträger unterhalb der Palette geschrieben, auf der die Komponente abgelegt wird. Der Datenträger ist in der Lage, die Seriennummern sämtlicher auf der Palette befindlichen Teile zu speichern.
Sobald an der Station ST140 die für ein Getriebe notwendigen Komponenten aus der Vormontage
kombiniert werden, wird dem in diesem Moment entstehenden Getriebe eine Getriebe-Seriennummer zugewiesen. Ist das Getriebe für die Kunden Saab oder Fiat vorgesehen, so erhält das Getriebe
zusätzlich zur Getriebe-Seriennummer eine Kunden-Seriennummer. Die virtuellen Kennungen auf
den Datenträgern 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 lässt
sich für jedes Getriebe nachvollziehen, aus welchen Komponenten es zusammengesetzt wurde.
Mit Ausnahme der Palette, die nach Einbringung des Wellensatzes in das Kupplungsgehäuse aus-
13
geschleust wird, werden die virtuellen Kennungen auf den Datenträgern der Paletten durch die
zugewiesene Getriebe-Seriennummer ersetzt. Von diesem Zeitpunkt an hat nur noch die GetriebeSeriennummer Gültigkeit.
Während der Bearbeitung einer Komponente bzw. eines Getriebes durch eine Montage-Station
sendet die SPS über einen Datenbus Steuerbefehle an die Steuergeräte der einzelnen Spindeln,
dabei wird auch die Seriennummer des zu bearbeitenden Teils übermittelt. Wie bereits erwähnt,
wird in der Vormontage die Seriennummer an der jeweiligen Montage-Station selbst erzeugt, in
der Endmontage wird die Seriennummer des bearbeiteten Getriebes aus dem Datenträger unterhalb der Palette ausgelesen. Die an den Steuergeräten anfallenden Prozessdaten werden samt der
Seriennummer des bearbeiteten Teils direkt von dem jeweiligen Steuergerät an den Rechner der
Montage-Station gesendet. Prozessdaten einer fehlgeschlagenen Operation werden dabei mit einem entsprechenden Fehlercode versehen. Die auf dem Rechner installierte Steuerungssoftware
speichert die von den Steuergeräten 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 genannten Datenhaltungssysteme für 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 Ausfällen von Fügevorrichtungen oder aufgrund von fehlgeschlagenen Operationen
kann es zu Abweichungen vom normalen Montageprozess kommen. Da diese Umstände Einfluss
auf die Datenerfassung haben, werden diese kurz beschrieben:
• Kommt es zu einem Ausfall einer Schraubvorrichtung, führen die Arbeiter die Verschraubungen mithilfe eines Handschraubers durch. Wie bei der Durchführung einer Verschraubung an einem Operationsstand, erfolgt in diesem Fall keine Erfassung der zugehörigen
Prozessdaten.
• Wie in Abschnitt 2.5 erwähnt, kann am Operationsstand OP090 ein Austausch einer Getriebekomponente erfolgen. In diesem Fall wird die virtuelle Kennung der ausgetauschten Komponente auf dem Datenträger der Palette nicht durch die Kennung der neuen Komponente
ersetzt. Stattdessen erhält das Datenfeld auf dem Datenträger lediglich den Wert 99999999“
”
um den Austausch der Komponente als Solchen zu erfassen. Eine Rückverfolgung von Prozessdaten für die Ersatzkomponente ist demnach nicht mehr möglich.
14
• Falls innerhalb des Verkettungsabschnittes 2 eine Pressoperation fehlschlägt, wird das betroffene 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 erfasst. Im Falle einer Verschrottung wird das Getriebe komplett auseinander gebaut. Während
die defekten Teile verschrottet werden, dienen die intakten Teile zukünftig als Ersatzteile.
Kapitel 3
Anforderungen
Die Aufgabenstellung in der vorliegenden Arbeit ist in Kapitel 1 erläutert. Es sollen qualitätsrelevante Merkmale der in der Montagelinie anfallenden Prozessdaten erfasst, über das Netzwerk
auf einen zentralen Server übertragen 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 Qualitätssicherung relevant
sind und als Qualitätsdaten bezeichnet werden. Es handelt sich dabei um Schraub- und Presskraftdaten 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 für den Endstand des Drehwinkels
• Aktuell geltender unterer und oberer Grenzwert für den Endstand des Anziehdrehmoments
• Zeitpunkt der Operation
15
KAPITEL 3. ANFORDERUNGEN
16
3.1.2 Presskraftdaten
Zu einer Pressoperation sollen folgende Attribute erfasst werden:
• Stationsnummer, Spindelnummer und Schrittnummer1
• Endstand der Einpresstiefe
• Endstand der Einpresskraft
• Aktuell geltender unterer und oberer Grenzwert für den Endstand der Einpresstiefe
• Aktuell geltender unterer und oberer Grenzwert für den Endstand der Einpresskraft
• Zeitpunkt der Operation
3.1.3 Shim-Daten
An der Station ST150 werden die für ein Getriebe zu verwendenden Shim-Größen ermittelt. Dabei
sollen folgende Attribute erfasst werden:
• Shim-Klasse
• Getriebekomponente, für die das Shim verwendet werden soll
• Zeitpunkt der Erfassung
3.1.4 Ausschleusungsdaten
Ergänzend zu den bisher genannten Qualitätsdaten soll der Zeitpunkt erfasst werden, zu dem ein
Getriebe aus der letzten Station (ST300) ausgeschleust wird und damit die Montagelinie ordnungsgemäß verlässt.
3.2 Relevante Stationen
Obwohl an allen Stationen in den Verkettungsabschnitten 1 und 2 Press- und/oder Schrauboperationen durchgeführt werden, sind im Rahmen der Qualitätssicherung nur die Schraub- und Presskraftdaten relevant, die an den in Tabelle 3.1 aufgelisteten Stationen erfasst werden. Zusätzlich
zeigt die Tabelle, über wie viele Schraub- und Pressspindeln die einzelnen Stationen verfügen.
1
Falls eine Verpressung in zwei Schritten durchgeführt wird, dient die Schrittnummer zur Unterscheidung der beiden
Pressoperationen.
Station
ST040
ST110
ST120
ST140
ST150
ST160
ST300
Anzahl
Schraubspindeln
2
2
1
1
-
Anzahl
Pressspindeln
1
5
9
4
4
-
17
Montageschritt
Montage des Stirnrades
Vormontage des Getriebegehäuses
Vormontage des Kupplungsgehäuses
Einpressen der Innenringe
Ermitteln der zu verwendenden Shim-Größen
Einstellen der Lager sowie Einbau der Shims
Erfassen des Ausschleusungszeitpunktes
Tabelle 3.1: Übersicht der qualitätsrelevanten Stationen
3.3 Datenkonsolidierung
Bei der Datenkonsolidierung sollen folgende Anforderungen berücksichtigt werden:
• Bei allen Messwerten ist eine Genauigkeit von zwei Stellen nach dem Komma ausreichend.
• Qualitätsdaten, die aufgrund einer fehlgeschlagenen Operation bereits vom Messsystem mit
einem entsprechenden Fehlercode versehen wurden, sollen nicht gespeichert werden. In einem 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 wiederholten Durchführung 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 Entitäten der Realität sind, werden die
entsprechenden Datensätze als Duplikate bezeichnet.
• Qualitätsdaten, die aufgrund fehlerhafter Werte nicht gespeichert werden können, sollen
in einen Fehler-Report geschrieben werden. Eine Korrektur von falschen oder fehlenden
Werten soll in keinem Fall erfolgen.
• Falls für ein Getriebe nicht zu allen Operationen ein entsprechender Datensatz vorhanden
ist, so wird dies toleriert.
3.4 Frontend
Es soll ein Frontend zur Verfügung gestellt werden, mit dem der Anwender nach Getrieben suchen
und sich Qualitätsdaten anzeigen lassen kann. Das Frontend soll mit der JSP/Servlet-Technologie
18
realisiert werden. Im Folgenden werden zwei Anwendungsfälle beschrieben, um die Anforderungen an das Frontend zu verdeutlichen.
Anwendungsfall 1
Der Anwender gibt entweder eine vollständige Seriennummer (Getriebe-Seriennummer oder Kunden-Seriennummer) oder die ersten Zeichen der Seriennummer ein und startet die Suche. Anschließend wird dem Anwender eine Auswahlliste der zur Sucheingabe passenden Seriennummern
angezeigt. Nach Auswahl einer Seriennummer wird dem Anwender eine Liste derjenigen Stationen angezeigt, zu denen Qualitätsdaten bezüglich des ausgewählten Getriebes verfügbar sind.
Nach Auswahl einer Station wird dem Anwender die Gesamtheit aller an der Station angefallenen
Qualitätsdaten bezüglich des ausgewählten Getriebes angezeigt.
Anwendungsfall 2
Der Anwender spezifiziert einen Getriebetyp und/oder einen Zeitraum für den Ausschleusungszeitpunkt und startet die Suche. Anschließend werden dem Anwender die Seriennummern derjenigen Getriebe angezeigt, die alle spezifizierten Suchkriterien erfüllen.
3.5 Aufbewahrung der Daten
Die erfassten Qualitätsdaten müssen für einen Zeitraum von mindestens zwei Jahren aufbewahrt
werden. Diese Anforderung ergibt sich aus den Richtlinien in [8], die eine Grundlage zur ISOZertifizierung 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 werden. Als Programmiersprache soll Java J2SE 1.4 oder höher verwendet werden. Bei der Implementierung soll berücksichtigt werden, dass die gesamte Konsolidierung möglichst in einer eigenständigen Applikation erfolgt, um eine schwache Kopplung mit anderen Applikationen auf
dem Server sicherzustellen.
Kapitel 4
Datenerfassung und Datenübertragung
In diesem Kapitel wird zunächst auf die Datenerfassung an den Montage-Stationen (Abschnitt 4.1)
sowie auf die Verfahrensweise bei der Übertragung der Daten von den Montage-Stationen zum
Server (Abschnitt 4.2) eingegangen. In den darauf folgenden Abschnitten werden die bei der Datenübertragung verwendeten Dateiformate detailliert beschrieben.
4.1 Datenerfassung
Das Auslesen der Schraub- und Presskraftdaten aus den Steuergeräten an den einzelnen MontageStationen erfolgt durch die Steuerungssoftware, die von dem Lieferanten der jeweiligen Fügevorrichtung entwickelt und betrieben wird. Die bisher verwendeten Datenhaltungssysteme an den
Montage-Stationen für 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 näher beschrieben
wird, zur Anwendung. Auf diese Weise wird die Möglichkeit geschaffen, bei Bedarf die Schraubund Presskraftdaten der Quellsysteme mit anderweitiger Statistik-Software (z. B. QS-STAT), die
das Q-DAS-Dateiformat als Eingabeformat unterstützt, zu verarbeiten. Aus technischen Gründen
existiert für jedes Steuergerät ein Datei-erzeugendes System, so dass die an den einzelnen Steuergeräten einer Montage-Station anfallenden Schraub- und Presskraftdaten jeweils in separaten
Dateien gespeichert werden. Für die Erfassung der Kombinationsdaten, der Shim-Daten sowie
der Ausschleusungsdaten sind ebenfalls die Lieferanten der jeweiligen Vorrichtung verantwortlich. Zur Erfassung der Kombinationsdaten wird das bestehende Datenhaltungssystem (vgl. Abschnitt 2.6) dahingehend modifiziert, dass das in Abschnitt 4.4 beschriebene Dateiformat erzeugt
wird. Für Shim-Daten und Ausschleusungsdaten bestehen zum Bearbeitungszeitpunkt der Arbeit
noch keine Datenhaltungssysteme. Für diese Datenarten wird jeweils ein Datei-erzeugendes System eingerichtet. Die Dateiformate, die dabei zur Anwendung kommen, werden in den Abschnitten 4.5 und 4.6 beschrieben.
19
KAPITEL 4. DATENERFASSUNG UND DATEN ÜBERTRAGUNG
Station
Anzahl
Dateierzeugende Systeme
ST040
ST110
ST120
ST140
ST150
ST160
ST300
5
6
10
5
1
4
1
Anzahl
Dateien
(periodisch, Periodendauer:
acht
Stunden)
5
6
10
5
1
4
1
Anzahl
(sofort)
20
Dateien
1750
2100
3500
1750
350
1400
350
Tabelle 4.1: Anzahl erzeugter Dateien in einem Zeitraum von acht Stunden bei einer Durchsatzrate
von 350 Getrieben in acht Stunden)
4.2 Periodische versus sofortige Datenübertragung
Die Übertragung der an den Montage-Stationen anfallenden Daten zum Server erfolgt automatisiert in Form von Textdateien mittels des File-Transfer-Protocols (FTP). Zu Beginn dieser Arbeit
ist ungeklärt, ob die Datenübertragung sofort oder periodisch erfolgen soll. Andere Verfahrensweisen sind aus technischen und unternehmenspolitischen Gründen von vornherein ausgeschlossen.
Unter der sofortigen Datenübertragung wird in dieser Arbeit eine Verfahrensweise verstanden, bei
der eine Datenübertragung zum Server ausgelöst wird, sobald in einem Steuergerät alle Daten
bezüglich eines bearbeiteten Teils eingetroffen sind. Dies bedeutet, dass für jedes bearbeitete Teil
eine separate Quelldatei erzeugt wird, die sofort nach Speicherung der entsprechenden Daten abgeschlossen und zum Server übertragen wird.
Unter der periodischen Datenübertragung wird in dieser Arbeit eine Verfahrensweise verstanden,
bei der die Datenübertragung zum Server in periodischen Zeitabständen erfolgt. Dazu werden
alle Daten, die während einer definierten Zeitperiode in einem Steuergerät eintreffen, in einer Datei gespeichert. Nach Ablauf einer Zeitperiode wird diese Datei abgeschlossen und zum Server
übertragen.
Vorteile der sofortigen Datenübertragung sind die geringere Verlustrate der Daten sowie die gleichmäßigere Auslastung des Netzwerkes. Nachteilig wirkt sich jedoch das hohe Dateiaufkommen aus,
da als Konsequenz einer sofortigen Datenübertragung pro Steuergerät und bearbeitetem Teil eine
Datei erzeugt wird. Tabelle 4.1 zeigt die Anzahl der innerhalb einer achtstündigen Zeitperiode erzeugten Dateien bei einer periodischen Datenübertragung im Vergleich zur Anzahl der im selben
Zeitraum erzeugten Dateien bei einer sofortigen Datenübertragung. Im Falle eines Server- oder
21
Netzwerkausfalls müssen die im Zeitraum des Ausfalls erzeugten Dateien im lokalen Dateisystem des Rechners an der Montage-Station gepuffert werden. Bei der sofortigen Datenübertragung
würden je nach Dauer des Ausfalls einige hundert oder gar tausend Dateien anfallen, die nach
Behebung des Ausfalls zum Server übertragen werden müssten. Die Praxis hat gezeigt, dass eine
Montage-Station dazu nicht in der Lage ist. Erfahrungsgemäß kommt es zu einem Rechnerabsturz an der betroffenen Montage-Station, was wiederum den Ausfall der Montage-Station und
zuletzt den Ausfall der gesamten Montagelinie zur Folge hätte. Die Instabilität der Rechner an den
Montage-Stationen wird durch die Steuerungssoftware der Lieferanten verursacht.
Aufgrund der beschriebenen Nachteile, die sich aus einer sofortigen Datenübertragung ergeben,
wird die periodische Datenübertragung gewählt. Dazu werden sämtliche in einem Steuergerät eintreffenden Daten in eine Datei geschrieben, die nach Ablauf einer Schicht abgeschlossen und zum
Server übertragen wird. Als Periodendauer wird die Dauer einer Schicht (acht Stunden) gewählt,
weil dadurch die Datenübertragung zwischen zwei Schichten erfolgen kann und damit eine Beeinträchtigung des Montageprozesses an der Montage-Station als Folge der Datenübertragung ausgeschlossen werden kann.
Die Lieferanten sind damit beauftragt, unter Berücksichtigung der in den folgenden Abschnitten
beschriebenen Anforderungen an die Dateiformate entsprechende Prozesse zur Datenerfassung
und Datenübertragung einzurichten. Die Verantwortung für alle Prozesse von der Erfassung bis
zur Ablieferung der Daten auf dem Server verbleibt bei der Abteilung Getriebefertigung.
4.3
Übertragung der Schraub- und Presskraftdaten
Wie bereits erwähnt, erfolgt die Übertragung der Schraub- und Presskraftdaten im Q-DAS ASCIITransferformat, welches im folgenden Abschnitt näher beschrieben wird. Da das Dateiformat
komplex ist, werden dabei lediglich die für diese Arbeit relevanten Strukturen des Dateiformats
beschrieben. Das Dateiformat ermöglicht es außerdem, denselben Sachverhalt auf verschiedene
Arten im Bezug auf Struktur und Datenrepräsentation darzustellen. Die in den folgenden Abschnitten 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 für die Definition des Transferformates war, ein einheitliches Dateiformat zum Austausch von Qualitätsdaten zwischen verschiedenen Systemen zu bieten. Dabei sollte sich das Dateiformat insbesondere durch folgende
Eigenschaften auszeichnen [6]:
Transparenz Es sollte einen einfachen und transparenten Aufbau haben, welches für den Anwen-
22
Abbildung 4.1: Grundstruktur des Q-DAS ASCII-Transferformats (Zeichnung angelehnt an [6])
der leserlich und editierbar ist.
Flexibilität Es sollte so flexibel sein, dass man beliebig viele Inhalte und somit beliebig viele
Qualitätsmerkmale 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 Automobilindustrie etabliert. Neben dem Q-DAS ASCII-Transferformat wurde neuerdings auch ein XMLbasiertes Format QML zur Darstellung von Qualitätsdaten definiert.
Wie aus Abbildung 4.1 ersichtlich, besteht das Q-DAS ASCII-Transferformat aus einem Beschreibungs- und einem Werteteil. Die beiden Teile können entweder in zwei getrennte Dateien oder in
eine gemeinsame Datei geschrieben werden. Während eine Datei, die beide Teile beinhaltet, mit
der Endung DFQ gekennzeichnet wird, tragen eine Wertedatei die Endung DFX und eine Beschreibungsdatei die Endung DFD. Um ein zusammengehöriges DFD/DFX-Datei-Paar zuordenbar zu
machen, werden die zusammengehörigen Dateien abgesehen von ihrer Dateiendung gleichnamig
benannt. Sowohl der Beschreibungsteil als auch der Werteteil basieren auf Schlüsselfeldern, 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 über die Qualitätsmerkmale, zu denen Messwerte im Werteteil der Datei gespeichert sind. Ein Qualitätsmerkmal
23
ist eine qualitätsrelevante Größe wie etwa das aufgewendete Drehmoment bei einer Schrauboperation. Jedes Schlüsselfeld im Beschreibungsteil steht in einer eigenen Zeile und besteht aus einer
Schlüsselnummer, gefolgt von einem Leerzeichen und dem eigentlichen Feldinhalt.
Am Anfang des Beschreibungsteils, im so genannten Kopf, befindet sich das Schlüsselfeld K0100,
in dem die Gesamtanzahl der im Beschreibungsteil beschriebenen Qualitätsmerkmale hinterlegt
ist. Es folgen jeweils in einem Block die Teiledaten (K1000 - K1999), die Merkmalsdaten (K2000
- K2999), die Prüfplandaten (K3000 - K3999), die Verwaltungsdaten (K4000 - K4999) sowie die
Sonstigen Daten (K5000 - K5999). Im Folgenden wird lediglich auf die Merkmalsdaten eingegangen, da die übrigen Daten des Beschreibungsteils für die Datenauswertung im Rahmen dieser
Arbeit nicht relevant sind.
Wie bereits erwähnt, können in einer Q-DAS-Datei Messwerte zu beliebig vielen Qualitätsmerkmalen gespeichert werden. Mithilfe der Merkmalsdaten werden die Eigenschaften aller Qualitätsmerkmale, zu denen Messwerte bei der Bearbeitung eines Teils erfasst und im Werteteil gespeichert wurden, beschrieben. Dies sind z. B. Eigenschaften wie Art der Messgröße, verwendete
Messeinheit oder die Grenzwerte, die für dieses Qualitätsmerkmal zum Zeitpunkt der Operation an der Montage-Station eingestellt waren. Zur Beschreibung eines Qualitätsmerkmals dienen die Schlüsselfelder K2000 - K2999 (z. B. Schlüsselfeld K2142 für die verwendete Messeinheit). Werden in einer Q-DAS-Datei mehrere Qualitätsmerkmale beschrieben, so werden folglich einige der Schlüsselfelder mehrfach verwendet. Um die verwendeten Schlüsselfelder einzelnen Qualitätsmerkmalen zuordnen zu können, werden die beschriebenen Qualitätsmerkmale
von
bis
durchnummeriert,
so dass jedes Qualitätsmerkmal eine eindeutige Merkmalsnum-
mer erhält. Zur Zuordnung eines Schlüsselfeldes zu einem Qualitätsmerkmal wird schließlich die
Schlüsselnummer des Schlüsselfeldes um die jeweilige Merkmalsnummer ergänzt (z. B. K2001/1).
Soll der angegebene Wert eines Schlüsselfeldes für alle Merkmale gelten, kann als Merkmalsnummer der Wert “ angegeben werden (z. B. K2001/0).
”
Werteteil
Bei der Bearbeitung eines Teils wird zu jedem im Beschreibungsteil beschriebenen Qualitätsmerkmal ein Messwert erfasst. Für jeden Messwert wird im Werteteil ein Werteeintrag angelegt,
der neben dem eigentlichen Messwert noch weitere Schlüsselfelder beinhaltet. Tabelle 4.2 zeigt
eine Übersicht aller Schlüsselfelder eines Werteeintrags. Die Feldinhalte der Schlüsselfelder eines Werteeintrags werden in aufsteigender Reihenfolge der Schlüsselnummern ohne Angabe dieser hintereinander geschrieben und durch das Zeichen ¶“ voneinander getrennt. Keines dieser
”
Schlüsselfelder darf dabei weggelassen werden, wobei jedoch einige von ihnen je nach Anforderung leer sein dürfen. Die Werteeinträge der einzelnen Messwerte bezüglich eines bearbeiteten
Teils werden wiederum in aufsteigender Reihenfolge der Merkmalsnummern in eine Zeile hintereinander geschrieben und durch das Zeichen ¤“ voneinander getrennt. Seriennummern im
”
Schlüsselfeld K0006 wird grundsätzlich das Zeichen #“ vorangestellt. Der -te Werteeintrag ei”
Schlüsselfeld
Messwert
Attribut
Schlüssel
K0001
K0002
Datum/Zeit
K0004
Ereignis
Seriennummer
Spindelnummer
K0005
K0006
K0007
Station
K0008
Maschine
Prüfmittel
K0010
K0012
24
Bedeutung
der erfasste Messwert
ein Fehlercode (ein Wert ungleich 0“ bedeutet, dass die
”
Operation fehlgeschlagen ist)
ein Zeitstempel, der den genauen Zeitpunkt der Operation
bzw. der Messung angibt
(nicht relevant)
die Seriennummer des bearbeiteten Teils
die Nummer der Spindel, an der die Operation durchgeführt wurde
die Nummer der Montage-Station, an der die Operation
durchgeführt wurde
(nicht relevant)
(nicht relevant)
Tabelle 4.2: Schlüsselfelder 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 Werteeinträge, wie
Qualitätsmerkmale definiert wurden, womit jede Zeile sämtliche Qualitätsdaten 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 gewählt, da dadurch die Zahl der zu
verarbeitenden Dateien nicht unnötig verdoppelt wird und zum anderen das einander Zuordnen
der DFD/DFX-Paare entfällt. Die gewählte Variante ist demnach effizienter und weniger fehleranfällig.
4.3.3 Anforderungen an die zu erzeugenden DFQ-Dateien
Wie in Abschnitt 4.1 erwähnt, sind für die Datei-erzeugenden Systeme die Lieferanten der jeweiligen Fügevorrichtung verantwortlich. Da die Lieferanten weder die gleichen Steuergeräte noch die
gleiche Steuerungssoftware verwenden und damit unterschiedliche technische Grundvoraussetzungen haben, ergeben sich zwischen den DFQ-Dateien für Schraub- und Presskraftdaten Unterschiede bezüglich ihrer Merkmalsstruktur. Die Schlüsselfelder, die bei der Speicherung eines Qualitätsmerkmals von einer in der Montagelinie erzeugten DFQ-Datei unterstützt werden müssen,
wurden in einem für alle Lieferanten verbindlichen Pflichtenheft (vgl. [5]) definiert. Für die Datenauswertungen im Rahmen dieser Arbeit ist jedoch nur ein Teil der definierten Schlüsselfelder
erforderlich. Die erforderlichen Schlüsselfelder sind im Anhang in Tabelle A.2 aufgeführt. Im
Folgenden soll auf die Merkmalsstrukturen eingegangen und der Aufbau der DFQ-Dateien an
25
konkreten Beispielen erläutert werden.
Merkmalsstruktur einer DFQ-Datei mit Schraubkraftdaten (Lieferant Bosch)
Werden an einer Montage-Station Schrauboperationen durchgeführt, so verfügt diese MontageStation über genau ein Steuergerät für alle an der Station befindlichen Schraubspindeln. Demnach
existiert an einer solchen Montage-Station genau ein Datei-erzeugendes System für alle an der
Montage-Station anfallenden Schraubkraftdaten. Vor dem Hintergrund, dass die Datenübertragung
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 Schrauboperation zwei Qualitätsmerkmale (Drehwinkel/Drehmoment) erfasst werden, beinhaltet eine DFQDatei einer Montage-Station mit
Schraubspindeln
Messwerte zu Qualitätsmerkmalen. Die
Qualitätsmerkmale Drehwinkel“ und Drehmoment“ einer Spindel mit der Spindelnummer er”
”
und .
halten dabei die Merkmalsnummern Fallbeispiel: Eine DFQ-Datei mit Schraubkraftdaten
Im Folgenden wird der Aufbau einer DFQ-Datei mit Schraubkraftdaten an einem konkreten Beispiel, welches in Abbildung 4.2 dargestellt ist, beschrieben. Der kursiv dargestellte Text ist nicht
Bestandteil der Datei, er soll lediglich zur Erklärung der einzelnen Zeilen beitragen.
Die Schlüsselfelder K0100 bis K2142/4 stellen den Beschreibungsteil der DFQ-Datei dar. Das
Schlüsselfeld K0100 bildet den Kopf und gibt die Anzahl der beschriebenen Qualitätsmerkmale
und damit die Anzahl der Messwerte an, die bei der Bearbeitung eines Teils erfasst und im Werteteil gespeichert wurden. Der Wert 4“ impliziert, dass die Montage-Station, an der die Datei
”
erzeugt wurde, über zwei Schraubspindeln verfügt. Die Schlüsselfelder K2001/1 bis K2142/1
beschreiben die Eigenschaften des ersten Qualitätsmerkmals. Aus dem Schlüsselfeld K2001/1
mit dem Wert 0017DW“ lässt sich entnehmen, dass es sich bei diesem Qualitätsmerkmal um
”
das Merkmal Drehwinkel“ handelt. Die verschiedenen Codes zur Identifizierung eines Qua”
litätsmerkmals wurden in [1] definiert und sind im Anhang in Tabelle A.1 aufgelistet. Die Schlüsselfelder K2110/1 und K2111/1 geben den unteren und den oberen Grenzwert an, der für den
Drehwinkel zum Zeitpunkt der Operation an der Montage-Station eingestellt war. In gleicher
Weise wird mittels der Schlüsselfelder K2001/2 bis K2142/2 das zweite Qualitätsmerkmal beschrieben. Bei diesem Qualitätsmerkmal handelt es sich um das Merkmal Drehmoment“. Die
”
Schlüsselfelder K2001/3 bis K2142/3 und K2001/4 bis K2142/4 beschreiben wiederum das dritte
und vierte Qualitätsmerkmal, bei denen es sich um die Merkmale Drehwinkel“ und Drehmo”
”
ment“ handelt. Laut Vereinbarung mit den Lieferanten sind die ersten beiden Qualitätsmerkmale
der ersten Spindel und das dritte und vierte Qualitätsmerkmal der zweiten Spindel zuzuordnen.
Die Information, welcher Spindel ein Qualitätsmerkmal zuzuordnen ist, lässt sich im Übrigen
auch aus einem der dem Qualitätsmerkmal zugehörigen Werteeinträge im Werteteil ermitteln, da
26
jeder Werteeintrag über ein Schlüsselfeld K0007 zur Angabe der Spindel verfügt.
Der Werteteil der DFQ-Datei beginnt nach dem Schlüsselfeld K2142/4. Im abgebildeten Beispiel
sind die Messwerte zweier bearbeiteter Getriebe gespeichert. Die zu einem Getriebe erfassten
Messwerte sind in den Werteeinträgen der vier Qualitätsmerkmale, die durch das Zeichen ¤“
”
voneinander getrennt sind, gespeichert. Der -te Werteeintrag einer Zeile im Werteteil ist dem
-ten Qualitätsmerkmal aus dem Beschreibungsteil zuzuordnen. Aus den ersten beiden Werteein-
trägen 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 Spindel 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 durchgeführt, so ist jede Pressspindel mit einem eigenen Steuergerät verbunden. Die Anzahl der Datei-erzeugenden Systeme ist daher identisch mit der Anzahl der an der Montage-Station befindlichen Pressspindeln, so dass an der Montage-Station für jede Spindel pro Schicht eine eigene Datei erzeugt wird. Bei jeder Pressoperation werden zwei Qualitätsmerkmale (Einpresstiefe/Einpresskraft) erfasst. Wird eine Verpressung in zwei Schritten durchgeführt, werden für die zweite Pressoperation zwei weitere Qualitätsmerkmale in der DFQ-Datei gespeichert. Die Qualitätsmerkmale 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 für eine DFQ-Datei mit Presskraftdaten. Die Schlüsselfelder
K0100 bis K2142/4 stellen den Beschreibungsteil der Datei dar. Der Wert 4“ des Schlüsselfeldes
”
K0100 impliziert, dass die Pressoperation an der ersten Spindel in zwei Schritten erfolgt. Die
Spindelnummer ist aus dem Schlüsselfeld K0007 eines der im Werteteil gespeicherten Werteeinträge zu ermitteln. Die Schlüsselfelder K2001/1 bis K2142/1 beschreiben die Eigenschaften des
ersten Qualitätsmerkmals. Aus dem Schlüsselfeld K2001/1 mit dem Wert 1503ET“ lässt sich ent”
nehmen, dass es sich bei diesem Qualitätsmerkmal um das Merkmal Einpresstiefe“ handelt. Die
”
Schlüsselfelder K2110/1 und K2111/1 geben den unteren und den oberen Grenzwert an, der für
die Einpresstiefe zum Zeitpunkt der Operation an der Montage-Station eingestellt war. In gleicher Weise wird mittels der Schlüsselfelder K2001/2 bis K2142/2 das zweite Qualitätsmerkmal
beschrieben. Bei diesem Qualitätsmerkmal handelt es sich um das Merkmal Einpresskraft“. Laut
”
Vereinbarung mit den Lieferanten sind die ersten beiden Qualitätsmerkmale der ersten Pressoperation (Schrittnummer 1“) zuzuordnen. Die Schlüsselfelder K2001/3 bis K2142/3 und K2001/4
”
27
K0100
4
Anzahl Merkmale in der Datei
K2001/1 0017DW
Merkmalscode für erstes Merkmal
K2110/1 45.0
Unterer Grenzwert für Drehwinkel von Spindel 1
K2111/1 105.0
Oberer Grenzwert für Drehwinkel von Spindel 1
K2142/1 ˚
Messeinheit für Drehwinkel von Spindel 1
K2001/2 1916DM
Merkmalscode für zweites Merkmal
K2110/2 2.0
Unterer Grenzwert für Drehmoment von Spindel 1
K2111/2 12.0
Oberer Grenzwert für Drehmoment von Spindel 1
K2142/2 Nm
Messeinheit für Drehmoment von Spindel 1
K2001/3 0017DW
Merkmalscode für drittes Merkmal
K2110/3 75.0
Unterer Grenzwert für Drehwinkel von Spindel 2
K2111/3 180.0
Oberer Grenzwert für Drehwinkel von Spindel 2
K2142/3 ˚
Messeinheit für Drehwinkel von Spindel 2
K2001/4 1916DM
Merkmalscode für viertes Merkmal
K2110/4 10.0
Unterer Grenzwert für Drehmoment von Spindel 2
K2111/4 14.0
Oberer Grenzwert für Drehmoment von Spindel 2
K2142/4 Nm
Messeinheit für Drehmoment von Spindel 2
70.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 für eine DFQ-Datei mit Schraubkraftdaten
bis K2142/4 beschreiben wiederum das dritte und das vierte Qualitätsmerkmal, bei denen es sich
um die Merkmale Einpresstiefe“ und Einpresskraft“ der zweiten Pressoperation (Schrittnummer
”
”
2“) handelt.
”
Der Werteteil der DFQ-Datei beginnt nach dem Schlüsselfeld K2142/4. Im abgebildeten Beispiel sind die Messwerte zweier bearbeiteter Getriebe gespeichert. Die zu dem Getriebe erfassten Messwerte sind in den Werteeinträgen der vier Qualitätsmerkmale, die durch das Zeichen ¤“
”
voneinander getrennt sind, gespeichert. Auch hier ist der -te Werteeintrag einer Zeile im Werte-
teil dem -ten Qualitätsmerkmal aus dem Beschreibungsteil zuzuordnen. Aus den ersten beiden
Werteeinträgen 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.
28
K0100
4
Anzahl Merkmale in der Datei
K2001/1 1503ET
Merkmalscode für erstes Merkmal
K2110/1 20.0
Unterer Grenzwert für Einpresstiefe von Schritt 1
K2111/1 130.0
Oberer Grenzwert für Einpresstiefe von Schritt 1
K2142/1 mm
Messeinheit für Einpresstiefe von Schritt 1
K2001/2 1505EK
Merkmalscode für zweites Merkmal
K2110/2 10
Unterer Grenzwert für Einpresskraft von Schritt 1
K2111/2 14
Oberer Grenzwert für Einpresskraft von Schritt 1
K2142/2 kN
Messeinheit für Einpresskraft von Schritt 1
K2001/3 1503ET
Merkmalscode für drittes Merkmal
K2110/3 20.0
Unterer Grenzwert für Einpresstiefe von Schritt 2
K2111/3 130.0
Oberer Grenzwert für Einpresstiefe von Schritt 2
K2142/3 mm
Messeinheit für Einpresstiefe von Schritt 2
K2001/4 1505EK
Merkmalscode für viertes Merkmal
K2110/4 10
Unterer Grenzwert für Einpresskraft von Schritt 2
K2111/4 14
Oberer Grenzwert für Einpresskraft von Schritt 2
K2142/4 kN
Messeinheit für Einpresskraft von Schritt 2
23.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 für eine DFQ-Datei mit Presskraftdaten
Benamung der DFQ-Dateien
Um zu vermeiden, dass mehrere DFQ-Dateien den gleichen Namen erhalten, was beim Übertragen
an den zentralen Server zum möglichen Überschreiben einer Datei auf dem Server führen könnte,
erfolgt die Namensgebung nach einer Namenskonvention, die in [1] festgelegt wurde und für alle
Lieferanten verbindlich ist. Die Namenskonvention stellt sicher, dass jede in der Montagelinie
erzeugte DFQ-Datei einen eindeutigen Namen erhält. Da der Aufbau des Dateinamens für die
Datenauswertung im Rahmen dieser Arbeit nicht relevant ist, wird auf die Namenskonvention
nicht weiter eingegangen.
4.4
Übertragung der Kombinationsdaten
Die Kombinationsdaten werden ebenfalls schichtweise von der Station ST140 zum Server übertragen. 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 Übertragung der Kombinationsdaten nicht nur die während der vorangegangenen Schicht erfassten Daten, sondern alle jemals in der Access-Datenbank erfassten Daten übertragen. Abbildung 4.4 zeigt einen beispielhaften Auszug aus der CSV-Datei.
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
Übertragung 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 übertragen wird. Wie die DFQ-Dateien erhalten
auch die erzeugten Shim-Dateien einen eindeutigen Dateinamen. Abbildung 4.5 zeigt einen exemplarischen Auszug aus einer Shim-Datei. Während die Werte in der zweiten Spalte die ermittelten
Shim-Klassen darstellen, geben die Werte in der dritten Spalte die Getriebekomponente an, für die
das entsprechende Shim verwendet werden soll.
R--04165473HH;10;HWU;13.01.2004 10:12:23
R--04165473HH;11;HWO;13.01.2004 10:12:23
R--04165473HH;1;AWE;13.01.2004 10:12:23
R--04165473HH;8;DIF;13.01.2004 10:12:23
R--04165474HH;12;HWU;13.01.2004 10:37:59
Abbildung 4.5: Auszug aus einer Datei mit Shim-Daten
4.6
Übertragung der Ausschleusungsdaten
Die Ausschleusungszeitpunkte der einzelnen Getriebe werden an der Station ST300 in eine CSVDatei geschrieben, die nach Abschluss einer Schicht an den Server übertragen wird. Abbildung 4.6
zeigt einen exemplarischen Auszug aus der Datei.
R--04165473HH;13.01.2004
R--04165474HH;13.01.2004
R--04165475HH;13.01.2004
R--04165476HH;13.01.2004
10:12:23
10:18:01
10:37:59
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 Datenmängel in den Quelldaten die Datenqualität und dadurch
auch den effektiven Nutzen der Daten verringern können, müssen die Quelldaten während des
Integrationsprozesses von Datenmängeln befreit werden. Schließlich soll eine ganzheitliche Sicht
auf möglichst fehlerfreie und in sich schlüssige Daten der Quellsysteme zur Verfügung stehen.
Um dieses Ziel zu erreichen, müssen 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 Datenmängel einer Datenbereinigung. In diesem
Kapitel wird zunächst der Begriff der Datenqualität genauer definiert (Abschnitt 5.1) sowie auf
die verschiedenen Arten von Datenmängeln eingegangen (Abschnitt 5.2), die für die Verringerung der Datenqualität verantwortlich sein können. Im Anschluss daran wird auf den Prozess der
Datentransformation (Abschnitt 5.3) sowie der Datenbereinigung (Abschnitt 5.4) näher eingegangen. Im Abschluss dieses Kapitels (Abschnitt 5.5) wird eine allgemeingültige Vorgehensweise zur
Datenkonsolidierung beschrieben.
5.1 Datenqualität
Daten dienen der Repräsentation von Tatsachen oder Entitäten aus einem Ausschnitt der Realität [4]. In dieser Arbeit liegen die Daten einem relationalen Datenmodell zugrunde, in dem
Entitäten der Realität durch -Tupel repräsentiert werden und die Attributwerte der Tupel die
Eigenschaften der repräsentierten Entitäten beschreiben. Die Attributwerte werden dabei durch
Zeichenketten codiert. Gleichartige Tupel werden zu jeweils einer Relation zusammengefasst. Die
Tupel einer Relation müssen dem Schema der Relation, dem so genannten Relationen-Schema,
entsprechen. Dies bedeutet, dass die Struktur der Tupel einer Relation durch das zugehörige
Relationen-Schema bestimmt wird. Das Relationen-Schema definiert eine Liste von Attributen
und für jedes dieser Attribute eine Grammatik, die wiederum die Menge der Zeichenketten de-
30
KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG
31
Abbildung 5.1: Hierarchie von Qualitätskriterien nach [4]
finiert, die das jeweilige Attribut als Wert annehmen darf. Die Daten unterliegen damit strengen
Regeln, der so genannten Syntaktik. Die Semantik dagegen beschäftigt sich mit der Bedeutung
dieser Zeichenketten, also mit dem Wissen, welches durch die Daten repräsentiert wird. Ein effektiver Nutzen der Daten erfordert eine möglichst hohe Datenqualität. In [10] wird Datenqualität bezeichnet als die Gesamtheit aller Eigenschaften von Daten hinsichtlich der Adäquatheit,
die Anforderungen einer Anwendungssituation zu erfüllen. Da die Definition von Datenqualität
als fitness-for-use in der Praxis nicht Ziel führend ist, bedarf es der Identifizierung von allgemeingültigen Kriterien von Datenqualität. In der Literatur finden sich verschiedene Ansätze zur
Definition von Datenqualitätskriterien, die sich in der Methodik zur Bestimmung von Kriterien
unterscheiden. In Abbildung 5.1 ist eine Hierarchie von Qualitätskriterien dargestellt, die aus dem
klassischen Ansatz zur Definition von Datenqualität hervorgeht. Dieser Ansatz bezieht sowohl die
syntaktischen Eigenschaften (z. B. Einheitlichkeit der Repräsentation) als auch die semantischen
Eigenschaften (z. B. Korrektheit) von Daten ein. Die vorgestellte Hierarchie resultiert aus verschiedenen Qualitätskriterien, die sich wiederum in weitere Kriterien unterteilen lassen. Sie ist aus [4]
übernommen und verdient keineswegs den Anspruch auf Vollständigkeit. Beispielsweise lassen
sich einzelne Qualitätskriterien in weitere noch spezifischere Qualitätskriterien aufteilen. Die folgenden Definitionen zu den einzelnen Qualitätskriterien sind ebenfalls aus [4] übernommen.
• Vollständigkeit ist die Eigenschaft, dass in einem Tupel alle Attributwerte vorhanden sind.
Darüber hinaus kann unter Vollständigkeit auch die Eigenschaft verstanden werden, dass
alle in der abgebildeten Realität vorkommenden Entitäten im Datenbestand repräsentiert
sind.
• Gültigkeit ist die Eigenschaft, dass jedes Tupel im Datenbestand eine Entität repräsentiert,
die auch tatsächlich in der abgebildeten Realität existiert.
• Integrität ist die Eigenschaft, dass alle und nur diejenigen Entitäten, die in der Realität
32
existieren, von einem Tupel im Datenbestand repräsentiert werden.
• Einheitlichkeit ist die Eigenschaft, dass alle Werte innerhalb eines Attributs einheitlich verwendet werden und daher gleichartig interpretiert werden können.
• Schema-Konformität ist die Eigenschaft, dass jedes Tupel zum Schema seiner Relation konform ist. Dies bedeutet, dass jedes Tupel im Bezug auf seine Struktur und seine Werte syntaktisch 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 vollständige Repräsentation der abgebildeten Realität vorliegt. In diesem Fall sind alle der bisher genannten Kriterien erfüllt.
• Eindeutigkeit ist die Eigenschaft, dass im Datenbestand keine Duplikate existieren. Als Duplikate werden Tupel verstanden, die dieselbe Entität der abgebildeten Realität repräsentieren,
aber nicht notwendigerweise in allen Attributen übereinstimmen.
Daten, die korrekt und eindeutig sind und dabei die einzelnen Kriterien zu 100% erfüllen, stellen
ein präzises Abbild der Realität dar und sind daher Daten von höchster Qualität. Unter Praxisbedingungen variiert gewöhnlich der Erfüllungsgrad einzelner Kriterien und der Erfüllungsgrad von
100% kann oft nicht erreicht werden. Metriken, auf deren Basis Erfüllungsgrade von Kriterien bestimmt werden können und damit letztlich die Qualität von Daten gemessen werden kann, werden
nicht eingeführt.
5.2 Datenqualitätsprobleme
Ein Datenqualitätsproblem besteht, wenn Daten aufgrund ihrer Eigenschaften den in Abschnitt 5.1
beschriebenen Qualitätskriterien nicht genügen und infolge dessen die Datenqualität verringert
ist. Das Erkennen von Daten, die den Qualitätskriterien nicht genügen, und das Identifizieren
der Ursachen bzw. der Verursacher stellt eine wesentliche Grundlage für Maßnahmen zur Verbesserung der Qualität von Daten dar. In [2] wird bei Datenqualitätsproblemen zwischen Single
Source- und Multi Source-Problemen unterschieden. Single Source-Probleme resultieren aus Datenmängeln, die bereits bei der Integration von Daten einer Datenquelle auftreten können. Multi
Source-Probleme resultieren dagegen aus Datenmängeln, die im direkten Zusammenhang mit der
Integration von Daten mehrerer Datenquellen stehen. Innerhalb beider Problembereiche wird wiederum zwischen schema- und instanzbezogenen Problemen unterschieden. Die Klassifizierung
nach [2] ist in Abbildung 5.2 dargestellt.
33
Abbildung 5.2: Klassifizierung von Qualitätsproblemen nach [2]
5.2.1 Single Source-Probleme
Single Source-Probleme werden häufig durch eine fehlerhafte Datenerfassung verursacht. Eine
Vielzahl möglicher 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 können durch Fehlfunktionen der Erfassungssysteme (z. B. Messsysteme) falsche Werte zurückgeliefert werden. Darüber
hinaus können auch der Erfassung nachgeschaltete Datenverarbeitungsprozesse für Datenmängel
verantwortlich sein. Eine unzureichende Eingabe bzw. Integritätskontrolle (vgl. Abschnitt 5.4.2)
kann die unterschiedlichen Datenmängel begünstigen, da in diesem Fall ungültige Dateneingaben
von der Applikation oder von dem Datenhaltungssystem nicht zurückgewiesen werden.
Single Source-Probleme, die durch ein verbessertes Schemadesign oder eine verbesserte Integritätskontrolle vermieden werden können, 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 lediglich Restriktionen zu Format und Struktur der Daten bestehen, deren Einhaltung jedoch nicht
überprüft wird. Erfolgt die Datenhaltung in einem Datenbanksystem, sind die Qualitätsprobleme
häufig auf ein mangelhaftes Schemadesign oder auf die ungenügende Verwendung von IntegritätsConstraints zurückzuführen [2]. Letzteres geschieht in der Regel, um den mit der Verwendung von
Integritäts-Constraints verbundenen Overhead klein zuhalten. Schemabezogene Qualitätsprobleme
34
sind grundsätzlich auch auf Instanzebene sichtbar. Im Folgenden werden einige schemabezogene
Single Source-Probleme erläutert, die im Rahmen dieser Arbeit relevant sind.
Wert außerhalb des zulässigen Wertebereichs Werte, die außerhalb des Wertebereichs des entsprechenden Attributs liegen, sind unzulässige Werte und verletzen das Kriterium der SchemaKonformität.
Beispiel: timestamp = 30.13.2004
Ungültige Kombination von Attributwerten In diesem Fall ist aufgrund der Kombination der
Attributwerte eine Integritätsbedingung verletzt. Dies ist beispielsweise der Fall, wenn eine
funktionale Abhängigkeit zwischen zwei oder mehreren Attributen durch die Attributwerte nicht erfüllt und somit ein Widerspruch erzeugt wird. Eine funktionale Abhängigkeit
besteht, wenn ein Attributwert von einem Wert eines anderen Attributs bestimmt wird. In
diesem Fall ist das Kriterium der Gültigkeit 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 Wertes für das betroffene Attribut verpflichtend ist, wird das Kriterium der Vollständigkeit verletzt.
Nichteindeutigkeit von Schlüsseln Das Kriterium der (Schlüssel-)Eindeutigkeit wird verletzt durch
das doppelte Vorkommen eines Wertes in einem Attribut, welches den Primärschlüssel darstellt.
Beispiel: emp1 = (id = 1, name = smith)
emp2 = (id = 1, name = miller)
Verletzung der referentiellen Integrität Die referentielle Integegrität wird verletzt, wenn ein
durch den Fremdschlüssel referenziertes Tupel nicht existiert.
Beispiel: emp1 = (id = 1, name = smith)
id = 1 existiert in der Master-Relation nicht
Instanzbezogene Single Source-Probleme resultieren aus Datenmängeln, die auch durch eine umfassende Eingabe- bzw. Integritätskontrolle nicht vermieden werden können. Im Folgenden sind
einige instanzbezogene Single Source-Probleme aufgeführt.
35
Falscher Wert Falsche Werte sind Werte, die zwar keine Integritätsbedingungen verletzen, aber
dennoch falsch sind, weil sie die Realität nicht korrekt abbilden. Falsche Werte sind in erster
Linie auf eine falsche Erfassung (z. B. Tipp- oder Messfehler) zurückzuführen und verletzen
das Kriterium der Gültigkeit.
Fehlender Wert Bei Attributen, für 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 Realität keinen Wert für das betroffene Attribut.
2. Es gibt in der Realität einen Wert für das betroffene Attribut, jedoch war der Wert bei
Erfassung des Datensatzes nicht bekannt.
3. Es ist nicht bekannt, ob es in der Realität ein Wert für das betroffene Attribut existiert.
In den beiden letzteren Fällen ist das Kriterium der Vollständigkeit verletzt.
Fehlendes Tupel Aufgrund des Fehlens eines ganzen Tupel ist das Kriterium der Vollständigkeit
verletzt.
Duplikate Duplikate treten auf, wenn die gleiche Entität aus der Realität durch zwei Tupel repräsentiert 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 können. Die verschiedenen Probleme können sich über einzelne Attribute, über
mehrere Attribute eines Tupels oder über den gesamten Datenbestand der Quelle erstrecken. Demnach können Datenmängel eine unterschiedliche Komplexität aufweisen.
Wie bereits erwähnt, werden die Datenmängel in erster Linie durch eine fehlerhafte Erfassung
erzeugt. Werden die Quelldaten über ein Netzwerk übertragen, können Übertragungsfehler Datenmängel verursachen (z. B. fehlerhafte Werte in Textdateien infolge einer fehlerhaften FTPÜbertragung). Fehlerhafte Datenverarbeitungsprozesse zur Vor- bzw. Nachbereitung der Datenübertragung (z. B. Export aus einer Datenbank) können wiederum Mängel an den Daten zur Folge
haben.
In [4] wird unter den Datenmängeln zwischen syntaktischen und semantischen Fehlern unterschieden. Ein syntaktischer Fehler bezieht sich immer auf die Struktur der Tupel oder auf das Format
der Werte, die zur Repräsentation von Entitäteneigenschaften verwendet werden. Ein syntaktischer
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. Semantisch falsche Daten dagegen sind zwar syntaktisch korrekt, bilden jedoch die Realität nicht
korrekt ab. Semantisch falsche Daten liegen beispielsweise dann vor, wenn Integritätsbedingungen
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, können
zusätzlich zu den Single Source-Problemen weitere Probleme entstehen, die als Multi SourceProbleme bezeichnet werden. Multi Source-Probleme können durch eine starke Heterogenität der
Quellen im Bezug auf die verwendeten Datenhaltungssysteme und Schemata verursacht werden.
Heterogene Systemlandschaften existieren häufig, wenn die Systemlandschaft historisch gewachsen ist und die einzelnen Quellsysteme unabhängig voneinander von verschiedenen Organisationseinheiten entwickelt wurden und dabei jedes Quellsystem speziell an die Bedürfnisse der jeweiligen Organisationseinheit angepasst wurde.
Auf der Schemaebene kann eine heterogene Systemlandschaft zu strukturellen Konflikten führen.
Strukturelle Konflikte resultieren aus unterschiedlichen Modellierungen eines Sachverhaltes (z. B.
unterschiedliche Datentypen, Speichern von mehreren Werten in einem Attribut, statt in getrennten Attributen).
Auf Instanzebene können Attribute unterschiedlicher Quellen trotz gleichen Datentyps unterschiedlich repräsentiert sein. Dies tritt beispielsweise auf, wenn in den verschiedenen Quellen ein unterschiedliches 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 müssen, wenn etwa bei Messwerten eine nicht einheitliche Messeinheit verwendet wird. Beim Zusammenführen
von Daten aus verschiedenen Quellen können Duplikate auftreten, wenn Tupel aus verschiedenen
Quellen die gleiche Entität in der Realität repräsentieren. Häufig tritt jedoch in diesem Fall nur
eine teilweise Überlappung der Tupel auf, da sie je nach Aufgabe der jeweiligen Datenquelle verschiedene Informationen beinhalten. Nicht zuletzt können Werte aus verschiedenen Quellen einen
logischen Widerspruch erzeugen, wenn etwa die Datenerfasser der verschiedenen Quellsysteme
über einen unterschiedlichen Wissensstand bezüglich eines Sachverhaltes verfügen oder infolge
einer mangelnden Zeitsynchronisation der Quellsysteme logisch widersprüchliche Datums- und
Zeitangaben gespeichert werden.
37
5.3 Datentransformation
Ein Bestandteil der Datenintegration ist die Transformation der Quelldaten, um die Daten der
einzelnen Quellsysteme hinsichtlich ihrer Repräsentation aneinander anzugleichen und an das
einheitliche Zielschema anzupassen. Mithilfe von Datentransformationen werden demnach Multi
Source-Probleme beseitigt, die durch eine uneinheitliche Repräsentation oder auch durch strukturelle Konflikte verursacht werden. Der gesamte Vorgang geschieht in der Regel anhand fest
definierter Transformationsregeln. Im Folgenden werden einige Beispiele für Datentransformationen aufgeführt. Dabei geht es ausschließlich um die Transformation von Daten, nicht um die
Transformation von Datenstrukturen bzw. Schemata. Ein definiertes Zielschema, ggf. als Resultat einer abgeschlossenen Schemaintegration, ist dafür eine unverzichtbare Vorraussetzung (vgl.
Abschnitt 5.5.2).
Anpassung des Datentyps
Falls der Datentyp eines Quellattributs nicht mit dem des entsprechenden Zielattributs übereinstimmt, ist eine Konvertierung der Attributwerte erforderlich. z. B.:
Zeichenkette
Zeichenkette
Datum
Zahl
Anpassung der Datenrepräsentation
Manchmal wird ein bestimmtes Merkmal im Quellsystem anders repräsentiert als im Zielsystem
z. B.:
Quellsystem
Zielsystem
M
(Männlich)
F
(Weiblich)
M
(Männlich)
W
(Weiblich)
Hier muss die Repräsentation der Quelldaten an die des Zielsystems angepasst werden.
Angleichung der Messeinheit
Numerische Merkmalsausprägungen besitzen in der Regel eine Messeinheit. Dabei kann die in
einem Quellattribut verwendete Messeinheit von der im Zielattribut benötigten abweichen. In diesem Fall ist eine Umrechnung zur Angleichung erforderlich. z. B.:
cm
m
38
Separierung und Kombination von Attributwerten
Manchmal kann es vorkommen, dass in den Quellsystemen zusammengefasste Attributwerte im
Zielsystem in einzelne Attribute aufgespaltet werden müssen. Diesen Vorgang nennt man Separierung, während der umgekehrte Fall, das Zusammenfügen von einzelnen Attributen aus den Quellen als Kombination von Attributwerten bezeichnet wird. Die Zerlegung beziehungsweise Kombination 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 Durchführung verschiedener Maßnahmen mit dem Zweck sämtliche Fehler
und Ungereimtheiten zu erkennen und zu beseitigen, um ein korrektes und eindeutiges Abbild
der Realität zu erhalten [4]. Ursprünglich 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 können. Infolge dessen ist die Datenbereinigung zu
einem elementaren Bestandteil der Datenintegration geworden. Eine universelle Methode für eine
umfassende und vollständige Datenbereinigung existiert nicht. Stattdessen existiert zur Datenbereinigung eine Vielzahl verschiedener Methoden, die jeweils auf die Behebung eines bestimmten
Qualitätsproblems abzielen. Darunter existieren Methoden sowohl zur Erkennung von Datenfehlern als auch zur Korrektur von falschen oder fehlenden Werten. Weist ein Datenbestand mehrere
unterschiedliche Qualitätsprobleme auf, so müssen zur vollständigen Datenbereinigung verschiedene Methoden in angemessener Weise miteinander kombiniert werden. Die Bereinigung von Daten erfordert grundsätzlich ein gutes Wissen über die Daten bzw. den abzubildenden Sachverhalt,
deshalb hängt der Erfolg der Datenbereinigung vor allem vom verfügbaren Wissen ab. Insbesondere wenn statistische Verfahren (vgl. Abschnitt 5.4.3) zur Anwendung kommen, kann die Datenbereinigung nur mit einer gewissen Fehlerwahrscheinlichkeit erfolgen. Aus diesem Grund ist häufig
eine händische Nachbearbeitung der als fehlerhaft identifizierten Daten notwendig, weshalb der
Prozess der Datenbereinigung auch als semi-automatisch bezeichnet wird. In den folgenden Abschnitten werden Methoden vorgestellt, die bei der Datenbereinigung zur Anwendung kommen.
Dabei werden nur jene Methoden vorgestellt, die zur weiteren Argumentation in dieser Arbeit relevant sind. Methoden zur Korrektur von Daten werden nicht erläutert, da falsche oder fehlende
Werte laut Anforderungen nicht korrigiert werden sollen. Stattdessen sollen die betroffenen Tupel
ignoriert bzw. in einen Fehler-Report geschrieben werden.
39
5.4.1 Parsen
Zum wirksamen Erkennen von syntaktischen Fehlern eignen sich Parser [4]. Ein Parser für eine
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
Grammatik
Einlesen von Quelldateien und zur Überprüfung ihrer Dateistruktur eingesetzt. Darüber 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 können mit einer hohen Zuverlässigkeit Daten erkannt werden, die das Kriterium
der Schema-Konformität verletzen.
5.4.2 Integritätskontrolle
Eine Möglichkeit, fehlerhafte Daten zu erkennen, besteht in der Überprüfung der Daten im Hinblick auf das Erfüllen der geltenden Integritätsbedingungen.
Daten besitzen zu jeder Zeit eine bestimmte Konfiguration von Attributwerten mit dem Zweck
einen Sachverhalt aus der Realität abzubilden. Da die Realität bestimmten Einschränkungen und
Regeln unterliegt (z. B. kann die aufgewendete Kraft bei einem Einpressvorgang immer nur positiv sein), stellen nicht alle möglichen Konfigurationen von Attributwerten ein korrektes Abbild der Realität dar. Daher werden über die Definition des Datenmodells hinaus statische Integritätsbedingungen definiert, die in ihrer Gesamtheit die Menge aller zulässigen Attributwertkombinationen definieren. Attributwertkombinationen, die nicht die definierten Integritätsbedingungen
erfüllen, sind folglich als fehlerhaft zu bezeichnen. Integritätsbedingungen werden insbesondere
aus funktionalen Abhängigkeiten oder aus applikationsspezifischen Geschäftsregeln (BusinessRules) abgeleitet. Beispiele für Geschäftsregeln sind:
• Regeln zur Prüfung der Einhaltung von Wertebereichen
• Regeln zur Prüfung gültiger Attributwertkombinationen
• Regeln zur Prüfung der Einhaltung von Berechnungsvorschriften
• IF ... THEN ... -Regeln
Wie aus den Beispielen ersichtlich, können Integritätsbedingungen eine unterschiedliche Tragweite haben. Die Bedingungen können 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 Möglichkeit eines deklarativen Weges Integritätsbedingungen (Integritäts-Constraints) zu definieren. In
einem solchen Fall wird die Integritätskontrolle durch das Datenbanksystem selbst durchgeführt.
40
Dabei werden schreibende Datenbankzugriffe, die deklarierte Integritätsbedingungen verletzen,
vom Datenbanksystem zurückgewiesen. Der Vorteil besteht darin, dass es zur Überprüfung der
definierten Integritätsbedingungen keiner applikationsseitigen Implementierung bedarf, was die
Entwicklung der Applikation erheblich vereinfacht.
Im relationalen Datenmodell, dem eine relationale Datenbank zu Grunde liegt, existieren insgesamt vier verschiedene Arten von Integritätsbedingungen, die im Folgenden kurz beschrieben werden:
Entitäts-Integrität Die Entitäts-Integrität sichert über den Primärschlüssel die Schlüsseleindeutigkeit einer Tabelle. Ein Primärschlüssel einer Tabelle besteht aus einer Teilmenge ihrer
Attribute, so dass niemals zwei Tupel den gleichen Wert für besitzen und keine Teilmen-
ge von
existiert, die die Eindeutigkeitseigenschaft besitzt. Alternative Schlüssel können
zusätzlich als ein UNIQUE-Schlüssel deklariert werden. Damit kann gewährleistet werden,
dass die Werte in bestimmten Spalten oder Spaltenkombinationen eindeutig sind.
Referentielle Integrität Die referentielle Integrität sichert die Gültigkeit eines Verweises zwischen zwei Tabellen über einen Fremdschlüssel. Ein Fremdschlüssel bezüglich einer Relation ist eine Teilmenge
von Attributen einer Relation , so dass zu jedem Zeitpunkt
für gilt: Zu jedem Wert von existiert ein gleicher Wert im Schlüsselattribut irgendeines Tupels von Relation .
Domänenbedingungen Bedingungen dieser Art beziehen sich auf die Werte, die ein Attribut
annehmen darf. Der Datentyp des Attributs wird bereits durch die Spaltendefinition impliziert. Darüber hinaus kann die Menge der möglichen Werte eines Attributs mithilfe einer
CHECK-Klausel (z. B. CHECK (FORCE > 0)) weiter eingeschränkt werden. Durch ein
NOT NULL-Constraint wird verhindert, dass in den entsprechenden Spalten fehlende Werte
vorkommen können.
Unternehmensbedingungen Unternehmensbedingungen umfassen alle Integritätsbedingungen,
die nicht durch die bisher genannten Bedingungen abgedeckt werden. Unternehmensbedingungen können 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 realisieren. 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 ausgeführt wird. PL/SQL ist eine prozedurale Erweiterung von
Oracle-SQL, die Sprachkonstrukte zur Verfügung stellt, die ähnlich sind mit Konstrukten einer imperativen Programmiersprache. Damit wird es dem Entwickler ermöglicht, komplexere Anwendungen zu entwickeln, die den Gebrauch von Kontrollstrukturen und prozedurale
Strukturen wie Prozeduren, Funktionen und Module erfordern.
41
Abbildung 5.3: Ausreißererkennung
Mithilfe der Integritätskontrolle lassen sich alle Fehler erkennen, die in Abschnitt 5.2 im Zusammenhang mit schemabezogenen Single Source-Problemen genannt werden. Der Erfolg der
Integritätskontrolle hängt dabei im hohen Maß von der Gründlichkeit der Analyse der geltenden
Integritätsbedingungen (Integritätsanalyse) ab.
5.4.3 Ausreißererkennung
Ein weiterer Ansatz ungültige 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 abweichen, werden als Ausreißer bezeichnet und als potentielle Fehlerkandidaten betrachtet. Auf diese
Weise können auch ungültige Daten erkannt werden, die mithilfe des alleinigen Wissens aus der
Integritätsanalyse nicht erkannt werden würden. 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 multivariaten Ausreißererkennung, also zur Erkennung von komplexen Fehlern. Voraussetzung für die
Anwendung dieser Methoden ist jedoch, dass sehr große Datenbestände zur Verfügung 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 später neu eintreffende und zu bereinigende Datensätze verglichen werden. Datensätze, 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 Abständen zu aktualisieren.
42
Als Beispiel sei ein statistisches Verfahren zur univariaten Ausreißererkennung erwähnt, welches
sich gut zur Erkennung von Ausreißern unter eindimensionalen Messwerten eignet. Das im Folgenden 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.
Für gilt dann
was beispielsweise bedeutet, dass bei einer Zufallsvariablen
für für für 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.
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 für den Wert gilt: oder
. Der Wert für muss an den jeweiligen Anwendungsfall und an die Werteverteilung
des Attributs angepasst werden [3].
Im Kontext der Datenbereinigung lässt sich für ein Attribut
5.5 Die Vorgehensweise
Die in diesem Abschnitt beschriebene Vorgehensweise zur Datenkonsolidierung ist im Wesentlichen an die in [4] beschriebene Vorgehensweise angelehnt. Danach stellt die Datenkonsolidierung
einen Prozess dar, der folgende Phasen durchläuft:
1. Datenanalyse
2. Definition des gemeinsamen Zielschemas
3. Definition der Datenbereinigungsprozesse
4. Implementierung der Datenbereinigungsprozesse
43
5. Einlesen der Quelldaten und Ausführen der Datenbereinigungsprozesse
Die Datenanalyse dient zur Ermittlung des zur Datenintegration erforderlichen Wissens über die
Dateneigenschaften sowie die auftretenden Datenqualitätsprobleme. Daraufhin wird das Schema
der Zieldatenbank definiert, welches sämtliche Daten aus den Quellsystemen aufnehmen kann.
In der anschließenden Phase zur Definition der Datenbereinigungsprozesse werden Regeln für
notwendige Datentransformationen definiert, die später bei der eigentlichen Datenintegration zur
Anpassung der Quelldaten an das Zielschema angewendet werden sowie geeignete Methoden zur
Datenbereinigung gewählt. Schließlich werden Prozesse definiert, die die zeitliche Abfolge zur
Durchführung der notwendigen Transformationen und Bereinigungsschritte festlegen. Nach erfolgter Implementierung können die Daten durch Ausführung der Datenbereinigungsprozesse eingelesen, konsolidiert und in die Datenbank geladen werden.
Im Regelfall sollen die ersten vier Phasen einmalig und die fünfte Phase in regelmäßigen Abständen
wiederholt durchlaufen werden. Bei Bedarf können selbstverständlich vorangegangene Phasen
wiederholt werden, wenn beispielsweise neue Qualitätsmängel in Erscheinung treten oder es einer
Korrektur bzw. Änderung 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 erforderlich, die im Zielsystem abzubildenden Daten zu identifizieren und zu analysieren. Ziel der Analyse ist es, möglichst gutes Wissen über die Inhalte und die Struktur der zu integrierenden Daten
zu gewinnen und dabei mögliche Qualitätsprobleme (vgl. Abschnitt 5.2) aufzudecken. Grundlage für die Datenanalyse sind Dokumentationen zu den Quellsystemen sowie bereits vorhandene
Beispieldaten. Darüber hinaus können auch Interviews mit Sachverständigen weitere notwendige
Informationen liefern. Der Grad der Analyse der Daten ist je nach Anwendungsfall verschieden
und hängt mitunter davon ab, welche Methoden zur Datenbereinigung angewendet werden. In [2]
werden zwei Ansätze zur Datenanalyse genannt.
Beim ersten Ansatz, der als Data Profiling bezeichnet wird, werden im Sinne eines Meta-Reengineering durch Sichten der Daten sowie durch Anwenden von einfachen statistischen Methoden
Metadaten über die einzelnen Attribute ermittelt. In der Regel werden dabei für jedes im Rahmen
der Datenintegration relevante Attribut folgende Eigenschaften ermittelt:
• Datentyp
• Wertebereich
• typische Muster von Werten bei Zeichenketten
44
• Minimale und maximale Länge von Werten
• Minimaler und maximaler Wert bei numerischen Werten
• Vorkommen von Nullwerten
• Eindeutigkeit
• Häufigkeitsverteilung von Werten
• Ermittlung des Durchschnittswertes, des Medians sowie der Standardabweichung bei numerischen Werten
Das Ermitteln der oben genannten Metadaten ist in verschiedener Hinsicht von Bedeutung. Zum
einen stellen die Ergebnisse des Data Profiling eine Grundlage für die Definition des Zielschemas
sowie von Integritätsbedingungen dar und zum anderen kann das Data Profiling zur Identifizierung von Datenqualitätsproblemen beitragen. Mithilfe der aufgestellten Häufigkeitsverteilungen
und der ermittelten statistischen Kenngrößen wie der Standardabweichung und des Durchschnittswertes können später innerhalb des Datenbereinigungsprozesses falsche Werte (univariate Ausreißer) entdeckt werden (vgl. Abschnitt 5.4.3). Statistische Kenngrößen wie Durchschnittswert,
Median und häufigster Wert können zur Korrektur von fehlenden oder falschen Werten herangezogen werden.
Wie der Vorgang des Data Profiling zur Identifizierung von möglichen Qualitätsproblemen führt,
wird im Folgenden anhand einiger Beispiele erläutert.
Beispiel 1
Tabelle 5.1 zeigt die Statistik eines Attributs, für welches die Eindeutigkeitseigen-
schaft gilt. Das Abweichen der beiden Werte voneinander zeigt, dass Attributwerte mehrmals vorkommen und demnach die Eindeutigkeitseigenschaft verletzt ist.
Anzahl Zeilen
Anzahl verschiedener Werte
32 056
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 Häufigkeiten aufgeführt. Das dreifache Vorkommen des Wertes S“ lässt auf ungültige
”
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.
Attribut
GESCHLECHT
GESCHLECHT
GESCHLECHT
GESCHLECHT
Inhalt
M
W
S
NULL
45
Anzahl Vorkommen
4 657
4 456
3
10
Attribut
GESCHLECHT
GESCHLECHT
Inhalt der Quelle 1 Inhalt der Quelle 2
M
M
W
F
Beispiel 3
In Tabelle 5.3 sind zu zwei verschiedenen Quellen jeweils alle in einem Attribut GE-
SCHLECHT vorkommenden Werte aufgeführt. Die unterschiedlichen Werte in den beiden Quellen, deuten auf eine uneinheitliche Repräsentation der Daten hin.
Bei den bisher erläuterten Analysen werden die einzelnen Attribute immer isoliert voneinander
betrachtet. Aufgrund von applikationsspezifischen Geschäftsregeln existieren häufig aber auch
Abhängigkeiten zwischen Attributen, die sich sowohl auf mehrere Attribute eines Tupels als auch
auf Attribute mehrerer inhaltlich zusammenhängender Tupel erstrecken können. Aus diesem Grund
werden auf Basis der geltenden Geschäftsregeln Integritätsbedingungen definiert, anhand derer
fehlerhafte Daten erkannt werden können (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 können,
die nicht ohne weiteres aus Geschäftsregeln abgeleitet werden können. Die dabei gewonnenen
Informationen über die Daten können zur Erkennung und Korrektur von fehlerhaften Daten verwendet werden.
Datenqualitätsprobleme, die aus Schema- oder Datenkonflikten resultieren, geben Aufschluss über
die zur Datenintegration notwendigen Datentransformationen. In diesem Zusammenhang müssen
die Quelldaten auch auf redundante Informationen hin untersucht werden. Dabei werden Attribute
in den Quelldaten ermittelt, die möglicherweise gleiche Informationen beinhalten und somit bei
der Zusammenführung der Quelldaten entfernt werden können.
5.5.2 Definition des Zielschemas
Unter Berücksichtigung der in der Datenanalyse gewonnenen Informationen über die Daten der
Quellsysteme und der dokumentierten Anforderungen wird ein normalisiertes Datenmodell erstellt, welches in der Lage ist alle zu integrierenden Daten aufzunehmen. Eine aufwändige Sche-
46
maintegration, bei der die lokalen Schemata aus den Quellsystemen in ein einheitliches Schema
überführt werden und etwaige strukturelle Konflikte beseitigt werden, erübrigt sich in diesem Anwendungsfall, da die Datenhaltungssysteme der Quellsysteme auf Textdateien basieren und daher
keine komplexen Schemata besitzen. Auf die Probleme, die mit einer Schemaintegration verbunden sein können, sowie deren Lösungsansätze wird daher nicht weiter eingegangen. Die Anforderungen, die bei einer Schemaintegration an das Zielschema gestellt werden, lassen sich allerdings
auf den vorliegenden Anwendungsfall übertragen und entsprechend anpassen. Die Anforderungen
sind im Folgenden aufgeführt:
• Die in den ursprünglichen Quelldateien enthaltenen Informationen sollen vollständig übernommen werden (Vollständigkeit)
• Im Zielschema sollen keine redundanten Strukturen vorkommen (Minimalität)
• Das Zielschema soll verständlich sein (Verständlichkeit)
• Die im Zielschema enthaltenen Informationen müssen äquivalent 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
übertragen und in die Importtabellen eines vom Zielschema abgegrenzten Datenbeschaffungsbereichs importiert. Die Attribute der Importtabellen ergeben sich aus der Analyse der Quellsysteme
und nehmen die Daten auf, die für die Integration der Daten in das Zielschema benötigt werden.
Beim Importvorgang werden die Daten in der Regel unverändert übernommen und gegebenenfalls
archiviert, um über die Möglichkeit einer Wiederherstellung der Originaldaten zu verfügen.
In der anschließenden Transformationsphase werden die notwendigen Transformationen und Bereinigungsschritte durchgeführt. Hierzu müssen Regeln für die notwendigen Datentransformationen bezüglich Struktur und Repräsentation definiert und geeignete Methoden zur Datenbereinigung gewählt werden. Außerdem muss ein Prozess definiert werden, der die zeitliche Abfolge zur
Durchführung der notwendigen Transformationen und Bereinigungsschritte festlegt. Eine Vorgabe, in welcher Reihenfolge bestimmte Transformations- und Bereinigungsschritte durchgeführt
werden sollten, existiert nicht. Sinnvollerweise erfolgt anfangs eine Überprüfung der Daten im
Hinblick auf die syntaktische Korrektheit, da das Erfüllen dieses Kriteriums unumgänglich für die
weitergehende Datenbereinigung ist. Die anschließende Behandlung der einzelnen semantischen
Fehler sollte möglichst in Reihenfolge zunehmender Komplexität erfolgen. Die Transformation
und Bereinigung der Daten erfolgt gewöhnlich in einem ebenfalls vom Zielschema abgegrenzten Transformationsbereich (Staging Area), der aus verschiedenen Zwischentabellen besteht. Auf
47
diese Weise kann die Aufbereitung der Daten durchgeführt werden, ohne dass die Zieltabellen davon beeinträchtigt werden. Somit ist gewährleistet, dass in den Zieltabellen immer nur vollständig
konsolidierte Daten vorliegen. Nach Durchlaufen der Transformationsphase liegen im Transformationsbereich die Quelldaten in einer Form vor, wie sie in das Zielschema übernommen werden
können.
In der Ladephase werden die bereinigten Daten schließlich in das Zielsystem übertragen.
Kapitel 6
Datenkonsolidierung
In diesem Kapitel wird die in Kapitel 5 beschriebene Vorgehensweise zur Datenkonsolidierung auf
den vorliegenden Anwendungsfall angewendet. Im folgenden Abschnitt wird zunächst eine Analyse der einzelnen Quellsysteme durchgeführt (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 Durchführung der Datenanalyse wurden vorhandene Prozessdaten aus den bestehenden Datenhaltungssystemen in Tabellen einer Oracle-Datenbank importiert. Damit war es möglich, mittels der Abfragesprache SQL einzelne Datenabfragen effizient durchzuführen, um sich ein Bild
über die vorhandenen Daten und Qualitätsprobleme zu machen. In den folgenden Abschnitten werden die Metadaten sowie weitere Integritätsbedingungen der einzelnen Quellsysteme aufgeführt,
außerdem werden die Single Source-Probleme der Quellsysteme beschrieben. Syntaktisch falsche
oder fehlende Werte können in fast allen Quellsystemen vorkommen. Erfolgt am Operationsstand
OP090 ein Austausch einer Komponente aus der Wellenvormontage, können der Ersatzkomponente keine Schraub- und Presskraftdatensätze zugeordnet werden, da beim Austausch die virtuelle
Kennung der Ersatzkomponente nicht erfasst wird. Dieser Fall führt demnach zum Verlust von
Schraub- und Presskraftdatensätzen. Die eben genannten Qualitätsprobleme werden in den folgenden 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 Tabelle 6.1 dargestellt. Die Getriebe-Seriennumner besteht aus 13 ASCII-Zeichen und hat folgenden
48
KAPITEL 6. DATENKONSOLIDIERUNG
49
Aufbau:
Stelle
Bedeutung
1-3
Kürzel für das Werk (R-- = Rüsselsheim)
4+5
Produktionsjahr (verfügt das Getriebe über eine SAAB-Kunden-Seriennummer, wird
6-11
die Angabe für das Produktionsjahr auf 00“ gesetzt)
”
fortlaufende Nummer
12+13
zweistelliger Alpha-Code, der den Getriebetyp angibt
Da die Zusammensetzungen der Kunden-Seriennummern für diese Arbeit nicht relevant sind, wird
auf diese nicht weiter eingegangen.
Feldname
Datentyp
Wertebereich
(Getriebe-
Text
ID FIAT
(FIAT-KundenSeriennummer)
Text
ID SAAB
(SAAB-KundenSeriennummer)
Text
TIMESTAMP (Zeitpunkt der
Erfassung)
V ID1 bis V ID6 (Virtuelle Kennungen der Stationen
ST040, ST060, ST070, ST080,
ST110, ST120)
Datum
wird durch den regulären Ausdruck R–[0-9]8[A-Z]2 beschrieben
wird durch den regulären
Ausdruck [0-9]2-[0-9]1-[09]3-[0-9]7 beschrieben
wird
durch
den
regulären
Ausdruck
FM6[09]1[4,5,B]1[A-Z]5[09]3 beschrieben
Format: dd.MM.yyyy hh:mm:ss
Text
achtstellige Zeichenkette
ID OPEL
Seriennummer)
Min./Max.
Länge
13 / 13
16 / 16
13 / 13
8/8
Tabelle 6.1: Metadaten der Kombinationsdaten
Weitere Integritätsbedingungen
• 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
50
Single Source-Probleme
Aufgrund von Erfassungsfehlern durch die Software an der Station ST140 weisen die Kombinationsdaten relativ viele fehlende oder abgeschnittene Werte in allen Feldern mit Ausnahme des
Feldes TIMESTAMP auf. In einigen Zeiträumen sind 10% der Datensätze fehlerhaft. Das Fehlen eines Wertes im Feld ID OPEL tritt offensichtlich auf, wenn ein Getriebe wiederholt in die
Station ST140 eingeschleust wird, da das Einfügen eines Datensatzes mit einer bereits existenten Getriebe-Seriennummer dazu führt, dass der Datensatz zwar eingefügt wird, aber das Feld
ID OPEL leer bleibt. Darüber hinaus führt 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 Einschleusung verwendet, weisen die Datensätze 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 unterscheiden, sind die zu einer einzelnen Pressoperation erfassten Datenfelder in allen Quellsystemen identisch. Aus diesem Grund werden in diesem Abschnitt die Presskraftdaten aller Quellsysteme gemeinsam behandelt. In Tabelle 6.2 sind die Metadaten der Presskraftdaten aufgeführt. Da die
Felder in den DFQ-Dateien lediglich über ihre Schlüssel identifiziert werden, sind zur besseren
Lesbarkeit zusätzlich frei vergebene Feldnamen angegeben, die später teilweise auch bei der Definition des Zielschemas verwendet werden.
Das Feld PART NUMBER beinhaltet die Seriennummer des bearbeiteten Teils. Stammt der Datensatz von einer Montage-Station aus der Vormontage, so ist die Seriennummer die achtstellige
virtuelle Kennung, ansonsten die 13-stellige Getriebe-Seriennummer. Das Feld ATTRIBUTE speichert einen Fehlercode zwischen 0 und 255. Der Wert 0“ bedeutet, dass die Operation sowie die
”
Messung erfolgreich waren. Die gültigen Werte für die Felder STATION und SPINDLE sowie deren gültige Wertekombination ergeben sich aus den gestellten Anforderungen (vgl. Abschnitt 3.2).
An der fünften Pressspindel der Station ST110 sowie an allen Pressspindeln der Station ST140
wird jedes Teil zweimal bearbeitet. Hieraus ergeben sich der Wertebereich für das Feld STEP sowie die gültigen Wertekombinationen der Felder STATION, SPINDLE und STEP. Die Werte der
Felder MEASUREMENT VALUE DIM1 (Einpresstiefe) und MEASUREMENT VALUE DIM2
(Einpresskraft) hängen von den Grenzwerteinstellungen an den Montage-Stationen ab, die in
den Feldern LOWER LIMIT DIM1 (Unterer Grenzwert für Einpresstiefe), UPPER LIMIT DIM1
(Oberer Grenzwert für die Einpresstiefe), LOWER LIMIT DIM2 (Unterer Grenzwert für die Einpresskraft) und UPPER LIMIT DIM2 (Oberer Grenzwert für Einpresskraft) übertragen werden.
51
Feldname
Datentyp
Wertebereich
K0006 - PART NUMBER
(Teile-Seriennummer)
Text
K0002 - ATTRIBUTE (Fehlercode)
K0008 - STATION (Station)
K0007 - SPINDLE (Spindel)
ganze
Zahl
Text
ganze
Zahl
ganze
Zahl
Datum
wird durch den regulären Ausdruck R–[0-9]8[A-Z]2 beschrieben; bei Daten, die an den
Stationen ST040, ST110, ST120
erzeugt werden: achtstellige Zeichenkette
[0;255]
STEP (Schritt)
K0004 - TSTAMP (Erfassungsdatum)
K2110 - LOWER LIMIT DIM1
(Untere Grenze für Einpresstiefe)
K2111 - UPPER LIMIT DIM1
(Obere Grenze für Einpresstiefe)
(Untere Grenze für Einpresskraft)
(Obere Grenze für Einpresskraft)
K0001
MEASUREMENT VALUE DIM1
(Messwert für Einpresstiefe)
K0001
(Messwert für Einpresskraft)
040, 110, 120, 140, 160
[1;9]
[1;2]
Format: dd.MM.yyyy/hh:mm:ss
Zahl
0
Zahl
0
Zahl
Zahl
Zahl
0
Zahl
Tabelle 6.2: Metadaten der Presskraftdaten
Min./Max.
Länge
13 / 13
bzw. 8 / 8
3/3
52
Datensätze erfolgreicher Pressoperationen dürfen selbstverständlich nur Messwerte beinhalten,
die innerhalb der jeweiligen Grenzwerteinstellungen liegen. Im Laufe der Zeit ändern sich die
Grenzwerteinstellungen an den Montage-Stationen, so dass sich auch die Werteverteilungen in
den Feldern für die Einpresstiefe und die Einpresskraft ändern. Inwiefern sich die Grenzwerteinstellungen zukünftig ändern werden, lässt sich aufgrund der in der Montagelinie herrschenden
Unwägbarkeiten nicht vorhersagen.
Im Allgemeinen definiert die Abteilung Fertigungsplanung Vorgaben für die an den MontageStationen einzustellenden Grenzwerte für die Einpresskraft. Diese Vorgaben werden jedoch von
der Abteilung Getriebefertigung nicht immer eingehalten. Hierfür 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 Fertigungsqualität und gibt der Abteilung Getriebefertigung Grenzwerte für
die einzelnen Pressoperationen vor, die unverbindliche Richtwerte darstellen. Bei der Vorgabe der
Grenzwerte werden Aspekte der Schaltbarkeit, der Öldichtigkeit und der mechanischen Dauerbelastbarkeit berücksichtigt. Dies kann bedeuten, dass eine niedrigere Produktionszahl angestrebt
wird, wenn dabei gleichzeitig die Qualität des einzelnen Getriebes steigt. Vorteile dieses Vorgehens sind weniger Garantierücknahmen und geringere Ausschusskosten.
Die Abteilung Getriebefertigung dagegen hat ein Interesse an einer störungsfrei gefertigten hohen
Produktionszahl. Zur Erreichung dieses Ziels wird mit einer geringeren Präzision, also mit breiteren Toleranzbereichen produziert, was nicht im Sinne einer hohen Fertigungsqualität ist, aber
dennoch zu akzeptablen Ergebnissen führen kann.
Aufgrund von Informationen seitens der Planungsabteilung kann jedoch die Aussage getroffen
werden, dass sich voraussichtlich die eingestellten Grenzwerte für die Einpresskraft, unabhängig
von der angestrebten Fertigungspräzision, innerhalb der in Tabelle 6.3 aufgeführten Toleranzbereiche bewegen werden. Werte, die nicht innerhalb der aufgeführten Toleranzbereiche liegen, können
also als falsche Werte (z. B. durch Erfassungs- oder Übertragungsfehler verursacht) betrachtet
werden. Analysen von Beispieldaten haben allerdings ergeben, dass bei vereinzelten Spindeln der
Wert für den unteren Grenzwert für die Einpresskraft beabsichtigt im negativen Bereich liegt.
Grenzwerteinstellungen im negativen Bereich sind physikalisch unsinnig und werden lediglich
aus betriebstechnischen Gründen vorgenommen. Aus diesem Grund wird der Wertebereich für
das Feld LOWER LIMIT DIM2 (Unterer Grenzwert für die Einpresskraft) in den negativen Bereich ausgedehnt.
In welchen Bereichen sich die an den Montage-Stationen eingestellten Grenzwerte für die Einpresstiefe und damit auch die Messwerte für die Einpresstiefe bewegen werden, lässt sich aus
heutiger Sicht nicht beurteilen. Die an den Montage-Stationen eingestellten Grenzwerte für die
Einpresstiefe werden von der Abteilung Getriebefertigung bestimmt und können sich ebenfalls
im Laufe der Zeit aufgrund verschiedener betriebsbedingter Faktoren ändern. Für die Grenzwerte
der Einpresstiefe existieren auch keine Vorgaben seitens der Abteilung Fertigungsplanung, da die
Station
Spindel
ST040
ST110
ST110
ST110
ST110
ST110
ST120
ST120
ST120
ST120
ST120
ST120
1
1
2
3
4
5
1
2
3
4
5
6
Toleranzbereich
Anpresskraft(kN)
]0;15]
]0;8]
]0;8]
]0;8]
]0;8]
]0;8]
]0;8]
]0;8]
]0;8]
]0;8]
]0;10]
]0;10]
53
Station
Spindel
ST120
ST120
ST120
ST140
ST140
ST140
ST140
ST160
ST160
ST160
ST160
7
8
9
1
2
3
4
1
2
3
4
Toleranzbereich
Anpresskraft(kN)
]0;10]
]0;10]
]0;8]
]0;10]
]0;10]
]0;10]
]0;10]
]0;15]
]0;10]
]0;10]
]0;10]
Tabelle 6.3: Toleranzbereiche für Pressoperationen
Werte für die Einpresstiefe keine hohe Relevanz haben. Entscheidend ist, dass bei einer Operation
die angestrebte Einpresskraft erreicht wird, um die ausreichende Festigkeit der Pressverbindung
zu gewährleisten. Aufgrund der genannten Unwägbarkeiten in der Montagelinie lassen sich also
anhand von Beispieldaten keine Aussagen über die Werteverteilung in den genannten Feldern sowie über die Beziehung zwischen den Feldern für die Einpresstiefe und die Einpresskraft treffen.
Aus diesem Grund soll auf weitere statistische Analysen der Presskraftdaten verzichtet werden.
1. Alle Felder sind Pflichtfelder.
2. Für die Kombination der Felder (PART NUMBER, STATION, SPINDLE, STEP) gilt die
Eindeutigkeitseigenschaft.
3. Der Messwert für die Einpresstiefe liegt zwischen dem unteren und dem oberen Grenzwert
für die Einpresstiefe
LOWER LIMIT DIM1 MEASURING VALUE DIM1 UPPER LIMIT DIM1
4. Der Messwert für die Einpresskraft liegt zwischen dem unteren und dem oberen Grenzwert
für die Einpresskraft
Wird bei einem Getriebe eine Pressoperation wiederholt, so wird die Eindeutigkeitseigenschaft
der Feldkombination (PART NUMBER, STATION, SPINDLE, STEP) verletzt.
54
Station
Spindel
Toleranzbereich
Drehwinkel (°)
Sollwert Drehmoment (Nm)
ST040
ST040
ST110
ST110
ST120
ST140
1
2
1
2
1
1
[45;105]
[45;60]
-
60
30
20
10
10
45
Toleranzbereich
Drehmoment
(Nm)
[30;150]
[20;75]
[18;22]
[8;12]
[8;12]
[38;52]
Tabelle 6.4: Sollwerte und Toleranzbereiche für Schrauboperationen
Semantisch falsche Messwerte in Form von Ausreißern, die durch Fehlmessungen verursacht werden, 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, Datenübertragung 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 Quellsysteme in einem gemeinsamen Abschnitt behandelt. In Tabelle 6.5 sind die Metadaten der Schraubkraftdaten aufgeführt. Auch hier sind zur besseren Lesbarkeit zusätzlich frei vergebene Feldnamen
angegeben.
Die Wertebereiche der Felder PART NUMBER und ATTRIBUTE sind identisch mit denen der
gleichnamigen Felder der Presskraftdaten. Die gültigen Werte für die Felder SPINDLE und STATION sowie deren gültige Wertekombinationen ergeben sich bei den Schraubkraftdaten ebenfalls
aus den gestellten Anforderungen (vgl. Abschnitt 3.2). Wie bei den Pressvorrichtungen können
sich im Laufe der Zeit die Grenzwerteinstellungen an den Schraubvorrichtungen und damit auch
die Wertebereiche der Felder für den Drehwinkel und das Drehmoment ändern. Präzisere Aussagen über die Eigenschaften der Felder MEASUREMENT VALUE DIM2 (Drehmoment), LOWER LIMIT DIM2 (Unterer Grenzwert für das Drehmoment) und UPPER LIMIT DIM2 (Oberer
Grenzwert für das Drehmoment) lassen sich aus den Vorgaben für die Sollwerte seitens der Abteilung Fertigungsplanung, die in Tabelle 6.4 aufgeführt sind, ableiten. Die eingesetzten Schrauber
sind sehr präzise und erreichen in der Regel den Sollwert für das Drehmoment mit einer Abweichung von +/- 0,5 Nm. Stärker abweichende Drehmomente, die jedoch innerhalb der aufgeführten
Toleranzbereiche liegen, können trotzdem zu akzeptablen Ergebnissen führen. Die Grenzwerteinstellungen an den Montage-Stationen werden von der Abteilung Getriebefertigung vorgenom-
55
men und können sich im Lauf der Zeit ändern. Bei der Bemessung der Grenzwerte steht in erster
Linie ein reibungsloser Montageprozess im Vordergrund, dabei werden unter Umständen auch
Faktoren wie z. B. der aktuell verwendete Schraubentyp oder der aktuell montierte Getriebetyp
berücksichtigt. Voraussichtlich werden sich die eingestellten Grenzwerte jedoch innerhalb der in
Tabelle 6.4 aufgeführten Toleranzbereiche bewegen. Wie bei den Presskraftdaten können also Werte, die nicht innerhalb der angegebenen Toleranzbereiche liegen, als falsche Werte betrachtet werden.
In welchen Bereichen sich die an den Montage-Stationen eingestellten Grenzwerte und damit
auch die Messwerte für den Drehwinkel bewegen werden, lässt sich aus heutiger Sicht nur für
die Schraubspindeln der Station ST040 beurteilen (vgl. Tabelle 6.4). Für die Spindeln der übrigen
Stationen existieren auch keine Vorgaben für den Drehwinkel seitens der Abteilung Fertigungsplanung, da bei diesen Spindeln die Zahl der ausgeführten Umdrehungen keine Relevanz hat.
Entscheidend ist lediglich, dass das geforderte Drehmoment erreicht wird, um die notwendige Festigkeit der Schraubenverbindung zu gewährleisten.
Wie bei den Presskraftdaten soll auf weitere statistische Analysen der Schraubkraftdaten verzichtet
werden.
1. Alle Felder sind Pflichtfelder.
2. Für die Kombination der Felder (PART NUMBER, STATION, SPINDLE) gilt die Eindeutigkeitseigenschaft.
3. Der Messwert für Drehwinkel liegt zwischen dem unteren und dem oberen Grenzwert für
den Drehwinkel
4. Der Messwert für Drehmoment liegt zwischen dem unteren und dem oberen Grenzwert für
das Drehmoment
Wird bei einem Getriebe eine Schrauboperation wiederholt, so wird die Eindeutigkeitseigenschaft
der Feldkombination (PART NUMBER, STATION, SPINDLE) verletzt.
Es können ganze Schraubkraftdatensätze fehlen, wenn aufgrund eines Ausfalls einer Schraubspindel die entsprechenden Verschraubungen mithilfe eines Handschraubers durchgeführt werden.
Auch bei Schrauboperationen werden semantisch falsche Messwerte in Form von Ausreißern von
dem jeweiligen Messsystem erkannt.
56
Feldname
Datentyp
Wertebereich
K0006 - PART NUMBER
(Teile-Seriennummer)
Text
K0002 - ATTRIBUTE (Fehlercode)
K0008 - STATION (Station)
K0007 - SPINDLE (Spindel)
ganze
Zahl
Text
ganze
Zahl
Datum
wird durch den regulären Ausdruck R–[0-9]8[A-Z]2 beschrieben; bei Daten, die an den
Stationen ST040, ST110, ST120
erzeugt werden: achtstellige Zeichenkette
[0;255]
K0004 - TSTAMP (Erfassungsdatum)
(Untere Grenze für Drehwinkel)
(Obere Grenze für Drehwinkel)
(Untere Grenze für Drehmoment)
(Obere Grenze für Drehmoment)
K0001
(Messwert für Drehwinkel)
K0001
(Messwert für Drehmoment)
040, 110, 120, 140
[1;2]
Format: dd.MM.yyyy/hh:mm:ss
Zahl
Zahl
Zahl
Zahl
Zahl
Zahl
Tabelle 6.5: Metadaten der Schraubkraftdaten
Min./Max.
Länge
13 / 13
bzw. 8 / 8
3/3
Feldname
OPEL ID
Seriennummer)
(Getriebe-
SHIM CLASS (Shim-Klasse)
SHAFT (Art der Komponente)
TSTAMP (Zeitpunkt der Erfassung)
57
Datentyp
Wertebereich
Text
[1,25]
ganze
Zahl
Text
Datum
HWO,
HWU, AWE, DIF,
(HWO = Hauptwelle oben,
HWU = Hauptwelle unten,
AWE = Antriebswelle, DIF =
Differentialgehäuse)
Min./Max.
Länge
13 / 13
3/3
Tabelle 6.6: Metadaten der Shim-Daten
6.1.4 Shim-Daten
Die Metadaten der Shim-Daten sind in Tabelle 6.6 aufgeführt. Das Feld OPEL ID beinhaltet die
13-stellige Getriebe-Seriennummer. Das Feld SHIM CLASS beinhaltet nicht die absolute Angabe
für die Shim-Größe, sondern einen Wert zwischen 1 und 25. Jeder Wert repräsentiert dabei eine
Shim-Größe (Shim-Klasse). Der Wertebereich des Feldes SHAFT setzt sich aus vier dreistelligen
Kürzeln zusammen, die jeweils eine Komponentenart repräsentieren.
• Für die Kombination der Felder (OPEL ID, SHAFT) gilt die Eindeutigkeitseigenschaft.
• Alle Felder sind Pflichtfelder.
• Das Feld OPEL ID ist ein Fremdschlüssel, der die Kombinationsdaten referenziert.
Die Eindeutigkeitseigenschaft der Feldkombination (OPEL ID, SHAFT) wird verletzt, wenn ein
Getriebe die Station ST150 wiederholt durchläuft.
6.1.5 Ausschleusungsdaten
Die Metadaten der Ausschleusungsdaten sind in Tabelle 6.7 aufgeführt.
Feldname
OPEL ID
Seriennummer)
(Getriebe-
TSTAMP (Zeitpunkt der Ausschleusung)
58
Datentyp
Wertebereich
Text
Datum
Min./Max.
Länge
13 / 13
Tabelle 6.7: Metadaten der Ausschleusungsdaten
• Für das Feld OPEL ID gilt die Eindeutigkeitseigenschaft.
• Beide Felder sind Pflichtfelder.
• Das Feld OPEL ID ist ein Fremdschlüssel, der die Kombinationsdaten referenziert.
Die Eindeutigkeitseigenschaft des Feldes OPEL ID wird verletzt, wenn ein Getriebe die Station
ST300 wiederholt durchläuft.
6.1.6 Beziehungen zwischen den Quellen und Multi Source-Probleme
Fremdschlüsselbeziehungen zwischen den Daten der einzelnen Quellsysteme wurden bereits beschrieben.
Der Ablauf des Montageprozesses, also die Reihenfolge der durchgeführten Operationen, ist statisch. Aus diesem Grund müssen die Zeitstempel der einzelnen Datensätze bezüglich eines Getriebes zeitchronologisch in der Reihenfolge liegen, wie die entsprechenden Operationen in der
Montagelinie durchgeführt werden. Aufgrund einer nicht funktionierenden Synchronisierung der
Zeiteinstellungen an den Montage-Stationen kann es allerdings zu widersprüchlichen Zeitangaben
kommen. Infolge von Aus- und Einschleusungen können sich die Reihenfolgen der Paletten in
der Montagelinie ändern. Eine Operation kann nur durchgeführt werden, wenn alle ihre vorangegangenen Operationen erfolgreich durchgeführt wurden. Wird eine Operation wiederholt, müssen
zwangsweise auch alle nachfolgenden Operationen wiederholt werden, was zur Folge hat, dass die
bereits erfassten Messwerte der nachfolgenden Operationen ungültig 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 Einflüsse zwischen
Operationen, die dasselbe Getriebe bearbeiten, bekannt sind. Demnach existieren, abgesehen von
59
den Beziehungen bezüglich der Fremdschlüssel und der Zeitstempel, keinerlei Abhängigkeiten
zwischen den einzelnen Datensätzen, aus denen weitere Integritätsbedingungen abgeleitet werden
können.
Aufgrund der standardisierten Speicherung der Schraub- und Presskraftdaten existieren keine wesentlichen Multi Source-Probleme. Die erfassten Merkmale bei einer Operation sowie die zu deren Speicherung verwendete Datenrepräsentation, sind bei allen Quellsystemen identisch. In allen
DFQ-Dateien werden dieselben Datumsformate sowie bei Messwerten und Grenzwerteinstellungen dieselben Messeinheiten verwendet. Es wird lediglich in den DFQ-Dateien ein anderes Datumsformat verwendet als in den Dateien der übrigen Quellsysteme. Außerdem ist die Präzision
in den Feldern für die Grenzwerte und die tatsächlich gemessenen Werte bei den Schraub- und
Presskraftdaten deutlich höher als jene, die in den Anforderungen definiert wurde. Des Weiteren
existieren keine Datenüberlappungen. Wenn man von den Daten aus der Wellen- und Gehäusevormontage absieht, ist das einander Zuordnen aller Datensätze einer Getriebe-Entität problemlos
möglich, da die Getriebe-Seriennummer als globaler Schlüssel 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. Abbildung 6.1 zeigt eine Gesamtübersicht der Tabellen ohne die Fehlertabellen.
Die Tabelle TRANSMISSION
Jedes montierte Getriebe wird mit seiner Getriebe-Seriennummer in der Tabelle TRANSMISSION (vgl. Tabelle 6.8) erfasst. Die Spalte OPEL ID speichert die Getriebe-Seriennummer und
dient als Primärschlüssel. Wird das Getriebe für die Kunden Fiat oder Saab montiert, so wird die
entsprechende Kunden-Seriennummer in die Spalte CUSTOMER ID geschrieben. Die Spalte DATE 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 Einfügezeitpunkt
des Datensatzes.
Die Tabelle STATION
Diese Tabelle (vgl. Tabelle 6.9) speichert alle qualitätsrelevanten Montage-Stationen. Die Spalte STATION ID stellt den Primärschlüssel der Tabelle dar. Die Spalten STATION NAME, INVENTORY NO und MANUFACTURER dienen zur Erfassung weiterer optionaler Angaben wie
Beschreibung, Inventarnummer und Hersteller der Montage-Station zur Anzeige im Frontend.
60
Zieltabellen
SCREWING_OPERATION
PRESSING_OPERATION
PK
FK1
PK
STATION
OP_ID
SPINDLE
STEP
LOWER_FORCE_TEST
UPPER_FORCE_TEST
STATION_ID
PK
STATION_ID
STATION_NAME
INVENTORY_NO
MANUFACTURER
FK1
OP_ID
SPINDLE
LOWER_TORQUE_TEST
UPPER_TORQUE_TEST
STATION_ID
LOWER_ANGLE_TEST
UPPER_ANGLE_TEST
PRESSING
PK,FK1
PK,FK2
OP_ID
OPEL_ID
FK3
LIMIT_ID
FORCE
DISTANCE
TSTAMP
SCREWING
TRANSMISSION
PK
OPEL_ID
OP_ID
FK1
LIMIT_ID
ANGLE
TORQUE
TSTAMP
OPEL_ID
CUSTOMER_ID
DATE_EXIT
DATE_INSERT
LIMIT_PRESSING
PK
PK,FK3
PK,FK2
LIMIT_SCREWING
SHIM
LIMIT_ID
PK
PK,FK1
PK
LOWER_LIMIT_DISTANCE
UPPER_LIMIT_DISTANCE
LOWER_LIMIT_FORCE
UPPER_LIMIT_FORCE
OPEL_ID
SHAFT
SHIM_CLASS
TSTAMP
LIMIT_ID
LOWER_LIMIT_ANGLE
UPPER_LIMIT_ANGLE
LOWER_LIMIT_TORQUE
UPPER_LIMIT_TORQUE
Importtabellen
IMPORT_MEASUREMENT
IMPORT_COMBINATION
PK
DATE_ST140
OPEL_ID
FIAT_ID
SAAB_ID
VID_ST040
VID_ST110
VID_ST120
COMBINATION
PK
PK
OPEL_ID
STATION_ID
PK
PK
PK
PK
PK
PART_NUMBER
SPINDLE
STATION
STEP
TYPE
SYSTEM_PARAM
PK
ATTRIBUTE
VALUE
ATTRIBUTE
LOWER_LIMIT_DIM1
LOWER_LIMIT_DIM2
MEASURING_VALUE_DIM1
MEASURING_VALUE_DIM2
TSTAMP
UPPER_LIMIT_DIM1
UPPER_LIMIT_DIM2
DATE_INSERT
VIRTUAL_ID
DATE_ST140
DATE_INSERT
Abbildung 6.1: Logisches Datenbankmodell (ohne Fehlertabellen)
Feldname
OPEL ID
Datentyp
CHAR(13)
CUSTOMER ID
VARCHAR2(16)
DATE INSERT
DATE EXIT
DATE
DATE
61
Beschreibung
GetriebeSeriennummer
KundenSeriennummer
Einfügedatum
Zeitpunkt der Ausschleusung
Beispiel
R--04123456MH
M68102P0010
07.01.04 12:13:46
06.01.04 19:17:56
Tabelle 6.8: Die Tabelle TRANSMISSION
Feldname
STATION ID
STATION NAME
INVENTORY NO
MANUFACTURER
Datentyp
CHAR(3)
VARCHAR2(20)
VARCHAR2(6)
VARCHAR2(20)
Beschreibung
Stationsnummer
Stationsname
Inventarnummer
Herstellername
Beispiel
140
Station 140
745552
LSW
Tabelle 6.9: Die Tabelle STATION
Die Tabelle SCREWING OPERATION
Jeder Eintrag in der Tabelle SCREWING OPERATION (vgl. Tabelle 6.10) repräsentiert eine qualitätsrelevante Schrauboperation in der Montagelinie. Die Spalte STATION ID stellt einen Fremdschlüssel dar und referenziert auf die gleichnamige Spalte der Tabelle STATION, so dass jeder Schrauboperation die Station zugeordnet wird, an der die Operation durchgeführt wird. Die
Spalte SPINDLE speichert die Spindelnummer. Die Spalte OP ID stellt einen künstlich erzeugten Primärschlüssel dar und speichert Werte, die durch die Kombination der Werte in den Spalten STATION ID und SPINDLE erzeugt werden. In den Spalten LOWER ANGLE TEST, UPPER ANGLE TEST, LOWER TORQUE TEST und UPPER TORQUE TEST werden die in Tabelle 6.4 aufgeführten Toleranzbereiche für 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) repräsentiert eine qualitätsrelevante Pressoperation in der Montagelinie. Auch in dieser Tabelle stellt die Spalte STATION ID einen Fremdschlüssel dar. Die Spalten SPINDLE und STEP speichern die Spindel- und
Schrittnummer. Die Spalte OP ID stellt einen künstlich erzeugten Primärschlüssel dar und speichert 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-
Feldname
OP ID
Datentyp
CHAR(5)
STATION ID
SPINDLE
LOWER ANGLE TEST
UPPER ANGLE TEST
LOWER TORQUE TEST
UPPER TORQUE TEST
CHAR(3)
NUMBER(2)
NUMBER(6,2)
NUMBER(6,2)
NUMBER(6,2)
NUMBER(6,2)
62
Beschreibung
Künstlich
erzeugter
Primärschlüssel
Stationsnummer
Spindelnummer
Unterer Prüfwinkel
Oberer Prüfwinkel
Unteres Prüfmoment
Oberes Prüfmoment
Beispiel
14002
140
2
40.00
120.00
2.00
14.00
Tabelle 6.10: Die Tabelle SCREWING OPERATION
Feldname
OP ID
Datentyp
CHAR(7)
STATION ID
SPINDLE
STEP
LOWER FORCE TEST
UPPER FORCE TEST
CHAR(3)
NUMBER(2)
NUMBER(2)
NUMBER(4,2)
NUMBER(4,2)
Beschreibung
Künstlich
erzeugter
Primärschlüssel
Stationsnummer
Spindelnummer
Schrittnummer
Untere Prüfkraft
Obere Prüfkraft
Beispiel
1400201
140
2
1
0.1
4.5
Tabelle 6.11: Die Tabelle PRESSING OPERATION
den die in Tabelle 6.3 aufgeführten Toleranzbereiche für die Einpresskraft gespeichert. Sie werden 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 Montagelinie vorkommenden Grenzwerteinstellungen für Schrauboperationen. Dabei handelt es sich um die
Grenzwerteinstellungen, die an den Montage-Stationen eingestellt werden und mit den Messwerten zusammen übertragen werden. Die Spalten LOWER LIMIT TORQUE und LOWER LIMIT ANGLE repräsentieren die unteren Grenzwerte für Drehmoment und Drehwinkel und die Spalten
UPPER LIMIT TORQUE und UPPER LIMIT ANGLE die oberen Grenzwerte für Drehmoment
und Drehwinkel. Die Spalte LIMIT ID stellt einen künstlich generierten Primärschlüssel dar.
Diese Tabelle ist durch eine Normalisierung der Tabelle SCREWING entstanden, der ursprünglich
die Spalten für die Grenzwerteinstellungen angehörten. Die Normalisierung wurde durchgeführt,
um eine große Redundanz in der Tabelle SCREWING zu vermeiden. Grenzwerteinstellungen an
den Montage-Stationen können über Wochen hinweg unverändert bleiben, so dass bei einer nichtnormalisierten Tabelle SCREWING einige tausend Datensätze exakt die selbe Wertebelegung für
die Grenzwerteinstellungen besitzen würden.
Feldname
LIMIT ID
Datentyp
NUMBER
LOWER LIMIT ANGLE
NUMBER(6,2)
UPPER LIMIT ANGLE
NUMBER(6,2)
LOWER LIMIT TORQUE
NUMBER(6,2)
UPPER LIMIT TORQUE
NUMBER(6,2)
63
Beschreibung
Künstlich
generierter
Primärschlüssel
Unterer Grenzwert für Drehwinkel
Oberer Grenzwert für Drehwinkel
Unterer Grenzwert für Drehmoment
Oberer Grenzwert für Drehmoment
Beispiel
12
40.0
150.0
8.23
12.23
Tabelle 6.12: Die Tabelle LIMIT SCREWING
Feldname
OP ID
OPEL ID
LIMIT ID
Datentyp
CHAR(5)
CHAR(13)
NUMBER
ANGLE
TORQUE
TSTAMP
NUMBER(6,2)
NUMBER(6,2)
DATE
Beschreibung
Schlüssel für Operation
Schlüssel für Grenzwerteinstellung
Gemessener Drehwinkel
Gemessenes Drehmoment
Zeitpunkt der Operation
Beispiel
14002
R--04123450MH
80
10
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 Durchführung einer Schrauboperation erfassten Messwerte für den Drehwinkel und das Drehmoment. Die erfassten Messwerte werden in den Spalten ANGLE und TORQUE gespeichert. Die Spalte TSTAMP
speichert den Zeitpunkt der Durchführung der Operation. Die Spalten OPEL ID, LIMIT ID und
OP ID stellen Fremdschlüssel dar und referenzieren auf die gleichnamigen Spalten der Tabellen
TRANSMISSION, LIMIT SCREWING und SCREWING OPERATION. Sie ordnen den Messwerten das bearbeitete Getriebe, die bei Durchführung 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 Grenzwerteinstellungen für Pressoperationen.
Feldname
LIMIT ID
Datentyp
NUMBER
LOWER LIMIT DISTANCE
NUMBER(6,2)
UPPER LIMIT DISTANCE
NUMBER(6,2)
LOWER LIMIT FORCE
NUMBER(4,2)
UPPER LIMIT FORCE
NUMBER(4,2)
64
Beschreibung
Künstlich generierter
Primärschlüssel
Unterer Grenzwert für
Einpresstiefe
Oberer Grenzwert für
Einpresstiefe
Unterer Grenzwert für
Einpresskraft
Oberer Grenzwert für
Einpresskraft
Beispiel
12
220.0
270.0
10.0
14.0
Tabelle 6.14: Die Tabelle LIMIT PRESSING
Feldname
OP ID
OPEL ID
LIMIT ID
Datentyp
CHAR(7)
CHAR(13)
NUMBER
DISTANCE
FORCE
TSTAMP
NUMBER(6,2)
NUMBER(4,2)
DATE
Beschreibung
Schlüssel für Operation
Schlüssel für Grenzwerteinstellung
Gemessene Einpresstiefe
Gemessene Einpresskraft
Beispiel
1400201
R--04123450MH
237.27
12.23
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 Durchführung einer Pressoperation erfassten Messwerte für die
Einpresstiefe und die Einpresskraft.
Die Tabelle SHIM
Die Tabelle SHIM (vgl. Tabelle 6.16) speichert die für ein Getriebe ermittelten Shim-Klassen. Die
Spalte OPEL ID dient als Fremdschlüssel und referenziert auf die gleichnamige Spalte der Tabelle
TRANSMISSION. Die Spalten SHIM CLASS und SHAFT dienen zur Speicherung der ShimKlasse sowie eines Kürzels für die Getriebekomponente, für 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 Primärschlüssel der
Tabelle SHIM.
Feldname
OPEL ID
SHIM CLASS
SHAFT
TSTAMP
Datentyp
CHAR(13)
NUMBER(2,0)
CHAR(3)
DATE
Beschreibung
Shim-Klasse
Kürzel für Komponente
65
Beispiel
R--04123456MH
12
HWO
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 übernommen werden konnten. Alle Spaltenwerte werden als Text gespeichert, um auch Datensätze erfassen zu können, die Formatfehler
in numerischen Spalten aufweisen. Die Spalte MSG dient zur Speicherung eines Hinweistextes,
weshalb der Datensatz nicht in die Zieltabellen übernommen wurde. Die Spalte DATE INSERT
speichert das Einfügedatum des Datensatzes.
Die Spalten LOWER LIMIT DIM1, UPPER LIMIT DIM1 und MEASUREMENT VALUE DIM1
speichern den unteren und den oberen Grenzwert sowie den Messwert für den Weg (Einpresstiefe/Drehwinkel). Die Spalten LOWER LIMIT DIM2, UPPER LIMIT DIM2 und MEASUREMENT VALUE DIM2 speichern den unteren und den oberen Grenzwert sowie den Messwert für
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 übernommen werden konnten. Auch in dieser Tabelle werden alle
Werte als Text gespeichert, außerdem verfügt diese Tabelle ebenfalls über die Spalten MSG und
DATE INSERT zum Erfassen eines Hinweistextes und des Einfügedatums.
Die Tabelle ERROR COMBINATION
In dieser Tabelle (vgl. Tabelle 6.19) werden alle Kombinationsdaten gespeichert, die aufgrund
fehlerhafter Daten nicht in die Zieltabellen übernommen werden konnten.
Die Tabelle SYSTEM PARAM
Diese Tabelle (vgl. Tabelle 6.20) stellt eine Hilfstabelle dar, in der Parameter abgelegt werden, die
über verschiedene Instanzen der Datenbereinigungsprozesse hinweg gesichert werden müssen. In
Feldname
PART NUMBER
ATTRIBUTE
STATION
SPINDLE
STEP
MEASURING VALUE DIM1
Datentyp
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
LOWER LIMIT DIM1
VARCHAR2(20)
UPPER LIMIT DIM1
VARCHAR2(20)
LOWER LIMIT DIM2
VARCHAR2(20)
UPPER LIMIT DIM2
VARCHAR2(20)
TSTAMP
TYPE
VARCHAR2(20)
CHAR(1)
MSG
DATE INSERT
VARCHAR2(255)
DATE
66
Beschreibung
Seriennummer
Fehlercode
Stationsnummer
Spindelnummer
Schrittnummer
Messwert
für
Einpresstiefe/Drehwinkel
Messwert
für
Einpresskraft/Drehmoment
Unterer Grenzwert für Einpresstiefe/Drehwinkel
Oberer Grenzwert für Einpresstiefe/Drehwinkel
Unterer Grenzwert für Einpresskraft/Drehmoment
Oberer Grenzwert für Einpresskraft/Drehmoment
Art des Datensatzes (0=Schraubkraftdatensatz/1=Presskraftdatensatz)
Hinweistext
Einfügedatum
Tabelle 6.17: Die Tabelle ERROR MEASUREMENT
der Spalte ATTRIBUTE wird der Parametername und in der Spalte VALUE der zugehörige 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 Repräsentation an
das gemeinsame Zielschema anzupassen. Dabei sollen Daten, die offensichtlich fehlerhaft sind
bzw. die in Abschnitt 5.1 genannten Qualitätskriterien nicht erfüllen, aussortiert werden.
Bei der Überprüfung der Quelldaten auf die Erfüllung der einzelnen Qualitätskriterien ist es sinnvoll, die Daten anfangs unter syntaktischen Gesichtspunkten zu überprüfen. Dazu können die
während der Datenanalyse ermittelten Informationen über die jeweiligen Datentypen sowie die typischen Muster der Werte verwendet werden. Während dessen erfolgt auch ein Vollständigkeitstest,
um zu prüfen, ob zu allen Feldern entsprechende Werte vorhanden sind. Der Test auf Vollständigkeit ist einfach durchzuführen, da bis auf die Kunden-Seriennummer alle Felder Pflichtfel-
Feldname
OPEL ID
SHIM CLASS
SHAFT
TSTAMP
MSG
DATE INSERT
Datentyp
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(255)
DATE
67
Beschreibung
Shim-Klasse
Komponente
Fehlermeldung
Einfügedatum
Tabelle 6.18: Die Tabelle ERROR SHIM
Feldname
OPEL ID
FIAT ID
SAAB ID
DATE ST140
VID ST040
VID ST110
VID ST120
MSG
DATE INSERT
Datentyp
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(20)
VARCHAR2(255)
DATE
Beschreibung
Zeitpunkt der Erfassung an der Station ST140
Virtuelle Kennung ST040
Hinweistext
Einfügedatum
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 Interpretationsmöglichkeiten eines nicht vorhandenen Wertes resultieren kann (vgl. Abschnitt 5.1), nicht
auf. Anhand der beiden genannten Überprüfungen können alle Datensätze, die die Kriterien der
Vollständigkeit und der Schema-Konformität verletzen, erkannt werden. Die Erfüllung der beiden
Kriterien ist Voraussetzung für die Überprüfung der semantischen Korrektheit.
Nach erfolgter Überprüfung der syntaktischen Korrektheit sollten die Quelldaten auf semantische
Korrektheit hin überprüft werden. Die Überprüfung der Werte erfolgt mithilfe des Wissens über
die Wertebereiche und die Integritätsbedingungen, welches während der Datenanalyse erworben
wurde.
Die Eindeutigkeit der Qualitätsdaten ist einfach sicherzustellen, da alle Datensätze über eine bestimmte Feldkombination eindeutig identifizierbar sind (z. B. bei Schraubkraftdatensätze anhand
der Seriennummer des bearbeiteten Teils und der Angaben für die Station und die Spindel). Eine
aufwändige Duplikateliminierung, wie sie beispielsweise bei Adressdaten erforderlich ist, entfällt
in diesem Anwendungsfall. Duplikate infolge einer mehrfachen Datenübertragung können problemlos vermieden werden. Bei Duplikaten, die durch eine wiederholte Durchführung einer Ope-
Feldname
ATTRIBUTE
VALUE
Datentyp
VARCHAR2(50)
VARCHAR2(50)
Beschreibung
Parametername
Wert
68
Beispiel
LAST COMBINATION DATE
12.12.1995 12:34:34
Tabelle 6.20: Die Tabelle SYSTEM PARAM
ration verursacht werden, soll grundsätzlich der Datensatz mit dem größeren Zeitstempel gespeichert werden. Eine Plausibilitätsüberprüfung der Zeitstempel soll nicht erfolgen, da die Zeitsynchronisierung der Montage-Stationen nicht einwandfrei funktioniert. Im Übrigen wird der Korrektheit der Zeitstempel keine hohe Priorität beigemessen, da keine Datenanalysen geplant sind,
die die Plausibilität der Zeitstempel voraussetzen würden.
Wie bereits in Abschnitt 5.1 beschrieben, kann unter dem Kriterium der Vollständigkeit auch die
Eigenschaft verstanden werden, dass alle Entitäten der Realität im Datenbestand repräsentiert sind.
Obwohl der Vollständigkeitstest, ob für ein Getriebe zu allen Operationen ein entsprechender Datensatz vorhanden ist, aufgrund des bekannten Aufbaus der Montagelinie und der damit bekannten
Anzahl der zu erwartenden Datensätze einfach zu realisieren wäre, wird auf ihn verzichtet, da dieses Kriterium laut Anforderungen nicht erfüllt werden muss.
Das Kriterium Einheitlichkeit ist durch die standardisierte Repräsentation der Schraub- und Presskraftdaten weitgehend gegeben. Es müssen lediglich Transformationen der Quelldaten bezüglich
ihrer Struktur durchgeführt werden, um sie in die normalisierte Zieldatenbank schreiben zu können.
Die Bereinigung der Datensätze beschränkt sich damit auf die Überprüfung der Eindeutigkeit,
der Vollständigkeit und der Gültigkeit der Werte mithilfe der in Abschnitt 6.1 ermittelten Integritätsbedingungen. Alle durchzuführenden Überprüfungen können mithilfe entsprechender Integritäts-Constraints in den Zieltabellen durchgeführt werden.
Bei der Definition der Datenbereinigungsprozesse wurde von dem in Abschnitt 5.5.3 beschriebenen Schema eines ETL-Prozesses abgewichen. Es existieren demnach keine strikt getrennten Phasen für Extraktion, Transformation und Laden der Daten, da die temporäre Speicherung
sämtlicher Daten in einem Transformationsbereich in diesem Anwendungsfall nicht unbedingt als
notwendig erscheint und daher unnötigen Overhead verursachen würde. Eine Speicherung von Datensätzen im Transformationsbereich ist erforderlich, wenn komplexere Abhängigkeiten zwischen
Datensätzen existieren, so dass die Bereinigung eines Datensatzes das Vorhandensein anderer Datensätze voraussetzt. Dies ist beispielsweise der Fall, wenn mehrere Datensätze zur Erkennung von
logischen Widersprüchen einander abgeglichen werden müssen. Da die Zeitstempelbeziehungen
außer Acht gelassen werden sollen, bestehen keine Abhängigkeiten, die es vor dem Ladevorgang
Feldname
OPEL ID
FIAT ID
SAAB ID
DATE ST140
VID ST040
Datentyp
VARCHAR2(25)
VARCHAR2(25)
VARCHAR2(25)
DATE
VARCHAR2(15)
VID ST110
VID ST120
VARCHAR2(15)
VARCHAR2(15)
69
Beschreibung
Virtuelle Kennung: Stirnrad/Differential
(ST040)
Virtuelle Kennung: Getriebegehäuse (ST110)
Virtuelle
Kennung:
Kupplungsgehäuse
(ST120)
Tabelle 6.21: Die Tabelle IMPORT COMBINATION
zu überprüfen gilt. Ein Teil der Quelldaten kann demnach im Arbeitsspeicher transformiert werden und direkt in die Zieltabellen geladen werden. Das temporäre Speichern der Quelldaten in
Hilfstabellen wird daher auf die Schraub- und Presskraftdaten aus der Vormontage beschränkt.
Bei diesen Quelldaten ist das temporäre Speichern unvermeidlich, da sie vor dem Ladevorgang in
die Zieltabellen aufgrund der nicht existenten Getriebe-Seriennummer mit den Kombinationsdaten kombiniert werden müssen. Darüber hinaus sollen an den Quelldaten keine Korrekturen von
falschen Werten vorgenommen werden, so dass bereits während des Einlesevorgangs der Quelldateien als fehlerhaft identifizierte Datensätze gar nicht erst in den Transformationsbereich geladen
werden müssen, sondern direkt in einen Fehler-Report geschrieben werden können.
Zur Bereinigung der eintreffenden Quelldaten sind insgesamt fünf 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 fünfte Prozess dient nicht der eigentlichen Datenbereinigung, sondern lediglich zum Löschen
nicht mehr benötigter Datensätze 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 nachfolgenden Prozess zur Zuordnung der Schraub- und Presskraftdaten aus der Vormontage zu den
70
einzelnen Getrieben verwendet werden können. Der Aufbau der Kombinationsdatei ist in Tabelle 2.1 und ein exemplarischer Auszug aus dieser in Abbildung 4.4 dargestellt.
Der Inhalt der Kombinationsdatei wird unverändert 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 Anforderungsbereich 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. Darüber hinaus erfolgt bereits beim Parsen der Datei eine syntaktische Überprüfung
der Werte in der Spalte TIMESTAMP, weil die syntaktische Korrektheit für die weitere Verarbeitung der Daten erforderlich ist. Da die Quelldatei nicht nur die Kombinationsdaten der vorangegangenen Schicht, sondern alle jemals erfassten Kombinationsdaten beinhaltet (Full-Dump),
wird vor Beendigung dieses Prozesses der Zeitstempel des jüngsten Eintrages der Tabelle IMPORT COMBINATION in die Tabelle SYSTEM PARAM (vgl. Tabelle 6.20) geschrieben. Damit
wird ein Zeiger auf den zuletzt integrierten Datensatz über die aktuelle Prozessinstanz hinweg
bis zu einer erneuten Prozessausführung festgehalten. Bei einem erneuten Start dieses Prozesses
werden dann nur die Dateieinträge in die Tabelle IMPORT COMBINATION geschrieben, deren
Zeitstempel größer sind als der Zeitstempel des in der vorangegangen Prozessinstanz zuletzt integrierten Datensatzes. Auf diese Weise wird vermieden, dass bei jeder Ausführung dieses Prozesses
der gesamte Inhalt der Quelldatei importiert werden muss. Nach dem Einlesen der Quelldatei besteht der gesamte Datenbestand der Kombinationsdaten in der Tabelle IMPORT COMBINATION
zur Verfügung, ohne dass nochmals auf die Quelldatei zugegriffen werden muss, sofern ein Zugriff
auf ältere Daten notwendig werden sollte.
Im weiteren Verlauf werden alle Datensätze aus der Tabelle IMPORT COMBINATION, die seit
der letzten Prozessausführung hinzugekommen sind und demnach bis dahin nicht integriert wurden, selektiert und wie folgt transformiert:
(OPEL ID, FIAT ID,
SAAB ID, DATE ST140,
(OPEL ID, CUSTOMER 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 gleiche Kunden-Seriennummer und einen kleineren Zeitstempel trägt. Besitzt der gefundene Ein-
71
trag eine gültige Getriebe-Seriennummer, so wird diese für die weitere Verarbeitung herangezogen. Datensätze mit nicht vorhandener Getriebe-Seriennummer und nicht vorhandener KundenSeriennummer werden verworfen und in die Tabelle ERROR COMBINATION geschrieben. Hintergrund dieser Vorgehensweise ist, dass bei einer fehlenden Getriebe-Seriennummer möglicherwiese eine erneute Einschleusung des Getriebes stattgefunden hat und bei der erneuten Erfassung der Kombinationsdaten der Wert für die Getriebe-Seriennummer verloren gegangen ist.
Verfügt der Datensatz über eine Kunden-Seriennummer, kann über diese der Datensatz der vorangegangenen Einschleusung gefunden und anhand dieses Datensatzes die zugehörige GetriebeSeriennummer ermittelt werden.
Der Datensatz (OPEL ID, CUSTOMER ID, DATE ST140) wird in die Tabelle TRANSMISSION geschrieben, wobei die ersten beiden Attribute des Datensatzes auf die gleichnamigen Spalten der Tabelle abgebildet werden. Das Attribut DATE ST140 wird dagegen auf die Spalte DATE EXIT der Tabelle abgebildet, um die genannte Spalte mit dem Erfassungsdatum der Station
ST140 vorzubelegen. Auf diese Weise steht der ungefähre Montagezeitpunkt zur Verfügung, falls
in der Montagelinie aus irgendwelchen Gründen 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 einzufügenden Datensatzes, wird auch die Spalte DATE EXIT entsprechend aktualisiert. Die Vollständigkeit wird sichergestellt, indem alle Spalten der Tabelle TRANSMISSION mit
Ausnahme der Spalte CUSTOMER ID als NOT NULL deklariert sind. Eine Plausibilitätskontrolle
der Getriebe-Seriennummer erfolgt mithilfe einer CHECK-Klausel.
Die Datensätze (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 COMBINATION geschrieben. Die Attribute OPEL ID und DATE ST140 werden dabei auf die gleichnamigen 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 Primärschlüssel,
der sich aus den Spalten OPEL ID und STATION ID zusammensetzt, sichergestellt. Ein bereits
vorhandener Datensatz mit gleichem Schlüsselwert wie der neu zu speichernde Datensatz, wird
überschrieben, sofern der neu zu speichernde Datensatz den größeren Zeitstempel der beiden Datensätze besitzt. Wird ein Fehler in einem der durch die Transformation entstandenen Datensätze
gefunden, wird der ursprüngliche Datensatz, aus dem der betroffene Datensatz bei der Transformation hervorgegangen ist, in die Tabelle ERROR COMBINATION geschrieben.
Feldname
OPEL ID
VIRTUAL ID
STATION ID
DATE ST140
DATE INSERT
Datentyp
CHAR(13)
CHAR(8)
CHAR(3)
DATE
DATE
72
Beschreibung
Virtuelle Kennung
Stationsnummer
Einfügedatum
Tabelle 6.22: Die Tabelle COMBINATION
Nach Beendigung dieses Prozesses stehen alle Kombinationsdaten der vorangegangenen Schicht
in der Tabelle COMBINATION zur Verfügung, um später die Schraub- und Presskraftdaten aus
der Vormontage den jeweiligen Getrieben zuordnen zu können. Dabei ist sichergestellt, dass die
Daten syntaktisch korrekt und vollständig sind. Außerdem beinhalten die Daten zu jedem Getriebe, 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 verarbeitet werden können 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 Werteeinträgen im Werte-
teil einer DFQ-Datei werden die Datensätze (PART NUMBER, ATTRIBUTE, STATION, SPINDLE, 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 für den zu speichernden Datensatz gewählt. 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 Operation 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
”
für das Zielsystem erforderlichen Datentypen konvertiert. Im weiteren Verlauf wird zwischen Datensätzen unterschieden, die aufgrund ihrer Herkunft (Vormontage oder Endmontage) über eine
virtuelle Kennung oder eine Getriebe-Seriennummer verfügen.
Ein Datensatz, der aus der Vormontage stammt und daher im Attribut PART NUMBER über ei-
Feldname
PART NUMBER
ATTRIBUTE
STATION
SPINDLE
STEP
Datentyp
VARCHAR2(8)
NUMBER(3)
CHAR(3)
NUMBER(2)
NUMBER(1)
NUMBER(6,2)
NUMBER(5,2)
LOWER LIMIT DIM1
NUMBER(6,2)
UPPER LIMIT DIM1
NUMBER(6,2)
LOWER LIMIT DIM2
NUMBER(5,2)
UPPER LIMIT DIM2
NUMBER(5,2)
TSTAMP
TYPE
VARCHAR2(20)
CHAR(1)
DATE INSERT
DATE
73
Beschreibung
Seriennummer
Fehlercode
Stationsnummer
Spindelnummer
Schrittnummer
Messwert
für
Einpresstiefe/Drehwinkel
Messwert
für
Einpresskraft/Drehmoment
Unterer Grenzwert für Einpresstiefe/Drehwinkel
Oberer Grenzwert für Einpresstiefe/Drehwinkel
Unterer Grenzwert für Einpresskraft/Drehmoment
Oberer Grenzwert für Einpresskraft/Drehmoment
Art des Datensatzes (0=Schraubkraftdatensatz/1=Presskraftdatensatz)
Einfügedatum
Tabelle 6.23: Die Tabelle IMPORT MEASUREMENT
ne virtuelle Kennung verfügt, wird unverändert in die Tabelle IMPORT MEASUREMENT (vgl.
Tabelle 6.23) geschrieben. Der Primärschlüssel dieser Tabelle setzt sich zusammen aus den Spalten PART NUMBER, STATION, SPINDLE, STEP und TYPE. Ein bereits vorhandener Datensatz
mit gleichem Schlüsselwert wie der neu zu speichernde Datensatz, wird überschrieben, sofern
der neu zu speichernde Datensatz den größeren Zeitstempel der beiden Datensätze besitzt. Eine
Überprüfung auf Einhaltung der definierten Wertebereiche sowie weiterer Integritätsbedingungen
erfolgt an dieser Stelle nicht.
Ein Datensatz, die aus der Endmontage stammt und daher im Attribut PART NUMBER bereits
über eine Getriebe-Seriennummer verfügt, wird direkt in die Zieltabellen geschrieben. Dazu wird
ein zu speichernder Datensatz zunächst wie folgt transformiert:
74
(PART NUMBER, ATTRIBUTE,
(MEASURING VALUE DIM1,
STATION, SPINDLE, STEP,
MEASURING VALUE DIM2,
PART NUMBER, TSTAMP),
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 UPPER 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 Tabelle SCREWING oder PRESSING geschrieben. Der Wert für das Attribut OP ID wird aus der
Wertekombination der Attribute STATION ID, SPINDLE und ggf. STEP des ursprünglichen Datensatzes ermittelt. Der Wert für das Attribut LIMIT ID entspricht dem Schlüsselwert der entsprechenden Grenzwerteinstellung in der Tabelle LIMIT PRESSING bzw. LIMIT SCREWING. Die
Attribute OP ID, TSTAMP und LIMIT ID werden beim Einfügen auf die gleichnamigen Spalten der Zieltabelle abgebildet und das Attribut PART NUMBER wird in die Spalte OPEL ID
der Zieltabelle geschrieben. Die Attribute MEASUREMENT VALUE DIM1 und MEASUREMENT VALUE DIM2 werden je nach Zieltabelle auf die Spalten DISTANCE und FORCE oder
ANGLE und TORQUE abgebildet. Alle Spalten der beiden Zieltabellen SCREWING und PRESSING sind als NOT NULL deklariert. Die Eindeutigkeit in den beiden Tabellen wird jeweils durch
den Primärschlüssel, der sich aus den Spalten OPEL ID und OP ID zusammensetzt, sichergestellt.
Ein bereits vorhandener Datensatz mit gleichem Schlüsselwert wie der neu zu speichernde Datensatz, wird überschrieben, sofern der neu zu speichernde Datensatz den größeren Zeitstempel der
beiden Datensätze besitzt.
Die Überprüfung der ermittelten Integritätsbedingungen bezüglich der Wertebereiche und der Einhaltung der Toleranzbereiche, die in den Tabellen SCREWING OPERATION und PRESSING
75
OPERATION erfasst sind (vgl. Abschnitt 6.2), erfolgen mithilfe von CHECK-Klauseln und Triggern. Bei Verletzung einer Integritätsbedingung wird der ursprüngliche 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 Einfügen des Press- bzw. Schraubkraftdatensatzes angelegt. Diese Vorgehensweise ermöglicht es auch Datensätze zu speichern, deren
Getriebe-Seriennummer nicht in der Kombinationstabelle auftaucht. Diese Vorgehensweise ist
ausdrücklich erwünscht.
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
Datensätze eines Getriebes beinhaltet die Spalte DATE EXIT schließlich einen Zeitpunkt, der dem
tatsächlichen Ausschleusungszeitpunkt zeitlich gesehen am nächsten liegt. Diese Vorgehensweise
bleibt auch dann bestehen, wenn die Station ST300 Daten sendet. Auf diese Weise können Ausfälle
bei der Datenerfassung an der Station ST300 kompensiert werden.
2. Phase
Nachdem alle neu eingetroffenen DFQ-Dateien verarbeitet wurden, werden die Schraub-
und Presskraftdatensätze aus der Vormontage mit den Kombinationsdaten kombiniert, um die
einzelnen Datensätze den einzelnen Getrieben zuzuordnen. Dazu werden die Datensätze in der
Tabelle COMBINATION mit denen in der Tabelle IMPORT MEASUREMENT kombiniert. Abbildung 6.2 zeigt den dabei verwendeten EQUI-Join. Die Datensätze aus der Vormontage, die nach
der Kombination über eine Getriebe-Seriennummer verfügen, 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 zeilenweise eingelesen, dabei wird jeder Datensatz nach erfolgter Datentypkonvertierung der Felder SHIM CLASS und TSTAMP in die Tabelle SHIM geschrieben. Alle Spalten in der Tabelle SHIM sind als NOT NULL deklariert. Zur Definition der gültigen Wertebereiche der Spalten
SHIM CLASS und SHAFT sind entsprechende CHECK-Klauseln deklariert. Die Eindeutigkeit in
der Tabelle SHIM wird durch den Primärschlüssel, der sich aus den Spalten OPEL ID und SHAFT
zusammensetzt, sichergestellt. Ein bereits vorhandener Datensatz mit gleichem Schlüsselwert wie
der neu zu speichernde Datensatz, wird überschrieben, sofern der neu zu speichernde Datensatz
den größeren Zeitstempel der beiden Datensätze besitzt. Sollte in der Tabelle TRANSMISSION
kein Datensatz mit entsprechender Getriebe-Seriennummer existieren, so wird der Datensatz von
76
SELECT
OPEL_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
FROM
COMBINATION C, IMPORT_MEASUREMENT I
WHERE
C.VIRTUAL_ID = I.PART_NUMBER
AND
STATION_ID = STATION
Abbildung 6.2: EQUI-Join zur Zuordnung der Schraub- und Presskraftdaten aus der Vormontage
zu den einzelnen Getrieben
diesem Prozess vor Einfügen des Shim-Datensatzes angelegt. Fehlerhafte Shim-Datensätze werden 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. Jedes in der Quelldatei erfasste Ausschleusungsdatum wird nach erfolgter Datentypkonvertierung
in die Spalte DATE EXIT des entsprechenden Getriebe-Datensatzes in der Tabelle TRANSMISSION eingetragen. Ein in der Spalte DATE EXIT bereits eingetragener Zeitstempel wird dabei
überschrieben, sofern der neu einzutragende Zeitstempel größer als der bestehende ist. Sollte in
der Tabelle TRANSMISSION kein Datensatz mit entsprechender Getriebe-Seriennummer existieren, 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 verhindern, werden die einzelnen Tabellen regelmäßig bereinigt. Dazu werden Datensätze, deren
Einfügezeitpunkte länger als eine bestimmte Zeitspanne zurückliegen und daher mit hoher Wahrscheinlichkeit nicht mehr benötigt werden, aus den Tabellen gelöscht. Der Einfügezeitpunkt eines
Datensatzes wird der Spalte DATE INSERT entnommen. Für jede Tabelle wird ein eigener Wert
für die Verfallszeitspanne“ definiert.
”
Kapitel 7
Implementierung
In diesem Kapitel wird auf die Implementierung der in Abschnitt 6.3 definierten Datenbereinigungsprozesse (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 Programme/Skripte auf Betriebsystemebene aufgerufen. Demnach existiert abgesehen von der Datenbank keine Kopplung mit anderen Applikationen, so dass die Applikation plattformunabhängig
ist und einfach installiert werden kann. Der Aufbau der Applikation in ihren wesentlichen Komponenten ist in Abbildung 7.1 schematisch dargestellt. Die einzelnen Datenbereinigungsprozesse
sind dabei in grauer Farbe dargestellt. Die durchgezogenen Pfeile skizzieren die verschiedenen
Datenflüsse und die gestrichelten Pfeile deuten Prozessaufrufe an.
Der Timer startet in konstanten Zeitabständen den Thread ConsolidationTask“. Dieser Thread
”
ruft schließlich nacheinander die einzelnen Datenbereinigungsprozesse auf, die für das Einlesen
der Quelldateien und das Abspeichern der Quelldaten in der Datenbank verantwortlich sind. Zugriffe auf die Datenbank durch die Datenbereinigungsprozesse erfolgen ausschließlich über eine
Datenbankabstraktionssschicht. Der Logger unterstützt das Application-Logging und der SessionBuffer ermöglicht allen anderen Komponenten einen Zugriff auf verschiedene Konfigurationseinstellungen der Applikation, die über eine Konfigurationsdatei vorgenommen werden können. Die
ausführbare 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 Methode main der Klasse qsf40.QSF40 und damit kurz nach dem Starten der Applikation erzeugt
77
KAPITEL 7. IMPLEMENTIERUNG
78
CombinationFileReader
CombinationData
LoadingTask
DFQFileReader
MeasurementLoadingTask
ShimFileReader
ShimDataLoadingTask
ExitDataFileReader
ExitDataLoadingTask
CleaningTask
Logger
Combination
Task
SessionBuffer
ConsolidationTask
Datenbankabstraktionsschicht
Tim er
Applikation QSF40
Datenbank
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.TimerTask abgeleiteten 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 Zeitabständen,
”
unabhängig davon wie lange die einzelnen Ausführungen der Datenbereinigung dauern, gestartet
wird. Der Zeitabstand zwischen zwei Ausführungen der Datenkonsolidierung sowie der Zeitpunkt
der ersten Ausführung nach dem Start der Applikation können über die bereits erwähnte Konfigurationsdatei definiert werden.
Die Datenbankabstraktionsschicht
Die Datenabstraktionsschicht wird durch die Klasse qsf40.DBConnection implementiert. Sie
kapselt ein java.sql.Connection-Objekt und sämtliche SQL-Statements, die im Rahmen
der Datenkonsolidierung zur Anwendung kommen, in entsprechenden Methoden. Darüber hinaus
ist die Klasse für das Öffnen und Schließen der Datenbankverbindung verantwortlich. Zugriffe auf
die Datenbank durch die Datenbereinigungsprozesse erfolgen ausschließlich über entsprechende
Methodenaufrufe der Datenbankabstraktionsschicht.
Der Logger
Mithilfe des Loggers können Fehlermeldungen und sonstige Meldungen seitens der Applikation protokolliert werden, um das Überwachen und Debuggen der Applikation zu erleichtern. Der
79
Logger ist mithilfe der Java Logging API (Paket java.util.logging) realisiert. Das LogLevel sowie das Verzeichnis, in dem die Log-Datei gespeichert wird, können ebenfalls über die
Konfigurationsdatei definiert werden.
Die Datei-Parser
Zum Einlesen der Quelldateien steht für 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 für 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 ParserKlasse ein Objekt der Klasse qsf40.Combination, qsf40.Shim, qsf40.ExitData oder
ein Array mit Objekten der Klasse qsf40.Measurement zurückliefert. Die ersten drei genannten Klassen kapseln jeweils alle Werte einer Zeile der entsprechenden CSV-Datei. Die Klasse
Measurement kapselt alle relevanten Werte, die zu einer Schraub- bzw. Pressoperation gespeichert werden sollen. Jedes Measurement-Objekt besitzt damit sowohl Werte der zuletzt gelesenen Zeile aus dem Werteteil als auch Werte aus dem Beschreibungsteil, der unmittelbar nach
Öffnen der DFQ-Datei komplett ausgewertet wird. Werte weiterer nicht relevanter Schlüsselfelder,
die ggf. in einer DFQ-Datei gespeichert sind, werden beim Einlesen ignoriert. Die Anzahl der
Measurement-Objekte im zurückgelieferten Array ist abhängig von der Anzahl der Qualitätsmerkmale, die bei der Bearbeitung eines Teils erfasst wurden (Anzahl Spindeln bei Schraubkraftdateien, Anzahl Schritte bei Presskraftdateien).
Der SessionBuffer
Die Klasse qsf40.SessionBuffer dient der Speicherung verschiedener Konfigurationseinstellungen der Applikation sowie einer Referenz auf das Logger-Objekt über die gesamte Laufzeit der Applikation. Bei der Implementierung der Klasse wurde das Singleton-Muster realisiert,
so dass über einen Aufruf der Methode getInstance() aus allen Komponenten der Applikation auf das Singleton-Objekt und damit auf die Konfigurationseinstellungen und den Logger
zugegriffen werden kann. Beim ersten Aufruf der Methode getInstance(), der in der Methode main der Klasse qsf40.QSF40 vor Erzeugung der Timer-Instanz erfolgt, werden die
in der Datei qsf40.properties gespeicherten Konfigurationseinstellungen eingelesen. Die
80
Konfigurationsdatei beinhaltet im Wesentlichen die Verbindungsdaten zur Datenbank, die Namen
der Eingangsverzeichnisse, das Log-Level, die Zeitspanne zwischen zwei Ausführungszeitpunkten
der Datenbereinigung sowie die Zeitspannen, nach denen Datensätze aus den jeweiligen Fehlerund Hilfstabellen gelöscht werden sollen (vgl. Abschnitt 6.3.5). Über entsprechende Methodenaufrufe können die Einstellungen abgefragt werden. Nach Einlesen der Konfigurationsdatei wird
das Logger-Objekt erzeugt und ein Verbindungstest zur Datenbank durchgeführt. Tritt dabei ein
Fehler auf, wird die Applikation vorzeitig beendet.
Die Datenbereinigungsprozesse
Für 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 Kombinationsdaten)
• qsf40.tasks.MeasurementLoadingTask (Laden und Bereinigen der Schraub- und
Presskraftdaten - 1. Phase)
• qsf40.tasks.CombinationTask (Laden und Bereinigen der Schraub- und Presskraftdaten - 2. Phase)
• qsf40.tasks.ShimDataLoadingTask (Laden und Bereinigen der Shim-Daten)
• qsf40.tasks.ExitDataLoadingTask (Laden und Bereinigen der Ausschleusungsdaten)
• qsf40.tasks.CleaningTask (Bereinigen der Fehler- und Hilfstabellen)
Jede dieser Klassen verfügt über eine Methode run(), die den entsprechenden Datenbereinigungsprozess implementiert und von dem Thread ConsolidationTask“ aufgerufen wird. Jeder
”
Bereinigungsprozess, der Quelldateien einliest, überprüft anfangs das Eingangsverzeichnis auf
neu eingetroffene Quelldateien. Jeder Datenbereinigungsprozess verfügt dabei über 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 eingelesen. Die in den Quelldateien gespeicherten Daten werden gemäß den in Abschnitt 6.3 beschriebenen Definitionen der Datenbereinigungsprozesse verarbeitet. Nach erfolgreichem Abarbeiten einer Quelldatei wird diese aus dem Eingangsverzeichnis gelöscht. Sobald alle Dateien erfolgreich
abgearbeitet und gelöscht 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
”
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 Stabilität der Applikation zu erreichen sowie Datenverluste zu vermeiden. Es wird sichergestellt, dass eine Quelldatei nur dann gelöscht wird,
wenn sie auch fehlerfrei abgearbeitet werden konnte. Bei schwerwiegenden Fehlern (z. B. NichtErreichbarkeit 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 Präsentationsframework (z. B. Struts) zur Trennung von BusinessLogik und Layout oder auf einen Application-Server verzichtet. Bei der Implementierung wurde
u. a. für 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 verwendet. 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, führt die Suche durch und zeigt nach einer erfolgreichen
Suche die Trefferliste an (vgl. Anwendungsfälle 1 und 2 in Abschnitt 3.4).
• station overview.jsp. Diese Seite zeigt, nachdem in der Trefferliste ein Getriebe
ausgewählt wurde, alle Stationen an, zu denen Qualitätsdaten des ausgewählten 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 Stationen eine Station ausgewählt wurde, alle Schraub- und Presskraftdaten bezüglich des ausgewählten Getriebes und der ausgewählten Station an (vgl. Anwendungsfall 1 in Abschnitt 3.4).
• shim data.jsp. Diese Seite zeigt die Shim-Daten eines Getriebes an. Sie wird aufgerufen, wenn auf der Seite station overview.jsp die Station ST150 ausgewählt wurde
(vgl. Anwendungsfall 1 in Abschnitt 3.4).
Kapitel 8
Tests der Applikation QSF40
In diesem Kapitel wird die Vorgehensweise bei den durchgeführten Tests der Applikation QSF40
erläutert. Da ein Test der Applikation unter Realbedingungen, also bei laufendem Montagebetrieb
nicht durchgeführt werden konnte, weil die Prozesse zur Übertragung der Daten von den MontageStationen zum Server bis zuletzt nicht eingerichtet waren, wurde eine GUI-gestütze 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 durchgeführten Tests
erläutert.
8.1 Die Applikation QSF40Sim
Die Applikation QSF40Sim simuliert das Verhalten der Montagelinie, indem sie Quelldateien in
die Eingangsverzeichnisse der Applikation QSF40 überträgt, was unter Realbedingungen durch
die Datenübertragungsprozesse geschieht. Die abgelegten Quelldateien beinhalten dabei Prozessdaten, die von der Applikation QSF40Sim selbst erzeugt werden. Die verwendeten Dateiformate sind
äquivalent 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 repräsentieren Paletten, auf denen Teile transportiert werden, und
speichern daher Seriennummern von Komponenten bzw. Getrieben. Spindle-Objekte repräsen82
KAPITEL 8. TESTS DER APPLIKATION QSF40
83
tieren Spindeln und sind für das Erzeugen von Prozessdaten zuständig. ControlUnit-Objekte
stellen die Datei-generierenden Systeme dar. Sie übertragen nach Abschluss einer Schicht die in
den Spindle-Objekten erzeugten Daten in Form von Textdateien in die Eingangsverzeichnisse
der Applikation QSF40. Die Station-Objekte repräsentieren die Stationen der Montagelinie.
Über Referenzen ist jedes Station-Objekt sowohl mit dem Objekt der vorgeschalteten Station
als auch mit dem Objekt der nachgeschalteten Station verknüpft. Ein Station-Objekt ist für die
Annahme und Weitergabe von Palette-Objekten zuständig. Nach Annahme eines PaletteObjektes 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 für diese
Stationen entsprechende Unterklassen der Klasse Station.
Zur Abbildung des Montageprozesses wurde das Erzeuger/Verbraucher-Muster implementiert.
Jedes Station-Objekt läuft innerhalb eines eigenen Threads und verhält sich gleichzeitig aus
Sicht seines Vorgänger-Objektes als Verbraucher“ und aus Sicht seines Nachfolger-Objektes als
”
Erzeuger“ von Palette-Objekten, indem es kontinuierlich bei seinem Vorgänger-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 übergeben wird.
Gleichermaßen können sich Palette-Objekte aufstauen, wenn ein Station-Objekt wesentlich
langsamer als sein Vorgänger-Objekt arbeitet. Überschreitet die Zahl der aufgestauten PaletteObjekte einen bestimmten Wert, kommt es zu einem Produktionsstillstand“ bei dem Vorgänger”
Objekt.
Die Spindle-Objekte erzeugen mithilfe von Zufallsgeneratoren (Klasse java.util.Random)
Prozessdaten, worunter sich auch Daten mit syntaktischen Fehlern und fehlenden Werten befinden.
Darüber hinaus können auch Änderungen der Grenzwerteinstellungen sowie Wiederholungen von
Operationen simuliert werden. Die Dauer einer Schicht sowie die Durchlaufzeiten der einzelnen
Stationen können spezifiziert werden. Indirekt lässt sich mithilfe dieser Parameter die Stückzahl
der in einer Schicht montierten Getriebe definieren.
8.2 Durchführung der Tests
Die Basisklassen der Applikation QSF40 wurden fortlaufend während der Implementierungsphase 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 entsprechenden Datei-Parser oder das korrekte Ausführen der SQL-Statements in der Datenbankabstraktionsschicht. Zum Testen der Parser-Klassen wurden sowohl selbst erzeugte Dateien aller
Quelldatei-Typen als auch DFQ-Dateien, die von dem Lieferanten Promess zur Verfügung gestellt
wurden, verwendet. In einem nächsten Schritt wurden mithilfe der Basisklassen die Datenberei-
KAPITEL 8. TESTS DER APPLIKATION QSF40
84
nigungsprozesse implementiert und hinsichtlich ihrer korrekten Funktionsweise isoliert voneinander getestet. In einem letzten Schritt wurden die Implementierungen der einzelnen Bereinigungsprozesse zu einer ganzen Applikation zusammengefügt. Bei den anschließenden Tests der Applikation standen im Gegensatz zu den vorangegangenen Tests Aspekte wie Speicherverbrauch,
CPU-Auslastung und Stabilität unter möglichst realistischen Bedingungen im Vordergrund. Ein
Vorteil bei der Zuhilfenahme der Applikation QSF40Sim bestand in der Möglichkeit, die Schichtdauer, die in der Realität acht Stunden beträgt, deutlich zu verkürzen ohne dabei die Menge
der erzeugten Daten zu reduzieren. Damit war es möglich die Applikation QSF40 über einen
längeren Zeitraum mit realistischen Datenmengen zu testen, wobei lediglich die Zeiträume zwischen zwei Ausführungszeitpunkten der Datenbereinigungsprozesse verkürzt waren. Während der
Testdurchführungen liefen die Applikation QSF40 sowie die Oracle-Datenbank (Oracle 9.1, Standardinstallation) auf einer Sun UltraSPARC 60 Workstation mit einem 450MHz Prozessor und
2GB Arbeitspeicher unter Sun Solaris 8.0. Die Applikation QSF40Sim lief während dessen auf
einem separaten Personal Computer. Die von der Applikation QSF40Sim erzeugten Quelldateien
wurden fortlaufend über das Netzwerk in die auf der Sun Workstation befindlichen Eingangsverzeichnisse kopiert.
Bei allen Testdurchführungen betrug die Schichtdauer 45 Minuten und die Durchsatzrate ca. 350
Getriebe/Schicht. Theoretisch hätte die Schichtdauer auch auf wenige Minuten verkürzt werden
können, doch benötigt die Applikation QSF40 einen Zeitraum von bis zu 40 Minuten, die Daten einer Schicht (350 Getriebe, 12.250 Datensätze) in die normalisierte Datenbank zu schreiben. Um zu
gewährleisten, dass die Applikation QSF40 bis Abschluss einer Schicht alle Daten der vorangegangen Schicht abgearbeitet hat, wurde die genannte Schichtdauer gewählt. Die Gesamtdauer jeweils
einer Testdurchführung war unterschiedlich lang und lag zwischen einer Schichtdauer und drei
Tagen. Bei allen Tests lag die CPU-Auslastung während der Ausführung der Datenbereinigungsprozesse in einem unkritischen Bereich, der Speicherverbrauch lag ebenfalls nach anfänglichem
Ansteigen konstant bei einem unkritischen Wert.
Mithilfe der durchgeführten Tests konnten Unzulänglichkeiten bei der Ausnahmebehandlung aufgedeckt werden. Nach einigen Verbesserungen bei der Ausnahmebehandlung lief die Applikation
schließlich stabil.
Kapitel 9
Fazit
Die Heterogenität der Quellsysteme ist nicht sehr stark ausgeprägt, da nur wenige Hersteller an der
Entwicklung der Quellsysteme beteiligt sind und die Formate für die Schraub- und Presskraftdaten
standardisiert sind. Außerdem existieren zwischen den einzelnen Datensätzen keine komplexen
Abhängigkeiten. Die Bereinigung der Quelldaten kann mithilfe der in der Zieldatenbank definierten Integritäts-Constraints durchgeführt werden, wobei allerdings auf eine Plausibilitätskontrolle
der Zeitstempel verzichtet wird. Infolge der eben genannten Punkte ist die Integration der Quelldaten unproblematisch.
Die Implementierung der Datenbereinigungsprozesse als Standalone-Applikation in Java ohne Zuhilfenahme externer Tools stellt eine schwache Kopplung zu anderen Applikationen sicher. Es ist
ohne großen Aufwand möglich, Qualitätsdaten weiterer Spindeln, die ursprünglich nicht im Anforderungsbereich 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 Datenübertragungsprozesse in der Montagelinie konnte die Applikation mithilfe der Applikation QSF40Sim unter annähernd realistischen Bedingungen getestet werden. Unter Testbedingungen funktionierte die implementierte Lösung im Bezug
auf Performance und Stabilität gut, so dass die Testergebnisse als positiv zu bewerten sind.
Mit der Applikation QSF40 zur Datenkonsolidierung sowie dem realisierten Frontend zur Erzeugung aller geforderten Reports, sind alle gestellten Anforderungen der Opel Powertrain GmbH
erfüllt.
Unabhängig davon sei jedoch erwähnt, dass die Datenqualität stark von der Disziplin der Arbeiter
und deren strikter Einhaltung des Fertigungsprozesses abhängt. Gelegentlich werden Getriebe auf
Paletten ausgetauscht, ohne dass die Getriebe-Seriennummer auf dem Datenträger der betroffenen Palette entsprechend aktualisiert wird. Dies gilt auch für den Austausch von Komponenten
und deren virtuelle Kennungen bei Reparaturen. Es ist vorgekommen, dass ein fertig montiertes
Getriebe auseinandergebaut, die auf dem Gehäuse 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 Fällen können selbstverständlich trotz Durchführung einer
Datenbereinigung keine korrekten Daten zur Verfügung gestellt werden.
Literaturverzeichnis
[1] Fiat-GM-Powertrain Manufacturing Engineering. General specification for measuring valuegenerating 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 Proceedings of The Conference on Information Quality (IQ2000), Massachusetts Institute of Technology, October 20-22, 2000, pp. 200-209
[4] Müller, Heiko; Freytag, Johann-Christoph. Problems, Methods, and Challenges in Comprehensive 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 für Qualitätsdokumente
und -aufzeichnungen, D10A1D4 Revision 5, 2000
[9] Grote, K.-H.; Beitz, W. Taschenbuch für den Maschinenbau, Springer, 19. Auflage, 1997
[10] Witten, I.H.; Frank, E. Data Mining - Praktische Werkzeuge und Techniken für das maschinelle Lernen, Hanser, 2001
87
Anhang A
Tabellen
88
ANHANG A. TABELLEN
Code
0017DW
0017AR
1916DM
1916TQ
1503ET
1503PD
1505EK
1505PF
89
Merkmal
Drehwinkel
Drehwinkel
Drehmoment
Drehmoment
Einpresstiefe
Einpresstiefe
Einpresskraft
Einpresskraft
Tabelle A.1: Codes zur Identifizierung der Qualitätsmerkmale
Schlüsselfeld
K0001
K0002
K0004
K0006
K0007
K0008
K2001
K2110
K2111
Bedeutung
Messwert
Fehlercode
Zeitstempel
Seriennummer
Spindelnummer
Stationsnummer
Merkmalscode
Unterer Grenzwert
Oberer Grenzwert
Tabelle A.2: Von einer DFQ-Datei zu untersützende Schlüsselfelder eines Qualitätsmerkmals

Kapitel 1 Einleitung

Transcription

Similar documents

Einige Tipps zum wissenschaftlichen Arbeiten

Die ersten Schritte in der Administration der PostgreSQL

Datenqualitätsanalyse beim Ladevorgang in Data Warehouses am

1.4 Prinzip der Strukturierung des Unter- richtsablaufs