Echtzeitdatenerfassung und Datenkonsolidierung zur ... · Universitat des Saarlandes, FR Informatik¨ Max-Planck-Institut f¨ur Informatik, AG5 Diplomarbeit im Fach Informatik Echtzeitdatenerfassung

Universitat des Saarlandes, FR Informatik

Max-Planck-Institut fur Informatik, AG5

Diplomarbeit im Fach Informatik

Echtzeitdatenerfassung und

Datenkonsolidierung zur

Qualitatssicherung einer

Getriebefertigungsstrecke

Autor

Christian Nicolaus

Betreuer

Prof. Dr.-Ing. Gerhard Weikum

Dr. Manfred Hensel

Datum der Abgabe

28. Juli 2005

Zusammenfassung

Im Getriebewerk der Opel Powertrain GmbH in Russelsheim werden im Rahmen der Qualitats-

sicherung an den einzelnen Montage-Stationen Prozessdaten erfasst. Diese Arbeit befasst sich mit

der Entwicklung eines Systems zur Bereinigung und Integration der an den Montage-Stationen an-

fallenden Prozessdaten, um eine einheitliche Basis fur spatere Data Mining-Analysen und sonstige

Datenabfragen zu schaffen.

Ich versichere hiermit, dass ich die vorliegende Arbeit selbstandig verfasst und keine anderen als

die angegebenen Quellen und Hilfsmittel verwendet habe.

Christian Nicolaus

Saarbrucken, 28. Juli 2005

Danksagung

Diese Arbeit entstand in der Fachrichtung Informatik an der Universitat des Saarlandes in Zusam-

menarbeit mit der Opel Powertrain GmbH in Russelsheim. Ich mochte an dieser Stelle folgenden

Personen danken:

Herrn Dr. Manfred Hensel von der EDS Deutschland GmbH, fur die ausgesproch-

en freundliche Unterstutzung bei allen auftretenden

Fragen und Problemen sowie die gute Betreuung der

Arbeit.

Frau Britta Basler von der EDS Deutschland GmbH, fur die kritischen

und hilfreichen Anmerkungen.

Herrn Prof. Dr.-Ing. Gerhard Weikum fur die Betreuung der Arbeit seitens der Universitat.

Allen anderen beteiligten Personen der Opel Powertrain GmbH, der Adam Opel AG so-

wie der EDS Deutschland GmbH, die mir bei sowohl

fachlichen als auch organisatorischen Fragen behilflich

waren.

Inhaltsverzeichnis

1 Einleitung 1

1.1 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Umfeld der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Die Opel Powertrain GmbH . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.2 Das Getriebewerk in Russelsheim . . . . . . . . . . . . . . . . . . . . . 3

1.3 Inhaltsuberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Bestandsaufnahme 6

2.1 Verbindungstechniken in der Getriebemontage . . . . . . . . . . . . . . . . . . . 6

2.2 Shims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Aufbau der Montagelinie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Aufbau einer Montage-Station . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Aufbau eines Operationsstands . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6 Erfassung von Prozessdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7 Abweichungen vom normalen Montageprozess . . . . . . . . . . . . . . . . . . 13

3 Anforderungen 15

3.1 Relevante Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 Schraubkraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.2 Presskraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3 Shim-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.4 Ausschleusungsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Relevante Stationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Datenkonsolidierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.5 Aufbewahrung der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.6 Systemumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

i

INHALTSVERZEICHNIS ii

4 Datenerfassung und Datenubertragung 19

4.1 Datenerfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Periodische versus sofortige Datenubertragung . . . . . . . . . . . . . . . . . . 20

4.3 Ubertragung der Schraub- und Presskraftdaten . . . . . . . . . . . . . . . . . . . 21

4.3.1 Das Q-DAS ASCII-Transferformat . . . . . . . . . . . . . . . . . . . . 21

4.3.2 DFD/DFX versus DFQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3.3 Anforderungen an die zu erzeugenden DFQ-Dateien . . . . . . . . . . . 24

4.4 Ubertragung der Kombinationsdaten . . . . . . . . . . . . . . . . . . . . . . . . 28

4.5 Ubertragung der Shim-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.6 Ubertragung der Ausschleusungsdaten . . . . . . . . . . . . . . . . . . . . . . . 29

5 Grundlagen zur Datenkonsolidierung 30

5.1 Datenqualitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 Datenqualitatsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.1 Single Source-Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.2 Multi Source-Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Datentransformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4 Datenbereinigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4.1 Parsen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.4.2 Integritatskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.4.3 Ausreißererkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.5 Die Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.5.1 Datenanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.5.2 Definition des Zielschemas . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.5.3 Definition der Datenbereinigungsprozesse . . . . . . . . . . . . . . . . . 46

6 Datenkonsolidierung 48

6.1 Datenanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.1.1 Kombinationsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.1.2 Presskraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.1.3 Schraubkraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.1.4 Shim-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1.5 Ausschleusungsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1.6 Beziehungen zwischen den Quellen und Multi Source-Probleme . . . . . 58

6.2 Definition des Zielschemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.3 Definition der Datenbereinigungsprozesse . . . . . . . . . . . . . . . . . . . . . 66

6.3.1 Einlesen und Bereinigen der Kombinationsdaten . . . . . . . . . . . . . 69

6.3.2 Einlesen und Bereinigen der Schraub- und Presskraftdaten . . . . . . . . 72

6.3.3 Einlesen und Bereinigen der Shim-Daten . . . . . . . . . . . . . . . . . 75

INHALTSVERZEICHNIS iii

6.3.4 Einlesen und Bereinigen der Ausschleusungsdaten . . . . . . . . . . . . 76

6.3.5 Bereinigen der Import- und Fehlertabellen . . . . . . . . . . . . . . . . . 76

7 Implementierung 77

7.1 Die Applikation QSF40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.2 Das Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8 Tests der Applikation QSF40 82

8.1 Die Applikation QSF40Sim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.2 Durchfuhrung der Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

9 Fazit 85

A Tabellen 88

Abbildungsverzeichnis

1.1 Aufbau des F40-Getriebes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Schematischer Aufbau des Getriebewerks . . . . . . . . . . . . . . . . . . . . . 5

2.1 Einpressung einer Welle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Kraft-Weg-Diagramm einer Pressvorgangs . . . . . . . . . . . . . . . . . . . . . 8

2.3 Layout der Montagelinie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Grundstruktur des Q-DAS ASCII-Transferformats (Zeichnung angelehnt an [6]) . 22

4.2 Beispiel fur eine DFQ-Datei mit Schraubkraftdaten . . . . . . . . . . . . . . . . 27

4.3 Beispiel fur eine DFQ-Datei mit Presskraftdaten . . . . . . . . . . . . . . . . . . 28

4.4 Auszug aus einer Datei mit Kombinationsdaten . . . . . . . . . . . . . . . . . . 29

4.5 Auszug aus einer Datei mit Shim-Daten . . . . . . . . . . . . . . . . . . . . . . 29

4.6 Auszug aus einer Datei mit Ausschleusungsdaten . . . . . . . . . . . . . . . . . 29

5.1 Hierarchie von Qualitatskriterien nach [4] . . . . . . . . . . . . . . . . . . . . . 31

5.2 Klassifizierung von Qualitatsproblemen nach [2] . . . . . . . . . . . . . . . . . 33

5.3 Ausreißererkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1 Logisches Datenbankmodell (ohne Fehlertabellen) . . . . . . . . . . . . . . . . 60

6.2 EQUI-Join zur Zuordnung der Schraub- und Presskraftdaten aus der Vormontage

zu den einzelnen Getrieben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.1 Aufbau der Applikation QSF40 . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

iv

Tabellenverzeichnis

2.1 Aufbau der Kombinationstabelle . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Ubersicht der qualitatsrelevanten Stationen . . . . . . . . . . . . . . . . . . . . . 17

4.1 Anzahl erzeugter Dateien in einem Zeitraum von acht Stunden bei einer Durch-

satzrate von 350 Getrieben in acht Stunden) . . . . . . . . . . . . . . . . . . . . 20

4.2 Schlusselfelder eines Werteeintrags . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1 Statistik zu Beispiel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44



6.1 Metadaten der Kombinationsdaten . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2 Metadaten der Presskraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.3 Toleranzbereiche fur Pressoperationen . . . . . . . . . . . . . . . . . . . . . . . 53

6.4 Sollwerte und Toleranzbereiche fur Schrauboperationen . . . . . . . . . . . . . . 54

6.5 Metadaten der Schraubkraftdaten . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.6 Metadaten der Shim-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.7 Metadaten der Ausschleusungsdaten . . . . . . . . . . . . . . . . . . . . . . . . 58

6.8 Die Tabelle TRANSMISSION . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.9 Die Tabelle STATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.10 Die Tabelle SCREWING OPERATION . . . . . . . . . . . . . . . . . . . . . . 62

6.11 Die Tabelle PRESSING OPERATION . . . . . . . . . . . . . . . . . . . . . . . 62

6.12 Die Tabelle LIMIT SCREWING . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.13 Die Tabelle SCREWING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.14 Die Tabelle LIMIT PRESSING . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.15 Die Tabelle PRESSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.16 Die Tabelle SHIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.17 Die Tabelle ERROR MEASUREMENT . . . . . . . . . . . . . . . . . . . . . . 66

6.18 Die Tabelle ERROR SHIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.19 Die Tabelle ERROR COMBINATION . . . . . . . . . . . . . . . . . . . . . . . 67

v

TABELLENVERZEICHNIS vi

6.20 Die Tabelle SYSTEM PARAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.21 Die Tabelle IMPORT COMBINATION . . . . . . . . . . . . . . . . . . . . . . 69

6.22 Die Tabelle COMBINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.23 Die Tabelle IMPORT MEASUREMENT . . . . . . . . . . . . . . . . . . . . . 73

A.1 Codes zur Identifizierung der Qualitatsmerkmale . . . . . . . . . . . . . . . . . 89

A.2 Von einer DFQ-Datei zu untersutzende Schlusselfelder eines Qualitatsmerkmals . 89

Kapitel 1

Einleitung

1.1 Ziel der Arbeit

Aufgrund der hohen Kundenerwartung und der in der EU geltenden Gewahrleistungspflicht sind

die Automobilhersteller bemuht, qualitativ hochwertige Produkte zu liefern. Denn hohe Produkt-

qualitat halt die Zahl der Beanstandungen seitens der Kunden gering, erhoht damit die Kundenzu-

friedenheit und spart erhebliche Kosten ein. Da hohe Produktqualitat schließlich einen wichtigen

Wettbewerbsvorteil darstellt, bekommt die Qualitatssicherung einen immer hoheren Stellenwert.

Im Zuge der Verbesserung der Qualitatssicherung bauen die Unternehmen ihre Qualitatsmanage-

mentsysteme aus. Ein IT-gestutztes Qualitatsmanagementsystem zur durchgehenden Produktions-

kontrolle in der Serienfertigung ermoglicht es, Ruckmeldungen aus dem Fertigungsprozess in die

zukunftige Fertigung einzubeziehen, so dass ein kontinuierlicher Qualitatsuberprufungs- und Ver-

besserungsprozess sichergestellt wird. Um die Einflussfaktoren der Produktion auf das Produkt

zu erkennen, werden qualitatsrelevante Prozessdaten des Fertigungsprozesses erfasst, gespeichert

und durch anschließendes Data Mining analysiert. Beim Data Mining handelt es sich um einen

automatisierten Prozess, der große Datenbestande anhand von statistischen Verfahren und Tech-

niken des maschinellen Lernens nach signifikanten Mustern und Trends durchsucht, die sonst

unerkannt geblieben waren. Data Mining kann als zentrale Phase eines als Knowledge Discove-

ry in Databases (KDD) bezeichneten Prozesses aufgefasst werden. Dieser nicht-triviale Prozess

enthalt u. a. eine Phase zur Interpretation und Konsolidierung von Mining-Ergebnissen. Die in

dieser Phase gewonnenen Erkenntnisse konnen moglicherweise Anreize fur spatere Maßnahmen

zur Qualitatsverbesserung darstellen.

Im Rahmen der Qualitatssicherung in der Getriebemontage bei der Opel Powertrain GmbH wer-

den im Getriebewerk in Russelsheim an den einzelnen Montage-Stationen qualitatsrelevante Pro-

zessdaten erfasst und lokal gespeichert. Die durch die lokale Datenspeicherung verursachte Ver-

teilung der Prozessdaten auf die einzelnen Montage-Stationen erschwert jedoch einfache Datenab-

1

KAPITEL 1. EINLEITUNG 2

fragen und verhindert eine ganzheitliche Sicht auf die Prozessdaten, so dass umfassendere Daten-

analysen nicht moglich sind. Daher ist es erforderlich, die an den Montage-Stationen anfallenden

Prozessdaten auf einem zentralen Server zusammenzufuhren und in ein einheitliches Datensche-

ma zu integrieren. Infolge dessen wird ein schnellerer und genauerer Mining-Prozess ermoglicht,

da die Daten auf einer einheitlichen Basis vorliegen.

Eine erfolgreiche Integration von Daten verschiedener Quellen erfordert im Allgemeinen eine

Konsolidierung der Quelldaten. Zum einen ist haufig die Homogenisierung der Daten erforder-

lich, um die mitunter in unterschiedlichen Formaten gespeicherten Daten aneinander anzuglei-

chen und an die gemeinsame, in der Regel normalisierte, Zieldatenbank auf dem zentralen Server

anzupassen. Zum anderen bedarf es einer Bereinigung der Quelldaten, da die Daten haufig mit

Datenmangeln unterschiedlicher Art behaftet sind. Typische Datenmangel sind beispielsweise:

• Inkorrekte Angaben, verursacht durch Eingabe-, Mess- oder Verarbeitungsfehler

• Logisch widerspruchliche Angaben

• Fehlende Angaben

• Duplikate im Datenbestand

Die Ursachen fur Datenmangel oben genannter Art sind vielfaltig. In der Regel wird jedoch die

Qualitat der Daten maßgeblich durch die Datenerfassungsphase im Quellsystem bestimmt. Wird

die Datenerfassung beispielsweise von einer Person durchgefuhrt, so konnen durch mangelnde

Fertigkeiten oder mangelnde Konzentration des Datenerfassers falsche Daten gespeichert werden.

Aber auch bei der automatischen Datenerfassung konnen durch defekte oder unzureichend justier-

te Messgerate falsche Daten geliefert werden. Schließlich konnen unzureichende Eingabekon-

trollen oder mangelhafte Datenverarbeitungsprozesse, die der Erfassung nachgeschaltet sind, Da-

tenmangel wie etwa fehlende Daten, logisch widerspruchliche Daten oder Duplikate begunstigen.

In der Datenubertragungsphase, in der die Datenbestande von den Quellsystemen zum Server

ubertragen werden, konnen Datenmangel aus technischen Fehlern (z. B. Netzwerkfehlern) so-

wie fehlerhaften Datenverarbeitungsprozessen zur Vor- bzw. Nachbereitung der Datenubertragung

(z. B. Export aus einer Datenbank) resultieren.

Da Datenmangel oben genannter Art die Ergebnisse statistischer Verfahren verfalschen, haben sie

einen negativen Einfluss auf die Ergebnisse aus den Data Mining-Analysen, was wiederum in-

nerhalb des KDD-Prozesses zu falschen Schlussfolgerungen in der Phase der Interpretation und

Konsolidierung von Mining-Ergebnissen fuhren kann. Weil demnach Datenmangel den effekti-

ven Nutzen der Daten vermindern konnen, ist der Prozess der Datenbereinigung mittlerweile ein

elementarer Bestandteil der Datenintegration geworden. Der Datenbereinigungsprozess umfasst


samtliche Maßnahmen, fehlerhafte Daten zu erkennen und zu beseitigen, um die Qualitat der Da-

ten zu erhohen. Aufgrund der großen Datenmengen, die gewohnlicher Weise erzeugt werden, ist

es unvermeidlich, die Datenbereinigung weitestgehend automatisiert durchzufuhren.

Ziel dieser Arbeit ist es, fur das Getriebewerk der Opel Powertrain GmbH in Russelsheim ein

System zu entwickeln, welches kontinuierlich neu erfasste Prozessdaten konsolidiert und in eine

zentrale Datenbank schreibt, um damit eine einheitliche Basis fur Datenanalysen zu schaffen. Mit

dem Ziel einer fruhzeitigen und automatisierten Fehlererkennung soll das System Fehler behaftete

Prozessdaten aussortieren und in einen Fehler-Report schreiben.

1.2 Umfeld der Arbeit

1.2.1 Die Opel Powertrain GmbH

Seit Juli 2001 ist die Opel Powertrain GmbH ein Tochterunternehmen der Fiat-GM-Powertrain.

Die Verwaltungszentrale der Fiat-GM-Powertrain befindet sich in Turin. Russelsheim ist Ent-

wicklungs- und Produktionsstandort fur Getriebe und Antriebstechnik mit ca. 1.750 Mitarbei-

tern. Insgesamt beschaftigt die Fiat-GM-Powertrain 24.000 Mitarbeiter an 17 Fertigungsstand-

orten und 7 Forschungs- und Entwicklungszentren in neun Landern Europas, Afrikas, Asiens und

Sudamerikas. Die Jahresproduktion umfasst ca. 5 Millionen Getriebe und ca. 5 Millionen Motor-

en. Der Jahresumsatz belauft sich auf insgesamt 7 Milliarden Euro. Die Fiat-GM-Powertrain ist

damit das weltweit großte eigenstandige Unternehmen auf dem Antriebssektor. Zu den Kunden

zahlen u. a. Alfa Romeo, Fiat, Chevrolet, Cadillac, Lancia, Opel, Saab und Vauxhall.

1.2.2 Das Getriebewerk in Russelsheim

Im Russelsheimer Getriebewerk werden gegenwartig ausschließlich F40-Getriebe in verschieden-

en Ausfuhrungen (Typen) produziert. Das F40-Getriebe ist ein 6-Gang-Schaltgetriebe fur lei-

stungsstarke Frontantriebe. Die Typenvielfalt wird durch die Erfullung von individuellen Kun-

denwunschen (z. B. Ubersetzung, Materialbeschaffenheit bestimmter Teile, etc.) verursacht. Der

grundlegende Aufbau des Getriebes und damit auch der Montageprozess sind jedoch bei allen

Typen identisch. Abbildung 1.1 stellt den grundlegenden Aufbau des Getriebes dar, die zentralen

Komponenten des Getriebes sind das Differential in Kombination mit dem Stirnrad, die untere und

die obere Hauptwelle, die Antriebswelle sowie das Getriebe- und das Kupplungsgehause.

Abbildung 1.2 zeigt den schematischen Aufbau des Getriebewerks. Im Logistikbereich werden die

Rohteile aus der Schmiede angeliefert, die dann entsprechend ihrer Verwendung auf die Wellen-

fertigung oder Zahnradfertigung verteilt werden. Anschließend werden die bearbeiteten Rohteile

der Harterei zugefuhrt. In der Harterei werden die Teile durch eine Warmebehandlung gehartet.

Dieser Prozess ist notwendig, da ungehartete Teile den hohen Kraften, die in einem Getriebe auf-


Abbildung 1.1: Aufbau des F40-Getriebes

treten, nicht standhalten wurden. Nach der Behandlung in der Harterei und anschließend erfolgter

Prazisionsnachbearbeitung werden die Teile in den Montagebereich transportiert, wo sie zu einem

voll funktionsfahigen Getriebe zusammengesetzt werden. Die vorliegende Arbeit beschrankt sich

ausschließlich auf den Bereich der Datenerfassung im Montagebereich.

1.3 Inhaltsuberblick

Nach dieser Einleitung wird in Kapitel 2 eine Bestandsaufnahme durchgefuhrt. Dabei wird jenes

Wissen uber den Aufbau der Montagelinie sowie uber die verschiedenen Ablaufe in der Montage-

linie vermittelt, welches zum Verstandnis spaterer Diskussionen fuhrt.

In Kapitel 3 werden die Anforderungen seitens der Opel Powertrain GmbH an das zu entwickeln-

de System beschrieben.

Kapitel 4 geht zunachst auf die Datenerfassung an den Montage-Stationen sowie auf die Verfah-

rensweise bei der Ubertragung der Daten von den Montage-Stationen zum Server ein. Anschlie-

ßend werden die Dateiformate, die bei der Datenubertragung zur Anwendung kommen, beschrie-

ben.

Kapitel 5 befasst sich mit den notwendigen Grundlagen zur Datenkonsolidierung. Der Begriff der

Datenqualitat wird prazisiert und die verschiedenen Datenmangel, die fur die Verringerung der Da-

tenqualitat verantwortlich sein konnen, werden genauer erlautert. Abschließend werden mogliche


Abbildung 1.2: Schematischer Aufbau des Getriebewerks

Methoden zur Datenbereinigung sowie eine allgemeingultige Vorgehensweise zur Datenkonsoli-

dierung beschrieben.

In Kapitel 6 wird die zuvor beschriebene Vorgehensweise zur Datenkonsolidierung auf den vorlie-

genden Anwendungsfall angewendet und eine Losung fur das zu entwickelnde System diskutiert.

Kapitel 7 geht auf die Implementierung der realisierten Losung ein.

Kapitel 8 erlautert die Vorgehensweise sowie die erzielten Ergebnisse bei den durchgefuhrten Tests

der Implementierung.

Abschließend wird in Kapitel 9 ein Fazit gezogen.

Kapitel 2

Bestandsaufnahme

In diesem Kapitel werden zunachst die notwendigen Grundlagen aus dem Maschinenbau erlautert

(Abschnitte 2.1 und 2.2). Anschließend werden der grobe Ablauf des Montageprozesses (Ab-

schnitt 2.3) sowie der Aufbau einer Montage-Station (Abschnitt 2.4) und eines Operationsstandes

(Abschnitt 2.5) beschrieben. Außerdem wird auf die Prozessdatenerfassung in der Montagelinie

eingegangen (Abschnitt 2.6). Abschließend werden die vorkommenden Abweichungen vom Mon-

tageprozess erlautert, da diese Einfluss auf die Erfassung der Prozessdaten haben (Abschnitt 2.7).

2.1 Verbindungstechniken in der Getriebemontage

Bei der Getriebemontage werden die einzelnen Teile auf zwei verschiedene Arten miteinander

verbunden. Bei den beiden Verbindungsarten handelt es sich um Press- sowie Schraubenverbin-

dungen.

Pressverbindungen

Wie in Abbildung 2.1 angedeutet, werden bei einer Pressverbindung zwei Teile zusammengefugt,

indem sie mithilfe einer Presse ineinander gepresst werden. Wahrend vor dem Pressvorgang zwi-

schen dem Außen- und dem Innenteil einUbermaß besteht, wirkt nach dem Pressvorgang aufgrund

der Werkstoffpressung in der Fugeflache zwischen beiden Teilen eine Haftkraft, durch die die bei-

den Teile zusammengehalten werden [9]. Der Krafteverlauf eines Pressvorgangs lasst sich durch

ein Kraft-Weg-Diagramm (siehe Abbildung 2.2) beschreiben, welches die aufgewendete Anpress-

kraft in Abhangigkeit des vom Pressstempel zuruckgelegten Weges angibt. Im Rahmen der Qua-

litatssicherung ist insbesondere die aufgewendete Kraft bei Abschluss des Pressvorgangs von Be-

deutung. Da das exakte Erreichen des Sollwertes aus technischen Grunden nicht moglich ist, wird

fur die aufzuwendende Anpresskraft ein Toleranzbereich festgelegt, der beim Pressvorgang ein-

gehalten werden muss. Wahrend das Uberschreiten der oberen Toleranzgrenze zur Beschadigung

6

KAPITEL 2. BESTANDSAUFNAHME 7

Abbildung 2.1: Einpressung einer Welle

der entsprechenden Teile fuhren kann, hat das Unterschreiten der unteren Toleranzgrenze einen

ungenugenden Zusammenhalt der Teile zur Folge.

Schraubenverbindungen

Eine Schraubenverbindung ist eine losbare Verbindung von Teilen durch eine oder mehrere Schrau-

ben. Wird eine Kopfschraube angezogen, dann entsteht eine Zugkraft (Vorspannkraft) �� in der

Schraube und eine gleich hohe Druckkraft zwischen den zu verschraubenden Teilen. Beim Drehen

der Schraube mussen das mit �� steigende Reibungsmoment im Gewinde und das Reibungsmo-

ment unterhalb des Kopfes uberwunden werden [9]. Die Summe der beiden Momente ergeben

das Anziehdrehmoment, welches fur die Qualitatssicherung eine relevante Große darstellt. Wie

bei einem Pressvorgang lasst sich auch der Krafteverlauf eines Schraubvorgangs durch ein Kraft-

Weg-Diagramm beschreiben. Es zeigt das aufgewendete Drehmoment in Abhangigkeit der vom

Schrauber durchgefuhrten Drehbewegung. Bei einem Schraubvorgang ist es wichtig, dass das auf-

gewendete Drehmoment bei Abschluss des Schraubvorgangs in einem fest definierten Toleranzbe-

reich liegt. Ein zu geringes Anziehdrehmoment kann dazu fuhren, dass mogliche Relativbewegun-

gen der Teile gegeneinander nicht genugend verhindert werden. Ein zu hohes Anziehdrehmoment

kann eine Beschadigung der Schraube oder des Gewindes und somit ein Versagen der Schrauben-

verbindung zur Folge haben.

2.2 Shims

Aufgrund der Getriebekonstruktion und der Maßtoleranzen bei der Fertigung der einzelnen Getrie-

beteile existiert langsseitig zwischen den drei existierenden Wellen (Antriebswelle, Obere Haupt-

welle, Untere Hauptwelle) und der Gehausewand sowie zwischen dem Differentialgehause und der


Abbildung 2.2: Kraft-Weg-Diagramm einer Pressvorgangs

Gehausewand jeweils ein Spiel. Um diese Spiele auszugleichen, wird zwischen den eben genann-

ten Teilen und der Gehausewand jeweils eine Scheibe (Shim) eingesetzt, die in etwa vergleichbar

mit einer Unterlegscheibe fur Schrauben ist. Insgesamt existieren 25 verschiedene Shim-Großen,

die zum Ausgleich vorhandener Spiele verwendet werden konnen.

2.3 Aufbau der Montagelinie

Abbildung 2.3 zeigt das Layout der Montagelinie. Die weißen Rechtecke stellen Stationen dar,

an denen Getriebe oder Getriebekomponenten von Maschinen bearbeitet werden. Bei der Bear-

beitung werden uberwiegend Schraub- und Pressoperationen durchgefuhrt. In dieser Arbeit wird

unter einer Schrauboperation ein einzelner Schraubvorgang und unter einer Pressoperation ein

einzelner Pressvorgang verstanden. Die grauen Rechtecke skizzieren Operationsstande, an denen

Schrauboperationen oder sonstige Tatigkeiten von einer Person durchgefuhrt werden.

Die Montagelinie gliedert sich in drei Verkettungsabschnitte. Wahrend der Verkettungsabschnitt 1

(VK1) die Vormontage des Differentials und der verschiedenen Wellen umfasst, werden im Ver-

kettungsabschnitt 2 (VK2) die Vormontage des Getriebe- und des Kupplungsgehauses sowie die

Endmontage des Getriebes durchgefuhrt. Der Verkettungsabschnitt 3 (VK3) dient zur Endkontrol-

le des Getriebes sowie zur Durchfuhrung einiger abschließender Arbeiten am Getriebe.


Abbildung 2.3: Layout der Montagelinie


Ein Ausgangspunkt der Montagelinie sind die Stationen ST010 und ST011, die fur die Vormon-

tage des Differentials zustandig sind. Beide fuhren exakt die gleichen Montageschritte durch und

laufen wahlweise im Einzel- oder im Doppelbetrieb. Jedes montierte Differential gelangt uber ein

Laufband zur Station ST040, an der das Stirnrad montiert wird. Dabei werden jeweils ein Differ-

ential und ein Stirnrad miteinander verschraubt. Jedes montierte Stirnrad wird jeweils auf einer

separaten Palette, die an den nachfolgenden Stationen jeweils mit einer weiteren Getriebekompo-

nente bestuckt wird, abgelegt. Jede der drei nachfolgenden Stationen ST060, ST070 und ST080

ist fur die Vormontage genau eines Wellentyps (Untere Hauptwelle, Obere Hauptwelle, Antriebs-

welle) zustandig. Bei der Wellenvormontage werden im Wesentlichen die Zahnrader der einzelnen

Gange auf die Wellen aufgepresst. Nach Durchlaufen der Station ST080 verfugt jede Palette uber

ein Differential, welches mit einem Stirnrad verbunden ist, sowie uber drei verschiedene Wellen

und damit uber einen kompletten Wellensatz, der fur das Innenleben eines Getriebes erforderlich

ist.

Ein weiterer Ausgangspunkt der Montagelinie ist die Station ST110. Wahrend an der Station

ST110 die Vormontage des Getriebegehauses erfolgt, wird an der Station ST120 die Vormonta-

ge des Kupplungsgehauses durchgefuhrt. Bei der Vormontage dieser beiden Gehausekomponenten

werden insbesondere Dichtungsringe in die verschiedenen Gehauseoffnungen eingepresst. Zusam-

mengesetzt bilden die beiden Gehausekomponenten das komplette Gehause eines Getriebes. Die

Getriebe- und Kupplungsgehause werden jeweils auf separaten Paletten in abwechselnder Reihen-

folge in die Station ST140 eingeschleust.

Die Laufbander der beiden Ausgangspunkte der Montagelinie munden in die Station ST140, an

der die Endmontage des Getriebes beginnt. Sobald jeweils eine Palette mit einem kompletten

Wellensatz aus der Wellenvormontage sowie eine Palette mit einem Kupplungsgehause aus der

Gehausevormontage eingeschleust wurden, wird der Wellensatz in das Kupplungsgehause einge-

bracht und die bei diesem Vorgang frei werdende Palette ausgeschleust. Das auf einer weiteren Pa-

lette aus der Gehausevormontage folgende Getriebegehause wird im weiteren Verlauf unmittelbar

hinter der Palette des Kupplungsgehauses mit dem inzwischen eingebrachten Wellensatz transpor-

tiert, um an der Station ST190 zum Verschließen des Getriebes verwendet zu werden. Aufgrund

dieses Prozessablaufs entscheidet sich an der Station ST140 aus welchen Wellen und aus wel-

chen Gehausekomponenten ein Getriebe zusammengesetzt wird. An der darauf folgenden Station

ST150 werden durch Ermitteln der vorhandenen Spiele die benotigten Shim-Großen ermittelt. Der

Einbau der entsprechenden Shims wird an der Station ST160 durchgefuhrt. Außerdem wird an die-

ser Station das Einstellen der Lager vorgenommen. An der Station ST190 werden nach erfolgtem

Dichtmittelauftrag die beiden Gehausekomponenten zusammengeschraubt. Wahrend am Operati-

onsstand OP210 gegebenenfalls Korrekturen der Gehauseverschraubungen durchgefuhrt werden,

wird am Operationsstand OP220 die Schaltmechanik montiert.


Im Verkettungsabschnitt 3 werden an den Stationen ST250, ST260 und ST270 akustische End-

kontrollen durchgefuhrt, bei denen das montierte Getriebe im laufenden Betrieb getestet wird. Die

darauf folgenden Stationen sind fur einige abschließende Arbeiten zustandig, wie beispielsweise

die Olaufbereitung sowie das Einlasern der Getriebe-Seriennummer in das Getriebegehause. Als

letzte Tatigkeit wird an der Station ST300 ein Etikett mit der Getriebe-Seriennummer gedruckt,

welches anschließend zur logistischen Erfassung des Getriebes eingescannt wird. Von diesem Mo-

ment an steht das fertig montierte Getriebe dem Vertrieb zur Verfugung.

2.4 Aufbau einer Montage-Station

An jeder Montage-Station befinden sich verschiedene Fugevorrichtungen, deren Art und Anzahl

von den durchzufuhrenden Operationen abhangt. Fur Schrauboperationen existieren ausschließ-

lich Schraubvorrichtungen der Firma Bosch und fur Pressoperationen ausschließlich Pressvorrich-

tungen der Firma Promess. Jede Fugevorrichtung verfugt wiederum uber mindestens eine Spindel,

die je nach Art der Fugevorrichtung ein einzelner Schrauber oder ein einzelner Pressstempel ist.

Jeder Spindel ist eine Spindelnummer zugewiesen, dazu werden die Press- und Schraubspindeln

einer Montage-Station jeweils von � bis � durchnummeriert. Eine eindeutige Spindelnummernzu-

ordnung, uber alle Press- und Schraubspindeln einer Montage-Station betrachtet, existiert nicht.

Abgesehen von ein paar Ausnahmen bei den Pressspindeln, bei denen Verpressungen in zwei

Schritten durchgefuhrt werden, wird jedes Teil genau einmal von ein und derselben Spindel be-

arbeitet. Erfolgt eine Verpressung in zwei Schritten, so kann jeder Schritt als eine eigene Press-

operation aufgefasst werden. Jede Spindel ist mit einem Steuergerat verbunden, welches fur die

Steuerung der entsprechenden Spindel und zum Empfangen der an dieser Spindel anfallenden Pro-

zessdaten verantwortlich ist.

Des Weiteren ist jede Station mit einem gewohnlichen Rechner (Microsoft WindowsNT 4.0) aus-

gestattet, der uber ein lokales 10MBit-Netzwerk mit dem zentralen Server verbunden ist. In je-

dem Rechner ist eine speicher-programmierbare Steuereinheit (SPS) eingebaut, die wiederum mit

den an der Montage-Station befindlichen Steuergeraten verbunden ist. Eine SPS ist ein Automa-

tisierungsgerat, welches die autarke Steuerung des gesamten Montageprozesses an der Montage-

Station ubernimmt. Uber eine Steuerungssoftware auf dem Rechner der Montage-Station konnen

jeder Spindel die Sollwerte sowie die Toleranzbereiche fur Weg (Drehwinkel/Einpresstiefe) und

Kraft (Drehmoment/Einpresskraft) zugewiesen werden.

2.5 Aufbau eines Operationsstands

Operationsstande dienen insbesondere der Durchfuhrung kleinerer Reparaturen an Werkstucken.

Beispielsweise kann am Operationsstand OP050 eine Verschraubung von einem Arbeiter korrigiert

werden, wenn diese zuvor an der Station ST040 aus irgendwelchen Grunden nicht zufriedenstel-


Feldname Felddatentyp BeschreibungID OPEL Text Getriebe-SeriennummerID SAAB Text Kunden-Seriennummer (SAAB)ID FIAT Text Kunden-Seriennummer (FIAT)TIMESTAMP Datum/Uhrzeit Zeitpunkt der ErfassungV ID1 Text Virtuelle Kennung: Stirnrad/Differential (ST040)V ID2 Text Virtuelle Kennung: Untere Hauptwelle (ST060)V ID3 Text Virtuelle Kennung: Obere Hauptwelle (ST070)V ID4 Text Virtuelle Kennung: Antriebswelle (ST080)V ID5 Text Virtuelle Kennung: Getriebegehause (ST110)V ID6 Text Virtuelle Kennung: Kupplungsgehause (ST120)

Tabelle 2.1: Aufbau der Kombinationstabelle

lend durchgefuhrt wurde. Die Verschraubung erfolgt in diesem Fall mit einem Handschrauber. Am

Operationsstand OP090 besteht die Moglichkeit, auf einer Palette eine fehlerhafte Getriebekompo-

nente aus der Wellenvormontage auszutauschen. Das Austauschen einer Welle ist beispielsweise

dann notwendig, wenn bei der besagten Welle das Aufpressen eines Zahnrades in einer der zuvor

durchlaufenen Stationen fehlgeschlagen ist. Eine Reparatur von fehlerhaften Verpressungen er-

folgt grundsatzlich nicht, stattdessen werden die betroffenen Teile ausgetauscht und verschrottet.

2.6 Erfassung von Prozessdaten

Jeweils zu Beginn der Montage eines Stirnrades (Station ST040) und der Vormontage einer Welle

(Stationen ST060, ST070 und ST080) sowie der Vormontage einer Gehausekomponente (Statio-

nen ST110 und ST120) weist die jeweilige Montage-Station der entstehenden Komponente eine

achtstellige Seriennummer zu, die als virtuelle Kennung bezeichnet wird. Jede Montage-Station

verwendet dabei ein eigenes Nummernband. Die erzeugte Kennung wird auf einen elektronischen

Datentrager unterhalb der Palette geschrieben, auf der die Komponente abgelegt wird. Der Daten-

trager ist in der Lage, die Seriennummern samtlicher auf der Palette befindlichen Teile zu spei-

chern.

Sobald an der Station ST140 die fur ein Getriebe notwendigen Komponenten aus der Vormontage

kombiniert werden, wird dem in diesem Moment entstehenden Getriebe eine Getriebe-Seriennum-

mer zugewiesen. Ist das Getriebe fur die Kunden Saab oder Fiat vorgesehen, so erhalt das Getriebe

zusatzlich zur Getriebe-Seriennummer eine Kunden-Seriennummer. Die virtuellen Kennungen auf

den Datentragern der drei Paletten aus der Vormontage werden ausgelesen und zusammen mit der

zugewiesenen Getriebe-Seriennummer und ggf. der Kunden-Seriennummer in eine Tabelle einer

Microsoft Access-Datenbank geschrieben, deren Aufbau in Tabelle 2.1 dargestellt ist. Damit lasst

sich fur jedes Getriebe nachvollziehen, aus welchen Komponenten es zusammengesetzt wurde.

Mit Ausnahme der Palette, die nach Einbringung des Wellensatzes in das Kupplungsgehause aus-


geschleust wird, werden die virtuellen Kennungen auf den Datentragern der Paletten durch die

zugewiesene Getriebe-Seriennummer ersetzt. Von diesem Zeitpunkt an hat nur noch die Getriebe-

Seriennummer Gultigkeit.

Wahrend der Bearbeitung einer Komponente bzw. eines Getriebes durch eine Montage-Station

sendet die SPS uber einen Datenbus Steuerbefehle an die Steuergerate der einzelnen Spindeln,

dabei wird auch die Seriennummer des zu bearbeitenden Teils ubermittelt. Wie bereits erwahnt,

wird in der Vormontage die Seriennummer an der jeweiligen Montage-Station selbst erzeugt, in

der Endmontage wird die Seriennummer des bearbeiteten Getriebes aus dem Datentrager unter-

halb der Palette ausgelesen. Die an den Steuergeraten anfallenden Prozessdaten werden samt der

Seriennummer des bearbeiteten Teils direkt von dem jeweiligen Steuergerat an den Rechner der

Montage-Station gesendet. Prozessdaten einer fehlgeschlagenen Operation werden dabei mit ei-

nem entsprechenden Fehlercode versehen. Die auf dem Rechner installierte Steuerungssoftware

speichert die von den Steuergeraten empfangenen Prozessdaten im lokalen Dateisystem. Handelt

es sich bei den Prozessdaten um Daten einer Schrauboperation, so werden die Werte in dem von

der Firma Aton GmbH entwickelten Datenbankformat Nexum gespeichert. Prozessdaten einer

Pressoperation werden dagegen in eine Microsoft Access-Datenbank geschrieben. Die eben ge-

nannten Datenhaltungssysteme fur die Prozessdaten von Schraub- und Pressoperationen werden

an dieser Stelle nicht weiter beschrieben, da sie im Rahmen dieser Arbeit nicht weiter verwendet

werden sollen (vgl. Abschnitt 4.1).

2.7 Abweichungen vom normalen Montageprozess

Aufgrund von Ausfallen von Fugevorrichtungen oder aufgrund von fehlgeschlagenen Operationen

kann es zu Abweichungen vom normalen Montageprozess kommen. Da diese Umstande Einfluss

auf die Datenerfassung haben, werden diese kurz beschrieben:

• Kommt es zu einem Ausfall einer Schraubvorrichtung, fuhren die Arbeiter die Verschrau-

bungen mithilfe eines Handschraubers durch. Wie bei der Durchfuhrung einer Verschrau-

bung an einem Operationsstand, erfolgt in diesem Fall keine Erfassung der zugehorigen

Prozessdaten.

• Wie in Abschnitt 2.5 erwahnt, kann am Operationsstand OP090 ein Austausch einer Getrie-

bekomponente erfolgen. In diesem Fall wird die virtuelle Kennung der ausgetauschten Kom-

ponente auf dem Datentrager der Palette nicht durch die Kennung der neuen Komponente

ersetzt. Stattdessen erhalt das Datenfeld auf dem Datentrager lediglich den Wert”99999999“

um den Austausch der Komponente als Solchen zu erfassen. Eine Ruckverfolgung von Pro-

zessdaten fur die Ersatzkomponente ist demnach nicht mehr moglich.


• Falls innerhalb des Verkettungsabschnittes 2 eine Pressoperation fehlschlagt, wird das be-

troffene Getriebe ausgeschleust und wahlweise repariert oder verschrottet. Im Falle einer

Reparatur wird das defekte Teil durch ein intaktes Teil ersetzt und das Getriebe anschlie-

ßend wieder eingeschleust. Der Austausch des defekten Teils wird DV-technisch nicht er-

fasst. Im Falle einer Verschrottung wird das Getriebe komplett auseinander gebaut. Wahrend

die defekten Teile verschrottet werden, dienen die intakten Teile zukunftig als Ersatzteile.

Kapitel 3

Anforderungen

Die Aufgabenstellung in der vorliegenden Arbeit ist in Kapitel 1 erlautert. Es sollen qualitatsre-

levante Merkmale der in der Montagelinie anfallenden Prozessdaten erfasst, uber das Netzwerk

auf einen zentralen Server ubertragen und in konsolidierter Form in einer Datenbank gespeichert

werden. Die genauen Anforderungen seitens der Opel Powertrain GmbH an das zu entwickelnde

System werden in diesem Kapitel beschrieben.

3.1 Relevante Daten

Es existieren drei verschiedene Arten von Daten, die im Rahmen der Qualitatssicherung relevant

sind und als Qualitatsdaten bezeichnet werden. Es handelt sich dabei um Schraub- und Presskraft-

daten sowie Shim-Daten.

3.1.1 Schraubkraftdaten

Zu einer Schrauboperation sollen folgende Merkmale erfasst werden:

• Getriebe-Seriennummer und Kunden-Seriennummer

• Stationsnummer und Spindelnummer

• Endstand des Drehwinkels

• Endstand des Anziehdrehmoments

• Aktuell geltender unterer und oberer Grenzwert fur den Endstand des Drehwinkels

• Aktuell geltender unterer und oberer Grenzwert fur den Endstand des Anziehdrehmoments

• Zeitpunkt der Operation

15

KAPITEL 3. ANFORDERUNGEN 16

3.1.2 Presskraftdaten

Zu einer Pressoperation sollen folgende Attribute erfasst werden:


• Stationsnummer, Spindelnummer und Schrittnummer1

• Endstand der Einpresstiefe

• Endstand der Einpresskraft

• Aktuell geltender unterer und oberer Grenzwert fur den Endstand der Einpresstiefe

• Aktuell geltender unterer und oberer Grenzwert fur den Endstand der Einpresskraft

• Zeitpunkt der Operation

3.1.3 Shim-Daten

An der Station ST150 werden die fur ein Getriebe zu verwendenden Shim-Großen ermittelt. Dabei

sollen folgende Attribute erfasst werden:


• Shim-Klasse

• Getriebekomponente, fur die das Shim verwendet werden soll

• Zeitpunkt der Erfassung

3.1.4 Ausschleusungsdaten

Erganzend zu den bisher genannten Qualitatsdaten soll der Zeitpunkt erfasst werden, zu dem ein

Getriebe aus der letzten Station (ST300) ausgeschleust wird und damit die Montagelinie ordnungs-

gemaß verlasst.

3.2 Relevante Stationen

Obwohl an allen Stationen in den Verkettungsabschnitten 1 und 2 Press- und/oder Schrauboper-

ationen durchgefuhrt werden, sind im Rahmen der Qualitatssicherung nur die Schraub- und Press-

kraftdaten relevant, die an den in Tabelle 3.1 aufgelisteten Stationen erfasst werden. Zusatzlich

zeigt die Tabelle, uber wie viele Schraub- und Pressspindeln die einzelnen Stationen verfugen.

1Falls eine Verpressung in zwei Schritten durchgefuhrt wird, dient die Schrittnummer zur Unterscheidung der beidenPressoperationen.


Station AnzahlSchraub-spindeln

AnzahlPressspin-deln

Montageschritt

ST040 2 1 Montage des StirnradesST110 2 5 Vormontage des GetriebegehausesST120 1 9 Vormontage des KupplungsgehausesST140 1 4 Einpressen der InnenringeST150 - - Ermitteln der zu verwendenden Shim-GroßenST160 - 4 Einstellen der Lager sowie Einbau der ShimsST300 - - Erfassen des Ausschleusungszeitpunktes

Tabelle 3.1: Ubersicht der qualitatsrelevanten Stationen

3.3 Datenkonsolidierung

Bei der Datenkonsolidierung sollen folgende Anforderungen berucksichtigt werden:

• Bei allen Messwerten ist eine Genauigkeit von zwei Stellen nach dem Komma ausreichend.

• Qualitatsdaten, die aufgrund einer fehlgeschlagenen Operation bereits vom Messsystem mit

einem entsprechenden Fehlercode versehen wurden, sollen nicht gespeichert werden. In ei-

nem solchen Fall kann man davon ausgehen, dass die betroffene Operation wiederholt wird

oder das Getriebe ausgeschleust und verschrottet wird.

• Falls eine Operation wiederholt wird, sollen nur jene Daten erfasst werden, die mit der wie-

derholten Durchfuhrung im Zusammenhang stehen. Die Daten des ersten Versuchs sollen

in diesem Fall verworfen werden. Obwohl mehrere Messungen, die das gleiche Getriebe

und die gleiche Operation betreffen, verschiedene Entitaten der Realitat sind, werden die

entsprechenden Datensatze als Duplikate bezeichnet.

• Qualitatsdaten, die aufgrund fehlerhafter Werte nicht gespeichert werden konnen, sollen

in einen Fehler-Report geschrieben werden. Eine Korrektur von falschen oder fehlenden

Werten soll in keinem Fall erfolgen.

• Falls fur ein Getriebe nicht zu allen Operationen ein entsprechender Datensatz vorhanden

ist, so wird dies toleriert.

3.4 Frontend

Es soll ein Frontend zur Verfugung gestellt werden, mit dem der Anwender nach Getrieben suchen

und sich Qualitatsdaten anzeigen lassen kann. Das Frontend soll mit der JSP/Servlet-Technologie


realisiert werden. Im Folgenden werden zwei Anwendungsfalle beschrieben, um die Anforder-

ungen an das Frontend zu verdeutlichen.

Anwendungsfall 1

Der Anwender gibt entweder eine vollstandige Seriennummer (Getriebe-Seriennummer oder Kun-

den-Seriennummer) oder die ersten Zeichen der Seriennummer ein und startet die Suche. An-

schließend wird dem Anwender eine Auswahlliste der zur Sucheingabe passenden Seriennummern

angezeigt. Nach Auswahl einer Seriennummer wird dem Anwender eine Liste derjenigen Sta-

tionen angezeigt, zu denen Qualitatsdaten bezuglich des ausgewahlten Getriebes verfugbar sind.

Nach Auswahl einer Station wird dem Anwender die Gesamtheit aller an der Station angefallenen

Qualitatsdaten bezuglich des ausgewahlten Getriebes angezeigt.

Anwendungsfall 2

Der Anwender spezifiziert einen Getriebetyp und/oder einen Zeitraum fur den Ausschleusungs-

zeitpunkt und startet die Suche. Anschließend werden dem Anwender die Seriennummern derje-

nigen Getriebe angezeigt, die alle spezifizierten Suchkriterien erfullen.

3.5 Aufbewahrung der Daten

Die erfassten Qualitatsdaten mussen fur einen Zeitraum von mindestens zwei Jahren aufbewahrt

werden. Diese Anforderung ergibt sich aus den Richtlinien in [8], die eine Grundlage zur ISO-

Zertifizierung darstellen. Angesichts der geplanten Data Mining-Analysen wird jedoch von einem

Aufbewahrungszeitraum von mindestens zehn Jahren ausgegangen.

3.6 Systemumgebung

Die konsolidierten Daten sollen in einer Oracle ��-Datenbank unter Sun Solaris gespeichert wer-

den. Als Programmiersprache soll Java J2SE 1.4 oder hoher verwendet werden. Bei der Imple-

mentierung soll berucksichtigt werden, dass die gesamte Konsolidierung moglichst in einer ei-

genstandigen Applikation erfolgt, um eine schwache Kopplung mit anderen Applikationen auf

dem Server sicherzustellen.

Kapitel 4

Datenerfassung und Datenubertragung

In diesem Kapitel wird zunachst auf die Datenerfassung an den Montage-Stationen (Abschnitt 4.1)

sowie auf die Verfahrensweise bei der Ubertragung der Daten von den Montage-Stationen zum

Server (Abschnitt 4.2) eingegangen. In den darauf folgenden Abschnitten werden die bei der Da-

tenubertragung verwendeten Dateiformate detailliert beschrieben.

4.1 Datenerfassung

Das Auslesen der Schraub- und Presskraftdaten aus den Steuergeraten an den einzelnen Montage-

Stationen erfolgt durch die Steuerungssoftware, die von dem Lieferanten der jeweiligen Fuge-

vorrichtung entwickelt und betrieben wird. Die bisher verwendeten Datenhaltungssysteme an den

Montage-Stationen fur die Schraub- und Presskraftdaten (vgl. Abschnitt 2.6) werden jedoch im

Rahmen dieser Arbeit nicht verwendet. Stattdessen kommt eine Textdateibasierte Datenhaltung

im so genannten Q-DAS ASCII-Transferformat, welches in Abschnitt 4.3.1 naher beschrieben

wird, zur Anwendung. Auf diese Weise wird die Moglichkeit geschaffen, bei Bedarf die Schraub-

und Presskraftdaten der Quellsysteme mit anderweitiger Statistik-Software (z. B. QS-STAT), die

das Q-DAS-Dateiformat als Eingabeformat unterstutzt, zu verarbeiten. Aus technischen Grunden

existiert fur jedes Steuergerat ein Datei-erzeugendes System, so dass die an den einzelnen Steu-

ergeraten einer Montage-Station anfallenden Schraub- und Presskraftdaten jeweils in separaten

Dateien gespeichert werden. Fur die Erfassung der Kombinationsdaten, der Shim-Daten sowie

der Ausschleusungsdaten sind ebenfalls die Lieferanten der jeweiligen Vorrichtung verantwort-

lich. Zur Erfassung der Kombinationsdaten wird das bestehende Datenhaltungssystem (vgl. Ab-

schnitt 2.6) dahingehend modifiziert, dass das in Abschnitt 4.4 beschriebene Dateiformat erzeugt

wird. Fur Shim-Daten und Ausschleusungsdaten bestehen zum Bearbeitungszeitpunkt der Arbeit

noch keine Datenhaltungssysteme. Fur diese Datenarten wird jeweils ein Datei-erzeugendes Sys-

tem eingerichtet. Die Dateiformate, die dabei zur Anwendung kommen, werden in den Abschnit-

ten 4.5 und 4.6 beschrieben.

19

KAPITEL 4. DATENERFASSUNG UND DATENUBERTRAGUNG 20

Station Anzahl Datei-erzeugende Syste-me

Anzahl Dateien(periodisch, Peri-odendauer: achtStunden)

Anzahl Dateien(sofort)

ST040 5 5 1750ST110 6 6 2100ST120 10 10 3500ST140 5 5 1750ST150 1 1 350ST160 4 4 1400ST300 1 1 350

Tabelle 4.1: Anzahl erzeugter Dateien in einem Zeitraum von acht Stunden bei einer Durchsatzratevon 350 Getrieben in acht Stunden)

4.2 Periodische versus sofortige Datenubertragung

Die Ubertragung der an den Montage-Stationen anfallenden Daten zum Server erfolgt automati-

siert in Form von Textdateien mittels des File-Transfer-Protocols (FTP). Zu Beginn dieser Arbeit

ist ungeklart, ob die Datenubertragung sofort oder periodisch erfolgen soll. Andere Verfahrenswei-

sen sind aus technischen und unternehmenspolitischen Grunden von vornherein ausgeschlossen.

Unter der sofortigen Datenubertragung wird in dieser Arbeit eine Verfahrensweise verstanden, bei

der eine Datenubertragung zum Server ausgelost wird, sobald in einem Steuergerat alle Daten

bezuglich eines bearbeiteten Teils eingetroffen sind. Dies bedeutet, dass fur jedes bearbeitete Teil

eine separate Quelldatei erzeugt wird, die sofort nach Speicherung der entsprechenden Daten ab-

geschlossen und zum Server ubertragen wird.

Unter der periodischen Datenubertragung wird in dieser Arbeit eine Verfahrensweise verstanden,

bei der die Datenubertragung zum Server in periodischen Zeitabstanden erfolgt. Dazu werden

alle Daten, die wahrend einer definierten Zeitperiode in einem Steuergerat eintreffen, in einer Da-

tei gespeichert. Nach Ablauf einer Zeitperiode wird diese Datei abgeschlossen und zum Server

ubertragen.

Vorteile der sofortigen Datenubertragung sind die geringere Verlustrate der Daten sowie die gleich-

maßigere Auslastung des Netzwerkes. Nachteilig wirkt sich jedoch das hohe Dateiaufkommen aus,

da als Konsequenz einer sofortigen Datenubertragung pro Steuergerat und bearbeitetem Teil eine

Datei erzeugt wird. Tabelle 4.1 zeigt die Anzahl der innerhalb einer achtstundigen Zeitperiode er-

zeugten Dateien bei einer periodischen Datenubertragung im Vergleich zur Anzahl der im selben

Zeitraum erzeugten Dateien bei einer sofortigen Datenubertragung. Im Falle eines Server- oder


Netzwerkausfalls mussen die im Zeitraum des Ausfalls erzeugten Dateien im lokalen Dateisys-

tem des Rechners an der Montage-Station gepuffert werden. Bei der sofortigen Datenubertragung

wurden je nach Dauer des Ausfalls einige hundert oder gar tausend Dateien anfallen, die nach

Behebung des Ausfalls zum Server ubertragen werden mussten. Die Praxis hat gezeigt, dass eine

Montage-Station dazu nicht in der Lage ist. Erfahrungsgemaß kommt es zu einem Rechnerab-

sturz an der betroffenen Montage-Station, was wiederum den Ausfall der Montage-Station und

zuletzt den Ausfall der gesamten Montagelinie zur Folge hatte. Die Instabilitat der Rechner an den

Montage-Stationen wird durch die Steuerungssoftware der Lieferanten verursacht.

Aufgrund der beschriebenen Nachteile, die sich aus einer sofortigen Datenubertragung ergeben,

wird die periodische Datenubertragung gewahlt. Dazu werden samtliche in einem Steuergerat ein-

treffenden Daten in eine Datei geschrieben, die nach Ablauf einer Schicht abgeschlossen und zum

Server ubertragen wird. Als Periodendauer wird die Dauer einer Schicht (acht Stunden) gewahlt,

weil dadurch die Datenubertragung zwischen zwei Schichten erfolgen kann und damit eine Beein-

trachtigung des Montageprozesses an der Montage-Station als Folge der Datenubertragung ausge-

schlossen werden kann.

Die Lieferanten sind damit beauftragt, unter Berucksichtigung der in den folgenden Abschnitten

beschriebenen Anforderungen an die Dateiformate entsprechende Prozesse zur Datenerfassung

und Datenubertragung einzurichten. Die Verantwortung fur alle Prozesse von der Erfassung bis

zur Ablieferung der Daten auf dem Server verbleibt bei der Abteilung Getriebefertigung.

4.3 Ubertragung der Schraub- und Presskraftdaten

Wie bereits erwahnt, erfolgt die Ubertragung der Schraub- und Presskraftdaten im Q-DAS ASCII-

Transferformat, welches im folgenden Abschnitt naher beschrieben wird. Da das Dateiformat

komplex ist, werden dabei lediglich die fur diese Arbeit relevanten Strukturen des Dateiformats

beschrieben. Das Dateiformat ermoglicht es außerdem, denselben Sachverhalt auf verschiedene

Arten im Bezug auf Struktur und Datenreprasentation darzustellen. Die in den folgenden Ab-

schnitten beschriebene Darstellungsweise ist jene, die mit den Lieferanten vereinbart wurde.

4.3.1 Das Q-DAS ASCII-Transferformat

Das Q-DAS ASCII-Transferformat wurde von der Q-DAS GmbH in Zusammenarbeit mit dem

Automobilhersteller Ford entwickelt und in [6] definiert. Motivation fur die Definition des Trans-

ferformates war, ein einheitliches Dateiformat zum Austausch von Qualitatsdaten zwischen ver-

schiedenen Systemen zu bieten. Dabei sollte sich das Dateiformat insbesondere durch folgende

Eigenschaften auszeichnen [6]:

Transparenz Es sollte einen einfachen und transparenten Aufbau haben, welches fur den Anwen-


Abbildung 4.1: Grundstruktur des Q-DAS ASCII-Transferformats (Zeichnung angelehnt an [6])

der leserlich und editierbar ist.

Flexibilitat Es sollte so flexibel sein, dass man beliebig viele Inhalte und somit beliebig viele

Qualitatsmerkmale von verschiedenen Teilen erfassen kann.

Komprimierbarkeit Der Inhalt einer Q-DAS-Datei sollte sich gut komprimieren lassen.

Mittlerweile hat sich das Dateiformat zum weltweiten Standard insbesondere in der Automobil-

industrie etabliert. Neben dem Q-DAS ASCII-Transferformat wurde neuerdings auch ein XML-

basiertes Format QML zur Darstellung von Qualitatsdaten definiert.

Wie aus Abbildung 4.1 ersichtlich, besteht das Q-DAS ASCII-Transferformat aus einem Beschrei-

bungs- und einem Werteteil. Die beiden Teile konnen entweder in zwei getrennte Dateien oder in

eine gemeinsame Datei geschrieben werden. Wahrend eine Datei, die beide Teile beinhaltet, mit

der Endung DFQ gekennzeichnet wird, tragen eine Wertedatei die Endung DFX und eine Beschrei-

bungsdatei die Endung DFD. Um ein zusammengehoriges DFD/DFX-Datei-Paar zuordenbar zu

machen, werden die zusammengehorigen Dateien abgesehen von ihrer Dateiendung gleichnamig

benannt. Sowohl der Beschreibungsteil als auch der Werteteil basieren auf Schlusselfeldern, deren

jeweilige Bedeutung in [6] eindeutig definiert wurde.

Beschreibungsteil

Im Beschreibungsteil werden Informationen abgelegt, die zur Interpretation und Auswertung der

im Werteteil gespeicherten Daten notwendig sind. Dies sind u. a. Informationen uber die Quali-

tatsmerkmale, zu denen Messwerte im Werteteil der Datei gespeichert sind. Ein Qualitatsmerkmal


ist eine qualitatsrelevante Große wie etwa das aufgewendete Drehmoment bei einer Schraubope-

ration. Jedes Schlusselfeld im Beschreibungsteil steht in einer eigenen Zeile und besteht aus einer

Schlusselnummer, gefolgt von einem Leerzeichen und dem eigentlichen Feldinhalt.

Am Anfang des Beschreibungsteils, im so genannten Kopf, befindet sich das Schlusselfeld K0100,

in dem die Gesamtanzahl der im Beschreibungsteil beschriebenen Qualitatsmerkmale hinterlegt

ist. Es folgen jeweils in einem Block die Teiledaten (K1000 - K1999), die Merkmalsdaten (K2000

- K2999), die Prufplandaten (K3000 - K3999), die Verwaltungsdaten (K4000 - K4999) sowie die

Sonstigen Daten (K5000 - K5999). Im Folgenden wird lediglich auf die Merkmalsdaten einge-

gangen, da die ubrigen Daten des Beschreibungsteils fur die Datenauswertung im Rahmen dieser

Arbeit nicht relevant sind.

Wie bereits erwahnt, konnen in einer Q-DAS-Datei Messwerte zu beliebig vielen Qualitatsmerk-

malen gespeichert werden. Mithilfe der Merkmalsdaten werden die Eigenschaften aller Qualitats-

merkmale, zu denen Messwerte bei der Bearbeitung eines Teils erfasst und im Werteteil gespei-

chert wurden, beschrieben. Dies sind z. B. Eigenschaften wie Art der Messgroße, verwendete

Messeinheit oder die Grenzwerte, die fur dieses Qualitatsmerkmal zum Zeitpunkt der Opera-

tion an der Montage-Station eingestellt waren. Zur Beschreibung eines Qualitatsmerkmals die-

nen die Schlusselfelder K2000 - K2999 (z. B. Schlusselfeld K2142 fur die verwendete Messein-

heit). Werden in einer Q-DAS-Datei mehrere Qualitatsmerkmale beschrieben, so werden folg-

lich einige der Schlusselfelder mehrfach verwendet. Um die verwendeten Schlusselfelder ein-

zelnen Qualitatsmerkmalen zuordnen zu konnen, werden die beschriebenen Qualitatsmerkmale

von � bis � durchnummeriert, so dass jedes Qualitatsmerkmal eine eindeutige Merkmalsnum-

mer erhalt. Zur Zuordnung eines Schlusselfeldes zu einem Qualitatsmerkmal wird schließlich die

Schlusselnummer des Schlusselfeldes um die jeweilige Merkmalsnummer erganzt (z. B. K2001/1).

Soll der angegebene Wert eines Schlusselfeldes fur alle Merkmale gelten, kann als Merkmalsnum-

mer der Wert”�“ angegeben werden (z. B. K2001/0).

Werteteil

Bei der Bearbeitung eines Teils wird zu jedem im Beschreibungsteil beschriebenen Qualitats-

merkmal ein Messwert erfasst. Fur jeden Messwert wird im Werteteil ein Werteeintrag angelegt,

der neben dem eigentlichen Messwert noch weitere Schlusselfelder beinhaltet. Tabelle 4.2 zeigt

eine Ubersicht aller Schlusselfelder eines Werteeintrags. Die Feldinhalte der Schlusselfelder ei-

nes Werteeintrags werden in aufsteigender Reihenfolge der Schlusselnummern ohne Angabe die-

ser hintereinander geschrieben und durch das Zeichen”¶“ voneinander getrennt. Keines dieser

Schlusselfelder darf dabei weggelassen werden, wobei jedoch einige von ihnen je nach Anforde-

rung leer sein durfen. Die Werteeintrage der einzelnen Messwerte bezuglich eines bearbeiteten

Teils werden wiederum in aufsteigender Reihenfolge der Merkmalsnummern in eine Zeile hin-

tereinander geschrieben und durch das Zeichen”¤“ voneinander getrennt. Seriennummern im

Schlusselfeld K0006 wird grundsatzlich das Zeichen”#“ vorangestellt. Der �-te Werteeintrag ei-


Schlusselfeld Schlussel Bedeutung

Messwert K0001 der erfasste MesswertAttribut K0002 ein Fehlercode (ein Wert ungleich

”0“ bedeutet, dass die

Operation fehlgeschlagen ist)Datum/Zeit K0004 ein Zeitstempel, der den genauen Zeitpunkt der Operation

bzw. der Messung angibtEreignis K0005 (nicht relevant)Seriennummer K0006 die Seriennummer des bearbeiteten TeilsSpindelnummer K0007 die Nummer der Spindel, an der die Operation durch-

gefuhrt wurdeStation K0008 die Nummer der Montage-Station, an der die Operation

durchgefuhrt wurdeMaschine K0010 (nicht relevant)Prufmittel K0012 (nicht relevant)

Tabelle 4.2: Schlusselfelder eines Werteeintrags

ner Zeile ist mit denjenigen Merkmalsdaten in Verbindung zu bringen, die im Beschreibungsteil

mit der Merkmalsnummer � versehen sind. Jede Zeile beinhaltet also so viele Werteeintrage, wie

Qualitatsmerkmale definiert wurden, womit jede Zeile samtliche Qualitatsdaten beinhaltet, die bei

der Bearbeitung genau eines Teils gespeichert wurden.

4.3.2 DFD/DFX versus DFQ

Es wird die Variante mit einer gemeinsamen DFQ-Datei gewahlt, da dadurch die Zahl der zu

verarbeitenden Dateien nicht unnotig verdoppelt wird und zum anderen das einander Zuordnen

der DFD/DFX-Paare entfallt. Die gewahlte Variante ist demnach effizienter und weniger feh-

leranfallig.

4.3.3 Anforderungen an die zu erzeugenden DFQ-Dateien

Wie in Abschnitt 4.1 erwahnt, sind fur die Datei-erzeugenden Systeme die Lieferanten der jeweili-

gen Fugevorrichtung verantwortlich. Da die Lieferanten weder die gleichen Steuergerate noch die

gleiche Steuerungssoftware verwenden und damit unterschiedliche technische Grundvorausset-

zungen haben, ergeben sich zwischen den DFQ-Dateien fur Schraub- und Presskraftdaten Unter-

schiede bezuglich ihrer Merkmalsstruktur. Die Schlusselfelder, die bei der Speicherung eines Qua-

litatsmerkmals von einer in der Montagelinie erzeugten DFQ-Datei unterstutzt werden mussen,

wurden in einem fur alle Lieferanten verbindlichen Pflichtenheft (vgl. [5]) definiert. Fur die Da-

tenauswertungen im Rahmen dieser Arbeit ist jedoch nur ein Teil der definierten Schlusselfelder

erforderlich. Die erforderlichen Schlusselfelder sind im Anhang in Tabelle A.2 aufgefuhrt. Im

Folgenden soll auf die Merkmalsstrukturen eingegangen und der Aufbau der DFQ-Dateien an


konkreten Beispielen erlautert werden.

Merkmalsstruktur einer DFQ-Datei mit Schraubkraftdaten (Lieferant Bosch)

Werden an einer Montage-Station Schrauboperationen durchgefuhrt, so verfugt diese Montage-

Station uber genau ein Steuergerat fur alle an der Station befindlichen Schraubspindeln. Demnach

existiert an einer solchen Montage-Station genau ein Datei-erzeugendes System fur alle an der

Montage-Station anfallenden Schraubkraftdaten. Vor dem Hintergrund, dass die Datenubertragung

schichtweise erfolgt, wird an der Montage-Station pro Schicht genau eine Datei erzeugt, in der die

Messungen aller Schraubspindeln der gesamten Schicht gespeichert sind. Da bei jeder Schraubop-

eration zwei Qualitatsmerkmale (Drehwinkel/Drehmoment) erfasst werden, beinhaltet eine DFQ-

Datei einer Montage-Station mit � Schraubspindeln Messwerte zu �� Qualitatsmerkmalen. Die

Qualitatsmerkmale”Drehwinkel“ und

”Drehmoment“ einer Spindel mit der Spindelnummer � er-

halten dabei die Merkmalsnummern �� und ��.

Fallbeispiel: Eine DFQ-Datei mit Schraubkraftdaten

Im Folgenden wird der Aufbau einer DFQ-Datei mit Schraubkraftdaten an einem konkreten Bei-

spiel, welches in Abbildung 4.2 dargestellt ist, beschrieben. Der kursiv dargestellte Text ist nicht

Bestandteil der Datei, er soll lediglich zur Erklarung der einzelnen Zeilen beitragen.

Die Schlusselfelder K0100 bis K2142/4 stellen den Beschreibungsteil der DFQ-Datei dar. Das

Schlusselfeld K0100 bildet den Kopf und gibt die Anzahl der beschriebenen Qualitatsmerkmale

und damit die Anzahl der Messwerte an, die bei der Bearbeitung eines Teils erfasst und im Wer-

teteil gespeichert wurden. Der Wert”4“ impliziert, dass die Montage-Station, an der die Datei

erzeugt wurde, uber zwei Schraubspindeln verfugt. Die Schlusselfelder K2001/1 bis K2142/1

beschreiben die Eigenschaften des ersten Qualitatsmerkmals. Aus dem Schlusselfeld K2001/1

mit dem Wert”0017DW“ lasst sich entnehmen, dass es sich bei diesem Qualitatsmerkmal um

das Merkmal”Drehwinkel“ handelt. Die verschiedenen Codes zur Identifizierung eines Qua-

litatsmerkmals wurden in [1] definiert und sind im Anhang in Tabelle A.1 aufgelistet. Die Schlus-

selfelder K2110/1 und K2111/1 geben den unteren und den oberen Grenzwert an, der fur den

Drehwinkel zum Zeitpunkt der Operation an der Montage-Station eingestellt war. In gleicher

Weise wird mittels der Schlusselfelder K2001/2 bis K2142/2 das zweite Qualitatsmerkmal be-

schrieben. Bei diesem Qualitatsmerkmal handelt es sich um das Merkmal”Drehmoment“. Die

Schlusselfelder K2001/3 bis K2142/3 und K2001/4 bis K2142/4 beschreiben wiederum das dritte

und vierte Qualitatsmerkmal, bei denen es sich um die Merkmale”Drehwinkel“ und

”Drehmo-

ment“ handelt. Laut Vereinbarung mit den Lieferanten sind die ersten beiden Qualitatsmerkmale

der ersten Spindel und das dritte und vierte Qualitatsmerkmal der zweiten Spindel zuzuordnen.

Die Information, welcher Spindel ein Qualitatsmerkmal zuzuordnen ist, lasst sich im Ubrigen

auch aus einem der dem Qualitatsmerkmal zugehorigen Werteeintrage im Werteteil ermitteln, da


jeder Werteeintrag uber ein Schlusselfeld K0007 zur Angabe der Spindel verfugt.

Der Werteteil der DFQ-Datei beginnt nach dem Schlusselfeld K2142/4. Im abgebildeten Beispiel

sind die Messwerte zweier bearbeiteter Getriebe gespeichert. Die zu einem Getriebe erfassten

Messwerte sind in den Werteeintragen der vier Qualitatsmerkmale, die durch das Zeichen”¤“

voneinander getrennt sind, gespeichert. Der �-te Werteeintrag einer Zeile im Werteteil ist dem

�-ten Qualitatsmerkmal aus dem Beschreibungsteil zuzuordnen. Aus den ersten beiden Werteein-

tragen der ersten Zeile im Werteteil geht also hervor, dass das Getriebe mit der Seriennummer

”R–0435467HH“ am 12.01.2004 um 12:33 Uhr von der Spindel mit der Spindelnummer

”1“ be-

arbeitet wurde, der Drehwinkel und das Drehmoment betrugen dabei 70.260796° und 10.978796

Nm. Der Drehwinkel und das Drehmoment bei der Bearbeitung desselben Getriebes an der Spin-

del mit der Spindelnummer”2“ betrugen dagegen 95.045683° und 12.900307 Nm.

Merkmalsstruktur einer DFQ-Datei mit Presskraftdaten (Lieferant Promess)

Werden an einer Montage-Station Pressoperationen durchgefuhrt, so ist jede Pressspindel mit ei-

nem eigenen Steuergerat verbunden. Die Anzahl der Datei-erzeugenden Systeme ist daher iden-

tisch mit der Anzahl der an der Montage-Station befindlichen Pressspindeln, so dass an der Mon-

tage-Station fur jede Spindel pro Schicht eine eigene Datei erzeugt wird. Bei jeder Pressoper-

ation werden zwei Qualitatsmerkmale (Einpresstiefe/Einpresskraft) erfasst. Wird eine Verpres-

sung in zwei Schritten durchgefuhrt, werden fur die zweite Pressoperation zwei weitere Qua-

litatsmerkmale in der DFQ-Datei gespeichert. Die Qualitatsmerkmale”Einpresstiefe“ und

”Ein-

presswinkel“ einer Pressoperation mit der Schrittnummer � erhalten die Merkmalsnummern ��

und ��.

Fallbeispiel: Eine DFQ-Datei mit Presskraftdaten

Abbildung 4.3 zeigt ein Beispiel fur eine DFQ-Datei mit Presskraftdaten. Die Schlusselfelder

K0100 bis K2142/4 stellen den Beschreibungsteil der Datei dar. Der Wert”4“ des Schlusselfeldes

K0100 impliziert, dass die Pressoperation an der ersten Spindel in zwei Schritten erfolgt. Die

Spindelnummer ist aus dem Schlusselfeld K0007 eines der im Werteteil gespeicherten Werteein-

trage zu ermitteln. Die Schlusselfelder K2001/1 bis K2142/1 beschreiben die Eigenschaften des

ersten Qualitatsmerkmals. Aus dem Schlusselfeld K2001/1 mit dem Wert”1503ET“ lasst sich ent-

nehmen, dass es sich bei diesem Qualitatsmerkmal um das Merkmal”Einpresstiefe“ handelt. Die

Schlusselfelder K2110/1 und K2111/1 geben den unteren und den oberen Grenzwert an, der fur

die Einpresstiefe zum Zeitpunkt der Operation an der Montage-Station eingestellt war. In glei-

cher Weise wird mittels der Schlusselfelder K2001/2 bis K2142/2 das zweite Qualitatsmerkmal

beschrieben. Bei diesem Qualitatsmerkmal handelt es sich um das Merkmal”Einpresskraft“. Laut

Vereinbarung mit den Lieferanten sind die ersten beiden Qualitatsmerkmale der ersten Pressope-

ration (Schrittnummer”1“) zuzuordnen. Die Schlusselfelder K2001/3 bis K2142/3 und K2001/4


K0100 4 Anzahl Merkmale in der DateiK2001/1 0017DW Merkmalscode für erstes MerkmalK2110/1 45.0 Unterer Grenzwert für Drehwinkel von Spindel 1K2111/1 105.0 Oberer Grenzwert für Drehwinkel von Spindel 1K2142/1 ˚ Messeinheit für Drehwinkel von Spindel 1K2001/2 1916DM Merkmalscode für zweites MerkmalK2110/2 2.0 Unterer Grenzwert für Drehmoment von Spindel 1K2111/2 12.0 Oberer Grenzwert für Drehmoment von Spindel 1K2142/2 Nm Messeinheit für Drehmoment von Spindel 1K2001/3 0017DW Merkmalscode für drittes MerkmalK2110/3 75.0 Unterer Grenzwert für Drehwinkel von Spindel 2K2111/3 180.0 Oberer Grenzwert für Drehwinkel von Spindel 2K2142/3 ˚ Messeinheit für Drehwinkel von Spindel 2K2001/4 1916DM Merkmalscode für viertes MerkmalK2110/4 10.0 Unterer Grenzwert für Drehmoment von Spindel 2K2111/4 14.0 Oberer Grenzwert für Drehmoment von Spindel 2K2142/4 Nm Messeinheit für Drehmoment von Spindel 270.260796¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶1¶140¶¶¤ 10.978796¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶1¶140¶¶¤ 95.045683¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶2¶140¶¶¤ 12.900307¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶2¶140¶¶89.862006¶0¶12.01.2004/12:35:07¶¶#R--0435468HH¶1¶140¶¶¤ 11.007295¶0¶12.01.2004/12:35:07¶¶#R--0435468HH¶1¶140¶¶¤ 99.003619¶0¶12.01.2004/12:35:07¶¶#R--0435468HH¶2¶140¶¶¤ 13.170942¶0¶12.01.2004/12:35:07¶¶#R--0435468HH¶2¶140¶¶

Abbildung 4.2: Beispiel fur eine DFQ-Datei mit Schraubkraftdaten

bis K2142/4 beschreiben wiederum das dritte und das vierte Qualitatsmerkmal, bei denen es sich

um die Merkmale”Einpresstiefe“ und

”Einpresskraft“ der zweiten Pressoperation (Schrittnummer

”2“) handelt.

Der Werteteil der DFQ-Datei beginnt nach dem Schlusselfeld K2142/4. Im abgebildeten Bei-

spiel sind die Messwerte zweier bearbeiteter Getriebe gespeichert. Die zu dem Getriebe erfas-

sten Messwerte sind in den Werteeintragen der vier Qualitatsmerkmale, die durch das Zeichen”¤“

voneinander getrennt sind, gespeichert. Auch hier ist der �-te Werteeintrag einer Zeile im Werte-

teil dem �-ten Qualitatsmerkmal aus dem Beschreibungsteil zuzuordnen. Aus den ersten beiden

Werteeintragen der ersten Zeile im Werteteil geht also hervor, dass das Getriebe mit der Seri-

ennummer”R–0435467HH“ am 12.01.2004 um 12:33 Uhr zum ersten Mal von der Spindel mit

der Spindelnummer”1“ bearbeitet wurde, die Einpresstiefe und die Einpresskraft betrugen da-

bei 23.265796 mm und 10.278796 kN. Bei der zweiten Bearbeitung desselben Getriebes von der

Spindel mit der Spindelnummer”1“ betrugen die Einpresstiefe und die Einpresskraft 27.145603

mm und 12.800347 kN.


K0100 4 Anzahl Merkmale in der DateiK2001/1 1503ET Merkmalscode für erstes MerkmalK2110/1 20.0 Unterer Grenzwert für Einpresstiefe von Schritt 1K2111/1 130.0 Oberer Grenzwert für Einpresstiefe von Schritt 1K2142/1 mm Messeinheit für Einpresstiefe von Schritt 1K2001/2 1505EK Merkmalscode für zweites MerkmalK2110/2 10 Unterer Grenzwert für Einpresskraft von Schritt 1K2111/2 14 Oberer Grenzwert für Einpresskraft von Schritt 1K2142/2 kN Messeinheit für Einpresskraft von Schritt 1K2001/3 1503ET Merkmalscode für drittes MerkmalK2110/3 20.0 Unterer Grenzwert für Einpresstiefe von Schritt 2K2111/3 130.0 Oberer Grenzwert für Einpresstiefe von Schritt 2K2142/3 mm Messeinheit für Einpresstiefe von Schritt 2K2001/4 1505EK Merkmalscode für viertes MerkmalK2110/4 10 Unterer Grenzwert für Einpresskraft von Schritt 2K2111/4 14 Oberer Grenzwert für Einpresskraft von Schritt 2K2142/4 kN Messeinheit für Einpresskraft von Schritt 223.265796¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶1¶140¶¶¤ 10.278796¶0¶12.01.2004/12:33:56¶¶#R--0435467HH¶1¶140¶¶¤ 27.145663¶0¶12.01.2004/12:34:16¶¶#R--0435467HH¶1¶140¶¶¤ 12.800347¶0¶12.01.2004/12:34:16¶¶#R--0435467HH¶1¶140¶¶27.462006¶0¶12.01.2004/12:34:49¶¶#R--0435468HH¶1¶140¶¶¤ 12.557295¶0¶12.01.2004/12:34:49¶¶#R--0435468HH¶1¶140¶¶¤ 29.993619¶0¶12.01.2004/12:35:12¶¶#R--0435468HH¶1¶140¶¶¤ 13.370342¶0¶12.01.2004/12:35:12¶¶#R--0435468HH¶1¶140¶¶

Abbildung 4.3: Beispiel fur eine DFQ-Datei mit Presskraftdaten

Benamung der DFQ-Dateien

Um zu vermeiden, dass mehrere DFQ-Dateien den gleichen Namen erhalten, was beimUbertragen

an den zentralen Server zum moglichen Uberschreiben einer Datei auf dem Server fuhren konnte,

erfolgt die Namensgebung nach einer Namenskonvention, die in [1] festgelegt wurde und fur alle

Lieferanten verbindlich ist. Die Namenskonvention stellt sicher, dass jede in der Montagelinie

erzeugte DFQ-Datei einen eindeutigen Namen erhalt. Da der Aufbau des Dateinamens fur die

Datenauswertung im Rahmen dieser Arbeit nicht relevant ist, wird auf die Namenskonvention

nicht weiter eingegangen.

4.4 Ubertragung der Kombinationsdaten

Die Kombinationsdaten werden ebenfalls schichtweise von der Station ST140 zum Server uber-

tragen. Dazu wird nach Abschluss einer Schicht die Gesamtheit aller Kombinationsdaten aus der

in Abschnitt 2.6 beschriebenen Tabelle (vgl. Tabelle 2.1) einer Microsoft Access-Datenbank im

CSV-Format exportiert (Full-Dump). Im Gegensatz zu allen anderen Datenarten werden also bei

der Ubertragung der Kombinationsdaten nicht nur die wahrend der vorangegangenen Schicht er-

fassten Daten, sondern alle jemals in der Access-Datenbank erfassten Daten ubertragen. Abbil-

dung 4.4 zeigt einen beispielhaften Auszug aus der CSV-Datei.


R--04165473ML;;;13.01.2004 10:12:23;3C29lgN7;5C29WBnD;5C29nqfD;5C28rC63;4C2CRp93;5C27Rc47;6C22AbiE;6C22TbTC;

R--90000100CE;;12140000001008;13.01.2004 10:18:01;443GRsj1;443GXvEF;443Go9Q2;443HXIDG;443Hp0OJ;443HI7kE;

R--04165475HH;M68102P0010;;13.01.2004 10:37:59;443GVhP0;443GrQh7;443Gr3bE;443HdMZ1;443Hw056;443HuOZG;

Abbildung 4.4: Auszug aus einer Datei mit Kombinationsdaten

4.5 Ubertragung der Shim-Daten

Die Shim-Daten werden an der Station ST150 in eine CSV-Datei geschrieben, die nach Abschluss

einer Schicht abgeschlossen und an den Server ubertragen wird. Wie die DFQ-Dateien erhalten

auch die erzeugten Shim-Dateien einen eindeutigen Dateinamen. Abbildung 4.5 zeigt einen exem-

plarischen Auszug aus einer Shim-Datei. Wahrend die Werte in der zweiten Spalte die ermittelten

Shim-Klassen darstellen, geben die Werte in der dritten Spalte die Getriebekomponente an, fur die

das entsprechende Shim verwendet werden soll.

R--04165473HH;10;HWU;13.01.2004 10:12:23R--04165473HH;11;HWO;13.01.2004 10:12:23R--04165473HH;1;AWE;13.01.2004 10:12:23R--04165473HH;8;DIF;13.01.2004 10:12:23R--04165474HH;12;HWU;13.01.2004 10:37:59

Abbildung 4.5: Auszug aus einer Datei mit Shim-Daten

4.6 Ubertragung der Ausschleusungsdaten

Die Ausschleusungszeitpunkte der einzelnen Getriebe werden an der Station ST300 in eine CSV-

Datei geschrieben, die nach Abschluss einer Schicht an den Server ubertragen wird. Abbildung 4.6

zeigt einen exemplarischen Auszug aus der Datei.

R--04165473HH;13.01.2004 10:12:23R--04165474HH;13.01.2004 10:18:01R--04165475HH;13.01.2004 10:37:59R--04165476HH;13.01.2004 10:45:11

Abbildung 4.6: Auszug aus einer Datei mit Ausschleusungsdaten

Kapitel 5

Grundlagen zur Datenkonsolidierung

Die Datenkonsolidierung dient der Integration der Daten der unterschiedlichen Quellsysteme in

ein einheitliches Zielschema. Da Datenmangel in den Quelldaten die Datenqualitat und dadurch

auch den effektiven Nutzen der Daten verringern konnen, mussen die Quelldaten wahrend des

Integrationsprozesses von Datenmangeln befreit werden. Schließlich soll eine ganzheitliche Sicht

auf moglichst fehlerfreie und in sich schlussige Daten der Quellsysteme zur Verfugung stehen.

Um dieses Ziel zu erreichen, mussen nach Erzeugen der Zieltabellen die in unterschiedlicher Form

vorliegenden Quelldaten transformiert werden, um sie an die Zieltabellen anzupassen. Außerdem

bedarf es zur Erkennung und Beseitigung der Datenmangel einer Datenbereinigung. In diesem

Kapitel wird zunachst der Begriff der Datenqualitat genauer definiert (Abschnitt 5.1) sowie auf

die verschiedenen Arten von Datenmangeln eingegangen (Abschnitt 5.2), die fur die Verringe-

rung der Datenqualitat verantwortlich sein konnen. Im Anschluss daran wird auf den Prozess der

Datentransformation (Abschnitt 5.3) sowie der Datenbereinigung (Abschnitt 5.4) naher eingegan-

gen. Im Abschluss dieses Kapitels (Abschnitt 5.5) wird eine allgemeingultige Vorgehensweise zur

Datenkonsolidierung beschrieben.

5.1 Datenqualitat

Daten dienen der Reprasentation von Tatsachen oder Entitaten aus einem Ausschnitt der Rea-

litat [4]. In dieser Arbeit liegen die Daten einem relationalen Datenmodell zugrunde, in dem

Entitaten der Realitat durch �-Tupel reprasentiert werden und die Attributwerte der Tupel die

Eigenschaften der reprasentierten Entitaten beschreiben. Die Attributwerte werden dabei durch

Zeichenketten codiert. Gleichartige Tupel werden zu jeweils einer Relation zusammengefasst. Die

Tupel einer Relation mussen dem Schema der Relation, dem so genannten Relationen-Schema,

entsprechen. Dies bedeutet, dass die Struktur der Tupel einer Relation durch das zugehorige

Relationen-Schema bestimmt wird. Das Relationen-Schema definiert eine Liste von Attributen

und fur jedes dieser Attribute eine Grammatik, die wiederum die Menge der Zeichenketten de-

30

KAPITEL 5. GRUNDLAGEN ZUR DATENKONSOLIDIERUNG 31

Abbildung 5.1: Hierarchie von Qualitatskriterien nach [4]

finiert, die das jeweilige Attribut als Wert annehmen darf. Die Daten unterliegen damit strengen

Regeln, der so genannten Syntaktik. Die Semantik dagegen beschaftigt sich mit der Bedeutung

dieser Zeichenketten, also mit dem Wissen, welches durch die Daten reprasentiert wird. Ein ef-

fektiver Nutzen der Daten erfordert eine moglichst hohe Datenqualitat. In [10] wird Datenqua-

litat bezeichnet als die Gesamtheit aller Eigenschaften von Daten hinsichtlich der Adaquatheit,

die Anforderungen einer Anwendungssituation zu erfullen. Da die Definition von Datenqualitat

als fitness-for-use in der Praxis nicht Ziel fuhrend ist, bedarf es der Identifizierung von allge-

meingultigen Kriterien von Datenqualitat. In der Literatur finden sich verschiedene Ansatze zur

Definition von Datenqualitatskriterien, die sich in der Methodik zur Bestimmung von Kriterien

unterscheiden. In Abbildung 5.1 ist eine Hierarchie von Qualitatskriterien dargestellt, die aus dem

klassischen Ansatz zur Definition von Datenqualitat hervorgeht. Dieser Ansatz bezieht sowohl die

syntaktischen Eigenschaften (z. B. Einheitlichkeit der Reprasentation) als auch die semantischen

Eigenschaften (z. B. Korrektheit) von Daten ein. Die vorgestellte Hierarchie resultiert aus verschie-

denen Qualitatskriterien, die sich wiederum in weitere Kriterien unterteilen lassen. Sie ist aus [4]

ubernommen und verdient keineswegs den Anspruch auf Vollstandigkeit. Beispielsweise lassen

sich einzelne Qualitatskriterien in weitere noch spezifischere Qualitatskriterien aufteilen. Die fol-

genden Definitionen zu den einzelnen Qualitatskriterien sind ebenfalls aus [4] ubernommen.

• Vollstandigkeit ist die Eigenschaft, dass in einem Tupel alle Attributwerte vorhanden sind.

Daruber hinaus kann unter Vollstandigkeit auch die Eigenschaft verstanden werden, dass

alle in der abgebildeten Realitat vorkommenden Entitaten im Datenbestand reprasentiert

sind.

• Gultigkeit ist die Eigenschaft, dass jedes Tupel im Datenbestand eine Entitat reprasentiert,

die auch tatsachlich in der abgebildeten Realitat existiert.

• Integritat ist die Eigenschaft, dass alle und nur diejenigen Entitaten, die in der Realitat


existieren, von einem Tupel im Datenbestand reprasentiert werden.

• Einheitlichkeit ist die Eigenschaft, dass alle Werte innerhalb eines Attributs einheitlich ver-

wendet werden und daher gleichartig interpretiert werden konnen.

• Schema-Konformitat ist die Eigenschaft, dass jedes Tupel zum Schema seiner Relation kon-

form ist. Dies bedeutet, dass jedes Tupel im Bezug auf seine Struktur und seine Werte syn-

taktisch korrekt ist.

• Konsistenz ist die Eigenschaft, dass die Tupel im Datenbestand syntaktisch korrekt sind und

keine Unregelmaßigkeiten aufweisen.

• Korrektheit ist die Eigenschaft, dass eine genaue, einheitliche und vollstandige Reprasenta-

tion der abgebildeten Realitat vorliegt. In diesem Fall sind alle der bisher genannten Krite-

rien erfullt.

• Eindeutigkeit ist die Eigenschaft, dass im Datenbestand keine Duplikate existieren. Als Du-

plikate werden Tupel verstanden, die dieselbe Entitat der abgebildeten Realitat reprasentieren,

aber nicht notwendigerweise in allen Attributen ubereinstimmen.

Daten, die korrekt und eindeutig sind und dabei die einzelnen Kriterien zu 100% erfullen, stellen

ein prazises Abbild der Realitat dar und sind daher Daten von hochster Qualitat. Unter Praxisbe-

dingungen variiert gewohnlich der Erfullungsgrad einzelner Kriterien und der Erfullungsgrad von

100% kann oft nicht erreicht werden. Metriken, auf deren Basis Erfullungsgrade von Kriterien be-

stimmt werden konnen und damit letztlich die Qualitat von Daten gemessen werden kann, werden

nicht eingefuhrt.

5.2 Datenqualitatsprobleme

Ein Datenqualitatsproblem besteht, wenn Daten aufgrund ihrer Eigenschaften den in Abschnitt 5.1

beschriebenen Qualitatskriterien nicht genugen und infolge dessen die Datenqualitat verringert

ist. Das Erkennen von Daten, die den Qualitatskriterien nicht genugen, und das Identifizieren

der Ursachen bzw. der Verursacher stellt eine wesentliche Grundlage fur Maßnahmen zur Ver-

besserung der Qualitat von Daten dar. In [2] wird bei Datenqualitatsproblemen zwischen Single

Source- und Multi Source-Problemen unterschieden. Single Source-Probleme resultieren aus Da-

tenmangeln, die bereits bei der Integration von Daten einer Datenquelle auftreten konnen. Multi

Source-Probleme resultieren dagegen aus Datenmangeln, die im direkten Zusammenhang mit der

Integration von Daten mehrerer Datenquellen stehen. Innerhalb beider Problembereiche wird wie-

derum zwischen schema- und instanzbezogenen Problemen unterschieden. Die Klassifizierung

nach [2] ist in Abbildung 5.2 dargestellt.


Abbildung 5.2: Klassifizierung von Qualitatsproblemen nach [2]

5.2.1 Single Source-Probleme

Single Source-Probleme werden haufig durch eine fehlerhafte Datenerfassung verursacht. Eine

Vielzahl moglicher Fehlerarten steht im Zusammenhang mit einer manuellen Dateneingabe. Auf

diese Fehlerarten wird nicht weiter eingegangen, da die Datenerfassung im Rahmen dieser Arbeit

ausschließlich automatisch erfolgt. Bei der automatischen Datenerfassung konnen durch Fehlfunk-

tionen der Erfassungssysteme (z. B. Messsysteme) falsche Werte zuruckgeliefert werden. Daruber

hinaus konnen auch der Erfassung nachgeschaltete Datenverarbeitungsprozesse fur Datenmangel

verantwortlich sein. Eine unzureichende Eingabe bzw. Integritatskontrolle (vgl. Abschnitt 5.4.2)

kann die unterschiedlichen Datenmangel begunstigen, da in diesem Fall ungultige Dateneingaben

von der Applikation oder von dem Datenhaltungssystem nicht zuruckgewiesen werden.

Single Source-Probleme, die durch ein verbessertes Schemadesign oder eine verbesserte Inte-

gritatskontrolle vermieden werden konnen, werden als schemabezogene Single Source-Probleme

bezeichnet. Diese Probleme treten insbesondere in Quellsystemen mit einer Textdateibasierten

Datenhaltung auf, da in diesem Fall ein Schema im eigentlichen Sinne nicht existiert, sondern le-

diglich Restriktionen zu Format und Struktur der Daten bestehen, deren Einhaltung jedoch nicht

uberpruft wird. Erfolgt die Datenhaltung in einem Datenbanksystem, sind die Qualitatsprobleme

haufig auf ein mangelhaftes Schemadesign oder auf die ungenugende Verwendung von Integritats-

Constraints zuruckzufuhren [2]. Letzteres geschieht in der Regel, um den mit der Verwendung von

Integritats-Constraints verbundenen Overhead klein zuhalten. Schemabezogene Qualitatsprobleme


sind grundsatzlich auch auf Instanzebene sichtbar. Im Folgenden werden einige schemabezogene

Single Source-Probleme erlautert, die im Rahmen dieser Arbeit relevant sind.

Wert außerhalb des zulassigen Wertebereichs Werte, die außerhalb des Wertebereichs des ent-

sprechenden Attributs liegen, sind unzulassige Werte und verletzen das Kriterium der Schema-

Konformitat.

Beispiel: timestamp = 30.13.2004

Ungultige Kombination von Attributwerten In diesem Fall ist aufgrund der Kombination der

Attributwerte eine Integritatsbedingung verletzt. Dies ist beispielsweise der Fall, wenn eine

funktionale Abhangigkeit zwischen zwei oder mehreren Attributen durch die Attributwer-

te nicht erfullt und somit ein Widerspruch erzeugt wird. Eine funktionale Abhangigkeit

besteht, wenn ein Attributwert von einem Wert eines anderen Attributs bestimmt wird. In

diesem Fall ist das Kriterium der Gultigkeit verletzt.

Beispiel: age = 22, birth date = 10.02.1977, current date = 14.08.2004

Fehlender Wert Wenn zu einem Attribut kein Wert angegeben ist, obwohl die Angabe eines Wer-

tes fur das betroffene Attribut verpflichtend ist, wird das Kriterium der Vollstandigkeit ver-

letzt.

Nichteindeutigkeit von Schlusseln Das Kriterium der (Schlussel-)Eindeutigkeit wird verletzt durch

das doppelte Vorkommen eines Wertes in einem Attribut, welches den Primarschlussel dar-

stellt.

Beispiel: emp1 = (id = 1, name = smith)

emp2 = (id = 1, name = miller)

Verletzung der referentiellen Integritat Die referentielle Integegritat wird verletzt, wenn ein

durch den Fremdschlussel referenziertes Tupel nicht existiert.

Beispiel: emp1 = (id = 1, name = smith)

id = 1 existiert in der Master-Relation nicht

Instanzbezogene Single Source-Probleme resultieren aus Datenmangeln, die auch durch eine um-

fassende Eingabe- bzw. Integritatskontrolle nicht vermieden werden konnen. Im Folgenden sind

einige instanzbezogene Single Source-Probleme aufgefuhrt.


Falscher Wert Falsche Werte sind Werte, die zwar keine Integritatsbedingungen verletzen, aber

dennoch falsch sind, weil sie die Realitat nicht korrekt abbilden. Falsche Werte sind in erster

Linie auf eine falsche Erfassung (z. B. Tipp- oder Messfehler) zuruckzufuhren und verletzen

das Kriterium der Gultigkeit.

Fehlender Wert Bei Attributen, fur die die Angabe eines Wertes nicht verpflichtend ist, erweist

sich die unterschiedliche Semantik von nicht vorhandenen Angaben als problematisch, da

das Fehlen eines Wertes auf drei verschiedene Arten interpretiert werden kann:

1. Es gibt in der Realitat keinen Wert fur das betroffene Attribut.

2. Es gibt in der Realitat einen Wert fur das betroffene Attribut, jedoch war der Wert bei

Erfassung des Datensatzes nicht bekannt.

3. Es ist nicht bekannt, ob es in der Realitat ein Wert fur das betroffene Attribut existiert.

In den beiden letzteren Fallen ist das Kriterium der Vollstandigkeit verletzt.

Fehlendes Tupel Aufgrund des Fehlens eines ganzen Tupel ist das Kriterium der Vollstandigkeit

verletzt.

Duplikate Duplikate treten auf, wenn die gleiche Entitat aus der Realitat durch zwei Tupel re-

prasentiert wird, deren Attributwerte nicht notwendigerweise identisch sind. In diesem Fall

wird das Kriterium der Eindeutigkeit verletzt.

Beispiel: emp1 = (id = 1, name = john smith)

emp2 = (id = 2, name = j. smith)

Aus den genannten Beispielen ist ersichtlich, dass Single Source-Probleme eine unterschiedliche

Tragweite haben konnen. Die verschiedenen Probleme konnen sich uber einzelne Attribute, uber

mehrere Attribute eines Tupels oder uber den gesamten Datenbestand der Quelle erstrecken. Dem-

nach konnen Datenmangel eine unterschiedliche Komplexitat aufweisen.

Wie bereits erwahnt, werden die Datenmangel in erster Linie durch eine fehlerhafte Erfassung

erzeugt. Werden die Quelldaten uber ein Netzwerk ubertragen, konnen Ubertragungsfehler Da-

tenmangel verursachen (z. B. fehlerhafte Werte in Textdateien infolge einer fehlerhaften FTP-

Ubertragung). Fehlerhafte Datenverarbeitungsprozesse zur Vor- bzw. Nachbereitung der Daten-

ubertragung (z. B. Export aus einer Datenbank) konnen wiederum Mangel an den Daten zur Folge

haben.

In [4] wird unter den Datenmangeln zwischen syntaktischen und semantischen Fehlern unterschie-

den. Ein syntaktischer Fehler bezieht sich immer auf die Struktur der Tupel oder auf das Format

der Werte, die zur Reprasentation von Entitateneigenschaften verwendet werden. Ein syntaktischer


Fehler liegt beispielsweise vor, wenn ein Tupel nicht die erwartete Anzahl von Attributen besitzt

oder ein verwendeter Attributwert nicht im Wertebereich des entsprechenden Attributs liegt. Se-

mantisch falsche Daten dagegen sind zwar syntaktisch korrekt, bilden jedoch die Realitat nicht

korrekt ab. Semantisch falsche Daten liegen beispielsweise dann vor, wenn Integritatsbedingungen

verletzt werden, Duplikate existieren oder Tupel falsche Werte aufweisen.

5.2.2 Multi Source-Probleme

Wenn Daten aus verschiedenen Quellen in ein einheitliches Zielschema integriert werden, konnen

zusatzlich zu den Single Source-Problemen weitere Probleme entstehen, die als Multi Source-

Probleme bezeichnet werden. Multi Source-Probleme konnen durch eine starke Heterogenitat der

Quellen im Bezug auf die verwendeten Datenhaltungssysteme und Schemata verursacht werden.

Heterogene Systemlandschaften existieren haufig, wenn die Systemlandschaft historisch gewach-

sen ist und die einzelnen Quellsysteme unabhangig voneinander von verschiedenen Organisati-

onseinheiten entwickelt wurden und dabei jedes Quellsystem speziell an die Bedurfnisse der je-

weiligen Organisationseinheit angepasst wurde.

Auf der Schemaebene kann eine heterogene Systemlandschaft zu strukturellen Konflikten fuhren.

Strukturelle Konflikte resultieren aus unterschiedlichen Modellierungen eines Sachverhaltes (z. B.

unterschiedliche Datentypen, Speichern von mehreren Werten in einem Attribut, statt in getrenn-

ten Attributen).

Auf Instanzebene konnen Attribute unterschiedlicher Quellen trotz gleichen Datentyps unterschied-

lich reprasentiert sein. Dies tritt beispielsweise auf, wenn in den verschiedenen Quellen ein unter-

schiedliches Datumsformat verwendet wird.

Beispiel: Quelle 1: timestamp = 11.12.1977

Quelle 2: timestamp = 1977-12-11

Außerdem kann es vorkommen, dass Werte unterschiedlich interpretiert werden mussen, wenn et-

wa bei Messwerten eine nicht einheitliche Messeinheit verwendet wird. Beim Zusammenfuhren

von Daten aus verschiedenen Quellen konnen Duplikate auftreten, wenn Tupel aus verschiedenen

Quellen die gleiche Entitat in der Realitat reprasentieren. Haufig tritt jedoch in diesem Fall nur

eine teilweise Uberlappung der Tupel auf, da sie je nach Aufgabe der jeweiligen Datenquelle ver-

schiedene Informationen beinhalten. Nicht zuletzt konnen Werte aus verschiedenen Quellen einen

logischen Widerspruch erzeugen, wenn etwa die Datenerfasser der verschiedenen Quellsysteme

uber einen unterschiedlichen Wissensstand bezuglich eines Sachverhaltes verfugen oder infolge

einer mangelnden Zeitsynchronisation der Quellsysteme logisch widerspruchliche Datums- und

Zeitangaben gespeichert werden.


5.3 Datentransformation

Ein Bestandteil der Datenintegration ist die Transformation der Quelldaten, um die Daten der

einzelnen Quellsysteme hinsichtlich ihrer Reprasentation aneinander anzugleichen und an das

einheitliche Zielschema anzupassen. Mithilfe von Datentransformationen werden demnach Multi

Source-Probleme beseitigt, die durch eine uneinheitliche Reprasentation oder auch durch struk-

turelle Konflikte verursacht werden. Der gesamte Vorgang geschieht in der Regel anhand fest

definierter Transformationsregeln. Im Folgenden werden einige Beispiele fur Datentransforma-

tionen aufgefuhrt. Dabei geht es ausschließlich um die Transformation von Daten, nicht um die

Transformation von Datenstrukturen bzw. Schemata. Ein definiertes Zielschema, ggf. als Resul-

tat einer abgeschlossenen Schemaintegration, ist dafur eine unverzichtbare Vorraussetzung (vgl.

Abschnitt 5.5.2).

Anpassung des Datentyps

Falls der Datentyp eines Quellattributs nicht mit dem des entsprechenden Zielattributs uberein-

stimmt, ist eine Konvertierung der Attributwerte erforderlich. z. B.:

Zeichenkette � Datum

Zeichenkette � Zahl

Anpassung der Datenreprasentation

Manchmal wird ein bestimmtes Merkmal im Quellsystem anders reprasentiert als im Zielsystem

z. B.:

Quellsystem M (Mannlich)

F (Weiblich)

Zielsystem M (Mannlich)

W (Weiblich)

Hier muss die Reprasentation der Quelldaten an die des Zielsystems angepasst werden.

Angleichung der Messeinheit

Numerische Merkmalsauspragungen besitzen in der Regel eine Messeinheit. Dabei kann die in

einem Quellattribut verwendete Messeinheit von der im Zielattribut benotigten abweichen. In die-

sem Fall ist eine Umrechnung zur Angleichung erforderlich. z. B.:

cm � m


Separierung und Kombination von Attributwerten

Manchmal kann es vorkommen, dass in den Quellsystemen zusammengefasste Attributwerte im

Zielsystem in einzelne Attribute aufgespaltet werden mussen. Diesen Vorgang nennt man Separie-

rung, wahrend der umgekehrte Fall, das Zusammenfugen von einzelnen Attributen aus den Quel-

len als Kombination von Attributwerten bezeichnet wird. Die Zerlegung beziehungsweise Kom-

bination von Attributen kann nach einer vorher festgelegten Regel oder Berechnungsvorschrift

geschehen.

5.4 Datenbereinigung

Ein weiterer Bestandteil der Datenintegration ist die Bereinigung der Quelldaten. Der Prozess der

Datenbereinigung ist in der Literatur nicht einheitlich definiert. Allgemein versteht man unter einer

Datenbereinigung die Durchfuhrung verschiedener Maßnahmen mit dem Zweck samtliche Fehler

und Ungereimtheiten zu erkennen und zu beseitigen, um ein korrektes und eindeutiges Abbild

der Realitat zu erhalten [4]. Ursprunglich zielte die Datenbereinigung auf die Eliminierung von

Duplikaten ab (z. B. Sorted-Neighbourhood-Methode), die insbesondere bei der Integration von

Daten aus verschiedenen Quellen auftreten konnen. Infolge dessen ist die Datenbereinigung zu

einem elementaren Bestandteil der Datenintegration geworden. Eine universelle Methode fur eine

umfassende und vollstandige Datenbereinigung existiert nicht. Stattdessen existiert zur Datenbe-

reinigung eine Vielzahl verschiedener Methoden, die jeweils auf die Behebung eines bestimmten

Qualitatsproblems abzielen. Darunter existieren Methoden sowohl zur Erkennung von Datenfeh-

lern als auch zur Korrektur von falschen oder fehlenden Werten. Weist ein Datenbestand mehrere

unterschiedliche Qualitatsprobleme auf, so mussen zur vollstandigen Datenbereinigung verschie-

dene Methoden in angemessener Weise miteinander kombiniert werden. Die Bereinigung von Da-

ten erfordert grundsatzlich ein gutes Wissen uber die Daten bzw. den abzubildenden Sachverhalt,

deshalb hangt der Erfolg der Datenbereinigung vor allem vom verfugbaren Wissen ab. Insbesonde-

re wenn statistische Verfahren (vgl. Abschnitt 5.4.3) zur Anwendung kommen, kann die Datenbe-

reinigung nur mit einer gewissen Fehlerwahrscheinlichkeit erfolgen. Aus diesem Grund ist haufig

eine handische Nachbearbeitung der als fehlerhaft identifizierten Daten notwendig, weshalb der

Prozess der Datenbereinigung auch als semi-automatisch bezeichnet wird. In den folgenden Ab-

schnitten werden Methoden vorgestellt, die bei der Datenbereinigung zur Anwendung kommen.

Dabei werden nur jene Methoden vorgestellt, die zur weiteren Argumentation in dieser Arbeit re-

levant sind. Methoden zur Korrektur von Daten werden nicht erlautert, da falsche oder fehlende

Werte laut Anforderungen nicht korrigiert werden sollen. Stattdessen sollen die betroffenen Tupel

ignoriert bzw. in einen Fehler-Report geschrieben werden.


5.4.1 Parsen

Zum wirksamen Erkennen von syntaktischen Fehlern eignen sich Parser [4]. Ein Parser fur eine

Grammatik � ist ein Programm, das entscheidet, ob ein gegebenes Wort ein Element der durch

die Grammatik � definierten Sprache ist. Im Kontext der Datenbereinigung werden Parser zum

Einlesen von Quelldateien und zur Uberprufung ihrer Dateistruktur eingesetzt. Daruber hinaus

kann mithilfe von Parsern entschieden werden, ob die Struktur eines Tupels der erwarteten Struktur

entspricht und die einzelnen Attributwerte in den entsprechenden Wertemengen enthalten sind.

Auf diese Weise konnen mit einer hohen Zuverlassigkeit Daten erkannt werden, die das Kriterium

der Schema-Konformitat verletzen.

5.4.2 Integritatskontrolle

Eine Moglichkeit, fehlerhafte Daten zu erkennen, besteht in der Uberprufung der Daten im Hin-

blick auf das Erfullen der geltenden Integritatsbedingungen.

Daten besitzen zu jeder Zeit eine bestimmte Konfiguration von Attributwerten mit dem Zweck

einen Sachverhalt aus der Realitat abzubilden. Da die Realitat bestimmten Einschrankungen und

Regeln unterliegt (z. B. kann die aufgewendete Kraft bei einem Einpressvorgang immer nur po-

sitiv sein), stellen nicht alle moglichen Konfigurationen von Attributwerten ein korrektes Ab-

bild der Realitat dar. Daher werden uber die Definition des Datenmodells hinaus statische Inte-

gritatsbedingungen definiert, die in ihrer Gesamtheit die Menge aller zulassigen Attributwertkom-

binationen definieren. Attributwertkombinationen, die nicht die definierten Integritatsbedingungen

erfullen, sind folglich als fehlerhaft zu bezeichnen. Integritatsbedingungen werden insbesondere

aus funktionalen Abhangigkeiten oder aus applikationsspezifischen Geschaftsregeln (Business-

Rules) abgeleitet. Beispiele fur Geschaftsregeln sind:

• Regeln zur Prufung der Einhaltung von Wertebereichen

• Regeln zur Prufung gultiger Attributwertkombinationen

• Regeln zur Prufung der Einhaltung von Berechnungsvorschriften

• IF ... THEN ... -Regeln

Wie aus den Beispielen ersichtlich, konnen Integritatsbedingungen eine unterschiedliche Trag-

weite haben. Die Bedingungen konnen sich auf einzelne Attribute, mehrere Attribute eines Tupels

oder auch auf Attribute verschiedener Tupel beziehen.

Relationale Datenbanksysteme wie z. B. Oracle bieten mittels der Abfragesprache SQL die Mog-

lichkeit eines deklarativen Weges Integritatsbedingungen (Integritats-Constraints) zu definieren. In

einem solchen Fall wird die Integritatskontrolle durch das Datenbanksystem selbst durchgefuhrt.


Dabei werden schreibende Datenbankzugriffe, die deklarierte Integritatsbedingungen verletzen,

vom Datenbanksystem zuruckgewiesen. Der Vorteil besteht darin, dass es zur Uberprufung der

definierten Integritatsbedingungen keiner applikationsseitigen Implementierung bedarf, was die

Entwicklung der Applikation erheblich vereinfacht.

Im relationalen Datenmodell, dem eine relationale Datenbank zu Grunde liegt, existieren insge-

samt vier verschiedene Arten von Integritatsbedingungen, die im Folgenden kurz beschrieben wer-

den:

Entitats-Integritat Die Entitats-Integritat sichert uber den Primarschlussel die Schlusseleindeu-

tigkeit einer Tabelle. Ein Primarschlussel � einer Tabelle besteht aus einer Teilmenge ihrer

Attribute, so dass niemals zwei Tupel den gleichen Wert fur � besitzen und keine Teilmen-

ge von � existiert, die die Eindeutigkeitseigenschaft besitzt. Alternative Schlussel konnen

zusatzlich als ein UNIQUE-Schlussel deklariert werden. Damit kann gewahrleistet werden,

dass die Werte in bestimmten Spalten oder Spaltenkombinationen eindeutig sind.

Referentielle Integritat Die referentielle Integritat sichert die Gultigkeit eines Verweises zwi-

schen zwei Tabellen uber einen Fremdschlussel. Ein Fremdschlussel bezuglich einer Relati-

on �� ist eine Teilmenge �� von Attributen einer Relation ��, so dass zu jedem Zeitpunkt

fur �� gilt: Zu jedem Wert von �� existiert ein gleicher Wert im Schlusselattribut irgend-

eines Tupels von Relation ��.

Domanenbedingungen Bedingungen dieser Art beziehen sich auf die Werte, die ein Attribut

annehmen darf. Der Datentyp des Attributs wird bereits durch die Spaltendefinition impli-

ziert. Daruber hinaus kann die Menge der moglichen Werte eines Attributs mithilfe einer

CHECK-Klausel (z. B. CHECK (FORCE > 0)) weiter eingeschrankt werden. Durch ein

NOT NULL-Constraint wird verhindert, dass in den entsprechenden Spalten fehlende Werte

vorkommen konnen.

Unternehmensbedingungen Unternehmensbedingungen umfassen alle Integritatsbedingungen,

die nicht durch die bisher genannten Bedingungen abgedeckt werden. Unternehmensbe-

dingungen konnen mithilfe einer CHECK-Klausel definiert werden, sofern sich diese nur

auf Attribute innerhalb eines Tupels beziehen. Komplexere Unternehmensbedingungen, die

sich nicht nur auf Attribute eines Tupels beziehen, lassen sich dagegen mit Triggern realisie-

ren. Ein Trigger in einer Oracle-Datenbank ist im Wesentlichen eine PL/SQL-Prozedur, die

mit einer Tabelle assoziiert ist und automatisch aufgerufen wird, wenn auf der Tabelle eine

beliebige Schreiboperation ausgefuhrt wird. PL/SQL ist eine prozedurale Erweiterung von

Oracle-SQL, die Sprachkonstrukte zur Verfugung stellt, die ahnlich sind mit Konstrukten ei-

ner imperativen Programmiersprache. Damit wird es dem Entwickler ermoglicht, komplexe-

re Anwendungen zu entwickeln, die den Gebrauch von Kontrollstrukturen und prozedurale

Strukturen wie Prozeduren, Funktionen und Module erfordern.


Abbildung 5.3: Ausreißererkennung

Mithilfe der Integritatskontrolle lassen sich alle Fehler erkennen, die in Abschnitt 5.2 im Zu-

sammenhang mit schemabezogenen Single Source-Problemen genannt werden. Der Erfolg der

Integritatskontrolle hangt dabei im hohen Maß von der Grundlichkeit der Analyse der geltenden

Integritatsbedingungen (Integritatsanalyse) ab.

5.4.3 Ausreißererkennung

Ein weiterer Ansatz ungultige Daten zu erkennen, besteht in der Ausreißererkennung. Bei der

Ausreißererkennung werden die zu bereinigenden Daten auf Muster oder Trends hin untersucht,

denen der Großteil dieser Daten entspricht. Daten, die von diesen Mustern oder Trends abwei-

chen, werden als Ausreißer bezeichnet und als potentielle Fehlerkandidaten betrachtet. Auf diese

Weise konnen auch ungultige Daten erkannt werden, die mithilfe des alleinigen Wissens aus der

Integritatsanalyse nicht erkannt werden wurden. Zur Ausreißererkennung existiert eine Vielzahl

von verschiedenen Verfahren, von denen ein Großteil auf Methoden des Data Mining basiert (z. B.

Clustering- oder Assoziationsregel-Algorithmen). Diese Methoden eignen sich gut zur multiva-

riaten Ausreißererkennung, also zur Erkennung von komplexen Fehlern. Voraussetzung fur die

Anwendung dieser Methoden ist jedoch, dass sehr große Datenbestande zur Verfugung stehen [3].

Wie in Abbildung 5.3 schematisch dargestellt, kann bei einfacheren statistischen Verfahren auf

Basis korrekter Beispieldaten ein statistisches Modell erstellt werden, mit dem spater neu ein-

treffende und zu bereinigende Datensatze verglichen werden. Datensatze, die von diesem Modell

abweichen, werden dann als potentielle Ausreißer betrachtet. Zur kontinuierlichen Verbesserung

des Modells empfiehlt es sich, das Modell in regelmaßigen Abstanden zu aktualisieren.


Als Beispiel sei ein statistisches Verfahren zur univariaten Ausreißererkennung erwahnt, welches

sich gut zur Erkennung von Ausreißern unter eindimensionalen Messwerten eignet. Das im Fol-

genden beschriebene Verfahren macht sich die Tschebyscheff-Ungleichung zunutze.

Die Tschebyscheff-Ungleichung lautet

� ��

�

wobei � eine Zufallsvariable ist und die Variablen � und den Durchschnitt und die Standardab-

weichung der Zufallsvariablen � darstellen.

Fur � � � � gilt dann

� ��

��

� fur � ��

�fur � �

�

�fur � �

was beispielsweise bedeutet, dass bei einer Zufallsvariablen � mindestens 75% der Werte im In-

tervall �� liegen (bei speziellen Verteilungen kann dieser Wert bedeutend großer

sein). Demnach weichen Werte, die außerhalb des Intervalls �� liegen, von einem

sehr großen Teil (mindestens 75%) der Daten ab.

Im Kontext der Datenbereinigung lasst sich fur ein Attribut � durch Ermitteln des Durchschnitts

�� und der Standardabweichung � ein statistisches Modell erzeugen. Ein Wert� eines Attributs �

kann dann als Ausreißer in Betracht gezogen werden, wenn fur den Wert� gilt: � � �� oder

� � ��. Der Wert fur muss an den jeweiligen Anwendungsfall und an die Werteverteilung

des Attributs � angepasst werden [3].

5.5 Die Vorgehensweise

Die in diesem Abschnitt beschriebene Vorgehensweise zur Datenkonsolidierung ist im Wesentli-

chen an die in [4] beschriebene Vorgehensweise angelehnt. Danach stellt die Datenkonsolidierung

einen Prozess dar, der folgende Phasen durchlauft:

1. Datenanalyse

2. Definition des gemeinsamen Zielschemas

3. Definition der Datenbereinigungsprozesse

4. Implementierung der Datenbereinigungsprozesse


5. Einlesen der Quelldaten und Ausfuhren der Datenbereinigungsprozesse

Die Datenanalyse dient zur Ermittlung des zur Datenintegration erforderlichen Wissens uber die

Dateneigenschaften sowie die auftretenden Datenqualitatsprobleme. Daraufhin wird das Schema

der Zieldatenbank definiert, welches samtliche Daten aus den Quellsystemen aufnehmen kann.

In der anschließenden Phase zur Definition der Datenbereinigungsprozesse werden Regeln fur

notwendige Datentransformationen definiert, die spater bei der eigentlichen Datenintegration zur

Anpassung der Quelldaten an das Zielschema angewendet werden sowie geeignete Methoden zur

Datenbereinigung gewahlt. Schließlich werden Prozesse definiert, die die zeitliche Abfolge zur

Durchfuhrung der notwendigen Transformationen und Bereinigungsschritte festlegen. Nach er-

folgter Implementierung konnen die Daten durch Ausfuhrung der Datenbereinigungsprozesse ein-

gelesen, konsolidiert und in die Datenbank geladen werden.

Im Regelfall sollen die ersten vier Phasen einmalig und die funfte Phase in regelmaßigen Abstanden

wiederholt durchlaufen werden. Bei Bedarf konnen selbstverstandlich vorangegangene Phasen

wiederholt werden, wenn beispielsweise neue Qualitatsmangel in Erscheinung treten oder es einer

Korrektur bzw. Anderung eines Datenbereinigungsprozesses bedarf. In den folgenden Abschnitten

werden die ersten drei Phasen detaillierter beschrieben.

5.5.1 Datenanalyse

Aufgrund der Verteilung der Daten auf verschiedene Systeme ist es im ersten Schritt erforder-

lich, die im Zielsystem abzubildenden Daten zu identifizieren und zu analysieren. Ziel der Ana-

lyse ist es, moglichst gutes Wissen uber die Inhalte und die Struktur der zu integrierenden Daten

zu gewinnen und dabei mogliche Qualitatsprobleme (vgl. Abschnitt 5.2) aufzudecken. Grundla-

ge fur die Datenanalyse sind Dokumentationen zu den Quellsystemen sowie bereits vorhandene

Beispieldaten. Daruber hinaus konnen auch Interviews mit Sachverstandigen weitere notwendige

Informationen liefern. Der Grad der Analyse der Daten ist je nach Anwendungsfall verschieden

und hangt mitunter davon ab, welche Methoden zur Datenbereinigung angewendet werden. In [2]

werden zwei Ansatze zur Datenanalyse genannt.

Beim ersten Ansatz, der als Data Profiling bezeichnet wird, werden im Sinne eines Meta-Re-

engineering durch Sichten der Daten sowie durch Anwenden von einfachen statistischen Methoden

Metadaten uber die einzelnen Attribute ermittelt. In der Regel werden dabei fur jedes im Rahmen

der Datenintegration relevante Attribut folgende Eigenschaften ermittelt:

• Datentyp

• Wertebereich

• typische Muster von Werten bei Zeichenketten


• Minimale und maximale Lange von Werten

• Minimaler und maximaler Wert bei numerischen Werten

• Vorkommen von Nullwerten

• Eindeutigkeit

• Haufigkeitsverteilung von Werten

• Ermittlung des Durchschnittswertes, des Medians sowie der Standardabweichung bei nu-

merischen Werten

Das Ermitteln der oben genannten Metadaten ist in verschiedener Hinsicht von Bedeutung. Zum

einen stellen die Ergebnisse des Data Profiling eine Grundlage fur die Definition des Zielschemas

sowie von Integritatsbedingungen dar und zum anderen kann das Data Profiling zur Identifizie-

rung von Datenqualitatsproblemen beitragen. Mithilfe der aufgestellten Haufigkeitsverteilungen

und der ermittelten statistischen Kenngroßen wie der Standardabweichung und des Durchschnitts-

wertes konnen spater innerhalb des Datenbereinigungsprozesses falsche Werte (univariate Aus-

reißer) entdeckt werden (vgl. Abschnitt 5.4.3). Statistische Kenngroßen wie Durchschnittswert,

Median und haufigster Wert konnen zur Korrektur von fehlenden oder falschen Werten herange-

zogen werden.

Wie der Vorgang des Data Profiling zur Identifizierung von moglichen Qualitatsproblemen fuhrt,

wird im Folgenden anhand einiger Beispiele erlautert.

Beispiel 1 Tabelle 5.1 zeigt die Statistik eines Attributs, fur welches die Eindeutigkeitseigen-

schaft gilt. Das Abweichen der beiden Werte voneinander zeigt, dass Attributwerte mehrmals vor-

kommen und demnach die Eindeutigkeitseigenschaft verletzt ist.

Anzahl Zeilen 32 056Anzahl verschiedener Werte 32 039

Tabelle 5.1: Statistik zu Beispiel 1

Beispiel 2 In Tabelle 5.2 sind alle in einem Attribut GESCHLECHT vorkommenden Werte so-

wie deren Haufigkeiten aufgefuhrt. Das dreifache Vorkommen des Wertes”S“ lasst auf ungultige

Werte schließen. Handelt es sich bei dem Attribut um ein Pflichtfeld, deuten die Vorkommen des

Wertes NULL auf fehlende Werte in diesem Attribut hin.


Attribut Inhalt Anzahl Vorkommen

GESCHLECHT M 4 657GESCHLECHT W 4 456GESCHLECHT S 3GESCHLECHT NULL 10


Attribut Inhalt der Quelle 1 Inhalt der Quelle 2

GESCHLECHT M MGESCHLECHT W F


Beispiel 3 In Tabelle 5.3 sind zu zwei verschiedenen Quellen jeweils alle in einem Attribut GE-

SCHLECHT vorkommenden Werte aufgefuhrt. Die unterschiedlichen Werte in den beiden Quel-

len, deuten auf eine uneinheitliche Reprasentation der Daten hin.

Bei den bisher erlauterten Analysen werden die einzelnen Attribute immer isoliert voneinander

betrachtet. Aufgrund von applikationsspezifischen Geschaftsregeln existieren haufig aber auch

Abhangigkeiten zwischen Attributen, die sich sowohl auf mehrere Attribute eines Tupels als auch

auf Attribute mehrerer inhaltlich zusammenhangender Tupel erstrecken konnen. Aus diesem Grund

werden auf Basis der geltenden Geschaftsregeln Integritatsbedingungen definiert, anhand derer

fehlerhafte Daten erkannt werden konnen (vgl. Abschnitt 5.4.2).

Ein zweiter Ansatz im Rahmen der Datenanalyse ist die Anwendung von Data Mining-Methoden,

mit deren Hilfe auch Dateneigenschaften (z. B. Trends, Muster, etc.) aufgedeckt werden konnen,

die nicht ohne weiteres aus Geschaftsregeln abgeleitet werden konnen. Die dabei gewonnenen

Informationen uber die Daten konnen zur Erkennung und Korrektur von fehlerhaften Daten ver-

wendet werden.

Datenqualitatsprobleme, die aus Schema- oder Datenkonflikten resultieren, geben Aufschluss uber

die zur Datenintegration notwendigen Datentransformationen. In diesem Zusammenhang mussen

die Quelldaten auch auf redundante Informationen hin untersucht werden. Dabei werden Attribute

in den Quelldaten ermittelt, die moglicherweise gleiche Informationen beinhalten und somit bei

der Zusammenfuhrung der Quelldaten entfernt werden konnen.

5.5.2 Definition des Zielschemas

Unter Berucksichtigung der in der Datenanalyse gewonnenen Informationen uber die Daten der

Quellsysteme und der dokumentierten Anforderungen wird ein normalisiertes Datenmodell er-

stellt, welches in der Lage ist alle zu integrierenden Daten aufzunehmen. Eine aufwandige Sche-


maintegration, bei der die lokalen Schemata aus den Quellsystemen in ein einheitliches Schema

uberfuhrt werden und etwaige strukturelle Konflikte beseitigt werden, erubrigt sich in diesem An-

wendungsfall, da die Datenhaltungssysteme der Quellsysteme auf Textdateien basieren und daher

keine komplexen Schemata besitzen. Auf die Probleme, die mit einer Schemaintegration verbun-

den sein konnen, sowie deren Losungsansatze wird daher nicht weiter eingegangen. Die Anforde-

rungen, die bei einer Schemaintegration an das Zielschema gestellt werden, lassen sich allerdings

auf den vorliegenden Anwendungsfall ubertragen und entsprechend anpassen. Die Anforderungen

sind im Folgenden aufgefuhrt:

• Die in den ursprunglichen Quelldateien enthaltenen Informationen sollen vollstandig uber-

nommen werden (Vollstandigkeit)

• Im Zielschema sollen keine redundanten Strukturen vorkommen (Minimalitat)

• Das Zielschema soll verstandlich sein (Verstandlichkeit)

• Die im Zielschema enthaltenen Informationen mussen aquivalent zu den Informationen in

den Quelldateien sein (Korrektheit)

5.5.3 Definition der Datenbereinigungsprozesse

Basierend auf den Ergebnissen der Datenanalyse wird ein so genannter ETL-Prozess (Extraction,

Transformation, Loading) definiert.

In der Extraktionsphase werden die Quelldaten aus den Quellsystemen extrahiert, an den Server

ubertragen und in die Importtabellen eines vom Zielschema abgegrenzten Datenbeschaffungsbe-

reichs importiert. Die Attribute der Importtabellen ergeben sich aus der Analyse der Quellsysteme

und nehmen die Daten auf, die fur die Integration der Daten in das Zielschema benotigt werden.

Beim Importvorgang werden die Daten in der Regel unverandert ubernommen und gegebenenfalls

archiviert, um uber die Moglichkeit einer Wiederherstellung der Originaldaten zu verfugen.

In der anschließenden Transformationsphase werden die notwendigen Transformationen und Be-

reinigungsschritte durchgefuhrt. Hierzu mussen Regeln fur die notwendigen Datentransformatio-

nen bezuglich Struktur und Reprasentation definiert und geeignete Methoden zur Datenbereini-

gung gewahlt werden. Außerdem muss ein Prozess definiert werden, der die zeitliche Abfolge zur

Durchfuhrung der notwendigen Transformationen und Bereinigungsschritte festlegt. Eine Vorga-

be, in welcher Reihenfolge bestimmte Transformations- und Bereinigungsschritte durchgefuhrt

werden sollten, existiert nicht. Sinnvollerweise erfolgt anfangs eine Uberprufung der Daten im

Hinblick auf die syntaktische Korrektheit, da das Erfullen dieses Kriteriums unumganglich fur die

weitergehende Datenbereinigung ist. Die anschließende Behandlung der einzelnen semantischen

Fehler sollte moglichst in Reihenfolge zunehmender Komplexitat erfolgen. Die Transformation

und Bereinigung der Daten erfolgt gewohnlich in einem ebenfalls vom Zielschema abgegrenz-

ten Transformationsbereich (Staging Area), der aus verschiedenen Zwischentabellen besteht. Auf


diese Weise kann die Aufbereitung der Daten durchgefuhrt werden, ohne dass die Zieltabellen da-

von beeintrachtigt werden. Somit ist gewahrleistet, dass in den Zieltabellen immer nur vollstandig

konsolidierte Daten vorliegen. Nach Durchlaufen der Transformationsphase liegen im Transfor-

mationsbereich die Quelldaten in einer Form vor, wie sie in das Zielschema ubernommen werden

konnen.

In der Ladephase werden die bereinigten Daten schließlich in das Zielsystem ubertragen.

Kapitel 6

Datenkonsolidierung

In diesem Kapitel wird die in Kapitel 5 beschriebene Vorgehensweise zur Datenkonsolidierung auf

den vorliegenden Anwendungsfall angewendet. Im folgenden Abschnitt wird zunachst eine Analy-

se der einzelnen Quellsysteme durchgefuhrt (Abschnitt 6.1). Basierend auf den dabei gewonnenen

Informationen werden im Anschluss ein einheitliches Zielschema erstellt (Abschnitt 6.2) und die

notwendigen Datenbereinigungsprozesse definiert (Abschnitt 6.3). Auf die Implementierung der

Datenbereinigungsprozesse wird in Kapitel 7 eingegangen.

6.1 Datenanalyse

Zur Durchfuhrung der Datenanalyse wurden vorhandene Prozessdaten aus den bestehenden Da-

tenhaltungssystemen in Tabellen einer Oracle-Datenbank importiert. Damit war es moglich, mit-

tels der Abfragesprache SQL einzelne Datenabfragen effizient durchzufuhren, um sich ein Bild

uber die vorhandenen Daten und Qualitatsprobleme zu machen. In den folgenden Abschnitten wer-

den die Metadaten sowie weitere Integritatsbedingungen der einzelnen Quellsysteme aufgefuhrt,

außerdem werden die Single Source-Probleme der Quellsysteme beschrieben. Syntaktisch falsche

oder fehlende Werte konnen in fast allen Quellsystemen vorkommen. Erfolgt am Operationsstand

OP090 ein Austausch einer Komponente aus der Wellenvormontage, konnen der Ersatzkomponen-

te keine Schraub- und Presskraftdatensatze zugeordnet werden, da beim Austausch die virtuelle

Kennung der Ersatzkomponente nicht erfasst wird. Dieser Fall fuhrt demnach zum Verlust von

Schraub- und Presskraftdatensatzen. Die eben genannten Qualitatsprobleme werden in den fol-

genden Abschnitten nicht jedes Mal explizit genannt. Auf Multi Source-Probleme wird in einem

separaten Abschnitt eingegangen.

6.1.1 Kombinationsdaten

Die Metadaten der Kombinationsdaten ergeben sich im Wesentlichen aus [7] und sind in Tabel-

le 6.1 dargestellt. Die Getriebe-Seriennumner besteht aus 13 ASCII-Zeichen und hat folgenden

48

KAPITEL 6. DATENKONSOLIDIERUNG 49

Aufbau:

Stelle Bedeutung

1-3 Kurzel fur das Werk (R-- = Russelsheim)

4+5 Produktionsjahr (verfugt das Getriebe uber eine SAAB-Kunden-Seriennummer, wird

die Angabe fur das Produktionsjahr auf”00“ gesetzt)

6-11 fortlaufende Nummer

12+13 zweistelliger Alpha-Code, der den Getriebetyp angibt

Da die Zusammensetzungen der Kunden-Seriennummern fur diese Arbeit nicht relevant sind, wird

auf diese nicht weiter eingegangen.

Feldname Datentyp Wertebereich Min./Max.Lange

ID OPEL (Getriebe-Seriennummer)

Text wird durch den regularen Aus-druck R–[0-9]�8�[A-Z]�2� be-schrieben

13 / 13

ID FIAT (FIAT-Kunden-Seriennummer)

Text wird durch den regularenAusdruck [0-9]�2�-[0-9]�1�-[0-9]�3�-[0-9]�7� beschrieben

16 / 16

ID SAAB (SAAB-Kunden-Seriennummer)

Text wird durch den re-gularen Ausdruck FM6[0-9]�1�[4,5,B]�1�[A-Z]�5�[0-9]�3� beschrieben

13 / 13

TIMESTAMP (Zeitpunkt derErfassung)

Datum Format: dd.MM.yyyy hh:mm:ss

V ID1 bis V ID6 (Virtuel-le Kennungen der StationenST040, ST060, ST070, ST080,ST110, ST120)

Text achtstellige Zeichenkette 8 / 8

Tabelle 6.1: Metadaten der Kombinationsdaten

Weitere Integritatsbedingungen

• Alle Felder sind eindeutig.

• Abgesehen von den Feldern ID FIAT und ID SAAB sind alle Felder Pflichtfelder.

• Einem Getriebe kann nur eine Kunden-Seriennummer zugewiesen sein� ID FIAT != NULL

XOR ID SAAB != NULL


Single Source-Probleme

Aufgrund von Erfassungsfehlern durch die Software an der Station ST140 weisen die Kombina-

tionsdaten relativ viele fehlende oder abgeschnittene Werte in allen Feldern mit Ausnahme des

Feldes TIMESTAMP auf. In einigen Zeitraumen sind 10% der Datensatze fehlerhaft. Das Feh-

len eines Wertes im Feld ID OPEL tritt offensichtlich auf, wenn ein Getriebe wiederholt in die

Station ST140 eingeschleust wird, da das Einfugen eines Datensatzes mit einer bereits existen-

ten Getriebe-Seriennummer dazu fuhrt, dass der Datensatz zwar eingefugt wird, aber das Feld

ID OPEL leer bleibt. Daruber hinaus fuhrt das wiederholte Einschleusen eines Getriebes an der

Station ST140 und das damit verbundene erneute Erfassen der Kombinationsdaten zur Verletzung

der Eindeutigkeitseigenschaft in den Feldern V ID1, V ID2, V ID3, V ID4, V ID5 und V ID6.

Wird bei einer erneuten Einschleusung ein anderer Wellensatz als bei der vorangegangen Ein-

schleusung verwendet, weisen die Datensatze der beiden Einschleusungen in den Feldern V ID1,

V ID2, V ID3, V ID4, V ID5 und V ID6 unterschiedliche Werte auf.

6.1.2 Presskraftdaten

Obwohl sich die DFQ-Dateien der einzelnen Quellsysteme in ihrer Merkmalsstruktur unterschei-

den, sind die zu einer einzelnen Pressoperation erfassten Datenfelder in allen Quellsystemen iden-

tisch. Aus diesem Grund werden in diesem Abschnitt die Presskraftdaten aller Quellsysteme ge-

meinsam behandelt. In Tabelle 6.2 sind die Metadaten der Presskraftdaten aufgefuhrt. Da die

Felder in den DFQ-Dateien lediglich uber ihre Schlussel identifiziert werden, sind zur besseren

Lesbarkeit zusatzlich frei vergebene Feldnamen angegeben, die spater teilweise auch bei der De-

finition des Zielschemas verwendet werden.

Das Feld PART NUMBER beinhaltet die Seriennummer des bearbeiteten Teils. Stammt der Da-

tensatz von einer Montage-Station aus der Vormontage, so ist die Seriennummer die achtstellige

virtuelle Kennung, ansonsten die 13-stellige Getriebe-Seriennummer. Das Feld ATTRIBUTE spei-

chert einen Fehlercode zwischen 0 und 255. Der Wert”0“ bedeutet, dass die Operation sowie die

Messung erfolgreich waren. Die gultigen Werte fur die Felder STATION und SPINDLE sowie de-

ren gultige Wertekombination ergeben sich aus den gestellten Anforderungen (vgl. Abschnitt 3.2).

An der funften Pressspindel der Station ST110 sowie an allen Pressspindeln der Station ST140

wird jedes Teil zweimal bearbeitet. Hieraus ergeben sich der Wertebereich fur das Feld STEP so-

wie die gultigen Wertekombinationen der Felder STATION, SPINDLE und STEP. Die Werte der

Felder MEASUREMENT VALUE DIM1 (Einpresstiefe) und MEASUREMENT VALUE DIM2

(Einpresskraft) hangen von den Grenzwerteinstellungen an den Montage-Stationen ab, die in

den Feldern LOWER LIMIT DIM1 (Unterer Grenzwert fur Einpresstiefe), UPPER LIMIT DIM1

(Oberer Grenzwert fur die Einpresstiefe), LOWER LIMIT DIM2 (Unterer Grenzwert fur die Ein-

presskraft) und UPPER LIMIT DIM2 (Oberer Grenzwert fur Einpresskraft) ubertragen werden.



K0006 - PART NUMBER(Teile-Seriennummer)

Text wird durch den regularen Aus-druck R–[0-9]�8�[A-Z]�2� be-schrieben; bei Daten, die an denStationen ST040, ST110, ST120erzeugt werden: achtstellige Zei-chenkette

13 / 13bzw. 8 / 8

K0002 - ATTRIBUTE (Fehler-code)

ganzeZahl

[0;255]

K0008 - STATION (Station) Text �040, 110, 120, 140, 160� 3 / 3K0007 - SPINDLE (Spindel) ganze

Zahl[1;9]

STEP (Schritt) ganzeZahl

[1;2]

K0004 - TSTAMP (Erfassungs-datum)

Datum Format: dd.MM.yyyy/hh:mm:ss

K2110 - LOWER LIMIT DIM1(Untere Grenze fur Einpresstie-fe)

Zahl � 0

K2111 - UPPER LIMIT DIM1(Obere Grenze fur Einpresstiefe)

Zahl � 0

K2110 - LOWER LIMIT DIM2(Untere Grenze fur Einpres-skraft)

Zahl

K2111 - UPPER LIMIT DIM2(Obere Grenze fur Einpres-skraft)

Zahl

K0001 - MEASURE-MENT VALUE DIM1(Messwert fur Einpresstie-fe)

Zahl � 0

K0001 - MEASURE-MENT VALUE DIM2(Messwert fur Einpresskraft)

Zahl

Tabelle 6.2: Metadaten der Presskraftdaten


Datensatze erfolgreicher Pressoperationen durfen selbstverstandlich nur Messwerte beinhalten,

die innerhalb der jeweiligen Grenzwerteinstellungen liegen. Im Laufe der Zeit andern sich die

Grenzwerteinstellungen an den Montage-Stationen, so dass sich auch die Werteverteilungen in

den Feldern fur die Einpresstiefe und die Einpresskraft andern. Inwiefern sich die Grenzwertein-

stellungen zukunftig andern werden, lasst sich aufgrund der in der Montagelinie herrschenden

Unwagbarkeiten nicht vorhersagen.

Im Allgemeinen definiert die Abteilung Fertigungsplanung Vorgaben fur die an den Montage-

Stationen einzustellenden Grenzwerte fur die Einpresskraft. Diese Vorgaben werden jedoch von

der Abteilung Getriebefertigung nicht immer eingehalten. Hierfur ist in erster Linie ein gewisser

Interessenskonflikt zwischen den beiden Abteilungen verantwortlich.

Die Abteilung Fertigungsplanung hat ein Interesse an mechanisch einwandfrei funktionierenden

Getrieben in hoher Fertigungsqualitat und gibt der Abteilung Getriebefertigung Grenzwerte fur

die einzelnen Pressoperationen vor, die unverbindliche Richtwerte darstellen. Bei der Vorgabe der

Grenzwerte werden Aspekte der Schaltbarkeit, der Oldichtigkeit und der mechanischen Dauer-

belastbarkeit berucksichtigt. Dies kann bedeuten, dass eine niedrigere Produktionszahl angestrebt

wird, wenn dabei gleichzeitig die Qualitat des einzelnen Getriebes steigt. Vorteile dieses Vorge-

hens sind weniger Garantierucknahmen und geringere Ausschusskosten.

Die Abteilung Getriebefertigung dagegen hat ein Interesse an einer storungsfrei gefertigten hohen

Produktionszahl. Zur Erreichung dieses Ziels wird mit einer geringeren Prazision, also mit brei-

teren Toleranzbereichen produziert, was nicht im Sinne einer hohen Fertigungsqualitat ist, aber

dennoch zu akzeptablen Ergebnissen fuhren kann.

Aufgrund von Informationen seitens der Planungsabteilung kann jedoch die Aussage getroffen

werden, dass sich voraussichtlich die eingestellten Grenzwerte fur die Einpresskraft, unabhangig

von der angestrebten Fertigungsprazision, innerhalb der in Tabelle 6.3 aufgefuhrten Toleranzberei-

che bewegen werden. Werte, die nicht innerhalb der aufgefuhrten Toleranzbereiche liegen, konnen

also als falsche Werte (z. B. durch Erfassungs- oder Ubertragungsfehler verursacht) betrachtet

werden. Analysen von Beispieldaten haben allerdings ergeben, dass bei vereinzelten Spindeln der

Wert fur den unteren Grenzwert fur die Einpresskraft beabsichtigt im negativen Bereich liegt.

Grenzwerteinstellungen im negativen Bereich sind physikalisch unsinnig und werden lediglich

aus betriebstechnischen Grunden vorgenommen. Aus diesem Grund wird der Wertebereich fur

das Feld LOWER LIMIT DIM2 (Unterer Grenzwert fur die Einpresskraft) in den negativen Be-

reich ausgedehnt.

In welchen Bereichen sich die an den Montage-Stationen eingestellten Grenzwerte fur die Ein-

presstiefe und damit auch die Messwerte fur die Einpresstiefe bewegen werden, lasst sich aus

heutiger Sicht nicht beurteilen. Die an den Montage-Stationen eingestellten Grenzwerte fur die

Einpresstiefe werden von der Abteilung Getriebefertigung bestimmt und konnen sich ebenfalls

im Laufe der Zeit aufgrund verschiedener betriebsbedingter Faktoren andern. Fur die Grenzwerte

der Einpresstiefe existieren auch keine Vorgaben seitens der Abteilung Fertigungsplanung, da die


Station Spindel ToleranzbereichAnpresskraft(kN)

Station Spindel ToleranzbereichAnpresskraft(kN)

ST040 1 ]0;15] ST120 7 ]0;10]ST110 1 ]0;8] ST120 8 ]0;10]ST110 2 ]0;8] ST120 9 ]0;8]ST110 3 ]0;8] ST140 1 ]0;10]ST110 4 ]0;8] ST140 2 ]0;10]ST110 5 ]0;8] ST140 3 ]0;10]ST120 1 ]0;8] ST140 4 ]0;10]ST120 2 ]0;8] ST160 1 ]0;15]ST120 3 ]0;8] ST160 2 ]0;10]ST120 4 ]0;8] ST160 3 ]0;10]ST120 5 ]0;10] ST160 4 ]0;10]ST120 6 ]0;10]

Tabelle 6.3: Toleranzbereiche fur Pressoperationen

Werte fur die Einpresstiefe keine hohe Relevanz haben. Entscheidend ist, dass bei einer Operation

die angestrebte Einpresskraft erreicht wird, um die ausreichende Festigkeit der Pressverbindung

zu gewahrleisten. Aufgrund der genannten Unwagbarkeiten in der Montagelinie lassen sich also

anhand von Beispieldaten keine Aussagen uber die Werteverteilung in den genannten Feldern so-

wie uber die Beziehung zwischen den Feldern fur die Einpresstiefe und die Einpresskraft treffen.

Aus diesem Grund soll auf weitere statistische Analysen der Presskraftdaten verzichtet werden.


1. Alle Felder sind Pflichtfelder.

2. Fur die Kombination der Felder (PART NUMBER, STATION, SPINDLE, STEP) gilt die

Eindeutigkeitseigenschaft.

3. Der Messwert fur die Einpresstiefe liegt zwischen dem unteren und dem oberen Grenzwert

fur die Einpresstiefe

� LOWER LIMIT DIM1 �MEASURING VALUE DIM1 � UPPER LIMIT DIM1

4. Der Messwert fur die Einpresskraft liegt zwischen dem unteren und dem oberen Grenzwert

fur die Einpresskraft



Wird bei einem Getriebe eine Pressoperation wiederholt, so wird die Eindeutigkeitseigenschaft

der Feldkombination (PART NUMBER, STATION, SPINDLE, STEP) verletzt.


Station Spindel ToleranzbereichDrehwinkel (°)

Sollwert Drehmo-ment (Nm)

ToleranzbereichDrehmoment(Nm)

ST040 1 [45;105] 60 [30;150]ST040 2 [45;60] 30 [20;75]ST110 1 - 20 [18;22]ST110 2 - 10 [8;12]ST120 1 - 10 [8;12]ST140 1 - 45 [38;52]

Tabelle 6.4: Sollwerte und Toleranzbereiche fur Schrauboperationen

Semantisch falsche Messwerte in Form von Ausreißern, die durch Fehlmessungen verursacht wer-

den, werden in der Regel direkt von dem jeweiligen Messsystem erkannt. In diesem Fall wird der

entsprechende Datensatz mit einem Fehlercode versehen.

Semantisch falsche Werte, verursacht durch nachgeschaltete Datenebereinigungsprozesse (z. B.

Datenspeicherung, Datenubertragung oder Datenimport), sind jedoch nicht auszuschließen.

6.1.3 Schraubkraftdaten

Wie bei den Pressoperationen sind die bei einer Schrauboperation erfassten Datenfelder in allen

Quellsystemen identisch. Aus diesem Grund werden auch die Schraubkraftdaten aller Quellsyste-

me in einem gemeinsamen Abschnitt behandelt. In Tabelle 6.5 sind die Metadaten der Schraub-

kraftdaten aufgefuhrt. Auch hier sind zur besseren Lesbarkeit zusatzlich frei vergebene Feldnamen

angegeben.

Die Wertebereiche der Felder PART NUMBER und ATTRIBUTE sind identisch mit denen der

gleichnamigen Felder der Presskraftdaten. Die gultigen Werte fur die Felder SPINDLE und STA-

TION sowie deren gultige Wertekombinationen ergeben sich bei den Schraubkraftdaten ebenfalls

aus den gestellten Anforderungen (vgl. Abschnitt 3.2). Wie bei den Pressvorrichtungen konnen

sich im Laufe der Zeit die Grenzwerteinstellungen an den Schraubvorrichtungen und damit auch

die Wertebereiche der Felder fur den Drehwinkel und das Drehmoment andern. Prazisere Aussa-

gen uber die Eigenschaften der Felder MEASUREMENT VALUE DIM2 (Drehmoment), LOW-

ER LIMIT DIM2 (Unterer Grenzwert fur das Drehmoment) und UPPER LIMIT DIM2 (Oberer

Grenzwert fur das Drehmoment) lassen sich aus den Vorgaben fur die Sollwerte seitens der Abtei-

lung Fertigungsplanung, die in Tabelle 6.4 aufgefuhrt sind, ableiten. Die eingesetzten Schrauber

sind sehr prazise und erreichen in der Regel den Sollwert fur das Drehmoment mit einer Abwei-

chung von +/- 0,5 Nm. Starker abweichende Drehmomente, die jedoch innerhalb der aufgefuhrten

Toleranzbereiche liegen, konnen trotzdem zu akzeptablen Ergebnissen fuhren. Die Grenzwert-

einstellungen an den Montage-Stationen werden von der Abteilung Getriebefertigung vorgenom-


men und konnen sich im Lauf der Zeit andern. Bei der Bemessung der Grenzwerte steht in erster

Linie ein reibungsloser Montageprozess im Vordergrund, dabei werden unter Umstanden auch

Faktoren wie z. B. der aktuell verwendete Schraubentyp oder der aktuell montierte Getriebetyp

berucksichtigt. Voraussichtlich werden sich die eingestellten Grenzwerte jedoch innerhalb der in

Tabelle 6.4 aufgefuhrten Toleranzbereiche bewegen. Wie bei den Presskraftdaten konnen also Wer-

te, die nicht innerhalb der angegebenen Toleranzbereiche liegen, als falsche Werte betrachtet wer-

den.

In welchen Bereichen sich die an den Montage-Stationen eingestellten Grenzwerte und damit

auch die Messwerte fur den Drehwinkel bewegen werden, lasst sich aus heutiger Sicht nur fur

die Schraubspindeln der Station ST040 beurteilen (vgl. Tabelle 6.4). Fur die Spindeln der ubrigen

Stationen existieren auch keine Vorgaben fur den Drehwinkel seitens der Abteilung Fertigungs-

planung, da bei diesen Spindeln die Zahl der ausgefuhrten Umdrehungen keine Relevanz hat.

Entscheidend ist lediglich, dass das geforderte Drehmoment erreicht wird, um die notwendige Fe-

stigkeit der Schraubenverbindung zu gewahrleisten.

Wie bei den Presskraftdaten soll auf weitere statistische Analysen der Schraubkraftdaten verzichtet

werden.


1. Alle Felder sind Pflichtfelder.

2. Fur die Kombination der Felder (PART NUMBER, STATION, SPINDLE) gilt die Eindeu-

tigkeitseigenschaft.

3. Der Messwert fur Drehwinkel liegt zwischen dem unteren und dem oberen Grenzwert fur

den Drehwinkel


4. Der Messwert fur Drehmoment liegt zwischen dem unteren und dem oberen Grenzwert fur

das Drehmoment



Wird bei einem Getriebe eine Schrauboperation wiederholt, so wird die Eindeutigkeitseigenschaft

der Feldkombination (PART NUMBER, STATION, SPINDLE) verletzt.

Es konnen ganze Schraubkraftdatensatze fehlen, wenn aufgrund eines Ausfalls einer Schraubspin-

del die entsprechenden Verschraubungen mithilfe eines Handschraubers durchgefuhrt werden.

Auch bei Schrauboperationen werden semantisch falsche Messwerte in Form von Ausreißern von

dem jeweiligen Messsystem erkannt.



K0006 - PART NUMBER(Teile-Seriennummer)

Text wird durch den regularen Aus-druck R–[0-9]�8�[A-Z]�2� be-schrieben; bei Daten, die an denStationen ST040, ST110, ST120erzeugt werden: achtstellige Zei-chenkette

13 / 13bzw. 8 / 8

K0002 - ATTRIBUTE (Fehler-code)

ganzeZahl

[0;255]

K0008 - STATION (Station) Text �040, 110, 120, 140� 3 / 3K0007 - SPINDLE (Spindel) ganze

Zahl[1;2]

K0004 - TSTAMP (Erfassungs-datum)

Datum Format: dd.MM.yyyy/hh:mm:ss

K2110 - LOWER LIMIT DIM1(Untere Grenze fur Drehwinkel)

Zahl

K2111 - UPPER LIMIT DIM1(Obere Grenze fur Drehwinkel)

Zahl

K2110 - LOWER LIMIT DIM2(Untere Grenze fur Drehmo-ment)

Zahl

K2111 - UPPER LIMIT DIM2(Obere Grenze fur Drehmo-ment)

Zahl

K0001 - MEASURE-MENT VALUE DIM1(Messwert fur Drehwinkel)

Zahl

K0001 - MEASURE-MENT VALUE DIM2(Messwert fur Drehmoment)

Zahl

Tabelle 6.5: Metadaten der Schraubkraftdaten



OPEL ID (Getriebe-Seriennummer)


13 / 13

SHIM CLASS (Shim-Klasse) ganzeZahl

[1,25]

SHAFT (Art der Komponente) Text �HWO, HWU, AWE, DIF�,(HWO = Hauptwelle oben,HWU = Hauptwelle unten,AWE = Antriebswelle, DIF =Differentialgehause)

3 / 3

TSTAMP (Zeitpunkt der Erfas-sung)


Tabelle 6.6: Metadaten der Shim-Daten

6.1.4 Shim-Daten

Die Metadaten der Shim-Daten sind in Tabelle 6.6 aufgefuhrt. Das Feld OPEL ID beinhaltet die

13-stellige Getriebe-Seriennummer. Das Feld SHIM CLASS beinhaltet nicht die absolute Angabe

fur die Shim-Große, sondern einen Wert zwischen 1 und 25. Jeder Wert reprasentiert dabei eine

Shim-Große (Shim-Klasse). Der Wertebereich des Feldes SHAFT setzt sich aus vier dreistelligen

Kurzeln zusammen, die jeweils eine Komponentenart reprasentieren.


• Fur die Kombination der Felder (OPEL ID, SHAFT) gilt die Eindeutigkeitseigenschaft.

• Alle Felder sind Pflichtfelder.

• Das Feld OPEL ID ist ein Fremdschlussel, der die Kombinationsdaten referenziert.


Die Eindeutigkeitseigenschaft der Feldkombination (OPEL ID, SHAFT) wird verletzt, wenn ein

Getriebe die Station ST150 wiederholt durchlauft.

6.1.5 Ausschleusungsdaten

Die Metadaten der Ausschleusungsdaten sind in Tabelle 6.7 aufgefuhrt.



OPEL ID (Getriebe-Seriennummer)


13 / 13

TSTAMP (Zeitpunkt der Aus-schleusung)


Tabelle 6.7: Metadaten der Ausschleusungsdaten


• Fur das Feld OPEL ID gilt die Eindeutigkeitseigenschaft.

• Beide Felder sind Pflichtfelder.

• Das Feld OPEL ID ist ein Fremdschlussel, der die Kombinationsdaten referenziert.


Die Eindeutigkeitseigenschaft des Feldes OPEL ID wird verletzt, wenn ein Getriebe die Station

ST300 wiederholt durchlauft.

6.1.6 Beziehungen zwischen den Quellen und Multi Source-Probleme

Fremdschlusselbeziehungen zwischen den Daten der einzelnen Quellsysteme wurden bereits be-

schrieben.

Der Ablauf des Montageprozesses, also die Reihenfolge der durchgefuhrten Operationen, ist sta-

tisch. Aus diesem Grund mussen die Zeitstempel der einzelnen Datensatze bezuglich eines Ge-

triebes zeitchronologisch in der Reihenfolge liegen, wie die entsprechenden Operationen in der

Montagelinie durchgefuhrt werden. Aufgrund einer nicht funktionierenden Synchronisierung der

Zeiteinstellungen an den Montage-Stationen kann es allerdings zu widerspruchlichen Zeitangaben

kommen. Infolge von Aus- und Einschleusungen konnen sich die Reihenfolgen der Paletten in

der Montagelinie andern. Eine Operation kann nur durchgefuhrt werden, wenn alle ihre vorange-

gangenen Operationen erfolgreich durchgefuhrt wurden. Wird eine Operation wiederholt, mussen

zwangsweise auch alle nachfolgenden Operationen wiederholt werden, was zur Folge hat, dass die

bereits erfassten Messwerte der nachfolgenden Operationen ungultig werden. Dieser Fall tritt ein,

wenn ein Getriebe ausgeschleust, auseinandergebaut und nicht wieder in dieselbe Station, sondern

einige Stationen vorher eingeschleust wird.

Aus Interviews mit Fertigungsplanern geht hervor, dass keine wechselseitigen Einflusse zwischen

Operationen, die dasselbe Getriebe bearbeiten, bekannt sind. Demnach existieren, abgesehen von


den Beziehungen bezuglich der Fremdschlussel und der Zeitstempel, keinerlei Abhangigkeiten

zwischen den einzelnen Datensatzen, aus denen weitere Integritatsbedingungen abgeleitet werden

konnen.

Aufgrund der standardisierten Speicherung der Schraub- und Presskraftdaten existieren keine we-

sentlichen Multi Source-Probleme. Die erfassten Merkmale bei einer Operation sowie die zu de-

ren Speicherung verwendete Datenreprasentation, sind bei allen Quellsystemen identisch. In allen

DFQ-Dateien werden dieselben Datumsformate sowie bei Messwerten und Grenzwerteinstellun-

gen dieselben Messeinheiten verwendet. Es wird lediglich in den DFQ-Dateien ein anderes Da-

tumsformat verwendet als in den Dateien der ubrigen Quellsysteme. Außerdem ist die Prazision

in den Feldern fur die Grenzwerte und die tatsachlich gemessenen Werte bei den Schraub- und

Presskraftdaten deutlich hoher als jene, die in den Anforderungen definiert wurde. Des Weiteren

existieren keine Datenuberlappungen. Wenn man von den Daten aus der Wellen- und Gehause-

vormontage absieht, ist das einander Zuordnen aller Datensatze einer Getriebe-Entitat problemlos

moglich, da die Getriebe-Seriennummer als globaler Schlussel fungiert.

6.2 Definition des Zielschemas

In diesem Abschnitt wird das logische Datenbankmodell des Zielsystems vorgestellt, dabei werden

die einzelnen Tabellen in ihrem Aufbau und deren Beziehungen zueinander beschrieben. Abbil-

dung 6.1 zeigt eine Gesamtubersicht der Tabellen ohne die Fehlertabellen.

Die Tabelle TRANSMISSION

Jedes montierte Getriebe wird mit seiner Getriebe-Seriennummer in der Tabelle TRANSMIS-

SION (vgl. Tabelle 6.8) erfasst. Die Spalte OPEL ID speichert die Getriebe-Seriennummer und

dient als Primarschlussel. Wird das Getriebe fur die Kunden Fiat oder Saab montiert, so wird die

entsprechende Kunden-Seriennummer in die Spalte CUSTOMER ID geschrieben. Die Spalte DA-

TE EXIT speichert den Zeitpunkt, zu dem das Getriebe die letzte Montage-Station (ST300) und

somit die Montagelinie verlassen hat. Die Spalte DATE INSERT speichert den Einfugezeitpunkt

des Datensatzes.

Die Tabelle STATION

Diese Tabelle (vgl. Tabelle 6.9) speichert alle qualitatsrelevanten Montage-Stationen. Die Spal-

te STATION ID stellt den Primarschlussel der Tabelle dar. Die Spalten STATION NAME, IN-

VENTORY NO und MANUFACTURER dienen zur Erfassung weiterer optionaler Angaben wie

Beschreibung, Inventarnummer und Hersteller der Montage-Station zur Anzeige im Frontend.


TRANSMISSION

PK OPEL_ID

CUSTOMER_IDDATE_EXITDATE_INSERT

PRESSING_OPERATION

PK OP_ID

SPINDLESTEPLOWER_FORCE_TESTUPPER_FORCE_TEST

FK1 STATION_ID

STATION

PK STATION_ID

STATION_NAMEINVENTORY_NOMANUFACTURER

SHIM

PK,FK1 OPEL_IDPK SHAFT

SHIM_CLASSTSTAMP

PRESSING

PK,FK1 OP_IDPK,FK2 OPEL_ID

FK3 LIMIT_IDFORCEDISTANCETSTAMP

SCREWING

PK,FK3 OPEL_IDPK,FK2 OP_ID

FK1 LIMIT_IDANGLETORQUETSTAMP

LIMIT_PRESSING

PK LIMIT_ID

LOWER_LIMIT_DISTANCEUPPER_LIMIT_DISTANCELOWER_LIMIT_FORCEUPPER_LIMIT_FORCE

LIMIT_SCREWING

PK LIMIT_ID

LOWER_LIMIT_ANGLEUPPER_LIMIT_ANGLELOWER_LIMIT_TORQUEUPPER_LIMIT_TORQUE

SCREWING_OPERATION

PK OP_ID

SPINDLELOWER_TORQUE_TESTUPPER_TORQUE_TEST

FK1 STATION_IDLOWER_ANGLE_TESTUPPER_ANGLE_TEST

IMPORT_COMBINATION

PK DATE_ST140

OPEL_IDFIAT_IDSAAB_IDVID_ST040VID_ST110VID_ST120

COMBINATION

PK OPEL_IDPK STATION_ID

VIRTUAL_IDDATE_ST140DATE_INSERT

IMPORT_MEASUREMENT

PK PART_NUMBERPK SPINDLEPK STATIONPK STEPPK TYPE

ATTRIBUTELOWER_LIMIT_DIM1LOWER_LIMIT_DIM2MEASURING_VALUE_DIM1MEASURING_VALUE_DIM2TSTAMPUPPER_LIMIT_DIM1UPPER_LIMIT_DIM2DATE_INSERT

SYSTEM_PARAM

PK ATTRIBUTE

VALUE

Zieltabellen

Importtabellen

Abbildung 6.1: Logisches Datenbankmodell (ohne Fehlertabellen)


Feldname Datentyp Beschreibung Beispiel

OPEL ID CHAR(13) Getriebe-Seriennummer

R--04123456MH

CUSTOMER ID VARCHAR2(16) Kunden-Seriennummer

M68102P0010

DATE INSERT DATE Einfugedatum 07.01.04 12:13:46DATE EXIT DATE Zeitpunkt der Aus-

schleusung06.01.04 19:17:56

Tabelle 6.8: Die Tabelle TRANSMISSION


STATION ID CHAR(3) Stationsnummer 140STATION NAME VARCHAR2(20) Stationsname Station 140INVENTORY NO VARCHAR2(6) Inventarnummer 745552MANUFACTURER VARCHAR2(20) Herstellername LSW

Tabelle 6.9: Die Tabelle STATION

Die Tabelle SCREWING OPERATION

Jeder Eintrag in der Tabelle SCREWING OPERATION (vgl. Tabelle 6.10) reprasentiert eine qua-

litatsrelevante Schrauboperation in der Montagelinie. Die Spalte STATION ID stellt einen Fremd-

schlussel dar und referenziert auf die gleichnamige Spalte der Tabelle STATION, so dass je-

der Schrauboperation die Station zugeordnet wird, an der die Operation durchgefuhrt wird. Die

Spalte SPINDLE speichert die Spindelnummer. Die Spalte OP ID stellt einen kunstlich erzeug-

ten Primarschlussel dar und speichert Werte, die durch die Kombination der Werte in den Spal-

ten STATION ID und SPINDLE erzeugt werden. In den Spalten LOWER ANGLE TEST, UP-

PER ANGLE TEST, LOWER TORQUE TEST und UPPER TORQUE TEST werden die in Ta-

belle 6.4 aufgefuhrten Toleranzbereiche fur den Drehwinkel sowie das Drehmoment erfasst. Die

Toleranzbereiche werden zur Datenbereinigung neu eintreffender Schraubkraftdaten verwendet

(vgl. Abschnitte 6.1.3 und 6.3.2).

Die Tabelle PRESSING OPERATION

Jeder Eintrag in der Tabelle PRESSING OPERATION (vgl. Tabelle 6.11) reprasentiert eine qua-

litatsrelevante Pressoperation in der Montagelinie. Auch in dieser Tabelle stellt die Spalte STA-

TION ID einen Fremdschlussel dar. Die Spalten SPINDLE und STEP speichern die Spindel- und

Schrittnummer. Die Spalte OP ID stellt einen kunstlich erzeugten Primarschlussel dar und spei-

chert Werte, die durch die Kombination der Werte in den Spalten STATION ID, SPINDLE und

STEP erzeugt werden. In den Spalten LOWER FORCE TEST und UPPER FORCE TEST wer-



OP ID CHAR(5) Kunstlich erzeugterPrimarschlussel

14002

STATION ID CHAR(3) Stationsnummer 140SPINDLE NUMBER(2) Spindelnummer 2LOWER ANGLE TEST NUMBER(6,2) Unterer Prufwinkel 40.00UPPER ANGLE TEST NUMBER(6,2) Oberer Prufwinkel 120.00LOWER TORQUE TEST NUMBER(6,2) Unteres Prufmoment 2.00UPPER TORQUE TEST NUMBER(6,2) Oberes Prufmoment 14.00

Tabelle 6.10: Die Tabelle SCREWING OPERATION


OP ID CHAR(7) Kunstlich erzeugterPrimarschlussel

1400201

STATION ID CHAR(3) Stationsnummer 140SPINDLE NUMBER(2) Spindelnummer 2STEP NUMBER(2) Schrittnummer 1LOWER FORCE TEST NUMBER(4,2) Untere Prufkraft 0.1UPPER FORCE TEST NUMBER(4,2) Obere Prufkraft 4.5

Tabelle 6.11: Die Tabelle PRESSING OPERATION

den die in Tabelle 6.3 aufgefuhrten Toleranzbereiche fur die Einpresskraft gespeichert. Sie wer-

den zur Datenbereinigung neu eintreffender Presskraftdaten verwendet wird (vgl. Abschnitte 6.1.2

und 6.3.2).

Die Tabelle LIMIT SCREWING

Die Tabelle LIMIT SCREWING (vgl. Tabelle 6.12) speichert alle in der gesamten Montageli-

nie vorkommenden Grenzwerteinstellungen fur Schrauboperationen. Dabei handelt es sich um die

Grenzwerteinstellungen, die an den Montage-Stationen eingestellt werden und mit den Messwer-

ten zusammen ubertragen werden. Die Spalten LOWER LIMIT TORQUE und LOWER LIMIT -

ANGLE reprasentieren die unteren Grenzwerte fur Drehmoment und Drehwinkel und die Spalten

UPPER LIMIT TORQUE und UPPER LIMIT ANGLE die oberen Grenzwerte fur Drehmoment

und Drehwinkel. Die Spalte LIMIT ID stellt einen kunstlich generierten Primarschlussel dar.

Diese Tabelle ist durch eine Normalisierung der Tabelle SCREWING entstanden, der ursprunglich

die Spalten fur die Grenzwerteinstellungen angehorten. Die Normalisierung wurde durchgefuhrt,

um eine große Redundanz in der Tabelle SCREWING zu vermeiden. Grenzwerteinstellungen an

den Montage-Stationen konnen uber Wochen hinweg unverandert bleiben, so dass bei einer nicht-

normalisierten Tabelle SCREWING einige tausend Datensatze exakt die selbe Wertebelegung fur

die Grenzwerteinstellungen besitzen wurden.



LIMIT ID NUMBER Kunstlich generierterPrimarschlussel

12

LOWER LIMIT ANGLE NUMBER(6,2) Unterer Grenzwert fur Dreh-winkel

40.0

UPPER LIMIT ANGLE NUMBER(6,2) Oberer Grenzwert fur Dreh-winkel

150.0

LOWER LIMIT TORQUE NUMBER(6,2) Unterer Grenzwert fur Dreh-moment

8.23

UPPER LIMIT TORQUE NUMBER(6,2) Oberer Grenzwert fur Dreh-moment

12.23

Tabelle 6.12: Die Tabelle LIMIT SCREWING


OP ID CHAR(5) Schlussel fur Operation 14002OPEL ID CHAR(13) Getriebe-Seriennummer R--04123450MHLIMIT ID NUMBER Schlussel fur Grenzwertein-

stellungANGLE NUMBER(6,2) Gemessener Drehwinkel 80TORQUE NUMBER(6,2) Gemessenes Drehmoment 10TSTAMP DATE Zeitpunkt der Operation 12.12.1995

12:34:34

Tabelle 6.13: Die Tabelle SCREWING

Die Tabelle SCREWING

Die Tabelle SCREWING (vgl. Tabelle 6.13) dient zur Speicherung der bei Durchfuhrung ei-

ner Schrauboperation erfassten Messwerte fur den Drehwinkel und das Drehmoment. Die erfas-

sten Messwerte werden in den Spalten ANGLE und TORQUE gespeichert. Die Spalte TSTAMP

speichert den Zeitpunkt der Durchfuhrung der Operation. Die Spalten OPEL ID, LIMIT ID und

OP ID stellen Fremdschlussel dar und referenzieren auf die gleichnamigen Spalten der Tabellen

TRANSMISSION, LIMIT SCREWING und SCREWING OPERATION. Sie ordnen den Messwer-

ten das bearbeitete Getriebe, die bei Durchfuhrung der Operation eingestellten Grenzwerte sowie

die jeweilige Schrauboperation in der Tabelle SCREWING OPERATION zu.

Die Tabelle LIMIT PRESSING

Die Tabelle LIMIT PRESSING (vgl. Tabelle 6.14) ist analog zur Tabelle LIMIT SCREWING

aufgebaut und speichert alle in der gesamten Montagelinie vorkommenden Grenzwerteinstellun-

gen fur Pressoperationen.



LIMIT ID NUMBER Kunstlich generierterPrimarschlussel

12

LOWER LIMIT DISTANCE NUMBER(6,2) Unterer Grenzwert furEinpresstiefe

220.0

UPPER LIMIT DISTANCE NUMBER(6,2) Oberer Grenzwert furEinpresstiefe

270.0

LOWER LIMIT FORCE NUMBER(4,2) Unterer Grenzwert furEinpresskraft

10.0

UPPER LIMIT FORCE NUMBER(4,2) Oberer Grenzwert furEinpresskraft

14.0

Tabelle 6.14: Die Tabelle LIMIT PRESSING


OP ID CHAR(7) Schlussel fur Operation 1400201OPEL ID CHAR(13) Getriebe-Seriennummer R--04123450MHLIMIT ID NUMBER Schlussel fur Grenzwertein-

stellungDISTANCE NUMBER(6,2) Gemessene Einpresstiefe 237.27FORCE NUMBER(4,2) Gemessene Einpresskraft 12.23TSTAMP DATE Zeitpunkt der Operation 12.12.1995

12:34:34

Tabelle 6.15: Die Tabelle PRESSING

Die Tabelle PRESSING

Die Tabelle PRESSING (vgl. Tabelle 6.15) ist analog zur Tabelle SCREWING aufgebaut und

dient zur Speicherung der bei Durchfuhrung einer Pressoperation erfassten Messwerte fur die

Einpresstiefe und die Einpresskraft.

Die Tabelle SHIM

Die Tabelle SHIM (vgl. Tabelle 6.16) speichert die fur ein Getriebe ermittelten Shim-Klassen. Die

Spalte OPEL ID dient als Fremdschlussel und referenziert auf die gleichnamige Spalte der Tabelle

TRANSMISSION. Die Spalten SHIM CLASS und SHAFT dienen zur Speicherung der Shim-

Klasse sowie eines Kurzels fur die Getriebekomponente, fur die das Shim verwendet werden soll.

Die Spalte TSTAMP speichert den Zeitpunkt der Erfassung des Datensatzes an der Station ST150.

Die Spalten OPEL ID und SHIM CLASS bilden einen zusammengesetzten Primarschlussel der

Tabelle SHIM.



OPEL ID CHAR(13) Getriebe-Seriennummer R--04123456MHSHIM CLASS NUMBER(2,0) Shim-Klasse 12SHAFT CHAR(3) Kurzel fur Komponente HWOTSTAMP DATE Zeitpunkt der Erfassung 12.01.2004

12.12.12

Tabelle 6.16: Die Tabelle SHIM

Die Tabelle ERROR MEASUREMENT

In dieser Tabelle (vgl. Tabelle 6.17) werden alle Schraub- und Presskraftdaten gespeichert, die

aufgrund fehlerhafter Werte nicht in die Zieltabellen ubernommen werden konnten. Alle Spal-

tenwerte werden als Text gespeichert, um auch Datensatze erfassen zu konnen, die Formatfehler

in numerischen Spalten aufweisen. Die Spalte MSG dient zur Speicherung eines Hinweistextes,

weshalb der Datensatz nicht in die Zieltabellen ubernommen wurde. Die Spalte DATE INSERT

speichert das Einfugedatum des Datensatzes.

Die Spalten LOWER LIMIT DIM1, UPPER LIMIT DIM1 und MEASUREMENT VALUE DIM1

speichern den unteren und den oberen Grenzwert sowie den Messwert fur den Weg (Einpres-

stiefe/Drehwinkel). Die Spalten LOWER LIMIT DIM2, UPPER LIMIT DIM2 und MEASURE-

MENT VALUE DIM2 speichern den unteren und den oberen Grenzwert sowie den Messwert fur

die aufgewendete Kraft (Einpresskraft/Drehmoment). In der Spalte TYPE wird erfasst, ob es sich

bei dem Datensatz um einen Presskraftdatensatz oder um einen Schraubkraftdatensatz handelt.

Die Tabelle ERROR SHIM

In dieser Tabelle (vgl. Tabelle 6.18) werden alle Shim-Daten gespeichert, die aufgrund fehlerhafter

Werte nicht in die Zieltabellen ubernommen werden konnten. Auch in dieser Tabelle werden alle

Werte als Text gespeichert, außerdem verfugt diese Tabelle ebenfalls uber die Spalten MSG und

DATE INSERT zum Erfassen eines Hinweistextes und des Einfugedatums.

Die Tabelle ERROR COMBINATION

In dieser Tabelle (vgl. Tabelle 6.19) werden alle Kombinationsdaten gespeichert, die aufgrund

fehlerhafter Daten nicht in die Zieltabellen ubernommen werden konnten.

Die Tabelle SYSTEM PARAM

Diese Tabelle (vgl. Tabelle 6.20) stellt eine Hilfstabelle dar, in der Parameter abgelegt werden, die

uber verschiedene Instanzen der Datenbereinigungsprozesse hinweg gesichert werden mussen. In


Feldname Datentyp Beschreibung

PART NUMBER VARCHAR2(20) SeriennummerATTRIBUTE VARCHAR2(20) FehlercodeSTATION VARCHAR2(20) StationsnummerSPINDLE VARCHAR2(20) SpindelnummerSTEP VARCHAR2(20) SchrittnummerMEASURING VALUE DIM1 VARCHAR2(20) Messwert fur Einpresstie-

fe/DrehwinkelMEASURING VALUE DIM2 VARCHAR2(20) Messwert fur Einpres-

skraft/DrehmomentLOWER LIMIT DIM1 VARCHAR2(20) Unterer Grenzwert fur Einpresstie-

fe/DrehwinkelUPPER LIMIT DIM1 VARCHAR2(20) Oberer Grenzwert fur Einpresstie-

fe/DrehwinkelLOWER LIMIT DIM2 VARCHAR2(20) Unterer Grenzwert fur Einpres-

skraft/DrehmomentUPPER LIMIT DIM2 VARCHAR2(20) Oberer Grenzwert fur Einpres-

skraft/DrehmomentTSTAMP VARCHAR2(20) Zeitpunkt der OperationTYPE CHAR(1) Art des Datensatzes (0=Schraubkraft-

datensatz/1=Presskraftdatensatz)MSG VARCHAR2(255) HinweistextDATE INSERT DATE Einfugedatum

Tabelle 6.17: Die Tabelle ERROR MEASUREMENT

der Spalte ATTRIBUTE wird der Parametername und in der Spalte VALUE der zugehorige Wert

erfasst.

6.3 Definition der Datenbereinigungsprozesse

Die Datenbereinigungsprozesse dienen dazu, die von den Montage-Stationen empfangenen Daten

einzulesen und zu transformieren, um sie damit hinsichtlich ihrer Struktur und Reprasentation an

das gemeinsame Zielschema anzupassen. Dabei sollen Daten, die offensichtlich fehlerhaft sind

bzw. die in Abschnitt 5.1 genannten Qualitatskriterien nicht erfullen, aussortiert werden.

Bei der Uberprufung der Quelldaten auf die Erfullung der einzelnen Qualitatskriterien ist es sinn-

voll, die Daten anfangs unter syntaktischen Gesichtspunkten zu uberprufen. Dazu konnen die

wahrend der Datenanalyse ermittelten Informationen uber die jeweiligen Datentypen sowie die ty-

pischen Muster der Werte verwendet werden. Wahrend dessen erfolgt auch ein Vollstandigkeitstest,

um zu prufen, ob zu allen Feldern entsprechende Werte vorhanden sind. Der Test auf Vollstan-

digkeit ist einfach durchzufuhren, da bis auf die Kunden-Seriennummer alle Felder Pflichtfel-



OPEL ID VARCHAR2(20) Getriebe-SeriennummerSHIM CLASS VARCHAR2(20) Shim-KlasseSHAFT VARCHAR2(20) KomponenteTSTAMP VARCHAR2(20) Zeitpunkt der ErfassungMSG VARCHAR2(255) FehlermeldungDATE INSERT DATE Einfugedatum

Tabelle 6.18: Die Tabelle ERROR SHIM


OPEL ID VARCHAR2(20) Getriebe-SeriennummerFIAT ID VARCHAR2(20) Kunden-Seriennummer (FIAT)SAAB ID VARCHAR2(20) Kunden-Seriennummer (SAAB)DATE ST140 VARCHAR2(20) Zeitpunkt der Erfassung an der Station ST140VID ST040 VARCHAR2(20) Virtuelle Kennung ST040VID ST110 VARCHAR2(20) Virtuelle Kennung ST110VID ST120 VARCHAR2(20) Virtuelle Kennung ST120MSG VARCHAR2(255) HinweistextDATE INSERT DATE Einfugedatum

Tabelle 6.19: Die Tabelle ERROR COMBINATION

der sind. Das Fehlen einer Kunden-Seriennummer wird als nicht kritisch beurteilt und toleriert.

Aufgrund dessen tritt in diesem Fall die Problematik, die aus den unterschiedlichen Interpreta-

tionsmoglichkeiten eines nicht vorhandenen Wertes resultieren kann (vgl. Abschnitt 5.1), nicht

auf. Anhand der beiden genannten Uberprufungen konnen alle Datensatze, die die Kriterien der

Vollstandigkeit und der Schema-Konformitat verletzen, erkannt werden. Die Erfullung der beiden

Kriterien ist Voraussetzung fur die Uberprufung der semantischen Korrektheit.

Nach erfolgter Uberprufung der syntaktischen Korrektheit sollten die Quelldaten auf semantische

Korrektheit hin uberpruft werden. Die Uberprufung der Werte erfolgt mithilfe des Wissens uber

die Wertebereiche und die Integritatsbedingungen, welches wahrend der Datenanalyse erworben

wurde.

Die Eindeutigkeit der Qualitatsdaten ist einfach sicherzustellen, da alle Datensatze uber eine be-

stimmte Feldkombination eindeutig identifizierbar sind (z. B. bei Schraubkraftdatensatze anhand

der Seriennummer des bearbeiteten Teils und der Angaben fur die Station und die Spindel). Eine

aufwandige Duplikateliminierung, wie sie beispielsweise bei Adressdaten erforderlich ist, entfallt

in diesem Anwendungsfall. Duplikate infolge einer mehrfachen Datenubertragung konnen pro-

blemlos vermieden werden. Bei Duplikaten, die durch eine wiederholte Durchfuhrung einer Ope-



ATTRIBUTE VARCHAR2(50) Parametername LAST COMBINATION DATEVALUE VARCHAR2(50) Wert 12.12.1995 12:34:34

Tabelle 6.20: Die Tabelle SYSTEM PARAM

ration verursacht werden, soll grundsatzlich der Datensatz mit dem großeren Zeitstempel gespei-

chert werden. Eine Plausibilitatsuberprufung der Zeitstempel soll nicht erfolgen, da die Zeitsyn-

chronisierung der Montage-Stationen nicht einwandfrei funktioniert. ImUbrigen wird der Kor-

rektheit der Zeitstempel keine hohe Prioritat beigemessen, da keine Datenanalysen geplant sind,

die die Plausibilitat der Zeitstempel voraussetzen wurden.

Wie bereits in Abschnitt 5.1 beschrieben, kann unter dem Kriterium der Vollstandigkeit auch die

Eigenschaft verstanden werden, dass alle Entitaten der Realitat im Datenbestand reprasentiert sind.

Obwohl der Vollstandigkeitstest, ob fur ein Getriebe zu allen Operationen ein entsprechender Da-

tensatz vorhanden ist, aufgrund des bekannten Aufbaus der Montagelinie und der damit bekannten

Anzahl der zu erwartenden Datensatze einfach zu realisieren ware, wird auf ihn verzichtet, da die-

ses Kriterium laut Anforderungen nicht erfullt werden muss.

Das Kriterium Einheitlichkeit ist durch die standardisierte Reprasentation der Schraub- und Pres-

skraftdaten weitgehend gegeben. Es mussen lediglich Transformationen der Quelldaten bezuglich

ihrer Struktur durchgefuhrt werden, um sie in die normalisierte Zieldatenbank schreiben zu konnen.

Die Bereinigung der Datensatze beschrankt sich damit auf die Uberprufung der Eindeutigkeit,

der Vollstandigkeit und der Gultigkeit der Werte mithilfe der in Abschnitt 6.1 ermittelten Inte-

gritatsbedingungen. Alle durchzufuhrenden Uberprufungen konnen mithilfe entsprechender Inte-

gritats-Constraints in den Zieltabellen durchgefuhrt werden.

Bei der Definition der Datenbereinigungsprozesse wurde von dem in Abschnitt 5.5.3 beschrie-

benen Schema eines ETL-Prozesses abgewichen. Es existieren demnach keine strikt getrenn-

ten Phasen fur Extraktion, Transformation und Laden der Daten, da die temporare Speicherung

samtlicher Daten in einem Transformationsbereich in diesem Anwendungsfall nicht unbedingt als

notwendig erscheint und daher unnotigen Overhead verursachen wurde. Eine Speicherung von Da-

tensatzen im Transformationsbereich ist erforderlich, wenn komplexere Abhangigkeiten zwischen

Datensatzen existieren, so dass die Bereinigung eines Datensatzes das Vorhandensein anderer Da-

tensatze voraussetzt. Dies ist beispielsweise der Fall, wenn mehrere Datensatze zur Erkennung von

logischen Widerspruchen einander abgeglichen werden mussen. Da die Zeitstempelbeziehungen

außer Acht gelassen werden sollen, bestehen keine Abhangigkeiten, die es vor dem Ladevorgang



OPEL ID VARCHAR2(25) Getriebe-SeriennummerFIAT ID VARCHAR2(25) Kunden-Seriennummer (FIAT)SAAB ID VARCHAR2(25) Kunden-Seriennummer (SAAB)DATE ST140 DATE Zeitpunkt der Erfassung an der Station ST140VID ST040 VARCHAR2(15) Virtuelle Kennung: Stirnrad/Differential

(ST040)VID ST110 VARCHAR2(15) Virtuelle Kennung: Getriebegehause (ST110)VID ST120 VARCHAR2(15) Virtuelle Kennung: Kupplungsgehause

(ST120)

Tabelle 6.21: Die Tabelle IMPORT COMBINATION

zu uberprufen gilt. Ein Teil der Quelldaten kann demnach im Arbeitsspeicher transformiert wer-

den und direkt in die Zieltabellen geladen werden. Das temporare Speichern der Quelldaten in

Hilfstabellen wird daher auf die Schraub- und Presskraftdaten aus der Vormontage beschrankt.

Bei diesen Quelldaten ist das temporare Speichern unvermeidlich, da sie vor dem Ladevorgang in

die Zieltabellen aufgrund der nicht existenten Getriebe-Seriennummer mit den Kombinationsda-

ten kombiniert werden mussen. Daruber hinaus sollen an den Quelldaten keine Korrekturen von

falschen Werten vorgenommen werden, so dass bereits wahrend des Einlesevorgangs der Quellda-

teien als fehlerhaft identifizierte Datensatze gar nicht erst in den Transformationsbereich geladen

werden mussen, sondern direkt in einen Fehler-Report geschrieben werden konnen.

Zur Bereinigung der eintreffenden Quelldaten sind insgesamt funf verschiedene Prozesse definiert:

1. Einlesen und Bereinigen der Kombinationsdaten

2. Einlesen und Bereinigen der Schraub- und Presskraftdaten

3. Einlesen und Bereinigen der Shim-Daten

4. Einlesen und Bereinigen der Ausschleusungsdaten

5. Bereinigen der Import- und Fehlertabellen

Der funfte Prozess dient nicht der eigentlichen Datenbereinigung, sondern lediglich zum Loschen

nicht mehr benotigter Datensatze in den Import- und Fehlertabellen. In den folgenden Abschnitten

werden die genannten Prozesse in ihrem Ablauf beschrieben.

6.3.1 Einlesen und Bereinigen der Kombinationsdaten

Dieser Prozess dient der Speicherung der Kombinationsdaten in einer Form, wie sie im nach-

folgenden Prozess zur Zuordnung der Schraub- und Presskraftdaten aus der Vormontage zu den


einzelnen Getrieben verwendet werden konnen. Der Aufbau der Kombinationsdatei ist in Tabel-

le 2.1 und ein exemplarischer Auszug aus dieser in Abbildung 4.4 dargestellt.

Der Inhalt der Kombinationsdatei wird unverandert in die Tabelle IMPORT COMBINATION (vgl.

Tabelle 6.21) geladen. Lediglich die Spalten V ID2, V ID3 und V ID4 werden entfernt, da die

Erfassung der mit diesen virtuellen Kennungen verbundenen Messwerte nicht im Anforderungs-

bereich liegen und die Spalten TIMESTAMP, V ID1, V ID5 und V ID6 werden auf die Spalten

DATE ST140, VID ST040, VID ST110 und VID ST120 der Tabelle IMPORT COMBINATION

abgebildet. Daruber hinaus erfolgt bereits beim Parsen der Datei eine syntaktische Uberprufung

der Werte in der Spalte TIMESTAMP, weil die syntaktische Korrektheit fur die weitere Verar-

beitung der Daten erforderlich ist. Da die Quelldatei nicht nur die Kombinationsdaten der vor-

angegangenen Schicht, sondern alle jemals erfassten Kombinationsdaten beinhaltet (Full-Dump),

wird vor Beendigung dieses Prozesses der Zeitstempel des jungsten Eintrages der Tabelle IM-

PORT COMBINATION in die Tabelle SYSTEM PARAM (vgl. Tabelle 6.20) geschrieben. Damit

wird ein Zeiger auf den zuletzt integrierten Datensatz uber die aktuelle Prozessinstanz hinweg

bis zu einer erneuten Prozessausfuhrung festgehalten. Bei einem erneuten Start dieses Prozesses

werden dann nur die Dateieintrage in die Tabelle IMPORT COMBINATION geschrieben, deren

Zeitstempel großer sind als der Zeitstempel des in der vorangegangen Prozessinstanz zuletzt inte-

grierten Datensatzes. Auf diese Weise wird vermieden, dass bei jeder Ausfuhrung dieses Prozesses

der gesamte Inhalt der Quelldatei importiert werden muss. Nach dem Einlesen der Quelldatei be-

steht der gesamte Datenbestand der Kombinationsdaten in der Tabelle IMPORT COMBINATION

zur Verfugung, ohne dass nochmals auf die Quelldatei zugegriffen werden muss, sofern ein Zugriff

auf altere Daten notwendig werden sollte.

Im weiteren Verlauf werden alle Datensatze aus der Tabelle IMPORT COMBINATION, die seit

der letzten Prozessausfuhrung hinzugekommen sind und demnach bis dahin nicht integriert wur-

den, selektiert und wie folgt transformiert:

(OPEL ID, FIAT ID, (OPEL ID, CUSTOMER ID, DATE ST140),

SAAB ID, DATE ST140, � (OPEL ID, VID ST040, ’ST040’, DATE ST140),

VID ST040, VID ST110, (OPEL ID, VID ST110, ’ST110’, DATE ST140),

VID ST120) (OPEL ID, VID ST120, ’ST120’, DATE ST140)

Die Felder SAAB ID und FIAT ID verschmelzen dabei zu einem Feld CUSTOMER ID, da jedes

Getriebe maximal nur eine Kunden-Seriennummer besitzen kann.

Tritt ein Datensatz mit fehlender Getriebe-Seriennummer und vorhandener Kunden-Seriennummer

auf, so wird in der Tabelle IMPORT COMBINATION nach einem Eintrag gesucht, der die glei-

che Kunden-Seriennummer und einen kleineren Zeitstempel tragt. Besitzt der gefundene Ein-


trag eine gultige Getriebe-Seriennummer, so wird diese fur die weitere Verarbeitung herange-

zogen. Datensatze mit nicht vorhandener Getriebe-Seriennummer und nicht vorhandener Kunden-

Seriennummer werden verworfen und in die Tabelle ERROR COMBINATION geschrieben. Hin-

tergrund dieser Vorgehensweise ist, dass bei einer fehlenden Getriebe-Seriennummer moglich-

erwiese eine erneute Einschleusung des Getriebes stattgefunden hat und bei der erneuten Er-

fassung der Kombinationsdaten der Wert fur die Getriebe-Seriennummer verloren gegangen ist.

Verfugt der Datensatz uber eine Kunden-Seriennummer, kann uber diese der Datensatz der vor-

angegangenen Einschleusung gefunden und anhand dieses Datensatzes die zugehorige Getriebe-

Seriennummer ermittelt werden.

Der Datensatz (OPEL ID, CUSTOMER ID, DATE ST140) wird in die Tabelle TRANSMISSI-

ON geschrieben, wobei die ersten beiden Attribute des Datensatzes auf die gleichnamigen Spal-

ten der Tabelle abgebildet werden. Das Attribut DATE ST140 wird dagegen auf die Spalte DA-

TE EXIT der Tabelle abgebildet, um die genannte Spalte mit dem Erfassungsdatum der Station

ST140 vorzubelegen. Auf diese Weise steht der ungefahre Montagezeitpunkt zur Verfugung, falls

in der Montagelinie aus irgendwelchen Grunden kein Ausschleusungszeitpunkt erfasst werden

sollte (vgl. auch Abschnitt 6.3.2). Existiert bereits ein entsprechender Datensatz in der Tabelle

TRANSMISSION, so wird die Spalte CUSTOMER ID des vorhandenen Datensatzes aktualisiert.

Ist der in der Spalte DATE EXIT gespeicherte Zeitstempel des vorhandenen Datensatzes kleiner

als der des einzufugenden Datensatzes, wird auch die Spalte DATE EXIT entsprechend aktuali-

siert. Die Vollstandigkeit wird sichergestellt, indem alle Spalten der Tabelle TRANSMISSION mit

Ausnahme der Spalte CUSTOMER ID als NOT NULL deklariert sind. Eine Plausibilitatskontrolle

der Getriebe-Seriennummer erfolgt mithilfe einer CHECK-Klausel.

Die Datensatze (OPEL ID, VID ST040, ’ST040’, DATE ST140), (OPEL ID, VID ST110, ’ST110’,

DATE ST140) und (OPEL ID, VID ST120, ’ST120’, DATE ST140) werden in die Tabelle COM-

BINATION geschrieben. Die Attribute OPEL ID und DATE ST140 werden dabei auf die gleich-

namigen Spalten der Tabelle abgebildet. Die Attribute VID ST040, VID ST010 und VID ST120

werden dagegen in die Spalte VIRTUAL ID und die Zeichenketten ’ST040’, ’ST110’ und ’ST120’

in die Spalte STATION ID geschrieben. Alle Spalten der Tabelle COMBINATION sind als NOT

NULL deklariert. Die Eindeutigkeit in der Tabelle COMBINATION wird durch den Primarschlussel,

der sich aus den Spalten OPEL ID und STATION ID zusammensetzt, sichergestellt. Ein bereits

vorhandener Datensatz mit gleichem Schlusselwert wie der neu zu speichernde Datensatz, wird

uberschrieben, sofern der neu zu speichernde Datensatz den großeren Zeitstempel der beiden Da-

tensatze besitzt. Wird ein Fehler in einem der durch die Transformation entstandenen Datensatze

gefunden, wird der ursprungliche Datensatz, aus dem der betroffene Datensatz bei der Transfor-

mation hervorgegangen ist, in die Tabelle ERROR COMBINATION geschrieben.



OPEL ID CHAR(13) Getriebe-SeriennummerVIRTUAL ID CHAR(8) Virtuelle KennungSTATION ID CHAR(3) StationsnummerDATE ST140 DATE Zeitpunkt der Erfassung an der Station ST140DATE INSERT DATE Einfugedatum

Tabelle 6.22: Die Tabelle COMBINATION

Nach Beendigung dieses Prozesses stehen alle Kombinationsdaten der vorangegangenen Schicht

in der Tabelle COMBINATION zur Verfugung, um spater die Schraub- und Presskraftdaten aus

der Vormontage den jeweiligen Getrieben zuordnen zu konnen. Dabei ist sichergestellt, dass die

Daten syntaktisch korrekt und vollstandig sind. Außerdem beinhalten die Daten zu jedem Getrie-

be, welches mehrmalig durch die Station ST140 geschleust wurde, die jeweils zuletzt erfassten

Kombinationen.

6.3.2 Einlesen und Bereinigen der Schraub- und Presskraftdaten

Da die Schraub- und Presskraftdaten aufgrund ihrer gleichartigen Struktur auf gleiche Weise ver-

arbeitet werden konnen und sich lediglich die Zieltabellen der beiden Datenarten unterscheiden,

werden die Schraub- und Presskraftdaten von demselben Prozess verarbeitet. Das Dateiformat

der Schraub- und Presskraftdateien ist in Abschnitt 4.3.1 beschrieben. Der gesamte Prozess zur

Verarbeitung der Schraub- und Presskraftdaten gliedert sich in zwei Phasen:

1. Phase Aus den Inhalten des Beschreibungsteils sowie den einzelnen Werteeintragen im Werte-

teil einer DFQ-Datei werden die Datensatze (PART NUMBER, ATTRIBUTE, STATION, SPIND-

LE, STEP, MEASURING VALUE DIM1, MEASURING VALUE DIM2, LOWER LIMIT DIM1,

UPPER LIMIT DIM1, LOWER LIMIT DIM2, UPPER LIMIT DIM2, TSTAMP, TYPE) erzeugt.

Das Attribut TYPE dient zur Unterscheidung zwischen Schraub- und Presskraftdaten und anhand

dessen Wert werden die Zieltabellen fur den zu speichernden Datensatz gewahlt. Ein Datensatz,

der im Attribut ATTRIBUTE einen Wert ungleich”0“ aufweist, wird direkt in die Tabelle ER-

ROR MEASUREMENT geschrieben, da ein solcher Datensatz von einer fehlgeschlagenen Ope-

ration stammt und laut Anforderungen nicht gespeichert werden soll. Weist der Wert des Attributs

ATTRIBUTE den Wert”0“ auf, so werden die einzelnen Attributwerte des Datensatzes in die

fur das Zielsystem erforderlichen Datentypen konvertiert. Im weiteren Verlauf wird zwischen Da-

tensatzen unterschieden, die aufgrund ihrer Herkunft (Vormontage oder Endmontage) uber eine

virtuelle Kennung oder eine Getriebe-Seriennummer verfugen.

Ein Datensatz, der aus der Vormontage stammt und daher im Attribut PART NUMBER uber ei-



PART NUMBER VARCHAR2(8) SeriennummerATTRIBUTE NUMBER(3) FehlercodeSTATION CHAR(3) StationsnummerSPINDLE NUMBER(2) SpindelnummerSTEP NUMBER(1) SchrittnummerMEASURING VALUE DIM1 NUMBER(6,2) Messwert fur Einpresstie-

fe/DrehwinkelMEASURING VALUE DIM2 NUMBER(5,2) Messwert fur Einpres-

skraft/DrehmomentLOWER LIMIT DIM1 NUMBER(6,2) Unterer Grenzwert fur Einpresstie-

fe/DrehwinkelUPPER LIMIT DIM1 NUMBER(6,2) Oberer Grenzwert fur Einpresstie-

fe/DrehwinkelLOWER LIMIT DIM2 NUMBER(5,2) Unterer Grenzwert fur Einpres-

skraft/DrehmomentUPPER LIMIT DIM2 NUMBER(5,2) Oberer Grenzwert fur Einpres-

skraft/DrehmomentTSTAMP VARCHAR2(20) Zeitpunkt der OperationTYPE CHAR(1) Art des Datensatzes (0=Schraubkraft-

datensatz/1=Presskraftdatensatz)DATE INSERT DATE Einfugedatum

Tabelle 6.23: Die Tabelle IMPORT MEASUREMENT

ne virtuelle Kennung verfugt, wird unverandert in die Tabelle IMPORT MEASUREMENT (vgl.

Tabelle 6.23) geschrieben. Der Primarschlussel dieser Tabelle setzt sich zusammen aus den Spal-

ten PART NUMBER, STATION, SPINDLE, STEP und TYPE. Ein bereits vorhandener Datensatz

mit gleichem Schlusselwert wie der neu zu speichernde Datensatz, wird uberschrieben, sofern

der neu zu speichernde Datensatz den großeren Zeitstempel der beiden Datensatze besitzt. Eine

Uberprufung auf Einhaltung der definierten Wertebereiche sowie weiterer Integritatsbedingungen

erfolgt an dieser Stelle nicht.

Ein Datensatz, die aus der Endmontage stammt und daher im Attribut PART NUMBER bereits

uber eine Getriebe-Seriennummer verfugt, wird direkt in die Zieltabellen geschrieben. Dazu wird

ein zu speichernder Datensatz zunachst wie folgt transformiert:


(PART NUMBER, ATTRIBUTE, (MEASURING VALUE DIM1,

STATION, SPINDLE, STEP, MEASURING VALUE DIM2,

MEASURING VALUE DIM1, PART NUMBER, TSTAMP),

MEASURING VALUE DIM2,

LOWER LIMIT DIM1, � (LOWER LIMIT DIM1,

UPPER LIMIT DIM1, UPPER LIMIT DIM1,

LOWER LIMIT DIM2, LOWER LIMIT DIM2,

UPPER LIMIT DIM2, UPPER LIMIT DIM2)

TSTAMP, TYPE)

Je nach Datenart wird der Datensatz (LOWER LIMIT DIM1, UPPER LIMIT DIM1, LOWER -

LIMIT DIM2, UPPER LIMIT DIM2) in die Tabelle LIMIT PRESSING oder LIMIT SCREWING

geschrieben, sofern ein entsprechender Datensatz in der jeweiligen Zieltabelle noch nicht existiert.

Die Attribute LOWER LIMIT DIM1 und UPPER LIMIT DIM1 werden dabei je nach Zieltabelle

auf die Spalten LOWER LIMIT ANGLE und UPPER LIMIT ANGLE oder LOWER LIMIT -

DISTANCE und UPPER LIMIT DISTANCE abgebildet. Die Attribute LOWER LIMIT DIM2

und UPPER LIMIT DIM2 werden dagegen auf die Spalten LOWER LIMIT TORQUE und UP-

PER LIMIT TORQUE oder LOWER LIMIT FORCE und UPPER LIMIT FORCE abgebildet.

Alle Spalten der beiden Zieltabellen sind als NOT NULL deklariert.

Der Datensatz (MEASURING VALUE DIM1, MEASURING VALUE DIM2, PART NUMBER,

TSTAMP) wird zusammen mit den Attributen OP ID und LIMIT ID je nach Datenart in die Ta-

belle SCREWING oder PRESSING geschrieben. Der Wert fur das Attribut OP ID wird aus der

Wertekombination der Attribute STATION ID, SPINDLE und ggf. STEP des ursprunglichen Da-

tensatzes ermittelt. Der Wert fur das Attribut LIMIT ID entspricht dem Schlusselwert der entspre-

chenden Grenzwerteinstellung in der Tabelle LIMIT PRESSING bzw. LIMIT SCREWING. Die

Attribute OP ID, TSTAMP und LIMIT ID werden beim Einfugen auf die gleichnamigen Spal-

ten der Zieltabelle abgebildet und das Attribut PART NUMBER wird in die Spalte OPEL ID

der Zieltabelle geschrieben. Die Attribute MEASUREMENT VALUE DIM1 und MEASURE-

MENT VALUE DIM2 werden je nach Zieltabelle auf die Spalten DISTANCE und FORCE oder

ANGLE und TORQUE abgebildet. Alle Spalten der beiden Zieltabellen SCREWING und PRES-

SING sind als NOT NULL deklariert. Die Eindeutigkeit in den beiden Tabellen wird jeweils durch

den Primarschlussel, der sich aus den Spalten OPEL ID und OP ID zusammensetzt, sichergestellt.

Ein bereits vorhandener Datensatz mit gleichem Schlusselwert wie der neu zu speichernde Daten-

satz, wird uberschrieben, sofern der neu zu speichernde Datensatz den großeren Zeitstempel der

beiden Datensatze besitzt.

Die Uberprufung der ermittelten Integritatsbedingungen bezuglich der Wertebereiche und der Ein-

haltung der Toleranzbereiche, die in den Tabellen SCREWING OPERATION und PRESSING


OPERATION erfasst sind (vgl. Abschnitt 6.2), erfolgen mithilfe von CHECK-Klauseln und Trig-

gern. Bei Verletzung einer Integritatsbedingung wird der ursprungliche Datensatz in die Tabelle

ERROR MEASUREMENT geschrieben.

Sollte in der Tabelle TRANSMISSION kein Datensatz mit entsprechender Getriebe-Seriennummer

existieren, wird der Datensatz von diesem Prozess vor Einfugen des Press- bzw. Schraubkraft-

datensatzes angelegt. Diese Vorgehensweise ermoglicht es auch Datensatze zu speichern, deren

Getriebe-Seriennummer nicht in der Kombinationstabelle auftaucht. Diese Vorgehensweise ist

ausdrucklich erwunscht.

Da es ungewiss ist, ob die Station ST300 jemals Ausschleusungsdaten senden wird, wird nach

jedem Speichern eines Press- oder Schraubkraftdatensatzes der Wert des Attributs TSTAMP in die

Spalte DATE EXIT des entsprechenden Getriebe-Datensatzes in der Tabelle TRANSMISSION

eingetragen, sofern der neue Zeitstempel großer als der vorhandene ist. Nach Abarbeitung aller

Datensatze eines Getriebes beinhaltet die Spalte DATE EXIT schließlich einen Zeitpunkt, der dem

tatsachlichen Ausschleusungszeitpunkt zeitlich gesehen am nachsten liegt. Diese Vorgehensweise

bleibt auch dann bestehen, wenn die Station ST300 Daten sendet. Auf diese Weise konnen Ausfalle

bei der Datenerfassung an der Station ST300 kompensiert werden.

2. Phase Nachdem alle neu eingetroffenen DFQ-Dateien verarbeitet wurden, werden die Schraub-

und Presskraftdatensatze aus der Vormontage mit den Kombinationsdaten kombiniert, um die

einzelnen Datensatze den einzelnen Getrieben zuzuordnen. Dazu werden die Datensatze in der

Tabelle COMBINATION mit denen in der Tabelle IMPORT MEASUREMENT kombiniert. Ab-

bildung 6.2 zeigt den dabei verwendeten EQUI-Join. Die Datensatze aus der Vormontage, die nach

der Kombination uber eine Getriebe-Seriennummer verfugen, werden schließlich auf die gleiche

Weise in die Zieltabellen geladen wie die Daten aus der Endmontage in der ersten Phase.

6.3.3 Einlesen und Bereinigen der Shim-Daten

Das Dateiformat einer Shim-Datei ist in Abschnitt 4.5 beschrieben. Die Shim-Datei wird zei-

lenweise eingelesen, dabei wird jeder Datensatz nach erfolgter Datentypkonvertierung der Fel-

der SHIM CLASS und TSTAMP in die Tabelle SHIM geschrieben. Alle Spalten in der Tabel-

le SHIM sind als NOT NULL deklariert. Zur Definition der gultigen Wertebereiche der Spalten

SHIM CLASS und SHAFT sind entsprechende CHECK-Klauseln deklariert. Die Eindeutigkeit in

der Tabelle SHIM wird durch den Primarschlussel, der sich aus den Spalten OPEL ID und SHAFT

zusammensetzt, sichergestellt. Ein bereits vorhandener Datensatz mit gleichem Schlusselwert wie

der neu zu speichernde Datensatz, wird uberschrieben, sofern der neu zu speichernde Datensatz

den großeren Zeitstempel der beiden Datensatze besitzt. Sollte in der Tabelle TRANSMISSION

kein Datensatz mit entsprechender Getriebe-Seriennummer existieren, so wird der Datensatz von


SELECTOPEL_ID, I.PART_NUMBER,ATTRIBUTE, SPINDLE,STATION, STEP,TYPE, TSTAMP,MEASURING_VALUE_DIM1, MEASURING_VALUE_DIM2,LOWER_LIMIT_DIM1, LOWER_LIMIT_DIM2,UPPER_LIMIT_DIM1, UPPER_LIMIT_DIM2

FROMCOMBINATION C, IMPORT_MEASUREMENT I

WHEREC.VIRTUAL_ID = I.PART_NUMBER

ANDSTATION_ID = STATION

Abbildung 6.2: EQUI-Join zur Zuordnung der Schraub- und Presskraftdaten aus der Vormontagezu den einzelnen Getrieben

diesem Prozess vor Einfugen des Shim-Datensatzes angelegt. Fehlerhafte Shim-Datensatze wer-

den in die Tabelle ERROR SHIM geschrieben.

6.3.4 Einlesen und Bereinigen der Ausschleusungsdaten

Das Eingabeformat einer Datei mit Ausschleusungsdaten ist in Abschnitt 4.6 beschrieben. Je-

des in der Quelldatei erfasste Ausschleusungsdatum wird nach erfolgter Datentypkonvertierung

in die Spalte DATE EXIT des entsprechenden Getriebe-Datensatzes in der Tabelle TRANSMIS-

SION eingetragen. Ein in der Spalte DATE EXIT bereits eingetragener Zeitstempel wird dabei

uberschrieben, sofern der neu einzutragende Zeitstempel großer als der bestehende ist. Sollte in

der Tabelle TRANSMISSION kein Datensatz mit entsprechender Getriebe-Seriennummer existie-

ren, so wird der Datensatz von diesem Prozess angelegt.

6.3.5 Bereinigen der Import- und Fehlertabellen

Um ein zu starkes Anwachsen der Datenmengen in den Fehler- sowie Importtabellen zu ver-

hindern, werden die einzelnen Tabellen regelmaßig bereinigt. Dazu werden Datensatze, deren

Einfugezeitpunkte langer als eine bestimmte Zeitspanne zuruckliegen und daher mit hoher Wahr-

scheinlichkeit nicht mehr benotigt werden, aus den Tabellen geloscht. Der Einfugezeitpunkt eines

Datensatzes wird der Spalte DATE INSERT entnommen. Fur jede Tabelle wird ein eigener Wert

fur die”Verfallszeitspanne“ definiert.

Kapitel 7

Implementierung

In diesem Kapitel wird auf die Implementierung der in Abschnitt 6.3 definierten Datenbereini-

gungsprozesse (Abschnitt 7.1) sowie des Frontends (Abschnitt 7.2) eingegangen.

7.1 Die Applikation QSF40

Die einzelnen Datenbereinigungsprozesse sind unter Verwendung der Programmiersprache Java

(J2SE 1.4.1) innerhalb einer Standalone-Applikation mit dem Namen”QSF40“ implementiert. Es

werden also keine externen Tools zum Einlesen der CSV-Dateien verwendet oder sonstige Pro-

gramme/Skripte auf Betriebsystemebene aufgerufen. Demnach existiert abgesehen von der Da-

tenbank keine Kopplung mit anderen Applikationen, so dass die Applikation plattformunabhangig

ist und einfach installiert werden kann. Der Aufbau der Applikation in ihren wesentlichen Kom-

ponenten ist in Abbildung 7.1 schematisch dargestellt. Die einzelnen Datenbereinigungsprozesse

sind dabei in grauer Farbe dargestellt. Die durchgezogenen Pfeile skizzieren die verschiedenen

Datenflusse und die gestrichelten Pfeile deuten Prozessaufrufe an.

Der Timer startet in konstanten Zeitabstanden den Thread”ConsolidationTask“. Dieser Thread

ruft schließlich nacheinander die einzelnen Datenbereinigungsprozesse auf, die fur das Einlesen

der Quelldateien und das Abspeichern der Quelldaten in der Datenbank verantwortlich sind. Zu-

griffe auf die Datenbank durch die Datenbereinigungsprozesse erfolgen ausschließlich uber eine

Datenbankabstraktionssschicht. Der Logger unterstutzt das Application-Logging und der Session-

Buffer ermoglicht allen anderen Komponenten einen Zugriff auf verschiedene Konfigurationsein-

stellungen der Applikation, die uber eine Konfigurationsdatei vorgenommen werden konnen. Die

ausfuhrbare Klasse der Applikation ist die Klasse qsf40.QSF40.

Der Timer

Bei dem Timer handelt es sich um eine Instanz der Klasse java.util.Timer, die in der Me-

thode main der Klasse qsf40.QSF40 und damit kurz nach dem Starten der Applikation erzeugt

77

KAPITEL 7. IMPLEMENTIERUNG 78

Datenbank

Applikation QSF40

Tim

er Consolidation-Task

ShimFileReader

CombinationTask

CleaningTask

CombinationDataLoadingTask

Se

ssio

n-

Bu

ffer

Log

ger

DFQFileReader

Combination-FileReader

ExitData-FileReader

Measurement-LoadingTask

ShimData-LoadingTask

ExitData-LoadingTask

Da

ten

ban

k-a

bstr

aktio

ns-

sch

ich

t

Abbildung 7.1: Aufbau der Applikation QSF40

wird. Der Thread”ConsolidationTask“, der von dem Timer gestartet wird, wird durch die von der

Klasse java.util.TimerTaskabgeleiteten Klasse qsf40.tasks.ConsolidationTask

implementiert. Zur Registrierung des”ConsolidationTask“ -Threads beim Timer wird die Methode

scheduleAtFixedRate()des Timer-Objektes verwendet. Diese Methode stellt sicher, dass

der Thread”ConsolidationTask“ und damit die Datenbereinigung in konstanten Zeitabstanden,

unabhangig davon wie lange die einzelnen Ausfuhrungen der Datenbereinigung dauern, gestartet

wird. Der Zeitabstand zwischen zwei Ausfuhrungen der Datenkonsolidierung sowie der Zeitpunkt

der ersten Ausfuhrung nach dem Start der Applikation konnen uber die bereits erwahnte Konfigu-

rationsdatei definiert werden.

Die Datenbankabstraktionsschicht

Die Datenabstraktionsschicht wird durch die Klasse qsf40.DBConnection implementiert. Sie

kapselt ein java.sql.Connection-Objekt und samtliche SQL-Statements, die im Rahmen

der Datenkonsolidierung zur Anwendung kommen, in entsprechenden Methoden. Daruber hinaus

ist die Klasse fur das Offnen und Schließen der Datenbankverbindung verantwortlich. Zugriffe auf

die Datenbank durch die Datenbereinigungsprozesse erfolgen ausschließlich uber entsprechende

Methodenaufrufe der Datenbankabstraktionsschicht.

Der Logger

Mithilfe des Loggers konnen Fehlermeldungen und sonstige Meldungen seitens der Applikati-

on protokolliert werden, um das Uberwachen und Debuggen der Applikation zu erleichtern. Der


Logger ist mithilfe der Java Logging API (Paket java.util.logging) realisiert. Das Log-

Level sowie das Verzeichnis, in dem die Log-Datei gespeichert wird, konnen ebenfalls uber die

Konfigurationsdatei definiert werden.

Die Datei-Parser

Zum Einlesen der Quelldateien steht fur jeden Quelldatei-Typ ein eigener Datei-Parser zur Verfu-

gung. Die verschiedenen Datei-Parser sind in den folgenden Klassen implementiert:

• qsf40.reader.CombinationFileReader (Kombinationsdaten)

• qsf40.reader.ShimFileReader (Shim-Daten)

• qsf40.reader.ExitDataFileReader (Ausschleusungsdaten)

• qsf40.reader.DFQFileReader (Schraub- und Presskraftdaten)

Der Parser fur DFQ-Dateien ist dabei in der Lage, alle in der Montagelinie erzeugten DFQ-Dateien

einzulesen. Alle Parser-Klassen implementieren eine Methode readLine(), die je nach Parser-

Klasse ein Objekt der Klasse qsf40.Combination,qsf40.Shim,qsf40.ExitDataoder

ein Array mit Objekten der Klasse qsf40.Measurement zuruckliefert. Die ersten drei ge-

nannten Klassen kapseln jeweils alle Werte einer Zeile der entsprechenden CSV-Datei. Die Klasse

Measurement kapselt alle relevanten Werte, die zu einer Schraub- bzw. Pressoperation gespei-

chert werden sollen. Jedes Measurement-Objekt besitzt damit sowohl Werte der zuletzt ge-

lesenen Zeile aus dem Werteteil als auch Werte aus dem Beschreibungsteil, der unmittelbar nach

Offnen der DFQ-Datei komplett ausgewertet wird. Werte weiterer nicht relevanter Schlusselfelder,

die ggf. in einer DFQ-Datei gespeichert sind, werden beim Einlesen ignoriert. Die Anzahl der

Measurement-Objekte im zuruckgelieferten Array ist abhangig von der Anzahl der Qualitats-

merkmale, die bei der Bearbeitung eines Teils erfasst wurden (Anzahl Spindeln bei Schraubkraft-

dateien, Anzahl Schritte bei Presskraftdateien).

Der SessionBuffer

Die Klasse qsf40.SessionBuffer dient der Speicherung verschiedener Konfigurationsein-

stellungen der Applikation sowie einer Referenz auf das Logger-Objekt uber die gesamte Lauf-

zeit der Applikation. Bei der Implementierung der Klasse wurde das Singleton-Muster realisiert,

so dass uber einen Aufruf der Methode getInstance() aus allen Komponenten der Appli-

kation auf das Singleton-Objekt und damit auf die Konfigurationseinstellungen und den Logger

zugegriffen werden kann. Beim ersten Aufruf der Methode getInstance(), der in der Me-

thode main der Klasse qsf40.QSF40 vor Erzeugung der Timer-Instanz erfolgt, werden die

in der Datei qsf40.properties gespeicherten Konfigurationseinstellungen eingelesen. Die


Konfigurationsdatei beinhaltet im Wesentlichen die Verbindungsdaten zur Datenbank, die Namen

der Eingangsverzeichnisse, das Log-Level, die Zeitspanne zwischen zwei Ausfuhrungszeitpunkten

der Datenbereinigung sowie die Zeitspannen, nach denen Datensatze aus den jeweiligen Fehler-

und Hilfstabellen geloscht werden sollen (vgl. Abschnitt 6.3.5). Uber entsprechende Methoden-

aufrufe konnen die Einstellungen abgefragt werden. Nach Einlesen der Konfigurationsdatei wird

das Logger-Objekt erzeugt und ein Verbindungstest zur Datenbank durchgefuhrt. Tritt dabei ein

Fehler auf, wird die Applikation vorzeitig beendet.

Die Datenbereinigungsprozesse

Fur jeden der in Abschnitt 6.3 definierten Datenbereinigungsprozesse existiert eine eigene Klasse.

Dabei handelt es sich um folgende Klassen:

• qsf40.tasks.CombinationDataLoadingTask (Laden und Bereinigen der Kom-

binationsdaten)

• qsf40.tasks.MeasurementLoadingTask (Laden und Bereinigen der Schraub- und

Presskraftdaten - 1. Phase)

• qsf40.tasks.CombinationTask (Laden und Bereinigen der Schraub- und Presskraft-

daten - 2. Phase)

• qsf40.tasks.ShimDataLoadingTask (Laden und Bereinigen der Shim-Daten)

• qsf40.tasks.ExitDataLoadingTask (Laden und Bereinigen der Ausschleusungs-

daten)

• qsf40.tasks.CleaningTask (Bereinigen der Fehler- und Hilfstabellen)

Jede dieser Klassen verfugt uber eine Methode run(), die den entsprechenden Datenbereini-

gungsprozess implementiert und von dem Thread”ConsolidationTask“ aufgerufen wird. Jeder

Bereinigungsprozess, der Quelldateien einliest, uberpruft anfangs das Eingangsverzeichnis auf

neu eingetroffene Quelldateien. Jeder Datenbereinigungsprozess verfugt dabei uber ein eigenes

Eingangsverzeichnis, welches in der Konfigurationsdatei spezifiziert werden kann. Beinhaltet das

Eingangsverzeichnis keine Quelldateien, so wird der Prozess beendet. Anderenfalls werden alle

Quelldateien im Eingangsverzeichnis nacheinander mithilfe des passenden Datei-Parsers eingele-

sen. Die in den Quelldateien gespeicherten Daten werden gemaß den in Abschnitt 6.3 beschriebe-

nen Definitionen der Datenbereinigungsprozesse verarbeitet. Nach erfolgreichem Abarbeiten ei-

ner Quelldatei wird diese aus dem Eingangsverzeichnis geloscht. Sobald alle Dateien erfolgreich

abgearbeitet und geloscht wurden, wird der Datenbereinigungsprozess beendet. Zur Speicherung

der Schraub- und Presskraftdaten greifen die beiden Prozesse”MeasurementLoadingTask“ (Laden

und Bereinigen der Schraub- und Presskraftdaten - 1. Phase) und”CombinationTask“ (Laden und


Bereinigen der Schraub- und Presskraftdaten - 2. Phase) auf dieselbe Routine zu.

Bei der Implementierung der Datenbereinigungsprozesse wurde ein großes Augenmerk auf die

Ausnahmebehandlung gelegt, um eine hohe Stabilitat der Applikation zu erreichen sowie Da-

tenverluste zu vermeiden. Es wird sichergestellt, dass eine Quelldatei nur dann geloscht wird,

wenn sie auch fehlerfrei abgearbeitet werden konnte. Bei schwerwiegenden Fehlern (z. B. Nicht-

Erreichbarkeit der Datenbank) wird ein Datenbereinigungsprozess direkt mit einer entsprechenden

Fehlermeldung beendet.

7.2 Das Frontend

Das Frontend wurde mithilfe von JavaServerPages (JSP) realisiert. Aufgrund der wenig komplexen

Business-Logik wurde auf ein Prasentationsframework (z. B. Struts) zur Trennung von Business-

Logik und Layout oder auf einen Application-Server verzichtet. Bei der Implementierung wurde

u. a. fur die Datenbankanbindung die Java Standard Tag Library verwendet. Als Servlet-Container,

in dessen Umgebung die Seiten implementiert und getestet wurden, wurde der Tomcat 4.1 verwen-

det. Insgesamt besteht das Frontend aus den folgenden JSP-Dateien:

• search.jsp. Diese Seite ist die Startseite des Frontends, sie zeigt eine Eingabemaske zur

Spezifizierung der Suchkriterien an, fuhrt die Suche durch und zeigt nach einer erfolgreichen

Suche die Trefferliste an (vgl. Anwendungsfalle 1 und 2 in Abschnitt 3.4).

• station overview.jsp. Diese Seite zeigt, nachdem in der Trefferliste ein Getriebe

ausgewahlt wurde, alle Stationen an, zu denen Qualitatsdaten des ausgewahlten Getriebes

in der Datenbank vorhanden sind (vgl. Anwendungsfall 1 in Abschnitt 3.4).

• pressing screwing data.jsp. Diese Seite zeigt, nachdem in der Liste der Statio-

nen eine Station ausgewahlt wurde, alle Schraub- und Presskraftdaten bezuglich des aus-

gewahlten Getriebes und der ausgewahlten Station an (vgl. Anwendungsfall 1 in Abschnitt 3.4).

• shim data.jsp. Diese Seite zeigt die Shim-Daten eines Getriebes an. Sie wird aufgeru-

fen, wenn auf der Seite station overview.jsp die Station ST150 ausgewahlt wurde

(vgl. Anwendungsfall 1 in Abschnitt 3.4).

Kapitel 8

Tests der Applikation QSF40

In diesem Kapitel wird die Vorgehensweise bei den durchgefuhrten Tests der Applikation QSF40

erlautert. Da ein Test der Applikation unter Realbedingungen, also bei laufendem Montagebetrieb

nicht durchgefuhrt werden konnte, weil die Prozesse zurUbertragung der Daten von den Montage-

Stationen zum Server bis zuletzt nicht eingerichtet waren, wurde eine GUI-gestutze Applikation

mit dem Namen”QSF40Sim“ implementiert, die das Verhalten der Montagelinie aus Sicht der

Applikation QSF40 simuliert. In Abschnitt 8.1 wird diese Applikation in ihrem Aufbau und ihrer

Funktionsweise grob beschrieben. In Abschnitt 8.2 werden schließlich die durchgefuhrten Tests

erlautert.

8.1 Die Applikation QSF40Sim

Die Applikation QSF40Sim simuliert das Verhalten der Montagelinie, indem sie Quelldateien in

die Eingangsverzeichnisse der Applikation QSF40 ubertragt, was unter Realbedingungen durch

die Datenubertragungsprozesse geschieht. Die abgelegten Quelldateien beinhalten dabei Prozessda-

ten, die von der Applikation QSF40Sim selbst erzeugt werden. Die verwendeten Dateiformate sind

aquivalent zu den Original-Dateiformaten aus der Montagelinie.

Die Applikation QSF40Sim stellt ein komplettes Modell der Montagelinie dar. Der Aufbau der

Montagelinie wird im Wesentlichen durch Instanzen folgender Klassen abgebildet:

• qsf40sim.Palette

• qsf40sim.Spindle

• qsf40sim.ControlUnit

• qsf40sim.Station

Objekte der Klasse Palette reprasentieren Paletten, auf denen Teile transportiert werden, und

speichern daher Seriennummern von Komponenten bzw. Getrieben. Spindle-Objekte reprasen-

82

KAPITEL 8. TESTS DER APPLIKATION QSF40 83

tieren Spindeln und sind fur das Erzeugen von Prozessdaten zustandig. ControlUnit-Objekte

stellen die Datei-generierenden Systeme dar. Sie ubertragen nach Abschluss einer Schicht die in

den Spindle-Objekten erzeugten Daten in Form von Textdateien in die Eingangsverzeichnisse

der Applikation QSF40. Die Station-Objekte reprasentieren die Stationen der Montagelinie.

Uber Referenzen ist jedes Station-Objekt sowohl mit dem Objekt der vorgeschalteten Station

als auch mit dem Objekt der nachgeschalteten Station verknupft. Ein Station-Objekt ist fur die

Annahme und Weitergabe von Palette-Objekten zustandig. Nach Annahme eines Palette-

Objektes liest das Station-Objekt die Seriennummer aus und veranlasst die Erzeugung von

Prozessdaten zu der eingelesenen Seriennummer. Da die Ausgangsstationen, die Endstation sowie

die Station ST140 ein anderes Verhalten als die sonstigen Stationen aufweisen, existieren fur diese

Stationen entsprechende Unterklassen der Klasse Station.

Zur Abbildung des Montageprozesses wurde das Erzeuger/Verbraucher-Muster implementiert.

Jedes Station-Objekt lauft innerhalb eines eigenen Threads und verhalt sich gleichzeitig aus

Sicht seines Vorganger-Objektes als”Verbraucher“ und aus Sicht seines Nachfolger-Objektes als

”Erzeuger“ von Palette-Objekten, indem es kontinuierlich bei seinem Vorganger-Objekt ein

Palette-Objekt anfordert und es nach einer definierten Durchlaufzeit an sein Nachfolger-Objekt

freigibt. Produziert ein Station-Objekt wesentlich langsamer als sein Nachfolger-Objekt, so

muss das Nachfolger-Objekt solange warten, bis ihm ein neues Palette-Objekt ubergeben wird.

Gleichermaßen konnen sich Palette-Objekte aufstauen, wenn ein Station-Objekt wesentlich

langsamer als sein Vorganger-Objekt arbeitet. Uberschreitet die Zahl der aufgestauten Palette-

Objekte einen bestimmten Wert, kommt es zu einem”Produktionsstillstand“ bei dem Vorganger-

Objekt.

Die Spindle-Objekte erzeugen mithilfe von Zufallsgeneratoren (Klasse java.util.Random)

Prozessdaten, worunter sich auch Daten mit syntaktischen Fehlern und fehlenden Werten befinden.

Daruber hinaus konnen auch Anderungen der Grenzwerteinstellungen sowie Wiederholungen von

Operationen simuliert werden. Die Dauer einer Schicht sowie die Durchlaufzeiten der einzelnen

Stationen konnen spezifiziert werden. Indirekt lasst sich mithilfe dieser Parameter die Stuckzahl

der in einer Schicht montierten Getriebe definieren.

8.2 Durchfuhrung der Tests

Die Basisklassen der Applikation QSF40 wurden fortlaufend wahrend der Implementierungspha-

se getestet. Zweck der Tests war es mithilfe von Testfallklassen die korrekte Funktionsweise der

einzelnen Klassen zu testen, wie etwas das korrekte Einlesen von Quelldateien durch die ent-

sprechenden Datei-Parser oder das korrekte Ausfuhren der SQL-Statements in der Datenbankab-

straktionsschicht. Zum Testen der Parser-Klassen wurden sowohl selbst erzeugte Dateien aller

Quelldatei-Typen als auch DFQ-Dateien, die von dem Lieferanten Promess zur Verfugung gestellt

wurden, verwendet. In einem nachsten Schritt wurden mithilfe der Basisklassen die Datenberei-

KAPITEL 8. TESTS DER APPLIKATION QSF40 84

nigungsprozesse implementiert und hinsichtlich ihrer korrekten Funktionsweise isoliert voneinan-

der getestet. In einem letzten Schritt wurden die Implementierungen der einzelnen Bereinigungs-

prozesse zu einer ganzen Applikation zusammengefugt. Bei den anschließenden Tests der Ap-

plikation standen im Gegensatz zu den vorangegangenen Tests Aspekte wie Speicherverbrauch,

CPU-Auslastung und Stabilitat unter moglichst realistischen Bedingungen im Vordergrund. Ein

Vorteil bei der Zuhilfenahme der Applikation QSF40Sim bestand in der Moglichkeit, die Schicht-

dauer, die in der Realitat acht Stunden betragt, deutlich zu verkurzen ohne dabei die Menge

der erzeugten Daten zu reduzieren. Damit war es moglich die Applikation QSF40 uber einen

langeren Zeitraum mit realistischen Datenmengen zu testen, wobei lediglich die Zeitraume zwi-

schen zwei Ausfuhrungszeitpunkten der Datenbereinigungsprozesse verkurzt waren. Wahrend der

Testdurchfuhrungen liefen die Applikation QSF40 sowie die Oracle-Datenbank (Oracle 9.1, Stan-

dardinstallation) auf einer Sun UltraSPARC 60 Workstation mit einem 450MHz Prozessor und

2GB Arbeitspeicher unter Sun Solaris 8.0. Die Applikation QSF40Sim lief wahrend dessen auf

einem separaten Personal Computer. Die von der Applikation QSF40Sim erzeugten Quelldateien

wurden fortlaufend uber das Netzwerk in die auf der Sun Workstation befindlichen Eingangsver-

zeichnisse kopiert.

Bei allen Testdurchfuhrungen betrug die Schichtdauer 45 Minuten und die Durchsatzrate ca. 350

Getriebe/Schicht. Theoretisch hatte die Schichtdauer auch auf wenige Minuten verkurzt werden

konnen, doch benotigt die Applikation QSF40 einen Zeitraum von bis zu 40 Minuten, die Daten ei-

ner Schicht (350 Getriebe, 12.250 Datensatze) in die normalisierte Datenbank zu schreiben. Um zu

gewahrleisten, dass die Applikation QSF40 bis Abschluss einer Schicht alle Daten der vorangegan-

gen Schicht abgearbeitet hat, wurde die genannte Schichtdauer gewahlt. Die Gesamtdauer jeweils

einer Testdurchfuhrung war unterschiedlich lang und lag zwischen einer Schichtdauer und drei

Tagen. Bei allen Tests lag die CPU-Auslastung wahrend der Ausfuhrung der Datenbereinigungs-

prozesse in einem unkritischen Bereich, der Speicherverbrauch lag ebenfalls nach anfanglichem

Ansteigen konstant bei einem unkritischen Wert.

Mithilfe der durchgefuhrten Tests konnten Unzulanglichkeiten bei der Ausnahmebehandlung auf-

gedeckt werden. Nach einigen Verbesserungen bei der Ausnahmebehandlung lief die Applikation

schließlich stabil.

Kapitel 9

Fazit

Die Heterogenitat der Quellsysteme ist nicht sehr stark ausgepragt, da nur wenige Hersteller an der

Entwicklung der Quellsysteme beteiligt sind und die Formate fur die Schraub- und Presskraftdaten

standardisiert sind. Außerdem existieren zwischen den einzelnen Datensatzen keine komplexen

Abhangigkeiten. Die Bereinigung der Quelldaten kann mithilfe der in der Zieldatenbank definier-

ten Integritats-Constraints durchgefuhrt werden, wobei allerdings auf eine Plausibilitatskontrolle

der Zeitstempel verzichtet wird. Infolge der eben genannten Punkte ist die Integration der Quell-

daten unproblematisch.

Die Implementierung der Datenbereinigungsprozesse als Standalone-Applikation in Java ohne Zu-

hilfenahme externer Tools stellt eine schwache Kopplung zu anderen Applikationen sicher. Es ist

ohne großen Aufwand moglich, Qualitatsdaten weiterer Spindeln, die ursprunglich nicht im An-

forderungsbereich lagen, von der Applikation erfassen zu lassen. Hierzu muss lediglich in einer

bestimmten Tabelle der Zieldatenbank ein Datensatz angelegt werden.

Trotz nicht abgeschlossener Einrichtung der Datenubertragungsprozesse in der Montagelinie konn-

te die Applikation mithilfe der Applikation QSF40Sim unter annahernd realistischen Bedingun-

gen getestet werden. Unter Testbedingungen funktionierte die implementierte Losung im Bezug

auf Performance und Stabilitat gut, so dass die Testergebnisse als positiv zu bewerten sind.

Mit der Applikation QSF40 zur Datenkonsolidierung sowie dem realisierten Frontend zur Erzeu-

gung aller geforderten Reports, sind alle gestellten Anforderungen der Opel Powertrain GmbH

erfullt.

Unabhangig davon sei jedoch erwahnt, dass die Datenqualitat stark von der Disziplin der Arbeiter

und deren strikter Einhaltung des Fertigungsprozesses abhangt. Gelegentlich werden Getriebe auf

Paletten ausgetauscht, ohne dass die Getriebe-Seriennummer auf dem Datentrager der betroffe-

nen Palette entsprechend aktualisiert wird. Dies gilt auch fur den Austausch von Komponenten

und deren virtuelle Kennungen bei Reparaturen. Es ist vorgekommen, dass ein fertig montiertes

Getriebe auseinandergebaut, die auf dem Gehause eingelaserte Getriebe-Seriennummer ausgefeilt

wurde und das Getriebe anschließend unter einer anderen Getriebe-Seriennummer in die Monta-

85

KAPITEL 9. FAZIT 86

gelinie eingeschleust wurde. In solchen Fallen konnen selbstverstandlich trotz Durchfuhrung einer

Datenbereinigung keine korrekten Daten zur Verfugung gestellt werden.

Literaturverzeichnis

[1] Fiat-GM-Powertrain Manufacturing Engineering. General specification for measuring value-

generating systems at SPC applications, Version 2.0, 2003

[2] Rahm, Erhard; Do, Hong-Hai. Data Cleaning: Problems and Current Approaches, IEEE

Bulletin of the Technical Committee on Data Engineering, Vol 23 No. 4, December 2000

[3] Maletic, Jonathan; Marcus, Andrian. Data Cleaning: Beyond Integrity Analysis, in Procee-

dings of The Conference on Information Quality (IQ2000), Massachusetts Institute of Techno-

logy, October 20-22, 2000, pp. 200-209

[4] Muller, Heiko; Freytag, Johann-Christoph. Problems, Methods, and Challenges in Compre-

hensive Data Cleansing, Technical Report HUB-IB-164, Humboldt University Berlin, 2003

[5] Opel Powertrain Manufacturing Engineering. Pflichtenheft SPC-Netzwerk, 2001

[6] Q-DAS GmbH. Q-DAS ASCII Transferformat, 2003

[7] BAB Automationstechnik GmbH. Programmbeschreibung Opel F40 - Station 140, 2002

[8] General Motors Engineering. GME Liste der Aufbewahrungszeiten fur Qualitatsdokumente

und -aufzeichnungen, D10A1D4 Revision 5, 2000

[9] Grote, K.-H.; Beitz, W. Taschenbuch fur den Maschinenbau, Springer, 19. Auflage, 1997

[10] Witten, I.H.; Frank, E. Data Mining - Praktische Werkzeuge und Techniken fur das maschi-

nelle Lernen, Hanser, 2001

87

Anhang A

Tabellen

88

ANHANG A. TABELLEN 89

Code Merkmal

0017DW Drehwinkel0017AR Drehwinkel1916DM Drehmoment1916TQ Drehmoment1503ET Einpresstiefe1503PD Einpresstiefe1505EK Einpresskraft1505PF Einpresskraft

Tabelle A.1: Codes zur Identifizierung der Qualitatsmerkmale

Schlusselfeld Bedeutung

K0001 MesswertK0002 FehlercodeK0004 ZeitstempelK0006 SeriennummerK0007 SpindelnummerK0008 StationsnummerK2001 MerkmalscodeK2110 Unterer GrenzwertK2111 Oberer Grenzwert

Tabelle A.2: Von einer DFQ-Datei zu untersutzende Schlusselfelder eines Qualitatsmerkmals

Documents

Echtzeitdatenerfassung und Datenkonsolidierung zur ... · Universitat des Saarlandes, FR Informatik¨ Max-Planck-Institut f¨ur Informatik, AG5 Diplomarbeit im Fach Informatik Echtzeitdatenerfassung