The subject matter disclosed herein relates to process control systems and, more specifically, to monitoring the health of a process controller.
Control systems are often used in conjunction with process systems, such as manufacturing or production processes, to regulate and/or monitor various operating parameters of the process. For instance, a control system may regulate the values of certain input parameters of the process in order to drive one or more target output parameters (e.g., flow rate, power output, etc.) to a desired value. Some control systems may also provide process data to an operator in the form of visual feedback, such as by outputting certain selected data points through a human-machine interface (HMI), which may include a graphical user interface displayed using a display device. This may enable the operator to monitor and assess the process performance parameters in substantially real time and, if necessary, take corrective actions if certain parameters are deviating from an expected range or norm.
Such control systems may use process controllers for controlling system operations, and the process controllers may include a combination of hardware and software components. As may be appreciated, components of the process controller may not function as anticipated. Therefore, the components of the process controller may be monitored to identify potential problems that may occur. The monitoring system may provide alarm data (e.g., diagnostic alarm messages) to an operator to notify the operator about the potential process controller problems. However, such monitoring systems may provide large amounts of data that can be difficult to interpret. Further, the alarm data may include false alarms or repeating alarms that make it hard to determine where real problems are occurring. Still further, the alarm data may require a human operator to decipher multiple signals to determine an actual problem.
Certain embodiments commensurate in scope with the originally claimed invention are summarized below. These embodiments are not intended to limit the scope of the claimed invention, but rather these embodiments are intended only to provide a brief summary of possible forms of the invention. Indeed, the invention may encompass a variety of forms that may be similar to or different from the embodiments set forth below.
In a first embodiment, a system is provided for monitoring health of a process control system. The system includes a device configured to receive diagnostic alarm data that relates to the health of the process control system, group the diagnostic alarm data into a plurality of groups, and identify a problem associated with each group of diagnostic alarm data in the plurality of groups.
In a second embodiment, an article of manufacture is provided for a health monitoring system. The article of manufacture includes one or more tangible, machine-readable media having encoded thereon processor-executable instructions having instructions to receive diagnostic alarm data that relates to the health of the process control system, instructions to group the diagnostic alarm data into a plurality of groups, and instructions to identify a problem associated with each group of diagnostic alarm data in the plurality of groups.
In a third embodiment, a method is provided for monitoring health of a process control system. The method includes receiving diagnostic alarm data that relates to the health of the process control system, grouping the diagnostic alarm data into a plurality of groups, and identifying a problem associated with each group of diagnostic alarm data in the plurality of groups.
These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
One or more specific embodiments of the present invention will be described below. In an effort to provide a concise description of these embodiments, all features of an actual implementation may not be described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
When introducing elements of various embodiments of the present invention, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements. Further, the term “client” may refer to a computer (e.g., a processor and storage that allows execution and storage of machine-readable instructions to provide the functionality described herein) and/or computer processes running on such computers.
The disclosed embodiments relate to systems and methods for monitoring and improving health of a process controller (e.g., whether components of the process controller are functioning properly), such as an industrial process controller in an industrial system. For example, the disclosed embodiments may be used to monitor and improve health of N-level redundant process controllers, wherein N is equal to 1, 2, 3, 4, 5, or more. In certain embodiments, the process controllers may be triple modular redundant (TMR) process controllers, such as Mark™ VIe controllers running ControlST software, made by General Electric Company of Schenectady New York. These N-level redundant process controllers may be used in various industrial systems, such as turbine systems, power generation systems, power distribution systems (e.g., for an electrical power grid), gas processing systems, chemical production systems, gasification systems, industrial automation systems, power plants, or any other suitable industrial system. Furthermore, these N-level redundant controllers may be used with specific equipment, such as gas turbines, steam turbines, gasifiers, compressors, boilers, furnaces, heat recovery steam generators (HRSGs), air separation units (ASUs), acid gas removal (AGR) units, carbon capture units, motorized machinery, or any combination thereof. Accordingly, the health of these process controllers may be particularly important for maintaining the operation of these systems and equipment, because the efficiency and continuous operation of these systems and equipment may affect services such as power distribution to an electrical power grid.
In certain embodiments discussed in detail below, the health monitoring systems include a device (e.g., computer and/or computer processes running on computers) in the system that receives diagnostic alarm data that relates to the health of the process controller. The device may include components (e.g., software and/or hardware) that filter the diagnostic alarm data based on a set of rules resulting in a limited set of diagnostic alarm data (e.g., false alarm data removed, duplicate alarm data removed, etc.). The device may include components (e.g., software and/or hardware) that validate the diagnostic alarm data based on a set of rules resulting in a limited set of diagnostic alarm data (e.g., invalid alarms removed). The device may include components (e.g., software and/or hardware) that group the diagnostic alarm data based on a set of rules resulting in one or more groups of diagnostic alarm data (e.g., based on logical or other relationships). The device may include components (e.g., software and/or hardware) that identify and prioritize problems associated with each group of diagnostic alarm data based on known problem data, an analysis of characteristics of diagnostic alarm data, user defined problem data, rules, predictive models, knowledge based data, or any combination thereof. The device may include components (e.g., software and/or hardware) that identify and prioritize solutions for each problem associated with each group of diagnostic alarm data based on known solution data, an analysis of characteristics of diagnostic alarm data, user defined solution data, rules, predictive models, knowledge based data, or any combination thereof. The device may also output information or notifications pertaining to the diagnostic alarm data, groups, problems, and solutions to a user interface, either locally or remotely, to enable viewing and selection of an appropriate solution. For example, the user interface may be displayed on a display screen, such that a user can view a prioritized list of possible solutions for each problem associated with each group. In this manner, the disclosed embodiments may effectively process the diagnostic alarm data to identify symptoms indicative a common health issue (e.g., problem) with the process controller, and then propose a solution based on historical data, knowledge based data, models, heuristics, and so forth. Thus, the disclosed embodiment may substantially improve the process of diagnosing and correcting problems with the process controller, thereby helping to maintain continuous operation, efficiency, and performance of the process controller.
With the foregoing in mind,
In the illustrated embodiment, the turbine system 18 includes sensors 29 which provide feedback relating to the operation of the turbine system 18. The process controller 16 receives data from the sensors 29 and may also control the operation of the turbine system 18 (e.g., gas turbine system, steam turbine system, etc.). However, as may be appreciated, the process controller 16 may control any suitable type of process. For example, the process controller 16 may control operation of a utility system, a manufacturing plant, a boiler system, a water treatment system, a blowout preventer system (e.g., in a drilling system), and so forth. The process controller 16 operates using control circuitry 30 which may include various components. For example, the control circuitry 30 may include one or more controllers, printed circuit boards, switches, cables, or any suitable electronic component.
In addition, the process controller 16 includes a processor 32, storage 34, memory 36, and may include a display 38. Each of these devices may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium) or a combination of both hardware and software elements. It should be noted that the process controller 16 is merely one example of a particular implementation and is intended to illustrate the types of components that may be present in the process controller 16. It should also be noted that the processor 32 and/or other data processing circuitry may be generally referred to herein as “data processing circuitry.” This data processing circuitry may be embodied wholly or in part as software, firmware, hardware, or any combination thereof. Furthermore, the data processing circuitry may be a single contained processing module or may be incorporated wholly or partially within any of the other elements within the process controller 16.
The processor 32 and/or other data processing circuitry may be operably coupled with the nonvolatile storage 34 and the memory 36 to execute instructions. Such programs or instructions executed by the processor 32 may be stored in any suitable article of manufacture that includes one or more tangible, computer-readable media at least collectively storing the instructions or routines, such as the nonvolatile storage 34 and the memory 36. The nonvolatile storage 34 and the memory 36 may include any suitable articles of manufacture for storing data and executable instructions, such as random-access memory, read-only memory, rewritable flash memory, hard drives, and optical discs. The display 38 may be any type of display for showing information, such as any device that may depict the status of processes being controlled by the process controller 16.
The control circuitry 30 and/or the processor 32 of the process controller 16 monitor the health of the components of the process controller 16. As such, the process controller 16 provides broadcast data that includes process controller 16 health data (e.g., data that may indicate a problem with a component of the process controller 16) as well as other process control data (e.g., data relating to the operation of the processes being controlled).
The workstations 20, 22, and 24 are configured to receive the broadcast data from the process controller 16 and to process and/or display portions of the broadcast data that relate to the particular workstation 20, 22, and 24 (e.g., the workstations 20, 22, and 24 may extract portions of the broadcast data, such as process controller 16 health data). To accomplish this, the workstations 20, 22, and 24 each include a processor 40, storage 42, memory 44, and a display 46. Further, the workstations 20, 22, and 24 may include a human machine interface (HMI) for an operator to use for displaying the broadcast data and/or communicating with the process controller 16. As may be appreciated, the process controller 16 health data (i.e., diagnostic alarm data) may be displayed by the workstations 20, 22, and 24. However, the process controller 16 health data may be presented in a format that makes the data hard to understand. Further, there may be large amounts of process controller 16 heath data which makes the data difficult to sort through and diagnose. For example, the process controller 16 health data may be presented with other broadcast data (e.g., data relating to the process being controlled) and the other broadcast data may appear to be more important to an operator. Therefore, in certain situations, the operator may ignore the process controller 16 health data because of these or other difficulties.
To decrease the amount of process controller 16 health data (i.e., diagnostic alarm data) and make the data easier to analyze, the diagnostic alarm data is sent to the rules device 26 for filtering. In certain embodiments, the rules device 26 receives diagnostic alarm data from the process controller 30. However, in other embodiments, the rules device 26 may receive diagnostic alarm data from one of the workstations 20, 22, and 24. Like the workstations 20, 22, and 24, the rules device 26 includes a processor 48, memory 50, storage 52, and may include a display 54. As may be appreciated, the processors 40 and 48, storage devices 42 and 52, memory 44 and 50, and displays 46 and 54 of the workstations 20, 22, and 24, and the rules device 26 may function in a similar manner to the respective components of the process controller 16 described above.
As illustrated, the storage 52 of the rules device 26 may include rules 56 that are used to filter, group, identify health issues (e.g., problems) in each group, and identify solutions for each problem in each group relating to the diagnostic alarm data (e.g., using thresholds, algorithms, or other logic). Further, the storage 52 may include a rules engine 57 which is used to receive diagnostic alarm data, filter the diagnostic alarm data based on the rules 56, group the diagnostic alarm data based on the rules 56, identify at least one problem for each group of diagnostic alarm data based on the rules 56, identify at least one solution for each problem in each group of diagnostic alarm data based on the rules 56, and output data or notification pertaining to the groups, problems, and solutions.
The rules engine 57 (e.g., based on rules 56) may be configured to filter the diagnostic alarm data to produce a filtered or limited diagnostic alarm data, which may be limited to actionable diagnostic alarm data (e.g., data that can be used to take corrective action). It should be noted that, in certain embodiments, the storage 52 of the rules device 26 may include software for collecting or extracting data from the broadcast data of the process controller 30. In addition, in certain embodiments, the filtered diagnostic alarm data may be provided to the remote monitoring portion 14 where the filtered diagnostic alarm data may be analyzed. As may be appreciated, the rules 56 may include any suitable filtering rules that can be used to filter the diagnostic alarm data. For example, the rules 56 may include rules for filtering the diagnostic alarm data based on: a frequency that diagnostic alarm data is repeated (e.g., the rules may filter out diagnostic alarm data for an alarm that repeats more often than one time per minute, hour, day, week, etc.), a state of the process controller (e.g., startup, shutdown, normal operation, unknown), a group associated with the diagnostic alarm data (e.g., alarm data from a specific controller, alarm data that relates to certain types of components, alarm data that relates to a certain time period, a newly occurring alarm), a type of process controller being monitored (e.g., analog, digital), a feature related to a history of the diagnostic alarm data (e.g., a time that an alarm occurs, a recurring diagnostic alarm, an alarm that has previously been provided to the remote monitoring portion 14), whether the alarm is actionable (e.g., whether there is a resolution for the problem causing the alarm), and an expected alarm within the diagnostic alarm data (e.g., a known recurring alarm, a false alarm).
The rules engine 57 (e.g., based on rules 56) may be configured to group the diagnostic alarm data to produce a plurality of groups diagnostic alarm data, which may be grouped based on various logical or other relationships. Furthermore, the rules engine 57 (e.g., based on rules 56) may be configured to identify problems and solutions for each group of the diagnostic alarm data, which may substantially improve diagnostics and health of the process controller 16 by reducing the amount of user analysis to troubleshoot various problems. For example, the rules engine 57 may be configured to group, identify problems, and identify solutions relating to the diagnostic alarm data based on knowledge based rules 56 detailing expert knowledge on the workings and configurations of the process controller 16, the turbine system 18, as well as knowledge useful in making deductions or predictions on the correlations between different diagnostic alarm data. By further example, the rules engine 57 may include expert system rules 56 (e.g., forward chained expert system, backward chained expert system), regression models (e.g., linear regression, non-linear regression), recursive rules (e.g., Prolog rules), dynamic logic rules (e.g., modal logic), neural network rules, genetic algorithm rules, fuzzy logic models (e.g., predictive fuzzy logic models), and other predictive models (e.g., Markov chain models, Bayesian models, support vector machine models) that may be used to predict the correlations between various diagnostic alarm data, possible problems, and possible solutions relating to undesired maintenance events (e.g., failure of a power supply, failure of a processor core, failure of an input/output [I/O] pack, insufficient memory, loose bus connection) related to the process controller 16. By further example, the rules engine 57 may be configured to group, identify problems, and identify solutions relating to the diagnostic alarm data based on “if . . . then . . . ” rules 56 with the “if” portion set as an antecedent condition, and the “then” portion set as a consequent of the antecedent condition. Furthermore, the rules 56 may be derived through consultation with one or more experts in the field, such as a controller system health experts, or automatically, such as by using machine learning techniques (e.g., reinforcement learning, decision tree learning, inductive logic programming, neural network training, clustering, support vector machine).
The rules device 26 may receive the rules 56 as part of site configuration data that one or more of the workstations 20, 22, and 24 provide to the rules device 26. Further, in certain embodiments, the rules device 26 may receive the rules 56 as part of site configuration data from another source, such as from another portion of the rules device 26. Specifically, the site configuration data may include specific rules that apply to a specific process controller 16 being monitored and/or to a specific location of the process controller 16.
The remote monitoring portion 14 is used to transmit configuration data to the rules device 26 and to receive diagnostic alarm data (e.g., filtered, grouped, and correlated with respective problems and solutions) from the rules device 26. Specifically, the remote monitoring portion 14 includes a configuration device 58 and one or more remote services computers 60. Further, the configuration device 58 includes configuration rules data 62, which the configuration device 58 transmits to the rules device 26. For example, the filtering rules 56 of the rules device 26 may include a combination of the configuration rules data 62 from the configuration device 58 and the rules from the site configuration data to form a combined set of rules 56 for filtering diagnostic alarm data. In certain embodiments, the configuration rules data 62 may include generic filtering rules that apply to diagnostic alarm data from any process controller 16 at any location (e.g., the filtering rules apply to multiple process controllers 16). Likewise, the configuration rules data 62 may include various data grouping or classifying rules 56, problem identification rules 56, and solution identification rules 56 that are either generic for all process controllers 16, tailored to particular classes or types of controllers 16, or tailored to an individual controller 16 or industrial system using the controller 16.
The remote services computer 60 receives diagnostic alarm data (e.g., filtered, grouped, and correlated with respective problems and solutions) from the rules device 26. Specifically, the remote service computer 60 includes a processor 64, storage 66, memory 68, and a display 70 for receiving and displaying the diagnostic alarm data (e.g., filtered, grouped, and correlated with respective problems and solutions) received from the rules device 26. As may be appreciated, the processor 64, the storage 66, the memory 68, and the display 70 may function in a similar manner to the respective components of the process controller 16 described above. The remote services computer 60 also includes a user interface 72 which may enable an operator to interact with the remote services computer 60 (e.g., view diagnostic alarm data as filtered, grouped, and correlated with respective problems and solutions). As illustrated, the configuration device 58 and the remote service computer 60 include the wireless antenna 28 for wireless communications. In other embodiments, the configuration device 58 and the remote service computer 60 may communicate using a wired system or a combination of a wireless and a wired system. As may be appreciated, the components of the utility plant system 12 may communicate with the components of the remote monitoring portion 14.
At block 82, the rules engine 57 of the rules device 26 receives the diagnostic alarm data from the workstations 20, 22, and 24. As may be appreciated, in certain embodiments, the rules engine 57 may be configured to receive the diagnostic alarm data directly from the process controller 16, or from some other device, such as another device within the rules device 26. In other embodiments, the rules engine 57 may be directly built into the process controller 16. Next, at block 84, the rules engine 57 filters the diagnostic alarm data based on a selected set of rules 56. As previously described, the rules device 26 may receive the rules 56 from site configuration files provided to the rules device 26 by the workstations 20, 22, and 24, and/or the rules device 26 may receive the rules 56 from the configuration device 58. As may be appreciated, the rules device 26 may receive the rules 56 from another suitable source. Some or all of the rules 56 may be selected and applied to the diagnostic alarm data received by the rules engine 57. The rules 56 may apply any suitable logic to filter the diagnostic alarm data, as described above. At block 86, the rules engine 57 provides a limited or filtered set of diagnostic alarm data to a remote location (e.g., the remote monitoring portion 14 or the remote services computer 60). It should be noted that data may be transmitted and/or received by the various devices in the system 10 as the data is produced (e.g., not stored for later analysis, substantially real time). Further, the rules engine 57 may apply the rules 56 to the diagnostic alarm data as the engine 57 receives the data. Likewise, the filtered or limited diagnostic alarm data (e.g., actionable diagnostic alarm data) may be transmitted to the remote services computer 60 as soon as it has been filtered.
Next, at block 96, the operator determines the cause of the diagnostic alarm data. The operator may use many different resources to determine the cause of the diagnostic alarm data. For example, the operator may analyze the operation of the process at the same time that the alarm was generated, or the operator may analyze what the process controller 16 was trying to do when the alarm was generated. Further, the operator may contact personnel located where the process controller 16 is located, remotely connect to the process controller 16 (e.g., via a network connection, using a network lockbox, remote services gateway, etc.), remotely look through historic or current diagnostic alarm data stored on the process controller 16, and remotely check the status of the process controlled by the process controller 16. The operator may also utilize technology experts to determine the cause of the diagnostic alarm data. At block 98, the operator formulates steps to resolve any issues with the portion of the process controller 16 that relates to the diagnostic alarm data. Then, at block 100, the health issues of the process controller 16 are resolved (e.g., such as by modifying software configurations, replacing hardware, etc.). For example, in certain embodiments, the operator may transmit instructions and/or send hardware for resolving the health issues to personnel located where the process controller 16 is located. In other embodiments, the operator may implement steps to resolve the health issues of the process controller 16 (e.g., by modifying software settings). As may be appreciated, prior to implementing steps to resolve the health issues of the process controller 16, the operator may contact personnel located where the process controller 16 is located to notify the personnel of the steps to be used.
As may be appreciated, in certain embodiments, the rules engine 57 may be configured to receive the diagnostic alarm data 112 directly from the process controller 16, or from some other device, such as another device within the rules device 26. In other embodiments, the rules engine 57 may be directly built into the process controller 16. As discussed in detail above, during operation of the monitoring system 10, the process controller 16 broadcasts data that includes diagnostic alarm data 112 (e.g., health data relating to components of the process controller 16). The workstations 20, 22, and 24 may extract data from the broadcast data based on the particular purpose and/or configuration of the workstation 20, 22, or 24 receiving the data. For example, one workstation 20, 22, or 24 may be used to monitor (and extract data from the broadcast data relating to) the operation of one or more components of the turbine system 18 (e.g., steam and/or gas turbine), gasifier, gas treatment system, compressor, boiler, furnace, air separation unit, electrical generator, or any combination thereof. Further, the workstations 20, 22, and 24 may extract diagnostic alarm data 112 from the broadcast data, wherein the diagnostic alarm data 112 relates to the process being controlled and the health of components within the process controller 16. In certain situations, an operator may not know how to respond to diagnostic alarm data that appears on the display of one of the workstations 20, 22, and 24. Further, there may be large amounts of diagnostic alarm data. Therefore, in block 114, the rules engine 57 of the rules device 26 collects the diagnostic alarm data 112 from the workstations 20, 22, and 24.
In certain embodiments, the rules engine 57 of the rules device 26 collects 114 diagnostic alarm data 112 during sessions of passive listening, i.e., without interfering with control system operation. During the sessions, diagnostic alarm data 112 may be simultaneously collected and extracted; the extracted data being sent to the rules device 26 and/or the remote service computer 60. Passive listening allows collection 114 of critical alarms for comprehensive diagnostic purposes, while still allowing them to be handled expediently at the time they are generated. In one embodiment of passive listening, diagnostic alarm data 112 is collected 114 through consecutive sessions of user-defined or preset intervals. For example, the rules engine 57 of the rules device 26 may collect diagnostic alarm data 112 for a session of approximately 1 to 24, 2 to 16, 3 to 12, or 4 to 8 hours before closing the session with the controller 16. These sessions of data collection 114 may be well suited for lower priority diagnostic alarm data 112, e.g., wherein any problems may be addressed at a later time. The rules engine 57 of the rules device 26 may continue running sessions until a user intervenes or all the sessions in the queue have completed. By further example, the rules engine 57 of the rules device 26 may collect diagnostic alarm data 112 during certain events, such as an installation or replacement of a component, a critical event that may warrant an immediate analysis and troubleshooting, or any other time. For example, in certain embodiments, the data collection 112 may occur in real-time during operation of the process controller 16, particularly for diagnostic alarm data 112 of a higher priority or criticality.
At block 116, the rules engine 57 processes the diagnostic alarm data 112 to identify at least one problem based on a selected set of rules 56. As appreciated, the processing step 116 may occur at a time delay after data collection 114 (e.g., after an 8 hour session of data collection 114), or the processing step 116 may occur substantially immediately (e.g., in real-time) as the diagnostic alarm data 112 is collected by the system 10. As previously described, the rules device 26 may receive the rules 56 from site configuration files provided to the rules device 26 by the workstations 20, 22, and 24, and/or the rules device 26 may receive the rules 56 from the configuration device 58. As may be appreciated, the rules device 26 may receive the rules 56 from another suitable source. Some or all of the rules 56 may be selected and applied to the diagnostic alarm data 112 received by the rules engine 57. The rules 56 may apply any suitable logic to filter, validate, and group the diagnostic alarm data 112, as described below. Furthermore, the rules 56 may apply any suitable logic to identify at least one problem for each group of the diagnostic alarm data 112, as well as identify at least one solution for each problem. Further, the rules engine 57 may apply the rules 56 to the diagnostic alarm data 112 as the engine 57 receives the data 112. As discussed above, the process 110 may be used to identify the at least one problem (block 116) based on various rules 56, such as knowledge based rules, expert system rules, regression models, recursive rules, dynamic logic rules, neural network rules, genetic algorithm rules, fuzzy logic models, predictive models, “if . . . then . . . ” rules, or any combination thereof.
After problems are identified at block 116, the process 110 may then output one or more notifications 120 relating to the at least one problem (block 118), e.g., to an on-site or off-site location where appropriate action may be taken. For example, the diagnostic alarm data 112 (e.g., subject to processing 116) and identified problems may be transmitted to the remote services computer 60 upon completion of the processing 116. The notifications 120 may include a list of problems and suggested solutions (e.g., actions) that may solve the problems identified from processing 116 the diagnostic alarm data 112. For example, the notifications 120 may further prioritize the list of problems in an order of criticality or urgency, while also prioritizing the list of solutions in an order of relevancy, probability of correcting the problem, or the like. In this manner, the notifications 120 substantially improve the user's ability to analyze and respond to the diagnostic alarm data 112, thereby helping to increase health, maintain continuous operation, and improve performance and/or efficiency of the process controller 16 and the industrial system (e.g., turbine system 18).
At block 126, the rules engine 57 of the rules device 26 filters the diagnostic alarm data 112 from the workstations 20, 22, and 24 based on the rules 56 (e.g., filtering rules), as discussed in detail above with reference to
At block 128, the rules engine 57 of the rules device 26 validates the diagnostic alarm data 112 from the workstations 20, 22, and 24 based on the rules 56 (e.g., validation rules), thereby removing any invalid alarms. In certain embodiments, the validation step 128 may check a variety of parameters, such as an alarm condition and an alarm source, to ensure that the alarm is valid. For example, the rules engine 57 may perform the validation step 128 by analyzing log files, internal sensor feedback, usage of resources (e.g., processor, memory, paging files, etc.), or any combination thereof, of the process controller 16. As noted above, the rules engine 57 may validate the diagnostic alarm data 112 via analysis of alternative alarm sources, such as other controllers of a redundant controller 16. For example, in a triple modular redundant (TMR) controller 16, the validation step 128 may evaluate diagnostic alarm data 112 provided by controllers R, S, and T, each relating to the same problem. However, the diagnostic alarm data 112 may represent a problem with only one controller (e.g., R controller) rather than the other controllers (e.g., S and T controllers), and thus the validation step 128 may validate only the alarm directly relating to the R controller while not validating the alarm data 112 relating to the S and T controllers. Alternatively, the set of diagnostic alarm data 112 from the three controllers (e.g., R, S, and T) may be used to validate one another, rather than eliminating the alarm data 112 originating from controllers S and T. One example would be a communication loss with the R controller, which would result in communication related alarms in the R, S, and T controllers. As also noted above, the rules engine 57 may validate the diagnostic alarm data 112 via analysis of the alarm condition (if possible). For example, if the alarm condition relates to other alarms, then it may be possible to validate the diagnostic alarm data in view of the presence or absence of related alarms. One example includes a communication break due to a power loss to the IO pack, which may result in alarms related to the voltage drop by the IO pack monitoring power supply. The rules engine 57 is configured to eliminate any diagnostic alarm data 112 that does not correspond to an actual problem suitable for corrective action (e.g., false alarms).
At block 130, the rules engine 57 of the rules device 26 groups the diagnostic alarm data 112 from the workstations 20, 22, and 24 based on the rules 56 (e.g., grouping or classifying rules), thereby creating a plurality of groups based on logical or other relationships. As discussed above, the groups are generated by the grouping step 130 based on various rules 56, such as knowledge based rules, expert system rules, regression models, recursive rules, dynamic logic rules, neural network rules, genetic algorithm rules, fuzzy logic models, predictive models, “if . . . then . . . ” rules, or any combination thereof. For example, each group may be defined by one or more common characteristics in the diagnostic alarm data 112, such as a source or origination of the diagnostic alarm data 112, a type of the diagnostic alarm data 112, a code or identifier of the diagnostic alarm data 112, or any combination thereof. As appreciated, the knowledge based rules 56 may include known logical or other relationships between different alarms, alarms and components of the process controller 16, and so forth, based on experience or knowledge (e.g., of experts) relating to the controller 16 and/or the system 10. The rules 56 may also include historical data relating to alarms, including correlations between the diagnostic alarms and operational parameters, problems, solutions, etc. relating to the process controller 16 and/or the system 10. Furthermore, the rules engine 57 may be configured to learn or intelligently develop groupings of diagnostic alarms based on historical data, knowledge based data, statistical analysis, user input, and so forth. In certain embodiments, the rules engine 57 may store and/or generate a list of reference groups of logically related diagnostic alarms, e.g., akin to symptoms of one or more common health issues (e.g., problems). These reference groups may be used to group the diagnostic alarm data 112. However, any suitable rules 56 may be used to group the diagnostic alarm data 112 in a logical manner to facilitate the process 122 of identifying solutions for health issues (e.g., problems) of the process controller 16. For example, the relationships may be based on master-slave relationships, component-subcomponent relationships, cause-effect relationships, operating relationships, hardware-software relationships, and so forth.
At block 132, the rules engine 57 of the rules device 26 identifies at least one health issue (e.g., problem) relating to each group of the diagnostic alarm data 112 from the workstations 20, 22, and 24 based on the rules 56 (e.g., problem identification rules), thereby generating a list of possible problems. As discussed above, the health issues (e.g., problems) are identified by the step 132 based on various rules 56, such as knowledge based rules, expert system rules, regression models, recursive rules, dynamic logic rules, neural network rules, genetic algorithm rules, fuzzy logic models, predictive models, “if . . . then . . . ” rules, or any combination thereof. For example, the logically related diagnostic alarm data 112 in each group may be akin to symptoms, which may collectively suggest at least one health issue (e.g., problem) that may be corrected by the system itself or a user. In certain embodiments, the rules engine 57 may be configured to learn or intelligently identify health issues (e.g., problems) that are logically related to certain groups of diagnostic alarms based on historical data, knowledge based data, statistical analysis, user input, and so forth. Furthermore, the rules engine 57 may be configured to predict future health issues (e.g., problems) that are logically related to certain groups of diagnostic alarms based on historical data, knowledge based data, statistical analysis, user input, and so forth. The rules engine 57 also may be configured to statistically determine a likelihood of a problem existing or occurring, a priority level of the problem, a criticality of the problem, or a relevance to other problems. For example, the rules engine 57 may use the rules 56 to provide a list of rules in an order of priority, criticality, time of occurrence, and so forth. However, as appreciated, the problem identification step 132 may rely on a variety of rules 56 to identify one or more health issues (e.g., problems) for each group of diagnostic alarm data 112.
At block 134, the rules engine 57 of the rules device 26 identifies at least one solution (e.g., treatment) to correct the health issue (e.g., problem) relating to each group of the diagnostic alarm data 112 from the workstations 20, 22, and 24 based on the rules 56 (e.g., solution identification rules), thereby generating a list of possible solutions (e.g., treatments). As discussed above, the solutions (e.g., treatments) are identified by the step 134 based on various rules 56, such as knowledge based rules, expert system rules, regression models, recursive rules, dynamic logic rules, neural network rules, genetic algorithm rules, fuzzy logic models, predictive models, “if . . . then . . . ” rules, or any combination thereof. For example, the rules engine 57 may identify and prioritize the solutions based on a likelihood of success, relevance to the problem, and so forth. Thus, as illustrated in
At block 144, the rules engine 57 identifies logical or other relationships based on an analysis of characteristics of the diagnostic alarm data 112. For example, as discussed above, the rules engine 57 may compare the diagnostic alarm data 112 against historical data, knowledge based data, trends in the diagnostic alarm data 112, and various information contained with each alarm in the diagnostic alarm data 112. In particular, each alarm of the diagnostic alarm data 112 may include a plurality of properties, such as an alarm state, an alarm type, an alarm source, an alarm name, an alarm description, an alarm priority, or any other aspect. Each of these properties of the alarm data 112 may be used by the rules engine 57 for purposes of evaluation and identifying logical or other relationships among the alarm data 112. The rules engine 57 may use rules 56, such as predictive rules, statistical analysis rules, and so forth, to help analyze and intelligently identify the logical or other relationships.
At block 146, the rules engine 57 identifies logical or other relationships among diagnostic alarm data 112 based on user-defined relationships. For example, users may add relationships to the rules 56 based on their own knowledge, experience, and interactions with the process controller 16 and/or system 10. In this manner, the users can customize the rules 56 to facilitate grouping of the diagnostic alarm data 112. In certain embodiments, the users may be able to customize the rules 56 via certain software tools, which may also enable the user to view the diagnostic alarm data, operational data, trends, and other information, to help tailor the rules 56 (and logical or other relationships) to their specific needs and/or preferences. At block 148, the rules engine 57 groups the diagnostic alarm data 12 based on the relationships 142, 144, and 146, thereby generating groups 150. In certain embodiments, each group may include 1 to 100 or more of the diagnostic alarm data 112. Furthermore, each alarm of the diagnostic alarm data 112 may be limited to a single group, or the data 112 may appear in any number of the groups.
At block 156, the rules engine 57 identifies possible problems (e.g., health issues) based on an analysis of characteristics of the diagnostic alarm data 112. For example, as discussed above, the rules engine 57 may compare the diagnostic alarm data 112 against historical data, knowledge based data, trends in the diagnostic alarm data 112, and various information contained with each alarm in the diagnostic alarm data 112. In particular, each alarm of the diagnostic alarm data 112 may include a plurality of properties, such as an alarm state, an alarm type, an alarm source, an alarm name, an alarm description, an alarm priority, or any other aspect. Each of these properties of the alarm data 112 may be used by the rules engine 57 for purposes of evaluation and identifying possible problems among the alarm data 112. The rules engine 57 may use rules 56, such as predictive rules, statistical analysis rules, and so forth, to help analyze and intelligently identify the possible problems. For example, the rules engine 57 may effectively analyze each alarm of the diagnostic alarm data 112 as a potential symptom of a common health issue (e.g., problem), and thus the rules 56 may include a plurality of symptoms (e.g., alarms) indicative of each health issue (e.g., problem). Furthermore, the logical or other relationships used to define the groups 150 also help in identifying the possible problems. In other words, by evaluating the diagnostic alarm data 112 collectively within each group 150, the rules engines 57 may be able to more effectively and intelligently identify one or more problems relating to the process controller 16.
At block 158, the rules engine 57 identifies possible problems (e.g., health issues) among diagnostic alarm data 112 based on user-defined problem data. For example, users may add problems (or data used to identify problems) to the rules 56 based on their own knowledge, experience, and interactions with the process controller 16 and/or system 10. In this manner, the users can customize the rules 56 to facilitate the problem identification 158 within each group 150 of the diagnostic alarm data 112. In certain embodiments, the users may be able to customize the rules 56 via certain software tools, which may also enable the user to view the diagnostic alarm data, operational data, trends, and other information, to help tailor the rules 56 (and possible problems) to their specific needs and/or preferences. At block 160, the rules engine 57 prioritizes the possible problems associated with each group 150 of the diagnostic alarm data 12 based on the identified problems 154, 156, and 158, thereby generating a prioritized list or set of problems 162. For example, the problems may be prioritized according to a criticality to the health of the process controller 16, a time sensitivity to resolution (e.g., how urgent the alarm should be addressed to mitigate further problems), a time of receipt, a statistical correlation with other problems (e.g., likelihood of leading to additional problems in other areas), or any combination thereof. In certain embodiments, each set of problems 162 may include 1 to 10 or more problems associated with each group 150 of the diagnostic alarm data 112. Furthermore, each problem 162 may be limited to a single group 150, or the problem 162 may appear in any number of the groups 150.
At block 168, the rules engine 57 identifies possible solutions for the problems 162 (e.g., health issues) associated with each group 150 of the diagnostic alarm data 112 based on an analysis of characteristics of the diagnostic alarm data 112. For example, as discussed above, the rules engine 57 may compare the diagnostic alarm data 112 and/or the possible problems 162 against historical data, knowledge based data, trends in the data 112 and/or problems 162, and various information contained with each alarm in the diagnostic alarm data 112. In particular, each alarm of the diagnostic alarm data 112 may include a plurality of properties, such as an alarm state, an alarm type, an alarm source, an alarm name, an alarm description, an alarm priority, or any other aspect. Each of these properties of the alarm data 112 may be used by the rules engine 57 for purposes of evaluation and identifying possible solutions for the problems 162. The rules engine 57 may use rules 56, such as predictive rules, statistical analysis rules, and so forth, to help analyze and intelligently identify the possible solutions. Again, the logical or other relationships used to define the groups 150 also help in identifying the possible solutions. In other words, by evaluating the diagnostic alarm data 112 and problems 162 collectively within each group 150, the rules engines 57 may be able to more effectively and intelligently identify one or more solutions for the problems 162 relating to the process controller 16.
At block 170, the rules engine 57 identifies possible solutions for the problems 162 (e.g., health issues) associated with each group 150 of the diagnostic alarm data 112 based on user-defined solution data. For example, users may add solutions (or data used to identify solutions) to the rules 56 based on their own knowledge, experience, and interactions with the process controller 16 and/or system 10. In this manner, the users can customize the rules 56 to facilitate the solution identification 170 within each group 150 of the diagnostic alarm data 112. In certain embodiments, the users may be able to customize the rules 56 via certain software tools, which may also enable the user to view the diagnostic alarm data, operational data, trends, and other information, to help tailor the rules 56 (and possible solutions) to their specific needs and/or preferences. At block 172, the rules engine 57 prioritizes the possible solutions for problems 162 associated with each group 150 of the diagnostic alarm data 12 based on the identified problems 166, 168, and 170, thereby generating a prioritized list or set of solutions 174. For example, the solutions may be prioritized according to a statistical relevancy to the particular problem or set of problems within each group 150, a statistical success rate at solving the particular problem or set of problems within each group 150, or any other prioritization scheme. In certain embodiments, each set of solutions 174 may include 1 to 10 or more solutions for each problem 162 associated with each group 150 of the diagnostic alarm data 112. Furthermore, each solution 174 may be limited to a single group 150, or the solution 174 may appear in any number of the groups 150.
The solution section 182 depicts the solutions 174 for the problem 162 (e.g., health issues) associated with the diagnostic alarm data 112, as provided by the process 164 of
Technical effects of the invention include systems and methods for processing diagnostic alarm data that relates to the health of components of the process controller 16. Filters may remove redundant, unusable, expected, invalid or other alarm data from diagnostic alarm data to make it easier to analyze. The data is then logically grouped and problems associated with each group are identified. Solutions are identified and associated with each group and problem. A user may then analyze the diagnostic alarm data, groups, problems and solutions and resolve issues that relate to the health of components of the process controller 16. Thus, the diagnostic alarms can be used more accurately and with less training for operators, thereby improving the overall health and operation of the process controller 16.
This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.