DE10330666A1

DE10330666A1 - Verfahren zur Erzeugung und Pflege von Produktdaten

Info

Publication number: DE10330666A1
Application number: DE2003130666
Authority: DE
Inventors: Werner Fässler; Bernd Dr. Ullmann; Paolo Andrea Walty; Albrecht Eckart Wittlinger
Original assignee: Alstom Schweiz AG
Current assignee: General Electric Technology GmbH
Priority date: 2002-07-11
Filing date: 2003-07-08
Publication date: 2004-01-22

Abstract

Bei einem Verfahren zur Erzeugung und Pflege von Produktdaten wird eine besonders gute Handhabbarkeit der Daten durch die Aufgliederung der Wertschöpfungg in eine erste virtuelle Phase (I) und eine zweite reelle Phase (II) erreicht. Dabei erfolgt in der ersten Phase die Konstruktion und Projektierung eines Produktes, während die zweite Phase die Herstellung und den Betrieb des Produktes mitsamt der Wartung und Instandhaltung abbildet. Entsprechend werden die beiden Phasen weiter in Module (1, 2, 3, 4) unterteilt. Die Erfindung macht sich dabei die Erkenntnis zunutze, dass über die gesamte Wertschöpfung mit denselben Objekten gearbeitet wird, wobei ein Objekt in unterschiedlichen Revisionsständen vorliegen kann. Dabei zeigt sich, dass in unterschiedlichen Phasen der Wertschöpfung ein Zugriff auf bestimmte Revisionen eines Objektes zu beschränken ist, und dass der zum Zugriff auf bestimmte Daten zu berechtigende Personenkreis ebenfalls von Modul zu Modul variiert. Durch eine geeignete Wahl der Schnittstellen zwischen den Modulen lässt sich so der Zugriff von der Benutzerschnittstelle (6) über eine Zugriffsschutzroutine (5) besonders effizient steuern.

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft ein Verfahren zur Erzeugung und Pflege von Produktdaten. Das Verfahren ist besonders für die Verwendung im Bereich von Systemen und Komponenten von stromerzeugenden Maschinen wie Gasturbinenanlagen, Dampfturbinenanlagen, Wasserturbinenanlagen und Kombikraftwerken, sowie anderen komplexen und technisch hochstehenden betriebs- und wartungsintensiven Anlagen geeignet.
STAND DER TECHNIK
Im Laufe des Wertschöpfungsprozesses von komplexen und technologisch hochstehenden Produkten muss eine Vielzahl von technischen, statistischen und logistischen Informationen, welche für dieses Produkt relevant sind, geschaffen, bearbeitet und verwaltet werden. Dies gilt besonders auch im Bereich von Systemen und Komponenten von stromerzeugenden Maschinen wie Gasturbinenanlagen, Dampfturbinenanlagen, Wasserturbinenanlagen, Kombikraftwerken und so fort. Gemäss einem Stand der Technik erfolgt die Dokumentation der Entstehehung und der Betriebsgeschichte derartiger Anlagen in Dossiers, wobei diese in Papierform oder durchaus bereits voll oder teilweise elektronisch geführt sein können. Bei der althergebrachten Dokumentation in Papierform werden in der Entwicklungsphase zunächst Unterlagen wie technische Zeichnungen und Spezifikationen ausgearbeitet, und diese werden anschliessend ausgedruckt und in Papierform abgelegt. Geht dann zu einem bestimmten System eine Bestellung ein, so werden diese Spezifikationen und technischen Informationen an die spezifischen Wünsche des Auftraggebers angepasst und überarbeitet. Die Spezifikationen des daraus resultierenden geplanten Systems werden daraufhin wiederum auf Papier dokumentiert, und die einzelnen Komponenten gegebenenfalls in unterschiedlichen Produktionsstätten aufgrund der für diese Komponenten zur Verfügung gestellten Pläne produziert. Dabei kann es sehr häufig vorkommen, dass die effektiv produzierte Komponente nicht zu 100% den in den Spezifikationen gemachten Vorgaben entspricht. So kann es zum Beispiel sein, dass Masse nicht genau eingehalten werden, dass andere Materialien verwendet werden, oder dass Toleranzen vollständig ausgeschöpft werden. Diese Zusatzinformationen, welche sich erst aus dem eigentlichen Produktionsprozess ergeben, müssen in den Detailplänen zu den Komponenten vermerkt werden, da sie gegebenenfalls für die Anpassung von unterschiedlichen Komponenten aneinander von grösster Wichtigkeit sind.
Bei der eigentlichen Montage des Systems müssen dann nicht nur die Komponenten zur Verfügung stehen, sondern auch die zugehörigen Spezifikationen, gegebenenfalls inklusive deren Änderungen auf Grund des spezifischen Produktionsprozesses. Nach der Montage muss das System im tatsächlichen Montagezustand festgehalten werden und eine ausführliche Dokumentation dieses Zustandes angefertigt werden. Dies geschieht wiederum üblicherweise indem die technischen Zeichnungen zusammen mit den im Produktionsprozess oder bei der Montage vorgenommenen Änderungen sowie der Ergebnisse von Inbetriebnahmetests in Papierform abgelegt werden. Während der Phase des eigentlichen Betriebs des Systems werden im Rahmen von Wartungen oder Reparaturen Ersatzteile eingefügt oder Änderungen respektive Erweiterungen vorgenommen. Auch diese zusätzlichen Informationen, welche den jeweiligen Istzustand des Systems dokumentieren, müssen äusserst sorgfältig verwaltet und auf einem jeweils aktuellen Stand gehalten werden, um die Geschichte des Systems verfolgen zu können und durch gezielte Wartung respektive Reparaturarbeiten Standzeiten so niedrig wie möglich zu halten.
Das beschriebene Verfahren des Standes der Technik erfordert einen hohen und mit der Komplexität der Produkte exponentiell zunehmenden Aufwand bezüglich des Abgleichs und der Nachführung der an unterschiedlichen Orten vorhandenen Dossiers. Eine Unsaubere Dokumentation des Ist-Zustandes oder uneinheitlich dokumentierte Revisionen an unterschiedlichen Stellen ziehen leicht unabsehbare Folgen nach sich.
Die ebenfalls schon geläufige voll- oder teilelektronische Führung der Dossiers, bei der die einzelnen Dokumente in digitalisierter Form abgelegt werden, unterscheidet sich von der Führung der Dossiers in Papierform nur wenig, und wirft auch weiterhin die aus einer Sammlung heterogener Dokumente hervorgehenden Probleme auf, wie die Gefahr uneinheitlicher Revisionsstände.
Weiterhin werfen die nach dem Stand der Technik geläufigen Verfahren informationslogistische Probleme auf. Zunehmend werden hochwertige Komponenten und komplexe Projekte nicht an einem einzigen Ort abgewickelt, sondern vielmehr an unterschiedlichsten Standorten rund um die Welt. Dies betrifft nicht mehr nur die eigentliche Produktion sondern auch die Entwicklung vom ersten Moment an. Insbesondere bei technologisch sehr hochstehenden Produkten müssen in der Entwicklungsphase jeweils für spezifische Problembereiche unterschiedliche, hochspezialisierte Fachkräfte hinzugezogen werden, welche üblicherweise nicht alle an einem einzigen Ort verfügbar sind. So kann es zum Beispiel vorkommen, dass bei der Entwicklung allein einer Turbinenschaufel in Bezug auf die aerodynamische Gestaltung des Blattes ein Fachmann in Amerika beauftragt ist, in Bezug auf die Gestaltung der Kühlluftführung innerhalb der Schaufel ein anderer Fachmann in Europa verantwortlich zeichnet, und in Bezug auf die spezifische Ausbildung des Schaufelfusses ein wiederum anderer Entwickler in Australien. Das klassische informationslogistische Verfahren kann in derart vernetzten und globalen Situationen nicht mehr sinnvoll verwendet werden, da ansonsten unter anderem eine typische Entwicklungsdauer durch die notwendige Verschiebung von Dokumentationen derart verlängert wird, dass nicht mehr konkurrenzfähig gearbeitet werden kann. Ausserdem ergibt sich das Problem, dass die Zusammenarbeit von unterschiedlichen Fachleuten an ein und derselben Komponente nur äusserst erschwert möglich ist, und eine synergetische Vernetzung des Wissens stark behindert wird.
Zusammenfassend muss festgestellt werden, dass innerhalb komplexer Technologien und Projekte das Informationsmanagement von Produktdaten nach dem Stand der Technik bis heute "von Hand" vorgenommen wird, also eine Vielzahl nur schwer überprüfbarer äusserer Eingriffe benötigt und entsprechend fehleranfällig ist.
DARSTELLUNG DER ERFINDUNG
Hier greift die Erfindung. Der Erfindung liegt demnach die Aufgabe zugrunde, ein Verfahren der eingangs genannten Art anzugeben, welches die Nachteile des Standes der Technik zu vermeiden vermag. Das erfindungsgemässe Verfahren soll eine Straffung der Informationslogistik, eine Beschleunigung des Entwicklungs- und Bestellverfahrens bei gleichzeitiger globaler Verfügbarkeit und guter Verfolgbarkeit und zuverlässiger Dokumentation von Produkten über die gesamte Wertschöpfungskette und Lebensdauer ermöglichen.
Erreicht wird dies durch die Gesamtheit der Merkmale des Anspruchs 1.
Der Kern der Erfindung besteht mit anderen Worten darin, zunächst alle Daten über die gesamte Wertschöpfungskette und Lebensdauer zentral zu speichern. So kann gewährleistet werden, dass immer alle im Rahmen der Wertschöpfungskette mit dem Produkt beschäftigten Personen auf die gleiche und aktuelle produktrelevante Information zugreifen. Ein häufig auftretendes technisches Problem im Zusammenhang mit derart komplexen Dokumentationen, kann so verhindert werden, nämlich, dass die Aktualisierung der produktrelevanten Information nicht gewährleistet ist und entsprechend unterschiedliche Bearbeitungsschritte von verschiedenen Voraussetzungen, wie beispielsweise unterschiedlichen Revisionsständen von Konstruktionszeichnungen, ausgehen, woraus sich bei Montage und Betrieb grosse Probleme ergeben könnten, da derart unterschiedliche Komponenten unter Umständen nicht mehr auf einander angepasst sind und entweder vor Ort modifiziert oder nochmals in die Produktion zurückgeschickt werden müssen. Ausserdem wird durch die zentrale Datenaufbewahrung eine redundante Aufbewahrung der Dokumentation effizient verhindert. Die globale Verfügbarkeit kann über spezifische Datenleitungen oder über das Internet gewährleistet werden. Die zentrale Haltung der Daten erlaubt ausserdem eine effiziente Überwachung von Komponenten und deren Zustand, und es ist so beispielsweise möglich, Korrelationen zwischen bestimmten Bauteilen und bestimmten Defekten leicht aufzudecken respektive bei bekannten Defekten von spezifischen Bauteilen diese in allen Systemen, in welchen sie eingebaut sind, zu ersetzen.
Bei einer derartigen zentralen Datenaufbewahrung muss nun aber auf der anderen Seite die Möglichkeit zur Datenmanipulation äusserst genau kontrolliert werden, um Missgriffe zu verhindern. Entsprechend müssen die Möglichkeiten von Erzeugung, Zugriff, Revision, und/oder Ausführbarkeit der Daten strukturiert werden und sichere Regeln gefunden werden, welche Person in welcher Phase welche Operationen durchführen darf. Wird dies nicht getan, so besteht das Problem, dass gegebenenfalls bestimmte Spezifikationen von Komponenten, welche nur von definierten Personen im Rahmen von besonderen Vorgängen geändert werden dürften, von nicht autorisierten Personen modifiziert werden. Auch dies kann dazu führen, dass am Ende Komponenten andere Spezifikationen aufweisen, als ursprünglich geplant war, ohne dass dies in Echtzeit dokumentiert wäre. Spätestens bei der Montage ergeben sich dadurch mutmasslich gravierende Probleme. Überraschenderweise zeigt es sich nun aber, dass eine Einteilung des Wertschöpfungsprozesses in zwei Phasen und eine entsprechende Definition der Möglichkeiten von Erzeugung, Zugriff, Revision, und/oder Ausführbarkeit der Daten in Abhängigkeit davon, in welcher dieser beiden Phasen des Wertschöpfungsprozesses das Produkt sich befindet, die genannten Probleme weitgehend verhindern kann. Die erste Phase ist dabei eine rein virtuelle Phase, in welcher das eigentliche Produkt respektive die eigentliche Komponente noch gar nicht existiert, sondern diese vielmehr zunächst entwickelt und anschliessend an die Kundenwünsche angepasst wird. In der zweiten Phase existiert physikalisch ein Produkt respektive eine Komponente, und parallel dazu müssen die zugehörigen Informationen verwaltet respektive aktualisiert gehalten werden. Die beiden Phasen werden im Wertschöpfungsprozess nacheinander durchlaufen, und die produktrelevanten Daten werden an einer Schnittstelle von der ersten an die zweite Phase übergeben. Dies geschieht bevorzugt in einem standardisierten Datenformular, beispielsweise in einer Metasprache, wie Markup Language. Die beiden Phasen zeichnen sich durch grundlegende Unterschiede in Bezug auf sinnvolle und notwendige Änderung und Neuschaffung von Information sowie den zu bestimmten Zugriffen zuzulassenden Personenkreis aus, und eine entsprechende Aufteilung der Zugriffsberechtigungen auf diese zwei Phasen erweist sich in dieser Hinsicht als äusserst effizient.
Die erste Phase umfasst also im Wesentlichen die Konstruktion und Projektierung eines Produktes, während die zweite Phase die Herstellung und/oder den Zusammenbau und den betrieb mitsamt der Wartung und Instandhaltung umfasst. Entsprechend ist es sinnvoll, wenn in der ersten Phase alle Revisionen einer Komponente verfügbar sind, während in der zweiten Phase bevorzugt nur noch der in die Realität umgesetzte Revisionsstand verfügbar sein soll.
Gemäss einer ersten bevorzugten Ausführungsform der vorliegenden Erfindung umfasst die erste Phase zwei Module, beispielsweise ein Basismodul und ein Bestellungsmodul, welche beiden Module im Wertschöpfungsprozess nacheinander durchlaufen werden. Das Basismodul umfasst die Phase der reinen Entwicklung. Das Bestellmodul umfasst die Anpassung des im Basismodul entwickelten Produktes an eine spezifische Bestellung. Die beiden Module werden im Wertschöpfungsprozess nacheinander durchlaufen, und die produktrelevanten Daten werden an einer Schnittstelle vom Basismodul an das Bestellmodul übergeben. Dies geschieht bevorzugt in einem standardisierten Datenformular, beispielsweise in einer Metasprache, wie Markup Language. Dabei werden wiederum die Möglichkeiten von Erzeugung, Zugriff, Revision, und/oder Ausführbarkeit der Daten in Abhängigkeit davon definiert, in welchem Modul das Produkt sich befindet. Ebenso werden die Befugnisse bestimmter in den Wertschöpfungsprozess involvierter Personen zur Vornahme von Datenmanipulationen abhängig vom Modul vorgegeben. Die Zulässigkeit der Zugriffe wird dabei von einer Zugriffsschutzroutine überprüft. Die beiden Module weisen ebenfalls grundlegende Unterschiede in Bezug auf die sinnvolle Änderung und Neuschaffung von Information auf. Im Basismodul werden dabei in erster Linie Daten erzeugt und miteinander verknüpft respektive anschliessend elektronisch über spezifische Routinen freigegeben. Informationen von Teilkomponenten können dabei zu Baugruppen respektive Systemen verknüpft werden und entsprechende Strukturen angelegt und visualisiert werden. Im Bestellungsmodul wird anschliessend das Resultat der im Basismodul entwickelten Struktur respektive Information (Spezifikationen, technische Zeichnungen etc.) als ganzes übernommen und nur noch an die spezifischen Wünsche des Auftraggebers angepasst. Dies kann manuell oder automatisiert mittels eines Konfigurators erfolgen. Dabei können insbesondere bereits im Basismodul festgelegte Optionen ausgewählt werden, oder es kann individuell modifiziert werden. Änderungen werden dabei bevorzugt in einem Differenzreport dokumentiert und festgehalten.
In einer weiteren bevorzugten Ausführungsform der Erfindung ist die zweite, reelle Phase des Wertschöpfungsprozesses in ein Montagemodul und ein Servicemodul unterteilt. Diese beiden Module werden im Wertschöpfungsprozess nacheinander durchlaufen, wobei das Montagemodul die Phase der Montage und Inbetriebnahme des Produkts umfasst und wobei das Servicemodul die daran anschliessende Phase des Betriebs des Produkts umfasst. Die beiden Module werden im Wertschöpfungsprozess nacheinander durchlaufen, und die produktrelevanten Daten werden an einer Schnittstelle vom Montagemodul an das Servicemodul übergeben. Dies geschieht bevorzugt in einem standardisierten Datenformular, beispielsweise in einer Metasprache, wie Markup Language. Dabei werden wiederum die Möglichkeiten von Erzeugung, Zugriff, Revision, und/oder Ausführbarkeit der Daten in Abhängigkeit davon definiert, in welchem Modul das Produkt sich befindet. Ebenso werden die Befugnisse bestimmter in den Wertschöpfungsprozess involvierter Personen zur Vornahme von Datenmanipulationen abhängig vom Modul vorgegeben. Die Zulässigkeit der Zugriffe wird dabei von einer Zugriffsschutzroutine überprüft. Dabei sind wiederum die Möglichkeiten von Erzeugung, Zugriff, Revision, und/oder Ausführbarkeit der Daten in Abhängigkeit davon definiert, in welchem der beiden Module das Produkt sich befindet. Bei der Montage und Inbetriebnahme stehen die Führung von Montage- und Testprotokollen und die gegebenenfalls erforderliche Dokumentation von Modifikationen im Vordergrund. Diese Dokumentation geschieht bevorzugt im Montagemodul. In der Phase des Betriebes und der Wartung des Produktes sind die Dokumentation von Wartungsvorgängen sowie von Reparaturen und Teileaustausch vorrangig. Dies erfolgt im Servicemodul.
Festzustellen ist noch, dass, wenn beide Phasen wie beschrieben in Module aufgeteilt sind, die Schnittstelle von der ersten, virtuellen Phase zur zweiten, reellen Phase gleichzeitig eine Schnittstelle zwischen dem Bestellmodul und dem Montagemodul darstellt.
Eine weitere bevorzugte Ausführungsform der Erfindung ist dadurch gekennzeichnet, dass an der Schnittstelle von einem Modul in das nächstfolgende Modul ein Haltepunkt definiert wird, in welchem der Zustand des Produkts bei diesem Übergang in nicht mehr veränderbarer Weise festgehalten und abgespeichert wird. Es handelt sich dabei um so genannte Produktlebensdauer-Zustände. Dabei wird bevorzugt der Zustand nach Durchlauf des Basismoduls als Konstruktions- oder "as designed"- Zustand festgehalten, sowie der Zustand nach Durchlauf des Bestellmoduls als Bestell- oder "as ordered"-Zustand, der Zustand nach Durchlauf des Montagemoduls als Liefer- oder "as built"-Zustand und der aktuelle Ist-Zustand innerhalb des Servicemoduls als Betriebs- und Wartungs- oder "as maintained" Zustand.
Gemäss einer weiteren bevorzugten Ausführungsform der vorliegenden Erfindung werden die Produktdaten in Form von Objekten und, falls erforderlich, diesen Objekten zugeordnete Informationen definiert, wobei die Objekte zu Objektstrukturen miteinander verknüpft werden, derart, dass die Speicherung redundanter Daten vermieden wird, und wobei die Möglichkeiten von Erzeugung, Zugriff, Revision, und/oder Ausführbarkeit der Objekte objektspezifisch und in Abhängigkeit davon definiert sind, in welcher Phase respektive in welchem Modul das Produkt sich befindet. Die objektorientierte und über Verknüpfungen strukturierte Art der Datenhaltung erlaubt eine besonders einfache Realisierung von Zugriffsberechtigungen, da diese auf spezifische Objekte in Abhängigkeit des aktuellen Moduls zugeschnitten werden kann. Das technische Problem der Definition der Zugriffsberechtigungen wird so besonders einfach gelöst und ausserdem eine minimale Datenmenge ermöglicht, da es bei Verknüpfungen möglich ist, auch bei unterschiedlichen Revisionen auf die gleichen Dateien zuzugreifen, falls diese substantiell nicht geändert wurden. Objekte werden bevorzugt in unterschiedliche Objektklassen eingeteilt wie beispielsweise. Teile, Einzelteile, Baugruppen, Systeme, Prüfprozess, Prüfschritt, Dokumente, Bestellung, Montage, Wartung, und so weiter.
Es ist weiterhin von Vorteil, wenn eine Bearbeitung von freigegebnen Objekten nach einem zwingend vorgeschriebenen Änderungsprotokoll durchgeführt und auf dessen Einhaltung überprüft wird. So können Fehlmanipulationen an den Daten wirksam verhindert werden und ausserdem kann sichergestellt werden, dass in einem bestimmten Änderungsvorgang effektiv alle notwendigen Schritte vollzogen wurden.
Eine andere bevorzugte Ausführungsform der vorliegenden Erfindung ist dadurch gekennzeichnet, dass Objekte mit einem Benachrichtigungs-Verteiler verknüpft werden. Bei einer Revision eines Objektes werden diesem Verteiler entsprechend automatisch Informationen versendet und/oder es werden in Abhängigkeit von Revisionsklassen regelbasiert Entscheidungen getroffen und weitergeleitet. Diese automatische Benachrichtigung aller Benutzer, welche gegebenenfalls an einem bestimmten Objekt arbeiten und dieses modifizieren oder als Basis benützen könnten, führt zu einer optimalen Koordination der Zugriffe.
Technisch realisiert wird die Zugriffsberechtigung und allgemein der Zugriff auf die Produktdaten durch eine Zugriffsschutzroutine und eine Benutzerschnittstelle, User-Interface, wobei der Zugriff weltweit elektronisch möglich ist. Dabei wird einem Benutzer in Abhängigkeit vom Produkt selektiv eine Berechtigungsebene zugewiesen. Je nach Produkt oder Produktgruppe, sowie seiner Funktion und Rolle innerhalb eines Projektes wird der Benutzer zu Erzeugung, Zugriff, Revision, und/oder Ausführbarkeit bestimmter Objekte und/oder Objektklassen berechtigt.
Weitere bevorzugte Ausführungsformen des erfindungsgemässen Verfahrens sind in den abhängigen Ansprüchen beschrieben.
Die vorliegende Erfindung betrifft ausserdem die Verwendung eines Verfahrens, wie es oben beschrieben wurde, im Zusammenhang mit Systemen und Komponenten für Maschinen insbesondere im Bereich von Stromerzeugung, Gasturbinenanlagen, Wasserturbinenanlagen, Dampfturbinenanlagen und Kombikraftwerken.
Des Weiteren betrifft die vorliegende Erfindung Computerprogrammsysteme zur Durchführung eines erfindungsgemässen Verfahrens sowie zu der genannten Verwendung.
KURZE ERLÄUTERUNG DER FIGUREN
Die Erfindung soll nachfolgend anhand von Ausführungsbeispielen im Zusammenhang mit den Zeichnungen näher erläutert werden. Es zeigen:
1 eine schematische Darstellung des Verfahrens mit Modulen;
2 eine Prinzipdarstellung des Aufbaus von Strukturen aus Objekten innerhalb der Module;
3 einen möglichen Lebenslauf von Objekten;
4 eine schematische Darstellung beispielshafter Objektstrukturen; 5 ein Blockdiagramm eines Basismoduls;
6 ein Beispiel für eine Objektstruktur im Basismodul; 7 ein Blockdiagramm eines Bestellungsmodul;
8 ein Beispiel für eine Objektstruktur im Bestellungsmodul; 9 ein Blockdiagramm eines Montagemodul;
10 ein Beispiel für eine Objektstruktur im Montagemodul; 11 ein Blockdiagramm eines Servicemodul; und
12 ein Beispiel für eine Objektstruktur im Servicemodul.
WEGE ZUR AUSFÜHRUNG DER ERFINDUNG
1 zeigt eine schematische Darstellung des Wertschöpfungsprozesses eines Produktes von der Entwicklung bis zum Betrieb. Der Wertschöpfungsprozess wird zunächst in eine erste Phase I und in eine zweite Phase II aufgeteilt. Die erste Phase I ist eine rein virtuelle Phase, bei welcher noch kein tatsächliches Produkt physikalisch vorliegt, sondern nur Daten in elektronischer Form oder auf Papier erzeugt und bearbeitet werden. Die erste Phase I bildet damit nur einen Sollzustand ab. Nach dem Durchlauf der ersten Phase tritt ein Produkt in die zweite Phase II ein, in dem neben Informationen ein physisches Produkt geschaffen und bearbeitet wird.
Phase I ist unterteilt in ein Basismodul 1. in welchem die eigentliche Entwicklung abgebildet wird, und in welchem also die Produktdaten erstmals geschaffen werden. Nach Abschluss des durch das Basismodul 1 umfassten Prozesses wird ein Haltepunkt definiert, an dem der Konstruktions- oder "as designed"-Zustand festgehalten wird. Dieser Zustand kann nicht mehr verändert werden. Somit kann dieser Zustand jederzeit wieder abgerufen und mit einem späteren Zustand oder mit dem Ist-Zustand verglichen werden.
An einer Schnittstelle zwischen dem Basismodul 1 und dem Bestellungsmodul 2 werden die produktrelevanten Daten, welche hier dem Konstruktionszustand entsprechen, vom Basismodul an das Bestellmodul übergeben und dort weiter bearbeitet. Es erfolgt eine Anpassung des entwickelten Systems an kundenspezifische Wünsche und Vorgaben. Auch das Bestellungsmodul 2 wird durch einen Haltepunkt, den sogenannten Bestell- oder "as ordered"-Zustand abgeschlossen, welcher unveränderbar ist und auf welchen jederzeit zugegriffen werden kann. Auf diese Phase im Wertschöpfungsprozess folgt der Abschnitt, welcher im Montagemodul 3 bearbeitet wird, in welchem die Fertigung und/oder Montage dokumentiert wird. Auch der Durchlauf des Montagemoduls 3 wird mit einem Haltepunkt abgeschlossen, an dem der Liefer- oder "as assembled" -Zustand festegehalten und dokumentiert wird. Zuletzt tritt das Produkt respektive System in die durch das Servicemodul 4 umfasste Phase, in welcher die Dokumentation respektive die notwendigen Arbeitsschritte bei Wartungen und Reparaturen festgehalten werden sowie der Betrieb dokumentiert wird. Die einzelnen Module gehen lückenlos ineinander über. In jedem Modul kann die Objektstruktur den entsprechenden Randbedingungen angepasst werden.
Die grösste Zunahme an Information im Rahmen des Wertschöpfungsprozesses findet normalerweise in der vom Basismodul 1 umfassten Phase statt, wo die eigentliche Entwicklung stattfindet und dokumentiert wird. In der vom Bestellmodul 2 umfassten Phase werden die in der Phase 1 definierten Spezifikationen in der Regel nur noch modifiziert und angepasst. Während der Montage, die vom Montagemodul 3 umfasst wird, werden Idealerweise nur noch Dokumentationen abgelegt, welche die Spezifikation des Lieferzustandes dokumentieren, so zum Beispiesl Testprotokolle, Qualitätszertifikate und dergleichen. In der Praxis geht die notwendige Dokumentation in dieser Phase aber über reine Protokollierung hinaus, denn im Normalfall sind im Rahmen der Montage spezifische kleinere Modifikationen notwendig, um separat angefertigte Komponenten aneinander anzupassen. In der letzten Phase, welche vom das Servicemodul 4 umfasst wird, wird unter anderem der effektive Betrieb überwacht, beispielsweise durch ein Betriebsstunden-Logging.
Der Zugriff zu den Modulen wird über eine Zugriffsschutzroutine 5 überwacht. In Abhängigkeit von definierten Zugriffsberechtigungen wird das Anlegen, das Lesen, die Revision oder die Ausführung von Daten erlaubt. Der Benutzer greift über diese Zugriffsschutzroutine mit Hilfe der Benutzerschnittstelle 6, User Interface, auf eine zentrale Datenbank zu. Dieser Zugriff kann global über das Internet erfolgen; da es sich aber bei den zentral verwalteten Daten häufig um sehr grosse Dateien wie technische Zeichnungen und Grafiken handelt, sind unter Umständen auch dezidierte Datenleitungen notwendig (WAN). Der Zugriff ist dabei modulspezifisch, und die Berechtigungen nehmen grundsätzlich von Modul 1 zu Modul 4 sukzessive ab.
In 2 ist dargestellt, wie die produktbezogenen Daten realisiert werden. Dazu werden zunächst Objekte O_i definiert, welche, in der Figur ganz links dargestellt, gewissermassen als Bibliothek im Rahmen des Basismoduls 1 zur Verfügung stehen. Diese Basis-Objektstrukturen sind im Basismodul 1 verfügbar und können abgerufen werden. Diese Objekte können beispielsweise Teile T; der Objektklasse "Part" umfassen, aber auch Dokumente D; der Objektklasse "Dokument" und so fort. Die einzelnen Objekte werden ausgewählt und zueinander in Beziehung gesetzt. So entsteht eine Struktur, wie sie im mit Basis 1 bezeichneten Abschnitt angegeben ist. Beispielsweise kann es sich in der hier angegebenen Struktur beim Objekt O₁ ₀ um eine Schraube handeln, beim Objekt 0₅ um eine Mutter und beim Objekt O₄ um ein Bauteil, wobei Schraube und Mutter in im Objekt O₂ definierter Weise in das Bauteil O₄ eingebaut werden.
Anschliessend an das Basismodul 1 wird dieser Zustand, der Konstruktionszustand, an das Bestellungsmodul 2 übergeben. In 2 ist gezeigt, dass hierbei ein weiteres Objekt O_best dieser Struktur übergeordnet wird, um zu kennzeichnen, dass es sich nun um eine Struktur im Bestellungsmodul handelt. Im Rahmen des Bestellungsmoduls wird nun das Objekt O₁ ₀ durch ein anderes Objekt O₉ ersetzt. Nach Abschluss der Phase im Bestellungsmodul im so genannten Bestellzustand wird dieser an das Montagemodul übergeben. Wiederum wird die Struktur durch O_mont gekennzeichnet, und im dargestellten Fall wird das Objekt O₇ durch das Objekt O₈ ersetzt sowie ein weiteres Objekt C₇ mit dem Objekt O₆ verknüpft. Ist die Montage abgeschlossen wird der Lieferzustand festgehalten und an das Servicemodul 4 übergeben. Nach entsprechender Kennzeichnung durch O_Serv wird im Beispiel ein Objekt O₁ ₀ zusätzlich mit dem Objekt O₂ verknüpft. Durch die Speicherung und Verknüpfung von Objekten wird die Speicherung redundanter Daten durch das System weitgehend verhindert.
3 zeigt, wie die Objekte mittels eines sogenannten Objektmasters 7, 8 eindeutig identifiziert werden. Zu jedem Objektmaster werden bei jeder Revision (Änderung, Überarbeitung) ein Objekt mit Lebenslaufdaten des Objektes angehängt. Dabei bezeichnet ein "-" die Neuerstellung eines Objektes, und die Grossbuchstaben A, B, C, ... bezeichnen sukzessive Revisionen eines Objektes. In 3a) kontrolliert in Objektmaster 7 der Objektklasse "Part" die Revisionen eines Objektes der Objektklasse Part. Die Zustände -,A,B sind überholt, der Zustand C gültig und freigegeben, und der Zustand D ist in Arbeit aber noch nicht freigegeben. Diese Art der Strukturierung erlaubt die exakte Verfolgung der einzelnen Arbeitsschritte, welche an einem Objekt vollzogen wurden.
3b) zeigt beispielhaft die Kontrolle eines Objektes der Objektklasse "Dokument" durch einen Objektmaster 8 der Objektklasse "Dokument". Es wird ersichtlich, wie die einzelnen Objekte auf die zu Grunde liegenden physischen Dokumente verweisen: Die Objekte sind meist nicht die eigentlichen, technische Information enthaltenden Dateien, sondern Zeiger auf einem Objekt zugeordnete technische Information enthaltende Dateien. Dabei können Objekte unterschiedlichen Bedingungen unterliegen, so können Objekte von bestimmten Typen nur auf ein weiteres Objekt oder physikalisches Dokument zeigen, bei anderen Objekten hingegen sind so genannte 1:n Beziehungen möglich.
4 zeigt weiterhin, wie bei Revision von Objekten die Datenstruktur verändert wird. 4a) zeigt eine Basisstruktur. Um die Struktur zu verändern, muss das Objekt am Knotenpunkt, an dem Objekte zugefügt oder entfernt werden sollen, revisioniert und freigegeben werden. Im Beispiel wird, wie in 4b) der Einfachheit halber ohne Objektmaster dargestellt, das Objekt O₃ zusätzlich mit dem Objekt O₁ ₃ verknüpft. Für bestimmte Objekte gilt eine l- Master zu n- Revision Beziehung. Im Konstruktionszustand sind alle Revisionen verfügbar, während z. B. ab dem Haltepunkt Bestellzustand nur die entsprechend definierte- Revision verfügbar ist. 4c) zeigt weiterhin die Verknüpfung eines Prüfplans OPP₁ mit den Prüfschritten OPS₁ bis OPS_n und dem Objekt O₁.
5 zeigt eine schematische Darstellung des Basismoduls 1. Im Basismodul erfolgt die Erzeugung, Revision und Freigabe sämtlicher Objekte, Attribute, im Speziellen der Objektklassen "Part" und "Dokumente". Bei Dokumenten erfolgt zudem die Zuordnung der Informationen und Dateien zum Basis-Objekt, also einem Master mit seinen Revision, als physische Dokumente. Die Erzeugung, Revision und Freigabe der basisrelevanten Objektbeziehungen zu einer "as designed" Struktur mit Varianten und Optionen ist eine wesentliche Funktionalität des Basismoduls.
Grundsätzlich werden im Basismodul Objekte wie beispielsweise "Teile", "Dokumente", "Bestellungen" erzeugt, diese Objekte miteinander zu einer Basisstruktur verknüpft und elektronisch mittels Workflow freigegeben. Dies ist in 5 schematisch dargestellt. Nach einer Startinstruktion 9 wird ein Objektgenerator 10 aufgerufen, welcher wahlweise die Generierung eines neuen Objektes oder eines revisionierten Objektes mit erhöhtem Revisionsstand erlaubt. Als Objekte stehen dabei unter anderem die Klassen "Part" T und "Dokument" D zur Verfügung. Dabei können die Objekte aus Bibliotheken bezogen werden, oder aber auch durch Migration oder manuelle Eingabe erzeugt werden. Mit einem "-" ist ausserdem die Möglichkeit einer ersten Erstellung eines Objektes dargestellt, und mit R die Möglichkeit, eine Revision vorzunehmen. Die Revisionen werden dabei fortlaufend mit den Buchstaben A-Z bezeichnet. Bei der Durchführung von Revisionen werden diese von einem Master geordnet, was in Zusammenhang mit 6 noch näher erläutert wird. Anschliessend werden diese Objekte in einer Verknüpfungseinheit 11 zur einer Objektstruktur, der Basisstruktur 101, verknüpft. Dabei werden die Verknüpfungen der Objekte ebenfalls als Objekte "Verknüpfung", "Relation" mit Attributen oder Dateien geführt. Die Attribute der Objekte können mit mehrsprachigen Texten versehen werden, hier ist die Übersetzungseinheit 16 von Bedeutung. Bei dem Objekt „Dokumente" wird zu einem Dokument, das beispielsweise mittels eines Textsystems erzeugt wurde, ein in einem Repräsentationsdaten-Generator 14 eine Repräsentationsdatei erstellt und diese Datei nach der elektronischen Freigabe durch die Zertifizierungseinheit 12 in der Stempeleinheit 15 mit einem „Stempel" zur Kennzeichnung der Freigabe ergänzt. Papierdokumente können in diesem Zusammenhang auch gescannt, registriert und mit dem Objekt „Dokument" verknüpft werden, falls keine Textdatei verfügbar ist. Es kann zum Objekt „Dokument" ein Objekt „Dokument-Übersetzung" erzeugt und je gewählte Fremdsprache elektronisch freigegeben werden.
Die Zertifizierungseinheit 12 regelt Freigabenprozesse wie Reviews; dies kann automatisch oder individuell geschehen. Wichtig ist, dass bereits im Basismodul ein freigegebenes Objekt meist nur über einen Revisionsprozess mit zwingend verlangtem Änderungsprotokoll geändert werden kann.
Von grosser Relevanz im Zusammenhang mit der gemeinsamen Arbeit an Objekten von verschiedenen Standorten aus ist zudem die Möglichkeit, ein Objekt mit einen Benachrichtigungs- Verteiler zu verknüpfen. Eine Benachrichtigungseinheit 13 steuert bei einer Revision des Objektes die automatische Benachrichtigung der betroffenen Stellen. In Abhängigkeit von Revisionsklassen werden so regelbasiert Entscheidungen getroffen und weitergeleitet.
In 6 ist die Verknüpfung von Einzelteilen zu Baugruppen und weiter zu Systemen im Basismodul schematisch dargestellt. Dabei sind Objekte D; der Objektklasse "Dokumente" und T; der Objektklasse "Parts" sowie die Objekt-Master T_iM und D_iM dargestellt. Die Objektbeziehungen sind in Form von Pfeilen visualisiert. Die durchgezogenen Linien stellen die tatsächlichen Objektbeziehungen der aktuellen Revisionsstände dar. Die gestrichelten Linien stellen die Objektbeziehungen überholter Revisionen dar. Die gepunkteten Linie stellen die Objekt – Master-Beziehungen dar. Erkennbar ist im dargestellten, an sich sehr einfachen Fall, folgender Sachverhalt: Eine Baugruppe T₁ ist durch einen Master T₁ _M repräsentiert, der auf zwei Revisionen T₁ _R _:- T_R:A verweist. T_1R:Aist die höchste und aktuelle Revision; T₁ _R _:- ist eine überholte Revision. T₁ verweist auf die Einzelteile T₂ und T₃, jeweils in einer spezifischen Revision. Die Einzelteile T₂ und T₃ sind wiederum als Master und Revisionen dargestellt. Die Objekte T_i der Klasse "Parts" verweisen auch auf Objekte D; der Klasse "Dokumente". Die Dokumente sind, ebenso wie die Teile, durch Objekt-Master D_iM und Revisionen D_iR _:j repräsentiert. Die Dokumentrevisionen verweisen im Beispiel weiter auf physische Dokumente D. "Dokument"-Objekte und "Part"-Objekte sind also in vollkommen analoger Weise mit Mastern und Revisionen organisiert, was die Verwaltung der Daten stark vereinfacht.
Zusammenfassend ist in 6 gezeigt, wie Objekte „Einzelteil" zu „Baugruppen" und diese zu „Systemen" verknüpft sind, und inklusive aller Objekte „Dokumente" als Produkt-Struktur dargestellt werden. Das System erlaubt es dabei, diese Produkt-Struktur jederzeit in aktualisierter Form zu visualisieren.
Bereits im Basismodul wie in den anderen Modulen sind Möglichkeiten vorgesehen, Prüfprozesse zu automatisieren. So können zum Beispiel Objekte „Prüfprozess" mit Objekten „Prüfschritten" und dieser mit Objekten „Prüfdokumente", welche Prüfanweisungen und Prüfprotokolle enthalten, verknüpft werden, und der „Prüfprozess" kann dem zu prüfendem „Teil" zugeordnet werden. So werden beispielsweise in der Darstellung in 5 vom dort dargestellten Repräsentationsdaten-Generator 14 und der Stempeleinheit 15 oder der Übersetzungseinheit 16 speziell zertifizierte Dokumente mit einem "Stempel" versehen, sofern dies notwendig ist.
Das Basismodul wird in einem Haltepunkt abgeschlossen, welcher als Konstruktions- oder "as designed" -Zustand bezeichnet wird, und welcher dazu dient, den Abschluss der Konstruktionsphase zu dokumentieren und abrufbar zu halten. So kann der Produktlebenslauf jederzeit nachvollzogen werden.
7 zeigt eine stark schematisierte Darstellung der Operationen im Bestellmodul. In diesem Modul erfolgt die Erzeugung, Revision und Freigabe der bestellungsrelevanten Objektbeziehungen zu einer Bestell- oder "as ordered" -Struktur. Zusätzlich erfolgt die Zuordnung von rein bestellungsrelevanten Objekten Das Modul wird mit einem Haltepunkt abgeschlossen, in dem der Bestell- oder "as ordered" -Zustand festgehalten wird. Dabei wird der Konstruktionszustand als Eingabewert und Startzustand verwendet. Die Basisstruktur 101 dient als Eingabestruktur für das Bestellmodul. Die Eingabestrukture werden zunächst in einer Konfigurationsroutine 17 bearbeitet. Die erstellte Bestellungs-Struktur wird selektiv an die spezifischen Kundenanforderungen angepasst. Dies kann manuell oder automatisiert mittels der Konfigurationseinheit 17 erfolgen. Der Konfigurator ermöglicht mittels Entscheidungstabellen bei Objekten mit Varianten, die erforderlichen Merkmale auszuwählen und festzulegen, und somit die Bestellungsstruktur eindeutig zu definieren. Mit anderen Worten wird ausgehend von der Produkte-Struktur des Basismoduls eine Bestellungsstruktur ausgehend von einem Top Part /Top System erzeugt. Mit den Teilen und/oder Systemen verbundene Dokumentobjekte und Prüfobjekte werden in die Konfigurationseinheit 17 übernommen, in welchem Optionen zur Verfügung gestellt werden. In der anschliessenden selektiven Bestellungsanpassungseinheit 18, in welchem die gewählten Optionen festgelegt werden, werden diese Optionen der spezifischen Bestellung des Kunden effektiv angepasst, und es wird die Bestellstruktur 102 erzeugt. Die Optionen werden in einem Parameterobjekt festgelegt. Danach erlaubt ein Differenzreportgenerator 19 eine Überwachung und Kontrolle der Änderungen, denn Bestellungsstrukturen unterliegen einem Änderungsdienst. Für jede Änderung wird entsprechend ein Differenzreport erstellt. Differenzreports können sowohl zwischen den Revisionsständen einer Bestellung, wie Order Rev.: A zu Order Rev.: B, oder auch zwischen Bestellungen, Order A zu Order B, erzeugt werden. Ob Änderungen aus der Basisstruktur in die Bestellungsstruktur übernommen werden, wird vom zuständigen Bestellungsmanager entschieden. Dies kann auch automatisiert aufgrund zu berücksichtigender Änderungsklassen erfolgen. Optional wird wiederum eine Zertifizierungseinheit 12 durchlaufen, wie sie bereits in Zusammenhang mit dem Basismodul beschrieben wurde, sowie wiederum eine Benachrichtigungseinheit 20, welche auch als "Watchdog" bezeichnet wird, welche eine automatische Versendung von Benachrichtigungen an alle Betroffenen erlaubt.
Eine entsprechende Struktur, welche im Bestellungsmodul bearbeitet wurde, ist in 8 dargestellt. Dabei ist ersichtlich, dass auch ein bestimmter Bestellungszustand wiederum als Objekt dargestellt wird, und wiederum Revisionen unterzogen werden kann. Bestellobjekt-Master O_best,M verweist auf die im Ausführungsbeispiel einzige Version O_best,R. Dieses Objekt der Objektklasse "Bestellung" verweist auf die Baugruppe T₁ in der Revision A. Die zugehörige Produktestruktur, die hier nur im aktuellen Revisionszustand dargestellt ist, ist oben im Zusammenhang mit der 6 bereits detailliert erläutert. Ein spezielles Bestellungsmodul ist das Modul Bestellung – Produktion, das spezielle Informationen zur Fertigung, wie zum Beispiel Fertigungszeichnungen und Fabrikationsanweisungen enthält. Das Bestellungsmodul wird mit einem Haltepunkt abgeschlossen, in dem der Bestell- oder "as ordered"-Zustand" -Zustand festgehalten wird. Die eingangs erwähnte rein virtuelle Phase des Wertschöpfungsprozesses ist mit Erreichen dieses Haltepunktes abgeschlossen.
Im Montagemodul wird die eigentliche Herstellung und/oder der Zusammenbau des Produktes nachvollzogen. Es findet eine reale Wertschöpfung statt, weshalb das Montagemodul und das diesem nachgeordnete Service-Modul der reellen Phase des Wertschöpfungsprozesses zugeordnet werden. Es erfolgt die Erzeugung, Revision und Freigabe der montage-relevanten Objektbeziehungen zu einer "as built / as maintained" Struktur mitsamt der Zuordnung der rein montagerelevanten Objekte. Dabei wird ausgehend von der Bestellungsstruktur die vom Lieferanten / Auftragnehmer die tatsächlich gelieferte Struktur abgebildet. Der wesentliche und grundsätzliche Aufbau des Montagemoduls ist schematisch in 9 dargestellt. Ein Lieferant oder das Monteur fügt, wo erforderlich, zusätzliche oder ergänzende respektive ergänzte Dokumente, wie beispielsweise Istwerte zu Prüfprotokollen, in die Montage-Struktur ein. Eine erste Routine, der Abweichungsreport-Generator 21, hält erst bei der Montage ersichtliche und notwendige Änderungen und daraus resultierende Abweichungen von der Spezifikation fest, und es werden sogenannte Abweichungsmeldungen oder Non Conformance Reports, NCRs, erstellt und mit der Struktur verknüpft. In einer zweiten Routine Testreports 22 werden Spezifikationsprotokolle und Tests in der Struktur, wie sie tatsächlich hergestellt wurde, mit den entsprechenden virtuellen Informations-Strukturen, die beispielsweise und insbesondere aus dem Bestellmodul stammen, verbunden. Damit wird ausgehend von der – virtuellen – Bestellstruktur die – reelle – Lieferstruktur 103 erzeugt. Der Zugriff der zwei Routinen 21 und 22 auf die Lieferstruktur 103 erfolgt auf bereits erläuterte Weise über eine Zugriffsschutzroutine 5. Auch im Montagemodul wird mit Vorteil eine Benachrichtigungseinheit vorgesehen, mit welcher Benachrichtigungen an betroffene Mitarbeiter automatisch verschickt werden können. 10 zeigt eine Objektstruktur im Montagemodul, bei welcher nun der Montage-Zustand wiederum als Objekte O_mont,R:- mit entsprechendem Master O_mont,R:- zusätzlich eingebunden ist. Der Arbeitsfortschritt wird fortlaufend protokolliert. Das Montagemodul wird im Haltepunkt Lieferzustand, "as built"-Zustand, abgeschlossen.
Im Servicemodul erfolgt die Zuordnung von wartungs- und betriebsrelevanten Objekten zu den Objekten innerhalb der Liefer-, "as built"-, -Struktur oder Betriebs- und Wartungs-, "as maintained"-, -Struktur in Abhängigkeit zeitlich definierter Ereignisse. Ausgangszustand ist der Lieferzustand, welcher vom Montagemodul übernommen wird. In einer ersten Routine "Serviceobjekte"-Einheit 23 erfolgt ein Zugang zu der Produktdaten-Struktur, die beispielsweise bei der Durchführung Wartungs- oder Reparaturmassnahmen geändert wird. Dabei handelt es sich um eine Eingaberoutine. In der Routine "Betriebsobjekte" 24 erfolgt unter anderem ein sogenanntes Betriebsdaten-Logging. Dabei werden die Betriebsdaten für den laufenden Betrieb bevorzugt kontinuierlich oder quasikontinuierlich oder auch zu diskreten Zeitpunkten aufgezeichnet. Der Zugriff auf die eigentliche Datenstruktur, Service-Struktur 104, erfolgt wie gehabt über eine Zugriffsschutzroutine 5, welche spezifisch entsprechend der jeweiligen Phase der Wertschöpfung konfiguriert ist. 12 zeigt ein Beispiel für eine Struktur, wie sie im Servicemodul erzeugt und bearbeitet wird.
Grundsätzlich bestehen im Rahmen aller Module 1 bis 4 zugeordnete Relationen zwischen Objekten. Objekte werden miteinander zu Strukturen verbunden. Diese Verbindung kann, falls sinnvoll, ebenfalls Informationsdaten wie Dateien und Änderungsprotokolle enthalten. Zur Absicherung eines kontrollierten Zugriffs auf die Daten wird eine Zugriffsschutzroutine zur Verfügung gestellt. In diesem wird selektiv je nach Phase/Modul, Produktgruppe, Funktion und Rolle auf die Objekte und deren Verknüpfungen zu Produktstrukturen über weltweit verteilte Standorte elektronisch der Zugriff freigegeben. Die Zugriffsschutzroutine regelt den Datenzugriff auf alle beschriebenen Module. Nur berechtigte Personen, User, können Objekte und deren Daten erzeugen, verändern, freigeben und einsehen.
Zusammenfassend ergibt sich folgendes Vorgehen: Im Basismodul werden Basis-Objekte für die Module Bestellung, Montage- und Service, sowie die Strukturen des Produktes in Form von Verknüpfungen der Objekte erstellt. Diese Basisstrukturen werden im Konstruktionszustend eingefroren und erhalten den Status Konstruktionszustand, "as designed". Die Basisstrukturen werden in eine initiale Orderstruktur kopiert, wobei sowohl eingefrorene als auch nicht eingefroren Strukturen verwendet werden können. Allerdings bedingen letztere in der Bestellungsstruktur Nachbearbeitungen durch manuelle Konfigurationen. Eine abgeschlossene Bestellung kann in den Status Bestellzustand, "as ordered", überführt werden. Bestellungsstrukturen werden, sobald die Bestellung komplett ist, an das Montagemodul übergehen. Die Montagestruktur wird vervollständigt und in den Status Lieferzustand, „as assembled", überführt. Real fertiggestellte Produktstrukturen werden an das Servicemodul übergeben. Das Servicemodul dokumentiert zu jeder Revision die entsprechende Struktur mit allen angehängten Dokumenten, inklusive der zugehörigen Prüfdokumentation. Differenzreports können bei Bedarf zwischen den Objekten und deren Revisionen bei allen Modulen durch automatischen Strukturvergleich erzeugt werden.
Die Verwaltung der Objekte und Produktstrukturen wird durch die hierarchische Organisation der Objekte in Objektmaster und von diesen verwaltete Revisionen erleichtert, wobei für bestimmte Objekte eine 1 Master zu n Revisionen Beziehung, auch als "1:n" Beziehung bezeichnet, gilt. Die Möglichkeit zum Zugriff auf bestimmte Revisionen ist in Abhängigkeit vom jeweiligen Modul vorgegeben. Während im Konstruktionszustand alle Revisionen eines Objektes verfügbar sind, sind ab dem Bestellzustand nur noch die im Order-Objekt definierten Revisionen zugänglich.
Das vorliegende Verfahren lässt sich mit Vorteil auf einer Oracle-Datenbank mit der Software von Metaphase (SDRC, Cincinnati, Ohio) realisieren.

1: Basismodul
2: Bestellungsmodul
3: Montagemodul
4: Servicemodul
5: Zugriffsschutzroutine
6: Benutzerschnittstelle, User Interface
7: Objektmaster
8: Objektmaster
9: Startinstruktion
10: Objektgenerator
11: Verknüpfungseinheit
12: Zertifizierungseinheit
13: Benachrichtigungseinheit, Messenger Unit, Watchdog
14: Repräsentationsdaten-Generator
15: Stempeleinheit
16: Übersetzungseinheit
17: Konfigurationseinheit
18: Bestellungsanpassungseinheit
19: Differenzreport-Generator
20: Benachrichtigungseinheit, Messenger Unit, Watchdog
21: Abweichungsreport-Generator, NCR-Generator
22: Testreporteinheit
23: Serviceobjekt-Einheit
24: Betriebsobjekt-Einheit
101: Basisstruktur
102: Bestellstruktur, Order-Struktur
103: Lieferstruktur, Assembly-Struktur
104: Service-Struktur
I: erstes Phase, virtuelle Phase
II: zweites Phase, reelle Phase
O_i: Objekt i (allgemeiner Oberbegriff)
O_i-: Neuerstellung des i-ten Objekts
T_i: Teil i (Objektklasse Part)
D_i: Dokument i (Objektklasse Dokument)
R: Revisionen
M: Master
OPP_i: Objekt Prüfplan
OPS_i: Objekt Prüfplanschritte

Claims

Verfahren zur Erzeugung und Pflege von Produktdaten, wobei produktrelevante Daten über den gesamten Wertschöpfungsprozess der Produkte von einer ersten Stufe der Entwicklung bis hin zum Betrieb und zur Wartung eines Produktes in wenigstens einer zentralen Datenbanken erzeugt und gepflegt werden, und wobei der Wertschöpfungsprozess in zwei Phasen (I, II) aufgeteilt wird, von denen die erste Phase (I) einen rein virtuellen Abschnitt des Wertschöpfungsprozesses und die zweite Phase (II) einen dem ersten Abschnitt nachfolgenden virtuellen und reellen Abschnitt des Wertschöpfungsprozesses umfasst, wobei die erste Phase und die zweite Phase im Wertschöpfungsprozess nacheinander durchlaufen werden und die produktrelevanten Daten an einer Schnittstelle zwischen der ersten und der zweiten Phase von der ersten zur zweiten Phase übergeben werden, und bei welchem Verfahren die Möglichkeiten von Erzeugung, Zugriff, Revision, und/oder Ausführbarkeit der Daten in Abhängigkeit davon definiert werden, in welcher Phase (I, II) des Wertschöpfungsprozesses das Produkt sich befindet.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die erste Phase (I) ein Basismodul (1) und ein Bestellungsmodul (2) umfasst, welche Module (1,2) im Wertschöpfungsprozess nacheinander durchlaufen werden und die produktrelevanten Daten an einer Schnittstelle zwischen dem Basismodul und dem Bestellmodul vom Basismodul zum Bestellmodul übergeben werden, wobei das Basismodul (1) die Phase der reinen Entwicklung umfasst, und das Bestellungsmodul (2) die Phase der Anpassung des entwickelten Produktes an die Spezifikationen einer Bestellung umfasst, und wobei die Möglichkeiten von Erzeugung, Zugriff, Revision, und/oder Ausführbarkeit der Daten in Abhängigkeit davon definiert werden, in welchem Modul (1,2) das Produkt sich befindet.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die zweite Phase (II) ein Montagemodul (3) und ein Servicemodul (4) umfasst, welche Module (3,4) im Wertschöpfungsprozess nacheinander durchlaufen werden und die produktrelevanten Daten an einer Schnittstelle zwischen dem Montagemodul und dem Servicemodul vom Montagemodul ersten zum Servicemodul übergeben werden, wobei das Montagemodul (3) die Phase der realen Montage des Produkts bis zur ersten Inbetriebnahme umfasst und das Servicemodul (4) die daran anschliessende Phase des Betriebs des Produkts umfasst, und wobei die Möglichkeiten von Erzeugung, Zugriff, Revision, und/oder Ausführbarkeit der Daten in Abhängigkeit davon definiert sind, in welchem Modul (3,4) das Produkt sich befindet.
Verfahren nach einem der Ansprüche 2 oder 3, dadurch gekennzeichnet, dass an der Schnittstelle von einem Modul in das nächstfolgende Modul ein Haltepunkt definiert wird, und der Zustand des Produkts bei diesem Übergang in nicht mehr veränderbarer Weise festgehalten und abgespeichert wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Produktdaten in Form von Objekten (Oi) definiert werden, wobei die Objekte zu Objektstrukturen miteinander verknüpft werden, sodass die Speicherung redundanter Daten verhindert wird, und wobei die Möglichkeiten von Erzeugung, Zugriff, Revision, und/oder Ausführbarkeit der Objekte objektspezifisch und in Abhängigkeit davon definiert sind, in welcher Phase (I, II) respektive in welchem Modul (1-4) das Produkt sich befindet.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Produktdaten zusätzlich in Form von den Objekten (Oi) zugeordneten Informationen definiert werden.
Verfahren nach einem der Ansprüche 5 oder 6, dadurch gekennzeichnet, dass die Objekten (O _i) in verschiedene Objektklassen wie Teile (T_i), Einzelteile, Baugruppen, Systeme, Prüfprozess, Prüfschritt, Dokumente (D_i), Bestellung (O_best), Montage (O_mont.), Service (O_Serv), unterteilt werden.
Verfahren nach einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, dass eine Bearbeitung von zur Bearbeitung freigegebenen Objekten (O_i), nach einem Änderungsprotokoll auf Zulässigkeit und Regelmässigkeit überprüft und vorgenommen wird.
Verfahren nach einem der Ansprüche 5 bis 8, dadurch gekennzeichnet, dass Objekte (O _i) mit einem Benachrichtigungs-Verteiler (13) verknüpft werden, und, dass bei einer Revision eines derartigen Objektes diesem Verteiler entsprechend automatisch Informationene versandt werden und/oder in Abhängigkeit von Revisionsklassen regelbasiert Entscheidungen getroffen und weitergeleitet werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Zugriff auf die Produktdaten über eine Zugriffsschutzroutine (5) und eine Benutzerschnittstelle (6) weltweit elektronisch erfolgt, und dem zugreifende Benutzer in Abhängigkeit vom Produkt selektiv eine Berechtigungsebene zugewiesen wird.
Verwendung eines Verfahrens nach einem der Ansprüche 1 bis 10 im Zusammenhang mit Systemen und Komponenten für Maschinen insbesondere im Bereich von Stromerzeugung, Gasturbinenanlagen, Dampfturbinenanlagen Wasserturbinenanlagen und Kombikraftwerken.
Computerprogrammsystem zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 10, respektive zur Verwendung nach Anspruch 11.