Version control and audit trail in a process control system6449624Abstract A system useful for controlling a process includes a computer-readable medium and a processor in communication with the computer-readable medium. The system further includes a first database and a second database. The first database stores first data representative of a first configuration of the process, while the second database stores second data representative of a second configuration of the process. A configuration routine of the system is stored in the computer-readable medium and configured to be executed by the processor to facilitate a modification of the first configuration of the process. A version control routine of the system is stored in the computer-readable medium and configured to be executed by the processor to store in the second database third data indicative of the modification of the first configuration of the process. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1
Version Control Preferences Dialog
Name Type Min Max Default Content
Manual Radio n/a n/a Selected Determines if a
Check-out Button dialog is displayed to
prompt user to
check-out an item for
modification.
Automatic Radio n/a n/a Not Indicates if item will
check-out Button selected be automatically
checked out.
Automatic Radio n/a n/a Not Indicates if item will
Check-out Button selected be automatically
and Check-in checked out and
checked in when
modifying an item
configuration.
The user may wish to select automatic check-out because, for instance, changes to one versionable item may affect and cause changes to one or more other versionable items. For example, the modification of an item such as a composite function block may affect one or more modules that use the composite function block. The VCAT system 98 preferably determines during each check-out operation which other versionable items need to be checked out in order to modify the configuration of an item. The modification of these other versionable items may be referred to as "consequential changes." If the user has elected manual check-out, then the VCAT system 98 prompts the user to check these items out. If automatic check-out is enabled, the VCAT system 98 does not prompt the user and automatically checks out each of the other items for which consequential changes may occur. The user may check-out and check-in items manually by utilizing the appropriate command offered via the version control sub-menu 120 or the context menu 116. Preferably, the VCAT system 98 then determines whether the selected item is a versionable item. At this time, the VCAT system 98 also determines whether the selected item has already been checked out. In the event that the selected item is already checked out, a message dialog (not shown) will alert the user of the fact and provide the user with an opportunity via, for instance, a button, to dismiss the message dialog and return to the previous state of the user interface 94. Because the configuration of the process 10 is set forth in a hierarchal manner, the VCAT system 98 must allow for checking out items having subordinate items that are also versionable. Accordingly, during a check-out operation, the user is provided with the option of recursively checking out any such items. A similar option is provided in connection with the check-in operation. In one embodiment, if a recursive check-out or check-in is selected by the user, the VCAT system 98 generates a dialog window (not shown) that provides the user with a list of versionable, subordinate items that may be checked out (or checked in). The user may then select (or de-select) any one of the listed items to initiate a selective recursive operation. When the VCAT system 98 is integrated with the configuration applications 96, the appearance of the items displayed within the main window 80 may be modified to denote that the item has been checked-out. In one embodiment, a checkmark overlays the icon associated with the item. It should be understood that a variety of other appearance schemes may be utilized. Checkmarks of different colors may also be utilized to denote specific users or when the item was checked out by the current user or a different user. With reference now to FIG. 9, checked out items may be manually checked in using the appropriate commands made available in the version control sub-menu 120 and the context menu 116. A check-in dialog window 124 is preferably generated upon user initiation of the check-in procedure when the user has elected to proceed with a manual check-in environment. The check-in dialog window 124 includes a comment field 126 for accepting user-supplied commentary regarding the modification of the item. The commentary may, for instance, include an explanation of why the modifications were made. In addition to the comment field 126, the check-in dialog window 124 provides several other options to the user, each of which is described in detail below in Table 2. In particular, the user is provided with the options of designating that any subordinate items associated with the item to be checked in (that are also checked out) should be checked in, and electing that the item should remain checked out for further modifications. As set forth above, the check-in operation also stores data representative of the configuration in the version control database 102 as the latest configuration version. In this case, however, even though the item has been checked in, the opportunity to make further modifications to the configuration of the item remains persists because the item remains checked out. The check-in dialog window 124 provides "OK" and "Cancel" buttons 128 and 130 for executing or canceling the check-in procedure, respectively, as well as a "Differences" button 132 that initiates a comparison of the current version of the item (as represented by data stored in the configuration database 100) and the modified version to be checked in. The comparison information is generated by the VCAT system 98 by accessing the configuration database 100 and the latest version in the version control database 102 and presented via the user interface 94. The generation and presentation of the "Differences" information will be discussed in greater detail hereinbelow.
TABLE 2
Version Control Check-In Dialog
Name Type Min Max Default Content
Recursive Checkbox n/a n/a Not Checks in any
checked subordinate items
that are checked out
by this user;
preferably only
applicable to certain
levels of the
configuration
hierarchy.
Keep Checkbox n/a n/a Not Indicates whether the
checked out checked VCAT system
should keep the item
checked out.
Differences Button n/a n/a n/a Difference between
latest version (to be
checked in) and the
current version in
the configuration
database
Comment Edit field n/a n/a Empty User-supplied
description of
change.
Upon checking in an item, the VCAT system 98 may modify the appearance of the item to indicate that the item has been checked-in. This appearance modification may, for example, amount to the removal of a check-mark over the icon associated therewith. The VCAT system 98 may further include functionality that permits the user to request a status update for all of the items in the configuration database 100 to ensure that those items that are checked out are indicated as such via a checkmark or the like. Such functionality may be necessary, for instance, if two or more users are working on configuring the process at the same time, and one of the users has recently checked out an item shown on the user interface 94 of another user. Selection of the "Cancel" button within the check-in dialog window 124 closes the Check-in dialog window without initiating a check-in operation. The VCAT system 98, however, may also enable a user to initiate an "undo checkout" task that removes the check-mark over the icon and, if the item was modified, retrieves the data indicative of the latest version from the version control database 102, and imports the data into the configuration database 100. This procedure restores the configuration of the versionable item to the version that was current as of the time of the check-out operation. This task may be made available via a drop-down or context menu associated with the VCAT system 98. The configuration applications 96 may provide additional ways to initiate the check-out/check-in operations. For example, the user may select an item in the Explorer system and access the "Properties" associated therewith via a right-click or similar pointer maneuver. A Properties window is then generated in accordance with standard windowing techniques that provides for editing of the contents of various "properties" fields displayed within the window. A module, for instance, may have a textual description associated therewith, or utilize certain parameters during execution within the process. The textual description and parameter values may be specified as "Properties" of the module. If the user modifies a property and selects an "OK" or "Apply" button, the VCAT system 98 prompts the user to check-out the item (if automatic check-out is not enabled), after which a check-in procedure is initiated as described hereinabove. Similar actions may be generated via utilization of an "Open" command made available in a command menu of the process configuration applications. A check-out procedure may also be initiated by the VCAT system 98 when a user attempts to rename an item within the Explorer system. In accordance with standard windowing techniques, the user may select the name associated with an item to allow for editing thereof. Once the user is finished editing the name and attempts to enter the modification, the new name will only be accepted if the item is checked out. If the item is already checked out, the item is renamed in the configuration database 100, and data indicative of a new version of the item is stored in the version control database 102 when it is checked in. At that time, the VCAT system 98 may generate further data representative of commentary that describes the renaming operation, and then associate such data with the data indicative of the new version of the item. If the item to be renamed is not yet checked out, the user is prompted to check-out the item via a dialog window (not shown) to that effect (if automatic check-out is not enabled). As set forth above, data representative of each prior configuration of an item is stored in the version control database 102 together with data reflective of a version assigned thereto. The version is preferably identified by number, but may be indicated in any other manner. Having each prior configuration associated with a version number may assist the user during an analysis of the contents of the version control database 102, as well as when the process is in the run-time environment. To this end, the version number or identifier of an item is preferably included as an item parameter when the item is downloaded to the controller 12 and/or a batch executive routine. (The batch executive routine resides on the workstation 14 to manage the execution of a batch process and oversee the controller 12 in connection therewith.) In other words, the data downloaded from the workstations 14 when the process control system 10 is preparing to implement a process includes version identifying data for certain items in the configuration database 100 (i.e., each module, phase, procedural element, etc.) that are involved in the download operation. The version information is then available in the run-time environment to a process operator via the controller 12 and/or the batch executive. Knowledge of the version information may assist in the communication between the process operators and the process designers working within the configuration applications 96. It should be noted that downloading an item to the controller 12, or the run-time environment in general, involves one or more dialog windows (not shown) generated by the configuration applications 96 for the user interface 94 that guide the user through the download procedure. These dialog windows may correspond with the same windows generated by the configuration applications 96 when the VCAT system 98 is not integrated therewith. However, the VCAT system 98 may verify that all items to be downloaded are not checked out before allowing the download procedure to proceed. If any items are checked out, the VCAT system 98 may generate one or more error dialog windows (not shown) that alert the user to the situation and identify the checked out items. Such error dialog windows may facilitate the check-in procedure by providing a button therein directed to initiating a check-in procedure of one or more checked out items identified in the dialog window. With reference now to FIG. 10, the version identifying information may be made available to the process designers via a version audit report (hereinafter "audit report") generated by the VCAT system 98 in accordance with one embodiment of the present invention. In general, each change or modification to the process configuration is recorded in the version control database 102 as a specific version associated with the process. The data indicative of the version and the substance of the modification may be linked to data representative of the check-in date and time, the user who checked-in the item, and the reasons for the modification. It should be noted that the VCAT system 98 may also store data representative of the check-out date and time, as well as the identity of the user checking out the item. The audit trail report may be provided to the user via an audit trail dialog window 140 generated by the VCAT system 98 for the user interface 94. More particularly, a "Show history" task may be initiated by the user by using one of the above-described techniques involving, for instance, the context menu 116, while the user is within one of the configuration applications 96. The audit trail of history may also be provided to the user via any other display device, such as a printer, or may be embodied in an electronic version of the report such that, for instance, data representative of the audit trail is delivered electronically over a network. The audit trail dialog window 140 includes a table portion 142 having a header 144 that identifies a plurality of field names for presenting version information relating to a version number, a user name associated with the check-out, the data and time of the check-in, and a description of the modification or action. The version information is presented in lines (or records) beneath the field names as shown in FIG. 10. Each record is selectable via a pointer or otherwise to initiate a variety of operations. The functionality provided by the VCAT system 98 in connection with the audit trail dialog window is summarized below in Table 3.
TABLE 3
Audit Trail Dialog Window
Name Type Min Max Default Content
Version, List n/a n/a n/a Each line
User, Date, control corresponds with a
Action history record for
the item.
Close Button n/a n/a Enabled Closes the dialog.
Rollback Button n/a n/a Enabled Rollback to the
selected version.
Differences Button n/a n/a Enabled Compares two
selected versions or
selected version with
current version.
Details Button n/a n/a Enabled Displays comments
of selected version.
View Button n/a n/a Enabled Displays the
exportable item in
text or graphical
format.
As set forth in Table 3, the user may view the details of a version of the item by selecting the line of the table portion 142 corresponding with that version and then selecting a View button 143. The data stored in the version control database 102 is then accessed to present the configuration information for the selected version of the item in either a textual or graphical format, or both, based on the nature of the item. Certain items, for instance, may only constitute text and, thus, may not be viewed in the graphical format. For example, versionable items such as a workstation or I/O device only contain parameters that can be modified. The parameters are set forth in text and, thus, no graphical view would be available for such items. Some items, however, may be viewed in both the graphical format and the textual format and generally include items such as modules, composite function blocks, or other items based on a sequential flow chart algorithm. In such cases, the user may be prompted to elect one of the formats or, alternatively, both formats may be presented. An example of an item shown in the textual format is shown in FIG. 11, which is a screen display generated by the VCAT system 98 for the user interface 94. The screen display includes a text view window 146 having a frame 148 for the textual information associated with the item. The text view window 146 provides the user with several viewing options or operations which will be described hereinbelow. FIG. 12 is an example of a screen display of an item shown in the graphical format. Like the screen display for the textual format, the graphical format is presented via a graphical view window 150 having a frame 152 for the graphical information associated with the item. Returning to FIG. 11 and Table 3, the user may also analyze any comments recorded at the time of check-in for a particular version by selecting a Details button 154 after highlighting the desired version. The comments are preferably stored via the check-in dialog window 124, but other schemes may be utilized to associate data representative of comments with a particular version. The audit trail dialog window 140 further allows the user to select two versions of the item by using a pointer (or other selection mechanism) to highlight the corresponding two records in the table portion 142. Highlighting two records enables the user to initiate a Differences operation by selecting a Differences button 156, which, in turn, causes the VCAT system 98 to generate a Differences window dialog that provides the configuration information for each selected version of the item in a format that permits the user to compare the two versions. The details of the Differences operation will described in greater detail hereinbelow. If only a single record has been highlighted, and the Differences button 156 is selected, the VCAT system 98 will generate the Differences window such that the selected version is compared with the current version of the item stored in the configuration database 100. The audit trail dialog window 140 also generally enables the user to implement one of the prior versions of the configuration of the item. More particularly, the VCAT system 98 may be directed by the user to initiate a routine that accesses the version control database 102 to retrieve the data representative of a prior configuration version in order to modify the data stored in the configuration database 100 in connection with the selected item. The modification of the configuration database 100 may then occur by importing the data from the version control database 102 into the configuration database 100. To implement this "rollback" to a prior configuration version of an item, and in accordance with one embodiment, the audit trail dialog window 140 includes a Rollback button 158 that may be selected by the user once a record in the table portion 142 has been selected. In one embodiment, the VCAT system 98 provides the user with the option to rollback to a configuration that was downloaded to the controller 12 for utilization within the run-time environment. Such a rollback operation may be initiated by selection of a task item such as "Recover download" from a drop-down or context menu, and include the generation by the VCAT system 98 of a specialized audit trail dialog window (not shown) that only lists those versions that were downloaded. As will be described in greater detail hereinbelow, the version control database 102 preferably includes data indicative of whether a version was downloaded for use in the run-time environment. A version may then be selected by the user, the configuration information for which is then retrieved from the version control database 102 by the VCAT system 98 and stored as the latest configuration version. Preferably, the VCAT system 98 determines whether the configuration data import operation is successful by checking for other items in the configuration hierarchy and process that depend upon the item. For example, when a configuration version of a module is being restored, the configuration version may require a certain subordinate item (e.g., composite function) block to exist. The module is then said to have a "dependency" in the sense that the success of the rollback operation is dependent upon the continued existence of that subordinate item. A module may have numerous different types of dependencies, such as embedded function blocks, linked function blocks, enumeration sets, alarm types, other modules, plant areas, and controllers. Accordingly, in one embodiment, the VCAT system 98 checks each subordinate item of the item being subjected to a rollback to determine whether any versionable items have been deleted. In a preferred embodiment, the data imported into the configuration database is checked into the version control database 102 as well as the latest configuration version of the item. The check-in occurs concurrently with the modification of the configuration database 100, and preferably includes the storage of data representative of a comment indicating that the user reverted back to a prior configuration version of the item. Alternatively, the VCAT system 98 may generate a dialog window to provide the user with the option of entering a customized comment, entering a default comment, or no comment at all. If the item was checked out before the rollback task was initiated, the VCAT system 98 may, but need not, keep the item checked out after the rollback task is completed. Lastly, the audit trail dialog window 140 includes a button 160 for dismissing the dialog window 140 and returning the user interface 94 to its previous state. As shown in FIG. 10, one of the actions (other than a check-in operation) recorded in the audit trail report is a label setting operation for the entire process configuration. With reference now to FIG. 13, the user may initiate a Set Label operation by selecting a versionable item within, for instance, one of the modules designed using the configuration applications, and selecting the Set Label task via either a drop-down or context menu generated by the VCAT system 98. In response, the VCAT system 98 generates a Set Label dialog window 162 that includes a label field 164 and a comment field 166. The user is then prompted to enter a label to be applied to the selected item (and subordinate items) in the version control database 102. The latest configuration version of each item stored in the version control database 102 is then assigned the user-entered label. The audit trail data stored in the version control database 102 is also updated to reflect the assignment of the label, which is preferably applied to the latest configuration version. More particularly, the version action in the audit trail configuration history data will reflect that the version corresponds with a newly assigned label having the entered name, and the details associated therewith will correspond to the information entered by the user in the comment field 166 of the Set Label dialog window 162. Setting a label may be advantageous for a process designer in the sense that the process designer may manually note via a label, such as "DOWNLOADED TO CONTROLLER1," which configuration versions of various items were downloaded to the controller 12 for implementation in the process. Preferably, however, the VCAT system 98 automatically assigns a label for each downloaded item to flag the configuration version as having been downloaded to the run-time device. Data representative of further information such as the date and time of the download and the items that were downloaded concurrently may also be stored in connection with the label. The VCAT system 98 may then accordingly provide the capability to revert back the configuration of the entire process, or some portion thereof, to the version associated with a label set via the above-described procedure for each of the affected items in the version control database 102. In one embodiment, this capability applies only to the root (or top level) item in the configuration hierarchy developed using the configuration applications 96. In such case, a "Revert System to Label" task may be initiated when the user has selected the root item and proceeds to select the appropriate task item from a drop-down menu or a context menu similar to the menu shown in FIG. 7. A warning dialog (not shown) may be generated by the VCAT system 98 prompting the user for verification of intent to revert the system back to a label. If the user indicates that a "Revert System to Label" task is desired, the user may then be prompted for the name of the label to which the system will be reverted back. Alternatively, the VCAT system 98 may automatically revert the system back to the last label set in the version control database 102. In any event, once the Revert System to Label task is executed, the VCAT system 98 accesses the version control database 102 to retrieve the data representative of the configuration version associated with the label for each item, and imports the retrieved data into the configuration database 100. The VCAT system 98 then modifies the version control database 102 to reflect the reversion by storing data indicative of a new configuration version for each item as well as data associated therewith that reflects the reversion back to the label. In one embodiment, this data may be associated with the configuration version by storing data representative of a comment that indicates the reversion back to the label. In accordance with one embodiment, the VCAT system 98 preferably still stores data in the version control database 102 that is representative of an item that was deleted or otherwise removed from the configuration database 100. In such a case, the version control database 102 may be relied upon when and if the user decides to revert back to a process configuration utilizing the deleted item. Referring now to FIG. 14, the VCAT system 98 may also enable a user to purge items that have been deleted from the configuration database 100. To that end, the VCAT system 98 generates a Recover/Purge dialog window 168 having a list of such deleted items. The Recover/Purge dialog window 168 may be generated upon selection of a Recover/Purge task item in either a drop-down or context menu. Such a task item may be enabled or other made available to the user after selection of an item within the configuration applications 96. If the selected item has one or more subordinate items that have been deleted from the configuration database 100, the user may initiate the recover operation via the dialog window 168 to add data representative of one or more of the deleted items to the configuration database 100. The Recover/Purge dialog window 168 includes a Recover button 170 for restoring one or more deleted items in the list that have been selected by the user. When restoring a deleted item, the VCAT system 98 may access the version control database 102 to retrieve the latest configuration version of the deleted item, and then import the data associated therewith into the configuration database 100. Alternatively, the VCAT system 98 prompts the user for selection of a prior configuration version to the extent multiple versions are stored in the version control database 102. Selection of a purge button 172 provided in the dialog window 168, on the other hand, results in the removal of any data associated with the item from the version control database 102. Further details regarding the Recover/Purge dialog window 168 are provided below in Table 4.
TABLE 4
Recover/Purge Dialog Window
Name Type Min Max Default Content
Items Check list n/a n/a List of List all subordinate
boxes subordinate items deleted based
items upon a selected
deleted parent.
based upon
a selected
parent
Recover Button n/a n/a n/a Item is restored to
the configuration
database by
retrieving the data
from the version
control database and
importing the item
into the
configuration
database.
Purge Button n/a n/a n/a Item and all audit
trail history data are
removed from the
version control
database
permanently
In accordance with one embodiment of the invention, the VCAT system 98 supports version control and audit trail functionality for items that are not created, developed, or managed by the configuration applications 96. For example, a user may create a document in a word processing program that describes the functionality of a particular item. It would be desirable to store and track any editing of the document as the configuration and, hence, the description, are modified. To this end, the main control window 80 generated by the Explorer system for the user interface 94 is utilized to designate a new version control item. More particularly, the user first expands a "User Workspace" object (i.e., an object in the Explorer system). A task item directed to creating a new folder within the hierarchy frame 82 is then selected by the user, and a new folder is created and named in accordance with known windowing techniques. Similarly, a task item directed to creating a new item is selected, and the user is then provided with the opportunity to browse for a document or file to insert as a new item in the recently created folder. Once the document or file is inserted into the folder, it is then added to the version control database 102 as another item for which versions and version-related information can be stored. Subsequently, any version of the file or document may be retrieved from the version control database 102 using a Get task item made available to the user via a drop-down or context menu. The Get task provides the user with a dialog window (not shown) that prompts for a desired storage location for the retrieved file, such as a floppy disk. The native application utilized to create the file or document (e.g., a word processing application) may then be used to access the contents of the file or document from the designated storage location. With reference now to FIG. 15, the VCAT system 98 preferably generates a message dialog window 174 for display of version control feedback information to the user via the user interface 94. The message dialog window 174 includes a text box 176 in which textual descriptions of each version control operation is documented as it occurs. Generally, the message dialog window 174 permits the user to scroll through a history of the operations that have occurred since a Clear button 178 was last selected by the user. An Abort button 180 is also provided to enable a user to abort a version control operation at the next opportunity. For example, if the user has initiated a rollback operation, execution of the operation by the VCAT system 98 may be ceased via selection of the Abort button 180 unless, for instance, execution of the operation has already been completed. The message dialog window 174 may automatically minimize in accordance with known windowing techniques if version control operations have not occurred for a certain period of time. The message dialog window 174 is then automatically re-displayed on the user interface 94 upon initiation of the next version control operation. The manner in which the VCAT system 98 provides the user with a textual view of the configuration of an item via the textual view dialog window 146 will now be described in connection with FIG. 11. The VCAT system 98 may, but need not, be capable of displaying the configuration information of each item in the version control database 102 in a textual format. As explained above, some items, by their nature, may have configuration information that also may be displayed graphically. The format in which the configuration information for an item is set forth is not pertinent to the practice of the present invention. However, the VCAT system 98 preferably utilizes a textual format that minimizes the amount of horizontal scrolling necessary for user viewing of both a single configuration version of an item as well as when comparing two versions. Furthermore, it is preferred that key words and labels be utilized to identify attributes such as object type and properties. Examples of item-type identifying labels that may be utilized include "PARAMETER," "FUNCTION_BLOCK," and "CONTROLLER." Examples of property labels are "NAME" and "DESCRIPTION." The key words and labels may then be translated to the appropriate language. For example, a Japanese version of the user interface 94 would display the key words in Japanese. Conditional and other logic statements in the language may also be translated into an easy-to-read format for display in the textual view. In one embodiment, the textual format for each item includes delimiting language such as BEGIN and END. For example, as shown in FIG. 11, configuration version number 13 of a module has a parameter delimited by the following BEGIN and END statements: BEGIN Parameter "ABS_PRESS_CF" END Parameter "ABS_PRESS_CF" In another embodiment, the name of the item may not be identified in conjunction with a label, such as in the following example:
BEGIN FUNCTION_BLOCK
NAME = "AI1"
DEFINITION = "AI1"
DESCRIPTION = "Analog Input"
LEFT = 200
TOP = 200
HEIGHT = 125
WIDTH 400
END FUNCTION_BLOCK
The textual view dialog window 146 includes a find button 200, a find down button 202, and a find up button 204. The buttons 200, 202, and 204 generally allow the user to navigate the textual information set forth in the frame 148 in accordance with a character string selected therein with a pointer or the like in accordance with known windowing techniques. To this end, initiating the find operation by selecting the find button 200 may cause the VCAT system 98 to generate a find dialog window (not shown) to facilitate the user's navigation of the frame 148. A character string may then be entered into a field and, the first instance of the string may be found by, for example, selecting an "OK" button (not shown) in the find dialog window. The user may subsequently use the buttons 202, 204 to find instances of the string in either the down or up directions, respectively. Further information with regard to these operations and others provided via the textual view dialog window 146 is set forth below in Table 5.
TABLE 5
Textual View Dialog Window
Name Type Min Max Default Content
Find Button n/a n/a Enabled Allows user to enter
a search string.
Find down Button n/a n/a Disabled Navigates to next
instance of the
search string
Find up Button n/a n/a Disabled Navigates to
previous instance of
the search string
At this point, it would be instructive to describe in greater detail the manner in which the textual information set forth in the dialog window 146 is generated by the VCAT system 98 from the data representative thereof stored in the version control database 102. It should first be understood that the manner in which the version control data is stored is not critical to practice of certain aspects of the present invention. In one embodiment of the present invention, however, the version control data is preferably stored in the version control database 102 in a file-based format. In an alternative embodiment, the data is stored in an object-oriented fashion such that the version control database comprises an object-oriented database. The version control database 102 is preferably administered using the DeltaV.TM. Database Administrator application available from Fisher-Rosemont, Inc. modified to the extent necessary to handle both of the databases 100, 102. Alternatively, the Microsoft SQL Server.RTM. Enterprise Manager may be utilized for this purpose. To generate the textual information representative of the configuration version, the VCAT system 98 executes a routine that generally accesses the version control database 102 to export the pertinent data in a manner that can be translated into either a text- or graphical-based format. To this end, during a check-in operation, the VCAT system 98 stores a text-based representation of the version control data in a file in accordance with a markup language, such as XML (Extensible Markup Language). The text contained in the XML document that is generated at this point may be serialized into a single character string that is stored in the version control database 102. More particularly, in one embodiment, each versionable item may have a database record corresponding to each configuration version. In that case, each configuration version record has a field dedicated to having a single character string of XML text stored therein that represents the version control data associated with the configuration version. Preferably, these configuration version records make up one table of a plurality of tables in the version control database 102, which, in this case, is a relational database. The relational database may include other tables directed to storing the following: (1) whether each versionable item is deleted, the current version identifier, whether the item is currently checked out and, if applicable, to whom; and, (2) the audit trail information for each versionable item. In a preferred embodiment, all of the configuration data necessary to completely define a configuration of an item is separately stored for each version. Alternatively, the configuration data may be stored in manner that only defines the differences between versions, in which case the data associated with multiple database fields would have to be accessed to develop the XML document for a particular version The version control data is thereby set forth in a structured manner that can be easily manipulated and parsed when the version control database 102 is later accessed. To develop the configuration information shown in the example of FIG. 11, the VCAT system 98 interprets the XML representation of the version control data to provide the configuration information in an easy-to-read textual format. The manner in which the XML-formatted data is processed should be readily appreciated by those skilled in the art, but will now be briefly described in greater detail. At the time of the filing of the instant application, XML is a markup language well known to those skilled in the art and believed to be in the midst of the standardization as XML 1.0 by the World Wide Web Consortium (www.w3.org). While other data schemes may be utilized, the use of any one of a number of markup languages is preferred to facilitate the generation of both textual and graphical representations of the configuration of the item. Generally speaking, a document set forth in XML has a logical structure composed of declarations, comments, and processing instructions, as well as nodes that start with a single root (or document) element. For example, a versionable item may have an initial or root "MODULE" element to represent a portion of a control strategy. This MODULE element may contain an attribute node called NAME, which has a text node containing the name of the module. Additionally, the module may contain element nodes to describe the module. Such elements may include, for example, ALGORITHM_TYPE, DESCRIPTION, EXECUTION SPEED, AND MODULE_TYPE. Each of these elements may have a textual node that maintains a value representative of that particular portion of the configuration. The MODULE element node may further include element nodes that contain additional elements, thereby creating a hierarchy. For example, a MODULE may include a STEP, and the STEP may include one or more ACTION elements. The ACTION elements, in turn, include elements such as NAME, DESCRIPTION, ACTION_TYPE, and the like. Thus, the XML format sets forth the version control data with the aid of tags in a manner similar to that found in HyperText Markup Language (HTML) documents. In XML documents, however, the tags may be customized to the types of data being stored, as described above. For example, the function block for which a textual representation was provided hereinabove is set forth below in XML format: <Function_Block> <Name>AI1</Name> <Definition>AI</Definition> <Description>Analog Input</Description> <Left>200</Left> <Top>200</Top> <Height>125</Height> <Width>400</Width> </Function_Block> The data stored in an XML document is accessed in accordance with an object model that provides for parsing the document to create a data tree structure having a plurality of nodes associated with the version control data. Practice of the present invention may utilize any one of several different object models, such as the Document Object Model as applied to XML. Thus, the textual information provided in the textual view dialog window 146 via the user interface 94 is generated by loading the XML text in the database field to create the above-described object nodes for the configuration version. The document object model may then be used to traverse the data structure established by the object nodes in order to extract the configuration information and generate the textual format shown in FIG. 11 for the selected version and item. The graphical view dialog window 150 of FIG. 12 is also generated from the above-described XML-based routine. As will be readily recognized to those skilled in the art, the same XML document utilized to generate the textual information may be able to support a graphical representation, given the necessary objects in the tree structure, together with the knowledge of how certain objects are to be displayed. With a limited number of object types available, such knowledge is provided by the VCAT system 98. For instance, when the XML document indicates that an item is a function block, the VCAT system 98 may initiate a routine for a generic drawing function block and, in so doing, refer again to the data provided in the XML document to draw the function block in accordance with other parameters. It should be understood that not every item may be displayed graphically. However, items that may be displayed graphically include, but are not limited to, those that are generally defined by a function block or sequential flow chart algorithm. The graphical view dialog window 150 that results from a user's selection of a configuration version in the audit trail dialog window 140 provides a user with various options to facilitate review of the configuration. More particularly, the dialog window 150 includes a text view button 206 that allows the user to display the configuration information displayed in the frame 152 in a textual format in accordance with the above-described manner. The text view button 206 may also be directed to a particular subordinate item displayed in the frame 152. More particularly, after a user has selected the subordinate item, the text view button 206 may be selected to view the configuration information of the subordinate item in a textual format. Alternatively, the subordinate item may be selected using a right-click or the like to generate a context menu 207 that provides the text view task as an item to be selected. The dialog window 150 further includes a Display Parent button 208 and a Drill Down button 210. The Drill Down button 210 provides the user with the option to display (to the extent possible) the configuration information for a subordinate item of the originally selected item in a graphical format. Once an item (such as a composite function block 212) displayed in the frame 152 is selected by the user, the Drill Down button 210 is enabled for selection by a user with a pointer or the like. The button 210 may then be selected to "drill" into the subordinate item to display graphical configuration information related thereto. The Drill Down task may also be initiated using the context menu 207. The Display Parent button 208 provides the user with the option to return to a graphical view of the parent item by removing the view of the subordinate item. Alternatively, the subordinate item may be displayed in a separate dialog window such that the display parent operation causes the VCAT system 98 to close the dialog window associated with the subordinate item and thereby return to the graphical view of the parent item. In an alternative embodiment, if no graphical view is available for a subordinate item (because, for instance, it does not constitute a composite function block or a module), then a textual view dialog window will be generated. It shall be understood that eventually the act of drilling into subordinate items within a graphical view dialog window will result in a textual view dialog window. It shall be appreciated that utilizing an XML document generated on-the-fly as an intermediary between the version control database 102 and the generation of the user interface 94 provides an efficient, flexible approach to the presentation of configuration information. More importantly, however, generating an XML document for each configuration version also provides for the rapid and efficient comparison of two versions of a selected item. Comparing versions of an item is useful in the general context of version control to determine what is commonly referred to as "Differences" between versions. With respect to the process control system 10 set forth hereinabove, it would be beneficial to display the differences between two versions of an item both textually and graphically. In a preferred embodiment, the VCAT system 98 generates Differences dialog windows for both textual and graphical presentations of the differences between two versions using the above-described, XML-based processing of the data stored in the version control database 102. Because the tree structure of an XML document is easily parsed in accordance with the object model, two versions of an item may be easily compared by parsing the corresponding two XML documents and comparing the parsed data object-by-object. With reference now to FIG. 16, a textual differences dialog window 220 includes a first frame 222 and a second frame 224 for displaying configuration information for a first configuration version and a second configuration version, respectively. Both horizontal and vertical scrolling of the textual information displayed in each frame 222, 224 is provided for using known windowing techniques. The first frame 222 may set forth the configuration information for an older version (e.g., Version number 13), while the second frame may set forth the configuration information for a more recent version (e.g., Version 14). It should be noted, however, that the versions need not be consecutively numbered, inasmuch as any two versions may be compared by the VCAT system 98. As the older version, the first frame 222 may include one or more lines of text that were deleted as a result of a check-out/check-in modification of the configuration. Preferably, the text associated with such deleted lines is shown in a different color (e.g., blue), font, or style than the remaining text. To denote that blue-colored text, for instance, is representative of a deleted line, a button 226 may include the text "Deleted lines" in a blue color. Similarly, the frame 224 may include one or more lines of text that were inserted as a result of a modification to the configuration of the item. Such lines of text may, for instance, be set forth in a green color, as well as a button 228 having the green-colored text "Inserted Text." Lastly, the content of one or more lines of text may have been changed (but not deleted entirely) between versions. Such lines may be set forth in a red color in both of the frames 222, 224, together with a button 230 having the red-colored text "Changed Text." It should be understood that any color or style scheme might be utilized to differentiate the above-identified types of differences and to set the changed text apart from the text common to both versions. The textual differences dialog window 220 also includes a find button 232, a find down 234, a find up button 236, a Down button 238, and an Up button 240 that provide the same navigational functionality described hereinabove in connection with the textual view dialog window 146. These navigation tools preferably apply to both of the frames 222, 224, such that any vertical scrolling operation initiated by the user results in the scrolling of both frames. In an alternative embodiment, these navigation tools (as well as other standard scrolling techniques in a windows environment) may be applied to one of the frames 222, 224 based upon, for instance, which frame has been selected by a user. The textual information for the versions being compared need not be set forth in a side-by-side manner. For instance, the textual differences dialog window may alternatively include a single frame wherein the common text, changed text, inserted lines, and deleted lines are shown and differentiated via a similar color or style scheme. Differences between the two versions may also be shown in that context by using redlining, underlining, demarcating punctuation, and the like. A graphical differences dialog window 250 is shown in FIG. 17. The graphical differences dialog window 250 is based on a single frame window similar to the graphical view dialog window 150, but may alternatively use a two frame, side-by-side window to juxtapose the versions. To differentiate between common objects, deleted objects, added objects, and changed objects, a color scheme may again be employed. The colors may be applied to the objects as a background color, a border, a matting, an outline, etc. Buttons 252, 254, and 256 are set forth as a key to the color scheme in the same manner as set forth hereinabove in connection with the textual differences dialog window 220. For example, a step item S1 and a transition item T1 are shown with a colored border (e.g., red) to indicate that the items have been modified. A further step item S2 and further transition item T2 are shown with a different colored border (e.g., blue) to indicate that the items have been deleted or removed. It should be noted that the color scheme may also be applied to the lines interconnecting the items. Exemplary changes to an item that are denoted by a colored outline or frame include adding an action to a step and changing the expression of a transition. Changes to the execution order of the function blocks may be denoted by outlining, framing, etc. only the portion of the object dedicated to displaying the execution order. This portion may, for instance, be located at the bottom of an object. In the event that an object was renamed between versions, the color scheme may be employed to show the two versions of the object as deleted and added. Alternatively, the VCAT system 98 may provide the user with the option of only displaying substantive differences between versions, such that cosmetic changes are not displayed. The graphical differences dialog window 250 also includes a Display text button 258 that provides the same functionality as the button 206 with respect to both the selected item and any subordinate item. If a subordinate item is shown as having been modified, the VCAT system 98 provides the user with the capability of drilling into the item (through appropriate selection thereof) to generate either a textual differences dialog window or another graphical differences dialog window for that subordinate item. In one embodiment, drilling down is only available for those items for which a graphical dialog window may be generated. In general, however, which type of dialog window will be generated depends on the type of item as explained hereinabove. Drilling into a subordinate item may also be initiated by selection thereof followed by selection of a drill down button 260. A return to the previous graphical differences dialog window 250 may be accomplished by selection of a Display Parent button 262 that operates in the same manner as the button 208. When an item that has been removed is at the same location in the graphical differences dialog window as an item that has been added, one of the items may be obscured. Additionally, when a comments is changed, the old comment will not be visible in the graphical view. To allow the user to see the hidden item or comment, the VCAT system 98 may provide a mechanism (via a menu item or selection sequence using a pointer or the like) to toggle between which item or comment is shown (i.e., on top) and which item is obscured from view. In a preferred embodiment, the above-described textual view and graphical view dialog windows, including those directed to viewing differences, include a button or task item sequence that permits a user to toggle between textual and graphical displays. The VCAT system 98 would preferably only include such functionality on dialog windows for items that can be displayed in both formats. It should be understood that the VCAT system 98 may impose a security check on the version control environment. For example, for an operation (e.g., rollback) that requires a certain level or type of authorization, the VCAT system 98 may determine before executing the operation whether the user is authorized to initiate the operation. When a new user is added to the VCAT system 98, the VCAT system 98 may generate a new user dialog window (not shown) having a plurality of checkboxes corresponding with a plurality of VCAT operations that may be selected or not selected to provide the user with a desired amount of authorization. It should be further understood that the VCAT system 98 may provide a user having appropriate authorization with the option of enabling or disabling the VCAT system 98. Once disabled, the VCAT system 98 would allow the configuration applications 96 to operate without imposing the check-out/check-in and other procedures. When re-enabled, the VCAT system 98 preferably performs a synchronization routine that accesses the configuration database 100 to compare the current configuration data with the latest configuration data stored in the version control database 102. For each item that encountered a configuration modification during the period that the VCAT system 98 was disabled, a new configuration version is added, and data representative of the current version in the configuration database 100 is stored in association therewith. New items may also be created in the version control database 102 to the extent necessary. Furthermore, a label may be assigned to all items in the version control database 102 to denote that the VCAT system 102 has been re-enabled. The synchronization routine may also be executed at any time. In certain instances, it should be appreciated that the VCAT system 98 may have to initiate one or more undo check-out operations and/or check-out operations to the extent necessary to modify the version control database 102. The VCAT system 98 may also include a database backup/restore routine similar to the routine utilized to backup and restore the configuration database 100 administered by the Explorer system. Other common database utilities, such as a "Clean Database" routine directed to repairing the data storage structure of the version control database 102, may also be included as part of the VCAT system 98. The user interface 94 is preferably not the only output device by which version control information is provided to the users and operators of the VCAT system 98 and configuration applications 96. More particularly, one or more routines may be implemented by the VCAT system 98 to support the generation of reports for delivery to a printer or other display device. For example, the VCAT system 98 may provide the user with the ability to select task items directed to generating reports that present version control information related to which items are checked out, the audit trail of a particular item, the items checked out by a particular user, any deleted (but not purged) items, and a list of check-outs by date or some other parameter for which data may be stored in the version control database 102. Such information may be provided via any display device, whether located locally or remotely, and may be delivered in a format or in accordance with any protocol. To facilitate the generation of such reports, the VCAT system 98 preferably includes a query system. The query system generally permits the user to specify search criteria directed to any number of subjects, such as modifications or actions by a particular user, modifications or version control events that occurred during a specified time frame, modifications or version control events that occurred within a specific version or label, and modifications or version control events that relate to a specific item or an area of items. After the user has entered the one or more criteria for a query, the VCAT system 98 will initiate a search routine that accesses the version control database 102 and analyzes the contents thereof. In a preferred embodiment, the VCAT system 98 executes the search routine in a background manner, such that other version control operations may be initiated and executed concurrently therewith. The query system may generate one or dialog windows for display via the user interface 94. Examples of two such dialog windows are shown in FIGS. 18 and 19. A history report options dialog window 280 may be generated after selection of an item followed by selection of a task item directed thereto via either a drop-down menu or context menu. The dialog window 280 provides checkboxes directed to whether the history report to be generated will include version control information concerning labels and subordinate items. A user field 282 is also provided to allow the history report to be directed to the modifications or version control events that were initiated by a specified user. Lastly, a "From date" field 284 and a "To date" field 286 may be used to specify a time period for the history report. To facilitate the entry of the starting and ending dates for the time period, a pop-up calendar or exemplary dates may be provided in a window generated for each field 284, 286 in accordance with known windowing techniques. With reference to FIG. 19, the query system may generate a general search dialog window 290 that includes a status search portion 292 and a search area portion 294 for identifying certain search criteria. The status search portion 292 includes checkboxes for instructing the VCAT system 98 to search for all checked out items or items checked out to a certain user. The user may be specified via a user field 296 having the capability of suggesting user names via a drop down window. The search area portion 294 includes several checkboxes that permit the user to search the version control information relating to only the selected item, the selected item and all subordinate items, or all items in the version control database 102. The screen displays of FIGS. 5-9, as well as other screens, may be created and modified using a windows-type format with standard windows-type commands, although any other format could be used as well. The format of these screen displays may be changed dramatically, for instance, in the event the VCAT system 98 is used in conjunction with configuration applications other than the Explorer system or the other applications specified hereinabove. Although the configuration applications 96 and the VCAT system 98 described herein are preferably implemented in one or more software routines, they may be implemented in a routine embodied in hardware, firmware, etc., and may be implemented by any other processor associated with the process control system 10. Thus, each of the operations and procedures described hereinabove may be implemented in a standard multi-purpose CPU or on specifically designed hardware or firmware as desired. When implemented in software, the software routine may be stored in any computer readable memory such as on a magnetic disk, a laser disk, or other storage medium, in a RAM or ROM of a computer or processor, etc. Likewise, this software may be delivered to a user or a process control system via any known or desired delivery method including, for example, on a computer readable disk or other transportable computer storage mechanism or over a communication channel such as a telephone line, the internet, etc. (which are viewed as being the same as or interchangeable with providing such software via a transportable storage medium). Thus, while the present invention has been described with reference to specific examples, which are intended to be illustrative only and not to be limiting of the invention, it will be apparent to those of ordinary skill in the art that changes, additions or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.
|
Same subclass Same class | ||||||||||