Masterarbeit - fim.uni-passau.de

Universität Passau
Fakultät für Informatik und Mathematik
Lehrstuhl für Mathematik
Schwerpunkt Digitale Bildverarbeitung
Prof. Dr. Tomas Sauer
Masterarbeit
zur Erlangung des akademischen Grades
Master of Science (M.Sc.)
Konzept eines zentralen
Fertigungsdaten-Management-Systems
Florian Bürchner
Studienfach
Erstprüfer
Zweitprüfer
Matrikelnummer
Datum
Informatik
Prof. Dr. Tomas Sauer
Prof. Dr. Ilia Polian
55508
7. Mai 2014
Danksagung
Zunächst möchte ich mich bei all denjenigen bedanken, die mich während der Anfertigung
dieser Masterarbeit unterstützt und motiviert haben.
Ganz besonders gilt dieser Dank Prof. Dr. Tomas Sauer, der den Kontakt zur ZF Friedrichshafen AG für mich bereits im Rahmen eines Praktikums und nun auch für diese
Abschlussarbeit hergestellt hat und Dr. Werner Schnitzlein, der seitens der ZF dieses interessante Thema ermöglicht hat und sich für eine Kooperation zwischen Universität und
Unternehmen einsetzt. Weiterhin bedanke ich mich bei Prof. Dr. Ilia Polian, der sich als
Zweitprüfer zur Verfügung gestellt hat.
Ebenfalls bedanken möchte ich mich bei meinem Betreuer Dipl.-Inf. Joseph Mandic für
seine ausgiebige Unterstützung und seine konstruktive Kritik, die mich oft auf den richtigen Kurs zurückgebracht hat. Weiterhin danke ich Dipl.-Ing. Ralf Kleinschmidt ohne
dessen Hilfe und Bemühungen in etlichen Diskussionen diese Arbeit nicht zustande gekommen wäre. Auch M. Eng. Patrick Peter danke ich, dass er mir stets mit Rat und Tat
zur Seite stand und immer ein offenes Ohr für mich hatte. Außerdem bedanke ich mich
bei B. Eng. Alex Nowitschkow, der immer für mich ansprechbar war und mich mit guten
Ideen unterstützt hat.
Nicht zuletzt gebührt meiner Familie großer Dank, insbesondere meinen Eltern, die mir
mein Studium ermöglicht und mich in all meinen Entscheidungen unterstützt haben.
3
4
Inhaltsverzeichnis
Abkürzungsverzeichnis
1. Einleitung
1.1. Problemstellung
1.2. Motivation . . .
1.3. Zielsetzung . .
1.4. Abgrenzung . .
1.5. Überblick . . .
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2. Systemlandschaft
2.1. PLM–Strategie . . . . . . . . .
2.2. Applikationen im FDO–Bereich
2.2.1. Übersicht . . . . . . . .
2.2.2. Axalant . . . . . . . . .
2.2.3. FATool . . . . . . . . . .
2.2.4. SAP . . . . . . . . . . .
2.2.5. EdgeCAM . . . . . . . .
2.2.6. ProE/CREO . . . . . .
2.3. Schnittstellen . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
11
11
12
12
13
.
.
.
.
.
.
.
.
.
15
16
19
19
20
23
28
29
29
29
3. Grundlagen
3.1. Systemanalyse . . . . . . . . . .
3.1.1. Standards . . . . . . . .
3.1.2. Architektur–Frameworks
3.2. Anforderungsanalyse . . . . . .
3.2.1. Methoden . . . . . . . .
3.2.2. Modellierung . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
34
34
39
44
45
48
4. Ist–Zustand
4.1. Übersicht . . . . . . . . . .
4.2. Status–Quo . . . . . . . . .
4.2.1. Aufbau . . . . . . . .
4.2.2. Datenbank . . . . . .
4.2.3. Schnittstelle . . . . .
4.2.4. Interaktive Rückgabe
4.2.5. Transferdaten . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
57
58
59
59
62
63
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
Inhaltsverzeichnis
4.3. Schwachstellen im Ist–Zustand . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5. Soll–Konzept–Szenario
5.1. Bestehendes Soll–Konzept . . . . . . . .
5.1.1. Übersicht . . . . . . . . . . . . .
5.1.2. Lastenheft . . . . . . . . . . . . .
5.1.3. Schwachstellen . . . . . . . . . .
5.1.4. Bewertung . . . . . . . . . . . . .
5.2. Erweitertes Soll–Konzept . . . . . . . . .
5.2.1. Erweiterungen im Lastenheft . . .
5.2.2. Schwachstellen des Ist–Zustands .
5.2.3. Schwachstellen des Soll–Zustands
5.3. Zusammenfassung . . . . . . . . . . . . .
6. Umsetzung
6.1. Problemstellung . . . . . . . . . . . . .
6.2. Ansatz . . . . . . . . . . . . . . . . . .
6.3. Implementierung . . . . . . . . . . . .
6.3.1. Synchronisation von Materialien
6.3.2. Parsen der Transfer–Queue . . .
6.3.3. Suche nach Dokumentstämmen
6.3.4. Überprüfen der Wiedervorlage .
6.4. Verifikation . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73
73
73
77
85
89
90
90
95
100
108
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
109
. 109
. 110
. 111
. 113
. 113
. 115
. 116
. 118
7. Fazit
123
Anhang
124
Tabellenverzeichnis
143
Abbildungsverzeichnis
145
Literaturverzeichnis
147
6
Abkürzungsverzeichnis
BLD
BOM
BTL
CAD
CAE
CAM
DMZ
DNC
ERP
FDM
FDO
FHM
KWZ
PDM
PDO
PLM
SMID
SML
WKZ
Bildkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Bill of materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Bauteil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Computer–Aided–Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Computer–Aided–Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Computer–Aided–Manufacturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Demilitarized–Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Distributed–Numerical–Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Enterprise–Ressource–Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Fabric–Data–Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Fertigungsdatenorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Fertigungshilfsmittel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Komplettwerkzeug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Product–Data–Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Produktdatenorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Product–Lifecycle–Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Sachmerkmal–ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Sachmerkmalleiste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7
Abkürzungsverzeichnis
8
1. Einleitung
Die Frage nach der optimalen IT–Struktur im Cloud–Zeitalter stellt Unternehmen heutzutage vor große Herausforderungen. Der Wunsch interne Daten weltweit und standortunabhängig zur Verfügung zu stellen wirft die Frage auf, ob periphere Systeme wie die
IT–Landschaft besser zentral organisiert oder als verteilte Ressourcen verwaltet werden
sollen. Der Grund für eine Neuausrichtung sind oftmals neue Anforderungen an alte Systeme, die teilweise eine Anpassung der IT–Architektur des gesamten Unternehmens nach
sich ziehen. Dabei sind diese Anpassungen unumgänglich, um neue Technologien und
Lösungen nutzen zu können und somit die Wettbewerbsfähigkeit zu wahren.
Auch die Zentralisierung bringt eine Reihe von Vorteilen gegenüber verteilten, dezentralen
Systemen mit sich. Neben der Möglichkeit an allen Standorten auf zuverlässige und aktuelle Daten und Dokumente zuzugreifen, was durch einen konsistenten und einheitlichen
Datenbestand sichergestellt wird, können neue Standorte auch leichter in die schon bestehende IT–Landschaft integriert werden. Doch die Zentralisierung wirft auch neue Fragen
auf wie Zugriffskontrollen, die Konfliktbehandlung oder die Performanz beim Zugriff.
Für die Zentralisierung eines bestehenden Systems sind mehrere Architekturmodelle denkbar, die abhängig von bestimmten Qualitätsfaktoren mehr oder weniger geeignet sind.
Diese Faktoren beziehen sich auf technische Anforderungen wie die Qualität der Netzanbindung der verschiedenen Standorte, die Zugriffsmethoden auf einzelne Dateien oder logische Faktoren wie Zugriffsberechtigungen. Den vorgestellten Architekturen ist allen ein
Master–System übergeordnet, das in regelmäßigen zeitlichen Intervallen Kenntnis über
alle im Netz existierenden Daten hat.
Abbildung 1.1.: Direktzugriff auf den Master–Server
Das bekannteste Modell der Zentralisierung stellt der Direktzugriff dar, wie er in Abbildung 1.1 dargestellt ist. Hierbei greifen entfernte Standorte direkt auf den Master–Server
9
1. Einleitung
zu, was zum Vorteil hat, dass viele Probleme, wie sie durch vollständig verteilte Systeme
entstehen, wegfallen. Die Zugriffsberechtigungen können leichter umgesetzt werden und
der Freigabestatus sowie Änderungen an Dateien stehen immer zuverlässig und aktuell
zur Verfügung. Der entscheidende Aspekt bei diesem Modell ist aber dennoch die Datenübertragungsrate zwischen den Standorten, da die entsprechenden Dateien oft sehr groß
sind und dies inakzeptable Zugriffszeiten nach sich ziehen kann.
Abbildung 1.2.: Replikation der Dateien auf den Slave
Eine mögliche Lösung für dieses Problem wäre die Trennung von den eigentlichen Dateien
und deren Meta–Daten, sodass ausschließlich die Dateien auf die verschiedenen Standorte
repliziert werden, die Meta–Daten aber zentral gehalten und über das Netz abgerufen
werden. In einem solchen hybriden System, wie es in Abbildung 1.2 zu sehen ist, sind
die Zugriffszeiten auf Dateien deutlich verbessert. Dennoch müssen die Dateien auf die
dezentralen Server der einzelnen Standorte repliziert werden und bei Änderungen auch
wieder mit dem Master–Server abgeglichen werden. Da dies durch die großen Datenmengen nur in bestimmten zeitlichen Abständen möglich ist, kann es sein, dass Dateien und
die zugehörigen Meta–Daten zeitweise inkonsistent vorliegen.
Abbildung 1.3.: Replikation der Dateien inklusive der Meta–Daten auf den Slave
Eine weitere Möglichkeit ist die Replikation, wie sie in Abbildung 1.3 dargestellt ist.
Hierbei handelt es sich bei den dezentralen Servern der einzelnen Standorte um eine
komplette Kopie des Master–Servers inklusive der Meta–Daten. Dadurch ergibt sich nun
auch ein asynchroner Abgleich, der Konflikte nach sich ziehen kann, wenn Dateien und
damit die zugehörigen Meta–Daten auf verschiedenen Systemen gleichzeitig verändert
werden. Bei großen Dateien und gleichzeitig schlechter Netzanbindung kann dieses Modell
den Zugriff auf Daten erleichtern, schafft aber dadurch auch die typischen Probleme, wie
sie bei verteilten Systemen auftreten. [ES09]
10
1.1. Problemstellung
In dieser Arbeit soll das aktuelle Architekturmodell der Fertigungsdaten–Management–
Software FATool für die ZF Friedrichshafen AG analysiert werden und weitere konzeptionelle Modelle entwickelt werden, die eine Zentralisierung berücksichtigen.
1.1. Problemstellung
Eine unternehmensweit zentrale Ausrichtung der Fertigungsdaten–Management–Software
FATool ist das Thema dieser Arbeit. Ein Konzept über den Soll–Zustand ist bereits vorhanden, wobei durch den hohen Detailgrad der Beschreibung beim Leser bereits tiefe
Einsichten in das System gefordert sind und damit keine Transparenz vermittelt werden
kann. Die aufgeschlüsselten Anwendungsfälle beschreiben bisher nur die Anforderungen
an das System, reflektieren aber nicht die Probleme, die in der Praxis auftreten können.
Vor diesem Hintergrund muss neben einer detaillierten Dokumentation auch eine exakte
Analyse durchgeführt werden, die untersucht, ob bereits im Ist–Zustand bestehende Probleme durch das neue Konzept gelöst werden können oder dadurch neue Probleme hervorgerufen werden. In Anbetracht der gefunden Schwachstellen soll ein eigenes Konzept zur
Zentralisierung erarbeitet werden, das Lösungsansätze für die bekannten Probleme bietet.
Die Suche nach Lösungen für Anforderungen an den Ist–Zustand stellt einen weiteren
wichtigen Punkt im Prozess der Zentralisierung dar. Dabei handelt es sich um Probleme,
die bereits bekannt sind, aber bisher nicht gelöst werden konnten. Es ist offensichtlich,
dass solche Schwachstellen vor der eigentlichen Zentralisierung gelöst werden müssen, denn
Anforderungen an die Systeme, die im Ist–Zustand nicht funktionieren, werden auch im
Soll–Zustand nicht funktionieren können.
1.2. Motivation
Der bedeutendste Punkt der Zentralisierung ist die konzernweite Nutzung aller produktionsrelevanten Daten. Da produzierende Betriebe meist eine große Menge an Objekten in
ihrem Materialstamm verwalten, ist es von enormer Bedeutung vor der Entwicklung eines
neuen, aktuell erforderlichen Teils zu wissen, ob ein solches – an einem anderen Standort
– schon existiert. Die Entwicklung neuer Materialien ist aufwendig, denn sie müssen entworfen, gezeichnet und im PDM–System mit Teilestamm und Stückliste angelegt werden.
Deshalb ist es nicht nur kostengünstiger, sondern auch zeitsparender, bereits existierende
Teile wieder zu verwenden, als eine Neuentwicklung zu veranlassen.
Ein weiterer positiver Nebeneffekt der zentralen Verwaltung ist, dass alle Benutzer auf
einen einheitlichen Datenbestand zurückgreifen können. Des Weiteren wird die Anbindung
neuer Standorte an das zentralisierte System vereinfacht, da die Architektur nicht mehr
entscheidend verändert werden muss.
11
1. Einleitung
1.3. Zielsetzung
Mit der vorliegenden Arbeit soll ein Beitrag geleistet werden, um den Prozess der Zentralisierung zu unterstützen und nachhaltig zu verbessern. Im Einzelnen werden dabei
folgende Ziele verfolgt:
• Dokumentation des Ist–Zustands und des bereits existierenden Soll–Konzepts für
spätere Supportaufgaben
• Analyse der bestehenden Konzepte anhand wissenschaftlicher Kriterien und Identifizierung eventueller Schwachstellen
• Bereitstellen eines eigenen Soll–Konzepts unter Berücksichtigung der aufgedeckten
Schwachstellen mit entsprechenden Lösungsansätzen
• Erarbeitung von technischen Lösungen der Schwachstellen des Ist–Zustands für
einen reibungslosen Betrieb des zentralisierten Konzepts
Durch die gewonnenen Erkenntnisse werden Empfehlungen für die Umsetzung der Zentralisierung ausgesprochen. Während die Analyse der bestehenden Systeme rein konzeptionell
durchgeführt wird, soll für eine der gefundenen Anforderungen eine Lösung erarbeitet und
diese im Anschluss implementiert und validiert werden.
1.4. Abgrenzung
Untersuchungsgegenstand dieser Arbeit ist die Zentralisierung der FDM–Software FATool.
Dieser Prozess betrifft verschiedene Bereiche, zum Einen die Applikation selbst, zum Anderen die Umstellung bzw. Vorbereitung der Systeme und Schnittstellen innerhalb des
ZF–Konzerns. Während der innere Aufbau von FATool aufgrund des geschlossenen Quellcodes als Black–Box zu betrachten ist, liegt die Verantwortung für die Vorbereitung der
systemeigenen Strukturen innerhalb der ZF Friedrichshafen AG.
Aus diesem Grund beschäftigt sich diese Arbeit mit der Analyse der vorhandenen Konzepte und eigenen Konzeptvorschlägen. Es wird jedoch kein Leitfaden geliefert der die
Zentralisierung im Detail beschreibt. Dies erfordert eine enge Zusammenarbeit mit dem
Software–Hersteller und ist nicht als ein Ein–Mann–Projekt zu verstehen. Vielmehr soll
diese Arbeit einen Baustein im Prozess der Zentralisierung darstellen.
Bei den Schnittstellen wird aus Gründen der Komplexität nur die Axa2FASys–
Schnittstelle betrachtet. Andere Schnittstellen werden nur funktional beschrieben.
12
1.5. Überblick
1.5. Überblick
Die Gliederung der Arbeit ist darauf ausgelegt beim Leser ein Verständnis über die Gesamtproblematik der Zentralisierung des FDM–Systems mit denen im ZF–Konzern eingesetzten Systeme zu entwickeln. Die beteiligten System werden exemplarisch am Standort
Passau aufgezeigt. Daraufhin werden die notwendigen theoretischen und wissenschaftlichen Grundlagen erarbeitet und im Anschluss bei der Analyse und Konzeption angewendet.
In Kapitel 2 soll zunächst ein Überblick über alle Systeme gegeben werden, die in Beziehung zu FATool stehen. Des Weiteren sollen die Schnittstellen zwischen diesen Systemen
und FATool beschrieben werden.
Das Kapitel 3 stellt den Theorieteil dieser Arbeit dar und soll die nötigen Grundlagen
für eine Analyse und Bewertung von Software–Architekturen schaffen. Darauf aufbauend
wird in Kapitel 4 der Ist–Zustand dokumentiert und analysiert und anschließend seine
Schwachstellen ausgearbeitet.
In Kapitel 5 wird das bereits bestehende Soll–Konzept analysiert und ein eigenes Konzept
erarbeitet, das die bereits herausgestellten Schwachstellen beseitigt.
Kapitel 6 beinhaltet einen Lösungsansatz für eine der zuvor analysierten Anforderungen.
Es umfasst außerdem deren Implementierung und Validierung.
In Kapitel 7 wird abschließend ein Fazit abgegeben, in dem der Fortschritt im Hinblick auf
den Beginn der Arbeit beleuchtet wird und ein Ausblick auf zukünftige Aufgabenfelder
der Zentralisierung gegeben werden.
13
1. Einleitung
14
2. Systemlandschaft
Die ZF Friedrichshafen AG ist ein weltweit agierendes Unternehmen mit 75.000 Mitarbeitern in 26 Ländern mit 121 Produktionsgesellschaften. Im Jahr 2011 wurde der Konzern
neu strukturiert und besteht seither aus den vier Divisionen Antriebstechnik, Fahrwerkstechnik, Nutzfahrzeugtechnik und Industrietechnik. Die Geschäftsfelder der Divisionen
können Abbildung 2.1 entnommen werden. Des Weiteren besteht das Gemeinschaftsprojekt ZF Lenksysteme GmbH, an dem die ZF Friedrichshafen AG und die Robert Bosch
GmbH jeweils zur Hälfte beteiligt sind. [ZF12b]
Aktionäre: 93,8 % Zeppelin-Stiftung und 6,2 % Dr. Jürgen und Irmgard Ulderup Stiftung
Antriebstechnik
Fahrwerktechnik
Nutzfahrzeugtechnik
Industrietechnik
Lenksysteme*
Automatgetriebe
Achssysteme
Lkw- und VanAntriebstechnik
Arbeitsmaschinensysteme
Pkw-Lenksysteme
Handschaltgetriebe/
Doppelkupplungsgetriebe
Fahrwerkkomponenten
Prüfsysteme
Nkw-Lenksysteme
Sonder-Antriebstechnik
Pkw-Lenksäulen
Marine-Antriebstechnik
Global Aftermarket
Bus-Antriebstechnik
Gummi & Kunststoff
Nkw-Achssysteme
Achsgetriebe
Dämpfungsmodule
Nkw-Fahrwerkmodule
Antriebsmodule
Gusstechnologie
Luftfahrt-Antriebstechnik
Nkw-Dämpfertechnologie
Nkw-Antriebsstrangmodule
Windkraft-Antriebstechnik
* ZF Lenksysteme GmbH ist ein
Gemeinschaftsunternehmen, an
dem die ZF Friedrichshafen AG
und die Robert Bosch GmbH
jeweils zu 50 % beteiligt sind.
Stand: Mai 2013
Abbildung 2.1.: Strukturierung des ZF–Konzerns [ZF12b]
Als Global Player hat der ZF–Konzern auch hohe Anforderungen an seine IT–Systeme.
Die Globalisierung fordert die Verfügbarkeit von Daten unabhängig von Standorten und
setzt voraus, dass während aller Phasen des Produktlebenszyklus ein gemeinsamer Zugriff
auf alle für das Produkt relevanten Informationen gegeben ist. ([ES09], S. 18)
Nachfolgend werden für die weitere Arbeit wichtige Begriffe definiert. Im Anschluss werden die verschiedenen Systeme am Standort Passau erklärt, die in dieser Strukturierung
in vielen anderen ZF–Standorten eingesetzt werden. Des Weiteren werden auch die Kommunikationskanäle zwischen den einzelnen Systemen beschrieben.
15
9
2. Systemlandschaft
2.1. PLM–Strategie
Für Unternehmen, die in einem globalen Umfeld agieren, ist es Voraussetzung dynamisch
auf sich wandelnde Märkte zu reagieren, um ihre Wettbewerbsfähigkeit zu wahren. Dieser
Markt fordert eine ständige Verbesserung der Durchlaufzeiten von Produkten, reduzierte
Kosten über den gesamten Produktlebenszyklus, zunehmende Absicherung bezüglich der
Produkthaftung und den daraus abgeleiteten Regeln für das Qualitätsmanagement.
Abbildung 2.2.: Phasen im Produktlebenszyklus [Bau06]
Daraus ergeben sich neue Anforderungen an den Produktentstehungsprozess, der aus der
Produktentwicklung und der Entwicklung von Fertigungstechnologien besteht. Der Produktentstehungsprozess umfasst die komplette Planung und Entwicklung von Produkten
und ihren zugehörigen Betriebsmitteln, Ressourcen, Fertigungs– und Montageprozessen,
deren Herstellung sowie Nutzung, Betrieb und Recycling. In Abbildung 2.2 sind die einzelnen Phasen des Lebenszyklus mit ihren zugeordneten Tätigkeiten abgebildet. [ES09]
Dies bedeutet für die IT, alle betroffenen Bereiche wie Mensch, Daten und Prozesse zu
verknüpfen, um die Produkt– und Prozesskomplexität beherrschen zu können. Die hierfür
eingesetzte Strategie heißt Product–Lifecycle–Management (PLM), das durch die Konsolidierung verschiedener Systeme eine Informationsstrategie definiert, die für jedes Unternehmen speziell und damit einzigartig ist. Durch eine vollständig vernetzte Unternehmenswelt
ermöglicht das PLM eine unternehmensübergreifende Arbeitsteilung, um Produkte zu entwickeln, zu produzieren, zu unterstützen oder schließlich wieder vom Markt zu nehmen.
Der Stellenwert der PLM–Strategie wird deutlich, wenn man bedenkt, dass die Neuentwicklung eines Kraftfahrzeugs in Europa und den USA vor zwanzig Jahren rund sechs bis
sieben Jahre dauerte, während es heute nur noch zwei bis drei Jahre sind. [Sen09]
Die Hauptaufgabe besteht in der Verwaltung aller Informationen, die am Lebenszyklus
eines Produktes beteiligt sind, um eine bessere Kontrolle über die Teilprozesse zu erhal-
16
2.1. PLM–Strategie
ten und dadurch eine transparente Aufstellung über Aufwände und Erträge ermitteln zu
können. Die Vorteile, die sich daraus ergeben, sind im Einzelnen:
•
•
•
•
Time-to-Market reduzieren
Zeit- und Kostenreduktion
Qualitätsverbesserung der Produkte
Erhöhung der Innovation
Um diese Ziele zu erreichen werden IT–Lösungen verwendet, die die virtuelle Produktentstehung unterstützen. Eine wesentliche Rolle spielen dabei die sogenannten Autorensysteme, wie Computer–Aided–Design (CAD) mit dem die funktionalen und geometrischen
Grundlagen des Produkts erarbeitet werden, Computer–Aided–Manufacturing (CAM),
das zur Steuerung von Fertigungs– und Montagemaschinen dient und Computer–Aided–
Engineering (CAE) mit dessen Hilfe die Technologien zur Simulation und Berechnung zur
Verfügung gestellt werden. [ES09]
Ein ganz wesentlicher Bestandteil eines vollständigen PLM–Konzepts ist ein Enterprise–
Ressource–Planning (ERP) System, das die verfügbaren Ressourcen für den betrieblichen
Ablauf optimiert. So lassen sich Ressourcen wie Kapital, Betriebsmittel und Personal
steuern, kontrollieren und koordinieren.
Den Kern einer jeden PLM–Strategie bildet jedoch das Product–Data–Management
(PDM) System, das die zentrale Lösung für den Produktentstehungsprozess darstellt.
Die ersten PDM–Systeme dienten zur Dokumentverwaltung und sind aus der Problematik heraus gewachsen die zunehmende Anzahl an CAD–Dokumenten zusammen mit den
gescannten Papierdokumenten zu verwalten. Schnell wurden die PDM–Systeme auch an
die Produktstruktur angebunden, was die Einführung von unternehmensweit harmonisierten Stammdaten und Stücklistenstrukturen zur Folge hatte. Deshalb bildeten PDM–
Systeme den Grundstein des heutigen PLM–Konzepts und sind daher als der administrative Backbone1 zu sehen. PLM ist aber nicht nur ein „Baukasten“ aus verschiedenen
Softwarelösungen, die gebündelt eingesetzt werden, sondern vielmehr eine integrierte Philosophie und Vorgehensweise mit einer ganzheitlichen Behandlung und Beeinflussung des
Produktlebens. Das heißt, PLM kann nicht als einmalige Aufgabe gesehen werden, da es
aufgrund der Integrationsfähigkeit ein Dauerzustand ist.
Der ständige Zuwachs an 2D– und 3D–Daten, sowie abgeänderte Prozesse und neue Anforderungen an das Management von Fertigungsdaten innerhalb des ZF–Konzerns, machten
es erforderlich zwischen Produktdaten und Fertigungsdaten zu unterscheiden.
Während die Produktdatenorganisation (PDO) alle Dokumente und Objekte für die Entwicklung eines Produktes verwaltet, werden bei der Fertigungsdatenorganisation (FDO)
alle Daten verwaltet, die für die Herstellung des Produktes relevant sind. Dazu zählen
unter anderem die Fertigungshilfsmittel (FHM), die als Unterkategorie der Betriebsmittel
einzuordnen sind, allerdings nicht an einen bestimmten Ort gebunden sind. Im Gegensatz
1
Ein Backbone als Teil eines Computernetzwerkes verbindet mehrere Netzwerke miteinander und stellt
so die Möglichkeit zum Informationsaustausch zur Verfügung.
17
2. Systemlandschaft
zu Maschinen sind Werkzeuge (WKZ), Spannmittel und Vorrichtungen für Maschinen,
aber auch die NC-Programme zur Steuerung der Maschinen als typische FHM zu benennen.
Wie in Abbildung 2.3 zu sehen ist, beginnt die PDO weit früher als die FDO, da die FDO
um die Produkte herum arbeitet und damit für die Produktion relevant ist. Dies bedeutet
konkret, falls sich am Produkt etwas ändert, so ändern sich auch die entsprechenden Betriebsmittel der Fertigung. Obwohl die Administrationsprozesse unterschiedliche Bereiche
abdecken, werden sie beide durch das standardisierte PDM–System verwaltet. Sie basieren
also auf einer einheitlichen Datenbank, aber stellen unterschiedliche Sichten auf das gleiche
System zur Verfügung, sodass durch diese Sichten die spezifischen Management–Prozesse
repräsentiert werden.
Abbildung 2.3.: Eingliederung des PDO und FDO Prozesses [ZF12a]
Die Stammdaten und Dokumenttypen werden gleich verwaltet, dennoch gibt es einige
Unterschiede in den Prozessen, die in Tabelle 2.1 dargestellt sind.
PDO–Prozess
Komplexes Statusnetz (ca. 70 Level)
Viele Prozessschritte (>300 Übergänge)
Viele Verantwortlichkeiten
Änderungsmanagement
Komplexe Stücklisten
Lange Entwicklungszyklen
FDO–Prozess
Einfaches Statusnetz (7 Levels)
Wenige Prozessschritte (30 Übergänge)
Wenige Verantwortlichkeiten
Kein Änderungsmanagement
Einfache Stücklisten (FHM)
Kurze Entwicklungszyklen
Tabelle 2.1.: Gegenüberstellung von PDO und FDO [ZF12a]
Die Vorteile, die sich aus der Trennung dieser Prozesse ergeben, sind:
• Erhöhte Prozesssicherheit durch weniger Management–Aufwand
• Fehlerminimierung und schnellere Verfügbarkeit
• Kosten– und Bestandsreduktion
Systeme, die sich mit der Verwaltung und Organisation der Fertigungsdaten befassen,
heißen Fabric–Data–Management (FDM) Systeme.
18
2.2. Applikationen im FDO–Bereich
2.2. Applikationen im FDO–Bereich
Im Folgenden werden die bisher vorgestellten Systeme konkret benannt und ihre Aufgaben
und Einsatzgebiete erläutert. Außerdem werden Interaktionen zwischen den Systemen
gesondert dargestellt.
2.2.1. Übersicht
In Abbildung 2.4 ist eine eingeschränkte Sicht auf die am Standort Passau eingesetzten
IT–Systeme gegeben. Diese Übersicht erhebt keinen Anspruch auf Vollständigkeit und soll
lediglich die Beziehungen zwischen den Systemen genauer darstellen. Andere Sichtweisen
auf die verwendeten Systeme sind möglich, jedoch für diese Arbeit nicht relevant.
Abbildung 2.4.: IT–Systeme im FDO–Bereiche am Standort Passau [Pet12]
Das Herzstück stellt das globale PDM–System Axalant dar, das ortsunabhängig und unternehmensübergreifend zur Verfügung steht. Hier sind alle Daten abgelegt, die entweder
der PDO oder FDO zugeordnet sind, sodass alle Softwaresysteme entweder direkt oder
indirekt – durch andere Systeme – mit Axalant in Verbindung stehen. Im Mittelpunkt
dieser Arbeit steht das FDM–System FATool, das ebenfalls eng mit Axalant verknüpft
19
2. Systemlandschaft
ist. FATool wird ebenfalls direkt aus der Produktion heraus genutzt und besitzt außerdem eine direkte Schnittstelle zum ERP–System SAP, dem CAD–System ProE/CREO
und der CAM–Anwendung EdgeCAM. Mit NC-Simul ist es möglich das Bewegungsprofil
der Maschine anhand der NC-Programme, die von EdgeCAM geliefert werden, zu simulieren. PartSolutions bietet normgerechte Beschreibungen von Einzelteilen in Form von
3D-Modellen, die vor allem von den CAD–Systemen verwendet werden. AutoCAD ist
ebenfalls ein CAD–System, das für die Zeichnung von 2D-Modellen verwendet wird.
2.2.2. Axalant
Das PDM–System Axalant ist das strategische und technische Informationssystem und
dient der Speicherung, Verwaltung und Bereitstellung aller produkt- und fertigungsbezogenen Daten und Dokumente. Es ist ein globales, unternehmensweites System, das durch
eine Verteilung der Informationen eine enge Zusammenarbeit in der Entwicklung und
Produktion über den gesamten Globus ermöglicht. [ZF10] Die Vorteile, die sich durch den
Einsatz des PDM–Systems ergeben, sind im Einzelnen:
• Gezielter und geschützter Zugriff auf aktuelle, technische Unterlagen und Dokumente rund um die Uhr, unabhängig vom Standort im ZF–Netzwerk
• Verwaltung von Produktdaten und technischen Dokumenten, als auch Fertigungshilfsmitteln entlang des Produktentstehungsprozesses
• Weltweite Kollaboration in der Erstellung und Änderung von gemeinsamen Daten
Im Folgenden wird auf die wichtigsten Eigenschaften des globalen PDM–Systems eingegangen.
Klassensystem Ein Klassensystem dient der Ordnung und Strukturierung von gleichartigen Elementen für die eine Beschreibung gegeben ist. Es besteht aus mehreren einzelnen
Klassen, die durch bestimmte Merkmale beschrieben werden, wobei die Zuordnung der
Merkmale je nach Klasse variiert. Eine Klasse fast somit Elemente zusammen, die gleiche oder ähnliche Merkmale besitzen. Das Zuordnen eines Materialstamms zu einer Klasse
nennt man Klassifizierung, wobei die Übersicht über alle Elemente einer Klasse, mit deren
Merkmalen und Merkmalswerten, Sachmerkmalleiste (SML) genannt wird. Das Zuweisen
von Merkmalswerten zu den einzelnen Sachmerkmalen, wird im Allgemeinen Bewertung
genannt.
Die spezifische Beschreibung von Objekten durch Merkmalswerte erlaubt eine gezielte
Suche nach Elementen mit bestimmten Merkmalen. Neben einer Kosten- und Zeitersparnis
und der Minimierung für das Anlegen von redundanten Daten, durch eine gewissenhafte
Beschreibung von Objekten, ergeben sich durch das Klassensystem folgende Vorteile:
•
•
•
•
20
Elemente können nach bestimmten Ordnungskriterien zusammengefasst werden
Materialien können genauer beschrieben werden
Der Ergebnisraum der Materialsuche ist eingeschränkt
Die Suche nach Materialien verkürzt sich
2.2. Applikationen im FDO–Bereich
Die Klassen selbst sind hierarchisch angeordnet und stellen mit spezifischen Ober- und Unterklassen einen Klassenbaum dar. Die Oberklassen sind grundsätzlich abstrakte Klassen
und beinhalten Unterklassen, wobei die Blätter des Baumes die eigentlichen Materialien
sind.
Abbildung 2.5.: 2D–Sachmerkmale
nach DIN4000 [Pet12]
Für die Klassifizierung wird die DIN40002
verwendet, die als Basis für eine einheitliche
Beschreibung der Sachmerkmalleisten dient
und als Standard innerhalb des ZF-Konzerns
gilt. Der Aufbau der DIN4000 ist in eine vierstufige Hierarchie eingeteilt, wobei die erste
Ebene die Sachmerkmal-Normen enthält, die
zweite Ebene die Gegenstandsgruppen, die
dritte Ebene die Teilefamilien und als vierte
Ebene die Bildkennung (BLD), die ähnlichen
Materialien unterschiedliche Merkmalsattribute zuweist.
In Abbildung 2.5 ist ein Stufenbohrer mit
drei Stufen abgebildet. Dieser ist in der
DIN4000-81 „Bohr– und Senkwerkzeuge mit
nicht lösbaren Schneiden“ zu finden und besitzt die Bildkennung 2. Die BLD ordnet
diesem Stufenbohrer die Merkmale zu, die
aus der Abbildung ersichtlich werden, wie als
Beispiel „B4 Nutzlänge“, „B5 Gesamtlänge“,
„B6 Spannutenlänge“ etc.
Stammdaten Als Stammdaten werden jene Daten bezeichnet, die selbstständig, ohne Beziehung zu anderen Daten aussagefähig sind. Dabei wird in Axalant zwischen den
Typen Materialstamm und Dokumentenstamm unterschieden. Beiden gemeinsam sind
identifizierende Attribute, die zur eindeutigen Bestimmung eines Stammsatzes dienen,
wie die Dokument- oder Materialnummer und den Funktionsattributen, die zusätzliche
Informationen für anderweitige Prozesse bereit halten.
Der Materialstamm definiert Materialien, also physikalisch greifbare Objekte, über einen
Materialstammsatz, der die zur Verwaltung eines Materials notwendigen Informationen,
wie Materialnummer, Benennung, Werkstoff, Abmessung, Status bereithält. Der Dokumentenstammsatz hingegen beschreibt das Material und bezeichnet einen Datensatz mit
Metadaten, wie Dokumentnummer, Benennung, Gültigkeit und den zugeordneten Dateien. Durch die Metadaten werden alle Informationen bereit gehalten, die zur Identifikation,
zum Austausch, zur Verwaltung und Nutzung eines Dokuments benötigt werden. [ZF13]
2
Diese Norm legt Begriffe und Grundsätze zur Gestaltung von Merkmalen, Merkmal–Listen und Konformitätsklassen fest. Diese Merkmale bilden die Grundlage der Kommunikation, zum Beispiel zwischen
Anwendern und Lieferanten. Ein weiteres Ziel ist die Kategorisierung dieser Merkmale in Konformitätsklassen, unter anderem zur Vereinheitlichung des Datenaustauschs.
21
2. Systemlandschaft
Berechtigungen Die Berechtigungskontrolle in Axalant ist hierarchisch in vier Stufen
aufgebaut und dient primär zum Schutz der hinterlegten Informationen.
• 1. Stufe: Sichtbarkeit
Die Sichtbarkeit beschränkt den Zugriff auf Metadaten von Stammsätzen und wird
über Verteilerflags gesteuert. Nur an Standorten für die das Verteilerflag an einem
spezifischen Datensatz gesetzt ist, können diesen auch einsehen.
• 2. Stufe: Rollen
Durch Rollen werden unterschiedliche Berechtigungsstufen umgesetzt, die verschiedene Funktionen, wie Anlegen, Bearbeiten oder Betrachten, an einem Stammsatz
freigeben. Rollen sind als ein Container zu verstehen, der alle einem Benutzer zugewiesenen Berechtigungen umfasst. Bei jeder ausgeführten Aktion in Axalant wird
unabhängig vom Datensatz überprüft, ob der Anwender die entsprechenden Rollen
besitzt.
• 3. Stufe: Änderungshoheiten Die Änderungshoheit ist als vierstellige Zahlenkombination angegeben und ist Datensätzen als auch Anwendern zugeordnet. Durch
die Änderungshoheit wird das für eine Änderung zuständige ZF-Geschäftsfeld bestimmt, sodass Anwender nur Datensätze verändern können bei denen die Änderungshoheiten mit der des Anwenders übereinstimmen.
• 4. Stufe: Owner–Group–World–Prinzip
Jeder Datensatz in Axalant ist einem bestimmten Eigentümer und damit einer Gruppe zugeordnet. So kann für jeden Datensatz explizit angegeben werden welche Rechte
der Eigentümer, die zugehörige Gruppe und alle anderen besitzen. Die möglichen
Rechte sind eingeteilt in „kein Zugriff“, „lesen“, „schreiben“ und „löschen“.
Stücklisten Durch Stücklisten (engl. Bill of materials (BOM)) wird in einer strukturierten Anordnung von Objekten beschrieben, welche Materialien oder andere Positionen wie
Stücklistentexte in einem Produkt verwendet werden. Die Stücklisten sind entsprechend
im Materialstamm hinterlegt und werden in Axalant angelegt und geändert.
Status Der Statuswechsel am FDO–Materialstamm dient zur Darstellung des Reifegrades. Die Übergänge zwischen den Status sind in Abbildung 2.6 dargestellt, wobei die
Status „In Vorfreigabe (FK540)“ und „Freigegeben (FK550)“ wichtige Abläufe im Prozess
anstoßen.
Abbildung 2.6.: Statuswechsel im FDO–Bereich [ZF10]
22
2.2. Applikationen im FDO–Bereich
Der Statuswechsel auf „In Vorfreigabe“ signalisiert, dass das Material seitens der Konstruktion angefragt wurde, es allerdings noch keinen finalen Reifegrad besitzt. In diesem
Fall wird der Materialstamm nach SAP übertragen. Der Statuswechsel nach „Freigegeben“ bedeutet, dass ein Material seitens der Konstruktion freigegeben ist und in den
Fertigungsprozess integriert werden kann. Eine erneute Übertragung an das SAP –System
wird dadurch angestoßen. Neue Daten werden angelegt oder bereits vorhandene überschrieben. Besitzt ein Material eine Stückliste, kann es nur freigegeben werden, falls alle
Elemente der Stückliste ebenfalls freigegeben sind.
2.2.3. FATool
Das FDM–System FATool ist das Informationssystem zur systematischen Organisation
aller Betriebsmittel, insbesondere aller Werkzeuge. Der Organisation liegt ebenfalls das in
der DIN4000 und ISO133993 definierte Klassifizierungssystem in Sachmerkmalleisten zu
Grunde. Die logische Verwaltung der Betriebsmittel hat im Einzelnen folgende Vorteile:
• Reduziert die Typenvielfalt von WKZ und FHM
• Reduziert den Lager- und Umlaufbestand
• Reduziert den Werkzeugverbrauch
Während FATool am Anfang ausschließlich für die NC-Programmverwaltung ausgelegt
war, wurde im Lauf der Zeit das Bedürfnis nach mehr Funktionalität größer, sodass heute
verschiedene Module im Umlauf sind. Die Module, die in der Betriebsmittelverwaltung
zum Einsatz kommen, werden im Folgenden dargestellt:
• Klassifizierung
Bei der Klassifizierung ist zu beachten, dass neue Materialien immer zuerst im führenden System Axalant anzulegen sind, denn nur dort wird eine eindeutige Materialnummer erstellt. Die eigentliche Klassifizierung wird aber häufig in FATool durchgeführt, da es übersichtlicher gestaltet ist und nicht alleine die Sachmerkmalattribute
darstellt, sondern auch deren Beschreibung.
• Komplettwerkzeug (KWZ) Verwaltung
Dient der Verwaltung von Werkzeugen, die aus mehreren verschiedenen Bauteilen
zusammengesetzt sind und an die CAM–Systeme übergeben werden können.
• Bauteil (BTL) Verwaltung
Umfasst alle Teile, die in irgendeiner Form weiter verwendet werden sollen, wie
Bohrer, Fräser oder Wendeschneidplatten, wobei die Bauteile in der Klassifizierung
nach DIN4000 gruppiert sind.
• Allgemeine Sachmerkmalverwaltung
Zu jedem Werkzeug sind die zugeordneten Merkmale und deren Werte abrufbar und
3
Werkzeugdatendarstellung und –austausch. – Übersicht, fundamentale Prinzipien und allgemeines Informationsmodell.
23
2. Systemlandschaft
über eine Stückliste ist die Referenzierung in die Bauteilebene möglich. Der Zusammenbau der Stücklisten erfolgt normalerweise in CREO und wird in Axalant gespeichert. Die zugehörigen Werkzeuggrafiken können ebenfalls als 2D– oder 3D–Grafik
eingesehen werden. Insbesondere die Verwaltung und Erstellung von Komplettwerkzeugen ist möglich.
• Lagerverwaltung
Die Lagerverwaltung unterteilt sich in die Gruppen Lagerstammdaten, physikalische
Lagerdaten und Lagerfunktionen. Die Lagerstammdaten sind Voraussetzung um eine Lagerverwaltung aufzubauen, wie Artikeldaten, Lieferantendaten oder Lagerorte.
Die physikalischen Daten beziehen sich auf Objekte, die tatsächlich vorhanden sind,
also auf den Artikel mit Informationen zu Standort, Anzahl oder dem Prüfdatum.
Zu den Lagerfunktionen zählen unter anderem das Bestellwesen sowie die Inventur.
• Prüfmittelverwaltung
Hier werden alle Prüf– und Messmittel eingetragen, sodass diese in regelmäßigen
Abständen auf ihre Maßhaltigkeit überprüft werden können und dabei die entsprechenden Prüfungen, Durchführungstermine und Ergebnisse erfasst werden können.
Ein weiterer wesentlicher Bestandteil ist die NC–Programmverwaltung in der alle Daten,
die für ein NC–Programm erforderlich sind, verwaltet werden. In dieser Verwaltung ist
auch die Kopplung mit dem CAM–System untergebracht und die Zuordnung von KWZ zu
einem NC–Programm, die nicht nur für die CAM–Systeme wichtig sind, sondern auch für
die Übergabe von Werkzeuginformationen an die CNC–Maschine. Neben der Maschinenverwaltung spielt in dieser Kategorie auch die Werkzeug–Ist–Datenverwaltung eine große
Rolle. Hier werden die Maße aus der Werkzeugvoreinstellung verwaltet.
Obwohl FATool inzwischen an vielen Standorten verfügbar ist, sind die Ausprägungen
des Systems durch die Modulstruktur durchaus unterschiedlich. Im Folgenden wird auf
die wichtigsten Eigenschaften des FDM–Systems eingegangen:
Sachmerkmalleisten Der Aufbau von FATool ist durch die Sachmerkmalleisten bestimmt. Die SML sind unterteilt durch ihre Bildkennung, die darüber entscheidet welche
Sachmerkmale zugeordnet werden. So können verschiedene Ausprägungen einer Gruppe klassifiziert werden, sodass nur eine Auswahl an Merkmalen angezeigt wird, um die
Lesbarkeit zu erhalten.
Sachmerkmale sind also Definitionen bestimmter Daten wie Artikelnummer, Durchmesser oder Werkstoff und werden in Gruppen zusammengefasst, den Sachmerkmalleisten.
Jedes Sachmerkmal ist innerhalb des ganzen Systems eindeutig durch eine Sachmerkmal–
ID (SMID) definiert. Alle Datensätze, die in der gleichen Sachmerkmalleiste abgebildet
werden sollen, müssen daher mit den in der SML verfügbaren Merkmalen bestimmt werden
können. Zur besseren Übersicht sind zusammengehörige Sachmerkmalleisten in Modulen
gruppiert. Eine Übersicht über den Vorgang der Klassifizierung mit SML ist in Abbildung 2.7 dargestellt.
24
2.2. Applikationen im FDO–Bereich
Abbildung 2.7.: Sachmerkmalleisten–System in FATool [Fas10]
25
2. Systemlandschaft
Gruppen Die Authentifizierung zum Start der Applikation läuft über den Windows–
Benutzernamen. Die Benutzerberechtigungen in FATool sind in Gruppen unterteilt, wobei
beim Programmstart überprüft wird, ob der Benutzer in einer der entsprechenden Windows–Usergruppen eingetragen ist. Je nach Art der Anwendung gibt es im ZF–Konzern
verschiedene Nutzergruppen, die mit einer dreistelligen Standortkennung beginnen. Für
Passau ergeben sich hiermit vier Gruppen:
•
•
•
•
PAS-FASYS-CAM, für die Programmierung
PAS-FASYS-ADMIN, für Administratoren
PAS-FASYS-VIEW, für die Arbeitsplanerstellung
PAS-FASYS-DNC, für die Fertigung
Innerhalb von FATool gibt es weitere Gruppen, die die Sichtbarkeit der einzelnen Module
regeln. Diese Gruppen sind im Einzelnen:
•
•
•
•
•
•
•
•
BTL, Bauteilverwaltung
KAL, Prüfmittelverwaltung
KWZ, Komplettwerkzeugverwaltung
PVW, NC–Programmverwaltung
SYS, FATool Administration
LVS, Lagerverwaltung
PMV, Prüfmittelverwaltung
SML, Sachmerkmalleistenverwaltung
Die einzelnen Module sind nur sichtbar, wenn der Benutzer in den entsprechenden Gruppen eingetragen ist.
Berechtigungen FATool bietet auch die Möglichkeit die Funktionen auf einzelne Sachmerkmalleisten zu beschränken. Hierfür gibt es ein Berechtigungssystem, das auf jede
einzelne Leiste angewendet werden kann.
Kennung
0
1
2
3
4
Berechtigung
kein Zugriff
zeigen
editieren
anlegen
löschen
Tabelle 2.2.: Zugriffsrechte
in FATool
Die möglichen Berechtigungen sind in Tabelle 2.2 dargestellt, wobei diese Rechte addierend zu verstehen sind, sodass jede übergeordnete Berechtigung die darunterliegenden
beinhaltet. Für jede Leiste werden zwei Kennungen zugeordnet, wobei die erste Berechtigungskennung für den Datensatz ist und die
zweite für die dazugehörigen Dateien.
Ein Auszug möglicher Konstellationen der Berechtigungskennungen ist in Tabelle 2.3 abgebildet und die Maske zur Vergabe von Berechtigungen auf Leistenebene mit Zuordnung
von Standorten in FATool ist im Anhang A.2 unter Abbildung A.8 zu finden.
26
2.2. Applikationen im FDO–Bereich
Datensatz
0
2
3
4
Dateien
0
0
3
4
Berechtigung
Kein Zugriff auf Daten oder Dateien
Editieren der Daten, kein Zugriff auf Dateien
Anlegen von Datensätzen und Dateien
Volle Zugriffsrechte
Tabelle 2.3.: Auszug möglicher Berechtigungen in FATool
Lizenzen FATool besitzt einen eigenen Lizenzserver, der dezentral für jeden Standort
zur Verfügung steht und die Lizenzen an die lokalen Clients verteilt. Sollte ein Client
die Applikation öffnen, so wird automatisch die richtige Lizenz vom Lizenzserver angefordert. Die richtige Anzahl an gekauften Lizenzen muss gut kalkuliert sein, denn ist das
System unterlizenziert, so ist ein effektives Arbeiten nicht möglich, da auf freie Lizenzen
gewartet werden muss. Eine Überlizenzierung ist aus betriebswirtschaftlicher Sicht nicht
erstrebenswert.
Dabei ist jedoch zwischen verschiedenen Arten von Lizenzen zu unterscheiden, je nachdem
wie FATool verwendet wird. Eine Aufstellung der möglichen Lizenzen kann in Tabelle 2.4
eingesehen werden.
Lizenz
FATool
View
CAM
INV
ASM
PCD
COMx
WVE
PCDEdt
MDE
MDEMap
DCOM
EXT
Beschreibung
Basis-Lizenz
Viewerlizenz (Read-only)
Lizenz für die NC-Verwaltung mit Bereitstellungsfunktion
Lizenz für die Lagerverwaltung
Lizenz für die Werkzeugverwaltung
Lizenz für die FAPcd IPC–DNC–Client Software
Maschinenlizenz aus dem FAPcd
Lizenz für die Werkzeugvoreinstellung
Lizenz für FAPcd mit der Option „Editieren der SML–Datenbank“
Lizenz für Maschinen–Daten–Erfassung
Lizenz für Maschinen im MDE
Anzahl der max. Aufrufe vom DCOM–Server
Lizenz für externe Schnittstellen (CREO, SolidWorks, etc.)
Tabelle 2.4.: Lizenztypen für FATool
Die PCD–Lizenz ist mit FAPcd4 für die Fertigung gedacht, wobei über sogenannte IPC–
DNC–Clients5 das NC–Programm direkt auf die Maschine geholt wird. Die COM6 –Lizenz
4
FAPcd ist ein PC-bedientes DNC–System als Standardanwendung.
Insel–PCs werden verwendet um mehrere Maschinen anzusteuern und mit NC-Programmen zu versorgen.
6
COM steht für eine serielle Schnittstelle bei der die Bits nacheinander über die Leitung übertragen
werden.
5
27
2. Systemlandschaft
wird ebenfalls in der Fertigung für Server benötigt, die Maschinen mit serieller Schnittstelle ansteuern. Mit PCDEdt kann an der Fertigungsmaschine das NC–Programm noch
geändert werden. Die Module MDE7 , MDEMap8 und WVE werden in Passau nicht verwendet. Die DCOM9 –Lizenz wird für den DCOM–Server benötigt, der versucht die Netzwerklast zu verringern.
2.2.4. SAP
Als ERP–System wird im ZF–Konzern SAP R/3 eingesetzt, das zur Steuerung und Verwaltung der Personalwirtschaft, der Logistik, der Arbeitsplanung und des Rechnungswesens dient. Da diese Faktoren keine allgemeine Systemlösungen zulassen, sondern höchstens branchenspezifisch ausgerichtet sind, muss das verwendete SAP –System in einem
Customizing 10 –Prozess an die Erfordernisse des Unternehmens angepasst werden. Das führende System für die Materialstamm– und Stücklistenverwaltung bleibt jedoch Axalant.
Abbildung 2.8.: Architektur der SAP–Systeme im ZF–Konzern
Aus diesem Grund gibt es innerhalb der ZF eine Reihe vieler verschiedener lokaler ERP–
Systeme, die an die unterschiedlichen Standorte angepasst sind und daher unabhängig
voneinander funktionieren. Wie in Abbildung 2.8 dargestellt, ist allen lokalen Systemen
ein SAP–Master übergeordnet, der die Daten aus Axalant an die lokalen ERP–Systeme
verteilt, vorausgesetzt der SAP–Standort ist in Axalant für den jeweiligen Standort eingetragen. Durch diese enge Verknüpfung des PDM– und ERP–Systems ist es möglich fertigungsrelevante Informationen an die werksspezifischen Installationen zu verteilen. Die
übertragenen Daten werden unter anderem genutzt, um Arbeitspläne zu erstellen, die
Auslastung der Fertigungsmaschinen zu kontrollieren oder Bestellungen durchzuführen.
7
Lizenz zur Maschinendaten–Erfassung in der Applikation.
Entsprechende MDE Lizenz für die Maschine.
9
Distributed Component Object Model ist ein RPC–System von Microsoft, das die Erstellung von
Softwarekomponenten ermöglicht, die unabhängig von der Programmiersprache eingesetzt werden
können und diese Komponenten über ein Rechnernetz kommunizieren zu lassen.
10
Unter Customizing versteht man die Anpassung eines Serienprodukts an die spezifischen betriebswirtschaftlichen Anforderungen eines Unternehmens.
8
28
2.3. Schnittstellen
2.2.5. EdgeCAM
EdgeCAM ist das strategische CAM–System im ZF–Konzern, welches diverse CAD–
native–Daten einlesen kann. Es dient der Erstellung von NC-Programmen für Fertigungsmaschinen im Bereich Drehen, Drehzentren, Bearbeitungszentren sowie Erodieren. Die
NC–Programme müssen für die Steuerung der DNC–Maschinen übersetzt werden, wozu ein Postprozessor erforderlich ist, der in einer Compilersprache oder in einem PP–
Assistenten innerhalb von EdgeCAM erstellt werden kann. Die in EdgeCAM über die
Jahre stark verbesserte Simulation mit Darstellung von Werkzeugen und Fertigungsmaschinen, macht den Bedarf an zusätzlicher Software in der Fertigungssimulation geringer.
Für Bauteile bei denen auf höchste Präzision gesetzt wird, kommt die Software NCSimul
zusätzlich zur Simulation in EdgeCAM zum Einsatz. Dabei erlaubt NCSimul eine Simulation aller CNC–Steuerungen und Maschinen unter Berücksichtigung der physikalischen
Maschinenachsen, sodass Programme nicht nur verifiziert, sondern auch optimiert werden
können.
2.2.6. ProE/CREO
Das strategische CAD–System im ZF–Konzern ist ProE, welches innerhalb der ZF im
Jahre 2013 durch die neuere Version CREO ersetzt wurde. Dieses System wird primär für
die Modellierung von 3D–Daten verwendet und wird gleichermaßen im PDO– als auch im
FDO–Bereich eingesetzt.
Für immer wiederkehrende Materialien verwendet CREO den normgerechten 3D–CAD–
Katalog der Software PartSolutions. Hier findet man Standard–Bauteile, wie Schrauben,
Unterlegscheiben oder Federn, die somit leicht in CREO als 3D–Modell importiert werden können. Für die Modellierung von 2D–Layouts, wie es häufig bei der Erstellung von
Grundrissen vorkommt, wird im ZF–Konzern AutoCAD verwendet.
2.3. Schnittstellen
FATool ↔ Axalant Zwischen Axlant und FATool besteht eine Schnittstelle, die je nach
Art der übertragenen Daten entweder unidirektional oder bidirektional sein kann. Die
unidirektionale Verbindung findet Verwendung bei der Übertragung von Geometriedaten,
von 3D–, 2D– und nicht-digitalen Zeichnungen, sowie von Stücklisten. Da Axalant das
zentrale Archiv aller Daten ist, ist es auch die Datenquelle für FATool. Nach FATool werden allerdings nur die relevanten FDO–Daten übertragen, sodass diese in beiden Systemen
zur Verfügung stehen.
Die Übertragung der SML–Daten stellt eine bidirektionale Verbindung dar, da sie die
Basis der einheitlichen und systemübergreifenden Klassifizierung ist. Materialien müssen
zwar wegen der Materialnummer immer in Axalant angelegt werden, da diese konzernweit
eindeutig sein muss, die Klassifizierung kann jedoch auch in FATool vorgenommen werden.
Nach der Aktualisierung der SML–Daten müssen diese anschließend wieder nach Axalant
eingecheckt werden. Es werden allerdings nur Daten an FATool übertragen, die in Axalant
freigegeben sind.
29
2. Systemlandschaft
FATool → SAP Zwischen FATool und SAP besteht eine unidirektionale Schnittstelle. Dabei wird ein sogenannter Dokument–Info–Satz übertragen, der die Basisdaten zum
eigentlich NC–Programm bereithält. Dieser beinhaltet den Arbeitsgang, die Maschinennummer, die NC–Programmnummer sowie den View des NC–Programms.
FATool ↔ EdgeCAM Die Verbindung zwischen FATool und EdgeCAM ist bidirektional, denn FATool stellt die benötigten Daten zur Erzeugung der NC–Programme bereit,
während die NC–Programme durch EdgeCAM erstellt bzw. bearbeitet und zurück übertragen werden.
Dazu wird auf dem jeweiligen Client eine temporäre Datei gespeichert, die von EdgeCAM
aufgerufen wird. Die für die Erstellung der NC–Programme benötigten Werkzeuge sind
ebenfalls in FATool gespeichert und werden in den lokalen Toolstore von EdgeCAM geladen. Nachdem das Programm erstellt ist, wird der Toolstore wieder bereinigt und das
fertige Programm zurück nach FATool übertragen.
FATool ↔ ProE/CREO Die Schnittstelle zwischen FATool und CREO ist bidirektional, da FATool die nötigen Daten für das CAD–System zur Verfügung stellt. Dabei handelt
es sich allerdings nur um die Metadaten, also die zugehörigen Merkmalswerte, während die
CAD–Dateien selbst aus Axalant angefordert werden. Bei Änderungen an den Zeichnungen wird die entsprechende CAD–Datei wieder in Axalant abgespeichert, die geänderten
Merkmalswerte zieht jedoch FATool beim Schließen der Schnittstelle. Durch eine interaktive Rückgabe zwischen FATool und Axalant werden die geänderten Merkmalswerte auch
nach Axalant übertragen. Dabei ist zu beachten, dass die interaktive Rückgabe durch
das Starten der Axalant–Applikation direkt am Client erfolgt. In FATool können außerdem Flächenmodelle aus den vorhandenen Merkmalsdaten erstellt werden. Dies geschieht
durch einen im Hintergrund laufenden Generator, der von CREO zur Verfügung gestellt
wird. Für Volumenmodelle sind in FATool parametrisierte Mastermodelle hinterlegt, die
direkt an CREO übergeben werden.
FATool ↔ DNC Distributed–Numerical–Control (DNC) bezeichnet computergestützte Werkzeugmaschinen, die in der Fertigung durch ein Computernetzwerk angesprochen
werden können und die entsprechenden Bearbeitungsprogramme direkt in die Steuerung
der Maschinen geladen werden können.
Über FATool werden diese Fertigungsmaschinen mit den benötigten NC–Programmen
versorgt, das ebenfalls die Auswahl der benötigten Werkzeuge enthält. Die Kommunikation zwischen FATool und der Maschine wird über einen als Proxy fungierenden DNC–
Server in einer Demilitarized–Zone (DMZ) ermöglicht. Somit werden die Programme vom
FATool –Server, der sich im Office–Netzwerk befindet, direkt über das sogenannte ShopFloor-Netzwerk in der Fertigung an die Maschine übergeben.
Da es sich hier aber um eine bidirektionale Schnittstelle handelt, können Daten von der
Maschine auch zurück an den FATool–Server übermittelt werden. Dies ist allerdings nur
dann der Fall, wenn das Programm selbst Unstimmigkeiten beinhaltet und direkt an der
Maschine geändert werden muss.
30
3. Grundlagen
Das Thema dieser Arbeit ist die Architektur von FATool hinsichtlich einer Zentralisierung
zu dokumentieren und analysieren. Dabei ist zunächst der Architekturbegriff zu klären,
der vielfältige Ausprägungen besitzen kann und in verschiedenen Ebenen auftritt, die sich
nicht leicht voneinander abgrenzen lassen.
Abbildung 3.1.: Architekturpyramide [Sta08]
Eine gelungene Trennung dieser Ebenen ist
durch die Architekturpyramide in Abbildung 3.1 gegeben. Sie werden nach oben hin
abstrakter und beeinflussen sich gegenseitig,
sodass ihre Grenzen durch unter– oder übergeordnete Ebenen bestimmt sind. An der
Spitze steht die Strategie in der die Ziele des
Unternehmens formuliert werden, wobei hier
ein klar definierter Zusammenhang zwischen
Geschäftsprozessen und der IT steht. Darunter steht die Business–Architektur, die geschäftliche Prozesse und betriebswirtschaftliche Funktionen definiert. Die Informationsarchitektur definiert die Struktur und die Zusammenarbeit aller IT–Systeme eines Unternehmens, indem der Informationsfluss und
die Schnittstellen der gesamten Systemlandschaft berücksichtigt werden. [Sta08]
Während hier die Gesamtheit der Anwendungslandschaft betrachtet wird und die einzelnen Systeme als Bausteine gelten, beschäftigt sich die Softwarearchitektur mit dem
detaillierten Aufbau eines einzelnen Bausteins. Durch ihre vielfältigen Aufgaben lässt sie
sich nur schwer definieren und besitzt auch in der Fachliteratur eine Menge an unterschiedlichen Definitionen. In [BCK12] ist eine weitestgehend akzeptierte Version für die
Definition von Softwarearchitektur zu finden:
„The software architecture of a program or computing system is the structure or structures
of the system, which comprise software components, the external visible properties of those
components and the relationship among them.“
Es handelt sich also genauer um die Strukturierung des Systems, die Zerlegung in seine
Teile, die Verantwortlichkeiten und das Zusammenspiel dieser Teile sowie deren Schnittstellen. Somit wird eine Vielzahl verschiedener Architekturentscheidungen in nur einem
31
3. Grundlagen
Begriff zusammengefasst, wobei sehr unterschiedliche Punkte betroffen sein können. „Es
kann um die Zerlegung des Gesamtsystems in Teile gehen (Strukturierung), um die Art,
wie Fremdsysteme angebunden werden, um die Verwendung bestehender Bibliotheken,
Komponenten oder Frameworks (make or buy?) und vieles mehr.“ [Zör12]
Am Boden der Pyramide ist die IT-Infrastruktur angesiedelt, die sich generell mit Themen
wie Hardware, Netztopologie und den eingesetzten Betriebssystemen und Datenbanksystemen beschäftigt. Die Ebenen Informationsarchitektur und Softwarearchitektur werden
durch den Überbegriff Unternehmensarchitektur bzw. IT–Architektur zusammengefasst.
Sie beschreibt die Elemente der IT und ihre Zusammenhänge untereinander sowie zu ihrer Umwelt und bietet daher eine abstrahierte, unternehmensweite Sicht auf alle Systeme
in einem Unternehmen, um Lücken und Redundanzen in der Struktur und den Komponenten der IT schneller zu erkennen. [JS08] Sie ermöglicht außerdem eine reibungslose
Unterstützung von Geschäftsprozessen durch Softwaresysteme und wird daher auch als
Business–IT–Alignment bezeichnet. [Sta08]
Vor diesem Hintergrund trifft für diese Arbeit der Begriff Softwarearchitektur am ehesten zu, da es sich um die
Zerlegung eines einzelnen Systems handelt. Wenn auch die Sichtweise auf die
Komponenten durch die Blackbox–Sicht
eingeschränkt ist, so können doch die externen Merkmale sowie die Schnittstellen zu anderen Systemen charakterisiert
werden. Wie in Abbildung 3.2 dargestellt ist, kann daher der innere Aufbau
des Systems nicht beschrieben werden,
sodass es sich hier bei der Architekturbeschreibung weniger um einen Bauplan
als mehr um einen Ablaufplan handelt.
Abbildung 3.2.: Blackbox
[SH11]
und
Whitebox
Die Aufgaben, die es innerhalb der Softwarearchitektur zu bewältigen gilt, sind ebenso
schwer zu benennen wie ihre Definition. Die Hauptbereiche werden in [SH11] allerdings
zu den folgenden zusammengefasst werden:
• Anforderungen und Randbedingungen klären
• Strukturen entwerfen
• Technische Konzepte entwerfen
• Architektur kommunizieren
• Umsetzung begleiten
• Architektur bewerten
32
Da im Rahmen dieser Arbeit die Strukturen durch das bestehende FATool bereits vorgegeben sind, ist der erste Schritt die Architekturdokumentation in der der Ist–Zustand
charakterisiert und dokumentiert wird. Sind die Grundlagen geschaffen, können die Anforderungen an das neue System gestellt und in der Anforderungsanalyse richtig formuliert
werden. Kriterien zur Bewertung von Architekturen werden ebenfalls erarbeitet. Das kommunizieren der Architektur ist ein begleitender und parallel stattfindender Prozess, der
genauso wie die Umsetzung in dieser Arbeit nicht betrachtet wird.
In Abbildung 3.3 ist die sog. „Architekturbrezel“ dargestellt, die aufzeigt, dass sich diese
Arbeit nur auf den linken Teil der „Brezel“ beschränkt. Nachdem die Ziele in einem ersten Schritt in Form von funktionalen und nicht–funktionalen Anforderungen erhoben und
detailliert beschrieben werden, kann die Architektur entwickelt werden, die durch Modelle und Konzepte charakterisiert ist. Abschließend werden diese Konzepte bewertet. Die
rechte Seite der „Brezel“ ist explizit nicht Teil dieser Arbeit und beschäftigt sich mit der
Implementierung und Evaluation sowie der Erarbeitung von Metriken zum Überwachen
der Umsetzung.
Abbildung 3.3.: „Architekturbrezel“ [Zör12]
Die Gliederung dieses Kapitels unterliegt somit dem logischen Aufbau dieser Arbeit. Zunächst muss das bestehende System analysiert werden, sodass die benötigten Anforderungen an das Soll–Konzept erarbeitet werden können. Die gefundenen Schwachstellen
müssen anhand von Anforderungen im Soll–Konzept gelöst werden. Eine abschließende
Bewertung stellt das Soll–Konzept den Schwachstellen des Ist–Zustands gegenüber und
zieht Bilanz ob diese erfüllt werden oder neue Schwachstellen entstehen lassen.
33
3. Grundlagen
3.1. Systemanalyse
Der Erfolg einer Systemanalyse hängt explizit von der Qualität der Systemdokumentation
ab. Da beide Begrifflichkeiten in der Literatur vorzufinden sind, aber nicht klar voneinander abgrenzbar sind, da sie sich denselben Techniken bedienen, werden beide in diesem
Kapitel zusammengefasst behandelt. Die Systemanalyse kann dabei auf zweierlei Arten
verstanden werden. Wenn ein bestehendes System so abgebildet wird wie es in der Realität vorzufinden ist, dann spricht man von der Ist–Analyse. Wird spezifiziert wie ein
zukünftiges System auszusehen hat, dann spricht man von der Soll–Analyse. [Rup13]
Um die gewonnen Ergebnisse explizit festzuhalten, werden diese in einer Dokumentation
zusammengefasst. Der Begriff Dokumentation wird im Duden definiert mit dem „Zusammenstellen und Nutzbarmach[en] von Dokumenten, Belegen und Materialien jeder Art“.
Somit hilft uns die Dokumentation Lösungen zu finden und diese nachvollziehbar und
bewertbar zu machen. Ein weiterer Grund, der eine Dokumentation von Architekturen
unabdingbar macht, sind Softwaresysteme, die viele Jahre im Einsatz sind und kontinuierlich weiterentwickelt werden, sodass durch unzureichende Dokumentation eine mangelnde
Wartbarkeit entsteht und jede Änderung zu einem Risikospiel wird. (vgl. [Ahl12], S.12)
Deshalb ist es ratsam, das Wissen, das in verschiedenen Köpfen steckt auf Papier zu
bringen, um die Nachvollziehbarkeit der Systeme auch weiterhin aufrecht zu erhalten.
Es ist auffällig, dass sich die in der Softwarearchitektur verwendeten Begriffe nicht immer
eindeutig definieren lassen und ihnen nur schwer eindeutige Tätigkeiten zuzuordnen sind.
Dies liegt einerseits an der Vielfältigkeit verschiedener Softwareprojekte, aber andererseits
auch an einem fehlenden standardisierten Vorgehen für die Analyse und Dokumentation
von Softwarearchitekturen. In anderen Disziplinen wie der Gebäudearchitektur gibt es
längst standardisierte Verfahren zur Planerstellung, sodass jeder Konstrukteur die Konstruktionszeichnungen seiner Kollegen verstehen und weiterentwickeln kann. Auch in der
Softwarearchitektur gibt es Ansätze in Form von Vorgehensmodellen und Frameworks,
die versuchen einen Leitfaden für den Aufbau von Architekturen zu liefern und dabei
ebenfalls ihre Individualität wahren.
3.1.1. Standards
Ein Standard zur Beschreibung von Architekturen wurde von der IEEE Computer Society mit der Norm ANSI/IEEE 1471-2000 geschaffen. Diese wurde am 21. September
2000 freigegeben und am 15. Juli 2007 als ISO/IEC 42010 übernommen und gilt seither
als internationaler Standard. Am 24. November 2011 wurde dieser Standard überarbeitet
und erweitert. Die Norm bildet den Grundstein für Architekturbeschreibungen, bestimmt
jedoch nicht wie die Architektur selbst auszusehen hat. Die Anwendungsgebiete für Architekturbeschreibungen sind im Einzelnen:
• Beschreibung des Systems und dessen Entwicklung
• Kommunikation unter den Stakeholdern des Systems
34
3.1. Systemanalyse
• Bewertung und Vergleich von Architekturen
• Planung, Management und Ausführung von Aufgaben der Systementwicklung
3.1.1.1. ISO/IEC/IEEE 42010:2007
Der vollständige Name dieser Norm lautet „Recommended Practice for Architectural Description of Software-Intensive Systems“ und standardisiert Architekturbeschreibungen
für softwareintensive Systeme, die sich dadurch auszeichnen, dass das Design, der Aufbau, die Bereitstellung und die Evolution des ganzen Systems durch Software wesentlich
beeinflusst wird.
In Abbildung 3.4 ist dass Schlüsselkonzept der IEEE 1471-2000 abgebildet, das neben den
Systemkomponenten auch die Einflussfaktoren auf das System und die nötigen Elemente
zur Architekturbeschreibung berücksichtigt und in Relation stellt.
Abbildung 3.4.: Konzeptionelles Architekturmodell nach IEEE42010:2007 [ISO07]
Der Begriff System umfasst dabei individuelle Anwendungen von traditionellen Systemen,
über Subsysteme, Produktlinien, Produktfamilien bis hin zu ganzen Unternehmen. Jedes
35
3. Grundlagen
dieser Systeme ist bestimmt durch seine Umwelt, die die äußeren Einflüsse verkörpert und
somit die Grenzen bezüglich der Anwendungsbereiche setzt.
Ein oder mehr Stakeholder 1 haben Interessen am oder Belange an das System, wobei Belange diejenigen Anforderungen repräsentieren, die durch mehrere Stakeholder vertreten
werden. Sie beziehen sich auf für die Entwicklung relevante Faktoren wie Performanz,
Zuverlässigkeit, Sicherheit, Verteilung oder Evolvierbarkeit. Ein System existiert im Allgemeinen, um einen Auftrag in seiner jeweiligen Umwelt zu erfüllen, der wiederum durch
die Stakeholder definiert wird.
Ein System besitzt des Weiteren eine zugrunde liegende Architektur, die durch eine Architekturbeschreibung erfasst wird. Diese besteht selbst aus mehreren Bestandteilen und
wird durch Sichten organisiert, die die Belange der Stakeholder widerspiegeln. Die Bedingungen für die Erstellung, Abbildung und Analyse von Sichten wird durch Sichtweisen
festgelegt, die die Sprachen zur Beschreibung oder die Analysemethoden vorschreiben.
Die Sichten sind zusammengesetzt aus einem oder mehreren Architekturmodellen, die aus
den in den Sichtweisen festgelegten Regeln erstellt werden. Ein Architekturmodell kann
dabei in mehr als einer Sicht beteiligt sein. [ISO07]
Eine Architekturbeschreibung nach der ISO 42010:2007 muss die folgenden Kriterien beinhalten:
• Kennzeichnung (ID), Versionsnummer und Übersichtsinformationen
Ausstellungsdatum und Status, ausstellende Organisation
Änderungshistorie, Zusammenfassung, Anwendungsbereich
Kontext, Glossar, Referenzen
• Identifikation der Stakeholder und ihre für das System relevanten Belange
Benutzer, Erwerber, Entwickler, Instandhalter des Systems
Ziel / Aufgabe des Systems
Eignung des Systems, Durchführbarkeit, Risikoabschätzung
Wartbarkeit, Einsatzfähigkeit, Evolvierbarkeit
• Spezifikation einer jeden Sichtweise, die für die Repräsentation der Architektur ausgewählt wurde sowie die Begründung der Auswahl
Kennzeichnung (Name), Stakeholder, Belange
Beschreibungssprache, Modellierungstechniken, analytische Methoden
• Eine oder mehrere Architektursichten
1
Kennzeichnung (ID) und einleitende Informationen
Als Stakeholder wird eine Person oder Gruppe bezeichnet, die ein berechtigtes Interesse am Verlauf
oder Ergebnis eines Prozesses oder Projektes hat.
36
3.1. Systemanalyse
Darstellung des Systems mit den Sprachen, Methoden und Techniken der zugeordneten Sichtweise und Informationen zu Konfigurationen
• Eine Beschreibung aller Inkonsistenzen unter den geforderten Bedingungen für eine
Architekturbeschreibung
• Eine Begründung für die Auswahl der Architektur
3.1.1.2. ISO/IEC/IEEE 42010:2011
Der vollständige Name der aktualisierten Norm lautet nun „Achitecture description“ und
verwendet die bereits bekannten Sichtweisen von Architekturen, ein erweitertes Framework und zusätzlich Beschreibungssprachen für Architekturen.
Abbildung 3.5.: Konzeptionelles Architekturmodell nach IEEE42010:2011 [ISO11]
Der wesentliche Unterschied der aktualisierten Norm ist, dass die Architekturbeschreibung als eigentliches Produkt mehr in das Zentrum gerückt ist und nun aus mehreren
Bestandteilen zusammengesetzt ist, wie in Abbildung 3.5 ersichtlich wird. Weiterhin hat
37
3. Grundlagen
ein System eine Architektur, wobei dies etwas abstraktes darstellt und nur durch seine
Beschreibung greifbar wird. Somit stellt die Beschreibung die eigentliche Architektur dar,
wodurch das System identifizierbar wird.
Stakeholder des Systems haben Belange, die durch Anforderungen, durch Designentscheidungen, die Implementierung und den Betrieb entlang des Systemlebenszyklus entstehen.
Sowohl die Stakeholder als auch ihre Belange werden eindeutig durch die Architekturbeschreibung bestimmt. Die Belange werden durch Architektur–Sichten repräsentiert, die
wiederum durch Sichtweisen in ihrer Erstellung, Interpretation und Analyse festgelegt
sind. Die Sichten bestehen aus einem oder mehreren Architektur–Modellen, wobei Modellierungskonventionen von den Belangen abgeleitet werden. Diese Konventionen sind durch
die Modellart festgelegt, die dieses Architektur–Modell bestimmen.
Neue Elemente dieser Norm sind Korrespondenzen, die verwendet werden um Relationen
zwischen einfachen Elementen auszudrücken. Jedes Konstrukt der Architekturbeschreibung kann ein solches einfaches Element sein, wobei die Korrespondenzen selbst durch
die Korrespondenzregeln geleitet werden. Ein weiterer Bestandteil ist die Architektur–
Begründung, die Erläuterungen und Argumentationen für bereits getroffene Architekturentscheidungen umfasst. Diese kann den Grund für Entscheidungen, mögliche Alternativen, eingegangene Kompromisse, mögliche Konsequenzen und Quellenangaben zu weiterführenden Informationen beinhalten. [ISO11]
Eine Architekturbeschreibung nach der Norm IEEE 42010:2011 muss die folgenden Inhalte
berücksichtigen:
• Kennzeichnung der Architekturbeschreibung und Übersichtsinformationen
• Identifikation der Stakeholder und ihrer Belange
Benutzer, Betreiber, Erwerber, Besitzer, Anbieter, Entwickler, Erbauer, Instandhalter des Systems
Zweck des Systems und die Eignung der Architektur um diesen Zweck zu erfüllen
Potentielle Risiken und Einflüsse während des Lebenszyklus des Systems auf
ihre Stakeholder
Machbarkeit, Wartbarkeit und Evolvierbarkeit des Systems
• Definition einer jeden Sichtweise, die in der Architekturbeschreibung verwendet wurde
Belange, die durch diese Sichtweise betroffen sind und die dazugehörigen Stakeholder
Modellarten, die in der Sichtweise verwendet werden und die verwendeten Modellierungssprachen, Begriffe, Konventionen, Techniken und analytische Methoden
Referenzen zu den Quellen
38
3.1. Systemanalyse
• Eine Sicht und ein Modell für jede genutzte Sichtweise
Identifizierende Informationen sowie die Zuweisung der leitenden Sichtweise
Architektur–Modelle, die alle Belange der leitenden Sichtweise berücksichtigen
und das ganze System abdecken
Aufnahme aller Probleme innerhalb einer Sicht bezogen auf die leitende Sichtweise
• Geeignete Korrespondenzregeln, Korrespondenzen und eine Aufzeichnung aller Inkonsistenzen zwischen den erforderlichen Inhalten einer Architekturbeschreibung
• Begründungen für die getroffenen Architekturentscheidungen
3.1.2. Architektur–Frameworks
Die Verwendung von Architektur–Frameworks ist begründet in der Größe von Unternehmensarchitekturen und der Vielzahl an unterschiedlichen Komponenten, die dabei zum
Einsatz kommen und somit sichergestellt wird, dass alle benötigten Aspekte berücksichtigt
werden. Auch kann das Verwenden einer vordefinierten Struktur dabei helfen die Kommunikation zwischen den Stakeholdern zu verbessern. Sie wahren einen ganzheitlichen Blick
auf die IT eines Unternehmens und berücksichtigen dabei die Organisation und zu verwendende Technologien bei der strategischen IT–Planung. Allerdings lassen sich Frameworks
nur selten generisch verwenden, da sich große Unternehmen auch durch unterschiedliche
Anforderungen auszeichnen und somit spezielle Anpassungen an den Frameworks nötig
sind.
Heutzutage gibt es daher mehr als 70 verschiedene Enterprise–Architecture–Frameworks
auf dem Markt. Allen Frameworks gemeinsam ist jedoch, dass die jeweilige Unternehmensarchitektur durch verschiedene Sichten und Aspekte beschrieben wird. Die Sichten
lassen sich abstrakt einordnen in eine Businessarchitektur, Datenarchitektur, Applikationsarchitektur und eine Technologiearchitektur. Die adressierten Aspekte sollen dabei eine
Antwort liefern auf die Fragen: „Was?, Wie?, Wo?, Wer?, Wieso?, Wann?, Wohin? und
Warum?“. [Han13]
3.1.2.1. Zachman Enterprise Architecture Framework
Das Zachman–Framework ist eines der ersten und bekanntesten Architekturframeworks
und beeinflusst auch noch heutige Frameworks maßgeblich. Es stellt die Analogie zwischen der IT– und Gebäudearchitektur her, die ähnlich komplex ist und ebenfalls die
ganzheitliche Betrachtung von Architekturen fordert. [Kel12] „Entwurfsziel des Frameworks war die Bereitstellung von Beschreibungskonzepten, die geeignet sind, die vielfältigen Schnittstellen von Komponenten eines Informationssystems sowie deren Integration
in die Organisation darzustellen.“ [Han13]
39
3. Grundlagen
Auch beim Zachman–Framework kommen verschiedene Sichten zum Einsatz, die entlang
der Zeilen angeordnet sind, wobei der Detaillierungsgrad der Ebenen von oben nach unten
zunimmt. Oft spricht man hier auch von verschiedenen Rollen. Die Aspekte sind entlang
den Spalten angeordnet und sind im Gegensatz zu den Sichten nicht sortiert. „Jede Sicht
wird unter dem jeweiligen Blickwinkel des Aspekts beleuchtet und in den Spalten der
Matrix dargestellt. Die Kombination aus allen Einträgen ergibt ein Gesamtbild des Unternehmens.“ [Han13] In Abbildung 3.6 ist die Matrix zum Zachman Enterprise Architecture
Framework visualisiert.
Abbildung 3.6.: Zachman–Framework [JS08]
Somit ergeben sich 36 Kategorien um alle beteiligten Objekte darzustellen, sodass die
Stakeholder aus den verschiedenen Sichten auf das Modell schauen können. Jeder dieser
Sichten berücksichtigt dabei die Bedingungen der übergeordneten. Es ist allerdings auch
möglich, dass untergeordnete Sichten übergeordnete beeinflussen, wobei die Bedingungen
der einzelnen Sichten additiv zu verstehen sind. Dabei wird bei den Sichten unterschieden
zwischen Planer, Besitzer, Designer, Builder, Programmierer und Nutzer. Die Perspektiven ergeben sich aus der Kombination mit den Aspekten Daten, Funktion, Netzwerk,
Personen, Zeit und Motivation.
Das Zachman–Framework ist allerdings nicht sehr weit verbreitet, da es extrem umfangreich ist und in der Praxis mehr auf prozessorientierte Vorgehensweisen gesetzt wird als
auf modellzentrierte. [Kel12]
40
3.1. Systemanalyse
3.1.2.2. TOGAF
The Open Group Architecture Framework ist das aktuell bekannteste und meist verwendete Modell zur Planung, Entwicklung und Wartung von Unternehmensarchitekturen. Es
bietet einen generischen Ansatz, der versucht ein breites Spektrum an Anforderungen
abzudecken, sodass auch TOGAF wie schon das Zachman–Framework für eine ad-hoc
Anwendung zu schwergewichtig ist. Es kann jedoch leicht um Bestandteile anderer Frameworks ergänzt werden und umfasst den kompletten Lebenszyklus einer Unternehmensarchitektur, wobei immer die Informationslandschaften im Vordergrund stehen. [Han13]
Das Modell einer Unternehmensarchitektur wird in TOGAF in 4 Domänen unterteilt:
• Geschäftsarchitektur betrachtet die Strategie, die Geschäftsprozesse und die Organisation des Unternehmens.
• Datenarchitektur beschreibt die Daten und deren Zusammenhänge sowie Prinzipien, die für die Geschäftsprozesse und Organisation benötigt werden.
• Anwendungsarchitektur verwaltet die Anwendungen sowie deren Beziehungen
untereinander und zu den Geschäftsprozessen.
• Technologiearchitektur beschreibt die aktuelle technische Realisierung der IT–
Infrastruktur sowie die technischen Standards.
Die Datenarchitektur und die Anwendungsarchitektur werden oft zur Informationssystemarchitektur zusammengefasst. Die Dokumentation von TOGAF ist in sieben Abschnitte
unterteilt, wobei die wichtigsten Teile die Architecture Development Method, das Architecture Content Framework und das Architecture Capability Framework sind.
Abbildung 3.7.: Architecture Development Method2
1
In Abbildung 3.7 sind die acht Phasen der Architecture Development Method zu sehen. Die ersten
beiden Phasen Prelim und A legen den Architekturkontext mit seinen Zielen und dem Zeitraum
fest. Die Phasen B - D sind verantwortlich für die
Architekturinhalte mit Ist– und Soll–Zustand der
spezifischen Teilarchitekturen. Die Phasen E und
F heißen Architekturtransitionsplanung und zeigen Möglichkeiten zur Realisierung mit entsprechender Bewertung auf. Die Phasen G und H sind
die Steuerung der Implementierungsprojekte zur
Überwachung, dass das Projekt den Anforderungen aus dem Soll–Konzept entspricht. Im letzten
Schritt werden neue Anforderungen gesammelt,
die für einen erneuten Durchlauf des Zyklus ausschlaggebend sind.
http://pubs.opengroup.org/architecture/togaf8-doc/arch/Figures/adm.gif (abgerufen am
04. Februar 2014)
41
3. Grundlagen
3.1.2.3. arc42
Die Autoren Hruschka und Zörner bringen mit arc42 ein frei verfügbares Template auf
den Markt, das vor allem übersichtlich und praxisorientiert ist. Angetrieben von der Problematik, dass viele Frameworks oder Vorgehensmodelle überladen sind und es mit hohem
Aufwand verbunden ist solche Modelle überhaupt einsetzbar zu machen, wird mit arc42
eine leichtgewichtige Strukturvorlage geliefert, die lediglich eine feste Gliederung vorsieht.
Natürlich ist diese Gliederung im Laufe der Zeit gewachsen und hat sich inzwischen bei
vielen Projekten bewährt, sodass sie dem Architekten vor allem Zeit erspart, auch wenn
durch eine feste Gliederung nicht immer alle Eventualitäten eines Softwareprojekts abgedeckt werden können. Sie ermöglicht neben dem Architekturprozess auch die Architekturdokumentation, wobei der Fokus allerdings auf einem einzelnen Softwaresystem liegt.
Im Folgenden wird die Gliederung des Templates inhaltlich vorgestellt, das in drei Teile
aufgeteilt ist. Der erste Teil widmet sich dem Problemraum, im zweiten Teil geht es um
die Lösungsbeschreibung und im dritten Teil folgt eine Bewertung der Lösung. [Zör12]
1. Einführung und Ziele Beschreibung von Sinn und Zweck des Systems mit seinen funktionalen und nicht–funktionalen Anforderungen. Es wird mehr Wert auf
Übersichtlichkeit gelegt als auf Vollständigkeit, da ein Einstieg in das zu lösende
Problem geschaffen werden soll. Kurz und knapp sollen die Aufgabenstellung sowie die Qualitätsziele im Hinblick auf die wesentlichen Architekturziele beschrieben
werden.
2. Projektbeteiligte Aufzählen von Personen oder Organisationseinheiten die das
System und seine Architektur beeinflussen. Des Weiteren muss benannt werden,
wie die jeweiligen Stakeholder mit dem System in Berührung stehen und was sie für
das System leisten müssen.
3. Randbedingungen sind diejenigen Faktoren, die die Freiheitsgrade bei Entwurfsentscheidungen begrenzen und sind meist von Auftraggebern oder Stakeholdern vorgegeben. Man unterscheidet zwischen technischen Randbedingungen, wie Hardware,
Software und betriebliche Randbedingungen (Betriebssystem, Datenbanken), organisatorischen Randbedingungen, wie Gesetzte, Vorschriften, Normen, Standards und
Regularien, und Konventionen in Form von Programmier–, Dokumentations– oder
Namenskonventionen.
4. Kontextabgrenzung Die Kontextabgrenzung sieht das ganze System als Blackbox mit seinen externen Schnittstellen und stellt eine Top–Level–Darstellung dar.
Sie berücksichtigt auch Nachbarsysteme, die Schnittstellen zwischen ihnen, die ausgetauschten Daten sowie Datenformate, die Übertragungskanäle und Metainformationen. Man unterscheidet zwischen einem fachlichen Kontext, in dem die Funktion
und das Umfeld des Systems aus einer geschäftlichen oder fachlichen Perspektive
beleuchtet wird und dem technischen bzw. Verteilungskontext, in dem die technischen Kanäle und Übertragungsmedien zwischen dem System, seinen Nachbarn und
deren Umgebung beschrieben wird.
42
3.1. Systemanalyse
5. Lösungsstrategie Hier wird ausgehend von der Aufgabenstellung, den Randbedingungen und den Qualitätsmerkmalen für die zentralen Entwurfsentscheidungen
argumentiert.
6. Bausteinsicht Die Systembestandteile werden als Bausteine bezeichnet und stellen
die statischen Strukturen des Systems dar. Durch eine Top–Down–Verfeinerung soll
das System immer weiter in seine Bestandteile aufgebrochen werden, wobei immer
zwischen Black– und Whitebox zu differenzieren ist. Da wir das System nicht in
seine einzelnen Bestandteile zerlegen können, sondern als Blackbox betrachten, ist
diese Sicht nur sehr eingeschränkt anwendbar.
7. Laufzeitsicht Diese Sicht verdeutlicht die Wirkungsweise des Systems zur Laufzeit. Neben der Zusammenarbeit von Laufzeitkomponenten, beschreibt diese Sicht
auch konkrete, exemplarische Abläufe, die klären wie das System die wichtigsten
fachlichen und technischen Anwendungsfälle bearbeitet.
8. Verteilungssicht Diese Sicht beschreibt die Ausführungsumgebungen des Systems,
die in Form von Knoten (Prozessoren, Rechner, Speicher) angegeben werden. Auf
ihnen werden Softwarebestandteile des Systems ausgeführt oder Daten gespeichert.
9. Typische Muster, Strukturen und Abläufe Dieses Kapitel dient um Redundanzen zu vermeiden, indem typische Strukturen oder Grundmuster, die oftmals
innerhalb der Architektur wiederkehren, nur einmal beschrieben werden.
10. Technische Konzepte Hier werden die zentralen technischen Entscheidungen dargelegt, deren Verständnis für Projektbeteiligte von großer Bedeutung ist. Neben
ihrer Beschreibung, gehört auch eine Begründung für die getroffenen Entscheidungen und eine Evaluation mit möglichen Alternativen in dieses Kapitel.
11. Entwurfsentscheidungen Hier werden die wesentlichen Entwurfsentscheidungen
beschrieben, die sich in folgende Kategorien einordnen lassen:
• Entscheidungen mit lang anhaltender Wirkung
• Entscheidungen mit Überraschungseffekt für zukünftige Architekten
• Entscheidungen unter hohem Risiko oder Zeitdruck getroffen
• Entscheidungen mit enormer Auswirkung auf die Qualitätsmerkmale
12. Qualitätsszenarien werden aufgestellt, um mögliche Risiken und Nicht–Risiken
hinsichtlich der geforderten Qualitätsmerkmale zu identifizieren. Auf Basis dieser
Szenarien lassen sich die Qualitätsmerkmale operationalisieren und messbar machen.
13. Risiken Dieses Kapitel enthält eine geordnete Liste der erkannten technischen Risiken.
14. Glossar Eine Liste oder Tabelle der wichtigsten Begriffe mit Definition.
43
3. Grundlagen
3.2. Anforderungsanalyse
Auf Basis der Anforderungen entsteht die Architektur, deshalb ist es besonders wichtig
eine hohe Qualität bei der Beschreibung der Anforderungen zu gewährleisten. Generell
sind Anforderungen als vom System bereitgestellte Funktionen zu verstehen. Die IEEE
Computer Society beschreibt Anforderungen als:
1. „A condition or capability needed by a user to solve a problem or achieve an object.“
2. „A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or other formally imposed
document.“
3. „A documented representation of a condition or capability as in 1. or 2.“
Eine Anforderung kann also eine abstrakte Beschreibung eines Services oder eine detaillierte funktionale Spezifikation sein, die entweder von einem Benutzer gebraucht wird oder
vom System eingehalten werden muss. Sie dienen außerdem als Grundlage für weitere
Prozessschritte und werden daher oft als Vertragsgrundlage genutzt. [GBBK10]
Dabei sind Anforderungen allerdings oft nicht stabil, sodass sie sich während des Prozessfortschritts ändern. Ein häufiges Problem sind Widersprüchlichkeiten zwischen Anforderungsbeschreibungen, die zu Inkonsistenzen führen können, wenn viele Stakeholder
am Projekt beteiligt sind und viele verschiedene Interessen verfolgt werden. Dies kann
man vermeiden, indem man Anforderungen nach ihrer Relevanz priorisiert oder in stabile
und volatile Anforderungen aufteilt, sodass auf Änderungen entsprechend schnell reagiert
werden kann. Es gibt Kriterien durch die sich gute Anforderungen auszeichnen. Sie sind
eindeutig definiert und abgegrenzt, verständlich, atomar, identifizierbar, einheitlich, notwendig und nachprüfbar. [GBBK10]
Eine bekannte Klassifikation von Anforderungen ist die Aufteilung in funktionale und
nicht–funktionale Anforderungen, wie sie in Abbildung 3.8 dargestellt ist.
Während funktionale Anforderungen
Funktionen beschreiben, die das System zur Verfügung stellen soll, beziehen sich nicht–funktionale Anforderungen eher auf Qualitätsmerkmale, statt
ein spezifisches Verhalten zu definieren.
Funktionale Anforderungen treffen also konkrete Aussagen wie das System
auf bestimmte Eingaben reagieren oder
sich in bestimmten Situationen verhalten soll.
44
Abbildung 3.8.: Klassifikation von Anforderungen [Rup13]
3.2. Anforderungsanalyse
Die nicht–funktionalen Anforderungen beziehen sich auf das ganze System und nicht auf
einzelne Systemfunktionen, wobei sie sichtbare Eigenschaften des Systems charakterisieren, wie Benutzerfreundlichkeit, Zuverlässigkeit oder Sicherheit. Die Trennung der beiden
Begrifflichkeiten ist deshalb oft problematisch, denn erschließt man nicht–funktionale Anforderungen genauer, werden sie zu funktionalen.
Die abstrakte Beschreibung der nicht–funktionalen Anforderungen führt zu einer weiteren
Unterteilung in Qualitätsanforderungen und Randbedingungen. Die Qualitätsanforderungen spezifizieren detailliert die Qualität von Systemfunktionen und beziehen sich daher auf
funktionale Anforderungen. Bezogen auf die „Zuverlässigkeit“ kann als Eigenschaft eines
Qualitätsmerkmals zum Beispiel die „Fehlertoleranz“ angegeben werden. Randbedingungen schränken den Handlungsspielraum der Systementwicklung weiter ein und beinhalten
als Beispiel Vorgaben an die Hardware. [Rup13]
Zu Beginn der Anforderungsanalyse wird zunächst der Scope bestimmt, der den Umfang des Systems definiert. In dieser Analysephase wird der fachliche Umfang festgelegt,
der sicherstellt, dass die Anforderungen auf Umsetzbarkeit geprüft werden und durch
das explizite aufstellen von Nicht–Zielen das richtige System entwickelt wird. Die Anforderungsanalyse umfasst also das Erstellen und Warten eines Anforderungsdokuments
bezüglich des Systems und dient der Bestimmung, Dokumentation und Überprüfung von
Anforderungen. [Som07]
3.2.1. Methoden
Die Anforderungen sind das Produkt der Anforderungsanalyse für deren Herleitung es
verschiedene Methoden gibt:
• Nicht–strukturierte Methoden: Natürliche Sprache
• Semi–strukturierte Methoden: Basieren auf natürlicher Sprache, werden aber durch
Vorlagen, ein eingeschränktes Vokabular und ergänzende Eigenschaften vorgegeben
• Strukturierte Methoden: Folgen einer definierten Syntax, Notation oder formalen
Spezifikation
Im Folgenden werden bewährte Methoden zum Sammeln von Informationen über vorhandene Systeme und das anschließende Herauslösen von Benutzer– und Systemanforderungen vorgestellt. [GBBK10]
3.2.1.1. Anwendungsfälle (Use–Cases)
Die Anwendungsfälle beschreiben die Erwartung der Umwelt an ein System auf Grundlage
der Interaktionen zwischen dem Nutzer und dem System, indem der Nutzer ein fachliches
Ziel zu verwirklichen versucht. Dabei sollen alle möglichen Szenarien berücksichtigt wer-
45
3. Grundlagen
den, wobei der Detaillierungsgrad beliebig fein gewählt werden. [GBBK10] Eine bewährte
Vorlage zur Beschreibung von Anwendungsfällen lieferte Cockburn mit folgendem Ansatz:
Name und Identifier : Benennung mit geordneter Nummerierung
Beschreibung
Beteiligte Akteure: involvierte Personen oder Systeme
Status: Fortschritt des Anwendungsfalls
Verwendete Anwendungsfälle: Verwendung anderer Anwendungsfälle
Auslöser: Gründe für das Ausführen eines Anwendungsfalls
Vorbedingungen: Bedingungen, die eine Ausführung nach sich ziehen
Invarianten: Bedingungen, die nicht verändert werden dürfen
Nachbedingungen: Der zu erwartende Zustand nach erfolgreichem Durchlauf
Standardablauf: Darstellung eines typischen Szenarios
Alternative Ablaufschritte: Szenarien, die ebenfalls auftreten können
Hinweise: kurze Beschreibung und Erklärung zum besseren Verständnis
Änderungsgeschichte: Versionierung mit Autor und Datum
Nicht nur das Systemverhalten kann durch Use–Cases sehr intuitiv beschrieben werden,
sie dienen auch zur Abgrenzung der Nachbarsysteme, sodass der Betrachtungsgegenstand
festgelegt werden kann. Zur modellhaften Beschreibung von Anwendungsfällen werden oft
Sequenzdiagramme verwendet, auf die in Kapitel 3.2.2.1 eingegangen wird.
3.2.1.2. User–Stories
Bei User–Stories beschreibt der Kunde selbst in wenigen Sätzen die Systemfunktionalität,
wobei jede Story genau eine Funktionalität realisiert. Der Kunde ist über den ganzen
Entwicklungszeitraum in das Projekt involviert, woraus sich die genaueren Anforderungen ergeben. Das Vorgehen ist entweder durch ein Schema vorgegeben oder völlig frei.
Oft werden User–Story–Cards verwendet wie in Abbildung 3.9 dargestellt, die das Ziel
verfolgen die Systemfunktionalität zu benennen, aber nicht zu ausführlich. Wie auf den
Abbildung 3.9.: User–Story-Card mit Vorderseite links und Rückseite rechts
46
3
3.2. Anforderungsanalyse
Story–Cards zu erkennen ist, muss jeder Beteiligte seine Rolle angeben, das Ziel das er erreichen möchte und den Nutzen für das System. Auf der Rückseite wird ein Akzeptanzfall
beschrieben mit dem die Funktionalität abgenommen werden kann.
Die User–Stories werden oft bei der agilen Softwareentwicklung eingesetzt, da die einzelnen Stories so beschrieben sind, dass sie im Rahmen eines Sprints4 umgesetzt werden
können. Insgesamt werden bei der agilen Software–Entwicklung ca. 80 User–Stories entwickelt. [GBBK10] Für die Verwendung von User–Stories ergeben sich folgende Vor– und
Nachteile:
+ Kurz und prägnant, daher gut
wartbar
+ Fördern die Diskussion zwischen Kunde und Entwickler
+ Reduzieren das Risiko von
Fehlentwicklungen
– Können kaum als Vertragsgrundlage
dienen
– Sind personenzentriert
– Starke Involvierung des Kunden ist unrealistisch
– Sind stark interpretierbar, sodass ein
Abnahmerisiko besteht
3.2.1.3. Szenarien
Szenarien werden gerne verwendet, um auch die Meinung und Kritik der Stakeholder
zu sammeln, die aus technikfernen Branchen stammen. An realen Beispielen wird durch
eine geschäfftsprozessgetriebene Sicht die Rolle im Softwaresystem leichter verständlich
und die Ausformulierung direkter Benutzerinteraktionen transparenter, sodass die erzeugte Resonanz zur weiteren Ausformulierung der Systemanforderungen verwendet werden
kann. [Som07]
Da Szenarien meist nur auf textbasierten Ansätzen beruhen, die durch Screenshots oder
Diagramme unterstützt werden, sind sie eher als grobgranulare Sammlung von Informationen zu betrachten, die zwar für die Fachabteilungen als Dokumentationen dienen können,
aber kaum Rechtssicherheit oder Verbindlichkeiten ausdrücken. [Rup13]
Szenarien beginnen immer mit einer groben Beschreibung der enthaltenen Interaktionen
und sollten nach [Som07] folgende Punkte enthalten:
• Erwartungen an das Systems und die Benutzer zu Beginn des Szenarios
• Ereignisablauf während des Szenarios
• Auflistung potentieller Fehler während des Szenarios und mögliche Workarounds
• Berücksichtigung gleichzeitig ablaufender Ereignisse
3
4
http://de.wikipedia.org/wiki/Story-Card (abgerufen am 28. Januar 2014)
Bei Scrum wird inkrementell entwickelt und jedes Inkrement ist ein Time–Box von 30 Tagen und heißt
Sprint. Mit jedem Durchlauf erhält der Kunde ein lauffähiges System, das sich dem Endprodukt immer
weiter annähert.
47
3. Grundlagen
• Beschreibung des Systems am Ende des Szenarios
Das Hauptproblem bei Szenarien stellt meist eine fehlende Struktur bei den Beschreibungen dar, sodass keine inhaltliche Einheitlichkeit gewahrt wird, was die Lesbarkeit
verschlechtert. Deshalb erheben Szenarien keinen Anspruch auf Vollständigkeit oder Redundanzfreiheit und auch Inkonsistenzen können nicht ausgeschlossen werden. [Rup13]
3.2.1.4. Interviews
Interviews sind bei fast allen Anforderungsanalysen enthalten, da sie mit geringem Aufwand gute Ergebnisse erzielen können. Dabei werden den Projektbeteiligten Fragen zum
aktuellen und zum zu entwickelnden System gestellt, wobei deren Antworten als die Anforderungen an das neue System gesehen werden. Bei Interviews unterscheidet man zwischen
zwei verschiedenen Arten:
• Geschlossene Interviews durch einen vordefinierten Fragenkatalog
• Offene Interviews ohne Agenda mit vordefinierten Punkten
Interviews sind gut geeignet um zu verstehen wie Beteiligte mit dem zugrunde liegenden
System arbeiten und welche Probleme sich in der Praxis ergeben. Da die Beteiligten
meist sehr tief im System verankert sind, setzen sie vieles, was dem Interviewer nicht klar
ist, als selbstverständlich voraus. Deshalb ist es ratsam neben den Interviews auch noch
andere Arten von Bestimmungsmethoden einzusetzen und durch die Mischung bessere
Ergebnisse zu erzielen. Doch durch fehlende Dokumentationen sind Interviews oft die
einzige Informationsquelle zur Anforderungsbestimmung. [Som07]
3.2.2. Modellierung
Da wir nun Methoden kennengelernt haben wie das Wissen der unterschiedlichen Stakeholder zusammengetragen werden kann, müssen diese Informationen in eine Form gebracht
werden, die es erlaubt von allen Projektbeteiligten verstanden zu werden. Für die Modellierung des erhobenen Wissens gibt es verschiedene Modellierungssprachen. Im Folgenden
wird auf die UML, eine allgemeingültige, visuelle Sprache eingegangen und domänenspezifische Sprachen, die nur in einem speziellen Anwendungsgebiet gültig sind. [GBBK10]
3.2.2.1. Unified Modelling Language
Während Softwareentwicklern früher einheitliche Tools und Sprachen zur Beschreibung
von Architekturen fehlten, ist UML inzwischen als weltweit standardisiertes Verfahren
anerkannt. Es wird verwendet um Analyse– oder Architekturmodelle von Softwarearchitekturen zu dokumentieren und baut auf verschiedenen Diagrammtypen auf, um unterschiedliche Sichten auf ein System repräsentieren zu können. [Sta08]
48
3.2. Anforderungsanalyse
Verhaltensmodelle
• Anwendungsfalldiagramm (Usecase Diagram)
Anwendungsfalldiagramme stellen die Sicht
der Akteure zwischen ihnen selbst und dem
Anwendungsfall dar. Da es sich um ein Verhaltensmodell handelt, wird kein Ablauf modelliert. Man verwendet Anwendungsfalldiagramme zur Modellierung spezifischer Anforderungen an ein System.
• Aktivitätsdiagramm (Activity Diagram)
Aktivitätsdiagramme werden verwendet, um
den Ablauf eines Anwendungsfalls zu beschreiben. Mit ihrer Hilfe lassen sich Vernetzungen von elementaren Funktionen sowie der Daten– und Kontrollfluss darstellen.
Dabei zeigt es die Sicht auf die dynamischen
Elemente des Systems.
• Zeitverlaufdiagramm (Timing Diagram)
Das Zeitverlaufdiagramm erlaubt eine zeitliche Sicht auf die dynamischen Aspekte des
modellierten Systems. Somit lassen sich präzise zeitliche Aussagen treffen, sodass es sich
vor allem zur Spezifikation von Interaktionen
eignet.
• Kommunikationsdiagramm (Communication Diagram)
Kommunikationsdiagramme werden verwendet um zwischen assoziierten Objekten übertragene Nachrichten darzustellen. Durch Sequenzausdrücke wird beschrieben welche der
Nachrichten parallel und welche sequentiell
gesendet werden.
49
3. Grundlagen
• Zustandsdiagramm (Statechart Diagram)
Das Zustandsdiagramm wird verwendet
um Systemzustände zu beschreiben. Dabei werden vor allem auch Zustandsänderungen und deren auslösende Ereignisse berücksichtigt. Das Diagramm wird
immer als endlicher Automat abgebildet
und kann zur Beschreibung des Systemverhaltens verwendet werden.
• Interaktion–Übersichts–Diagramm (Interaction Overview Diagram)
Interaktionsdiagramme werden dann
verwendet, wenn Szenarien sehr groß
werden und durch Aktivitäts– und Sequenzdiagramme dargestellt werden. Sie
gewährleisten eine übersichtliche Darstellungen von komplexen Prozessen
durch Modularisieren von einzelnen Ereignissen.
• Sequenzdiagramm (Sequence Diagram)
Mit Sequenzdiagrammen lässt sich die
Sicht auf die zeitliche Ordnung des modellierten Systems darstellen, wobei Interaktionen zwischen Objekten berücksichtigt werden sowie deren Nachrichtenaustausch. Die Zeitachse verläuft senkrecht, die ausgetauschten Nachrichten
werden durch horizontale Kanten dargestellt.
50
3.2. Anforderungsanalyse
Strukturmodelle Da im Rahmen dieser Arbeit FATool wegen des geschlossenen Quellcodes als Blackbox betrachtet wird, werden die Strukturmodelle durch ihren Bezug zur
Bausteinsicht nicht gebraucht. Als die kleinsten Bausteine bei Software werden die Klassen angesehen, auf die somit natürlich kein Zugriff möglich ist. Der Vollständigkeit halber
sollen die Strukturmodelle aber aufgezählt werden:
• Klassendiagramm (Class Diagram)
• Paketdiagramm (Package Diagram)
• Komponentendiagramm (Component Diagram)
• Verteilungsdiagramm (Deployment Diagram)
• Kompositions–Struktur–Diagramm (Composite Structure Diagram)
• Objektdiagramm (Object Diagram)
Diese Modelle können wegen der eingeschränkten Sichtweise nicht angewendet werden,
deshalb liegt der Fokus auf der Laufzeitsicht.
3.2.2.2. Domain Specific Languages
Eine Domain Specific Language wird verstanden als eine Modellierungssprache, die speziell
für ein bestimmtes Problemfeld geschaffen wurde und nur spezifische Anwendungsbereiche dieser Domäne abdeckt. Durch eine hohe Ausdrucksstärke der Problemspezifität sind
DSLs in der Regel nicht auf andere Domänen übertragbar. Man unterscheidet dabei zwischen textbasierten und visuellen DSLs, während erstere oft in XML formuliert werden,
sind visuelle meist Erweiterung der UML. [Som07]
Bekannte Beispiele für domänenspezifische Sprachen sind „reguläre Ausdrücke“ oder die
„Structured Query Language“, die in mehreren Sprachen Verwendung finden oder systemunabhängig einsetzbar ist.
3.2.2.3. Entity–Relationship–Modell
Das Entity–Relationship–Modell dient als Grundlage der semantischen Datenmodellierung
und beschreibt in der Anforderungsanalyse die relationale Datenstruktur eines Systems.
Dabei sind diese Modelle gängige Praxis zum Entwurf von Datenbankmodellen und bilden
die Basis eines persistenten Informationssystems. Die Daten werden hierbei in Entitäten
unterteilt – individuell identifizierbare Objekte der Wirklichkeit – und durch Beziehungen der Zusammenhang zwischen mehreren Entitäten abgebildet. Informationen und Eigenschaften, die im Kontext zu einer Entität stehen, werden Attribute genannt. Durch
Kardinalitäten wird festgelegt wie die Entitäten miteinander in Beziehung stehen, also
wie viele Verbindungen zwischen den Objekten erlaubt sind. [GBBK10] Hierbei gibt es
folgende Möglichkeiten:
51
3. Grundlagen
• 1:1 Entität A ist genau mit einer Entität B verbunden
• 1:N Entität A kann mit keiner oder beliebig vielen Entitäten B verbunden sein.
Entität B kann nur mit genau einer Entität A verbunden sein.
• N:M Entität A ist mit keiner oder beliebig vielen Entitäten B verbunden. Gleiches
gilt für Entität B im Bezug auf Entität A.
Durch verschiedene Notationen haben sich unterschiedliche grafische Darstellungsformen
für ER–Modelle entwickelt. Eine Übersicht über die verschiedenen Notationen ist in Abbildung 3.10 dargestellt.
Abbildung 3.10.: Typische ER–Notationen
5
Das erste und bekannteste ER–Modell wurde 1976 durch Peter Chen eingeführt und wird
deshalb auch als Chen–Notation bezeichnet. IDEF1X findet hauptsächlich im Bereich
Computer–Aided–Manufacturing Anwendung. Die Bachman– sowie die Martin–Notation
sind weit verbreitete Werkzeug–Diagramm–Sprachen. Die Min–Max–Notation war ein
Standard, wurde aber durch die UML–Notation abgelöst.5 Trotz unterschiedlicher Darstellungsformen, drücken alle Notationen in Abbildung 3.10 denselben Sachverhalt aus.
5
http://de.wikipedia.org/wiki/Entity-Relationship-Modell (abgerufen am 04. Februar 2014)
52
4. Ist–Zustand
Die Ist–Aufnahme des aktuell vorherrschenden Systems wurde nach den vorgestellten
Techniken aus dem Grundlagenkapitel erarbeitet. Hierbei werden zunächst in einer Übersicht die bisherigen Prozesse von FATool in Interaktion mit dem PDM–System Axalant
dargestellt, sowie der interne Aufbau näher erläutert. Anschließend wird der Status–
Quo hinsichtlich der Zentralisierung relevanter Funktionen beschrieben und schließlich
die Schwachstellen im Ist–Zustand herausgearbeitet und dokumentiert.
4.1. Übersicht
Im Folgenden wird der Ist–Zustand, wie er in Abbildung 4.1 zu sehen ist, mit Schwerpunkt auf die AXA2FASys Schnittstelle dargestellt. Die Durchführung der Ist–Analyse
ist Grundlage für das Bewerten der Soll–Architektur, denn Schwachstellen im bisherigen
Konzept können leicht zu Problemen in zukünftigen Architekturen führen und stellen
daher die Anforderungen an das Soll–Konzept.
Abbildung 4.1.: Ist–Architektur
Im Folgenden wird Abbildung 4.1, ausgehend vom Knoten Axalant, beschrieben.
53
4. Ist–Zustand
• Das Herz des bisherigen Systems bildet Axalant, das alle Daten global zur Verfügung stellt und somit das führende System repräsentiert. Beim Anlegen von neuen
Materialien muss stets mit Axalant begonnen werden, da die Materialnummern
dort automatisch und kollisionsfrei mit einem Nummerngenerator erstellt werden
und somit sichergestellt wird, dass diese konzernweit eindeutig sind. Ein weiterer
Grund ist, dass in Axalant auch die Muss–Merkmale hinterlegt sind, also diejenigen
SML–Datenfelder, die bei der Anlage neuer Materialien zwingend erforderlich sind
und somit eine Pflichteingabe darstellen, um einen gültigen Eintrag erzeugen und
anschließend freigeben zu können.
Da Axalant aber nur eine rudimentäre Beschreibung zu den einzelnen Merkmalsfeldern bietet, ist das Anlegen von Materialien für den Anwender schwierig, sodass
nach dem Erstellen der Muss–Kriterien zur weiteren Beschreibung nach FATool gewechselt wird. Dazu muss in Axalant zunächst der richtige SAP –Standort gesetzt
werden, sodass die Daten an die gewünschten lokalen FATool –Installationen verteilt
werden. Ebenfalls muss der Status des Materials geändert werden, um eine weitere Bearbeitung zu ermöglichen. Nach der Neuerstellung von Materialien ist deren
Status in Axalant zunächst auf „510 In Arbeit“. Um die Bearbeitung in FATool zu
ermöglichen, muss der Status auf „550 Freigegeben“ geändert werden. Das betreffende Material wird dann auf die sogenannte Auftragsliste gesetzt, die in regelmäßigen
Abständen auf Einträge überprüft und nach FATool übertragen wird.
• Die Kanten von Axalant in Richtung der zentralen FATool –Server tragen Bezeichnungen wie FP, PP, .., die als Abkürzungen der einzelnen SAP –Systeme gelten
(FP für Friedrichshafen, PP für Passau). Zusammengefasst werden diese Abkürzungen als ein einzelnes Programm verstanden, das im Folgenden „Dispatcher“ genannt
wird. Dieser wird in Passau verwaltet und verteilt je nach gesetztem SAP –Standort
die Daten an die lokalen FATool –Systeme. Dieses Programm ruft im Minutentakt die
Auftragsliste ab und stellt eine Verbindung zu den Schnittstellentabellen her. Sind
in der Auftragsliste neue Materialien enthalten, so werden die neu erstellten Datensätze oder die durchgeführten Änderungen an die dezentralen FATool –Systeme
weitergegeben und aktualisiert.
In dieser Abbildung steht GP1 stellvertretend für das SAP –System in Schwäbisch–
Gmünd. Dort läuft ebenfalls ein „Dispatcher“ nach dem gleichen Prinzip wie in
Passau, allerdings versorgt dieser nur ZF–Lenksysteme mit Daten. Der Grund dafür
ist, dass ZFLS ein Gemeinschaftsunternehmen ist und auch unabhängig vom ZF–
Konzern funktionieren muss. Außerdem werden nur die für ZFLS relevanten Daten
aus Axalant zur Verfügung gestellt, da in Axalant auch firmeninternes Wissen aus
anderen Fertigungsbereichen gespeichert ist, das für andere Divisionen nicht sichtbar
sein darf.
• Die Materialien aus der Auftragsliste liegen nun dezentral und standortabhängig
auf den jeweiligen FATool –Servern vor, die mit Passau, GNS, ..., Steyr bezeichnet werden. Eine Sonderstellung hat hier ZFLS, das unabhängig und eigenständig
versorgt wird.
54
4.1. Übersicht
• Wenn Materialien nun ergänzt oder geändert werden sollen, so erfolgt dies im FATool –Client. Nach Abspeichern der Änderungen beginnt eine interaktive Rückgabe der Merkmale nach Axalant. Dies bedeutet, dass die Axalant–Applikation
automatisch geöffnet wird und die in FATool geänderten oder erstellten Merkmalswerte sofort in der richtigen Eingabemaske in Axalant zur Verfügung stehen. Die
Rückgabe in die Eingabemaske von Axalant anstelle des direkten Schreibens in die
Datenbank hat mehrere Gründe:
Es werden nur Materialien nach FATool übertragen, die den Status „550 Freigegeben“ haben. Der Status selbst kann aber in FATool nicht geändert werden,
sodass für etwaige Bearbeitungen der Status in Axalant auf „565 In Bearbeitung“ gesetzt werden muss. Sind die Eingaben überprüft, kann das Material
wieder freigegeben werden. Somit wird es automatisch wieder auf die Auftragsliste gesetzt und die aktualisierte Version wird wieder an die relevanten
Standorte verteilt. Ist einem Material jedoch mehr als ein SAP –Standort zugeordnet, kann dieses nur mit einer speziellen Sonderrolle geändert werden,
die nur Key–Usern zugeteilt wird, da in der Regel eine Abstimmung mit den
anderen Standorten notwendig ist.
Die Interaktion zwischen Axalant und FATool kann fehlerträchtig sein, da nur
Axalant die originale Eingabemaske bietet, die auf die zugrundeliegende Datenbank abgestimmt ist. Falls in FATool also Änderungen gemacht werden und
sich diese Änderungen auf Merkmalsfelder beziehen, die in Axalant für das
entsprechende Material nicht verfügbar sind, so kann dies bei der interaktiven
Rückgabe in die Eingabemaske von Axalant leicht festgestellt werden.
Sowohl Axalant als auch FATool gehen bei der Gestaltung von Merkmalen,
Merkmalslisten und Konformitätsklassen strikt nach DIN4000 vor. Es kann
jedoch vorkommen, dass Änderungen an der DIN nicht zeitgleich umgesetzt
werden. Somit ist eines der Systeme auf einem aktuelleren Stand als das andere.
Durch die bidirektionale Schnittstelle und den Austausch der Daten zwischen
den Systemen, können solche Inkonsistenzen entdeckt und beseitigt werden.
Durch den manuellen Statuswechsel in Axalant werden auch Schnittstellen angesprochen, die durch ein direktes Schreiben vernachlässigt würden. Somit findet nach dem Freigeben eines Materials die direkte Übertragung nach SAP
statt.
• Die Kommunikation zwischen dem dezentralen FATool –Server und dem FaTool –
Client ist bidirektional, da es sich um eine Client–Server Anwendung handelt und
somit die Interaktionen zwischen den beteiligten Komponenten verdeutlicht werden
soll. Es werden allerdings auch Daten am lokalen FATool –Server gespeichert, die
nicht an Axalant übertragen werden. Dabei handelt es sich um zusätzliche Informationen, die von Axalant nicht verwaltet werden können, wie es bei Mehrschneidensystemen der Fall ist. In FATool ist es möglich für dieses Werkzeug verschiedene Schneiden auszuwählen, denen verschiedene Nummern zugewiesen sind. In Axalant werden
55
4. Ist–Zustand
diese Schneiden nicht berücksichtigt, sodass diese Informationen bei der interaktiven
Rückgabe verloren gehen würden. Eine Auswahl über verschiedene Schneiden bei
Komplettwerkzeugen in FATool mit zugehöriger Stückliste kann im Anhang A.2 in
Abbildung A.7 eingesehen werden.
Der bisherige Aufbau von FATool hat mit dem „Dispatcher“ bereits eine zentrale Komponente mit dem alle Standorte zentral aus Passau versorgt werden. Nur ZFLS stellt
eine Ausnahme dar, das durch einen separaten „Dispatcher“ von Schwäbisch–Gmünd aus
verwaltet wird. Trotz dieser zentralen Komponente treten alle Nachteile eines dezentralen Systems auf, da jeder Standort durch die Verteilung nur die Daten einsehen kann,
die in Axalant mit seinem SAP –Standort gekennzeichnet sind und somit eine stark eingeschränkte Sicht auf das komplette System bieten. Dies führt unweigerlich zu Redundanzen
und verursacht Mehrkosten, die durch das Neuerstellen von bereits an anderen Standorten
vorhandenen Betriebsmitteln entstehen.
Das oben beschriebene Zusammenspiel zwischen den Systemen wird in Abbildung 4.2
zum leichteren Verständnis noch einmal als Prozess dargestellt. Diese Abbildung stellt
den vorhergesehenen Austausch von Materialstämmen zwischen Axalant und FATool dar.
Abbildung 4.2.: Austausch von Materialstämmen
Ausgehend von Axalant wird ein Material angelegt für das im nächsten Schritt die hinterlegten Muss–Merkmale ausgefüllt werden müssen. Nur durch das Bereitstellen der
Muss–Kriterien kann ein Materialstamm freigegeben und somit synchronisiert werden.
Zur Übertragung nach FATool muss lediglich ein Statuswechsel auf „550 Freigegeben“
am Materialstamm durchgeführt werden. Eine originalgetreue Darstellung der FDO–
Materialstammmaske aus Axalant ist im Anhang A.2 bei Abbildung A.1 zu finden. Der
gewünschte Datensatz ist dann in FATool verfügbar und kann um weitere Sachmerkmale
ergänzt werden. Ist das Zuordnen von Merkmalswerten abgeschlossen, muss das Material
wieder mit Axalant synchronisiert werden, sodass beide Systeme konsistent sind. Dazu
setzt man in FATool den Betriebsmittelstatus auf „Warten auf Axalant Freigabe“ und es
öffnen sich entsprechende Eingabemasken in Axalant. Hierbei handelt es sich um die Materiallistenstammmaske (FDO-ART-SLI) zum Statuswechsel und die Klassifizierungsmaske
(FDO-GRP-ART-RLI) zum Eintragen der Merkmalswerte, die im Anhang A.2 in Abbildung A.2 und Abbildung A.3 dargestellt sind. Zusätzlich wurde dieser Eingabemaske ein
Menü angefügt mit der Option „Zurück nach CAD“, um die Schnittstelle zu beenden.
Dieser Vorgang wird als interaktive Rückgabe bezeichnet und setzt voraus, dass Axalant
56
4.2. Status–Quo
im Hintergrund geöffnet ist sowie ein User mit ausreichenden Berechtigungen am System angemeldet ist. Um die in FATool ergänzten Daten nun übernehmen zu können,
wird in Axalant der Status auf „565 In Nachbearbeitung“ gesetzt und der Materialstamm
anschließend wieder freigegeben.
Diese Übersicht liefert eine abstrakte Sicht auf die Architektur von FATool und Axalant.
In Abschnitt 4.2 wird auf die Details von FATool eingegangen und in Abschnitt 4.3 werden Schwachstellen des Systems sowie mögliche Ausnahmefälle bei bekannten Prozessen
beschrieben.
4.2. Status–Quo
Wie bereits in der Übersicht angedeutet, werden die Daten zwischen Axalant und FATool mit Hilfe eines „Dispatchers“ synchronisiert. Bisher wurde dieses Programm mit den
Abkürzungen der SAP –Standorte umschrieben, da genau diese in der Verteilung ausschlaggebend sind. Der „Dispatcher“ wird als Überbegriff für die Verteilung der Daten
verwendet, wobei er als ein Zusammenspiel aus mehreren Programmen zu verstehen ist.
Eine detailliertere Darstellung des Verteilungsprozesses ist in Abbildung 4.3 illustriert.
Abbildung 4.3.: FATool Master– und Client–Service [Fas12]
Die Verteilung ist aufgeteilt in einen Master–Service und einen Client–Service. Während
der Master–Service in Passau verwaltet wird und somit schon als eine zentrale Einheit
gesehen werden kann, laufen die Client–Services an jedem Standort gesondert.
57
4. Ist–Zustand
Der Master–Service arbeitet auf den Schnittstellentabellen und verteilt Meta–Daten und
die zugehörigen Dokumente. Dabei fungieren die Schnittstellentabellen als Zwischenspeicher für die Daten, die aus Axalant stammen und an die zugehörigen FATool –Zielsysteme
verteilt werden sollen. Damit dieser Vorgang kontinuierlich stattfindet, ruft der Master–
Service zeitgesteuert im Minutentakt bestimmte Funktionen auf und überprüft eine spezielle Tabelle innerhalb von Axalant. Diese Tabelle heißt Auftragsliste Datenexport und
ist im Anhang A.2 in Abbildung A.4 dargestellt. Da die Schnittstellentabellen und die
Axalant–Datenbank physikalisch getrennt sind, wird für die Übertragung ein Datenbank–
Link verwendet.
Jeder Standort hat seine eigenen FATool –Serversysteme, die vom Client–Service mit Daten versorgt werden. Genau wie der Master–Service wird dieser zeitgesteuert im Minutentakt aufgerufen und fragt beim Master–Service nach, ob für das entsprechende Zielsystem
Einträge vorliegen. In diesem Fall werden Daten bzw. Dokumente in das jeweilige System übertragen und stehen diesem Standort lokal zur Verfügung. Die FATool –Anwendung
selbst ist eine Client–Server Applikation und kommuniziert mit den lokalen Servern.
Falls in FATool Änderungen vorgenommen werden, müssen diese auch in Axalant eingecheckt werden. Für den Rückweg der Aktualisierung gibt es keine automatischen Prozesse,
sondern eine „interaktive Rückgabe“, die benutzergesteuert funktioniert. Dies hat unter
anderem mit den Berechtigungen zu tun, die in Axalant benötigt werden, um Änderungen
durchzuführen.
4.2.1. Aufbau
Ein typischer Aufbau eines Serversystems zum Betrieb von FATool ist in Abbildung 4.4
zu sehen. Es ist allerdings anzumerken, dass sich der Aufbau je nach Standort unterscheiden kann, wobei es in erster Linie auf den Einsatzzweck von FATool ankommt. Des
Weiteren müssen die verschiedenen Server, die hier logisch getrennt sind, physisch keine
unterschiedlichen Maschinen sein.
Abbildung 4.4.: Serveraufbau für FATool–
Installation
58
Der Datenbank–Server wird vom Client–
Service mit Daten beliefert und ist aufgeteilt in Konfigurations– und Daten–
Tabellen. Technisch gesehen beherrscht
FATool mehrere Datenbank–Systeme.
Während in Passau Oracle verwendet
wird, kommt in Gainesville Microsoft
SQL Server zum Einsatz. Der Applikationsserver ist zuständig für die Umsetzung des Client–Server–Konzepts und
stellt das Bindeglied zwischen der FATool –Client–Anwendung und den restlichen Servern dar.
4.2. Status–Quo
Dokumente werden nicht in der Datenbank gespeichert, sondern liegen auf einem Dateiserver, der als Grundlage einen Verzeichnisbaum zur Strukturierung verwendet. Dies gewährleistet einen schnellen Zugriff auf große Dateien durch die Produktion.
Der Lizenzserver verteilt je nach Verwendung automatisch die richtige Lizenz und muss
immer lokal zur Verfügung stehen, da ein Ausfall eines Lizenzservers auch den Ausfall der
Produktion nach sich ziehen könnte. Dies betrifft nur Standorte an denen DNC–Maschinen
im Einsatz sind.
4.2.2. Datenbank
Die Datenbank von FATool ist intern in Konfigurations– und Datentabellen aufgeteilt,
wie in Abbildung 4.5 ersichtlich wird.
Die Konfigurationstabellen sind fest
vorgegeben und werden von der
Client–Anwendung für etwaige Beschreibungen im Programm verwendet. Sie enthalten Leisteninformationen, die den Sachmerkmalen
und Sachmerkmalleisten zugeordnet werden. Die Datentabellen enthalten die Nutzdaten, also die Werte zu den Merkmalen. Während
die Konfigurationstabellen grundsätzlich vom System bereitgestellt
werden und nicht verändert werden
müssen, sind die Datentabellen manuell mit Einträgen zu füllen.
Abbildung 4.5.: Datenbankstruktur [Fas10]
Die Tabellen orientieren sich dabei an der DIN4000, wobei für jede Leiste eine eigene
Tabelle angelegt wird. Um die Menge an Tabellen und Klassen einzugrenzen werden die
Bildinformationen verwendet, sodass Sachmerkmale je nach Bildnummer den Leisten zugeordnet werden.
4.2.3. Schnittstelle
Durch die Schnittstelle AXA2FASys (oder auch PDM2FATool genannt) soll der Austausch
von Sachmerkmaldaten und Dokumenten zwischen FATool und Axalant sichergestellt werden. Beide Systeme basieren auf der DIN4000, die Klassenbenennung ist allerdings unterschiedlich, sodass Mapping–Funktionalitäten benötigt werden, um die Axalant–Klassen
(z.B. TT0030) in die richtigen Leisten von FATool (z.B. DIN4000–90) importieren zu
können. Ein Abgleich zwischen den Systemen ist in beide Richtungen möglich, wobei der
59
4. Ist–Zustand
Weg von Axalant nach FATool automatisch abläuft und von FATool nach Axalant manuell
durch die „interaktive Rückgabe“.
Die Schnittstelle selbst arbeitet direkt auf Datenbankebene, sodass gewünschte Datensätze zunächst aus der ursprünglichen Datenbank kopiert und in Schnittstellentabellen zur
Verfügung gestellt werden. Die Daten aus den Schnittstellentabellen werden schließlich
abgeholt, quittiert und in die Zieldatenbank geschrieben.
Für den Abgleich werden verschiedene Komponenten benötigt, wie der Master–Service,
der den Zugriff auf die Schnittstellentabellen ermöglicht oder der Client–Service, der die
Daten schließlich in die lokale Datenbank übernimmt, aber auch Komponenten, die seitens
der ZF zur Verfügung gestellt werden müssen:
• Axalant–Client zum Herauslesen und Zurückgeben der Daten
• SQL–Prozeduren und Funktionen zum Bereitstellen von Daten in Schnittstellentabellen
• CAX–Batch–Client zum Herauslesen der Dokumente aus Axalant
Der Axalant–Client wird dann benötigt, wenn in FATool Betriebsmittel manuell in das
System importiert werden sollen oder wenn durchgeführte Änderungen nach Axalant zurückgegeben werden. Dazu muss der Nutzer mit seinem Account in Axalant angemeldet
sein, sodass die entsprechenden Berechtigungen des Anwenders geprüft werden können.
Die SQL–Prozeduren werden zeitgesteuert durch den Master–Service aufgerufen und verwenden je nach durchzuführender Aktion verschiedene Funktionen, die auf den Schnittstellentabellen arbeiten. Dabei werden SML–Daten aus Axalant in diese Tabellen transportiert und durch Anfrage des Client–Service in die Konfigurations– und Datentabellen der lokalen FATool –Systeme verteilt. Hierfür werden die Konfigurationstabellen gebraucht, durch die beschrieben wird, wie eine Axalant–Klasse nach FATool gemappt wird.
Sie beinhaltet die Quellleiste mit der zugehörigen Bezeichnung und die Zielleiste mit einer
Bildkennung sowie einen Bezeichner für diese Leiste und einer Menge an Mapping–Regeln.
Diese Regeln müssen manuell angelegt werden. Für Datensätze, die über keine geeignete
Zielleiste in FATool verfügen, werden entsprechend der Konfiguration, vom System automatisch neue Leisten angelegt. Dies ist immer dann der Fall, wenn Klassen aus Axalant
keiner entsprechenden Klasse in FATool zugeordnet werden können. Für die Datentabellen gilt, dass sie immer nur von einer Seite gepflegt werden, wobei es eine lesende und
eine schreibende Seite gibt. Die schreibende ist in diesem Fall die vom Master–Service
aufgerufene Prozedur.
60
4.2. Status–Quo
In Tabelle 4.1 werden die Konfigurationstabellen der Schnittstelle aufgelistet:
Tabelle
AXA_GROUP_FATOOL_SYSTEM
AXA_GROUP_DAT
AXA_GRP_CLA
AXA_ZF_PLANTS
Beschreibung
Zuordnungstabelle für Leisten zu den lokalen FATool –
Zielsystemen.
Enthält Informationen zur Axalant–Klasse wie den
Klassencode, die Kurzbezeichnung oder die Beschreibung.
Enthält die verschiedenen Merkmalsbeschreibungen, die
einer Klasse zugeordnet sind. Für jedes Merkmal wird
ein eigener Eintrag erstellt, der einer Klasse zugewiesen
ist.
Enthält die genaue Definition des Werks, da oft mehrere
Werke an einem SAP –System hängen, ist die Abkürzung
nicht ausreichend für eine eindeutige Identifikation.
Tabelle 4.1.: Konfigurationstabellen der Schnittstelle
In Tabelle 4.2 sind die Datentabellen der Schnittstelle aufgelistet:
Tabelle
AXA_MAT_FATOOL_SYSTEM
AXA_GRP_ART
AXA_MASTER_STR
AXA_ZF_MAT_SAP
AXA_FILE_FATOOL_SYSTEM
AXA_MAT_FILE_DAT
FATOOL_AXA_GRP_ART
Beschreibung
Zuordnungstabelle für Materialstämme zu FATool –
Zielsystemen.
Enthält die eigentlichen Merkmalswerte.
Enthält die Stücklisten.
Zuordnung von Materialstämmen zum entsprechenden
Werk.
Zuordnungstabelle für Dokumentstämme zu FATool –
Zielsystemen.
Enthält Dokumentinformationen und stellt die Verbindung zwischen Material– und Dokumentstamm her.
Dient zur Datenübergabe von FATool nach Axalant.
Tabelle 4.2.: Datentabellen der Schnittstelle
Der CAX–Batch–Client ist schließlich zuständig für das Auschecken von Dokumenten aus
Axalant. Dieser Prozess erstellt im Allgemeinen eine Kopie des betroffenen Dokuments
und setzt es an der richtigen Stelle des Verzeichnisbaumes in FATool ein, sodass es auch
in diesem System verfügbar ist.
61
4. Ist–Zustand
Abbildung 4.6.: Übertragungsprozess
In Abbildung 4.6 ist der Übertragungsprozess
mit Prozeduren und Funktionen dargestellt. Ausgehend vom Master–Service wird die Prozedur
CADIM_CICS zeitgesteuert aufgerufen. Diese überprüft die Auftragsliste (Datenexport) auf neue
passende Einträge. Falls Einträge existieren werden die Sachmerkmale des Materialstamms mit
der Funktion GRP_ART_P8 kopiert. Die Stücklisten werden mit MASTER_STR in die Schnittstellentabellen kopiert. Schließlich werden noch mit einer der drei MAT_FILE_DAT Funktionen die angehängten Dokumentstämme untersucht, wobei der
Dokumenttyp für den Aufruf der entsprechenden
Funktion entscheidend ist.
Die beteiligten Aktionen bei der automatischen Übergabe sind in [Fas10] spezifiziert:
• Stammdaten übernehmen
• Stückliste übernehmen
• Standortzuordnungen übernehmen
• Massenänderungen zurückübergeben
• Dokumente anfordern oder löschen
4.2.4. Interaktive Rückgabe
Der Rückweg von FATool nach Axalant ist ein manueller Prozess der als „interaktive
Rückgabe“ bezeichnet wird. In Abbildung 4.2 wurde bereits der Hin– und Rückweg als
Prozess dargestellt.
Bei der Rückgabe nach Axalant muss der Betriebsmittelstatus in FATool auf „6 Warte auf
Axalant Freigabe“ gesetzt werden. Ein Axalant–Client mit angemeldeten Benutzer muss
im Hintergrund laufen. Die Daten werden dann mit Hilfe einer Datei an Axalant übergeben. Die Datei enthält alle benötigten Daten, wobei die Sachmerkmale als Einzelzeilen
eingetragen werden und als Trennzeichen zwischen Identifier und Werten 0xA5 verwendet
wird. Währenddessen die Schnittstelle zu Axalant geöffnet ist, aktualisiert FATool zwar
seine Oberfläche, aber es sind keine Benutzer–Interaktionen möglich.
Nachdem die Schnittstelle zu Axalant geschlossen wurde, wird in FATool der Return–Code
ausgewertet. Ist dieser 0, so werden die Daten aus Axalant noch einmal nach FATool geladen, da der Benutzer während der Rückgabe in Axalant noch ergänzende Eingaben
machen könnte. Falls dabei der Axalant–Status des Materialstamms „550 Freigegeben“
lautet, so wird der Betriebsmittelstatus in FATool dementsprechend angepasst und auf „0
62
4.2. Status–Quo
Freigegeben“ gesetzt. Falls der Return–Code -1 lautet, so wird eine Fehlerdatei ausgewertet und angezeigt. Der Betriebsmittelstatus bleibt im Fehlerfall auf „6 Warte auf Axalant
Freigabe“, kann aber durch eine automatische Übergabe von Axalant nach FATool auf „0
Freigegeben“ geändert werden.
4.2.5. Transferdaten
Um Einträge in den Schnittstellentabellen erzeugen zu können, bedient man sich der
zugrunde liegenden Axalant–Tabellen, die die gewünschten Daten beinhalten. Die Datenbanksysteme von Axalant und FATool sind jedoch nicht nur physikalisch getrennt, sondern
auch an unterschiedlichen Standorten. Während die Server für Axalant in Friedrichshafen
stehen, sind sie für die Verwaltung von FATool in Passau angesiedelt. Daten, die von
FATool importiert werden, müssen also von Axalant nach FATool transferiert werden,
sodass man sie „Transferdaten“ nennt. Als technische Lösung wurden hierfür sogenannte
Datenbank–Links verwendet, die in Oracle–Datenbanken zur Verfügung stehen.
Ein Datenbank–Link ist als Pointer zu verstehen, der eine unidirektionale Verbindung
zu einer anderen Datenbank ermöglicht. Dabei handelt es sich um zwei physikalische
Datenbankserver, die als verteilte Systeme
zu verstehen sind, aber als eine einheitliche
logische Datenbank benutzbar werden. Der
Vorteil den Datenbank–Links bieten ist, dass
ein lokaler Benutzer eine andere Datenbank
verwenden kann, ohne dabei als Benutzer
der anderen Datenbank eingetragen zu sein.
Die Verbindung kann dahingehend kontrolliert werden, dass beispielsweise nur „Stored
Procedures“ zugelassen werden. Somit stellt
der Datenbank–Link eine einfache Weise dar,
um Datenbanken miteinander zu verbinden.
Abbildung 4.7.: Funktionsweise
eines
1
Database–Link
In Abbildung 4.7 ist die Arbeitsweise eines Datenbank–Links dargestellt. Ein Benutzer
stellt eine Anfrage an die lokale Datenbank, da diese einen Link zur Remotedatenbank
gespeichert hat, wird die Anfrage an diese Datenbank umgeleitet. Der Benutzer selbst
merkt davon nichts und kann die entfernte Datenbank mit Hilfe eines eindeutigen globalen
Datenbanknamens direkt ansprechen. Globale Namen können mit Hilfe von Synonymen
angelegt werden, sodass eine Tabelle, die auf einem anderen Host zu finden ist, ohne
Angabe der kompletten URL erreicht werden kann.
1
http://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm#i1007719
(abgerufen am 04. Februar 2013)
63
4. Ist–Zustand
4.3. Schwachstellen im Ist–Zustand
4.3.1. Inkonsistenz zwischen Sachmerkmalen
Inkonsistente Sachmerkmale zwischen Axalant und FATool sind einfach herzustellen. Der
Prozess zum Austausch von SML–Daten ist bereits in Abbildung 4.2 skizziert und wird
in Abbildung 4.8 nun abgewandelt dargestellt.
Es beginnt wie auch im vorhergesehenen Prozess mit dem Anlegen eines Materialstamms
in Axalant. Der darauffolgende Schritt umgeht jedoch bereits zwei essentielle Vorgänge. In
FATool kann ein neu angelegter Materialstamm mit der Funktion „Neues Betriebsmittel
aus Axalant holen“ nach FATool importiert werden, unabhängig von dessen Status oder
ausgefüllten Muss–Merkmalen. Ist dieser Materialstamm erst einmal in FATool verfügbar,
können die Merkmalswerte beliebig ergänzt werden und der Betriebsmittelstatus auf „0
Freigegeben“ gesetzt werden, ohne dass Änderungen nach Axalant eingecheckt werden
müssen. Das führende System Axalant wird dadurch umgangen und auch Folgesysteme
wie SAP somit nicht aktualisiert.
Abbildung 4.8.: Erzeugen von Inkonsistenzen zwischen SML–Daten
Es muss zu keinem Zeitpunkt der Status auf „6 Warte auf Axalant Freigabe“ gesetzt
werden, was die interaktive Rückgabe aktivieren würde.
Inkonsistenzen sollten im Normalfall nur dann auftreten, wenn Mehrinformationen zur
Verfügung stehen, die von einem der beiden Systeme nicht verarbeitet werden können,
wie es bei KWZ mit mehreren Schneiden der Fall ist.
4.3.2. Eingeschränkte Suche
Die Suche nach Betriebsmitteln in FATool ist auf den eigenen Standort begrenzt. Dies
liegt einerseits an dem Verteilungskonzept, das mit den SAP –Standorten arbeitet und
andererseits an den lokalen Installationen, wodurch jeder Standort seine eigene Datenbank
besitzt. Das Problem besteht in der Redundanz bei der Fertigung von Betriebsmitteln.
64
4.3. Schwachstellen im Ist–Zustand
Oft werden solche neu angelegt und entwickelt, obwohl sie an anderen Standorten bereits
verfügbar wären, aber schlichtweg nicht gefunden werden oder einsehbar sind.
Um trotzdem nach FHM an anderen Standorten suchen zu können, musste man bisher nach Axalant wechseln. War die Suche nach dem Betriebsmittel erfolgreich, so muss
der eigene SAP –Standort eingetragen werden, der dieses Bauteil am lokalen Standort in
FATool verfügbar macht. Ist jedoch mehr als ein SAP –Standort eingetragen, darf das
Betriebsmittel nicht mehr geändert werden bzw. nur vom Standort mit der entsprechenden Änderungshoheit. Dies kann umgangen werden, indem eine Kopie des betroffenen
Materialstamms in Axalant angelegt wird, der nur einen SAP –Standorteintrag enthält.
4.3.3. Klassenmapping
Wie bereits beschrieben haben FATool und Axalant verschiedenartige Klassensysteme,
auch wenn beide auf DIN4000 basieren. Dies erfordert ein Mapping beim Import von
Klassen nach FATool. Die Herausforderung besteht darin, die Klassen in FATool aktuell zu halten, sodass beide Systeme auf denselben Grundlagen beruhen. Es ist jedoch –
ähnlich wie beim Dokumentabgleich – schwierig festzustellen, wann Änderungen an den
Klassen vorgenommen wurden. Wenn Änderungen in den lokalen FATool –Installationen
vorgenommen werden, müssen diese für jeden Standort manuell ausgeführt werden, was
mit einem enormen Zeitaufwand verbunden ist. So kann der komplette Update–Prozess
zwischen acht bis zehn Stunden dauern, sodass während dieser Zeit auch Inkonsistenzen
zwischen den Systemen auftreten können.
4.3.4. Änderungswesen
Um Änderungen an Betriebsmitteln in FATool verfolgen zu können, kann ein Konfigurationsparameter gesetzt werden, der diese in einem Änderungslogbuch protokolliert. In
diesem Logbuch werden allerdings nur der Änderungsuser und das Änderungsdatum gespeichert, sodass die ausgeführte Aktion nicht mehr nachvollziehbar ist. Durch das fehlende Änderungswesen können Änderungen teilweise nicht mehr rückgängig gemacht werden,
da die Art der Änderung nicht mehr bekannt ist.
4.3.5. Aktualisierungen
Bei Änderungen, die alle verfügbaren FATool –Installationen im ZF Konzern betreffen, wie
dem Klassenmapping, müssen diese für alle Standorte manuell durchgeführt werden. Es
muss also für jedes FATool –System die gleiche Aktion ausgeführt werden, wobei dieser
Prozess zeitversetzt stattfindet und dadurch zeitbedingte Inkonsistenzen zwischen den
Systemen entstehen.
65
4. Ist–Zustand
4.3.6. Dokumentabgleich
Wenn in Axalant Änderungen an Dokumenten gemacht werden, wird FATool über diese
Änderungen nicht in Kenntnis gesetzt, sodass zum Teil veraltete Dokumente im System
kursieren. Der Grund dafür liegt in der Schnittstelle AXA2FASys, die zwar Statuswechsel
am Materialstamm berücksichtigt, jedoch nicht am Dokumentenstamm. So werden die
Dokumente nur aktualisiert, wenn auch Änderungen am Materialstamm vollzogen werden und der Datenexport über die Auftragsliste angestoßen wird, wie in Abbildung 4.9
dargestellt. Eine andere Möglichkeit ein Dokument in FATool zu aktualisieren führt über
die Applikation selbst, indem die Funktion „Aktuelles Betriebsmittel aus Axalant holen“
gewählt wird und die entsprechende Materialnummer eingegeben wird. Beide Vorgehen
sind jedoch umständlich und nicht intuitiv.
Abbildung 4.9.: Dokumentabgleich mit bisherigen Möglichkeiten
Ein weiteres Problem des Dokumentabgleichs stellt die Versionierung in Axalant dar. Bei
versionierten Dokumente bleiben ältere im System erhalten, haben aber einen ungültigen
Status. Die Dokumente in FATool werden nicht durch die neueren Versionen ersetzt. Erschwerend kommt hinzu, dass bei einem manuellen Aktualisierungsprozess in FATool, wie
durch „Aktuelles Betriebsmittel aus Axalant holen“, das entsprechende Dokument trotz
neuer Versionen nicht aktualisiert wird. Somit werden durch die Versionierung dauerhaft
veraltete Dokumente in FATool gehalten.
4.3.7. Transferdaten
Die Transferdaten sind aus der Gegebenheit erwachsen, dass die Datenbanken von FATool und Axalant nicht nur physisch, sondern auch örtlich getrennt sind. Das Problem
bei den Transferdaten besteht darin, dass bei einer schlechten Anbindung des Standorts
66
4.3. Schwachstellen im Ist–Zustand
auch der Datenbank–Link in seiner Geschwindigkeit reduziert ist. Dies führt zu langen
Ladezeiten und macht große Auswertungen, Massenupdates oder Dokumentüberrollungen in einer angemessenen Zeit nahezu unmöglich. Vor allem viele kleine Anfragen an die
Remote–Datenbank bremsen den Link aus, da sich die Verzögerung durch die Verbindung
aufsummiert. Ein weiteres Problem des Datenbank–Link besteht im Aufbau der Queries.
Anfragen, die nur wenige Bedingungen enthalten, können den Link schnell verlangsamen,
da möglicherweise eine ganze Axalant–Tabelle empfangen werden muss und diese erst in
den Cache der lokalen Datenbank geladen werden muss.
In Abbildung 4.10 ist die aktuelle Situation mit den Transferdaten dargestellt. Die Da-
Abbildung 4.10.: Transferdaten mit Verbindung über Datenbank–Link
ten die gebraucht werden, um die Schnittstellentabellen zu füllen, sind in der Axalant
Datenbank zu finden. Diese befindet sich jedoch in Friedrichshafen, während die FATool –
Verwaltung in Passau ist. Die Prozeduren und Funktionen der Schnittstelle holen sich die
Daten über den Link und speichern sie in Passau in den Übergabetabellen. Ein „Dispatcher“ ist zuständig für die Verteilung der Daten an die lokalen Zielsysteme.
4.3.8. Inkonsistenz zwischen Dokumenten
Inkonsistenzen bei Dokumenten entstehen immer dann, wenn Dokumente direkt in FATool
verwaltet werden sollen oder nicht nach Axalant eingecheckt werden. Da Axalant das
strategische Dokumentverwaltungssystem ist, sollen alle Dokumente, die in FATool zur
Verfügung stehen, auch primär in Axalant vorhanden sein.
Generell ist es in FATool möglich einem Betriebsmittel ein Dokument manuell hinzuzufügen, was zu dem Problem führt, dass ein solches Dokument nicht von der Schnittstelle
67
4. Ist–Zustand
berücksichtigt wird und damit sehr leicht Inkonsistenzen zwischen beiden Systemen erzeugt werden können. Selbst wenn das Einchecken des Dokuments nach Axalant gewünscht
wird, muss zunächst manuell in Axalant ein Dokumentstamm angelegt werden.
Ein weiteres gängigeres Szenario ist das Anlegen eines Materials mit dem darauffolgenden
Erzeugen eines 3D–Modells, wie es in Abbildung 4.11 dargestellt ist. Hierbei kommen
mehrere Systeme zum Einsatz, die farblich gekennzeichnet sind: Axalant in rot, FATool
in gelb und CREO in grün. Des Weiteren sind auch zwei verschiedene Prozessabläufe
gekennzeichnet, wobei der richtige in grün und der falsche in rot abgebildet ist.
Abbildung 4.11.: Prozess vom Material zum 3D–Modell
Der Prozess zum Anlegen eines neuen Materialstamms beginnt immer in Axalant, da hier
unternehmensweit eindeutige Materialnummern vergeben werden. Da im aktuellen Zustand noch keine Merkmalswerte eingetragen sind, kann das Material in Axalant noch
nicht freigegeben und somit nicht über die AXA2FASys Schnittstelle übertragen werden. In FATool gibt es allerdings die Möglichkeit Betriebsmittel manuell zu importieren,
indem man die Funktion „Neues Betriebsmittel aus Axalant holen“ wählt und die entsprechende Materialnummer bereithält. Jetzt können die benötigten Merkmalswerte in
FATool ausgefüllt werden und daraufhin ein 3D–Modell erzeugt werden. Dies geschieht
im Hintergrund, indem CREO aufgerufen wird und eine STL2 –Datei erzeugt wird, die
als 3D–Flächenmodell im FATool –Viewer betrachtet werden kann. Eine originalgetreue
Darstellung der Betriebsmittelverwaltung von FATool mit Viewer und den verknüpften
Dokumenten kann im Anhang A.2 in Abbildung A.6 eingesehen werden.
Zur NC–Simulation wird allerdings ein Volumenmodell benötigt, das direkt in CREO
erstellt wird. Dazu stellt FATool die Funktion „3D–Grafik aus CAD–Masterpart erzeu2
Surface Tesselation Language bezeichnet eine Sprache zur Beschreibung von Oberflächen durch Dreiecke, die von CAD–Systemen unterstützt wird und somit als eine Standardschnittstelle angesehen
wird.
68
4.3. Schwachstellen im Ist–Zustand
gen“ bereit, sodass die eingegebenen Merkmalswerte zusammen mit einem parametrisierten Mastermodell nach CREO übergeben werden. Bevor das Volumenmodell in CREO
erzeugt werden kann, muss in Axalant ein Dokumentstamm zum zugehörigen Materialstamm angelegt werden. Dabei kann es nur einem Materialstamm zugeordnet werden,
da das Dokument zu den Merkmalswerten des Materials passen muss. Allerdings besteht
zwischen Material– und Dokumentstämmen im Allgemeinen eine n:m Beziehung, sodass
einem Material mehrere Dokumentstämme zugeordnet sein können, aber einem Dokument
auch mehrere Materialstämme wie in Abbildung 4.12 ersichtlich wird.
Abbildung 4.12.: Beziehung
zwischen
Material– und Dokumentstamm
CREO bietet hierfür die Funktion „Nach
Axalant mit Rückfrage“, sodass in
Axalant eine Maske erscheint mit der
der Dokumentstamm angelegt und einem Material zugewiesen werden kann.
Nach dem Anlegen stehen weitere durch
Axalant standardisierte Parameter zur
Verfügung, die zu dem 3D–Modell hinzugefügt werden müssen, um es mit dem
Dokumentstamm zu verknüpfen. Hierfür
sieht CREO die Funktion „Axalant Parameter zuordnen“ vor.
Das 3D–Modell ist an dieser Stelle fertig und wird in FATool mit „Speichern der 3D–Grafik
aus CAD“ zurückgeholt und damit die Schnittstelle zu CREO geschlossen. Das erzeugte
3D–Modell liegt in FATool als grafik.prt oder grafik.asm vor. Um die Merkmalswerte
nun auch nach Axalant zu übertragen, wird die interaktive Rückgabe verwendet. Dazu
setzt man den Betriebsmittelstatus in FATool auf „Warte auf Axalant Freigabe“ und die
Schnittstelle wird geöffnet. Während dieser Zeit ist FATool nicht nutzbar und in Axalant
erscheint die richtige vorausgefüllte Sachmerkmalleiste. Letzter Schritt in Axalant ist es
die Merkmalswerte zu speichern und mit „Zurück nach CAD“ die Schnittstelle zu schließen.
Diese Beschreibung stellt den normalen Prozess dar, wie er ablaufen sollte. In der Realität
wird allerdings oft nur das 3D–Modell in CREO erzeugt und wieder nach FATool zurückgeholt. Dabei wird kein Dokumentstamm in Axalant angelegt und das CAD–Dokument
steht nur in FATool zur Verfügung. Ohne dem Einchecken nach Axalant läuft dieser Prozess natürlich sehr viel schneller ab, aber andere Standorte haben keine Möglichkeit mit
diesen Dokumenten zu arbeiten und es entstehen Inkonsistenzen zwischen den Systemen.
4.3.9. Dokumentverwaltung
FATool besitzt keine eigene Dokumentverwaltung, sodass Dateien nur schwer als aktuell zu
erkennen sind und oft redundant im System vorliegen. Dies ist in der Namenskonvention
begründet, die in FATool gepflegt wird. So müssen TIF–Grafiken, die automatisch im
69
4. Ist–Zustand
Viewer angezeigt werden sollen, den Namen egrafik.tif erhalten und STL– oder PRT–
Dateien den Namen grafik.stl bzw. grafik.prt.
Wenn Dokumente in Axalant gespeichert werden, so müssen Sie einem Dokumentstamm
zugewiesen werden und bekommen automatisch eine AA–Nummer vom System. Will der
Benutzer nun die Datei aus FATool mit der aus Axalant abgleichen, so ist dies wegen
der verschiedenen Dateinamen nur bedingt möglich. Für den Benutzer ist es also schwer
nachzuvollziehen, ob im System die aktuellste Datei vorliegt.
Abbildung 4.13.: Redundanzen durch Namenskonventionen
Redundanzen liegen dann vor, wenn der Anwender aus den hinterlegten Merkmalen und
einem Mastermodell ein 3D–Modell erzeugen will, wie in Abbildung 4.13 gezeigt wird.
Das Modell wird in CREO erzeugt, wobei der Benutzer die fertige PRT–Datei in Axalant
einchecken muss. Dadurch wird automatisch ein Dokumentstamm erstellt und für diesen
eine AA–Nummer generiert. Die aus CREO eingecheckte Datei trägt die AA–Nummer als
Teil seines Dateinamen. Anschließend wird das Modell von CREO an FATool zurückgegeben und liegt ab sofort dort als grafik.prt vor. Durch die AXA2FASys Schnittstelle
wird der neu erstellte Dokumentstamm mit FATool synchronisiert und somit das bereits
existierende 3D–Modell erneut importiert, sodass es redundant vorliegt.
4.3.10. Datenleichen
Beim Anlegen von neuen Materialien in Axalant, ohne einen darauffolgenden Statuswechsel, kann es dazu kommen, dass Datensätze, die ursprünglich zwischen Axalant und FATool
synchronisiert wurden, nur noch in FATool existieren. Dies ist bei synchronisierten Datensätzen unbedingt zu vermeiden, da das System andernfalls Datenleichen enthalten kann.
Der Prozess, der zu einem solchen unerwünschten Ergebnis führt, ist in Abbildung 4.14
dargestellt. Nach dem Erstellen des neuen Materials muss man unterscheiden, ob ein Statuswechsel stattgefunden hat. Falls ein Wechsel auf „550 Freigegeben“ durchgeführt wurde,
wird das Material über die bestehende AXA2FASys Schnittstelle übertragen. Ist der Status auf „550 Freigegeben“ gesetzt, ist das unerwünschte Verhalten nicht zu beobachten,
70
4.3. Schwachstellen im Ist–Zustand
Abbildung 4.14.: Prozess zum Erzeugen von Datenleichen
da einmal freigegebene Materialstämme nicht mehr gelöscht werden können.
Findet kein Statuswechsel statt, so kann das gewünschte Material manuell nach FATool
geholt werden. Für den manuellen Import steht die Funktion „Neues Betriebsmittel aus
Axalant holen“ zur Verfügung. Durch Angabe der entsprechenden Materialnummer wird
das Betriebsmittel nach FATool importiert. Sollte es nun in Axalant gelöscht werden,
bleibt der Datensatz in FATool bestehen, da die Änderungen von der Schnittstelle wegen
des fehlenden Statuswechsels nicht berücksichtigt werden. Auch wenn dieser Fall nicht
das geplante Vorgehen darstellt, ist er zu berücksichtigen, da unvorhersehbare User–
Interaktionen zu diesem Verhalten führen können.
4.3.11. Betriebsmittelstatus
In FATool gibt es verschiedene Betriebsmittelstatus, die unter anderem angeben, ob ein
Betriebsmittel an einem Standort eingesetzt wird. Außerdem kann hier der Status zur
interaktiven Rückgabe gesetzt werden. Es gibt demnach die folgenden Status für Betriebsmittel:
• 0 Freigegeben
• 1 Im Test
• 2 Prüfen
• 5 ungeprüft
• 6 Warte auf Axalant Freigabe
• 7 Archiv
• 9 Gesperrt
In der Verwendung von Betriebsmitteln ist der Betriebsmittelstatus allerdings nicht greifend. Das heißt, selbst wenn ein Bauteil nicht auf „0 Freigegeben“ gesetzt ist, kann es
in Komplettwerkzeugen verwendet werden. Des Weiteren kann das Betriebsmittel auch
verwendet werden, wenn der Status explizit auf „9 Gesperrt“ gesetzt ist. Dies hat eine
irritierende Wirkung und führt dazu, dass der Betriebsmittelstatus durch die Anwender
schlecht gepflegt und überhaupt berücksichtigt wird.
71
4. Ist–Zustand
4.4. Zusammenfassung
In Tabelle 4.3 sind die gefunden Schwachstellen zusammenfassend dargestellt und mit
einer Kurzbeschreibung nach ihrer Priorität sortiert, die von 1 (höchste) bis 3 reicht.
`
Kurzbeschreibung
Priorität
ID Name
1 Eingeschränkte Suche Das Suchen von Betriebsmitteln ist auf
1
den eigenen Standort beschränkt.
2 Transferdaten
Die Performance des Datenbank–Link er1
schwert die Durchführung von Massenupdates.
3 Aktualisierungen
An jedem Standort müssen Änderun1
gen manuell durchgeführt werden, was zu
kurzfristigen Inkonsistenzen führt.
4 Inkonsistenz zwischen Ein manuelles Hinzufügen von Dokumen2
Dokumenten
ten, sowie das Erstellen von 3D–Modellen
ohne nachfolgendes Einchecken in das
PDM–System können Inkonsistenzen auslösen.
5 Inkonsistenz zwischen Eine Rückgabe der geänderten Merkmals2
Sachmerkmalen
werte ist nicht erforderlich, sodass die Systeme auf unterschiedlichen Ständen sind.
6 Klassenmapping
Änderungen an Klassen sind schwer fest2
zustellen und die Systeme demnach nicht
konsistent.
7 Dokumentabgleich
Veraltete Dokumente durch fehlendes Ver2
halten der Schnittstelle auf Änderungen
am Dokumentstamm zu reagieren.
8 Datenleichen
Manuell importierte Betriebsmittel wer2
den ohne zugehörigen Materialstamm als
Datenreste im System gehalten.
9 Betriebsmittelstatus
Der Betriebsmittelstatus greift nicht und
3
gesperrte Bauteile können dadurch in
KWZ verwendet werden.
10 Änderungswesen
Durchgeführte Änderungen sind ohne die
3
Protokollierung der ausgeführten Aktion
schwer nachzuvollziehen.
11 Dokumentverwaltung Durch die Namensgebung ist es schwierig
3
festzustellen, ob eine Datei aktuell ist und
es führt weiterhin zu Redundanzen.
Tabelle 4.3.: Schwachstellen im Ist–Zustand
72
5. Soll–Konzept–Szenario
In diesem Kapitel wird das bereits geplante Soll–Konzept anhand des Lastenhefts detailliert erläutert und gesondert auf Sachwachstellen eingegangen, die durch das neue
Konzept hervorgebracht werden. Offene Punkte, die das bestehende Lastenheft nicht abdeckt, werden in einem erweiterten Soll–Konzept dargelegt und mögliche Lösungswege für
die Schwachstellen des Ist– und Soll–Zustands beschrieben. In einer finalen Zusammenfassung wird überprüft, ob die gefundenen Schwachstellen durch das bestehende oder das
erweiterte Soll–Konzept beseitigt werden.
5.1. Bestehendes Soll–Konzept
Die folgenden Ideen zum Soll–Konzept sind dem Lastenheft vom 10.06.2013 entnommen
und spiegeln das geplante Vorgehen wider. Zunächst wird eine Übersicht über die Architektur gegeben und dann auf das Lastenheft eingegangen, wobei jeder Punkt beschrieben
und bewertet wird. Schließlich werden die Schwachstellen aufgezeigt, die durch das neue
Konzept entstehen.
5.1.1. Übersicht
Die Grundidee für die Architektur des Soll–Zustands besteht aus zwei getrennten FATool –
Master–Servern, wobei einer für klassische ZF–Standorte verantwortlich ist und der andere
für ZF–Lenksysteme. Dies ist erforderlich, da es zwischen ZF und ZFLS interne Konkurrenzsituationen gibt, sodass geheime Dokumente nur für die eigenen Zielsysteme sichtbar
sein dürfen. Ein anderer Punkt ist die Eigenständig von ZFLS, das heißt die Systeme von
ZFLS müssen bei einer eventuellen Trennung vom ZF–Konzern weiterhin lauffähig bleiben. Mappings und andere administrative Aufgaben werden dann nur noch auf einem der
beiden Master–Server ausgeführt, sodass alle Zielsysteme und der Master–ZFLS mit den
durchgeführten Änderungen synchronisiert werden und diese in allen Systemen konsistent
verfügbar sind.
Die lokalen Zielsysteme an den Standorten werden aus Gründen der Performanz erhalten
bleiben. In der Produktion müssen Daten schnell und zuverlässig zur Verfügung stehen,
sodass keine Leerlaufzeiten entstehen. Da es sich dabei oft um große Dateien handelt,
müssen diese komplett mit dem zentralen Master–Server abgeglichen werden. Auch wegen
den automatisch vergebenen Lizenzen muss der dezentrale, lokale Server bestehen bleiben,
73
5. Soll–Konzept–Szenario
da ein Verbindungsausfall zum Master–Server auch den Ausfall der Produktion nach sich
ziehen würde.
Das zentrale Viewing der FATool –Daten erfordert das Öffnen eines neuen FATool –Clients,
der Zugriff auf den zentralen Master–Server hat. Für den Import von gefundenen Betriebsmitteln muss weiterhin das SAP –Standortflag in Axalant wie schon im Ist–Zustand gesetzt
werden, sodass das entsprechende Material am jeweiligen Standort verfügbar wird.
Die Soll–Architektur des bereits bestehenden Konzepts ist in Abbildung 5.1 dargestellt
und wird im Folgenden detailliert beschrieben.
Abbildung 5.1.: Soll–Architektur
• Das PDM–System Axalant ist weiterhin das führende System für die Klassifizierung
und Stammdatenverwaltung, sodass neue Materialstämme nach wie vor dort angelegt werden müssen und somit konzernweit zur Verfügung stehen. Axalant selbst ist
von der Zentralisierung des FATool nicht betroffen und die Änderungen, die um das
System herum stattfinden, laufen für Axalant unsichtbar ab.
• Die Dispatcher, die bisher als zentrale Einheit fungierten, werden nun auf den
Master–ZF und Master–ZFLS verlegt. Damit sind in erster Linie die Schnittstellentabellen und der Master–Service betroffen, inklusiver ihrer PL/SQL Prozeduren
und Funktionen. Die Verteilung der Daten auf die Master–Server läuft ebenfalls über
die gesetzten SAP –Standorte. Während der Master–ZF für alle ZF internen Standorte verantwortlich ist, was mit den SAP –Standort Kürzeln FP, PP, .. verdeutlicht
74
5.1. Bestehendes Soll–Konzept
wird und zusammenfassend mit ZFGRP1 beschrieben wird, ist der Master–ZFLS
für alle Daten mit dem SAP –Standort GP1 verantwortlich, was mit ZFLS bezeichnet wird. Die beiden Master–Server beinhalten weitestgehend unterschiedliche
Daten. Nur Datensätze denen sowohl ZFGRP als auch ZFLS als Standorteintrag
zugewiesen ist, sind auf beiden verfügbar.
Neben dem Master–Service läuft auch der Client–Service am Master–ZF, der das
Master–FATool –Zielsystem mit Daten versorgt. Dieses Master–System wird ferner
als „zentrales FATool“ bezeichnet. Der eigentliche Aktualisierungsprozess über den
Dispatcher bleibt somit unverändert, mit dem Unterschied dass anstelle der standortspezifischen FATool –Systeme nun der Master–ZF und Master–ZFLS synchronisiert werden, die die Daten standortübergreifend verwalten. Die Administration des
Dispatchers für ZFGRP unterliegt weiterhin der Abteilung FIDA5 in Passau.
• Die Master–Server enthalten also einen Master– und einen Client–Service, um ihr
FATool –System – das zentrale FATool – mit Daten zu versorgen. Sie sind allerdings auch verantwortlich für die Verteilung der Daten an die standortspezifischen
FATool –Zielsysteme. Dazu muss ein weiterer Master–Service betrieben werden, der
allerdings abgeändert wird, da die Schnittstelle des neuen Konzepts zwischen den
Master–Servern und ihren dezentralen Zielsystemen eine bidirektionale Kommunikation vorsieht. Dies ist erforderlich, da zusätzliche Informationen, die von Axalant
nicht verarbeitet werden können, trotzdem zentral zur Verfügung stehen sollen.
Durch die „interaktive Rückgabe“ über Axalant würden diese Informationen verloren gehen und wären für andere Standorte nicht zugänglich. Dabei handelt es
sich um Mehrschneidensysteme für die in Axalant nur ein Stammsatz mit nur einer Schneide existiert, in FATool jedoch flexibel verschiedene Schneiden zugeordnet
werden können. Aber auch Benutzerdaten oder 3D–Modelle werden direkt von den
standortspezifischen Systemen an den Master zurückgegeben.
• Die dezentralen Server der einzelnen Standorte bleiben natürlich trotz des zentralen
Master–Servers erhalten, da Fertigungsdaten immer standortabhängig sind. Auch
in Anbetracht der Produktion müssen die Server für die Standorte lokal zur Verfügung stehen, denn ein Verbindungsausfall zum Master–Server könnte einen Produktionsstopp nach sich ziehen. Auf den lokalen Servern der Standorte läuft ein,
hinsichtlich der bidirektionalen Schnittstelle, abgeänderter Client–Service, der beim
Master–Server nach für ihn relevanten Daten anfragt. Die Verteilung erfolgt auch
hier weiterhin anhand der SAP –Standorte, sodass die lokalen Zielsysteme immer
eine Teilmenge an Daten des Master–Systems enthalten.
• Die jeweiligen FATool –Zielsysteme werden durch den zuständigen Divisionsstandort
administriert. Für die Industrietechnik (I–Division) ist Passau der Divisionsstandort
und verwaltet somit auch Gainesville. Die „interaktive Rückgabe“ bleibt erhalten,
um Änderungen mit Axalant abzugleichen. Zusätzlich kommt die Möglichkeit zum
1
Standorte können zu Gruppen zusammengefasst werden, sodass alle klassischen ZF–Standorte mit
ZFGRP bezeichnet werden und ZF–Lenksysteme mit ZFLS. ZFGRP bezeichnet dabei alle Bereiche
außer LS und Standorte in China.
75
5. Soll–Konzept–Szenario
„Viewen der zentralen Master–Daten“ hinzu. Dies bedeutet für den Endanwender,
dass er einen zusätzlichen FATool –Client öffnet, der auf die Daten des Master–ZF
zugreift und somit standortunabhängig alle Daten einsehen kann.
• Der Master–ZF Server wird vom Master–ZFLS mit Daten aus dem Bereich ZF–
Lenksysteme versorgt. Hierbei muss jedoch zwischen den Änderungshoheiten unterschieden werden. Während alle Datensätze am Master–ZFLS als Standort ZFLS
beinhalten, gibt es einige mit der spezifischen Änderungshoheit 4320. Das bedeutet,
dass diese Datensätze nur für ZFLS sichtbar sind und somit nicht mit dem Master–
ZF abgeglichen werden dürfen. Damit beinhaltet der Master–ZF Daten von ZFGRP
und ZFLS, sodass ZFLS Endanwender auch ihre eigenen Daten beim Viewing am
Master–Server zur Verfügung haben.
• Durch das Viewen von Daten anderer Standorte, können Betriebsmittel leichter gefunden und in das eigene FATool –Zielsystem importiert werden. Dies geschieht, wie
bereits beschrieben, durch das Setzen des SAP –Standorts am Materialstamm in
Axalant, sodass die AXA2FASys Schnittstelle die Daten mit dem eben hinzugefügten FATool –System synchronisiert. Dies gilt auch für ZFLS Benutzer, die jedoch
einen eigenen Master–Server haben, der ihr Zielsystem abgleicht. Sollen nun Daten
synchronisiert werden, die Mehrinformationen beinhalten, solche die also nur von
FATool verwaltet werden können (z.B. Mehrschneidensysteme), muss der Abgleich
zwischen den beiden FATool –Master–Servern möglich sein, da in Axalant diese Informationen nicht verfügbar sind. Der Abgleich von gemeinsamen FATool –Daten
findet also direkt zwischen den Master–Servern statt.
• Bei Änderungen an Mappings von Klassendefinitionen müssen diese in Zukunft nur
noch an einem System durchgeführt werden. Neben den Zielsystemen der ZFGRP,
wird auch der Master–ZFLS mit geänderten Mappings synchronisiert, die nur einer Änderung am Master–ZF bedürfen, um alle FATool –Systeme einheitlich und
konsistent zu halten.
• Das Viewing der zentralen Master–Daten findet auch für ZFLS–Anwender auf dem
Master–ZF Server statt, denn der Master–ZFLS beinhaltet nur Daten, die äquivalent
mit dem ihres lokalen FATool –Zielsystems sind und somit der Vorteil zur Suche von
Betriebsmitteln anderer Standorte zunichte wäre. Natürlich muss für das Viewing
somit ein erweitertes Sichtenkonzept eingeführt werden, da es innerhalb der ZF
interne Konkurrenten gibt, die Daten der jeweils anderen Standorte nicht einsehen
dürfen. Diese Regelung besteht nicht nur zwischen ZFGRP und ZFLS, sondern auch
zwischen Standorten innerhalb von ZFGRP, sodass das Sichtenkonzept ausreichend
feingranular aufgebaut werden muss.
76
5.1. Bestehendes Soll–Konzept
5.1.2. Lastenheft
Im Folgenden werden die Punkte des Lastenhefts zitiert, die in Relation mit dieser Arbeit
stehen. Zu jedem Punkt werden zusätzliche Informationen mit detaillierter Beschreibung
gestellt, damit die Anforderungen für den Leser verständlich werden. Falls Punkte fehlerhaft oder widersprüchlich beschrieben sind, wird in einer Anmerkung die Aussage richtig
gestellt. Falls Punkte etwaige Schwachstellen enthalten, werden sie als solche markiert
und im erweiterten Soll–Konzept mögliche Lösungswege vorgestellt. Konzepte, die FATool spezifisch sind und keine Verbindung zu den behandelten Themen dieser Arbeit
aufweisen, werden in dieser Arbeit nicht berücksichtigt. Dies betrifft die Punkte „Konzept für Software–Releasewechsel“ und „Konzept für dezentrale Funktionserweiterungen
je Standort“, sowie „Analyse der bestehenden Schnittstellen von FATool zu anderen IT–
Systemen an den beteiligten Standorten“. Als Schnittstelle zu anderen IT–Systemen wird
lediglich die Verbindung zu Axalant berücksichtigt.
Berechtigungskonzept
• „Die Sichtbarkeit der Daten aus dem PDM–System muss innerhalb der
PDM2FATool–Schnittstelle realisiert werden.“
Die Schnittstelle zwischen Axalant und FATool berücksichtigt bereits die Änderungshoheit des Fertigungshilfsmittels bei der Übertragung. Bisher dient die
Änderungshoheit in FATool rein informativen Zwecken und stellt keine funktionalen
Eingriffe dar. Die Schnittstelle muss dahingehend erweitert werden, dass auch
die Änderungshoheit des aktuell angemeldeten Benutzers verwendet und mit der
des Fertigungshilfsmittels abgeglichen wird, um über die Sichtbarkeit von Daten
entscheiden zu können. Das geplante Vorgehen für die Übertragung von Daten über
die Schnittstelle ist zunächst, dass nur Daten übertragen werden, die von allen
Standorten gesichtet werden dürfen.
Schwachstelle Da auch im FDO–Bereich Datensätze existieren, die nur für bestimmte Standorte sichtbar sein sollen, reicht es nicht aus sensible Datensätze in
der Schnittstelle zu filtern. Daher müssen die entsprechenden Berechtigungskonzepte aus Axalant nach FATool portiert werden. Dabei ist zu unterscheiden, ob die
Sichtbarkeit die Meta–Daten, die verknüpften Dateien oder beides betrifft.
• „Anwenderbezogene Änderungshoheit aus PDM–System muss in FATool zur Verfügung gestellt werden.“
In Axalant können einem Benutzer mehrere Änderungshoheiten zugewiesen
sein, wobei jeder Benutzer in der Regel eine seinem Standort entsprechende
Standard–Änderungshoheit besitzt. Diese wird unter anderem beim Anlegen von
neuen Datensätzen verwendet, da jedes Objekt eine eindeutige Änderungshoheit
besitzen muss. Um die anwenderbezogene Änderungshoheit in FATool umzusetzen,
muss zusätzlich der Zugriffstyp auf Datensätze, dem die Attribute „Lesen“, „Schrei-
77
5. Soll–Konzept–Szenario
ben“ und „Löschen“ sowie eine explizite Gültigkeit zugeordnet werden können,
synchronisiert werden. Da die Menge an Benutzern in FATool nur eine Teilmenge
der Benutzer in Axalant darstellt, können diese anwenderbezogenen Berechtigungen
stündlich aktualisiert und gemappt werden.
Schwachstelle Bei diesem Punkt wird davon ausgegangen, dass die anwenderbezogene Änderungshoheit als Berechtigungskonzept in FATool ausreichend ist. Dies
muss zunächst einer Prüfung unterzogen werden. Unterschiedliche Benutzerverwaltungen für die verschiedenen Systeme würde einen enormen Overhead bedeuten,
sodass ein Mapping der entsprechenden Benutzerrechte aus Axalant erstellt werden
muss. Welche Berechtigungen portiert werden müssen, wird durch Aufstellen der
Anforderungen ermittelt.
• „Das im FATool bestehende Berechtigungskonzept zur Administration der FATool–
Konfiguration muss verfeinert werden. Die Administratoren von FATool–Master
müssen auf allen FATool-Zielsystemen angelegt werden.“
Den Administratoren der zentralen Server muss es erlaubt sein, sich auch auf
die dezentralen Zielsysteme einzuloggen, um dort Anpassungen vornehmen zu
können. Auf standortspezifische Tabellen sollten allerdings nur die jeweiligen
Standortadministratoren Zugriff haben. Ihnen soll es außerdem erlaubt sein,
zentral User anzulegen. Allerdings sollten sie keinen Zugriff auf die zentralen
Mapping–Tabellen erhalten. Administrative Aufgaben, die den eigenen Standort
betreffen, sollen durchführbar bleiben. Änderungen, die alle Zielsysteme betreffen,
dürfen nur von zentralen Administratoren durchgeführt werden.
Anmerkung Diese Anpassung ist außerhalb des Berechtigungskonzepts von
Axalant durchzuführen und mit verschiedenen User–Rollen innerhalb von FATool
umzusetzen. Die User–Rollen aus Axalant müssen dennoch berücksichtigt werden,
sodass Änderungen nur an zulässigen Betriebsmitteln durchgeführt werden können.
Integration der FATool–Installation bei ZFLS
• „Systemtechnische Abbildung mit einem separaten Mastersystem ZFLS erforderlich.“
Wegen der Eigenständigkeit von ZFLS muss ein eigenständiges Mastersystem
eingeführt werden, sodass ZFLS bei einer möglichen Abspaltung vom restlichen
ZF–Konzern weiterhin autonom arbeiten kann. Eine Abbildung des Master–ZF
betrifft dabei allerdings nur Konfigurationsdaten wie Klassendefinitionen, die auf
dem administrativen Master–ZF gepflegt und auf Master–ZFLS abgebildet werden.
Die eigentlichen Nutzdaten werden nicht vollständig zwischen den Systemen
synchronisiert, da es auf beiden Seiten geheime Dokumente gibt, die für die jeweils
andere Seite nicht sichtbar sein sollen.
78
5.1. Bestehendes Soll–Konzept
• „ZF-Lenksysteme behält ihre eigenständige FATool Infrastruktur bei.“
Bereits im Ist–Zustand wurde der Dispatcher für ZFGRP und ZFLS separat
betrieben. Im Soll–Zustand ist es ebenfalls so geplant, mit dem Unterschied, dass
nun zunächst der zentrale Master–ZFLS mit den Daten synchronisiert wird und
erst dann die Daten an das momentan einzige FATool –Zielsystem innerhalb ZFLS
weitergereicht werden.
Schwachstelle Durch die Eigenständigkeit und die getrennten Dispatcher ist ZFLS
selbst zuständig für die Verteilung der Daten. Durch diese Selbstregulierung ist es
theoretisch möglich, dass ZFLS auch Daten nach Master–ZFLS importiert, die nicht
für ZF–Lenksysteme vorgesehen sind. Hierzu müssen in der jeweiligen Schnittstellenfunktion die gewünschten SAP –Standorte eingetragen werden. Dieses Vorgehen
kann nicht unbemerkt bleiben, da die Datensätze im eigentlichen Zielsystem fehlen
werden. Es sollte aber dennoch als Schwachstelle erwähnt werden.
• „Die FATool–Daten aus LS werden durch FASys bei Anlage und Änderung an den
ZF–Konzern zentralen Master repliziert. Dabei ist das Berechtigungskonzept aus
Axalant (Änderungshoheit, Sichtbarkeit an Standorten) zu berücksichtigen.“
Ein Abgleich zwischen den Servern Master–ZF und Master–ZFLS ist grundsätzlich möglich, wobei Daten von ZFLS nur dann repliziert werden, falls ihre
Änderungshoheit nicht 4320 ist. Darüber hinaus gibt es auch Datensätze, die
virtuelle Standorte als Eintrag haben und somit erst gar nicht repliziert werden
dürfen. Auch lesebeschränkte Daten sollen übertragen werden, allerdings sollen
dabei nur die Meta–Daten zur Verfügung stehen. Die beiden Master–Systeme
sind daher in ihrem Datenbestand relativ unterschiedlich. Gemeinsame Daten
kommen nur durch die Replikation von ZFLS nach ZF zustande, wenn ZFGRP und
ZFLS als Standorte eingetragen sind oder wenn Datensätze nach ZFLS importiert
werden, die Mehrinformationen aus FATool beinhalten und direkt zwischen den
Master–Servern abgeglichen werden.
• „Für die LS–Anwender soll die Möglichkeit bestehen, die Daten im FATool–Master–
ZF per Viewer anzusehen. Werden solche Teile bei ZFLS gebraucht, wird über einen
SAP–Standort–Eintrag im PDM–System das Teil auch in das Mastersystem von
ZFLS übertragen.“
Dadurch, dass ZFLS–Anwender auch Daten am zentralen Master–ZF viewen
können, müssen erweiterte Berechtigungskonzepte umgesetzt werden, da am
Master–ZF Datensätze existieren, die für ZFLS nicht sichtbar sein dürfen. Hierzu
wird einerseits die Berechtigung des Users und andererseits die des Standorts
überprüft, der durch die Schnittstelle über Axalant zur Verfügung gestellt wird. Der
Standorteintrag in Axalant muss manuell durchgeführt werden und setzt ebenfalls
die entsprechenden Berechtigungen in Axalant voraus.
79
5. Soll–Konzept–Szenario
• „Der FATool–Master–ZF sollte alle FATool–Daten von ZF und ZFLS beinhalten.“
Da die Konfigurationsdaten ausschließlich am Master–ZF gepflegt werden,
muss es sich bei diesem Punkt um die Nutzdaten handeln, die von Master–ZFLS
nach Master–ZF übertragen werden. Da hier von allen FATool –Daten die Rede ist,
müsste der Master–ZF den Master–ZFLS komplett beinhalten, was allerdings nicht
der Fall ist, wie in Abbildung 5.2 zu sehen ist.
4320 ZFLS ohne 4320 ZFLS ohne 4320 Master ZFLS ..... Dielingen Padua Gainesville Passau Master ZF Abbildung 5.2.: Datenüberschneidung zwischen ZF und ZFLS
Anmerkung Die beiden Systeme besitzen maximal eine gemeinsame Schnittmenge,
die nur die Daten betrifft deren Änderungshoheit ungleich zu 4320 ist. Des Weiteren
finden sich auch manuell nach Master–ZFLS importierte Daten in der Schnittmenge
wieder, die in beiden Systemen verfügbar sind und ein Austausch über Zusatzinformationen stattgefunden hat. Alle Datensätze mit Änderungshoheit 4320 sind nur
für ZFLS bestimmt und werden nicht mit Master–ZF repliziert.
• „Einheitliche Klassifizierungs– und Mapping–Tabellen werden auf dem FATool–
Master–ZF gepflegt, sodass beide Master auf dieselbe Basis zurückgreifen können. “
Die administrativen Aufgaben, wie das Anpassen von Mappings und Klassendefinitionen, müssen nur noch auf dem Master–ZF durchgeführt werden. Der
Master–ZFLS wird direkt synchronisiert und alle FATool –Zielsysteme sind mit nur
einer Anpassung aktuell und konsistent.
80
5.1. Bestehendes Soll–Konzept
Zentrales Mapping der PDM–SML–Felder
• „Der Ausgangspunkt für die FHM–Übertragung nach FATool sind die PDM–
Klassen.“
Der Austausch von Fertigungshilfsmitteln zwischen Axalant und FATool basiert auf den zugrunde liegenden Klassen aus Axalant. Jedes Fertigungshilfsmittel
wird einer Klasse in FATool zugeordnet, wofür zunächst ein Klassenmapping erstellt
werden muss. Nur durch die richtige Zuordnung von Quell– und Zielleiste kann ein
Import durchgeführt werden.
• „Die benötigten Klassen je FATool–Zielsystem können nach entsprechender Abstimmung standortspezifisch festgelegt werden. Dies wird auf FATool–Master–ZF
definiert und dann auf FATool–Master–ZFLS repliziert.“
Angenommen ein bestimmter Standort benötigt eine spezielle Klasse aus Axalant
in seinem Zielsystem, dann läuft die Verteilung über Master–ZF, wobei die
Klasse nur an den speziellen Standort ausgeliefert wird. Trotzdem bleibt sie am
zentralen Master–Server verfügbar. Solche Klassenmappings werden ausnahmslos
am Master–ZF gepflegt und auf den Master–ZFLS repliziert.
Schwachstelle Wenn seitens ZFLS eine neue Klasse und damit auch ein neues Klassenmapping gebraucht wird, so kann dies am zentralen Master–ZFLS nicht durchgeführt werden, da Klassenmappings nur am Master–ZF definiert werden. Es fehlt
eine Lösung wie ZFLS auch Klassenmappings verwalten und neu anlegen kann.
• „Die betroffenen FATool–Leistendefinitionen (Sachmerkmale, Leisten und Bilder)
werden auf die FATool–Zielsysteme sowie auch FATool–Master–ZFLS verteilt.“
Die einzige zu pflegende, zentrale Einheit stellt der Master–ZF dar, der FATool –Daten sowohl an die Zielsysteme, als auch an Master–ZFLS verteilt. Dadurch
wird der Aufwand bei Anpassungen an Konfigurationsdaten minimiert und kann
schnell und konsistent an alle anderen FATool –Installationen verteilt werden.
• „In FATool–Master gibt es ein einheitliches zentrales Klassenmapping.“
Das einheitliche zentrale Klassenmapping erhält die Konsistenz zwischen den
Systemen. Das Mapping ist somit für alle Standorte gleichermaßen bindend und
kann nur zentral verändert werden, jedoch nicht standortspezifisch.
• „FATool interne Leisten werden beim Releasewechsel zentral über FATool–Master
aktualisiert. Die Verantwortung liegt hier bei der Firma FASys.“
Bei Einführung des zentralen Systems muss ebenfalls ein Releasewechsel der
FATool –Applikation durchgeführt werden, der das neue Konzept unterstützt. Falls
sich somit Änderungen an Konfigurationsdaten ergeben, muss zukünftig kein Patch
mehr verteilt werden, sondern es werden die internen Leisten am Master–ZF
81
5. Soll–Konzept–Szenario
angepasst und auf die Zielsysteme repliziert.
• „Die Aktualisierung der standortspezifischen Leisten unterliegt der Verantwortung
des jeweiligen Standortes.“
Unter standortspezifischen Leisten versteht man diejenigen Daten, die so speziell auf einen Standort zugeschnitten sind, dass sie nicht zentral gepflegt werden
können. Dies ist bei der NC–Programmverwaltung der Fall, denn jeder Standort hat
verschiedene DNC–Maschinen im Einsatz, sodass dieses Modul nicht standortübergreifend verwaltet werden kann. So besitzt jeder Standort am zentralen Master–ZF
eine eigene standortspezifische Leiste, die die lokalen Daten enthält (z.B. ncpv_pas
für Passau, ncpv_pdv für Padova). So werden standortabhängige Daten auch für
andere Standorte einsehbar, wobei die Verteilung dezentral durchgeführt wird.
Das zentrale Sichten dieser Daten ist mit der Vorreiterrolle in der Produktion
begründet, die manche Standorte einnehmen und somit zukünftig für andere
Standorte relevant werden.
Schwachstelle Es ist nicht geklärt, ob Änderungen an standortspezifischen Leisten
am Master–ZF oder am lokalen Zielsystem durchzuführen sind.
• „Zusammenführung der vorhandenen Systeme in ein Mastersystem.“
Da die geplante Schnittstelle zwischen den FATool –Zielsystemen und den
Master–Servern bidirektional sein wird, soll diese genutzt werden, um die Daten
von den Zielsystemen auf den jeweiligen Master–Server zu replizieren. Die Urladung
des Master–Systems kommt also von den Zielsystemen selbst.
Schwachstelle Beim derartigen Zusammenführen von Daten kann es zu Konflikten
kommen, die durch gemeinsam genutzte Datensätze mit unterschiedlichen Merkmalswerten zwischen den verschiedenen Standorten entstehen. Hier sind geeignete
Maßnahmen zur Konfliktlösung zu entwickeln.
Neue Funktionalitäten
• „Viewing der zentralen Daten auf dem FATool–Master ZF muss möglich sein.“
Das Sichten der zentralen Daten wird durch einen Terminal–Server ermöglicht. Das zentrale FATool ist somit eine einmalig, zentral installierte Anwendung,
die über leistungsfähige WAN–Leitungen von mehreren lokalen Benutzern verwendet wird. Der Terminal–Server bietet dabei nur Zugriff auf die Applikation selbst,
sodass ein Benutzer eingeschränkte Rechte auf dem jeweiligen Server besitzt. Das
zentrale FATool ist eine eigene Applikation und läuft unabhängig vom lokalen
FATool. Anwender können so parallel im lokalen und im zentralen System suchen.
82
5.1. Bestehendes Soll–Konzept
• „Datenabgleich“
„Automatischer
Zielsystemen.“
Abgleich
zwischen
den
FATool–Master
und
FATool–
„Abgleich zwischen FATool–Master ZF und FATool–Master ZFLS.“
„Komplettwerkzeuge mit allen Schneiden müssen in die FATool–Zielsysteme
übertragen werden.“
Der Abgleich von Daten zwischen dem Master–ZF und den lokalen Zielsystemen
muss in beide Richtungen automatisch funktionieren. Der Grund für die Bidirektionalität liegt in den Zusatzinformationen, die nur von FATool gespeichert werden,
nicht jedoch von Axalant und somit direkt zwischen dem lokalen und dem zentralen Server ausgetauscht werden. Die Zusatzinformationen und das Klassenmapping sowie gemeinsam genutzte Datensätze machen einen Abgleich zwischen dem
Master–ZF und dem Master–ZFLS erforderlich. Komplettwerkzeuge mit mehreren
Schneiden können somit in jedes beliebige Zielsystem übertragen werden, ohne dass
Daten zwischen den Systemen verloren gehen.
• „Im FATool–Zielsystem muss es möglich sein, vom FATool–Master einen bestehenden Datensatz zu kopieren.“
Diese Funktion wird immer dann benötigt, wenn es sich um Datensätze mit
zusätzlichen Informationen handelt. Wird ein passendes Fertigungshilfsmittel im
zentralen System gefunden, so wird es durch das Eintragen des eigenen SAP –
Standorts in Axalant an das eigene FATool –Zielsystem übermittelt. Dabei bleiben
die Informationen, die von Axalant nicht gespeichert werden können, auf der
Strecke. Um diese Informationen dennoch zur Verfügung zu stellen, muss es eine
Funktion geben, die es erlaubt komplette Datensätze aus dem Mastersystem zu
kopieren.
Abbildung 5.3.: Übertragen zusätzlicher Informationen zwischen den zentralen Systemen
83
5. Soll–Konzept–Szenario
In Abbildung 5.3 ist dieses Szenario dargestellt, das mit dem Viewing der zentralen
Master–Daten beginnt. Ist ein passendes Betriebsmittel gefunden, so wird in Axalant
entweder der entsprechende SAP –Standort eingetragen oder, falls Änderungen am
Material notwendig sind, der komplette Datensatz kopiert. Im nächsten Schritt wird
dieser Datensatz durch die AXA2FASys Schnittstelle in das lokale Zielsystem übertragen. In beiden Fällen fehlen jedoch die Zusatzinformationen aus FATool. Hierzu
soll es nun eine Funktion geben, um die zusätzlichen Informationen für einen Datensatz von Master–ZF abrufen und replizieren zu können.
• „Produktverlagerungen“
„Es muss möglich sein ein NC–Programm samt Quellsourcen von einem
FATool–Zielsystem über den FATool–Master auf ein anderes FATool–Zielsystem
zu replizieren.“
Da in Axalant keine NC–Programme verwaltet werden, greift hier das Verteilungskonzept über die SAP –Standorte nicht. Obwohl die NC–Daten grundsätzlich standortabhängig sind, muss die Verlagerung von produktionsrelevanten Daten möglich
sein. Wenn ein Standort nicht genügend Kapazitäten zur Produktion hat, so können andere Standorte mit freien Kapazitäten einen Teil der Produktion übernehmen. Voraussetzung für ein erfolgreiches Verlagern der Produktion sind natürlich
kompatible Maschinen in der Fertigung. Deshalb braucht man Funktionen, die das
Replizieren von NC–Programmen zwischen den Zielsystemen ermöglichen.
84
5.1. Bestehendes Soll–Konzept
5.1.3. Schwachstellen
Im Folgenden werden die Schwachstellen, die im Lastenheft identifiziert werden konnten,
herausgestellt und genauer erklärt.
5.1.3.1. Selbstkontrolle
ZF–Lenksysteme übernimmt die Verteilung der für sie bestimmten Daten selbst. Hierfür
verwalten sie ihren eigenen Dispatcher, der aus der Auftragstabelle in Axalant alle Einträge mit dem Standortflag „GP1“ selektiert und die Daten an das bisher einzige Zielsystem
an Master–ZFLS weiterleitet. ZFLS besitzt eine eigene Schnittstelle nach Axalant, da
es als Joint-Venture flexibel bleiben und auch bei einer möglichen Abspaltung weiterhin
funktionieren muss. Doch die Schnittstelle wird auch selbst von ZFLS verwaltet und kann
somit manipuliert werden. Durch das Hinzufügen oder Abändern von Standorteinträgen
in den PL/SQL Funktionen können auch Datensätze, die für andere Standorte bestimmt
sind, abgegriffen werden. Es bekommt das System den Vorzug, das die Auftragstabelle
schneller abarbeitet. Im anderen System fehlt dieser Datensatz, da ein quittierter Eintrag
als abgearbeitet gilt. In Abbildung 5.4 ist eine manipulierte Schnittstelle dargestellt, die
eine fehlerhafte Verteilung der Daten erlaubt.
Abbildung 5.4.: Fehlerhafte Verteilung durch manipulierte Schnittstelle
Die Schnittstelle wurde dahingehend abgeändert, dass zwischen Axalant und Master–
ZFLS fälschlicherweise Daten synchronisiert werden, die für Master–ZF bestimmt wären.
Angenommen Master–ZFLS arbeitet die Auftragstabelle zum Datenexport schneller ab
als Master–ZF, dann würde ein Datensatz, der eigentlich für Passau bestimmt wäre, nach
Schwäbisch–Gmünd transferiert werden. Gleichzeitig würde dieser Datensatz im Passauer
System fehlen, was dieses Vorgehen sicherlich schnell aufdecken würde.
85
5. Soll–Konzept–Szenario
5.1.3.2. Berechtigungskonzept
Die Änderungshoheit als einziges Berechtigungskonzept nach FATool zu portieren, um die
Sichtbarkeit von Stammdatensätzen zu regulieren, kann in manchen Situationen nicht ausreichend sein. Da es weiterhin vertrauliche Daten gibt, die nicht nur zwischen ZF und ZFLS
zu verbergen sind, sondern auch zwischen bestimmten Standorten innerhalb ZFGRP, müssen explizit die Änderungshoheiten der betroffenen Stammdatensätze gesperrt werden.
Das Filtern der gesperrten Änderungshoheiten wird durch die AXA2FAsys Schnittstelle
übernommen. Dies hat allerdings den Nachteil, dass diese Daten auch für den berechtigten
Standort nicht mehr verfügbar sind, da sie bereits in der Schnittstelle verworfen werden.
Des Weiteren zieht dieses Vorgehen einen enormen organisatorischen Aufwand nach sich,
der vor allem bei zukünftigen Änderungen ständig aktuell gehalten werden muss. Doch
Änderungen in Axalant sind schwer feststellbar, sodass an dieser Stelle Inkonsistenzen
vorprogrammiert sind.
Ein anderer Ansatz ist, dass bereits die Schnittstelle die virtuellen Standorte auswertet,
die in Axalant verwendet werden, um die Sichtbarkeit auf bestimmte Standorte einzugrenzen. Hat ein Datensatz nur Passau als virtuellen Standort eingetragen, so sind diese Daten
für andere Standorte gar nicht erst existent. In der Schnittstelle zwischen Axalant und
Master–ZF wird nun überprüft, ob der zu übertragende Datensatz als Standort ZFGRP
besitzt und somit für alle klassischen Standorte sichtbar sein darf. Datensätze ungleich
ZFGRP werden durch die Schnittstelle ausgefiltert. Entsprechend werden für ZFLS Datensätze verworfen, die als Standorte ungleich ZFLS sind. Da es für ZFLS nur ein FATool –
Zielsystem gibt, sind die fehlenden Datensätze nicht so umfangreich wie es bei ZFGRP
der Fall sein wird.
In Abbildung 5.5 ist die Filterung bezüglich der virtuellen Standorte durch
die Schnittstelle dargestellt. Der Datensatz mit dem Standorteintrag Passau
wird somit von der Schnittstelle verworfen und ist keinem Standort zugänglich, selbst der befugte hat keinen Zugriff. Obwohl der organisatorische Aufwand somit eingegrenzt wird, bleibt das
Problem, dass auch befugte Standorte
auf ihre geheimen Daten keinen Zugriff haben, bestehen. Das direkte Filtern spricht für die Sicherheit der Daten, grenzt allerdings die Verfügbarkeit
dieser stark ein, sodass auch dieses Konzept keine ideale Lösung bietet.
Abbildung 5.5.: Filterung
stelle
durch
Schnitt-
Ein weiteres Problem der Änderungshoheit ist seine Position im Berechtigungsmodell
von Axalant. Die virtuellen Standorte, die speziell die Sichtbarkeit der Daten in Axalant
86
5.1. Bestehendes Soll–Konzept
regeln, sind der Änderungshoheit übergeordnet. Angenommen ein Anwender besitzt viele verschiedene Änderungshoheiten und das Konzept der virtuellen Standorte wird von
der Schnittstelle nicht berücksichtigt, dann wäre es möglich, dass dieser Benutzer mit
Stammdaten arbeiten kann, obwohl sie für seinen Standort gar nicht sichtbar wären. Im
Umkehrschluss könnten Benutzer mit wenigen Änderungshoheiten auch entsprechend weniger Daten einsehen, was die Produktivität des Systems stark einschränkt. Somit ist es
unumgänglich, dass die Schnittstelle die virtuellen Standorte unterstützt und zur Verfügung stellt. Die Verwendung der virtuellen Standorte in FATool wird daher als empfehlenswert angesehen.
5.1.3.3. Standortspezifische Änderungen
Durch das Lastenheft wird nicht geklärt an welcher Stelle standortspezifische Änderungen
durchzuführen sind. Im Allgemeinen sind zwei verschiedene Szenarien denkbar, wobei
die Änderungen entweder am zentralen Master–Server – Master–ZF bzw. Master–ZFLS
– durchgeführt werden und die Änderungen an das Zielsystem repliziert werden, oder
alternativ die Änderungen direkt am Zielsystem durchgeführt werden und anschließend
mit dem Master–Server abgeglichen werden.
Abbildung 5.6.: Mögliche standortspezifische Anpassungen
In Abbildung 5.6 sind die verschiedenen Möglichkeiten aufgezeigt, wobei Änderungen am
lokalen Server durch blaue Kanten und Änderungen am zentralen Server durch rote Kanten dargestellt werden. Im Falle von ZFLS ist ein weiteres Szenario denkbar, das als grüne
Kante dargestellt wird und Änderungen am Master–ZF vorsieht. Diese werden synchronisiert bis sie schließlich ebenfalls im Zielsystem vorhanden sind. Durch das Lastenheft wird
jedoch nicht geklärt, ob standortspezifische Leisten zwischen den Master–Servern repliziert werden und an welchen Stellen Änderungen vorgesehen werden, was dieses Vorgehen
ebenfalls relevant macht.
87
5. Soll–Konzept–Szenario
5.1.3.4. Datenmigration
Die Master–Server sollen durch die mit ihnen verbundenen Zielsysteme in einen Initialzustand gebracht werden, um die Anforderung zu erfüllen, dass sie die Daten aller angebundenen Systeme enthalten. Hierfür wird die bidirektionale Schnittstelle verwendet, die es
erlaubt Daten vom Zielsystem auf den zentralen Master zu replizieren. Verwenden jedoch
mehrere Standorte die gleichen Stammdaten kann es zu Konflikten kommen. Diese treten
immer dann auf, wenn gleiche Datensätze verschiedene Merkmalswerte aufweisen, was bisher in FATool möglich war. Durch diese Änderungen müssen Szenarien zur Konfliktlösung
entwickelt werden.
Abbildung 5.7.: Konflikt bei der Datenmigration
Wie in Abbildung 5.7 verdeutlicht, können die verschiedenen
Standorte innerhalb eines Materialstamms und desselben Merkmals
verschiedene Werte aufweisen. Da
der Master–ZF nur einen, für alle Standorte übergreifenden Datensatz speichern wird, muss er
entscheiden welcher Merkmalswert
übernommen wird. Bei Master–
ZFLS tritt dieses Problem nicht auf,
da bisher nur ein Zielsystem verknüpft ist und somit keine Konflikte
entstehen können.
Bei dieser Art der Datenmigration werden zwar die Mehrinformationen aus FATool berücksichtigt, wichtige Informationen aus Axalant zur Umsetzung des Berechtigungskonzepts fehlen jedoch. So muss ein Konzept zur Datenmigration entwickelt werden, das beide
Systeme unterstützt und die gewünschten Informationen im Master–Server bereitstellt.
5.1.3.5. Klassenmapping durch ZFLS
Auch für ZF–Lenksysteme muss die Möglichkeit bestehen Änderungen an Klassenmappings durchzuführen oder bei Bedarf neue anzulegen. Da alle Mappings und Klassendefinitionen ausschließlich auf Master–ZF gepflegt werden, muss Anwendern von ZFLS Zugriff
auf den administrativen Bereich von Master–ZF gewährt werden.
Da im Moment noch keine User–Rollen innerhalb von FATool entwickelt wurden, ist es
schwierig abzuschätzen welche Auswirkungen und Risiken ein administrativer Eingriff in
den Master–ZF seitens ZFLS birgt. Generell gilt jedoch, dass ein direkter Zugriff auf die
zentrale Applikation ein Sicherheitsrisiko darstellt, da somit auch alle ZF–Standorte aus
ZFGRP in ihren Konfigurationen geändert werden können.
88
5.1. Bestehendes Soll–Konzept
5.1.4. Bewertung
Im Folgenden wird validiert, ob die Anforderungen und Schwachstellen des Ist–Zustands
mit dem bestehenden Soll–Konzept gelöst werden können. In Tabelle 5.1 sind erneut alle
Schwachstellen aus dem Ist–Zustand nach ihrer Priorität sortiert und es wird angegeben,
ob diese durch die Anforderungen im Lastenheft gelöst werden konnten.
ID
1
2
3
4
5
6
7
8
9
10
11
Name
Eingeschränkte Suche
Transferdaten
Aktualisierungen
Inkonsistenz zwischen Dokumenten
Inkonsistenzen zwischen Sachmerkmalen
Klassenmapping
Dokumentabgleich
Datenleichen
Betriebsmittelstatus
Änderungswesen
Dokumentverwaltung
Priorität
1
1
1
2
2
2
2
2
3
3
3
Tabelle 5.1.: Schwachstellen des Ist–Zustands
`
Gelöst
4
2
4
2
2
2
2
2
2
2
2
Die Forderung, dass durch das neue Konzept alle Anforderungen mit Priorität 1 gelöst werden müssen, sind nicht vollständig erfüllt. Immerhin kann bei zwei von den drei wichtigsten
Punkten Abhilfe attestiert werden, wobei die Anforderungen mit niedrigeren Prioritäten
auf der Strecke bleiben.
Die standortübergreifende Suche und die Reduzierung des Verwaltungsaufwands wird
durch das bestehende Konzept optimal gelöst. Zur Situation der schlechten Verbindung
bei Massenupdates wird hingegen nicht eingegangen, sodass dieser Punkt im erweiterten
Lastenheft aufgegriffen werden muss. Anforderung der Priorität 2 werden vom Lastenheft
gänzlich ausgelassen und können durch teilweise einfache Änderungen in der Infrastruktur
der Systeme oder den Prozessen zwischen den Systemen gelöst werden. Lösungsvorschläge
für die Punkte dieser Kategorie sind im erweiterten Lastenheft zu finden. Bei den Punkten
mit Priorität 3 handelt es sich im Allgemeinen um nicht–funktionale Anforderungen, die
vor allem das Usability betreffen und im positiven Sinne zur Software–Ergonomie beitragen können. Im erweiterten Lastenheft werden diese Punkte jedoch nicht aufgegriffen, da
nur Entwürfe für funktionale Anforderungen im Rahmen dieser Arbeit von Interesse sind.
Während einige dieser Punkte durch das bestehende Lastenheft einfach nicht erfüllt werden, sind andere Punkte gar nicht berücksichtigt, die aber für ein zentrales Konzept absolut notwendig sind. Im erweiterten Lastenheft wird deshalb zwischen fehlenden Anforderungen, Schwachstellen aus dem Ist–Zustand und Schwachstellen aus dem Soll–Konzept
unterschieden.
89
5. Soll–Konzept–Szenario
5.2. Erweitertes Soll–Konzept
Das erweiterte Soll–Konzept nimmt das vorhandene Soll–Konzept als Grundlage und ergänzt es um wichtige Anforderungen, die bisher nicht berücksichtigt wurden aber als essentiell angesehen werden. Außerdem werden erneut die Schwachstellen aus dem Ist–Zustand
aufgegriffen und Lösungskonzepte angeboten. Durch das bestehende Soll–Konzept hervorgebrachte Schwachstellen werden ebenfalls berücksichtigt und mögliche Lösungen aufgezeigt.
5.2.1. Erweiterungen im Lastenheft
Im Folgenden werden Erweiterungen vorgestellt, die bisher vom Lastenheft nicht berücksichtigt wurden.
5.2.1.1. Datenreplikation
Die Replikation der Daten zwischen den Master–Servern und den einzelnen Standorten
wurde bisher durch das Lastenheft nicht genau spezifiziert und es sind mehrere Konzepte
denkbar. Wenn von Daten die Rede ist, dann sind in diesem Zusammenhang die Dokumente gemeint und die zugehörigen Meta–Daten, die eine Beschreibung zu den Dateien
liefern. Die Dokumente können unter Umständen - vor allem aber im CAD–Bereich – sehr
groß werden, sodass ein Transfer auf Abruf sehr zeitintensiv ist.
Das erste Konzept in Abbildung 5.8 sieht ein Replizieren der Meta–Daten als auch der
Dokumente auf die lokalen Systeme vor.
Abbildung 5.8.: Replizieren von Meta–Daten und Dokumenten
Jedem Standort stehen die Meta–Daten und Dokumente als lokale Arbeitskopie zur Verfügung, sodass Änderungen zunächst immer am dezentralen System durchgeführt werden
und anschließend durch die bidirektionale Schnittstelle zwischen dem Master–System und
90
5.2. Erweitertes Soll–Konzept
dem lokalen Zielsystem ein Abgleich stattfindet. Diese Methode hat den Nachteil, dass
trotz eines Master–Systems jeder Standort auf seinen eigenen Daten arbeitet, die später
am Master–Server gemerged werden müssen. Dabei können aber auch Probleme auftreten
wie man sie aus verteilten Systemen kennt, denn durch die lokalen Daten können dieselben
Dokumente an unterschiedlichen Standorten gleichzeitig geändert werden. Beim anschließenden Einchecken muss der Master–Server entscheiden welcher Datensatz schließlich der
gültige ist.
Im zweiten möglichen Konzept werden nur die Dokumente mit dem lokalen Zielsystem
repliziert, die Meta–Daten werden weiterhin zentral verwaltet, wie es in Abbildung 5.9
dargestellt ist.
Abbildung 5.9.: Replizieren ausschließlich von Dokumenten
Durch die enorme Dateigröße müssen die Dokumente immer lokal am jeweiligen Standort
zur Verfügung stehen, sodass diese nicht erst bei Bedarf geladen werden und somit die
Produktion verzögern. Da es sich bei den Meta–Daten um eine geringe Dateigröße handelt,
können diese durchaus online zur Verfügung gestellt werden. Jeder Standort greift somit
auf den immer gleichen Datenbestand zu, der somit auch leichter verwaltet werden kann.
Konflikte können durch dieses Konzept keine auftreten, da Datensätze, die von einem
Standort momentan bearbeitet werden, für andere Standorte gesperrt werden können.
Obwohl das Problem der verteilten Daten somit gelöst wäre, entsteht durch dieses Konzept
ein neues Problem. Die Verfügbarkeit der Meta–Daten ist abhängig von der Leitungsgüte,
wobei im schlimmsten Fall die Leitung komplett ausfallen kann und die Meta–Daten somit
nicht mehr zur Verfügung stehen. Dies würde ebenfalls einen Ausfall in der Produktion
bedeuten, was unbedingt zu verhindern ist.
Möchte man die positiven Eigenschaften aus den zwei bisherigen Konzepten vereinen,
ohne die negativen Seiteneffekte zu behalten, so ergibt sich ein drittes Konzept. Sowohl
die Dokumente als auch die Meta–Daten werden an die lokalen Zielsysteme repliziert.
Änderungen an Meta–Daten finden dennoch nur zentral statt, wie es in Abbildung 5.10
dargestellt ist.
Alle Daten und Dokumente stehen lokal zur Verfügung und werden auch von den lo-
91
5. Soll–Konzept–Szenario
Abbildung 5.10.: Replikation von Meta–Daten und Dokumenten aber nur zentrale Änderung der Meta–Daten
kalen Systemen gezogen, illustriert durch die rote Kante. Die Daten stehen immer zur
Verfügung, auch wenn die Verbindung unterbrochen werden sollte. Änderungen an Meta–
Daten können nur am zentralen System durchgeführt werden, sodass die entsprechenden
Datensätze für andere Standorte während der Bearbeitung gesperrt werden, was durch
die grüne Kante illustriert wird. Dieses Konzept ist robust gegen Ausfälle und sicher bei
Änderungen an Daten, allerdings sind Änderungen nicht sofort am Standort verfügbar,
denn die Übertragung durch die Schnittstelle kann Zeit in Anspruch nehmen. Änderungen
an den CAD–Dokumenten selbst müssen lokal gespeichert werden, da die Dateien für eine
direkte Übertragung zu groß sind und zeitversetzt mittels Streamingprotokollen an die
zentralen Master–Server kopiert werden.
5.2.1.2. Synchronisation
Unabhängig vom verwendeten Konzept bei der Replikation der Daten, stellt sich die Frage
nach dem Zeitpunkt der Synchronisation von geänderten Meta–Daten und Dokumenten.
Wie bereits beschrieben ist der Größenunterschied zwischen Dokumenten und den zugehörigen Meta–Daten enorm, sodass sich auch hier mehrere Konzepte ergeben.
Im synchronen Ansatz werden die Dateien und die Meta–Daten gleichzeitig mit dem
zentralen Server abgeglichen, wie es in Abbildung 5.11 dargestellt ist.
Natürlich sind die Meta–Daten um ein vielfaches schneller zentral verfügbar als die Dokumente, sodass sich zeitbedingte Inkonsistenzen zwischen Dokument und zugehörigen
Daten ergeben können. Das einem Stammsatz zugeordnete Dokumente ist in diesem Fall
nicht aktuell, was potentiell gefährlich ist, da der Benutzer nicht auf diesen Umstand
aufmerksam gemacht wird. Oft werden jedoch ausschließlich die veränderten Meta–Daten
zur weiteren Verarbeitung benötigt, die sofort nach dem Einchecken zur Verfügung stehen
und den Prozess beschleunigen.
92
5.2. Erweitertes Soll–Konzept
Abbildung 5.11.: Synchroner Abgleich mit Inkonsistenzen
Die sicherere Variante stellt der asynchrone Ansatz dar, der zunächst das veränderte
Dokument mit dem Master abgleicht und erst nach erfolgreichem Hochladen die Meta–
Daten synchronisiert, wie es in Abbildung 5.12 dargestellt ist.
Abbildung 5.12.: Asynchroner Abgleich mit Wartezeiten
Da die Dokumente die meiste Zeit für den Abgleich in Anspruch nehmen, werden sie
als erstes synchronisiert und erst dann die Meta–Daten, die in wenigen Sekunden abgeglichen sind. Somit sind die verknüpften Dokumente zu den Meta–Daten immer aktuell
und konsistent verfügbar. Unter Umständen entstehen durch das primäre Abhandeln der
Dokumente lange Wartezeiten, die den Prozess verlangsamen können, wenn nur die Meta–
Daten als weitere Basis gebraucht werden.
93
5. Soll–Konzept–Szenario
Einen eindeutig empfehlenswerten Ansatz gibt es in diesem Fall nicht, da sowohl der
eine als auch der andere Schwachstellen aufweist. In Anbetracht der Wertung von schnell
ablaufenden Prozessen ist aber dem synchronen Ansatz der Vorzug zu geben, da er die
Daten zur weiteren Verarbeitung ohne Verzögerungen zur Verfügung stellt, auch wenn
dies auf Kosten der Konsistenz geht.
5.2.1.3. Heterogene Datenbanken
Bisher waren heterogene Datenbanksysteme im Einsatz, während in Passau Oracle verwendet wurde, kam in Gainesville Microsoft SQLServer zum Einsatz. In Anbetracht der
Master–Slave–Architektur und der bidirektionalen Schnittstelle ist die Verwendung eines
homogenen DBMS2 zu empfehlen. Durch verschiedene DBMS–Systeme kommt Heterogenität auch auf Datenebene zum Vorschein, da oft verschiedene Schemata oder unterschiedliche Konventionen für die Speicherung verwendet werden. Die Auflösung der Heterogenität ist kompliziert und muss auf explizit gespeichertes semantisches Integrationswissen
zurückgreifen. Um auf dieselben konsistenten Daten zugreifen zu können, sollte deshalb
ein homogenes DBMS–System verwendet werden.
5.2.1.4. Automatische Rückgabe
Abhängig vom zukünftig umgesetzten Berechtigungskonzept ist eine automatische Rückgabe von geänderten Merkmalswerten von FATool nach Axalant denkbar. Bisher war der
Rückgabeprozess manuell durchzuführen und als „interaktive Rückgabe“ bekannt. Hierbei muss der Betriebsmittelstatus in FATool auf „6 Warte auf Axalant Freigabe“ gesetzt
werden und der im Hintergrund laufende Axalant–Client kommt in den Fokus. In einer
Eingabemaske sind alle Merkmalswerte dargestellt, sodass der Benutzer vor dem Einchecken alle Werte kontrollieren kann. Um die Änderungen schließlich einzuchecken, muss
am Material ein Statuswechsel auf „In Änderung“ vorgenommen werden, bevor die Werte gespeichert werden. Erst dann können die Merkmale überschrieben oder hinzugefügt
werden. Im letzten Schritt muss das Material wieder freigegeben werden, um es weiterhin
benutzen zu können.
Alle diese manuellen Vorgänge könnte man automatisieren, wenn die entsprechenden Benutzerrechte aus Axalant auch in FATool vorliegen. Die automatische Rückgabe wird ebenfalls wie gewohnt durch Setzen des Betriebsmittelstatus aktiviert. Ein aktiver Axalant–
Client ist an dieser Stelle nicht mehr notwendig, da die Berechtigungen direkt aus FATool
gezogen und mit Axalant abgeglichen werden. Bei einer erfolgreichen Überprüfung der
Berechtigungen, wird der Statuswechsel am Material automatisch durchgeführt und weitere Schnittstellen zu Nachbarsystemen angetriggert. Beim Speichern der Merkmalswerte
wird zunächst der Datentyp und die Feldkonventionen geprüft und bei erfolgreichem Abspeichern das entsprechende Material automatisch wieder freigegeben.
2
DBMS: Datenbenk–Managementsystem
94
5.2. Erweitertes Soll–Konzept
Somit hätte man eine vollautomatische bidirektionale Schnittstelle, die auch das Fehlerpotential von manuellen Eingaben durch den Endanwender senken kann.
5.2.2. Schwachstellen des Ist–Zustands
Im Folgenden werden für die im Ist–Zustand aufgedeckten Schwachstellen mögliche Lösungsvorschläge und Workarounds aufgezeigt. Dabei wird nur auf funktionale Anforderungen eingegangen, die innerhalb der Schnittstelle oder des FATool –Clients umzusetzen
sind.
5.2.2.1. Transferdaten
Da es sich beim Master–ZF Server zukünftig um eine zentrale Komponente handeln wird,
sollte der Serverstandort von Axalant und FATool –Master physisch gleich sein. Dies bedeutet, dass die Transferdaten somit direkt aus der Axalant–Datenbank in die Schnittstellentabellen geschrieben werden können, wie in Abbildung 5.13 verdeutlicht wird. Da
es sich hierbei um dieselbe Maschine oder zumindest dasselbe Rechenzentrum handeln
wird, besteht eine gute Anbindung zwischen den Systemen und lange Wartezeiten bei
Massenupdates oder vielen kleinen Anfragen werden zukünftig entfallen.
Abbildung 5.13.: Transferdatenverlagerung nach Axalant
95
5. Soll–Konzept–Szenario
Der Dispatcher befindet sich nun auf dem FATool –Master–ZF und verteilt die Daten an
die einzelnen Zielsysteme. Dadurch fällt Passau als physischer Verwaltungsstandort weg,
wenn auch die Administration weiterhin durch den Divisionsstandort Passau, genauer der
Abteilung FIDA5, durchgeführt wird.
5.2.2.2. Inkonsistenzen zwischen Dokumenten
Um Inkonsistenzen zwischen Dokumenten einzuschränken, muss zunächst die Möglichkeit
zum manuellen Hinzufügen von Dokument innerhalb von FATool deaktiviert werden. Diese Funktion bietet ein direktes Umgehen des strategischen Dokumentverwaltungssystems
Axalant, über dieses alle Dokumente nach FATool importiert werden sollen.
Das zweite Vorgehen zum Erzeugen von Inkonsistenzen war der Prozess zum Generieren
von 3D–Modellen mittels CREO. Das Problem war, dass nach dem Erstellen der 3D–
Grafik kein Dokumentstamm in Axalant angelegt wurde, sondern das Dokument direkt
nach FATool importiert wurde. Dieses Problem kann ganz leicht umgangen werden, wenn
das 3D–Modell nicht von CREO nach FATool zurückgeliefert wird, sondern über Axalant
und die AXA2FASys Schnittstelle nach FATool importiert wird, wie es in Abbildung 5.14
dargestellt ist. Die rote Kante verdeutlicht den Schritt der aus dem neuen Prozess heraus-
Abbildung 5.14.: Import von 3D–Modellen nach FATool
fällt. Eine direkte Rückgabe des Dokuments von CREO nach FATool ist somit nicht mehr
möglich und der Benutzer ist gezwungen in Axalant einen Dokumentstamm anzulegen,
um die Datei auch in FATool zur Verfügung zu haben. Der neue Dokumentstamm wird
von der Schnittstelle erkannt und automatisch in das richtige Zielsystem übertragen. Mit
dieser Methode werden gleichzeitig die Redundanzen zwischen den Dateien gelöst, denn
durch das Fehlen der direkten Rückgabe, fehlt auch die Datei grafik.prt im System.
Die Datei aus Axalant ist somit einzigartig – auch in FATool.
Ein Nachteil der mit dieser Methode einhergeht ist die geringe Wartezeit, die ein Benutzer aufbringen muss, bis das entsprechende Dokument schließlich nach FATool transferiert
wurde. Dies liegt an der Reaktionszeit der Schnittstelle, die im Minutentakt aufgerufen
96
5.2. Erweitertes Soll–Konzept
wird. Außerdem ist durch den Dateinamen, der jetzt als AA–Nummer vorliegt, ein automatisches Sichten des Dokuments im Viewer nicht mehr möglich. Dies wird durch die
Namenskonvention innerhalb der Anwendung verhindert.
5.2.2.3. Klassenmapping
Da die Anzahl der Klassen, die zwischen den Systemen ausgetauscht werden, sehr beschränkt ist, besteht die Möglichkeit, dass zur Überprüfung durch alle synchronisierten
Klassen iteriert wird und mit den original Klassen aus Axalant abgeglichen werden. Als
Anhaltspunkt für Veränderungen kann das „Update–Datum“ verwendet werden. Somit
kann die Differenz zwischen den Zeiten aus FATool und Axalant gebildet werden und bei
ungleichen Werten entsprechend mit einer erneuten Synchronisation der betroffenen Klasse begegnet werden. Das Klassenmapping müsste als separater Prozess angelegt werden,
der zeitgesteuert aufgerufen wird. Da Änderungen an Klassen im Verhältnis relativ selten
stattfinden, wäre ein Aktualisierungsintervall von 24 Stunden ausreichend.
5.2.2.4. Dokumentabgleich
Für den Dokumentabgleich wurden verschiedene Konzepte entwickelt und evaluiert. Der
beste Ansatz wurde anschließend implementiert. Die Umsetzung ist in Kapitel 6 zu finden.
5.2.2.5. Datenleichen
Das Problem der Datenleichen tritt nur auf, wenn Betriebsmittel manuell nach FATool
importiert werden. Dies bedeutet, dass über die Funktion „Betriebsmittel nach Axalant
holen“ nur die Materialnummer angegeben werden muss, um einen Materialstamm, unabhängig von seinem Status in Axalant, importieren zu können. Wenn der entsprechende
Datensatz in Axalant gelöscht wird, bleibt er in FATool als Datenleiche zurück.
Abbildung 5.15.: Speichern der manuell importierten Betriebsmittel
Die Funktion zum manuellen Importieren ist wichtig und muss erhalten bleiben, da die
Zuordnung von Merkmalswerten in FATool effizienter durchgeführt werden kann. Es muss
97
5. Soll–Konzept–Szenario
allerdings an dieser Funktion angesetzt werden, um Datenleichen zu verhindern. Eine Möglichkeit diesem Problem aus dem Weg zu gehen wäre die manuell importierten Betriebsmittel in einer Tabelle zu speichern und einmal pro Tag auf Verfügbarkeit im Quellsystem
zu überprüfen, wie es in Abbildung 5.15 dargestellt ist.
Diese Überprüfung muss natürlich nur solange durchgeführt werden bis das Betriebsmittel
in Axalant freigegeben wird, denn freigegebene Materialien können nicht mehr gelöscht
werden und durch den Statuswechsel wird das zugehörige Betriebsmittel in FATool über
die Schnittstelle aktualisiert. Sollte ein Betriebsmittel kein Pendant mehr in Axalant haben, so muss es auch aus FATool gelöscht werden. Betriebsmittel, die anschließend von
der Schnittstelle unterstützt und synchronisiert werden, können aus der Tabelle gelöscht
werden.
5.2.2.6. Betriebsmittelstatus
Das Problem des Betriebsmittelstatus von FATool besteht darin, dass er nichts aussagend ist. So können gesperrte Betriebsmittel weiterhin in Komplettwerkzeugen verwendet
werden. Dies muss dahingehend geändert werden, dass nur freigegebene Betriebsmittel in
Stücklisten verwendet werden dürfen.
Abbildung 5.16.: Beziehung zwischen Bauteil und Baugruppen
Für den Fall, dass ein Bauteil gesperrt
wird, das bereits Verwendung in einer
oder mehreren Baugruppen findet, muss
anders reagiert werden. Dies liegt an der
1:n Beziehung von Bauteilen, wie in Abbildung 5.16 dargestellt ist. So kann ein
Bauteil in mehreren Baugruppen verwendet werden. Diese Baugruppen alle zu sperren, würde einen enormen administrativen Aufwand nach sich ziehen. Es müsste jede einzelne gesperrte
Baugruppe auf Fehler untersucht werden. Deshalb wäre der Betriebsmittelstatus „Prüfen“ besser angebracht, sodass die Baugruppe weiter verwendet
werden kann, aber der Benutzer einen
Hinweis erhält, dass ein Problem vorliegt.
Beim Ändern des Betriebsmittelstatus erkennt FATool bereits in welchen Baugruppen
ein Bauteil verwendet wird und warnt den Benutzer bereits, ob er den Statuswechsel
wirklich durchführen will. Somit könnte auch der Status der verknüpften Baugruppen
leicht geändert werden.
98
5.2. Erweitertes Soll–Konzept
5.2.2.7. Inkonsistenzen zwischen SML
Das Problem inkonsistenter Sachmerkmale kommt einerseits daher, dass für Änderungen
an Merkmalswerten in FATool kein Statuswechsel durchgeführt werden muss und andererseits, dass diese Änderungen nicht nach Axalant eingecheckt werden müssen. Dies kann
zu unterschiedlichen Werten in gleichen Materialstämmen zwischen den beiden Systemen
führen.
Will man diesem Problem entgegentreten, so muss sichergestellt sein, dass der Betriebsmittelstatus in FATool bereits so verändert wurde, wie es zuvor beschrieben wurde. Denn
nur ein funktionierender Betriebsmittelstatus kann für neue, erweiterte Prozesse verwendet werden. Um dem ersten Problem zu begegnen, muss eine Policy eingeführt werden die
besagt, dass manuell importierte Betriebsmittel in FATool solange nicht freigegeben werden können, bis sie von der AXA2FASys–Schnittstelle berücksichtigt werden oder nach
Axalant eingecheckt wurden. Im zweiten Fall muss zusätzlich überprüft werden, ob der
Axalant–Status daraufhin auf „Freigegeben“ gesetzt wurde. Nur in diesem Fall behält das
Material auch in FATool den Betriebsmittelstatus „Freigegeben“. Dies kann leicht über
die Schnittstelle überprüft werden. Solange ein manuell importiertes Betriebsmittel nicht
eingecheckt und somit in Axalant freigegeben wurde, besitzt es den Betriebsmittelstatus
„Gesperrt“.
Die Lösung des Hauptproblems besteht im Zusammenlegen der beiden FATool –
Betriebsmittelstatus „Freigegeben“ und „Warte auf Axalant Freigabe“. Dadurch ist ein
Freigeben in FATool ohne ein Zurückgeben der geänderten Merkmalswerte nach Axalant
nicht mehr möglich, wie es in Abbildung 5.17 illustriert ist.
Abbildung 5.17.: Zusammenlegen der Status für Freigabe und Rückgabe
Der Prozess wurde dahingehend abgeändert, dass ein Betriebsmittel, das manuell importiert wurde, zunächst gesperrt ist und nicht in Komplettwerkzeugen verwendet werden
kann. Somit muss das Bauteil zuerst freigegeben werden, womit durch das Zusammenlegung der Status automatisch auch die interaktive Rückgabe gestartet wird.
99
5. Soll–Konzept–Szenario
Abbildung 5.18.: Abhängigkeit des Betriebsmittelstatus
Dies gilt ebenfalls für Betriebsmittel, die
bereits über die Schnittstelle synchronisiert
werden und somit initial freigegeben sind,
denn auch hier war es bisher möglich Merkmalswerte in FATool ohne Einchecken zu verändern. In diesem Fall muss der Betriebsmittelstatus bei etwaigen Änderungen automatisch auf „Gesperrt“ gesetzt werden. Um es
anschließend wieder freizugeben wird automatisch die interaktive Rückgabe gestartet
und abgewartet, ob über die AXA2FASys–
Schnittstelle auch der Axalant–Status „Freigegeben“ zurückgegeben wird. Nur in diesem
Fall wird der Betriebsmittelstatus in FATool
auch wieder auf „Freigegeben“ gesetzt, wie es
in Abbildung 5.18 dargestellt ist.
Veränderungen an Merkmalswerten können in FATool leicht festgestellt werden, denn
jedes Betriebsmittel muss explizit nach der Bearbeitung gespeichert werden. Somit könnte der Betriebsmittelstatus auch automatisch auf „Gesperrt“ gesetzt werden, nachdem
Veränderungen stattgefunden haben, solange bis die Änderungen auch nach Axalant zurückgegeben wurden.
5.2.3. Schwachstellen des Soll–Zustands
5.2.3.1. Selbstkontrolle
Da die Schnittstellen zukünftig auch zentral verwaltet werden, kann die administrative
Betreuung der Schnittstelle zu ZFLS ebenfalls durch die Abteilung FIDA5 übernommen
werden, die auch die Verteilung innerhalb von ZFGRP administriert. So kann ausgeschlossen werden, dass ZFLS eigenmächtig SAP –Standorte zur Übertragung freigibt. Bei einer
möglichen Abspaltung von ZFLS vom restlichen ZF–Konzern, kann die Schnittstelle zur
Administration an ZFLS zurückgegeben werden.
5.2.3.2. Berechtigungskonzept
Wie bereits in der Beschreibung dieser Schwachstelle erwähnt wurde, reichen die Änderungshoheiten alleine nicht aus, um die Sichtbarkeit und Veränderbarkeit der Stammdaten in FATool regulieren zu können. Es muss ein Konzept entwickelt werden, das alle an
das System und die Sicherheit gestellten Anforderungen erfüllt, ohne dabei das Berechtigungskonzept in FATool zu komplex werden zu lassen. Axalant stellt ein mehrstufiges
100
5.2. Erweitertes Soll–Konzept
Berechtigungssystem zur Verfügung, das von den Eigenschaften, die in FATool benötigten
Funktionen weit übersteigt. In FATool soll daher ein ausreichendes Minimum an Berechtigungen portiert werden.
Anforderungen Um entscheiden zu können welche Konzepte aus Axalant auch in FATool
umzusetzen sind, müssen die Anforderungen an das Berechtigungssystem definiert werden:
• Master–ZF enthält alle Datensätze mit Standort ZFGRP
Es existieren Datensätze am Master–ZF, die auch innerhalb ZFGRP für unterschiedliche Standorte nicht sichtbar sein dürfen
Es existieren Datensätze von ZF–Prüfsysteme, deren Meta–Daten zentral sichtbar sein sollen, die Dokumente jedoch nicht
• Master–ZFLS enthält alle Datensätze mit Standort ZFLS
• Master-ZF erhält Datensätze von Master–ZFLS mit Standort ZFLS ohne Änderungshoheit 4320
ZFLS–Anwender sichten Datensätze auf Master–ZF
Es existieren Datensätze auf Master–ZF, die für ZFLS–Anwender nicht sichtbar
sein dürfen
Berechtigungssysteme Um alle Anforderungen zu berücksichtigen muss zwischen der
Sichtbarkeit und Veränderbarkeit von Daten, sowie zwischen Meta–Daten und Dokumenten unterschieden werden. Um die Sichtbarkeit von Stammdaten regulieren zu können,
werden in Axalant virtuelle Standorte verwendet. Sie sind sowohl jedem Benutzer als
auch jedem Datensatz zugeordnet und nur bei übereinstimmenden Standorten werden die
Stammdaten angezeigt. Für unberechtigte Benutzer existieren diese Daten somit nicht.
Virtuelle Standorte können außerdem in Gruppen zusammengefasst werden, wie es bei
ZFGRP und ZFLS der Fall ist. Auf Datenbankebene hat jeder virtuelle Standort einen
eigenen Datenbankbenutzer mit unterschiedlichen Rechten. Die Auswahl über bestimmte
Datenbankbenutzer beim Start von Axalant läuft über dem Benutzer zugewiesene Rollen,
wie ZF-OWIA-MAS für das Mastersystem, das alle Daten enthält, ZF-OWIA-ZFGRP für alle
klassischen ZF–Standorte und ZF-OWIA-ZFLS für ZF–Lenksysteme.
Das zugrundeliegende Konzept wird ausschließlich von Oracle–Datenbanken zur Verfügung gestellt und nennt sich „Virtual Private Databases“. Mit VPDs können Policies
entworfen werden, die den Zugriff auf Zeilen– und Spaltenebene von Tabellen kontrollieren, ohne dafür verschiedene Views, Schemata oder Datenbanken zu verwenden. Immer
wenn Anfragen an VPD geschützte Tabellen ausgeführt werden, wird automatisch eine
dynamische WHERE–Klausel an die Anfrage angehängt, die die SQL–Anfrage des Benutzers verändert und die jeweilige Policy darauf anwendet. Somit kann der Zugriff auf Daten
101
5. Soll–Konzept–Szenario
feingranular gesteuert werden, ohne dass vorhandene Berechtigungen umgangen werden
können.3
Durch virtuelle Standorte kann die Sichtbarkeit von Daten gezielt gesteuert werden. Die
Veränderbarkeit muss jedoch durch zusätzliche Berechtigungen kontrolliert werden, denn
nicht jeder Benutzer der einen Datensatz sichten kann, sollte diesen auch ändern dürfen. Zum Ändern von Stammdaten wird deshalb die Änderungshoheit verwendet. Ein
vierstelliger Zahlencode, der auch jedem Benutzer zugeordnet ist und durch Abgleichen
der Änderungshoheiten entschieden wird, ob ein Benutzer berechtigt ist einen Datensatz
zu ändern. Jeder Benutzer besitzt mindestens eine oder mehrere Änderungshoheiten, wobei allerdings genau eine als Standard definiert ist. Beim Anlegen von neuen Stammdaten
wird die Standard–Änderungshoheit dieses Benutzers für den Stammdatensatz verwendet.
Obwohl die Änderungshoheit im Allgemeinen nicht mit dem Standort korreliert ist, kann
in Axalant mit einem Regelwerk die Zuordnung eines Standorts anhand der Änderungshoheit definiert werden. Durch eine zutreffende Änderungshoheit wird explizit festgelegt,
welche Aktionen der berechtigte Benutzer auf dem Datensatz durchführen darf. Folgende
Aktionen können jeder Änderungshoheit zugeordnet werden:
d
w
Löschen
Schreiben
v
vr
r
Lesen inkl. Native–Dateien
–
Lesen exkl. Native–Dateien
Lesen exkl. Native–Dateien
wenn freigegeben
Keine Berechtigungen
Tabelle 5.2.: Berechtigungen bzgl. der Änderungshoheit
Für den Spezialfall, dass die Meta–Daten für alle Standorte sichtbar sind, die Dokumente jedoch nur für bestimmte, gibt es die Möglichkeit einer Lesebeschränkung. Somit
kann explizit ausgewählt werden welche Organisationen bzw. Personen die Dokumente
sichten können. Auch im Änderungsfall kann eine Schreibbeschränkung gesetzt werden, die nur berechtigten Organisationen oder Personen erlaubt die Dokumente zu ändern.
Bei Änderungen gibt es jedoch Unterschiede, ob die Berechtigung auf Organisationen oder
Personen gesetzt wurde. Während bei berechtigten Organisationen auch Benutzer den Datensatz ändern dürfen, die nicht über die entsprechende Änderungshoheit verfügen, aber
deren Organisation als berechtigte eingetragen ist, ist die Änderungshoheit bei eingetragenen Personen nicht ausreichend. In diesem Fall können ausschließlich die berechtigten
Personen diese geschützten Stammdaten ändern.
Neben der bereits eingeführten Änderungshoheit braucht man also zwei weitere Berechtigungssysteme aus Axalant, die nach FATool portiert werden müssen. Zum Steuern von
Sichtbarkeiten werden die virtuellen Standorte verwendet, zur Regulierung der Sichtbarkeit von Meta–Daten und zugehörigen Dokumenten wird die Lese–/Schreibbeschränkung
verwendet.
3
http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#DBSEG80081
am 07.04.2014)
102
(abgerufen
5.2. Erweitertes Soll–Konzept
Berechtigungskonzepte Da nun die zu portierenden Berechtigungssysteme erörtert
wurden, sind Konzepte zu entwickeln wie die Sichtbarkeit und Änderung von Daten als
Prozess innerhalb von FATool umzusetzen sind.
Das Berechtigungskonzept zum Sichten von Daten ist in Abbildung 5.19 dargestellt und
beginnt mit der Auswertung des virtuellen Standorts. Dabei werden die Standortwerte
des Benutzers mit denen des Datensatzes auf Übereinstimmung verglichen. Nur wenn eine
Übereinstimmung vorliegt kann der Benutzer diesen Datensatz sehen, andernfalls würde
dieser für den Benutzer nicht existieren und die Meta–Daten wie auch die Dokumente wären unsichtbar. War diese Überprüfung erfolgreich wird als nächstes die Lesebeschränkung
ausgewertet.
Abbildung 5.19.: Berechtigungskonzept zum Sichten von Daten
Falls diese nicht gesetzt ist, werden sofort die FATool internen Berechtigungen ausgewertet, die hier als Blackbox dargestellt sind und bereits in Kapitel 2.2.3 näher erklärt
wurden. Nur wenn der Anwender auch die entsprechenden FATool –Berechtigungen besitzt, kann er mit dem Datensatz arbeiten. Ist die Lesebeschränkung doch gesetzt, so
muss überprüft werden, ob die Organisation des Benutzer oder der Benutzer selbst bei
berechtigten Organisationen/Personen eingetragen ist. Nur in diesem Fall, kann er auch
die zugehörigen Dokumente sichten. Andernfalls könnte er nur die Meta–Daten einsehen,
103
5. Soll–Konzept–Szenario
vorausgesetzt seine FATool –Berechtigungen sind ausreichend.
Das Berechtigungskonzept zum Ändern von Daten ist in Abbildung 5.20 dargestellt. Wie
auch beim Sichten von Daten muss als erstes der virtuelle Standort ausgewertet werden,
denn nur Datensätze, die der Benutzer sehen darf, sollte er auch ändern dürfen. Ist der
virtuelle Standort der Stammdaten beim Benutzer nicht eingetragen, so sind die Daten für
ihn unsichtbar und er kann sie nicht bearbeiten. Ist diese Überprüfung erfolgreich, so folgt
als nächstes die Auswertung der Schreibbeschränkung, die ähnlich der Lesebeschränkung
verläuft. Bei gesetzter Schreibbeschränkung wird überprüft, ob der Benutzer Zugriff auf
die Dokumente haben darf, indem die berechtigten Organisationen/Personen ausgewertet
werden. Ist die Organisation des Anwenders als berechtigt eingetragen, so ist auch er
berechtigt den Datensatz zu ändern, sofern die FATool internen Voraussetzungen erfüllt
werden.
Abbildung 5.20.: Berechtigungskonzept zum Ändern von Daten
Bei diesen Voraussetzungen wird überprüft ob der Benutzer in FATool ausreichende Be-
104
5.2. Erweitertes Soll–Konzept
rechtigungen besitzt, um die gewünschte Aktion durchzuführen. In einem zweiten Schritt
wird überprüft, ob der Axalant–Status auf „In Änderung“ gesetzt wurde, denn freigegebene Materialien können nicht geändert werden. Außerdem wird verifiziert, ob das entsprechende Betriebsmittel, das geändert werden soll, auch am SAP –Standort des Benutzers
verfügbar ist. Nur in diesem Fall macht es Sinn Änderungen an einem FHM zu erlauben,
ansonsten könnten auch FHM fremder Standorte geändert werden.
Ist die Organisation nicht als berechtigt eingetragen, so wird zunächst überprüft, ob der
Benutzer als berechtigte Person eingetragen ist. In diesem Fall würden wieder die FATool –Berechtigungen geprüft werden bevor der Datensatz bearbeitet werden kann. Sind
berechtigte Personen für diesen Stammdatensatz eingetragen, der Benutzer selbst ist allerdings nicht berechtigt, so kann er den Datensatz nicht bearbeiten. Falls keine berechtigten
Benutzer eingetragen sind und seine Organisation nicht zu den berechtigten zählt, führt
ein alternativer Weg über die Änderungshoheit. Die Änderungshoheit wird auch direkt
nach den virtuellen Standorten ausgewertet, falls die Schreibbeschränkung nicht gesetzt
ist. Hierbei werden die Änderungshoheiten des Benutzers mit der des Datensatzes abgeglichen. Liegt keine Übereinstimmung vor, so darf er den Stammsatz nicht ändern,
andernfalls müssen noch die Rechte an dieser Änderungshoheit überprüft werden. Die
Flags d/w für „Delete“ bzw. „Write“ erlauben ein Verändern der Daten, sofern die internen
Berechtigungen von FATool es zulassen, wohingegen die Flags r/v/vr/- nur das Sichten
der Daten erlauben, nicht aber das Ändern.
Umsetzung Während die Änderungshoheiten in FATool für alle Betriebsmittel bereits
mitgeführt werden – wenn auch zu rein informativen Zwecken – ist die Auswertung der
Änderungshoheit gut vorbereitet. Lediglich für die Benutzer muss ein Import ihrer zugehörigen Änderungshoheiten durchgeführt werden, sodass die Änderungshoheit des Betriebsmittels mit der des Benutzers abgeglichen werden kann und die zugehörigen Rechte
der Änderungshoheit ausgewertet werden.
Die Einführung der virtuellen Standorte in FATool ist durch ein technisches Problem begrenzt, denn „Virtual Private Databases“ sind ausschließlich in Oracle verfügbar, was die
Verwendung von Microsoft SQLServer zukünftig verhindern würde. Außerdem war das
Konzept der Sicherheit auf Zeilen– und Spaltenebene in FATool nicht geplant, sodass sich
ein komplett konträres Datenlayer zu diesem Ansatz ergeben hat, das einen substantiellen Neuaufbau bedeuten würde. Ein möglicher Workaround wäre, dass das Konzept der
virtuellen Standorte nur auf die Daten angewendet wird, die in der Anwendung sichtbar
werden, nicht jedoch auf Datenbankebene. Somit wird bei einer SQL–Abfrage dem Benutzer sein Standort automatisch als WHERE–Klausel angehängt und somit auf berechtigte
Datensätze gefiltert. Da ein normaler Anwender nicht bis zur Datenbank vordringt, ist
dieses Konzept sicher und kann nicht umgangen werden. Es müssen lediglich die virtuellen
Standorte der Betriebsmittel und der Benutzer nach FATool portiert werden.
Die berechtigten Organisationen/Personen laufen parallel zur Änderungshoheit und müssen ebenfalls für jedes Betriebsmittel und jeden Benutzer importiert werden. Dabei brauchen nur die Betriebsmittel berücksichtigt werden, die entweder eine Lese– oder Schreibbeschränkung gesetzt haben.
105
5. Soll–Konzept–Szenario
5.2.3.3. Standortspezifische Änderungen
Es sind verschiedene Szenarien für Änderungen an standortspezifischen Leisten denkbar. Die Änderungen können am lokalen Zielsystem durchgeführt werden, am zentralen
Master–Server oder im Falle von ZFLS entweder am Master–ZF oder am Master–ZFLS.
Bei zentralen Änderungen am Master–ZF braucht man bestimmte User–Rollen für ZFLS–
Anwender, sodass diese direkt Änderungen am System vornehmen können. Da dies in der
Regel nicht gewünscht ist und standortspezifische Änderungen für andere Standorte nicht
hoch relevant sind, ist die Variante mit den lokalen Änderungen am jeweiligen Zielsystem
der zentralen Variante vorzuziehen. Dies liegt auch daran, dass Änderungen sofort am
Standort verfügbar sind, ohne das diese zunächst über die Schnittstelle übertragen werden
müssen. Außerdem bietet diese Variante eine Ausfallsicherheit, falls der zentrale Master–
Server nicht erreichbar ist. Ein Abgleich der Änderungen findet über die bidirektionale
Schnittstelle statt, sodass Benutzer keine zentralen Rechte am Master–Server benötigen,
sondern die Änderungen auf ihren lokalen Systemen ausführen können.
5.2.3.4. Konflikte durch Datenmigration
Die Datenmigration der Master–Server soll durch das Zusammenführen der Daten aus den
Zielsystemen bewerkstelligt werden. Dabei kann es zu Konflikten kommen, wenn unterschiedliche Standorte verschiedene Werte für gleiche Merkmale besitzen. Der Master muss
sich für einen Wert entscheiden, der zentral gespeichert wird. Abweichende Merkmalswerte
der Zielsysteme werden zukünftig durch diesen überschrieben, wenn der Abgleich vollautomatisiert abläuft, sodass alle Zielsysteme dieselben Werte für gleiche Merkmale haben
werden. Somit erhält man einen konsistenten Datenbestand, gleichzeitig besteht aber die
Gefahr, dass solche Änderungen vom Standort selbst nicht wahrgenommen werden. Durch
das mergen der Daten aus den Zielsystemen fehlen die für das Berechtigungssystem benötigten Eigenschaft aus Axalant, die zukünftig berücksichtigt werden müssen. Die Datenmigration kann daher nicht durch die bidirektionale Schnittstelle durchgeführt werden,
sondern muss durch ein spezielles Skript automatisiert mit geeigneter Konfliktlösung ablaufen, wie es in Abbildung 5.21 dargestellt ist.
Abbildung 5.21.: Automatisierung der Migration
106
5.2. Erweitertes Soll–Konzept
Die Quelldaten sind als rote Kanten dargestellt und kommen direkt von den Zielsystemen
zu einem Automatisierungsskript, das alle benötigten Daten zum jeweiligen Betriebsmittel aus Axalant abruft. Das holen der Zusatzinformationen ist als bidirektionale blaue
Kante dargestellt und betrifft Daten wie die Änderungshoheit, die virtuellen Standorte
oder die berechtigten Organisationen/Personen. Der Abgleich mit den Master–Servern ist
als grüne Kante dargestellt, wobei dieser Abgleich bei Master–ZF bidirektional ist und
bei Master–ZFLS unidirektional. Da es bei ZFLS nur ein einziges Zielsystem gibt, kann es
zu keinen Konflikten kommen und die Datensätze können direkt geschrieben werden. Bei
Master–ZF hingegen kann es vorkommen, dass verschiedene Werte für dasselbe Merkmal
durch die Zielsysteme importiert werden. In diesem Fall gleicht das Migrationsskript die
Änderungshoheiten ab und es wird der Wert gewählt, dessen Standort die entsprechende
Änderungshoheit aufweist. Sollte in speziellen Fällen kein Zielsystem diese Änderungshoheit aufweisen, wird der Originalwert aus Axalant verwendet.
5.2.3.5. Klassenmapping durch ZFLS
Da es auch für ZFLS möglich sein muss Klassenmappings bei Bedarf hinzuzufügen, muss
der Zugriff auf Master–ZF gestattet werden, da dort alle Klassenmappings zentral verwaltet werden. Ein eigenständiges Einfügen von Klassenmappings am Master–ZFLS widerspricht der Idee eines eindeutigen zentralen Master–Servers, der als einzige Instanz Änderungen entgegennimmt. Auch die Übernahme administrativer Aufgaben durch ZFGRP
bringt keine Lösung, da die Eigenständigkeit von ZFLS gewahrt werden muss. Der Eingriff
in den administrativen Bereich von Master–ZF muss jedoch sinnvoll reguliert werden und
ist ohne entsprechende User–Rollen in FATool bisher nicht umsetzbar.
107
5. Soll–Konzept–Szenario
5.3. Zusammenfassung
In Tabelle 5.3 wird eine Übersicht über alle gefundenen Schwachstellen des Ist–Zustands
und des Soll–Konzepts gegeben. Neben einer Priorisierung, wurde vor allem untersucht, ob
die Schwachstellen durch das erweiterte Lastenheft geschlossen werden können. Außerdem
wurde eine Aufwandsschätzung durchgeführt, die angibt unter welchem Zeitaufwand die
jeweilige Schwachstelle geschlossen werden kann. Die Einheiten orientieren sich hierbei an
den Kleidergrößen und reichen von S (wenig) bis L (viel).
`
ID
Name
Priorität Konzept Aufwand
1
Eingeschränkte Suche
1
4
2
Transferdaten
1
4
S
3
Aktualisierungen
1
4
4
Inkonsistenz zwischen Dokumenten
2
4
L
5
Inkonsistenzen zwischen Sachmerkmalen
2
4
L
6
Klassenmapping
2
4
S
7
Dokumentabgleich
2
4
M
8
Datenleichen
2
4
S
9
Betriebsmittelstatus
3
4
S
10
Änderungswesen
3
2
?
11
Dokumentverwaltung
3
2
?
12
Selbstkontrolle
3
2
?
13
Berechtigungskonzept
1
4
L
14
Standortspezifische Änderungen
3
4
S
15
Konflikte durch Datenmigration
1
4
M
16
Klassenmapping durch ZFLS
3
2
?
Tabelle 5.3.: Schwachstellen mit Aufwandsabschätzung
Während die „eingeschränkte Suche“ und die „Aktualisierungen“ bereits durch das bestehende Soll–Konzept gelöst werden können, kann den „Transferdaten“, die erhebliche
Performanceprobleme bei Massenupdates verursacht haben, durch ein einfaches Verlagern
zur Axalant–Datenbank begegnet werden. Alle weiteren Schwachstellen des Ist–Zustands
können durch die neuen Konzepte geschlossen werden, mit Ausnahme vom „Änderungswesen“ und der „Dokumentverwaltung“, die eher im nicht–funktionalen Bereich anzusiedeln
sind und daher der Verantwortung des Herstellers obliegen.
Bei den neuen Schwachstellen, die durch das bestehende Soll–Konzept aufgeworfen werden, kann lediglich für die „Selbstkontrolle“ und das „Klassenmapping durch ZFLS“ momentan noch kein Konzept vorgelegt werden. Alle anderen Schwachstellen können im
erweiterten Lastenheft durch ausführliche Konzepte beseitigt werden.
Der Dokumentabgleich wird bereits im Rahmen dieser Arbeit implementiert und getestet, sodass er praxistauglich eingesetzt werden kann. Eine ausführliche Beschreibung des
zugrundeliegenden Konzepts und der Programmierarbeiten folgt in Kapitel 6.
108
6. Umsetzung
Bei der Umsetzung soll ein Arbeitspaket des Projekts implementiert und verifiziert werden. Dafür sind zunächst bezüglich der Problemstellung mögliche Lösungsansätze zu entwickeln. Die Verifizierung wird durch verschiedene Testfälle definiert, die den korrekten
Ablauf des Programms sicherstellen.
6.1. Problemstellung
Die Problemstellung wurde bereits in 4.3.6 ausführlich beschrieben. Hinzu kommen nun
Einschränkungen seitens des Systems:
1. Es sollen nur Dokumente berücksichtigt werden deren verknüpfte Materialstämme
zwischen Axalant und FATool synchronisiert werden. Dazu müssen Tabellen angelegt werden, die diese Informationen beinhalten.
2. Die Aktualisierung muss effizient und schnell ablaufen, sodass Inkonsistenzen weitestgehend vermieden werden. Dies geschieht durch zeitgesteuerte Aufrufe des Dokumentabgleichs im Minutentakt. Durch eine effektive Selektion der Dokumente sind
diese unmittelbar nach der Aktualisierung in FATool verfügbar.
3. Es gibt „Vertiffungsprozesse“, die aus einem nativen CAD–Dokument eine TIF–Datei
zum Betrachten erstellen. Hier wird extern ein Generator angestoßen, der diese
Grafik erzeugt, wobei dieser Plotprozess zeitverzögert fertiggestellt werden kann.
Die Datei existiert logisch in der Datenbank also schon, obwohl sie physisch noch
nicht vorliegt. Darauf muss ebenfalls entsprechend zeitversetzt reagiert werden.
Es ist also ein Prozess zu entwickeln, der den Dokumentabgleich zwischen Axalant und FATool unterstützt und dabei nur die im Rahmen des FDO–Bereichs verfügbaren Mittel verwendet. Das bedeutet, dass dieses Vorgehen durch konzernweite Regelungen eingegrenzt
ist, da als Beispiel keine Änderungen an globalen Prozessen bzw. direkte Änderungen am
Logi–View Code von Axalant gemacht werden dürfen. Somit sind zunächst Ansätze zu
spezifizieren, die ohne diese Regelungen zu verstoßen zum gewünschten Ergebnis führen.
109
6. Umsetzung
6.2. Ansatz
Da der Dokumentabgleich immer dann aktiv werden soll, wenn ein neues Dokument angelegt wird oder ein vorhandenes ersetzt wird, muss zunächst eine Strategie entwickelt
werden, die den Abgleichprozess über die entsprechenden Änderungen in Kenntnis setzt.
Dies ist bei einem System mit mehreren Millionen Datensätzen nicht einfach zu bewerkstelligen, sodass die folgenden zwei Ansätze denkbar sind:
1. Ansatz: Top–Down (Dekomposition) Der Top–Down–Ansatz ist der intuitive, bei
dem man davon ausgeht, dass alle Datensätze, die zwischen Axalant und FATool synchronisiert werden, durchsucht und die angehängten Dokumentenstämme auf Aktualität
geprüft werden. Da es einige Beschränkungen gibt, wie der Zuordnung eines Dokumentstamms zu mehreren Materialien, wird dieser Ansatz schnell zu ineffizient. Weitere Bedingung ist, dass die Aktualisierung innerhalb eines Wochenendes durchgeführt sein muss,
sodass die Systeme während der Arbeitszeit aktuell und benutzbar sind. Gruppiert man
nach Materialnummern so kommt man auf rund 170.000 Datensätze, die zwischen Axalant
und FATool ausgetauscht werden und überprüft werden müssten. Ob ein Wochenende dafür ausreicht ist fraglich, sodass man die Abarbeitung in Blöcke aufteilen müsste. Dabei
werden an einem Wochenende so viele Blöcke wie möglich abgearbeitet, alle anderen werden zum nächstmöglichen Zeitpunkt aktualisiert. Natürlich gibt es bei diesem Ansatz
immer noch Inkonsistenzen zwischen den Systemen.
2. Ansatz: Bottom–Up (Aggregation) Der Bottom–Up–Ansatz soll Aktualisierungen
nur reaktiv durchführen, das heißt wenn eine entsprechende Aktion am Dokumentstamm
vorausgegangen ist. Dies ist immer dann der Fall, wenn ein Benutzer ein neues Dokument
in Axalant eincheckt oder ein vorhandenes aktualisiert. Die technischen Möglichkeiten
innerhalb von Axalant sind jedoch begrenzt, sodass eine Tabelle gesucht werden muss,
die die benötigten Informationen protokolliert und zur Verfügung stellt. Eine Schnittstellentabelle nach SAP enthält genau die benötigten Informationen, ist jedoch für die
FDO–Abteilung nur mit Leserechten zu verwenden. Da bereits ausgeführte Aktionen des
Dokumentabgleichs kontrollierbar und nachvollziehbar sein sollten, muss es die Möglichkeit zum Quittieren geben. Dafür werden die entsprechenden Zeilen der Tabelle in eine
eigene beschreibbare FDO–Tabelle kopiert. Durch dieses Vorgehen ist es möglich die Aktualisierungen im Minutentakt durchzuführen, da es meist nur wenige Einträge pro Stunde
sind, die durch den Index auf der Spalte „Datum“ schnell und effizient zu sortieren sind.
So können stetig Aktualisierungen durchgeführt werden, sodass Inkonsistenzen nahezu
eliminiert werden, jedoch maximal im Sekundenbereich auftreten können.
Für das Problem der „Vertiffung“ muss zunächst der Dokumenttyp unterschieden werden.
Falls native CAD–Formate vorliegen, muss der Dokumentstamm zusätzlich eine TIF–
Grafik beinhalten. Ist diese Grafik vorhanden wird der normale Synchronisationsprozess
angestoßen, andernfalls muss berücksichtigt werden, dass der „Vertiffungsprozess“ eine
110
6.3. Implementierung
unbestimmte Zeit in Anspruch nehmen kann und somit die Grafik noch nicht physikalisch
vorliegt.
In Abbildung 6.1 ist das Programm konzeptionell dargestellt.
Abbildung 6.1.: Konzept der Wiedervorlage
Der Ausgangspunkt sind die Dokumentstämme, die mehrere Dokumente enthalten können, wobei zu jedem nativen
CAD–Format die entsprechende TIF–
Datei zum betrachten angehängt sein
muss. Wir unterscheiden zwischen AutoCAD, CCD und ProE, sowie den restlichen Dokumenttypen.
Sollte es sich also um eines der genannten nativen Datenformate handeln, muss
überprüft werden, ob die zugehörigen
TIF–Dateien vorhanden sind. Ist dies der
Fall, so kann der normale Synchronisierungsprozess, so wie er bisher abgelaufen
ist angestoßen werden. Im umgekehrten
Fall, wird davon ausgegangen, dass sich
die TIF–Datei noch im Erstellungsprozess befindet.
Somit muss erneut überprüft werden, ob die TIF–Datei zu einem späteren Zeitpunkt
vorhanden ist. Der betroffene Dokumentstamm wird in einer Tabelle zur Wiedervorlage
gespeichert, zusammen mit dem Timestamp der Suche und einem initialen Counter. Der
Counter wird verwendet um die Dateien nur einer gewissen Anzahl an Nachprüfungen
zu unterziehen. Liegt beispielsweise nach der dritten Vorlage die gewünschte Datei immer
noch nicht vor, so kann man davon ausgehen, dass die Vertiffung auf einen Fehler gelaufen
ist. Sie wird somit in einem Fehlerbericht gemeldet. Der Timestamp wird benötigt, um
dem Prozess die Zeit zu geben die er benötigt und nicht pro Aufruf der Funktion, die im
Minutentakt stattfindet, den Counter zu dekrementieren.
6.3. Implementierung
Das Programm wird direkt an die Schnittstelle AXA2FASys angebunden und innerhalb
der Oracle Datenbank implementiert. Als Programmiersprache wurde PL/SQL verwendet. Im Folgenden werden die essentiellen Programmteile vorgestellt, wohingegen in Anhang A.1 der komplette Quellcode verfügbar ist.
Da der Dokumentabgleich in eine bestehende Schnittstelle eingebaut werden muss, wird
er aus Gründen der Übersichtlichkeit in mehrere Subprogramme, bestehend aus Prozeduren und Funktionen, unterteilt. Der erste Schritt besteht darin nur die Materialnummern
111
6. Umsetzung
zu untersuchen, die zwischen Axalant und FATool synchronisiert werden. Im nächsten
Schritt wird die SAP –Transfer–Queue ausgelesen und nach entsprechenden Dokumentänderungen durchsucht. Eine originalgetreue Abbildung der SAP –Transfer–Queue ist im
Anhang A.2 in Abbildung A.5 zu sehen. Diese Prozedur liefert dann eine Materialnummer, die mit der im ersten Schritt angelegten Tabelle abgeglichen wird. Für die gefundenen
Materialnummern werden in einem dritten Schritt die verknüpften Dokumentstämme gesucht und überprüft, ob es sich um einen „Vertiffungsprozess“ handelt. Ist dies der Fall
und ist der Vertiffungsprozess noch nicht abgeschlossen, so wird der Dokumentstamm zur
erneuten Überprüfung gespeichert. Die Wiedervorlage stellt den letzten Schritt dar.
In Abbildung 6.2 ist links der bisherige Prozess des Dokumentabgleichs dargestellt und
rechts der angepasste Prozess. Wie zu erkennen ist werden die bereits bestehenden Funktionen verwendet und die neuen Prozeduren und Funktionen nur zwischengeschaltet.
Abbildung 6.2.: Alter (links) und neuer (rechts) Prozess des Dokumentabgleich
Die Prozedur CADIM_CICS_PROC_NEU_P8 wird von einem Task zeitgesteuert in einem bestimmten Intervall aufgerufen. Sie ist zuständig für die Auftragsliste (Datenexport) und reagiert somit auf Statuswechsel am Material, wobei die angehängten
Dokumentstämme berücksichtigt werden und je nach Dokumenttyp die entsprechenden Funktionen aufgerufen werden. Von besonderem Interesse ist dabei die Funktion
COPY_TO_AXA_MAT_FILE_DAT, die für die Übertragung der TIF–Dokumente verantwortlich ist und auf die wegen dem „Vertiffungsprozess“ gesondert eingegangen werden muss.
Im neuen Prozess kommt die Prozedur AXA_MAT_FILE_BPM_DOC hinzu, die auf Änderungen am Dokumentstamm reagiert, indem die SAP –Transfer–Queue geparst wird. Für den
gesonderten Fall der „Vertiffung“ kümmert sich nun die Funktion AXA_SEARCH_DOC_DAT,
indem bei Native–Dateien die zugehörigen TIF–Dateien gesucht werden. Falls diese nicht
gefunden werden, kommt der Dokumentstamm in eine Tabelle zur erneuten Vorlage. Um
112
6.3. Implementierung
diese Wiedervorlage kümmert sich die Funktion AXA_CHECK_REPEAT. Damit nur die Dokumentstämme aktualisiert werden, deren Materialstamm zwischen den Systemen synchronisiert wird, wird einmalig die Prozedur AXA_MAT_FILE_CPY_ART aufgerufen, die eine
entsprechende Tabelle generiert.
Im Folgenden wird auf die einzelnen Programme eingegangen, wobei sich der Abschnitt
„Synchronisation von Materialien“ mit der Prozedur AXA_MAT_FILE_CPY_ART, „Parsen der
Transfer–Queue“ mit der Prozedur AXA_MAT_FILE_BPM_DOC, „Suche nach Dokumentstämmen“ mit der Funktion AXA_SEARCH_DOC_DAT und „Überprüfen der Wiedervorlage“ mit
der Funktion AXA_CHECK_REPEAT beschäftigt.
6.3.1. Synchronisation von Materialien
Da die Transfer–Queue, deren Einträge als auslösendes Ereignis für die Aktualisierung
von Dokumenten dienen, auch Einträge enthält, die nicht zwischen FATool und Axalant
synchronisiert werden, muss zunächst überprüft werden, ob der gefundene Eintrag für den
Dokumentabgleich relevant ist. Um dies zu bewerkstelligen wird eine Tabelle angelegt, die
G4DBA.AXA_MAT_FILE_BPM_DOC_CUR
alle Materialien
enthält, die zwischen den Systemen ausgetauscht werden.
P * ID
NUMBER (10)
* C_TIME
DATE
Es existiert
bereits (ID)
eine Log–Tabelle, die alle übertragenen Materialien protokolliert. So
BPMDOC_CUR_PK
muss diese
Tabelle einfach
nur auf unterschiedliche Materialnummern ausgewertet werden
BPMDOC_CUR_PK
(ID)
BPMDOC_CUR_IDX (C_TIME)
und in eine neue Tabelle geschrieben werden. Für die Spalte „Materialnummer“ wird ein
Index angelegt, da in der produktiven Umgebung bereits mehr als 160.000 Materialien
synchronisiert werden.
G4DBA.AXA_MAT_FILE_BPM_DOC_ART
P * ID
* C_ID
* PART_ID
EDB_ID
NUMBER (10)
NUMBER (10)
VARCHAR2 (40 CHAR)
VARCHAR2 (40 CHAR)
BPMDOC_ART_PK (ID)
BPMDOC_ART_PK (ID)
BPMDOC_ART_IDX (PART_ID)
Abbildung 6.3.: Tabelle von synchronisierten Materialien
G4DBA.AXA_MAT_FILE_BPM_DOC_ERROR
G4DBA.AXA_MAT_FILE
In
Abbildung
6.3
ist
das
ScheID
NUMBER (10)
P * ID
NUM
ma
derNUMBER (10)
Synchronisations–Tabelle
C_ID
* DOC_ID
VARC
ERROR
VARCHAR2 (200 CHAR)
* PART_ID
VARC
AXA_MAT_FILE_BPM_DOC_ART
dargestellt.
C_TIME
DATE
* C_TIME
DATE
Die
ID ist der
Primärschlüssel
der Tabelle
DOCUMENT_ID
VARCHAR2
(40 CHAR)
* PROCESSED
NUM
DOC_VERSION
VARCHAR2 (10
CHAR)
EDB_ID
VARC
und
wird verwendet
um
die Zeilen eindeutig
DOC_VERSION
VARC
BPMDOC_ERROR_PK
identifizieren (ID)
zu können. Die Spalte C_ID
BPMDOC_PK (ID)
BPMDOC_ERROR_PK
enthält den (ID)
Fremdschlüssel zur Axalant–
BPMDOC_PK (ID)
Tabelle T_MASTER_DAT, die Informationen zu
den Materialstämmen enthält.
P *
*
*
*
Des Weiteren die PART_ID, also die Materialnummer mit dem Nummernschema
AA00.123.456 und die EDB_ID, ein systemweit eindeutiger Identifier für Tabellenzeilen,
der allerdings optional ist. Der komplette Quellcode dieser Prozedur sowie das Anlegen
der benötigten Tabellen und Indizes kann in Anhang A.1.1 eingesehen werden.
6.3.2. Parsen der Transfer–Queue
Die Prozedur AXA_MAT_FILE_BPM_DOC wird, wie in Abbildung 6.2 dargestellt, zeitgesteuert
aufgerufen und bedient sich der eben erzeugten Tabelle zum Abgleich der Materialnum-
113
6. Umsetzung
mern. Sie liefert die Materialstämme zu den gefundenen Einträgen der Transfer–Queue
und stößt über den Aufruf von Funktionen den eigentlichen Dokumentabgleich an.
Die Materialnummer wird an die bisher bestehenden Funktionen übergeben, die aufgerufen wurden, falls ein Statuswechsel am Material durchgeführt wurde. Der Unterschied
zum bisherigen Abgleich ist, dass nun die Dokumente das auslösende Ereignis darstellen,
aber trotzdem der gesamte Materialstamm mit allen verknüpften Dokumentstämmen aktualisiert wird. Diese Funktionen aktualisieren wie bisher die Daten und Dokumente im
entsprechenden FATool –Zielsystem. Für die Dokumentstämme stehen drei verschiedene
Funktionen bereit, die für verschiedene Dokumenttypen ausgelegt sind. Es werden initial
alle drei Funktionen aufgerufen, da sie selbst überprüfen, ob der vorliegende Dokumentenstamm den jeweils richtigen Dokumenttyp besitzt. Für den Fall der „Vertiffung“ wurde
die neue Funktion AXA_SEARCH_DOC_DAT zwischengeschaltet. Außerdem werden die Einträge aus der Wiedervorlagen–Tabelle selektiert und an die Funktion AXA_CHECK_REPEAT
übergeben.
ERROR
G4DBA.AXA_MAT_FILE_BPM_DOC_LOG
P *
*
*
*
*
CHAR)
CHAR)
CHAR)
ID
C_ID
PART_ID
C_TIME
PROCESSED
EDB_ID
DOC_VERSION
NUMBER (10)
VARCHAR2 (40 CHAR)
VARCHAR2 (40 CHAR)
DATE
NUMBER (1)
VARCHAR2 (40 CHAR)
VARCHAR2 (20 CHAR)
BPMDOC_PK (ID)
BPMDOC_PK (ID)
Abbildung 6.4.: Tabelle zum Quittieren
der Transfer–Queue
G4DBA.AXA_MAT_FILE_BPM_DOC_REPEAT
Gefundene
Einträge aus der Transfer–
ID
NUMBER (10)
Queue
werden
in (10)
eine Tabelle eingetraC_ID
NUMBER
REMAIN
(1)
gen,
um zu NUMBER
überprüfen,
ob die ÜbergaC_TIME
DATE
beDOCUMENT_ID
erfolgreich VARCHAR2
war. Wir
nennen die Tabelle
(40 CHAR)
DOC_VERSION
VARCHAR2 (10 CHAR)
AXA_MAT_FILE_BPM_DOC_LOG
daher Quittie* C_ID_1
NUMBER (10)
rungstabelle.
Die
Tabelle
besitzt eine ID als
* PART_ID
VARCHAR2
(40 CHAR)
* WORKTAN
NUMBER (10)
Primärschlüssel.
Die Spalte C_ID enthält die
* NATIVE_FILES
NUMBER
ID des Materialstamms und PART_ID die MaBPMDOC_REPEAT_PK (ID)
terialnummer. C_TIME beinhaltet den TimeBPMDOC_REPEAT_PK (ID)
stamp
zur Ausführung des Cursors.
BPMDOC_REPEAT_IDX (C_ID)
P *
*
*
*
Die Spalte PROCESSED enthält eine 1, wenn die Übergabe erfolgreich war, ansonsten eine
0. Die Spalten EDB_ID und DOC_VERSION sind optional und beinhalten den systemweiten
Identifier und die Version des Dokuments.
Damit nicht bei jedem Suchlauf die komplette Transfer–Queue durchsucht werden
muss und so Materialien mehrfach an die
Funktionen übergeben werden, muss der
Timestamp des letzten Cursor–Aufrufs gespeichert werden. Hierzu dient die Tabelle AXA_MAT_FILE_BPM_DOC_CUR. Sie besitzt
nur eine Spalte für die ID und eine Spalte
C_TIME für den Timestamp, der indexiert
ist.
G4DBA.AXA_MAT_FILE_BPM_DOC_CUR
P * ID
* C_TIME
NUMBER (10)
DATE
BPMDOC_CUR_PK (ID)
BPMDOC_CUR_PK (ID)
BPMDOC_CUR_IDX (C_TIME)
Abbildung 6.5.: Tabelle zum Speichern des
Cursor–Timestamps
G4DBA.AXA_MAT_FILE_BPM_DOC_ART
P * ID
* C_ID
* PART_ID
EDB_ID
NUMBER (10)
NUMBER (10)
VARCHAR2 (40 CHAR)
VARCHAR2 (40 CHAR)
Der Quellcode der Prozedur und die Befehle zum Erstellen der Tabellen sind im Anhang A.1.2 zu finden.
BPMDOC_ART_PK (ID)
BPMDOC_ART_PK (ID)
BPMDOC_ART_IDX (PART_ID)
G4DBA.AXA_MAT_FIL
P *
*
*
*
ID
C_ID
ERROR
C_TIME
DOCUMENT_ID
DOC_VERSION
NU
NU
VA
DA
VA
VA
BPMDOC_ERROR_PK (I
BPMDOC_ERROR_PK (I
114
6.3. Implementierung
6.3.3. Suche nach Dokumentstämmen
Die Funktion AXA_SEARCH_DOC_DAT wird von der Prozedur AXA_MAT_FILE_BPM_DOC aufgerufen und stellt den Zwischenschritt dar, der die „Vertiffung“ von nativen CAD–Dateien berücksichtigt. Als Eingabe erhält sie eine Materialnummer, woraufhin die verknüpften Dokumentstämme gesucht und ausgewertet werden. Der detaillierte Programmablauf kann
in Abbildung 6.6 eingesehen werden.
Abbildung 6.6.: Programmablauf zur Überprüfung von Dokumentstämmen
Jeder gefundene Dokumentstamm wird überprüft, beginnend mit der Auswertung des
Dokumenttyps. Handelt es sich hierbei um ein Native–Format (AutoCAD, CCD, ProE)
so wird verifiziert, ob der Dokumentstamm tatsächlich eine Native–Datei beinhaltet. Dies
geschieht mit Hilfe der Dateiendungen DRW, DWG und CDD. Ist im Dokumentstamm weniger als eine native Datei vorhanden, so führt dies wegen des Dokumenttyps zu einem
sofortigen Fehler. Dieser Fehler wird in einer entsprechenden Fehlertabelle protokolliert.
Handelt es sich um keinen nativen Dokumenttyp kann der Dokumentstamm zur sofortigen
Synchronisierung übergeben werden.
Im Normalfall hat ein solcher Dokumentstamm mehr als eine native Datei, sodass anschließend die Anzahl der TIF–Dateien ermittelt wird. Es sollten mindestens so viele
TIF–Dateien vorhanden sein wie Native–Dateien, denn jede native Datei wird mit mindestens einem TIF dargestellt. Da native Dateien aber auch aus mehreren Seiten bestehen
können, ist es auch zulässig, wenn mehr TIF als native Dateien vorhanden sind. In diesem
Fall stimmt das Verhältnis und es wird die normale Synchronisation angestoßen. Sind
allerdings weniger TIF als Native–Dateien vorhanden, ist dies entweder auf einen Fehler
oder auf den nicht fertiggestellten „Vertiffungsprozess“ zurückzuführen. So muss dieser
Dokumentstamm in die Wiedervorlage eingetragen werden, da die TIF–Grafiken zeitverzögert im System ankommen können. Bei der Wiedervorlage werden vordefinierte Werte
für die maximale Anzhal an Wiedervorlagen und ein Timestamp eingetragen, sodass diesem Prozess ein bestimmtes Zeitintervall bis zu seiner Beendigung zur Verfügung gestellt
115
G4DBA.AXA_MAT_FILE_BPM_DOC_CUR
P * ID
* C_TIME
NUMBER (10)
DATE
BPMDOC_CUR_PK (ID)
6. Umsetzung
BPMDOC_CUR_PK (ID)
BPMDOC_CUR_IDX (C_TIME)
wird.
G4DBA.AXA_MAT_FILE_BPM_DOC_ART
Die Fehlertabelle AXA_MAT_FILE_BPM_DOC_ERROR
P * ID
NUMBER (10)
* C_ID eigenen
NUMBER ID
(10) die C_ID
beinhaltet neben einer
* PART_ID
VARCHAR2 (40 CHAR)
des DokumentstammsEDB_ID
aus der
Axalant–Tabelle
VARCHAR2 (40 CHAR)
T_DOC_DAT als Fremdschlüssel
und eine SpalBPMDOC_ART_PK (ID)
te ERROR, die als String
den Fehler
beschreiben
BPMDOC_ART_PK
(ID)
BPMDOC_ART_IDX (PART_ID)
soll. Der Timestamp des Cursors wird in C_TIME
gespeichert. Zusätzliche, aber nicht notwendige,
Informationen sind die DOCUMENT_ID und die
DOC_VERSION.
G4DBA.AXA_MAT_FILE_BPM_DOC_ERROR
P *
*
*
*
ID
C_ID
ERROR
C_TIME
DOCUMENT_ID
DOC_VERSION
NUMBER (10)
NUMBER (10)
VARCHAR2 (200 CHAR)
DATE
VARCHAR2 (40 CHAR)
VARCHAR2 (10 CHAR)
BPMDOC_ERROR_PK (ID)
BPMDOC_ERROR_PK (ID)
G4DBA.AXA_MAT_FILE_BPM_DOC_REPEAT
P *
*
*
*
CHAR)
CHAR)
CHAR)
CHAR)
*
*
*
*
ID
C_ID
REMAIN
C_TIME
DOCUMENT_ID
DOC_VERSION
C_ID_1
PART_ID
WORKTAN
NATIVE_FILES
NUMBER (10)
NUMBER (10)
NUMBER (1)
DATE
VARCHAR2 (40 CHAR)
VARCHAR2 (10 CHAR)
NUMBER (10)
VARCHAR2 (40 CHAR)
NUMBER (10)
NUMBER
BPMDOC_REPEAT_PK (ID)
BPMDOC_REPEAT_PK (ID)
BPMDOC_REPEAT_IDX (C_ID)
Abbildung 6.8.: Tabelle
vorlage
zur
Wieder-
Abbildung 6.7.: Fehlertabelle der
Wiedervorlage
Die DOCUMENT_ID und die DOC_VERSION können als zusätzliche Information gespeichert
werden, allerdings optional. Für den Aufruf
der eigentlichen Update–Funktion benötigen
wir die C_ID_1 (ID des Materialstamms), die
PART_ID (zugehörige Materialnummer), die
ursprünglich erstellte WORKTAN zur Statuskontrolle und die Anzahl der nativen CAD–
Dateien, damit diese bei der Wiedervorlage nicht erneut gezählt werden müssen. Diese Informationen werden aus der Axalant–
Tabelle T_MASTER_DAT abgerufen.
Da die meisten Joins über die C_ID der Tabelle gemacht werden, wird hierfür ein Index erstellt, um den Zugriff zu beschleunigen. Der komplette Quellcode der Funktion
AXA_SEARCH_DOC_DAT sowie die zugehörigen Tabellen sind im Anhang A.1.3 zu finden.
6.3.4. Überprüfen der Wiedervorlage
Die Funktion AXA_CHECK_REPEAT wird ebenfalls von der Prozedur AXA_MAT_FILE_BPM_DOC
aufgerufen und zwar mit allen Werten, die sich zu diesem Zeitpunkt in der
Wiedervorlagen–Tabelle befinden. Als Eingabe reicht dieser Funktion die ID der
Wiedervorlagen–Tabelle, da so alle Einträge eindeutig identifizierbar sind und alle anderen Werte referenzierbar werden. In Abbildung 6.9 ist der detaillierte Programmablauf
der Wiedervorlage dargestellt.
116
ID
DOC_ID
PART_ID
C_TIME
PROCESSED
EDB_ID
DOC_VERSIO
BPMDOC_PK
BPMDOC_PK
Die Tabelle zur Wiedervorlage von Dokumentstämmen beinhaltet neben der ID als Primärschlüssel, die C_ID des Dokumentstamms (T_DOC_DAT), die Anzahl der restlichen Versuche REMAIN und den Timestamp des Cursor–Aufrufs in C_TIME.
C_LOG
G4DBA.AXA
P *
*
*
*
*
6.3. Implementierung
Der erste Schritt besteht in der Auswertung der Anzahl an TIF–Dateien unabhängig von
Counter und Timestamp. Dies gewährleistet eine schnellstmögliche Wiederherstellung der
Konsistenz zwischen den Systemen. Für den Fall, dass die „Vertiffung“ inzwischen abgeschlossen ist und somit entsprechend viele TIF–Dateien vorhanden sind, wird der Eintrag
aus der Tabelle der Wiedervorlage gelöscht und kann nun durch Aufruf der Update–
Funktion mit FATool synchronisiert werden.
Abbildung 6.9.: Programmablauf der Wiedervorlage
Andernfalls muss überprüft werden, ob der Timestamp bereits abgelaufen ist. Dabei wird
der aktuelle Timestamp erzeugt und die Differenz zu dem des Cursor–Aufrufs gebildet.
Das Standardintervall ist mit zehn Minuten angegeben und kann innerhalb der Funktion
geändert werden. Ist das Intervall noch nicht überschritten, so wird dieser Dokumentenstamm übersprungen. Für bereits abgelaufene Timestamps wird als nächster Schritt der
Counter für die Wiedervorlagen geprüft. Als Standard wurden hier maximal drei Wiedervorlagen gewählt. Ist der Counter größer als Null, so wird er dekrementiert und der
aktuelle Timestamp gesetzt, sodass wieder zehn Minuten gewartet wird bis der Counter
erneut herabgesetzt werden kann. Falls der Counter bereits auf Null steht, wird angenommen, dass der „Vertiffungsprozess“ gescheitert ist. Es wird dann ein Eintrag in der
Fehlertabelle erstellt und abschließend der Eintrag aus der Wiedervorlage entfernt.
Der komplette Quellcode der Funktion kann im Anhang A.1.4 eingesehen werden.
117
6. Umsetzung
6.4. Verifikation
Das Testen von Software besteht in der Regel aus einer Verifikation und einer Validierung.
Die Verifikation wird zur Überprüfung auf Korrektheit der durchgeführten Aktivität verwendet, wobei die Beschreibung des Systems funktionell äquivalent zu ihrer Ausgabe sein
muss. Die Validierung ist als eine Überprüfung auf Korrektheit mit Bezug auf die Kundenanforderungen zu sehen. In unserem Fall sind die Anforderungen an das System genau
spezifiziert und es ist daher eine Verifikation durchzuführen. Im folgenden sind die einzelnen Testfälle aufgeschlüsselt.
1. Testfall: Statuswechsel am Dokument
Voraussetzungen
• Eintrag in der Transfer–Queue
• Materialstamm–ID ist in der Sync–Tabelle eingetragen
Erwartungen
• Prozedur findet richtigen Materialstamm zum gefunden Eintrag der Queue
• Eintrag in Log–Tabelle wird erstellt
Beschreibung
Dieser Testfall überprüft, ob Änderungen am Dokumentstamm nachvollzogen werden, ohne dass eine Änderung am Materialstamm vorausgeht.
Die Prozedur AXA_MAT_FILE_BPM_DOC durchsucht die SAP –Transfer–Queue
nach passenden Einträgen und übergibt diese an die Update–Funktionen,
falls die Materialstamm–ID zu den synchronisierten Materialien zählt.
Falls passende Einträge gefunden werden, sollte in der Quittierungstabelle
AXA_MAT_FILE_BPM_DOC_LOG ein Eintrag erstellt werden.
2. Testfall: Normale Synchronisation ohne Native
Voraussetzungen
• Kein Nativeformat im Dokumenttyp
Erwartungen
• Aufruf der Update–Funktion
Beschreibung
Da es sich bei der Funktion AXA_SEARCH_DOC_DAT nur um einen Zwischenschritt handelt und eigentlich auf den „Vertiffungsprozess“ bei Native–
Formaten reagiert werden soll, muss getestet werden ob Dokumentstäm-
118
6.4. Verifikation
me mit einem anderem Dokumenttyp sofort an die Update–Funktion
COPY_TO_AXA_MAT_FILE_DAT weitergegeben werden.
3. Testfall: Fehler durch nicht vorhandene Native–Datei
Voraussetzungen
• Nativeformat im Dokumenttyp
• Keine Native–Datei vorhanden
Erwartungen
• Sofortiger Eintrag in die Fehlertabelle
Beschreibung
Ist der Dokumenttyp als Native angegeben, so muss der Dokumentstamm mindestens eine Native–Datei enthalten. Dies wird in der AXA_SEARCH_DOC_DAT
überprüft und sollte im negativen Fall zu einem sofortigen Fehler führen. Außerdem wird ein Eintrag in der Fehlertabelle AXA_MAT_FILE_BPM_DOC_ERROR
angelegt.
4. Testfall: Vertiffungsprozess nicht abgeschlossen
Voraussetzungen
• Nativeformat im Dokumenttyp
• Native–Datei vorhanden
• Anzahl der TIF–Dateien zu gering
Erwartungen
• Eintrag in die Wiedervorlagen–Tabelle
• Setzte Counter initial auf 3
• Setze Timestamp zum Aufruf des Cursors
Beschreibung
Für jede Native–Datei muss mindestens eine TIF–Datei im Dokumentstamm
vorhanden sein. Da es mehrblättrige CAD–Dokumente gibt, wird durch die
Funktion AXA_SEARCH_DOC_DAT ausschließlich überprüft, ob die Anzahl an TIF–
Dateien größer oder gleich der Anzahl an Native–Dateien ist.
119
6. Umsetzung
5. Testfall: Vertiffungsprozess abgeschlossen
Voraussetzungen
• Nativeformat im Dokumenttyp
• Native–Datei vorhanden
• Ausreichende Anzahl an TIF–Dateien vorhanden
Erwartungen
• Aufruf der Update–Funktion
Beschreibung
Sind mindestens so viele TIF–Dateien wie Native–Dateien im Dokumentstamm
enthalten, so ist der „Vertiffungsprozess“ entweder abgeschlossen oder es wurden Dokumente neu angelegt oder ersetzt. In diesem Fall wird direkt aus
AXA_SEARCH_DOC_DAT die Funktion COPY_TO_AXA_MAT_FILE_DAT aufgerufen
und somit die Synchronisation des zugehörigen Materialstamms veranlasst.
6. Testfall: Wiedervorlage und Delay nicht verstrichen
Voraussetzungen
• Anzahl der TIF–Dateien zu gering
• Delay nicht überschritten
Erwartungen
• Überspringen des Dokumentstamms
Beschreibung
Die Funktion AXA_CHECK_REPEAT wird für Eintrage aus der Wiedervorlagen–
Tabelle in kurzen Zeitabständen aufgerufen. Somit dürfte der übergebene
Dokumentstamm zwar überprüft werden, ob der „Vertiffungsprozess“ inzwischen abgeschlossen ist, allerdings darf der zugehörige Counter in der Tabelle
AXA_MAT_FILE_BPM_DOC_REPEAT nicht dekrementiert werden, solange der Zeitunterschied zwischen dem letzten und dem aktuellen Aufruf das voreingestellte
Delay nicht überschritten hat.
120
6.4. Verifikation
7. Testfall: Wiedervorlage und Delay verstrichen
Voraussetzungen
• Anzahl der TIF–Dateien zu gering
• Delay überschritten
• Ausreichende Anzahl an Wiedervorlagen
Erwartungen
• Dekrementiere Counter
• Setzte neuen Timestamp auf Zeitpunkt des Funktionsaufrufs
Beschreibung
Hat der Zeitunterschied zwischen dem letzten und dem aktuellen Aufruf das
Delay überschritten und der „Vertiffungsprozess“ ist noch nicht abgeschlossen,
so muss der zum Dokumentstamm zugehörige Counter in der Wiedervorlagen–
Tabelle ausgewertet werden. Für den Fall, dass dieser größer als Null ist, wird
er dekrementiert und der Timestamp auf den Zeitpunkt des Funktionsaufrufs
aktualisiert.
8. Testfall: Wiedervorlage und Counter abgelaufen
Voraussetzungen
• Anzahl der TIF–Dateien zu gering
• Delay überschritten
• Wiedervorlagen–Counter abgelaufen
Erwartungen
• Lösche den Dokumentstamm aus der Wiedervorlage
• Erstelle einen Eintrag in der Fehlertabelle
Beschreibung
Dem „Vertiffungsprozess“ wird generell eine bestimmte Anzahl an Wiedervorlagen gewährt, zwischen denen ein bestimmtes Zeitintervall eingehalten wird,
bis der Counter dekrementiert werden darf. Ab einem bestimmten Punkt muss
man davon ausgehen, dass der Prozess gescheitert ist. Dies ist der Fall, wenn
der Counter abgelaufen ist und die Funktion AXA_CHECK_REPEAT daraufhin den
Wert aus der Wiedervorlagen–Tabelle löscht und in die Fehlertabelle einträgt.
So werden erneute Aufrufe von Dokumentstämmen mit abgelaufenen Counter
verhindert und ein Bericht des Problems erstellt.
121
6. Umsetzung
9. Testfall: Wiedervorlage und Vertiffungsprozess erfolgreich
Voraussetzungen
• Ausreichende Anzahl an TIF–Dateien vorhanden
Erwartungen
• Löschen aus der Wiedervorlage
• Aufruf der Update–Funktion
Beschreibung
Wird ein Dokumentstamm aus der Wiedervorlage aufgerufen und die Funktion AXA_CHECK_REPEAT stellt fest, dass inzwischen eine ausreichende Anzahl
an TIF–Dateien vorliegt, so wird davon ausgegangen, dass der „Vertiffungsprozess“ erfolgreich war. In diesem Fall wird der Eintrag aus der Wiedervorlage gelöscht und die Update–Funktion COPY_TO_AXA_MAT_FILE_DAT aufgerufen und
der entsprechende Materialstamm mit FATool synchronisiert.
122
7. Fazit
Die Aufgabenstellung konnte im vorgegebenen Zeitrahmen von sechs Monaten erfolgreich
umgesetzt werden. Nach einer Übersicht über alle in der ZF eingesetzten Systeme, wurde der Ist–Zustand hinsichtlich FATool und dem Nachbarsystem Axalant analysiert und
dokumentiert. Dabei konnten elf Schwachstellen festgestellt und priorisiert werden. Für
alle funktionalen Anforderungen werden Lösungskonzepte aufgezeigt. Die Analyse nicht–
funktionaler Anforderungen war nicht Bestandteil dieser Arbeit. Viele der gefundenen
Schwachstellen können durch einfache Änderungen an den beteiligten Prozessen gelöst
werden. Das bestehende Soll–Konzept setzt bereits die wichtigsten Anforderungen um.
Eine Ausnahme bei den hoch–priorisierten Anforderungen stellen hier die Transferdaten
dar, die große Probleme bei Massenupdates und Dokumentüberrollungen verursachen.
Diesem Problem kann mit dem Verlagern der Transferdaten hin zum Axalant–Server begegnet werden, sodass diese Schwachstelle sehr einfach und zeitnah lösbar wird.
Allerdings ruft das bestehende Soll–Konzept auch neue Schwachstellen hervor. Diese konnten durch eine ausführliche Beschreibung und Analyse des Lastenhefts dargelegt werden.
Für drei von fünf gefundenen Schwachstellen konnte immerhin ein vollständiges Lösungskonzept vorgelegt werden. Das Berechtigungskonzept wurde dabei am intensivsten behandelt, da es den Zugriff auf sicherheitsrelevante Daten steuert. Hierzu wurde in mehreren
Schritten ein funktionierendes Berechtigungskonzept, nach einer Analyse der Anforderungen, für FATool spezifiziert. Für dieses System werden die Berechtigungen aus Axalant
verwendet, das weiterhin als zentrale Datenquelle für FATool fungiert. Dort wird ein
mehrstufiges Berechtigungssystem bereitgestellt, das die Anforderungen von FATool weit
übersteigt, sodass nur ein Minimum an Berechtigungen portiert werden muss. Für den
sinnvollen Einsatz der untersuchten Berechtigungen wurde sowohl für das Sichten als auch
für das Verändern von Daten ein Berechtigungskonzept vorgelegt. Auch Schwierigkeiten
bei der Umsetzung des Berechtigungsprozesses wurden berücksichtigt und gesondert behandelt. Neben Lösungskonzepten zu den Schwachstellen wurden auch Anforderungen im
eigens entwickelten erweiterten Lastenheft spezifiziert, die durch das bestehende Lastenheft nicht abgedeckt sind.
Der praktische Teil der Ausarbeitung beinhaltete die Umsetzung eines Arbeitspaketes des
zentralen FATool –Projekts. Hierbei handelt es sich um den Dokumentabgleich, den die
Schnittstelle zwischen Axalant und FATool bisher nur bedingt unterstützte. Nur bei der
Durchführung eines Statuswechsels am Materialstamm sind auch die verknüpften Dokumentstämme aktualisiert worden. Die Unterstützung direkter Änderungen an den Dokumenten war jedoch nicht gegeben. Weiterhin sind diese Änderungen in Axalant schwer
feststellbar, sodass zunächst eine Tabelle gefunden werden musste, die das gewünschte Er-
123
7. Fazit
eignis protokolliert, um darauf entsprechend reagieren zu können. Ein weiteres Problem,
das berücksichtigt werden musste, war der Plotprozess zum Erzeugen von TIF–Grafiken,
die zum Sichten von Native–Dateien Verwendung finden. Da diese von einem externen
Prozess erstellt werden, sind die Dateien bereits logisch in der Datenbank vorhanden,
auch wenn sie physisch noch nicht auf der Festplatte vorliegen. Der Dokumentabgleich
konnte nahtlos in die bestehende Schnittstelle eingeführt und durch ausführliche Tests
validiert werden.
Diese Arbeit erfüllt alle zum Ziel gesetzten Anforderungen. Die vorhandenen Konzepte
wurden untersucht und eigene Konzepte entwickelt. Das Lastenheft wurde in allen Punkten, die dem Leser große Einsicht in das Projekt abverlangen, dokumentiert und somit die
nötige Transparenz geschaffen. Im Hinblick auf die ZF–interne Schnittstelle AXA2Fasys
konnte eine Weiterentwicklung erreicht werden, die durch zahlreiche Tests jederzeit produktiv einsetzbar ist. Insgesamt hat diese Arbeit dazu beigetragen die Effektivität und
die Effizienz hinsichtlich der Zentralisierung zu steigern.
124
A. Anhang
A.1. Quelltext des Dokumentabgleich
A.1.1. AXA_MAT_FILE_BPM_DOC_ART
Zunächst muss die Tabelle zum Abgleich der Materialnummern erzeugt werden.
1
2
3
4
5
6
CREATE TABLE AXA_MAT_FILE_BPM_DOC_ART (
ID NUMBER(10) NOT NULL,
C_ID NUMBER(10) NOT NULL,
PART_ID VARCHAR2(40 CHAR) NOT NULL,
EDB_ID VARCHAR2(40 CHAR),
CONSTRAINT bpmdoc_art_pk PRIMARY KEY (ID));
Die ID der Tabelle soll eindeutig sein und automatisch generiert werden.
1
2
3
CREATE SEQUENCE bpmdoc_art_seq
START WITH 1
INCREMENT BY 1;
Bei einem Eintrag in die Tabelle soll für die ID der Wert automatisch abgerufen und
eingefügt werden.
1
2
3
4
5
6
7
8
CREATE OR REPLACE TRIGGER bpmdoc_art_bir
BEFORE INSERT ON AXA_MAT_FILE_BPM_DOC_ART
FOR EACH ROW
BEGIN
SELECT bpmdoc_art_seq.NEXTVAL
INTO :NEW.ID
FROM dual;
END;
Die PART_ID nach der gesucht wird, soll einen eindeutigen Index erhalten.
1
CREATE UNIQUE INDEX bpmdoc_art_idx ON AXA_MAT_FILE_BPM_DOC_ART (PART_ID);
Die Prozedur selektiert alle unterschiedlichen Materialnummern aus der bestehenden Log–
Tabelle und fügt diese in die Synchronisations–Tabelle ein. Da auf PART_ID ein eindeutiger
Index gesetzt ist, wird bei bereits bestehenden Einträgen ein Fehler geworfen.
125
A. Anhang
1
2
CREATE OR REPLACE
PROCEDURE AXA_MAT_FILE_CPY_ART AS
3
4
5
6
-- Cursor sammelt alle unterschiedlichen Materialnummern in AXA_GRP_ART
CURSOR CUR_GET_PART_ID IS
SELECT DISTINCT PART_ID, C_ID_2 FROM AXA_GRP_ART;
7
8
9
10
11
12
13
14
15
16
17
18
19
20
BEGIN
FOR REC_GET_PART_ID IN CUR_GET_PART_ID
LOOP
BEGIN
INSERT INTO AXA_MAT_FILE_BPM_DOC_ART (C_ID, PART_ID) VALUES (
REC_GET_PART_ID.C_ID_2, REC_GET_PART_ID.PART_ID);
EXCEPTION
WHEN DUP_VAL_ON_INDEX
THEN
DBMS_OUTPUT.put_line(’SKIPPING IDX ’ || REC_GET_PART_ID.PART_ID ||
’! Already exists.’);
END;
END LOOP;
COMMMIT;
END AXA_MAT_FILE_CPY_ART;
A.1.2. AXA_MAT_FILE_BPM_DOC
Um die gefundenen Datensätze quittieren zu können, wird eine Tabelle benötigt.
1
2
3
4
5
6
7
8
9
CREATE TABLE AXA_MAT_FILE_BPM_DOC_LOG (
ID NUMBER(10) NOT NULL,
DOC_ID VARCHAR2(40 CHAR) NOT NULL,
PART_ID VARCHAR2(40 CHAR) NOT NULL,
C_TIME DATE NOT NULL,
PROCESSED NUMBER(1) NOT NULL CHECK (PROCESSED IN (0,1)),
EDB_ID VARCHAR2(40 CHAR),
DOC_VERSION VARCHAR2(20 CHAR),
CONSTRAINT bpmdoc_pk PRIMARY KEY (ID));
Für das Inkrementieren des Primärschlüssels muss eine Sequenz erzeugt werden.
1
2
3
CREATE SEQUENCE bpmdoc_seq
START WITH 1
INCREMENT BY 1;
Für jeden Eintrag in die Tabelle soll die ID automatisch generiert und eingetragen werden.
1
2
CREATE OR REPLACE TRIGGER bpmdoc_bir
BEFORE INSERT ON AXA_MAT_FILE_BPM_DOC_LOG
126
A.1. Quelltext des Dokumentabgleich
3
4
5
6
7
8
FOR EACH ROW
BEGIN
SELECT bpmdoc_seq.NEXTVAL
INTO :NEW.ID
FROM dual;
END;
Ebenfalls muss eine Tabelle für die Timestamps der letzten Suchläufe gespeichert werden.
1
2
3
4
CREATE TABLE AXA_MAT_FILE_BPM_DOC_CUR (
ID NUMBER(10) NOT NULL,
C_TIME DATE NOT NULL,
CONSTRAINT bpmdoc_cur_pk PRIMARY KEY (ID));
Erneut wird eine Sequenz für diese Tabelle angelegt.
1
2
3
CREATE SEQUENCE bpmdoc_cur_seq
START WITH 1
INCREMENT BY 1;
Ein Trigger zum automatischen Inkrementieren des Primärschlüssels wird angelegt.
1
2
3
4
5
6
7
8
CREATE OR REPLACE TRIGGER bpmdoc_cur_bir
BEFORE INSERT ON AXA_MAT_FILE_BPM_DOC_CUR
FOR EACH ROW
BEGIN
SELECT bpmdoc_cur_seq.NEXTVAL
INTO :NEW.ID
FROM dual;
END;
Für die Timestamps muss ein Index generiert werden.
1
CREATE UNIQUE INDEX bpmdoc_cur_idx ON AXA_MAT_FILE_BPM_DOC_CUR (C_TIME);
Die Prozedur AXA_MAT_FILE_BPM_DOC beinhaltet zwei Cursor, wobei der erste die SAP –
Transfer–Queue durchsucht und zu den gefundenen Dokumentstämmen die verknüpften
Materialstämme selektiert. Der zweite Cursor liefert alle Einträge aus der Wiedervorlagen–
Tabelle. In der ersten Schleife wird durch den ersten Cursor iteriert und die bereits bestehenden Update–Funktionen aufgerufen, wobei die Funktion AXA_SEARCH_DOC_DAT noch
einen Zwischenschritt für TIF–Grafiken darstellt. Die zweite Schleife schickt die Ergebnisse des zweiten Cursors an die Funktion AXA_CHECK_REPEAT, die den Status der „Vertiffung“
überprüft.
1
2
CREATE OR REPLACE
PROCEDURE AXA_MAT_FILE_BPM_DOC AS
3
4
5
CUR_DATE
P_WORKTAN
DATE;
NUMBER(10);
127
A. Anhang
6
7
FAIL
CONTROL
NUMBER(1);
VARCHAR2(20 CHAR);
8
9
10
11
12
13
14
15
16
17
18
19
-- Liefert Materialnummern die zu ueberpruefen sind
CURSOR CUR_GET_PRT_ID IS
SELECT DISTINCT T_MASTER_DAT.PART_ID, T_MASTER_DAT.C_ID
FROM T_MASTER_DAT, T_MASTER_DOC, T_DOC_DAT, AXA_MAT_FILE_BPM_DOC_ART
WHERE T_MASTER_DAT.C_ID = T_MASTER_DOC.C_ID_1
AND T_MASTER_DOC.C_ID_2 = T_DOC_DAT.C_ID
AND T_MASTER_DAT.C_ID = AXA_MAT_FILE_BPM_DOC_ART.C_ID
AND T_DOC_DAT.C_ID IN (SELECT T_EER_SEN.EDB_ID FROM T_EER_SEN
WHERE T_EER_SEN.DISPATCH_TYPE=’BPM-DOC’
AND T_EER_SEN.ZF_APPLICATION = ’30’
AND T_EER_SEN.CRE_DATE > (SELECT MAX(C_TIME) FROM AXA_MAT_FILE_BPM_DOC_CUR)
);
20
21
22
23
-- Ruft die Datensaetze zur Wiedervorlage ab
CURSOR CUR_GET_RPT_ID IS
SELECT ID FROM AXA_MAT_FILE_BPM_DOC_REPEAT;
24
25
26
27
28
29
BEGIN
-- Timestamp muss erzeugt werden bevor der Cursor aufgerufen wird,
-- sodass keine Werte durchrutschen koennen. Dieser Timestamp wird
-- fuer den naechsten Durchlauf verwendet.
SELECT TO_CHAR(sysdate, ’DD.MM.YYYY HH24:MI:SS’) INTO CUR_DATE FROM dual;
30
31
32
33
34
FOR REC_PRT_ID IN CUR_GET_PRT_ID
LOOP
dbms_output.put_line(’AXA_MAT_FILE_BPM_DOC: TRANSFER QUEUE FOUND ENTRY ’
|| REC_PRT_ID.PART_ID); --DEBUG
35
-- Setze die Kontrollvariable initial auf 0.
FAIL := 0;
36
37
38
-- Generiere WorkTAN fuer die Kopierfunktionen. Jede MatNummer hat nur
-- eine WorkTAN, wenn auch 3 Funktionsaufrufe gemacht werden.
SELECT WORKTAN_SEQ.nextval INTO P_WORKTAN FROM dual;
39
40
41
42
-- Funktionsaufruf der Kopierfunktionen fuer verschiedene Dateiformate.
CONTROL := axa_search_doc_dat(REC_PRT_ID.C_ID, REC_PRT_ID.PART_ID,
P_WORKTAN);
IF CONTROL <> 0 THEN
FAIL := 1;
END IF;
43
44
45
46
47
48
128
A.1. Quelltext des Dokumentabgleich
49
50
51
52
CONTROL := copy_to_axa_mat_file_dat_pgd(REC_PRT_ID.C_ID, REC_PRT_ID.
PART_ID, P_WORKTAN);
IF CONTROL <> ’eingefuegt’ THEN
FAIL := 1;
END IF;
53
54
55
56
57
CONTROL := copy_to_axa_mat_file_dat_proe(REC_PRT_ID.C_ID, REC_PRT_ID.
PART_ID, P_WORKTAN);
IF CONTROL <> ’eingefuegt’ THEN
FAIL := 1;
END IF;
58
59
60
61
62
63
64
65
66
67
-- Kontrolliere ob ein Fehler aufgetreten ist
IF FAIL <> 0 THEN
INSERT INTO AXA_MAT_FILE_BPM_DOC_LOG (DOC_ID, PART_ID,
PROCESSED)
VALUES (REC_PRT_ID.C_ID, REC_PRT_ID.PART_ID, CUR_DATE,
ELSE
INSERT INTO AXA_MAT_FILE_BPM_DOC_LOG (DOC_ID, PART_ID,
PROCESSED)
VALUES (REC_PRT_ID.C_ID, REC_PRT_ID.PART_ID, CUR_DATE,
END IF;
END LOOP;
C_TIME,
’0’);
C_TIME,
’1’);
68
69
70
-- Timestamp einfuegen
INSERT INTO AXA_MAT_FILE_BPM_DOC_CUR (C_TIME) VALUES (CUR_DATE);
71
72
73
74
75
76
FOR REC_RPT_ID IN CUR_GET_RPT_ID
LOOP
CONTROL := AXA_CHECK_REPEAT(REC_RPT_ID.ID);
END LOOP;
77
78
79
COMMIT;
END AXA_MAT_FILE_BPM_DOC;
A.1.3. AXA_SEARCH_DOC_DAT
Zunächst muss eine Tabelle angelegt werden, die alle Dokumentstämme zur Wiedervorlage
speichert.
1
2
3
4
5
CREATE TABLE AXA_MAT_FILE_BPM_DOC_REPEAT (
ID NUMBER(10) NOT NULL,
C_ID NUMBER(10) NOT NULL,
REMAIN NUMBER(1) NOT NULL,
C_TIME DATE NOT NULL,
129
A. Anhang
6
7
8
9
10
11
12
DOCUMENT_ID VARCHAR2(40 CHAR),
DOC_VERSION VARCHAR2(10 CHAR),
C_ID_1 NUMBER(10) NOT NULL,
PART_ID VARCHAR2(40 CHAR) NOT NULL,
WORKTAN NUMBER(10),
NATIVE_FILES NUMBER NOT NULL,
CONSTRAINT bpmdoc_repeat_pk PRIMARY KEY (ID));
Für den Primärschlüssel muss eine Sequenz erzeugt werden.
1
2
3
CREATE SEQUENCE bpmdoc_repeat_seq
START WITH 1
INCREMENT BY 1;
Für jeden Tabelleneintrag soll der Primärschlüssel automatisch inkrementiert und eingetragen werden.
1
2
3
4
5
6
7
8
CREATE OR REPLACE TRIGGER bpmdoc_repeat_bir
BEFORE INSERT ON AXA_MAT_FILE_BPM_DOC_REPEAT
FOR EACH ROW
BEGIN
SELECT bpmdoc_repeat_seq.NEXTVAL
INTO :NEW.ID
FROM dual;
END;
Für die Joins auf die ID des Dokumentstamms soll ein eindeutiger Index angelegt werden.
1
CREATE UNIQUE INDEX bpmdoc_repeat_idx ON AXA_MAT_FILE_BPM_DOC_REPEAT (C_ID);
Eine Fehlertabelle soll die Einträge aus der Wiedervorlage übernehmen, falls deren Counter abgelaufen ist.
1
2
3
4
5
6
7
8
CREATE TABLE AXA_MAT_FILE_BPM_DOC_ERROR (
ID NUMBER(10) NOT NULL,
C_ID NUMBER(10) NOT NULL,
ERROR VARCHAR2(200 CHAR) NOT NULL,
C_TIME DATE NOT NULL,
DOCUMENT_ID VARCHAR2(40 CHAR),
DOC_VERSION VARCHAR2(10 CHAR),
CONSTRAINT bpmdoc_error_pk PRIMARY KEY (ID));
Die Fehlertabelle bekommt ebenfalls eine Sequenz.
1
2
3
CREATE SEQUENCE bpmdoc_error_seq
START WITH 1
INCREMENT BY 1;
Ein Trigger soll das automatische Inkrementieren übernehmen.
130
A.1. Quelltext des Dokumentabgleich
1
2
3
4
5
6
7
8
CREATE OR REPLACE TRIGGER bpmdoc_error_bir
BEFORE INSERT ON AXA_MAT_FILE_BPM_DOC_ERROR
FOR EACH ROW
BEGIN
SELECT bpmdoc_error_seq.NEXTVAL
INTO :NEW.ID
FROM dual;
END;
Die Funktion AXA_SEARCH_DOC_DAT erwartet als Eingabewerte die C_ID und PART_ID des
Materialstamms sowie die generierte WORKTAN, um den Prozess eindeutig identifizieren
zu können. Diese Werte werden in erster Linie auch gebraucht um die bereits bestehende Update–Funktion COPY_TO_AXA_MAT_FILE_DAT aufrufen zu können. Der Parameter
P_COUNT gibt die Anzahl der Wiedervorlagen an. Dies ist der Wert der initial in die
Wiedervorlagen–Tabelle geschrieben wird. Der Cursor liefert zu der übergebenen Materialnummer alle verknüpften Dokumentstämme, die den Status „6050 Freigegeben“ haben
und deren Dateien den Status „150 Freigegeben“ oder „160 In Änderung“ haben. Die Funktion liefert bei erfolgreichem Abarbeiten der übergebenen Daten eine 0 und bei Fehlern
eine 1 zurück.
1
2
CREATE OR REPLACE
FUNCTION "AXA_SEARCH_DOC_DAT" (IN_MAT_CID IN NUMBER, IN_MAT_PID IN VARCHAR2,
IN_WORKTAN_SEQ IN NUMBER)
3
4
5
RETURN NUMBER
IS
6
7
P_COUNT INTEGER := 3;
8
9
10
11
12
FILE_NUMBER INTEGER;
TIF_FILE_NUMBER INTEGER;
P_CONTROL NUMBER(1);
CUR_DATE DATE;
13
14
15
16
17
18
19
20
21
22
23
-- Liefert die Dokumentstaemme zur uebergebenen Materialnummer
CURSOR CUR_GET_IDS IS
SELECT T_DOC_DAT.* FROM T_DOC_DAT, T_MASTER_DOC
WHERE T_MASTER_DOC.C_ID_1 = IN_MAT_CID
AND T_DOC_DAT.C_ID = T_MASTER_DOC.C_ID_2
AND T_MASTER_DOC.LEV_IND = ’6050’
AND T_MASTER_DOC.C_ID > 0
AND T_DOC_DAT.C_ID > 0
AND T_DOC_DAT.DOC_TYPE<>’ZFL-PGD-DOC’
AND (T_DOC_DAT.LEV_IND=’150’ OR T_DOC_DAT.LEV_IND=’160’);
24
25
26
BEGIN
-- Initialisiere die Kontrollvariable
131
A. Anhang
27
P_CONTROL := 0;
28
29
30
FOR REC_GET_IDS IN CUR_GET_IDS
LOOP
31
-- Speichere aktuellen Timestamp
SELECT sysdate INTO CUR_DATE FROM dual;
32
33
34
-- Ueberpruefe ob ein Vertiffungsprozess beteiligt ist
IF (REC_GET_IDS.DOC_TYPE = ’AUTOCAD’)
OR (REC_GET_IDS.DOC_TYPE = ’CCD’)
OR (REC_GET_IDS.DOC_TYPE = ’DRAWFILE’ AND REC_GET_IDS.CAX_TYPE = ’DRW’)
THEN
dbms_output.put_line(’AXA_SEARCH_DOC_DAT: NATIVE DOCTYPE (’ || rec_get_ids.
c_id || ’)’); --DEBUG
35
36
37
38
39
40
41
-- Ueberpruefe ob eine NATIVE Datei vorhanden ist
SELECT COUNT(*) INTO FILE_NUMBER FROM T_DOC_FIL, T_FILE_DAT
WHERE REC_GET_IDS.C_ID = T_DOC_FIL.C_ID_1
AND T_DOC_FIL.C_ID_2 = T_FILE_DAT.C_ID
AND (T_FILE_DAT.ORG_NAME LIKE ’%.dwg’ -- AutoCAD
OR T_FILE_DAT.ORG_NAME LIKE ’%.cdd’ -- CCD
OR T_FILE_DAT.ORG_NAME LIKE ’%.drw’); -- ProE
42
43
44
45
46
47
48
49
-- Falls NATIVE vorhanden, ueberpruefe ob zugehoerige TIF Dateien vorhanden
-- Falls nicht, schreibe in Fehlertabelle
IF FILE_NUMBER >= 1
THEN
dbms_output.put_line(’AXA_SEARCH_DOC_DAT: NATIVE FILE FOUND (’ ||
rec_get_ids.c_id || ’)’); --DEBUG
50
51
52
53
54
55
-- Suche nach Anzahl der zugehoerigen TIF Dateien
SELECT COUNT(*) INTO TIF_FILE_NUMBER FROM T_DOC_FIL, T_FILE_DAT
WHERE REC_GET_IDS.C_ID = T_DOC_FIL.C_ID_1
AND T_DOC_FIL.C_ID_2 = T_FILE_DAT.C_ID
AND T_FILE_DAT.ORG_NAME LIKE ’%.tif’;
56
57
58
59
60
61
-- Falls weniger TIF als NATIVE, setze das Dokument in die Wiedervorlage
-- Falls nicht, stosse den normalen Sync-Prozess an
IF TIF_FILE_NUMBER < FILE_NUMBER
THEN
dbms_output.put_line(’AXA_SEARCH_DOC_DAT: TOO LESS TIF. INSERT IN
REPEAT. (’ || rec_get_ids.c_id || ’)’); --DEBUG
62
63
64
65
66
67
-- Datei in Wiedervorlage Tabelle eintragen!
INSERT INTO AXA_MAT_FILE_BPM_DOC_REPEAT (C_ID, REMAIN, C_TIME,
DOCUMENT_ID, DOC_VERSION, C_ID_1, PART_ID, WORKTAN, NATIVE_FILES)
68
69
132
A.1. Quelltext des Dokumentabgleich
70
VALUES (REC_GET_IDS.C_ID, P_COUNT, CUR_DATE, REC_GET_IDS.DOCUMENT_ID,
REC_GET_IDS.DOC_VERSION, IN_MAT_CID, IN_MAT_PID, IN_WORKTAN_SEQ,
FILE_NUMBER);
71
72
73
ELSE -- TIF_FILE_NUMBER >= FILE_NUMBER
dbms_output.put_line(’AXA_SEARCH_DOC_DAT: TIF EXIST. START SYNC (’ ||
rec_get_ids.c_id || ’)’); --DEBUG
74
75
76
77
78
79
80
-- Anzahl der TIF Dateien OK, stosse normalen Sync-Prozess an.
IF COPY_TO_AXA_MAT_FILE_DAT(IN_MAT_CID, IN_MAT_PID, IN_WORKTAN_SEQ, ’
insert’) <> ’eingefuegt’
THEN
P_CONTROL := 1;
END IF;
END IF; -- TIFs vorhanden?
81
82
83
ELSE -- FILE_NUMBER < 1
dbms_output.put_line(’AXA_SEARCH_DOC_DAT: NO NATIVE FOUND! ERROR! (’ ||
rec_get_ids.c_id || ’)’); --DEBUG
84
85
86
87
88
-- Kein NATIVE vorhanden -> Fehler
INSERT INTO AXA_MAT_FILE_BPM_DOC_ERROR (C_ID, ERROR, C_TIME, DOCUMENT_ID,
DOC_VERSION)
VALUES (REC_GET_IDS.C_ID, ’No Native found.’, CUR_DATE, REC_GET_IDS.
DOCUMENT_ID, REC_GET_IDS.DOC_VERSION);
END IF; -- Native Datei
89
90
91
ELSE -- Kein Vertiffungsprozess
dbms_output.put_line(’AXA_SEARCH_DOC_DAT: NO TIF PROCESS. START NORMAL SYNC
. (’ || rec_get_ids.c_id || ’)’); --DEBUG
92
93
94
95
96
97
98
99
-- Keine nativen Dateien enthalten, stosse den normalen Sync-Prozess an.
IF COPY_TO_AXA_MAT_FILE_DAT(IN_MAT_CID, IN_MAT_PID, IN_WORKTAN_SEQ, ’insert
’) <> ’eingefuegt’
THEN
P_CONTROL := 1;
END IF;
END IF;
END LOOP;
100
101
102
103
-- Keine Fehler aufgetreten
COMMIT;
RETURN P_CONTROL;
104
105
106
107
EXCEPTION
WHEN OTHERS
THEN
133
A. Anhang
108
109
110
COMMIT;
RETURN 1;
END AXA_SEARCH_DOC_DAT;
A.1.4. AXA_CHECK_REPEAT
Die Funktion AXA_CHECK_REPEAT erwartet nur die ID des Eintrags in der Wiedervorlagen–
Tabelle als Eingabewert. Alle anderen Werte, die gebraucht werden um den Update–
Prozess anzustoßen, können so dereferenziert werden. Der Wert P_DELAY beinhaltet die
Zeit, die zwischen zwei nicht erfolgreichen Wiedervorlagen gewartet wird, bevor der Counter herabgesetzt wird. Dieser Wert wird in Sekunden angegeben und ist standardmäßig
auf zehn Minuten eingestellt. Der Rückgabewert ist bei erfolgreichem Durchlauf 0 und bei
Auftreten eines Fehlers 1.
1
2
CREATE OR REPLACE
FUNCTION "AXA_CHECK_REPEAT" (IN_ID IN NUMBER)
3
4
5
RETURN NUMBER
IS
6
7
P_DELAY INTEGER := 10 * 60;
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CUR_DATE DATE;
REF_DATE DATE;
REF_REMAIN INTEGER;
TIF_FILE_NUMBER INTEGER;
FILE_NUMBER INTEGER;
DOC_ID VARCHAR2(40 CHAR);
DOC_VER VARCHAR2(10 CHAR);
TDOC_ID NUMBER(10);
TMAT_ID NUMBER(10);
TMAT_NUM VARCHAR2(40 CHAR);
TAN NUMBER(10);
P_CONTROL NUMBER(1);
NO_INSERT EXCEPTION;
22
23
BEGIN
24
25
26
-- Generiere Timestamp zum Abgleich
SELECT sysdate INTO CUR_DATE FROM dual;
27
28
29
30
-- Die referenzierten Daten abrufen
SELECT C_TIME, REMAIN, NATIVE_FILES, DOCUMENT_ID, DOC_VERSION, C_ID, C_ID_1,
PART_ID, WORKTAN
INTO REF_DATE, REF_REMAIN, FILE_NUMBER, DOC_ID, DOC_VER, TDOC_ID, TMAT_ID,
TMAT_NUM, TAN
134
A.1. Quelltext des Dokumentabgleich
31
32
FROM AXA_MAT_FILE_BPM_DOC_REPEAT
WHERE ID = IN_ID;
33
34
35
36
37
38
-- Checke hier die Anzahl der TIFs
SELECT COUNT(*) INTO TIF_FILE_NUMBER FROM T_DOC_FIL, T_FILE_DAT
WHERE TDOC_ID = T_DOC_FIL.C_ID_1
AND T_DOC_FIL.C_ID_2 = T_FILE_DAT.C_ID
AND T_FILE_DAT.ORG_NAME LIKE ’%.tif’;
39
40
41
IF TIF_FILE_NUMBER < FILE_NUMBER
THEN
42
43
44
IF timestamp_diff_in_seconds(CUR_DATE, REF_DATE) > P_DELAY
THEN
45
46
47
48
IF REF_REMAIN > 0
THEN
dbms_output.put_line(’AXA_CHECK_REPEAT: COUNTER DECREMENT (’ || TDOC_ID
|| ’)’); --DEBUG
49
50
51
52
53
-- Setze neuen Counter und Timestamp
UPDATE AXA_MAT_FILE_BPM_DOC_REPEAT
SET REMAIN=(REF_REMAIN-1), C_TIME=(CUR_DATE)
WHERE ID = IN_ID;
54
55
56
ELSE -- REF_REMAIN <= 0
dbms_output.put_line(’AXA_CHECK_REPEAT: COUNTER EXPIRED (’ || TDOC_ID ||
’)’); --DEBUG
57
58
59
60
-- Counter abgelaufen ohne, dass das TIF eingetroffen ist -> Fehler
INSERT INTO AXA_MAT_FILE_BPM_DOC_ERROR (C_ID, ERROR, C_TIME, DOCUMENT_ID,
DOC_VERSION)
VALUES (TDOC_ID, ’Counter expired. No TIF arrived!’, CUR_DATE, DOC_ID,
DOC_VER);
61
62
63
64
65
-- Gleichzeitig muss der Eintrag aus der Wiedervorlage geloescht werden
DELETE FROM AXA_MAT_FILE_BPM_DOC_REPEAT WHERE ID = IN_ID;
END IF; -- Counter
END IF; -- Timestamp
66
67
68
ELSE -- TIF_FILE_NUMBER >= FILE_NUMBER
dbms_output.put_line(’AXA_CHECK_REPEAT: TIF ARRIVED (’ || TDOC_ID || ’)’);
--DEBUG
69
70
71
-- Vertiffungsprozess abgeschlossen und erfolgreich
DELETE FROM AXA_MAT_FILE_BPM_DOC_REPEAT WHERE ID = IN_ID;
72
135
A. Anhang
73
74
75
76
77
78
-- Updateprozess anstossen
IF copy_to_axa_mat_file_dat(TMAT_ID, TMAT_NUM, TAN) <> ’eingefuegt’
THEN
RAISE NO_INSERT;
END IF;
END IF;
79
80
81
COMMIT;
RETURN 0;
82
83
84
85
86
87
88
89
90
91
92
93
EXCEPTION
WHEN NO_INSERT
THEN
DBMS_OUTPUT.PUT_LINE(’Insert not successful!’ || TDOC_ID);
COMMIT;
RETURN 1;
WHEN OTHERS
THEN
COMMIT;
RETURN 1;
END AXA_CHECK_REPEAT;
136
A.2. Screenshots
A.2. Screenshots
A.2.1. Axalant
Abbildung A.1.: FDO–Materialstammmaske
Abbildung A.2.: Sachmerkmalleiste bei interaktiver Übergabe
Abbildung A.3.: Listenstammmaske mit Menü zum Beenden der Schnittstelle
137
A. Anhang
Abbildung A.4.: Auftragstabelle Datenexport
Abbildung A.5.: SAP–Transfer–Queue
138
A.2. Screenshots
A.2.2. FATool
Abbildung A.6.: Betriebsmittelverwaltung mit Viewer und verknüpften Dokumenten
Abbildung A.7.: Komplettwerkzeug mit Auswahl der Schneidennummer und zugehöriger
Stückliste
139
A. Anhang
Abbildung A.8.: Benutzerberechtigungen auf Leistenebene mit zugeordneten Standorten
140
B. Urheberschaft und Sperrvermerk
Hiermit versichere ich an Eides statt, dass ich diese Masterarbeit selbstständig und ohne
Benutzung anderer als der angegebenen Quellen und Hilfsmittel angefertigt habe und
dass alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, als solche
gekennzeichnet sind, sowie dass ich die Masterarbeit in gleicher oder ähnlicher Form noch
keiner anderen Prüfungsbehörde vorgelegt habe.
Die vorgelegte Masterarbeit basiert auf internen vertraulichen Daten und Informationen
der ZF Friedrichshafen AG. In diese Arbeit dürfen Dritte, mit Ausnahme der Gutachter
und befugten Mitgliedern des Prüfungsausschusses, ohne ausdrückliche Zustimmung des
Unternehmens keine Einsicht nehmen. Eine Vervielfältigung und Veröffentlichung ohne
ausdrückliche Genehmigung ist auch auszugsweise nicht erlaubt.
Passau,
Ort, Datum
Unterschrift
141
B. Urheberschaft und Sperrvermerk
142
Tabellenverzeichnis
2.1.
2.2.
2.3.
2.4.
Gegenüberstellung von PDO und FDO . . .
Zugriffsrechte in FATool . . . . . . . . . . .
Auszug möglicher Berechtigungen in FATool
Lizenztypen für FATool . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
26
27
27
4.1. Konfigurationstabellen der Schnittstelle . . . . . . . . . . . . . . . . . . . . 61
4.2. Datentabellen der Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3. Schwachstellen im Ist–Zustand . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1. Schwachstellen des Ist–Zustands . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2. Berechtigungen bzgl. der Änderungshoheit . . . . . . . . . . . . . . . . . . 102
5.3. Schwachstellen mit Aufwandsabschätzung . . . . . . . . . . . . . . . . . . 108
143
Tabellenverzeichnis
144
Abbildungsverzeichnis
1.1. Direktzugriff auf den Master–Server . . . . . . . . . . . . . . . . . . . . . . 9
1.2. Replikation der Dateien auf den Slave . . . . . . . . . . . . . . . . . . . . . 10
1.3. Replikation der Dateien inklusive der Meta–Daten auf den Slave . . . . . . 10
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
Strukturierung des ZF–Konzerns . . . . . . . . . . .
Phasen im Produktlebenszyklus . . . . . . . . . . .
Eingliederung des PDO und FDO Prozesses . . . .
IT–Systeme im FDO–Bereiche am Standort Passau
2D–Sachmerkmale nach DIN4000 . . . . . . . . . .
Statuswechsel im FDO–Bereich . . . . . . . . . . .
Sachmerkmalleisten–System in FATool . . . . . . .
Architektur der SAP–Systeme im ZF–Konzern . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
16
18
19
21
22
25
28
3.1. Architekturpyramide . . . . . . . . . . . . . . . . . . . . . .
3.2. Blackbox und Whitebox . . . . . . . . . . . . . . . . . . . .
3.3. Architekturbrezel . . . . . . . . . . . . . . . . . . . . . . . .
3.4. Konzeptuelles Architekturmodell nach IEEE42010:2007 . . .
3.5. Konzeptuelles Architekturmodell nach IEEE42010:2011 . . .
3.6. Zachman–Framework . . . . . . . . . . . . . . . . . . . . . .
3.7. TOGAF Architecture Development Method . . . . . . . . .
3.8. Klassifikation von Anforderungen . . . . . . . . . . . . . . .
3.9. User–Story-Card mit Vorderseite links und Rückseite rechts
3.10. Typische ER–Notationen 1 . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
32
33
35
37
40
41
44
46
52
4.1. Ist–Architektur . . . . . . . . . . . . . . . . . . . . .
4.2. Austausch von Materialstämmen . . . . . . . . . . .
4.3. FATool Master– und Client–Service . . . . . . . . . .
4.4. Serveraufbau für FATool–Installation . . . . . . . . .
4.5. Datenbankstruktur . . . . . . . . . . . . . . . . . . .
4.6. Übertragungsprozess . . . . . . . . . . . . . . . . . .
4.7. Funktionsweise eines Database–Link . . . . . . . . . .
4.8. Erzeugen von Inkonsistenzen zwischen SML–Daten .
4.9. Dokumentabgleich mit bisherigen Möglichkeiten . . .
4.10. Transferdaten mit Verbindung über Datenbank–Link
4.11. Prozess vom Material zum 3D–Modell . . . . . . . .
4.12. Beziehung zwischen Material– und Dokumentstamm .
4.13. Redundanzen durch Namenskonventionen . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
56
57
58
59
62
63
64
66
67
68
69
70
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
145
Abbildungsverzeichnis
4.14. Prozess zum Erzeugen von Datenleichen . . . . . . . . . . . . . . . . . . . 71
5.1. Soll–Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Datenüberschneidung zwischen ZF und ZFLS . . . . . . . . . . . . . . .
5.3. Übertragen zusätzlicher Informationen zwischen den zentralen Systemen .
5.4. Fehlerhafte Verteilung durch manipulierte Schnittstelle . . . . . . . . . .
5.5. Filterung durch Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . .
5.6. Mögliche standortspezifische Anpassungen . . . . . . . . . . . . . . . . .
5.7. Konflikt bei der Datenmigration . . . . . . . . . . . . . . . . . . . . . . .
5.8. Replizieren von Meta–Daten und Dokumenten . . . . . . . . . . . . . . .
5.9. Replizieren ausschließlich von Dokumenten . . . . . . . . . . . . . . . . .
5.10. Replikation von Meta–Daten und Dokumenten aber nur zentrale Änderung
der Meta–Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.11. Synchroner Abgleich mit Inkonsistenzen . . . . . . . . . . . . . . . . . .
5.12. Asynchroner Abgleich mit Wartezeiten . . . . . . . . . . . . . . . . . . .
5.13. Transferdatenverlagerung nach Axalant . . . . . . . . . . . . . . . . . . .
5.14. Import von 3D–Modellen nach FATool . . . . . . . . . . . . . . . . . . .
5.15. Speichern der manuell importierten Betriebsmittel . . . . . . . . . . . . .
5.16. Beziehung zwischen Bauteil und Baugruppen . . . . . . . . . . . . . . . .
5.17. Zusammenlegen der Status für Freigabe und Rückgabe . . . . . . . . . .
5.18. Abhängigkeit des Betriebsmittelstatus . . . . . . . . . . . . . . . . . . .
5.19. Berechtigungskonzept zum Sichten von Daten . . . . . . . . . . . . . . .
5.20. Berechtigungskonzept zum Ändern von Daten . . . . . . . . . . . . . . .
5.21. Automatisierung der Migration . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
74
80
83
85
86
87
88
90
91
.
.
.
.
.
.
.
.
.
.
.
.
92
93
93
95
96
97
98
99
100
103
104
106
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
6.8.
6.9.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
112
113
114
114
115
116
116
117
FDO–Materialstammmaske . . . . . . . . . . . . . . . . . . . . . . . . .
Sachmerkmalleiste bei interaktiver Übergabe . . . . . . . . . . . . . . . .
Listenstammmaske mit Menü zum Beenden der Schnittstelle . . . . . . .
Auftragstabelle Datenexport . . . . . . . . . . . . . . . . . . . . . . . . .
SAP–Transfer–Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Betriebsmittelverwaltung mit Viewer und verknüpften Dokumenten . . .
Komplettwerkzeug mit Auswahl der Schneidennummer und zugehöriger
Stückliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.8. Benutzerberechtigungen auf Leistenebene mit zugeordneten Standorten .
.
.
.
.
.
.
137
137
137
138
138
139
A.1.
A.2.
A.3.
A.4.
A.5.
A.6.
A.7.
146
Konzept der Wiedervorlage . . . . . . . . . . . . . . . . . .
Alter und neuer Prozess des Dokumentabgleich . . . . . .
Tabelle von synchronisierten Materialien . . . . . . . . . .
Tabelle zum Quittieren der Transfer–Queue . . . . . . . .
Tabelle zum Speichern des Cursor–Timestamps . . . . . .
Programmablauf zur Überprüfung von Dokumentstämmen
Fehlertabelle der Wiedervorlage . . . . . . . . . . . . . . .
Tabelle zur Wiedervorlage . . . . . . . . . . . . . . . . . .
Programmablauf der Wiedervorlage . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 139
. 140
Literaturverzeichnis
[Ahl12]
Ahlemann, Frederik:
Springer–Verlag, 2012
Strategic Enterprise Architecture Management.
[Bau06]
Bauermann, Dr.-Ing. E.: Nutzung von PDM-Systemen im Maschinenbau.
April 2006. – ZF Friedrichshafen AG
[BCK12]
Bass, Len ; Clements, Paul ; Kazman, Rick: Software Architecture in
Practice. Addison–Wesley, 2012
[ES09]
Eigner, M. ; Stelzer, R.: Product Lifecycle Management: Ein Leitfaden für
Product Development und Life Cycle Management. Springer–Verlag, 2009. –
ISBN 9783540443735
[Fas10]
Fasys: FASys Dokumentation - Das FASys Sachmerkmalleistensystem. Dezember 2010
[Fas12]
Fasys: Axalantanbindung. Dezember 2012. – Implmentierung der Axalantanbindung
[GBBK10] Grechenig, Thomas ; Bernhart, Mario ; Breiteneder, Roland ; Kappel, Karin: Softwaretechnik: mit Fallbeispielen aus realen Entwicklungsprojekten. Pearson Studium, 2010 (IT Informatik). – ISBN 9783868940077
[Han13]
Hanschke, Inge: Strategisches Management der IT-Landschaft: Ein praktischer Leitfaden für das Enterprise Architecture Management. Hanser–Verlag,
2013. – ISBN 978–3–446–41702–1
[ISO07]
ISO/IEC/IEEE: ISO/IEC/IEEE Systems and Software engineering – Recommended practice for architectural description of software-intensive systems. In: ISO/IEC/IEEE 42010:2007 (IEEE Std) 1471-2000 (2007), S. 1–34
[ISO11]
ISO/IEC/IEEE: ISO/IEC/IEEE Systems and software engineering – Architecture description. In: ISO/IEC/IEEE 42010:2011(E) (Revision of ISO/IEC
42010:2007 and IEEE Std 1471-2000) (2011), S. 1–46
[JS08]
Janas, Thomas ; Schumann, Matthias: IT–Architekturen beim Zussamenschluss von Unternehmen. In: Arbeitsbericht (2008), S. 52
[Kel12]
Keller, Wolfgang: IT-Unternehmensarchitektur. 2. Aufl. Dpunkt–Verlag,
2012
147
Literaturverzeichnis
[Pet12]
Peter, Patrick: NC-Management mit FATool. April 2012. – ZF Friedrichshafen AG
[Rup13]
Rupp, Chris: Systemanalyse kompakt. Springer–Verlag, 2013
[Sen09]
Sendler, U.:
Das PLM-Kompendium: Referenzbuch des ProduktLebenszyklus-Managements. Springer–Verlag, 2009. – ISBN 9783540878971
[SH11]
Starke, Gernot ; Hruschka, Peter: Software–Architektur kompakt – angemessen und zielorientiert. Spektrum, akademischer Verlag, 2011
[Som07]
Sommerville, Ian: Software Engineering. Addison–Wesley, 2007 (Pearson
Studium). – ISBN 9783827372574
[Sta08]
Starke, Gernot: Effektive Software-Architekturen: ein praktischer Leitfaden.
Hanser–Verlag, 2008
[ZF10]
ZF: Schulungshandbuch, FHM-Verwaltung mit Axalant. Mai 2010. – ZF
Friedrichshafen AG
[ZF12a]
ZF: Management von Daten, digitalen Objekten und Dokumenten im PDM
System. 2012. – ZF Friedrichshafen AG, FDO-Support
[ZF12b]
ZF: ZF-Konzern; Auf einen Blick. 2012. – ZF Friedrichshafen AG
[ZF13]
ZF: PLM-Wiki. http://web-wiki.emea.zf-world.com/frd_plm/index.
php. Version: Januar 2013. – (abgerufen am 29.11.2013)
[Zör12]
Zörner, Stefan: Softwarearchitekturen dokumentieren und kommunizieren
– Entwürfe, Entscheidungen und Lösungen nachvollziehbar und wirkungsvoll
festhalten. Hanser–Verlag, 2012
148