Field Device Loop WarningSmart Notification of Parameter Changes

Abstract

To provide a system for preventing unnecessary or early parameter change of an active online field device from a secondary system different from a dispersion control system application which provides a control command to an online field device.SOLUTION: Parameter changes may cause detrimental effects to a plant process or activity. A request for a parameter change from a secondary system may be intercepted before the request is received by a field device or a controller for evaluation by an operator of a distributed control system. A validation process may provide a plant operator with override authority to approve or deny a set of critical parameter changes to an active field device or other active plant devices.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present disclosure relates generally to process control systems, and more specifically, to a process control system that is communicatively coupled to a separate secondary system that has independent access to the process control system's devices, and where write commands to plant devices are verified between the two systems. [Background technology]

[0002] A distributed control system (DCS) of a plant may include field devices, input / output (I / O) devices, controllers, and operator workstations. This distributed control system may include applications necessary to coordinate and control various processes of the plant. Other auxiliary tools and applications may be developed to support plant operations but may not be part of direct plant control. Such functions may include maintenance and health management of devices that may be performed by an asset management system or an asset maintenance system. Because maintenance and health monitoring functions traditionally require access to plant devices (sometimes direct physical access to plant devices by instrumentation engineers), the development of asset management systems may introduce independent access to field devices that are actively controlled by the DCS in live plant operations.

[0003] Because independent communication paths may exist between AMS and DCS applications for the same set of plant devices, situations exist where an instrumentation engineer may initiate a write command to a field device that may change the active control process without knowledge or approval from a user on the operational side of the process control system, such as a DCS operator. Because the operator may have more knowledge regarding the currently active processes of the plant being controlled by the DCS, the method and system may provide a validation process that involves active input and information from the DCS side before a write command can be executed or committed to the plant device. Summary of the Invention

[0004] The present disclosure describes a distributed control system including at least one controller and one field device, and a second system having independent access to the DCS plant device, where a write command from the second system to the DCS plant device is intercepted for an approval process. The approval process may include sending a notification to a DCS workstation to alert an operator that a write command or parameter change command of the DCS field device or other plant device is intercepted. This process may involve the DCS workstation sending an approval decision regarding the parameter change command. The approval decision may then be used to release the intercepted parameter change command for execution or commit in the field device or other plant device, or to terminate the parameter change command.

[0005] In some embodiments, intercepting the parameter change command is performed by a security service module. The security service module may be a component of the second system, or in some embodiments, the security service module may perform some of its functions independently of the second system. In some embodiments, a workstation of the second system may receive the approval decision from the DCS and display a message corresponding to the approval decision to a user of the second system. In some embodiments, the second system may be an asset management system or an asset maintenance system to provide health monitoring and maintenance to plant devices. [Brief description of the drawings]

[0006] [Figure 1] 1 is a block diagram of a distributed process control network located within a process plant or other industrial setting including industrial computing devices each having a platform that uses a communications architecture. [Diagram 2] 1 illustrates an asset management system (AMS) that may be coupled to a distributed process control system (DCS). [Diagram 3] 1 illustrates an example system in which an AMS may share a communication network with a DCS to communicate with plant devices. [Figure 4] 1 illustrates another system in which the AMS is coupled to the DCS through one communication network, while communicating with plant devices using a separate communication network. [Diagram 5] 1 illustrates an example warning screen of the AMS user interface without an approval process. [Figure 6] 3 illustrates a system similar to that of FIG. 2 with the addition of a security services module communicatively coupled between the AMS workstation and the DCS operator workstation. [Figure 7A]4 illustrates the system of FIG. 3 with the addition of a security services module communicatively coupled between the AMS workstation and the DCS operator workstation. [Figure 7B] 7B illustrates a communications architecture similar to that of FIG. 7A with a security services module communicatively coupled to a common network instead of being directly coupled between the AMS and DCS workstations. [Figure 7C] 5 illustrates the system of FIG. 4 with the addition of a security services module communicatively coupled between the AMS workstation and the DCS operator workstation. [Figure 8] SUMMARY OF THE DISCLOSURE An exemplary method for validating or authorizing write or parameter change commands to plant devices in a distributed control system is disclosed. [Figure 9] 9 illustrates a dashboard view of a portion of a process in a plant, illustrating a possible controller graphical user interface 900 with an overlay of a distributed control system. [Figure 10] 1 illustrates possible alerts that may be displayed on an operator workstation of a DCS to indicate that a parameter change command has been intercepted. [Figure 11] 13 illustrates an example of a possible message corresponding to an acknowledgment response from a DCS to a parameter change command. [Figure 12] 13 illustrates a possible message corresponding to a rejection response from a DCS to a parameter change command. [Figure 13] Illustrates a particular embodiment in which the AMS is implemented as a Field Device Integration (FDI) server component. [Figure 14] 1 illustrates an authorization system using a mobile computing device with wireless access to DCS and plant devices. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] FIG 1 illustrates a process control system 12 of a process plant 10. More particularly, the process control system 12 may represent a distributed process control system or DCS. The process plant 10 also includes one or more host workstations, computers, or user interfaces 16 (which may be any type of personal computer, workstation, etc.) that are accessible by plant personnel, such as process control operators, maintenance personnel, configuration engineers, etc. In the example illustrated in FIG 1, the user interfaces 16 are shown as connected to process control nodes 18 and a configuration database 21 via a common communication line or bus 22. The communication network 22 may be implemented using any desired bus-based or non-bus-based hardware, using any desired hardwired or wireless communication structure, and using any desired or suitable communication protocol, such as the Ethernet protocol.

[0008] Generally speaking, the nodes 18 of the process plant 10 include process control system devices connected together via a bus structure that may be provided on a backplane to which the different devices are attached. The nodes 18 (which may represent multiple nodes) are illustrated in FIG. 1 as including a process controller 24 (which may represent multiple controllers) and one or more process control system input / output (I / O) devices 28, 30, and 32. Each of the process control system I / O devices 28, 30, and 32 is communicatively connected to a set of process control related field devices, illustrated in FIG. 1 as field devices 40 and 42. The workstations 16, the process controller 24, the I / O devices 28-32, and the controller field devices 40 and 42 generally form the distributed process control system (DCS) 12 of FIG. 1.

[0009] Process controller 24, which may be, by way of example only, a DeltaV™ controller sold by Emerson Process Management or any other desired type of process controller, is programmed to provide process control functions (using what are commonly referred to as control modules) using I / O devices 28, 30, and 32, and field devices 40 and 42. Specifically, controller 24 implements or monitors one or more process control routines (also referred to as control modules) stored in or otherwise associated with memory 75, and communicates with field devices 40 and 42 and workstation 16 to control process 10 or portions of process 10 in any desired manner. Field devices 40 and 42 may be any desired type of field device, such as sensors, valves, transmitters, positioners, etc., and may conform to any desired open, proprietary, or other communications or programming protocol, including, for example, any fieldbus protocol, such as the HART or 4-20ma protocols (as illustrated for field device 40), the Foundation® Fieldbus protocol (as illustrated for field device 42), or the CAN, Profibus, AS Interface protocols, to name just a few. Similarly, I / O devices 28-32 may be any known type of process control I / O device using any suitable communications protocol(s).

[0010] A common backplane 76 (indicated by the dashed line passing through the controller 24 and the I / O devices 28-36) is used in each of the nodes 18 to connect the controller 24 to the process control I / O cards 28, 30, and 32. The controller 24 is also communicatively coupled to the bus 22 and acts as a bus arbitrator for the bus, allowing each of the I / O devices 28-32 to communicate with any of the workstations 16 via the bus 22.

[0011] FIG. 1 illustrates that multiple workstations 16 may be coupled to the DCS. The workstations may be programmed to run standard operational control applications for operating a plant. These standard operational control applications may involve controlling and manipulating plant processes using field devices and therefore may be considered part of the DCS. In addition to the workstations used to operate the plant, some workstations may be coupled external to the bus 22 and run applications for secondary functions other than DCS operational control. That is, these applications may have access to plant devices that are not directly involved in the operational control of the plant, such as maintenance and monitoring of the plant devices. One such application is an asset management system.

[0012] Figure 2 illustrates an asset management system (AMS) 200 that may be coupled to a distributed process control system (DCS) 112. Similar to Figure 1, the DCS 112 of Figure 2 may include at least an operator workstation 116, at least one controller 124, at least one I / O device 128, and one or more field devices 140. Figure 2 illustrates that each of the plant devices (124, 128, 140) of the DCS 112 may communicate using communication lines 151, 152, 153, or 154 within the DCS system.

[0013] 2 illustrates that the devices of DCS 112 may be communicatively coupled to AMS 200. AMS 200 may include a computer or workstation 201, which may represent multiple workstations or computing devices that may be used to perform maintenance functions on plant devices. Workstation 201 may provide a user interface to, for example, an instrumentation engineer whose role is to monitor and maintain one or more of the devices of DCS 112. DCS 112 may be under the control of one or more plant operators who interact with DCS 112 through one or more operator workstations 116 using DCS control programs. AMS computing device 201 may also represent a network of one or more workstations or servers that provide monitoring and maintenance functions to multiple users.

[0014] In general, AMS 200 may manage information related to one or more of the devices or components of DCS 112. In some industries, asset management system (AMS) 200 may also be referred to as an asset maintenance system. AMS 200 may monitor and collect information from plant devices and perform diagnostics to identify different fault symptoms of the plant devices. For example, through the functions and tools of AMS 200, the overall health and life of the plant devices and assets may be ascertained and recorded. During operation, AMS 200 may perform various tests on the plant devices to obtain information for calculating the device health and maintenance requirements of the plant devices. In some embodiments, AMS 200 may perform read and write operations on plant devices, such as controllers 124, I / O devices 128, field devices 140, and any other plant devices. Based on the diagnosis made by AMS 200 on the information extracted from the plant devices, AMS 200 may be programmed to prompt a user to adjust or modify parameters of the plant devices, such as controller 124, I / O 128, or field devices 140, to improve their efficiency. A typical user of AMS 200 may be an instrumentation engineer. In some embodiments, AMS 200 may be programmed to automatically adjust or modify parameters of the plant devices, such as controller 124, I / O 128, or field devices 140, to improve their efficiency.

[0015] As illustrated by FIG. 2, the AMS 200 may be communicatively coupled to one or more devices 124, 128, 140 of the DCS 112, separate and independent from the DCS 112. The communication lines 251-254 may represent separate or isolated communication networks independent of the communication and control networks 151-154 of the DCS 112. For example, as illustrated in FIG. 2, the AMS may have physical communication lines 251-254 and ports (not shown) to one or more of the devices of the DCS that are separate from the communication lines 151-154 and ports used by the devices to communicate with other components or devices of the DCS 112. In some embodiments, the AMS 200 may communicate with the devices of the DCS 112 via logical ports other than those used by the DCS 112 to transmit control signals or to communicate between the devices of the DCS 112. Because of the separate and independent communication paths between the AMS 200 and the DCS 112 to the plant devices 124, 128, 140, the instrumentation engineer may modify the plant devices 124, 128, 140 without the knowledge or approval of the plant operator if the modification is unnecessary or could have a damaging effect on the current plant process.

[0016] 3 illustrates a system in which the AMS 200 may share a communication network 160 with the DCS 112 to communicate with the plant devices 124, 128, and 140. The AMS 200 and DCS 112 in FIG. 3 may be similar to those in FIG. 2 and are similarly labeled. The shared communication network 160 may be, for example, an Ethernet network. Although communications between the plant devices and the AMS and DCS may share a common communication network, line, or link 160 to the controller 124, field device 140, or other plant devices, the AMS may be able to communicate directly with the plant devices 124, 128, 140 and send commands that change or modify parameters of the plant devices 124, 128, 140 without first communicating with or through the DCS system 112 or an operator application (e.g., running on the workstation 116). In the system of FIG. 3, the AMS 200 and DCS 112 may communicate directly with the controllers 124 or field devices 140 or any other devices of the plant using a common plant network 160; the AMS 200 does not need to communicate through the DCS 112 via a controller application running on the workstation 116. More specifically, the systems of FIGS. 2 and 3 illustrate that the AMS 200 may have the ability to unilaterally make parameter modifications to plant devices, such as the controllers 124, I / O 128, and field devices 140. To simplify further discussion regarding parameter modifications to plant devices, it should be understood that where AMS-initiated parameter modifications are described as being applied to controllers or field devices, in any embodiment described or claimed herein, the AMS may be capable of making the same or similar parameter modifications to any or all of the components of the DCS (e.g., servers, workstations, controllers, I / O, field devices, etc.).

[0017] FIG. 4 illustrates another system in which an AMS is coupled to a DCS. In the architecture of FIG. 4, the DCS and AMS may be communicatively coupled to each other via a communication network 160 connecting between a workstation 201 of the AMS 200 and a workstation 116 of the DCS 112. In this situation, there may be some level of information exchange between the two systems, but they may still perform field device modifications independently of each other. Although the systems of FIGS. 2-4 may include a shared communication line between the AMS 200 and the DCS 112, problems may still arise when the actions of a user, such as an instrumentation technician of the AMS 200, conflict with the operation of the DCS 112 controller of the plant in a potentially damaging manner. This conflict may arise simply because the operator currently engaged in managing the process has a higher level of knowledge and awareness of the current process activity in the plant than the instrumentation technician, whose maintenance duties are more routine.

[0018] In general, the AMS 200 may collect information from the plant devices 124, 128, 140 to determine the health of the various plant devices and improve the operation of the devices. In this manner, the AMS 200 may assist instrumentation engineers in providing maintenance, upkeep, and updates to the field devices. The AMS 200 may prompt the user to make adjustments based on its calculations, or in some systems, the AMS 200 may automatically make a set of adjustments. In many situations, collecting the information needed to determine the health and provide the proposed adjustments requires that one or more tests be performed on the target plant device, such as 124, 128, or 140. During the course of the tests, it may be necessary to modify one or more device or configuration parameters. Thus, at least two situations may require modification of the parameters of the controller or field device by the AMS during the test and during the post-test device modification.

[0019] However, problems may arise when the device is active or commissioned, such as when using the AMS 200, or when testing is initiated or adjustments are made by a user outside the operating environment of the DCS 112. Testing of devices in the DCS 112 is ideally performed when the field devices 124 are inactive or offline, but taking the devices offline may be impractical or difficult. This may be the case when critical processes are currently taking place and when the plant process cannot be shut down. Similarly, situations may arise when an instrumentation engineer needs to test a plant device that is exhibiting a fault or showing signs of a possible failure or degradation of functionality while the device is operational and active.

[0020] Assuming that the systems of Figures 2-4 allow a secondary system, such as an AMS, to make modifications to plant devices external to the DCS, conflicts may arise when a maintenance procedure (e.g., a write command) involving parameter modification of an actively commissioned field device may result in damaging operational changes in a live process. Although an instrumentation engineer may be trained to be careful in determining whether a test on a DCS field device or a write command may adversely affect or disrupt an active plant process, often the instrumentation engineer may not be informed at the time that all processes in the plant may be adversely affected by modifying the plant device. In at least some cases, the instrumentation engineer may not have the current situational awareness of the process that a DCS plant operator may possess. In these situations, potential hazards may exist when active plant devices are modified without the knowledge of the plant operator. Although this problem is described herein as existing between the AMS and the DCS, this problem may be generalized to plant systems in which an independent system external to the DCS may independently modify parameters of plant devices within the DCS.

[0021] In some existing systems, a simple warning screen may be presented to a user at an AMS terminal or workstation to warn the user that modifying a parameter may adversely affect the system. FIG. 5 illustrates an exemplary warning screen. In this embodiment, several important variables known to have a significant effect on active plant devices may be categorized into a high priority set, and a warning process may be implemented upon attempting to modify these parameters. In some systems, this high priority set may be designated a set referred to as loop_warning_variables. In some embodiments, loop_warning_variables may include parameters that may significantly alter the process control loop current in a module or section of the plant. In systems with a set of loop_warning_variables, the warning screen of FIG. 5 may be displayed whenever an attempt is made to modify a parameter in loop_warning_variables. In some embodiments, loop_warning_variables may be a set of parameters that may have a significant effect on the process control loop current, as defined by thresholds.

[0022] 5 may warn or alert a user to possible problems with modifying a high priority parameter set (e.g., loop_warning_variables), but the warning may not prevent modifications or write commands from being performed on plant devices where the operator has more knowledge of the dangerous consequences. Specifically, a simple warning screen may not reduce conflicts with plant operations that an AMS instrumentation engineer may not have knowledge of.

[0023] 6-8 illustrate that a first system (such as DCS 112) having access to plant devices 124, 128, and 140 as well as a second system (such as AMS 200) having access to the same plant devices 124, 128, and 140 may be communicatively coupled to a security services module (SSM) 300 that can provide a change approval process between a user of an AMS workstation 201 attempting to modify the plant devices 124, 128, 140 and an operator of a plant control system of DCS 112 actively managing the plant devices in a live plant operation. In these architectures, the security services module (SSM) 300 may intercept write commands or parameter change commands being sent to field devices or other plant devices until an approval process has occurred. In some embodiments, only write commands that include loop_warning_variables may be subject to or intercepted by the security services module for approval. In other embodiments, all write commands may be subject to the security services module for approval first. For convenience, many of the embodiments and descriptions herein relate to intercepting parameter change commands for field devices. However, it should be noted that unless otherwise specified, the methods, processes, and systems described herein may be equally applicable to intercepting parameter change commands for any plant device. Plant devices may include field devices, input / output devices, process controllers, and any other devices that may be modified independently of the control and communication structure of the DCS, including field devices, input / output devices, and process controllers. The term process control device may include filed devices, input / output devices, and process controllers.

[0024] 6-8 illustrate various ways in which the SSM may be communicatively coupled to the AMS and DCS. FIG. 6 illustrates the system of FIG. 2 with the addition of a security services module 300 communicatively coupled between the AMS workstation 201 and the DCS operator workstation 116. Similar to the architecture of FIG. 2, the AMS 200 and DCS 112 of FIG. 5 have separate and independent access to plant devices 124, 128, and 140. In the system of FIG. 5, the SSM may be able to coordinate between the AMS and DCS to intercept parameter change commands generated by the AMS for further approval processing.

[0025] FIG. 7A illustrates the system of FIG. 3 with the addition of a security services module 300 communicatively coupled between the AMS workstation 201 and the DCS operator workstation 116. Similar to the architecture of FIG. 3, the AMS 200 and DCS 112 of FIG. 7A share a common network link 160 for communicating with the plant devices 124, 128, and 140, and the two systems 200 and 112 have the ability to access the plant devices independently, except for the SSM 300, at which point it can intercept write commands from the AMS workstation 201 and abort commands pending approval from the DCS workstation 116. FIG. 7B illustrates an architecture similar to that of FIG. 7A with a security services module communicatively coupled to the common network 160 instead of being directly coupled between the AMS workstation 201 and the DCS workstation 116. In both FIGs. 7A and 7B, the SSM 300 can perform its function of intercepting parameter change commands and aborting those commands until the approval process has taken place.

[0026] FIG. 7C illustrates the system of FIG. 4 with the addition of a security service module 300 communicatively coupled to the AMS workstation 201 and the DCS operator workstation 116. Also similar to the architecture of FIG. 4, each of the AMS workstation 201 and the DCS workstation 116 may have independent physical communication line access to each of the plant devices, but share a common network 160 between each other. In this architecture, the SSM may be able to utilize the same common network 160 between the AMS 200 and the DCS 112 to perform its intercept function. In an embodiment, as described further below, the AMS may be programmed to communicate with the SSM to seek approval before generating or sending any parameter change commands. In some embodiments with the architecture of FIG. 7C, the process control device (e.g., controller or field device) may block write access and require a token or unlock key from the SSM before a parameter change command can be received by the process control device.

[0027] 8 illustrates a method for authorizing or approving a write command or parameter change command of a plant device in a distributed control system. A write command or parameter change command may be a request for a parameter change, a set of instructions for a parameter change, or any modification command that, when received by a plant device, may cause a parameter change to be performed, committed, or otherwise implemented.

[0028] At block 810, the system may intercept a write command for a parameter change to a field device. A security service module may perform the interception. The security service module may be a component of a server or workstation of a second system different from the DCS, such as an AMS. Alternatively, the interception function may be implemented as an executable program on a server that manages a common communication network between the second system and the DCS. At block 812, the system may determine whether the command is a critical parameter change. If the command is not for a critical parameter change, at block 814, the system may optionally prompt a user to confirm that the parameter change command is correct and whether to allow or pass the command. If the user confirms the command, at block 816, the command may be sent and / or committed to the plant device. In some embodiments, the DCS system may have a programmed or defined set of critical high priority variables, such as a loop_warning_variables set, that the system recognizes as critical or high priority. In these embodiments, write or change commands to parameters or variables other than the set of loop_warning_variables are considered non-critical and may be used to distinguish between critical and non-critical parameter sets in block 812. If the user rejects the command, in block 817 the command may be terminated.

[0029] If, at block 812, it is determined that the command is for a critical parameter change, then, at block 818, the system may abort the command of the critical parameter change of the field device. Aborting the sending of the command may involve placing the command in a holding state or status. In some embodiments, aborting the change command may involve placing the command in a temporary hold queue or cache until it is processed or approved (discussed further below) and then released (e.g., if approved) or terminated (e.g., if rejected). Note that the command at decision block 812 may apply to embodiments in which only critical or high priority parameter changes are intercepted and aborted from undergoing the approval process. However, in other embodiments, the system may intercept all parameter changes from secondary systems to the field device. In this case, the process bypasses block 812 and proceeds directly from block 810 to block 818.

[0030] At block 820, the system may alert the DCS that a write command from a secondary system (e.g., a system outside the DCS) has been intercepted. Block 820 may generate and send an alert or warning message to a distributed process control system (DCS) user interface device indicating that a critical parameter change command has been intercepted. When a DCS user interface, such as the workstation 116 of the DCS 112, receives an alert, the user interface may show the alert on top of an existing DCS control display. FIG. 9 shows a dashboard view of a portion of a process in a plant and illustrates a possible controller graphical user interface 900 with a distributed control system overlay. FIG. 9 shows a graphical representation of a portion of a process plant 910 being managed by a DCS application and illustrates one or more field devices 940 positioned around the activity in the plant. This graphical user interface (GUI) 900 may represent an operator monitoring a DCS application running on any one or more of the workstations 16 of FIG. 1. In general, an operator may use the GUI 900 to monitor plant processes and coordinate and schedule plant devices (e.g., controllers and field devices) by communicating through a set of input output I / O devices or interfaces. FIG. 9 may illustrate a bird's-eye view and dashboard view of the plant and processes, where a controller can monitor key parameters 956 in and around the plant 910 with the ability to look up more detailed information on any particular section or device. During normal operation of the plant, this screen may be interrupted by alarm messages from the SSM 300, as illustrated in FIG. 10.

[0031] At block 822, the system may display a message on a user interface device of the DCS. The message may inform a user of the DCS that an attempt or request to change a critical parameter of a field device is on hold, pending operator approval or operator feedback. FIG. 10 illustrates a possible message prompt 1010 that may be displayed on an operator workstation of the DCS. The message prompt may include at least some of the following fields: the command or request issued by the entity or user 1012, the intended plant device of the command or request 1014, the node or module of the plant device 1016, the target parameter of the modification 1018, the target parameter change to be made or the request to be made (not shown), the application or system 1020 that is making the change, safety guidelines associated with the commitment of the change 1022, and a prompt 1024 to allow or deny the command or change request.

[0032] In some embodiments, additional parameter information may be provided to the operator by querying an event chronicle database. The event chronicle database may be a database maintained by the DCS for recording information about all parameter changes made by the DCS to a plant device, such as a controller or a field device. The event chronicle may include a record including at least some of the following fields: date, time, user ID, device ID, parameter name, parameter value change, and effect. In general, the effect field of the event chronicle may provide information of any change in the plant device and the process or sub-process corresponding to the parameter change in the plant device. The effect field may additionally indicate any adverse effects or additional warnings regarding the parameter change, such as, but not limited to, adverse effects or fault events due to the parameter value change. In some embodiments, the additional field of the event chronicle may be an operator's observation or note that provides specific details or an operator's perspective for the parameter value change. The details may include warnings regarding possible missteps or correlated parameter effects that need to be considered when adjusting the parameter value in the future. In some embodiments, the event chronicle may include a record field that provides warnings of the parameter change. For example, a warning may indicate that a parameter value change is in progress or correlates to a scheduled event and therefore should not be made at a particular time.

[0033] At block 824, the system may send a response from the DCS user interface device to the AMS user interface device indicating whether the controller or field device critical parameter change was approved, denied, or rejected. In some embodiments, this response may be sent when the operator clicks on the approve or reject button 1024 in the DCS user interface graphical user interface as shown in FIG. 10. Once the DCS response is sent, the approval process may return to the AMS and at block 826 the AMS workstation may display the response from the DCS operator. FIG. 11 illustrates a possible message prompt 1110 that corresponds to a response from the DCS and is displayed in the AMS user interface.

[0034] The AMS system may receive and process the response from the DCS at block 826. In some embodiments, processing the response in the DCS may involve displaying the response to the critical parameter change command or information of the response on a user interface device of the AMS. In some embodiments, the process may verify whether the response from the DCS was acknowledged at block 828 and may release the intercepted parameter change command at block 830 or otherwise terminate the parameter change command at block 832.

[0035] FIG. 11 illustrates one embodiment of a graphical user interface (GUI) that may be displayed on a user interface (e.g., a workstation) of an AMS when a response to a critical parameter change is approved. Specifically, the GUI may be displayed to a user, such as an instrumentation engineer, indicating the response from a DCS operator. It may include some of the following: an identification of the affected plant device 1122, an identification of the affected module 1124, and a safety message 1126 related to the parameter change. The GUI may also include other relevant information not shown in FIG. 11, such as an identification of the parameter and requested parameter change (e.g., the value of the parameter), a reason for the determination, an indication of whether the change request was approved or rejected, etc. It should be noted that in some embodiments, the GUI of FIG. 11 may indicate approval by default, since there is no indication that the parameter request is rejected.

[0036] In some embodiments, blocks 826 and 828 may allow the user to perform additional confirmation or validation of the parameter change command that the DCS has approved. In some embodiments, the GUI of FIG. 11 may also include a field for the AMS operator to include the reason for the modification 1128, and a final validation or validation check button 1130 that prompts the user to validate the write command or reject it. If the user chooses to approve and apply the changes at block 828, the write command may be released from the AMS to the plant device for execution or commitment at block 830. If the user chooses not to apply the changes, the write command may terminate at block 832. In some embodiments, upon approval, the write command may be routed to the DCS for commitment to the field device. In this embodiment, the DCS may send the write command for commitment.

[0037] If the response from the DCS operator is a rejection of the critical parameter change, the system may display a response message as illustrated in Figure 12. Figure 12 illustrates a GUI 1200 that may include the following fields: an indication that the change request was rejected 1210, an identification of the affected plant device 1212, an identification of the control module of the plant device 1214, and an identification of the parameter and / or requested parameter change (e.g., the value of the parameter) 1216.

[0038] At block 832, the AMS or security services module (SSM) may terminate the critical parameter change command. This termination may be automatic immediately upon receiving a rejection response from the DCS, or in some embodiments, this termination may be delayed until the user indicates or acknowledges (e.g., via a screen prompt) that they receive the response message. In some embodiments, the display of FIG. 12 may include a button for acknowledging receipt of the message by a user of the AMS user interface. In this embodiment, the command may not be terminated until the user clicks a button indicating that the command is terminated or will not otherwise be executed. In general, the described methods and systems may apply priorities and authority to the DCS operator to terminate or permanently block or otherwise disable or delete the change command from the system. In embodiments where the change command is pending or in a queue, at block 832, the change command may be marked or flagged or tagged for deletion.

[0039] In some embodiments, a parameter change command may include multiple parameter changes. In some situations, the multiple parameters may include changes to critical parameters, such as those in the loop_warning_variables set, as well as non-critical parameters. In some embodiments, non-critical parameters may be low priority parameters that may have less impact on the process under the control of the plant device. In this embodiment, the described system may allow changes to non-critical parameters to be made even if changes to critical loop_warning_variables are rejected or rejected. In some embodiments, the write command is put on hold such that all parameters in the command are aborted until a decision is made regarding the critical parameters. The GUI of FIG. 12 may illustrate a case where multiple parameter changes include non-critical parameters. In this case, the GUI of the response message may include fields for the AMS operator, including a reason 1228 for modifying the non-critical parameters and a final verification or confirmation check 1230. FIG. 12 illustrates a GUI where a rejection of a critical parameter change is shown along with a prompt 1230 for the user to determine whether they want to proceed with the parameter change command for the non-critical parameters in the change command parameter set without the critical parameter change. As discussed above, in some embodiments, even changes to non-critical parameters, such as parameters other than the set of loop_warning_variables, may require DCS operator approval. The response GUI of Figure 12 may include other information not shown, such as the DCS operator's reason for rejection.

[0040] In some embodiments, critical parameter changes may be disabled or otherwise blocked from transmission while allowing non-critical parameter sets of the change command to pass or be released. In some embodiments, the AMS server may simply modify the change command parameter set to implement only those parameter changes that are not rejected by the operator. For example, in one embodiment where the change command includes instructions for a parameter change set, the AMS server may simply queue the command at block 818, inspect the command's parameter change set by sending a message to the DCS as in blocks 820-826 of FIG. 8, and then release the command upon approval at block 820, or modify the parameter change set to remove or delete critical parameters in response to DCS rejection of the requested change at block 832.

[0041] If the DCS includes a log, such as an event chronicle database, that captures changes made to plant devices, such as field devices, the resulting changes in operation, and notable results observed by the plant operator, the AMS or other second system may have a corresponding log, such as an audit trail log or database, that records test, inspection, and calibration changes made to field devices by the AMS or a user of the AMS. In one embodiment, the security service module may be programmed to retrieve relevant audit trail entries for intercepted commands of parameter changes. For example, the security service module may query the audit trail of the AMS for information based on the parameter changes requested to be modified by the change command. The audit trail log or database entry may include the date and time of the plant device modification made by the secondary system, such as the AMS, the type of modification, and the reason for the modification. The security service module may include this audit trail log information when forwarding an alert message to the DCS operator. The DCS operator may find the audit trail information useful in making a more informed decision to approve or reject a change command or change request. One situation may arise when a DCS operator would normally block or reject a change request based solely on information from the DCS side, but then realizes that the priority of modifying a plant device parameter based on audit trail information overrides initial operational considerations. This may be the case, for example, when the audit trail indicates a possible defect or significant degradation of a plant device.

[0042] In general, the processes and functions described in Figure 8 may be distributed between the AMS and DCS via computing components of the AMS and DCS, such as workstations or servers of each system, respectively. A separate computing device may be used to implement an SSM that may perform at least some of the functions or process blocks of Figure 8. In some embodiments, the process blocks of Figure 8 may be divided between the AMS, DCS, and SSM. In some embodiments, the SSM may have elements implemented by the AMS workstation and the DCS workstation to perform the processes of Figure 8.

[0043] FIG. 13 illustrates a particular embodiment in which the AMS is implemented as a field device integration (FDI) server component. The field device integration system is an industry standard approach for accessing and communicating with process control devices using electronic device descriptions (EDDs). In particular, the security services module 1308 may be programmed as a component of the FDI server 1312. A user of a workstation, such as the workstation 201, coupled to a common network, such as the network 160, may use the EDD field device interface or FDI client 1316 to send requests for critical parameter changes to field devices. The SSM 1308 of the FDI server 1312, as part of the AMS system, may be programmed to intercept some or all of the parameter change commands or requests from any one of the multiple FDI clients 1316. As illustrated by FIG. 13 , the FDI EDD server 1312 receives analog output (AO) HART communications from controllers 1340, I / O devices (e.g., CHARacterization Module (CHARM) Input / Output Card (CIOC) 1342, (part of an Emerson Delta V process control embodiment), and DCS workstations 1350. Independent of the DCS control functions communicated via the CHARM1 interface 1344, the FDI communication server interface 1330 can directly communicate with field devices 1320, such as IP104A field devices (e.g., valve positioners). The SSM 1308 of the FDI server 1312 component can process parameter change commands similar to the above embodiment. Specifically, the FDI-EDD server can send a request message for approval of the parameter change command to the DCS 1350. Based on the response of the DCS 1350, the SSM 1308 can release the parameter change command of commitment at the field device 1320 or terminate the parameter change command. It should be noted that all of the above embodiments can be applied to the embodiment of FIG. 13.

[0044] FIG. 14 illustrates one embodiment of an approval system, where an instrumentation engineer 1401 may use a mobile computing device 1410 that has wireless access to a DCS 1450 and has access to field devices 1420 via a HART communication interface 1412. In some embodiments, the mobile device 1410 may be physically and directly coupled to the field devices 1420 in the process plant via the communication interface 1412. The DCS workstation 1450 may monitor and control the field devices 1420 using corresponding controllers 1440, I / O 1442, and interfaces 1444. In this embodiment, the SSM 1408 may be programmed as a component of the mobile device 1410. The SSM 1408 may use a wireless communication link to the DCS 1450 as described above, and the same or similar process of approving parameter change commands may be implemented.

[0045] The following additional considerations apply to the above discussion: Throughout this specification, actions described as being performed by any device or routine generally refer to the actions or processes of a processor that manipulates or transforms data according to machine-readable instructions. The machine-readable instructions may be stored on and retrieved from a memory device communicatively coupled to the processor. In other words, the methods described herein may be embodied by a series of machine-executable instructions stored on a computer-readable medium (i.e., on a memory device). The instructions, when executed by one or more processors of a corresponding device (e.g., a server, a user interface device, etc.), cause the processor to perform the method. When instructions, routines, modules, processes, services, programs, and / or applications are referred to herein as being stored or saved on a computer-readable memory or a computer-readable medium, the terms "stored" and "saved" are intended to exclude transitory signals.

[0046] Additionally, the terms "operator," "personnel," "person," "user," "technician," and other similar terms are used to describe persons within a process plant environment who may use or interact with the systems, apparatus, and methods described herein, but these terms are not intended to be limiting. Where particular terms are used in the description, the terms are used in part for traditional activities engaged in by plant personnel, but are not intended to limit the personnel who may engage in a particular activity.

[0047] In addition, throughout this specification, multiple instances may implement the structures described as components, operations, or single instances. Although individual operations of one or more methods have been illustrated and described as separate operations, one or more of the individual operations may be performed simultaneously, and the operations need not be performed in the order illustrated. Structures and functions presented as separate components in the example configurations may be implemented as combined structures or components. Similarly, structures and functions presented as single components may be implemented as separate components. These and other variations, modifications, additions, and improvements are within the scope of the subject matter of this specification.

[0048] Unless specifically stated otherwise, discussions herein using words such as "processing," "computing," "calculating," "determining," "identifying," "presenting," "causing to present," "displaying," "displaying," and the like may refer to the actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electrical, magnetic, biological, or optical) quantities in one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

[0049] When implemented in software, any of the applications, services, and engines described herein may be stored in any tangible, non-transitory computer-readable memory, such as a magnetic disk, laser disk, solid-state memory device, molecular memory storage device, or other storage medium, such as in the RAM or ROM of a computer or processor. It should be noted that while the exemplary systems disclosed herein are disclosed to include software and / or firmware running on hardware, among other components, such systems are merely exemplary and should not be considered limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embedded solely in hardware, solely in software, or in any combination of hardware and software. Thus, one skilled in the art will readily appreciate that the examples provided are not the only ways to implement such a system.

[0050] Thus, while the invention has been described with reference 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.

[0051] It should also be understood that unless a term is expressly defined in this patent using the sentence "As used herein, the term "______" is herein defined to mean..." or a similar sentence, there is no intention to limit the meaning of the term, either expressly or by implication, beyond its plain or ordinary meaning, and such term should not be construed as being limited in scope based on any statement made in any section of this patent (other than the claim language). If any term recited in the final claim of this patent is referred to in this patent in a manner consistent with a single meaning, it is done merely for clarity so as not to confuse the reader, and it is not intended that such claim term be limited, by implication or otherwise, to that single meaning. Finally, unless a claim element is defined by the words "means" and a recitation of a function without any recitation of structure, the scope of any claim element is not intended to be construed based on application of 35 U.S.C. 112(f) and / or pre-AIA 35 U.S.C. 35 U.S.C. 112, paragraph 6.

[0052] Moreover, although the above text describes detailed descriptions of many different embodiments, it should be understood that the scope of this patent is defined by the language of the claims set forth at the end of this patent. The detailed description should be construed as merely exemplary and does not describe all possible embodiments, as describing all possible embodiments would be impractical, if not impossible. Many alternative embodiments could be implemented using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.

Claims

1. A computer-implemented method for verifying a critical parameter change to at least one field device in a distributed process control system (DCS), the DCS including at least one controller and the one field device, and the DCS having an asset management system (AMS) separate from the DCS and communicatively coupled to at least one of the controller of the DCS or the one field device of the DCS independently of the DCS, the computer-implemented method comprising: intercepting, via one or more processors, process control device parameter change commands originating from the asset management system (AMS), the parameter change commands including instructions to modify at least a set of critical parameters of the process control device; sending, via one or more processors, a warning message to a workstation of the distributed process control system (DCS) indicating that a parameter change command of the process control device is intercepted, the warning message including at least a user identifier, a plant device identifier, and a set of warning parameters including the set of critical parameters of the process control device that are modified by the parameter change command; displaying said warning message on said workstation of said DCS via one or more processors; receiving, via one or more processors, a response generated by the DCS workstation of the AMS workstation indicating whether the parameter change command to modify the set of critical parameters of the process control device is allowed; displaying, via one or more processors, the response from the DCS on a user interface device of the AMS; and and terminating, via one or more processors, the instructions to modify the set of critical parameters of the parameter change command if the response to modifying the set of critical parameters of the process control device is a reject response.

2. The method of claim 1 , wherein intercepting a process control device parameter change command comprises aborting the parameter change command before the command is received by the process control device.

3. 3. The method of claim 1 or claim 2, further comprising providing additional parameter information from the DCS in the response to the warning message, and wherein displaying the response to the parameter change command in the AMS comprises displaying the additional parameter information.

4. 4. The method of claim 3, wherein the additional parameter information comprises information regarding previous changes to the set of critical parameters of the process control device and previous effects on the process being controlled by the process control device based on the previous changes.

5. prompting a user of the AMS workstation to verify the parameter change command once the response and additional parameter information are displayed; 5. The method of claim 4, further comprising: committing the set of parameter changes to the process control device upon verifying the parameter change command at the user interface device of the AMS.

6. 6. The method of claim 3, further comprising transmitting additional information regarding the set of critical parameters from the AMS to the DCS for display on the DCS workstation, the additional information including a description of previous changes initiated by the AMS workstation to one or more parameters modified by the parameter change command, and a reason for a current change to the one or more parameters of the parameter change command.

7. 7. The method of claim 1, wherein the parameter change command is a command to modify a plurality of parameters of the process control device, including the set of critical parameters, and a set of non-critical parameters other than the set of critical parameters.

8. 8. The method of claim 7, further comprising: terminating changes to the set of critical parameters while allowing changes to the set of non-critical parameters to be committed to the process control device if the response to modifying the set of critical parameters of the process control device is a reject response.

9. The method according to claim 1 , wherein the user interface device of the AMS is generated based on an Electronic Device Description (EDD) processed by an EDD server.

10. 10. The method of claim 9, wherein sending an alert message to a workstation of the distributed process control system (DCS) is performed by the EDD server.

11. A computing system for validating a critical parameter change to at least one field device in a distributed process control system (DCS), the DCS including at least one controller and the one field device, the DCS having an asset management system (AMS) separate from the DCS, and communicatively coupled to at least one of the controller of the DCS or the one field device of the DCS, the computing system comprising: a workstation of the DCS adapted to communicate with the at least one controller and one field device of the DCS; a workstation of the AMS adapted to communicate with the at least one controller and one field device of the DCS independent of the DCS; a security services module communicatively coupled to the workstation of the asset management system (AMS) and the workstation of the distributed process control system (DCS), intercepting, via one or more processors, process control device parameter change commands originating from the workstation of the asset management system (AMS), the parameter change commands including instructions to modify at least a set of critical parameters of the process control device; sending, via one or more processors, a warning message to the workstation of the DCS indicating that the parameter change command for the process control device is intercepted, the warning message including at least a user identifier, a plant device identifier, and a set of warning parameters including the set of critical parameters of the process control device that are modified by the parameter change command; receiving, via one or more processors, from the workstation of the DCS, a response generated by the workstation of the DCS indicating whether the parameter change command to modify the set of critical parameters of the process control device is permitted; Releasing the intercepted parameter change command when the response to modify the set of critical parameters via one or more processors is permitted; and otherwise, terminating the instruction that modifies the set of critical parameters.

12. 12. The system of claim 11, wherein the security services module includes a component executed on the AMS workstation and a component executed on the DCS workstation, the AMS workstation component adapted to intercept the parameter change command at the AMS workstation, and the DCS workstation component adapted to receive an alert from the AMS workstation component indicating that the parameter change command has been intercepted.

13. 13. The system of claim 11 or claim 12, wherein if the response to modify the set of critical parameters is permitted, releasing the intercepted parameter change command includes sending a request to the DCS for the DCS to commit the modifications to the set of critical parameters of the process control device.

14. 14. The system of claim 11, wherein the workstation of the DCS is adapted to display at least one of the set of warning message parameters and prompt a user of the DCS workstation for approval of the parameter change command.

15. 15. The system of claim 14, wherein the workstation of the AMS is adapted to display the response from the workstation of the DCS indicating whether the parameter change command is permitted to modify the set of critical parameters of the process control device.

16. 16. The system of claim 11, wherein the parameter change command is for a plurality of parameters including the set of critical parameters and a set of non-critical parameters other than the set of critical parameters, and the security service module is adapted to allow an instruction to change the non-critical parameters of the process control device despite the response from the DCS workstation.

17. receiving the warning message indicating that the parameter change command was intercepted; displaying a prompt on the workstation of the DCS validating the intercepted parameter change command; 17. The system of claim 11, further comprising a security module of the distributed process control system (DCS) adapted to: send the response to the security services module, the response indicating whether the parameter change command was verified.

18. 20. The system of claim 17, wherein the security module of the DCS is further adapted to query an event chronicle database of the DCS for a modification history to at least one of the set of critical parameters of the parameter change command and display at least a portion of the modification history on a user interface of the DCS.

19. The system of any one of claims 11 to 18, wherein the security services module is adapted to query an audit trail database of the AMS for a history of previous modifications to the set of critical parameters of the parameter change command, the history of previous modifications including reasons for one or more previous parameter modifications.

20. 20. The system of claim 11, further comprising a Field Device Integration (FDI) Electronic Device Description (EDD) server running on the workstation of the asset management system (AMS) and adapted to receive a request for a parameter change to a process control device from a user interface, wherein the security service module is implemented using logic executed by the FDI EDD server.

21. A computing system for verifying a critical parameter change to at least one field device in a distributed process control system (DCS), the DCS including at least one controller and the one field device, and the DCS having a second system distinct from the DCS and communicatively coupled to the at least one controller or the one field device of the DCS, the computing system comprising: a workstation of the DCS adapted to communicate with the at least one controller and one field device of the DCS; and receiving, via one or more processors, an alert from the second system indicative of a parameter change command initiated by the second system to a process control device of the DCS; via one or more processors, querying an event chronicle database of said DCS for entries related to a set of parameters that are modified by said parameter change command; displaying, via one or more processors, the alerts from the second system along with event chronicle entries associated with the set of parameters modified by the parameter change commands; and adapted to transmit, via one or more processors, a response to the alert to the second system indicating whether the parameter change command was approved; The workstation of the second system includes: communicating, independent of the DCS, with at least one process control device of the DCS via one or more processors; intercepting, via one or more processors, parameter change commands of the second system, the parameter change commands including instructions to change at least a set of critical parameters of the at least one process control device of the DCS; sending, via one or more processors, an alert to the workstation of the DCS including an indication that the parameter change command has been intercepted; and releasing the intercepted parameter change command for execution at the process control device based on a response from the DCS workstation, via one or more processors.

22. The system of claim 21, further adapted to: an asset management system (AMS) workstation to retrieve an audit trail log corresponding to the set of critical parameters of the parameter change command including at least a parameter identifier, a previous parameter modification, and a reason for modification; and sending the alert to the DCS workstation includes sending the retrieved audit trail log.

23. 23. The system of claim 21 or claim 22, wherein the event chronicle entry includes an identifier of the set of critical parameters, a previous change to the set of critical parameters, and an effect of the previous change on a plant process.

24. A computing system for validating critical parameter changes to devices in a distributed process control system (DCS), the DCS including at least one controller and at least one field device, the DCS having a second system distinct from the DCS and communicatively coupled to at least one of the controllers or the one field device of the DCS via a common communications network; a security services module communicatively coupling the second system and the DCS via the common communications network, intercepting, via one or more processors, process control device parameter change commands originating from outside the DCS, the parameter change commands including instructions to change at least one set of critical parameters of the process control device; transmitting, via one or more processors, an alert message to a workstation of the DCS, the alert message indicating that a parameter change command of a process control device of the DCS has been intercepted; receiving, via one or more processors, from the workstation of the DCS, a response generated by the workstation of the DCS indicating whether the critical parameter change to the process control device was authorized; releasing the intercepted parameter change command via one or more processors if the response to the significant parameter change is permitted.

Images