-
Die
Erfindung betrifft ein Verfahren zum Betreiben eines objektbasierten
Konfigurationsystems 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.
-
Mit
einer Vielzahl von weltweit installierten EDD-basierten Feldbussystemen
(FF, HART, Profibus) ist EDD eine sehr weit verbreitete Beschreibungssprache
für Gerätebeschreibungen
in der Automatisierungstechnik.
-
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 V) 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.
-
Die
DTMs können
auch als Geräteobjekte bezeichnet
werden, die zusammen mit der Rahmenapplikation ein objektorientiertes
Konfigurationssystem für
Feldgerät
der Automatisierungstechnik darstellen.
-
Um
die Verwaltung der Geräteobjekte
auf den übergeordneten
Einheiten möglichste
einfach zu halten, liefern die Feldgerätehersteller nicht für jedes Feldgerät einen
separaten DTM, sondern stellen ein Hautobjekt zur Verfügung, das
eine Vielzahl von Geräteobjekten
für einzelne
Feldgrätetypen
dieses Herstellers umfasst.
-
Tritt
ein Fehlverhalten bei der Bedienung eines Feldgerätes auf,
so muss das entsprechende Geräteobjekt
aktualisiert werden. Eine Aktualisierung ist auch dann notwendig,
wenn das Gerät
neue Funktionalitäten
erhält,
auf die über
das bisher vorhandene Geräteobjekt
nicht zugegriffen werden konnte.
-
Problematisch
ist die Einbindung von aktualisierten Geräteobjekten in objektorientierte
Konfigurationssysteme bei der Verwendung von Hautobjekten.
-
Eine
Möglichkeit
besteht darin, ein aktualisiertes Geräteobjekt zu erzeugen und auch
ein entsprechend aktualisiertes Hauptobjekt zu erstellen. Dies bedeutet
aber einen erheblichen Testaufwand, da nicht nur das aktualisierte
Geräteobjekt
getestet werden muss, sondern auch alle weiteren Geräteobjekte
des betreffenden Hauptobjekts.
-
Eine
andere Möglichkeit
besteht darin, speziell für
das aktualisierte Geräteobjekt
ein aktualisiertes Hauptobjekt zu generieren und das nicht aktualisierte
Geräteobjekt
aus dem ursprünglichen
Hauptobjekt zu entfernen. Es entsteht neben den ursprünglichen
Geräteobjekten
ein völlig
unabhängiges
Geräteobjekt.
Dadurch ändert
sich aber die modulare Struktur des Konfigurationssystems und der
Anwender muss erhebliche Anpassungen an seinem System vornehmen.
-
Beide
Alternativen bedeuten für
den Betrieb eines objektbasierten Konfigurationssystem bei der Aktualisierung
von Geräteobjekten
einen erheblichen Aufwand entweder auf der Seite des Geräteherstellers
oder des Anwender.
-
Aufgabe
der Erfindung ist es deshalb ein Verfahren zum Betreiben eines objektbasierten
Kommunikationssystems für
Feldgeräte
der Automatisierungstechnik anzugeben, das die oben genannten Nachteile
nicht aufweist, das insbesondere eine einfache Integration von aktualisierten
Geräteobjekten ermöglicht.
-
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, zwei Hauptobjekte
vorzusehen, wobei ein Hauptobjekt für die Integration von aktualisierten
Geräteobjekten
zuständig
ist und zwischen den Hauptobjekten und einer für den Ablauf der Hauptobjekte notwendigen
Rahmenapplikation eine Zwischenschicht einzufügen, über die bestehende und aktualisierte
Geräteobjekte
ausgewählt
werden können.
-
Dadurch
können
aktualisierte Geräteobjekte einfach
in Konfigurationssysteme integriert werden, ohne dass für den Gerätehersteller
ein größerer Testaufwand
und für
den Anwender keine größeren Anpassungen
erfordert, weil die modulare Struktur des Systems beibehalten wurde.
-
Nachfolgend
ist die Erfindung anhand eines Ausführungsbeispiels näher erläutert.
-
Es
zeigen:
-
1 Grundstruktur
eines objektorientierten Konfigurationssystems mit einer Rahmenapplikation und
mehreren Gerätemanagern
nach dem FDT-Konzept,
-
2a Rahmenapplikation
mit mehreren instanziierten Gerätemanagern,
die von einem Hauptobjekt abgeleitet sind.
-
2b Rahmenapplikation
mit zwei instanziierten Gerätemanagern,
die von einem aktualisierten Hauptobjekt abgeleitet sind, wobei
eines der Geräteobjekte
ein aktualisiertes Geräteobjekt
ist,
-
2c Rahmenapplikation
mit zwei instanziierten Gerätemanagern,
die von verschiedenen Hauptobjekten abgeleitet sind, wobei ein Geräteobjekt
aktualisiert ist,
-
3a Rahmenapplikation
mit zwei instanziierten Gerätemanagern
gemäß der vorliegenden
Erfindung.
-
3b Rahmenapplikation
mit zwei instanziierten Gerätemanagern
gemäß der vorliegenden Erfindung,
wobei ein Geräteobjekt
aktualisiert ist.
-
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
Field Care® 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. ein 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.
-
In 2a ist
die Rahmenapplikation R mit zwei instanziierten Gerätemanagern
A und B schematisch dargestellt. Jedem Gerätemanager ist genau einem Feldgerätetyp zugeordnet.
Die Instanziierung der Gerätemanager
erfolgt durch Interaktion zwischen Rahmenapplikation R und Anwender.
Möchte der
Anwender ein bestimmtes Feldgerät
in sein Projekt einbinden, so ruft er über die Rahmenapplikation R
aus, eine Liste mit allen in einem Gerätekatalog K verzeichneten Feldgerätetypen
auf. Aus dieser Liste kann er einen bestimmten Feldgerätetyp (z.
B. Deltabar S, Fa. Endress + Hauser) auswählen.
-
Mit
Hilfe einer entsprechenden Kennung Kn (Deltabar S), die von der
Rahmenapplikation R an ein Hauptobjekt HO weitergegeben wird, instanziiert
das Hauptobjekt HO das entsprechende Geräteobjekt. Hierzu weist das.
Hauptobjekt HO einen Factory-Mechanismus auf.
-
Das
Hauptobjekt HO stellt einen Objektsatz OS mit einer Vielzahl von
Geräteobjekten
für jeweilige
Gerätemanager
zur Verfügung.
-
Der
Objektsatz OS kann z. B. alle von Endress + Hauser unterstützen Feldgerätetypen
umfassen.
-
Mit
Hilfe des Hauptobjekts HO können
noch eine Vielzahl von weiteren Geräteobjekten instanziiert werden.
In 2a ist nur noch ein weiteres instanziiertes Geräteobjekt
B explizit dargestellt. Das Hauptobjekt HO und das Geräteobjekt
A bilden zusammen den Gerätemanager
A für das
Feldgerät
A.
-
In 2b ist
eine erste Alternative, wie ein aktualisiertes Geräteobjekt
in das Konfigurationssystem KS eingebunden werden kann, dargestellt.
Dazu muss ein aktualisiertes Hauptobjekt HO und eine aktualisierte
Software des Geräteobjekts
B vom Feldgerätehersteller
zur Verfügung
gestellt werden. Die aktualisierten Objekt-Versionen sind jeweils
durch den Zusatz (V2) gekennzeichnet.
-
Die
aktualisierte Version des Hauptobjekts HO (V2) wird auf der Rechnereinheit
RE installiert und ersetzt damit die alte Version des Hauptobjekts HO,
welches somit nicht mehr zur Verfügung steht.
-
Dadurch,
dass das Hauptobjekt HO durch eine neue Version ersetzt, ändern sich
implizit auch alle instanziierten Gerätemanager, die nicht den Gerätetyp B
repräsentieren.
Diese Alternative der Integration eines aktualisierten Geräteobjekts
erfordert auf der Seite des Herstellers des Hauptobjekts einen erheblichen
Testaufwand, da nicht nur der Gerätemanager für den Gerätetype B gestestet werden muss, sondern
auch die Gerätemanager
für alle
anderen von Hauptobjekt HO (V2) unterstützten Gerätetypen getestet werden müssen. Dieser
Testaufwand ist insbesondere dann schwer zu leisten, wenn Geräteobjekte
variabel hinzugefügt
werden können.
-
In 2c ist
eine zweite Alternative dargestellt, wie ein geändertes Geräteobjekt in das Konfigurationssystem
KS eingebunden werden kann.
-
Hierzu
wird ein weiteres Hauptobjekt HO-2 erzeugt, das für die Instanziierung
des aktualisierten Geräteobjekts
B zuständig
ist und das Geräteobjekt B
in seinem Objektsatz OS-2 enthält.
Das Geräteobjekt
B wir dabei aus dem Objektsatz OS-1 des Hauptobjekts HO entfernt.
-
Die
unveränderten
Geräteobjekte
werden weiterhin über
das ursprüngliche
Hauptobjekt HO instanziiert.
-
Bei
dieser Alternative entstehen zwei völlig unabhängige Gerätemanager A und B. Eine gegenseitige
Beeinflussung der Gerätemanager
ist somit nicht mehr möglich.
Es ändert
sich jedoch die Modulstruktur des Kommunikationssystems KS elementar. Projekte
die den ursprünglichen
Gerätemanager
für Gerätetyp B
enthalten, können
nicht mehr oder nur teilweise geladen werden und alle Gerätemanager für den Gerätetyp B
müssen
manuell ausgetauscht werden, da der Rahmenapplikation R keine Regeln bekannt
sind, diesen Austausch automatisch durchzuführen. Alle Daten der ursprünglichen
Gerätemanagerinstanzen
gehen dabei verloren. Je nach Anzahl und Datensatzgröße der ursprünglich instanziierten
Gerätemanager
ist ein beträchtlicher
Konfigurationsaufwand für
den Anwender notwendig, um diesen Austausch vorzunehmen.
-
In 3a ist
die erfindungsgemäße Lösung näher dargestellt.
Zwischen die Rahmenapplikation R und dem Hauptobjekt HO-1 ist eine
Zwischenschicht Z eingefügt.
Die Darstellung hier entspricht im Wesentlichen der Situation in 2a ohne
Zwischenschicht.
-
In 3b ist
dargestellt, wie ein aktualisiertes Geräteobjekt in das Konfigurationssystem
KS integriert wird. Für
das aktualisierte Geräteobjekt
B muss ein zusätzliches
zweites Hauptobjekt HO-2 erzeugt werden.
-
Die
Zwischenschicht Z entscheidet, welches Geräteobjekt über welches Hauptobjekt instanziiert wird.
-
Wählt der
Anwender das Gerät
A mit der zugehörigen
Kennung Kn(A) aus, so wird das Hauptobjekt HS-1 und das Geräteobjekt
A instanziiert.
-
Wählt der
Anwender das Gerät
B mit der Kennung Kn(B) aus, so über
die Zwischenschicht Z das Hauptobjekt HO-2 und das aktuelle Geräteobjekt B
instanziiert.
-
Es
liegen nun zwei Gerätemanager
A und B vor, wobei der Gerätemanager
B die aktualisierte Softwareversion für das Geräteobjekt B aufweist An der
Modulstruktur des objektbasierten Konfigurationssystems KS ändert sich
hierbei nichts. Dadurch ist auch in der Rahmenapplikation R kein
Konfigurationsaufwand notwendig. Die Rahmenapplikation R nimmt überhaupt
nicht wahr, dass ein geändertes Softwareobjekt
B instanziiert wurde. Der wesentliche Vorteil, der sich hierdurch
ergibt, ist ein extrem geringer Testaufwand. Die Beeinflussung der
beteiligten Komponenten ist ebenfalls minimal. Außerdem ist der
Integrationsaufwand, der für
ein geändertes
Geräteobjekt
notwendig ist, minimal.
-
In 4 ist
das Schnittstellenkonzept zwischen Rahmenapplikation R und Zwischenschicht
Z bzw. Hauptobjekt HO schematisch dargestellt. Der Rahmenapplikation
R steht der Gerätekatalog
mit einer Vielzahl von Gerätetypen
zur Verfügung.
Bei einer Projekterstellung übernimmt
der Anwender verschiedene Geräte
in sein Projekt. Diese Projektdaten werden im Projektdatenspeicher
S abgespeichert. Die Rahmenapplikation R kann natürlich auch
auf die Microsoft Windows Registry zugreifen. Die Zwischenschicht
Z besitzt eine DTM-Schnittstelle IDTM, über die die Rahmenapplikation
R auf die Zwischenschicht Z zugreift. Das Hauptobjekt HO besitzt
ebenfalls eine entsprechende DTM-Schnittstelle IDTM. Zusätzlich weist
das Hauptobjekt HO noch eine proprietäre Schnittstelle IEH auf. Über diese
proprietäre Schnittstelle
IEH kann die Zwischenschicht Z auf das Hauptobjekt HO zugreifen.
Die erlaubten Konstellationen zwischen Zwischenschicht Z und den
Hauptobjekten HO und deren Geräteobjekte
bestimmt eine Datenbank D, die zum Beispiel durch die Microsoft Windows
Registry realisiert werden kann. Requests von der Rahmenapplikation
R werden über
die Zwischenschicht Z an das Hauptobjekt HO weitergeleitet. Zur
Instanziierung eines Gerätemanagers
für einen
Gerätetyp
Kn ermittelt die Zwischenschicht mit Hilfe der Datenbank D welches
Hauptobjekt HO1 oder HO2 zu instanziieren ist, um den Gerätetyp der Kennung
Kn darzustellen und instanziiert das entsprechende. Über die
proprietäre
Schnittstelle IEH initialisiert die die Zwischenschicht Z das Hauptobjekt HO1
bzw. HO2 und reicht damit die Kennung Kn weiter. Das Hauptobjekt
HO1 bzw. HO2 ermittelt anhand der Datenbank D das zum Gerätetype mit
der Kennung Kn passende Geräteobjekt
und instanziiert dieses.