Gesellschaft für Informatik e.V.

Lecture Notes in Informatics


Informatik bewegt: Informatik 2002 - 32. Jahrestagung der Gesellschaft für Informatik e.v. (GI), 30. September - 3.Oktober 2002 in Dortmund. P-19, 848-858 (2002).

GI, Gesellschaft für Informatik, Bonn
2002


Editors

Sigrid E. Schubert (ed.), Bernd Reusch (ed.), Norbert Jesse (ed.)


Copyright © GI, Gesellschaft für Informatik, Bonn

Contents

Sicherheitsrelevanter Fuzzy Controller

Gerhard H. Schildt

Abstract


Nach einer Einführung in sicherheitstechnische Begriffe wird ein Fuzzy Controller für sicherheitsrelevante Aufgaben der Prozesssteuerung vorgestellt. Es lässt sich zeigen, dass der erforderliche Umfang der Regelbasis relativ gering ist, um eine zufriedenstellende Arbeitsweise des Controllers sicherzustellen. Die Besonderheit dieses Entwurfes besteht darin, dass sich der Inhalt der Regelbasis für eine Validierung besonders gut eignet, da erfahrene Prozessoperateure ( Anlagenfahrer ), die über keine vertieften Kenntnisse der Informatik verfügen, durchaus in der Lage sind, den Inhalt der Regelbasis in ihrer Eigenschaft als Experten zu validieren. Für die überigen Softwarekomponenten des Fuzzy-Controllers ( Fuzzyfizierung, Inferenzalgorithmus, Defuzzyfizierung sowie Echtzeitbetriebssystemsoftware ) ist eine sog. Standard-Fuzzy-Software zu entwickeln und einmalig zu validieren. Darüberhinaus ergibt sich bei einem Fuzzy Controller ein recht gutes Echtzeitverhalten im Vergleich zum herkömmlichen PID-Controller. Der Entwurf ist weiter dadurch gekennzeichnet, dass grundsätzliche sicherheitstechnische Prinzipien implementiert wurden, so z.B. eine taktgesteuerte Überwachung des Scanners, ob dieser deterministisch die Regelbasis bearbeitet. Sollte der Scannvorgang \?hängen bleiben“, geht das Gesamtsystem durch eine Watchdog-Funktion in den sicheren Systemzustand über 1. Einführung Für sicherheitsrelevante Aufgaben der Prozeßsteuerung sind validierbare Hardund Softwaresysteme erforderlich. Bisher bestehen noch erhebliche Bedenken, für sicherheitsrelevante Prozesse softwarebasierte Systeme einzusetzen, da der Grundsatz gilt, dass Software niemals fehlerfrei sein wird ( \?software will never be error-free“ [GRA01]. Dennoch suchen überall Entwickler nach neuen Wegen, um auch softwarebasierte Systeme zur Steuerung sicherheitsrelevanter Systeme einzusetzen. Zunächst sollen einige sicherheitstechnische Begriffe eingeführt werden Sicherheitsrelevantes System = ein System, das keine Gefährdung von Menschen und 848 Material im Fall von Umwelteinflüssen oder systembedingten Ausfällen bewirkt. Technische Sicherheit = Eigenschaft einer Komponente, die unter gegebenen Umständen für eine vorgegebene Zeit keine Gefährdung von Menschen und Material verursacht ( solche Fehlzustände können durch technisch bedingte Ausfälle oder Fehlfunktionen elektronischer Einrichtungen z.B. durch elektromagnetische Störbeeinflussung bewirkt werden ). Gefährdung: Zustand eines Systems, der nicht mehr mit den im System gegebenen Mitteln beherrschbar ist und zu Personenoder Sachschäden führen kann. Sicherer Systemzustand: ein Systemzustand, aus dem heraus keine Gefährdung für Personen und Sachen entstehen kann, und der von selbst nicht mehr verlassen werden kann. Fail-safe : technische Ausfälle innerhalb einer Systemkomponente dürfen zu Fehlzuständen führen ( \?fail“ ), die jedoch sicher sein müssen ( \?safe“ ). Da es bis heute keinen einkanaligen fail-safe arbeitenden Computer für sicherheitsrelevante Prozesssteuerungen gibt, kann man stattdessen einen zweikanaligen Mikrocomputer ( SIMIS ) einsetzen, der zwar gegenüber Hardwareausfällen gesichert ist, nicht jedoch gegenüber Softwarefehlern. Um auch diese Fehlzustände zu vermeiden, kann man das Diversitätsprinzip ( redundante Software; engl.: n-version programming ) anwenden, wobei das Diversitätsprinzip bedeutet, dass eine gewünschte Funktion auf unterschiedlichen Entwicklungswegen realisiert wird ( engl.: "Existence of different means to perform a required function" ) [BIS86]. Dennoch ist festzustellen, dass man bei einem diversitären Systementwurf immer noch mit erheblichen Problemstellungen konfrontiert wird: 1. Es muß sichergestellt sein, daß hinreichende Diversifizierung vorliegt ( was nicht anderes bedeutet als ein \?inverser“ Sicherheitsnachweis ). 2. Es treten nicht-planbare Wartezeiten für miteinander zu vergleichender Resultate auf. Das ist gerade für Echtzeitanwendungen ein entscheidender Nachteil ! 3. Bei diversitärem Systementwurf benötigt man einen Vergleicher für zu vergleichende Resultate, der jedoch nicht nur ein einfacher Vergleicher ist, sondern auch noch über die Eigenschaft einer Toleranzfensterbearbeitung für zu vergleichende Resultate verfügen muß ( engl.: tolerance zone management ). Außerdem ist diese Eigenschaft auch noch fail-safe zu realisieren. Angesichts solcher Problemstellungen ist ein einkanaliger Systementwurf für eine sicherheitsrelevante Prozesssteuerung eher anzustreben, der die Möglichkeit einer 849 Validierung und Verifikation bietet ( engl.: V \& V process ). Hierzu bietet sich ein Controller-Konzept auf der Basis der Fuzzy-Logik an, da ein fuzzy-basierter Controller ein regelbasiertes System ist, dessen Regelbasis inhaltlich transparent und von daher leichter prüfbar ist. Daher wird im folgenden ein solcher Controller vorgestellt. 2. Fuzzy Controller Es wurde ein Fuzzy Controller entsprechend Abb.1 entworfen. Eingangsgröße des Reglers sind wie beim herkömmlichen PID-Regler die Regelabweichung $e(t)$ sowie die Änderungsgeschwindigkeit der Regelabweichung $de(t)/dt$, die jedoch anschließend durch eine Fuzzyfizierungskomponente über Zugehörigkeitsfunktionen ( engl.: membership function ) in Fuzzy-Äquivalente umgesetzt werden. Die Inferenzkomponente enthält eine implementierte Strategie, nach der vorzugehen ist, wenn eine oder mehrere Regeln aus der Regelbasis zutreffen ( \?feuern“ ). Dazu wird die Regelbasis ( engl.: rule base ) abgescannt, um festzustellen, welche Regeln feuern. Die Inferenzkomponente erstellt daraus ein fuzzyfiziertes Ergebnis ( engl.: fuzzy result ), das jedoch in dieser Form als Stellgröße für den technischen Prozeß ungeeignet ist. Es ist daher durch eine sog. Defuzzyfizierungskomponente wieder in einen scharfen Wert ( engl.: crisp value ) umzuwandeln. Dabei ergibt sich eine analoge Stellgröße, die dem technischen Prozeß zugeführt wird. Rulebase $w(t) e(t) u(t)$ Fuzzy- Inference Defuzzy- + - fication Engine fication Fuzzy Controller $y(t)$ Measurement Technical Recording Process Abb.1: Fuzzy Controller 2.1 Fuzzyfizierungskomponente Eingangsgrößen des Fuzzy-Controllers sind üblicherweise die Regelabweichung $e(t)$ sowie die Änderungsgeschwindigkeit der Regelabweichung $de(t)/dt$. Diese wertund 850 zeitkontinuierlichen Größen werden nun über Zugehörigkeitsfunktionen ( engl.: membership functions ) in Fuzzy-Äquivalente umgesetzt. Dabei ist man in der Wahl der Ausgestaltung der Zugehörigkeitsfunktionen nicht beschränkt; ohne Einschränkung der Funktionalität kann man z.B. dreiecksförmige Zugehörigkeitsfunktionen auswählen. Wählt man nämlich einfache Dreiecksfunktionen aus, so sind diese einfach im Sourcecode zu beschreiben: Z.B. kann eine Zugehörigkeitsfunktion für einen hohen Wert der Regelabweichung einfach beschrieben werden als (@0.6, 0, @1.0, 1, @1.4, 0) oder die Zugehörigkeitsfunktion für verschwindend kleine Werte der Regelabweichung als (@-0.3, 0, @0.0, 1, @0.3, 0) als normalisierte Beschreibung. Das bietet zugleich den Vorteil der einfachen Abspeicherung im Rechner, indem man für jede Zugehörigkeitsfunktion allein drei Wertepaare hinterlegt, zwischen denen dann linear interpoliert werden kann. Dadurch entsteht eine relativ einfache Software für die Fuzzyfizierungskomponente. Abb. 2 zeigt ein Fuzzy-Set mit den zugehörigen Zugehörigkeitsfunktionen. $μ(x)$ nl n m ns z ps p m pl x Abb.2: Fuzzy set mit den Zugehörigkeitsfunktionen 2.2 Inferenzkomponente Die zentrale Komponente des Fuzzy-Controllers ist die Inferenzkomponente ( engl.: inference engine ). In ihr ist die Vorgehensweise hinterlegt, wie zu verfahren ist, wenn eine oder benachbarte Regeln aus der Regelbasis feuern. Will man den Fuzzy Controller für sicherheitsrelevante Zwecke entwerfen, so muß sichergestellt sein, dass die Regelbasis zyklisch abgeprüft ( \?gescannt“ ) wird und dieser Vorgang nicht \?hängen bleibt“, da sonst der technische Prozeß nicht mehr echtzeitgemäß geführt wird. Dabei benötigt dieser Scanner-Vorgang stets dieselbe Zeit, wodurch das Echtzeitverhalten vorhersagbar wird. Dieser Vorgang wird von einem zentralen Taktgenerator synchronisiert. Außerdem ist durch eine geeignete Schaltung festzustellen, ob bei dem Scann-Vorgang überhaupt eine oder mehrere Regeln gefeuert haben. 2.3 Regelbasis Die Regelbasis enthält einen Satz von Regeln R , R R $\dots \dots $. . Die Menge dieser


Full Text: PDF

GI, Gesellschaft für Informatik, Bonn
ISBN 3-88579-348-2


Last changed 04.10.2013 17:55:53