-
Die
Erfindung betrifft ein Verfahren zum Testen von Gerätebeschreibungen
für Feldgeräte der Automatisierungstechnik
gemäß dem Oberbegriff des
Anspruchs 1 In der Automatisierungstechnik (Prozessautomatisierung/Fabrikautomatisierung) werden
vielfach Feldgeräte
eingesetzt, die zur Erfassung und/oder Beeinflussung von Prozessvariablen dienen.
Beispiele für
derartige Feldgeräte
sind Füllstandsmessgeräte, Massendurchflussmessgeräte, Druck-
und Temperaturmessgeräte,
pH- und Redoxpotential-Messgeräte,
Leitfähigkeitsmessgeräte etc. für die Prozessautomatisierungstechnik,
die als Sensoren die entsprechenden Prozessvariablen Füllstand,
Durchfluss, Druck, Temperatur, pH-Wert bzw. Leitfähigkeitswert
erfassen.
-
Zur
Beeinflussung von Prozessvariablen dienen Aktoren, z. B. Ventile,
die den Durchfluss einer Flüssigkeit
in einem Rohrleitungsabschnitt steuern oder Pumpen, die den Füllstand
in einem Behälter verändern.
-
Eine
Vielzahl solcher Feldgeräte
wird von der Firma Endress + Hauser® hergestellt
und vertrieben.
-
Häufig sind
Feldgeräte über Kommunikationssysteme
(Profibus®,
Foundation®-Fieldbus, HART® etc.)
mit übergeordneten
Einheiten verbunden. Diese übergeordneten
Einheiten dienen zur Prozesssteuerung, Prozessvisualisierung, zum
Gerätemanagement
(Konfigurieren und Bedienen) und zum Anlagenmanagement (Asset-Management)
mit entsprechenden Anwendungsprogrammen.
-
Die
Integration von Feldgeräten
in solche Anwendungen erfolgt über
Gerätebeschreibungen.
Diese Gerätebeschreibungen
werden von den Geräteherstellern
bereitgestellt, damit die übergeordneten Einheiten
die Bedeutung der von den Feldgeräten gelieferten Daten erkennen
und interpretieren können.
-
Es
sind verschiedene Gerätebeschreibungen
für die
unterschiedlichen Feldbussysteme bekannt (HART-Gerätebeschreibungen,
Fieldbus Foundation Gerätebeschreibungen,
Profibus-Gerätebeschreibungen).
-
In
Zusammenarbeit der Fieldbus Foundation (FF), der HART Communication
Foundation (HCF) und der Profibus Nutzerorganisation (PNO) wurde eine
elektronische Gerätebeschreibung
(Electronic Device Description EDD) geschaffen, die in der Norm IEC
61804-2 definiert ist.
-
Zur
Bedienung der Feldgeräte
sind entsprechende Bedienprogramme (Bedientools) notwendig, die
auf den übergeordneten
Einheiten entweder eigenständig
ablaufen (Endress + Hauser FieldCare, Pactware, AMS Fisher-Rosemount,
PDM Siemens) oder aber auch in Leitsystem-Anwendungen (Siemens PCS7,
ABB Symphony, Emerson Delta integriert sind.
-
Für eine vollumfängliche
Bedienung der Feldgeräte
sind seit kurzem spezielle Gerätebeschreibungen,
so genannte DTMs (Device Type Manager), die den FDT (Field Device
Tool) Spezifikationen entsprechen, erhältlich. Die als Industriestandard
geltenden FDT-Spezifikationen wurden von der PNO (Profibus Nutzer
Organisation) in Zusammenarbeit mit dem ZVEI (Zentralverband Elektrotechnik- und
Elektroindustrie) entwickelt. Die aktuelle FDT-Spezifikation 1.2.1
inklusive dem Addendum für die
Kommunikation „Foundation
Fieldbus" ist über den
ZVEI bzw. die PNO bzw. die FDT-Group erhältlich.
-
Viele
Feldgerätehersteller
liefern bereits für ihre
Feldgeräte
entsprechende DTMs aus. Die DTMs kapseln alle Variablen und Funktionen
des jeweiligen Feldgeräts
und bieten meist eine graphische Nutzeroberfläche zum Bedienen der Geräte an.
-
Als
Laufzeitumgebung benötigen
die DTMs eine Rahmenapplikation (FDT-Frame). Die Rahmenapplikation
und die entsprechenden DTMs erlauben so einen sehr komfortablen
Zugriff auf Feldgeräte
(z. B. Geräteparameter,
Messwerte, Diagnoseinformationen, Statusinformationen, etc.) sowie
den Aufruf von speziellen Funktionen, die einzelnen DTMs zur Verfügung stellen.
-
Da
Feldgeräte über DTMs
bedient werden, sind umfangreiche Funktionstests notwendig, um zu gewährleisten,
dass die DTMs in beliebigen Rahmenapplikationen einwandfrei arbeiten.
Diese Funktionstests haben auch einen Sicherheitsaspekt, da insbesondere
sicherheitskritische Einstellungen an Feldgeräten über DTMs vorgenommen werden
können.
-
Eine
Möglichkeit
DTMs zu testen, bietet das Testwerkzeug dtmINSPECTOR (M&M Software GmbH,
St. Georgen). Hierbei werden umfangreiche Testscripts erstellt,
die zusammen mit dem zu testenden DTM ausgeführt werden. Im Wesentlichen
wird bei diesen Tests überprüft, ob der
DTM den FDT-Spezifikationen (FDT Schnittstellendefinitionen) entspricht.
Mit diesem Testwerkzeug wird im Prinzip nur geprüft, ob die Schnittstelle logisch
einwandfrei arbeitet. Auch bei einem erfolgreich absolvierten Test mit
Hilfe dieses Testwerkzeugs ist jedoch nicht sichergestellt, dass
der DTM in allen Rahmenapplikationen einwandfrei funktioniert, da
die Reihenfolge der Schnittstellenaufrufe von Rahmenapplikation
zu Rahmenapplikation verschieden sein kann, was unterschiedliche
Abläufe
zur Folge haben kann.
-
Es
ist deshalb notwendig, DTMs auch in unterschiedlichen Rahmenapplikationen
zu testen und dabei zu prüfen,
ob sich DTM und Rahmenapplikation jeweils korrekt im Sinne der Spezifikation
verhalten.
-
Die
Anmelderin (Codewrights GmbH Karlsruhe) erstellt aus herkömmlichen
Gerätebeschreibungsdateien
(HART, FF oder Profibus) mit Hilfe eines entsprechenden Werkzeugs
(DTMstudio) gerätespezifische
DTMs in großer
Stückzahl.
Die einwandfreie Funktion jedes einzelnen DTMs in verschiedenen
Rahmenapplikationen zu testen, würde einen
erheblichen Testaufwand bedeuten. Aber selbst durch umfangreiche
Tests können
Fehler nicht mit Sicherheit aufgedeckt werden.
-
Zudem
besteht das Problem, dass im Fehlerfall zunächst nicht klar ist, welche
Komponente (DTM oder Rahmenapplikation) den Fehler verursacht. Aufgrund
der sehr komplexen Interaktion zwischen den einzelnen Komponenten
ist die Fehleranalyse oft sehr aufwändig und zeitintensiv, was
unvermeidlich mit erheblichen Kosten verbunden ist.
-
Aufgabe
der Erfindung ist es deshalb, ein Verfahren zum Testen von Gerätebeschreibungen
für Feldgeräte der Automatisierungstechnik
anzugeben, das die oben genannten Nachteile nicht aufweist, das insbesondere
einen geringen Testaufwand erfordert.
-
Gelöst wird
diese Aufgabe durch die im Anspruch 1 angegebenen Merkmale.
-
Vorteilhafte
Weiterentwicklungen der Erfindung sind in den Unteransprüchen angegeben.
-
Die
wesentliche Idee der Erfindung besteht darin, zwischen Rahmenapplikation
und Gerätebeschreibung
eine Prüfkomponente
vorzusehen, die transparent für
die Kommunikation zwischen Rahmenapplikation und Gerätebeschreibung
ist und die die Schnittstellenaufrufe auf Konformität mit der
Spezifikation prüft.
-
Dabei
werden sowohl die Gerätebeschreibung
(DTM) als auch die Rahmenapplikation auf Konformität geprüft.
-
In
einer Weiterentwicklung der Erfindung wird geprüft, ob die Schnittstellenaufrufe
nach der Spezifikation erlaubt sind. Außerdem wird geprüft, ob die
bei einem Schnittstellenaufruf übergebenen
Daten der Spezifikation entsprechen.
-
Häufig sind
in Schnittstellenspezifikationen auch für gewisse Aufgaben (z. B. Speichern
auf Anforderung der Rahmenapplikation) Sequenzen von Schnittstellenaufrufen
vorgeschrieben. Deshalb wird in einer Weiterentwicklung der Erfindung
auch geprüft,
ob Sequenzen von Schnittstellenaufrufen den Spezifikationen entsprechen.
-
In
vorteilhafter Weise wird die Prüfkomponente
mit Hilfe von Zustandsautomaten beschrieben, welche die dynamische
Abläufe,
die im Rahmen der Spezifikation möglich sind darstellen.
-
Das
erfindungsgemäße Verfahren
eignet sich besonders für
Gerätebeschreibungen,
die als DTMs den FDT-Spezifikationen entsprechen.
-
Nachfolgend
ist die Erfindung anhand eines in der Zeichnung dargestellten Ausführungsbeispiels näher erläutert.
-
Es
zeigt:
-
1 Grundstruktur
einer Rahmenapplikation und mehreren Gerätemanagern nach dem FDT-Konzept,
-
In 1 ist
die Grundstruktur des FDT-Konzepts schematisch dargestellt. Eine
Rahmenapplikation R, die auf einer Rechnereinheit RE abläuft, kommuniziert über definierte
FDT-Schnittstellen FDT mit Gerätemanager-Instanzen
DTM1, DTM2 die eine vollumfängliche
Bedienung des dem jeweiligen Gerätemanager
zugeordneten Feldgerätetyps
ermöglichen
und der Kommunikationsmanager-Instanz DTMC, der eine vollumfängliche
Bedienung der Schnittstelle ermöglicht.
Bei der Rahmenapplikation R kann es sich zum Beispiel um das Produkt
FieldCare® der
Firma Endress + Hauser handeln. Die Rahmenapplikation R dient unter
anderem zur Verwaltung und Instanziierung verschiedener Objekten,
dabei ist die Rahmenapplikation verantwortlich für den Aufbau der Projektstruktur,
den Aufbau der Verbindungen zwischen den Geräte- und Kommunikationsmanagern-Instanzen,
das Starten und Verwalten von Anwendungen, das Speichern und Laden
der Projektdaten sowie das Erzeugen und Zerstören von Projekten.
-
Zur
Verwaltung der Projektstruktur bietet jeder Gerätemanager und Kommunikationsmanager Information über seine
Informationsschnittstelle an.
-
Anhand
dieser Informationen kann die Rahmenapplikation R Katalogdaten K
aufbauen, die für die
Verwaltung der Projektstruktur benötigt werden.
-
Mit
der Projektstruktur steuert und verwaltet die Rahmenapplikation
auch die Kommunikationswege. In 1 sind zwei
Kommunikationsnetzwerke (z. B. Feldbusse) dargestellt, die über Kommunikationsschnittstellen
KS1, KS2 angesprochen werden. Die Gerätemanager-Instanzen kommunizieren
mit den Feldgeräten
nicht direkt, sondern nutzen die Kommunikations-Schnittstelle von
FDT, die sowohl von der Rahmenapplikation R als auch von einer Kommunikationsmanager-Instanz
angeboten werden können. In 1 kommuniziert die
Gerätemanager-Instanz DTM1, über eine
Kommunikations-Schnittstelle KS1 an der Rahmenapplikation R mit
dem im zugeordneten Feldgerät
F1, während
die Gerätemanager-Instanz
DTM2 mit Hilfe der Kommunikationsmanager-Instanz DTMC über eine
Kommunikationsschnittstelle KS2 mit dem Feldgerät F2 kommuniziert.
-
Die
Rahmenapplikation R verwaltet sowohl Anwendungen, welche Teil der
Rahmenapplikation sind, als auch die Gerätemanager- und Kommunikationsmanager-spezifischen
Anwendungen. Interne Anwendungen der Rahmenapplikation R, wie Diagnoseverfahren
und Datenerfassungen, nutzen die FDT-Schnittstellen um Daten mit
den Geräte-
und Kommunikationsmanager-Instanzen
auszutauschen. Gerätemanager-
und Kommunikationsmanager-spezifische
Anwendungen verwaltet die Rahmenapplikation mittels Nutzung einer
Applikations-Schnittstelle. Die Rahmenapplikation erfragt hierzu
Art und Anzahl der verfügbaren
Anwendungen über
eine Informations-Schnittstelle.
-
Die
Persistenz der Projektdaten realisiert die Rahmenapplikation R mit
Hilfe einer Persistenzschnittstelle, die von Geräte- und Kommunikationsmanager-Instanzen
bedient werden.
-
Die
Rahmenapplikation R bildet zusammen mit den Gerätemanager-Instanzen DTM1, DTM2
und der Kommunikationsmanager-Instanz DTMC etc. z. Bsp. objektbasiertes
Konfigurationssystem KS für Feldgeräte der Automatisierungstechnik.
Wie bereits erwähnt,
stellen die Feldgerätehersteller
Gerätemanager
für ihre
einzelnen Feldgeräte
zur Verfügung. Bevor
auf ein Feldgerät
zugegriffen werden kann, muss der entsprechende Gerätemanager,
mit allen zugehörigen
Objekten instanziiert werden.
-
Erfindungsgemäß ist zwischen
der Rahmenapplikation R und den DTMs eine Prüfkomponente P vorgesehen, die
transparent für
die Kommunikation über
die FDT-Schnittstelle
zwischen Rahmenapplikation und dem jeweiligen DTM ist und die die
Schnittstellenaufrufe überprüft.
-
So
wird mit Hilfe der Prüfkomponente
P überprüft, ob die
Schnittstellenaufrufe nach den FDT-Spezifikationen überhaupt
erlaubt sind.
-
Weiterhin
kann mit der Prüfkomponente
P überprüft werden,
ob die beim Schnittstellenaufruf übergebenen Daten den FDT-Spezifikationen
entsprechen.
-
Mit
der Prüfkomponente
P ist es auch möglich
Sequenzen von Schnittstellenaufrufen auf Konformität mit den
FDT-Spezifikationen zu prüfen.
-
Aus
den Spezifikationen und den erlaubten Abläufen an den Schnittstellen
wird ein als formales Modell, ein Zustandsautomat, generiert, auf
dem die Prüfkomponente
im Wesentlichen basiert.
-
Mit
der vorliegenden Erfindung ist es möglich, das korrekte Zusammenspiel
zwischen einer Gerätebeschreibung
DTM und einer Rahmenapplikation R zu prüfen. Dies kann ohne zusätzlichen
Aufwand während
der üblicherweise
durchzuführenden Integrationstests
erfolgen. Nicht Spezifikations-konformes Verhalten einer der beiden
Komponenten wird sofort erkannt, auch dann, wenn dies nicht unmittelbar
zu einem Fehlverhalten des Gesamtsystems führt.
-
In
einer Weiterentwicklung der Erfindung ist es auch möglich, alle
Komponenten eines komplexeren Systems mit mehreren DTMs (Kommunikations-, Gateway-
und Geräte-DTMs)
zu prüfen.
-
Die
Erfindung prüft
nicht nur die logische Funktion der DTM Schnittstellen sondern das
tatsächliche
korrekte Zusammenspiel von Rahmenapplikation und DTM.