-
Die Erfindung betrifft ein Verfahren zur Parametrierung eines Feldgeräts der Prozessautomatisierungstechnik.
-
In der Prozessautomatisierungstechnik werden vielfach Feldgeräte eingesetzt, die zur Erfassung und/oder Beeinflussung von Prozessgrößen dienen. Als Feldgeräte werden im Prinzip alle Geräte bezeichnet, die prozessnah eingesetzt werden und die prozessrelevante Informationen liefern oder verarbeiten. Insbesondere sollen hier Sensoren aber auch Aktoren genannt werde. Als Sensoren ausgestaltete Feldgeräte können beispielsweise Prozessmessgrößen wie Druck, Temperatur, Durchfluss, Füllstand oder Messgrößen der Flüssigkeits- und/oder Gasanalyse wie zum Beispiel pH-Wert, Leitfähigkeit, Konzentrationen bestimmter Ionen, chemischer Verbindungen und/oder Konzentrationen oder Partialdrücke von Gasen, überwachen.
-
Beim Neubau eine Anlage der Prozessautomatisierungstechnik, welche viele Feldgeräte umfasst, werden diese häufig schon vor der eigentlichen Installation am Bestimmungsort parametriert. Dies erfolgt in der Regel durch den Anlagenbauer in Zusammenarbeit mit dem Betreiber der Anlage. Ist die Anlage dann fertig, werden die vorab bestimmten Parameter auf die Feldgeräte geladen (die so genannte „Parametrierung“). Dies wird häufig als „Offline-“ oder „Vorab-“ Konfiguration bezeichnet.
-
Der Erfindung liegt die Aufgabe zugrunde, eine einfache, jedoch vollumfängliche und fehlerfreie Vorabkonfiguration für Feldgeräte bereit zu stellen.
-
Die Aufgabe wird gelöst durch ein Verfahren, umfassend die Schritte: Parametrieren eines Abbilds des Feldgeräts, wobei das Abbild als feldgerätespezifische Software auf einem Interpreter, insbesondere einem Software-Emulator, ausgeführt wird, wobei der Interpreter auf einem Host ausgeführt wird, und zwischen Host und Feldgerät während des Parametrierens keine Verbindung besteht; und Übertragen der über das Abbild erzeugten Parametrierung zum Feldgerät.
-
Damit die Offline-Konfiguration fehlerfrei funktioniert, müssen die im Feldgerät enthaltenen Abhängigkeiten der einstellbaren Parameter fehlerfrei abgebildet werden. Hierzu muss im Feldgerät implementierte Abhängigkeitslogik im zur Erstellung der Offline-Konfiguration verwendeten Programm nachgebildet werden. Auf diese Weise ist gewährleistet, dass voneinander abhängige Parameter nur in gültigen Datenkombinationen verändert werden können. Hierzu zählen beispielsweise Wertebereiche von einstellbaren Größen oder die Menge der zulässigen Auswahlmöglichkeiten eines Auswahlparameters. Stimmt die hierzu im Programm zur Offline-Konfiguration implementierte Abhängigkeitslogik nicht mir der im Feldgerät implementierten überein, kann es beim Übertragen der offline erstellten Parametrierung in das Feldgerät zur Ablehnung der Parametrierung seitens des Feldgeräts oder schlimmstenfalls zu Funktionsstörungen führen.
-
Es müssen also Parameterabhängigkeiten, wie Wertebereiche von Parametern, die Darstellung eines Parameters, Einheiten der Parameter, auch mit Abhängigkeiten etwa des Betriebsmodus, und beispielsweise die Sichtbarkeit von Parameter abgebildet werden. Zudem muss nach der erfolgten Parametrierung des Anwenders validiert werden, ob die gemachten Einstellungen technisch überhaupt zulässig sind.
-
Eine deckungsgleiche und fehlerfreie Abbildung eines Feldgeräts für die Offline-Parametrierung beispielsweise für die Vorabkonfiguration einer neuen Anlage oder für einen Kunden, der per Weboberfläche ein Gerät kauft, ist nur mit hohem Aufwand möglich. Ändert sich ein Feldgerät oder auch nur die verwendete Firmware-Version, so muss unter Umständen das Programm zur Vorabkonfiguration geändert oder neu erstellt werden.
-
Es handelt sich bei dem Abbild um das virtuelle Abbild der gesamten, d.h. unveränderten Feldgerätelogik.
-
Durch das oben genannte Verfahren ergibt sich keine Asynchronität zwischen dem Feldgerät und dem Abbild desselben, da der identische Code, der auf dem Feldgerät ausgeführt wird, auch auf dem Hostsystem über den Interpreter, insbesondere den Software-Emulator ausgeführt wird. Dadurch ist gewährleistet, dass die gesamte Abhängigkeitslogik des realen Feldgeräts auch während der Offline-Konfiguration zur Verfügung steht. Da keinerlei Transformation der im Feldgerät enthaltenen Abhängigkeitslogik in die im Hostsystem verwendete Abhängigkeitslogik erforderlich ist, sondern über die interpretierte bzw. emulierte Ausführung der Feldgerätesoftware die im Feldgerät tatsächlich verwendete Abhängigkeitslogik direkt verwendet wird, ist eine unterschiedliche Ausführung der Abhängigkeitslogik ausgeschlossen.
-
Auf dem Host kann dadurch die Bedienoberfläche des Feldgeräts direkt sichtbar gemacht werden und das virtuelle Feldgerät kann dadurch auf identische Weise im Hostsystem bedient und konfiguriert werden, wie es im realen Gerät der Fall wäre. In einer Ausgestaltung kann über geeignete Softwareschnittstellen zusätzlich eine an die jeweilige Host-Umgebung angepasste Bedienoberfläche zur Verbesserung des Bedienkomforts realisiert werden. Ein Beispiel hierfür ist eine Darstellung in Form einer interaktiven Webseite im Falle eines Hosts, der als Webserver ausgeführt ist. Hierbei würde etwa die Maus und Tastatur des Anwenders zur direkten Eingabe von Werten genutzt werden können und nicht über eine Nachbildung der Bedientasten des Vor-Ort-Displays des Feldgeräts eine in dieser Umgebung umständliche Bedienung erfolgen müssen.
-
Im Allgemeinen ist ein Interpreter ist ein Computerprogramm, das einen Programm-Quellcode im Gegensatz zu Assemblern oder Compilern nicht in eine auf dem System direkt ausführbare Datei übersetzt, sondern den Quellcode einliest, analysiert und ausführt. Die Analyse des Quellcodes erfolgt zur Laufzeit des Programmes.
-
In einer Ausgestaltung ist der Interpreter als Emulator, genauer als Software-Emulator, ausgestaltet. Ein Emulator ist ein Interpreter, da dieser den Maschinencode des Gastsystems befehlsweise oder in Befehlssequenzen auf einem „virtuellen Prozessor“ abarbeitet. In anderen Worten ist der Emulator eine Ausführungseinheit, die Maschinencode einer bestimmten Architektur ausführt. Als Emulator wird ein System bezeichnet, das ein anderes in bestimmten Teilaspekten nachbildet. Das nachgebildete System erhält die gleichen Daten, führt vergleichbare Programme aus und erzielt die möglichst gleichen Ergebnisse in Bezug auf bestimmte Fragestellungen wie das zu emulierende System. Software-Emulatoren sind Programme, die Recheneinheiten nachbilden und es so ermöglichen, Software für genau diese Recheneinheit auf einer Recheneinheit mit einer anderen Architektur zu verwenden.
-
Der Interpreter kann auch in der Sonderform eines Emulators, nämlich in einer virtuellen Maschine ausgeführt sein. Die virtuelle Maschine kann Teile des Maschinencodes des Gastsystems auf dem Hostsystem direkt ausführen. Die Definition von „Emulator“ bzw. „virtueller Maschine“ ist in der Literatur nicht eindeutig und verschwimmt. Im Sinne dieser Anmeldung führt eine „virtuelle Maschine“ große Teile ihrer Befehle nativ auf der CPU des Hostsystems aus. Da viele Befehle direkt auf der CPU des Hostsystems ausgeführt werden, muss für das Gastsystem die gleiche CPU-Architektur verwendet werden wie auf dem Hostsystem. Es ist dabei die Unterstützung des Prozessors und/oder des Betriebssystems des Hostsystems notwendig, um die Abstraktion zwischen Gast- und Hostsystem zu ermöglichen. Bei der Emulation hingegen besteht diese Notwendigkeit nicht. Bei der Emulation kann ein von der Hardware oder CPU abweichender Code ausgeführt werden. Ein gängiges Verfahren ist die Software-Emulation, welche sämtliche Funktionen von einzelnen Hardwarekomponenten in Software nachbildet. Dadurch können Programme ausgeführt werden, die für eine andere CPU geschrieben wurden. Die Software-Emulation ist somit plattformunabhängig realisierbar.
-
In einer Ausgestaltung ist der Interpreter als Skriptspracheninterpreter ausgestaltet.
-
In einer Ausgestaltung kann die Skriptsprache Lua sein. „Lua“ ist eine imperative Skriptsprache, die sowohl funktionale als auch objektorientierte Programmierung ermöglicht. Lua hat eine geringe Größe des kompilierten Skript-Interpreters und eine hohe Ausführungsgeschwindigkeit. Lua-Programme können plattformunabhängig entwickelt werden.
-
In einer Ausgestaltung können auf einem Host ein oder mehrere Skriptspracheninterpreter und/oder Emulatoren parallel gestartet und auch parallel betrieben werden.
-
Ist der Interpreter gestartet, wird anschließend darauf eine feldgerätespezifische Software ausgeführt. Die „feldgerätespezifische Software“ ist Software, die nicht primär Teil des Host ist, d.h. diese ist explizit nicht Bestandteil des Host-Betriebssystems. Die feldgerätespezifische Software wird zur Laufzeit geladen. Insbesondere wird die feldgerätespezifische Software zur Laufzeit von einem Speicher geladen. Der Speicher kann dabei sowohl als fest in der Hardware des Host integrierter Speicher (z.B. Flash-Speicher), in Form eines dem Anwender zugänglichen Wechselspeichers (z.B. Speicherkarte) oder auch in Form eines Netzwerkspeichers, welcher durch Datenkommunikation adressiert wird (z.B. Dateiserver) realisiert sein.
-
Im Allgemeinen ist die feldgerätespezifische Software somit Softwarecode, der in einer bestimmten (Programmier-) Sprache formuliert ist und auf dem Host ausgeführt wird. Ist der Interpreter als Emulator ausgestaltet, ist die feldgerätespezifische Software in Maschinencode formuliert. Ist der Interpreter als Skriptspracheninterpreter ausgestaltet, ist die feldgerätespezifische Software als spezifischer Softwarecode, im oben genannten Beispiel als Lua-Code formuliert.
-
In einer Ausgestaltung sind pro Host mehrere Interpreter ausführbar. In einer Ausgestaltung ist der Interpreter dynamisch instanziierbar. Der Programmcode des Interpreters befindet sich einmal auf dem Host, genauer auf einem Speicher des Host, und wird bei einem Aufruf einer Instanz abgearbeitet. Eine Instanz ist dabei ein konkretes Vorkommen eines Objekts, hier also des Interpreters, das (nur) während seiner Laufzeit existiert. In einer Ausgestaltung ist sind bereits mehrere Interpreter statisch geladen.
-
Bei der feldgerätespezifischen Software handelt es sich etwa um Signalverarbeitung von Sensordaten, um einen oder mehrere Zustandsautomaten, Menüführung des Feldgeräts, aber insbesondere um die Parametrierung des Feldgeräts.
-
In einer Ausgestaltung wird feldgerätespezifische Software auf den Host übertragen, wenn sich diese noch nicht auf dem Host befindet.
-
Die feldgerätespezifische Software muss einmalig vom Host geladen werden, um sie anschließend innerhalb seines Interpreters auszuführen.
-
In einer Ausgestaltung wird die feldgerätespezifische Software nativ, insbesondere als architekturspezifischer Binärcode, auf dem Feldgerät ausgeführt.
-
In einer Ausgestaltung umfasst das Feldgerät einen Interpreter, insbesondere einem Software-Emulator, und die feldgerätespezifische Software wird darauf ausgeführt.
-
In einer Ausgestaltung wird daher die feldgerätespezifische Software in einem Bytecode erstellt, der sowohl im Feldgerät als auch im Hostsystem in einem Interpreter ausführbar ist. In diesem Fall reduziert sich die Systemkomplexität signifikant, da alle codeausführenden Systeme nur noch mit einem Interpreter, der diesen einheitlichen Bytecode ausführen kann, ausgestattet werden können.
-
In einer Ausgestaltung umfasst die feldgerätespezifische Software mehrere Teilfragmente. So ist es etwa bei einem Mehrkanalgerät denkbar, dass die verschiedenen mit dem Feldgerät verbundenen Sensoren einen Teil der im Feldgerät laufenden Software (z.B. Signalverarbeitungsroutinen und Bedienmenüdialoge) bei der initialen Verbindung zwischen Sensor und Feldgerät in das Feldgerät übertragen um auf diese Weise flexibel an dieses angebunden werden können. Durch diese Architektur kann die feldgerätespezifische Software daher auch als die Gesamtheit der im Feldgerät laufenden Softwarekomponenten betrachtet werden.
-
In anderen Worten wird der auf dem Feldgerät laufende Code, sei es nativ oder über den Interpreter (siehe oben), ebenfalls auf einem Hostsystem ausgeführt. Der Feldgerätecode kann entweder einmalig bei einer Erstverbindung zwischen Feldgerät und Host in den Speicher des Hosts geladen werden, oder er steht dort bereits in Form einer Datenbank verschiedener Feldgerätecodes zur Verfügung, oder wird über eine Datenverbindung etwa aus dem Internet dynamisch geladen.
-
Insbesondere, wenn eine Vorabparametrierung erfolgt, befindet sich die feldgerätespezifische Software bereits auf dem Host oder wird etwa über das Internet bezogen, ohne dass zuvor eine Verbindung zum jeweiligen Feldgerät erforderlich wäre. Dadurch wird eine Offline-Parametrierung des Feldgeräts auch im Fall einer Erstinbetriebnahme möglich, zu der zum Zeitpunkt der Offline-Parametrierung noch nie zuvor eine Verbindung zum Feldgerät bestand.
-
Nach Beendigung der Offline-Parametrierung werden die Parameter an das Feldgerät übertragen. Die Übertragung kann dabei auf vielfältige Weise erfolgen. In einer Ausgestaltung handelt es sich dabei um einen Feldbus wie Modbus, Profibus, Fieldbus Foundation, HART, WirelessHART, über einen Webserver, per Bluetooth, WLAN, oder über ein Speichermedium. Der Host selbst muss nicht der direkte Kommunikationspartner sein, dies kann auch über eine weitere Ebene, wie z.B. ein Leitsystem erfolgen.
-
Als Host kommen dabei verschiedene Architekturen in Frage.
-
Zunächst soll auf FDT/DTM eingegangen werden. FDT (Field Device Tool) ist ein herstellerübergreifendes Konzept in der Automatisierungstechnik, welches die Parametrierung von Feldgeräten ermöglicht. Ein DTM (Device Type Manager) ist kein eigenständiges Programm, sondern funktioniert nur im Zusammenspiel mit einer FDT-Rahmenapplikation. Er repräsentiert inhaltlich ein bestimmtes Gerät oder eine Kommunikationskomponente mit seinen/ihren Eigenschaften und Funktionen einschließlich Bedienoberfläche. Aus einer Rahmenapplikation heraus ermöglichen die DTMs die Bedienung mit „ihren“ in der Anlage befindlichen Geräten bzw. Kommunikationskomponenten. Ein Anwender kann die Funktionen der angeschlossenen Geräte über die zugehörigen DTMs aufrufen. Geräte-DTMs sind Treiber und gerätespezifisch aufgebaut. Sie enthalten Daten, Funktionen und Logikelemente des Gerätes. Je nach Implementierungsgrad beinhaltet der Treiber eine grafische Benutzeroberfläche für das Einstellen der Geräteparameter bis zu Anwendungen für Diagnose und Wartung, z.B. eine Logik zur Gerätekalibrierung. Geräte-DTMs werden in der Regel vom Gerätehersteller entwickelt.
-
Das oben beschriebene Problem mit der notwendigen eins-zu-eins-Abbildung des Feldgeräts zur Bereitstellung einer Vorabkonfiguration für Feldgeräte wird damit beim FDT/DTM-Konzept besonders deutlich. Der Aufwand für den Hersteller von Feldgeräten, und damit von DTMs, ist sehr hoch.
-
In einer Ausgestaltung handelt es sich deswegen bei dem Host um einen Device Type Manager (DTM) und der Interpreter ist als Teil des Device Type Managers darin ausführbar.
-
Damit entfällt eine parallele Entwicklung von verschiedenen DTMs. Es muss lediglich ein einziger DTM entwickelt werden, auf welchem ein Interpreter ausführbar ist. Im Interpreter wird die entsprechende feldgerätespezifische Software ausgeführt. Diese wird für das entsprechende Feldgerät entwickelt und ist nun auf verschiedenen Arten von Hosts gleichermaßen ausführbar.
-
In einer Ausgestaltung handelt es sich bei dem Host um einen Webserver und der Interpreter wird darauf ausgeführt.
-
In einer Ausgestaltung handelt es sich bei dem Host um ein Mobilgerät und der Interpreter wird darauf, insbesondere als App oder als Teil einer App, ausgerührt. Das Mobilgerät ist dabei etwa ein Smartphone, Tablet, Phablet, Notebook, Netbook oder auch ein PDA.
-
Die Vorteile, die im Zusammenhang mit einem FDT/DTM genannt wurden, gelten bei der Ausführung des Hosts als Webserver oder auf einem Mobilgerät gleichermaßen. Im Falle des Webservers kann ein Anwender über den Browser ein Feldgerät entsprechend seinen Vorstellungen parametrieren. Dadurch, dass im Interpreter, der auf dem Webserver ausgeführt wird, der zum auf dem Feldgerät ausgeführte identische Code ausgeführt wird, kann wie bereits zuvor beschrieben sichergestellt werden, dass die so erstellte Parametrierung bzw. Konfiguration vollständig konsistent ist.
-
Durch die Tatsache, dass im Host der vollständige feldgerätespezifische Code ausgeführt wird, kann zum Zeitpunkt der Offline-Parametrierung durch Simulation verschiedener Zustände, etwa verschiedene Messwerte, Ereignisse oder Fehlerzustände, verifiziert werden, dass die getroffenen Einstellungen die gewünschte Auswirkung im Feldgerät haben werden. Dieser Aspekt geht über die statische Vorparametrierung z.B. über DTMs hinaus, da hier nur die Parametrierung an sich, nicht jedoch das komplette Geräteverhalten abgebildet werden kann.
-
In einer Ausgestaltung wird die aktuelle Parametrierung des Feldgeräts vor Beginn des Parametriervorgangs zunächst über eine Datenverbindung vom Feldgerät auf den Host geladen. Bei der Datenverbindung kann es sich um eine Kabelverbindung oder eine drahtlose Verbindung handeln. Die aktuelle Parametrierung kann auch über einen Feldbus direkt oder über das Leitsystem vom Feldgerät an den Host übertragen werden. Dadurch wird sichergestellt, dass auch das Abbild die aktuelle Parameterkonfiguration enthält und bei dem Rückübertragen nur die geänderten Parameter übertragen werden. In einer Ausgestaltung werden nur geänderte Parameter übertragen.
-
Die Aufgabe wird weiter gelöst durch ein Feldgerät, das zur Anwendung eines Verfahren wie oben beschrieben ausgestaltet ist, insbesondere das zum Empfang von über das Abbild erzeugten Parametrierung ausgestaltet ist.
-
In einer Ausgestaltung umfasst das Feldgerät einen Speicher mit feldgerätespezifischer Software.
-
In einer Ausgestaltung ist das Feldgerät als Messumformer ausgestaltet. Der Messumformer ist dabei insbesondere als Mehrkanalmessumformer ausgestaltet, d.h. an den Messumformer können mehrere Geräte, z.B. Sensoren, angeschlossen werden.
-
In einer Ausgestaltung wird auf dem Messumformer ein Interpreter, insbesondere ein Software-Emulator, ausgeführt, der zur Ausführung der feldgerätespezifischen Software ausgestaltet ist.
-
In einer Ausgestaltung ist das Feldgerät als Sensor zur Erfassung von Messwerten ausgestaltet.
-
Dies wird anhand der nachfolgenden Figuren näherer erläutert.
- 1a/b zeigt eine schematische Übersicht über das beanspruchte Verfahren.
- 2 zeigt einen Messumformer mit feldgerätespezifischer Software.
- 3a/b zeigt eine Messanordnung umfassend einen Messumformer und ein Feldgerät in zwei verschiedenen Ausführungsformen.
-
In den Figuren sind gleiche Merkmale mit gleichen Bezugszeichen gekennzeichnet.
-
1a zeigt eine schematische Übersicht über den ersten Schritt des beanspruchten Verfahrens. Ein Anwender A parametriert dabei ein Abbild 1' eines Feldgeräts 1. Das Feldgerät 1 ist beispielsweise ein Sensor 5. Das Feldgerät 1 ist beispielsweise aber auch ein Messumformer 20. Im Folgenden soll mit „Feldgerät“ immer ein Messumformer gemeint sein, wenn nicht anderweitig erwähnt.
-
Das Abbild 1' ist eine feldgerätespezifische Software 60, welche in einem Interpreter 50 ausgeführt wird. Der Interpreter 50 wird auf dem Host 70 ausgeführt. Es besteht keine Verbindung zwischen dem Host 70 und dem eigentlichen, d.h. realen, Feldgerät 1.
-
Der Interpreter 50 ist als Emulator, genauer als ein Software-Emulator, ausgeführt.
-
Der Interpreter 50 führt den Maschinencode des Gastsystems, also das Abbild 1' in Form der feldgerätespezifischen Software 60 befehlsweise auf einem virtuellen Prozessor auf dem Host 70 aus.
-
Im Allgemeinen wird als Emulator ein System bezeichnet, das ein anderes in bestimmten Teilaspekten nachbildet. Das nachgebildete System erhält die gleichen Daten, führt gleiche oder zumindest vergleichbare Programme aus und erzielt möglichst die gleichen Ergebnisse wie das zu emulierende System. Software-Emulatoren sind Programme, die einen Computer nachbilden und es so ermöglichen, Software für diesen Computer auf einem Computer mit einer anderen Architektur zu verwenden.
-
Im Interpreter 50 wird zumindest eine, bevorzugt genau eine, feldgerätespezifische Software 60 (pro Interpreter 50) ausgeführt. Es können mehrere Interpreter 50 pro Host 70 ausgeführt werden.
-
In einer Ausführungsform ist der Interpreter 50 nicht als Emulator ausgestaltet, sondern der Interpreter ist als Skriptspracheninterpreter ausgestaltet. In einer Ausführungsform ist diese Skriptsprache Lua. Andere Beispiele sind Python, VBA, Lisp, VBScript oder JScript. Grundsätzlich ist es auch möglich verschiedene Skriptspracheninterpreter auf einem Host 70 zu installieren und zu starten. Werden mehrere Interpreter 50 auf einem Host ausgeführt kommunizieren die einzelnen Interpreter 50 mittels standardisierter Schnittstellen miteinander. Im Allgemeinen sind die Schnittstellen als zentraler Bestandteil der gesamten System infrastruktur definiert und so ausgestaltet, dass sie über Jahre hinweg kompatibel sind, selbst wenn in der Zukunft Erweiterungen und Veränderungen durchgeführt werden, beispielsweise eine andere Art der Datentypen wie z.B. die Übertragung komplexer Spektren statt Messwerte, die üblicherweise als Wert mit der entsprechenden Einheit übertragen werden.
-
Für den Host 70 kommen verschieden Ausgestaltungen in Betracht. Der jeweilige Host umfasst einen entsprechenden Interpreter, wobei die darauf ausführbare feldgerätespezifische Software 60 immer die gleiche ist. In einer Ausgestaltung ist der Interpreter 50 ist auf allen möglichen Architekturen des Hosts 70 als Gleichteil ausgeführt, lediglich die notwendigen Schnittstellen zu seinen jeweils eigenen Komponenten wie z.B. den jeweiligen Eingabe- und Ausgabemöglichkeiten, sind spezifisch für den jeweiligen Host und werden entsprechend angepasst. Dabei kann der Interpreter 50 etwa in einer plattformübergreifenden Programmiersprache wie C geschrieben sein, sodass der Quellcode des Interpreters an sich für alle verschiedenen Plattformen gleich ist.
-
Der Host 70 ist etwa als DTM (Device Type Manager) ausgeführt. Als Teil des DTM ist ein Interpreter 50 ausgeführt.
-
Ebenso kann der Host 70 als Webserver ausgestaltet sein und der Interpreter 50 wird darauf ausgeführt.
-
Ebenso kann der Host 70 als Mobilgerät ausgestaltet sein, auf dem der Interpreter, etwa als App, ausgeführt wird.
-
Bei der feldgerätespezifischen Software 60 handelt es sich also um Signalverarbeitung von Sensordaten (siehe unten), um einen oder mehrere Zustandsautomaten, Parametrierung des Feldgeräts 1, Menüführung des Feldgeräts 1 oder Feldbusanbindung des Feldgeräts 1.
-
Für den Anwender A macht es keinen Unterschied, ob direkt das Feldgerät 1 bedient wird, oder ob über den Interpreter 50 im Host 70 auf das Abbild 1' zugegriffen wird. Die Menüführung mit allen Menüs samt möglichen Parametereinstellungen wird exakt abgebildet, da das Abbild 1' aus derselben Software realisiert ist, welche in Feldgerät 1 ausgeführt wird.
-
Hierzu müssen die feldgerätespezifischen Komponenten einmalig auf den Host 70 geladen werden, um ihn anschließend innerhalb seines Interpreter 50 auszuführen. Dazu gibt es verschiedene Möglichkeiten, auf die im Folgenden eingegangen wird.
-
Der Host 70 umfasst dazu einen Speicher 71, auf dem die feldgerätespezifische Software 60 gespeichert ist. Aus dem Speicher 71 wird die feldgerätespezifische Software 60 in den Emulator 50 geladen, was in 1a durch den gestrichelten Pfeil angedeutet ist. Alternativ oder zusätzlich zur Speicherung der feldgerätespezifischen Software 60 im Speicher 71, umfasst der Host 70 eine Anschlussmöglichkeit für externen Speicher, etwa eine Speicherkarte (etwa eine SD-Karte). In einer Alternative baut der Host 70 eine Datenverbindung ins Internet auf und lädt sich die für das jeweilige Feldgerät 1 bzw. 1' passende Software herunter. Anhand einer eindeutigen Kennung des Feldgeräts 1 wird die jeweils richtige Software gefunden.
-
Der Anwender A parametriert somit im Host 70 das Abbild 1' des Feldgeräts 1. Der Anwender nimmt also eine vollständige Parametrierung P des Feldgeräts vor.
-
Es ist möglich, dass die momentan aktuelle Parametrierung des Feldgeräts 1 zunächst vom Feldgerät 1 an den Host 70 übertragen wird, damit auf dem Host die aktuellste Version der Parameter vorhanden ist. Die Übertragung erfolgt beispielsweise über ein Backup der Geräteparametrierung, etwa auf einer SD-Karte, über einen Feldbus, Ethernet oder eine Funkverbindung.
-
Im nächsten Schritt, siehe 1b, wird die Parametrierung P vom Host 70 auf das reale Feldgerät 1 übertragen. Das Feldgerät 1 empfängt die Parametrierung P und pflegt entweder die gesamte Parametrierung ein. Alternativ werden nur die Unterschiede zur momentan aktuellen Parametrierung eingepflegt. Dadurch wird jeweils die momentan aktuelle Parametrierung des Feldgeräts 1 durch die getätigte Offline-Parametrierung P überschrieben.
-
Wie erwähnt ist das Feldgerät 1 als Messumformer 20 ausgestaltet, siehe dazu auch unten und insbesondere die 3a/b. Der Messumformer kann als Multikanalmessumformer ausgestaltet sein. An den Messumformer 20 können ein Sensor 5 oder mehrere Sensoren („Multikanal“) angeschlossen sein.
-
Der Messumformer 20 kann einen Interpreter 50 umfassen, wie in 2 dargestellt. Für diesen Interpreter gilt das Gleiche wie oben bezüglich eines Interpreters 50 auf einem Host 70 gesagte. Die feldgerätespezifische Software 60 als Abbild 1' des Feldgeräts 1, also des Messumformers 20, ist auf dem Interpreter 50 lauffähig. Es ist also möglich, dass große Teile der Software des Messumformers nicht „nativ“, d.h. direkt von einer CPU, ausgeführt werden, sondern in einem Interpreter 50. Im Interpreter 50 laufen also ein oder mehrere Zustandsautomaten, die Parametrierung des Messumformers 20, dessen Menüführung oder die Feldbusanbindung ab.
-
Der Messumformer 20 stellt in diesem Fall eine Ausgestaltung eines Hosts 70 dar.
-
Die gesamte Parametrierung P des Messumformers 20 wird durch die in ihm enthaltenen Parameter gebildet. Es existieren zum einen Parameter, die den angeschlossenen Sensor 5 betreffen, beispielsweise eine Temperatur-Offsetkorrektur. Zum anderen sind Parameter vorhanden, die den Messumformer 20 selbst betreffen, etwa eine Stromausgangskonfiguration (z.B. Stromspreizung). Beide Arten von Parametern können direkt „nativ“ im Messumformer eingestellt werden, etwa über ein dort vorhandenes Bedieninterface (z.B. via Display 22, das auch als Touchdisplay ausgestaltet sein kann, oder über am Messumformer vorhandene Knöpfe, Schalter o.a.).
-
Die im Messumformer 20 ablaufende feldgerätespezifische Software 60 beinhaltet unter anderem die Gesamtheit aller durch den Messumformers 20 bereitgestellten Parameter, also messumformerspezifische und sensorspezifische Parameter. Dadurch, dass die feldgerätespezifische Software 60 in Form eines Abbilds 1' in einem Interpreter 50 eines Hosts 70 ausgeführt werden kann, ist die Einstellung der genannten Parameter ebenso im Host 70 möglich.
-
Wird die feldgerätespezifische Software 60 aus mehreren Teilfragmenten aufgebaut, etwa durch messumformerspezifische und sensorspezifische Fragmente, ist die Menge der Einstellparameter abhängig von der konkreten physischen Verschaltung des Feldgeräts 1. Dies gilt insbesondere bei mehrkanaligen Messumformern, mit denen eine beliebige Kombination von Sensoren verbunden sein kann. Ist die physische Verschaltung des Feldgeräts 1 bekannt, kann somit im Host 70 die gleiche Ausprägung der feldgerätespezifischen Software 60 gebildet und als Abbild 1' im Interpreter 50 ausgeführt werden.
-
Die 3a und 3b zeigen eine Sensoranordnung 10 mit einem Messumformer 20 zur Ausführung des Verfahrens.
-
Der beanspruchte Messumformer 20 findet beispielsweise Anwendung in einer Sensoranordnung 10. Die Sensoranordnung 10 umfasst einen Sensor 5 und ein Anschlusselement 11, worauf zunächst eingegangen werden soll.
-
Über eine erste physikalische Schnittstelle 3 kommuniziert ein Sensor 5 mit dem Messumformer 20. Ein alternatives Wort für Messumformer ist Transmitter. Der Messumformer 20 wiederum ist mit einer übergeordneten Einheit 30, etwa einem Leitsystem, über ein Kabel 31 verbunden. Am Messumformer 20 ist sensorseitig ein Kabel 21 angeschlossen, dessen anderes Ende eine zur ersten physikalischen Schnittstelle 3 komplementäre zweite physikalische Schnittstelle 13 umfasst. Ein Anschlusselement 11 umfasst das Kabel 21 samt zweiter physikalischer Schnittstelle 13. Die physikalischen Schnittstellen 3, 13 sind etwa als galvanisch getrennte, insbesondere als induktive Schnittstellen ausgestaltet. Die physikalischen Schnittstellen 3, 13 sind mittels einer mechanischen Steckverbindung miteinander koppelbar. Die mechanische Steckverbindung ist hermetisch dicht, so dass von außen keine Flüssigkeit, etwa das zu messende Medium, Luft oder Staub eindringen kann.
-
Über die physikalischen Schnittstellen 3, 13 werden Daten (bidirektional) und Energie (unidirektional, d.h. vom Anschlusselement 11 zum Sensor 5) gesendet bzw. übertragen. Die Sensoranordnung 10 wird überwiegend in der Prozessautomatisierung angewendet.
-
Der Sensor 5 umfasst zumindest ein Sensorelement 4 zum Erfassen einer Messgröße der Prozessautomatisierung. Bei dem Sensor 5 handelt es sich dann etwa um einen pH-Sensor, auch als ISFET, im Allgemeinen einen ionenselektiven Sensor, einen Sensor zur Messung des Redoxpotentials, von der Absorption von elektromagnetischen Wellen im Medium, beispielsweise mit Wellenlängen im UV-, IR-, und/oder sichtbaren Bereich, des Sauerstoffs, der Leitfähigkeit, der Trübung, der Konzentration von nicht-metallischen Werkstoffen oder der Temperatur mit der jeweils entsprechenden Messgröße.
-
Der Sensor 5 umfasst weiter einen ersten Kupplungskörper 2, welche die erste physikalische Schnittstelle 3 umfasst. Wie erwähnt ist die erste physikalische Schnittstelle 3 zur Übertragung eines von der Messgröße abhängigen Werts an eine zweite physikalische Schnittstelle 13 ausgestaltet. Der Sensor 5 umfasst eine Datenverarbeitungseinheit µCS, etwa einen Mikrocontroller, welcher die Werte der Messgröße verarbeitet, etwa in ein anderes Datenformat wandelt. Die Datenverarbeitungseinheit µCS ist von der Rechenkapazität und Speichervolumen aus Energie- und Platzgründen eher klein bzw. sparsam konzipiert. Der Sensor 5 ist somit nur zu „einfachen“ Rechenoperation ausgestaltet, etwa einer zu Mittelung, Vorverarbeitung und Digitalwandlung.
-
Es können auch mehrere Sensoren 5 an einen Messumformer 20 angeschlossen werden. In 3a dargestellt sind zwei Sensoren 5, wobei nur einer der beiden mit allen Bezugszeichen versehen ist. Es können gleiche oder unterschiedliche Sensoren angeschlossen werden. Der linke der beiden ist im zusammengesteckten Zustand dargestellt. Ist der Messumformer 20 als Multikanalmessumformer ausgestaltet können beispielsweise bis zu acht Sensoren 5 angeschlossen werden.
-
Der Sensor 5 ist über die physikalischen Schnittstellen 3, 13 mit dem Anschlusselement 11 und schließlich mit dem Messumformer 20 verbindbar. Die Datenverarbeitungseinheit µCS wandelt den von der Messgröße abhängigen Wert (also das Messsignal des Sensorelements 4) in ein dem Messumformer 20 verständliches Protokoll. Ein Beispiel hierfür ist etwa das proprietäre Memosens-Protokoll der Anmelderin. Die erste und zweite physikalische Schnittstelle 3, 13 sind also zur bidirektionalen Kommunikation zwischen Sensor 5 und Messumformer 20 ausgestaltet. Wie erwähnt gewährleisten neben der Kommunikation die erste und zweite physikalische Schnittstelle 3, 13 auch die Energieversorgung des Sensors 5.
-
Das Anschlusselement 11 umfasst die zweite physikalische Schnittstelle 13, wobei die zweite physikalische Schnittstelle 13 komplementär zur ersten physikalischen Schnittstelle 3 ausgestaltet ist. Das Anschlusselement 11 umfasst ebenfalls eine Datenverarbeitungseinheit µCA. Die Datenverarbeitungseinheit µCA kann als Repeater für das gesendete Signal dienen. Weiter kann die Datenverarbeitungseinheit µCA das Protokoll wandeln oder ändern.
-
Das Anschlusselement 11 umfasst einen zweiten, zylindrischen Kupplungskörper 12, der komplementär zum ersten Kupplungskörper 2 ausgestaltet ist und welcher mit einem hülsenförmigen Endabschnitt auf den ersten Kupplungskörper 2 aufsteckbar ist, wobei die zweite physikalische Schnittstelle 13 in die erste physikalische Schnittstelle 3 gesteckt wird. Eine gegenteilige Anordnung, in der die zweite physikalische Schnittstelle 13 hülsenartig und die erste physikalische Schnittstelle 3 steckerartig ausgestaltet ist, ist ohne erfinderisches Zutun möglich.
-
Der Messumformer 20 umfasst ein Display 22 und ein oder mehrere Bedienelemente 23, etwa Knöpfe oder Drehknöpfe, über die der Messumformer 20 bedient werden kann. Über das Display 22 werden beispielsweise Messdaten des Sensors 5 angezeigt. Ebenso kann über die Bedienelemente 23 und der entsprechenden Ansicht im Display 22 der Sensor 5 konfiguriert und parametriert werden.
-
Der Messumformer 20 leitet (Kommunikation 35) Messdaten des Sensors 5 über das Kabel 31, wie erwähnt etwa an ein Leitsystem 30, weiter. Das Leitsystem 30 ist dabei entweder als Prozessleitsystem (PLC, SPS), PC oder Server ausgestaltet.
-
Der Messumformer 20 wandelt die Daten dazu in ein für das Leitsystem verständliches Datenformat, etwa in einem entsprechenden Bus wie HART, Profibus PA, Profibus DP, Foundation Fieldbus, Modbus RS485 oder auch ein Ethernet basierter Feldbus wie EtherNet/IP, Profinet oder Modbus/TCP. Diese Daten werden dann an das Leitsystem 30 weitergeleitet. Gegebenenfalls kann dies mit einem Webserver kombiniert werden, d.h. diese können parallel zueinander betrieben werden.
-
3b repräsentiert eine Ausgestaltung einer Sensoranordnung 10. Dabei wird an einen Messumformer 20 jeweils nur ein Sensor 5 angeschlossen. Der Messumformer 20 ist hier symbolisch als Rechteck dargestellt und ist in seinen Abmessungen kleiner als der Messumformer aus 3a, und hat etwa die Größe einer Streichholzschachtel. Der Messumformer 20 kann hier entweder als separate, an das Kabel 21 ansteckbare Einheit ausgestaltet sein, oder - wie hier dargestellt - direkt in das Kabel 21 integriert sein. Der Messumformer 20 besteht somit im Wesentlichen aus der Datenverarbeitungseinheit µCA. Der Messumformer 20 umfasst kein Display und hat - wenn überhaupt - nur ein oder zwei Bedienelemente, die für einen Reset oder zum Ein- und Ausschalten konfiguriert sind. Bevorzugt umfasst der Messumformer 20 in dieser Ausgestaltung keine Bedienelemente. Der Messumformer 20 umfasst daher ein Drahtlosmodul 24, etwa ein Bluetooth-Modul mit dem Protokollstapel Bluetooth Low Energy. An den Messumformer 20 drahtlos verbindbar ist darüber ein Mobilgerät (nicht dargestellt), etwa ein Mobiltelefon, Tablet, Laptop etc. Über das Mobilgerät kann mittels der Drahtlosverbindung über das Drahtlosmodul 24 der Sensor 5 konfiguriert und parametriert werden. Der Messumformer 20 wandelt die Rohmessdaten so, dass diese direkt an eine übergeordnete Einheit 30, also etwa das Leitsystem, weitergeleitet werden. Wie erwähnt können beispielsweise Daten in einem proprietären Protokoll vom Sensor 5 an das Anschlusselement 11 übertragen werden, während die Datenverarbeitungseinheit µCA dieses proprietäre Protokoll in ein Busprotokoll (Modbus, Foundation Fieldbus, HART, Profibus, EtherNet/IP; siehe oben) wandelt. Die Messumformer in den 3a und 3b haben im Wesentlichen die gleiche Grundfunktionalität.
-
Bezugszeichenliste
-
- 1
- Feldgerät
- 1'
- Abbild von 1
- 2
- Erster Kupplungskörper
- 3
- Erste physikalische Schnittstelle
- 4
- Sensorelement
- 5
- Sensor
- 10
- Sensoranordnung
- 11
- Anschlusselement
- 12
- Zweiter Kupplungskörper
- 13
- Zweite physikalische Schnittstelle
- 20
- Messumformer
- 21
- Kabel
- 22
- Display
- 23
- Bedienelemente
- 24
- Drahtlosmodul
- 30
- übergeordnete Einheit
- 31
- Kabel
- 50
- Interpreter
- 60
- feldgerätespezifische Software
- 70
- Host
- 71
- Speicher von 70
- A
- Anwender
- P
- Parametrierung
- µCA
- intelligente Einheit in 11
- µCS
- intelligente Einheit in 5
