WO2009019108A1 - Verfahren zum erstellen einer software in einem feldgerät durch einen benutzer - Google Patents

Verfahren zum erstellen einer software in einem feldgerät durch einen benutzer Download PDF

Info

Publication number
WO2009019108A1
WO2009019108A1 PCT/EP2008/059130 EP2008059130W WO2009019108A1 WO 2009019108 A1 WO2009019108 A1 WO 2009019108A1 EP 2008059130 W EP2008059130 W EP 2008059130W WO 2009019108 A1 WO2009019108 A1 WO 2009019108A1
Authority
WO
WIPO (PCT)
Prior art keywords
field device
version
user
versions
software
Prior art date
Application number
PCT/EP2008/059130
Other languages
English (en)
French (fr)
Inventor
Alain Chomik
Udo Fuchs
Pierre Harnist
Original Assignee
Endress+Hauser Flowtec Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Endress+Hauser Flowtec Ag filed Critical Endress+Hauser Flowtec Ag
Publication of WO2009019108A1 publication Critical patent/WO2009019108A1/de

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0426—Programming the control sequence
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44536—Selecting among different versions
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/23—Pc programming
    • G05B2219/23427—Selection out of several programs, parameters
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/25—Pc structure of the system
    • G05B2219/25428—Field device

Definitions

  • the invention relates to a method for creating a software in a field device of the process automation technology by a user and a versions manager according to the preamble of claim 16.
  • field devices are often used which serve to detect and / or influence process variables.
  • Sensors such as level gauges, flowmeters, pressure and temperature measuring devices, pH redox potential measuring devices, conductivity meters, etc., which record the respective process variables level, flow, pressure, temperature, pH or conductivity, are used to record process variables .
  • actuators such as valves or pumps, via which the flow of a liquid in a pipeline section or the level can be changed in a container.
  • Bus systems are connected to higher-level units.
  • the higher-level units are control systems or control units, such as PLC (Programmable Logic Controller) or PLC (Programmable Logic Controller).
  • PLC Process Control Control
  • PLC Process Visual Control Controller
  • PLC Process Control Control Controller
  • the software of the field devices is usually in several software modules subdivided, each performing individual functions or function groups of the field device.
  • control functions for the process control by function blocks are provided in the bus systems Profibus® and Foundation® Fieldbus, which are generally implemented in the field device by individual software modules.
  • Foundation® Fieldbus specification Fluorescence® Specification, Function Block Application Process, Revision FS 1.7
  • Profibus® Specification Profile Specification, Version 3.0
  • standard function blocks such as "Analog Input” (AI).
  • AO Analog Output
  • Dl Discrete Input
  • DO Discrete Output
  • TOT Totalizer
  • new versions are often created for individual software modules in which, for example, compared to the previous version provided additional functionality or errors are corrected.
  • additional software modules in the following: additional versions are created which are not intended to replace previous software modules on the field device, but as an additional software module to date to be added to existing software modules.
  • FIGS. 1A and 1B a new overall software for the field device has been created in which the software modules for which a new version was created de, have been replaced by the corresponding new versions and with the other software modules , for which no new version was created, were combined.
  • FIGS. 1A and 1B This is illustrated schematically in FIGS. 1A and 1B.
  • a field device 2 for example, four software modules, each of which is formed by a basic version 4 and each run or implement different functions F1, F2, F3 and F4 provided.
  • the field device 2 with the corresponding overall software is shown schematically in FIG. 1A.
  • new versions 6 are created for the software modules which implement the functions F2 and F4, which implement the functions F2.1 and F4.1 and which are to replace the basic versions 4 with the functions F2 and F4.
  • an additional version 8 which realizes a previously non-existent function F5 created.
  • a new overall software for the field device 2 was previously created by a combination of the new versions 6 with the functions F2.1 and F4.1, the additional version 8 with the function F5 and the basic versions 4 with the functions F1 and F3, as shown schematically in Fig. 1 B is shown.
  • the object of the present invention is to provide a method for creating a software in a field device of the process automation technology, by the availability of new versions or additional versions of software modules specific requirements of individual users more directly and be taken into account in a simpler way.
  • a method for creating software in a field device of the process automation technology by a user wherein a plurality of software modules is implemented on the field device, wherein at least two versions are implemented on the Feldge-unit for at least one of the software modules , and / or at least one software module implemented on the field device is an optionally activatable additional version, the following steps:
  • Software module that is an optional activatable add-on version
  • the inventive method can be very well with the help of Implement object-oriented architecture and object-oriented programming.
  • the inventive method not only are the most up-to-date versions and additional versions of software modules implemented on the field device, but also the previous versions of software modules for which newer versions are already available are implemented on the field device.
  • At least two versions are respectively implemented on the field device for at least two software modules, and the user can then select one version in each of these at least two software modules, so that a plurality of combination options results for the user.
  • the step of providing the selection option is configured in such a way that after executing a first selection of a first version by the user, depending on the choice made for the further software modules, only the selection possibilities are provided which are compatible with the first choice made. For example, this training is useful if the execution of a new version of a software module or an additional version is only possible if the latest version is also activated in another software module.
  • the user can be provided with the latest versions in addition to the current versions for selection, is provided according to an advantageous development that when loading one or more newly available version (s) of software module (s) this in the field device implemented in addition to the previous versions of software modules implemented on the field device.
  • the loading of newly available version (s) of the software module (s) can take place from a PC which is connected directly to the field device.
  • the software can be transferred from the PC to the field device via an FXA 193 service interface and an RS232 interface or a USB interface.
  • the version manager is a software in which the individual versions of software modules are detected or captured, and which can drive the individual versions to activate them.
  • the versions manager is loaded together with one or more new version (s) of software module (s) in the field device, and that the version manager the new (s) version (s ) of software module (s) and the previously implemented on the field device Versions of software modules provided to the user for selection.
  • the loading of the version manager is done as explained above with respect to the new version (s) of software module (s).
  • a correspondingly updated version manager is created, in which all available versions are captured and optionally has further information regarding such versions, such as their compatibility .
  • the version manager is then automatically activated and performs the step of providing the selection option when one or more new versions of software module (s) are loaded into the field device. This will provide the user with the choice immediately as soon as one or more new version (s) are available on the field device.
  • the version manager additionally activates the software modules, for which no selection option is provided and which are required for the operation of the field device, automatically activated. Furthermore, it is preferably provided that in the version manager the respective most recent versions of software modules are marked as preferred selection and, if a user does not select other versions, this preferred selection of versions is automatically activated.
  • the version manager provides a documentation for the user in which information relating to the activated versions of software modules is compiled.
  • the Version Manager has more information about each version, such as theirs Functionality, parameters, etc.
  • the documentation provides the user with a clear overview of only the information concerning the currently activated versions. If the field device is connected to a bus system, this documentation can be sent, for example, from the higher-level unit via the Internet or printed in paper form. If the field device has an integrated web server, the documentation station can also be sent directly from the field device via the Internet.
  • the field device is a to a
  • Bus system in particular a field device which can be connected to a Profibus® bus system and / or to a Foundation® Fieldbus bus system.
  • the field device preferably has software modules which in each case have individual function blocks, in particular standard function blocks, such as an "Analog Input", an "Analog Output” and / or a "Totalizer” ("Totalizer” only in the case of Profi-bus®).
  • Bus system function blocks specified in the Foundation® Fieldbus specification and Profibus® specification as standard function blocks.
  • other standard function blocks specified in the Foundation® Fieldbus specification and / or the Profibus® specification can also be implemented by software modules.
  • the field device software modules each realize individual functions or functional groups of the field device.
  • such software modules may have a "transducer block”; a “physical block”; a “Device Management”, a functional group ("Power FaN”), which detects a drop in the power supply of the field device and performs a backup of the current values of the field device; a function group ("system parameter") which allows the user to set a mode of measurement acquisition and measurement parameters, a functional group (“communication parameter”) that allows the user to make adjustments to the field device, can retrieve current measurement data from the individual function blocks, the execution of individual Function blocks, in particular of the function block "Totalizer", can make settings with respect to a cyclic data transmission to a higher-level unit, and / or can retrieve current settings of the field device and the transmission rate to a higher-level unit, a function group ("production") by which the user can retrieve manufacturer information about the field device, in particular a serial number, date of manufacture, hardware information, spare parts information, device-specific data
  • the blocks "Transducer Block”, "Physical Block” and “Device Management” are specified in the Profibus® Specification
  • the “Device Management” comprises a "Directory” and describes the specific configuration of the field device can also have several standard function blocks of the same type or multiple "transducer blocks".
  • the plurality of standard function blocks of the same type or the plurality of "transducer blocks” are each formed by a software module having a correspondingly high number of memories (instances) for the individual standard function blocks of the same type or " Transducer Blocks "has.
  • This menu guidance can be provided both on the field device itself and in a higher-level unit which serves for the process visualization and / or the configuration and parameterization.
  • a display and corresponding input keys are usually provided for this purpose, by means of which the user can select corresponding menu items and optionally make inputs.
  • the other information provided by the function groups with the abbreviations "Production”, “Version Info”, “Error” and / or “Power FaN” on query, when errors occur and / or in the event of a power drop can for example, on the display of the field device and / or on a display of a corresponding higher-level unit. According to a preferred embodiment of the invention are relevant
  • the “Device Description” serves to describe the functionality of the field device
  • the “Device Description” contains the information required for a higher-level unit about the functionality of the field device, in particular about the variables contained in the field device, their limits and access to them Variables.
  • a “Device Type Manager” is a device-specific software that encapsulates all the data and functions of the relevant field device and at the same time provides graphical operating elements. The “Device Type Manager” provides functions for accessing variables of the field device, for parameterizing and operating the field device and diagnostic functions ready.
  • the "Device Type Manager” is created by the manufacturer of the field device for the relevant field device.For execution, the "Device Type Manager” requires an FDT frame application (eg FieldCare®). It is preferably provided that the relevant information and, in particular, information about the activated and the versions of software modules provided in the selection option can be called up in a higher-level unit via the "Device Type Manager” and an FDT ("Field Device Tool”) frame application.
  • FDT Field Device Tool
  • relevant information about the version manager in particular information about the activated and on the provided in the selection options versions of software modules, is accessed via a built-in the field device web server and this information can be retrieved via a web browser ,
  • a version manager implemented as software in a field device of process automation technology or loadable into such a field device, wherein a plurality of software modules are implemented on the field device, the version manager set up in such a way
  • FIG. 1A is a schematic representation of a field device according to the prior art with a complete software of a basic version
  • FIG. 1B a schematic representation of the field device shown in FIG. 1A with a complete software of a new version
  • FIG. 2 is a schematic representation of a fieldbus network
  • Fig. 3A is a schematic representation of a field device having a plurality of software modules of a basic version and a version manager according to the present invention
  • FIG. 3B is a schematic illustration of the field device shown in FIG. 3A with the software modules activated; FIG.
  • Fig. 4A a schematic representation of that shown in Fig. 3A
  • Fig. 4B is a schematic representation of that shown in Fig. 4A
  • FIG. 2 is a schematic representation of a small one.
  • Fieldbus network in which four field devices FGO, FG1, FG2 and FG3 and a control unit PLC are connected to a field bus F.
  • the fieldbus F operates according to one of the known fieldbus standards of Profibus® (DP, PA or FMS).
  • the control unit PLC is a Profibus master (class 1 and / or class 2), while the field units FGO, FG1, FG2 and FG3 are each Profibus slaves.
  • the communication between the PLC control unit and the field devices FGO, FG1, FG2 and FG3 takes place according to the corresponding Profi-bus® standard.
  • a field device 2 similar to Fig. 1A, four Software modules, each formed by a basic version 4 and the different functions F1, F2, F3 and F4 perform or realize provided.
  • a version manager 10 is implemented, which is also designed as software.
  • the basic versions 4 of the four software modules are included. If the version manager 10 is activated by a user, the user will be presented with the basic versions 4 of the four existing software modules on a display. It is provided in the present embodiment that the user can activate the version manager 10 both from the field device 2 directly and from a higher-level unit (PLC, PLC, etc.). Accordingly, the user is presented with the four basic versions 4 of the existing software modules either on a display of the field device 2 or on a display of the higher-level unit.
  • PLC higher-level unit
  • the four basic versions 4 with the functions F1, F2, F3 and F4 are mandatory in the present case for the operation of the field device 2. Even if the user does not select all four basic versions 4, the version manager 10 is set up to activate all the basic versions 4 with the functions F1, F2, F3 and F4. The activation takes place in that the version manager 10 activates the individual basic versions 4.
  • the controllability is illustrated schematically by the lines 12 through which the version manager 10 in Figs. 3A, 3B, 4A and 4B is connected to the individual versions of software modules.
  • the activated basic versions 4 ' then actually be executed on the field device 2. They are highlighted in bold in FIG. 3B and are designated 4 '.
  • Also on the display can be selected by the user
  • Versions 4 are particularly highlighted so that the user can see at a glance which versions have been selected and thus activated.
  • the software modules here: the basic versions 4 with the functions F1, F2, F3 and F4
  • F1, F2, F3 and F4 for which no selection option is provided and which are required for the operation of the field device 2 can already be marked as preselected on the display. This allows the user to identify directly from the tag that there is no choice for these software modules.
  • new versions 6 are again created for the software modules which implement the functions F2 and F4, which realizes the functions F2.1 and F4.1 and which ones replace the basic versions 4 with the functions F2 and F4. Furthermore, an additional version 8, which realizes a previously non-existent function F5 created.
  • These new versions 6 and the additional version 8 are loaded into the field device 2 together with an updated version manager 101, in which all versions 4, 6 and 8 available on the field device 2 are detected. In this case, the new versions 6 and the additional version 8 are implemented in the field device 2 in addition to the previous basic versions 4.
  • a field device 2, in which the updated version manager 101 and the above-mentioned versions 4, 6 and 8 are implemented, is shown schematically in FIG. 4A.
  • the version manager 101 is automatically activated after loading and provides the user with a choice.
  • the respective most recent versions in this case the versions with the functions F1, F2.1, F3, F4.1 and F5 are marked as reserved versions on the corresponding display (of the field device 2 or the higher-level unit).
  • the Version Manager 101 automatically activates these prerecorded versions. If the user makes another selection (here the versions with the functions F1, F2.1, F3 and F4), the version manager 101 activates the selected versions. If a version 4, 6 or 8 not selected by the user is required for the operation of the field device 2, this is automatically activated by the version manager 101. Activation is accomplished by version manager 10 driving each version (see lines 12).
  • This function block is provided, for example, in flowmeters
  • the difference in the two versions lies in the activation of the function block "Totalizer” by a parameter SET_TOT, which is set to the values "0". , "1" and “2.” If the parameter SET_TOT is set to "0", the function block “Totalizer” runs in normal mode, ie it integrates the received measured values, such as flow values, and outputs the integrated value (Parameter TOTAL) If the parameter SET_TOT is set to "1”, the output value (parameter TOTAL) is set to zero. If the parameter SET_TOT is set to "2", the output value (parameter TOTAL) is set to a predetermined value, which is determined by a parameter PRESET_TOT.
  • the function block "Totalizer” starts after the parameter SET_TOT is set to "1” , immediately, to integrate the obtained measured values, starting at the value 0. If the parameter SET_TOT was previously set to "2", the function block "Totalizer” in the first version also starts immediately afterwards, the received one Integrate measured values, in which case starting at the value determined by the parameter PRESET_TOT. As a result, a user can, for example, trigger the start of a new integration process solely by setting the parameter SET_TOT to "1” or to "2" once.
  • the parameter SET_TOT is not automatically reset to the value “0" after being set to “1” or “2.” Instead, it remains at the set value until it is active (FIG. for example, by a user or by a corresponding program flow) is set to “0" again.
  • the function block "Totalizer” gives as the output value (parameter TOTAL) zero (for SET_TOT to "1") or a predetermined value, which is determined by the Parameter PRESET_TOT is determined (for SET_TOT on "T), off. Only when the SET_TOT parameter is actively reset to "0” does the "Totalizer” begin to re-integrate, as explained above with reference to the first version.
  • one or the other version may be advantageous for a user.
  • both versions can be provided to the user, and the user can activate the desired version.
  • error may be advantageous for the availability of different versions of software modules:
  • error messages are assigned to individual bit positions (in the case of a cyclic service) or corresponding numbers (in the case of an acyclic service)
  • the same bit positions or numbers should always be assigned to the same errors, with newer field devices, some of which do not cause errors that have occurred with old field devices
  • the present invention is not limited to the embodiments illustrated in the figures and explained above.
  • the respective versions of software modules are already selected in advance by the manufacturer in accordance with a customer request.
  • the user only has to activate the version manager if he wishes a different combination of versions of software modules.
  • the entire software of a field device can also be subdivided into other software modules than was explained above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Stored Programmes (AREA)

Abstract

In einem Verfahren zum Erstellen einer Software in einem Feldgerät (2) der Prozessautomatisierungstechnik durch einen Benutzer, wobei auf dem Feldgerät (2) eine Mehrzahl von Softwaremodulen implementiert ist, wobei für mindestens eines der Softwaremodule mindestens zwei Versionen (4, 6) auf dem Feldgerät (2) implementiert sind, und/oder mindestens ein auf dem Feldgerät (2) implementiertes Softwaremodul eine optional aktivierbare Zusatz-Version (8) ist, wird einem Benutzer eine Auswahlmöglichkeit bereitgestellt, über die er bei mindestens einem Softwaremodul, für das mindestens zwei Versionen (4, 6) auf dem Feldgerät (2) implementiert sind, eine Version (4, 6) auswählen kann und/oder über die er mindestens ein auf dem Feldgerät (2) implemen­tiertes Softwaremodul, das eine optional aktivierbare Zusatz-Version (8) ist, auswählen kann. Anschließend wird/werden die von dem Benutzer ausgewählte(n) Version(en) (4, 6, 8) in dem Feldgerät (2) aktiviert.

Description

Beschreibung Verfahren zum Erstellen einer Software in einem Feldgerät durch einen Benutzer
[0001] Die Erfindung betrifft ein Verfahren zum Erstellen einer Software in einem Feldgerät der Prozessautomatisierungstechnik durch einen Benutzer sowie einen Versionen-manager gemäß dem Oberbegriff des Anspruchs 16.
[0002] 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-Redoxpotential-messgeräte, Leitfähigkeitsmessgeräte, etc., welche die entsprechenden Prozess-variablen 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 Rohrlei-tungsabschnitt bzw. der Füllstand in einem Behälter geändert werden kann.
[0003] Als Feldgeräte werden im Prinzip alle Geräte bezeichnet, die prozessnah eingesetzt werden und die prozessrelevante Informationen liefern oder verarbeiten. Eine Viel-zahl solcher Feldgeräte wird von der Firma Endress + Hauser hergestellt und vertrie-ben.
[0004] In modernen Industrieanlagen sind Feldgeräte in der Regel über
Bussysteme (Profi-bus®, Foundation® Fieldbus, etc.) mit übergeordneten Einheiten verbunden. Dane-ben bestehen die Möglichkeiten einer Parallelverdrahtung sowie einer analogen Signalübertragung zwischen den Feldgeräten und der übergeordneten Einheit. Nor-malerweise 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.
[0005] 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) Stan-dardfunktionsblöcke, wie beispielsweise „Analog Input" (AI), „Analog Output" (AO), „Discrete Input" (Dl) 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 Funktions-gruppen durch zugehörige Softwaremodule in dem Feldgerät realisiert werden.
[0006] In der Re-gel weisen die einzelnen Softwaremodule jeweils die
Funktionsschnitt-stellen bzw. Phasen „Init" (Initialisieren), „Start" (Starten), „Execute" (Ausführen) und „Terminate" (Beenden) auf, wobei die eigentliche Funktion oder Funktionsgruppe des Software-moduls 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 been-det wird.
[0007] 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 vor-han-dene Softwaremodule zu ersetzen, sondern um als zusätzliches Softwaremodul zu den bisher vorhandenen Softwaremodulen hinzugefügt zu werden.
[0008] Bisher wurde im Falle neuer Versionen oder Zusatz-Versionen eine neue Gesamt-software für das Feldgerät erstellt, bei der die Softwaremodule, für die eine neue Version erstellt wur-de, 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 Figuren 1A und 1 B 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 ent-sprechenden Gesamtsoftware ist schematisch in Fig. 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 rea-lisieren 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 Fig. 1 B dargestellt ist.
[0009] Teilweise besteht für den Benutzer ein Bedarf an einer neuen Version eines be-stimmten Softwaremoduls oder an einer Zusatz-Version, da dadurch beispielsweise eine neue Funktionalität bereitgestellt wird und/oder ein Fehler der bisherigen Ver-sion behoben wird. Für andere Softwaremodule, für die neue Versionen verfügbar sind, kann der Benutzer jedoch daran interessiert sein, weiter die bisherigen Ver-sionen 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.
[0010] Demgemäß besteht die Aufgabe der vorliegenden Erfindung darin, ein Verfahren zum Erstellen einer Software in einem Feldgerät der Prozessautomatisierungs-technik bereitzustellen, durch das bei der Verfügbarkeit von neuen Versionen oder von Zu-satz-Versionen von Softwaremodulen spezielle Anforderungen einzelner Benutzer unmittelbarer und auf einfachere Weise berücksichtigt werden können.
[0011] Die Aufgabe wird durch ein Verfahren zum Erstellen einer Software in einem Feld-gerät der Prozessautomatisierungstechnik durch einen Benutzer gemäß Anspruch 1 und durch einen Versionenmanager gemäß Anspruch 16 gelöst. Vorteilhafte Weiter-bildungen der Erfindung sind in den Unteransprüchen angegeben.
[0012] 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 Feldge-rät implementiert sind, und/oder mindestens ein auf dem Feldgerät implementiertes Softwaremodul eine optional aktivierbare Zusatz-Version ist, die nachfolgenden Schritte auf:
[0013] a) Bereitstellen einer Auswahlmöglichkeit für den Benutzer, über die er bei min-destens 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;
[0014] b) Aktivieren der von dem Benutzer ausgewählten Version(en) in dem Feldgerät.
[0015] Das erfindungsgemäße Verfahren lässt sich dabei sehr gut mit Hilfe der Objekt-orien-tierten 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 Software-modulen, für die bereits neuere Versionen verfügbar sind, auf dem Feld-gerät implementiert. Unter „imple-mentiert" wird dabei verstanden, dass die jeweiligen Softwaremodule auf dem Feld-gerät verfügbar sind. Damit die einzelnen Softwaremodule tatsächlich ausgeführt werden können, müssen sie aktiviert werden. Durch das erfindungsgemäße Bereit-steilen einer Auswahlmöglichkeit und das Aktivieren der von dem Benutzer ausge-wählten Version(en) (Versionen und Zusatz-Ver-sionen) wird entsprechend den An-forderungen des Benutzers eine Gesamtsoftware für das Feldgerät erstellt. Die wei-teren Versionen bleiben auf dem Feldgerät verfügbar (implementiert) und können bei Bedarf ausge-wä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-Version(en) Bezug genommen. Bei einer optional aktivierbaren Zusatz-Version han-delt es sich dabei um eine Version, die nicht zwingend für den Betrieb des Feld-ge-rätes erforderlich ist, die aber beispielsweise gegenüber den bisherigen Software-modulen Zusatzfunktionen bereitstellt. Gemäß einer vorteilhaften Weiterbildung der Erfindung sind für mindestens zwei Softwaremodule jeweils mindestens zwei Versionen auf dem Feldgerät implemen-tiert, und der Benutzer kann dann bei diesen mindestens zwei Softwaremodulen jeweils eine Version auswählen, so dass sich für den Benutzer mehrere Kombi-nationsmöglichkeiten ergeben. Um zu vermeiden, dass durch den Benutzer Ver-sionen miteinander kombiniert werden, die nicht miteinander kompatibel sind, ist gemäß einer vorteilhaften Weiterbildung der Schritt des Bereitstellens der Auswahl-möglichkeit derart ausgestaltet, dass nach dem Ausführen einer ersten Auswahl einer ersten Version durch den Benutzer in Abhängigkeit von der getroffenen Aus-wahl für die weiteren Softwaremodule nur noch die Auswahl-möglichkeiten bereit-gestellt werden, die mit der ersten getroffenen Auswahl kompatibel sind. Beispiels-weise 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üg-baren 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 Soft-waremodul(en) 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.
[0017] Gemäß einer vorteilhaften Weiterbildung erfolgt der Schritt des
Bereitstellens der Auswahlmöglichkeit durch einen Versionenmanager, der als Software in dem be-treffenden Feldgerät implementiert ist oder in dieses ladbar ist, und durch den die jeweils in der Auswahlmöglichkeit bereitgestellten Version(en) von Softwaremo-dul(en) aktivierbar sind. Demgemäß ist der Versionenmanager eine Software, in der die einzelnen Ver-sionen von Softwaremodulen erfasst sind oder erfasst werden, und welche die einzelnen Versionen ansteuern kann, um sie zu aktivieren.
[0018] Gemäß einer vorteilhaften Weiterbildung ist vorgesehen, dass der Versionen-manager zusammen mit einer oder mehreren neuen Version(en) von Software-modul(en) 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 be-reitstellt. Beispiels-weise 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 wei-tere Informationen bezüglich dieser Versionen, wie beispielsweise deren Kompa-tibilität, verfügt. Gemäß einer vorteilhaften Weiterbildung wird der Versionenmanager automatisch dann aktiviert und führt den Schritt des Bereitstellens der Auswahl-mö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.
[0019] Vorzugsweise ist vorgesehen, dass der Versionenmanager zusätzlich die Software-module, 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 auto-matisch 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.
[0020] Gemäß einer vorteilhaften Weiterbildung stellt der Versionenmanager eine Doku-mentation für den Benutzer bereit, in der Informationen, welche die aktivierten Ver-sionen 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 akti-vierten 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 aus-ge-druckt werden. Weist das Feldgerät einen integrierten Webserver auf, kann die Doku-men-tation auch direkt von dem Feldgerät über das Internet versendet werden.
[0021] Gemäß einer vorteilhaften Weiterbildung ist das Feldgerät ein an ein
Bussystem, insbesondere ein an ein Profibus®-Bussystem und/oder an ein Foundation®-Field-bus-Bussystem, anschließbares Feldgerät. Vorzugsweise weist das Feldgerät Soft-waremodule auf, die jeweils einzelne Funktionsblöcke, insbesondere Standard-funktionsblöcke, wie beispielsweise einen „Analog Input", einen „Analog Output" und/oder einen „Totalizer" („Totalizer" nur bei Profi-bus®-Bussystem) Funktionsblock, realisieren, die in der Foundation® Fieldbus Spezifikation und der Profibus® Spe-zifikation als Stan-dardfunktionsblö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.
[0022] 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 FaN"), durch die ein Abfall in der Stromversorgung des Feldgerätes erfasst und eine Sicherung der aktuellen Werte des Feldgerätes durchgeführt wird; eine Funktions-gruppe („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 Ein-stellungen an dem Feldgerät vornehmen kann, aktuelle Messdaten von den einzel-nen Funktionsblöcken abrufen kann, die Ausführung einzelner Funktionsblöcke, ins-besondere 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 Serien-nummer, Herstellungsdatum, Hardware-Informationen, Ersatzteil-Informationen, ge-rätespezifische Daten und/oder Informationen über die Konfigurierung des Feld-gerä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 Feld-gerä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 Standard-funktionsblö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 Stan-dardfunktionsblöcke des gleichen Typs oder „Transducer Blocks" aufweist. Bei den weiteren beispielhaft aufgeführten Funktionsgruppen mit den
Kurzbezeich-nungen „Power FaN", „System Parameter", „Kommunikations Parameter", „Pro-duktion", „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 Funktions-gruppen die jeweils angeführten Funktionen auch nur teilweise vorgesehen werden öder es können in den einzelnen Funktionsgruppen weitere Funktionen mit aufge-nommen 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 Eingabe-tasten 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 FaN" auf Abfrage, bei Auftreten von Fehlern und/oder im Falle eines Stromabfalls bereitgestellt werden, können beispielsweise auf der Anzei-ge des Feldgerätes und/oder auf einer Anzeige einer entsprechenden übergeord-neten 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 bereit-stellt. Der „Device Type Manager" stellt Funktionen zum Zugang zu Variablen des Feldgerätes, zum Parametrisieren und Betreiben des Feldgerätes und Diagnose-funktionen bereit. Der „Device Type Manager" wird von dem Hersteller des Feldge-rä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 bereit-gestellten Versionen von Softwaremodulen, zugegriffen wird und diese Informationen über einen Webbrowser abrufbar sind.
[0025] Gemäß der vorliegenden Erfindung wird ferner ein Versionenmanager bereitgestellt, der als Software in einem Feldgerät der Prozessautomatisierungstechnik implemen-tiert ist oder der in solch ein Feldgerät ladbar ist, wobei auf dem Feldgerät eine Mehr-zahl von Softwaremodulen implementiert ist, wobei der Versionenmanager derart eingerichtet ist,
[0026] 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
[0027] b) dass er die von dem Benutzer ausgewählte(n) Version(en) auf dem Feldgerät aktiviert.
[0028] Die oberhalb in Bezug auf das erfindungsgemäße Verfahren erläuterten Weiter-bildungen sind entsprechend bei dem erfindungsgemäßen Versionenmanager möglich, wodurch jeweils die oberhalb genannten Vorteile erzielt werden. Ferner wer-den diese Vorteile auch bei einem Feldgerät erzielt, auf dem eine Mehrzahl von Softwaremodulen implementiert ist und das einen solchen Versionenmanager auf-weist.
[0029] Weitere Vorteile und Zweckmäßigkeiten der Erfindung ergeben sich anhand der nach-folgenden Beschreibung von Ausführungsbeispielen unter Bezugnahme auf die beigefügten Figuren. Von den Figuren zeigen:
[0030] Fig. 1A: eine schematische Darstellung eines Feldgerätes gemäß dem Stand der Technik mit einer Gesamtsoftware einer Basisversion;
[0031] Fig. 1 B: eine schematische Darstellung des in Fig. 1A dargestellten Feldge-rätes mit einer Gesamtsoftware einer neuen Version;
[0032] Fig. 2: eine schematische Darstellung eines Feldbus-Netzwerkes;
[0033] Fig. 3A: eine schematische Darstellung eines Feldgerätes mit mehreren Soft-waremodulen einer Basisversion und einem Versionenmanager ge-mäß der vorliegenden Erfindung;
[0034] Fig. 3B: eine schematische Darstellung des in Fig. 3A dargestellten Feldge-rätes, wobei die Softwaremodule aktiviert sind;
[0035] Fig. 4A: eine schematische Darstellung des in Fig. 3A dargestellten
Feldge-rätes, wobei auf dem Feldgerät zusätzlich neue Versionen und eine Zusatz-Version implementiert sind; und
[0036] Fig. 4B: eine schematische Darstellung des in Fig. 4A dargestellten
Feldge-rätes, wobei einzelne Versionen von Softwaremodulen aktiviert sind.
[0037] Fig. 2 ist eine schematische Darstellung eines kleinen
Feldbus-Netzwerkes, bei dem vier Feldgeräte FGO, FG1 , FG2 und FG3 und eine Steuereinheit SPS an einem Feld-bus F angeschlossen sind. Der Feldbus F arbeitet nach einem der bekannten Feld-bus-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 FGO, FG1 , FG2 und FG3 jeweils Profibus-Slaves sind. Die Kommunikation zwischen der Steuereinheit SPS und den Feldgeräten FGO, FG1 , FG2 und FG3 erfolgt nach dem entsprechenden Profi-bus® Standard.
[0038] In Fig. 3A sind in einem Feldgerät 2, ähnlich wie in Fig. 1A, vier Softwaremodule, die jeweils durch eine Basisversion 4 gebildet werden und die unterschiedliche Funktio-nen 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 Soft-ware ausgebildet ist. In dem Versionenmanager 10 sind die Basisversionen 4 der vier Softwaremodule er-fasst. 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 Aus-fü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.
[0039] Die vier Basisversionen 4 mit den Funktionen F1 , F2, F3 und F4 sind im vorliegen-den Fall für den Betrieb des Feldgerätes 2 zwingend erforderlich. Selbst wenn der Benutzer nicht alle vier Ba-sisversionen 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 an-steuert. Die Ansteuerbarkeit ist schematisch durch die Linien 12 dargestellt, durch welche der Versionenmanager 10 in den Fig. 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 aus-geführt werden. Sie sind in Fig. 3B durch Fettdruck hervorgehoben und werden mit 4' bezeichnet.
[0040] 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 Auswahl-mö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.
[0041] Ähnlich wie bei dem in den Figuren 1A und 1 B 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 rea-lisieren 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 Versionen-manager 101 und die oberhalb genannten Versionen 4, 6 und 8 implementiert sind, ist schematisch in Fig. 4A dargestellt.
[0042] Der Versionenmanager 101 wird nach dem Laden automatisch aktiviert und stellt dem Benutzer eine Auswahlmöglichkeit bereit. Dabei werden auf der entsprechen-den 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 vorge-merkten 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 Fig. 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 Fig. 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' beson-ders hervorgehoben werden, so dass der Benutzer auf einen Blick erkennen kann, welche Versionen ausgewählt wurden.
[0043] Die Implementierung von zwei verschiedenen Versionen von
Softwaremodulen auf einem Feldgerät und die Bereitstellung einer Auswahlmöglichkeit können insbeson-dere in den nachfolgenden Fällen sinnvoll sein.
[0044] Beispielsweise könnten zwei verschiedene Versionen von
Softwaremodulen zur Re-alisierung des Funktionsblocks „Totalizer" vorgesehen werden. Dieser Funktions-block 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 (Para-meter TOTAL). Wird der Parameter SET_TOT auf „1" gesetzt, so wird der Ausgabe-wert (Parameter TOTAL) auf Null gesetzt. Wird der Parameter SET_TOT auf „2" gesetzt, so wird der Ausgabewert (Parameter TOTAL) auf einen vorbestimm-ten Wert gesetzt, der durch einen Parameter PRESET_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 aufzuin-tegrieren, 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 PRESET_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.
[0045] 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 PRESET_TOT bestimmt wird (für SET_TOT auf ,,T), 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.
[0046] Je nach Einsatzbereich und Konfiguration der weiteren, an das Bussystem ange-schlossenen Geräte kann für einen Benutzer die eine oder die andere Version vor-teilhaft 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.
[0047] Ein weiteres Beispiel ist der Fall, dass sowohl eine neue Version für den Funktions-block „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 ange-schlossenen Geräte erfordern. In diesem Fall kann der Benutzer durch die Bereit-stellung der Auswahlmöglichkeit bei den Funktionsblöcken die jeweils gewünschte Version auswählen und aktivieren.
[0048] Auch bei der Realisierung der oberhalb genannten Funktionsgruppe mit der Kurz-bezeichnung „Fehler" kann die Verfügbarkeit verschiedener Versionen von Software-modulen vorteilhaft sein. In der Regel werden in Fehlerlisten einzelnen Fehlern ent-sprechende 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 Ab-hängigkeit von der Konfiguration seines Feldgerä-tes wählen.
[0049] Die vorliegende Erfindung ist nicht auf die in den Figuren dargestellten und oberhalb erläuterten Ausführungsbeispiele beschränkt. Beispielsweise kann zusätzlich vorge-sehen 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.
[0050] In den Ausführungsformen, die in den Figuren dargestellt sind, waren je Software-modul 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.

Claims

Ansprüche
1. 1. Verfahren zum Erstellen einer Software in einem Feldgerät (FG0-FG3; 2) der Prozessautomatisierungstechnik durch einen Benutzer, wobei auf dem Feld-gerät (FG0-FG3; 2) eine Mehrzahl von Softwaremodulen implementiert ist, wobei für mindestens eines der Softwaremodule mindestens zwei Versionen (4, 6) auf dem Feldgerät (FG0-FG3; 2) implementiert sind, und/oder mindestens ein auf dem Feldgerät (FG0-FG3; 2) implementiertes Software-mo-dul eine optional aktivierbare Zusatz-Version (8) ist, aufweisend die nachfolgenden Schritte:
a) Bereitstellen einer Auswahlmöglichkeit für den Benutzer, über die er bei mindestens einem Softwaremodul, für das mindestens zwei Versionen (4, 6) auf dem Feldgerät (FG0-FG3; 2) implementiert sind, eine Version (4, 6) auswählen kann und/oder über die er mindestens ein auf dem Feldgerät (FG0-FG3; 2) implemen-tiertes Softwaremodul, das eine optional aktivierbare Zusatz-Version (8) ist, auswählen kann; b) Aktivieren der von dem Benutzer ausgewählten Version(en) (4, 6, 8) in dem Feldgerät.
2. 2. Verfahren gemäß Anspruch 1 , dadurch gekennzeichnet, dass für mindestens zwei Softwaremodule jeweils mindestens zwei Versionen (4, 6) auf dem Feld-gerät (FG0-FG3; 2) implementiert sind, wobei bei dem Schritt des Bereitstellens der Auswahlmöglichkeit der Benutzer bei diesen mindestens zwei Softwaremodulen jeweils eine Version (4, 6) auswählen kann.
3. 3. Verfahren gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Schritt des Bereitstellens der Auswahlmöglichkeit derart ausgestaltet ist, dass nach dem Ausführen einer ersten Auswahl einer ersten Version (4, 6, 8) durch den Benutzer in Abhängigkeit von der getroffenen Auswahl für die weiteren Soft-waremodule nur noch die Auswahl-möglichkeiten bereitgestellt werden, die mit der ersten getroffenen Auswahl kompatibel sind.
4. 4. Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekenn-zeich-net, dass beim Laden von einer oder mehreren neu verfügbaren Version(en) (4, 6, 8) von Softwaremodul(en) diese in dem Feldgerät (FG0-FG3; 2) zusätzlich zu den bisherigen, auf dem Feldgerät (FG0-FG3; 2) implementierten Versionen (4) von Softwaremodulen implementiert wird/werden.
5. 5. Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekenn-zeich-net, dass der Schritt des Bereitstellens der Auswahlmöglichkeit durch einen Versionenmanager (10; 101) erfolgt, der als Software in dem betreffenden Feldgerät (FG0-FG3; 2) implementiert ist oder in dieses ladbar ist, und durch den die jeweils in der Auswahlmöglichkeit bereitgestellten Version(en) (4, 6, 8) von Softwaremodul(en) aktivierbar ist/sind.
6. 6. Verfahren gemäß Anspruch 5, dadurch gekennzeichnet, dass der Versionen-manager (10; 101) zusammen mit einer oder mehreren neuen Version(en) (6, 8) von Software-modul(en) in das Feldgerät (FG0-FG3; 2) geladen wird, und dass der Versionenmanager (10; 101) die neue(n) Version(en) (6, 8) von Soft-waremodul(en) sowie die bisher auf dem Feldgerät (FG0-FG3; 2) implemen-tierten Versionen (4) von Softwaremodulen dem Benutzer zur Auswahl bereit-stellt.
7. 7. Verfahren gemäß Anspruch 5 oder 6, dadurch gekennzeichnet, dass der Ver-sionenmanager (10; 101) automatisch dann aktiviert wird und den Schritt des Be-reitstellens der Auswahlmöglichkeit durchführt, wenn eine oder mehrere neue Version(en) (6, 8) von Softwaremodul(en) in das Feldgerät (FG0-FG3; 2) geladen wird/werden.
8. 8. Verfahren gemäß einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, dass der Versionenmanager (10; 101) zusätzlich die Softwaremodule, für die keine Auswahlmöglichkeit bereitgestellt wird und die für den Betrieb des Feldgerätes (FG0-FG3; 2) erforderlich sind, automatisch aktiviert.
9. 9. Verfahren gemäß einem der Ansprüche 5 bis 8, dadurch gekennzeichnet, dass in dem Versionenmanager (10; 101) die jeweils aktuellsten Versionen (4, 6, 8) von Softwaremodulen als bevorzugte Auswahl vorgemerkt sind und, falls ein Benutzer keine anderen Versionen (4, 6, 8) auswählt, diese bevorzugte Aus-wahl an Versionen (4, 6, 8) automatisch aktiviert wird.
10. 10. Verfahren gemäß einem der Ansprüche 5 bis 9, dadurch gekennzeichnet, dass der Versionenmanager (10; 101) eine Dokumentation für den Benutzer bereit-stellt, in der Informationen, welche die aktivierten Versionen (4, 6, 8) von Soft-waremodulen betreffen, zusammengestellt sind.
11. 11. Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekenn-zeichnet, dass das Feldgerät (FG0-FG3; 2) ein an ein Bussystem (F), insbe-sondere ein an ein Profibus®-Bussystem und/oder an ein Foundation®-Field-bus-Bussystem, anschließbares Feldgerät (FG0-FG3; 2) ist.
12. 12. Verfahren gemäß Anspruch 11 , dadurch gekennzeichnet, dass das Feldgerät (FG0-FG3; 2) Softwaremodule aufweist, die jeweils einzelne Funktionsblöcke, insbesondere jeweils einen „Analog Input", einen „Analog Output" und/oder einen „Totalizer" Funktionsblock, realisieren.
13. 13. Verfahren gemäß einem der vorangehenden Ansprüche, dadurch gekennzeich-net, dass das Feldgerät (FG0-FG3; 2) Softwaremodule aufweist, die jeweils ein-zelne Funktionen oder Funktionsgruppen des Feldgerätes (FG0-FG3; 2), ins-be-sondere einen „Transducer Block", einen „Physical Block", ein „Device Management", eine Funktionsgruppe („Power FaN"), durch die ein Abfall in der Stromversor-gung des Feldgerätes (FG0-FG3; 2) erfasst und eine Sicherung der aktuellen Werte des Feldgerätes (FG0-FG3; 2) 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 (FG0-FG3; 2) vornehmen kann, aktuelle
Mess-daten von den einzelnen Funktionsblöcken abrufen kann, die
Ausführung ein-zelner Funktionsblöcke, insbesondere des Funktionsblocks
„Totalizer", triggern kann, Einstellungen bezüglich einer zyklischen
Datenübertragung an eine über-geordnete Einheit (SPS) vornehmen kann, und/oder aktuelle Einstellungen des Feldgerätes (FG0-FG3; 2) sowie die
Übertragungsrate an eine übergeordnete Einheit (SPS) abrufen kann; eine Funktionsgruppe („Produktion"), durch die der Benutzer
Herstellerinfor-ma-tionen über das Feldgerät (FG0-FG3; 2), insbesondere eine
Seriennummer, Herstellungsdatum, Hardware-Informationen,
Ersatzteil-Informationen, geräte-spezifische Daten und/oder Informationen über die Konfigurierung des Feld-gerätes (FG0-FG3; 2) durch den Hersteller, abrufen kann; eine Funktionsgruppe („Version-Info"), durch die der Benutzer Informationen über die aktuelle Software des Feldgerätes (FG0-FG3; 2) 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
(FG0-FG3; 2) und/oder bei der Kommunikation mit einer übergeordneten
Einheit (SPS) auftreten oder aufgetreten sind; realisieren.
14. 14. Verfahren gemäß einem der Ansprüche 5 bis 13, dadurch gekennzeichnet, dass relevante Informationen über den Versionenmanager (10; 101) in einer „Device Description" (Gerätebeschreibung) und/oder in einem „Device Type Manager" festgelegt sind, insbesondere dass die relevanten Informationen über den Versionenmanager (10; 101), insbesondere Informationen über die akti-vierten und die in der Auswahlmöglichkeit bereitgestellten Versionen (4, 6, 8) von Softwaremodulen, über den „Device Type Manager" und eine FDT („Field Device Tool") Frame Anwendung in einer übergeordneten Einheit (SPS) abruf-bar sind.
15. 15. Verfahren gemäß einem der Ansprüche 5 bis 13, dadurch gekennzeichnet, dass über einen in das Feldgerät (FG0-FG3; 2) integrierten Webserver auf relevante Informationen über den Versionenmanager (10; 101), insbesondere auf Informationen über die aktivierten und auf die in der Auswahlmöglichkeit bereitgestellten Versionen (4, 6, 8) von Softwaremodulen, zugegriffen wird und diese Informationen über einen Webbrowser abrufbar sind.
16. 16. Versionenmanager, der als Software in einem Feldgerät (FG0-FG3; 2) der Prozessautomatisierungstechnik implementiert ist oder der in solch ein Feldgerät (FG0-FG3; 2) ladbar ist, wobei auf dem Feldgerät (FG0-FG3; 2) eine Mehrzahl von Softwaremodulen implementiert ist, dadurch gekennzeichnet, dass 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 (4, 6) auf dem Feldgerät (FG0-FG3; 2) implementiert sind, eine Version (4, 6) auswählen kann und/oder über die der Benutzer mindestens ein auf dem Feldgerät (FG0-FG3; 2) implementiertes Softwaremodul, das eine optional aktivierbare Zusatz-Version (8) ist, auswählen kann; und b) dass er die von dem Benutzer ausgewählte(n) Version(en) (4, 6, 8) auf dem Feldgerät (FG0-FG3; 2) aktiviert.
17. 17. Feldgerät, auf dem eine Mehrzahl von Softwaremodulen implementiert ist und das einen Versionenmanager (10; 101) gemäß Anspruch 16 aufweist.
PCT/EP2008/059130 2007-08-08 2008-07-11 Verfahren zum erstellen einer software in einem feldgerät durch einen benutzer WO2009019108A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200710037393 DE102007037393A1 (de) 2007-08-08 2007-08-08 Verfahren zum Erstellen einer Software in einem Feldgerät durch einen Benutzer
DE102007037393.9 2007-08-08

Publications (1)

Publication Number Publication Date
WO2009019108A1 true WO2009019108A1 (de) 2009-02-12

Family

ID=39941578

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/059130 WO2009019108A1 (de) 2007-08-08 2008-07-11 Verfahren zum erstellen einer software in einem feldgerät durch einen benutzer

Country Status (2)

Country Link
DE (1) DE102007037393A1 (de)
WO (1) WO2009019108A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009028195A1 (de) * 2009-08-04 2011-02-17 Endress + Hauser Flowtec Ag Erzeugung von konfigurationsspezifischen Gerätetreibern
DE102009046806A1 (de) * 2009-11-18 2011-06-01 Codewrights Gmbh Verfahren zum Bereitstellen von gerätespezifischen Informationen eines Feldgeräts der Automatisierungstechnik
EP2367084A1 (de) * 2010-03-18 2011-09-21 Siemens Aktiengesellschaft Verfahren für die Konfigurierung einer Steuerungseinrichtung einer industriellen Automatisierungsanordnung und Komponente für eine industrielle Automatisierungsanordnung
DE102010062835A1 (de) * 2010-12-10 2012-06-14 Codewrights Gmbh Verfahren zur Erstellung eines kundenspezifischen Setups für eine Bibliothek von Gerätetreibern
US10401816B2 (en) * 2017-07-20 2019-09-03 Honeywell International Inc. Legacy control functions in newgen controllers alongside newgen control functions

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030159135A1 (en) * 1999-12-16 2003-08-21 Dean Hiller Compatible version module loading
US20030199999A1 (en) * 2001-11-08 2003-10-23 Compass Technologies, Inc. Method and apparatus for providing a dynamically programmable field controller
DE102005062811A1 (de) * 2005-12-28 2007-07-05 Siemens Ag Verfahren zum Ansteuern einer modular aus Geräten und Baugruppen bestehenden Produktionsmaschine

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030159135A1 (en) * 1999-12-16 2003-08-21 Dean Hiller Compatible version module loading
US20030199999A1 (en) * 2001-11-08 2003-10-23 Compass Technologies, Inc. Method and apparatus for providing a dynamically programmable field controller
DE102005062811A1 (de) * 2005-12-28 2007-07-05 Siemens Ag Verfahren zum Ansteuern einer modular aus Geräten und Baugruppen bestehenden Produktionsmaschine

Also Published As

Publication number Publication date
DE102007037393A1 (de) 2009-02-12

Similar Documents

Publication Publication Date Title
EP2659317B1 (de) Feldgerät mit langzeit-firmware-kompatibilität
EP1525518B1 (de) Verfahren zum aktualisieren von gerätebeschreibungen für feldgeräte der prozessautomatisierungstechnik
DE102008019053B4 (de) Verfahren zum Betreiben einer Anlage der Prozessautomatisierungstechnik
DE102007026678A1 (de) Verfahren zum Austausch eines defekten Feldgerätes gegen ein neues Feldgerät in einem über digitalen Feldbus kommunizierenden System, insbesondere Automatisierungssystem
DE102010029952A1 (de) Verfahren zum Integrieren von zumindest einem Feldgerät in ein Netzwerk der Automatisierungstechnik
DE102009054901A1 (de) Verfahren zur offline Bedienung eines Feldgeräts der Automatisierungstechnik
WO2009074544A1 (de) Verfahren zum betreiben eines systems aufweisend ein feldgerät und ein bediensystem
WO2009047193A1 (de) Verfahren zum bedienen von feldgeräten der prozessautomatisierungstechnik mit einem geräteunabhängigen bedienprogramm
DE102007054417A1 (de) Bestimmen von geräteinternen Parameteradressen aus feldbusspezifischen Parameteradressen eines Feldgerätes
DE102010063854A1 (de) Verfahren zum Bereitstellen von gerätespezifischen Informationen eines Feldgeräts der Automatisierungstechnik und/oder zum Bedienen eines Feldgeräts
WO2009060000A1 (de) Bedienung eines wireless adapters über ein daran angeschlossenes feldgerät
DE102006062478A1 (de) Verfahren zum Betreiben eines objektbasierten Konfigurationssystems für Feldgeräte der Automatisierungstechnik
EP1714197B1 (de) Gerätetreiber für feldgeräte der prozessautomatisierungstechnik
WO2012013424A1 (de) Verfahren zur integration eines ersatz-feldgeräts anstelle eines feldgeräts in ein feldbussystem
WO2009019108A1 (de) Verfahren zum erstellen einer software in einem feldgerät durch einen benutzer
DE102007026602A1 (de) Einrichtung und Verfahren zum Prüfen der aktuellen Softwareinstallation von Feldgeräten eines verteilten Systems, insbesondere Automatisierungssystems
DE102007062395B4 (de) Verfahren zum Parametrieren eines Feldgerätes der Prozessautomatisierungstechnik
WO2008058991A1 (de) Verfahren zum betreiben eines nach dem blockmodell arbeitenden modularen feldgerätes der automatisierungstechnik
DE102008042919A1 (de) Feldgerät der Prozessautomatisierungstechnik
EP2486459B1 (de) Feldbus-Interface und Verfahren zum Betreiben desselben
DE102008043095A1 (de) Verfahren zum Parametrieren eines Feldgerätes
EP1495381B1 (de) Messeinrichtung f r die prozesstechnik und betriebsverfahren f r eine messeinrichtung
DE102013114406A1 (de) Verfahren zum Parametrieren eines Feldgerätes der Automatisierungstechnik
EP2095193B1 (de) Verfahren zum betreiben eines nach dem blockmodell arbeitenden feldgerätes für ein verteiltes automatisierungssystem
WO2002099546A1 (de) Verfahren zum festlegen von automatisierten prozessen

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08775041

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 08775041

Country of ref document: EP

Kind code of ref document: A1