WO2007121218A2 - Outil d'édition de dispositif de terrain - Google Patents

Outil d'édition de dispositif de terrain Download PDF

Info

Publication number
WO2007121218A2
WO2007121218A2 PCT/US2007/066394 US2007066394W WO2007121218A2 WO 2007121218 A2 WO2007121218 A2 WO 2007121218A2 US 2007066394 W US2007066394 W US 2007066394W WO 2007121218 A2 WO2007121218 A2 WO 2007121218A2
Authority
WO
WIPO (PCT)
Prior art keywords
parameter
column
values
editor
interface
Prior art date
Application number
PCT/US2007/066394
Other languages
English (en)
Other versions
WO2007121218A3 (fr
Inventor
Scott S. Bump
Nestor J. Camino, Jr.
Vladimir Kostadinov
Charles W. Piper
Richard L. Linscott
Johan I. Tegnell
Original Assignee
Invensys Systems, Inc.
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
Priority claimed from US11/403,228 external-priority patent/US20070078540A1/en
Priority claimed from US11/403,226 external-priority patent/US8799793B2/en
Priority claimed from US11/403,224 external-priority patent/US8527888B2/en
Application filed by Invensys Systems, Inc. filed Critical Invensys Systems, Inc.
Priority to EP07760453A priority Critical patent/EP2010991A4/fr
Publication of WO2007121218A2 publication Critical patent/WO2007121218A2/fr
Publication of WO2007121218A3 publication Critical patent/WO2007121218A3/fr

Links

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/418Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41845Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by system universality, reconfigurability, modularity
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/31From computer integrated manufacturing till monitoring
    • G05B2219/31121Fielddevice, field controller, interface connected to fieldbus
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/31From computer integrated manufacturing till monitoring
    • G05B2219/31132FDT interfacing profibus field device drivers DTM with engineering tool
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/31From computer integrated manufacturing till monitoring
    • G05B2219/31334Database with devices, configuration, of plant
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/32Operator till task planning
    • G05B2219/32137Configure, connect, combine different program modules
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/32Operator till task planning
    • G05B2219/32144Define device description using dd files
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Definitions

  • This invention relates generally to networked computerized industrial process control systems and, more particularly, relates to utilities providing lifetime support of field devices such as transmitters, positioners, etc. Tasks associated with such lifetime support include configuring, commissioning, monitoring, maintaining and replacing the field devices within an industrial process control system environment including potentially many types of field device types.
  • BACKGROUND Industry increasingly depends upon highly automated data acquisition and control systems to ensure that industrial processes are run efficiently, safely and reliably while lowering their overall production costs.
  • Data acquisition begins when a number of sensors measure aspects of an industrial process and periodically report their measurements back to a data collection and control system.
  • Such measurements come in a wide variety of forms and are used by industrial process control systems to regulate a variety of operations, both with respect to continuous and discrete manufacturing processes.
  • the measurements produced by a sensor/recorder include: a temperature, a pressure, a pH, a mass/volume flow of material, a quantity of bottles filled per hour, a tallied inventory of packages waiting in a shipping line, or a photograph of a room in a factory.
  • Typical industrial processes today are extremely complex and comprise many intelligent devices such as transmitters, positioners, motor drives, limit switches and other communication enabled devices.
  • sensors and control elements e.g., valve actuators
  • transmitters and positioners were comparatively simple components.
  • setup activities associated with a field device were relatively simple. Industry standards like 3-15psi for pneumatic instruments or 4-20ma for electronic instruments allowed a degree of interoperability that minimized setup and configuration of analog transmitters.
  • a set of parameters are set, within the new device, at either a device level (HART, PROFIBUS, FoxCOM, DeviceNet) or a block level within the device (FOUNDATIONTM fieldbus).
  • FDT field device tool
  • a known FDT architecture comprises a frame application, device DTMs, and DTMs for communications devices (Comm DTMs).
  • the FDT frame application implements FDT-compliant interfaces for DTMs to enable management of a variety of field device types, operating under a variety of protocols.
  • the frame application (Platform) and DTMs when combined, provide a set of graphical user interfaces (GUIs) that abstract specific implementation details of particular systems and devices thereby rendering differences between their associated protocols transparent to higher level applications built on top of the FDT architecture. Examples of such abstracted implementation details include: physical interfaces connecting to devices, persistent data storage, system management, and locations and types for device parameters.
  • the FDT architecture also includes a communication device type manager (Comm DTM), and device DTM.
  • Comm DTM performs the parameterization of communication devices such as Profibus- interface boards, Hart Modems or Gateways from Ethernet to Profibus.
  • the Comm DTMs define a standard communications interface (e.g., Set, Get, etc.) for accessing data within online devices (e.g., Fieldbus devices) using a particular communications protocol.
  • Device DTMs in general, are the drivers for lifetime management of field devices.
  • Known device-specific DTMs encapsulate the device-specific data and functions such as the device structure, its communication capabilities, and internal dependencies.
  • Device DTMs can also specify a graphic interface for presenting, for example, a configuration interface for an associated field device.
  • the device DTMs provide a standardized set of interfaces to device data within field devices.
  • Device DTMs provide/support, for example, visualization of a device status, analysis, calibration, diagnostics, and data access with regard to devices with which the device DTMs are associated.
  • Device DTMs plug into the Frame Application and become the high-level interface for the devices.
  • Device DTMs communicate with their associated devices through standardized interface methods supported by Comm DTMs. The following is a general example of a setup embodying the FDT architecture.
  • a field device is mounted to a fieldbus. However, the device is not ranged out in the field. Instead, the operator, via a workstation, installs device DTM software on a computer executing the frame application that serves as the host of the DTM.
  • the Comm DTM for communicating with the field device is installed on the computer system having the DTM and frame application.
  • the channel associated with the Comm DTM supports communications to/from the fieldbus.
  • a pointer to the main interface the channel is passed to the device DTM.
  • the device DTM is able to speak to the field device through the channel according to the protocol specified by the channel using specified FDT interfaces.
  • the device DTM is pre-defined for a particular device type.
  • DTM cannot be used for other types of devices.
  • providing specific DTMs for particular device types leads to a variety of vendor and device type-specific user interfaces.
  • a known DTM development environment developed by Code Wrights GmbH implements a tool which allows a developer to create device- specific DTMs using HART Communication Foundation Device Description (DD) files as a starting point.
  • DD HART Communication Foundation Device Description
  • the known DTM development tool requires expert programming knowledge to fully resolve and create the user interface.
  • DTMs cannot be created without a user first providing programming input.
  • Intelligent field devices today are becoming increasingly sophisticated. Such devices support a variety of configurable and observable parameters via DTMs and, in the case of field devices having associated blocks (e.g., transducer, analog in, etc.), block type managers (BTMs).
  • DTMs and BTMs are used by a wide variety of users to perform particular role-related tasks. For example, an operator who merely monitors/supervises devices in a runtime environment is unlikely to need access to the same set of device parameters as a process engineer who performs a variety of commissioning and maintenance tasks on such devices.
  • the DTMs and BTMs will be generally referred to herein as "type managers" (TMs).
  • Still yet another challenge when viewing a sophisticated device or block is gaining an understanding of what modifications have been made to the configurable parameters associated with the device. Making such determination on a single device can be an ordeal. The task is compounded when it must be performed on hundreds of devices or blocks.
  • a customization tool is provided in association with a universal device type manager (DTM) utility.
  • the customization tool facilitates creating a set of customized, application-specific templates for a device type.
  • the customized templates define access to device data via graphical user interfaces supported by the universal DTM utility and/or universal BTM utility for instances of the device type.
  • the universal DTM and BTM utilities are generally referred to herein as universal type managers (TMs).
  • customization tool in a device configuration environment for creating customized definitions for user interfaces supported by a field device editor.
  • the customization tool includes an editor definition selection control for specifying a first device template corresponding to a device type stored in a device definition database.
  • the first device template includes a first definition of an editor interface for the device type.
  • An editor graphical user interface comprising a set of user-selectable screens enables a user to modify the first definition of the editor interface via a customization tool provided via the editor interface for the device type, thereby rendering a modified version of the first definition of the editor interface.
  • the customization tool furthermore includes an editor store control for storing the modified version of the editor definition.
  • a compare tool including a user- friendly graphical user interface for providing comparison results, is utilized in a device configuration environment to compare parameter values from an instance of a field device (deployed in the field) to corresponding values maintained within an application database.
  • the utility displays the results on a user interface. More particularly the parameter names and associated values are presented in three columns of the user interface. A first column identifies a parameter within the field device. A second column identifies a previously archived value for the parameter identified in the first column, and a third column identifies a current value, captured from a device instance, corresponding to the parameter identified in the first column.
  • Figure 1 is schematic diagram depicting an exemplary process control network environment wherein the present invention is potentially incorporated;
  • FIG. 2 schematically depicts a set of entities, and their corresponding interfaces, associated with an exemplary universal FDM embodying the present invention
  • FIG. 3 is a flowchart summarizing the on-demand creation of a customized universal DTM for presenting a set of GUIs associated with lifetime management of any device for which a standard device description (DD) is provided;
  • DD device description
  • FIG. 4 is an illustrative graphical user interface associated with launching a DTM from a host application
  • FIG. 5 is an illustrative graphical user interface associated with a device home page rendered by a universal device type manager
  • FIG. 6 is an illustrative graphical user interface associated with a system management screen accessed via a tab presented on the device home page
  • FIG. 7 is an illustrative graphical user interface associated with a network management screen accessed via a tab presented on the device home page
  • FIG. 8 is an illustrative graphical user interface associated with a diagnostics screen accessed via a tab presented on the device home page;
  • FIG. 9 is an illustrative graphical user interface associated with a security screen accessed via a tab presented on the device home page;
  • FIG. 10 is an illustrative graphical user interface associated with a block home page rendered by a universal block type manager
  • FIG. 11 is an illustrative graphical user interface associated with a configuration screen accessed via a tab presented on the universal block type manager interfaces
  • FIG. 12 is an illustrative graphical user interface associated with a tuning screen accessed via a tab presented on the universal block type manager interfaces
  • FIG. 13 is an illustrative graphical user interface associated with a watch screen accessed via a tab presented on the universal block type manager interfaces
  • FIG. 14 is an illustrative graphical user interface associated with a diagnostics screen accessed via a tab presented on the universal block type manager interfaces
  • FIG. 15 is an illustrative graphical user interface associated with a methods screen accessed via a tab presented on the universal block type manager interfaces
  • FIG. 16 is an illustrative graphical user interface associated with a security screen accessed via a tab presented on the universal block type manager interfaces;
  • FIG. 17 is an illustrative graphical user interface associated with a customization utility accessed via a "Customization" tab presented on the universal block type manager interfaces;
  • FIG. 18 an illustrative graphical user interface associated with a screen accessed via a Group Parameters button in the Customization view
  • FIG. 19 an illustrative graphical user interface associated with a screen accessed via a Group Overview button in the Customization view
  • FIG. 20 an illustrative graphical user interface associated with a screen accessed via a Define Tabs button in the Customization view
  • FIG. 21 an illustrative graphical user interface associated with a screen accessed via a Details... button under a "Process" tab name in the Define Tabs view
  • FIG. 22 an illustrative graphical user interface associated with a screen accessed via a Tab Overview button in the Customization view;
  • FIG. 23 an illustrative graphical user interface associated with a screen accessed via a Set Permissions button in the Customization view
  • FIG. 24 an illustrative graphical user interface associated with a screen accessed via a Setup Downloads button in the Customization view
  • FIG. 25 summarizes a set of steps associated with defining and storing a customized child editor template for a device/block
  • FIG. 26 summarizes a set of steps for invoking a particular configuration of a customized child editor based upon a requestor's role(s); and
  • FIG. 27 is an exemplary user interface for supporting a compare function within an editor facility. DETAILED DESCRIPTION OF THE DRAWINGS
  • device DTMs are hosted by the frame application which provides a basic user interface framework within which the individual device DTMs provide their own specialized interfaces.
  • the frame application includes a hierarchical directory tree arrangement that shows various selectable/configurable system resources.
  • the frame application accesses the DTMs through interfaces to manage the DTMs.
  • the DTMs access the frame through another set of interfaces that allow the DTM to acquire information from, and transmit data to, the frame application.
  • lifetime management of a variety of field devices having differing device descriptions is supported by a single universal device type manager (DTM) utility.
  • DTM universal device type manager
  • the universal DTM functionality renders on-demand, in association with an FDT frame application, a variety of device type-specific DTM user interfaces.
  • the universal DTM supplements device type-specific DTMs provided for specific field devices and enables customizable lifetime management user interfaces for field devices for which suitable DTMs are not available.
  • a workstation 102 comprising a variety of field device configuration and monitoring applications, provides an operator/engineering interface through which an engineer/technician monitors the components of an industrial process control system.
  • the workstation 102 comprises any of a variety of hardware/operating system platforms.
  • the workstation 102 comprises a personal computer running on MICROSOFT'S WINDOWS operating system.
  • MICROSOFT'S WINDOWS operating system MICROSOFT'S WINDOWS operating system
  • alternative embodiments of the invention can potentially run on any one or more of a variety of operating systems such as: Unix, Linux, Solaris, Mac OS-X, etc.
  • the workstation 102 hosts a frame application, a universal DTM, one or more Comm DTMs, and a set of device type-specific DTMs.
  • the frame application for example INVENSYS's IACC frame application, provides access to a database for persistent storage of device descriptions (device definition database 107) as well as an application database 109 that stores a set of DTM customization definitions for defining particular field device access via the universal FF DTM embodying the present invention.
  • DTMs operate within an FDT frame application on the workstation 102.
  • the frame application provides the specified FDT interfaces defined in the FDT specification.
  • the FDT frame application comprises client applications that use DTMs, databases 107 and 109 for persistent storage of device descriptions/DTM parameters, and a communication link to the field devices.
  • FDT frame applications are incorporated into engineering tools for control systems (e.g., INVENSYS's IACC) as well as standalone tools for device configuration.
  • One or more Comm DTMs facilitate communications between the universal DTM and field devices.
  • the workstation 102, device definition database 107 and application database 109 are connected in a redundant configuration via dual Ethernet interfaces/wiring to redundant switches 104 and 106.
  • the Ethernet switches 104 and 106 are commercially available and provided, for example, by Allied Telesyn (e.g., model AT-8088/MT). While not specifically depicted in FIG. 1, additional nodes, comprising workstations, servers and other elements (e.g., control module assemblies) of a supervisory portion of the process control system are potentially connected to the redundant switches 104 and 106.
  • a device definition database 107 and application database 109 store information regarding device types (templates) and device instances, respectively.
  • hardwired connections between the workstation and switches 104 and 106 via ETHERNET local area network links are depicted in FIG. 1 , such links over a local supervisory level process control network are alternatively carried out via wireless network interfaces.
  • the switches 104 and 106 are also communicatively coupled to a control module assembly 108.
  • the control module assembly 108 comprises one or more control modules (also referred to as control processors).
  • An illustrative example of such control module assembly 108 is a Foxboro CP model FCP270, by Invensys Systems, Inc.
  • process control functionality is carries out in any of a variety of control modules - even by control programs incorporated into the workstations, intelligent transmitters, or virtually any communicatively coupled device capable of executing control programs, loops, scripts, etc.
  • an I/O module assembly 110 is connected to the control module assembly 108.
  • the communications protocols utilized for carrying out communications between the I/O module assembly 110 and control module assembly 108 is potentially any one of a variety of proprietary/non-proprietary communications protocols.
  • the communications between the control module assembly 108 and I/O module assembly 110 are carried out via a 2 MBit HDLC communication bus. While only a single I/O module assembly 110 is depicted in the illustrative example, embodiments of the invention comprise many I/O module assemblies.
  • the I/O module assemblies include a variety of interfaces for communicating directly and/or indirectly to a variety of devices including, for example, field devices.
  • the I/O module assembly 110 comprises a Foundation Fieldbus I/O module (e.g., an INVENSYS's field bus module model FBM228) that supports communications between the control module assembly 108 and a Foundation Fieldbus network 111.
  • a set of representative intelligent field devices 114 and 116 containing multiple application-dependent configurable parameters, are connected to the Foundation Fieldbus network 111.
  • the field devices 114 and 116 operate at the lowest level of an industrial process control system to measure (transmitters) and control (positioners) plant activity.
  • a Termination Assembly 112 communicatively couples the I/O module assembly 110 to the field devices 114 and 116.
  • the termination assembly 112 provides power and power conditioning to the extent needed by the field devices 114 and 116 on the network 111.
  • the process control network schematically depicted in FIG. 1 is greatly simplified for purposes of illustration. Those skilled in the art will readily appreciate that both the number of components, at each depicted level of the exemplary process control system, is generally many times greater than the number of depicted components. This is especially the case with regard to the number of depicted field devices. In an actual process control environment, the number of field devices, comprising both input devices (e.g., transmitters) and output devices (e.g., positioners) number in the hundreds for an industrial process control system.
  • input devices e.g., transmitters
  • output devices e.g., positioners
  • FIG. 2 a schematic diagram illustratively depicts primary components of an FDT application environment including a universal DTM 200 embodying the present invention.
  • the universal DTM 200 is implemented as a component object model (COM) object that complies with FDT specification 1.2, or higher, as further defined for FF.
  • the universal DTM 200 comprises multiple sub- components that provide support for providing device type-specific DTM user interfaces according to a generic/default specification associated with the universal DTM 200.
  • the primary program components of a universal DTM 200 are a business object 204 and one or more presentation objects 206.
  • An engineering database 202 includes device data 205, screen customization descriptions 207, and a default device template 209 (from which customized universal
  • DTM templates are derived) comprise portions of an engineering database 202.
  • a default device template 209 specifies the base functionality/appearance of the universal DTM 200, including tabs, buttons, etc.
  • the device data 205 contains the data values for device parameters configured through the universal DTM 200 or a universal BTM 210.
  • the device data 205 is potentially either for a device template or for a device instance.
  • the screen customization descriptions 207 specify customized screens defined by users including, for example, new tabs, security and access information displays.
  • the presentation objects 206 support user interface interactions for the universal DTM 200 (described further herein below with reference to a set of exemplary graphical user interfaces) in accordance with user-specified customizations, provided by the screen customization descriptions 207, to a default graphical user interface specification provided by the default device template 209 using the device description 211 and common file format 213.
  • the business object 204 is a server component and, in addition to supporting interactions with the presentation objects 206, supports interactions between the universal DTM 200 and external components. Customized behavior of the business object 204 for a selected device/type template is defined by a set of device/type- specific parameter values retrieved from the device data 205.
  • both the universal DTM 200 and the universal BTM 210 are defined and created for a particular specified device type template/instance, on-demand, by default definitions from the default device template 209 and a specified DD provided from device descriptions 211 via a DD Engine 212.
  • the DD engine 212 also provides access to device information maintained in CFF data 213.
  • the BTM 210 including BTM business object 214 and presentation objects 216, operates upon blocks associated with device templates and instances represented in the universal DTM 200 in a manner analogous to the operation of the universal DTM 200.
  • the engineering database 202 is also a source of vendor-provided DTMs 215.
  • the vendor-provided DTMs comprise statically defined DTMs that are intended to provide engineer access to the configuration/run-time parameters of a particular device type.
  • Examples of external components to which the business object 204 communicates include: a Comm DTM 208, block type managers (BTMs) - including a universal BTM 210, and the device description (DD) engine 212.
  • the DD engine 212 provides requested device descriptions and common file format files. BTMs provide access to block information associated with a designated FF device/type. The function blocks of a field device are described by BTMs that are child objects of the universal DTM 200.
  • the Comm DTM 208 facilitates communications between the universal DTM 200 and field devices.
  • the business object 204 also supports communications between the universal DTM 200 and the BTMs. Interfacing to the frame application, within which the universal DTM 200 operates, is through the FDT DTM interfaces (described herein below).
  • the business object 204 carries out a variety of functions in support of the overall universal DTM 200's functionality.
  • the server functions supported by the business object 204 are potentially used by frame applications without user interaction.
  • the business object 204 in an exemplary embodiment, implements as many functions as possible, thereby allowing a slim implementation of the presentation objects 206.
  • the following exemplary list of functions is implemented by the business object 204.
  • the business object 204 provides the FDT interfaces required to store/restore parameters to/from the device data 205.
  • an old value (before the editing) is maintained for each parameter.
  • each parameter will have status information for each data source by specifying a parameter status of the parameter within the project (storage) database and the device data 205.
  • the presentation objects 206 when invoked the presentation objects 206 load a set of device parameters from the business object 204.
  • Exemplary device parameter value types provided by the business object 204 to the presentation objects include: names, labels, descriptions, units, data types, security/access information - each parameter has an attribute to control read and write access of each parameter in a displayed security/access grid for a device template/instance.
  • the presentation objects 206 maintain a separate (temporary) "edit" database with regard to device parameter values that facilitate a variety of user interaction modes described herein below.
  • Edit Mode This mode distinguishes the granularity in which parameter changes will be written into the database (storage or device database): o Block Mode: The user is able to change several parameters in the different tabs of the presentation object. Selecting the Save button writes the changes to the business object 204 database 205 and in a frame application database. If the DTM is connected to the device it is also possible to work in this mode. Changes are only downloaded to the device when an "Apply" button is pressed. If the user presses cancel button the changes are lost.
  • the Direct Mode is used for immediate change of single parameter values. After the user changes a parameter and leaves the input control for this parameter, the parameter is validated and written into the database.
  • the direct mode is only available when the device is connected. If the device is connected and user presses the 'Block Mode' button the UDTM GUI switches to the 'Block Mode' user interaction style.
  • Connection mode In this mode the following states are distinguished: o Not connected (sometimes called Off-line): The universal DTM is not connected with a device. There is no communication / data exchange with the device. o Connected (sometimes called On-line): The universal DTM is connected with a device. There is communication / data exchange between the universal DTM and the device. o Device templates are always offline
  • the default template for the presentation objects 206 of the universal DTM 200 includes a set of buttons supporting user interaction.
  • the default set of buttons provided for presentation objects 206 include the following:
  • Save is available on the screens where DTM data can be changed.
  • the save button will trigger a request to the frame application to save the current DTM data to the database.
  • Download Write to the device parameters which have been modified by the user Download All: Write to the device all parameters which the customization has marked as downloadable parameters. The write occurs regardless of whether the parameters have been modified Upload All: Read from the device all parameters which the customization has marked as uploadable parameters. Parameters are not written to the database until a Save is done.
  • set of program interfaces are provided that facilitate invoking various functions supported by the displayed components.
  • the following interfaces are implemented by the exemplary universal DTM 200 to carry out functionality described herein regarding the lifetime management of field devices via a generalized device management utility.
  • FDT DTM interfaces 300 correspond to the mandatory interfaces for any DTM
  • the mandatory interfaces include a set of well known interfaces:
  • the primary interface used to interact with DTMs This interface provides the ability to get other interfaces implemented by the DTM. This interface provides the functions required to start up a DTM. This interface also provides functions to get the list of user interface actions supported by the ActiveX presentation objects which are part of the DTM.
  • IDTMActiveXInformation The interface used to retrieve a pointer to the ActiveX presentation object of the DTM which implements a supported function of the DTM.
  • FDT BTM interfaces 301 comprise the mandatory interfaces for any BTM
  • the mandatory interfaces include a set of well known interfaces:
  • IBtm The primary interface used to interact with BTMs. This interface provides the ability to get other interfaces implemented by the BTM. This interface provides the functions required to start up a BTM. This interface also provides functions to get the list of user interface actions supported by the ActiveX presentation objects which are part of the BTM.
  • IDTMActiveXInformation The interface used to retrieve a pointer to the ActiveX presentation object of the BTM which implements a supported function of the DTM. This is the same interface as defined for DTMs ⁇ IBtmlnformation - The interface used to query the DTM for information on what devices it is capable of configuring
  • the universal DTM 200 also includes a set of well known FDT Channel Interfaces 303 that represent mandatory interfaces for communication. These interfaces include:
  • ⁇ IFdtCommunication This is a standard FDT 1.2 interface which is the primary interface through which read and write requests are transmitted.
  • ⁇ IFdtChannelSubtopology This is a standard FDT 1.2 interface which is the interface that provides the functions through which the DTM implementing the channel interface is informed of the DTMs or BTMs that will be using the channel interface.
  • FDT interfaces are provided for notification of communication completion.
  • the well known FDT IFdtCommunicationEvents interface 302 is implemented by DTMs or BTMs to receive notification when read or write requests complete.
  • FDT interfaces are provided for notification of events to a host application (or another other interested external entity.
  • IDtmEvents 304 is an FDT 1.2 standard interface for sending event notifications from a DTM to the requesting entity.
  • Private DTM interfaces between business objects and presentation objects of a universal DTM or BTM support exchanging information between the business object 204 and presentation objects 206 implementing ActiveX controls, or the business object for a universal BTM 214 and the presentation object 216.
  • the universal DTM 200 implements the following optional interfaces:
  • This function allows comparing two offline device databases. It is a business object function and could be used by applications for comparisons. •
  • the universal DTM 200 implements the function IDtmOnlineDiagnosis:: Compare
  • This function allows the comparison of an offline device database with the online device data. It is a business object function and could be used by applications for comparisons.
  • the universal DTM 200 implements a IDtmDiagnosis::InitCompare method
  • This method defines the meaning of "DTMs of the same type" for purposes of determining whether two DTMs are of the same type, and therefore eligible for compare object. Two DTMs are of the same type when:
  • the second DTM has the same Devicetype-ID • the second DTM has the same Subdevice-Type, if available
  • the universal DTM 200 implements IDtmOnlineDiagnosis::GetDeviceStatus
  • This function retrieves the device status and returns a list with the latest status indications in user readable text form. It is a business function (without user interface) and could be used by applications to get the detailed device specific status information.
  • the universal DTM 200 implements the functions IDtmParamter::GetParameters and SetParameters
  • This function allows the frame applications to retrieve and store the device parameter information (detailed parameter information).
  • the universal DTM 100 implements the following FDT 1.2.1 specified interfaces: IDtmSingleDeviceDataAccess and Interface IDtmSinglelnstanceDataAccess.
  • BTMs are child objects of the universal DTM 200 and are connected to communication channels supported by the universal DTM 200.
  • the universal DTM 200 uses a DD Engine 212 interface (I Device 305) to identify which and how many block types could be connected to the universal DTM 200.
  • the DD Engine 212 creates, based on the information coming from the CFF file for each block, a unique UUID.
  • the universal DTM 200 uses the DD Engine interfaces to retrieve the UUIDs for the possible block types and creates for each a channel object.
  • Each channel object uses one unique block type UUID as a 'supported protocol' ID to identify which block type could be connected.
  • For each possible block connection a channel object is created by the universal DTM 200.
  • the UUID information is used as a block protocol identifier between the universal DTM 200 and a universal block type manager of the set of BTMs 210.
  • Standard FDT topology mechanisms and interfaces are used to assign a BTM to a DTM. If the DTM has child BTMs, it acts as a gateway. Mechanisms of nested communication defined in the FDT Specification are used for communication between the BTM and the DTM. If a DTM must create a BTM, it uses the standard interface IFdtTopology of the frame application. The frame application instantiates the BTM. Verification of assigned Child-BTMs performed by invoking the ValidateAddChild() method in the DTM of the IFdtChannelSubTopology interface. The frame application handles the instantiation of the BTMs.
  • the universal DTM 200 implements a private interface, I DtmBusinessObject
  • a universal BTM of the BTMs 210 uses the same interface to access the private business object 204 information. For this the universal BTM implements an object with a callback interface to get notifications from the business object 204. Using the interface I DtmBusinessObject 307 the Universal BTM is able to access some additional (private) information from the universal DTM 200.
  • Device Type related • Device Instance information - the device tag, device ID, etc.
  • Block Type and instance related Device Type related information includes:
  • Device identification information (Device Manufacturer, device type, version, DD and CFF versions)
  • Device Instance information includes: • Device Tag
  • the above-identified information is stored in the universal DTM 200 as parameters.
  • the universal BTM uses the universal DTM 200 interface function getParameterValue to access any parameter in the universal DTM 200.
  • paramStatus Enumeration type that is a superset of all possible status values for database sources. Depending on the selected database source not all values are applicable:
  • Attach is a function that facilitates obtaining configuration information from the business object 204.
  • the caller provides a callback interface as parameter, and the function returns an identifier ocxid to be used as argument ocxid of all other interface methods.
  • This function also returns additional information and interface pointers to an xml manager and the FDT container within which the business object 204 operates.
  • Detach disconnects the requestor from the business object 204.
  • InvokeFunction allows invoking a specified function supported by the business object 204.
  • runningFid the presentation objects 206 notify the business object when an invoked function with a specified function ID is running.
  • the handled function id is set after extracting the functional document
  • parameter information e.g. description, paramter group, tokenized string if available and a device parameter description including a number of fields defining properties of the identified parameter.
  • getParameter Value provides a requested parameter value as a variant, thereby allowing reading of any identified business object parameter value.
  • setParameter Value sets an identified parameter value. If the request fails, an error message is returned.
  • getParameterAsString provides a requested parameter value as a string.
  • setParameterAsString sets an identified parameter value using a string value. If the parameter value is not valid, then an error message is returned.
  • isActualParameterValue determines whether actual parameter value in the device and the temporary value of the parameter are equal
  • getActualParameterValue provides the actual (device) parameter value as a variant.
  • getActualParameterAsString provides actual (device) value as a string
  • getDefaultParameterValue provides the default parameter values as a variant.
  • getDefaultParameterAsString provides the default parameter value as a string.
  • GetParameterLabel provides the parameter label (for displays) of an identified parameter.
  • GetParameterUnit provides the unit of a parameter. If the parameter does not have a unit the returned string is empty.
  • GetParameterMaxLength provides the maximum length of an identified parameter. This is needed for parameters which do not have fixed length.
  • GetParameterEnumQualifiers converts, using the EnumQualifierString, an enum ordinal value to an enum string
  • VerifyParameters verifies the identified parameters (if verification is available).
  • GetNParameters provides the current number of parameters in the business object 206.
  • GetParameterName provides a name of a particular (indexed) parameter within a parameter list.
  • GetParameterNames provides a list of names of all parameters that contain a specified search string in their name.
  • SetParameterModified sets the modified flag of a parameter.
  • UploadParameterListStart starts uploading specified device parameters to a presentation object.
  • UploadParameterAllStart starts uploading all device parameters to a presentation object.
  • DownloadParameterListStart starts downloading specific device parameters. If a directdownload flag argument is true, then no device state handling (Pre and Post download actions) is performed. If a modified flag is set to true, only the modified parameters will be downloaded.
  • DownloadParameterAllStart starts downloading all device parameters for an identified presentation object. If the directdownload flag is true, then no device state handling (Pre and Post download actions) is performed. If the modified flag is set to true, then only the modified parameters will be downloaded.
  • DownloadParameterGroupStart starts downloading all device parameters of a group. If directdownload is true, then no device state handling (Pre and Post download actions) is performed. If the modified flag is set to true, then only the modified parameters will be downloaded.
  • ResumeMeasurement resumes measurement after successful completion of a PauseMeasurement function.
  • GetLastDeviceStatus provides the last retrieved fieldbus specific device status value.
  • AuditTrail Start Transaction marks the start of an audit trail transaction.
  • AuditTrail EndTransaction marks the end of an audit trail transaction.
  • AuditTrail Enabled determines whether an audit trail for a device DTM is supported and returns the availability of audit trail functionality.
  • AuditTrail FunctionEvent enters an audit trail function event entry into the audit trail system.
  • AuditTrail DeviceStatusEvent enters an audit trail device status event entry into the audit trail system.
  • LockDataSet locks the business object 204's data set (allows write access to parameters). This locking is used to coordinate parameter changes between different presentation objects.
  • UnLockDataSet unlocks the business object 204's data set.
  • GetNTrendParameters returns the number of device parameters which are marked for trending
  • GetTrendParameter returns information for the device parameter for trending for an id number.
  • the id number is between 0 and (getNTrendParameters()-l). The information is needed to set up the scales and axis description of the trend curves.
  • GetHelpfile returns the name of a help file for a device DTM.
  • TraceMessage sets a trace message within the business object 204.
  • GetProtocolParamlength retrieves the protocol specific parameter length for parameters.
  • GetDataLength retrieves the protocol specific data length (size) for a certain data type.
  • DeviceCommandStart sends a protocol specific command directly to the device.
  • getNavigationDocument returns an xml document to configure navigation.
  • GetUserlnformation provides an FDT user information data structure.
  • PrivateDialogEnabled returns information from a private dialog.
  • OpenActiveXControlRequest calls a function in the business object 204 from one of the presentation objects 206 to start another presentation object instance.
  • getCompareDTM provides a pointer to a DTM selected within the previously described IDtmDiagnosis::InitCompare method.
  • GetParameterSecAttrOP Access provides security attributes for functions and screens. For each universal DTM function and screen there is a security parameter that holds the access information (notvisible, disabled, enabled) for each user level (observer, operator, maintenance, planningEngineer) and the Administrator or OEM-Service qualifier.
  • SetParameterSecAttrOP Access sets the security attributes for functions and screens. For each universal DTM function and screen there is a parameter, which holds the access information (notvisible, disabled, enabled) for each user level (observer, operator, maintenance, planningEngineer) and the Administrator or OEM-Service qualifier.
  • getParamStatus provides the status information for a specified parameter paramName and database source.
  • getParamAllStatus provides all status information for a specified parameter.
  • getParamStatusAndValue provides a temporary value and the status information for a specified parameter paramName and database source.
  • getParamAHStatusAndValue provides a temporary value and all status information for a specified parameter paramName.
  • a callback interface IdtmEvents 304 is implemented by any entity that seeks to receive notifications from the business object 204.
  • OnUploadFinished the client of the callback interface receives a notification when an upload of parameters has finished.
  • a success flag indicates whether the upload operation was successful.
  • OnDownloadFinished the client of the callback interface receives a notification when a download of parameters has finished.
  • a success flag indicates whether the download was successful.
  • OnOnlineStateChanged enables the client of the callback interface to receive a notification when the online state of the business object 204 changes.
  • OnParamChanged enables the client to receive notification of any changes of the temporary value and/or the status information for a specified parameter (paramName) and database source.
  • a source argument identifies which data source value and/or status changed.
  • Upload and download actions may trigger OnParamChanged notifications with the database source flag set to databaseSource::device.
  • Project save or project load actions may trigger OnParamChanged notifications with the database source flag set to databaseSource::storage.
  • Edit actions may trigger OnParamChanged notifications with the database source flag set to databaseSource::All, because the temporary value changed compared to all (both) data sources.
  • the interfaces supported by the universal DTM 200 to the DD engine 212 enable the universal DTM 200 to obtain device type specific information from the DD and CFF files managed by the DD engine 212.
  • I Dde 306 is the main interface for the DD engine 212.
  • the I Dde interface 306 provides exposes methods for initializing the DD engine 212 and exposing the common information for the overall program behavior.
  • the I Device interface 305 provides an interface for device handling such as getting device information, block information, global device parameter information, system management information, network capabilities, etc.
  • FIG. 3 a flowchart summarizes a set of steps for dynamically building the universal DTM 200 within a frame application implementing FDT interfaces.
  • the series of steps provided in FIG. 3 further illustrate the dynamic/on-demand nature of building a customized universal DTM.
  • a host application such as INVENSYS' IACC receives an initial command via a graphical user interface to create a customized universal DTM based upon a specified device template or instance (see, FIG. 4 described herein below).
  • the device types are all Fieldbus Foundation device types, and the breadth of device types handled by the single universal DTM is confined to devices within the FF class.
  • the universal DTM is expanded to handle an extensible set of classes.
  • the host application In response to the received request, at step 320 the host application starts up the business object 204. Thereafter, at step 330, the host application defines the Device Description and the Common File Format entries to be retrieved via the DD Engine 212 corresponding to a device type associated with the previously user-specified device type, and the appropriate DD and CFF files are thereafter obtained.
  • the DD and CFF define, at least in part, the customized aspect of a default DTM associated with the universal DTM 200.
  • the universal DTM business object 204 uses the device information in the retrieved device description and the common file format files to generate a parameter set for populating placeholders within the specified device template (applicable to all FF devices) based upon the DD and CFF information corresponding to the identified FF device type.
  • step 350 to the extent that the user has selected a non-default pre-existing template upon which the customized universal DTM is to be based, data for the device template is retrieved from the device data 205 portion of the engineering database 202.
  • the host application utilizes the FDT DTM Interfaces 300 in the DTM business object 204 to set the device template data within the customized universal DTM. If there is no device template data in the engineering database 213, the default values specified in the common file format and the device description are used for the parameter set values. If there is template data in the engineering database 202 corresponding to the selected template, then the values from the device data 205 entry is used to set corresponding values of the parameters for the customized universal DTM.
  • step 360 user interface definitions are retrieved for the device template from the user defined DTM screen customization descriptions 207 portion of the engineering database 202.
  • step 370 the universal DTM Presentation object 206 generates a graphical user interface display corresponding to the selected template using the user defined DTM screen definitions and parameter data set in the universal DTM business object 204.
  • the host application retrieves a pointer to the presentation object 206 of the universal DTM 200.
  • the pointer corresponds to a first screen presented (the "Home Page” described further herein below with reference to FIG. 5) from the business object 204.
  • the presentation object 206 is used to display the first screen for the customized universal DTM.
  • the presentation object 206 retrieves parameter values and information associated with the selected device template/instance from the business object 204.
  • the presentation object retrieves user interface definitions associated with the selected device template/instance from the screen customization descriptions 207.
  • customization information is applied to a default universal DTM shell to render a customized universal DTM.
  • the customization information is obtained from various sources, including DDs, CFFs, user- defined device data and screens to render, on-demand, a customized universal DMT for performing any of a variety of operations relating to lifetime management of FF device instances.
  • Such operations include: creating new device type-specific templates from a default template, deriving and saving application-specific templates for previously created device type-specific templates, and managing on-line field device instances via device instances created from the previously defined templates.
  • FIG. 4 depicts an exemplary graphical user interface provided by an exemplary frame application, embedded within INVENSYS I/A Series Configuration Component (IACC), from which a user launches the universal DTM 200 for a selected target device.
  • IACC INVENSYS I/A Series Configuration Component
  • the frame application also provides FDT compliant interfaces for the universal DTM 200 once it has been launched.
  • the universal DTM 200 operates upon device templates derived from a default template or any other parent template.
  • the hierarchical inheritance/derivation relationship between various device templates, and instances created from the templates, follows the hierarchical arrangement of the tree structure depicted in the system pane 400.
  • a FF Devices node 402 on the tree of system elements is associated with a default FF device template that defines a default set of behaviors for the universal DTM 200 when operating in a Fieldbus Foundation device context/mode.
  • Each of the child nodes under the FF Devices node 402 (e.g., "BA30") is associated with a template derived from the default FF device template.
  • Each child template is characterized by the default template specification and a set of modifications to the default template to render the child template.
  • a user defines such child nodes by selecting the parent node (in this case the FF devices node), right clicking to expose a context menu 403, and then selecting the "New Definition” option 404. Thereafter, the user is prompted to provide a name for the new template (for display on the tree) as well as other information
  • the derived template is saved as a child node of the template node from which it is derived.
  • An inheritance relationship is thus established between a parent template and all children derived there from.
  • Such template inheritance can be applied to render a set of application-specific device DTMs.
  • a pressure transmitter DTM template can have a set of application-specific child templates for use in flow, tank level, and pressure applications.
  • Hierarchical template definitions provides a number of advantages.
  • One or more levels of derivation can be used to incorporate application-specific knowledge into more generally defined parent (e.g., device-specific templates) - information that would otherwise need to be provided by a commissioning engineer in the field.
  • the information defined for a device becomes more specific.
  • Including application-specific information in one or more levels of child device templates can thus save time when deploying or replacing devices as well as reduce the knowledge load on device commissioning agents.
  • Such use of a hierarchy of templates with various degrees of application-specific knowledge applied at the various levels, in the context of the universal DTM 200, also facilitates standardizing device configuration across a project or enterprise by ensuring a certain degree of common behavior/operation of devices used in similar applications. Such standardization cannot otherwise be assured in without time-consuming/exhaustive review of potentially very large numbers of parameter values assigned to hundreds or even thousands of devices distributed across an enterprise. Selecting FDT on the context menu 403 exposes an FDT sub-menu 406.
  • the FDT aspect of the IACC system supports both vendor-specific DTMs and universal DTM implementations for selected device types. Selecting the Associate Vendor option on the FDT sub-menu 406 enables a user to launch any one of potentially multiple vendor-coded DTMs within the IACC frame application. Such specialized vendor-developed/coded DTMs are well known in the art and will not be discussed further herein.
  • the universal DTM 200 embodying the present invention is launched, on-demand, based upon the currently selected template node (BA30) and a standard DD provided from a library of standard DDs managed by the DD engine 212.
  • the universal DTM 200 is customized on- demand to a specific device type, at the time it is launched by a user's input.
  • the device- specific customizations to the universal DTM 200 are based upon a DTM template (corresponding to the currently selected node on the system tree within pane 400) and the associated standard DD associated with a device type associated with the DTM template.
  • the resulting customized universal DTM interfaces share a common base functionality and look-and-feel for users.
  • a first screen or "home page" graphical user interface 500 is generated by the presentation object 206.
  • the home page graphical user interface includes a variety of status notifications as well as an initial set of information associated with the DTM customization template/instance and DD incorporated dynamically, on-demand into the universal DMT 200 at the time of launch.
  • the graphical user interface for the universal DTM 200 includes an information tab 502 that is automatically selected when the on-demand customized universal DTM is launched.
  • device information screen device identification and more general information about the device type represented by the template (or device instance created from a device-specific template) are displayed.
  • a device tree 504 represents blocks associated with the current device type as a set of sub-nodes under a device template root name (e.g., Foxboro.RTT25-F2.020101). Selecting one of the block nodes under the device root launches a customized universal BTM instance to be launched and presentation of a block first screen (see, FIG. 10 described herein below) similar to the first screen for the customized universal DTM.
  • a device identification pane 506 displays device type information from a DD and CFF obtained by the universal DTM 200 from the DD Engine 212. Such information includes: device manufacturer, device type, device version, DD version, and CFF file revision. The device identification pane 506 also provides specific device instance information including: device tag, device Address, and device ID. When the universal DTM 200 is connecting to a corresponding device it checks the device identification information against the loaded parameter values from the device.
  • a display box 508 potentially displays any of a variety of graphics displays associated with the specified device type referenced by the universal DTM 200.
  • a graphic to be added to a list within a graphics files pane 510) the user clicks on an Add button.
  • a resulting popup menu the user selects a File Open option.
  • a dialog opens to let the user define whether the graphics should be instance or device type specific.
  • To delete an entry the user selects the appropriate text reference within the graphics files pane 510 and presses a delete button. To display the information the user selects the reference. The graphics are thereafter rendered in the display box 508.
  • a links box 520 enables a user to enter electronic data links to any of a variety of information sources including URL's, network/file names, etc. referencing documentation in any of a wide variety of formats (e.g., .pdf, .bmp, .rtf, etc.).
  • a user enters a link within the links box 520 by clicking on an Add Button.
  • the user selects File Open.
  • File Open With a resulting standard File Open Dialog the user navigates through a system directory and selects a file. Afterwards a dialog opens to let the user define whether the linked file/document should be instance or device type specific.
  • To delete an entry the user selects the appropriate text reference within the graphics files pane 520 and presses a delete button.
  • To display the information the user selects the reference, and the resulting information is rendered in a viewing application that is launched in response to the selection (e.g., a .pdf viewer application).
  • a device type comments box 530 enables a user to enter textual information for the device type. It will be stored and be visible for all device types. Edit functions are supported for adding or changing text within box 530. The text within the device type comments box 530 is stored with any other customization data associated with the particular derived template when the derived template is stored.
  • a device comments box 540 enables a user to enter textual information for a particular device instance.
  • the content displayed within the device comments box 540 is only visible for the particular device instance, if any, associated with the current customized DTM instance.
  • the instance specific information is stored with all other parameter values with the FDT interfaces for persistence data in the frame application's database. This information persists with the device instance and is not tied to any template.
  • the first screen graphical user interface 500 provides an extensible platform for providing summary information to a user without having to navigate through a number of user interfaces.
  • the first screen user interface 500 while initially exposing the contents of an "information tab 502, supports an extensible set of additional tabs - each providing a particular type of information relating to a specified device type template or instance.
  • the set of tabs include: system management, network management, diagnostics, and security. Each of these types is described herein below with reference to FIGs. 6-9.
  • FIG. 6 an exemplary system management graphical interface 600 is provided by the customized universal DTM when a user selects the "SM" tab on the first screen graphical user interface 500.
  • the system management graphical interface 600 provides access to a variety of system management parameters associated with the customized universal DTM.
  • Parameters that are changeable in off-line mode include Device ID, Device Tag, Operational Powerup, Tl, T2, and T3.
  • the parameters Clock Sync Interval and Macrocycle Duration are only changeable if the device is a configuration master.
  • a link master assigns the Device address, but the user should be able to change it.
  • an exemplary network management graphical interface 700 is provided by the customized universal DTM when a user selects the "NM" tab on the first screen graphical user interface 500.
  • the network management graphical interface 700 only displays information relating to the network when connected on-line to an actual field device corresponding to the customized universal DTM operating in association with a field device instance and its associated device information provided by the DD engine 212.
  • an exemplary diagnostics graphical interface 800 is provided by the customized universal DTM when a user selects the "Diags" tab on the first screen graphical user interface 500.
  • the diagnostic screen rendered when a user selects the Diags tab, presents the overall status of the device. Like the NM tab, the Diags tab operates in conjunction with an on-line device instance.
  • the diagnostic interface 800 presents, by way of example, the following:
  • Device identification information (including Device tag, device ID and device address in the header);
  • Resource block status including Block Mode and Block error information
  • Transducer Block Status Including Block mode and XD error information
  • Function block status including Block mode, Block error and Status and value for the connectable parameters
  • an exemplary security graphical interface 900 is provided by the customized universal DTM when a user selects the "Security" tab on the first screen graphical user interface 500.
  • the universal DTM 200 supports a set of configurable access levels that are displayed in the form of a parameter permission / modification matrix displayed in the device parameter matrix 910.
  • the matrix 910 comprises a set of cells determining the ability of a set of identified classes of user to read and/or write parameter data associated with the device represented in the customized universal DTM.
  • a Tabs matrix 920 defines user class access to content represented under each of the aforementioned tabs displayed on the first screen as well as each of the graphical user interfaces described herein with reference to FIGs. 5-9.
  • a Functions matrix 930 defines the functions of the customized universal DTM that are accessible to the various user classes identified in the column headings. In the illustrative example, the Functions matrix identifies DD methods that can be invoked by different user classes as defined by their different roles in the project. Each device type can thus be associated with a corresponding permissions matrix.
  • FIG. 10 an exemplary universal BTM first page 1000 is illustratively depicted (in the present case for a transducer block, TR l identified in the device/block tree).
  • the interface contains much of the same information types and functionality described previously hereinabove with reference to the device first page 500.
  • the home page corresponds to an Identification tab.
  • the associated screen depicted in FIG. 10 shows information concerning the instance of the block in "Block" section 1002.
  • the Block section 1002 is initially loaded from a block description provided by the DD Engine 212. If the business object 214 is online, then the information is read from the block's parameter 0. The following information is available in this section: • Block type
  • a display box 1008 potentially displays any of a variety of graphics displays associated with the specified device type referenced by the universal BTM 210.
  • To enter a reference to a graphic (to be added to a list within a graphics files pane 1010) the user clicks on an Add button.
  • a resulting popup menu the user selects a File Open option.
  • With a resulting standard File Open Dialog the user navigates through a system directory and selects a file. Afterwards a dialog opens to let the user define whether the graphics should be instance or device type specific.
  • To delete an entry the user selects the appropriate text reference within the graphics files pane 1010 and presses a delete button. To display the information the user selects the reference. The graphics are thereafter rendered in the display box 1008.
  • a links box 1020 enables a user to enter electronic data links to any of a variety of information sources including URL's, network/file names, etc. referencing documentation in any of a wide variety of formats (e.g., .pdf, .bmp, .rtf, etc.).
  • a user enters a link within the links box 1020 by clicking on an Add Button.
  • the user selects File Open.
  • File Open With a resulting standard File Open Dialog the user navigates through a system directory and selects a file. Afterwards a dialog opens to let the user define whether the linked file/document should be instance or device type specific.
  • To delete an entry the user selects the appropriate text reference within the graphics files pane 1020 and presses a delete button.
  • To display the information the user selects the reference, and the resulting information is rendered in a viewing application that is launched in response to the selection (e.g., a .pdf viewer application).
  • the GUI for the universal BTM 210 also includes a Configuration tab.
  • an exemplary configuration graphical interface 1100 is provided by the customized universal BTM 210 when a user selects the "Configuration" tab.
  • the user is able to specify parameters in the block.
  • a user names and builds configuration entries corresponding to the blocks of a field device by selecting parameters from a list of block parameters.
  • the parameters of each identified block are identified by "parameter name” and current/last known value for the parameter is displayed in an adjacent column.
  • a units column and help column are also included for storing additional information relating to the block parameters.
  • an exemplary tuning graphical interface 1200 is provided by the customized universal BTM 210 when a user selects the "Tuning" tab.
  • the tuning tab interface 1200 combines the characteristics of a "Configuration” tab and a "Watch” tab.
  • the tuning interface 1200 allows a user to modify device parameters.
  • the interface 1200 also displays parameter values within a chart of Block Parameters.
  • the set of parameters are dynamically updated and displayed vertically over time.
  • the tuning interface 1200 allows the user to see the effect of changes made to the parameters in real time. It is thus used for tuning the blocks.
  • an exemplary watch graphical interface 1300 is provided by the customized universal BTM 210 when a user selects the "Watch" tab.
  • the watch graphical interface 1300 displays a user defined set of parameters over time.
  • the parameters are dynamically updated in a time sequence. Rather than showing the parameter and the current value it displays the parameter and the value over a span of time.
  • the user can display the parameter values either in a grid (presently shown) or in a graphical plot.
  • an exemplary diagnostics graphical interface 1400 is provided by the customized universal BTM 210 when a user selects the "Diagnostics" tab.
  • the diagnostics graphical interface 1400 displays a user defined set of parameters.
  • the parameter values are dynamically updated.
  • the screen shows the parameter name and the current value for the parameter.
  • the diagnostics graphical interface 1400 screen is thus used to display diagnostic parameters in a device which may be changing over time.
  • an exemplary methods graphical interface 1600 is provided by the customized universal BTM 210 when a user selects the "Methods" tab.
  • the methods are a scripting like language written in device description language. These scripts are written by the device vendor to perform specific functions.
  • the methods graphical interface 1500 shows the methods in the device description file and interacts with the DD Engine 212 to execute the method script.
  • an exemplary security graphical interface 1600 is provided by the customized universal BTM 210 when a user selects the "Security" tab.
  • the universal BTM 210 supports a set of configurable access levels that are displayed in the form of a set of parameter, method, function and screen permission / modification matrices.
  • the customization tool facilitates modifying device editor definitions of existing device templates, through a set of graphical user interface screens, to define child templates having customized user access to device/block parameters that are presented via the universal DTM/BTM graphical user interface screens (described herein above).
  • the same customization capability can be used to modify an existing device editor definition associated with a device template.
  • child templates exist, the children inherit the changes based upon value locking designations described further herein below.
  • the illustrative embodiment of the customization tool described herein below is directed to a universal BTM.
  • the customization tool is equally applicable to the editor definitions associated with DTM.
  • the customization tool is used to modify an existing editor for a particular device template and store the customized version as a derived child device template.
  • an expert instrument engineer utilizes the customization tool to edit a previously created DTM/BTM editor definition to specify particular display screens and permissions associated with the editor interface for the particular device type associated with the device template.
  • the changes can be directed, for example, to the permissions definitions associated with the device type's editor, thereby defining customized access to appropriate parameters by certain classes of individuals.
  • an operator's display screens include only device/block status information, while a process engineer's display screens provide read/write access to parameters for configuring and/or maintaining the field devices.
  • the device template containing the modified editor definition is stored as a child template of the template from which it was derived within the engineering database 202.
  • FIG. 17 an exemplary graphical user interface is provided for a user with sufficient credentials to invoke a customization tool by selecting a Customize tab 1700 from a home page for a transducer block. It is noted that the customization tool is also invoked by selecting a Customize tab for a device from a graphical user interface provided by a universal device type manager.
  • a customization main page displayed in FIG. 17 presents a set of user options for customizing the defined interfaces and permissions associated with the currently loaded editor for the device type template.
  • the customization tool comprises a set of six views that are accessed by a set of corresponding buttons (e.g., Group Parameters 1702, Group Overview 1704, Define Tabs 1706, Tab Overview 1708, Set Parameters 1710, and Setup Downloads 1712).
  • buttons e.g., Group Parameters 1702, Group Overview 1704, Define Tabs 1706, Tab Overview 1708, Set Parameters 1710, and Setup Downloads 1712.
  • the customization tool upon selecting the Group Parameters 1702 button, presents a customization page/dialog that enables a user to categorize parameters. This provides a user the opportunity to arrange parameters on a user interface according to their use (e.g., configuration, diagnostics, calibration, process data, etc.).
  • These user-customized parameter group definitions are potentially used to define the arrangement of parameters within other display screens of the editor utility for accessing/displaying field device information.
  • the group designations are also used to enforce different access rights to various user classes/roles/tasks.
  • a set of previously defined groups is accessed via a Parameter Group box 1800.
  • the Parameter Group box 1800 is, by way of example, a drop-down list (e.g., combo box) control that provides a list of currently defined parameter groups.
  • the user selects one of the groups (e.g., Process) to reveal the current set of parameters assigned to the group, and modify the assigned set of parameters.
  • the parameters presently assigned to the "process" set are displayed in box 1802.
  • a user adds new parameters to the set by selecting one of the parameters in box 1804 and then selecting the add button 1806.
  • the user removes a parameter from the set by selecting a parameter in box 1802 and then selecting the remove button 1808.
  • a parameter is assignable to multiple groups. For example a parameter can be assigned to both a "diagnostic” parameters group as well as the "process” parameters group.
  • the Parameter Group dialog depicted in FIG. 18 also supports adding and removing groups.
  • selecting the "Group Names" 1814 button launches a dialog box that lists all the presently existing parameter groups.
  • Controls e.g., buttons
  • a parameter name field 1900 specifies a parameter of either a simple type or a structure including sub-parameters. Structure parameters are identified by a "+/-" sign adjacent to an index number in an index column 1902. When a "+" sign is selected, the structure is expanded to reveal sub-parameters.
  • Parameter Groups are identified at column headings. Each group's assigned parameters are indicated by checked boxes with the appropriate group column. A user can select any checkbox to change a parameter's membership status in any group. When a "show all parameters" checkbox 1904 is unchecked, the Group Overview dialog only lists parameters that have not yet been assigned to any group. Parameters assigned to a group will not be visible. This allows the engineer to determine which device parameters have not been assigned to any group and assign them.
  • the customization tool upon selecting the Define Tabs 1706 button, presents a customization page/dialog that indicates associations between parameter groups and tabs - where the tabs correspond to a current set of pages/views of information presented by the customized device editor (e.g., Configuration, Diagnostics, Tuning, and Watch in FIG. 17).
  • a user via the Define Tabs dialog, creates new views to display particular groups of parameters.
  • the interface in FIG. 20 shows the currently defined tabs and parameter groups.
  • the dialog shows which parameter groups a tab displays and whether all parameters in the group are displayed or a subset.
  • a user can select the "Tab Names" 2000 button to invoke a dialog for creating a new tab name of a particular tab type.
  • the Tab Names... dialog shows all of the tabs currently defined. Pressing a "New" button creates a new entry (tab/view) in a displayed tab list. A Remove button facilitates removing an existing tab (which may be blocked in the case of certain required tabs). Furthermore, a user can assign a "type" to a tab.
  • Configuration tabs display parameters and allow an engineer to enter values. Diagnostic tabs read the current value from the device and display it to the engineer. They do not allow modifications to the displayed values. Watch tabs read values from the device and periodically update the display. Watch tabs show the parameter values changing over time. Tuning tabs contain two panes. A first pane acts like a configuration tab, allowing the engineer to modify device values. A second pane shows selected parameters changing over time.
  • FIG. 21 An illustrative dialog for editing the parameters associated with a named tab is presented in FIG. 21. Selecting the "Details" button causes the editor facility to display a dialog that shows parameters currently assigned to a tab.
  • a combo box 2100 lists various classes of parameters to be displayed in the pool of available parameters on a left pane 2102.
  • a right pane 2104 displays a set of parameters presently associated with the (Process) tab. The engineer selects parameters in the left hand pane and add them to the tab by pressing the "»" button. After adding a parameter to the tab, the parameter is shown in the right hand pane. The engineer selects parameters from different groups to add to the tab. The engineer can also select parameters currently in the tab and remove them by pressing the " «" button.
  • the customization tool upon selecting the Tab Overview 1708 button, presents a customization page/dialog that displays a dialog that provides an overview of all the parameters and the selectable tabs/views within which they are presented. A single parameter can be presented on multiple tabs/views.
  • the engineer uses the Tab Overview dialog depicted in FIG. 22 to assign a parameter to a tab by checking the check box under the tab column for a parameter. This has the same behavior as assigning parameters to a tab through the Define Tab dialog described herein above with reference to FIG. 21.
  • the Tab Overview dialog in FIG. 22 does not allow the engineer to create or delete tabs. Only existing tabs can be seen.
  • a "show all parameters" check box 2200 when unchecked, shows only parameters that are presently not assigned to any tab/view. Parameters assigned to a tab will not be visible. This allows the engineer to determine which device parameters have not been assigned to any tab and assign them.
  • the customization tool upon selecting the Set Permissions 1710 button, the customization tool presents a customization page/dialog that displays a dialog for facilitating defining access and security for parameters and tabs based on a user's class/task/role (referred to herein generally as "role").
  • the Set Permissions dialog replaces the Security tab presented in the embodiment depicted in FIG. 9.
  • a Parameter pane 2300 shows all the parameters for the device. Roles are identified by column heading in each pane. The engineer specifies the access allowed to each user type based on their role. Parameter access can be set to be Read or Read & Write.
  • a Screen name pane 2302 facilitates specifying which tabs/views of the customized view sets are visible to particular roles. Thus, in the illustrative example "observers" will not have access to the Configuration, Compare, or Customize tabs/views on the customized device/block editor interfaces.
  • a Function name pane 2304 facilitates specifying operations supported by the editor such as adding notes about a device on a role/user-type basis. The engineer enables or disables the operation to be accessible to a user based on their defined role.
  • the parameter definitions for a device in a DD file do not specify whether parameters must be written to the device in a specific order. Nor do the parameter definitions specify a device mode that a device must be in for the parameter write to occur. Furthermore, after writing a parameter, a delay may be required before a next parameter is written to the device.
  • the customization tool upon selecting the Setup Downloads 1708 button, the customization tool presents a customization page/dialog that displays a dialog that facilitates specifying parameter write operations.
  • the Setup Downloads dialog displays a list of candidate parameters in a left hand pane 2400.
  • the parameters displayed in pane 2400 are filtered by selecting a parameter group from a combo box 2402 that lists various classes, groups, types of parameters. As an example an engineer selects an entry within combo box 2402 to show only parameters in a "Process" group.
  • Parameters that are to be written to a device as part of a device download operation are designated by adding a parameter from pane 2400 to a writable list pane 2403.
  • the download behavior is defined for each parameter in the writable list pane 2403 by designating a device operation mode within which the parameter can be downloaded.
  • a delay after writing a parameter is also designated in a Wait column in pane 2403.
  • the order of downloading a parameter is modified by selecting the parameter and pressing the "up" or "down” button adjacent to the pane 2403. These buttons move the parameters up or down in the middle pane display.
  • An engineer adds parameters to the download list pane 2404 from the writable list pane 2403 by selecting parameters in the pane 2403 and then pressing the "»" button. Pressing the "»" button makes a copy of the parameter in the right hand pane. In other words the parameter is shown both in the middle pane and in the right hand pane.
  • the definition of write mode and time delay is used during commissioning by reading a value specified for the corresponding entry in the writable list pane 2403.
  • the engineer removes parameters from the commissioning set by selecting parameters in pane 2404 and pressing the " «" between panes 2403 and 2404.
  • the customization editor described herein also supports specifying default parameter values. Such values are specified by exposing the parameter in one of the tabs/views containing the parameter and entering a value.
  • the values submitted during customization are stored in association with the definition of the customized child template.
  • value and editor interface customization locking is supported to prevent modifications to particular child templates and values assigned to particular parameters.
  • Such locking is generally designated by an administrator. Locking is achieved by clicking on the lock icon shown next to parameters and buttons in the dialogs displayed in FIGs. 18-24 described herein above.
  • a locked parameter prevents unauthorized engineers using the template or instances derived from the template, from modifying the customization or values.
  • an expert instrument engineer can define a device template which allows the engineers using the templates to set up a device to modify or set only a very small number of parameters.
  • the lock in the dialogs for a customized template implements the following lock paradigm: • Parameters Locked in Parent inherit value, and retain a link to the value, in the parent. These parameters can not be modified • Parameters Locked in Me can be modified. These parameters do not maintain a link to the value in the parent. These parameters become Locked in Parent when the template is inherited • Parameters Unlocked can be modified. They do not maintain a link to the value in the parent.
  • an engineer invokes a customization process by selecting a New Definition option on the context menu 404 (in FIG. 4) for an existing device type template (BA 30) to commence the customization process on a new child device template. This process is summarized in FIG. 25.
  • a child template is created from an existing device type template - which may itself be a child of yet another template. If the child template is derived from the generic root device (e.g., FF Device), then the user takes additional steps to associate the child device template with a device type including associated DD and CFF files for the device type of interest. This step is by-passed when creating child templates from existing templates that are already associated with a device type.
  • the generic root device e.g., FF Device
  • step 2502 assuming an engineer has a proper assigned role, the engineer utilizes customization tool interfaces described hereinabove with reference to FIGs. 17-24 to define the customized editor definition for the child device template.
  • the child device template is then stored during step 2504 under the parent template from which it was derived.
  • an association is established, if not already present, between the child device template and a device definition.
  • This association facilitates presentation of the child template as a suitable device type (and thus editor) when creating a new device instance.
  • the association facilitates automated filtering of device templates from which an engineer creates device instances for an actual hardware configuration. Multiple child templates can be associated with a same device description.
  • FIG. 26 a set of steps summarize the use of an instance of the child device template, including the customized editor definition, to provide a customized editor interface for the device instance for a logged on user having a particular role.
  • an instance of the child device template including a customized editor definition, is created for a particular device/block in a system.
  • the instance is created, for example, when a user seeks to add a device (and its associated blocks) to a control system engineering database.
  • suitable templates are presented to the user based upon, for example, a specified device type. The user selects one of the presented device templates.
  • a user invokes the customized editor on the device instance to carry out a task.
  • the user at the time of the request, has logged onto the system and has a set of associated roles that were previously defined by an administrator.
  • the host of the child editor passes the roles associated with the requesting user to the child editor instance.
  • the child editor instance thereafter customizes the access provided to the user (including both the tabs and associated views displayed in FIGs. 17-24) based upon the provided roles. It is noted that while the aforementioned exemplary steps in both FIGs. 25 and
  • a Compare utility is exposed via the editor interface associated with a particular device type in accordance with an embodiment of the present invention.
  • the compare utility extracts a copy of previously stored parameter values from the engineering database 202 for a device instance and compares those values to a set obtained from an actual live device.
  • the copy of values from the database 202 is generally a default configuration, while the values from the live device have undergone some transformation, either intentional or inadvertent, to reside in a possibly faulty state.
  • the Compare utility user interface depicted in FIG. 27, and its associated functionality enables a user to view differences between the device configuration as stored in the engineering database and a current configuration in a physical device and any blocks in the device with a minimized degree of effort. Such comparison of values helps ensure the physical device is executing with an intended configuration. Conversely, the live values from a device may actually be the desired source of data for the engineering database 202.
  • the Compare utility also facilitates updating the engineering database 202 if device maintenance dictates changes to the configuration. For example, the Compare utility corresponding to the graphical user interface depicted in FIG. 27 is used to review a set of configured settings against a standard/default set of parameter values for a device as part of a device commissioning procedure performed in the workshop.
  • the Compare dialog view is displayed by the editor facility.
  • the dialog initially displays values from the engineering database in the Database Value column 2702.
  • the Device Value column 2704 is initially blank.
  • the compare utility invokes a series of read operations on the device associated with the currently executing editor facility to acquire corresponding parameter data from the device.
  • the received data values are presented, upon receipt, within the Device Value Column.
  • the Compare dialog view also contains a transiently depicted progress indicator (not shown in present view showing comparison results) that tracks the progress of reading device values from the device.
  • the device values are updated on demand using a Refresh button 2708.
  • the refresh button 2708 is used, for example, to display new values as changes are made to the device.
  • Compare utility Another aspect of the Compare utility and its associated dialog view is that the respective values from the database 208 and the device are compared after both have become available.
  • a graphical indication e.g., ⁇ , an unequal sign
  • an unequal sign
  • the Compare dialog supports filtering parameters.
  • filters include: display only parameters with non-matching values, display only a particular defined group of parameters, only selected parameters (indicated by checking the column on the left side of the dialog view. These filter modes are invoked by checking the appropriate box at the bottom of the dialog view. The last filter is to show selected parameters when the "Selections Only" box is checked. The user can click on a row to select parameters. Once parameters have been selected, the user can elect to download the database value to the device by pressing a Download SeI button 2710. The user can also select parameters which will be written to the database to become part of the engineering configuration by pressing an Upload SeI button 2712 after selecting parameters.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Manufacturing & Machinery (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Programmable Controllers (AREA)
  • User Interface Of Digital Computer (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un outil de personnalisation en association avec un utilitaire de gestionnaire type de dispositif universel (DTM). L'outil de personnalisation comporte un ensemble d'interfaces utilisateur et une fonctionnalité associée qui facilite la création d'un ensemble de modèles personnalisés pour un type de dispositif particulier. Le modèle personnalisé définit l'accès à des données de dispositif par le biais d'interfaces graphiques supportées par l'utilitaire DTM universel et/ou l'utilitaire BTM universel pour des instances du type de dispositif. Un outil de comparaison permet de comparer des valeurs de paramètres à partir d'une instance d'un dispositif de terrain à des valeurs correspondantes conservées dans une base de données d'application. Après la comparaison, l'utilitaire affiche les noms de paramètres et les valeurs associées en trois colonnes de l'interface utilisateur. Une première colonne identifie un paramètre dans le dispositif de terrain. Une deuxième colonne identifie une valeur précédemment archivée pour le paramètre identifié dans la première colonne, et une troisième colonne identifie une valeur courante, capturée à partir d'une instance de dispositif, correspondant au paramètre identifié dans la première colonne.
PCT/US2007/066394 2006-04-11 2007-04-11 Outil d'édition de dispositif de terrain WO2007121218A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP07760453A EP2010991A4 (fr) 2006-04-11 2007-04-11 Outil d'édition de dispositif de terrain

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US11/403,228 2006-04-11
US11/403,224 2006-04-11
US11/403,228 US20070078540A1 (en) 2005-10-05 2006-04-11 Utility for comparing deployed and archived parameter value sets within a field device editor
US11/403,226 2006-04-11
US11/403,226 US8799793B2 (en) 2005-10-05 2006-04-11 Tool for creating customized user interface definitions for a generic utility supporting on-demand creation of field device editor graphical user interfaces
US11/403,224 US8527888B2 (en) 2006-04-11 2006-04-11 Method and supporting configuration user interfaces for streamlining installing replacement field devices

Publications (2)

Publication Number Publication Date
WO2007121218A2 true WO2007121218A2 (fr) 2007-10-25
WO2007121218A3 WO2007121218A3 (fr) 2008-09-18

Family

ID=38610315

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/US2007/066244 WO2007121141A2 (fr) 2006-04-11 2007-04-09 Procédé et interfaces utilisateur de configuration de soutien pour rationaliser l'installation de dispositifs de terrain de remplacement
PCT/US2007/066394 WO2007121218A2 (fr) 2006-04-11 2007-04-11 Outil d'édition de dispositif de terrain

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/US2007/066244 WO2007121141A2 (fr) 2006-04-11 2007-04-09 Procédé et interfaces utilisateur de configuration de soutien pour rationaliser l'installation de dispositifs de terrain de remplacement

Country Status (3)

Country Link
EP (2) EP2011009A4 (fr)
CN (1) CN101460928B (fr)
WO (2) WO2007121141A2 (fr)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008043095A1 (de) * 2008-10-22 2010-04-29 Endress + Hauser Process Solutions Ag Verfahren zum Parametrieren eines Feldgerätes
GB2481496A (en) * 2010-06-21 2011-12-28 Fisher Rosemount Systems Inc Sending recorded configuration data to replacement process control field devices
US20120310384A1 (en) * 2011-05-31 2012-12-06 General Electric Company Systems and methods for identifying foundation fieldbus linking devices
US8713166B2 (en) 2011-05-31 2014-04-29 General Electric Company Systems and methods for facilitating communication with foundation fieldbus linking devices
US8762528B2 (en) 2011-05-31 2014-06-24 General Electric Company Systems and methods for write protecting foundation fieldbus linking devices
US8868732B2 (en) 2011-05-31 2014-10-21 General Electric Company Systems and methods for facilitating communication with foundation fieldbus linking devices
US9094299B1 (en) * 2013-01-08 2015-07-28 Juniper Networks, Inc. Auto-generation of platform-independent interface and operational scripts for configuring network devices
US9130853B2 (en) 2011-05-31 2015-09-08 General Electric Company Systems and methods for identifying foundation fieldbus linking devices
DE102014016819A1 (de) * 2014-11-14 2016-05-19 Abb Technology Ag Verfahren und Einrichtung zur Verwaltung und Konfiguration von Feldgeräten einer Automatisierungsanlage
WO2018082872A1 (fr) * 2016-11-03 2018-05-11 Endress+Hauser Process Solutions Ag Fourniture d'informations relatives à des fonctionnalités supplémentaires de composants de bus de terrain
US20180356801A1 (en) * 2015-11-30 2018-12-13 Endress+Hauser Process Solutions Ag Method and system for optimizing the operation of at least one of a plurality of field devices from automation technology
US10209695B2 (en) 2013-11-22 2019-02-19 Abb Schweiz Ag Method and a system for replacing and commissioning of a field device
CN111007809A (zh) * 2018-09-28 2020-04-14 费希尔-罗斯蒙特系统公司 在过程工厂内的现场设备的批量调试

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008001886A1 (de) * 2008-05-20 2009-11-26 Endress + Hauser Flowtec Ag Verfahren zum Austausch von Parametrier- und Konfigurierdaten zwischen einem Konfigurier- oder Managementsystem und einem Feldgerät
US9229947B2 (en) * 2010-09-27 2016-01-05 Fisher-Rosemount Systems, Inc. Methods and apparatus to manage process data
DE102010062908B4 (de) 2010-12-13 2012-10-31 Siemens Aktiengesellschaft Verfahren zum Parametrisieren eines Gerätes, parametrisierbares Gerät und Parametrisierungsvorrlchtung
DE102010055337B4 (de) * 2010-12-21 2021-12-16 Abb Ag Integration von Feldgeräten in ein verteiltes System
CN102148711B (zh) * 2011-04-08 2013-12-18 瑞斯康达科技发展股份有限公司 一种网络设备的备份方法和系统
US10185308B2 (en) * 2012-04-30 2019-01-22 Fisher Controls International Llc Methods and systems to provide update information of a device description of a field instrument
US9563188B2 (en) 2013-08-01 2017-02-07 General Electric Company Systems and methods for batch device commissioning and decommissioning
DE102013218971A1 (de) * 2013-09-20 2015-03-26 Vega Grieshaber Kg Kundenspezifische Konfiguration und Parametrierung von Füllstandmessgeräten beim Bestellvorgang
US10018998B2 (en) 2014-02-14 2018-07-10 Yokogawa Electric Corporation Field device commissioning system and field device commissioning method
US9719887B2 (en) 2014-02-14 2017-08-01 Yokogawa Electric Corporation Field device commissioning system and field device commissioning method
US10078034B2 (en) 2014-02-14 2018-09-18 Yokogawa Electric Corporation Field device commissioning system and field device commissioning method
DE102014007386A1 (de) * 2014-05-20 2015-11-26 Abb Technology Ag Verfahren und Einrichtung zur Verwaltung und Konfiguration von Feldgeräten einer Automatisierungsanlage
US10623244B2 (en) 2014-12-19 2020-04-14 Emerson Process Management Lllp Data transfer on an industrial process network
US9921569B2 (en) * 2015-03-06 2018-03-20 Yokogawa Electric Corporation Field device commissioning system and method
CN105093937B (zh) * 2015-03-13 2018-09-18 霍尼韦尔环境自控产品(天津)有限公司 楼宇控制系统设计设备和方法
CN105093938B (zh) * 2015-03-13 2018-08-24 霍尼韦尔环境自控产品(天津)有限公司 楼宇控制系统设计及维护设备和方法
CN105093939B (zh) * 2015-03-13 2018-12-14 霍尼韦尔环境自控产品(天津)有限公司 楼宇控制系统设计及调试设备和方法
US10502340B2 (en) * 2015-08-17 2019-12-10 Honeywell International Inc. System for a valve setup
GB2560647B (en) * 2015-10-12 2022-09-21 Fisher Rosemount Systems Inc Configuration in process plant using I/O-abstracted field device configurations
WO2022106885A1 (fr) * 2020-11-18 2022-05-27 Myomega Systems Gmbh Système de commande industrielle
CN116482985A (zh) * 2022-11-25 2023-07-25 苏州金梓树智能科技有限公司 基于变量差异进行模式切换的数据处理方法及系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5617522A (en) * 1995-04-03 1997-04-01 Honeywell Inc. Methods and apparatus for providing and/or customizing display screens and operator interfaces for process control and measurement instruments
US5960169A (en) * 1997-02-27 1999-09-28 International Business Machines Corporation Transformational raid for hierarchical storage management system
US6342907B1 (en) * 1998-10-19 2002-01-29 International Business Machines Corporation Specification language for defining user interface panels that are platform-independent
US6754885B1 (en) * 1999-05-17 2004-06-22 Invensys Systems, Inc. Methods and apparatus for controlling object appearance in a process control configuration system
US6788980B1 (en) * 1999-06-11 2004-09-07 Invensys Systems, Inc. Methods and apparatus for control using control devices that provide a virtual machine environment and that communicate via an IP network
US6449715B1 (en) * 1999-10-04 2002-09-10 Fisher-Rosemount Systems, Inc. Process control configuration system for use with a profibus device network
US6801920B1 (en) * 2000-07-05 2004-10-05 Schneider Automation Inc. System for remote management of applications of an industrial control system
US7797634B2 (en) * 2002-10-31 2010-09-14 Brocade Communications Systems, Inc. Method and apparatus for displaying network fabric data

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of EP2010991A4 *

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008043095A1 (de) * 2008-10-22 2010-04-29 Endress + Hauser Process Solutions Ag Verfahren zum Parametrieren eines Feldgerätes
GB2481496A (en) * 2010-06-21 2011-12-28 Fisher Rosemount Systems Inc Sending recorded configuration data to replacement process control field devices
US8832236B2 (en) 2010-06-21 2014-09-09 Fisher-Rosemount Systems, Inc. Methods, apparatus and articles of manufacture to replace field devices in process control systems
US9130853B2 (en) 2011-05-31 2015-09-08 General Electric Company Systems and methods for identifying foundation fieldbus linking devices
US20120310384A1 (en) * 2011-05-31 2012-12-06 General Electric Company Systems and methods for identifying foundation fieldbus linking devices
US8713166B2 (en) 2011-05-31 2014-04-29 General Electric Company Systems and methods for facilitating communication with foundation fieldbus linking devices
US8762528B2 (en) 2011-05-31 2014-06-24 General Electric Company Systems and methods for write protecting foundation fieldbus linking devices
US8769072B2 (en) 2011-05-31 2014-07-01 General Electric Company Systems and methods for identifying foundation fieldbus linking devices
US8868732B2 (en) 2011-05-31 2014-10-21 General Electric Company Systems and methods for facilitating communication with foundation fieldbus linking devices
US9094299B1 (en) * 2013-01-08 2015-07-28 Juniper Networks, Inc. Auto-generation of platform-independent interface and operational scripts for configuring network devices
US10209695B2 (en) 2013-11-22 2019-02-19 Abb Schweiz Ag Method and a system for replacing and commissioning of a field device
DE102014016819A1 (de) * 2014-11-14 2016-05-19 Abb Technology Ag Verfahren und Einrichtung zur Verwaltung und Konfiguration von Feldgeräten einer Automatisierungsanlage
US10416640B2 (en) 2014-11-14 2019-09-17 Abb Schweiz Ag Method and device for managing and configuring field devices in an automation installation
US20180356801A1 (en) * 2015-11-30 2018-12-13 Endress+Hauser Process Solutions Ag Method and system for optimizing the operation of at least one of a plurality of field devices from automation technology
US10698389B2 (en) * 2015-11-30 2020-06-30 Endress+Hauser Process Solutions Ag Method and system for optimizing the operation of at least one of a plurality of field devices from automation technology
WO2018082872A1 (fr) * 2016-11-03 2018-05-11 Endress+Hauser Process Solutions Ag Fourniture d'informations relatives à des fonctionnalités supplémentaires de composants de bus de terrain
US10783099B2 (en) 2016-11-03 2020-09-22 Endress+Hause Process Solutions AG Provision of information regarding additional functionalities of field bus components
CN111007809A (zh) * 2018-09-28 2020-04-14 费希尔-罗斯蒙特系统公司 在过程工厂内的现场设备的批量调试

Also Published As

Publication number Publication date
EP2011009A2 (fr) 2009-01-07
EP2010991A4 (fr) 2011-06-01
WO2007121218A3 (fr) 2008-09-18
EP2011009A4 (fr) 2011-06-29
EP2010991A2 (fr) 2009-01-07
CN101460928B (zh) 2012-02-08
WO2007121141A2 (fr) 2007-10-25
WO2007121141A3 (fr) 2008-02-14
CN101460928A (zh) 2009-06-17

Similar Documents

Publication Publication Date Title
US9513785B2 (en) Tool for creating customized user interface definitions for a generic utility supporting on-demand creation of field device editor graphical user interfaces
US8464168B2 (en) Device home page for use in a device type manager providing graphical user interfaces for viewing and specifying field device parameters
US8782539B2 (en) Generic utility supporting on-demand creation of customizable graphical user interfaces for viewing and specifying field device parameters
US20070078540A1 (en) Utility for comparing deployed and archived parameter value sets within a field device editor
EP2010991A2 (fr) Outil d'édition de dispositif de terrain
US8527888B2 (en) Method and supporting configuration user interfaces for streamlining installing replacement field devices
US7836217B2 (en) Associating and evaluating status information for a primary input parameter value from a Profibus device
US7120558B2 (en) Remotely monitoring/diagnosing distributed components of a supervisory process control and manufacturing information application from a central location
EP2645190B1 (fr) Appareil et procédé permettant de déterminer la compatibilité de fonctionnement entre des dispositifs de champ
USRE40817E1 (en) Process control system including automatic sensing and automatic configuration of devices
US7272815B1 (en) Methods and apparatus for control configuration with versioning, security, composite blocks, edit selection, object swapping, formulaic values and other aspects
US7089530B1 (en) Process control configuration system with connection validation and configuration
US6449715B1 (en) Process control configuration system for use with a profibus device network
US6754885B1 (en) Methods and apparatus for controlling object appearance in a process control configuration system
US7096465B1 (en) Process control configuration system with parameterized objects
US20100064297A1 (en) Configuring And Providing Enhanced Access To Profibus Device Diagnostic Data
US7941581B2 (en) Method for integrating device-objects into an object-based management system, or configuration system, for field devices in automation technology, which stores updated device objects, activates a program for accessing the stored date and starting a dialog for invoking a selected number of updated device-objects
US20100222902A1 (en) Methods and apparatus for control configuration with object hierarchy, versioning, inheritance, and other aspects
JP2011040059A (ja) プロセス制御構成方法、プロセス制御構成システム、モジュールテンプレート、及びプロセス制御システム
US20080313629A1 (en) Method for installation of objects for a component-based management system for field devices of automation technology
Zhang et al. Research on EDDL

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200780020744.8

Country of ref document: CN

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

Ref document number: 07760453

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2007760453

Country of ref document: EP