Method for building a menu page on a host with a display

Abstract

The invention discloses a method for constructing a menu page on a host with a display, wherein a field device, in particular a sensor, is connected to the host, the method comprising the steps: creating a list for the host, the list comprising at least one sensor-referenced parameter; sending the list from the host to the field device (subscribe); sending the value of the at least one sensor-referenced parameter from the field device to the host as soon as the list is on the field device and as soon as the value of the at least one sensor-referenced parameter changes (stream); and constructing and displaying the menu page on the display with the current value of the at least one sensor-referenced parameter.

Description

[0001] The invention relates to a method for constructing a menu page on a host with a display, wherein a field device, in particular a sensor, is connected to the host.

[0002] In process automation technology, field devices are often used to record and / or influence process variables. Sensors such as level gauges, flowmeters, pressure and temperature gauges, pH / ORP meters, conductivity meters, etc. are used to record process variables and measure the corresponding process variables: level, flow, pressure, temperature, pH value or conductivity. Field devices are all devices that are used close to the process and that supply or process process-relevant information. In addition to the sensors mentioned above, field devices are also generally used to describe units that are directly connected to a fieldbus and are used to communicate with higher-level units, such as remote I / Os, gateways, linking devices and wireless adapters. A large number of such field devices are manufactured and distributed by the Endress + Hauser Group.

[0003] Before commissioning and before changing the function of the field device, it must be parameterized. For parameterization, especially for reading and / or writing parameters, operating tools are used. Such operating tools are usually implemented on a communication unit designed separately from the respective field device and communicate with the field device via a fieldbus or a service interface of the field device (which may also be used for communication using a manufacturer-specific protocol). However, to integrate such field devices into a control system, the field devices must also be parameterized accordingly by the control system. In addition to parameterization, diagnostics of the field devices is also possible.

[0004] For this purpose, field devices offer the possibility of parameterization or diagnostics using a computer program developed specifically for the respective field device. To reduce the effort required to write a separate program for each field device, the cross-manufacturer FDT / DTM concept was introduced in automation technology with the goal 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 specified for this purpose and standardizes the data exchange between the field devices, the control system, and / or an asset management system.The basis of this concept is the so-called FDT frame application, also known to experts as the FDT host, which is a software program that loads the Device Type Manager (DTM for short). The Device Type Manager is essentially a driver that contains all the functions, structure, parameters, and a graphical user interface (GUI for short) for a specific field device or possibly a device family, and is supplied 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 diagnostic steps can be performed by a higher-level unit, such as an operating tool or the control system.

[0005] In addition to the technology described above, so-called device descriptions, known to experts as "Device Descriptions" (DD), are used to perform parameterization and / or diagnostics on field devices. These device descriptions of the field devices to be integrated are based on so-called machine description languages, such as the Electronic Device Description Language (EDDL), which is standardized in IEC 61804-3. EDDL is a text-based description language used to describe the field device and its functions. The description is based on syntactical and semantic specifications or rules and is similar to simple programming languages. The description thus generated in one or more files is also referred to as an Electronic Device Description file (EDD file). This device description is stored on a host, e.g., a handheld device, laptop, etc., installed and thus enables access to all data and parameters of the corresponding field device.

[0006] In addition to the two previously described concepts, the FDI (Field Device Integration) specification was created, which combines the two field device integration techniques described above: FDT / DTM and DD / EDDL. This FDI standard supports multiple process control communication protocols (e.g., HART, Foundation Fieldbus, and Profibus), enabling process control systems to manage field devices using a universal toolkit. This universal toolkit, known as the FDI Device Package, includes everything a host system, consisting of a server and a client, such as a process control system, needs to integrate a field device.Each FDI Device Package must contain a Device Description (EDD), which encompasses a variety of parameter definitions, parameter structures for context-specific views, and automated device procedures such as calibration for a specific field device. An FDI Device Package can contain user interface plug-ins, i.e., software components that support advanced device commissioning and diagnostic functions.

[0007] The parameterization of the field device can be done in advance, i.e. before commissioning and offline, or with a field device already connected to a fieldbus, i.e. “online”.

[0008] The term “online parameterization” in process automation refers to a process in which the settings (parameters) of a field device are read and changed via a remote connection, typically a fieldbus such as HART or PROFIBUS. The technologies mentioned above, in which a device driver is loaded into a host application, are suitable for this. This device driver contains a description of the device menu, via which the device settings can be displayed in menu pages. The user navigates through these menu pages and is given access to the parameters referenced in the page. When a menu page is displayed, the current values ​​of the referenced parameters are read from the field device. In some cases, parameters are also periodically reread from the field device (e.g. measured values, system status parameters).

[0009] The state of the art is to read the parameters for a menu page as follows: A so-called "request" for a parameter (or a predefined group of parameters with a limited size) is sent from the host to the field device. The field device sends the values ​​of the parameter(s) in a so-called "response." The application must wait for the response before sending the next request.

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

[0011] Established technologies such as the FDI mentioned above could also use Bluetooth LE, Wi-Fi, and similar technologies as a transmission medium. However, the "request-response" method described above has the disadvantage that it takes a long time to transmit all the parameters of a menu page, as latency comes into play with each request. This results in loading times of several seconds for the menu page content, which the user has to wait before continuing with the operation. This is especially the case when existing drivers for field devices with newer transmission methods such as Bluetooth are used.

[0012] The invention is based on the object of accelerating the menu structure, in particular reducing latency, and above all continuing to use existing drivers for field devices even with modern transmission types.

[0013] The problem is solved by a method for constructing 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-referenced parameter; sending the list from the host to the field device; sending the value of the at least one sensor-referenced parameter from the field device to the host as soon as the list is on the field device and as soon as the value of the at least one sensor-referenced parameter changes; and constructing and displaying the menu page on the display with the current value of the at least one sensor-referenced parameter.

[0014] The claimed method expands established technologies such as EDD and FDI (see below) with extensions that minimize the disruptive influence of latency and thus waiting times during operation / parameterization. Depending on the design of the method, existing device drivers can be reused unchanged or with slight enhancements. Only minor adjustments to the host application and the field device software make it possible to circumvent the latency problem with the claimed method.

[0015] The request-response procedure of common technologies for online parameterization of process automation field devices (such as EDD, FDI) is extended almost transparently for latency-prone transmission media (such as Bluetooth LE, Wi-Fi) with a subscription streaming procedure that transmits the values ​​of the relevant parameters in a latency-optimized manner and converts the existing requests into local access to cached parameter values. Without significant development effort, existing technologies (e.g., EDD, FDI) can be used with transmission media such as Bluetooth LE or Wi-Fi in a way that minimizes waiting times for the operator.

[0016] One embodiment provides that the at least one sensor-referenced parameter is settings of the field device, measured values ​​of the field device, diagnostic information of the field device, event counters of the field device and / or system status displays of the field device.

[0017] One embodiment provides that the at least one sensor-referenced parameter is a dynamic parameter, i.e. a parameter that changes frequently and quickly.

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

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

[0020] One embodiment provides that the method further comprises the step of storing the transmitted value of the at least one sensor-referenced parameter in a cache on the host, and constructing the menu page based on the values ​​in the cache.

[0021] One embodiment provides that the cache contains all sensor-referenced parameters of all lists.

[0022] One design provides for a backup to be created or restored.

[0023] One design provides for a list to be created for each menu page.

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

[0025] One arrangement provides for a new list to replace the previous list.

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

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

[0028] This is explained in more detail using the following figures. Fig. 1 shows a measurement system with host and field device. Fig. 2 shows the prior art method for constructing a menu page. Fig. 3 shows the claimed method for constructing a menu page.

[0029] In the figures, identical features are identified by identical reference numerals.

[0030] Fig. Figure 1 shows a measuring system with a host 1 and a field device 2. The host includes a display / GUI (reference number 7). The "host 1" in this document includes hardware (i.e., a computer with display 7) and software, for example, an FDI host, EDD host, FDT host, or an FDT-based FDI host. Examples of hardware are a control center PC, a laptop, a tablet, a handheld device, or similar, 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, for example, is a sensor. The sensor 1 includes several parameters 3. The host 1 has local access 5 to a device description 6, for example, as part of the FDI package from the driver. The field device 2 is connected to the host 1 via a remote access 4, for example, Bluetooth or HART.

[0031] Fig. Figure 2 shows the prior art method for constructing a menu page. If a page is left, the new page is constructed from a static description. The GUI 7 receives this information via local access 5 from the description of the device menu, for example, from the driver as part of the FDI packet. This new page must be filled with the current values ​​of the parameters 3. To do this, host 1 sends a "request" with the individual parameter 3 to field device 2, which responds with the "response" containing the value of the parameter. This is susceptible to latency. The new page can only be constructed once all parameters have been queried. This can sometimes take several seconds. Shown in Fig. 2 two requests with parameters, but there can be many more.

[0032] Fig. In contrast, Figure 3 shows the claimed method for constructing a menu page.

[0033] The solution to the latency problem consists in extracting a list 8 of the relevant parameters 3 (the "sensor-referenced parameter" or the multiple sensor-referenced parameters) from the menu page description in host 1 (e.g. EDDL code in the FDI packet). A list 8 is therefore created for the host (for example, by the host itself, see below), the list 8 comprising at least one sensor-referenced parameter 3. The list can contain a large number of parameters 3. This list 8 is sent in its entirety to field device 2. The field device supports a suitable transmission protocol for this purpose. This process is referred to as "subscribe" or "subscription" because host 1 informs field device 2 which parameters 3 are relevant for the host application in the current situation.

[0034] Field device 2 then immediately sends the current values ​​of these parameters 3 without waiting for a response from the host application. This is referred to as "streaming." As soon as the values ​​of a parameter 3 specified in the current list 8 change at a later time, the current value is sent to host 1 without the host having to take any action. In one embodiment, a periodic check can be performed to determine whether a value has changed.

[0035] Finally, the new menu page was created and displayed on display 7 with the current values ​​of the sensor-referenced parameters 3.

[0036] Transferring a new list will replace the previous list.

[0037] The latency practically only comes into play between sending the (first) list and receiving the first parameter value.

[0038] The received parameter values ​​are cached in Host 1; this is referred to as Cache 9. The menu page is constructed based on the values ​​in the cache.

[0039] The host application's existing communication requests (during menu page loading and periodic reading) are now redirected to this cache 9, i.e., converted into local accesses. The first request may need to be delayed until the cache is full.

[0040] In one embodiment, the cache contains exactly the parameters of the active pages.

[0041] In one embodiment, the list 8 is iteratively and adaptively filled with the most frequently changing sensor-referenced parameters 3. This limits the cache 9 to frequently exchanged parameters. This list can be saved in the GUI 7 and reloaded upon reconnection to the device.

[0042] In one embodiment, list 8 is created by a parser, in particular an interpreter, on the host. The menu description interpreter (e.g., in EDDL) is thus extended so that, when parsing the information for the menu page to be displayed, it constructs list 8 of all referenced parameters 3 of this page. In one embodiment, the lists are precalculated, and the list for the current page is loaded from the driver.

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

[0044] In one embodiment, list 8 contains only parameters 3, which change frequently.

[0045] In one embodiment, this list is created 8 times per menu page or across the entire menu. This primarily speeds up polling processes. Parameters 3 can be displayed for setting only on a specific page. However, in one embodiment, parameters 3 can be displayed on another page as information or referenced in visibility conditions for other menu items. In one embodiment, there are also purely display parameters, such as measured values, that should be displayed in different places. This means that each page has its own individual list of referenced parameters, although these lists may overlap.

[0046] So, at least there are options for maintaining an individual list for each menu page or for providing a global list for the entire menu structure (i.e., all menu pages). There can also be a kind of "favorites list" that contains the most frequently referenced parameters.

[0047] In one embodiment, the list will be created in advance and stored separately, particularly together with the device description. Thus, during the development of the device description (e.g., FDI package), an external (offline) parser can be used to precalculate the lists 8 of parameters 3 for each menu page and store them together with the conventional description. The existing parser is extended to report the page change along with its identification.

[0048] By means of the claimed method, larger quantities of parameters 3 up to the entirety of parameters 3 can be sent, for example in order to create or restore a backup. List of reference symbols 1 host 2 field device 3 (sensor-referenced) parameters 4 Remote access 5 local access 6 Description of the device menu 7 Display / GUI 8 List 9 Cache

Claims

[1] Method for constructing a menu page on a host with a display, wherein a field device, in particular a sensor, is connected to the host, the procedure comprising the steps - Creating a list for the host, the list comprising at least one sensor-referenced parameter; - Sending the list from the host to the field device (subscribe); - Sending the value of the at least one sensor-referenced parameter from the field device to the host as soon as the list is on the field device and as soon as the value of the at least one sensor-referenced parameter changes (stream); and - Structure and display of the menu page on the display with the current value of at least one sensor-referenced parameter. [2] Method according to the preceding claim, wherein the at least one sensor-referenced parameter is settings of the field device, measured values ​​of the field device, diagnostic information of the field device, event counters of the field device and / or system status indicators of the field device. [3] Method according to one of the preceding claims, wherein the at least one sensor-referenced parameter is a dynamic parameter, i.e. a parameter that changes frequently and quickly. [4] Method according to one of the preceding claims, wherein the host is designed as an FDI host, EDD host, FDT host or FDT-based FDI host. [5] Method according to one of the preceding claims, further comprising the step - Storing the sent value of at least one sensor-referenced parameter in a cache on the host, and building the menu page based on the values ​​in the cache. [6] Method according to the preceding claim, wherein the cache comprises all sensor-referenced parameters of all lists. [7] Method according to the preceding claim, whereby a backup is created or restored. [8] Method according to one of the preceding claims, wherein one list is created per menu page. [9] Method according to one of the preceding claims, wherein the list is iterative and adaptive and comprises the most frequently changing sensor-referenced parameters. [10] Method according to one of the preceding claims, wherein a new list replaces the previous list. [11] Method according to one of the preceding claims, wherein the list is created by a parser, in particular an interpreter, on the host. [12] Method according to one of the preceding claims, wherein the list is created in advance and stored separately, in particular together with the device description.

Images