DE69428279T2

DE69428279T2 - Produktstrukturverwaltung

Info

Publication number: DE69428279T2
Application number: DE69428279T
Authority: DE
Inventors: Richard Koko; D. Stewart
Original assignee: Electronic Data Systems LLC
Current assignee: Siemens Industry Software Inc
Priority date: 1993-06-29
Filing date: 1994-06-27
Publication date: 2002-06-27
Anticipated expiration: 2014-06-28
Also published as: JP3170646B2; AU683676B2; CA2165944C; BR9406913A; EP0706691A1; AU7251094A; EP0706691B1; CA2165944A1; JPH08512157A; RU2119188C1; US5434791A; DE69428279D1; WO1995001610A1

Description

TECHNISCHES GEBIET DER ERFINDUNG

Die Erfindung betrifft computergestützte Produkt-Konstruktion und insbesondere ein Verfahren zum Managen der Struktur eines Produkts im Verlauf von Konstruktions- und Herstellungs- Prozessen.

HINTERGRUND DER ERFINDUNG

"Produkt-Daten-Management" (PDM) ist ein Begriff, der verwendet wird, um computergestützte Verfahren zum Managen von Produkt-Konstruktion und Produkt-Herstellung zu beschreiben. Ein Beispiel eines PDM-Systems ist das Informations-Manager-System, das von Electronics Data Systems verkauft wird. Die Konstruktion des Informations-Manager-Systems basiert auf den Objekten, die es manipuliert. Ein primärer Fokus des Systems ist das Darstellen der Weiterentwicklung hinsichtlich seiner Objekte und der Vorgänge an ihnen. Objekt-Klassen werden durch Entwickeln von Weiterentwicklungs-Operationen abgeleitet, wie zum Beispiel Konstruktion, Herstellung, Administration, Projekt-Management sowie Kosten-Kontrolle.
Systeme für computergestützte Konstruktion und computergestützte Herstellung (CAD/CAM) sind ein weiterer Typ von computergestützter Herstellungs-Unterstützung. Sie werden allgemein von Konstruktions-Ingenieuren verwendet, um präzise Geometrien von Produkt-Konstruktionen und Produkt-Revisionen zu entwickeln.
Sowohl PDM als auch CAD/CAM sind in der heutigen Produkt- Konstruktions- und Herstellungs-Umgebung hilfreich. Vorhandene CAD/CAM-Systeme und PDM-Systeme bringen jedoch die Anforderungen von verschiedenen Typen von potentiellen Benutzern nicht wirksam in Einklang, die mit der Produkt-Konstruktion und -Herstellung beschäftigt sind. Ein erster Typ von Benutzer, wie zum Beispiel ein Konstruktions-Ingenieur, ist an den präzisen Konfigurationen eines Produkts sowie an der Bilanzierung von Revisions-Alternativen interessiert. Ein zweiter Typ von Benutzer, wie zum Beispiel ein Produktions-Ingenieur beschäftigt sich allgemein mit ungenauen Konfigurationen, die verschiedene Revisionen des gleichen Produkts beinhalten können. Beispielsweise möchte der Produktions-Ingenieur auf ein Basis-Produkt zurückkommen, dessen Komponenten bezüglich einiger Daten und Seriennummern verändert wurden.
Es ist in der Technik bekannt, einen Computer zu verwenden, um verschiedene Typen von Objekten zu speichern, die verwendet werden können, um eine Material-Liste zu erzeugen. Beispielsweise offenbart die EP-A-0 520 923 ein Verfahren und ein System für die Definition und für das Verfolgen von mehreren einzelnen Produkt-Konfigurationen für das Konfigurations-Management, in dem mit Kunden vereinbarte Ansichten von dem Produkt definiert sind, indem temporäre Veränderungen der Basis-Produkt-Konfiguration angewendet werden.
Die EP-A-0 483 039 offenbart ein System und ein Verfahren zum Speichern und Wiederauffinden von sowohl Zeit-orientierten Versionen als auch von Ansichts-orientierten Versionen von Entwicklungs-Veränderungs-Informationen, wobei die Entwicklungs- Veränderungs-Informationen durch ein Satz von Status-Zuständen fortschreiten und der Zugriff auf die Daten durch verschiedene Benutzer-Gruppen durch den Status der Information konditioniert wird. Eine Versions-Steuer-Software-Logik ermöglicht es den Benutzern, Versions-Objekte durch logisches Schlüssel-Gruppieren von Datenelementen zu erzeugen. Die Versions-Steuer-Logik wirkt auf die logischen Schlüssel und speziellen Versions-Attribute dieser Objekte für die genaue Spezifikation und Selektion von Objekt-Beispielen während der Erzeugungs-, Aktualisierungs- oder Wiederauffindungs-Vorgänge.
Es besteht die Forderung nach einer computergestützten Produktions-Unterstützung; die den Anforderungen von beiden Typen von Benutzern genügt.

ZUSAMMENFASSUNG DER ERFINDUNG

Die vorliegende Erfindung betrifft ein Verfahren nach Anspruch 1 oder nach Anspruch 7.
Ein computergestütztes Produkt-Struktur-Management System (PSM) speichert Daten, die eine ungenaue Struktur von einem Produkt darstellen, und zeigt Daten, die eine genaue Struktur von diesem Produkt darstellen. Das PSM speichert eine Beschreibung von jeder Komponente von dem Produkt als ein Objekt einer Sicht-Daten-Klasse. Es speichert außerdem eine Beschreibung von einer Revision bezüglich einer Komponente als ein Objekt einer Sicht-Revisions-Daten-Klasse. Es verbindet Sicht-Objekte und Sicht-Revisions-Objekte mit Vorkommnis-Referenzen miteinander und mit Sicht-Objekten und Sicht-Revisions-Objekten von anderen Komponenten. Während seiner Run-Time-Operation empfängt es eine Eingabe von einem Benutzer, wodurch ein darzustellendes Produkt spezifiziert wird. Wenn die Spezifikation ungenau ist, wendet es Konfigurations-Regeln an, um zu bestimmen, welche Sicht-Revision von jeder Komponente verwendet werden soll. Für jede Komponente von dem Produkt findet es ein Objekt der Sicht-Daten-Klasse oder ein Objekt der Sicht-Revisions-Daten-Klasse und baut einen Satz von Sicht-Objekten und Sicht-Revisions-Objekten zusammen, indem die Vorkommnis-Referenzen verwendet werden. Das Ergebnis ist eine Struktur-Liste von Gegenständen des Produkts.
Ein Vorteil von dem PSM-System besteht darin, daß es die Fähigkeit zur Verfügung stellt, eine Produkt-Struktur mit einer Material-Liste zu bilden, wodurch das Produkt hinausgehend über seine einfache Geometrie dargestellt wird.
Das PSM-System speichert Daten, die ungenaue Anordnungen von einem Produkt darstellen, aber genaue Anordnungen erzeugen können. Dies ermöglicht die Schaffung einer "virtuellen Anordnung" aus irgendeiner Kombination aus Komponenten oder aus Revisionen von Komponenten. Alle Revisionen sind zur Verwendung in einer virtuellen Anordnung austauschbar.
Die Fähigkeit, mehr als eine Ansicht für verschiedene Versionen des gleichen Produkts zusammenzubauen, ermöglicht gleichzeitig die Entwicklung von verschiedenen Aspekten des gleichen Produkts. Zum Beispiel kann die Konstruktions- und Produktions- Abteilung des gleichen Unternehmens gleichzeitig an der Produkt- Weiterentwicklung teilnehmen.
Das PSM-System kann die Geschäfts-Regeln von einem Unternehmen zur Verwaltung der Produkt-Anordnung beinhalten. Dadurch ist das PSM-System besser in der Lage, die Anforderungen von einem bestimmten Benutzer zu übernehmen.
Das PSM-System speichert Geschichten von Revisionen bezüglich einzelner Komponenten des Produkts. Wenn daher an einem Produkt eine Änderung durchgeführt wurde, und diese letztere als falsch erachtet wird, dann kann der Benutzer die vorhergehende Version rekonstruieren.
Das PSM-System kann mit einem CAD/CAM-System integriert werden, um geometrische Modelle von einem Produkt zur Verfügung zu stellen. Material-Listen können durch das PSM-System erzeugt und durch CAD/CAM-Geometrien verbessert werden. Umgekehrt können in der CAD/CAM-Abbildungs-Umgebung Geometrien erzeugt und verwendet werden, um Material-Listen zur Verwendung durch das PSM- System zu erzeugen.

KURZBESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 zeigt ein computergestütztes PDM-System, das ein PSM-System gemäß der Erfindung beinhaltet.
Fig. 2 zeigt eine Übersicht von dem Betrieb des PSM.
Fig. 3 zeigt eine Anzeige von einem Bereich von einer Material-Liste (BOM) für ein bestimmtes Produkt.
Fig. 4 zeigt eine vergrößerte Anzeige von einer Material- Liste.
Fig. 5 zeigt, wie PSM verschiedene Ansichten von der gleichen Gegenstands-Revision bildet.
Fig. 6 zeigt die Beziehungen zwischen den Daten-Klassen, Gegenstand und Gegenstands-Revision.
Fig. 7 zeigt die Beziehung zwischen den Daten-Klassen, Sicht und Sicht-Revision.
Fig. 8 zeigt, wie ein Konfigurations-Objekt (CO) erzeugt wird, um die Beziehungen zwischen Gegenstands-Revisionen zu managen.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

Fig. 1 zeigt ein Computersystem zum Implementieren eines Produkt-Daten-Manager-Systems (PDM) 10, mit dem ein Produkt- Struktur-Manager (PSM) 12 integriert ist. Der PSM 12 ist ein Typ von PDM-Modul, das sich mit der Speicherung von Produkt- Revisions-Geschichten und mit dem Zusammensetzen von verschiedenen Konfigurationen von einem Produkt aus diesen Revisionen beschäftigt, und zwar gemäß der hier beschriebenen Erfindung. Wie in dem Hintergrund-Abschnitt erläutert, ist ein Beispiel von einem PDM-System 10, ohne PSM 12, der Informations-Manager, ein Produkt von Electronic Data Systems.
PSM 12 ist im Speicher von einem herkömmlichen Computersystem 12, wie beispielsweise ein VAX/VMS- oder ein UNIX-System, gespeichert und wird von diesem ausgeführt. Üblicherweise ist das Computersystem ein Teil von einem verteilten Netzwerk von Arbeitsstationen mit einer Anzahl von Computern 11. In dem Beispiel von dieser Beschreibung enthält das Betriebssystem ein Untersystem vom Window-Typ, das verschiedene graphische Benutzer-Schnittstellen unterstützt, wie zum Beispiel Dialog-Boxen und Auswahl-Tasten. Der Computer 11 steht mit Eingabe- und Ausgabe-Vorrichtungen in Verbindung, die für den Zweck dieser Beschreibung eine Tastatur, eine Zeiger-Vorrichtung und eine Graphik-Anzeige sind.
PSM 11 kann mit anderen PDM-Modulen 12a integriert sein, die verschiedene PDM-Aufgaben implementieren. Ein Vorteil der Implementierung von PSM 12 als ein Teil von einem umfassenderen Satz von PDM-Modulen 12a besteht darin, daß es von Daten aus anderen Programm-Modulen Gebrauch machen kann und Daten zu diesen liefern kann. Beispielsweise kann ein Weiterentwicklungs- Prozess-Manager-Modul (EPM) den Prozess bilden, durch den Produkte für die Herstellung empfohlen werden, wobei Daten von diesem Modul dem PSM 12 zur Verfügung gestellt werden, um anzugeben, daß eine bestimmte Konfiguration von einem Produkt einen "genehmigten" Status hat. Ein Weiterentwicklungs-Resourcen- Manager-Modul (ERM) kann modellieren, wie Resourcen, wie zum Beispiel Material und Mitarbeiter zugeteilt werden.
Wie nachfolgend erläutert wird, speichert PSM 12 ein Modell von zumindest einem Produkt. Das Computerprogramm, das verwendet wird, um PSM 12 zu implementieren, basiert auf einer Objektorientierten Konstruktion. Daher stehen Daten mit Klassen in Beziehung, die Hierarchien und Beziehungen haben. Klassen spezifizieren, welche Daten sie speichern und welche Vorgänge an ihnen durchgeführt werden können. Beispiele von Daten-Klassen sind Objekte und werden durch Abbildung der Operationen von verschiedenen Anwendungs-Bereichen abgebildet. Es sind Darstellungen dieser Objekte, die durch die Benutzer-Schnittstelle 16 manipuliert werden.
Das Datenmodell, das durch PSM 12 gespeichert wird, enthält Objekte der Daten-Klassen, den Gegenstand und die Gegenstands- Revision, die sich auf Daten-Klassen, Sicht und Sicht-Revision beziehen. Im wesentlichen stellen ein Gegenstand und eine Gegenstands-Revision eine Komponente von einem Produkt dar. Wie anschließend erläutert wird, sind die Daten-Klassen, Sicht und Sicht-Revision Attribute von dem Gegenstand und Gegenstands- Revisions-Daten-Klassen und ermöglichen es, daß jede Komponente mehr als eine Version hat.
Die PDM-Plattform 14 stellt eine Basis zur Verfügung, auf der der Rest des Systems 10 aufgebaut ist. Sie hat mehrere Module, einschließlich eines Dauer-Objekt-Managers (POM). Das POM stellt folgende Service-Leistungen zur Verfügung: Abbilden von Gegenstands-Darstellung zu Beziehungs-Darstellung, Benachrichtigen und gleichzeitige Zugriffs-Steuerung. Im Allgemeinen isoliert die Plattform-Schicht 14 das PSM 12 von dem Betriebs- System und anderen Unter-Systemen des Computers 11.
Die Benutzer-Schnittstellen-Schicht 16 enthält Benutzer- Anwendungs-Programmierungen, die auf der darunterliegenden Architektur aufgebaut sind. Da das PSM 12 über eine Benutzer- Schnittstelle 16 kundenorientiert konstruiert ist, entspricht es der Programm-Strategie, die oft als "Toolkit"-Konstruktion bezeichnet wird.
Entsprechend dem "Toolkit"-Versuch enthält PSM 12 einen gespeicherten Satz an "generischen" Funktionen. Im Anhang sind verschiedene Funktionen aufgeführt, die an Objekten von PSM 12 durchgeführt werden können. Insbesondere sind diese Funktionen in dem PSM 12 vorgesehen, so daß die Benutzer-Schnittstelle 16 Nachrichten zu Objekten weiterleiten kann.
Fig. 2 stellt einen Überblick der Funktion von PMS 12 dar, zusammen mit einem Beispiel von jedem Schritt. Im wesentlichen ist PSM 12 ein interaktives Verfahren zum Anwenden eines Computers zum Abbilden und Verwalten der Struktur von einem Produkt und dessen Revisionen. Es soll verstanden werden, daß viele der Schritte das Empfangen von Daten-Eingängen von einem Benutzer beinhalten. Zum Zwecke dieser Beschreibung wird angenommen, daß der Benutzer ein menschlicher Benutzer ist, aber in einigen Fällen kann die Eingabe durch andere Programme erzeugt werden. Daher kann der hier bezeichnete "Benutzer" ein menschlicher Benutzer oder ein Computer sein.
Wie in Schritten 21 und 22 angegeben, sind Produkt-Gegenstände und Revisionen von diesen dargestellt und als Ansichten und Sicht-Revisionen. In dem Beispiel von Fig. 2 hat das Produkt 1 (das auch ein Gegenstand sein kann) drei Komponenten. Jeder Gegenstand ist durch eine Ansicht dargestellt, zum Beispiel V-1-1, V-1-2 und V-1-3. Eine Ansicht V-1-1 hat drei Sicht- Revisionen VR-1-1-1, VR-1-1-2 und VR-1-1-3. Wie nachfolgend in Verbindung mit Fig. 4 erläutert, sind Ansichten und Sicht-Revisionen als Identifizierer, Beschreibungen und angehängte Objekte gespeichert, wie zum Beispiel Zeichnungen.
Ein Merkmal von PSM 12 ist die Fähigkeit, Daten zu speichern und zu bearbeiten, die ungenaue Konfiguration des gleichen Produkts darstellen. Da jeder Gegenstand von dem Produkt eine oder mehrere Revisionen haben kann, ist das gespeicherte Modell ungenau. Wie in Schritt 23 angegeben, ermöglicht PSM 12 diese ungenaue Produkt-Beschreibung durch Bezugnahme von Ansichten und Sicht-Revisions-Objekte mit "Vorkommnis"-Objekten. Allgemein ermöglicht die Vorkommnis-Beziehung, daß eine Produkt-Struktur ungenau gespeichert wird, indem die Informationen gespeichert werden, daß eine Ansicht eine andere verwendet, ohne daß Referenzen für spezielle Sicht-Revisionen erforderlich sind.
Wie in Schritten 24 und 25 angegeben, wenn ein Benutzer ein genaues Produkt ansehen möchte, kann er entweder das Produkt genau spezifizieren oder das Produkt ungenau mit einer Art von Beschreibung anfordern, welche Konfiguration es haben soll. Ein Beispiel des Letzteren kann eine Anfrage sein, wie zum Beispiel "Zeigen mir Produkt 1, wie es für die Produktion genehmigt ist".
In Schritt 26 führt die ungenaue Anforderung in der Anwendung der Konfigurations-Regeln zu einer Auswahl einer Sicht- Revision, so daß das genaue Produkt zusammengebaut werden kann.
Unabhängig davon, ob die Anforderung genau oder ungenau ist, findet in Schritt 27 das PSM 12 die korrekte Sicht-Revision wieder. In dem Beispiel ist VR-1-1-2 entweder ein Teil der genauen Spezifikation oder wurde durch Konfigurations-Regeln ausgewählt.
In Schritt 28 setzt PSM 12 eine genaue Version des Produkts zusammen. In dem Beispiel ist eine genaue Zusammensetzung von Produkt 1 aus VR-1-1-2, V-1-2 und V-1-3 zusammengesetzt. Das Produkt wird als eine Material-Liste dargestellt, die Komponenten in Form von Gegenstands- oder Gegenstands-Revisions- Identifiziererri auflistet. Wie nachfolgend in Verbindung mit Fig. 4 erläutert, kann das Zusammensetzen erfordern, daß PSM 12 "Erscheinungs"-Objekte erzeugt, die Wege zu Ansichten sind, die Kontext-spezifisch sind.
Die Fähigkeit von PSM 12, ungenaue Anordnungen zu managen, gibt dem Benutzer die Fähigkeit, mehr als eine Version von dem gleichen Produkt zu sehen. Deshalb kann Schritt 24 mit einer anderen Anfrage wiederholt werden, was zu einer Anwendung von anderen Konfigurations-Regeln, der Auswahl von einer anderen Sicht-Revision oder einer anderen Ansicht von dem Produkt führt.
Fig. 3 ist ein Beispiel von einer durch PSM 12 erzeugten Anzeige, die einen Bereich von einer BOM-Liste 30 für ein bestimmtes Produkt darstellt. Jeder Gegenstand auf einer BOM kann eine wesentliche Komponente sein, d.h. ein Stückteil oder eine Zwischen-Unterbaugruppe. Ein Produkt ist ebenfalls ein Gegenstand. In Fig. 3 hat ein Fahrrad eine Anzahl von Gegenständen als Komponenten. Als ein besseres Beispiel kann ein Vergaser ein Produkt in dem Sinne sein, daß es als eine Einheit verkauft werden kann, aber ebenfalls als ein Gegenstand, wenn er als Komponente von einem Fahrzeug verkauft wird.
Der Benutzer kann mit dem BOM 30 in Beziehung treten, indem Gegenstände mit einer Zeiger-Vorrichtung ausgewählt werden. Der Benutzer kann den Pegel der dargestellten Abstraktion steuern, wie zum Beispiel durch Vergrößern oder Verkleinern von ausgewählten Gegenständen, um zusätzliche Daten, die mit jedem Gegenstand in Beziehung stehen, zu zeigen oder zu verstecken. Daher, obwohl das BOM 30 eine genaue Produkt-Struktur darstellt, können die Gegenstände auf dem BOM 30 vergrößert werden, um deren zugehörige Ansicht oder Sicht-Revision zu zeigen.
Fig. 4 zeigt einen Produkt-Struktur-Dialog 40, der durch PSM 12 erzeugt wird, d.h. eine Erweiterung von einem BOM 30. Die verschiedenen Daten-Spalten, die in den Anzeigen verfügbar sind, wie jene in Fig. 3 und 4, sind Gegenstand der Auswahl des Benutzers und werden durch PSM 12 geeignet formatiert.
Jeder Gegenstand des Dialogs 40 ist mit irgendwelchen zusätzlichen Daten gezeigt, die damit in Beziehung stehen, d.h. ein Identifizierer von irgendwelchen Gegenstands-Revisionen, ein Identifizierer von dessen Ansicht, eine Sicht-Beschreibung, eine Vorkommnis-Beschreibung, unabhängig davon, ob es sich um feine Erscheinung, eine Erscheinungs-Beschreibung und Status davon handelt. Im Allgemeinen können diese zusätzlichen Daten von einem Benutzer während irgendeiner Stufe der Produkt-Konstruktion eingegeben werden. Daher ist der Dialog 40 eine Daten-Eingabe-Einrichtung, ebenso wie eine Einrichtung zum Darstellen einer endgültigen Produkt-Struktur.
In dem Beispiel von Fig. 4 hat ein Gegenstand, eine Fahrgestell-Baugruppe, identifiziert als EX-125, zwei Gegenstände, eine vordere Achsen-Baugruppe und eine hintere Achsen-Baugruppe, die einer Revision der vorderen Achsenbaugruppe ist, bezeichnet als AX-025 bzw. AX-025-1. Jeder Achsen-Baugruppe hat zwei Räder, und alle vier Räder sind der gleiche Gegenstand, WH-56-1, eine schlauchlose Version. Jedoch kann in dem Kontext des gesamten Fahrgestells jeder Reifen hinsichtlich der Frage beschrieben sein, ob es sich um den linken oder rechten oder vorderen oder hinteren handelt. Daher, bezüglich einer Achsen-Baugruppe, hat ein Reifen eine direkte Eltern-Kind-Beziehung (ein Vorkommnis). In anderen Worten, die Achsen-Baugruppe hat zwei Vorkommnisse von einem Reifen. Das Fahrgestell hat zwei Vorkommnisse von einer Achsen-Baugruppe. Jedoch kann bezüglich des Fahrgestells jeder Reifen eine Kontext-spezifische Beziehung haben, d.h. links, vorne etc. (eine Erscheinung). Erscheinungen ermöglichen es dem PSM 12, einen Pfad von Ansichten und Sicht-Revisionen zu bestimmen, wenn ein Produkt eine Vielzahl von Komponenten der gleichen Ansicht oder Sicht-Revision hat und wenn diese Komponenten eine indirekte Beziehung zu anderen Gegenständen haben.
Fig. 5 zeigt, wie PSM 12 Daten speichert, die über den Dialog 40 eingegeben werden, um eine ungenaue Struktur zu bilden und um eine genaue zusammenzusetzen. Die Daten-Klassen, die für dieses Modell verwendet werden, sind in Verbindung mit Fig. 6-8 beschrieben.
Insbesondere stellt Fig. 5 ein Modell von einer Gegenstands-Revision dar, die mehr als eine Ansicht hat. In diesem Beispiel hat eine spezifische Gegenstands-Revision zwei Sicht- Revisionen, und die Gegenstände in jeder Sicht-Revision sind durch Vorkommnisse mit anderen Sicht-Revisionen verknüpft. Anstelle einer Gegenstands-Revision kann die spezifizierte Gegenstands-Revision ein Gegenstand sein, der keine Revisionen hat. In diesem Sinne werden hier Gegenstände und Gegenstands- Revisionen austauschbar verwendet.
Unter Verwendung von Konzepten der Graphen-Theorie, sind Ansichten und Sicht-Revisionen als Knoten, Vorkommnisse als Bögen und Erscheinen als Wege abgebildet. Daten werden jedem dieser Objekte beigefügt. Wegen der Struktur-Beschreibungen, d.h. Ansichten und Sicht-Revisionen als Knoten anstelle von Gegenständen und Gegenstands-Revisionen zu verwenden, können verschiedene Ansichten von dem gleichen Gegenstand oder Gegenstands-Revisionen diesem Gegenstand oder Gegenstands-Revision angehängt sein. Dies ermöglicht mehrere Ansichten von einem Gegenstand.
In dem Beispiel aus Fig. 5 hat der Gegenstand zwei mögliche Strukturen. Eine Struktur hat vier Komponenten VR-2-1, VR-2-2-1, VR-2-3-1 und VR-2-4. Die andere Struktur hat sechs Komponenten, VR-2-1, VR-2-2-2, VR-2-3-2, VR-2-4, VR-2-5 und VR-2-6. Verschiedene Sicht-Revisionen sind in jeder Struktur gleich.
Obwohl Fig. 5 eine Graphik von zwei Strukturen in zwei Dimensionen ist, kann der Graph als eine dreidimensionale Darstellung von ungenauen Strukturen dargestellt sein. Wenn die Benutzer-Anfrage ungenau ist, wird der Mechanismus zum Bestimmen, welche Sicht-Revision von einem Objekt wieder aufgefunden werden soll, durch Anwendung der Konfigurations-Regeln durchgeführt. Beispielsweise kann ein Benutzer spezifizieren, daß er die letzte Version von einem "Produkt A" mit dem Status "genehmigt zur Herstellung durch X" angezeigt haben möchte.
Beginnend bei irgendeinem Knoten auf irgendeiner Ebene erlauben es die Konfigurations-Regeln dem PSM 12, eine genaue Anordnung zu bestimmen, indem für verschiedene Sicht-Revisionen von einem Gegenstand und auf einer Ebene der Vorkommnisse rauf- und runtergegangen wird. Eine Sicht-Revision von einem Gegenstand bewirkt eine Veränderung der Ebenen, und die korrekte Sicht-Revision muß lokalisiert werden, um eine genaue Struktur zu bestimmen.
Es ist möglich, daß ein Benutzer anfordern kann, daß ein Produkt dargestellt wird, das vollständig aus genauen Referenzen besteht. In diesem Fall muß PSM 12 lediglich solche Objekte zum Zusammenbau wiederfinden, ohne auf die Konfigurations-Regeln Bezug zu nehmen.
Fig. 6 zeigt die Beziehung zwischen den Daten-Klassen, Gegenständen und Gegenstands-Revision. Die Objekte von diesen Daten-Klassen stellen Produkt-Komponenten dar, die somit den Gegenständen von einem BOM entsprechen. Ein Gegenstand kann eine Komponente von einem anderen Gegenstand sein. Einige Objekte sind direkt an einem Gegenstand angebracht, wohingegen andere an einer Gegenstands-Revision angebracht sind.
Eine Gegenstands-Revision ist von anderen Gegenstands-Revisionen unterscheidbar, erfüllt aber die gleiche Form, Anschluß und Funktionsanforderungen wie alle anderen Revisionen von dem gleichen Gegenstand. Gegenstands-Revisionen stellen die iterative Versuche von Konstruktions-Ingenieuren dar, die Konstruktionsziele von dem Produkt zu erfüllen. Beispielsweise können verschiedene Revisionen Versuche wiedergeben, die Kosten zu verbessern oder Fehler zu vermeiden. Allgemein wird eine Gegenstands-Revision als austauschbar mit anderen Revisionen des gleichen Gegenstands erachtet. In dem Beispiel aus Fig. 6 hat der Gegenstand AX-025 zwei Revisionen, AX-025-A und AX-025-B.
Ein Gegenstand oder eine Gegenstands-Revision kann Attribute haben, die deren Spezifikationen enthalten. Einige Attribute von einem Gegenstand spezifizieren diesen, während andere von Spezifikations-Attributen abgeleitet sind. Wie in irgendeinem Objekt-orientieren System können Attribute selbst Objekte sein. Tatsächlich sind die meisten Attribute von einem Gegenstand Objekte, die selbst durch Anwendungs-Programmierung manipuliert werden können.
Fig. 7 zeigt die Beziehung zwischen den Daten-Klassen, Ansicht und Gegenstand. Eine Ansicht ist ein Attribut von einem Gegenstand oder Gegenstands-Revision, die verwendet wird, um die Struktur davon zu beschreiben. Jede Ansicht weiß, welcher Gegenstand eine Ansicht davon ist. Sicht-Objekte ermöglichen es einem Benutzer, einen Gegenstand zu spezifizieren, den er auf einer Material-Liste dargestellt haben möchte. Eine Ansicht stellt einen Teil von einer ungenauen Struktur in dem Sinne dar, daß jede Ansicht eine Nummer von Sicht-Revisionen haben kann.
Funktionen, die mit Ansichten in Beziehung stehen, sind in dem Anhang wiedergegeben. Attribute von der Sicht-Klasse haben einen Gegenstands-Ordner (wahlweise Eltern), ein Konfigurations- Objekt (nachfolgend in Verbindung mit Fig. 11 erläutert) und einen Sicht-Typ. Ein Sicht-Typ ist eine Daten-Klasse, deren Objekte Weiterentwicklungs-spezifische Klassifikationen von Ansichten darstellen. Eine. Ansicht kann beispielsweise als eine "Konstruktions"-Ansicht gegenüber einer "Zusammenbau"-Ansicht sein. Diese Klassifikation kann verwendet werden, um zwischen mehreren Ansichten des gleichen Produkts zu differenzieren.
Fig. 7 zeigt außerdem die Beziehungen zwischen den Daten- Klassen, Ansicht und Sicht-Revision. Eine Ansicht kann eine oder mehrere Sicht-Revisionen haben. Ansichten behalten ihre eigenen Revisions-Geschichten, indem jede Ansicht den "Anker" von ihren Revisionen bildet. Diese Sicht-Revisionen sind eine Daten- Klasse, Sicht-Revision. Im Allgemeinen ist eine Sicht-Revision eine genaue Darstellung, die mit einer BOM-Ausgabe in Beziehung stehen kann. Der Benutzer kann eine Sicht-Revision spezifizieren, so daß das BOM 30 oder der Dialog 40 den entsprechenden Gegenstand anzeigt.
Fig. 7 zeigt außerdem den Beziehungstyp Vorkommnis. Eine Ansicht oder eine Sicht-Revision kann Vorkommnisse haben, die sich auf andere Sicht-Objekte oder auf Sicht-Revisions-Objekte beziehen. Im Allgemeinen ist ein Vorkommnis eine Beziehung zwischen zwei Ansichten, die es ermöglicht, daß eine Anordnung von Komponenten gebildet wird. Ein Vorkommnis ist eine Eltern-Kind- Beziehung, die verwendet wird, um Daten von der entsprechenden Ansicht in dem Kontext von der Referenz-Ansicht zu speichern. Sicht-Revisionen können Vorkommnisse oder Referenz-Vorkommnisse oder Erscheinungen haben.
Das folgende ist ein Beispiel, wie Vorkommnis-Beziehungen gebildet werden:
{Sicht-Revision } -> {Ansicht, Gegenstand}.
Wenn eine Sicht-Revision eingegeben wird, erzeugt PSM 12 eine Gegenstands-Revision. Dann, wenn eine Produkt-Struktur angefragt wird, kann diese aus einer Benutzer-Referenz zu dem zugehörigen Gegenstand zusammengesetzt werden. Daher sind Sicht- Revisionen Attribute von ihren Gegenstands-Revision. Es können mehrere Sicht-Revisionen pro Gegenstands-Revision vorliegen.
Die Nummer von Vorkommnissen in einer Kette von Gegenständen oder Gegenstands-Revision bestimmt die Tiefe von einer Baugruppe von solchen Gegenständen. Beispielsweise hat der folgende Gegenstand eine Tiefe von vier Vorkommnissen:
A -> B; B -> C; C -> D; D -> E.
Das Kind von einem Vorkommnis kann eine Ansicht (ungenau) oder eine Sicht-Revision (genau) sein. Wenn eine Baugruppe von einem Gegenstand abgefragt wird, wenn eine genaue Spezifikation erfolgt, kann die zugehörige Sicht-Revision wieder aufgefunden werden. Falls eine ungenaue Spezifikation erfolgt, wird die korrekte Sicht-Revision bestimmt, indem Konfigurations-Regeln angewendet werden, und dann wieder aufgefunden wird.
Fig. 7 zeigt außerdem die Beziehung von der Daten-Klasse, Erscheinung, zu Vorkommnis und Sicht-Revisions-Daten-Klassen. Erscheinungen stellen PSM 12 eine Einrichtung zur Verfügung, um ein Kontext-spezifisches Vorkommnis zu identifizieren. Eine Erscheinung ist ein Attribut von einer Sicht-Revision. Dessen Attribute sind ein Weg und ein Elternteil.
Fig. 8 zeigt, wie ein Konfigurations-Objekt (CO) erzeugt wird, wenn eine Ansicht von einem Gegenstand erzeugt wird, um die Beziehung zwischen den Revisionen davon zu managen. Das CO behält zwei separate Revisions-Geschichten: eine für Arbeits- Revisionen und eine für veröffentlichte Revisionen. Arbeits- Revisionen sind solche, die editiert werden können. zu jedem Zeitpunkt, an dem der Benutzer eine Arbeits-Revision sichert, kann er wählen, ob andere vorhergehende Revisionen überschrieben werden sollen. Wenn die vorhergehende Revision nicht überschrieben wird, wird die letzte Revision an die Revisions- Geschichte angehängt. Veröffentlichte Revisionen sind jene, die nicht mehr verändert werden können. Jede Revisions-Geschichte hat eine CO-Wurzel als ihren Anker. Eine Geschichte erscheint in lediglich einer CO und enthält Null oder mehr Revisionen.
Wenn Revisionen zu der CO hinzugefügt werden, werden sie zu der Geschichte hinzugefügt, und zwar abhängig davon, ob sie Arbeits-Revisionen oder veröffentlichte Revisionen sind. Außerdem, wenn eine Arbeits-Revision veröffentlicht wird, kann eine Duplikat-Referenz zu diesem Sicht-Revisions-Objekt in dem veröffentlichten Geschichts-Objekt angeordnet werden. Das Duplikat wird in der Arbeits-Geschichte behalten, bis eine nachfolgende Arbeits-Version genehmigt wird.
Fig. 8 zeigt ebenfalls, wie PSM 12 Zugriff zu Revisionen schafft. Revisionen sind als eine "Kette" gespeichert, wobei ein Zeiger immer auf die nächste Revision in der Kette zeigt.
Es wird wieder auf Fig. 2 Bezug genommen, in der eine Run- Time-Operation von PSM 12 mit einer ungenauen Benutzer-Anfrage nach einem Produkt beginnen kann. Als ein Beispiel kann der Benutzer nach "Produkt A, wie es vom Management genehmigt ist" fragen. Als ein weiteres Beispiel kann ein Benutzer nach "der letzten Revision, an der ich gearbeitet habe" fragen.
PSM 12 findet die korrekte Sicht-Revision wieder, indem Konfigurations-Regeln angewendet werden, um zu bestimmen, welche Gegenstands-Revision die Benutzer-Anfrage erfüllt. Insbesondere wendet PSM 12 Konfigurations-Regeln auf Gegenstände an, um zu bestimmen, welche Gegenstands-Revision wirksam ist. Dann bestimmt PSM 12 über das CO von dieser Gegenstands-Revision, welche Sicht-Revision wiedergefunden werden soll.
Wie vorstehend in Verbindung mit Fig. 1 angemerkt, bedient PSM 12 eine Benutzer-Schnittstellen-Schicht 16, so daß der Benutzer nicht direkt mit PSM 12 zusammenarbeitet. Das PSM 12 enthält jedoch eine Reihe von Funktionen, die die Schnittstellen-Schicht 16 unterstützen. Der Anhang zeigt Beispiele von solchen Funktionen, einschließlich Funktionen zum Umgang mit Konfigurations-Regeln. Aus Daten, die als Argumente für diese Funktionen zur Verfügung gestellt werden, bestimmt PSM 12, welche Gegenstände betrachtet werden und welche Revisionen zurückgeschickt werden.
Eine genaue Konfiguration von einem Produkt oder Gegenstand kann auch durch eine Anfrage nach einer speziellen Sicht-Revision eingeleitet werden. Diese Sicht-Revision-Funktionen, wie in der Anlage angegeben, können verwendet werden, um spezielle Sicht-Revisionen zu betätigen.
Zum Zusammenfügen einer Struktur bestimmt PSM 12 zunächst, welche Vorkommnisse von einer Ansicht oder Sicht-Revision wirksam sind. Dann findet es die Kinder von den Vorkommnissen und wendet Konfigurations-Regeln an, um zu entscheiden, welche der Sicht-Revisionen geladen werden sollen. Die Kinder von den Vorkommnissen von jeder dieser Sicht-Revisionen werden dann gefunden, eine Konfigurations-Regel wird angewendet, und so weiter, bis die Tiefe von dem spezifizierten Gegenstand erreicht ist.
Ein Merkmal von PSM 12 besteht darin, daß Revisionen als ein Status bezeichnet werden können. Der Status ist ein Objekt, das den Status-Typ und ein Genehmigungs-Datum von einer Revision definiert. Zusätzlich können Revisionen Wirksamkeits-Daten bezeichnen. Allgemein steht der Status mit der Genehmigung zur Herstellung in Beziehung, und die Wirksamkeit steht mit dem Zeitpunkt der Herstellung in Beziehung. Beispielsweise kann eine Revision den Status "genehmigt zur Produktion" haben. Dies ermöglicht es, daß der Benutzer auf eine vorhergehende Revision zugreifen und darin arbeiten kann, die einen speziellen Status hat. Wirksamkeit ist in Begriffen von einer Revision definiert, die zwischen speziellen Daten wirksam ist, vor einem speziellen Datum, nach einem speziellen Datum, zwischen speziellen Serien- Nummern, vor einer speziellen Serien-Nummer oder nach einer speziellen Serien-Nummer. Das Status-Objekt hat den Attribut- Status-Typ, die bestimmte Status-Bezeichnungen sind, die von einem Unternehmen verwendet werden. das heißt "freigegeben", "genehmigt zur Herstellung", etc. Der Status und Wirksamkeits- Bezeichnungen können zu einer Konfiguration führen, die allgemein nicht mit einer genauen Baugruppe zusammenpassen kann, die von einem Konstruktions-Ingenieur erzeugt wurde.
Ein weiteres Merkmal von PSM 12 besteht darin, daß Benutzer an "halb-genauen" Revisionen arbeiten können. Eine Ersatzliste ist eine Daten-Klasse, deren Objekte eine Einrichtung schaffen, um eine Liste von Gegenstands-Revisionen zu spezifizieren, die anstelle anderer Gegenstands-Revisionen ersetzt werden soll, wie durch eine Konfigurations-Regel bestimmt ist. Gegenstands- Revisionen können auf dieser Liste vorgesehen sein. Der Anhang stellt Funktionen zum Implementieren der Ersatzliste dar.
Ein "Kontext"-Objekt ermöglicht es dem Benutzer, mehrere Fenster zu öffnen. Jedes Fenster kann seine eigenen Konfigurations-Regeln haben. Funktionen, die mit diesem Objekt in Beziehung stehen, sind in dem Anhang dargestellt.
Ein Benutzer kann Erscheinungen von verschiedenen Sicht- Revisionen anfordern, um in verschiedenen Anordnungen von dem gleichen Produktoder in verschiedenen Produkten äquivalent zu sein. Eine "Äquivalenz"-Daten-Klasse ermöglicht es, daß Knoten, die in separaten Anordnungen erscheinen, äquivalent bezeichnet werden. Funktionen, die mit äquivalenten Objekten in Beziehung stehen, sind im Anhang angeführt.

Andere Ausführungsbeispiele

Obwohl die Erfindung unter Bezugnahme auf spezielle Ausführungsbeispiele beschrieben wurde, ist diese Beschreibung nicht dazu bestimmt, um in einem beschränkenden Sinne ausgelegt zu werden. Verschiedene Modifikationen der offenbarten Ausführungsbeispiele, ebenso wie alternative Ausführungsbeispiele, sind für Fachleute offensichtlich. Es wird daher angenommen, daß die beiliegenden Ansprüche alle Modifikationen beinhalten, die in den tatsächlichen Schutzbereich der Erfindung fallen. Modul Funktionen

Claims

1. Verfahren zum Wiedergeben und Darstellen von Daten für eine präzise Struktur von einem Produkt, bei dem ein Computer (11) verschiedene Arten von Objekten speichert, die dazu verwendet werden können, eine Stückliste (30) zu erstellen, gekennzeichnet durch:

Speichern (21) einer Beschreibung von jeder Komponente eines Produktes als ein Sicht-Objekt (V-1-1 ... V-1-3) einer Sicht- Datenklasse;

Speichern (22) einer Beschreibung von jeder Wiederbetrachtung bei einer Komponente eines Produktes als ein Sicht-Revisions-Objekt (VR-1-1-1, ... VR-1-1-3) einer Sicht-Revisions- Datenklasse;

Verknüpfen (23) von Sicht-Objekten (V-1-1 ... V-1-3) und Sicht-Revisions-Objekten (VR-1-1-1, ... VR-1-1-3) von verschiedenen Komponenten mit Verweisen auf Vorkommnis-Objekte einer Vorkommnis-Datenklasse (ODC);

Empfangen (24) einer Eingabe von einem Benutzer, die ein Produkt, das betrachtet werden soll, präzise spezifiziert;

Wiederauffinden (27) von mindestens einem Sicht-Objekt (V-1- 1. ... V-1-3) oder einem Sicht-Revisions-Objekt (VR-1-1-1, ... VR-1-1-3) für jede Komponente des Produktes durch Verwenden der Vorkommnis-Objekte; und

Zuordnen (28) jedes Sicht-Objektes (V-1-1 ... V-1-3) und Sicht-Revisions-Objektes (VR-1-1-1, ... VR-1-1-3) zu einer Komponente des Produktes, um eine Stückliste (30) zu erstellen.

2. Verfahren nach Anspruch 1, ferner gekennzeichnet durch den Schritt des Verknüpfens von Sicht-Revisions-Objekten (VR-1- 1-1, ... VR-1-1-3) von derselben Komponente mit Verweisen auf ein Sicht-Objekt (V-1-1 ... V-1-3), das dieser Komponente zugeordnet ist.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Produkt mehrere Komponenten desselben Typs (T) hat, und daß das Verfahren ferner den Schritt des Speicherns von kontextspezifischen Beschreibungen von solchen Komponenten als Erscheinungs-Objekte aufweist.

4. Verfahren nach Anspruch 1, ferner gekennzeichnet durch den Schritt des Verwendens eines Objektes einer Konfigurationsobjekt-Datenklasse, um Entwicklungsgeschichten von Sicht-Revisionen zu speichern.

5. Verfahren nach Anspruch 1, ferner gekennzeichnet durch den Schritt des Verwendens einer Konfigurationsregel, um zu bestimmen, welches Sicht-Revisions-Objekt (VR-1-1-1, ... VR-1-1- 3) einer Komponente während des Wiederauffindungschrittes wiederaufgefunden werden soll.

6. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Komponenten durch Artikel-Objekte von Artikel- und Artikel- Revisions-Datenklassen (IDC, IR) dargestellt werden, und wobei die Sicht-Objekte (V-1-1 ... V-1-3) und die Sicht-Revisions- Objekte (VR-1-T-1, ... VR-1-1-3) Attribute von entsprechenden Artikel-Objekten sind.

7. Verfahren zum Wiedergeben und Darstellen von Daten für eine präzise Struktur von einem Produkt, bei dem ein Computer (11) verschiedene Arten von Objekten speichert, die dazu verwendet werden können, eine Stückliste (30) zu erstellen, gekennzeichnet durch:

Speichern eines Satzes von Konfigurationsregeln zum Bestimmen, wie eine präzise Version des Produktes zusammengesetzt werden soll;

Empfangen (24) einer Eingabe von einem Benutzer, die ein zu betrachtendes Produkt und mindestens eine Bedingung, die mit dem Produkt verbunden ist, ungenau spezifiziert;

Verwenden (26) von mindestens einer der Konfigurationsregeln, um eine Sicht-Revision von einer Komponente von dem Produkt zu bestimmen, die die mindestens eine Bedingung erfüllt;

Wiederauffinden (27) eines Satzes von Sicht-Objekten (V-1-1 ... V-1-3) und Sicht-Revisions-Objekten (VR-1-1-1, ... VR-1-1- 3), die jede Komponente des Produktes darstellen, indem die Vorkommnis-Objekte verwendet werden; und Zuordnen (28) jedes Sicht-Objektes (V-1-1 ... V-1-3) und jedes Sicht-Revisions-Objektes (VR-1-1-1, ... VR-1-1-3) zu einer Komponente des Produktes, um eine Stückliste (30) zu erstellen.

8. Verfahren nach Anspruch 7, ferner gekennzeichnet durch den Schritt des Verknüpfens von Sicht-Revisions-Objekten (VR-1- 1-1, ... VR-1-1-3) von derselben Komponente mit Verweisen auf ein Sicht-Objekt (V-1-1 ... V-1-3), das dieser Komponente zugeordnet ist.

9. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß der Schritt des Eingabe-Empfangens Empfangsdaten aufweist, die einer Statusbedingung entsprechen, und daß der Schritt des Verwendens der Konfigurationsregeln eine Sicht-Revision bestimmt, die diesen Status hat.

10. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß der Schritt des Empfangens einer Eingabe Empfangsdaten aufweist, die einer Gültigkeitsbedingung entsprechen, und daß der Schritt des Verwendens der Konfigurationsregeln eine Sicht-Revision bestimmt, die diese Gültigkeit hat.

11. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß das Produkt mehrere Komponenten desselben Typs (T) hat, und daß das Verfahren weiter den Schritt des Speicherns von kontextspezifischen Beschreibungen von solchen Komponenten als Erscheinungs-Objekte aufweist.

12. Verfahren nach Anspruch 7, ferner gekennzeichnet durch den Schritt des Verwendens eines Objektes einer Konfigurationsobjekt-Datenklasse, um Entwicklungsgeschichten von Sicht-Revisionen zu speichern.

13. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß die Komponenten durch Artikel-Objekte von Artikel- und Artikel- Revisions-Datenklassen (IDC, IR) dargestellt werden, und daß die Sicht-Objekte (V-1-1 ... V-1-3) und die Sicht-Revisions-Objekte (VR-1-i, ... VR-1-1-3) Attribute der entsprechenden Artikel- Objekte sind.

14. Verfahren nach Anspruch 7, ferner gekennzeichnet durch den Schritt des Anzeigens der Stückliste (30) und des Empfangens von Daten von einem Benutzer, um Daten, die an die Sicht-Objekte (V-1-1 ... V-1-3) angebunden sind, hinzuzufügen, zu ändern oder zu löschen.