Method for establishing menu page on host having display

Abstract

The invention relates to a method for establishing a menu page on a host having a display. A method for establishing a menu page on a host having a display wherein a field device, in particular a sensor, is connected to the host, the method comprising the steps of: creating a list for the host, the list comprising at least one sensor reference parameter; sending the list from the host to the field device (subscription); sending (streaming) the value of the at least one sensor reference parameter from the field device to the host once the list is on the field device and once the value of the at least one sensor reference parameter changes; and establishing and displaying a menu page on the display with the current value of the at least one sensor reference parameter.

Description

Technical Field

[0001] The invention relates to a method for creating a menu page on a host computer having a display, wherein field devices, in particular sensors, are connected to the host computer. Background Art

[0002] Field devices for capturing and / or modifying process variables are frequently used in process automation technology. Sensors such as fill level measuring devices, flow meters, pressure and temperature measuring devices, pH-redox potentiometers, conductivity meters, etc. are used to record corresponding process variables such as fill level, flow, pressure, temperature, pH level and conductivity. All devices that are process-oriented and supply or process process-related information are referred to as field devices. In addition to the above-mentioned sensors, units that are directly connected to the fieldbus and are used to communicate with superordinate units, such as remote I / Os, gateways, linking devices and wireless adapters, are also often referred to as field devices. The company group Endress+Hauser produces and distributes a wide variety of such field devices.

[0003] Prior to startup, and in order to modify the functionality of a field device, it must be parameterized. An operating tool is used for parameterization, in particular for reading and / or writing parameters. Such an operating tool is usually implemented in a communication unit separate from the field device in question and is connected to the field device via a fieldbus or via a service interface of the field device (if necessary, via the service interface of the field device, also communicating using a manufacturer-specific protocol). Moreover, such a field device must be parameterized accordingly by the control system in order to integrate the field device into the control system. In addition to parameterization, diagnosis of the field device is also possible.

[0004] For this purpose, field devices offer the possibility of performing parameterization or diagnostics using a computer program developed specifically for a given field device. In order to reduce the effort required to write a separate program for each field device, the cross-manufacturer concept of FDT / DTM was introduced in automation technology, with the aim of requiring only one program for all field devices. FDT stands for "Field Device Tool" and standardizes the communication and configuration interface between all field devices and control systems. The FDT interface is specifically used for this purpose and standardizes the data exchange between field devices, control systems and / or asset management systems. The basis of this concept is the so-called FDT frame application, also called FDT host by experts, which is a software program that loads a device type manager (DTM for short). The device type manager is essentially a driver that contains all the functions, structures, parameters and graphical user interfaces (GUIs) for a specific field device or possible device family and is provided by the field device manufacturer. Via the FDT host into which the device type manager has been loaded, the field device can be parameterized and / or optionally the diagnostic steps can be performed by a higher-level unit such as an operating tool or control system.

[0005] In addition to the above-mentioned techniques, so-called device descriptions (DD) are used to perform parameterization and / or diagnosis of field devices. These device descriptions of integrated field devices are based on so-called machine description languages, such as the Electronic Device Description Language (EDDL) standardized in IEC 61804-3. EDDL is a text-based description language for describing field devices and their functions. The description is based on syntactic and semantic specifications or rules and is similar to a simple programming language. The description generated in one or more files is therefore also referred to as an electronic device description file (EDD file). The device description is installed on a host, such as a handheld device, a laptop computer, etc., and enables access to all data and parameters of the corresponding field device.

[0006] In addition to the two concepts mentioned above, the FDI (Field Device Integration) specification was created, which brings together the two field device integration technologies FDT / DTM and DD / EDDL. The FDI standard provides support for multiple process control communication protocols (e.g., HART, Foundation Fieldbus, and Profibus), enabling process control systems to manage field devices using a common toolset. This common toolkit, called the FDI device grouping, includes everything a host system (such as a process control system) consisting of a server and a client needs to integrate field devices. Each FDI device grouping must contain a device description (EDD), which includes various parameter definitions, parameter structures for context-specific considerations, and automated device processes, such as calibration for specific field devices. FDI device groups can contain user interface plug-ins, i.e., software components that support modern device startup and diagnostic functions.

[0007] Parameterization of field devices can be done either in advance, i.e. before startup and offline, or with field devices already connected to the fieldbus, i.e. "online".

[0008] In process automation, the term "online parameterization" refers to the process of reading and changing the settings (parameters) of a field device via a remote connection (usually a fieldbus such as HART or PROFIBUS). The above-mentioned technique of loading a device driver into a host application is suitable for this purpose. The device driver contains a description of the device menu, which can be used to display the device settings in menu pages. The user navigates through these menu pages and in each case obtains access to the parameters referenced in the page. When the menu page is displayed, the current value of the referenced parameter is read from the field device. In some cases, the parameters (e.g., measured values, system status parameters) are also periodically re-read from the field device.

[0009] The prior art reads the parameters of a menu page as follows: a "request" for a parameter (or a fixed group of parameters with a limited size) is sent from the host to the field device. The field device sends the value of the parameter in a "response". The application must wait to receive the response before it can send the next request.

[0010] In recent years, new transmission technologies have also become established in process automation, such as Bluetooth LE (Low Energy). These have higher data rates than HART, for example, but have significant latency, in the order of 100ms.

[0011] Even established technologies (such as the above-mentioned FDI) can use Bluetooth LE, WiFi and similar technologies as transmission medium. However, the disadvantage of the above-mentioned "request / response process" is that it takes a long time to transmit all the parameters of the menu page, because each request is delayed. This results in a loading time of several seconds for the content of the menu page, so the user has to wait until he can continue. This is especially true when existing drivers for field devices are used with newer transmission types (such as Bluetooth).

[0012] The invention is based on the object of speeding up the menu construction, in particular reducing delays, and above all continuing to use existing drivers for field devices even in the case of modern transmission types. Summary of the invention

[0013] The object is achieved by a method for creating a menu page on a host having a display, wherein a field device, in particular a sensor, is connected to the host. The method comprises the following steps: creating a list for the host, the list comprising at least one sensor reference parameter; sending the list from the host to the field device; once the list is on the field device and once the value of at least one sensor reference parameter changes, sending the value of at least one sensor reference parameter from the field device to the host; and creating and displaying a menu page on the display with the current value of at least one sensor reference parameter.

[0014] The proposed claimed method extends established techniques, such as EDD and FDI (see below), with extensions that minimize delays during operation / parameterization and thereby the disruptive effects of latency. Depending on the design of the method, existing device drivers can be reused unchanged or slightly extended. Only small adjustments to the host application and field device software enable the delay problems of the claimed method to be avoided.

[0015] The request / response process of common technologies (such as EDD, FDI) for online parameterization of field devices in process automation is almost transparently extended for delay-prone transmission media (such as Bluetooth LE, WiFi) by a subscription streaming method, which sends the values ​​of relevant parameters in a delay-optimized manner and converts existing requests into local accesses to cached parameter values. Without major development efforts, existing technologies (e.g., EDD, FDI) can be used with transmission media such as Bluetooth LE or WiFi in a manner that minimizes waiting time for operators.

[0016] One embodiment provides that the at least one sensor reference parameter is a setting of the field device, a measured value of the field device, diagnostic information of the field device, an event counter of the field device, and / or a system status display of the field device.

[0017] An embodiment provides that at least one sensor reference parameter is a dynamic parameter, ie a parameter that changes frequently and rapidly.

[0018] One embodiment provides that the host is designed as an FDI host, an EDD host, an FDT host or an FDT-based FDI host.

[0019] One embodiment provides that the host is configured as a client / server application.

[0020] One embodiment provides that the method further comprises the steps of storing the sent value of the at least one sensor reference parameter in a cache on the host, and establishing a menu page based on the value in the cache.

[0021] One embodiment provides that the cache contains all sensor reference parameters for all lists.

[0022] One embodiment provides for a backup to be created and / or restored.

[0023] One embodiment provides that a list is created for each menu page.

[0024] One embodiment provides that the list is iterative and adaptive and includes the most frequently changing sensor reference parameters.

[0025] One embodiment provides that the new list replaces the previous list.

[0026] An embodiment provides that the list is created by a parser, in particular an interpreter, on the host computer.

[0027] One embodiment provides that the list is created in advance and is stored separately, in particular together with the device description. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] This is explained in more detail with reference to the following figures.

[0029] Figure 1 A measuring system with a host and a field device is shown.

[0030] Figure 2 A prior art method for building a menu page is shown.

[0031] Figure 3 The claimed method for creating a menu page is shown.

[0032] In the drawings, like features are marked with like reference numerals. DETAILED DESCRIPTION

[0033] Figure 1 A measuring system with a host 1 and a field device 2 is shown. The host comprises a display / GUI (reference numeral 7). "Host 1" in this document comprises hardware (i.e. a computer with a display 7) and software, such as an FDI host, an EDD host, an FDT host or an FDI host based on FDT. Examples of hardware are a control center PC, a laptop, a tablet or a handheld computer, etc., such as the "FieldXpert" product from the Endress+Hauser group. An example of software is the "FieldCare" product from the Endress+Hauser group. The field device 2 is, for example, a sensor. The sensor 1 comprises a plurality of parameters 3. The host 1 has local access 5 to the device description 6, for example as part of an FDI packet from a drive. The field device 2 is connected to the host 1 via remote access 4, such as Bluetooth or HART.

[0034] Figure 2 A prior art method for setting up a menu page is shown. If a page is left, a new page is set up from a static description. The GUI 7 receives this information as part of an FDI packet from the description of the device menu via local access 5, for example from a driver. This new page must be filled with the current value of the parameter 3. To this end, the host 1 sends a "request" with a separate parameter 3 to the field device 2, which responds with a "response" with the value of the parameter. This is sensitive to delays. Only once all parameters have been requested can a new page be set up. This can sometimes take several seconds. Figure 2 Two requests with parameters are shown, but there can be more.

[0035] on the contrary, Figure 3 The claimed method for creating a menu page is shown.

[0036] The solution to the delay problem consists in extracting a list 8 of relevant parameters 3 ("sensor reference parameters" and / or a plurality of sensor reference parameters) from the description of a menu page (e.g. an EDDL code in an FDI packet) in the host 1. Thus, a list 8 is created for the host (e.g. by the host itself; see below), the list 8 comprising at least one sensor reference parameter 3. The list may contain various parameters 3. This list 8 is sent as a whole to the field device 2. The field device supports a suitable transmission protocol. This process is a subscription or "subscription" process, since the host 1 informs the field device 2 which parameters 3 are relevant to the host application in the current situation.

[0037] The field device 2 then immediately sends the current values ​​of these parameters 3, without having to wait for a response from the host application in each case. This is called "streaming" or "streaming". If the value of a particular parameter 3 in the current list 8 changes at a later point in time, the current value is sent to the host 1 without the host 1 having to take any action itself. In one embodiment, a periodic check can be performed to see if the value has changed.

[0038] Finally, a new menu page has been created and is shown on the display 7 together with the current value of the sensor reference parameter 3.

[0039] Transmitting a new list will replace the previous list.

[0040] In practice, the delay only works between sending the (first) list and receiving the first parameter value.

[0041] In the host 1 the received parameter values ​​are cached; this is cache 9. A menu page is built based on the values ​​in the cache.

[0042] Requests of existing communications of the host application (when setting up a menu page and during periodic reading) are now redirected to this cache 9, ie converted into local accesses. The first request may need to be delayed until the cache is full.

[0043] In one embodiment, the cache contains exactly the parameters of the active page.

[0044] In one embodiment, the list 8 is iteratively and adaptively populated with the most frequently changing sensor reference parameters 3. This limits the cache 9 to frequently exchanged parameters. The list can be saved in the GUI 7 and reloaded when reconnecting to the device.

[0045] In one embodiment, the list 8 is created by a parser, in particular an interpreter, on the host. The interpreter of the menu description (e.g. in EDDL) is therefore extended so that when parsing the information of the menu page to be displayed, it builds a list 8 of all reference parameters 3 of this page. In one embodiment, the list is pre-calculated and the list of the current page in each case is loaded from the driver.

[0046] In one embodiment, the interpreter of the menu description is extended such that when parsing the device description it (only) builds a list 8 of dynamically changing parameters 3, such as measured values, diagnostic information or event counters.

[0047] In one embodiment, the list 8 contains only the parameters 3 that change frequently.

[0048] In one embodiment, this list 8 is established per menu page or across the entire menu. This primarily speeds up the polling process. The parameters 3 for configuration may be displayed only on a particular page. However, the parameters 3 may be displayed as information on another page, or referenced in the visibility conditions of other menu items. In addition, in one embodiment, there are pure display parameters to be displayed in different locations, such as measured values, i.e., each page has a separate list of reference parameters, and these lists may overlap.

[0049] Thus, there is at least the option of maintaining a separate list for each menu page or providing a global list for the entire menu structure (ie, the totality of all menu pages). There may also be a kind of "favorites list" containing the most frequently referenced parameters.

[0050] In one embodiment, the list is pre-created and stored separately from the device description. For example, during the development of the device description (e.g., FDI packet), an external (offline) parser can be used to pre-compute the list 8 of parameters 3 for each menu page and store them with the regular description. The existing parser is extended to report changes to the page with its identification.

[0051] With the aid of the claimed method, a larger amount of parameters 3 can be sent—up to the entirety of parameters 3, for example in order to create or restore a backup.

[0052] List of reference symbols

[0053] 1 Host

[0054] 2. Field equipment

[0055] 3 (Sensor Reference) Parameters

[0056] 4 Remote Access

[0057] 5. Local Access

[0058] 6Description of the Device Menu

[0059] 7Display / GUI

[0060] 8 List

[0061] 9 Cache

Claims

1. A method for establishing a menu page on a host having a display, wherein: Field devices, in particular sensors, are connected to the host, The method comprises the following steps: - creating a list for the host, the list comprising at least one sensor reference parameter; - sending the list from the host to the field device (subscription); - sending the value of the at least one sensor reference parameter from the field device to the host (streaming) as soon as the list is on the field device and as soon as the value of the at least one sensor reference parameter changes; and - Creating and displaying said menu page on said display with the current value of at least one sensor reference parameter.

2. The method according to the preceding claim, in, The at least one sensor reference parameter is a field device setting, a field device measurement value, a field device diagnostic information, a field device event counter, and / or a field device system status indicator.

3. The method according to any one of the preceding claims, in, The at least one sensor reference parameter is a dynamic parameter, ie a parameter that changes frequently and rapidly.

4. The method according to any one of the preceding claims, in, The host is designed as an FDI host, an EDD host, an FDT host or an FDT-based FDI host.

5. The method according to any one of the preceding claims, further comprising the steps of: - storing the sent value of at least one sensor reference parameter in a cache on the host and building the menu page based on the value in the cache.

6. The method according to the preceding claim, in, The cache contains all sensor reference parameters for all lists.

7. The method according to the preceding claim, in, Create and / or restore backups from this.

8. The method according to any one of the preceding claims, in, Create a list for each menu page.

9. The method according to any one of the preceding claims, in, The list is iterative and adaptive and includes the most frequently changing sensor reference parameters.

10. The method according to any one of the preceding claims, in, The new list replaces the previous list.

11. The method according to any one of the preceding claims, in, The list is created by a parser, in particular an interpreter, on the host computer.

12. The method according to any one of the preceding claims, in, The list is created in advance and is stored, in particular separately from the device description.

Images