Derived and linked definitions with override

The present invention relates generally to process plants, and more particularly to the use of flexible objects in configuring and representing the operation of process plants or process control systems.

CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 61/711,110, entitled "Process Plant Configurations Using Flexible Objects," filed October 8, 2012, the entirety of which is incorporated herein by reference. The contents are incorporated herein by reference. In addition, this application claims the benefit of U.S. Provisional Patent Application Serial No. 61/711,105, entitled "Configurable User Displays in a Process Control System," filed October 8, 2012, the entire contents of which is incorporated herein by reference.

Further, this application is related to United States Patent Application Serial No. __________, entitled "Method and Apparatus for Managing Process Control Configuration," filed concurrently herewith, the entire contents of which are incorporated herein by reference. This application is also related to US Patent Application No. __________, entitled "Derived and Linked Definitions with Override," filed concurrently herewith, the entire contents of which are hereby incorporated by reference. In addition, this application is related to US Patent Application Serial No. __________, entitled "Dynamically Reusable Classes," filed concurrently herewith, the entire contents of which are hereby incorporated by reference.

Distributed process control systems, such as those used in chemical, petroleum, or other process plants, typically communicate to one or more field devices via analog, digital, or combined analog/digital buses. It includes one or more process controllers communicatively coupled. Field devices, which can be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level, and flow rate sensors), are located within the process environment to open and close valves, measure process parameters, and perform process functions such as Smart field devices, such as field devices conforming to the well-known Fieldbus protocol, may also perform control calculations, alarm functions, and other control functions typically implemented in controllers. A process controller, also typically located within the plant environment, receives signals indicative of process measurements made by the field devices and/or other information related to the field devices and, for example, directs different control modules to make process control decisions. It executes the operating controller application, generates control signals based on the information received, and interfaces with control modules or blocks implemented in field devices such as HART and FOUNDATION® Fieldbus field devices. A control module of the controller sends control signals over the communication lines to the field devices, thereby controlling operation of the process plant.

Information from field devices and controllers travels through the data highway to operator workstations, personal computers, data historians, report generators, centralized databases, which are typically located in the control room or other location, usually away from the harsh plant environment. provided to one or more other hardware devices such as These hardware devices can, for example, change the settings of process control routines, modify the operation of control modules within the controller or field device, display the current state of the process, and allow operators to perform functions related to the process, such as displaying triggered alarms, simulating process operation for purposes of training personnel or testing process control software, maintaining and updating configuration databases, etc. Run the application to get

As an example, Emerson Process The DeltaV control system sold by Management includes multiple applications stored in and executed by different devices located at various locations within the process plant. A configuration application residing on one or more operator workstations allows users to create or modify process control modules and download these process control modules to dedicated distributed controllers via the data highway. Typically, these control modules are objects of an object-oriented programming protocol that perform functions based on inputs thereto within the control scheme and provide outputs to other function blocks within the control scheme. Consists of interconnecting function blocks. The configuration application allows the configuration designer to create or modify the operator interface used by the display application to display data to the operator and allow the operator to change settings such as setpoints within the process control routine. can be Each dedicated controller, and in some cases one or more field devices, stores a respective controller application that operates control modules that are assigned and downloaded thereto to implement the actual process control functionality. and execute. A display application, which may run on one or more operator workstations (or one or more remote computing devices in communication with the operator workstation and the data highway) receives data from the controller application over the data highway, A user interface may be used to display this data to a process control system designer, operator, or user, providing any of a number of different views, such as an operator view, an engineer view, a technician view, and the like. A configuration database application provides the current process control routine configuration and While the data historian application may be executed on a further computer attached to the data highway to store data associated with them, the data historian application typically manages some of the data provided throughout the data highway. or stored in and executed by a data historian device that collects and stores all. Alternatively, the configuration database can be located on the same workstation as the configuration application.

Currently, 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 control strategies for the process plant and to provide display presentations at the process plant's user interface. All template objects have default properties, settings, and methods associated with them. An engineer using the configuration application can select these template objects and, in essence, place a copy of the selected template objects in the configuration screen to develop a module, such as a control module. During the process of selecting template objects and placing them in configuration screens, the engineer interconnects the inputs and outputs of these objects and modifies their parameters, names, tags, and other properties for specific use in the process plant. Create a unique control module for After creating one or more such control modules, the engineer may store the created modules in a library or configuration data storage area. The engineer can then instantiate the control module (e.g., have an executable file corresponding to the control module created) and attach it to the appropriate controller or controller(s) for operational execution of the process plant. ), field devices, and other process elements.

Engineers then typically create 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 at one or more of the workstations to provide operators or maintenance personnel with pre-configured displays regarding the operational status of control systems or devices within the plant. do. Typically, these displays include alarm displays that receive and display alarms generated by controllers or devices within the process plant, control displays that indicate the operational status of controllers and other devices being controlled within the process plant, It takes the form of a maintenance display, etc., which indicates the functional status of the devices in the process plant. These displays are generally preconfigured to display information or data received from process control modules, devices, or other process elements within the process plant, in a known manner. In some known systems, the display has a graphic associated with each physical or logical element, each associated with the physical or logical element to receive data about the physical or logical element. created through the use of objects that are communicatively coupled to The object can change the graphics on the display screen based on the data received, for example, to show that the tank is half full, to show the liquid flow rate as measured by the flow sensor, and so on.

Similar to the control configuration application, the display creation application can be placed on the screen in any desired configuration to create operator displays, maintenance displays, etc. Operator control buttons such as tanks, valves, sensors, slide bars, on/off It may have template graphical display items such as switches. Template graphical display items may be stored in a template library along with the configuration object or may be stored in a different template library. When placed on a screen, individual graphic items can be interconnected on the screen in a manner that provides different users with some information or display of the internal workings of the process plant. However, to animate a graphic display, the display creator specifies the communication link between the graphic item and the relevant data source in the process plant so that each graphical item can be measured by a sensor. It must be manually combined with data generated within the process plant, such as data that was generated or data that indicates valve positions. This process can be tedious, time consuming and error prone. Furthermore, once a display is created, it remains static in its configuration and layout.

Control template objects in the control configuration application and display items in the display creation application are convenient because they can be copied and used to create many different control modules and graphical displays, but often A need exists to create multiple identical control modules and graphical displays for different equipment and displays within a process plant. For example, many medium to large sized process plants have multiple instances of the same or similar equipment that can be controlled and displayed using the same basic common control module and display.

To address this problem, U.S. Pat. No. 7,043,311 (the entire disclosure of which is expressly incorporated herein by reference) describes a class object, also called a module class object (and generally referred to herein as A process plant configuration system using class objects or called classes) is disclosed that allows a user to create multiple control modules, unit or equipment modules, or display modules from a common module class object. These control, instrument, or display modules are created as instances of module classes or class objects, and include all of the features and properties of module class objects, thereby allowing many similar controls from a single or common class module object. Make it easier to create , equipment, or display objects. Instances can then have child objects of their own, and thus objects can have multiple generations or multiple levels of relationships. Thereafter, each of the instances, child objects, or multi-level child objects created from the module class object can be automatically modified by making and storing the changes to their respective parent objects. For example, module instances keep a connection to their module class object and are automatically updated when the class module is changed or updated. Similarly, child objects and multi-level child objects created from a parent object that is not a class object can be automatically changed by making and storing changes to the parent object. In one embodiment, at least some of the child objects are stored in a system configuration data storage area or other data storage area that is logically and/or physically separate from the library.

However, in a typical control system used, for example, in a process plant, there may be hundreds of similar items (such as control modules or display elements) that must be defined. These items include, for example, control strategies associated with controlling flow or pressure, as well as display components used to represent these control strategies in graphical displays. It is now quite typical to implement a configuration system that uses classes or modular class objects to configure these common items, the configuration system containing a library of modular class objects that the user can configure for use in the plant. to create multiple copies or instances of any particular module class object. In these systems, modifications to an object must first be made to the module class object, then to all instances of the module class object, child objects, and multi-level child objects (if any) to modify these objects. Automatically propagate changes. In fact, these configuration systems are designed so that only minor adjustments, such as changing the parameter values of a module instance, can be made directly to the module instance. For example, a typical class behavior for a control strategy allows instances of class items to be modified only at the parameter level, if that particular parameter is granted modify access from within the module class. only allow it. Consequently, many different module class objects must be developed to compose process plant items (such as plant equipment) that differ from each other by only a small or small amount. Unfortunately, as more and more of these module class objects are defined, the original productivity gains gained by using configuration class objects diminish.

Still further, as noted above, current configuration systems using class-type configuration items typically require that when a change is made to a class item, the change is immediately propagated to all module instances of that class. designed to ensure that This feature is designed into the composition system because instances actually share or point to their respective parent items or objects (eg, class items or objects) for their definition. This automatic change propagation feature makes control system design easier and more efficient in the early stages of design, but once the control system is installed and operational in the plant, the instances associated with a particular module class object. It may not be acceptable or practical to change all at once. Importantly, a module class object typically undergoes many changes as part of its life. After a module class object has been created, subsequent changes to the module class (which may be structural changes or parameter value changes) may cause changes to other objects such as the module instance, one or more child objects, and/or derived module classes. result in a modified module class that needs to be distributed among the module classes of In practice, however, each affected child object to be put into operation in the plant may need to be individually tested and validated on actual process equipment, so users can make changes to module class objects Waiting for the appropriate amount of time to update all module instances for that class object may require a delay of months or years. Furthermore, because changes to module class objects are automatically distributed to derived objects, a single change to a module class can affect hundreds and potentially thousands of module instances and child objects. Many process industries spread out across multiple areas of the plant during the plant operating phase. cannot handle the destructive downloads required as a result. As a result, control systems are initially designed with module instances bound to module class objects, and only these instances are ultimately converted to classless control modules before the system enters the plant operation phase. be done.

For various reasons explained above, class instances are often detached or disassociated from the original class object, allowing changes to be made to the class instance, thereby creating a new class Create modules or allow changes to be made to class objects without being propagated to all of the instances immediately. However, this behavior destroys the original benefits of using class-type configuration objects.

Even in smaller systems where the class/instance connection is not broken, it is still difficult to define and debug new changes to control objects without affecting all instances of the class, which on the one hand , because it is not possible to implement a new change to an instance, and on the other hand, when any change is made to a class object, this change is automatically applied to each instance of the class object. Here again, one of the child objects, eg an instance, must be temporarily detached from the class object so that new changes can be designed and tested against the instance. In this case, once the change is complete, it must be manually made to the class object and the user must clean up the instance used for testing and reattach the instance to its proper class object. There is a need to. So, in practice, in addressing these challenges, users would prefer to create all separate class objects to handle small variations between instances by moving more classes away from the original class object for testing purposes. , or abandon the concept of classes entirely.

Still further, most configuration systems used in the market today do not use classes to configure graphic displays for control systems. Typically, graphics are defined separately from control strategies, and one graphic item is often used with multiple different control strategy classes. Therefore, when changes are made to a particular graphical item, the user needs to verify that the altered graphical item works with all control strategy instances on all displays. As modifications to control strategies occur and control strategy classes proliferate in the manner noted above, each graphical item for each instance needs to be verified, which can be time consuming and non-intrusive. Practical.

A graphic utility can be used to update similar graphic items, but the utility will make all selected graphic items identical. So, finally, this solution is similar to using classes for graphic items. Furthermore, designing instance differences in graphics is difficult and requires programming skills. Since a wide variety of variations are possible, and indeed expected in graphic items, specific forms are used to determine which variations are allowed or allowed in overriding structures in each of the graphic display items created from a common graphic object. It is necessary to design a system that specifies These variations specify changes such as, for example, on an instance the user can define a rotation for a portion of an item, select which strings and variables should be shown on the display, which are optional, etc. including doing Without this forward-looking design, a graphical object cannot have even small changes made to it. Unfortunately, configuration systems that attempt to design or pre-specify permissible changes in graphic items quickly become unusable because variations in graphic items are so common. As a result, maintaining graphics costs efficiently is an ongoing problem within control systems, and the steps to maintain graphics must be coordinated with changes made to the control module classes used in the control configuration system. increased only when necessary.

In a more general sense, users want to compose displays from reusable graphical components and be able to see the changes they have made from the original graphical definition. In addition, they can make changes to the definitions in one place and apply these changes to the displays where the graphical definitions are used, then maintain the specific changes they made on the various displays. I hope you can. Currently, in some display systems, display components can be grouped into dynamos, which are combinations of primitive shapes such as rectangles and text blocks configured with animation and event handler behaviors. These primitives can be configured in various combinations to represent equipment or data from parts of the plant. Some dynamos are typically provided out-of-the-box as part of the display configuration system, while others are generated and maintained by project engineering, while still others are configured by the customer. be. Currently, when these dynamos are used for display, an exact copy is placed on the display for each instance of using the original dynamo. However, there is no hard link back to the original dynamo. However, each instance may have different animation representation paths, position orientations, or other visual aspects required to allow this particular display to fit within the current display field on the user interface in which the display elements are used. It is possible to change some aspects of the dynamo such as.

There are several problems and limitations with this approach. Generally speaking, customers seek to minimize financial costs and maximize display quality and reliability. However, invariably one or more changes are required to the dynamo definition. After changes are made to the master or original dynamo, the customer must actually make those changes by updating all displays that use that specified dynamo. However, determining where a dynamo is used is a significant challenge because there is no hard link between the modified original dynamo and its copy. Typically, each generated dynamo contains a string field that stores the dynamo name and version. However, not all customers use this technique and in any case this field can be inadvertently cleared or deleted by the user during an editing session, thereby returning the name to the original dynamo. lose attached connection. Furthermore, if a new dynamo is created from an existing dynamo and this reference value is not updated, the string will have an incorrect reference to the original dynamo name and version. Furthermore, if the difference was a change to the display or dynamo, it is only possible to know what the difference is in the dynamo, but it is unclear why. Therefore, when changes are made to the original dynamo, it is difficult for the user to determine if the changes should be incorporated into the particular dynamo being used in a particular display.

Still further, while a user can update an instance to a new dynamo and retain this instance-specific changes, the user typically does not know which changes are in the new master and which are instance-specific. , and thus cannot determine which differences in the display items should be left as is. Currently, updating to a new version of the dynamo requires a full recopy of the dynamo to replace the configured values for the display. This process overwrites any changes to display items that are instance specific. Consequently, 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 will be Lost. This operation negatively impacts the quality of the operator display and also takes longer as it involves a manual process. Still further, the original dynamo level is only one level deep. Consequently, dynamos can only be built from primitive shapes, not from other dynamos, which prevents building a set of dynamos that are used as references for other dynamos.

The configuration system uses flexible or modifiable object (e.g., module class objects, module instance objects, and child objects) technology to enable class-based configurations to develop new control strategies or display elements and to Making changes to these elements both more useful and beneficial when they are in operation or running in a plant environment. Such configuration systems are referred to interchangeably herein as "flexible configuration systems" or "configuration systems." In particular, the use of new flexible objects reduces the proliferation of class objects by allowing more variation among the instances created from class objects, allowing a single class object to be used in a wide variety of applications. be applicable to A configuration system with new flexible objects allows users to add items to e.g. a classed type instance (or other child object) according to their specific needs, but allows the user to modify the changes to other instances. in a manner that does not force an instance or child object to be removed or disassociated from a class unless it is desired to do so on the parent object itself, and in a manner that does not affect other instances of the same class can be added with Similarly, items added to an instance or child object may be flagged in the instance or child object so as not to interfere with anything added to the parent level and for clear documentation purposes. , and can be labeled. Still further, the composition system with the new flexible objects supports invalidating parent content at the child level and/or deleting parent content at the child level. Disabling or removing parent content at the child level, for example, allows core class functionality to remain part of the class while allowing users to better navigate instances where users need to have less functionality than the rest of the class instance. to process and If desired, any disabled content at the child level can be visually turned off or made invisible in the configuration utility that enables viewing of the child, and can be re-enabled at any time by the user. Disabled content is not used at runtime, but exists only in the configuration environment. If the user determines that the child object contains previously invalidated parts of the parent object, then that child object can be flagged for download to update the runtime version of the control system.

In addition, a configuration system using flexible objects makes classes more available in a running plant by allowing changes or updates to be distributed incrementally to instances and child objects. For example, a user or configuration engineer can optionally: Class changes can be propagated downward to instances, which results in improved plant performance and better runtime support instead of forcing all class changes to be propagated to all instances of the class at the same time. This tiered feature allows users to make class changes and propagate the changes only to those instances that require the change. The user may then return later to propagate changes to more instances or the rest of the instances. More specifically, this tiered feature helps determine which instances are there based on current plant operational considerations, instead of having to manually manage downloads or perform automatic downloads to all instances at the same time. allows users to determine if they can have configuration updates downloaded to the .

As another feature, the configuration system using flexible objects enhances the user's ability to incrementally make and verify changes by selectively propagating instance changes back up to class objects. For example, the configuration system allows a user to propagate changes made on an instance upwards to the return class object for distribution to the rest of the downwards return instance. This feature provides the user with a built-in testing environment that allows the user to modify and test one instance of the class object before rolling out the modification to all other instances of the class object.

As will be understood, a configuration system described herein may be a controller, device, display, or other device within a process plant or process control system, such as, for example, within the run-time operating environment of the process plant or system. While providing a mechanism that allows users to control the rollout of changes from module classes and other parent objects to module instances and other child objects operating in process elements of retain their sexuality. Accordingly, the configuration system described herein provides control over time such that real-time operation in a portion of a process plant or process control system (or in some cases, the entire plant or system) is not adversely affected. Module classes and others that are integrated into process elements (corresponding to parent objects and their respective child objects) of a process plant or process control system to modify plant or system operation and/or behavior in a structured step-by-step manner. allow changes to the parent object of the . In some situations, changes to parent objects are not propagated to child objects. In addition, changes can be made to the process plant or system in a controlled manner (instead of waiting until a suitable time for all process elements corresponding to child objects of the changed parent object to be updated). The occurrence of unnecessary delays in applying changes to portions of a process plant or process control system (or, in some cases, the entire plant or system) is reduced because they can be applied additively to process elements. , thus, over time, increasing the overall efficiency and productivity of the process plant or system.

Additionally, the techniques, systems, and methods described herein allow users to securely handle temporary copies of parent or child objects, and only when proper authorization has been received, to control, device, or Allows you to prepare a parent or child object for deployment (download) to other process elements. Approving a draft of a modification or change to be applied or instantiated in a process element of the run-time environment of a process plant or control system (either from a modified parent object or from a modified child object) is therefore pending. Reduces the chances of a complete or incorrect modification or change being inadvertently incorporated into a plant or system. That is, by using the draft and approved techniques described herein, the configuration system improves the accuracy of changes integrated into the process plant or system, thereby improving the quality of operation of the process plant or system. Improve.

In some cases, the composition system may implement phased execution by using an editorial and distribution mechanism that may be loosely based on the book publishing model in which users work on final approved drafts, and within the plant. Bringing editions distributed to locations. For some controllers, displays, or other plant assets, it is best to incorporate or use the latest edition whenever it is released, while others are incorporated or upgraded to new editions. or do so only when it is convenient. Still further, using this system, users can make changes to configuration libraries and system configuration items without triggering a download and potentially impacting the runtime system. Users can save changes to items or objects as drafts and create editions that can be distributed and downloaded to the runtime system once the changes are approved. More specifically, in the configuration system, module instances (and other child objects) are linked to a specified edition of the module class or parent object, which allows the module class or parent object to add additional editions without immediately affecting its children. Allows you to go through changes (editions). Thus, in an exemplary embodiment, this feature eliminates the need to download the module instance each time a change is made to the module class, but instead allows the user to ensure that the module instance links to the latest edition of the module class. so that you can control when it is updated. Naturally, a child object links to the specified edition of its parent object, whether the parent object is a library item or not, so that the parent object can be changed or modified without immediately affecting all of its child objects. enable

Thus, using the configuration system step-by-step techniques described herein, a user can either have changes to a library item or parent object automatically distributed to child objects, or the user can You can choose to manage manually. Additionally, parent libraries and system configuration items can go through multiple stages: draft, edition, and download edition (for system configuration items). Here, the user can create a temporary copy (draft) of the parent object and download the modified edition of the item to the run-time system only with proper approval, which means that the draft item is , means that it can be tested without affecting the system in production. Similarly, to enhance the user's experience and make the user feel more in control, the user can see the draft, the difference between the current edition and the downloaded edition. In relation to the specified item, the user can choose to see the differences between the draft and the current edition, between the draft and the downloaded edition, between the current edition and the downloaded edition, and so on. Additionally, Libraries and System Configuration Items can support references, in which case see which System Configuration Items use the Library Item and whether the System Configuration Item uses the latest edition of the Library Item. Is possible.

Still further, the use of editions within module class and instance structures creates packages that are essentially editioned collections of specified parent item editions, and simultaneously distributes these packages for download. enable This feature allows a library package to be designed for the specific solution or problem being designed, and from which most, if not all, of the required plant configurations can be created. Later, when the package is updated to correct problems or improve functionality, new editions of the package can be installed by simultaneously installing new editions of the library items included with the package. Users are then free to update the system configuration as their plant situation permits, which occurred in the current configuration system where updates to a parent item must be used immediately to update its child items. Eliminate or reduce logistical issues. As an example, the configuration system described herein manages libraries and system configuration items including engineering units, alarm settings, and global values, security objects (such as user accounts, function and parameter security, and authorization policies). and may also be applied to user-generated documents such as standard operating procedures (SOPs), start/end procedures, alarm aids, and the like.

In relation to display items, the configuration system's flexible objects are linked graphical configurable shapes (e.g., Graphical Element Modules or GEMs), which provide one or more visual representations or representations of configurable shapes. ii) is stored separately from the usage/instance of that GEM in a given display and other objects In addition, flexible objects in the configuration system define graphical definitions from other graphical definitions (e.g. displays and GEMs) For example, a GEM may be constructed using other GEMs.

Typically, overwriting, changing, or modifying a parent object results in corresponding changes to instances or child objects. The configuration system's flexible objects extend this overriding concept to allow changes to the internal structure of display items, using simple parameter overrides backed by control strategy function blocks. These additional overrides can be, for example, overrides to properties, animations and event handlers, overrides that favor adding graphical shapes, animations or event handlers, overrides that favor moving graphical shapes, and/or remove or Overrides that support graphical shapes, animations or event handlers may be included. Overrides for a given display instance can be stored with the instance separately from the GEM definition, so knowing which changes are specific to the display instance or have been made in the GEM definition used in the display instance. It is possible to know the changes. Thus, overwriting GEMs and other display objects (whether parent or child) can include modifications and changes to the content of GEMs and other display objects.

Additionally, when loading a display, the GEM definition can be used to determine the initial representation, animation, and event handling behavior of display items. Overrides can then be applied to the specified display instance of the display item or class object to provide instance-specific changes, as needed. This feature can be used to change a shape's orientation or position, or remove a shape, or remove a text block that shows the value in text form and add a rectangle that graphically shows the value as a fill percentage. It can be implemented using simple property overrides to replace a shape with another shape. Alternatively, an override can add or modify an existing animation or event handler by overwriting one or more of the properties of the existing animation or event handler. Modified and overridden GEMs of one embodiment may be stored or maintained as child objects of the GEM definition.

Additionally, the display configuration system allows GEMs to be built on top of other GEMs, allowing generic items to be easily created for specific functions, industry groups, or customers. In one embodiment, a GEM can be unfolded by derivation, in which case the same overriding structure can be applied in the derived GEM, whereby display items are unbundled as new display class objects in the library or at runtime. , can be spread out as an instance opened by the operator. The display configuration system may also include mechanisms by which the user can easily determine all of the instances of the GEM (if used) and which displays are derived from other displays. Similarly, the display configuration system allows the user to deterministically determine what has been modified on the derived definition or usage, the composite shape (e.g. , GEM), adding and removing shapes, adding and removing data (animations), adding and removing event handlers, and shapes, animations, and event handlers , and a mechanism that allows overriding properties of any other object type in the GEM definition.

Still further, the display configuration system allows users to update definitions or derived definitions (display class items) to new versions and apply these changes to instances without losing instance overrides. may include a mechanism for The display configuration system also allows users to create GEMs by combining other GEM definitions, derive displays from other displays, derive GEMs from other GEMs, and create display instances. Contains a mechanism that allows you to indicate tweaks and overrides.

The flexible configuration of graphical elements and displays provided by the display configuration system allows a process plant or process control system to be monitored, controlled and/or operated in real time more safely and efficiently. In particular, the display configuration system enables operators to specifically monitor, control and/or operate one or more portions of a process control system or plant, both in the real-time or run-time operating and configuration environment of the plant. Allows configuration of adapted or customized graphical elements and/or displays. The graphical elements and/or displays may additionally or alternatively be specifically adapted or customized for a particular operator, group of operators, organizational entity, business, or other entity. The display configuration system also includes customized graphical elements and/or customized displays for operator general (e.g., plant-wide or system-wide, real-time or configuration environments) access, use, reuse, and integration. allows you to save Therefore, operator confusion and error is reduced because the configuration of the graphical element(s) and/or graphical display(s) is streamlined and fully customizable in multiple environments of a process plant or system, thereby reducing operator to operate the process plant or system efficiently and safely.

Further, the graphical element(s) and/or display(s) are customized for the specific purposes of a specific part or entity of a process plant or system (e.g., control one or more processes). Real-time data generated by a unique part or entity of a process plant or system and requiring necessary manual and/or automatic intervention may include customized graphical element(s) and/or display(s). easily and rapidly identifiable with In one embodiment, real-time data is received and identified at the customized graphical element and/or display, and updated control algorithms are manually and/or automatically generated based on the content of the identified data. and sent to the process plant for execution. In other embodiments, based on the content of the received and identified data, recovery action instructions are manually and/or automatically sent to one or more process elements of the process plant or system being implemented; and /or Termination or initialization instructions are sent to one or more process elements of the process plant or system being implemented. Of course, other data, configurations, and/or instructions may be transmitted to and/or executed by the process plant or system based on the real-time data received and identified. In some cases, data, configurations, and/or instructions delivered to the process plant or system based on the identified real-time data result in changes to the process plant or system (e.g., updated or new configurations) or introduce changes in their behavior. In some cases, the delivered data, configuration, and/or instructions cause the process plant or control system to perform actions (e.g., remove certain process elements from operation,

Accordingly, the display configuration system enables the graphical elements and/or displays to generate more customized and detailed information (and particularly in relation to real-time data generated by the process plant or system), Any necessary modifications to the control and/or operation of one or more portions of the process plant or process control system are more rapidly determined and integrated into the run-time environment of the process plant or control system. Thus, using the techniques, methods, and systems described herein, the efficiency and safety of process plants or systems are further improved.

<figref num="1">An illustrative distributed process control located within a process plant or process control system, including workstations that implement configuration applications that use module class objects to configure control and display activities for the process plant or process control system 1 is a block diagram of a network; FIG.</figref><figref num="2">Figure 2 is a diagram of the reactor unit of Figure 1;</figref><figref num="3">3 is a diagram of an aggregation equipment entity used in the reactor unit of FIG. 2; FIG.</figref><figref num="4">FIG. 3 is a diagram of the outlet valve system used in the reactor unit of FIG. 2;</figref><figref num="5">FIG. 4 is an example logic diagram showing the interrelationships between a module class object and associated module objects for the unit, equipment, control, and display types of the module class object.</figref><figref num="6">2 is a logical diagram of an example reactor unit module class object that may be used to perform configuration activities for the reactors in the plant of FIG. 1; FIG.</figref><figref num="7">FIG. 4 is a depiction of an example configuration screen that may be used by a configuration operator to configure a process plant using module class objects;</figref><figref num="8">2 is a block diagram of an example scenario in which a user modifies a module object stored in the library of the process control system of FIG. 1; FIG.</figref><figref num="9">2 is a block diagram of a second example scenario in which a user modifies a module object stored in the library of the process control system of FIG. 1; FIG.</figref><figref num="10">FIG. 10 is a block diagram of the second example scenario of FIG. 9 including additional actions;</figref><figref num="11">3 is a block diagram of a third example scenario in which a user modifies a module object stored in the system configuration data storage area of the process control system of FIG. 1; FIG.</figref><figref num="12">FIG. 4 shows three possible representations of an example valve graphical element;</figref><figref num="13">FIG. 4 shows a diagram of an example defined usage pattern;</figref><figref num="14">FIG. 10 shows a class diagram for an example nested defined usage pattern;</figref><figref num="15">FIG. 10 is a diagram showing an illustration of abstracted nested state definition usage;</figref><figref num="16">FIG. 11 shows a diagram of an example derived pattern;</figref><figref num="17">FIG. 11 shows a diagram of an example of a nested derived pattern;</figref><figref num="18">FIG. 10 is a diagram showing an example of shape usage created based on the definition;</figref><figref num="19">FIG. 10 is an illustration of a field value override refinement applied to a usage pattern;</figref><figref num="20">FIG. 10 is an illustration of a field value override refinement applied to a derived pattern;</figref><figref num="21">FIG. 4 is an illustration of multiple modifications or tweaks to an object at multiple levels;</figref>

Referring now to FIG. 1, a process plant 10 includes one or more process controllers 12 coupled to multiple workstations 14 via, for example, Ethernet connections or buses 15 . The controller 12 is also coupled to devices or equipment within the process plant 10 via a set of communication lines or buses 18, only the set of communication lines 18 being connected to the controller 12a illustrated in FIG. Communication line or bus 18 may be, for example, a wired connection, a wireless connection, or a combination of wired and wireless connections. Fisher-Rosemount as an example only Controller 12, which may be implemented with a DeltaV controller sold by Systems, Inc., implements one or more process control routines 19, thereby controlling process plant 10 or one or more processes of process plant 10. Control elements such as field devices and function blocks within field devices distributed throughout the process plant 10 may be communicated to implement the desired control of operation. The workstation 14 (which may be, for example, a personal computer) designs process control routines 19 executed by the controller 12 and display routines executed by the workstation 14 or other computer, such process control. It can be used by one or more configuration engineers to communicate with controller 12 to download routines 19 to controller 12 . Additionally, workstation 14 may execute display routines that receive and display information relating to process plant 10 or elements thereof during operation of process plant 10 .

Each workstation 14 includes memory 20 for storing applications, such as configuration design applications and display or display applications, and for storing data, such as configuration data, related to the configuration of process plant 10 . Each of the workstations 14 also allows configuration engineers to design process control routines and other routines and download these process control routines to the controller 12 or other computer or during operation of the process plant 10 . It includes a processor 21 that runs applications so that information can be collected and displayed to the user. In some embodiments, the remote computing service is communicatively connected to workstations 14 (eg, via a network or web-based interface) to allow configuration engineers to run applications remotely from workstations 14. are doing.

Still further, each of controllers 12 includes memory 22 for storing control and communication applications and processor 24 for executing control and communication applications in any known manner. In some cases, each of controllers 12 stores and executes controller applications that implement control strategies using a number of different independently executed control modules or blocks 19 . Each control module 19 is a control module within process plant 10, each function block being a part or subroutine of an overall control routine, e.g., controlling the operation of one or more processes performed by process plant 10. may consist of what are commonly referred to as function blocks that work in conjunction with other function blocks (via communications called links) to implement the process control loops of .

As is well known, a function block, which can be an object of an object-oriented programming protocol, typically is a transmitter, sensor, or other device to perform some physical function within process plant 10 . Input functions such as those associated with field devices such as process parameter measurement devices, control functions such as those associated with control routines that implement controls such as PIDs, fuzzy logic, or some such as valves or other field devices. Implement one of the output functions that control the behavior of the device. Of course, there are hybrid and other kinds of complex function blocks such as model predictive controllers (MPC), optimizers, and the like. As the Fieldbus and DeltaV system protocols use control modules and function blocks designed and implemented in an object-oriented programming protocol, the control module can be used in any desired control programming scheme including, for example, sequential function charts, ladder logic, etc. and is not limited to being designed using function blocks or any other particular programming technique.

Workstation 14 communicates process control routine 19 within controller 12 to a user via a display screen showing the control elements within process control routine 19 and how these control elements are configured to provide control of process plant 10 . can provide a graphical depiction of In the system of FIG. 1, configuration database 25 stores configuration data used by controllers 12 and workstations 14 and, in some cases, data generated by process plant 10 for future use. It is connected to an Ethernet bus 15 to serve as a data historian by collecting and storing the In one embodiment, configuration database 25 may include library items (eg, templates and class modules) and system configuration items (eg, objects created from library items) that correspond to configuration data. Accordingly, configuration database 25 may be partitioned logically and/or physically into library data storage areas and system configuration storage areas.

In the process plant 10 shown in FIG. 1, controller 12a communicates, via bus 18, three similarly configured reactors (duplicated within plant 10), referred to herein as Reactor_01, Reactor_02, and Reactor_03. communicatively connected to a set of devices). Reactor_01 has a reactor or tank 100, three input valve systems (equipment entities) 101, 102 connected to control fluid inlet lines that provide acid, alkali, and water to reactor 100, respectively, and 103 , and an outlet valve system 104 connected to control fluid flow from the reactor 100 . A sensor 105 , which can be any desired type of sensor such as a level sensor, temperature sensor, pressure sensor, etc., is located in or near the reactor 100 . For the purposes of this discussion, we will assume that sensor 105 is a level sensor. In addition, a shared header valve system 110 is connected on the water line upstream of each of Reactor_01, Reactor_02, and Reactor_03 reactors to provide a master control for controlling the flow of water to each of those reactors.

Similarly, Reactor_03 includes reactor 300, three input valve systems 301, 302 and 303, outlet valve system 304, and level sensor 305. In the example of FIG. 1, Reactor_01, Reactor_02, and Reactor_03 reactors have input valve systems 101, 201, and 301 that provide acid to reactor 100, input valve systems 102, 202, and 302 that provide alkali, and water-providing input valve systems 103, 203, and 303 in conjunction with shared water header 110 may be used to produce salt. Outlet valve systems 104, 204, and 304 direct product from flow lines directed toward the right of FIG. 1 and waste or other waste from flow lines directed toward the bottom of FIG. It can be operated to expel unwanted material.

Controller 12a is communicatively coupled to valve systems 101-104, 110, 201-204, and 301-304 and sensors 105, 205, and 305 via bus 18 to control the operation of these elements. , Reactor-01, Reactor_02, and Reactor_03. Such operations are commonly referred to as phases and include, for example, filling reactors 100, 200, 300; heating materials in reactors 100, 200, 300; may include discarding the contents of the reactor, washing the reactor 100, 200, 300, and the like.

The valves, sensors, and other equipment shown in Figure 1 may be of any desired type or type, including, for example, Fieldbus devices, standard 4-20ma devices, HART devices, wireless HART devices, etc. , HART protocol, wireless HART protocol, or other wireless protocol, 4-20ma analog protocol, etc., using any known or desired communication protocol to communicate with controller 12 (e.g., either controller 12 or 12a) can. Typically, functions located within the process environment that directly affect the control of the process (e.g., physical functions such as opening and closing valves, measurement functions used in control algorithms or loops, and/or other functions). Devices that implement are referred to herein as "field devices."

Still further, other types of devices may be connected to and controlled by controller 12 in accordance with the principles discussed herein. For example, controller 12 may be connected to one or more input/output (I/O) devices (not shown), which in turn may be connected to one or more field devices. I/O devices are typically used by controller 12 to enable communication between one or more field devices, controller 12, and/or process control systems. Thus, I/O devices can also participate in the direct execution of control algorithms or loops that control processes. Accordingly, controllers, I/O devices, and field devices are generally and categorically referred to herein as "process control devices." Of course, the term "process control device" is not limited to controllers, I/O devices, and field devices only, but also control algorithms and processes that are executed to control processes in a process plant or process control system. /or other devices involved in or necessary for the loop may also be included.

In addition, many other controllers and types may be connected within plant 10 to control other devices or areas associated with process plant 10, and the operation of such additional controllers may be any desired. It can be coordinated with the operation of the controller 12a shown in FIG. 1 in a manner. In some embodiments, the process plant 10 of FIG. 1 includes access points, gateways between wireless and wire networks within the plant 10, gateways to other networks, repeaters within or external to the plant 10, routers. , etc., for wireless communication (not shown) within the process plant 10 . These nodes for wireless communication may be controllers 12, workstations 14, configuration databases 25, field devices, other wirelessly enabled nodes, and others (using wire protocols, wireless protocols, or combinations thereof). database or data storage device.

Generally speaking, the process plant 10 of FIG. 1 is a high-level system in which, for example, one of the workstations 14 or controllers 12a directs the operation of one or more of the reactor units (as well as other equipment). Implement a batch process that runs a control routine, a batch execution routine, and performs a series of different steps (commonly referred to as phases) required to produce a product, such as a particular type of salt can be used to To implement the different phases, batch execution routines use what is commonly referred to as a recipe that specifies the steps to be performed, the amounts and times associated with the steps, and the order of the steps. Steps for one recipe include, for example, filling a reactor with a suitable material or substance, mixing the materials in the reactor, and bringing the materials in the reactor to a certain temperature for a certain amount of time. This may include heating, emptying the reactor, and then washing the reactor to prepare for the next batch run. Each of the steps defines a phase of batch run, and the batch run routine within controller 12a executes a different control algorithm for each one of these phases. Of course, the specific ingredients, amounts of ingredients, heating temperatures, times, etc., may vary for different recipes, and thus these parameters will vary from batch run to batch run depending on the products produced or produced and the recipes used. obtain. Those skilled in the art will appreciate that although the control routine and configuration are described herein for a batch run of the reactor illustrated in FIG. may be used to implement other desired batch process operations or to implement continuous process operations.

As will also be appreciated, the same phases or steps of a batch process can be implemented on each of the different reactor units of FIG. 1 at the same time or at different times. Furthermore, since the reactor units of FIG. 1 generally contain the same number and type of equipment, the same generic phase control routine for a particular phase may be used with different reactor units. It can be used to control each of the different reactor units, except where it needs to be modified to control the different hardware or equipment associated with it. For example, to implement a fill phase for Reactor_01 (where the reactor unit is being filled), the fill control routine may, for example, set the input valve to the input valve for a period of time until the level meter 105 senses that the vessel 100 is full. One or more valves associated with systems 101, 102, and 103 are opened. However, this same control routine changes the designation of the input valve(s) to that associated with valve system 201, 202, and 203 instead of valve system 101, 102, and 103, and the designation of level meter. can be used to implement the filling phase of Reactor_02 by simply changing level meter 205 instead of level meter 105.

FIG. 2 shows one of the reactors of FIG. 1 in more detail, in particular Reactor_01. As shown analogously to FIG. 1, Reactor_01 of FIG. It includes an outlet valve system 104 for removing material from 100 and a level sensor 105 . As further shown in FIG. 2, each of the input valve systems 101, 102, and 110 includes two valves arranged parallel to each other and a flow measurement device arranged downstream of the two valves, in aggregate. We use similar equipment entities called instruments. The aggregators for the input valve system 101, shown in more detail in FIG. including a flow meter 101c located downstream of the Aggregator 101 has associated with it one or more control modules or routines that are used to control acid input using measurements made by flow meter 101c. A first such control routine may implement fast flow control through aggregator 101 using coarse valve 101a and fine valve 101b, while a second such control routine may implement coarse valve 101a and fine valve 101b. can be used to implement precise flow control through the aggregator 101 .

As can be seen from FIG. 2, alkalinity input valve system 102 includes a totalizer with coarse valve 102a, fine valve 102b, and flow meter 102c, and shared water input valve system 110 includes coarse valve 110a, fine valve 110b, , and flow meter 110c. Each of the aggregators 101, 102, and 110 have the same type of replicated equipment there, even though they are used in different locations on the same unit, the Reactor_01 unit. Similarly, Reactor_02 and Reactor_03 also include summing to input valve systems 201 , 202 , 301 and 302 .

Similarly, outlet valve system 104 is another replicated device that includes three valves. As best shown in FIG. 4, the outlet valve system 104 includes a main outlet valve 104a that must be opened for any material discharged from the tank 100, a main outlet valve 104a to deliver product from the tank 100, and a main outlet valve 104a. Product valve 104b, which must be opened in conjunction with valve 104a, and main outlet valve 104a, to drain material such as waste, cleaning fluids, etc. from tank 100 into a drain or evacuation system. It includes an exhaust valve 104c that does not. Of course, one or more control routines control the state of valves 104a, 104b, and 104c to close tank 100 and either drain tank 100 or empty tank 100 of product. Associated with valve system 104 .

To create and modify process configurations, the stored configuration application 50 of one of the workstations 14 of FIG. 1 includes a set of module class objects 52 for use in configuring the process control plant 10. . Module class objects are particularly useful when configuring plants with multiple sets of replicated equipment. Generally speaking, different module class objects 52 are for each different type of physical unit or equipment replicated or used within process plant 10 . It can be created for each different type of display application replicated or used within the process plant 10, for each type of control activity, and so on. Once created, module class object 52 may be used to configure the elements of process plant 10 that correspond to the module class object.

In essence, module class objects 52, which are generic versions of process entities and are not bound to any particular process entity, are associated with lower level objects or instances 53, 54, 55, and 56 (module objects or module referred to herein as blocks). As used herein, the term "process entity" generally refers to a subset of the process plant 10 or environment that can be identified, categorized, or grouped together. For example, a process entity may be a physical area of a plant, equipment type, control function type, group of related displays, or other classification. A process entity may contain other process entities. For example, the process entity corresponding to "valve" may include lower level process entities such as "gas valve" or "water valve", and the lower level process entity "water valve" may refer to "unidirectional water valve". It may include even lower level process entities such as "valves" and "bi-directional water valves".

As noted above, a module class object, as used herein, is generally a generic or taxonomic designation of a process entity. A module object 53, 54, 55, 56 may be created or derived from a module class object and thus inherit the same structure and properties as the module class object from which it was created or derived. However, each module object is bound to a specific entity within process plant 10 . Thus, while a different module object 53 may exist or be created for each of the different reactor units of that type actually present in the plant 10, a single module class object 52 may be used for a particular type of reaction. It can be made to represent equipment units (no matter how many of those reactor units are present in plant 10).

A module object created or derived from a module class object is associated with and owned by the module class object. Consequently, changes made to a module class object can be reflected or propagated to each of the module objects associated with that module class object. Therefore, if multiple module objects are created from a particular module class object, each of the different module objects is bound to a different process entity, and each of the different module objects simply modifies the module class object. and propagating the change down to the associated module object. As discussed, when a module class object is changed, propagation can occur automatically or the time of propagation can be selected.

The module class object 52 of FIG. 1 may be what is commonly referred to as an object in an object-oriented programming environment or language. Consequently, these objects have the ability to own or point to other objects. Generally speaking, module class objects 52 describe how their individual elements interact, such as how physical elements interconnect or how logical elements work in conjunction with physical elements. Definitions, or high-level objects that can contain instructions or definitions of individual elements such as control routines, equipment, or other elements that are associated with the process entity along with the instructions. In other words, a module class object is an object within an object-oriented programming language, control element, display, etc. that provides a basis for controlling or displaying a particular piece or group of equipment within, for example, the process plant 10. It may also be useful to create many instances where the element is used to configure different replicated pieces of equipment within the process control plant 10 .

Basically, each module class object can apply a generic definition of a process entity to that entity for use by the controller 12 controlling that entity or by the workstation 14 performing display activities on that entity. A configuration container that contains, in all its forms, different control and/or display applications or routines. A module class object may represent a process entity of any nature, such as a unit, piece of equipment, control entity, display application, and so on. During configuration of the process plant 10, the module class object can be used to create configuration instances of process entities for any number of different process entities conforming to the definition provided by the module class object, each configuration instance (module objects created from module class objects) are associated or bound to different actual process entities. These different module objects include, among other things, control routines and/or display routines that, when located within the process plant 10, are linked to specific process entities, and that these control routines are responsible for the actual control over the process entities. 1 to perform the activities, and during operation of the process plant 10, the display routines run on workstations 14 to perform the actual display activities for the entities. can be downloaded to

Different kinds of module class objects may reflect different scopes of process entities and thus may contain control and/or display routines configured to operate on or for different scopes of process entities. The greater the scope of a process entity, such as a unit, the more control and/or display routines are typically associated with module class objects and the more likely it is to use those module class objects to configure sections of the plant. Easy. However, the larger the scope of the process entity associated with the module class object, the less likely it is that the process will contain replicated equipment in that scope, and thus the less likely the module class object will be useful in a large scope. . Conversely, the lower the scope of process entities associated with a module class object, the more likely it is that the module class object can be used in a variety of different places in the plant, but the module class object in any particular instance The amount of configuration performed when using class objects is small. In any case, the module class object allows configuration to be performed for different replicated devices at a higher level of abstraction than at the control module level, which is the module class object, particularly the unit When using a large range of modular class objects such as levels, it makes it easier and less time consuming to configure a process plant using replicated units and other equipment.

Thus, multiple levels of objects are possible. For example, the objects (e.g., "instance objects") corresponding to instances 53, 54, 55, 56 created from module class object 52 are themselves sets of one or more instance child objects (not shown). can be a parent object to One or more of the instance child objects may be parent objects to further levels of child objects, and so on. As used herein, a "process element object" is generally the lowest level object corresponding to the basic process entity whose configuration is downloaded, such as a valve, sensor, graphic shape, or controller. point to Thus, a process element object may be an instance object with no child objects.

In one example, when configuring a process control system, a configuration engineer may create a single module class object for different elements replicated within the process plant, such as the different reactors in FIG. The configuration engineer can then create instances of module class objects (module objects) for each of the actual reactors of FIG. Each such created module object contains control routines used by the controller 12a to operate one of the reactors of FIG. 1 and the equipment within one of the reactors of FIG. specifically binds or ligates to These control routines can then be downloaded to the controller 12a and used during operation of the process plant 10. FIG. However, once created, each of the module objects is still bound to the module class object and can be controlled by the module class object that is modified to provide or deny access to the module object, and so on.

Although there are many different possible types of module class objects that can be created or used within a process plant to perform configuration activities within the process plant, four specific types are considered herein as examples. These include unit module class objects, equipment module class objects, control module class objects, and display module class objects. Generally speaking, each different kind of module class object is designed or intended for a different range of controls or uses within process plant 10 . Unit module class objects are intended to be used to represent (and configure) control activities for a wide range of equipment within a process plant. In particular, a unit module class object is an instrument (typically a replicated instrument), such as the reactor of Figure 1, which has individual elements that work together in some known way. is intended to be modeled or used to construct an interrelated set of

Equipment module class objects are intended to be used to represent (and configure) control activities for a non-wide range of physical equipment within a process plant. The equipment associated with an equipment module class object is generally one or more physical entities such as valves, flow meters, etc. that make up the subsystems of the unit, and the equipment module class object is one or more commands or algorithms. , which may be Command Driven Algorithms (CDA), State Driven Algorithms (SDA), Sequential Function Chart (SFC) Algorithms, Function Block Diagram (FBD) Algorithms, Phase Algorithms, etc., implemented on one device There may be. Therefore, an equipment module class object is intended to organize the control of multiple low-level components or entities within a unit so as to provide a base set of functionality for that equipment when used within the unit. As is known, command-driven algorithms (command-driven control logic) are used when low-level components must work together through multiple steps to achieve a function. For example, a valve may need to be open for a certain amount of time, then closed when another valve is opened, and then closed. The aggregator 101 of FIG. 3 employs this type of command-driven algorithm to first initiate and then operate the coarse and fine valves based on flow meter readings to provide the desired total flow through the aggregator. to use. A state-driven algorithm (state-driven control logic) may specify the states of different low-level components that can be manipulated in a single step. Such state-driven algorithms may be used in the outlet valve system 104 of FIG. of the outlet valve system 104 to deliver the product from

A control module class object is intended to be used to represent (and configure) individual control elements or control modules within a process plant. A control module class object provides or specifies a particular kind of control to be performed on a plant entity, such as a piece of equipment or even a unit, such as a valve, meter, etc. Generally speaking, a control module class object is a set of communicatively interconnected function blocks that define a number of control modules running on a controller useful for implementing replicated control activities within a process plant. It provides certain types of control programming, such as sets. In most cases, a control module class object can provide generic control strategies to operate a single device or set of related devices.

A display module class object is intended to be used to represent (and configure) display activities displayed by a user, such as to a control operator, during operation of process plant 10 . Thus, the display module class object is the programming required to create a display of some kind within the operator workstation 14 of FIG. may specify the programming required to operate on one or more of the workstations 14 (as well as any other devices within the process plant 10) that make the Types of display class modules include, for example, alarm displays, configuration display displays, operation display displays, diagnostic displays, and the like. Of course, a display module class object may provide a display representing or coupled to any desired range of physical elements or entities within the process plant. For example, a display module class object may display information about an entire area, unit, piece of equipment, control element, or any combination of these elements within process plant 10 .

Referring to FIG. 5, the hierarchy graph shows the interconnections between the different types of module class objects used in the configuration application 50 of FIG. 1, and between the module class objects and the module objects developed from those module class objects. shows the interrelationship of Looking from the top of the graph of FIG. It is separated into one of type 402 , control module class type 404 , and display module class type 406 . Of course, other types of module class objects may be provided or used as well, and the four types shown here are merely exemplary module class types. Individual module class objects (which can be, for example, high-level objects in an object-oriented programming language and are represented in FIG. 5 by double lines for clarity purposes) are different belongs under each of the types. In particular, there may be many different unit module class objects for different units or types of units within process plant 10 . For example, reactor unit class module object 410 may represent a particular type or configuration of reactor within process plant 10 . Similarly, packager unit module class object 412 may represent a particular type or configuration of packaging unit within process plant 10, and dryer unit class module object 414 may represent a particular type or configuration of dryer unit within process plant 10. configuration. Of course, there may be more than one reactor unit module class object representing reactors that differ from each other in physical configuration. Furthermore, different

Similarly, there may be many different equipment module class objects used to represent, model, and configure different types of equipment within process plant 10 . Examples shown in FIG. 5 include aggregate equipment module class object 416 and outlet valve equipment module class object 418, each associated with a different type of equipment (and preferably replicated equipment) within process plant 10. be done. Similarly, there may be many different types of control module class objects, shown in FIG. 5 as on/off valve control module class object 422, level sensor control module class object 424, and flow meter control module class object 426. Additionally, the display module class objects are shown in FIG. 5 as alarm display module class object 432, display display module class object 434, and diagnostic display module class object 436. Of course, any other desired unit, equipment, control and display module class objects may be created and used within configuration application 50 of process plant 10 in accordance with the principles described herein.

Each module class object can have sub-objects associated with it or owned by it. These sub-objects can be their own module class objects, or they can be module objects created as instances of the module class object to which they belong, as shown in FIG. Such instances are referred to interchangeably herein as "module objects," "instances," "instance objects," or "module instance objects" of the module class objects on which they are based or from which they are created. be done. FIG. 5 shows that reactor unit module class object 410 has three reactor module objects named Reactor_01 (reference 440a), Reactor_02 (reference 440b), and Reactor_03 (reference 440c) associated with it; These reactor module objects correspond to (ie, link to) respective reactor class objects 410 of FIG. FIG. 5 also shows the aggregate instrument module class object 416 as having or owning five different child module objects named Water1, Acid1, Acid2, Alkali1, and Alkali2 (references 440d-440h). Similarly, the on/off valve control module class object 422 is shown as containing child module objects named Coarse_Valve1, Coarse_Valve2, Coarse_Valve3, Fine_Valve1, Fine_Valve2, and Fine_Valve3 (references 440i-440n). Additionally, FIG. 5 shows Alarm_A graphic element object 440o based on alarm display module object 432, Temp_Se nsor_B graphic element 440p and Control_Module_C graphic element 440q, and Test_Module_D graphic element 440r and Pump_E graphic element 440s based on diagnostic display module 436 are shown. Similarly, each of the other unit, equipment, control and display module class objects in FIG. 5 may have one or more module objects associated with them. However, for simplicity, these module objects are not shown in FIG.

In the graph in Figure 5, Reactor_01, Reactor_02, and Reactor_03 unit module objects, Acid1, Acid 2, Alkali1, Alkali2, and Water1 Aggregator (instrument) module objects (references 440a-h), Coarse_Valve1, Coarse_Valve2, Coarse_Valve3, Fine_Valve1, Fine_Valve2, and Fine_Valve3 control module objects (references 440i-440n), Alarm_A, Temp_Sensor_B, Control_Module_C, Each of the Test_Module_D, Pump_E graphic element objects (references 440o-440s), and other unit, equipment, control and display module objects, may represent units, equipment, control modules, display applications, and graphical or graphic elements within the process plant 10. It is a separate object that is bound to an actual process element within process plant 10, such as a display element. Objects 440a-440s are therefore referred to interchangeably herein as "process element objects," "process element module objects," or "element objects." Similarly, each of the objects 440a-440s is a "child" or "child object" of its respective "parent" or "parent object" 410-436. For example, because there are multiple actual acid totalizers used in the plant 10, there are multiple acid totalizer process element module objects generated in the configuration routine, and separate child acid totalizer process element module objects. , for each of the individual acid counters present in the plant 10 . However, each of the child distinct aggregator process element module objects are bound or owned by the same parent aggregator module class object 416 . Of course, the graph in Figure 5 shows a limited number of module class objects, module objects, instance objects, and processes associated with it.

Furthermore, objects that are children of parent objects may themselves have child objects. For example, class object FlowMeterControlModule 426 may include two child instance objects such as, for example, "Water_Flow_MeterModule" and "Solvent_Flow_MeterModule" (not shown). The Water_Flow_Meter module may contain respective child process element module objects corresponding to respective actual flow meter elements within the process plant 10 such as "Water_Flow_Meter_1" and "Water_Flow_Meter_2". Thus, process element objects Water_Flow_Meter_1 and Water_Flow_Meter_2 are Water_Flow_Meter modules based on flow meter control module 426 .

Each of the module class objects of FIG. 5 (and therefore each of the module objects of FIG. 5) defines or directs, as part of the object, the physical or logical process elements that define or build the module. , and, if desired, how those process elements interact, either physically or logically, to perform certain activities within the process plant 10 . For example, a unit module class object typically contains instructions for all of the physical and control elements within or making up the process entity being defined as a unit. A unit module class object may also define the specific construction of individual parts and how these parts are combined together as a unit. Similarly, equipment module class objects typically have controls that define how the pieces interact, either physically or logically, to operate as a piece of equipment when placed within the plant 10. Contains control routines or control modules used to control entities defined as a piece of equipment and commands using routines or control modules. Similarly, each control module class object defines a control activity, typically in the form of some control algorithm, to be implemented within the plant. Each display module class object also represents, among other things, the display screen configuration, the information displayed, and the graphics or graphical elements presented on the display screen and the plant 10, representing various elements of the process plant 10 and plant 10, if any. may define the data to be collected for a specified type of unit, equipment, area of the plant, or any other physical or logical entity within the .

As part of a module class definition, a module class object may point to or define other module class objects embedded or used therein. If so, module objects created from that module class object either embed or reference other module objects created from other module class objects, according to the relationships defined at the module class level. , or contain. Although not strictly required, instrument module class objects may incorporate other instrument module class objects, control module class objects, and display module class objects, while unit module class objects may include other unit module class objects. , instrument module class objects, control module class objects, and display module class objects. Control module class objects may embed or reference other control module class objects and display module class objects. However, other module class object interrelationships may be used as well, if desired. These built-in relationships are that any of the Display Module class objects can be contained or referenced by any of the Control, Instrument, and Unit Module class objects; may be contained or referenced by any of the equipment and unit module class objects, and any of the equipment module class objects may be contained by any of the unit module class objects indicated by the giant arrows at the bottom of the graph in FIG. Module class objects combine other module class objects of the same type. It is understood that it can be crowded. For example, a unit module class object may incorporate another unit module class object as part of its definition. Similarly, an instrument module class object may contain another instrument module class object, a control module class object may contain another control module class object, and a display module class object may contain another display module class object. obtain. Of course, a module class object may use or embed another module class object multiple times if desired. For example, a reactor unit module class object may incorporate or use an aggregate equipment module class object many times because the reactor modeled by the reactor unit module class object contains multiple instances of aggregates. obtain.

When a first module class object embeds or uses a second module class object, any module object created from or as an instance of the first module class object is It is also understood to incorporate or use a module object created from or as an instance. Thus, when reactor unit module class object 410 uses aggregator module class object 416 as an element or part thereof, Reactor_01 module object, as an element or part thereof, aggregator module object such as Acid1 module object 440e using or including one of Similarly, if an aggregate equipment module class object embeds or contains an outlet valve equipment module class object, e.g., a module object created from an aggregate equipment module class object uniquely named as Totalizer_1 will have an outlet valve equipment module class object contains a module object created from and uniquely named, for example, Outlet_Valve_2. Thus, relationships between module class objects when defined at the module class object level are reflected in module objects developed or created from these module class objects. This interconnection or reference between module class objects (and therefore module objects) allows for high variability and high transitionability of objects during configuration activities, thereby allowing primitive modules such as control and equipment module class objects After the set of class objects is created, more complex module class objects, such as unit module class objects, reference primitive module class objects. can be easily created by Of course, module class objects can reference or use other module class objects, but they can also or alternatively refer to simple objects such as valves, sensors, or process element objects that do not have associated module class objects. be defined or used. These simple or process element objects are fully defined within the module class object itself in terms of the control routines used for them.

An example reactor unit module class object 410 is illustrated in FIG. 6 to illustrate one way of describing or defining entities associated with or presented within the unit module class object. As shown in FIG. 6, reactor unit module class object 410 contains a designation of tank 500, which is a simple object or process element object within process plant 10 for which no module class object exists. Tank 500 is shown dashed because there is no need for control or low level activities to control or implement input/output activities to the tank. Consequently, tank 500 is included only to illustrate interconnections between other objects associated with reactor unit module class object 410 . The reactor unit module class object 410 is also three different references to the aggregator module class object 416 of FIG. including. The water tallyer module class object 510 is shown in the section of the unit module class object 410 separated by a dashed line to indicate that it is a shared module class object, thus the unit module class object 410 is Share control of this object with the unit module class object. The outlet object 504 in FIG. 6 is a reference to the outlet valve instrument module class object 418 in FIG. 5, the level sensor 505 is a reference to the level sensor control module class object 424 in FIG. A valve object, which can be a simple valve element (and thus defined entirely within the unit module class object 410) or a reference to a valve control module class object defined elsewhere in the configuration strategy. is a reference to an object. Physical interconnections between different entities or parts of the Reactor Unit Module class object 410 are also shown for the purpose of defining the interconnections between these different elements. As noted above, a unit module class object 410 or any other module class object of any type is a simple element defined entirely within the module class object (including any generic control routines associated with them). and/or may contain references to module class objects defined outside the module class object.

Unit module class object 410 also has two instance display module class objects called Reactor Display 520 and Reactor Alarm Display 522 which are references to Display Display Module Class Object 434 and Alarm Display Module Class Object 432 of FIG. including. These objects include generic display activities for displaying status (e.g., tank fill level, etc.) and alarms associated with any of the reactor unit equipment or parts defined in the reactor unit module class object 410. Define. Similarly, unit module class object 410 may include other elements, such as phase class objects shown in box 524 as Dose, Mix, Drain, and Flush phase class objects, each of which is defined by unit module class object 410. defines generic control routines that are run on units that are A unit module class object can have zero or more associations to phase class objects. Phase class object 524 can be defined anywhere in unit module class object 410 and imported into it in any desired manner. In a sense, the phase class 524 is defined by the unit module class object 410 to perform different functions such as filling the unit, heating the unit, emptying the unit, cleaning the unit, etc. A command or routine that can be run on a unit that

Additionally, unit module class object 410 may include a memory or section 526 that stores references to module class objects created from this unit module class object 410 by configuration application 50 (FIG. 1). Section 526 is essentially a list of module objects created from and owned by unit module class object 410 . (Of course, this list or other indication of owned module objects can be stored in any desired manner, either on the workstation or by the configuration application 50, physically in the unit module class object 410). need not be included). In any event, in the example of FIG. 6, unit module class object 410 owns module class objects such as Reactor_01 440a, Reactor_02 440b, Reactor_03 440c, each of which is created from reactor unit module class object 410. ing.

Unit module class object 410 also includes a set of methods 530 that can be performed by unit module class object 410 either during or after configuration activity. Method 530 may include a change management method or application that automatically propagates changes made to unit module class object 410 to each of module objects 526 owned by unit module class object 410 . Other methods are security control methods that enforce security or access control on and/or any of the unit module objects 526 owned by the unit module class object 410, or a user or configuration engineer changing parameters and/or Or it may include a method that allows security parameters to be specified for a module class object or any module object created from it. Of course, different methods 530 may perform any other procedure on or for unit module class object 410 .

If desired, the unit module class object 410 can control how changes made to the module class object 410 are communicated to the unit module object 526, as well as how security access is set in the unit module object 526. One way to provide this functionality is by one or more flags or parameters within the unit module class object 410 that specify how changes are communicated to the unit module object 526 and how security is handled in the unit module object 526. is to set In particular, one or more change propagation parameters may be set to specify whether changes made to the unit module class object 410 are automatically propagated to one or more of the module class objects 526. . These change propagation parameters may be stored in the unit module object 526 and indicate whether changes made to the unit module class object are reflected in the unit module object, either for the entire unit module object or by sub-element basis. can be specified. For example, each unit module class object 410 created from the unit module class object 410 enables or disables changes made to the unit module class object 410 to be automatically reflected in the unit module class object 410 . May contain global change parameters 534 (marked with a "C") that may be set on the unit module object. Similarly, each sub-element or block, such as blocks 501-505, 510, 520, and 522, for that block only, changes made to that block in the unit module class object 410 are reflected in the unit module object. may include a change parameter 536 that specifies whether to Naturally, different blocks of the unit module object , for example, a change made to Acid block 501 of unit module class object 410 is propagated to the corresponding Acid block in a particular one of module objects 526, but not to Alkali block 502 of unit module class object 410. Changes made can be set differently so that they are not propagated to a particular one of the unit module objects' alkaline blocks. Furthermore, the different unit module objects created from the unit module class object are such that changes to Alkali block 502 within unit module class object 410 propagate to the corresponding Alkali block of the first one of unit module objects 526. may have their modification parameters set differently from each other such that they are not propagated to the corresponding Alkali block of the second one of the unit module objects 526 . Of course, the change management method of the unit module class object 410 is to set the change parameters of the unit module object 526 to make or not make changes in those objects when changes are made in the unit module class object 410. can be accessed and used. , but not to the corresponding Alkali block of the second one of the unit module objects 526 . Of course, the change management method of the unit module class object 410 is to set the change parameters of the unit module object 526 to make or not make changes in those objects when changes are made in the unit module class object 410. can be accessed and used. , but not to the corresponding Alkali block of the second one of the unit module objects 526 . Of course, the change management method of the unit module class object 410 is to set the change parameters of the unit module object 526 to make or not make changes in those objects when changes are made in the unit module class object 410. can be accessed and used.

Similarly, unit module class object 410 may include one or more security parameters that specify how security or access is controlled in each of unit module objects 526 . The unit module class object 410 has a global security parameter 538 (marked "S") that can provide any desired level of security to the overall reactor unit module object created from the reactor unit module class object 410. ) and/or for each of blocks 501-505, 510, 520, 522, etc., a unit module class that specifies the level of security for each of those blocks on the block by block criteria. It may contain different security parameters 540 for each sub-element of object 410 . Global security parameters 538 can be locking parameters that lock the unit module class object to all users except those with pre-authorized security access levels. Of course, security parameters 538 and 540 specify any one of many different levels of security, such as no access, limited access, access to certain types or identities of users, etc. Thus, the security level can be set differently in different blocks and different unit module objects created from the same unit module class object. If desired, part of the security measures may include providing encryption over one or more methods or algorithms associated with the unit module class object.

The modification and security parameters of the unit module class object 410 may be set to default values, and the corresponding modification and security parameters of each unit module object 526 created from the unit module class object 410 are set to this default value when created. It is understood that this is acceptable. However, default changes and security parameters may also be changed individually (by a user with appropriate security access) in unit module objects 526 after these unit module objects are created. While modifications and security parameters are discussed herein for reactor unit module class objects, analogous modifications and security parameters are available for other types of unit module class objects, as well as equipment module class objects, It can be provided in any desired type, such as a control module class object, a display module class object, or the like.

If desired, the unit module class object 410 is the documentation stored for or associated with the unit class module object, including documentation associated with the unit or any sub-elements of the unit associated with the unit module class object 410. may contain references, such as URLs or other references to . Such a reference is shown in FIG. 6 as reference 549 .

The embodiment shown in FIG. 6 depicts modification parameters and security parameters associated with a unit module class object 410 and indicated as modification propagation and security guidelines that apply to children or published objects of the module class object 410. do. In some embodiments, modification parameters and/or security parameters are additionally or alternatively associated with each child object or each derived object of module class object 410 (eg, with reactor object 440a). may be associated and may indicate guidelines as to whether each child or derived object receives changes or incorporates security constraints from one or more parent objects.

7 depicts a screen display that may be produced by configuration application 50 of FIG. 1 during the process of a configuration engineer creating and using module class objects to configure process plant 10. FIG. Typically, the screen display includes an explorer view on the left side of the screen that provides an organizational tree structure depicting the configuration of process plant 10 . Similarly, a screen display typically includes one or more displays of information on its right side. These information displays provide further information about selected ones of the explorer display's elements. The information that can be displayed to the user or changed by the user in the information display depends on the control and security parameters of Figure 6 set for each of the different module class objects or their sub-elements. can be determined or controlled; Accordingly, certain elements within the explorer display may be displayable or exposed to the user for viewing and/or modification based on the security and control parameters set on the module class object, the explorer It can be propagated to module objects that are rendered in the display. Of course, as previously explained, the information may be hidden at all times, or may be viewable or changeable only by the user entering a password or other security code. , always displayable and unchangeable, always displayable and changeable, or any other combination of these or other security and change parameters. Still further, if desired, the displayability, visibility or modifiability of elements may be highlighted, grayed out, etc. to inform the user which elements may be displayed or modified in more detail. , color or any other technique in the explorer display.

In FIG. 7, screen display 600 includes a portion of explorer configuration display 602 depicted on the left side of the display. A portion of explorer view 602 shows a library that stores a number of module class objects, including unit module class object 604 , equipment module class object 606 , and control module class object 608 . Reactor unit module class objects 610 (which may correspond to reactor unit module class object 410 of FIG. 6) are stored in unit module class library 604 and include Dose, Mix, Drain, and Flush phase class objects, and Acid, Contains instructions for a number of sub-elements including Alkaline, Water, and Outlet Equipment Module Class Objects, Water_In and Level_Meter Control Module Class Objects and other objects as desired. Thus, as defined in the unit module class library 604, the reactor unit module class object 610 includes an indication of the phase class as well as an indication of the equipment module class object and the control module class object. Since Reactor Unit Module class object 610 is selected on screen 600 , those elements are depicted in more detail on right side 612 of screen 600 .

Still further, the instrument module class library 606 includes an aggregate instrument module class object 614 and a Reactor_Outlet instrument module class object 616 (which may correspond to the aggregate instrument module class object 416 of FIG. 7). Aggregate instrument module class object 614 contains three different parts of algorithms called Command_00001, Command_00002, and Command_00003 (such as one of algorithms 564 in FIG. 7). Module class object 614 also contains references to control module objects called Coarse_Valve and Fine_Valve (which are on/off type control module class objects) and Flow_Meter (which is a flow meter type control module class object). Still further, the Reactor_Outlet equipment module class object 616 includes State_00001, State_00002, and State_00003, Target, Drive, Monitor, and Readback modules, and Outlet, Drain, and Product valve control module objects (of type On/Off control module class object). It has a state-driven control algorithm with different states called (which may be instructions or references to module blocks, named Outlet, Drain, and Product, or may be simple objects). The commands and state-driven algorithms associated with the Aggregator and Reactor_Outlet module class objects 614 and 616 may be any desired routines, referencing control module objects within the equipment module class object used with those commands. You may In particular, the CDA or SDA command algorithms of the equipment module class object are Equipment modules) may be included by incorporating the names of those modules that indicate which equipment will be manipulated when implementing the algorithm. The use of the name of a control module (or another equipment module) within these algorithms designates the control module object referenced or associated with the equipment module object in which the algorithm is located, and the specified name is the name of the equipment module. Objects are concatenated or instantiated when they are created from an instrument module class object.

Of course, if desired, the screen shown in FIG. 7 and similar screens can be placed within Dose or other Phase classes, or within other modules such as Unit Module Class Objects, Equipment Module Class Objects, and Display Module Class Objects. can be used by configuration engineers to generate and specify control algorithms for any of the , thereby creating any desired module class object. After creating one or more module class objects as described above, configuration engineers may then use these module class objects to configure elements within process plant 10 .

Either an instrument or a control module can be designated within a unit module class object as a shared or non-shared module object. A non-shared module object is wholly owned by the higher level module object from which it is created. A shared module object is owned or associated with two or more higher level module objects. The shared or non-shared nature of a module object affects the representation of the module object in the explorer view. In particular, while a shared module object specification results in a shared module block or module object being drawn under each of the higher level module objects that share that element as well as the stand-alone module object of the explorer hierarchy, A module object designation results in module objects being drawn only below higher level objects in the control strategy.

Similarly, configuration engineers can create components for units, instruments, control elements, and display elements according to the principles described therein within the process control environment, any other unit module class objects, instruments It is understood that a module class object and a control module class object and a display module class object may be used. Further, the configuration engineer can modify one or more of the unit module class objects and have those modifications propagated to each of the module objects created from and associated with those unit module class objects. , changes can be made to elements of the configuration of different process entities on a global basis. This feature makes it easier and less time consuming to make changes in a configuration after it has already been created. Additionally, a configuration engineer may specify access levels to different elements or components of a module object within the configuration system by setting security parameters within the module class object. As noted above, configuration engineers may specify security on modules by module criteria at any level, such as the unit module level, the equipment module level, the control module level, and the display module level. Thus, some elements of a unit module object may be displayable even when others are not.

Of course, once the configuration system has been completed and the module objects have been linked to individual process entities within process plant 10, the control and display modules or elements associated with these modules will be part of the operational execution of process plant 10. 1 to appropriate controllers 12, devices, and workstations 14 of FIG.

The techniques, systems, and methods described herein enable configuration of process plants and process control systems using flexible class, instance, and process element objects. In one embodiment, propagation of changes or modifications to parent objects is phased or delayed in one or more respective child objects so that the timing of configuration updates can be controlled at the process plant. . In one embodiment, the phasing and/or delay is indicated by the user and may be different for different child objects. In another embodiment, changes made to a parent object are applied to selected child objects, but not all of the parent's child objects. The user may indicate a selection of the desired child object to which the changes apply. In yet another embodiment, changes made to a child object are selectively applied to its parent object and/or one or more child objects. A selection of the desired parent and/or child object(s) to which the changes apply may be indicated by the user. Additionally or alternatively, users may make draft changes or modifications to various objects without automatic distribution and/or instantiation (eg, creation of executable files) of the changes. Different sets of draft changes can be saved as different versions of various objects and tested offline without affecting the actual operation of the runtime process plant.

Moreover, the techniques, systems, and methods described herein apply to items or objects stored in libraries (eg, templates and/or user-created library objects) of the process control system or plant 10 . Alternatively or additionally, the techniques, systems and methods are in some cases items stored in the configuration database 25 of the process control system or plant 10 created or derived at least in part from library items or objects. Or apply it to an object.

Still further, one or more of the flexible configuration techniques and objects described herein may be used in a process plant, such as process plant 10 of FIG. 1, or other suitable process plant or process control system. obtain. In one embodiment, one or more of the techniques described herein are performed by configuration application 50 executing on one or more workstations 14 in FIG. In another embodiment, one or more of the techniques described herein are performed at least in part by a remote application accessing the application (eg, a web client or other remote access means). In some embodiments, one or more of the flexible configuration techniques are used in combination with other configuration techniques other than those described herein.

Moreover, the flexible composition techniques and objects described herein are implemented using modular classes such as those illustrated in FIG. However, the flexible configuration techniques described herein may be implemented using other suitable module classes, software architectures, and/or programming techniques.

Item or Object Draft:

As previously discussed, embodiments of the flexible configuration techniques, systems, and methods described herein allow users to configure libraries and configurations without requiring downloads that could adversely affect a run-time process plant or process control system. Allows changes to be made to system configuration items or objects. Library items or objects are generally stored centrally in an accessible location or library (eg, configuration database 25 or other storage accessible to workstations 14 and other interfaces and computing devices). is a template object. System configuration items or objects (and some library items or objects) are generally based on or derived from one or more library items. For some items and objects, at least some aspects are customized by the user.

As used herein, the term "item" generally refers to an object such as a class object, instance object, or process element object. Items may be stored in libraries (e.g., "library items" or "library objects"), or items may be stored in system configuration data storage areas (e.g., "configuration items" or "configuration objects"). Additionally, as used herein, the term "item" also generally refers to items within and defined by an object, eg, at least part of the content of the object. Possible internal items of an object include, for example, methods, actions, data fields or other attributes, inputs, outputs, types of I/O (e.g., system type of input/output card or device that communicates with it), capabilities or usage, definitions, parameter values, references to parent objects, references to child objects, references to other objects that are neither parent nor child objects. , and other internal items. An internal item may be defined absolutely (e.g. a data field that stores a constant value or expression), or an internal item may be an absolute value, an absolute expression, a reference to another object, or another reference etc. may be defined relatively. For example, internal items defined by a graphic display element object may include references to parent objects, one or more fields, triggers, functions, display definitions, event handlers, animations, placeholders, parameters, tables, and so on. In another embodiment, the internal items defined by the control module element object are references to parent objects, one or more of inputs, outputs, parameters, function blocks, interconnections, field expressions, external references, actions, algorithms, including transitions etc.

As generally used herein, a "link" item is an object or item whose structure and starting values are derived or created from a parent object or item and/or whose structure and starting values are points to an object or item that is provided to a child object or item. Therefore, a linked item can be a parent item. Additionally or alternatively, linked items may be child items. Thus, as generally used herein, an "unlinked" item refers to an item or object that does not have a parent object and does not have any child objects. Linking (e.g., maintaining an indication of parent/child object relationships) allows the user to define the structure and starting value of the parent item or object, then assign the same structure and starting value to the instance or child object. allow sharing. For example, when a user wants to make a modification or change that affects all instances of a class object, the user modifies only the class object and the change is distributed or propagated to linked instances of the class object.

As used herein, the term "current item" or "current object" refers to the instantiated (and in some cases, downloaded) and corresponding process elements of process plant 10. Refers to an item or object that can be executed during the runtime of a . For example, when the current process element control object is instantiated, the executable configuration code corresponding to the current process element control object is downloaded to a process element such as controller 12 or 12a in FIG. is configured to operate during runtime according to the functions, inputs, outputs, and other conditions defined by the instantiated current process element control object. In another embodiment, the current graphic display presentation object is instantiated in the user interface when a display corresponding to the definitions contained in the current graphic display presentation object is constructed and presented on the user interface. Changes made to a particular internal item defined by an object typically do not affect other internal items defined by the object.

The terms "modification" and "tweak" are used interchangeably herein to refer to one or more changes to the content of an object while maintaining a link to its parent object. One example of a modification or change to a current item or object is adding new internal items to the current item or object, such as adding new parameters or actions. Additionally or alternatively, modification may include deleting existing items of the current process element object and/or changing values, expressions, or references of items defined by the object. In some scenarios, modification includes disabling certain items, so that certain items are ignored during instantiation. For example, for a particular instance object, the user can override items defined in the parent class object. Such capabilities allow users to define instances that have less functionality than the rest of the class but still include core class functionality. Any disabled content may be visually erased or hidden or otherwise disabled and not used during runtime. Disabled content can be enabled by the user when appropriate. In general, modification may involve resolving references to constant values or expressions, such as when a parent object reference resolves to a constant value for each child object.

Any changes, modifications, and combinations thereof may be made to class items or objects, instance items or objects, process element items or objects, or internal items. In the case of instance objects and other child objects, in one embodiment changes or modifications to a child object do not result in the child object being removed from its parent. For example, modifications to an instance object do not remove the instance object from its class, nor do they affect other instances of the same class unless indicated by a user or the like. In one embodiment, changes or modifications to items defined by child objects may be indicated by flags or other indicia within the child objects and labeled as such, thus not disturbing items at the class level. Thus, this flexibility may reduce proliferation of parent objects and may make a single parent item or object more applicable to a wider variety of applications by allowing more variation in its child items or objects.

Additionally, a user can save a set of modifications to an item or object as a draft. Generally, draft objects can be tested without affecting the runtime process plant or system. (As used herein, "testing" of a draft object generally refers to the ability to do an initial inspection on the draft object itself to determine if a change or modification is correct, It does not imply full factory testing, which typically requires draft objects to work in environments with other drafts.)

In one embodiment, only one draft may exist at a time for a particular object. In one embodiment, multiple different drafts may exist for a particular object. A user may be able to add, delete, or modify draft objects. In some embodiments, version control of draft objects is available. A draft object may be identified as a draft by a flag, field, or other indication contained in or associated with the object. In one embodiment, the draft object is stored as a child object of the currently instantiated object, as a child object of the current object's parent object, or as a child object of the library from which the current object is derived. In some scenarios, other information corresponding to the draft object (eg, author, time of storage, etc.) may also be stored.

Different drafts containing different modifications to the current object may be created and stored (eg, at the same time). Different drafts may be sequential in nature. For example, a first draft may correspond to constructing a legacy process device, and a second draft may correspond to constructing a newer model of the process device. Different drafts may differ in content. For example, a first draft may correspond to configuring a valve manufactured by manufacturer A to perform a particular function, while a second draft may correspond to configuring a valve manufactured by manufacturer A to perform a similar function. B. may correspond to constructing valves manufactured by B. Of course, any combination of sequential and/or content changes may appear across the set of drafts, eg, as desired by the user.

Drafts generally cannot be instantiated or downloaded, but can be distributed and downloaded to ensure that they function properly before being published to an edition. can be tested. In this way, a user can make modifications to the current item or object and store the modifications as a draft. Once the user determines the draft is acceptable, the user may publish the draft, e.g., generate a new edition of the item or object, such as a "published" or "approved" item or object. A new edition of an item or object is stored and it is available for instantiation or download to a process plant or system.

Edition:

Editions therefore help users record and control changes to process elements. In particular, an item or object may undergo changes as part of its lifespan. First, an object is created, and each subsequent change to the object (either structural, such as adding/removing a function block, or changing a parameter value) typically causes its child objects distributed or transmitted to However, during actual process plant operation, changes to parent items or objects (and especially incomplete, unapproved or untested changes) should be prevented from entering the run-time system in an uncontrolled manner. . Accordingly, the flexible configuration techniques and objects described herein include "editions" that allow users to control the distribution and propagation of changes. As used herein, "edition" generally refers to draft modifications to the current object that have been approved or published and are available for instantiation into the runtime environment. Drafts cannot be instantiated, but editions or publications can be instantiated into process plants or process control systems.

In one embodiment, the draft is published to an edition when the user so indicates (eg, only after the user approves the draft). Therefore, when a draft amendment to an object's process element item is approved, the state of the process element item or object changes from a first state (e.g., the "draft" state) where instantiation is prevented or not possible. can be changed to a second state (eg, a published state) in which it can be made public. In one embodiment, only authorized users or users with appropriate security clearance can publish drafts to editions (eg, approve draft revisions to produce published revisions or editions). When multiple drafts are available, the user can select which of the multiple drafts will be published to the edition.

An object's edition may be identified by a flag, field, or other indication contained in or associated with the object. In one embodiment, an edition or published modified object has as its parent a separate object that points to or links to a draft, current object, another edition, another object, or a library object of the modified object. is stored as an object of In some scenarios, other information corresponding to the edition of the object (eg, author, time of publication, etc.) may also be stored. In one embodiment, a child item or object can be linked to both the edition of the parent object and the parent object itself.

When multiple editions of an object are available, in one embodiment, the user may indicate or select which of the multiple editions to instantiate. For example, a user may indicate that different editions of an object are instantiated at different process elements within the process plant. Alternatively or additionally, the user may indicate different times of instantiation for editions or for different editions. In some cases, users can also delete, disable, or edit editions.

In some embodiments, only one draft (and not multiple drafts) can be stored. In such embodiments, only the current edition of the current object can be edited by the user. Thus, after editing, the user saves the draft modified object and upon user command, the draft modified object is published as a new current edition of the object. In one embodiment, the previous current edition may be automatically deleted if it does not have any child objects linked to it and is the only edition, such as in the case of library items or objects. Thus, if the current edition does not have any child objects, subsequent publications of modifications to the current edition may simply replace or overwrite the current edition (e.g., no additional current editions are created ). In one embodiment, one or more previous current editions may be hidden from the user or rendered inaccessible to the user.

In one embodiment, publishing a parent item or object that has at least one child object automatically generates a new current edition of the child object. In one embodiment, renaming an object does not create a new edition of the object, but renaming an internal item defined by the object saves the renamed internal item as a draft; and Publishing a renamed Internal Item Draft as a new edition of the Internal Item.

In one embodiment, when a published item or object points to or is embedded in another published item or object (and is itself nested in multiple levels of objects), the innermost item or object Creating a new edition may automatically create a new edition of each of the containing items or objects at all levels of nesting.

Distribution or Communication of Changes and Modifications:

The terms "dispersion" and "transmission" are used interchangeably herein and generally refer to structural transitions (function block usage for control objects, dynamo usage, geometry, parameter types, wire , and animations, display definitions, shapes, connectors, etc., for graphic element objects) and parameter values from a parent object to a child object and/or from a child object to its parent object. Modifications or changes to an editioned or published object are typically propagated. In one embodiment, only changed items contained in the published edition of the object are propagated. In one embodiment, the entire edition of the object is propagated.

Policy settings may control the distribution or propagation process on a per-object or per-item basis. In one embodiment, policy settings are modifiable by a user, such as a configuration designer or system administrator. Access to changing policy settings is securely controlled with some configuration system. Distributing and propagating policy settings includes at least two possible values, automatic and user-managed. In one example, if the policy is set to automatic for an equipment item defined in the library, any changes or modifications to the library storage equipment item published to the new edition will not affect any linking of that equipment item. automatically and immediately propagated to the item, resulting in a new published edition of the linked item.

However, if the object's policy is set to user-managed, newly published changes are not automatically and immediately propagated to the linked item. Instead, the user manually initiates propagation (or creates a script or similar to initiate propagation) to selected link items at selected times. In the library storage item example above, if the policy is set to user-managed, the user may select specific child system configuration items to receive publication changes at selected times. Additionally, if there are multiple stored editions of the library storage item, the user can indicate which of the multiple editions will be communicated at what time.

Thus, the flexible configuration techniques and objects described herein allow users to make changes to parent objects (e.g., class objects), child objects (e.g., instance objects) to which changes are distributed or propagated. Allows you to specify and specify when the transmission occurs. Thus, after publishing, changes made to the parent object can be immediately propagated to only the child objects that require changes, while other child objects can be updated with the changes later. Selection of those to receive changes or modifications can be performed on a per process entity or element basis, or on a group basis (e.g. area of a plant, all devices of a manufacturer, all operating a release of X). devices, all meters in a test generation line, etc.). Such selectivity of distribution and propagation can improve process performance during runtime because not all child objects are updated at once. Additionally, changes and modifications can be phased into the process plant in an optimized and controlled manner.

In one embodiment, for a parent object that has at least one child item, and that also has multiple existing editions, changing the distribution or propagation policy settings will affect any currently instantiated public object of the parent object. It does not affect the original edition. However, if the content of the parent item or object subsequently changes, the content change is propagated to all of its child items or objects, so that the children can use the resulting current edition of the parent object and avoid previous editions. is deleted or disabled.

In one embodiment, the propagation or distribution of parameter values from parent objects occurs only if the values have not been overwritten in child objects.

As with parent objects, changes or modifications made to child objects (e.g., instance objects or process element objects) are also optionally propagated or distributed to their respective parent objects (e.g., class objects or instance objects). obtain. In one embodiment, the timing and/or content of the transmission are selected by the user. In this way, changes in child objects can be propagated to the parent object, which in turn can propagate changes to other child objects.

In one embodiment, a user may indicate that a particular item defined by a child object should be hidden (eg, disabled) from the parent object. For example, if a particular parameter value is added to a child object, but was not generally applicable to the parent object and other children of the parent object, then the particular parameter value, during propagation to the parent object, It may be flagged, or otherwise hidden or disabled.

Instantiation:

In one embodiment, the edition may be selected by the user for instantiation. Instantiation of the selected edition results in execution of the corresponding process element during runtime according to internal items defined by the selected edition. For example, in the case of control objects, the user desires a particular published edition of the control object to be downloaded to the corresponding device of the runtime system. The user instructs the system to generate a download edition from the selected edition and send the download edition to the process element of the runtime system. Thus, during runtime, the process element executes an execution edition of the control object, which execution edition contains the configuration that encompasses the modifications contained in the edition. In another embodiment, the user instructs the configuration system to instantiate exposed graphic display element objects to be included on the display presentation. The composition system creates a running edition of the graphic display element object. When the corresponding display representation is constructed at run time, the run edition of the graphic display object is executed resulting in each graphical element contained on the display representation. When multiple editions are available, the user may select which of the multiple editions is instantiated.

In the above examples of instantiation, instantiation occurs at a time specified or indicated by the user or after an event specified or indicated by the user. In some embodiments, a user may indicate that an edition of an object will be instantiated immediately after publication. For example, the user may indicate that the instantiation of the first set of child objects corresponding to the edition will be performed immediately after publication, and that the instantiation of the second set of child objects corresponding to the edition will occur at a specified constant and that instantiation of the third set of child objects corresponding to the edition is delayed until the user explicitly requests instantiation. Thus, using the flexible configuration system techniques and objects described herein, users can control when and which modifications are instantiated on various process control elements.

Naturally, the techniques and objects described herein provide more flexibility in modifying the content of an object or item, and more flexibility in managing the distribution and timing of modifications within a process plant or process control system. and capabilities to users. For example, users can create instances and usages of objects, create copies of objects, create derived items from objects, and internal items (e.g., usages and instances ), modify internal items and instances (e.g. parameters and property values) contained in objects and usages, hide or disable selected internal items, link objects It may be possible to unlink and/or control the propagation and distribution of changes to items or objects.

Example scenario:

Several example scenarios are then provided to illustrate the features, capabilities, and operation of the flexible configuration of a process plant or process control system. These example scenarios may be implemented by any one or more portions of the techniques illustrated by any of Figures 1-7, or a combination thereof. These example scenarios are not intended to be limiting, but are provided herein to illustrate some of the concepts, advantages, and uses of the techniques, systems, and methods described herein. provided. Additionally, these scenarios are not an exhaustive set of possible scenarios. Further, while these example scenarios generally refer to library items or objects, scenarios are objects within a process plant or process control system such as system configuration objects, graphics and display objects, instance objects, process element objects, class objects, and the like. can be easily applied to other items and objects of

In a first example scenario, shown in FIG. 8, a user performs a task or executes one or more commands that create, change, or modify a library item or object 1000 . In one embodiment, commands are received at the configuration system, for example, via workstation 14 or other user interface. When a user creates or edits a library item or object 1000 and saves it, a draft 1002 of the item is stored. A user may make additional edits to draft 1002 . At some point the user approves the changes and publishes the item 1005 . Publishing 1005 results in a new edition 1008 of library item 1000 because library item 1000 in this first example scenario does not have any children. A new edition 1008 is available for instantiation into the run-time environment of a process plant or process control environment.

In a second example scenario shown in FIG. 9, a library item 1010 may have child items or objects 1012 such as, for example, the library item 1010 is linked to another library item or system configuration item 1012 . In this second scenario, the user makes a change to library item 1010 and saves it as draft modified library item 1013 . At some point, changes to Draft 1013 are approved and the user publishes Draft 1013 to produce the current edition of Library Edition 1014 containing the changes. A user can determine how changes to a library item 1010 are distributed or communicated to its children 1012 in light of, for example, process plant operational phases, staffing, procedural issues, and/or other considerations. You wish to control User-managed distribution allows process plants (refinery etc.).

To achieve controlled propagation or distribution of the current edition 1014 of the library item 1010, the user sets policy settings for the library item 1010 that control the distribution process. In one embodiment, policy settings may correspond to library items 1010 . Alternatively, policy settings may correspond to usage or children 1012 of library item 1010 . In one embodiment, policy settings may include two options, automatic 1018 and user-managed 1015 . When the policy is set to automatic type 1018, the current published edition 1014 of library item 1010 (or changes contained in the published edition 1014) are automatically distributed 1018 from library item 1010 to child item 1012. be. When the policy setting is user-managed 1015, the user can create a draft 1022 of the current edition 1014. Draft 1022 may then be published as new current edition 1025 of child item 1012 .

As shown in FIG. 10, a new current edition 1025 of system configuration item 1012 can be instantiated. For example, if system configuration item 1012 corresponds to a control or function block, current edition 1025 may be converted to download edition 1028, which, as run edition 1032, is converted to corresponding run-time item 1030 (e.g., automatically or may be downloaded) at the user's direction. In another embodiment, if system configuration item 1012 corresponds to a graphical element, the current edition of the graphical element is instantiated at runtime when a display presentation containing the graphical item is constructed.

On the other hand, referring back to FIG. 9, if the distributed policy setting indicates user-managed 1018, the user can manually propagate changes made to library item 1010 to each of its child items 1012 or can disperse. Essentially, the current edition 1014 of library item 1010 is pulled from the library by user command 1018 (which may be explicitly entered by the user or included in a script) for child item 1012 . In one embodiment, the user selects a child item of interest (eg, system configuration item 1012) and the current edition 1014 (or modifications thereto) of the library item 1010 is propagated to the child item of interest 1012. requires 1018 to be Upon propagation, a draft 1022 of the system configuration item 1012 is created and stored. The user may or may not make additional edits to the draft system configuration item 1022 . At some desired point, the user publishes the draft system configuration item 1022, resulting in a new edition 1025 of the system configuration item 1012 that can be instantiated.

The previous scenario describes modifications to library items 1000 and 1010. However, library items 1010 are not only modifiable. FIG. 11 illustrates a scenario where a user makes changes directly to system configuration items 1040 that are not library templates. The user saves the changes to the configuration item 1040 as a draft 1042 and after the draft 1042 is approved, the user publishes the draft 1042 to the current edition 1045 of the item 1040. In the example shown in FIG. 11, the user requests that a (eg, executable) download edition 1048 be generated, and then proceeds to have the download edition 1048 of item 1040 sent to runtime item 1050 . , and thus the execution edition 1052 is contained in and executed by the corresponding runtime item 1050 .

Other possible scenarios that demonstrate the flexible techniques and objects described herein include the following.

1. A user copies a library item that has multiple editions.

In this scenario, the distributed policy settings are set to user-managed. A library item with multiple editions exists in the library.

A user copies a library item to create a new library item with a different name. The resulting copy of the library item has a single edition that matches the current edition of the original library item. However, the new library item is simply a copy and is unaffected by subsequent changes to the original library item.

2. A user derives a library item from another library item.

Items (such as displays or faceplates) reside in libraries. The item has, for example, a single tank showing one transmitter and two valves.

A user selects a command that creates a draft of a new library item derived from the first library item. The user then modifies the draft to add a second sending device, saves the draft, and publishes the draft as a first edition of the derived library item.

The user then modifies the original library item to add a third valve, saves a draft of the original library item, and publishes the draft to editions. The user then distributes the modified editions of the original library item. As a result of the distribution, the derived library item now contains three valves.

3. A user creates an instance of a library item with multiple editions.

The distribution setting is set to User Managed and in this scenario only one current edition is available at any given time. A user creates a library item and creates a first instance of the library item. The user then modifies the original library item, saves the modification as a draft, and publishes the modified original library item. Publishing results in a new edition of the original library item.

The user then creates a second instance of the library item. The second instance is based on the current edition of the library item (eg, the modified original library item), but the first instance is unaffected. That is, the first instance remains based on the original library item without modification.

In one embodiment, when a new instance or usage is created from a library item that has multiple editions, the new instance or usage refers to the currently available edition of the library item.

4. Users create usages for library items that have multiple editions.

This scenario is similar to the previous scenario, but includes library item usage instead of instances. In this scenario only one current edition is available at a time. If a new usage is created from an item with multiple editions, the new usage is based on the currently available editions of the library item.

5. User modifies library items with usage.

In this scenario, system configuration items are based on library items. The system configuration items include usage amounts of library items (complex function block usage amounts in modules, etc.). Change distribution is set to user-managed.

The user modifies the library item on which the system configuration item is based and observes that the library item now has a visual indicator (such as a stack icon) indicating that multiple editions of the library item exist. The user opens a reference view on the library item and finds, for example, that there is a new (here: current) edition of the library item contained in the system configuration item that does not have usage (complex function block usage of the module) see what to do

6. User modifies a library item that has the usage of another library item.

This scenario is similar to the previous scenario, but usage is contained in a separate library item rather than a system configuration item. In this scenario, the distribution policy only controls distribution to system configuration items and remains set to user-managed. Changes to library items are automatically spread across usage within other library items, regardless of policy settings. That is, distribution to library items defaults to "automatic" and cannot be modified. Variance is recursive if the affected library item is itself used by another library item, and a new edition is created for all library items affected by changes to another library item. created in

In some embodiments, modifiable policy settings are available for library items and different modifiable policy settings are available for non-library items, such as configuration items.

7. User modifies library items that have instances.

In this scenario, library item instances (such as module instances) are stored as system configuration items. Distribution is set to user-managed.

The user modifies the library item and observes that the library item now has a visual indicator (such as a stack icon) indicating that multiple editions exist. The user opens a reference view on the library item and sees that there are system configuration instances that are not using the new (here current) edition of the library item.

8. User modifies library items that have derived library items.

In this scenario, the Parent Library Item is used by a Derived Library Item, which in turn is used by the System Configuration Item. Distribution to system configuration items is set to user-managed and distribution to library items is defaulted to automatic, not modifiable.

The user modifies the parent library item. Derived library items are automatically updated because the library item distribution setting is automatic. However, system configuration items based on derived libraries are not updated because the distribution setting for configuration items is set to user-managed. Therefore, the system configuration item continues to use the previous edition of the derived library item. The user sees this by opening the References view on the parent Library Item and observing that the Derived Library Item uses the current edition of the parent Library Item, but the System Configuration Item does not. be able to.

9. Users update usage in the context of library items.

Building on the previous scenario, the user sees a stack icon corresponding to the library item, indicating that not all instances of the library item have been updated. Distribution to system configuration items is set to user-managed.

The user opens the reference display on the library item and sees two rows corresponding to two displays, each using the library item. The user then changes one of the displays to use the current updated edition of the library item. When the user opens the display, the user can see the current updated version of the library item, e.g., both the display and any library item usage indicate that they are using the current updated edition. see the edition.

Later, the user opens the reference view on the second display and changes usage to use the current updated edition of the library item. The user saves the second display and the usage view shows that the current updated edition of the library item is being used.

As a result of the user modification, there are no items in the system linked to the first edition of the library item, so the first edition is automatically deleted by the system. In other embodiments, the first edition may be disabled or set to inactive.

The user can select multiple usages that are not current and can choose to update them to the current edition. Directives on library items can disappear when all instances are using the latest edition. If the usage or instance cannot be updated during a multiple selection operation, the usage or instance is skipped and the update proceeds to the next item. At the end of the update, the user is shown which items were not successfully updated.

10. User updates library item usage in the context of the library item.

In one embodiment, changes to library items are automatically distributed to usage in other library items regardless of system configuration distribution policy settings. In some embodiments, different library distribution policy settings may be available and modifiable by users authorized to do so.

11. The user updates the instance in the context of the library item.

This scenario extends the traditional class-oriented module behavior. Library items exist and instances of library items are stored as system configuration items. However, the instance is not using the current edition of the library item. The distribution to system configuration objects is set to user-managed.

A user selects a library item and opens a browse view. The user sees that the system configuration instance is not using the current edition of the library item, so the user selects the instance and executes the "make current" command. This command results in a new draft of the instance using the current edition of the library item. The user may then take steps to edit and/or publish the draft of the system configuration instance.

12. Users update derived items in the context of library items.

Users can create library items based on other library items. For example, a user can create a parent library module without any interlocks, and then create a derived library module that has all the capabilities of the parent library module with the addition of interlocks. Changes to the algorithms of the parent library module can flow to the derived library modules, thus users benefit from having the algorithms defined in one predetermined location.

13. User updates usage in context of usage.

In this scenario, the user wishes to update the usage to use the current edition. For example, a control module object is stored as a system configuration object and contains function block usage for a single edition composite block with a single input connector. A single edition composite block is a library item and the distribution to system configuration objects is set to user-managed. The user modifies the library composite block to add another input connector and creates a new current edition for the library composite block. The user can see a graphic indicating that the library composite block has multiple editions.

The user then selects the function block usage on a particular control module and selects the "make current" command. Specific control module usage has been updated to use the current edition and therefore show additional input connectors. If no previous library composite block edition is used in the system, the graphic changes to indicate that the library composite block no longer has multiple editions.

14. User updates library item usage in the context of library item usage.

Like derived items, library item usage (eg, function blocks) in other library items can be defaulted to automatic updates regardless of the distribution policy setting to configuration items. However, if changes cannot be automatically distributed to another library item due to some conflict, the user may manually correct the library item usage.

15. The user updates the instance in the context of the instance.

In this scenario, the library module has a single edition and instances of the library module are stored as system configuration items. Distribution to system configuration items is set to user-managed. Users modify library modules and publish changes. A graphic on the display associated with the library module indicates that the library composite block has multiple editions.

The user selects the module instance and selects the "Make Current" command. A draft of an instance is created that uses the current modified edition of the library module. The user can then publish the draft to create a new current edition of the module instance. If the previous library module edition is no longer used anywhere in the system, the multiple editions directive associated with the library is removed from the display.

16. User updates all instances contained in the equipment item.

This scenario is similar to the previous scenario, except that updates are made in the context of equipment items such as regions, cells, or units. A library module exists with a single edition and two instances of the module exist in the system configuration under the region. Distribution to system configuration is set to user-managed. The user modifies the library module and a graphic is provided indicating that the library composite block has multiple editions.

On the display corresponding to the context (eg, region), the region is also marked as having non-current instances. Zooming in on the region display, two module instances are marked as not current. The user selects the region and selects the "make current" command. A draft of an instance using the current edition of the library module is created. The user can publish the draft to create a new current edition of the module instance, thus removing the "not current" marking from the display. Multiple edition directives corresponding to a library module may also disappear from the display if the previous library module edition is no longer used anywhere in the system.

17. The user updates the derived item in the context of the derived item.

The library stores two items, a library display DISP1 and a library display DISP2 derived from DISP1. The user modifies DISP1 to add a string field, publish DISP1, and distribute DISP1. Therefore, DISP2 is automatically updated with the string field.

Similarly, the library stores a library device type VALVE that may have a faceplate associated with it. Libraries may also store library device types DVC derived from VALVE, containing additional information to faceplates used by VALVE. Additionally, the library stores an application specific library device type MfctrDVC, which in turn adds even more information to the faceplate for the DVC. When the user changes the parameter value for VALVE, the parameter value is automatically updated in both DVC and MfctrDVC when DVC and MfctrDVC do not overwrite the parameter value.

As a continuation to the above, the user creates an application specific device type MfctrDVC-CriticalService by deriving this device type from the MfctrDVC device type. By doing so, the user overrides one of the parameters. In this succession scenario, when the user changes the value of the same parameter in VALVE, the parameter value is automatically updated in DVC and MfctrDVC because DVC and MfctrDVC do not overwrite the parameter value. However, the parameter value is not changed in MfctrDVC-CriticalService because the user overridden the parameter value.

Thus, in one embodiment, library items derived from other items are always updated when the parent library item changes, regardless of the distribution policy setting for system configuration items. However, due to conflicts, the current edition of a parent library item may not automatically propagate to derived library items with structural changes. After the user corrects this issue, the user can manually update the derived library item.

18. The user updates the usage resulting in rule violations.

In this scenario, the distribution to system configuration objects is set to automatic. However, distributing changes made to library items may fail to update some or all of the child system configuration instances if rules (eg, database rules) are violated. This difference may not be apparent to the user when saving the library item when distribution is coupled with the later publishing step. In fact, the new edition may already be in use by other linked items before the discrepancy is discovered. In this situation, the user can edit the library item to correct the discrepancies, thus creating a new current edition of the library item that can be used for all instances without breaking the rules.

To illustrate, an update to a new edition with new usage conflicts with the usage name added to the instance. For example, the library stores a library module LM with a usage named USAGE1. System configuration instances MA and MB of library module LM reside in area AreaA. The user then adds usage USAGE2 to instance MA.

The user adds the usage USAGE2 to the library module LM, publishes the library module LM and distributes it. Since instance MA already has usage USAGE2, instance MA remains non-current and the "not current" referent corresponds to instance MA. However, the instance MB has no such usage and is successfully updated.

19. User saves library item after switching from user-managed to automatic system configuration distribution.

In this scenario, the library item is used by multiple displays. One display is using the current edition while the other display is using the previous edition. The user switches from user-managed to automatic distribution. Changing the distribution from user-managed to automatic distribution does not affect the display.

When the system configuration distribution setting is set to automatic, the user modifies the library item. Therefore, all instances of the library item are updated to use the current modified edition. As all of the system configuration instances are updated, older editions of library items are no longer referenced and can be automatically deleted. Icons for library items change to indicate that only one edition exists.

20. User downloads a non-using instance of the current edition of the library item.

A user may download to a process element a system configuration instance that does not use the current edition of the library item. A download request can result in a download warning being displayed.

21. The user downloads an object with usage that does not use the current edition of the library item.

A user may download to a process element a system configuration instance that does not contain the current edition of usage of a library item. A download request can result in a download warning being displayed.

22. The user imports a file containing library items.

In this scenario, the user imports a file and presents the user with a list of items in that file. The user can select from import behaviors (skip, overwrite, etc.) for each item.

As the example scenarios above illustrate, a user can perform at least the following actions or commands using the flexible configuration techniques, systems, and methods described herein.

Edit - allows you to open and modify an item or object. Users can open drafts or editions.

Save as Draft - Save the opened (and possibly modified) item as a draft.

test-drive draft objects without downloading or instantiating them.

Approve Approve the draft for publication.

Publish - Take a draft and turn it into the current edition. Publishing typically occurs after approval of the draft.

Generate - Generate download or runtime editions from published or current editions.

Send - Send the edition to the runtime.

Download - Embodiment of the send command to send the download edition to the runtime. Downloading is typically performed in the context of a system configuration item.

Distribute/propagate/update--updating another linked object with modifications made to a particular object edition. Updating, distributing or propagating a modification to a particular object may result in updating multiple other linked objects, such as child objects and/or parent objects, for example.

Update from LibraryUpdates (eg, distributes or propagates) modifications to a library object edition to child objects derived from the library object. Updating or propagating a library object can result in multiple levels of updating of linked children. Thus, a user may, for example, create instances or derived item usages from current editions of library items.

Delete - Delete an object or item from storage.

Validate - Inspect an item or object for errors. Both drafts and editions are verified.

Differencesdetermines differences between various editions of an object or item.

References - Determines the references associated with an item or object.

In some embodiments, one or more of the above actions or commands may be hidden or unavailable to the end user. For example, create and send commands may be combined with download commands, or users may not be allowed to delete items unless the user has appropriate permissions.

In one embodiment, a user can request a flexible configuration system to indicate any differences between draft and current published and download editions for an item or object. For example, a user can choose between a draft and the current published edition, between a draft and any edition in version control, between a draft and a download edition, between two different drafts, between two different current editions. You may ask to see the differences between the current edition and the download edition, and between other combinations.

In one embodiment, a user can set the Can be requested to the configuration system. Conversely, in one embodiment, a user can request a view to determine if a child object is using the current edition of its parent object.

package:

In some embodiments, the draft, publish, and instantiate techniques described above may be applied to groups of objects. A group of objects or multiple objects are generally referred to herein as a "package". In one embodiment, the members of the package are selected by the user. At least some of the members of the package are, in some cases, provided out-of-the-box (OOB) by the manufacturer or provider.

For example, an OOB package may include a set of "starter" library items (eg, modules, composites, displays, devices, etc.). A user may select various items from a starter collection of items to create a process solution such as a control loop or process model. If the user has added customized objects to the OOB package, the user may designate the augmented OOB package as a different package than the starter package.

Another example package may include configuration implementations adapted to solve unique process problems, such as, for example, boiler packages or reactor packages. Such packages are typically used as complete solutions to handle control problems and are referred to herein as "solution packages" or the like. In one embodiment, a solution package includes any instantiation rules that are applied when a user instantiates the package. For example, when a boiler package is instantiated, a rule can describe how all items in the package are to be named according to a naming convention using string substitution.

As with items or objects, one or more drafts may be created or edited for the current package. Draft packages can be published to editions, and editions can be selected for instantiation. In one embodiment, if a user wishes to save a new edition of a package, the new edition may replace the previous edition, or the new edition may be stored concurrently with the previous edition.

These techniques of Package Draft, Package Publish, and Package Instantiation provide users with yet another level of flexibility. In an exemplary (but non-limiting) scenario, a library package is created and stored as the first draft of the package. For example, a library package corresponds to a boiler or reactor template configuration. A first draft of the package is published, stored as a first edition, and instantiated into a process plant or system. The first edition is subsequently modified (eg, correcting issues and/or adding functionality to the boiler or reactor) and subsequently published as a second edition of the package. Upon receiving a user instruction to instantiate the second edition of the package, only those items contained in the second edition of the package that are updated from the first version of the package are instantiated. Additionally, the user may indicate the timing of instantiation of various update items as required by logistics, performance, bandwidth, and/or other constraints. If use of the second edition needs to be terminated for any reason, the first edition can be re-instantiated into the process plant or system.

Graphical or display item or object:

Now considering flexible graphical or display items or objects, as generally referred to herein, a "display" is a graphical entity (e.g., , the most granular entity). Typically, flexible graphical or display items or objects are composed of other graphical objects and may be stored in an object library or system configuration data storage entity. Displays can be instantiated during run-time of process elements by downloading published editions for execution, or can be instantiated in real-time, such as when an operator requests a particular display view to be constructed. . Display types that can be defined by flexible graphical items or objects include, for example:

1) Operational Display: The operational display generally provides a window into the process or representation of the process as it is being executed in the process plant. Typically, display representations are composed of GEMs and other library and/or system configuration objects and can be instantiated on a local or remote user interface.

2) Dashboard Display: The dashboard display provides important indicators for operators and plant personnel. A dashboard display may be constructed from library and/or system configuration objects and instantiated on a local or remote user interface. In some embodiments, the limited capabilities, features, or graphics included on the dashboard display may be configured and instantiated by the operator at runtime. The capabilities, features, and graphical elements and shapes included on dashboard displays are generally referred to herein as "gadgets." Generally speaking, gadgets are GEMs that are marked as available at runtime and can be placed on dashboard displays. Accordingly, as used herein, the term "GEM" refers generically to both GEMs that are gadgets and GEMs that are not gadgets. Examples of dashboards and gadgets can be found in "Configurable User Displays in a co-pending US Provisional Patent Application No. 61/711,105 entitled "Process Control System", the entire contents of which are incorporated herein by reference.

3) Layout Display: A layout display provides an area or region on the user interface that allows the user to organize other displays on top of it. A layout display allows a user to create an arrangement of displays on a single monitor screen or across several monitor screens.

4) Form Display: The form display provides the user interface for data entry during configuration or run time. Form displays can be utilized by users to create or modify objects, enter configuration or run-time data, enter values, and generally manipulate display items and objects.

A display typically contains one or more representations, each of which is a different visual representation of the display. Each view of the display may contain shapes (eg, rectangles, ellipses, and other shapes) and/or controls (eg, labels or text boxes), stored in an object library or in a system configuration data storage entity. It may have a corresponding object to be stored. Some shapes, such as rectangles, text boxes, or stack panels, can be constructed and stored in the configuration system (eg, compiled and registered with the system). Other shapes can be created by users and corresponding shape objects can be stored in an object library or stored as system configuration GEMs or gadgets.

As discussed earlier, GEMs or Gadgets are reusable shapes that combine one or more shapes with behaviors. GEMs and gadgets can be created by users, published to editions, stored in the configuration system as objects such as libraries or system configurations. GEMs can be linked to other objects, and subsequent changes to GEM objects can be propagated to other GEMs and all uses of GEMs in displays, eg, in the manner described above. In one embodiment, out-of-box (OOB) shapes, GEMs, gadgets, and displays (which in some cases correspond to a customer's specific industry) are, for example, a set of primitive objects or a "starter set" of objects. , provided in the configuration system library.

Similar to a display, a GEM can contain one or more visual representations or indications. Each of the GEM representations includes one or more built-in and/or created shapes. FIG. 12 shows three possible different views of an exemplary Valve GEM: vertical view 1060a, horizontal view 1060b, and alternative vertical view 1060c. A diagram of the GEM can be used to present different levels of detail, placement of shapes, or different foci of information related to the GEM.

In addition to relatively static shapes and displays, displays, GEMs, or gadgets are also dynamic, allowing operators to view, navigate through, or change process data. May contain behaviors. Dynamic behavior can include, for example, animation and event handling, both of which are discussed below.

Animation maps process data from sources within the process plant to various shapes on the display to present the process data in textual or graphical form. Animation results can be applied to a shape field (eg, a string field or a visibility field) such that the animation changes when the source field value changes. Animation thus allows the process data to be manipulated by a function (eg, a mathematical function) to transform the raw process data into a meaningful visual presentation. For example, an animation can be applied to a rectangle shape to show the fill percentage of the rectangle for a tank level, or an animation can be applied to a text shape to display the fill percentage value in text form.

Event handlers are configured to implement defined responses to events such as mouse clicks, keyboard movements, and accelerator key moves. A defined response can be, for example, moving to another display, acknowledging an alarm, changing a process setpoint, entering data, and other such actions.

Since a GEM can be included in multiple visual presentations or presentations, the animations and event handlers associated with the GEM can be created once and reused in different presentations to provide different orientations or presentations of the data. . Thus, the amount of custom code required to create GEMs and modify GEM usage for each of its various representations can be reduced.

To make the GEM reusable across many objects and sources of information, in one embodiment animation and event handler paths are partially or fully tokenized with placeholders. The value of the placeholder value can be provided when configuring the specific usage of the GEM, or the placeholder value can be set programmatically at runtime. Animations and event handlers can reference placeholders, so the value of the placeholder is substituted in the reference at runtime to resolve the path to the specified object. Additionally, similar to GEMs, displays may also support placeholders, thus making them reusable. Display instances can be created as part of configuration or dynamically at runtime by providing values for various placeholder(s).

In some embodiments, information reuse and sharing is determined by using a global set. The global set allows configuration designers to configure shared state and behavior across many unrelated displays and GEMs, for example, for the lifetime of a client Human Machine Interface (HMI) session. Items in the global set can be referenced and used by any display or GEM, thus allowing reuse and sharing among many items. In one embodiment, each item in the global set is stored in an object linked to the object corresponding to the global set.

In some embodiments, reuse and sharing of information occurs through the use of styles and/or style sets. A style is a collection of field name and value pairs, and a styleset is a collection of styles. In one embodiment, all shapes support styles. When a shape is added by a user to a display or representation of a GEM, the style field can be set to the desired style of the style set. As a result, the added shape uses the values defined in the style for each field. Styles and style sets can be represented to the composition system by respective objects.

In some embodiments, named constants allow user flexibility in creating name-value pairs. For example, fields within a graphic element object are assigned constants named as values, such as TitleFont or TankBodyColor. Name constants allow project standards to be created and assigned to field values. When project standards change, named constant values can be updated in one central location. Named constants may include, for example, name, title, description, and data type. Any field value can be set to a value or named constant, such as fields on shape usage, animations, transformers, tables, global sets, and styles.

pattern:

Display objects may relate to each other and other objects by one or more patterns, such as usage patterns or derived patterns. Additionally or alternatively, configuration objects may relate to each other and other objects by one or more patterns. The use of different kinds of patterns need not be mutually exclusive. For example, various aspects of some patterns may be combined.

A usage pattern is generally a definition-based containment or grouping of objects. FIG. 13 shows a diagram of an example of a defined usage design pattern. With usage patterns, the definition of graphical object 1062a includes one or more usages 1062b of one or more other graphical items 1062c. When instantiated, these usages 1062b represent graphical shapes defined by graphical objects 1062a presented on the display's display. Each usage 1062b may have definitions including default values for internal items such as fields, events, and behaviors. In one embodiment, such internal items may be configured.

The defined usage patterns may be nested in multiple levels if desired. FIG. 14 shows a class diagram for an example nested definition usage design pattern. For example, a display can contain a GEM that can contain another GEM or a shape.

FIG. 15 shows an illustration of the definition usage of abstracted nested states. In FIG. 15, usage C1 (reference 1065a) is based on the definition of usage B1 (reference 1065b). A user may modify (eg, overwrite or tweak) one or more internal items from another usage. For example, in FIG. 15, the change to usage C1 (reference 1065c) is a minor adjustment.

Another pattern in which objects can be related is the derivation pattern. A diagram of an example derived pattern is shown in FIG. Derivation patterns allow definitions to be extended without using aggregation (as is the case with the definition usage patterns discussed above). In particular, derived patterns allow the creation of new definitions 1068a without creating another level of hierarchy. Therefore, all internal items of the "underlying" definition 1068a are included in the derived definition 1068b.

Derived patterns can be multiple levels of nesting, for example, a derived definition can be based on another derived definition that can ultimately be based on a non-derived definition. Any desired number of nesting levels may be possible. FIG. 17 illustrates an example nested derivation pattern of a new definition 1070a created from a first derived definition 1070b created from a second derived definition 1070c created from a non-derived definition (not shown).

Flexible items and objects:

As previously discussed, objects can be flexibly defined and used in the configuration system. In one embodiment, a flexible object may contain one or more internal items, which in turn may be defined by another object. A description of flexible items, objects, and internal items that can be included in the configuration system follows. These descriptions are presented in the context of graphical or display objects, and the concepts and attributes discussed herein also apply to configuration objects.

A field is an internal item that represents a state or attribute of a given object. For example, the rectangle size is stored in the width and height fields. Each field can have a name and a value. In one embodiment, additional metadata associated with a field indicates whether the field can be animated, whether the field is read-only, and other attributes of the field such as the data type of the field. Metadata can be used, for example, in the construction of a given object. A field's value can be a simple data type such as a string, or it can be a reference to another object such as a library object, shape object, or process element object. In one embodiment, the value of the field can be modified or overridden by the user.

Placeholders are generated internal items that allow the defined item to be used across multiple other objects. For example, for display objects, placeholders can be graphic items that allow animations and event handlers to be created and reused across different graphics or display objects and source paths. Placeholders thus provide some level of indirection and are resolved by value at runtime. In some embodiments, placeholders may be nested.

Parameters are internal items that represent the state or attributes of a field. For example, for displays and graphical objects, parameters can be graphical items that have values and states. Parameters may be added to graphical items such as GEMs, gadgets, displays and dashboards, layouts and forms, global sets, and the like. Parameters are typically not visible during runtime. However, parameters can affect the visual aspects of objects during runtime (such as animations) by creating expressions that reference the values. A user may add parameters to an object, but in some embodiments a user may not be able to add parameters to a particular library item or primitive object.

A function is an internal item that provides behavior for a specified object. For example, with displays and graphical objects, functions can be graphic items or generic behaviors provided from a group or global set. For example, a group's visual item may provide an AddShape() function, or a global set may provide an OpenDisplay() function. Some functions may be built-in and therefore not modifiable by the user. Other functions can be created by the user. In one embodiment, functions may be executed during runtime via programming APIs or scripts. In addition, functions may take one or more arguments, such as constants, values of fields, references to other objects, or references to parameters. A function may, in some instances, return a value such as a constant, the value of a field, a reference to another object, or a reference to a parameter.

An animation is an internal item that maps data from a source or object to the fields of the internal item. For example, for a display or graphic object, an animation can map data to the FillPercent field of a rectangle or the Text property of a Label. Animations involve expressions that are reevaluated and/or recalculated when the referenced value of the expression changes. Additionally, the animation is associated with the field of interest, eg, a field on a parent object that is updated with the result of a recalculated expression. Therefore, at runtime, when the animation's computed value changes, the field of interest is updated with the recomputed value, thus causing the screen rendering to change. In one embodiment, the animation includes an update frequency and may include a transformer that transforms the expression result.

A transformer is an internal item that transforms an animation expression result into a final animation result. For example, a transformation may change the recalculated value (result) of the expression, the data type or format of the result, both the result and the data type, or the transformation may change some other of the transformations on the result of the expression. can implement the type of Each transducer type may include designated fields that may be configured by the user.

An event is an item inside an object that defines actions and responses. Event definitions typically include event triggers such as user clicks, mouse movements, mouse hovers, or data changes. Optionally, events are also defined with event handlers that execute one or more response functions or behaviors when the trigger is fired. Event handlers can be configured by the user, provided as OOB behaviors on pre-configured definitions, or provided as built-in behaviors on specified shapes. Adding event handlers for specified events allows customers to create behaviors based on specified triggers.

Each event trigger may support one or more specified arguments. Event triggers typically include a source argument that indicates the object that fired the event trigger. Additionally, event triggers may include optional arguments appropriate to the type of event, such as information to be sent upon activation. Mouse move triggers can have source arguments and mouse location coordinates (e.g., X, Y) sent when the mouse move trigger is fired, whereas mouse click triggers, for example, can have only source arguments. can have In some cases, events are not triggered based on user actions, but when an object's field value or system state changes, eg, from start to steady state.

In some embodiments, event handlers are configured for event triggers. In these embodiments, the event handler is called when an event trigger is fired and performs one or more functions in response to trigger firing. In one embodiment, the user defines event handlers to include custom behavior or logic to be executed along with available functions (eg, functions available for display, window or global set).

A table is an internal item that contains one or more data structures with input values and output results. In one embodiment, a table may be used with a table converter that converts input values from one data type to another. For example, for graphic objects, table usage may include converting process values to colors or converting process values to strings. Thus, tables provide a non-programmatic way to configure results for a range of input values. The table can operate on an exact match of input values or on a range of input values.

Shape objects are basic generated visual building blocks that can be combined together to generate composite visual representations and specialized visual items such as GEMs and displays. Some shape objects can be embedded (eg, have an OOB with the executable installed with the configuration system) and are referred to herein as primitive shapes. Primitive shapes can be geometric shapes (e.g. rectangles, lines, ellipses), containers (e.g. groups, panels, grids) in which other shapes can be placed, controls (e.g. text boxes, drop-down combo boxes, or batch list control, trend), etc.).

Each shape (primitive or not) has a definition. A definition may include, for example, one or more fields, animations, events with event triggers, handlers, and/or connection points. In one embodiment, a shape may support a style field. Typically, most shapes are configurable and modifiable. For example, rectangles are provided as built-in to the configuration system, and users can modify rectangle objects by setting field values and adding events or animations to the rectangle usage. The user can then save the modified rectangular shape as a new object and publish it after approval.

FIG. 18 shows an example of shape usage Rect1 (reference 1075) created based on the definition 1078 of a rectangle. The user has modified the values of the width 1080a and height 1080b fields from the default rectangle definition values. In addition, the user has added an animation 1082a targeting the width field and a range transformer 1082b to properly scale the values. The user also added an event handler 1085a on usage 1075 for click event 1085b, and the event handler was configured to call the OpenDisplay() function. In one embodiment, only fields that are specifically overridden (eg, 1080a, 1080b) are preserved. That is, shape usage 1075 links back to definition 1078, and any field whose value is not overridden comes from definition 1078 (or style, in some cases). For example, if the foreground brush for rectangle definition 1078 is changed from blue to gray, the foreground brush (e.g. usage Rect1 1075) will have a blue foreground brush after the change is propagated from the rectangle definition 1078 edition.

In terms of geometric shape definitions, group shapes allow several shapes to be treated as one shape for actions such as visibility, resizing, placement/orientation, and events. A group shape is thus a copy of a plurality of shapes that relatively maintain their respective (X, Y) coordinate orientations. The behavior of the fields and events of a group and how they affect the fields and events of contained shapes within the group may be configurable. For example, a dynamo is one type of group shape.

Panel shapes can be similar to group shapes, but can allow more specific control over the rendering of contained shapes (eg, size, position, placement, etc.). Items within a panel are generally ordered or docked to a designated area of the panel and, unlike groups, do not have relative coordinate settings. Panels have the ability to control items when the exact number of items is not known, and the ability to arrange items visually without having to move each item individually when the panel or containing window is resized. and are given to the user. Panels also provide behaviors when items are added, removed, or hidden within the panel by adjusting the position of other items to eliminate blank space and avoid duplication.

Connector usage represents the physical linking elements of a process plant such as wires, pipes, ducts, or conveyors. During composition, a connection point indicates an indication of the connection of connection usage to shape usage. Connector usage allows connectors to be tracked, routed and resized as shape usage is moved during composition. Specifically, a connector traces and routes according to its defined algorithms and settings. A connector is thus a shape that links other display objects together on a display, defined by their respective properties and behaviors. When placed and connected on a display, the connector can be routed around different geometric usages. Configuration users can modify connector placement or routing, define default visuals, and/or modify connection points for connector usage.

Layers organize and enhance the user's editing experience by hiding and locking shapes that can interfere with the current task or prevent inadvertent modification of shape usage. Another type of display object that can be used during composition. Layers provide a way to organize geometry usage and assist in the construction of display definitions and/or GEM display definitions. Layers can also be used to organize shapes to provide run-time features such as showing and hiding details such as help, maintenance, or diagnostic layers.

In particular, the display can have one or more layers. A shape in the display may be associated with a particular layer (eg, shape objects and layer objects may be linked). A particular layer can be designed as either configuration only or both configuration and runtime. Layers can be visible or invisible. Layers can be locked and unlocked to prevent inadvertent selection or modification. When a layer's visibility changes, the value can be propagated recursively to all layers matching by name on the contained GEM usage. For example, visibility on the "help" layer applies to any GEM usage associated with the help layer.

User-created items and objects:

At least some of the flexible objects discussed above may be created by users, for example, as follows.

Display - For example, a visual item that a user can open at runtime. The display typically presents an indication of an operating process or provides details about a specified area of the process.

GEMs and gadgetseg, composed shapes that represent process elements or other entities within a process and may be included (eg, placed) on displays or other GEMs. For example, devices, control modules, dynamos, displays, or other process elements can be represented by GEMs. A GEM can be configured to be reusable to represent different instances of the same type of process equipment or pieces within a plant or process. Thus, a GEM can be constructed and tested once, but used many times with other GEMs and displays. Typically, GEMs include name, title, description, selected display, and other fields such as tables, events, parameters and functions. GEMs may be nested within other GEMs or displays, for example. Typically, a GEM has one or more display definitions that provide one or more corresponding visual representations of the GEM. A default view may be provided for the GEM, and in some embodiments the user may be able to change the default view. Of course, the user may be able to change any of the fields defined by the GEM.

In one embodiment, gadgets are GEMs that are available at runtime and can be placed on dashboard displays. Operators may, for example, be able to create and modify gadgets during runtime.

A GEM definition can be derived from another GEM definition. When a GEM is derived from another GEM, the derived GEM contains all representations from the underlying GEM. A user may modify these representations of the derived GEM or add additional representations to the derived GEM. Additional representations may be independent, derived from existing representations defined in existing GEM definitions, or created from underlying GEM definitions.

In one embodiment, when a GEM is placed on the display's view or another GEM's view, the placed GEM becomes a shape usage (similar to adding built-in shape usage such as rectangles or groups). . However, placed GEMs remain linked back to their respective definitions, and changes to usage are propagated based on propagation settings and strategies.

In one embodiment, modifying (eg, resizing) GEM usage is similar to modifying group usage. Additionally, GEMs or gadgets can be constructed by using standardized or partially standardized forms that are presented to the construction designer.

Displayeg, a display or a visual representation within a GEM. Each display or GEM can have one or more defined representations. Visual or graphical items (eg, shapes and other GEMs) can be added to the display definition. Views can be independent or derived from another view within the same or underlying parent definition.

Standalone display definitions typically define their entire content and information, such as shape, statically configured field values, animations, and event handlers. Therefore, an independent display definition is not based on any other display definition within the containing display or GEM definition. However, a display or GEM definition can have multiple views that are independent and not derived from a common view.

A derived display definition, on the other hand, is typically based on another display definition within the same container definition. Once the container definition is derived, the view definition can be derived from the view of the container definition's underlying definition. For example, display A defines display A and display B. If display B is derived from display A, then display B has by default display A and display B, but display C may also be defined to be derived from display B.

A display definition may include a set of known fields, which the user may configure or the user may add animations for those fields. The display definition may also contain one or more events with known triggers to which the user may add event handlers. In addition, a particular view definition includes shape usages, such as all usages from the underlying view, as well as any shape usages added to this particular view definition. A view can provide a namespace so that items within the view definition can be named uniquely.

Global SetA composed item that holds state (eg, values) and behaviors (eg, functions) that can be referenced from, eg, unrelated displays, gadgets, and GEMs. Generally, global sets do not have any visual representation at runtime, but are available at runtime. A global set may be marked as a single unit, or a global set may correspond to an instance or group of objects. A global set thus provides a way to share and reuse information among many objects.

Styles and StyleSets - a collection of field names and values (e.g. field/value pairs) that can be applied across sets of changes and shape usages or other visual items at one location, e.g. to maintain consistency be. A styleset is a collection of styles, typically including a name, title, description, and possibly other fields. In one embodiment, when a shape has a style set, the value for the style's field is applied to the shape unless the field is overridden and animated. Style sets can be editionable and versionable.

Thus, as discussed above, the composition system supports a robust set of visual or graphic items, each defined by a respective object. A set of visual or graphic items is, for example, one or more display definitions, dashboards, layouts, GEM definitions, gadget definitions, global sets, built-in shape definitions, group definitions, display definitions, shape usage, group usage, dynamos , GEM Usage, Gadget Usage, Chrome Usage, Region Usage, Panel Usage, Junction Points, Connectors, Animations, Transformers, Event Triggers, Event Handlers, Placeholders, Parameters, Functions, Tables, Name Sets, Styles , and/or style sets. At least a portion of the set of visuals or graphic items may be created or modified by a user.

Furthermore, the objects that define each visual or graphic item are e.g. fields, event triggers, functions, display definitions, event handlers, animations, placeholders, parameters, tables, name sets, transformers, usage of built-in shapes ( GEM Usage(s), Gadget Usage(s), Chrome Usage, Region Usage, Group Usage, Dynamo, Panel Usage, Junction Points, Connectors, Global Sets, Style Sets and/or one or more internal items such as styles. Each of the internal items defined in the visual or graphic item object may be built into the configuration system, added by the user, or configured by definition or by reference to another item.

Changes, fixes and tweaks:

As previously discussed, a user can change, modify, or fine-tune the content of an object definition. That is, a user can modify one or more internal items of an object while maintaining links to the definitions on which each is based. These changes, modifications, and tweaks may include, for example, additions, deletions, and/or modifications to the object's content (eg, fields or other internal items). Furthermore, these changes, when published in an edition, generally supersede the object's underlying definition, and that future changes from the modified definition apply when a new edition is propagated. can enable For example, if an item (eg, GEM) included in the definition is modified and fine-tuned in usage or derived representations, fine-tuning takes precedence. However, if an item is deleted from the underlying definition, usage or tweaks to the derived definition are lost. For example, an item (eg, GEM) that was included in the underlying definition is deleted but was previously tweaked in the usage or derived definition. Fine tuning is lost in this embodiment. Furthermore, if an item (e.g., GEM) contained in the underlying definition is modified but deleted in the usage or derived definition, the change to the underlying definition is not propagated to the usage or derived definition. .

In one embodiment, fine-tuning on specifier object usage may be pushed back to the underlying definition, in one embodiment. In one embodiment, the underlying definition is updated to a new edition that includes the tweaks made to the child, and the tweaks are removed from the child.

Figures 19-21 show examples of modifications or tweaks that can be made to various visual items and objects. In particular, FIG. 19 shows an illustration of field value override refinements applied to usage patterns. In FIG. 19, the width field value 1090a and height field value 1090b are overridden.

FIG. 20 shows an example of field value override refinements applied to derived patterns. In FIG. 20, the width field value 1092a and height field value 1092b are overridden.

FIG. 21 shows an example of multiple modifications or tweaks to an object at multiple levels. In particular, Figure 21 shows how tweaks applied to lower definitions become default values for the next level (e.g. references 1095a-1095c), and how values are overridden at multiple levels. (eg, references 1098a, 1098b) and how overrides on the outermost definition take precedence (eg, reference 1100).

As shown in FIGS. 19-21, in one embodiment, fine tuning may be performed on usage patterns and derivative patterns. Additionally, tweaks or modifications may be made to configuration items or objects and/or visual or graphic items or objects. For example, the set of visual or graphic items that can be fine-tuned is one or more of display definitions, dashboards, layouts, GEM definitions, gadget definitions, global sets, built-in shape definitions, group definitions, display definitions, shape usage, group usage, dynamo, GEM usage, gadget usage, chrome usage, area usage, panel usage, connection points, connectors, animations, transformers, event triggers, event handlers, placeholders, parameters, functions, tables, May include name sets, styles, and/or style sets. Further fine-tuning includes fields, event triggers, functions, display definitions, event handlers, animations, placeholders, parameters, tables, name sets, transformers, built-in shape usage(s), GEM usage(s). Yes), gadget usage(s), chrome usage, region usage, group usage, dynamos, panel usage, connection points, connectors, global sets, style sets and/or other objects such as styles. It can be performed on one or more objects included in the definition.

When embodied, any of the methods and techniques described in or part of this specification can be stored on a magnetic disk, laser disk, optical disk, semiconductor memory, in the RAM or ROM of a computer or processor. It may be implemented by executing software stored in one or more non-transitory tangible computer-readable storage media or memory, such as other memory devices or other storage media. In one embodiment, any of the methods and techniques described herein or a part thereof is a configurator or flexible configurator (eg, one or more configuration applications or other suitable applications). can be performed by A configurator may be communicatively coupled to a data storage device and one or more configurable elements included in a process plant or process control system. A configurator is one or more tangible and non-tangible instructions that computer-executable instructions may be executable to implement any of the methods and techniques described herein or a part thereof. It may include computer-executable instructions stored in temporary memory or a computer-readable storage medium.

While the foregoing text discusses a detailed description of a number of different embodiments, it is intended that the scope of this patent be defined by the language of the claims discussed at the end of this patent and equivalents thereof. be understood. The detailed description should be construed as merely exemplary and does not describe every possible embodiment because it would be unreasonable, if not impossible, to describe every possible embodiment. . Numerous alternative embodiments, using either current technology or technology developed after the filing date of this patent, still come within the scope of the claims and all equivalents thereof. , can be implemented. By way of example and not limitation, the present disclosure contemplates at least the following aspects.

A method of configuring a process plant comprising receiving a first user input indicating modifications to current process element objects for specified elements of the process plant, the specified elements being controlled in the process plant. receiving, corresponding to one or more processes, modifying the current process element object based on the first user input to generate a modified process element object for the specified element; delaying instantiation of the modified process element object until a specified time indicated by a second user input; causing instantiation of the modified process element object to operate during runtime according to the modified process element object to provide control or display functionality.

The method of the preceding aspect, wherein receiving a first user input indicating a modification to the current process element object indicates a modification to the current instance object from which the set of current process element objects is created. receiving an input, wherein the set of current process element objects includes a current process element object for the specified element and a current instance object created from the class object; modifying the current instance object to produce a modified instance object based on user input indicating modification of the process; modifying the set of current process element objects based on the modified instance object; The method further comprising:

The method of any of the preceding aspects, wherein the current instance object is the first current instance object, the modified instance object is the first modified instance object, and the present The method is based on user input indicating modifications to the first current instance object to modify the second current instance object to generate a second modified instance object, comprising: 2. The method further comprising modifying, wherein the current instance object is created from the class object.

The method of any of the preceding aspects, wherein the second current instance object is based on the first current instance object.

The method of any of the preceding aspects, wherein the specified time is a first specified time, and the set of current process control element objects is the first set of current process control element objects. and the method causes instantiation of the first set of current process control element objects at a first specified time; and a second specified time different from the first specified time. causing instantiation of a second set of current process control element objects corresponding to the second modified instance object at the fixed time.

The method of any of the preceding aspects, wherein the first current instance object is indicated by the user, the second current instance object is indicated by the user, or the first specified The method, wherein at least one of the time is indicated by the user, or a second specified time is indicated by the user.

The method of any of the preceding aspects, wherein maintaining the alternate current process element object includes not modifying the alternate current process element object based on user input indicating modifications to the current instance object. wherein another current process element object is excluded from the set of current process element objects based on the class object and corresponding to the current instance object.

The method of any of the preceding aspects, further comprising propagating modifications to current instance objects to class objects.

The method of any of the preceding aspects, wherein receiving first user input indicative of modifications to the current process element object is user input indicative of modifications to the class object on which the current process element object is based. a method comprising receiving a

The method of any of the preceding aspects, wherein the current process element object is the first current process element object and the modified process element object is the first modified process element object and the method further comprises modifying the second current process element object based on the first user input to generate a second modified process element object; The process element object of the method is based on the class object.

The method of any of the preceding aspects, wherein the specified time is a first specified time, and the method performs a second specified time different from the first specified time. The method further comprising, in time, causing instantiation of a second modified process element object.

The method of any of the preceding aspects, wherein at least one of the first current process element objects is created from the first instance object or the second current process element object is created from the second A method created from two instance objects, a first instance object and a second instance object created from a class object.

The method of any of the preceding aspects, wherein the current process element object is the first current process element object and the modified process element object is the first modified process element object and the method further comprising not modifying the second current process element object based on the first user input, wherein the second current process element object is based on the class object.

The method of any of the preceding aspects, wherein the second current process element object is indicated by the user.

The method of any of the preceding aspects, wherein receiving the first user input indicating modifications to the current process element object includes adding to the content of the current process element object; deleting at least a first portion of the content of the object; invalidating at least a first portion of the content of the current process element object; or invalidating at least a second portion of the content of the current process element object; to enable the disabled contents of the current process element object, to change the values contained in the current process element object, to change the references contained in the current process element object, to change the current process element object to A method comprising at least one of renaming or resolving references contained in the current process element object.

The method of any of the preceding aspects, wherein receiving the first user input indicating modifications to the current process element object for the specified element is for one of the control module or the display module. receiving a first user input indicating a modification to the current process element object of the .

The method of any of the preceding aspects, wherein storing the modified process element object as a draft modified process element object; and causing instantiation of the modified process element object comprises causing instantiation of the public modified process element object. ,Method.

The method of any of the preceding aspects, wherein the modified process element object is the first modified process element object, and the method applies the current process element object or the first modified receiving a third user input indicating another modification to one of the process element objects; and modifying the current process element according to the third user input to generate a second modified process element object. modifying one of the objects or the first modified process element object.

The method of any of the preceding aspects, wherein storing the modified process element object as a draft modified process element object comprises storing the first draft modified process element object as a first draft modified process element object. storing the modified process element object, the method further comprising storing the second modified process element object as a second draft modified process element object.

The method of any of the preceding aspects, wherein receiving user instructions to publish the draft modified process element objects receives user instructions to publish the selected draft modified process element objects. method, including

The method of any of the preceding aspects, wherein the user request compares at least two of the current process element object, the draft revised process element object, and the published revised process element object. and displaying on a user interface the comparison corresponding to the user request.

The method of any of the preceding aspects, comprising: receiving an indication of a selection of a set of objects to be included in the draft package; storing the indication of the draft package; and generating the published package. and causing instantiation of a set of process element objects corresponding to objects included in the published package.

The method of any of the preceding aspects, wherein the set of objects includes at least one of class objects, instance objects, library objects, or process element objects.

The method of any of the preceding aspects, wherein the draft package is a first draft package and the method receives third user input indicating modifications to the first draft package. modifying the first draft package according to a third user input; and storing the modified first draft package as a second draft package; receiving user instructions to publish the draft package to generate a published package includes receiving user instructions to publish the selected draft package to generate the published package.

A method of configuring a process plant, comprising: receiving user input indicating modifications to current class objects corresponding to one or more processes controlled in the process plant; propagating modifications to each current object of a first subset of the current set of objects created from the class object and a second subset of the current set of objects created from the class object, such as creating Not Propagating Modifications to Subsets and Process Element Objects Each First Set of Process Elements Modified to Provide Control or Display Functions Related to One or More Processes Controlled in a Process Plant causing the instantiation of a first set of modified process element objects corresponding to the first subset of modified objects to operate at runtime according to a first set of each of the process elements; A second set of current objects to operate at runtime according to a second subset of the current objects to provide control or display functionality related to one or more processes controlled in the process plant. maintaining instantiations of a second set of current process element objects corresponding to the second subset.

The method of any of the preceding aspects, comprising receiving at least one of an indication of a user selection of a first subset of current objects or a user selection of a second subset of current objects. Further comprising a method.

The method of any of the preceding aspects, wherein the first subset of current objects includes a first current instance object created from a current class object; the subset includes a second current instance object created from the current class object, the first subset of current objects includes a first current process element object having a definition based on the current class object; or wherein the second subset of current objects includes a second current process element object having a definition based on the current class object.

The method of any of the preceding aspects, further comprising maintaining a correction indication.

The method of any of the preceding aspects, wherein receiving user input indicative of modifications to the current class object comprises: adding to the contents of the current class object; deleting a portion of one, invalidating at least a first portion of the contents of the current class object or invalidating at least a second portion of the contents of the current class object; Validate content, change the values contained in the current class object, change the references contained in the current class object, rename the current class object, or a method comprising at least one of: decoding a reference that is

The method of any of the preceding aspects, wherein each current object of a third subset of the set of current objects created from the class object to create a third subset of modified objects. the method further comprising communicating the modification to the In one embodiment, each current object that contains propagated modifications may be renamed.

The method of any of the preceding aspects, wherein the user input is the first user input, and the method is performed on the modified process element object until the specified time indicated by the second user input. The method further comprising delaying instantiation of the set of 1's.

The method of any of the preceding aspects, wherein the specified time is a first specified time, and the method performs a second specified time different from the first specified time. The method further comprising, until a time, delaying instantiation of a third set of modified process element objects corresponding to a third subset of the current set of objects.

The method of any of the preceding aspects, wherein each first set of process elements includes at least one of a display module or a control module.

A method of configuring a process plant, comprising: receiving user input indicating modifications to current instance objects created from class objects corresponding to one or more processes controlled in the process plant; modifying the current instance object to generate a modified instance object, and modifying the current instance object based on the modified instance object to generate a first set of modified process element objects. Modifying a first set of current process element objects created from instance objects and controlling or displaying each first set of process elements pertaining to one or more processes controlled in a process plant causing instantiation of the first set of modified process element objects to operate during runtime according to the first set of process element objects modified to provide functionality; transmitting the modification to another set of objects so as to generate a set of objects, the other set of objects being based on the class object; modified to operate during runtime according to a second set of process element objects, the set of which is modified to provide control or display functions relating to one or more processes controlled in the process plant causing instantiation of a second set of modified process element objects corresponding to the set of other objects.

The method of any of the preceding aspects, wherein the current instance object is a first current instance object and propagating the modification to the set of other objects is the first created from the class object. A method that includes propagating modifications to two current instance objects.

The method of any of the preceding aspects, further comprising not propagating the modification to a third current instance object created from the class object.

The method of any of the preceding aspects, wherein communicating the fix to the set of other objects includes communicating the fix to the class object.

The method of any of the preceding aspects, further comprising maintaining a correction indication.

The method of any of the preceding aspects, further comprising not modifying the third set of current process element objects based on the modification class object, wherein the third set of current process element objects is , based on the class object and indicated by the user.

The method of any of the preceding aspects, wherein propagating the modification to the set of other objects comprises propagating the modification to another object created based on the current instance object. .

The method of any of the preceding aspects, wherein the another object is one of the process element objects created from another instance object or the current instance object.

The method of any of the preceding aspects, further comprising receiving an indication of user selection of a set of other objects.

The method of any of the preceding aspects, further comprising not modifying the third set of current process element objects based on the modified instance objects; A method in which the set is based on the current instance object and indicated by the user.

The method of any of the preceding aspects, wherein the user input is the first user input, and the method is performed on the modified process element object until the specified time indicated by the second user input. The method further comprising delaying instantiation of the set of 1's.

The method of any of the preceding aspects, wherein the specified time is a first specified time, and the method performs a second specified time different from the first specified time. The method further comprising delaying instantiation of the second set of modified process element objects until time.

The method of any of the preceding aspects, wherein receiving user input indicating a modification to the current instance object comprises: adding to the content of the current instance object; deleting one portion, invalidating at least a first portion of the contents of the current instance object or invalidating at least a second portion of the contents of the current instance object; Validating content, changing values contained in the current instance object, changing references contained in the current instance object, renaming the current instance object, or changing the values contained in the current instance object a method comprising at least one of: decoding a reference that is

The method of any of the preceding aspects, wherein each first set of process elements includes at least one of a control module or a display module.

The method of any of the preceding aspects, further comprising renaming any modified objects.

A method of configuring a process plant comprising receiving user input indicating modifications to current process element objects for specified elements of the process plant, wherein the specified elements are one or more controlled in the process plant. and modifying the current process element object based on user input to generate a modified process element object for the specified element and the draft modified process further comprising storing the modified process element objects as element objects; and receiving user instructions to publish the draft modified process element objects to produce published modified process element objects. , the specified element operates during runtime according to the published modified process element object to provide control or display functionality for one or more processes controlled in the process plant. A method comprising: causing an instantiation of a process element.

The method of any of the preceding aspects, wherein the user input is the first user input and the modified process element object is the first modified process element object, the method comprising: receiving a second user input indicating another modification to one of the current process element object or the first modified process element object; and generating a second modified process element object. and modifying one of the current process element object or the first modified process element object according to the second user input to.

The method of any of the preceding aspects, wherein storing the modified process element object as a draft modified process element object comprises storing the first draft modified process element object as a first draft modified process element object. storing the modified process element object, the method further comprising storing the second modified process element object as a second draft modified process element object.

The method of any of the preceding aspects, wherein receiving user instructions to publish the draft modified process element objects receives user instructions to publish the selected draft modified process element objects. method, including

The method of any of the preceding aspects, wherein the user request compares at least two of the current process element object, the draft revised process element object, and the published revised process element object. and displaying on a user interface the comparison corresponding to the user request.

The method of any of the preceding aspects, wherein storing a plurality of draft modified objects of the process plant as a package of drafts, wherein the plurality of draft modified objects is a draft modification receiving user instructions to publish the draft package to produce a published package; and storing the published modified objects included in the published package. Publishing at least a subset of the modified objects of the plurality of drafts to produce a set, and one or more process element objects corresponding to the set of modified objects that have been published are controlled in the process plant causing the instantiation of the set of modified exposed objects to operate during runtime according to the set of modified objects exposed to provide control or display functionality related to the process of The method further comprising:

The method of any of the preceding aspects, wherein storing a plurality of draft modified objects comprises a draft class object or a draft instance created from the draft class object or another class object. A method comprising storing a plurality of draft modified objects including at least one of the objects.

The method of any of the preceding aspects, further comprising receiving an indication of selection of a plurality of draft modified objects.

The method of any of the preceding aspects, wherein the draft package is a first draft package and the method receives another user input indicating modifications to the first draft package. and modifying the first draft package according to another user input; and storing the modified first draft package as a second draft package; receiving user instructions to publish the draft package to generate the includes receiving user instructions to publish the selected draft package to generate the published package.

The method of any of the preceding aspects, wherein receiving user input indicative of modifications to the current process element object comprises receiving user input indicative of modifications to the current instance object upon which the current process element object is based. receiving user input indicating modifications to the current class object on which the current process element object is based.

Apparatus configured to perform any of the preceding methods or any combination of the preceding methods.

Therefore, in light of the above, the techniques, systems, methods, apparatus, and devices discussed herein provide real-time Its behavior and/or behavior in a controlled manner over time allowing changes to module classes and other parent objects to be integrated into a process plant or process control system so that its behavior is not adversely affected to change Additionally, the changes are additionally applied to the process elements of the process plant or system (instead of waiting until a time when all process elements corresponding to the child objects of the modified parent object to be updated, for example). or may be performed in stages, thereby reducing the occurrence of unnecessary delays in applying changes to portions of the process plant or process control system (or, in some cases, the entire plant or system); Over time, increase the overall efficiency and productivity of the process plant or system.

Furthermore, the techniques, systems, methods, apparatus, and devices discussed herein are useful for drafting modifications or changes to parent and/or child objects that they may be processed in a process plant or control system run-time environment. Allows approval before being applied or instantiated on an element (whether from modified parent object or modified child object). Therefore, the probability of incomplete or inaccurate modifications or changes being inadvertently incorporated into a plant or system is greatly reduced, and accuracy is improved in changes being integrated into a process plant or system, thereby increasing the process plant Or increase the quality, efficiency and safety of system operation.

Furthermore, the techniques, systems, methods, apparatus, and devices discussed herein with respect to graphical elements and displays may enable process plants or process control systems to more safely and efficiently monitor, control, and/or operate in real-time. allow to be In particular, an operator may be specifically adapted or customized for the specific monitoring, control, and/or operation of one or more portions of a process control system or plant in both the plant's real-time or run-time operating and configuration environments. configurable graphical elements and/or displays. Additionally or alternatively, one or more of the graphical elements and/or displays are specifically adapted or customized for a particular operator, group of operators, organizational entity, business, or other entity. obtain. Operators can save these customized graphical elements and/or displays for general (eg, plant-wide or system-wide, real-time or configuration) access, use, reuse, and integration. Therefore, operator confusion and errors are reduced as the configuration of the graphic element(s) and/or graphic display(s) is streamlined and customized in multiple environments, thereby enabling the operator to efficiently and safely process Make a plant or system operational.

Still further, because the graphical element(s) and/or display(s) are customized for the specific purpose of a specific part or entity of a process plant or system (e.g., one or more process Real-time data generated by a unique part or entity of a process plant or system (while controlling the ) is easily and rapidly identifiable with In some cases, data, configurations, and/or instructions associated with an intervention and delivered to a process plant or system result in changes to the process plant or system (e.g., updated or new configurations to process elements). Or bring changes to their behavior. In some cases, the delivered data, configurations, and/or instructions cause the process plant or control system to perform actions (e.g., remove certain process elements from operation, replace data generated by sources). source, etc.). Accordingly, the techniques, methods, and systems described herein provide graphical elements and/or displays with more customized and detailed information (and particularly in relation to real-time data generated by a process plant or system). any necessary modifications to the control and/or operation of one or more parts of the process plant or process control system are determined more rapidly and at the runtime of the process plant or control system. Be integrated with the environment. Thus, using the techniques, methods, and systems described herein, the efficiency and safety of process plants or systems are further improved.