-
Die Erfindung betrifft ein Verfahren zur Überprüfung einer maschinenlesbaren Beschreibung eines Geräts in einer elektronischen Gerätebeschreibungssprache. Bei einer Geräteintegration wird häufig eine Beschreibung des Geräts in einer elektronischen Gerätebeschreibungssprache verwendet. Unter dem Begriff „Geräteintegration“ wird in der vorliegenden Anmeldung die Anbindung von Feldgeräten, beispielsweise Sensoren und Aktuatoren, und anderen Feldkomponenten, z. B. Remote I/O-Geräten, Multiplexern, Wartengeräten oder Kompaktreglern, in ein automatisiertes technisches System, z. B. ein Supervisory Control and Data Acquisition(SCADA)-System oder ein Prozessleitsystem (PLS), verstanden. Feldgeräte und Feldkomponenten werden häufig auch als prozessnahe Komponenten (PNK) bezeichnet.
-
Über den Anlagenlebenszyklus hinweg, der u. a. das Engineering, das Commissioning, die Inbetriebnahme und den Betrieb umfasst, verwenden die jeweiligen Anwender, Planer, Inbetriebnehmer, Betreiber usw., eine computergestützte Integrationsumgebung zur Unterstützung bei Aufgaben wie Projektierung, Wartung, Condition Monitoring und Asset Management.
-
Ein Feldgerät wird u. a. beschrieben durch Parameterdaten, Messeinheiten, Versions- und Produktinformationen für die verschiedenen, zuvor genannten Aufgaben. Außerdem werden dem Nutzer Gerätefunktionen z. B. für Eigendiagnose und Kalibrierung zur Verfügung gestellt. Die Integration dieser Informationen in die höheren Ebenen der Automatisierung, z. B. SCADA oder PLS, ist dennoch mit gewissen Schwierigkeiten verbunden.
-
Die Beschreibung der zu integrierenden Geräte basiert u. a. auf sog. Maschinenbeschreibungssprachen, wie der Electronic Device Description Language (EDDL), die in der IEC 61804-3 standardisiert ist und die wohl zukünftig verbreitet Einsatz finden wird. EDDL ist eine textbasierte Beschreibungssprache, die zur Beschreibung des Feldgeräts und seiner Funktionen dient. Die Beschreibung erfolgt nach syntaktischen und semantischen Vorgaben oder Regeln und ähnelt einfachen Programmiersprachen. Die damit in einer Datei oder mehreren Dateien erzeugte Beschreibung wird als Electronic Device Description(EDD)-Datei bezeichnet. Die Beschreibungen der Feldgeräte der unterschiedlichen Kommunikationsprotokolle, u. a. PROFIBUS, Highway Adressable Remote Transducer (HART), Foundation Fieldbus (FF), sind durch unterschiedliche Teile des EDD-Sprachraums, z. B. ARRAY, BLOCK, COLLECTION usw., vorgegeben. Da es sich um frei lesbaren Text handelt, können EDD prinzipiell mit beliebigen Texteditoren erstellt werden. Je nach Kommunikationsprotokoll werden jedoch zur Erstellung der Dateien dem jeweiligen Protokoll entsprechende, spezifische Editoren eingesetzt. Beispielsweise wird zur Erstellung einer Beschreibung eines HART-Feldgeräts ein Werkzeug der HCF für Design und Test verwendet, wobei eine Gerätebeschreibung im HART-EDD-Format entsteht, die in einem Steuerungssystem durch einen HART-Interpreter verarbeitet wird. In entsprechender Weise gibt es spezielle Werkzeuge der FF und der Profibus/Profinet International(PNO)-Community.
-
Ein Prozessleitsystem interpretiert die eingelesenen Dateien, um eine Verbindung zum Feldgerät herzustellen und um dem Anwender eine Visualisierung des Feldgeräts auf einem Bediengerät aufzubereiten. Der Entwickler einer EDD muss diese bisher auf syntaktische und semantische Fehler überwiegend manuell prüfen, da Fehler der EDD erst bei ihrer Verwendung im Interpreter des Prozessleitsystems sichtbar werden. Aufgrund der wachsenden Komplexität der Feldgeräte und ihrer Funktionen steigt die Vielfalt der durch den Gerätehersteller oder den EDD-Entwickler zu testenden Fälle. Ziel der Überprüfung ist die Vermeidung späterer Laufzeitfehler im Betrieb des Steuerungssystems. Zusätzlich ist dabei problematisch, dass es im Gegensatz zu gängigen Programmiersprachen bei der EDDL erlaubt ist, Objekte in einer Beschreibung zu verwenden, bevor sie im EDD-Sprachraum definiert sind. Hierbei die Übersicht zu bewahren und auf die Durchgängigkeit der Namensgebung zu achten, ist ebenfalls Aufgabe des Entwicklers.
-
Neben den verfügbaren Editoren zum Erstellen der EDD erhält der EDD-Entwickler rudimentär auch Unterstützung beim Test der EDD. Hierzu wird von der ifak systems GmbH ein Entwicklungswerkzeug angeboten, welches das Editieren von Dateien und Projekten ermöglicht. Weiterhin besitzt es ein Werkzeug zur Überprüfung der EDD, einen sogenannten EDD-Checker, welcher die EDD auf syntaktische und statische semantische Fehler, beispielsweise bezüglich der Auflösung von Referenzen und Typen, prüft. Außerdem verfügt es über eine Visualisierungsmöglichkeit der Gerätebeschreibung, die einen Onlinetest der beschriebenen Funktionalität und Parameter gegen die Geräteimplementierung erlaubt. Dabei beziehen sich alle Überprüfungen auf die jeweilige EDD-Spezifikation und das jeweils verwendete Profil.
-
In der Regel hängt das Ergebnis eines EDD-Checks von verschiedenen Ungenauigkeiten in den Definitionen, die in der Norm gegeben sind, ab. Diese führen beispielsweise dazu, dass weitere Quasiprofile entstehen Es ist daher zwingend erforderlich, dass eine erstellte EDD nicht nur durch den jeweiligen EDD-Entwickler getestet wird, sondern auch von dritter Stelle zertifiziert wird. Derartige Zertifizierungsstellen sind je nach Profil beispielsweise bei der HCF, der FF und PNO eingerichtet. Ein weiteres Problem besteht darin, dass das Werkzeug zum Editieren und Überprüfen einer EDD nur schwer an Norm- und Sprachänderungen anpassbar ist und ein Update durch den Hersteller des Werkzeugs erfordert. Dieser hält die Spezifikation der jeweiligen Norm und Sprache fest in seinem Programm verankert und ermöglicht keine nachträgliche Manipulation durch EDD-Entwickler. Es ist ebenfalls nicht möglich, mit dem Werkzeug eine EDD in einer anderen Beschreibungssprache, z. B. I/O Device Description (IODD) oder Machine Device Description (MDD), zu überprüfen. Zudem ist es nicht ohne größeren Aufwand möglich, zusätzliche Regeln zur Überprüfung einer EDD, z. B. im Fall der Verwendung von Quasiprofilen, in dem bekannten Werkzeug zu hinterlegen, da die bisherigen Regeln im Sourcecode des Werkzeugs verwoben sind, wobei dieses Wissen und das allgemeine Problemlösungswissen in den Algorithmen und Datenstrukturen vermengt ist. Bei Änderungen muss daher der Programmcode modifiziert werden. Dies ist insbesondere bei älteren Programmcodes mit großen Schwierigkeiten verbunden, was sich wiederum nachteilig auf die Wartbarkeit des Werkzeugs auswirkt. Das anwendungsbezogene Wissen kann somit nur durch Programmierer des Werkzeugs in dieses eingebracht werden. Die Folgen sind also aufwendige Programmierarbeiten, wenn Profiländerungen oder Ergänzungen in das Programm, mit welchem das Werkzeug realisiert ist, eingebracht werden müssen.
-
Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zur Überprüfung einer maschinenlesbaren Beschreibung eines Geräts in einer elektronischen Gerätebeschreibungssprache zu schaffen, das bei Änderungen der Beschreibungssprache einfacher anpassbar ist. Eine weitere Aufgabe ist, ein Computerprogramm zu schaffen, welches bei seiner Ausführung das Verfahren zur Überprüfung einer maschinenlesbaren Beschreibung durchführt.
-
Zur Lösung dieser Aufgabe werden bei dem neuen Verfahren zur Überprüfung einer maschinenlesbaren Beschreibung eines Geräts, die in einer elektronischen Gerätebeschreibungssprache vorliegt, die in Anspruch 1 angegebenen Schritte ausgeführt. In den weiteren Ansprüchen sind vorteilhafte Weiterbildungen bzw. ein Computerprogramm zur Ausführung des Verfahrens beschrieben.
-
Die Erfindung hat den Vorteil, dass mit der Trennung von Wissensbasis und Wissensverarbeitung ein wissensbasiertes System geschaffen wird, das gegenüber „konventionellen“ Programmen deutliche Vorteile besitzt. In der Wissensbasis wird eine explizite Darstellung von Fachwissen über eine Gerätebeschreibungssprache, z. B. EDDL nach IEC 61804-3, ermöglicht. Außerdem wird durch die Verwendung eines wissensbasierten Systems die Widerverwendbarkeit des in der Wissensbasis formulierten Wissens für weitere Anwendungen unterstützt. Das Wissen kann beispielsweise zu Schulungszwecken in Unternehmen, z. B. zur Erstellung eines Gerätepakets, eingesetzt werden. Dadurch werden die bisher langen Einarbeitungszeiten neuer Mitarbeiter und die damit verbundenen Kosten reduziert.
-
Zudem sehen sich heute Unternehmen häufig damit konfrontiert, dass ältere Mitarbeiter aufgrund des demographischen Wandels das Unternehmen verlassen und somit wichtige Wissensträger verloren gehen. Deren Wissen über Gerätebeschreibungen einheitlich in der Wissensbasis eines wissensbasierten Systems zu formulieren stellt in vorteilhafter Weise eine Möglichkeit dar, das Wissen zu erhalten. Dieser Vorteil ist auch insbesondere vor dem Hintergrund von Bedeutung, dass frei gewordene Stellen aufgrund des Fachkräfte- und Ingenieurmangels kaum adäquat neu zu besetzen sind.
-
Ein weiterer Vorteil des neuen Verfahrens ist die domänenübergreifende Wiederverwendbarkeit der Komponente zur Wissensverarbeitung, da diese nicht an das jeweils in der Wissensbasis hinterlegte Wissen angepasst werden muss.
-
Ein weiterer wesentlicher Vorteil der Trennung von Wissensbasis und Wissensverarbeitung ist darin zu sehen, dass Änderungen oder Erweiterungen der Wissensbasis ohne weiteres vorgenommen werden können und keine aufwendigen Programmierarbeiten mehr notwendig machen.
-
Wegen der verbesserten Wartungsmöglichkeit, die in eine häufigere und umfangreichere Wartung der Wissensbasis mündet, wird schließlich die Zuverlässigkeit der Prüfungsergebnisse und damit die Qualität der erstellten Gerätebeschreibung erheblich verbessert. Ein Anwender des Verfahrens erhält damit wertvolle Unterstützung bei der Erstellung einer maschinenlesbaren Beschreibung und der Geräteintegration.
-
Anhand der Zeichnung, in der ein Ausführungsbeispiel der Erfindung dargestellt ist, werden im Folgenden Ausgestaltungen und Vorteile der Erfindung näher erläutert.
-
Die Figur zeigt ein Strukturbild mit einem wissensbasierten System 1, das zur Überprüfung einer maschinenlesbaren Beschreibung 2 in einer elektronischen Gerätebeschreibungssprache dient. Im Folgenden werden die Beschreibungen als EDD und die Beschreibungssprache als EDDL bezeichnet. Das wissensbasierte System (WBS) 1 sieht eine Trennung von Wissen, welches in einer Wissensbasis 3 hinterlegt ist, und einer Komponente 4 zur Wissensverarbeitung vor. Während in der Wissensbasis 3 spezielles Wissen über den Anwendungsbereich, z. B. das Expertenwissen zur Prüfung von Quasiprofilen und EDD, zu finden ist, stellt die Komponente 4 als Wissensverarbeitungskomponente eine anwendungsunabhängige Komponente zur Problemlösung dar.
-
Das in der Wissensbasis 3 hinterlegte Wissen kann nach Herkunft und Gebrauch unterschieden werden. Dabei wird zwischen bereichsbezogenem Wissen 5 und fallspezifischem Wissen 6 unterschieden.
-
Bereichsbezogenes Wissen 5, welches auch als Expertenwissen bezeichnet wird, dient dazu, Wissen über einen ausgrenzbaren Teil der Realität darzustellen. Dieses beschriebene Wissen ist allgemeingültig für einen bestimmten, abgegrenzten Anwendungs- bzw. Problembereich wie beispielsweise für die Prüfung einer EDD. Im Fall der EDDL ist dieses Wissen beispielsweise in der Norm IEC 61804-3 spezifiziert. Diese gibt klar den Namensraum und die Syntax einer EDD vor.
-
Fallspezifisches Wissen 6 dient der Darstellung gültiger Sachverhalte in einem speziellen Fall. Dieses Wissen bezieht sich im Gegensatz zum bereichsspezifischen Wissen 5 auf einen konkreten Anwendungsfall aus dem Problembereich. Es liegt beispielsweise aufgrund von bereits bestehenden oder gerade erstellten EDDs vor und kann als eine Instanziierung betrachtet werden. Fallspezifisches Wissen 6 ist in diesem Fall beispielsweise das Wissen über ein spezielles Feldgerät.
-
Das vorhandene Wissen kann je nach Gebrauch in Klassenwissen 7, Faktenwissen 8 und Regelwissen 9 unterschieden werden.
-
Das WBS 1 für das Engineering automatisierter technischer Systeme ermöglicht die Beschreibung von sogenanntem Klassenwissen 7 zur Beschreibung von terminologischem Wissen in der Wissensbasis 3. Anhand des Klassenwissens 7 können konkrete Aussagen über ggf. existierende Artefakte und ihrer Zusammenhänge in der realen Welt getroffen werden, z. B. welche Artefakte und Zusammenhänge zwischen diesen Artefakten können existieren. Dabei wird alles in jeweils einer abgegrenzten Domäne und der speziellen Anwendung, z. B. Überprüfung einer EDD, betrachtet.
-
Das Faktenwissen 8, bei welchem es sich um deklaratives Wissen handelt, wird auch als assertionales Wissen bezeichnet und ist im Kontext des WBS 1 dem fallspezifischen Wissen 6 zuzuordnen. Anhand des Faktenwissens 8 können konkrete Aussagen über die Existenz der beschriebenen Artefakte und ihrer Zusammenhänge in der realen Welt getroffen werden, z. B. welche Artefakte und Zusammenhänge zwischen diesen Artefakten existieren in der jeweils abgegrenzten Domäne und der speziellen Anwendung, hier einer Überprüfung einer EDD. Typisches Faktenwissen 8 bei einem EDD-Check ist beispielsweise die notwendige Existenz des MANUFACTURER-Attributes, welches mittels einer Zahl den Hersteller der EDD codiert und durch eine Spezifikation definiert wird.
-
Unter Regelwissen 9 versteht man prozedurales Wissen, das sich auf die Kenntnis von Prozeduren zur Problemlösung bezieht. Mit dem Regelwissen 9 lässt sich prüfen ob ein EDDL-Konstrukt richtig ist und die Syntax eingehalten wird. Zum Beispiel muss ein Item xy vom Typ VARIABLE ein Attribut TYPE haben. Gleichzeitig lässt sich daraus eine Regel für den EDD-Check ableiten, die besagt: Wenn VARIABLE und kein Attribut TYPE, dann Fehler. Außerdem wird durch das Regelwissen 9 ermöglicht, Regeln abzubilden, welche die Semantik prüfen. Wenn zum Beispiel ein Item zz durch ein Item UNIT referenziert wird, muss es vom Typ VARIABLE sein. Wenn zz ein Item vom Typ MENU ist, liegt dagegen ein Fehler vor.
-
In der Wissensbasis 3 sind Wissensmodelle zur Beschreibung des Regelwissens 9, Faktenwissens 8 und Klassenwissens 7 eindeutig festgelegt. Die klassische Logik bildet die Basis, auf der Regeln und Ontologien aufbauen. Das Klassenwissen 7 wird auf der terminologischen Ebene von Ontologien abgebildet und das Faktenwissen 8 auf der assertionalen Ebene von Ontologien. Mithilfe von Regeln wird das Regelwissen 9 im Kontext des WBS 1 beschrieben.
-
Die Komponente 4 besteht aus einem Interviewermodul 10, einem Erklärungsmodul 11, einem Wissenserwerbsmodul 12, einem Inferenzmodul 13, einem Steuerungsmodul 14 und einem Schnittstellenmodul 15.
-
Das Interviewermodul 10 dient der manuellen Eingabe von fallspezifischem Wissen 6, insbesondere Faktenwissen 8, durch den EDD-Entwickler. Dazu führt das Interviewermodul 10 einen Dialog mit dem Entwickler, weshalb es auch als Dialogmodul bezeichnet werden kann.
-
Das Erklärungsmodul 11 dient dem EDD-Entwickler nachzuvollziehen, wie neues Wissen, z. B. ein Prüfungsergebnis, ermittelt wurde. Das Erklärungsmodul 11 unterstützt somit den EDD-Entwickler, die Prüfungsergebnisse zu interpretieren. Weiterhin hilft das Erklärungsmodul 11 sowohl dem Entwickler, der z. B. die Ergebnisse im Rahmen seiner Problemlösung benötigt, als auch dem Experten, welcher das Wissen in die Wissensbasis 3 einpflegt und wartet, Inkonsistenzen sowie Redundanzen zu identifizieren und Wissenslücken zur Prüfung zu lokalisieren.
-
Das Wissenserwerbsmodul 12 ermöglicht es dem EDD-Entwickler, manuell bereichsbezogenes Wissen 5, insbesondere Klassenwissen 7 und Regelwissen 9, in das WBS 1 einzupflegen und zu warten. Es erlaubt, manuell Wissen in die Wissensbasis 3 des WBS 1 einzuschreiben. Um automatisiert Wissen aus dem Engineeringprozess der verschiedenen Domänen und Anwendungen in der Wissensbasis 3 des WBS 1 für das Engineering automatisierter technischer Systeme abzubilden, ist das Schnittstellenmodul 15 vorgesehen. Dieses ermöglicht das automatisierte Einlesen und Ausgeben von Klassenwissen 7, Faktenwissen 8 und Regelwissen 9 mithilfe einer definierten E/A-Schnittstelle.
-
Als ein weiteres Modul der Komponente 4 zur Wissensverarbeitung im Kontext des WBS 1 koordiniert das Steuerungsmodul 14 das Zusammenwirken des Inferenzmoduls 13, Interviewermoduls 10, Erklärungsmoduls 11 und Schnittstellenmoduls 15. Im Rahmen dieser Koordination initiiert das Steuerungsmodul 14 die jeweiligen Prozesse der einzelnen Module und steuert den Wissensfluss zwischen diesen.
-
Die Aufgabe des Inferenzmoduls 13 besteht darin, das Regelwissen 9 auf das Faktenwissen 8 anzuwenden. Dieser Vorgang kann als „Feuern“ von Regeln bezeichnet werden. Als Ergebnis inferenziert das Modul 13 so ggf. neues Wissen oder initiiert eine Handlung.
-
In der technischen Realisierung des WBS 1 ermöglichen Beschreibungsmittel Web Ontology Language (OWL), Semantic Web Rule Language (SWRL), Semantic Query Web Rule Language (SQWRL) und Rule Interchange Format (RIF) sowie z. B. die Werkzeuge Jess und Protégé die stringente Einhaltung des beschriebenen modularen Konzeptes des WBS 1. Dabei erlaubt OWL die getrennte Beschreibung von Klassenwissen 7 und Faktenwissen 8, SWRL und SQWRL die Beschreibung von Regelwissen 9 in der Wissensbasis 3. Ein Beispiel einer Regel in der Sprache SWRL lautet:
(Item (?y) ^! Type(?y, ?x)) ⇒ (?x, merke =”Fehler”)
-
RIF ermöglicht den Austausch von Regelwissen 9, das zur Überprüfung der EDD dient, und EDD dient dem Austausch von Klassenwissen 7 und Faktenwissen 8. Der jeweilige Austausch erfolgt mithilfe des Schnittstellenmoduls 15 der Komponente 4. Die Trennung von Inferenzmodul 13 und Steuerungsmodul 14 ermöglicht die Verwendung des Inferenzsystems Jess aus dem Kontext des Semantic Web als Inferenzmodul 13 in Kombination mit einer gezielten Steuerung durch das Steuerungsmodul 14. Das Werkzeug Protégé wird als Wissenserwerbsmodul 12 verwendet.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- IEC 61804-3 [0004]
- IEC 61804-3 [0010]
- IEC 61804-3 [0018]
