-
Die
vorliegende Erfindung betrifft ein Verfahren zum Parametrieren eines Feldgerätes der
Prozessautomatisierungstechnik gemäß dem Oberbegriff des Anspruchs
1, ein Feldgerät
und einen Gerätetreiber für ein Feldgerät.
-
In
der Prozessautomatisierungstechnik werden vielfach Feldgeräte eingesetzt,
die zur Erfassung und/oder Beeinflussung von Prozessvariablen dienen.
Zur Erfassung von Prozessvariablen dienen Sensoren, wie beispielsweise
Füllstandsmessgeräte, Durchflussmessgeräte, Druck-
und Temperaturmessgeräte,
pH-Redoxpotentialmessgeräte,
LeiTfähigkeitsmessgeräte, etc.,
welche die entsprechenden Prozessvariablen Füllstand, Durchfluss, Druck,
Temperatur, pH-Wert bzw. Leitfähigkeit
erfassen. Zur Beeinflussung von Prozessvariablen dienen Aktoren, wie
zum Beispiel Ventile oder Pumpen, über die der Durchfluss einer
Flüssigkeit
in einem Rohrleitungsabschnitt bzw. der Füllstand in einem Behälter geändert werden
kann. Als Feldgeräte
werden im Prinzip alle Geräte
bezeichnet, die prozessnah eingesetzt werden und die prozessrelevante
Informationen liefern oder verarbeiten. Eine Vielzahl solcher Feldgeräte wird
von der Firma Endress + Hauser hergestellt und vertrieben.
-
In
modernen Industrieanlagen sind Feldgeräte in der Regel über Bussysteme
(Profibus®,
Foundation® Fieldbus,
HART®,
etc.) mit übergeordneten Einheiten
verbunden. Normalerweise handelt es sich bei den übergeordneten
Einheiten um Leitsysteme bzw. Steuereinheiten, wie beispielsweise
SPS (speicherprogrammierbare Steuerung) oder PLC (Programmable Logic
Controller). Die übergeordneten Einheiten
dienen unter anderem zur Prozesssteuerung, Prozessvisualisierung,
Prozessüberwachung sowie
zur Inbetriebnahme der Feldgeräte.
-
Zur
Bedienung von Feldgeräten,
insbesondere zur Parametrierung und Konfigurierung (im Folgenden
allgemein als „Parametrierung" bezeichnet) von
Feldgeräten,
ist in einer übergeordneten
Einheit in der Regel ein Bedienprogramm (Bedientool) vorgesehen.
Bei der Parametrierung eines Feldgerätes werden über solch ein Bedienprogramm
Parameter dieses Feldgerätes
eingestellt bzw. abgeändert.
Solche Para meter sind beispielsweise ein Messbereich, Grenzwerte,
Einheiten, etc.. Die übergeordnete
Einheit kann dabei direkt an dem Feldbus, an dem die betreffenden
Feldgeräte
angeschlossen sind, oder an einem übergeordneten Kommunikationsnetzwerk angeschlossen
sein. Daneben kann ein Feldgerät auch
durch ein Bediengerät,
wie beispielsweise durch einen tragbaren Personal-Computer (Laptop), ein
tragbares Handbediengerät
(Handheld), einen PDA (engl.: Personal Digital Assistant; deutsch:
Persönlicher
Digitaler Assistent), etc., auf dem ein Bedienprogramm implementiert
ist, parametriert werden. Solch ein Bediengerät kann über den Feldbus, an dem das
zu parametrierende Feldgerät
angeschlossen ist, oder direkt über
eine entsprechende, an dem Feldgerät vorgesehene Service-Schnittstelle
mit dem Feldgerät
kommunizieren.
-
Die
Parametrierungsdaten von Feldgeräten (selbst
bei gleichem Feldgerätetyp)
unterscheiden sich in der Regel je nach Prozess, in dem das betreffende
Feldgerät
eingesetzt wird, und je nach Einsatzort und Funktion des Feldgerätes in dem
betreffenden Prozess. In der Regel werden von einem Anlagenbetreiber
bzw. Benutzer Upload-Datensätze
der Parametrierungsdaten der einzelnen Feldgeräte erstellt und abgespeichert.
Solch ein Upload-Datensatz umfasst in der Regel die komplette Parametrierung eines
Feldgerätes
sowie Informationen zur Geräteidentität des Feldgerätes, insbesondere
dessen Feldgerätetyp
und dessen Version. Der „Upload-Datensatz" wird dabei aus dem
betreffenden Feldgerät
in einen hierfür
vorgesehenen Speicher geladen und dort gespeichert. Der Speicher
ist in der Regel in einer Rechnereinheit, insbesondere in einer übergeordneten
Einheit und/oder einem Bediengerät,
vorgesehen. Muss ein Feldgerät
von seinem Einsatzort entfernt werden, beispielsweise weil es extern
kalibriert oder repariert wird, so hat ein Benutzer häufig, um
einen Ausfall der Anlage zu vermeiden, ein Feldgerät des gleichen
Feldgerätetyps
auf Lager. Eine Parametrierung des neu einzusetzenden Feldgerätes erfolgt
dabei in der Regel derart, dass die in dem Upload-Datensatz des
bisher eingesetzten Feldgerätes
enthaltenen Parametrierungsdaten auf das neu einzusetzende Feldgerät geladen
werden. Dieser Vorgang wird als „Download" bezeichnet, da es sich um das Laden
von Daten von dem Speicher in der Rechnereinheit auf das Feldgerät handelt.
In der Regel wird auf die gleiche Weise vorgegangen, wenn ein bisher
eingesetztes Feldgerät
vollständig
durch ein neu einzusetzendes Feldgerät ersetzt werden soll.
-
Dabei
tritt häufig
der Fall auf, dass sich die Version des bisher eingesetzten Feldgerätes von
der Version des neu einzusetzenden Feldgerätes unterscheidet, insbesondere
dass unterschiedliche Softwareversionen bei den beiden Feldgeräten vorgesehen
sind. Solche unterschiedlichen Softwareversionen unterscheiden sich
in der Regel auch in der Parametrierung. Insbesondere sind bei neueren
Softwareversionen häufig
mehrere Parameter vorgesehen als bei älteren. Selbst bei Parametern,
die in beiden Softwareversionen vorgesehen sind, können sich
unter anderem deren Grenzwerte, Messbereiche, Einheiten, Datenumfang,
die Abhängigkeit
von einzelnen Parametern untereinander, etc., unterscheiden. Demnach
kann bei einem Download von Parametrierungsdaten, die sich auf eine
Softwareversion eines Feldgerätetyps
(im Folgenden: zweite Softwareversion) beziehen, in ein Feldgerät des gleichen
Feldgerätetyps
und einer anderen Softwareversion (im Folgenden: erste Softwareversion)
die Problematik auftreten, dass einige Parameterwerte nicht unmittelbar
oder direkt in die erste Softwareversion übernommen werden können. Insbesondere
ist dies dann der Fall, wenn ein Parameterwert der zweiten Softwareversion
einen in der ersten Softwareversion für diesen Parameter vorgesehenen
Grenzwert überschreitet,
wenn ein in der zweiten Softwareversion vorgesehener Parameter in
der ersten Softwareversion nicht existiert, oder wenn in der ersten
Softwareversion eine Abhängigkeit
von zwei Parametern vorgesehen ist, die bei den Parametrierungsdaten
der zweiten Softwareversion nicht erfüllt ist.
-
Zum
Teil ist die Gerätesoftware
von Feldgeräten
oder ein Bedienprogramm derart ausgelegt, dass eine Parametrierung
des Feldgerätes
mit Parametrierungsdaten einer älteren
Softwareversion möglich
ist. Da die älteren
Softwareversionen jeweils bekannt sind, können in diesem Fall entsprechende Algorithmen
implementiert werden, die eine fehlerhafte Parametrierung verhindern.
Die von den Algorithmen vorgenommenen Änderungen an den einzelnen
Parametern sind jedoch nicht transparent für den Benutzer. Ferner ist
es bisher nicht möglich,
eine fehlerfreie Parametrierung eines Feldgerätes mit Parametrierungsdaten
einer neueren Softwareversion zu garantieren. Grundsätzlich könnte zwar
vorgesehen sein, dass für
den Fall, dass ein Parameterwert der neueren (zweiten) Softwareversion
nicht in die ältere (erste)
Softwareversion übernommen
werden kann, für
diesen Parameter ein Default-Wert oder ein in dem betreffenden Feldgerät vorher
für diesen
Parameter gespeicherter und verwendeter Parameterwert (Revert-Wert)
verwendet wird. Dabei besteht jedoch ein Risiko, dass dieser Parameter
kritisch für
den Prozess, in dem das Feldgerät
eingesetzt wird, ist und sich die Änderung desselben (beispielsweise
auf einen Default-Wert
oder einen Revert-Wert) nachteilig auf den Prozess auswirkt. Um
solch ein Risiko zu vermeiden, ist die Gerätesoftware von Feldgeräten in der
Regel derart ausgebildet, dass sie immer dann, wenn ein Parameter
der zweiten Softwareversion nicht direkt in die erste Softwareversion übernehmbar
ist, das Laden der Parametrierungsdaten der zweiten Softwareversion
in das Feldgerät
blockiert. In diesem Fall muss der Benutzer die Parametrierung des
Feldgerätes
selbst durchführen,
was zeitaufwändiger
ist und mit einem längeren
Ausfall der Anlage verbunden sein kann.
-
Demgemäß besteht
die Aufgabe der vorliegenden Erfindung darin, ein Verfahren zum
Parametrieren eines Feldgerätes
der Prozessautomatisierungstechnik bereitzustellen, das transparent
für den Benutzer
ist und das eine schnelle Durchführung
der Parametrierung basierend auf bereits verfügbaren Parametrierungsdaten
ermöglicht.
-
Die
Aufgabe wird durch ein Verfahren gemäß Anspruch 1, durch einen Gerätetreiber
gemäß Anspruch
15 und durch ein Feldgerät
gemäß Anspruch 17
gelöst.
Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
-
Gemäß der vorliegenden
Erfindung wird ein Verfahren zum Parametrieren eines Feldgerätes der Prozessautomatisierungstechnik
einer ersten Softwareversion basierend auf Parametrierungsdaten, die
sich auf eine zweite Softwareversion desselben Feldgerätetyps beziehen,
bereitgestellt. In dem Verfahren werden die nachfolgenden Schritte
automatisiert durchgeführt:
Angeben zumindest der Parameter, deren Parameterwerte von der zweiten
Softwareversion nicht direkt in die erste Softwareversion übernehmbar
sind, sowie mindestens eines Parametrierungsvorschlages in Bezug
auf diese Parameter; und Bereitstellen zumindest einer Auswahlmöglichkeit
an den Benutzer dahingehend, ob die Parameterwerte gemäß dem Parametrierungsvorschlag
(in dem Feldgerät) übernommen
werden sollen.
-
Mit „Parametrieren" wird auch der Vorgang des „Konfigurierens", der in der Regel
ebenfalls durch Eingabe entsprechender Parameter durchgeführt wird,
umfasst. Unter „automatisiert" wird im vorliegenden
Fall verstanden, dass die betreffenden Schritte automatisch, ohne
menschliches Eingreifen, durchgeführt werden. Beispielsweise
können
die einzelnen Schritte durch eine oder mehrere Steuerungen durchgeführt werden.
-
Demgemäß können durch
das vorliegende Verfahren Parametrierungsdaten eines Feldgerätes einer
zweiten Softwareversion zum Parametrieren eines Feldgerätes einer
ersten Softwareversion verwendet werden. Dies ist insbesondere dann
vorteilhaft, wenn die zweite Softwareversion jünger als die erste Softwareversion
ist, es sich bei dem zu parametrierenden Feldgerät also um ein Feldgerät einer älteren Generation
handelt. Durch die Angabe der nicht direkt übernehmbaren Parameter und
zumindest eines Parametrierungsvorschlages in Bezug auf diese Parameter
ist das Verfahren transparent für
einen Benutzer. Insbesondere wird der Benutzer darüber informiert,
bei welchen der Parameter eine Änderung vorgenommen
werden muss. Stimmt der Benutzer den geänderten Parametern gemäß dem Parametrierungsvorschlag
zu, so kann das Parametrieren des Feldgerätes schnell und einfach durchgeführt werden.
Daneben besteht für
den Benutzer die Möglichkeit,
geänderte
Parameter gemäß dem Parametrierungsvorschlag,
deren Übernahme
er nicht wünscht,
abzulehnen. Gemäß der vorliegenden
Erfindung können
für einen
oder mehrere Parameter, die nicht direkt übernehmbar sind, auch mehrere Auswahlmöglichkeiten
bereitgestellt werden.
-
Bei
dem erfindungsgemäßen Verfahren
kann insbesondere vorgesehen sein, dass in Bezug auf einen Parameter,
der in der zweiten Softwareversion zusätzlich gegenüber der
ersten Softwareversion vorhanden ist, als Parametrierungsvorschlag
angegeben wird, dass dieser bei der Parametrierung weggelassen wird.
Ferner kann vorgesehen sein, dass in Bezug auf einen Parameter,
dessen Parameterwert gemäß der zweiten
Softwareversion nicht innerhalb eines gültigen Wertes oder Wertebereichs
der ersten Softwareversion liegt, ein hierfür vorgesehener Default-Wert
und/oder ein in dem Feldgerät
vorher unter diesem Parameter gespeicherter Wert (Revert-Wert) als
Parametrierungsvorschlag/Parametrierungsvorschläge angegeben wird/werden. Für die Bereitstellung
der Revert-Funktion müssen
die Parametrierungsdaten, die vorher in dem Feldgerät gespeichert und
verwendet wurden, zumindest bis zum Abschluss der Auswahl durch
den Benutzer gespeichert werden. Bestehen Abhängigkeiten einzelner Parameter
von jeweils anderen Parametern, so werden diese bei der Angabe eines
Parametrierungsvorschlages ebenfalls berücksichtigt. Beispielsweise kann
sich durch die Änderung
einer Einheit einer Messgröße auch
deren oberer Grenzwert entsprechend ändern.
-
Gemäß einer
vorteilhaften Weiterbildung wird dem Benutzer zumindest für die Parameter,
deren Parameterwerte von der zweiten Softwareversion nicht direkt
in die erste Softwareversion übernehmbar
sind, automatisiert eine Vergleichsdarstellung, insbesondere eine
Vergleichstabelle, in der die jeweiligen Parameterwerte gemäß der zweiten
Softwareversion und die jeweiligen Parameterwerte gemäß dem mindestens
einen Parametrierungsvorschlag gegenübergestellt werden, bereitgestellt.
Dann kann der Benutzer, vorzugsweise einzeln, in der Vergleichsdarstellung
auswählen,
ob der/die Parameterwert(e) gemäß dem mindestens
einen Parametrierungsvorschlag übernommen
werden sollen. Solch eine Vergleichsdarstellung kann insbesondere
mit Hilfe einer Vergleichs-Funktion (Compare-Funktion) erzeugt werden.
Vorzugsweise werden dabei sämtliche
Parameterwerte in einer Vergleichstabelle dargestellt, wobei die
nicht direkt übernehmbaren
Parameter hervorgehoben sind. Eine Hervorhebung kann dabei insbesondere
grafisch auf einer entsprechenden Anzeige erfolgen, so dass die
nicht direkt übernehmbaren
Parameter leicht erkennbar sind. Ferner besteht die Möglichkeit,
Parameter, die voneinander abhängig
sind, als solches zu kennzeichnen. Zusätzlich können bei den nicht direkt übernehmbaren
Parametern zusätzliche
Informationen (beispielsweise in der Vergleichsdarstellung) bereitgestellt
werden, die nähere
Details dazu angeben, warum der betreffende Parameterwert der zweiten
Softwareversion nicht in die erste Softwareversion übernehmbar
ist.
-
Gemäß einer
vorteilhaften Weiterbildung wird dem Benutzer bei dem Schritt des
Bereitstellens zumindest einer Auswahlmöglichkeit die Möglichkeit gegeben,
für mindestens
einen Parameter, dessen Parameterwert von der zweiten Softwareversion nicht
direkt in die erste Softwareversion übernehmbar ist, selbst einen
Parameterwert einzugeben. Daneben besteht die Möglichkeit, dem Benutzer diese Eingabemöglichkeit
auch für
die anderen Parameter, deren Parameterwerte in die erste Softwareversion übernehmbar
sind, zu geben. Bestehen Abhängigkeiten
bei den betreffenden, änderbaren
Parametern, so sind bei einer Änderung
durch den Benutzer auch die jeweiligen abhängigen Parameter entsprechend zu ändern.
-
Gemäß einer
vorteilhaften Weiterbildung wird das Parametrieren durch ein Bedienprogramm für Feldgeräte initiiert,
das auf einer mit dem Feldgerät
in Kommunikationsverbindung stehenden Rechnereinheit läuft. Vorzugsweise
kommunizieren die Rechnereinheit und das Feldgerät über einen Feldbus miteinander.
Dabei wird vorzugsweise ein standardisiertes Bussystem, wie beispielsweise
Profibus® (s.
Profibus® Profile
Specification, Version 3.0), Foundation® Fieldbus
(s. Foundation® Specification,
Function Block Application Process, Revision FS 1.7) oder HART® eingesetzt.
Die Kommunikation über
den Feldbus kann sowohl drahtgebunden als auch drahtlos, wie beispielsweise über Funk,
erfolgen. Das Bedienprogramm ist dabei derart ausgebildet, dass über dieses
zumindest eine Parametrierung des betreffenden Feldgerätes durchgeführt werden
kann. Daneben kann das Bedienprogramm auch noch weitere Funktionen,
wie beispielsweise Diagnosefunktionen, etc. umfassen. Die Rechnereinheit,
auf der das Bedienprogramm installiert ist, kann insbesondere ein
Bediengerät
oder eine übergeordnete
Einheit sein. Dabei ist unerheblich, auf welcher Ebene eines Feldbussystems
und/oder Netzwerksystems die betreffende übergeordnete Einheit vorgesehen
ist, sofern eine Kommunikation mit dem zu parametrierenden Feldgerät möglich ist.
Insbesondere kann es sich bei der übergeordneten Einheit um eine
direkt an dem Feldbus, an dem auch das zu parametrierende Feldgerät angeschlossen
ist, angeschlossene speicherprogrammierbare Steuerung (SPS), oder
auch um ein Leitsystem, das über
ein übergeordnetes
Firmennetzwerk (und ein entsprechendes Gateway) mit dem Feldbus
in Verbindung steht, handeln.
-
Gemäß einer
vorteilhaften Weiterbildung wird in dem Bedienprogramm ein virtuelles
Feldgerät,
welches die Parametrierungsfunktionalität des zu parametrierenden Feldgerätes aufweist,
geladen. Anschließend
werden in das virtuelle Feldgerät
die Parametrierungsdaten, die sich auf die zweite Softwareversion
beziehen, geladen. Daraus werden dann die Parameter, deren Parameterwerte
von der zweiten Software version nicht direkt in die erste Softwareversion übernehmbar
sind und vorzugsweise der mindestens eine Parametrierungsvorschlag
in Bezug auf diese Parameter ermittelt.
-
Als „virtuelles
Feldgerät" wird dabei eine
Darstellungsform eines realen, physischen Feldgerätes verstanden.
Insbesondere werden dabei die Daten und das Verhalten eines realen,
physischen Feldgerätes
derart durch eine entsprechende Software dargestellt, wie das reale,
physische Feldgerät
durch einen Kommunikationspartner „wahrgenommen" wird. Das virtuelle
Feldgerät
muss dabei auf dem Betriebssystem (z. B. Windows®) der
Rechnereinheit, auf der es geladen wird, lauffähig sein. Im vorliegenden Fall ist
nicht erforderlich, dass das in dem Bedienprogramm geladene virtuelle
Feldgerät
sämtliche
Daten und das gesamte Verhalten des zu parametrierenden Feldgerätes umfasst.
Vielmehr ist ausreichend, wenn das virtuelle Feldgerät zumindest
die Daten und das Verhalten des zu parametrierenden Feldgerätes aufweist,
die in Bezug auf eine Parametrierung desselben relevant sind. Diese
Parametrierungsfunktionalität
kann beispielsweise das Erzeugen einer entsprechenden Fehlermeldung
umfassen, falls ein Parameterwert von der zweiten Softwareversion
nicht direkt in die erste Softwareversion übernehmbar ist. Solch eine
Fehlermeldung kann dabei auch nähere
Details bezüglich
der Inkompatibilität
umfassen, wie beispielsweise die Angabe, dass der betreffende Parameter
in der ersten Softwareversion nicht vorhanden ist, dass durch den
betreffenden Parameterwert ein Grenzwert der ersten Softwareversion überschritten wird,
etc.. Ferner kann die Parametrierungsfunktionalität eines
Feldgerätes
auch die Bereitstellung von Default-Werten oder Revert-Werten in
Bezug auf Parameter, die nicht direkt in die erste Softwareversion übernehmbar
sind, umfassen.
-
Vorzugsweise
wird das virtuelle Feldgerät
in derselben Rechnereinheit wie das Bedienprogramm geladen und kommuniziert
mit dem Bedienprogramm über
entsprechende Kommunikationsschnittstellen. Alternativ ist jedoch
auch möglich,
das virtuelle Feldgerät
in einer Rechnereinheit zu laden, die getrennt von der Rechnereinheit
des Bedienprogramms angeordnet ist. In diesem Fall können ebenfalls
entsprechende Kommunikationsschnittstellen zwischen dem Bedienprogramm
und der Rechnereinheit vorgesehen werden. Während des Schrittes des Ladens
der Parametrie rungsdaten in das virtuelle Feldgerät können dann
beispielsweise durch das Bedienprogramm die in dem virtuellen Feldgerät erzeugten
Fehlermeldungen protokolliert werden. Ferner können gegebenenfalls die in
dem virtuellen Feldgerät
für die
betreffenden Parameter bereitgestellten Default-Werte und/oder Revert-Werte
an das Bedienprogramm kommuniziert werden. Basierend auf diesen
Informationen können
dann insbesondere die nicht direkt übernehmbaren Parameter sowie
der mindestens eine Parametrierungsvorschlag in Bezug auf diese Parameter
angegeben werden. Ferner kann das Bedienprogramm darauf basierend
einem Benutzer die mindestens eine Auswahlmöglichkeit bereitstellen.
-
Bei
einer Kommunikation des Bedienprogramms mit einem realen, physischen
Feldgerät über einen
Feldbus sind die über
den Feldbus übertragbaren
Informationen begrenzt. Insbesondere können über den Feldbus nur die Parameterwerte
gelesen werden, nicht jedoch deren Eigenschaften (Properties), wie
beispielsweise Messbereiche, Textbeschreibungen, wie z. B. „Volumenfluss", Formate, Einheiten
oder Auswahlmenüs.
Durch die Kommunikation zwischen dem Bedienprogramm und dem virtuellen
Feldgerät über entsprechende
Kommunikationsschnittstellen können
diese Kommunikationsschnittstellen derart konfiguriert werden, dass
darüber
detailliertere Informationen bezüglich
der Parametrierung übertragen
werden können,
als dies bei einer Kommunikation über den Feldbus möglich ist.
-
Ein
weiterer Vorteil dieser Weiterbildung besteht darin, dass eine weitgehende
Offline-Parametrierung des Feldgerätes vorgenommen werden kann. Das
heißt, über einen
Großteil
der Zeit des Parametrierungsvorganges findet keine Kommunikation
mit dem zu parametrierenden Feldgerät statt. Insbesondere werden
vorzugsweise die Parametrierungsdaten, die sich auf die zweite Softwareversion
beziehen, zunächst
nur in das virtuelle Feldgerät
geladen. Dabei können
die nicht direkt übernehmbaren
Parameter und der mindestens eine Parametrierungsvorschlag, wie
oberhalb erläutert
wurde, ermittelt werden. Erst nach „Genehmigung" durch den Benutzer werden
die (gegebenenfalls durch den Benutzer geänderten) Parametrierungsdaten
in das Feldgerät geladen.
Bis zu diesem Ladevorgang hat die Parametrierung keinen Einfluss
auf das zu parametrierende Feldgerät. Falls das Feldgerät im Einsatz
ist, kann folglich eine Unterbrechung des Prozessablaufs rduziert
oder voll ständig
vermieden werden.
-
Gemäß einer
vorteilhaften Weiterbildung weist das Bedienprogramm eine Rahmenapplikation, vorzugsweise
eine FDT-Rahmenapplikation (Field-Device-Tool-Rahmenapplikation), und mindestens eine
darin ausführbare
Softwarekomponente, vorzugsweise einen Feldgerät-DTM (Feldgerät-Device-Type-Manager),
die/der dem zu parametrierenden Feldgerät zugeordnet ist und Bedienfunktionalitäten desselben
kapselt, auf, wobei über
das Bedienprogramm eine dynamisch bindende Bibliotheksdatei, vorzugsweise
eine DLL-Datei (Dynamic-Link-Library-Datei), durch die das virtuelle
Feldgerät
dargestellt (bzw. emuliert) wird, geladen wird.
-
Ein
DTM (Device Type Manager) ist eine gerätespezifische Software, die
Daten und Funktionen des betreffenden Feldgerätes kapselt und gleichzeitig
grafische Bedienelemente bereitstellt. Insbesondere stellen DTMs
Funktionen zum Zugang zu Variablen des Feldgerätes, zum Parametrieren und
Betreiben des Feldgerätes
und Diagnosefunktionen bereit. Die DTMs sind alleine nicht lauffähig. Als
Laufzeitumgebung dient eine dem FDT-Standard entsprechende Rahmenapplikation,
wie beispielsweise das Bedienprogramm „FieldCare®" von Endress + Hauser.
Die FDT-Spezifikation ist beispielsweise über die FDT-Group erhältlich.
Neben einer FDT-Rahmenapplikation kann auch eine andere Rahmenapplikation,
wie beispielsweise eine TCI-Rahmenapplikation
(Tool-Calling-Interface-Rahmenapplikation), und eine entsprechende,
darin ausführbare
Softwarekomponente eingesetzt werden. In einer TCI-Rahmenapplikation
sind die Schnittstellen nicht so strikt festgelegt, wie dies bei
dem FDT-Standard der Fall ist.
-
Die
Bereitstellung von Feldgerät-DTMs
ist für den
Feldgerätehersteller
mit einem erheblichen Aufwand verbunden. Wird die Gerätesoftware
eines Feldgerätes
geändert,
so muss in der Regel auch der zugehörige Feldgerät-DTM umgeschrieben
werden. Nach der Fertigstellung müssen die Feldgerät-DTMs aufwendig
getestet werden, um sicherzustellen, dass sie korrekt funktionieren.
Um den Aufwand für
die Herstellung von Feldgerät-DTMs
zu reduzieren, werden Feldgerät-DTMs
häufig
auf der Basis von bereits vorhandenen Gerätebeschreibungen (DD; engl.:
Device Descriptions), insbesondere von HART® DDs
erstellt. Durch solche Gerätebeschreibungen
können jedoch
nicht komplexe Funktionalitäten
beschrieben werden. Solche komplexen Funktionalitäten müssen dann
im Rahmen einer Überarbeitung
in den Feldgerät-DTMs ergänzt werden.
-
Eine
dynamisch bindende Bibliotheksdatei ist im Unterschied zu einem
Programm keine eigenständig
lauffähige
Einheit sondern ein Hilfsmodul, das einem oder mehreren Programm(en)
zur Verfügung
gestellt wird. Die dynamisch bindende Bibliotheksdatei wird bei
Bedarf in einen Arbeitsspeicher geladen und durch einen sogenannten „Lader" mit dem ausführenden
Programm verbunden. In dem Betriebssystem Windows® wird
eine dynamisch bindende Bibliotheksdatei beispielsweise als DLL
(Dynamic Link Library) bezeichnet, während in den Unix-artigen Betriebssystemen
die Bezeichnung „shared
library" gebräuchlich
ist. Ein Vorteil, das virtuelle Feldgerät durch eine dynamisch bindende
Bibliotheksdatei darzustellen, besteht darin, dass die dynamisch
bindende Bibliotheksdatei unabhängig vom
ausführenden
Programm (beispielsweise ein Feldgerät-DTM, der wiederum über das
Bedienprogramm aufgerufen wird) einfach geändert werden kann. Ferner kann
solch eine dynamisch bindende Bibliotheksdatei auch in bestehende
Systeme aufgenommen werden, so dass eine Aufrüstung einfach möglich ist.
-
Gemäß einer
vorteilhaften Weiterbildung weist die Softwarekomponente, insbesondere
der Feldgerät-DTM,
die/der dem zu parametrierenden Feldgerät zugeordnet ist, die dynamisch
bindende Bibliotheksdatei, durch die das virtuelle Feldgerät dargestellt
wird, auf und die dynamisch bindende Bibliotheksdatei wird über diese
Softwarekomponente geladen. Alternativ dazu kann vorgesehen sein,
dass eine Softwarekomponente, die einem Feldgerät des gleichen Feldgerätetyps und
der zweiten Softwareversion zugeordnet ist, die dynamisch bindende
Bibliotheksdatei, durch die das virtuelle Feldgerät dargestellt
wird, aufweist und dass die dynamisch bindende Bibliotheksdatei über diese
Softwarekomponente geladen wird. In beiden Fällen weist das virtuelle Feldgerät jeweils
die Parametrierungsfunktionalität des
zu parametrierenden Feldgerätes
(der ersten Softwareversion) auf. Ist die zweite Softwareversion jünger als
die erste Softwareversion, so weist bei der zweiten Variante eine
Softwarekomponente, die einem Feldgerät einer neueren (hier: zweiten)
Softwareversion zugeordnet ist, eine oder mehrere dynamisch bindende
Bibliotheksdatei(en) auf, durch die jeweils ein virtuelles Feldgerät einer älteren (hier:
ersten) Softwareversion dargestellt wird. Diese zweite Variante
hat den Vorteil, dass beim Erstellen von der Softwarekomponente
sämtliche
Informationen bezüglich
der aktuellsten Softwareversion (hier: der zweiten Softwareversion)
und sämtlicher älteren Softwareversionen
(hier: insbesondere der ersten Softwareversion) vorliegen. Demgemäß können bei dem/den
virtuellen Feldgerät(en)
der älteren
Softwareversionen (hier: der ersten Softwareversion) und/oder in
der zugehörigen
Softwarekomponente geeignete Algorithmen und Parametrierungsvorschläge für die Fälle, in
denen ein Parameter nicht direkt übernehmbar ist, vorgesehen
werden. Bei der ersten Variante müssten solche Algorithmen, welche die
Kenntnis der neueren Softwareversion(en) voraussetzen, durch nachträgliche Updates
der dynamisch bindenden Bibliotheksdatei, durch die das virtuelle
Feldgerät
dargestellt wird, ergänzt
werden.
-
Gemäß einer
vorteilhaften Weiterbildung wird das virtuelle Feldgerät zumindest
teilweise aus einem Programmcode einer Gerätesoftware des zu parametrierenden
Feldgerätes
erzeugt. Die entsprechende dynamisch bindende Bibliotheksdatei,
durch die das virtuelle Feldgerät
vorzugsweise dargestellt wird, kann durch einen entsprechenden Compiler
gewonnen werden. Dadurch kann auf einfache Weise sichergestellt
werden, dass das virtuelle Feldgerät die gleiche Parametrierungsfunktionalität wie das
zu parametrierende Feldgerät
aufweist. Ferner entfällt ein
zusätzlicher
Entwicklungs- und Testaufwand für die
Erstellung der dynamisch bindenden Bibliotheksdatei, wie dies für die Entwicklung
und das Testen eines entsprechend ausgebildeten Feldgerät-DTMs erforderlich
wäre.
-
Gemäß einer
vorteilhaften Weiterbildung werden nach dem Schritt des Bereitstellens
zumindest einer Auswahlmöglichkeit
an den Benutzer der Auswahl des Benutzers entsprechende Parametrierungsdaten
in dem Bedienprogramm erstellt und in das zu parametrierende Feldgerät geladen.
Vorzugsweise wird nach der Auswahl des Benutzers (und gegebenenfalls
nach einer Änderung
durch den Benutzer) durch das Bedienprogramm ein Upload-Datensatz
der (gegebenenfalls geänderten)
Parametrierungsdaten des virtuellen Feldgerätes erstellt und dieser in
das Feldgerät
geladen. Das Laden in das Feldgerät erfolgt dabei vorzugsweise über den
Feldbus, an dem das Feldgerät
angeschlossen ist. Bis zur tatsächlichen
Durchführung
des Ladevorganges kann die Parametrierung offline durchgeführt werden.
-
Als
Alternative zu der oberhalb erläuterten Verwendung
eines virtuellen Feldgerätes
in dem Bedienprogramm werden gemäß einer
vorteilhaften Weiterbildung bei dem erfindungsgemäßen Verfahren
die nachfolgenden Schritte durchgeführt: Laden der Parametrierungsdaten,
die sich auf die zweite Softwareversion desselben Feldgerätetyps beziehen,
in das zu parametrierende Feldgerät der ersten Softwareversion,
wobei eine Gerätesoftware
des zu parametrierenden Feldgerätes
derart ausgebildet ist, dass durch diese nach dem Laden der Schritt
des Angebens zumindest der Parameter, deren Parameterwerte von der
zweiten Softwareversion nicht direkt in die erste Softwareversion übernehmbar
sind, sowie mindestens eines Parametrierungsvorschlages in Bezug
auf diese Parameter durchgeführt
wird. Im Gegensatz zu der oberhalb erläuterten Bereitstellung des
virtuellen Feldgerätes
wird dieses Verfahren weitgehend online, d. h. unter Durchführung einer Kommunikation
zwischen dem Bedienprogramm auf der Rechnereinheit und dem zu parametrierenden Feldgerät, durchgeführt. Ferner
ist bei dieser Variante die Gerätesoftware
des zu parametrierenden Feldgerätes
entsprechend erweitert gegenüber
der Gerätesoftware
herkömmlicher
Feldgeräte.
Dadurch sind in dem Feldgerät
ein erhöhter
ROM-Speicherbedarf und
eine höhere
Prozessorleistung als bei herkömmlichen
Feldgeräten
erforderlich. Insbesondere bei solchen Feldgeräten, die für einen Anschluss an ein Foundation®-Fieldbus-Bussystem
optimiert sind und/oder die als modulare 4-Leiter-Feldgeräte ausgebildet sind, sind in
der Regel ausreichend hohe Prozessorleistungen und ein ausreichender ROM-Speicher
vorhanden, so dass diese Feldgeräte besonders
gut für
ein Verfahren gemäß dieser
Weiterbildung geeignet sind.
-
Insbesondere
sind bei dieser Weiterbildung in der Gerätesoftware entsprechende Algorithmen implementiert,
durch die in dem Fall, in dem ein Parameterwert der zweiten Softwareversion
nicht direkt in die erste Softwareversion übernehmbar ist, entsprechende
Abfangmechanismen vorgesehen werden. Insbesondere können durch
die Algorithmen die oberhalb erläuterten
Abfangmechanismen und Parametrierungsvorschläge, wie beispielsweise das
Weglassen oder Ausklammern zusätzlicher Parameter, das
Bereitstellen eines Revert-Wertes oder Default-Wertes, etc., bereitgestellt
werden.
-
Gemäß einer
vorteilhaften Weiterbildung werden die Parametrierungsdaten, die
sich auf die zweite Softwareversion beziehen, bei dem Vorgang des
Ladens in einen Speicher des zu parametrierenden Feldgerätes geladen,
nicht aber direkt als Parameterwerte des zu parametrierenden Feldgerätes übernommen.
Dies hat den Vorteil, dass ein Teil der Schritte der Parametrierung,
insbesondere das Ermitteln der nicht direkt übernehmbaren Parameter und
der zugehörigen
Parametrierungsvorschläge
sowie gegebenenfalls die Berücksichtigung
von Änderungen
von Parametern durch den Benutzer, durchgeführt werden können, ohne
dass sich die tatsächlichen
Parametereinstellungen des Feldgerätes ändern. Dadurch können weitgehend
die Vorteile erzielt werden, die bei der oberhalb erläuterten
Offline-Durchführung
dieser Schritte (bei dem virtuellen Feldgerät) erzielt werden. Insbesondere
kann das Feldgerät
während
dieser Zeit an dem Prozess angeschlossen bleiben und mit den in
dem Feldgerät
bisher eingestellten Parameterwerten arbeiten.
-
Alternativ
hierzu können
die Parametrierungsdaten, die sich auf die zweite Softwareversion beziehen,
auch direkt als Parameterwerte des Feldgerätes übernommen werden. In diesem
Fall entspricht der Parametrierungsvorschlag bereits den in dem
Feldgerät
eingestellten Parameterwerten. Dennoch wird einem Benutzer die erfindungsgemäße Auswahlmöglichkeit
und gegebenenfalls auch eine Änderungsmöglichkeit
in Bezug auf die nicht direkt übernehmbaren
Parameter bereitgestellt, so dass deren Parameterwerte gegebenenfalls
nochmals entsprechend der Auswahl (bzw. Änderung) des Benutzers geändert werden.
Insbesondere dann, wenn in dem Feldgerät nicht ausreichend Speicherplatz
für die
oberhalb erläuterte,
zusätzliche
Abspeicherung der Parametrierungsdaten zur Verfügung steht, ist diese Alternative
relevant.
-
Gemäß einer
vorteilhaften Weiterbildung wird vor Übernahme der Parameterwerte
der Parametrierungsdaten, die sich auf die zweite Softwareversion
desselben Feldgerätetyps
beziehen, eine Sicherungskopie der bisherigen Parameterwerte des zu
parametrierenden Feldgerätes
erstellt. Die Sicherungskopie kann beispielsweise durch die Gerätesoftware
des Feldgerätes
erstellt werden und in einem Speicher des Feldgerätes gespeichert
werden. Ist in dem Feldgerät
selbst nicht ausreichend Speicherplatz für solch eine Sicherungskopie,
so kann diese auch durch das Bedienprogramm von dem Feldgerät angefordert
und in einem Speicher (bspw. der Rechnereinheit) gespeichert werden.
-
Gemäß einer
vorteilhaften Weiterbildung erfolgt der Schritt des Angebens der
nicht direkt übernehmbaren
Parameter und des mindestens einen Parametrierungsvorschlages dadurch,
dass die Gerätesoftware
eine entsprechende Nachricht an das Bedienprogramm auf der Rechnereinheit
sendet. Das Bedienprogramm ist dabei derart ausgebildet, dass durch
dieses eine entsprechende Angabe an einen Benutzer weitergegeben
wird und der Schritt des Bereitstellens zumindest einer Auswahlmöglichkeit durchgeführt wird. Über das
Bedienprogramm kann ein Benutzer vorzugsweise die in der Auswahlmöglichkeit
bereitgestellten Alternativen auswählen und gegebenenfalls noch
weitere Änderungen
der Parameterwerte vornehmen. Vorzugsweise werden anschließend von
dem Bedienprogramm an das Feldgerät der Auswahl des Benutzers
entsprechende Anweisungen erteilt, ob und gegebenenfalls wie einzelne
Parameter der Parametrierungsdaten, die sich auf die zweite Softwareversion
beziehen, zu ändern
sind. Sind die Parametrierungsdaten vorerst nur in einem Speicher
des Feldgerätes
abgespeichert, so kann das Bedienprogramm ferner einen entsprechenden Befehl
zur Übernahme
der Parametrierungsdaten aus dem Speicher geben.
-
Bei
der vorliegenden Variante mit der erweiterten Gerätesoftware
wird ein Teil des erfindungsgemäßen Verfahrens
durch die Gerätesoftware
in dem Feldgerät
durchgeführt.
Dadurch müssen
Informationen bezüglich
des Parametrierungsvorganges, wie beispielsweise Fehlermeldungen,
dass ein Parameterwert nicht direkt übernehmbar ist, zwischen dem Feldgerät und dem
Bedienprogramm (in der Rechnereinheit) über den Feldbus (oder eine
Service-Schnittstelle) kommuniziert werden. Diese Kommunikationsmöglichkeiten
sind in der Regel eingeschränkter
als bei der oberhalb erläuterten
Kommunikation zwischen dem Bedienprogramm und dem virtuellen Feldgerät. Insbesondere
dann, wenn das Bedienprogramm ausschließlich auf einer Gerätebeschreibung
(DD) basiert und einen entsprechenden Interpreter aufweist, sind
die Möglichkeiten
der Kommunikation detaillierter Informationen bezüglich der Inkompatibilität einzelner
Parameter, der Änderungsmöglichkeiten
einzelner Parameter durch einen Benutzer, etc. beschränkt. Ferner
tritt teilweise das Problem auf, dass sich die Interpretation ein-
und derselben Fehlermeldung durch Bedienprogramme unterschiedlicher
Hersteller unterscheiden kann.
-
Gemäß einer
vorteilhaften Weiterbildung weist das Bedienprogramm eine Rahmenapplikation, vorzugsweise
eine FDT-Rahmenapplikation (Field-Device-Tool-Rahmenapplikation), und mindestens eine
darin ausführbare
Softwarekomponente, vorzugsweise einen Feldgerät-DTM (Feldgerät-Device-Type-Manager),
die/der dem zu parametrierenden Feldgerät zugeordnet ist und Bedienfunktionalitäten desselben
kapselt, auf. Gegenüber
der oberhalb erläuterten,
ausschließlich
auf einer Gerätebeschreibung
basierenden Variante können
hier durch die Bereitstellung des Feldgerät-DTM und einer FDT-Rahmenapplikation
wesentlich detailliertere Informationen bezüglich der Parametrierung ausgetauscht
werden. Ferner kann eine Vergleichsdarstellung der nicht direkt übernehmbaren
Parameterwerte und des mindestens einen Parametrierungsvorschlages
und/oder die Bereitstellung einer Änderungsmöglichkeit einzelner Parameter
auf einfache Weise realisiert werden. Im Wesentlichen die gleichen
Vorteile werden erzielt, wenn anstelle der FDT-Rahmenapplikation
die oberhalb erläuterte
TCI-Rahmenapplikation und eine entsprechende, darin ausführbare Softwarekomponente
verwendet werden.
-
Die
oberhalb in Bezug auf das erfindungsgemäße Verfahren erläuterten
Vorteile und Weiterbildungen sind in entsprechender Weise auch bei
dem erfindungsgemäßen Gerätetreiber
für ein
Feldgerät der
Prozessautomatisierungstechnik und dem erfindungsgemäßen Feldgerät der Prozessautomatisierungstechnik
realisierbar.
-
Weitere
Vorteile und Zweckmäßigkeiten
der Erfindung ergeben sich anhand der nachfolgenden Beschreibung
von Ausführungsbeispielen
unter Bezugnahme auf die beigefügten
Figuren. Von den Figuren zeigen:
-
1:
eine schematische Darstellung eines einfachen Feldbus-Netzwerkes;
-
2:
eine schematische Darstellung einer Rechnereinheit, auf der ein
Bedienprogramm läuft, und
eines zu parametrierenden Feldgerätes gemäß einer Ausführungsform
der vorliegenden Erfindung;
-
3:
eine schematische Darstellung einer Rechnereinheit, auf der ein
Bedienprogramm läuft, und
ein zu parametrierendes Feldgerät
gemäß einer weiteren
Ausführungsform
der vorliegenden Erfindung; und
-
4:
eine schematische Darstellung der Erzeugung einer Gerätesoftware
eines Feldgerätes und
einer dynamisch bindenden Bibliotheksdatei aus einem gemeinsamen
Programmcode.
-
1 ist
eine beispielhafte, schematische Darstellung eines einfachen Feldbus-Netzwerkes, bei dem
vier Feldgeräte
FG0, FG1, FG2 und FG3, ein Bediengerät B und eine Steuereinheit
SPS an einem Feldbus F angeschlossen sind. Der Feldbus F arbeitet
nach einem der bekannten Feldbus-Standards von Profibus® (DP,
PA oder FMS). Die Steuereinheit SPS ist ein Profibus-Master, während die
Feldgeräte FG0,
FG1, FG2 und FG3 Profibus-Slaves sind. Die Kommunikation zwischen
der Steuereinheit SPS und den Feldgeräten FG0, FG1, FG2 und FG3 erfolgt nach
dem Profibus® Standard.
Auch das Bediengerät B
kommuniziert mit einem zu parametrierenden Feldgerät über den
Feldbus F nach dem Profibus® Standard.
-
In 2 ist
eine Rechnereinheit 2, insbesondere ein Personal-Computer,
dargestellt, auf dem ein Bedienprogramm 4 installiert ist. 2 betrifft
eine Ausführungsform,
in der die Bedienung von Feldgeräten über das
Bedienprogramm 4 basierend auf Gerätebeschreibungen (DD) der betreffenden
Feldgeräte
erfolgt. Das Bedienprogramm 4 ist mit einem ersten Speicher 6,
der Gerätebeschreibungen
(DD) für verschiedene
Feldgeräte
zur Verfügung
stellt, und einem zweiten Speicher 8 zum Abspeichern von
Parameterwerten von Feldgeräten
verbunden. Das Bedienprogramm 4 weist einen Interpreter 10 auf,
der Informationen aus dem ersten Speicher 6 ausliest und sie
basierend auf der jeweiligen Gerätebeschreibungssprache
(z. B. HART®-DDL,
d. h. HART®-Device-Description-Language)
entschlüsselt.
Zur Kommunikation über
einen Feldbus weist die Rechnereinheit 2 einen COM-Port 12 auf.
Dieser ist über
ein (nicht dargestelltes) HART®-Modem mit einem HART®-Feldbus 14 verbunden.
An dem HART®-Feldbus 14 sind
mehrere Feldgeräte
angeschlossen, von denen in 1 beispielhaft
ein Feldgerät 16 dargestellt
ist. Das Feldgerät 16 weist
einen Feldgerät-Speicher 18 und
eine auf dem Feldgerät 16 implementierte
Gerätesoftware 20 einer
ersten Softwareversion auf.
-
Im
Folgenden wird ein erstes Verfahren zum Parametrieren des Feldgerätes 16 über das
Bedienprogramm 4 beschrieben. Dabei soll das Feldgerät 16 mit
Parametrierungsdaten, die als Upload-Datensatz von einem anderen
(nicht dargestellten) Feldgerät
des gleichen Feldgerätetyps
und einer zweiten Softwareversion in dem zweiten Speicher 8 der Rechnereinheit 2 gespeichert
wurden, parametriert werden. Die zweite Softwareversion ist dabei
jünger als
die erste Softwareversion. Neben den eigentlichen Parameterwerten
der verschiedenen Parameter umfassen die Parametrierungsdaten auch
Informationen zur Geräteidentität des zugehörigen Feldgerätes, insbesondere
dessen Feldgerätetyp
und dessen Version. Als erster Schritt werden die Parametrierungsdaten,
die sich auf die zweite Softwareversion beziehen, durch das Bedienprogramm 4 von der
Rechnereinheit 2 in das Feldgerät 16 geladen. Die
Gerätesoftware 20 des
Feldgerätes 16 erkennt anhand
der in den Parametrierungsdaten enthaltenen Informationen zur Geräteidentität, dass
sich die Parametrierungsdaten auf eine andere Softwareversion als
diejenige des Feldgerätes 16 beziehen.
Um eine fehlerhafte Parametrierung des Feldgerätes 16 zu vermeiden,
werden die erhaltenen Parametrierungsdaten vorerst nur in dem Feldgerät-Speicher 18 gespeichert.
Das Feldgerät 16 kann
dadurch mit den bisher eingestellten Parameterdaten am Prozess angeschlossen
bleiben.
-
Die
Gerätesoftware 20 ist
derart ausgebildet, dass sie im Folgenden die Parameter der erhaltenen Parametrierungsdaten
ermittelt, deren Parameterwerte nicht direkt in die erste Softwareversion
des Feldgerätes 16 übernehmbar
sind. Ferner ist die Gerätesoftware 20 derart
ausgebildet, dass sie einen Parametrierungsvorschlag in Bezug auf
diese Parameter erstellt. In dem Parametrierungsvorschlag werden
beispielsweise Parameter, die in der zweiten Softwareversion zusätzlich gegenüber der
ersten Softwareversion sind, ausgeklammert. Für Parameter, die nicht übernehmbar
sind, weil sie beispielsweise einen in der ersten Softwareversion
vorgesehenen Grenzwert überschreiten,
wird als Parametrierungsvorschlag ein in dem Feldgerät 16 vorgese hener
Default-Wert und/oder ein bisher in dem Feldgerät vorgesehener Revert-Wert
(des betreffenden Parameters) vorgeschlagen.
-
Als
nächster
Schritt übersendet
das Feldgerät 16 eine
entsprechende Nachricht an das Bedienprogramm 4 in der
Rechnereinheit 2. Die an das Bedienprogramm 4 übermittelbaren
Informationen werden dabei durch die verfügbaren Möglichkeiten der Gerätebeschreibung
(DD), der verwendeten Gerätebeschreibungssprache
und des jeweiligen Bedienprogramms 4 bestimmt bzw. begrenzt.
In dem Bedienprogramm 4 wird anschließend die erhaltene Nachricht
basierend auf der Gerätebeschreibung
des Feldgerätes 16 interpretiert
und dem Benutzer die Informationen bezüglich der nicht direkt übernehmbaren
Parameter und des mindestens einen Parametrierungsvorschlages übermittelt.
Stimmt der Benutzer dem mindestens einen Parametrierungsvorschlag
zu, so wird eine entsprechende Nachricht an das Feldgerät 16 gesendet.
Als nächsten
Schritt greift die Gerätesoftware 20 des
Feldgerätes 16 auf die
in dem Speicher 18 gespeicherten Parametrierungsdaten gemäß dem Parametrierungsvorschlag zu
und übernimmt
diese als Parameterwerte für
das Feldgerät 16.
Lehnt der Benutzer den Parametrierungsvorschlag ab, so wird gemäß der vorliegenden Ausführungsform
das Feldgerät 16 vorerst
mit dessen bisherigen Parameterwerten betrieben. Der Benutzer kann
dann beispielsweise selbst eine Parametrierung des Feldgerätes ohne
Verwendung der bereits verfügbaren
Parametrierungsdaten, die sich auf die zweite Softwareversion beziehen,
durchführen.
-
Im
Folgenden wird ein zweites Verfahren zum Parametrieren des Feldgerätes 16 unter
Bezugnahme auf 2 erläutert, wobei vorwiegend auf
die Unterschiede gegenüber
dem ersten Verfahren eingegangen wird. Dieses zweite Verfahren kann
insbesondere dann angewendet werden, wenn der Feldgerät-Speicher 18 nicht
ausreichend groß ist,
um die von dem Bedienprogramm 4 erhaltenen Parametrierungsdaten
vorab parallel zu den bisherigen Parametrierungsdaten des Feldgerätes 16 zu
speichern. Im Unterschied zu dem ersten Verfahren fordert das Bedienprogramm 4,
vor dem Schritt des Ladens der Parametrierungsdaten von der Rechnereinheit 2 auf das
Feldgerät 16,
das Feldgerät 16 auf,
dessen bisherige Parametrierungsdaten an die Rechnereinheit 4 zu übermitteln.
Die bisherigen Parametrierungsdaten werden dann in dem zweiten Speicher 8 der Rechnereinheit 2 als
Sicherungskopie gespei chert. Anschließend werden die „neuen" Parametrierungsdaten,
die sich auf die zweite Softwareversion beziehen, in das Feldgerät 16 geladen
und direkt als neue Parameterwerte des Feldgerätes 16 übernommen. Für Parameter,
deren Parameterwerte nicht direkt in die erste Softwareversion des
Feldgerätes 16 übernehmbar
sind, werden die Parameterwerte übernommen,
die beispielsweise in dem Parametrierungsvorschlag bei dem ersten
Verfahren angegeben werden. Bei dem zweiten Verfahren werden folglich
die Parametereinstellungen des Feldgerätes 16 direkt geändert, so
dass sich die Änderungen
auch direkt auf einen Prozess auswirken, falls das Feldgerät an einem Prozess
angeschlossen ist. Wie bei dem ersten Verfahren sendet das Feldgerät 16 eine
entsprechende Nachricht an das Bedienprogramm 4 und der
Benutzer kann dann wiederum auswählen,
ob er dem Parametrierungsvorschlag zustimmt. Stimmt der Benutzer
zu, so bleiben die bereits übernommenen
Parametrierungsdaten in dem Feldgerät 16 als Parameterwerte
eingestellt. Lehnt der Benutzer den Parametrierungsvorschlag ab,
so können
die Parametrierungsdaten, die als Sicherungskopie in der Rechnereinheit 2 gespeichert
wurden, zurück
in das Feldgerät 16 geladen
und wieder als Parameterwerte in dem Feldgerät 16 übernommen
werden.
-
Im
Folgenden wird unter Bezugnahme auf 3 ein drittes
Verfahren zum Parametrieren eines Feldgerätes 22 über ein
Bedienprogramm 24, das auf einer Rechnereinheit 26 implementiert
ist, beschrieben. Es wird hierbei vorwiegend auf die Unterschiede gegenüber dem
ersten Verfahren eingegangen. Die Rechnereinheit 26 ist über eine
Feldbus-Schnittstelle 27 und einen Feldbus 28 mit
dem Feldgerät 22 verbunden.
Das Feldgerät 22 weist
eine Gerätesoftware 30 und
einen Feldgerät-Speicher 32 auf.
Das Bedienprogramm 24 umfasst eine auf der Rechnereinheit 26 laufende
FDT-Rahmenapplikation 34, die über definierte FDT-Schnittstellen 36 mit
Feldgerät-DTMs,
die beispielhaft durch die beiden Feldgerät-DTMs 38, 40 dargestellt
sind, kommuniziert. Der Feldgerät-DTM 38 ist
dabei dem Feldgerät 22 zugeordnet
und kapselt dessen Bedienfunktionalität. Weitere Feldgerät-DTMs sind
in entsprechender Weise für
(nicht dargestellte) weitere Feldgeräte, die an dem Feldbus 28 angeschlossen
sind, vorgesehen. Aus Gründen der Übersichtlichkeit
sind nur die Kommunikationswege zwischen der Rahmenapplikation 34 und
dem Feldgerät-DTM 38 des
Feldgerätes 22 dargestellt. Über die
Rahmenapplikation 34 wird unter ande rem das Starten und
Verwalten von Anwendungen (Client Applications), das Speichern und
Laden von Projektdaten aus einem Projektdatenspeicher 42 und
das Parametrieren der an dem Feldbus 28 angeschlossenen
Feldgeräte
durchgeführt.
-
Eine
Kommunikation zwischen dem Feldgerät-DTM 38 und dem zugehörgen Feldgerät 22 erfolgt über einen
Kommunikations-DTM 44 (sowie eine entsprechende FDT-Schnittstelle und
die Feldbus-Schnittstelle 27). Der Feldgerät-DTM 38 weist eine
DLL-Datei 46 auf, durch die ein virtuelles Feldgerät, das dem
realen Feldgerät 22 nachgebildet
ist und dessen Parametrierungsfunktionalität aufweist, dargestellt bzw.
emuliert wird. Die DLL-Datei 46 wird über den zugehörigen Feldgerät-DTM 38 geladen. Die
weiteren Feldgerät-DTMs
des Bedienprogramms 24 sind vorzugsweise in entsprechender
Weise ausgebildet. Ferner können
die einzelnen Feldgerät-DTMs 38, 40 auf
einen den Feldgerät-DTMs
zugeordneten Speicher 48 zugreifen, in dem Upload-Datensätze der
verschiedenen, an dem Feldbus 28 angeschlossenen Feldgeräte gespeichert
sind.
-
Im
Folgenden soll, ähnlich
wie bei dem ersten Verfahren, das Feldgerät 22 mit Parametrierungsdaten,
die als Upload-Datensatz von einem anderen (nicht dargestellten)
Feldgerät
des gleichen Feldgerätetyps
und einer zweiten Softwareversion in dem Speicher 48 der
Rechnereinheit 26 gespeichert wurden, parametriert werden.
Für die
Parametrierung des Feldgerätes 22 muss
der zugehörige
Feldgerät-DTM 38 durch
die FDT-Rahmenapplikation 34 instanziiert werden. Nach
der Instanziierung stellt der Feldgerät-DTM 38 dem Benutzer
eine graphische Bedienoberfläche
(graphical user interface) und die Geschäftslogik (business logic) des
Feldgerätes 22 zur
Verfügung. Über den
Feldgerät-DTM 38 wird
die DLL-Datei 46 und damit das virtuelle Feldgerät geladen.
Anschließend
greift der Feldgerät-DTM 38 auf den
Speicher 48 zu und lädt
die Parametrierungsdaten, die sich auf die zweite Softwareversion
beziehen, in das virtuelle Feldgerät. Bei Parametern, deren Parameterwerte
nicht direkt in das virtuelle Feldgerät übernehmbar sind, werden durch
das virtuelle Feldgerät
entsprechende Fehlermeldungen erzeugt. Diese Fehlermeldungen werden
durch den Feldgerät-DTM 38 protokolliert
und analysiert. Das virtuelle Feldgerät und/oder der Feldgerät-DTM 38 sind
dabei derart ausgebildet, dass sie für nicht direkt übernehmbare
Parameterwerte einen (oder mehrere) Parametrierungsvor schlag/Parametrierungsvorschläge ermitteln.
Die Parametrierungsvorschläge
können dabei
so wie bei dem ersten Verfahren vorgesehen sein.
-
Als
nächster
Schritt wird ein Upload-Datensatz der in dem virtuellen Feldgerät vorgesehenen Parametrierungsdaten
mit den entsprechenden Parametrierungsvorschlägen erstellt. Mittels einer
Vergleichs-Funktion (Compare-Funktion) wird dem Benutzer auf einer
Anzeige der Rechnereinheit 26 eine Vergleichstabelle, in
der sämtliche
Parameterwerte gemäß der zweiten
Softwareversion und bei den Parametern, deren Parameterwerte nicht
direkt übernehmbar
sind, die jeweiligen Parameterwerte gemäß dem mindestens einen Parametrierungsvorschlag einander
gegenübergestellt
werden. Die Parameter, deren Parameterwerte nicht direkt übernehmbar sind,
sind graphisch hervorgehoben. Anhand der Vergleichstabelle kann
der Benutzer überprüfen, ob er
den Parametrierungsvorschlägen
bezüglich
der nicht direkt übernehmbaren
Parameter zustimmt. Bei mehreren Parametrierungsvorschlägen in Bezug
auf einen Parameter kann er eine gewünschte Auswahl treffen. Stimmt
er in Bezug auf einen Parameter nicht dem Parametrierungsvorschlag
zu, so kann er diesen Parameter auch selbst in der Vergleichstabelle ändern. In
diesem Fall wird die Änderung
des Parameters auch in das virtuelle Feldgerät übernommen. In dem virtuellen
Feldgerät
wiederum werden gegebenenfalls weitere Parameter, die von dem geänderten
Parameter abhängig
sind, geändert.
Anschließend
wird ein neuer Upload-Datensatz des virtuellen Feldgerätes erstellt
und dem Benutzer wiederum eine entsprechend geänderte Vergleichstabelle dargestellt.
Stimmt der Benutzer den in der Vergleichstabelle angegebenen Parametern
zu, so wird dieser Upload-Datensatz über den Feldbus 28 in
das reale Feldgerät 22 geladen.
Ferner wird der Upload-Datensatz in dem Speicher 48 gespeichert.
-
In 4 ist
schematisch dargestellt, wie eine Feldgerät-DLL DLL, durch den ein virtuelles
Feldgerät
dargestellt bzw. emuliert wird, und eine Gerätesoftware GS für ein Feldgerät generiert
werden. Beide werden von dem gleichen Programmcode C-Code, der im vorliegenden
Ausführungsbeispiel
in der Programmiersprache C oder C++ geschrieben ist, abgeleitet.
Die Feldgerät-DLL
DLL wird über
einen Standard Intel I386-Compiler gewonnen. Die Gerätesoftware
GS wird über
einen IAR-Compiler gewonnen.
-
Die
vorliegende Erfindung ist nicht auf die in den Figuren dargestellten
Ausführungsbeispiele
beschränkt.
Insbesondere ist die Darstellung des virtuellen Feldgerätes als
dynamisch bindende Bibliotheksdatei, insbesondere als DLL-Datei,
nur eine beispielhafte, für
das Betriebssystem Windows® geeignete Ausführungsform.
Ferner muss der Programmcode der Gerätesoftware nicht zwangsweise
in der Programmiersprache C oder C++ geschrieben sein. Alternativ
kann dieser beispielsweise auch in JAVA geschrieben sein. Durch
einen entsprechenden Compiler (JAVA-Runtime-Engine) kann dann ein virtuelles Feldgerät erzeugt
werden.