Method for parameterizing a field device

Abstract

The present disclosure relates to a method for parameterizing a field device of process automation technology, comprising at least the following steps: parameterizing a mapping of the field device, wherein the mapping is executed as field-device-specific software on an interpreter, especially a software emulator; wherein the interpreter is executed on a host and there is no connection between host and field device during parameterization, and transmitting the parameterization generated via the mapping to the field device.

Claims

1. A method for parameterizing a field device of process automation technology, comprising the steps of: providing a field-device-specific software, wherein the field-device-specific software includes an entirety of software components of the field device; providing a host and an interpreter running on the host; executing the field-device-specific software on the interpreter on the host; parameterizing the field-device-specific software running on the interpreter, wherein there is no connection between host and field device during parameterization; and transmitting the parameterization generated via the field-device-specific software to the field device.

2. The method according to claim 1, wherein the host is a device type manager (DTM) and the interpreter is executable in the device type manager as part of the device type manager.

3. The method according to claim 1, wherein the host is a web server and the interpreter is executed on the web server.

4. The method according to claim 1, wherein the host is a mobile device and the interpreter is executed thereon as an app or as part of an app.

5. The method according to claim 1, wherein the host includes a memory which stores the field-device-specific software and holds the field-device-specific software available, and wherein the field-device-specific software can be reloaded via a data carrier or via a data connection of the host.

6. The method according to claim 5, wherein the field-device-specific software includes a plurality of subfragments.

7. The method according to claim 1, wherein a current parameterization of the field device is first loaded from the field device to the host via a data connection before the start of the parameterization process.

8. The method according to claim 5, wherein the field-device-specific software is first loaded directly from the field device to be parameterized to the host via a data connection.

9. The method according to claim 1, wherein the interpreter includes a software emulator and a virtual processor, and wherein the executing of the field-device-specific software includes executing field-device-specific software machine code on the emulator and the virtual processor on the host.

10. A method for parameterizing a field device of process automation technology, comprising the steps of: parameterizing a mapping of the field device, wherein the mapping is executed as field-device-specific software on an interpreter, wherein the interpreter is executed on a host and there is no connection between host and field device during parameterization; and transmitting the parameterization generated via the mapping to the field device, wherein the host includes a memory which stores field-device-specific software and holds the field-device-specific software available, wherein the field-device-specific software can be reloaded via a data carrier or via a data connection of the host, and wherein the field-device-specific software is first loaded directly from the field device to be parameterized to the host via a data connection.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) This will be explained in more detail with reference to the following figures.

(2) FIG. 1a/b shows a schematic overview of the claimed method.

(3) FIG. 2 shows a measuring transducer with field-device-specific software.

(4) FIG. 3a/b shows a measurement arrangement comprising a measuring transducer in two different embodiments.

DETAILED DESCRIPTION

(5) In the figures, the same features are identified with the same reference characters.

(6) FIG. 1a shows a schematic overview of the first step of the claimed method. A user A parameterizes thereby a mapping 1′ of a field device 1. The field device 1 is, for example, a sensor 5. The field device 1 is, however, also a measuring transducer 20, for example. In the following, a “field device” should always be understood to mean a measuring transducer, unless otherwise mentioned.

(7) The mapping 1′ is a field-device-specific software 60 which is executed in an interpreter 50. The interpreter 50 is executed on the host 70. There is no connection between the host 70 and the actual, i.e. real, field device 1.

(8) The interpreter 50 is embodied as an emulator, more precisely as a software emulator.

(9) The interpreter 50 executes the machine code of the guest system, that is, the mapping 1′ in the form of the field-device-specific software 60 on a virtual processor on the host 70.

(10) In general, a system that simulates another system in certain partial aspects is called an emulator. The simulated system receives the same data as, executes the same programs as or at least programs comparable to, and achieves results as similar as possible to the system to be emulated. Software emulators are programs that simulate a computer and thus allow the use of software for this computer on a computer with a different architecture.

(11) In the interpreter 50, at least one—preferably, precisely one—field-device-specific software 60 (per interpreter 50) is executed. Several interpreters 50 can be executed per host 70.

(12) In one embodiment, the interpreter 50 is not designed as an emulator, but as a script language interpreter. In one embodiment, this script language is Lua. Other examples are Python, VBA, Lisp, VBScript, or JScript. It is basically also possible to install and start various script language interpreters on a host 70. When several interpreters 50 are executed on a host, the individual interpreters 50 communicate with one another by means of standardized interfaces. In general, the interfaces are defined as a central part of the overall system infrastructure and are designed to be compatible over years, even if in the future extensions and modifications are performed, for example a different type of data types, such as the transmission of complex spectra instead of measured values, which are typically transmitted as a value with the corresponding unit.

(13) Various embodiments are possible for the host 70. The respective host comprises a corresponding interpreter, wherein the field-device-specific software 60 executable thereon is always the same. In one embodiment, the interpreter 50 is embodied as a common part on all possible architectures of the host 70; only the necessary interfaces with its respective own components, such as the respective input and output possibilities, are specific to the respective host and are adapted accordingly. In doing so, the interpreter 50 can, for example, be written in a cross-platform programming language, such as C, so that the source code of the interpreter is, in principle, then the same for all different platforms.

(14) The host 70 is executed, for example, as a device type manager (DTM). An interpreter 50 is executed as part of the DTM.

(15) Also, the host 70 may be designed as a web server and the interpreter 50 executed thereon.

(16) The host 70 can also be designed as a mobile device on which the interpreter is executed, for instance as an app.

(17) The field-device-specific software 60 thus constitutes signal processing of sensor data (see below), one or more state machines, parameterization of the field device 1, menu navigation of the field device 1, or a field bus connection of the field device 1.

(18) It makes no difference to the user A whether the field device 1 is operated directly or whether the mapping 1′ is accessed via the interpreter 50 in the host 70. The menu navigation with all menus, together with possible parameter settings, is mapped exactly, since the mapping 1′ is realized from the same software which is executed in field device 1.

(19) To this end, the field-device-specific components must be loaded once onto the host 70 in order to subsequently be executed within its interpreter 50. There are various possibilities for this, which will be discussed in the following.

(20) For this purpose, the host 70 comprises a memory 71 on which the field-device-specific software 60 is stored. The field-device-specific software 60 is loaded into the emulator 50 from the memory 71 which is indicated in FIG. 1a by the dashed arrow. Alternatively or in addition to storing the field-device-specific software 60 in the memory 71, host 70 comprises a connectivity for an external memory, such as a memory card (for instance an SD card). In an alternative, the host 70 establishes a data connection to the Internet and downloads the software appropriate to the respective field device 1 or 1′. Based upon a unique identification of the field device 1, the correct software is found in each case.

(21) The user A thus parameterizes the mapping 1′ of the field device 1 in the host 70. The user thus undertakes a complete parameterization P of the field device.

(22) It is possible for the presently current parameterization of the field device 1 to be initially transmitted from the field device 1 to the host 70 so that the most current version of the parameters is present on the host. The transmission is effected, for example, via a backup of the device parameterization, for example on an SD card, via a field bus, Ethernet or a radio connection.

(23) In the next step, see FIG. 1b the parameterization P is transmitted from the host 70 to the real field device 1. The field device 1 receives the parameterization P and populates either the entire parameterization. Alternatively, only the differences from the presently current parameterization are populated. The presently current parameterization of the field device 1 is thereby overwritten in each case by the offline parameterization P effected.

(24) As mentioned, field device 1 is embodied as a measuring transducer 20, see also below and especially FIG. 3a/b. The measuring transducer can also be embodied as a multi-channel measuring transducer. A sensor 5 or a plurality of sensors (“multi-channel”) can be connected to the measuring transducer 20.

(25) The measuring transducer 20 may comprise an interpreter 50 as shown in FIG. 2. The same applies to this interpreter as was stated above with respect to an interpreter 50 on a host 70. The field-device-specific software 60 as mapping 1′ of the field device 1, i.e. of the measuring transducer 20, can be run on the interpreter 50. It is thus possible that large parts of the software of the measuring transducer are not executed “natively” i.e. directly by a CPU, but rather in an interpreter 50. Thus, one or more state machines, the parameterization of the measuring transducer 20, its menu navigation or the field bus connection run in the interpreter 50.

(26) In this case, the measuring transducer 20 represents an embodiment of a host 70.

(27) The entire parameterization P of the measuring transducer 20 is formed by the parameters contained therein. There are, on the one hand, parameters relating to the connected sensor 5, for example a temperature offset correction. On the other hand, there are parameters relating to the measuring transducer 20 itself, for instance a current output configuration (e.g. current spreading). Both types of parameters can be directly adjusted “natively” in the measuring transducer, for example via an operating interface present there (e.g. via display 22, which can also be embodied as a touchscreen, or via buttons, switches, etc. present on the measuring transducer).

(28) Field device specific software 60 running in the measuring transducer 20 includes, inter alia, the totality of all parameters provided by the measuring transducer 20, i.e., measuring-transducer-specific and sensor-specific parameters. By virtue of the fact that the field-device-specific software 60 can be executed in the form of a mapping 1′ in an interpreter 50 of a host 70, the adjusting of said parameters is also possible in the host 70.

(29) If the field-device-specific software 60 is constructed from a plurality of partial fragments, for example by measuring-transducer-specific and sensor-specific fragments, the number of adjustable parameters depends on the specific physical interconnection of the field device 1. This applies especially to multi-channel measuring transducers to which any combination of sensors can be connected. If the physical interconnection of field device 1 is known, the same manifestation of the field-device-specific software 60 can thus be formed in the host 70 and executed as mapping 1′ in the interpreter 50.

(30) FIGS. 3a and 3b show a sensor arrangement 10 with a measuring transducer 20 for executing the method.

(31) The claimed measuring transducer 20 is used, for example, in a sensor arrangement 10. The sensor arrangement 10 comprises a sensor 5 and a connection element 11, which shall be discussed first.

(32) A sensor 5 communicates with the measuring transducer 20 via a first physical interface 3. An alternative word for measuring transducer is transmitter. The measuring transducer 20 in turn is connected to a higher-level unit 30, such as a control system, by a cable 31. A cable 21 is connected on the sensor side to the measuring transducer 20, the cable's other end comprising a second physical interface 13 that is complementary to the first physical interface 3. A connection element 11 comprises the cable 21, along with the second physical interface 13. The physical interfaces 3, 13 are designed as electrically isolated, especially inductive, interfaces. The physical interfaces 3, 13 can be coupled with each other by means of a mechanical plug connection. The mechanical plug connection is hermetically sealed, so that no fluid, such as the medium to be measured, air, or dust, can enter from the outside.

(33) Data (bi-directional) and power (uni-directional, i.e., from the connection element 11 to the sensor 5) are transmitted or transferred via the physical interfaces 3, 13. Sensor assembly 10 is used predominantly in process automation.

(34) The sensor 5 comprises at least one sensor element 4 for detecting a measurand of process automation. The sensor 5 is then, for example, a pH sensor, also [called] ISFET, generally an ion-selective sensor, a sensor for measurement of the redox potential, from the absorption of electromagnetic waves in the medium, e.g., with wavelengths in the UV, IR, and/or visible range, of the oxygen, of the conductivity, of the turbidity, of the concentration of non-metallic materials, or of the temperature, along with the respectively corresponding measurand.

(35) The sensor 5 further comprises a first coupling body 2, which comprises the first physical interface 3. As mentioned, the first physical interface 3 is designed for the transmission to a second physical interface 13 of a value that is a function of the measurand. The sensor 5 comprises a data processing unit μCS, such as a microcontroller, which processes the values of the measurand, e.g., converts them into a different data format. The data processing unit μCS is designed for energy and space reasons to be rather small or economical with respect to the computing capacity and the memory volume. The sensor 5 is thus designed only for “simple” computing operations—for example, for averaging, preprocessing, and digital conversion.

(36) Several sensors 5 can also be connected to a measuring transducer 20. Shown in FIG. 3a are two sensors 5, wherein only one of the two is provided with all of the reference characters. The same or different sensors can be connected. The left one of the two is shown in the plugged-in state. If the measuring transducer 20 is embodied as a multi-channel measuring transducer, up to eight sensors 5 can be connected, for example.

(37) The sensor 5 can be connected via the physical interfaces 3, 13 to the connection element 11, and ultimately to the measuring transducer 20. The data processing unit μCS converts the value that depends upon the measurand (i.e., the measurement signal of the sensor element 4) into a protocol that the measuring transducer 20 can understand. An example in this regard is, for example, the applicant's proprietary Memosens protocol. The first and second physical interfaces 3, 13 are thus designed for the bi-directional communication between the sensor 5 and the measuring transducer 20. As mentioned, in addition to the communication, the first and second physical interfaces 3, 13 also ensure the supply of power to the sensor 5.

(38) The connection element 11 comprises the second physical interface 13, wherein the second physical interface 13 is designed to be complementary to the first physical interface 3. The connection element 11 likewise comprises a data processing unit μCA. The data processing unit μCA may serve as a repeater for the transmitted signal. Furthermore, the data processing unit μCA can convert or modify the protocol.

(39) The connection element 11 comprises a second, cylindrical coupling body 12 that is designed to be complementary to the first coupling body 2 and can be slipped with a sleeve-like end portion onto the first coupling body 2, wherein the second physical interface 13 is plugged into the first physical interface 3. An opposite arrangement, in which the second physical interface 13 is designed to be sleeve-like and the first physical interface 3 is designed to be plug-like, is possible, without any inventive effort.

(40) The measuring transducer 20 comprises a display 22 and one or more operating elements 23, such as buttons or rotary buttons, by means of which the measuring transducer 20 can be operated. Measured data, for example, of the sensor 5 are displayed by the display 22. The sensor 5 can also be configured and parameterized by means of the operating elements 23 and the corresponding view on the display 22.

(41) The measuring transducer 20 forwards (communication 35) the measured data of the sensor 5 via the cable 31, as mentioned, to a control system 30, for example. The control system 30 is in this case designed as a process control system (PLC, SPS), PC, or server.

(42) To this end, the measuring transducer 20 converts the data into a data format that the control system can understand, e.g., into a corresponding bus, such as HART, Profibus PA, Profibus DP, Foundation Fieldbus, Modbus RS485, or even into an Ethernet-based field bus, such as EtherNet/IP, Profinet, or Modbus/TCP. These data are then forwarded to the control system 30. This can, if required, be combined with a web server, i.e., they can be operated in parallel to one another.

(43) FIG. 3b represents an embodiment of a sensor arrangement 10. In this case, only one sensor 5 is respectively connected to a measuring transducer 20. The measuring transducer 20 is in this case illustrated symbolically as a rectangle, is smaller in its dimensions than the measuring transducer from FIG. 3a, and is approximately the size of a matchbox. The measuring transducer 20 can in this case be designed as a separate unit that can be connected to the cable 21 or, as shown here, be integrated directly into the cable 21. The measuring transducer 20 thus consists essentially of the data processing unit μCA. The measuring transducer 20 does not comprise a display and has, if any, only one or two operating elements, which are configured for a reset or for turning on and off. In this embodiment, the measuring transducer 20 preferably comprises no operating elements. The measuring transducer 20 therefore comprises a wireless module 24, such as a Bluetooth module, with the Bluetooth Low Energy protocol stack. A mobile device (not shown), such as a cellphone, tablet, laptop, etc., can thereby be wirelessly connected to the measuring transducer 20. By means of the mobile device, the sensor 5 can be configured and parameterized using the wireless connection via the wireless module 24. The measuring transducer 20 converts the raw measured data such that they are directly transmitted to a higher-level unit 30, such as the control system. As mentioned, data can, for example, be transmitted in a proprietary protocol from the sensor 5 to the connection element 11, while the data processing unit μCA converts this proprietary protocol into a bus protocol (Modbus, Foundation field bus, HART, Profibus, EtherNet/IP; see above). The measuring transducers in FIG. 3a and FIG. 3b essentially have the same basic functionality.