B. Konfigurierungszyklus von EngCon

Im Folgenden wird der vollständige zentrale Zyklus des Kontrollmechanismus von ENGCON in Ergänzung zu der verkürzten Darstellung in Kapitel 3, Abschnitt 3.5.2 ff. vorgestellt. Eine schematische Übersicht ist dem Flussdiagramm in Abbildung B.3 zu entnehmen. Die nachfolgende, sequentielle Abfolge des Zyklus orientiert sich an der Beschreibung von Ranze et al. (2002, S. 849 f.) und Günter (1992, S. 118 ff.):

1. Auswahl der Aufgabenstellung
   Auswahl eines von den in der Wissensbasis definierten Zielkonzepten. Das Zielkonzept definiert den Wurzelknoten der kompositionellen Hierarchie (siehe Abbildung 3.3). Alle weiteren Konfigurierungsobjekte sind direkt oder indirekt Teil dieses Wurzelobjektes.

2. Generieren der initialen Teilkonfiguration
   Durch die Wahl der Aufgabenstellung wird die erste Teilkonfiguration erzeugt. Sie ist der Ausgangspunkt für alle weiteren Teilkonfigurationen und besteht bereits aus den benötigten Konfigurierungsobjekten. Diese Objekte sind Instanzen der Konzepte, die durch die Aufgabenstellung in der Begriffshierarchie spezifiziert sind.

3. Bestimmen der aktuellen Strategie
   Auswahl einer Strategie, die i.d.R. über mehrere Zyklen beibehalten wird. Der Konfigurierungsvorgang wird zur Strukturierung in unterschiedliche Phasen eingeteilt. Sie dienen dazu, einzelne Teilaufgaben zu bearbeiten, die relativ unabhängig voneinander sind. Phasen werden jeweils einer Strategie zugeordnet, in der das für die jeweilige Phase benötigte Kontrollwissen repräsentiert wird (vgl. Abschnitt 3.5.1 und Abschnitt 3.5.2). Die Auswahl einer Strategie erfolgt automatisch anhand der höchsten Priorität der verfügbaren Strategien. Der Benutzer kann sie allerdings auch manuell auswählen. Ein ,,Experte`` erhält somit die Möglichkeit, die Konfigurierung weitestgehend selbst zu beeinflussen.

   Wenn alle Strategien abgearbeitet wurden, wird die sog. ,,Default-Strategie`` aufgerufen. Sie besitzt die geringste Priorität und listet alle verbleibenden Konfigurierungsschritte in der Agenda auf, die vom Wissensingenieur nicht explizit aufgeführt wurden.

4. Generieren der Agenda
   Die Reihenfolge der Konfigurierungsschritte ist entscheidend für eine erfolgreiche Konfigurierung. Der Kontrollmechanismus überprüft dazu, welche Konfigurierungsschritte jeweils noch möglich sind und fasst diese Schritte in einer Agenda zusammen. Um mögliche Konfigurierungsschritte ausfindig zu machen, erfolgt ein Vergleich der Konfigurierungsinstanzen mit den zugehörigen Konzepten der Begriffshierarchie. Für Instanzen, die noch nicht vollständig spezialisiert sind, werden die entsprechenden Agenda-Einträge generiert.

   Die in der jeweiligen Strategie definierten KS-Foki werden zur Optimierung eingesetzt (vgl. Abschnitt 3.5.1). Ein KS-Fokus wird dazu genutzt, die Agenda auf einen bestimmten Teil der aktuellen Teilkonfiguration einzuschränken bzw. zu fokussieren (siehe Abbildung B.1). Die Reihenfolge der Konfigurierungsschritte in der Agenda leitet sich her aus den in der aktuellen Strategie priorisierten Agenda-Auswahlkriterien. Die Priorität ist durch die dort definierte Reihenfolge der Auswahlkriterien repräsentiert.

   Abbildung B.1: Konfigurierungsschritt-Fokus (KS-Fokus)

   

   Weil sich die Erzeugung der Agenda an der Begriffshierarchie orientiert, in der in einem Metamodell entsprechend der CWA die generische Beschreibung aller vollständigen, zulässigen Konfigurierungen definiert ist, wird gewährleistet, dass in der Agenda für alle notwendigen Konfigurierungsschritte stets auch die erforderlichen Agenda-Einträge existieren. Wenn in der Agenda keine Einträge mehr vorhanden sind, ist die Konfigurierung entweder vollständig spezifiziert, oder es sind alle Konfigurierungsschritte der aktuellen Phase (Strategie) durchgeführt worden. Als nächstes würde dementsprechend versucht werden, eine neue Strategie auszuwählen (Schritt 3).

5. Auswahl aus der Agenda
   Mit Hilfe von Agenda-Auswahlkriterien wird ein Konfigurierungsschritt zur Durchführung aus der erzeugten Agenda ausgewählt. Ein Agenda-Auswahlkriterium ist ein Muster, das durch die Angabe einer teilweisen Spezifikation eines Konfigurierungsschrittes repräsentiert wird.^B.1 Es kann sich auf Konfigurierungsobjekte (do), Eigenschaften von Konfigurierungsobjekten (slot) oder KS-Typen (ks-typ) beziehen (siehe Abbildung B.2). Die Agenda-Einträge werden mit dem Muster verglichen. Ein erfolgreicher Vergleich bedeutet, dass der Eintrag das Kriterium erfüllt.

   Abbildung B.2: Agenda-Auswahlkriterium

   

   Die Auswahlkriterien sind innerhalb der Strategie in einer strikten Ordnung definiert. Die Reihenfolge steht für die Priorität der Kriterien. Liefert die Anwendung eines Auswahlkriteriums mehr als einen Konfigurierungsschritt, werden der Reihe nach die folgenden Kriterien angewendet, bis nur genau ein Schritt übrig bleibt.^B.2

6. Auswahl des Bearbeitungsverfahrens
   Ein Bearbeitungsverfahren ist eine Methode zur Durchführung eines Konfigurierungsschrittes. Die möglichen Verfahren sind unter Schritt 7 aufgeführt. Die Auswahl des jeweiligen Bearbeitungsverfahrens orientiert sich wiederum an der Reihenfolge, in der die Verfahren in der Strategie spezifiziert sind. Kann ein Verfahren nicht angewandt werden (z.B. wenn kein Default-Wert vorhanden ist), wird das jeweils nächste Bearbeitungsverfahren verwendet. Sind keine automatischen Verfahren anwendbar, wird eine Eingabe des Benutzers erwartet.

7. Anwendung des Bearbeitungsverfahrens
   Durch die Anwendung eines Bearbeitungsverfahrens wird ein Konfigurierungsschritt durchgeführt. Hierbei wird für den betreffenden Konfigurierungsschritt ein Wert bzw. ein Ergebnis ermittelt oder ein Wertebereich eingeschränkt. Folgende Bearbeitungsverfahren sind vorgesehen:^B.3
   • Default: Übernahme eines statischen Wertes (z.B. 2.0GHz für die Taktung eines Prozessors).

   • dynamischer Default: Ein dynamischer Default ist eine Funktion zur Auswahl aus dem zulässigen Wertebereich eines Slots (z.B. Mittelwert oder Minimum).

   • Berechnungsfunktion: Eine beliebige durch den Wissensingenieur definierbare Funktion, die zur Auswertung des Bearbeitungsverfahrens aufgerufen wird. Die Berechnungsfunktion wird nur einmalig zur Durchführung des Konfigurierungsschrittes durchgeführt.

   • allgemein zulässiger Wertebereich (AZW): Mit diesem Bearbeitungsverfahren wird verhindert, dass dem Benutzer jeder z.B. durch ein Constraint automatisch festgelegte Slot-Wert zur Bestätigung bzw. Änderung anschließend nochmals vorgelegt wird, wie es das Standardverfahren wäre. Die Änderung eines solchen Wertes durch den Benutzer würde zu einer Inkonsistenz führen und einen Konflikt auslösen, der entsprechend behoben werden müsste (siehe unten).

   • Benutzereingabe: Es wird eine Anfrage an den Benutzer vorgenommen, um den Wert für einen Konfigurierungsschritt zu ermitteln. Der Benutzer besitzt dabei die Möglichkeit, den aktuellen Konfigurierungsschritt zurückzustellen oder andere Bearbeitungsverfahren einzusetzen.

   Die möglichen Bearbeitungsverfahren lassen sich unproblematisch erweitern. Über eine allgemeine Schnittstelle können beliebige Verfahren zur Berechnung eines Konfigurierungsschrittes eingebunden werden. Denkbar sind z.B. Bibliotheks- bzw. fallbasierte Lösungen, die Auswertung von Simulationsprogrammen, etc. (vgl. Günter, 1991a, S. 101).

8. Berechnung der Auswirkungen eines Konfigurierungsschrittes
   Nach der Ausführung des Konfigurierungsschrittes, müssen mögliche Auswirkungen auf andere Konfigurierungsobjekte berücksichtigt werden. Dies können taxonomische Inferenzen und Auswirkungen das Constraint-Netz betreffend sein, die entsprechend berechnet werden müssen. Taxonomische Inferenzen bewirken die Spezialisierung von Komponenten bzw. Aggregaten (vgl. Abschnitt 3.4.4). Die Constraint-Propagation dient der Validierung, ob die aktuelle Teilkonfiguration weiter eingeschränkt werden kann bzw. ob sich Inkonsistenzen ergeben haben (vgl. Abschnitt 3.6).^B.4 Weiterhin prüft der Pattern-Matcher, ob neue Constraints zum Constraint-Netz hinzugefügt werden müssen, weil z.B. neue Komponenten in der aktuellen Teilkonfiguration erzeugt worden sind (vgl. Abschnitt 3.6.1). Taxonomische Inferenzen und Constraints werden so lange propagiert, bis sich keine Änderungen mehr ergeben.

9. Auflösen von Konflikten
   Stellen sich Konfigurierungsentscheidungen als falsch heraus, führt dies zu Konflikten bzw. Inkonsistenzen in der aktuellen Teilkonfiguration. Ein inkonsistenter Zustand ergibt sich z.B. dann, wenn sich ein Oberkonzept aufgrund eines Konflikts mit einem anderen Konzept nicht zu einem seiner Unterkonzepte spezialisieren lässt. Die Wissensbasis definiert in diesem Fall nicht das für den aktuellen Konfigurierungszustand benötigte Konzept. ENGCON unterstützt derzeit die Anwendung eines Konfliktauflösungsverfahrens in Form eines einfachen ,,Undo`` durch den Benutzer.^B.5

10. Aktualisieren der Agenda
    Zum einen werden die Einträge in der Agenda überprüft, ob sie aufgrund von Einschränkungen durch Constraints oder taxonomischen Inferenzen terminal sind und entsprechend entfernt werden können. Zum anderen wird geprüft, ob neue Einträge zur Agenda hinzugefügt werden müssen. Wenn die Agenda leer sein sollte, wird mit Schritt 3 die nächste Strategie ausgewählt, ansonsten fährt der Kontrollmechanismus fort mit Schritt 5, der Auswahl des nächsten Konfigurierungsschrittes aus der Agenda.

Abbildung B.3: Der vollständige zentrale Kontrollzyklus (vgl. Ranze et al., 2002, S. 849 f.)

Fußnoten

...^B.1

In PLAKON und KONWERK waren noch eine Reihe weiterer Auswahlkriterien vorgesehen, auch auf Planungsaufgaben bezogen, die jedoch von ENGCON nicht implementiert werden.

...^B.2

Bei einem nicht eindeutigen Ergebnis wird aus den verbleibenden Konfigurierungsschritten eine zufällige Auswahl getroffen.

...^B.3

In PLAKON war als weiteres Bearbeitungsverfahren die Propagation des Constraint-Netzes vorgesehen. Es gab in diesem System die Möglichkeit, dass Constraint-Netz aus Effizienzgründen nicht bei jedem Durchlauf des Zyklus zu propagieren. In KONWERK hatte man von diesem Vorgehen allerdings bereits Abstand genommen, da es generell wünschenswert ist, möglichst schnell konsistente Werte im Constraint-Netz zu erhalten, und der verwendete Constraint-Solver entsprechend leistungsfähiger war.

...^B.4

PLAKON unterstützte die Möglichkeit, aus Effizienzgründen lediglich Teile des Constraint-Netzes zu propagieren. ENGCON hingegen propagiert immer das vollständige Netz, um zu gewährleisten, dass alle Abhängigkeiten bei jedem Zyklus erfasst werden.

...^B.5

Im Rahmen von ENGCON wurde weiterhin eine Form von abhängigkeitsgesteuertem Backtracking untersucht, bei dem, gestützt auf ein Abhängigkeitsnetz, versucht wird zu ermitteln, welche Konfigurierungsentscheidung den Konflikt verursacht hat. Der Benutzer wird auf diese Weise zu der Stelle geführt, wo der Konflikt ausgelöst wurde. Diese Konfliktbehandlung wurde bisher allerdings lediglich prototypisch umgesetzt.