Fuzzylogik und Regelbasierte Systeme

Transkript

1 Fuzzylogik und Regelbasierte Systeme Ausarbeitung für das Masterprojekt: Thomas Beermann Dennis Huning Dennis Löhr

2 Inhaltsverzeichnis I. Übersicht Autor: Dennis Löhr, B.Sc Übersicht Einleitung Fuzzy-Logik Klassische Logik vs. Fuzzy-Logik Fuzzysets Fuzzifizierung Defuzzifizierung Fuzzy Operatoren Fuzzy-Controlling Einleitung Implikation Anwendungen Regelbasierte Systeme Einleitung Die Regelbasis Die Faktenbasis Inferenzmaschine Vorwärtsverkettung Rückwärtsverkettung Zusammenfassung Herkunft Jefis II. Jefis Drools Adapter Autor: Dennis Huning, B.Sc Jefis Drools Adapter Einleitung Der Rete-OO Algorithmus Überblick Erzeugen eines deterministischen Baumes ii

3 Inhaltsverzeichnis Laufzeit Ausführung Beispiel eines Baumes Erweiterung des Rete-OO Algorithmus um Fuzzy Logik Drools Chance Adapter III. Jefis Ruleengine Autor: Dennis Löhr, B.Sc Jefis Ruleengine Einleitung Beispiel in Lab4Jefis Die Lab4Jefis Rule-Engine IV. FCL und ANTLR Autor: Thomas Beermann, B.Sc FCL und ANTLR FCL Einleitung Beispiel Beschreibung VAR INPUT / VAR OUTPUT FUZZIFY / DEFUZZIFY RULEBLOCK ANTLR Einleitung Lexer/Parser Beispiel Benutzung in Java Treewalker Beispiel V. Anhang ANTLR 39 A. Fcl.g B. FCLTreeWalker.g Jefis Ruleengine 45 Abbildungsverzeichnis 46 iii

4 Inhaltsverzeichnis Literaturverzeichnis 47 iv

5 Einleitung Diese Ausarbeitung dokumentiert das Masterprojekt 2009/2010 im Labor für Informatik an der Fachhochschule Münster - Fachbereich Elektrotechnik und Informatik. Thema des Masterprojektes war es Fuzzy-Logik und klassische Regelbasierte Systeme zu verbinden. Das Kapitel 1 beschreibt dafür die Grundlagen im Bereich Fuzzy-Logik und Regelbasierte Systeme, die für das Verständnis der Ausarbeitung erforderlich sind. Nachfolgend stellt das Kapitel 2 den ersten Teil bzw. das erste Semester des Masterprojektes dar. Hierbei geht es hauptsächlich um die Fuzzy-Erweiterung von drools:chance, das ein Unterprojekt von Drools 1 ist. Im Weiteren wird das zweite Semester geschildert. Nach dem Abschluss des drools:chance Projektes wurde das Projekt Jefis um Ruleengine Funktionalitäten erweitert. Das Kapitel 3 beschreibt, wie die Ruleengine für Jefis implementiert wurde und gibt zum Schluss noch ein ausführliches Beispiel für die Benutzung. Ein wichtiger Bestandteil der Ruleengine ist es Regeln und Fuzzysets aus einer Datei auslesen zu lassen. Dafür war es notwendig eine einheitliche Form zu bestimmen, die in der Fuzzy Control Language (FCL) gefunden wurde, beschrieben in Kapitel 4.1. Zuletzt bestand dann noch das Problem diese FCL-Dateien mit Java auszulesen und in Jefis- Objekte umzuwandeln. Aus verschiedenen Gründen, erläutert in Kapitel 4.2, wurde dafür ANTLR genommen

6 Teil I. Übersicht Autor: Dennis Löhr, B.Sc. 2

7 1. Übersicht 1.1. Einleitung Dieses Kapitel gibt eine Übersicht über die notwendigen Grundlagen um den weiteren Teil der Ausarbeitung nachzuvollziehen. Es werden grundlegende Aspekte von Fuzzy erklärt, wie beispielsweise Fuzzysets, Fuzzifizierung oder Fuzzy-Operatoren. Im Abschnitt Regelbasierte Systeme werden Themen wie Faktenbasis, Inferenzmaschinen und Vorwärtsverkettung erläutert. Abschließend gibt der Abschnitt Jefis einen Überblick über das im Labor für Informatik der FH-Münster entstandene gleichnamige Projekt Fuzzy-Logik Klassische Logik vs. Fuzzy-Logik In der klassischen Logik kann ein Element x X entweder einer bestimmten Menge A zugeordnet werden oder nicht. Schnell ist ersichtlich, dass es in vielen Fällen einer weicheren Betrachtung bedarf. Als Beispiel sei hier eine Regel zur Lüftersteuerung genannt, die Regel besagt, dass die Kühlung ab einer Temperatur größer 80 C angeschaltet wird. Eine minimale Abweichung um -0,0001 von der kritischen Temperatur würde in der klassischen Logik nicht zum Einschalten der Kühlung führen. Wodurch es in diesem Beispiel zu einer unnötig langen thermischen Überstrapazierung der CPU und daraus resultierend zu einer schnelleren Alterung kommt. Ein anderes Systemverhalten ist in der klassischen Logik nicht möglich, da für die Indikatorfunktion oder Charakteristische Funktion χ A der Menge A gilt: χ A : X {0, 1} { } 1 : x A χ A (x) = 0 : x / A Um eine solche Einschränkung zu umgehen, erweitert die Fuzzy-Logik die zweielementige Menge {0, 1} auf das abgeschlossene Intervall I:= [0, 1]. Die so entstehende Lösungsmenge à wird als Fuzzy-Menge bezeichnet und besteht aus geordneten Paaren der Form: à = {(x, µã(x)) x X} Durch µ ist auf dieser Menge eine Funktion definiert, die den Grad angibt, zu dem ein Element x X in der Menge à enthalten ist. Die Funktion µ wird als Zugehörigkeitsfunktion bezeichnet. 3

8 KAPITEL 1. ÜBERSICHT Abbildung 1.1.: Beispiel Fuzzy Partition für einen Wertebereich von 0 bis Fuzzysets Damit die Zugehörigkeitsfunktion überhaupt den Wert der Zugehörigkeit ermitteln kann, muss über der Menge à eine beliebige Funktion beschrieben werden. Eine solche Funktion wird als Fuzzyset bezeichnet. Mehrere Fuzzysets werden zu einer Fuzzy Partition zusammengefasst. In der Abbildung 1.1 wird eine Beispiel Partition mit drei Fuzzysets gezeigt. Wie das Beispiel zeigt können beliebige Funktionen genutzt werden um ein Fuzzyset zu beschreiben. Zusätzlich sieht man, dass ein Wert mehrere Zugehörigkeitswerte haben kann, z.b. für den Wert 45 liefert µ(45) = {0, 0.7, 0.5}. Das bedeutet, dass der Eingabewert von 45 zu 0% im ersten Fuzzyset, zu 70% im Fuzzyset zwei und zu 50% im dritten Fuzzyset liegt Fuzzifizierung Bei der Fuzzifizierung wird für einen scharfen Wert in einem dazugehörigen Fuzzyset die Zugehörigkeit ermittelt, dafür wird aber erstmal ein Eingabe-Fuzzyset benötigt. In diesem Fuzzyset wird der Zugehörigkeitsgrad wie in Abbildung 1.1 bestimmt. Hierbei wird von der X-Achse bei dem scharfen Wert senkrecht bis zu dem Fuzzyset gegangen und dann die Zugehörigkeit auf der Y-Achse abgelesen. Hierbei können verschiedene Verfahren benutzt werden um dies dann in ein Eingabe-Fuzzyset umzuwandeln. Eines dieser Verfahren funktioniert so: Das betreffende Eingabe Fuzzyset dadurch gebildet wird, dass das zugehörige Fuzzyset bis zur Zugehörigkeit gefüllt wird. Bei einem weiterem Verfahren wird das zugehörige Fuzzyset mit der Zugehörigkeit Multipliziert. Es gibt noch andere Verfahren die hier allerdings nicht weiter beschrieben werden Defuzzifizierung Für die Defuzzifizierung gibt es auch mehrere Methoden dies zu machen die wohl am weitesten verbreitete Methode ist die Schwerpunktmethode (center of gravity). Die Defuzzifizierung eines Sets sehen wir in Abbildung 1.2. In diesem Beispiel wurde die Schwerpunktmethode verwendet, durch die Verteilung und den Füllstand der Sets ergibt sich der Schwerpunkt bei 28,57%. Zusätzlich zu dieser gibt es auch noch die Maximum Methode, hierbei wird das Maximum innerhalb des Fuzzysets gesucht und als defuzzifizierter Wert zurückgegeben. Dabei gibt es drei Methoden: 4

9 KAPITEL 1. ÜBERSICHT Abbildung 1.2.: Beispiel Defuzzifizierung über die Schwerpunktmethode 1 x y x y x y x Tabelle 1.1.: Wahrheitstabelle der klassischen Logik 1. Linkes Maximum - hier wird von links das Maximum gesucht. 2. Rechtes Maximum - hier wird von rechts das Maximum gesucht. 3. Mittleres Maximum - hier wird erst das linke und das rechte Maximum gesucht und anschließend der Mittelwert gebildet Fuzzy Operatoren In der klassischen Logik ist es möglich mehrere Elemente verschiedener Mengen über die Operatoren, und, zu verknüpfen (Tabelle 1.1). Da die Fuzzy-Logik nicht aus einer endlichen Mengen von Möglichkeiten besteht wird schnell ersichtlich, dass man die Operatoren nicht eins zu eins auf die Fuzzy-Logik überführen kann. Daher müssen spezielle Operatoren eingeführt werden, die die gleichen Ergebnisse wie in Tabelle 1.1 liefern. Eine Lösung dieses Problems ist es die Operatoren durch die in Tabelle 1.2 gezeigten Funktionen zu ersetzen. Die sich dadurch ergebene Wahrheitstabelle wird in Tabelle 1.3 gezeigte. Wie man leicht erkennen kann, liefern die Funktionen für die Grenzwerte 0 und 1 die gleichen Ergebnisse. Diese Norm wird auch MINMAX-Norm genannt. 1 Quelle der Graphik ist das Labor für Prozessinformatik und Prozesslenkung, FH-Münster - Fachbereich Elektrotechnik und Informatik 5

10 KAPITEL 1. ÜBERSICHT x y min(x,y) t-norm x y max(x,y) s-norm x 1-x c-norm Tabelle 1.2.: Abbilden der Operationen auf Funktionen x y min(x,y) max(x,y) 1-x Tabelle 1.3.: Wahrheitstabelle der Fuzzy-Logik Fuzzy-Controlling Einleitung Fuzzy-Controlling wird in der Elektrotechnik seit den 1970er Jahren eingesetzt. Zu Beginn aber fast ausschließlich im asiatischen Raum. In der Elektrotechnik werden Fuzzy- Controller als Regler eingesetzt, wobei diese genauso wie andere Regler auch mit scharfen Eingabewerten versorgt werden. Abbildung 1.3.: Beispiel Fuzzy-Regler in einem Schaltbild Aber anders als bei anderen Reglern fuzzifiziert der Fuzzy-Regler die Eingabewerte bevor er mit den Daten arbeitet. Wenn die Eingabedaten dann für den Fuzzy-Regler aufbereitet wurden, verarbeitet der Regler die Eingaben mit seinen Regeln. Nachdem die internen Regeln des Fuzzy-Reglers dann abgearbeitet sind, werden die Ausgabewerte defuzzifiziert. Das Defuzzifizieren wird gemacht um wieder scharfe Werte für z.b. eine Motorsteuerung zu erhalten. Auch beim Fuzzy-Controlling ist es möglich Fuzzy- Regler zu verketten, um so eine Hintereinanderausführung von verschiedenen Regeln zu ermöglichen. Das wird allerdings in der Praxis nicht gemacht da dies nur die Komplexität des Systems unnötig steigern würde. 6

11 KAPITEL 1. ÜBERSICHT Implikation Die Implikation ist der Kernbestandteil des Systems, hier gibt es eine Vielzahl an verschiedenen Verfahren. Einige dieser Verfahren sind Goedel,Lucasiewicz oder Zadeh, in technischen Systemen wird aber meist nur Larsen oder Mamdani eingesetzt. Wobei die Mamdani Implikation die am meisten genutzte in der Elektrotechnik ist. Allgemein beschrieben wird bei der Implikation bestimmt, zu welchem Anteil die einzelnen Werte innerhalb eines Fuzzysets erfüllt sind. Bei der Mamdani Implikation µ A B (x, y) := min{µ A (x), µ B (x)} wird beispielsweise ein Wert innerhalb eines Fuzzysets bis zum Maximum der Schnittmenge gefüllt Anwendungen In der Elektrotechnik werden Fuzzy-Systeme mit den folgenden Vor- bzw. Nachteilen beschrieben. Vorteile sind, dass Lösungen auch möglich sind, wenn Kein in sich geschlossenes mathematisches Modell des Prozesses, z.b. in Form von Differentialgleichungen, existiert oder gefunden werden kann, oder wenn die Komplexität des Problems für eine solche Modellierung zu groß ist. Unscharfe und vage Aussagen oder intuitive Einschätzungen zur Modellierung des Sachverhalts herangezogen werden müssen. Viele Eingangsparameter und hohe Nichtlinearität vorliegen. Nachteile sind: Die Beliebigkeit bzw. die Freiheit, die der Entwickler bei der Wahl und Implementierung des Fuzzy-Modells hat. Es existieren keine standardisierten Vorgehensweisen, um Erfahrungswissen in die Daten- und Regelbasis eines Fuzzy-Systems umzusetzen. Die Beliebigkeit bzw. die Freiheit, die der Entwickler bei der Modifizierung eines Fuzzy-Modells zur Feinabstimmung oder Ergebnisverbesserung hat. Hierzu existieren ebenfalls keine standardisierten Methoden. Die Anpassung eines Fuzzy-Modells an veränderte Parameter kann daher schwierig und zeitaufwendig werden oder auch scheitern. Fuzzy-Systeme besitzen keine Lernfähigkeit, die Regeln und Zugehörigkeitsfunktionen müssen vom Entwickler entworfen und optimiert werden. [Nel05] Auch bei Systemen bei denen man annehmen würde, dass dort besonders auf eine mathematische Beweisbarkeit geachtet wird gibt es Gegenbeispiele. Eines dieser Gegenbeispiele ist ein Raketen Zielsystem. In der Diplomarbeit von Alfons Möllers 2 wurde ein 2 Quelle für das Beispiel ist die Diplomarbeit von Alfons Möllers an der FH Münster aus dem Jahr

12 KAPITEL 1. ÜBERSICHT Abbildung 1.4.: Flugbahn und Geschwindigkeitskorrektur über Fuzzy Abbildung 1.5.: Schaltplan der Flugbahn und Geschwindigkeitskorrektur Problem beschrieben bei dem Es die Aufgabe war ein System zu entwerfen, dass die Geschwindigkeit eines Flugobjekts so anpasst das dieses zum richtigen Zeitpunkt am Ziel ankommt. Hierbei muss man jedoch erwähnen das durch einen Fuzzy-Regler nur Korrekturwerte an die eigentliche Flugkontrolle geliefert werden und nicht das ganze System auf Fuzzy-Controlling basiert. Ein weiteres Beispiel ist das inverse Pendel 3. In einem Versuchsaufbau an der Fachhochschule Münster ist es sogar möglich, ein gefülltes Bierglas auf das inverse Pendel zu stellen, wie in Abbildung 1.6 zu sehen ist. Beim Versuchsaufbau wird an einem beweglichen Schlitten über ein Kugellager eine Stange befestigt. Ziel des Systems ist es die Stange in eine aufrechte Position zu bekommen. Dies gilt als schönes Beispiel, denn über eine normale Regelung ist es nicht möglich den gesamten Vorgang in einen Regler abzubilden. Da es sich bei Normalen Regler meist um lineare Systeme handelt. Wenn dieses Problem versucht wird über normale Regler 3 Quelle für das Beispiel ist die Diplomarbeit von Stefan Tombrock an der FH Münster aus dem Jahr

13 KAPITEL 1. ÜBERSICHT zu lösen, ist hierfür notwendig das die zugehörigen Differentialgleichungen für viele Positionen linearisiert wird. Durch den Einsatz von einem Fuzzy-Regler ist es möglich, das Ganze in einem Regler zu implementieren. Eine Lösung hierfür ist das Aufstellen der Regeln die in Abbildung 1.7 zu sehen sind, zusammen mit den Fuzzysets aus Abbildung 1.6. Abbildung 1.6.: Bierglas auf Inversen Pendel; Fuzzysets des Beispiels Abbildung 1.7.: Regeln des Inversen Pendels 1.3. Regelbasierte Systeme Einleitung Ein Regelbasiertes System besteht aus einer Faktenbasis, einer Regelbasis und einer Inferenzmaschine. Hierbei stellt die Inferenzmaschine den Kern des Systems dar, da 9

14 KAPITEL 1. ÜBERSICHT die Inferenzmaschine aus den in der Regelbasis enthaltenen Regeln zusammen mit den gegebenen Fakten Schlussfolgerungen bildet. Hierbei wird beispielsweise aus dem Fakt, dass es gerade regnet gefolgert, dass die Straßen nass sind. Was im weiteren Verlauf noch genauer erklärt wird. Abbildung 1.8.: Komponenten eines Regelbasierten Systems [Bec] Die Regelbasis ist eine Sammlung von Wissen. Diese Regeln sind folgendermaßen aufgebaut: WENN (Prämisse / Voraussetzung) DANN (Konklusion durch eine Aktion). Sollte das Wissen nicht in dieser Form vorliegen so muss es umgeformt werden, dies wird beispielsweise aus dem Wissen Alle Vögel können fliegen = Wenn ein Tier ein Vogel ist, dann kann es fliegen. Diese Regeln werden aber nicht einfach fest integriert, sondern dynamisch hinzugefügt. Dadurch ist es möglich das System auf viele spezielle Anwendungsgebiete anzupassen oder das System an sich ändernde Anforderungen anzupassen. Dies ist auch notwendig, denn einer IDC-Studie zufolge ändern sich ca. 45% aller Regeln in einem Release-Zyklus [DWM08]. Aktuelle Beispiele für Systeme bzw. Notationen, mit denen Regeln erstellt werden können sind: JBOSS-Rules, Ross-Notation, AORML - Agent Object Relationship Modeling Language, ORM - Objekt Role Modeling Language und URML - UML-Based Rule Modeling Language. [Dre]. 10

15 KAPITEL 1. ÜBERSICHT Die Faktenbasis setzt sich aus allen bekannten Fakten zusammen. Hierbei kann es sich sowohl um Messwerte, Symptome oder auch um Ergebnisse aus vorherigen Berechnungen handeln. Zu dem gibt es auch Regelsysteme die gezielt Fragen stellen, um beispielsweise medizinische Diagnosen zu stellen. Ein Beispiel ist hierfür das medizinische Diagnosesystem MYCIN. MYCIN ist in den 70er Jahren als ein Konsultationssystem zur Diagnose und Therapie von Infektionskrankheiten durch Antibiotika entwickelt worden. [Bei06] Durch die Trennung des Wissens, was in den Regeln definiert ist und dem Verarbeiten des Wissens in der Inferenzmaschine werden einige Eigenschaften von Regelbasierten Systemen begründet. Folgende Eigenschaften von Regelsystemen stammen von Torben Pullmann [Pul00] Transparenz: Aufgrund der transparenten Wissensrepräsentation kann das Verhalten von wissensbasierten Systemen in einfacher Weise erklärt und vorhergesagt werden. Flexibilität: Wissen kann in einfacher Weise hinzugefügt und entfernt werden. Benutzerfreundlichkeit: Der Umgang mit wissensbasierten Systemen erfordert kein programmiertechnisches Vorwissen. Kompetenz: Wissensbasierte Systeme verfügen in ihrem Anwendungsbereich über eine hohe Problemlösungsfähigkeit Inferenzmaschine Für die Inferenzmaschine selbst gibt es zwei grundsätzliche Vorgehensweisen, die Vorwärtsverkettung und die Rückwärtsverkettung. Bei der Vorwärtsverkettung wird versucht aus den vorhandenen Informationen, durch die Auswertung neue Informationen zu generieren. Das Verfahren wird auch in Abbildung 1.8 verwendet. Ein Beispiel für dieses Verfahren ist. Aus den Regeln: 1. Wenn man viel Schokolade isst, dann nimmt man viele Kalorien auf. 2. Wenn man viele Kalorien aufnimmt, dann wird man dick. Wenn jetzt bekannt ist, dass jemand viele Kalorien zu sich nimmt, folgern wir aus der zweiten Regel, dass diese Person dick ist. Dies ist die einfache Inferenz, da hier noch nicht das Ergebnis einer anderen Regel ausgewertet wird Vorwärtsverkettung Wenn aber die Inferenzmaschine die Vorwärtsverkettung verwendet, brauch nur bekannt sein, dass eine Person viel Schokolade isst. So können wir daraus folgern, dass diese Person viele Kalorien zu sich nimmt und daraus wieder das diese Person dick ist. Dieses Verfahren hat aber einen Nachteil, um beispielsweise einen bestimmten angestrebten Zustand zu erreichen, müssten bei der Vorwärtsverkettung alle Möglichkeiten der Faktenbasis durchgegangen werden. 11

16 KAPITEL 1. ÜBERSICHT Rückwärtsverkettung Dies wird von der Rückwärtsverkettung besser behandelt. Haben wir wieder die vorherige Regel gegeben und der Zustand den wir anstreben ist es herauszufinden, warum eine bestimmte Person übergewichtig ist, so können wir unsere Regeln auswerten, die das gewünschte Ergebnis haben. In diesem Fall wäre das die zweite Regel, die besagt Wenn eine Person viele Kalorien zu sich nimmt, dann wird sie dick. Aber das ist nicht die einzige Möglichkeit, sondern wir haben noch die Regeln, die die Prämisse der zweiten Regel als Konklusion haben, was bei der ersten Regel gegeben ist. Daraus ergibt sich das Ergebnis mit dieser Regelbasis, dass eine Person dick ist, wenn sie viele Kalorien zu sich nimmt oder viel Schokolade isst Zusammenfassung Zusammengefasst bezeichnet der Begriff der Inferenz das Gewinnen von neuen Fakten aus alten Fakten. Um die Faktenbasis zu erweitern und noch mehr Fakten zu erzeugen. Um eine Schleifenbildung zu verhindern, die im Normalfall auftreten würde, wird ein Beispiel gegeben. Als Regeln gelten wieder die beiden bekannten: 1. Wenn man viel Schokolade isst, dann nimmt man viele Kalorien auf. 2. Wenn man viele Kalorien aufnimmt, dann wird man dick. Wenn in diesem Fall die Faktenbasis den Input bekommt, dass jemand viel Schokolade isst, generiert die erste Regel daraus, dass diese Person viele Kalorien zu sich nimmt. Für die nächste Iteration haben wir also in der Faktenbasis das Wissen, dass eine Person viel Schokolade isst und viele Kalorien zu sich nimmt, damit können wir jetzt beide Regeln wieder ausführen. Damit würde also eine Endlosschleife laufen, da kein Wissen aus der Faktenbasis entfernt wird. Aus diesem Grund wird bei einer Inferenzmaschine noch eine Konfliktmenge gebildet. Die Konfliktmenge stellt die aktiven Regeln dar, an dem Beispiel erklärt heißt das für die Faktenbasis und die Konfliktmenge, dass sie leer sind. Geben wir nun zur Faktenbasis die Information hinzu, dass jemand viel Schokolade isst, so werden der Konfliktmenge auch alle Regeln hinzugefügt, die von der aktuellen Faktenbasis bedient werden können. Nachdem dann die Regeln aus der Konfliktmenge gefeuert wurden, werden die neu gewonnenen Informationen der Faktenbasis hinzugefügt. Dabei werden alle vorherigen aktiven Regeln aus der Konfliktmenge entfernt und im Anschluss die Regeln hinzugefügt die durch die neuen Informationen gefeuert werden können. Damit würde also nach der ersten Iteration bzw. dem Ausführen der ersten Regel nur die zweite Regel in der Konfliktmenge enthalten sein, wodurch wir das Problem der Endlosschleife für dieses einfache Beispiel gelöst haben Herkunft Als Geburtsstunde der künstlichen Intelligenz wird ein Workshop in Dartmouth im Sommer des Jahres 1956 angesehen, der von John McCarthy, Marvin Minsky, Nathan Rochester und Claude Shannon organisiert wurde. Durch diesen Workshop hat sich auch 12

17 KAPITEL 1. ÜBERSICHT der englische Name artificial intelligence durchgesetzt. Vor diesem Workshop wurden Computer nur als arithmetische Rechenmaschinen angesehen. Nach diesem Workshop aber haben die Teilnehmer, an verschiedenen Einrichtungen, versucht dem Computer mit Wissen über einzelne Fachgebiete zu versehen, woraus auch die Regelbasierten Systeme entstanden. Das erste System, das erfolgreich intensiv Wissen in der Form einer großen Anzahl von Regeln aus einem spezifischen Anwendungsbereich einsetze, war DENDRAL. Das DENDRAL Projekt wurde in den 1960er Jahren gestartet und interpretiert Auswertungen von Massenspektrometern. [Bei06] 1.4. Jefis Jefis (Java Expert Fuzzy Inference System) ist ein Projekt der FH-Münster 4. Das Projekt beschäftigt sich mit Fuzzylogic. Wie in Abbildung 1.9 zu sehen ist, ist das Fuzzyset einer der zentralen Bestandteile des Systems. Es unterstützt eine Vielzahl von verschiedenen Implikationen wie beispielsweise Goedel, Lucasiewicz, Larsen, Mamdani und noch einige mehr. Diese Vielfalt setzt sich bei den Normen fort, hier gibt es die Normen Algebraic, Bounded oder MinMax um nur einige zu nennen. Des Weiteren sind Elemente zur Visualisierung enthalten mit denen sich Beispiel Applets in kurzer Zeit erstellen lassen. Ein Beispiel für die Visualisierung lässt sich in Abbildung 3.1 finden. Abbildung 1.9.: UML Diagramm der wichtigsten Jefis Klassen [NW09] 4 Jefis ist ein Projekt des Labor für Informatik das zu finden ist unter 13

18 Teil II. Jefis Drools Adapter Autor: Dennis Huning, B.Sc. 14

19 2. Jefis Drools Adapter 2.1. Einleitung Das erste Kapitel hat einen Überblick über die grundlegenden Themen des folgendem Kapitels gegeben. In diesem Kapitel wird kurz der Rete-OO Algorithmus angeschnitten, da dieser in JBoss Drools verwendet wird und alle folgenden Abschnitte in diesem Kapitel auf diesem Projekt basieren. Anschließend wird auf die Kombination von Regelbasierten Systemen und Fuzzy eingegangen, im Speziellen auf die Arbeit von Davide Sottara 2.3 und den im Masterprojekt 2009/10 entstandenen Adapter des Jefis-Projektes Der Rete-OO Algorithmus Überblick Der Rete-OO ist eine für objektorientierte Systeme optimierte Version des Rete Pattern Matching Algorithmus und wird in der Business-Rule-Engine JBoss Drools eingesetzt. Erfunden wurde der Rete Algorithmus von Dr. Charles Forgy. Der eigentliche Algorithmus kann in zwei Aufgaben aufgeteilt werden: Erzeugen eines deterministischen Baumes Laufzeit Ausführung Erzeugen eines deterministischen Baumes Während der ersten Ausführungsphase wird aus den Bedingungen der LHS aller Regeln eine Baumstruktur erzeugt, dabei entspricht jeder Knoten einer Teilbedingung (Prämisse). Die LHS einer speziellen Regel ergibt sich aus der Verknüpfung einzelner Pfade. Zusätzlich werden gleiche Bedingungsteile von unterschiedlichen Knoten geteilt. In der Literatur wird vom Nodesharing gesprochen. Rete-OO kennt insgesamt die acht in der Abbildung 2.1 gezeigten Knoten. In jedem Baum ist der erste Knoten der ReteNode. Dieser Knoten errechnet für jedes Objekt, das zum WorkingMemory hinzugefügt wird, den zugehörigen Hashwert und speichert diesen. Durch diese Maßnahme wird sichergestellt, dass kein gleiches Faktum zweimal den Baum durchläuft. In der zweiten Ebene befinden sich die ObjectTypeNodes die eine instanceof-prüfung durchführen. Somit kann jeder Pfad nur von dem Faktum durchlaufen werden an dem eine objektspezifische Prüfung erfolgreich durchgeführt werden kann. AlphaNodes führen eine atomare Überprüfung an einer Membervariable durch. Trifft 15

20 KAPITEL 2. JEFIS DROOLS ADAPTER Abbildung 2.1.: Auflistung der unterschiedlichen Rete-OO Knoten die abgefragte Bedingung zu, wird das Faktum im sogenannten AlphaMemory abgespeichert. Zusätzlich propagiert ein AlphaNode, falls das Faktum die Bedingung erfüllt hat, dieses zu seinem Nachfolger. BetaNodes (JoinNodes) stellen eine Verbindung zwischen Gruppen aus einem oder mehreren Tupeln und eindeutigen Fakten her. Tupel werden an dem linken und Fakten am rechten Eingang angelegt. Auch BetaNodes verfügen über einen Speicher. Für die Daten vom linken Eingang heißt dieser Speicher BetaMemory. Die Daten vom rechten Eingang werden im AlphaMemory gespeichert. Daher enthält der BetaMemory alle eingehenden Tupel und der AlphaMemory alle eingehenden Objekte. LeftInputAdapterNodes bekommen ein Objekt übergeben und propagieren nur ein einzelnes Objekttupel weiter an den darunter liegenden Knoten. Jeder Pfad endet mit dem TerminalNode. Dieser Knoten ist mit einer bestimmten Regel verknüpft. Sobald der Knoten aktiviert wird, fügt der Algorithmus die mit der TerminalNode verknüpften Regel zur Konfliktmenge hinzu Laufzeit Ausführung Während der Laufzeit Ausführung durchläuft der Rete-Algorithmus drei Phasen: Match: Inhalt des WorkingMemories (WM) wird auf alle LHS angewendet. Als Resultat wird eine Menge (Conflict-Set), bestehend aus den Regeln deren LHS Wahrheitswert gleich wahr ist, geliefert. Conflict-Resolution: Es wird eine Regel aus der Konfliktmenge zum Ausführen ausgewählt. Act: Es wird die ausgewählte Regel ausgeführt. Dies hat zur Folge, dass sich der Status des WM ändert, wodurch ein Rematching getriggert wird. Zu beachten ist hierbei, dass 90% der Rechenzeit für die Matching-Phase benötigt wird. 16

21 KAPITEL 2. JEFIS DROOLS ADAPTER Beispiel eines Baumes In der Software Drools [dro10] werden die Regeln in der Drools Rule Language (DRL) verfasst. Dabei werden die Regeln standardmäßig im MVEL-Dialekt[mve10] angegeben. Eine in MVEL verfasste Regel zeigt das nachfolgende Beispiel: Listing 2.1: Beispiel Regel in MVEL 1 rule " rule1 " when 3 $cpu : CPU ( temp > 80 && voltage > 1.55 ) $cpucooler : Cooler ( cpu == $cpu && fanspeed <= 120 ) 5 then $cpucooler. setfanspeed (200); 7 end Die Regel hängt von den zwei Objekten CPU und Cooler ab. Der deterministische Baum, der für diese Regel erzeugt wird, besteht aus zwei Pfaden (Abbildung 2.2). Einer behandelt alle Abfragen am Objekt CPU und der Andere Abfragen am Objekt Cooler. Die ersten Knoten jedes Zweiges sind vom Typ ObjektTypNode und überprüfen die im WorkingMermory enthaltenden Fakten auf ihr Instanzart. Das bedeutet: Für unser Beispiel werden alle Objekte kontrolliert, ob sie vom Typ CPU oder vom Typ Cooler sind. Wenn die Fakten vom Typ des entsprechenden Zweiges sind, werden diese an den darauf folgenden Knoten propagiert. Jeder Zweig enthält für jede atomare Abfrage, aus einer Regel, einen Knoten vom Typ AlphaNode. Der Pfad für die Fakten vom Typ CPU beinhaltet zwei AlphaNodes. Der erste Knoten überprüft ob die Temperatur größer als 80 C ist. Falls dies zutrifft, wird ein neuer Eintrag in dem AlphaMemory für das Objekt erzeugt. Anschließend wird das Objekt an den nächsten Knoten propagiert. Der nächste Knoten vom Typ AlphaNode überprüft, ob die Spannung der CPU größer als 1,55V ist. Im Pfad des Coolers wird abgefragt, ob die Cooler-Instanz zu einer im AlphaMemory Abbildung 2.2.: Baum für die im Listing gezeigte Regel gespeicherten CPU-Instanz gehört. Daher propagiert der LeftInputAdapterNode, aus 17

22 KAPITEL 2. JEFIS DROOLS ADAPTER dem Pfad der CPU das Tupel, bestehend aus Objekt Hashwert und Instanz-ID, an den linken Eingang des BetaNodes. Wurden alle Bedingungen erfüllt, fügt der TerminalNode die Regel zur Konfliktmenge hinzu Erweiterung des Rete-OO Algorithmus um Fuzzy Logik Davide Sottara hat in [DS08] eine Möglichkeit vorgestellt den Rete-OO Algorithmus um Fuzzy Logik zu erweitern. Seine Erweiterungen sind in dem Drools-Branch Drools Chance [Sot10b] zu finden. In den nächsten Zeilen wird auf die grundlegende Idee seiner Erweiterung eingegangen. Bei der Implementierung von Fuzzy Logik gibt es mehrere gravierende Unterschiede. Bei der von Davide Sottara vorgestellten Möglichkeit wird die Unschärfe als ungefähr aufgefasst. Bei dieser Implementierung kann man sich die Fuzzy-Sets, je nach Abfrage, als ansteigende oder abfallende Flanke vorstellen, wobei der zu prüfende Wert als Schwellwert dient. Bei diesem Verfahren wird die Standard MVEL-Syntax um die Operatoren is und seems ergänzt. Auf den beiden Operatoren is und seems wird in den nächsten, Abschnitten noch eingegangen. Eine Abfrage, die mit dem anfängt, wird -Operator als unscharfer Wert aufgefasst. Dies bedeutet für die Temperatur-Regel aus 2.1: Listing 2.2: Beispiel Regel mit -Operator 1 rule " rule1 " degree ɛ r 3 when cpu : CPU ( temp ~> 80 && voltage ~> 1.55 ) 5 cpucooler : Cooler ( cpu == cpu && fanspeed ~> 120 ) then 7 cpucooler. setfanspeed (200); end Wie durch die vorangegangenen Abschnitte zu erkennen ist, muss bei der Erweiterung des Rete-OO-Algorithmus bedacht werden, dass es keine scharfen Werte mehr gibt. Hierdurch können Auswertungen der Knoten bei falsch nicht einfach verworfen werden. Dies führt zu einem weiteren Problem: Was passiert mit nicht erfüllten Regeln?. Um dieses Problem zu lösen, gibt es mehrere Strategien: Niemals verwerfen: Regeln deren Bedingungen nicht erfüllt sind, werden trotzdem gefeuert. Dieses Verhalten generiert allerdings ein Performance Problem. Künstliche Schwellwerte: Über ein Regelargument (degree) kann man einen Schwellwert setzen, der den Zugehörigkeitswert angibt, der erfüllt sein muss, damit eine Regel feuert. Heuristiken und weiteres: Über Interfaces ist es möglich eigene Evaluatoren zu implementieren. 18

23 KAPITEL 2. JEFIS DROOLS ADAPTER 2.4. Drools Chance Wie bereits erwähnt ist es möglich eigene Evaluatoren zu erstellen. Diese Evaluatoren müssen sich von der abstrakten Klasse BaseImperfectEvaluator ableiten. Die abstrakte Klasse enthält eine Vielzahl von unterschiedlichen eval()-methoden. Das nächste Listing zeigt eine solche Methode. Wie man erkennen kann, gibt diese Methode eine Variable des Typs IDegree zurück. Listing 2.3: Beispiel einer eval()-methode der abstrakten Klasse BaseImperfectEvaluator protected abstract IDegree eval ( Object left, Object right, IDegreeFactory factory ); Das Interface IDegree repräsentiert den Zugehörigkeitswert einer Variable, also einen Wert im Intervall I:= [0, 1]. Zusätzlich zu der Repräsentation des Intervalls ist es laut [Sot10a] eine Anforderung an IDegree, die Werte True und False annehmen zu können. Daher bietet es eine Möglichkeit den Zugehörigkeitswert auf boolean zu casten. Damit die Ruleengine bei der Auswertung einer Regel mit Fuzzylogik auch den angepassten Evaluator wählt, muss dieser registriert werden. Das Registrieren eines solchen Evaluators geschieht in zwei Schritten. Zum einem muss eine Definition, die sich von ImperfectEvaluatorDefinition ableitet, erstellt werden. Diese Definition enthält eine ID (z.b. seems ), die angibt auf welche Regeln der Evaluatoroperator angewendet werden soll. Außerdem enthält die Definition eine getevaluator()-methode, die den Evaluator zurückgibt. Zusätzlich muss der Operator an der Klasse Operator registriert werden. Im zweiten Schritt wird der Classname des Standards Operators durch den eigenen Classname ersetzt. Dazu wird beim Erstellen der RuleEngine eine modifizierte Package- BuilderConfiguration übergeben. Durch diesen Mechanismus war es uns möglich einen Adapter für das Jefis Projekt zu schreiben. Dieser Adapter erlaubt es die Regeln mit Hilfe der FuzzySets und FuzzyNormen aus Jefis auszuwerten. Im nächsten Abschnitt wird die Implementierung des Adapters beschrieben, wodurch noch einmal verdeutlicht wird, wie man eigene Evaluatoren erstellt und registriert Adapter Die Abbildung 2.3 gibt einen Überblick über die Klassen die genutzt werden um Jefis zu adaptieren. Das zentrale Objekt des Jefis Projektes ist das FuzzySet. FuzzySets verfügen über das Wissen wie sie miteinander verknüpft werden sollen. Das heißt: Welche Operatoren beim And oder Or angewendet werden sollen. Außerdem liefern FuzzySets die Zugehörigkeit zu einer Variable. Hinter jeder linguistischen Variable aus einer Regel steht ein solches Set. Auf dieses FuzzySet muss der Evaluator zugreifen können um die Zugehörigkeit zurückgeben. Für das folgende Listing 2.4 bedeutet dies, dass der Evaluator auf die beiden FuzzySets mit cold und low zugreifen muss. Über die tostring()-methode des right -Objektes aus der eval()-methode bekommt man den Namen des Sets geliefert. 19

24 KAPITEL 2. JEFIS DROOLS ADAPTER Abbildung 2.3.: Klassendiagramm des Jefis-Drools-Adapters Listing 2.4: Beispiel Regel mit Fuzzy-Evaluatoren 1 rule " R11 " when 3 $cooler : Cooler ($t: temperature is " cold " && $c: fancurrent is " low " ) then 5 $cooler. setstatus (" green ", drools. getconsequencedegree ()); end Mit diesen Namen kann man sich an der Klasse FuzzySetRegistry das entsprechende FuzzySet geben lassen. Die Registry ist als Singelton realisiert worden. Registriert werden die FuzzySets automatisch beim Erzeugen eines FuzzySetDecorators. Dieses Vorgehen schließt ein, dass der Name cold, da er zu Identifizierung genutzt wird, eindeutig sein muss. Damit die Ruleengine den FuzzyEvaluator auch benutzt, wird in der Klasse JefisDrools- Builder der Property Eintrag des entsprechenden Evaluators in der Klasse PackageBuilderConfiguration angepasst, siehe nachfolgendes Listing 2.5. Listing 2.5: Ersetzen der Standard Evaluatoren protected void configurepackagebuilder () { 2 packagebuilder = new PackageBuilder (); packagebuilderconf = packagebuilder. getpackagebuilderconfiguration (); 4 // register some EvaluatorDefinitions... 6 packagebuilderconf. setproperty (" drools. evaluator. seems ", FuzzySeemsEvaluatorDefinition.class. getname ()); 8 packagebuilderconf. setproperty (" drools. evaluator.is", IsEvaluatorDefinition.class. getname ()); 10 } Die Regel R11 aus dem vorausgegangenen Beispiel besteht aus zwei Prämissen, die durch den &&-Operator verknüpft sind. Für die Berechnung ruft die Ruleengine ein Implemen- 20

25 KAPITEL 2. JEFIS DROOLS ADAPTER tierung von IDegreeFactory auf. Welche Factory gewählt wird, kann beim Erzeugen einer RuleBase angegeben werden, siehe nachfolgendes Listing: Listing 2.6: Übergabe der DegreeFactory rulebaseconf = new RuleBaseConfiguration (); 2 rulebaseconf. setproperty ( DEGREE_FACTORY_TAG, JefisDegreeFactory.class. getname ()); 4... RuleBase rulebase = RuleBaseFactory. newrulebase ( rulebaseconf ); Welche Algorithmen die Factory JefisDegreeFactory für die Operatoren zurückgibt, wird in einer Properties-Datei parametrisiert [NW09]. Durch einen Eintrag bestimmt man welcher Operator mit welcher Klasse verknüpft ist. Im folgendem Beispiel 2.7 wird die Factory so parametrisiert, dass diese als Standardnormoperator eine Instanz der Klasse de.lab4inf.fuzzy.norms.fuzzyminmax und als Standardimplikationsoperator eine Instanz der Klasse de.lab4inf.fuzzy.logic.mamdani zurückgibt. Listing 2.7: Beispiel der Properties-Datei 1 norm. operator. DEFAULT = de. lab4inf. fuzzy. norms. FuzzyMinMax norm. operator. MinMax = de. lab4inf. fuzzy. norms. FuzzyMinMax implication. operator. DEFAULT = de. lab4inf. fuzzy. logic. Mamdani implication. operator. Zadeh = de. lab4inf. fuzzy. logic. Zadeh 9 implication. operator. Goedel = de. lab4inf. fuzzy. logic. Goedel

26 Teil III. Jefis Ruleengine Autor: Dennis Löhr, B.Sc. 22

27 3. Jefis Ruleengine 3.1. Einleitung Nach einem erfolgreichen Abschluss der ersten Hälfte des Masterprojektes, wurde entschieden das wir uns in der zweiten Hälfte des Masterprojektes das an der Fachhochschule Münster entwickelte Jefis erweitern. Damit es mit Jefis nicht nur möglich ist Fuzzy-Controlling zu betreiben, sondern auch möglich ist Fuzzy-Logic abzubilden. Dabei sollte man berücksichtigen das Jefis von sich aus keine Ruleengine, sondern einen Fuzzy-Controller abbildet. Dieser ist zwar so entwickelt, dass Jefis aus einer XML-Datei die Regeln dynamisch neu einliest aber dadurch, dass der Controller nur scharfe Werte verarbeiten kann, war er nicht geeignet für das eigentliche Ziel unseres Masterprojektes. Eines der wichtigsten Eigenschaften einer Ruleengine ist, dass es die Ergebnisse aus einer vorherigen Regel, als Eingabe für eine neue benutzen kann (siehe Vorwärtsverkettung bzw. Rückwärtsverkettung ). Dies wurde bei Jefis darüber gelöst, das die Ergebnisse erst defuzzifiziert und anschließend wieder fuzzifiziert werden. Durch dieses Defuzzifizieren und anschließendem Fuzzifizieren entstehen Ungenauigkeiten die spätestens nach der Hintereinanderausführung von mehreren Regeln ein erhebliches Ausmaß annehmen Beispiel in Lab4Jefis Da Jefis eine gute Möglichkeit liefert die Fuzzysets zu visualisieren wurde eine Beispielanwendung im Applet FuzzyRuleEngineApplet demonstriert. Bei diesem Applet gibt es vier Fuzzysets in der Regelbasis (Food, Service, Tip und Waiter), damit wir eine Hintereinanderausführung von mehreren Regeln haben gibt es dazu die Regeln: 1. IF service IS good AND food IS delicious THEN tip IS generous 2. IF tip IS generous THEN waiter IS happy In Abbildung 3.1 ist unter den Fuzzysets Premise: food und Premise: service zu sehen, mit welchen Eingabesets wir in die Regeln hineingegangen sind. Die Eingabe Sets sind auch in den Fuzzysets Service und Food zu sehen, bei service ist dies das gelbe Dreieck wobei die Schnittmenge mit dem Set service:good hier als weiße Fläche eingefärbt ist. Beim set food ist das Eingabeset durch das lila Dreieck und die Schnittmenge durch eine türkise Fläche gekennzeichnet. Aus diesen beiden Fuzzyset-Schnittmengen ergibt sich jetzt das Fuzzyset Premise: tip das im Ausgabe Set Tip bis zum Minimum der beiden 23

28 KAPITEL 3. JEFIS RULEENGINE Abbildung 3.1.: Applet zur Visualisierung der Implikation Eingabe Sets gefüllt ist. Zum Schluss bildet sich aus dem neuen Eingabeset Premise:tip das neue Ausgabeset Result:waiter. In dem Applet 3.2 wurde die Regelbasis noch fest in den Javacode eingegeben. Für eine produktive Umgebung kann man dies allerdings nur schwer durchsetzen da, wie im Kapitel schon beschrieben ist, sich viele Regeln ändern. Deshalb haben wir vor der Auswahl einer geeigneten Repräsentation der Regeln gestanden, zur Auswahl kamen dabei die XML-Basierte Sprache von Jefis, die standardisierte FCL 4.1 oder eine vollkommen eigene Entwicklung. Aufgrund dessen, dass es sich im Gegensatz zu beiden Alternativen bei FCL um eine standardisierte Sprache für Fuzzy handelt wurde diese dann auch genommen. Genaueres kann aus dem Kapitel 4.1 entnommen werden Die Lab4Jefis Rule-Engine Um das Beispiel des Applet 3.1 mit FCL Unterstützung zu benutzen, benötigen wir eine FCL-Datei. Diese FCL-Datei muss wie im nachfolgenden Kapitel 4.1 beschrieben wird aufgebaut sein. Für das Beispiel stellt die FCL-Dateien die Wissensbasis des Systems dar. Damit die beiden Eingabesets aus dem obigen Beispiel also zur Verfügung stehen, benötigen wir innerhalb des FUNCTION BLOCKs die Elemente aus dem Listing

29 KAPITEL 3. JEFIS RULEENGINE VAR_INPUT 2 service : REAL ; food : REAL ; 4 END_VAR Listing 3.1: FCL beschreibung der Fuzzysets service und food 6 FUZZIFY service TERM poor := (0, 1) (4, 0); 8 TERM good := (1, 0) (4,1) (6,1) (9,0); TERM excellent := (6, 0) (9, 1); 10 END_FUZZIFY 12 FUZZIFY food TERM rancid := (0, 1) (1, 1) (3,0); 14 TERM delicious := (7,0) (9,1); END_FUZZIFY Wobei es für die Rule-Engine nicht erheblich ist, ob ein Fuzzyify oder Defuzzify Block benutzt wird, da wir in der Rule-Engine mit den Ausgabesets der vorherigen Regel weiter arbeiten. Deshalb sollten wir auch für tip einen Fuzzyify Block, wie im folgenden Listing 3.2 benutzen. Listing 3.2: FCL beschreibung der Fuzzysets tip und waiter 1 VAR_OUTPUT tip : REAL ; 3 waiter : REAL ; END_VAR 5 FUZZIFY tip 7 TERM cheap := (0,0) (5,1) (10,0); TERM average := (10,0) (15,1) (20,0); 9 TERM generous := (20,0) (25,1) (30,0); END_FUZZIFY 11 DEFUZZIFY waiter 13 TERM sad := ( -1.1,0) ( -1,1) (0,1) (3,0); TERM normal := (2,0) (4,1) (5,1) (7,0); 15 TERM happy := (6,0) (9,1) (9.5,1) (9.6,0); END_DEFUZZIFY Wie beim Fuzzyset waiter bzw. food zu sehen ist, können nicht nur Dreiecke benutzt werden, sondern es ist auch möglich Senken, Trapeze oder Polygone zu benutzen. Dadurch ist der Freiheitsgrad beim Erstellen der Fuzzysets groß, was allerdings bei den Polygonen, wenn sehr viele Regeln benutzt werden zu Performance Einbußen führt. Damit die Wissensbasis für das Beispiel aus dem Applet aber komplett ist, wird zusätzlich zu den Fuzzysets auch der RULEBLOCK mit den Regeln benötigt. Die beiden Regeln aus dem Beispiel können hierfür einfach wie in Listing 3.3 eingegeben werden oder zusätzlich mit der Norm und der Implikation versehen werden wie in Listing 3.4. Listing 3.3: FCL beschreibung der Regeln ohne Norm und Implikation RULEBLOCK No1 2 RULE 1 : IF service IS good AND food IS delicious THEN tip IS generous ; RULE 2 : IF tip IS generous THEN waiter IS happy ; 4 END_RULEBLOCK Listing 3.4: FCL beschreibung der Regeln mit Norm und Implikation RULEBLOCK No1 2 AND : MIN ; ACCU : MAX ; 4 RULE 1 : IF service IS good AND food IS delicious THEN tip IS generous ; RULE 2 : IF tip IS generous THEN waiter IS happy ; 6 END_RULEBLOCK Damit sind alle Teile der FCL-Datei komplett. Diese kann auch im Anhang zusammengefasst unter Listing 6.1 betrachtet werden. Damit das Wissen, das in der FCL-Datei 25

30 KAPITEL 3. JEFIS RULEENGINE enthalten ist, in der Rule-Engine benutzten werden kann, wird ein FCLRuleEngineBuilder benötigt. Über diesen kann mit der Methode buildruleengine dann die Rule-Engine mit der FCL-Datei erzeugt werden. Damit die Rule-Engine jetzt aber auch eine Regel ausführen kann, benötigt sie eine Faktenbasis. Als Input für die Faktenbasis hatte das Beispiel aus dem Applet für beide Fuzzysets, service und food, ein normales Dreieck. Dieses erzeugen wir über den Konstruktor des FuzzyTriangle und setzten den Namen des Fuzzysets, auf den es angewendet werden soll. Danach werden die einzelnen Sets zu der Premise hinzugefügt. Das Listing 3.5 enthält alle dafür notwendigen Elemente. Listing 3.5: Java Code zum erstellen der Beispiel Premise HashMap <String, FuzzySet > premises ; 2 FuzzySet set ; premises = new HashMap <String, FuzzySet >(); 4 // Service set = new FuzzyTriangle (3, 2); 6 set. setname (" service "); premises.put (set. getname (), set ); 8 // Food 10 set = new FuzzyTriangle (7, 3); set. setname (" food "); 12 premises.put (set. getname (), set ); Wenn in der FCL-Datei nicht die Implikation und die Norm gewählt wurden, müssen diese jetzt gesetzt werden. Die dafür notwendigen Funktionen sind im Listing 3.6 enthalten. Für diese stellt Jefis eine Vielzahl von verschiedenen Normen und Implikationen zur Verfügung. Listing 3.6: Java Code zum setzen der Implikation und der Norm ruleengine. setimplicationtype (" Mamdani "); 2 ruleengine. setnorm (new FuzzyMinMax ()); Nachdem der Rule-Engine nun alle Details bekannt sind, die notwendig sind, um das Beispiel aus dem Applet darzustellen, können die Faktenbasis und die Wissensbasis über die Methode conclusion zusammengeführt werden. Dabei wird eine Liste mit Fuzzysets zurückgegeben, bei der beachtet werden muss das diese keine bestimmte Reihenfolge besitzen, sondern über ihren Namen identifiziert werden können. 26

31 Teil IV. FCL und ANTLR Autor: Thomas Beermann, B.Sc. 27

32 4. FCL und ANTLR 4.1. FCL Einleitung Die Fuzzy Control Language oder auch FCL ist eine von der International Electrotechnical Commission (IEC ) standardisierte, domänenspezifische Sprache. Es hat nur Sprachelemente die direkt mit Fuzzy Logik zusammenhängen, wie die Deklaration von Fuzzy Sets und Regeln, aber nicht einmal so grundlegende Konstrukte wie Schleifen. Aus dem Grund ist es auch nicht möglich ganze Programme in FCL zu schreiben sondern nur die Teile davon, die die Fuzzy Regelmaschine beschreiben. Der Standard ist nicht frei und muss erworben werden. Allerdings gibt es einen Entwurf von 1997 der sich nicht entscheidend von dem finalen Standard unterscheidet und frei verfügbar ist unter [iec10]. Dieser Entwurf wurde in diesem Projekt verwendet Beispiel Im Folgenden wird die Syntax von FCL genauer erklärt. Am Besten kann man dies an einem einfachen Beispiel erklären. Die in diesem FCL Codebeispiel beschriebene Regel Maschine berechnet die Glücklichkeit eines Kellers anhand des Trinkgelds, welches er wiederum bekommt abhängig von der Qualität des Essens und des Services. FUNCTION_BLOCK tipper // Anfang eines neuen Block. Es kö nnen mehrere in einer Datei definiert sein. 2 VAR_INPUT // Definition der Eingangsvariablen 4 service : REAL ; food : REAL ; 6 tip : REAL ; END_VAR 8 VAR_OUTPUT // Definition der Ausgangsvariablen 10 waiter : REAL ; END_VAR 12 FUZZIFY service // Festlegung der Sets für den Eingang service 14 TERM poor := (0, 1) (4, 0) ; TERM good := (1, 0) (4,1) (6,1) (9,0); 16 TERM excellent := (6, 0) (9, 1); END_FUZZIFY 18 FUZZIFY food // Festlegung der Sets für den Eingang food 20 TERM rancid := (0, 1) (1, 1) (3,0) ; TERM delicious := (7,0) (9,1); 22 END_FUZZIFY 24 FUZZIFY tip // Festlegung der Sets für den Eingang / Ausgang tip TERM cheap := (0,0) (5,1) (10,0); 26 TERM average := (10,0) (15,1) (20,0); TERM generous := (20,0) (25,1) (30,0); 28 END_FUZZIFY 30 DEFUZZIFY waiter // Festlegung der Sets für den Ausgang waiter TERM sad := (0,0) (5,1) (10,0) 32 TERM normal := (10,0) (15,1) (20,0) TERM happy := (20,0) (25,1) (30,0) 28

33 KAPITEL 4. FCL UND ANTLR 34 END_DEFUZZIFY 36 RULEBLOCK service_food_tip AND : MIN ; // Angabe der Norm. MIN für AND impliziert auch MAX für OR 38 ACCU : MAX ; // Angabe der Norm für die Zusammenfassung der Ergebnisse. ACT : MIN ; // Angabe der Norm für die Aktivierung der Regeln. 40 RULE 1 : IF service IS poor OR food is rancid THEN tip IS cheap ; 42 RULE 2 : IF service IS good THEN tip IS average ; RULE 3 : IF service IS excellent AND food IS delicious THEN tip is generous ; 44 RULEBLOCK tip_waiter 46 AND : BOUNDED ; ACCU : MAX ; 48 ACT : PROD ; 50 RULE 4 : IF tip IS cheap THEN waiter IS sad ; RULE 5 : IF tip IS average THEN waiter IS normal ; 52 RULE 6 : IF tip IS generous THEN waiter IS happy ; END_RULEBLOCK 54 END_FUNCTION_BLOCK FCL wurde als Sprache für Fuzzy Control entwickelt, was man auch direkt bemerkt. Eine FCL-Datei kann aus mehreren FUNCTION BLOCKs aufgebaut sein. Diese haben wie reale Bausteine einen oder mehrere Ein-und Ausgänge. Dieses Beispiel besteht nur aus dem FUNCTION BLOCK tipper. Die Eingaben und Ausgaben werden am Anfang deklariert in den Blöcken beginnend mit VAR INPUT bzw. VAR OUTPUT. Bei einem normalen Fuzzy Control Block werden die Eingänge immer fuzzifiziert und die Ausgänge immer defuzzifiert, so dass man die Variablen immer als Input oder Output deklarieren muss. Bei der Rule Engine aus diesem Projekt müssen die Eingänge und Ausgänge aber nicht unbedingt fuzzifiert und defuzzifiziert werden. Zu einen kann man auch mit unscharfen Werten als Eingang reingehen, zum anderen können auch unscharfe Werte als Ausgabe herauskommen. Aus diesem Grund können Regeln auch verkettet werden ohne jeweils die Eingänge oder Ausgänge fuzzifizieren bzw. defuzzifieren zu müssen. Daraus folgt, dass man die Variablen nicht immer unbedingt als Input oder Output deklarieren kann. Bei service und food ist es offensichtlich, da diese nur als Eingabe verwendet werden im Regelblock service food tip benutzt werden. Ebenso verhält es sich mit waiter nur eben als Ausgabe im zweiten Regelblock. Bei tip ist das nicht mehr so eindeutig. tip wird sowohl im 1. als auch im 2. Regelblock verwendet sowohl als Eingabe als auch als Ausgabe. Ist das der Fall wird eine Variable als Eingabe deklariert. Als nächstes folgt die Angabe der Partitionen und Sets für die einzelnen Variablen. Dies geschieht in dem FUZZIFY bzw. DEFUZZIFY Block. Für jede Variable wird ein eigener Block angelegt und in diesen Blöcken die Sets definiert. Jedes Set wird durch TERM gefolgt von dem Namen eingeleitet. Es gibt dann verschiedene Möglichkeiten ein Set zu definieren. In diesem Beispiel werden einfach verschiedene Referenzpunkte gewählt, die in den Klammern angegeben werden. Der erste Wert ist die Eingabe und der Zweite die Zugehörigkeit zum Set. Zwei Punkte müssen mindestens angegeben werden. Alle weiteren Werte werden dann daraus berechnet. Nachdem die Eingabe-und Ausgabewerte angegeben und die dazugehörigen Sets definiert wurden gibt man im RULEBLOCK die Regeln an. Bevor die eigentlichen Regeln beginnen, kann man die Rule Engine noch mit 3 verschiedenen Optionen parametrisieren. Zunächst ist da die Norm. Hier reicht es entweder die AND oder OR Norm anzugeben da die jeweils andere implizit darauf folgt. Dann gibt es noch die Akkumulationsnorm, 29