DE69434975T2

DE69434975T2 - Verfahren und vorrichtung zum konfigurieren von systemen

Info

Publication number: DE69434975T2
Application number: DE69434975T
Authority: DE
Inventors: John Austin LYNCH; David Austin FRANKE
Original assignee: Versata Development Group Inc; Trilogy Development Group Inc
Current assignee: Versata Development Group Inc
Priority date: 1993-03-29
Filing date: 1994-03-21
Publication date: 2008-01-24
Anticipated expiration: 2014-03-22
Also published as: BR9406179A; WO1994023372A1; ATE363100T1; CA2158153A1; AU685451B2; DE69434975D1; KR100291012B1; JPH08509309A; AU6494794A; CA2158153C; US5708798A; KR960701406A; EP0719432A1; US5515524A; EP0719432B1; EP0719432A4

Description

1. SACHGEBIET DER ERFINDUNG
Die Erfindung betrifft das Gebiet der computerbasierten Systemkonfiguration.
2. STAND DER TECHNIK
Das Konfigurieren eines Systems bezieht sich auf den Vorgang der Auswahl und Verbindung von Komponenten zur Erfüllung einer bestimmten Notwendigkeit oder Anforderung. Wenn ein System auf einer begrenzten Anzahl von Komponenten beruht, kann der Prozess der Systemkonfiguration relativ unkompliziert sein. Zum Beispiel erfordert der Kauf eines Autos, dass ein Händler ein System (Auto und verschiedene Optionen) konfiguriert, um eine Kundenanforderung zu erfüllen. Nach der Auswahl aus einer Mehrzahl von Modellen schließt der Händler die Transaktion durch die Wahl von Optionen zur Konfiguration und zur Preisbestimmung eines Autos ab. Die Konfiguration eines solch einfachen Systems kann mit Papier und Bleistift erfolgen.
Wenn die Spezifikationen jedoch kundenspezifischer und verschiedenartiger werden, erhöht sich die Anzahl der Konfigurationsalternativen, und die Aufgabe der Konfiguration eines Systems wird immer komplizierter. Diese erhöhte Kompliziertheit hat zu einem Bedarf an computergestützter Hilfe beim Konfigurationsprozess geführt. Frühe computergestützte Systeme erweitern unabhängig generierte Konfigurationsaufträge für Systeme in Produktionsaufträge. Sie erfüllen nicht den eigentlichen Bedarf an computergestützten Werkzeugen vor der Auftragserweiterung. Das heißt, sie lassen die eigentliche Erzeugung einer Systemkonfiguration auf der Grundlage der Eingabe von Notwendigkeiten und/oder Anforderungen außer Acht.
Ein Beispiel für ein komplexes System ist ein Desktop-Computersystem. Die verfügbaren Konfigurationsalternativen eines Computersystems sind zahlreich und vielfältig, darunter Alternativen, die bei der Wahl des Mikroprozessors, Motherboards, Monitors, der Grafikkarte, Speicherchips, Stromversorgung, Speichergeräte, Speichergerätsteuerungen, Modems und Software verfügbar werden.
Das Konfigurieren eines Desktop-Computersystems erfordert, dass eine gewählte Komponente mit den anderen Komponenten im konfigurierten System kompatibel ist. Zum Beispiel muss die Stromversorgung ausreichend sein, um Strom an alle Systemkomponenten zu liefern. Weiterhin müssen Monitor und Grafikkarte (z. B. Auflösung) und das Speichergerät mit seiner Steuerung (z. B. SCSI-Schnittstelle) kompatibel sein. Ein Motherboard muss über genügend Einbauplätze verfügen, um alle in das System installierten Platinen aufzunehmen.
Die physischen Beschränkungen des Gehäuses, in dem die Systemkomponenten untergebracht sind, werden ebenfalls berücksichtigt. Das Gehäuse hat eine feste Anzahl an Einbaurahmen für Speichergeräte (z. B. Diskettenlaufwerke, Festplattenlaufwerke oder Bandlaufwerke). Diese Einbaurahmen haben weitere Eigenschaften, die ihre Verwendung bestimmen. Zum Beispiel kann sich ein Einbaurahmen vorne im Gehäuse befinden und von der Frontplatte des Gehäuses zugänglich sein. Ein anderer Einbaurahmen kann hinter den von vorne zugänglichen Einbaurahmen angeordnet und so auf Geräte beschränkt sein, die nicht zugänglich zu sein brauchen (z. B. ein Festplattenlaufwerk). Einbaurahmen können in voller oder nur in halber Höhe vorliegen. Bevor ein Speichergerät in die Konfiguration aufgenommen werden kann, muss ein Konfigurationssystem den Rahmen erkennen, in dem das Speichergerät untergebracht wird. Dies erfordert, dass zumindest die Zugänglichkeit und Höhe des Speichergeräts untersucht werden müssen, um dessen Kompatibilität mit einem verfügbaren Einbaurahmen im Gehäuse zu bestimmen.
Die Verbindung zwischen einem Speichergerät und seiner Steuerung muss auf der Grundlage von deren Ort bestimmt werden. Das Kabel, das das Speichergerät und seine Steuerung verbindet, muss kompatible physische Schnittstellen (z. B. 24-Pin-Stecker und 24-Pin-Buchse) aufweisen.
Ein Verfahren zur Einrichtung einer Kommunikationsstrecke in einem Computersystem wird als Prioritätsverkettung bezeichnet. Die Prioritätskette bietet die Möglichkeit, Komponenten so miteinander zu verbinden, dass ein Signal durch eine Komponente hindurch und dann zur nächsten geht. Die Bestimmung, ob eine Prioritätsverkettung eingerichtet werden kann, erfordert, dass die verfügbaren logischen (d. h. IDE oder SCSI) und physischen Schnittstellen (z. B. 24-Pin) aller Elemente in einer Prioritätsverkettung bekannt sind. Weiterhin ist es wichtig zu wissen, ob Konvertierungen vom Quelldatentyp zum Zieldatentyp zulässig sind. Wenn ein Kandidat für die Prioritätsverkettung zum System hinzukommt, können die vorhandenen Verbindungen zwischen vorhandenen Elementen geprüft werden, um festzustellen, ob die neue Komponente ein Element der Prioritätsverkettung sein sollte.
Die Beispiele Stromversorgung und Speichergerätkomponente veranschaulichen die Notwendigkeit, die strukturellen Wechselbeziehungen zwischen den Komponenten (d. h. physische und räumliche Beziehungen) zu definieren. Um diese Vorstellung noch etwas mehr zu veranschaulichen, stelle man sich vor, die Komponenten, die elektrischen Strom benötigen, wie Computer-, Telekommunikations-, medizinische oder unterhaltungselektronische Komponenten, seien auf zwei Schränke verteilt. Des Weiteren verfügt jeder Schrank über eine zugehörige Stromversorgung, die die im Schrank befindlichen Komponenten mit elektrischem Strom speist. Um dem Stromverbrauch gerecht zu werden und die Forderung zu erfüllen, dass keine Stromversorgung überlastet werden darf, muss das Modell verstehen, in welchen bestimmten Schrank die einzelnen Komponenten eingebaut werden und den Stromverbrauch pro Schrank aktualisieren. Während die in den beiden Schränken verfügbare Gesamtstromleistung für alle in die beiden Schränke einzubauenden Komponenten ausreichen kann, darf eine Komponente nicht in einen Schrank eingebaut werden, wenn dies zu einer Überlastung der Schrankstromversorgung führen würde. Daher muss die physische Anordnung der Komponente im Schrank bekannt sein, um bestimmen zu können, ob der spätere Einbau einer Komponente zulässig ist. In gleicher Weise müssen die physischen Verbindungen zwischen diesen Komponenten berücksichtigt werden. Die Position der einzelnen Komponenten in der strukturellen Hierarchie wird zur Bestimmung der Mindest- oder Optimallänge der Verbindungskomponenten herangezogen.
Frühe computergestützte Konfigurationssysteme gingen von einem als regelbasiert bezeichneten Ansatz aus. Regelbasierte Konfigurationssysteme definieren Regeln (z. B. „wenn A, dann B"), um eine Auswahl von Konfigurationsalternativen auf Gültigkeit zu prüfen. Das System der Digital Equipment Corporation mit der Bezeichnung R1/XCON (beschrieben in McDermott, John, „R1: A Rule-Based Configurer of Computer Systems", Artificial Intelligence 19, (1982), S. 39-88) ist ein Beispiel für ein regelbasiertes Konfigurationssystem. R1/XCON bewertet einen vorhandenen unabhängig generierten Systemauftrag und identifiziert erforderliche Modifizierungen des Systems zur Erfüllung der Konfigurationsregeln des Modells. Die zur Ausführung der Konfiguration und Validierung genutzten Regeln sind zahlreich, miteinander verwoben und voneinander abhängig. Bevor eine Änderung dieser Regeln möglich ist, muss dass Gewebe, das diese Regeln schaffen, erfasst werden. Sämtliche Änderungen dieser Regeln müssen von einer Person vorgenommen werden, die in Bezug auf die Wirkung, die eine Änderung auf das gesamte Regelwerk haben wird, erfahren und kenntnisreich sein muss. Es ist daher schwierig und zeitraubend, diese Regeln zu unterhalten.
Eine mögliche Lösung der mit regelbasierten Systemen verbundenen Probleme ist ein restriktionsbasiertes System. Ein restriktionsbasiertes System unterwirft die Verwendung einer Komponente in der Konfiguration Restriktionen bzw. Randbedingungen. Zum Beispiel darf ein Festplattenlaufwerk erst zu einer Konfiguration hinzugefügt werden, wenn eine kompatible Speichergerätsteuerung zur Verwendung durch das Anforderungsspeichergerät verfügbar ist. Das Erfordernis einer Steuerung ist eine „Randbedingung" für das Festplattenlaufwerk.
Während vorhandene restriktionsbasierte Systeme einige der Mängel von regelbasierten Systemen aufgreifen, stellen sie jedoch kein komplettes Konfigurations-Tool dar. Reine restriktionslösende Systeme gehen nicht generativ an die Konfiguration heran (d. h., sie erzeugen keine auf Bedürfnissen, Komponentenanforderungen und/oder Ressourcenanforderungen beruhende Systemkonfiguration). Vorhandene restriktionsbasierte Systeme verwenden eine Funktionshierarchie, die mit der Anordnung einer Komponente in einer Konfiguration (z. B. Memory-Chip auf dem Motherboard oder der Speichererweiterungsplatine, Speichergerät im Schrankeinbaurahmen oder Steuerung im Motherboard-Einbauplatz) verbundene strukturelle Aspekte nicht anspricht.
Bennett et al., US-Patent 4,591,983 , liefert ein Beispiel für ein restriktionsbasiertes System, das einen Erkennungs- oder Verifizierungsansatz statt eines generativen Herangehens an die Systemkonfiguration anwendet. Das heißt, Bennett validiert lediglich ein unabhängig konfiguriertes System. Im Wesentlichen wird eine Bestellung von einer unabhängigen Quelle wie einem Händler erzeugt und Bennett wird dazu verwendet, zu prüfen, ob das in der Bestellung enthaltene System Randbedingungen verletzt. Bennett erzeugt keine auf Bedürfnissen oder Komponentenanforderungen beruhende Systemkonfiguration (d. h. ein generativer Ansatz). Somit bietet Bennett nicht die Fähigkeit zur interaktiven Konfiguration eines Systems durch interaktive Auswahl seiner Komponenten.
Ein Modell besteht aus allen Elementen, die in ein konfiguriertes System einbezogen werden können. Bei Bennett werden die Modellelemente in einer Aggregationshierarchie gruppiert. Eine Aggregationshierarchie schafft Hierarchieebenen, die eine Gruppe von Elementen darstellen. Verzweigungen von einem Eintrag in einer aktuellen Ebene erweitern den Eintrag, so dass der Eintrag „aus den Elementen der Zweige auf den unteren Ebenen zusammengesetzt ist. Ein Desktop-Computer zum Beispiel „besteht aus" einer Tastatur, einem Monitor und einer Systembox. Eine Systembox „besteht aus" Stromversorgung, Motherboard, Baugruppen und Speichergeräten. Die „Besteht aus"-Beziehung beschreibt lediglich die Elemente, die ein anderes Element ausmachen. Die „Besteht aus"-Beziehung definiert jedoch keine strukturellen Beziehungen zwischen den Modellelementen. Die „Besteht aus"-Beziehung beschreibt keine physischen, strukturellen Beziehungen zwischen den Elementen wie „physisch enthalten", „physisch untergeordnetes Teil von" und „physisch verbunden mit". Mit dem beschriebenen Desktop-Computersystem kann also nicht bestimmt werden, ob der Monitor im Desktop-Computersystem „physisch enthalten" ist. Eine Systembox „besteht aus" Speichergeräten, doch kann nicht bestimmt werden, ob eines oder mehrere der Speichergeräte in der Systembox „physisch enthalten" ist/sind.
Eine Funktionshierarchie organisiert die Komponenten eines Modells auf der Grundlage des von den Komponenten im Modell erfüllten Zweckes bzw. ihrer Funktion. Jeder Eintrag in der Hierarchie kann weiter in speziellere Funktionseinträge aufgegliedert werden. Somit definiert die Abstammung eines Eintrags seine Funktionalität, und das Fortschreiten von einer Ebene zur nächsten partikularisiert die Funktionalität eines Hierarchieeintrags.
So wie sie in aktuellen Konfigurationssystemen verwendet wird, definiert eine Funktionshierarchie keine strukturellen Wechselbeziehungen oder die physischen und räumlichen Verbindungen zwischen den Elementen. Eine Funktionshierarchie kann kein Speichergerät in einem Schrankeinbaurahmen, eine Steuerungsbaugruppe in einem bestimmten Einbauplatz oder einen Speicher-Chip auf der Speichererweiterungsplatine anordnen.
2 stellt ein Beispiel für eine Funktionshierarchie dar. Hardwarekomponente 30 ist das Basiselement der Hierarchie. Die nächste Ebene unter Hardwarekomponente 30 (d. h. der zweiten Ebene 49) gibt allgemeine Funktionen im Modell an. Zum Beispiel führen ROM 31, Prozessoreinheit 31, Prozessor 32, Speicher 34, Käfig 35, Platine 36, Verbinder 37 und Speichergerät 38 alle die Funktion der Hardwarekomponente 30 zusätzlich zu deren speziellen Funktionen aus. Der Prozessor 33 kann auf die Funktion Sonderzweck 40 oder Universalzweck 41 spezialisiert werden. Sonderzweck 40 kann zum Arithmetik-Prozessor 51 spezialisiert werden.
Aus 2 ist ersichtlich, dass eine Funktionshierarchie nicht die Fähigkeit bietet, die strukturellen Aspekte des Systems zu definieren. Zum Beispiel ist sie nicht in der Lage, den Inhalt des Käfigs 35 zu ermitteln. Der physische und räumliche Ort des Motherboard-Platzes 54, der vom Einbauplatz 46 abstammt, wobei dieser wiederum vom Verbinder 37 abstammt, kann aus der Funktionshierarchie nicht bestimmt werden. Es besteht keine Möglichkeit zu ermitteln, dass der Motherboard-Platz 54 im Motherboard enthalten ist. Aus der Funktionshierarchiedefinition geht nicht klar hervor, ob sich der Arithmetik-Prozessor 51 auf dem Motherboard 44 oder einem anderen Modellelement befindet. Es lässt sich nicht ermitteln, ob sich Speicher-Chip 42 und ROM 31 auf dem Motherboard 44, der Speicherplatine 52 oder einem anderen Modellelement befinden.
Eine Funktionshierarchie verleiht nicht die Fähigkeit, tatsächliche Verbindungen zwischen konfigurierten Instanzen oder der Datenübertragung zu definieren. Das heißt, dass eine Komponente mit einer anderen verbunden ist, die kompatible logische Datentypen (z. B. serielle Schnittstelle) und kompatible physische Verbindungselemente (z. B. 24-Pin) aufweist. Eine Funktionshierarchie definiert lediglich die Funktion, die eine Komponente ausführt.
Da sie keine tatsächlichen Verbindungen zwischen den für die Konfiguration ausgewählten Komponenten definiert, kann sie auch keine Prioritätskette zwischen den konfigurierten Komponenten einrichten. In 2 definiert eine Funktionshierarchie den Verbinder 37, die Speichergerätsteuerung 53, das Diskettenlaufwerk 48 und Festplattenlaufwerk 49 als Komponententypen. Zum sparsamen Umgang mit Ressourcen kann der Benutzer ein System konfigurieren wollen, in dem ein Ereignis am Diskettenlaufwerk 48 über eine Prioritätskette mit einem Ereignis der Speichergerätsteuerung 53 über das Festplattenlaufwerk 49 verknüpft ist. Doch kann die Funktionshierarchie lediglich die Tatsache widerspiegeln, dass ein konfiguriertes System den von Speichergerätsteuerung 53, Festplattenlaufwerk 49, und Diskettenlaufwerk 48 gebotenen Funktionsumfang enthält. Sie kann nicht abbilden, dass ein Ereignis des Diskettenlaufwerks 48 über ein Ereignis des Festplattenlaufwerks 49 mit einem Ereignis der Speichergerätsteuerung 53 verbunden ist.
Aus diesem Grund kann eine Funktionshierarchie keinen Verbindungspfad durchlaufen, um strukturelle Wechselbeziehungen zwischen konfigurierten Instanzen zu erkennen. Daher kann eine Funktionshierarchie keine Prioritätskette aufstellen. Eine Funktionshierarchie kann also keine Prioritätskette zwischen Komponenten herstellen.
Ein weiteres Beispiel für ein restriktionsbasiertes System mit einer Funktionshierarchie ist in den folgenden Artikeln beschrieben: Mittal und Frayman, „Towards a Generic Model of the Configuration Task", in Proceedings of the Ninth IJCAI (IJCAI89), S. 1395-1401; und Frayman und Mittal, „COSSACK: A Constraints-Based Expert System for Configuration Tasks", in Sriram und Adey, Knowledqe-Based Expert Systems in Engineering: Planning and Design, September 1987, S. 143-66.
Das Cossack-System verwendet ein auf einer Funktionshierarchie beruhendes Konfigurationssystem. Nach Cossack muss ein System, das eine Funktionshierarchie nutzt, die erforderlichen Funktionen eines konfigurierten Systems erkennen. Wenn die erforderlichen Funktionen erkannt sind, muss Cossack eine oder mehrere bestimmte Komponente(n) identifizieren, die Schlüssel- oder Hauptkomponenten für die Implementierung dieser erforderlichen Funktionen sind. Die Cossack-Darstellung macht die Struktur nicht deutlich. Außerdem bietet Cossack keine Mechanismen für Schlussfolgerungen über oder mit Strukturinformationen an. Somit kann Cossack keine strukturbasierten Schlüsse ziehen. Zum Beispiel sind die internen Datenübertragungspfade innerhalb von Komponenten nicht dargestellt. Es besteht daher keine Möglichkeit, die Datenübertragung innerhalb einer Komponente zu verfolgen und keine Möglichkeit, eine Datenverbindung mit einem anderen Element einzurichten.
Ein Konfigurationssystem, ob zum Konfigurieren eines Computersystems oder eines anderen Systems genutzt, sollte ein Tool für die folgenden interaktiven Aktionen bereitstellen: Definition und Unterhaltung eines Modells; Definition und Unterhaltung (d. h. Upgrade) eines konfigurierten Systems; Erzeugung von Marketingpaketen; Erzeugung einer grafischen Darstellung der physischen und räumlichen Positionen der Komponenten des konfigurierten Systems; Verwendung der grafischen Darstellung zur Modifikation oder zum Upgrade eines konfigurierten Systems; und Erzeugung von Konfigurationsberichten (z. B. erfolglose Anforderungen, Angebote und Materiallisten). Ein solches System muss die Systemkomponenten, die strukturellen Beziehungen zwischen den Komponenten (d. h. räumliche und physische Positionen), die eigentlichen physischen und räumlichen Verbindungen der Komponenten und die von den einzelnen Komponenten auferlegten Randbedingungen definieren.
Die Patentschrift WO 93/01577 offenbart ein computerbasiertes Design-Tool zur Auswahl und Organisation miteinander verbindbarer Komponenten wie Möbelkomponenten und ein damit verbundenes Verfahren. Das darin beschriebene System verwendet einen regelbasierten Ansatz und weist als wesentliche Komponenten eine Wissensbasis zur Speicherung von Informationen über die verfügbaren Komponenten, eine Regelbasis mit Regeln zur Verbindung von Komponenten und eine Inferenz-Engine zur Auswahl und Anwendung der Regeln auf. Um eine Montageeinheit zu konstruieren, wählt der Benutzer nacheinander Komponenten aus und fügt sie zum System hinzu.
DARSTELLUNG DER ERFINDUNG
Die vorliegende Erfindung verwendet einen generativen Ansatz zum Konfigurieren von Systemen, so dass das System auf der Grundlage von Komponenten, Ressourcenanforderungen oder Eingaben in Form von Bedürfnissen konfiguriert werden kann. Die vorliegende Erfindung stellt ein restriktionsbasiertes Konfigurationssystem mit einer Funktionshierarchie, die hierarchische und nichthierarchische Struktur versteht, sowie damit verbundene Randbedingungen, die Schlussfolgerungen über strukturelle Beziehungen und deren Generierung ermöglicht. Die strukturellen Aspekte des Modells bieten die Fähigkeit, ein Modellelement als enthalten in oder durch ein anderes Modellelement zu definieren. Zusätzlich bietet das Strukturmodell die Möglichkeit, den logischen Datentyp und physische Verbindungen zwischen Elementen zu erkennen sowie Verbindungen zwischen Elementen herzustellen.
Zum Konfigurieren eines Systems akzeptiert die vorliegende Erfindung Eingaben in Form von Anforderungen (z. B. Komponenten oder Ressourcen) oder Bedürfnissen, wie etwa den Ausdruck des Bedürfnisses nach einem Desktop-Computer, der in einer CAD-Umgebung (d. h. computergestütztes Design) verwendet werden soll. Mit diesen Informationen konfiguriert die vorliegende Erfindung ein System durch Erkennen des Bedarfs an Ressourcen und Komponenten, der von oder durch die erkannten Ressourcen oder Komponenten auferlegten Randbedingungen sowie der strukturellen Aspekte des Systems.
Die Systemkonfiguration kann auf einer allgemeinen Systemdefinition (d. h. Desktop-Computersystem zum Betrieb in einer CAD-Umgebung) oder einer beliebigen Ebene weiterer Spezifizierung (z. B. Diskettenlaufwerk nach Hersteller und Modellnummer) basieren. Die Systemkonfiguration kann auf spezifischen Komponentenanforderungen (z. B. Laserdrucker) oder Bedürfnissen (z. B. Druckfähigkeit) basieren. Wenn das System konfiguriert ist, kann das konfigurierte System in Produkte gebündelt und ein Angebot erzeugt werden. Der Paketerstellungsprozess kann eine heuristische Spezifizierung umfassen, um die Zuordnung von Produkt und Komponenten zu steuern. So kann das Produkt mit der größten Anzahl an Komponenten zum Beispiel den Vorzug gegenüber anderen möglichen Produktauswahlen, die eine geringere Anzahl von Komponenten abdecken, erhalten.
Die funktionale und strukturelle Hierarchie der vorliegenden Erfindung bietet die Fähigkeit, die Struktur des Konfigurationsmodells und des aus dem Modell konfigurierten Systems zu definieren. Die Strukturhierarchie umfasst eine Container-Struktur. Ein Container ermöglicht es zu spezifizieren, dass eine Komponente von bzw. in einer anderen Komponente enthalten ist. Somit lässt sich zum Beispiel erkennen, dass eine Komponentenanforderung für ein Diskettenlaufwerk nicht erfüllt werden kann, weil keine freien Einbaurahmen im Schrank vorhanden sind, die zur Aufnahme der angeforderten Komponente eingerichtet sind.
Der Strukturhierarchiebegriff bietet die Möglichkeit der Zusammenlegung von Ressourcen. Die explizite Darstellung der Struktur, insbesondere der hierarchischen Struktur, bietet die Möglichkeit, ererbte Ressourcen zu definieren und auf sie zuzugreifen. Zum Beispiel können Computer-, Telekommunikations-, medizinische oder Unterhaltungselektronik-Komponenten in einem Schrank untergebracht werden, der diese Komponenten mit Strom versorgt. Diese Einzelkomponenten können den elektrischen Strom von einem strukturell übergeordneten Element ererben (d. h. einem Hierarchieeintrag, der eine oder mehrere Ebenen über den Komponenten in der Modellhierarchie angesiedelt ist). Weiterhin kann das strukturell übergeordnete Element Ressourcen zusammenlegen und eine homogene Ressource an strukturell untergeordnete Elemente (d. h. einem Hierarchieeintrag, der eine oder mehrere Ebenen unter dem strukturell übergeordneten Element in der Modellhierarchie angesiedelt ist) stellen. Zum Beispiel kann ein Schrank mehr als eine elektrische Stromquelle enthalten, doch werden diese den strukturell untergeordneten Komponenten als einziger Ressourcenpool präsentiert. Wenn eine Komponente daher eine bestimmte Ressource benötigt, kann diese Ressource von einem Ressourcenpool bereitgestellt werden. Wenn ein Desktop-Computersystem zum Beispiel mehrere Stromversorgungen enthält, kann eine Diskettenlaufwerkkomponente Strom aus einem Ressourcenpool beziehen, ohne zu wissen, dass der Ressourcenbedarf von mehreren Stromquellen befriedigt wird.
Außerdem bietet die Strukturspezifikation die Möglichkeit, Verbindungen zwischen Komponenten eines konfigurierten Systems anzugeben. Wenn weitere Komponenten zur Konfiguration hinzukommen, können die zur Montage der Systemkomponenten erforderlichen physischen und logischen Verbindungen geprüft werden. Zum Beispiel muss vor der Eingliederung eines Druckers mit einer seriellen logischen Schnittstelle und einem physischen 24-Pin-Anschluss im konfigurierten System ein serieller Port verfügbar sein. Weiterhin muss eine physische Verbindung zwischen dem Drucker und dem seriellen Port eingerichtet werden. Wenn der serielle Port eine 9-Pin-Buchse ist und der Drucker eine 24-Pin-Buchse aufweist, muss ein Kabel vorhanden sein, das Drucker und seriellen Port physisch miteinander verbinden kann. Außerdem wird die eigentliche Verbindung in der Konfiguration erstellt und kann bei der späteren Verbindungsbearbeitung untersucht werden. Die Verbindungsbearbeitung bietet die Möglichkeit, Kriterien für die Erfüllung einer Verbindungsanforderung zu erkennen. Zum Beispiel können Verbindungskriterien die billigste, längste oder optimale Durchgangsverbindung umfassen.
Mit der Verbindungsbearbeitung kann auch die Nutzung der konfigurierten Systemressourcen optimiert werden. Zum Beispiel können die Ressourcen einer Steuerung durch eine Prioritätskette anderer Komponenten optimiert werden. Durch die Verbindung einer Komponente mit einer anderen über mehrere eingreifende Komponenten lassen sich mehrere Komponenten über einen einzigen Port oder eine Verbindung mit einer Komponente verbinden.
In der vorliegenden Erfindung wird eine Modellsprache zur Definition einer Modellhierarchie verwendet. Die Modellhierarchie ist strukturell und funktional. Die Modellsprache bietet die Möglichkeit, eine in Produktlinien gruppierte Produktbasis zu definieren. Das Strukturhierarchiemodell umfasst als Grundklassen die Komponente, Verbundgruppe, den Container, Port und Verbinder. Die Grundklassen können sich in abgeleitete Klassen (d. h. systemspezifische Klassen) aufgliedern, die an Blatt-Deszendenten enden. Blatt-Deszendenten definieren den Typ der Komponenten im funktional-strukturellen Hierarchiemodell. Eigenschaften, Datentypen, Ressourcen und Randbedingungen definieren das Modell weiter.
Eine Modellsprache liefert das Format für die Definition der Elemente, der den Komponenten auferlegten Randbedingungen und der Modellstruktur. Die Modellsprache kann direkt verwendet oder aufgrund von Eingaben eines interaktiven Modellunterhaltungssystems zur Erstellung und Wartung des Modells generiert werden.
Das Unterhaltungssystem zeigt das Modell grafisch an und bildet die Schnittstelle für die Auswahl der zu aktualisierenden Modellelemente. Wenn die gewünschten Aktualisierungen vorgenommen wurden, bietet das Unterhaltungssystem die Möglichkeit, das neue Modell zu testen oder zu prüfen, ob das neue Modell erfolgreich kompiliert werden kann.
Wenn das Modell erfolgreich definiert wurde, bietet die vorliegende Erfindung die Möglichkeit, mit dem funktional-strukturellen Hierarchiemodell ein System zu konfigurieren. Eine interaktive Schnittstelle bietet die Möglichkeit, eine Konfiguration als Modellelementanforderung (z. B. Komponenten), Ressourcenanforderung und/oder Bedürfnisanforderung (z. B. Forderungen) auszudrücken. Die Konfigurations-Engine wird aufgerufen, um diese Anforderungen zu erfüllen.
Die Konfigurations-Engine greift auf die Produktbasis zu, um Anforderungen mit einer festgelegten Priorität zu erfüllen. Eine Anforderung wird verarbeitet, indem Komponenten zur Konfiguration hinzugefügt oder vorhandene Komponenten erkannt werden, die die Anforderung erfüllen können. Weiterhin werden Verbindungen, Datenübertragungspfade und dynamisch ermittelte Strukturbeziehungen definiert. Bei erfolgreicher Verarbeitung einer Anforderung werden die Konfigurationsmodifikationen ausgeführt. Fehlgeschlagene Anforderungen werden gemeldet.
Eine grafische Darstellung veranschaulicht das konfigurierte System und dessen Strukturmerkmale. Die Elemente des konfigurierten Systems werden in Form ihrer physischen und räumlichen Position zu anderen Elementen illustriert. Elemente sind in anderen Elementen enthalten, bestehen aus anderen Elementen oder sind mit solchen verbunden. Diese grafische Darstellung bietet außerdem eine Schnittstelle zur Modifikation und Wartung von Elementen des konfigurierten Systems.
Die Elemente des konfigurierten Systems werden zur Preisbestimmung des Systems und aus Fertigungsgründen in verfügbare Marketing- und Fertigungspakete gebündelt. Der Bündelungsprozess führt eine Produkt-Komponenten-Zuordnung auf der Basis von Produktdefinitionen aus.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist eine schematische Darstellung des Konfigurations-Computersystems.
2 stellt eine Funktionshierarchie dar.
3 stellt eine funktional-strukturelle Hierarchie dar, die aus den fünf Grundklassen, abgeleiteten Klassen und Komponententypen besteht.
4 ist die funktional-strukturelle Hierarchie für ein Modell zur Konfiguration von Computersystemen.
5 stellt die Komponentenverbindungen mit mehreren eingreifenden Komponenten und Datentypen dar.
6 stellt den Prozessablauf der Konfigurations-Engine dar.
7 stellt den Ablauf des Prozesses SatisfyResourceRequest (Erfüllen einer Ressourcenanforderung) dar.
8 stellt den Ablauf der Prozesse SatisfyContainerConstraint und SatisfyComponentRestraint (Erfüllen einer Container-Randbedingung, Erfüllen einer Komponenten-Randbedingung) dar.
9A stellt den Ablauf des Prozesses SatisfyConnectionConstraint (Erfüllen einer Verbindungs-Randbedingung) dar.
9B stellt den Ablauf des Prozesses CandidatePorts (Port-Kandidaten) dar.
10 stellt den Ablauf des Prozesses EstablishSetCover (Abdeckung einrichten) dar.
11 stellt ein Systemfenster für eine Konfiguration eines Desktop-Computersystems dar.
12 ist ein Ablaufschema, das die Funktionsweise des Konfigurationssystems darstellt.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Es wird ein Verfahren und eine Vorrichtung für die Konfiguration von Systemen beschrieben. In der folgenden Beschreibung werden zahlreiche spezifische Details angeführt, um eine genauere Beschreibung der vorliegenden Erfindung zuliefern. Es wird für den Fachmann jedoch offenkundig sein, dass die vorliegende Erfindung auch ohne diese spezifischen Details ausgeführt werden kann. In anderen Fällen wurden wohlbekannte Merkmale nicht im Detail beschrieben, um die Erfindung nicht in den Schatten zu stellen.
Die vorliegende Erfindung bietet ein Tool für das Konfigurieren von Systemen, das einen breiten Anwendungsbereich hat, darunter: Computer-Hardware, Computer-Software, Computernetze, Telekommunikationssysteme (z. B. Nebenstellenanlagen und Voicemail), Kopierer, medizinische Bildgebungsanlagen, Fahrzeuge (z. B. Feuerwehr- und Baufahrzeuge), elektronische Steuerungen, Gebäude, Möbel nach dem Baukastenprinzip, Fertigungstechnik, Fertigungssysteme, Unterhaltungselektronik und elektronische Systeme.
1 ist eine schematische Darstellung des erfindungsgemäßen Konfigurationssystems. Das Konfigurationssystem 10 besteht aus dem Modellunterhaltungssubsystem 12, dem Subsystem Konfigurationserstellung und Berichte 14, dem Subsystem Pakete/Angebote, dem Kommunikationsbus 18, Ein-/Ausgabe 20, Speicher 22, Zentraleinheit (CPU) 24 und Massenspeicher 26.
12 ist ein Ablaufschema, das die Funktionsweise des Konfigurationssystems darstellt. In Block 600 wird eine Modellbasis gelesen. Das Konfigurationssystem verwendet die Modellbasis mit Informationen über alle zum Konfigurieren eines Systems verfügbaren Elemente (z. B. Komponenten und Ressourcen). Diese Modellbasis wird als Produktbasis bezeichnet.
Die Produktbasis wird mit einer Modellsprache erstellt. Die Modellsprache liefert die Syntax oder Anweisungen zur Definition der Modellelemente, die den Modellelementen auferlegten Randbedingungen und die Struktur des Modells. An Verarbeitungsblock 604 kann mit der Modellsprache die Modelldefinition eingegeben werden, die Modellverarbeitung endet in Block 606.
Modellunterhaltung – Der Prozess der Modelldefinition kann durch Wahl des Modellunterhaltungssubsystems an Entscheidungsblock 602 erleichtert werden (d. h. „Modellunterhaltungssubsystem verwenden?"). An Block 608 wird das entweder neue oder vorhandene Modell angezeigt. An Block 610 kann das Modell bearbeitet werden. Das Modellunterhaltungssubsystem 12 bietet die Möglichkeit, die Gültigkeit des modifizierten Modells an Entscheidungsblock 612 zu prüfen oder einem Debugging-Prozess zu unterziehen (d. h. „write Integrity, ProductBase Integrity oder Debugger?"). Die Auswahl „write Integrity" ermittelt die Integrität der Parse-Datei (d. h. Teilmengen der Produktbasis) unter Hinzufügung der Modifikationen. Die Auswahl „ProductBase Integrity" ermittelt die Integrität der Produktbasis unter Hinzufügung der Modifikationen.
Bei Auswahl der Option „Debugger" werden an Block 618 Benchmark-Systemkonfigurationsanforderungen aus einer Datei ausgelesen. An Block 14 wird das Subsystem Konfigurationserstellung und Berichte 14 aufgerufen, um mit den modifizierten Modell- und Benchmark-Konfigurationsanforderungen ein System zu konfigurieren. Die Verarbeitung dieser Anforderungen durch das Subsystem Konfigurationserstellung und Berichte 14 kann zur Untersuchung des Konfigurationsprozesses verfolgt werden.
Wenn an Entscheidungsblock 622 weitere Modifikationen erfolgen (d. h. „Modell ändern?"), wird in 608 eine grafische Darstellung des Modells angezeigt und der Modifikationsprozess in Block 610 weitergeführt. Wenn keine weiteren Modifikationen erfolgen, wird in Block 624 die Modelldefinition generiert, und das Modellunterhaltungssubsystem endet in Block 606.
Subsystem Konfigurationserstellung und Berichte – Das Subsystem Konfigurationserstellung und Berichte 14 generiert mit der Modelldefinition ein nach den benutzerspezifischen Anforderungen und Bedürfnissen konfiguriertes System. Die entsprechende Konfiguration wird grafisch dargestellt. Es werden Berichte mit Angaben zur Konfiguration erstellt. Wenn festgestellt wird, dass eine vorhandene Konfiguration in Entscheidungsblock 630 aktualisiert wird (d. h. „Upgrade des vorhandenen Systems?"), wird das vorhandene System gelesen und seine Elemente in Block 632 als vorhanden markiert. Wenn ein neues System konfiguriert wird, wird an Block 634 eine leere Systeminstanz erstellt. Die Formulare für die Eingabe von Elementanforderungen oder Bedürfnissen werden in 636 angezeigt. Wenn die Eingabe an Block 638 9 unvollständig ist (d. h. „Anforderungen abgeschlossen?"), wird die Verarbeitung in Block 636 fortgesetzt.
Konfigurations-Engine – Wenn die Eingabe aller Anforderungen und Bedürfnisse abgeschlossen ist, wird die Konfigurations-Engine aufgerufen, um in 640 anhand der Eingabe ein konfiguriertes System zu generieren. Eine grafische Darstellung der Konfiguration wird in 642 angezeigt. Die Konfiguration kann modifiziert, Berichte können erstellt oder die Komponenten der Konfiguration können in Pakete gebündelt und ein Angebot erstellt werden. Wenn an Entscheidungsblock 644 Modifikationen beabsichtigt sind (d. h. „Konfigurationsänderungen?"), wird die Verarbeitung an Block 652 (d. h. „Modell filtern?") fortgesetzt. Wenn an Entscheidungsblock 652 ein gefiltertes Modell verwendet wird, wird eine Teilmenge des Modells in Block 654 generiert. Das Teilmodell umfasst jene Modellelemente, die aufgrund der gegebenen Konfiguration gewählt wurden. Die Verarbeitung wird mit der Anzeige der Eingabeformulare in 636 fortgesetzt. Wenn kein gefiltertes Modell verwendet wird, wird die Verarbeitung in 636 fortgesetzt.
Nach dem Konfigurieren eines Systems können die Konfigurationselemente in Marketing- oder Fertigungsprodukte gebündelt werden. Der Paketierer 660 weist die Konfigurationskomponenten Produkten zu. Die Angebotserstellung 662 erzeugt ein Preisangebot für das konfigurierte System. Das Angebot wird in 664 angezeigt. Wenn es in Entscheidungsblock 666 keine Konfigurationsmodifikationen gibt (d. h. „Konfiguration ändern?"), endet die Verarbeitung bei Block 606. Wenn es Konfigurationsmodifikationen gibt, wird in Block 668 das Subsystem Konfigurationserstellung und Berichte 14 aufgerufen.
STRUKTURELLE HIERARCHIE
Das erfindungsgemäße Konfigurationssystem ist ein restriktionsbasiertes Schema mit einer funktional-strukturellen Hierarchie. 3 zeigt diese funktional-strukturelle Hierarchie und fünf ihr innewohnende Grundklassen an. Die funktional-strukturelle Hierarchie enthält eine Klassenhierarchie aus fünf inneren Grundklassen 70, die die Grundtypen von Modellobjekten definieren. Diese fünf Grundklassen sind: Komponente 60, Verbundgruppe 62, Verbinder 64, Container 66 und Port 68. Die Komponente 62 ist die Grundklasse, von der alle anderen Klassen und Komponententypen abgeleitet sind. Von Komponente 62 beginnt jeder Zweig des Hierarchiebaums mit einer inneren Grundklasse und verzweigt sich zu systemspezifischen Klassen, die als abgeleitete Klassen 88 bezeichnet werden. Abgeleitete Klassen 88 sind Definitionen von breiten Komponentenkategorien wie Speichergeräte, Stromversorgungen und Peripheriekarten. Aus den Grundklassen können mehrere Generationen von abgeleiteten Klassen hervorgehen. Jeder Zweig endet mit „Blatt-Deszendenten" oder Komponententypen 90. Die Komponententypen 90 repräsentieren tatsächliche Komponenten, die installiert und konfiguriert werden können.
Die Klasse Verbundgruppe 62 ist eine statische Struktur (d. h. Elemente mit einer Substruktur). Elemente in dieser Klasse haben oder sind Subkomponenten einer Zusammenstellung. Die Klasse Verbinder 64 zweigt von der Klasse Verbundgruppe 62 ab. Diese Klasse definiert die Modellelemente, die Elemente verbinden. Ein Element in der Klasse Container 66 gibt an, dass dieses Element weitere Elemente enthalten kann. Elemente in der Klasse Port 68 geben Anschlussalternativen an und definieren den Datentyp eines Ports. Von der Klasse Port 68 abgeleitete Elemente können physisch mit anderen von der Klasse Port 68 abgeleiteten Elementen verbunden sein.
Die vorliegende Erfindung bietet die Möglichkeit, in einer strukturellen Hierarchie darzustellen, wie Komponenten eines bestimmten Systems räumlich und physisch existieren. Innerhalb der Strukturhierarchie gibt es drei Arten von Substrukturen: Verbundgruppenhierarchien, Container-Hierarchien und Port-Beziehungen. Verbundgruppenhierarchien identifizieren Komponenten als Teil anderer Komponenten. Zum Beispiel hat ein Gestellrahmen acht Baugruppeneinbauplätze. Container-Hierarchien identifizieren in anderen Komponenten enthaltene Komponenten. Eine Container-Hierarchie ist eine dynamische Struktur, da diese bei der Erstellung einer Konfiguration dynamisch erstellt wird. Zum Beispiel wird eine CPU-Karte in Einbauplatz 0 des Gestellrahmens angeordnet.) Port-Beziehungen identifizieren Komponenten, die Verbindungen zu anderen Komponenten herstellen. Eine Verbindungs- oder Port-Beziehung wird bei der Erstellung einer Konfiguration dynamisch erstellt. Die Beziehungen zwischen Generationen innerhalb dieser Substrukturen werden durch die Schlüsselwörter „childOf", „containedBy" und „connectsWith" ausgedrückt.
Das Schlüsselwort „childOf" gibt an, dass eine Komponente Teil einer Komponente ist, die von der Klasse Verbundgruppe abstammt. Das Schlüsselwort „containedBy" gibt an, dass eine Komponente in einer Komponente enthalten ist, die von der Grundklasse Container abstammt. Das Schlüsselwort „connectsWith" gibt an, dass eine Komponente eine Verbindung zu einer Komponente herstellt, die von der Port-Klasse abstammt.
Container-Hierarchien haben normalerweise eine Wechselbeziehung mit Verbundgruppenhierarchien. Ein Container ist häufig „childOf" einer Verbundgruppe, und die Verbundgruppe ist „containedBy" einem anderen Container. Jede Substruktur hat ein Wurzelmitglied, das auch Deszendent der Grundklasse mit demselben Namen ist (d. h. Verbundgruppe, Container oder Port). Mitglieder einer Substruktur können jeder in der Klassenhierarchie definierten Klasse angehören. Zum Beispiel kann eine von der Klasse Container abstammende Komponente der Klasse Einbaurahmen eine Komponente der Klasse Speichergerät (abstammend von der Klasse Komponente) oder der Klasse Karte_Gestellrahmen (abstammend von der Klasse Container) enthalten.
4 stellt die strukturelle Hierarchie der fünf Grundklassen, abgeleiteten Klassen, Blatt-Deszendenten und Substruktur-Beziehungen dar. Die Strukturbeziehungen definieren weiterhin die Strukturaspekte des Modells. Zum Beispiel ist Einbauplatz 114 „childOf" Schrank 110. Daher ist Einbauplatz 110 eine Subkomponente der Verbundgruppenkomponente Schrank 110. Weiterhin ist Schrank 110 „childOf" System 116. Zweite Auftritte der Karte 118 (d. h. 118A) und des Einbauplatzes (d. h. 114A) veranschaulichen die Substrukturbeziehung zwischen Karte und Einbauplatz. Karte 118A ist „containedBy" Einbauplatz 114A. Auf gleiche Weise ist das Speichergerät 120A „containedBy" Einbaurahmen 122A und Steckerausgang DB25 124A „connectsWith" Buchsenausgang DB25 126.
Die Strukturaspekte des erfindungsgemäßen Modells bieten die Möglichkeit, Ressourcen zu ererben und zusammenzulegen. Zum Beispiel kann eine Container-Komponente, Schrank, aus einem Gestellrahmen und zwei 100W-Stromversorgungen A und B bestehen. Jedes der Elemente im Gestellrahmen-Container verbraucht oder erfordert eine gewisse Menge Strom. Wenn die Gestellrahmen-Komponente zwei Zentraleinheiten (CPUs), die zusammen 110 Watt (z. B. je 55 Watt) verbrauchen, einen RAM-Speicher, der 70 Watt verbraucht, und mehrere Karten (z. B. Steuerungen), die insgesamt 20 Watt verbrauchen, enthält, dann kann keine der Stromversorgungen unabhängig von der anderen den Gestellrahmen und seine Elemente mit ausreichend Strom versorgen.
Dennoch können, da die beiden Stromversorgungen im Container-Schrank enthalten und Teil von ihm sind, die beiden Stromversorgungen zusammengelegt werden, um die Elemente im Schrank zu versorgen. Wenn also die Ressourcenanforderungen für die Elemente in diesem Beispiel verarbeitet werden, kann die eine oder die andere zur Erfüllung der Anforderung verwendet werden. Außerdem ist es möglich, den Ressourcenbedarf für ein beliebiges Element mit beiden Stromversorgungen zu decken. Wenn zum Beispiel ein CPU-Ressourcenbedarf zuerst mit 55 W von Stromversorgung A verarbeitet wird und die Ressourcenverarbeitung für den RAM-Speicher als nächstes folgt, kann der Bedarf des RAM-Speichers nicht mit Stromversorgung A allein gedeckt werden. Doch ist es möglich, den Ressourcenbedarf des RAM unter Verwendung von 45 Watt aus Stromversorgung A und 25 Watt aus Stromversorgung B zu decken. Eine weitere Ressource, bei der das Zusammenlegen von Ressourcen möglich ist, ist eine Wärmeableitungsressource.
CONTAINER
Die strukturelle Hierarchie bietet die Möglichkeit, das Modell so zu strukturieren, dass ein Modellelement oder eine Gruppe von Modellelementen in einem bzw. einer anderen enthalten ist. Die Verwendung des enthaltenen Modellelements in einer Konfiguration kann durch die Verfügbarkeit eines Container-Elements in der Konfiguration beschränkt sein.
8 stellt den Ablauf der Prozesse SatisfyContainerConstraint und SatisfyComponentRestraint (Erfüllen einer Container-Randbedingung, Erfüllen einer Komponenten-Randbedingung) dar. An Entscheidungsblock 500 (d. h. „Geforderte Instanz schon in der Konfiguration verfügbar?") wird die Randbedingung durch die verfügbare Instanz erfüllt und die Verarbeitung bei Block 526 fortgesetzt, wenn die geforderte Instanz bereits existiert und zur Erfüllung der Randbedingung zur Verfügung steht. Wenn nicht, wird die geforderte Instanz instantiiert und die Modifikationsliste in Verarbeitungsblock 502 aktualisiert. Bei Entscheidungsblock 504 (d. h. „Sind Randbedingungen zu verarbeiten?") wird die Randbedingung durch die neue Instanz erfüllt und die Verarbeitung bei Block 526 fortgesetzt, wenn die neue Instanz keine Randbedingungen aufweist.
Wenn Randbedingungen zu verarbeiten sind, wird die nächste Randbedingung bei 508 erkannt. Wenn festgestellt wird, dass es sich um die Randbedingung „requiresContainer" an Entscheidungsblock 510 (d. h. „Container erforderlich?") handelt, wird die Verarbeitung bei Block 512 (d. h. „Container-Randbedingung erfüllen") fortgesetzt, um die Randbedingung „requiresContainer" zu erfüllen, und die Verarbeitung wird bei Entscheidungsblock 522 (d. h. „Randbedingung erfüllt?") fortgesetzt.
Wenn festgestellt wird, dass es sich nicht um die Randbedingung „requiresContainer" an Entscheidungsblock 510, sondern um die Randbedingung „requiresConnection" bei Entscheidungsblock 514 (d. h. „Verbindung erforderlich?") handelt, wird die Verarbeitung bei Block 516 (d. h. „Verbindungs-Randbedingung erfüllen") fortgesetzt, um die Randbedingung „requiresConnection" zu erfüllen, und die Verarbeitung wird bei Entscheidungsblock 522 (d. h. „Randbedingung erfüllt?") fortgesetzt.
Wenn es sich nicht um die Randbedingung „requiresContainer" an Entscheidungsblock 510 und nicht um die Randbedingung „requiresConnection" an Entscheidungsblock 514 (d. h. „Verbindung erforderlich?") handelt, wird die Verarbeitung bei Entscheidungsblock 518 (d. h. „Komponente erforderlich?") fortgesetzt. Wenn festgestellt wird, dass es sich um die Randbedingung „requiresComponent" an Entscheidungsblock 518 (d. h.,,Komponente erforderlich?") handelt, wird die Verarbeitung bei Block 520 (d. h. „Komponenten-Randbedingung erfüllen") fortgesetzt, um die Randbedingung „requiresComponent" zu erfüllen, und die Verarbeitung wird bei Entscheidungsblock 522 (d. h. „Randbedingung erfüllt?") fortgesetzt. Bei Entscheidungsblock 522 (d. h. „Randbedingung erfüllt?") wird die Verarbeitung bei Entscheidungsblock 504 (d. h. „Sind Randbedingungen zu verarbeiten?") fortgesetzt, wenn die Randbedingung erfüllt wurde. Wenn die Randbedingung nicht erfüllt wurde, wird die Randbedingung als nicht durch eine vorhandene oder neue Instanz erfüllt markiert und die neue Instanz in Verarbeitungsblock 524 aus der Modifikationsliste entfernt. Die Verarbeitung wird bei Block 526 fortgesetzt.
VERBINDUNGSVERARBEITUNG
Die Verwendung eines Modellelements in einer Konfiguration kann auch durch die Fähigkeit, eine Verbindung zu einem anderen Modellelement herzustellen, eingeschränkt sein. Die Randbedingung „requiresConnection" erfordert, dass zwischen den beiden Komponenten eine physische Verbindung besteht. 9A stellt den Ablauf des Prozesses zur Erfüllung der Randbedingung „requiresConnection" dar. Bei Verarbeitungsblock 280 wird eine Zielkomponente gewählt und eine Liste von Ports erstellt. Bei Verarbeitungsblock 282 werden die angeforderten Ressourcen zugewiesen. Bei Verarbeitungsblock 284 wird die Liste CandidatePorts aufgerufen, um für die Zielkomponente zugängliche freie Ports zu erkennen. Bei Verarbeitungsblock 286 werden lokale Portkandidaten (d. h. jene Ports, die frei sind und den erforderlichen Datentyp haben) erkannt. Bei Verarbeitungsblock 288 werden die Verbinderkandidaten identifiziert.
Bei Verarbeitungsblock 290 (d. h. „Wurden alle Verbinder geprüft?") wird, wenn alle Verbinder geprüft wurden, die Anforderung als erfolglos markiert und die Verarbeitung an Block 306 (d. h. „Rückkehr") fortgesetzt. Wenn nicht, wird der nächste Verbinder bei Block 294 gewählt. Bei Entscheidungsblock 296 (d. h. „Ist der physische Typ von Port1 des Verbinders mit dem physischen Typ des Ziel-Ports verbindbar?") wird die Verarbeitung bei Entscheidungsblock 290 (d. h. „Wurden alle Verbinder geprüft") fortgesetzt, wenn Port1 des Verbinders nicht vom gleichen physischen Typ (z. B. 25-Pin) wie der Ziel-Port ist.
Andernfalls wird die Verarbeitung bei Entscheidungsblock 298 fortgesetzt. Bei Entscheidungsblock 298 (d. h. „Ist der physische Typ von Port2 des Verbinders mit dem physischen Typ des lokalen Ports verbindbar?") wird die Verarbeitung bei Entscheidungsblock 290 (d. h. „Wurden alle Verbinder geprüft") fortgesetzt, wenn Port2 des Verbinders nicht vom gleichen physischen Typ (z. B. 25-Pin) wie der lokale Port ist. Andernfalls wird die Verarbeitung bei Entscheidungsblock 300 fortgesetzt. Wenn es bei Entscheidungsblock 300 (d. h. „Gibt es einen Übertragungspfad zwischen Port1 und Port2?") keinen Übertragungspfad zwischen Port1 und Port2 gibt, wird die Verarbeitung bei Entscheidungsblock 290 (d. h. „Wurden alle Verbinder geprüft") fortgesetzt. Andernfalls wird die angeforderte Ressource bei Block 302 zugewiesen. Bei Verarbeitungsblock 304 wird der Ziel-Port an Port2 des Verbinders und der lokale Port an Port1 des Verbinders angeschlossen. Die Verarbeitung wird bei Block 306 beendet.
Es müssen Port-Kandidaten erkannt werden, um eine Randbedingung „requiresConnection" zu erfüllen. 9B stellt den Ablauf des Prozesses CandidatePorts(list) (Port-Kandidatenliste) dar. In Verarbeitungsblock 310 von „CandidatePorts(list)" wird die Port-Variable auf den nächsten Port auf der Liste eingestellt. Wenn der Port bei Entscheidungsblock 312 (d. h. „Ist Port verbunden?") verbunden ist, wird die Verarbeitung bei Verarbeitungsblock 316 fortgesetzt. Wenn nicht, bestimmt der Entscheidungsblock 314 (d. h. „Richtiger Daten-Typ oder sind Konvertierungen zulässig?"), ob die Datentypen kompatibel sind. Wenn nicht, wird die Verarbeitung bei Block 310 fortgesetzt und der nächste Port gesucht.
Wenn sie kompatibel sind, wird „thePort" auf die Port-Liste gesetzt und die Verarbeitung bei Block 310 fortgesetzt. Wenn festgestellt wird, dass „thePort" bereits bei Verarbeitungsblock 312 angeschlossen wurde, wird die Verarbeitung bei Verarbeitungsblock 316 fortgesetzt und „newPort" auf den Port eingestellt, mit dem „thePort" verbunden ist. Bei Block 320 wird eine neue Portliste für alle Ports, an die „newPort" überträgt, erstellt. Wenn „newList" bei Entscheidungsblock 322 (d. h. „Enthält newList einen Port der anfordernden Komponente?") einen der anfordernden Komponentenports enthält, wird die Verbindung in Block 326 als bereits vorhanden markiert und die Verarbeitung kehrt zu Block 328 zurück. Wenn nicht, wird CandidatePorts(list) für die „newList" aufgerufen.
KONFIGURATIONS-ENGINE
Wenn der Benutzer die Komponenten für das zu modellierende System gewählt hat, ruft er die Konfigurations-Engine auf. Der Konfigurator greift auf die Produktbasis zu, um die Objektklasse zu erkennen. Nach erfolgreicher Durchführung bestimmter Gültigkeitsprüfungen instantiiert (d. h. erstellt) der Konfigurator ein Mitglied dieser Klasse, das als Objektinstanz bezeichnet wird. Der Konfigurator instantiiert lediglich jene Objekte, die zur Konfiguration des angeforderten Systems erforderlich sind.
Die Konfigurations-Engine verarbeitet die Komponenten- und Ressourcenanforderungen mit der angegebenen Priorität. Mit der Bearbeitung der einzelnen Anforderungen wird die vorhandene Konfiguration modifiziert durch: (1) Hinzufügen der angeforderten Komponente und weiterer zur Unterstützung der angeforderten Komponente notwendiger Komponenten sowie (2) Identifizieren vorhandener und neuer Komponenten, die zur Bereitstellung der angeforderten Ressource erforderlich sind. Wenn eine Anforderung erfolgreich verarbeitet wird, werden die Konfigurationsmodifikationen ausgeführt, und diese Konfiguration wird die Eingabekonfiguration bei der Verarbeitung der nächsten Anforderung.
6 stellt den Prozessablauf der Konfigurations-Engine dar. Verarbeitungsblock 202 erstellt eine Prioritätsliste der Anforderungen. Wenn bei Entscheidungsblock 204 (d. h. „Alle Anforderungen verarbeitet?") festgestellt wird, dass alle Anforderungen verarbeitet wurden, wird die Verarbeitung bei Block 206 beendet. Wenn nicht, wird die Verarbeitung bei Block 208 fortgesetzt.
Der Anforderungstyp wird in Entscheidungsblock 210 (d. h. „Anforderungstyp?") festgelegt. Handelt es sich um eine Komponentenanforderung, wird die Verarbeitung bei Verarbeitungsblock 212 fortgesetzt. Bei Block 212 wird die angeforderte Komponente instantiiert und zur Modifikationsliste gesendet, und die Verarbeitung wird bei Entscheidungsblock 216 fortgesetzt. Handelt es sich um eine Ressourcenanforderung, wird die Komponente, die diese Ressource liefern kann, in Verarbeitungsblock 214 (d. h. „Ressourcenanforderung erfüllen") identifiziert werden, und die Verarbeitung wird bei Entscheidungsblock 216 fortgesetzt. Bei Entscheidungsblock 216 (d. h. „Instantiierung oder Zuweisung erfolgreich?") wird die Verarbeitung bei Entscheidungsblock 224 (d. h. „Sind Randbedingungen zu verarbeiten?") fortgesetzt, wenn die Instantiierung der Komponente oder Zuweisung der Ressource erfolgreich war. Wenn die Instantiierung der Komponente oder Zuweisung der Ressource nicht erfolgreich war, wird die Verarbeitung bei Entscheidungsblock 218 (d. h. „Gibt es weitere Alternativen zur Erfüllung der Anforderung?") fortgesetzt.
Wenn in Entscheidungsblock 218 (d. h. „Gibt es weitere Alternativen zur Erfüllung der Anforderung?") festgestellt wird, dass keine weiteren Alternativen zur Erfüllung der Anforderung bestehen, wird die Anforderung als erfolglos identifiziert und die Verarbeitung bei Entscheidungsblock 204 (d. h. „Alle Anforderungen verarbeitet?") fortgesetzt. Wenn weitere Alternativen bestehen, werden die Modifikationen der fehlgeschlagenen Alternative bei 220 aus der Modifikationsliste entfernt, die nächste Alternative bei 222 an die Modifikationsliste gesendet und die Verarbeitung bei Entscheidungsblock 224 (d. h. „Alle Anforderungen verarbeitet?") fortgesetzt.
Wenn keine Randbedingungen zu verarbeiten sind, werden die Modifikationen bei Entscheidungsblock 224 (d. h. „Sind Randbedingungen zu verarbeiten?") zur Konfiguration in Verarbeitungsblock 244 gesendet und die Verarbeitung bei Entscheidungsblock 204 (d. h. „Alle Anforderungen verarbeitet?") fortgesetzt. Wenn Randbedingungen zu verarbeiten sind, wird die nächste Randbedingung bei 226 erkannt. Wenn festgestellt wird, dass es sich um die Randbedingung „requiresContainer" an Entscheidungsblock 228 (d. h. „Container erforderlich?") handelt, wird die Verarbeitung bei Block 230 (d. h.,,Container-Randbedingung erfüllen") fortgesetzt, um die Randbedingung „requiresContainer" zu erfüllen, und die Verarbeitung wird bei Entscheidungsblock 240 (d. h. „Randbedingung erfüllt?") fortgesetzt. Wenn festgestellt wird, dass es sich nicht um die Randbedingung „requiresContainer” an Entscheidungsblock 228, sondern um die Randbedingung „requiresConnection" bei Entscheidungsblock 236 (d. h. „Verbindung erforderlich?") handelt, wird die Verarbeitung bei Block 232 (d. h. „Verbindungs-Randbedingung erfüllen") fortgesetzt, um die Randbedingung „requiresConnection" zu erfüllen, und die Verarbeitung wird bei Entscheidungsblock 240 (d. h. „Randbedingung erfüllt?") fortgesetzt.
Wenn es sich nicht um die Randbedingung „requiresContainer" an Entscheidungsblock 228 und nicht um die Randbedingung „requiresConnection" an Entscheidungsblock 236 (d. h. „Verbindung erforderlich?") handelt, wird die Verarbeitung bei Entscheidungsblock 238 (d. h. „Komponente erforderlich?") fortgesetzt. Wenn festgestellt wird, dass es sich um die Randbedingung „requiresComponent" an Entscheidungsblock 238 (d. h. „Komponente erforderlich?") handelt, wird die Verarbeitung bei Block 234 (d. h. „Komponenten-Randbedingung erfüllen") fortgesetzt, um die Randbedingung „requiresComponent" zu erfüllen, und die Verarbeitung wird bei Entscheidungsblock 240 (d. h. „Randbedingung erfüllt?") fortgesetzt. Am Entscheidungsblock 240 (d. h. „Randbedingung erfüllt?") wird die Verarbeitung bei Entscheidungsblock 224 (d. h. „Sind Randbedingungen zu verarbeiten?") fortgesetzt, wenn die Randbedingung erfüllt wurde. Wenn die Randbedingung nicht erfüllt wurde, wird die Verarbeitung bei Entscheidungsblock 218 (d. h. „Gibt es weitere Alternativen zur Erfüllung der Anforderung?") fortgesetzt.
Dass Ressourcen von einzelnen Komponenteninstanzen angeboten und nicht als globale Systementitäten dargestellt werden, hilft bei der Erforschung von Alternativen. 7 stellt den Ablauf des Prozesses SatisfyResourceRequest (Erfüllen einer Ressourcenanforderung) dar. Bei Verarbeitungsblock 250 wird die nächste Komponente, die die geforderte Ressource anbietet, gesucht. Wenn in Entscheidungsblock 252 (d. h. „Komponenteninstanzen gefunden?") festgestellt wird, dass keine Komponente diese Ressource anbietet, wird die Verarbeitung bei Verarbeitungsblock 262 fortgesetzt.
Wenn eine Komponente gefunden wird, wird die Verarbeitung bei Entscheidungsblock 254 (d. h. „Wurde diese Ressource verbraucht?") fortgesetzt. Wenn die Ressource verbraucht wurde, wird die Verarbeitung bei Verarbeitungsblock 250 (d. h. „Nächste Komponente, die die geforderte Ressource anbietet, suchen") fortgesetzt. Wenn die Ressource nicht verbraucht wurde, wird bei Entscheidungsblock 256 geprüft, ob Klassenanforderungen und optionale Anforderungen gültig sind. Wenn alle Prüfungen gültig sind, wird die aktuelle Instanz bei Verarbeitungsblock 258 gewählt und die Verarbeitung bei Verarbeitungsblock 264 fortgesetzt. Wenn eine der Prüfungen ungültig ist, wird die Verarbeitung bei Verarbeitungsblock 260 (d. h. „Wurden alle Ressourceninstanzen geprüft?") fortgesetzt. Wenn nicht alle Ressourceninstanzen geprüft wurden, wird die Verarbeitung bei Block 250 fortgesetzt, wo nach der nächsten Komponente gesucht wird, die diese Ressource anbietet.
Wenn alle die Ressource anbietenden Komponenten geprüft wurden oder wenn (bei Entscheidungsblock 252) festgestellt wird, dass keine vorhandene Komponente die Ressource anbietet, wird die Verarbeitung bei Block 262 fortgesetzt und eine neue Komponenteninstanz erstellt, die Konfigurationsmodifikation zur Modifikationsliste gesendet und die Verarbeitung bei Block 264 fortgesetzt. Bei Block 264 wird der zurückgegebenen Instanzvariable der anfordernden Komponente eine Instanz des angeforderten Komponententyps zugewiesen. Die Verarbeitung wird bei Entscheidungsblock 266 (d. h. „Erfüllt die aktuelle Instanz die Abfrage- und Testbedingungen?") fortgesetzt, um festzustellen, ob alle Abfrage- und Testbedingungen erfüllt sind. Wenn nicht, wird die Verarbeitung bei Verarbeitungsblock 250 fortgesetzt. Ansonsten endet die Verarbeitung bei Block 268.
MODELLSPRACHE
Die Modellsprache ermöglicht die Definition eines Modells (z. B. Modellelemente, Model-Randbedingungen und Modellstruktur). Mit der Syntax der Modellsprache werden Anweisungen zur Definition der Modell- oder Produktbasis eingegeben. Die Produktbasis enthält alle Informationen über ein Modell. Die Produktbasis enthält die Informationen, mit denen ein System konfiguriert wird.
Die Produktbasis kann außerdem hierarchische Produktlinien enthalten. Produktlinien gestatten die Unterteilung einer Produktbasis in Gruppen. Ein Beispiel für eine solche Gruppierung sind Marketing-Abteilungen wie DesktopSysteme. Ein Desktopsystem kann alle Komponenten enthalten, die üblicherweise als Teile eines Desktop-Computersystems verkauft werden, darunter Systemsoftware, Modemkarten, Mikroprozessor-Chips usw. Nur Komponenten, die Teil des gleichen Produkts sind, können zusammen konfiguriert werden. Jedoch kann jede Komponente Teil mehrerer Produktlinien sein. Es können auch Produktlinienhierarchien deklariert werden. Ein Child-Element in einer Produktlinienhierarchie erbt vom Parent-Element, und jede Komponente im Parent-Element wird auf das Child-Element vererbt. Das Format einer Produktliniendeklaration sieht wie folgt aus (Hinweis: reservierte Wörter sind fett gedruckt, doppelte Unterstreichungen deuten Wiederholungen an und Teile in „« »" sind obligatorisch):
Oder zur Deklaration von Produktlinienhierarchien:
Systemmodelle werden in Dateien gespeichert, die als Parse-Dateien bezeichnet werden. Gemeinsam sind die Parse-Dateien als Produktbasis bekannt. Parse-Dateien enthalten Informationen über eine allgemeine Kategorie in einem Systemmodell. Datenrepräsentationen einzelner Systeme sind als Objekte bekannt. Schränke, Speichergeräte und Peripheriekarten sind Beispiele von Objekten in der Produktbasis, die zur Konfiguration von Computersystemen verwendet wird. Eine Eigenschaft bietet Attribute für ein Objekt. Zum Beispiel sind in der Produktbasis eines Computersystems solche Eigenschaften wie Kapazität, Strombedarf und Anschluss-Schnittstelle Eigenschaften eines Speichergerät-Objekts. Außerdem kategorisiert eine Eigenschaft ein Objekt. Das heißt, dass Objekte mit gleichen Eigenschaften als Objektklassen bezeichnet werden. Objekte können Eigenschaften von anderen Objekten erben. Das heißt, eine Objektklasse fungiert als Parent-Klasse, und die Child-Klasse weist zusätzlich zu weiteren Eigenschaften sämtliche Eigenschaften der Parent-Klasse auf.
Attribute definieren als für eine erfolgreiche Konfiguration einer Komponente zu berücksichtigende Aspekte einer Komponente. Beispiele von Attributen einer Stromversorgung sind erforderlicher Schrankeinbauplatz und Restleistung, nachdem alle Stromverbraucherkomponenten in die Konfiguration eingebunden wurden. Attribute können auf Klassenebene zugewiesen werden, wobei die Abkömmlinge (Deszendenten) der Klasse die Klassenattribute erben. Außerdem können Attribute mit bestimmten Komponententypen assoziiert werden. Es gibt keine Grenze für die Anzahl an Attributen, die einer Komponente oder Klasse zugewiesen werden können.
Attributwerte können vom Typ Gleitkomma (floating point), Boole (boolean), Kette (string), Datentyp (data type), Komponente (component) und Ressource (resource) sein. Attribute können mehrwertig sein. Das heißt, mehrwertige Attribute können mehr als einen Wert haben. Zum Beispiel kann für eine entweder in einen internen Einbaurahmen mit voller oder halber Höhe einbaubare Komponente das Attribut „attribute_Bay_type_required" beide Werte enthalten. Ein Attribut wird durch eine Anweisung deklariert (Hinweis: „I" gibt eine Auswahl an):
Beispiele für Attributdeklarationen:

Flogt Position

Flogt throughput_available

Flogt load_consumed

resource space_type_required
Eine Ressource ist eine Systemware, die mit Komponententypen assoziiert ist. Eine Ressource kann mehreren Komponententypen zugewiesen sein. Mehrere Ressourcen können einer Komponente zugewiesen sein. Wenn eine Komponente instantiiert wird, wird die dieser Komponente zugewiesene Ressource für die Konfiguration verfügbar gemacht. Wenn eine Komponentenressource verbraucht wird, wird nur die von der zugewiesenen Komponente gelieferte Ressource nicht mehr verfügbar. Die Verfügbarkeit einer Ressource des gleichen Typs, die von einer zweiten Komponente angeboten wird, bleibt vom Verbrauch der Ressource der ersten Komponente unberührt. Wenn daher der gleiche Ressourcentyp von der zweiten Komponente bezogen werden kann, bedeutet der Verbrauch der Ressource der ersten Komponente nicht den Verbrauch aller Ressourcen dieses Typs im modellierten System.
Bevor ein Ressourcentyp einem Komponententyp zugewiesen oder von einer Komponenteninstanz genutzt werden kann, muss der Ressourcentyp deklariert werden. Eine Ressourcendeklaration hat folgendes Format:
resource «ResourceName»,
Beispiel für eine Ressourcendeklaration:
resource static RAM resource;
Datentypdeklarationen definieren die Schnittstellentypen und Datenübertragungsprotokolle, die den Verbindungen im modellierten System zur Verfügung stehen. Beispiele für Datentypen sind SCSI und IDE. Ein Datentyp wird wie folgt deklariert:
Eine abgeleitete Klasse wird durch folgende Anweisung definiert (Hinweis: der mit dem Symbol „¿" gekennzeichnete Teil ist fakultativ):
Der Anzeigestatus umfasst die Werte Hidden (Ausgeblendet), Listed (Gelistet) und Drawn (Angezeigt). Drawn gestattet Klassenmitgliedern, in der grafischen Darstellung der Konfiguration angezeigt zu werden. Listed gestattet Klassenmitgliedern, auf der Liste der Zusatzkomponenten angezeigt zu werden. Hidden wird für ausgeblendete Mitglieder (d. h. nicht angezeigt) verwendet, die „children" (Subkomponenten) im Status Drawn haben. Ein Attributwert kann zum Zeitpunkt der Deklaration zugewiesen werden, doch ist dies nicht Bedingung. Connection origin (Verbindungsursprung) gibt an, ob Instanzen dieser Klasse als Anfangspunkte für die Berichterstellung genutzt werden können oder nicht. Beispiel für die Deklaration einer abgeleiteten Klasse:
In diesem Beispiel wird die abgeleitete Klasse Bay (Einbaurahmen) erstellt. Sie ist Mitglied der Grundklasse Container. Daher kann sie andere Elemente enthalten. Ihre Attribute sind height, half_height compatibility (mit voller/halber Einbauhöhe kompatibel), front_accessibility (Frontzugang; d. h. die Komponente in diesem Einbaurahmen kann von der Front eines Systemschranks erreicht werden), Höhe und Position. Diese Attribute werden von jedem Deszendenten dieser abgeleiteten Klasse ererbt.
Systemkomponenten oder Komponententypen werden durch folgende Deklaration definiert:
Das Feld „label" definiert die Bezeichnung, die der grafischen Darstellung der Komponente gegeben wurde. Das Feld „Description" definiert die angezeigte oder gemeldete Beschreibung. Das Feld „dataType" wird verwendet, wenn der Komponententyp Deszendent eines Ports ist und definiert den Datentyp, der von diesem Komponententyp übertragen werden muss. Das Feld „subComponents" definiert die strukturell untergeordneten Elemente des Komponententyps „Composite" (Verbundgruppe). Das Feld „transfers" definiert die Pfade, über die Daten durch eine Verbundgruppenkomponente fließen können. „Transfers" ist ein Mechanismus zum Ausdruck eines internen Datenpfads innerhalb einer Verbundgruppenkomponente. Ein Kabel wird zum Beispiel als Komponente mit zwei Ports dargestellt und zur Übertragung von Daten von einem Port zum anderen verwendet. Das Feld „values" ermöglicht die Einrichtung von Komponentenattributen oder Eigenschaften. „fillDirection" beschreibt die Reihenfolge, in der mehrere in einem einzelnen Container befindliche Komponenten angezeigt werden.
Beispiel für eine Komponentendefinition:
Dieses Beispiel definiert einen Komponententyp „Cabinet1" innerhalb der Klassen Cabinet (Schrank) und Composite (Verbundgruppe). 4 ist die strukturelle Hierarchie für ein Modell zur Konfiguration von Computersystemen. Cabinet1 108 ist Deszendent von Cabinet 110, der Deszendent von Composite 112 ist. Daher gehört Cabinet1 108 dem Komponententyp Verbundgruppe an. Dieser hat Subkomponenten oder „Children": Slot1_1 bis Slot1_10 und CabinentBay{4}). Die Ganzzahl „4" gibt an, dass Cabinet1 vier Komponententypen CabinetBay (Schrankeinbaurahmen) enthält.
Beispiel für den Komponententyp Composite, der Deszendent eines Verbinders ist:
Beispiel einer Komponententypdefinition, die eine Ressource bereitstellt:
Randbedingungen bieten Konfliktlösungsangaben, um zu ermitteln, ob Komponenten zum konfigurierten System hinzugefügt werden können. Randbedingungen können solche Dinge wie Platzzuweisung, Platzeinschluss und weitere Komponentenanforderungen regeln. Randbedingungen werden als Komponentenkennzeichen und Komponentenabhängigkeiten ausgedrückt. Randbedingungen testen die Attribute und Abstammung von Komponenten und identifizieren Komponenten, die für die erfolgreiche Instantiierung von Komponenten erforderlich sind.
Die Namen der Randbedingung und der Klasse, auf die die Randbedingung angewendet werden kann, werden in der ersten Zeile der Deklaration gekennzeichnet. Der Ausdruck „requiresComponent, „requiresContainer" und „requiresConnection" gibt jeweils zusätzliche Elemente (d. h. Komponenten, Container oder Verbindungen) an, die zur Konfiguration der Komponente mit Randbedingung erforderlich sind. Die benötigten zusätzlichen Elemente können durch eine Kombination aus dem Namen einer abgeleiteten Klasse und Ressourcen, den Namen einer abgeleiteten Klasse oder dem Namen eines Komponententyps identifiziert werden. Wenn während der Konfiguration eine Anforderung erfüllt wird, gibt die Konfigurations-Engine die Instanz des gefundenen angeforderten Komponententyps zurück. Die Variable „?ReturnedInstance" kennzeichnet die mit der Instanz des von der Konfigurations-Engine gefundenen angeforderten Komponententyps assoziierte Variable. Eine Anforderung kann weiter darum bitten, dass die Konfigurations-Engine eine Auswahl auf der Grundlage der Attributmaximierung trifft. Das bedeutet, dass die Auswahl ein gegebenes Attribut maximiert. Daher gibt eine „?ReturnedInstance.AttributeName"-Deklaration das angeforderte Element mit der größten Menge an AttributeName zurück. Die Option Attributmaximierung kann auch ein Ausdruck sein, der auf andere zurückgegebene Instanzen verweist, die von vorherigen Komponentenanforderungen mit der aktuellen Randbedingung erstellt wurden und mit ihnen Operationen ausführen. Eine Komponenteninstanz gilt als verbraucht, wenn sie nicht zur Erfüllung einer Randbedingungsforderung zur Verfügung steht. Das Schlüsselwort „Consumed" (Verbraucht) kann als Zeichen für eine Instanz angesehen werden, die von einer Instanz als nicht verfügbar zurückgegeben wurde. Wenn eine Instanz verbraucht ist, schließt die Konfigurations-Engine diese Instanz bei späteren Suchläufen zur Erfüllung einer anderen Anforderung aus. Das Schlüsselwort „Existing" beschränkt die Suche auf vorhandene Instanzen. Das Schlüsselwort „New" fordert, dass eine neue Instanz zur Erfüllung einer Randbedingungsanforderung erstellt wird.
Die Randbedingung „requiresConnection" (Verbindung erforderlich) verfügt über weitere Argumente, die die Anforderungen an den gesamten Verbindungspfad, der mehrere verschiedene Komponenten enthalten kann, beschreiben. Die Randbedingungsanforderung „requiresConnection" hat eine zusätzliche Anforderung, die sich von den Randbedingungen „requiresComponent" und „requiresContainer" unterscheidet. Wie die beiden anderen Randbedingungen erfordert „requiresConnection", dass die Anforderung erfüllt wird. Zusätzlich fordert die Randbedingung „requiresConnection", dass die Instanz mit der Randbedingung mit der erfüllenden Instanz verbunden ist.
Das Feld bzw. die Variable „StartingComponentName" verweist auf die Anfangskomponente der Verbindung (d. h. wo die Verbindung beginnt). Wenn diese Variable nicht eingestellt ist, wird die Instanz mit der Randbedingung als Anfangskomponente angenommen. Die nächste Zeile (d. h. «ClassName, ResourceName | ClassName | ComponentName») kennzeichnet die Verbindungskomponente.
Der Datentyp, den die Verbindung unterstützt, wird im Feld „DataType" angegeben. Das Feld „dataType" gibt die Datentypanforderungen eines Ports der angeforderten Instanz an. Weiterhin gibt das Feld „dataType" die Datentypanforderungen eines Ports der Instanz mit der Randbedingung an. Da das Feld „dataType" lediglich verlangt, dass die Instanz mit der Randbedingung und die angeforderte Instanz vom gleichen Datentyp sind, kann eine Verbindungsrandbedingung durch eine mehrstufige Verbindung erfüllt werden. Zum Beispiel ist es möglich, ein SCSI-Gerät durch eingreifende Komponenten an eine SCSI-Karte anzuschließen.
5 stellt die Komponentenverbindungen mit mehreren eingreifenden Komponenten und Datentypen dar. Die Instanz mit Randbedingung 161 verfügt über Port 160 und Port 162. Port 162 ist mit dem Verbinder 179 an Port 163 angeschlossen. Port 164 von Verbinderblock 179 ist an Port 165 der ersten eingreifenden Komponente 166 angeschlossen. Port 167 der ersten eingreifenden Komponente ist an Port 168 des Verbinders 180 angeschlossen. Mehrere eingreifende Komponenten 183 stellt eine Anzahl von eingreifenden Komponenten dar, die zwischen der ersten eingreifenden Komponente 166 und der n-ten eingreifenden Komponente 173 angeordnet werden können. Verbinder 180 und Verbinder 181 sind an den beiden Enden der mehreren eingreifenden Komponenten 183 angeordnet. Port 171 des Verbinders 181 ist an Port 172 der n-ten eingreifenden Komponente 173 angeschlossen. Port 174 ist an Port 175 des Verbinders 182 angeschlossen. Port 176 des Verbinders 182 ist an Port 177 der Diskettenlaufwerksteuerung 178 angeschlossen. Die Kette 184 stellt den verketteten Kommunikations- oder Verbindungspfad zwischen der Instanz mit Randbedingung 161 und der Diskettenlaufwerksteuerung 178 dar.
Die Felder „?ReturnedInstance" und „?ReturnedInstance.AttributeName" haben die gleiche Funktionalität wie bei den Randbedingungsausdrücken „requiresComponent" und „requiresContainer". Die Variable „%Path" ist an alle Instanzen gebunden, mit denen die Verbindung hergestellt wird. Das heißt, dass alle in die Verbindung einbezogenen Instanzen als Verbindungspfad bezeichnet werden.
Hinsichtlich der Instanzvariablen „?ReturnedInstance.AttributeName" und „?ReturnedInstance" ist die Maximierungsoption die gleiche wie für die Randbedingungen „requiresComponent" und „requiresContainer". Für die Pfadinstanzvariable gibt es zwei Maximierungsoptionen. Die erste Option ist der Verbinder. Das Feld „ClassName" gibt die gewünschte Klasse der zur Einrichtung des Pfades genutzten Verbinderinstanzen an. Das Feld „?ConnectorInstance" ist an die zurückgegebene Verbinderinstanz gebunden und „AttributeName" ist das zu maximierende Verbinderinstanzattribut. Die Anforderung für „?ConnectorInstance" wird auf die gleiche Weise maximiert wie die zurückgegebenen Instanzen für „requiresComponent" und „requiresContainer".
Die zweite Maximierungsoption von „requiresConnection" ist die Pfadlängenoption. Diese Option bietet die Möglichkeit, Auswahlen unter Pfaden nach Priorität zu ordnen. Die Pfadlänge wird durch die Anzahl an Komponenteninstanzen im Pfad einschließlich Instanzen der Klasse Verbinder definiert. Der längste Pfad wird durch das Schlüsselwort „Longest" in der Randbedingungsdeklaration angegeben. Wenn die Option des längsten Pfades nicht gewählt wurde, wählt die Konfigurations-Engine den kürzesten Pfad.
Die Angaben „Consumed", „Existing" und „New" der Randbedingung „requiredConnection" haben die gleiche Funktionalität wie in den Randbedingungsdeklarationen „requiresComponent" und „requiresContainer". Die Option Konvertierungen bietet die Möglichkeit anzugeben, dass die angeforderte Instanz einen anderen Datentyp als die Instanz mit Randbedingung haben kann. Wenn diese Option gewählt wird, braucht der Port auf der angeforderten Seite keine Daten des Datentyps „dataType" zu unterstützen. Die einzige Anforderung besteht darin, dass der in der Variable „dataType" angegebene Datentyp am Port der Anforderungsseite verfügbar ist. Die Option erweitert die Alternativen, die die Konfigurations-Engine bei der Erfüllung der Verbindungsanforderung berücksichtigen darf, denn diese braucht nun nicht mehr eine Abschlusskomponente mit dem gleichen Datentyp wie die Anforderungsinstanz zu wählen. Wenn also eine Verbindungsrandbedingung Konvertierungen zulässt, brauchen zur Erfüllung einer Anforderung nach einer SCSI-Verbindung nur SCSI-Daten an die anfordernde Instanz gesendet zu werden.
Beispiel für eine Randbedingungsdefinition:
Die Randbedingung „requiresContainer" (Container erforderlich) gibt an, dass der Komponententyp Speichergerät einen Container (d. h. einen Einbaurahmen) erfordert. Zusätzlich erlegt diese Randbedingungsdefinition der Klasse Speichergerät in der Modellhierarchie und allen ihren Deszendenten eine Randbedingung auf. Sie erfordert die längste Kabelkomponententypverbindung zu einem SCSI-Karten-Komponententyp. Der von dieser Verbindung unterstützte Datentyp heißt „SCSIDatatype". Ein Port der Instanz mit Randbedingung muss also diesen Datentyp unterstützen. Die Datentyprandbedingungen lassen sich mit einer mehrstufigen Verbindung erfüllen. Daher muss das SCSI-Speichergerät über eingreifende Komponenten an die SCSI-Karte angeschlossen sein. Die Variable „?card" kennzeichnet die verwendete SCSI-Karteninstanz. Die Variable „%path" enthält Informationen zu den für die Herstellung der Verbindung verwendeten Instanzen.
Die Modellsprache ermöglicht die Durchführung weiterer Tests und Abfragen, um zu gewährleisten, dass die Konfigurations-Engine verwendbare Instanzen oder Instanzenmengen zurückgibt. Wenn eine Randbedingung eine Komponentenanforderung enthält, werden diese Tests und Abfragen hinter dieser Anforderung angeordnet. Wenn die Abfragen und Tests nicht erfüllt werden, sucht die Konfigurations-Engine weiter nach einer anderen Alternative zur Erfüllung der Anforderung. Es folgen Beispiele für den in der Modellsprache gelieferten Test: Mathematische Operatoren:

+: (Addition)
–: (Subtraktion)
*: (Multiplikation)
/: (Division)
ABS: (Absolutwert)
SQRT: (Quadratwurzel)

Relationale Operatoren:

>

(größer als)

<

(kleiner als)

=

(gleich)

>=

(größer als oder gleich)

<=

(kleiner als oder gleich)

!=

(ungleich)

Boolesche Operatoren:

OR

(logisch inklusives oder)

AND

(logische Konjunktion)

NOT

(logische Negation)

Zuweisungsoperator:

:=

(wird zu, nimmt den Wert an von)

Zum Beispiel kann beim Konfigurieren eines Computersystems ein Test zur Konfiguration eines Diskettenlaufwerks für das Computersystem ausgeführt werden. Ein Diskettenlaufwerk erfordert einen Einbaurahmen oder -platz im Systemschrank. Eine solche Randbedingung würde als eine Komponentenanforderung „requiresContainer" ausgedrückt. Diese Anforderung würde die Konfigurations-Engine dazu veranlassen, nach einer Kandidateninstanz zur Erfüllung der Anforderung zu suchen. Wenn die Engine die Kandidateninstanz (d. h. „?bay") zurückgibt, können weitere Tests durchgeführt werden, um festzustellen, ob das Laufwerk in die zurückgegebene Instanz passt. Dies kann durch Vergleich der Höhenattributwerte der Kandidateninstanz (d. h. „?bay") und der Instanz mit Randbedingung (d. h. „?this") wie folgt erfolgen:
?bay.height >= ?this.height
Interne Standardfunktionen bieten zusätzliche Test- und Abfragemöglichkeiten.
Interne Standardfunktionen lassen sich in Abfrage- und Prädikatfunktionen unterteilen. Beispiele für Abfragefunktionen:

ceil: Fragt ein Attribut vom Typ Gleitkomma oder einen Ausdruck, der einen Gleitkommawert bewertet, nach dem kleinsten ganzzahligen Wert größer als oder gleich dem Gleitkommawert ab. Gibt eine ganze Zahl zurück. Syntax: ceil («Ausdruck»)
ClassName: Fragt eine Sollvariable nach allen in der Menge enthaltenen Instanzen ab, die zur angegebenen Klasse gehören. Syntax: ClassName («%InstanzMenge»)
ComponentName: Fragt eine Sollvariable nach allen in der Menge enthaltenen Instanzen ab, die zum angegebenen Komponententyp (z. B. Blattklasse) gehören. Syntax: ComponentName («%ZurückgegebeneInstanz»)
Component: Fragt eine Sollvariable nach allen Instanzen ab, die nicht Deszendenten der Klasse Verbinder sind. Syntax: ClassName («%InstanzMenge»)
component,: Fragt eine Instanz nach dem Komponententyp (d. h. der Klassenhierarchie-Blattklasse) ab, deren Deszendent sie ist. Gibt den Parent-Komponententyp zurück. Syntax: component («%Zurückgegebenelnstanz»)
COUNT: Fragt eine Sollvariable nach allen in der Menge enthaltenen Instanzen ab, die zur angegebenen Klasse gehören. Syntax: COUNT («ClassName ComponentTypeName» «(%InstanzMenge)»)

Beispiel für eine Randbedingungsdefinition mit Abfrage- und Prädikatfunktionalität:
In diesem Beispiel erfordert Storage_Device eine Verbindung zu einer Komponente vom Typ „SCSICard". Die Verbindung muss den Datentyp „SCSIDatatype" aufweisen. Die Komponenteninstanz vom Typ „SCSICard" ist an die Instanzvariable „?card" gebunden, und die Komponenten im Verbindungspfad sind (als Menge) an die Sollvariable „%path" gebunden. Die Verbinderkomponente zur Einrichtung der Verbindung muss den Typ „Cable" haben und ist an die Instanzvariable „?c" gebunden. Kandidatenkabel werden vom kürzesten zum längsten angefordert und bei Vorhandensein von Alternativpfaden von der SCSICard-Instanz wird der längste Pfad (mit der größten Anzahl an Komponenten) bevorzugt.
Dieses Beispiel gibt an, dass das Storage_Device in einer Containerkomponente vom Typ „Bay" untergebracht werden muss. Die Instanz vom Typ „Bay" muss die Bay_Resource versorgen. Die Instanz vom Typ „Bay" ist an die Instanzvariable „?bay" gebunden, und die Instanz ist als „consumed" (d. h. nicht verfügbar für spätere Komponentenanforderung vom Typ Bay) gekennzeichnet.
Im Beispiel erfordert die Wortgruppe „ancestor (?bay, Cabinet) == ancestor (?card, Cabinet", dass der strukturelle Vorgänger (vom Typ Schrank) der durch „?bay" gekennzeichneten Instanz die gleiche Instanz wie der strukturelle Vorgänger (vom Typ Schrank) der durch „?card" gekennzeichneten Instanz sein muss. Mit anderen Worten müssen sich Karte und Einbaurahmen im gleichen Schrank befinden.
Die im vorigen Beispiel verwendete Wendung „Forall" gibt an, dass alle Komponenteninstanzen vom Typ Storage_Device, die am ersten Kabel in „%path" angeschlossen sind, im gleichen Schrank wie die Instanz von Storage_Device mit Randbedingung untergebracht sein müssen.
Randbedingungsbeziehungen können entweder auf Komponenten- oder auf Klassenebene hergestellt werden. Auf Komponentenebene geben Randbedingungsbeziehungen an, welche Komponententypen welchen Randbedingungen unterliegen. Die in der Randbedingungsbeziehung bezeichnete Komponente kann jedem der von einer Komponententypdeklaration definierten Komponententypen angehören. Die Randbedingung kann eine durch eine Randbedingungsdeklaration deklarierte Randbedingung sein. Syntax für die Angabe einer Randbedingung auf Komponentenebene:
Randbedingungen können auch auf Klassenebene ausgedrückt werden. Eine Randbedingung auf Klassenebene wird als Konjunkt in Ausdrücken von Randbedingungen auf Komponentenebene für alle von der Klasse mit Randbedingung abgeleiteten Komponententypen bewertet. Wenn ein Ausdruck auf Komponentenebene bewertet wird, werden Randbedingungen auf Klassenebene an den Beginn des Randbedingungsausdrucks angehängt und enden mit der Anforderung dieser Randbedingung und Prädikatfunktionausdrücken. Wenn eine Komponente die Randbedingungen auf Klassenebene von verschiedenen Ebenen in der Klassenhierarchie erbt, werden die Randbedingungen von der primitivsten Klasse (d. h. der Wurzelklasse-Komponente) zur systemspezifischsten Klasse (d. h. dem benutzerdefinierten Komponententyp) angefordert. Die Syntax für die Deklaration einer Randbedingungsbeziehung auf Klassenebene lautet wie folgt:
constrain class «ClassName» with «ConstraintName»
Die vorliegende Erfindung bietet die Möglichkeit, in einer strukturellen Hierarchie mit drei Substrukturtypen darzustellen, wie Komponenten eines bestimmten Systems räumlich und physisch existieren: Verbundgruppenhierarchien, Container-Hierarchien und Verbindungsbeziehungen. Verbundgruppenhierarchien identifizieren Komponenten als Teil anderer Komponenten. Container-Hierarchien identifizieren Komponenten als in anderen Komponenten enthalten. Verbindungsbeziehungen identifizieren Komponenten, die Verbindungen zu anderen Komponenten herstellen. Die Beziehungen zwischen Generationen innerhalb dieser Strukturhierarchie werden durch die Schlüsselwörter „childOf, „containedBy" und „connectsWith" ausgedrückt. Strukturbeziehungen werden wie folgt deklariert:
«ClassName» childOf «ClassName»
«ClassName» containedBy «ClassName»
«ClassName» connects With «ClassName»
MODELLUNTERHALTUNG
Ein Modell kann durch Anweisungen definiert werden, die in ihrer Syntax der oben beschriebenen Modellsprache entsprechen. Weiterhin bietet eine interaktive Einrichtung, das Subsystem Modellunterhaltung, die Möglichkeit, ein Modell mit einer grafischen Benutzeroberfläche zu definieren und zu unterhalten. Das Subsystem Modellunterhaltung bietet die Möglichkeit, die Produktbasis interaktiv mit einer grafischen Benutzeroberfläche zu definieren. Die semantischen Darstellungen, Klassenhierarchien und Strukturhierarchien des Modells können mit einer grafischen Benutzeroberfläche interaktiv angezeigt (d. h. durchsucht) und modifiziert (d. h. bearbeitet) werden. Außerdem wird die Eingabe von Randbedingungen überprüft. Es werden Test- und Debugging-Möglichkeiten angeboten, um Probleme im Modell zu erkennen und die Leistung des modifizierten Modells zu testen und zu optimieren. Zum Beispiel wird die Modelldefinitionssyntax geparst und geprüft und es werden Musteranforderungen ausgeführt. Zur Überwachung der Leistung der Konfigurationsanforderungen im modifizierten Modell können Diagnosefunktionen aufgerufen werden.
Die Durchsuchfähigkeit des Unterhaltungssystems bietet die Möglichkeit, grafische Darstellungen der Klassen und Substrukturkomponenten der Modellhierarchie anzuzeigen. Es wird auch ein Klassenbaum zur Darstellung der Deszendenten von Grundklassen in der Modellhierarchie (d. h. eine Objektklassenhierarchie) verwendet. Die Objektklassenhierarchie wird durch fünf separate Bäume, einen für jede Grundklasse, dargestellt. Jeder Zweig kann mehrere Deszendenten aufweisen.
Mit einem Komponentenbaum werden die substrukturellen Beziehungen von Verbundgruppen-, Verbinder- und Container-Komponenten dargestellt. Verbundgruppenbäume werden zuerst aufgeführt, gefolgt von Verbinder- und Container-Bäumen.
Ein Hierarchiemitglied kann durch Doppelklick auf das Feld, das das Hierarchiemitglied enthält, zur Modifikation ausgewählt werden. Es wird ein Bearbeitungsfenster für die gewählte Hierarchie angezeigt. Es kann auch ein Listenmenü zur Auswahl des zu bearbeitenden Mitglieds verwendet werden. In einer bevorzugten Ausführungsform bestehen die Listenmenüs aus einer Reihe von Pulldown-Menüs, die aus der Menüleiste des Fensters „Unterhaltung" ausgewählt werden können. Die ursprüngliche Menüleiste enthält eine Auswahl für jedes allgemeine Element des Produktbasismodells (d. h. Klassen, Komponententypen, Randbedingungen usw.). Wenn ein allgemeines Element ausgewählt wird, wird ein neues Fenster angezeigt, das die Modellmitglieder dieser allgemeinen Typauswahl auflistet. Ein Modellmitglied kann zusammen mit einer Operation (d. h. Kommentar, Anzeigen, Neu oder Bearbeiten) ausgewählt werden. Eine Kommentar-Operation ermöglicht das Hinzufügen eines Kommentars zur Produktbasis nach dem ausgewählten Mitglied. Die Operation „Anzeigen" bietet die Möglichkeit, die Einstellungen für ein gewähltes Modellelement anzuzeigen. Das Modellmitglied kann durch Auswahl der Operationen „Neu" oder „Bearbeiten" modifiziert werden.
Zum Modifizieren eines Attributs eines Modellmitglieds wird in der bevorzugten Ausführungsform zum Beispiel der Attributtyp aus dem Listenmenü gewählt. Wenn die Attribute angezeigt werden, kann eine Operation „Neu" oder „Bearbeiten" gewählt werden, um ein neues Attribut hinzuzufügen bzw. ein vorhandenes Attribut zu modifizieren. Eine Attributauswahl muss auch erfolgen, wenn die Operation „Bearbeiten" gewählt wird. Nach dieser Auswahl wird das Fenster „Attribut-Editor" angezeigt. Die Felder des Fensters (z. B. Name, Attributtyp und Mehrwertig) sind ursprünglich entweder leer oder enthalten die Standardeinstellungen für eine Neu-Operation bzw. die aktuellen Attributeinstellungen für eine Bearbeiten-Operation. Das Feld „Attributname" kann gewählt und modifiziert werden. Das Typfeld kann durch Auswahl aus einer Liste gültiger Attributtypen modifiziert werden. Das Feld „Mehrwertig" lässt sich aktivieren und deaktivieren. Nach dem Vornehmen der Modifikationen können diese gespeichert oder abgebrochen werden.
Ressourcen und Datentypen können auf die gleiche Weise wie die Erstellung und Modifikation eines Attributs hinzugefügt oder modifiziert werden. Modellelemente, die relationale Definitionen erfordern, benötigen zusätzliche Bezeichnungen. Beispiele hierfür sind abgeleitete Klassen, Produktlinien (d. h. Parent-Produktlinie), Randbedingungen (d. h. Klasse mit Randbedingungen) und Komponententypen.
In der bevorzugten Ausführungsform erfordert das Hinzufügen einer abgeleiteten Klasse einen zusätzlichen Anfangsschritt zur Definition der Position der neuen abgeleiteten Klasse in der Modellhierarchie. An dieser Stelle haben die Operationen „Neu" und „Bearbeiten" die gleichen Operationscharakteristika, einschließlich der Möglichkeit, zu speichern oder abzubrechen. Das heißt, die abgeleiteten Feldwerte (vorhanden, Standard oder leer) werden in einem Editor-Fenster angezeigt. Außerdem können allen Mitgliedern der abgeleiteten Klassen und deren Komponententypen Attribute hinzugefügt werden; Randbedingungen können auf Klassenebene für die abgeleitete Klasse angegeben werden; strukturelle Hierarchiebeziehungen können für die abgeleitete Klasse definiert werden; der Anzeigestatus des Anzeigefensters kann definiert werden; die abgeleitete Klasse kann als Verbindungsursprung (d. h. als Ausgangspunkt für einen Kabelbericht) gewählt werden; und der Komponentenabstand (d. h. der durchschnittliche Abstand von Mitgliedern der abgeleiteten Klasse zu anderen zur gleichen Verbundgruppe gehörenden Objekten sowie der Abstand vom Mitglied der abgeleiteten Klasse zum externen Port auf der Verbundgruppe) für untergeordnete Elemente der in die Verbindungen einbezogenen Verbundgruppenobjekte definiert werden.
Zum Hinzufügen einer neuen Komponente zum Modell muss die Klasse gewählt werden, deren Deszendent die neue Klasse ist. Das Feld „Subkomponente" bietet die Möglichkeit, die Strukturhierarchie (d. h. strukturell untergeordnete Elemente) einer Verbundgruppenkomponente anzugeben. Die Operationen „Neu" oder „Bearbeiten" bieten ferner die Möglichkeit, Connectivity-Felder wie Transfers (d. h. Pfade, auf denen sich Daten durch eine Verbundgruppenkomponente bewegen können), Datentyp, Verbindungsursprung anzugeben. Weiterhin können die folgenden Feldinformationen angegeben werden: Name des Komponententyps, zugehörige Attribute, Produktlinien (d. h. Produktlinien, die diese Komponente enthalten), Randbedingungen auf Blattebene, Ressourcen, Beschreibung, Bezeichnung, Teilenummer, Füllrichtung und Anzeigestatus.
Das Unterhaltungssystem bietet ferner die Möglichkeit, ein modifiziertes System zu testen. Die Option „Write-Integrität" legt fest, ob eine Parse-Datei (d. h.) geparst werden und eine modifizierte Parse-Datei geschrieben werden kann. Die Option „ProductBase-Integrität" legt fest, ob eine Parse-Datei (d. h.) geparst werden und eine modifizierte Parse-Datei geschrieben werden kann. Wenn nicht, werden Syntaxfehlermeldungen angezeigt. Die Debugger-(d. h. Konfigurier-)Option liest Komponentenanforderungen aus einer Anforderungsdatei und versucht, diese Komponenten mit den gewählten Randbedingungen in der aktuellen Parse-Datei zu konfigurieren. Der Debugger bietet eine Verfolgungsgmöglichkeit für Randbedingungen. Eine Tiefenverfolgung erzeugt Verfolgungsausgaben für eine verfolgte Randbedingung und alle von ihr erzeugten Randbedingungen. Eine flache Verfolgung erzeugt eine Verfolgungsausgabe für verfolgte Randbedingungen.
BEDARFSANALYSE
Der Prozess der Umsetzung von Kundenanforderungen in spezifische Komponenten und Konfigurationen wird als „Bedarfsanalyse" bezeichnet. Die Modellsprache bietet die Möglichkeit, ein Modell in Form von Kundenbedürfnissen und -anforderungen auszudrücken.
Mit einem Bedarfsanalyseansatz zur Modellbildung kann die Konfiguration auch in Form von Kapazitäten (d. h. erforderliche Mindestreaktionszeiten) oder Durchsatz ausgedrückt werden. Die Bedarfsanalysenkonfiguration kann mit einem Sprachnachrichten-Systemmodell veranschaulicht werden. Ein konfiguriertes Sprachnachrichtensystem kann eine bestimmte Anzahl an Stunden von Sprachdaten aufzeichnen und muss eine Reaktionszeit von unter fünf Sekunden für den Zugriff auf gespeicherte Nachrichten bieten müssen. Zur weiteren Veranschaulichung kann eine Telekommunikationskonfiguration in Form von Anrufaufkommen und höchstzulässigen Fehlleitungen (z. B. abgebrochene Anrufe) angegeben oder eine Computersystemkonfiguration erforderlich sein, um bestimmte Verarbeitungslasten, Datenspeichererfordernisse oder Reaktionszeiten zu unterstützen.
Die Modellsprache bietet die Möglichkeit, ein Bedarfsanalysemodell in der Konfigurationsmodelliersprache durch folgende Elemente auszudrücken: (1) Interpretation der Kundenanforderungsmengen (z. B. Sprachnachrichtenspeicherkapazität) und (2) Identifzierung der zugehörigen Mengen an Konfigurationskomponenten und Ressourcen. Dies ermöglicht das Erstellen von Modellanforderungen in Form von Bedarf zusätzlich zu Komponentenanforderungen. Komponenten können als Anforderungen oder Bedürfnisse befriedigend identifiziert werden. Das heißt, die Komponenten können als Lieferanten von einer Menge an Ressourcen (z. B. Megabytes an Speicherkapazität) identifiziert werden. Wenn ein Benutzer ein System oder einen Teil davon als Bedürfnisse oder Anforderungen ausdrückt, kann eine oder können mehrere Komponente(n) aus der Produktbasis gewählt werden.
EINGABEFORMULARE
Eingabeformulare bieten die Möglichkeit, Komponentenanforderungen vom Benutzer zu akzeptieren. Eingabeformulare gestatten dem Benutzer, die im System zu konfigurierenden Typen und Mengen von Komponenten anzugeben. Eingabeformulare bestehen aus Standardfensterformaten wie Listenfeldern und Schaltflächen. Eine dritte Art von Eingabeformularen bietet die Möglichkeit, eine Menge einer gegebenen Komponente anzugeben (Hinweis: Dokumentation bezeichnet dies als einzigartig...brauchen wir für diese Anmeldung mehr über dieses Merkmal?) Die Benutzerauswahlen auf den Eingabeformularen werden als Komponentenanforderungen bezeichnet. Eingabeformulare bieten die Möglichkeit, eine Standardpriorität für Komponentenanforderungen zuzuweisen. Standardprioritäten können von einer Anforderungspriorität (requestPriority) außer Kraft gesetzt werden. Diese Prioritäten bieten die Möglichkeit, die Reihenfolge anzugeben, in der Komponentenanforderungen von der Konfigurations-Engine erfüllt werden.
PRODUKT-KOMPONENTEN-ZUORDNUNGEN
Produkt-Komponenten-Zuordnungen definieren diskrete und zusammengesetzte Komponenten als Teile und Produkte in einem Verkaufsbestand und ordnen diese Teile und Produkte (d. h. Bündel) einer Menge aller Komponenteninstanzen in einem konfigurierten System zu. Die Produkt-Komponenten-Zuordnung enthält Darstellungen, die die einzelnen Teile und Produkte als angeforderte und optionale Bestandkomponenten definieren. Diese Darstellungen spezifizieren weiter, wie die Produkte in der Angebotserstellung angezeigt werden. Eine Darstellung besteht aus folgenden Abschnitten: Produkt-Header, Liste optionaler Geräte und Optionsrestriktionsliste.
Der Abschnitt „Produkt-Header" liefert den Produktnamen, wie er in der Produktbasis erscheint. Dies ermöglicht dem Paketierer, Komponenten in einem konfigurierten System mit Produkten abzustimmen und eine Satzzuordnung zu erkennen. Dieser Abschnitt umfasst auch die folgenden Zusatzinformationen: einen Produktbeschreibungs-String, der das Produkt für die Nutzung durch andere Teile der Erfindung (z. B. die Angebotserstellung) beschreibt; einen Produktnummern-String; den Preis (d. h. den Preis des Produkts); ein Produktlinien-String kennzeichnet die Produktlinien, denen das Produkt angehört und wird zur Eingrenzung der Satzzuordnungsuche verwendet; und eine Liste erforderlicher Komponenten, die für dieses Produkt erforderliche Komponenten (d. h. nach Teilenummer) oder Produkte (d. h. nach Produktnummer) angibt.
Die Liste optionaler Geräte führt zusätzliche Produktpakete auf, die in das Basispaket (d. h. das im Produkt-Header beschriebene Produkt) aufgenommen werden können. Ein Listeneintrag für optionale Geräte enthält: eine optionsspezifische ID zur eindeutigen Kennzeichnung des Eintrags; eine Optionsbeschreibung zur Beschreibung des Eintrags; eine Zusatzkostenangabe, die die Extrakosten bei Aufnahme dieses Eintrags aufführt; und eine Konstituentenproduktnummernliste, die die zum Eintrag gehörenden Produkte oder Komponenten nach deren Nummer angibt.
Bei der Optionsrestriktionsliste handelt es sich um eine Liste mit Optionengruppen, die voneinander abhängig sind und nach besonderen Kriterien gewählt werden müssen. Jeder Listeneintrag umfasst Folgendes: eine gruppenspezifische ID zur eindeutigen Kennzeichnung des Eintrags, eine Mengenangabe und eine optionsspezifische ID-Liste. Das Mengenangabefeld gibt die Anzahl an Mitgliedern einer Optionsgruppe an, die gewählt werden können oder müssen. Das Mengenangabefeld weist Grenzen oder Schlüsselwörter wie „atLeastOne" (mindestens ein), „atMostOne" (höchstens ein) oder „exactlyOne" (genau ein) auf. Die Grenzen sind zwei ganze Zahlen (in Klammern und durch Komma getrennt), die die obere und untere Grenze angeben. Das Schlüsselwort „atLeastOne" gibt an, das ein Mitglied der Optionsgruppe gewählt werden muss. Das Schlüsselwort „atMostOne" gibt an, dass nur ein Mitglied der Gruppe gewählt werden darf und kein Mitglied gewählt werden muss. Das Schlüsselwort „exactlyOne" gibt an, dass mindestens ein Mitglied der Optionsgruppe gewählt werden muss, doch nicht mehr als eines gewählt werden darf. Die Liste optionsspezifischer IDs ist eine durch Leerzeichen getrennte Liste optionsspezifischer IDs.
Beispiel für einen Eintrag in eine Produkt-Komponenten-Zuordnung für ein Modell zur Konfiguration von Computersystemen:
PAKETIERER
Der Paketierer bündelt Komponenten in Produkt-(d. h. Marketing-)Pakete. Der Paketierer verwendet die Produkt-Komponenten-Zuordnung, um eine Satzzuordnung für ein konfiguriertes System aufzustellen. Bei einer Satzzuordnung handelt es sich um eine Menge von Viel-zu-Eins-Entsprechungen von Komponenteninstanzen in einem konfigurierten System mit den Produktpaketen, wobei die einzelnen Komponenteninstanzen jeweils einem Produktpaket zugeordnet werden.
Die Satzzuordnung bezeichnet den Prozess der Zuordnung einer Objektmenge (z. B. Komponenteninstanzen in einer Konfiguration) zu einer Menge von Oberbegriffen (z. B. Produkten). Mit diesem Prozess werden Komponenten für die aktuelle Konfiguration mit einer gewissen Gruppenzuordnung oder Einordnung (z. B. Produkte) erstellt. Ein mit der Satzzuordnung verbundenes häufiges Problem besteht darin, dass bei einer Erhöhung der Anzahl an Objekten und Satzzuordnungsalternativen die Anzahl dieser Alternativen exponentiell anwächst. Zur Begrenzung der Satzzuordnungsalternativen können heuristische Verfahren zur Bestimmung einer Mindestsatzzuordnung eingesetzt werden. Ein Beispiel für eine heuristische Anwendung ist die preisgünstigste Zuordnung. Mit diesem Verfahren werden die Zuordnungen maximiert und die Kosten minimiert. Das heißt, die Produkte, die die größte Zuordnung bei geringsten Kosten bieten, werden ausgewählt.
Ein weiteres heuristisches Verfahren basiert auf dem strukturellen Kontext der Alternativen. In einigen Fällen hat ein Produkt eine Struktur, die eine physische Einheit oder Gruppierung von Komponenten definiert. Dies kann zum Beispiel geschehen, wenn eine Senkung der Fertigungskosten durch Fertigung der Komponenten als Einheit erzielt wird. Diese Einsparungen können an den Käufer eines Systems weitergegeben werden, wo das kostenreduzierte System tatsächlich gekauft wird. Es ist daher erforderlich, die konfigurierten Komponenten zur Bestimmung von deren strukturellem Kontext zu untersuchen und dann die Attribute dem Strukturkontext der Produkte zuzuweisen. Ein Beispiel ist die Festplattenanordnung in einem Computerkonfigurationsmodell. Die Festplattenanordnung ist physisch konfiguriert oder gefertigt, mit einem Gestellrahmen, Stromversorgung, Steuerung und fünf Laufwerken. Es muss daher der Strukturkontext von Laufwerksanforderungen untersucht werden. Der Prozess der Auswahl von Instanzen als durch die Laufwerksanordnung „abgedeckt" muss die Feststellung einbeziehen, dass die „abgedeckten" Instanzen im Gestellrahmen oder als Laufwerksanordnung zu konfigurieren sind.
10 stellt den Ablauf des Prozesses EstablishSetCover (Abdeckung einrichten) dar. An Verarbeitungsblock 450 werden die Produkte erkannt, die manche oder alle Komponenteninstanzen in der aktuellen Konfiguration abdecken können. Wenn bei Entscheidungsblock 452 (d. h. „Wurden Produkte erkannt?") keine Produkte erkannt wurden, endet die Verarbeitung bei Block 454. Wenn Produkte erkannt wurden, werden diese anhand der Instanzenanzahl, die das Produkt abdecken kann, in Verarbeitungsblock 456 priorisiert. Wenn bei Entscheidungsblock 458 (d. h. „Sind Instanzen nicht abgedeckt?") alle Instanzen der aktuellen nach Prioritäten geordneten Produktliste zugeordnet wurden, wird eine neue Produktliste erstellt, die Produkte in der aktuellen Konfiguration in Block 474 abdeckt, und die Verarbeitung wird bei Entscheidungsblock 452 (d. h. „Wurden Produkte erkannt?") fortgesetzt.
Wenn nicht, wird bei Block 460 das nächste Produkt aus der Liste gewählt. Wenn bei Entscheidungsblock 462 (d. h. „Existieren alle Elemente?") nicht alle Elemente des Produkts im konfigurierten System existieren, wird die Verarbeitung bei Verarbeitungsblock 460 fortgesetzt. Wenn sie existieren, werden zuvor nicht zugeordnete, aber vom aktuellen Produkt abdeckbare Instanzen in Verarbeitungsblock 464 erkannt. Wenn bei Entscheidungsblock 466 (d. h. „Instanzen erkannt?") keine Instanzen vom Produkt abgedeckt werden können, wird die Verarbeitung bei Entscheidungsblock 458 (d. h. „Sind Instanzen nicht abgedeckt?") fortgesetzt.
Wenn einige Instanzen erkannt wurden, wird ermittelt, ob eventuell bei Entscheidungsblock 468 (d. h. „Gibt es unerfüllte Produktoptionsrandbedingungen?") Produktoptionsrandbedingungen nicht erfüllt werden können. Wenn das der Fall ist, wird die Verarbeitung bei Entscheidungsblock 458 (d. h. „Sind Instanzen nicht abgedeckt?") fortgesetzt. Wenn nicht, wird die Verarbeitung bei Entscheidungsblock 470 (d. h. „Alle strukturellen Kontexte erkannt?") fortgesetzt. Wurden diese nicht erkannt, wird die Verarbeitung bei Block 460 fortgesetzt und das nächste Produkt herangezogen. Wenn ja, werden die zugeordneten Komponenteninstanzen bei Block 472 als durch das aktuelle Produkt abgedeckt markiert und die Verarbeitung bei Entscheidungsblock 458 (d. h. „Sind Instanzen nicht abgedeckt?") fortgesetzt.
DARSTELLUNG DES MODELLIERTEN SYSTEMS
Wenn ein System auf der Basis der gestellten Anforderungen konfiguriert wurde, werden verschiedene Berichts-Tools angewendet, um Informationen über das konfigurierte System zu erhalten. In der bevorzugten Ausführungsform umfassen diese Tools eine grafische Darstellung der allgemeinen Systemanordnung, eine Materialliste, eine Ersatzteilliste sowie eine Liste von Komponentenanforderungen, die nicht erfüllt werden konnten.
Die vorliegende Erfindung bietet die Möglichkeit, ein Modell in Strukturbegriffen auszudrücken. Das heißt, dass Komponenten durch ihre strukturell übergeordneten Elemente (Parents, z. B. Container), Verbindungen und Zusammensetzungen definiert werden. Daher ist die vorliegende Erfindung in der Lage, das konfigurierte System gemeinsam mit seinen Strukturmerkmalen grafisch anzuzeigen.
Die grafische Darstellung des konfigurierten Systems und seiner Strukturmerkmale wird als Systemfenster bezeichnet und bietet eine Abbildung der allgemeinen Anordnung des konfigurierten Systems. In der bevorzugten Ausführungsform zeigt das Systemfenster für ein Modell zur Konfigurierung von Computersystemen das Innere und die Frontseite aller im System verwendeten Schränke sowie die Anordnung der Karten, Stromversorgungen und Speichergeräte an. 11 stellt ein Systemfenster für eine Konfiguration eines Desktop-Computersystems dar. Das Systemfenster 540 zeigt die Komponenten des konfigurierten Systems und deren relative Anordnung im System an. Der Gestellrahmen 550 enthält die Systemplatine 552, den Laufwerkkäfig 554 und die Stromversorgung 556. Die Hauptplatine 552A ist eine Detaildarstellung der Systemplatine 552.
Die Hauptplatine 552A veranschaulicht die physische Anordnung anderer Komponenten auf der Systemplatine und deren relative Position. Zum Beispiel befindet sich die EVGA-Grafikkarte 558 unter der CPU-Platine 560. Weiterhin ist die Anordnung der Netzwerkkarte 562 und FAST-SCSI 564 in Einbauplätzen relativ zur CPU-Platine 560 im Systemfenster 540 ersichtlich. Freie Einbauplätze 566 werden offen dargestellt und liegen am nächsten zur CPU-Platine 560. Die Speichererweiterungsplatine 568A ist eine Detaildarstellung der Speichererweiterungskarte 568. 1 M Simm-Chips 570 sind auf der Speichererweiterungsplatine 568A angeordnet. Acht Speicherbänke 572 bleiben ungenutzt. Der Laufwerkkäfig (Seitenansicht) 554A ist eine Detaildarstellung des Laufwerkkäfigs 554. Ein Festplattenlaufwerk 535 MB (SCSI) 574, ein Diskettenlaufwerk 3,5'' 1,44 MB 576 und ein Bandlaufwerk zur Datensicherung 525 MB (SCSI) 578 befinden sich im Laufwerkkäfig 554. Die Frontplatte 580 zeigt die Lage der Frontseite des Laufwerkkäfigs (Seitenansicht) 554A. Das Diskettenlaufwerk 3,5'' 1,44 MB 576 und das Bandlaufwerk zur Datensicherung 525 MB 578 wurden als frontseitig zugängliche Komponenten konfiguriert. Der Einbaurahmen 582 ist ein frontseitig zugänglicher Einbaurahmen, der kein Gerät enthält. Der Einbaurahmen 584 ist ein freier Einbaurahmen im hinteren Bereich des Laufwerkkäfigs 554.
Das Systemfenster bietet auch die Möglichkeit, die grafisch dargestellten Strukturen interaktiv zu bearbeiten. Die vorliegende Erfindung bietet die Möglichkeit, strukturelle Aspekte des konfigurierten Systems durch Hinzufügen, Löschen oder Ersetzen von Komponenten in der konfigurierten Struktur zu modifizieren. Die vorliegende Erfindung bietet außerdem die Fähigkeit, die konfigurierte Struktur durch Änderung der strukturellen Verbindungen und Zusammensetzungen zu modifizieren.
Diese Fähigkeit zur grafischen Anzeige und Bearbeitung kann für neu konfigurierte Systeme und für vorhandene Konfigurationen oder Systeme genutzt werden. Das heißt, dass sämtliche Upgrades bei einem vorhandenen konfigurierten System grafisch ausführbar sind. Eine Fähigkeit zum „Einfrieren und Füllen" (Freeze and Fill) gestattet dem Benutzer, einen Teil des vorhandenen Systems einzufrieren und den nicht eingefrorenen Teil zu füllen bzw. zu modifizieren. Diese „Freeze and Fill"-Fähigkeit bietet außerdem die Möglichkeit, ein Angebot für die neue Konfiguration zu erstellen, das lediglich die zur Originalkonfiguration hinzugefügten Komponenten enthält und eventuelle Gutschriften für gelöschte oder entnommene Komponenten berücksichtigt.
In der bevorzugten Ausführungsform stellt die Materialliste (BOM) eine Liste aller konfigurierten Komponenten und Ersatzteile dar, die seit der letzten Konfigurationsanforderung im System verwendet werden. Für jede Komponente und jedes Ersatzteil wird Teilenummer und Bezeichnung angegeben.
In der bevorzugten Ausführungsform bietet die Teileliste Angaben zu Zusatzkomponenten (d. h. Ersatzteilen), Gesamtressourcen, erfolglosen Anforderungen und fehlgeschlagenen optionalen Anforderungen. Gesamtressourcen bietet die Summe aller direkt vom Benutzer angeforderten Komponenten und Ressourcen an. Bei erfolglosen Anforderungen und fehlgeschlagenen optionalen Anforderungen handelt es sich um Komponentenanforderungen, die wegen Platzmangel, fehlender Verbinderverfügbarkeit usw. nicht erfüllt werden konnten.
ANGEBOTSERSTELLUNG
Die Angebotserstellung berechnet die Kosten der einzelnen Produktpakete und ermittelt die Kosten aller zur Komplettierung des Systems erforderlichen Produktpakete. Die Angebotserstellung bietet die Möglichkeit, Angebote auf verschiedene Weise anzuzeigen. Zum Beispiel kann das Angebot nach Produkt mit der Fähigkeit zur Erweiterung oder Reduzierung der Produktinformationen und Preisangaben für einzelne Produktteile bzw. das ganze Paket versehen sein. Die Art der Präsentation von Produkten oder Berechnung von Preisen lässt sich kundenspezifisch anpassen.

Claims

Verfahren zum Konfigurieren eines Systems unter Benutzung eines Computersystems, welches die folgenden Schritte umfaßt: Zugreifen auf ein Modell in dem Computersystem, welches Elemente, die zum Konfigurieren des Systems verwendet werden, und strukturelle Beziehungen zwischen den Elementen in dem Modell umfaßt, wobei das Modell eine strukturelle Modellhierarchie besitzt, wobei es in dieser strukturellen Modellhierarchie Elemente, die als in einem anderen Element enthalten definiert sind, und/oder Elemente, die als Teil eines anderen Elements definiert sind, gibt, Einrichten von mehreren Ressourcen, die von einem oder mehreren Elementen in der strukturellen Hierarchie angeboten werden, Instantiieren einer Systemkonfiguration auf der Grundlage des Modells und auf der Grundlage von Konfigurationsanforderungen, welche Ressourcenanforderungen umfassen, wobei das Instantiieren einer Systemkonfiguration das Erzeugen von Instanzen von einem oder mehreren Modellelementen auf der Grundlage der Anforderungen umfaßt.
Verfahren nach Anspruch 1, wobei das Elementmodell eine strukturelle Modellhierarchie definiert, welches Komposit- und Containerhierarchien und Anschlußbeziehungs-Unterstrukturen umfaßt.
Verfahren nach Anspruch 1 oder 2, wobei die Instanzen überprüft werden, um festzustellen, ob eine Randbedingung des Modells existiert und die Randbedingung erfüllt ist, wenn die Randbedingung existiert.
Verfahren nach einem der Ansprüche 1 bis 3, welches die weiteren Schritte umfaßt: (a) Instantiieren einer Konfigurationsinstanz in dem Computersystem, (b) Modifizieren der Konfigurationsinstanz in Reaktion auf eine Anforderung, indem in der Konfigurationsinstanz Instanzen von einem oder mehreren Modellelementen auf der Grundlage der Anforderungen erzeugt werden, (c) Speichern der Modifikationen in einer Modifikationsliste, (d) Überprüfen der Instanzen, um zu bestimmen, ob eine Randbedingung existiert, (e) Erfüllen der Randbedingung in dem Computersystem, wenn die Randbedingung existiert, (f) Übergeben der Modifikationen an die Konfigurationsinstanz und Entfernen der Modifikationen aus der Modifikationsliste, wenn keine Randbedingung existiert und wenn die Randbedingung erfüllt ist, und (g) Entfernen der Modifikation aus der Konfigurationsinstanz und der Modifikationsliste, wenn die Randbedingung nicht erfüllt ist.
Verfahren nach Anspruch 4, wobei die Konfigurationsinstanz leer ist, wenn eine neue Konfiguration definiert wird und die Konfigurationsinstanz eine existierende Konfiguration enthält, wenn ein existierendes System aktualisiert wird.
Verfahren nach Anspruch 4 oder 5, wobei die Instanzen in der Konfiguration aufgrund einer oder mehrerer der Komposit- und Containerhierarchien und Anschlußbeziehungen einer Randbedingung unterliegen.
Verfahren nach einem der Ansprüche 2 bis 4, welches weiterhin den folgenden Schritt enthält: Erfüllen von Komponentenrandbedingungen der Komponentenhierarchie in dem Computersystem, wenn die Instanzen durch die Komponentenrandbedingungen eingeschränkt sind, Erfüllen von Containerrandbedingungen der Containerhierarchie in dem Computersystem, wenn die Instanzen durch die Containerrandbedingungen eingeschränkt sind, und Erfüllen von Verbindungsrandbedingungen der Anschlußbeziehung in dem Computersystem, wenn die Instanzen durch die Verbindungsrandbedingungen eingeschränkt sind.
Verfahren nach Anspruch 4, welches die folgenden Schritte enthält: Identifizieren einer Alternative zum Erfüllen der Anforderung, wenn die Instanzen von einem oder mehreren Modellelementen die Anforderung nicht erfüllen und wenn die Instanzen von einem oder mehreren Modellelementen die Randbedingungen nicht erfüllen und Wiederholen der Schritte (b) bis (g) für diese Alternative.
Verfahren nach Anspruch 4, welches weiterhin den Schritt des Anzeigens umfaßt, daß die Anforderung nicht erfolgreich war, wenn die Instanzen von einem oder mehreren Modellelementen die Anforderung nicht erfüllen und wenn die Instanzen von einem oder mehreren Modellelementen die Randbedingungen nicht erfüllen und keine Alternative identifiziert werden kann, um die Anforderung zu erfüllen.
Verfahren nach einem der Ansprüche 1 bis 9, wobei eine Ressourcenanforderung zum Konfigurieren des Systems in dem Computersystem unter Verwendung der folgenden Schritte erfüllt wird: (a) Einrichten einer Konfigurationsinstanz in dem Computersystem, (b) Überprüfung der Konfigurationsinstanz auf ein eine Ressource anbietendes Element in Reaktion auf eine Anforderung für diese Ressource, (c) Wählen der Ressource von diesem Element, wenn die Ressource nicht bereits vorher verbraucht worden ist, (d) Auswählen einer neu erzeugten Elementinstanz, welche diese Ressource anbietet, wenn keine vorhandenen Elemente die Ressourcenanforderung erfüllen, und (e) Wiederholen der Schritte (b) bis (d), wenn die Elementauswahl nicht Anfrage und Testbedingungen erfüllt.
Verfahren nach einem der Ansprüche 1 bis 10, wobei eine Containerrandbedingung in einem Computersystem zum Konfigurieren von Systemen unter Verwendung der folgenden Schritte erfüllt wird: Einrichten einer Konfigurationsinstanz in dem Computersystem, Erfüllen der Containerrandbedingung in dem Computer, wenn die Containerrandbedingung existiert, durch: (a) Überprüfen der Konfigurationsinstanz, um zu bestimmen, ob eine Containerinstanz zur Verfügung steht, um die Containerrandbedingung zu erfüllen, (b) Modifizieren der Konfigurationsinstanz durch Erzeugen einer neuen Containerinstanz, wenn die Containerrandbedingung nicht durch eine Containerinstanz in der Konfigurationsinstanz erfüllt werden kann, (c) Speichern der Modifikation in einer Liste von Modifikationen, wenn die Containerrandbedingung nicht durch eine Containerinstanz in der Konfigurationsinstanz erfüllt werden kann, (e) Überprüfen der neuen Containerinstanz, um zu bestimmen, ob eine Randbedingung vorhanden ist, (f) Erfüllen der Randbedingung in dem Computersystem, wenn die Randbedingung für die neue Containerinstanz existiert, (g) Übergeben der Modifikationen an die Konfigurationsinstanz und Entfernen der Modifikationen aus der Modifikationsliste, wenn keine Randbedingung existiert und wenn die Randbedingung erfüllt ist, und (h) Entfernen der Modifikationen aus der Konfigurationsinstanz und aus der Modifikationsliste, wenn die Randbedingung nicht erfüllt ist.
Verfahren nach einem der Ansprüche 1 bis 11, wobei eine Komponentenrandbedingung in einem Computersystem zum Konfigurieren von Systemen unter Verwendung der folgenden Schritte erfüllt wird: Einrichten einer Konfigurationsinstanz in dem Computersystem, Erfüllen der Komponentenrandbedingung in dem Computersystem, wenn die Komponentenrandbedingung existiert, durch (a) Prüfen der Konfigurationsinstanz, um zu bestimmen, ob eine Komponenteninstanz zur Verfügung steht, um die Komponentenrandbedingung zu erfüllen, (b) Modifizieren der Konfigurationsinstanz durch Erzeugen einer neuen Komponenteninstanz, wenn die Komponentenrandbedingung nicht durch eine Komponenteninstanz in der Konfigurationsinstanz erfüllt werden kann, (c) Speichern der Modifikationen in einer Modifikationsliste, wenn die Komponentenrandbedingung nicht durch eine Komponenteninstanz in der Konfigurationsinstanz erfüllt werden kann, (e) Überprüfen der neuen Komponenteninstanz, um festzustellen, ob eine Randbedingung existiert, (f) Erfüllen der Randbedingung für die neue Komponenteninstanz in dem Computersystem, wenn die Randbedingung existiert, (g) Übergeben der Modifikationen an die Konfigurationsinstanz und Entfernen der Modifikationen aus der Modifikationsliste, wenn keine Randbedingung für die neue Komponenteninstanz existiert und wenn die Randbedingung erfüllt ist, und (h) Entfernen der Modifikationen aus der Konfigurationsinstanz und der Modifikationsliste, wenn die Randbedingung für die neue Komponenteninstanz nicht erfüllt ist.
Verfahren nach einem der Ansprüche 1 bis 12, wobei eine Verbindungsrandbedingung in einem Computersystem mit Hilfe der folgenden Schritte erfüllt wird: Einrichten einer Konfigurationsinstanz in dem Computersystem, Erzeugen einer Verbindungsrandbedingung derart, daß ein Targetelement in der Konfigurationsinstanz eine Verbindung zu einem Zielelement der Konfigurationsinstanz erfordert, (a) Erzeugen einer Liste von Zielelementen, (b) Auswählen eines Zielelements aus der Liste von Zielelementen, (c) Identifizieren von nicht verbundenen Anschlüssen des Zielelements, welche von dem Targetelement aus zugänglich sind, (d) Identifizieren von verfügbaren Anschlüssen des Targetelements, (e) Auswählen eines ersten Anschlusses aus den nicht verbundenen Anschlüssen des Zielelements, (f) Auswählen eines zweiten Anschlusses aus einem der verfügbaren Anschlüsse des Targetelements, (g) Vergleichen des physikalischen Typs und des logischen Datentyps des ersten Anschlusses mit dem physikalischen Typ und dem logischen Datentyp des zweiten Anschlusses, (h) Überprüfen des Übertragungspfads zwischen dem ersten Anschluß und dem zweiten Anschluß, (i) Verbinden des ersten Anschlusses mit dem zweiten Anschluß, wenn der physikalische Typ und der logische Datentyp kompatibel sind und wenn der Übertragungspfad zwischen dem ersten Anschluß und dem zweiten Anschluß existiert und (j) Wiederholen der Schritte (b) bis (j), wenn der physikalische Typ und der logische Datentyp nicht kompatibel sind und wenn der Transferpfad zwischen dem ersten Anschluß und dem zweiten Anschluß nicht existiert.
Verfahren nach einem der Ansprüche 1 bis 13, welches den Schritt des Anzeigen einer graphischen Darstellung der Systemkonfiguration und der strukturellen Beziehungen zwischen den Elementen der Systemkonfiguration durch das Computersystem umfaßt.
Verfahren nach einem der Ansprüche 1 bis 14, wobei die Konfigurationsanforderungen Elementanforderungen, Ressourcenanforderungen und Identifizierungen von Erfordernissen sind.
Verfahren nach einem der Ansprüche 1 bis 15, welches den Schritt des Erzeugens eines Berichts einer Liste von Materialien durch das Computersystem umfaßt, welcher eine Teilnummer und eine Beschreibung für jede Komponente und jedes Ersatzteil der Systemkonfiguration, die Gesamtheit der Ressourcen, die fehlgeschlagenen Anforderungen und die fehlgeschlagenen optionalen Anforderungen enthält.
Verfahren nach einem der Ansprüche 1 bis 16, welches weiterhin die folgenden Schritte umfaßt: Bündeln der Instanzen in der Systemkonfiguration in Produktgruppierungen durch das Computersystem und Erzeugen einer Preisangabe für die Systemkonfiguration.
Computersystem zum Konfigurieren eines Systems, welches umfaßt: eine Einrichtung, die dafür eingerichtet ist, in dem Computersystem auf ein Modell zuzugreifen, welches Elemente, die zum Konfigurieren des Systems verwendet werden, und strukturelle Beziehungen zwischen den Elementen in dem Modell umfaßt, wobei das Modell eine strukturelle Modellhierarchie aufweist, wobei in der strukturellen Modellhierarchie Elemente, die als in einem anderen Element enthalten definiert sind, und/oder Elemente, die als Teil eines anderen Elements definiert sind, vorhanden sind, wobei mehrere Ressourcen durch ein oder mehrere Elemente in der strukturellen Hierarchie angeboten werden, eine Einrichtung, welche dafür eingerichtet ist, eine Systemkonfiguration auf der Grundlage des Modells und auf der Grundlage von Konfigurationsanforderungen, welche Ressourcenanforderungen umfassen, zu instantiieren, wobei die Einrichtung, die dafür eingerichtet ist, eine Systemkonfiguration zu instantiieren, eine Einrichtung umfaßt, die dafür eingerichtet ist, Instanzen von einem oder mehreren Modellelementen auf der Grundlage der Anforderungen zu erzeugen.
Computerprogramm zum Konfigurieren eines Systems, wobei das Programm einen Computer veranlaßt, ein Verfahren nach einem der Ansprüche 1 bis 17 auszuführen, wenn es auf dem Computersystem ausgeführt wird.
Computerlesbares Speichermedium, welches einen computerlesbaren Programmcode enthält, wobei der Programmcode ein Computersystem veranlaßt, ein Verfahren nach einem der Ansprüche 1 bis 17 auszuführen, wenn er auf dem Computersystem ausgeführt wird.