-
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.
-
Die Veröffentlichung THRAMBOULIDIS,K.; PRAYATI,A.: „Field Device Specification for the Development of Function Block Oriented Engineering Support Systems", erschienen In: 8th IEEE International Conference on Energing Technologies and Factory Automation, 2001, Bd.1, DOI: 10.1109/ETFA.2001.996417, S.581-587 offenbart eine Vier-Ebenen-Architektur für funktionsblockbasiertes Prozesskontrollsystem.
-
Die
DE 10 2004 038 808 A1 offenbart ein Versionskontrollsystem, welches die Verwaltung von Versionen von Prozessanlagenelementen, die Entitäten in einer Prozessanlage repräsentieren oder repräsentieren können, unterstützt. Die Prozessanlagenelemente können beispielsweise Modulobjekte umfassen, die spezifisch Prozessentitäten der Prozessanlage repräsentieren können.
-
Die
US 2004/0162841 A1 offenbart ein computerimplementiertes Verfahren, welches den Speichervorgriff von Objektdaten betrifft. Die Anmeldung offenbart mit „Microsoft Repository“ ein Versionskontrollsystem.
-
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 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 KommunikationsSchnittstelle 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 KommunikationsSchnittstelle 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.
