TECHNICAL FIELD

The present invention relates generally to process plants and, more particularly, to the use of flexible objects in configuring and viewing the operation of a process plant or process control system.

DESCRIPTION OF THE RELATED ART

Distributed process control systems, like those used in chemical, petroleum or other process plants, typically include one or more process controllers communicatively coupled to one or more field devices via analog, digital or combined analog/digital buses. The field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process environment and perform process functions such as opening or closing valves, measuring process parameters, etc. Smart field devices, such as the field devices conforming to the well-known Fieldbus protocol may also perform control calculations, alarming functions, and other control functions commonly implemented within the controller. The process controllers, which are also typically located within the plant environment, receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices and execute a controller application that runs, for example, different control modules which make process control decisions, generate control signals based on the received information and coordinate with the control modules or blocks being performed in the field devices, such as HART and FOUNDATION® Fieldbus field devices. The control modules in the controller send the control signals over the communication lines to the field devices to thereby control the operation of the process plant.

Information from the field devices and the controller is usually made available over a data highway to one or more other hardware devices, such as operator workstations, personal computers, data historians, report generators, centralized databases, etc., typically placed in control rooms or other locations away from the harsher plant environment. These hardware devices run applications that may, for example, enable an operator to perform functions with respect to the process, such as changing settings of the process control routine, modifying the operation of the control modules within the controllers or the field devices, viewing the current state of the process, viewing alarms generated by field devices and controllers, simulating the operation of the process for the purpose of training personnel or testing the process control software, keeping and updating a configuration database, etc.

As an example, the DeltaV™ control system, sold by Emerson Process Management, includes multiple applications stored within and executed by different devices located at diverse places within a process plant. A configuration application, which resides in one or more operator workstations, enables users to create or change process control modules and download these process control modules via a data highway to dedicated distributed controllers. Typically, these control modules are made up of communicatively interconnected function blocks, which are objects in an object oriented programming protocol that perform functions within the control scheme based on inputs thereto and that provide outputs to other function blocks within the control scheme. The configuration application may also allow a configuration designer to create or change operator interfaces which are used by a viewing application to display data to an operator and to enable the operator to change settings, such as set points, within the process control routines. Each dedicated controller and, in some cases, one or more field devices, stores and executes a respective controller application that runs the control modules assigned and downloaded thereto to implement actual process control functionality. The viewing applications, which may be executed on one or more operator workstations (or on one or more remote computing devices in communicative connection with the operator workstations and the data highway), receive data from the controller application via the data highway and display this data to process control system designers, operators, or users using the user interfaces, and may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. A data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided across the data highway while a configuration database application may run in a still further computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.

Presently, configuration applications typically include a library of template objects or items, such as function block template objects and, in some cases, control module template objects. These configuration applications are used to configure a control strategy for a process plant and to provide display views at user interfaces of a process plant. The template objects all have default properties, settings and methods associated therewith. The engineer using the configuration application can select these template objects and essentially place copies of the selected template objects into a configuration screen to develop a module, e.g., a control module. During the process of selecting and placing the template objects into the configuration screen, the engineer interconnects the inputs and outputs of these objects and changes their parameters, names, tags and other properties to create a specific control module for a specific use in the process plant. After creating one or more such control modules, the engineer may store the created module in the library or in a configuration data storage area. The engineer can then instantiate the control module (e.g., cause an executable file corresponding to the control module to be created) and download it to the appropriate controller or controllers, field devices, and other process elements for execution during operation of the process plant.

Thereafter, the engineer generally creates one or more displays for operators, maintenance personnel, etc. within the process plant by selecting and building display objects in a display creation application. These displays are typically implemented on a system wide basis in one or more of the workstations and provide preconfigured displays to the operator or maintenance persons regarding the operating state of the control system or the devices within the plant. Typically, these displays take the form of alarming displays that receive and display alarms generated by controllers or devices within the process plant, control displays indicating the operating state of the controllers and other devices being controlled within the process plant, maintenance displays indicating the functioning state of the devices within the process plant, etc. These displays are generally preconfigured to display, in known manners, information or data received from the process control modules, devices, or other process elements within the process plant. In some known systems, displays are created through the use of objects that each have a graphic associated with a physical or logical element, and that are each communicatively tied to the physical or logical element to receive data about the physical or logical element. An object may change the graphic on the display screen based on the received data to illustrate, for example, that a tank is half full, to illustrate the fluid flow measured by a flow sensor, etc.

Similar to the control configuration application, a display creation application may have template graphical display items, such as tanks, valves, sensors, operator control buttons like slide bars, on/off switches, etc. which may be placed on a screen in any desired configuration to create an operator display, maintenance display and the like. Template graphical display items may be stored in a template library along with configuration objects, or may be stored in a different template library. When placed onto the screen, individual graphic items may be interconnected on the screen in a manner that provides some information or display of the inner-workings of the process plant to different users. However, to animate the graphic display, the display creator must manually tie each of the graphical items to data generated within the process plant, such as data measured by sensors or indicative of valve positions, etc. by specifying a communication link between the graphic item and the relevant data source within the process plant. This process is tedious, time consuming and maybe fraught with error. Moreover, once a display is created, it remains static in its configuration and layout.

While the control template objects within the control configuration application and the display items within the display creation application are convenient because they can be copied and used to create many different control modules and graphical displays, there is often a need to create numerous of the same control module and graphical display for different equipment and displays within the process plant. For example, many medium to large sized process plants have numerous instances of the same or similar equipment that can be controlled and viewed using the same basic general control modules and displays.

To address this problem, U.S. Pat. No. 7,043,311 (the entire disclosure of which is hereby expressly incorporated by reference herein) discloses a process plant configuration system that uses class objects also called module class objects (and generally referred to herein as class objects or classes) to enable a user to create numerous control modules, unit or equipment modules, or display modules from a common module class object. These control, equipment or display modules are created as instances of the module class or class object and include all of the features and properties of the module class object, thereby making it easier to create a number of similar control, equipment or display objects from a single or common class module object. Instances may, in turn, have their own children objects, so that objects may have multi-generational or multi-level relationships. Thereafter, each of the instances, children objects, or multi-level children objects created from a module class object may be changed automatically by making and storing changes to its respective parent object. For example, module instances retain their connection to the module class object and are updated automatically when the class module is changed or updated. Similarly, children objects and multi-level children objects created from a parent object that is not a class object may be changed automatically by making and storing changes to the parent object. In an embodiment, at least some of the children objects are stored in a system configuration data storage area or other data storage area which is logically and/or physically separate from the library.

However, in a typical control system used in, for example, a process plant, there can be hundreds of similar items (such as control modules or display elements) that must be defined. These items include control strategies associated with the control of flow or pressure, for example, as well as the display components used to represent these control strategies in graphic displays. It is now fairly typical to implement a configuration system that use classes or module class objects to configure these common items, wherein the configuration system includes a library of module class objects, and enables a user to produce many copies or instances of any particular module class object for use in the plant. In these systems, modifications to the objects must be made to the module class object first, which then causes these changes to be automatically propagated to all of the instances, children objects, and multi-level children objects (if any) of the module class object. In fact, these configuration systems are designed to allow only small adjustments to be made directly on the module instances, such as changing parameter values in the module instances. For example, typical class behavior for control strategies enables an instance of a class item to be modified only on the parameter level, and only if that specific parameter has been granted change access from within the module class. As a result, many different module class objects must be developed to configure process plant items (such as plant equipment) that only differ from each other by small or minor amounts. Unfortunately, as more and more of these module class objects are defined, the original productivity gains obtained by using configuration class objects decrease.

Still further, as noted above, current configuration systems that use class based configuration items are typically designed to assure that, when a change is made to a class item, that change is immediately propagated to all of the module instances of that class. This feature is designed into the configuration system because instances actually share, or point to, their respective parent items or objects (e.g., the class item or object) for their definitions. Although this automatic change propagation feature makes control system design easier and more effective in the early stages of the design, once the control system is installed and running in a plant, it may not be acceptable or practical to change all of the instances associated with a particular module class object at the same time. Importantly, a given module class object typically experiences many changes as part of its lifetime. After a module class object has been created, subsequent changes to the module class (which may be structural changes or parameter value changes) result in a modified module class whose changes need to be distributed to module instances, to one or more children objects, and/or to other module classes such as derived module classes. However, as a practical matter, each affected child object running in the plant may need to be individually tested and verified on actual process equipment, and thus the user may need to delay the change to the module class object for months or years waiting for an appropriate time to update all of the module instances for that class object. Moreover, because changes to a module class object are automatically distributed to derived objects, a single change to a module class could affect hundreds and possibly thousands of module instances and children objects. Many process industries cannot deal with the resulting disruptive downloads required, spanning multiple areas of the plant, during the plant operations phase. As a result, control systems are being initially engineered with module instances tied to a module class object, only for these instances to be eventually converted into classless control modules before the system enters the plant operations phase.

For the various reasons described above, class instances are in many cases being broken off of or are being disassociated from the original class object to allow changes to be made to the class instance, which thereby creates a new class module or which allows changes to be made to the class object without being propagated to all of the instances immediately. However, this operation destroys the advantages of using class based configuration objects in the first place.

Even in smaller systems in which class/instance connections are not being severed, it is still difficult to define and debug a new change to a control object without affecting all of the instances in the class because, on the one hand, it is not possible to implement new changes on an instance, and because, on the other hand, when any change is made to the class object, this change is automatically applied to each instance of the class object. Here again, one of the children objects, e.g., an instance, must be temporarily broken off from the class object so that the new change can be designed and tested on the instance. In this case, the change, once complete, must be manually made on the class object and the user must clean up the instance used for testing and re-attach the instance to its proper class object. Thus, in effect, to deal with these issues, the user must create an entire separate class object to handle slight variations between instances by breaking more and more classes off from the original class object for testing purposes, or must abandon the class concept completely.

Still further, most configuration systems used in the market today do not use classes to configure graphic displays for the control system. Typically, the graphics are defined separately from the control strategies, and one graphics item is often used with multiple different control strategy classes. Thus, when a change is made to a particular graphics item, the user must verify that the changed graphics item works with all of the control strategy instances, on all of the displays. As modifications to control strategies occur and the control strategy classes proliferate in the manners noted above, each graphics item for each instance needs to be verified, which becomes time consuming and impractical.

While graphics utilities can be used to update similar graphics items, the utility would make all of the selected graphics items identical. Thus, in the end, this solution is similar to using classes for graphics items. Moreover, designing instance differences in graphics is difficult and requires programming skills. Because a wide variety of variations are allowed and in fact are expected in graphics items, it is necessary to design a system, using special forms, that specifies which variations are to be allowed or enabled with override structures in each of the graphics display item created from a common graphics object. These variations include, for example, specifying changes such as allowing the user on an instance to define the rotation for part of the item, select what strings and variables must be shown in the display and which ones are optional, etc. Without this up front design, the graphic objects cannot even have small changes made thereto. Unfortunately, a configuration system which attempts to design or pre-specify the allowable changes in the graphics items quickly becomes unusable, as variations on graphics items is very common. As a result, maintaining graphics cost effectively is an ongoing problem within control systems, and is only exacerbated when the step of maintaining graphics must be coordinated with the changes being made to control module classes used in the control configuration system.

In a more general sense, users want to configure a display out of reusable graphical components and be able to see the changes they made from the original graphical definition. Additionally, they want to be able to make changes to the definition in one place and have these changes applied to the displays for which the graphical definition is used, and thereafter maintain the specific changes they made on the various displays. Currently, in some display systems, display components can be grouped into dynamos, which are a combination of basic shapes, such as rectangles and text blocks configured with the animations and event handler behaviors. These basic shapes can be configured into various combinations to represent equipment or data from part of the plant. Some dynamos are typically provided out of the box as part of the display configuration system, while other dynamos are created and maintained by project engineering, and still other dynamos are configured by the customer. Currently, when these dynamos are used on a display, a complete copy is placed in the display for each instance that uses the original dynamo. However, there is no hard link back to the original dynamo. However, each instance may change several aspects of the dynamo, such as the animation expression paths, position orientation or other visual aspects required to allow this particular display to fit within the current display field of the user interface on which the display element is used.

There are several problems and limitations to this approach. Generally speaking, the customer is trying to minimize the financial cost and is trying to maximize quality and reliability of the displays. However, invariably, one or more changes are needed to a dynamo definition. After a change is made to a master or original dynamo, the customer needs to put those changes into production by updating all the displays that use that specific dynamo. However, because there is no hard link between the original dynamo being changed and its copies, determining where the dynamo is used is a serious issue. Typically, each created dynamo includes a string field to store the dynamo name and version. However, not all customers use this technique and, in any event, this field can be inadvertently cleared or deleted by a user during an edit session, thereby losing the named connection back to the original dynamo. Moreover, if a new dynamo is created from an existing dynamo and this reference value is not updated, the string will have the incorrect reference to the original dynamo name and version. Further, if a difference was a change on the display or to the dynamo, it is only possible to know what is different in the dynamo, but not why. Thus, it is difficult for users to determine if a change needs to be incorporated into a particular dynamo being used in a particular display when changes are made to the original dynamo.

Still further, while the user can update the instance to the new dynamo and retain the instance specific changes, the user typically does not know which changes are in the new master and which are instance specific, and so cannot determine which differences within the display item should be left in place. Currently, updating to a new version of a dynamo requires a complete recopy of the dynamo to replace the values configured on the display. This process overwrites any changes on the display item that are instance specific. As a result, the user must then manually reapply all changes previously made to the display item or instance, and if the user forgets some of the changes, these changes are lost. This operation negatively affects the quality of the operator displays and also takes longer because it entails a manual process. Still further, the original dynamo levels are only one level deep. As a result, a dynamo can only be built from the basic shapes and not from other dynamos, which prevents building up a set of dynamos to be used as the basis for other dynamos.

SUMMARY

A configuration system uses a simplified configuration pane or form to configure properties of attributes of a graphic element, such as the graphic element's shape, dynamic behaviors, etc. The simplified configuration panes are provided as objects, which can be configured, published and reference other objects, such as a graphic element object, instead of using scripts. Thus, a configuration element may be configured to include properties that are most commonly used for a particular graphic element, rather than exposing all possible properties in the configuration system, which may number in the thousands. For example, a graphic element object for a valve may have a particular shape and designation. Common properties for such a graphic element includes fill color for the shape, line thickness for the shape, font, font size and dynamic behaviors. A configuration element for the valve graphic element may be configured to include a set of options for fill color, line thickness, font, font size and dynamic behaviors. When the configuration element is instantiated, a user is presented with the set of options to configure the properties for the valve graphic element. The graphic element object is linked and bound to the configuration element object such that upon instantiation, the graphic element is displayed with the properties defined in the configuration element object. Subsequent changes to the configuration element object would then propagate to the graphic element objects that are linked to the configuration element object.

