next up previous contents index
Nächste Seite: 3. Wissensbasierte Konfigurierung am Aufwärts: 2. Wissensbasierte Konfigurierung Vorherige Seite: 2.2.6 Verhaltensbasiertes Konfigurieren   Inhalt   Index

2.3 Konfigurierungswerkzeuge

Im Folgenden werden eine Reihe von bestehenden Konfigurierungswerkzeugen und die jeweils eingesetzten Methoden benannt. Die vorgestellten Systeme stellen lediglich eine exemplarische Auswahl dar. Eine ausführliche Beschreibung der einzelnen hier genannten Systeme ist dem Anhang A ff. zu entnehmen.

Zunächst ist eine Reihe historischer Systeme zu erwähnen, deren Eigenschaften für die Entwicklung von ENGCON und dessen Vorgänger z.T. eine besondere Bedeutung hatten. Die erste Konfigurierungsanwendung überhaupt war Anfang der 80er Jahre das bereits erwähnte System XCON, der klassische Vertreter des regelbasierten Ansatzes. Die große Anzahl Regeln zur Konfigurierung einer Vielzahl komplexer Objekte führte schließlich zu einem erheblichen Software-Wartungsproblem (vgl. Neumann, 1988, S. 34). Das System SICONFEX, ebenfalls in den 80er Jahren entwickelt, war bereits mit einer hochstrukturierten Wissensbasis ausgestattet, die Schemata und Vererbungsmechanismen unterstützte. Inferenzmechanismus war weiterhin ein, wenn auch erweiterter, Regelmechanismus. Eine weitere Strukturierung des Domänenwissens wurde in den Systemen MMC-KON und ALL-RISE vorgenommen: Neben is-a gibt es hier auch bereits has-parts Relationen innerhalb von Spezialisierungs- und Zerlegungshierarchien. In ALL-RISE werden Abhängigkeiten zudem bereits durch Constraints repräsentiert und propagiert. Alle genannten Systeme wurden zum Lösen jeweils spezifischer Konfigurierungsaufgaben entworfen und eingesetzt (vgl. Neumann, 1991).

Moderne Konfiguratoren besitzen eine domänenunabhängige Wissensrepräsentation. Sofern sie in überschaubaren Domänen eingesetzt werden, verwenden sie aus Gründen der Akzeptanz zumeist relativ einfache Inferenzmechanismen. Der CAS-KONFIGURATOR und CAMELEON EPOS setzen sowohl Regeln als auch Entscheidungsbäume zur Steuerung des Konfigurierungsprozesses ein. Im CAMOS.CONFIGURATOR werden sog. ,,passive`` Constraints verwendet. Passive Constraints sind Regeln, die bidirektional ausgewertet werden, jedoch keinen Einfluss auf den Kontrollfluss haben (vgl. Günter et al., 1999). Ebenfalls eine eingeschränkte Art Constraints, sog. ,,gerichtete`` Constraints, nutzt das Konfigurierungswerkzeug COMIX (vgl. Sutschet, 2001). Der Konfigurator SALESPLUS (vgl. Yu und Skovgaard, 1998) von Baan verfügt über ein eigens implementiertes Constraint-System, welches die Verarbeitung spezieller Constraint-Typen zur Unterstützung des Konfigurierungsvorgangs ermöglicht. Die Konfigurierung selbst zeichnet sich allerdings lediglich durch die konsistente Anpassung bestehender Standard-Produktmodelle aus. Bei der SALES CONFIGURATION ENGINE (SCE) von SAP kommt ein Truth Maintenance System (TMS) zum Einsatz. Ziel ist es, dadurch ein wissensbasiertes Backtracking zum Auffinden von Fehlerursachen bei Konfigurierungskonflikten und die Interpretation von Design-Entscheidungen zu ermöglichen (vgl. Günter und Kühn, 1999, S. 59).2.6 Die Systeme COSMOS (vgl. Günter et al., 1999) und KIKON (vgl. Emde et al., 1996) sind Beispiele für ressourcenbasierte Konfigurierungswerkzeuge. Sie bieten für Domänen, deren Objekte sich als Ressourcen modellieren lassen, eine Abstraktion von einzelnen Komponenten auf deren Ressourcenforderung bzw. -angebot.

Bei modernen Konfigurierungsanwendungen, die zur Bearbeitung umfangreicher Domänen mit komplexen Abhängigkeiten entworfen wurden, setzt man überwiegend auf erweiterte constraint-basierte Ansätze, welche die Dynamik des Konfigurierungsverlaufs angemessen unterstützen. So besitzt der TACTON CONFIGURATOR ein dynamisches Constraint-System, welches ein während der Konfigurierung anwachsendes Constraint-Netz unterstützt (vgl. Orsvärn und Axling, 1999). Die Constraint-Lösungsmechanismen von LAVA (vgl. Fleischanderl et al., 1998) und ILOG CONFIGURATOR (vgl. ILOG, 2001) bzw. JCONFIGURATOR (vgl. ILOG, 2003) implementieren Generative Constraint Satisfaction, ein ebenfalls dynamischer Constraint-Formalismus, der den Anforderungen zur Behandlung von komplexen Konfigurierungsproblemen gerecht wird (vgl. Abschnitt 4.4).

Gegenstand aktueller Forschung ist das Konfigurierungswerkzeug CONBACON (vgl. John und Geske, 2002). Der Schwerpunkt von CONBACON liegt auf einem Constraint-System, welches die effiziente Behandlung einer Rekonfigurierung nach Erhalt von Änderungswünschen des Anwenders ermöglicht. Das Projekt CAWICOMS (vgl. Ardissono et al., 2002), ebenfalls aktueller Forschungsgegenstand, hat zum Ziel, ein B2B-Framework zur verteilten Produktkonfigurierung von Waren und Dienstleistungen anzubieten. Dafür kommen neben dem JCONFIGURATOR als Inferenz-Engine moderne Web-Technologien zum Einsatz.

Sowohl ENGCON (vgl. Hollmann et al., 2000) als auch dessen Vorläufer PLAKON (vgl. Cunis et al., 1991) und KONWERK (vgl. Günter, 1995a) sind ebenfalls für variantenreiche Konfigurierungsszenarien geeignet. Sie sind in erster Linie strukturbasierte Konfigurierungswerkzeuge. Der Schwerpunkt dieser Systeme liegt daher auf einem begriffshierarchie-orientierten Kontrollmechanismus. Zusätzlich kommen weitere Inferenzmechanismen zum Einsatz, wie z.B. ein ausgereiftes Constraint-System. Auf das Konfigurierungssystem ENGCON wird in dem folgenden Kapitel ausführlich eingegangen.



Fußnoten

...2.6
Bei der Rücknahme von Entscheidungen lassen sich auf diese Weise Abhängigkeiten identifizieren und ggf. weitere Konfigurierungsschritte ebenfalls zurücknehmen.

next up previous contents index
Nächste Seite: 3. Wissensbasierte Konfigurierung am Aufwärts: 2. Wissensbasierte Konfigurierung Vorherige Seite: 2.2.6 Verhaltensbasiertes Konfigurieren   Inhalt   Index