DE3911465C2 - Verfahren zur automatischen Konfiguration technischer Systeme aus Komponenten - Google Patents

Description

Die vorliegende Erfindung bezieht sich auf ein Verfahren gemäß dem Oberbegriff des Anspruchs 1. Ein solches Verfahren ist durch die EP 03 04 866 A2 bekannt.

Stand der Technik

An der Literatur ist ein Verfahren zur Konfiguration technischer Systeme bekannt, das z. B. bei einem in der GB 22 06 713 A beschriebenen System und auch im Konfigurations-Expertensystem R1 (s. McDermott, J. "R1: A Rule-Based Configurer of Computer-Systems", Artificial Intelligence 19 (1982), S. 39-86), später XCON genannt, verwendet wird, welches darin besteht, daß die beim Konfigurieren des technischen Systems aus dem vorgegebenen Spektrum verfügbarer Komponententypen zu beachtenden Regeln in einem mit einem Rechner verbundenen Speicher gespeichert sind und diese Regeln als Produktionsregeln der Programmiersprache OPS 5 behandelt und bearbeitet werden. In den Regeln werden in der Syntax der OPS 5-Programmiersprache Informationen über den momentanen Stand des Konfigurations-Vorgangs, über die vorliegende Teil-Konfiguration und über die konkret zur Verfügung stehenden Komponententypen verknüpft und davon abhängig Handlungsanweisungen erteilt. Nachteile des Verfahrens sind, daß wegen der explizierten Nennung von Komponenten und Typen in den Regeln bei jeder Änderung an Komponenteneigenschaften oder am Spektrum der Komponententypen im Prinzip das ganze Regelwerk überarbeitet werden muß, daß nur schwer oder gar nicht zu erkennen ist, welche Regeln auf welche Komponententypen angewendet werden und daher geändert werden müssen oder entfallen können, und daß wegen der Produktionsregelbehandlung durch OPS 5 der tatsächliche Ablauf des Konfigurationsvorganges schwer zu durchschauen oder zu verifizieren ist.

Aus der Literatur ist ferner ein Verfahren zur Konfiguration technischer Systeme bekannt, das im Expertensystem-Prototyp SICONFEX (s. Lehmann, E. et al. "SICONFEX ein Expertensystem für die Konfiguration eines Betriebssystems", 15. GI-Jahrestagung, 1985, S. 792-805) eingesetzt wurde, bei dem Informationen über die verfügbaren Komponenten nicht in Form von Regeln, sondern jeweils Komponententyp-weise zusammengefaßt in einem Speicher abgelegt werden. Nachteile des Verfahrens sind, daß die Hardware-Komponenten vom Benutzer festgelegt werden müssen bzw. wie bei den Software-Komponenten explizit genannt werden. Dadurch sind nur sehr spezielle Konfigurationsaufgaben behandelbar, zudem ist die Anpassung der Wissensbasis an die laufenden Änderungen im Sachgebiet recht aufwendig.

Ein weiteres Verfahren zur Konfiguration technischer Systeme aus Komponenten ist aus dem Vorführen von Applikationsstudien zur Expertensystem-Schale KEM bekannt. Im Grundgedanken einer Beschreibung der Konfigurationsvorgabe durch eine Menge von Produktionsregeln ähnelt es XCON; die technischen Daten der Komponententypen werden jedoch wie bei SICONFEX objektorientiert zu jedem Komponententyp zusammengefaßt repräsentiert. Da in den Regeln alle abhängigen Komponenten explizit genannt werden, weist es ebenfalls die Nachteile von SICONFEX und XCON auf.

Daneben sind noch Expertensysteme bekannt geworden, die jeweils auf ein spezielles Anwendungsgebiet zugeschnitten sind und deren Schlußfolgerungen für dieses Anwendungsgebiet speziell programmiert werden, ohne daß dabei eine auf andere Anwendungsgebiete übertragbare oder allgemein anwendbare technische Lehre zur Lösung von Konfigurationsaufgaben offenbart wird. Zum Beispiel gibt die eingangs bereits genannte EP 0 304 866 A2 ein Expertensystem an, das allein auf ein Verdrahtungsproblem zugeschnitten ist, ohne daß erläutert wird, wie, sondern nur daß das System Schlüsse aus den jeweiligen Komponententypen zieht.

Aufgabe der Erfindung ist es, ein Verfahren der eingangs genannten Art zu schaffen, das zur Konfiguration von technischen Systemen aus Komponenten universell einsetzbar ist, ein einfaches und durchschaubares, aber wirksames Vorgehen zeigt und das bei Änderungen im Komponententypspektrum mit geringem Aufwand nachgeführt bzw. angepaßt werden kann.

Diese Aufgabe wird gemäß der Erfindung durch die im Anspruch 1 gekennzeichneten Merkmale gelöst. In den Unteransprüchen 2 bis 6 sind vorteilhafte Ausgestaltungen und Weiterbildungen des Verfahrens beschrieben.

Der Vorteil des gewählten Verfahrens liegt darin begründet, daß nicht, wie bisher in bekannten Verfahren direkte Beziehungen zwischen Komponenten beschrieben werden, sondern Beziehungen von Komponenten zu Ressourcen und damit in indirekter Weise zu anderen Komponenten.

Als Ressourcen sind hier modellhafte, abstrahierte Träger von Wechselwirkungen an Schnittstellen (zum Beispiel elektrische Energie) zu verstehen, gekennzeichnet durch die Angabe einer Art (zum Beispiel elektrischer Strom bei 5 V) und Angabe einer Stärke (zum Beispiel 3 A). Solche Schnittstellen werden nach dem Sprachgebrauch der Physik als extensive Leistungsmerkmale bezeichnet, d. h. die Stärke verhält sich additiv. Als intensive Leistungsmerkmale werden entsprechend Größen bezeichnet, deren Stärke sich nichtadditiv verhält, zum Beispiel Temperaturwerte.

Die Wechselwirkungen an Schnittstellen sind gerichtet, wobei gemäß dem unterlegten Modell die Ressource von einer oder mehreren Komponenten bereitgestellt, von anderen Komponenten verbraucht/belegt (d. h. exklusiv genutzt, zum Beispiel elektrischer Strom) oder vorausgesetzt/benutzt (d. h. nichtexklusiv genutzt, zum Beispiel Taktfrequenz) wird.

Ressourcen beschreiben meist physikalische Eigenschaften bzw. Schnittstellen, deren Festlegungen eine lange Lebensdauer besitzen. Da die Beziehungen zwischen Komponenten indirekt über die Angabe von Ressourcen notiert werden, genügt es bei der Einführung einer neuen Komponente, diese und ihre Beziehungen zu Ressourcen zu beschreiben. Damit sind indirekt die Wechselwirkungen mit allen bereits bestehenden Komponenten festgelegt, Änderungen bei den bisherigen Komponenten bedarf es nicht.

Anhand der Zeichnung soll das Verfahren nach der Erfindung für eine vorteilhafte Ausgestaltung im folgenden beschrieben werden:

Verzeichnis der Zeichnungsfiguren

Fig. 1 Datenflußplan,

Fig. 2 Programmablaufplan "Auswahl der Komponenten",

Fig. 3 Programmablaufplan "Nimm nicht erfüllte Anforde­ rung aus Bilanz",

Fig. 4 Programmablaufplan "Auswahl der geeigneten Komponententypen",

Fig. 5 Programmablaufplan "Sortiere Liste der geeigneten Komponententypen nach Eignung",

Fig. 6 Programmablaufplan "Bilanz erstellen",

Fig. 7 Programmablaufplan "Revidiere vorige Entscheidung",

Fig. 8 Datenstruktur "Komponententyp",

Fig. 9 Datenstruktur "Komponententaxonomie",

Fig. 10 Visualisierung der Komponententaxonomie.

Die wesentlichen Informationen werden in vier Speichern S1 bis S4 gehalten, wobei die Speicher S3 und S4 Teile eines Rechners R sind (s. Fig. 1).

Die Anforderungs-Spezifikation beschreibt die geforderten Leistungen des zu konfigurierenden Systems, das heißt, welche Ressourcen es in welchem Umfang und in welcher Qualität bereitstellen soll. Solche Ressourcen, d. h. Ressourcen, die als exklusiv oder nichtexklusiv genutzt bekannt sind, die aber noch nicht bereitgestellt sind, werden "geforderte" Ressourcen genannt.

Der Katalog verfügbarer Komponententypen enthält Informationen zu allen Komponenten (siehe auch Fig. 9 und Fig. 10).

Die Entscheidungsliste enthält ein Protokoll aller bereits erfolgten Entscheidungen, wobei neben dem gewählten Komponententyp auch andere geeignete (Alternativen) notiert werden.

Die Bilanz enthält für jede Ressource die Angabe, welche verbleibenden Anforderungen bestehen. Diese Anforderungen ergeben sich aus der Anforderungs-Spezifikation und den Folge-Anforderungen, die aufgrund der Operation "Verbrauchsfeststellung (v)" aus den bereits gewählten Komponenten errechnet werden, abzüglich den von diesen Komponenten bereitgestellten Ressourcen, festgestellt in der Operation "Bereitstellung (b)". Mit Hilfe der Operation "Wählen (w)" wird aus den verbleibenden Anforderungen und den Informationen des Komponenten-Katalog eine neue Auswahl getroffen.

Fig. 2 beschreibt den groben Programmablauf. Das Programm arbeitet nach einer Initialisierung, in der der Speicher "Bilanz" zunächst anhand der Anforderungen aus der Spezifikation gefüllt wird, in einer Schleife. Bei jedem Schleifendurchlauf wird für jeweils eine noch nicht erfüllte Anforderung eine Komponente ausgesucht. Hierfür werden zuerst alle geeigneten Komponententypen bestimmt, die anschließend nach Grad der Eignung sortiert werden. Ein Exemplar des geeignetsten Komponententyps wird gewählt.

Nach der Auswahl wird die Bilanz aktualisiert, indem die Ressourcen, die eine Komponente des gewählten Typs bereitstellt, bestehende Anforderungen vermindern, andererseits die von der Komponente verbrauchten/belegten Ressourcen die gestellten Anforderungen erhöhen. Diese Folgeanforderungen werden bei einem der späteren Schleifendurchläufe bearbeitet.

Die Schleifenbearbeitung endet, wenn keine erfüllbaren Anforderungen mehr existieren. Die gewählten Komponenten werden ausgegeben, ergänzt um die Bereitstellungs-/Belegungs- Bilanz.

Falls während der Schleifenbearbeitung für eine Anforderung keine geeigneten Komponenten gefunden werden, wird versucht, durch Revidierung früherer Entscheidungen zu einer Lösung zu kommen. Dabei werden alle früheren Entscheidungen schrittweise, beginnend bei der jüngsten, zurückgenommen, bis eine Festlegung erreicht wird, für die mindestens eine Alternative besteht. Statt der alten Festlegung wird nun der nächstbeste geeignete Komponententyp ausgesucht und mit der Auswahl ab diesem Entscheidungsstand fortgefahren. Dieser Vorgang kann sich mehrfach wiederholen. Falls keine früheren Entscheidungen mit Alternativen existieren, ist die Anforderung nicht erfüllbar. Dies wird gemeldet. Um noch weitere eventuell vorhandene nicht erfüllbare Anforderungen bestimmen zu können, wird mit der Abarbeitung der Schleife fortgefahren, wobei in Zukunft die als unerfüllbar gemeldete Anforderung nicht mehr berücksichtigt wird.

Falls überhaupt eine Lösung existiert, wird sie mit diesem Verfahren gefunden. Wenn mehr als eine Lösung existiert, so wird die erste Konfiguration, die allen Anforderungen genügt, als Lösung geliefert.

Fig. 3 beschreibt die Auswahl der nächsten zu erfüllenden Anforderung. Ein temporäre Liste dient der Aufnahme der verbleibenden Anforderungen. In einer Schleife werden alle Einträge der Bilanz untersucht, ob die zugehörige Anforderung bereits erfüllt ist, ob sie bereits als nicht erfüllbar erkannt ist oder ob sie zu den extern zu erfüllenden Anforderungen gehört.

Wenn keine dieser Bedingungen gilt, wird die Anforderung in die Liste der verbleibenden Anforderungen eingetragen. Nach dieser Filterung wird entschieden, welche dieser Anforderungen als nächste zu bearbeiten ist. Die bei dieser Auswahl bestimmte Reihenfolge der Anforderungsabdeckung hat entscheidenden Einfluß auf die Güte der Lösung. Die günstigste Reihenfolge hängt vom jeweiligen Anwendungsgebiet ab.

Der durch Fig. 4 beschriebenen Programmteil filtert aus dem Katalog diejenigen Komponententypen heraus, die zur Erfüllung der gerade betrachteten Anforderung geeignet sind. Dies geschieht in einer Schleife, in der diejenigen Komponententypen des Katalogs in die Liste der geeigneten Komponententypen eingetragen werden, die zur Abdeckung der Anforderung beitragen, die intensiven Leistungsanforderungen erfüllen und mit den bisher gewählten Komponententypen verträglich sind.

Das Sortieren der Liste der geeigneten Komponententypen nach Grad der Eignung wird in Fig. 5 dargestellt. In einer Schleife wird die Liste der geeigneten Komponenten abgearbeitet und jedes Element sortiert in eine temporäre Liste eingetragen. Sortierkriterium ist die anwendungsspezifische Bewertung des Komponententyps. Da ein Komponententyp mehrere Ressourcen unterschiedlichen Typs bereitstellen kann, wird dabei nicht nur die Erfüllung der gerade betrachteten Anforderung bewertet, sondern alle verbleibenden Anforderungen berücksichtigt.

Nach Abarbeitung der Schleife wird die sortierte temporäre Liste als jüngstes Element in die Entscheidungsliste eingetragen.

Die Bilanz, das heißt die Aufstellung der bisher aufgelaufenen Anforderungen und Bereitstellungen, wird durch den in Fig. 6 beschriebenen Programmteil erstellt. Dabei werden zuerst die Anforderungen der Anforderungs- Spezifikation in die Bilanz eingetragen. Anschließend wird in einer Schleife jeder Eintrag in der Entscheidungsliste berücksichtigt. Das erste Element dieser Einträge legt dabei den Typ der jeweils gewählten Komponente fest, die restlichen Elemente (die alternativen Komponententypen) werden ignoriert. Aus dem Komponententypen-Katalog wird jeweils entnommen, welche Ressourcen der Komponententyp bereitstellt und welche er voraussetzt bzw. verbraucht/belegt.

Dies wird in die Bilanz verrechnet.

Das Revidieren früherer Entscheidungen im Falle von Sackgassen wird durch Ändern der Entscheidungsliste vorgenommen, deren neue Festlegungen bei der nachfolgenden Bilanzierung berücksichtigt werden (Fig. 7).

Bei diesem Ändern der Entscheidungsliste wird der jüngste Eintrag untersucht, ob zur bisherigen Wahl alternative Komponententypen notiert sind. Wenn dies der Fall ist, wird die bisherige Wahl verworfen, die bisher beste Alternative wird gewählt und die restlichen Alternativen rücken nach. Dies wird dadurch erzielt, daß in der Entscheidungsliste beim jüngsten Eintrag, einer Liste von Komponententypen, das erste Element entfernt wird.

Falls im jüngsten Eintrag der Entscheidungsliste keine Alternativen notiert sind, wird dieser Eintrag gestrichen und der nunmehr jüngste Eintrag einer Revision unterzogen.

Die bevorzugte Ausführung des Komponententypen-Katalogs verwendet im Speicher S1, in dem für jede verfügbare Komponententype die in den Ansprüchen genannten Informationen enthalten sind, die im folgenden beschriebenen Datenstrukturen:
Die Datenstruktur "Komponententyp" beschreibt jeweils einen Komponententyp (Fig. 8). Hierzu gehören Angaben über die Ressourcen, die die Komponente belegt bzw. benutzt, Angaben über die Ressourcen, die sie bereitstellt, Angaben über die intensiven Leistungsanforderungen, die die Komponente zu erfüllen hat, Angaben von anderen Komponententypen, mit denen Unverträglichkeit besteht, sowie Regeln, die u. a. zur Bewertung der Komponente dienen oder Beziehungen auszudrücken, die über das Schema hinausgehen.

Um eine systematische Gliederung des Komponententypen- Kataloges zur erreichen und die Zahl der Eintragungen zu minimieren, werden ähnliche Komponententypen in Oberklassen zusammengefaßt. Bei den Oberklassen werden alle gemeinsamen Eigenschaften notiert, während bei dem Komponententyp selbst die individuellen Eigenschaften (einschließlich der Zugehörigkeit zu Oberklassen) eingetragen werden. Dazu dient der Eintrag "Oberklassen" der Datenstruktur "Komponententyp" (Fig. 8).

Die Beziehungsstruktur zwischen mehreren Komponententypen und ihren Oberklassen, wie sie in der Datenstruktur "Komponententyp" repräsentiert wird, zeigt Fig. 9 exemplarisch. An dieser Fig. 9 soll auch erläutert werden, wie auf Informationen über einen Komponententyp zugegriffen wird. Das Grundverfahren besteht darin, eine benötigte Information rekursiv so lange zu suchen, bis sie gefunden ist, zunächst in der Datenstruktur des Komponententyps, danach in den zugehörigen Oberklassen des Komponententyps oder der Klasse. Dies führt zu einem baumartigen Suchraum, der "depth first" durchmustert wird.

Als Beispiel sei die Information "vom Komponententyp X bereitgestellte Ressource vom Ressourcentyp D" gesucht. Dazu wird zuerst in der Datenstruktur zum Komponententyp X unter den Angaben über bereitgestellte Ressourcen nach einem Eintrag über den Ressourcentyp D gesucht. Wenn dort ein solcher Eintrag nicht gefunden wird, werden die in der Angabe "Oberklassen von X" eingetragenen Oberklassen betrachtet und dort nach der Information "bereitgestellte Ressource vom Ressourcentyp D" gesucht. Im Beispiel ist Oberklasse die Klasse F. Ist auch dort eine solche Information nicht notiert, so wird das Verfahren für Klasse F wiederholt und deren Oberklassen durchsucht. Im Beispiel sind dies die Klassen A, B und C, die in dieser Reihenfolge betrachtet werden. Wenn die Information gefunden wird, beispielsweise in B, endet die Suche dort.

Fig. 10 gibt eine bevorzugte Form der Darstellung wieder, mit der die Komponententaxonomie auf der Einheit V visualisiert wird. In diesem Beispiel sind Komponententypen mit einer grauen Fläche unterlegt, die restlichen Begriffe benennen Oberklassen. Dabei benennen die links von einer Klasse oder einem Komponententyp stehenden Begriffe jeweils die Oberklassen dieser Klasse oder dieses Komponententyps. Rechts von einer Klasse sind entsprechend Unterklassen bzw. Komponententypen dieser Klasse notiert.

Bei Aufbau und/oder Pflege des Katalogs verfügbarer Komponententypen wird erfindungsgemäß zunächst die Komponententaxonomie auf der Einheit V dargestellt. Die Interaktion des Benutzers mit der Einrichtung beginnt dann jeweils durch Markieren eines Begriffs in der Visualisierung der Taxonomie mittels der Markierungseinheit M, wodurch weitere Interaktionsmittel zur Anzeige, Eingabe oder Änderung der Angaben zu dem angewählten Komponententyp bzw. der angewählten Klasse aktiv werden, gegebenenfalls unter Zwischenschaltung von Menüs zur Auswahl von Operationen.

Claims (7)

1. Verfahren zur automatischen Konfiguration technischer Systeme aus Komponenten unter Verwendung eines Rechners und einer Anzahl mit ihm verbundener Speicher anhand einer Anforderungsspezifikation und eines Katalogs verfügbarer Komponententypen, dadurch gekennzeichnet,

• - daß in einem mittelbar oder unmittelbar mit dem Rech­ ner (R) verbundenen ersten Speicher (S1) ein Katalog verfügbarer Komponententypen abgespeichert wird und dabei in diesem ersten Speicher (S1) für jede verfügbare Komponententype mindestens eine der folgenden Informationen abgelegt wird:
  • Art und Größe der intensiven Leistungsmerkmale,
    Art und Größe der bereitgestellten Ressourcen,
    Art und Größe der vorausgesetzten Ressourcen,
    Art und Größe der verbrauchten/belegten Ressourcen,
• - daß in einem mittelbar oder unmittelbar mit dem Rechner (R) verbundenen zweiten Speicher (S2) die Anforderungsspezifikation für das zu konfigurierende technische System abgespeichert wird und dabei in diesem Speicher mindestens eine der folgenden Informationen abgelegt wird:
  • Art und Größe der für das technische System geforderten Ressourcen,
    Art und Größe der für das technische System geforderten intensiven Leistungsmerkmale,
• - und daß die automatische Auswahl von Komponenten für das technische System durch den Rechner (R) so vorgenommen wird, daß, ausgehend von den für das technische System geforderten Ressourcen, solange noch Ressourcenbedarf besteht und Komponententypen im Katalog existieren, welche entsprechende Ressourcen bereitstellen und die intensiven Leistungsmerkmale erfüllen, wiederholt jeweils eine oder mehrere Komponenten des bestgeeigneten Komponententyps ausgewählt werden und deren bereitgestellte Ressourcen bzw. deren vorausgesetzte oder verbrauchte/belegte Ressourcen im verbleibenden Ressourcenbedarf berücksichtigt werden.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß die Komponententypen des Katalogs in einer Taxonomie der Komponententypen hierarchisch unter Oberklassen geordnet werden, indem zu jeder Komponententype und Oberklasse die zugehörige(n) Oberklasse(n) gespeichert wird (werden), und
daß für Eigenschaften, für die alle Komponententypen einer Oberklasse stets und üblicherweise ein gemeinsamer Wert oder Anfangswert oder ein gemeinsamer Grundwert zukommt, dieser Wert oder Grundwert nur bei der jeweiligen Oberklasse notiert wird, um für alle Unterklassen und Klassenmitglieder zu gelten, dem diese Werte aus den gespeicherten Daten einer der gespeicherten Oberklassen entnommen werden.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet,
daß als Eigenschaften zu jedem Komponententyp und jeder Oberklasse im Katalog festgelegt und im zugehörigen Speicher abgelegt wird, mit welchen Ressourcen, Komponenten oder Komponentengruppen zusammen eine Komponente ausgewählt bzw. nicht ausgewählt werden kann, und
daß diese Informationen bei der Auswahl berücksichtigt werden.

4. Verfahren nach einem der Ansprüche 2 oder 3, dadurch gekennzeichnet,
daß für jeden Komponententyp und jede Oberklasse im Katalog Regeln festgelegt und zugeordnet werden, unter welchen Bedingungen, insbesondere bezüglich der anderen ausgewählten Komponenten, eine Komponente in Betracht zu ziehen bzw. nicht zulässig ist, indem diese Regeln im Speicher für den Katalog abgespeichert und dem jeweiligen Komponententyp zugeordnet werden, und
daß diese Regeln bei der Auswahl einer Komponente angewendet und berücksichtigt werden.

5. Verfahren nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet,
daß für den Aufbau und/oder die Pflege des Katalogs verfügbarer Komponententypen im Rechner (R) in einer Einheit (V) eine grafische oder semigrafische Darstellung der Komponententaxonomie angezeigt wird, und
daß dabei mit dieser Einheit (V) oder mit einer weiteren Einheit (E) im Rechner (R) jede einzelne der dargestellten Oberklassen und Komponententypen zur interaktiven Manipulation des Katalogs und Information zu den Oberklassen und Komponententypen anwählbar gehalten wird.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet,
daß bei der Auswahl der Komponenten jeweils eine Vorauswahl solcher Komponententypen getroffen wird, die im Prinzip geeignet sind, den aktuellen Ressourcenbedarf oder Teile davon abzudecken, und
daß aus dieser Gruppe von Komponententypen der Komponententyp mit den niedrigsten Systemkosten oder Kosten pro abgedeckter Ressource festgestellt und eine Komponente dieses Typs ausgewählt wird.

7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß durch Variation der Auswahl von Komponenten unter den im Prinzip geeigneten Komponenten systematisch oder zufällig alternative Konfigurationen ermittelt und solange die besten Konfigurationen gesucht werden, bis ein vorgegebenes Kriterium erfüllt oder eine Zeitscheibe überschritten oder jede Alternative untersucht ist.