Die Darstellung von Stücklisten und Operationsplänen für eine variantenreiche Fertigung bereitet in der Praxis nach wie vor Schwierigkeiten. Moniert werden vor allem der immense Wartungsaufwand sowie die hohe administrative Belastung von qualifizierten Fachkräften. Konkrete Lösungsansätze verspricht hier die ExpertensystemTechnik.

Die Abbildung von variantenreichen Produkten durch Teilestämme, Stücklisten und Operationspläne bildete bis heute ein eher unbefriedigend gelöstes Problem. In der Praxis finden sich meistens zwei Vorgehensweisen:

- Stückliste und Operationsplan werden je in einen fixen Teil und variable Teile untergliedert. Der fixe Teil bildet zusammen mit einem der variablen Teile eine mögliche Variante. Die multiplikative "Explosion" der Menge der zu speichernden Stücklisten- und Operationsplanpositionen kann dabei meistens nicht vermieden werden. Der Aufwand, um sie zu warten, ja überhaupt aufzufinden, ist folglich sehr groß. Ein hoher Prozentsatz an gespeicherter Information ist zudem redundant.

- Für jeden Auftrag wird die Variante "von Hand" am Terminal zusammengesetzt. Dies ergibt eine hohe administrative Belastung von qualifizierten Arbeitskräften.

Speicheraufwand wächst additiv mit Problemgröße

Durch Erweiterung der bisher üblichen Stücklisten- und Operationsplan- Strukturen zu einem Expertensystem können beide Nachteile behoben werden: Nur eine Stückliste und einen Operationsplan werden in der erweiterten Form ohne Rendundanz abgespeichert. Der Speicheraufwand wächst additiv mit der Problemgröße und nicht mehr multiplikativ. Für die Auftragsauslösung muß ferner nur noch ein Satz von Parameterwerten eingegeben werden. Die Auswahl der richtigen Variante erfolgt dann automatisch.

Das Expertensystem ist Teil einer mit modernen Mitteln realisierten DV-Lösung im produktiven Einsatz. Bestehende PPS- Lösungen können meistens zu einem solchen Expertensystem erweitert werden.

Die Problemstellung und Zielsetzung soll hier am Beispiel einer Brandschutzklappe demonstriert werden (Abbildung 1).

Diese wird in einen Lüftungskanal eingebaut und unterbricht im Brandfall automatisch den für die Brandausbreitung gefährlichen Luftstrom. Da Lüftungskanäle sich dem Bauobjekt anpassen, muß die Herstellerfirma imstande sein, eine Klappe für praktisch jeden möglichen Querschnitt anzubieten, sogar für nicht metrische Masse. Dazu schreibt der Kunde den Klappentyp und manchmal auch die Kanaltiefe und die Art der Anschlußprofile vor.

Diese Kundenvorgaben wie Klappentyp, Höhe, Breite, Tiefe und Profilart werden im folgenden Parameter genannt. Sie werden als unabhängig bezeichnet, weil der Kunde eine beliebige Kombination von Parameterwerten in seiner Bestellung vorschreiben kann und diese in ihrer Gesamtheit das Produkt eindeutig charakterisieren.

Wegen der geforderten Flexibilität der Kundenvorgaben wird die Klappe nicht in Serie, sondern einzeln hergestellt. Lediglich Halbfabrikate wie Seitenteile, Leisten und Antriebsbausätze können für bestimmte häufig auftretende Parameterwerte in Kleinserien vorgefertigt werden.

Mit den einzelnen Parametern ändern sich natürlich auch die Menge der benötigten Materialien wie Blech, Leisten-, Befestigungs- oder Antriebsmaterial, zusammen zwischen 30 und 50 Stücklistenpositionen. Es ändern sich ebenfalls die Arbeitsanweisungen, zum Beispiel Maschinennummern und Vorgabezeiten, bis hin zur Anzahl Befestigungslöcher und Lochdistanz in den Anschlußprofilen. Es handelt sich um ein sogenanntes Variantenstücklisten- und -operationsplan-Problem:

Stücklisten erweisen sich oft als nahezu identisch

Gegenwärtig werden zwei Klappentypen mit Breiten zwischen 15 Zentimeter und 250 Zentimeter und Höhen zwischen 15 Zentimeter und 80 Zentimeter angeboten. Wollte man für beide Klappentypen und für alle 5 Zentimeter-Abmessungen je eine separate Stückliste und einen separaten Operationsplan abspeichern, so wären das bereits über tausend (genau 2 x 48 x 11).

Die durch die Kombination von Parameterwerten theoretische Zahl von Stücklisten und Operationsplänen geht in die Zehntausende, die praktisch auftretende in die Tausende.

Alle diese Stücklisten und Operationspläne sind einander sehr ähnlich. Und geradezu typisch für diese Art Fertigung ist, daß sie sich sogar über weite Teile als identisch erweisen. Zudem sind die sich verändernden Daten durch die Parameterwerte eindeutig berechenbar. Im Einführungsbeispiel müssen die Abmessungen, der Klappentyp und die anderen Parameter gegeben sein, damit das Produkt eindeutig bestimmt ist.

Multiplikative "Explosion " ist meist unvermeidlich

In einem herkömmlichen System könnte man Stückliste und Operationsplan bei Vorliegen einer Bestellung mit deren Parameter dauernd neu erstellen.

Man fertigt eine Kopie eines mit den letzten Mutationen dauernd ß jour gebrachten Originals, eigentlich einer "Schablone", an. Anschließend wird diese gemäß den aktuellen Parameterwerten abgeändert. Bei sehr vielen Stücklisten- und Operationsplanpositionen ergibt dies eine hohe administrative Belastung von qualifizierten Arbeitskräften.

Werden die einmal erstellten Stücklisten und Operationspläne je doch dauernd in der Datenbank behalten, so wird der Speicher- und Wiederauffindeaufwand für zig-tausend identische Stücklisten- und Operationsplanpositionen fraglich. Und als eigentliches Hauptproblem erweist sich der Wartungsaufwand der so erstellten Tausenden von Stücklisten und Operationsplänen, zum Beispiel aufgrund von Konstruktionsänderungen.

Einige heute auf dem Markt angebotene Lösungen bieten sogenannte "Variantenstücklisten". Stückliste und Operationsplan werden in je einen fixen und variable Teile untergliedert. Der fixe Teil bildet zusammen mit einem der variablen Teile eine mögliche Variante. Die multiplikative "Explosion" der Menge der zu speichernden Stücklisten- und Operationsplanpositionen kann dabei meistens nicht vermieden werden, was die bereits erwähnten Speicherund Wartungsprobleme bringt.

Gesucht ist eine flexible Lösungsstruktur, um die gegebene Problemstellung in den Griff zu bekommen. Es wird ein System benötigt, das Variantenstücklisten und -operationspläne mit mehreren unabhängigen Parametern optimal speichern und verwalten kann. Zudem ist ein möglichst geringer Erstellungs- und Wartungsaufwand sowie eine tragbare Rechnerbelastung erwünscht.

Es gilt natürlich die Voraussetzung, daß alle durch Variantenwahl des Kunden sich verändernden Teile durch die Angabe eines Satzes von Parameterwerten eindeutig bestimmbar sind. In der Praxis bedeutet diese Voraussetzung im allgemeinen keine Einschränkung.

Zu diesem Problemkreis wird ein Expertensystem definiert, dessen Realisation mit einem Datenbankkonzept ausschließlich skizziert wird. Sodann werden die Anwendung auf das Einführungsbeispiel gezeigt und die praktischen Erfahrungen diskutiert.

Das Zusammenspiel der verschiedenen Komponenten eines Expertensystems wird in Abbildung 2 demonstriert.

Gleichzeitig werden auch die Teilnehmer zum Bau und Betrieb eines Expertensystems vorgestellt.

- Ein Informatiker ist zuständig für den Bau eines Expertensystems. Während des Betriebs wird er jedoch nicht mehr benötigt.

- Der Experte erstellt und wartet die Regeln, falls vorhanden, die Metaregel. Beides wird oft auch unter dem Begriff Wissensbasis zusammengefaßt.

- Der Benutzer erfaßt und wartet die Fakten; die in der Faktenbasis gespeichert sind.

- Zur Abfrage von Wissen über Fakten ruft der Benutzer einen Inferenzmotor auf. Dies ist ein Programm, welches Regeln auf Fakten anwenden kann und imstande ist, neue Fakten abzuleiten, welche die eigentliche Frage beantworten.

Wichtig ist die Feststellung, daß der Experte für die Abfrage nicht anwesend sein muß. Im praktischen Fall wird er aber mit den Benutzern einen periodischen Kontakt schaffen, um die Wissensbasis zu vervollkommnen.

Diese eher technisch orientierte Betrachtungsweise soll helfen, die Architektur von Expertensystemen aufzuzeigen:

- Die Wissensbasis ist sowohl von Anwendungsprogrammen als auch von der Faktenbasis getrennt. In der praktischen Realisierung allerdings wird, will man von den Vorteilen der Speicherung in einer Datenbank Nutzen ziehen, die Wissensbasis durch Entitäten der Datenbank dargestellt.

- Der Inferenzmotor ist eine vom Wissen unabhängige Programmlogik. Insbesondere ändert er sich nicht, wenn das Wissen sich ändert.

Wie präsentieren sich die Regeln einer Wissensbasis? Dafür gibt es verschiedene Möglichkeiten. Die bekannteste und intuitiv am einfachsten verständliche bilden die sogenannten Produktionsregeln. Es handelt sich dabei um "Wenn-Dann"-oder "Falls-Dann"-Formulierungen: Falls eine bestimmte Situation gegeben ist (eine Anzahl Fakten), dann schließe (inferenziere) daraus gewisse Aktionen (eine Anzahl Fakten).

Bei Betrachtung der angebotenen Produktreihe vom Standpunkt des Kunden oder des Verkäufers, so gibt es viele "ähnliche" Produkte, die durch die Spezifikation von Parameterwerten unterschieden werden.

Man sagt dann etwa: "Ich möchte eine Brandschutzklappe des Typs 1, mit Länge-a, Breite-b und Tiefe-t, denn Optionen x und y sowie dem Zubehör s, t, und u".

Aus dieser Sicht gibt es sofort eine theoretisch sehr große Zahl von möglichen Produkten: Es sei p(i) der Parameter i (zum Beispiel Typ, Länge, Breite, Tiefe, Optionen, Zubehör, etc.) und p(i) die Anzahl der möglichen Worte für den Parameter p(i). Bei n Parametern ergeben sich

 Ip(i)I = Ip(1) I * Ip(2) I * . . * Ip(n) I 1 <= i <= n

Kombinationsmöglichkeiten, jede mit einer Stückliste und einem Operationsplan. Diese sind zwar in ihrer Gesamtheit alle verschieden. Eine bestimmte Position kann jedoch in vielen dieser Kombinationsmöglichkeiten auftreten.

Sei p(1) die Breite und p(2) die Tiefe. Sei zum Beispiel der Teil X ein zugeschnittenes Blechteil-Halbfabrikat der Breite 800 Millimeter und der Tiefe 240 Millimeter, das unabhängig von den anderen Parameterwerten eingebaut wird.

Dann muß die identische Position in allen verschiedenen Stücklisten vorkommen, die für die Breite 800 Millimeter und die Tiefe 240 Millimeter existieren. Dies ist eine unter Umständen sehr große Zahl, in der Ordnung von

 Ip(i)I = Ip(3)I * Ip(4) * . . * Ip(n)I 3 <= i <= n

Bei Betrachtung dieser Produktreihe vom konstruktiven Standpunkt, wie dies zum Beispiel auch in den Konstruktionsplänen zum Ausdruck kommt, sieht man ein Produkt (nicht viele "ähnliche") mit einer Stückliste und einem Operationsplan.

Die Stückliste enthält sämtliche möglichen Ausgangsteile (Rohmaterialien, Halbfabrikate) je einmal, desgleichen der Operationsplan sämtliche möglichen Operationsplanzeilen je einmal. Durch Tabellen wird dann ausgedrückt, daß gewisse Stücklisten- oder Operationsplanpositionen nur unter gewissen Bedingungen auftreten.

In solchen Konstruktionsplänen steht etwa: "Das Teil X (zum Beispiel ein zugeschnittenes Blechteil-Halbfabrikat) geht mit der Einbaumenge 1 in das Produkt ein, genau wenn die Breite 800 Millimeter und die Tiefe 240 Millimeter beträgt, (wobei die anderen Parameter offenbar jeden Wert annehmen dürfen)."

Oder man liest: "Teil Y (zum Beispiel eine zugeschnittene Leiste) geht in das Produkt ein, und zwar mit der Einbaumenge 1, wenn Länge < 1300 Millimeter oder mit der Einbaumenge 2, wenn die Länge >= 1300 Millimeter."

Oder man liest: "Teil Z (zum Beispiel eine Option) geht in das Produkt zur Einbaumenge 1 ein, falls Typ-2 und Option = x, oder falls Typ = 1 und Option = y."

Was geschieht also? Jede Stücklistenposition (beziehungsweise jede Operationsplanposition) kommt mit jeder ihrer verschiedenen Erscheinungsformen statt in der oben erwähnten, oft sehr großen Zahl, genau einmal vor, zusammen mit einem von den Parametern abhängigen Bedingungssatz.

Produktions-DB stellt die Fakten bereit

Diese bedingte Formulierung von Positionen in Stückliste und Operationsplan entspricht nun genau der Formulierung von Produktionsregeln in einem Expertensystem in der regressiven Form (von der Wirkung zur Ursache):

- Der Bedingungssatz entspricht dabei der "Falls"-Klausel einer Produktionsregel.

- Die Stücklisten-oder Operationsplanposition in erweiterter Form, also inklusive Bedingungssatz, entspricht der Produktionsregel des Expertensystems.

Dem Begriff "Produktionsregel" im Expertensystem entspricht hier also eine "Produktionsregel" im eigentlichen Sinn, das heißt, eines zu fertigenden Produktes.

Die Fakten des Expertensystems werden gebildet durch die Artikel-, Maschinen- und Arbeitsplatz-Daten einer Produktionsdatenbank, sowie durch die Parameterwerte einer Abfrage, zum Beispiel, für einen vorliegenden Auftrag.

Der Inferenzmotor wird in diesem Fall nur für die Vorwärtssteuerung benötigt, zudem nur einstufig. In den "Falls"-Klauseln der Produktionsregeln kommen in den Parametern variable Ausdrücke vor. Der Inferenzmotor liefert durch Auswertung der Produktionsregeln , in deren "Falls"-Klauseln die Parameter vorkommen, die für die eingegebenen Parameterwerte als "Faktum" gültige (Auftrags-) Stückliste und den (Auftrags-) Operationsplan:

Es handelt sich dabei um einige Zeilen Programmcode, die einen logischen Ausdruck in der sogenannten "konjunktiven" Normalform auswerten können.

Die Experten sind die Konstrukteure und Fertigungstechniker des Unternehmens. Sie verwenden übrigens eine den Produktionsregeln entsprechende Ausdrucksweise - meistens unbewußt - , wenn sie ihre Entscheidungstabellen für Variantenstücklisten und -operationspläne zu Papier bringen. Zudem verwenden sie bei komplexen Sachverhalten automatisch die erwähnte disjunktive Normalform.

Daß es sich wirklich um Experten und Expertenwissen handelt, kann aus der Tatsache abgeleitet werden, daß zwei verschiedene Konstrukteure selten die genau gleiche Konstruktion für ein vorgegebenes Produkt abliefern. Ebenso liefern zwei Fertigungstechniker selten den genau gleichen Operationsplan.

Die Benutzer sind die Fertigungssteuerer, die die Fertigungsaufträge auslösen und verfolgen, sowie letztendlich die Mitarbeiter in der Fertigung.

Es ist nun sehr wichtig, die Produktionsregeln in einer den Experten und den Benutzern vertrauten Form zu präsentieren, im Umfeld der gewohnten Begriffe der PPS. Zudem müssen sie in die auf diesem Gebiet gewohnte Datenbankumgebung eingepaßt werden. Die im folgenden entwickelte Lösungsstruktur nimmt besonders auf diese Aspekte Rücksicht.

In Anlehnung an die bereits erwähnten Beispiele sei von folgendem Aufbau der Produktionsregeln ausgegangen, die zusammen die Stückliste / den Operationsplan in erweiterter Form einer Baugruppe bilden:

- Der Identifikationsteil der Position (zum Beispiel Komponentenidentifikation oder Stücklisten- oder Operationsplanpositionsnummer):

Jede Stückliste (beziehungsweise jeder Operationsplan) enthält so viele Identifikationsteile, wie Positionen vorhanden sind, zum Beispiel u Positionen (u >= 1).

- Der "variable" Teil pro Position, im folgenden Variante genannt (zum Beispiel Einbaumenge, Zeiten, Operationstexte / Kapazitätseinheiten): Pro Position x, 1 <= x <= u, gibt es v(x) solcher Varianten, wobei v(x) >= 1 für alle x, 1 <= x <= u ist. Das heißt für jede Position gibt es mindestens eine Variante, gegebenenfalls ist sie die einzige ("Normalfall").

Bei verschiedenen Varianten wählt KI-System die erste

Ohne Beschränkung der Allgemeinheit darf man annehmen, daß bei einer bestimmten Einstellung der Parameterwerte nur eine Variante zur Auswahl steht. Falls mehrere Varianten in Frage kommen könnten, zum Beispiel aufgrund fehlerhafter Angaben, so wird die erste ausgewählt.

- Die "Falls"-Klauseln werden durch eine im Sinne der disjunktiven Normalform verknüpfte Folge von einfachen logischen Ausdrücken (zum Beispiel Relationen wie Typ = 2, Ordermenge > 100, Gültigkeitsdatum < 19850131) gespeichert: Pro Variante y(x), 1 <= y(x) <= v(x), l <= x <= u, gibt es w(y(x)) solcher Relationen, wobei w(y(x)) >= 0 und sinnvollerweise w(y(x)) >= 1, sobald v(x) > l (da sonst die verschiedenen Varianten je unbedingt vorkommen würden).

Eine Verbindung der drei Teile, Identifikationsteil, Variante und "Falls"-Klausel, bildet zusammen eine Produktionsregel.

Die verallgemeinerte Struktur und der bisher übliche Spezialfall sind zum besseren Verständnis in Abbildung drei in graphischer Form aufgezeichnet. Dieser Aufbau bildet tatsächlich eine Erweiterung zu bisherigen Stücklisten- und Operationsplanprozessoren: Wählen wir nämlich v(x) = 1 und w(y(x)) = 0 für 1 = y(x) = v(x) und alle x, l <= x <= u, so haben wir den bisherigen "üblichen" Fall einer "unbedingten" Position mit einer Einbaumenge beziehungsweise Kapazitätseinheit/Text/Zeit.

Für die Realisierung wird der Identifikationsteil und die Variante in einer Entität der Datenbank zusammengefaßt.

Im Falle einer relationalen DB sind die konventionellen Entitäten "Stückliste" und "Operationsplan" lediglich um ein Schlüsselattribut zu erweitern, Dies wird meistens ein Zähler sein, der zusammen mit der Positionsnummer (und natürlich der Baugruppenidentifikation) den Schlüsselbegriff der Entität "Stücklisten" oder "Operationspläne" bildet.

Was die Darstellung der "Falls" Klauseln betrifft, so ergeben sich hier Relationen von sehr einfacher Form:

Die Beispiele zeigen, daß Parameterwerte mit einem Ausdruck in anderen Parameterwerten oder einfach mit einem konstanten Wert verglichen werden.

Die Relationen lassen sich sinnvollerweise in einer eigenen Entität führen, wobei der Schlüssel der um einen weiteren Zähler für die Relationen erweiterte Schlüssel der Stücklisten- oder Operationsplanentität ist.

Ein weiteres Attribut der Entität "Relation" wird zur Identifikation der Verknüpfung im Sinne der disjunktiven Normalform geführt:

Man kann eine einfache Angabe "o" für die Oder- Verknüpfung sowie " " (leer) für die Und-Verknüpfung wählen. Die Relation ist dann mit den vorhergehenden Relationen für die gleiche Variante mit der entsprechenden Verknüpfung verbunden.

Die Relation selber kann - je nach ihrer Komplexität - auf verschiedene Weise implementiert werden. In einfacheren Fällen wird eine formatisierte Relation am schnellsten zu realisieren sein.

Im einfachsten Fall wird ein Parameterwert mit einem konstanten Wert verglichen. Wir benötigen lediglich drei Felder, um die Relation zu beschreiben:

Dies heißt übersetzt, daß die entsprechende Variante zum Zug kommt, "falls (die Länge kleiner als 18.5 und der Typ gleich 2) oder die Ordermenge nicht kleiner als 400" ist.

Für sehr komplizierte Verhältnisse empfiehlt es sich einen Formelscanner einzusetzen, um die Relation, beziehungsweise die linke und die rechte Seite der Relation, im Freiformat nach den Regeln der Algebra anzugeben.

Der Inferenzmotor bestimmt für jede Position die erste Variante, für die eine Auswertung der "Falls"-Klausel den Wert "wahr" ergibt.

Die Belastung der Rechner ist - vor allem bei sehr variantenreichen Produkten - sehr hoch. Dies hauptsächlich deshalb, weil für die Ermittlung der zu einer bestimmten Parametereinstellung gehörenden Positionen im allgemeinen mehr Stücklisten- und Operationsplanpositionen (das heißt Varianten) gelesen werden, als schlußendlich in den Fabrikationsauftrag eingestellt werden. Dazu kommt der Aufwand für das Behandeln der Relationen.

Die Praxis hat gezeigt, daß für komplexe Verhältnisse zudem Einbaumenge und Texte nicht konstant, sondern ebenfalls von den Parametern abhängig sind.

Verbindung zu CAD/CAM schafft viele Vorteile

Im konkreten Fall wurde dafür ein Formelgenerator entwickelt, der einen algebraischen Ausdruck mit den Grundrechenarten, Klammern und Konstanten, variabel in den Parametern, nach den Gesetzen der Algebra und der Arithmetik auswerten kann. Die Formeln werden wiederum durch die Anwender gewartet.

Ein noch nicht abzuschätzender Vorteil ist in der Verbindung zu den Gebieten CAD/CAM zu sehen. Mit CAD wird eine Zeichnung für alle Varianten erstellt, innerhalb CAM wird ein (parameterisiertes) Programm zur Steuerung der Maschinen erstellt. Durch die ExpertensystemTechnologie wird im PPS eine Stückliste und ein Operationsplan für alIe Varianten geführt. Die Schnittstellen sind in natürlicher Weise vorgegeben: zum CAD die Produktionsregeln, zum CAM die Auftragspapiere mit dem Satz von Parameterwerten, welche als Input des CNC-Programmes dienen.

*Dr. Paul Schönsleben ist Professor an der Universität Neuchatel, Schweiz.

Der Beitrag basiert auf einer modifizierten Passage aus dem Buch "FIexible PPS mit Computer" von Professor Dr. Paul Schönsleben, erschienen bei CW-Publikationen, München (1985).