-
Die
Erfindung betrifft ein Verfahren zum Erstellen einer Software in
einem Feldgerät
der Prozessautomatisierungstechnik durch einen Benutzer sowie einen
Versionenmanager gemäß dem Oberbegriff
des Anspruchs 16.
-
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,
etc.) mit übergeordneten
Einheiten verbunden. Daneben bestehen die Möglichkeiten einer Parallelverdrahtung
sowie einer analogen Signalübertragung
zwischen den Feldgeräten
und der übergeordneten
Einheit. 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.
-
Die
Software der Feldgeräte
ist in der Regel in mehrere Softwaremodule unterteilt, die jeweils
einzelne Funktionen oder Funktionsgruppen des Feldgerätes ausführen. Insbesondere
werden in den Bussystemen Profibus® und
Foundation® Fieldbus
Steuerungsfunktionen für
die Prozesssteuerung durch Funktionsblöcke bereitgestellt, die in
dem Feldgerät in
der Regel durch einzelne Softwaremodule realisiert werden. Für bestimmte
Standardfunktionen sind in der Foundation® Fieldbus
Spezifikation (Foundation® Specification, Function
Block Application Process, Revision FS 1.7) und der Profibus® Spezifikation
(Profibus Profile Specification, Version 3.0) Standardfunktionsblöcke, wie
beispielsweise „Analog
Input" (AI), „Analog
Output" (AO), „Discrete
Input" (DI) und „Discrete
Output" (DO) spezifiziert.
Bei dem Bussystem Profibus® ist zusätzlich der
Standardfunktionsblock „Totalizer" (TOT) spezifiziert.
Daneben können
weitere Funktionen und Funktionsgruppen, wie beispielsweise die
in der Profibus® Spezifikation
spezifizierten „Transducer
Block", „Physical
Block", „Device
Management" und
vom Hersteller spezifizierte Funktionen und Funktionsgruppen durch
zugehörige Softwaremodule
in dem Feldgerät
realisiert werden.
-
In
der Regel weisen die einzelnen Softwaremodule jeweils die Funktionsschnittstellen
bzw. Phasen „Init" (Initialisieren), „Start" (Starten), „Execute" (Ausführen) und „Terminate" (Beenden) auf, wobei die
eigentliche Funktion oder Funktionsgruppe des Softwaremoduls während der
Phase „Execute" ausgeführt wird.
Die Phasen „Init" und „Start" dienen zum Initialisieren
und Konfigurieren des jeweiligen Softwaremoduls in der Startphase.
Die Phase „Terminate" wird von dem Softwaremodul
ausgeführt,
wenn die Ausführung
der Funktion oder Funktionsgruppe des Softwaremoduls beendet wird.
-
Aufgrund
von Weiterentwicklungen werden für
einzelne Softwaremodule oftmals neue Versionen erstellt, in denen
beispielsweise gegenüber
der vorhergehenden Version zusätzliche
Funktionalitäten bereitgestellt
oder Fehler korrigiert werden. Daneben werden teilweise zusätzliche
Softwaremodule (im Folgenden: Zusatz-Versionen) erstellt, die nicht dazu bestimmt
sind, bisher auf dem Feldgerät
vorhandene Softwaremodule zu ersetzen, sondern um als zusätzliches
Softwaremodul zu den bisher vorhandenen Softwaremodulen hinzugefügt zu werden.
-
Bisher
wurde im Falle neuer Versionen oder Zusatz-Versionen eine neue Gesamtsoftware
für das Feldgerät erstellt,
bei der die Softwaremodule, für
die eine neue Version erstellt wurde, durch die entsprechenden neuen
Versionen ersetzt wurden und mit den weiteren Softwaremodulen, für die keine
neue Version erstellt wurde, kombiniert wurden. Dies ist schematisch
in den 1A und 1B veranschaulicht.
In einem Feldgerät 2 sind
beispielsweise vier Softwaremodule, die jeweils durch eine Basisversion 4 gebildet
werden und die jeweils unterschiedliche Funktionen F1, F2, F3 und
F4 ausführen
bzw. realisieren, vorgesehen. Das Feldgerät 2 mit der entsprechenden
Gesamtsoftware ist schematisch in 1A dargestellt.
Aufgrund von Weiterentwicklungen werden für die Softwaremodule, welche
die Funktionen F2 und F4 realisieren, neue Versionen 6 erstellt,
welche die Funktionen F2.1 und F4.1 realisieren und welche die Basisversionen 4 mit
den Funktionen F2 und F4 ersetzen sollen. Ferner wurde eine Zusatz-Version 8,
welche eine bisher nicht vorhandene Funktion F5 realisiert, erstellt.
Eine neue Gesamtsoftware für
das Feldgerät 2 wurde
bisher durch eine Kombination der neuen Versionen 6 mit
den Funktionen F2.1 und F4.1, der Zusatz-Version 8 mit
der Funktion F5 und der Basisversionen 4 mit den Funktionen
F1 und F3 erstellt, wie schematisch in 1B dargestellt
ist.
-
Teilweise
besteht für
den Benutzer ein Bedarf an einer neuen Version eines bestimmten
Softwaremoduls oder an einer Zusatz-Version, da dadurch beispielsweise
eine neue Funktionalität
bereitgestellt wird und/oder ein Fehler der bisherigen Version behoben
wird. Für
andere Softwaremodule, für die
neue Versionen verfügbar
sind, kann der Benutzer jedoch daran interessiert sein, weiter die
bisherigen Versionen zu verwenden. Dies ist insbesondere dann der
Fall, wenn die Verwendung einer neuen Version kostenaufwändige Anpassungen
von weiteren Anlagenteilen, wie beispielsweise von weiteren an ein
Bussystem angeschlossenen Feldgeräten oder einer übergeordneten
Einheit, erfordern würde. Auch
könnte
der Fall auftreten, dass eine neue Version oder eine Zusatz-Version
nicht kompatibel mit weiteren, an der Anlage angeschlossenen Geräten ist.
In diesen Fällen
war es bisher erforderlich, dass der Hersteller auf speziellen Kundenwunsch
eine neue Gesamtsoftware für
das Feldgerät
erstellen musste, in der die gewünschten
Versionen von Softwaremodulen zusammengestellt wurden. Dies ist
mit erheblichen Kosten und Aufwand verbunden.
-
Demgemäß besteht
die Aufgabe der vorliegenden Erfindung darin, ein Verfahren zum
Erstellen einer Software in einem Feldgerät der Prozessautomatisierungstechnik
bereitzustellen, durch das bei der Verfügbarkeit von neuen Versionen
oder von Zusatz-Versionen von Softwaremodulen spezielle Anforderungen
einzelner Benutzer unmittelbarer und auf einfachere Weise berücksichtigt
werden können.
-
Die
Aufgabe wird durch ein Verfahren zum Erstellen einer Software in
einem Feldgerät
der Prozessautomatisierungstechnik durch einen Benutzer gemäß Anspruch
1 und durch einen Versionenmanager gemäß Anspruch 16 gelöst. Vorteilhafte
Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
-
Gemäß der vorliegenden
Erfindung weist ein Verfahren zum Erstellen einer Software in einem Feldgerät der Prozessautomatisierungstechnik
durch einen Benutzer, wobei auf dem Feldgerät eine Mehrzahl von Softwaremodulen
implementiert ist, wobei für
mindestens eines der Softwaremodule mindestens zwei Versionen auf
dem Feldgerät
implementiert sind, und/oder mindestens ein auf dem Feldgerät implementiertes
Softwaremodul eine optional aktivierbare Zusatz-Version ist, die
nachfolgenden Schritte auf:
- a) Bereitstellen
einer Auswahlmöglichkeit
für den Benutzer, über die
er bei mindestens einem Softwaremodul, für das mindestens zwei Versionen auf
dem Feldgerät
implementiert sind, eine Version auswählen kann, und/oder über die
er mindestens ein auf dem Feldgerät implementiertes Softwaremodul,
das eine optional aktivierbare Zusatz-Version ist, auswählen kann;
- b) Aktivieren der von dem Benutzer ausgewählten Version(en) in dem Feldgerät.
-
Das
erfindungsgemäße Verfahren
lässt sich dabei
sehr gut mit Hilfe der Objekt-orientierten Architektur und der Objekt-orientierten
Programmierung umsetzen. Gemäß der vorliegenden
Erfindung werden nicht nur jeweils die aktuellsten Versionen und Zusatz-Versionen
von Softwaremodulen auf dem Feldgerät implementiert, sondern es
bleiben auch die bisherigen Versionen von Softwaremodulen, für die bereits
neuere Versionen verfügbar
sind, auf dem Feldgerät
implementiert. Unter "implementiert" wird dabei verstanden,
dass die jeweiligen Softwaremodule auf dem Feldgerät verfügbar sind.
Damit die einzelnen Softwaremodule tatsächlich ausgeführt werden
können,
müssen
sie aktiviert werden. Durch das erfindungsgemäße Bereitstellen einer Auswahlmöglichkeit
und das Aktivieren der von dem Benutzer ausgewählten Version(en) (Versionen
und Zusatz-Versionen) wird entsprechend den Anforderungen des Benutzers
eine Gesamtsoftware für
das Feldgerät
erstellt. Die weiteren Versionen bleiben auf dem Feldgerät verfügbar (implementiert)
und können bei
Bedarf ausgewählt
werden. Dadurch besteht für den
Benutzer auch die Möglichkeit,
auf spätere Änderungen
zu reagieren und sich bei Bedarf eine entsprechende Gesamtsoftware
des Feldgerätes
selbst neu zusammenzustellen. Sofern keine näheren Angaben gemacht werden,
wird durch „Version" oder „Versionen" allgemein auch auf
Zusatz-Versionen) Bezug genommen. Bei einer optional aktivierbaren Zusatz-Version
handelt es sich dabei um eine Version, die nicht zwingend für den Betrieb
des Feldgerätes
erforderlich ist, die aber beispielsweise gegenüber den bisherigen Softwaremodulen
Zusatzfunktionen bereitstellt.
-
Gemäß einer
vorteilhaften Weiterbildung der Erfindung sind für mindestens zwei Softwaremodule jeweils
mindestens zwei Versionen auf dem Feldgerät implementiert, und der Benutzer
kann dann bei diesen mindestens zwei Softwaremodulen jeweils eine
Version auswählen,
so dass sich für
den Benutzer mehrere Kombinationsmöglichkeiten ergeben. Um zu
vermeiden, dass durch den Benutzer Versionen miteinander kombiniert
werden, die nicht miteinander kompatibel sind, ist gemäß einer
vorteilhaften Weiterbildung der Schritt des Bereitstellens der Auswahlmöglichkeit
derart ausgestaltet, dass nach dem Ausführen einer ersten Auswahl einer
ersten Version durch den Benutzer in Abhängigkeit von der getroffenen
Auswahl für
die weiteren Softwaremodule nur noch die Auswahlmöglichkeiten
bereitgestellt werden, die mit der ersten getroffenen Auswahl kompatibel
sind. Beispielsweise ist diese Weiterbildung dann sinnvoll, falls
die Ausführung
einer neuen Version eines Softwaremoduls oder einer Zusatz-Version
nur dann möglich
ist, falls auch bei einem anderen Softwaremodul die neueste Version
aktiviert ist.
-
Damit
für den
Benutzer neben den jeweils aktuellsten Versionen auch die bisherigen
Versionen zur Auswahl bereitgestellt werden können, ist gemäß einer
vorteilhaften Weiterbildung vorgesehen, dass beim Laden von einer
oder mehreren neu verfügbaren
Version(en) von Softwaremodul(en) diese in dem Feldgerät zusätzlich zu
den bisherigen, auf dem Feldgerät
implementierten Versionen von Softwaremodulen implementiert wird/werden.
Das Laden von neu verfügbaren
Version(en) von Softwaremodulen) kann dabei von einem PC aus erfolgen,
der direkt an das Feldgerät
angeschlossen wird. Die Software kann beispielsweise über ein
FXA 193 Service-Interface
und eine RS232 Schnittstelle oder eine USB Schnittstelle von dem
PC auf das Feldgerät übertragen
werden.
-
Gemäß einer
vorteilhaften Weiterbildung erfolgt der Schritt des Bereitstellens
der Auswahlmöglichkeit
durch einen Versionenmanager, der als Software in dem betreffenden
Feldgerät
implementiert ist oder in dieses ladbar ist, und durch den die jeweils
in der Auswahlmöglichkeit
bereitgestellten Version(en) von Softwaremodulen) aktivierbar sind.
Demgemäß ist der
Versionenmanager eine Software, in der die einzelnen Versionen von
Softwaremodulen erfasst sind oder erfasst werden, und welche die
einzelnen Versionen ansteuern kann, um sie zu aktivieren.
-
Gemäß einer
vorteilhaften Weiterbildung ist vorgesehen, dass der Versionenmanager
zusammen mit einer oder mehreren neuen Version(en) von Softwaremodulen)
in das Feldgerät
geladen wird, und dass der Versionenmanager die neue(n) Version(en) von
Softwaremodul(en) sowie die bisher auf dem Feldgerät implementierten
Versionen von Softwaremodulen dem Benutzer zur Auswahl bereitstellt.
Beispielsweise erfolgt das Laden des Versionenmanagers derart, wie
es oberhalb in Bezug auf die neue(n) Version(en) von Softwaremodul(en)
erläutert
wurde. Demnach wird jedesmal dann, wenn eine oder mehrere neue Version(en)
bereitgestellt werden, ein entsprechend aktualisierter Versionenmanager
erstellt, in dem sämtliche
verfügbare
Versionen erfasst sind und der gegebenenfalls über weitere Informationen bezüglich dieser
Versionen, wie beispielsweise deren Kompatibilität, verfügt. Gemäß einer vorteilhaften Weiterbildung
wird der Versionenmanager automatisch dann aktiviert und führt den
Schritt des Bereitstellens der Auswahlmöglichkeit durch, wenn eine oder
mehrere neue Version(en) von Softwaremodul(en) in das Feldgerät geladen
wird/werden. Dadurch wird dem Benutzer unmittelbar dann, sobald eine
oder mehrere neue Version(en) auf dem Feldgerät verfügbar sind, die Auswahlmöglichkeit
bereitgestellt.
-
Vorzugsweise
ist vorgesehen, dass der Versionenmanager zusätzlich die Softwaremodule,
für die
keine Auswahlmöglichkeit
bereitgestellt wird und die für
den Betrieb des Feldgerätes
erforderlich sind, automatisch aktiviert. Ferner ist vorzugsweise
vorgesehen, dass in dem Versionenmanager die jeweils aktuellsten
Versionen von Softwaremodulen als bevorzugte Auswahl vorgemerkt
sind und, falls ein Benutzer keine anderen Versionen auswählt, diese
bevorzugte Auswahl an Versionen automatisch aktiviert wird. Durch
diese beiden Weiterbildungen wird jeweils sichergestellt, dass auch
ein Benutzer, der nicht über
detaillierte Kenntnisse über
die einzelnen Versionen von Softwaremodulen verfügt, eine Auswahl trifft, mit
der das Feldgerät
betrieben werden kann. Trifft der Benutzer keine Auswahl, so wird
das Feldgerät
automatisch mit den jeweils aktuellsten Versionen betrieben, so
dass eine möglichst
umfangreiche Funktionalität
bereitgestellt wird.
-
Gemäß einer
vorteilhaften Weiterbildung stellt der Versionenmanager eine Dokumentation
für den
Benutzer bereit, in der Informationen, welche die aktivierten Versionen
von Softwaremodulen betreffen, zusammengestellt sind. In diesem
Fall verfügt der
Versionenmanager über
weitergehende Informationen zu den einzelnen Versionen, wie beispielsweise über deren
Funktionalität,
Parameter, etc. Durch die Dokumentation werden dem Benutzer auf übersichtliche
Weise nur die Informationen bereitgestellt, welche die aktuell aktivierten
Versionen betreffen. Falls das Feldgerät an ein Bussystem angeschlossen ist,
kann diese Dokumentation beispielsweise von der übergeordneten Einheit über das
Internet versendet oder in Papierform ausgedruckt werden. Weist das
Feldgerät
einen integrierten Webserver auf, kann die Dokumentation auch direkt
von dem Feldgerät über das
Internet versendet werden.
-
Gemäß einer
vorteilhaften Weiterbildung ist das Feldgerät ein an ein Bussystem, insbesondere ein
an ein Profibus®-Bussystem
und/oder an ein Foundation®-Fieldbus-Bussystem, anschließbares Feldgerät. Vorzugsweise
weist das Feldgerät
Softwaremodule auf, die jeweils einzelne Funktionsblöcke, insbesondere
Standardfunktionsblöcke,
wie beispielsweise einen „Analog
Input", einen „Analog
Output" und/oder
einen „Totalizer" („Totalizer” nur bei Profibus®-Bussystem)
Funktionsblock, realisieren, die in der Foundation® Fieldbus
Spezifikation und der Profibus® Spezifikation als Standardfunktionsblöcke spezifiziert
sind. Daneben können
auch noch weitere Standardfunktionsblöcke, die in der Foundation® Fieldbus
Spezifikation und/oder der Profibus® Spezifikation
spezifiziert sind, durch Softwaremodule realisiert werden.
-
Gemäß einer
vorteilhaften Weiterbildung weist das Feldgerät Softwaremodule auf, die jeweils einzelne
Funktionen oder Funktionsgruppen des Feldgerätes realisieren. Insbesondere
können
solche Softwaremodule einen „Transducer
Block"; einen „Physical
Block"; ein „Device
Management"; eine Funktionsgruppe
(„Power
Fail"), durch die
ein Abfall in der Stromversorgung des Feldgerätes erfasst und eine Sicherung
der aktuellen Werte des Feldgerätes durchgeführt wird;
eine Funktionsgruppe („System Parameter"), durch die durch
den Benutzer ein Modus der Messwerterfassung und Parameter für die Messwertbestimmung
einstellbar sind; eine Funktionsgruppe („Kommunikations Parameter"), durch die der
Benutzer Einstellungen an dem Feldgerät vornehmen kann, aktuelle
Messdaten von den einzelnen Funktionsblöcken abrufen kann, die Ausführung einzelner
Funktionsblöcke,
insbesondere des Funktionsblocks „Totalizer”, triggern kann, Einstellungen bezüglich einer
zyklischen Datenübertragung
an eine übergeordnete
Einheit vornehmen kann, und/oder aktuelle Einstellungen des Feldgerätes sowie
die Übertragungsrate
an eine übergeordnete
Einheit abrufen kann; eine Funktionsgruppe („Produktion"), durch die der
Benutzer Herstellerinformationen über das Feldgerät, insbesondere
eine Seriennummer, Herstellungsdatum, Hardware-Informationen, Ersatzteil-Informationen,
gerätespezifische
Daten und/oder Informationen über
die Konfigurierung des Feldgerätes
durch den Hersteller, abrufen kann; eine Funktionsgruppe („Version-Info"), durch die der
Benutzer Informationen über
die aktuelle Software des Feldgerätes abrufen kann; und/oder
eine Funktionsgruppe („Fehler"), durch die der
Benutzer über
das Auftreten von Fehlern und die Art der Fehler informiert wird,
die in dem Feldgerät
und/oder bei der Kommunikation mit einer übergeordneten Einheit auftreten
oder aufgetreten sind; realisieren.
-
Die
Blöcke „Transducer
Block", „Physical Block" und „Device
Management” sind
dabei in der Profibus® Spezifikation spezifiziert.
Das „Device
Management" umfasst
ein „Directory" (Verzeichnis) und beschreibt
die konkrete Konfiguration des Feldgerätes. Ein Feldgerät kann dabei
auch mehrere Standardfunktionsblöcke
des gleichen Typs oder mehrere „Transducer Blocks" aufweisen. In diesem
Fall ist bevorzugt, dass die mehreren Standardfunktionsblöcke des
gleichen Typs oder die mehreren „Transducer Blocks" jeweils durch ein
Softwaremodul gebildet werden, das eine entsprechend hohe Anzahl
an Speichern (Instanzen) für
die einzelnen Standardfunktionsblöcke des gleichen Typs oder „Transducer Blocks" aufweist.
-
Bei
den weiteren beispielhaft aufgeführten Funktionsgruppen
mit den Kurzbezeichnungen „Power
Fail", „System
Parameter", „Kommunikations
Parameter", „Produktion", „Version-Info" und „Fehler" wurden einzelne
Funktionen eines Feldgerätes
entsprechend ihren Eigenschaften gruppiert. Diese so gebildeten
Funktionsgruppen können
dann durch einzelne Softwaremodule realisiert werden. Je nach spezieller
Ausgestaltung des betreffenden Feldgerätes können bei den einzelnen Funktionsgruppen
die jeweils angeführten
Funktionen auch nur teilweise vorgesehen werden oder es können in
den einzelnen Funktionsgruppen weitere Funktionen mit aufgenommen
werden. Bei den Funktionsgruppen mit den Kurzbezeichnungen „System
Parameter" und „Kommunikations
Parameter" kann
eine Menüführung bereitgestellt
werden, durch die der Benutzer die relevanten Informationen erhalten
kann und/oder Einstellungen vornehmen kann. Diese Menüführung kann sowohl
an dem Feldgerät
selbst als auch in einer übergeordneten
Einheit, die der Prozessvisualisierung, und/oder der Konfigurierung
und Parametrisierung dient, bereitgestellt werden. Direkt am Feldgerät sind hierfür in der
Regel eine Anzeige und entsprechende Eingabetasten vorgesehen, durch
die der Benutzer entsprechende Menüpunkte auswählen und gegebenenfalls Eingaben
vornehmen kann. Auch die weiteren Informationen, die durch die Funktionsgruppen
mit den Kurzbezeichnungen „Produktion", „Version-Info", „Fehler" und/oder „Power
Fail" auf Abfrage,
bei Auftreten von Fehlern und/oder im Falle eines Stromabfalls bereitgestellt
werden, können
beispielsweise auf der Anzeige des Feldgerätes und/oder auf einer Anzeige
einer entsprechenden übergeordneten
Einheit angezeigt werden.
-
Gemäß einer
bevorzugten Weiterbildung der Erfindung sind relevante Informationen über den
Versionenmanager in einer „Device
Description" (Gerätebeschreibung)
und/oder in einem „Device
Type Manager" enthalten.
Die „Device
Description" dient
dazu, die Funktionalität
des Feldgerätes
zu beschreiben. Die „Device
Description" enthält die für eine übergeordnete
Einheit erforderlichen Informationen über die Funktionalität des Feldgerätes, insbesondere über die
in dem Feldgerät
enthaltenen Variablen, deren Grenzwerte und den Zugang zu diesen
Variablen. Ein „Device
Type Manager" ist
eine gerätespezifische
Software, die alle Daten und Funktionen des betreffenden Feldgerätes kapselt
und gleichzeitig grafische Bedienelemente bereitstellt. Der „Device Type
Manager" stellt
Funktionen zum Zugang zu Variablen des Feldgerätes, zum Parametrisieren und Betreiben
des Feldgerätes
und Diagnosefunktionen bereit. Der „Device Type Manager" wird von dem Hersteller
des Feldgerätes
zu dem betreffenden Feldgerät
erstellt. Zur Ausführung
benötigt
der „Device
Type Manager" eine
FDT-Frame Anwendung (z. B. FieldCare®).
Vorzugsweise ist vorgesehen, dass die relevanten Informationen und
insbesondere Informationen über
die aktivierten und die in der Auswahlmöglichkeit bereitgestellten
Versionen von Softwaremodulen über
den „Device
Type Manager" und
eine FDT („Field
Device Tool") Frame
Anwendung in einer übergeordneten
Einheit abrufbar sind.
-
Alternativ
dazu kann vorgesehen sein, dass über
einen in das Feldgerät
integrierten Webserver auf relevante Informationen über den
Versionenmanager, insbesondere auf Informationen über die
aktivierten und auf die in der Auswahlmöglichkeit bereitgestellten
Versionen von Softwaremodulen, zugegriffen wird und diese Informationen über einen
Webbrowser abrufbar sind.
-
Gemäß der vorliegenden
Erfindung wird ferner ein Versionenmanager bereitgestellt, der als
Software in einem Feldgerät
der Prozessautomatisierungstechnik implementiert ist oder der in
solch ein Feldgerät
ladbar ist, wobei auf dem Feldgerät eine Mehrzahl von Softwaremodulen
implementiert ist, wobei der Versionenmanager derart eingerichtet
ist,
- a) dass er einem Benutzer eine Auswahlmöglichkeit
bereitstellt, über
die der Benutzer bei mindestens einem Softwaremodul, für das mindestens zwei
Versionen auf dem Feldgerät
implementiert sind, eine Version auswählen kann und/oder
über die
der Benutzer mindestens ein auf dem Feldgerät implementiertes Softwaremodul,
das eine optional aktivierbare Zusatz-Version ist, auswählen kann;
und
- b) dass er die von dem Benutzer ausgewählte(n) Version(en) auf dem
Feldgerät
aktiviert.
-
Die
oberhalb in Bezug auf das erfindungsgemäße Verfahren erläuterten
Weiterbildungen sind entsprechend bei dem erfindungsgemäßen Versionenmanager
möglich,
wodurch jeweils die oberhalb genannten Vorteile erzielt werden.
Ferner werden diese Vorteile auch bei einem Feldgerät erzielt,
auf dem eine Mehrzahl von Softwaremodulen implementiert ist und
das einen solchen Versionenmanager aufweist.
-
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:
-
1A:
eine schematische Darstellung eines Feldgerätes gemäß dem Stand der Technik mit einer
Gesamtsoftware einer Basisversion;
-
1B:
eine schematische Darstellung des in 1A dargestellten
Feldgerätes
mit einer Gesamtsoftware einer neuen Version;
-
2:
eine schematische Darstellung eines Feldbus-Netzwerkes;
-
3A:
eine schematische Darstellung eines Feldgerätes mit mehreren Softwaremodulen
einer Basisversion und einem Versionenmanager gemäß der vorliegenden
Erfindung;
-
3B:
eine schematische Darstellung des in 3A dargestellten
Feldgerätes,
wobei die Softwaremodule aktiviert sind;
-
4A:
eine schematische Darstellung des in 3A dargestellten
Feldgerätes,
wobei auf dem Feldgerät
zusätzlich
neue Versionen und eine Zusatz-Version implementiert sind; und
-
4B:
eine schematische Darstellung des in 4A dargestellten
Feldgerätes,
wobei einzelne Versionen von Softwaremodulen aktiviert sind.
-
2 ist
eine schematische Darstellung eines kleinen Feldbus-Netzwerkes,
bei dem vier Feldgeräte
FG0, FG1, FG2 und FG3 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 (Klasse
1 und/oder Klasse 2), während
die Feldgeräte
FG0, FG1, FG2 und FG3 jeweils Profibus-Slaves sind. Die Kommunikation
zwischen der Steuereinheit SPS und den Feldgeräten FG0, FG1, FG2 und FG3 erfolgt
nach dem entsprechenden Profibus® Standard.
-
In 3A sind
in einem Feldgerät 2, ähnlich wie
in 1A, vier Softwaremodule, die jeweils durch eine
Basisversion 4 gebildet werden und die unterschiedliche
Funktionen F1, F2, F3 und F4 ausführen bzw. realisieren, vorgesehen.
Zusätzlich
ist in dem Feldgerät 2 ein
Versionenmanager 10 implementiert, der ebenfalls als Software
ausgebildet ist. In dem Versionenmanager 10 sind die Basisversionen 4 der
vier Softwaremodule erfasst. Falls der Versionenmanager 10 von
einem Benutzer aktiviert wird, werden dem Benutzer die Basisversionen 4 der
vier vorhandenen Softwaremodule auf einer Anzeige angezeigt. Dabei
ist in der vorliegenden Ausführungsform vorgesehen,
dass der Benutzer den Versionenmanager 10 sowohl von dem
Feldgerät 2 direkt
als auch von einer übergeordneten
Einheit (SPS, PLC, etc.) aus aktivieren kann. Dementsprechend werden
dem Benutzer die vier Basisversionen 4 der vorhandenen Softwaremodule
entweder auf einer Anzeige des Feldgerätes 2 oder auf einer
Anzeige der übergeordneten
Einheit angezeigt.
-
Die
vier Basisversionen 4 mit den Funktionen F1, F2, F3 und
F4 sind im vorliegenden Fall für
den Betrieb des Feldgerätes 2 zwingend
erforderlich. Selbst wenn der Benutzer nicht alle vier Basisversionen 4 auswählt, ist
der Versionenmanager 10 derart eingerichtet, dass er alle
Basisversionen 4 mit den Funktionen F1, F2, F3 und F4 aktiviert.
Die Aktivierung erfolgt dadurch, dass der Versionenmanager 10 die
einzelnen Basisversionen 4 ansteuert. Die Ansteuerbarkeit
ist schematisch durch die Linien 12 dargestellt, durch
welche der Versionenmanager 10 in den 3A, 3B, 4A und 4B mit
den einzelnen Versionen von Softwaremodulen verbunden ist. Die aktivierten
Basisversionen 4' können dann
tatsächlich
auf dem Feldgerät 2 ausgeführt werden.
Sie sind in 3B durch Fettdruck hervorgehoben
und werden mit 4' bezeichnet.
-
Auch
auf der Anzeige können
die von dem Benutzer ausgewählten
Versionen 4' besonders
hervorgehoben werden, so dass der Benutzer auf einen Blick erkennen
kann, welche Versionen ausgewählt und
damit aktiviert wurden. Die Softwaremodule (hier: die Basisversionen 4 mit
den Funktionen F1, F2, F3 und F4), für die keine Auswahlmöglichkeit
bereitgestellt wird und die für
den Betrieb des Feldgerätes 2 erforderlich
sind, können
auf der Anzeige bereits als vorausgewählt gekennzeichnet werden.
Dadurch kann der Benutzer anhand der Kennzeichnung direkt erkennen,
dass für
diese Softwaremodule keine Auswahlmöglichkeit besteht.
-
Ähnlich wie
bei dem in den 1A und 1B dargestellten
Beispiel werden wiederum für die
Softwaremodule, welche die Funktionen F2 und F4 realisieren, neue
Versionen 6 erstellt, welche die Funktionen F2.1 und F4.1
realisieren und welche die Basisversionen 4 mit den Funktionen
F2 und F4 ersetzen sollen. Ferner wurde eine Zusatz-Version 8, welche
eine bisher nicht vorhandene Funktion F5 realisiert, erstellt. Diese
neuen Versionen 6 und die Zusatz-Version 8 werden
zusammen mit einem aktualisierten Versionenmanager 101,
in dem sämtliche, auf
dem Feldgerät 2 verfügbaren Versionen 4, 6 und 8 erfasst
sind, in das Feldgerät 2 geladen.
Dabei werden die neuen Versionen 6 und die Zusatz-Version 8 zusätzlich zu
den bisherigen Basisversionen 4 in dem Feldgerät 2 implementiert.
Ein Feldgerät 2,
in dem der aktualisierte Versionenmanager 101 und die oberhalb
genannten Versionen 4, 6 und 8 implementiert
sind, ist schematisch in 4A dargestellt.
-
Der
Versionenmanager 101 wird nach dem Laden automatisch aktiviert
und stellt dem Benutzer eine Auswahlmöglichkeit bereit. Dabei werden
auf der entsprechenden Anzeige (des Feldgerätes 2 oder der übergeordneten
Einheit) die jeweils aktuellsten Versionen (hier die Versionen mit
den Funktionen F1, F2.1, F3, F4.1 und F5) als vorgemerkte Versionen
gekennzeichnet. Wenn der Benutzer keine anderen Versionen auswählt, aktiviert
der Versionenmanager 101 automatisch diese vorgemerkten
Versionen. Trifft der Benutzer eine andere Auswahl (hier die Versionen
mit den Funktionen F1, F2.1, F3 und F4), so werden von dem Versionenmanager 101 die
ausgewählten
Versionen aktiviert. Ist eine von dem Benutzer nicht ausgewählte Version 4, 6 oder 8 für den Betrieb
des Feldgerätes 2 erforderlich,
so wird diese durch den Versionenmanager 101 automatisch
aktiviert. Die Aktivierung erfolgt dadurch, dass der Versionenmanager 10 die
einzelnen Versionen ansteuert (siehe Linien 12). In der
in 4B dargestellten Konstellation können die
ausgewählten
und aktivierten Basisversionen 4' mit den Funktionen F1, F3 und
F4 und die neue Version 6' mit
der Funktion F2.1 auf dem Feldgerät 2 ausgeführt werden.
Diese aktivierten Versionen sind in 4B durch
Fettdruck hervorgehoben und jeweils durch 4' bzw. 6' bezeichnet. Auch auf der Anzeige
können
die von dem Benutzer ausgewählten
Versionen 4' bzw. 6' besonders hervorgehoben
werden, so dass der Benutzer auf einen Blick erkennen kann, welche
Versionen ausgewählt wurden.
-
Die
Implementierung von zwei verschiedenen Versionen von Softwaremodulen
auf einem Feldgerät
und die Bereitstellung einer Auswahlmöglichkeit können insbesondere in den nachfolgenden
Fällen
sinnvoll sein.
-
Beispielsweise
könnten
zwei verschiedene Versionen von Softwaremodulen zur Realisierung des
Funktionsblocks „Totalizer" vorgesehen werden. Dieser
Funktionsblock ist beispielsweise in Durchflussmessgeräten vorgesehen.
Der Unterschied in den beiden Versionen liegt in der Ansteuerung
des Funktionsblockes „Totalizer" durch einen Parameter SET_TOT,
der auf die Werte „0", „1" und „2" gesetzt werden kann.
Wird der Parameter SET_TOT auf „0" gesetzt, so läuft der Funktionsblock „Totalizer" im Normalbetrieb,
d. h. er integriert die erhaltenen Messwerte, wie beispielsweise
Durchflusswerte, auf und gibt den aufintegrierten Wert aus (Parameter
TOTAL). Wird der Parameter SET_TOT auf „1" gesetzt, so wird der Ausgabewert (Parameter
TOTAL) auf Null gesetzt. Wird der Parameter SET_TOT auf „2" gesetzt, so wird
der Ausgabewert (Parameter TOTAL) auf einen vorbestimmten Wert gesetzt,
der durch einen Parameter PRESST_TOT bestimmt wird.
-
In
einer ersten Version wird der Parameter SET_TOT, nachdem er auf „1" oder „2" gesetzt wurde, sofort
wieder auf den Wert „0" zurückgesetzt. Demnach
beginnt der Funktionsblock „Totalizer", nachdem der Parameter
SET_TOT auf „1" gesetzt wurde, sofort,
die erhaltenen Messwerte aufzuintegrieren, wobei er bei dem Wert
Null startet. Wurde der Parameter SET_TOT zuvor auf „2" gesetzt, so beginnt
der Funktionsblock „Totalizer" bei der ersten Version
ebenfalls sofort danach, die erhaltenen Messwerte aufzuintegrieren,
wobei in diesem Fall bei dem Wert gestartet wird, der durch den
Parameter PRESST_TOT bestimmt wird. Dadurch kann ein Benutzer beispielsweise
allein durch einmaliges Setzen des Parameters SET_TOT auf „1" oder auf „2" den Start eines
neuen Integrationsvorganges triggern.
-
In
einer zweiten Version wird der Parameter SET_TOT, nachdem er auf „1" oder „2" gesetzt wurde, nicht
automatisch auf den Wert „0" zurückgesetzt. Vielmehr
bleibt er so lange auf dem jeweils gesetzten Wert, bis er aktiv
(beispielsweise durch einen Benutzer oder durch einen entsprechenden
Programmablauf) wieder auf „0" gesetzt wird. Während der
Zeit, in welcher der Parameter SET_TOT auf „1" oder „2" gesetzt ist, gibt der Funktionsblock „Totalizer" als Ausgabewert
(Parameter TOTAL) Null (für
SET_TOT auf "1") bzw. einen vorbestimmten
Wert, der durch den Parameter PRESST_TOT bestimmt wird (für SET_TOT
auf „2"), aus. Erst wenn
der Parameter SET_TOT aktiv auf „0" zurückgesetzt
wurde, beginnt der „Totalizer", von neuem zu integrieren,
wie es oberhalb unter Bezugnahme auf die erste Version erläutert wurde.
-
Je
nach Einsatzbereich und Konfiguration der weiteren, an das Bussystem
angeschlossenen Geräte
kann für
einen Benutzer die eine oder die andere Version vorteilhaft sein.
Durch die vorliegende Erfindung können dem Benutzer beide Versionen
zur Verfügung
gestellt werden, und der Benutzer kann die gewünschte Version aktivieren.
-
Ein
weiteres Beispiel ist der Fall, dass sowohl eine neue Version für den Funktionsblock „Analog
Input" als auch
für den
Funktionsblock „Analog Output" bereitgestellt wurde.
Während
die neue Version des Funktionsblockes „Analog Input" für den Benutzer
erhebliche Vorteile bietet, würde
die neue Version des Funktionsblockes „Analog Output" erhebliche Anpassungen
der weiteren, an das Bussystem angeschlossenen Geräte erfordern.
In diesem Fall kann der Benutzer durch die Bereitstellung der Auswahlmöglichkeit
bei den Funktionsblöcken
die jeweils gewünschte
Version auswählen
und aktivieren.
-
Auch
bei der Realisierung der oberhalb genannten Funktionsgruppe mit
der Kurzbezeichnung „Fehler" kann die Verfügbarkeit
verschiedener Versionen von Softwaremodulen vorteilhaft sein. In
der Regel werden in Fehlerlisten einzelnen Fehlern entsprechende
Bitpositionen (bei einem zyklischen Dienst) oder entsprechende Nummern
(bei einem azyklischen Dienst) zugeordnet. Dadurch kann anhand der
Bitposition oder der Nummer einer Fehlermitteilung erkannt werden,
welche Art von Fehler aufgetreten ist. Aus Kompatibilitätsgründen sollten
dabei den gleichen Fehlern immer die gleichen Bitpositionen oder
Nummern zugeordnet werden. Bei neueren Feldgeräten treten zum Teil Fehler,
die bei alten Feldgeräten
aufgetreten sind, nicht mehr auf. Umgekehrt ist erforderlich, bei
neuen Geräten
weitere Bitpositionen oder Nummern für Fehler zu vergeben, die nur für die neuen
Geräte
relevant sind. Um zu vermeiden, dass unnötig umfangreiche Fehlerlisten
erstellt und verwaltet werden müssen,
kann es vorteilhaft sein, unterschiedliche Fehlerlisten für verschiedene
Generationen von Feldgeräten
und/oder für
verschiedene Versionen von Software, die auf dem Feldgerät implementiert
sind, zu erstellen. Der Benutzer kann dann zwischen zwei oder mehreren
verschiedenen Versionen von Softwaremodulen für die Realisierung der Funktionsgruppe
mit der Kurzbezeichnung „Fehler" in Abhängigkeit
von der Konfiguration seines Feldgerätes wählen.
-
Die
vorliegende Erfindung ist nicht auf die in den Figuren dargestellten
und oberhalb erläuterten Ausführungsbeispiele
beschränkt.
Beispielsweise kann zusätzlich
vorgesehen sein, dass die jeweiligen Versionen von Softwaremodulen
entsprechend einem Kundenwunsch bereits vorab durch den Hersteller
ausgewählt
werden. Der Benutzer muss den Versionenmanager in diesem Fall nur
dann aktivieren, wenn er eine andere Kombination von Versionen von Softwaremodulen
wünscht.
Ferner kann die Gesamtsoftware eines Feldgerätes auch in andere Softwaremodule
unterteilt werden, als dies oberhalb erläutert wurde.
-
In
den Ausführungsformen,
die in den Figuren dargestellt sind, waren je Softwaremodul höchstens
zwei verschiedene Versionen verfügbar.
Die Erfindung kann jedoch auch dann realisiert werden, wenn für ein Softwaremodul
mehr als zwei Versionen verfügbar
sind.