System zum rechnergestützten Erstellen von Regeln zur Überwachung und/oder Diagnose einer technischen Anlage

Die Erfindung betrifft ein System zum rechnergestützten Erstellen von Regeln zur Überwachung und/oder Diagnose einer technischen Anlage, insbesondere einer industriellen Anlage, wie z.B. einer Fertigungs- bzw. Produktionsanlage.

Zur Überwachung bzw. Diagnose von technischen Anlagen ist es erforderlich, basierend auf der Struktur der Anlage ein geeignetes Überwachungs- bzw. Diagnose-System zu erstellen, das im Betrieb der Anlage basierend auf Sensor-Signalen oder Pro- zessinformationen der Anlage Fehlfunktionen bzw. kritische Betriebszustände bzw. Ursachen hierfür feststellt.

Aus dem Stand der Technik sind regelbasierte ÜberwachungsSysteme bekannt, die ihr Verhalten basierend auf Regeln anpassen können, die es jedoch nicht ermöglichen, redundante Regeln zu identifizieren bzw. die Konsistenz von Regeln zu überprüfen oder die Regeln auf andere Weise zu analysieren.

Aufgabe der Erfindung ist es deshalb, ein System zur Erstel- lung von Regeln zur Überwachung und/oder Diagnose einer technischen Anlage zu schaffen, in dem ein Benutzer beim Entwurf von Regeln einfach und flexibel unterstützt wird und die Regeln automatisch überprüft werden können. Diese Aufgabe wird durch die unabhängigen Patentansprüche gelöst. Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen definiert.

Das erfindungsgemäße System umfasst eine digitale Wissensba- sis in der Form einer ersten Ontologie. Ontologien sind hinlänglich aus dem Stand der Technik bekannt und repräsentieren semantisches Wissen in der Form von digitalen Daten. Hierfür nutzen Ontologien sog. Konzepte bzw. Klassen und Relationen zwischen den Konzepten sowie weitere Konstrukte, wie Infe- renz- und Integritätsregeln zum Schlussfolgern und zur Gewährleistung ihrer Gültigkeit. Die erste Ontologie umfasst eine Anlagen-Ontologie, welche die technische Anlage basie- rend auf Konzepten und Relationen beschreibt, sowie eine Regel -Ontologie , welche als Konzepte Regeln umfasst und somit die Struktur der Regeln abbildet. Eine jeweilige Regel ist dabei über eine Bedingungs-Relation mit Konzepten in der Form von einer oder mehreren Bedingungen verknüpft, die auf ein oder mehrere Konzepte der Anlagen-Ontologie verweisen. Ferner ist eine jeweilige Regel über eine Konsequenz -Relation mit dem Konzept einer aus der oder den Bedingungen abgeleiteten Konsequenz (z.B. eines Zustands) verknüpft, die auf ein oder mehrere Konzepte der Anlagen-Ontologie verweist. Mit anderen Worten leitet eine jeweilige Regel eine Konsequenz in Bezug auf eine Anlagenkomponente dann ab, wenn der oder die Bedingungen der Regel erfüllt sind.

Das erfindungsgemäße System umfasst ferner eine Benutzer- Schnittstelle, über welche ein Benutzer die Regel -Ontologie durch Spezifikation von Regeln (insbesondere Instantiierung von Regeln) verändern kann, wodurch die erste Ontologie editiert wird. Darüber hinaus ist ein Reasoner (Schlussfolgerer) vorgesehen, wobei Reasoner zur Verarbeitung von Ontologien an sich bekannt sind. Der Reasoner wird auf eine zweite Ontologie angewendet. Die zweite Ontologie kann identisch mit der ersten editierten Ontologie sein oder mittels eines Ontolo- gie-Transformationsmittels aus der ersten editierten Ontologie abgeleitet werden. Der Reasoner verifiziert die Regeln in der zweiten Ontologie und gibt das Verifikationsergebnis über die Benutzerschnittstelle aus. Dem Benutzer wird somit wiederholt die Möglichkeit gegeben, basierend auf dem Verifikationsergebnis des Reasoners über die Benutzerschnittstelle nochmals Änderungen an den Regeln vorzunehmen und dann den Reasoner wieder laufen zu lassen. Der Reasoner erkennt insbesondere redundante, ähnliche, widersprüchliche und inkonsistente Regeln, und diese fehlerhaften Regeln können durch einen Benutzer dann behoben werden. Das erfindungsgemäße System umfasst ferner ein Regel -Generie- rungsmittel, um aus der ersten editierten Ontologie ausführbare Regeln zu generieren, die von einer Regel -Maschine

(engl. Rule Engine) ausgeführt werden können. Auf diese Weise werden Regeln geschaffen, die anschließend im Betrieb der technischen Anlage mittels der Regel -Maschine verarbeitet werden können, wobei die Regel -Maschine basierend auf den Regeln kritische Zustände, Fehlzustände und dgl . der techni- sehen Anlage erkennen kann bzw. diagnostizieren kann. Die

Ausführung von Regeln basierend auf Regel -Maschinen ist dabei an sich aus dem Stand der Technik bekannt.

Die Erfindung beruht auf der Erkenntnis, dass in einem regel- basierten Überwachungs- bzw. Diagnosesystem die Regeln basierend auf einer Ontologie repräsentiert werden können, was die Möglichkeit schafft, dass vom Benutzer erstellte Regeln automatisch mittels eines Reasoners analysiert werden können. Hierdurch wird ein verbessertes System zur Erstellung von be- nutzerspezifischen Regeln geschaffen, welche anschließend im Betrieb einer technischen Anlage zu deren Überwachung bzw. Diagnose genutzt weden können.

In einer besonders bevorzugten Ausführungsform wird die erste Ontologie basierend auf einem Ontologie-Editor beschrieben und ist mit dem Ontologie-Editor editierbar. Zum Beispiel kann als Editor Semantic Mediawiki verwendet werden, das auf OWL/RDF basiert. Semantic Mediawiki ist ein an sich bekannter Editor aus dem Semantic Web Bereich, der auf Webseiten ba- siert. Mit diesem Editor kann besonders einfach eine Benutzerschnittstelle zum Editieren von Regeln geschaffen werden. Ggf. kann die erste Ontologie jedoch auch über andere Editoren, wie z.B. Protege, beschrieben werden. In einer weiteren bevorzugten Ausführungsform wird die zweite Ontologie basierend auf der an sich bekannten Beschreibungssprache OWL (OWL - Ontology Web Language) realisiert. In einer weiteren Variante des erfindungsgemäßen Systems um- fasst die Anlagen-Ontologie eine strukturelle Ontologie und eine Prozess-Ontologie, wobei die strukturelle Ontologie Komponenten der Anlage sowie deren strukturellen Zusammenhänge und die Prozess-Ontologie durch die Komponenten der Anlage durchgeführte Prozesse beschreibt. Hierdurch können strukturiert die beim Betrieb einer Anlage ablaufenden Prozesse in der Ontologie abgebildet werden. In einer weiteren Ausgestaltung ist das erfindungsgemäße System derart ausgestaltet, dass es zunächst die editierte erste Ontologie exportiert, wobei die exportierte Ontologie anschließend mit dem Ontologie-Transformationsmittel in die zweite Ontologie überführt wird. Insbesondere wird dabei die exportierte Ontologie mit einer generischen Ontologie zusammengefügt, wobei die generische Ontologie Axiome und Konzepte enthält, die im Rahmen der Verifikation durch den Reasoner benötigt werden. Das Zusammenfügen von Ontologien sowie die Definition einer geeigneten generischen Ontologie ist dabei an sich aus dem Stand der Technik bekannt bzw. liegt im Rahmen von fachmännischem Handeln (siehe z.B. Bao, J. und Ho- navar, V. , "Adapt OWL as a Modular Ontology Language" , In

Proceedings of OWLED 2006 (November 10-11 2006)). Alternativ oder zusätzlich kann die weitere Ontologie von dem Regel - Generierungsmittel zur Erzeugung der ausführbaren Regeln genutzt werden.

In einer weiteren Variante des erfindungsgemäßen Systems können über die Benutzerschnittstelle ferner Konzepte und Rela- tionen der ersten Ontologie durch einen Benutzer spezifiziert werden. Hierdurch wird es ermöglicht, das System flexibel an beliebige technische Anlagen anzupassen.

Der im erfindungsgemäßen System verwendete Reasoner ist vor- zugsweise ferner derart ausgestaltet, dass er die Konzepte in der zweiten Ontologie klassifiziert und das Klassifikationsergebnis über die Benutzerschnittstelle ausgibt. Hierdurch werden dem Benutzer hilfreiche Informationen über die techni- sehe Anlage bzw. die verarbeiteten Regeln gegeben, die er dann wiederum im Rahmen des Editierens der ersten Ontologie berücksichtigen kann. In einer weiteren Ausführungsform des erfindungsgemäßen Systems ist die Benutzerschnittstelle derart ausgestaltet, dass ein Benutzer Abfragen an die zweite Ontologie richten kann, wobei die Abfrageergebnisse über die Benutzerschnittstelle ausgegeben werden. Vorzugsweise werden dabei Abfragen in der an sich bekannten Abfragesprache SPARQL verarbeitet. Gemäß dieser Variante kann der Benutzer die zweite Ontologie basierend auf seinen Wünschen geeignet analysieren.

In einer weiteren, besonders bevorzugten Ausführungsform ist das Regel -Generierungsmittel derart ausgestaltet, dass es zunächst Regeln in der an sich bekannten RIF-XML-Serialization- Syntax erzeugt und die Regeln dieser Syntax anschließend in die ausführbaren Regeln des Formats der Regel -Maschine übersetzt, wobei entsprechende Übersetzungsalgorithmen an sich bekannt sind. Das Format der Regel -Maschine ist dabei z.B. das Etalis-Format . Mit dieser Variante erfolgt eine Wandlung in das generische RIF-Format, was es ermöglicht, das System flexibel an verschiedene Formate unterschiedlicher Regel - Maschinen anzupassen.

Die Erfindung betrifft ferner ein Verfahren zum rechnergestützten Erstellen von Regeln zur Überwachung und/oder Diagnose einer technischen Anlage mittels des oben beschriebenen erfindungsgemäßen Systems. Dabei wird eine digitale Wissens- basis in der Form einer ersten Ontologie bereitgestellt, wobei die erste Ontologie eine Anlagen-Ontologie umfasst, welche die technische Anlage basierend auf Konzepten und Relationen beschreibt, sowie eine Regel -Ontologie, welche als Konzepte Regeln umfasst, wobei eine jeweilige Regel über eine Bedingungs-Relation mit Konzepten in der Form von einer oder mehreren Bedingungen verknüpft ist, die auf eine oder mehrere Konzepte der Anlagen-Ontologie verweisen, und über eine Konsequenz-Relation mit dem Konzept einer aus der oder den Be- dingungen abgeleiteten Konsequenz verknüpft ist, die auf eine oder mehrere Konzepte der Anlagen-Ontologie verweist. Ferner wird eine Benutzerschnittstelle bereitgestellt, über welche ein Benutzer die Regel -Ontologie durch Spezifikation von Re- geln verändern kann, wodurch die erste Ontologie editiert wird .

Im Rahmen des obigen Verfahrens wird ein Reasoner auf eine zweite Ontologie angewendet, welche mittels eines Ontologie- Transformationsmittels aus der ersten editierten Ontologie abgeleitet ist oder welche die erste editierte Ontologie ist, wobei der Reasoner die Regeln in der zweiten Ontologie verifiziert und das Verifikationsergebnis über die Benutzerschnittstelle ausgibt. Ferner generiert ein Regel -Generie- rungsmittel aus der ersten editierten Ontologie ausführbare Regeln, die von einer Regel -Maschine ausgeführt werden können .

Alle im Vorangegangenen beschriebenen bevorzugten Varianten des erfindungsgemäßen Systems können analog auch in dem oben beschriebenen erfindungsgemäßen Verfahren implementiert werden .

Die Erfindung betrifft darüber hinaus ein Verfahren zur Über- wachung und/oder Diagnose einer technischen Anlage, wobei ausführbare Regeln, die mit dem oben beschriebenen erfindungsgemäßen System erstellt sind bzw. werden, während des Betriebs der technischen Anlage über eine Regel -Maschine ausgeführt werden.

Ferner betrifft die Erfindung eine Vorrichtung zur Überwachung und/oder Diagnose einer technischen Anlage, wobei die Vorrichtung zur Ausführung des oben beschriebenen Verfahrens zur Überwachung bzw. Diagnose der technischen Anlage einge- richtet ist.

Die Erfindung umfasst ferner ein Computer-Programmprodukt mit einem auf einem maschinenlesbaren Träger gespeicherten Pro- grammcode zur Durchführung des oben beschriebenen erfindungs- gemäßen Verfahrens zum Erstellen von Regeln bzw. des oben beschriebenen erfindungsgemäßen Verfahrens zur Überwachung und/oder Diagnose einer technischen Anlage, wenn der Pro- grammcode auf einem Computer ausgeführt wird.

Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Figuren detailliert beschrieben. Es zeigen:

Fig. 1 eine schematische Darstellung einer Ausführungsform des erfindungsgemäßen Systems zur Erstellung von Regeln;

Fig. 2 eine schematische Darstellung der in der Wissensbasis aus Fig. 1 enthaltenen Ontologie;

Fig. 3 eine detaillierte Darstellung der in Fig. 2 enthalte- nen Anlagen-Ontologie ;

Fig. 4 eine detaillierte Darstellung der in Fig. 2 enthaltenen Regel -Ontologie ; Fig. 5 eine schematische Darstellung einer Klassifikation des Konzepts der Bedingung aus der Regel -Ontologie der Fig . 4 ; und

Fig. 6 eine schematische Darstellung eines Beispiels einer

Regel, die in der Ontologie ON2 aus Fig. 1 enthalten ist .

Im Folgenden wird ein Ausführungsbeispiel der Erfindung basierend auf der Überwachung bzw. Diagnose einer technischen Anlage in der Form einer industriellen Anlage beschrieben, bei der es sich z.B. um eine Fertigungsstraße oder um eine andere Anlage zur Herstellung von Produkten handeln kann. In der Regel umfasst die Überwachung einer industriellen Anlage die Ableitung von Gerätezuständen der industriellen Anlage, um die Wartung dieser Geräte geeignet zu planen. Ferner beinhaltet die Überwachung meist auch eine sog. Prozess-Überwa- chung, bei der bestimmte Prozesse, die im Betrieb der Anlage durchgeführt werden, überwacht werden, um deren korrekte Ausführung zu gewährleisten. Ferner beinhaltet die Überwachung einer industriellen Anlage in der Regel auch eine Energie- Überwachung, welche den aktuellen Energieverbrauch der Anlage im Vergleich zu einem erwarteten Energieverbrauch analysiert. Die Betreiber einer industriellen Anlage müssen somit eine Vielzahl von verschiedenartigen Überwachungsaufgaben durchführen. Die im Folgenden beschriebene Ausführungsform stellt dabei ein System bereit, mit dem entsprechende Regeln zur Überwachung der Anlage einfach und effizient erstellt, ver- waltet und ausgeführt werden können.

Fig. 1 zeigt in schematischer Darstellung eine Architektur, mit der entsprechende Regeln erzeugt werden können. Die erzeugten Regeln können im Rahmen der Überwachung bzw. gegebe- nenfalls einer Diagnose einer technischen Anlage angewendet werden. Die Architektur umfasst die Komponente RUEN, welche das Erstellen entsprechender Regeln durch einen Benutzer betrifft (sog. Rule Engineering), die Komponente RUMA, welche die Weiterverarbeitung bzw. Verwaltung der Regeln betrifft (sog. Rule Maintenance) , sowie die Komponente RÜDE, welche die Umsetzung bzw. Nutzung der Regeln betrifft (sog. Rule Deployment) .

Gemäß der Ausführungsform der Fig. 1 wird eine Wissensbasis KB in der Form einer (ersten) Ontologie 0N1 bereitgestellt.

Diese Ontologie umfasst eine Anlagen-Ontologie PON sowie eine Regel -Ontologie RON. Dabei ist eine Benutzerschnittstelle UI vorgesehen, mit der ein Benutzer, die Regeln zur Überwachung bzw. Diagnose der technischen Anlage entwirft, die Wissensba- sis bzw. die erste Ontologie editieren kann, indem er Regeln in der Regel -Ontologie RON spezifiziert bzw. instantiiert . Gegebenenfalls kann ein Benutzer auch Konzepte zu der Anlagen-Ontologie bzw. Regel -Ontologie hinzufügen. Beispiele ei- ner Anlagen-Ontologie und einer Regel -Ontologie werden weiter unten näher beschrieben. Erfindungswesentlich ist dabei, dass in der Wissensbasis KB die Regeln selbst wiederum als eine Ontologie enthalten sind, was es im Rahmen der Weiterverar- beitung der Regeln (Komponente RUMA) ermöglicht, diese Regeln geeignet über einen Reasoner zu verifizieren und zu klassifizieren .

Wie sich aus den obigen Ausführungen ergibt, kann somit ein Benutzer, wie z.B. ein Ingenieur mit Wissen über die Anlage, sein Wissen in der Form einer Ontologie-Bibliothek 0N1 in der Wissensbasis KB ablegen bzw. editieren. Die Wissensbasis enthält Ontologien, welche den Ingenieur unterstützen, hierauf anlagen- spezifische Ontologien durch Bearbeiten der Wissens- basis zu generieren. Der Benutzer hat dabei die Möglichkeit, entweder zusätzliche Konzepte zu der Bibliothek hinzuzufügen oder Konzepte auf bereits bestehende Konzepte in der Bibliothek abzubilden. Hierdurch wird die Flexibilität und Anpass- barkeit der Wissensbasis gewährleistet.

In der hier beschriebenen Ausführungsform wird zum Editieren der Wissensbasis KB bzw. der Ontologie ON1 der an sich bekannte Editor „Semantic Mediawiki (SMW) " verwendet, der die Ontologie-Bibliothek in entsprechende RDF-Modelle (RDF = Re- source Description Framework) umsetzt, welche es einem Benutzer ermöglichen, strukturiertes Wissen über die Anlage in der Form von Webseiten zu erzeugen und zu editieren. Semantic Mediawiki unterstützt dabei Experten in ihrer Aufgabe, Daten der Anlage und Regeln zur Überwachung bzw. Diagnose der Anla- ge zu modellieren. Ferner ermöglicht Semantic Mediawiki die Visualisierung und Navigation in entsprechenden modellierten Daten über die technische Anlage. Mit der Komponente RUEN und der zugeordneten Schnittstelle UI wird somit einem Experten ermöglicht, die der Überwachung bzw. Diagnose zugrunde lie- gende technische Anlage näher zu spezifizieren und entsprechende Regeln zur Überwachung bzw. zur Diagnose der Anlage festzulegen . Gemäß der Ausführungsform der Fig. 1 wird die durch den Benutzer editierte erste Ontologie ON1 in eine anlagen- spezifi - sehe Ontologie PSON exportiert, die auf der an sich bekannten OWL/RDF-Spezifikation beruht (OWL = Ontology Web Language) . Dieser Export kann über Semantic Mediawiki mittels der speziellen Webseite „Special : ExportRDF" erfolgen. Der Export der Ontologie ist in Fig. 1 mit dem Pfeil PI bezeichnet. Dabei besteht auch die Möglichkeit, dass die exportierte Ontologie wieder in die Wissensbasis KB importiert wird, was durch den Pfeil P2 angedeutet ist. Dies wird durch ein Skript erreicht, welches OWL in die SMW-Syntax wandelt. Ein weiteres Merkmal von SMW ist eine Benutzerführung, die durch Templates und Semantic Forms erreicht wird, wodurch es ermöglicht wird, explizit Regel -Vorlagen für Benutzer zu spezifizieren.

Ein Vorteil der Verwendung von Semantic Mediawiki besteht ferner darin, dass die Zusammenarbeit von verschiedenen Experten ermöglicht wird, welche mit unterschiedlichen Aspekten der Anlage vertraut sind. Zum Beispiel können Hersteller von Komponenten der Anlage allgemeine Überwachungsregeln für diese Komponenten spezifizieren, da sie vertieftes Wissen haben, welches zur Überwachung der Komponenten benötigt wird. Ein weiterer Vorteil von Semantic Mediawiki besteht darin, dass es zum einen eine Gesamtübersicht über alle Aspekte der über- wachten Anlage mit Navigationslinks liefert und zum anderen spezifische Aspekte der Anlage mit sog. ASK-Abfragen gefiltert werden können.

In der Ausführungsform der Fig. 1 wird die generierte anla- gen- spezifische Ontologie PSON in eine zweite OWL-Ontologie ON2 mit einem Ontologie-Transformationsmittel OTM überführt, was durch den Pfeil P3 angedeutet ist. Diese Ontologie ON2 annotiert die Ontologie PSON mit entsprechenden Axiomen und Konzepten (auch als Klassen bezeichnet) , welche bei der Wei- terverarbeitung der Regeln in der Komponente RUMA benötigt werden. Im Rahmen der Weiterverarbeitung der Regeln wird dabei ein sog. Reasoner REA eingesetzt, wobei Reasoner zum Ableiten von Wissen aus Ontologien an sich bekannt sind. Zum Beispiel kann der Reasoner HermiT bzw. Fact++ bzw. Pellet verwendet werden.

Der Reasoner REA wird auf die Ontologie ON2 angewendet, wie durch den Pfeil P4 angedeutet ist. Der Reasoner verifiziert dabei die in der Ontologie ON2 enthaltenen Regeln, indem er semantisch nicht korrekte Regeln identifiziert. Ferner klassifiziert er die Regeln, indem er sie in einer strukturierten Taxonomie (d.h. Klassifikation) anordnet. Das entsprechende Verifikations- und Klassifikationsergebnis wird wiederum über die Benutzerschnittstelle UI ausgegeben. Der Benutzer kann dann basierend auf dem angezeigten Ergebnis entsprechende Widersprüche in der ursprünglichen Wissensbasis bzw. darin enthaltene Fehler korrigieren. In der Ausführungsform der Fig. 1 besteht ferner die Möglichkeit, dass ein Benutzer Abfragen

QUE an die Ontologie ON2 richtet, wie durch den Pfeil P5 angedeutet ist. Hierdurch kann er z.B. wiederverwendbare Regeln aus der Ontologie herausfiltern. Gemäß der Ausführungsform der Fig. 1 erfolgt eine Umsetzung RÜDE der Regeln derart, dass mit einem Regel-Generierungs- Mittel RGM die Ontologie PSON in sog. RIF-Regeln RR übersetzt wird (siehe Pfeil P6) . Hierfür werden alle Regel -bezogenen Informationen der Ontologie PSON in eine Regel -Ontologie ex- portiert, welche dann in die RIF-Regeln RR gewandelt wird.

RIF ist ein an sich bekanntes Format, das z.B. durch die RIF- XML-Serialization-Syntax repräsentiert werden kann. Diese Syntax wird mit dem Regel-Generierungs-Mittel RGM über an sich bekannte Verfahren in ausführbare Regeln EXR eines Re- gel-Sprach-Formats gewandelt, die dann durch eine Regel- Maschine RM (engl. Rule Engine) ausgeführt werden können. Die Wandlung der RIF-Regeln RR in ausführbare Regeln EXR ist in Fig. 1 durch den Pfeil P7 angedeutet. In einer speziellen Ausführungsform beruhen die ausführbaren Regeln dabei auf dem Format Etalis. Mit der entsprechenden Regel -Maschine RM können diese Regeln dann im Realbetrieb des technischen Systems ausgeführt werden (Pfeil P8) . Als Ergebnis können entsprechende Überwachungs- oder Diagnosezustände der technischen Anlage und deren Komponenten bei deren Betrieb basierend auf Sensordaten oder Prozessdaten mithilfe der ausführbaren Regeln abgeleitet werden. Es können somit z.B. Warnmeldungen ausgegeben werden, sofern im Betrieb der technischen Anlage kritische Zustände auftreten. Ebenso können über die ausführbaren Regeln z.B. Diagnosedaten der technischen Anlage gewonnen werden. Durch die Zwischenwandlung der Regeln in das RIF-Format wird die Flexibilität des Systems erhöht, da der Benutzer eine geeignete Regel -Maschine in Abhängigkeit von den Anlagen- spezifischen Gegebenheiten auswählen kann. Falls das System z.B. Echtzeit-Ereignisse überwachen soll, kann er eine komplexere CEP (Complex Event Processing) Regel -Maschine , wie z.B. Drools Fusion, verwen- den.

Im Folgenden werden die in der Wissensbasis KB enthaltenen Ontologien PON und RON näher erläutert. Die nachfolgend beschriebenen Ontologien beruhen zum Teil auf Ontologie-Mustern von bekannten Ontologie-Quellen . Zum Beispiel basieren sie auf der Process Specification Language (PSL) , welche semantischen Konzepte in Bezug auf den durch die Anlage durchgeführten Prozess identifiziert, formal definiert und strukturiert. Die Anlagen-Ontologie PON enthält semantisches Wissen über die spezifische Anlage, wie z.B. über Verbindungen zwischen Komponenten der Anlage oder über Produkte, welche durch die Anlage hergestellt werden. Demgegenüber enthält die Regel - Ontologie RON Regeln zur Erkennung von Zuständen in der Anlage, wie z.B. eine Regel zum Ableiten des Zustands

„powerTooHigh" (d.h. zu hohe elektrische Leistung) für einen Motor ml der Anlage.

Die Anlagen-Ontologie PON wird in der hier beschriebenen Ausführungsform ferner nochmals aufgeteilt in eine strukturelle Ontologie STON und eine Prozess-Ontologie PRON (Fig. 2) . Die strukturelle Ontologie definiert verschiedene Arten von grundlegenden Informationen. Zum einen wird eine Komponenten- Taxonomie festgelegt, welche Klassen von Komponenten identi- fiziert und benennt und diese in einer Hierarchie anordnet. Ferner beschreibt die strukturelle Ontologie die Topologie der Anlage, was über eine Hierarchie erreicht wird, die festlegt, welche Komponenten in anderen Komponenten enthalten sind. Hierzu wird die weiter unten beschriebene Relation

„part-of" (abgekürzt po) genutzt sowie andere Relationen, die ebenfalls weiter unten beschrieben sind. Darüber hinaus definiert die strukturelle Ontologie Eigenschaften von Komponenten über Attribute. Der Namensraum der strukturellen Ontolo- gie ist „pl : " .

Die Prozess-Ontologie PRON spezifiziert das Material, das durch Aktivitäten der Anlage verarbeitet und durch Komponenten der Anlage während des gesamten Produktionsprozesses ma- nipuliert wird. Der Namensraum der Prozess-Ontologie ist „pr : " .

Im Unterschied zu den obigen Ontologien STON und PRON verwendet die Regel -Ontologie PON Konzepte, welche benötigt werden, um grundlegende Regeln zur Erkennung von Zuständen der überwachten Elemente der anderen Ontologien zu spezifizieren. Diese Regel-Ontologie ist ein wesentlicher Bestandteil des erfindungsgemäßen Systems, da sie zum Erstellen und zum Weiterverarbeiten der Regeln benötigt wird. Der Namensraum der Regel-Ontologie ist „mon:".

Fig. 2 zeigt ein UML-Diagramm, welches eine Ausführungsform einer im erfindungsgemäßen System verwendeten Ontologie ON1 zeigt. Wie oben erwähnt, umfasst diese Ontologie die Anlagen- Ontologie PON und die Regel-Ontologie RON. Die Anlagen-Onto- logie setzt sich aus der strukturellen Ontologie STON und der Prozess-Ontologie PRON zusammen. In an sich bekannter Weise werden in dem Diagramm der Fig. 2 und auch in weiteren Figuren durch Pfeile mit schwarzen Spitzen Relationen RE darge- stellt. Aus Übersichtlichkeitsgründen sind nur einige der Relationen mit dem Bezugszeichen RE versehen. Demgegenüber charakterisieren Pfeile mit weißen Spitzen Klassenbeziehungen, d.h. das Konzept, an dem ein Pfeil mit weißer Spitze endet, ist ein übergeordnetes Konzept des Konzepts, an dem der Pfeil seinen Ursprung hat. Die Blöcke in Fig. 2, welche keine

Ontologien sind, stellen die Klassen bzw. Konzepte dar, welche aus Übersichtlichkeitsgründen nur zum Teil mit dem Be- zugszeichen CL versehen sind. Durch die Pfeile mit gestrichelten Linien P9 bzw. P10 wird ferner angedeutet, dass die Ontologie RON die Ontologie PON bzw. die Ontologie PRON die Ontologie STON nutzt. Die strukturelle Ontologie STON enthält als Konzepte Attribute ATT sowie Komponenten COM der Anlage. Die Prozess-Ontologie PRON enthält als Konzepte Aktivitäten ACT sowie Material MAT . Die Regel -Ontologie RON enthält als Konzepte Regeln RU, Zustände ST, Bedingungen CO sowie Elemente EL. Folgende Relationen sind in der Ontologie ON1 der Fig. 2 enthalten:

- Relation sb (= specified-by) , die festlegt, durch welches Attribut ATT eine Komponente COM spezifiziert wird;

- Relation mo (= monitors) , welche festlegt, welches Element EL durch die Komponente COM überwacht wird;

- Relation pi (= participates-in) , welche festlegt, an welcher Aktivität ACT eine Komponente COM beteiligt ist;

- Relation hp (= has-participant) , welche festlegt, welche Komponente COM an einer Aktion ACT beteiligt ist;

- Relation pro (= processes) , welche festlegt, welche Akti- vität ACT ein Material MAT verarbeitet;

- Relation ipr (= is-processed) , welche festlegt, welches Material MAT durch eine Aktivität ACT verarbeitet wird;

- Relation ma (= manipulates) , welche festlegt, welche Komponente COM ein Material MAT verarbeitet;

- Relation ima (= is-manipulated-by) , welche festlegt, welches Material MAT durch eine Komponente COM manipuliert (verarbeitet) wird;

- Relation bo (= body) , welche einer if-Relation entspricht und eine Bedingung CO der entsprechenden Regel RU fest- legt;

- Relation he (= head) , welche einer then-Relation entspricht und festlegt, welcher Zustand ST aufgrund der Re- gel RU beim Eintritt der über die Relation bo spezifizierten Bedingung CO eintritt;

- Relation ri (= resides-in) , welche festlegt, welcher Zustand ST durch ein Element EL eingenommen wird.

Im Speziellen enthält die Anlagen-Ontologie PON der Fig. 2 die in der nachfolgenden Tabelle beschriebenen Konzepte (= Klassen) mit einer entsprechenden (informellen) Definition. Nicht all diese Konzepte sind in Fig. 2 gezeigt. Die nachfol- gend genannten deutschen Begriffe für die Konzepte sind dabei äquivalent zu den in Klammern genannten englischen Begriffen.

Konze t Definition

Element EL Zentrales Konzept dieser Ontologie, welches (= Element) alle Objekte einer Anlage umfasst.

Aktivität Eine Aktion, welche in der Prozess-Ontologie ACT ( = definiert ist, z.B. entspricht „mlRunFast" der Activity) Klasse der Aktionen, in welcher ein Motor ml

ein Objekt schnell bewegt.

Aktivitäts- Eine Aktion, welche an einem spezifischen Ort Auftreten und einem spezifischen Zeitpunkt instantiiert ACO ( = ist, z.B. entspricht „mlRunFast wird durch MoActivity- tor ml um 14 Uhr am 25. Mai 2013 ausgeführt" Occurrence) dem Auftreten der Aktivität „mlRunFast".

Komponente Dieses Konzept beschreibt eine einzelne oder COM (= Com- eine zusammengesetzte Komponente in der Anlaponent ) ge. Die Komponenten können über die Relation

pi an Aktivitäten teilnehmen. Jede Anlage setzt sich aus mehreren Komponenten zusammen, z.B. ist die Komponente „Motor ml" Teil der Arbeitszelle 1.

Material Eine Klasse des Materials wird über die RelaMAT (= Mation ima durch Komponenten in der Anlage maniterial) puliert und durch die Relation pro durch Aktivitäten verarbeitet. Die Klasse Material ist entweder eine natürliche Ressource NAR, ein Produkt PRO oder ein Hilfsmaterial AUM. Ein Beispiel für eine natürliche Ressource ist

Energie .

Material - Diese Klasse bezeichnet Material, das in einer Auftreten Anlage an einem spezifischen Ort und zu einem MAO (= Maspezifischen Zeitpunkt verarbeitet wird, z.B. terial - „ein Teil eines Fahrzeugs, das über ein FörOccurrence) derband um 14 Uhr am 24. Juni 2013 transportiert wird" .

Attribut Die Klasse Attribut wird verwendet, um EigenATT (= Atschaften von Elementen bzw. Komponenten zu tribute) spezifizieren, z.B. kann eine Komponente Attribute wie „maximale Eingangsleistung = 400W" umfassen .

Attribut- Diese Klasse beschreibt eine Eigenschaft eines Auftreten Elements, die zu einem bestimmten Zeitpunkt ATO (= At- instantiiert wird, z.B. „ein Motor ml hat die tribute- Eingangsleistung von 500W um 14 Uhr am 25. Mai Occurrence) 2013" .

Fig. 3 zeigt nochmals eine detaillierte Darstellung der oben beschriebenen Anlagen-Ontologie PON in der Form eines UML- Diagramms . Neben den bereits in Fig. 2 enthaltenen Klassen bzw. Relationen sind noch die folgenden weiteren Klassen bzw. Relationen gezeigt:

- Die Klasse ATO, welche dem oben beschriebenen Attribut- Auftreten entspricht;

- die Klasse ACO, welche dem oben beschriebenen Aktivitäts- Auftreten entspricht;

- die Klasse MAO, welche dem oben beschriebenen Material - Auftreten entspricht;

- die Klasse NAR, welche der oben beschriebenen natürlichen Ressource entspricht;

- die Klasse PRO, welche dem oben beschriebenen Produkt ent- spricht ;

- die Klasse AUM, welche dem oben beschriebenen Hilfsmateri- al entspricht; - die Relation ato (= attribute-occurence-of) , welche spezifiziert, welches Attribut ATT in der Klasse ATO vorkommt;

- die Relation aco (= activity-occurence-of) , welche spezifiziert, welche Aktivität ACT in der Klasse ACO vorkommt; - die Relation mao (= material -occurence-of) , welche spezifiziert, welches Material MAT in der MAO vorkommt;

- die Relation po/ct (= part-of/connected-to) , welche spezifiziert, von welcher übergeordneten Komponente die Komponente COM Teil ist bzw. mit welcher Komponente die Kompo- nente COM verbunden ist.

Einige der Konzepte der oben beschriebenen Anlagen-Ontologie bauen auf Ontologie-Muster von verfügbaren Ontologie-Quellen auf, wie z.B. die Konzepte „Aktivität" und „Aktivitäts-Auf- treten" mit entsprechenden Axiomen aus der PSL-Ontologie . Alle anderen Konzepte wurden extrahiert, indem verschiedene Produktionsanlagen analysiert wurden, bekannte Standards im Bereich der Herstellung (z.B. CAEX für eine Anlagen-Struktur) überprüft wurden und Interviews mit Experten durchgeführt wurden. Einige Konzepte der in Fig. 3 gezeigten Anlagen-Ontologie PON werden erst zur Laufzeit der Anlage instantiiert . Diese Konzepte sind ergänzend in Fig. 3 mit dem Bezugszeichen CL ' bezeichnet und betreffen die Klassen Attribut-Auftreten ATO, Aktivitäts-Auftreten ACO und Material -Auftreten MAO. Diese Konzepte werden als Platzhalter mit Standard-Namen modelliert, so dass sie durch andere Konzepte in der Ontologie repräsentiert und referenziert werden können. Alle Eigenschaften der in Fig. 3 gezeigten Anlagen-Ontologie stellen eine Untereigenschaft der Relation structural-relation dar, die in der weiter unten beschriebenen Fig. 4 mit dem Bezugszeichen str bezeichnet ist.

In der nachfolgenden Tabelle sind Konzepte wiedergegeben, die in der Regel -Ontologie RON enthalten sind. Die nachfolgend genannten deutschen Begriffe für die Konzepte sind dabei äquivalent zu den in Klammern genannten englischen Begriffen. Konze t Definition

überwachtes Zentrales Konzept dieser Ontologie, welche alElement MEL le Elemente EL einer Anlage umfasst, die über( = wacht werden können. Dies ist entweder eine

Monitoring Aktivität, eine Komponente oder ein Material. Element)

Regel RU (= Eine Regel wird verwendet, um einen Zustand ST Rule) für ein überwachtes Element EL basierend auf einer oder mehreren überwachten Bedingungen CO abzuleiten .

Bedingung Eine Bedingung muss erfüllt sein, um eine ReCO ( = gel auszulösen. Eine Bedingung ist dann er¬

Monitoring füllt, wenn ein spezifischer Operator (z.B. Condition) „gleich") zwischen einem Element EL, das über die Relation re (= reference) mit der Bedingung verbunden ist, und einem Auftreten OC (weiter unten beschrieben) vorhanden ist. Unterschiedliche überwachte Bedingungen können mit logischen Operatoren, wie z.B. OR oder AND verknüpft sein.

Zustand ST Eine Klasse von Zuständen, in der sich ein (= State) überwachtes Element befindet. Beispielsweise kann ein Zustand definiert sein als „Energie- Verbrauch zu hoch" .

Zustands- Ein Auftreten eines Zustands . Zum Beispiel ist Auftreten „Energie-Verbrauch des Motors ml ist zu hoch STO (= Sta- um 14 Uhr am 25. Mai 2013" ein Zustands- te-Occur- Auftreten des Zustands „Energie-Verbrauch ist rence) zu hoch" .

Auftreten Ein Supertyp von allen Objekten, die im BeOC ( = trieb der Anlage instantiiert werden.

Occurrence)

Zeitpunkt Ein spezieller Zeitpunkt.

TP ( =

Timepoint) Die anhand der obigen Tabelle erläuterten Konzepte bzw. Relationen sind nochmals detailliert in Fig. 4 dargestellt. Dabei werden die Konzepte bzw. Relationen wie folgt bezeichnet: - RU entspricht dem oben erläuterten Konzept einer Regel;

- CO entspricht dem oben erläuterten Konzept einer überwachten Bedingung;

- ST entspricht dem oben erläuterten Konzept eines Zustands;

- EL entspricht dem oben erläuterten Konzept eines Elements; - OC entspricht dem oben erläuterten Konzept eines Auftretens ;

- STO entspricht dem oben erläuterten Konzept eines Zustand- Auftretens ;

- TP entspricht dem oben erläuterten Konzept eines Zeit- punkts;

- MEL entspricht dem oben erläuterten Konzept eines überwachten Elements;

- lo (= logical Operator) entspricht einem logischen Operator, wie AND oder OR;

- re (= reference) entspricht der oben erläuterten Relation „reference" und verweist auf ein Element EL;

- op (= Operator) entspricht der Relation „Operator" und

verweist auf ein Auftreten OC;

- so(= state-occurence-of) entspricht der Relation des Auf- tretens eines Zustands;

- io(= is-occuring-at) entspricht der Relation des Auftretens eines Zustands zu einer bestimmten Zeit.

Die weiteren, in Fig. 4 enthaltenen Relationen wurden bereits im Vorangegangenen beschrieben. Wiederum bezeichnen die Klassen CL ' Konzepte, welche während der Laufzeit der Anlage in- stanziiert werden.

Über die Regel -Ontologie gemäß Fig. 4 kann die korrekte

Struktur von Regeln während deren Entwurfs verifiziert werden. Erfindungswesentlich ist dabei, dass nicht nur das Wissen über die technische Anlage, sondern auch die Regeln in der Form von Ontologien erfasst sind. Vor dem Spezifizieren einer Regel für ein spezielles überwachtes Element ml (ml bezeichnet einen Motor) über die Benutzerschnittstelle UI kann ein Experte nach Informationen über ml suchen, die in der An- lagen-Ontologie hinterlegt sind. Zum Beispiel kann der Benut- zer nach dem Attribut „powerMl" oder dem Prozess „RunFast" suchen, die mit ml in Verbindung stehen. Das Attribut „powerMl" bezeichnet dabei die Leistung, mit der der Motor betrieben wird. Während der Definition einer Regel kann der Experte alle Elemente auswählen, die mit der Komponente ml in Beziehung stehen, insbesondere die gerade erwähnten Attribute bzw. Prozesse „powerMl "und „RunFast". Basierend darauf kann er dann eine Regel spezifizieren, wie z.B. die Regel RU1 , die in der weiter unten beschriebenen Fig. 6 gezeigt ist. Das System kann dann über ein Axiom verschiedene Vorgaben verifi - zieren, z.B. mittels eines Axioms, welches aussagt, dass alle überwachten Bedingungen, die über die Relation lo mit einer Regel (in diesem Fall RU1) verknüpft sind, nur eine Relation structural-relation (str) zu den Objekten haben kann, auf welche sich das überwachte Element (in diesem Fall ml) be- zieht.

Zusätzlich kann ein Benutzer die Konzepte der Regel -Ontologie nutzen, um manuell Taxonomien von Zuständen, überwachten Bedingungen oder Regeln zu konstruieren. Solche Taxonomien wei- sen verschiedene Vorteile auf. Zum einen wird eine höhere

Wiederverwendbarkeit der überwachten Regeln aufgrund der gemeinsamen Informationsstrukturen erreicht, wenn neue Regeln durch den Benutzer entworfen werden. Zum anderen wird die Zusammenarbeit zwischen verschiedenen Experten erleichtert, da die automatische Auswahl von Objekten mit identischen Bedeutungen vereinfacht wird.

Fig. 5 zeigt in schematischer Darstellung eine mögliche Erweiterung der in Fig. 4 gezeigten Ontologie, wobei eine Taxo- nomie der überwachten Bedingung CO gebildet wird. Im Besonderen enthält die Klasse der überwachten Bedingung CO die Unterklassen PRC (Prozess-Bedingung) , ATC (Attribut-Bedingung) , STC (Zustands-Bedingung) sowie MAC (Material -Bedingung) . Die- se Bedingungen sind mit Unterklassen der Klasse Element EL und der Klasse Auftreten OC verknüpft, nämlich den Klassen ACT, ACO, ATT, ATO, ST, STO, MAT, MAO, die bereits im Vorangegangenen beschrieben wurden. Diese Unterklassen sind mit der Klasse COM über geeignete Relationen verknüpft, nämlich den Relationen pi, ex, sb, ha, ri, hs, ma, mac . Bis auf die Relationen ex, ha, hs und mac wurden alle genannten Relationen bereits oben erläutert. Die Relation ex (= executes) bedeutet, dass die Komponente COM das Aktivitäts-Auftreten ACO ausführt. Die Relation ha (= has-attribute) bedeutet, dass die Komponente COM das Attribut ATO hat. Die Relation hs (= has-state) bedeutet, dass die Komponente COM den Zustand STO hat. Die Relation mac bedeutet, dass die Komponente COM das Material -Auftreten MAC verarbeitet. Die einzelnen Klassen PRC, ATC, STC und MAC haben Relationen mit den genannten Unterklassen der Klasse Element EL und der Klasse Auftreten OC. Dabei werden die Relationen acr, acop, atr, atop, sr, sop, mr und mop verwendet . Die Bedeutung dieser Relationen ist wie folgt: acr (= activityRef) stellt eine Referenz re auf eine Aktivität ACT dar;

acop (= activityOp) stellt einen Operator op für ein Aktivi- täts-Auftreten ACO dar;

atr (= attributeRef) stellt eine Referenz re auf ein Attribut ATT dar;

atop (= attributeOp) stellt einen Operator op für ein Attribut-Auftreten ATO dar;

sr (= stateRef) stellt eine Referenz re auf einen Zustand ST dar;

sop (= stateOp) stellt einen Operator op für ein Zustands- Auftreten STO dar;

mr (= materialRef) stellt eine Referenz re auf ein Material MAT dar;

mop (= materialOp) stellt einen Operator op für ein Material- Auftreten MAO dar. Mit der in Fig. 5 gezeigten Ontologie kann die Regel -Ontolo- gie auf verschiedene technische Domänen durch Hinzufügen von domänen- spezifischen Klassen erweitert werden. Zum Beispiel wird die Bedingung „Temperatur von ml größer 40 °C" nunmehr gemäß Fig. 5 durch die Unterklasse Attribut-Bedingung ATC repräsentiert, wohingegen „Aktivitäts-Auftreten von ml = mittlere Geschwindigkeit" durch die Unterklasse Prozess-Bedingung PRC spezifiziert ist. Ebenso ist bspw. aus Fig. 5 ersichtlich, dass die Prozessbedingung PRC eine Unterklasse der überwachten Bedingung CO ist.

Fig. 6 verdeutlicht beispielhaft eine über die Benutzerschnittstelle UI in der Wissensbasis KB der Fig. 1

instantiierte Regel RU1 in Bezug auf den Motor ml. Die Regel enthält dabei die Prozess-Bedingung PRC-ml, die Attribut- Bedingung ATC-ml sowie die Zustands-Bedingung STC-ml . Die Darstellung der Fig. 6 ist dem Fachmann hinlänglich bekannt und beruht auf OWL . Dabei bezeichnen rechteckige Boxen OWL- Klassen, schwarze Rauten OWL- Individuen, weiße Rauten anonyme OWL- Individuen, durchgezogene Pfeile OWL-Obj ekteigenschaften und gestrichelte Pfeile OWL-Datentyp-Eigenschaften . Fig. 6 enthält die Typdeklarationen RDF : type sowie die an sich bekannte Relation differentFrom aus dem OWL-Namensräum . Ferner bezeichnet die Komponente wcl die Arbeitszelle 1 und es exis- tieren das Aktivitäts-Auftreten ProcessOccMl , das Attribut- Auftreten InputPowerMl , der Zustand TempTooHigh und das Zu- stands-Auftreten StateOccWcl. Darüber hinaus existiert der Zustand powTooHigh_RunFast_TempTooHigh . Ferner sind als neue, noch nicht beschriebene Relationen iet (= isEqualto = ist ge- nauso groß wie) sowie ibt (= isBiggerthan = ist größer als) in Fig. 6 enthalten, welche Untertypen der Relation "Operation" sind. Ferner bezeichnet die Relationen io (= instance-of) eine entsprechende Instantiierung in der RDF-Syntax, die Relation mv (= measured-value) stellt einen Messwert dar und die Relation mip bezeichnet die maximale Eingangsleistung.

Darüber hinaus ist in Fig. 6 eine Taxonomie von Zuständen wiedergegeben, welche über die Benutzerschnittstelle UI aus Fig. 1 durch einen Benutzer festgelegt werden kann.

PowTooHigh bezeichnet dabei den Zustand mit zu hoher Leistung des Motors ml, TempTooHigh den Zustand mit zu hoher Temperatur des Motors ml und TempTooLow den Zustand mit zu niedriger Temperatur des Motors ml. Wie bereits oben erwähnt, bezeichnet RunFast den Zustand eines schnell laufenden Motor. Der Zustand PowTooHigh ist eine Unterklasse des Leistungszustands POS. Die Zustände TempTooHigh und TempTooLow sind Unterklassen des Temperaturzustands TES . Die Zustände POS und TES sind wiederum Unterklassen des Attribut-Zustands AS, der wiederum eine Unterklasse des Zustands ST ist. Der Zustand RunFast ist eine Unterklasse des Motorzustands MOS, der eine Unterklasse des Prozesszustands PS ist, der wiederum eine Unterklasse des Zustands ST ist.

Die in Fig. 6 dargestellte Regel sagt folgendes aus: „Falls ein Motor ml eine Aktivität ausführt, die der Aktivität

RunFast entspricht und der gemessene Wert der Eingangsleistung größer als 400 ist und ml ein Teil der Komponente der Arbeitszelle 1 mit der Identität wcl ist, welche derzeit in einem Zustand zu hoher Temperatur TempTooHigh ist, dann wird der Zustand des Motors ml auf PowTooHigh_RunFast_TempTooHigh gesetzt, was bedeutet, dass der Energieverbrauch und die Umgebungstemperatur des Motors während des Prozesses RunFast zu hoch sind.

In Folgenden wird beschrieben, wie mit dem in Fig. 1 gezeigten Reasoner REA Regeln aus der Ontologie 0N2 verifiziert werden können. Üblicherweise sind verschiedene Experten bei der Implementierung von Regeln über das System der Fig. 1 beteiligt. Diese Experten definieren Regeln, um individuelle überwachte Zustände von überwachten Elementen der Anlage zu spezifizieren. Während des Entwurfs der Regeln oder späterer Adaptionen können redundante, widersprüchliche oder inkonsis- tente Regeln auftreten. In dem System der Fig. 1 können solche Regeln mittels des Reasoners REA identifiziert werden. Beispielhaft wird eine Verifikation erläutert, gemäß der zwei widersprüchliche Regeln identifiziert werden. Zwei Regeln widersprechen sich, wenn sie zwei unterschiedliche Zustände ableiten, obwohl sie als Eingabe die gleichen Bedingungen ha- ben. Wenn bspw. eine Regel Rulel den Zustand TempTooHigh und eine Regel Rule2 den Zustand TempTooLow ableitet, obwohl sich beide Regeln auf die gleiche Bedingung beziehen, wird eine solche Inkonsistenz durch einen geeigneten OWL-DL Reasoner, wie z.B. Pellet, erkannt. Ein weiteres Beispiel einer Verifi- kationsaufgäbe ist die Identifikation von Regeln, welche nie ausgeführt werden können. Dies ist bspw. der Fall, wenn Regeln inverse überwachte Bedingungen verwenden. Dies trifft bspw. dann auf, wenn eine Regel die beiden Bedingungen „Temperatur von ml größer 20 °C" und „Temperatur von ml kleiner 20°C" enthält. Auch solche inverse Bedingungen innerhalb einer Regel werden über einen geeigneten Reasoner erkannt .

Der in Fig. 1 verwendete Reasoner REA kann ferner auch eine Klassifikation vornehmen. Dabei werden an sich bekannte Klas- sifikations-Mechanismen von OWL-Reasonern eingesetzt, um die Regeln RU sowie die überwachten Bedingungen CO in verschiedene Klassifikationshierarchien bzw. Taxonomien zu strukturieren. Mittels der Klassifikation können Regeln strukturiert werden, indem Subtypen von überwachten Bedingungen identifi- ziert werden. Allgemein kann eine Regel Rulel als ein Subtyp einer anderen Regel Rule2 klassifiziert werden, falls die Regel Rulel eine Teilmenge der Bedingungen CO der Regel Rule2 verwendet. Ein Beispiel einer Umsetzung dieser Klassifikationsaufgabe ist wie folgt: Falls die Regel Rulel aus Fig. 6 drei Bedingungen aufweist, während eine andere Regel Rule2 nur zwei dieser Bedingungen aufweist, wird die Regel Rulel als Subtyp der Regel Rule2 durch einen OWL-Reasoner klassifiziert. Gemäß der Klassifikations-Aufgabe können auch redundante Regeln identifiziert werden. Der Reasoner überprüft in diesem Fall, ob einige Regeln in der Regel -Ontologie äquivalente Bedingungen aufweisen und die gleichen Zustände folgern. Diese Regeln werden dann durch den Reasoner als äquivalent eingestuft. Wie aus Fig. 1 ersichtlich, können ferner Abfragen QUE durch einen Benutzer an die Ontologie ON2 gerichtet werden. In einer speziellen Ausführungsform werden dabei SPARQL-Abfragen verarbeitet. Zum Beispiel kann ein Benutzer den Wunsch haben, alle Motoren vom Typ M1FK7 in der Anlage durch neue Motoren vom Typ M1PH8 mit weniger Energieverbrauch zu ersetzen. Über eine entsprechende Abfrage in der Ontologie ON2 kann er dann alle Regeln identifizieren, die den Motor vom Typ M1FK7 ent- halten und sich auf den Leistungsverbrauch POS beziehen. Die in Fig. 6 gezeigte Taxonomie von Zuständen kann dabei innerhalb dieser Abfrage verwendet werden. Abfragen können ferner zur Filterung von Metainformationen sowie zur Datenanalyse benutzt werden.

Die in Fig. 1 gezeigte Wandlung der Wissensbasis KB bzw. Ontologie ON1 in ausführbare Regeln EXR kann als Workflow beschrieben werden. In dem Workflow wird sowohl die Anlagen- Ontologie PON als auch die Regel -Ontologie RON über Semantic Mediawiki definiert. Durch diese Ontologien wird die Wissensbasis KB gebildet, die dann in die Anlagen-spezifische OWL- Ontologie PSON mittels eines Exports gewandelt wird. Aus dieser Ontologie wird dann die Ontologie ON2 abgeleitet, die dann über den Reasoner validiert wird. Durch mehrfaches Edi- tieren der ursprünglichen Ontologie ON1 und ein Validieren der daraus abgeleiteten Ontologien ON2 wird schließlich eine konsistente Ontologie erstellt. Um diese zu nutzen, werden die Regeln in der Ontologie PSON auf das generische Format RIF abgebildet. Das heißt, die Regeln werden in die RIF-XML- Serialization-Syntax übersetzt. Die Übersetzung erfolgt dabei mittels XSLT mit einem geeigneten XSL-Stylesheet . Hieraus wird dann die RIF-XML-Serialization-Syntax gemäß der Abbildung erhalten, die in dem W3C RIF-Standard definiert ist. Zur Erzeugung der RIF-Regeln wird ein XSLT-Prozessor, wie z.B. Saxon, verwendet, der mit einem XSL-Stylesheet parametrisiert ist, welches die für die RIF-XML-Syntax spezifische XSLT- Übersetzung enthält. Das XSL-Stylesheet besteht aus einer Anzahl von XML-Templates, welche übereinstimmende XML-Struktu- ren identifizieren und geeignete RIF-spezifische Code-Fragmente spezifizieren, in welche die XML-Strukturen übersetzt werden . Die RIF-Regeln werden schließlich über XSLT in spezifische Regeln des Sprachformats einer Regel -Maschine RM gewandelt. Während der XSLT-Prozessierung werden dabei übereinstimmende XML-Strukturen ermittelt und in Regel -Code-Fragmente übersetzt. Schließlich werden über die entsprechende Regel-Ma- schine ausführbare Regeln erhalten. In einer speziellen Ausführungsform beruhen die ausführbaren Regeln dabei auf der Regel-Sprache Etalis.

Als Ergebnis des im Vorangegangenen beschriebenen Systems er- hält man schließlich geeignete ausführbare Regeln, die mit EXR in Fig. 1 bezeichnet sind. Im Rahmen des Betriebs der technischen Anlage, für welche die Regeln entworfen wurden, wird dann eine Regel -Maschine RM mit diesen Regeln in Betrieb genommen. Die Regel -Maschine verarbeitet dabei entsprechende Zustände der technischen Anlage, die z.B. über Sensoren er- fasst werden. Als Ergebnis erzeugt die Regel -Maschine dann überwachte Ereignisse und annotiert diese mit maschinenlesbarer Semantik. Die Ereignisse können entweder über eine

Schnittstelle einem Benutzter angezeigt werden oder durch weitere Modulen (z.B. ein Diagnose-Modul) verarbeitet werden.

Die im Vorangegangenen beschriebenen Ausführungsformen der Erfindung weisen eine Reihe von Vorteilen auf. Insbesondere wird ein einfaches und effizientes Erstellen von Regeln für eine technische Anlage über eine Benutzerschnittstelle erreicht, wobei die Regeln im Unterschied zum Stand der Technik auch als Ontologien dargestellt werden. Hierdurch wird es ermöglicht, dass über wissensbasiertes Reasoning bzw. Abfrage- Mechanismen die Regeln geeignet überprüft und insbesondere verifiziert und klassifiziert werden können. Das Überprüfungsergebnis kann dem Benutzer präsentiert werden, der daraufhin bei Inkonsistenzen in der Regelbasis Anpassungen an den erstellten Regeln vornehmen kann. Das erfindungsgemäße System ermöglicht ferner eine automatische Wandlung der Regeln aus der Ontologie in geeignete ausführbare Regeln einer Regel -Maschine , die anschließend einfach und effizient zur Überwachung bzw. Diagnose der technischen Anlage eingesetzt werden kann.