Controlled rollout of module classes
The controlled rollout of module classes in process plants addresses the challenge of simultaneous upgrades by allowing selective and staged upgrades, enhancing flexibility and reducing risk and resource constraints.
Patent Information
- Application Number
- JP2023108445
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2017-08-08
- Filing Date
- 2023-06-30
- Publication Date
- 2025-04-01
- Estimated Expiration
- 2038-08-06
AI Technical Summary
Current process plant configurations require a one-to-one mapping between module classes and instances, leading to challenges when upgrading hardware, as all instances must be updated simultaneously, which can be resource-intensive and risky, especially when budget or resource constraints are involved.
A module-based system and method for a controlled rollout of a module class, allowing for the generation of a second version of a module class based on modifications to the first version, enabling selective upgrades of process control elements while ignoring unupgraded elements, thus maintaining a phased rollout state.
This approach allows for staged upgrades of process control elements, reducing the risk of system instability and resource overload, while enabling more flexible and economical management of process plant configurations.
Smart Images

Figure 0007654718000001 
Figure 0007654718000002 
Figure 0007654718000003
Abstract
Description
[Technical field]
[0001] The present invention relates generally to process plants, and more particularly to the controlled roll-out of a class of modules for configuring a process plant. [Background technology]
[0002] Distributed process control systems, typically used in power generation, chemical manufacturing, oil refineries, industrial manufacturing or other types of plants, typically include one or more process controllers communicatively coupled to a number of field devices via analog, digital, or combined analog / digital, or via a wireless bus. The field devices, which may be, for example, valves, valve positioners, switches, transmitters (e.g., temperature, pressure, level, and flow rate sensors), burners, heat exchangers, furnaces, etc., are located within the plant environment and perform process functions, such as opening or closing valves, measuring process parameters, etc., in response to control signals deployed and sent by the controller. Smart field devices, such as field devices conforming to any of the well-known Fieldbus protocols, may also perform control calculations, alarm functions, and other functions typically implemented in or by a plant controller. A plant controller is also typically located within the plant environment and executes a controller application that executes different control modules that receive signals indicative of process measurements made by the field devices and / or other information relating to the field devices, e.g., make process control decisions and generate process control signals based on the received information, and interface with the control modules or blocks implemented in the field devices, such as HART™ and FOUNDATION™ based Fieldbus field devices. The control modules within the controller send the process control signals over communication lines or networks to the field devices, thereby controlling the operation of the process.
[0003] Information from the field devices and controllers is usually made available over a data highway to one or more other computing devices, such as operator workstations, personal computers, data historians, report generators, centralized databases, etc., that are typically located in a control room or other location away from the more hostile plant environment. These computing devices may run applications that may enable operators to perform functions related to the process, such as, for example, changing settings on process control routines, modifying the operation of control modules in the controllers or field devices, viewing the current state of the process, viewing alarms generated by the field devices and controllers, maintaining and updating configuration databases, etc.
[0004] As an example, the OVATION™ control system, sold by EMERSON PROCESS MANAGEMENT, includes multiple applications stored in and executed by different devices located at various locations within a process plant. Configuration applications residing in one or more operator workstations allow users to create or modify process control modules and download these process control modules over a data highway to a dedicated distributed controller. Typically, these control modules are composed of communicatively interconnected function blocks, which are objects in an object-oriented programming protocol that perform functions within a control scheme based on inputs thereto and provide outputs to other function blocks in the control scheme. The configuration applications also allow designers to create or modify operator interfaces used by a viewing application to display data to an operator, and the configuration applications allow designers to view and modify the operator interfaces used by a viewing application to view and display data to an operator. The data highway may allow the operator to change settings such as set points in the process control routines. Each of the dedicated controllers, and in some cases each of the field devices, stores and executes a controller application that executes the control modules assigned to and downloaded to them to implement the actual process control functions. A viewing application may run on one or more operator workstations, receiving data from the controller applications over the data highway and displaying this data to a process control system designer, operator, or user using a user interface. The data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided over the data highway, while a configuration database application may run on a more remote computer connected to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.
[0005] Currently, a process plant can be made up of module classes and their respective module objects (also known as module instances). A "module class" is a template for a particular type of module, e.g., a control module. A "module instance" of a class is effectively instantiated from, and thus a "child" of, its parent module class.
[0006] A module instance may correspond to a particular element in a process control system. For example, a valve class may have many valve instances, where each instance corresponds to a unique valve in a process plant. A module instance lives in computer memory and may store data about the valve and / or perform functions to control the valve. In existing implementations, as described, for example, in U.S. Pat. No. 7,043,311, entitled "Module Class Objects in a Process Plant Configuration System," module instances may each be created from a respective module class object, where the module object is said to be associated with and owned by the module class.
[0007] In current systems, a one-to-one mapping is maintained between a module class and instances of that module class for use within the process plant. In current systems, for a given module class, multiple live versions of a module instance cannot exist. Thus, when a modification is made to a class, all child module instances must be modified as well, and thus, all module instances for a module class are immediately affected by the change to the module class. As a result, any new module instance instantiated for a module class, or any change made to a module class, is automatically reflected and propagated to each of the module instances associated with that module class object. As explained by U.S. Pat. No. 7,043,311, when numerous module instances are created from a particular module class, where each of the different module instances is bound to a different process entity, each of the different module instances is automatically modified by simply invoking a change to the module class. For example, the change is automatically propagated to the associated module instances within the process plant.
[0008] However, this is particularly true within a process plant, including process plants that contain, for example, numerous different types or configurations of field devices, process control elements, e.g., CHARMs, position switches, etc. This can create problems in a process plant that includes hardware of different configurations. For example, if an operator, e.g., an engineer, of the process plant wants to upgrade the hardware of the process plant, if the new hardware requires a new module class and thus a new module instance each (e.g., to control the new hardware), then in order to maintain a one-to-one mapping for all similar hardware in the plant, the operator would need to immediately update and install all the new version of the hardware and remove all of the old hardware and its respective module instances associated with the old module class. On the one hand, such a procedure would ensure that all of the new module instances are of the same version and thus maintain a one-to-one mapping between the new module class and the new module instance for the new hardware. However, on the other hand, there may be insufficient budget or resources to purchase and install all such hardware at once.
[0009] In current implementations, to address this challenge, engineers may be forced to install some, but not all, of the new hardware. However, such implementations are undesirable because they break the one-to-one relationship between the hardware class and its instances. For example, such implementations require new module instances to accommodate the new hardware, requiring different module classes for different hardware configurations, in which case the engineer is forced to actually break class linkages to phase in the new module classes and associated instances over time. In this way, similar hardware may have different classes that cause version control breaks for similar hardware, devices, elements, etc. in the plant, thereby making the overall configuration, maintenance, and maintainability of the plant less effective and potentially dangerous.
[0010] As an example, a process plant may be associated with a valve class, where the valve class may have over 100 instances corresponding to hardware valves located within the process plant. In this example, the logic of the valve class may need to be modified to accommodate new values, new features, or new use cases within the process plant. Because the valve class has over 100 valve instances, the implementation of changes to the instances must be synchronized with the installation of new hardware (e.g., including associated cables) over time. According to current practice, changes to the valve class immediately affect all of the respective valve instances, where the change causes the new valve instance to be automatically downloaded to all valves associated with a given value class in the existing online system. However, downloading a new valve instance to old valve hardware may cause the logic of the old valve module to function incorrectly, creating problems, malfunctions, and possibly dangerous situations within the process plant.
[0011] In current implementations, to address this, an engineer must first break the one-to-one mapping, which is the class coupling between the valve class and that valve class instance to any hardware that runs the valve instance that the engineer does not want affected before changing the class. As mentioned earlier, this is undesirable, especially in a validated plant, because those uncoupled instances are now autonomous and their logic can be changed arbitrarily. This creates version control issues that can be difficult to manage, track, and ultimately dangerous to the process plant. Furthermore, this situation also creates additional overhead for the control engineer to keep track of the uncoupled instances, introducing confusion and errors.
[0012] In some cases, an engineer can create a new dummy module class and connect / disconnect one instance at a time to the new dummy module class to implement the desired changes over time. However, this second approach not only takes a long time, but also creates an administrative burden and can introduce confusion and errors, especially when multiple engineers are responsible for configuring and maintaining the process plant. Summary of the Invention
[0013] To overcome the aforementioned problems, a module-based system and method for controlled roll-out of a module class for configuring a process plant is described. In various embodiments, the module-based system and method may include one or more processors configured to generate a second version of the module class based on a modification of a first version of the module class. In some embodiments, the module class may be a derived module class, where the derived module class inherits properties or functionality of a parent module class.
[0014] In some embodiments, a module class may be associated with one or more module instances, which may each be associated with a process control element of a process plant. The process control elements may include a field device or a portion of a field device, including, for example, a valve.
[0015] A second version of a module class may correspond to a changed process control element of a process plant, including, for example, a hardware change in which one process control element is replaced with another process control element.
[0016] In some embodiments, modifications to the first version of the module class may include adding one or more inputs (e.g., feedback inputs) to the module class, where the one or more inputs may be accessed to facilitate at least partial control of the upgraded process control element.
[0017] In various embodiments, the module-based systems and methods are operable to execute roll-out instructions. The roll-out instructions may include routines for updating one or more upgraded process control elements, where the upgraded process control elements are each associated with a new module instance based on the second version of the module class. The roll-out instructions may also be implemented to ignore, e.g., skip, one or more non-upgraded process control elements, where the non-upgraded process control elements remain each associated with a previous module instance based on the first version of the module class. For example, the roll-out instructions may be implemented via a selective upgrade routine, where the selective upgrade routine associates the upgraded process control elements with a new module instance based on the second version of the module class. The selective upgrade routine may be implemented to simply ignore or skip the non-upgraded process control elements, whereby the non-upgraded process control elements are not associated with any second new module instance based on the second version of the module class.
[0018] In some embodiments, the rollout instructions may be executed immediately, while in other embodiments, the rollout instructions may be executed at a scheduled time.
[0019] In an additional embodiment, once the rollout command is executed, the upgraded In one embodiment, the upgraded and non-upgraded process control elements may each be used together to control at least a portion of the process plant. In such an embodiment, the process plant is at least partially controlled by different versions, e.g., a first version and a second version of the same module class that include simultaneous versions.
[0020] Module-based systems and methods may be configured to track one or more module instances via a module configuration record. In some embodiments, the module configuration record may indicate a module class version for each of the one or more module instances. The module configuration record may also indicate that the module class has a phased rollout state.
[0021] In some embodiments, the module-based systems and methods may be further configured to prevent additional upgrades of a module class when the module configuration record indicates that the module class has a phased rollout state.
[0022] In other embodiments, the upgraded process control elements may be included in an upgraded process control element set that defines each process control element associated with a new module instance of the second version of the module class. The upgraded process control element set may be created when the rollout instructions are executed. In certain embodiments, the upgraded process control element set may be a subset of all process control elements of the process plant.
[0023] In some embodiments, a selection of process control elements for inclusion in the upgraded process control element set may be received by a module-based system and method, including, for example, via a graphical interface that allows an operator to select which process control elements to include in the upgraded process control element set.
[0024] For example, in some embodiments, selecting the set of upgraded process control elements may include selecting process control elements associated with a particular derived module class, in other embodiments, selecting the set of upgraded process control elements may include selecting process control elements associated with a particular hierarchy of the process plant, and in yet further embodiments, selecting the set of upgraded process control elements may include selecting process control elements associated with a physical area of the process plant.
[0025] In various embodiments, additional rollout instructions may be executed that apply configuration changes to the new module instance based on the second version of the module class and to the previous module instance based on the first version of the module class. The configuration changes may include additional modifications applied to each of the second version of the module class and the first version of the module class, for example, to apply a patch or quick fix to the module class as a whole. For example, in one embodiment, the additional modifications may add computing functionality to each of the second version of the module class and the first version of the module class to increase functionality of the module class across both versions.
[0026] The advantages will become more apparent to those skilled in the art from the following description of the preferred embodiment, which has been shown and described for purposes of illustration. As will be understood, the present embodiment may be capable of other different embodiments, and its details may be modified in various respects. Accordingly, the drawings and description are to be regarded as illustrative in nature, and as restrictive. It's not something like that. [Brief description of the drawings]
[0027] The drawings described below illustrate various aspects of the systems and methods disclosed herein. It should be understood that each drawing illustrates an embodiment of a particular aspect of the disclosed systems and methods, and that each of the drawings is intended to correspond to a possible embodiment thereof. Furthermore, wherever possible, the following description will refer to reference numerals contained in the following drawings, in which features illustrated in multiple drawings will be designated with consistent reference numerals.
[0028] The figures show configurations which are currently being described; however, it is understood that the present embodiments are not limited to the precise configurations and manner in which they are shown.
[0029] [Figure 1] FIG. 1 is a block diagram of one embodiment of a distributed process control network located within a process plant, including an operator workstation implementing a configuration application for controlled roll-out of module classes for configuring the process plant. [Diagram 2] 1 illustrates one embodiment of a first configuration screen that may be used to modify a first version of a module class in accordance with various embodiments herein. [Diagram 3] 3 is a diagrammatical illustration of an embodiment of the configuration screen of FIG. 2 showing a second version of the module class from FIG. 2. [Figure 4] 4 is an illustration of one embodiment of the configuration screen of FIG. 3 showing process control elements selected to be associated with a new module instance of a second version of the module class from FIG. 3. [Diagram 5] FIG. 4 is an illustration of one embodiment of the configuration screen of FIG. 3 showing a process control element selected based on a particular derived class, where the selected process control element is associated with a new module instance of a second version of the module class from FIG. 3. [Figure 6] 4 is an illustration of an embodiment of the configuration screen of FIG. 3 showing new module instances of a second version of the module class from FIG. 3 rolled out to process control elements within a process plant. [Figure 7] 11 illustrates an embodiment of the configuration screen of FIG. 3 showing additional rollout instructions that apply configuration changes to new module instances based on a second version of the module class and to previous module instances based on a first version of the module class. [Figure 8] 8 is an illustration of one embodiment of the configuration screen of FIG. 7 showing a rollout confirmation screen for executing additional rollout instructions. [Figure 9] 1 illustrates an embodiment of a configuration screen showing module instances associated with a particular type of process control element of a process plant. [Figure 10] 2 illustrates one embodiment of a controlled rollout of module classes for configuring the process plant of FIG. 1.
[0030] The drawings depict preferred embodiments for purposes of illustration only. Alternative embodiments of the systems and methods illustrated herein may be used without departing from the principles of the invention as described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0031] Description of the Preferred Embodiments FIG. 1 is a block diagram of one embodiment of a distributed process control network located within a process plant, including an operator workstation implementing a configuration application for controlled rollout of module classes for configuring the process plant. In the embodiment of FIG. 1, the process plant 10 includes one or more process controllers 12 coupled to a number of workstations 14, for example, via an Ethernet connection or bus 15. The controllers 12 are also coupled to devices or equipment within the process plant 10 via a set of communication lines or buses 18, of which only the set of communication lines 18 connected to the controller 12a is shown in FIG. 1. The controllers 12, which may be implemented, by way of example only, using OVATION™ controllers sold by Fisher-Rosemount Systems, Inc., may communicate with field devices distributed throughout the process plant 10 and control elements, such as function blocks within the field devices, to execute one or more process control routines 19, thereby implementing the desired control of the process plant 10. The workstations 14, which may be, for example, personal computers, may be used by one or more configuration engineers to design the process control routines 19 executed by the controllers 12 and display routines executed by the workstations 14 or other computers, and to communicate with the controllers 12 to download such process control routines 19 to the controllers 12 and 12a. Additionally, the workstation 14 may execute display routines that receive and display information pertaining to the process plant 10 or elements thereof during operation of the process plant 10 .
[0032] Each of the workstations 14 includes memory 20 for storing applications, such as configuration design applications and display or viewing applications, as well as for storing data, such as configuration data pertaining to the configuration of the process plant 10. Each of the workstations 14 also includes a processor 21 for executing applications to enable a configuration engineer to design process control routines and other routines and download those process control routines to the controller 12 or to other computers, or to collect information and display it to a user during operation of the process plant 10.
[0033] Further still, each of the controllers 12 includes a memory 22 that stores control and communication applications, as well as a processor 24 that executes the control and communication applications in any known manner. In one case, each of the controllers 12 stores and executes a controller application that implements a control strategy using a number of different, independently executing control modules or blocks 19. The control modules 19 may each be comprised of what are generally referred to as function blocks, each of which is a portion or subroutine of an overall control routine and operates in conjunction with other function blocks (through communications called links) to implement a process control loop within the process plant 10.
[0034] As is known, a function block may be an object within an object oriented programming protocol, but typically performs one of the following functions: an input function, such as associated with a transmitter, sensor, or other process parameter measurement device, a control function, such as associated with a control routine that performs control, such as PID, fuzzy logic, or the like, or an output function that controls the operation of some device, such as a valve, to perform some physical function within the process plant 10. Of course, hybrid and other types of composite function blocks exist, such as model predictive controllers (MPCs), optimizers, etc. Although the Fieldbus protocol and the OVATION™ System protocol use control modules and function blocks that are designed and implemented in an object oriented programming protocol, the control modules may be designed using any desired control programming scheme, including, for example, sequential function blocks, ladder logic, etc., and are not limited to being designed using function blocks or any other particular programming technique or programming language.
[0035] The workstation 14 may provide a user with a graphical depiction of the process control routine 19 in the controller 12 via a display screen that illustrates the process control elements within the process control routine 19 and the manner in which these process control elements are configured to provide control of the process plant 10. In the system of Figure 1, a configuration database 25 is connected to the Ethernet bus 15 and may store configuration data used by the controller 12 and the workstation 14, as well as function as a data historian by collecting and storing data generated by the process plant 10 for future use.
[0036] In the process plant 10 illustrated in FIG. 1, the controller 12a is communicatively connected via a bus 18 to three sets of similarly configured reactors, referred to herein as reactor_01, reactor_02, and reactor_03, which are replicated equipment within the process plant 10. The reactor_01 includes a reactor vessel or tank 100, three input valve systems (which are process control elements as equipment entities) 101, 102, and 103 connected to control fluid inlet lines providing acid, alkali, and water, respectively, into the reactor vessel 100, and an outlet valve system 104 connected to control the fluid outflow of the reactor vessel 100. A sensor 105, which may be any desired type of sensor, such as a level sensor, a temperature sensor, a pressure sensor, etc., is disposed in or near the reactor vessel 100. Additionally, a shared header valve system 110 is connected on the water lines upstream of each of the reactors, reactor_01, reactor_02, and reactor_03, to provide a master control for controlling the flow of water to each of these reactors.
[0037] Similarly, reactor_02 includes a reactor vessel 200, three input valve systems 201, 202, and 203, an outlet valve system 204, and a level sensor 205, while reactor_03 includes a reactor vessel 300, three input valve systems 301, 302, and 303, an outlet valve system 304, and a level sensor 305. In the example of FIG. 1, the reactors of reactor_01, reactor_02, and reactor_03 can produce salt by input valve systems 101, 201, and 301 that provide acid, input valve systems 102, 202, and 302 that provide alkali, and input valve systems 103, 203, and 303 that provide water to the reactor vessel 100 in cooperation with a shared water header 110. Outlet valve systems 104, 204, and 304 may operate to direct product out of the flow line oriented to the right in FIG. 1 and to discharge waste or other unwanted materials out of the flow line oriented to the bottom in FIG. 1.
[0038] The controller 12a is communicatively coupled to the valve systems 101-104, 110, 201-204, and 301-304, and the sensors 105, 205, and 305 via the bus 18 to control the operation of these process control elements to perform one or more operations for the reactor units, reactor_01, reactor_02, and reactor_03. Such operations, generally referred to as phases, may include, for example, filling the reactor vessels 100, 200, 300, heating materials in the reactor vessels 100, 200, 300, releasing waste from the reactor vessels 100, 200, 300, cleaning the reactor vessels 100, 200, 300, etc.
[0039] 1 may be any desired kind or type of process control elements, including, for example, Fieldbus devices, standard 4-20Ma devices, HART devices, etc., and may communicate with the controller 12 using any known or desired communication protocol, such as, for example, the Fieldbus protocol, the HART protocol, the 4-20Ma analog protocol, etc. Furthermore, other types of devices may be connected to and controlled by the controller 12 in accordance with the principles described herein. Also, other numbers and types of controllers may be connected within the process plant 10 to control other devices or areas associated with the plant, and the operation of such additional controllers may be coordinated in any desired manner with the operation of the controller 12a illustrated in FIG.
[0040] In general, the process plant 10 of FIG. 1 may be used to implement a batch process in which, for example, one of the workstations 14 or the controller 12a executes a batch execution routine, which is a high-level control routine that directs the operation of one or more of the reactor units (as well as other process control elements or other equipment) to perform a series of different steps (commonly referred to as phases) that are required to produce a product, for example, a particular type of salt. To implement the different phases, the batch execution routine uses what are commonly referred to as recipes, which specify the steps to be performed, the amounts and times associated with the steps, and the sequence of the steps. Steps for a recipe may include, for example, filling a reactor vessel with appropriate materials or ingredients, mixing the materials in the reactor vessel, heating the materials in the reactor vessel to a certain temperature for a certain time, emptying the reactor vessel, and then cleaning the reactor vessel to prepare it for the next batch run. Each of the steps defines a phase of the batch operation, and the batch execution routine in the 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 differ for different recipes, and as a result, these parameters may vary from batch run to batch run depending on the product being manufactured or produced and the recipe being used. Those skilled in the art will appreciate that although the control routines and configurations are described herein for a batch run in the reactor illustrated in Figure 1, the control routines may be used to control other desired devices to perform any other desired batch process run, or to perform a continuous process run, if desired.
[0041] It will also be appreciated that the same phase or step of a batch process may be performed at the same or different times in each of the different reactor units of Figure 1. Furthermore, because the reactor units of Figure 1 generally include the same number and type of equipment, the same generic phase control routine for a particular phase may be used to control each of the different reactor units, except that the generic phase control routine needs to be modified to control different hardware, equipment, or otherwise process control elements associated with the different reactor units. For example, to implement a fill phase for reactor_01 (the reactor unit is filled), the fill control routine opens one or more valves, which are process control elements, associated with input valve systems 101, 102, and 103 for a certain period of time, e.g., until level meter 105 detects that vessel 100 is filled. However, this same control routine can be used to implement a fill phase for reactor_02 by simply changing the designation of the input valve(s) to be associated with valve systems 201, 202, and 203 instead of valve systems 101, 102, and 103, and by changing the designation of the level meter to be level meter 205 instead of level meter 105.
[0042] To make it easier and less time-consuming to create and modify process configurations, one modular control technique that has been developed includes a configuration application 50 that contains a set of module class objects 52 (i.e., module classes) that are used to configure the process control plant 10, stored on one of the workstations 14 of FIG. 1. One example of this technique is described in U.S. Patent No. 7,043,311, entitled "Module Class Objects in a Process Plant Configuration System," the entire disclosure of which is expressly incorporated herein by reference. In particular, U.S. Patent No. 7,043,311 describes a modular class object configuration system that includes a set of module class objects 52 (i.e., module classes) that are used to configure the process control plant 10. 1 illustrates that module class objects 52 are used when configuring a plant having a large set of replicated equipment. Generally, a different module class object 52 may be created for each different type of physical unit or equipment that is replicated or used within the process plant 10, for each type of control activity that is replicated or used within the process plant 10, for each different type of display application that is replicated or used within the process plant 10, etc. Once created, the module class object 52 may be used to configure the process control elements of the process plant 10 that correspond to the module class object.
[0043] Module class objects 52 (referred to herein as module class objects or module classes) are essentially generic versions of process entities and are not tied to any particular process entity, but may have lower level objects or instances 53, 54, 55, and 56 (referred to herein as module objects, module blocks, or module instances) associated with them. Each module instance is created from and based on a module class, and inherits the same structure and properties as the module class from which it is created. Each module object may be tied to a particular entity within the process plant 10. Thus, a single module class 52 may be created to represent a particular type of reactor unit (regardless of how many of those reactor units are present in the plant 10), while different module instances 53 may exist or be created for each of the different reactor units of that type that are actually present in the plant 10.
[0044] In existing implementations, as described, for example, by U.S. Patent No. 7,043,311, module objects created from a module class are associated with and owned by the module class. As a result, any changes made to a module class are automatically reflected in or propagated to each of the module instances associated with that module class. Thus, if many module instances are created from a particular module class, and each of the different module instances is bound to a different process entity, when each of the different module instances is modified, it is simply a matter of modifying the associated module class, and the changes can be automatically propagated down to the associated module instances.
[0045] Essentially, each module class is a configuration container that contains a comprehensive definition of a process entity in the form of all the different control and / or display applications or routines that are applicable to that entity that will be used by the controller 12 to control that entity or by the workstation 14 to perform display activities on that entity. The module classes may represent process entities of any nature, such as units, equipment, control entities, display applications, etc. During configuration of the process plant 10, the module classes may be used to create configuration instances of the process entities that fit the definitions provided by the module class objects for any number of different process entities, with each configuration instance (a module object created from a module class object) being associated or tied to a different actual process entity. These different module instances contain, among other routines, control and / or display routines that are tied to a particular process entity as disposed within the process plant 10, and these control routines can be downloaded to and used within the controller 12 of FIG. 1 to perform the actual control activities on the process entities, and the display routines can be downloaded at the workstation 14 to perform the actual display activities for the entities during operation of the process plant 10.
[0046] As described herein, different types of module class objects may be implemented in different ways. Module classes may reflect the range of process entities that are associated with a module class, thereby including control and / or display routines that operate on or are configured with respect to different ranges of process entities. The larger the range of process entities, e.g., units, the more control and / or display routines will typically be associated with module classes, making it easier to configure sections of a plant using those module classes. However, the larger the range of process entities associated with a module class, the less likely a process will include duplicated equipment at that range, and therefore the less likely the module class will be useful on a large scale. Conversely, the lower the range of process entities associated with a module class, the more likely the module class will be able to be used in a variety of different places in a plant, but the less amount of configuration that will be done when using that module class in any particular instance.
[0047] Figure 2 illustrates one embodiment of a first configuration screen that may be used to modify a first version of a module class. The configuration screen may be part of a configuration application, such as configuration application 50 running on one of the workstations 14 of Figure 1. For example, as illustrated by Figure 2, configuration screen 250 is part of a control studio configuration application. General details of the control studio configuration application are described in U.S. Patent No. 7,043,311.
[0048] The configuration screen 250 of FIG. 2 illustrates the configuration of a particular field device module class, for example, the 2-state valve module class 256 as depicted in the 2-state valve window 252. Specifically, the configuration screen 250 illustrates a graphical representation of the 2-state valve module class 256. The 2-state valve module class 256 includes a control with a DC1 device control 258. The DC1 control 258 may include logic, routines, or functions for controlling a physical 2-state valve device operating within the process plant 10. The logic, routines, or functions of the 2-state valve module class 256 may be implemented in a variety of different computer languages, including, for example, C, C++, Java, or any other computer language for implementing drivers, BIOS software, or other software for controlling a 2-state valve device associated with the 2-state valve module class 256. In some embodiments, the logic, routines, or functions may be executed on a device that controls the 2-state valve, including, for example, any of the controllers 12 or 12a of FIG. 1.
[0049] A module class may have one or more outputs 260, where information computed by or stored in an instance of the module class may be determined and / or output from the instance for use in configuring or otherwise controlling the process plant 10. In the embodiment of Figure 3, for example, the DC1 device control 258 of the Two-State Valve Module class 256 includes a valve position output 262, which may include an output number or other value that indicates a current or desired open or closed position during valve operation.
[0050] Information for the 2-state valve module class 256 is displayed within the control configuration window 254. For example, the control configuration window 254 includes information for the 2-state valve module class 256, including input fields for defining the title, description, and process type of the 2-state valve module class 256. For example, the title of the class may have been defined as "2-State Valve" in a previous configuration session. In addition, the control configuration window 254 allows an execution run time to be specified, and for the current exemplary embodiment, an instance of the 2-state valve module class 256 is set to run every 2 seconds.
[0051] The control configuration window 254 also includes library information, which is 2 includes a family tree of two-state valve module instances shown with the module class. For example, in the current embodiment, 25 two-state valve module instances 256a are associated with and based on the two-state valve module class 256. The 25 two-state valve module instances 256a are live instances running in computer memory that are instantiated from, and therefore based on, the associated two-state valve module class 256. The family tree of the control configuration window 254 also shows a two-state valve IL module class 257, which is a derived class of the two-state valve module class 256. For example, the derived class two-state valve IL module class 257 may have additional properties or functionality when compared to its parent two-state valve module class 256. As shown in the current embodiment of FIG. 2, the 25 two-state valve IL module instances 257a are also associated with the derived two-state valve IL module class 257. Thus, configuration window 254 depicts a Two-State Valve Module class 256 having 25 instances, which has a derived class (i.e., Two-State Valve IL) having another 25 instances, in which case Two-State Valve Module class 256 and Two-State Valve IL Module class 257 are said to be in the same family.
[0052] In the embodiment of FIG. 2, each of module classes 256, 256a, 257, and 257a currently includes only a single, or first, version, although additional, further versions may be created as described further herein.
[0053] 3 is an illustration of an embodiment of the configuration screen of FIG. 2 showing a second, new version of the 2-state valve module class 256 from FIG. 2. As disclosed in various embodiments herein, a configuration application 50 executing on one or more processors, such as one of the workstations 14 of FIG. 1, may be configured to generate a second version of the module class based on modifications to a first version of the module class. In the embodiment of FIG. 3, the second version of the 2-state valve module class 256 from FIG. 2 is generated based on modifications to the original, or first, version of the 2-state valve module class 256. For example, the control configuration window 254 includes the second version of the 2-state valve module class 256 from FIG. 2. The second version is also included under the family tree and shown as a new 2-state valve module class 356.
[0054] The second version of the Two-State Valve Module class 356 may correspond to changed process control elements of the process plant, including, for example, a hardware change in which one process control element is replaced with another process control element. In one embodiment, for example, an engineer may update the first version's module class (e.g., Two-State Valve Module class 256) with a new module class (e.g., Two-State Valve Module class 356) to correspond to the changed hardware. The engineer may then roll out the updated Two-State Valve Module class 356 to the new hardware (e.g., valves) as described herein, which may include testing the new valves. After the engineer is satisfied with the changes, the engineer may indicate that the remaining similar valves will receive the updated module class Two-State Valve Module class 356.
[0055] In some embodiments, for example, a modification to a first version of a module class may include adding one or more inputs (e.g., feedback inputs) to the first version of the module class, where the one or more inputs are accessed by a configuration application 50 executing, for example, on one of the workstations 14 of FIG. 3 illustrates adding two inputs to a 2-state valve module class 256 to create a new 2-state valve module class 356. Using the configuration screen 250, one or more inputs 350 may be added via a 2-state valve window 252. Specifically, in the embodiment of FIG. 3, the 2-state valve module class 256 is modified to add an open position feedback input 352 and a closed position feedback input 354 to create the 2-state valve module class 356.
[0056] In some embodiments, the logic or functionality of the DC1 device control 258 may also be modified to use the newly added input values of the open position feedback input 352 and the closed position feedback input 354. For example, in at least one embodiment, the values of the open position feedback input 352 and the closed position feedback input 354 are fed into the logic or functionality of the DC1 device control 258 during operation of a two-state valve running instance based on the Two-State Valve Module Class 356, where the inputs 352 and 354 are used to improve or optimize the operation of a physical two-state valve device operating within the process plant 10 to refine or implement more precise control over the valve position output value 262.
[0057] 4 is an illustration of one embodiment of the configuration screen of FIG. 3 showing process control elements selected to be associated with the second version Two-State Valve Module class 356 of the module class from FIG. 3. In the embodiment of FIG. 4, the selection of process control elements includes process control elements selected to be included in the upgraded process control element set. As illustrated in FIG. 4, the process elements selected for inclusion in the upgraded process control element set may be received via a graphical interface where an operator, e.g., an engineer, may select which process control elements to include in the upgraded process control element set with the intent of upgrading those process control elements with a new instance based on the second version Two-State Valve Module class 356.
[0058] For example, as shown in Figure 4, an upgraded process control element set dialog box 402 is displayed to an operator to receive a selection for inclusion within the process control element set. In the embodiment of Figure 4, the upgraded process control elements are included in an upgraded process control element set that defines each process control element associated with a new module instance of a second version of a module class (e.g., Two-State Valve Module class 356).
[0059] In some embodiments, the selection may also relate to a particular area of the process plant 10. For example, in FIG. 4, the selection relates to the “Feedstock Area” of the process plant 10. The operator may select various two-state valve instances currently running within the Feedstock Area, including instances running within Feedstock Unit 1 (e.g., model instances corresponding to two-state valve devices, named “XV-101” and “XV-102”), Feedstock Unit 2 (e.g., model instances corresponding to two-state valve devices, named “XV-201” and “XV-202”), and Feedstock Unit 3 (e.g., model instances corresponding to two-state valve devices, named “XV-301” and “XV-302”). In the current embodiment, each of the Raw Material Unit 1 area, Raw Material Unit 2 area, and Raw Material Unit 3 area may represent a different sub-area or logical area of the plant, whereby the sub-areas or logical areas of Raw Material Units 1-3 form a hierarchy to a larger Raw Material Area, where Raw Material Units 1-3 exist within the Raw Material Area and are specific to a particular instance (e.g., two-state valves XV-101, XV-102, XV-103, XV-104, XV-105, XV-106, XV-107, XV-108, XV-109, XV-2000, XV-2010, XV-2020, XV-2030, XV-2040, XV-2050, XV-2060, XV-2070, XV-2080, XV-2090, XV-3000, XV-3010, XV-3020, XV-3030, XV-3040, XV-3050, XV-3060, XV-3070, XV-3080, XV-3090, XV-4090, XV-4090, XV-4090, XV-4090, XV-4090, XV-4090, XV-5090, XV-5090, XV-5090, XV-5090, XV-6090, XV-6090, XV-6090, XV-7090, XV-7090, XV-8090, XV-8090, XV-9090, XV-910, XV-9100, XV-9101, XV-9102, XV-9103 2, XV-201, etc.) are present within the sub-areas or logical areas of raw material units 1-3. Thus, in some embodiments, selecting the upgraded set of process control elements may include selecting process control elements associated with a physical area of the process plant.
[0060] 4, all of the two-state valve instances associated with each of the sub-areas or logical areas of Raw Material Units 1-3 are shown selected, and in this embodiment, each of the two-state valve instances is selected to be associated with a new module instance of the second version Two-State Valve Module class 356. Thus, in some embodiments, selecting the upgraded set of process control elements may include selecting process control elements associated with a particular hierarchy of the process plant.
[0061] In various embodiments, new module instances of selected process control elements included in the process control element set may be instantiated when the rollout instructions are executed. The upgraded process control element set may be a subset of all process control elements of the process plant, where, for example, some but not all of the process control elements of the process plant are included in the process control element set for modification.
[0062] 5 is an illustration of an embodiment of the configuration screen of FIG. 3 showing a process control element selected based on a particular derived class. In the embodiment of FIG. 5, the selected process control element is associated with a new instance based on a second version of the Two-State Valve Module class 356. As illustrated in FIG. 5, an operator may select the Two-State Valve IL Module class 257 from the filter screen 502, which is a particular derived class derived from the Two-State Valve Module class 256. In some embodiments, the selection of the process control element may result in the process control element being included in a process control element set, as described herein for FIG. 4. In such an embodiment, the process control element set includes process control elements associated with a particular derived module class, in which case a rollout instruction is executed to update those instances based on the Two-State Valve IL Module class 257, e.g., all 25 module instances 257a.
[0063] 6 is an illustration of an embodiment of the configuration screen of FIG. 3 showing new module instances of the Two-State Valve Module class 356 rolled out to process control elements in the process plant 10. In the embodiment of FIG. 6, the process control elements updated via the rollout receive new functionality including new improved or optimized features provided by the Two-State Valve Module class 356 as described herein. Thus, after the rollout is performed, the Two-State Valve Module class 356 may be associated with one or more new module instances based on the Two-State Valve Module class 356. Each of the new module instances may be associated with a process control element of the process plant, such as a field device, or a portion of a field device including, for example, a valve, or specifically, in this embodiment, a two-state valve device.
[0064] Benefits of using the rollout functionality as described herein include that modifications to a module class, e.g., the Two-State Valve Module class 256, do not automatically propagate to its associated instances. Instead, a control engineer may modify a module class, e.g., the Two-State Valve Module class 256, to generate a new Two-State Valve Module class 356. Importantly, when a set of valves Only when an update is ready, as identified, for example, by an engineer or some other process, e.g., an automated process, can a rollout be performed to change those valves designated for update. This allows the process plant 10 to be upgraded in stages, which may provide a more economical and less resource intensive approach to configuring, managing, and / or controlling the operation of the process plant 10. This also allows engineers to repeatedly test new module classes and their associated instances without any concern that undesignated instances will be affected or unintentionally updated.
[0065] The control configuration window 254 of FIG. 6 illustrates new module instances based on the new 2-state valve module class 356 that were generated as a result of performing the rollout. Specifically, the 2-state valve module class 356 has three new module instances 356a based on the 2-state valve module class 356. The three new module instances 356a may correspond to three device valves operating within the process plant that receive the enhanced functionality defined by the new 2-state valve module class 356. In addition, a derived module class (i.e., 2-state valve IL module class 357) is also illustrated, where the 2-state valve IL module class 357 is an additional module class derived from the 2-state valve module class 356 that may include additional functionality or information regarding the valves that implement the module instances, e.g., the two module instances 357a, based on the 2-state valve IL module class 357. The additional functionality or information may include, for example, the location of the valve within the process plant, the date the valve was placed into operation within the process plant, or other information or functionality related to the valve. Thus, as shown in the embodiment of FIG. 6, after the rollout is performed, the process plant has at least two module class versions (e.g., Two-State Valve Module class 256 and Two-State Valve Module class 356) and associated instances running within the process plant 10 for purposes of configuring and controlling the process plant 10 as described herein.
[0066] In various embodiments, new module instances, such as module instances 356a and 357a, may be rolled out via rollout instructions executed by one or more processors of the process plant, including, for example, configuration application 50 executing on one or more of the processors of workstation 14 of Figure 1. The rollout instructions may include routines for updating one or more upgraded process control elements, each associated with the new module instance based on a second version of a module class, such as Two-State Valve Module class 356 or Two-State Valve IL Module class 357.
[0067] The rollout instructions may also be implemented to ignore, e.g., skip, one or more non-upgraded process control elements, each of which remains associated with a previous module instance based on the first version of the module class, e.g., Two-State Valve Module class 256 or Two-State Valve IL Module class 257.
[0068] In one embodiment, an engineer may modify the Two-State Valve Module class 256 to include an update to the Two-State Valve Module class 356 as described herein and then save the update in the configuration application 50. The engineer may then instruct the system how to roll out the update. For example, the rollout instructions may be implemented via a selective upgrade routine that selects an upgraded version of the Two-State Valve Module class 356 based on a second version of the module class. The associate process control element with the new module instance routine may be selected from the configuration screen 250, such as the rollout changes selection 600, which may cause the configuration application 50 to execute rollout instructions to update the identified upgraded process control element.
[0069] In some embodiments, the selective upgrade routine can be implemented to simply ignore or skip the non-upgraded process control elements, such that the non-upgraded process control elements are not associated with any second new module instance based on the second version of the module class, e.g., the Two-State Valve Module class 356 or the Two-State Valve IL Module class 357.
[0070] In some embodiments, the rollout instructions may be executed immediately when selected. In other embodiments, the rollout instructions may be executed at scheduled times. For example, an engineer may schedule the next rollout at a first time for one set of valves and another time for a subset of other valves (e.g., via an opportunistic rollout of a module class change). Other use cases may implement scheduling the rollout based on operator training and / or availability, e.g., as a phased rollout based on operator shift or work schedules.
[0071] In some embodiments, once the rollout instructions are executed, each of the upgraded and non-upgraded process control elements may be downloaded to the controller 12 or 12a and used together to control at least a portion of the process plant. In such embodiments, the process plant is controlled by a first version and a second version of the same module class (e.g., Bi-State Valve Module class 256 and Bi-State Valve Module class 356) that include different versions, e.g., simultaneously.
[0072] In still further embodiments, the module configuration record may be configured, for example via the configuration application 50, to track module instances, e.g., module instances 256a, 257a, 356a and / or 357a, currently running within the process plant. In some embodiments, the module configuration record may indicate the version of the module class for each of the module instances. The module configuration record may also indicate that the module class has a phased rollout state. For example, from a system perspective, in some embodiments, when an engineer saves an update to a module class, the rollout of the updated module class becomes a manual step instead of an automatic step. In such an embodiment, the module class being rolled out is flagged as being in a phased rollout stage and has two live versions of the same module class, e.g., a version of the module instance based on the previous two-state valve module class 256 and a version of the module instance based on the new two-state valve module class 356.
[0073] 7 is an illustration of one embodiment of the configuration screen of FIG. 3 showing additional rollout instructions that apply configuration changes to a new module instance (e.g., two-state valve module class 256) based on a second version of the module class and to a previous module instance (e.g., two-state valve module class 356) based on a first version of the module class. For example, the embodiment of FIG. 7 can be used to roll out configuration changes across multiple versions of a module class (e.g., both versions of the two-state valve module class). A simple repair may be performed (across all versions) where each version of the module class receives a configuration change that implements the simple repair.
[0074] Specifically, in various embodiments, the additional rollout instructions may be executed by one or more processors, such as one or more of the processors of workstation 14 of FIG. 1. The additional rollout instructions may apply configuration changes to each of the new module instance (e.g., module instance 356a and / or 357a) based on the second version of the module class and the previous module instance (e.g., module instance 256a and / or 257a) based on the first version of the module class. The configuration changes may include additional modifications to be applied to each of the second version of the module class (e.g., two-state valve module class 356) and the first version of the module class (e.g., two-state valve module class 256), such as to apply a patch or quick fix to the module class as a whole. For example, in one embodiment, the fix may be applied to a running instance. In other embodiments, the module class may be an updated new instance instantiated to replace an existing module instance, such as module instance 356a and / or 357a, and / or module instance 256a and / or 257a.
[0075] In the embodiment of FIG. 7, the additional modifications include adding computational functionality 700 to both the second version of the module class (Two-State Valve Module class 356) and the first version of the module class (Two-State Valve Module class 256) to improve the functionality of the module classes and their associated instances, and therefore the valves, across both versions.
[0076] 8 is an illustration of one embodiment of the configuration screen of FIG. 7 showing a rollout confirmation screen 800 for executing additional rollout instructions. For example, the rollout confirmation screen 800 may be launched after an engineer selects the rollout changes selection 600, where the rollout confirmation screen 800 confirms whether the engineer wants to roll out a quick fix change to a module instance, as described with respect to FIG.
[0077] Figure 9 is an illustration of one embodiment of a configuration screen showing module instances associated with a particular type of process control element in the process plant 10. In the embodiment of Figure 9, the particular type of process control element is an XC-224 field device, which is one type of valve. Figure 9 illustrates the state of the phased rollout from the perspective of the XC-224 device. The phased rollout is shown on the XC-224 device display view, on the lower right hand side of the XC-224 device window 952 and in the window heading 972.
[0078] The XC-224 device is identified in a control configuration window 954. The XC-224 device is also identified hierarchically in a control explorer window 953. Specifically, the control explorer window 953 arranges various process control elements, including the XC-224 device, in a hierarchical manner according to the physical location or area of the process control elements within the process plant. For example, as shown by the control explorer window 953, the XC-224 device is located at the bottom tower of a feed heater element, where the feed heater element is located at or is part of a location, area or logical area of Feed Unit 1, which in turn is part of a larger feed area located at a site named Kronos within the process plant 10.
[0079] The configuration window 954 displays control information and options for the XC-224 device. Includes options to modify the title, description, process type, controller assignment, and runtime of the XC-224 device.
[0080] Configuration window 954 also displays the module instances instantiated based on the associated XC-224 module class. In the embodiment of FIG. 9, there are two versions of the XC-224 module class (module classes 956 and 957) that are similar to two versions of the 2-state valve module class (i.e., 2-state valve module class 256 and 2-state valve module class 356) as described herein. Thus, the disclosure relating to the 2-state valve module class applies equally herein to the XC-224 module class. For example, configuration screen 950 corresponds to configuration screen 250 described herein, and configuration screen 950 specifically relates to the XC-224 module class. As an additional example, as illustrated by XC-224 device window 952, the XC-224 module class includes DC1 device control 958 that corresponds to DC1 device control 258 of 2-state valve module class 256 and 2-state valve module class 356 described herein. Additionally, the XC-224 module class includes a valve position output 962 that corresponds to the valve position output 262 of the Two-State Valve Module class 256 and the Two-State Valve Module class 356 described herein. Similarly, the XC-224 module class includes a calculation function 959 that corresponds to the calculation function 700 for the Two-State Valve Module class 356 described herein.
[0081] The XC-224 module class 956 represents an easier first version of the XC-224 module class. The XC-224 module class 956 is associated with one or more module instances 956a that correspond to XC-224 devices currently operating within the process plant. Similarly, the XC-224 module class 957 is a modified second version of the XC-224 module class. The XC-224 module class 957 is associated with three module instances 957a, each of which may correspond to a newly installed XC-224 device currently operating within the process plant 10.
[0082] In some embodiments, the configuration application 50 and / or the controller 12 may be further configured to prevent additional upgrades of a module class when the module configuration record indicates that the module class has a phased rollout state. For example, the configuration record may include information illustrated by window heading 972 to indicate that updates are not currently permitted by "Phased Rollout Is In Progress." In some embodiments, the option to prevent updates of the module class may be a selectable option, such as in this case, as shown in FIG. 9, where an engineer may select selectable option 970 to prevent instances from changing the module structure. Thus, the selectable option 970 may be used to prevent instances from changing the module structure when the module class is in the middle of a phased rollout, and to control the timing and / or limitations of changes to the class.
[0083] 10 illustrates one embodiment of a method 1000 for controlled rollout of a module class for configuring a process plant 10. The method 1000 begins (1002) at block 1004, where one or more processors (e.g., one or more processors executing on one or more of the workstations 14 of FIG. 1 ) generate a second version of a module class (e.g., Two-State Valve Module class 356) based on a first version of the module class (e.g., Two-State Valve Module class 256). A second version of the module class may be generated. In some embodiments, the module class may be a derived module class described herein (e.g., 2-State Valve IL Module class 257 or 2-State Valve IL Module class 357). The module class may be associated with one or more module instances, which may each be associated with a process control element of the process plant, including, for example, a field device such as a valve, as described herein. The second version of the module class may correspond to a changed process control element of the process plant, including, for example, a hardware change in which one process control element is replaced with another process control element. In some embodiments, the modifications to the first version of the module class may include adding one or more inputs (e.g., feedback inputs) to the module class, where the one or more inputs may be accessed to facilitate at least partial control of the upgraded process control element.
[0084] At block 1006, rollout instructions are executed by the one or more processors to update the one or more upgraded process control elements. The rollout instructions cause each of the upgraded process control elements to be associated with a new module instance based on the second version of the module class (e.g., Two-State Valve Module class 356). The rollout instructions may also be implemented to ignore, e.g., skip, one or more non-upgraded process control elements, which each remain associated with a previous module instance based on the first version of the module class (e.g., Two-State Valve Module class 256).
[0085] In some embodiments, the rollout instructions may be implemented via a selective upgrade routine that associates upgraded process control elements with new module instances based on the second version of the module class, and the selective upgrade routine simply ignores or skips non-upgraded process control elements, such that the non-upgraded process control elements are not associated with any second new module instances based on the second version of the module class.
[0086] As described herein, in some embodiments, the rollout instructions may be executed immediately, while in other embodiments, the rollout instructions may be executed at a scheduled time.
[0087] At block 1008, once the rollout instructions are executed, each of the upgraded and non-upgraded process control elements may be used together to control at least a portion of the process plant 10. In such an embodiment, the process plant 10 is controlled by different versions of the same module class, for example a first version and a second version.
[0088] Module-based systems and methods may be configured to track one or more module instances via a module configuration record. In some embodiments, the module configuration record may indicate a module class version for each of the one or more module instances. The module configuration record may also indicate that the module class has a phased rollout state.
[0089] In some embodiments, the module-based systems and methods may be further configured to prevent additional upgrades of a module class when the module configuration record indicates that the module class has a phased rollout state.
[0090] In still further embodiments, the upgraded process control elements may be included in an upgraded process control element set that defines each process control element associated with a new module instance of the second version of a module class (e.g., Two-State Valve Module class 356). The upgraded process control element set may be created when the rollout instructions are executed. In some embodiments, the upgraded process control element set may be a subset of all process control elements of the process plant.
[0091] Selections of process control elements for inclusion in the upgraded process control element set may be received by module-based systems and methods, including, for example, via a graphical interface that allows an operator to select which process control elements to include in the upgraded process control element set.
[0092] For example, in some embodiments, selecting the set of upgraded process control elements may include selecting process control elements associated with a particular derived module class, in other embodiments, selecting the set of upgraded process control elements may include selecting process control elements associated with a particular hierarchy of the process plant, and in yet further embodiments, selecting the set of upgraded process control elements may include selecting process control elements associated with a physical area of the process plant.
[0093] In various embodiments, additional rollout instructions may be executed that apply configuration changes to each of a new module instance (e.g., Two-State Valve Module class 356) based on the second version of the module class and a previous module instance (e.g., Two-State Valve Module class 256) based on the first version of the module class. The configuration changes may include additional modifications applied to each of the second version of the module class and the first version of the module class. For example, in one embodiment, the additional modifications may add computational capabilities to each of the second version of the module class and the first version of the module class to increase functionality of the module class across both versions.
[0094] Additional Considerations When implemented, any of the software described herein may be stored in any computer readable memory, for example on a magnetic disk, laser disk, or other storage medium, in the RAM or ROM of a computer or processor, etc. Similarly, the software may be distributed to a user, process plant, or operator workstation using any known or desired distribution method, including, for example, a computer readable disk or other portable computer storage mechanism, or via a communications channel, for example, a telephone line, the Internet, the World Wide Web, any other local or wide area network, etc. (This distribution is considered to be the same as or compatible with providing such software via a portable storage medium). Additionally, the software may be provided directly without modulation or encryption, or may be modulated and / or encrypted using any suitable modulation carrier and / or encryption technique before being transmitted over a communications channel.
[0095] Although the present invention has been described with respect to specific examples, it will be apparent to those skilled in the art that these examples are illustrative only and are not intended to be limitations of the invention, and that modifications, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention. It would be.
[0096] The final claims of this application are not intended to be construed under 35 U.S.C. § 112(f) unless conventional means-plus-function language is expressly recited, e.g., unless the claim expressly recites language such as "means for" or "step for." The systems and methods described herein are directed to improving computer functionality and improve upon the functionality of conventional computers.
Claims
1. 1. A module-based system for implementing a controlled roll-out of a class of modules for configuring a process plant, the module-based system comprising: a processor in communicative communication with one or more process controllers of the process plant, the processor configured to communicate with the one or more process controllers to control a plurality of process control elements of the process plant, the plurality of process control elements comprising at least one upgraded process control element and one non-upgraded process control element; a memory communicatively coupled to the processor, the memory configured to store a plurality of module classes for distributed, network-based configuration of the plurality of process control elements of the process plant; The processor, generating a second version of a module class, the module class being selected from the plurality of module classes, the second version being generated based on modifications to a first version of the module class, the module class being associated with one or more module instances, and the one or more module instances being modified. Each of the modules is created from at least one of the plurality of module classes and generating module instances based on a module class and inheriting identical structure and properties, each module instance being associated with a process control element of one or more process control elements of the process plant; executing a rollout instruction, the rollout instruction updating the upgraded process control elements, the upgraded process control elements associated with new module instances based on the second version of the module class, the rollout instruction ignoring the non-upgraded process control elements and preventing changes to a module structure, the non-upgraded process control elements remaining associated with previous module instances based on the first version of the module class, and the process plant being simultaneously controlled by different versions of a same module class, including a first version and a second version. To be controlled, to execute, Tracking the one or more module instances via a module configuration record. and tracking the module configuration record indicating a version of the module class for each of the one or more module instances, the module configuration record indicating that the module class has a phased rollout state, the phased rollout state indicating that a rollout of the module class is in progress and that updates to the module class are not currently allowed. The processor is further configured to prevent additional updates of the module classes due to the phased rollout state being indicated.
2. The module-based system of claim 1 , further configured to operate at least a portion of the process plant by using the upgraded and non-upgraded process control elements.
3. 3. The module-based system of claim 1, further configured to execute the rollout instructions by a selective upgrade routine, wherein the selective upgrade routine associates the upgraded process control element with the new module instance based on the second version of the module class, and wherein the selective upgrade routine does not associate the non-upgraded process control element with a second new module instance based on the second version of the module class.
4. The module-based system of claim 1 , wherein the module class is a derived module class.
5. The module-based system of claim 1 , wherein the rollout instructions are executed (a) immediately or (b) at a scheduled time.
6. The module-based system of claim 1 , wherein the particular process control element is a field device.
7. The module-based system of claim 1 , wherein the second version of the module class corresponds to a changed process control element of the process plant.
8. 8. The module-based system of claim 1, wherein the modifications to the first version of the module class include adding one or more inputs to the module class, and the module-based system is further configured to access the one or more inputs to facilitate control of the upgraded process control element.
9. The module-based system of claim 8 , wherein the one or more inputs to the module class are one or more feedback inputs.
10. 10. The module-based system of claim 1, wherein the upgraded process control elements are included in an upgraded process control element set, the upgraded process control element set defining each process control element to be associated with a new module instance of the second version of the module class when executed by the rollout instructions, the upgraded process control element set including a subset of all process control elements of the process plant. Hmm.
11. The module-based system of claim 10 , operable to receive one or more process control element selections, the process control element selections indicating each process control element to be included in the upgraded process control element set.
12. 11. The module-based system of claim 10, wherein the upgraded set of process control elements includes process control elements associated with at least one of a particular derived module class, a particular hierarchy of the process plant, and a physical area of the process plant.
13. 13. The module-based system of claim 1, further configured to execute additional rollout instructions, the additional rollout instructions applying configuration changes to the new module instance based on the second version of the module class and to the previous module instance based on the first version of the module class, the configuration changes including additional modifications to each of the second version of the module class and the first version of the module class.
14. 14. The module-based system of claim 13, wherein the incremental modifications add computational functionality to each of the second version of a module class and the first version of the module class, the computational functionality being added to enhance functionality of the module class.
15. 1. A module-based method for implementing a controlled roll-out of a class of modules for configuring a process plant using one or more processors, the method comprising: generating a second version of a module class based on modifications to a first version of the module class selected from a plurality of module classes, the module classes being associated with one or more module instances, each of the one or more module instances being associated with the first version of the module class, the second version of a module class being generated ... second version of a module class being generated based on modifications to a first version of the module class selected from a plurality of module classes, the module classes being associated with one or more module instances, each of the one or more module instances being associated with the first version of the module class, A module class that is created from at least one of multiple module classes and is the source of the module class generating a module instance based on the process plant, the module instance inheriting the same structure and properties as the process plant, each module instance being associated with a process control element of the process plant; The processor executes rollout instructions, the rollout instructions updating the upgraded process control elements, the upgraded process control elements associated with new module instances based on the second version of the module class, the rollout instructions ignoring the non-upgraded process control elements and preventing changes to a module structure, the non-upgraded process control elements remaining associated with previous module instances based on the first version of the module class, and the process plant is operable to update different versions of the same module class, including a first version and a second version. and tracking the one or more module instances via a module configuration record, the module configuration record indicating a version of the module class for each of the one or more module instances; tracking a module class that indicates that the module class has a phased rollout state, the phased rollout state indicating that a rollout of the module class is in progress and that updates of the module class are not currently allowed; Including, The processor is further configured to prevent additional updates of the module class due to the phased rollout state being indicated.
16. 16. The module-based method of claim 15, further comprising: operating at least a portion of the process plant by using the upgraded process control element and the non-upgraded process control element.
17. 17. The module-based method of claim 15 or 16, further comprising executing the rollout instructions by a selective upgrade routine, wherein the selective upgrade routine associates the upgraded process control element with the new module instance based on the second version of the module class, and wherein the selective upgrade routine does not associate the non-upgraded process control element with a second new module instance based on the second version of the module class.
18. 18. The module-based method of claim 15, wherein the module class is a derived module class.
19. 19. The module-based method of claim 15, wherein the rollout instructions are executed (a) immediately or (b) at a scheduled time.
20. 20. The module-based method of any one of claims 15 to 19, wherein the particular process control element is a field device.
21. 21. The module-based method of claim 15, wherein the second version of the module class corresponds to a modified process control element of the process plant.
22. 22. The module-based method of claim 15, wherein the modification to the first version of the module class includes adding one or more inputs to the module class, and the module-based method is further configured to access the one or more inputs to facilitate at least partial control of the upgraded process control element.
23. 23. The module-based method of claim 22, wherein the one or more inputs to the module class are one or more feedback inputs.
24. 24. The module-based method of claim 15, further comprising: defining each process control element such that the upgraded process control element is included in an upgraded process control element set, the upgraded process control element set being associated with a new module instance of the second version of the module class when executed by the rollout instructions, the upgraded process control element set including a subset of all process control elements of the process plant.
25. 25. The module-based method of claim 24, operable to receive one or more process control element selections, the process control element selections indicating each process control element to be included in the upgraded process control element set.
26. 25. The module-based method of claim 24, wherein the upgraded set of process control elements includes process control elements associated with at least one of a particular derived module class, a particular hierarchy of the process plant, and a physical area of the process plant.
27. 27. The module-based method of claim 15, further comprising executing additional rollout instructions to apply configuration changes to the new module instance based on the second version of the module class and to the previous module instance based on the first version of the module class, the configuration changes including additional modifications to each of the second version of the module class and the first version of the module class.
28. 30. The module-based method of claim 27, wherein the incremental modifications add computational functionality to each of the second version of a module class and the first version of the module class, the computational functionality being added to enhance functionality of the module class.
29. 1. A module-based system for implementing a controlled roll-out of a class of modules for configuring a process plant, the module-based system comprising: a processor in communicative communication with one or more process controllers of the process plant, the processor configured to communicate with the one or more process controllers to control a plurality of process control elements of the process plant, the plurality of process control elements comprising at least one upgraded process control element and one non-upgraded process control element; a memory communicatively coupled to the processor, the memory configured to store a plurality of module classes for distributed, network-based configuration of the plurality of process control elements of the process plant; The processor, generating a second version of a module class, the module class being selected from the plurality of module classes, the second version being generated based on modifications to a first version of the module class, the module class being associated with one or more module instances, and the one or more module instances being modified. Each of the modules is created from at least one of the plurality of module classes and generating module instances based on a module class and inheriting identical structure and properties, each module instance being associated with a process control element of the one or more process control elements of the process plant; executing a rollout instruction, the rollout instruction updating the upgraded process control elements, the upgraded process control elements associated with new module instances based on the second version of the module class, the rollout instruction ignoring the non-upgraded process control elements and preventing changes to a module structure, the non-upgraded process control elements remaining associated with previous module instances based on the first version of the module class, and the process plant being simultaneously controlled by different versions of a same module class, including a first version and a second version. To be controlled, to execute, [0023] the modification to the first version of the module class includes adding one or more inputs to the module class, the module-based system being further configured to access the one or more inputs to facilitate at least partial control of the upgraded process control element; The one or more inputs to the module class are one or more feedback inputs. Module based system.
30. 1. A module-based method for implementing a controlled roll-out of a class of modules for configuring a process plant using one or more processors, the method comprising: generating a second version of a module class based on modifications to a first version of the module class selected from a plurality of module classes, the module classes being associated with one or more module instances, each of the one or more module instances being associated with the first version of the module class, the second version of a module class being generated ... second version of a module class being generated based on modifications to a first version of the module class selected from a plurality of module classes, the module classes being associated with one or more module instances, each of the one or more module instances being associated with the first version of the module class, A module class that is created from at least one of multiple module classes and is the source of the module class generating a module instance based on the process plant, the module instance inheriting the same structure and properties as the process plant, each module instance being associated with a process control element of the process plant; The processor executes rollout instructions, the rollout instructions updating the upgraded process control elements, the upgraded process control elements associated with new module instances based on the second version of the module class, the rollout instructions ignoring the non-upgraded process control elements and preventing changes to a module structure, the non-upgraded process control elements remaining associated with previous module instances based on the first version of the module class, and the process plant is operable to update different versions of the same module class, including a first version and a second version. and Including, the modification to the first version of the module class includes adding one or more inputs to the module class, the module-based method being further configured to access the one or more inputs to facilitate at least partial control of the upgraded process control element; the one or more inputs to the module class are one or more feedback inputs; Module-based approach.
Citation Information
Patent Citations
Parallel processing system
JP1998011304A
Sensor, host device and sensor system
JP2000269972A
Version management for object in process plant configuration system
JP2005339494A
Computer and method for installing set program
JP2006126992A
Method and device for updating control program of NC machine tool
JP2007102625A