DE10244685A1

DE10244685A1 - Produktkonfigurationsverfahren und -system

Info

Publication number: DE10244685A1
Application number: DE10244685A
Authority: DE
Inventors: Shane A Atkinson
Original assignee: Numatics Inc
Current assignee: Numatics Inc
Priority date: 2001-09-25
Filing date: 2002-09-24
Publication date: 2003-04-24
Also published as: ITRM20020476A0; US8306795B2; US20030061238A1; ITRM20020476A1

Abstract

Die Erfindung betrifft ein objekt-orientiertes Produktkonfigurationssystem, das im allgemeinen ein Modellier-Tool zum Modellieren einer bestimmten Produktlinie und ein Runtime-Tool umfaßt, um die im Modell erzeugten Informationen einer oder mehreren externen Software-Anwendungen verfügbar zu machen. Insbesondere ermöglicht das Modellier-Tool einem Modellerzeuger ein Produktmodell-Objekt zu schaffen, bei der es sich um eine elektronische Datei handelt, die automatisch die Werte einsetzt und die alle erforderlichen Informationen über eine spezielle Produktlinie enthält. Sobald das Produktmodell-Objekt erzeugt ist, stellt das Runtime-Tool einer externen Anwendung eine Schnittstelle zur Verfügung, damit diese Zugriff auf die Informationen erhält und sie benutzen kann. Auf diese Weise kann ein einziges Ursprungssystem nützliche Informationen an verschiedene Arten von Software-Anwendungen liefern.

Description

Bezug zu verwandten Anmeldungen

Diese Anmeldung beansprucht die Priorität der vorläufigen US- Patentanmeldung Nr. 60/325 005, angemeldet am 25. September 2001, wobei hier auf deren gesamten Inhalt Bezug genommen wird.

Erfindungsgebiet

Die vorliegende Erfindung betrifft im allgemeinen ein Produktkonfigurationssystem und insbesondere ein objekt-orientiertes Produktkonfigurationssystem, welches ein Modellier-Tool zum Modellieren eines Produkts und ein Runtime-Tool zum Konfigurieren eines Produktes umfaßt.

Hintergrund der Erfindung

Hersteller bieten ihren Kunden oft eine sehr große Auswahl hinsichtlich der Merkmale und Eigenschaften von Produkten, wodurch den Kunden eine größere Flexibilität bei der Bestellung von Artikeln gegeben wird, um deren individuellen Bedürfnissen zu entsprechen. Die spezifische Kombination von Produkteigenschaften, wie sie vom Kunden ausgewählt wird, bezeichnet man üblicherweise als "Produktkonfiguration", nachfolgend der Einfachheit halber nur "Konfiguration" genannt. Mit steigender Anzahl der Wahlmöglichkeiten für den Kunden nimmt auch die Komplexität rund um die Konfiguration zu. Die Auswahl einer bestimmten Eigenschaft kann die Auswahl von anderen Eigenschaften erfordern oder ausschließen. Beispielsweise kann ein Kunde bei einem konfigurierbaren Fahrrad ein Mountainbike- Paket auswählen. Das Auswählen dieses Pakets erfordert zwingend die Wahl eines speziellen verstärkten Federungssystems, während es gleichzeitig die Wahl eines bestimmten Straßenfederungssystems ausschließt. Die Richtlinien, die die Auswahl der Konfiguration bestimmen, werden zusammenfassend als "Regeln" bezeichnet. Die Schwierigkeiten, die Auswahlmöglichkeiten, Regeln und andere Informationen, die mit einer speziellen Konfiguration zusammenhängen, zu verwalten, können recht überwältigend werden. Daher besteht ein Bedarf an Produktkonfigurationssystemen, die üblicherweise als "Konfiguratoren" bezeichnet werden, um den Vorgang zu automatisieren.
Das Produktkonfigurationssystem sollte auch eine "sinnvolle Modellnummer" verwenden, d. h. eine Modellnummer, bei der sich jedes Zeichen auf ein bestimmtes Attribut des Produktes bezieht. Beispiele für die Art von Attributen, die durch Modellnummerzeichen wiedergegeben werden können, sind ein Optionspaket, eine Teileabmessung, eine Produktfarbe, etc. Identische Konfigurationen haben deshalb die gleiche sinnvolle Modellnummer. Obwohl in konventionellen Produktkonfigurationssystemen bereits sinnvolle Modellnummern verwendet werden, sind auf diesem Gebiet noch Verbesserungen möglich.
Ein Bereich, der verbessert werden kann, betrifft den Automatisierungsgrad. Einige konventionelle Produktkonfigurationssysteme laufen nur teilweise automatisch ab, d. h. daß bestimmte Abschnitte des Konfigurationsvorganges automatisch ablaufen und andere nicht. Jeder Abschnitt des Konfigurationsvorgangs, der manuell ausgeführt werden muß, bietet Gelegenheit für menschliche Fehler. Deshalb wäre es von Vorteil, den Automatisierungsgrad für ein solches System zu erhöhen. Beispielsweise könnte ein Kunde, der seine Produktauswahl über die Firmen- Website trifft, ein hoch automatisiertes Produktkonfigurationssystem verwenden, um sofort zu bestimmen, ob eine bestimmte Produktkonfiguration verfügbar ist, welche. Materialien erforderlich sind, wieviel die Konfiguration kostet, und die Bestellung direkt von sich aus an den Hersteller senden.
Ein weiterer verbesserungswürdiger Bereich ist das Problem der Kompatibilität. Es ist wünschenswert, daß ein Produktkonfigurationssystem flexibel und kompatibel ist, so daß es mit einer Vielzahl von Systemen zusammenarbeiten kann. Beispielsweise könnte eine Firma verschiedene Software- Anwendungen benutzen, wie z. B. eine Software zum Erstellen einer Stückliste oder eine zum Tätigen von Bestellungen über das Internet, und das Produktkonfigurationssystem sollte mit all diesen kompatibel sein.
Darüber hinaus gibt es das Problem der Komplexität. In der Vergangenheit verwendeten die Produktkonfigurationssysteme eine unüberschaubare Menge von logischen Codes ("logic code"), um die an sie gestellten Aufgaben zu erfüllen. Dadurch entstand ein System, bei dem die Logik, typischerweise in Form von endlosen wenn-dann-Aussagen, und die Daten, die üblicherweise aus gigantischen Datenbanken und Verweistabellen bestanden, zwei voneinander getrennte Einheiten waren. Jede dieser Einheiten war sehr schwer und zeitaufwendig zu verwalten. Dagegen sind "objekt-orientierte" Produktkonfigurationssysteme als eine Sammlung von Unterobjekten organisiert, wobei die Logik und die Daten eins sind. Systeme dieser Art ermöglichen auch die geteilte Verwendung von Logik und Daten, so daß ein einziges Produktkonfigurationssystem Informationen an eine Vielzahl von verschiedenen Anwendungen liefern könnte. Früher hätten separate Produktkonfigurationssysteme für jede Informationen anfordernde Anwendung entwickelt werden müssen.
Deshalb wäre es von Vorteil, ein verbessertes Produktkonfigurationssystem bereitzustellen, welches sinnvolle Modellnummern verwendet, vollautomatisch abläuft, mit zahlreichen Arten von Software-Anwendungen kompatibel ist und objekt-orientiert ist, so daß die Komplexität des Systems reduziert wird, indem hogik und Daten gemeinsam genutzt werden.

Gegenstand der Erfindung

Die vorstehend aufgeführten Nachteile der konventionellen Produktkonfigurationssysteme werden durch die vorliegende Erfindung überwunden, die ein Verfahren und eine Vorrichtung zum Konfigurieren eines Produktes bereitstellt. Das erfindungsgemäße Verfahren umfaßt den Schritt des Bereitstellens eines Software-Tools, welches ein elektronisches objekt-orientiertes Produktmodell erzeugen kann, das stellvertretend für eine Produktlinie steht, und den Schritt des Bereitstellens eines Software-Tools, das im Produktmodell gespeicherte Informationen für eine oder mehrere Software-Anwendungen verfügbar machen kann. Vorzugsweise umfaßt das Produktmodell ein elektronisches Profilmodell, welches stellvertretend für ein Produkt innerhalb der Produktlinie steht, dabei umfaßt das Profilmodell ein oder mehr Teilemodelle, die stellvertretend für ein Einzelteil innerhalb des Produkts stehen und das Teilemodell umfaßt ein oder mehr elektronische Eigenschaftsmodelle, welche stellvertretend für eine Eigenschaft des Einzelteils stehen.
Die Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung umfassen das Bereitstellen eines Verfahrens und einer Vorrichtung zum Konfigurieren eines Produktes, sind jedoch nicht darauf beschränkt, wobei die vorliegende Erfindung relativ einfach ausgeführt ist, eine rentable Entwicklung darstellt, eine hohe Lebensdauer hat und sinnvoll eingesetzt werden kann.

Kurzbeschreibung der Zeichnungen

Die Vorteile und Merkmale des Produktkonfigurationssystems gemäß der vorliegenden Erfindung sind anhand der beiliegenden Beschreibung, Ansprüche und Zeichnungen deutlich zu erkennen, wobei
Fig. 1 ein Blockdiagramm ist, das einen Überblick über eine bevorzugte Ausführung des erfindungsgemäßen Produktkonfigurationssystems gibt;
Fig. 2 ein Blockdiagramm ist, das einen Überblick über eine bevorzugte Ausführung des in Fig. I dargestellten Produktmodell-Objekts zeigt;
Fig. 3 ein Blockdiagramm ist, das eine bevorzugte Ausführung eines in Fig. 2 dargestellten Modellnummernmanager- Objekts zeigt;
Fig. 4 eine bevorzugte Ausführung einer Modellnummer ist, die in Verbindung mit dem in Fig. 3 dargestellten Modellnummernmanager-Objekt benutzt wird;
Fig. 5 ein Blockdiagramm ist, das eine bevorzugte Ausführung des in Fig. 2 dargestellten Teiletyp-Objekts zeigt;
Fig. 6 ein Blockdiagramm ist, das eine bevorzugte Ausführung des in Fig. 2 dargestellten Virtuelle-Teiletyp- Objekts zeigt;
Fig. 7 ein Blockdiagramm ist, das eine bevorzugte Ausführung des in Fig. 2 dargestellten Profil-Objekts zeigt;
Fig. 8 ein Blockdiagramm ist, das eine bevorzugte Ausführung des in Fig. 2 dargestellten Beschreibungsmanager- Objekts zeigt;
Fig. 9 ein Blockdiagramm ist, das einen Überblick über eine bevorzugte Ausführung des in Fig. 1 dargestellten Runtime-Tool gibt;
Fig. 10 ein Ablaufdiagramm ist, das einen Überblick über eine bevorzugte Ausführung der Funktionen des in Fig. 9 dargestellten Runtime-Tool gibt;
Fig. 11 ein Ablaufdiagramm ist, das eine bevorzugte Ausführung der in Fig. 10 dargestellten Initialisiere- Sitzung-Sequenz zeigt;
Fig. 12 ein Ablaufdiagramm ist, das eine bevorzugte Ausführung der Konfiguriere-Produkt-Sequenz zeigt; und
Fig. 13 ein Ablaufdiagramm ist, das eine bevorzugte Ausführung der in Fig. 10 dargestellten Datenerhebungsausgabe-Sequenz zeigt.

Detaillierte Beschreibung der bevorzugten Ausführung

Stand der Technik

Viele verschiedene Produktkonfigurationssysteme werden überall in der herstellenden Industrie und in anderen Branchen genutzt. Zur Zeit sind fünf allgemeine Arten von Produktkonfigurationssystemen erhältlich, die als 1. bis 5. Generation bezeichnet werden. Die erste Generation umfaßt ein einfaches Konfigurationssystem mit der Möglichkeit, Optionen auszuwählen, d. h. Systeme der ersten Generation bieten dem Anwender eine Auswahl zwischen einer oder mehreren Optionen. Beispielsweise könnte dabei ein Anwender, der sich ein Fahrrad mit einem System der ersten Generation zusammenstellen will, aufgefordert werden, zwischen einem "roten, grünen oder weißen Rahmen" zu wählen. Ein System der ersten Generation berücksichtigt keine zusätzlichen Erwägungen, wie z. B. die Tatsache, daß Rahmen mit bestimmten Farben zum Einbau in Fahrräder mit Rädern einer bestimmten Farbe ausgeschlossen sind. Diese Art von Produktkonfigurationssystem funktioniert gut, wenn die Auswahlmöglichkeiten relativ begrenzt und nicht voneinander abhängig sind.
Produktkonfigurationssysteme der zweiten Generation sind denen der ersten Generation ähnlich, aber sie verfügen über einen Regelsatz oder gegenseitige Abhängigkeiten, die bestimmte Wahlen auf der Basis der bereits gemachten Selektionen erlauben oder ausschließen. Systeme der zweiten Generation ähneln den unter dem Begriff "Expertensystem" bekannten Systemen. Nachfolgend einige Beispiele für Regeln, die von einem System der zweiten Generation verwendet werden könnten: "Wenn ein roter Rahmen ausgesucht wird, dann können nur rote, weiße oder verchromte Räder gewählt werden" oder "Wenn ein grüner Rahmen ausgesucht wird, dann können rote Räder nicht gewählt werden". Die Verwendung von Regeln stellt einen wichtigen Fortschritt gegenüber den Systemen der ersten Generation dar, jedoch können diese Regeln in Abhängigkeit von der Komplexität des Produkts leicht sehr lang werden und sehr schwierig zu verwalten sein.
Obwohl es auch für ein Produktkonfigurationssystem der ersten oder zweiten Generation möglich ist, eine sinnvolle Modellnummer zu verwenden, d. h. eine Modellnummer, bei der jedes Zeichen zu einem Attribut einer Produktlinie gehört, stellt die Erzeugung einer präzisen Stückliste eine zusätzliche Herausforderung dar. Diese Herausforderung wurde von den Produktkonfigurationssystemen der dritten Generation angenommen, die oft als "matrix-based systems" bezeichnet werden. Ein System der dritten Generation verwendet noch immer Optionsauswahl und Regeln, wie sie in den vorhergehenden beiden Generationen vorkommen, benutzt aber auch tabellenförmige Felder oder Raster, die mit Informationen gefüllt sind, die zu den unzähligen Bestandteilen dieser Produktlinie gehören. Datenbank- Suchschlüssel, die zum Auffinden von Informationen in einer Datenbank verwendet werden, ermöglichen die Auswahl von individuellen Bestandteilen. Dementsprechend können Systeme der dritten Generation spezifische Abschnitte einer Modellnummer herausziehen oder strukturell analysieren Lind zergliedern und diese Abschnitte als Datenbank-Suchschlüssel verwenden, um die entsprechenden Informationen zu finden; im Gegensatz zum einfachen Verwenden von Regeln, um zu bestimmen, welche Optionen ausgewählt werden können und welche nicht. Das System kann auch die Datenbankinformationen zum Zusammenstellen einer Stückliste verwenden, eine Fähigkeit, welche Systeme früherer Generationen nicht hatten. Es wird darauf hingewiesen, daß unzählige Typen von Datenstrukturen, einschließlich Datenbanken, Raster, Felder, Tabellenkalkulation, etc. verwendet werden könnten, um die Informationen, die zu einer bestimmten Produktlinie gehören, zu speichern.
Produktkonfigurationssysteme der vierten Generation, die oft als "teilintelligente/auf Regeln basierende Systeme" [Partintelligent/Rules based Systems] bezeichnet werden, verfügen über viele der Eigenschaften der Systeme der vorhergehenden Generationen und sie ordnen zusätzliche Daten zu, die vorher nicht berücksichtigt wurden. Bei diesen Systemen wurde der Tatsache Rechnung getragen, daß das Erstellen einer korrekten Stückliste nicht immer durch das einfache Verwenden von Abschnitten einer Modellnummer erreicht werden kann. Es gibt einige Fälle, in denen zusätzliche Informationen und Daten erforderlich sind. Beispielsweise kann, wenn ein Anwender ein bestimmtes Produkt konfiguriert und das Konfigurationssystem versucht, eine Stückliste zu erzeugen, die richtige Wahl für eine bestimmte Schraube auf Informationen basieren, die nicht direkt in der Modellnummer enthalten sind, wie z. B. der Durchmesser des Rohres, durch das die Schraube gesteckt wird. In diesem Fall wäre eine Verweistabelle für Rohrdurchmesser erforderlich, zusätzlich zu den Verweistabellen für die Modellnummer für diese spezielle Produktlinie, um eine korrekte Stückliste zu erzeugen. In diesem Sinne sind Systeme der vierten Generation weit genug entwickelt, um jenseits der Modellnummer zu suchen und die nötigen zusätzlichen Informationen einzuholen. Obwohl Produktkonfigurationssysteme wie diese viele Bedürfnisse auf diesem Gebiet erfüllen, ist die schiere Größe und Komplexität der dazugehörigen Datenstrukturen und Logik oft überwältigend. Darüber hinaus müssen Systeme dieses Typs oft mit einem Unternehmensproduktionsplanungssystem (Enterprise Resource Planning (ERP)-System) gekoppelt werden, das viele der Informationen enthält. Die Pflege der korrekten Daten und präzisen Logik kann eine entmutigende Aufgabe sein, besonders wenn eine einzige Produktlinie Einzelteilabwandlungen haben kann, die weit in die Millionen gehen.
Die neueste Generation von Produktkonfigurationssystemen, Generation 5, ist ein objekt-orientiertes System. Objektorientierte Systeme verwenden einen anderen Ansatz beim Konfigurieren eines Produktes als die früheren Systeme der vorhergehenden Generationen. Objektorientierte Systeme zerlegen eine Produktlinie in ihre Bestandteile, die wiederum in noch elementarere Einheiten aufgegliedert werden können, etc. In diesem Sinn wird jeder Bestandteil unabhängig "modelliert", d. h. alle dazugehörigen Informationen, die gebraucht werden, um jenen Bestandteil zu beschreiben, werden in einer Hierarchie von Objekten innerhalb des Systems gespeichert. Eine solche Struktur bietet zahlreiche Vorteile. Erstens: die Logik, mit der das System betrieben wird und die produktspezifischen Daten werden vereinfacht, weil sie zusammen in einer einzigen Einheit gespeichert werden, anstelle von unabhängigen logischen Codes, die Informationen aus einer unabhängigen Datenquelle herausziehen. Zweitens: sobald eine Produktlinie präzise modelliert ist, sind bestimmte Dinge, wie die Modellnummern und Stücklisten tatsächlich vorbestimmt. Dadurch verschiebt sich der Schwerpunkt von der Pflege von komplexen Rastern, Verweistabellen, Datenbanken und anderen Datenstrukturen, die nur mit Hilfe von komplizierten, auf der Logik basierenden Regeln zugänglich sind. Die Betonung liegt jetzt auf dem präzisen Modellieren oder Definieren eines Produktes auf der Basis seiner Bestandteile und Eigenschaften. Drittens: objektorientierte Systeme können so geschaffen sein, daß sie als "Stand-alone"-Systeme unabhängig funktionieren, das bedeutet, daß sie nicht durch Bündelung innerhalb eines größeren Systems, z. B. einem ERP-System, anwendungsspezifisch sind. Dementsprechend kann ein einziges objekt-orientiertes System Informationen an zahllose externe Anwendungen liefern. Dies sind nur einige der Vorteile, die die Verwendung eines Systems mit einer objekt-orientierten Struktur mit sich bringt. Die nachfolgende Beschreibung betrifft das Produktkonfigurationssystem der vorliegenden Erfindung.

Vorliegende Erfindung

Die vorliegende Erfindung betrifft ein objekt-orientiertes Produktkonfigurationssystem 10. Im allgemeinen ist das Konfigurationssystem 10 so ausgelegt, daß es zwei Hauptaufgaben erfüllt: 1) es stellt ein Werkzeug zum Modellieren einer bestimmten Produktlinie bereit und 2) es stellt ein Werkzeug zum Zugreifen auf und Präsentieren der Informationen über diese als Modell gestaltete Produktlinie zur Verfügung. Die erste Aufgabe wird durch einen Baustein des Konfigurationssystems 10 gelöst, der als Modellier-Tool 12 bezeichnet wird, während die zweite Aufgabe durch eine Komponente des Konfigurationssystems ausgeführt wird, die als Runtime-Tool 14 bezeichnet wird. Kurz gesagt, das Modellier-Tool 12 stellt einem Anwender, hier als "Modellerzeuger" bezeichnet, die Schnittstelle und die Software-Tools zur Verfügung, um ein Produktmodell-Objekt 16 zu erzeugen, wobei es sich um eine elektronische Datei handelt, die alle Informationen über eine bestimmte Produktlinie enthält. Das Runtime-Tool 14 stellt einem Benutzer einer externen Anwendung 18 eine Schnittstelle und die Software-Tools zur Verfügung, die erforderlich sind, um Zugriff auf die im Produktmodell-Objekt 16 enthaltenen Informationen auf eine Art zu erhalten, daß die Informationen in sinnvoller Weise genutzt werden können.
Das Produktkonfigurationssystem 10 eignet sich zum Implementieren in vielen verschiedenen Szenarien. Beispielsweise könnte das gesamte Konfigurationssystem 10 auf einem Desktop- Computer ohne die Verwendung eines Servers installiert werden. In diesem Fall würden die erforderlichen elektronischen Dateien sowohl für das Modellier-Tool 12 als auch für das Runtime- Tool 14 in einem einzigen Gerät gespeichert. Als Alternative könnte das Produktkonfigurationssystem 10 in einer Client/Server-Anordnung eingebaut werden, d. h. bestimmte elektronische Dateien, die sowohl vom Modellier-Tool 12 als auch vom Runtime-Tool 14 benutzt werden, könnten sich auf einem Server befinden, während andere elektronische Dateien in einem bestimmten Gerät des Kunden vorhanden sind. Das Produktkonfigurationssystem 10 der vorliegenden Erfindung ist sehr flexibel, da es so ausgeführt werden kann, daß es weder geräte-, plattform- noch architekturspezifisch ausgeführt ist, wodurch es zu einer sehr großen Anzahl von externen Anwendungen kompatibel ist. Das eigentliche Modellier-Tool 12, Runtime- Tool 14 und das Produktmodell-Objekt 16 kinnen auf einem beliebigen computerlesbaren Träger, wie z. B. einer Festplatte, einem Schreib/Lese-Speicher (RAM), auf CD-ROMs und DVDs gespeichert sein, um nur einige wenige zu nennen. Es lohnt sich anzumerken, der Computer, der in Verbindung mit der vorliegenden Erfindung verwendet wird, alle internen und peripheren Bestandteile umfaßt, die standardmäßig vorgesehen und im Stand der Technik bekannt sind, einschließlich eines Monitors, einer Tastatur und einer Maus.
In Fig. 1 umfaßt das objekt-orientierte Produktkonfigurationssystem 10 der vorliegenden Erfindung im allgemeinen zwei primäre Softwarekomponenten: ein Modellier-Tool 12 und ein Runtime-Tool 14. Allgemein gesagt ist das Modellier-Tool 12 ein ausführbares Softwareprogramm, welches einem Modellerzeuger die Schnittstelle und die Software-Tools zur Verfügung stellt, die zum Modellieren einer speziellen Produktlinie erforderlich sind. Eine spezielle Produktlinie wird modelliert, indem ein Produktmodell-Objekt 16 erzeugt wird, bei dem es sich um eine elektronische Datei handelt, die verschiedene Arten von Informationen über diese Produktlinie enthält, die in der Form von Objekten gespeichert sind. Das Runtime-Tool 14, welches eine Schnittstelle zum Programmieren von Anwendungsprogrammen (API) ist, dient als Vermittler, indem es den zahlreichen Arten von externen Anwendungen 18 die Informationen des Produktmodell-Objekt verfügbar macht. Ein bedeutender Vorteil dieses Systems besteht darin, daß Informationen zu einer speziellen Produktlinie in einer einzigen Quelle enthalten sind, aber dennoch einer Vielzahl von Anwendungen zur Verfügung stehen. Folglich wird die Erhaltung, Pflege und Verwendung dieser Informationen stark vereinfacht.
Das Modellier-Tool 12 und das Runtime-Tool 14 der vorliegenden Erfindung können durch eine von vielen Methoden konzipiert sein, und dennoch in der Lage sein, das Produktmodell-Objekt 16 zu erzeugen bzw. Zugriff dazu zu vermitteln. Deshalb konzentriert sich die folgende Beschreibung hauptsächlich auf der Struktur des Produktmodell-Objekts 16, und nicht auf eine spezielle Implementierung des Modellier-Tools 12 oder des Runtime-Tools 14.

Modellier-Tool

Das Modellier-Tool 12 ist ein ausführbares Softwareprogramm, welches dem Modellerzeuger eine graphische Benutzeroberfläche (GUI) und die Software-Tools zur Verfügung stellt, die erforderlich sind, um ein Produktmodell-Objekt 16 zu erzeugen. Vorzugsweise ist das Modellier-Tool 12 in einer objektorientierten Sprache geschrieben, wie JAVA oder C++, obwohl auch andere Programmiersprachen verwendet werden können. Die graphische Benutzeroberfläche des Modellier-Tools umfaßt eine Sammlung von verschiedenen Fenstereditoren, die dem Modellerzeuger jeweils ermöglichen, Informationen zu einem bestimmten Aspekt der als Modell zu gestaltenden Produktlinie einzugeben. Zum Beispiel ermöglicht einer der Fenstereditoren dem Modellerzeuger, dem speziellen Produktmodell-Objekt 16, das gerade erzeugt wird, einen Namen zu geben, während ein anderer der Fenstereditoren dem Modellerzeuger erlaubt, ein Modellnummernschema für die Produktlinie zu konzipieren. Das Modellier- Tool 12 führt darüber hinaus zahlreiche. Arten zusätzlicher Funktionen aus, z. B. das Anlegen von geeigneten Unterverzeichnissen, Dateien und allem, was sonst noch nötig sein könnte. Alle diese Informationen sind in der Form von elektronischen Dateien gespeichert, die als Objekte bezeichnet werden, die gemeinsam das größere Produktmodell-Objekt 16 bilden. In diesem Sinne gibt das Modellier-Tool 12 dem Modellerzeuger die Fähigkeit, alle Merkmale einer speziellen Produktlinie zu definieren, indem er ein Produktmodell-Objekt 16 erzeugt, das nachfolgend erörtert wird.

Produktmodell-Objekt

In Fig. 2 ist eine spezielle Ausführung eines Produktmodell- Objekts 16 zu sehen, welches sowohl selbst ein Objekt als auch eine Sammlung von kleineren Unterobjekten ist. Diese speziellen Unterobjekte, die im Produktmodell-Objekt dieser Ausführung enthalten sind, umfassen: ein oder mehr Modellnummernmanager-Objekte 30, ein oder mehr Teiletyp-Objekte 32, ein oder mehr Virtuelle-Teiletyp-Objekte 34, ein oder mehr Profil- Objekte 36, ein oder mehr Beschreibungsmanager-Objekte 38 sowie ein oder mehr Teileresourcen-Objekte 40. Das Produktmodell-Objekt, welches in Form einer elektronischen Datei gespeichert ist, gehört zu einer umfassenden Produktlinie und die kleineren Unterobjekte, aus denen es besteht, gehören zu spezifischen Aspekten dieser Produktlinie. Eines dieser Unterobjekte könnte die Informationen über einen spezifischen Unterbestandteil oder eine Unter-Baugruppe der Produktlinie enthalten. Beispielsweise könnte ein Modellerzeuger ein umfassendes Produktmodell-Objekt für eine Fahrrad-Produktlinie erzeugen, die eine Sammlung von kleineren Unterobjekten beinhaltet. Eines dieser Unterobjekte könnte Informationen enthalten, die sich spezifisch auf den Fahrradrahmen beziehen, während ein anderes Unterobjekt Informationen zu den Fahrradgabeln, den Rädern, etc. enthält. Darüber hinaus könnte jedes dieser Unterobjekte aus einer Sammlung von noch kleineren Unter- Unterobjekten bestehen. Das Unterobjekt, das Informationen über das Rad enthält, könnte weiter zergliedert sein und eine Sammlung von Unter-Unterobjekten mit Informationen zum Reifen, zum Schlauch, den Speichen, usw. einschließen. Dies geht so weiter bis zu dem Punkt, an dem der Modellerzeuger ein Einzelteil nicht in Form von weiteren Unter-Bestandteilen beschreiben will. Jedes Objekt, Unterobjekt oder sogar Unter- Unterobjekt könnte selbst eine Reihe von Objekten umfassen, die jeweils zu einem spezifischen Attribut oder Aspekt des größeren Objekts gehören. Beispielsweise kann das Objekt, das zu den Speichen gehört, Unterobjekte umfassen, die das Teilenumerierungsschema für die Speiche definieren, die Abmessungen bereitstellen, Werkstoffe angeben, etc. Deshalb setzt ein Produktmodell-Objekt 16 eine Produktlinie in ein Modell um, indem es zu Unterbestandteilen gehörende Unterobjekte, zu speziellen Merkmalen gehörende Unterobjekte und zu anderen Aspekten der Produktlinie gehörende Unterobjekte, wie z. B. dem Modellnumerierungsschema, sowie alle verschiedenen Abhängigkeiten der Objekte untereinander einschließt. Sobald das Modellier-Tool 12 verwendet wird, um ein Produktmodell-Objekt zu erzeugen, befindet es sich in einem hier als Initialzustand bezeichneten Zustand. Der Initialzustand ist eine rohe Schablone, die alle möglichen Variationen einer Produktlinie definiert, die aber nicht eine spezifische Produktkonfiguration enthält, welche als "eingerichteter Zustand" bekannt ist. Diese zu einem Modell gestalteten Informationen werden dann kompiliert und dem API oder Runtime-Tool 14 verfügbar gemacht, durch die eine spezifische Produktkonfiguration erzeugt wird. Somit erzeugt das Runtime-Tool 14 eine spezifische Konfiguration, indem es aus den verfügbaren Variationen, die im Produktmodell-Objekt im Initialzustand definiert sind, auswählt. Die Erläuterung des Produktmodell-Objekts beginnt mit dem Modellnummernmanager-Objekt 30.
Fig. 3 zeigt ein Beispiel des Modellnummernmanager-Objekts 30 im Detail, bei dem es sich um eine "Perspektive" des Eingabe- Typs handelt. Allgemein gesagt, ist eine Perspektive ein Objekt, welches den Austausch von Informationen zwischen einem Anwender und dem Produktmodell-Objekt 16 steuert, da verschiedene Anwender bei verschiedenen Aspekten der Produktlinie betroffen sind. Beispielsweise könnten Anwender, die sich im Bereich "Bestellungen" befinden, wissen wollen, ob eine bestimmte Modellnummer gültig ist oder nicht, während Anwendern, die sich mit Produktverkäufen befassen, der Preis des Produkts wichtig ist, während wieder andere Anwender, die sich mit der Technik befassen, die Abmessungen von spezifischen Einzelteilen überprüfen wollen. Alle diese Anwender sind mit dem gleichen Produkt befaßt, wobei sie aber jeweils unterschiedliche Arten von Informationen suchen. Perspektiven berücksichtigen dies, indem sie den Austausch von Informationen zu und von einem Produktmodell-Objekt 16 steuern. Das Modellnummernmanager- Objekt ist nur ein Beispiel eines Objekts des Perspektive- Typs.
Das in den Fig. 3 und 4 gezeigte Modellnummernmanager- Objekt 30 definiert ein Modellnumerierungsschema für die durch das Produktmodell-Objekt 16 dargestellte Produktlinie. Das Modellnumerierungsschema definiert den Regelsatz und die Verknüpfungen zu Informationen, die eine Modellnummer sinnvoll machen. Das bedeutet, eine Modellnummer 50 wird in ein oder mehr Zeichensegmente 52 zerlegt, deren Inhalte und Positionen sich spezifisch auf eine bestimmte Eigenschaft der Produktlinie beziehen. Traditionell betrachteten Konfigurationssysteme jedes Zeichen einzeln, wobei ein Zeichen "Modellnummerposition" (1. Position, 2. Position, etc.) genannt wurde. Das erfindungsgemäße Konfigurationssystem ist jedoch in der Lage, mehrstellige Zeichen 56 in einem einzigen Zeichensegment 52 als Gruppe zusammenzufassen und jedes Zeichensegment 52 separat zu behandeln. Ein sinnvolles Numerierungsschema ist vorteilhaft, da es fähig ist, sowohl Katalogartikel, die bereits eine bestimmte Modellnummer haben, als auch maßgeschneiderte Artikel, deren Artikelnummer erst noch bestimmt werden muß, effektiv zu handhaben. Beispielsweise kann ein Modellnumerierungsschema, das zu einem Fahrrad gehört, ein erstes Zeichensegment umfassen, welches die spezielle Produktserie dieser Fahrrad- Produktlinie identifiziert. Das zweite Zeichensegment könnte anzeigen, ob es sich um ein Herrenrad oder ein Damenrad handelt. Das dritte Zeichensegment könnte mit der Größe des Rahmens korrespondieren, und so weiter. Dementsprechend ermöglicht es ein sinnvolles Numerierungsschema, ein Produkt durch seine Modellnummer zu beschreiben. Das Produktkonfigurationssystem 10 der vorliegenden Erfindung verwendet einen Algorithmus, im Gegensatz zu einem Datenbankeintrag, um die Produktmodellnummer zu prüfen, wie nachfolgend erklärt wird. Ferner weist jedes Zeichensegment 52 ein entsprechendes Zeichensegment-Objekt 54 auf, wie in Fig. 3 gezeigt ist. Das Modellnummernmanager-Objekt enthält wahrscheinlich zahlreiche Zeichensegment-Objekte, die jedoch alle die gleiche Struktur haben, weshalb nur ein einziges Zeichensegment-Objekt 54 beschrieben wird.
Jedes Zeichensegment-Objekt 54 gehört zu einem einzelnen Zeichensegment 52, welches wiederum ein oder mehrere Zeichen 56 enthalten kann. Das in Fig. 3 gezeigte Zeichensegment-Objekt 54 umfaßt ein Wertspezifikator-Objekt 60, ein oder mehrere Zeichenkontingent-Objekte 62, ein Modellspezifikator-Objekt 64 sowie mehrere Informationsfelder und Flags. Ein Flag (eine Markierung) ist einfach ein Boolescher Wert, der entweder den Wert WAHR oder den Wert FALSCH wiedergibt. Das Wertspezifikator-Objekt 60 bestimmt, welche Zeichen in diesem Zeichensegment erlaubt sind und welche nicht; dies wird als "vertikale Überprüfung" bezeichnet. Das Wertspezifika tor-Objekt 60 ist ein Boolescher Spezifikator, bei dem entweder der Wert WAHR oder FALSCH herauskommt, je nachdem, ob die Zeichen 56 für dieses Zeichensegment 52 angemessen sind. Beispielsweise würde das Wertspezifikator-Objekt 60 ein FALSCH ausgeben, wenn das erste Zeichensegment 52 eine zweistellige Zahl zwischen 00 und 99 sein soll und die Zeichen "AA" in diesem Zeichensegment ermittelt würden. Mehrere verschiedene Kategorien von Booleschen Spezifikatoren stehen zur Verfügung, dazu gehören Gleichheits- Spezifikatoren, Bereichs-Spezifikatoren, Inklusiv- Spezifikatoren, Exklusiv-Spezifikatoren, Alphabetische Spezifikatoren, Numerische Spezifikatoren, Alphanumerische Spezifikatoren und Ungültig-Spezifikatoren. Um einen dieser Booleschen Spezifikatoren zu verwenden, muß ihnen eine Zeichenkette, ein sogenannter String, vorgelegt werden, so daß sie diese prüfen können.
Der Gleichheits-Spezifikator enthält einige Informationsfelder, die der Modellerzeuger definieren muß; dazu gehören ein Gleichheitswert und eine Vergleichsfunktion. Der Gleichheitswert ist der Wert, mit dem die vorgelegte Zeichenkette verglichen wird. Die Vergleichsfunktion ist die spezielle Funktion, die verwendet wird, um den Gleichheitswert mit der vorgelegten Zeichenkette zu vergleichen und die die folgenden Funktionen enthalten kann: =, <, >, ≤, ≥, Zeichenketten können leicht durch Verwendung von ASCII-Werten miteinander verglichen werden, wie im Stand der Technik bekannt ist. Für den Bereichs-Spezifikator ist es erforderlich, daß der Modellerzeuger Minimum- und Maximumbereiche definiert. Dann ergibt das Bereichspezifikator-Objekt ein WAHR, wenn der numerische oder ASCII-Wert der vorgelegten Zeichenkette in dem Bereich zwischen diesen beiden vom Modellersteller definierten Grenzwerten liegt. Darüber hinaus kann das Bereichspezifikator-Objekt einen Nur-Nummern-Flag enthalten, der verwendet wird, um Zeichenketten aus mehrstelligen Nummern zu prüfen. Wenn der Nur- Nummern-Flag auf WAHR gesetzt würde, wäre 01 = 1, 001 = 1, 0001 = 1, und so weiter. Wohingegen, wenn der Nur-Nummern-Flag auf FALSCH gesetzt wäre, 01 wie zwei separate Zeichen behandelt würde (sowohl als eine 0 als auch eine 1). Das Inklusiv- Spezifikator-Objekt erfordert, daß der Modellerzeuger eine Liste von Werten definiert, bei denen, wenn sie eingegeben werden, ein WAHR herauskommt. Auf diese Weise wird eine vorgelegte Zeichenkette mit dieser Liste verglichen, um zu bestimmen, ob sie in der Liste enthalten ist oder nicht. Dagegen erfordert das Exklusiv-Spezifikator-Objekt, daß der Modellerzeuger eine Liste mit Werten eingibt, so, wenn die vorgelegte Zeichenkette nicht darin enthalten ist, das Exklusiv- Spezifikator-Objekt ein WAHR ausgibt. Für das Alphabetische Spezifikator-Objekt braucht der Modellerzeuger keine Informationen einzugeben, da es eine vorgelegte Zeichenkette prüft und ein WAHR herauskommt, wenn der ASCII-Wert dieser Zeichenkette innerhalb des Bereichs von alphabetischen ASCII-Zeichen liegt. In ähnlicher Weise benötigt das Numerische Spezifikator-Objekt keine Informationen vom Modellerzeuger und gibt ein WAHR aus, wenn der ASCII-Wert der vorgelegten Zeichenkette in einen Bereich fällt, der für numerische Werte vorgesehen ist. Ebenso ergibt das Alphanumerische Spezifikator-Objekt ein WAHR, wenn eine vorgelegte Zeichenkette entweder im alphabetischen Bereich oder numerischen Bereich der ASCII-Werte liegt. Bei dem Ungültig-Spezifikator-Objekt ergibt sich ein FALSCH, gleichgültig was für eine Zeichenkette vorgelegt wird, und er wird verwendet, um absichtlich zu verursachen, daß ein Zeichensegment für ungültig befunden wird. Das Ungültig- Spezifikator-Objekt wird im Zusammenhang mit Fehlermeldungen verwendet und wird nachfolgend genauer beschrieben. Es wird darauf hingewiesen, daß die soeben erörterten Booleschen Spezifikatoren im gesamten Produktmodell-Objekt 16 verwendet werden können und daß sie nicht auf das Zeichensegment-Objekt 54 beschränkt sind. Darüber hinaus ist die vorhergehende Auflistung nicht exklusiv.
Das Zeichenkontingent-Objekt 62 ist ebenfalls ein Boolescher Spezifikator und umfaßt im allgemeinen ein oder mehr zusammenpassende Paare; jedes Paar enthält ein Segmentposition-Objekt 70 sowie ein Wertspezifikator-Objekt 72. Das Zeichenkontingent-Objekt 62 wird zum Definieren von Regeln verwendet, um ungültige Modellnummernkombinationen zu verhindern. Dieser Regelsatz wird oft als eine Überprüfungssequenz für das Zeichensegment bezeichnet und der Vorgang wird "horizontale Überprüfung" genannt. Das Zeichenkontingent-Objekt ergibt einen Wert WAHR oder FALSCH, der anzeigt, ob die spezielle Produktkonfiguration, wie sie durch die vorgelegte Modellnummer wiedergegeben ist, zulässig ist. Beispielsweise könnten bei einer horizontalen Überprüfungssequenz für eine Fahrrad-Modellnummer bestimmte Kombinationen von Merkmalen nicht gültig sein. Wenn ein Anwender, der sich ein Fahrrad zusammenstellt, ein Mountainbike-Paket auswählt, das durch das dritte Zeichensegment wiedergegeben wird und dann ein Paar Straßenreifen auswählt, die durch das fünfte Zeichensegment dargestellt werden, sollte eine Fehlermeldung den Anwender alarmieren, daß eine solche Modellnummernkombination ungültig ist. Dies gilt, obwohl jedes dieser Zeichensegmente unabhängig voneinander gültig ist; d. h. sie sind gültig bei vertikaler Überprüfung, nicht aber bei horizontaler Überprüfung. Es ist die Kombination dieser beiden Segmente, die ungültig ist. Das Segmentposition-Objekt 70 identifiziert das andere Zeichensegment, mit dem das vorliegende Zeichensegment (zu dem das Zeichensegment-Objekt 54 gehört) verglichen werden soll, und das Wertspezifikator-Objekt 72 enthält die Vergleichskriterien. Das Wertspezifikator- Objekt 72 kann einer der vorstehend erörterten Booleschen Spezifikatoren sein, es kann aber auch zu einer anderen Kategorie gehören. Auf diese Weise werden zwei oder mehr Zeichensegmente 52 verglichen und wenn diese spezielle Kombination zulässig ist, gibt das Zeichenkontingent-Objekt 62 ein WAHR aus, und wenn sie nicht zulässig ist, ein FALSCH. Es lohnt sich anzumerken, daß, obwohl bei einem Vergleich zwei oder mehr Zeichensegmente 52 betroffen sind, nur eines der entsprechenden Zeichensegment-Objekte 54 ein Zeichenkontingent-Objekt 62 enthalten braucht, um diesen Vergleich auszuführen. Wenn der Vergleich einmal vorgenommen worden ist, braucht er nicht noch einmal ausgeführt zu werden.
Das Modellspezifikator-Objekt 64 enthält eine Verknüpfung, die die Beziehung zwischen dem betreffenden Zeichensegment 52 und seiner korrespondierenden Eigenschaft herstellt, die im Produktmodell-Objekt 16 gespeichert ist. Insbesondere ist das Modellspezifikator-Objekt 64 ein Spezifikator des Verknüpfungstyps, das die erforderlichen Informationen enthält, um das Zeichensegment-Objekt 54 mit einem Teiletyp- oder einem Virtuelle-Teiletyp-Objekt zu verknüpfen, die bisher noch nicht beschrieben wurden. In diesem Sinne kann das Modellspezifikator- Objekt entweder als Eingang oder als Ausgang dienen. Im Sinne eines Eingangs kann das Modellspezifikator-Objekt spezifische Informationen aus einem anderen Objekt herausziehen und diese Informationen verwenden, um zu einem Wert für das korrespondierende Zeichensegment 52 zu gelangen. Dies ist der Fall, wo ein Produkt bereits konfiguriert wurde und der Modellnummernmanager benutzt wird, um eine Modellnummer abzuleiten. Im Sinne eines Ausgangs kann das Modellspezifikator-Objekt, wenn eine bestimmte Modellnummer während des Konfigurationsvorganges eingegeben worden ist, den Wert des vom Anwender bereitgestellten Zeichensegments 52 an ein anderes Objekt ausgeben, so daß das empfangende Objekt mit diesem Wert besetzt wird. Dies geschieht während des Konfigurationsvorganges, bei dem eine bekannte Modellnummer verwendet wird, um ein Produkt zu konfigurieren. Die vom Modellspezifikator-Objekt 64 bereitgestellten Verknüpfungen ermöglichen es dem. Konfigurationssystem 10 der vorliegenden Erfindung zu "wissen", welche Eigenschaft mit welchem Zeichensegment 52 verbunden ist, wodurch die Verwendung von sinnvollen Modellnummern möglich ist.
Darüber hinaus umfaßt jedes Zeichensegment-Objekt 54 einen Festlänge-Zeichen-Flag 80, einen Profillisten-String 82, einen Initial-Zeichen-Wert 84, ein Positions-Wert 86 sowie einen Beweglichen Flag 88. Der Festlänge-Zeichen-Flag 80 enthält einen Wert, der anzeigt, ob das Modellnummerierungsschema eine Kombination von Optionen gemäß einem ersten oder einem zweiten Verfahren behandeln soll. Es sei z. B. angenommen, daß ein Fahrrad drei verfügbare Optionen hat, die wie folgt dargestellt werden: LS = Ledersitz, WR = Radreflektoren und SE - Sitzerhöhung und daß die Optionsauswahl am Ende der Modellnummer stehen (S-10XX, wobei "XX" die Optionsbezeichnung ist). Wenn der Festlänge-Zeichen-Flag 80 auf WAHR eingestellt ist, und deshalb eine "feste Nummer" anzeigt, dann ist die Anzahl der Zeichen 56 innerhalb eines bestimmten Zeichensegments 52 festgelegt. Dementsprechend müssen Kombinationscodes verwendet werden, um die Auswahl von mehr als nur einer Option zu ermöglichen. Zum Beispiel könnte LL = LS + WR sein, so daß, wenn sowohl Ledersitze als auch Radreflektoren gewünscht werden, die Modellnummer S-10LL lauten würde. Wenn der Festlänge- Zeichen-Flag 80 auf FALSCH steht und damit eine "nicht-feste Nummer" anzeigt, werden zusätzliche Optionscodes einfach an den vorherigen Optionscode angehängt. Beispielsweise würde das Auswählen sowohl der Ledersitze als auch der Radreflektoren eine Modellnummer ergeben, die S-10LSWR lautet. Der Profillisten-String 82 ist eine Liste von Profil-Objekten, die noch nicht erklärt wurden, und die dieses spezielle Modellnummerierungsschema verwenden können. Der Initial-Zeichen-Wert 84 enthält einen Wert, der die Anzahl von Zeichen 56 anzeigt, die im fraglichen Zeichensegment 52 enthalten sein sollte. Wenn der Initial-Zeichen-Wert auf 3 eingestellt ist würde das System somit wissen, daß dieses Zeichensegment ein Segment mit drei Ziffern ist. Der Positions-Wert 86 zeigt die Position des Zeichensegments 52 in der gesamten Modellnummer 50 an. Wenn ein erstes Zeichensegment-Objekt 54 einen Positions-Wert 86 enthält, der auf 1 steht und einen Initial-Zeichen-Wert 84, der auf 2 steht, und wenn ein zweites Zeichensegment-Objekt 54 einen Positions-Wert 86 enthält, der auf 2 steht und einen Initial-Zeichen-Wert 84, der auf 1 steht, würde das System dadurch wissen, daß das erste Zeichensegment 52 zwei Zeichen lang und das zweite Zeichensegment ein Zeichen lang ist. Der bewegliche Flag 88 enthält einen Wert WAHR oder FALSCH, der bestimmt, ob dieses Zeichensegment 52 zu einer anderen Position bewegt oder aus der Modellnummer 50 weggelassen werden kann. Es sei angemerkt, daß, obwohl die soeben erörterten Informationen in der Form von Flags, Werten und Strings vorliegen, Informationen auch in der Form von zusätzlichen Objekten innerhalb des Zeichensegment-Objekts 54 vorhanden sein könnten. Wie zuvor gesagt, ist für jedes Zeichensegment 52 der Modellnummer 50 ein separates Zeichensegment-Objekt 54 erforderlich.
Es wird darauf hingewiesen, daß die spezielle Reihenfolge, die Anzahl der Zeichen pro Zeichensegment, die Art der zulässigen Zeichen, die Anzahl der Zeichensegmente in der Modellnummer sowie weitere Details der vorstehend diskutierten und in den Figuren dargestellten Beispiele nur exemplarisch zu verstehen und nicht auf diese Ausführungen beschränkt sind. Nach der Einrichtung des Modellnummernmanager-Objekts 30 kann der Modellerzeuger einen oder mehrere Teiletyp-Objekte 32 erzeugen.
In Fig. 5 ist eine Ausführung eines Teiletyp-Objekts 32 zu sehen, das ein oder mehrere Teileeigenschaft-Objekte 100, einen Teilenummernmanager 102 und mehrere Flags enthält. Das Teiletyp-Objekt 32 ist eine allgemeine Schablone, die stellvertretend für ein bestimmtes Einzelteil steht; dieses Einzelteil kann dabei ein elementares Einzelteil sein, das nicht weiter zerlegt werden kann oder es kann sich um eine Baugruppe handeln, die aus einer Reihe von kleineren Bestandteilen besteht. In beiden Fällen stellt die Sammlung aller Teiletyp- Objekte 32 zusammen eine übergeordnete Liste von Teilen dar, die ein Modellerzeuger selektieren kann, wenn er ein spezielles Produkt "modelliert". Wenn ein spezifisches Einzelteil nicht durch ein Teiletyp-Objekt 32 dargestellt ist, kann es nachher nicht während des Modellierungsprozesses verwendet werden. Um ein Teiletyp-Objekt 32 angemessen zu beschreiben, muß der Modellerzeuger zahlreiche Teileeigenschaft-Objekte 100 definieren, die Informationen über die spezifischen Eigenschaften dieses Teiletyp-Objekts enthält. Es stehen zahlreiche Kategorien von Teileeigenschaft-Objekten 100 zur Verfügung, dazu gehören die Kategorien Beschreibungseigenschaft, Mischeigenschaft, Boolesche Eigenschaft, Logische. Eigenschaft, Numerische Eigenschaft, Berechnungseigenschaft, Abmessungseigenschaft und Durchmessereigenschaft, um nur einige wenige zu nennen. Ein Objekt 100 der Kategorie Beschreibungseigenschaft kann eine beliebige Art von Textbeschreibung der Eigenschaft, die mit dem Teileeigenschaft-Objekt 100 verbunden ist, enthalten. Die Kategorie Mischeigenschaft kann Werte von anderen Teileeigenschaft-Objekten 100 strukturell analysieren und zergliedern und sie in einem einzelnen kombinierten String speichern. Die Kategorie Boolesche Eigenschaft kann einen WAHR- oder FALSCH-Wert speichern, ähnlich wie die zuvor erörterten Flags. Ein Objekt 100 der Kategorie Logische Eigenschaft kann das Resultat einer Booleschen Gleichung speichern, die auf anderen Objekten 100 der Kategorien Logische Eigenschaft oder Boolesche Eigenschaft basiert. Somit kann ein Objekt der Kategorie Logische Eigenschaft auf andere Teileeigenschaft-Objekte 100 zugreifen, um einen Wert zu ergeben. Die Kategorie Numerische Eigenschaft kann nur Zahlen speichern. Die Kategorie Berechnungseigenschaft kann das Resultat einer mathematischen Funktion mit Variablen speichern, wobei die Werte dieser Variablen in anderen Objekten der Kategorie. Numerische Eigenschaft oder Berechnungseigenschaft enthalten sind. Schließlich enthalten die Kategorien Abmessungseigenschaft und Durchmessereigenschaft Informationen zu den räumlichen Dimensionen. Es können weitere Kategorien von Teileeigenschaft-Objekten 100 bestehen; dies ist lediglich eine Liste der am häufigsten benutzten Kategorien. Jetzt, da die verschiedenen Kategorien von Teileeigenschaft-Objekten 100 genannt worden sind, werden nachstehend die Unterobjekte eines Teileeigenschaft-Objekts 100 beschrieben.
Jedes Teileeigenschaft-Objekt 100 entspricht einem speziellen Attribut des Teiletyp-Objekts 32, das gerade "modelliert" wird, und kann ein Eingabespezifikator-Objekt 110, ein Wertfilter-Objekt 112 sowie ein oder mehr Ineinanderteileeigenschaft-Objekte 114 enthalten. Wenn ein Teiletyp-Objekt 32 erstmalig erzeugt wird, befindet es sich in einem allgemeinen oder "initialisierten" Zustand; d. h. es enthält keine spezifischen Werte für die Eigenschaften des Einzelteils. Jedes Teileeigenschaft-Objekt 100 wird jedoch eingerichtet, um später während des Konfigurationsvorganges spezifische Informationen zu erhalten. Dieser Vorgang des Empfangens sowie des Prüfens und Bestätigens von Informationen schließt auch das Eingabespezifikator-Objekt 110 und das Wertfilter-Objekt 112 ein. Das Eingabespezifikator-Objekt enthält eine Verknüpfung oder einen Weg, die/der dieses spezielle Teileeigenschaft-Objekt 110 mit einem anderen Objekt innerhalb des Produktmodell- Objekts 16 verbindet. Jenes andere Objekt kann ein weiteres Teileeigenschaft-Objekt innerhalb desselben Teiletyp-Objekts sein, oder es kann sich in einem ganz anderen separaten Objekt befinden, z. B. im Modellnummernmanager-Objekt 30. Dieses Verknüpfen ermöglicht eine Kettenreaktion oder einen automatischen Informationsfluß, wenn spezifische Werte schließlich während des Konfigurationsvorganges eingegeben werden. Nehmen wir in dem zuvor erörterten Fahrrad-Szenario zum Beispiel an, daß es ein erstes Teiletyp-Objekt 32 für eine Radspeiche gibt und daß dieses Teiletyp-Objekt ein erstes Teileeigenschaft- Objekt 100 (der Kategorie Abmessungseigenschaft) enthält, welches zu der Speichenlänge gehört. Nehmen wir weiter an, das erste Teileeigenschaft-Objekt umfaßt ein Eingabespezifikator- Objekt 110, welches die Speichenlänge mit einem Teileeigenschaft-Objekt (der Kategorie Durchmesser-Eigenschaft) verbindet, das in einem zweiten Teiletyp-Objekt für eine Radbaugruppe enthalten ist. Wenn ein Anwender während des Konfigurationsvorganges einen spezifischen Wert für den Raddurchmesser eingibt, könnte dies automatisch die Speichenlänge mit dem spezifischen korrespondierenden Wert besetzen. Diese Verkettungsstruktur sorgt für eine schnelle und präzise Konfiguration eines Produktes, indem so weit wie möglich gemeinsam benutzte Daten verwendet werden. Das soeben gegebene Beispiel beschreibt ein Eingabespezifikator-Objekt 110, das zwei Teileeigenschaft-Objekte miteinander verknüpft, wobei jedoch das Eingabespezifikator-Objekt genauso leicht mit anderen Arten von Objekten verknüpft sein könnte. Wenn beispielsweise das Eingabespezifikator-Objekt 110 eine Verknüpfung enthalten würde, die das Teileeigenschaft-Objekt 100 mit einem Zeichensegment-Objekt 54 verbindet und ein Anwender würde eine spezifische Modellnummer während des Konfigurierens eingeben, dann könnte das spezifische Zeichen, das mit dem fraglichen Zeichensegment-Objekt korrespondiert, verwendet werden, um das Teileeigenschaft-Objekt automatisch mit einem spezifischen Wert zu besetzen. Ab und zu ist der automatisch durch diese verknüpfte Netzstruktur erhaltene Wert nicht sinnvoll für das Teileeigenschaft-Objekt 100, welches die Abfrage macht. In diesem Fall verwendet das Teileeigenschaft-Objekt das Wertfilter-Objekt 112, um einen sinnvollen Wert zu erhalten.
Das Wertfilter-Objekt 112 ändert einen bestimmten Wert in eine für das abfragende Teileeigenschaft-Objekt 100 sinnvollere Form um. Wenn z. B. in dem vorhergehenden Beispiel das Teileeigenschaft-Objekt 100 für die Räder der Kategorie Beschreibungseigenschaft angehört, die auf Texten basiert, anstelle einer auf einem Wert basierenden Durcchmessereigenschaft- Kategorie, dann kann der Anwender während des Konfigurierens einen qualitativen Wert wie "groß" angeben, anstelle eines quantitativen Wertes für den Raddurchmesser. Die Größe "groß" ist nicht sinnvoll für das Teileeigenschaft-Objekt 100, das zur Speichenlänge gehört und mit dem Raddurchmesser über das Eingabespezifikator-Objekt verbunden ist und einen Zahlenwert für den Durchmesser benötigt. Deshalb würde das Wertfilter- Objekt 112 "groß" in eine tatsächliche Speichenlänge umwandeln, wie z. B. 12", was dann von dem Teileeigenschaft-Objekt 100 für die Speichenlänge akzeptiert werden könnte. Dadurch läßt das Wertfilter-Objekt 112 den automatischen Fluß von Werten während des Konfigurierens fortbestehen, selbst wenn jene Werte anderer Art sind. Es wird darauf hingewiesen, daß Eingabespezifikator- und Wertfilter-Objekte, zusätzlich zum automatischen Empfangen von Informationen, wie eben erläutert, auch zum automatischen Verfügbarmachen von Informationen verwendet werden können. Es sei z. B. angenommen, das zuvor beschriebene Teileeigenschaft-Objekt für den Raddurchmesser ist mit einem zweiten Teileeigenschaft-Objekt verknüpft, welches zur Größe der Bremsen gehört. Während des Konfigurierens könnte das Eingabespezifikator-Objekt für die Räder automatisch einen Durchmesserwert an das Eingabespezifikator-Objekt für die Bremsen ausgeben, das diese Informationen wiederum benutzen könnte, um die richtige Bremsengröße zur Eingabe in ein Teileeigenschaft- Objekt für die Bremsengröße zu bestimmen. In diesem Szenario dient das Teileeigenschaft-Objekt für den Raddurchmesser, das zuvor Informationen von einem Zeichensegment-Objekt 54 erhalten hat, als Datenquelle, indem es einem Teileeigenschaft- Objekt für die Bremsen Informationen verfügbar macht.
Es lohnt sich anzumerken, daß das Wertfilter-Objekt 112 ein Spezifikator des Umwandlungstyp ist, was bedeutet, daß es zum Konvertieren eines Wertes in einen anderen Wert benutzt wird. Es gibt zahlreiche Kategorien von Spezifikatoren des Umwandlungstyps, dazu gehören: Zuordnungsspezifikatoren, Dateizuordnungsspezifikatoren, Tafelspezifikatoren, Bedingte Tafelspezifikatoren und Brüche-Spezifikatoren, um nur einige wenige zu nennen. Kurz gesagt, Zuordnungsspezifikatoren benutzen eine Eins-zu-Eins-Zuordnung von Werten, die in der Technik weit verbreitet ist, um jedem eingegebenen Wert: einen umgewandelten Wert zuzuweisen. Diese Zuordnungsliste wird vom Modellerzeuger geschaffen und kann einen Vorgabeerkenn-Flag enthalten. Wenn der Vorgabeerkenn-Flag eingestellt ist und ein eingegebener Wert nicht in der Zuordnung aufgeführt ist, wird ein Standardwert zugewiesen, anstatt eine Fehlermeldung zu senden. Wenn der Vorgabeerkenn-Flag nicht gesetzt ist und ein eingegebener Wert nicht in der Zuordnung aufgeführt ist, würde eine Fehlermeldung erfolgen. Das Dateizuordnungspezifikator-Objekt ist identisch mit dem Zuordnungspezifikator-Objekt, mit der Ausnahme, daß die Zuordnungsliste auf der Festplatte und nicht im RAM gespeichert ist. Dies ist besonders hilfreich, denn Zuordnungslisten haben eine große Anzahl von Eintragungen. Das Tafelspezifikator-Objekt verwendet eine Funktionstafel mit X- und Y-Achsen, um den Wert auszugeben, der sich in deren Schnittpunkt befindet. Statt also nur einen Einzelwert zu benötigen, wie dies bei den vorhergehenden Spezifikatoren des Zuordnungs- und Dateizuordnung-Typs der Fall war, sind bei dieser Art von Spezifikatoren zwei Werte erforderlich. Das Spezifikator-Objekt vom Typ Bedingte Tafel verwendet eine Liste von Tafelspezifikatoren, so die eigentliche Funktionstafel plus zwei Werte (insgesamt drei Eingangswerte) bereitgestellt werden müssen, um einen spezifischen Wert zu erhalten. Der Brüchespezifikator-Typ wandelt einen Bruch in eine Dezimalzahl um und umgekehrt. Dies sind nur einige der zur Verfügung stehenden Spezifikatoren des Umwandlungstyps, da auch andere in der Technik bekannte verwendet werden könnten.
Die meisten Kategorien von Teileeigenschaft-Objekten 100 enthalten nicht automatisch ein Eingabespezifikator-Objekt 110, da dies ein Objekt ist, das typischerweise erst beim Modellierungsprozeß hinzugefügt wird. Die Teileeigenschaft-Objekte der Kategorien Berechnungseigenschaft, Logische Eigenschaft und Mischeigenschaft haben jedoch permanent installierte Eingabespezifikator-Objekte. Diese Arten vor. Teileeigenschaft- Objekten 100 speichern einen Wert, der zu dieser Eigenschaft gehört, der direkt von Werten abgeleitet ist, die in anderen Objekten gespeichert sind. Deshalb ist es erforderlich, daß das Teileeigenschaft-Objekt ein Eingabespezifikator-Objekt 110 hat, um sich mit dem Objekt zu verbinden, in dem die dazugehörige Information gehalten wird. Ein weiterer Unterschied sollte angesprochen werden: der Unterschied zwischen aktiven und passiven Teileeigenschaft-Objekten 100. Die vorstehend erörterten Teileeigenschaft-Objekte definierten jeweils ein Eingabespezifikator-Objekt 110, welches eine Verknüpfung zu einem anderen Objekt enthielt. Ein solches Objekt bezeichnet man als "aktiv", da die Werte dieser vernetzten Objekte automatisch während des Konfigurierens eingesetzt werden. Dementsprechend verbreiten sich jene Werte über das gesamte Produktmodell- Objekt 16, wenn spezifische Wert während des Konfigurierens eingegeben werden, und besetzen ansonsten Leerstellen von Objekten mit spezifischen Zahlen, wo dies möglich ist. Dagegen gibt es auch ein Eingabespezifikator-Objekt 110, das nicht mit einem anderen Objekt verknüpft ist. Diese werden als "passive" Teileeigenschaft-Objekte bezeichnet, da ein manuell eingegebener Wert während der Modellierungsphase oder des Konfigurierungsvorgangs erforderlich ist. Wegen der manuellen Dateneingabe ist es wünschenswert, daß das passive Eingabespezifikator-Objekt vom Booleschen Typ ist, wie er zuvor erörtert wurde, um sicherzustellen, daß die eingegebenen Werte für das Teileeigenschaft-Objekt 100 geeignet sind.
Das Beispiel des in Fig. 5 gezeigten Ineinanderteileeigenschaft-Objekt 114 weist die gleiche Struktur auf, wie das gerade beschriebene Teileeigenschaft-Objekt 100, ist aber innerhalb eines größeren, übergreifenden Teileeigenschaft- Objekts zur leichteren Gestaltung eingebetzet. Die Verwendung von Ineinanderteileeigenschaft-Objekten, um Hilfs- oder vorübergehende Eigenschaften innerhalb einer größeren, umfassenderen Eigenschaft zu verbinden, ist optional. Da die Struktur und die Funktionalität der Ineinanderteileeigenschaft-Objekte 114 die gleiche ist wie die der gerade beschriebenen nicht eingebetteten Teileeigenschaft-Objekte 10(), wird eine weitergehende Beschreibung unterlassen.
Darüber hinaus umfaßt das Teileeigenschaft-Objekt einen Benutzequelle-Flag 120, einen Kaskade-Flag 122 und einen Ausgabe- Flag 124. Der Benutzequelle-Flag 120 ermöglicht einem Objekt, Informationen über ein Wertfilter-Objekt 112 anzufordern und dabei zu bestimmen, ob der Originalwert empfangen werden soll, bevor er durch das Wertfilter-Objekt geändert wird oder der umgewandelte Wert. Wenn der Benutzequelle-Flag gesetzt ist, wird der Originalwert benutzt, der von dem die Informationen bereitstellenden Objekt gesendet wird; wenn er nicht gesetzt ist, wird der umgewandelte Wert verwendet. Der Kaskade-Flag 122 unterstützt das automatische Besetzen von Ineinanderteileeigenschaft-Objekten 114 mit Daten. Wenn dieser Flag gesetzt ist, wird der Wert, der mit diesem Teileeigenschaft-Objekt 100 verbunden ist, automatisch in jedwede Ineinanderteileeigenschaft-Objekte 114 während des Konfigurierens eingesetzt. Dieser automatische Datenfluß erfolgt (überall), mit Ausnahme dort, wo das Ineinanderteileeigenschaft-Objekt 114 entweder der Kategorie Berechnungseigenschaft, Logische Eigenschaft oder der Misch-Eigenschaft angehört, die ein festes Eingabespezifikator-Objekt haben, welches das Ineinanderteileeigenschaft-Objekt mit einer anderen Steile verknüpft. Der Ausgabe-Flag 124 hat damit zu tun, welche Informationen dem Anwender während des Konfigurierens präsentiert werden. Wenn der Ausgabe-Flag gesetzt ist, und unter der Annahme, daß die richtigen Flags im Beschreibungsmanager-Objekt 38 (noch nicht erörtert) gesetzt sind, dann wird der Wert für dieses Teileeigenschaft-Objekt 100 in einem Ausgabebericht für den Anwender enthalten sein. Folglich kann der Modellerzeuger bestimmen, welche Teileeigenschaft-Objekte im Ausgabebericht aufgeführt sein werden.
Das Teiletyp-Objekt 32 kann auch ein Teilenummernmanager- Objekt 102 enthalten, das zum automatischen Ableiten einer sinnvollen Teilenummer für das korrespondierende Teiletyp- Objekt verwendet wird. Dies ist ein optionales Merkmal, das eine Ableitung einer Teilenummer ermöglicht. Das Teilenummernmanager-Objekt 102 definiert das Nummerierungsschema für die Teilenummer und umfaßt im allgemeinen ein oder mehr Zeichensegment-Objekte 129, die jeweils ein oder mehr Modellspezifikator-Objekte 130, ein oder mehr Wertspezifikator-Objekte 132 und ein oder mehr Zeichenkontingent-Objekte 134 umfassen, die den Objekten des Modellnummernmanager-Objekts mit den gleichen Bezeichnungen sehr ähnlich sind. Das Modellspezifikator-Objekt 130 verknüpft das Zeichensegment-Objekt 129 mit anderen Objekten, typischerweise mit einem Teileeigenschaft- oder Virtuelle Teileeigenschaft-Objekt, von dem Informationen bezogen werden können. Diese Informationen werden dann durch das Wertspezifikator-Objekt 132 in Zeichen umgewandelt, die in der Teilenummer verwendet werden. In diesem Sinne dient das Wertspezifikator-Objekt 132 nicht als Spezifikator des Booleschen Typs, sondern eher wie einer vom Umwandlungstyp. Dementsprechend können alle Kategorien des Spezifikators vom Umwandlungstyp als Wertspezifikator-Objekte 132 verwendet werden. Jedes Zeichenkontingent-Objekt 134 wird benutzt, um bestimmte Segmente der Teilenummer ein- oder auszuschalten und bestimmte Aspekte der Teilenummer-Logik nach Bedarf zu aktivieren. Kurz gesagt, das Teilenummernmanager-Objekt 102 wird während des Modellierungsprozesses erstellt, so daß ein Mechanismus vorhanden ist, um eine sinnvolle Teilenummer zu erzeugen, obwohl eine eigentliche Teilenummer erst dann vergeben wird, wenn das Produkt konfiguriert ist. Wenn der Modellerzeuger es vorzieht, ein Teilenummernmanager-Objekt wegzulassen, muß eine Teilenummer manuell zu einem späteren Zeitpunkt eingegeben werden. Diese manuell eingegebene Teilenummer würde dann statisch für jede Konfiguration des Produktmodell-Objekts 16 bleiben.
Das Teiletyp-Objekt 32 enthält auch einen Namen-String 136, einen Endbaugruppe-Flag 138 und einen Baugruppe-Flag 140. Der Namen-String 136 ist ein Zeichen-String, der vorzugsweise eine beschreibende Kennzeichnung für dieses Teiletyp-Objekt 32 enthält. Der Endbaugruppe-Wert 138 ist ein Flag, der anzeigt, ob dieses spezielle Teiletyp-Objekt zur Endmontage gehört oder nicht, was später erklärt wird. In ähnlicher Weise ist der Baugruppe-Flag 140 ein Boolescher Wert, der anzeigt, ob dieses Teiletyp-Objekt 32 eine Baugruppe aus anderen Teiletyp- Objekten ist. Selbstverständlich kann das Teiletyp-Objekt 32 sowie alle anderen Objekte zusätzliche Felder, Flags, Variablen, Unterobjekte, etc. enthalten oder eines der hier gezeigten Elemente nicht enthalten. Die Sammlung von Teiletyp- Objekten 32 dient als eine übergeordnete liste von allgemeinen Teileschablonen, aus der der Modellerzeuger bei der Modellierung einer Produktlinie auswählen kann. In ähnlicher Weise dient die Sammlung von Virtuelleteiletyp-Objekten 34 als übergeordnete Liste, aber statt allgemeine Teileschablonen darzustellen, repräsentieren sie allgemeine Modifikationen.
In Fig. 6 ist eine Ausführung eines Virtuelleteiletyp-Objekts 34 zu sehen, das eine allgemeine, standardisierte Modifikation für eine im Modellierungsprozess befindliche Produktlinie dar. Anders gesagt, das Virtuelleteiletyp-Objekt ist eine Schablone für eine verfügbare Modifikation, wie z. B. eine Option oder ein Optionspaket. Das hier gezeigte Virtuelleteiletyp-Objekt 34 enthält ein oder mehr Virtuelleteileeigenschaft-Objekte 150, die in ihrer Struktur jeweils identisch mit den zuvor beschriebenen Teileeigenschaft-Objekten 100 sind. Deshalb wird auf eine zweite Beschreibung verzichtet. Das Virtuelleteiletyp-Objekt 34 umfaßt auch einen Namen-String 152, einen Kombination-Flag 154, einen Kombiniertertyp-String 156, einen Code- String 158, einen Beschreibungsstring 160 sowie einen Leercode-String 162 und einen Wiederverwendbar-Flag 164. Der Namen- String 152 ist einfach eine Text-Zeichenkette, die den Namen dieses speziellen Virtuelleteiletyp-Objekts 34 enthält. Der Kombination-Flag 154 ist dem Baugruppe-Flag 140 ähnlich, indem er anzeigt, ob diese Option eine Kombination von anderen Optionen enthält. Unter Bezugnahme auf das zuvor verwendete Fahrrad-Szenario könnte beispielsweise ein Mountainbike- Optionspaket für diese Fahrrad-Produktlinie verfügbar sein. Das Mountainbike-Paket ist jedoch nicht ein wirkliches Einzelteil, so daß es nicht als Teiletyp-Objekt 32 dargestellt wird. Es ist vielmehr ein Optionspaket, das bestimmte Teiletyp- Objekte modifiziert, es ist also ein Virtuelleteiletyp-Objekt 34. Dieses Paket könnte eine Sammlung von individuellen Mountainbike-Optionen enthalten, wie z. B. grobstrukturierte Spurreifen, zusätzliche Stoßdämpfer, eine Reisepackung, etc. Somit wäre das gesamte Mountainbike-Optionspaket ein Virtuelleteiletyp-Objekt 34, wobei sein Kombination-Flag gesetzt ist, um anzuzeigen, daß es sich um eine Sammlung von individuellen Virtuelleteiletyp-Objekten handelt. Obwohl bisher nicht erwähnt, könnte das Modellspezifikator-Objekt 64 ein Zeichensegment-Objekt 54 mit einem Virtuelleteiletyp-Objekt 34 verknüpfen, genauso wie es ein Zeichensegment-Objekt 54 mit einem Teiletyp-Objekt 32 verknüpfen konnte. Gerade durch dieses Modellspezifikator-Objekt werden Optionen ausgewählt und innerhalb einer sinnvollen Modellnummer eingebaut. Der Code-String 158, Beschreibung-String 160 und LeerCode-String 162 können an diesem Punkt nicht besetzt werden, da sie so lange noch nicht editierbar sind, bis ein Profil-Objekt 36 definiert ist. Deshalb erfolgt eine Beschreibung dieser Variablen weiter unten. Kurz gesagt, Virtuelleteiletyp-Objekte 34 sind nicht wirkliche Einzelteile, weshalb sie auch nicht als Teiletyp-Objekte 32 dargestellt sind, es handelt sich vielmehr um Optionen, die, wenn sie ausgewählt werden, die Attribute der wirklichen Einzelteile modifizieren. Sobald alle Virtuelleteiletyp-Objekte 34 erzeugt sind, kann der Modellerzeuger dazu übergehen, ein Profil-Objekt 36 zu erzeugen.
In Fig. 7 ist ein Beispiel für ein Profil-Objekt 36 zu sehen, das ein Endbaugruppeteile-Objekt 180, ein oder mehr Virtuelleteile-Objekte 182 und mehrere Informationsfelder umfaßt. Während das Produktmodell-Objekt 16 eine gesamte Produktlinie repräsentiert, stellt das Profil-Objekt 36 ein spezielles Produktszenario innerhalb dieser Produktlinie dar. Das Produktszenario wiederum steht stellvertretend für eine spezielle Produktstruktur und schließt eine Vielzahl von spezifischen, zulässigen Produktkonfigurationen ein. Manchmal, wenn die verschiedenen Konfigurationen, die für ein einzelnes Produkt verfügbar sind, sich deutlich unterscheiden, ist es gerechtfertigt, verschiedene Profil-Objekte 36 für ein einzelnes Produkt zu erzeugen; eines für jeden Haupttyp der Variation. Wenn z. B. ein spezielles Fahrradprodukt sowohl eine Herrenrad- als auch eine Damenradversion umfaßt, zwischen denen nur kleine Unterschiede vorhanden sind, könnte ein einziges Profil-Objekt 36 erzeugt werden, um die Struktur der beiden Variationen ausreichend zu beschreiben. Wenn sich jedoch die Herrenradversion von der Damenradversion deutlich in vieler, verschiedenen Bereichen unterscheiden würde, wäre es vorteilhaft, separate Profil-Objekte 36 zu haben, die auf jeweils eine Version ausgerichtet sind. Um ein Profil-Objekt 36 zu erstellen, beginnt der Modellerzeuger mit dem Auswählen aus der Sammlung von Teiletyp-Objekten 32, die bereits geschaffen worden sind. Vorzugsweise wird das Profil-Objekt so erzeugt, daß Teile in einer hierarchischen Ordnung zusammengesetzt werden, wobei mit einer Gesamtbaugruppe angefangen und mit kleineren individuellen Einzelteilen fortgefahren wird.
Vorzugsweise beginnt der Modellerzeuger mit einem Endbaugruppeteile-Objekt 180, welches stellvertretend für das herzustellende Endprodukt steht. Um ein spezielles Endbaugruppeteile- Objekt 180 auszuwählen, studiert der Modellerzeuger nur solche Teiletyp-Objekte 32, die durch ihren Endbaugruppe-Flag 138 als Endbaugruppen gekennzeichnet sind. Wenn ein als Endbaugruppe gekennzeichnetes Teiletyp-Objekt 32 ausgewählt und dem Profil- Objekt 36 zugefügt ist, wird es zu einem Endbaugruppeteile- Objekt 180. In diesem Endbaugruppeteile-Objekt 180 enthalten sind alle die Teileeigenschaft-Objekte 100 und anderen Informationen, die eingerichtet wurden, als das Teiletyp-Objekt 32 anfangs erzeugt wurde. Vorzugsweise hat jedes Profil-Objekt 36 nur ein einziges Endbaugruppeteile-Objekt 180, das wiederum so eingerichtet ist, daß es eine Vielzahl von Teile-Objekten 184 enthält. Wenn der Baugruppe-Flag 140 eines Teiletyp-Objekts 32 gesetzt ist, dann kann dieses Teiletyp-Objekt ein oder mehr untergeordnete Teiletyp-Objekte enthalten, wenn es dem Profil- Objekt zugefügt wird. Dieser Ablauf des Zufügens von Teiletyp- Objekten geht weiter, bis ein Teiletyp-Objekt zugefügt wird, das nicht eine Baugruppe ist. Wenn ein Teiletyp-Objekt 32 ausgewählt wird und einem Profil-Objekt zugefügt wird, ist das zugefügte Objekt nicht mehr ein Teiletyp-Objekt, sondern es ist jetzt ein Teile-Objekt 184. Das Teile-Objekt 184 hat alle die gleichen Elemente, wie die zuvor erörterten Teiletyp- Objekte 32 sowie ein oder mehr optionale Konfigurationsmanager-Objekte 200.
Das Konfigurationsmanager-Objekt 200 ist optional und ermöglicht es dem Anwender, Kundenmodifikationen auszuwählen, die nicht in den Teiletyp-Objekten 32 oder Virtuelleteiletyp- Objekten 34 vorgesehen sind. Das Teile-Objekt 184 kann ein oder mehr Konfigurationsmanager-Objekte 200 enthalten, die jeweils einen Namen-String 202, ein Beschränkung-Objekt 204, ein Modifizierer-Objekt 206, ein Aktiv-Flag 208, einen Einmalausführen-Flag 210 sowie einen Initialisiere-Flag 212 umfaßt. Der Namen-String 202 identifiziert einfach das spezielle Konfigurationsmanager-Objekt. Das Beschränkung-Objekt 204 und das Modifizierer-Objekt 206 dienen zusammen als ein Art "wenn-dann" Anweisung. Das Beschränkung-Objekt stellt eine Beschränkung oder Bedingung dar, während das Modifizierer-Objekt eine Folge darstellt, wenn diese Bedingung erfüllt ist. Ein Beschränkung- Objekt könnte aussagen, "wenn der Fahrradrahmen eine "große" Größe hat" und das Modifizierer-Objekt könnte dann heißen "dann füge ein Verlängerungsrohr zur Sitz-Baugruppe hinzu". Zu den üblichen Fähigkeiten der Modifizierer-Objekte 206 gehört, daß sie ein Teil hinzufügen, ein Teil entfernen, ein Teil auf der Basis einer gewünschten Menge hinzufügen, einen Wert für ein Teileeigenschaft-Objekt setzen sowie ein Teil von einer speziellen Verweistabelle für Einzelteile austauschen können, wobei diese Tabelle als Teileresourcen bezeichnet wird, die später beschrieben wird. Durch den Aktiv-Flag 208 kann, wenn er gesetzt ist, das Konfigurationsmanager-Objekt 200 deaktiviert oder abgeschaltet werden. Das ist besonders nützlich, wenn der Modellerzeuger das Konfigurationsmanager-Objekt zeitweise deaktivieren will, ohne es zu löschen, z. B. während der Fehlerbeseitigung. Der Einmalausführen-Flag 210 erlaubt, wenn er gesetzt ist, daß das Konfigurationsmanager-Objekt 200 nur einmal während des Konfigurationsvorganges ausgeführt wird, wodurch dem Kunden nur eine einzige Gelegenheit gewährt wird, seine Auswahl zu treffen. Dies kann vorteilhaft sein, wenn der Modellerzeuger verhindern möchte, daß ein Anwender Änderungen vornehmen kann, nachdem ein bestimmter Anteil des Konfigurationsvorganges abgelaufen ist. Schließlich wird das Konfigurationsmanager-Objekt 200, wenn der Initialisiere-Flag 212 gesetzt ist, während des Konfigurationsvorganges vor allem anderen Objekten ausgeführt. Dies ist nützlich, wenn Kundenmodifikationen, die auftreten, zuerst behandelt werden müssen, damit sie später richtig berücksichtigt werden können. Es lohnt sich anzumerken, daß das Konfigurationsmanager-Objekt nur verwendet werden kann, um Teile-Objekte nach Kundenwunsch anzupassen, die identifizierbar sind, wenn das Profil-Objekt 36 eingerichtet ist. Das heißt, der Modellerzeuger muß bei der Erstellung des Profil-Objekts die Teile-Objekte spezifisch kennzeichnen, die für eine Modifikation in Frage kommen. Ein Stapelkonfigurationsmanager-Objekt (nicht dargestellt) ist dem Konfigurationsmanager-Objekt im wesentlichen ähnlich. Es ermöglicht jedoch einem Anwender, die Teile-Objekte während des Konfigurierens zu modifizieren, wodurch noch mehr Flexibilität beim Vornehmen von Modifikationen gegeben ist.
Das Virtuelleteile-Objekt 182 unterstützt Optionen oder Standardmodifikationen für das Profil-Objekt 36 und umfaßt generell alle zuvor im Zusammenhang mit dem Virtuelleteiletyp- Objekt 34 diskutierten Elemente. Wie bei den Teiletyp- und Teile-Objekten, wird aus einem Virtuelleteiletyp-Objekt 34, sobald es einem Profil-Objekt 36 zugefügt wird, ein Virtuelleteile-Objekt 182. Das ursprüngliche Virtuelleteiletyp-Objekt 34, das ausgewählt wurde, bleibt jedoch in der Sammlung von Virtuelleteiletyp-Objekten erhalten, damit es beim Erzeugen von weiteren Profil-Objekten 36 ausgewählt werden kann. Das gleiche gilt für Teiletyp-Objekte. Während des Modellierungsprozesses sind alle Virtuelleteile-Objekte 182, die der Modellerzeuger für eine spätere Auswahl verfügbar macht, in einem umfassenden Profil-Objekt 36 enthalten. Während des Konfigurationsvorganges werden jene Virtuelleteile-Objekte, die tatsächlich ausgewählt wurden, in der Virtuelleteileliste 220 aufgenommen, die sich im Endbaugruppeteile-Objekt 180 befindet. Darüber hinaus könnte das Profil-Objekt 36 mehrere Virtuelleteileliste-Objekte enthalten, eines für jedes Virtuelleteiletyp-Objekt 34, das als Schablone während der Erstellung des Profil-Objekts verwendet wurde. Wenn beispielsweise ein Virtuelleteiletyp-Objekt mit dem Namen "Option", als Schablone verwendet wird, um ein Dutzend verschiedener Virtuelleteile- Objekte 182 zu erstellen, wobei jedes einen kennzeichnenden Code-String 158 hat, dann hätte diese Schablone mit der Bezeichnung "Option" ihr eigenes Virtuelleteileliste-Objekt 220. Wird während des Konfigurierens ein spezifisches Virtuelleteile-Objekt 82 ausgewählt, so wird sein korrespondierender Code- String 158 der Virtuelleteileliste 220 zugefügt.
Die zuvor erzeugten Virtuelleteiletyp-Objekte 34 waren allgemeine Schablonen, so daß jetzt zusätzliche Informationen bereitgestellt werden müssen. Der Beschreibungsstring 160 enthält eine Textbeschreibung dieses speziellen Virtuelle- Teiletyp-Objekts 182 und wird nun durch der Modellerzeuger bereitgestellt. Zahlreiche Virtuelleteile-Objekte 82 können aus einer einzigen Schablone eines Virtuelleteiletyp-Objekts 34 geschaffen werden, deshalb besteht die Notwendigkeit für einen Code-String 158, um sie zu unterscheiden. Jedesmal wenn ein Virtuelleteiletyp-Objekt ausgewählt und einem Profil-Objekt 36 zugefügt wird, muß der Modellerzeuger das neu erzeugte Virtuelleteile-Objekt 182 mit einem spezifischen Code-String 158 versehen. Dieser Code-String wird von dem Modellspezifikator- Objekt 64 im Zeichensegment-Objekt 54 auf eine Art verwendet, daß die Zeichen des Codes mit den Zeichen in der Modellnummer 50 korrespondieren. Der Leercode-String 162 ist eine Zeichenkette, die von einem Virtuelleteile-Objekt des Kombinationstyps ausgegeben wird, wenn die Kombination leer ist. Der Wiederverwendbar-Flag 164 bestimmt, ob ein Virtuelleteile-Objekt 182, dessen Kombination-Flag 154 nicht gesetzt ist, sowohl für ein Kombination-Virtuelleteile-Objekt als auch für ein einzelnes Virtuelleteile-Objekt verwendet werden kann. Wenn der Wiederverwendbar-Flag gesetzt ist, wird das Virtuelleteile-Objekt 182, das nicht dem Kombinationstyp angehört, berechtigt, ein Teil eines separaten Virtuelleteile-Objekts zu werden, dessen Kombination-Flag gesetzt ist. Somit wird das eine Virtuelleteile-Objekt, das in der Kombination enthalten ist, mehrfach verwendet, anstatt zwei doppelte Virtuelleteile-Objekte gehalten werden: eines für das einzelne Virtuelleteile-Objekt und eines für das Kombinations-Virtuelleteile-Objekt. Wie bei dem Teile-Objekt 184 kann das Virtuelleteile-Objekt 183 auch entweder ein Konfigurationsmanager-Objekt oder ein Stapelkonfigurationsmanager-Objekt umfassen.
Das Profil-Objekt 36 umfaßt auch einen Überarbeitungsdatum- String 222 und einen Version-String 224. Der Überarbeitungsdatum-String 222 enthält einen String aus Zeichen, der das Überarbeitungsdatum des betreffenden speziellen Profil-Objekts 36anzeigt. Dadurch kann der Modellerzeuger ein Profil-Objekt 36 kopieren, den Überarbeitungsdatum-String 222 ändern und Änderungen im Profil-Objekt vornehmen, ohne frühere Versionen dieses Profil-Objekts zu verändern. Das erfindungsgemäße Produktkonfigurationssystem 10 betrachtet alle Überarbeitungen als ein einziges Profil-Objekt, d. h. sie stammen alle von einem gemeinsamen Vorgänger ab. Während des Konfigurationsvorganges wählt das System die Version mit dem letzten Überarbeitungsdatum-String, wenn keine gegenteiligen Anweisungen vom Anwender vorliegen. Der Version-String identifiziert lediglich die Version des Modellier-Tools 12, das zum Erstellen dieses Profil- Objekts verwendet wird.
Sobald das Profil-Objekt 36 eingerichtet ist, existiert jetzt ein Modell eines bestimmten Produkt-Szenarios innerhalb der Produktlinie. Allgemein definiert dieses Modell alle Attribute, Einzelteile, Strukturen, Nummerierungsschemata, Beziehungen, etc., die erforderlich sind, um das Produkt ausreichend zu beschreiben. Anders gesagt, das Profil repräsentiert ein Gattungsmodell eines spezifischen Produkts. Die für jenes Produkt erforderliche Struktur und die besonderen Einzelteile sind durch das Profil spezifisch definiert, wobei jedoch die individuellen Werte für das Produkt erst während des Konfigurationsvorganges eingetragen werden. Das nächste zu erzeugende Element des Produktmodell-Objekts 16 ist das Beschreibungsmanager-Objekt 38.
Das Beschreibungsmanager-Objekt 38 in Fig. 8 ist ein Objekt des Perspektive-Typs, das bestimmt, welche Informationen aus dem Profil-Objekt 36 herausgezogen und einer externen Anwendung 18 während des Konfigurationsvorganges zur Verfügung gestellt werden. Die hier gezeigte spezielle Ausführung des Beschreibungsmanager-Objekts 38 gehört zu einer Stückliste und enthält ein oder mehr Teiledescriptor-Objekte 230, ein oder mehr Stapelteiledescriptor-Objekte 232 und ein oder mehr Kundendescriptor-Objekte 234. Jedes Teiledescriptor-Objekt 230 ist so ausgeführt, daß es spezifische Informationen im Profil- Objekt 36 lokalisiert und herauszieht und diese Informationen in einer bestimmten Zeile eines Ausgabeberichts darstellt. Im allgemeinen enthält das Teiledescriptor-Objekt ein Teilespezifikator-Objekt 240, ein Virtuelleteilespezifikator-Objekt 242 und ein Beschränkung-Objekt 244. Wie andere zuvor erörterte Objekte des Spezifikator-Typs enthält das Teilespezifikator- Objekt 242 eine Verknüpfung, die es mit einem spezifischen Teileeigenschaft-Objekt 100 verbindet, so daß das Beschreibungsmanager-Objekt 38 bei Bedarf auf spezifische Attribute zugreifen kann. Sobald diese Informationen beim Teiledescriptor-Objekt 230 eingegangen sind, muß es bestimmen, welche Informationen an die Informationen anfordernde externe Anwendung 18 ausgegeben werden sollen. Hier kommt jetzt das Beschränkung-Objekt 244 ins Spiel. Das Beschränkung-Objekt 244 enthält im wesentlichen Aussagen des "wenn"-Typs, ähnlich wie das Beschränkung-Objekt 204, um zu bestimmen, welche Informationen verfügbar gemacht werden, und es ist mit einem spezifischen Teilespezifikator-Objekt 240 verknüpft. Wenn die "wenn"- Aussage wahr ist, werden die im korrespondierenden Teilespezifikator-Objekt 240 enthaltenen Informationen in einer Zeile des Ausgabeberichts verfügbar gemacht; wenn die "wenn"-Aussage falsch ist, entfällt die Zeile im Ausgabebericht. Auf diese Weise kann das Beschreibungsmanager-Objekt 38 steuern, welche Informationen an welche externe Anwendung 18 verfügbar gemacht werden. Wenn beispielsweise ein Anwender einer Materialkauf- Anwendung wissen möchte, wie die Stückliste für ein spezielles Produkt aussieht, würde der Anwender das Beschreibungsmanager- Objekt aufrufen, das für Stücklisten verwendet wird. Jenes Beschreibungsmager-Objekt enthält ein oder mehr Teiledescriptor- Objekte, wobei jedes davon, grob gesagt, eine Zeile eines Ausgabeberichts darstellt. Jedes Teiledescriptor-Objekt wiederum enthält ein oder mehr Beschränkung-Objekte 244. Für jede Zeile oder Eingabe in einem Ausgabebericht werden die korrespondierenden Beschränkung-Objekte 244 ausgewertet. Wenn die Aussage wahr ist, holt das korrespondierende Teilespezifikator-Objekt 240 (oder je nachdem die Virtuelleteilespezifikator- oder Stapelteilespezifikator-Objekte) die gesuchten Informationen ein und das Teiledescriptor-Objekt 230 gibt diese Informationen in der Form einer Zeile eines Ausgabeberichtes aus, der diese Informationen widerspiegelt. Wenn die Aussage falsch ist, entfällt diese Zeile im Ausgabebericht. Somit würde der Anwender einen Ausgabebericht erhalten, der Informationen über die Stückliste enthält, jedoch keine nicht-angeforderten Informationen wie z. B. eine Preisliste, etc. Ein im wesentlichen identisches System wird verwendet, um Informationen von Virtuelleteileeigenschaft-Objekten 150 über das Virtuelleteilespezifikator-Objekt 242 zugänglich zu machen.
Informationen, die von dem Teilespezifikator-Objekt 240 aus einem Teile-Objekt oder einem Virtuelleteile-Objekt entnommen werden, werden in Verbindung mit einem oder mehreren der folgenden Flags verwendet: Name 250, Eigenschaft 250, Teilenummer 254, Ebene 256 oder Kommentare 258, um nur einige wenige zu nennen. Wenn der Namen-Flag 250 gesetzt ist, wird der Name des Teiledescriptor-Objekts 230 in einer Zeile ausgegeben. Wenn der Eigenschaft-Flag 252 gesetzt ist, werden alle Teileeigenschaft-Objekte für das korrespondierende Teile-Objekt, deren Ausgabe-Flag 124 gesetzt ist, in der Ausgabezeile aufgenommen. Wenn der Teilenummer-Flag 254 gesetzt ist, wird das Teilenummernmanager-Objekt 102 des korrespondierenden Teile-Objekts benutzt, um eine Teilenummer für die Ausgabezeile abzuleiten. Wenn kein Teilenummernmanager-Objekt gesetzt ist, wird die manuell eingegebene Teilenummer verwendet. Wenn der Ebene-Flag 256 gesetzt ist, wird die hierarchische Ebene des korrespondierenden Teile-Objekts innerhalb des Profil-Objekts angegeben. Wenn, zu guter Letzt, der Kommentare-Flag gesetzt ist, erscheinen Kommentare zu dem Teile-Objekt, wie sie vom Modellerzeuger vorgesehen wurden, in der Ausgabezeile.
Das Stapelteiledescriptor-Objekt 232 ist dem Teiledescriptor- Objekt 230 ähnlich, mit dem Unterschied, daß dieses Objekt in der Lage ist einen Ausgabebericht mit mehreren Ausgabezeilen bereitzustellen, die einer Masse von Teile-Objekten im Profil- Objekt entsprechen, und nicht nur einer einzigen Ausgabezeile, die einem einzigen Teile-Objekt entspricht. Das Stapelteiledescriptor-Objekt 232 enthält ein Teilezusammenfassungspezifikator-Objekt 270 und ein Beschränkung-Objekt 272. Das Teilezusammenfassungspezifikator-Objekt enthält eine Verknüpfung zu Informationen, die sich im Profil-Objekt 36 befinden, aber anstatt eine direkte Verknüpfung zu einem spezifischen Teile-Objekt vorzusehen, ermöglicht dieses Objekt einem Anwender, eine Verknüpfung zu definieren, die Informationen von allen Teile-Objekten einholt, die den Kriterien entsprechen. Beispielsweise kann ein Anwender Informationen für alle Teile-Objekte ermitteln oder ausschließen, deren Baugruppe-Flags 138 gesetzt sind. Wie zuvor enthält das Stapelteiledescriptor-Objekt 232 ein Beschränkung-Objekt 272, das bestimmt, welche Zeilen eines Ausgabeberichts aufgenommen werden.
Es kann auch ein Kundendescriptor-Objekt 234 vorhanden sein, das die speziellen Informationen in einem Ausgabebericht kundengerecht aufbereiten kann. Dieses Kundendescriptor-Objekt enthält ein Kundenspezifikator-Objekt 280 und ein Beschränkung-Objekt 282 und gibt dem Anwender die Möglichkeit, entweder einen Text- oder einen mathematischen Ausdruck zu konstruieren, um Informationen nach dessen Wahl aus dem Profil-Objekt 36 zu erlangen. Wie zuvor erörtert, umfaßt das Spezifikator- Objekt 280 eine Verknüpfung zu den gesuchten speziellen Informationen und das Beschränkung-Objekt 282 dient als Filter bei der Bestimmung, welche Informationen im Ausgabebericht enthalten sein werden. Es wird darauf hingewiesen, daß das in Fig. 8 dargestellte und vorstehend beschriebene Beschreibungsmanager-Objekt 38 für ein Stückliste-Objekt des Perspektive-Typs bestimmt ist, daß jedoch auch andere Objekte des Perspektive-Typs zur Verfügung stehen können. Ein Beschreibungsmanager-Objekt für eine Preisliste, d. h. eine Liste, die den Preis jedes Einzelteils eines speziellen Produkts enthält, und ein Beschreibungsmanager-Objekt für eine Beschreibung des Produkts sind nur einige Beispiele für andere Objekte des Perspektive-Typs, die bereitgestellt werden könnten. Durch diesen architekturartigen Aufbau können auch später noch Objekte des Perspektive-Typs hinzugefügt werden, um Informationen ausgeben zu können, die heute noch nicht vorgesehen sind. Der nächste Schritt bei der Erzeugung des Produktmodells 16 besteht darin, das Teileresourcen-Objekt 40 einzurichten.
Das Teileresourcen-Objekt 40 enthält eine Liste von vorkonfigurierten Teilen oder Baugruppen, die dem Profil-Objekt 36 während des Konfigurierens zugefügt werden können. Diese vorkonfigurierten Baugruppen werden dem Produktmodell-Objekt 16 zugefügt, wobei alle ihre Teileeigenschaft-Objekte bereits mit spezifischen Werten besetzt sind. Somit handelt es sich nicht um allgemeine Schablonen von Einzelteilen wie die Teiletyp- Objekte 32, in denen noch keine spezifischen Werte eingesetzt sind. Vielmehr sind sie statische Modelle mit vorbestimmten Werten, die manchmal als "off line", d. h. abgeschaltet oder nicht mehr angeschlossen, bezeichnet werden. Es ist möglich, die verschiedenen Teileresourcen in einer Liste zu speichern, anstatt in einem Objekt.
Der letzte Schritt bei der Erzeugung des Produktmodell-Objekts 16 ist die Zusammenstellung der verschiedenen Objekte in einer einzigen elektronischen Produktmodell-Datei. 16, wie z. B. einer Datei mit einer ".dpm"-Endung. Das Anlegen der ".dpm"-Datei kann durch Konvertieren der zuvor erörterten Klasse/Objekt- Struktur in ein Binärformat erfolgen. Eine objekt-orientierte Programmiersprache, wie z. B. die JAVA-Sprache von Sun Microsystems, würde diese Konvertierung in Binärformat ermöglichen. Bis zu diesem Punkt war die Beschreibung der vorliegenden Erfindung primär auf die Struktur des Produktmodell-Objekts 16 gerichtet. Der Vorgang des Eingebens von. Informationen über eine Produktlinie in das Produktmodell-Objekt 16 wird als "Modellierungsprozess" bezeichnet. Die Beschreibung wendet sich jetzt dem Prozeß des Konfigurierens eines spezifischen Produktes zu, dem Abrufen detaillierter Informationen über jenes Produkt und dem Verwenden jener Informationen in einer bestimmten Weise. Dieser Prozess wird als "Konfigurationsvorgang" bezeichnet und erfolgt mit Hilfe des Runtime-Tools 14.

Runtime-Tool

Das Runtime-Tool 14 ist eine Software-Ebene, die es zahllosen Arten von externen Anwendungen 18 ermöglicht, Zugriff auf die innerhalb des Produktmodell-Objekts 16 gespeicherten Informationen zu erhalten und sie zu nutzen. Anders gesagt ist das Runtime-Tool 14 eine binäre Bibliothek, die als Schnittstelle zum Programmieren von Anwendungsprogrammen (API [Application Programming Interface]) verwendet werden kann, um eine Kundenanwendung oder eine externe Anwendung 18 mit spezifischen Produktinformationen zu verbinden, die im Produktmodell enthalten sind. Beispielsweise könnte bei einer externen geschäftlichen Anwendung, wie z. B. bei einem ERP-System, einer Produktpreisfestsetzungsanwendung, einer Firmen-Website oder einer Verkaufsanwendung das Runtime-Tool 14 verwendet werden, um Zugriff auf die Informationen zu erhalten, die von der Ausgabe-Perspektive benötigt werden, die mit dieser speziellen Anwendung 18 korrespondiert. Somit startet das Runtime-Tool 14 das Produktkonfigurationssystem 10 mit einer enormen Flexibilität aus, besonders in Situationen, wo ein Hersteller eine Vielzahl von externen Anwendungen benutzen, aber nur eine einzige Informationsquelle unterhalten will.
Fig. 9 gibt einen allgemeinen Überblick über die Struktur einer Ausführungsform des Runtime-Tool 14. Das dargestellte Runtime-Tool hat mehrere Sitzungs-Objekte geladen, die nachfolgend erklärt werden, wobei jedes davon ein Produktmodell- Objekt 16 enthält. Die innerhalb dieses Produktmodell-Objekts enthaltenen Informationen werden während des Konfigurationsvorganges verwendet, um einen Ausgabebericht zu erstellen, welcher dann einer externen Anwendung 18 verfügbar gemacht wird. In der bisherigen Beschreibung des Produktmodell-Objekts 16 wurde dieses Objekt primär im Hinblick auf Struktur und Architektur beschrieben, in der folgenden Beschreibung wird das Runtime-Tool 14 primär hinsichtlich seiner Funktionalität dargestellt.
In Fig. 10 ist ein allgemeiner Überblick über die Funktionen des Runtime-Tool 14 zu sehen, die die folgenden Hauptsequenzen umfassen: die Initialisieresitzung-Sequenz 300, die Konfiguriereprodukt-Sequenz 302 und die Datenerhebungsausgabe-Sequenz 304. Die Initialisieresitzung-Sequenz eröffnet eine Sitzung, welche den Rahmen bildet, in dem das Runtime-Tool 14 ein Produkt konfiguriert. Der Prozeß des Konfigurierens eines Produkts kann eine Vielzahl von individuellen Vorgängen des Informationsaustausches umfassen, die alle innerhalb des Rahmens der Sitzung stattfinden und somit durch Verwendung einer gemeinsamen Sitzungsbezeichnung identifiziert werden, die als Sitzungs-ID bezeichnet wird. Die Konfiguriereprodukt-Sequenz sendet eine eingegebene Modellnummer an das Produktmodell- Objekt 16, welches dann ein Produkt konfiguriert, wenn jene Modellnummer mit einer gültigen Produktkonfiguration korrespondiert. Sobald ein Produkt konfiguriert ist, informiert die Datenerhebungsausgabe-Sequenz das Produktmodell-Objekt 16 darüber, welche Ausgabeinformationen gebraucht werden, während dann ein korrespondierendes Beschreibungsmanager-Objekt die angeforderten Informationen ausgibt. Es versteht sich, daß dies ein sehr allgemeiner Überblick ist und nicht alle Aspekte des Runtime-Tool berücksichtigt. Beispielsweise gibt es zahllose Aspekte zu dem Thema, wie das Runtime-Tool mit mangelhaften Informationen umgeht, in Situationen also, wo das Runtime- Tool nicht genügend Informationen hat, um ein Produkt richtig zu konfigurieren. Die Erörterung wendet sich nun einer detaillierteren Beschreibung der ersten Sequenz im Konfigurationsprozeß zu, der Initialisieresitzung-Sequenz 300.
Man kann sich eine Sitzung als eine virtuelle Produktionsfabrik vorstellen, bei der das Runtime-Tool 14 zum Konfigurieren von Produkten verwendet wird. Das Runtime-Tool kann zum Erzeugen von Mehrfachsitzungen benutzt werden, die nur durch den Speicherplatz beschränkt sind, und jede Sitzung kann wiederum Zugriff auf viele Produktmodell-Objekte 16 haben. Es kann jedoch nicht mehr als ein einziges Produktmodell-Objekt auf einmal aktiv sein. In Fig. 11 ist die Initialisieresitzung- Sequenz 300 detaillierter dargestellt, wobei es mehrere Arten gibt, um eine Sitzung zu initialisieren.
Als erstes muß der Anwender bestimmen, ob er eine neue Sitzung eröffnen oder eine von den bereits existierenden aufrufen will (Schritt 310). Wenn der Anwender eine neue Sitzung wählt, muß er ein Verfahren dafür wählen. Die erste Entscheidung beinhaltet, ob der Anwender nach der Firma suchen will (Schritt 312). Wenn der Anwender sich entscheidet, nach der Firma zu suchen, wird ihm der Firmaauswahl-Schritt 314 vorgelegt, der eine Liste mit allen dem Runtime-Tool 14 verfügbaren Firmen enthält. Von dieser Liste muß der Anwender eine bestimmte Firma auswählen, wodurch wiederum bestimmt wird, welche Produktmodell- Objekte in dieser speziellen Sitzung verfügbar sein werden. Wenn beispielsweise die Firma X ausgewählt wird, sind nur die Produktmodell-Objekte verfügbar, die der Firma X zugewiesen sind. Als nächstes erscheint der Erzeugesitzung-Schritt 316, bei dem ein Sitzungs-Objekt erzeugt und Zugriff zu allen Produktmodell-Objekten der ausgewählten Firma gewährt wird.
Zurück zu Schritt 312: Wenn sich der Anwender entscheidet, nicht nach der Firma zu suchen, stehen ihm noch immer mehrere andere Suchoptionen zur Verfügung. Die erste Option betrifft das Suchen anhand der Modellnummer (Schritt 320). Wenn der Anwender entscheidet, anhand der Modellnummer zu suchen, dann ermöglicht der Modellnummernsuchen-Schritt 322 dem Anwender, entweder eine vollständig oder teilweise bekannte Modellnummer einzugeben. Wie eine Internet-Suchmaschine benutzt das Runtime-Tool 14 diese Modellnummer, um jedes Produktmodell 16 zu durchsuchen und kommt mit einer Liste von Produktmodell- Objekten und einer prozentuellen Übereinstimmung zurück. Die prozentuelle Übereinstimmung zeigt an, ob jene Modellnummer bei dem Modellnummernmanager-Objekt 30 des speziellen Produktmodell-Objekts gültig ist. Es sei angemerkt, daß nicht für jedes Produktmodell-Objekt eine Sitzung erzeugt wird, für das eine prozentuelle Übereinstimmung gefunden wird. Vielmehr muß der Anwender ein Produktmodell-Objekt von der Liste auswählen, das anschließend verwendet wird, um ein entsprechendes Sitzungs-Objekt zu erzeugen.
Zurück zu Schritt 320: Wenn der Anwender nicht anhand der Modellnummer suchen will, bleibt als einzige Option übrig, anhand des Produktmodells zu suchen (Schritt 330). Es gibt mehrere verschiedene Wege, auf denen ein Anwender anhand des Produktmodells suchen kann. Beispielsweise könnte dem Anwender eine Liste mit verschiedenen Produktmodell-Objekten 16 vorgelegt werden, die dem Runtime-Tool zur Verfügung stehen, aus der er eines auswählen könnte. Wenn der Anwender eine spezifische Produktmodellbezeichnung kennt, wie z. B. einen Namen oder Code, kann er diese Informationen eingeben und das Runtime- Tool könnte die verfügbaren Produktmodell-Objekte nach einer passenden Kennzeichnung durchsuchen. Unabhängig davon, welche spezielle Methode benutzt wird, geht die Steuerung zu dem Erzeugesitzung-Schritt 332 über, sobald ein Produktmodell-Objekt 16 ausgewählt wurde. Der Erzeugesitzung-Schritt 332 ist dem Erzeugesitzung-Schritt 316 ähnlich, wobei jedoch Schritt 332 ein Sitzungs-Objekt erzeugt, das nur Zugriff auf die gerade ausgewählten, einzelnen Produktmodell-Objekte 16 gewährt, während Schritt 316 ein Sitzungs-Objekt erzeugt, das Zugriff auf alle Produktmodell-Objekte der ausgewählter. Firma hat.
Zurück zu Schritt 310: Wenn der Anwender entscheidet, aus den bereits existierenden Sitzungs-Objekten auszuwählen, und nicht eine neue Sitzung erzeugt, dann liefert der Vorhandenesitzungauswahl-Schritt 340 dem Anwender eine Liste von bereits bestehenden Sitzungs-Objekten, aus der er auswählen kann. Nach getroffener Wahl muß der Anwender entscheiden, ob er das bestehende Sitzungs-Objekt noch einmal verwenden oder ob er es kopieren will (Schritt 342). Wenn der Anwender entscheidet, das Sitzungs-Objekt noch einmal zu verwenden, kann er durch Überschreiben Änderungen vornehmen und diese abspeichern (Wiederverwendesitzungobjekt-Schritt 344); wenn der Anwender entscheidet, das Sitzungs-Objekt zu kopieren, wird eine identische Kopie angelegt und das original vorhandene Sitzungs- Objekt bleibt unverändert (Kopieresitzungobjekt-Schritt 346). Gleichgültig, welchen Weg der Anwender wählt, um vom Anfang der Initialisieresitzung-Sequenz 300 bis zu dessen Ende zu gelangen, bis der Anwender soweit ist, daß er diese Sequenz verläßt und zur Konfiguriereprodukt-Sequenz 302 übergeht, wurde ein Sitzungs-Objekt eröffnet. Dieses Sitzungs-Objekt bestimmt, welche Produktmodell-Objekte anschließend während des Konfigurationsvorganges verfügbar sind. Zusätzlich wurden die Modellnummernmanager-Objekte 30 jedes verfügbaren Produktmodell- Objekts initialisiert, was nun erklärt wird.
In Fig. 12 ist die Konfiguriereprodukt-Sequenz 302 dargestellt, die den Konfigurationsprozeß implementiert. Der Konfigurationsprozeß beginnt dort, wo das Runtime-Tool 14 einen beliebigen Zeichenstring, der als Modellnummer bezeichnet wird, an ein Produktmodell-Objekt 16 schickt, clas wiederum diesen String in ein sehr detailliertes Datenmodell umwandelt, von dem spezifische Informationen abgerufen werden können. Dieser Prozeß resultiert in einer "Produkt-Freigabe" an die externe Anwendung 18, d. h. einem Benutzer der externen Anwendung wird ermöglicht, daß er Wissen über ein Produkt vom elektronischen Standpunkt aus erlangt. Eine Anwendung 18 mit Produkt-Freigabe kann eine Modellnummer eingeben und dann einen korrespondierenden Preis, eine Beschreibung des Produkts oder eine Stückliste abrufen. Der erste Schritt im Konfigurationsvorgang besteht darin, eine Modellnummer an ein Produktmodell-Objekt zu schicken.
Schritt 400 übergibt dem ersten Produktmodell-Objekt 16 in der laufenden Sitzung die vom Anwender eingegebene Modellnummer. Als nächstes wird in Schritt 402 die Version dieses Produktmodell-Objekts geprüft, was im Version-String 224 gespeichert ist, um zu bestimmen, ob es mit dieser Runtime-Version kompatibel ist. Wenn die beiden Versionen nicht-kompatibel sind, wird eine Fehlermeldung zurückgeschickt und das Produktmodell- Objekt 16 muß mit Hilfe einer geeigneten Version des Modellier-Tools 12 neu aufgebaut werden. Angenommen, das fragliche Produktmodell-Objekt und das Runtime-Tool sind kompatibel, dann werden durch Schritt 404 alle Modellnummernmanager- Objekte 30 innerhalb dieses Produktmodell-Objekts 16 geladen. Dann beginnt der Vorgang der horizontalen und vertikalen Überprüfung der Modellnummer, wie sie zuvor erläutert wurde, wobei mit dem ersten geladenen Modellnummernmanager-Objekt begonnen wird. Gemäß diesem Vorgang werden alle Zeichensegment-Objekte 54 in dem geladenen Modellnummernmanager-Objekt anfänglich deaktiviert. Danach werden sie nach ihrer Reihenfolge angeordnet, die durch die im Position-String 86 gespeicherte ganze Zahl festgelegt ist. Werden zwei oder mehr Zeichensegment- Objekte in der gleichen Position aufgefunden, werden sie so geordnet, daß jene Zeichensegment-Objekte mit Zeichenkontingent-Objekten 62 vor denen berücksichtigt werden, die keine Zeichenkontingent-Objekte haben. Die eingegebene Modellnummer wird dann analysiert und zergliedert, um jedes Zeichensegment- Objekt 54 gemäß seiner neu bestimmten Reihenfolge auszufüllen und gemäß der Länge jedes Zeichensegments, wie sie durch den Initialzeichen-String 84 bestimmt wird. An diesem Punkt muß ein Zeichensegment-Objekt 54 für jede Position oder jedes Zeichensegment 52 in der Modellnummer ausgewählt werden. Wenn multiple Zeichensegment-Objekte für eine einzige Position vorhanden sind, wird das erste Zeichensegment, dessen Zeichenkontingent mit WAHR bewertet ist, ausgewählt und anschließend aktiviert. Nach der Aktivierung eines spezifischen Zeichenkontingent-Objekts 62 beurteilt auch das korrespondierende Wertspezifikator-Objekt 60 das analysierte und zergliederte Zeichensegment 52 der eingegebenen Modellnummer (Schritt 408). Wenn diese Überprüfung nicht erfolgreich ist, womit gezeigt wird, daß die eingegebene Modellnummer eine ungültige Produktkonfiguration darstellt, geht die Sequenz weiter zu Schritt 420.
Schritt 420 prüft, ob das vorhergehende Modellnummernmanager- Objekt 30 das letzte des fraglichen Produkamodell-Objekts war. Sollten sich noch mehr Modellnummernmanager-Objekte in jenem Produktmodell befinden, werden sie initialisiert und die Überprüfung wird gemäß dem zuvor beschriebenen Prozeß wiederholt. Die Abfolge der Schritte 406, 408, 420 wird fortgesetzt, bis entweder ein Modellnummernmanager-Objekt gefunden wird, das die eingegebene Modellnummer bestätigt oder bis das betreffende Produktmodell keine weiteren Modellnummernmanager-Objekte mehr hat. Wenn das letztere der Fall ist, wird durch Schritt 422 das nächste Produktmodell-Objekt in die laufende Sitzung geladen und der Vorgang wird wiederholt. Dies setzt sich fort, bis ein Modellnummernmanager-Objekt aufgefunden wird, das die eingegebene Modellnummer bestätigt, wobei der Konfiguriereprodukt-Sequenz 302 an diesem Punkt zu Schritt 430 übergeht. Wenn kein Modellnummernmanager gefunden wird, um die eingegebene Modellnummer zu bestätigen, wird der Anwender mit einer entsprechenden Fehlermeldung benachrichtigt.
Jetzt, da die Modellnummer bestätigt worden ist, muß das Runtime-Tool 14 das/die korrespondierende(n) Profil-Objekt(e) auswählen. Der erste Schritt, Schritt 430, beinhaltet das Laden aller Profil-Objekte in die laufende Sitzung, die in der Profilliste 82 aufgeführt sind. Von diesen geladenen Profil- Objekten muß eines ausgewählt werden (Schritt 432). Wenn das fragliche Produktmodell-Objekt nur ein einziges Profil-Objekt 36 enthält, wird dieses Profil-Objekt ausgewählt. Wenn das Produktmodell-Objekt jedoch mehrere Profil-Objekte enthält und kein Zeichensegment-Objekt 54 spezifisch als ein "Profil- Segment" bezeichnet ist, wird das erste in der Profilliste 82 aufgeführte Profil-Objekt ausgewählt. Wenn es ein Zeichensegment-Objekt 54 gibt, welches spezifisch zur Identifizierung eines korrespondierenden Profil-Objekts vorgesehen ist, wird das Modellspezifikator-Objekt 64 dieses Segments verwendet, um zu bestimmen, welches Profil-Objekt auszuwählen ist. An diesem Punkt muß das ausgewählte Profil-Objekt mit den Informationen aus der eingegebenen Modellnummer initialisiert werden (Schritt 434). Es sei angemerkt, daß das Profil-Objekt zu diesem Zeitpunkt durch ein Teilegerüst dargestellt wird, aber es fehlen ihm spezifische Werte, wie z. B. Abmessungen, sowie möglicherweise vorgesehene optionale Bauteile, die noch hinzuzufügen sind. Die eingegebene Modellnummer wird in verschiedene Zeichensegmente 52 analysiert und zergliedert und jedes dieser Segmente wird in ein korrespondierendes Zeichensegment-Objekt 54 eingesetzt. Damit beginnt ein wichtiger Teil des Konfigurationsvorganges, bei dem das Modellspezifikator-Objekt 64 jedes Zeichensegment-Objekts verwendet wird, um die Zeicheninformationen in der Modellnummer mit der richtigen Stelle im Profil- Objekt zu verbinden. Es gibt verschiedene Kategorien von Modellspezifikator-Objekten 64. Beispielsweise lenkt ein Modellspezifikator-Objekt der Teileeigenschaftspezifikator- Kategorie die Zeichen eines korrespondierenden Zeichensegments zu einem Teileeigenschaft-Objekt 100 im ausgewählten Profil- Objekt. Ein Modellspezifikator-Objekt der Teilespezifikator- Kategorie fügt dem Profil-Objekt ein neues Teile-Objekt aus der List der verfügbaren Teiletyp-Objekte hinzu. Alternativ fügt ein Modellspezifikator-Objekt der Virtuelleteilespezifikator-Kategorie ein neues Virtuelleteile-Objekt aus den verfügbaren Virtuelleteile-Objekten 182, die sich im gesamten Profil-Objekt 36 befinden, zu dem Virtuelleteileliste-Objekt 220 hinzu, das sich im Endbaugruppeteile-Objekt 180 befindet. Sobald alle Zeichensegmente 52 der eingegebenen Modellnummer mit bestimmten Objekten innerhalb des Profil-Objekts verknüpft sind, befindet sich das Modell nun in einem "kritischen Zustand". An diesem Punkt müssen die Informationen aus der Modellnummer innerhalb des Profil-Objekts verbreitet werden.
Schritt 436 besteht im Einstellen von spezifischen Werten für die Teileeigenschaft-Objekte 100, wodurch eine Kettenreaktion ausgelöst wird, durch die Werte von anderen Teileeigenschaft- Objekten über die hierarchische Struktur eingesetzt werden. Beginnend mit den so genannten "primären" Teileeigenschaft- Objekten oder Teileeigenschaft-Objekten an der Spitze der hierarchischen Struktur werden zuerst Werte eingesetzt, die mit den eingegebenen Zeichensegmenten korrespondieren, und jene Werte werden dann mittels der Eingabespezifikator-Objekte 110 über das gesamte Endbaugruppe-Objekt verbreitet. Folglich kommt es zu einem Selbstkonfigurationsprozess, bei dem alle "aktiven" Teileeigenschaft-Objekte 100 innerhalb des Endbaugruppe-Objekts, wie zuvor erörtert, mit spezifischen Werten besetzt werden. Wenn dieser Vorgang abgeschlossen ist, sollten die Konfigurationsmanager-Objekte ausgeführt werden.
Die Konfigurationsmanager-Objekte 200 werden verwendet, um alle Teileeigenschaft-Objekte zu berücksichtigen, deren Wert nicht direkt aus der eingegebenen Modellnummer bestimmt werden kann, wie zuvor beschrieben. Somit führt jedes Teile-Objekt 184, das ein "passives" Teileeigenschaft-Objekt enthält, d. h. ein Objekt, dessen Wert nicht direkt für das automatische, kettenreaktionsartige Einsetzen von Werten verbunden ist, ein entsprechendes Konfigurationsmanager-Objekt 200 aus. Jenes Objekt sorgt für ansonsten undefinierte Werte und kann auch Teile-Objekte hinzufügen oder entfernen, die während der Aufbauphase unbestimmbar waren. Wenn darüber hinaus noch zusätzliche Informationen erforderlich sind, um das Produkt richtig zu konfigurieren, ein Zustand, der als Mangel bekannt ist, wird eine Fehlermeldung und möglicherweise eine Anwender- Schnittstelle an den Anwender geschickt, die anzeigt, welche Informationen gebraucht werden. Die Anwender-Schnittstelle kann die Form einer Eingabe-Box, einer Listenauswahl-Box oder eine andere geeignete Form haben. Nach dem Ausführen der Konfigurationsmanager-Objekte der Teile-Objekte, führt das Runtime-Tool jene Konfigurationsmanager-Objekte aus, die sich in den Virtuelleteile-Objekten befinden, die dem Endbaugruppeteile-Objekt 180 während des Konfigurationsvorgangs zugefügt worden waren. Dieser Vorgang ist weitgehend der gleiche, wie der soeben beschriebene, so daß auf eine vollständige Beschreibung verzichtet wird. Es sei noch einmal wiederholt, daß jedes beliebige nicht-initialisierte Konfigurationsmanager- Objekt so ausgeführt werden kann, daß es in der Lage ist, das Teilegerüst in Übereinstimmung mit der ausgewählten Option oder anderen Modifikationen zu verändern, die durch das korrespondierende Virtuelleteile-Objekt dargestellt werden. Sobald dieser Schritt abgeschlossen ist, befindet sich das Modell in einem sogenannten "eingerichteten Zustand", d. h. es repräsentiert ein spezifisches Produkt in großer Detailgenauigkeit und ist bereit zur Abfrage, so daß es die gewünschten Ausgabeinformationen liefern kann.
In Fig. 13 ist die Datenerhebungsausgabe-Sequenz 304 dargestellt, die, allgemein gesprochen, bestimmt, welche Informationen aus dem konfigurierten Produkt entnommen und dem Anwender der externen Anwendung 18 verfügbar gemacht werden. Als erstes wird dem Anwender eine Liste vorgelegt, die alle zur Auswahl stehenden Ausgabeinformationen enthält (Schritt 500). Diese Liste kann eine Zusammenstellung der verschiedenen Namen-Strings 250 sein, die innerhalb jedes Beschreibungsmanager-Objekts 38 enthalten sind. Sobald die gewünschten Ausgabeinformationen ausgewählt wurden, werden durch den Schritt 502 diese Informationen aus dem korrespondierenden Beschreibungsmanager-Objekt 38 herausgezogen, wie zuvor im Zusammenhang mit Fig. 8 beschrieben wurde. An diesem Punkt hält das Runtime- Tool nun die gewünschten Ausgabeinformationen und in Schritt 504 werden diese Informationen dem Anwender auf einem der zahlreichen in der Technik bekannten Arten angezeigt. Diese Informationen können z. B. in der Form eines Ausgabeberichts auf dem Computermonitor des Anwenders erscheinen, an einen Drucker geschickt oder auf einem elektronischen Datenträger gespeichert werden, etc.. Darüber hinaus kann die Art der Informationen von einer Preisliste über eine Stückliste bis zu einer Beschreibung der Abmessungen des Produktes reichen. Was auch immer es ist, der Anwender hat jetzt ein Produkt konfiguriert und diese Konfiguration verwendet, um selektiv spezifische Informationen zu erlangen. Schritt 506 gibt dem Anwender Gelegenheit, die Selektion fortzusetzen und Ausgabeinformationen zu dem konfigurierten Produkt zu erhalten, bis er aufhören möchte; an diesem Punkt endet der Konfigurationsvorgang.
Nach der Datenerhebungsausgabe-Sequenz 304 sollte der Anwender die Möglichkeit haben, entweder die Sitzung, die gerade beendet wurde, oder alle noch offenen Sitzungen zu schließen. Wenn die Sitzung geschlossen ist, wird sie abgeschaltet und aus dem Speicher entfernt. Es sollte auch eine Funktion vorgesehen sein, um eine Produktkonfiguration zu löschen, wodurch eine spezielle Produktkonfiguration einfach aus der Sitzung entfernt würde, ohne die Sitzung selbst zu schließen. Bei Absturz des Programms (oder wenn Dateifehler vom Produktmodell-Objekt gemeldet werden), wird vorgeschlagen, daß eine Funktion "Schließe Produktmodell" vorgesehen sein sollte, um sicherzustellen, daß das Betriebssystem von der beabsichtigten Anweisung, "reinen Tisch" zu machen, "weiß".
Es wird deutlich, daß gemäß der vorliegenden Erfindung ein objektorientiertes Produktkonfigurationssystem und -verfahren bereitgestellt wird, das die hier beschriebenen Ziele und Vorteile verwirklicht. Es versteht sich von selbst, daß die vorstehende Beschreibung die einer bevorzugten beispielhaften Ausführung der Erfindung ist und daß die Erfindung nicht auf die dargestellte spezifische Ausführungsform beschränkt ist. Beispielsweise könnte der Aufbau des Modellier-Tools 12, des Runtime-Tools 14, des Produktmodell-Objekts 16 und all ihrer zahlreichen Unterkomponenten von der in den Figuren dargestellten und in der Beschreibung erläuterten abweichen. Objekte, Daten, Funktionen, Logikbausteine, etc. könnten hinzugefügt, weggelassen oder sonstwie gegenüber den spezifisch dargestellten verändert werden. Darüber hinaus gibt es zahlreiche Fälle, wo Informationen in der Form eines bestimmten Wertes, einer bestimmten Zeichenkette oder Flags gespeichert sein sollen. Diese Werte können ebenso gut in Form von zusätzlichen Objekten oder sonstigen anderen, in der Technik bekannten Datentypen gespeichert werden. Ferner könnten die speziellen Sequenzen, Schritte, etc. und die entsprechende Reihenfolge bei ihrer Ausführung von dem zuvor erörterter abweichen, da die hier gezeigten Ausführungen lediglich als Beispiel gedacht waren. Der Schutzumfang der vorliegenden Erfindung soll auch verschiedene Änderungen und Modifikationen einschließen.

Claims

1. Verfahren zum Konfigurieren eines Produktes, wobei das Verfahren die folgenden Schritte umfaßt:

a) Bereitstellen eines ersten Software-Tools, das ein elektronisches objekt-orientiertes Produktmodell erzeugen kann, welches stellvertretend für eine Produktlinie steht, wobei

a) das genannte Produktmodell ein elektronisches Profilmodell umfaßt, das stellvertretend für ein Produkt innerhalb der Produktlinie steht;

b) das genannte Profilmodell ein elektronisches Teilemodell umfaßt, das stellvertretend für ein Einzelteil innerhalb des Produkts steht;

c) das genannte Teilemodell ein elektronisches Teileeigenschaftsmodell umfaßt, das stellvertretend für eine Eigenschaft des Einzelteils steht; sowie

b) Bereitstellen eines zweiten Software-Tools, das die gespeicherten Informationen in dem genannten Produktmodell für eine oder mehrere Software-Anwendungen verfügbar machen kann.

2. Verfahren nach Anspruch 1, wobei das genannte Produktmodell einen elektronischen Modellnummernmanager umfaßt, der ein sinnvolles Modellnummernsystem definieren kann, so daß eine sinnvolle Modellnummer verwendet werden kann.

3. Verfahren nach Anspruch 2, wobei der genannte Modellnummernmanager ein elektronisches Zeichensegment umfaßt, das zu einem Abschnitt der sinnvollen Modellnummer gehört und Informationen mit dem genannten Teileigenschaftsmodell austauschen kann.

4. Verfahren nach Anspruch 3, wobei ein erstes Zeichensegment den Abschnitt der sinnvollen Modellnummer prüfen kann, indem Daten mit einem zweiten Zeichensegment ausgetauscht werden, wobei dieser Vorgang als horizontale Überprüfung bezeichnet wird.

5. Verfahren nach Anspruch 4, wobei das genannte erste Zeichensegment auch den Abschnitt der sinnvollen Modellnummer prüfen kann, ohne Daten mit einem anderen Segment auszutauschen, wobei ein solcher Vorgang als vertikale Überprüfung bezeichnet wird.

6. Verfahren nach Anspruch 3, wobei der Abschnitt der sinnvollen Modellnummer ein oder mehrere individuelle Modellnummernzeichen enthalten kann.

7. Verfahren nach Anspruch 1, wobei das genannte Produktmodell eine Sammlung aus einem oder mehreren elektronischen Teiletypenmodellen umfaßt, wobei jedes davon stellvertretend für eine Teileschablone steht und zur Aufnahme in das genannte Profilmodell selektierbar ist.

8. Verfahren nach Anspruch 7, wobei das genannte Teiletypenmodell zu dem genannten Teilemodell wird, wenn es für das Profilmodell ausgewählt und in diesem aufgenommen ist.

9. Verfahren nach Anspruch 1, wobei das genannte Produktmodell eine Sammlung einer oder mehrerer elektronischer virtueller Teiletypenmodelle umfaßt, wobei jedes davon stellvertretend für eine verfügbare Modifikation steht und zur Aufnahme in das genannte Profilmodell selektierbar ist.

10. Verfahren nach Anspruch 9, wobei das genannte virtuelle Teiletypenmodell zu einem virtuellen Teilemodell wird, wenn es ausgewählt und in dem genannten Profilmodell aufgenommen ist.

11. Verfahren nach Anspruch 9, wobei das genannte virtuelle Teiletypenmodell stellvertretend für ein verfügbares Optionspaket steht.

12. Verfahren nach Anspruch 10, wobei das genannte Profilmodell einen elektronischen Konfigurationsmanager umfaßt, der Modifikationen, die durch das genannte virtuelle Teilemodell eingebracht werden und anderenfalls nicht berücksichtigt würden, im genannten Profilmodell implementieren kann.

13. Verfahren nach Anspruch 1, wobei ein erstes Teileeigenschaftsmodell elektronisch mit einem zweiten Teileeigenschaftsmodell so verbunden ist, daß Informationen zwischen ihnen ausgetauscht werden können.

14. Verfahren nach Anspruch 13, wobei der Informationsaustausch während der Benutzung des genannten zweiten Software-Tools erfolgt, so daß die Informationen automatisch über das genannte Profilmodell verteilt werden.

15. Verfahren nach Anspruch 14, wobei das genannte Teileeigenschaftsmodell einen elektronischen Filter umfaßt, der einen Datentyp in einen anderen umwandeln kann, so daß der genannte Filter die automatische Verteilung von Informationen unterstützt.

16. Verfahren nach Anspruch 1, wobei das genannte Teilemodell einen elektronischen Teilenummernmanager umfaßt, der eine sinnvolle Teilenummer bereitstellen kann.

17. Verfahren nach Anspruch 1, wobei das genannte Produktmodell einen elektronischen Beschreibungsmanager umfaßt, der steuern kann, welche Informationen während der Benutzung des genannten zweiten Software-Tools für eine Softwareanwendung verfügbar gemacht werden.

18. Verfahren nach Anspruch 17, wobei der genannte Beschreibungsmanager einen elektronischen Teile-Descriptor umfaßt, der elektronisch mit dem genannten Teileeigenschaftsmodell so verbunden ist, daß zwischen ihnen Informationen ausgetauscht werden können.

19. Verfahren nach Anspruch 17, wobei der genannte Beschreibungsmanager einen elektronischen Stapel-Teile-Descriptor umfaßt, der Kriterien akzeptieren kann und der Informationen ausschließlich von den Teileeigenschaftsmodellen für eine oder mehrere Software- Anwendungen verfügbar macht, die die genannten Kriterien erfüllen.

20. Verfahren nach Anspruch 1, wobei bei dem genannten elektronischen objekt-orientierten Produktmodell sowohl die Logik als auch die Daten in einem einzigen Objekt gespeichert sind.

21. Verfahren nach Anspruch 1, wobei das genannte erste und zweite Software-Tool Bestandteil eines selbständigen Produktkonfigurationssystem sind.

22. Verfahren nach Anspruch 1, wobei das genannte zweite Software-Tool die gleichen Informationen für eine erste Software-Anwendung und eine zweite Software-Anwendung verfügbar machen kann, wobei die erste und die zweite Software-Anwendung unterschiedlichen Typs sind.

23. Verfahren nach Anspruch 1, wobei während einer Software-Anwendung eine Modellnummer in das zweite Software-Tool eingegeben werden kann, wobei das genannte Software-Tool die eingegebene Modellnummer dem genannten Produktmodell übermitteln kann und das genannte Produktmodell bestimmen kann, ob die eingegebene Modellnummer gemäß dem sinnvollen Modellnummernschema gültig ist.

24. Verfahren nach Anspruch 23, wobei, wenn die eingegebene Modellnummer gültig ist, das genannte Produktmodell dem zweiten Software-Tool eine Datenausgabe übermitteln und das zweite Software-Tool die Datenausgabe an die Software-Anwendung weiterleiten kann.

25. Computerlesbarer Datenträger mit darauf gespeicherten, von einem Computer ausführbaren Instruktionen zur Durchführung des Verfahrens nach Anspruch 1.

26. Computerlesbarer Datenträger mit einer darauf gespeicherten objekt-orientierten Datenstruktur, umfassend:
ein für eine Produktlinie stellvertretendes Produktmodell;
ein innerhalb des genannten Produktmodells befindliches Profilmodell, das stellvertretend für ein Produkt innerhalb der Produktlinie steht;
ein innerhalb des genannten Profilmodells befindliches Teilemodell, das stellvertretend für ein Einzelteil des Produkts steht;
ein innerhalb des Teilemodells befindliches Teileeigenschaftsmodell, das stellvertretend für ein Attribut des Einzelteils steht, wobei die genannte Datenstruktur in der Lage ist, automatisch Informationen, die in einem ersten Teileeigenschaftsmodell gespeichert sind, zu einem zweiten Teileeigenschaftsmodell zu verteilen, das sich an einer anderen Stelle in dem genannten Profilmodell befindet.

27. Computerlesbarer Datenträger nach Anspruch 26, wobei die genannte objekt-orientierte Datenstruktur für ein Software-Tool zugänglich ist, so daß die in dem genannten Produktmodell gespeicherten Informationen für eine oder mehrere Software-Anwendungen verfügbar gemacht werden.