SYSTEM AND METHOD FOR MANAGING ALERTS ASSOCIATED WITH DEVICES OF A PROCESS CONTROL SYSTEM - Patent application

Abstract

To provide a technique for managing an alert associated with a device in a process control system within a process plant.SOLUTION: A series of devices may generate the series of alerts and may communicate with an asset management system, and the asset management system may examine the series of alerts to determine whether a rule (plurality is possible) is applicable. In an embodiment, the rule determines how the series of alerts should be stored, as well as the rule may designate an action (plurality is possible) to initiate in response to storing the series of alerts. Moreover, the asset management system may automatically generate a new rule (plurality is possible) to be applied to the alert of the device so as to further refine the alert management.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates generally to alerts associated with devices or assets in a process control system, and more particularly to effectively and efficiently implementing and operating a management system for effectively and efficiently managing alerts generated by devices or assets. [Background technology]

[0002] Distributed process control systems, such as those used in chemical, petroleum, industrial, or other process plants for manufacturing, refining, transforming, creating, or producing physical substances or products, typically include one or more process controllers communicatively coupled to one or more field devices via an analog bus, a digital bus, or a combined analog / digital bus, or via one or more wireless communication links or networks. The field devices, which may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level, and flow sensors), are positioned within the process environment and generally perform physical or process control functions, such as opening and closing valves, measuring process and / or environmental parameters, such as temperature, flow, or pressure, to control one or more processes running within the process plant or system. Smart field devices, such as field devices conforming to well-known Fieldbus protocols, may also perform control calculations, alarm functions, and other control functions typically implemented in controllers. A process controller, also typically located within a plant environment, executes a controller application that executes different control modules that receive signals indicative of process measurements made by and / or other information regarding the field devices, e.g., make process control decisions, generate control signals based on the received information, and interface with control modules or blocks that execute in the field devices, such as HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices. The control modules within the controller send control signals over communication lines or links to the field devices to thereby control the operation of at least a portion of a process plant or system, e.g., control at least a portion of one or more industrial processes running or executing within the plant or system.I / O devices, also typically located within a plant environment, are typically disposed between a controller and one or more field devices and enable communication therebetween, for example, by converting electrical signals to digital values, and vice versa. As used herein, field devices, controllers, and I / O devices are generally referred to as "process control devices" and are generally located, disposed, or installed within the field environment of a process control system or plant.

[0003] Furthermore, in many process or industrial plants, the process control network includes safety instrumented systems (SIS) that operate to detect significant safety-related issues within the process plant and automatically open and close valves, remove power from devices, switch flows within the plant, etc., when a problem occurs that poses or could lead to a significant hazard within the plant, e.g., a toxic chemical spill, an explosion, etc. These safety systems typically have one or more separate controllers in addition to the standard process control controller, called safety system logic solvers, that are connected to safety field devices via a separate bus, communication line, or wireless network installed within the process plant. The logic solvers execute safety instrumented function (SIF) routines and uses safety field devices to detect process conditions related to significant events, such as the position of certain safety switches or shut-off valves, overflows or underflows in the process, operation of critical power generation or control devices, operation of fault detection devices, etc., thereby detecting events within the process plant. Upon detection of an event, which may be a single condition or the simultaneous occurrence of two or more conditions, the safety controller takes some action to limit the harmful nature of the event, such as closing a valve, powering off a device, removing power from a section of the plant, etc. Generally, these actions involve tripping or switching a safety device into a "safe" operating mode designed to prevent serious or hazardous conditions within the process plant.

[0004] In either case, information from the field devices, controllers, and safety system logic solvers (also called safety controllers) may typically be made available via a data highway or communication network to one or more other hardware devices, such as operator workstations, personal computers or other types of computing devices with user interfaces, data historians, report generators, centralized databases, or other centralized management computing devices that are typically located in a control room or other location away from the plant's more hostile field environment, e.g., in the back-end environment of a process plant. Each of these hardware devices is typically centralized throughout the process plant or throughout portions of the process plant. These hardware devices run applications that may enable a control or safety system operator to perform functions related to the control of the process and / or operation of the process plant, such as changing the settings of process control routines or safety routines, modifying the operation of control modules in process controllers, safety system controllers, field devices, etc., viewing the current state of the process, viewing alerts or alarms generated by field devices, process controllers, or safety system controllers, simulating the operation of a process for purposes of training personnel or testing process control software, maintaining and updating configuration databases, etc. The data highways utilized by the hardware devices, controllers, and field devices may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[0005] As an example, the DeltaV™ control system sold by Emerson Process Management includes multiple applications stored in and executed by different devices located at various locations within a process plant. Configuration applications resident in one or more workstations or computing devices within the back-end environment of a process control system or plant enable users to create or modify process control modules and download them to dedicated distributed controllers via a data highway. Typically, these control modules are composed of communicatively interconnected function blocks, which are objects in an object-oriented programming protocol that perform functions within a control scheme based on inputs and provide outputs to other function blocks within the control scheme. The configuration application may also enable a configuration designer to create or modify operator interfaces that a viewing application uses to display data to an operator and to allow the operator to change settings, such as setpoints, within a process control routine. Each dedicated controller (e.g., a process controller or safety system controller) and, in some cases, one or more field devices, stores and executes its respective controller or safety application, which runs its assigned and downloaded control modules to implement the actual process control and safety system functions.

[0006] Additionally, plant display applications, which may be running on one or more user interface devices, such as operator workstations, one or more remote computing devices communicatively connected to the operator workstations and the data highway, receive data from the controllers and field devices via the data highway and display this data via user interface screens to a designer, operator, or user of the process control system. These user interface devices or applications may provide any of several different views, such as an operator's view, an engineer's view, a technician's view, etc., tailored to actions taken by different users within the plant. Additionally, a data historian application is typically stored and executed on a data historian device that collects and stores some or all of the data provided over the data highway, while a configuration database application may run in an additional computer attached to the data highway to store the current process control routine configuration and its associated data. Alternatively, the configuration database may be located on the same workstation as the configuration application.

[0007] One of the key activities performed by control and / or safety system operators, maintenance system operators, etc. relates to viewing and responding to alerts and alarms generated by various devices, control routines, safety system routines, maintenance routines, etc. during plant operation. Typically, process control operators, safety system operators, maintenance personnel, etc. view user interface display screens provided by user interface applications executing on workstations, handheld devices, etc., typically within the plant's back-end environment, separate from the actual field devices and other field equipment within the plant's field environment. During operation, the user interface application may present the user with one of several possible pre-configured plant views, each plant view typically depicting a certain area, unit, section, or other portion of the plant. As is well known, physical process elements (e.g., valves, sensors, etc., utilized to control processes within a process plant) may be depicted according to piping and instrumentation diagrams (P&IDs) and / or plant floor layouts and / or other plans or “blueprints” of process control system or safety system layouts. Additionally, these user interface applications typically display a banner or other display showing some or all of the various alerts or alarms generated or initiated by devices and logic modules within the plant. The banner typically depicts an icon associated with each alert or alarm initiated within the plant, and these icons may be organized, color-coded, displayed as solid or flashing icons, etc. based on the severity, priority, location, or other criteria of the alert or alarm or the source of the alert or alarm.

[0008] Typically, a process plant incorporates hundreds, if not thousands, of devices that control and monitor the manufacturing process. Each of these devices can generate several alerts each day. In addition, many alerts may be non-essential (e.g., alerts for empty pipes that are not in use) or may not otherwise cause real problems. Furthermore, some devices that are not critical to the process and that are in an alert state but do not have an urgency for repair may therefore be placed on a list to be repaired at the next scheduled outage or plant turnaround, but may continue to generate alerts. For at least these reasons, managing alerts can be time-consuming and difficult. Therefore, there is an opportunity for a system and method for efficiently and effectively managing alerts associated with a process control system. Summary of the Invention

[0009] A system and method are disclosed for managing alerts associated with a process control system of a process plant. During operation of the process control system, a series of process control devices may generate alerts and send the alerts to a computing device, such as a workstation. The computing device may examine the alerts and determine whether a rule applies to the alert(s) or whether a new rule needs to be established. Generally, a rule may specify a memory location that may be associated with the alert(s). If a rule applies to a received alert, the computing device may associate the alert with the memory location specified by the rule. Alternatively, the computing device may establish a new rule to be applied to subsequent alerts received from the device.

[0010] In one embodiment, a computer-implemented method is provided for managing alerts associated with a set of devices in a process plant, at least some of the set of devices being communicatively connected to operate within the process plant during runtime to enable a process control system of the process plant to control the set of processes. The method may include receiving, at a computing device, an alert associated with operation of the devices in the process plant from one of the set of devices; accessing from a memory a set of rules for managing the alert, where one rule in the set of rules (i) is applicable to the alert and (ii) specifies a storage location; and associating the alert with the storage location, where one or more of the rules and the storage location specify an action to initiate; and initiating the action in response to associating the rule with the storage location.

[0011] In another embodiment, a management system for managing alerts associated with a set of devices in a process plant is provided, the system being communicatively connected to the set of devices, at least some of the set of devices being communicatively connected to operate within the process plant during runtime to enable a process control system of the process plant to control the set of processes. The system may include: a memory (i) at least partially segmented into a set of memory locations and (ii) storing a set of rules for managing the alerts; and a processor interfaced with the memory, the processor configured to: receive an alert from one of the set of devices associated with operation of the device in the process plant; access the set of rules from the memory, where one rule of the set of rules (i) is applicable to the alert; and (ii) specify one of the set of memory locations and associate the alert with the memory, where one or more of the rules and the storage location specify an action to initiate; and initiate the action in response to associating the rule with the storage location.

[0012] In a further embodiment, a computer-implemented method for generating rules for managing alerts associated with a set of devices in a process plant, at least some of the devices being communicatively connected to operate within the process plant during runtime to enable a process control system of the process plant to control the set of processes, the method including: receiving, at a computing device, an alert from one of the devices associated with operation of the device in the process plant; determining from the alert that a new rule should be established for the device; and establishing the new rule for the device, the new rule specifying a storage location for the alert associated with operation of the device. and, at the computing device, receiving from the device a subsequent alert associated with operation of the device; and, after receiving the subsequent alert, associating the subsequent alert with a memory location specified by the new rule.

[0013] In yet a further embodiment, a management system is provided for managing alerts associated with a set of devices in a process plant, the system being communicatively connected to the set of devices, at least some of the set of devices being communicatively connected to operate within the process plant during runtime to enable a process control system of the process plant to control the set of processes. The system may include: (i) a memory that is at least partially segmented into a set of memory locations and (ii) storing a set of rules for managing the alerts; and a processor interfaced with the memory, the processor configured to: receive, from one of the set of devices, an alert associated with operation of the device in the process plant; determine from the alert that a new rule should be established for the device; establish the new rule for the device, where the new rule specifies a memory location for the alert associated with the operation of the device; receive, from the device, a subsequent alert associated with the operation of the device; and, after receiving the subsequent alert, associate the subsequent alert in the memory with the memory location specified by the new rule.

[0014] Yet another embodiment of these techniques is a computing device that includes one or more processors and a non-transitory computer-readable medium that stores instructions that implement the functions described herein. [Brief explanation of the drawings]

[0015] [Figure 1] FIG. 1 is a block diagram of a process control system that may implement alert management functionality, according to certain embodiments. [Figure 2]1 depicts a display application running on an operator workstation that presents a user display interface illustrating aspects of alarm management, according to certain embodiments. [Figure 3] FIG. 2 is a hardware diagram of an exemplary computing device, in accordance with certain embodiments. [Figure 4] FIG. 1 is a signal diagram associated with alert management in a process control system, according to certain embodiments. [Figure 5] 1 is a flow diagram associated with managing alerts associated with a set of devices in a process plant, according to certain embodiments. [Figure 6] 1 is a flow diagram associated with generating rules for managing alerts associated with a set of devices in a process plant, according to certain embodiments. [Figure 7] 1A-1C are illustrative diagrams depicting various of the described features in accordance with particular embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0016] The process control system of the process plan may be configured with multiple process control devices that may be configured to generate alerts associated with or detected by the operation and status of the process control devices. The alerts may serve to notify a user of potential device problems so that the user can review the alert to determine the potential impact of the alert and / or take corrective action.

[0017] In general, alerts are distinct from (or may be considered a type of alarm) and alerts, as discussed herein, may be intended for operators who primarily supervise or manage a process plant. In contrast, alarms are typically not intended for the purpose of The alerts and alarms are intended for technicians or maintenance personnel who are responsible for directly addressing issues such as repair or maintenance of the system. For this reason, alerts and alarms may be generated, managed, and addressed in different ways.

[0018] As discussed herein, alerts may relate to hardware failures, sensor or control problems, reactive or proactive reporting of past or upcoming maintenance requirements, etc. Alerts may be of different types and may have different severities. For example, an alert may have one of the following types: "fault," "maintenance," "advisory," or "communication," and an alert may have one of the following severities: low, medium, or high.

[0019] The present embodiment describes an alert management system configured to communicate with process control devices of a process plant. The alert management system is configured to automatically manage alerts generated by and received from the process control devices according to a set of storage locations. In particular, received alerts may be automatically mapped to specific storage locations based on the source process control device, the severity or criticality of the alert, or both.

[0020] According to embodiments, the alert management system and method may additionally implement certain actions when mapping alerts to storage locations. For example, low-priority alerts may be removed from the active device alert list. In a further example, high-priority alerts may trigger emails or other communications to be sent to appropriate personnel. In one implementation, the alert management system and method may automatically and autonomously generate and implement new rules for mapping alerts and / or devices to storage locations based on specific criteria. In additional or alternative implementations, the system may allow users to specify rules for mapping alerts and / or devices to storage containers.

[0021] Thus, the present system and method provide numerous benefits. In particular, the present system and method effectively and efficiently manage alerts generated by process control devices to reduce the volume of alerts presented to process plant personnel. This reduces the time and effort personnel spend addressing alerts. Additionally, the present system and method automatically generate new rules and alert mappings based on monitoring conditions and operations within the process plant, thereby further refining the operation of the alert management system. It should be understood that further advantages are contemplated.

[0022] FIG. 1 illustrates a process plant, process control system, or process control environment 5 that may operate to control one or more industrial processes in real time and in which an alert management system may be implemented to provide enhanced alert management capabilities within the control system or plant 5. Generally speaking, the process plant 5 includes one or more wired or wireless process control devices, components, or elements that, when activated and operating online, perform physical functions in cooperation with the process control system to control one or more processes running within the process plant (which may be any type of process or industrial plant). The process plant 5 and / or process control system may include, for example, one or more wired communication networks and / or one or more wireless communication networks. Additionally, the process plant 5 or control system may include centralized databases, such as continuous, batch, asset management, configuration, history, and other types of databases.

[0023] In particular, FIG. 1 depicts a block diagram of an exemplary process plant, process control system, or process control environment 5 having one or more process controllers and safety controllers that receive signals indicative of process measurements made by field devices; It processes this information using one or more process control and / or safety system control routines that generate control signals that are sent over wired or wireless process control communication links or networks to other field devices to control the operation of processes within the plant 5. Typically, at least one field device performs a physical function (e.g., opening or closing a valve, raising or lowering a temperature, measuring, sensing a condition, etc.) to control the operation of a process. Some types of field devices communicate with a controller using input / output (I / O) devices. Process controllers, field devices, and I / O devices may be wired or wireless, and any number and combination of wired and wireless process controllers, field devices, and I / O devices may be included within the process plant environment or system 5.

[0024] For example, the system of Figure 1 depicts a process control system 5 having multiple process controllers 11, some of which are communicatively connected to field devices 15-22 via wired input / output (I / O) cards 26 and 28. Some of the process controllers 11 are also communicatively connected wirelessly or partially wirelessly to field devices 40-46 via a wireless gateway 35 and a process control data highway 10. The process control data highway 10 may include one or more wired and / or wireless communication links and may be implemented using any desired or suitable communication protocol, such as, for example, an Ethernet protocol. In some configurations (not shown), one or more of the process controllers 11 may be communicatively coupled to the wireless gateway 35 using one or more communication networks other than the data highway or communication network 10, such as by using any number of other wired or wireless communication links supporting any other communication protocol, for example, Wi-Fi or other IEEE 802.11 compliant wireless local area network protocol, mobile communication protocol (e.g., WiMAX, LTE, or other ITU-R compatible protocol), Bluetooth® protocol, HART® protocol, WirelessHART® protocol, Profibus protocol, FOUNDATION® Fieldbus protocol, etc.

[0025] The controller 11 may, by way of example, be a DeltaV™ controller sold by Emerson Process Management and may operate to implement a batch or continuous process using at least some of the field devices 15-22 and 40-46. In addition to being communicatively connected to the process control data highway 10, the controller 11 may be communicatively connected to at least some of the field devices 15-22 and 40-46 using any desired hardware and software, for example, associated with standard 4-20 mA devices, I / O cards 26, 28, and / or any smart communication protocol such as the FOUNDATION® Fieldbus protocol, the HART® protocol, the WirelessHART® protocol, etc. In FIG. 1 , the controller 11, the field devices 15-22, and the I / O cards 26, 28 are wired devices, and the field devices 40-46 are wireless field devices. Of course, the wired field devices 15-22 and wireless field devices 40-46 may conform to any other desired standard(s) or protocol, such as any wired or wireless protocol, including any standard or protocol developed in the future.

[0026] The process controller 11 of FIG. 1 includes a processor 30 that implements or oversees one or more respective process control routines 38 (e.g., stored in memory 32), each defining a separate node of the process control system. , generally referred to herein as a control module. The processor 30 is configured to communicate with the field devices 15-22 and 40-46 and with other nodes communicatively connected to the controller 11. It should be noted that any control routine or module 38 described herein may have portions thereof implemented or performed by different controllers or other devices, if so desired. Similarly, the control routines or control modules 38 described herein implemented within the process control system 5 may take any form, including software, firmware, hardware, etc. Additionally, the control routines 38 may be implemented in any desired software format, such as using object-oriented programming, ladder logic, sequential function charts, function block diagrams, or any other software programming language or design paradigm. The control routines or control modules 38 may be stored in any desired type of memory 32, such as random access memory (RAM) or read-only memory (ROM). Similarly, the control routines 38 may be hard-coded, for example, into one or more EPROMs, EEPROMs, application-specific integrated circuits (ASICs), or any other hardware or firmware elements. Thus, the controller 11 may be configured to implement control strategies or routines in any desired manner.

[0027] In one case, the controller 11 implements control strategies using control modules 38 defined by what are generally referred to as function blocks, where each function block is an object or other portion (e.g., a subroutine) of an overall control routine and operates in cooperation with other function blocks (through communications called links) to implement a process control loop within the process control system 5. Control-based function blocks typically perform one of the following functions: an input function, such as one associated with a transmitter, sensor, or other process parameter measurement device; a control function, such as one associated with a control routine implementing PID, fuzzy logic, or the like; or an output function, which controls the operation of some device, such as a valve, to implement some physical function within the process control system 5. Of course, hybrid and other types of function blocks exist. The function blocks may be stored in and executed by the controller 11, as is typically the case when these function blocks are used for or associated with standard 4-20 mA devices and some types of smart field machines, e.g., HART® devices, or may be stored in and executed by the field device itself, as may be the case with FOUNDATION® Fieldbus devices. Thus, as will be appreciated, the controller 11 may include one or more control routines 38 that may implement one or more control loops performed by executing one or more of the function blocks.

[0028] The wired field devices 15-22 may be any type of device, such as sensors, valves, transmitters, positioners, etc., while the I / O cards 26 and 28 may be any type of I / O device conforming to any desired communication or controller protocol. In FIG. 1 , the field devices 15-18 are standard 4-20 mA or HART® devices that communicate to the I / O card 26 via analog lines or combined analog and digital lines, while the field devices 19-22 are smart devices, such as FOUNDATION® Fieldbus field devices, that communicate to the I / O card 28 via a digital bus using the FOUNDATION® Fieldbus communication protocol. However, in some embodiments, at least some of the wired field devices 15-22 and / or at least some of the I / O cards 26, 28 may additionally or alternatively communicate using the process control data highway 10 and / or other suitable control system protocols (e.g., Profibus, DeviceNet, Fou The controller 11 may communicate with the device by using a standard network (such as ND Fieldbus, ControlNet, Modbus, HART, etc.).

[0029] In the system of FIG. 1 , the wireless field devices 40-46 communicate over the wireless process control communication network 70 using a wireless protocol, such as the WirelessHART® protocol. Such wireless field devices 40-46 may communicate directly with one or more other devices or nodes of the wireless network 70 that are also configured to communicate wirelessly (e.g., using the wireless protocol or another wireless protocol). To communicate with one or more other nodes not configured to communicate wirelessly, the wireless field devices 40-46 may utilize a wireless gateway 35 connected to the process control data highway 10 or to another process control communication network. The wireless gateway 35 provides access to the various wireless devices 40-58 of the wireless communication network 70. In particular, the wireless gateway 35 provides a communicative coupling between the wireless devices 40-58, the wired devices 11-28, and / or other nodes or devices of the process control plant 5. For example, the wireless gateway 35 provides a communicative coupling by using the process control data highway 10 and / or by using one or more other communication networks of the process plant 5.

[0030] Like the wired field devices 15-22, the wireless field devices 40-46 of the wireless network 70 perform physical control functions within the process plant 5, such as opening and closing valves, obtaining measurements of process parameters, etc. However, the wireless field devices 40-46 are configured to communicate using the wireless protocol of the network 70. In this manner, the wireless field devices 40-46, the wireless gateway 35, and the other wireless nodes 52-58 of the wireless network 70 are producers and consumers of wireless communication packets.

[0031] In some configurations of the process plant 5, the wireless network 70 includes non-wireless devices. For example, in FIG. 1 , field device 48 is depicted as a legacy 4-20 mA device, and field device 50 is depicted as a wired HART® device. To communicate within the network 70, field devices 48 and 50 are connected to the wireless communication network 70 via wireless adapters 52 a, 52 b. The wireless adapters 52 a, 52 b support wireless protocols such as WirelessHART and may also support one or more other communication protocols such as Foundation® Fieldbus, PROFIBUS, DeviceNet, etc. Additionally, in some configurations, the wireless network 70 includes one or more network access points 55 a, 55 b, which may be separate physical devices in wired communication with the wireless gateway 35 or may be provided together with the wireless gateway 35 as an integrated device. The wireless network 70 may also include one or more routers 58 for forwarding packets from one wireless device to another within the wireless communication network 70. In the example system of FIG. 1, wireless devices 40-46 and 52-58 communicate with each other and with wireless gateway 35 via wireless links 60 of wireless communication network 70 and / or through process control data highway 10.

[0032] Still further, one or more of the process controllers 11 may be connected to a safety logic solver or safety system controller 72, which in turn is connected to safety system field devices or assets 74. The safety controller 72 may be directly connected to the field devices 74 (as shown in FIG. 1) or may be connected to the field devices 74 through one or more I / O devices (not shown in FIG. 1), and in either case may be connected to the field devices 74 through any wired or wireless communication link. Similarly, the field devices 74 may be connected to any device within the plant for safety purposes. The safety controller 72 may be any type of device that performs any of the types of physical or sensing functions described above and may be compatible with one of the communication protocols described above or other communication protocols. Similarly, the safety controller 72 may store one or more safety system logic modules 76, referred to herein as safety system modules, in memory 77 and execute these safety system modules 76 on a processor 78. The safety system logic modules 76 may be configured in any of the manners described above for the process control module 38 and may perform any desired function within the safety system, including user interface functions such as alert and alarm functions. If desired, the safety logic controller 72 may be in the same or a different node as the process controller 11.

[0033] 1 also includes one or more operator workstations 80, each communicatively connected to the data highway 10 and each including memory and one or more computer processors. Operators and other personnel may use the operator workstations 80 to configure the plant 5 and elements within the plant 5, and / or to view and monitor the runtime operation of the process plant 5, as well as to perform any diagnostic, corrective, maintenance, and / or other actions that may be required. At least some of the operator workstations 80 may be located within various protected areas within or near the plant 5, and in some situations, at least some of the operator workstations 80 may be remotely located but still communicatively connected to the plant 5. The operator workstations 80 may be wired or wireless computing devices.

[0034] The example process control system 5 is further illustrated as including a configuration application 81 (stored in memory and executing on at least one processor of the operator workstations 80) and a configuration database 82, each of which is also communicatively connected to the data highway 10. As described above, various instances of the configuration application 81 may execute on one or more computing devices, enabling users to create or modify process control modules (38) and / or safety system modules (76), configure alert management and viewing routines and support mechanisms, and download these modules and support mechanisms to the controllers 11, safety logic devices 72, or other nodes of the process plant 5 via the data highway 10, and enabling users to create or modify operator interface display modules executing on operator interface devices, through which operators can view the process plant 5, view data, and change data settings within the process control routines 38, safety system routines 76, field devices 15-22 and 40-58 of the plant 5, etc. The configuration database 82 stores created (e.g., configured) control and safety system modules and / or operator interface display modules or routines. If desired, the configuration application 81 and configuration database 82 may be centralized and have a unitary logical appearance to the process control system 5, although multiple instances of the configuration application 81 may run simultaneously within the process control system 5 and the configuration database 82 may be implemented across multiple physical data storage devices.If desired, the user interface display device for the configuration system may be different from the operator workstation 80, as the user interface device for the configuration system is utilized by configuration and development engineers regardless of whether the plant 5 is operating in real time, whereas the operator workstation 80 is generally utilized by control and safety system operators during real-time operation of the process plant 5 (also interchangeably referred to herein as "runtime" operation of the process plant 5).

[0035] The example process control system 5 also includes a data history application 83 and a data history database 84, each of which is also communicatively connected to the data highway 10. The data history application 83 operates to collect some or all of the data provided over the data highway 10 and historize or store the data in the history database 84 for long-term storage. Like the configuration application 81 and the configuration database 82, the data history application 83 and the history database 84 are centralized and may have a unitary logical appearance to the process control system 5, although multiple instances of the data history application 83 may run simultaneously within the process control system 5 and the data history database 84 may be implemented across multiple physical data storage devices.

[0036] In some configurations, the process control system 5 includes one or more other wireless access points 85 that communicate with other devices using other wireless protocols, such as Wi-Fi or other IEEE 802.11-compliant wireless local area network protocols, mobile communication protocols, such as WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution) or other ITU-R (International Telecommunication Union Radio Communication Sector) compatible protocols, shortwave wireless communications, such as near field communication (NFC) and Bluetooth, or other wireless communication protocols. Typically, such wireless access points 85 enable handheld or other portable computing devices (e.g., user interface devices 86) to communicate over a respective wireless process control communications network, which may be different from the wireless network 70 and may support different wireless protocols than the wireless network 70. For example, the wireless or portable user interface device 86 may be a mobile workstation or diagnostic tester (e.g., one instance of the operator workstation 80) utilized within the process plant 5 by an operator or by maintenance personnel. In some scenarios, in addition to the portable computing device, one or more process control devices (e.g., controller 11, field devices 15-22, or wireless devices 40-58) also communicate using a wireless protocol supported by access point 85.

[0037] In some configurations, a process control system 5 includes one or more gateways 87, 88 to systems outside of the proximate process control system 5. Typically, such systems may serve as consumers or suppliers of information generated by or manipulated by the process control system 5. For example, a process control plant 5 may include a gateway node 87 for communicatively connecting the proximate process plant 5 to another process plant. Additionally or alternatively, a process control plant 5 may include a gateway node 88 for communicatively connecting the proximate process plant 5 to an external public or private system, such as a laboratory system (e.g., a Laboratory Information Management System or LIMS), an operator round database, a material handling system, a maintenance management system, a product inventory management system, a manufacturing scheduling system, a weather data system, a shipping and handling system, a packaging system, the Internet, another provider's process control system, or other external system.

[0038] FIG. 1 illustrates an example process plant 5 with a finite number of field devices 15-22 and 40-46, a wireless gateway 35, a wireless adapter 52, an access point 55, a router 58, a wireless process control communication network 70, a safety system logic device 72, and three controllers 11 with safety system field devices 74. While only one controller 11 and / or safety logic device 72 are shown, it should be noted that this example is merely an illustrative and non-limiting embodiment. Any number of controllers 11 and / or safety logic devices 72 may be included in the process control plant or system 5, and any of the controllers 11 and safety logic devices 72 may communicate with any number of wired or wireless devices and networks 15-22, 40-46, 35, 52, 55, 58, 70, and 74 to control processes within the plant 5.

[0039] Additionally, it should be noted that the process plant or control system 5 of FIG. 1 includes a field environment 90 (e.g., the process plant floor) and a back-end environment 92 communicatively connected by a data highway 10. As depicted in FIG. 1 , the field environment 90 includes physical components (e.g., process control devices, field devices, I / O networks, network elements, etc.) disposed, installed, and interconnected therein that operate to control a process during runtime. For example, the controller 11, I / O cards 26, 28, field devices 15-22, and other devices and network components 40-46, 35, 52, 55, 58, 70, and the safety logic solver 72 and safety device 74 are located, disposed, or otherwise included within the field environment 90 of the process plant 5. Generally speaking, in the field environment 90 of the process plant 5, raw materials are received and processed using the physical components disposed therein to produce one or more products.

[0040] The back-end environment 92 of the process plant 5 typically includes various elements, such as computing devices, operator workstations, databases or data banks, etc., that are shielded and / or protected from the harsh conditions and materials of the field environment 90. As shown in FIG. 1 , the back-end environment 92 includes, for example, an operator workstation 80, configuration or development systems 81, 82 for control modules and other executable modules, data history systems 83, 84, and / or other centralized management and operation systems, computing devices, and / or functionality supporting the runtime operation of the process plant 5. In some configurations, the various computing devices, databases, and other elements and equipment included in the back-end environment 92 of the process plant 5 may be physically located at different physical locations, some of which may be local to the process plant 5 and some of which may be remote.

[0041] During operation of the plant 5, as illustrated in FIG. 1, one or more of the operator workstations 80 may implement a user interface application 95 that provides a user, such as a control system operator, with views of various equipment and data associated with the equipment. FIG. 2 illustrates one of the operator interfaces 80 of FIG. 1 as including a computer processor 93 and a memory 94 that stores a user interface display program or application 95 that executes on the processor 93 to provide the user with one or more plant display views and / or faceplate display views to assist the user in performing day-to-day operations such as managing the plant, viewing the current status of equipment within the plant, etc. One such plant display view 96 is illustrated in FIG. 2 and presents the user with a view of plant operation in the form of a plant layout view or plant display 97. The plant display 97 may be based on a PI&D diagram and may depict various icons or other representations of devices, such as valves, tanks, transmitters (e.g., sensors), etc., as interconnected within the plant 5, and may depict various important parameters and values, such as device tags or names, control system references or logic, measured process parameter values, etc. The plant display 97 allows the user to interact with the graphical elements of the display 97 to view additional information, navigate to other plant displays 97, and view other information views (pop-up windows) about elements or parameters within the graphical display. The plant display view 96 may include user interaction features or elements that enable the user to view various devices (e.g., controllers, I / O devices, field devices, etc.), modules (e.g., control or safety system modules), or other containers within the plant 5. The faceplate displays generally provide some information about the devices and / or modules, such as the device or module's nominal icon, tag, name, description, manufacturer, type of device, one or more values ​​of critical parameters associated with the device or module, etc. Additionally, the user interface display application 95 may present a banner 99 or other display that may display icons of various alerts that have been generated or received (and possibly are active) within the plant 5 or portion of the plant 5.

[0042] During operation of the plant display application or program 95, a user can use the display view 96 to view a variety of different plant displays (e.g., generated and associated by different plant display modules or interface modules stored in the configuration database 82 of FIG. 1 ), where each of the plant displays has graphical information depicting various different pieces of equipment, sections, control routines, etc., of the plant 5. The user can manipulate the display view 96 in a standard manner to view detailed graphical displays of the same or different sections or portions of the plant 5, to view control system displays (e.g., illustrating control logic), etc. The user can also select various elements within the display view 96 and view one or more faceplate displays 98 that provide additional information about those elements. In some cases, the faceplate displays 98 may allow the user to change the values ​​of one or more critical parameters of the element. Similarly, the user can select an icon for one of the alerts in the banner 99, and the plant display application 95 automatically provides a pre-configured plant display associated with that alert. Generally, upon selecting an alert, the plant display application 95 may communicate with the container (e.g., device or module) that generated the alert to obtain plant display, faceplate display, and other information for use or presentation to a user within the display view 96 for the selected alert. Generally, a container may be a physical device such as a field device, I / O device, etc., or a logic module running on a processor such as a process control module, safety system logic module, etc., or any other entity that generates an alert. Figure 4 describes more detailed functionality associated with the alert management system and method.

[0043] 3 illustrates a hardware diagram of an exemplary computing device 341 (such as workstation 80 as discussed with respect to FIG. 1) that may interface with devices of field environment 90, and in which functionality as discussed herein may be implemented. According to an embodiment, computing device 341 may be any type of computing device configured to interface and communicate with devices such as a laptop computer, a desktop computer, a tablet device, a smartphone, a smartwatch, smart glasses, etc.

[0044] The computing device 341 may include a processor 372 as well as a memory 378. The memory 378 may store an operating system 379 that can facilitate the functionality discussed herein as well as a set of applications 375 (i.e., machine-readable instructions). For example, one of the set of applications 375 may be an alert management application 390 configured to facilitate management of alerts received from the device. It should be understood that one or more other applications 392 are contemplated.

[0045] Processor 372 may interface with memory 378 to execute an operating system 379 and a suite of applications 375. According to some embodiments, memory 378 may also store alert rules data 380, which may include rules specifying how alerts should be segmented or stored. In embodiments, memory 378 may be segmented to store alerts according to the rules of alert rules data 380 so that the alerts may be accessed, modified, deleted, and / or the like. Memory 378 may include one or more forms of volatile and / or non-volatile fixed and / or removable memory, such as, for example, ROM, EPROM, RAM, EEPROM, and / or other hard drives, flash memory, memory cards, etc.

[0046] Computing device 341 may further include a communications module 377 configured to interface with devices in field environment 90 via a wired connection or via one or more wireless networks. According to some embodiments, communications module 377 may include one or more transceivers (e.g., WWAN, WLAN, and / or WPAN transceivers) that function according to IEEE, 3GPP, or other standards and that are configured to transmit and receive data via one or more communications ports 376.

[0047] Computing device 341 may further include a user interface 381 configured to present information to and / or receive input from a user. As shown in FIG. 3, user interface 381 may include a display screen 382 and I / O components 383 (e.g., ports, capacitive or resistive touch-sensitive input panels, keys, buttons, lights, LEDs). According to some embodiments, a user may access computing device 341 via user interface 381 to review information (e.g., alert information), make selections, and / or perform other functions.

[0048] In some embodiments, computing device 341 may perform the functions discussed herein as part of a “cloud” network or may otherwise communicate with other hardware or software components in the cloud to transmit, retrieve, or otherwise analyze data.

[0049] Generally, a computer program product according to one embodiment may include a computer-usable storage medium (e.g., standard random access memory (RAM), optical disk, universal serial bus (USB), etc.) having computer-readable program code embedded therein, which may be adapted to be executed by processor 372 (e.g., working in conjunction with operating system 379) to facilitate the functions described herein. In this regard, the program code may be implemented in any desired language and may be implemented as machine code (e.g., via Golang, Python, Scala, C, C++, Java, Actionscript, Objective-C, Javascript, CSS, XML), assembly code, bytecode, interpretable source code, etc. In some embodiments, the computer program product may be part of a cloud network of resources.

[0050] 4 depicts an example signal diagram 400 associated with managing alerts generated by devices in a process control system of a process plant. The signal diagram 400 includes field device A 405 (such as one of the field devices discussed with respect to FIG. 1), field device B 406 (such as one of the field devices discussed with respect to FIG. 1), field device C 408 (such as one of the field devices discussed with respect to FIG. 1), and field device D 409 (such as one of the field devices discussed with respect to FIG. 1). 3. The computer system 400 may include a workstation B 410, a processor 415, and a memory 420. In one implementation, the processor 415 and the memory 420 may be included as part of a computing device 425 (such as the workstation 80 discussed with respect to FIG. 1 or the computing device 341 discussed with respect to FIG. 3). In another implementation, the processor 415 and the memory 420 may be associated with separate components or devices.

[0051] The signal diagram 400 may begin when field device A 405 generates (429) alert A. In an embodiment, field device A 405 may generate alert A in response to various conditions, triggers, etc. within the process plant, as discussed herein. Alert A may indicate an action(s) or condition(s) associated with the process control system, its component(s), or the field device 405 itself. Additionally, alert A may include or indicate various information, such as the type (e.g., “fault,” “maintenance,” “advisory,” or “communication”), severity (e.g., “low,” “medium,” or “high”), and the identity of the source device (here, field device A 405). Field device A 405 may transmit (430) alert A to processor 415, such as via the process control data highway 10.

[0052] The processor 415 may retrieve (432) from the memory 420 a set of rules applicable to alert A. In an embodiment, the processor 415 may examine alert A and retrieve one or more rules applicable to either alert A (or the information contained therein), field device A 405, or both. Generally, the rules may specify how to manage or process the received alert, which may include storing the received alert in a storage location (e.g., a container or folder) that may be specified by the rules.

[0053] The processor 415 may determine (434) whether any of the rule(s) is applicable to alert A. In particular, a rule is applicable to alert A if the information in alert A matches the rule, if field device A 405 (i.e., source A of the alert) matches the rule, or both. For example, a rule may specify that any alert from field device A 405 should be directed to a memory location associated with alert suppression; in another example, a rule may specify that any high severity alert received from any field device should be directed to a memory location associated with high priority; and in a further example, a rule may specify that any high severity alert received from field device A 405 should be directed to a memory location associated with communication generation. If no rule is applicable (“No”), processing may repeat, terminate, or proceed to other functions, such as monitoring for subsequent alerts.

[0054] If there is an applicable rule (“Yes”), processor 415 may provide (436) alert A to memory 420 for storage. In an embodiment, the rule applicable to alert A may specify a storage location (e.g., a particular folder or container) for alert A. Thus, memory 420 may store (438) alert A in the specified storage location, which may or may not store additional alerts received from field device A 405 or from additional field device(s). According to an embodiment, storage of alert A and / or the additional alerts in memory 420 may be implemented physically and / or logically.

[0055] The processor may further initiate (440) alert A, applicable rules, and / or applicable actions associated with storing alert A. According to an embodiment, a rule may be associated with storing the alert in a specified storage location and may be associated with initiating one or more actions. The alert suppression command may specify one or more actions. For example, the action may be to suppress alerts received from a particular device or group of devices. In normal operation, received alerts may be indicated or presented in a user interface of a workstation to allow an individual (e.g., a technician) to review the alert and determine any corrective actions. However, when an alert is suppressed, the alert may be prevented from being presented in the user interface of the workstation or may be presented separately from other alerts. In this example, any alerts stored in a memory location associated with alert suppression may be suppressed from being presented. Similarly, the action may be to unsuppress alerts received from a particular device or group of devices, such as in the case of alerts that were previously suppressed. Thus, any alerts stored in a memory location associated with alert unsuppression may be presented in the user interface of the workstation. In this example, any alerts that were previously suppressed may be presented in the user interface.

[0056] In another example, the action may be to send a notification (e.g., an email, text message, or other type of electronic communication) to a particular account or device, and the notification may indicate the alert as well as any information associated with the alert. Thus, any alert stored in a memory location associated with notification generation may cause processor 415 to generate a notification and send the notification to a designated recipient. For example, the designated recipient may be an email address, a phone number, a particular workstation or other electronic device, and / or the like. Thus, the recipient of the notification may review the notification and determine what action, if any, to take in response to the notification.

[0057] In a further example, the action may be to move alert(s) from one storage location to another. In particular, a rule may specify that storing an alert from a particular device in a specified storage location causes other alerts associated with the particular device to be relocated to the specified storage location. According to an embodiment, a rule and / or its associated action may be applicable to a single device (e.g., field device A405) or a group of devices. For example, a rule may specify that any low-priority alert from any device in a particular node (there may be several devices) be stored in a storage location associated with alert suppression.

[0058] In addition to or in lieu of the functionality discussed herein, the signal diagram 400 details a scenario having field device B 410 generate (441) alert B. In an embodiment, field device B 410 may generate alert B in response to various conditions, triggers, etc. within the process plant, as discussed herein. Alert B may indicate an action(s) or condition(s) associated with the process control system, its component(s), or the field device 410 itself. Additionally, alert B may include or indicate various information such as type (e.g., “Fault,” “Maintenance,” “Advisory,” or “Communication”), severity (e.g., “Low,” “Medium,” or “High”), and identification of the source device (here, field device B 410). Field device B 410 may transmit (442) alert B to processor 415, such as via the process control data highway 10.

[0059] The processor 415 may examine (444) alert B to determine whether any rules (such as one of the rules retrieved in (432)) are applicable to alert B. In this particular scenario, it may be assumed that no rules are applicable. Therefore, the processor 415 may determine (446) whether to create or generate a new rule. According to an embodiment, the processor 415 may examine alert B and its information, the source device, The controller may determine to create or generate a new rule based on the availability of the device (i.e., field device B410), the device (i.e., field device B410), or a combination thereof. In particular, the creation of a new rule may be based on availability resulting from the suppression (or unsuppression) of an alert, the generation and transmission of a notification, the relocation of an alert, and / or other factors.

[0060] For example, alert B may be of low severity and / or may be a duplicate of an alert previously received from field device B 410. In this example, processor 415 may determine that it may be beneficial to create a rule specifying that subsequent alerts from field device B 410 should be suppressed (i.e., moved to a storage location associated with alert suppression). As another example, alert B may specify a condition in field device B that may require immediate attention by a technician. In this example, processor 415 may determine that it may be beneficial to create and send to the technician a rule specifying that a notification be generated (and / or that a subsequent alert from field device B 410 triggers notification generation). It should be understood that additional examples are contemplated.

[0061] In another example, alert B may indicate that field device B 410 needs repair. In this example, processor 415 may determine that it may be advantageous to create a rule specifying that subsequent alerts indicating field device B 410 needs repair should be suppressed until a subsequent turnaround event (i.e., a scheduled occurrence to repair field device B 410). As such, alert B and the subsequent alerts may be associated with a memory location that may be designated as repair. After the turnaround event (perhaps to repair field device B 410), processor 415 may cause the suppressed alerts to be removed or deleted.

[0062] If processor 415 determines that a new rule is not needed (“no”), processing may repeat, terminate, or proceed to other functions, such as monitoring for subsequent alerts. If processor 415 determines that a new rule is needed (“yes”), processor 415 may generate (448) a new rule according to the analysis and determination of (446). Additionally, processor 415 may provide (450) the new rule to memory 420, which may store (452) the new rule. In this manner, processor 415 may retrieve or access the new rule from memory 420 for analysis in association with any subsequently received alerts to determine how to manage the subsequently received alerts.

[0063] 4, it should be understood that a user may access computing device 425 to create new rules or modify existing rules. In particular, a user may specify what to do when an alert (or type of alert) is received from a particular device, including the storage location to be associated with the alert and the action(s) to initiate.

[0064] 5 depicts a block diagram of an example method 500 for managing alerts associated with a set of devices in a process plant, at least some of which are communicatively connected to operate within the process plant during runtime to enable a process control system of the process plant to control the set of processes. According to an embodiment, method 500 may be facilitated by a computing device (such as an operator workstation) configured with an application and configured to connect to and interface with the set of devices in the process plant. It should be understood that the functionality of method 500 is exemplary and that additional or alternative functionality is contemplated.

[0065] Method 500 may begin when a computing device receives an alert associated with the operation of a device in a process plant from one of a set of devices (block 505). In an embodiment, the device may transmit the alert to the computing device in response to generating the alert. The computing device may access from memory a set of rules for managing the alert (block 510), where one rule in the set of rules (i) is applicable to the alert and (ii) specifies a storage location. In an embodiment, the alert may specify a severity and / or the rule may indicate a specified device. Further, the computing device may identify a rule based on one or more of the severity of the alert matching the specified severity of the rule and the devices matching the specified device of the rule.

[0066] The computing device may associate the alert with a storage location (block 515), where one or more of the rule and the storage location specify an action to initiate. In particular, associating the alert with a storage location may trigger the execution of a particular action, and the action itself may vary. In some particular scenarios, the action may relate to suppressing the alert, unsuppressing the alert, notifying the alert, or other action. Thus, the computing device may determine how to proceed based on the type of action (block 520).

[0067] If the action involves suppressing the alert (“Suppress”), the computing device may suppress the alert (block 525). In particular, the computing device may prevent or suppress the alert from being presented on a user interface that would otherwise be presented on the user interface. Thus, the alert associated with the storage location and any other alerts may be, at least temporarily, prevented from being presented on the user interface.

[0068] If the action involves unsuppressing the alert (“unsuppress”), the computing device may unsuppress the alert (block 530). In particular, the computing device may cause the alert to be presented on a user interface; otherwise, the alert is suppressed. In one implementation, the alert associated with the storage location and any other alerts may be presented on a user interface.

[0069] If the action relates to a notification (“Notification”), the computing device may generate a notification indicating the alert (block 535). Notably, the notification may be any type of electronic communication, such as a text message, email, or the like. The computing device may further transmit the notification to an electronic device (block 540), which may be internal or external to the process plant. In this manner, a user of the electronic device may review the notification and determine what action, if any, should be taken to address the alert.

[0070] 6 depicts a block diagram of an example method 600 for generating rules for managing alerts associated with a set of devices in a process plant, at least some of which are communicatively connected to operate within the process plant during runtime, enabling a process control system of the process plant to control the set of processes. According to an embodiment, method 600 may be facilitated by a computing device (such as an operator workstation) configured with an application and configured to connect to and interface with the set of devices in the process plant. It should be understood that the functionality of method 600 is exemplary and that additional or alternative functionality is contemplated.

[0071] Method 600 may begin when a computing device receives an alert associated with the operation of a device in a process plant from one of a set of devices (block 605). In an embodiment, the device may send the alert to the computing device in response to generating the alert. The computing device may determine whether to establish a new rule (block 610). In an embodiment, the determination may be based on the alert and / or the device. In one implementation, the alert may specify a severity (e.g., “high priority”), and the computing device may determine that the severity meets at least a threshold level and therefore that a new rule should be established. In another implementation, the computing device may determine to establish a new rule if no rule exists on the device. If the computing device determines not to establish a new rule (“no”), processing may return to block 605, end, or proceed to other functions. If the computing device determines to establish a new rule (“yes”), processing may proceed to block 615.

[0072] At block 615, the computing device may establish a new rule for the device, where the new rule may specify a storage location for an alert associated with the device's operation. In one implementation, such as when the alert has a severity, the new rule may specify that subsequent alerts associated with the device's operation and having the severity are associated with the storage location. In another implementation, the alert may indicate that the device needs repair, and the new rule may specify that subsequent alerts indicating that the device needs repair are associated with the storage location until a subsequent turnaround event.

[0073] In a further implementation, the new rule may specify an address (e.g., an email address or a phone number) for directing an electronic communication indicating an alert associated with the device operation. In yet a further implementation, the new rule may specify that a work order be generated indicating an alert associated with the device operation. The computing device may store (block 620) the new rule for subsequent access, such as when a subsequent alert is received.

[0074] The computing device may receive a subsequent alert associated with the device's operation from the device (block 625). After receiving the subsequent alert, the computing device may determine whether the new rule applies (block 630). For example, if the new rule specifies that an alert from device A with a high priority be stored in a high-priority folder, and the subsequent alert is a high-priority alert from device A, the computing device determines that the new rule applies. If the computing device determines that the new rule does not apply ("No"), processing may return to block 625 to monitor for subsequent alerts or proceed to an end or other function.

[0075] If the computing device determines that the new rule applies (“Yes”), the computing device may associate subsequent alerts with the storage location specified by the new rule (block 635). Thus, subsequent alerts may be stored according to the new rule.

[0076] 7 is an example diagram 700 depicting various functions associated with the present embodiment. The example diagram 700 includes a device 705 (such as one of the field devices as discussed with respect to FIG. 1) in communication with an asset management system 710, which may be implemented on the hardware and software of a computing device (such as computing device 341 as discussed with respect to FIG. 3). The device 705 generates device alerts 706 to notify asset management personnel. The information may be transmitted to the management system 710.

[0077] The asset management system 710 may implement a storage structure 720 for rules and alerts. According to an embodiment, the storage structure 720 includes a series of storage locations (depicted as a series of folders) with which rules and / or alerts may be associated. For example, the series of storage locations may include a "New Folder," "Next Turnaround," "Low Priority," "High Priority," and an "Active Alert List." Each of the series of storage locations may have an associated action that may be taken when an alert is stored in the corresponding storage location. For example, any alerts stored in the "Low Priority" folder may be suppressed from appearing in the user interface.

[0078] After receiving the device alert 706, the asset management system 710 may examine the device alert 706 to determine whether any rule(s) apply. Depending on whether a rule applies, the asset management system 710 may store the device alert 706 in an appropriate storage location accordingly. For example, the device alert 706 may be stored in a "low priority" folder, a "high priority" folder, or another folder. The asset management system 710 may add and initiate any actions associated with the appropriate storage location. For example, if the device alert 706 is added to the "active alerts list" folder, the asset management system 710 may generate and send an email to an appropriate account.

[0079] Asset management system 710 may further include a rules editor folder 715. According to an embodiment, a user may use rules editor folder 715 to enter new rules (or modify existing rules), which may have an associated one of the storage locations in storage structure 720. Using rules editor folder 715, a user may specify what to do when an alert (or type of alert) is received from a particular device, including the storage location to be associated with the alert and the action(s) to initiate.

[0080] Embodiments of the technology described in this disclosure may include any number of the following aspects, either alone or in combination.

[0081] 1. A computer-implemented method for managing alerts associated with a set of devices in a process plant, at least some of the set of devices being communicatively connected to operate within the process plant during runtime to enable a process control system of the process plant to control the set of processes, the method including: receiving, at a computing device, an alert associated with operation of the device in the process plant from one of the set of devices; accessing from a memory a set of rules for managing the alert, one rule of the set of rules (i) being applicable to the alert and (ii) specifying a storage location; accessing and associating the alert with the storage location, one or more of the rules and the storage location specifying an action to initiate; and initiating the action in response to associating the rule with the storage location.

[0082] 2. The computer-implemented method of claim 1, wherein initiating an action includes suppressing the alert from being presented on a user interface.

[0083] 3. The computer-implemented method of claim 1, wherein initiating an action includes generating a notification indicating the alert and sending the notification to an electronic device.

[0084] 4. The computer-implemented method of claim 1, further comprising: at the computing device, receiving from the device an additional alert associated with operation of a device in the process plant; determining that the rule applies to the additional alert; and associating the additional alert with a storage location in response to determining that the rule applies to the additional alert.

[0085] 5. The computer-implemented method of claim 1, wherein the alert specifies a severity, and wherein accessing a set of rules for managing the alert includes identifying a rule from the set of rules, and wherein the severity of the alert matches the specified severity of the rule.

[0086] 6. The computer-implemented method of claim 1, wherein the alert specifies a severity, and wherein accessing a set of rules for managing the alert includes identifying a rule from the set of rules, wherein (i) the severity of the alert matches the specified severity of the rule, and (ii) the device matches the specified device of the rule.

[0087] 7. The computer-implemented method of claim 1, wherein accessing a set of rules for managing alerts includes identifying a rule from the set of rules, wherein the device matches a specified device of the rule.

[0088] 8. The computer-implemented method of claim 1, further comprising: determining that the alert has been associated with the storage location for at least a threshold amount of time; and initiating additional actions in response to the determination.

[0089] 9. The computer-implemented method of claim 8, wherein initiating an additional action includes disassociating the alert from the storage location.

[0090] 10. A management system for managing alerts associated with a set of devices in a process plant, the system being communicatively connected to the set of devices, at least some of the set of devices being communicatively connected to operate within the process plant during runtime to enable a process control system of the process plant to control the set of processes; the system comprising: a memory (i) at least partially segmented into a set of memory locations and (ii) storing a set of rules for managing the alerts; and a processor interfacing with the memory, the processor configured to: receive an alert from one of the set of devices associated with operation of the device in the process plant; access the set of rules from the memory, where one rule of the set of rules (i) is applicable to the alert and (ii) specifies one of the set of memory locations; and associate the alert with the memory in the memory, where one or more of the rules and the storage location specify an action to initiate; and initiate the action in response to associating the rule with the storage location.

[0091] 11. The management system of claim 10, wherein to initiate the action, the processor is configured to suppress the alert from being presented on the user interface.

[0092] 12. The management system of claim 10, wherein to initiate the action, the processor is configured to generate a notification indicating the alert and cause the notification to be transmitted to the electronic device.

[0093] 13. The processor receives, from the device, an additional alert associated with operation of the device in the process plant, determines that the rule applies to the additional alert, and The management system of claim 10 , further configured to associate, in memory, the additional alert with the storage location in response to determining that applies to the additional alert.

[0094] 14. The management system of claim 10, wherein the alert specifies a severity, and to access the set of rules for managing the alert, the processor is configured to identify a rule from the set of rules, and the severity of the alert matches the specified severity of the rule.

[0095] 15. The management system of claim 10, wherein the alert specifies a severity, and to access a set of rules for managing the alert, the processor is configured to identify a rule from the set of rules, where (i) the severity of the alert matches the specified severity of the rule, and (ii) the device matches the specified device of the rule.

[0096] 16. The management system of claim 10, wherein to access the set of rules for managing the alert, the processor is configured to identify a rule from the set of rules, and the device matches a specified device of the rule.

[0097] 17. The management system of claim 10, wherein the processor is further configured to determine that the alert has been associated with the storage location for at least a threshold amount of time, and to initiate additional actions in response to the determination.

[0098] 18. The management system of claim 17, wherein the processor is configured to disassociate the alert from the storage location to initiate additional actions.

[0099] 19. A computer-implemented method for generating rules for managing alerts associated with a set of devices in a process plant, at least some of the set of devices being communicatively connected to operate within the process plant during runtime to enable a process control system of the process plant to control the set of processes, the method including: receiving, at a computing device, an alert associated with operation of the device from one of the set of devices in the process plant; determining from the alert that a new rule should be established for the device; establishing the new rule for the device, the new rule specifying a memory location for the alert associated with the operation of the device; receiving, at the computing device, a subsequent alert associated with operation of the device from the device; and after receiving the subsequent alert, associating the subsequent alert with the memory location specified by the new rule.

[0100] 20. The computer-implemented method of claim 19, wherein the alert specifies a severity level, and determining from the alert that a new rule should be established for the device includes determining that the severity of the alert meets at least a threshold level.

[0101] 21. The computer-implemented method of claim 20, wherein establishing a new rule for the device includes establishing a new rule for the device, the new rule being associated with an operation of the device and specifying that a subsequent alert having a severity is associated with a storage location.

[0102] 22. The method of claim 19, wherein determining from the alert that a new rule should be established for the device includes determining that a rule does not exist for the device. The computer-implemented method described herein.

[0103] 23. The computer-implemented method of claim 19, wherein the alert indicates that the device needs repair, and wherein establishing a new rule for the device includes establishing a new rule for the device, the new rule specifying that subsequent alerts indicating that the device needs repair will be associated with the storage location until a subsequent turnaround event.

[0104] 24. The computer-implemented method of claim 19, wherein establishing a new rule for the device includes establishing a new rule for the device, the new rule further specifying an address for directing electronic communications indicating an alert associated with operation of the device.

[0105] 25. The computer-implemented method of claim 19, wherein establishing a new rule for the device includes establishing a new rule for the device, the new rule further specifying that a work order is generated indicating an alert associated with operation of the device.

[0106] 26. The computer-implemented method of claim 19, further comprising storing the new rules for subsequent accesses.

[0107] 27. The computer-implemented method of claim 19, wherein associating the subsequent alert with the memory location specified by the new rule comprises: determining that the new rule applies to the subsequent alert; and associating the subsequent alert with the memory location specified by the new rule.

[0108] 28. A management system for managing alerts associated with a set of devices in a process plant, the system being communicatively connected to the set of devices, at least some of the set of devices being communicatively connected to operate within the process plant during runtime to enable a process control system of the process plant to control a set of processes; the system comprising: a memory (i) at least partially segmented into a set of memory locations and (ii) storing a set of rules for managing the alerts; and a processor interfaced with the memory, the processor being configured to: receive, from one of the set of devices, an alert associated with operation of the device in the process plant; determine from the alert that a new rule should be established for the device; establish the new rule for the device, where the new rule specifies a memory location for the alert associated with the operation of the device; receive, from the device, a subsequent alert associated with the operation of the device; and, after receiving the subsequent alert, associate the subsequent alert in the memory with the memory location specified by the new rule.

[0109] 29. The management system of claim 28, wherein the alert specifies a severity level, and to determine from the alert that a new rule should be established for the device, the processor is configured to determine that the severity of the alert meets at least a threshold level.

[0110] 30. The management system of claim 29, wherein the new rule specifies that subsequent alerts associated with the device operation and having a severity are associated with a storage location.

[0111] 31. The management system of claim 28, wherein to determine from the alert that a new rule should be established for the device, the processor is configured to determine that a rule does not exist for the device.

[0112] 32. The management system of claim 28, wherein the alert indicates that the device needs repair, and the processor establishes a new rule specifying that subsequent alerts indicating that the device needs repair will be associated with the storage location until a subsequent turnaround event.

[0113] 33. The management system of claim 28, wherein the new rule further specifies an address for directing an electronic communication indicating an alert associated with operation of the device.

[0114] 34. The management system of claim 28, wherein the new rule further specifies that a work order is generated indicating an alert associated with the operation of the device.

[0115] 35. The management system of claim 28, wherein the processor is further configured to cause the memory to store the new rules for subsequent accesses.

[0116] 36. The management system of claim 28, wherein the memory, to associate the subsequent alert with the memory location specified by the new rule, the processor is configured to: determine that the new rule applies to the subsequent alert, and associate, in the memory, the subsequent alert with the memory location specified by the new rule.

[0117] Additionally, the foregoing aspects of the present disclosure are merely illustrative and are not intended to limit the scope of the present disclosure.

[0118] 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 in accordance with 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., an operator workstation, a commissioning tool, 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 computer-readable medium, the terms “stored” and “saved” are intended to exclude transitory signals.

[0119] Additionally, the terms "operator," "personnel," "person," "user," "technician," "administrator," 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.

[0120] Additionally, throughout this specification, multiple instances may refer to a component, an operation, or a single instance. The structures described may be implemented as a single component. Although individual operations of one or more methods are 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 illustrative configurations may be implemented as a combined structure or component. Similarly, structures and functions presented as a single component 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.

[0121] Unless specifically stated otherwise, discussions herein using words such as "processing," "operating," "calculating," "determining," "identifying," "presenting," "causing to present," "displaying," "displaying," and the like may refer to machine (e.g., computer) actions or processes that manipulate or transform 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.

[0122] If 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 as including, among other components, software and / or firmware running on hardware, 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 embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, those skilled in the art will readily appreciate that the provided examples are not the only ways to implement such systems.

[0123] Thus, while the present 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.

[0124] It should also be understood that unless a term is expressly defined in this patent using the sentence "As used herein, the term '______' is defined herein to mean..." or similar, 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 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, this is done solely 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.

[0125] Furthermore, while the above text sets forth detailed descriptions of many different embodiments, it is understood that the scope of this patent is defined by the language of the claims set forth at the end of this patent. It should be understood that the detailed description is to be construed as merely exemplary and does not describe every possible embodiment, as doing so 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. 1. A computer-implemented method for generating rules for managing alerts associated with a set of devices in a process plant, at least some of the devices being communicatively connected to operate within the process plant during runtime to enable control of a set of processes by a process control system of the process plant, the method comprising: receiving, at a computing device, an alert from a device of the set of devices associated with operation of the device within the process plant; determining from the alert that a subsequent alert associated with operation of the device should be unsuppressed; establishing a new rule for the device based on determining that a subsequent alert from the device should be unsuppressed, the new rule specifying a memory location for the subsequent alert associated with operation of the device; receiving, from the device, at the computing device, a subsequent alert associated with operation of the device; after receiving the subsequent alert, associating the subsequent alert with the memory location specified by the new rule.

2. The computer-implemented method of claim 1, further comprising presenting the subsequent alert in a user interface.

3. Presenting the subsequent alert in the user interface, The computer-implemented method of claim 2 , further comprising presenting the subsequent alert and any other alerts associated with the storage location in the user interface.

4. The method of claim 1, further comprising:

4. The method of claim 1, further comprising: establishing the new rule for the device, the new rule further specifying an address for directing electronic communications indicating the alert associated with operation of the device. Computer-implemented method.

5. The method of claim 1, further comprising:

5. The computer-implemented method of claim 1, further comprising establishing the new rule for the device, the new rule further specifying that a work order is generated indicating the alert associated with operation of the device.

6. 1. A management system for managing alerts associated with a set of devices in a process plant, the system being communicatively connected to the set of devices, at least some of the devices being communicatively connected to operate within the process plant during runtime to enable control of a set of processes by a process control system of the process plant; (i) a memory at least partially segmented into a set of memory locations, and (ii) storing a set of rules for managing alerts; a processor interfaced with the memory, receiving an alert from a device in the set of devices associated with operation of the device within the process plant; determining from the alert that a subsequent alert associated with the operation of the device should be unsuppressed; establishing a new rule for the device based on determining that a subsequent alert from the device should be unsuppressed, where the new rule specifies a memory location for the subsequent alert associated with operation of the device; receiving a subsequent alert from the device associated with operation of the device; a processor configured to, after receiving the subsequent alert, associate in the memory the subsequent alert with the memory location specified by the new rule.

7. Further comprising a user interface, The processor, The management system of claim 6 , further configured to cause the user interface to present the subsequent alert.

8. The method of claim 7, further comprising: causing the user interface to present the subsequent alert; The management system of claim 7 , configured to cause the user interface to present the subsequent alert and any other alerts associated with the storage location.

9. To establish the new rules for the device, the processor:

9. The management system of claim 6, configured to establish the new rule for the device, wherein the new rule further specifies an address for directing electronic communications indicating the alert associated with operation of the device.

10. To establish the new rules for the device, the processor:

10. The management system of claim 6, configured to establish the new rule for the device, wherein the new rule further specifies that a work order is generated indicating the alert associated with operation of the device.

11. The processor, The management system of claim 6 , further configured to store the new rules for subsequent accesses.

12. To associate the subsequent alert with the memory location specified by the new rule, the processor: determining that the new rule applies to the subsequent alert; The management system of claim 6 , configured to associate the subsequent alert with the storage location specified by the new rule.

13. 1. A non-transitory computer readable medium having stored thereon a set of instructions executable by a processor to manage alerts associated with a set of devices in a process plant, at least some of the devices being communicatively connected to operate within the process plant during runtime to enable a process control system in the process plant to control a set of processes, the instructions comprising: instructions for receiving, at a computing device, from a device in the set of devices, an alert associated with operation of the device within the process plant; instructions for determining from the alert that a subsequent alert associated with operation of the device should be unsuppressed; instructions for establishing a new rule for the device based on determining that a subsequent alert from the device should be unsuppressed, the new rule specifying a memory location for the subsequent alert associated with operation of the device; instructions for receiving, at the computing device, from the device, a subsequent alert associated with operation of the device; and instructions for, after receiving the subsequent alert, associating the subsequent alert with the memory location specified by the new rule.

14. The non-transitory computer-readable medium of claim 13, wherein the instructions further include instructions for presenting the subsequent alert in a user interface.

15. The method of claim 1, further comprising:

15. The non-transitory computer-readable medium of claim 14 comprising instructions for presenting the subsequent alert and any other alerts associated with the storage location in the user interface.

Images